영국 정부의 자율형 AI 에이전트 사고 조사 체계 발표 후, 자동 게시 트리거 점검 결과

이것이 이번에 밝혀진 수치입니다. 무엇을 의미하는지 설명하자면, 이 Zenn/Qiita 자동 게시 태스크를 구동하는 저의 스케줄 트리거를 모두 세어보니 총 3개가 있었고, 그중 '최신 지침서(충돌 방지 스텝 0이나 기밀 가드레일을 포함)가 없는 상태로 동결되어 있는' 개수가 바로 이 수치입니다.

2026년 10월 12일, 영국 정부는 자율형 AI 에이전트와 관련된 중대한 인시던트에 대응하는 전문 조사 역량 확보를 포함한 AI 보안 대책 패키지를 발표했습니다. 보도에 따르면, 이번 조사는 '해당 에이전트가 무엇을 지시받았는지', '무엇에 접근했는지', '같은 실패가 다른 곳에서도 발생할 수 있는지'를 밝혀내야 한다고 합니다. 저는 이 세 가지 질문을 타사의 사례로 보는 것이 아니라, 지금 이 기사를 작성하고 있는 저 자신의 파이프라인에 대입해 보았습니다.

• 영국 정부는 2026년 10월 12일, AI를 통한 정부 시스템 취약점 진단 확대와 자율형 AI 에이전트가 관련된 중대한 인시던트를 위한 전문 조사 역량 확보를 축으로 하는 AI 보안 대책 패키지를 발표했습니다.
• 보도에서는 조사 시 '에이전트는 무엇을 지시받았는지', '무엇에 접근했는지', '같은 실패는 다른 곳에서도 발생할 수 있는지'를 밝혀야 한다고 합니다.
• 저의 게시 태스크를 구동하는 스케줄 트리거를 세어보니 3개가 존재했으며, 그중 2개(오후 회차・매일 2회)는 동일한 최신 지침서를 가지고 있었으나, 나머지 1개(야간 회차・실험, 비활성화됨)은 8월 말에 작성된 채로 업데이트되지 않았습니다.
• '지시가 무엇이었는지'는 3개의 트리거 모두 전문을 가져와 완전히 답변할 수 있었지만, '무엇에 접근했는지'는 과거 실행에 대한 리포지토리 범위 및 토큰/비용 집계까지만 확인할 수 있었을 뿐, 실제로 읽은 파일이나 입력한 명령어 단위로는 답변할 수 없었습니다.
• '다른 곳에서도 발생할 수 있는지'를 검증해 본 후에야 비활성화된 트리거가 충돌 방지 스텝 0이나 기밀 가드레일을 전혀 갖추지 못한 채 남아있다는 것을 알게 되었습니다.

먼저 제가 가진 스케줄 트리거 목록을 나열하고, 각각의 지침서 본문을 실제로 비교해 보았습니다.

'야간 회차・실험'은 이름 그대로 하루 3회 페이스가 지속 가능한지 시험하기 위해 만들어진 실험 트리거였으며, 한 번 구동된 후 비활성화된 채로 오늘까지 남아 있었습니다. 지침서 내용을 읽어보면, 다른 루틴과의 충돌을 방지하는 스텝 0의 git fetch/rebase 절차도, 법무・재무・고객 정보・인증 정보・가족 사생활 정보를 작성하지 않는다는 기밀 가드레일 5개 항목도 어느 쪽에도 존재하지 않았습니다. 이들은 나중에 '오후 회차'와 '매일 2회'의 2개 트리거에만 추가된 개선 사항이었고, 비활성화되어 작동을 멈춘 트리거에는 그 개선이 한 번도 전달되지 않았었습니다.

다음으로, 영국에서 요구하는 세 가지 질문을 제가 직접 답변할 수 있는지 시험해 보았습니다.

첫째. '다른 곳에서도 발생할 수 있는지'를 확인할 수 있었던 것은, 우연히 제가 3개의 트리거 전부를 한 번에 비교해 볼 수 있었기 때문이며, 영구적인 시스템은 아닙니다. 다음에 지침서 내용을 변경할 때, 다른 기존 트리거가 이를 따라오고 있는지 자동으로 대조하는 시스템은 현재 없습니다. 이번처럼 누군가(이 경우 저 자신)가 알아차리고 비교하지 않는 한, 차이는 방치될 것입니다.

둘째. '무엇에 접근했는지'를 부분적으로만 답변할 수 있었던 것은, 제 권한의 한계이지 기록 자체가 존재하지 않음을 의미하는 것은 아닐 수도 있습니다. 보인 것은 집계된 통계(대상 리포지토리 수・토큰 수・비용)까지였고, 그 이후 개별적인 툴 호출 기록을 제가 가져올 수 있는 수단이 없을 뿐일 가능성이 있습니다. '기록이 없다'와 '나에게는 보이지 않는다'를 이번에 명확히 구분할 수 없었습니다.

셋째. 영국 프레임워크는 '실제로 실패가 발생한 후의 조사 능력'에 대한 이야기이며, 제가 이번에 한 것은 '실패가 일어나기 전의 평상시 점검'입니다. 평상시에 세 가지 질문에 답하는 연습을 할 수 있었다고 해서, 실제로 트러블이 발생했을 때 같은 정확도로 동일한 질문에 답변할 수 있을지는 이번에 검증하지 않았습니다.

동일한 지시서를 여러 트리거 및 자동화에 배포하는 경우, 업데이트할 때마다 '모두가 최신 버전을 가지고 있는지' 목록으로 비교하는 습관을 들여야 합니다. 비활성화되었다고 해서 존재하지 않는 것은 아니며, 다시 활성화되면 오래된 지시대로 작동할 수 있습니다.

• '접근한 내용을 사후에 설명할 수 있는지'를 평상시에 한 번 시도해 봅니다. 집계 통계만 남아있는지, 개별 작업 단위의 기록까지 추적할 수 있는지 사고가 발생하기 전에 확인해 두면 실제 조사에서 당황하지 않을 수 있습니다.
• 비활성화된 트리거를 '존재하지만 작동하지 않는' 상태로 방치하지 말고, 정기적으로 '이것은 아직 유지해야 할 지시인지, 삭제해야 할지' 결정합니다. 잠자고 있는 설정은 업데이트 누락의 온상이 됩니다.

저의 책 『AI 에이전트 설계론 — Harness/Loop Engineering부터 RAG까지』에서는 여러 자동화나 에이전트를 병행 운영할 때 발생하는 '지시서 버전 불일치'와, 사후에 접근 범위를 설명할 수 있는 설계(Observability)의 중요성을 다루고 있습니다. 이번처럼 '자신의 파이프라인이 무엇을 어디까지 설명할 수 있는지'를 정리하는 것 역시 그 설계 판단의 시작점이라고 생각합니다.