내 AI 에이전트 시스템에 이미 적용되어 있던 6가지 패턴이 있었다. 문제는 그걸 설명하려면 항상 한 문단씩 필요했다는 거다.

70년 전 도요타의 공장 바닥에서 시작된 품질 관리 개념들이 — 안돈(andon), 포카요케(poka-yoke), 지도카(jidoka) — 지금 내 에이전트를 운영하는 방식과 정확히 같은 구조였다. 나는 이미 이 패턴들을 실행하고 있었지만, 이름이 없어서 설명 비용이 들고 있었다.

이 글은 그 패턴들에 이름을 붙이고, 3단계 강제 체계(3-tier enforcement)로 구조화한 이야기다. 커밋 하나에 정본 1개, 규칙 통합 1건, 린터 1개, 링크 1개. 329줄.

문제: 실행은 하고 있었지만, 설명할 수 없었다

Drewgent를 6개월 운영하면서 나는 자연스럽게 특정 패턴으로 수렴하고 있었다.

cron이 실패하면 바로 멈추지 않고 단계적으로 대응한다 API 키는 절대 평문으로 파일에 쓰지 않는다 — vault_cli.py로만 접근한다 모호한 task는 자동으로 멈추고 나한테 묻는다 “빌드 통과했다”는 “실제로 작동한다”는 증거가 아니다 — 프로세스를 직접 확인한다

이 패턴들은 AGENTS.md, rules.md, 개별 스킬 파일에 흩어져 있었다. 누군가 “왜 이렇게 했어?”라고 물으면 나는 매번 같은 설명을 반복해야 했다.

문제는 패턴의 부재가 아니라 이름의 부재였다. 실행은 되고 있었지만, 공유와 검증이 불가능했다. Provenance를 기록할 때도 “점진제동 원칙 적용”이라고 쓰는 게 아니라 “launchd ThrottleInterval 10s + cron_state.json WARN → discord_send.py → kanban_block”을 한 줄로 써야 했다.

트리거: agent-wiki 리뷰

lazymac2x/agent-wiki (MIT)를 검토하다가 제조 품질공학과 AI 에이전트 하네스 사이의 동형사상을 발견했다. “아, 이게 패턴이구나.”

이미 실행 중인 패턴에 이름을 붙이면 설명 비용이 제로가 된다. “왜 launchd에 ThrottleInterval을 10초로 설정했나요?” → “점진제동(andon) 원칙입니다.” 끝. 더 이상 문단이 필요 없다.

하지만 이름만 붙여서는 부족했다. 이름이 있으면 검증할 수 있어야 한다. 그래서 3-tier enforcement를 설계했다.

What This Builds

manufacturing-bridge.md (228줄) — 6대 패턴 정본 + patterns registry + enforcement tier별 규칙 rules.md 업데이트 (30줄 추가) — Manufacturing Bridge 섹션, 3-tier 통합 bridge-lint.sh (70줄) — config-driven 태그 검증기. patterns registry YAML을 awk로 파싱 ponytail 링크 (1줄) — ponytail이 구조적 불가능의 코드 레벨 인스턴스임을 명시

4개 파일, 329줄. 새 기능 0개. 하지만 이 329줄이 Drewgent의 전체 의사결정에 이름을 붙이고 검증 가능하게 만들었다.

6개 패턴 — 번역, 발명이 아니다

제조 품질공학은 70년간 검증된 개념들이다. FMEA는 1949년 미군이 개발했고, poka-yoke는 1960년대 Shigeo Shingo가 체계화했고, andon은 1950년대 도요타 생산 시스템의 핵심이었다. AI 에이전트 거버넌스는 새로운 문제가 아니다. 이미 풀린 문제의 번역일 뿐이다.

  1. 점진제동 (andon) — graduated remediation

장애 대응을 4단계로 분리한다. 처음부터 kill -9를 날리지 않는다.

선경고: Discord 알림만. cron 1회 실패 → WARN 로그 조이기: launchd ThrottleInterval 10s. 연속 2-3회 실패 시 재시도 간격 증가 늘추기: 큐 적체, 속도 제한. 반복 실패 시 office-autopilot sequential 처리 세우기: kanban_block + AskUserQuestion. 치명적 오류 시 완전 정지

핵심: 先경고 없이 세우기로 가면 안 된다. “그냥 멈추자”는 마지막 수단이어야 한다.

  1. 구조적 불가능 (poka-yoke) — structural impossibility

“하지 마” 규칙은 실패한다. 구조적으로 불가능하게 만들어야 한다.

watcher exclude: vault.key 읽기 시도 자체를 차단 (opencode.jsonc) chmod 600: credential 파일을 에이전트가 읽을 수 없게 만듦 vault_cli.py 의무화: set/get 외에 API 키를 다룰 경로가 없음 禁 blind_write: Read 없이 Write를 시도하면 tool 설계상 실패

Ponytail 스킬은 이 패턴의 코드 레벨 인스턴스다. “YAGNI? → stdlib? → native? → dep? → one line? → minimum.” 체크리스트를 통과하면 불필요한 코드가 애초에 생성되지 않는다.

  1. 자동정지 + 인간판단 (jidoka) — automatic stop + HITL

정지는 자동, 재가동 결정은 반드시 인간.

production DB 쓰기 감지 → AskUserQuestion task 분류 불가 → kanban_block → Discord 알림 rm -rf 감지 → 자동 차단 (禁 rule) confidence

규칙 하나: 정지만 하고 인간 판단 없이 넘어가는 건 “무음 fail” = P1 결함. 자동화된 정지는 인간 판단을 받을 의무가 있다.

  1. flaky vs systematic (SPC) — special cause vs common cause

모든 실패가 같은 무게를 가져서는 안 된다.

1회 단발, 패턴 없음 → retry + ignore 반복, 동일 조건 → 근본수정 + 재발방지 문서 특정 조건에서만 발생 → 층별 분석 점진적 증가 → 先경고 (점진제동으로 연결)

“그냥 flaky겠지”는 금지. 실제로는 systematic인 경우가 더 많다. 진단 없이 flaky로 치부하는 게 가장 위험한 가정이다.

  1. 두눈 실증 (3-hyun) — gemba-genbutsu-genjitsu

CI-green ≠ live-works. 테스트 통과만 믿고 “됐다”고 단정하지 않는다.

현장 (gemba): 실제 실행 환경 — process list, launchd list, docker ps 현물 (genbutsu): 실제 상태 덤프 — D1 직접 SELECT, cron_state.json 현실 (genjitsu): 실제 결과 — HTTP response, terminal output, screenshot

3현 중 최소 2가지를 직접 확인해야 QA 통과. 이 규칙을 위반하면 P1 결함이다. implementer가 “빌드 통과했다”고 말해도, 내가 직접 현장/현물/현실을 확인하기 전까지는 완료가 아니다.

  1. 사전 위험 식별 (FMEA) — risk scoring

작업 시작 전에 잠재 고장 모드를 점수화한다. RPN = 심각도 × 발생 × 검출.

RPN ≤ 10: 모니터링만 RPN 11-50: guardrail + 알림 RPN ≥ 51: pre-mortem 필수, HITL gate, kanban_block fallback

신규 cron job, 신규 skill, 신규 스크립트, kanban task 생성 시 RPN을 계산한다. 모든 위험을 막을 순 없으니 점수로 우선순위를 정하고 높은 것만 집중 방어한다. (이 패턴은 아직 DRAFT — kanban template에 RPN 필드 통합 중.)

3-Tier Enforcement

이름을 붙이는 것만으로는 부족하다. 패턴이 지켜지고 있는지 검증할 수 있어야 한다. 그래서 3단계 강제 체계를 설계했다.

┌─────────────────────────────────────────────────────────┐ │ Tier 1 행동 규칙 (AGENTS.md) │ │ provenance에 manufacturing-bridge:<패턴id> 태그 포함 │ │ 누락 → bridge-lint WARNING │ ├─────────────────────────────────────────────────────────┤ │ Tier 2 Lint Gate (bridge-lint.sh) │ │ YAML frontmatter → awk parse → 태그 검증 │ │ 미등록 태그 탐지 → registry 확장 자동 반영 │ ├─────────────────────────────────────────────────────────┤ │ Tier 3 禁 Rule (P1 결함) │ │ 3현 위반 → P1 (task_qa_gate.neuron) │ │ (향후) 자동정지+HITL 회피 → P1? │ └─────────────────────────────────────────────────────────┘

Tier 1은 행동 규칙이다. 모든 provenance 기록에 패턴 태그를 포함해야 한다. 태그 누락 시 bridge-lint가 WARNING을 출력하지만, 실행 자체는 막지 않는다.

Tier 2는 린트 게이트다. bridge-lint.sh가 변경된 .md 파일의 frontmatter에서 태그를 검증한다. 재미있는 점은 config-driven이라는 거다 — patterns registry는 manufacturing-bridge.md의 YAML frontmatter에 정의되어 있고, lint 스크립트는 awk로 이 YAML을 파싱한다. registry에 패턴을 추가하기만 하면 lint가 자동으로 검증 대상을 확장한다. 하드코딩된 패턴 목록이 없다.

Tier 3은 禁 규칙이다. P1 결함. 현재는 3현(두눈 실증) 위반만 해당하지만, 점진적으로 확장할 예정이다. 예를 들어 자동정지+HITL을 회피하고 조용히 넘어가는 것도 P1으로 올릴 계획이다.

설계 결정

결정대안선택 이유 Config-driven registry하드코딩된 패턴 목록확장성. 새 패턴 추가 시 lint 코드 변경 불필요 YAML frontmatter별도 JSON/YAML 파일정본 파일 하나로 패턴 정의 + registry + enforcement 규칙을 동시에 관리 3-tier 구분단일 enforcement점진적 강제. 모든 패턴에 같은 수준의 강제를 적용할 필요 없음 bridge-lint = WARNINGERROR (block)block은 Tier 3 위반에만. WARNING은 인지 + 문서화 우선 pre-commit hookCI 전용발견 시점을 최대한 앞당김. PR에 도착하기 전에 로컬에서 잡는다

그래서?

이 커밋(ce585068) 이후로 Drewgent의 모든 provenance 기록에는 manufacturing-bridge:andon, manufacturing-bridge:poka-yoke 같은 태그가 포함된다. 새 메커니즘을 설계하기 전에 “이미 6개 패턴 중 해당하는 게 있나?”를 먼저 확인한다.

329줄이 바꾼 것은 설명 방식이었다. 패턴에 이름을 붙이기 전에는 “에이전트가 중요한 결정을 내릴 때 자동으로 멈추고 나한테 물어보게 했어, 왜냐하면 무음 fail이 제일 위험하니까”라고 말해야 했다. 지금은 “jidoka 적용했어”라고 말한다.

이름을 붙이는 게 지식을 만든다. 검증을 구조화하는 게 시스템을 만든다. 그리고 그게 taste다 — 패턴을 설명하는 비용을 제로로 만드는 설계.

정본: harness/patterns/manufacturing-bridge.md린터: scripts/bridge-lint.sh규칙: P0-brainstem/brain/rules.md (Manufacturing Bridge 섹션)

inspired_by: lazymac2x/agent-wiki (MIT) — 제조↔에이전트 동형사상 개념 검토 및 Taste Review 계기

Built with opencode-drewgent