SOLID 원칙 (SOLID principles)
쉽게 풀면
객체지향으로 코드를 짤 때 나중에 고치기 쉬우려면 어떻게 나눠야 하는지를 정리한 다섯 가지 규칙입니다. 하나의 클래스는 한 가지 이유로만 바뀌어야 하고, 기능을 더할 때 기존 코드를 뜯지 않아야 하며, 자식 타입은 부모 자리에 넣어도 문제가 없어야 하고, 인터페이스는 쓰지 않는 것까지 강요하지 않아야 하며, 구체적인 것보다 추상적인 것에 기대야 한다는 내용입니다.
왜 중요한가
객체지향 설계에서 자주 반복되는 실패 유형을 짧은 이름으로 정리해 주어, 코드 리뷰와 설계 토론의 공통 어휘가 되었습니다. 특히 의존 관계의 방향을 뒤집는 마지막 원칙은 의존성 주입과 계층형 아키텍처 설계의 이론적 근거가 됩니다. 실무 면접과 교육 과정에서 표준 소재로 다뤄집니다.
논문에서는 이렇게 쓰입니다
구체적인 구현 대신 약속된 인터페이스에 기대게 바꾸자 테스트가 쉬워졌다는 뜻입니다.
조금 더 깊게 보면
로버트 마틴이 정리하고 마이클 페더스가 머리글자로 묶은 것으로, 단일 책임·개방 폐쇄·리스코프 치환·인터페이스 분리·의존 역전의 다섯으로 구성됩니다. 리스코프 치환 원칙만이 형식적 정의를 갖춘 계약 관계이고 나머지는 경험적 지침에 가깝습니다. 개별 원칙은 결국 응집도와 결합도를 객체지향 맥락에서 구체화한 것으로 이해할 수 있습니다.
주의할 점
객체지향 프로그래밍의 4대 원칙인 캡슐화·상속·다형성·추상화는 객체지향이 무엇인지를 설명하는 언어적 특성인 반면, SOLID는 그 특성을 어떻게 써야 하는지에 대한 설계 지침이라는 점에서 전혀 다른 목록입니다. 원칙을 기계적으로 적용해 클래스와 인터페이스를 과도하게 쪼개면 복잡도만 늘어납니다.