생성형 AI 관측성 설계: 프롬프트를 남기지 않고 장애를 찾는 로그 기준

장애를 찾겠다고 프롬프트와 답변을 전부 로그에 남겼다가 고객 문서가 로그 시스템에 한 번 더 쌓이는 경우가 있습니다. 운영 DB는 접근이 엄격한데 로그 검색 권한은 개발 조직 전체에 열려 있다면 보호 경계가 오히려 약해집니다.

반대쪽도 문제다. “민감하니 아무것도 기록하지 않는다”로 정하면 어느 모델 버전에서 오류가 늘었는지, 도구가 실제로 실행됐는지, 재시도가 비용을 얼마나 만들었는지 확인할 수 없습니다.

생성형 AI 관측성은 원문을 많이 모으는 일이 아니라 문제를 재구성할 최소 정보를 정하는 일입니다.

먼저 답할 운영 질문을 적는다

수집 필드는 대시보드 모양이 아니라 질문에서 나와야 합니다.

어느 기능과 모델에서 시간 초과가 늘었나?
입력이 길어진 원인은 검색 문서인가, 도구 명세인가?
구조화 출력 실패 뒤 몇 번 재시도했나?
에이전트가 어떤 정책 판정을 받고 도구를 실행했나?
특정 사고 시각에 영향을 받은 요청과 고객 범위는 어디까지인가?
삭제 요청이 원문 저장소와 진단 표본에도 반영됐나?

이 질문은 대부분 프롬프트 원문 없이 답할 수 있습니다. 필요한 것은 요청을 잇는 ID, 실행 버전, 수량, 상태와 판정 결과다.

OpenTelemetry 생성형 AI 의미 규약은 입력·출력 메시지, 시스템 지침, 검색 질의와 도구 인자·결과에 민감정보가 포함될 수 있다고 경고합니다. 표준에 필드가 있다는 사실이 곧 전부 수집하라는 뜻은 아닙니다. OpenTelemetry GenAI Attributes

로그 필드를 세 등급으로 나눈다

A. 상시 수집할 운영 메타데이터

원문을 담지 않는 수치와 식별자다. 정상 요청에도 남겨야 기준선을 만들 수 있습니다.

영역	권장 필드	용도
요청	`trace_id`, `request_id`, `feature`, `environment`	한 요청의 경로와 소유 기능 식별
모델	`provider`, `requested_model`, `resolved_model`, `model_config_version`	모델·설정 변경과 회귀 연결
사용량	입력·출력·캐시 토큰, 검색 문서 수, 도구 호출 수	비용과 비정상 증폭 확인
성능	큐 대기, 첫 토큰, 전체 지연, 재시도 횟수	병목과 공급자 장애 구분
결과	상태 코드, 내부 오류 분류, 파싱 성공, 거부 분류	제품 계약 실패 집계
정책	가드레일 버전, 허용·차단·승인 필요, 규칙 ID	안전 경계와 실행 이유 재구성

사용자와 테넌트 식별자가 필요하면 원본 계정 ID 대신 접근이 제한된 가명 키를 고려합니다. 해시만 붙였다고 항상 익명이 되는 것은 아닙니다. 입력 범위가 작으면 사전 대입으로 다시 알아낼 수 있으니 키가 있는 HMAC이나 별도 매핑 저장소처럼 위협 모델에 맞는 방식을 정해야 합니다.

B. 조건부로만 남길 진단 표본

오류 원인을 찾으려면 일부 내용이 필요할 때가 있습니다. 자동 전수 수집 대신 다음 조건을 붙입니다.

사용 목적이 품질 분석 또는 특정 사고 조사로 정해져 있다.
서비스 데이터 정책과 고객 계약이 허용한다.
비밀값·직접 식별자·불필요한 문서를 먼저 제거한다.
표본 비율, 접근 역할, 보존 만료와 삭제 책임자가 있다.
원문 열람과 내보내기가 별도 감사 로그에 남는다.

표본은 “전체 요청의 1%”보다 위험별로 뽑는 편이 유용합니다. 구조화 출력 실패, 정책 차단, 새 모델 카나리처럼 분석 질문이 있는 집단을 선택하고 정상 요청은 짧은 대조 표본만 둡니다.

C. 로그에서 금지할 값

API 키, 비밀번호, 세션 토큰과 인증 헤더
주민등록번호, 카드 전체 번호와 복구 코드
업로드 파일 전체와 검색 원문 전체
도구 호출에 포함된 인증 자격 증명
고객이 삭제한 데이터를 되살릴 수 있는 원문 복사본

마스킹은 수집 뒤 배치 작업으로 미루지 않습니다. 애플리케이션이나 수집기에서 외부 로그 저장소로 보내기 전에 제거합니다. 예외 처리기가 요청 객체 전체를 직렬화하지 않는지도 따로 시험해야 한다.

한 요청을 잇는 최소 이벤트 구조

에이전트는 모델 호출과 도구 실행이 여러 번 이어집니다. 각 이벤트를 독립 로그로 남기면 순서를 재구성하기 어렵습니다.

{
  "trace_id": "tr_01J...",
  "span_id": "sp_07",
  "parent_span_id": "sp_03",
  "event_type": "tool.result",
  "feature": "order_support",
  "agent_version": "2026-08-23.2",
  "resolved_model": "provider-model-version",
  "tool_name": "order.read",
  "policy_decision": "allow",
  "argument_schema_valid": true,
  "result_class": "success",
  "result_size_bytes": 1842,
  "duration_ms": 214,
  "content_captured": false
}

도구 인자 전체 대신 스키마 통과 여부, 대상 종류, 결과 크기와 상태를 남깁니다. 결제 금액처럼 사고 조사에 꼭 필요한 값은 별도 허용 목록과 더 좁은 접근 역할을 둘 수 있습니다. AI 에이전트의 승인·감사 구조는 AI 에이전트 권한 설계 가이드와 함께 설계하는 편이 안전합니다.

SDK 기본값을 우리 정책으로 착각하지 않는다

OpenAI Agents SDK tracing은 모델 생성, 도구 호출, 핸드오프와 가드레일 실행을 추적합니다. 공식 문서는 기본 추적에 민감한 입력·출력이 포함될 수 있으며 trace_include_sensitive_data 설정으로 제외할 수 있다고 안내합니다. Zero Data Retention 조건에서는 기본 추적 기능을 사용할 수 없다는 제한도 명시돼 있습니다. OpenAI Agents SDK Tracing

SDK를 도입할 때는 다음을 코드 리뷰 항목으로 둡니다.

추적이 기본으로 켜지는 환경은 어디인가.
프롬프트, 응답과 함수 인자가 기본 필드에 들어가는가.
민감정보 제외 설정이 모든 실행 경로에 적용되는가.
추적 데이터가 어느 계정·리전·보존 정책에 저장되는가.
ZDR이나 내부 규정과 충돌하면 자체 exporter로 바꿀 수 있는가.

애플리케이션 로그도 마찬가지다. 공식 SDK 설정은 모델 입력과 출력의 로그 기록을 별도로 제어할 수 있게 합니다. 개발 환경에서 잠시 켠 디버그 로그가 운영 배포에 남지 않도록 환경별 시험이 필요합니다. OpenAI Agents SDK Configuration

프롬프트 없이도 만들 수 있는 대시보드

신뢰성 화면

기능·모델별 성공률과 오류 분류
p50, p95 전체 지연과 첫 토큰 시간
파싱 실패와 도구 실행 실패 비율
재시도, 공급자 429·5xx와 회로 차단 상태

품질 화면

고정 평가 세트의 통과율
검색 근거 포함률과 인용 검증률
사람 반려·수정 비율
정책 차단과 거짓 차단 표본

비용 화면

기능·팀·업무 단위별 토큰과 추정 원가
재시도로 낭비된 비용
캐시 사용률과 긴 입력 분포
예산 대비 일별 소진 속도

품질은 운영 로그의 대리 지표만으로 확정하기 어렵습니다. 응답 길이가 짧아졌다고 정확성이 좋아진 것은 아니다. 고정 평가와 사람 검토를 별도 표본으로 연결하세요. 비용 필드 설계는 LLM API 비용 예산 가이드에서 더 자세히 다룹니다.

보존 기간은 데이터 종류별로 다르게 둔다

모든 추적 데이터를 1년 보존하거나 전부 7일 뒤 지우는 식의 단일 정책은 운영과 개인정보 양쪽에 맞지 않을 수 있습니다.

데이터	보존 판단 예시
집계 지표	장기 추세가 필요하므로 원문 없이 비교적 길게 보존
요청 메타데이터	사고 탐지·청구 대조 기간에 맞춤
가명화된 상세 추적	장애 조사와 회귀 분석에 필요한 짧은 기간
진단 원문 표본	목적이 끝나는 즉시 삭제하도록 가장 짧게 설정
보안 감사 이벤트	법적·계약상 요구와 조사 필요를 별도 검토

보존표에는 데이터 소유자, 저장 위치, 접근 역할, 삭제 방식, 법적 보류 예외를 같이 씁니다. 삭제 작업이 성공했다고 표시하는 것만으로 부족합니다. 검색 색인, 내보낸 파일과 분석 샌드박스까지 표본이 복제됐는지 확인해야 한다.

사고 조사 때 원문 수집을 임시로 늘리는 절차

평소에는 메타데이터만 남기다가 재현하기 어려운 장애가 생길 수 있습니다. 이때 개발자가 임의로 전체 프롬프트 로그를 켜지 않도록 사전 절차를 둡니다.

조사할 기능, 오류 유형과 시간 범위를 티켓에 적습니다.
개인정보·보안 책임자가 수집 필드와 표본 크기를 승인합니다.
특정 테넌트 또는 시험 계정처럼 범위를 좁힙니다.
자동 종료 시각과 암호화된 저장 위치를 설정합니다.
열람자와 내보내기 기록을 남깁니다.
조사 종료 뒤 원문 삭제와 설정 복구를 확인합니다.

사고 기록과 책임 분담은 생성형 AI 사고 대응·레드팀 가이드에서 이어서 점검할 수 있습니다.

배포 전 확인표

프롬프트와 응답 없이도 오류 요청을 trace_id로 찾을 수 있다.
요청 모델과 실제 해석된 모델 버전을 구분한다.
토큰, 지연, 재시도, 도구 호출과 정책 판정을 기록한다.
인증값과 업로드 원문은 exporter 전에 제거한다.
SDK의 민감정보 수집 기본값을 환경별로 시험했다.
원문 표본에는 승인, 만료, 접근 감사가 붙는다.
고객 삭제 요청이 진단 표본과 내보내기에도 전달된다.
로그 저장소 침해를 가정한 영향 범위를 검토했다.

NIST 생성형 AI 프로필은 배포 뒤 모니터링, 사고 기록, 개인정보 위험과 제3자 요소를 함께 관리하도록 권고합니다. 자발적 프레임워크이므로 적용 범위와 산업 규정은 조직이 별도로 확인해야 합니다. NIST AI 600-1

첫 단계에서는 프롬프트 저장 기능을 켜기보다 상시 메타데이터 15개를 정하세요. 그 정보로 해결하지 못한 실제 장애가 생겼을 때만 조건부 표본을 추가하면, 수집 목적과 위험을 설명하기 쉬워집니다.