왜 포스트모텀에서 발견된 문제가 다음번에도 똑같이 발생할까?

3주 동안 아무도 눈치채지 못한 anon_guest bypass가 있었다. 포스트모텀에서 원인을 쫓다 발견했다. “어떻게 이걸 놓쳤지?”라는 질문에 팀원 모두가 같은 대답을 했다. “원래 있는 코드라서.”

익숙함은 가장 위험한 면죄부다. Manufacturing Bridge 6패턴(ep.47)을 구축해놓고도, 정작 가장 기본적인 — “이 코드가 정말 필요한가?” — 라는 질문을 놓치고 있었다. 패턴이 시스템으로 번역되지 않으면, 포스트모텀은 매번 같은 결론을 낸다. “우리가 더 주의했어야 한다.”

이번 빌드는 그 갭을 메운 기록이다.

무엇을 만들었나

Fresh-Eye 스킬 (104줄) — 6개 adversarial 체크리스트, LLM 불필요 7개 SUSPICIOUS_PATTERNS — housekeeper deep clean에 통합, 매일 04:00 자동 스캔 check_code_bypasses() — grep 기반, m-log + Drewgent 전역 bypass/backdoor 탐지 check_agent_health() — AGENTS.md 1050줄 한도, skills description 누락, cron stale job 감시 주간 cron fresh-eyes — 매주 일 06:00, flash 모델로 7일치 변경분 adversarial review AXIOMS.md 회귀검사 — 대전제를 grep-verifiable하게 정의, housekeeper가 매일 검증

Manufacturing Bridge 6패턴이 실제로 작동한 방식

흥미로운 점은 이 빌드가 의도치 않게 Manufacturing Bridge의 6개 패턴을 모두 구현하고 있다는 것이다. 패턴을 먼저 정의하고 시스템을 만든 게 아니라, 문제를 쫓다 보니 패턴이 스스로 드러났다.

패턴 Fresh-Eye 구현

안돈(Andon) — 이상 시 정지+알림 SUSPICIOUS_PATTERNS 탐지 → housekeeper 리포트에 포함 → Discord 전달

포카요케(Poka-Yoke) — 실수 자체를 구조적으로 차단 6개 체크리스트를 매번 보게 강제. 익숙함에 의한 누락을 시스템이 방지

지도카(Jidoka) — 이상 감지 시 자동 정지 grep 탐지 + housekeeper 리포트로 HITL 트리거. bypass 발견 시 인간 판단 대기

3현(Genchi Genbutsu) — 현장·현물·현실 코드 bypass를 추상적 위험이 아닌 구체적 grep 패턴으로 정의. 현장 코드에서 직접 검증

SPC(통계적 공정 관리) — 데이터 기반 이상 감지 check_agent_health()가 AGENTS.md 라인 수, skills description覆盖率, cron 적체를 정량화

FMEA(RPN) — 사전 위험 식별 AXIOMS.md의 machine-verifiable 대전제가 사전에 “이런 건 위반하지 않는다”를 정의

키 설계 결정: Familiarity Blindness를 시스템으로 깨는 법

  1. LLM을 배제한 이유

LLM에게 “이 코드 리뷰해줘”라고 하면 bypass를 찾아낼까? 아마 찾아낼 것이다. 하지만 그게 문제가 아니다. 문제는 LLM이 리뷰를 대신하면, 인간은 리뷰 자체를 하지 않게 된다는 점이다. 익숙함은 그냥 다른 곳으로 이동할 뿐 — 사라지지 않는다.

Fresh-eye는 질문을 던지는 행위 자체를 강제한다. 6개의 체크리스트는 LLM보다 덜 정확할 수 있다. 하지만 매주 일요일 아침, 이 6개 질문을 보면서 코드를 다시 보는 습관이 생긴다. 그 습관이 familiar blindness를 깨는 진짜 도구다.

  1. 정규식이면 충분한 이유

isAgent, isForce, anon_guest, deepseek-chat — 이 패턴들은 AST 분석이 필요하지 않다. 단순한 grep으로도 찾을 수 있는 패턴이지만, 아무도 grep을 돌리지 않았을 뿐이다.

7개 패턴으로 시작했다. 이 패턴들은 살아있는 문서다 — 새로운 bypass 패턴이 발견될 때마다 추가된다. 시스템이 스스로 진화한다.

  1. 주1회 cron이면 충분한 이유

모든 commit마다 adversarial review를 돌리면? 경고 피로(warning fatigue)가 온다. 중요한 건 주기적으로 신선한 눈으로 보는 것이지, 매 순간 감시하는 게 아니다.

매주 일요일 06:00, flash 모델이 지난 7일의 변경분을 6개 체크리스트로 검토한다. 리포트는 P6-prefrontal/incidents/에 저장되고, Critical 발견 시 Discord로 즉시 전달된다.

아키텍처

Postmortem Trigger └── Familiarity Blindness 발견 └── Fresh-Eye SKILL.md (104줄, 6 체크리스트) ├── Layer 0: SUSPICIOUS_PATTERNS 자동 탐지 (매일 04:00) │ └── housekeeper deep clean → Discord 리포트 ├── Layer 1: 수동 체크리스트 (매 리뷰 시) │ └── 6개 질문: Bypass/Pooled/Dead/Dual/Security/Config └── Layer 2: 주간 cron fresh-eyes (일 06:00) └── flash 모델 adversarial review → incidents/

실제 효과

배포 첫 주, housekeeper가 2건의 bypass 패턴을 잡아냈다. 하나는 staging 환경에 남아있는 isLocalDev 플래그, 다른 하나는 deprecation 예정인 API 호출이었다. 둘 다 “원래 있던 코드”라서 아무도 신경 쓰지 않던 것들이다.

104줄의 SKILL.md, 7개의 정규식, 매일 04:00에 도는 크론 하나. 이게 전부다. 근데 이 단순한 시스템이 3주 동안 아무도 발견하지 못한 문제를 배포 첫 주에 찾아냈다.

포스트모텀이 효과적이려면, 포스트모텀의 결론이 시스템으로 번역되어야 한다. “다음부터는 더 주의하자”는 시스템이 아니다. SUSPICIOUS_PATTERNS에 정규식 하나 추가하는 것이 시스템이다.

관련 포스트: Manufacturing Bridge — 6 Quality Patterns for AI Agent Governance, GraphRCA — 지식 그래프 기반 근본 원인 분석