에이전트가 오류를 읽습니다
MCP 서버 도구 호출이 실패하면, 오류 메시지가 에이전트의 컨텍스트의 일부가 됩니다. 에이전트는 오류를 읽고 다음에 무엇을 할지 결정합니다. 재시도해야 하는가? 다른 접근을 시도해야 하는가? 사용자에게 도움을 요청해야 하는가? 결정은 전적으로 오류 메시지가 무엇을 알려 주는지에 달려 있습니다.
"Error: ECONNREFUSED"라고 말하는 오류 메시지는 에이전트에게 연결이 거부되었다는 것은 알려 주지만, 왜인지 또는 그것에 대해 무엇을 해야 할지는 알려 주지 않습니다. "Error: PostgreSQL의 localhost:5432에 연결할 수 없습니다. 데이터베이스 서버가 실행되고 있지 않거나 포트가 잘못되었을 수 있습니다. PostgreSQL이 시작되었는지, 연결 설정이 데이터베이스 구성과 일치하는지 확인하십시오."라고 말하는 오류 메시지는 에이전트가 사용자에게 문제를 설명하고 구체적인 해결책을 제안할 만큼 충분한 정보를 제공합니다.
좋은 오류는 회복을 가능하게 합니다
AI가 소비하는 도구를 위한 최고의 오류 메시지는 다음 패턴을 따릅니다. 무엇이 일어났는지, 왜 일어났을 가능성이 있는지, 무엇이 그것을 고칠 수 있는지입니다. "쿼리가 0행을 반환했습니다. 테이블 'users'는 존재하지만 비어 있을 수 있거나, WHERE 절 'created_at > 2026-12-01'이 어떤 레코드와도 일치하지 않을 수 있습니다. 날짜 범위를 넓히거나 테이블 내용을 확인해 주십시오." 이는 에이전트가 사용자에게 묻지 않고도 수정된 쿼리를 시도할 만큼 충분한 컨텍스트를 줍니다.
오류 분류도 도움이 됩니다. 오류가 권한 문제를 가리키면, 에이전트는 재시도가 도움이 되지 않을 것임을 압니다. 일시적인 네트워크 문제를 가리키면, 재시도가 성공할 수도 있습니다. 잘못된 매개변수를 가리키면, 에이전트는 다른 매개변수를 시도할 수 있습니다. 명확한 분류는 더 똑똑한 회복 전략을 가능하게 합니다.
나쁜 오류는 루프를 만듭니다
"Internal server error"나 "Something went wrong" 같은 모호한 오류 메시지는 에이전트가 작업할 정보를 주지 않습니다. 같은 실패하는 호출을 재시도해서 토큰을 낭비하거나, 같은 이유로 실패하는 약간 다른 접근을 시도하거나, 단순한 매개변수 조정이 문제를 해결했을 자리에서 완전히 포기할 수 있습니다.
가장 나쁜 패턴은 오류가 통째로 삼켜져서, 무언가 잘못되었다는 표시 없이 반환되는 경우입니다. 에이전트는 빈 결과나 부분 결과를 받고는 그것이 옳다고 가정하고 진행합니다. 이것은 하류로 연쇄 오류를 일으킵니다.
MCP 서버 제작자께
MCP 서버를 만드신다면, 오류 메시지에 투자해 주십시오. 모든 오류 경로는 언어 모델이 문제를 이해하고 해결책을 제안하는 데 도움이 될 메시지를 반환해야 합니다. 오류를 사용자의 로그나 데이터베이스에 접근할 수 없는 주니어 개발자에게 주는 지시처럼 생각해 주십시오. 그분이 문제를 진단하고 해결하기 위해 무엇을 알아야 할까요?
관련 컨텍스트를 오류에 포함해 주십시오. 어떤 작업이 시도되었는지, 어떤 매개변수가 사용되었는지, 예상된 동작은 무엇이었는지, 실제로 무엇이 일어났는지가 그 컨텍스트입니다. 이 컨텍스트는 코드 몇 줄이 더 들지만, 에이전트가 서버와 어떻게 상호작용하는지를 극적으로 개선합니다.