2026년 1월에 TOKIUM에 입사하여, QA 팀에서 테스트 자동화에 힘쓰고 있는 ikedan입니다.

지금까지의 기사에서, 저는 Claude를 「또 다른 동료」로 맞이하여, 회고·지식 정리·복수 세션의 병행 등 방어 계층을 하나씩 추가해 왔습니다. 전작 속에서 저는 이 숙제를 예고했습니다. warn의 발생 데이터로부터 오검출률을 측정하여, 어떤 가드를 block으로 격상할지 판별하는 운용에 대해 쓰겠다고 말이죠. 본 기사는 그 숙제의 회수입니다.

전작에서 소개한 「대장에서 다음 작업을 집어내어 별도 세션으로 배정하는」 운용은 지금도 현역입니다. 분위기만 재현하면 다음과 같습니다 (※ 더미 데이터에 의한 재현이며, 실제 조작 화면이 아닙니다).

pickup で次の作業を拾い、dispatch で別セッションへ振る流れの再現（ダミーデータ）

이 dispatch는 대장의 queued 전체에 대해 돌릴 수도 있습니다. orchestrator가 태스크마다 worker 세션을 자동으로 생성하여 모든 태스크를 실행시키고, done이 반환될 때마다 검수해 나가는 흐름입니다 (※ 이 또한 더미 데이터에 의한 재현입니다).

orchestrator が queued 全タスクへ worker セッションを自動起動し、全件 done まで監視・検収するオーケストレーションの再現（ダミーデータ）

솔직히 말하면, 전작의 맺음말에서 예고했던 또 다른 숙제── 「무인으로 일을 계속 뿌리는 완전 자동 루프를 어디까지 사람의 손에서 떼어놓을 수 있을까」──는 본 기사를 집필하는 시점에서도 아직 회수하지 못했습니다. 루프의 메커니즘 자체는 구현·테스트가 완료되었고, 실제로 윈도우를 자동 실행하는 단계까지는 작동합니다. 하지만 안전하게 테스트하기 위한 전제 조건(병행 세션이 적은 「조용한 창」)을, 매일 복수의 세션을 동시에 실행하는 제 운용 환경에서는 오히려 만들기 어려워, 본 작업 투입 판단은 계속 미루고 있습니다. 이 경계선에 대한 숙제는 또 다른 기회에 회수할 예정입니다.

또 하나, 전작 시점에는 아직 없었던 이야기로, dispatch 하는 worker에 어떤 모델을 할당할지도 전작 공개 2일 후(2026년 7월 4일)부터 자동 배분되게 되었습니다. 태스크 종류에 따라 설계·아키텍처 판단과 같은 무거운 판단은 상위 모델로, dispatch 그 자체나 정형 헬스 체크와 같은 기계적인 작업은 하위 경량 모델로, 그 외에는 중간 모델로 종류별로 고정 할당하는 메커니즘입니다 (기본은 가볍게, 필요할 때만 무겁게 한다는 생각입니다). 이 배분 자체의 효과 검증은 아직 진행 중이며, 본 기사의 테마(warn/block의 격상 판단)와는 별개의 축이므로 여기서는 깊게 다루지 않겠습니다.

사전에 차단하는 Hook을 만들기 시작했을 무렵, 저는 단순하게 이렇게 생각했습니다. 위험한 조작 패턴을 발견하면 닥치는 대로 block 하면 된다. 가드는 많을수록 안전할 것이라고.

실제로 해보니, 이것은 틀렸습니다.

가드는 늘릴수록 무시된다

block을 늘릴수록 안전해질 것이라고 생각할지도 모릅니다. 실제로는 반대였습니다.

block을 하나 늘릴 때마다 마찰이 증가합니다. 그리고 오검출 (FP: False Positive)로 인해 정당한 조작까지 막히게 되면, 가드는 그저 방해꾼이 됩니다. 방해꾼은 언젠가 무효화될 수 있습니다. --no-verify로 그냥 통과시키거나, 환경 변수로 통째로 멈추거나, 최악인 것은 「이 가드는 시끄러우니까」라며 삭제되는 것입니다. 너무 많이 막는 가드는 막는 힘 그 자체를 잃습니다.

전작까지 만든 파괴 조작 가드에서도 가장 고생했던 것은 「위험한 문자열」과 「위험한 커맨드」를 구분하는 것이었습니다. grep "rm -rf" file와 같은 검색이나, 커밋 메시지에 우연히 들어간 rm -rf라는 문자열까지 막아버리면 가드는 신뢰를 잃게 됩니다. 파고들면 이것은 오검출과의 싸움이었습니다.

이 「늘릴수록 무시되는」 현상은 QA에 국한된 고민이 아닙니다. Google의 사이트 신뢰성 엔지니어링 (SRE: 대규모 시스템을 안정적으로 운용하기 위한 기술 영역)의 모니터링 장에서도, 「모든 호출 알람은 대응 가능(actionable)해야 한다」고 명시되어 있으며, 오보가 쌓여 대응 피로(Alert Fatigue)에 빠진 현장은 결국 알람 자체를 무효화하게 된다고 적혀 있습니다. 메커니즘으로 폭주를 막는다는 이야기의 선배 격인 분야입니다.

그래서 저는 사고방식을 바꿨습니다. 「막을 수 있는가」가 아니라 「막아서 의미가 있는가」, 「막아도 오검출로 인해 자멸하지 않는가」를 데이터로 확인한 뒤에 결정하기로 했습니다.

그래서 warn부터 시작해서 측정한다

새로운 가드는 원칙적으로 warn부터 시작하기로 했습니다. 또 다른 동료인 Claude를 갑자기 모든 조작에서 구속하는 것이 아니라, 우선 옆에서 상황을 지켜보겠다는 뜻입니다.

당분간은 warn(멈추지 않고 알리기만 함) 상태로 작동시키며, 얼마나 잘못 발화(trigger)하는지, 반대로 얼마나 실제 상황을 놓치는지(miss)를 몇 세션 동안 관찰합니다. 그 후에 정말로 block으로 격상시켜야 할지를 판단합니다.

'측정한다'는 것은 비유가 아닙니다. warn이 발화할 때마다 나의 가드(guard)는 작은 로그(log)로 기록을 남깁니다. 예를 들어 종료 시 체크의 발화는 전용 로그에, 망가진 도구 호출(tool call)의 탐지는 별도의 로그에, 모수(그 사이에 작동한 도구 호출의 총수)와 세트로 쌓여갑니다. 발화의 절대수만 봐서는 의미가 없기 때문에, 모수와 나란히 배치하여 비율로 볼 수 있도록 해두었습니다.

사실, 횟수를 세어서 '임의의 메모에서 필수 규칙으로 승격시킨다'는 발상 그 자체는 사내의 선행 기사 ── 맛상(まっさん)의 「학습하는 기억의 3층 구조」 ── 에서 배운 것입니다. 본 기사의 warn에서 block으로의 격상은, 그 승격을 막연한 추측이 아니라 오탐지율(false positive rate)이라는 척도로 측정하며 판단해 보려는 시도이기도 합니다.

이 "효과가 있을 것으로 예상되지만 바로 투입하지 않고, warn으로 측정해 본 뒤 block으로 만든다"라는 단계는, 첫 번째 기사에서 쓴 "만든 즉시 시운전한다"라는 발상의 운영 버전이기도 합니다.

측정해 보니, 네 가지 결말로 나뉘었다

실제로 warn으로 측정하여 격상을 판단한 결과, 가드는 크게 네 가지 결말로 나뉘었습니다.

순서대로 적겠습니다.

결말 ① 6건은 warn 상태로 유지했다

측정한 결과, 격상할 가치가 없었던 것이 6건 있었습니다.

• 종료 시 마무리 누락·독립 검증 누락을 촉구하는 경고: 애초에 관측이 불완전합니다. "다른 수단으로 완료를 검증한 흔적이 있는지"를 보고 싶은데, 대화 이력은 압축이나 교체로 인해 일부만 추적할 수 있어 오탐지 클래스를 완전히 닫을 수 없습니다. 그래서 block으로 만들지는 않고, 경고가 일정 횟수 쌓이면 "이 가드를 block으로 올릴지 재평가하라"는 작은 표식(tripwire)만을 자동으로 추가하며, 강제할지 여부는 로그가 쌓인 후에 결정하도록 단계적으로 도입했습니다. -
• 다른 세션과의 동시 편집 경고: 전작에서 썼듯이, 애초에 다른 세션을 멈출 권한이 없습니다(이는 구조상의 엄격한 제약입니다). 게다가 PreToolUse에서 "허가"를 반환해 버리면, 허가 플로우를 단축하여 대상 편집을 무조건 통과시켜 버립니다. 그래서 "알리기만 하는 것"에 철저히 집중합니다. -
• 판단 떠넘기기를 방지하는 가드 (이 글을 쓰고 있는 지금도, 나의 세션에는 매번 이것이 나타납니다): 멈추는 방식에는 deny를 사용하고 있지만, 같은 질문을 다시 던지면 통과되며, 1세션당 정지 횟수에도 상한을 두어 가드 스스로가 다운되면 묵묵히 통과(fail-open)하도록 하고 있습니다. block도 warn도 아닌 "마찰이 있는 warn"이라고라도 불러야 할 형태로, 완전한 벽으로 만들지는 않았습니다. -
• 망가진 도구 호출의 리셋 권장: AI가 내보내는 도구 호출 형식 자체가 망가져 있는 경우, 그것은 애초에 PreToolUse에 도달하기 전에 차단됩니다. 기계적으로 개입할 수 있는 경로가 종료 시의 경고밖에 남아있지 않은 데다, "일단 리셋하면 고쳐진다"라는 대책 자체도 미증명 상태이므로, 강제하지 않고 권장에 머물러 있습니다. -
• 동일 브랜치에서 병행하는 커밋의 폭넓은 탐지: 여러 세션이 같은 브랜치에서 병행하고 있다는 주의 신호가 쌓이면, 기계적인 deny로 격상해야 할지를 지속적으로 측정하고 있는 가드입니다. 신호가 떴던 시간대와 실제로 문제가 발생한 시간대를 대조하여 상관관계를 다시 분석해 보았으나, 일치하는 결과는 보이지 않았습니다. 이 글을 쓰고 있는 오늘 진행한 재평가에서도 동일한 결론(보류)을 다시 확인했습니다. "예전에 측정해서 결정했다"가 아니라, 그때마다 다시 측정하여 동일한 결론에 도달하고 있다는 점이 다른 warn 유지 그룹과는 조금 다릅니다. -
• 위임 판단(큰 조사는 외부 도구로 넘겨야 한다는 선언)을 촉구하는 세션 종료 시의 뒷받침: 세션이 끝날 무렵에만 내보낼 수 있는 성질상, "그 자리에서 다시 하게 만들기"가 불가능합니다. 그래서 처음부터 block이 아니라, 1세션당 한 번씩만 살짝 알려주는 형태로 남겨두고 있습니다.

공통점은, 관측이 불완전하거나, 멈출 권한이 없거나, 대책의 효과가 미증명되었거나, 애초에 그 타이밍에는 "재시도"를 강제할 수 없는 것들은 block으로 올리지 않는다는 선긋기입니다.

결말 ② 3건, block으로 격상했다

반대로, 격상할 가치가 있는 증거가 모인 것은 3건을 block으로 올렸습니다.

하나는, 병행 작업의 이중 확보를 방지하는, 좁게 압축된 가드(guard)입니다. 여러 세션이 동일한 태스크를 두고 다툴 때, "장부에 이미 기록된 선행 확보(claim)를, 나중에 알지 못하고 다시 확보하는 것"이라는 구체적인 경로만을 차단합니다. 독립된 별도의 에이전트에 의한 적대적 리뷰(adversarial review)를 통해 이 경로를 차단 대상으로 지목하여 특정하였고, 그 과정에서 발견된 5건의 구멍(과잉 차단·판정 누락)을 시정했습니다. 게다가 동일 ID의 재확보·죽은 세션으로부터의 인계·재출시·횟수 상한 등, 네 가지의 퇴로를 남겨둔, 범위를 좁게 압축한 block입니다.

또 하나는, 외부에 불가역적인 부작용을 일으키는 단어의 검지입니다. 태스크명에 「과금」 「결제」 「drop table」 「truncate」 「webhook」 등이 포함되어 있고, 동시에 자동 실행 경로에 올라타 있는 경우에만 사람의 승인을 거치도록 합니다. 이것들을 선택한 이유는 실제 로그에서 오검지(false positive)가 거의 제로였을 뿐만 아니라, 만일 놓쳤을 때의 결과(결착)가 최대치(돈을 움직임·테이블을 삭제함·외부로 전송함)이기 때문입니다.

또 하나는, ①에서 "경계는 하되 멈추지는 않는다"로 유지했던, 동일 브랜치 병행 커밋(commit)의 검지와 뿌리가 같은 가드입니다. 다만 이쪽은 조건을 극단적으로 좁혀서, 「파일을 지정하지 않은 통째로의 commit」이면서 「그 자리에 함께 있던 다른 세션이 건드린 파일과, 앞으로 커밋할 파일이 실제로 겹치는 경우」라는 2가지 조건이 동시에 성립할 때만 block 합니다. 파일을 지정한 commit이나 다른 세션과 무관한 commit은 항상 통과됩니다. 똑같은 "병행 커밋에 대한 경계"라도, 넓고 느슨한 판정은 warn 상태로 유지하고, 좁고 물적 증거를 확보할 수 있는 판정만을 block으로 격상시켰다는 것이 실태입니다.

둘 다, "위험하니까"가 아니라 "측정해 보니 오검지가 낮고, 또한 놓쳤을 때의 대가가 크기 때문에" 격상했습니다. 숫자로 before → after를 나열하면 다음과 같습니다.

결말 ③ "확실하게는 맡길 수 없다"며, 격하·유지시킨 것

그리고 일단 block이나 완전 자동화를 노렸으나, 측정 결과 "이것은 확실하게는 맡길 수 없다"고 판단하여 격하하거나 유지시킨 것도 있습니다.

외부 부작용을 검지하는 단어 리스트는 적대적 검증을 거친 결과, 양방향으로 틀릴 수 있음이 밝혀졌습니다. 「PR을 작성」과 같이 조사가 들어간 표현을 놓치는 한편(FN), 「메일……의 관점」이라는 사내 테스트 항목명을 외부 전송으로 착각하여 과도하게 차단(FP)합니다. 둘 다 단어의 표면적인 형태에 의존하고 있어 사람의 판단을 대체할 수 없습니다.

그래서 이 검지는 "확실한 block"이 아니라 **best-effort (할 수 있는 범위 내에서)**라고 명문화하였고, 확실히 차단하고 싶을 때는 사람이 태스크에 명시적인 플래그를 세우는 운용에 맡겼습니다. "이론상으로는 차단할 수 있을 것이다"를 측정하여 "다 차단할 수 없다"고 인정하고, 솔직하게 내려놓은 사례입니다.

방향이 다른 「보류」도 있었습니다. 태스크 할당부터 기동까지를 완전히 무인으로 돌리는 자동화를 일단 목표로 했습니다. 하지만 실제로 자식 프로세스(Child Process)를 기동하여 진짜 데이터를 쓰는 일련의 흐름은, 테스트에서는 가짜 부품으로만 재현할 수 있었고 실환경에서는 검증하지 못했습니다. 미검증 상태로 전자동(Full Automation) 단계로 올리는 것은, 제가 가장 주의하고 있는 「검증 없는 완료」 그 자체입니다. 그래서 기계가 후보를 고르고, 사람이 기동하는 한 단계 전의 형태로 유지했습니다. 이것은 「강등」이 아니라, 확증을 얻을 때까지의 「승격 보류」입니다.

결말 ④ 승격→되돌리기→재승격 과정을 거쳐 block에 안착했다

삼분류 중 어디에도 깔끔하게 들어맞지 않는 것이 딱 1건 있었습니다. 제품 브랜치(Product Branch)로의 잘못된 체크아웃(Checkout)을 막는 가드입니다.

처음에는 warn(실제로 오염 인시던트가 발생한 직후의 응급처치)으로 시작하여, 얼마 후 block으로 승격시켰습니다. 그런데 그 승격을 독립된 별도의 에이전트(Agent)에게 적대적으로 리뷰하게 했더니, 오검출(False Positive)과 판정을 빠져나가는 회피책이 모두 발견되었습니다. 그래서 일단 block을 철회하고, warn 상태로 되돌렸습니다. 판정식을 오검출을 일으키지 않는 형태로 다시 만든 후, 다시 한번 block으로 승격시켰습니다. 그것으로 끝이 아니라, 그 후에도 추가적인 적대적 검증을 실시한 결과, 커맨드(Command) 작성 방식을 바꾼 또 다른 우회로가 발견되어 그때마다 수정하며 현재도 block으로서 작동하고 있습니다.

일직선으로 「warn→측정→block」으로 진행된 다른 2건과 달리, 이것은 승격한 후에도 적대적 검증을 멈추지 않았기에 구멍을 메우면서 block을 유지할 수 있었던 사례입니다 (②의 또 다른 1건인 병행 커밋의 협역 검출은 애초에 한 번도 되돌리지 않았습니다). 측정하고 끝내는 것이 아니라, 승격한 후에도 계속해서 측정할 필요가 있다는 의미에서, ③의 「측정해도 알 수 없는 것의 한계」와 유사한 교훈을 담고 있습니다.

이 기사의 하이라이트 ── 「전송」을 막으려 했더니, 버튼 이름에 부딪혔다

외부에 부작용(Side Effect)을 내는 태스크를 막고 싶다고 생각했을 때, 제가 처음에 작성하려 했던 리스트에는 일본어 동사도 포함되어 있었습니다. 「전송(送信)」「송부(送付)」「통지(通知)」「게시(投稿)」. 외부로 무언가를 내보내는 조치의 대표격들입니다.

그런데 실제 로그에서 오검출을 세어보니 상황이 달랐습니다.

우리가 만들고 있는 것은 경비 정산·청구서 프로덕트(Product)입니다. 화면에는 「전송」 버튼이 있고, 「통지」 설정이 있으며, 테스트 항목에는 「메일 송부 관점」, 「통지 표시」 같은 이름들이 나열됩니다. 「전송」, 「통지」라는 단어는, 막고 싶은 외부 조작과 막고 싶지 않은 QA 작업 대상 사이에서 구분이 되지 않았습니다. 로그에 남은 발화를 정성적으로 대략 세어보니, 오검출은 「통지」가 6건, 「전송」과 「송부」가 각각 2건으로 무시할 수 없는 숫자였습니다.

반면, 영어의 기호적인 단어나 불가역적인 금융·파괴 관련 단어는 오검출이 거의 제로였습니다. 「drop table」이나 「truncate」를 무심코 태스크명에 쓰는 일은 거의 없고, 「과금」, 「결제」도 QA 화면 라벨과는 충돌하지 않습니다.

그래서, 같은 「외부로 내보내는 단어」라도 오검출률에 따라 선별하여, 높은 FP(False Positive)를 보이는 일본어 동사는 의도적으로 리스트에서 제외했습니다. 만약 측정하지 않고 「외부로 내보낸다면 전부 막는다」라고 단순하게 구성했다면, QA의 정상적인 작업 때마다 가드가 발화하여 가장 먼저 무효화되었을 것입니다.

이 사건은 저에게 상징적이었습니다. 위험함은 단어의 의미로 결정되지 않는다. 자신의 환경에서 실제로 얼마나 잘못 맞느냐로 결정된다. 그것은 책상 위에서는 알 수 없는 것이었습니다.

측정해도 알 수 없는 것 ── 이 운용의 한계

지금까지 「측정하고 나서 결정한다」라고 써왔지만, 지킬 수 있는 것만 쓰면 신뢰할 수 없는 기사가 되기에, 측정해도 알 수 없는 것도 써두겠습니다. 한계는 명확히 세 가지가 있습니다.

첫 번째는, 「율(Rate)」이라고 말해도 대개 분모가 없다는 점입니다. 예를 들어 제가 가장 재발이 잦은 검출기는 과거에 92건의 경고(Warning)를 냈으나, 독립적인 세 가지 관점에서 재검토한 결과 그중 약 88%가 구조적인 오검출(False Positive)이었습니다. 하지만 이 「약 88%」는 건수를 하나씩 정성적으로 분류한 근사치일 뿐, 정밀한 통계치는 아닙니다. 별도의 감사에서는 "개선율을 내려고 해도 분모(본래의 모수)가 없어 효과를 엄밀하게 측정할 수 없다"라고까지 지적되었습니다. 측정했다고는 해도, 대부분은 근사와 정성에 머무는 것이 솔직한 심정입니다.

다만, 분모를 확보할 수 있는 상황에서는 warn 상태로 두더라도 내용을 견고하게 만드는 것만으로도 효과가 있습니다. 테스트 항목의 「1개 케이스에 기대값이 복수 존재」하는 것을 검지하는 체크를 2,093건의 실제 데이터에 적용했을 때, 처음에는 위반율이 9.56%였으며 그 대부분이 오검출이나 경계값 문제였습니다. 그래서 block으로 격상시키지 않고, warn 판정 로직에서 구조적인 오검출을 차례로 제거해 나갔더니 위반율은 5.64%까지 떨어졌습니다. block으로 올리기 전에, warn 측의 정밀도를 높인다는 선택지가 가장 수수하면서도 가장 효과적일 때가 있습니다.

두 번째는 자기 참조의 오염입니다. 자신의 가드(Guard) 효능을 자신의 세션에서 측정하면, 관측 그 자체가 거동을 바꾸어 버립니다. 실제로 망가진 도구 호출(Tool Call)을 조사하던 중에, 그 망가진 호출을 저 자신이 몇 번이고 반복해서 재발시키고 말았습니다. 측정하고 있는 대상에, 측정하고 있는 자기 자신이 영향을 주게 되는 것입니다.

세 번째는 기준선이 고정되어 있지 않다는 점입니다. 가드는 지금도 개수 중이며, warn과 block의 경계는 측정할 때마다 움직입니다. 이번에 block으로 올리지 않았던 것이 로그가 쌓이면 올라갈 수도 있고, 그 반대의 경우도 있습니다. 이것은 「한 번 정하면 끝」이 아니라, 계속해서 측정해 나가는 운용입니다.

마치며 ── 전달하기·정돈하기·멈추기·피하기·측정하기

5편의 기사를 연결하면 다음과 같습니다.

「위험한 것은 전부 block으로 만들면 된다」라고 생각했으나, 막상 측정해 보니 격상할 가치가 있는 것은 3건, 6건은 warn 상태로 유지, 2건은 솔직히 격하되었으며, 나머지 1건은 승격과 반려를 반복한 끝에 block에 안착했습니다. 방어를 추가하는 것 자체가 목적이 되어가던 저에게 이는 다소 의외의 결과였습니다. 강한 힘을 늘리는 것보다, 늘린 힘이 잘못하여 자신을 옭아매지 않는지를 측정하는 것이 결국 방어를 더 오래 지속시킨다. 그것이 warn에서 시작하여 측정한다는 수수한 절차의 가장 큰 효용이었습니다.

인간과 AI가 함께 품질을 지키는 시대에, 가드는 「얼마나 강하게 막을 수 있는가」로 평가받기 쉽습니다. 하지만 실제로 효과를 발휘하는 것은, 막은 뒤에 자신의 작업을 망가뜨리지는 않는지, 잘못하여 방해꾼이 되지는 않는지를 데이터로 계속 확인하는 신중함일지도 모릅니다.

다음에는 지금까지의 가드로는 닿지 않는 영역 ── 망가진 도구 호출이나 판단을 통째로 맡겨버리는 것처럼, PreToolUse의 Hook으로는 기계적으로 다 막을 수 없고 AI 자신의 생성 측 규율로만 좁힐 수 있는 구멍에 대해 또 다른 기사로 써보도록 하겠습니다.