AI의 모든 행동을 승인하면 안전하지만 아무 일도 못 합니다. 승인 없이 놔두면 빠르지만 재앙이 터집니다. 이 딜레마를 어떻게 풀었는지 이야기합니다.
• • •
승인 피로라는 문제
처음 AI와 일하기 시작했을 때는 모든 걸 확인했습니다. 파일을 읽는 것도, 코드를 쓰는 것도, 테스트를 돌리는 것도. AI가 한 줄을 바꿀 때마다 "이거 맞아?"를 확인했습니다.
일주일이면 지칩니다.
하루에 AI와 주고받는 상호작용이 수백 번입니다. 그 중 90%는 위험하지 않은 행동입니다. 파일 읽기, 구조 분석, 상태 확인. 이런 것까지 일일이 승인하면 AI를 쓰는 의미가 없어집니다. 혼자 하는 게 더 빠릅니다.
승인 피로가 쌓이면 결국 "그냥 해"라고 하게 됩니다. 그리고 그 순간 사고가 터집니다.
이게 승인 피로의 진짜 위험입니다. 피로가 쌓이면 판단력이 떨어지고, 중요한 순간에도 대충 승인하게 됩니다. "아 이것도 괜찮겠지"하고 넘기는 순간, 프로덕션 설정이 덮어씌워지거나, 의도하지 않은 파일이 삭제됩니다.
• • •
승인 없이는 재앙
그렇다고 승인을 없앨 수는 없습니다. 실제로 겪은 일들입니다.
설정 파일 덮어쓰기. AI가 "최적화"를 위해 설정 파일을 수정했는데, 기존 설정 값들이 초기화됐습니다. 서비스에 의존하는 외부 시스템과의 연동이 깨졌습니다.
범위 확장. "이 함수를 수정해달라"고 했는데, AI가 "관련된 다른 함수도 같이 수정하는 게 좋겠다"고 판단해서 요청하지 않은 파일 5개를 건드렸습니다. 의도치 않은 사이드 이펙트가 발생했습니다.
승인 우회. "~하겠습니다"라고 보고만 하고, 승인을 기다리지 않고 바로 실행하는 패턴. 형식적으로는 보고했지만 실질적으로는 무단 실행이었습니다.
승인 부재로 발생한 사고 유형
세 가지 모두 "승인 절차가 있었으면 막을 수 있었던" 사고입니다.
이런 경험을 하고 나면, "모든 걸 승인하겠다"는 쪽으로 돌아가고 싶어집니다. 하지만 그러면 다시 승인 피로가 쌓이고, 악순환이 반복됩니다.
• • •
위험도 기반 분류
해결책은 행동을 위험도에 따라 분류하는 것이었습니다.
모든 행동이 같은 위험도를 가지지 않습니다. 파일을 읽는 것과 파일을 수정하는 것은 근본적으로 다릅니다. 코드를 수정하는 것과 프로덕션에 배포하는 것도 다릅니다.
| 위험도 |
행동 유형 |
승인 방식 |
예시 |
| 낮음 |
읽기, 검증, 분석 |
자동 진행 |
파일 읽기, 상태 확인 |
| 중간 |
쓰기, 수정 |
"~하겠습니다. Y/N?" |
코드 변경, 파일 생성 |
| 높음 |
배포, 삭제, 외부 전송 |
체크리스트 + 서명 |
프로덕션 배포, 데이터 삭제 |
이 분류의 핵심은 "되돌릴 수 있는가"입니다. 파일을 읽는 건 아무 부작용이 없으니 자동으로 해도 됩니다. 코드를 수정하는 건 git으로 되돌릴 수 있지만 사이드 이펙트가 있을 수 있으니 승인이 필요합니다. 배포는 되돌리기 어렵고 실제 유저에게 영향을 주니 전체 체크리스트가 필요합니다.
중간 위험도의 승인 방식이 중요합니다. AI가 "X를 수정하겠습니다. Y/N?"이라고 묻고, 사람이 Y를 입력하면 진행합니다. 한 글자로 끝나는 승인이지만, 이 한 글자가 "사람이 확인했다"는 기록을 남깁니다.
• • •
안전과 생산성 사이
이 모델의 실제 효과를 수치로 보겠습니다.
승인 모델 적용 전후
승인 필요 상호작용 비율~20%
80%는 읽기/검증이므로 자동 진행
승인 1건당 소요 시간~3초
Y/N 한 글자 입력
승인 피로 체감대폭 감소
불필요한 승인 80% 제거
전체 상호작용의 약 80%가 읽기/검증이므로 자동으로 처리됩니다. 나머지 20%만 승인하면 됩니다. 그리고 그 20%의 대부분은 "Y"를 입력하는 3초짜리 승인입니다. 전체 체크리스트가 필요한 고위험 행동은 하루에 1~2건 정도입니다.
이 균형이 생산성과 안전성을 동시에 지킵니다. 빠르게 움직이되, 위험한 순간에는 반드시 사람이 확인합니다.
• • •
신뢰의 역설
여기서 역설적인 이야기를 하나 해야 합니다.
AI가 신뢰를 쌓을수록, 더 조심해야 합니다.
AI가 실수 없이 10번 연속으로 작업을 완료하면, 사람은 자연스럽게 경계를 풉니다. "이 정도면 믿어도 되겠지." 그리고 11번째에 사고가 터집니다.
이건 AI의 문제가 아닙니다. 사람의 인지 편향 문제입니다. "최근에 잘 됐으니까 앞으로도 잘 되겠지"라는 확증 편향. 성공 경험이 쌓일수록 이 편향은 강해집니다.
그래서 승인 모델은 "신뢰가 쌓이면 승인을 줄이는" 방식이 아닙니다. 위험도 분류는 AI의 신뢰도와 무관하게 적용됩니다. AI가 아무리 잘 하더라도, 쓰기 작업은 승인이 필요하고, 배포는 체크리스트가 필요합니다.
물론 미래에 충분한 무결점 실적이 쌓이면, 승인 기준을 완화하는 것도 고려할 수 있습니다. 하지만 그 판단은 시스템이 아니라 사람(CEO)만 할 수 있습니다. 그리고 완화하더라도, 핵심 고위험 행동의 승인은 절대 제거하지 않습니다.
• • •
1인 창업자를 위한 모델
이 승인 모델이 특히 1인 창업자에게 맞는 이유가 있습니다.
팀이 없습니다. 대기업이라면 코드 리뷰어, QA 팀, DevOps 팀이 각자 검증 단계를 담당합니다. 1인 창업자는 이 모든 역할을 혼자 합니다. AI가 코드를 쓰고, 사람이 승인하는 구조는 사실상 2인 팀의 코드 리뷰 프로세스입니다.
컨텍스트 스위칭이 적습니다. 1인 창업자는 모든 결정의 맥락을 알고 있습니다. "이 수정이 전체 시스템에 어떤 영향을 주는가"를 직관적으로 판단할 수 있습니다. 그래서 승인에 걸리는 시간이 짧습니다. 3초짜리 Y/N이 가능한 이유입니다.
실패 비용이 큽니다. 1인 창업자에게 프로덕션 사고는 치명적입니다. 복구할 팀이 없고, 고객 대응을 혼자 해야 합니다. 그래서 고위험 행동의 승인이 더 중요합니다.
1인 창업자 vs 팀 환경
팀 환경
• PR 리뷰어가 코드 검증
• QA 팀이 테스트 커버
• DevOps가 배포 관리
• 사고 시 팀이 복구
1인 + AI (승인 모델)
• 검증 에이전트가 코드 검증
• 자동화 테스트가 품질 보장
• CEO 승인이 배포 게이트
• 구조가 사고를 사전 차단
팀이 하는 일을 AI + 구조로 대체하는 것. 그것이 승인 모델의 본질입니다.
물론 팀이 커지면 이 모델도 바뀌어야 합니다. 여러 사람이 동시에 AI를 사용하는 환경에서는 승인 권한을 누가 가지는지, 충돌은 어떻게 해결하는지 등 새로운 문제가 생깁니다. 그건 팀이 생겼을 때 고민할 문제입니다.
지금은 1인 창업자와 AI가 안전하게, 빠르게, 지속 가능하게 일하는 것. 그것이 이 모델의 목표이고, 4개월간의 운영으로 그 목표가 달성 가능하다는 것을 확인했습니다.
Approve every AI action, and you are safe but nothing gets done. Let it run free, and it is fast but disasters strike. This is how we solved the dilemma.
• • •
The Problem of Approval Fatigue
When I first started working with AI, I checked everything. Reading files, writing code, running tests. Every time the AI changed a single line, I verified: "Is this correct?"
It takes about a week to burn out.
There are hundreds of interactions with AI per day. 90% of them are non-risky actions: reading files, analyzing structure, checking status. If you approve each of these individually, using AI becomes pointless. Doing it yourself would be faster.
When approval fatigue builds up, you eventually say "just do it." And that is exactly when incidents happen.
This is the real danger of approval fatigue. As fatigue accumulates, judgment deteriorates, and you start rubber-stamping even critical decisions. The moment you think "this one's probably fine too," production settings get overwritten or unintended files get deleted.
• • •
Without Approval, Disaster
But you cannot eliminate approvals either. These are real incidents that happened.
Configuration file overwrite. The AI modified a configuration file for "optimization," and existing settings were reset to defaults. Integrations with external systems that depended on the service broke.
Scope creep. I asked to "modify this function," but the AI decided "it would be better to modify related functions too" and touched 5 files that were never requested. Unintended side effects followed.
Approval bypass. A pattern of reporting "I will proceed with..." without waiting for approval before executing. Formally it was reported, but in practice it was unauthorized execution.
Incident Types from Missing Approvals
Config/Data OverwriteCritical
Scope Deviation (Unrequested Changes)High
Approval Bypass (Report then Execute)High
All three were incidents that "could have been prevented with an approval process."
After experiences like these, you want to go back to "approve everything." But then approval fatigue builds up again, and the vicious cycle repeats.
• • •
Risk-Based Classification
The solution was to classify actions by risk level.
Not all actions carry the same risk. Reading a file and modifying a file are fundamentally different. Modifying code and deploying to production are also different.
| Risk Level |
Action Type |
Approval Method |
Example |
| Low |
Read, Verify, Analyze |
Auto-proceed |
Read files, check status |
| Medium |
Write, Modify |
"I will do X. Y/N?" |
Code changes, file creation |
| High |
Deploy, Delete, External Send |
Checklist + Sign-off |
Production deploy, data deletion |
The key principle of this classification is "Can it be reversed?" Reading a file has no side effects, so it can proceed automatically. Modifying code can be reverted with git but may have side effects, so approval is needed. Deployment is hard to reverse and directly impacts real users, so a full checklist is required.
The approval method for medium-risk actions is key. The AI asks "I will modify X. Y/N?" and the person types Y to proceed. It is a single-character approval, but that one character creates a record that "a human verified this."
• • •
Between Safety and Productivity
Let us look at the real-world impact of this model in numbers.
Before and After the Approval Model
% of Interactions Requiring Approval~20%
80% are read/verify operations, auto-processed
Time per Approval~3 sec
Single character Y/N input
Perceived Approval FatigueSignificantly Reduced
80% of unnecessary approvals eliminated
About 80% of all interactions are read/verify operations handled automatically. Only the remaining 20% need approval. Most of those are 3-second "Y" inputs. High-risk actions requiring a full checklist occur about 1-2 times per day.
This balance preserves both productivity and safety. Move fast, but always have a human verify at critical moments.
• • •
The Paradox of Trust
Here is a paradox that needs to be addressed.
The more trust AI builds, the more careful you need to be.
When AI completes 10 tasks in a row without error, people naturally lower their guard. "It's reliable enough by now." Then the 11th task produces an incident.
This is not an AI problem. It is a human cognitive bias problem. The confirmation bias of "it worked recently, so it will keep working." The more success accumulates, the stronger this bias becomes.
That is why the approval model does not "reduce approvals as trust builds." Risk classification applies regardless of AI reliability. No matter how well the AI performs, write operations need approval and deployment needs a checklist.
Of course, in the future, a sufficient track record of flawless performance could justify relaxing approval criteria. But that decision can only be made by a human (the CEO), not the system. And even when relaxed, approvals for core high-risk actions are never removed.
• • •
A Model for Solo Founders
There are specific reasons why this approval model is especially suited for solo founders.
There is no team. In a large company, code reviewers, QA teams, and DevOps teams each handle verification stages. A solo founder does all of this alone. The structure where AI writes code and a human approves is effectively a 2-person team's code review process.
Context switching is minimal. A solo founder knows the context of every decision. They can intuitively assess "how does this change affect the entire system?" This is why approval time is short. That is what makes the 3-second Y/N possible.
The cost of failure is high. For a solo founder, a production incident is devastating. There is no team to recover, and customer support falls entirely on one person. That makes high-risk action approval even more critical.
Solo Founder vs Team Environment
Team Environment
• PR reviewers verify code
• QA team covers testing
• DevOps manages deployment
• Team recovers from incidents
Solo + AI (Approval Model)
• Verification agents review code
• Automated tests ensure quality
• CEO approval gates deployment
• Structure prevents incidents proactively
Replacing what a team does with AI + structure. That is the essence of the approval model.
Of course, as the team grows, this model must evolve. In an environment where multiple people use AI simultaneously, new questions arise: who holds approval authority, how are conflicts resolved? Those are problems for when the team exists.
For now, the goal is for a solo founder and AI to work safely, quickly, and sustainably together. That is this model's objective, and 4 months of operation have confirmed it is achievable.
