프로그래밍 패러다임과 SOLID: 단정 대신 선택 기준으로 정리하기

2022년 6월 28일, 『면접을 위한 CS 전공지식 노트』의 프로그래밍 패러다임 부분을 읽고 선언형·함수형·객체지향·절차지향과 SOLID를 목록으로 옮겼다. 기존 글은 객체지향이 다른 패러다임보다 느리다고 일반화했고, SOLID를 문장 하나씩 외우는 규칙처럼 적었다. 이번에는 개념의 경계와 실제 선택 기준을 중심으로 다시 정리한다.

학습 대상: 『면접을 위한 CS 전공지식 노트』

패러다임은 서로 배타적인 상자가 아니다

프로그래밍 패러다임은 문제와 프로그램을 바라보는 관점이다. 하나의 언어와 프로그램 안에서도 여러 관점이 섞일 수 있다. Java는 클래스 기반 객체지향 언어지만, 절차적인 제어 흐름과 람다·스트림 같은 함수형 스타일도 사용할 수 있다.

관점	주로 묻는 질문	대표적인 표현
명령형	상태를 어떤 순서로 바꿀 것인가	대입, 반복문, 조건문
절차형	작업 순서를 어떤 프로시저로 나눌 것인가	함수·프로시저 호출
객체지향	상태와 행동을 어떤 객체와 협력으로 묶을 것인가	클래스, 객체, 메시지, 인터페이스
선언형	원하는 결과와 제약을 어떻게 기술할 것인가	SQL 질의, 규칙, 구성 선언
함수형	값을 함수로 변환하고 부수 효과를 어떻게 통제할 것인가	순수 함수, 불변 값, 고차 함수

절차형은 보통 명령형의 한 방식으로 볼 수 있고, 함수형은 선언형 성격을 가질 수 있다. 이 표도 절대적인 분류표라기보다 차이를 이해하기 위한 지도다.

함수형 프로그래밍에서 구분할 두 개념

순수 함수는 같은 입력에 대해 같은 결과를 만들고, 함수 밖의 상태를 관찰하거나 변경하는 부수 효과를 피하는 함수다. 입력에만 의존한다는 설명만으로는 외부 상태 변경 여부가 빠지기 쉽다.

고차 함수는 함수를 인자로 받거나 함수를 결과로 돌려주는 함수다. 함수가 일급 값으로 취급되는 언어에서는 함수를 변수에 담고 전달하는 방식으로 재사용 가능한 연산을 구성할 수 있다.

함수형 스타일을 사용한다고 모든 코드에서 I/O나 상태를 없앨 수 있는 것은 아니다. 외부 효과가 발생하는 경계를 분명히 하고, 계산 부분을 예측하기 쉽게 만드는 것이 핵심에 가깝다.

객체지향의 네 개념은 목적과 비용을 함께 본다

• 추상화: 지금 문제에 필요한 특성과 행동을 드러내고 나머지 세부를 감춘다.
• 캡슐화: 관련 상태와 행동을 묶고, 객체의 유효한 상태를 지키도록 접근 경계를 둔다.
• 상속: 기존 타입의 상태와 행동을 바탕으로 하위 타입을 정의한다. 재사용 수단이지만 강한 결합과 취약한 계층을 만들 수 있어 관계가 실제로 대체 가능한지 확인해야 한다.
• 다형성: 같은 타입이나 인터페이스를 통해 서로 다른 구현을 사용할 수 있게 한다. Java에서는 오버라이딩과 인터페이스 구현이 대표적이다.

객체지향은 설계 시간이 항상 더 오래 걸리거나 실행 속도가 항상 더 느린 패러다임이 아니다. 성능은 알고리즘, 자료구조, 메모리 배치, 런타임 최적화, I/O와 워크로드에 따라 달라진다. 패러다임 이름만으로 성능 순위를 정하면 실제 병목을 놓친다.

SOLID는 설계 판단을 돕는 질문이다

원칙	외우기보다 확인할 질문
단일 책임 원칙(SRP)	이 모듈이 바뀌는 이유와 이해관계자가 지나치게 여러 개인가?
개방-폐쇄 원칙(OCP)	안정된 코드를 매번 고치지 않고 새 동작을 추가할 경계가 있는가?
리스코프 치환 원칙(LSP)	하위 타입을 사용해도 상위 타입이 약속한 행위와 불변 조건이 유지되는가?
인터페이스 분리 원칙(ISP)	사용하지 않는 기능까지 클라이언트가 의존하도록 강제하는가?
의존 역전 원칙(DIP)	핵심 정책이 구체적인 인프라 구현에 직접 끌려가고 있지는 않은가?

SRP의 ‘하나’는 메서드 수가 아니라 변경 이유에 관한 말이다. OCP도 코드를 절대 수정하지 말라는 뜻이 아니다. DIP는 단순히 상위 클래스를 하나 더 만드는 기법이 아니라, 정책과 세부 구현 사이의 의존 방향을 추상화로 조절하는 원칙이다.

이 원칙들은 규칙을 많이 적용할수록 좋은 점수표가 아니다. 작은 프로그램에 불필요한 계층을 미리 만들면 오히려 이해하기 어려워진다. 실제 변경 압력, 테스트 비용, 팀의 이해 수준을 보고 필요한 경계만 도입해야 한다.

패러다임을 고르는 기준

1. 데이터 변환이 중심이면 순수한 계산과 부수 효과 경계를 먼저 나눈다.
2. 상태와 수명주기를 가진 개체의 협력이 중심이면 객체와 인터페이스를 검토한다.
3. 단순한 순차 작업이면 절차적인 코드가 가장 읽기 쉬울 수 있다.
4. 성능이 중요하면 패러다임을 추측하기보다 실제 워크로드를 측정한다.
5. 설계 원칙은 현재 변경 이유를 설명할 때 도입한다.

디자인 패턴을 선택하는 기준은 디자인 패턴을 문제 신호로 고르는 법에서 이어서 볼 수 있다.

참고 자료

• Oracle Java Tutorials: Object-Oriented Programming Concepts
• Java Language Specification: Introduction
• Microsoft Learn: Architectural principles
• Microsoft Learn: Common web application architectures