Airbnb가 말하는 평가 주도 개발(EDD): GenAI 제품을 믿을 수 있게 만드는 방법

출처: Rohit Girme 외 (Airbnb Engineering, Medium)
원문: https://medium.com/airbnb-engineering/eval-driven-development-lessons-from-evaluating-genai-at-scale-e817e5ae5788

작성자: 팔복소프트-김팔복

한눈에 보기

• Airbnb는 LLM 기반 제품을 만들 때 평가(Evaluation)를 부차적인 작업이 아니라 핵심 엔지니어링 활동으로 다루며, 이를 **평가 주도 개발(Eval-Driven Development, EDD)**이라고 부릅니다.
• 가장 중요한 습관은 단순합니다. 프로토타입에 100개 정도의 입력을 넣고 출력을 직접 눈으로 읽으면서 실패 유형을 분류한 뒤, 그걸 기반으로 평가를 만드는 것입니다.
• 평가는 세 개의 층으로 구성합니다. 코드 기반의 프로그래밍 검사 → LLM-as-Judge(가상 심판) → 사람 평가 순으로, 비용이 낮은 것부터 걸러냅니다.
• LLM 심판은 반드시 골든 데이터셋(50~100개, 나쁜 예시 포함)으로 캘리브레이션해야 하며, 사람과의 일치율 80% 후반~90%대를 목표로 합니다. 검증 안 된 심판은 없는 것보다 더 위험합니다.
• 에이전트 시스템은 최종 답변만 보면 안 되고, 개별 스텝 → 전체 경로(trajectory) → 세션 단위까지 나눠서 평가해야 합니다.

주요 내용

왜 GenAI에는 별도의 평가 전략이 필요한가

LLM은 기존 소프트웨어 테스트의 전제를 여러 개 깨뜨립니다. 출력이 비결정적이고, "정답"의 기준이 주관적이며, AI를 평가하기 위해 또 다른 AI를 써야 하는 상황이 자주 생깁니다. 게다가 하나의 요청 안에서 검색, 추론, 툴 호출, 생성이 연쇄적으로 일어나기 때문에 각 단계가 독립적으로 실패할 수 있습니다.

Airbnb는 리뷰 하이라이트, AI 고객 지원, 게스트·호스트용 커뮤니케이션 기능 등 여러 LLM 기능을 운영하면서, 평가 전략 없이 개발하면 세 가지 문제가 반복된다고 정리합니다.

• 거짓 확신: "도움이 되는가" 같은 일반적인 지표는 점수가 잘 나오지만, 실제 사용자가 겪는 실패 유형을 잡아내지 못합니다.
• 감지되지 않는 회귀: 프롬프트를 바꿨는데 측정하지 않던 영역이 조용히 나빠집니다.
• 낭비되는 노력: 실제 성과와 상관없는 지표를 위해 대규모 평가 파이프라인을 만들게 됩니다.
  그래서 프로젝트 전체 공수에서 평가에 상당한 비중을 배정하는 것을 당연하게 받아들여야 한다는 게 Airbnb의 입장입니다.

단 하나의 규칙: 데이터를 직접 봐라

Airbnb가 모든 팀에게 권하는 출발점은 프레임워크나 툴이 아닙니다. 프로토타입을 만들고, 100개 정도의 예시(합성 데이터도 괜찮음)를 돌린 뒤, 출력과 트레이스를 직접 읽고 모델의 실수를 분류하는 것입니다. 이 습관 하나가 어떤 방법론보다 제품 품질에 크게 기여한다고 강조합니다.

이 습관을 공식화한 것이 EDD입니다. TDD(테스트 주도 개발)의 GenAI 버전이라고 볼 수 있는데, 모든 실패를 미리 예측하는 대신 실패 유형이 발견될 때마다 이를 평가로 기록하고 지속적으로 테스트하는 체계를 만드는 접근입니다. EDD의 원칙은 다음과 같습니다.

• 목표와 출시 기준(gate)을 먼저 정의한다. 처음엔 불명확해도 데이터 탐색 과정에서 발견될 수 있다.
• 지표는 머릿속에서 만들지 말고, 실제 관찰된 오류에서 도출한다.
• 평가자는 작고 날카롭게 유지한다. 잘 캘리브레이션된 LLM 심판 35개가 노이즈 많은 2030개보다 낫다. 각 심판은 하나의 정확성 차원만 담당한다.
• 좋고 나쁨에 대한 의견이 갈릴 때 최종 결정을 내리는 사람 결정권자를 정한다.
• 제품 담당자와 "X와 Y 중 뭐가 나은가", "이 출력의 문제가 뭔가"를 계속 논의한다.

3층 구조의 평가 방법

모든 평가는 아래 세 방법의 조합으로 이뤄집니다.

1층: 프로그래밍 검사 — LLM 호출 없이 코드로 처리하는 결정적 검사입니다. JSON 스키마 유효성, 길이·공백 체크, 금지어 정규식, 분류 문제라면 precision/recall 같은 전통 ML 지표 등이 해당합니다. 비용이 거의 없으니 명백한 실패는 여기서 먼저 걸러냅니다. 출력 포맷은 프롬프트 지시에만 의존하지 말고 structured output(JSON 스키마)으로 강제하라는 조언도 덧붙입니다.

2층: LLM-as-Judge(가상 심판) — 더 강한 모델이 정교한 루브릭을 기준으로 다른 모델의 출력을 평가합니다. 톤, 일관성, 원문 충실성(faithfulness) 같은 미묘한 품질을 사람 평가보다 훨씬 적은 비용으로 확인할 수 있습니다. 핵심은 루브릭 설계입니다. "이 설명이 우리 기준에 맞게 읽기 좋은가?"처럼 모호한 기준은 사람도 일관되게 적용할 수 없고, 사람이 못 하면 LLM은 더 못 합니다. 심판마다 하나의 차원만 평가하게 하고, 생성 모델과 다른 모델을 심판으로 쓰고, few-shot 예시와 명확한 출력 스키마·점수 기준을 넣는 것이 원칙입니다.

3층: 사람 평가 — 여전히 ground truth의 최종 기준입니다. 골든 데이터셋 구축, 안전·고위험 영역, 자동 평가자 간 의견 불일치 해소에는 사람이 필요합니다.

시작 규모에 대한 경험칙도 있습니다. 도메인 전문가가 라벨링한 20~100개 정도로 시작하고, 루브릭이 충분히 견고해지고 물량이 병목이 됐을 때만 대규모 어노테이션 인력으로 확장하라는 것입니다. 그리고 전문가들끼리 라벨에 대한 의견이 갈리면 멈추고, 자동화 전에 사람의 불일치부터 해결해야 합니다.

심판 캘리브레이션: 검증 없는 심판은 위험하다

캘리브레이션되지 않은 가상 심판은 거짓 확신만 주기 때문에 없느니만 못합니다. Airbnb가 권하는 절차는 이렇습니다.

1. 50~100개의 골든 데이터셋을 만든다. 반드시 나쁜 예시를 포함해야 한다. 좋은 예시만으로는 판별력을 테스트할 수 없다.
2. 가상 심판을 골든셋에 돌린다.
3. 사람 라벨과의 일치율을 측정한다. 목표는 80% 후반~90%대. Cohen's kappa나 Krippendorff's alpha 같은 지표를 쓸 수 있다. (사람끼리도 의견이 갈리므로 100% 일치는 목표가 아니다.)
4. 불일치 사례를 분석해 프롬프트와 few-shot 예시를 수정하고, 목표 일치율에 도달할 때까지 반복한다.
5. 실패 유형은 계속 진화하므로 주기적으로 재캘리브레이션한다.

에이전트 시스템은 경로까지 평가해야 한다

멀티스텝 추론, 툴 호출, 분기 로직이 있는 에이전트는 최종 출력만 봐서는 부족합니다. 최종 답이 맞아도 그 과정의 추론이 틀렸거나, 툴 파라미터가 잘못됐거나, 경로가 비효율적일 수 있기 때문입니다. 그래서 세 개 층위로 나눠 평가합니다.

• 스텝 수준: 개별 툴 호출이나 추론 단계가 올바른가
• 경로(trajectory) 수준: 전체 진행 경로가 합리적이고 효율적이었는가
• 세션 수준: 전체 상호작용이 사용자의 목표를 달성했는가
  구현 측면에서는 에이전트가 남기는 트레이스와 스팬(어떤 서브 에이전트가 호출됐는지, 입출력, 호출된 툴 등)을 관측 플랫폼이나 저장소에 기록해두고, DFS 같은 트리 순회로 트레이스를 메모리에 재구성하는 방법을 소개합니다. 이렇게 하면 특정 서브 에이전트가 적절한 시점에 호출됐는지, 올바른 툴을 썼는지 검증할 수 있고, 특정 에이전트 범위로 평가를 좁힐 수도 있습니다.

실전 흐름: 처음부터 끝까지

여행 플랫폼의 지원 정책 관련 질문에 답하는 AI 어시스턴트를 만든다고 가정한 예시입니다.

1. 탐색: 100개 입력을 돌리고 전부 읽는다. 원문에 없는 정책을 지어낸 응답 15건(충실성), 맞지만 장황한 응답 8건(간결성), 정당한 질문 거부 5건(과잉 거부), JSON 깨짐 3건(포맷)을 발견한다.
2. 평가 구축: JSON 유효성과 길이는 프로그래밍 검사로, 충실성과 간결성은 각각 별도의 가상 심판으로 만든다. PM이나 도메인 전문가가 실패 사례를 포함해 60개를 라벨링해 골든셋으로 삼는다.
3. 캘리브레이션과 반복: 충실성 심판의 사람 일치율이 78%로 부족했는데, 분석해보니 정확한 패러프레이즈를 "불충실"로 오판하고 있었다. 루브릭을 고치고 few-shot을 추가하니 88%로 상승. 이후 검색 단계를 개선해 충실성 실패 자체를 크게 줄였다.
4. 확장과 모니터링: 5,000개 예시로 평가를 확장하고, 프로덕션에서는 비식별화된 실 트래픽의 5%를 매일 샘플링해 프로그래밍 검사와 가상 심판을 돌리고, 플래그된 출력을 사람이 검토한다. 주간 PM 리뷰로 새 실패 유형을 발견하면 새 평가를 추가하는 루프를 돌린다.
   모델·프롬프트를 개선할 때는 한 번에 하나의 변수만 바꾸라는 조언도 있습니다. 모델을 고정하고 프롬프트를 바꾸고, 다음엔 프롬프트를 고정하고 모델을 바꾸고, 마지막으로 서빙 설정을 바꾸는 식입니다. 각 단계에서 가상 심판이 후보를 좁혀주고, 상위 후보의 샘플로 다시 심판을 개선하면서 평가자와 후보가 서로를 다듬어 갑니다.

정리

이 글의 핵심은 "일단 데이터를 직접 읽어라"라는 단순한 습관에서 출발해, 실제 관찰된 실패를 평가로 기록하고 계속 테스트하는 체계(EDD)를 만드는 것입니다. 프로그래밍 검사 → LLM 심판 → 사람 평가의 3층 구조를 쓰되, LLM 심판은 나쁜 예시가 포함된 골든셋으로 반드시 검증한 뒤에 신뢰해야 합니다. Airbnb는 결국 AI로 성공하는 팀은 최고의 모델을 가진 팀이 아니라, 무엇이 "좋은 결과"인지에 대한 소통과 제품 비전이 가장 명확한 팀이라고 강조합니다.

• LLM
• Eval-Driven-Development
• LLM-as-Judge
• Airbnb
• AI에이전트