Google Developer Group 해커톤 1등 회고

2026년 8월 29일 열린 2026 I/O Extended: Hack the Beat에 4인큐라는 팀으로 참가했다.

이번 해커톤에는 사람 심사위원이 없었다.

우리가 만든 서비스에 접속해 실제 기능을 확인하고, 기획과 비즈니스 가능성까지 평가하는 것도 AI Agent였다.

팀은 네 명이었다.

• 백지훈
• 서새찬
• 홍의민
• 이예람

개발자 세 명과 디자이너 한 명으로 구성되어 있었지만, 기획자와 개발자처럼 역할을 완전히 나누지는 않았다. 네 명이 같이 기획했고 각자 필요한 작업에 Agent를 붙였다.

사용한 도구도 하나가 아니었다.

Antigravity, Gemini CLI, Claude Code를 섞어서 사용했다.

그런데 이번 대회에서 기억에 남은 것은 Agent가 코드를 얼마나 많이 작성했느냐가 아니었다.

심사 기준을 바탕으로 우리만의 심사 Agent를 만들고, 실제 심사를 받기 전에 계속 평가받았던 과정이었다.

결과적으로 25팀 중 1등을 했다.

심사위원이 AI인 해커톤

이번 대회의 주제는 상당히 넓었다.

Make the Party Better 파티를 더 잘 즐길 수 있는 서비스를 만들어라.

처음 주제만 봤을 때는 범위가 너무 넓다고 느꼈다.

무슨 기술을 써야 하는 것도 아니고, 어떤 문제를 해결해야 하는 것도 아니었다. 파티라는 상황 안에서 문제부터 직접 찾아야 했다.

대신 다른 대회와 달리 평가 규칙이 굉장히 구체적으로 공개되어 있었다.

심사 영역은 크게 세 가지였다.

여기에 D. 주제 적합성이 별도로 존재했다.

D는 단순 가산점이 아니었다.

A, B, C로 얻은 점수에 다시 배율을 적용하는 구조였다.

즉 파티라는 주제를 억지로 끼워 넣었다고 판단되면 앞에서 받은 점수 자체가 깎였다.

더 특이했던 것은 채점 방식이었다.

Google Developer Group에서 독자적으로 개발한 창업가, 엔지니어, 투자자 역할의 AI 심사관 세 명이 12개 항목을 각각 세 번씩 평가하고, 항목별 중앙값을 사용한 뒤 세 페르소나의 결과를 다시 합산했다.

그리고 A 영역은 문서만 읽고 판단하지 않았다.

심사 Agent가 Playwright를 이용해 우리가 제출한 배포 URL에 직접 접속했다.

우리가 제출한 3단계 테스트 시나리오를 실제로 수행하고, 기능이 정말 동작했는지를 기준으로 점수를 매겼다.

기획안에 기능이 있다고 적어놓는 것만으로는 부족했다.

실제 브라우저에서 확인할 수 없다면 관련 항목의 점수에 상한이 걸리는 규칙도 있었다.

이때 생각이 조금 달라졌다.

처음에는 2시간 30분 안에 무엇을 최대한 많이 만들지를 고민했다.

그런데 루브릭을 읽다 보니 그보다 먼저 해야 할 일이 보였다.

무엇을 만들면 점수를 받는지부터 정확히 이해해야 했다.

2시간 30분 중 약 1시간을 기획에 썼다

개발에 주어진 시간은 약 2시간 30분이었다.

시간만 보면 최대한 빨리 아이디어를 하나 고르고 구현에 들어가는 것이 맞아 보였다.

그런데 우리는 반대로 갔다.

약 1시간 가까이를 기획에 사용했다.

물론 네 명이 한 시간 동안 화면만 보고 회의한 것은 아니었다.

우리 팀은 이전부터 여러 대회와 프로젝트를 같이 해왔다. 2년가까이 호흡을 맞췄던 팀이라 서로 어떤 방식으로 일하는지 잘 알고 있었다.

개발 환경을 처음부터 손으로 만드는 상황도 아니었다.

기존에 개발해서 사용하던 프로젝트 초기화·배포 자동화 도구인 project-auto-wizard가 있었고, 이를 이용해 Spring Boot 프로젝트와 NAS·Cloudflare 기반 배포 환경 세팅 같은 작업을 기획과 병렬로 진행했다.

대략 이런 식이었다.

프로젝트 초기화 / DB / 배포 환경
              │
              └──── Agent + 기존 자동화로 병렬 진행

공식 루브릭 분석
        ↓
아이디어 검토
        ↓
심사 항목과 대조
        ↓
기능 구체화
        ↓
PRD 작성

시간이 짧았기 때문에 오히려 기획을 자세히 해야 한다고 판단했다.

이번 심사에서는 기획안과 구현이 다르면 감점을 받았다.

기획안에서 많은 것을 약속하고 구현하지 못하는 것도 좋지 않았고, 반대로 열심히 구현했지만 심사 기준과 관련 없는 기능이라면 제한된 시간을 낭비하는 셈이었다.

그래서 기능 하나를 추가할 때도 계속 질문했다.

이 기능은 어느 심사 항목에 대응하는가?

실제 Agent가 브라우저에서 확인할 수 있는가?

파티라는 주제와 직접적으로 연결되는가?

우리가 2시간 30분 안에 끝까지 구현할 수 있는가?

루브릭을 단순한 채점표보다는 요구사항 문서처럼 보기 시작했다.

높은 점수보다 먼저 점수 상한을 봤다

공식 루브릭에서 특히 유용했던 것은 각 항목의 10점 조건보다 어떤 경우 일정 점수 이상 받을 수 없는지가 명확하게 적혀 있다는 점이었다.

예를 들어 수익 모델에서

추후 구독 모델을 도입할 예정이다.

라고 쓰는 것만으로는 높은 점수를 받을 수 없었다.

누가 돈을 내고, 언제 내고, 얼마를 내는지를 구체적으로 설명해야 했다.

시장 규모도 마찬가지였다.

큰 시장 조사 자료 하나를 가져와서

관련 시장은 수조 원 규모다.

라고 적는 것만으로는 부족했다.

도달 가능한 사용자 수와 사용 빈도, 단가 등을 이용해서 우리 서비스 기준으로 시장을 계산해야 했다.

GTM도

SNS 바이럴을 진행한다.

정도로는 부족했다.

어디에서 첫 사용자를 만날 것인지, 누가 실행할 것인지, 언제 실행할 것인지까지 구체화해야 했다.

반대로 우리는 해커톤 현장에서 실제 사용자 인터뷰까지 진행하지는 않았다.

따라서 실제 관찰이나 사용자 대화가 있어야 상한을 풀 수 있는 B1 같은 항목은 완벽하게 채울 수 없었다.

없는 근거를 만들어내기보다는 그 점수는 감수하기로 했다.

모든 항목에서 10점을 받겠다는 전략이 아니라, 짧은 시간 안에 실제로 증명 가능한 부분을 최대한 높이는 전략에 가까웠다.

실제 심사를 받기 전에 심사 Agent를 만들어보기로 했다

심사 방식이 이 정도로 공개되어 있으니 자연스럽게 다음 생각으로 이어졌다.

실제 심사를 기다릴 필요가 있나?

실제 심사 Agent에 사용되는 프롬프트는 공개되지 않았다.

따라서 행사에서 사용하는 Agent를 그대로 복제하는 것은 불가능했다.

하지만 사용할 수 있는 정보는 많았다.

• 공식 루브릭 12개 항목
• 각 항목의 배점
• 0점, 5점, 10점의 기준
• 점수 상한 조건
• 창업가, 엔지니어, 투자자라는 심사관 역할
• 운영진이 설명한 심사 방식

이 자료를 토대로 실제 심사 Agent가 어떤 관점으로 우리 결과물을 볼지를 추정하는 모의 심사관을 만들었다.

저장소에는 아예 다음과 같이 따로 정리했다.

docs/personas/
├── founder.md
├── engineer.md
└── investor.md

중요한 점은 단순히 프롬프트 앞에

너는 창업가야.
이 서비스를 평가해줘.

정도만 넣은 것이 아니었다는 것이다.

각 페르소나마다 어떤 것을 중요하게 보는지, 어떤 근거를 인정할지, 무엇을 감점할지까지 나눴다.

저장소에도 실제 프롬프트를 복제한 것이 아니라 공식 루브릭과 운영진 설명을 바탕으로 역설계한 추정 페르소나라고 명시했다.

창업가는 "실제로 누가 쓰는데?"를 보게 했다

창업가 Agent는 기능보다 먼저 사용자를 보도록 만들었다.

이 Agent가 계속 던지는 질문은 대략 이런 식이었다.

첫 사용자는 어디에서 데려올 것인가?

그 사람이 실제로 어떤 상황에서 불편을 겪는가?

카카오톡이나 인스타그램으로 하면 안 되는가?

다음 파티에서도 다시 사용할 이유가 있는가?

기획안에 적은 기능이 실제 제품에도 있는가?

특히 이번 주제에서는 카카오톡으로 하면 되지 않나?라는 질문이 중요했다.

파티에서 친구들을 연결하고 무언가를 공유하는 서비스는 조금만 평범하게 만들면 단체 채팅방으로 대부분 대체할 수 있었다.

그래서 기능을 추가할 때도

단순히 있으면 재미있는가?

보다

이 기능 때문에 파티라는 상황에서 별도의 제품을 사용할 이유가 생기는가?

를 더 많이 봤다.

엔지니어는 "그래서 정말 동작하나?"를 보게 했다

엔지니어 Agent는 문서보다 배포된 제품을 먼저 의심하도록 만들었다.

제출한 핵심 플로우가 처음부터 끝까지 성공하는가?

콘솔이나 네트워크 오류는 없는가?

모바일에서도 정상적으로 동작하는가?

기획안에서 주장한 기능을 실제 화면에서 확인할 수 있는가?

초대 링크를 다른 브라우저에서 열어도 동작하는가?

실제 심사 Agent가 Playwright로 배포 URL을 조작한다는 점도 반영했다.

예를 들어 사람 눈에는 버튼처럼 보이더라도 클릭 요소가 단순한 <div>라면 Agent가 버튼으로 인식하지 못할 가능성이 있었다.

아이콘 버튼에 의미 있는 텍스트나 aria-label이 없다면 어떤 버튼인지 찾기 어려울 수 있었다.

성공 결과를 3초짜리 Toast 하나로만 보여주면 심사 Agent가 결과를 확인하는 시점에는 사라졌을 수도 있었다.

결국 엔지니어 Agent에게는 두 가지를 같이 보게 했다.

사람이 사용할 수 있는가?
+
심사 Agent가 성공 여부를 검증할 수 있는가?

투자자는 숫자 없는 주장을 최대한 의심하게 했다

투자자 Agent는 사업 관련 주장을 구체화하는 데 사용했다.

이쪽은 질문이 꽤 직설적이었다.

누가 돈을 내는가?

언제 내는가?

얼마를 내는가?

시장 규모 계산식은 무엇인가?

대체재는 정확히 무엇인가?

파티 하나가 늘어날 때 서버 비용은 얼마인가?

광고, 구독, 바이럴, 큰 시장처럼 그럴듯하지만 검증하기 어려운 단어를 최대한 배제하도록 했다.

예를 들어 시장 규모를 이야기한다면 적어도 다음 형태의 계산을 요구했다.

도달 가능한 사용자
×
연간 사용 빈도
×
전환율 가정
×
가격

계산이 정확한 미래 예측이라는 뜻은 아니었다.

적어도 어떤 가정을 사용해서 그 숫자가 나왔는지는 설명할 수 있어야 한다고 봤다.

모의 심사 Agent를 기획 단계부터 넣었다

세 페르소나를 만든 다음 바로 구현에 들어간 것도 아니었다.

아이디어가 어느 정도 정리되면 PRD를 작성하고, 세 페르소나 관점으로 다시 확인했다.

아이디어
   ↓
PRD 작성
   ↓
창업가 Agent
   ↓
엔지니어 Agent
   ↓
투자자 Agent
   ↓
감점 예상 지점 수정
   ↓
구현

이 과정을 거쳐 만든 서비스가 Party Passport였다.

Party Passport는 파티에서 실제로 만난 사람을 기록하는 서비스다.

참가자는 초대 링크를 통해 들어오고, 현장에서 다른 참가자의 QR이나 코드를 태그하면서 만난 사람과 증표를 쌓는다. 파티가 끝난 뒤에는 다시 만나고 싶은 사람을 비밀리에 선택하고, 서로 선택한 경우에만 결과를 확인할 수 있게 했다.

서비스 자체에 대한 자세한 내용은 GitHub 저장소에 남겨두었다.

구현 후에는 진짜 점수를 매겼다

여기서부터 모의 심사 Agent를 만든 것이 꽤 유용해졌다.

서비스가 어느 정도 동작하기 시작하자 세 Agent에게 다시

괜찮은 것 같아?

라고 물은 것이 아니라 실제 심사표를 그대로 채우게 했다.

세 페르소나가 서로의 평가에 영향을 받지 않고 독립적으로 12개 항목을 채점하도록 했다.

그리고 점수가 많이 벌어진 항목은 우선해서 확인했다.

모의 심사 기준 평균은 6.44점이었다.

높다고 하기는 어려운 점수였다.

그런데 이 표에서 점수보다 먼저 눈에 들어온 부분이 있었다.

A2 배포·안정성이었다.

창업가  9
엔지니어 5
투자자  9

같은 결과물을 봤는데 엔지니어 혼자 네 점이나 낮게 줬다.

왜 그런지 확인했다.

엔지니어 Agent 혼자 500 오류를 발견했다

엔지니어 Agent는 실제 배포된 API까지 확인했다.

그 과정에서 picks, matches 쪽 요청에서 500 오류가 발생하는 것을 발견했다.

원인은 DB 스키마였다.

기존 데이터가 존재하는 테이블에 NOT NULL 컬럼이 제대로 반영되지 않으면서 애플리케이션이 기대하는 스키마와 실제 DB 스키마가 달라져 있었다.

문서만 읽었을 때는 찾기 어려운 문제였다.

창업가와 투자자 Agent 역시 이 부분을 발견하지 못했다.

엔지니어 심사 Agent만 라이브 API를 직접 두드려 500을 발견했다. 문서만 읽은 다른 심사 Agent는 발견하지 못했다.

이 버그 하나 때문에 단순히 안정성 점수만 떨어지는 것도 아니었다.

상호 선택 결과가 정상적으로 동작하지 않으면서 리텐션과 차별점에서 주장하던 기능도 함께 영향을 받았다.

결국 하나의 장애가 여러 심사 항목의 근거를 동시에 무너뜨리고 있었다.

이때 세 개의 Agent를 나눈 의미가 꽤 명확해졌다.

서로 다른 종류의 실패를 찾는 리뷰어 세 개가 필요했다.

Agent의 감점 사유를 실제 제품에 반영했다

자가 채점을 하고 끝내지는 않았다.

점수가 낮은 이유 중 남은 시간 안에 수정할 수 있는 것들을 다시 제품에 반영했다.

실제 커밋에도 심사 지적사항 반영이라는 이름으로 수정 내용이 남아 있다.

대표적으로 다음 문제들이 있었다.

결제 시점을 설명하면서 제품에는 결제 시점이 없었다

문서에서는 일정 규모 이상의 파티에 비용을 받는 수익 모델을 이야기하고 있었다.

그런데 실제 제품에서는 예상 인원을 입력하는 과정이 없었다.

결국 문서가 주장하는 수익 모델과 구현이 맞지 않았다.

첫 화면에 예상 인원 입력을 추가하고, 일정 인원을 초과하면 결제 확인 단계가 나타나도록 수정했다.

비용 계산과 실제 코드가 맞지 않았다

단위 경제성을 계산하면서 API 요청 비용을 계산했는데, 실제 구현에서 발생하는 polling 요청을 충분히 반영하지 못했다.

Agent가 이 부분을 지적하면서 코드를 다시 확인했다.

polling 빈도를 낮추기 위해 주기를 4초에서 15초로 늘렸고, 종료된 파티에서는 polling 자체를 멈추도록 했다.

기획 문서의 비용 계산도 실제 요청 수를 기준으로 다시 작성했다.

결과 API가 실패하면 화면 전체가 사실상 사라졌다

정상 플로우만 생각하고 만든 부분이었다.

결과 데이터를 가져오지 못해도 사용자가 최소한 증표함이나 다음 파티 만들기, 다시 시도 같은 행동을 할 수 있도록 fallback을 추가했다.

서버 오류를 그대로 화면에 보여주고 있었다

500이 발생하면 서버의 JSON이나 프록시 HTML이 화면에 그대로 노출되는 부분도 있었다.

사용자가 이해할 수 있는 오류 메시지로 바꿨다.

이런 것들은 해커톤에서 시간이 충분했다면 언젠가 직접 찾았을 문제일 수도 있다.

하지만 2시간 30분 안에서는 모든 코드를 사람이 직접 따라가며 리뷰할 시간이 없었다.

모의 심사 Agent가 어디부터 확인할지를 정하는 역할을 해줬다.

사람에게 자연스러운 UI가 Agent에게도 자연스럽지는 않았다

실제 심사자가 브라우저 Agent라는 점은 UX에도 영향을 줬다.

사람에게는 자연스럽지만 Agent가 검증하기 어려운 UI가 있었다.

예를 들어 같은 화면에 "파티 만들기"라는 텍스트가 여러 개 존재하면 사람은 위치와 문맥을 보고 어떤 버튼인지 쉽게 구분한다.

Agent가 텍스트를 기반으로 요소를 찾는다면 이야기가 달라진다.

성공 여부를 Toast에만 표시하는 것도 비슷했다.

사람은 화면 한쪽에

복사되었습니다.

라는 Toast가 잠깐 나타났다 사라져도 이미 성공했다는 사실을 기억한다.

하지만 Agent가 다음 단계에서 성공 여부를 확인한다면 해당 텍스트는 이미 DOM에서 사라졌을 수 있다.

그래서 중요한 완료 상태는 화면에 계속 남도록 했다.

초대 링크가 생성되었습니다
참여 완료
만난 사람 1명

같은 정보였다.

클릭 가능한 요소도 의미 있는 HTML 요소로 바꾸고 aria-label, htmlFor 같은 정보도 보강했다.

이 과정에서 평소와 조금 다른 질문을 하게 됐다.

이 기능을 사람이 사용할 수 있는가?

에서 끝나지 않고,

이 기능을 사람이 사용할 수 있는가?

그리고

Agent가 이 기능이 성공했다는 사실을
정확하게 확인할 수 있는가?

까지 보게 됐다.

이번 대회에서 처음 경험한 꽤 특이한 UX 조건이었다.

구현보다 "근거"를 맞추는 작업도 많았다

이번 루브릭에는 꽤 마음에 들었던 규칙이 하나 있었다.

의도와 근거를 구분했다.

추후 구현할 예정이다.

이렇게 확장할 수 있다.

바이럴을 통해 사용자를 확보한다.

같은 문장은 실제 근거와 동일하게 평가하지 않았다.

더 나아가 기획안에서 주장한 기능이 실제 브라우저에서 확인되지 않으면 그 기능에 의존한 다른 항목까지 점수가 제한될 수 있었다.

그래서 개발 막바지에는 코드를 작성하는 것만큼 다음 세 가지를 맞추는 일이 중요했다.

기획안에서 주장하는 것
           =
실제로 구현한 것
           =
심사 Agent가 확인할 수 있는 것

기획안에는 있지만 구현하지 않은 기능은 없는지 확인했다.

비즈니스 모델에서 이야기하는 결제 시점이 실제 화면에도 있는지 확인했다.

서버 비용을 주장한다면 코드의 실제 요청량과 계산이 맞는지도 다시 확인했다.

검증하지 않은 것을 굳이 크게 포장하지 않는 것도 전략이었다.

2시간 30분짜리 프로토타입이니 한계가 있을 수밖에 없었다.

실제 사용자 인터뷰를 하지 못했고, 최초 유입 전략 역시 실제 실행까지 이어진 것은 아니었다.

우리의 모의 심사에서도 이런 부분은 낮은 점수로 남았다.

그 점까지 억지로 10점으로 만들려고 하지는 않았다.

제출 1분 전까지 다시 고쳤다

시간은 계속 줄어들고 있었다.

약 한 시간을 기획에 사용한 만큼 실제 구현과 검증에 사용할 수 있는 시간은 더 짧았다.

후반부에는 거의 이런 과정을 반복했다.

구현
 ↓
배포
 ↓
모의 심사
 ↓
감점 이유 확인
 ↓
코드 수정
 ↓
문서 수정
 ↓
다시 배포

500 오류가 나오면 고쳤고,

문서와 구현이 다르면 맞췄고,

비용 계산이 실제 코드와 다르면 다시 계산했다.

완성도 있는 결과물을 만들고 우리가 만든 심사 Agent에게서 조금이라도 점수를 더 받기 위해 마지막까지 수정했다.

하지만 모든 문제를 해결하지는 못했다.

실제 자가 채점 문서에도 제출 시점까지 남아 있던 한계가 기록돼 있다.

최초 유입 전략은 아직 실행되지 않았고, 시장 규모의 확장 논리도 충분하지 않았으며, 일부 권한 검증과 마감 처리 역시 완전히 구현하지 못한 상태였다.

시간 제한이 있는 해커톤이니 어느 순간부터는

무엇을 더 만들까?

보다

남은 시간에 무엇을 고쳐야 점수에 가장 큰 영향을 주는가?

를 판단해야 했다.

결국 제출 마감 약 1분 전에 최종 제출했다.

3등, 2등, 그리고 1등

제출이 끝난 뒤 결과 발표가 진행됐다.

발표 순서는 3등부터였다.

3등이 발표됐다.

우리 팀은 아니었다.

다음은 2등이었다.

역시 우리 팀은 아니었다.

여기까지는 어느 정도 수상을 기대하고 있었다.

서비스가 실제로 동작했고, 심사 기준에 맞춰 계속 검증했기 때문에 수상권에는 들어갈 수도 있겠다고 생각했다.

그런데 현장에서 다른 팀들의 결과물도 봤다.

잘 만든 팀이 많았다.

그래서 2등까지 우리 이름이 나오지 않았을 때는 오히려 1등을 확신하지 못했다.

그리고 마지막 1등이 발표됐다.

25팀 중 1등이었다.

우승보다 기억에 남은 것은 평가자를 개발 루프에 넣어본 경험이었다

여러 대회에 참가했지만 AI Agent가 전체 팀의 결과물을 직접 평가하는 대회는 처음이었다.

AI 심사가 사람보다 무조건 객관적이라고 말하고 싶지는 않다.

Agent 역시 어떤 모델과 프롬프트를 사용하는지, 어떤 방식으로 실행하는지에 따라 결과가 달라질 수 있다.

실제 심사 Agent의 프롬프트도 공개되지 않았기 때문에 우리가 만든 모의 Agent가 실제 심사관과 얼마나 비슷했는지도 알 수 없다.

그래도 참가자 입장에서 이번 방식은 꽤 마음에 들었다.

이유는 규칙을 상당히 구체적으로 알 수 있었기 때문이다.

다른 대회에서는 심사 기준이 있어도 종종 이런 생각을 하게 된다.

심사위원이 이 아이디어를 좋아할까?

이번에는 그것보다 다음 질문을 더 많이 했다.

이 항목에서 우리가 보여줄 수 있는 실제 근거가 있는가?

Agent가 직접 테스트했을 때 성공하는가?

이 주장은 제품에서 확인할 수 있는가?

평가 기준이 명확하니 평가를 마지막 단계에만 둘 필요도 없었다.

우리는 그 기준을 가지고 평가자를 직접 만들어 개발 중간에 넣었다.

기존 Agent 사용 방식이 대략 이랬다면,

사람이 결정
   ↓
Agent가 구현
   ↓
사람이 리뷰

이번에는 하나의 과정이 더 생겼다.

사람이 방향 결정
        ↓
Agent가 구현
        ↓
모의 심사 Agent가 평가
        ↓
사람이 감점 이유를 판단
        ↓
Agent가 다시 수정

Agent를 단순한 구현자가 아니라 평가자로도 사용해본 셈이다.

그리고 이 방식은 실제 문제도 하나 찾아냈다.

창업가와 투자자 Agent가 9점을 준 안정성 항목에서 엔지니어 Agent 혼자 5점을 줬고, 이유를 따라가 보니 실제 프로덕션 API에서 500 오류가 발생하고 있었다.

세 Agent를 만든 것이 단순한 역할극으로 끝나지 않은 순간이었다.

실제 심사 Agent가 우리 모의 심사 Agent와 같은 이유로 좋은 평가를 내렸는지는 모르겠다.

다른 팀과 정확히 몇 점 차이가 났는지도 모른다.

따라서 모의 심사 Agent를 만들었기 때문에 1등을 했다고 단정할 수는 없다.

확인할 수 있는 사실은 이 정도다.

우리는 공개된 평가 기준을 분석했고,

그 기준으로 창업가·엔지니어·투자자 관점의 모의 심사 Agent를 만들었고,

기획부터 구현까지 계속 평가를 반복했다.

그 과정에서 실제 오류와 기획-구현 불일치도 찾아 수정했다.

그리고 최종 결과는 25팀 중 1등이었다.

다음에 비슷하게 평가 기준이 명확한 해커톤에 참가한다면 이 방식은 다시 사용해보고 싶다.

마지막 제출 직전에 심사표를 한 번 펼쳐보는 대신,

처음부터 평가자를 개발 루프 안에 넣는 방식으로.

프로젝트

• Hack the Beat - Party Passport
• 백지훈
• 서새찬
• 홍의민
• 이예람