# 감사 기록과 관측
> **이 장에서 배우는 것**
> 에이전트 시스템에서 무엇을 기록해야 하는지, 왜 일반 서버 로그로는 부족한지,
> 그리고 기록하면 안 되는 것.
## 답할 수 없으면 배포한 게 아닙니다
배포 후 어느 날 이런 질문이 옵니다.
```
"그 메일 왜 나갔습니까?"
"이 숫자 어디서 나온 겁니까?"
"승인은 누가 했습니까?"
"지난달에 왜 갑자기 비용이 두 배가 됐습니까?"
```
네 질문 모두 **기록이 없으면 답할 수 없습니다.** 그리고 답을 못 하면 그
시스템은 다음 심의에서 내려갑니다.
## 네 가지 이유
| 이유 | 무엇이 필요한가 |
|---|---|
| **규제** | [AI 기본법](/guide/ax-compliance) 고영향 AI는 확인 문서를 **5년 보관** |
| **사고 조사** | 엉뚱한 지시가 어느 문서를 타고 들어왔나 |
| **개선** | 어디서 자주 실패하나, 재작업은 왜 생기나 |
| **비용** | 어느 작업이 사용량을 먹나 |
**첫 줄이 특히 오해가 많습니다.** 조치를 했다는 사실이 아니라 **조치를 확인한
문서**를 5년간 보관해야 합니다. 그건 사후에 만들 수 없습니다.
## 일반 로그로는 부족합니다
기존 서버 로그는 **요청 하나 = 줄 하나**입니다. 에이전트는 그렇지 않습니다.
```
사용자 요청 1건
├ 모델 호출 (계획 세우기)
├ 도구: 파일검색 → 결과 12건
├ 모델 호출 (어느 파일 볼지 판단)
├ 도구: 파일읽기 ×3
├ 모델 호출 (초안 작성)
├ 사람 승인 대기 → 승인
└ 도구: 메일발송 → 완료
```
**한 줄로는 이 구조가 안 보입니다.** 필요한 건 로그가 아니라 **트리 형태의
추적 기록(트레이스)**입니다. "왜 그랬나"는 이 트리를 따라가야만 답이 나옵니다.
업계는 이 부분에서 **OpenTelemetry의 GenAI 시맨틱 컨벤션**으로 수렴하고
있습니다. 모델 호출·에이전트 실행·도구 호출·세션 지표를 표준 속성으로 남기는
규약이고, 2026년 현재 주요 코딩 에이전트들이 이 형식으로 기록을 내보냅니다.
**직접 만들기 전에 이 표준을 먼저 보세요.** 나중에 도구를 갈아탈 때 기록이
살아남습니다.
## 남길 것
```
□ 누가 무엇을 시켰나 사용자 · 워크스페이스 · 요청 원문
□ 무엇을 근거로 삼았나 참조한 문서 · 검색 결과의 출처
□ 어떤 도구를 어떻게 불렀나 도구 이름 · 인자 · 결과 요약 · 소요 시간
□ 사람이 무엇을 판단했나 승인/거부 · 누가 · 언제 · 거부 사유
□ 무엇이 나갔나 외부로 나간 동작과 대상
□ 얼마가 들었나 모델별 토큰 · 호출 수
□ 어떻게 끝났나 성공/실패/중단 · 오류 내용
```
**네 번째 줄을 눈여겨보세요.** 승인 기록은 규제 대응과 사고 조사 양쪽에서
가장 먼저 요구되는 항목인데, 화면에만 있고 저장은 안 하는 경우가 흔합니다.
## 남기면 안 되는 것
기록을 늘리는 것만 생각하면 여기서 사고가 납니다.
| 절대 | 왜 |
|---|---|
| API 키·토큰·비밀번호 | 로그는 접근 권한이 넓습니다. 유출 경로 1순위 |
| 프롬프트 원문 속 개인정보 | 보관 근거와 기간이 필요합니다 |
| 고객 문서 전문 | 요약과 식별자만. 원문은 원래 있던 곳에 |
> **보존 기간이 서로 충돌합니다.** 규제는 "5년 보관"을 요구하고 개인정보보호법은
> "최소 보관"을 요구합니다. 답은 **분리**입니다. 감사에 필요한 것(누가·언제·무엇을
> 승인)은 5년, 내용물(원문·개인정보)은 짧게. 처음부터 두 저장소로 나누세요.
## 언제 붙이나
```mermaid
graph TD
A["Phase 3 — POC"] -->|"트레이스 켜기"| B["어디서 실패하는지 보임"]
B --> C["Phase 4 — 배포"]
C -->|"보존·접근 통제 설계"| D["운영"]
D --> E["사고 조사 · 규제 대응 · 비용 분석"]
```
**POC 때부터 켜는 게 맞습니다.** 배포 후에 붙이면 "왜 POC에서는 잘 됐는데"에
답할 수 없습니다. 그리고 POC 단계의 트레이스가 실패 유형을 보여줘서
품질 검사용 사례집(평가 데이터셋)의 재료가 됩니다.
## 제품에서는
| 남는 것 | 어디서 |
|---|---|
| 워크스페이스별 사용량과 크레딧 소비 | [사용량과 크레딧](/guide/cn-usage) |
| 스레드에 남는 도구 호출과 결과 | [스레드](/guide/cn-thread) |
| 예약·큐 실행 이력 | [큐와 예약](/guide/cn-queue) |
| 시스템 단위 실행 기록 | [시스템 관리](/guide/cn-systems-manage) |
## 자주 하는 오해
### "모델이 왜 그렇게 판단했는지도 기록되나요?"
**아닙니다.** 남는 것은 **무엇을 보고 무엇을 했는지**이지 내부 사고 과정이
아닙니다. 그래서 "왜"에 대한 답은 항상 **입력과 행동의 재구성**입니다. 다행히
규제가 요구하는 설명 의무도 대개 이 수준입니다 — 어떤 자료로 어떤 절차를 거쳐
어떤 결론에 이르렀는지.
### "다 남기면 저장 비용이 크지 않나요?"
**전문(全文)을 다 남기려니 큽니다.** 도구 결과는 요약과 식별자만 남기고 원문은
원래 위치를 가리키면 크기가 한 자릿수 퍼센트로 떨어집니다. 그리고 앞서 말한
대로 원문 보관은 개인정보 측면에서도 짐입니다.
---
## 확인
**1. 일반 서버 로그로 에이전트를 추적할 수 없는 이유는?**
답
**요청 하나가 여러 번의 모델 호출과 도구 호출로 갈라지기 때문**입니다. 한 줄
로그로는 그 구조가 안 보입니다. "왜 그랬나"는 트리 형태의 트레이스를 따라가야
답이 나옵니다.
**2. 5년 보관 요구와 개인정보 최소보관 원칙은 어떻게 양립합니까?**
답
**저장소를 분리합니다.** 감사에 필요한 항목(누가·언제·무엇을 승인했나)은 5년,
내용물(원문·개인정보)은 짧게 보관합니다. 처음부터 두 개로 나누어 설계해야
나중에 분리할 수 있습니다.
**3. 기록을 POC 단계부터 켜야 하는 이유는?**
답
**배포 후에 붙이면 "POC에서는 왜 잘 됐나"에 답할 수 없기 때문**입니다. 또한 POC
단계의 트레이스가 실패 유형을 드러내서 평가 데이터셋의 재료가 됩니다.
---
기술과 절차는 갖췄습니다. 마지막은 사람입니다 →
[변화관리](/guide/ax-change-management)