업무 로그와 모델 로그를 구분해야 한다
두 종류의 로그는 봉사 대상이 근본적으로 다르다. 업무 로그는 프로세스를 기록하고(시스템 트러블슈팅용), 모델 로그는 의미를 기록한다(AI 행위 분석용). 둘의 민감도와 사용 장면은 완전히 다르다.
상용에서의 방식은 계층 관리 + 등급별 저장이다: 업무 로그는 일반 플랫폼에 넣어 장기 보존하고, 모델 로그는 별도로 암호화·마스킹하고 접근을 제한하며 엄격하게 보존한다. 그리고 **request_id**로 양쪽을 연결한다.
두 종류의 로그가 각각 무엇에 관심을 두는가
| 업무 로그의 관심사 | 모델 로그의 관심사 |
|---|
| 사용자가 누구인가 | Prompt와 입출력 |
| 어떤 버튼을 눌렀는가 | 도구 호출 |
| 인터페이스가 성공했는가 | 검색 증거 |
| 주문이나 작업 상태가 어떻게 변했는가 | 안전 차단 |
섞었을 때의 두 가지 문제
- 트러블슈팅 효율 저하 — 엔지니어는 인터페이스 에러를 보고 싶은데 대량의 Prompt와 답변에 파묻힌다
- 컴플라이언스 리스크 상승 — 모델 입력에 프라이버시, 계약, 고객 자료가 있을 수 있어 일반 업무 로그에 함부로 나타나면 안 되며 매우 현실적인 권한 문제를 낳는다
등급별 저장
| 업무 로그 | 모델 로그 |
|---|
| 목적지 | 일반 로그 플랫폼에 진입 | 고보안 등급 저장소 |
| 라벨 | 일반 검색, 장기 보존 | 독립 암호화, 데이터 마스킹, 접근 제한, 엄격한 보존 |
| 요점 | 보존 기간이 비교적 김 | 별도 암호화·마스킹·접근 제한, 그리고 더 엄격한 보존 정책 설정 |
정리
대모델 애플리케이션은 업무 로그와 모델 로그를 구분해야 한다. 용도, 민감 등급, 보존 주기, 접근 권한이 다르기 때문이다. request_id로 연결하는 것이지, 모든 내용을 하나의 로그에 밀어 넣는 것이 아니다.
핵심 통찰
- 로그 계층화의 근거는 「독자가 다르다」이지 「데이터가 많다」가 아니다 — 「로그가 너무 많다」는 현상일 뿐이고, 진짜 경계선은 소비자다. SRE/백엔드 엔지니어는 업무 로그를 읽고, 알고리즘/리스크/컴플라이언스는 모델 로그를 읽는다. 소비자가 다른 모든 데이터 흐름은 물리적 분리를 고려해야 한다.
- 프로세스 vs 의미가 이 문제의 핵심 이분법이다 — 업무 로그의 필드는 열거 가능한 구조화 이벤트(누가, 무엇을 눌렀나, 성공했나)이고, 모델 로그의 필드는 자유 텍스트 의미(Prompt, 출력, 검색 증거)다. 전자는 색인과 집계에 적합하고 후자는 부피가 크고 민감하며 색인이 어렵다. 이것들을 같은 저장소에 밀어 넣는 것은 전혀 다른 두 종류의 부하가 하나의 색인 전략을 공유하게 하는 것이다.
- 컴플라이언스 리스크가 성능 문제보다 치명적이다 — 트러블슈팅 효율 저하는 경험 문제지만, 프라이버시/계약/고객 자료가 일반 로그 플랫폼으로 흘러드는 것은 법률 문제다. 많은 사람이 접근할 수 있는 일반 로그 플랫폼은 태생적으로 「최소 권한」 원칙과 충돌한다. 분리의 제1동기는 컴플라이언스여야지 성능이 아니다.
- 「민감 등급」이 「보존 주기」를 결정한다 — 이 두 차원은 독립적이지 않다. 민감할수록 보존이 짧아야 한다. 업무 로그를 장기 보존하는 것은 추적을 위해서고, 모델 로그를 엄격히 보존하는 것은 노출 창구를 제한하기 위해서다. 보존 정책 설계 시 둘을 묶어서 고려해야 한다.
request_id가 분리 후 다시 꿰매는 유일한 증표다 — 계층화의 대가는 트러블슈팅 시 시스템을 넘나들어야 한다는 것이고, request_id가 그 대가를 최소로 낮추는 실이다. 이것은 「분리 저장, 논리적 연결」이라는 범용 패턴이다(같은 부류로 trace_id, session_id가 있다).- 연결 키는 요청 입구에서 생성해 전 사슬로 전파해야 한다 — request_id가 중간에 생성되거나 시스템마다 각자 생성하면, 분리한 뒤 다시는 이어 붙일 수 없다. 이 필드는 포맷보다 생성 위치가 훨씬 중요하다.
- 마스킹은 쓰기 전에 일어나야지 조회 시에 하면 안 된다 — 「데이터 마스킹」이 모델 로그 저장 정책의 일부라는 것은, 원문을 쓴 뒤 조회 측에서 가리는 방식으로는 디스크에 평문이 남는다는 뜻이다.
- 작업의 순서 자체가 공학적 판단이다 — 실제 프로젝트에서 마스킹(지혈, 이미 발생 중인 리스크의 확대 방지)이 보통 권한 격리(입구 좁히기)보다 우선하고, 품질 분석 대시보드는 가치 발굴에 속하므로 마지막에 해도 된다. 컴플라이언스 작업의 순서 원칙은 이렇다: 먼저 새로운 노출이 생기는 것을 멈추고, 그다음 기존 노출면을 좁힌다.
엔지니어링 실전 Tips
- request_id를 양쪽 로그의 색인 필드에 넣을 것: 그것이 유일한 join key이며, 일반 필드로만 적재하면 트러블슈팅 시 풀 스캔이 매우 고통스럽다.
- 업무 로그에 「하는 김에」 Prompt 조각을 출력하지 말 것: 계층화 방안의 가장 흔한 파괴 지점이다. 디버그 로그 한 줄로 모든 격리 노력이 무효화될 수 있으므로, 상용 전에 정적 검사나 샘플링 감사가 있어야 한다.
- 모델 로그를 용도별로 한 겹 더 세분할 것: Prompt/출력(최고 민감), 도구 호출 파라미터(중간), 검색 증거(지식베이스 출처에 따라), 안전 차단 결과(비교적 완화). 일률적으로 「고보안 등급」으로 만들면 품질 분석이 한 발짝도 못 나간다.
- 마스킹 시 가역 해시를 남겨 연결을 지원할 것: 고객명을 통째로 가리면 고객 차원의 품질 분석이 불가능해진다. 안정적인 해시로 바꾸면 마스킹하면서도 그룹핑 가능성을 유지한다.
- 보존 주기는 컴플라이언스 요구와 정렬한 뒤 더 짧은 값을 취할 것: 모델 로그의 엄격한 보존 일수는 감으로 정하는 것이 아니라 적용되는 프라이버시 법규와 내부 데이터 등급 제도를 참조해야 한다.
- 모델 로그 접근에도 감사를 붙일 것: 접근 제한은 출입문일 뿐이고, 누가 언제 어떤 레코드를 봤는지도 똑같이 흔적을 남겨야 컴플라이언스 검사 시 자증할 수 있다.
- 품질 분석 대시보드는 되도록 마스킹된 파생 지표를 소비할 것: 명중률, 거부율, 도구 실패율 같은 집계 지표는 원문에 접근할 필요가 없으므로 저밀도 구역에서 처리할 수 있다.
- 업무 로그의 「장기 보존」에도 상한을 둘 것: 「보존 기간이 비교적 길다」는 것이지 영구가 아니다. 상한 없는 보존도 똑같이 컴플라이언스 부채다.