도구 호출은 성공했지만, 결과는 실패했습니다

대부분의 엔지니어링 팀은 실패를 잘못된 방식으로 생각하도록 훈련받았습니다.

우리는 크래시 (Crashes)를 찾습니다.

우리는 예외 (Exceptions)를 찾습니다.

우리는 알림 (Alerts)을 찾습니다.

우리는 빨간색 대시보드를 찾습니다.

하지만 가장 치명적인 실패 중 일부는 전혀 실패처럼 보이지 않습니다.

그것들은 성공처럼 보입니다.

몇 달 전, AI 에이전트 (AI agents) 및 MCP 서버 (MCP servers)와 작업하던 중, 저는 계속해서 반복되는 패턴을 발견했습니다.

에이전트가 도구 (Tool)를 호출합니다.

도구는 성공적인 응답을 반환합니다.

오류도 없습니다.

예외도 없습니다.

타임아웃 (Timeout)도 없습니다.

모든 것이 정상적으로 보입니다.

하지만 작업은 완료되지 않았습니다.

액션은 전혀 일어나지 않았습니다.

사용자는 잘못된 결과를 받았습니다.

고객이 엔지니어링 팀보다 먼저 문제를 발견했습니다.

이것은 매우 다른 유형의 실패입니다.

그리고 AI 시스템이 프로덕션 (Production) 환경으로 이동함에 따라 점점 더 흔해지고 있습니다.

모든 엔지니어가 하는 가정

대부분의 소프트웨어 시스템은 단순한 가정 위에 구축됩니다:

요청이 성공했다면, 결과도 성공한 것이다.

그 가정은 외부 시스템이 등장하기 전까지는 놀라울 정도로 잘 작동합니다.

현대의 AI 에이전트 (AI agents)는 API, MCP 서버 (MCP servers), 데이터베이스 (Databases), SaaS 플랫폼, 검색 시스템, 그리고 수십 개의 외부 도구에 의존합니다.

추가되는 모든 의존성은 요청과 결과가 서로 어긋날 수 있는 또 다른 기회를 만듭니다.

시스템은 성공을 보고합니다.

현실은 실패를 보고합니다.

이것이 발생하는 네 가지 방식

1. Null 응답 (Null Responses)

도구가 성공적으로 반환됩니다.

응답은 기술적으로 유효합니다.

실제 결과는 비어 있습니다.

{
  "result": null
}

에이전트는 계속 진행합니다.

사용자는 불완전한 정보를 받습니다.

아무도 즉시 알아차리지 못합니다.

2. 부분 실행 (Partial Execution)

요청이 세 가지 액션을 트리거했습니다.

그중 하나만 완료되었습니다.

도구는 어쨌든 성공을 보고합니다.

워크플로우 (Workflow)는 이제 일관성 없는 상태에 놓이게 됩니다.

3. 오래된 데이터 (Stale Data)

응답이 성공적으로 도착합니다.

정보는 몇 시간 전의 것입니다.

에이전트는 구식인 현실을 바탕으로 결정을 내립니다.

4. 스키마 드리프트 (Schema Drift)

필드가 변경됩니다.

응답 형식이 진화합니다.

시스템은 여전히 데이터를 수신합니다.

데이터의 의미가 변합니다.

워크플로 (Workflow)가 소리 없이 깨집니다.

이러한 실패가 비용이 많이 드는 이유

크래시 (Crash)는 눈에 보입니다.

침묵하는 실패 (Silent failure)는 눈에 보이지 않습니다.

크래시는 즉시 보고됩니다.

침묵하는 실패는 계속 작동합니다.

사용자는 신뢰를 잃습니다.

엔지니어는 디버깅 (Debugging)에 수 시간을 소비합니다.

팀은 이미 피해가 발생한 후에 사건을 재구성합니다.

조사는 보통 다음과 같이 시작됩니다:

"고객이 무언가 잘못된 것 같다고 말했습니다."

그것은 신뢰성 문제를 발견하는 가장 비용이 많이 드는 방법 중 하나입니다.

교훈

교훈은 간단합니다.

성공적인 요청 (Request)을 신뢰하는 것을 멈추십시오.

성공적인 결과 (Outcome)를 검증하기 시작하십시오.

그 둘은 같은 것이 아닙니다.

응답 코드 (Response code)는 통신이 이루어졌는지 여부를 알려줍니다.

원하는 결과가 발생했는지 여부는 알려주지 않습니다.

AI 시스템이 도구 (Tools) 및 외부 시스템에 더 많이 의존하게 됨에 따라, 그 차이는 점점 더 중요해집니다.

오늘 바로 실행할 수 있는 한 가지 행동

시스템의 최근 프로덕션 (Production) 도구 호출 10건을 검토하십시오.

각 호출에 대해 다음을 질문하십시오:

• 요청이 성공했는가?
• 의도한 결과가 실제로 발생했는가?
• 만약 발생하지 않았다면, 우리는 어떻게 알 수 있는가?

만약 이 답변들이 서로 다르다면, 당신은 이미 신뢰성 격차 (Reliability gap)를 발견한 것입니다.

그리고 당신이 발견하지 않는다면, 결국 사용자가 그것을 발견하게 될 가능성이 높습니다.