블로그 · 가이드 · 2026년 10월 28일
운영 중인 AI 에이전트를 위한 추적성 체크리스트: 무엇을 기록하고, 무엇에 서명하고, 검토자에게 무엇을 보여 줄 것인가
공개: 100monkeys.ai는 오픈 소스 에이전트 오케스트레이터 AEGIS를 만들고, 아래에서 인용하는 awesome-agent-traceability 목록을 관리합니다. 이 체크리스트는 특정 벤더에 묶이지 않습니다. 모든 항목은 공개 도구로 충족할 수 있고, 어느 것도 저희 제품을 요구하지 않습니다. 저희 AI 에이전트 하나가 초안을 쓰고 회사가 검토했으며, 이 한국어판은 영어 원문 가이드의 번역입니다.
AI 에이전트가 실제 시스템에서 행동하면, 나중에 누군가는 그것이 무엇을 왜 했는지 묻게 됩니다. 이 체크리스트는 그 질문이 오기 전에 해 둘 일입니다. 모든 실행에서 무엇을 기록할지, 기록을 믿을 수 있도록 무엇에 서명할지, 그리고 검토하는 사람 앞에 무엇을 놓을지. 각 항목은 awesome-agent-traceability 목록의 공개 표준이나 도구를 하나씩 짚습니다.
이 틀은 저희 논문 Red levers: traceable, deterministic agents in production(영어)에서 왔습니다. 이 논문은 사람이 에이전트 시스템이 내린 모든 결정과 그 이유를 볼 수 있고 시스템을 멈출 수 있을 때, 그 시스템이 운영 환경에서 안전하다고 정의합니다. 로깅은 첫째를, 기록된 이유는 둘째를, 검토 단계는 셋째를 위한 것입니다.
1부. 무엇을 기록할 것인가
1단계. 모든 실행에 ID 부여
실행이 시작될 때 ID를 부여하고 모든 모델 호출, 도구 호출, 부수 효과에 그 ID를 이어서 붙이세요. 그것이 없으면 로그는 아무도 묶을 수 없는 이벤트 더미입니다. 생성형 AI를 위한 OpenTelemetry 시맨틱 규약의 trace ID와 span ID를 쓰세요. 이 규약은 모델 호출, 에이전트 단계, 도구 호출에 공통 이름을 정의하므로 서로 다른 프레임워크의 트레이스를 같은 방식으로 읽을 수 있습니다. 에이전트 span에 대한 규약은 에이전트의 생성과 호출을 다룹니다.
2단계. 요청과 의도를 말로 기록
에이전트가 무엇을 요청받았는지, 누가 요청했는지, 어떤 이유가 주어졌는지 기록하세요. 그리고 중요한 행위가 있을 때마다 에이전트가 직접 쓴 한 줄짜리 이유를 기록하세요. 행위 순간에 쓴 이유는 증거이고, 나중에 재구성한 이유는 이야기일 뿐입니다.
3단계. 모델과 설정 기록
모델 호출마다 제공자, 모델 이름과 버전, 출력을 바꾸는 매개변수(temperature, 최대 토큰 수, 제공된 도구), 토큰 수를 기록하세요. 모델 버전과 연결할 수 없는 동작은 제공자가 모델을 업데이트한 뒤에는 재현할 수 없습니다.
4단계. 모든 도구 호출을 입력과 출력과 함께 기록
도구 이름, 인자, 결과, 시각을 기록하세요. 개인 정보는 저장한 뒤가 아니라 저장하기 전에 가리세요. Presidio가 공개된 선택지 중 하나입니다. 어딘가에 쓴 도구 호출은 무엇을 바꿨는지도 기록해야 합니다. diff, 레코드 ID, 메시지 ID 같은 것입니다.
5단계. 정책 결정마다 기록
정책 엔진이 호출을 허용하거나 거부했다면 그 결정과 결정을 내린 규칙을 기록하세요. Open Policy Agent는 바로 이 용도로 결정 로그를 남깁니다. 거부는 허용만큼 남겨 둘 가치가 있습니다. 한계가 지켜졌다는 것을 보여 주기 때문입니다.
6단계. 신원과 접근 범위 기록
실행이 어떤 자격 증명이나 토큰을 썼는지, 그리고 그 자격 증명이 무엇에 닿을 수 있었는지를 기록하세요. 비밀 값 자체는 기록하지 않습니다. 검토자의 질문은 흔히 "더 나쁜 일을 할 수도 있었나"이고, 그 답은 실행이 가진 범위입니다.
7단계. 실행을 재현 가능하게 만들기
작업을 다시 실행할 수 있을 만큼 저장하세요. 입력, 각 단계의 상태, 이벤트의 순서입니다. Temporal 같은 지속 실행(durable execution) 엔진은 워크플로를 결정적으로 다시 재생할 수 있게 해 주는 워크플로 이벤트 이력을 보관합니다.
2부. 무엇에 서명할 것인가
8단계. 로그를 추가 전용으로 만들고 체인으로 연결
나중에 고쳐 쓸 수 있는 기록은 아무것도 증명하지 못합니다. 이벤트를 추가 전용 저장소에 쓰고, 각 항목을 해시로 바로 앞 항목과 연결해서 삭제되거나 수정된 항목이 체인을 끊도록 하세요. IETF SCITT 워킹 그룹은 추가 전용 투명성 서비스에 등록되는 서명된 진술을 정의하며, 이것이 이 용도에 바로 쓸 수 있는 형태입니다.
9단계. 에이전트가 만든 결과물에 서명
실행이 산출물(빌드, 보고서, 배포된 파일)을 만들면, 그것이 어떻게 만들어졌는지에 대한 서명된 진술을 붙이세요. in-toto Attestation Framework가 그런 진술을 담고, SLSA는 빌드 출처(provenance)의 수준을 정의합니다. 미디어의 경우 C2PA 사양이 AI가 만들거나 편집한 콘텐츠를 포함해 서명된 출처 매니페스트를 붙입니다.
10단계. 승인에 서명
사람이 어떤 행위를 승인했다면 누가, 언제, 정확히 무엇을 보고 승인했는지 기록하세요. 승인을 내용에 묶으세요. 승인 뒤에 행위가 바뀌면 그 승인은 더 이상 유효하지 않습니다.
3부. 검토자에게 무엇을 보여 줄 것인가
11단계. 요약이 아닌 행위 자체를 보여 주기
검토자는 실행 자체의 출력으로 렌더링된 이메일, diff, 또는 실행될 명령을 봐야 합니다. 승인을 원하는 바로 그 모델이 쓴 요약은 검토 화면이 될 수 없습니다.
12단계. 행위 옆에 이유를 보여 주기
에이전트가 기록한 의도를 그것이 만든 변경 옆에 두세요. "이 줄은 왜 여기 있나"라는 질문에는 그 줄이 반영될 때 쓰인 문장이 답해야 합니다.
13단계. 실행 당시의 제한을 보여 주기
정책과 자격 증명 범위를 실행 옆에 보여 주세요. 에이전트가 브랜치 하나에만 쓸 수 있었다는 것을 본 검토자는, 모든 것에 닿을 수 있었다고 가정해야 하는 검토자와 실행을 다르게 읽습니다.
14단계. 검토자에게 중지 수단 주기
모든 검토 화면에는 거부할 방법이 있어야 하고, 그 거부는 지켜져야 합니다. Red levers에 인용된 EU AI Act 제14조는 고위험 시스템을 감독하는 사람이 "intervene in the operation of the high-risk AI system or interrupt the system"(고위험 AI 시스템의 작동에 개입하거나 시스템을 중단)할 수 있기를 요구합니다. 여기서 이를 인용하는 것은 통제 장치의 형태에 관한 것이지, 규정 준수를 주장하는 것이 아닙니다.
스스로 점검하기
지난주의 실행 하나를 골라 기록만으로 답해 보세요. 누가 요청했는지, 에이전트가 무엇을 호출했는지, 무엇을 바꿨는지, 어떤 정책 아래였는지, 누가 승인했는지, 그 기록이 이후에 수정될 수 있었는지. 답할 수 없는 질문마다 위의 단계 하나에 대응합니다.
저희가 적용하는 방식
저희는 이 목록의 일부를 위한 도구를 만듭니다. AEGIS by 100monkeys.ai, in beta는 에이전트를 격리되고 정책이 강제되는 런타임에서 영속 상태와 함께 실행하는 자체 호스팅 오케스트레이터입니다. How to give an orchestrator an approval step(영어)은 그 승인 게이트를 실제 예제로 보여 주고, 이 설치 가이드는 서버에서 AEGIS를 실행하는 과정을 안내합니다. Carbon Forge는 코드와 글을 하나의 기록에 담으며, 그곳의 blame은 반영 시점에 쓰인 의도를 보여 줍니다.