The95PercentRule
주니어 개발자들을 위한 패턴 언어 - 마지막 5%의 자동화를 포기하고 단순함을 선택하는 지혜
Contents
The Story 1: The Migration Script Trap (Programming)
한 주니어 개발자가 레거시 DB를 새로운 시스템으로 마이그레이션하는 스크립트를 짜고 있었다. "95%는 완료됐어요. 그런데 나머지 5% 데이터가 문제입니다." 그는 수백 줄의 복잡한 예외 처리 코드를 가리켰다. "50건 정도의 데이터가 형식이 제멋대로라 이걸 자동으로 보정하는 알고리즘을 짜고 있어요. 3일째 이것만 하고 있네요." 시니어가 답했다. "50건 고치는 데 직접 하면 30분이면 돼. 네가 짠 그 복잡한 코드를 유지보수하는 비용은 3년이 갈 거고. 자동화의 목적은 '100% 자동'이 아니라 '시간 절약'이야." 주니어는 복잡한 코드를 다 지우고 에러 로그만 남겼다. 마이그레이션은 그날 오후에 끝났다.
The Story 2: The Perfect Garden (Ordinary Life)
민수와 하나는 각자 마당에 '정원'을 가꾸고 있다.
민수의 정원 (The 100% Perfectionist): 민수는 정원에 잡초가 단 하나도 있는 것을 용납하지 못한다. 그는 매일 아침부터 저녁까지 핀셋을 들고 아주 작은 풀 한 포기까지 뽑아낸다. "완벽한 정원을 만들어야 해." 하지만 민수는 잡초를 뽑느라 정작 꽃에 물을 주거나 나무를 가꿀 시간이 없었다. 민수의 정원은 잡초는 없었지만, 주인은 지쳐버렸고 꽃들도 생기를 잃었다.
하나의 정원 (The 95% Pragmatist): 하나는 큰 잡초들만 눈에 띌 때 솎아낸다. "95% 정도만 깔끔하면 충분해. 남은 5%의 작은 풀들은 자연스러운 풍경의 일부라고 생각하자." 하나는 잡초 뽑기에 쏟을 에너지를 아껴 새로운 꽃을 심고 나무를 전정했다. 하나의 정원은 완벽하게 매끈하지는 않았지만, 항상 꽃이 피어있고 생명력이 넘쳤다. 마지막 5%의 완벽함에 집착하지 않을 때 더 큰 가치를 돌볼 수 있음을 하나는 알고 있었다.
Context
당신은 반복적인 작업을 자동화하거나 도구를 만들고 있다. 처음 90~95%의 케이스를 처리하는 것은 쉽고 빨랐다. 하지만 남은 소수의 엣지 케이스 (Edge Case), 불규칙한 데이터, 주관적 판단이 필요한 부분들이 발목을 잡는다.
일상적인 상황:
- "이것만 자동화하면 완벽한데..."라며 며칠을 보낸다.
예외 처리를 위해 메인 로직보다 더 큰 if-else 블록을 만든다.
- 자동화 도구를 만들었는데, 너무 복잡해서 동료들이 쓰기 어려워한다.
- "완전 자동화"라는 로망에 사로잡혀 있다.
Problem
마지막 5%를 자동화하는 비용은 종종 나머지 95%를 합친 것보다 비싸다. 이를 무리하게 자동화하려다 시스템의 복잡도가 폭발하고 유지보수가 불가능해진다.
The Complexity Curve
자동화의 비용 곡선은 선형이 아니라 지수적입니다.
- 0% → 80% 자동화: 매우 쉬움 (Happy Path)
- 80% → 95% 자동화: 적당한 노력 (Common Edge Cases)
- 95% → 100% 자동화: 엄청난 비용 (Chaos, Human Judgment)
마지막 5%는 보통 규칙성이 없거나, 문맥 파악이 필요하거나, 외부 요인에 의존합니다. 이를 코드로 해결하려면 배보다 배꼽이 더 커집니다.
The Fragility of 100%
마지막 5%까지 처리하려고 억지로 끼워 맞춘 로직은 매우 취약(Brittle)합니다. 데이터 형식이 조금만 바뀌어도 스크립트 전체가 깨집니다. 결과적으로 "완전 자동화" 도구는 신뢰를 잃고, 아무도 쓰지 않게 됩니다.
Solution
의도적으로 불완전한 자동화 (Semi-Automation)를 선택하라. 기계가 잘하는 95%는 기계에게, 사람이 잘하는 5%는 사람에게 맡겨라.
Principle 1: Distinguish the Goal
먼저 질문하십시오. "이것은 사람의 개입 없이 돌아가야 하는가 (Unattended)?"
YES (e.g., CI/CD Pipeline): 이때는 100% 자동화가 필수입니다. 입력을 엄격하게 통제하여 100%를 달성하십시오.
NO (e.g., Migration, Report Gen): 사람이 실행 버튼을 누르는 도구라면 95%까지만 해주고 "나머지는 네가 확인해"라고 넘기는 것이 현명합니다.
Principle 2: The Human-in-the-Loop Pattern
가장 강력한 패턴은 "기계가 초안을 잡고(Draft), 사람이 검수/완료(Finalize)하는 것"입니다.
- 기계가 확실한 것만 처리하고, 애매한 것은 "검토 필요" 폴더로 뺍니다. 이것은 100% 자동화보다 훨씬 만들기 쉽고 유연하며 결과물의 품질도 높습니다.
Principle 3: Stop at the "Knee of the Curve"
노력 대비 효과 그래프에서 기울기가 꺾이는 지점(Knee)에서 멈추십시오. 남은 작업이 수동으로 10분 내외라면, 자동화를 멈추는 것이 경제적입니다.
Principle 4: Make the Manual Part Easy
자동화를 포기하는 대신, 수작업을 편하게 만드십시오. "처리 못한 50건은 review_needed.csv에 저장했습니다. 열어서 확인하고 다시 돌리세요"와 같은 친절한 반자동 시스템을 지향하십시오.
Real Examples
Example 1: The Daily Report
표준 서식은 자동 처리하고, 이상한 서식이 발견되면 경고를 띄우고 멈추는 시스템. 사람이 1분만 개입하면 복잡한 파서 없이도 보고서를 완성할 수 있다.
Example 2: Code Migration Tool
Java 코드를 Kotlin으로 바꿀 때 IDE의 자동 변환 기능을 쓴 뒤, 빨간 줄(에러)이 뜨는 몇 군데만 개발자가 직접 수정하는 방식. 완벽한 변환기보다 10배 빠르다.
Common Pitfalls
"But Manual Work is Bad!"
자동화 자체가 목적이 아니라 문제 해결이 목적임을 기억하십시오. 일회성 작업이나 비용이 높은 작업에서는 수동이 최선일 때가 많습니다.
"I Can Fix This with One More Regex..."
그 정규식 하나가 당신의 코드를 유지보수 불가능한 괴물로 만드는 마지막 지푸라기일 수 있습니다.
Connection to Other Patterns
WorkingFirst - 일단 95%라도 작동하게 만드십시오. 완벽을 기하다가 0%에 머물지 마십시오. 순서
ArtisanMind - 어디서 멈출지 아는 것이 장인의 감각입니다. 기계적 완벽함보다 실용적 가치를 보십시오. 정신
TinyExperiment - 5%를 자동화하는 게 얼마나 걸릴지 작게 실험해보고, 견적이 안 나오면 포기하십시오. 탐색
ComplexityTaming - 95%에서 멈추는 것은 시스템의 복잡성을 관리하는 핵심 전략입니다. 조절
Signs of Success
- 도구가 단순하고 코드가 짧아 이해하기 쉽다.
- 예외 처리가 명확하여 사용자가 당황하지 않는다.
- 엣지 케이스 때문에 밤새 디버깅하는 스트레스가 사라진다.
- "완벽하진 않은데 내 일의 90%를 줄여줘서 너무 편해"라는 피드백을 듣는다.
The Ultimate Insight
전설적인 프로그래머 Tom Cargill의 "90-90 법칙": "코드의 첫 90%는 개발 시간의 90%를 차지한다. 나머지 10%의 코드는 남은 개발 시간의 90%를 차지한다."
마지막 5%는 악마가 사는 곳입니다. 그곳에 들어가지 마십시오. 대신 그 5%를 위한 아름다운 수동 인터페이스를 열어두십시오. 그것이 기계와 인간이 조화롭게 협업하는 방법입니다.
CategoryPatternLanguage CategoryProgramming CategoryAutomation CategoryProductivity