AX LABS
← 블로그 AX Ops 방법론

트레이스는 켜고 내용은 숨겨라

에이전트 운영의 기본값은 수집과 마스킹이다

AX LABS 8분 읽기

AI agent를 운영에 올린 팀이 가장 먼저 부딪히는 장면은 비슷하다. 사용자는 “아까는 됐는데 지금은 왜 안 되냐”고 묻고, 개발팀은 모델 호출 로그와 앱 로그를 따로 뒤진다. tool call은 있었지만 어떤 args가 들어갔는지, prompt가 바뀌었는지, reasoning token이 급증했는지 한 화면에서 보이지 않는다. 그래서 원문을 모두 켜자는 말이 나온다. 그 순간 운영 관측성은 보안 사고 후보가 된다.

기본값은 수집 ON, 원문 OFF다

Default-on trace collector의 목적은 모든 내용을 모으는 것이 아니다. 모든 실행 경로를 빠짐없이 남기되, 원문 내용은 기본적으로 숨기는 것이다.

OpenTelemetry의 2026년 GenAI observability 글은 GenAI semantic conventions가 모델, token count, tool invocation을 표준화한다고 설명한다. 동시에 prompt content와 tool arguments는 민감정보를 담을 수 있어 기본 수집 대상이 아니라고 못 박는다. content capture를 켜면 prompt, system prompt, tool schema, tool arguments, tool results가 span attribute로 채워진다. (opentelemetry.io)

이 원칙은 현장 설계의 출발점이다.

trace는 항상 켠다. 원문은 항상 의심한다. 운영에 필요한 것은 재현 가능한 구조이지, 무방비 원문 저장이 아니다.

SDK 기본값은 서로 다르다. Claude Code 문서는 user prompt text, tool input details, tool content가 span에서 기본 redaction된다고 설명한다. 반면 OpenAI Agents SDK 문서는 tracing이 기본 활성화되고, generation/function span의 입력·출력이 민감할 수 있으며 trace_include_sensitive_data로 캡처를 끌 수 있다고 설명한다. 그래서 AX Ops에서는 SDK 기본값을 믿지 않고 collector 정책을 별도로 둔다. (code.claude.com)

Span은 하나지만 보관함은 네 개다

GenAI span은 운영자가 보는 단위다. 그러나 저장 정책은 네 갈래로 나뉜다.

데이터 수집 기본값 처리 원칙
실행 메타데이터 ON model, latency, token, status, retry, workflow id는 그대로 보관
prompt·message OFF hash, 길이, template id, redacted preview만 남김
tool args·result 제한 ON schema 기반 필드 allow-list, 값은 mask·drop·HMAC
reasoning·PII OFF reasoning은 count·summary·reference만, PII는 저장 전 제거

OpenTelemetry attribute registry에는 gen_ai.input.messages, gen_ai.output.messages, gen_ai.tool.call.arguments, gen_ai.tool.call.result, gen_ai.usage.reasoning.output_tokens 같은 필드가 잡혀 있다. 특히 tool arguments와 result는 민감정보 경고가 붙어 있고, 가능한 경우 구조화된 object로 다루도록 되어 있다. (opentelemetry.io)

구조화가 중요하다. JSON string으로 통째로 저장하면 마스킹은 정규식 싸움이 된다. object로 풀면 customer_id는 HMAC, account_no는 drop, region은 keep 같은 정책을 필드 단위로 걸 수 있다.

Collector는 redaction 앞에 분류기를 둔다

OTel Collector에는 attribute, filter, redaction, transform processor가 있다. 공식 문서는 민감 데이터 처리를 위해 attribute 수정, span filtering, allow-list 기반 redaction, regex transform을 조합하라고 안내한다. processor는 pipeline 안에서 telemetry를 변환·필터·보강하는 위치다. (opentelemetry.io)

하지만 GenAI 운영에서는 범용 redaction만으로 부족하다. 순서는 이렇게 잡는다.

  1. GenAI classifier: span에서 gen_ai.*, MCP, tool namespace를 식별한다.
  2. content splitter: prompt, tool args, reasoning, PII 후보를 별도 envelope로 분리한다.
  3. schema masker: tool별 allow-list와 field policy를 적용한다.
  4. redaction processor: 남은 attribute를 fail-closed로 한 번 더 걸러낸다.
  5. dual exporter: 운영 backend에는 masked trace, 제한 vault에는 승인된 원문 조각만 보낸다.

Redaction processor README는 allowed list에 없는 attribute를 삭제하고, blocked value에 맞는 값은 mask한다고 설명한다. allowed list가 비어 있으면 아무 attribute도 허용하지 않는 fail-closed 동작도 명시한다. 이 성질 때문에 마지막 방어선으로 적합하다. (github.com)

reasoning은 디버깅 데이터가 아니다

reasoning은 prompt보다 더 위험하다. 고객 데이터, 내부 정책, tool 결과, 모델의 중간 판단이 섞인다. 운영자는 reasoning 원문이 아니라 “왜 느려졌는가, 왜 tool을 반복했는가, 어디서 handoff됐는가”를 알아야 한다.

그래서 reasoning은 세 값만 남긴다. reasoning.output_tokens, provider가 제공한 안전한 summary, 그리고 접근 통제된 원문 reference다. OpenAI의 2026년 공식 가이드는 Responses API에서 reasoning items가 turn과 tool call을 가로질러 유지될 수 있고, ZDR 구성에서는 encrypted reasoning items를 넘기는 방식을 언급한다. 이 흐름은 reasoning을 일반 로그처럼 저장하지 말라는 신호다. (cdn.openai.com)

Default-on trace collector는 “더 많이 저장하는 장치”가 아니다. 운영 복기를 가능하게 하면서도 prompt, tool args, reasoning, PII의 보관 책임을 분리하는 장치다. 이 설계를 먼저 하지 않으면 agent rollout은 관측성과 보안 사이에서 계속 흔들린다.

참고는 운영 설계에 남겨라

AX Ops에서는 이 collector 정책을 PoC 뒤 보안 검토가 아니라 agent 운영 설계의 첫 산출물로 둔다. trace를 켜고, 원문을 나누고, 마스킹을 기본값으로 고정하는 일부터 시작해야 한다. 다음 agent 운영 설계는 AX Ops 방법론 →에서 이어진다.