CS 앱 바이브 코딩: 아키텍트는 꼭 필요한데! 코더는??
- Marcetto Corp.
- 1월 20일
- 2분 분량
앞선 블로그에서 바이브 코딩 고객이탈 관리 앱을 만들면서 느낀 놀라움을 잠시 공유했죠. 개발자가 코드를 한 줄씩 정성스레 써 내려 가는 대신, 자산의 생각 혹 의도(Vibe)를 채팅 창에 입력하면 AI가 코드 알아서 다해주는 바이브 코딩을 하면서 처음 든 생각은 이랬습니다. 이제 개발이라는 일이 "How" 에서 "What"으로 옮겨가는구나.
경험으로 배운 바이브 코딩의 한계: "나무는 보되 숲은 보지 못한다"
바이브 코딩을 하면서 얻은 교훈은 AI가 단위 업무는 기막히게 수행하지만, 전체적인 구조(숲)를 보는 능력은 아직은 부족하다는 점입니다(물론 저의 오해일 수 있습니다). 그리고 이로 인해 아래와 같은 문제를 경험하게 되었습니다.
맥락을 이해하지 못한다: 하지만 자신이 만드는 앱의 전체 그림이나 기능 간의 유기적인 관계는 잘 이해하지 못하는 것 같습니다.
비효율 이슈: 전체 구조를 잡아주는 '설계도' 없이 대화로만 진행하다 보니, 중복 작업이 발생하거나 애써 만든 기능을 삭제하거나 재작업, 중복 작업하는 경우가 종종 발생합니다. 마치 건물을 짓는데 설계도 없이, 지반도 다지지 않고 기둥 올리고, 지붕 얹는 것 같은 느낌이었습니다.
안정성과 확장성 문제: 무식하면 용감하다고, 기능을 자꾸 넣어서 앱이 커질수록 데이터 흐름이 꼬이고 자꾸 에러가 발생합니다. 버그 해결도 점점 어려워지고 ㅎㅎ.
개발의 일관성: 앱 개발 전체에 대한 전략과 이해가 부족하고 로드맵도 없다보니, 일관성이 아주 많이 부족합니다. 예를 들어, 고객 데이터 관리 기능을 작업하다가 데이터 분석 기능 작업을 하고 있고, 한마디로 우왕좌왕입니다.
이런 시행착오를 경험하면서 생각이 또 바뀌었습니다: “코더는 몰라도, 아키텍트는 꼭 필요할 것 같은데?”
코더는???, 하지만 아키텍트는 꼭 필요한데!
시행착오를 하면서 얻은 중간 결론은 코더(Coder)의 필요성은 커지지 않지만, 아키텍트(Architect)는 점점 더 커졌다는 점입니다. 그래서 경험 많은 아키텍트 한 분을 소개받아 협업을 하게 되었죠. 같이 일하면서 숲 전체를 보고 설계도를 그려내고, 결과물을 만들어내도록 관리하는 아키텍트의 가치를 깨닫고 있습니다.
아키텍트와 함께 일하면서 느낀 그들의 역할과 가치입니다.
잘 돌아가는 앱을 만드는데 필요한 개발 법과 순서를 배워가고 있습니다.
좋은 앱을 개발하기 위해 무엇을 고민하고 어떤 것을 준비해야 하는지 배우고 있습니다.
앱 개발 과정의 위험 요소와 위험 관리 방법을 배우고 있습니다.
개발 중인 앱의 뒷면에 숨어 있는 요소(예를 들어, 앱의 데이터베이스와 데이터 처리 방식 등)와 요소간 관계와 구조를 대충이라도 알게 되었습니다.
그리고 이런저런 사소한 것들까지…
바이브 코딩이 나무는 잘 보지만 숲은 못보는 것 같다고 흉을 봤는데, 저에게도 앱 개발이란 숲이 조금씩 보이기 시작합니다. 내용을 정리하다 보니 ‘배운다’라는 동사를 많이 썼네요. 남의 일이라고 생각하던 코딩을 만나면서 학습자 모드가 On 된 것 같습니다. 즐거운 경험입니다.
기업의 성장과 지속가능성을 위한 Customer Success 전략과 실행 모델을 제시합니다.
▶ 해당 콘텐츠는 저작권법에 의하여 보호받는 저작물로 (주)마르케또에 저작권이 있습니다.
▶ 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적 이용을 허용하지 않습니다.
댓글