“코딩보다 문서가 중요했어요” – 바이브코딩 콘테스트 공동 3등 수상자 인터뷰

리트머스 바이브코딩 콘테스트 개최!

지난 2025년 11월 29일, 리트머스에서 첫 번째 바이브코딩 콘테스트를 개최했습니다.

100명의 참가 신청자가 모인 이번 대회는 오전 11시부터 저녁 7시까지, 단 8시간 동안 진행됐습니다. 참가자들은 대회 시작과 동시에 메일로 전달받은 PRD(제품 요구사항 문서)를 바탕으로 AI 코딩 도구를 활용해 하나의 완성된 웹 서비스를 만들어내는 도전에 나섰습니다.

온라인으로 진행된 대회는 기술 스택과 도구 선택이 완전히 자유로웠고, 결과물은 GitHub를 통해 제출받았습니다. 19시 이후의 커밋은 인정되지 않는, 말 그대로 시간과의 싸움이었죠.

평가 기준은 세 가지!

• 기능 완성도 — PRD의 상세 요구사항을 얼마나 버그 없이 구현했는가
• UI/UX 완성도 — 전체적인 디자인 퀄리티와 사용자 경험
• 문서화 — 프로젝트의 유지보수 용이성과 개발 문서

의도적으로 요구사항을 많이 넣어 변별력을 높였습니다. 모든 걸 완성하는 게 목표가 아니라, 제한된 시간 안에서 우선순위를 정하고 완성도 있는 결과물을 내는 것, 바로 바이브코딩의 본질을 시험하고 싶었습니다.

상금은 1등 100만 원, 2등 50만 원, 3등 25만 원(2명)으로 총 200만 원이 걸린 대회였습니다.

이번 인터뷰에서는 바이브코딩 콘테스트 공동 3등을 수상한 나호정 님을 만나 이야기를 나눴습니다. 교육 회사 IT 기획 본부에서 프로덕트 매니저로 일하며, 기획과 개발을 넘나드는 역할을 수행하고 있는 호정 님은 문서화와 AI 중심 워크플로우를 무기로 8시간 동안의 콘테스트에 도전했는데요. 비개발자 PM로서 바이브코딩을 어떻게 활용했는지, 그리고 AI가 개발 경험을 어떻게 확장시켰는지에 대한 생각을 이번 인터뷰를 통해 들어봤습니다.

기본 정보

Q. 간단한 자기 소개 부탁드립니다.

저는 현재 교육 회사 IT 기획 본부에서 프로덕트 매니저로 일하고 있습니다. 개발자 출신은 아니며, 현재 회사에서 운영하는 학원에서 근무 하다가 AI를 활용한 개발 능력을 감사하게도 인정받아 본사로 오게 된 케이스 입니다.

기존의 개발 지식은 대학 때 파이썬으로 그래프 출력을 배운 정도였습니다. 지금은 웹페이지를 만들거나, 간단한 앱을 빌드하여 배포하는 것 까지 가능한 수준입니다. 사내에선 기획자 포지션이지만 간단한 형태의 개발까지 직접 수행하고 있습니다. 현재는 랜딩페이지나, 기본적인 CRUD 동작을 제공하는 페이지, 간단한 모바일 앱을 빌드하고 출시할 수 있을 정도의 개발 지식을 갖고 있습니다. 이러한 기획부터 개발까지의 확장된 개념의 풀스택 경험을 7개월 가량 진행하고 있습니다.

Q. 이번 콘테스트에 참여하게 된 계기는 무엇인가요?

평소 'AI 공모전' 같은 키워드로 검색하며 관련 정보를 찾아보는 편인데, 그 과정에서 이번 콘테스트를 알게 되었습니다.

Q. 바이브코딩 경험은 어느 정도였나요?

바이브코딩 경험은 2년 정도 됩니다. 바이브코딩이란 용어가 없던 GPT 3.5부터 시작했으니 바이브코딩 경험 자체는 많으나, 체계적으로 바이브'코딩'을 배운지는 8개월이 채 되지 않네요.

AI가 처음 나왔을 때 VBA 엑셀 자동화 툴을 만들면서 처음으로 바이브코딩을 시작했습니다. GPT 3.5와 VS Code를 활용해 하나하나 코드를 복붙하며 사이트를 만들기 시작하면서부터, 본격적으로 바이브코딩 경험을 쌓게 되었습니다. 이후 커서(Cursor) 같은 툴이 나오면서 랜딩페이지부터 다양한 기능을 제공하는 웹사이트를 직접 개발하게 되었습니다.

업무 과정에서 빠르게 개발 역량을 높여야 했기 때문에, 회사 차원의 프로그래밍 교육, 다양한 AI툴의 지원으로 여러 최신 툴을 익히고 배우며 부족한 실력을 키워가고 있습니다.

기획 및 전략

Q. 서비스 컨셉에 대해서 간단히 설명해주세요.

기능적으로 차별점을 두기 보단, 개발 워크플로우에 대해서 차별점을 두었습니다. 비개발자 출신이면서 기획자로서의 경력도 길지 않다 보니 이미 많은 기업들에 의해 검증된 정형화된 워크플로우를 적용하고 싶었습니다. 그래서 BMAD-Method 방식으로 진행하였습니다.

BMAD-Method 방식은 애자일 방법론의 하나로, 저만의 가장 작은 팀을 구성하는 것입니다. 일종의 프롬프트 모음집이라고 생각해주시면 됩니다. 프로덕트 매니저, 개발자, 아키텍처, 리서처, 테스터 등 각 AI에이전트를 하나씩 불러 역할에 맞춰 작업의 과정을 세분화하는 방식입니다. 큰 기업에서 제품 출시를 위해 각 직원들이 수행하던 업무 방식을 개인 혼자서도 구현할 수 있게 해주는 워크플로우입니다.

또한, 요구되는 기능이 많은 반면 시간 제약이 있어 순차적으로 하나하나 개발하기엔 시간이 부족할 것 같아, 터미널을 여러개 실행하여 병렬적으로 개발하는 방식으로 진행하였습니다. Epic 단위로 큰 방향성을 잡고 공통적으로 세팅이 필요한 부분을 먼저 개발, 이후의 Epic은 병렬로 개발하고 마지막에 하나로 통합하는 방식으로 하여 시간 단축을 중점으로 개발을 진행하였습니다.

리트머스 주석
BMAD-Method는 'Breakthrough Method for Agile AI-Driven Development'의 약자로, 소프트웨어 개발의 모든 단계에 AI 기술을 에이전트 기능으로 밀접하게 결합하여 개발 생산성을 극대화하는 차세대 애자일 방법론입니다. 기획과 설계부터 구현 및 테스트에 이르는 전체 개발 사이클을 AI 중심으로 재편함으로써 프로세스 전반의 속도를 비약적으로 높이고 결과물의 품질을 안정화하며, 개발자가 단순 반복적인 작업에서 벗어나 보다 핵심적인 아키텍처 설계와 창의적인 아이디어 구현에 집중할 수 있는 환경을 구축하는 것을 지향합니다.

Q. 8시간이라는 제한된 시간 안에서 어떤 흐름/단계로 진행하셨나요?

바로 개발을 시작하는 것 보단 방향성을 확실히 하기 위해 문서를 제대로 완성하는 것이 기본 준비라고 생각하여, 개발을 본격적으로 시작하기 전 약 2시간 동안은 문서 작업에 집중했습니다. 요구사항을 정리하고, 각 요구사항을 어떻게 만들어야 하는지, 각 과정을 병렬적으로 처리하기 위해 어떻게 분류하고 순서를 정할 지, 적용되는 기술 스팩도 정리하고, 어떤 기능은 추가하지 않아도 되고 어떤 기능은 필수적으로 먼저 구현해야 할지 등을 우선적으로 정리했습니다. Claude Code에서 BMAD-Method 방식에 따라 PRD부터 Epic을 거쳐 스토리로 나눠서 작업하고, 각 스토리 개발이 완료되고 나면 어떤 개발이 이루어졌는지 다시 스토리 문서를 업데이트 하여 기록하며 진행하였습니다.

문서 작업 이후로는 쭉 개발을 진행했고, 마지막 한 시간은 배포와 테스트에 사용했습니다.

Q. 개발 작업에 있어서 시간 배분과 우선순위는 어떻게 정하셨나요?

가장 높은 우선순위는 역시 문서 작업이었습니다.

다시 하게 된다면, 문서를 꼼꼼하게 세팅하는 것도 좋지만 YOLO 모드로 빠르게 한번에 생성해도 괜찮겠다는 생각이 들었습니다. 생각보다 시간이 지체되어, 문서 작업 후반부에 YOLO 방식으로 한번에 생성하였는데 하나하나 꼼꼼히 진행 한 것과 한번에 빠르게 생성한 문서들의 퀄리티 차이가 크게 나지 않았습니다. Claude Opus 4.5의 발전된 성능을 여실히 체감 할 수 있었던 순간이었습니다.

제가 놓여있는 실무 환경에서는 시간 압박보다 퀄리티가 더 중시 됩니다. 따라서, 평소엔 시간이 제약 조건으로 작용되지 않는 환경에서 작업하는 편인데, 이번 콘테스트를 통해 시간을 효율적으로 단축하는 방법을 많이 배웠습니다. 이후 실제 업무에서도 기능별 구현 난이도에 따라 꼼꼼히 살펴보며 생성이 필요한 문서와 한번에 빠르게 생성이 가능한 문서를 구분해가며 진행하여, 보다 효율적인 업무를 할 수 있게 되었습니다.

AI 기능 구현

Q. 어떤 기능을 위해 어떤 AI 툴을 활용하셨나요? 그리고 그 이유는 무엇인가요?

개발도구로는 Claude Code, Antigravity, Gemini를 활용했고, 백엔드로는 Firebase의 app hosting 기능과 DB는 Supabase를 사용했습니다.

Q. 한 작업당 개발 과정에서 AI 재지시는 총 몇 회 정도 이루어졌나요?

크게는 5번 정도 진행하였습니다. 평소에도 프롬프트를 여러번 입력하지 않고 한번에 원하는 결과를 낼 수 있도록 단일 프롬프트로 압축하는 연습을 많이 합니다. 그 중에서도 컨텍스트 엔지니어링 기법으로 개발하는 것을 선호합니다. 결과에 대해서 수정이 필요한 순간에, AI에게 바로 수정 사항을 요청하는 것이 아닌, 개발의 토대가 된 스토리문서를 먼저 수정한 다음 해당 문서대로 개발을 다시 지시하는 방식으로 수정을 진행하였습니다. 이 방법을 통해 AI가 수정할 범위를 정확히 지정하여 다른 코드에 줄 수 있는 영향을 최소화하고, 이전에 실패했던 방법을 다시 시도하지 않도록 방지할 수 있었습니다. 만약 클로드 코드만으로 문제가 해결되지 않는다면 Antigravity에서 Gemini를 소환하여 다른 LLM의 시각에서도 해결을 시도하였습니다. 기존의 계획에서 토큰 관리 방법을 교체하는 과정이 있었고, 이후에 제대로 작동하지 않은 기능들이 있어 해당 과정에서 5번 정도 수정했습니다.

Q. 가장 많이 사용한 프롬프트 패턴은 무엇이었나요?

BMAD-Method 워크플로우를 기반으로 한 프롬프트 패턴을 많이 사용했습니다.

기본적인 PRD나 구조에 대한 문서를 만들어 놓고, 각 기능별로 개발에 필요한 스토리 문서를 생성 후 스토리를 문서를 기반으로 개발. 이후에 해당 개발이 잘 이루어졌는지 리뷰하는 방식입니다. 리뷰 과정에서도 Chrome Devtools MCP로 개발 한 내용을 웹에서 직접 AI가 직접 테스트 하게 하여, 테스트 결과를 해당 스토리 문서에 업데이트 하게 하였습니다. 만약 AI가 해결을 못한 문제가 있다면 다시 스토리 문서를 스토리 제작 에이전트를 통해 수정하고 해당 문서를 개발 에이전트에게 재지시 하는 방식으로 진행하였습니다.

Q. 이번 개발에서 AI가 가장 잘해줬다고 느낀 영역과

AI 때문에 가장 시간이 새어나갔다고 느낀 영역을 각각 하나씩 이야기해 주세요.

• 잘했던 부분

확실히 개발에 대한 기본적인 구조를 잘 만들어줬습니다. 어디에 어떤 파일들이 있는지 파악하기 쉬웠고, 문서를 중심으로 하다 보니 다른 기능과 연동이 필요할 때 코드 하나하나 검색하지 않고 문서를 통해 전달하여 빠르게 진행이 가능했습니다.

• 못했던 부분

보안 관련 작업이었습니다. Supabase MCP를 사용해서 진행했는데도 권한 설정에서 문제가 생겼습니다. 하나가 안 되면 연쇄적으로 영향을 미치기 때문에, 수정이 필요할 때는 문서를 기반으로 하다보니 모든 문서를 한번에 수정하지 못한 것이 지속적인 재지시를 할 수 밖에 없었습니다. 컨텍스트 엔지니어링의 단점으로, 수정이 이루어지면 모든 문서를 수정해야 되므로 기획 단계에서 검토가 필수적입니다.

하나의 수정이 있으면 “같은 현상이 발생할 것 같은 문서들도 함께 수정해 줘”라고 요청하여 다른 문서도 수정하였지만, 단순한 검색 기능만으로 문서를 검토하고 수정하기에 한계가 명확했습니다.

Q. 디자인 작업 시, 실제로 피그마 없이 AI만으로 작업을 하셨나요? 디자인 작업 과정을 설명해주세요.

원래 실무에서는 피그마를 사용하는데, 이번에는 Claude Code의 Skills 기능 중 프론트엔드 디자인 스킬을 활용했습니다. 이미지나 아이콘 생성은 안티그래비티를 통해 Gemini의 nanobanana pro를 사용했습니다.

원하는 이미지가 항상 완벽하게 나오는 건 아니지만, 실제로 사람에게 이미지 수정 작업을 요청하듯, 이미지 내부에 설명을 첨부하여 표시하니 원하는 방향으로 수정이 이루어졌습니다. 수정은 필수적이란 생각으로, 한 번에 원하는 이미지가 완벽하게 완성될 거라는 기대를 버리고 작업하는 것이 중요했습니다.

Q. 프롬프트를 던질 때, "큰 단위로 한 번에 시키기 vs 작은 단위로 쪼개서 시키기" 중 본인이 더 효율적이라고 느낀 방식은 무엇이었나요? 그리고 그 이유는 무엇인가요?

작은 단위로 쪼개는 방식이 훨씬 효율적이었습니다.

큰 단위로 한 번에 받아서 작동만 하면 된다는 마음으로 하면 후폭풍이 감당이 안 되었어요. QA, 기능 추가, 수정 단계에서 AI가 제대로 수행하지 못하는 것을 많이 경험하였습니다. 한번에 단순히 프롬프트를 몰아서 진행 했을 경우에, 용어도 '타임라인', '타임테이블', '스케줄' 등 다양하게 사용하는 모습을 보고, 문서를 기반으로 쪼개서 진행하는 것을 선호하게 되었습니다.

문제해결 및 생산성

Q. 개발 중 가장 큰 문제는 무엇이고, 어떤 프롬프팅 방식으로 해결하셨나요?

크게 두 가지 문제가 있었습니다.

첫째, 혼자서 개발하는 경우가 많다 보니 하나의 작업에 매몰되는 것을 방지하는 게 어려웠습니다. 작은 기능 하나를 완벽히 구현해야한다는 생각에 매몰되어, UX적으로 영향이 적음에도 해당 기능 하나를 수정하기 위해 예상보다 많은 시간을 쏟은 경험이 있었습니다. 현재는 발생한 문제를 하나하나 수정하기 보단, 개발이 완료된 이후 QA 와 피드백을 통해 별도의 공수를 산정하여, 일정에서 벗어나지 않도록 조치하고 있습니다.

둘째, 보안 관련 설정에서 문제가 생겼습니다. 작동만 하면 됐지 싶었는데, 외부에서 호출했을 때도 접근이 가능한 상태였습니다 이러한 부분은 바이브코딩으로 입문한 비개발자가 놓치기 쉬운 부분이기에, 저도 해당 부분에 대해서 많은 피드백과 학습과정이 있었습니다. 현재는 항상 해당 부분을 크로스 체크하여 문제를 검토하며 진행하고 있습니다.

Q. 전체 작업 시간 중 디버깅에 사용된 비율은 얼마나 되나요?

약 20~30% 정도입니다. 개발 과정에서 마지막 두 시간은 테스트하고 수정하는 데 사용했어요. 중간중간 개발할 때도 AI가 테스트 코드를 만들어주거나, MCP를 활용해서 AI가 직접 확인하게 하여 제가 직접 디버깅한 시간도 한 시간 정도 있네요. AI가 수행한 디버깅까지 합치면 비율이 좀 더 올라갈 것 같습니다.

Q. 이번 과제를 사람이 코딩하는 방식으로 개발했을 때 예상 시간과 실제로 바이브코딩으로 걸린 시간을 비교해 본다면 어느 정도 차이가 날까요?

개발에 대한 지식이 거의 없어서 공수 산정이 어렵지만, 추측해보면 손으로 직접 코딩했다면 10배까지도 차이 나지 않을까 생각합니다.

인사이트

Q. 완성한 프로젝트에서 가장 만족스러운 부분은 무엇인가요?

디자인적으로 Antigravity를 제대로 써본 게 처음이라 정말 만족스러웠습니다. 프로그램 컨셉을 이해해서 배경이나 아이콘, 파비콘까지 잘 만들어주는 모습을 보고 많이 놀랐어요.

저는 디자이너가 아니다 보니 UI내의 디자인적인 작업이 항상 어려웠는데, 일반적으로 잘 만든 UI와 퀄리티 차이가 크지 않게 나와서 그 어려움을 극복한 것 같아 뿌듯했습니다.

Q. 바이브코딩을 통해 개발을 바라보는 관점이 바뀐 점이 있다면 무엇인가요?

저는 원래 코딩이나 AI에 대해 잘 몰랐던 사람이고, 그나마 있던 재능은 글쓰기였어요. 영화 블로그를 운영하고 프리랜서 작가 생활도 했죠. AI가 나왔을 때 입력창이 글쓰기 형태여서 많은 것을 할 수 있게 되었습니다.

개발에 대한 시선이 바뀌었다기보다, AI 덕분에 이 세상에서 할 수 있는 일이 많아졌다는 것을 느꼈어요. 유일한 재능이 문장을 만드는 것뿐이었는데, 이제는 그림도 그리고 서비스도 만들 수 있게 된 게 신기합니다.

Q. 바이브코딩을 잘하기 위해 추천하는 학습 방법이나 리소스는 무엇인가요?

BMAD-Method를 다같이 연구하면 좋겠습니다. BMAD에서 요구하는 업무 방식을 익힌다면 단순히 코딩뿐만 아니라 무언가를 배우며 살아갈 때, 행동 이전에 준비 과정에서 생각 할 수 있는 폭을 늘릴 수 있습니다. 예를 들어 요리를 배우고 싶다면 바로 재료부터 사서 시작하는 게 아니라, '요리를 통해 누구에게 무슨 음식을 줘야 할까'부터 생각하는 것 처럼요.

저는 개발 자체보다 문서 작업을 더 좋아하게 되었습니다. 창의적인 것을 좋아하는 편인데, 문서화과정에서 다양한 브레인스토밍을 하고 하나하나 고려하며 준비하는 과정, 그리고 차곡차곡 쌓아놓은 것들이 실제로 구현되는 걸 보는 게 더 재미있더라고요.

처음 바이브코딩을 시작할 때 이런 기록 과정 없이 시작한 게 너무 아쉬워요. 그 과정 과정에서 그당시 들었던 생각이나 여러 인사이트가 스치듯 지나갔는데, 문장으로 만들어내지 않으면 그 순간의 생각을 확신하기 어렵거든요. 지금 생각해보면 정말 아쉽습니다.

Q. 바이브코딩 개발 중 주의할 점은 무엇이라고 생각하시나요?

결국 사람이 이해하기 좋은 것이 AI도 이해하기 좋습니다. '내가 개떡같이 말해도 AI가 알아서 해주겠지'라는 마인드를 버려야 해요. 내가 봐도 충분히 이해가 잘 될 때 작업을 시작해야 합니다. 내 머릿속에 직접 AI를 박는 게 아니면 잘 안 되거든요.

Q. AI 시대에서 살아남기 위한 바이브코더들에게 조언 한 마디 부탁드립니다.

제가 감히 조언할 입장은 아니고 저 또한 서툴게 배워가고 있는 입장이기에, 위기나 변화 속에서 살아남을 수 있는 여러가지 방법 중에서 하나의 방법 정도로만 생각해주시면 좋겠습니다.

저는, 수능에 빗대어 이야기 하고 싶습니다. 이제는 월 3만 원(Gemini Pro 구독료)이면 수능 만점자의 지능을 내 휴대폰에 담을 수 있는 시대입니다. 단순히 정답을 찾아내는 능력은 누구나 갖추게 될 수 있는 시점에서, 수능 만점 그 자체가 목표가 될 수는 없습니다. 앞으로는 문제를 마주했을 때 나만의 관점으로 해결의 실마리를 찾고, 이를 결과로 연결할 수 있는 '나만의 해결 도구'를 얼마나 다양하게 갖추느냐'가 핵심 경쟁력이 되겠죠.

과거에는 단 하나의 방법을 온전히 완성하는 것이 살아남는데 가장 주요한 것으로 평가받았다면, AI시대 이후에는 문제 상황이 오면 대응할 수 있는 자신만의 여러 해결법을 갖추는 것이 중요하다고 생각합니다. 무엇이든지 쉽게 시도해볼 수 있는 시대가 된 만큼, 단순히 알고 있는 지식 보다도 직접 행동을 통해 얻어낸 경험 자체가 더 유효해졌다고 생각합니다.

그리고 또 중요한 것은 메모하는 습관이라고 생각합니다. 저는 스스로를 '메모 호더(Memo Hoarder)'라고 표현할 정도로 메모를 중요하게 생각했었는데 유용하게 사용하지는 못했습니다. 현재는 AI툴을 이용해 작성해놓은 무작위의 메모를 정리하는 방법을 배웠고, 과정 속의 경험들이 휘발되지 않고 온전히 제 것으로 쌓이게 되었습니다.

이처럼 다양한 경험을 기반으로 한 자신만의 여러 무기를 갖춰놓고, 그 과정을 기록하여 다시 자신의 발전의 재료로 만든다면 빠르게 변화하는 AI 시대에서 살아남을 수 있지 않을까 합니다.