8개의 에이전트 프레임워크에 걸쳐 104개의 실제 GitHub 이슈를 대상으로 우리 도구를 테스트하며 배운 점

작성자: Rudrendu Paul 및 Sourav Nandy

Repo: github.com/RudrenduPaul/agent-observability. 이 저장소는 AI 에이전트의 실행을 기록하고 재현하여, 실패를 다시 트리거하는 비용을 지불하지 않고도 디버깅할 수 있게 해줍니다. pip install agent-observability-trace-cli 명령어로 설치할 수 있습니다.

요약: 우리는 8개의 서로 다른 에이전트 프레임워크에서 발생한 104개의 실제 GitHub 이슈를 대상으로 우리의 접근 방식을 테스트했습니다. 거의 모든 경우에 작동했습니다. 처음에는 작동하지 않았던 사례와 우리가 무엇을 변경해야 했는지를 포함하여 우리가 배운 점은 다음과 같습니다.

여러분의 LangGraph 에이전트가 10단계 프로세스 중 8단계에서 실패한다고 가정해 봅시다. LangSmith는 트레이스(trace)를 보여주므로 무슨 일이 일어났는지 확인할 수 있습니다.

하지만 그 실패를 실제로 연구하기 위해 재현하려면 에이전트 전체를 다시 실행해야 합니다. 이는 언어 모델(language model)에 8번 더 호출해야 함을 의미하며, 약 30초를 더 기다려야 하고, 대략 15센트의 API 비용이 발생합니다. 그리고 언어 모델은 항상 두 번 똑같이 대답하지 않기 때문에, 실패가 다시 발생하지 않을 수도 있습니다.

아직 아무도 이 문제를 진정으로 해결하지 못했습니다.

대신 우리의 접근 방식은 다음과 같습니다: 실제 네트워크 호출을 한 번 기록한 다음, 네트워크 트래픽 없이, 비용 발생 없이 원하는 만큼 반복해서 재현(replay)하는 것입니다.

Terminal recording of agent-trace recording a live HTTP call, then replaying the same run offline with zero network requests

실행 중일 때 한 번 기록하세요. 그 후 모든 재현은 동일한 결과와 함께 동일한 실행이 되며, API 호출도 없고 다시 트리거하는 데 드는 비용도 없습니다.

심지어 고도화된 AI 모델조차도 간단해 보이는 작업에 어려움을 겪습니다. 바로 방금 실패한 멀티 에이전트 시스템 (multi-agent system)을 살펴보고, 어떤 에이전트가 원인을 제공했는지 말하는 것입니다. 2025년, Penn State와 Duke의 연구진은 127개의 실제 멀티 에이전트 실패 사례로 구성된 데이터셋을 구축하고, AI 모델이 원인을 정확히 식별할 수 있는지 테스트했습니다. 가장 성능이 좋은 모델조차 올바른 에이전트를 선택한 확률은 53.5%에 불과했으며, 정확한 실패 단계 (failing step)를 찾아낸 확률은 14.2%뿐이었습니다. 연구진은 가장 진보된 추론 모델 (reasoning models)조차 아직 이 작업을 수행할 만큼 충분히 신뢰할 수 없다는 결론을 내렸습니다.

이 문제는 더 나은 대시보드 (dashboard)를 만든다고 해서 해결할 수 있는 것이 아닙니다. 대부분의 "에이전트 관측성 (agent observability)" 도구들은 잘못된 질문에 답하고 있습니다. 무엇이 일어났는지 아는 것은 상당히 쉽습니다. 하지만 실제로 연구할 수 있도록 그 정확한 실패를 저렴하고 신뢰할 수 있게 다시 재현하는 것은 완전히 다른 문제이며, 이를 위해 구축된 도구는 거의 없습니다.

이것이 지금 중요한 이유는 에이전트 배포 속도가 수동으로 디버깅 (debug)하는 능력보다 더 빠르게 성장하고 있기 때문입니다. Gartner는 2025년 5% 미만이었던 기업용 애플리케이션 중 특정 작업 전용 AI 에이전트를 사용하는 비중이 2026년 말에는 40%에 달할 것이라고 예측했는데, 이는 Gartner가 추적해 온 사례 중 가장 빠른 채택 곡선 중 하나입니다. McKinsey의 2026년 AI 현황 보고서 (2026 State of AI report)는 더 신중합니다. 조직의 23%가 비즈니스 어딘가에서 에이전트 시스템을 실제로 확장하고 있다고 답했지만, 단일 비즈니스 기능조차 채택률 10%를 넘지 못했습니다. 이 두 수치를 나란히 놓고 보면 상황은 명확합니다. 에이전트는 이를 디버깅하기 위한 도구들이 성숙해지는 속도보다 훨씬 빠르게 프로덕션 (production) 환경으로 이동하고 있습니다.

에이전트 관측성의 실제 격차

사람들이 "에이전트 관측성 (agent observability)"에 대해 이야기할 때, 보통 에이전트의 호출 (calls)을 추적하여 대시보드로 보내고, 무언가 고장 났을 때 트레이스 (trace)를 살펴보는 것을 의미합니다. 그것은 무엇이 일어났는지에 대한 가시성 (visibility)을 제공합니다. 하지만 실제로 연구할 수 있도록 동일한 문제를 다시 발생시킬 수 있는 쉽고 저렴한 방법을 제공하지는 않습니다.

그것이 중요한 차이점입니다. 트레이스 도구는 무엇이 일어났는지 알려줄 뿐입니다. 어떻게 하면 같은 일이 저렴하고 신뢰성 있게 다시 발생하게 할 수 있는지는 말해주지 않습니다. 이것은 두 가지 별개의 문제입니다. 첫 번째 문제는 이미 대부분 해결되었습니다. 거의 아무도 두 번째 문제를 해결하지 못했습니다.

실제로 실패를 다시 유발하기 위한 API 호출 비용은 사실 더 작은 비용입니다. 더 큰 비용은 프로덕션 환경에서 발생한 실패를 반복적으로 재실행하며, 그 순간을 포착하기 위해 투입되는 엔지니어링 시간입니다. 이것이 에이전트가 데모 단계를 지나 팀의 속도를 실제로 늦추는 원인입니다.

소프트웨어의 다른 부분들은 이와 같은 문제를 전에 해결한 적이 있습니다. Mozilla의 rr 디버거는 2017년 이래로 일반적인 Linux 프로그램의 정확한 동작을 기록하고 재생할 수 있었으며, Firefox의 코드베이스처럼 큰 규모에서도 작동할 만큼 견고합니다. ACM Queue에서는

우리는 langchain-ai/langgraph, langchain-ai/langchain, openai/openai-agents-python, run-llama/llama_index, microsoft/autogen, crewAIInc/crewAI, pydantic/pydantic-ai, deepset-ai/haystack, 그리고 agno-agi/agno에 걸쳐 있는 104개의 이슈에 대한 작동하는 해결책을 찾아냈습니다. 이 모든 해결책은 이미 각 프로젝트의 메인 브랜치(main branch)에 반영되었으며, 1,367개의 테스트로 구성된 전체 테스트 스위트(test suite)를 깨끗하게 통과합니다.

최종적인 수치보다 중요한 것은 그 과정이었습니다. 우리는 Python 프로그램과 모델의 API 사이의 HTTP 트래픽을 관찰하는 것만으로도 충분할 것이라고 가정하며 시작했습니다. 대부분의 Python AI 도구들이 실제로 모델과 통신하는 방식이 바로 그러하기 때문입니다. 하지만 그 가정은 상당히 빠르게 틀린 것으로 드러났으며, 이는 유익한 방향으로 틀렸습니다. 무작위적인 엣지 케이스(edge cases)가 아니라, 동일한 유형의 트래픽에서 계속해서 실패가 발생했기 때문입니다.

• Google의 Gemini와 Vertex AI 도구들은 보통 일반적인 HTTP 대신 gRPC를 통해 요청을 보냅니다. HTTP 트래픽만 관찰하는 도구는 이 경우 아무것도 볼 수 없습니다. 이러한 격차(gap)가 바로 langchain-ai/langchain#8304가 발생한 정확한 이유입니다. VertexAI의 text-bison 모델이 아무런 출력 없이 조용히 응답을 반환했지만, 그 이유에 대한 기록이 전혀 없었습니다.

• AWS의 Bedrock 및 SageMaker용 SDK는 우리가 관찰하던 계층(layer)보다 낮은 수준에서 자체적으로 네트워크 연결을 관리합니다. 이러한 격차로 인해, 멀티 도구 호출(multi-tool-call) 요청 시 Bedrock에서 오류가 발생한 후 crewAIInc/crewAI#4749에서 작업에 활용할 수 있는 캡처된 증거가 남지 않았습니다.

• OpenAI의 Realtime API와 모든 MCP 도구 서버는 단일 요청 및 응답 대신 장기 실행 연결(long-lived connections)을 사용합니다. openai/openai-agents-python#2308에서 Realtime Agent의 도구 호출이 조용히 깨졌을 때, 우리는 기존 도구를 확장하는 것만으로는 이를 처리할 수 없었습니다. 우리는 그러한 종류의 연결을 캡처하기 위해 완전히 별개의 시스템을 구축해야 했습니다.

• 또한 프로그램이 처음 시작될 때, 즉 어떤 기록 세션(recording session)이 시작되기 전에 한 번 생성되는 HTTP 클라이언트(HTTP clients)와 관련된 미묘한 버그를 발견했습니다. langgraph dev가 시작되는 방식이 바로 이와 같습니다. 초기 수정 사항은 기록이 시작된 후에 생성된 클라이언트만 패치했기 때문에, 이러한 사례들을 조용히 놓치고 있었습니다. 이를 해결하려면 단순히 설정을 바꾸는 것이 아니라, 우리 도구가 어떤 클라이언트를 가로챌(intercept)지 결정하는 방식을 변경해야 했습니다.

우리는 이러한 프레임워크들을 비난하는 것이 아닙니다. 이는 단지 실제 문제가 얼마나 복잡한지를 보여줄 뿐입니다. 에이전트가 수행하는 모든 것을 캡처하는 것은 단 하나의 작업이 아니라, 네다섯 개의 별도 작업이 필요합니다. 누락된 부분을 찾는 유일한 방법은 실제 사용자가 실제로 겪은 실패 사례를 대상으로 테스트하는 것입니다. 문서를 읽고 추측하는 것만으로는 그곳에 도달할 수 없습니다.

실제 실행(run)을 확인하는 프로세스는 다음과 같습니다: 기록된 실행 목록을 나열한 다음, inspect 명령어를 하나에 지정하여 문제가 있어 보이는 모든 것을 자동으로 표시합니다.

Terminal recording of agent-trace list showing a recorded run, then agent-trace inspect auto-checking it for known malformed request/response shapes

이것은 우리가 실제 GitHub 이슈를 대상으로 104번 반복한 것과 동일한 프로세스입니다: 실행을 찾고, inspect를 지정하고, 증거가 실제로 있는지 확인합니다.

104개 중 12개의 사례

아래의 각 행은 실제 이슈로 연결됩니다. 이는 우리가 발견한 것들의 대표적인 샘플입니다. 각 이슈에 대한 정확한 수정 사항이 포함된 104개 이슈 전체 목록은 저장소(repository)에 있습니다.

이 접근 방식이 실제로 작동하지 않는 경우

이러한 도구는 자신의 한계에 대해 솔직하게 밝힘으로써 신뢰를 얻습니다. 따라서 이 도구가 작동하지 않는 지점은 다음과 같습니다.

이 도구는 사용자의 프로그램에서 전송된 트래픽만 볼 수 있습니다. 사용자가 직접 실행하지 않는 별도의 호스팅된 서비스(hosted service)에서 발생하는 내부 호출은 볼 수 없습니다. 일부 AI 제공업체가 HTTP 대신 사용하는 프로토콜인 gRPC에 대한 지원은 실제 구현되어 있으나 부분적입니다. 우리는 일반적인 요청-응답 (request-and-response) 패턴은 완전히 캡처합니다. 하지만 일부 도구가 사용하는 최신 비동기 스트리밍 (async streaming) 스타일을 포함하여, gRPC의 스트리밍 모드 (streaming modes)는 아직 캡처하지 못합니다. 기록은 실제 요청이 존재할 때부터 시작됩니다. 예를 들어, SDK가 요청을 생성하는 도중과 같이 더 이른 단계에서 무언가 실패한다면, 우리가 캡처할 수 있는 데이터가 없습니다. 만약 프레임워크 전용 통합 (framework-specific integrations) 중 하나를 설정했다면, 해당 통합 자체의 에러 핸들링 (error handling)이 때때로 그러한 초기 단계의 실패를 잡아낼 수 있습니다. 설정을 하지 않았다면, 코드의 다른 곳에서 해당 에러를 잡아내야 합니다.

또한 우리는 이 도구가 무엇을 대체하고 무엇을 대체하지 않는지에 대해서도 솔직해지고자 합니다. 때로는 아직 특정 실패를 목격하지 못한 라이브 트래픽 (live traffic) 전반의 동작을 이해해야 할 때가 있습니다. 그러한 개방형 디버깅 (open-ended debugging)을 위해서는, 모든 일이 발생하는 동안 모든 것을 지켜보는 일반적인 대시보드 도구가 여전히 필요합니다. 우리의 도구는 무언가 고장 났다는 것을 이미 알고 있는 바로 그 순간, 추가 비용 없이 필요한 만큼 그 정확한 실패 사례를 면밀히 연구해야 할 때를 위해 구축되었습니다. 이 도구는 애초에 알려지지 않은 문제를 발견하도록 돕기 위한 것이 아닙니다. 이 둘은 서로 다른 작업이며, 이를 동일한 것으로 취급하는 것은 두 가지 모두를 과장하는 것입니다.

만약 여러분의 팀이 프로덕션(production) 환경에서 훨씬 더 많은 에이전트를 실행하려 한다면, 여기 간단한 교훈이 있습니다. 오프라인에서 실패를 재현(reproduce)할 수 있는 능력을 나중에 처리해도 되는 '있으면 좋은 기능(nice-to-have)'으로 취급하지 마십시오. 대규모 시스템을 확장(scale)하기 전에 적절한 모니터링(monitoring)을 갖추고자 하는 것과 마찬가지로, 확장을 하기 전에 반드시 갖춰야 할 요소로 취급하십시오. 위에서 언급한 McKinsey와 Gartner의 수치는 확장이 대부분의 팀이 보유한 디버깅(debugging) 도구가 따라잡을 수 있는 속도보다 이미 더 빠르게 진행되고 있음을 보여줍니다. 일단 실패가 라이브 API(live API)를 대상으로 다시 실행하는 대신 로컬(locally)에서 재현할 수 있는 것이 되면, 실행 결과가 이미 여러분의 디스크(disk)에 저장되어 있기 때문에 버그를 수정하는 데 걸리는 시간은 답답한 오후 시간에서 단 몇 분으로 단축될 수 있습니다.

에이전트가 다른 에이전트를 호출하기 시작하면 이것이 왜 더 시급해지는가