데모는 실패 없이 50번 실행되었습니다. 그리고 우리는 그것을 출시했습니다.

운영(production)에 들어간 지 3일째, 에이전트는 자신감 넘치는 헛소리를 내뱉기 시작했습니다. 에러가 아니었습니다. 충돌(crash)도 아니었습니다. 에이전트는 작업을 완료했고, 결과를 작성했으며, 성공을 기록했습니다. 하지만 그 결과는 틀렸습니다. 아무도 6시간 동안 이를 알아채지 못했습니다.

에이전트의 업무는 제3자 엔드포인트(endpoint)에서 구조화된 데이터(structured data)를 가져와 요약하고, 의사결정을 라우팅(routing)하는 것이었습니다. 테스트 단계에서 해당 엔드포인트는 항상 최소 하나 이상의 항목이 포함된 리스트를 반환했습니다. 하지만 3일째 되는 날, 빈 리스트를 반환했습니다. 유효한 JSON이었지만 항목은 0개였습니다. 에이전트는 이런 입력을 본 적이 없었습니다. 에이전트는 멈추지 않았습니다. 데이터의 부재를 마치 무언가 의미가 있는 것처럼 요약했고, 그럴듯한 문맥을 채워 넣었으며, 자신 있게 라우팅했습니다.

빈 입력값에 대한 자신감 넘치는 자동 완성(autocomplete). 이것이 바로 데모에서는 절대 드러나지 않는 운영 환경에서의 실패 모드(failure mode)입니다.

데모가 이를 숨긴 이유

출시 전 실행한 모든 테스트는 좋은 입력값들을 사용했습니다. 깔끔한 구조, 예상된 범위, 해피 패스(happy path)였습니다. 저는 API 실패를 테스트했습니다. 잘못된 형식의 JSON을 테스트했습니다. 하지만 "여기에 아무것도 없다"는 의미를 가진, 기술적으로는 유효한 응답에 대해서는 테스트하지 않았습니다.

데모는 작동하는 것을 보여주는 데 최적화되어 있습니다. 운영 환경은 당신이 놓친 모든 것을 찾아냅니다. 이러한 간극은 모든 소프트웨어에 존재하지만, AI는 이를 더 알아차리기 어렵게 만듭니다. 전통적인 시스템은 예외(exception)를 발생시키거나 null을 반환합니다. LLM은 일관성 있으면서도 틀린 내용을 작성합니다. 당신은 출력을 읽고, 도메인을 이해하고, "최근 거래 내역 하나를 요약함"이 "거래 내역을 찾을 수 없음"이 되었어야 한다는 점을 알아차려야 합니다. 그러기 위해서는 인간의 확인이나 명시적인 단언(assertion)이 필요합니다. 저에게는 둘 다 없었습니다.

더 깊은 문제는 데이터 계층(data layer)과 추론 계층(reasoning layer) 사이에 아무런 계약(contract) 없이 핸드오프(handoff)가 이루어졌다는 점입니다. 데이터 계층은 "여기에 0개의 항목이 있다"라고 말했고, 추론 계층은 "받은 것이 무엇이든 의미를 부여해 보겠다"라고 말했습니다. 그리고 실제로 그렇게 했습니다. 아주 형편없이 말이죠. 0개의 항목이 멈춰서 확인해야 할 특별한 케이스라는 것을 아무도 알려주지 않았습니다.

벤치마크(Benchmarks)는 이것을 보여주지 않습니다. 백 번의 해피 패스 실행도 이것을 보여주지 않습니다. 빈 리스트 케이스는 당신이 다른 일을 하고 있는 3일째 되는 날에 나타납니다.

해결책은 영리하지 않았습니다

저는 가드(guard)를 추가했습니다. 에이전트가 데이터를 바탕으로 추론(reasoning)하기 전에, 입력값이 의미 있는 답변을 내놓기 위한 최소 조건을 충족하는지 확인하도록 했습니다. 충족하지 못할 경우, 구조화된 "데이터 없음(no data)" 신호를 반환하고 중단합니다. 다운스트림 시스템(downstream system)은 해당 신호를 명시적으로 처리합니다.

이것이 해결책의 전부입니다. 프롬프트 엔지니어링 (prompt engineering), 파인튜닝 (fine-tuning), 새로운 모델, 영리한 아키텍처 (architecture) 따위는 없었습니다. 모델이 무엇인가를 건드리기 전에 실행되는 단순한 체크입니다.

매력적이지 않은 부분은 에이전트가 처리하는 모든 데이터 유형에 대해 "최소 조건"을 정의하는 작업이 에이전트를 구축하는 것보다 더 오래 걸렸다는 점입니다. 저는 각 입력 유형을 깊이 고민하며 다음과 같이 자문해야 했습니다: "여기서 '유효하지만 의미 없는' 상태란 어떤 모습인가?" 이 과정을 건너뛸 수는 없습니다. 이를 정의하지 않으면, 모델은 항상 할 말을 찾아낼 것입니다. 모델은 그런 면에서 매우 능숙하기 때문입니다.

저는 Agent Enterprise (aienterprise.dk)에서 여러 에이전트를 운영하고 있으며, 이 패턴은 모든 에이전트에서 반복됩니다. 데모는 제가 선택한 입력을 사용합니다. 프로덕션 (production)은 아무도 선택하지 않은 입력을 사용합니다. 이 두 집단 사이의 차이가 바로 당신의 신뢰성 (reliability)이 살거나 죽는 지점입니다.

Martin Fowler의 플랫폼에 올라온 신뢰할 수 있는 에이전트 AI (agentic AI)에 관한 글은 2026년 6월 Hacker News에서 171점을 받았습니다. 45점이 아닙니다. 이는 사람들이 흥미로운 새로운 에이전트 기능에 대해 읽고 있다는 뜻이 아닙니다. 프로덕션 환경에 진입하여 도움을 찾고 있는 사람들이라는 뜻입니다. 실무자 커뮤니티는 그 간극이 어디에 있는지 알고 있습니다.

데모는 에이전트가 '할 수 있음'을 증명합니다. 프로덕션은 아무도 지켜보지 않는 새벽 3시에, 잘못된 입력이 들어왔을 때 에이전트가 '실제로 해냄'을 증명합니다. 그것이 메워야 할 유일한 간극입니다.

신뢰성은 유일한 기능입니다. 그 외의 모든 것은 데모일 뿐입니다.