YAGNI 원칙
YAGNI 원칙이란?
YAGNIYou Aren’t Gonna Need It는 “당신은 그것이 필요하지 않을 것이다” 라는 의미로, 미래에 필요할지 모르는 기능을 미리 구현하지 말라는 원칙입니다. 이는 개발 과정에서 복잡성과 시간 낭비를 줄이고, 더 단순하고 유연한 코드를 작성하는 데 중점을 두자는 의미이며, 애자일 개발이나 Extreme Programming에서 자주 강조됩니다.
개념 설명
YAGNI 원칙은 불필요한 기능 구현을 피함으로써, 개발 시간을 절약하고 코드의 복잡성을 줄이려는 원칙입니다. 미리 예상하여 기능을 구현하면, 대부분 그 기능은 사용되지 않거나, 나중에 변경될 가능성이 큽니다.
예시
다음 코드는 YAGNI 원칙을 위반한 예시입니다.
public class User
{
public string Name { get; set; }
public int Level { get; set; }
// 필요하지 않은 기능을 미리 구현
public void ApplyDiscount()
{
if (Level == 1) { /* Bronze discount */ }
else if (Level == 2) { /* Silver discount */ }
else if (Level == 3) { /* Gold discount */ }
}
}이 코드는 원래 다음과 같이 간소한 코드입니다.
public class User
{
public string Name { get; set; }
// 필요하지 않은 기능은 나중에 추가
}YAGNI 원칙의 이점
- 시간 절약: 필요 없는 기능 구현에 시간을 낭비하지 않습니다.
- 유지보수 용이: 불필요한 복잡성을 줄여 코드 관리가 쉬워집니다.
- 효율적인 개발: 현재 필요한 것에만 집중하여 더 빠르게 작업할 수 있습니다.
YAGNI 원칙의 한계
미래 확장성의 희생
YAGNI를 너무 엄격하게 적용하면, 소프트웨어가 빠르게 성장하거나 요구사항이 변할 때 확장성을 갖추지 못한 코드를 마주할 수 있습니다. 미래의 요구에 대응하기 위해 기존 코드를 대규모로 리팩토링해야 할 수도 있습니다.
복잡한 비즈니스 로직에서의 한계
복잡한 비즈니스 로직을 다루는 시스템에서는 미래의 요구를 어느 정도 예측하고 설계하는 것이 중요합니다. 이 경우 YAGNI를 너무 엄격히 적용하면, 코드가 지나치게 단순해져서 향후의 요구사항을 쉽게 반영하지 못하는 한계가 있습니다.
기능 추가 시 리팩토링 부담
실제로 새로운 요구사항이 발생할 때, 이전에 YAGNI 원칙을 적용해 구현하지 않았던 기능을 나중에 추가하려면, 기존 코드에 대한 리팩토링 부담이 커질 수 있습니다. 특히, 시스템이 이미 배포된 상태에서는 리팩토링으로 인해 기존 기능에 영향을 줄 가능성이 존재합니다.
설계 유연성의 저하
YAGNI 원칙에 따라 기능을 최소한으로 설계하면, 소프트웨어의 설계가 지나치게 단순해지면서 유연성을 잃을 수 있습니다. 이는 새로운 기능을 추가할 때 설계의 변화가 어려워지는 문제로 이어질 수 있습니다.
적용 범위의 모호성
YAGNI 원칙을 어디까지 적용해야 할지에 대한 경계가 명확하지 않을 수 있습니다. “필요하지 않다"는 판단이 주관적일 수 있어, 팀 내에서 적용 범위에 대한 논의가 필요합니다. 지나치게 엄격하게 YAGNI를 적용할 경우, 필요한 기능마저 뒤로 미루어 비효율적인 코드 구조를 만들 수 있습니다.
맺음말
YAGNI 원칙은 불필요한 기능을 미리 구현하지 않음으로써, 개발 속도와 코드 품질을 높이는 중요한 원칙입니다. 필요한 기능은 필요할 때 추가하는 것이 더 효율적입니다.
심화학습
YAGNI와 다른 설계 원칙의 조화
YAGNI와 KISS 원칙
KISS 원칙은 코드를 단순하게 유지하는 데 중점을 두며, YAGNI와 같은 맥락에서 불필요한 기능을 미리 추가하지 않도록 강조합니다. 두 원칙은 복잡성 줄이기라는 동일한 목표를 추구하며, 특히 초기 설계 단계에서 함께 적용될 수 있습니다.
YAGNI와 DRY 원칙
DRY Don’t Repeat Yourself 원칙은 코드의 중복을 없애고 재사용성을 높이려는 원칙입니다. YAGNI와 함께 적용할 때 주의할 점은, 필요하지 않은 추상화나 중복 제거를 피하라는 것입니다. 예를 들어, 재사용 가능할 것이라는 막연한 추정 하에 미리 코드를 추상화하는 것은 YAGNI 원칙을 위반할 수 있습니다.
YAGNI와 애자일 개발
진화적 설계와 YAGNI
애자일 개발 방식에서는 요구사항이 프로젝트 진행 중에도 변화할 수 있기 때문에, YAGNI 원칙은 애자일 팀에서 특히 유용합니다. 진화적 설계와 결합하여, 필요한 기능만을 우선 구현하고, 요구사항이 구체화될 때마다 기능을 점진적으로 추가하는 방식으로 YAGNI를 실무에 적용할 수 있습니다.
MVP(최소 기능 제품)와 YAGNI
MVP Minimum Viable Product 전략과 YAGNI 원칙은 긴밀한 연관이 있습니다. MVP는 제품의 핵심 기능만을 구현해 빠르게 시장에 출시하는 전략으로, 이 과정에서 불필요한 기능을 생략하고 핵심 기능에만 집중하는 YAGNI 원칙이 큰 역할을 합니다.
YAGNI와 기술 부채 관리
기술 부채 최소화
YAGNI 원칙은 기술 부채를 줄이는 데 도움이 됩니다. 미래에 필요할지 모를 기능을 미리 구현하는 것은 종종 기술 부채를 쌓는 원인이 되는데, YAGNI를 적용하면 필요할 때만 기능을 추가하여 불필요한 복잡성이나 부채를 줄일 수 있습니다.
기술 부채와의 타협
그러나 YAGNI 원칙을 지나치게 엄격하게 적용하면, 나중에 필요한 기능을 추가하는 과정에서 기존 코드에 큰 리팩토링이 필요할 수 있습니다. 따라서 기술 부채와 YAGNI 간의 균형을 맞추는 것이 중요합니다. 기술 부채를 최소화하면서도, 미래의 확장을 염두에 둔 설계를 유지하는 것이 좋습니다.
YAGNI와 TDD의 결합
YAGNI 원칙과 테스트 주도 개발TDD는 서로 잘 맞는 개발 방법론입니다. TDD는 기능을 추가할 때 반드시 그 기능에 대한 테스트를 먼저 작성하는 방식으로 개발이 진행되기 때문에, 불필요한 기능을 미리 구현하는 위험을 줄일 수 있습니다. 이는 YAGNI 원칙과 직접적으로 연결되며, 현재 필요한 기능에만 집중하는 개발을 촉진합니다.
필요한 기능만 구현
TDD는 테스트에서 요구하는 동작을 충족하기 위해 최소한의 코드만을 작성하게 만듭니다. TDD 과정에서 불필요한 기능을 미리 구현하지 않게 되며, 이는 YAGNI 원칙을 자연스럽게 따르게 되는 방식입니다.
테스트를 통한 명확한 요구사항 확인
테스트 코드를 작성할 때, 실제로 요구되는 동작만을 테스트하므로 불확실한 요구사항이나 미래의 요구에 대한 구현을 피할 수 있습니다. 이는 YAGNI 원칙의 핵심인 “미래에 필요할지 모를 기능을 미리 구현하지 않는다"는 철학과도 일치합니다.
리팩토링과 YAGNI
TDD는 코드의 리팩토링을 중요하게 다룹니다. 리팩토링 과정에서 테스트는 코드의 품질을 유지하고 개선할 수 있는 안전 장치 역할을 하므로, YAGNI 원칙을 지키면서도 점진적으로 코드를 개선할 수 있는 유연성을 제공합니다. 리팩토링 시 필요하지 않은 코드를 제거하거나, 실제 필요할 때만 코드를 추가하게 되는 것도 TDD와 YAGNI의 자연스러운 결합 결과입니다.
예시
[Test]
public void ShouldApplyDiscountToGoldLevelUser()
{
var user = new User { Level = 3 };
user.ApplyDiscount();
Assert.AreEqual( /* 할인 후 값 확인 */ );
}위 테스트에서는 골드 레벨 유저에게만 할인이 적용되도록 요구하고 있습니다. 이 요구사항을 만족시키기 위해 개발자는 오직 골드 레벨에 대한 할인 기능만을 구현하게 되고, 다른 등급에 대한 불필요한 코드를 미리 작성하지 않게 됩니다. 이는 YAGNI 원칙을 지키면서 필요한 기능만을 구현하는 TDD의 예시입니다.
팀 내 YAGNI 적용 시 유의 사항
YAGNI 원칙을 팀 내에서 적용할 때는 명확한 커뮤니케이션과 의사 결정 과정이 필수적입니다. 특히, 팀원이 각자 다른 판단 기준을 가지고 있다면 YAGNI 원칙을 지나치게 엄격하게 적용하거나, 필요하지 않은 기능을 미리 추가하는 실수를 범할 수 있습니다. 팀 내에서 YAGNI를 성공적으로 적용하기 위해서는 몇 가지 유의 사항이 있습니다.
공유된 이해와 합의
팀 내에서는 YAGNI 원칙의 개념과 목표에 대해 공유된 이해가 필요합니다. 모든 팀원이 YAGNI의 의미를 명확히 알고, 그 원칙을 어느 정도까지 적용할지 합의하는 과정이 필수적입니다. 이를 통해 각 개발자가 동일한 기준으로 기능 구현을 판단할 수 있게 됩니다.
기능 우선순위 설정
YAGNI를 실무에서 적용할 때는 기능 우선순위를 명확히 정하는 것이 중요합니다. 각 기능이 실제로 프로젝트의 현재 단계에서 꼭 필요한지, 아니면 미래의 요구사항일 가능성이 있는지를 팀원들과 논의하고 결정해야 합니다. 우선순위를 설정하는 과정에서 YAGNI를 적용할지 여부를 논의할 수 있습니다.
의사 결정 프로세스
미래의 요구사항을 예상하여 기능을 미리 구현할지, 아니면 나중에 추가할지 결정하는 과정은 항상 쉬운 일은 아닙니다. 팀 내에서 의사결정이 명확하게 이뤄지지 않으면, YAGNI 원칙이 무너질 수 있습니다. 책임 있는 의사결정 프로세스를 도입하고, 각 기능 구현 여부에 대해 팀원이 합리적인 결정을 내리도록 돕는 절차가 필요합니다.
명확한 문서화
YAGNI 원칙을 적용한 경우, 그 결정에 대해 명확하게 문서화해야 합니다. 왜 해당 기능을 나중에 구현하기로 했는지에 대한 설명과, 그 기능이 추후 추가될 가능성에 대해 팀원들 간 공유된 이해를 가지는 것이 중요합니다.
지속적인 피드백과 검토
YAGNI는 유연한 원칙이므로, 팀원들 간의 지속적인 피드백과 검토가 필요합니다. 팀 내에서 YAGNI 원칙을 성공적으로 적용하려면, 각 기능의 필요성을 주기적으로 평가하고, 변화하는 요구사항에 맞춰 팀 전체가 동일한 방향으로 나아가도록 해야 합니다.
Buy me a coffee