109. 불필요한 기능 구현 금지 원칙 (YAGNI, You Aren't Gonna Need It)

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

본질: YAGNI (You Aren't Gonna Need It, 불필요한 기능 구현 금지 원칙)는 현재 실제로 필요한 기능만 구현하고, 미래에 필요할 것이라는 추측을 근거로 한 선행 설계·구현을 금지하는 익스트림 프로그래밍(XP, Extreme Programming)의 핵심 원칙이다.

가치: 미래를 위해 미리 만들어둔 기능의 80%는 실제로 사용되지 않으며, 이 과정에서 소모된 개발 시간·테스트 비용·유지보수 부담이 오버엔지니어링(over-engineering)이라는 부채로 쌓인다.

판단 포인트: YAGNI는 단순히 기능을 줄이는 것이 아니라 "지금 이 요구사항이 실제로 확정된 것인가, 아니면 개발자의 추측인가"를 끊임없이 질문하게 만드는 판단 훈련이다.

Ⅰ. 개요 및 필요성

YAGNI는 켄트 벡(Kent Beck)의 XP (Extreme Programming) 방법론에서 명시적으로 언급된 원칙이다. 1990년대 후반 소프트웨어 프로젝트들이 "언젠가 필요할 것 같아서" 만든 기능들로 비대해지고 출시가 지연되는 문제를 해결하기 위해 등장했다.

개발자가 미래 확장성을 위해 선행 구현을 시도하는 이유는 크게 세 가지다. 첫째, 나중에 수정하면 비용이 더 들 것이라는 걱정, 둘째, 지금이 기술적으로 올바른 구조를 만들 기회라는 믿음, 셋째, 사용자 요구보다 기술적 완성도를 우선시하는 개발자의 본능이다. YAGNI는 이 세 가지 이유 모두를 실증적 관찰로 반박한다.

┌─────────────────────────────────────────────────────────────┐
│          YAGNI 위반 시 낭비 경로                             │
├─────────────────────────────────────────────────────────────┤
│ 추측 기반 기능 구현                                          │
│        │                                                    │
│        ▼                                                    │
│  코딩 비용 + 테스트 비용 + 문서 비용                         │
│        │                                                    │
│        ▼                                                    │
│  미사용(실제 요구와 불일치) ─────────▶ 80% 확률로 제거      │
│        │                                                    │
│        ▼                           추가 비용 발생           │
│  제거 비용 + 코드베이스 복잡도 유산 → 기술 부채로 축적       │
└─────────────────────────────────────────────────────────────┘

이 낭비 경로가 반복되면 출시 지연, 예산 초과, 코드베이스 복잡도 증가라는 삼중 타격이 발생한다. YAGNI는 이 순환을 "지금 필요한 것만" 원칙으로 차단한다.

📢 섹션 요약 비유: 여행 짐을 쌀 때 "혹시 산에 갈 수도 있으니" 등산화를 넣으면, 도시 여행 내내 무거운 가방을 끌고 다녀야 한다. 필요할 때 현지에서 빌리는 것이 더 효율적이다.

Ⅱ. 아키텍처 및 핵심 원리

YAGNI를 실천하는 핵심 메커니즘은 반복적 개발(Iterative Development)과 지속적 리팩토링(Continuous Refactoring)의 결합이다. 현재 요구사항을 가장 단순한 방법으로 구현하고, 새로운 요구사항이 확정되면 그때 코드를 확장하는 방식이다. 이를 위해 코드가 언제든 안전하게 변경될 수 있는 테스트 커버리지(test coverage)가 선행되어야 한다.

항목	설명	포인트
API 설계	현재 미사용 파라미터 추가	현재 필요한 파라미터만 정의
데이터베이스	향후 통계용 컬럼 선제 추가	실제 요구 시 마이그레이션
아키텍처	트래픽 예상으로 MSA 선제 적용	모놀리스 시작 후 필요 시 분리
플러그인 구조	아직 없는 플러그인을 위한 프레임워크	두 번째 플러그인 등장 시 추출

┌─────────────────────────────────────────────────────────────┐
│          YAGNI 실천: 반복적 진화 설계 사이클                 │
├─────────────────────────────────────────────────────────────┤
│  현재 요구사항 확정                                          │
│        │                                                    │
│        ▼                                                    │
│  최소한의 구현 (Simplest Thing That Could Possibly Work)     │
│        │                                                    │
│        ▼                                                    │
│  배포·피드백 수집                                            │
│        │                                                    │
│        ▼                                                    │
│  새 요구사항 확정 → 리팩토링 후 확장                         │
│        │                                                    │
│        └──────────── 반복 ────────────────────────▶         │
└─────────────────────────────────────────────────────────────┘

YAGNI와 테스트 주도 개발(TDD, Test-Driven Development)은 상호 강화 관계다. TDD는 "통과해야 할 테스트가 없는 코드는 작성하지 않는다"는 규칙으로 YAGNI를 자연스럽게 강제한다.

📢 섹션 요약 비유: 건물 설계에서 아직 허가받지 않은 10층을 미리 철골 구조로 지어두면, 나중에 설계가 바뀔 때 그 구조를 모두 뜯어내야 한다. 허가가 나면 그때 증축하는 것이 현명하다.

Ⅲ. 비교 및 연결

YAGNI와 과도한 미래 대비 설계를 "오버엔지니어링"이라고 하며, 반대편에서는 너무 짧은 시야로 인한 "언더엔지니어링"의 위험도 있다. 두 극단의 경계를 설정하는 것이 YAGNI 적용의 실질적 도전이다.

비교 축	A	B
설계 범위	현재 확정된 요구사항만	미래 추측을 반영한 선행 설계
코드 크기	최소한으로 유지	사용되지 않는 추상화·확장 포인트 포함
변경 비용	낮음 (단순한 구조)	높음 (복잡한 구조 이해 필요)
미래 대응	리팩토링으로 점진적 확장	미리 만든 구조가 실제 필요와 불일치

YAGNI는 DDD (Domain-Driven Design, 도메인 주도 설계)와 결합할 때 특히 강력하다. 도메인 전문가와 함께 현재 비즈니스 요구를 정확히 파악한 후, 그 범위만 구현하는 방식이다. 이는 바운디드 컨텍스트(Bounded Context) 설정의 실용적 기준이 되기도 한다.

📢 섹션 요약 비유: 지금 당장 2명이 사는 집에 20개 방을 지으면 대부분 빈 방으로 남고 관리비만 나간다. 식구가 늘어날 때 증축하는 것이 YAGNI다.

Ⅳ. 실무 적용 및 기술사 판단

스타트업과 신규 프로젝트에서 YAGNI는 생존 원칙이다. MVP (Minimum Viable Product, 최소 기능 제품)를 빠르게 출시하여 시장 반응을 확인한 후, 실제 사용자 피드백을 기반으로 기능을 확장하는 린(Lean) 개발 방식이 YAGNI의 실무 표현이다.

기술사 감리 관점에서는 과도한 설계가 사업 범위 초과, 납기 지연, 예산 낭비의 원인이 되므로 과업대비표(Task Traceability Matrix)를 통해 구현된 기능이 승인된 요구사항 범위 내에 있는지 확인한다.

판단 체크리스트

이 기능 또는 설계 요소가 현재 확정된 요구사항에서 실제로 요구되는가?
"나중에 필요할 것 같다"는 판단이 사용자·도메인 전문가의 요청인가, 개발자의 추측인가?
이 추상화·확장 포인트가 현재 2개 이상의 서로 다른 구현체를 위한 것인가?
이 기능 없이 현재 요구사항을 충족할 수 있는가?
지금 추가하지 않았다가 나중에 추가할 때 리팩토링 비용이 과도하게 높아지는가?

📢 섹션 요약 비유: 요리사가 오늘 저녁 메뉴에 없는 요리를 위해 식재료를 미리 구매하면, 재료는 상하고 냉장고만 가득 찬다. 주문이 들어올 때 신선하게 준비하는 것이 YAGNI다.

Ⅴ. 기대효과 및 결론

YAGNI를 일관되게 실천하면 코드베이스가 현재 실제 요구사항에 정확하게 맞는 형태로 유지되어 이해하기 쉽고 변경하기 쉬운 상태가 지속된다. 개발팀의 집중력이 현재 가치 창출에 집중되어 출시 속도가 빨라지고, 불필요한 기능 유지에 드는 기술 부채(technical debt)가 축적되지 않는다.

한계는 리팩토링이 전제가 된다는 점이다. YAGNI를 실천하면 나중에 구조 변경이 필요해지는 상황이 자주 생기므로, 이를 빠르게 수행할 수 있는 자동화된 테스트와 CI/CD (Continuous Integration/Continuous Delivery, 지속적 통합/배포) 파이프라인이 반드시 갖춰져야 한다. 이 환경 없이 YAGNI만 적용하면 나중에 큰 수정이 필요할 때 위험해진다.

미래 방향으로는 ① AI 기반 요구사항 분석을 통한 실제 필요 기능 예측 정확도 향상, ② 기능 플래그(Feature Flag)를 활용한 YAGNI와 미래 준비 절충, ③ 아키텍처 적합성 테스트(Fitness Function)를 통한 YAGNI 위반 자동 감지가 발전하고 있다.

YAGNI는 "지금 필요하지 않은 것은 짓지 않는다"는 단순한 금지가 아니라, "실제 변화에 빠르게 응답할 수 있는 린한 코드베이스를 유지한다"는 능동적 설계 철학으로 기억해야 한다.

📢 섹션 요약 비유: 도서관 사서는 아직 읽힐지 모르는 책을 대량 구매하여 서가를 채우는 대신, 실제 대출 요청이 들어올 때 구매하는 주문형 방식을 선택한다. 필요가 확인된 순간에 준비하는 것이 YAGNI다.

📌 관련 개념 맵

[XP(Extreme Programming)] → [YAGNI] → [TDD] → [MVP] → [CI/CD] → [지속적 리팩토링]

개념	연결 포인트
KISS	YAGNI와 함께 오버엔지니어링을 막는 상호 보완 원칙
TDD	테스트가 없는 코드는 작성하지 않음으로써 YAGNI를 자연히 강제
MVP	YAGNI의 제품 단위 실천 형태
기술 부채	YAGNI 위반으로 쌓이는 불필요한 코드·설계의 부담

📈 관련 키워드 및 발전 흐름도

[오버엔지니어링 문제 인식] → [XP(Extreme Programming) 방법론] → [YAGNI 원칙 정립] → [TDD·CI/CD 기반 안전한 리팩토링] → [린 스타트업·MVP] → [기능 플래그 기반 점진적 출시]

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

YAGNI는 오늘 숙제에 나오지 않는 문제를 미리 풀지 않는 원칙이에요.
지금 필요한 것만 정확하게 하면 시간도 아끼고 실수도 줄어들어요.
내일 숙제가 나오면 그때 풀면 돼요. 미리 만든 답이 틀릴 수도 있으니까요!