에이전트를 출시하는 모든 팀은 똑같은 회의를 거칩니다. 누군가 "준비되었나요?"라고 물으면 회의실은 의견이 갈립니다. 한 사람은 멋진 데모를 보았지만, 다른 사람은 한 시간 전에 에이전트가 환불 정책을 마음대로 만들어내는 것을 목격했습니다. 논쟁은 겉돌기만 합니다. 왜냐하면 아무도 "준비되었다"는 것이 무엇을 의미하는지 합의하지 않았기 때문입니다. 결국 가장 목소리가 큰 사람의 의견이 승리하고, 에이전트는 단지 느낌(vibe)에 따라 출시됩니다.

AI 에이전트를 프로덕션 준비(production-ready) 상태로 만드는 것은 확신의 순간이 아닙니다. 그것은 구축하기 전에 미리 적어두고, 그에 따라 측정해야 하는 기준(bar)입니다. 이 포스트는 그 기준에 관한 것입니다. 왜 에이전트가 이미 출시하고 있는 서비스들과는 다른 기준이 필요한지, 그리고 "준비되었나요?"라는 질문이 논쟁이 아닌 숫자가 되도록 어떻게 기준을 정의할 수 있는지에 대해 다룹니다.

왜 에이전트에게는 "프로덕션 준비" 개념이 깨지는가

일반적인 서비스의 경우, "프로덕션 준비"는 확립되어 있습니다. 유효한 입력에 대한 올바른 출력, 에러 처리, 지연 시간(latency) 목표 달성, 테스트 및 롤백(rollback) 기능 등이 갖춰져야 합니다. 완료된 상태의 형태를 알고 있는 것입니다. 하지만 에이전트는 이 가정들 중 세 가지를 동시에 깨뜨립니다:

• 비결정론적(non-deterministic)입니다. 동일한 입력에 대해 서로 다른 출력이 나올 수 있으므로, "정확함"은 "충분히 자주, 수용 가능한 수준으로 맞음"이 됩니다.
• 실패 지점(failure surface)이 개방적입니다. 함수는 당신이 열거한 방식으로 실패하지만, 에이전트는 언어, 도구, 판단을 즉석에서 조합하기 때문에 당신이 전혀 상상하지 못한 방식으로 실패합니다.
• 최악의 상황은 500 에러가 아닙니다. 그것은 맞은 것처럼 보이는 확신에 찬 오답입니다. 이는 시스템 충돌(crash)보다 훨씬 더 비용이 많이 드는데, 충돌은 적어도 실패했다는 사실을 알려주기 때문입니다.

따라서 정직한 질문은 "에이전트가 정확한가"가 아닙니다. "에이전트가 안전하게, 예산 범위 내에서, 그리고 신뢰할 수 있을 만큼 충분히 반복 가능하게, 수용 가능한 수준으로 틀리는가"입니다. 그 질문은 네 가지 부분으로 나뉘며, 각 부분은 당신의 기준을 구성하는 한 줄의 선이 됩니다.

기준을 구성하는 네 가지 선

구축하기 전에 이것들을 적어두세요. 만약 이것들을 채울 수 없다면, 당신은 사양(spec)을 가진 것이 아니라 바람(wish)을 가진 것뿐입니다.

1. 태스크 성공 (Task success). 해피 패스(happy-path) 데모가 아닌, 고정된 실제 태스크 세트에서 에이전트가 정확하게 완료해야 하는 비율은 얼마입니까? 숫자를 선택하세요. 85%는 7명 중 1명의 사용자가 틀린 답변을 받는다는 의미입니다. 이 직무에 허용 가능한 수준인가요, 아니면 해고 사유인가요? 의도적으로 결정하십시오.
2. 실패 허용 가능성 (Failure acceptability). 모든 잘못된 결과가 동일한 것은 아닙니다. "확실하지 않습니다, 사람에게 연결해 드릴게요"라고 말하는 에이전트는 우아하게 실패(failed gracefully)한 것입니다. 반면, 정책을 임의로 만들어내고 자신 있게 말하는 에이전트는 위험하게 실패(failed dangerously)한 것입니다. 당신이 설정한 기준(bar)은 어떤 실패를 허용하고 어떤 실패를 결격 사유로 볼 것인지를 결정합니다.
3. 비용 및 지연 시간 상한 (Cost and latency ceiling). 정답을 맞히더라도 호출당 40초가 걸리고 3달러가 소요되는 에이전트는 채팅창에 배치할 준비가 되지 않은 것입니다. 예산은 부연 설명이 아니라 정확성(correctness)의 일부입니다.
4. 격리 (Containment). 에이전트가 틀렸을 때(그리고 반드시 틀릴 때), 피해를 막는 것은 무엇입니까? 인간의 개입(human in the loop) 없이 돈을 옮기거나, 데이터를 삭제하거나, 고객에게 이메일을 보낼 수 있습니까? 기준은 당신이 수용할 수 있는 폭발 반경(blast radius)을 정의합니다.

이 중 어느 것도 "데모가 작동했다"는 것과 같지 않습니다. 데모는 친절한 운영자가 있는 단일 샘플일 뿐입니다. 기준은 당신이 직접 선별하지 않은 입력값에 대해 에이전트에게 요구하는 것입니다.

먼저 의도적으로 정의하십시오

사후에 작성된 기준은 조작된 것입니다. 일단 작동하는 에이전트를 갖게 되면, 모든 임계값(threshold)은 에이전트가 이미 달성한 점수에 맞춰 조용히 미끄러집니다. 82%는 "80%면 괜찮아"가 됩니다. 무서운 실패 모드는 "예외 케이스(edge case)"가 됩니다. 당신은 자신이 만든 것을 자신이 의도했던 것으로 합리화하게 될 것입니다. 기준을 통과하지 못할 용기가 아직 남아 있을 때 숫자를 설정하십시오.

이 내용 중 어느 것도 아직 기준을 어떻게 측정할지는 알려주지 않습니다. 그것은 평가 세트(eval set)가 사후 고려 사항이 아닌, 당신이 실제로 구축하고 있는 제품이 되는 파트 2에서 다룹니다. 지금 당장의 승리는 더 작으면서도 동시에 더 큽니다. 다음에 누군가 "준비되었나요?"라고 물을 때, 당신은 논쟁하지 않습니다. 대신 기준을 가리킵니다.

데모는 일화(anecdote)입니다. 기준은 계약(contract)입니다. 정의하기를 거부하는 것은 출시할 수 없습니다.