저는 생업으로 다른 기업들을 위한 AI 에이전트 (AI agents)를 구축합니다. 제가 가장 자주 목격하는 패턴은 "모델이 할 수 없다"가 아닙니다. 그것은 "데모는 작동했고, 제품을 출시했는데, 이제는 세 번 중 한 번꼴로 실패하며 아무도 그 이유를 말하지 못한다"입니다.

데모와 프로덕션 (production) 사이의 그 간극은 대부분 산술적인 문제입니다. 그리고 일단 그 수학적 원리를 내면화하면 구축 방식이 바뀝니다.

아무도 슬라이드에 넣지 않는 수학

에이전트의 각 단계가 95%의 신뢰도를 가진다고 가정해 봅시다. 아주 좋아 보입니다. 이제 10개의 단계를 연결해 보겠습니다. 이는 2026년 기준으로 볼 때 겸손한 수준의 에이전트입니다:

0.95 ^ 10 ≈ 0.60

엔드 투 엔드 (end-to-end) 성공률은 60%입니다. 이를 20단계로 늘리면 36%가 됩니다. 그리고 단계당 95%는 관대한 수치입니다. 지저분한 입력값(messy inputs)을 처리하며 실제 작업을 수행하는 에이전트의 경우, 단계별 오류율은 10~20%에 가깝습니다. 85%의 단계율을 가진 8개 단계에 대해 수치를 계산해 보면 다음과 같습니다:

0.85 ^ 8 ≈ 0.27

네 번의 실행 중 약 세 번은 어딘가에서 실패합니다. 이것은 나쁜 모델이 아닙니다. 확률이 복합적으로 작용하여 정확히 제 역할을 수행하고 있는 것입니다.

데모는 이를 완전히 숨깁니다. 데모는 하나의 해피 패스 (happy path)입니다. 깨끗한 입력, 짧은 체인 (chain), 속도 제한 (rate limits) 없음, 모호한 데이터 없음, 그리고 녹화하기에 좋아 보일 때까지 다섯 번 정도 실행해 보는 상황 말입니다. 프로덕션은 당신이 상상도 못 했던 쓰레기 데이터를 입력하는 수백 명의 사용자이며, "이 도구를 호출하고 결과를 파싱하라"는 모든 명령이 내부적으로 실제로는 3~4단계로 이루어져 있기 때문에 당신이 생각하는 것보다 훨씬 긴 체인을 가집니다.

단계 수준에서는 실패가 보이지 않는다

팀을 실제로 괴롭히는 부분은 바로 여기입니다. 복합적인 실패는 충돌 (crash)로 나타나지 않습니다. 개별 단계는 고립된 상태에서 보면 모두 합리적으로 보입니다.

3단계에서 필드를 약간 잘못 읽습니다. 출력값은 여전히 형식이 잘 갖춰진 JSON입니다. 이것이 4단계로 전달되면, 4단계는 손상된 컨텍스트 (context)를 바탕으로 자신 있게 추론하고, 5단계부터 8단계까지 그 위에 쌓아 올립니다. 최종 답변은 틀렸지만 그럴듯해 보이며, 3단계를 가리키는 스택 트레이스 (stack trace)도 없습니다. 고객이 당혹스러운 스크린샷을 찍어 보낸 후에야, 보통 수동으로 전체 인과 관계 체인을 추적함으로써 겨우 찾아낼 수 있을 뿐입니다.

이것이 바로 대부분의 경우 "모델이 환각(hallucination)을 일으켰다"는 진단이 잘못된 이유입니다. 모델은 항상 하던 대로 했을 뿐입니다. 즉, 전달받은 것을 그대로 전파(propagate)했을 뿐입니다. 시스템에 체크포인트(checkpoint)도, 검증 게이트(validation gate)도, 그래서 3단계에서 발생한 드리프트(drift)가 이후의 모든 과정을 오염시키기 전에 이를 잡아낼 방법도 없었던 것입니다.

또 다른 조용한 살인자는 컨텍스트(context)입니다. 사람들은 "200K 토큰 윈도우(token window)"라는 말을 들으면 200K 토큰의 작업 기억(working memory)을 가지고 있다고 가정합니다. 하지만 실제로 에이전트(agent)는 오래된 지침들이 도구 출력(tool output)과 중간의 쓰레기 데이터(intermediate junk) 아래에 파묻히면서, 그 수치에 도달하기도 훨씬 전에 맥락을 놓치기 시작합니다. 진짜 한계는 컨텍스트의 크기가 아니라 컨텍스트의 품질입니다. 관련성 있는 8K의 정교한 컨텍스트가 노이즈가 섞인 80K보다 언제나 더 낫습니다.

실제로 성과를 내는 것들

해결책 중 특별히 기이한 것은 없습니다. 그것들은 우리가 이미 알고 있는 지루한 분산 시스템(distributed-systems)의 규율을 비결정론적(non-deterministic)인 작업자에게 적용하는 것뿐입니다. 중요한 정신적 전환은 이것입니다: 에이전트를 프롬프트(prompt)로 취급하는 것을 멈추고, 시스템(system)으로 취급하기 시작하는 것입니다.

에이전트 외부의 체크포인트 상태(Checkpoint state). 상태(state)는 대화 속에 머무는 것이 아니라 저장소(store)에 존재해야 합니다. 프로세스가 6단계에서 중단된다면, 전체 체인을 다시 시작하여 비용을 두 번 지불하는 것이 아니라 6단계부터 재개해야 합니다. 이 한 가지 변화가 "실행 실패, 처음부터 다시 시작"을 "실행 실패, 정확히 이 지점에서 실패함, 여기서부터 재시도"로 바꿔줍니다.

경계에서의 검증(Validate at the boundaries). 모든 도구의 입력과 출력은 계약(contract)에 따라 확인됩니다. 스키마(schema), 건전성 검사(sanity check), 혹은 숫자가 범위 내에 있는지 확인하는 어설션(assertion) 등이 이에 해당합니다. 목표는 오염된 3단계 출력을 미스터리가 되어버리는 8단계가 아니라, 깨끗하게 복구 가능한 오류인 3단계에서 잡아내는 것입니다. 도구의 입출력(I/O)에 대한 Pydantic 스타일의 검증은 여러분이 구매할 수 있는 가장 저렴한 신뢰성입니다.

부수 효과(Side effects)를 멱등(Idempotent)하게 만드세요. 비결정론적(Non-deterministic)인 워커(Worker)를 사용할 때 재시도(Retry)는 타협할 수 없는 요소이며, 이는 하나의 단계(Step)가 두 번 실행될 수 있음을 의미합니다. 만약 특정 단계가 카드를 결제하거나 이메일을 발송한다면, 멱등성 키(Idempotency key)의 유무가 단순한 재시도와 사고(Incident) 사이의 차이를 결정합니다. 분명히 짚고 넘어가야 할 점은, LLM 단계를 재시도하는 것은 캐시 조회(Cache lookup)가 아니라는 것입니다. 동일한 프롬프트라도 다른 답변을 반환할 수 있으므로, 멱등성은 모델 호출이 아니라 부수 효과(Side effect) 단계에 존재해야 합니다.

평가(Evals)를 CI에 포함하세요. 에이전트의 동작을 회귀(Regress)할 수 있는 코드처럼 취급하세요. 실제로 회귀가 발생하기 때문입니다. 하나의 케이스를 돕기 위해 수정한 프롬프트가 조용히 다른 다섯 개의 케이스를 망가뜨릴 수 있으며, 테스트 세트가 없다면 여러분은 눈을 감고 제품을 출시하는 것과 같습니다. 모든 변경 사항에 대해 실행되는 적절한 규모의 실제 케이스 세트는, 수동으로 확인하는 방식으로는 절대 잡아낼 수 없는 조용한 회귀(Regressions)를 포착해 줍니다.

불편한 진실은 매끄러운 데모에서 유료 사용자 앞에 내놓을 수 있는 무언가로 넘어가는 과정이 대부분 더 나은 프롬프트가 아니라, 오류 처리(Error handling), 상태 관리(State management), 관찰 가능성(Observability)과 같은 매력적이지 않은 엔지니어링 작업이라는 점입니다. Shanti Infosoft에서 에이전트를 구축할 때 수행하는 실제 작업의 대부분은 사람들이 기대하는 모델 조율(Model wrangling)이 아니라, 바로 이러한 스캐폴딩(Scaffolding, 기반 구조) 작업입니다.

데모는 아름답게 작동하지만 프로덕션(Prod) 환경에서는 불안정한 에이전트를 바라보고 있다면, 가장 먼저 더 큰 모델을 찾지 마세요. 트레이스(Trace)를 열고, 체인(Chain)이 조용히 잘못된 방향으로 흐르는 단계를 찾아낸 뒤, 왜 그곳에서 아무것도 잡아내지 못했는지 질문하십시오. 열에 아홉은 그 답이 지능(Intelligence)의 문제가 아닙니다. 여러분이 해피 패스(Happy path)를 구축해 놓고 그것을 시스템이라고 불렀기 때문입니다.