설계/설계 원칙

SOLID의 DIP : 변화에 강한 구조를 만드는 의존성 역전 원칙

1. 의존성이 왜 문제인가? 시스템이 망가지는 구조의 시작애플리케이션 개발을 하다 보면, 단순한 기능 변경이 시스템 전반에 영향을 미치는 상황을 자주 경험하게 된다. 예를 들어, 주문 처리 후 완료 시 이메일을 발송하는 기능을 처음에는 단순하게 구현했다고 가정하자. 그런데 시간이 지나면서 SMS나 푸시 알림도 함께 발송하라는 요구가 추가되기 마련이다. 이러한 변화에 대응하기 위해 많은 개발자는 기존의 이메일 발송 코드에 SMS나 푸시 알림 전송 로직을 그대로 덧붙이는 방식을 선택한다. 처음에는 빠르게 동작하므로 문제가 없어 보일 수 있지만, 이런 방식은 시스템의 복잡도를 빠르게 증가시킨다. 가장 큰 문제는 비즈니스 로직이 특정 기술 구현에 직접 의존하게 된다는 점이다. 다시 말해, '사용자 등록'과 같은..

2025. 5. 12. 17:14
설계/설계 원칙

SOLID의 ISP : 역할 중심 설계를 도와주는 인터페이스 분리 원칙

1. 구조를 망치는 인터페이스정교하게 설계된 애플리케이션도, 시간이 지나고 요구사항이 누적되면 점차 구조적인 균열이 드러난다. 특히 문서에는 '공통 인터페이스'라 명시되어 있지만, 실제 구현을 맡은 개발자는 "이 메서드, 왜 내가 구현해야 하지?"라고 생각하게 된다. 이 질문은 단순한 불만이 아니다. 이는 인터페이스의 책임과 역할 경계가 무너지고 있다는 신호다. 그 원인은 범용 인터페이스에 있다. 처음에는 기능 통합과 재사용성 증대를 위해 하나의 인터페이스로 묶는 것이 타당해 보였다. 그러나 시간이 흐르면서 각기 다른 책임이 뒤섞이기 시작하고, 구현체는 자신과 무관한 기능까지 포함한 인터페이스를 강제로 구현하게 된다. 결과적으로 '모두를 위한 인터페이스'는 '아무도 적합하지 않은 구조'로 변질된다. 이로..

2025. 5. 7. 15:58
설계/설계 원칙

SOLID의 LSP : 왜 타입만 맞으면 안 되는가? 설계 오류를 막는 리스코프 치환 원칙

1. 추상화는 알지만 치환 가능성은 모른다.객체지향 프로그래밍(OOP, Object Oriented Programming)에서 상속과 인터페이스는 더 이상 낯선 개념이 아니다. 많은 개발자들이 재사용성과 확장성을 위해 추상화하고, 새로운 기능을 위해 하위 클래스나 구현 클래스로 분리해 나간다. 문제는 여기서부터 발생한다. 분명히 상위 타입에 맞게 코드를 작성했고, 컴파일도 문제없이 완료되었는데 런타임 시 기존 코드가 깨진다.클래스를 새로 하나 추가했을 뿐인데 테스트가 실패하거나 의외의 장애가 발생하는 상황은 생각보다 흔하다. 이는 단순한 실수가 아니라, 추상화를 사용하는 방식 자체에 근본적인 결함이 있었을 가능성을 의미한다. 많은 개발자들은 '상속'을 문법적으로 잘 이해하지만, 상속이 발생시키는 추상 타..

2025. 5. 2. 17:01
설계/설계 원칙

SOLID의 OCP : 조건문 없이 유연하게 확장하는 개방-폐쇄 원칙

1. 기능 하나가 전체 시스템에 악영향을 주는 이유단순한 기능 추가가 기존 시스템에 심각한 영향을 미치는 상황은 많은 개발자들이 공통적으로 겪는 현실이다. 클라이언트의 요청은 종종 사소해 보인다. 마치 if 문 하나만 추가하면 해결될 것처럼 느껴진다. 하지만 실제로 코드를 수정하고 나면, 예상치 못한 테스트 실패나 런타임 예외가 발생하는 일이 적지 않다. 이는 단순히 조건이 하나 늘어났기 때문이 아니라, 해당 로직이 이미 복잡하게 얽힌 의존 구조 속에 놓여 있기 때문이다. 작은 변경이 미묘한 상호작용을 유발하고, 이는 연쇄적인 문제로 확산된다. 이러한 상황은 일정의 압박 속에서 반복된다. 개발자는 빠르게 대응하기 위해 기존 코드 위에 또 다른 수정 코드를 덧붙이게 되고, 결과적으로 전체 구조는 누더기처럼..

2025. 5. 1. 14:36
설계/설계 원칙

SOLID의 SRP : 클래스 책임 분리로 복잡도를 낮추는 단일 책임 원칙

1. 오래된 코드, 왜 이렇게 복잡해졌을까?오래된 애플리케이션의 코드가 복잡해지는 데에는 단 하나의 원인만 있는 것은 아니다.초기에는 잘 구조화되고 의도대로 동작하던 코드라 하더라도, 시간이 흐르면서 다양한 요인들이 누적되면서 점차 복잡도가 증가하는 경우가 많다. 예를 들어, 당장의 요구사항을 빠르게 반영해야 하는 상황에서 임시적인 방식으로 코드를 덧붙이기 시작하면, 어느새 전체 구조는 계획 없이 확장된다. 또한 인력의 잦은 교체나 설계 의도에 대한 공유 부족으로 인해 코드의 맥락을 이해하지 못한 채 기능이 누적되면서 점점 관리하기 어려운 형태가 되곤 한다. 이처럼 설계적 문제와 운영 현실이 맞물려 발생하는 코드의 복잡성은 다양한 원인에서 비롯되지만, 그 근본을 자세히 들여다보면 결국 공통된 구조적 문제..

2025. 4. 29. 17:02