소프트웨어 개발에서의 YAGNI 원칙: 그 추상화나 일반 코드가 정말 필요한가요?

YAGNI란 무엇인가요? 필요 없는 건 만들지 마세요

이 논의의 핵심은 익스트림 프로그래밍과 린 소프트웨어 개발의 핵심 개념인 YAGNI 원칙, 즉 "필요 없을 거야(You Aren't Gonna Need It)"입니다. 데릭의 설명처럼, YAGNI 원칙은 개발자들에게 미래에 필요할 것이라고 생각하는 기능이나 특징을 구현하지 말고 현재 필요한 기능에 집중하라고 말합니다.

데릭은 다음과 같은 미묘한 차이를 덧붙입니다. 예측 불가능한 코드를 작성하는 것은 피해야 하지만, 나중에 적응하는 데 제약을 두어서도 안 된다는 것입니다. 핵심 과제는 유용 할 수 있는 기능에 시간을 낭비하지 않으면서도 변화에 유연하게 대처하는 것입니다. 이는 애자일 소프트웨어 개발 및 소프트웨어 엔지니어링에서 흔히 발생하는 딜레마입니다.

그는 YAGNI 원칙의 두 가지 흔한 오용 사례를 설명합니다.

1. 기능 기획 – 미래의 요구 사항을 예측하고 지금부터 개발을 시작합니다.

2. 코드 추상화 – 기존 코드를 너무 일찍 일반화하거나 추상화하여, 향후 필요할 수 있는 다른 기능들을 추측하는 경향이 있습니다.

두 경우 모두 결과는 대개 노력 낭비, 복잡성 증가, 기능 추가 등으로 이어지는데, 이는 좋은 관행과 KISS 원칙(Keep It Simple, Stupid, 단순하게 유지하라)이 지향하는 바와 정반대입니다.

실제 사례: 배송 알림 시스템

설명을 위해 데릭은 사용자의 소포가 배송되면 SMS를 보내는 배송 관리 시스템을 예로 들었습니다. 이 시스템은 Twilio를 사용하며, 해당 기능은 배달 이벤트를 처리하고 연락처 정보를 가져와 메시지를 전송하는 방식으로 작동합니다.

이처럼 간단한 코드 개발 프로세스는 현재 요구 사항을 충족합니다. 간단하고, 테스트 가능하며, 가치를 제공합니다. 하지만 여기서 다음과 같은 질문이 생깁니다. 만약 나중에 SMS 제공업체를 바꾸고 싶다면 어떻게 해야 할까요?

많은 개발자들이 YAGNI 원칙을 잘못 적용하는 부분이 바로 이 지점입니다. 그들은 나중에 다른 구현 방식이 나올 수도 있기 때문에 지금 SMS 로직을 추상화해야 한다고 생각합니다. 그래서 그들은 ISmsService와 같은 인터페이스를 만듭니다.

추상화: 당신은 존재하지 않을지도 모르는 미래를 위해 구축하고 있습니까?

데릭은 이러한 초기 추상화에 이의를 제기합니다. 구현체가 하나뿐이고 현재 공급업체를 전환해야 할 필요가 없다면 왜 추상화해야 하느냐는 것입니다. 미래에 필요하지 않을 수도 있는 상황을 대비해 불필요한 복잡성을 더하고 있는 것입니다.

그는 소프트웨어 엔지니어링 비용을 예로 들어 설명합니다. 결국 두 번째 공급업체를 추가하게 되면 인터페이스가 Twilio의 특정 요구 사항(예: "발신자" 전화번호 로직)에 너무 밀접하게 연결되어 있다는 것을 깨닫게 됩니다. 갑자기, 그 추상적인 개념이 오히려 부담이 된다. 이처럼 제한된 지식을 바탕으로 구축된 추상화는 종종 버그를 유발하고 리팩토링을 복잡하게 만듭니다.

여기서 핵심은 다음과 같습니다. 시간을 절약하는 것이 아니라, 맥락이 부족하여 잘못된 것을 만들고 있는 것입니다.

너무 일찍 범용성을 확보하려는 개발자의 함정

컴퓨터 과학 프로젝트에서 가장 흔한 YAGNI(You Aggregation, Aggregation, and No Independence, and Niche ... 데릭은 또 다른 예시를 통해 이를 설명합니다. 바로 SMS와 이메일 알림을 하나의 일반적인 알림 시스템으로 통합하는 것입니다.

이를 위해 개발자는 알림 유형(SMS 또는 이메일), 통합 주소 필드를 정의하고 두 가지 모두를 처리하는 단일 서비스를 만들 수 있습니다. 하지만 이러한 지나치게 추상적인 설계는 결국 논리를 복잡하게 만들고, 취약하고 유지 관리가 어려운 조건부 코드 경로를 생성합니다.

이는 전형적인 기능 추가 현상이며, 린 소프트웨어 개발과 견고한 원칙을 무시했을 때 나타나는 특징입니다. 사용자에게 당장 필요한 기능이 없는 예측 불가능한 코드를 작성하고 있습니다. 이는 애자일 소프트웨어 개발 프로세스에서 매우 위험한 신호입니다.

수정보다는 확장을 선호하세요

데릭은 과도한 설계를 하기보다는 가장 간단한 해결책을 제시합니다. 나중에 이메일 알림 기능을 지원해야 할 경우, 해당 기능을 별도로 구현하면 된다는 것입니다.

이벤트 기반 아키텍처를 사용하면 각 이벤트가 여러 독립적인 핸들러를 트리거할 수 있습니다. 예를 들어, SMS용 처리 장치와 이메일용 처리 장치를 따로 만들 수 있습니다. 나중에 하나를 제거해도 다른 하나에는 영향을 미치지 않습니다. 이 방법은 단순성을 촉진하고, 변경되는 요구사항을 지원하며, 관심사 분리를 존중합니다. 이 모든 것은 애자일 및 테스트 주도 개발의 모범 사례와 일치합니다.

과도하게 설계하는 것이 아니라 확장 가능한 시스템을 구축함으로써, 모든 가능한 미래를 예측하지 않고도 유연성을 유지할 수 있습니다. 이렇게 하면 불필요한 복잡성을 피하고 적응력을 유지할 수 있습니다.

YAGNI 원칙 위반의 실제 비용

데릭은 불필요한 기능을 구축하는 데 드는 실제 비용을 강조합니다.

• 사용하지 않을 것을 만드는 데 쏟는 시간

• 즉각적인 가치를 제공하지 않는 추가적인 복잡성

• 개발자들이 이제 사용되지 않거나 과도하게 구축된 코드를 유지 관리해야 하므로 소유 비용이 증가합니다.

• 과도한 설계로 인해 버그 및 오류 발생 가능성이 높아짐

이는 애자일 소프트웨어 개발의 또 다른 핵심 원칙, 즉 나중에 가치를 창출할 가능성이 아니라 지금 당장 가치를 제공하는 데 집중하는 것과 일맥상통합니다.

그는 경험 많은 개발자들이 미래의 요구 사항에 대한 자신의 직감을 믿는 실수를 저지르는 경우가 많으며, 그 직감이 틀렸다고 지적합니다. 경험이 아무리 많더라도 몇 달 후 시스템에 필요한 것이 무엇인지 예측하는 것은 대개 어려운 일입니다.

결론: 맥락이 ​​중요하고, 단순함이 승리한다

데릭은 마지막으로 자신이 디자인 원칙이나 추상화에 반대하는 것은 아니라고 분명히 밝혔습니다. 사실 그는 진화할 수 있는 시스템을 구축하는 것을 중요하게 생각합니다. 하지만 문제는 현재로서는 정당한 이유 없이 무언가를 시행하는 것, 즉 본질적으로 YAGNI 원칙을 위반하는 데 있습니다.

그는 개발자들에게 "지금 당장 가치 있는 코드를 작성하고 기능을 구현하라"고 권장합니다. 현재 사용자를 희생시키면서 미래의 요구 사항을 쫓는 것을 피하라는 것입니다. 깔끔한 코드 작성 방식을 고수하고, 예측 불가능한 구조에 갇히지 않으면서 변화를 지원하는 설계 전략을 선호하세요.

그는 또한 개발자들에게 미래를 위해 설계했지만 결국 필요하지 않았던 YAGNI 원칙에 대한 자신들의 끔찍한 경험담을 공유해 달라고 요청합니다. 이는 많은 프로젝트에서 흔히 발생하는 이야기입니다.

결론: 개발 프로세스에 YAGNI 원칙을 적용하십시오

YAGNI 원칙은 개발자의 도구 상자에서 가장 가치 있는 도구 중 하나로 남아 있습니다. 이는 애자일, 린, KISS(Keep It Simple, Stupid) 철학과 일맥상통하며, 필요한 것만 만들고 그 이상은 만들지 말라는 점을 상기시켜 줍니다. 데릭 코마틴은 자신의 영상 에서 실제 코드와 개발 프로세스 사례를 통해 YAGNI 개념을 명확하게 설명하며, 효과적인 적용 방법에 대한 구체적인 지침을 제공합니다.

그러므로 다음에 추상화 계층, 일반 클래스 또는 추가 기능을 추가하고 싶은 유혹이 들 때는 잠시 멈추고 스스로에게 질문해 보세요.

지금 겪고 있는 문제를 해결하고 계신가요, 아니면 언젠가 발생할지도 모르는 문제를 해결하고 계신가요?

미래에 대한 상상에 시간을 낭비하지 마세요. 오늘 가치 창출에 집중하세요. 소프트웨어를 단순하고 유지보수하기 쉬우며 실제 요구사항에 부응하도록 설계하세요.

왜냐하면 당신은 아마 필요 없을 테니까요.