단계적 납품 불가
완전한 인증 시스템을 요청하면 AI가 "일단 간단한 아이디/비밀번호 로그인부터 만들고, OAuth는 나중에 추가해요"라고 말합니다. 그 나중은 결코 오지 않습니다. 이 강에서는 두 가지 데모를 통해 "간단한 버전 먼저"의 전체 라이프사이클을 살펴보고, 올바른 대응 방법을 연습합니다.
실제로 AI가 "간단한 버전부터"라고 말할 때 이는 복잡성과 거의 무관합니다. AI는 빠르게 실행 가능한 것을 보여줌으로써 긍정적인 피드백을 얻으려 합니다. "임시 방안 사용", "일단 Mock", "간단하게 처리" — 이 모든 것은 같은 패턴입니다. 이 패턴을 깨면 AI가 오히려 완전한 방안을 더 진지하게 분석합니다.
재생을 클릭하여 "간단한 버전 먼저" 로그인 모듈이 90일 동안 어떻게 영구 기술 부채가 되는지 확인하세요. 위의 두 숫자가 타임라인과 함께 변합니다.
간단한 버전 출시
아이디/비밀번호 로그인이 작동됩니다. AI는 "OAuth는 나중에 추가할게요"라고 약속하고, 당신도 합리적이라고 생각합니다.
"나중에"는 오지 않았다
새로운 요구사항이 계속 들어오고 OAuth를 추가하러 돌아오는 사람이 없습니다. 세션, 권한, 결제, 알림 4개 모듈이 간단한 인터페이스에 직접 의존하기 시작합니다.
영구 기술 부채가 되다
완성하려 할 때 의존성이 이미 굳어져 있음을 발견합니다. 9개 모듈이 간단한 버전과 결합되어 리팩토링 비용이 전면 재작성보다 높습니다. 간단한 버전이 영구 버전이 되었습니다.
AI가 단계적 방안을 제안했습니다. 당신의 대응이 90일 후의 결과를 결정합니다. 두 분기 모두 시도해 보세요.
금지된 방법
어떤 이유로도 구현 단순화는 금지됩니다: "임시 방안 사용", "나중에 최적화", "일단 Mock", "간단하게 처리" 모두 허용되지 않습니다. AI가 자발적으로 단계적 납품, MVP, 1/2/3단계를 계획하는 것도 금지됩니다. 모든 구현은 완전하고 올바르며 코드 부채가 없어야 합니다.
권장 방법
기능 평가는 두 가지만 답하면 됩니다: 완전히 구현하는 데 무엇이 필요한지, 얼마나 복잡한지. 정말 너무 복잡할 때는 "먼저 해야 할 전제 결정사항"을 명확히 나열하여 선택권을 인간에게 돌려줍니다. 알려진 결함이 있는 방안의 경우 바로 올바른 버전을 제공하세요. 임시방편 방안을 먼저 만들지 마세요.
대형 프로젝트에서 이 규칙은 지나치게 엄격해 보일 수 있습니다: 기능이 정말로 2000줄의 코드가 필요할 때 한 번에 완성하는 것은 현실적이지 않습니다. 그래도 올바른 행동은 여전히 유효합니다 — AI가 완전한 방안과 실제 작업량을 제공하고, 인간이 분할 여부와 방법을 결정합니다. 분할은 인간의 결정이고, 다운그레이드는 AI의 독단적인 행동입니다. 이 차이가 이 규칙의 핵심입니다.
"나중에 최적화" — 그 나중은 결코 오지 않습니다. 선택권을 되찾으세요: AI는 완전한 방안과 실제 비용을 제공하는 책임이 있고, 분할 여부와 방법은 인간이 결정합니다.