GitHub에서 AI 거버넌스를 검색하면, 수만 개의 스타를 받은 레포지토리가 줄줄이 나옵니다. 규모로 보면 CX 하네스는 비교 대상이 안 됩니다.
그런데 하나 물어보겠습니다. 그 레포지토리의 규칙들이 실제 프로덕션 환경에서 검증된 적이 있습니까?
• • •
AI 거버넌스의 현재
2025~2026년 현재, AI 코딩 어시스턴트를 위한 거버넌스 자료는 크게 세 가지 유형으로 나뉩니다.
유형 1: 규칙 컬렉션. 커뮤니티가 큐레이션한 AI 지시문 모음집입니다. 수만 개의 스타를 받은 레포지토리들이 여기에 속합니다. "이런 규칙을 적으면 AI가 잘 작동한다"는 경험을 모은 것이죠.
유형 2: 프레임워크 템플릿. 구조화된 설정 파일과 워크플로우를 제공하는 프레임워크입니다. 단순 규칙 모음보다 한 단계 진화한 형태이지만, 대부분 템플릿 수준에 머뭅니다.
유형 3: 실전 검증 프레임워크. 실제 프로덕션 환경에서 수개월간 운영하며 검증된 프레임워크입니다. CX 하네스가 여기에 해당합니다.
| 항목 |
규칙 컬렉션 |
프레임워크 템플릿 |
실전 검증 |
| 커뮤니티 | 수만 스타 | 수천 스타 | 소규모 |
| 구조적 강제 | 없음 | 부분적 | 다층 자동 검증 |
| 실패 기록 | 없음 | 없음 | 구체적 사고 기록 |
| 프로덕션 검증 | 미검증 | 미검증 | 4개월+ 운영 |
• • •
규칙 컬렉션의 한계
규칙 컬렉션의 가치는 분명합니다. 시작점으로서 훌륭합니다. "AI에게 어떤 지시를 내려야 하는지" 모를 때, 다른 사람들이 정리한 규칙을 참고하면 빠르게 시작할 수 있습니다.
하지만 한계도 명확합니다.
규칙을 적는 것과 규칙을 강제하는 것은 다릅니다. "코드 수정 전에 기존 상태를 확인하라"는 규칙을 설정 파일에 적을 수 있습니다. 하지만 AI가 그 규칙을 어겼을 때 어떻게 됩니까? 아무 일도 일어나지 않습니다. 사람이 발견해서 지적하기 전까지는요.
규칙 간 충돌을 해결하는 메커니즘이 없습니다. "빠르게 진행하라"와 "신중하게 검토하라"가 동시에 있으면 AI는 어떤 걸 우선시할까요? 규칙 컬렉션은 이런 충돌에 대한 해답을 제공하지 않습니다.
규칙이 왜 존재하는지 맥락이 없습니다. "승인 없이 파일을 수정하지 마라"라는 규칙은, 승인 없이 수정했다가 프로덕션 서비스가 터진 경험이 있어야 진짜 무게를 가집니다. 맥락 없는 규칙은 형식적으로 따르다가 중요한 순간에 무시됩니다.
• • •
프레임워크 템플릿의 한계
프레임워크 템플릿은 규칙 컬렉션보다 한 단계 발전한 형태입니다. 구조화된 설정 파일, 워크플로우 정의, 역할 분담 등을 제공합니다.
하지만 대부분 "이론적으로 이렇게 하면 좋다"는 수준에 머뭅니다.
전투 계획은 첫 교전 순간 쓸모없어진다. 프레임워크도 마찬가지입니다.
프레임워크 템플릿의 가장 큰 문제는, 실제 프로덕션에서 어떤 상황이 발생하는지 경험하지 못한 상태에서 설계됐다는 점입니다. AI가 새벽 3시에 설정 파일을 덮어쓰는 상황, 승인을 "하겠습니다"라고 해놓고 승인 없이 진행하는 상황, 범위를 슬금슬금 확장해서 요청하지 않은 파일까지 건드리는 상황. 이런 것들은 실제로 겪어봐야 알 수 있습니다.
그래서 프레임워크 템플릿은 "잘 되는 경우"는 커버하지만 "일이 틀어지는 경우"에 대한 대비가 부족합니다. 실전에서 거버넌스가 정말 필요한 순간은 바로 그 "틀어지는 경우"입니다.
• • •
실전 검증이란
"실전 검증"이라는 말을 쓸 때, 저는 매우 구체적인 의미로 사용합니다.
모든 원칙이 특정 사고에서 비롯됐다. CX 하네스의 핵심 원칙 5개는 각각 구체적인 실패 사례에서 나왔습니다. "CEO 전건 승인"은 승인 없이 코드를 수정해서 서비스가 깨진 사고에서. "AS-IS 먼저"는 기존 상태를 확인하지 않고 코드를 덮어써서 데이터가 유실된 사고에서. 이론이 아니라 흉터입니다.
진화 기록이 존재한다. 규칙 18개 → 원칙 5개로 압축한 과정, 자동 트리거 7개 → 2개로 정리한 과정, C-Suite 8인 → 5인으로 줄인 과정. 이 모든 변화에는 "왜 바꿨는가"에 대한 기록이 있습니다.
실패 기록이 공개돼 있다. 대부분의 프레임워크는 "이렇게 하면 잘 됩니다"만 보여줍니다. CX 하네스는 "이렇게 했더니 이렇게 터졌습니다"도 공개합니다. 실패에서 배우는 것이 더 값지기 때문입니다.
• • •
CX 하네스의 차별점
솔직하게 정리하겠습니다.
CX 하네스만의 것
실패 기록 공개
구체적인 사고 일시, 원인, 대응을 모두 기록
진화 타임라인
5주간의 단계적 성숙 과정이 기록으로 남아 있음
C-Suite 토론 시스템
5개 관점의 교차 검증 + 신호등 체계
프로덕션 SaaS에서 4개월+ 운영
실제 유저가 사용하는 서비스를 이 프레임워크로 운영 중
다른 프레임워크에서는 "이렇게 하라"고 합니다. CX 하네스에서는 "우리가 이렇게 했더니 이런 일이 벌어졌고, 그래서 이렇게 바꿨다"고 합니다. 이 차이가 핵심입니다.
• • •
솔직한 한계
공정하게 이야기해야 합니다. CX 하네스에는 명확한 한계가 있습니다.
1인 운영에 최적화돼 있습니다. 이 프레임워크는 1인 창업자가 AI와 협업하는 환경에서 만들어졌습니다. 팀 단위 개발 환경에서는 승인 모델, C-Suite 시스템 등이 다르게 설계돼야 합니다.
커뮤니티 검증이 부족합니다. 수만 스타를 받은 레포지토리는 수천 명의 개발자가 사용하면서 피드백을 줬습니다. CX 하네스는 아직 1명(저)의 경험에 기반합니다.
특정 도구에 맞춰져 있습니다. 현재 CX 하네스는 특정 AI 코딩 어시스턴트 환경에 맞춰 설계됐습니다. 다른 도구에서는 자동 트리거, 검증 에이전트 등의 구현 방식이 달라져야 합니다.
이 한계들을 숨기지 않는 이유는 단순합니다. 한계를 아는 것이 프레임워크를 올바르게 사용하는 첫 걸음이기 때문입니다.
• • •
왜 공개하는가
CX 하네스를 공개하는 이유는 경쟁 우위를 위해서가 아닙니다.
AI와 함께 일하는 사람이 점점 많아지고 있습니다. 그리고 대부분은 제가 1주차에 겪은 것과 같은 좌절을 겪고 있습니다. "규칙을 적었는데 안 지켜진다." "사과만 하고 같은 실수를 반복한다." "어떻게 해야 할지 모르겠다."
저는 그 과정을 5주간 겪었고, 구조적 해결책을 찾았습니다. 이 경험을 공유하면 다른 사람들이 같은 시행착오를 줄일 수 있습니다.
최고의 프레임워크는 실전에서 깨지고, 고쳐지고, 다시 깨지면서 만들어집니다. 그 과정 자체를 공유하는 것이 가장 큰 가치입니다.
물론 CX 하네스가 정답은 아닙니다. 하지만 "실전에서 검증된 하나의 답"이라는 점에서 참고할 가치가 있다고 생각합니다. 여러분의 환경에 맞게 수정하고, 더 나은 프레임워크를 만들어주시면 됩니다.
규칙 컬렉션에서 시작해도 좋고, 프레임워크 템플릿에서 시작해도 좋습니다. 중요한 건, 거기서 멈추지 않고 실전에서 계속 발전시키는 것입니다.
Search for AI governance on GitHub, and repositories with tens of thousands of stars line up. In terms of scale, CX Harness is not even in the same league.
But let me ask one question. Have the rules in those repositories ever been validated in an actual production environment?
• • •
AI Governance Today
As of 2025-2026, governance resources for AI coding assistants fall into three main types.
Type 1: Rule Collections. Community-curated collections of AI instructions. The repositories with tens of thousands of stars fall here. Collections of "write these rules and AI works well" experiences.
Type 2: Framework Templates. Frameworks providing structured configuration files and workflows. A step beyond simple rule collections, but most remain at the template level.
Type 3: Battle-Tested Frameworks. Frameworks validated through months of operation in actual production environments. CX Harness belongs here.
| Aspect |
Rule Collections |
Framework Templates |
Battle-Tested |
| Community | Tens of thousands of stars | Thousands of stars | Small scale |
| Structural Enforcement | None | Partial | Multi-layer auto verification |
| Failure Records | None | None | Specific incident records |
| Production Validation | Unvalidated | Unvalidated | 4+ months in operation |
• • •
Limits of Rule Collections
The value of rule collections is clear. They are excellent starting points. When you do not know "what instructions to give AI," referencing rules others have compiled lets you start quickly.
But the limitations are equally clear.
Writing rules and enforcing rules are different. You can write "check current state before modifying code" in a configuration file. But what happens when AI violates that rule? Nothing. Not until a human discovers and flags it.
No mechanism for resolving rule conflicts. If "proceed quickly" and "review carefully" both exist, which does AI prioritize? Rule collections provide no answer to such conflicts.
No context for why rules exist. The rule "do not modify files without approval" only carries real weight when backed by the experience of a production service breaking because files were modified without approval. Context-free rules are followed formally until they are ignored at critical moments.
• • •
Limits of Framework Templates
Framework templates are one step beyond rule collections. They provide structured configuration files, workflow definitions, and role assignments.
But most remain at the level of "in theory, this should work well."
No battle plan survives first contact with the enemy. Frameworks are the same.
The biggest problem with framework templates is that they are designed without experiencing what actually happens in production. Situations where AI overwrites a configuration file at 3 AM, says "I will proceed" then executes without waiting for approval, or gradually expands scope to touch unrequested files. You can only know these things by living through them.
So framework templates cover "when things go right" but lack preparation for "when things go wrong." In practice, governance is needed most precisely in those "going wrong" moments.
• • •
What Battle-Tested Means
When I use the term "battle-tested," I mean something very specific.
Every principle originated from a specific incident. Each of CX Harness's 5 core principles came from a concrete failure. "CEO approval for all actions" came from a service-breaking incident where code was modified without approval. "AS-IS first" came from data loss when code was overwritten without checking current state. These are not theory — they are scars.
Evolution records exist. The process of compressing 18 rules to 5 principles, refining 7 auto-triggers to 2, reducing C-Suite from 8 to 5 members. Every change has a record of "why it was changed."
Failure records are public. Most frameworks only show "do this and it works." CX Harness also shares "we did this and it broke." Because learning from failure is more valuable.
• • •
CX Harness Differentiators
Let me lay it out honestly.
What Only CX Harness Has
Public failure records
Specific incident dates, causes, and responses all documented
Evolution timeline
5 weeks of step-by-step maturation documented
C-Suite debate system
5-perspective cross-verification + traffic light system
4+ months operating a production SaaS
A service with real users is being run with this framework
Other frameworks say "do it this way." CX Harness says "we did it this way, this is what happened, and here is how we changed." That difference is the core.
• • •
Honest Limitations
To be fair, CX Harness has clear limitations.
Optimized for solo operation. This framework was built in an environment where a solo founder collaborates with AI. In team development environments, the approval model and C-Suite system would need to be designed differently.
Lacks community validation. Repositories with tens of thousands of stars have been used by thousands of developers who provided feedback. CX Harness is still based on 1 person's (my) experience.
Tailored to specific tools. CX Harness is currently designed for a specific AI coding assistant environment. With other tools, auto-triggers, verification agents, and other implementations would need to differ.
The reason for not hiding these limitations is simple. Knowing the limitations is the first step to using the framework correctly.
• • •
Why We Share
We are not sharing CX Harness for competitive advantage.
More and more people are working with AI. And most are experiencing the same frustrations I went through in Week 1. "I wrote rules but they are not followed." "It apologizes and repeats the same mistake." "I do not know what to do."
I went through that process for 5 weeks and found structural solutions. Sharing this experience helps others reduce the same trial and error.
The best frameworks are built by breaking in production, being fixed, and breaking again. Sharing the process itself is the greatest value.
Of course, CX Harness is not the answer. But as "one answer validated in production," we believe it is worth referencing. Adapt it to your environment and build something better.
Starting from rule collections is fine. Starting from framework templates is fine too. What matters is not stopping there, but continuing to evolve through real-world practice.
