실행 추적성

=> AI관련들 이동

AI 엔지니어링에서 운영 가시성과 실행 추적성을 확보하는 방법

AI Agent가 단순히 답변을 생성하는 수준을 넘어 여러 Tool을 호출하고, 외부 데이터를 조회하고, 파일을 수정하며, 여러 단계의 작업을 수행하기 시작하면서 운영 가시성 및 실행 추적성(Observability)의 중요성도 커지고 있다.

Observability는 일반적으로 관측 가능성이라고 번역하지만 다소 직역된 표현처럼 느껴질 수 있다.

이 글에서는 조금 더 직관적으로

"AI가 실제로 무엇을 했는지 확인하고 추적할 수 있는 능력"

이라는 의미에서 운영 가시성 또는 실행 추적성이라는 표현을 사용하려고 한다.

기존 애플리케이션에서도 로그와 모니터링은 중요했다.

요청 발생
   ↓
API 호출
   ↓
오류 발생
   ↓
Log 확인
   ↓
Stack Trace 확인
   ↓
원인 분석

하지만 AI Agent에서는 문제가 조금 달라진다.

Agent는 하나의 요청을 처리하면서 여러 번 모델을 호출하고, Context를 검색하고, Tool을 선택하고, 실행 결과에 따라 다음 행동을 결정할 수 있다.

사용자 요청
    ↓
Agent 판단
    ↓
Context 검색
    ↓
Tool A 호출
    ↓
결과 확인
    ↓
Tool B 호출
    ↓
Agent 재판단
    ↓
최종 결과

문제는 최종 결과만 보고서는 중간에 어떤 일이 일어났는지 알기 어렵다는 것이다.

예를 들어 Agent가 잘못된 답변을 만들었다고 하자.

원인은 여러 가지일 수 있다.

사용자 의도를 잘못 이해했는가?

잘못된 Context를 검색했는가?

오래된 문서를 참고했는가?

잘못된 Tool을 선택했는가?

Tool Parameter를 잘못 생성했는가?

Tool 결과를 잘못 해석했는가?

중간 상태가 잘못 전달되었는가?

재시도 과정에서 다른 방향으로 갔는가?

따라서 AI 시스템에서는 단순히

ERROR 발생

을 기록하는 것만으로는 부족하다.

Agent가 어떤 경로를 거쳐 현재 결과에 도달했는지를 추적할 수 있어야 한다.

---

왜 AI Agent에서 실행 추적성이 더 중요할까?

기존 애플리케이션은 대부분 개발자가 미리 정의한 흐름을 따라간다.

Controller
    ↓
Service
    ↓
Repository
    ↓
Database

어떤 API가 호출되면 대략 어떤 코드가 실행되는지 예상할 수 있다.

하지만 Agent 시스템에서는 실행 경로가 요청마다 달라질 수 있다.

예를 들어 같은 예약 변경 요청이라도

Request A

예약 조회
 → 예약 변경
 → 완료

가 될 수도 있고

Request B

회원 조회
 → 예약 조회
 → 정책 검색
 → 예약 변경
 → 결제 조회
 → 환불 처리

가 될 수도 있다.

즉 실행 경로 자체가 동적이다.

따라서 Agent 시스템에서는

무엇을 실행했는가?

뿐만 아니라

어떤 순서로 실행했는가?

를 함께 볼 수 있어야 한다.

특히 Agent는 최종적으로 정상적인 답변을 만들더라도 내부적으로 잘못된 경로를 거쳤을 수 있다.

잘못된 Tool 선택
      ↓
추가 검색
      ↓
또 다른 Tool 호출
      ↓
우연히 정답 도달

겉으로는 성공처럼 보인다.

하지만 다음 실행에서는 같은 경로가 실패할 수 있다.

따라서 AI Agent에서는 최종 결과뿐 아니라 실행 과정도 하나의 품질 대상으로 봐야 한다.

---

1. Agent의 실행을 Trace 단위로 기록한다

AI Agent의 실행을 분석하려면 하나의 사용자 요청이 어디에서 시작해서 어디까지 진행되었는지를 연결해서 볼 수 있어야 한다.

예를 들어

사용자 요청

"이번 달 매출을 분석해줘."

라는 작업이 있다고 하자.

Agent 내부에서는 다음과 같은 작업이 발생할 수 있다.

Trace #A1024

사용자 요청
   ↓
Model Call
   ↓
매출 데이터 필요 판단
   ↓
Database Tool
   ↓
Model Call
   ↓
지난달 데이터 추가 조회
   ↓
Database Tool
   ↓
분석
   ↓
최종 답변

이 전체 실행 흐름을 하나의 Trace로 묶어 관리할 수 있다.

그리고 Trace 내부의 각 작업은 개별 Step 또는 Run으로 기록한다.

Trace

├─ Model Call
├─ Retrieval
├─ Tool Call
├─ Model Call
├─ Tool Call
└─ Final Response

이렇게 하면 문제가 발생했을 때 특정 Agent 실행 전체를 한 번에 확인할 수 있다.

---

2. Tool 호출을 상세하게 추적한다

Agent 시스템에서는 Tool 사용이 매우 중요하다.

Agent가 Tool을 잘못 선택하거나 Parameter를 잘못 전달하면 실제 시스템에 영향을 줄 수 있기 때문이다.

따라서 최소한 다음 정보는 기록할 필요가 있다.

어떤 Tool을 호출했는가?

언제 호출했는가?

어떤 Parameter를 전달했는가?

실행 결과는 무엇인가?

성공했는가?

실패했다면 어떤 오류인가?

얼마나 오래 걸렸는가?

예를 들어

Tool

cancelReservation

Input

reservationId = R1024

Result

SUCCESS

Duration

320ms

처럼 기록할 수 있다.

또한 Tool을 실행하기 전에 승인 절차가 있었다면 그것도 함께 남긴다.

refundPayment

risk = HIGH

approval = REQUIRED

approved_by = USER

result = SUCCESS

이런 기록이 있으면 단순한 디버깅을 넘어 감사 기록(Audit Trail)으로도 사용할 수 있다.

---

3. 어떤 Context를 사용했는지 확인할 수 있어야 한다

AI Agent가 잘못된 판단을 했을 때 실제 원인은 모델이 아니라 Context일 수 있다.

예를 들어

VIP 취소 정책
= 예약 2시간 전까지 가능

이 현재 정책인데 Agent가

3시간 전까지 가능

으로 답했다고 해보자.

Agent 자체의 추론 문제가 아닐 수도 있다.

Trace를 확인했더니

CancellationPolicy_2025.md

라는 오래된 문서를 검색했을 수도 있다.

따라서 Retrieval을 사용하는 시스템에서는 다음 정보도 확인할 수 있어야 한다.

어떤 검색어를 사용했는가?

어떤 문서를 가져왔는가?

문서의 Version은 무엇인가?

검색 Score는 얼마인가?

몇 개의 문서를 Context에 넣었는가?

최종 답변에서 어떤 정보가 사용되었는가?

즉

User Request
    ↓
Retrieval
    ↓
Context
    ↓
Agent

전체 경로를 확인할 수 있어야 한다.

이는 RAG뿐만 아니라 Ontology나 Graph 기반 Context Retrieval에서도 동일하다.

VIP
 ↓
Customer
 ↓
Reservation
 ↓
CancellationPolicy

Agent가 어떤 Entity와 Relation을 따라갔는지 추적할 수 있다면 잘못된 관계를 찾기도 쉬워진다.

---

4. Agent의 상태 변화를 기록한다

Agent는 단순한 요청/응답 모델이 아니라 상태를 가지고 작업하는 경우가 많다.

예를 들어 LangGraph 형태의 Agent라면

Planner
 ↓
Worker
 ↓
Reviewer
 ↓
Human Gate
 ↓
Worker

처럼 상태를 계속 전달한다.

따라서 어떤 단계에서 상태가 어떻게 변경되었는지 기록할 필요가 있다.

예를 들어

State #1

task = 예약 정책 수정
status = PLANNING

에서

State #2

task = 예약 정책 수정
status = IMPLEMENTING
target_file = ReservationService.java

그리고

State #3

status = VALIDATING
test_failed = 2

처럼 변화할 수 있다.

이러한 상태 변화를 기록하면

어느 시점에서 잘못된 정보가 들어갔는가?

를 찾기 쉬워진다.

특히 Multi-Agent 시스템에서는 Agent 사이에 전달되는 상태가 잘못되면서 오류가 발생할 수도 있기 때문에 중요하다.

---

5. Multi-Agent의 Handoff를 추적한다

여러 Agent가 협업하면 하나의 작업이 여러 Agent를 거친다.

Planner
   ↓
Researcher
   ↓
Worker
   ↓
Reviewer

이때 각 Agent가 무엇을 전달했는지 확인할 수 있어야 한다.

예를 들어 Worker가 잘못된 구현을 했다.

원인은 Worker가 아니라 Planner가 잘못된 Task를 전달했을 수도 있다.

User

"VIP 예약 취소 제한을 2시간으로 변경"

        ↓

Planner

"VIP 예약 취소 제한을 3시간으로 변경"

        ↓

Worker

정확히 3시간으로 구현

Worker만 보면 정상적으로 작업했다.

문제는 Handoff 과정에서 발생했다.

따라서 Multi-Agent 환경에서는

Agent A

Input
Output

        ↓

Agent B

Input
Output

형태로 Agent 사이의 전달 경로를 추적할 수 있어야 한다.

---

6. 실행 결과와 실제 환경 상태를 함께 본다

Agent가

"작업을 완료했습니다."

라고 응답했다고 해서 실제 작업이 완료된 것은 아니다.

예를 들어 예약 취소 Agent가

예약을 취소했습니다.

라고 답했지만 실제 DB 상태가

status = ACTIVE

라면 실패다.

따라서 실행 추적에서는 Agent의 답변과 실제 환경 상태를 함께 보는 것이 좋다.

Agent Response

"예약 취소 완료"

        ↓

Environment State

reservation.status = CANCELLED

Coding Agent도 마찬가지다.

Agent

"Bug 수정 완료"

        ↓

Git Diff
Test Result
Build Result

를 함께 확인해야 한다.

Agent의 자연어 응답보다 실제 시스템 상태가 더 중요한 관측 대상이 될 수 있다.

---

7. Test와 Eval 결과를 Trace에 연결한다

Agent가 코드를 수정했다면 이후 실행된 Test 결과도 같은 Trace에서 확인할 수 있어야 한다.

예를 들어

Task #1827

Agent 코드 수정
      ↓
Unit Test

32 PASS
2 FAIL
      ↓
Agent 재수정
      ↓
Unit Test

34 PASS
      ↓
Regression Test

128 PASS

형태로 확인할 수 있다.

그러면 단순히 최종적으로 Test가 통과했다는 사실뿐 아니라

처음에 무엇을 잘못했는가?

몇 번 수정했는가?

어떤 오류를 통해 수정했는가?

까지 확인할 수 있다.

Eval 결과 역시 연결할 수 있다.

Trace #1024

Task Success        PASS
Correctness         0.96
Tool Selection      PASS
Security            PASS
Cost                $0.23
Latency             8.4s

이렇게 하면 Trace가 단순한 디버깅 기록을 넘어 Agent 품질 분석 데이터가 된다.

---

8. 비용과 Token 사용량도 추적한다

AI 시스템에서는 비용도 중요한 운영 정보다.

예를 들어 하나의 Task를 완료했는데

Model Call 3회

Token 20K

Cost $0.10

가 발생한 Agent와

Model Call 27회

Token 180K

Cost $1.30

가 발생한 Agent가 있다고 하자.

둘 다 Task를 성공했더라도 두 번째 Agent에는 개선할 부분이 있을 수 있다.

따라서 Trace에서 다음 정보를 확인할 수 있으면 좋다.

Input Token

Output Token

Model Call 횟수

Tool Call 횟수

Retry 횟수

Task당 비용

그리고 비용이 비정상적으로 증가하는 Agent를 찾을 수 있다.

평균 Task 비용

$0.30

인데

Task #9921

$4.80

이 발생했다면 원인을 분석한다.

무한 Loop?

불필요한 검색?

Context 과다?

Retry 반복?

너무 비싼 Model 사용?

실행 추적성은 비용 최적화와도 직접 연결된다.

---

9. Latency를 단계별로 추적한다

Agent의 응답이 느리다고 해도 모델이 느린 것인지 Tool이 느린 것인지 알 수 없다.

예를 들어 전체 응답 시간이

18초

라고 하자.

Trace를 분해하면

Model Call       2.1s

Retrieval        0.8s

Database Tool   11.2s

Model Call       2.4s

Formatting       0.3s

처럼 나타날 수 있다.

이 경우 Model을 바꾸는 것이 아니라 Database Tool을 개선해야 한다.

따라서 Agent의 실행 시간을

전체 Latency

뿐만 아니라

Step별 Latency

로 확인하는 것이 좋다.

특히 여러 Tool과 Agent가 연결될수록 병목 지점을 찾기 위해 Trace가 중요해진다.

---

10. Retry와 Loop를 감지한다

Agent는 실패했을 때 스스로 다시 시도할 수 있다.

이 기능은 정확성을 높이는 데 도움이 되지만 잘못 설계하면 무한 반복이 발생할 수 있다.

Tool 호출
 ↓
실패
 ↓
Retry
 ↓
실패
 ↓
Retry
 ↓
...

따라서 다음 정보를 관찰할 필요가 있다.

Retry 횟수

동일 Tool 반복 호출

동일 Query 반복

동일 Error 반복

Agent Step 수

예를 들어

search_customer

를 15번 반복하고 있다면 비정상적인 패턴일 가능성이 높다.

일정 수준 이상 반복되면

Agent 실행 중단

또는

Human Gate

로 넘길 수도 있다.

즉 Observability는 단순히 문제 발생 후 확인하는 것뿐만 아니라 비정상 Agent 행동을 실시간으로 감지하는 역할도 한다.

---

11. 정상 종료와 실제 성공을 구분한다

기존 시스템에서는 HTTP 200이 반환되면 어느 정도 성공으로 판단할 수 있었다.

하지만 AI Agent는 다르다.

HTTP 200

이면서도

잘못된 답변

잘못된 Tool 선택

필요한 행동 누락

정책 위반

이 발생할 수 있다.

따라서 다음 두 가지를 구분해야 한다.

System Success

요청 처리 자체가 정상적으로 종료되었는가?

Task Success

사용자가 원한 작업이 실제로 완료되었는가?

예를 들어

HTTP       200
Agent      정상 종료
Tool Error 없음

하지만

예약 상태 ACTIVE

→ Task Failure

일 수 있다.

AI Agent 운영에서는 기술적인 성공과 업무적인 성공을 분리해서 관찰해야 한다.

---

12. 실패 유형을 분류한다

Agent 실패를 모두

Agent Error

하나로 기록하면 개선하기 어렵다.

실패 원인을 분류하는 것이 좋다.

예를 들어

Intent Error

사용자 요구사항 이해 실패

Retrieval Error

잘못된 Context 검색

Tool Selection Error

잘못된 Tool 선택

Tool Execution Error

Tool 실행 실패

Policy Error

권한 또는 정책 위반

Reasoning / Decision Error

중간 판단 오류

Timeout

시간 초과

이렇게 분류할 수 있다.

운영 데이터가 쌓이면

전체 실패 1,000건

Retrieval Error       38%
Tool Selection Error  24%
Tool Execution Error  18%
Policy Error           10%
기타                   10%

처럼 볼 수 있다.

그러면

모델을 더 좋은 것으로 바꿔야 한다.

가 아니라

Retrieval 구조를 먼저 개선해야 한다.

는 판단을 할 수 있다.

---

13. Correlation ID를 이용해 전체 요청을 연결한다

Agent 시스템이 복잡해지면 하나의 사용자 요청이 여러 시스템을 지나간다.

Frontend
   ↓
API
   ↓
Agent
   ↓
MCP
   ↓
Database
   ↓
외부 API

각 시스템의 Log가 따로 존재하면 하나의 요청을 추적하기 어렵다.

따라서 요청마다 고유한 ID를 부여할 수 있다.

trace_id = A7F29C

그리고 각 시스템에서 같은 ID를 기록한다.

API

trace_id=A7F29C

Agent

trace_id=A7F29C

Tool

trace_id=A7F29C

Database

trace_id=A7F29C

그러면 문제가 발생했을 때 하나의 ID를 기준으로 전체 시스템의 실행 경로를 추적할 수 있다.

이는 기존 분산 시스템의 Distributed Tracing과 같은 개념을 Agent 시스템까지 확장한 것이다.

---

14. 로그를 구조화한다

Agent 로그를 단순 문자열로 남기면 나중에 분석하기 어렵다.

예를 들어

Agent가 Tool을 호출했고 실패했습니다.

보다 다음처럼 구조화할 수 있다.

{
  "traceId": "A1024",
  "agent": "reservation-agent",
  "event": "tool_call",
  "tool": "cancelReservation",
  "status": "failed",
  "latency": 321,
  "retry": 1
}

이렇게 하면 검색과 집계가 쉬워진다.

예를 들어

cancelReservation

최근 24시간 실패율

또는

reservation-agent

평균 Tool Call 횟수

같은 지표를 만들 수 있다.

Agent 시스템이 커질수록 사람이 직접 Log를 읽는 방식에는 한계가 있기 때문에 구조화된 Event 형태로 기록하는 것이 중요하다.

---

15. Dashboard를 통해 전체 상태를 확인한다

개별 Trace 분석도 중요하지만 시스템 전체 상태를 한눈에 볼 수 있어야 한다.

예를 들어 Dashboard에서 다음 정보를 확인할 수 있다.

Task Success Rate

92.4%

Tool Error Rate

2.1%

Average Latency

8.3s

P95 Latency

15.8s

Average Cost

$0.28

Human Intervention

7.4%

Agent별로 비교할 수도 있다.

Planner

Success 97%

Worker

Success 91%

Reviewer

Detection Rate 88%

또는 Tool별로 볼 수 있다.

Database Tool

Error 0.4%

Web Tool

Error 3.8%

Payment Tool

Error 1.1%

이런 Dashboard가 있으면 특정 문제가 증가하는 것을 빠르게 발견할 수 있다.

---

16. 중요한 이상 행동에는 Alert를 설정한다

모든 Trace를 사람이 직접 확인하는 것은 불가능하다.

따라서 중요한 이상 행동에는 자동 Alert를 설정하는 것이 좋다.

예를 들어

Error Rate > 5%

→ Alert

Task당 Tool Call > 30

→ Alert

Task Cost > $3

→ Alert

Security Policy Violation 발생

→ Critical Alert

Human Approval 우회 시도

→ Critical Alert

처럼 설정할 수 있다.

AI Agent에서는 기존 서버의 CPU나 Memory뿐만 아니라 Agent 행동 자체를 Alert 조건으로 사용할 수 있다는 점이 중요하다.

---

17. Production Trace를 Eval 데이터로 다시 활용한다

실행 추적성의 가장 큰 가치는 단순한 디버깅이 아니다.

실제 운영에서 발생한 실패를 다시 평가 데이터로 활용할 수 있다.

예를 들어 Production에서 다음 문제가 발생했다.

사용자

"지난달 예약 취소 내역 보여줘."

Agent

이번 달 데이터 조회

Trace를 분석해보니 날짜 해석이 잘못되었다.

이 사례를

Eval Dataset

에 추가한다.

Input

지난달 예약 취소 내역 보여줘.

Expected

이전 달 데이터 조회

그리고 이후 Agent 변경 시 항상 다시 실행한다.

Production Failure
       ↓
Trace 분석
       ↓
Eval Case 생성
       ↓
Regression Eval
       ↓
다시는 같은 오류가 발생하지 않도록 함

즉

Observability → Evaluation → Improvement

의 루프가 만들어진다.

---

18. 모든 데이터를 무조건 기록하지 않는다

Observability가 중요하다고 해서 모든 정보를 그대로 저장하는 것은 위험하다.

Agent Context에는 다음과 같은 정보가 들어갈 수 있다.

개인정보

회사 내부 문서

API Response

Source Code

Customer Data

Credential

이를 그대로 Trace에 남기면 새로운 보안 문제가 발생할 수 있다.

따라서 기록 단계에서

Masking

Redaction

Filtering

을 적용할 수 있다.

예를 들어

전화번호

010-1234-5678

대신

010-****-5678

처럼 저장한다.

API Key와 같은 Secret은 아예 저장하지 않는 것이 좋다.

Authorization

Bearer ********

실행 추적성과 개인정보 보호 사이의 균형을 고려해야 한다.

---

19. Trace 보관 기간을 관리한다

Agent Trace는 빠르게 쌓인다.

하루

10만 Task

Task당 20 Step

→ 200만 Events

모든 Trace를 영구 보관하면 저장 비용도 크게 증가한다.

따라서 데이터 유형에 따라 보관 기간을 다르게 설정할 수 있다.

일반 Trace

30일

오류 Trace

90일

보안 관련 Trace

정책에 따른 장기 보관

또는 정상 요청은 일부만 Sampling하고 실패 요청은 전부 저장하는 방식도 사용할 수 있다.

Success Trace

10% Sampling

Failure Trace

100% 저장

즉 Observability에도 비용 관리가 필요하다.

---

20. Monitoring과 Observability를 구분한다

Monitoring과 Observability는 비슷해 보이지만 조금 다르게 볼 수 있다.

Monitoring은 주로

현재 시스템에 문제가 있는가?

를 확인한다.

예를 들어

Error Rate

Latency

CPU

Memory

Request Count

같은 지표를 본다.

반면 Observability는

왜 이런 결과가 발생했는가?

를 분석하는 데 초점이 있다.

Agent에서는 특히 이 차이가 중요하다.

Monitoring

Agent 실패율이 10%로 증가했다.

에서 끝나는 것이 아니라

Observability

최근 Retrieval 결과가 변경되면서
잘못된 문서를 가져오기 시작했고

그 결과 Payment Tool 대신
Reservation Tool을 선택하면서

Task 실패율이 증가했다.

까지 분석할 수 있어야 한다.

즉

Monitoring
=
문제가 있다는 것을 발견

Observability
=
문제가 발생한 이유를 추적

이라고 볼 수 있다.

---

21. 기존 애플리케이션 모니터링과 Agent Trace를 연결한다

AI Agent만 별도로 관찰해서도 충분하지 않다.

실제 시스템은 기존 애플리케이션과 연결되어 있기 때문이다.

User
 ↓
Frontend
 ↓
Backend
 ↓
AI Agent
 ↓
MCP / Tool
 ↓
Database

예를 들어 Agent 응답이 느린 이유가 모델 때문이 아니라 Backend API 장애일 수도 있다.

따라서 가능하다면

Application Trace
       +
Agent Trace
       +
Infrastructure Metric

을 연결해서 볼 수 있는 것이 좋다.

User Request
     ↓
Backend 200ms
     ↓
Agent 2s
     ↓
Payment API 12s
     ↓
Agent 1s

Total 15.2s

이렇게 전체 요청을 연결하면 실제 병목을 정확히 찾을 수 있다.

---

22. OpenTelemetry와 같은 공통 표준을 활용할 수 있다

Agent 시스템마다 독자적인 Trace 형식을 만들면 Tool이나 플랫폼을 변경할 때 어려움이 생길 수 있다.

기존 분산 시스템에서는 OpenTelemetry를 이용해

Trace

Metric

Log

를 표준화하는 방식이 널리 사용된다.

AI Agent 영역에서도 이러한 기존 관측 표준을 확장해

Model Call

Tool Call

Retrieval

Agent Step

같은 실행 정보를 연결하려는 방향이 사용되고 있다.

특정 Agent Framework나 Observability 제품에 완전히 종속되지 않도록 공통 추적 체계를 사용하는 것도 고려할 수 있다.

---

23. 모든 내부 추론 내용을 저장하려고 할 필요는 없다

Agent의 실행을 추적한다고 해서 모델 내부의 모든 사고 과정을 저장해야 하는 것은 아니다.

실제로 운영에 필요한 것은 대부분

어떤 입력을 사용했는가?

어떤 Context를 조회했는가?

어떤 Tool을 선택했는가?

어떤 Parameter를 사용했는가?

어떤 결과를 받았는가?

상태가 어떻게 바뀌었는가?

최종 결과는 무엇인가?

와 같은 관찰 가능한 행동과 상태 변화다.

중요한 것은 모델 내부 생각을 모두 기록하는 것이 아니라

시스템이 어떤 판단 결과를 바탕으로 실제로 어떤 행동을 했는지 추적할 수 있는 것이다.

---

24. Trace는 Debugging 도구를 넘어 개선 데이터가 된다

초기에는 Observability를 단순히

문제가 발생했을 때 Log 확인

정도로 생각하기 쉽다.

하지만 Agent 시스템에서 Trace 데이터는 더 큰 가치를 가진다.

운영 Trace를 분석하면

자주 실패하는 Task

불필요하게 반복되는 Tool

잘못 선택되는 Tool

자주 누락되는 Context

비용이 높은 Workflow

Human Gate가 많이 발생하는 영역

을 발견할 수 있다.

그리고 이를 기반으로

Prompt 개선

Context 개선

Tool 개선

Ontology 개선

Agent 구조 개선

Eval Dataset 추가

를 할 수 있다.

즉 Observability는

문제 발생
   ↓
원인 분석

에서 끝나는 것이 아니라

문제 발생
   ↓
Trace 분석
   ↓
패턴 발견
   ↓
Eval 추가
   ↓
시스템 개선
   ↓
Production 재측정

이라는 지속적인 개선 루프의 시작점이 된다.

---

AI Agent의 실행 추적 구조

전체 구조를 정리하면 다음과 같다.

                      사용자 요청

                           ↓

                     Trace 생성

                           ↓

                     Agent 실행

                           ↓

       ┌───────────────────┼───────────────────┐
       │                   │                   │

    Model Call          Retrieval           Tool Call

       │                   │                   │
       │                   │                   │

 Token / Cost        Context / Source      Input / Output
 Latency             Version / Score       Latency / Error

       └───────────────────┼───────────────────┘

                           ↓

                     State 변경

                           ↓

                     Agent 판단

                           ↓

                     Test / Eval

                           ↓

                    최종 환경 상태

                           ↓

              ┌────────────┴────────────┐
              │                         │

          Dashboard                  Trace 분석

              │                         │

           Alert                  Failure 분석

                                        ↓

                                  Eval Dataset

                                        ↓

                                   Agent 개선

실제로 활용할 수 있는 방법을 정리하면 다음과 같다.

• Trace
• Run / Step Tracking
• Tool Call Tracking
• Retrieval Tracking
• Context Source Tracking
• Agent State Tracking
• Multi-Agent Handoff Tracking
• Environment State Verification
• Test / Eval Result Tracking
• Token Usage
• Cost Tracking
• Latency Tracking
• Retry / Loop Detection
• Correlation ID
• Structured Logging
• Dashboard
• Alert
• Failure Classification
• Audit Log
• Data Masking
• Trace Sampling
• Retention Policy
• OpenTelemetry
• Production Trace → Eval 변환

결국 AI 엔지니어링에서 실행 추적성을 확보한다는 것은 단순히 로그를 많이 남기는 것이 아니다.

중요한 것은

무슨 일이 일어났는가?

왜 이런 결과가 나왔는가?

어디에서 문제가 시작되었는가?

어떻게 다시 발생하지 않게 할 것인가?

에 답할 수 있는 구조를 만드는 것이다.

AI Agent가 단순한 응답 생성기에서 실제 시스템을 움직이는 실행 주체로 발전할수록 사람이 모든 실행을 직접 지켜보는 것은 불가능해진다.

따라서 앞으로의 AI 엔지니어링에서는 Agent가 자율적으로 움직일 수 있게 만드는 것만큼

그 Agent가 무엇을 했는지 언제든 추적하고 설명할 수 있는 환경을 만드는 것

이 중요해질 것이다.

결국 실행 추적성의 핵심은

AI를 계속 지켜보는 것이 아니라, 문제가 생겼을 때 그 행동을 다시 따라갈 수 있게 만드는 것

이라고 볼 수 있다.