감사 기록과 관측

이 장에서 배우는 것 에이전트 시스템에서 무엇을 기록해야 하는지, 왜 일반 서버 로그로는 부족한지, 그리고 기록하면 안 되는 것.

답할 수 없으면 배포한 게 아닙니다

배포 후 어느 날 이런 질문이 옵니다.

네 질문 모두 기록이 없으면 답할 수 없습니다. 그리고 답을 못 하면 그 시스템은 다음 심의에서 내려갑니다.

네 가지 이유

첫 줄이 특히 오해가 많습니다. 조치를 했다는 사실이 아니라 조치를 확인한 문서를 5년간 보관해야 합니다. 그건 사후에 만들 수 없습니다.

일반 로그로는 부족합니다

기존 서버 로그는 요청 하나 = 줄 하나입니다. 에이전트는 그렇지 않습니다.

한 줄로는 이 구조가 안 보입니다. 필요한 건 로그가 아니라 트리 형태의 추적 기록(트레이스)입니다. "왜 그랬나"는 이 트리를 따라가야만 답이 나옵니다.

업계는 이 부분에서 OpenTelemetry의 GenAI 시맨틱 컨벤션으로 수렴하고 있습니다. 모델 호출·에이전트 실행·도구 호출·세션 지표를 표준 속성으로 남기는 규약이고, 2026년 현재 주요 코딩 에이전트들이 이 형식으로 기록을 내보냅니다. 직접 만들기 전에 이 표준을 먼저 보세요. 나중에 도구를 갈아탈 때 기록이 살아남습니다.

남길 것

네 번째 줄을 눈여겨보세요. 승인 기록은 규제 대응과 사고 조사 양쪽에서 가장 먼저 요구되는 항목인데, 화면에만 있고 저장은 안 하는 경우가 흔합니다.

남기면 안 되는 것

기록을 늘리는 것만 생각하면 여기서 사고가 납니다.

보존 기간이 서로 충돌합니다. 규제는 "5년 보관"을 요구하고 개인정보보호법은 "최소 보관"을 요구합니다. 답은 분리입니다. 감사에 필요한 것(누가·언제·무엇을 승인)은 5년, 내용물(원문·개인정보)은 짧게. 처음부터 두 저장소로 나누세요.

언제 붙이나

graph TD
  A["Phase 3 — POC"] -->|"트레이스 켜기"| B["어디서 실패하는지 보임"]
  B --> C["Phase 4 — 배포"]
  C -->|"보존·접근 통제 설계"| D["운영"]
  D --> E["사고 조사 · 규제 대응 · 비용 분석"]

POC 때부터 켜는 게 맞습니다. 배포 후에 붙이면 "왜 POC에서는 잘 됐는데"에 답할 수 없습니다. 그리고 POC 단계의 트레이스가 실패 유형을 보여줘서 품질 검사용 사례집(평가 데이터셋)의 재료가 됩니다.

제품에서는

자주 하는 오해

"모델이 왜 그렇게 판단했는지도 기록되나요?"

아닙니다. 남는 것은 무엇을 보고 무엇을 했는지이지 내부 사고 과정이 아닙니다. 그래서 "왜"에 대한 답은 항상 입력과 행동의 재구성입니다. 다행히 규제가 요구하는 설명 의무도 대개 이 수준입니다 — 어떤 자료로 어떤 절차를 거쳐 어떤 결론에 이르렀는지.

"다 남기면 저장 비용이 크지 않나요?"

전문(全文)을 다 남기려니 큽니다. 도구 결과는 요약과 식별자만 남기고 원문은 원래 위치를 가리키면 크기가 한 자릿수 퍼센트로 떨어집니다. 그리고 앞서 말한 대로 원문 보관은 개인정보 측면에서도 짐입니다.

확인

1. 일반 서버 로그로 에이전트를 추적할 수 없는 이유는?

2. 5년 보관 요구와 개인정보 최소보관 원칙은 어떻게 양립합니까?

3. 기록을 POC 단계부터 켜야 하는 이유는?

기술과 절차는 갖췄습니다. 마지막은 사람입니다 → 변화관리