80% 신뢰도로는 부족하다: 고객 신뢰를 얻는 평가 플라이휠

URL: https://www.youtube.com/watch?v=Emo5FGGY-wM 날짜: 2026-10-09 채널: aiDotEngineer 원문 제목: Why 80% Reliability Isn't Good Enough — Felipe Blanes, Amazon AGI Lab 발표자: Felipe Blanes, Amazon AGI Lab 기술 스태프

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 제품의 평가 점수가 높아도 고객이 실제 업무를 맡길 수 없다면 성공이 아니며, 고객의 실제 사용 신호를 평가에 계속 반영하는 플라이휠이 신뢰를 만든다.==

• 공개 벤치마크와 합성 데이터에 맞춘 정적 평가(evals)는 고객이 예상 밖으로 사용하는 순간의 실패를 포착하지 못한다.
• 80% 신뢰도는 고객에게 에이전트를 감시하고 실패 뒤 수작업을 해야 한다는 뜻으로 읽히지만, 약 90%에 도달하면 업무 흐름을 통째로 넘길 수 있다는 메시지로 바뀐다.
• 성공 기준을 고객에게서 정의하고, 생산 환경 신호를 수집하고, 모델·엔지니어링·제품의 간극을 진단하고, 우선순위를 정해 다시 평가에 반영해야 한다.

벤치마크를 더 좋은 것으로 교체하는 일만으로는 생산 환경의 간극을 닫을 수 없다. 고객과 직접 대화하고 사용 데이터를 관찰해 고객이 실제로 중요하게 여기는 성공을 정의한 뒤, 고객 여정이 바뀔 때마다 평가도 함께 진화시켜야 한다.

1. Amazon AGI Lab의 제품 여정과 문제의 배경

Amazon AGI Lab은 브라우저에서 할 수 있는 일을 자동화하는 에이전트 제품을 연구 미리보기에서 AWS의 프로덕션 서비스로 발전시켰고, 그 과정에서 고객 신뢰를 얻는 평가 체계의 필요성을 확인했다.

1.1. Nova 브라우저 에이전트의 발전

1. 연구 미리보기 출시

   1. 출시 시점: 전년 3월에 Nova 연구 미리보기를 공개했다.
   2. 제품 역할: Nova는 브라우저 에이전트를 만들도록 돕는 도구이며, 웹 브라우저에서 수행하는 거의 모든 작업을 자동화할 수 있다.
   3. 초기 목표: 완성된 제품을 가정하기보다 고객에게 먼저 배포해 최대한 많은 피드백을 받는 데 초점을 맞췄다.

2. 개발자 경험 개선

   1. 발견한 간극: 첫 몇 달 동안 고객이 에이전트를 만드는 개발자 경험에 부족한 점이 드러났다.
   2. 7월의 개선: 고객이 에이전트를 더 나은 경험으로 만들 수 있도록 개발자 경험 전체를 새로 설계했다.

3. AWS 서비스화

   1. 12월의 전환: Nova 서비스를 AWS에서 정식으로 출시했다.
   2. 현재의 사용 범위: 누구나 프로덕션 수준의 에이전트를 구축할 수 있는 AWS의 핵심 서비스로 자리 잡았다.

1.2. 고객 지원 업무에서 얻은 관찰

1. 고객 지원의 실제 의미

   1. 일상적 협업: 고객과 매일 협력하며 고객의 문제와 제품이 문제 해결을 돕는 방식을 파악했다.
   2. 역할의 위치: 제품이 연구 미리보기에서 AWS 서비스로 발전하는 동안 고객 활성화(customer enablement)를 담당했다.

2. 고객 신호의 중요성

   1. 사용 맥락의 필요: 제품 내부 지표만으로는 고객이 무엇을 해결하려 하는지 완전히 알 수 없다.
   2. 평가 개선의 출발점: 고객의 실제 목표와 실패 상황이 이후 평가 시나리오와 제품 우선순위를 결정한다.

2. 벤치마크 착시와 정적 평가의 한계

공개 벤치마크나 직접 만든 합성 데이터에서 높은 점수를 얻는 일과 고객이 프로덕션에서 제품을 신뢰하는 일 사이에는 큰 간극이 있다.

2.1. 벤치마크 착시가 생기는 과정

1. 평가 최적화의 유혹

   1. 공개 벤치마크: AI 팀은 모두가 사용하는 공개 벤치마크를 기준으로 제품을 최적화한다.
   2. 내부 벤치마크: 팀이 직접 만든 합성 데이터와 평가 세트를 사용해 제품을 측정하기도 한다.
   3. 목표의 편향: 평가 점수에서 최고가 되는 일이 실제 고객의 성공보다 앞서기 쉽다.

2. 프로덕션에서 드러나는 예상 밖 사용

   1. 고객의 행동: 고객은 팀이 예상하지 않은 작업을 시도한다.
   2. 제품의 붕괴: 정적 평가에서 드러나지 않은 입력과 흐름이 제품을 깨뜨린다.
   3. 핵심 원인: 평가가 정적 상태에 머물러 고객의 사용 방식과 함께 변하지 않는다.

2.2. 표준 개발 과정이 만드는 ‘희망’의 단계

1. 요구사항부터 평가까지

   1. 요구사항 수령: 제품 체인에서 요구사항을 받고 제품을 만들기 시작한다.
   2. 평가 실행: 제품이 충분히 다듬어지면 공개 벤치마크나 합성 데이터로 평가하고 그 점수에 맞춰 최적화한다.
   3. 출시 판단: 팀이 편안함을 느끼는 점수에 도달하면 고객에게 제품을 배포한다.

2. 정적 평가 이후의 공백

   1. 남는 선택지: 제품을 출시한 뒤 정적 평가로 할 수 있는 일은 평가가 고객 행동을 정확히 반영했기를 바라는 것뿐이다.
   2. 실패의 귀결: 평가가 고객 행동을 반영하지 못했다면 실제 사용이 시작되는 순간 실패가 나타난다.
   3. 문제의 본질: 더 좋은 벤치마크를 찾는 문제가 아니라 고객 피드백을 다시 제품 개선으로 연결하는 고객 루프를 닫는 문제다.

3. 고객 피드백을 평가로 되돌리는 Eval Flywheel

평가 플라이휠은 고객이 중요하게 여기는 성공을 정의하고, 실제 사용 신호를 모으고, 간극을 행동 가능한 영역으로 나누고, 우선순위에 따라 개선한 뒤 다시 같은 순환을 실행하는 구조다.

3.1. 1단계: 고객 기준으로 성공 정의하기

1. 성공의 주체 전환

   1. 잘못된 기준: 팀이 성공이라고 생각하는 상태를 먼저 정하고 그 기준에 맞춰 제품을 평가하지 않는다.
   2. 올바른 기준: 고객이 성공이라고 생각하는 결과와 해결하려는 문제를 기준으로 삼는다.

2. 고객 목표의 구체화

   1. 문제 확인: 고객이 어떤 업무를 해결하려 하는지 확인한다.
   2. 제품 적합성 확인: 만들고 있는 기능이 고객 문제를 실제로 해결하는지 확인한다.

3.2. 2단계: 사용 신호를 수집하기

1. 계측과 데이터

   1. 엔지니어의 첫 반응: 제품에 계측을 넣고 고객 행동에 대한 지표와 데이터를 최대한 많이 수집한다.
   2. 관찰 대상: 고객이 어떤 입력을 넣고 어떤 흐름을 실행하며 어디에서 실패하는지 기록한다.

2. 고객과 직접 대화하기

   1. 대화의 실행: 고객에게 연락하고 회의를 잡고 고객을 직접 방문한다.
   2. 데이터의 한계: 계측 데이터만 보면 고객이 해결하려는 핵심 문제를 놓치거나 지표를 오해할 수 있다.
   3. 보완 정보: 고객이 실제로 시도한 일과 원하는 결과를 직접 들은 통찰을 계측 신호와 함께 사용한다.

3.3. 3단계: 간극을 행동 가능한 영역으로 진단하기

1. 모델 영역

   1. 실패 위치 파악: 모델이 어떤 입력과 작업에서 실패하는지 확인한다.
   2. 평가 반영: 모델 실패에서 얻은 사례를 모델 평가 시나리오로 되돌린다.

2. 엔지니어링 영역

   1. 하네스 간극: 제품의 하네스나 구현에 어떤 부족함이 있는지 파악한다.
   2. 전통적 버그 수정: 엔지니어링 팀이 고칠 수 있는 결함으로 분류하고 수정한다.

3. 제품 영역

   1. 이해 가능성: 고객이 제품이 해결하려는 문제를 정확히 이해하는지 확인한다.
   2. 포지셔닝: 제품이 적절하게 포지셔닝되어 있는지, 고객 기대가 제품 범위와 맞는지 점검한다.

3.4. 4단계: 의사결정으로 연결하고 반복하기

1. 우선순위화

   1. 팀별 배분: 발견한 간극을 우선순위에 따라 정리한다.
   2. 실행 주체: 과학 연구팀, 엔지니어링팀, 제품팀이 각자의 간극을 해결하도록 결정한다.

2. 반복 속도

   1. 플라이휠의 본질: 고객 신호 수집부터 진단과 의사결정까지의 순환을 계속 반복한다.
   2. 개선의 방향: 한 번 만든 평가를 고정하지 않고 고객의 다음 사용 신호를 다시 평가에 넣는다.

4. 고객 여정에 따라 달라지는 학습

고객은 제품을 사용하는 동안 자신이 할 수 있는 일을 넓히고, 고객 수가 늘어나면 반복되는 대표 사용 사례가 나타나며, 동시에 미래 제품 간극도 드러낸다.

4.1. 초기부터 확장까지의 네 가지 학습

1. 사용 사례 발견

   1. 첫 만남의 질문: 고객이 가진 문제를 이해하고 제품이 그 문제를 해결하는지 확인한다.
   2. 초기 단계의 기준: 고객이 원하는 일과 제품이 제공해야 할 핵심 가치의 일치 여부를 검증한다.

2. 얼리 어답터가 보여주는 가능성

   1. 예상 밖 실험: 얼리 어답터는 과감한 일을 시도하고 기존 제품이 전혀 도울 수 없는 작업도 찾아낸다.
   2. 새로운 활용: 팀이 한 번도 상상하지 못한 방식으로 제품을 사용해 새로운 가능성을 드러낸다.

3. 확장에서 발견하는 영웅 사용 사례

   1. 패턴 인식: 고객 수가 늘어나면 여러 고객에게 반복되는 사용 패턴을 찾을 수 있다.
   2. 영웅 사용 사례: 대부분의 고객이 제품으로 해결하려는 대표 문제와 업무가 핵심 사용 사례가 된다.

4. 제품 간극과 미래 로드맵

   1. 간극 수집: 얼리 어답터와 확장 단계 고객 모두 제품이 채우지 못하는 부분을 드러낸다.
   2. 미래의 기반: 제품팀은 간극을 우선순위화하고 다음에 만들 기능의 기반으로 삼는다.

4.2. 신뢰 절벽: 80%와 90% 사이의 의미 변화

1. 80% 신뢰도의 실제 의미

   1. 표면적 해석: 제품팀은 80%의 신뢰도가 충분히 괜찮다고 생각할 수 있다.
   2. 고객의 해석: 고객은 에이전트를 계속 감시해야 하고, 실패하면 직접 수작업을 해야 한다고 받아들인다.
   3. 비용의 역전: 에이전트를 추가하는 동시에 감시와 수동 처리를 더해야 하므로 업무가 줄지 않고 오히려 늘어난다.

2. 약 90%에서 일어나는 전환

   1. 신뢰 메시지 변화: 약 90%의 신뢰도에 도달하면 고객은 실제 업무를 맡길 수 있다고 판단한다.
   2. 업무 위임: 고객은 하나의 워크플로를 에이전트에 통째로 넘길 수 있다고 느낀다.

3. 신뢰의 이진성

   1. 0과 1의 상태: 신뢰도 수치는 연속적인 점수처럼 보이지만 고객 관점에서 신뢰는 0 또는 1에 가깝다.
   2. 중간 상태의 부재: 에이전트를 믿고 맡기거나 믿지 못하고 감시하는 선택 사이에는 실무적으로 큰 중간 지대가 없다.

4.3. 평가 투명성이 만드는 신뢰

1. 무엇이 잘 작동하는가

   1. 성능 공개: 제품이 어떤 작업을 잘 수행하는지 고객에게 보여준다.
   2. 신뢰 가능한 범위: 해당 작업에서 어느 수준의 신뢰도와 결과를 기대할 수 있는지 알려준다.

2. 무엇을 개선하고 있는가

   1. 알려진 간극: 현재 부족하지만 팀이 파악하고 있는 문제를 밝힌다.
   2. 개선 투자: 해당 문제를 더 나아지게 하려고 지금 투자하고 있는 작업을 공유한다.

3. 무엇이 범위 밖인가

   1. 어려운 공개: 제품이 하지 못하는 일을 인정하는 일은 가장 어렵지만 반드시 필요하다.
   2. 실패 방지: 고객이 범위 밖 작업을 시험하게 두지 말고 처음부터 작동하지 않는다고 알려야 한다.
   3. 전환 비용: 시장에 도구가 많기 때문에 고객이 제품이 안 되는 일을 시도했다가 실패하면 제품을 잊고 다음 도구로 이동할 수 있다.

4. 투명성과 벤치마크의 비교

   1. 핵심 발견: 제품의 한계를 투명하게 공개하는 일이 더 높은 벤치마크 점수보다 고객 신뢰를 더 크게 높인다.
   2. 공개 범위: 제품이 할 수 있는 일뿐 아니라 할 수 없는 일을 특히 분명하게 말해야 한다.

5. 고객 협업에서 발견한 구체적 사례

고객과 밀접하게 일하면 예상하지 못한 비용 최적화, 사용자층 확대, 제품 유연성 요구를 발견하고 다음 기능의 방향을 구체화할 수 있다.

5.1. Amazon Leo: 궤적 캐싱으로 비용 최적화

1. 사용 맥락

   1. 조직: Amazon Leo는 Amazon의 위성 인터넷 사업이다.
   2. 발견한 요구: 고객이 제품을 사용할 때마다 매번 추론을 실행하지 않아도 되는 방법이 필요했다.

2. 해결 방향

   1. 궤적 캐싱: 이전에 수행한 작업의 궤적(trajectory)을 캐시하도록 기능을 만들었다.
   2. 안전한 폴백: 캐시된 궤적이 실패하면 모델로 되돌아가도록 구성했다.
   3. 효과: 모든 요청에 추론을 반복하지 않아도 되어 Amazon Leo의 비용을 최적화했다.

5.2. Hertz: 기술 수준이 다른 QA 인력 지원

1. 기존 사용 사례

   1. 조직: Hertz는 자동차 렌털 회사다.
   2. 업무: 제품을 QA 자동화에 사용했다.

2. 사용자층의 차이

   1. 기술 인력: 일부 QA 엔지니어는 기술 수준이 높아 Python과 다른 프로그래밍 언어로 스크립트를 작성할 수 있었다.
   2. 비기술 인력: QA 조직의 다른 사람들은 같은 수준의 프로그래밍 역량을 갖추지 못했다.

3. 제품 방향의 변화

   1. 발견한 요구: 기술 지식이 적은 QA 담당자도 사용할 수 있는 경험이 필요했다.
   2. 기능 결과: 더 많은 고객이 사용할 수 있도록 비기술 사용자용 경험 전체를 구축했다.

5.3. Sol: 다양한 RPA 사용 사례를 위한 유연성

1. 사업 특성

   1. 조직: Sol은 다른 회사의 프로세스를 자동화하는 RPA(robotic process automation) 스타트업이다.
   2. 사용 사례의 폭: 반복 프로세스 자동화를 제공하므로 회사마다 매우 다양한 업무를 다룬다.

2. 제품 요구

   1. 발견한 요구: 정해진 한 가지 흐름만 제공하면 다양한 고객 업무를 수용하기 어렵다.
   2. 유연성: 고객이 제품을 자신의 필요에 맞게 조정할 수 있는 추가적인 유연성이 필요했다.

3. 구현 방향

   1. 작동 계층 조정: 특히 도구의 actuation stack, 즉 실제 동작을 수행하는 계층을 고객이 맞춤화할 수 있게 해야 했다.
   2. 학습의 의미: 고객이 실제로 하려는 일을 파악하면 다음 기능과 제품 설계의 방향이 구체화된다.

6. 평가 플라이휠을 운영하는 네 가지 원칙

고객 신호를 빠르게 평가와 의사결정으로 되돌리고, 팀과 고객 모두에게 제품의 실제 능력 범위를 정직하게 공개해야 한다.

6.1. 생산 환경에서 평가 시나리오를 도출하기

1. 상상보다 실제 사용

   1. 기준: 평가 시나리오는 팀의 상상이나 합성 데이터만으로 만들지 않는다.
   2. 출처: 프로덕션에서 실제로 발생한 고객 사례와 실패에서 도출한다.

2. 합성 데이터의 위치

   1. 초기 유용성: 제품 개발 초기에 합성 데이터를 만드는 일은 중요하다.
   2. 고객 유입 이후: 고객 신호가 쌓이기 시작하면 반드시 그 신호를 평가에 반영한다.

6.2. 행동 가능한 영역으로 분류하기

1. 분류 기준

   1. 제품 문제: 제품의 사용성, 이해 가능성, 포지셔닝에서 생긴 문제를 분리한다.
   2. 엔지니어링 문제: 구현과 하네스에서 고칠 수 있는 문제를 분리한다.
   3. 연구 문제: 모델이 특정 입력이나 작업을 처리하지 못하는 문제를 분리한다.

2. 팀의 실행

   1. 우선순위: 세 영역을 같은 방식으로 뭉뚱그리지 않고 해결 가능성과 영향에 따라 정렬한다.
   2. 책임 연결: 각 문제를 제품, 엔지니어링, 과학 팀의 실행 항목으로 연결한다.

6.3. 능력과 한계를 정직하게 공유하기

1. 공유 대상

   1. 가능한 일: 고객이 신뢰하고 맡길 수 있는 기능을 공개한다.
   2. 개선 중인 일: 현재 간극과 개선 계획을 공개한다.
   3. 불가능한 일: 제품 범위 밖의 작업을 명확하게 공개한다.

2. 신뢰 효과

   1. 기대 조정: 고객은 제품이 언제 실패할지 알고 적절한 업무만 맡길 수 있다.
   2. 신뢰 축적: 높은 점수만 제시하는 것보다 한계를 숨기지 않는 태도가 더 큰 신뢰를 만든다.

6.4. 플라이휠을 가능한 한 빠르게 돌리기

1. 속도와 개선

   1. 반복 주기: 고객 신호를 모으고 평가에 반영하는 속도가 빠를수록 제품 개선 속도도 빨라진다.
   2. 운영 원칙: 명백해 보이는 원칙이라도 고객 피드백과 평가 업데이트 사이의 시간을 줄이는 기준으로 계속 유지한다.

2. 평가의 신선도

   1. 주간 기대치: 평가가 매주 더 똑똑해지고 고객의 실제 문제를 더 잘 반영해야 한다.
   2. 정체 신호: 매주 평가가 똑똑해지지 않는다면 평가가 낡고 있다는 뜻이다.

7. 최종 결론과 실용적 시사점

고객이 중요하게 여기는 문제를 평가에 담고 고객의 변화에 맞춰 평가를 계속 갱신해야 에이전트가 실제 업무를 맡을 수 있는 수준의 신뢰를 얻는다.

7.1. 반드시 기억할 두 가지

1. 고객의 관심사를 평가하라

   1. 평가 기준: 평가가 반영해야 할 대상은 팀이 고객에게 중요하다고 추측하는 내용이 아니라 고객이 실제로 중요하게 여기는 내용이다.
   2. 실행 질문: 고객에게 무엇이 문제인지, 어떤 결과를 성공으로 보는지 묻고 그 답을 평가에 반영한다.

2. 평가는 한 번 만들고 끝내는 산출물이 아니다

   1. 플라이휠 관점: 평가는 고객이 진화할 때 함께 진화하는 순환 구조다.
   2. 고객 여정의 변화: 고객은 제품을 익힐수록 더 복잡한 일을 시도하므로 현재 고객이 하려는 일을 평가가 계속 반영해야 한다.

7.2. 실행 순서

1. 루프 구축: 고객 성공을 정의하고 신호를 수집하고 간극을 분류하는 루프를 제품 운영에 넣는다.
2. 중요한 평가 배포: 실제 업무에 의미 있는 평가를 제품 개선과 출시 판단에 사용한다.
3. 신뢰 획득: 고객이 감시와 수작업을 덧붙이지 않고 워크플로를 맡길 수 있을 때 제품의 가치가 실현된다.
4. 후속 대화: 발표 후 부스에서 추가 논의를 이어가며 고객의 구체적인 사례를 더 수집한다.

주요 발언 모음

“This is not about better benchmarks. It's about closing the customer loop.”

“Define success here: it's not what you think it's success; it's what your customer think it's success.”

“When you get to a point around 90% reliability, the message changes to your customer.”

“Reliability is a zero to one. You trust or you don't. There is nothing like in the middle there.”

“Transparent on product limitation increase trust more than higher benchmarks.”

“Derive eval scenarios from production, not imagination.”

“If you are not seeing your evals getting smarter every week, that means your evals are getting stale.”

“Evals are not built once. It's a flywheel that evolves as your customer evolves.”

핵심 데이터 & 수치

• 80% 신뢰도: 에이전트를 계속 모니터링하고 실패 뒤 수동 작업을 해야 하므로 고객에게 ‘맡길 수 없음’으로 읽힌다.
• 약 90% 신뢰도: 고객이 업무 흐름을 에이전트에 넘길 수 있다고 판단하는 신뢰 전환점으로 제시된다.
• 0과 1: 신뢰는 실무에서 연속 점수보다 맡기거나 맡기지 않는 이진적 판단에 가깝다.
• 전년 3월: Nova 연구 미리보기를 출시하고 고객 피드백 수집을 시작했다.
• 7월: 초기 고객 피드백에 따라 개발자 경험 전체를 개선했다.
• 12월: Nova를 AWS 서비스로 출시해 프로덕션 수준 에이전트 구축을 지원했다.
• 매주: 평가가 고객의 실제 문제를 더 잘 반영하도록 똑똑해져야 하며, 그렇지 않으면 낡은 평가로 간주한다.
• 네 단계: 고객 여정은 사용 사례 발견, 얼리 어답터의 가능성 발견, 확장 단계의 영웅 사용 사례, 제품 간극과 미래 기능 발견으로 나뉜다.
• 네 원칙: 생산 환경에서 시나리오 도출, 행동 가능한 영역으로 분류, 능력과 한계의 정직한 공유, 빠른 플라이휠 실행이 핵심 운영 원칙이다.

결론 및 시사점

1. 공개 벤치마크 점수는 고객의 실제 성공을 대신할 수 없으므로 프로덕션의 고객 행동과 실패를 평가의 원천으로 삼는다.
2. 80% 신뢰도는 감시와 수작업을 남겨 고객의 총비용을 높일 수 있으므로, 고객이 워크플로를 위임할 수 있는 신뢰 수준을 별도로 확인한다.
3. 제품이 하지 못하는 일을 명확히 밝히는 투명성이 높은 성능 수치만 제시하는 전략보다 장기적인 고객 신뢰를 높인다.
4. 모델·엔지니어링·제품 간극을 분리하면 각 팀이 실행 가능한 개선을 빠르게 선택할 수 있다.
5. 고객이 제품을 익혀 더 복잡한 작업으로 이동할수록 평가도 계속 진화해야 하며, 매주 평가가 더 똑똑해지는지 점검한다.