LLM이 코드만 보고도 사람처럼 평가할 수 있을까?

네이버 '모두의 Engineering Day'에서 AI 네이티브 업무 경험을 위한 AI 해커톤 개최

반복 업무 자동화를 목표로 현업 담당자가 낸 문제에 25개 팀이 MVP 개발로 경쟁

LLM을 평가자로 활용하여 코드와 문서 기반으로 공정한 평가 방식 설계 시도

LLM 평가 결과와 사람 평가(출제자 SUPER, 최종 심사) 간의 일치도 및 안정성 검증 진행

명확한 루브릭과 평가 범위가 있다면 LLM이 사람과 유사한 판단을 내릴 수 있음을 확인

LLM 기반 평가 시스템 설계 원칙

본 해커톤에서는 코드와 문서만을 입력으로 활용하여 LLM이 평가자로 기능하도록 설계했습니다. 평가 대상은 하루 만에 개발된 MVP였으며, 실제 서비스 코드처럼 방대하고 복잡한 환경은 아니었습니다. 평가의 핵심은 '일을 얼마나 줄였는가'라는 명확한 기준을 세우고, 이를 문제별 세부 루브릭으로 구체화하는 것이었습니다. LLM은 단순히 기능 구현 여부를 넘어, 문제 해결 흐름이 코드 안에서 처음부터 끝까지 이어지는지를 확인하는 보조 평가 도구로 활용될 가능성을 탐색했습니다. 이는 AI 환각(Hallucination) 없이 명확한 기준 하에 LLM을 활용하는 방안을 제시합니다.

LLM 평가와 사람 평가의 일치 지점 분석

문제 A에서는 LLM 평가 상위권 팀과 출제자의 SUPER 선택이 일치하여, 실제 사용 가능성과 동작 완성도를 중요시하는 평가 축이 같았음을 시사합니다. 문제 B에서는 사내 메신저 봇, OCR, 경비 시스템 연동 등 구체적인 기술 스택과 경계 처리를 상세히 본 루브릭 덕분에 LLM이 차별화된 팀을 정확히 식별했습니다. 반면 문제 C에서는 LLM 평가, SUPER, 최종 심사가 다른 팀을 가리키며, 점수 차가 작을 경우 단일 평가만으로는 1위를 단정하기 어렵다는 점을 확인했습니다. 이는 LLM 평가가 사람의 판단과 유사한 경향을 보이지만, 복잡한 문제에서는 다각적인 검증이 필요함을 의미합니다.

반복 평가를 통한 LLM 평가의 안정성 검증

해커톤 종료 후 각 문제별 제출물을 5회씩 재평가하여 LLM 평가의 안정성을 확인했습니다. 점수 자체는 다소 흔들렸으나, 상위권을 유지하는 팀들은 비교적 안정적인 결과를 보였습니다. 이는 반복 평가에서도 꾸준히 상위권을 차지한 팀들이 입력부터 판단, 결과 생성까지 이어지는 문제 해결 흐름을 코드에서 명확하게 보여주었기 때문입니다. 반면 점수가 크게 흔들린 제출물은 기술 부족보다는 해당 기술이 실제 업무를 어디까지 대체하는지가 모호한 경우가 많았습니다. 따라서 평가의 일관성을 확보하기 위해 반복 평가 결과와 순위 유지 여부를 함께 고려하는 것이 중요함을 시사합니다.

LLM 평가의 한계점 및 향후 과제

이번 해커톤에서 LLM 평가는 코드와 문서만을 기반으로 진행되었으며, 실제 제출물을 직접 실행해보는 검증 단계까지는 가지 못했습니다. 낯선 저장소를 안정적으로 실행하는 것은 별도의 어려움이 따르며, 반복 평가에서 확인했듯 코드와 문서만으로도 업무 흐름이 잘 이어진 팀은 꾸준히 상위권에 남았습니다. 따라서 모든 제출물을 직접 실행하는 것이 다음 과제라고 단정하기보다는, 명확한 루브릭과 평가 범위 설정을 통해 LLM을 보조 평가 도구로 활용하는 방안을 지속적으로 모색할 필요가 있습니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)와 같이 복잡한 시스템에서도 적용 가능성을 보여줍니다.