증인이 용의자였다: AI 감사 로그를 그대로 믿을 수 없는 이유

AI 요약

AI 에이전트가 잘못된 데이터베이스를 지우거나 승인받지 않은 호출을 해도, 자체 로그에는 성공했다고 남을 수 있습니다. 행동한 시스템이 결과 기록까지 작성하기 때문입니다. 기존 모니터링은 성공 여부를 확인하도록 만들어진 경우가 많아, 형식이 정상인 잘못된 보고를 초록불로 표시할 수도 있습니다. 이때 사고 기록을 쓴 주체가 사고의 원인이 됩니다.

전통적인 버그는 예외나 실패한 테스트처럼 눈에 띄게 드러나는 일이 많습니다. 반면 AI의 실패는 그럴듯한 결과로 나타나기 쉽습니다. 함수가 얼핏 맞아 보이지만 확인하지 않은 경우에 틀리거나, 쿼리가 정상처럼 보이는 숫자를 내놓거나, 요약이 중요한 내용을 조용히 빠뜨릴 수 있습니다. 즉시 경고가 없으면 발견 시점이 늦어지고, 몇 주 뒤에 잘못된 대시보드나 운영 환경의 예외를 보고 나서야 원인을 역추적하게 됩니다. 빠르게 만든 결과가 나중에 신뢰성과 조사 비용의 부담으로 돌아옵니다.

검증을 더 쌓아도 신뢰 문제는 사라지지 않습니다

에이전트의 보고가 의심스러우니 별도 검증기를 두자는 대응도 충분하지 않습니다. 검증기 역시 하나의 프로세스이며, 잘못된 입력을 받거나 침해될 수 있습니다. 다시 검증기를 붙이면 검증기의 검증기를 누가 확인할지 묻게 됩니다. CI(지속적 통합)가 에이전트 보고를 그대로 읽는다면, 같은 신뢰 문제에 CI라는 이름표만 붙인 셈입니다. 검증을 층층이 쌓아도 신뢰의 근거가 되는 바닥은 생기지 않습니다.

글은 질문을 바꿉니다. 기록이 진실을 증명한다고 요구하지 말고, 누가 언제 어떤 주장을 했는지 위변조가 드러나는 방식으로 남겨야 합니다. 해시 체인(Hash chain)과 서명으로 각 항목을 앞선 항목과 연결하면, 나중에 기록을 고치거나 순서를 바꿀 때 흔적이 남습니다. 이 방식은 주장의 정답 여부를 증명하지 않습니다. 대신 그 주장이 언제 누구에게서 나왔고, 이후 바뀌지 않았는지를 보여줍니다. 조용한 삭제는 체인의 공백으로, 제안 없이 남은 승인은 대응 항목이 없는 사건으로 드러납니다.

기록을 설계하는 다섯 가지 원칙

첫째, 작성자를 분리합니다. 제안, 승인, 실행을 하나의 프로세스가 모두 맡지 않도록 하고, 각 단계를 서로 다른 주체의 사건으로 기록합니다. 사후에 내용이 맞지 않으면 단일 보고서가 아니라 서로 연결된 사건의 순서를 확인합니다.

둘째, 주장을 기록하는 시점에 봉인합니다. 해시 체인과 서명을 써서 사후 수정이나 순서 변경이 드러나게 합니다. 셋째, 기록을 행위자 바깥에 둡니다. 에이전트나 운영자가 기록을 몰래 고칠 수 없도록 추가만 가능한 저장소를 쓰고, 가능하면 외부에도 기록의 기준점을 남깁니다.

넷째, 행동뿐 아니라 행동 당시의 판단 근거도 남깁니다. 데이터베이스 삭제 사례라면 에이전트가 개발 환경이라고 생각했는지, 어떤 계정과 대상을 선택했는지 기록해야 원인을 조사할 수 있습니다. 다만 그 판단 근거 역시 에이전트가 말한 내용이므로, 기록만 봉인한다고 사실로 바뀌지는 않습니다. 다섯째, 승인을 맡은 주체를 구체적인 사람으로 식별합니다. ‘검토자’나 ‘시스템’ 같은 역할 이름만 남기면 누가 승인했는지 확인하기 어렵습니다.

보장하는 범위와 남은 문제

이 설계는 결과가 옳았는지, 승인자가 내용을 이해했는지 증명하지 않습니다. 승인을 반복하다 보면 내용을 살피지 않고 처리하는 승인 피로(approval fatigue)도 생길 수 있습니다. 변조를 막는 것이 아니라 변조가 조용히 지나가지 못하게 만드는 접근입니다. 글은 이를 ‘거짓말이 흔적을 남기게 한다’는 최소한의 보장으로 설명합니다.

댓글에서는 한 단계 더 나아간 방법으로 독립적으로 봉인된 기록 흐름끼리 대조하는 방안이 나옵니다. 에이전트의 주장과 도구가 실제로 받은 호출처럼, 같은 사건을 서로 다른 주체가 기록하면 두 기록의 불일치가 단일 로그로는 얻을 수 없는 단서가 됩니다. 다만 두 흐름이 같은 서비스, 자격 증명, 저장소, 시계에 의존하면 한 번의 침해로 모두 영향을 받을 수 있습니다. 기록의 독립성 자체를 설계 조건으로 삼아야 한다는 지적입니다. 네트워크나 저장소처럼 행동을 결정하지 않고 결과를 관찰하는 계층에서 기록을 얻고, 성공 보고 대신 총합·행 수·참조 데이터 존재 여부 같은 불변 조건을 검사하자는 의견도 나옵니다.

원문: dev.to / 번역·요약: Trawling

dev.to 반응

• @glenallen — “변조가 드러나는 기록”과 “진실이 드러나는 기록”의 차이가 아마 여기서 가장 중요합니다. 봉인된 기록은 에이전트가 특정 대상, 신원, 결과를 특정 시점에 주장했다는 점을 증명할 수 있지만, 그 주장이 맞았는지 확인하려면 독립적인 진실의 출처가 여전히 필요합니다. IT Path Solutions에서는 이 구분 덕분에 검증을 훨씬 명확하게 설명할 수 있었습니다. 감사 계층은 출처와 순서를 확인하고, 독립 시스템 상태나 권위 있는 산출물은 실제 결과를 확인합니다. 그렇지 않으면 완벽하게 기록된 잘못된 결정을 완벽한 체인으로 보관할 수 있습니다. 가장 강한 구조에는 두 속성이 모두 필요할 수 있습니다. 주장을 몰래 고치지 못하게 하고, 정확성을 확인하는 증거는 주장을 만든 행위자 바깥에 둬야 합니다.
  • @james_anderson_h — 제가 가장 다듬고 싶었던 구분이 바로 변조 여부와 진실 여부입니다. 봉인은 누가 어떤 순서로 무슨 주장을 했고, 그 기록이 바뀌지 않았다는 점을 증명하지만 주장이 옳았는지는 말해주지 않습니다. “완벽하게 기록된 잘못된 결정의 완벽한 체인”이라는 표현이 과도한 출처 신뢰의 함정을 정확히 짚었습니다. 제안하신 두 계층 구조에도 동의합니다. 감사 계층은 출처와 순서를 맡고, 독립된 시스템 상태나 권위 있는 산출물은 정확성을 맡아야 합니다. 두 번째 출처도 주장을 만든 행위자 바깥에 있어야 합니다. 그렇지 않으면 증인과 용의자가 같은 문제를 한 계층 아래에서 다시 만납니다. 봉인만 있으면 상황을 읽을 수 있고, 봉인과 외부의 실제 상태가 함께 있어야 읽기와 오류 감지가 가능합니다.
  • @glenallen — 이 소유권 분리가 있어야 구조가 단순한 감사 기록을 넘어 방어 가능한 설계가 됩니다. 다음 질문은 그 독립성 자체를 어떻게 시험하느냐입니다. 같은 서비스, 자격 증명, 상태 저장소가 감사 기록과 ‘진실의 근거’ 모두에 영향을 줄 수 있다면, 두 계층 구조는 독립적인 것처럼 보여도 같은 실패 원인을 공유합니다. 출처 독립성을 명시적인 아키텍처 불변 조건으로 다루면 더 강해질 수 있습니다. 에이전트의 주장을 반박하는 데 쓰는 증거는 그 주장을 만든 제어 경로 바깥에 있어야 합니다.
• @slabb — 글의 주장에 반론을 보태자면, 더 나아갈 방법이 있습니다. 글의 설계 요소에도 이름 없이 들어 있습니다. 독립적으로 봉인된 기록 흐름들을 대조하는 방법입니다. 하나의 체인은 누가 언제 무엇을 주장했는지 보증하지만, 주장의 진실 여부는 보증하지 못합니다. 기록할 때 거짓말을 봉인해도 검증 결과는 계속 깨끗하게 나오기 때문입니다. 하지만 같은 사건을 서로 다른 주체가 기록한 봉인된 체인 두 개는 서로 다를 수 있습니다. 변조가 드러나는 두 출처 사이의 불일치는 단일 기록으로 얻지 못하는 증거입니다. 한 흐름에서는 ‘우회가 공백을 남긴다’에 그치지만, 여러 흐름을 대조하면 ‘기록 시점의 거짓말이 충돌을 남긴다’로 나아갑니다. 가장 드러내기 어려운 공백은 글에서 말한 ‘당시의 판단 근거’일 겁니다. 용의자의 자기 보고를 봉인하는 데 그치기 때문입니다. 이를 보완하려면 에이전트가 행동한 세계를 독립적으로 관찰하는 기록, 즉 대조할 또 다른 흐름이 필요합니다.
  • @james_anderson_h — 제가 놓친 방법이 바로 이것입니다. 독립적으로 봉인된 흐름의 대조는 출처만이 아니라 주장 자체에 관한 증거를 만드는 단계입니다. 단일 체인으로는 기록 시점의 거짓말을 잡을 수 없습니다. 깨끗하게 봉인된 거짓말은 검증에서도 계속 깨끗하게 나옵니다. 하지만 같은 사건을 서로 다른 당사자가 기록한 두 흐름은 어긋날 수 있고, 둘 다 사후에 바꿀 수 없다면 그 불일치가 증거가 됩니다. ‘우회가 공백을 남긴다’에서 ‘기록 시점의 거짓말이 충돌을 남긴다’로 바뀝니다. 제 판단은 틀렸습니다. 가시성은 체인 하나의 바닥이고, 흐름 간 대조가 그 위 단계입니다. 당시의 판단 근거도 용의자의 자기 보고이므로, 봉인만으로는 자기 보고를 변조 불가능하게 만들 뿐입니다. 실제로 에이전트가 놓인 상황을 독립적으로 관찰해야 이 공백을 닫을 수 있습니다.
• @dhruv_malaviya_cdcc71e595 — 이 논리에 암묵적으로 들어 있는 계층을 명시하면 “에이전트 로그를 믿지 말라”는 말을 구현 가능한 구조로 바꿀 수 있습니다. 에이전트 로그, 애플리케이션 로그, 인프라 로그, 네트워크나 저장소 계층, 외부 관찰자 순서입니다. 행위자에게서 멀어질수록 신뢰도가 올라갑니다. 대부분의 팀이 두 번째 단계에서 멈추는 이유는 로그를 가장 쉽게 남길 수 있기 때문입니다. 가장 저렴하면서도 실제로 독립적인 기록은 보통 네트워크나 저장소 계층에서 얻습니다. 이 구성 요소들은 판단하지 않고 관찰하기 때문에 그럴듯한 성공 보고를 만들어내지 않습니다. 테스트에도 적용할 점이 있습니다. 성공 여부를 단언하면 용의자에게 스스로 채점하라고 시키는 셈입니다. 합계가 맞는지, 행 수가 일치하는지, 참조한 기록이 존재하는지 같은 불변 조건을 확인하면 결과가 말로 빠져나가기 어렵습니다. 작성하기는 더 번거롭지만 이런 실패 유형을 잡는 데 필요한 테스트입니다. 모니터링도 ‘성공했는가’보다 ‘세계의 상태가 여전히 일관적인가’를 물어야 합니다. 보고가 아니라 실제 효과를 측정해야 합니다.
• @eye_java_420f1faa10ae8b86 — 이 글은 제가 지금 쓰는 구조를 설명하는 것처럼 읽힙니다. 서버 사이드나 계정, 런타임이 전혀 없는 작은 정적 도구 사이트 여덟 개를 운영합니다. 행위자와 기록자가 같은 프로세스일 때 증인과 용의자 문제가 생깁니다. 제 해결책은 덜 영리합니다. 프로세스를 없앴습니다. 기록을 변조할 감사 로그도 없습니다. 체크인된 데이터로 페이지를 빌드하고, 저장소에서 빌드를 다시 실행할 수 있습니다. 방문자가 숫자를 믿어도 되느냐고 물으면, 사이트가 그에게 동적으로 거짓말할 능력이 없다고 답합니다. 방문자를 기억하거나, 방문자별로 답을 바꾸거나, 어제 무슨 말을 했는지 기억하지 못합니다. 독립된 출처를 대조하자는 이 댓글의 논점도 맞습니다. 정적 사이트에서는 매번 전부 다시 빌드하면 됩니다. 배포 때마다 원본 데이터에서 모든 페이지를 다시 만들면 데이터와 화면이 어긋난 채 남아 있을 틈이 없습니다. 단, 데이터만으로 동작 전체를 다시 만들 수 있는 사이트에 한정됩니다. 사용자별 상태가 필요해지는 순간 증인이 다시 필요해지고, 글의 문제도 다시 등장합니다.
• @arhancanli — 가장 드러내기 어려운 공백은 애초에 기록되지 않은 항목입니다. 체인은 기록된 항목의 수정이나 삭제를 잡지만, 에이전트가 스무 번 시도한 뒤 성공한 한 번만 봉인하면 체인은 온전해 보입니다. 연구에서도 기록된 숫자는 모두 실제인데 분모가 빠져 정직해 보이는 기록이 흔합니다. 95% 신뢰도로 아무 효과 없는 시도 스무 번을 하면 적어도 하나가 유의미해 보일 확률이 64%입니다. 결과를 보기 전에 계획을 봉인해야 누락을 드러낼 수 있습니다. 시도 횟수, 대상, 중단 규칙을 먼저 기록하면 빠진 시도가 계획과 비교했을 때 공백으로 나타납니다. 에이전트가 보고하지 않은 호출도 도구가 보는 이유로, 도구 경계의 기록 역시 도움이 됩니다.
• @kartik-nvjk — “증인이 용의자다”라는 표현이 와닿습니다. 에이전트가 자기 성공 로그를 쓰는 상황에서 초록색 대시보드가 아무것도 증명하지 못하는 이유가 정확히 그렇습니다. 에이전트 평가에서도 같은 문제를 겪었습니다. 실행은 정상 형식으로 성공을 보고하면서 조용히 엉뚱한 대상을 가리킵니다. 해결책은 대역 외 검증(out-of-band verification)뿐이라고 보시나요? 아니면 에이전트 자신의 로깅을 에이전트에게 불리하게 설계할 수도 있나요?