카카오벤처스 심사역이던 글쓴이는 후원 조건으로 '참가자'가 되어 랄프톤에 뛰어들지만, 비개발자로서 도구와 개념을 제대로 모르고 시작해 연속 실패를 겪습니다. 이후 멘토들의 도움으로 랄프(반복 실행 루프)의 핵심은 '구체적인 요구사항 + 구체적인 종료조건(검증)' 임을 깨닫고, 팀을 꾸려 '경찰과 도둑' 방식의 검증 루프 아이디어로 프로젝트를 완주합니다. 삽질 끝에 얻은 결론은, AI 코딩 시대에도 완벽함·깊이·지구력은 여전히 비싸고 희소한 자원이며, 개발자 도구 시장과 투자 판단 기준도 함께 변하고 있다는 것입니다.

1. 프롤로그: "앤이 이번엔 참가자로 나가보면 어때요?" 😅

카카오벤처스는 2026년 기준으로 AI를 잘 쓰는 해커 커뮤니티에 주목하고 있었습니다. '바이브 코딩'이 보편화되어도 비개발자와 개발자 사이의 활용 격차가 여전히 크고, 비개발자는 CLI 환경 진입부터 막히는 일이 많기 때문입니다.

그러던 중 글쓴이는 커뮤니티를 직접 만나보기로 하고 구봉님을 만났고, 구봉님이 컨셉이 강한 해커톤 '랄프톤'을 열 계획이라며 후원 및 참여를 제안합니다. 첫 랄프톤 때는 개인 사정으로 불참했지만, 회사 팀원들이 심사(Judge)로 활약하며 후원을 이어갔고, 랄프톤이 흥행하자 다음에도 후원을 결정합니다. 대신 이번에는 조건이 붙습니다.

'앤이 이번엔 참가자로 나가보면 어때요?'

그렇게 글쓴이는 심사만 하던 사람에서, 갑자기 '빌더'가 되어야 하는 사람이 됩니다. 준비 기간은 3주였지만 체감상 해커톤이 코앞이었고, 본인이 할 수 있는 건 "OMC에 자연어로만 시키는 것"뿐이었다고 고백합니다(OMC는 비개발자에게 빠른 '와우 모먼트'를 주는 도구라고 강조합니다).

2. 랄프톤의 규칙: "2시간 스펙, 5시간은 손 떼라" 🧤

글쓴이가 이해한 랄프톤은 일반 해커톤과 달랐습니다. 스펙(요구사항)을 2시간 동안 짜고, 나머지 5시간은 랄프가 돌아가는 시간이라 "손을 떼야" 합니다. 중간에 랄프가 멈추면 스펙을 잘못 짠 것이고, 컴퓨터를 만지면 가재옷 벌칙이 있습니다.

그래서 글쓴이는 목표부터 엇나간(?) 결심을 합니다. 수상보다 중요한 건 이것이었다고요.

랄프를 멈추지 않고 돌려야 한다. 적어도 3–4시간은.

아예 목적(좋은 결과물)보다 수단(랄프를 오래 돌리기)이 앞서버린 상태로, 본격 삽질이 시작됩니다.

3. "제 랄프가 있었는데요, 없었습니다" — 도구 설치부터 연속 실패 💥

문제는 글쓴이가 랄프를 어떻게 돌리는지조차 몰랐다는 것입니다. 브라이언(장동욱 상무)과의 대화창에는 이해 못할 깃헙 링크만 쌓였고, "일단 깔고 써보라"는 말에 다음 플러그인부터 설치합니다.

• Ouroboros: 첫 랄프톤 수상작 기반의 랄프 도구 모음
• Oh-my-claudecode(OMC): 비개발자를 위한 클로드코드(Claude Code) 플러그인 모음

그런데 OMC로 "몸 풀기" 삼아 시도한 주주총회 업무 자동화가 이틀 내내 계속 터집니다. 메일 분류부터 의안 판단까지 계속 실패하고, 글쓴이는 "이러다 랄프톤 나가면 망신만 당하겠다"는 위기감을 느낍니다.

이때 브라이언이 도움을 구하러 간 'XX'의 정체는, 전(前) 카카오벤처스 심사역이기도 한 댄 이시다(홍남호 대표)였습니다. 댄은 주주총회 자동화가 어려운 이유를 단칼에 짚습니다.

"주주총회 자동화는 진짜 예외 케이스가 많아서 어려울 수밖에 없어요."

이 대화를 통해 글쓴이가 얻은 첫 결론은 단순합니다.

"진작 물어가면서 했어야 했다."

4. D-2 밤 10시, 랄프 과외의 '혈 뚫리는 순간' ⚡

해커톤 이틀 전 금요일 밤, 글쓴이는 댄에게 줌으로 긴급 과외를 요청합니다. 여기서 글쓴이는 스스로의 "비개발자다운 실수"를 공개하는데, 내용이 꽤 치명적입니다.

• 숨김 처리된 .claude 디렉토리를 굳이 작업 디렉토리로 잡아놓고 저장
• 디렉토리를 /user/로 대충 지정한 뒤, 부정확한 파일명을 말해놓고 AI가 전 디렉토리를 뒤지는 동안 멍하니 기다림

댄은 도구의 원리(디렉토리 기반 동작)를 모르는 상태에서 AI에게 "전국을 뒤져서 현관문 고쳐라"라고 시키는 꼴이라며, 비유로 정확히 꽂아줍니다.

"앤은 AI에게 '서울시 XX동 @@아파트 101동 302호 현관문 고장 해결해줘' 해야 하는데,
'대한민국인데 저 현관문 좀 고쳐줘'라고 시키고 있는 거예요."

즉 글쓴이는 클로드코드의 작동 원리도, 랄프의 전제도 모른 채 환상을 가지고 있었고, 그래서 실패 루프에 갇혀 AI 개발 효용성 자체에 염증이 날 뻔합니다.

그리고 랄프에 대한 가장 중요한 교정이 들어갑니다. 랄프는 "만능 해결사"가 아니라, 결국 이런 성격이라는 겁니다.

• 랄프는 똑똑한 해결사가 아니라 "될 때까지 반복하라"는 아주 단순한 루프
• 그래서 반드시 필요한 조건 2가지가 있음
  1. '주어진 일'을 매우 구체적으로 정의
  2. '될 때까지(종료 조건)'를 매우 구체적으로 정의

글쓴이는 자신이 "5층 빌라를 마이너스 옵션으로 대충" 지어달라고 해놓고, 랄프가 15분 만에 날림 결과물을 가져온 상황이었다고 인정합니다.

5. "나 혼자 나갔다간 큰일난다" — 팀원 제이든 합류 🤝

랄프를 반쯤 이해하고 나니, 또 다른 현실이 보입니다. 혼자서는 위험하다는 직감입니다.

'나 혼자서 나갔다간 큰일난다.'

주변을 수소문하던 중 사무실에서 제이든(김명준, 딥테크팀 인턴)을 발견하고 D-3에 함께 나가자고 제안합니다. 제이든은 "일요일 백수"라는 답으로 합류를 확정하고, 시작부터 클로드코드 결제 플랜을 올리며 4시간 랄프 성공까지 해냅니다. 글쓴이는 이 합류 자체가 생존의 분기점이었다는 뉘앙스로 묘사합니다.

6. 무엇을 만들 것인가: 사주봇 vs 세컨드 브레인, 그리고 '각하' 🧠

이제 핵심은 "무엇을 만들지"입니다. D-1에 영택님의 도움까지 받아 마지막 과외 겸 아이데이션을 하지만, 팀 내 의견이 갈립니다.

• 글쓴이: 부동산 사주 앱(풍수/사주/자미두수/별자리 교차검증 등)
• 제이든: 세컨드 브레인(업무 비서, 데이터 통합/정리/알림)

글쓴이는 특히 API 연동 자동화에 대해 "예외 케이스 대응하다가 끝나는 거 아니냐"는 PTSD가 있었지만, 밤 12시 무렵 결국 다시 댄에게 묻습니다.

"사주 봇 만들까요? 세컨브레인 만들까요?"

댄의 답은 단호했습니다.

"사주 봇은 기각하세요… 한 시간도 안 돌아갈 거예요."

이 한마디로 방향이 정리되고, 세컨드 브레인 쪽으로 기울게 됩니다.

7. 핵심 아이디어 등장: 랄프 ver. "경찰과 도둑" (검증 루프 혁신) 👮‍♂️🦹‍♂️

제이든이 작성한 세컨드 브레인 스펙은 Slack/Google Calendar/Notion/Gmail을 엮어 개인 비서를 만들고, 슬랙 DM으로 정보를 전달하며, 여러 에이전트로 테스트케이스를 촘촘히 검증하는 형태였습니다.

하지만 글쓴이는 여전히 불안합니다. 특히 "이게 실제로 도움이 됐는지"를 어떻게 검증할지가 अस्प명확했고, 심사역이 정답지(골든 데이터셋)를 만들어 주기도 싫고 시간도 없었습니다.

이때 댄이 던진 아이디어가 글의 하이라이트입니다.

"랄프로 경찰과 도둑을 시켜보자.
한 에이전트는 방어(도둑), 한 에이전트는 공격(경찰)해서
둘이 합의에 이를 때까지 반복하면 퀄리티가 개선되지 않을까?"

즉, 적대적 구조로 검증을 강화하는 방식입니다(글은 GAN의 적대적 공격에서 영감을 받았다고 설명). 팀은 이 "경찰과 도둑" 검증 루프를 프로젝트의 중심 주제로 삼고 새벽 2시에 잠듭니다.

8. 해커톤 당일: "랄프해가 밝았습니다… 비개발자는 눈을 뜨고 서로를 확인" 😨➡️🙂

글쓴이는 "시민 속에 섞여든 마피아" 같은 마음으로 행사장에 도착합니다. 참가자가 50명 이상으로 보일 만큼 규모가 커져 있었고, 혼자 왔으면 큰일 날 뻔했다며 다시 제이든에게 고마워합니다.

둘은 앉자마자 requirements(요구사항)를 최대한 구체화합니다.

• 제이든: 모호성 제거 중심
• 글쓴이: 심사역 워크플로우의 예외 상황(엣지 케이스) 반영
• 검증 시나리오(경찰/도둑)도 더 정교화
• .env의 API 키 세팅도 재확인

Ouroboros 인터뷰로 requirements를 넣자, 도구가 매기는 모호도 점수가 "우리가 본 것 중 최저"로 나옵니다. 그리고 랄프가 한 시간 넘게 잘 돌아가며 둘은 잠시 희망회로를 돌립니다.

팀 이름도 정합니다: 비버와 사육사.

9. 대형 사고: "랄프는 안 멈춰요, 근데 랩탑이 멈춰요…" 🧯

그런데 이번엔 랄프가 아니라 노트북이 멈춥니다. 랄프가 돌 때마다 응용 프로그램 메모리가 90GB까지 치솟고 랩탑이 꺼집니다. 켜도 30분 돌다가 다시 다운되는 일이 반복됩니다.

결국 팀은 랩탑이 4번 다운되며 "가재옷 신청 최다 팀"이 되는 불명예(?)까지 얻고, "이걸로라도 어그로를 끌었다"고 자기합리화합니다.

문제가 해결되지 않자, 글쓴이는 Ouroboros 제작자 재규님에게 달려가 도움을 요청합니다. 이것저것 시도했지만(메모리 초과 시 중지 조건, 병렬 중단 등) 말을 듣지 않았고, 원인은 의외로 단순했습니다.

• 첫 실행에서 병렬 실행 변수를 선언해버리면
• 중간에 "순차 실행(sequential)으로 바꿔달라"고 해도
• 계속 에이전트들이 병렬로 돌아가며 메모리를 터뜨린다

해결책은 세션을 재시작하고 순차 실행으로 다시 돌리는 것이었습니다. 이때 시간이 4시 반. 제이든은 사실상 포기 상태로 커피를 사러 나갑니다.

그런데 돌아와 보니, 갑자기 구현이 되어 있습니다. 슬랙봇을 켜보니 "돌아갑니다."

결국 팀은 급히 버그를 고치고 깃헙에 발표 자료와 코드를 푸시해 6시에 완주합니다.

10. 반전: "빈집에서 경찰과 도둑을 1800번 했다" 🫠

완주 후에야 냉정하게 확인해보니, 경찰과 도둑 프레임워크가 실제 데이터가 아니라, 봇이 생성한 테스트 데이터 안에서만 열심히 싸운 상태였습니다.

"빈 집에서 경찰과 도둑을 천 팔백번을 했다…."

즉 requirements에 스모크 테스트(실환경 최소 검증)를 못 박지 못한 것이 결정적 실수였습니다.

다만 사후적으로 실제 봇을 활성화한 뒤 발생한 7개 버그를 바탕으로 "경찰/도둑 에이전트가 해결 가능한 시나리오인가"를 다시 물어보니, 대체로 해결 가능했고 결론적으로는 의미가 있을 수 있다는 수준의 확신을 얻습니다.

11. 랄프톤이 준 가장 큰 선물: '인지 부하'와 '초심'에 대한 재발견 🎁

글쓴이가 이런 삽질기를 공개하는 이유는, 실패담을 자랑하려는 게 아니라 다음을 남기기 위해서라고 정리됩니다.

• AI 코딩의 현실에 부딪힌 비개발자들에게 "나도 못했지만 완주했다"는 용기
• 해커 커뮤니티, 담론, 투자 미래에 대한 고민을 짧은 기간(3일) 동안 급성장한 생각으로 기록

11-1. 개발의 인지 부하 vs 사업화의 인지 부하

글쓴이는 "개발은 쉬워졌고 아이디어가 비싸졌다"는 말에 공감하면서도, 직접 랄프를 최적화해보니 사업 용어(KSF, 시장 사이즈, 해자)가 낯설어질 정도로 개발에 뇌 용량이 빨려 들어갔다고 말합니다. 즉 AI 시대에도, 혹은 AI 시대이기 때문에 더더욱 아키텍처·오픈소스·검증 설계가 큰 인지 부하라는 겁니다.

그러면서도 결국엔 변명으로만 둘 수 없다는 쪽으로 생각이 수렴합니다. 사업이든 엔지니어링이든 깊게 고민하는 사람들은 둘 다 해내며, 다만 "하나만 잘하기도 정말 어렵다"는 현실을 인정합니다. 그래서 중요한 건 개인이든 팀이든 '소화 가능한 인지 부하 총량'을 키우는 것이라고 정리합니다(컨디션 관리, 함께할 사람 영입 등).

글의 문장을 한국어로 옮기면, 핵심 선언은 이렇습니다.

아이디어는 여전히 싸다. 코드는 점점 싸진다. 토큰도 점점 싸진다.
하지만 완벽함은 언제나 비쌌다. 깊이는 언제나 비쌌다. 지구력은 언제나 희소했다.

11-2. 개발자 도구 PMF는 아직 진행 중

글쓴이는 가까운 시기(글 기준 "6개월 내")에는 여전히 개발자 도구 중심의 PMF가 유지될 거라고 봅니다. 이유는 AI 앱을 만드는 빌더들이 감당해야 하는 인지 부하가 크고, 기획자가 바이브코딩에 깊게 들어가기엔 스트레스 포인트가 명확하기 때문입니다. 그래서 교육/온보딩 형태의 사업 기회도 보인다고 덧붙입니다.

11-3. "깃헙의 빌보드화"와 투자 환경의 변화

랄프톤 우승자와의 대화를 통해, 글쓴이는 오픈소스가 "좋은 의미의 레버리지"로 작동하는 흐름을 강하게 느낍니다. 바이브코딩이 퍼지며 깃헙이 대중화되고, 깃헙 스타가 개발자의 유명세를 만드는 경로가 되면서, 글쓴이는 이를 Social Git Capital 같은 개념으로 설명합니다.

동시에 초기 투자자(VC) 입장에서는 "스타 많은 오픈소스만 보고 투자"하는 체계를 만들기 어렵고, 심사역도 직접 헤비하게 써보고 만들어봐야 판단력이 생긴다고 말합니다. 2012년엔 '사람만 보고' 투자했다면, 2026년엔 사람 + 그 사람의 깃헙까지 보는 시대가 됐다는 자각으로 이어집니다.

11-4. 심사역으로서의 초심 회복

마지막으로 글쓴이는 해커톤 하루 동안(9시~6시) 만들기에 급급했지만, 오랜만에 "살아있음"을 느꼈다고 말합니다. 개발자들이 해커톤 티셔츠를 입고 스티커를 붙이는 이유도, 그게 노력과 열정의 아티팩트라서 이해됐다고요.

또한 빌더가 되어보니 결과물에 애착이 쉽게 생기고, 그 애착이 큰 만큼 심사역으로서 질문할 때도 "훼손하는 검증"이 아니라 순수한 호기심으로 다가가야 한다는 반성을 남깁니다.

글쓴이가 끝에 남긴 메시지는, 회의적인 생각이 들 수 있음을 인정하면서도 결국 이 한 줄로 모입니다.

"사람이 잘하고 싶게 하는 원동력은 먼 곳에 있지 않더라.
AI에게도 가려지지 않는 순수한 열정의 합!"

12. 마무리

이 글은 "비개발자 심사역이 랄프톤에서 빌더로 살아남은 과정"을 시간순으로 따라가며, 랄프의 본질이 '반복'이 아니라 '구체적 지시 + 구체적 검증'에 있음을 반복해서 보여줍니다. 동시에 직접 만들어본 경험을 통해, AI 시대에도 여전히 비싼 자원이 완벽함, 깊이, 지구력이라는 점과, 개발자 도구/오픈소스/투자 판단 기준이 바뀌는 흐름을 생생하게 정리한 회고록입니다.