소프트웨어 아키텍처 시리즈 2화 – 설계 원칙과 아키텍처 원칙: SOLID, KISS, DRY는 왜 중요한가?
소프트웨어 아키텍처 설계의 기초를 이루는 원칙들인 SOLID, KISS, DRY는 코드 품질뿐 아니라 시스템 아키텍처의 구조에도 깊이 연결되어 있습니다. 그 실제 의미와 실무 적용 관점에서의 맥락을 함께 살펴봅니다.
아키텍처와 설계 원칙, 어디까지 연결되는가?
많은 개발자들이 "SOLID", "KISS", "DRY"라는 용어를 알고는 있지만, 그 의미를 단순히 코드 레벨의 규칙 정도로만 생각하는 경우가 많습니다. 그러나 이들 원칙은 단순히 클래스 설계나 함수 구조에만 해당하는 것이 아닙니다. 시스템 전체 아키텍처를 구성하는 큰 틀에서도 핵심적인 역할을 합니다.
아래에서 각각의 원칙이 소프트웨어 아키텍처와 어떻게 연결되는지 하나씩 살펴보겠습니다.
1. SOLID 원칙 – 구조적 안정성을 위한 기초
SOLID는 객체지향 설계 5대 원칙으로 다음 다섯 가지로 구성됩니다.
- S: 단일 책임 원칙 (SRP)
→ 하나의 컴포넌트(모듈, 서비스, 클래스)는 단 하나의 변화 이유만 가져야 한다.
→ 아키텍처 레벨에서는 모듈화를 위한 핵심 기준이 됩니다. 예: 서비스마다 독립된 책임 분리. - O: 개방-폐쇄 원칙 (OCP)
→ 기능을 추가할 수는 있어야 하지만, 기존 코드는 변경하지 않아야 한다.
→ 예를 들어, 이벤트 처리 방식에서 새로운 이벤트 타입을 추가할 때 기존 핸들러 코드를 건드리지 않고 확장할 수 있어야 합니다. - L: 리스코프 치환 원칙 (LSP)
→ 상위 타입의 객체는 하위 타입으로 대체해도 문제 없어야 한다.
→ API나 인터페이스 기반 설계에서 구현체 변경이 가능한 구조를 보장함. - I: 인터페이스 분리 원칙 (ISP)
→ 특정 클라이언트를 위한 인터페이스는 그에 필요한 기능만 가져야 한다.
→ 여러 서비스에 동일한 인터페이스를 강제로 적용하지 않음으로써, BFF 패턴처럼 목적에 맞는 인터페이스를 설계할 수 있습니다. - D: 의존 역전 원칙 (DIP)
→ 고수준 모듈은 저수준 모듈에 의존해서는 안 된다. 둘 다 추상화에 의존해야 한다.
→ 이는 헥사고날 아키텍처, 클린 아키텍처의 핵심 철학이기도 합니다.
이 원칙들은 단순히 OOP 패턴이 아니라, 아키텍처 수준에서 각 계층이 어떻게 구성되어야 하는지를 결정짓는 핵심 기준입니다.
2. KISS – Keep It Simple, Stupid
"간단하게 유지하라"는 의미의 KISS는 너무 단순해서 무시되기 쉽지만, 실제로는 아키텍처가 실패하는 가장 큰 이유 중 하나가 불필요한 복잡성입니다.
- 무리한 추상화, 과도한 레이어 분리, 모든 케이스를 커버하려는 설계는 결국 유지보수의 적이 됩니다.
- 예: 작은 프로젝트에 CQRS, 이벤트 소싱, 클러스터링까지 도입한다면? 실제로는 유지보수 비용이 아키텍처 설계 이점보다 더 커질 수 있습니다.
아키텍트는 시스템을 단순화하는 방향으로 나아갈 수 있어야 하며, KISS는 이를 가능하게 하는 원칙입니다.
3. DRY – Don't Repeat Yourself
중복은 기술 부채의 씨앗입니다. 같은 로직이 여러 레이어에서 반복될 경우, 추후 수정 시 오류 가능성이 크게 증가합니다.
- 아키텍처에서 DRY를 적용하는 방식은 크게 두 가지입니다.
- 공통 유틸리티 또는 서비스 계층으로 분리
- API나 모듈 설계 시 재사용 가능한 방식으로 구성
하지만 무조건 "DRY가 최고다"라고 할 수는 없습니다.
때로는 복잡한 추상화보다 약간의 중복이 유지보수 측면에서는 더 나을 수도 있습니다. 이건 실무에서 판단이 필요한 영역이며, "추측"보다 경험 기반의 사례에 따라 결정되어야 합니다.
모르면 모른다고 말해야 할 지점: 원칙 간 우선순위?
개발자 커뮤니티에서는 종종 “SOLID 중 어떤 원칙이 가장 중요한가?”, “DRY vs KISS 중 무엇이 우선인가?” 같은 질문이 나옵니다.
하지만 이 질문에 정답은 없습니다.
프로젝트의 규모, 인력 구성, 배포 전략, 비즈니스 변화 속도 등 수많은 변수에 따라 달라집니다. 하나의 원칙을 맹목적으로 따르기보다는, 문맥에 따라 균형 있는 적용이 필요합니다. 이 부분은 수많은 논문과 아키텍처 서적들에서도 다양한 해석이 존재하며, 절대적 진리는 없습니다.
마무리하며
설계 원칙들은 단순히 ‘이렇게 하세요’라는 규칙이 아니라, 시스템의 생존 가능성을 높이기 위한 전략적 판단의 도구입니다.
잘 설계된 아키텍처는 언제나 이 원칙들과 대화를 나누고 있으며, 때로는 일부 원칙을 희생하면서도 전체적인 품질과 가치를 지킬 수 있는 방향을 고민합니다.