🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

이 글은 AI 에이전트의 오류를 코드 실패가 아니라 런타임에 드러나는 추론 실패로 보고, runs·traces·threads 기반 관측성이 디버깅과 평가의 핵심 토대가 된다고 설명한다.

📌 핵심 요약

• 전통적 소프트웨어는 코드와 로그, 스택 트레이스로 실패 지점을 추적할 수 있었지만, AI 에이전트는 수십·수백 단계의 추론과 도구 호출 속에서 행동이 발생하므로 무엇이 잘못됐는지 이해하려면 실제 실행 기록이 필요하다.
• LLM 애플리케이션에서 에이전트로 갈수록 불확실성은 커진다. 에이전트는 LLM과 도구를 반복 호출하며 상태를 유지하고 맥락에 따라 행동을 바꾸기 때문에, 코드와 프롬프트만으로는 실제 동작을 알 수 없다.
• 에이전트 관측성의 핵심 원시 단위는 run, trace, thread다. run은 단일 LLM 호출의 입력·출력·도구·맥락을 담고, trace는 전체 실행 궤적을 연결하며, thread는 여러 실행이 이어지는 대화 세션과 상태 변화를 보존한다.
• 에이전트 평가는 결정론적 코드 경로를 확인하는 전통적 테스트와 다르다. 단일 단계에서는 특정 순간의 판단을, 전체 턴에서는 완전한 작업 수행 궤적을, 다중 턴에서는 대화와 누적 맥락 유지 여부를 평가해야 한다.
• 운영 환경의 trace는 단순한 사후 디버깅 자료가 아니라 지속적 개선의 입력이 된다. 실제 사용자 입력에서 드러난 실패 양상은 오프라인 평가 사례로 전환되고, 평가 스위트는 사전에 설계한 시나리오만이 아니라 실제 실행 데이터로 확장된다.

🧩 주요 포인트

1. 전통적 소프트웨어는 코드와 로그, 스택 트레이스로 실패 지점을 추적할 수 있었지만, AI 에이전트는 수십·수백 단계의 추론과 도구 호출 속에서 행동이 발생하므로 무엇이 잘못됐는지 이해하려면 실제 실행 기록이 필요하다.
2. LLM 애플리케이션에서 에이전트로 갈수록 불확실성은 커진다. 에이전트는 LLM과 도구를 반복 호출하며 상태를 유지하고 맥락에 따라 행동을 바꾸기 때문에, 코드와 프롬프트만으로는 실제 동작을 알 수 없다.
3. 에이전트 관측성의 핵심 원시 단위는 run, trace, thread다. run은 단일 LLM 호출의 입력·출력·도구·맥락을 담고, trace는 전체 실행 궤적을 연결하며, thread는 여러 실행이 이어지는 대화 세션과 상태 변화를 보존한다.
4. 에이전트 평가는 결정론적 코드 경로를 확인하는 전통적 테스트와 다르다. 단일 단계에서는 특정 순간의 판단을, 전체 턴에서는 완전한 작업 수행 궤적을, 다중 턴에서는 대화와 누적 맥락 유지 여부를 평가해야 한다.
5. 운영 환경의 trace는 단순한 사후 디버깅 자료가 아니라 지속적 개선의 입력이 된다. 실제 사용자 입력에서 드러난 실패 양상은 오프라인 평가 사례로 전환되고, 평가 스위트는 사전에 설계한 시나리오만이 아니라 실제 실행 데이터로 확장된다.

🧠 상세 정리

1. 문제의 출발점: 코드 오류가 아니라 추론 오류

글은 AI 에이전트 디버깅이 전통적 소프트웨어 디버깅과 근본적으로 다르다는 문제의식에서 출발한다. 일반 소프트웨어에서는 오류 로그와 스택 트레이스를 보고 실패한 코드 줄이나 함수를 찾아가면 된다. 그러나 에이전트가 2분 동안 200단계를 수행하다가 중간 어딘가에서 잘못된 판단을 했다면, 실패 지점은 단일 코드 줄이 아니라 에이전트의 추론 과정 안에 있다. 그래서 저자는 에이전트의 실제 행동을 이해하지 못하면 신뢰할 수 있는 에이전트를 만들 수 없고, 체계적 평가 없이는 개선이 실제로 효과가 있었는지도 검증할 수 없다고 강조한다.

2. 소스 오브 트루스의 이동: 코드에서 trace로

에이전트를 만들 때 개발자는 여전히 도구 목록, 접근 가능한 데이터, 프롬프트, 도구 설명 같은 코드를 작성한다. 하지만 LLM이 그 지시를 어떻게 해석하고 어떤 순서로 판단할지는 실행 전에는 확정적으로 알 수 없다. 이 때문에 글은 에이전트 엔지니어링에서 진짜 근거가 코드 자체에서 실제 실행을 보여주는 trace로 이동한다고 설명한다. 관측성과 평가는 이 반복 루프를 닫는 장치이며, 에이전트가 어떤 맥락에서 무엇을 보고 어떤 결정을 내렸는지를 기록해야 디버깅과 개선이 가능해진다.

3. 전통적 관측성과 에이전트 관측성의 차이

전통적 소프트웨어는 대체로 결정론적이어서 같은 입력에 같은 출력이 나오고, 로직은 코드에 명시된다. LLM 애플리케이션은 자연어의 모호성을 도입하지만 보통 하나의 LLM 호출 안에 묶여 있다. 반면 에이전트는 LLM과 도구를 반복적으로 호출하면서 작업이 끝났다고 판단할 때까지 상태를 유지하고, 상황에 따라 행동을 바꾼다. 따라서 기존 분산 trace처럼 어떤 서비스가 호출됐고 시간이 얼마나 걸렸는지만 기록하는 방식으로는, 200단계 실행 중 왜 특정 시점에 read_file이 아니라 edit_file을 골랐는지 같은 질문에 답할 수 없다.

4. 에이전트 평가는 코드 경로가 아니라 추론을 평가한다

전통적 소프트웨어 테스트는 output이 expected_output과 같은지 확인하는 식의 결정론적 검증에 강하다. 하지만 에이전트 평가는 읽고 수정할 수 있는 코드 경로가 아니라, 특정 맥락에서 에이전트가 한 판단과 전체 실행 결과를 평가해야 한다. 글은 단일 단계, 전체 턴, 다중 턴이라는 서로 다른 평가 단위를 제시한다. 단일 단계 평가는 특정 순간의 의사결정이 맞았는지 보고, 전체 턴 평가는 하나의 작업을 끝까지 제대로 수행했는지 보며, 다중 턴 평가는 대화가 이어지는 동안 맥락을 유지했는지를 확인한다.

5. 운영 환경은 실패 사례를 발견하는 주된 교사

글은 에이전트에서 production의 역할이 전통적 소프트웨어와 다르다고 말한다. 일반 소프트웨어에서는 오프라인 테스트, 통합 테스트, 스테이징 검증으로 대부분의 정합성 문제를 미리 잡고, 운영 환경에서는 놓친 엣지 케이스를 확인하는 경우가 많다. 그러나 에이전트는 자연어 입력이 매번 다르고 사용자가 어떤 표현으로 요청할지 예측하기 어렵다. 그래서 운영 trace는 예상하지 못한 실패 양상을 드러내며, 실제 사용자 상호작용에서 올바른 행동이 무엇인지 이해하게 해준다. 이 trace들은 이후 오프라인 평가 케이스가 되어 평가 스위트를 계속 확장한다.

6. 관측성의 세 가지 원시 단위: run, trace, thread

에이전트 관측성은 비결정적 추론을 포착하기 위해 run, trace, thread라는 세 가지 단위를 사용한다. run은 하나의 실행 단계, 특히 한 번의 LLM 호출과 그 입력·출력·지시·도구·맥락을 담는다. trace는 여러 run을 연결해 하나의 완전한 에이전트 실행 궤적을 보여주며, 각 단계의 도구 호출과 인자, 결과, 중첩 구조를 포함한다. thread는 여러 trace를 하나의 대화 세션으로 묶어 시간에 따른 상호작용과 상태 변화를 보존한다. 이 개념들은 기존 관측성의 trace나 span과 닮았지만, 핵심은 서비스 호출 시간이 아니라 추론 맥락을 기록한다는 점이다.

7. trace와 thread가 드러내는 장기적 맥락의 중요성

글은 에이전트 trace가 매우 커질 수 있다고 설명한다. 일반적인 분산 trace가 몇백 바이트 수준일 수 있는 반면, 복잡하고 오래 실행되는 에이전트의 trace는 수백 메가바이트에 이를 수 있다. 이는 과한 기록이 아니라, 각 단계에서 모델에 들어간 정보와 도구 호출, 결과, 단계 간 관계를 이해하기 위해 필요한 맥락이다. thread의 중요성은 코딩 에이전트 예시로 설명된다. 11번째 턴에서 생긴 실수만 보면 합리적인 도구 호출처럼 보일 수 있지만, 전체 thread를 보면 6번째 턴에서 잘못된 가정을 메모리에 저장했고 그 오류가 누적되어 이후 행동을 망쳤다는 사실을 발견할 수 있다.

8. 평가 단위별 활용: 단일 단계와 전체 턴

관측성 원시 단위는 평가 단위와 직접 연결된다. 단일 단계 평가는 run을 대상으로 하며, 특정 상태에서 에이전트가 올바른 도구를 골랐는지 또는 올바른 인자를 사용했는지 확인한다. 글의 예시는 일정 조율 에이전트가 회의를 바로 생성하기 전에 먼저 가능한 시간을 찾아야 한다는 상황이다. 사용자가 내일 아침 Harrison과 회의를 잡아 달라고 했을 때, 테스트는 find_meeting_times를 골랐는지 확인하고 schedule_meeting을 바로 호출하지 않았는지 검증한다. 전체 턴 평가는 trace를 대상으로 하며, 필요한 도구 호출 궤적, 최종 응답의 정확성과 유용성, 파일 작성이나 메모리 저장 같은 상태 변화를 함께 본다.

🧾 핵심 주장 / 시사점

• 에이전트 품질 관리는 코드 리뷰만으로 충분하지 않으며, 실제 실행에서 생성된 trace를 제품의 핵심 데이터 자산처럼 축적하고 재사용해야 한다.
• 운영 trace를 평가 케이스로 전환하는 루프가 중요하다. 예상한 테스트만 통과하는 에이전트보다, 실제 실패 사례를 계속 흡수해 회귀를 막는 에이전트가 더 안정적으로 개선된다.
• 디버깅 대상이 코드 줄에서 추론 궤적으로 이동했기 때문에, 관측성 도구도 단순 로그 수집을 넘어 프롬프트, 도구 선택, 인자, 결과, 장기 맥락의 변화를 함께 설명할 수 있어야 한다.

✅ 액션 아이템

• run·trace·thread 단위를 기준으로 실행 로그를 통합 저장하고, 각 항목에 입력·출력·도구 호출·상태를 함께 기록한다.
• 평가를 단일 단계, 단일 턴, 다중 턴으로 나눠 판단 오류·추론 궤적 단절·맥락 불일치로 실패 유형을 분리해 정리한다.
• 운영 trace의 반복 실패를 오프라인 사례로 환류해 사전 설계 시나리오 외 실제 입력 기반 평가 범위를 확장한다.

❓ 열린 질문

• run·trace·thread를 어느 깊이까지 영구 수집해야 추적 정확도와 저장·분석 비용을 동시에 맞출 수 있는가?
• 멀티 턴에서 맥락 유지 실패를 판정할 때 실제 사용자 입력 변동성을 반영한 기준은 무엇으로 잡아야 하는가?
• 실시간 trace에서 추론 실패를 코드/프롬프트 한계로 인한 오류와 구분하려면 판단 기준은 어떻게 정해야 하는가?