에이전트가 실패한 API를 5번 반복 호출했는데, 버그는 코드에 없었습니다

버그가 터졌습니다. 에이전트가 같은 API 호출을 5번이나 반복하고 있었거든요. 습관처럼 코드부터 열었는데 retry 로직은 멀쩡했습니다. 함수 흐름도 정상이고 로그에도 에러 하나 없었어요.

코드에 답이 없었습니다. 트레이스를 열고 나서야 원인이 보이더라고요.

에이전트 코드는 빈 그릇에 가깝습니다

에이전트 코드를 열어보면 모델 지정과 도구 목록, 그리고 시스템 프롬프트 정도가 전부예요. 어떤 도구를 언제 부를지, 어떤 순서로 추론할지는 코드에 없습니다.

LangGraph 기반 에이전트를 운영하는 팀에서 자주 나오는 이야기가 “코드 리뷰로는 에이전트 품질을 판단할 수 없다”는 거예요.

• 같은 코드 + 같은 입력으로 매번 다른 도구 호출 패턴 발생
• handleSubmit() 같은 함수와 달리 분기 로직 자체가 코드에 존재하지 않음
• GPT-5.2 기준 동일 쿼리 10회 테스트 시 도구 호출 순서 일치율 약 40%
• 오류가 나도 코드에는 버그가 없어서 재현이 불가능

이게 핵심적인 변화예요. 기존 소프트웨어에서는 코드가 곧 동작이었습니다. 에이전트에서 코드는 그냥 뼈대일 뿐이에요. 실제 동작은 런타임에 만들어지는데, 모델이 받은 컨텍스트를 어떻게 추론하느냐에 따라 달라집니다.

트레이스가 새로운 소스코드입니다

트레이스는 에이전트가 밟은 모든 발자국이에요. 각 단계에서 뭘 추론했고, 어떤 도구를 왜 불렀는지 전부 기록됩니다. 기존 소프트웨어에서 코드로 하던 디버깅과 테스트, 성능 분석을 이제 트레이스로 해야 하는 구조죠.

에이전트가 에러 메시지를 보고도 같은 호출을 반복하는 건 코드 버그가 아니라 추론 실패입니다. 그리고 트레이스를 열어야만 보여요.

• 트레이스 비교로 프롬프트 변경 전후 추론 품질 차이를 즉시 확인 가능
• LangSmith에서 특정 시점의 트레이스를 플레이그라운드에 로드하면 브레이크포인트처럼 사용 가능
• 로그를 아무리 쌓아도 재현할 수 없는 것을, 트레이스 한 장이 정확한 시점에서 보여줌

이렇게 생각해보세요. 기존 디버깅은 레시피를 읽으면서 실수를 찾는 거예요. 에이전트 디버깅은 주방 CCTV 영상을 돌려보면서 셰프가 어디서 틀렸는지 찾는 겁니다. 레시피는 완벽할 수 있어요. 문제는 실행 과정에서 터집니다.

테스트 방식이 근본적으로 바뀝니다

기존에는 배포 전에 테스트하고 끝이었죠. 에이전트는 비결정적이라 프로덕션에서도 계속 평가해야 합니다.

트레이스를 수집해서 eval 데이터셋을 만들고 품질 저하나 드리프트를 잡아내는 파이프라인이 없으면 에이전트를 규모 있게 운영하는 게 불가능해요.

트레이스 기반 eval을 도입한 팀에서 태스크 성공률이 눈에 띄게 올라간 사례가 여럿 있습니다. 패턴은 일관돼요. 트레이스가 배포 전 테스트로는 절대 잡을 수 없는 실패 유형을 드러냅니다.

• 프로덕션 트레이스에서 주 1회 샘플링 후 자동 eval 파이프라인 구축 권장
• 배포 전 테스트만으로는 비결정적 시스템의 품질 보장 불가
• 트레이스 없는 모니터링은 서버 가동률만 보는 것과 같음
• 에이전트가 “정상 작동” 중이면서 완전히 엉뚱한 태스크를 수행하는 경우, 트레이스로만 포착 가능

협업과 제품 분석도 트레이스 위에서 일어납니다

코드 리뷰는 GitHub에서 했습니다. 에이전트의 판단은 어디서 리뷰할까요?

옵저버빌리티 플랫폼이 그 자리를 가져가고 있어요. 트레이스에 코멘트를 달고, 특정 판단 시점을 공유하고, 풀 리퀘스트를 리뷰하듯 에이전트의 추론을 검토하는 방식으로 협업 자체가 바뀌고 있습니다.

제품 분석도 마찬가지예요. “사용자 30%가 불만족”이라는 지표가 나왔을 때 트레이스를 열지 않으면 원인을 알 수 없거든요. 에이전트 입장에서는 태스크를 성공적으로 완료했는데, 사용자가 실제로 원하는 걸 완전히 빗나가고 있을 수 있으니까요.

• Mixpanel 같은 제품 분석 도구와 디버깅 도구가 트레이스 위에서 하나로 수렴
• 에이전트 도구 호출 패턴 분석으로 사용자가 원하는 기능까지 역추적 가능

결론

에이전트 시대에 코드는 건물 설계도이고 트레이스는 CCTV 녹화본입니다. 건물에서 사고가 나면 설계도를 펴는 게 아니라 녹화본부터 돌려보는 거죠.

에이전트 품질을 제대로 잡고 있는 팀은 무게중심을 코드에서 트레이스로 옮긴 팀입니다. 코드가 중요하지 않아서가 아니에요. 진짜 중요한 실패들, 즉 사용자와 돈을 날리는 실패들은 트레이스가 포착하는 런타임 동작 안에 숨어 있기 때문입니다.