최근 바이브코딩 비판 글을 여러 개 읽었다. "2년간 바이브코딩 후 손코딩 복귀", "바이브 코딩의 마법을 깨기", "8년차 AI 엔지니어가 바이브코딩을 포기한 이유". 다들 경험에서 우러나온 글이고, 지적도 맞는 말이 많았다. AI가 생성한 코드는 유지보수가 어렵다. 동의한다.
다만 나는 개발자가 아니라 기획과 개발 사이에서 일해온 사람이다. 그래서인지 이 글들을 읽으면서 자꾸 다른 지점이 걸렸다.
나는 기획자가 의도한 것과 개발자가 이해한 것이 다를 때마다 되돌아가는 비용을 오래 지켜봤다. 그 경험에서 보면, "코드를 잘 짜느냐"보다 "사업 니즈를 고객 서비스로 바꾸는 전체 과정에서 각 단계의 출발선을 어떻게 앞으로 당길 것인가"가 더 넓은 질문이 아닐까 싶다.
개발의 시작은 사업적 니즈다. 아웃풋은 고객에게 제공하는 서비스다. 그 사이에 기획, 디자인, 개발, 테스트, 배포가 있다. 유지보수 가능한 코드도 중요하지만, 이걸 최종 결과물로 놓는 순간 개발 앞뒤의 단계가 시야에서 사라진다.
같은 지도를 봐야 출발선을 당길 수 있다
개발 프로세스를 릴레이 경주에 비유해보겠다. 기획 → 디자인 → 개발 → 테스트 → 배포. 각 주자가 바통을 넘기며 달린다. 바이브코딩 비판은 "개발 주자의 폼이 엉성하다"는 거다. 틀린 말은 아니지만, 전체 경주 시간을 줄이려면 각 주자가 더 앞에서 출발할 수 있게 만드는 게 효과적이다.
내가 겪은 팀에서는 "해석-변형-되돌아감" 사이클이 가장 큰 지연 요인이었다. 기획자가 PRD를 쓰면 디자이너가 해석하고, 개발자가 또 해석하는 데 시간이 걸렸다. 해석 과정에서 의도가 변형되면 되돌아갔다. 이런 커뮤니케이션 집약적인 환경에서는 이 해석 비용이 무시하기 어렵다.
바이브코딩은 이 초기 해석 비용의 일부를 효율적으로 개선할 수 있다. 기획자가 자연어로 의도를 전달하면, AI가 동작하는 프로토타입을 만든다. "이게 내가 원한 건가?"를 실물로 확인할 수 있다. 해석이 사라지는 건 아니다. 하지만 문서와 와이어프레임 사이를 오가며 추상적으로 맞추던 과정이, 실물을 놓고 구체적으로 확인하는 과정으로 바뀐다. 다음 주자가 백지가 아니라 동작하는 기준점에서 출발할 수 있다.
출발선을 당기려면 전제 조건이 있다. 모든 주자가 같은 지도를 봐야 한다.
PRD가 그 지도 역할을 해야 한다. 기획, 디자인, 개발, 테스트 모든 단계에서 하나의 소스를 보고 일하는 것. SSOT(Single Source of Truth)다. 현실은 다르다. 기획자는 Confluence에, 디자이너는 Figma에, 개발자는 Jira 티켓에 각자의 해석을 만든다. 같은 기능인데 세 버전의 요구사항이 생긴다.
기획자 관점에서 내가 생각하는 접근은 이렇다. 바이브코딩을 PRD를 빠르게 만드는 데 먼저 접목한다. 기획자가 자연어로 의도를 쏟아내면, AI가 구조화된 PRD 초안을 만들어준다. 여기까지는 바이브코딩이 잘하는 영역이다.
그런데 PRD가 기획 의도만 담고 있으면, 다음 단계가 시작을 못 한다. 디자이너는 "뭘 기준으로 화면을 잡지?", 백엔드 개발자는 "API 스펙이 어디까지 확정된 거지?", QA는 "뭘 검증해야 하지?"가 된다. 결국 각 부서가 시작하려면 뭐가 필요한지 — 그 Input을 PRD에 정의하는 게 핵심이다.
각 영역의 성공 조건은 해당 부서가 가장 잘 안다. 기획자가 그걸 대신 정의할 수는 없다. 대신 기획자가 할 수 있는 건, 각 부서가 "이게 있으면 시작할 수 있다"고 말하는 Input의 구조를 PRD에 담는 거다. 이렇게 시작 조건이 명확해지면, 이전 단계에서 뭘 어디까지 만들어야 하는지가 정해지고, 각자가 순서를 기다리지 않고 병렬로 출발할 수 있다. 출발선이 앞으로 당겨지는 건 이런 구조에서 나오지 않을까 싶다.
PRD가 모든 걸 담을 필요는 없다. 핵심은 "기준 문서가 하나"라는 원칙이다. 해석이 갈리면 PRD를 업데이트한다. 구두 합의로 넘어가지 않는다.
한 번에 전부가 아니라, 단계별로 빠르게
바이브코딩으로 한 번에 완성된 서비스를 만들려는 접근을 종종 본다. "AI야, 이런 앱 만들어줘." 이건 바이브코딩이든 손코딩이든 실패하기 쉽다.
이것도 마찬가지로 나눠서 접근해야 한다. 단계를 나누고, 각 단계를 빠르게 진행하는 데 집중한다. 내 경우에는 이런 리듬으로 잡았을 때 기획을 빠르게 진행하는 효과가 있었다.
- PRD → 프로토타입: 하루 이내. 의도 확인이 목적이다.
- 프로토타입 → 각 영역 피드백: 반나절. 각자의 시작 조건에 비춰 "이게 되나?"를 확인한다.
- 피드백 → PRD 업데이트
- 확정된 PRD → 각 영역 병렬 진행
내가 기획 프로세스를 나눠서 AI를 접목하는 것처럼, 각 팀도 자기 영역의 워크플로에 맞게 접목하면 된다. 팀과 도메인에 따라 절차와 시간은 달라진다. 그리고 나뉘어진 워크플로를 연결하는 공통 문서 — 그게 앞서 말한 PRD다. 물론 프로토타입은 의도 확인 도구일 뿐이다. 동작한다고 프로덕션에 바로 쓸 수 있는 건 아니다.
"바이브코딩이 좋은 코드를 만드느냐." 중요한 질문이지만, 그것만으로는 좁다.
"사업 니즈에서 고객 서비스까지, 각 부서가 시작할 수 있는 조건을 어떻게 앞당길 것인가." PRD를 SSOT로 설계하고, 각 부서의 시작 Input을 정의하고, 바이브코딩으로 초기 해석 비용을 줄인다.
그리고 이 프로세스의 답은 아마 도메인마다 다를 거라고 생각한다. 정답이 하나였다면 범용 도구 하나로 충분하지 않았을까. 최근 FDE(Field Development Engineer)라는 직군이 부상하고, AI 컨설팅 조직이 기업별 개발 프로세스를 설계해주는 흐름이 생기는 것도 그래서인 것 같다. 각 조직의 사업 구조, 팀 구성, 도메인 특성이 다르니까.
바이브코딩 하나로 기획부터 배포까지 모든 답을 찾으려는 접근은, 내가 보기에 1인 개발이나 초기 스타트업에 더 맞는 방식이다. 조직이 커지고 도메인이 복잡해질수록, 바이브코딩은 전체 프로세스의 특정 단계를 가속하는 수단에 가까워지지 않을까. 어떤 단계에, 어떤 조건으로 쓸 것인지. 나는 그 설계가 더 흥미로운 질문이라고 느낀다.
불러오는 중...