[바이브 코딩] #2: AI와 협업하기 위한 우리만의 법칙

들어가며

---

안녕하세요, 개발자 Stark입니다!

지난 편에서 예고했듯이, 오늘은 본격적인 바이브 코딩에 앞서 저희가 세운 전략과 전술, 그리고 Key Point를 공유하려고 합니다. 솔직히 말씀드리면, 강화도 숙소에 도착했을 때 저희는 약간 막막했습니다. "AI에게 모든 걸 맡긴다"는 거창한 목표는 세웠지만, 정확히 어떻게 해야 할지는 모르는 상태였거든요.

 

그래서 첫날, 숙소에 도착하자마자 저희는 소파에 나란히 앉아서 진지한 작전 회의를 시작했습니다. "어떻게 하면 AI가 알아서 일하게 만들 수 있을까?" "우리가 자는 동안에도 개발이 진행되려면?" "AI끼리 협업하게 하는 방법은?" 이런 질문들을 던지며 1시간 내내 토론했습니다. 그 결과 나온 것이 저희만의 전략과 전술이었습니다. 완벽하진 않지만, 적어도 2박 3일 동안 AI와 함께 뭔가를 만들어내기에는 충분한 계획이었습니다.

 

이번 포스팅 한 줄 요약

• AI를 '도구'가 아닌 '24시간 일하는 동료'로 만들기 위한 Monkeys팀의 작전 계획 소개
  
  

바이브 코딩 시리즈 정리

#1: AI와 2박 3일 - Monkeys 프로젝트의 시작

#2: AI와 협업하기 위한 우리만의 법칙 (현)

#3: AI 도구 선택과 12단계 계획

#4: 실전 Day1 - 아이디어부터 화면까지 

#5: 실전 Day2-3 - 백엔드 완성 그리고 배포

#6: Monkeys 프로젝트 최종 보고

 

 

전략

---

강화도 숙소에 도착하자마자 저희는 노트북을 펼쳤습니다. 2박 3일이라는 짧은 시간, 효율적인 전략 없이는 불가능하다는 것을 알았기 때문입니다.

 

저희가 세운 첫 번째 전략은 "모든 작업에 AI를 활용한다"였습니다. 이게 단순해 보이지만 실은 꽤 극단적인 원칙이었습니다. 아이디어 도출부터 기획, 디자인, 개발, 테스트, 배포, 심지어 커밋 메시지 작성까지 정말 '모든' 작업을 AI에게 맡기기로 한 것입니다. 여기서 인간의 역할은 오직 프롬프트 입력과 결과 확인, 그리고 의사결정뿐이었습니다.

 

예를 들어, 일반적으로는 개발자가 직접 프로젝트 내부 폴더 구조를 만들고 초기 세팅을 하는데 저희는 이것조차 AI에게 맡겼습니다. "Kotlin을 사용하는 SpringBoot 프로젝트를 생성하고 헥사고날 아키텍처로 구성해 줘"라고 요청하는 식으로요. 심지어 .gitignore 파일이나 application.yml같은 환경변수 설정도 모두 AI가 처리하도록 했습니다.

 

두 번째 전략은 "사람이 쉬더라도 AI는 쉬지 않아야 한다"는 것이었습니다. 이것은, 저희가 밥을 먹거나 잠을 자는 동안에도 AI가 계속 작업을 진행할 수 있어야 한다는 의미입니다. 일반적인 개발에서는 개발자가 자리를 비우면 작업이 멈춥니다. 하지만 AI는 토큰 한도가 남아있는한 무한으로 일할 수 있습니다. 그래서 저희는 스스로 프롬프트를 생성해서 자신에게 질문하고 알아서 작업하는 시스템을 만들기로 했습니다. 예를 들어 "지금 xxx 아이디어로 개발하고 잘 동작하는지 최종 검증해줘"라고 작업을 던져두기만 하면, AI가 밤새 알아서 계획을 세우고 하나씩 처리하는 방식을 말합니다.

 

또한 '병렬 처리' 전략도 추가했습니다. Claude Code로 백엔드, 프론트엔드를 개발하는 동안, 다른 창에서는 Gemini CLI가 테스트 코드를 작성하고 README 문서를 작성하는 식으로 여러 AI Agent를 동시에 가동하기로 했습니다. 마치 여러 명의 개발자가 동시에 작업하는 것처럼요. (특히 기대했던 것은 MD파일로 기획자, 디자이너, 개발자를 모두 만들어서 동시에 알아서 작업하도록 해보고 싶었습니다.)

 

마지막으로 '실패 허용' 전략도 중요했습니다. 처음에는 큰 꿈을 가지고 서비스 1개씩은 만들고 MCP 서비스를 하나 만들어보자고 얘기했지만 잘 생각해 보니 2박 3일이라는 짧은 시간 안에 이런 결과물을 만들겠다는 것은 욕심이라고 생각했습니다. 그래서 "작동하는 MVP"를 하나라도 만드는 것을 목표로 삼았습니다. 코드가 좀 지저분해도, 디자인이 좀 투박해도, 일단 돌아가기만 하면 성공이라고 정의했습니다. 완벽주의를 버리고 작업을 시작하니 마음이 한결 가벼워졌습니다.

전술

---

전략이 정해지자 구체적인 전술을 짜기 시작했습니다.

 

먼저 AI 도구 선정부터 시작했습니다. 시중에 나와 있는 수많은 AI 중에서 어떤 것을 선택할지가 이번 프로젝트의 성패를 좌우할 수 있기 때문이었습니다. 코딩에는 Claude Code와 Gemini CLI를 테스트하기로 했고, 디자인에는 피그마의 Make를 후보로 뒀습니다. 특히 기대를 걸었던 것은 Claude Code라는 개발 에이전트였는데, 터미널에서 직접 코드를 작성하고 실행까지 할 수 있다는 점이 매력적이었습니다.

 

두 번째로 비즈니스 도메인 선정을 AI에게 맡기기로 했습니다. "2박 3일 안에 만들 수 있으면서도 실제로 사용 가능한 서비스 아이디어 10개를 제안해줘"라고 요청하고, AI가 제안한 아이디어들을 사람이 직접 평가해서 최종 선택하는 방식입니다. 이 과정도 AI가 주도하게 하려고 아이디어 전문가 페르소나를 입혀주고 요청을 진행하기로 했습니다.

 

세 번째는 문서 작성의 자동화였습니다. 개발하면서 문서 작성하는 게 얼마나 귀찮은 일인지 개발자라면 다 아실 겁니다. 그래서 AI가 코드를 작성할 때마다 자동으로 README를 업데이트하고, API 문서를 생성하고, 심지어 사용자 매뉴얼까지 작성하도록 설정했습니다. 또한 소스코드의 관리 또한 문서화의 일종이라고 보는데 Claude Code가 코드를 수정할 때마다 자동으로 의미 있는 커밋 메시지를 작성하고, 브랜치를 생성하고, PR까지 올리도록 설정했습니다. 완전 자동화된 개발 프로세스를 만들고 싶었습니다. (리뷰 개념은 코드래빗과 Claude Code의 상호작용을 고려해 봤습니다)

 

네 번째는 개발 프로세스 설계였습니다. 저희는 모든 작업을 AI가 주도하도록 방향성을 잡았습니다. 먼저 피그마 Make AI로 디자인을 생성하고, 그 디자인을 분석해서 필요한 기능 목록을 추출합니다. 그다음 추출된 기능을 기반으로 데이터베이스 스키마와 API 명세를 설계하고, 최종적으로 프론트엔드와 백엔드 코드를 생성하는 방식입니다.

 

다섯 번째로 AI 페르소나 전략을 세웠습니다. 단순히 "코드 짜줘"라고 하는 것보다 "너는 구글에서 10년간 일한 시니어 백엔드 개발자야. 확장 가능하고 유지보수가 쉬운 코드를 작성해 줘"라고 역할을 부여하면 결과물의 품질이 확연히 달라집니다. 저희는 프로젝트 매니저, UX 디자이너, 백엔드 개발자, 프론트엔드 개발자, QA 엔지니어, DevOps 엔지니어 등 각 역할별 페르소나를 정의해서 질문하기로 했습니다.

 

여섯 번째는 QA 자동화였습니다. AI(Claude Code)가 코드를 작성하면 다른 AI(Gemini CLI)가 그 코드를 리뷰하고, 테스트 코드를 작성하고, 실제로 테스트를 실행해서 결과를 검증하는 파이프라인을 구축해보고 싶었습니다. 특히 인간의 개입 없이 AI끼리만 돌아가는 시스템을 만든다면 엄청날 것 같다는 생각을 했습니다.

 

일곱 번째는 프롬프트 최적화 전략이었습니다. 처음부터 완벽한 프롬프트를 작성하기는 불가능합니다. 그래서 AI의 응답을 보고 계속해서 프롬프트를 수정하고 개선하는 접근방식을 택했습니다. 특히 잘 작동한 프롬프트가 있다면 바로 공유해서 서로 적용하기로 했습니다.

 

여덟 번째는 아키텍처 사전 정의였습니다. AI는 맥락을 이해하는 데 한계가 있기 때문에, 프로젝트의 전체적인 아키텍처와 폴더 구조, 네이밍 컨벤션, 코딩 스타일 가이드 등을 미리 상세하게 정의해서 입력하기로 했습니다. 마침 Claude Code는 CLAUDE.MD라는 파일에 이것들을 작성해 두면 알아서 읽고 적용해 주기 때문에 너무 편했습니다. 예를 들어 "이 프로젝트는 SpringBoot3.x.x를 사용하고, Kotlin을 주언어로 사용하며, 헥사고날 아키텍처로 설계하고, PostgreSQL을 데이터베이스로 사용해"처럼 구체적으로 적어주기로 했습니다. 그리고 지속적으로 업데이트해서 서로의 Sync를 맞추기로 했습니다.

 

마지막으로 인간을 위한 준비도 빼놓을 수 없었습니다. AI가 작업하는 동안 저희도 뭔가를 하긴 해야 했습니다. 그래서 넷플릭스와 유튜브 프리미엄을 준비했고, 에너지 드링크와 라면, 과자를 산더미처럼 쌓아뒀습니다. 그리고 밤샘 작업을 대비해 수면 패턴을 미리 조정하고, 근처  산책 루트도 파악해 뒀습니다. (결과적으로 이 준비가 가장 유용했습니다...)

Key Point

---

본격적인 작업에 앞서 저희는 몇 가지 핵심 질문들에 대해 깊이 논의했습니다.

 

첫 번째는 "프롬프트 입력 퀄리티를 어떻게 높일 것인가?"였습니다. AI의 답변 품질은 저희가 어떻게 질문하는지에 달려있었기 때문입니다. 저희가 내린 결론은 프롬프트는 추상적이지 않아야 하고 최대한 명확해야 하며 원하는 작업을 순차적으로 입력해야 한다는 것입니다. 예를 들어 "로그인 기능 만들어줘"가 아니라 "1. 이메일과 비밀번호를 입력받아 2. JWT 토큰을 발급하는 REST API를 만들어줘"처럼 구체적으로 순서를 적어서 요청하는 것입니다.

 

또한 프론트엔드와 백엔드 코드를 Claude Code(AI Agent)가 따로 학습하지 않고 동시에 참조해서 서로 간의 연동이 가능하도록 설계했습니다. 이렇게 구성해야만 소스코드 전체의 맥락을 이해해서 더 일관성 있는 코드가 개발될 것이기 때문입니다.

 

두 번째 고민은 "업무 히스토리를 어떻게 남길 것인가?"였습니다. 바이브 코딩은 AI가 엄청난 속도로 개발을 진행합니다. 잠깐 한눈파는 사이에도 수많은 코드가 생성되기 때문에 흐름을 놓치게 되면 그 순간부터는 정확한 히스토리를 남기는 것이 어렵더군요.. 만약 AI가 개발한 코드를 체계적으로 기록해두지 않으면 나중에는 한 뭉텅이의 큰 히스토리만 남고 어떤 시점에 어떤 것이 개발되었는지는 확인할 수 없을지도 모릅니다. 이것을 방지하기 위해 AI Agent가 매 작업을 끝낼 때마다 스스로 히스토리를 업데이트하도록 구성했습니다.

 

세 번째는 다소 철학적인 질문이었습니다. "바이브 코딩은 정말 아무나 할 수 있을까?" 저희의 결론은 '아주 간단한 프로젝트는 누구나 할 수 있지만 enterprise급의 시스템을 개발하기 위해서는 기초 지식은 필요할 것이다'였습니다. 네트워크 동작 원리나 프레임워크의 구조 그리고 데이터베이스 개념 정도는 알아야 AI에게 올바른 명령을 내릴 수 있을 것 같았습니다. 물론 아주 간단한 프로토타입을 개발하는 것이라면 개발 지식 없이도 가능할 수 있습니다.

 

네 번째 고민은 "하나의 소스코드 위에서 여러 사람이 AI 에이전트로 협업할 수 있을까?"였습니다. 솔직히 이 부분이 가능하다면 실무에서 엄청나게 유용하게 사용될 것이라고 생각했지만 아직은 무리라는 생각이 들었습니다. AI 활용 개발 규칙을 잘 정한다면 가능할지도 모르지만 그렇다 하더라도 AI가 여러 소스코드를 동시에 수정할 것이기 때문에 작업자들 간의 충돌이 발생할 가능성이 매우 높을 것이라고 봤습니다.

 

마지막으로 "개발 중 발생하는 오류를 어떻게 최소화할 것인가?"에 대해서도 논의했습니다. 저희는 두 가지 접근법을 시도해 보기로 했습니다. 저(stark)는 매 프롬프트 요청마다 작업한 내용을 최종 검증하도록 해서 안정성을 높이는 방식을, eddy님은 검증 없이 빠르게 진행하되 나중에 한 번에 디버깅하는 방식을 택했습니다.

 

 

마무리하며

---

이렇게 저희의 프로젝트 전략과 전술 그리고 Key Point까지 모두 설명드렸습니다.

 

솔직히 말씀드리면, 도착해서 계획을 세우고 프로젝트 초기 세팅을 하는데만 첫날 오후가 다 갔습니다. "무계획이 계획"이라며 시작했는데, 결국 노트 2장 분량의 작전 계획서를 만들고 있었습니다. 아이러니하게도 AI에게 모든 걸 맡기기 위해서는 인간이 더 치밀하게 사전준비를 해야 한다는 것을 깨달았습니다.

 

eddy님과 저는 작업 중간마다 노트북 화면을 보며 서로를 격려했습니다. "우리가 정말 2박 3일 만에 뭔가를 만들 수 있을까?" "AI가 정말 우리 대신 밤새 일해줄까?" 반신반의하면서도, 동시에 묘한 기대감이 있었습니다. 마치 처음 프로그래밍을 배우면서 내가 뭔가를 만들 수 있을지 기대하던 감정과 비슷했던 것 같습니다.

 

무엇보다 재미있었던 건, 저희가 단순 '개발자'가 아닌 'AI를 지휘하는 개발자'가 되어간다는 느낌을 받았습니다. 코드를 직접 짜는 대신 AI에게 어떻게 지시할지 고민하고, 디버깅하는 대신 프롬프트를 최적화하는 방법을 연구하고... 이게 정말 미래의 개발 방식일 수도 있겠다는 생각이 들었습니다.

 

다음 편은 드디어 실전입니다. 저희가 어떤 도구를 선택했고 개발 프로세스를 어떻게 설계했는지 생생하게 전해드리겠습니다. 기대된다면 다음 편도 읽어봐 주세요!

To be continued...

 

2025.08.23 - [AI] - [바이브 코딩] #3: AI 도구 선택과 12단계 계획

[바이브 코딩] #3: AI 도구 선택과 12단계 계획