AI가 만든 코드를 어떻게 믿을까: 내 프로젝트로 평가 문제를 만드는 법

핵심 요약 (TL;DR)

AI가 고친 코드가 그럴듯해 보인다고 해서 내 서비스에 맞는 것은 아닙니다. 최근 공개된 Self-bench는 로컬 코딩 세션과 병합된 GitHub pull request에서 완료된 작업을 찾아, 변경 전 커밋을 기준으로 과제를 재구성합니다. 숨은 테스트와 기준 구현을 만들고, 해결 전에는 실패하고 원래 구현에서는 통과하는지 확인한 뒤 코딩 에이전트 평가용 Harbor 작업으로 내보냅니다. 핵심은 새로운 벤치마크 점수를 쫓는 일이 아니라, 내 프로젝트가 이미 겪은 문제로 AI를 시험한다는 발상입니다.

범용 벤치마크만으로는 왜 부족할까요?

공개 벤치마크는 모델을 비교하는 데 도움이 되지만, 내 서비스의 예약 규칙이나 관리자 화면의 예외 처리까지 알려 주지는 않습니다. 어떤 에이전트가 일반적인 알고리즘 문제를 잘 풀어도, 우리 저장소의 폴더 구조와 기존 약속을 지키리라는 보장은 없습니다.

Self-bench가 흥미로운 이유는 실제로 끝난 작업에서 평가 재료를 찾는다는 점입니다. 변경 전 상태와 변경 후 상태가 모두 있으므로, ‘무엇이 부족했고 무엇이 통과해야 했는지’를 프로젝트의 역사에서 가져올 수 있습니다. 다만 이 도구가 모든 판단을 자동으로 보장하는 것은 아닙니다. 테스트가 잘못 설계되면 AI는 잘못된 답을 통과시키는 데에도 능숙할 수 있습니다.

비개발자도 이 원칙을 어떻게 가져올 수 있을까요?

복잡한 평가 도구부터 설치할 필요는 없습니다. AI에게 기능을 맡기기 전에 세 줄의 확인 기준을 적으세요. 예를 들어 “빈 이메일로 제출하면 오류 문구가 보인다”, “정상 신청은 관리자 목록에 한 번만 나타난다”, “모바일에서 제출 버튼이 화면 밖으로 밀리지 않는다”처럼 사용자가 실제로 만지는 장면으로 씁니다.

수정이 끝나면 AI에게 ‘완료’라고만 말하게 하지 말고, 어떤 파일을 바꿨는지와 각 기준을 어떻게 확인했는지 받으세요. 그리고 가장 중요한 한두 흐름은 직접 눌러 봅니다. 에이전트의 설명이 아니라 서비스의 실제 반응을 확인하는 시간이 필요합니다.

좋은 검증 기준은 어떤 모습일까요?

좋은 기준은 관찰 가능하고, 실패했을 때 원인을 좁힐 수 있습니다. “예쁘게 만들어 주세요”보다 “390px 화면에서 버튼이 가로 스크롤 없이 보인다”가 낫습니다. “안전하게 처리해 주세요”보다 “권한 없는 사용자는 관리자 화면 주소를 열 수 없다”가 낫습니다.

AI 코딩 시대의 테스트는 개발자만의 형식적인 절차가 아닙니다. 내 제품이 지켜야 할 약속을 글로 남기는 일입니다. 이 약속이 쌓이면 도구나 모델을 바꿔도 프로젝트가 무엇을 해야 하는지 잃지 않습니다.

FAQ: Self-bench를 바로 써야 하나요?

저장소와 GitHub 작업 이력이 있고 여러 모델을 비교하려는 팀에는 의미가 있습니다. 처음 MVP를 만드는 단계라면 먼저 핵심 사용자 흐름의 수동 확인 기준부터 적는 편이 현실적입니다.

FAQ: AI가 테스트까지 만들면 사람이 볼 필요가 없나요?

필요합니다. AI가 만든 테스트도 요구사항을 제대로 반영했는지 확인해야 합니다. 특히 결제, 권한, 개인정보 흐름은 실제 화면과 데이터로 별도 검토해야 합니다.

FAQ: 테스트가 많을수록 좋은가요?

무조건 그렇지는 않습니다. 자주 깨지고 실패 비용이 큰 흐름부터 명확하게 확인하는 것이 먼저입니다.

출처: https://github.com/mupt-ai/self-bench
참고: https://news.ycombinator.com/
관찰 시점: 2026-08-15 KST