[AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까

네이버가 2026년 봄 개최한 '모두의 Engineering Day' AI 해커톤에서, 25개 팀의 코드와 문서를 LLM이 자동 채점하는 'LLM as a Judge' 평가 파이프라인을 설계하고 실제 운영한 사례를 다룬다. 코드만 읽는 LLM이 사람의 판단에 가까운 결론에 도달할 수 있는지, 반복해도 안정적인 결과가 나오는지를 검증했다.

핵심 포인트

루브릭을 "일을 얼마나 줄였는가" 하나의 핵심 기준으로 설계하고, 기능 완성도 40%, 기술/구현 20%, 차별성/문제해결 20%, 문서/제출자료 20%의 4개 축으로 세분화했다.
팀별 채점 에이전트(team-evaluator), 문제별 취합 에이전트(topic-lead), 한 줄 평 작성/검수 에이전트를 분리해 이전 팀 판단이 다음 평가에 섞이는 컨텍스트 오염을 차단했다.
문제 A, B에서 LLM 평가 1위, 출제자 SUPER(슈퍼패스), 최종 우승이 모두 같은 팀으로 일치했다.
문제 C는 불일치했는데, 상위권 점수 차가 작은 경우 단일 총점보다 반복 평가 평균이 더 신뢰할 수 있다는 교훈을 얻었다.
5회 반복 평가에서 문제 A는 팀 NStake 4/5회, 문제 B는 youngsoo 5/5회, 문제 C는 timamanager 4/5회 1위를 기록해 상위권 안정성을 확인했다.

상세 정리

배경: 25팀 100여 명의 제출물을 당일 짧은 시간에 일관된 기준으로 채점해야 하는 운영 문제에서 LLM as a Judge를 도입했다.
문제 구성: 출자·투자 현황 관리(A), 영수증 경비 정산(B), 업무 시간 관리(C) 3가지 문제, 각 8~9팀이 경쟁.
평가 체계: 1차에서 LLM 자동 평가(문제당 상위 2팀 선발)와 출제자 SUPER 패스가 병행되고, 2차는 사내 AI 커뮤니티 30% + 출제자 30% + 참가자 40% 투표로 최종 결정.
루브릭 핵심: 기능이 업무 흐름의 끝까지 이어지는지(입력→판단→결과 생성)를 봤다. 단순 OCR 데모와 실제 경비 처리 자동화를 구분하는 세분화 기준을 설계했다.
에이전트 파이프라인: 팀별 채점 에이전트는 한 팀만 보고, 취합 에이전트는 같은 문제의 결과만 모으며, 한 줄 평은 작성과 검수 에이전트로 분리했다.
평가 결과: 문제 A(팀 NStake)·B(팀 youngsoo)는 LLM 1위 = SUPER = 최종 1위로 3자 판단이 일치. 문제 C는 LLM 1위(daylog), SUPER(TeamNaver_Assistant), 최종(timamanager)이 모두 달랐다.
불일치 원인: 문제 C는 상위권 점수 차가 작았고, daylog는 문서/제출자료에 강했으나 최종 우승팀 timamanager는 실제 동작 완성도에서 앞섰다.
반복 평가 실험: 해커톤 종료 후 5회 재채점. 상위권을 유지한 팀의 공통점은 "입력부터 판단, 결과 생성까지 이어지는 흐름이 코드에서 확인됐다"는 점이었다.
안정성 결론: 점수 차가 작은 경우 단일 평가 총점보다 3~5회 병렬 반복 후 평균을 쓰는 것이 다음 과제로 남았다.
인사이트: 명확한 루브릭이 있으면 LLM이 코드와 문서만으로도 사람에 가까운 판단을 내릴 수 있으며, 더 복잡한 코드베이스의 보조 평가 도구로 활용 가능성이 있다.

왜 읽나LLM as a Judge를 실제 평가 파이프라인으로 설계·운영해본 경험이 필요한 AI/ML 엔지니어, 에이전트 아키텍처나 LLM 신뢰성 검증에 관심 있는 개발자에게 유용하다.

네이버 D2 블로그

원문은 여기서 이어서 읽을 수 있어요

원문 읽기

읽음 (0)

·takedown 요청

[AI 해커톤 후기] 코드와 문서만 읽은 LLM은 어떻게 사람과 같은 팀을 1위로 골랐을까

이 글과 비슷한

에이전틱 SDLC를 QA 엔지니어링 마인드셋으로 구축하기

보안 업무를 위한 AI 에이전트 플랫폼 「SAGE」 개발기 1편: 판단은 사람에게 남기는 설계

실리콘투의 사내 지식 MCP 게이트웨이 구축기