“혼자서도 팀처럼 개발할 수 있었어요” – 바이브코딩 콘테스트 1등 수상자 인터뷰

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

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

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

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

평가 기준은 세 가지!

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

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

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

이번 인터뷰에서는 콘테스트 1등 수상자 Hung Nguyen 님을 만나 이야기를 나눴습니다. 캐나다에서의 학업과 실무 경험을 바탕으로 풀스택 엔지니어로 일해 온 그는, 제한된 8시간 안에서 명확한 전략과 AI 활용 방식으로 완성도 높은 결과물을 만들어냈는데요. 짧은 시간 안에 어떻게 작업을 설계하고 우선순위를 정했는지, 그리고 바이브코딩과 AI 시대의 개발자 역량을 어떻게 바라보고 있는지 그의 경험을 통해 들어봤습니다.

기본 정보

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

저는 캐나다에서 약 8년 정도 거주했습니다. 처음에는 전자공학을 전공했지만, 2022년부터는 IT 분야 쪽으로 방향을 바꾸게 됐고, 2025년 4월에 정식으로 졸업했습니다. 전공을 바꾸는 과정이 쉽지는 않았지만, 기술을 실제로 쓰는 일에 더 흥미를 느끼게 된 게 계기가 됐습니다.

학업 중에는 정부 기관인 아동·가족부(Ministry of Children and Family Services)에서 1년간 인턴으로 근무했습니다. 이때 여러 실무 프로젝트에 직접 참여하면서, 이론보다는 실제 운영 환경에서 시스템이 어떻게 돌아가는지를 경험할 수 있었습니다. 기본적인 AI 지식도 이 시기에 자연스럽게 쌓았고, 학업 전반에서 AI를 꽤 적극적으로 활용해 왔습니다.

졸업 이후에는 소규모 스타트업에 합류해 풀스택 엔지니어로 일했습니다. 팀 규모가 3명 정도로 작다 보니, 파운딩 엔지니어이자 프로젝트 리드 역할도 함께 맡게 됐습니다. 기술 스택은 주로 Next.js와 React를 사용했고, 빠른 개발 속도가 중요한 환경이어서 AI 도구를 적극적으로 활용하며 제품 개발을 진행했습니다.

Q. 바이브코딩 경험은 어느 정도였나요? (초보 / 중급 / 경험 있음)

굳이 나누자면 중급 정도라고 생각합니다. 처음부터 업무에 바로 바이브코딩을 적용한 건 아니고, 개인 사이드 프로젝트를 중심으로 먼저 써 보기 시작했습니다. 프로젝트를 하나씩 해보면서 시행착오도 많이 겪었고, 그 과정에서 AI와 어떻게 협업해야 실제로 생산성이 올라가는지 조금씩 감을 잡게 됐습니다.

지금은 업무 전반에서 AI를 거의 매일 사용하고 있습니다. 도구 자체를 쓰는 데 부담은 없고, 작업 흐름 안에 자연스럽게 녹여서 활용하고 있다고 느낍니다.

전략

Q. 단 8시간 안에 작업을 완료하셨다고 했는데, 작업 프로세스와 시간 배분은 어떻게 하셨나요?

전체 과제 수행 시간은 8시간이었고, 이 중 실제 구현에 쓴 시간은 약 5시간 정도였습니다. 짧은 시간 안에 가능했던 가장 큰 이유는 개발 과정을 최대한 명확하게 나눠서 계획했고, 프롬프트도 되도록 구체적으로 작성했기 때문입니다. 과제 자체가 비교적 상세한 스펙을 제공하고 있었던 점도 도움이 됐습니다.

• 1단계: 작업과 기능 정리

프롬프트를 작성할 때 가장 신경 쓴 부분은 컨텍스트 길이였습니다. 설명이 너무 길어지면 오히려 AI가 핵심을 놓치는 경우가 많았기 때문입니다. React와 Tailwind에 대한 기본적인 이해가 UI 구현에 도움이 됐고, AI가 가끔 오래됐거나 부정확한 코드를 만들기도 해서, 그걸 직접 판단하고 수정할 수 있는 기본적인 IT 지식은 꼭 필요하다고 느꼈습니다.

• 2단계: 빌드 진행

스펙을 확인한 뒤 기술 스택은 Next.js와 Neon(PostgreSQL)로 정했습니다. 라이브러리 선택에는 개인 취향도 어느 정도 들어가지만, 사용 편의성과 무료 여부도 함께 고려했습니다.

먼저 인증(Authentication)을 구현했고, Google이나 GitHub OAuth를 지원하는 better-auth를 사용했습니다. 이후 DB 구조와 필요한 테이블, 컬럼을 먼저 직접 잡고, AI의 제안을 참고해 수정했습니다. 별도의 백엔드를 두기보다는 Next.js의 Built-in API Routes(Serverless API)를 활용했습니다.

이 과정에서 GitHub에 커밋할 때마다 AI가 작성한 코드를 반드시 다시 확인하고 테스트했습니다. 커밋은 최대한 잘게 나눠서, 변경 사항을 추적하거나 되돌리기 쉽게 관리했습니다. 우선순위는 항상 “일단 돌아가게 만들자”에 두고, 핵심 기능부터 검증했습니다.

• 3단계: 프론트엔드 구현과 개선

AI에게는 가능한 한 구체적인 스펙을 전달했습니다. 참고할 서비스가 있을 때는 이번에는 Linear를 레퍼런스로 사용했는데, 이런 맥락을 함께 주면 결과가 확실히 좋아졌습니다. 필요에 따라 이미지 분석 기능도 활용했지만, 이 방식은 아직 조금 불안정하다는 느낌이 있었습니다.

• 4단계: 랜딩 페이지 제작

랜딩 페이지는 사용자가 가장 먼저 보게 되는 화면이기 때문에, 최대한 깔끔하고 정돈된 인상을 주는 데 집중했습니다.

• 5단계: 배포

코드는 GitHub에 푸시한 뒤, 기존에 가지고 있던 도메인을 사용해 Vercel에 배포했습니다. 전체적으로 실제 손이 간 작업 시간은 약 5시간 정도였습니다.

AI 기능 구현

Q. 어떤 기능을 위해 어떤 AI 도구를 활용하셨고, 그 이유는 무엇인가요?

주로 사용한 AI 도구는 Claude Opus 4.5와 Grok Fast였습니다.

그중에서도 Claude Opus 4.5는 코딩 작업에 있어 가장 성능이 뛰어나다고 느꼈습니다. 다만 프리미엄 모델이기 때문에, 로직이 매우 복잡하거나 컨텍스트 범위가 넓은 작업에 한해서 선택적으로 사용했습니다. 토큰 사용량을 효율적으로 관리하기 위해, 복잡한 작업도 가능하면 작은 단위로 나누어 프롬프트를 작성하려고 했습니다.

Grok Fast는 전반적으로 안정적이고 속도도 빠른 편이었습니다. 현재 GitHub 계정을 통해 무료로 사용할 수 있기 때문에, 상대적으로 단순한 작업이나 반복적인 업무에 주로 활용했습니다.

프런트엔드 디자인 작업에서는 Gemini 3 Pro와 Flash 모델도 사용했는데, 두 모델 모두 디자인 결과물이 꽤 좋았습니다. 특히 Flash 모델은 토큰 사용량이 낮은 편임에도 결과물의 퀄리티가 높아서 인상 깊었습니다.

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

작업 난이도에 따라 조금씩 달랐습니다.

간단한 작업의 경우에는 평균적으로 1~2회 정도였고, 디자인 작업처럼 결과를 조정해야 하는 경우에는 보통 3~5회 정도 재지시가 필요했습니다.

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

프롬프트를 작성할 때 정해진 공식이나 템플릿을 따로 두지는 않았습니다. AI에게 작업을 맡길 때는, 수정이 필요한 파일이나 코드 조각을 그대로 제공한 뒤 비교적 직관적인 질문을 던지는 방식을 주로 사용했습니다.

제가 생각하는 좋은 프롬프트는 요구사항과 기대 결과가 명확하고, 불필요한 설명 없이 핵심이 잘 전달된 형태입니다. 대화하듯 길게 쓰기보다는, 명령에 가깝게 직관적이고 핵심만 담아 작성하는 편이 훨씬 효율적이라고 느꼈습니다.

또한 온라인에는 프롬프트를 정제하거나 간결하게 만들어주는 도구들도 있는데, 이런 도구를 활용하면 핵심 요구사항만 담긴 최적화된 프롬프트를 만드는 데 도움이 됩니다.

Q. 8시간 안에 프로젝트를 완성하는 데 도움이 된 도구나 라이브러리가 있었나요?

Context7 MCP를 사용했습니다. 이 도구는 AI가 인터넷상의 문서를 직접 리서치할 수 있도록 도와주기 때문에, 사람이 직접 자료를 찾아보는 시간을 크게 줄여 줍니다. 동시에 AI가 구버전 정보를 최신 기준으로 보완하는 데에도 상당히 도움이 됐습니다.

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

네, Figma나 다른 레퍼런스 툴은 사용하지 않았고, 디자인 작업은 전적으로 AI에 의존했습니다. 원하는 UI 분위기를 전달하기 위해 smooth, dark color, typography style 같은 키워드와 정보를 제공했고, AI가 그에 맞는 UI를 생성하도록 했습니다.

물론 모든 결정을 AI에게 맡기지는 않았습니다. 항상 제 의견을 더해 수정 방향을 제시했고, 마음에 드는 테마가 나오면 그 스타일을 기준으로 전체 앱 UI를 다시 정리하고 리팩터링하도록 요청했습니다.

문제 해결 및 생산성

Q. 개발 중 가장 어려웠던 부분은 무엇이었나요?

가장 시간이 많이 걸린 부분은 프론트엔드 디자인이었습니다. 디자인 전문 역량이 없다 보니, 몇 번의 프롬프트만으로 원하는 결과를 얻기는 쉽지 않았습니다. 반면 로직이나 문법 쪽은 AI가 강점을 보이는 영역이라 큰 문제는 없었고, 대부분은 프롬프트 맥락이 부족했을 때 생기는 문제였습니다.

또 하나 자주 겪는 문제는 AI가 수정하면 안 되는 코드까지 덮어쓰는 경우였습니다. 파일 전체가 통째로 바뀌는 상황은 바이브코딩을 해본 분들이라면 공감하실 것 같습니다. 그래서 파일을 최대한 짧게 유지하고, 수시로 리팩터링하는 걸 중요하게 생각합니다.

로직 디버깅은 주로 console.log를 활용해 비교적 직접적으로 진행했습니다. 복잡한 경우에는 AI에게 어디에 로그를 찍으면 좋을지 묻고, 그걸 바탕으로 원인을 추적했습니다. 작업이 끝날 때마다 정상 동작하는 상태를 커밋하고, 새 AI 대화창을 여는 습관도 도움이 됐습니다.

Q. 이번 과제를 사람이 직접 코딩하는 방식으로 개발했다면, 예상 시간과 바이브코딩으로 실제 걸린 시간의 차이는 어느 정도였나요?

바이브코딩은 확실히 훨씬 빠르다고 느꼈습니다. 제 경우에는 AI를 사용하지 않았다면, 핵심 기능만 구현하는 데에도 최소 2~3일은 걸렸을 것 같습니다.

그리고 디자인까지 포함했다면, 전체적으로는 일주일 정도는 필요했을 것이라고 생각합니다. 이 과제에서는 특히 디자인 작업이 시간을 많이 차지하는 영역이었기 때문에, 그 차이가 더 크게 느껴졌습니다.

인사이트

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

가장 만족스러운 부분은 디자인입니다. 여러 번 디자인을 반복하면서 다양한 시안을 만들어봤고, 그중에서 가장 마음에 드는 하나를 골라 전체 테마로 가져갔습니다.

결과적으로 프로젝트의 분위기나 방향성과 잘 맞는 디자인이 나왔다고 느꼈습니다.

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

바이브코딩은 혼자서 작업하더라도, 마치 하나의 팀이 된 것처럼 개발을 진행할 수 있다는 느낌을 줬습니다. 이 점은 제가 기존에 생각하던 개발 방식과는 확실히 다른 경험이었습니다.

다만 동시에, 프로그래밍 기초를 유지하는 데에는 분명한 위험 요소도 있다고 생각합니다. AI에 의존하는 비중이 커질수록, 스스로 코드를 작성하는 능력은 자연스럽게 약해질 수 있기 때문입니다. 그렇기 때문에 AI가 만들어내는 결과를 이해하고, 관리할 수 있을 정도의 기본기는 반드시 필요하다고 느꼈습니다.

요즘 개발은 단순히 코드를 작성하는 일에 그치지 않고, 시스템을 설계하고 버그를 해결하는 비중이 훨씬 커졌습니다. 그런 점에서 앞으로는 AI가 올바른 방향으로 코딩하도록 가이드하는 능력이 개발자에게 더욱 중요한 역량이 될 것이라고 생각합니다.

Q. 바이브코딩을 잘하기 위해 추천하고 싶은 학습 방법이나 리소스가 있을까요?

OpenAI(ChatGPT), Cursor, Google(Gemini), Anthropic(Claude)처럼 큰 기업들이 제공하는 문서와 자료들은 바이브코딩을 이해하는 데 상당히 도움이 된다고 생각합니다.

AI에게 질문하면 바로 답변을 받을 수 있다는 점도 학습 측면에서는 큰 장점입니다.

하지만 그럼에도 불구하고, 가장 중요한 것은 직접 프로젝트를 만들어보는 연습이라고 생각합니다. 떠오르는 아이디어가 있다면 크고 작음을 따지지 말고 구현해 보면서, 자신에게 맞는 방식과 흐름을 찾아가는 게 중요하다고 봅니다.

Q. 바이브코딩을 할 때 개발자들이 특히 주의해야 할 점은 무엇이라고 보시나요?

개발자는 계속해서 코드를 직접 작성하고, 사고하는 연습을 병행해야 한다고 생각합니다. 특히

“이 코드는 AI 없이는 내가 못 쓸 것 같다”는 느낌이 들 때일수록, AI의 도움 없이 직접 타이핑하고 고민해보는 시간이 필요하다고 봅니다. 코드를 읽는 것과 직접 작성하는 것은 분명히 다르기 때문입니다.

또한 일부 회사에서는 코딩 테스트나 기술 과제에서 AI 사용을 허용하지 않는 경우도 있기 때문에, 이런 상황에 대비하려면 기본기를 꾸준히 유지하는 것이 중요합니다. 이런 연습은 업무 시간이 아니라 개인적인 여유 시간에 하는 것이 더 적절하다고 생각합니다. 업무 시간에 무리하게 연습을 끼워 넣으면 오히려 효율이 떨어질 수 있습니다.

결국 AI를 사용하더라도 버그를 고치고 결과에 책임지는 건 개발자 본인이기 때문에, 항상 꼼꼼함이 필요합니다. 만약 AI를 사용했는데도 속도가 나지 않거나 효율이 떨어진다면, 그건 AI를 잘못 쓰고 있다는 신호일 수 있습니다. 반대로 생산성과 효율이 눈에 띄게 좋아졌다면, 이미 올바른 방식으로 활용하고 있다고 볼 수 있다고 생각합니다.

Q. AI 시대를 살아가려는 바이브코더들에게 한 마디 조언을 해주신다면요?

개발자로서 진지하게 커리어를 쌓고 싶다면, AI의 도움 없이도 코드를 이해하고 작성할 수 있는 기본기를 먼저 다지는 것이 중요하다고 생각합니다.

AI 덕분에 초반에 웹 애플리케이션을 만드는 건 굉장히 쉬워졌지만, 내부 원리를 이해하지 못하면 이후에 문제가 생겼을 때 손을 대기 어렵습니다. 그 결과, 이해하지 못한 코드가 계속 쌓이면서 기술 부채로 이어지게 됩니다. 실제로 저는 AI가 버그를 수정하려다, 사용자가 제안된 명령과 결과를 제대로 이해하지 않은 채 승인해버려서 코드베이스와 데이터 전체가 날아간 사례도 여러 번 봐왔습니다.

현재의 AI 모델만으로는, 이런 식으로 쌓인 기술 부채를 완전히 해결해 주기는 어렵다고 생각합니다.

반대로 개발 배경이 없는 분들이라면, 단순히 바이브코딩을 경험해 보고 싶다는 이유로 AI를 활용해 보는 것도 충분히 괜찮다고 생각합니다. 그 경험이 계기가 되어, 만드는 즐거움을 느끼게 될 수도 있기 때문입니다.

다만 장기적으로 보면 언젠가는 코드를 몰라도, 원하는 결과를 얼마나 구체적으로 설명할 수 있는지만으로 웹 애플리케이션을 만들 수 있는 시점이 올 수도 있겠지만, 지금은 아직 그 단계는 아니라고 생각합니다. 그래서 여전히 기본적인 개발 역량은 중요하다고 봅니다.