프로그래밍 패러다임

패러다임이란

프로그래밍 패러다임은 프로그램을 무엇의 조합으로 볼지에 대한 관점이다. 명령의 나열로 볼 수도, 함수의 합성으로 볼 수도, 협력하는 객체로 볼 수도 있다. 패러다임은 언어에 묶여 있지 않다. 현대 언어 대부분은 여러 패러다임을 섞어 쓰는 멀티 패러다임 언어다.

언어는 수천 개지만 패러다임은 수십 개다. 패러다임의 눈으로 보면 Java, JavaScript, C#, Ruby, Python은 거의 같은 객체 지향 패러다임을 구현한 언어다.

패러다임은 개념의 묶음이다

패러다임을 정확하게 정의하는 방법은 그 패러다임이 쓰는 프로그래밍 개념의 집합으로 보는 것이다. 개념들을 작은 핵심 언어(kernel language)로 묶으면 패러다임 하나가 된다. 겉보기에 전혀 다른 함수형과 객체 지향도 개념 하나 차이일 때가 많다.

패러다임을 가르는 축은 둘이다.

• 관찰 가능한 비결정성(observable nondeterminism): 같은 입력으로 시작해도 스케줄러의 선택에 따라 결과가 달라질 수 있는가. 경쟁 상태(race condition)가 대표 증상이다. 이름 붙은 상태와 동시성을 함께 가진 언어(Java 등)는 이것을 표현할 수 있어 동시성 프로그래밍이 어렵다. 실세계 상호작용(클라이언트-서버)에는 필요하지만, 필요할 때만 허용한다. 모든 프로그램이 결정적인 선언적 동시성(declarative/dataflow concurrency) 패러다임도 있다.
• 상태의 표현력: 상태가 이름 붙었나(named, 변수·셀) 이름 없나(unnamed, 모나드처럼 인자로 실려 다니나), 결정적인가, 순차인가 동시인가. 함수형(이름 없음·결정적·순차) → 선언적 동시성 → 동시 논리 프로그래밍 → 메시지 전달·공유 상태 동시성(이름 있음·비결정적·동시) 순으로 표현력이 커진다.

이름 붙은 상태는 모듈성을 위해 필요하다. 모듈 M의 함수 F가 몇 번 불렸는지 세고 싶을 때, 상태가 없으면 F의 인자에 카운트 입력·출력을 더해야 하고 F를 부르는 모든 사용자 코드가 바뀐다. 모듈 안에 셀 하나를 두면 인터페이스를 그대로 두고 해결된다. 대신 상태를 가진 구성 요소는 한 번 옳다고 증명해도 계속 옳다는 보장이 없다. 그래서 상태는 밖에서 들여다볼 방법을 남겨 둔다.

새 개념이 필요하다는 신호: 창조적 확장 원칙

프로그램이 풀려는 문제와 무관한 기술적 이유로 프로그램 전체를 고쳐야 하는 일(pervasive modification) 이 생기면, 언어에 개념 하나가 빠져 있다는 신호다. 이를 창조적 확장 원칙(creative extension principle)이라 한다.

개념은 많을수록 좋은 것이 아니다. 너무 적으면 프로그램이 복잡해지고, 너무 많으면 추론이 복잡해진다. 문제에 딱 맞는 개념만 가진 패러다임을 고른다. 상태가 복잡성의 주원인이라는 관점은 소프트웨어 복잡성에 있다.

여덟 가지 패러다임

구조적 프로그래밍: goto를 없앤 첫 전환

명령형 안에서도 가장 먼저 자리 잡은 규율은 구조적 프로그래밍(structured programming) 이다. 프로그램을 순차·선택(if)·반복(while)·프로시저 호출만으로 짜고 임의 점프 goto를 쓰지 않는다.

이 네 재료는 거의 모든 언어가 갖춘 기본 구성 요소다.

함수는 코드 재사용 수단이자 추상화 단위다. 같은 계산을 여러 곳에 복사하면 버그를 고칠 때 모든 복사본을 찾아야 한다. 함수로 묶으면 부르는 쪽은 이름과 매개변수·반환값만 알고 안의 반복문과 변수는 보지 않는다. 함수가 다른 함수를 부르며 층을 쌓기 때문에 큰 프로그램을 함수 단위로 나눠 여러 사람이 동시에 짤 수 있다. 자주 쓰는 함수를 미리 짜서 검증해 둔 묶음이 라이브러리(library)다. 함수를 얼마나 작게 나눌지는 클린 코드: 함수와 이름에 있다.

근거는 「실행 중인 프로세스의 진행 상황을 어떤 좌표로 설명할 수 있는가」다. 구조적 제어만 쓰면 지금 위치는 코드 안의 위치(텍스트 인덱스) 와 호출 스택·반복 횟수(동적 인덱스) 로 기술된다. 이 좌표는 프로그래머가 통제하지 않아도 정해지므로 변수 값이 무엇을 뜻하는지 해석할 기준이 된다. goto를 마구 쓰면 그런 좌표 체계를 찾기가 끔찍하게 어려워진다. 이 논증(Dijkstra, 1968)은 이후 「~ considered harmful」이라는 제목 관용구를 낳았다. 같은 논리를 동시성으로 옮긴 것이 구조적 동시성이다. C의 goto cleanup처럼 함수 안에서 한 방향으로만 뛰는 제한된 쓰임은 지금도 관용구로 남아 있다.

반응형은 반응형 프로그래밍과 RxJS, 동시성은 동시성·병렬·비동기·논블로킹과 동시성 모델에서 자세히 다룬다.

명령형·함수형·객체 지향 비교

같은 일을 세 방식으로 쓰면 차이가 보인다.

# 명령형: 상태를 바꿔 가며 어떻게 할지 적는다
total = 0
for p in prices:
    if p > 100:
        total += p
 
# 함수형: 데이터를 변환하는 식으로 무엇을 원하는지 적는다
total = sum(filter(lambda p: p > 100, prices))
 
# 객체 지향: 책임을 가진 객체에게 메시지를 보낸다
total = cart.total_of_items_over(100)

함수형 프로그래밍의 핵심 개념

순수 함수가 함수형의 메커니즘 전체를 받친다. 출력이 입력에만 달려 있으므로 함수 호출을 결과값으로 바꿔 생각할 수 있고(등식 추론), 결과를 캐시해도(메모이제이션), 호출 순서를 바꾸거나 미뤄도(지연 평가), 여러 코어에 나눠도(병렬화) 의미가 같다. 테스트는 입력과 기대 출력만 있으면 된다. 고차 함수와 합성도 조립하는 부품이 순수해야 조립 결과를 예측할 수 있다. 치환이 깨지는 예는 프로그래밍 언어 의미론의 「순수성과 참조 투명성」에 있다.

부수 효과를 모두 없애는 것은 이상이 아니다. 화면에 그리고, 파일에 쓰고, 요청에 답하는 것이 프로그램의 목적이라 효과가 없는 프로그램은 아무 일도 하지 않는다. 목표는 효과를 없애는 것이 아니라 분리하고 경계로 모으는 것이다. 계산은 순수 함수로 짜고, 입출력은 프로그램 가장자리의 얇은 층에 모은다(함수형 코어, 명령형 셸). Haskell은 효과를 IO 타입으로 표시해 이 분리를 타입으로 강제한다(타입 시스템의 효과 시스템). 성능이 중요한 곳에서는 지역 변수를 바꾸는 명령형 반복문이 더 단순하고 빠를 수도 있다. 바깥에서 관찰되지 않는 지역 변경은 함수의 순수성을 해치지 않는다.

순수 함수는 스레드 안전하다. 경쟁 상태는 여러 스레드가 공유 가변 상태를 동시에 읽고 쓸 때 생기는데, 순수 함수는 공유 상태를 읽거나 쓰지 않고 인자와 지역 변수만 쓰므로(지역 변수는 스레드마다 스택에 따로 있다) 몇 개의 스레드가 동시에 불러도 서로 간섭하지 않는다. 락이 필요 없다. 단, 인자로 받은 가변 객체를 다른 스레드가 동시에 고치고 있다면 함수가 읽는 값 자체가 흔들리므로, 불변 데이터와 함께 써야 완전히 안전하다.

함수형 메커니즘을 쓰는 이유:

• 추론과 테스트: 상태 변화를 따라가지 않고 함수 하나만 보고 이해한다. 버그 후보가 효과가 있는 경계로 좁혀진다.
• 동시성과 병렬화: 불변 데이터와 순수 함수는 락 없이 나눠 처리할 수 있다. 멀티코어와 분산 처리(MapReduce, Spark)의 기본 모델이다.
• 조합과 재사용: 고차 함수로 「무엇을 할지」를 인자로 넘겨 반복 구조를 한 번만 쓴다.
• 선언적 표현: 「어떻게」가 아니라 「무엇을」 쓰므로 의도가 드러난다.

비용도 있다. 불변 갱신은 복사·할당이 늘고, 재귀와 고차 함수는 익숙하지 않은 사람에게 읽기 어렵다. 그래서 현대 언어는 순수 함수형으로 가기보다 람다·스트림·불변 컬렉션·record 같은 함수형 도구를 섞는다. JavaScript에서의 실천(액션·계산·데이터, 카피 온 라이트, 커링)은 함수형 프로그래밍에 있다.

객체 지향의 핵심 개념

구성 요소

네 기둥

추상화와 캡슐화는 자주 섞어 쓰지만 묻는 질문이 다르다.

추상화는 설계 수준에서 경계를 정하고, 캡슐화와 정보 은닉은 그 경계를 코드로 지킨다. 정보 은닉이 결합도를 낮추는 원리는 계층과 API에 있다.

객체 사이의 관계도 두 가지로 나눠 말한다. is-a는 "Car는 Vehicle이다"처럼 상속으로 표현하고, has-a는 "Car는 Engine을 가진다"처럼 다른 객체를 멤버로 들고 쓰는 것이다. has-a는 부분의 수명이 전체에 묶이는 합성(composition)과 따로 사는 집합(aggregation)으로 갈리며, UML 표기와 코드 모양은 UML 관계에 있다.

클래스와 객체 지향은 같은 말이 아니다

클래스가 있다고 객체 지향 언어인 것도, 객체 지향 언어에 클래스가 꼭 있어야 하는 것도 아니다.

• 클래스 없는 객체 지향: JavaScript(ES2015 전)와 Self는 객체가 다른 객체를 프로토타입으로 삼아 직접 상속한다(객체 지향 프로그래밍과 JavaScript). Go는 클래스·상속 없이 구조체, 메서드, 암묵적 인터페이스, 임베딩으로 캡슐화와 다형성을 얻는다(Go 언어). 객체 지향의 본질을 메시징·캡슐화·늦은 바인딩으로 보면 클래스는 그 구현 수단의 하나일 뿐이다(객체 지향의 본질: 메시징).
• 클래스가 있어도 객체 지향이 아닌 코드: Java로도 static 메서드와 데이터만 든 클래스로 절차적 코드를 짤 수 있다. C++·Python·Kotlin은 객체 지향을 지원하는 멀티 패러다임 언어다. 클래스는 데이터와 함수를 묶는 문법이고, 객체 지향은 책임을 가진 객체들이 메시지로 협력하는 설계 방식이다.

상속은 재사용 수단이지만 결합을 강하게 만든다. 행동을 재사용하려면 상속보다 조합(composition)을 먼저 고려하는 것이 일반적인 원칙이다. 객체 지향을 클래스가 아니라 메시지를 주고받는 객체로 보는 관점은 객체 지향의 본질: 메시징에, JavaScript에서의 객체 지향은 객체 지향 프로그래밍과 JavaScript에 있다.

정리

• 패러다임은 프로그램을 보는 관점이고, 현대 언어는 여러 패러다임을 섞는다.
• 패러다임은 레코드·클로저·동시성·이름 붙은 상태 같은 개념의 묶음이다. 비결정성과 상태는 필요할 때만 들인다. 코드 전체를 고쳐야 하는 일이 반복되면 개념이 하나 빠졌다는 신호다.
• 명령형은 "어떻게", 선언형·함수형은 "무엇을" 쓴다. 객체 지향은 상태와 행동을 객체로 묶어 책임을 나눈다.
• 함수형은 불변성과 순수 함수로 추론과 병렬화를 쉽게 하고, 객체 지향은 큰 도메인을 역할로 나누기 쉽게 한다.
• 순수 함수는 공유 상태를 건드리지 않아 스레드 안전하다. 부수 효과는 없애는 것이 아니라 경계로 모은다.
• 클래스는 객체 지향의 한 구현 수단이다. 프로토타입·구조체 기반 객체 지향도 있다.
• 객체 지향의 네 기둥은 추상화, 캡슐화, 상속, 다형성이다. 상속보다 조합을 먼저 생각한다.

관련 노트: 소프트웨어 복잡성, 상태와 결합을 다루는 열다섯 가지 설계, 객체 지향의 본질: 메시징, 객체 지향 프로그래밍과 JavaScript, 반응형 프로그래밍과 RxJS, 동시성·병렬·비동기·논블로킹과 동시성 모델, GoF 디자인 패턴, 프로그램이 실행되기까지, 프로그래밍 언어 의미론, 함수형 프로그래밍