Docker AI Governance에 조직 단위 감사 로그 조회와 SIEM 전송 기능이 추가됐다. 핵심은 AI 에이전트가 실행한 작업뿐 아니라 정책에 따라 허용되거나 거부된 요청, 사람의 판단을 기다리도록 보류된 요청까지 정책 결정 시점에 기록한다는 점이다. 보안팀은 Docker Cloud에서 조직 전체 기록을 검색하거나 기존 SIEM으로 이벤트를 전달해 에이전트의 행동과 정책 집행 결과를 함께 조사할 수 있다.
일반적인 애플리케이션 로그는 실행된 프로세스나 에이전트가 만든 결과를 중심으로 수집한다. 반면 정책이 실행 전에 차단한 도구 호출, 접근하지 못하게 한 도메인, 요청됐지만 제공되지 않은 자격 증명은 후속 출력 자체가 만들어지지 않을 수 있다. Docker는 정책을 집행하는 런타임 계층에서 구조화된 이벤트를 생성해 이러한 간극을 보완한다고 설명한다.
Docker Cloud 조회와 SIEM 전송
Docker Cloud에는 조직 전체 감사 기록을 한곳에서 검색하는 화면이 제공된다. 원문에 따르면 기록 보존 기간은 90일이며 CSV 내보내기를 지원한다. 기존 로컬 디스크 전달 방식도 계속 사용할 수 있고, 로컬 전달과 Docker Cloud 기록을 동시에 운영할 수 있다.
감사 이벤트는 일반 HTTPS 연결을 통해 기존 SIEM 엔드포인트로 전달할 수 있다. Docker는 연동 대상의 예로 Splunk와 Dynatrace를 제시한다. 감사 로그의 Docker Cloud 제공과 SIEM 스트리밍은 모두 Docker AI Governance에 포함된다고 밝혔다.
다만 원문은 개별 SIEM의 인증 방식, 재전송 동작, 네트워크 제한이나 필드 매핑 방법까지 설명하지 않는다. 따라서 실제 도입 전에는 사용하는 SIEM의 수신 조건과 Docker가 제공하는 연결 방식을 별도로 대조해야 한다. 90일보다 긴 보존이 필요한 조직도 SIEM이나 별도 저장 경로를 이용한 장기 보존 방안을 검토할 필요가 있다. 이는 공식 지원 범위를 단정하는 설명이 아니라 운영 환경에서 확인해야 할 사항이다.
정책 집행 지점의 기록이 중요한 이유
Docker가 설명한 정책 판단 결과는 허용, 거부, 사람의 확인을 기다리는 보류의 세 가지다. 허용 기록은 에이전트가 실제로 수행한 행동을 보여준다. 거부와 보류 기록은 실행 결과만 수집하는 방식으로는 놓치기 쉬운 시도와 정책 반응을 보여준다.
예를 들어 정책이 도구 호출을 거부하면 호출 결과는 생성되지 않는다. 특정 도메인의 접근을 막거나 요청된 자격 증명을 제공하지 않은 경우에도 에이전트 출력만으로는 해당 시도와 차단 이유를 파악하기 어렵다. 정책 결정이 내려진 지점에서 기록을 만들면 “에이전트가 무엇을 했는가”뿐 아니라 “무엇을 하려 했고 정책이 무엇을 막았는가”도 조사할 수 있다.
이 기록은 배포 후 사고 조사에만 쓰이는 것은 아니다. Docker는 보안팀이 에이전트 배포를 승인하기 전에 입증 가능한 감사 기록을 요구하는 사례가 늘고 있다고 설명한다. 조직은 허용 이벤트로 정상 활동을 확인하고 거부 이벤트로 설정한 통제가 실제로 작동하는지 점검할 수 있다. 보류 이벤트가 예상한 작업에서 발생하는지도 함께 살피면 사람의 승인이 필요한 정책 흐름을 확인하는 데 도움이 된다.
현재 지원 범위와 제한
발표 시점의 기록 범위는 Docker Sandboxes의 정책 판단과 샌드박스 세션 이벤트다. 모든 Docker 환경에 자동 적용되는 기능은 아니다. Docker AI Governance 라이선스를 보유한 사용자가 조직에서 강제 적용되는 정책 아래에 있을 때 기록이 제공된다. 기능을 검토할 때는 라이선스 보유 여부뿐 아니라 조직 정책이 실제로 강제되고 있는지도 확인해야 한다.
Docker는 MCP Gateway의 정책 집행 판단 등 다른 출처도 제공 가능해지는 대로 같은 스키마로 기록할 계획이라고 밝혔다. 이는 향후 확장 방향이며 현재 지원 범위가 아니다. MCP Gateway 이벤트가 당장 수집된다고 전제하거나, 지원 시점과 세부 범위를 확정된 기능처럼 해석해서는 안 된다.
감사 기록에는 메타데이터만 들어간다. Docker 설명에 따르면 프롬프트 내용, 에이전트 출력, 매개변수 값은 포함되지 않는다. 따라서 이 기능은 프롬프트와 결과를 포함하는 전체 실행 기록이나 연구 재현 기록을 대신하지 않는다. 입력과 출력까지 보존해야 하는 팀은 정책 감사 기록과 별도의 실행 기록을 구분해 설계해야 한다.
도입 전에 확인할 항목
| 항목 | 확인할 내용 |
|---|---|
| 이용 조건 | 대상 사용자에게 Docker AI Governance 라이선스가 있고 조직 정책이 강제 적용되는지 확인한다. |
| 기록 범위 | 필요한 이벤트가 현재 지원되는 Docker Sandboxes 정책 판단 또는 세션 이벤트에 해당하는지 구분한다. |
| 정책 결과 | 대표적인 허용·거부·보류 시나리오에서 예상한 감사 이벤트가 생성되는지 시험한다. |
| 보존 기간 | Docker Cloud의 90일 보존이 조직의 요구를 충족하는지 판단한다. |
| 전송 경로 | 로컬 디스크, Docker Cloud, SIEM 가운데 필요한 경로를 정하고 병행 운영 여부를 검토한다. |
| 데이터 내용 | 프롬프트, 출력, 매개변수 값이 제외되는 점을 고려해 감사 목적에 충분한 기록인지 확인한다. |
| 외부 연동 | SIEM의 HTTPS 수신 조건과 이벤트 검색 방식을 실제 환경에서 시험한다. |
SIEM 연결을 검증할 때는 적은 수의 시험 이벤트로 시작하는 편이 안전하다. 이벤트가 수신되고 필요한 필드로 검색되는지, 로컬 전달과 병행할 때 운영상 혼선이 없는지 살핀 뒤 범위를 넓힐 수 있다. 인증, 권한 분리, 장애 시 재처리 같은 세부 동작은 원문에 명시되지 않았으므로 실제 제품 문서와 조직 환경을 기준으로 확인해야 한다.
누구에게 유용한가
이미 중앙 보안 관제 체계를 운영하는 조직에는 정책 집행 기록을 기존 조사 절차에 합칠 수 있다는 점이 가장 직접적인 이점이다. 보안팀이 관리하지 않는 개별 개발자 환경에서 사후 증거를 조립하는 대신, 조직 전체 기록을 Docker Cloud에서 찾거나 익숙한 SIEM에서 조회할 수 있다.
팀 개발 환경에서는 기술 오류로 실패한 작업과 조직 정책이 의도적으로 거부한 작업을 구분하는 데 활용할 수 있다. 두 상황은 대응 방법이 다르므로 SIEM에서 정책 결과를 기준으로 검색할 수 있다면 운영 장애와 보안 통제를 나눠 조사하기가 쉬워진다. 사람의 승인을 기다리는 보류 기록 역시 승인 흐름이 의도대로 작동하는지 확인하는 자료가 된다.
반면 에이전트가 Docker Sandboxes 밖에서 실행되거나 필요한 이벤트가 아직 지원 범위에 없다면 이번 발표만으로 즉시 전환할 근거는 약하다. 개인 프로젝트에서도 조직 전체 검색과 SIEM 전송이 필요하지 않다면 계속 제공되는 로컬 디스크 전달 방식이 목적에 맞는지 먼저 비교할 수 있다.
도입 판단에서는 새로운 기록 화면의 존재보다 실제 조사 가능성을 봐야 한다. 필요한 정책 결정이 빠짐없이 남는지, 담당자가 검색할 수 있는지, 90일 보존으로 충분한지, 기존 보안 절차에 연결할 수 있는지를 작은 범위에서 검증하는 것이 핵심이다. 원문에는 구체적인 상품 가격이나 외부 SIEM의 수집·저장 비용이 제시되지 않으므로 비용 판단은 현재 계약과 운영 환경을 기준으로 별도 확인해야 한다.
출처와 검증
이 글은 Docker가 2026년 8월 3일 공개한 발표를 기준으로 정리했다. 지원 대상, 라이선스 조건, 보존 기간, 이벤트 스키마와 연동 방식은 실제 적용 시점에 달라질 수 있으므로 최신 공식 문서를 확인해야 한다.
원문: Docker AI Governance: Audit Logs, Now Where Your Security Team Already Works