9%의 롤백(Rollback) 수치: Sinch 2026 연구가 실제로 말해주는 것

2026년 5월 13일에 발표된 2,527명의 시니어 AI 의사 결정권자 대상 설문조사 결과가 나왔습니다. 헤드라인 수치는 다음과 같습니다: 기업의 74%가 배포된 AI 고객 커뮤니케이션 에이전트(customer-communications agent)를 롤백(rollback)한 경험이 있습니다. 만약 여기서 읽기를 멈춘다면, 여러분은 에이전트 분야가 망가졌다고 생각할 것입니다. 하지만 그것은 틀렸습니다. 아직 아무도 인용하지 않고 있는 진짜 수치는 9%입니다. 이것은 완전한 자동화된 평가(automated evaluation) 커버리지를 실행 중인 팀들의 롤백(rollback) 비율입니다. 9%와 74% 사이의 격차는 이 보고서에서 가장 실행 가능한(actionable) 핵심 요소이며, 거의 아무도 이에 대해 이야기하지 않고 있습니다.

이 글은 제가 6개월 전 첫 번째 프로덕션 에이전트(production agent)를 디버깅(debugging)할 때 꼭 필요했던 내용입니다. 헤드라인이 아니라, 바로 이 격차에 대한 이야기입니다.

여러분을 걱정시켜야 할 수치

2026년 5월 13일 발표된 Sinch의 "AI 프로덕션 패러독스(AI Production Paradox)" 연구는 10개국 2,527명의 의사 결정권자를 대상으로 조사되었습니다. 자세히 들여다보기 전까지는 서로 맞지 않아 보이는 두 가지 숫자가 있습니다:

• 74% — 모든 응답자를 대상으로 한 전체 롤백(rollback) 비율
• 81% — 성숙한 거버넌스 프레임워크(mature governance frameworks)를 갖춘 조직의 롤백(rollback) 비율

네, 도구(tooling)를 더 잘 갖춘 팀들이 더 자주 롤백(rollback)을 합니다. 오타가 아닙니다. Forrester의 2026년 패널 연구는 그 이유를 분석합니다: 자동화된 평가(automated evals)가 없는 에이전트는 47%의 롤백(rollback) 비율을 보였고, 완전한 평가 커버리지(full eval coverage)를 갖춘 에이전트는 9%의 롤백(rollback) 비율을 보였습니다. 완전하게 평가된 에이전트들이 실패를 덜 하는 것이 아니라, 실패를 더 눈에 띄게 하는 것입니다. 실패를 볼 수 있는 팀은 고객에게 전달되기 전에 이를 잡아냅니다. 실패를 볼 수 없는 팀은 문제가 생기기 전까지는 괜찮다고 생각합니다.

만약 여러분이 프로덕션(production)에서 에이전트를 운영하고 있는데 평가 커버리지(eval coverage)가 없다면, 여러분은 9% 그룹에 속하지 않습니다. 여러분은 47%와 74% 사이 어딘가에 있으며, 아직 롤백(rollback)을 하지 않은 유일한 이유는 이를 인지할 수 있는 계측(instrumentation) 수단이 없기 때문입니다.

9%라는 수치를 따라 하기 어려운 이유

9% 그룹이 뭔가 특별한 것을 하고 있는 것은 아닙니다. 그들은 세 가지 지루한 일을 꾸준히 수행하고 있습니다:

1. 그들은 평가(evals)를 노트북 실험이 아닌 프로덕션 코드(production code)로 취급합니다. 평가 세트(Eval sets)는 저장소(repo)에 존재하며, 모든 PR(Pull Request)에서 실행되고, 회귀(regression)가 발생하면 CI(지속적 통합)를 실패시킵니다.
2. 그들은 단순히 실행(execution)이 아니라 결과(outcome)를 기록합니다. 입력 토큰, 출력 토큰, 지연 시간(latency), 모델 이름과 같은 호출 엔벨로프(call envelope)는 모든 관측성(observability) 도구가 무료로 제공하는 정보입니다. 하지만 결과 — 즉, 고객의 이메일에 실제로 올바른 답변이 전달되었는가 — 는 그 어떤 도구도 제공하지 않습니다. 그것은 직접 작성해야 합니다.
3. 그들은 매주 트레이스(traces)의 샘플을 읽기 위해 사람에게 비용을 지불합니다. 모든 트레이스가 아니라 샘플입니다. 사람의 역할은 에이전트(agent)를 수정하는 것이 아니라, 평가 격차(eval gap)를 찾아내는 것입니다.

이 목록에 포함되지 않은 것이 무엇인지 주목하십시오: 월 300달러의 LangSmith 청구서, Helicone 구독, Langfuse 배포, Arize Phoenix 설치, 또는 다른 11개의 관측성 벤더(observability vendors)는 여기에 없습니다. 도구는 도움이 됩니다. 9%라는 수치는 도구에 관한 것이 아닙니다. 그것은 세상이 의도와 일치했는지 확인하는 규율(discipline)에 관한 것이며, 이는 정의상 오직 인간만이 결정할 수 있는 일입니다.

10분 자가 진단: 당신은 9%입니까, 아니면 74%입니까?

지금 바로 당신의 에이전트 저장소(agent repo)에서 다음을 실행해 보십시오. 결과는 이진적(binary)입니다. 만약 어떤 답변이라도 "아니오" 또는 "모르겠습니다"라면, 당신은 롤백(rollback) 비율이 더 높은 그룹에 속해 있습니다.

# 1. 에이전트를 다시 실행하지 않고도
#    "최근 10개의 고객 대상 도구 호출이 올바르게 수행되었는가"에 답할 수 있습니까?
grep -E "outcome_verify|post_action_check" logs/ | tail -10
...

만약 이 세 가지 질문 중 어느 하나라도 "아니오" 또는 "모르겠습니다"라고 답했다면, 9% 그룹은 당신의 동료 그룹이 아닙니다. 당신의 동료 그룹은 47%(평가 없음) 또는 74%(결과 계측 없음)입니다.

이번 주에 바로 따라 할 수 있는 9% 그룹의 행동

벤더(vendor)는 필요 없습니다. 당신에게 필요한 것은 세 가지 습관과 0달러짜리 툴체인(toolchain)입니다.

습관 1: 결과 중심 로깅(outcome-line logging), 부수 효과(side-effecting)가 있는 도구 호출당 한 줄씩

에이전트 내에서 상태를 변경하는 다섯 가지 도구를 선택하세요: send_email, charge_card, create_ticket, update_record, send_slack. 각 도구에 대해, 호출이 성공적으로 반환된 후, _호출 이후 세상이 어떤 모습이기를 의도했는지_를 기록하는 단 한 줄의 로그를 남기세요. 그 한 줄이 바로 당신의 결과 어설션 (outcome assertion) 입니다.

# 이전 방식 — 실행만 수행
logger.info("send_email", to=to, subject=subject, message_id=resp["id"])
# 대시보드 표시: 성공. 당신은 이제 눈이 먼 상태입니다.
...

outcome_verify_at 라인은 스케줄링된 작업 (scheduled job) 입니다. 이 작업이 실행되었을 때 실제 세상이 의도와 일치하지 않는다면, 당신은 일반적인 200 응답이 아닌 버그 리포트처럼 읽히는 로그 라인을 받게 됩니다. 이것이 47% 그룹과 9% 그룹의 차이입니다.

습관 2: 예외 없는 주간 인간 트레이스 리뷰 (weekly human trace review), 20분

지난 한 주 동안의 트레이스 (traces) 중 20개를 선택하세요. 실패한 것과 "성공한" 것을 섞으세요. 그것들을 읽으세요. 다음 사항들을 확인하세요: 도구 호출 (tool call)이 사용자의 의도와 일치했는가, 아니면 에이전트가 코드로 작성되지 않은 디스패처 (dispatcher) 상의 엣지 케이스를 스스로 만들어냈는가? 모델이 스키마 (schema) 상으로는 Y를 반환한다고 되어 있음에도 불구하고 X를 반환했다고 주장했는가? 고객이 요청한 것을 받았는가, 아니면 모델이 고객이 받아야 한다고 생각한 것을 받았는가?

이것은 소프트웨어가 당신을 대신해 해줄 수 있는 일이 아닙니다. LangSmith는 트레이스를 보여줄 뿐이며, 읽는 것은 당신의 몫입니다. 코드 리뷰 도구가 디프 (diffs)를 보여주면 사람이 읽는 것과 같은 방식입니다. 9%라는 수치는 트레이스 수집 수치가 아니라, 인간이 읽은 수치입니다.

습관 3: 노트북에 머무는 것이 아닌, CI를 실패시키는 평가 세트 (eval set)

모든 PR (pull request)에서 실행되는 평가 세트는 배포 전 회귀 (regressions)를 잡아냅니다. 노트북에 머무는 평가 세트는 고객이 불만을 제기한 후에야 회귀를 잡아냅니다. CI 훅 (hook)이 그 차이를 만듭니다. 평가 세트 자체는 30개의 예시일 수도 있습니다. 직접 손으로 작성할 수도 있습니다. 정교할 필요는 없습니다. 에이전트의 성능이 퇴보했을 때 빌드를 실패시켜야 합니다.

# .github/workflows/agent-evals.yml
name: agent evals
on: [pull_request]
...

아무도 쓰지 않는 관점

아무도 쓰지 않는 관점

9% 대 47%의 격차는 도구(tooling)의 격차가 아닙니다. 그것은 인간의 주의력(human attention) 격차입니다. 9% 수치를 기록한 팀들은 트레이스(trace)에 대한 주간 단위의 인간 검토, 결과 라인 스키마(outcome-line schema), 그리고 CI를 실패시키는 평가 세트(eval set)를 제도화했습니다. 47% 수치를 기록한 팀들은 관측성(observability) 벤더가 "자동 롤백 감지(auto-rollback-detection)" 기능을 출시하기만을 기다리고 있습니다. 하지만 이 기능은 정의상 위에서 언급한 결과 라인 스키마 없이는 존재할 수 없습니다.

9%라는 수치는 재현 가능합니다. 엔터프라이즈 규모의 인프라, 10명의 엔지니어 팀, 또는 월 3,000달러의 관측성 비용이 필요하지 않습니다. 일주일에 20분의 인간의 주의력, 10줄 정도의 결과 로깅(outcome-logging) 스키마, 그리고 CI를 실패시키는 30개의 예시 평가 세트만 있으면 됩니다. 이 중 어느 것도 생소한 것이 아닙니다. 이 모든 것들은 "배포 완료"와 "운영 환경 장애" 사이에서 놓치기 쉬운 것들이며, 바로 포렌식 로그 검토(forensic log review)가 메우기 위해 만들어진 지점입니다.

향후 90일 이내에 에이전트(agent)를 배포할 예정이라면 의미하는 바

Sinch의 연구는 74%의 사람들에게는 나쁜 소식이지만, 만약 당신이 이에 따라 행동한다면 당신에게는 좋은 소식입니다. 이번 주에 다음 세 가지 조치를 순서대로 취하십시오:

1. 상태를 변경하는 5개의 도구(tool)에 outcome_assertion 라인을 추가하십시오. 단 5줄의 코드면 충분합니다. 벤더는 필요 없습니다.
2. CI를 실패시키는 평가 세트(eval set)를 구축하십시오. 시작 단계에서는 직접 작성한 30개의 예시로도 충분합니다. 고객이 불만을 제기할 때가 아니라, 회귀(regression)가 발생했을 때 빌드가 실패하는 것을 목표로 하십시오.
3. 이번 주 금요일 일정에 20분을 할당하여 20개의 트레이스(trace)를 읽으십시오. 실패한 케이스와 "성공한" 케이스 모두 포함합니다. 발견한 내용을 기록하십시오. 평가 세트가 커버하지 못하는 항목들의 목록이 바로 당신의 로드맵입니다.

이 중 어느 것도 제품(product)이 아닙니다. 이것은 규율(discipline)입니다. 9%라는 수치는 제품의 수치가 아니라 규율의 수치입니다. 만약 당신의 규율이 실제로 올바른 것들을 잡아내고 있는지 확인하기 위해 제3자의 시각이 필요하다면, 다음 단계는 일주일 동안 인간에게 비용을 지불하고 트레이스를 읽게 하는 것입니다. 하지만 이는 반드시 위의 세 가지 습관이 자리 잡은 후에만 수행해야 합니다. 스키마 없는 인간의 검토는 단순한 의견일 뿐이지만, 스키마가 있는 인간의 검토는 포렌식(forensic)입니다.

9%는 마법이 아닙니다. 세 가지 습관과 일정 예약일 뿐입니다. 74%는 당신이 이 습관들을 건너뛸 경우 마주하게 될 결과입니다.