그날의 숫자
| 지표 | 값 | 출처 |
|---|---|---|
| 보안 경계 축(W005) 세션 | 403 | AX_AI_USAGE_WORKFLOW_PATTERNS.csv (W005) |
| 그 안 프롬프트 총량 | 666 | 동 CSV |
| 도구 실행 누적 | 48,067 | 동 CSV |
| 실패 누적 | 8,780 | 동 CSV |
| permission 실패 | 874 | E002 failure_category_counts |
| error / timeout / nonzero_exit | 3,115 / 2,549 / 1,949 | E002 |
| exception / fatal | 227 / 55 | E002 |
데이터 출처: AX_AI_USAGE_WORKFLOW_PATTERNS.csv W005 라인 + AX_AI_USAGE_SEMANTIC_ANALYSIS.json derived_metrics — Chart 02_sessions_over_time hook 자리, 본 회는 보안 축 단일 절단면.
무슨 일이 있었나
이 축의 프롬프트들은 평균보다 짧지 않다. 오히려 길다. OWASP Top 10 매트릭스를 작성하라, RLS 18/18 활성 여부를 검증하라, AES-256 사업자번호 암호화의 키 로테이션 정책을 점검하라, 에이전트 production failure mode 카탈로그를 mitigation 매핑까지 포함해 카테고리별로 정리하라 — Operator P 가 던진 명령은 한 줄짜리 호기심이 아니라, 외부 송부 직전의 마지막 점검 같은 형태다.
문제는 그 점검을 받아 든 에이전트가 매번 통과만 하지 않았다는 데 있다. 어떤 명령은 거부됐고, 어떤 명령은 거부됐어야 했는데 통과했다. 그 두 경우 모두 로그에는 같은 한 줄이 남는다. exit code, stderr, retry, 그리고 다음 프롬프트.
[W005 / 보안·시크릿·검증 경계]
sessions : 403
prompts : 666 (avg 1.65 prompts/session)
tool_calls : 48,067 (avg 119.3 calls/session)
failures : 8,780 (avg 21.8 failures/session)
failure_rate : 18.3% per tool call
세션당 도구 호출 119회, 그 중 22회가 어떤 형태로든 실패한다. 5번 중 1번 가까이가 막힌다는 뜻이다. 이게 보안 축의 정상 상태였다. 빨간 줄이 안 뜨면 오히려 검증을 안 한 거였다.
실패 카드 한 장
E002 가 정리한 실패 분류 7종은 무게가 다 다르다.
error 3,115 (35.5%) ← 일반 도구 오류
timeout 2,549 (29.0%) ← 응답 안 옴
failure 2,378 (27.1%) ← 명시적 실패 신호
nonzero_exit 1,949 (22.2%) ← 프로세스 비정상 종료
permission 874 ( 9.9%) ← 거부됨
exception 227 ( 2.6%) ← 미처리 예외
fatal 55 ( 0.6%) ← 복구 불가
(합계가 100% 를 넘는 이유는 한 실패가 다중 라벨을 받기 때문이다 — nonzero_exit AND permission 같은 조합)
permission 874건. 이 숫자가 본 축의 살아 있는 신호다. 다른 카테고리는 망가진 도구의 문제일 수 있다. permission 만은 다르다. 거부 자체가 정책이 작동했다는 증거이고, 동시에 그 거부를 우회하려는 다음 시도가 시작될 자리이기도 하다.
본 축의 한 세션은 이렇게 흘렀다. 첫 시도가 permission denied 로 막힌다. 두 번째 시도에서 Operator P 가 권한 컨텍스트를 바꾼다. 세 번째 시도가 nonzero_exit 으로 떨어진다. 네 번째 시도가 통과한다 — 그런데 통과한 그 명령이, 원래 거부됐어야 할 명령이었다는 걸 알아채는 사람은 그 세션 안에 없다. 그 다음 주, 다른 세션에서 누군가가 같은 패턴을 다시 발견하고 retroactive 하게 secret 노출을 redact 한다.
874건의 permission 중 몇 건이 건강한 거부 였고 몇 건이 우회된 거부 였는지, 본 데이터는 분리해 주지 않는다. 그게 본 축이 다음 분기 작업으로 넘기는 가장 무거운 빚이다.
그날의 깨달음
- permission denied 는 종착점이 아니라 분기점이다. 874건은 stop 의 숫자가 아니라, 다음 시도로 들어간 진입의 숫자에 가깝다. 보안 운영을 측정할 때 거부 카운트만 자랑하면 안 되는 이유 — 거부 직후 통과까지의 시간차와 컨텍스트 변경 흔적이 진짜 지표다.
- 도구 호출 1회당 실패율 18.3% 는 노이즈가 아니라 워크플로 자체다. 보안 축은 빨간 줄이 안 뜨면 검증을 안 한 것이다. 다른 축에서 이 수치는 alarming 하지만 W005 에서는 baseline 이고, baseline 이 낮아지면 오히려 의심해야 한다 — 모형이 거부를 시뮬레이션만 하고 실제로 막지 않을 가능성.
- 본 축의 실패 로그는 다음 작업의 입력값으로 재사용되어야 한다. E002 의 핵심 주장이 그것이다 — "실패는 버려진 로그가 아니라 다음 작업 조건으로 재사용되는 데이터였다." 본 축에서는 그 명제가 가장 직접적으로 작동한다. permission denied 의 컨텍스트를 다음 세션의 system prompt 에 negative example 로 박는 루프가 없으면, 같은 우회 패턴이 같은 자리에서 다시 일어난다. 본 데이터가 그것을 증명한다 — 세션은 403개지만 패턴은 그보다 훨씬 적었다.
다음 날
다음 날, Operator P 는 본 축 데이터를 보고 두 가지를 정했다. 하나는, permission denied 직후 60초 안에 일어난 retry 의 컨텍스트 diff 를 별도 인덱스로 뽑아 두기. 다른 하나는, 보안 축 세션의 시스템 프롬프트에 지난 7일간 본 워크스페이스에서 우회된 거부 패턴 을 negative example 로 자동 주입하기.
두 가지 모두 본 회 시점에는 아직 구현되지 않았다. 다만 8,780건의 실패 중 적어도 874건은 원래 다음 시도의 입력값이 됐어야 할 데이터 였다는 자각 하나는, 본 축이 본 분기에 남긴 가장 또렷한 산출이다.
거부당했어야 할 명령이 한 번이라도 통과했다면, 그 한 번을 발견하는 비용은 통과시킨 비용보다 훨씬 크다. 본 축이 알려준 건 그 비용의 자릿수였다 — 세션 403개, 실패 8,780건, 그리고 그 사이 어딘가에 있는 알 수 없는 우회 1건.
Editor's note: 본 회의 모든 수치는 AX_AI_USAGE_WORKFLOW_PATTERNS.csv W005 라인 및 AX_AI_USAGE_SEMANTIC_ANALYSIS.json derived_metrics 실측. permission 거부 / 우회 / retroactive redact 의 비율 분해는 본 데이터로는 분리되지 않으며, "874건 중 몇 건이 우회됐는가" 는 본 회의 narrative 일반화 (실 데이터로는 미분리). 5월 중순의 별건 시크릿 incident 는 본 회에서 의도적으로 다루지 않음 (hold). 사람·회사·repo·도메인·키 실명은 codename 정책에 따라 0건.
