시스매

YAGNI 원칙 핸드북

9 min read

2025-08-09 00:12

Tags:

YAGNI 원칙 핸드북

1. 만들어진 이유: 과잉 설계의 함정

YAGNI는 “You Ain’t Gonna Need It” 의 약자로, “당신은 그것을 필요로 하지 않을 것이다”라는 의미. 이 원칙은 익스트림 프로그래밍(XP) 방법론의 창시자 중 한 명인 켄트 벡(Kent Beck)에 의해 대중화되었음.

1990년대 소프트웨어 개발 현장은 ‘미래를 위한 설계’라는 명목 아래 복잡하고 방대한 기능을 미리 구현하는 것이 일반적이었음. 개발자들은 앞으로 필요할지도 모른다는 막연한 추측만으로 수많은 코드를 추가했고, 이는 다음과 같은 문제점을 낳았음.

  • 개발 시간 증가: 사용되지 않을 수도 있는 기능에 시간과 노력을 낭비.

  • 유지보수 비용 증가: 코드가 복잡해질수록 버그 발생 가능성이 높아지고, 수정 및 관리가 어려워짐.

  • 변화 대응력 저하: 거대하고 복잡한 시스템은 새로운 요구사항이나 시장 변화에 유연하게 대처하기 어려움.

YAGNI는 이러한 과잉 설계(Over-engineering) 의 폐해를 막고, ‘지금 당장 필요한 가장 단순한 것’ 에 집중하자는 철학에서 탄생했음. 이는 불확실한 미래를 예측하는 데 드는 비용을 없애고, 현재 가치에 집중하여 개발 효율성을 극대화하려는 시도.

2. 핵심 개념: 단순함의 추구

YAGNI의 핵심은 “필요할 때까지 만들지 말라” 는 한 문장으로 요약 가능.

  • 현재의 요구사항에만 집중: “언젠가 필요할 거야”라는 가정은 버리고, 지금 당장 명확하게 요구되는 기능만 구현.

  • 최소한의 기능 구현 (MVP): 가장 단순하고 핵심적인 기능부터 개발하고, 이후 피드백이나 실제 필요에 따라 기능을 확장.

  • 추측성 일반화 방지: 특정 기능 몇 개에만 필요한 로직을 “나중에 다른 곳에서도 쓰일지 모른다”는 이유로 섣불리 일반화하거나 추상화하지 않음.

비유: 여행 가방을 싸는 것에 비유할 수 있음.

  • 나쁜 예 (YAGNI 위반): “혹시 정글에 갈지도 모르니 벌레 퇴치 스프레이를 챙기고, 사막에 갈 수도 있으니 선글라스를, 극지방에 대비해 방한복도 넣자.” 결국 가방만 무거워지고 대부분의 짐은 쓰이지 않음.

  • 좋은 예 (YAGNI 적용): “이번 여행지는 파리다. 파리 날씨와 일정에 맞는 옷과 필수품만 챙기자. 다른 것이 필요해지면 현지에서 구하면 된다.” 가볍고 효율적인 여행이 가능.

3. 적용 방법: 언제, 어떻게?

YAGNI를 적용하는 것은 단순히 기능을 만들지 않는 것이 아니라, ‘언제’ 만들지를 결정하는 것.

  1. 기능 개발 전 질문하기:

    • “이 기능이 지금 당장 정말로 필요한가?”

    • “이 기능이 없으면 시스템이 동작하지 않는가?”

    • “요구사항 명세서에 명확히 나와 있는가?”

    • “이것을 구현하지 않고 현재 문제를 해결할 다른 더 간단한 방법은 없는가?”

  2. 코드 리팩토링 시:

    • 중복 제거(DRY 원칙) vs YAGNI: 코드 중복이 발생했을 때, 무조건 추상화부터 시도하는 것이 아니라 이 중복이 정말로 ‘같은’ 개념인지 판단해야 함. 우연히 코드가 같을 뿐, 비즈니스 로직상 다른 개념이라면 섣부른 추상화는 오히려 나중에 더 큰 문제를 야기할 수 있음. 세 번 이상 반복될 때 리팩토링을 고려하는 ‘3의 법칙(Rule of Three)‘을 함께 적용하면 좋음.

  3. 테스트 주도 개발(TDD)과 함께 사용:

    • TDD는 실패하는 테스트를 먼저 작성하고, 그 테스트를 통과할 만큼의 최소한의 코드만 작성하는 방식. 이는 자연스럽게 YAGNI 원칙을 따르도록 유도함. 필요한 기능(테스트 케이스)에 대한 코드만 작성하게 되므로 불필요한 기능 추가를 막아줌.

4. 장점과 주의점

장점주의점 (오해와 남용)
개발 속도 향상설계 자체를 무시하는 것으로 오해
코드 단순성 유지기본적인 아키텍처나 확장성을 전혀 고려하지 않는 것
유지보수 비용 감소명백하게 필요한 기능조차 미루는 핑계로 남용
요구사항 변경에 유연한 대응리팩토링 없는 YAGNI는 기술 부채(Technical Debt)를 쌓음
팀의 집중력 향상장기적인 비전이나 큰 그림을 보지 못하게 될 위험

가장 중요한 주의점: YAGNI는 ‘좋은 설계’를 포기하라는 의미가 아님. 오히려 현재 요구사항에 맞는 가장 단순하고 깨끗한 설계를 하라는 의미. 미래의 불확실한 요구사항 때문에 현재의 설계를 복잡하게 만들지 말라는 것. 리팩토링을 통해 지속적으로 코드를 개선한다는 전제가 반드시 필요함.

5. 다른 원칙과의 관계

  • KISS (Keep It Simple, Stupid): “단순하게 유지하라”는 원칙. YAGNI는 ‘무엇을’ 단순하게 만들 것인지(현재 필요한 것)에 대한 구체적인 지침을 제공하며 KISS 철학을 실천하는 방법론 중 하나.

  • DRY (Don’t Repeat Yourself): “반복하지 말라”는 원칙. YAGNI와 상충하는 것처럼 보일 수 있음. DRY는 코드의 중복을 제거하기 위해 추상화를 권장하지만, YAGNI는 섣부른 추상화를 경계함. 이 둘 사이의 균형을 잡는 것이 중요. ‘우연한 중복’과 ‘본질적인 중복’을 구분하는 능력이 필요.

  • SoC (Separation of Concerns): “관심사의 분리”. 좋은 아키텍처의 기본. YAGNI를 따른다고 해서 기본적인 모듈 분리나 책임 분리 같은 좋은 설계 원칙을 무시해서는 안 됨.

YAGNI는 단독으로 존재하는 마법의 지팡이가 아니라, 다른 개발 원칙들과 조화를 이룰 때 진정한 힘을 발휘합니다.

이 핸드북이 YAGNI 원칙을 이해하는 데 도움이 되었기를 바랍니다. 혹시 특정 상황에서 YAGNI를 어떻게 적용할지 더 구체적인 예시가 궁금하신가요?

References

YAGNI 원칙

그래프 뷰

백링크