AI 시스템의 감사 가능성은 나중에 문제가 생겼을 때 무엇이 입력됐고, 어떤 판단을 거쳤고, 어떤 도구가 실행됐고, 누가 책임질 수 있는지를 따라갈 수 있는 능력입니다. 단순히 로그를 많이 남기는 일이 아니라, AI가 실제 업무·권한·고객·규제와 연결될 때 필요한 설명 가능한 실행 기록을 남기는 문제입니다.
Loop engineering 관점에서는 agent가 한 번 답하고 끝나는 채팅이 아니라 반복 실행되는 시스템이 됩니다. 이때 작업 큐, 상태 저장, 재시도, 권한 제한, 관찰 가능성이 없다면 실패 원인을 추적하기 어렵습니다. AI 일자리 전환 프레임워크가 말하는 노동 전환에서도 공공·의료·법률·교육처럼 책임이 큰 영역은 모델 성능만이 아니라 데이터 거버넌스, 책임 소재, 감사 가능성을 함께 봐야 합니다.
한 줄로 말하면
AI 시스템의 감사 가능성은 AI가 왜 그런 행동을 했는지 사후에 추적하고, 책임과 재검증을 가능하게 만드는 실행 기록과 절차입니다.
왜 AI에서 더 중요해졌나
전통적인 소프트웨어도 로그와 감사 기록이 필요합니다. 하지만 AI 시스템에서는 문제가 조금 더 복잡해집니다.
첫째, 입력과 출력이 고정된 규칙만으로 결정되지 않습니다. 같은 모델이라도 prompt, context, 검색된 문서, memory, tool 결과에 따라 다른 행동을 할 수 있습니다. 따라서 최종 답만 저장하면 충분하지 않습니다.
둘째, AI가 도구를 호출하면 실제 부작용이 생길 수 있습니다. 문서 작성, 고객 응대, 배포, 결제, 권한 변경, 메시지 전송처럼 외부 세계에 영향을 주는 작업에서는 “모델이 그렇게 말했다”가 아니라 “어떤 조건에서 어떤 권한으로 어떤 실행이 승인됐는가”를 남겨야 합니다.
셋째, AI가 노동 흐름에 들어오면 책임 문제가 생깁니다. 공공 서비스, 의료, 법률, 교육, 금융처럼 사람이 책임을 져야 하는 영역에서는 AI가 어떤 근거로 보조했는지, 사람이 어디서 검토했는지, 기록이 얼마나 보존되는지가 채택의 병목이 될 수 있습니다. 실제 업무 도구와 연결되는 agent라면 Agent containment처럼 권한과 실행 환경을 미리 제한하는 설계도 함께 필요합니다.
감사 가능성이 포함해야 하는 것
1. 입력과 근거의 기록
어떤 사용자 요청, 문서, 검색 결과, memory가 판단에 들어갔는지 남겨야 합니다. 특히 Agent memory consolidation이 개입된 시스템에서는 저장된 기억의 출처와 epistemic status가 함께 보존되어야 합니다. 불확실한 기억이 확정 사실처럼 쓰였는지 나중에 확인할 수 있어야 하기 때문입니다.
2. 실행 경로의 기록
agent가 어떤 순서로 생각하고, 어떤 도구를 호출하고, 어느 단계에서 실패했는지 추적할 수 있어야 합니다. iii의 loop engineering 글은 agent loop를 관찰 가능하고 상태를 가진 분산 시스템으로 보라고 설명합니다. 이 관점에서는 trace, retry, dead-letter 처리, 중복 실행 방지 같은 오래된 소프트웨어 인프라 원칙이 AI agent에도 그대로 중요해집니다.
3. 권한과 승인 경계
감사 가능성은 기록만의 문제가 아닙니다. 누가 어떤 권한을 가졌는지, 모델이 직접 실행할 수 있는 일과 사람 승인이 필요한 일을 어디서 나누는지도 포함합니다. 권한 경계가 없다면 나중에 기록을 보더라도 왜 위험한 행동이 가능했는지 설명하기 어렵습니다.
4. 재검증과 수정 가능성
감사 가능한 시스템은 “왜 틀렸는가”를 찾을 수 있어야 합니다. 오래된 memory, 잘못된 source, 약한 verifier, 중복 실행, 사람 검토 누락처럼 원인을 나눠 볼 수 있어야 다음 설계를 고칠 수 있습니다.
관찰 가능성과의 차이
관찰 가능성은 시스템이 지금 어떻게 움직이는지 보이게 만드는 능력입니다. 지연 시간, 실패율, trace, tool call, queue 상태 같은 운영 지표가 여기에 들어갑니다.
감사 가능성은 한 걸음 더 나아가 책임 있는 설명을 요구합니다. 단순히 “오류가 났다”를 아는 것이 아니라, “어떤 입력과 권한과 승인 절차 때문에 이 결과가 나왔고, 누가 어떤 기준으로 검토할 수 있는가”를 묻습니다. 그래서 관찰 가능성은 감사 가능성의 재료가 될 수 있지만, 그 자체로 충분하지는 않습니다.
투자·산업 관점에서 보는 법
AI 제품을 평가할 때 “모델이 얼마나 똑똑한가”만 보면 놓치는 것이 많습니다. 실제 기업 환경에서는 보안, 권한 관리, 데이터 거버넌스, 감사 trail, 비용 통제, 사람 검토 절차가 도입 속도를 좌우할 수 있습니다.
특히 AI 노동 전환에서는 감사 가능성이 중요한 병목입니다. 규제와 책임이 강한 직업일수록 AI가 업무 일부를 잘 수행해도, 그 수행 결과를 설명하고 검토하고 책임질 수 있어야 실제 워크플로에 들어갈 수 있습니다. 반대로 감사 가능성이 약한 AI는 데모는 좋아도 조직 안의 핵심 업무로 들어가기 어렵습니다.
헷갈리지 말아야 할 점
감사 가능성은 모델이 항상 맞는다는 보장이 아닙니다. 오히려 틀릴 수 있다는 전제에서, 틀렸을 때 원인을 찾고 책임 있게 고치기 위한 구조입니다.
또한 모든 기록을 무작정 저장하는 것과도 다릅니다. 개인정보, 영업비밀, 보안 권한이 섞인 기록은 보존 기간과 접근 권한을 설계해야 합니다. 좋은 감사 가능성은 더 많은 기록이 아니라, 나중에 책임 있게 재구성할 수 있는 필요한 기록을 안전하게 남기는 일입니다.
마지막으로 감사 가능성은 법무·컴플라이언스 부서만의 문제가 아닙니다. agent를 제품으로 만드는 팀에게는 실행 품질과 안전성을 높이는 핵심 인프라이고, AI 도입 기업에게는 업무 재설계가 실제로 가능한지 판단하는 기준입니다.