AI 에이전트의 모든 작업에 감사 로그가 필요한 이유, 그리고 무엇을 기록해야 하는가

에이전트의 작업이란 실제로 무엇인가

사람이 "이슈 닫기"를 누르면 한 사람의 한 가지 작업입니다. 에이전트가 이슈를 닫으면 연쇄가 됩니다. 사람(또는 스케줄)이 에이전트 실행을 시작하고, 실행이 도구를 호출하고, 도구가 스코프를 확인하고, 스코프는 토큰에, 토큰은 사람에 묶여 있으며, 그제야 이슈 상태가 바뀝니다. 이 고리 중 어느 것이든 잘못된 지점일 수 있습니다.

그래서 "에이전트가 했다"는 답이 아닙니다. 감사 로그가 답해야 할 질문은 어떤 실행이, 누구의 토큰으로, 어떤 도구를, 어떤 레코드에 대해 호출했고, 결과는 무엇이었는가입니다. 이 다섯 가지 중 하나라도 빠지면 그 로그는 위안이지 통제가 아닙니다.

일반 애플리케이션 로그로는 부족한 이유

대부분의 제품은 이미 무언가를 기록합니다. 웹 서버는 요청을, 데이터베이스는 변경을 기록하고, 채팅 도구는 메시지 기록을 보관합니다. 에이전트의 작업이 "어딘가에 들어 있다"고 말하고 싶어지지만, 실무에서는 세 가지 이유로 실패합니다.

• 경계에서 귀속이 사라집니다. 에이전트의 요청은 보통 연동 사용자나 에이전트가 들고 있는 토큰의 주인이 보낸 요청으로 도착합니다. 애플리케이션 로그에는 "Moeid가 이슈 412를 닫음"이라고 남습니다. Moeid가 점심을 먹고 있었고 야간 스케줄이 시작한 실행이 그 일을 했다는 사실은 남지 않습니다.
• 읽기는 보이지 않습니다. 애플리케이션 로그는 쓰기를 기록합니다. 모든 거래의 금액을 읽고 채팅 메시지로 요약한 에이전트는 읽기의 흔적을 남기지 않으며, 유출은 데이터베이스가 아니라 요약 안에 있습니다.
• 로그를 검토할 수 없습니다. 에이전트 작업이 만 줄의 요청 소음과 섞인 로그는 창업자가 금요일에 열어 이번 주 에이전트가 무엇을 했는지 확인할 수 있는 것이 아닙니다. 아무도 읽지 않는다면 감독이 아닙니다.

Anthropic의 에이전트 구축 지침은 분명합니다. 에이전트의 계획 단계를 명시적으로 보여 투명성을 우선하고, 체크포인트에서 사람의 피드백을 위해 멈추며, 최대 반복 횟수 같은 중단 조건을 두라는 것입니다. 감사 로그는 실행이 끝나고 채팅 창을 닫은 뒤에도 그 투명성이 살아남게 하는 수단입니다.

표준이 요구하는 것

알아둘 만한 문서가 셋 있습니다. "충분함"이 무엇인지 정의하고, 고객사 구매 팀이 여러분에게 인용할 문서이기 때문입니다.

• OWASP Top 10 for Agentic Applications(2026). OWASP GenAI Security Project가 2025년 12월 9일에 발표했으며 100명 이상이 기여했습니다. 불충분한 로깅은 과도한 에이전시, 도구 오용, 메모리 오염과 함께 명시된 열 가지 위험 중 하나입니다. 2차 해설들은 카테고리 번호에서 서로 어긋나므로 ID가 아니라 이름으로 인용하십시오.
• EU AI법 제12조. "고위험 AI 시스템은 시스템 수명 전체에 걸쳐 이벤트(로그)의 자동 기록을 기술적으로 가능하게 해야 한다." 로깅은 "의도된 목적에 적합한" 추적 가능성을 제공해야 합니다. 위험이 될 수 있는 상황의 식별, 시판 후 모니터링, 운영 모니터링의 세 가지입니다. 부속서 III 시스템에는 2027년 12월 2일부터, 부속서 I 시스템에는 2028년 8월 2일부터 적용됩니다. 작은 팀의 이슈 트래커는 고위험 시스템이 아니지만, 이 문구는 로그의 목적을 잘 정의합니다.
• Anthropic, "Building effective agents"(2024년 12월). 표준은 아니지만 가장 많이 인용되는 실무 지침입니다. 계획 단계의 투명성, 사람의 체크포인트, 가드레일을 갖춘 샌드박스 테스트. 오늘날의 도구 대부분이 존재하기 전에 쓰였지만 여전히 옳습니다.

공통된 맥락은 이렇습니다. 로그는 자동이어야 하고(사후에 손으로 쓴 보고가 아니라), 연속적이어야 하며(샘플이 아니라 모든 작업), 목적에 맞아야 합니다(무슨 일이 있었는지 재구성할 만큼이지, 모든 것의 복사본이 아니라).

다섯 가지 필드, 그리고 빼야 할 한 가지

에이전트가 수행하는 모든 호출에 대해 우리가 보관하는 기록이며, 어떤 팀에게든 최소한이라고 봅니다.

그리고 빼야 할 것은 내용입니다. 거래 금액도, 이슈 본문도, 메시지 텍스트도 넣지 않습니다. 이유는 두 가지입니다. 첫째, 로그는 로그를 볼 권한이 있는 누구에게나 보여줄 수 있어야 합니다. 내용을 담으면 기록한 모든 것의 권한을 물려받아, 정작 가장 필요한 사람에게 보여줄 수 없게 됩니다. 둘째, 내용은 이미 레코드 안에 있습니다. 대상 ID가 그곳을 가리키고, 레코드 자체의 버전 기록이 무엇이 바뀌었는지 보여줍니다.

도구, 행위자, 대상, 결과, 시각을 담은 로그는 이 글의 모든 질문에 답할 수 있습니다. 내용까지 담은 로그는 접근 통제가 더 약한 데이터베이스의 두 번째 사본입니다.

읽기도 쓰기만큼 중요하다

반사적으로 쓰기만 기록하게 됩니다. 무언가를 망가뜨리는 것은 쓰기이기 때문입니다. 에이전트는 이 계산을 바꿉니다. CRM 읽기 권한을 가진 에이전트는 에이전트에 접근할 수 있는 누구에게서든 채팅 창에서 모든 거래와 금액을 나열해 달라는 요청을 받을 수 있습니다. CRM의 권한 체계는 거래 금액을 읽으려면 특정 권한이 필요하다는 전제로 만들어졌습니다. 에이전트의 토큰에는 그 권한이 있고 요청한 사람에게는 없다면, 그 읽기의 로그가 유출의 유일한 증거입니다.

우리의 규칙은 읽기도 쓰기와 같은 수준으로 기록하되 결과 필드를 정직하게 유지하는 것입니다. 거부된 읽기("refused: crm.value.view")는 성공한 읽기 천 건보다 검토자에게 더 유용합니다. 권한 계층이 작동하고 있음을, 그리고 누가 떠보고 있었는지를 보여주기 때문입니다.

속도 제한도 감사의 일부다

로그는 무슨 일이 있었는지 알려줍니다. 제한은 누군가 로그를 읽기 전에 잘못된 일이 만 번 일어나는 것을 막습니다. 둘은 한 쌍입니다. 토큰별 호출 제한과 더 엄격한 쓰기 제한이 있으면 루프에 빠진 에이전트나 도난당한 토큰의 피해가 유한해지고, 로그에는 사람이 볼 수 있는 429의 급증이 나타납니다.

Atrix에서는 모든 MCP 토큰이 분당 120회 호출과 30회 쓰기로 제한됩니다. 일부러 낮게 잡았습니다. 사람의 하루 업무를 돕는 에이전트는 근처에도 가지 않고, 루프는 십 초 안에 도달합니다.

Atrix는 에이전트 작업을 어떻게 기록하는가

Atrix AI는 OAuth 2.1 뒤에 있는 85개 도구의 MCP 서버를 통해 워크스페이스를 에이전트에 노출합니다. 모든 호출은 위의 다섯 가지 필드 그대로, 즉 도구, 결과, 대상의 종류와 ID, 그리고 그 뒤의 토큰과 사람으로 감사됩니다. 내용은 감사 로그에 절대 기록되지 않습니다. /developers에 문서화된 REST API를 통한 호출에도 똑같이 적용됩니다.

세 가지 설계 결정이 대부분의 일을 합니다.

1. 스코프는 좁고 절대 넓어지지 않습니다. 토큰에는 특정 스코프가 부여됩니다(2026년 10월 기준 부여 가능한 스코프는 49개). 쓰기 스코프는 해당 읽기를 함의하지만 그 외에는 아무것도 함의되지 않습니다. 아홉 개 스코프는 추가로 본인 계정의 해당 권한을 요구하므로, 토큰은 만든 사람 이상에 절대 닿을 수 없고 권한은 호출마다 확인됩니다. 어떤 사람의 접근을 회수하면 그 사람이 만든 모든 토큰이 그 즉시 범위를 잃습니다.
2. 사람에게 알림을 보내는 쓰기는 게이트로 막혀 있습니다. 피드에 업데이트를 게시하는 것은 별도의 명명된 스코프이며 일반 쓰기 스코프에서 절대 함의되지 않습니다. 모든 사람의 휴대폰에 알림이 가기 때문입니다. 에이전트가 우연히 이를 물려받을 수 없습니다.
3. 로그는 에이전트가 아니라 사람의 것입니다. 감사 항목은 토큰과 그것을 만든 사람을 명시합니다. "에이전트가 했다"는 이름이 있는 동료로 귀결되며, 그 사람이 에이전트에게 허용한 일에 책임을 집니다.

한계도 분명히 말합니다. 이것은 MCP와 API를 통한 호출의 감사입니다. Atrix는 코드를 스캔하지 않고, 정적 분석을 실행하지 않으며, 에이전트의 "요구사항 감사"는 동결된 기준선 대비 커버리지 확인이지 보안 도구가 아닙니다. 감사 로그는 워크스페이스에서 누가 무엇을 했는지에 답하지, 에이전트의 추론이 타당했는지는 평가하지 않습니다.

작은 팀을 위한 감독 체계 세우기

보안 팀은 필요 없습니다. 다섯 가지 필드, 주 1회의 습관, 그리고 누가 에이전트를 연결할 수 있는지에 대한 규칙이면 됩니다.

1. 에이전트 연결마다 한 사람이 책임집니다. 공유 연동 사용자는 없습니다. 토큰을 만든다면 이름이 있는 사람이 자기 계정으로 만들어, 토큰이 가진 권한이 그 사람의 것이 되고 로그가 그 사람을 명시하도록 합니다.
2. 읽기부터 부여합니다. 일주일 동안 읽기 스코프만으로 에이전트를 연결합니다. 로그를 읽습니다. 그런 다음 에이전트에 실제로 필요한 쓰기 스코프 하나만 추가합니다.
3. 매주 로그를 읽되, 쓰기와 거부로 필터링합니다. 금요일에 20분. 찾는 것은 두 가지, 예상하지 못한 쓰기와 누군가 필요 이상을 요구했음을 보여주는 거부입니다.
4. 알림을 보내는 쓰기는 사람의 트리거 아래에 둡니다. 팀 전체에 게시하거나, 고객에게 이메일을 보내거나, 돈을 움직이는 모든 것은 사람이 명시적으로 부여하고 별도로 검토하는 스코프여야 합니다.
5. 속도 제한은 사람이 손으로 할 수 있는 양보다 낮게 설정합니다. 사람이 1분에 30건을 바꿀 수 없다면 에이전트에게도 허용해서는 안 됩니다.
6. 필요해지기 전에 보존 기간을 정합니다. 90일치 감사 항목이면 "지난달에 무슨 일이 있었나"의 거의 모든 질문에 답할 수 있습니다. 로그에 내용이 없다면 더 길어도 괜찮습니다. 내용을 넣지 말아야 할 또 하나의 이유입니다.

에이전트 로깅 방식 비교

채팅 기록에는 한마디 덧붙일 필요가 있습니다. 에이전트 자신의 요약("거래 세 건을 성사로 옮겼습니다")을 기록으로 삼고 싶어집니다. 그것은 조사받는 당사자의 진술입니다. 감사 로그가 독립적인 기록입니다.

자주 묻는 질문

AI 에이전트 감사 로그에는 무엇이 들어가야 합니까?

최소한 호출된 도구, 토큰과 그 소유자, 대상의 종류와 ID, 결과(ok, 거부, 오류), 시각입니다. 내용은 빼십시오. 대상 ID가 레코드를 가리키고, 레코드 자체의 기록이 변경을 보관합니다.

에이전트의 읽기도 기록해야 합니까, 쓰기만 기록해야 합니까?

둘 다입니다. 에이전트는 읽은 뒤 채팅에서 요약하는 방식으로 데이터를 유출할 수 있고, 그 읽기가 유일한 증거입니다. 읽기를 쓰기와 같은 수준으로 기록하고 특히 거부된 읽기에 주의하십시오.

AI 에이전트 감사 로그는 법적 의무입니까?

대부분의 작은 팀에게는 아닙니다. EU AI법 제12조는 고위험 AI 시스템에 이벤트 자동 기록을 요구하며, 부속서 III 시스템에는 2027년 12월 2일부터 적용됩니다. 이슈 트래커나 CRM 에이전트는 고위험이 아닙니다. OWASP Top 10 for Agentic Applications(2026)는 불충분한 로깅을 명명된 위험으로 열거하는데, 이는 법이 아니라 지침이지만 구매 설문지가 인용하는 것이 바로 이것입니다.

감사 로그는 에이전트의 채팅 기록과 어떻게 다릅니까?

채팅 기록은 에이전트가 쓴, 자신이 무엇을 했는지에 대한 설명입니다. 감사 로그는 에이전트가 작업한 시스템이 작업 시점에 토큰과 사람을 명시하며 쓰는 것입니다. 둘이 어긋나면 감사 로그가 옳습니다.

Atrix는 에이전트가 읽거나 쓴 내용을 기록합니까?

아니요. Atrix는 모든 MCP 및 API 호출에 대해 도구, 결과, 대상의 종류와 ID, 그 뒤의 토큰과 사람을 기록합니다. 내용은 감사 로그에 절대 기록되지 않습니다. 레코드의 변경은 해당 레코드 자체의 버전 기록에서 볼 수 있습니다.

에이전트 감사 항목은 얼마나 오래 보관해야 합니까?

90일이면 실무상 거의 모든 질문에 답할 수 있습니다. 잘 설계된 항목은 내용을 담지 않으므로 더 오래 보관해도 위험이 적습니다. 더 중요한 것은 누군가 매주 그것을 읽는 것입니다.

다음 단계

에이전트를 처음으로 업무에 연결한다면 읽기 스코프, 이름이 있는 한 명의 책임자, 주 1회 로그 확인으로 시작하십시오. Atrix AI 에이전트도 같은 제한 안에서 동작하며, MCP 문서에는 모든 스코프와 그 함의가 적혀 있어 부여하기 전에 무엇을 부여할지 정할 수 있습니다.

출처

2026년 10월 확인: OWASP Top 10 for Agentic Applications for 2026, EU AI법 제12조: 기록 보관, Anthropic, Building effective agents.