컴플라이언스 대시보드가 0%를 보여줄 때, 그게 정말 문제일까 센서가 문제일까
여러 서브에이전트를 병렬로 띄우고 그 결과를 하나로 합치는 fan-out 구조를 프로덕션에 쓰고 있다면, 그리고 “병합 전에 반드시 검증 단계를 거친다”는 규칙을 어딘가에 문서로 박아뒀다면, 이 글을 읽어야 합니다. 자체 프로덕션 코딩 에이전트 하네스에서 이 규칙의 실제 준수율을 세어봤더니 5%가 나왔고, 그 수치가 개선됐는지 확인하려던 후속 실험은 데이터를 단 한 건도 반환하지 못했습니다. 두 사건 모두 규칙이 지켜지지 않아서가 아니라, 지켜진 사실을 측정할 통로 자체가 없었기 때문에 벌어졌습니다. 이 논문은 그 간극에 이름을 붙이고, 왜 조용한 대시보드가 “괜찮다”는 신호가 아니라 답이 두 개인 질문인지를 보여줍니다.
5%라는 숫자, 무엇을 증명하는가
병렬로 여러 서브에이전트를 디스패치해 결과를 병합하는 fan-out 패턴은 구조적으로 위험합니다. 각 브랜치의 오류가 병합 과정에서 세탁돼, 합쳐진 결과물은 실제보다 더 확신에 찬 것처럼 보이고 어느 브랜치가 틀렸는지 알려줄 자연스러운 시점이 사라집니다. 그래서 많은 프로덕션 하네스가 “병합 전에 반드시 검증 스테이지를 거친다”는 규칙을 채택합니다. 이 논문이 다루는 팀도 마찬가지였습니다. 다만 이 규칙을 몇 달째 운용한 뒤 당연한 질문을 던졌습니다. 실제로 지켜지고 있는가.
세는 방식은 단순해 보였습니다. 폐쇄가 일어날 때마다 원장에 영수증이 남고, fan-out 디스패치는 세션 트랜스크립트에 전부 기록되니 두 수를 나누면 준수율이 나옵니다. 1,877개의 프로덕션 세션을 훑자 fan-out 디스패치 이벤트 180건 중 영수증이 남은 것은 9건, 5.0%였습니다.
프로덕션 세션 1,877개를 감사한 결과입니다. fan-out 디스패치 180건 중 영수증이 남은 것은 9건(5.0%)이었고, 나머지 171건은 준수 여부를 알 수 없는 상태로 남았습니다.
이 5%를 어떻게 읽어야 할지에는 몇 가지 해석이 있습니다. 첫 번째 해석은 규칙이 95%의 경우에 무시됐다는 것입니다. 두 번째는 검증이 실제로 자주 일어났지만 기록되지 않았다는 것입니다. 원래 흐름에서 영수증을 남기려면 JSON 검증 기록을 직접 작성하고, kill/keep 임계값을 정하고, 로깅 스크립트를 수동으로 호출하는 등 다섯 단계를 거쳐야 했는데, 이미 검증 자체는 끝났다고 느끼는 순간에 이 절차를 자발적으로 완주할 사람은 거의 없습니다. 세 번째는 측정 자체가 어디서 어떻게 봤는지에 따른 산물이라는 것입니다. 이 논문이 만든 프레임워크로 보면, 대시보드가 보여준 숫자는 이 세 가지 중 어느 것도 구분해주지 않습니다.
계측 편향: 규칙이 있다는 것과 측정 가능하다는 것은 다르다
논문은 이 현상에 계측 편향(instrumentation bias)이라는 이름을 붙입니다. 실제로 검증이 일어났는지를 나타내는 지표 C_true와, 감사자에게 그 영수증이 보이는지를 나타내는 지표 C_obs를 따로 정의하고, 그 기댓값의 차이 Δ를 계측 편향으로 정의합니다. 이 시스템에서는 영수증이 남았다면 검증이 실제로 일어났다는 것을 확실히 보장하지만, 그 역은 성립하지 않습니다. 대화 도중에 즉흥적으로 검증했거나 운영자가 결과를 눈으로 훑어본 경우처럼, 영수증 없이도 검증이 일어날 수 있기 때문입니다. 그래서 Δ는 구조적으로 항상 0 이상이고, 대시보드에 찍힌 준수율은 진짜 준수율의 하한선일 뿐입니다. 이 비대칭성이 위험한 이유는, 낮은 대시보드 수치가 항상 실제로는 준수율이 높은 상황과도 양립 가능하기 때문입니다. 대시보드만으로는 프로세스가 망가진 것인지 센서가 망가진 것인지 구분할 수 없습니다.
논문은 Δ가 벌어지는 경로를 세 가지 메커니즘으로 나눕니다. 수작업 마찰(manual-step friction)은 로깅 절차가 있다는 걸 알고 기꺼이 따르려는 의지도 있지만, 검증이 이미 끝난 시점에 그 절차가 상대적으로 너무 비싸게 느껴지는 경우를 말합니다. 도구 인지 격차(tooling-awareness gap)는 디스패치하는 순간 오케스트레이팅 모델의 주의가 본질적인 작업에 쏠려 있어 거버넌스 절차를 떠올릴 여유가 없는 경우입니다. 가장 다루기 까다로운 유형은 실행 범위 불일치(scope-parity gap)입니다. 검증도 실제로 일어났고 영수증도 정확히 남았는데, 감사 장비가 다른 호스트나 컨테이너, 네트워크 파티션에서 돌아가느라 아무것도 못 보는 경우입니다. 대시보드에 나타나는 신호가 완전한 비준수와 구분되지 않는다는 점에서 세 유형 중 가장 위험합니다.
개념을 정리한 개략도로 수치를 담고 있지 않습니다. 행동 준수가 관측 가능해지려면 영수증이 남고(방출) 그 영수증이 감사자에게 수집돼야 하는데, 마찰과 인지 격차는 방출 단계를, 범위 불일치는 수집 단계를 각각 억제합니다.
여기서 논문이 강조하는 구분이 하나 있습니다. 계측 편향은 굿하트의 법칙(측정이 목표가 되는 순간 그 측정은 의미를 잃는다)과는 다른 문제입니다. 굿하트 현상은 지표가 계속 생산되지만 그 생산 과정 자체가 왜곡되는 타당성(validity) 문제이고, 계측 편향은 지표가 정확하게 생산됐을 때는 신뢰할 만하지만 애초에 충분히 자주 생산되지 않거나 감사자가 닿을 수 없는 곳에서 생산되는 완전성(completeness) 문제입니다. 그래서 대응 방향도 정반대입니다. 굿하트 편향에 맞설 때는 좋아 보이는 지표를 의심해야 하지만, 계측 편향에 맞설 때는 나빠 보이거나 아예 아무것도 보이지 않는 지표를 의심해야 합니다.
실측: 원인 규명, 그리고 두 번째 실패
같은 날 팀은 두 갈래 개선을 배포했습니다. 다섯 단계짜리 수동 흐름을 plan과 tally 두 개의 명령으로 대체해 임계값 판정과 중복 제거, 검증 집계를 사람의 판단이 아니라 결정론적 코드가 담당하도록 옮겼고, 디스패치 시점에 자동으로 발동하는 훅을 붙여 fan-out이 일어나는 바로 그 순간에 영수증 절차를 상기시키도록 했습니다. 각각 마찰 메커니즘과 인지 격차 메커니즘을 정확히 겨냥한 조치였습니다.
이 개선이 실제로 폐쇄율을 끌어올렸는지 확인하기 위해 팀은 훅이 배포된 시각을 기준으로 이전 구간과 이후 구간을 나누고, 두 구간의 영수증 비율을 이표본 비율 검정으로 비교하는 전/후 자연실험을 설계했습니다. 그런데 재실행 결과는 양쪽 구간 모두 관측치가 0건이었습니다. 세션 파일도, 디스패치 호출도, 원장 항목도 전부 0으로 나왔고, 두 z통계량은 계산 자체가 불가능한 상태(undefined)였습니다.
원인은 감사 장비 자체의 범위 불일치였습니다. 세션 트랜스크립트는 대화형 세션을 돌리는 머신의 로컬 홈 디렉터리 아래에 기록되는데, 이 재실행 스캔은 별도의 배치 컴퓨트 노드에서 실행됐고 그 노드에는 애초에 해당 디렉터리 자체가 존재하지 않았습니다. 글롭 패턴이 빈 집합으로 확장됐고, 그 이후의 모든 집계가 결정론적으로 0을 상속받았습니다. 더 까다로운 점은 이 실패가 조용했다는 것입니다. 잡은 에러 없이 정상 종료됐고, 모든 필드에 0을 보고했습니다. 이는 정말로 아무도 검증을 닫지 않았을 때 나올 법한 모양과 정확히 같습니다. 스캔 로직도, 윈도우 파라미터도, 통계 설계도, 원장 경로도 전부 올바랐습니다. 코드 리뷰가 점검할 수 있는 모든 구성 요소가 멀쩡했는데도 결과는 텅 비었습니다. 감사자가 감사 대상과 같은 곳에 서 있는지는 어떤 단위 테스트도, 어떤 코드 리뷰도, 스캐너를 작성한 모델의 추론 과정도 잡아낼 수 없는 배포 속성이었기 때문입니다.
이 결과가 남기는 세 가지 함의
이 사고는 세 층위에서 각각 다른 교훈을 남깁니다. 회사 차원에서는, 자체 하네스의 fan-out 검증 준수율을 정량화하면서 “규칙이 있다”는 것과 “규칙이 계측돼 있다”는 것을 분리해서 검증해야 한다는 실무 지침이 도출됩니다. 정책 설계 단계에서 이 둘을 같은 것으로 취급하면, 실제로는 잘 지켜지고 있는 프로세스를 망가졌다고 오판해 과도하게 손을 대거나, 반대로 아무도 지켜보지 않는 시스템을 건강하다고 착각하는 두 가지 실패 모두를 반복하게 됩니다.
사회적으로는 AI 감사·규제 논의에 던지는 시사점이 있습니다. 최근 부상하는 기계 판독 가능한 컴플라이언스 프레임워크는 원장에 도달한 증거의 가치를 높여주지만, 애초에 생성되지 않았거나 수집되지 않은 증거에 대해서는 아무것도 해주지 않습니다. 오히려 결과가 더 그럴듯하고 권위 있어 보이게 만들 뿐, 더 완전하게 만들지는 못합니다. 그래서 이런 프레임워크는 준수율 수치 옆에 “감사자가 실제로 어느 범위까지 관측할 수 있었는가”를 나타내는 커버리지 메타데이터를 필수 항목으로 함께 실어야 한다는 것이 이 논문의 제안입니다.
과학적으로는 자율 에이전트 하네스의 새로운 실패 모드를 정식화했다는 점이 핵심입니다. 계측 편향을 세 가지 메커니즘으로 분해하고, 굿하트 현상과 구분하고, 실제 프로덕션 세션 로그(수천 세션, 수백 건의 fan-out) 기반 전/후 자연실험으로 이를 측정하는 프로토콜을 제시했습니다. 다만 그 프로토콜을 실행에 옮긴 첫 시도가 스스로 프레임워크가 예측한 세 번째 메커니즘, 즉 범위 불일치의 실사례가 됐다는 점이 이 논문에서 가장 설득력 있는 대목입니다. 계측 편향의 분류를 막 정리한 팀이 바로 그 실패를 자기 손으로 재현한 셈이기 때문입니다.
한계와 다음 단계
이 연구는 단일 팀의 단일 프로덕션 하네스만 다룹니다. 5.0%라는 수치는 그 시스템, 그 시기의 도구 사용성을 반영한 값일 뿐 다른 곳에서도 비슷하게 나타난다고 주장하지 않습니다. 일반화할 수 있다고 주장하는 것은 수치가 아니라 프레임워크와 세 가지 속성(존재·계측·범위 일치)을 나눠 점검해야 한다는 구조적 원칙입니다.
더 근본적인 한계는 자연실험 재실행이 실패하면서 개선 조치의 실제 효과를 검증된 수치로 보고하지 못했다는 점입니다. 이 논문은 개선 전 기준선과 범위 불일치라는 실패 모드의 실증만 확보했을 뿐, 두 명령 도구와 디스패치 훅이 폐쇄율을 실제로 끌어올렸다고는 아직 말할 수 없습니다. 또한 진짜 준수 여부(C_true)를 독립적으로 확인해줄 오라클이 없어서 Δ는 정의는 명확하지만 아직 추정할 수 없는 이론적 양으로 남아 있고, 전/후 비교 설계 자체도 “기록이 쉬워져서 늘어난 준수”와 “관측되는 것을 의식해서 실제로 늘어난 준수”라는 두 채널을 구분하지 못한다는 구조적 약점을 안고 있습니다. 다음 단계로는 대화형 세션과 같은 범위에서 실행되는 스캐너로 재실험을 다시 돌리고, 세션 파일을 0건 찾았을 때는 조용히 0을 보고하는 대신 크게 실패하도록 하는 생존성 검증(liveness assertion)을 추가하는 작업이 최우선 과제로 제시됩니다. 그 이후에는 다른 프로덕션 하네스로 프로토콜을 확장하고, 영수증 없는 fan-out 이벤트를 사람이 표본 추출해 직접 검토하는 오라클을 구축해 Δ를 추정치가 아닌 보정된 값으로 전환하는 것이 목표입니다.