에어비앤비는 생성형 AI 제품을 안정적으로 운영하려면 평가를 출시 전 마지막 점검이 아니라 처음부터 설계에 포함되는 엔지니어링 활동으로 다뤄야 한다고 말합니다. 이를 위해 실제 오류에서 평가 기준을 만들고, 코드 기반 검사·LLM 심사·사람의 판단을 함께 사용하며, 특히 에이전트 시스템은 최종 답변뿐 아니라 도구 호출과 전체 실행 경로까지 살펴봐야 합니다. 핵심은 좋은 모델 자체보다도 명확한 제품 기준, 보정된 평가기, 지속적인 팀 협업에 있습니다.

1. 생성형 AI 평가가 어려운 이유

글은 에어비앤비가 리뷰 하이라이트, AI 고객 지원, 게스트·호스트용 스마트 커뮤니케이션 등 다양한 LLM 기반 기능을 제품에 적용하고 있다고 소개하며 시작합니다. 내부적으로는 AI가 사용자의 반응과 제품 동향을 파악해, 다음 개선 지점을 찾는 데에도 활용됩니다.

하지만 생성형 AI는 기존 소프트웨어 테스트의 전제를 흔듭니다. 전통적인 프로그램은 같은 입력에 대체로 같은 결과를 내고, 정답 여부도 비교적 분명합니다. 반면 LLM의 결과는 비결정적이며, 무엇이 "좋은 답변"인지는 맥락과 사람의 판단에 따라 달라집니다. AI의 결과를 평가하기 위해 또 다른 AI를 심사자로 쓰는 경우도 많은데, 이 심사 AI 역시 오류를 낼 수 있습니다.

또한 한 번의 LLM 상호작용 안에는 검색, 추론, 도구 호출, 텍스트 생성이 연속적으로 연결될 수 있습니다. 각 단계는 독립적으로 실패할 수 있으므로, 최종 답변만 맞는지 보는 방식으로는 충분하지 않습니다.

각 제품팀은 저마다의 평가 기준과 워크플로를 갖지만, 에어비앤비는 이를 뒷받침하는 공통 인프라와 원칙도 운영합니다. 인프라 팀이 도구와 모범 사례를 제공하고, 서로 다른 제품 영역에서 얻은 학습을 전사적으로 공유하는 방식입니다. 다만 글은 이것이 모든 팀에 똑같이 적용되는 처방은 아니며, 상황에 맞는 평가 설계가 필요하다고 전제합니다.

2. 평가를 처음부터 설계하는 기반

LLM 시스템 평가는 프로젝트 시작부터 계획해야 할 작업입니다. 평가 전략 없이 개발하면 보통 세 가지 문제가 발생합니다.

• 잘못된 자신감: 일반적인 "도움이 되는가" 점수는 높지만, 실제 사용자가 겪는 치명적 실패를 측정하지 못한 채 출시할 수 있습니다.
• 감지하지 못한 성능 저하: 프롬프트를 조금 바꿨을 뿐인데, 측정하지 않던 품질 요소가 미묘하게 나빠질 수 있습니다.
• 헛된 확장 비용: 실제 제품 성과와 상관없는 지표를 위해 대규모 평가 파이프라인을 만들 수 있습니다.

따라서 평가는 불필요한 부가 비용이 아니라, 제품이 실제로 작동하도록 만드는 데 필요한 상당한 비중의 개발 투자로 봐야 합니다.

데이터를 직접 읽는 한 가지 원칙

저자들이 가장 강하게 권하는 원칙은 매우 단순합니다.

"의심스러울 때는 데이터를 보라."

팀은 먼저 프로토타입을 만들고, 합성 데이터여도 좋으니 약 100개의 사례를 실행해 보아야 합니다. 그 뒤 숫자만 보지 말고 결과물과 실행 추적 기록(trace)을 직접 읽으며, 모델이 어디서 어떤 실수를 하는지 찾아야 합니다. 발견한 오류를 유형별로 분류한 뒤, 그 오류를 잡아낼 평가를 만들어야 합니다.

"출력과 추적 기록을 읽고 모델의 실수를 찾아라. 그것을 분류하고 평가를 만들어라."

이 습관이 어떤 프레임워크나 도구보다 제품 품질에 큰 영향을 준다는 것이 글의 주장입니다.

평가 주도 개발(EDD)의 다섯 원칙

이 습관을 체계화한 방법이 평가 주도 개발(Eval-Driven Development, EDD) 입니다. 이는 테스트 주도 개발(TDD)의 생성형 AI 버전으로, 모든 실패를 사전에 예측하려 하기보다 실제로 발견되는 실패를 계속 찾고, 평가 기준으로 코딩하고, 재검증하는 방식입니다. 또한 이해관계자들이 "좋은 결과"의 의미를 구체적으로 합의하게 만들어 제품 로드맵에도 영향을 줍니다.

EDD는 다음 다섯 원칙에 기반합니다.

1. 목표와 출시 기준을 미리 정한다
   무엇을 최적화할지, 출시 전에 반드시 충족해야 할 조건이 무엇인지 정의합니다. 다만 초기에는 답이 완전하지 않을 수 있으며, 데이터를 탐색하면서 기준을 발견할 수도 있습니다.

2. 실제 오류가 지표를 이끌게 한다
   관찰된 실패 사례를 바탕으로 제품, 엔지니어링, 도메인 전문가 등과 함께 평가 기준을 만듭니다. 추상적인 상상만으로 지표를 만들지 않습니다.

3. 심사기는 적고 날카롭게 유지한다
   잡음이 많은 20~30개의 평가기보다, 각각 한 가지 정확성 차원만 맡는 잘 보정된 3~5개의 LLM 심사기가 더 낫습니다.

4. 최종 의사결정자를 둔다
   "좋음"과 "나쁨"은 팀이 함께 논의해야 하지만, 의견이 갈릴 때 최종 판단을 내릴 인간 의사결정자가 필요합니다.

5. 지속적으로 협업한다
   제품 담당자는 정기적으로 "X가 Y보다 나은가?", "이 출력에서 실제로 무엇이 문제인가?"라는 질문에 답하며 평가 기준을 계속 다듬어야 합니다.

3. 세 가지 평가 방법을 겹겹이 사용하는 법

글은 생성형 AI 평가가 크게 세 가지 방법, 또는 이들의 조합으로 이루어진다고 설명합니다. 빠르고 단순한 검사부터 시작해, 더 섬세하고 비용이 큰 검증으로 내려가는 다층 방어 구조입니다.

1. 코드 기반·휴리스틱 검사: 빠르고 비용이 낮으며 명백한 실패를 잡습니다.
2. LLM 심사기(LLM-as-a-Judge): 문체, 충실성, 관련성 같은 미묘한 품질을 판단합니다.
3. 사람 평가: 고위험 사례, 미묘한 판단, 자동 평가기 간 불일치를 해결합니다.

코드 기반 검사로 기본 오류 걸러내기

LLM 호출이 필요 없는 결정적 코드 검사는 가장 먼저 적용해야 할 필터입니다. JSON 형식이 맞는지, 빈 응답이나 지나치게 긴 응답은 없는지, 금지어가 들어가지는 않았는지 등을 빠르게 확인할 수 있습니다.

예를 들어 다음과 같은 검사가 여기에 해당합니다.

• 형식 유효성 검사: JSON 또는 스키마가 올바른지 확인하며, 항상 적용합니다.
• 길이·필수값 검사: 빈 출력, 의심스럽게 짧거나 긴 출력 등을 확인합니다.
• 키워드·정규표현식 검사: 안전·규정 준수를 위해 금지된 표현을 찾습니다.
• 정확도·재현율·F1 점수: 분류 문제에 활용합니다.
• 코사인 유사도: 정답 참조 문장이 있을 때 의미적으로 비슷한지 확인합니다.

특히 후속 데이터 파이프라인이 깨지는 일을 막으려면, 프롬프트에 "JSON으로 출력하라"고 쓰는 것만으로는 부족합니다. 글은 JSON 스키마 같은 구조화된 출력 방식을 사용해 엄격한 형식을 보장하라고 권합니다.

"프롬프트 지시만으로 데이터 형식을 맞추려 하지 말라. 그러면 후속 데이터 파이프라인이 깨진다."

가상 심사기: LLM-as-a-Judge

두 번째 계층은 더 강력한 LLM이 다른 LLM의 결과를 명확한 루브릭에 따라 평가하는 방식입니다. 사람의 대규모 검토보다 훨씬 적은 자원으로 말투, 일관성, 근거 충실성, 관련성처럼 미묘한 품질을 측정할 수 있습니다.

좋은 가상 심사기를 만들기 위한 핵심은 모호하지 않은 루브릭입니다. 예를 들어 "설명이 읽기 쉽고 우리 기준에 맞는가?"라는 질문은 사람도 일관되게 적용하기 어렵기 때문에 LLM에는 더욱 부적합합니다.

글은 숙소 설명의 가독성을 판정하는 가상의 루브릭 예시를 제시합니다. 좋은 설명은 친절한 여행 상담원처럼 따뜻하지만 전문적이고, 자연스러우며, 문법적으로 완결되어야 합니다. 지나치게 격식적이거나 전문 용어가 많고, 너무 가볍거나 광고성 표현이 강하며, 로봇 같은 어조라면 실패입니다. 내부 용어, 인용부호, 글머리표, 문장 파편도 피해야 하며, 문장은 마침표로 끝나야 합니다.

"좋은 설명은 친절한 여행 상담원처럼 따뜻하지만 전문적이고, 단순하며 자연스럽고 문법적으로 완결되어야 한다."

심사 결과도 자유 텍스트가 아니라, 오류 유형과 설명을 담은 reason, 그리고 0 또는 1의 score를 포함한 명시적 JSON 형식으로만 반환하도록 요구합니다. 이처럼 기준과 출력 형식을 좁혀야 자동 평가 결과를 후속 시스템에서 안정적으로 활용할 수 있습니다.

가상 심사기를 신뢰할 수 있게 보정하기

보정되지 않은 가상 심사기는 아예 없는 것보다 위험할 수 있습니다. 그럴듯한 점수로 팀에 잘못된 확신을 주기 때문입니다. 에어비앤비가 제안하는 보정 과정은 다음과 같습니다.

1. 좋은 사례뿐 아니라 나쁜 사례도 포함한 50~100개 규모의 골든 데이터셋을 만듭니다.
2. 가상 심사기를 골든 세트에 실행합니다.
3. 사람의 라벨과 얼마나 일치하는지 측정합니다. 목표는 대체로 80% 후반~90%대의 일치율입니다.
4. 불일치 사례를 분석하고, 심사 프롬프트와 퓨샷 예시를 고친 뒤 다시 반복합니다.
5. 시간이 흐르며 실패 유형이 변하므로, 주기적으로 다시 보정합니다.

일치도는 Cohen's kappa나 Krippendorff's alpha 같은 통계 지표로도 측정할 수 있습니다. 다만 사람끼리도 완벽히 일치하지 않으므로, 완전한 100% 일치를 목표로 삼을 필요는 없습니다.

사람 평가가 반드시 필요한 순간

사람의 판단은 여전히 정답 데이터의 기준, 고위험 영역의 안전장치, 그리고 자동 평가기 간 충돌을 해결하는 최종 수단입니다.

글은 처음에는 도메인 전문가가 라벨을 붙인 20~100개 사례로 시작하라고 조언합니다. 대규모 라벨링 인력을 쓰는 것은 루브릭이 매우 견고하고, 진짜 병목이 처리량일 때만 고려해야 합니다.

특히 전문가들이 한 사례의 라벨에 동의하지 못한다면 자동화를 서두르면 안 됩니다.

"전문가들이 라벨에 동의하지 않는다면, 멈춰라. 무엇이든 자동화하기 전에 인간 사이의 불일치부터 해결하라."

개발 중, 출시 전, 운영 중이라는 각 단계에서도 세 방법은 모두 필요합니다. 코드 검사는 즉시 기본 오류를 막고, 가상 심사기는 대량의 품질 검증을 담당하며, 사람은 자동화가 놓칠 수 있는 중요한 예외와 판단 기준을 맡습니다.

4. 에이전트 시스템은 답변 과정까지 평가해야 한다

에이전트형 AI는 여러 단계의 추론, 도구 호출, 분기 로직, 중간 상태 전환을 수행합니다. 따라서 최종 답변만 평가해서는 부족합니다. 최종 답변이 우연히 맞더라도, 그 과정에서 잘못된 도구 매개변수를 사용했거나 불필요하게 긴 경로를 거쳤거나, 잘못된 추론을 했을 수 있기 때문입니다.

에어비앤비는 에이전트 평가를 다음 세 층위에서 수행해야 한다고 설명합니다.

• 단계 수준 평가: 개별 추론 단계나 도구 호출이 올바른지 확인합니다.
• 궤적 수준 평가: 전체 실행 경로가 합리적이고 효율적이었는지 살펴봅니다.
• 세션 수준 평가: 사용자와의 전체 상호작용이 궁극적으로 사용자의 목표를 달성했는지 판단합니다.

이를 위해 에이전트가 남기는 trace와 span, 즉 실행 기록을 활용합니다. 이 기록에는 어떤 에이전트와 하위 에이전트가 실행됐는지, 입력과 출력은 무엇이었는지, 어떤 도구를 호출했는지 등이 담깁니다. 이런 기록을 관측 플랫폼이나 영구 저장소에 보관한 다음, DFS 같은 트리 순회 방식으로 메모리에서 실행 경로를 재구성할 수 있습니다.

그 결과 특정 하위 에이전트가 적절한 시점에 호출됐는지, 올바른 도구를 사용했는지, 필요한 에이전트 또는 하위 에이전트만 범위로 좁혀 평가할 수 있습니다. 즉, 평가는 모델 하나가 아니라 검색·도구·에이전트·생성 단계를 포함한 전체 시스템을 대상으로 해야 합니다.

5. 여행 플랫폼 지원 AI의 실전 평가 과정

글은 여행 플랫폼의 지원 정책 질문에 답하는 가상의 AI 어시스턴트를 사례로, 처음부터 운영 모니터링까지의 과정을 설명합니다.

100개 사례를 읽고 실패 유형 찾기

먼저 프로토타입에 100개 입력을 넣고 모든 출력을 읽습니다. 그 결과 다음 문제가 발견됩니다.

• 15개 응답이 원본 문서에 없는 정책 세부 내용을 만들어 냈습니다. 이는 충실성(faithfulness) 문제입니다.
• 8개는 내용은 맞지만 너무 장황했습니다. 이는 간결성 문제입니다.
• 5개는 답할 수 있는 유효한 질문을 거절했습니다. 이는 과도한 거절(over-refusal) 문제입니다.
• 3개는 JSON 형식이 깨졌습니다. 이는 출력 형식 문제입니다.

이 단계에서 중요한 점은 일반적인 "도움이 되는가" 점수를 보지 않고, 제품에서 실제로 발견된 실패를 구체적인 평가 대상으로 바꾼다는 것입니다.

평가기를 만들고 골든 세트를 구성하기

다음으로 JSON 유효성 및 길이 범위를 확인하는 코드 기반 검사를 추가합니다. 동시에 충실성을 판단하는 가상 심사기와 간결성을 판단하는 별도 가상 심사기를 만듭니다. 충실성 심사기에는 생성 모델과 다른 모델, 분리된 프롬프트, 단계적 사고 방식을 사용합니다.

제품 관리자(PM) 또는 도메인 전문가는 실패 사례를 포함한 60개 예시에 라벨을 붙여 골든 세트로 만듭니다. 여기서도 각 평가기는 하나의 품질 차원에 집중합니다. 한 평가기가 모든 것을 판단하는 이른바 "신 평가기(God evaluator)"를 만들지 않는 것이 원칙입니다.

보정하고, 변수는 하나씩만 바꾸기

처음에 충실성 가상 심사기는 PM의 판단과 78%만 일치합니다. 이는 신뢰하기에 충분하지 않습니다. 불일치 사례를 분석해 보니, 심사기가 정확한 바꿔 말하기(paraphrase)까지 "원문에 충실하지 않다"고 잘못 판정하고 있었습니다.

그래서 루브릭을 수정하고 퓨샷 예시를 추가하자, 사람과의 일치율은 88%까지 올라갑니다. 이어 검색 단계를 개선하자 충실성 오류도 크게 줄어듭니다.

글은 모델과 프롬프트를 개선할 때 한 번에 여러 요소를 바꾸지 말라고 강조합니다.

"먼저 모델을 고정하고 프롬프트를 바꾸고, 다음에는 프롬프트를 고정한 채 모델을 바꾸고, 그다음에 둘 다 고정한 상태에서 서빙 구성을 바꿔라."

각 단계에서 가상 심사기 결과로 후보군을 좁히고, 상위 후보의 샘플을 이용해 다시 가상 심사기를 개선합니다. 이런 반복을 통해 후보 시스템과 평가기 자체가 서로를 더 정교하게 만들며, 둘 다 안정화될 때까지 발전합니다.

대규모 평가와 운영 중 감시

평가기와 시스템이 어느 정도 안정되면 평가 범위를 5,000개 사례로 확장합니다. 운영 환경에서는 매일 비식별화된 실제 트래픽의 5%를 표본 추출해 코드 기반 검사와 가상 심사기를 실행합니다. 문제가 표시된 출력은 사람이 검토하고, PM은 매주 결과를 검토합니다.

이 과정에서 새 실패 유형이 발견되면 새로운 평가기를 추가하고, 시스템도 그에 맞춰 개선합니다. 즉, 운영 환경의 평가는 출시 전 한 번 하고 끝나는 검사가 아니라 계속 닫히는 개선 순환 고리입니다. 🔄

또한 실제 사용자 데이터는 사람 검토 전에 강력한 비식별화 처리를 거치며, 사용 목적도 안전성과 품질 보증으로 엄격히 제한됩니다. 이는 에어비앤비의 개인정보 보호 원칙에 맞추기 위한 조치입니다.

6. 핵심 교훈과 마무리

글은 생성형 AI 제품의 성공이 단순히 가장 뛰어난 모델을 선택하는 데 달려 있지 않다고 결론짓습니다. 더 중요한 것은 실제 사용자 경험에서 실패를 찾아내고, 이를 측정 가능한 기준으로 만들며, 자동화와 사람의 판단을 결합해 지속적으로 개선하는 능력입니다.

특히 기억할 핵심은 다음과 같습니다.

1. 출력과 실행 기록을 직접 읽는 것이 모든 평가의 출발점입니다.
2. 일반적 지표보다 제품에서 실제로 일어나는 고유한 실패 유형을 측정해야 합니다.
3. 처음에는 50~100개 사례로 빠르게 실패하고 저렴하게 반복해야 합니다.
4. 평가기는 한 가지 품질 차원에 집중시켜야 합니다.
5. 가상 심사기는 사람과 80% 후반~90%대의 일치율을 달성하기 전까지 대규모로 신뢰해서는 안 됩니다.
6. 코드 기반 검사, 가상 심사기, 사람 평가를 함께 쓰는 다층 방어 체계가 필요합니다.
7. 골든 세트에는 반드시 나쁜 사례를 포함해야 합니다.
8. 모델만이 아니라 검색, 도구 호출, 전체 파이프라인을 평가해야 하며, 에이전트는 최종 답변뿐 아니라 실행 경로도 봐야 합니다.
9. 출시 전 평가를 운영 환경에도 반영해 지속적으로 감시해야 합니다.
10. 평가는 팀 스포츠입니다. 제품 성공의 정의를 만드는 일에는 엔지니어, PM, 도메인 전문가 등 여러 사람이 함께 참여해야 합니다.

"AI에서 성공하는 팀은 최고의 모델을 가진 팀이 아니라, 최고의 소통과 가장 명확한 제품 비전을 가진 팀이다."

결국 평가 주도 개발은 AI의 오류를 없애겠다는 단순한 품질 관리 기법이 아닙니다. 제품이 사용자에게 어떤 경험을 제공해야 하는지 팀이 명확히 합의하고, 실제 데이터로 그 약속을 계속 검증하는 개발 문화입니다.