YAGNI 원칙 (You Aren't Gonna Need It) - 미래의 환상을 걷어내는 실용주의 설계

⚠️ 이 문서는 익스트림 프로그래밍(XP)의 핵심 사상 중 하나인 YAGNI 원칙을 다룹니다. "나중에 필요할지도 몰라"라는 추측성 설계가 어떻게 시스템을 비대하게 만들고 개발 속도를 저하시키는지 분석하며, 현재의 가치에 집중하는 기민한 설계 전략을 제시합니다.

핵심 인사이트 (3줄 요약)

본질: YAGNI(You Aren't Gonna Need It)는 실제로 필요하다는 확신이 들기 전까지는 기능을 추가하거나 복잡한 아키텍처를 도입하지 말라는 '과잉 엔지니어링 금지' 원칙이다.

가치: 불필요한 코드 작성 시간을 아끼고, 사용되지 않을 코드의 유지보수 비용과 버그 발생 가능성을 사전에 차단하여 실제 비즈니스 가치 생산에 집중하게 한다.

실행: "미래를 대비한 설계" 대신 "미래에 쉽게 변경할 수 있는 단순한 설계"를 선택하며, 실제 요구사항이 발생했을 때 리팩토링을 통해 기능을 확장한다.

Ⅰ. 개요 (Context & Background)

소프트웨어 개발자들은 종종 "나중에 이 기능이 추가될 거야", "언젠가는 DB를 교체할 수도 있어"라는 가정을 전제로 복잡한 인터페이스와 추상화 계층을 미리 만듭니다. 하지만 통계적으로 이러한 추측성 기능의 80% 이상은 실제로 사용되지 않으며, 남겨진 코드는 짐이 됩니다.

Pain Point: 사용되지 않는 코드는 시스템의 복잡도를 높이고, 테스트 범위를 넓히며, 미래의 진짜 변경을 방해하는 장애물이 됩니다.
도입 목적: 개발 비용 절감, 출시 속도(Time-to-Market) 단축, 그리고 실제 사용자 피드백에 기반한 실질적 기능 고도화를 위함입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

YAGNI는 '추측'을 '현실'로 대체하는 사고방식의 전환입니다.

┌─────────────────────────────────────────────────────────────┐
│                   [ YAGNI Design Strategy ]                 │
│                                                             │
│      [ Speculative Design ]         [ Just-In-Time Design ] │
│      (Future Guessing)              (Current Reality)       │
│             │                              │                │
│   ┌─────────▼─────────┐          ┌─────────▼─────────┐      │
│   │ Abstract Interface│          │ Concrete Impl.    │      │
│   │ Extra Parameters  │          │ Minimum Params    │      │
│   │ Complex Framework │          │ Simple Script     │      │
│   └─────────┬─────────┘          └─────────┬─────────┘      │
│             │                              │                │
│       [ Waste of Time ]             [ Rapid Delivery ]      │
│       [ High Maintenance ]          [ Agile Pivot OK ]      │
│                                                             │
│  ※ Motto: "Do the simplest thing that could possibly work   │
│    right now, and refactor later when needed."              │
└─────────────────────────────────────────────────────────────┘

1. YAGNI의 3가지 핵심 실천법

요구사항 기반 구현: 명문화된 사용자 스토리나 티켓이 없는 기능은 절대 코딩하지 않습니다.
단순한 시작: 처음부터 확장을 고려한 거대한 프레임워크를 도입하기보다, 현재 문제를 해결하는 가장 작은 코드로 시작합니다.
진화적 아키텍처 (Evolutionary Architecture): 미래를 위해 복잡하게 설계하는 대신, 나중에 구조를 바꾸기 쉽도록 결합도를 낮추는(Decoupling) 것에만 집중합니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

YAGNI와 관련 설계 원칙들을 비교합니다.

구분	YAGNI (추측 방지)	DRY (중복 방지)	KISS (복잡 방지)
관점	미래의 시간 낭비 방지	현재의 로직 일관성 확보	현재의 이해 가능성 확보
행동	"아직 만들지 마라"	"똑같이 만들지 마라"	"어렵게 만들지 마라"
실수 사례	"나중에 쓸 필드를 미리 추가"	"서로 다른 로직을 억지로 통합"	"디자인 패턴 10개를 겹쳐 사용"

트레이드오프: YAGNI를 너무 극단적으로 적용하면 나중에 구조를 바꿀 때 비용이 더 많이 들 수 있습니다. 따라서 **"확장성을 미리 만드는 것"**과 **"확장 가능한 상태를 유지하는 것"**의 차이를 아는 것이 중요합니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

1. 감리 및 기술사적 관점의 판단

기능 범위 검증: 감리 시 과업지시서(SOW)에 없는 기능이 포함되어 있다면 리소스 낭비로 간주할 수 있습니다. 특히 공공 사업에서 "추후 확장을 고려한 과도한 아키텍처"는 예산 낭비의 근거가 될 수 있습니다.
애자일 성숙도: 팀이 YAGNI를 실천하고 있다면, 이는 강력한 테스트 자동화와 리팩토링 역량을 갖추고 있다는 신호입니다. 구조 변경에 대한 두려움이 없어야 YAGNI가 가능하기 때문입니다.

2. 실무 적용 가이드

데이터베이스 스키마: "나중에 쓸 것 같은 컬럼" extra_1, extra_2 등을 만들지 않습니다.
API 파라미터: 현재 비즈니스 로직에서 쓰지 않는 필드는 요청/응답에서 제외합니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

YAGNI를 준수하면 소프트웨어는 가볍고(Lean) 기민해집니다. 변화가 일상인 현대 IT 환경에서 가장 위험한 것은 "잘못된 예측에 기반한 거대한 성벽"입니다.

미래 전망: 마이크로서비스(MSA) 환경에서 각 서비스가 자신의 최소 기능에만 집중하는 것은 YAGNI의 아키텍처적 발현입니다. 필요한 기능은 다른 서비스를 추가하거나 조합함으로써 해결합니다.
결론: 소프트웨어 개발에서 가장 빠른 코드는 **"작성하지 않은 코드"**입니다.

📌 관련 개념 맵 (Knowledge Graph)

익스트림 프로그래밍 (XP): 심플 디자인 사상
MVP (최소 존립 제품): 비즈니스적 YAGNI
디자인 부채 (Design Debt): 과잉 설계로 인한 부채
유연한 설계: 낮은 결합도, 고응집도

👶 어린이를 위한 3줄 비유 설명

YAGNI는 "내일 소풍 갈 때 비가 올지도 모르니까 지금 우산을 펴고 있지 마세요"라는 뜻이에요.
비가 올 때 우산을 챙기면 되는데, 해가 쨍쨍한데 우산을 들고 다니면 힘만 들고 놀기도 힘들잖아요.
진짜 필요한 일이 생겼을 때 준비하는 게 가장 똑똑한 방법이랍니다.