에이전트 PoC를 운영으로 넘기기 전, OpenTelemetry GenAI 로그부터 표준화해야 합니다

에이전트 로그는 프롬프트 전문 보관소가 아니라, operation·tool·model·latency·error를 추적하는 운영 telemetry로 설계해야 합니다.

들어가며 — 독자가 지금 이 문제를 검색하는 이유

AI 에이전트 PoC는 데모까지는 잘 갑니다.

문제는 운영으로 넘기는 순간부터 시작됩니다.

“왜 이 답을 했는가?”

“어떤 도구를 호출했는가?”

“어느 단계에서 느려졌는가?”

“비용이 늘어난 원인은 모델 호출인가, tool call인가?”

“실패한 실행을 다시 재현할 수 있는가?”

이 질문에 답하려면 대화 로그만으로는 부족합니다.

프롬프트와 응답 전문을 그대로 저장하는 방식은 보안·개인정보·권한 문제를 키울 수 있고, 장애 분석에도 늘 효율적인 것은 아닙니다.

이번 글의 핵심은 단순합니다.

에이전트 PoC를 운영으로 넘기기 전에 먼저 “무엇을 남길지”를 표준 스키마로 정해야 합니다.

그 기준으로 참고할 수 있는 것이 OpenTelemetry GenAI semantic conventions입니다.

OpenTelemetry 공식 문서는 GenAI attribute registry에서 gen_ai.operation.name, 입출력 메시지, tool call 관련 속성을 정의하고 있습니다. 다만 일부 GenAI semantic convention 문서는 별도 저장소로 이동 중이라고 표시되어 있어, 최종 안정성이나 각 APM 벤더의 지원 범위는 확인이 필요합니다.

출처: OpenTelemetry GenAI attribute registry, OpenTelemetry semantic-conventions v1.44.0 release

1. 에이전트 관찰성의 목표는 “대화 저장”이 아니라 “실행 추적”입니다

에이전트 운영 로그를 설계할 때 가장 흔한 실수는 모든 입력과 출력을 그대로 저장하려는 것입니다.

물론 디버깅할 때는 원문이 도움이 될 수 있습니다.

하지만 운영 기준에서는 그보다 먼저 정해야 할 것이 있습니다.

• 어떤 작업이 실행됐는가?
• 어떤 모델이 호출됐는가?
• 어떤 도구가 사용됐는가?
• 어느 단계에서 지연이 발생했는가?
• 오류가 난 위치는 모델 호출인가, 도구 호출인가, 후처리인가?
• 같은 실패가 반복되는가?

OpenTelemetry GenAI attribute registry는 이런 질문에 답하기 위한 속성 체계를 제공합니다. 예를 들어 gen_ai.operation.name은 GenAI 작업의 이름을 남기기 위한 속성입니다. 리서치 기준으로는 tool call 관련 속성과 입출력 메시지 관련 속성도 정의되어 있습니다.

여기서 중요한 점은 “무엇을 모두 저장할까?”가 아니라 “장애 분석과 비용 분석에 필요한 최소 telemetry는 무엇인가?”입니다.

운영형 에이전트 로그는 다음 네 가지를 중심으로 설계하는 편이 안전합니다.

구분	남겨야 할 내용	이유
operation	에이전트가 수행한 작업 이름	어떤 업무 흐름에서 문제가 났는지 추적
model	호출된 모델 정보	품질·비용·지연 원인 분석
tool	호출된 도구 이름과 단계	외부 시스템 연동 실패 분석
latency/error	지연시간과 오류	운영 장애 탐지와 재발 방지

반대로 프롬프트 전문, 사용자 입력 전문, 도구 응답 전문은 기본 저장 대상으로 두면 안 됩니다.

PII, 내부 문서, 고객 정보, 권한이 필요한 업무 데이터가 섞일 수 있기 때문입니다.

필요하다면 전문 저장은 별도 정책으로 분리해야 합니다.

• 기본값: 전문 미저장
• 예외: 디버깅 목적의 제한 저장
• 보존 기간: 별도 지정
• 접근 권한: 운영자·개발자 역할별 분리
• 마스킹: PII 및 민감정보 제거 후 저장

이렇게 해야 에이전트 로그가 보안 리스크가 아니라 운영 자산이 됩니다.

2. span·attribute·event를 나누면 장애 분석이 쉬워집니다

에이전트 실행은 하나의 답변처럼 보이지만, 실제로는 여러 단계가 이어진 결과입니다.

예를 들어 사내 문서 검색 에이전트라면 흐름은 대략 이렇습니다.

1. 사용자 질문 수신

2. 검색 쿼리 생성

3. 문서 검색 tool 호출

4. 검색 결과 요약

5. 최종 답변 생성

이 전체를 하나의 로그 문자열로 저장하면 나중에 분석하기 어렵습니다.

대신 실행 단계를 trace로 보고, 각 단계를 span으로 나눠야 합니다.

운영 PoC에서 최소한 잡아야 할 구조는 다음과 같습니다.

```markdown

trace: 사용자 요청 1건

• span: agent operation
• attribute: gen_ai.operation.name
• attribute: model
• attribute: latency
• attribute: error 여부
• span: tool call
• attribute: gen_ai.tool.name
• attribute: tool call 성공/실패
• attribute: latency
• event: 입력/출력 메시지 관련 이벤트
• 단, 전문 저장 여부는 보안 정책에 따라 제한

```

여기서 핵심은 tool call을 별도로 볼 수 있어야 한다는 점입니다.

에이전트 장애는 모델 답변 자체보다 도구 호출에서 발생하는 경우가 많습니다.

• 권한이 없는 문서에 접근하려고 한 경우
• 외부 API가 실패한 경우
• tool 호출 결과가 비어 있는 경우
• 검색 결과가 기대한 범위와 다른 경우
• 모델이 잘못된 도구를 선택한 경우

이런 문제를 찾으려면 gen_ai.tool.name처럼 도구 단위로 추적할 수 있는 속성이 필요합니다.

단순히 “에이전트 실패”라고만 남기면 복구가 어렵습니다.

“어떤 operation에서, 어떤 tool을 호출했고, 어느 단계에서 실패했는가”까지 남겨야 다음 조치를 정할 수 있습니다.

3. 운영 승격 전에는 “검증 쿼리”로 로그 품질을 확인해야 합니다

관찰성은 설치했다고 끝나는 일이 아닙니다.

PoC를 운영으로 넘기기 전에는 telemetry가 실제로 분석 가능한 형태인지 검증해야 합니다.

이때 먼저 필요한 산출물은 대시보드가 아니라 “검증 질문 목록”입니다.

예를 들어 다음 질문에 답할 수 있어야 합니다.

• 특정 gen_ai.operation.name 기준으로 실행 건수를 볼 수 있는가?
• operation별 평균 지연시간을 볼 수 있는가?
• tool call 실패만 따로 필터링할 수 있는가?
• 특정 tool에서 반복적으로 오류가 발생하는지 볼 수 있는가?
• 모델 호출 단계와 tool 호출 단계의 지연을 분리해서 볼 수 있는가?
• 실패한 실행의 trace를 따라가며 원인을 확인할 수 있는가?
• 입력·출력 전문을 저장하지 않아도 장애 분석에 필요한 최소 정보가 남는가?

이 질문에 답하지 못한다면, 아직 운영 관찰성 기준이 잡힌 것이 아닙니다.

특히 비용 분석까지 고려한다면 model, operation, latency, error를 함께 볼 수 있어야 합니다. 리서치에서 제시된 관점처럼 에이전트 로그는 프롬프트 전문 저장소가 아니라 operation/tool/model/latency/error 중심의 표준 telemetry로 설계하는 것이 좋습니다.

다만 현재 GenAI semantic convention의 세부 안정성과 APM 벤더별 지원 범위는 확인이 필요합니다.

따라서 운영 도입 전에는 다음을 별도로 확인해야 합니다.

• 사용 중인 APM이 OpenTelemetry GenAI 속성을 어느 범위까지 지원하는가
• gen_ai.operation.name 등 주요 속성이 검색·필터·대시보드에서 활용 가능한가
• tool call 관련 속성이 벤더 UI에서 보이는가
• 입출력 메시지 저장 정책을 끌 수 있는가
• 민감정보 마스킹 또는 샘플링 정책을 적용할 수 있는가

바로 적용하는 체크리스트 또는 비교 기준

에이전트 PoC를 운영으로 넘기기 전, 아래 체크리스트를 먼저 확인해볼 수 있습니다.

1. 관찰성 스키마

• [ ] 에이전트 실행 1건을 trace로 볼 수 있다.
• [ ] 주요 작업 단위가 operation으로 구분된다.
• [ ] gen_ai.operation.name에 해당하는 작업 이름을 남긴다.
• [ ] 모델 호출과 tool call을 같은 로그 문자열이 아니라 별도 단계로 볼 수 있다.
• [ ] gen_ai.tool.name처럼 도구 이름을 추적할 수 있다.
• [ ] latency와 error를 operation/tool 단위로 볼 수 있다.

2. 보안·권한 기준

• [ ] 프롬프트 전문을 기본 저장하지 않는다.
• [ ] 출력 전문 저장 여부를 별도 정책으로 정한다.
• [ ] PII 마스킹 기준을 정한다.
• [ ] tool call 결과 전문을 어디까지 보존할지 정한다.
• [ ] 운영자, 개발자, 감사 담당자의 로그 접근 권한을 분리한다.
• [ ] 민감한 내부 문서나 고객 데이터가 telemetry에 그대로 남지 않도록 한다.

3. 운영 검증 질문

• [ ] 특정 operation의 실패율을 볼 수 있는가?
• [ ] 특정 tool call의 실패만 필터링할 수 있는가?
• [ ] 느린 실행이 모델 때문인지 tool 때문인지 구분할 수 있는가?
• [ ] 실패 trace를 보고 재현 가능한 테스트 케이스로 옮길 수 있는가?
• [ ] 비용 증가 원인을 operation/model/tool 단위로 추적할 수 있는가?
• [ ] APM 벤더가 OpenTelemetry GenAI 속성을 실제로 지원하는지 확인했는가?

4. PoC 운영 승격 기준

운영으로 넘기기 전 최소 기준은 다음처럼 잡는 것이 좋습니다.

기준	통과 조건
추적성	실행 1건의 trace를 끝까지 따라갈 수 있다
도구 관찰성	어떤 tool이 언제 호출됐는지 볼 수 있다
장애 분석	실패 지점이 model/tool/후처리 중 어디인지 구분된다
보안	입력·출력 전문 저장 정책과 마스킹 기준이 있다
벤더 확인	사용 중인 APM에서 GenAI 속성 지원 범위를 확인했다
재발 방지	실패 trace를 평가 데이터나 회귀 테스트로 전환할 수 있다

마무리 + 생각해볼 질문 1개

에이전트 운영의 출발점은 더 똑똑한 프롬프트가 아닙니다.

실패했을 때 무엇이 일어났는지 설명할 수 있는 관찰성입니다.

OpenTelemetry GenAI semantic conventions는 에이전트 실행을 표준 telemetry로 바라보게 해줍니다.

다만 GenAI convention의 세부 안정성과 벤더별 지원 범위는 확인이 필요합니다. 처음부터 특정 벤더 대시보드에 맞춰 설계하기보다 operation/tool/model/latency/error 중심의 최소 스키마를 먼저 정하는 편이 안전합니다.

에이전트 로그를 프롬프트 전문 저장소로 만들지 마세요.

운영에서 필요한 것은 “모든 대화의 보관”이 아니라 “문제가 생겼을 때 원인을 찾고 다시 재현할 수 있는 구조”입니다.

생각해볼 질문은 하나입니다.

우리 에이전트 PoC는 실패했을 때, “무슨 답을 했는지”가 아니라 “어느 operation과 tool에서 왜 실패했는지”를 설명할 수 있나요?