생성형 AI 프로젝트에서 평가는 흔히 마지막에 붙습니다. 모델을 고르고, 기능을 만들고, 출시를 준비한 뒤에야 무엇이 좋은 결과인지 확인합니다. 순서가 거꾸로일 때가 많습니다.
에어비앤비가 공개한 평가 주도 개발 방식은 평가를 사후 검증이 아니라 개발 규율로 둡니다. 모든 실패를 미리 예측하려 하지 않습니다. 대신 실패가 나타나면 발견하고, 기준으로 만들고, 이후에도 계속 검사합니다.
시작은 의외로 소박합니다. 프로토타입에 입력 100개를 넣고 사람이 출력을 전부 읽습니다. 읽으면서 실패를 유형별로 나누고, 그중 50~100개를 골든셋으로 만듭니다. AI가 채점하게 할 때도 바로 믿지 않습니다. 사람이 매긴 점수와 얼마나 일치하는지 먼저 확인하고, 어긋난 사례를 보며 기준을 고칩니다.
문서에서 더 인상 깊었던 것은 숫자보다 조직 규칙이었습니다. 의견이 갈릴 때 최종 판단을 내릴 사람을 정하고, 전문가끼리 합의하지 못하면 자동화를 멈춥니다. 출시 후에도 PM이 매주 결과를 읽고 새 실패를 평가 항목으로 추가합니다.
평가를 개발팀에만 맡기면 측정하기 쉬운 것만 남기 쉽습니다. 형식 오류나 응답 속도는 잘 측정할 수 있지만, 사용자가 왜 불편한지와 어떤 답을 좋은 답이라 부를지는 기술만으로 결정되지 않습니다. 결국 평가는 제품의 기준을 밖으로 꺼내는 일입니다.
몇 해 전 사내 챗봇을 만들 때 우리는 확신도가 낮으면 답하지 않도록 했습니다. 당시에는 정답률을 포기한 임시방편이라고 생각했습니다. 지금 돌아보면 그것은 가장 단순한 평가 체계였습니다. 시스템이 스스로 물러나야 할 순간을 정한 것이니까요.
골든셋 파일 자체는 큰 자산이 아닙니다. 복사할 수 있기 때문입니다. 더 중요한 것은 그 파일을 만들면서 조직 안에 생긴 합의입니다. 무엇을 좋은 결과라 부를 것인지, 의견이 갈리면 누가 결정할 것인지, 새 실패를 어떻게 다음 기준으로 남길 것인지에 대한 합의입니다.
모델은 사 올 수 있습니다. 하지만 우리 조직이 무엇을 좋다고 부를지는 우리가 정하는 수밖에 없습니다.