해커톤에서 키보드를 한 번도 안 만진 팀이 우승했습니다. AI 에이전트가 밤새 10만 줄의 코드를 짰고, 그중 7만 줄은 테스트 코드였어요. 개발자는 설계도만 던져놓고 퇴근했고요. 이게 서울 한복판에서 실제로 일어난 일이에요.
이게 뭔데?
랄프톤(Ralphton)은 "인간은 퇴근하고 AI가 코딩한다"는 콘셉트의 해커톤이에요. 개발자 커뮤니티 팀어텐션(Team Attention)이 카카오벤처스와 함께 주최했고, 글로벌 빅테크 오픈AI가 후원했어요. 2026년 2월 28일부터 3월 1일까지 서울 성북구에서 열렸고, 오픈AI 싱가포르 개발자들이 직접 현장을 찾았어요.
기존 해커톤은 참가자들이 밤새 직접 코드를 짜고, 그 결과물을 평가하는 방식이었잖아요. 랄프톤은 완전히 달라요. 참가자는 아이디어와 설계 문서(PRD, 스펙)만 제출하고, 실제 코딩은 AI 에이전트가 수행해요. 첫날에 하네스 엔지니어링(harness engineering) — 쉽게 말해 AI가 올바르게 작동할 수 있도록 환경과 제약 조건을 설계하는 작업 — 을 완료하면, AI 에이전트가 밤새 자율적으로 코딩하고, 다음 날 아침 심사위원이 결과물을 평가하는 구조예요.
예선을 거친 9팀이 본선에 참가했어요. 스타트업 개발자, 창업자 등이 참여했고, 뱅크샐러드 공동창업자인 황성현 씨(현재 더벤처스 테크리드)도 LLM 기반 퍼즐 웹을 만들었어요. AI 에이전트 스타트업을 운영하는 김우영 씨는 악보 PDF를 분석해서 전조(키)를 자동 변환하는 서비스를 개발했고요.
뭐가 달라지는 건데?
우승팀의 사례가 가장 직관적으로 보여줘요. 이 팀은 고정캠 영상을 기반으로 가사노동을 자동화하는 봇을 만들었는데, 핵심은 과정이에요.
시작부터 끝까지 참가자들이 키보드를 한 번도 만지지 않았어요. 대신 개발 전에 AI 에이전트 간 133회의 소크라틱 문답(Socratic reasoning)을 거치게 해서, 설계의 모호성 지수를 0.05까지 낮췄어요. AI 에이전트가 "이 요구사항이 A를 의미하는 건가요, B를 의미하는 건가요?"라고 서로 묻고 답하면서, 사람이 놓칠 수 있는 설계 허점을 스스로 잡아낸 거예요.
10만 줄 중 7만 줄이 테스트 코드라는 점도 인상적이에요. AI가 "일단 돌아가게 짜고 나중에 테스트"가 아니라, 처음부터 검증 가능한 코드를 설계한 거거든요. 여러 AI 에이전트를 활용하는 과정에서 발생할 수 있는 거짓 보고(hallucination)도 이 테스트 코드가 사전에 차단했어요.
| 기존 해커톤 | 랄프톤 | |
|---|---|---|
| 개발자 역할 | 직접 코드 작성 | 설계도 + 하네스 엔지니어링 |
| 코딩 주체 | 사람 | AI 에이전트 |
| 밤샘 대상 | 개발자 | AI (개발자는 퇴근) |
| 품질 보증 | 코드 리뷰 | AI 간 133회 문답 + 70% 테스트 코드 |
| 핵심 역량 | 코딩 스킬 | 설계 능력 + AI 환경 설계 |
반면 실패 사례도 있었어요. 한 팀은 진행 중에 스펙을 급하게 확장하고 워크트랙 3개를 병렬로 실행했다가, 배포가 중단되고 이상 루프에 빠졌어요. 결국 코드를 직접 수정해야 했고요. AI 에이전트에게 명확한 설계 없이 과도한 자율성을 부여하면 오히려 역효과가 난다는 걸 보여준 사례예요.
3등 팀은 또 다른 접근을 보여줬어요. 비용 최적화에 집중해서, 비싼 모델에서 저렴한 모델로 전환하면서도 동일한 성능 지표를 달성했어요. AI 에이전트 시대의 경쟁력이 단순히 "가장 좋은 모델 쓰기"가 아니라 "같은 결과를 더 효율적으로 만들기"에도 있다는 증거예요.
과거 1인 개발자가 비즈니스를 스케일업하는 데는 분명한 한계가 있었지만 이번 랄프톤을 통해 그 장벽이 완전히 무너졌음을 확인했다.
— 장동욱, 카카오벤처스 이사
팀어텐션의 정구봉 개발자도 "AI를 도구로 쓰는 단계를 넘어, AI 에이전트 활용법을 얼마나 깊게 내재화하느냐가 기업의 진정한 해자(moat)가 될 것"이라고 말했어요.
핵심만 정리: 시작하는 법
랄프톤이 보여준 건 결국 "하네스 엔지니어링"의 실전이에요. 개발자가 직접 코드를 짜는 대신, AI 에이전트가 제대로 일할 수 있는 환경을 설계하는 거죠. 당장 시작할 수 있는 단계를 정리했어요.
- PRD(제품 요구 문서)부터 정교하게 쓰기
랄프톤 우승팀의 성공 비결은 "키보드를 안 만진 것"이 아니라 "설계 문서를 극도로 정교하게 쓴 것"이에요. AI 에이전트에게 넘기기 전에, 요구사항의 모호성을 최대한 제거하세요. "이런 식으로도 해석될 수 있지 않나?"라는 질문이 나오면 문서가 아직 부족한 거예요. - AI 에이전트 간 검증 루프 설계하기
우승팀이 133회 문답을 시킨 이유가 있어요. 에이전트 하나가 코드를 쓰면, 다른 에이전트가 "이게 스펙에 맞나?"를 검증하는 루프를 만들어야 해요. Claude Code의 CLAUDE.md에 검증 규칙을 넣거나, CI/CD 파이프라인에 자동 테스트를 연결하는 것부터 시작하세요. - 테스트 코드를 먼저 쓰게 시키기
"본 코드 먼저, 테스트는 나중에"가 아니라 "테스트 먼저, 본 코드는 그 다음"으로 순서를 바꾸세요. 우승팀 코드의 70%가 테스트였다는 건 우연이 아니에요. AI 에이전트가 자기 결과물을 스스로 검증할 수 있는 기준을 먼저 만들어주는 거예요. - 스펙 변경은 최소한으로, 병렬은 신중하게
실패한 팀의 교훈이에요. 진행 중 스펙 확장과 무분별한 병렬 실행은 AI 에이전트를 혼란에 빠뜨려요. 하나의 명확한 워크트랙을 끝까지 밀고 가는 게 낫습니다. - 하네스 엔지니어링을 팀 자산으로 축적하기
CLAUDE.md, MCP 서버 설정, 검증 스크립트 — 이런 걸 개인 환경이 아니라 레포에 커밋하세요. 다음 프로젝트, 다음 팀원이 같은 하네스를 쓸 수 있어야 복리 효과가 생겨요.
하네스 엔지니어링이란?
프롬프트 엔지니어링 → 컨텍스트 엔지니어링 → 하네스 엔지니어링으로 진화하고 있어요.
프롬프트 = "무엇을 물어볼까"
컨텍스트 = "무엇을 보여줄까"
하네스 = "AI가 작동하는 전체 환경(스캐폴딩, 제약, 검증 루프)을 어떻게 설계할까"
랄프톤은 이 하네스 엔지니어링을 해커톤이라는 극한 환경에서 실증한 사례예요.
