AI 에이전트의 로그를 읽을 수 없다면, 그것은 아직 데모일 뿐입니다

용어

• AI 에이전트 (AI Agent): LLM이 도구 호출 (tool call), 검색 (search), 파일 조작, 외부 API 실행 등을 조합하여 태스크를 진행하는 메커니즘
• 트레이스 (trace): 1회의 실행에서 입력, 참조 정보, tool call, tool result, 최종 출력 등을 나중에 추적할 수 있는 실행 기록
• 평가 케이스 (Evaluation case): 변경 전후의 동작을 비교하는 테스트 케이스와 같은 것
• 리트리벌 (retrieval): 문서나 DB에서 답변이나 판단에 사용할 근거를 추출하는 처리
• 메모리 (memory): 과거의 대화, 사용자 설정, 프로젝트 정보 등을 다음 회차 이후에 사용하는 기록
• 평가용 모델 (Evaluation model): 출력이나 trace를 다른 LLM이 평가하게 하는 메커니즘. 최종 판정자가 아님

AI 에이전트는 동작한 이후부터 어려워진다

AI 에이전트의 데모를 만드는 것은 쉬워졌습니다. 하지만 실전에서 요구되는 것은 "한 번 잘 작동했는가"가 아닙니다.

실패했을 때, 다음 질문에 답할 수 있는가입니다.

• 왜 그 도구를 호출했는가
• 어떤 검색 결과나 memory가 판단에 영향을 주었는가
• 실패가 prompt, retrieval, memory, tool, planning, verification 중 어디에서 발생했는가
• 수정 후에, 이전에 성공했던 케이스가 망가지지 않았는가
• 인간은 어디에서 승인하고, 어디에서 멈췄어야 했는가

답할 수 없다면, 운용 시스템이라기보다 아직 데모에 가까운 상태입니다.

실패를 설명할 수 없는 에이전트는 개선할 수 없다

일반적인 Web 앱이라도 로그가 없으면 장애 대응이 어려워집니다. AI 에이전트의 실패는 예외나 HTTP 상태 코드만으로는 나타나지 않습니다.

• 올바른 도구가 존재함에도 불구하고 다른 도구를 호출함
• 오래된 문서를 근거로 채택함
• 과거의 memory를 현재의 태스크에 잘못 사용함
• retry로 우연히 성공하여 근본 원인이 숨겨짐
• prompt를 수정했더니 다른 태스크의 성공률이 떨어짐

이것들은 에러 로그만으로는 보이지 않습니다.

같은 "기대하지 않은 실행"이라도, 원인 계층에 따라 수정 대상이 달라집니다.

어떤 정보를 보고, 어떤 판단을 하며, 어떤 행동을 선택했고, 어디에서 어긋났는지. 거기까지 추적할 수 없으면 수정은 감에 의존하게 됩니다.

trace는 "저장하는 로그"가 아니라 "고치기 위한 재료"

agent trace는 나중에 읽기 위한 실행 기록입니다. 다만, 입출력만으로는 부족합니다. 최소한 다음 정보는 남기고 싶습니다.

관측 대상	보고 싶은 이유
사용자 입력	무엇을 의뢰받았는지 재현하기
...

작은 검증: trace에 무엇을 남기면 원인을 분류할 수 있는가

24건의 합성 케이스(synthetic case)로 작은 검증을 수행했습니다. 실제 데이터는 아닙니다. 보고 싶은 것은 분류기의 성능이 아니라, trace의 입도(granularity)를 바꾸면 원인을 어디까지 분류할 수 있는가입니다.

항목	내용
케이스 수	24건
...

예를 들어, 다음과 같은 케이스입니다.

case = {
"label": "Tool argument failure",
"user_goal": "PROJ-21 을 closed 로 만들기",
...

증상만 보면 "결과가 기대와 다르다"는 것밖에 알 수 없습니다. 하지만 trace를 보면 도구 선택은 update_ticket으로 자연스럽습니다. 반면, 대상 ID가 PROJ-21이 아니라 PROJ-12로 되어 있습니다. 이 경우 가장 먼저 의심해야 할 것은 도구 선택이 아니라 도구 인자(tool argument)입니다.

결과는 다음과 같습니다.

실패 분류	건수	증상만	trace 있음
Instruction	3	1	3
...	합계	24	5

이 숫자는 일반화되지 않습니다. 합성 케이스이므로, trace 측에는 분류에 필요한 정보를 넣어두었습니다.

중요한 것은 24/24가 아니라 다음 점입니다.

증상명은 원인명이 아닙니다. trace에 tool call, tool args, retrieval, memory, verification이 남아 있으면 다음에 봐야 할 계층을 좁힐 수 있습니다.

실전 도입 전에 "어떤 실패를 분류하고 싶은가"를 결정하고, 이를 위한 trace 항목을 남겨둡니다. 이렇게 하면 observability는 단순한 로그 저장이 아니라 개선 루프의 부품이 됩니다.

trace를 개선 루프에 넣기

trace는 개선 루프에 넣어야 비로소 효과를 발휘합니다.

trace는 분류하여 평가 케이스로 되돌리고, 수정 후의 퇴행 확인(regression testing)과 실전 모니터링까지 연결해야 비로소 개선에 효과적입니다.

순서는 다음과 같습니다.

• 운영(production) trace 수집
• 실패 분류
• 대표 사례를 평가 케이스(evaluation case)로 전환
• prompt, tool schema, retrieval, memory, routing 등 원인 계층에 맞춰 수정
• 퇴행 확인(regression testing) 평가 실행
• 출시 여부 판단
• 운영 모니터링을 통한 재발 확인

LangSmith의 평가 문서에서는 운영 trace를 평가용 데이터로 되돌리는 흐름을 설명하고 있습니다. OpenAI의 trace grading docs에서도 trace에 점수나 라벨을 붙여 실패를 분석하는 개념을 설명하고 있습니다.

평가용 모델은 편리하지만, 최종 판정자는 아니다

대량의 trace를 사람이 직접 읽는 것은 매우 힘든 일입니다. 평가용 모델을 통해 "지시를 따랐는가", "근거가 있는가"를 거칠게 확인할 수 있다면 운영은 훨씬 수월해집니다.

하지만 평가용 모델을 최종 판정자로 삼아서는 안 됩니다.

• 채점 기준이 모호하면 자연스러운 문장을 높게 평가하기 쉽다
• 실제 시스템의 비즈니스 제약 사항을 알지 못한다
• tool의 부작용이나 권한 리스크를 간과할 수 있다
• 모델 간의 특성(bias) 때문에 동일한 종류의 실패를 놓칠 수 있다

현실적인 방법은 평가용 모델을 1차 필터(first filter)로 사용하는 것입니다. 위험도가 높은 항목과 랜덤 샘플을 사람이 직접 확인하고, 그 차이를 채점 기준이나 평가 케이스에 다시 반영합니다.

요약

AI 에이전트가 동작하는 단계까지는 빠르게 발전했습니다.

하지만 운영 환경에서는 "어떻게 동작시키는가"뿐만 아니라, "어떻게 수정 가능한 상태로 유지할 것인가"가 중요해집니다.

실패했을 때 trace를 읽을 수 있다. 분류할 수 있다. 대표 사례를 평가 케이스로 되돌릴 수 있다. 수정 전후의 퇴행을 확인할 수 있다.

이 상태가 되어야 비로소 에이전트는 데모를 넘어 운영 시스템에 가까워집니다.

참고 자료

Discussion