바이브 코딩으로 48시간 만에 250명 규모 해커톤 AI 심사 시스템 구축기

안녕하세요! 지난 주 목요일, 카카오 AI 캠퍼스에서는 크루들을 대상으로 한 특별한 '10K 해커톤’이 열렸습니다. 이 해커톤은 무박 2일의 전통적인 방식에서 벗어나, 단 10시간 동안 AI 도구를 최대한 활용해 아이디어를 MVP(최소 기능 제품)로 구현하는 '바이브 코딩(Vibe Coding)'에 중점을 둔 행사였죠.

이런 취지를 살려 "심사도 AI로 해야 하지 않을까요?"라는 의견이 나왔고… 제가 무심코 "Gemini를 쓰면 시연 영상 심사도 가능할 것 같은데요?"라고 말했다가 덜컥 프로젝트의 담당자가 되어버렸습니다. 😅

🚀 D-30, 아이디어에서 v1.0 기획서까지

행사 한 달 전, 저와 동료 sue.cream는 AI 심사 시스템 구축의 여정을 시작했습니다. sue.cream는 순식간에 v0를 이용해 시스템의 초기 프로토타입을 만들어냈습니다. “와, AI로 하니 정말 뚝딱이네!” 저희는 이른 성공에 안도하며 다른 급한 업무를 먼저 처리하기로 했습니다. 😂

하지만 시간은 흘러 D-14, 일정의 압박이 시작되었습니다. 관련 담당자들과 모여 심사 프로세스 전반에 대한 깊은 논의를 진행했습니다. 놀랍게도, 미팅이 끝난 직후 회의록을 Gemini에게 전달하자 단 몇 분 만에 AI 심사의 목표, 주요 기능, 단계별 체크리스트가 담긴 AI 심사 시스템 기획서 v1.0이 완성되었습니다.

기획서가 나온 당일, 저는 v0를 붙잡고 3시간 동안 화면 설계를 시작했습니다. 로그인, 결과 제출, 팀 대시보드, 동료 평가, 최종 결과 페이지 등 총 14개에 달하는 페이지 구성을 완료했죠. v0에게 대화하듯 요구사항을 전달하니 자유자재로 화면이 만들어졌고, 에셋 이미지를 올리자 제법 그럴듯한 사이트가 완성되었습니다. 프론트엔드의 세션 유지나 API 호출을 가정한 Mock 데이터 바인딩 같은 기술적인 부분까지 미리 처리해두었습니다.

💻 D-13, AI가 개발해주는 프론트엔드와 백엔드

다음 날, v0에서 작업한 결과물을 깃헙으로 연동해 소스코드를 확보했습니다. 보통 이런 UI 도구는 코드가 지저분하게 생성되곤 하는데, v0의 결과물은 놀라울 정도로 깔끔했습니다. 로컬에서 실행했을 때 완벽하게 돌아가는 것을 보고 '이제 거의 다 끝났다’고 생각했죠. 하지만 그것은 거대한 착각이었습니다. 모든 것은 이제 시작이었습니다.😱

이제 Claude Code를 만날 시간이었습니다. 가장 먼저 프론트엔드 코드를 분석해 API 명세서를 만들어달라고 요청했습니다. v0에서 이미 Mock 데이터 구조를 잡아두었기에, Claude는 이를 기반으로 필요한 API 스펙을 정확하게 설계해주었습니다.

이 명세서를 들고 백엔드 프로젝트 구성에 돌입했습니다. 기존에 Spring AI + Kotlin 기반 프로젝트 경험이 있어서 자신감은 있었지만, OpenAI, Claude, Gemini라는 각기 다른 LLM을 하이브리드 심사위원으로 구성하는 것은 처음이었습니다.

start.spring.io에서 Spring AI, PostgreSQL, Google OAuth2, JWT, Modulith 등 필요한 의존성을 추가해 템플릿 프로젝트를 생성했습니다. 그리고 Claude Code에게 이 프로젝트와 API 명세서를 보여주며

“이 명세대로 API를 구현하고 필요한 데이터베이스 스키마를 설계해줘”

라고 지시했습니다.

정말 이게 가능하냐고요? 네, 가능했습니다. Claude는 프로젝트 구조를 분석한 뒤, 명세서에 맞춰 Controller, Service, Repository, Entity를 척척 개발하기 시작했습니다. 이 작업이 진행되는 약 10분 동안 저는 사내 시스템에서 개발용 DB를 생성하며 기다렸죠.

백엔드 작업이 끝나자마자, 프론트엔드 프로젝트로 돌아와 Claude에게 "이제 백엔드 API 서버가 준비됐으니, 프론트에서 실제 API를 호출하도록 코드를 수정해줘"라고 요청했습니다. 놀랍게도 Claude는 백엔드 프로젝트의 컨트롤러 코드를 스스로 확인하며 Mock 데이터를 실제 API 호출로 하나씩 교체하기 시작했습니다.

잠시 후, 로컬에서 프론트와 백엔드 서버를 모두 실행했습니다. 설마 했는데… 한 번에 성공했습니다! 로그인부터 팀 대시보드까지 모든 기능이 순조롭게 동작했습니다.

🤯 D-10, 배포와 구글 로그인이라는 거대한 벽

이제 담당자들에게 공유하기 위해 사내 시스템에 배포할 차례였습니다. 사내 클러스터(DKOS) 생성, 인그레스 설정, 방화벽 처리 등 대부분의 작업은 직접 진행했지만, Dockerfile이나 k8s 설정 파일 등은 Claude의 도움을 받았습니다. (물론, 기존 프로젝트 설정을 참고해 수정하는 과정은 필요했습니다.)

* DKOS: 카카오 사내의 Kubernetes(k8s) 기반 클러스터 오케스트레이션 서비스로, 대다수의 카카오 서비스가 DKOS 기반으로 개발/운영되고 있습니다.

다음은 구글 로그인 구현이었습니다. Claude에게 Google OAuth2 인증과 JWT 세션 유지를 요청했고, 프론트와 백엔드 코드가 순식간에 수정되었습니다. 로컬 테스트는 완벽했죠.

그러나 배포된 환경에서는 구글 로그인이 먹통이었습니다. 여기서부터 기나긴 삽질이 시작되었습니다. AI는 한번 문제에 빠지면 헤어나오지 못하는 경향이 있는데, 딱 그런 상황이었습니다. 원인은 로드밸런서 환경에서 여러 서버 인스턴스를 오가며 세션이 유실되는 문제였습니다. 이 문제는 과거 프로젝트 코드를 참고해 겨우 해결했습니다.

하지만 이번엔 구글 로그인 시 무한 로딩에 빠지는 문제가 발생했습니다. 시간은 흘러가고 해결책은 보이지 않았습니다. 결국 '내일의 나’에게 맡기기로 하고 잠시 작업을 중단했습니다.

다른 업무를 처리하느라 시간은 어느새 D-5로 다가왔습니다. 여전히 문제는 해결되지 않았죠. 날을 잡고 AI가 작성한 코드를 한 줄 한 줄 뜯어보다가 마침내 원인을 찾았습니다. k8s 설정 파일 중, AI가 작성한 프록시 설정이 잘못되어 구글 인증 서버에 접근하지 못하고 타임아웃이 발생했던 것입니다. 설정을 수정하자 거짓말처럼 모든 문제가 해결되었습니다. AI로 로그인 하나 구현 못 하나 싶었는데, 정말 다행스러운 해프닝이었습니다.

🛠️ D-4, 전면 개편과 코드베이스의 역습

시스템이 안정되자 근본적인 질문이 떠올랐습니다. “그래서 행사 당일, 이 시스템을 어떻게 운영할 건데?” 1차, 2차 결과물 제출 페이지가 동시에 열려 있으면 안 되는 등 운영 시나리오가 전혀 고려되지 않았던 것이죠.

D-4, 특단의 조치를 내렸습니다. 바로 어드민 기능 전면 개편이었습니다.

팀 관리, 제출물 관리, AI 심사 관리, 동료 평가 관리 등 필요한 모든 기능 기획을 새로 하고, v0로 어드민 대시보드 화면을, Claude Code로 API를 다시 구현했습니다. 유저와 어드민의 권한(RBAC)도 재검토했죠. 이 과정에서는 앞뒤 가리지 않고 요청, 테스트, 보완을 반복했습니다. 놀랍게도 Claude는 대부분의 복잡한 요구사항을 의도대로 구현해주었습니다.

하지만 코드베이스가 커지자 부작용이 나타났습니다. AI가 이미 구현된 기능을 분석하지 못하고 유사한 기능을 새로 만들려는 시도가 반복되었습니다. 이때부터는 대충 말해도 알아듣는 ‘바이브 코딩’ 모드보다, 조금 불편하더라도 상세히 지시하며 AI가 다른 길로 새지 않도록 하는 것이 중요해졌습니다.

이후 담당자 리뷰, CTO 보고, 현장 운영진과의 QA를 거치며 시스템을 계속 보완했습니다. 특히 테스트 데이터가 없는 상황에서는 AI로 수백 개의 테스트 데이터를 생성하여 DB에 삽입해 테스트를 진행하기도 했습니다.

🎉 D-Day, 그리고 예상치 못한 변수들

밤을 새우고, 드디어 10K 해커톤 행사가 시작되었습니다. 저의 해커톤은 이제 결과를 볼 시간이었습니다.

1차 결과물 제출과 AI 심사는 순조롭게 진행되었습니다. 다만 한 가지 아쉬운 점은, AI가 심사 내용은 매우 깊이 있게 작성하는 반면, 점수가 그 내용을 충분히 반영하지 못하는 느낌이었습니다. 다음에는 심사평과 점수 산정을 분리해야겠다는 교훈을 얻었습니다.

2차 심사에서는 이번 프로젝트의 하이라이트인 Gemini의 시연 영상 분석이 기다리고 있었습니다. 변수가 많을 것을 우려해, 참가자들이 자신의 유튜브 영상 URL이 제대로 분석되는지 미리 확인할 수 있는 테스트 페이지를 급히 만들어 배포했습니다.

그런데 2차 결과물이 제출되면서 문제가 터졌습니다. 시연 영상과 전혀 관련 없는 광고 영상 URL이 제출되었는데, AI가 "해커톤의 주제를 광고 영상 제작으로 가정하면, 이 영상은 완성도가 매우 높다"며 90점 이상의 높은 점수를 준 것입니다. 아차 싶었습니다. 심사 프롬프트에 해커톤의 취지에 대한 설명이 부족했던 탓이었습니다. 즉시 프롬프트를 수정하여 재배포하고, 기존 제출물들을 다시 분석 돌렸습니다.

제출 마감이 임박하자 더 큰 문제들이 발생했습니다.

• 숏츠(Shorts) 영상 등록 불가: 세로 비율의 영상이 숏츠로 간주되어 분석이 안 되는 문제가 있었습니다.
• 할루시네이션(환각) 현상: 영상이 유튜브에 업로드 및 인코딩되는 도중에 심사가 시작되면, Gemini가 오류 대신 전혀 엉뚱한 내용의 심사평을 내놓았습니다.

후자는 재심사나 재업로드를 통해 해결했지만, 숏츠 문제는 행사가 지연되다보니, 다음 단계를 진행할 수 밖에 없었고, 일부 팀이 마감 시간 내에 영상을 재등록하지 못하는 안타까운 상황으로 이어졌습니다. 사전에 숏츠 분석 불가 공지를 놓친 제 불찰이 커서 너무나 죄송한 마음입니다. 😭

🏆 최종 결과와 교훈

이후 과정은 동료 평가로 이어졌습니다. 각 참가자는 자신을 제외한 무작위 2팀의 결과물을 보고 더 나은 프로젝트를 선택하는 방식으로 총 5회 평가를 진행했습니다. 250여 명의 참가자로부터 약 1,200개의 평가 데이터가 쌓였고, 이를 기반으로 ELO Rating 점수를 산출했습니다.

* ELO Rating: 플레이어 간의 상대적인 실력을 수치화하여 평가하는 순위 기반 등급 시스템입니다. 경기 결과에 따라 참가자들의 레이팅 점수가 조정되며, 이 점수를 통해 승률을 예측하거나 실력 순위를 매길 수 있습니다. 원래 체스 등의 1:1 게임에서 사용되었으며, 최근에는 AI 모델 간의 성능 비교, 추천 알고리즘 평가 등 다양한 분야로 활용이 확장되고 있습니다.

최종 순위는 2차 AI 심사 점수와 동료 평가 점수를 합산하여 매겨졌고, 마침내 최종 7팀이 선정되었습니다.

단순한 아이디어로 시작했지만, AI 심사 시스템을 구축하는 과정은 생각보다 훨씬 복잡하고 고려할 것이 많았습니다. '바이브 코딩’이 누구나 쉽게 개발을 시작하게 해주는 강력한 도구임은 분명하지만, 안정적이고 고도화된 시스템을 구축하는 데는 여전히 개발자의 깊은 경험과 통찰력이 필수적이라는 것을 절실히 깨달았습니다.

주말에 Claude Code에게 지난 커밋 기록을 기반으로 개발 소요 시간을 산정해보라고 하니 '약 48시간’이라는 결과가 나왔습니다. 물론 다른 업무와 병행하며 간헐적으로 작업했기에 실제 집중한 시간은 더 적었을 겁니다.

“지난 커밋을 토대로 일 별 개발 추정시간을 계산해줘”

AI의 도움이 없었다면 이 모든 것은 불가능했을 겁니다.

긴 글 읽어주셔서 감사드리며, 저의 경험이 여러분께 작은 도움이 되었기를 바랍니다.

마지막으로 10K 해커톤 심사 시스템 구축에 도움을 주신 모든 분들께 감사드립니다.

주요 기술 스택

• Frontend: v0 (UI 생성), React, TypeScript
• Backend: Spring AI, Kotlin, PostgreSQL, JWT
• AI Models: OpenAI, Claude, Gemini (하이브리드 심사위원)
• Infrastructure: Kubernetes, Docker, Google OAuth2
• Development Tools: Claude Code (AI 페어 프로그래밍)

핵심 교훈

1. 바이브 코딩의 가능성과 한계: AI 도구는 빠른 프로토타이핑에 탁월하지만, 복잡한 시스템에서는 세밀한 지시와 검증이 필요합니다.
2. 프롬프트 엔지니어링의 중요성: AI 심사의 품질은 프롬프트의 명확성에 크게 좌우됩니다.
3. 예외 상황 대비: 실제 운영 환경에서는 예상치 못한 변수가 항상 발생합니다.
4. 개발자의 역할 변화: AI 시대에도 시스템 설계, 문제 해결, 품질 보증에서 개발자의 경험은 여전히 핵심입니다.