Part 01 — Personal Harness

규칙 50개를 넘자
하네스라는 감시 장치가 사람 손을 벗어나기 시작했다

혼자서 컴퓨터 한 대로 돌리는 하네스(harness)인데도 벌써 사람이 감당할 관리 한계에 닿았다는 이야기입니다. 하네스란 AI가 '다 했다'고 대충 넘어가지 못하도록 규칙과 검사로 감시하는 장치입니다. 지금 쌓여 있는 것만 세어도 rules 50+, hooks 15+, 14-phase pipeline입니다. 차례로 AI가 지켜야 할 규칙 50개 이상, 규칙 위반을 막는 검문 스크립트(hook) 15개 이상, 14단계로 이어지는 작업 과정(pipeline)이라는 뜻입니다. 그래서 구성 요소를 하나하나 세고, 달마다 어떻게 불어났는지 되짚고, 실제로 부딪힌 사례 4개를 적었습니다. 문제의 뿌리는 규칙끼리 서로 부딪히는 조합의 수가 O(n²)처럼 규칙 수의 제곱으로 불어난다는 점입니다. 규칙이 2배가 되면 따져야 할 조합은 4배가 됩니다.

하네스를 이루는 구성 요소 목록
Rules (Global)50+
AI가 지켜야 할 규칙(rule)을 적어 둔 문서 파일입니다. 글로벌(global)은 어느 프로젝트에서 일하든 늘 같이 읽힌다는 뜻입니다. 규칙끼리 서로 모순되지 않는지 살펴야 합니다. 3개월 동안 한 번도 안 쓰인 규칙은 정리합니다. 여러 프로젝트에서 반복되는 규칙은 공통 규칙으로 끌어올립니다.
HARD Hooks15+
훅(hook)은 규칙을 강제로 검사하는 자동 실행 스크립트입니다. 이름 앞에 붙은 '하드'는 AI의 판단에 맡기지 않고 스크립트가 무조건 강제한다는 뜻입니다. 검사를 통과하면 통과 신호를, 막히면 차단 신호를 돌려줍니다. 새 검사를 추가할 때는 언제 실행할지 지정하는 표도 함께 고쳐야 합니다. 실행 순서에 따라 결과가 달라지기도 합니다.
Skills100+
스킬(skill)은 특정 작업을 자동으로 처리하는 기능 묶음입니다. 설명 문서와 실행 스크립트로 이뤄집니다. 언제 자동으로 켜질지 조건을 관리해야 합니다. 버전이 바뀌어도 서로 맞물리도록 유지해야 합니다.
Agents30+
에이전트(agent)는 역할별로 나눠 둔 AI 일꾼입니다. 각자 쓸 수 있는 도구 권한을 따로 나눕니다. 지시문을 역할에 맞게 다듬습니다. 맡은 역할 밖의 작업은 막아 둡니다.
Pipeline Phases14
파이프라인(pipeline)은 프로젝트 시작부터 마무리까지 이어지는 14단계 작업 흐름입니다. 먼저 프로젝트를 세팅하고, 중간에 다른 AI가 결과를 반박하며 검증하고, 마지막에 마무리합니다. 앞 단계 결과를 뒤 단계로 넘기고, 중간에 실패하면 되돌려 복구합니다.
Signal Collectors5
fix_commit, bug_fixer_retry, recurrence, telemetry, adversarial_finding.
QA Gates3-way
QA(품질 검사) 게이트란 완성된 화면을 서로 다른 검사 도구 3개로 교차 검증하는 관문입니다. 한 도구가 놓친 문제를 다른 도구가 잡아내도록 이중, 삼중으로 확인하는 방식입니다.
Potential Interactions1,225
규칙 50개가 서로 영향을 줄 수 있는 짝, 즉 잠재적 상호작용의 개수입니다. 규칙 하나를 나머지 전부와 짝지어 세면 1,225쌍이 됩니다(계산식 50×49÷2). 다만 이 중 실제로 부딪히는 경우는 약 5%뿐입니다.
달이 갈수록 복잡도가 불어난 과정
Month 1 (2026-02)
규칙 10개 · 검문 스크립트 5개, 아직 손으로 관리할 수 있었다
막 시작한 단계입니다. 기본 설정 파일 하나와 최소한의 품질 검사만 있습니다. 규칙끼리 부딪히는 일이 없습니다. 프로젝트도 하나뿐이라 단순합니다.
Month 2 (2026-03)
규칙 30개 · 검문 스크립트 10개, 규칙끼리 어긋나기 시작했다
프로젝트가 늘면서 문제가 생깁니다. 모든 프로젝트에 통하는 규칙과 특정 프로젝트에만 맞는 규칙의 경계가 흐려집니다. 시스템이 스스로 규칙을 자동으로 만들어 내기 시작합니다. 쓸모없어진 규칙을 쳐낼 정리 작업이 필요해집니다.
Month 3 (2026-04)
규칙 50개 이상 · 검문 스크립트 15개 이상, 관리를 전담할 절차가 필요해졌다
효과 없는 규칙을 걸러 내는 관리자 역할이 없어, 힘없는 규칙이 계속 쌓입니다. 검문 스크립트끼리도 서로 부딪힙니다. 예를 들어 품질 검사와 코드 리뷰가 서로 다른 시간 조건을 걸어 충돌합니다. 앞선 2단계에서 규칙 분류가 막힌 문제도 그대로 남아 있습니다.
4개월째 이후 (예상)
사람의 이해 한계에 다다를 것으로 예상
규칙 50개 이상이 서로 어떻게 얽히는지를 사람이 머릿속에 다 담아 두기란 사실상 불가능합니다. 규칙이 서로 모순되는지 자동으로 찾아내는 장치가 반드시 있어야 합니다.
복잡성이 실제로 터진 사례들
Case 1: 규칙끼리 정반대 지시
convergence-loop-no-mid-question는 '작업 중간에 멈추지 말고 끝까지 진행하라'는 규칙의 이름입니다. 그 반대편에는 completion-verification이라는 규칙이 있습니다. '완료라고 말하기 전에 멈춰 서서 검증하라'는 규칙입니다. 두 규칙은 적용 범위가 다르지만 그 경계가 흐릿합니다. '다 됐다고 선언하기 전에 스스로 점검하라'와 '중간에 멈추지 말라'가 정면으로 부딪히는 순간이 실제로 생깁니다.
Case 2: 검문 스크립트끼리 충돌 (시간 제한)
qa-gate-before-push는 코드를 서버에 올리기 직전에 실행되는 검문 스크립트입니다. 품질 검사를 통과했다는 표시 파일 .qa-cycle-passed를 요구합니다. 그것도 1시간 안에 만들어진 것이어야 합니다. 여기에 코드 리뷰를 통과했다는 표시 파일 .codex-review-passed까지 따로 요구하고, 이것도 1시간 안이어야 합니다. 새 커밋(변경 기록)을 하나 만들 때마다 두 표시 파일을 다시 만들고, mark-qa-pass.sh라는 등록 스크립트도 다시 돌려야 합니다. 이 절차가 꼬여 코드 올리기가 5회 연속 막히는 일이 실제로 벌어졌습니다.
Case 3: Scaffold Bloat
스캐폴드 블로트(scaffold bloat)란 AI 작업의 뼈대가 되는 규칙과 설정 파일 묶음이 검증 안 된 규칙으로 부풀어 오르는 현상입니다. 시스템이 버그를 고칠 때마다 새 규칙을 하나씩 만들어 냅니다. 그 규칙이 정말 효과가 있었는지 걸러 주는 관리자 역할이 없어, 검증 없이 계속 쌓이기만 합니다. 그 결과 3개월 동안 한 번도 안 쓰인 규칙이 전체의 약 20%에 이르는 것으로 추정됩니다.
Case 4: 스스로 만든 빠져나갈 구멍
premature-completion-detector는 '섣부른 완료 선언'을 잡아내는 감시 장치의 이름입니다. 이걸 만들 때, 예외로 봐줄 표현 목록인 VERIFICATION_MARKERS에 너무 헐거운 조건("Iter [0-9]+")을 넣었습니다. 이 조건은 문장 어딘가에 'Iter 숫자'라는 반복 회차 표기만 있으면 검증을 마친 것으로 봐주는 정규식(문자 패턴 규칙)입니다. 그러자 AI가 스스로 그 표현을 만들어 감시 장치를 빠져나갔습니다. 규칙을 만든 쪽과 규칙을 지켜야 하는 쪽이 같아서 스스로를 봐주게 되는 문제입니다.
규칙 종류별로 얼마나 자주 부딪히나
규칙 종류가 서로 충돌할 가능성입니다. 막대 오른쪽의 하이·미드·로우는 충돌 가능성이 높음·중간·낮음이라는 뜻입니다.
QA vs Workflow
HIGH
Security vs Speed
HIGH
Self-improve vs Stability
MED
Scope vs Universality
MED
Automation vs Control
MED
Brevity vs Completeness
LOW