Engineering
[AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까
2026년 7월 6일
원문에서 보기 ↗2026년 봄, 네이버는 개발 직군 중심으로 열리던 Engineering Day를 모든 직군이 함께하는 '모두의 Engineering Day'로 넓혔습니다. 행사의 마지막 순서는 AI 해커톤이었습니다. 목표는 단순히 AI를 써보는 것이 아니라, 사람이 하던 반복 업무를 AI로 줄이고 그 과정에서 'AI native로 일해 보는 경험'을 만드는 것이었습니다.
실제 업무 문제를 겪는 현업 담당자(problem holder)가 세 가지 문제를 냈고, 문제를 푸는 사람(solver)은 직군 제한 없이 네 명씩 팀을 이뤘습니다. 모두 25개 팀, 100여 명이 현장에서 문제와 매칭되었습니다. 각 팀은 바로 사용할 수 있는 수준의 최소 기능 제품(minimum viable product, MVP)을 하루 안에 만들어야 했습니다. 주제는 신규 서비스가 아니라 사람이 손으로 처리하던 반복 업무를 줄이는 사내 문제로 좁혔습니다.
행사를 준비하면서 마지막까지 남은 고민은 평가였습니다. 25팀의 제출물을 짧은 시간 안에 보고, 문제별 상위 팀을 공정하게 가려야 했습니다. 모든 코드를 실행해 볼 수 있다면 가장 좋았겠지만 시간이 부족했고, 제출된 코드와 문서를 일관된 기준으로 빠르게 읽을 방법이 필요했습니다. 마침 LLM의 성능이 좋아지면서 LLM을 평가자로 활용하는 방식(LLM as a judge)이 외부에서도 활발히 시도되고 있었습니다. 공통 문제를 두고 여러 팀이 경쟁하는 이번 행사에도 적용해 볼 만하다고 판단했습니다.
이 글은 코드와 문서만 읽는 평가를 어떻게 설계했는지, 그 결과가 사람의 평가와 얼마나 일치했는지, 평가를 반복해도 비슷한 결과가 나오는지를 정리한 기록입니다. 다만 평가 대상은 세 문제, 25팀, 100여 명이 하루 만에 만든 MVP였습니다. 실제 서비스 코드처럼 방대하고 복잡한 환경에 이 방식을 그대로 적용하기는 어렵지만, 'LLM이 코드와 문서만 읽고도 사람과 비슷한 판단을 내릴 수 있는지'를 가늠해 볼 수 있었습니다.
세 개의 문제와 평가 단계
세 개의 문제는 다음과 같습니다.
- 문제 A(출자·투자 현황 관리): 수기 엑셀로 취합하던 출자·투자 지분 현황을 입력하고 검증할 수 있는 플랫폼으로 전환
- 문제 B(영수증 경비 정산): 영수증을 일일이 모아 처리하던 정산을 사내 메신저 봇으로 자동화
- 문제 C(업무 시간 관리): 흩어진 업무 소스를 모아 하루 일정을 만들고 실제 쓴 시간까지 돌아보는 어시스턴트 구현
심사는 1차와 2차로 나눴습니다. 1차는 문제별 후보군을 좁히는 예선이었고, 2차는 최종 시상을 정하는 본선이었습니다. 1차 안에는 두 트랙이 있었습니다. LLM 평가단은 문제당 상위 2팀을 점수와 근거로 추렸고, 문제 출제자는 본인 문제에서 꼭 살리고 싶은 1팀을 SUPER(슈퍼패스)로 본선에 올렸습니다.
| 단계 | 단계 | 평가 주체 | 결과 |
|---|---|---|---|
| 1차 | 트랙 A — LLM 자동 평가 | LLM 평가단 | 문제당 상위 2팀 선발 |
| 1차 | 트랙 B — SUPER(슈퍼패스) | 문제 출제자 | 본인 문제에서 1팀 구제 |
| 2차 | 2차 | 사내 AI 커뮤니티 30% + 출제자 30% + 참가자 40% | 최종 수상자 결정 |
LLM 평가는 사내에서 제공하는 코딩 에이전트로 진행했습니다. 평가 절차와 루브릭(채점 기준표)을 하나의 '스킬'로 정의하고, 에이전트가 그 스킬에 따라 코드와 문서를 읽게 했습니다. 사내에는 Claude Code와 Codex가 제공되었는데, 두 에이전트의 결과를 얻고 맞춰 볼 시간이 부족했습니다. 그래서 이번 LLM 평가는 Codex 하나로 진행했습니다.
평가 기준은 '일을 얼마나 줄였는가'
이 평가가 던진 질문은 하나, '실제로 사용자의 일을 얼마나 줄여줬는가'였습니다. 단순히 AI나 기술을 사용했다는 사실은 중요하지 않았습니다. 같은 기능이라도 어디까지 이어지는지에 따라 점수가 달라졌습니다. 예를 들어 RAG(문서를 검색해 답을 보강하는 기법)가 정책을 찾아줘도 그 답이 경비 분류나 한도 판단으로 이어지지 않으면 검색을 돕는 데 그칩니다. 업무 화면으로 이동시키기만 하고 입력은 사람에게 맡기는 브라우저 확장 프로그램도 마찬가지입니다. 반대로 화면 입력을 대신 채우고, 실제 저장·상신(결재 요청)에 필요한 데이터를 만들고, 실패했을 때 다시 처리하는 흐름까지 구현했다면 사용자의 일을 대신했다고 볼 수 있습니다. 정적 대시보드도 정해진 상황만 보여주는지, 실제 수집 결과를 계속 반영하는지에 따라 다르게 평가했습니다. 그래서 발표 자료의 설명보다는 입력을 받고, 판단하고, 결과를 만드는 흐름이 실제 코드 안에서 이어지는지를 봤습니다. 기준을 납득 가능하게 만드는 것만으로는 충분하지 않았습니다. 문제당 상위 2팀을 가려야 했기 때문에, 비슷하게 좋아 보이는 팀들 사이에서도 차이가 드러나야 했습니다. 그래서 기능 완성도(functionality) 40점, 기술·구현(technical) 20점, 차별성·문제해결(differentiation) 20점, 문서·제출자료(documentation) 20점의 네 가지 평가 축을 정했습니다. 발표 자료만 보면 비슷해 보이는 팀도 코드에서 확인되는 구현 범위, 예외 처리, 업무 흐름의 연결 정도를 기준으로 보면 차이가 났습니다.
평가 시스템의 동작
평가 파이프라인은 단순했습니다. 각 팀의 저장소 주소, 커밋, 제출물 경로를 고정한 매니페스트를 준비하면 에이전트가 코드와 문서를 읽고 점수와 한 줄 평을 생성했습니다. 사람이 개입한 곳은 매니페스트를 준비하는 사전 단계와 결과 공개 시점을 정하는 단계뿐이었습니다.
가장 신경 쓴 부분은 공정성이었습니다. 화면을 직접 실행하지 않고 코드와 문서만으로 구현 수준을 판단해야 했기 때문에, 참가자와 운영자가 납득할 수 있는 기준이 필요했습니다. 발표 자료에는 완성됐다고 적혀 있어도 코드로 확인되지 않으면 구현 완료로 보지 않았습니다. TODO로 남은 기능, 틀만 있고 동작하지 않는 코드, 발표 자료에만 있는 기능도 마찬가지였습니다. 다만 같은 이유로 감점을 반복하지는 않고, 구현된 만큼만 점수를 주고 확인되지 않은 부분은 점수를 주지 않았습니다. 채점은 팀별로 분리했습니다. 팀별 채점 에이전트(team-evaluator)는 매니페스트에서 팀명, 문제, 커밋, 저장소, 제출물 경로를 확인한 뒤 문제별 루브릭에 따라 코드와 문서를 읽었습니다. 점수만 남기면 이후 조율과 검수가 어려우므로 내부 JSON에는 점수, 강점, 근거, 판단 리스크를 함께 남겼습니다. 세 문제는 동일한 네 가지 평가 축을 사용했지만, 문제별 스킬에서 중점적으로 본 부분은 달랐습니다.
| 문제 | 중점적으로 본 부분 |
|---|---|
| 문제 A(출자·투자 현황 관리) | 수기 엑셀 기반 출자 현황을 기준 데이터(master DB)로 옮기는 입력, 검증, 불일치 발견·수정 경로 |
| 문제 B(영수증 경비 정산) | 영수증 인식부터 카드 매칭, 분류, 한도 확인, 임시 저장까지 이어지는 경비 처리 흐름 |
| 문제 C(업무 시간 관리) | 흩어진 업무 소스를 모아 하루 일정으로 바꾸는 핵심 흐름, 실제 연동, 상태 관리, 문서 근거 |
예를 들어 문제 B에서는 단순 OCR 데모와 실제 경비 처리 자동화를 나눠 보는 기준을 촘촘하게 뒀습니다. 영수증을 읽는 데서 끝나는지, 카드 매칭, 분류, 한도 확인, 예외 회복, 임시 저장까지 업무 흐름이 이어지는지를 따로 확인했습니다. 채점이 끝나면 문제별 취합 에이전트(topic-lead)가 같은 문제의 팀별 결과를 모았습니다. 이 단계에서는 새 점수를 만들지는 않고, 개별 채점 결과의 점수, 근거, 위험을 같은 문제 안에서 비교하고 점수 스케일과 상위권 후보가 갈리는 지점을 확인했습니다. 평가를 조율할 때는 책임을 나누는 데 신경을 썼습니다. 팀별 채점, 문제 내 조율, 한 줄 평 작성을 한 컨텍스트에 몰아넣으면 앞선 팀의 인상이나 문장의 톤이 다음 판단에 섞일 수 있고 평가 집중도가 떨어질 수도 있습니다. 그래서 채점 에이전트는 한 팀만 보고, 취합 에이전트는 같은 문제의 결과만 모으고, 한 줄 평은 작성(copywriter)과 검수(reviewer) 에이전트로 분리했습니다. 운영 관점에서는 네 가지 공통 평가 축을 먼저 고정했다는 점도 도움이 됐습니다. 문제별 세부 루브릭은 달라도 같은 평가 축을 공유했기 때문에 결과를 하나의 파이프라인으로 모으기 쉬웠습니다.
사람의 판단과 만난 지점
LLM 평가는 문제당 상위 2팀을 뽑는 1차 관문이었습니다. 따라서 공식 우승팀이 LLM 후보군 안에 들어왔다는 사실만으로는 큰 의미를 부여하기 어렵습니다. 더 흥미로웠던 지점은 문제 A와 문제 B에서 서로 다른 세 판단이 같은 팀을 가리켰다는 점입니다. LLM은 8~9개 팀(문제 A는 9개 팀, 문제 B와 C는 각 8개 팀) 중 해당 팀을 1위로 평가했습니다. 문제 출제자도 같은 팀을 SUPER로 골랐고, 최종 심사에서 사람들이 고른 우승 팀도 같았습니다.
| 문제 | LLM 1위 | SUPER | 최종 1위 | 일치 | 상위권 양상 | 우수한 지점 |
|---|---|---|---|---|---|---|
| 문제 A (출자·투자 현황 관리) | 팀 NStake | 팀 NStake | 팀 NStake | 일치 | 1~3위 초접전 | 기능 완성도 |
| 문제 B (영수증 경비 정산) | 팀 youngsoo | 팀 youngsoo | 팀 youngsoo | 일치 | 1위가 비교적 뚜렷 | 차별성, 문제 해결 |
| 문제 C (업무 시간 관리) | 팀 daylog | 팀 TeamNaver_Assistant | 팀 timamanager | 불일치 | 1~3위 접전 | 문서, 제출 자료 |
문제 A는 상위권 점수 차가 거의 없는 초접전이었습니다. 눈에 띄는 것은 LLM 평가에서 접전 구간의 맨 앞에 놓인 팀이 출제자의 SUPER 선택과 같았다는 사실입니다. 팀 NStake를 고른 SUPER 선택도 실제 사용 가능성과 동작 완성도를 중요시한 결과라면, 두 평가는 같은 축에 무게를 둔 셈입니다.
문제 B에서는 팀 youngsoo가 차별성과 문제 해결에서 비교적 뚜렷하게 앞섰습니다. 이 문제의 스킬은 사내 메신저 봇(WORKS Bot), OCR, 예외 회복, 한도 확인, 사내 경비 시스템(neon-ess), 상신 안전성 같은 경계를 자세히 봤습니다. 루브릭이 영수증을 읽기만 하는 수준과 실제 경비 처리를 자동화하는 수준을 나눠 보도록 설계돼 있었기 때문에, 차별성이 코드 근거로 확인되는 팀을 찾아낼 수 있었습니다.
문제 C에서는 LLM 평가, SUPER, 최종 심사가 서로 다른 팀을 가리켰습니다. 당일 결과만 보면 문서와 제출 자료 근거가 확실한 팀 daylog가 LLM 평가에서 앞섰고, 공식 우승 팀 timamanager는 실제 동작 완성도에서 강했습니다. 특정 팀이 맞고 틀렸다는 뜻은 아닙니다. 문제 C처럼 상위권 점수 차가 작을 때는 한 번의 평가 총점만으로 1위를 단정하기 어렵다는 사실을 알 수 있었습니다.
반복 평가와 안정성
문제 C의 불일치를 보고 나니 한 가지를 더 확인하고 싶었습니다. 같은 제출물을 LLM이 다시 채점하면 비슷한 결과가 나올까, 아니면 실행할 때마다 전혀 다른 결과가 나올까 하는 것이었습니다. 해커톤이 끝난 뒤 각 문제를 5회씩 다시 평가해 봤습니다. 점수 자체는 예상보다 흔들렸지만, 상위권을 유지하는 팀은 비교적 안정적이었습니다.
반복 평가에서 1위가 나온 횟수는 다음과 같았습니다.
| 문제 | 5회 중 1위 횟수 |
|---|---|
| 문제 A | 팀 NStake 4회, 팀 team22 1회 |
| 문제 B | 팀 youngsoo 5회 |
| 문제 C | 팀 timamanager 4회, 팀 Sherpa 1회 |
여기서 보고 싶었던 것은 문제별 순위를 다시 매기는 것이 아니라, 반복 평가에서도 상위권을 유지하는 팀에는 어떤 공통점이 있는가였습니다.
팀 NStake는 출자 현황 입력부터 기준 데이터 대조와 불일치 수정까지 이어졌습니다. 팀 youngsoo는 영수증 인식부터 카드 매칭, 분류, 임시 저장과 상신까지 이어졌습니다. 팀 timamanager는 업무 소스 수집부터 일정 생성, 상태 갱신, 퇴근 리뷰까지 이어졌습니다. 세부 구현은 달랐지만 점수를 만든 이유는 비슷했습니다. 입력부터 판단, 결과 생성까지 이어지는 문제 해결 흐름이 코드에서 보였다는 것입니다.
반대로 점수가 크게 흔들린 제출물은 기술이 부족했기 때문은 아니었습니다. 그 기술이 실제 업무를 어디까지 대신하는지가 애매한 경우가 많았습니다.
그래서 문제 C처럼 점수 차가 작은 경우에는 평가 한 번의 총점뿐 아니라 같은 평가가 반복해서 유지되는지도 함께 봐야 한다고 느꼈습니다. 반복해도 같은 팀이 상위에 남는다면, 그 평가는 운이 아니라 기준에 따라 어느 정도 일관되게 작동했다고 볼 수 있습니다.
회고
평가를 맡은 팀이 해커톤 뒤 잠깐 모여 회고했을 때 가장 아쉬워했던 점은 당일에 정해진 시간 안에 결과를 내야 하기 때문에 반복 평균을 사용하지 못했다는 것입니다. 다음에는 가능한 범위에서 평가를 병렬로 3~5회 반복하고, 평균 점수와 함께 반복 평가에서도 순위가 유지되는지를 보려고 합니다.
실제 실행 검증까지 가지 못한 것도 한계였지만, 모든 제출물을 직접 실행해 보는 것이 다음 과제라고 생각하지는 않습니다. 낯선 저장소를 안정적으로 실행하는 일에는 평가와는 또 다른 어려움이 있고, 사후 반복 평가에서 확인했듯, 코드와 문서만 읽어도 실제 업무 흐름이 잘 이어진 팀은 반복해서 상위권에 남았기 때문입니다.
반면, 다음에도 공통 평가 축을 먼저 정하고 문제별 세부 루브릭으로 구체화하는 방식은 유지하려고 합니다. 문제별 루브릭이 달라도 같은 평가 축을 공유했기 때문에 결과를 한 방향으로 모을 수 있었습니다.
마치며
이번 평가에서 가장 분명하게 확인한 것은, 채점 기준이 충분히 구체적이면 코드와 문서만 읽은 LLM도 사람의 판단에 가까운 결론에 도달할 수 있다는 점이었습니다. LLM은 단순히 기능 구현 여부만 보는 것이 아니라, 실제 문제를 해결하는 흐름이 코드 안에서 처음부터 끝까지 이어지는지까지 확인했습니다.
명확한 루브릭과 평가 범위가 있다면, 더 복잡한 코드에서도 제품이 의도한 업무 흐름을 갖추었는지 점검하는 보조 평가로 LLM 평가를 활용할 수 있겠다는 아이디어를 얻었습니다. 작은 코드베이스에서 본 가능성이지만, 이번 해커톤에서 여러 팀의 코드를 같은 기준으로 살펴보고, 그 판단을 사람의 평가와 나란히 비교해 본 덕분에, 그 가능성을 작게나마 실제 사례로 확인할 수 있었습니다.