"AI가 알아서 해줄 거야."
4개월 전, 저도 그렇게 생각했습니다. AI에게 코드를 맡기고, 제품을 만들고, 심지어 품질까지 관리하게 했습니다. 처음에는 놀라웠습니다. 하루 만에 프로토타입이 나오고, 일주일이면 기능 하나가 완성됐으니까요.
그런데 두 달쯤 지나자 문제가 보이기 시작했습니다. AI가 제가 시키지 않은 일을 하고 있었습니다. 파일을 덮어쓰고, 범위를 확장하고, 승인 없이 구조를 바꿨습니다. 한 번은 설정 파일을 통째로 덮어써서 라이브 서비스에 에러가 난 적도 있습니다.
이건 AI가 나빠서가 아닙니다. 통제 구조가 없었기 때문입니다.
• • •
AI에게 회사를 맡기면 생기는 일
1인 창업자가 AI를 쓰는 방식은 대기업과 근본적으로 다릅니다. 대기업은 AI가 특정 작업을 보조합니다. 1인 창업자에게 AI는 팀 그 자체입니다. 코드를 짜고, 디자인을 하고, 테스트를 하고, 배포까지 합니다.
이 상황에서 세 가지 문제가 반복적으로 발생합니다.
💥
범위 확장 (Scope Creep)
"버튼 색 바꿔줘"라고 했는데 레이아웃 전체를 재설계합니다. 시키지 않은 일을 자발적으로 합니다.
⚠
무단 실행 (Unauthorized Actions)
승인 없이 파일을 수정하고, 구조를 변경하고, 배포 관련 설정을 건드립니다.
📉
품질 저하 (Quality Degradation)
수정할수록 코드 품질이 떨어집니다. 이전 맥락을 잊고, 같은 실수를 반복합니다.
이 문제들의 공통점은 AI의 능력 부족이 아니라 관리 구조의 부재라는 점입니다. 뛰어난 신입 개발자를 채용했는데, 코드 리뷰도 없고, 배포 프로세스도 없고, 누가 뭘 승인하는지도 정해지지 않은 회사에 던져놓은 것과 같습니다.
• • •
하네스란 무엇인가
CX 하네스는 AI와 함께 제품을 만들 때 필요한 거버넌스 프레임워크입니다. 4개월간 실제 SaaS를 운영하면서 만들어졌습니다. 이론이 아니라 실전에서 나온 구조입니다.
핵심 철학은 단순합니다.
처음에는 자연어로 된 규칙 18개를 만들어서 AI에게 "이거 지켜"라고 했습니다. AI는 그 규칙을 읽었고, 이해했다고 대답했고, 그리고 위반했습니다. 반복적으로.
왜 그런지 분석한 결과, AI가 규칙을 무시하는 게 아니라 맥락이 길어지면 우선순위가 밀리는 것이었습니다. "CEO 승인 후 진행"이라는 규칙이 있어도, 작업에 몰입하면 그 규칙보다 "주어진 작업을 완수하는 것"이 더 높은 우선순위가 됩니다.
하네스는 이 문제를 구조적 강제로 해결합니다. 규칙을 읽게 하는 게 아니라, 규칙을 우회할 수 없는 구조를 만듭니다.
• • •
3레이어 아키텍처
하네스는 세 겹의 층으로 구성됩니다. 각 층이 다른 층의 빈틈을 보완합니다.
Layer 1 — 핵심 원칙
5개의 불변 원칙
모든 행동의 기준. "CEO 전건 승인", "현재 상태 먼저 확인", "교차 검토 필수", "구체적 기록", "지시만 실행". 이 5개는 어떤 상황에서도 변하지 않습니다.
Layer 2 — C-Suite 시스템
AI 5인의 상시 견제
CPO(제품), CTO(기술), CDO(디자인), CQO(품질), CBO(마케팅). 매 응답마다 5개 관점에서 교차 검토합니다. 신호등 체계로 유저 관점을 강제 점검합니다.
Layer 3 — 자동 검증
다단계 검증 에이전트
별도 AI 모델이 코드를 검증합니다. 코드 검증, 계획 검증, 스펙 확인, 배포 보호 — 4단계 자동 검증으로 사람이 놓치는 것을 잡습니다.
왜 3개 층이 필요한가? 하나의 층만으로는 반드시 빈틈이 생기기 때문입니다.
원칙만 있으면 → AI가 원칙을 읽고도 위반합니다. C-Suite만 있으면 → 같은 AI가 모자만 바꿔 쓰는 거라 진짜 견제가 안 됩니다. 자동 검증만 있으면 → 무엇을 검증해야 하는지의 기준이 없습니다.
세 층이 겹쳐야 비로소 빠져나갈 수 없는 구조가 만들어집니다.
• • •
규칙이 실패하는 이유
처음에 18개 규칙을 자연어로 작성했습니다. "모든 코드 수정 전에 현재 상태를 확인할 것", "승인 없이 파일을 수정하지 말 것", "범위를 확장하지 말 것". 합리적인 규칙들이었습니다.
AI는 이 규칙을 완벽하게 이해했습니다. 규칙이 뭔지 물어보면 18개를 다 암송했습니다. 그리고 작업을 시작하면 위반했습니다.
실제 위반 패턴 (4개월간 기록)
AS-IS 미확인 — 기존 상태 확인 없이 수정22%
자연어 규칙 18개 시절의 위반 유형 분포.
규칙을 알고 있어도 "작업 완수" 본능이 우선합니다.
핵심 통찰은 이것이었습니다. AI는 규칙을 "읽는" 것과 "따르는" 것이 다릅니다. 읽는 건 100% 합니다. 따르는 건 맥락에 따라 우선순위가 밀립니다. 마치 회사에 행동강령이 있지만 마감에 쫓기면 무시되는 것과 같습니다.
규칙은 선언입니다. 구조는 강제입니다. 이 차이를 깨닫는 데 2개월이 걸렸습니다.
• • •
구조가 작동하는 이유
구조적 강제란, AI가 규칙을 따르겠다고 "결심"하는 게 아니라, 규칙을 우회할 수 없는 환경을 만드는 것입니다.
예를 들어 보겠습니다.
규칙 방식
"코드 수정 후 반드시 교차 검토를 받을 것"
→ AI가 읽음
→ 작업 중 잊음
→ "수정 완료했습니다" 보고
→ 검토 생략
구조 방식
코드 수정 완료 시 자동 트리거 발동
→ 별도 AI 모델이 자동으로 검토
→ 결과가 보고에 포함되어야 함
→ 결과 없으면 보고 자체가 불완전
→ 생략 불가
하네스가 도입한 구조적 강제의 핵심 메커니즘은 세 가지입니다.
첫째, 자동 트리거. 세션이 시작될 때, 사용자가 요청할 때 자동으로 실행되는 절차가 있습니다. AI가 "하겠다"고 결심할 필요가 없습니다. 구조가 자동으로 실행합니다.
둘째, 외부 검증. 같은 AI가 자기 코드를 검토하는 게 아니라, 별도 AI 모델이 검증합니다. 자기감시의 구조적 한계를 우회합니다.
셋째, 인간 승인. 모든 쓰기 작업(코드 수정, 배포, 구조 변경)은 반드시 사람의 승인을 거칩니다. 읽기와 검증은 자동이지만, 실행은 승인 후에만.
이 세 가지가 결합하면, AI는 여전히 자유롭게 분석하고 제안하지만, 실행은 통제된 환경에서만 이루어집니다.
• • •
누구를 위한 프레임워크인가
하네스는 특정 상황에서 가장 큰 가치를 발휘합니다.
1인 창업자 / 솔로 파운더
AI를 CTO, 디자이너, QA로 동시에 쓰고 있다면. 혼자서 모든 걸 관리하면서 품질을 유지해야 한다면.
소규모 팀 (2~5명)
AI를 팀원처럼 쓰고 있지만, AI의 산출물을 체계적으로 검증할 사람이 부족한 팀.
AI-Heavy 프로젝트
코드의 80% 이상을 AI가 생성하는 프로젝트. AI 산출물의 품질 관리가 곧 프로젝트 성패를 결정하는 경우.
AI 거버넌스에 관심 있는 누구나
AI를 단순한 도구가 아니라 "관리해야 할 에이전트"로 보는 관점에 공감한다면.
하네스는 오픈소스로 공개됩니다. 4개월간 실전에서 검증된 구조를 그대로 공유합니다. 완벽하지 않습니다. 지금도 매일 개선하고 있습니다. 하지만 "AI에게 일을 시키면서 품질을 어떻게 유지하는가?"라는 질문에 대한, 하나의 실전 답안이 될 수 있다고 생각합니다.
다음 글에서는 18개 규칙이 5개 핵심 원칙으로 압축된 과정을 이야기합니다. 왜 13개가 삭제되었고, 남은 5개가 왜 이 5개인지.
"AI will handle everything."
Four months ago, I thought the same thing. I let AI write the code, build the product, and even manage quality. At first, it was impressive. A prototype in a day, a full feature in a week.
But about two months in, problems started appearing. The AI was doing things I never asked for. It overwrote files, expanded scope, and changed architecture without approval. Once, it completely overwrote a configuration file and caused errors in the live service.
This wasn't because the AI was bad. It was because there was no governance structure.
• • •
What Happens When AI Runs Your Company
The way a solo founder uses AI is fundamentally different from how enterprises do it. Enterprises use AI to assist with specific tasks. For a solo founder, AI is the team. It writes code, designs, tests, and deploys.
In this situation, three problems occur repeatedly.
💥
Scope Creep
You ask to "change the button color" and it redesigns the entire layout. It voluntarily does work you never requested.
⚠
Unauthorized Actions
It modifies files, changes architecture, and touches deployment settings without approval.
📉
Quality Degradation
The more edits it makes, the worse the code quality gets. It forgets previous context and repeats the same mistakes.
The common thread is that these problems stem not from AI's lack of capability, but from the absence of a management structure. It's like hiring a brilliant junior developer and dropping them into a company with no code reviews, no deployment process, and no defined approval chain.
• • •
What Is the Harness
CX Harness is a governance framework for building products with AI. It was born from 4 months of operating a real SaaS product. Not theory — structure forged in production.
The core philosophy is simple.
Rules fail. Only structure works.
Initially, we created 18 natural-language rules and told the AI "follow these." The AI read them, confirmed it understood, and then violated them. Repeatedly.
After analysis, we discovered that the AI wasn't ignoring the rules — as context grew longer, rule priority got deprioritized. Even with a rule like "proceed only after CEO approval," when the AI was deep in a task, "completing the given work" became a higher priority than that rule.
The Harness solves this through structural enforcement. Instead of making AI read rules, it creates structures that rules cannot bypass.
• • •
3-Layer Architecture
The Harness consists of three layers. Each layer covers the gaps of the others.
Layer 1 — Core Principles
5 Immutable Principles
The foundation of all behavior. "CEO approval for all actions," "check current state first," "mandatory cross-review," "specific documentation," "execute only what is instructed." These 5 never change regardless of circumstances.
Layer 2 — C-Suite System
Continuous Oversight by 5 AI Executives
CPO (Product), CTO (Tech), CDO (Design), CQO (Quality), CBO (Marketing). Every response is cross-reviewed from 5 perspectives. A traffic light system enforces user-perspective checks.
Layer 3 — Automated Verification
Multi-Stage Verification Agents
Separate AI models verify the code. Code review, plan review, spec check, deploy guard — 4-stage automated verification catches what humans miss.
Why are 3 layers needed? Because a single layer always has gaps.
Principles alone → AI reads them and still violates them. C-Suite alone → the same AI just wearing different hats, so real checks don't happen. Automated verification alone → there's no criteria for what to verify.
Only when all three layers overlap does an inescapable structure emerge.
• • •
Why Rules Fail
We initially wrote 18 rules in natural language. "Check current state before any code modification," "Do not modify files without approval," "Do not expand scope." Reasonable rules.
The AI understood them perfectly. When asked what the rules were, it could recite all 18. Then it would start working and violate them.
Actual Violation Patterns (4-Month Record)
Scope creep — performing unrequested work38%
Skipped approval — "I'll proceed right away"28%
No AS-IS check — modifying without checking current state22%
Missing report — only delivering results after changes12%
Violation type distribution during the 18-rule era.
Even when rules are known, the "task completion" instinct takes priority.
The key insight was this: AI "reading" rules and "following" rules are different things. Reading happens 100% of the time. Following depends on context — priorities shift. Just like how a company has a code of conduct, but it gets ignored under deadline pressure.
Rules are declarations. Structure is enforcement. It took 2 months to realize this difference.
• • •
Why Structure Works
Structural enforcement means that instead of AI "deciding" to follow rules, you create an environment where rules cannot be bypassed.
Here's an example.
Rule-Based Approach
"Code must undergo cross-review after modification"
→ AI reads the rule
→ Forgets during work
→ Reports "modification complete"
→ Review skipped
Structure-Based Approach
Auto-trigger fires on code modification
→ Separate AI model reviews automatically
→ Results must be included in report
→ Report is incomplete without results
→ Cannot be skipped
The three core mechanisms of structural enforcement in the Harness are:
First, automated triggers. Procedures that execute automatically when a session starts or when a user makes a request. The AI doesn't need to "decide" to do it. The structure executes automatically.
Second, external verification. Instead of the same AI reviewing its own code, a separate AI model performs verification. This structurally bypasses the limitations of self-monitoring.
Third, human approval. All write operations (code changes, deployments, structural changes) require human approval. Reading and verification are automatic, but execution happens only after approval.
When these three combine, AI remains free to analyze and suggest, but execution only happens in a controlled environment.
• • •
Who Is This Framework For
The Harness delivers the most value in specific situations.
Solo Founders
If you're using AI as your CTO, designer, and QA simultaneously. If you need to maintain quality while managing everything alone.
Small Teams (2-5 people)
If you're using AI like a team member but lack people to systematically verify AI output.
AI-Heavy Projects
Projects where 80%+ of code is AI-generated. Where quality management of AI output directly determines project success or failure.
Anyone Interested in AI Governance
If you see AI not as a simple tool but as "an agent that needs to be managed."
The Harness is open source. We're sharing the exact structure that was validated in production over 4 months. It's not perfect. We improve it every day. But we believe it can serve as one practical answer to the question: "How do you maintain quality while having AI do the work?"
In the next post, we'll discuss how 18 rules were compressed into 5 core principles. Why 13 were deleted, and why these specific 5 remained.
