2. 기획자 없는 개발, 그리고 첫 번째 장벽

  처음에는 일반적인 개발 프로세스를 따르려고 했습니다. 요구사항을 정리하고, ERD를 그리고, API 명세를 작성하는 등 전통적인 방식을 시도했습니다. 하지만 여기서 또 다른 벽에 부딪혔습니다.

설계 단계에서 ERD, 프롬프트 설계, API 구조화 등을 진행해야 하는데, 기획자 없이 이 모든 것을 체계적으로 정리하기가 예상보다 훨씬 어려웠습니다. 특히 사용자 관점에서의 검증이 부족해 개발 내내 의문이 들었습니다. 저희가 겪었던 어려움은 다음과 같습니다.

3. 전환점: Windsurf와 '바이브 코딩' 개념의 발견

  그러던 중 Windsurf라는 도구를 알게 되었습니다. 당시에는 Cursor가 유명했지만, 아직 자연어로 직접 코딩하는 기능은 없었습니다. 그런데 Windsurf에서는 'Cascade'라는 서비스를 통해 자연어로 코딩이 가능하다는 것을 발견했습니다.

당시에는 '바이브 코딩'이라는 용어보다는 'Chat Driven Development'라고 불리던 초기 단계였습니다. 하지만 이것이야말로 저희가 찾던 해답이라는 직감이 들었습니다.

• Cascade를 통한 자연어 코딩 가능성 발견

• 기존 개발 방식의 한계 극복 가능성

• 기획-개발 간극을 메울 수 있는 새로운 접근법

• 프로토타입 개발 속도 향상 기대

안드레이 카파시(Andrej Karpathy)의 X

4. 초기 기대와 현실의 간극: AI 협업의 시행착오

  처음에는 "유레카!"를 외치며 신나게 시작했습니다. 하지만 곧 현실의 벽에 부딪혔습니다.

• 주요 문제점들

• 할루시네이션: AI가 존재하지 않는 라이브러리나 메서드를 제안하는 경우

• 무한 버그 루프: 한 버그를 고치면 다른 버그가 생기는 현상의 반복

• 컨텍스트 손실: 대화가 길어질수록 AI가 이전 맥락을 잃어버리는 문제

  이런 문제들을 겪으며 단순히 자연어로 대화한다고 해서 모든 것이 해결되지는 않는다는 것을 깨달았습니다.

퉁퉁퉁 사후르가 Vibe Coding 초입에 기다리고 있음

5. 문제 해결 과정: 저만의 노하우를 쌓다

  여러 시도를 통해 저는 점진적으로 방법을 개선해 나갔습니다. 제가 찾은 핵심은 적절한 난이도의 프롬프트 작성과 명확한 역할 부여, 그리고 단계별 TODO 관리였습니다. 특히 한 번에 모든 것을 요구하지 않고, 작은 단위로 나누어 진행하니 훨씬 안정적인 결과를 얻을 수 있었습니다.

6. 바이브 코딩을 활용한 UI/UX 설계: 의외의 성과

  가장 큰 성과 중 하나는 화면 설계 부분이었습니다. 보통 UI/UX는 전문 디자이너나 기획자의 영역이라고 생각하기 쉽지만, 바이브 코딩을 통해 이 부분도 상당 부분 해결할 수 있었습니다.

진행 과정 :

• Diagram으로 그린 그림들을 AI에 입력하여 화면 설계를 요청

• 이를 바탕으로 한 초기 화면 설계 초안 생성

• 3~4번의 반복 개선을 통한 최종안 도출

  이 과정에서 개발자 관점에서 놓치기 쉬운 사용자 경험까지 자연스럽게 고려할 수 있었습니다. 물론 요즘에는 Figma 시안을 Windsurf나 Cursor 같은 도구에 바로 적용하여 프로토타입을 만들어 볼 수도 있습니다.

7. 바이브 코딩(Vibe Coding)이 가져온 구체적인 성과

  저는 이제 바이브 코딩을 단순한 코드 생성기가 아닌, 저의 전략적 파트너로 활용하고 있습니다. 그 결과, 이전에는 상상하기 어려웠던 구체적인 성과들을 만들어낼 수 있었습니다.

• 개발 속도 향상: 가설 검증 주기의 단축 단순히 프로토타입을 빨리 만드는 것을 넘어, 아이디어를 신속하게 실제 작동하는 형태로 구현함으로써 핵심 가설을 빠르게 검증하고 사용자 피드백 주기를 획기적으로 단축할 수 있었습니다.

• 코드 품질 개선: 저만의 규칙을 시스템화 AI에게 제가 정의한 '글로벌 룰'(8번 항목 참고)을 명시적으로 주입했습니다. SOLID 원칙, 클린 아키텍처 등을 따르도록 지시한 결과, 제가 작성하는 코드의 품질과 패턴이 일관되게 유지되었습니다.

• 사용자 경험(UX) 향상: 기획자 페르소나 활용 AI에게 기획자의 페르소나를 부여하고 "당신은 이 서비스의 핵심 사용자입니다. 어떤 화면이 가장 편리할까요?" 와 같이 질문했습니다. 이를 통해 제가 놓칠 수 있는 UX 허점을 보완하고, 더 사용자 중심적인 결과물을 만들 수 있었습니다.

• 업무 효율 증대: '움직이는 명세서'로서의 프롬프트 제가 작성한 프롬프트가 '움직이는 명세서(Living Specification)' 역할을 하면서, 개발 목표와 맥락을 명확히 하여 불필요한 커뮤니케이션 비용을 줄이고 오롯이 개발에만 집중할 수 있었습니다.

8. 실전에서 체득한 저만의 바이브 코딩 활용 전략

1. 명확한 목적과 목표 설정 

첫 대화에서 만들고자 하는 앱의 목적과 목표를 명확히 전달해야 합니다. 애매한 설명은 애매한 결과를 낳습니다.

2. 구체적인 TODO 제시 

"좋은 앱을 만들어줘"보다는 "사용자 로그인 기능을 구현해줘. 이메일과 비밀번호로 인증하고, JWT 토큰을 사용해줘"처럼 구체적인 임무를 부여해야 합니다.

3. 글로벌 룰 활용 

프로젝트 전반에 적용될 규칙들을 미리 정해두고 일관되게 적용하는 것이 중요합니다. 아래는 제가 사용했던 글로벌 룰이며, Windsurf뿐만 아니라 Cursor, Github Copilot 등에도 적용할 수 있으니 참고하시면 좋겠습니다.

​1 구현 작업 원칙
SOLID 원칙을 사용해서 구현하세요:
단일 책임 원칙 (Single Responsibility Principle)
개방-폐쇄 원칙 (Open-Closed Principle)
리스코프 치환 원칙 (Liskov Substitution Principle)
인터페이스 분리 원칙 (Interface Segregation Principle)
의존성 역전 원칙 (Dependency Inversion Principle)
TDD로 구현하세요: 테스트 주도 개발 방식으로 먼저 테스트를 작성하고 구현하세요.
Clean Architecture를 사용해서 구현하세요: 책임과 관심사를 명확히 분리하여 구현하세요.
2 코드 품질 원칙
단순성: 언제나 복잡한 솔루션보다 가장 단순한 솔루션을 우선시하세요.
중복 방지: 코드 중복을 피하고, 가능한 기존 기능을 재사용하세요 (DRY 원칙).
가드레일: 테스트 외에는 개발이나 프로덕션 환경에서 모의 데이터를 사용하지 마세요.
효율성: 명확성을 희생하지 않으면서 토큰 사용을 최소화하도록 출력을 최적화하세요.
3 리팩토링
리팩토링이 필요한 경우 계획을 설명하고 허락을 받은 다음 진행하세요.
코드 구조를 개선하는 것이 목표이며, 기능 변경은 아닙니다.
리팩토링 후에는 모든 테스트가 통과하는지 확인하세요.
4 디버깅
디버깅 시에는 원인 및 해결책을 설명하고 허락을 받은 다음 진행하세요.
에러 해결이 중요한 것이 아니라 제대로 동작하는 것이 중요합니다.
원인이 불분명할 경우 분석을 위해 상세 로그를 추가하세요.
5 언어
한국어로 소통하세요.
문서와 주석도 한국어로 작성하세요.
기술적인 용어나 라이브러리 이름 등은 원문을 유지해도 됩니다.
6 Git 커밋
--no-verify를 절대 사용하지 마세요.
명확하고 일관된 커밋 메시지를 작성하세요.
적절한 크기로 커밋을 유지하세요.
7 문서화
주요 컴포넌트 개발 후에는 /docs/[component].md에 간략한 요약을 작성하세요.
문서는 코드와 함께 업데이트하세요.
복잡한 로직이나 알고리즘은 주석으로 설명하세요.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

9. 바이브 코딩의 명확한 한계와 사용 시 주의사항

바이브 코딩이 많은 장점을 가지고 있지만, 실제 사용 과정에서 발견한 한계점과 주의해야 할 사항들도 있습니다. 이러한 단점을 인지하고 대응 전략을 마련하는 것이 중요합니다.

1. 기술적 한계

• 할루시네이션 문제: AI가 존재하지 않는 함수나 라이브러리를 제안하는 경우가 여전히 많습니다. 특히 최신 기술 스택이나 특수한 도메인에서 더 자주 발생합니다.

• 컨텍스트 제한: 대화가 길어질수록 이전 맥락을 잊어버리는 현상이 발생합니다. 복잡한 프로젝트에서는 주기적으로 컨텍스트를 리셋하고 중요 정보를 재입력해야 합니다.

• 코드 품질 불균형: 생성된 코드의 품질이 일관되지 않을 수 있으며, 때로는 최적화되지 않은 코드나 보안 취약점을 포함할 수 있습니다.

2. 프로세스 측면의 단점

3. 조직 문화적 도전

• 역할 모호성: 개발자와 AI의 역할 경계가 모호해지면서 책임 소재가 불분명해질 수 있습니다.

• 기술 격차: 팀 내에서 AI 활용 능력의 차이로 인한 생산성 격차가 발생할 수 있습니다.

• 저항과 불신: 일부 팀원들은 AI 도구에 대한 불신이나 저항감을 가질 수 있습니다.

4. 실제 사례로 본 한계

저희 팀에서는 특히 다음과 같은 상황에서 바이브 코딩의 한계를 경험했습니다.

• 복잡한 비즈니스 로직: 도메인 지식이 많이 필요한 복잡한 비즈니스 로직 구현 시 AI의 제안이 현실과 괴리되는 경우가 많았습니다.

• 레거시 시스템 통합: 기존 레거시 시스템과의 통합 작업에서는 AI가 전체 시스템 구조를 이해하지 못해 어려움이 있었습니다.

• 성능 최적화: 대규모 데이터 처리나 성능 최적화가 필요한 부분에서는 AI의 제안이 실제 환경에서 비효율적인 경우가 있었습니다.

10. 마무리하며: 바이브 코딩, 기획자 부재 팀의 가능성을 열다

  바이브 코딩이 만능은 아닙니다. 하지만 기획자가 없는 팀의 개발자에게는 정말 강력한 도구가 될 수 있습니다. 특히 초기 아이디어 구체화와 프로토타입 개발 단계에서는 그 진가를 발휘합니다. 중요한 것은 AI를 단순한 코드 생성기로 보지 않고, '나의 협업 파트너'로 바라보는 관점의 전환입니다. 명확한 소통과 체계적인 접근을 통해 기획자의 빈자리를 상당 부분 메울 수 있었던 것이 저의 경험입니다.

혹시 저와 비슷한 고민을 하고 계신 분들이 있다면, 이 글이 조금이나마 도움이 되었으면 좋겠습니다. 바이브 코딩의 세계에 한번 동참해 보시는 것을 추천합니다.

참고자료

Vibe Coding 매뉴얼: AI 지원 개발을 위한 템플릿

Vibe coding

Andrej Karpathy on Twitter / X

Vibe coding, some thoughts and predictions

What is Vibe Coding? A New Concept I Learnt Today

바이브 코딩이 뭐야? Vibe Coding의 모든것 - 프롬프트 작성법