Hamel Husain의 글 “It’s Hard to Eval” Is a Product Smell은 AI 제품에서 자주 나오는 말, “이 제품은 평가하기 어렵다"를 다르게 봅니다. 저자의 주장은 단순합니다. 평가가 어렵다면 평가 방식만의 문제가 아니라, 제품이 사용자의 검증 과정을 충분히 돕지 못한다는 신호일 수 있습니다.
1) 어려운 평가는 제품 냄새다
많은 AI 팀은 평가를 나중 문제로 둡니다. 먼저 모델이 그럴듯한 결과를 내게 만들고, 이후에 자동 평가나 사람 평가를 붙이려 합니다. Hamel은 순서가 반대여야 한다고 말합니다. 제품이 검증하기 쉬운 산출물을 만들도록 설계되어야 평가도 쉬워집니다.
예를 들어 사용자가 AI 데이터 에이전트에게 “지난 분기 Product A의 순매출은 얼마인가?“라고 묻는다고 합시다. 에이전트가 “$4.21M"이라는 숫자만 답하면 사용자는 그 숫자를 믿을 근거가 없습니다. 결국 지표 정의, SQL, 원천 데이터, 중간 계산을 다시 확인해야 합니다. 이러면 AI가 시간을 줄여준 것이 아니라 검토 비용을 사용자에게 떠넘긴 셈입니다.
좋은 설계는 답을 더 길게 쓰는 것이 아닙니다. 사용자가 실제로 확인하는 경로를 제품 안에 넣는 것입니다. 지표 정의가 어디서 왔는지, 어떤 쿼리를 실행했는지, 어떤 중간값이 맞지 않는지, 무엇은 아직 신뢰할 수 없는지 보여줘야 합니다. 최종 숫자는 같아도 검증 가능한 숫자와 검증 불가능한 숫자는 전혀 다른 제품 경험입니다.
2) 검증 가능한 산출물은 더 작다
두 번째 사례는 K-12 체육 수업 계획 생성기입니다. 교사가 학년, 수업 시간, 장소, 장비를 입력하면 AI가 수업 계획을 만듭니다. 문제는 완전히 새 계획 하나를 통째로 받으면 교사가 전체를 다시 판단해야 한다는 점입니다.
Hamel이 제안하는 방향은 기존에 검증된 수업 계획을 기준점으로 삼는 것입니다. AI가 새 계획을 처음부터 쓰는 대신, 실제 교사들이 쓰는 계획을 가져오고 사용자의 제약에 맞게 몇 군데만 바꿉니다. 그리고 바뀐 부분을 diff로 보여줍니다. 예를 들어 50분 계획을 45분에 맞추기 위해 준비운동을 줄였거나, 장비 수에 맞춰 스테이션 개수를 바꿨다는 식입니다.
이 설계는 사용자에게도 좋고 평가에도 좋습니다. 교사는 전체 계획을 다시 읽는 대신 “이 변경이 내 조건을 잘 반영했는가"만 보면 됩니다. 팀 입장에서도 평가 범위가 줄어듭니다. 검색한 기준 계획이 적절했는지, 변경 사유가 맞는지, 제약을 어기지 않았는지를 각각 확인할 수 있습니다.
3) 고위험 문서는 완성본보다 근거가 먼저다
세 번째 사례는 산재 의료 보고서입니다. AI가 환자 기록, 영상 판독, 치료 노트, 이전 검사 자료를 읽고 50페이지짜리 전문가 의견서를 만든다고 해봅시다. 이 영역에서 최종 보고서만 내놓는 제품은 위험합니다. 의사는 결국 모든 주장과 근거를 다시 확인해야 하고, 책임도 의사에게 남습니다.
그래서 제품은 보고서 생성기보다 연구 보조자에 가까워야 합니다. 각 기록에서 중요한 사실을 뽑고, 원문 페이지로 돌아갈 수 있는 링크를 붙이고, 서로 충돌하는 검사 결과를 표시하고, 아직 판단이 필요한 빈틈을 드러내야 합니다. 의사가 이 단위들을 확인한 뒤에야 최종 보고서가 조립되는 편이 더 안전합니다.
핵심은 AI가 사람을 루프 밖으로 밀어내는 것이 아닙니다. 사람이 책임져야 하는 판단을 더 작은 단위로 나누고, 그 판단에 필요한 근거를 바로 볼 수 있게 만드는 것입니다.
4) 제품 설계 질문 네 가지
이 글의 실무적 가치는 평가를 제품 설계 질문으로 바꿔준다는 데 있습니다. AI 제품을 만들 때 다음 네 가지를 먼저 물어볼 수 있습니다.
- 사용자는 실제로 무엇을 확인해야 하는가?
- 사용자는 무엇을 신뢰 기준으로 삼아 비교할 수 있는가?
- 전문가가 빠르게 이상함을 감지할 때 쓰는 신호는 무엇인가?
- 사용자가 한 번에 승인하거나 거절할 수 있는 가장 작은 단위는 무엇인가?
이 질문에 답하면 평가 데이터도 더 잘 생깁니다. 사용자가 승인한 단위, 수정한 단위, 거절한 단위가 그대로 평가 신호가 됩니다. 반대로 최종 산출물 하나만 던지는 제품은 사용자에게도 불친절하고, 팀이 자동 평가를 만들 때도 신호가 흐립니다.
5) AI 시대의 병목은 생성이 아니라 확인이다
Hamel은 이 논의가 완전히 새로운 디자인 원칙은 아니라고 말합니다. 전문가가 실제로 무엇을 확인하는지 관찰하는 needfinding, 많은 근거를 구조화해 이해하는 sensemaking 같은 오래된 개념과 닿아 있습니다.
다만 AI 제품에서는 이 문제가 더 선명해졌습니다. 예전에는 사람이 결과물을 만드는 과정에서 자연스럽게 확인도 함께 일어났습니다. AI가 생성 과정을 압축하면서 확인이 별도 병목으로 떠올랐습니다. 따라서 좋은 AI 제품은 “무엇을 만들어줄 것인가"만큼이나 “사용자가 어떻게 믿을 수 있게 할 것인가"를 설계해야 합니다.
결론 및 시사점
Hamel의 글은 평가를 모델 품질 측정만으로 좁히지 않습니다. 평가하기 쉬운 제품은 대개 사용하기도 쉽습니다. 출처, 중간 과정, 변경 이유, 미확인 항목을 제품 안에 드러내면 사용자는 AI 결과를 다시 처음부터 검토하지 않아도 됩니다.
실무적으로는 AI 기능을 붙일 때 최종 출력 화면부터 그리지 말고, 사용자의 검증 흐름부터 그리는 편이 낫습니다. 신뢰는 더 자신 있는 문장으로 생기지 않습니다. 확인할 수 있는 근거와 되돌아갈 수 있는 경로에서 생깁니다.
한 줄 결론: AI 제품의 경쟁력은 더 그럴듯한 완성본을 만드는 능력이 아니라, 사용자가 결과를 빠르게 믿거나 고칠 수 있게 만드는 검증 설계에서 나온다.