Part 01 — Personal Harness

개인 하네스의
은밀한 복잡성

하네스(harness)란 AI가 '다 했다'고 대충 넘어가지 못하도록 규칙과 검사로 감시하는 장치입니다. 지금 이야기하는 것은 혼자서 컴퓨터 한 대로 돌리는 시스템인데도, 벌써 rules 50+, hooks 15+, 14-phase pipeline — AI가 지켜야 할 규칙 50개 이상, 규칙 위반을 막는 검문 스크립트 15개 이상, 14단계로 이어지는 작업 과정 — 이 쌓여 사람이 감당할 관리 한계에 이미 닿았습니다. 규칙끼리 서로 부딪히는 조합의 수는 O(n²)처럼 규칙 수의 제곱으로 불어납니다. 규칙이 2배가 되면 따져야 할 조합은 4배가 됩니다.

시스템을 이루는 구성 요소 목록
Rules (Global)50+
AI가 지켜야 할 규칙을 적어 둔 문서 파일입니다. 규칙끼리 서로 모순되지 않는지 살펴야 합니다. 3개월 동안 한 번도 안 쓰인 규칙은 정리합니다. 여러 프로젝트에서 반복되는 규칙은 공통 규칙으로 끌어올립니다.
HARD Hooks15+
규칙을 강제로 검사하는 자동 실행 스크립트입니다. 검사를 통과하면 통과, 막히면 차단 신호를 돌려줍니다. 새 검사를 추가할 때는 언제 실행할지 지정하는 표도 함께 고쳐야 합니다. 실행 순서에 따라 결과가 달라지기도 합니다.
Skills100+
특정 작업을 자동으로 처리하는 기능 묶음입니다. 설명 문서와 실행 스크립트로 이뤄집니다. 언제 자동으로 켜질지 조건을 관리해야 합니다. 버전이 바뀌어도 서로 맞물리도록 유지해야 합니다.
Agents30+
역할별로 나눠 둔 AI 일꾼입니다. 각자 쓸 수 있는 도구 권한을 따로 나눕니다. 지시문을 역할에 맞게 다듬습니다. 맡은 역할 밖의 작업은 막아 둡니다.
Pipeline Phases14
프로젝트 시작부터 마무리까지 이어지는 14단계 작업 흐름입니다. 먼저 프로젝트를 세팅하고, 중간에 다른 AI가 결과를 반박하며 검증하고, 마지막에 마무리합니다. 앞 단계 결과를 뒤 단계로 넘기고, 중간에 실패하면 되돌려 복구합니다.
Signal Collectors5
fix_commit, bug_fixer_retry, recurrence, telemetry, adversarial_finding.
QA Gates3-way
완성된 화면을 서로 다른 검사 도구 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
시스템이 버그를 고칠 때마다 새 규칙을 하나씩 만들어 냅니다. 그 규칙이 정말 효과가 있었는지 걸러 주는 관리자 역할이 없어, 검증 없이 계속 쌓이기만 합니다. 그 결과 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