그리고 그 순간, '이렇다면 프로그래밍 지식이 없는 PM이나 디자이너도 '바이브 코딩'을 이용해 충분히 코딩할 수 있겠다'는 '불씨'를 발견하게 된 것입니다. 저희는 이 불씨를 키우기 위해, 앞에서 다른 발표자분들이 소개해 주신 MCP 도입을 비롯한 다양한 실험들을 거쳐 저희만의 바이브 코딩 환경을 갖췄습니다.

먼저 저희가 세팅한 환경을 영상으로 한번 보시겠습니다. 이 영상도 벌써 3개월 전에 찍어둔 영상이네요.

영상에 보이듯이, 먼저 채팅으로 요구사항을 작성합니다. 이 요구사항도 사실 직접 작성한 것은 아닙니다. 저희가 회의를 할 때마다 매번 녹음을 하는데, 그 회의록을 바탕으로 AI가 신규 기능의 요구사항을 생성해서 제안하는 것입니다.

먼저 Cursor 에이전트가 어떻게 디자인할지에 대해서 제안을 하면, 저희는 일종의 내부 FGI를 진행합니다. 저희 개발자, 디자이너, 사업팀장이 '이게 충분히 괜찮은가'에 대해서 피드백을 직접 돌리고 있는 거고요.

이를 통해 이 기획이 괜찮다고 판단되어 "그대로 이제 개발해줘"라고 명령을 내리면, 영상에서 보듯, 왼쪽 리더보드에서 1등, 2등, 3등이 강조되는 효과가 바로 적용되는 것을 확인할 수 있습니다.

저희는 이런 방식으로 지난 2~3개월간 정말 행복하게 개발을 진행했습니다. '누구나 코딩할 수 있다!'는 가능성을 본 시간이었습니다.

'바이브 코딩' 환경의 전제 조건

이런 환경을 만들기 위해서는 아래 세 가지 환경이 필요합니다.

1. 모든 정보를 리포지토리에 기록

먼저 모든 정보가 리포지토리 안에 있어야 합니다. 단순히 코드뿐만 아니라, 이 프로젝트에 대한 모든 설명이 노션이나 피그마 같은 외부에 흩어져 있는 것이 아니라, 리포지토리 내에 존재해서 Claude Code가 바로 그 안에서 정보를 찾아볼 수 있어야 합니다.

2. 언제든 질문에 답할 수 있는 시스템

이렇게 되면 기획자나 다른 작업자가 '현재 어떻게 구현되어 있는지'를 알기 위해 개발자를 찾아갈 필요가 없어집니다. 그냥 커서나 클로드코드에게 질문하면 지금의 구현 상태를 바로 이해할 수 있게 되죠.

그 덕분에 ‘현재 상태 파악 → 새로운 기획 → 기획 문서 작성 → 실제 수행'에 이르는 이 모든 과정을 이제는 누구나 할 수 있게 되었습니다.

3. 빠른 수정과 배포 환경

물론 이를 위해서는 Vercel이나 GitHub처럼(GitHub은 당연히 기본이겠죠), 코드를 빠르게 수정하고 업로드하면 즉시 배포가 이루어지는 환경을 갖춰야 합니다. 저희는 Slack-Cursor integration 도 적용해 두어서, 이렇게 슬랙에 메시지를 올리는 것만으로도 바로 Dev 서버에 반영되도록 구축해 놓았습니다.

이 환경이 구축되고 나니, 출퇴근길에도 피드백을 바로바로 수정 할 수 있게 되었습니다.

프로젝트가 커지자 문제가 생기다

하지만, 이렇게 '누구나 코딩하는' 행복한 개발을 이어가던 중, 예상치 못한 문제들이 생기기 시작했습니다. 바로 '실력의 양극화'가 심해지는 것이었습니다.

프로젝트가 작을 때는 AI(커서, 클로드)의 컨텍스트 윈도우만으로도 프로젝트의 모든 내용을 이해할 수 있었습니다. 하지만 프로젝트가 일정 규모 이상으로 커지자, 할루시네이션(환각)이 발생하기 시작했습니다. 코드에 대해 설명을 요청해도 자꾸 거짓말을 하더군요.

더 큰 문제는, 디자이너나 기획자분들은 AI가 코드를 생성하는 '중간 과정'을 알 수 없다 보니, 의도를 알 수 없는 이상한 코드들이 자꾸 만들어지는 것이었습니다. 결국 제가 매번 리뷰를 하면서 물어봐야 했습니다.

"여기 이 인풋박스는 왜 생겼나요?"
"이 버튼은 특별한 의도가 있으신 건가요, 아니면 클로드가 알아서 만든 건가요?"

게다가 분명히 기존 API로 충분히 구현 가능한 기능임에도, (그 사실을 모르는) 기획자나 디자이너가 AI에게 "이거 해줘"라고 요청하면, AI가 똑같은 기능을 하는 API를 새로 만들어 중복으로 탑재하는 일이 빈번했습니다. 당연히 이 코드는 비개발자분들이 리뷰 과정에서 걸러낼 수 없었습니다.

심지어 DB에 존재하지도 않는 정보를 억지로 화면에 보여달라고 요청하니, AI가 어떻게든 그 요청을 수행하려고 발버둥 치면서, 말 그대로 '괴물 같은' 코드와 컴포넌트들이 탄생하고 있었습니다.

근본 원인: 컨텍스트 과부하와 의도 상실

'이대로는 안 되겠다'고 생각했습니다. '애초에 이런 접근이 왜 발생했을까?' 그 원인을 파고들어 보니, 근본적인 문제는 '컨텍스트 과부하'였습니다.

이렇게 컨텍스트가 계속 폭발하고 비효율적으로 사용되자, AI는 환각을 일으키고 결과물의 '의도'가 사라지는 현상이 나타났습니다. 프로젝트가 커지고 코드가 많아질수록 '누가 이 코드를 만들었는지', '클로드가 만든 건지, 작업자가 만든 건지', '도대체 무슨 의도로 만든 건지'가 점점 흐려지는 상황에 이른 것입니다.

저희는 무슨 문제가 터질 때마다 Claude.md (저희의 룰 파일)에 규칙을 추가했습니다. 그러다 보니 어느새 Claude.md 파일이 2,000줄을 넘어간 겁니다.

결국 AI 세션을 켜자마자, 채팅을 시작하기도 전에 이미 컨텍스트의 30%가 이 룰 파일로 채워져 있는 현상이 발생했습니다. '일단 룰부터 줄여야 한다'는 결론이 섰습니다.

또 다른 문제는 '비효율적인 반복 학습'이었습니다.

저희는 MCP를 연결해 두었는데요. AI는 작업을 할 때마다 매번 최신 공식 문서를 가져오려고 했습니다. 하지만 사람은 그렇게 일하지 않습니다. 실제 사람은 매번 최신 문서를 통째로 열어보지 않습니다. 이 프로젝트에서 자주 쓰는 기능에 대한 가이드 문서를 콤팩트하게 작성해 두면 충분합니다.

해결책은 '맥도날드'에 있었습니다

그래서 '어떻게 이 문제를 해결할 수 있을까?', '단순히 Claude.md를 잘 쪼개서 쓰면 되는 걸까?' 고민이 깊어졌습니다. 어떻게 하면 이 방식을 큰 프로젝트에도 적용할 수 있을까요?

제가 내린 결론은, 'AI에게 무작정 많은 컨텍스트를 주는 것' 자체가 문제라는 것이었습니다. AI는 컨텍스트를 많이 안다고 해서 더 똑똑하게 일하지 않았습니다.

또한, '의도'가 기록되어야 했습니다. 코드만 리포지토리에 남기면 '왜 이 코드를 작성했는지'에 대한 지식은 전혀 남지 않습니다. 채팅창의 기록도 그 창을 끄면 날아가 버리니 소용없었죠.

결국, 지금까지의 '바이브 코딩' 방식은 확장성이 현저히 부족했습니다. 2~3명 규모의 소규모 팀은 서로 자주 이야기하고 물어볼 수 있으니 컨텍스트가 자연스럽게 공유됩니다. 하지만 저희는 '팀'으로 일해야 하고, 팀으로 일하기 위해서는 모든 컨텍스트가 확실하게 공유되어야 하는데, 지금 방식은 그에 미치지 못했습니다.

'세상은 이런 확장성 문제를 어떻게 해결하고 있을까? 적어도 우리는 평소에 이렇게 일하지 않는데.'

그렇게 고민하다 맥도날드를 떠올렸습니다.

맥도날드에서 일하는 분들은 전문 셰프가 아닙니다. 하지만 전문 셰프가 아니어도, 전국 어디서나 훌륭하고 맛있는 햄버거가 나옵니다. '이 맥도날드 같은 프랜차이즈 방식을 우리가 차용할 수 없을까?'라는 생각을 하게 됐습니다.

맥도날드처럼 일할 수 있다면, 규모를 확장할 수 있습니다. 햄버거 만들 줄 몰라도 프랜차이즈를 차릴 수 있고, 햄버거를 만들 수 있으니까요.

이 방식을 저희 팀에 적용해 보았습니다.

테크리드인 제가 '매뉴얼'을 제공하고,
'바이브 코더'인 PM, 디자이너분들이 '지점장'이 되어 각각의 클라이언트(업무)를 관리합니다.
그리고 실제 일은 커서와 클로드 같은 '알바(AI 에이전트)'가 수행하는 구조입니다.

맥도날드 알바의 업무 원칙 - 새로운 에이전트 운영 원칙

그래서 저희는 '새로운 방식으로 에이전트를 동작시키자'는 결론을 내리고, 몇 가지 원칙을 세웠습니다.

첫째, 에이전트가 켜지면 200줄 내외의 핵심 가이드만 읽고 바로 일을 시작해야 합니다. 만약 가이드가 200줄을 넘어가면, 그 가이드는 반드시 쪼개져야 합니다.

둘째, 문제가 생기거나 추가 정보가 필요할 때를 대비해, 가이드마다 어펜딕스(Appendix)를 달았습니다. "이게 부족하면 다른 문서를 참조해라", "전문을 보려면 최신 정보는 이 URL에 있다"는 식으로요. 이렇게 하니, 웬만한 업무는 그 200줄의 초기 가이드만으로도 충분히 시작할 수 있었습니다.

셋째, (그리고 어쩌면 이게 가장 중요할 수 있는데) 하나의 업무가 끝나면 컨텍스트를 즉시 잊어버리게 했습니다.

저희는 '리포지토리에 남지 않는 정보는 휘발되어도 되는 정보다'라고 정의했습니다. 만약 어떤 정보가 리포지토리가 아닌 채팅창에만 남아있거나, 제가 매번 채팅으로 다시 설명해야 하거나, 옆사람이 와서 '그건 이런 히스토리가 있어서...'라고 부연 설명을 해야만 한다면, 저희는 그것을 '잘못된 업무'라고 정의했습니다.

지점장, 즉 바이브코더의 역할

그렇다면 '바이브 코더(사람)'는 무엇을 해야 할까요?

바로, '왜(Why)' 이 일을 하는지 항상 기록해야 합니다. '어떤 이유 때문에 이 피처를 개발했다'는 의도를 남겨야 합니다.

또한, '결정 과정'을 명확히 명시해야 합니다. (클로드 코드에게 물으면 보통 해결책 1, 2, 3번을 주곤 하죠.) 여러 해결책 중 왜 이 방식을 선택했는지, 그 장단점과 판단의 근거를 남겨야 합니다. 정답이 없는 상황에서 선택을 내리는 그 주관이 바로 '실력'입니다. 이 히스토리가 있어야만, 나중에 다른 사람이 봤을 때 '그냥 좋아 보여서 선택했는지' 혹은 '명확한 근거로 결정을 내렸는지' 추적할 수 있습니다.

이는 '우선순위의 기록'과도 연결됩니다.

AI에게 '무슨 기능을 개발해줘'라고 할 때, 단순히 기능 리스트만 나열해서는 안 됩니다. 반드시 지켜야 하는 Must-have, 하면 좋은 Should-have, 있어도 그만 없어도 그만인 Nice-to-have를 명확히 구분해야 합니다.

이렇게 스펙 문서를 쪼개서 제공해야만, AI가 '괴물'을 만들어내지 않고 'Must-have'를 지키면서 'Nice-to-have'까지 달성하도록 유도할 수 있습니다.

맥도날드 시스템의 개발 워크플로우

그렇다면 전체적인 워크플로우는 어떻게 될까요?

결국, '기획서 작성(PRD)'이 압도적으로 중요해집니다. 저희의 '프랜차이즈' 방식은 AI '알바'들이 '매뉴얼'을 보고 일하는 구조이기 때문에, '무엇을 개발할 것인가'에 대한 명확한 기획서가 반드시 있어야 합니다.

저희는 이 기획서를 AI에게 검토시킵니다. "현재 구현 상태가 이런데, 기존 기능을 재사용해도 되는지? 어디를 고쳐야 하는지? 혹은 새로 만들어야 하는지?" 등을 AI가 먼저 검토하게 합니다.

심지어 디자인에 대해서도, 저희는 AI를 통해 가상의 FGI(Focus Group Interview)를 진행시킵니다. "이 신규 개발안에 대해 디자이너, 사업팀장, 기획자가 모인다면 어떤 토론을 할 것 같은지" AI에게 시뮬레이션하도록 지시하는 거죠. 이 토론 내용을 바탕으로 스스로 피드백 하도록 시키면, 정말 괜찮은 기획서가 금방 '뚝딱' 나옵니다.

이렇게 기획서가 완성되고 나면, 그다음은 그냥 일을 시키기만 하면 됩니다. 우리는 이미 '환각이 없는 에이전트 알바 군단(잘 정비된 매뉴얼)'을 만들었고, '완벽한 기획서'를 작성했기 때문입니다. 기획서만 잘 쓰면, 뒷단은 정말 마법같이 잘 풀리는 경험을 할 수 있습니다.

프롬프트 폴더

간단한 예시를 들어보겠습니다.

'바이브 코딩'으로 일할 때를 생각해 보죠. 만약 '목록에서 조회수 보여주기' 기능이 필요하면, 대부분 채팅창에 "목록에서 조회수 보여줘"라고 바로 명령을 내립니다. 그러다 결과물을 보고 "음... 조회수가 좀 강조돼야겠네요. 빨간색으로 해줘"라고 합니다. 그러다 또 "너무 새빨갛네요. 좀 더 자연스럽게 해봐" 같은 식으로 하나하나 커맨드를 내리게 됩니다.

이런 방식은 한 페이지짜리 간단한 프로젝트에서는 통할지 모릅니다. 하지만 이 작업이 단순히 화면(View)뿐만 아니라 DB까지 건드려야 하는 큰 작업이라면, 절대 좋은 결과를 얻을 수 없습니다.

그래서 저희는 아까 말씀드린 피드백 루프에 따라 명확하게 PRD 문서를 작성한 뒤에야 일을 시킵니다.

(이 화면은) 저희가 실제 작업하는 프롬프트 폴더입니다.

보시는 것처럼, 저희는 하나의 기획 문서를 작성하기 위해 7단계를 거칩니다.

워크플로우 기반 컨텍스트 확보
요구사항(Requirement) 정의
UX 설계
의존성(Dependency) 분석
구현 계획(Plan) 작성
워크플로우 및 리스크 분석
테스트 작성

저희는 이 7단계를 거쳐 비로소 하나의 기획 문서를 완성시킵니다.

우리 팀의 워크플로우를 녹여내는 법

그런데 이렇게 문서를 작성하는 게 생각만큼 어렵지 않습니다. 저희는 '어차피 우리가 평소 회의할 때 이 과정들을 다 거치지 않나?'라는 지점에서 접근했습니다.

그래서 저희는 모든 회의에서 녹음기를 켜둡니다. 그리고 회의가 끝나면, "우리가 회의에서 이 결론을 도출한 과정을 스크립트로 작성해줘"라고 (AI에게) 요청합니다.

즉, 이것을 엄청나게 어렵게 '작성'해야 한다고 생각하실 필요가 없습니다. 결국 팀이든 개인이든, 자신에게 가장 익숙한 작업 워크플로우가 있기 마련입니다. 저희는 단지 그 워크플로우를 그대로 녹음하고, 그 녹음된 내용을 기반으로 (AI가 일할) 워크플로우를 만들 뿐입니다.

저희가 실제로 기획 문서를 작성한 방식을 예로 들어보겠습니다.

한번은 회의에서 "로그인 코드가 최근 잦은 리팩토링으로 너무 복잡해졌다. 이거 클린업하자"라는 얘기가 나왔습니다.

그럼 저희는 '로그인 및 회원가입 코드 클린업'이라고 제목만 정합니다.

그러면 AI가 녹취된 회의록을 기반으로 기획서 초안을 작성해 줍니다.

물론, 이 초안을 그대로 쓰진 않습니다. 사람이 그 문서를 검토하며 "이 부분은 사실과 좀 다르네", "이건 지금 당장 할 필요 없겠다" 같은 내용을 수정합니다. 그리고 가장 중요한, 이 작업의 '목표(Goal)'와 '비목표(Non-goal)'를 명확히 정의합니다.

그렇게 사람이 최종 검토한 기획서가 완성되면, 비로소 AI에게 일을 시키면 됩니다.

이후 AI는 필요한 가이드문서를 찾아 기획의도를 바탕으로 구체적인 작업을 수행합니다.

또한 모든 기획서(PRD)와 베타테스터들의 CS 데이터도 모두 가지고 있기에 추후 AI 스스로 기획서를 팔로업하고 해결책을 제시하는 것도 가능합니다.

결론: 익숙한 방식에 새로운 기술을 녹여내기

네, 이렇게 해서 저희가 구축한 '맥도날드 시스템'에 대해 간단히 설명을 드렸습니다.

제가 이 과정을 겪으면서 느낀 점은, 지금 세상에 완전히 새로운 기술이 등장했지만, 사실 이게 완벽하게 '새로운' 것만은 아니라는 점입니다.

어떻게 보면 우리가 하던 일의 일부를 AI가 대체하고 있는 것뿐입니다. 저희가 해야 할 일은, 이미 세상에서 '잘 동작하고 있는 성공 모델(저의 경우는 맥도날드)'을 찾아, 이 새로운 AI 시대에 맞게 잘 녹여내는 것이었습니다.

AI가 대체할 수 있는 부분은 과감히 녹여내고, 우리가 기존에 잘 동작시켰던 방식의 본질은 살리는 것. 그것이 핵심이었습니다.

Q&A

Q. 클로드 코드를 사용할 때, 화면을 보지 않고 있을 때도 있는데요. 그럴 때 작성을 안 하는 경우도 있던데, 이럴 때 해결 방법이 있으신가요?

Human in the loop 가 중요하기 때문에, 한쪽에 화면을 계속 켜두고 있습니다. 혹시 의도치 않은 행동을 한다면, 왜 그렇게 행동했는지 묻고, 다음부터 그렇게 하지 않으려면 어느 가이드를 고치면 되는지 묻고 고치게 합니다. git worktree 와 함께 사용해서 여러 창에서 동시에 작업하면 효율이 훨씬 좋습니다.

Q. 저는 1년 연간회원으로 클로드를 사용하는데요. 4.5로 업데이트 되면서 토큰 사용량이 금방 소진되더라고요. 이런 건 어떻게 해결을 하시는 편인가요?

이것도 컨텍스트 엔지니어링을 통해 많이 개선되었습니다. 토큰을 많이 사용한다는 건 그만큼 컨텍스트를 많이 처리하고 있다는 것입니다. 도메인별로 DB구조, API목록, 페이지 구성 등을 md 형태로 작성하여 쪼개서 가지고 있도록 하여, md 만 읽고 구조를 파악해서 불필요하게 grep 을 통해 다수의 파일을 읽는 일이 없도록 하였습니다. 기존에는 문서의 최신화가 늘 문제였지만, 지금은 일도 아닙니다.

추가로 팁을 드리자면, Agents.md 에 '문서를 늘 최신화 하라'라고만 넣어두거나 상세가이드를 넣어두면 클로드가 작업을 빼먹거나 불필요한 타이밍에 문서를 갱신합니다. 'PR을 할때 pr-guide.md 문서를 참조해라'라고 명시하고, pr-guide.md 에 체크리스트를 작성해두면 PR 타이밍에 항상 문서가 업데이트 됩니다.

Q. 비 개발자 분들도 바이브코딩에 참여하게 된 계기가 궁금합니다

개발자한테 설명할 시간에 커서한테 시키면 바로 작업이 끝나기 때문입니다. 실제로 이렇게 개발해서 2주는 걸리는 피쳐가 하루면 끝났습니다.