기록이 남아야 통제할 수 있다: 감사 로그(Audit Event) 설계
현재와의 관계
감사 이벤트를 JSON Schema로 고정한 판단은 현재 Core에도 남아 있다. 컴포넌트 목록은 이후 줄었다.
개발팀에서 AI 도구를 활발히 쓰기 시작하면, 보안 관리자나 플랫폼 엔지니어가 마주하는 답답함은 바로 **"불투명성"**입니다.
"대체 누가, 어떤 모델을 써서, 우리 코드베이스를 대상으로 어떤 프롬프트를 날렸는지 알 수가 없다."
사용 여부조차 블랙박스인 상태에서는 아무리 좋은 정책 가이드라인을 배포해 봤자 공염불에 불과합니다. 제로 트러스트(Zero Trust) 철학의 출발점은 **"모든 행동은 기록되고, 사후에 추적 가능해야 한다"**는 것입니다.
GoVail은 이 불투명성을 걷어내기 위해 표준화된 감사 로그(Audit Event) 시스템을 설계에 내재화했습니다.
1. 로그 포맷은 명확하고 지루해야 한다 (Schema-First)
수많은 마이크로서비스가 얽혀 있는 시스템에서 각자 자기만의 형식으로 로그를 남기기 시작하면 사후 분석이나 통합 대시보드(Grafana 등) 구성은 헬게이트가 열립니다.
GoVail은 처음부터 게이트웨이, 런타임, 대시보드 콘솔이 일치된 약속 하에 데이터를 주고받도록 JSON Schema를 먼저 설계했습니다. (이 스키마들은 govail-contracts 레포지토리에서 통합 관리됩니다.)
- 이유: 게이트웨이(Rust)와 분석기(Python), 런타임 간에 서로 다른 프로그래밍 언어를 쓰더라도 감사 이벤트의 데이터 포맷이 절대 어긋나지 않도록 강제하기 위함입니다.
- 예시:
audit_event.schema.json은 모든 AI 요청 발생 시 다음과 같은 항목을 의무적으로 담도록 선언합니다.event_id: 고유 식별자 (UUID)timestamp: RFC3339 규격 시간actor: 요청을 보낸 개발자 또는 시스템 식별자model_requested: 요청한 모델명status:allowed(허용됨) /blocked(차단됨) /flagged(경고 검출됨)violation_reason: 차단 시 구체적 위반 규칙 종류 (예:secret_detected)
2. 감사 로그의 기록 시점
GoVail Gateway는 두 가지 시점에 감사 로그를 발행합니다.
- 차단 즉시 (Blocking Path):
- 만약 프롬프트 스캔 단계에서
secret_detected룰에 걸려 요청이 파기되는 경우, Gateway는 LLM 상위 노드로 네트워크 요청을 보내기 직전에 차단 사실을 감사 로그로 즉시 떨어뜨리고 클라이언트에게 에러 코드를 내려줍니다.
- 만약 프롬프트 스캔 단계에서
- 정상 트래픽 처리 완료 시 (Forwarding Path):
- 필터를 무사히 통과해 LLM으로부터 정상 답변을 수신하면, 트래픽 메트릭(사용된 토큰 수, 소요 시간 등)을 첨부한 이벤트 로그가 남습니다.
이렇게 축적된 감사 로그는 단순히 디스크에 파일로 쌓일 수도 있고, Temporal 워크플로우를 거쳐 저장소에 적재되거나 Prometheus/Grafana 대시보드로 전달되어 실시간 모니터링 그래프를 그리는 밑바탕이 됩니다.
3. 개인정보 유출(PII)과 감사 로그의 딜레마
감사 로그 자체가 또 다른 개인정보나 기밀 유출의 온상이 되지 않도록 설계에 특별한 주의를 기울여야 합니다. GoVail은 감사 로그 기록 시 사용자의 원본 프롬프트 내용 전체를 무조건 저장하지 않는 옵션을 기본 탑재할 계획입니다. 대신 위험 패턴 감지 여부, 위반 단어의 마스킹된 조각(예: sk-proj-****)만을 기록하도록 유도하여 감사 로그 자체의 보안 무결성을 지킵니다.