실제 운영될 서비스를 기획자 없이 개발자로만, 바이브 코딩 프로젝트 회고
기획자와 디자이너 없이, 서버와 프론트엔드를 합쳐 개발자 4명으로만 약 2개월간 프로젝트를 진행했다. 다른 프로젝트들과 병행했기 때문에 실질적인 개발 기간은 그보다 더 짧았다.
기획과 디자인은 기존 프로젝트를 바탕으로 마이그레이션을 하면서, 동시에 새로운 기능을 얹는 프로젝트였다. 유저 페이지와 관리자 페이지가 나눠져있기 때문에, 유저 기능과 관리자 기능을 각자 나눠 맡아 진행하였으며, 내가 맡았던 유저페이지의 주요 변경 사항은 다음과 같았다.
- NextJS 마이그레이션 : 기존 구조에서는 고객사별로 메타태그를 커스텀할 수 없다는 한계가 있어 이를 보완하기 위해 도입했다.
- FSD 구조 채택 : 현재 프론트엔드 팀 컨벤션으로 도입되고 있어, FSD 구조를 채택하게 되었다.
- 새로운 기능과 굵직한 수정사항 : 멤버십, 외부 사이트 SSO 연동, 결제 모듈 변경 등
원래대로라면 기존 프로젝트에 기능을 추가하는 방식으로 진행했겠지만, 공통화가 어려운 기능이 많았다. 게다가 최근 회사 전반에 AI를 최대한 활용해보자는 분위기가 있어서, 소수 인원이 AI를 적극적으로 활용하는 방식으로 프로젝트를 진행하게 됐다.
"활용"을 넘어 "바이브 코딩"에 가까웠던 개발 방식
프론트엔드와 서버 모두 AI를 최대한 활용해 아주 빠르게 개발해 나갔다. 흐름은 대략 이랬다.
- 서버팀에서 클로드를 사용하여 API와 문서를 만든다.
- 그 결과물을 프론트엔드에게 전달한다.
- 프론트엔드는 다시 클로드에게 그 문서를 바탕으로 개발한다.
AI를 "적극적으로 활용"한다는 표현을 넘어, 사실상 바이브 코딩에 가까운 방식이었다. 결제 모듈까지 포함된 중요한 서비스를 이런 방식으로 개발한다는 건 흔치 않은 경험이었고, 개발자로서 왠지 모를 죄책감도 들었다. 하지만 실제 서비스로 운영까지 하다보니, 역시 어느정도의 장단점이 있는 하나의 개발 방식이라는 생각이 들었다.
ㅤ
장점 1. 빠른 기능 개발과 빠른 되돌리기
가장 크게 체감한 장점은 빠르게 만들고 빠르게 되돌릴 수 있다는 점이었다. 기획이 확실히 정해지지 않은 상태였고 고객사 요청도 계속 바뀌었기 때문에, 만들었던 기능을 다시 들어내거나 방향을 바꾸는 비효율적인 작업이 잦았다.
프로젝트 규모가 작았던 데다 FSD 구조 덕분에 코드가 복잡하게 얽혀 있지 않아, 기능을 추가하거나 삭제하는 일이 간단했다. FSD의 단점으로 흔히 꼽히는 복잡함과 진입 난이도 역시 클로드 덕분에 큰 어려움 없이 작성할 수 있었다.
장점 2. 프론트엔드 - 서버간 커뮤니케이션 비용 감소
서버와 프론트엔드 양쪽 모두 바이브 코딩에 가깝게 개발하다 보니, 서버는 AI가 빠르게 뽑아낸 문서를 일일이 검토하지 않아도 됐고, 프론트엔드 역시 AI로 화면을 개발하니 문서의 길이나 복잡성을 크게 신경 쓸 필요가 없었다.
문서를 먼저 읽고 이해한 뒤 개발을 시작하는 게 아니라, 문서를 바탕으로 개발을 끝낸 뒤 결과물을 보며 변경 사항을 파악하는 식이었다. 이 순서의 역전이 커뮤니케이션 비용을 꽤 많이 줄여줬다.
ㅤ
단점 1. 기획자와 디자이너의 부재에서 오는 기획과 디자인의 필요성
기존 기획과 디자인이 있다고는 하지만, 새로 추가되는 기능이나 브랜드 이미지를 녹여내는 부분에서는 어딘가 어설픈 느낌이 남았다. AI가 기획도 잘한다고들 하지만, 전체 플로우나 사소한 부분을 놓쳐 결국 먼 길을 돌아가는 경우가 있었다. 디자인 역시 무엇이 좋은 디자인인지 판단하기 어려워, 결국엔 디자이너 분께 직접 여쭤보거나 부탁드리는 일이 생겼다.
단점 2. 코드가 내 손을 벗어났다는 불안감
AI가 작성한 결과물을 검토한다고는 하지만, 여러 세션을 동시에 돌리면서 얽히는 코드까지 확실히 검토했냐고 한다면, 솔직히 아니었다. 그렇기 때문에 불안했다. 결과물을 검토하다 잘못된 점을 발견할 때면 그 불안이 더 커졌고, 코드 분량이 늘어날수록 어느 순간 내가 이걸 통제하지 못하게 되는 것 아닐까 하는 생각이 들었다.
단점 3. 수정이 쌓일수록 사람이 읽기 힘든 코드가 된다
개발이 진행될수록 방향이 바뀌거나 수정되는 일이 잦았는데, 그럴 때마다 팀 클로드 지침에 따라 내부 메모리에 기록이 남고, 바뀐 히스토리가 주석으로 계속 쌓였다. 그러다 보니 코드 한 줄에 주석이 네 줄씩 붙기도 하고, 이미 수정되어 더 이상 유효하지 않은 방향을 가리키는 잘못된 주석이 남기도 했다.
ㅤ
실제 서비스로 운영하며 느낀 것들
약 두 달간 바이브 코딩에 가까운 형태로 진행된 이 개발은, 과정 내내 불안했지만 결국 실서비스로 운영되고 있다. 아직 오래되진 않았지만 꽤 괜찮은 이용률과 매출을 보여주고 있다. 운영하면서 느낀 점들은 다음과 같다.
오히려 기존 서비스보다 문제 발생률이 낮았다
개발에 쓸 리소스를 QA에 집중할 수 있었던 덕분에 실사용 시 문제 발생률이 오히려 낮았다. 개발 과정에서 사람이 놓칠 법한 부분을 AI가 먼저 짚어줘 보완했던 경우도 종종 있었다. 이렇게 해서 정말 서비스를 할 수 있을까 싶을 정도로 불안했는데, 예상과는 정반대의 결과였다.
내가 만든 코드지만 남의 코드처럼 느껴진다
요청 사항이나 버그를 처리하다 보면, 분명 내가 만든 코드인데도 다른 사람의 코드를 읽는 기분이 들었다. 평소라면 문제가 생긴 위치나 수정할 지점을 바로 짚어냈겠지만, AI로 빠르게 개발하다 보니 주요 서비스를 제외하고는 어떤 기능이 어디에 있는지 정확히 기억하기 어려웠다.
여기서 한 가지 기이한 느낌이 있었다. "AI가 쓴 코드"라는 느낌보다는 "다른 사람이 짠 코드"를 읽는 것 같았다는 점이다. 누구나 읽기 쉬운 우아한 구조는 아니었지만, 디버깅을 하거나 구조를 파악할 때 큰 어려움은 없었다. 그 지점에서, 적어도 어중간한 개발자보다는 낫다는 생각이 들었다.
ㅤ
복잡하거나 위험 부담이 큰 프로젝트였어도 이렇게 할 수 있었을까?
이 프로젝트는 어느 정도 믿을 구석이 있었기에 과감하게 AI를 쓸 수 있었다. 잘못되면 기존 프로젝트로 돌아갈 수 있었고, 완성된 뒤 크게 수정할 일이 없는 성격의 프로젝트이기도 했다.
또 하나, 각자 하나의 레포지토리를 맡아 거의 1인 개발에 가깝게 진행했기 때문에 가능했다고 생각한다. 그 덕에 AI를 쓸 때 생기기 쉬운 코드 충돌이나 복잡함이 없었고, 책임 영역이 겹치지 않아 훨씬 편하게 개발할 수 있었다.
결국 이건 시범적으로 시도해본 프로젝트였기 때문에 가능했다고 본다. 개발하면서도 위험하다고 느낀 부분이 많았다. AI 코딩에서 흔히 나오는 이야기인, **"책임은 누가 지는가?"**를 직접 체감하기도 했다. AI가 만든 문서를 바탕으로 개발했는데 그 코드가 잘못됐다면, 잘못된 문서를 만든 서버의 잘못인가, 그 문서대로 잘못된 코드를 짠 프론트엔드의 잘못인가?
그뿐 아니라, 코드 품질이 떨어지는 부분이 있을 때 그게 개발자의 의도가 아니라 AI의 결과라는 걸 알기 때문에, 문제점을 지적하기가 난감했던 경험도 있었다. 이 코드의 문제를 설명한다 한들 결국 AI를 다시 학습시킬 뿐이지, 개발자가 배울 수 있을까 하는 생각도 들었다.
AI는 최고의 도구이지만, 앞으로도 도구로써 남을 것 같다.
바이브 코딩에 대해 다른 사람들은 어떻게 생각하는지 찾아보니, 많은 사람이 비슷한 궁금증과 의견을 나누고 있었다. 대체로 모이는 결론은 바이브 코딩으로 결과물을 만들 수 있는 조건이 1인 개발, 유지보수 부담이 크지 않음, 작은 규모라는 것이었는데, 이번 프로젝트에서 내가 느낀 점과 상당히 닮아 있었다.
바이브 코딩이 처음 유행할 때, 나는 AI가 더 발전하면 정말 바이브 코딩만으로도 서비스를 만들 수 있지 않을까 생각했다. 그때와 비교하면 지금의 AI는 컨텍스트 용량이 100배 이상 늘어날 만큼 무섭게 성장했다. 그럼에도 아직 바이브 코딩만으로 좋은 서비스를 만들기는 어렵지 않을까 싶었다. 정확하게 말하자면, 바이브 코딩만으로 좋은 서비스를 만들 수는 있지만 그 서비스를 유지보수 하면서 더 큰 서비스로 확장하기에는 바이브 코딩만으로는 한계가 있다고 생각한다. 그럼에도 AI는 획기적인 생산성 도구이자 개발 패러다임이고, 개발자의 밥그릇 노리는 도구라는 것은 슬프지만 인정해야만 할 것 같다.