AI가 밤새 코딩하는 해커톤, 랄프톤

---

요즘은 함수 하나 짜달라고 하면 테스트까지 붙여서 돌려주는 장면을 하루에도 몇 번씩 봅니다.

처음엔 신기했습니다. 프롬프트를 넣으면 함수가 나오고, 컴포넌트가 나오고, API 코드가 나왔습니다. 조금 지나자 AI는 테스트 코드도 만들고, 오류도 고치고, 문서도 정리하기 시작했습니다.

그러다 보니 질문이 조금씩 바뀌었습니다.

"그러면 사람은 무엇을 해야 하나?"

랄프톤(Ralphthon)은 이 질문을 꽤 직접적으로 보여준 AI 해커톤입니다.

사람이 밤새 코딩하는 해커톤이 아니라, 사람이 초반에 문제를 정의하고 설계한 뒤 AI가 밤새 코딩하는 해커톤입니다.

사람은 잡니다. AI가 일합니다. 다음 날 아침, 사람은 결과물을 확인하고 데모합니다.

장난처럼 들릴 수 있지만, 이 행사에서 보이는 변화는 꽤 현실적입니다. AI 시대에 개발자, 기획자, 창업가의 역할이 어디로 옮겨가는지를 보여주기 때문입니다.

해커톤은 원래 사람의 실행력을 보여주는 자리였다

해커톤은 겉으로 보면 밤새 코딩하는 행사입니다.

하지만 실제로는 제한된 시간 안에서 사람이 어디까지 문제를 이해하고 결과물을 만들 수 있는지 보여주는 방식에 가깝습니다. 짧은 시간에 팀을 만들고, 아이디어를 정리하고, 역할을 나누고, 구현하고, 발표 가능한 형태까지 끌고 가야 합니다.

그 안에서 평가되는 건 코드 작성 능력만이 아닙니다. 무엇을 해결할지 정하는 문제 정의, 제한된 시간에 맞게 크기를 줄이는 범위 조절, 누가 무엇을 맡을지 나누는 역할 분담, 아이디어를 동작하는 형태로 만드는 구현력, 그리고 결과물을 남에게 이해시킬 수 있게 정리하는 발표까지 한꺼번에 드러납니다.

그래서 해커톤의 밤샘은 상징적이었습니다. 잠을 줄이고 에너지를 몰아넣어, 제한된 시간에 사람이 어디까지 만들 수 있는지를 증명하는 방식이었기 때문입니다.

그동안 해커톤의 주인공은 사람이었습니다. 사람이 문제를 정의하고, 코드를 작성하고, 버그를 고치고, 마지막 발표를 준비했습니다.

랄프톤은 이 구조를 뒤집는다

랄프톤이 하는 일은 간단합니다.

사람이 밤새 구현하는 대신, AI가 밤새 구현합니다. 사람은 초반에 제품 아이디어, 요구사항, 작업 구조, 검증 조건을 준비합니다. 그 뒤에는 AI 에이전트가 장시간 자율적으로 작업할 수 있는 환경을 만듭니다.

구분	내용
공식 명칭	AI Builders 4th Ralphthon
주최	Team Attention, Kakao Ventures
후원	OpenAI
일정	2026년 2월 28일 ~ 3월 1일
참가 규모	9팀 13명, 8팀 완주
진행 규칙	사람이 노트북을 넘긴 뒤 AI 에이전트가 밤새 작업
공식 설명	"AI agents run overnight while you sleep"

공식 일정에도 이 구조가 드러납니다. 저녁 8시에 laptop handoff가 있고, 그 뒤로는 노트북 사용이 금지됩니다. 사람은 쉬거나 자고, AI가 밤새 코드를 쓰고 테스트를 만들고 오류를 고칩니다. 다음 날 아침 결과물을 확인하고 발표합니다.

이 문장만 보면 사람의 일이 줄어든 것처럼 보입니다. 하지만 실제로는 반대에 가깝습니다.

사람이 옆에서 계속 고쳐줄 수 없기 때문에, 초반 설계의 밀도가 훨씬 중요해집니다.

코딩 속도가 아니라 위임 구조가 성과를 가른다

랄프톤을 "AI가 사람 대신 코딩한 행사"로만 보면 정작 봐야 할 것을 놓치기 쉽습니다.

더 앞에 두어야 할 질문은 이것입니다.

AI가 사람 없이도 계속 앞으로 가게 하려면, 사람은 처음에 무엇을 설계해야 하는가?

일반 해커톤과 랄프톤의 차이는 이렇게 볼 수 있습니다.

기존 해커톤	랄프톤
사람이 밤새 구현한다	AI가 밤새 구현한다
오류가 나면 사람이 바로 개입한다	오류를 스스로 찾고 복구할 구조가 필요하다
중간에 방향을 계속 바꿀 수 있다	초반 설계가 틀리면 밤새 틀어진다
실행력이 크게 드러난다	위임 구조 설계 능력이 크게 드러난다
"얼마나 잘 만들었나"를 본다	"사람 없이도 AI가 얼마나 전진했나"도 본다

AI는 이미 정의가 끝난 문제에서는 빠릅니다. 무엇을 만들어야 하는지, 어떤 입력과 출력이 필요한지, 어떤 조건을 만족해야 하는지, 실패했을 때 뭘 고쳐야 하는지가 명확할 때 강합니다.

반대로 문제가 흐릿하면 AI도 흔들립니다. 그럴듯한 결과물은 만들 수 있지만, 방향이 맞는지는 보장하기 어렵습니다.

여기서 사람의 역할이 드러납니다.

무엇을 만들지, 왜 만드는지, 사용자에게 실제로 필요한지, 어디까지 만들면 완료로 볼지를 정하는 일입니다.

한 문장으로 줄이면 이렇습니다.

AI는 실행에 강하고, 사람은 방향과 기준을 정해야 합니다.

랄프톤의 1등과 2등이 보여준 것

많은 사람이 주목한 부분은 1등과 2등 사례입니다. 공식 페이지에는 두 팀 모두 "Lobster crawl 0 times"로 기록되어 있습니다. 중간에 사람이 손을 대지 않고, AI가 자율 실행으로 결과물을 만들었다는 의미입니다.

순위	팀 / 프로젝트	기록	결과물
1등	houseops / Ouroboros	12.8시간 자율 실행, 5 commits, 169,553 LOC, 65 test files	GPT-4o Vision으로 방 청결도를 판단하고, Discord 봇으로 집안일을 배정하는 시스템
2등	cyberthug-screenclone / Oh My Codex	7시간 연속 자율 실행, 76 commits, 45,522 LOC	21개 User Story를 완료하고, Live2D 캐릭터가 진행 상황을 감정적으로 리포트하는 프로젝트

1등 Ouroboros는 요구사항의 모호성을 낮추기 위해 133회 이상의 소크라틱 인터뷰를 사용했다고 소개됩니다. AI가 무작정 코드를 쓰게 한 것이 아니라, 먼저 문제를 좁히고 조건을 구체화한 뒤 실행하게 만든 것입니다.

2등 Oh My Codex는 한 번 만든 뒤 의도적으로 리셋하고, 하네스만 보존한 채 다시 생성하는 방식을 사용했습니다. 결과물을 한 번 만든 데 그치지 않고, AI가 다시 실행해도 같은 결과에 도달할 수 있는 구조를 검증한 사례로 볼 수 있습니다.

다만 코드의 양만 보면 초점을 놓치기 쉽습니다. 많은 줄을 생성했다는 사실보다 봐야 할 것은, AI가 사람 없이도 계속 진행할 수 있도록 만든 구조입니다. 문제를 어떻게 쪼개 AI가 길을 잃지 않게 했는지, 상태를 어떻게 남겨 다음 작업을 이어가게 했는지, 결과가 맞는지 판단할 검증 조건을 어떻게 뒀는지, 실패했을 때 사람 없이 어떻게 다시 시도하게 했는지 — 이런 설계가 순위를 갈랐습니다.

랄프톤은 코딩 속도 경쟁이라기보다 위임 구조 경쟁에 가깝습니다.

사람이 얼마나 오래 깨어 있었는가가 아니라, 사람이 없어도 AI가 얼마나 오래 앞으로 갈 수 있었는가를 본 것입니다.

개발자의 역할은 어디로 가는가

랄프톤이 보여주는 건 "개발자가 필요 없어진다"가 아닙니다.

오히려 개발자가 더 잘해야 하는 일이 바뀌고 있다는 쪽에 가깝습니다.

기존에는 직접 코드를 작성하는 능력이 크게 보였습니다. 하지만 AI가 구현을 빠르게 도와줄수록, 그 위에 있는 능력이 더 크게 요구됩니다.

이전에 크게 보이던 능력	앞으로 더 크게 요구되는 능력
직접 코드를 빠르게 작성하기	무엇을 만들지 정확히 정의하기
구현 중 생기는 문제를 즉시 고치기	AI가 혼자 진행할 수 있는 작업 구조 만들기
기능 단위로 개발하기	요구사항, 권한, 데이터, 상태, 예외를 함께 설계하기
결과물을 눈으로 확인하기	테스트와 검증 기준으로 맞는 결과인지 판단하기
도구를 잘 다루기	도구가 일할 수 있는 조건을 정확히 만들기

예를 들어 "어드민 페이지 만들어줘"라고만 하면 AI는 그럴듯한 화면을 만들 수 있습니다.

하지만 실무에서는 그걸로 부족합니다. 어떤 데이터를 볼지, 누가 접근할 수 있는지, 필터 조건은 무엇인지, 다운로드 범위는 어디까지인지, 개인정보는 어떻게 제외할지 같은 기준이 필요합니다. 다운로드 기능도, 대시보드도, 테스트도 마찬가지입니다. 다운로드라면 범위·권한·파일 형식·개인정보 제외 조건을, 대시보드라면 어떤 지표가 운영 판단에 필요한지와 기준일·집계 방식을, 테스트라면 반드시 잡아야 할 실패와 성공 조건을 먼저 정해줘야 합니다.

AI가 빠르게 실행할수록, 잘못된 방향으로도 빠르게 달릴 수 있습니다. 그래서 사람이 할 일은 더 또렷해집니다.

문제를 정의하고, 작업을 쪼개고, 기준을 세우고, 나온 결과가 맞는지 판단하는 일입니다.

이걸 못하면 AI는 생산성을 주는 도구가 아니라, 검토할 코드와 정리할 혼란을 늘리는 도구가 되기 쉽습니다.

실무에서는 무엇이 달라질까

랄프톤은 해커톤 사례지만, 이 변화는 실제 서비스 개발에서도 이어집니다.

AI가 랜딩 페이지든 어드민이든 테스트 코드든 빠르게 뽑아도, 그게 전환을 만드는지, 운영 판단에 쓸모가 있는지, 중요한 실패를 잡는지는 다른 문제입니다.

그래서 앞으로의 실무 능력은 조금 더 복합적이 됩니다. 무엇이 진짜 문제인지 읽는 감각, 그 문제를 AI가 처리할 단위로 쪼개는 능력, 모호하지 않게 요구사항을 쓰는 능력, 긴 작업에서 AI가 길을 잃지 않게 컨텍스트를 관리하는 능력, 결과가 맞는지 판단할 기준을 만드는 능력, 그리고 실제 운영 가능한 수준으로 복잡도를 조절하는 능력입니다.

AI 시대의 생산성은 도구 자체만으로 결정되지 않습니다.

AI가 일할 수 있는 조건을 얼마나 정확하게 만들어두었는가에서 갈립니다.

정리

랄프톤은 특이한 해커톤처럼 보입니다.

사람은 자고, AI가 코딩합니다.

하지만 이 행사가 보여준 장면은 꽤 현실적입니다. 이미 많은 개발 현장에서 AI는 코드를 쓰고, 화면을 만들고, 테스트를 제안합니다.

이제 차이는 "AI를 쓰는가"가 아니라 "AI에게 어떤 방식으로 일을 맡기는가"로 옮겨가고 있습니다.

앞으로 개발자에게 더 무거워질 질문은 이런 것들입니다. 무엇을 해결할 문제로 정의할 것인가, 그 문제를 어떤 순서로 나눌 것인가, 어디까지 AI에게 맡길 것인가, 그리고 결과가 맞는지 어떻게 검증할 것인가. 실행보다 판단 기준이 더 무거워지는 방향입니다.

AI가 밤새 코딩하는 시대에는 사람의 일이 사라지는 게 아닙니다.

사람의 위치가 바뀝니다.

코드를 직접 치는 사람에서, 문제를 정의하고 방향을 잡고 검증 기준을 세우는 사람으로.

랄프톤을 흥미롭게 봐야 하는 이유는 여기에 있습니다.

참고

• Team Attention, Ralphthon | AI Builders 4th