패턴·플레이북 · Patterns
AI 자동화의 audit trail 설계
자동화가 무슨 판단을 왜 했는지 나중에 되짚을 수 없다면, 그 자동화는 사고가 났을 때 손쓸 데가 없다. 추적은 사고 후가 아니라 설계 때 정한다.
승인 게이트와 Human-in-the-loop이 “틀리기 전에 막는” 장치라면, audit trail은 “틀린 뒤에 되짚는” 장치다. 둘은 짝이다. 아무리 게이트를 잘 둬도 비결정적인 시스템은 언젠가 예상 못 한 출력을 내고, 그때 무슨 일이 있었는지 되짚을 수 없으면 손쓸 데가 없다. 그리고 이 되짚기는 사고가 난 뒤에 만들 수 없다 — 무엇을 남길지는 설계할 때 정해진다.
audit trail은 사고가 난 뒤 로그를 뒤지는 일이 아니라, 처음부터 "무슨 입력에 무슨 판단을 왜 했고 누가 통과시켰는지"를 되짚을 수 있게 남겨 두는 설계다.
최소한 무엇을 남기나
전부를 남길 수는 없다. 비용도 들고 노이즈만 쌓인다. 그래서 한 번의 자동 판단을 나중에 재구성할 수 있는 최소 구성을 정한다. 네 가지가 한 줄로 이어져야 한다.
핵심은 네 칸이 하나로 묶여 있어야 한다는 점이다. 입력 로그 따로, 출력 로그 따로, 승인 기록 따로 흩어져 있으면, 사고 났을 때 그걸 다시 잇느라 시간을 다 쓴다. “이 출력은 이 입력을 보고 이 근거로 냈고 이 사람이 통과시켰으며 결국 적용/롤백됐다”가 한 줄로 따라와야 한다. 특히 판단의 근거는 비결정적 시스템에서 빠지기 쉬운데, 같은 입력에도 다른 답이 나올 수 있으니 “왜 이 답이었나”가 없으면 재현조차 안 된다.
세 가지 질문에 답하려고 남긴다
audit trail이 답해야 하는 건 결국 세 질문이다. 이걸 기준으로 무엇을 남길지가 정해진다.
- 무슨 일이 있었나. 사고가 났을 때 어떤 입력에서 어떤 출력이 나왔는지 시간순으로 재구성할 수 있는가. 디버깅의 출발점.
- 누구 책임인가. 자동으로 적용된 건지, 사람이 승인한 건지, 승인했다면 누가 무엇을 보고 했는지. 책임 소재가 흐리면 같은 사고가 반복된다.
- 어떻게 되돌리나. 무엇이 어떻게 바뀌었는지 기록돼 있어야 롤백할 수 있다. 변경 전 상태를 안 남기면 되돌릴 방법이 없다.
이 세 질문에 답이 안 나오는 기록은 양이 많아도 audit trail이 아니라 그냥 로그 더미다.
남기는 것과 찾는 것은 다르다
흔한 함정은 “다 남겼으니 됐다”고 생각하는 것이다. 그런데 기록은 남기는 것과 찾을 수 있는 것이 다르다. 테라바이트로 쌓여 있어도 특정 사건을 검색해 관련 레코드를 연결해 볼 수 없으면, 사고 한복판에서 그 기록은 없는 것과 같다. 그래서 추적은 쌓는 설계만큼 읽는 설계가 중요하다 — 식별자로 묶고, 검색이 되고, 한 사건의 입력·판단·승인·결과를 한자리에 모아 볼 수 있어야 한다.
여기서 공개 가능한 범위를 넘는 구체적인 스키마나 보관 기간 같은 운영 디테일은 시스템마다 다르고, 이 글의 목적도 아니다. 패턴만 남긴다 — 네 칸을 하나로 묶고, 세 질문에 답하게 하고, 찾을 수 있게 둔다.
비결정 시스템일수록 더
audit trail은 새로운 개념이 아니다. 금융이든 인프라든 중요한 시스템은 늘 추적을 남겨 왔다. 다만 AI 자동화에서는 그 중요도가 한 단계 올라간다. 결정론적 코드는 같은 입력에 같은 출력이라 코드만 봐도 재현되지만, 모델은 매번 다른 답을 낼 수 있어서 “그때 왜 그랬나”를 기록으로 남겨두지 않으면 사후에 복원할 길이 없다. 매번 다른 답을 내는 부품일수록, 무엇을 보고 무엇을 왜 했는지가 더 중요해진다.
아직 정리 중인 건 근거(왜 이 출력인지)를 어느 수준까지 남기느냐다. 너무 적으면 재현이 안 되고, 전부 남기면 비용과 노이즈가 감당이 안 된다. 그 적정선은 사고를 몇 번 되짚어 보고 나서야 잡힐 것 같아 지금은 열어둔다.
- 초안 작성. 최소 레코드 4칸·세 질문·찾을 수 있는 설계 정리 (성숙도: 탐색 중)
- 판단 근거를 남기는 적정 수준을 익명화 사례로 보강