앞선 블로그에서 바이브 코딩 고객이탈 관리 앱을 만들면서 느낀 놀라움을 잠시 공유했었죠. 개발자가 코드를 한 줄씩 정성스레 써 내려 가는 대신, 자산의 생각 혹 의도(Vibe)를 채팅 창에 입력하면 AI가 코드 알아서 다해주는 바이브 코딩을 하면서 처음 든 생각은 이랬습니다. 이제 개발이라는 일이 "How" 에서 "What"으로 옮겨가는구나. 그런데 좀 더 시간이 지나면서 생각이 또 바뀌었습니다. 

경험으로 배운 바이브 코딩의 한계: "나무는 보되 숲은 보지 못한다"

바이브 코딩을 하면서 얻은 교훈은 AI가 단위 업무는 기막히게 수행하지만, 전체적인 구조(숲)를 보는 능력은 아직은 부족하다는 점입니다(물론 저의 오해일 수 있습니다). 그리고 개발 능력과 경험 Zero인 내 상황과 맞물려 아래의 문제들을 경험했습니다:  
 

• 단위 기능은 뛰어나다: AI는 지시한 특정 기능 구현이나 에러 수정은 참 빠르고 정확합니다.
• 맥락을 이해하지 못한다: 하지만 자신이 만드는 앱의 전체 그림이나 기능 간의 유기적인 관계는 잘 이해하지 못하는 것 같습니다.
• 비효율 이슈: 전체 구조를 잡아주는 '설계도' 없이 대화로만 진행하다 보니, 중복 작업이 발생하거나 애써 만든 기능을 삭제하거나 재작업, 중복 작업하는 경우가 종종 발생합니다. 마치 건물을 짓는데 설계도 없이, 지반도 다지지 않고 기둥 올리고, 지붕 얹는 것 같은 느낌이었습니다. 
• 안정성과 확장성 문제: 무식하면 용감하다고, 기능을 자꾸 넣어서 앱이 커질수록 데이터 흐름이 꼬이고 자꾸 에러가 발생합니다. 버그 해결도 점점 어려워지고 ㅎㅎ.
• 개발의 일관성: 앱 개발 전체에 대한 전략과 이해가 부족하고 로드맵도 없다보니, 일관성이 아주 많이 부족합니다. 예를 들어, 고객 데이터 관리 기능을 작업하다가 데이터 분석 기능 작업을 하고 있고, 한마디로 우왕좌왕입니다. 

이런 시행착오를 경험하면서 생각이 또 바뀌었습니다: “코더는 몰라도, 아키텍트는 필요할 것 같은데?” 

코더는???, 하지만 아키텍트는 꼭 필요한데!

시행착오를 하면서 얻은 중간 결론은 코더(Coder)의 필요성은 크지 않지만, 아키텍트(Architect)는 점점 더 커졌다는 점입니다. 그래서 경험 많은 아키텍트 한 분을 소개받아 협업을 하게 되었죠. 같이 일하면서 숲 전체를 보고 설계도를 그려내고, 결과물을 만들어내도록 관리하는 아키텍트의 가치를 깨닫고 있습니다. 

내가 느낀 아키텍트의 가치, 

능력있는 아키텍트 분과 일하면서 느낀 그들의 가치입니다.

• 잘 돌아가는 앱을 만드는데 필요한 개발 방법과 순서를 배워가고 있습니다.
• 좋은 앱을 개발하기 위해 무엇을 고민하고, 어떤 것을 준비해야 하는지 배우고 있습니다.
• 앱 개발 과정의 위험 요소와 위험 관리 방법을 배우고 있습니다.
• 개발 중인 앱의 뒷면에 숨어 있는 요소(예: 앱 보안, 앱의 데이터베이스와 데이터 처리 방식 등)와 요소간 관계와 구조를 대충이라도 알게 되었습니다.
• 그리고 이런저런 소소한 것들…

바이브 코딩이 나무는 잘 보지만 숲은 못보는 것 같다고 흉을 봤는데, 저에게도 앱 개발이란 숲이 조금씩 보이기 시작합니다. 내용을 정리하다 보니 ‘배운다’라는 동사를 많이 썼네요. 남의 일이라고 생각하던 코딩을 만나면서 학습자 모드가 On 된 것 같습니다. 즐거운 경험입니다.