03 · POP vs OOP

30초 답변 🔥 먼저 이 문장

L1개념 — 계층이 깨지는 지점

L2언어 설계 — POP가 실제로 주는 다섯 가지

1. 값 타입 다형성 — struct·enum도 프로토콜로 추상화된다. 상속은 class 전용이다.
2. retroactive conformance — extension Int: MyProtocol {}처럼 남의 타입에 나중에 능력을 붙인다.
3. 기본 구현 — protocol extension으로 공통 로직 제공. 상속의 코드 재사용 이점을 값 타입에서도.
4. 제네릭과 결합 — func f<T: Drawable>(_ x: T)는 특수화되어 정적 디스패치가 가능하다.
5. 테스트 경계 — 프로토콜로 경계를 그으면 Mock 주입이 쉬워진다.

// ⚠️ 경고: extension declares a conformance of imported type 'URL'
//          to imported protocol 'Identifiable'
extension URL: Identifiable { /* ... */ }

// ✅ "알고 하는 것"임을 명시
extension URL: @retroactive Identifiable { /* ... */ }

// ✅ 더 안전한 대안 — 내 타입으로 감싼다
struct IdentifiedURL: Identifiable { let id: URL }

언제 class 상속이 여전히 맞는가

L3구현 — witness table과 "오버라이드되지 않는" 함정

이 질문은 POP를 이해했는지 가르는 대표 문제입니다. 그리고 답이 구현에 있습니다.

protocol Greeter {
    func hello()          // 요구사항 O
}
extension Greeter {
    func hello() { print("protocol hello") }
    func bye()   { print("protocol bye") }   // 요구사항 X — extension 전용
}
struct Person: Greeter {
    func hello() { print("Person hello") }
    func bye()   { print("Person bye") }
}

let p: Greeter = Person()
p.hello()   // "Person hello"   ← 예상대로
p.bye()     // "protocol bye"   ← ⚠️ Person.bye 가 안 불린다!

let q = Person()          // 정적 타입이 Person
q.bye()     // "Person bye"     ← 같은 객체인데 결과가 다르다

protocol Trackable {
    func track()            // ✅ 요구사항으로 승격 → witness table 진입
    var name: String { get }
}
extension Trackable {
    func track() {          // 여기는 "기본값"일 뿐
        Analytics.log(name)
    }
}
struct Checkout: Trackable {
    let name = "checkout"
    func track() {          // 이제 프로토콜 타입으로 담아도 이게 불린다
        Analytics.log(name, extra: ["revenue": true])
    }
}

L4CS 근본 — 다형성 3종과 표현 문제

① 다형성에는 세 종류가 있다

프로그래밍 언어 이론에서 다형성은 세 가지로 분류됩니다(Strachey / Cardelli-Wegner 분류). "POP vs OOP" 논쟁은 사실 어느 다형성을 주력으로 쓸 것인가의 문제입니다.

OOP는 서브타입 다형성 중심이고, POP는 파라메트릭 + 애드혹 조합입니다. 그래서 POP가 성능상 유리할 수 있는 이유가 여기서 나옵니다 — 앞의 둘은 특수화로 정적 디스패치가 될 수 있지만, 서브타입 다형성은 원리상 런타임 조회가 필요합니다.

② Swift 프로토콜은 인터페이스가 아니라 타입 클래스에 가깝다

자바 인터페이스와 Swift 프로토콜을 같은 것으로 보면 여러 설명이 안 됩니다. 실제로는 Haskell의 타입 클래스(type class)에 훨씬 가깝습니다.

③ witness table = 딕셔너리 패싱

Haskell 컴파일러가 타입 클래스를 구현하는 고전적 방법이 딕셔너리 패싱입니다 — 제약이 붙은 함수에 "함수 표"를 숨은 인자로 하나 더 넘기는 것. Swift의 witness table이 정확히 같은 물건입니다.

// 우리가 쓴 것
func describe<T: Drawable>(_ x: T) -> String {
    x.draw()
}

// 특수화가 안 될 때, 개념적으로 컴파일러가 만드는 것
//   Drawable 딕셔너리(= witness table)를 숨은 인자로 받는다
func describe(_ x: OpaqueValue, _ witness: DrawableWitnessTable) -> String {
    witness.draw(x)          // 표에서 함수 포인터를 꺼내 호출
}

// ─── 그래서 두 가지가 자동으로 설명된다 ───
// (1) extension 전용 메서드가 표에 없으니 동적으로 못 찾는다  → L3의 함정
// (2) 특수화되면 표 자체가 사라져 직접 호출이 된다            → 05번의 정적 디스패치

이 한 장의 그림으로 L3의 함정과 05번의 디스패치가 같은 사실의 두 얼굴이라는 게 드러납니다.

④ 표현 문제 (Expression Problem) — OOP와 FP가 서로 못 하는 것

1998년 Philip Wadler가 정리한 고전 문제입니다. 데이터에는 두 축의 확장이 있습니다.

            새 연산 추가 →      area()   perimeter()   describe()
새 타입     Circle              ...        ...            ...
   ↓        Square              ...        ...            ...
            Triangle(새 타입)    ...        ...            ...

OOP(클래스): 새 "타입" 추가는 쉽다   (클래스 하나 추가하면 끝)
            새 "연산" 추가는 어렵다 (모든 클래스를 열어 메서드 추가)

FP(패턴매칭): 새 "연산" 추가는 쉽다  (함수 하나 추가하면 끝)
            새 "타입" 추가는 어렵다 (모든 함수의 switch 를 수정)

Swift의 프로토콜 extension은 이 문제의 한쪽을 실질적으로 완화합니다. 새 연산을 추가할 때 기존 타입을 수정하지 않고 extension으로 붙일 수 있고, 새 타입을 추가할 때도 프로토콜만 채택하면 기존 연산이 전부 따라옵니다.

protocol Shape { var area: Double { get } }

// 새 연산 추가 — 기존 타입 코드를 건드리지 않는다
extension Shape {
    var description: String { "면적 \(area)" }
}

// 새 타입 추가 — 기존 연산 코드를 건드리지 않는다
struct Triangle: Shape { var area: Double { /* ... */ } }
// description 은 자동으로 따라온다

이게 개방-폐쇄 원칙(OCP)의 실제 구현입니다 — 확장에는 열려 있고 수정에는 닫혀 있다. "POP가 왜 좋은가"에 대한 가장 깊은 답이 이겁니다. 다형성 이야기가 아니라 변경의 파급 범위 이야기예요.

⑤ 리스코프 치환 원칙과 다이아몬드 — 상속이 어긋나는 지점

• LSP: 하위 타입은 상위 타입을 대체할 수 있어야 한다. 상속은 구현까지 물려받기 때문에 위반하기 쉽습니다. 고전 예가 정사각형/직사각형 — 수학적으로는 Square is-a Rectangle이지만, width를 바꾸면 height도 바뀌므로 Rectangle이 보장하던 계약이 깨집니다. POP는 능력만 요구하고 구현을 물려주지 않으니 이 위반 여지가 구조적으로 작습니다.
• 다이아몬드 문제: 다중 상속에서 같은 조상을 두 경로로 물려받으면 저장된 상태가 중복됩니다(C++이 virtual 상속으로 씨름하는 그 문제). Swift는 클래스 다중 상속을 아예 금지해 원천 차단했고, 프로토콜은 다중 채택이 가능하지만 저장 프로퍼티가 없어서 상태 다이아몬드가 성립하지 않습니다. 남는 건 기본 구현 충돌뿐인데, 이건 컴파일 에러로 만들어 개발자가 명시적으로 해소하게 합니다.

protocol A { func run() }
protocol B { func run() }
extension A { func run() { print("A") } }
extension B { func run() { print("B") } }

struct S: A, B { }
// ❌ error: type 'S' does not conform to protocol 'A' / 'B'
//    → 애매한 채로 조용히 하나를 고르지 않는다. 명시하라고 요구한다.

struct T: A, B { func run() { print("T") } }   // ✅ 직접 해소

CS 정본으로 더 내려가기

이 페이지의 L4는 면접 답변에 필요한 깊이까지만 팝니다. 같은 주제를 CS 원리 → iOS 매핑 → 재현·측정 순서로 끝까지 파는 것은 허브의 iOS 개발자 CS 로드맵이고, 대응 챕터는 아래입니다.

경험으로 말하기

꼬리 질문 대비

func makeSome() -> some Shape { Circle() }   // 항상 Circle. 타입이 하나로 고정
func makeAny()  -> any Shape  { Bool.random() ? Circle() : Square() }  // 둘 중 하나

// some: 컴파일 타임에 타입 확정 → 특수화·정적 디스패치·박싱 없음
// any : 런타임에 결정      → existential container, witness table 경유

let a: [any Shape] = [Circle(), Square()]   // ✅ 섞을 수 있다
// let s: [some Shape] = [Circle(), Square()]  // ❌ 타입이 하나여야 한다

쉽게 이해하기

OOP는 생물 분류표입니다. 포유류 → 개과 → 개. 부모가 하나뿐이라 깔끔하지만 유연하지 않아요. "로봇 강아지"를 넣으려면 표가 이상해집니다. 기계이기도 하고 강아지이기도 한데, 부모는 하나만 고를 수 있으니까요.

POP는 자격증입니다. "운전 가능", "수영 가능", "충전 가능". 사람이든 로봇이든 필요한 자격증만 따면 됩니다. 몇 개를 따든 상관없고, 나중에 새 자격증을 만들어서 이미 있는 사람에게 발급할 수도 있어요(retroactive conformance).

그런데 여기 함정이 있습니다. 자격증에 "기본 요령" 안내문을 붙일 수 있는데(protocol extension), 이 안내문이 자격증 항목(요구사항)에 없는 내용이면 이상한 일이 생깁니다. 사람을 "자격증 소지자"로만 보고 부르면 안내문대로 하고, "그 사람"으로 보고 부르면 자기 방식대로 합니다. 같은 사람인데 어떻게 부르느냐에 따라 행동이 달라지는 거죠.

이유는 단순합니다. 자격증 발급 대장(witness table)에는 자격증 항목만 적혀 있어서, 대장을 뒤져 보는 방식으로는 "그 사람 고유 방식"을 찾을 수가 없습니다. 그래서 대장에 없으면 안내문으로 바로 갑니다.

해결도 여기서 나옵니다. 사람마다 다르게 하고 싶은 항목이라면, 안내문에만 적지 말고 자격증 항목 자체에 넣으세요. 그러면 대장에 올라가고, 어떻게 부르든 그 사람 방식이 나옵니다.

설계 근거 · 1차 자료

이 페이지의 "왜 그렇게 설계했나" 주장은 아래에서 나왔습니다. 면접에서 근거를 물으면 이 이름들을 대면 됩니다.