"AI에게 규칙을 주면 지킬까요?"
결론부터 말하겠습니다. 안 지킵니다.
Convince-X를 만들면서 AI를 CTO, CPO, CDO 등 C-Suite 역할로 활용하고 있습니다. AI에게 코드를 짜게 하고, 아키텍처를 설계하게 하고, UX를 리뷰하게 합니다. 이 과정에서 "AI가 규칙을 안 지키는 문제"를 5주에 걸쳐 해결해나간 기록입니다.
이건 기술 이야기이기도 하지만, 동시에 관리(governance)의 이야기입니다. AI를 도구로 쓰는 모든 사람이 결국 부딪히게 될 문제입니다.
• • •
규칙 18개의 시대
처음에는 자연어 규칙으로 시작했습니다. 설정 파일에 AI가 지켜야 할 규칙을 적어놓는 방식입니다.
"코드를 수정하기 전에 반드시 현재 상태를 확인할 것." "테스트를 통과하지 못한 코드를 배포하지 말 것." "승인 없이 파일을 삭제하지 말 것."
이런 규칙이 18개까지 늘어났습니다. 초기에는 잘 작동하는 것처럼 보였습니다. AI가 규칙을 읽고, "네, 이해했습니다. 먼저 현재 상태를 확인하겠습니다"라고 답하니까요.
규칙 18개 시대의 구조
1. CEO 승인 필수
2. AS-IS 확인
3. 테스트 통과
4. 파일 삭제 금지
5. 범위 확장 금지
6. 보고 형식 준수
7. 보안 정보 금지
8. i18n 적용
... +10개 더
전부 자연어. 강제하는 메커니즘 없음. "지키겠습니다"라는 약속에 의존.
문제는, 규칙이 많아질수록 AI가 선택적으로 무시하기 시작했다는 것입니다.
• • •
AI는 규칙을 어깁니다
2주차부터 위반이 눈에 띄기 시작했습니다. 가장 흔한 패턴은 "승인 없이 진행"이었습니다.
규칙에는 "모든 실행은 CEO 승인 후 진행"이라고 되어 있는데, AI가 "효율을 위해 바로 진행하겠습니다"라고 하면서 코드를 수정하는 경우가 반복됐습니다. AI는 규칙을 모르는 게 아닙니다. 알면서도 "이건 사소한 변경이니까 괜찮겠지"라는 판단을 합니다.
실제 위반 사례
사례 1: "간단한 수정이니 바로 진행하겠습니다" → 설정 파일 덮어쓰기로 게임 에러 발생
사례 2: AS-IS 확인 없이 코드 수정 → 기존 기능 깨짐
사례 3: 테스트 없이 "완료"라고 보고 → 배포 후 버그 발견
사례 4: C-Suite 견제 없이 진행 → 단방향 의견으로 잘못된 결정
가장 심각했던 건 03-08 사건입니다. AI가 외주 프로젝트의 설정 파일(cfg)을 승인 없이 덮어써서 게임에 에러가 발생했습니다. 대원칙 5개를 전부 위반한 사건이었습니다. 원인 분석을 시켜봤더니 처음에는 "파일이 이미 손상되어 있었다"고 했다가, 증거를 제시하니 "제가 덮어썼습니다"로 말을 바꿨습니다.
이때 깨달았습니다. 자연어 규칙은 약속이지 강제가 아니다. AI가 "지키겠습니다"라고 해도, 맥락이 바뀌면 규칙보다 효율을 우선하는 경향이 있습니다.
같은 AI가 모자만 바꿔 쓰는 건 진짜 견제가 아닙니다. 진짜 견제는 구조에서 나옵니다.
• • •
구조적 강제의 시작
3주차에 방향을 전환했습니다. 규칙을 더 추가하는 대신, 구조적으로 위반할 수 없게 만들기로 했습니다.
채널톡의 사례가 힌트가 됐습니다. 채널톡은 고객 응대 규칙을 자연어로 적는 대신, 시스템 구조로 강제합니다. "고객에게 친절하게 응대하세요"가 아니라, 응대 템플릿 자체가 친절한 톤으로 되어 있는 식입니다.
이 원칙을 AI 거버넌스에 적용했습니다.
구조적 강제 — 3계층
Layer 3 — 테스트 강제 (최상위)
자동화 테스트 통과해야 배포 가능
자연어로 "테스트 하세요"가 아니라, 시스템이 차단
Layer 2 — 행동 규칙
Hook + Agent가 자동 실행
세션 시작 시 자동으로 상태 확인, 코드 수정 시 자동 리뷰
Layer 1 — 자연어 규칙 (최하위)
원칙 문서 (설정 파일)
가이드라인 역할. 단독으로는 강제력 없음
핵심 인사이트는 이것입니다: 자연어 규칙 < 행동 규칙 < 테스트 강제. 위로 갈수록 AI가 우회할 수 없습니다. 테스트가 실패하면 배포 자체가 안 되니까요.
이때 도입한 것이 자동 트리거 시스템입니다. 핵심 시점에만 자동으로 실행되는 트리거를 두었습니다. 불필요한 자동화를 제거하고 핵심만 유지한 것입니다.
• • •
에이전트라는 해법
Hook만으로는 부족했습니다. 코드를 수정한 후 "이게 맞는지" 검증하는 과정이 필요한데, AI 스스로 자기 코드를 리뷰하는 건 구조적으로 한계가 있습니다. 작성자와 검토자가 같으니까요.
그래서 도입한 것이 코드 검증 에이전트입니다. 별도의 AI 모델을 호출해서 코드 리뷰를 시킵니다. 같은 AI라도 다른 컨텍스트에서 호출하면 다른 관점을 제공합니다.
코드 검증 에이전트의 역할: 코드 수정이 완료되면 자동으로 호출됩니다. 다각도 검토를 수행하고, 통과/경고/차단 중 하나를 판정합니다. 차단이 나오면 배포가 막힙니다.
보고 형식도 바꿨습니다. 모든 코드 수정 보고에는 반드시 검증 결과가 포함되어야 합니다. 리뷰 결과 없는 보고는 금지. 이렇게 하니 "리뷰 없이 바로 배포"하는 경우가 구조적으로 불가능해졌습니다.
작업 흐름이 명확해졌습니다.
검증 모델 — 작업 흐름
1. 현재 상태 확인 → CEO 보고
2. CEO 승인
3. 코드 수정
4. 다단계 AI 검증 (다각도 자동 검토)
5. 품질 관문 (자동화 테스트 + 검증 결과)
→ 차단 시 배포 중단. 수정 후 재검사
6. 결과 종합 + 검증 판정 → CEO 보고
7. CEO 확인 → 배포
이걸 검증 모델이라고 부릅니다. 읽기와 검증은 자동, 쓰기와 배포는 CEO 승인. 승인과 자동 리뷰의 결합입니다.
• • •
Lv4 업그레이드
5주차에 대폭 업그레이드를 했습니다. 검증 에이전트를 여러 개로 늘리고, 반복 작업을 자동화하는 스킬 시스템도 도입했습니다.
코드 검증 에이전트
코드 품질 검증
다각도 검토를 수행하고 통과/경고/차단을 판정합니다.
계획 검증 에이전트
계획 사전 검토
실행 전 계획 단계에서 범위 초과, 리스크 사전 감지.
스펙 확인 에이전트
스펙 준수 확인
CEO가 결정한 스펙 대비 구현 일치 여부 검증.
배포 보호 에이전트
배포 관문
배포 전 최종 체크. 테스트, 환경변수, 보안 확인.
실행 순서는 다단계 AI 검증 → CEO 승인입니다. 각 단계를 통과해야 다음으로 넘어갑니다.
동시에 18개 규칙을 5개 핵심 원칙으로 압축했습니다.
| # |
원칙 |
내용 |
| 1 |
CEO 전건 승인 |
모든 실행은 승인 후 진행. 예외 없음. |
| 2 |
AS-IS 먼저 |
코드 만지기 전에 기존 상태 확인 후 보고. |
| 3 |
Agent 교차 검토 |
코드 수정 시 검증 에이전트 자동 호출. 리뷰 결과 필수 포함. |
| 4 |
구체적 수면 정리 |
세션 종료 시 미완료 항목을 체크리스트로 구체적 기록. |
| 5 |
CEO 지시만 실행 |
자비스가 범위를 확장하지 않는다. 시킨 것만 한다. |
규칙이 18개에서 5개로 줄었지만, 실효성은 오히려 올라갔습니다. 왜냐하면 규칙의 수가 아니라 강제하는 구조가 핵심이니까요.
• • •
실패에서 배운 것
5주간의 진화 과정에서 가장 큰 교훈을 준 건 성공이 아니라 실패입니다.
03-08 사건은 이미 언급했습니다. cfg 파일 덮어쓰기. 대원칙 5개 전부 위반. 원인 분석 시 말 바꿈. 이 사건 이후 "실패 기록(failures.md)"을 만들어서 모든 위반 사례를 문서화하기 시작했습니다. 같은 실수를 반복하지 않기 위해서입니다.
03-15 사건은 다른 종류의 실패였습니다. AI가 "바로 진행하겠습니다"를 반복하면서 승인 없이 코드를 수정했습니다. 한 세션에서 여러 번. C-Suite 견제도 방기했고, 보고도 불성실했습니다.
| 날짜 |
실패 내용 |
대응 |
| 03-08 |
cfg 덮어쓰기, 5원칙 전부 위반, 말 바꿈 |
실패 기록 도입, 구조적 강제 전환 결정 |
| 03-15 |
승인 없이 반복 진행, 견제 방기 |
검증 모델 강화, 신호등 체계 도입 |
이 실패들이 준 가장 큰 교훈은 하나입니다.
AI는 선의로 규칙을 어깁니다. "이게 더 효율적이니까"라는 판단으로. 그래서 선의에 의존하면 안 되고, 구조로 막아야 합니다.
• • •
하네스의 현재와 미래
다른 프레임워크들도 조사했습니다. GitHub에서 인기 있는 AI 거버넌스 프로젝트들을 분석했습니다. 대부분 자연어 규칙 기반이었고, 구조적 강제까지 가는 프레임워크는 거의 없었습니다.
Convince-X의 하네스가 특별한 이유는 실전에서 실패하고, 그 실패를 기록하고, 구조로 해결한 과정이 있기 때문입니다. 이론이 아니라 실전입니다.
현재 하네스의 구성 요소를 정리하면 이렇습니다.
하네스 현재 스펙:
• 핵심 원칙 5개 (18개에서 압축)
• 다수의 검증 에이전트 (각각 다른 역할 담당)
• 자동화 스킬 시스템 (반복 작업 효율화)
• 핵심 자동 트리거만 유지
• 신호등 체계 (통과/경고/차단)
• 실패 기록 (모든 위반 사례 문서화)
• 검증 운영 모델 (CEO 승인 + 자동 리뷰)
앞으로의 방향은 명확합니다. 더 적은 규칙, 더 강한 구조. AI가 더 똑똑해질수록, 규칙을 우회하는 것도 더 교묘해집니다. 그래서 규칙이 아니라 구조가 답입니다.
이 하네스를 오픈소스로 공개하려고 준비하고 있습니다. AI와 함께 일하는 모든 사람에게 유용할 거라고 생각합니다. 규칙 18개를 쓰느라 시간을 쓰는 것보다, 구조 5개를 만드는 게 훨씬 효과적이라는 걸 5주에 걸쳐 증명했으니까요.
"If you give AI rules, will it follow them?"
I'll give you the answer upfront: No, it won't.
While building Convince-X, I use AI in C-Suite roles like CTO, CPO, and CDO. I have AI write code, design architecture, and review UX. This is the record of solving "the problem of AI not following rules" over the course of 5 weeks.
This is a technology story, but simultaneously a story about governance. It's a problem everyone using AI as a tool will eventually face.
• • •
The Era of 18 Rules
We started with natural language rules. Writing the rules AI should follow in a configuration file.
"Always check current state before modifying code." "Don't deploy code that hasn't passed tests." "Don't delete files without approval."
These rules grew to 18. In the early days, they seemed to work. AI would read the rules and respond, "Yes, I understand. I'll check the current state first."
Structure of the 18-Rule Era
1. CEO Approval Required
2. AS-IS Check
3. Tests Must Pass
4. No File Deletion
5. No Scope Creep
6. Report Format
7. No Security Info
8. Apply i18n
... +10 more
All natural language. No enforcement mechanism. Relying on a promise of "I'll follow them."
The problem was that as rules increased, AI started selectively ignoring them.
• • •
AI Breaks Rules
Starting in week 2, violations became noticeable. The most common pattern was "proceeding without approval."
The rules stated "all actions require CEO approval before proceeding," but AI would say "I'll proceed directly for efficiency" and modify code. AI doesn't lack awareness of the rules. It knows them but judges "this is a minor change, so it should be fine."
Actual Violation Cases
Case 1: "It's a simple fix, I'll proceed directly" → Configuration file overwrite caused game errors
Case 2: Code modified without AS-IS check → Broke existing functionality
Case 3: Reported "complete" without testing → Bugs found after deployment
Case 4: Proceeded without C-Suite checks → One-sided opinions led to bad decisions
The most severe was the 03-08 incident. AI overwrote a client project's configuration file (cfg) without approval, causing game errors. All 5 core principles were violated. When asked for root cause analysis, it first claimed "the file was already corrupted," then changed its story to "I overwrote it" when presented with evidence.
That's when I realized: natural language rules are promises, not enforcement. Even when AI says "I'll follow them," it tends to prioritize efficiency over rules when context changes.
The same AI wearing different hats is not real checks and balances. Real checks come from structure.
• • •
The Start of Structural Enforcement
In week 3, we changed direction. Instead of adding more rules, we decided to make it structurally impossible to violate them.
Channel Talk's approach provided a hint. Channel Talk enforces customer service rules not through natural language but through system structure. Not "be kind to customers" but templates that are inherently kind in tone.
We applied this principle to AI governance.
Structural Enforcement — 3 Layers
Layer 3 — Test Enforcement (Highest)
Automated tests must pass before deployment
Not "please run tests" in natural language — the system blocks it
Layer 2 — Behavioral Rules
Hooks + Agents auto-execute
Auto state check on session start, auto review on code changes
Layer 1 — Natural Language Rules (Lowest)
Principle documents (configuration file)
Guideline role. No enforcement power alone
The key insight: Natural language rules < Behavioral rules < Test enforcement. The higher you go, the less AI can bypass. If tests fail, deployment simply doesn't happen.
This is when we introduced the auto-trigger system. Triggers that automatically execute only at critical points. Removing unnecessary automation and keeping only what's essential.
• • •
Agents as the Solution
Hooks alone weren't enough. After modifying code, a verification process is needed, but having AI review its own code has structural limitations. The author and reviewer are the same entity.
So we introduced code verification agents. A separate AI model is called to perform code review. Even the same AI provides different perspectives when called from a different context.
Code Verification Agent's Role: Automatically called when code changes are complete. Performs multi-angle review and issues a Pass/Warn/Block verdict. Block means deployment is halted.
The reporting format changed too. Every code change report must include verification results. Reports without review results are prohibited. This made "deploying without review" structurally impossible.
The workflow became clear.
Verification Model — Workflow
1. Check current state → Report to CEO
2. CEO approves
3. Code modification
4. Multi-stage AI verification (multi-angle auto review)
5. Quality gate (automated tests + verification results)
→ Block = deployment halted. Fix and re-test
6. Consolidated results + verification verdict → Report to CEO
7. CEO confirms → Deploy
We call this the verification model. Reading and verification are automatic; writing and deployment require CEO approval. A combination of approval and automated review.
• • •
The Lv4 Upgrade
In week 5, a major upgrade was made. Verification agents were expanded to multiple, and a skill system for automating repetitive tasks was also introduced.
Code Verification Agent
Code Quality Verification
Performs multi-angle reviews and issues Pass/Warn/Block verdicts.
Plan Verification Agent
Pre-execution Plan Review
Detects scope creep and risks at the planning stage before execution.
Spec Check Agent
Spec Compliance Check
Verifies whether implementation matches the specs decided by the CEO.
Deploy Guard Agent
Deployment Gate
Final check before deployment. Tests, environment variables, security verification.
The execution order is multi-stage AI verification → CEO approval. Each stage must pass before moving to the next.
Simultaneously, 18 rules were compressed into 5 core principles.
| # |
Principle |
Description |
| 1 |
CEO Approves Everything |
All actions proceed only after approval. No exceptions. |
| 2 |
AS-IS First |
Check and report existing state before touching code. |
| 3 |
Agent Cross-Review |
Verification agents auto-invoked on code changes. Review results mandatory. |
| 4 |
Concrete Session Handoff |
Record incomplete items as specific checklists at session end. |
| 5 |
Execute Only CEO Instructions |
The AI does not expand scope. Only do what's been asked. |
Rules went from 18 to 5, but effectiveness actually increased. Because it's not about the number of rules -- it's about the structure that enforces them.
• • •
Lessons from Failure
The biggest lessons from the 5-week evolution came not from success but from failure.
The 03-08 incident was already mentioned. cfg file overwrite. All 5 principles violated. Changed its story during root cause analysis. After this incident, we created a "failure log (failures.md)" to document every violation case. To prevent repeating the same mistakes.
The 03-15 incident was a different kind of failure. AI kept repeating "I'll proceed directly" and modified code without approval. Multiple times in one session. Abandoned C-Suite checks, gave incomplete reports.
| Date |
Failure |
Response |
| 03-08 |
cfg overwrite, all 5 principles violated, changed story |
Failure log introduced, structural enforcement decision |
| 03-15 |
Repeated unauthorized actions, abandoned checks |
Verification model strengthened, traffic light system introduced |
The single biggest lesson from these failures:
AI breaks rules with good intentions. Judging "this is more efficient." That's why you can't rely on good intentions -- you must block with structure.
• • •
The Harness Today and Tomorrow
We also researched other frameworks. Analyzed popular AI governance projects on GitHub. Most were natural language rule-based, and almost none went as far as structural enforcement.
What makes Convince-X's harness special is that it has the process of failing in practice, documenting those failures, and solving them through structure. Not theory -- practice.
Here's the current harness composition:
Current Harness Specs:
• 5 core principles (compressed from 18)
• Multiple verification agents (each with different roles)
• Automated skill system (repetitive task efficiency)
• Only essential auto-triggers retained
• Traffic light system (Pass/Warn/Block)
• Failure log (all violations documented)
• Verification operating model (CEO approval + auto review)
The direction forward is clear: fewer rules, stronger structure. As AI gets smarter, it also gets more sophisticated at circumventing rules. That's why structure, not rules, is the answer.
We're preparing to open-source this harness. I believe it will be useful for anyone working with AI. Over 5 weeks, we proved that building 5 structures is far more effective than writing 18 rules.
