Data Oriented Programming

1. 객체 지향 프로그래밍의 복잡성

이 챕터는 OOP를 비판하기 위한 것이 아니라, OOP가 시스템 복잡성을 증가시키는 경향이 있음을 인식하게 하고, 이를 줄이는 대안 패러다임인 DOP(Data-Oriented Programming) 를 탐색하도록 동기를 부여하기 위한 것이다.

배경: Klafim 프로젝트 요구사항

• 도서 소셜 네트워크 스타트업 Klafim의 글로벌 도서관 관리 시스템(GLMS) 프로토타입 개발
• 두 가지 사용자 유형: Member(회원) / Librarian(사서)
• 핵심 기능 목록

1.1 OOP 설계: 고전적 방식

1.1.1 설계 단계

• Theo(개발자)는 모든 비즈니스 엔티티를 클래스로 표현하는 OOP 설계 접근 방식을 채택
• UML 클래스 다이어그램을 먼저 작성한 후 코딩에 진입

식별된 주요 클래스

• Library: 시스템의 중심 루트 클래스
• Book: 도서 엔티티
• BookItem: 도서의 개별 복사본
• BookLending: 대출 발생 시 생성되는 대출 정보 객체
• Member: 도서관 회원
• Librarian: 사서
• User: Librarian과 Member의 기반 클래스
• Catalog: 도서 목록 관리
• Author: 저자

1.1.2 UML 기초 (UML 101)

UML 화살표 종류 및 의미

핵심 인사이트: 합성(Composition)은 생명주기가 연동되고, 연관(Association)은 각자 독립적 생명주기를 가진다.

1.1.3 클래스 다이어그램 각 요소 설명

Library 클래스

• 시스템의 루트 역할, 자체 동작 없이 소유 객체에 모두 위임
• 소유 관계 (합성)
  • Member 다수
  • Librarian 다수
  • Catalog 1개

User / Member / Librarian 클래스

• User: 공통 기반 클래스
  • 데이터: id, email, password
  • 메서드: login()
• Member: User를 상속
  • 추가 데이터: 없음
  • 메서드: checkout(), returnBook(), block(), unblock(), isBlocked()
  • BookLending 다수 소유
• Librarian: User를 상속
  • 추가 데이터: 없음
  • 메서드: blockMember(), unblockMember(), getBookLendingsOfMember(), addBookItem()

Catalog 클래스

• 도서 관리 책임
• 메서드: search(), addBookItem()
• Book 다수 소유

Book / BookItem / BookLending 클래스

• Book
  • 데이터: id, title
  • Author와 다대다 연관 관계 (독립적 생명주기)
  • BookItem 다수 소유
• BookItem: 도서의 개별 복사본
  • 데이터: id, libId
  • 메서드: checkout()
  • BookLending 다수 소유
• BookLending: 대출 이벤트 객체
  • 데이터: id, lendingDate, dueDate
  • 메서드: isLate(), returnBook()

1.2 복잡성의 원인

OOP 시스템이 복잡해지는 근본 원인은 다음 네 가지로 요약된다.

참고: Ben Moseley & Peter Marks의 논문 “Out of the Tar Pit”(2006)에서 정의한 개념, 즉 “시스템을 이해하기 어렵게 만드는 것”을 의미한다. 실행 자원 소비량과는 무관하다.

1.2.1 클래스 간 관계의 과다

문제: 코드와 데이터가 클래스 안에 혼합되면, 클래스는 코드 관계와 데이터 관계를 동시에 가져 관계가 폭발적으로 증가한다.

예시 - Member 클래스의 관계

flowchart TD
    Library -->|has many| Member
    Member -->|has many| BookLending
    Member -->|extends| User
    Librarian -->|uses| Member
    Member -->|uses| BookItem

• Member 클래스 하나가 5개의 관계에 연루됨
  • 데이터 관계 2개: Library, BookLending
  • 코드 관계 3개: User(상속), Librarian(사용됨), BookItem(사용)

해결 사고 실험: Member를 MemberCode와 MemberData로 분리하면?

flowchart LR
    subgraph Data Side
        Library2[Library] -->|has many| MemberData
        MemberData -->|has many| BookLending2[BookLending]
    end
    subgraph Code Side
        Librarian2[Librarian] -->|uses| MemberCode
        MemberCode -->|extends| UserCode[UserCode]
        MemberCode -->|uses| BookItem2[BookItem]
    end

• 두 독립적인 서브시스템으로 분리됨
• 각 부분을 별도로, 순서 무관하게 이해 가능

핵심 인사이트: 코드와 데이터가 분리된 시스템은 혼합된 시스템보다 단순하다. 단순한 독립 부분 여러 개로 구성된 시스템이, 하나의 복잡한 덩어리보다 덜 복잡하다.

1.2.2 예측 불가능한 코드 동작

Case 1: 지역 변수에 할당 후 두 번 출력 (예측 가능)

class Member {
  isBlocked: boolean;

  displayBlockedStatusTwice(): void {
    const isBlocked = this.isBlocked; // 값을 로컬 변수에 복사
    console.log(isBlocked);           // true
    console.log(isBlocked);           // 항상 true (예측 가능)
  }
}

• boolean은 원시 타입(primitive), 값이 복사됨
• 결과 예측 가능: 두 번 모두 동일한 값 출력

Case 2: 객체 멤버를 직접 두 번 접근 (예측 불가능)

class Member {
  isBlocked: boolean;

  displayBlockedStatusTwice(): void {
    console.log(this.isBlocked); // true 일 수 있음
    // --- 컨텍스트 스위치 발생 가능 ---
    // 다른 스레드 또는 비동기 코드가 this.isBlocked = false 로 변경할 수 있음
    console.log(this.isBlocked); // false 일 수도 있음
  }
}

• 싱글 스레드 환경: 동일 값 출력 (안전해 보임)
• 멀티 스레드 환경: 두 console.log 사이에 컨텍스트 스위치가 발생하면 값이 바뀔 수 있음
• JavaScript/TypeScript에서도 비동기 코드에 의해 동일한 문제 발생 가능

OOP에서의 해결책과 그 비용

• mutex 등 동시성 보호 메커니즘 사용
  • 성능 저하 발생
  • 데드락(deadlock) 위험 증가

핵심 인사이트: 데이터가 가변적(mutable)이면 코드는 예측 불가능하다. DOP는 원시 타입과 컬렉션 타입 모두를 불변(immutable) 값으로 동일하게 취급함으로써 이 문제를 해결한다.

1.2.3 복잡한 데이터 직렬화

시나리오: /search REST 엔드포인트를 JSON으로 구현한다고 가정

요청 JSON

{
  "searchCriteria": "author",
  "query": "albert"
}

응답 JSON

[
  {
    "title": "The world as I see it",
    "authors": [{ "fullName": "Albert Einstein" }]
  },
  {
    "title": "The Stranger",
    "authors": [{ "fullName": "Albert Camus" }]
  }
]

OOP 방식의 구현 구조

flowchart LR
    SearchController -->|creates| SearchQuery
    SearchController -->|calls| Catalog
    SearchController -->|creates| SearchResult
    Catalog -->|returns| BookList["List<Book>"]

• SearchQuery: JSON 문자열 → 데이터 객체 역직렬화
• SearchController: 흐름 조율
• SearchResult: 데이터 객체 → JSON 문자열 직렬화

문제점 - 엔드포인트마다 반복

• 직렬화/역직렬화 로직이 매번 새로운 클래스에 중복 작성됨
• 본질적으로 모든 직렬화는 동일한 작업: 필드명과 값을 순회하며 연결
• OOP에서는 데이터가 클래스 멤버에 갇혀있어 범용적 접근이 불가능

핵심 인사이트: OOP에서 데이터는 클래스 멤버 안에 갇혀 있어(locked in), 범용적인 직렬화가 어렵다. 대부분의 OOP 언어는 리플렉션(reflection)이나 코드 장황함(verbosity)으로 이를 부분적으로 완화하지만, 둘 다 복잡성을 수반한다.

1.2.4 복잡한 클래스 계층 구조

문제: 코드가 클래스 메서드에 갇혀있어(locked in), 새 요구사항 발생 시 계층 구조를 재편해야 한다.

시나리오 1: VIP Member 추가 요구

• VIPMember는 회원이면서(Member) 도서 아이템 추가 권한(Librarian의 기능)도 필요
• Librarian::addBookItem 코드를 재사용할 방법이 없음 - 클래스에 갇혀있기 때문

해결책: 중간 기반 클래스 UserWithBookItemRight 추가

classDiagram
    User <|-- UserWithBookItemRight
    UserWithBookItemRight <|-- Librarian
    UserWithBookItemRight <|-- VIPMember
    User <|-- Member
    VIPMember --|> Member : also extends

• addBookItem을 UserWithBookItemRight로 이동
• Librarian과 VIPMember 모두 UserWithBookItemRight를 상속
• VIPMember가 Member와 UserWithBookItemRight를 동시에 상속 -> 다중 상속 문제 발생

시나리오 2: Super Member 추가 요구

• SuperMember는 회원이면서 특정 Librarian 권한(대출 목록 조회)도 필요
• 계층 구조에 UserWithBlockMemberRight까지 추가 필요

최종 결과

classDiagram
    User <|-- UserWithBookItemRight
    User <|-- UserWithBlockMemberRight
    UserWithBookItemRight <|-- VIPMember
    UserWithBlockMemberRight <|-- VIPMember
    UserWithBookItemRight <|-- Librarian
    UserWithBlockMemberRight <|-- Librarian
    User <|-- Member
    Member <|-- VIPMember
    Member <|-- SuperMember
    UserWithBookItemRight <|-- SuperMember

• “Deadly Diamond of Death” 패턴이 3개 발생
  • 클래스 D가 B와 C를 상속하고, B와 C가 모두 A를 상속하는 모호성
• 시스템이 너무 복잡해져 데드라인 내 구현 실패

핵심 인사이트: OOP에서는 코드가 클래스에 갇혀있어 새 요구사항이 생길 때마다 클래스 계층 전체를 재설계해야 한다. 클래스 상속보다 합성(Composition over Inheritance) 을 선호해야 한다.

챕터 1 요약

용어 정의

• 복잡성(Complexity): 이해하기 어려운 것 (실행 자원과 무관)
• DOP: Data-Oriented Programming
• OOP: Object-Oriented Programming
• FP: Functional Programming

OOP의 복잡성 증가 원인 4가지

1. 코드와 데이터 혼합 - 클래스가 코드 관계와 데이터 관계를 동시에 가져 관계가 복잡해짐
2. 객체 가변성 - 코드 동작 예측 불가, 멀티스레드 환경에서 명시적 동기화 필요
3. 데이터가 객체에 갇힘 - 범용적 데이터 직렬화/역직렬화가 어려움
4. 코드가 클래스에 갇힘 - 새 요구사항마다 복잡한 클래스 계층 재설계 필요

DOP가 제시하는 방향

• 코드와 데이터를 분리
• 데이터를 불변(immutable) 으로 취급
• 데이터에 범용적으로 접근 가능하도록 설계
• DOP는 OOP와도, FP와도 호환 가능

핵심 요약: OOP의 복잡성 증가는 특정 언어의 문법 문제가 아니라 “객체 안에 상태와 메서드를 함께 묶는다”는 OOP의 근본 철학에서 비롯된다. 코드와 데이터를 분리하는 것만으로도 시스템은 눈에 띄게 단순해진다.

2. 코드와 데이터의 분리

DOP의 첫 번째 원칙: 코드는 함수 안에, 데이터는 함수의 컨텍스트 밖에 존재해야 한다. 함수의 동작이 함수 내부에 어떤 식으로든 캡슐화된 데이터에 의존해서는 안 된다.

2.1 DOP 시스템의 두 가지 구성 요소

• DOP 시스템은 명확히 두 파트로 분리된다
  • 데이터 엔티티(Data Entities): 정보를 보유하는 구조체. 멤버(필드)만 가짐
  • 코드 모듈(Code Modules): 기능을 수행하는 순수 함수들의 집합. 상태를 가지지 않음
• DOP 원칙은 언어에 종속되지 않는다 — OOP 언어, 함수형 언어 모두에서 적용 가능
• DOP는 데이터 캡슐화에 반대한다
  • OOP에서 데이터와 코드가 하나의 객체에 혼재하는 것이 복잡성과 경직성의 주요 원인

flowchart LR
    subgraph DOP 시스템
        DE[데이터 엔티티\n멤버만 존재\n코드 없음]
        CM[코드 모듈\n상태 없는 함수들\n멤버 없음]
    end
    CM -->|데이터를 인자로 받아 사용| DE

2.2 데이터 엔티티 (Data Entities)

• 데이터 엔티티: 시스템에서 정보를 보유하는 부분
• 데이터 엔티티를 발견하는 방법: 요구사항에서 명사와 명사구를 찾아라

도서관 관리 시스템 예시 (Library Management System)

요구사항에서 추출한 명사(데이터 엔티티):

• users, members, librarians → 사용자 관리(User Management) 그룹
• books, authors, book copies, book lendings → 카탈로그(Catalog) 그룹

mindmap
  root((Library Data))
    Catalog
      Books
      Authors
      Book Items
      Book Lendings
    User Management
      Users
      Members
      Librarians

TIP: 데이터 엔티티를 발견한 후, 중첩 목록이나 마인드맵으로 고수준 그룹으로 분류하라.

2.3 코드 모듈 (Code Modules)

• 코드 모듈: 기능(함수)의 집합체. DOP에서는 모든 함수가 상태를 가지지 않는다
• 기능을 발견하는 방법: 요구사항에서 동사구를 찾아라

모듈 설계 원칙

1. 외부에 노출되는 함수들을 하나의 모듈로 묶어라
2. 모듈 내 모든 함수는 정적(static) 이며 상태가 없다
3. 함수가 조작할 데이터는 첫 번째 인자로 명시적으로 전달한다
4. 고수준 모듈은 고수준 데이터 엔티티에 대응한다

OOP vs DOP 비교

기존 OOP 방식 — 데이터가 암묵적 인자(implicit argument)로 전달됨:

class Library {
  catalog: Catalog;
  userManagement: UserManagement;

  getBookLendings(userId: string, memberId: string) {
    // this.catalog, this.userManagement 를 통해 상태에 접근
  }
}

DOP 방식 — 데이터가 명시적 인자(explicit argument)로 전달됨:

class Library {
  static getBookLendings(
    libraryData: LibraryData,
    userId: string,
    memberId: string
  ) {
    // libraryData를 통해 데이터에 접근
  }
}

핵심 인사이트: 전통적인 OOP에서 객체의 상태는 메서드의 암묵적 인자다. DOP에서는 이를 명시적 인자로 전달한다.

도서관 시스템의 최종 모듈 구조

flowchart TD
    subgraph lib["Library 모듈"]
        L1["searchBook(libraryData, searchQuery)"]
        L2["addBookItem(libraryData, bookItemInfo)"]
        L3["blockMember(libraryData, memberId)"]
        L4["unblockMember(libraryData, memberId)"]
        L5["login(libraryData, loginInfo)"]
        L6["getBookLendings(libraryData, userId)"]
        L7["checkoutBook(libraryData, userId, bookItemId)"]
        L8["returnBook(libraryData, userId, bookItemId)"]
    end

    subgraph cat["Catalog 모듈"]
        C1["searchBook(catalogData, searchQuery)"]
        C2["addBookItem(catalogData, bookItemInfo)"]
        C3["checkoutBook(catalogData, bookItemId)"]
        C4["returnBook(catalogData, bookItemId)"]
        C5["getBookLendings(catalogData, userId)"]
    end

    subgraph um["UserManagement 모듈"]
        U1["blockMember(userManagementData, memberId)"]
        U2["unblockMember(userManagementData, memberId)"]
        U3["login(userManagementData, loginInfo)"]
        U4["isLibrarian(userManagementData, userId)"]
    end

    lib -->|사용| cat
    lib -->|사용| um

• Library 모듈의 함수들이 따르는 공통 패턴:
  • libraryData를 인자로 받는다
  • Catalog 함수 호출 시 libraryData.catalog를 전달한다
  • UserManagement 함수 호출 시 libraryData.userManagement를 전달한다

TIP: 고수준 DOP 모듈은 고수준 데이터 엔티티에 대응한다. TIP: DOP 모듈 간의 유일한 관계는 사용(Usage) 관계다.

2.4 DOP 시스템은 이해하기 쉽다

왜 이해하기 쉬운가?

• 시스템이 코드 모듈과 데이터 엔티티 두 파트로 명확히 분리되어 있기 때문
• 데이터 엔티티를 이해할 때: 그것을 조작하는 코드의 세부사항을 알 필요가 없다
• 코드 모듈을 이해할 때: 조작되는 데이터 엔티티의 세부사항을 알 필요가 없다
• 관심사의 명확한 분리(Clear Separation of Concerns)

OOP 클래스 다이어그램 vs DOP 모듈 다이어그램

• DOP 모듈 다이어그램이 더 단순한 이유: 제약(Constraints) 이 있기 때문
  • 모든 함수는 정적(stateless)
  • 모듈 간 관계는 오직 사용(Usage) 뿐 — 연관도, 합성도, 상속도 없다

참고: DOP에서 다형성(Polymorphism)은 클래스 상속이 아닌 다른 메커니즘으로 구현한다 (13장에서 다룸).

2.5 DOP 시스템은 유연하다

유연성의 근거

• 코드와 데이터가 분리되어 있기 때문에, 요구사항이 바뀌어도 시스템 설계 변경 없이 적응 가능한 경우가 많다

예시: Super Member 요구사항 추가

새 요구사항:

• Super Member: 다른 멤버의 대출 목록 조회 가능
• VIP Member: 도서 아이템 추가 가능

기존 코드:

class Library {
  static getBookLendings(
    libraryData: LibraryData,
    userId: string,
    memberId: string
  ): BookLending[] {
    if (UserManagement.isLibrarian(libraryData.userManagement, userId)) {
      return Catalog.getBookLendings(libraryData.catalog, memberId);
    } else {
      throw new Error("Not allowed to get book lendings");
    }
  }
}

Super Member 지원 추가 후 — 설계 변경 없이 함수 하나만 추가:

class Library {
  static getBookLendings(
    libraryData: LibraryData,
    userId: string,
    memberId: string
  ): BookLending[] {
    const isAllowed =
      UserManagement.isLibrarian(libraryData.userManagement, userId) ||
      UserManagement.isSuperMember(libraryData.userManagement, userId);

    if (isAllowed) {
      return Catalog.getBookLendings(libraryData.catalog, memberId);
    } else {
      throw new Error("Not allowed to get book lendings");
    }
  }
}

class UserManagement {
  static isLibrarian(userManagementData: UserManagementData, userId: string): boolean {
    // 구현 예정
    return false;
  }

  // 새로 추가된 함수 — 기존 설계 변경 없음
  static isSuperMember(userManagementData: UserManagementData, userId: string): boolean {
    // 구현 예정
    return false;
  }
}

VIP Member 지원 추가 — 동일한 패턴 반복:

class Library {
  static addBookItem(
    libraryData: LibraryData,
    userId: string,
    bookItemInfo: BookItemInfo
  ): void {
    const isAllowed =
      UserManagement.isLibrarian(libraryData.userManagement, userId) ||
      UserManagement.isVIPMember(libraryData.userManagement, userId);

    if (isAllowed) {
      Catalog.addBookItem(libraryData.catalog, bookItemInfo);
    } else {
      throw new Error("Not allowed to add a book item");
    }
  }
}

class UserManagement {
  static isLibrarian(userManagementData: UserManagementData, userId: string): boolean {
    return false;
  }

  static isVIPMember(userManagementData: UserManagementData, userId: string): boolean {
    return false;
  }
}

TIP: DOP 시스템은 유연하다. 요구사항 변경에 대해 시스템 설계 변경 없이 적응하는 경우가 많다.

챕터 2 요약

• DOP의 첫 번째 원칙은 코드와 데이터의 분리다
• DOP 원칙은 언어에 종속되지 않는다 (OOP, 함수형 언어 모두 적용 가능)
• DOP는 데이터 캡슐화에 반대한다
• 데이터 엔티티: 정보를 보유하는 시스템의 구성 요소. 코드 없이 멤버(필드)만 존재
• 코드 모듈: 상태 없는(stateless) 함수들의 집합체. 멤버(필드) 없음
• 데이터 엔티티를 발견하려면 요구사항의 명사를, 코드 모듈을 발견하려면 동사구를 찾아라
• 전통적 OOP에서 객체 상태는 메서드의 암묵적 인자. DOP에서는 명시적 인자로 전달
• DOP 모듈 간의 유일한 관계는 사용(Usage) 관계 (연관, 합성, 상속 없음)
• 데이터 엔티티 간의 관계는 연관(Association) 과 합성(Composition) 만 존재
• 고수준 코드 모듈은 고수준 데이터 엔티티에 대응한다
• 코드와 데이터의 분리는 시스템을 이해하기 쉽게 만들고 유연하게 만든다
• 다형성(Polymorphism)은 클래스 상속 없이도 구현 가능 (13장에서 상세 설명)

3. 기본 데이터 조작

DOP에서는 OOP의 경직된 클래스 계층 구조 대신, 데이터를 맵(map)과 배열(array)의 유연한 조합으로 표현한다. 모든 정보는 “정보 경로(information path)“를 통해 접근 가능하며, 이것이 DOP의 두 번째 원칙의 핵심이다.

DOP 원칙 #2

핵심 인사이트: 데이터 엔티티를 범용 자료구조(generic data structures)로 표현하라.

3.1 데이터 모델 설계 (Designing a Data Model)

핵심 개념

• DOP에서 데이터 설계는 코드와 완전히 분리하여 독립적으로 진행한다
• 데이터 간의 관계는 오직 두 가지만 고려한다
  • 연관(Association): 점선 + 빈 다이아몬드, 간접 참조
  • 합성(Composition): 실선 + 채운 다이아몬드, 직접 포함
• 관계의 다중성: 일대일, 일대다, 다대다

데이터 집합의 세 가지 종류

인덱스의 키는 항상 문자열(string)이다.

도서관 관리 시스템 데이터 모델

erDiagram
    Library {
        string name
        string address
    }
    Catalog {
        object booksByIsbn
        object authorsById
    }
    Book {
        string isbn
        string title
        number publicationYear
        array authorIds
    }
    Author {
        string id
        string name
        array bookIsbns
    }
    BookItem {
        string id
        string libId
        string purchaseDate
        boolean isLent
    }
    BookLending {
        string bookItemId
        string bookIsbn
        string lendingDate
    }
    UserManagement {
        object librariansByEmail
        object membersByEmail
    }
    Member {
        string email
        string encryptedPassword
        boolean isBlocked
        array bookLendings
    }
    Librarian {
        string email
        string encryptedPassword
    }
    Library ||--|| Catalog : contains
    Library ||--|| UserManagement : contains
    Catalog ||--o{ Book : booksByIsbn
    Catalog ||--o{ Author : authorsById
    Book ||--o{ BookItem : contains
    Member ||--o{ BookLending : has
    UserManagement ||--o{ Member : membersByEmail
    UserManagement ||--o{ Librarian : librariansByEmail

• Book과 Author의 관계는 다대다 간접 연관: Book은 authorIds(ID 배열)를 가지고, Author는 bookIsbns(ISBN 배열)를 가진다
• 실제 Author 객체는 Catalog의 authorsById 인덱스를 통해 조회한다

3.2 레코드를 맵으로 표현하기 (Representing Records as Maps)

DOP의 데이터 표현 방식

• 동질적 맵(Homogeneous map): 모든 값이 같은 타입 ({[key: string]: Book})
• 이질적 맵(Heterogeneous map): 값이 서로 다른 타입 ({ isbn: string, title: string, publicationYear: number, ... })

핵심 인사이트: DOP에서 레코드는 이질적 문자열 맵으로 표현한다.

OOP 방식 vs DOP 방식 비교

OOP 방식 (클래스 기반)

class BookItem {
  constructor(
    public id: string,
    public libId: string,
    public isLent: boolean
  ) {}
}

class Book {
  constructor(
    public isbn: string,
    public title: string,
    public publicationYear: number,
    public authors: string[],
    public bookItems: BookItem[]
  ) {}
}

const watchmenBook = new Book(
  "978-1779501127",
  "Watchmen",
  1987,
  ["alan-moore", "dave-gibbons"],
  [
    new BookItem("book-item-1", "nyc-central-lib", true),
    new BookItem("book-item-2", "nyc-central-lib", false),
  ]
);

DOP 방식 (맵 기반)

const watchmenBook = {
  isbn: "978-1779501127",
  title: "Watchmen",
  publicationYear: 1987,
  authorIds: ["alan-moore", "dave-gibbons"],
  bookItems: [
    { id: "book-item-1", libId: "nyc-central-lib", isLent: true },
    { id: "book-item-2", libId: "nyc-central-lib", isLent: false },
  ],
};

안전성 vs 유연성 트레이드오프

OOP의 안전성이 가져오는 비용 (예시)

• 검색 결과에 저자 이름을 포함하고 책 아이템 정보를 제외하려면?
• OOP: BookInSearchResults라는 새 클래스와 변환 생성자를 별도로 작성해야 함
• DOP: 런타임에 필드를 자유롭게 추가/삭제/변경 가능, 별도 클래스 불필요

DOP가 제공하는 두 가지 핵심 이점

1. 유연성: 런타임에 레코드 필드를 자유롭게 추가, 삭제, 변경할 수 있다
2. 범용성(JSON 직렬화 무료 제공): 레코드가 맵이므로 JSON.stringify() 한 줄로 직렬화된다. 별도의 직렬화 로직(리플렉션 등) 불필요

DOP는 데이터 안전성을 일부 포기하는 대신, 유연성과 범용성을 얻는다.

3.3 범용 함수로 데이터 조작하기 (Manipulating Data with Generic Functions)

Catalog 레코드 인스턴스

import _ from "lodash";

const catalogData = {
  booksByIsbn: {
    "978-1779501127": {
      isbn: "978-1779501127",
      title: "Watchmen",
      publicationYear: 1987,
      authorIds: ["alan-moore", "dave-gibbons"],
      bookItems: [
        { id: "book-item-1", libId: "nyc-central-lib", isLent: true },
        { id: "book-item-2", libId: "nyc-central-lib", isLent: false },
      ],
    },
  },
  authorsById: {
    "alan-moore": { name: "Alan Moore", bookIsbns: ["978-1779501127"] },
    "dave-gibbons": { name: "Dave Gibbons", bookIsbns: ["978-1779501127"] },
  },
};

정보 경로 (Information Path)

• DOP에서 모든 데이터 조각은 정보 경로(information path)를 통해 접근할 수 있다
• 정보 경로는 파일 시스템 경로와 유사하며, 중첩된 엔티티의 키들로 구성된다
• 정보 경로는 1급 시민(first-class citizen): 변수에 저장하고, 인자로 전달할 수 있다

// Watchmen 책의 제목에 대한 정보 경로
const path = ["booksByIsbn", "978-1779501127", "title"];
_.get(catalogData, path); // → "Watchmen"

// Alan Moore의 첫 번째 책 ISBN에 대한 정보 경로
_.get(catalogData, ["authorsById", "alan-moore", "bookIsbns", 0]);
// → "978-1779501127"

_.get의 직접 구현

function get(m: Record<string, any>, path: (string | number)[]): any {
  let res = m;
  for (const key of path) {
    res = res[key];
  }
  return res;
}

정보 경로 방식의 차별점

• OOP에서는 catalogData.booksByIsbn["978-1779501127"].title처럼 특정 타입에 의존하는 전용 코드가 필요하다
• DOP에서는 경로를 변수로 만들어 범용 함수에 인자로 전달할 수 있다
• 정적 언어(Java 등)에서는 맵의 값 타입이 Map<String, Object>가 되어 꺼낼 때 타입 캐스팅이 필요하지만, 대부분의 경우 데이터를 그냥 전달(pass-around)만 하므로 큰 문제가 되지 않는다

참고: 맵에서 필드를 접근하는 것은 클래스 멤버 접근보다 미세하게 느리지만, 대부분의 경우 유의미한 성능 차이는 없다.

3.4 검색 결과 계산하기 (Calculating Search Results)

목표: 책 제목으로 검색 후 BookInfo 형태로 반환

// 반환 목표 형태
const bookInfo = {
  title: "Watchmen",
  isbn: "978-1779501127",
  authorNames: ["Alan Moore", "Dave Gibbons"],
};

핵심 범용 함수들

_.map 직접 구현

function map<T, R>(coll: T[], f: (item: T) => R): R[] {
  const res: R[] = [];
  for (let i = 0; i < coll.length; i++) {
    res[i] = f(coll[i]);
  }
  return res;
}

_.filter 직접 구현

function filter<T>(coll: T[], f: (item: T) => boolean): T[] {
  const res: T[] = [];
  for (const item of coll) {
    if (f(item)) res.push(item);
  }
  return res;
}

Catalog 모듈 구현

import _ from "lodash";

class Catalog {
  // 책의 authorIds를 author 이름 배열로 변환
  static authorNames(catalogData: Record<string, any>, book: Record<string, any>): string[] {
    const authorIds: string[] = _.get(book, "authorIds");
    return _.map(authorIds, (authorId: string) =>
      _.get(catalogData, ["authorsById", authorId, "name"])
    );
  }

  // Book 레코드 → BookInfo 레코드 변환 (클래스 생성 불필요)
  static bookInfo(catalogData: Record<string, any>, book: Record<string, any>) {
    return {
      title: _.get(book, "title"),
      isbn: _.get(book, "isbn"),
      authorNames: Catalog.authorNames(catalogData, book),
    };
  }

  // 제목 기반 검색: Book 레코드들을 필터링하여 BookInfo 배열 반환
  static searchBooksByTitle(catalogData: Record<string, any>, query: string) {
    const allBooks = _.values(_.get(catalogData, "booksByIsbn"));
    const matchingBooks = _.filter(allBooks, (book) =>
      _.get(book, "title").includes(query)
    );
    return _.map(matchingBooks, (book) => Catalog.bookInfo(catalogData, book));
  }
}

Library 모듈 구현

class Library {
  // JSON 직렬화는 JSON.stringify 한 줄로 끝 (범용성의 핵심)
  static searchBooksByTitleJSON(libraryData: Record<string, any>, query: string): string {
    const catalogData = _.get(libraryData, "catalog");
    const results = Catalog.searchBooksByTitle(catalogData, query);
    return JSON.stringify(results);
  }
}

사용 예시

const libraryData = {
  catalog: catalogData, // 위에서 정의한 catalogData
};

Library.searchBooksByTitleJSON(libraryData, "Wat");
// → '[{"title":"Watchmen","isbn":"978-1779501127","authorNames":["Alan Moore","Dave Gibbons"]}]'

핵심 인사이트

• bookInfo를 위한 별도 클래스를 만들 필요가 없다
• 코드의 대부분은 단순한 데이터 조작(data manipulation) 이며, 불필요한 추상화가 없다
• _.filter에 맵을 전달하면 맵의 값(values) 들을 순회한다

3.5 서로 다른 타입의 레코드 처리하기 (Handling Records of Different Types)

“레코드 타입을 어떻게 구분하는가?”

DOP의 놀라운 답: 대부분의 경우, 레코드 타입을 알 필요가 없다.

• 중요한 것은 필드의 값이다
• 예를 들어 Catalog.authorNames는 Book 레코드를 받지만, 실제로는 authorIds 필드의 값만 관심을 갖는다

타입 구분이 필요한 경우의 두 가지 패턴

패턴 1: 인덱스로 구분 (Librarian vs Member처럼 명확히 구분되는 경우)

import _ from "lodash";

function isLibrarian(userManagement: Record<string, any>, email: string): boolean {
  return _.has(_.get(userManagement, "librariansByEmail"), email);
}

const userManagementData = {
  librariansByEmail: {
    "franck@gmail.com": {
      email: "franck@gmail.com",
      encryptedPassword: "bXlwYXNzd29yZA==",
    },
  },
  membersByEmail: {
    "samantha@gmail.com": {
      email: "samantha@gmail.com",
      encryptedPassword: "c2VjcmV0",
      isBlocked: false,
      bookLendings: [
        {
          bookItemId: "book-item-1",
          bookIsbn: "978-1779501127",
          lendingDate: "2020-04-23",
        },
      ],
    },
  },
};

isLibrarian(userManagementData, "franck@gmail.com"); // → true

패턴 2: 피처 필드(Feature Field)로 구분 (한 레코드가 여러 타입 특성을 가질 수 있는 경우)

// isVIP, isSuper 같은 boolean 피처 필드로 타입 특성을 표현
function isVIPMember(userManagement: Record<string, any>, email: string): boolean {
  return _.get(userManagement, ["membersByEmail", email, "isVIP"]) === true;
}

function isSuperMember(userManagement: Record<string, any>, email: string): boolean {
  return _.get(userManagement, ["membersByEmail", email, "isSuper"]) === true;
}

두 패턴의 선택 기준

• 인덱스로 구분: 레코드 간 데이터 구조가 명확히 다를 때 (Librarian은 bookLendings 없음)
• 피처 필드로 구분: 한 레코드가 동시에 여러 특성을 가질 수 있을 때 (VIP이면서 동시에 Super일 수 있음)

types: ["VIP", "Super"]처럼 타입 컬렉션을 유지하는 것보다, 각 기능마다 isVIP, isSuper 같은 boolean 피처 필드를 두는 것이 더 단순하다.

최종 UserManagement 모듈

class UserManagement {
  static isLibrarian(userManagement: Record<string, any>, email: string): boolean {
    return _.has(_.get(userManagement, "librariansByEmail"), email);
  }

  static isVIPMember(userManagement: Record<string, any>, email: string): boolean {
    return _.get(userManagement, ["membersByEmail", email, "isVIP"]) === true;
  }

  static isSuperMember(userManagement: Record<string, any>, email: string): boolean {
    return _.get(userManagement, ["membersByEmail", email, "isSuper"]) === true;
  }
}

챕터 3 요약

DOP 원칙 #2 핵심 정리

• 레코드는 이질적 문자열 맵으로 표현한다
• 컬렉션은 배열, 인덱스는 동질적 문자열 맵으로 표현한다
• 데이터 조작은 _.get, _.map, _.filter 등의 범용 함수로 수행한다
• JSON 직렬화는 JSON.stringify 한 줄로 무료 제공된다
• 모든 정보는 정보 경로(information path) 를 통해 접근할 수 있다
• 레코드 타입 정보는 대부분 불필요하며, 필요시 피처 필드로 표현한다
• 데이터와 코드의 약한 의존성 덕분에 요구사항 변경에 유연하게 대응할 수 있다

이 챕터에서 사용된 Lodash 함수 정리

4. 상태 관리

DOP Principle #3: Data is immutable.

핵심 개념 요약

• DOP에서 뮤테이션(mutation) 이란 시스템의 상태를 변경하는 연산이다.
• 상태 관리의 핵심은 데이터를 직접 변경하지 않고, 다중 버전(multi-version) 으로 관리하는 것이다.
• 뮤테이션은 두 단계로 분리된다.

4.1 다중 버전 시스템 데이터 (Multiple Versions of the System Data)

핵심 아이디어

• Git의 커밋 히스토리처럼, 시스템 데이터를 여러 버전으로 유지한다.
• 특정 시점의 시스템 상태는 특정 버전의 시스템 데이터를 참조(reference) 한다.
• 뮤테이션 실행 후, 참조를 다음 버전으로 이동시킨다.

핵심 구분

핵심 인사이트: 데이터는 불변(immutable)이지만, 상태 참조는 가변(mutable)이다.

[Mutation A] --> Data V10 [Mutation B] --> Data V11  <-- System State (before C) [Mutation C] --> Data V12  <-- System State (after C)

이점

• 이전 버전의 데이터는 가비지 컬렉터에 의해 자동 수거되거나
• 의도적으로 히스토리 참조를 유지하면 Git처럼 이전 상태로 복원 가능

4.2 구조적 공유 (Structural Sharing)

핵심 아이디어

• 새로운 버전의 데이터를 만들 때, 변경된 부분만 새로 생성하고 나머지는 공유한다.
• 깊은 복사(deep copy) 없이 효율적으로 새 버전 생성이 가능하다.

핵심 인사이트: 구조적 공유는 두 버전 간에 공통된 부분을 재귀적으로 공유함으로써 메모리와 연산 측면에서 효율적으로 새 버전의 데이터를 생성한다.

동작 원리 시각화

Watchmen의 publicationYear를 1987 -> 1986으로 변경하는 경우:

flowchart TD
    subgraph "Next Library"
        NL[Library] --> NUP[UserManagement - 공유]
        NL --> NC[Catalog - 새로 생성]
        NC --> NAB[authorsById - 공유]
        NC --> NBI[booksByIsbn - 새로 생성]
        NBI --> NW[Watchmen - 새로 생성]
        NW --> NY[publicationYear: 1986 - 새로 생성]
    end

    subgraph "Current Library"
        CL[Library] --> CUP[UserManagement]
        CL --> CC[Catalog]
        CC --> CAB[authorsById]
        CC --> CBI[booksByIsbn]
        CBI --> CW[Watchmen]
        CW --> CY[publicationYear: 1987]
    end

• UserManagement : 변경 없음 -> 공유
• authorsById : 변경 없음 -> 공유
• Library, Catalog, booksByIsbn, Watchmen, publicationYear : 새로 생성

Lodash FP 모듈을 이용한 불변 함수 사용

기본 Lodash의 _.set은 원본을 직접 변경(mutate)하므로, Lodash FP 모듈로 불변 버전을 사용해야 한다.

import * as fp from 'lodash/fp';
import _ from 'lodash';

// Lodash를 불변 모드로 설정 (시그니처는 기존 Lodash와 동일하게 유지)
const immutable_ = fp.convert({
  cap: false,
  curry: false,
  fixed: false,
  immutable: true,
  rearg: false,
});

// publicationYear를 1986으로 변경한 새로운 libraryData 반환 (원본 불변)
const nextLibraryData = immutable_.set(
  libraryData,
  ['catalog', 'booksByIsbn', '978-1779501127', 'publicationYear'],
  1986
);

불변 함수(immutable function) 란, 데이터를 직접 변경하는 대신 변경된 새 버전의 데이터를 반환하는 함수이다.

멤버 추가 뮤테이션 코드 예시

// UserManagement 레이어: 멤버 추가
function addMember(userManagement: object, member: object): object {
  const email = immutable_.get(member, 'email') as string;
  const infoPath = ['membersByEmail', email];

  if (immutable_.has(userManagement, infoPath)) {
    throw new Error('Member already exists.');
  }

  // 멤버가 추가된 새로운 버전의 userManagement 반환
  return immutable_.set(userManagement, infoPath, member);
}

// Library 레이어: UserManagement에 위임
function addMemberToLibrary(library: object, member: object): object {
  const currentUserManagement = immutable_.get(library, 'userManagement') as object;
  const nextUserManagement = addMember(currentUserManagement, member);

  // userManagement가 갱신된 새로운 버전의 library 반환
  return immutable_.set(library, 'userManagement', nextUserManagement);
}

• 모든 함수는 정적(static) 이며, 조작할 데이터를 인자로 받는다.
• 함수는 상태를 변경하지 않고 새 버전의 데이터를 반환한다.

4.3 구조적 공유 구현 (Implementing Structural Sharing)

구조적 공유의 핵심 구현은 단 11줄의 코드로 표현 가능하다.

function setImmutable(
  map: Record<string, unknown>,
  path: string[],
  value: unknown
): Record<string, unknown> {
  let modifiedNode: unknown = value;
  const k = path[0];
  const restOfPath = path.slice(1);

  if (restOfPath.length > 0) {
    modifiedNode = setImmutable(
      map[k] as Record<string, unknown>,
      restOfPath,
      value
    );
  }

  // 현재 레벨의 맵을 얕은 복사(shallow clone)하고 해당 키만 교체
  const result = Object.assign({}, map);
  result[k] = modifiedNode;
  return result;
}

동작 핵심

• Object.assign({}, map) 으로 현재 레벨만 얕은 복사
• 변경 경로 상의 노드만 새로 생성하고, 나머지는 참조 공유
• 재귀적으로 경로를 따라 내려가며 처리

4.4 데이터 안전성 (Data Safety)

공유 데이터 변조 위험

구조적 공유로 두 버전이 동일한 참조를 공유하고 있을 때, 네이티브 setter로 직접 변경하면 양쪽 버전 모두 영향을 받는다.

const books = {
  '978-1779501127': {
    isbn: '978-1779501127',
    title: 'Watchmen',
    publicationYear: 1987,
    authorIds: ['alan-moore', 'dave-gibbons'],
  },
};

const nextBooks = immutable_.set(books, ['978-1779501127', 'publicationYear'], 1986);

console.log('Before:', nextBooks['978-1779501127']['authorIds'][1]); // dave-gibbons

// 네이티브 setter로 직접 변경 -> 공유 참조이므로 양쪽 모두 오염
books['978-1779501127']['authorIds'][1] = 'dave-chester-gibbons';

console.log('After:', nextBooks['978-1779501127']['authorIds'][1]); // dave-chester-gibbons

핵심 인사이트: 모든 데이터 조작은 불변 함수를 통해서만 해야 한다. 네이티브 hash map setter 사용은 금지된다.

해결책: 영속적 자료구조 (Persistent Data Structures)

주요 라이브러리 목록:

• JavaScript: Immutable.js
• Java: Paguro
• C#: Immutable Collections
• Python: Pyrsistent
• Ruby: Hamster

4.5 뮤테이션의 커밋 단계 (The Commit Phase of a Mutation)

계산 단계와 커밋 단계의 분리

• 계산 단계(Library.addMember 등)는 새 버전의 데이터를 반환할 뿐, 시스템 상태를 직접 변경하지 않는다.
• 상태 변경은 오직 커밋 단계(commit phase) 에서만 이루어진다.

[커밋 전] System State -> State(member 1명)
[커밋 후] System State -> State(member 2명)

구현 구조

두 개의 싱글톤 클래스로 구성된다:

• System: 각 뮤테이션을 구현하는 클래스
• SystemState: 시스템 상태(데이터 참조)를 관리하는 클래스

// 시스템 상태를 관리하는 싱글톤 클래스 (Stateful)
class SystemState {
  private systemData: object = {};

  get(): object {
    return this.systemData;
  }

  commit(previous: object, next: object): void {
    this.systemData = next;
  }
}

const systemState = new SystemState();

// 뮤테이션을 구현하는 싱글톤 클래스
class System {
  addMember(member: object): void {
    const previous = systemState.get();
    // 계산 단계: 새 버전의 데이터 계산 (Stateless)
    const next = addMemberToLibrary(previous, member);
    // 커밋 단계: 시스템 상태를 다음 버전으로 전진 (Stateful)
    systemState.commit(previous, next);
  }
}

핵심 인사이트: 계산 단계는 Stateless다. 커밋 단계는 Stateful이다.

4.6 시스템 상태 무결성 보장 (Ensuring System State Integrity)

OOP 방식의 한계

• OOP에서는 데이터를 소유한 클래스의 메서드만이 데이터를 조작하여 무결성을 보호한다.
• 하지만 이 경우 검증 로직이 여러 클래스에 분산된다.

DOP 방식의 장점

• 커밋 단계의 코드가 모든 뮤테이션에 공통으로 사용되므로, 데이터 검증을 중앙화할 수 있다.
• 커밋 직전에 새 버전의 데이터가 유효한지 검증하고, 유효하지 않으면 커밋을 거부한다.

class SystemState {
  private systemData: object = {};

  get(): object {
    return this.systemData;
  }

  commit(previous: object, next: object): void {
    // 커밋 전 전체 시스템 데이터 유효성 검증 (Git의 커밋 훅과 유사)
    if (!SystemValidity.validate(previous, next)) {
      throw new Error('The system data to be committed is not valid!');
    }
    this.systemData = next;
  }
}

• previous와 next 를 모두 전달하는 이유: 변경된 부분만 선택적으로 검증하여 연산 효율 최적화 가능

핵심 인사이트: DOP에서는 시스템 데이터를 전체로서 검증한다. 데이터 검증은 데이터 조작과 분리된다.

4.7 이전 상태 복원 (Restoring Previous States)

구조적 공유와 메모리 효율

• 구조적 공유 덕분에 여러 버전의 시스템 상태를 유지해도 메모리가 폭발하지 않는다.
• 대부분의 데이터가 버전 간에 공유되기 때문이다.

핵심 인사이트: 구조적 공유 덕분에 메모리를 폭발시키지 않고 시스템 상태의 많은 버전을 유지할 수 있다.

단일 Undo 구현

SystemState에 previousSystemData 참조를 추가하여 한 단계 전으로 복원한다.

stateDiagram-v2
  direction LR

  state "V12 (현재)" as V12
  state "V13 (다음)" as V13
  state "V12 (Undo 후)" as UNDO

  V12 --> V13 : commit (addMember)

  note right of V12
      systemData: V12
      prevSystemData: V11
  end note

  note right of V13
      systemData: V13
      prevSystemData: V12
  end note

  V13 --> UNDO : undoLastMutation()

  note right of UNDO
      systemData: V12
      prevSystemData: V12
  end note

classDiagram
class SystemState {
    -object systemData
    -object previousSystemData
    +get() object
    +commit(previous, next) void
    +undoLastMutation() void
}

• 여러 단계의 Undo가 필요하다면 단순 참조 2개가 아닌 버전 참조 스택(stack) 으로 확장하면 된다.

챕터 4 요약

DOP 상태 관리 원칙

• 데이터는 불변, 하지만 상태 참조는 가변
• 모든 데이터 조작은 불변 함수 를 통해서만 수행
• 네이티브 setter 직접 사용 금지

뮤테이션의 2단계 구조

flowchart LR
    A[뮤테이션 호출] --> B{계산 단계\nStateless}
    B --> |새 버전의 데이터 반환| C{커밋 단계\nStateful}
    C --> |유효성 검증 통과| D[시스템 상태 전진]
    C --> |유효성 검증 실패| E[커밋 거부 / 예외]

구조적 공유의 핵심 가치

무결성 보장의 중앙화

• 커밋 단계가 모든 뮤테이션에 공통이므로 검증 로직을 한 곳에 집중 가능
• Git의 커밋 훅(commit hook)과 유사한 역할
• previous와 next 모두 전달하여 변경분만 선택 검증하는 최적화 가능

이 챕터에서 사용된 Lodash 함수

5. 기본 동시성 제어

핵심 요약: DOP에서 동시성 제어는 락(lock) 없이 낙관적 동시성 제어(Optimistic Concurrency Control) 전략으로 처리한다. 상태가 불변(immutable) 해시맵으로 표현되기 때문에 이 전략이 효율적으로 작동한다.

5.1 Optimistic Concurrency Control

개념

• 낙관적 동시성 제어(OCC) 란 “허락을 구하는 대신 용서를 구한다”는 전략이다.
• 뮤테이션(mutation)은 마치 자신이 유일하게 실행 중인 것처럼 계산을 수행하고, 커밋 단계에서 충돌을 해소한다.
• 락(lock) 기반 전략과 달리 데드락 위험이 없고 읽기/쓰기 처리량(throughput)이 높다.
• Elasticsearch 같은 고확장성 데이터베이스가 이 전략을 사용한다.

뮤테이션의 두 단계

핵심 포인트

• 계산 단계의 코드는 변경이 없다. 동시성 처리를 위한 코드 변경은 오직 커밋 단계에만 집중된다.
• 커밋 단계의 조정(reconciliation) 로직 구현은 범용적이다. 시스템 데이터가 불변 해시맵으로 표현된다면 어떤 DOP 시스템에서도 동일한 코드를 재사용할 수 있다.

OCC 로직 흐름

flowchart TD
    A[계산 단계: 현재 상태 캡처] --> B[다음 버전 계산]
    B --> C{동시 뮤테이션 발생?}
    C -- No --> D[상태 업데이트: Fast-forward]
    C -- Yes --> E{충돌 여부 확인}
    E -- No --> F[상태 업데이트: 3-way Merge]
    E -- Yes --> G[뮤테이션 중단: Abort]

5.2 Reconciliation between Concurrent Mutations

세 가지 버전의 상태

커밋 단계가 시작될 때, 세 가지 버전의 시스템 상태가 존재한다.

• current !== previous 인 경우 = 다른 뮤테이션이 동시에 실행되었음을 의미한다.

조정(Reconciliation) 세 가지 시나리오

Git의 브랜치 머지와 개념적으로 동일하다.

DOP와 Git의 비유

실사용 시스템에서 충돌하는 동시 뮤테이션은 매우 드물다. 따라서 Abort 후 재시도를 요청하는 방식은 실용적으로 충분히 수용 가능하다.

5.3 Reducing Collections

diff 알고리즘 구현의 핵심 도구인 reduce를 이해하는 단계다.

reduce 개념

• 컬렉션의 모든 요소를 순회하며 누적값(accumulator)을 만들어 최종 단일 값을 반환한다.
• reduce(collection, f, initVal) 형태로 동작한다.

TypeScript 직접 구현

function reduce<T, R>(
  coll: T[],
  f: (acc: R, elem: T) => R,
  initVal: R
): R {
  let currentRes = initVal;
  for (let i = 0; i < coll.length; i++) {
    currentRes = f(currentRes, coll[i]);
  }
  return currentRes;
}

// 사용 예시: 배열 합산
reduce([1, 2, 3], (res, elem) => res + elem, 0);
// → 6

로직 전개 시각화

initVal → f(initVal, a[0]) → f(결과1, a[1]) → f(결과2, a[2]) → 최종값

5.4 Structural Difference

이 섹션은 diff 알고리즘의 구체적인 구현을 다룬다. 재귀(recursion) 안에 reduce가 포함되는 비자명한(non-trivial) 코드이므로 집중이 필요하다.

구조적 diff(Structural Diff)란?

• 두 해시맵 간의 구조적 차이를 계산한다.
• 필드 순서를 무시하고 구조를 기준으로 비교한다.

diff의 종류 (중첩 필드 없는 맵)

diff의 종류 (중첩 필드 있는 맵)

diff의 종류 (배열)

• 배열은 인덱스 순서 기준으로 비교한다.
• 동일하면 null, 다르면 두 번째 배열의 값을 반환한다.

구조적 diff 알고리즘 구현 (TypeScript)

import _ from "lodash";

function diffObjects(
  data1: Record<string, unknown> | unknown[],
  data2: Record<string, unknown> | unknown[]
): Record<string, unknown> | unknown[] {
  const emptyObject = _.isArray(data1) ? [] : {};

  // 두 값이 동일한 참조면 즉시 빈 객체 반환 (구조적 공유 덕분에 효율적)
  if (data1 === data2) {
    return emptyObject;
  }

  const keys = _.union(_.keys(data1), _.keys(data2));

  return _.reduce(
    keys,
    (acc: Record<string, unknown>, k: string) => {
      const res = diff(_.get(data1, k), _.get(data2, k));

      // 차이가 없으면 누적값에 추가하지 않음
      if ((_.isObject(res) && _.isEmpty(res)) || res === "no-diff") {
        return acc;
      }
      return _.set(acc, [k], res);
    },
    emptyObject as Record<string, unknown>
  );
}

function diff(data1: unknown, data2: unknown): unknown {
  // 둘 다 객체(맵 또는 배열)이면 재귀적으로 구조 비교
  if (_.isObject(data1) && _.isObject(data2)) {
    return diffObjects(
      data1 as Record<string, unknown>,
      data2 as Record<string, unknown>
    );
  }
  // 값이 다르면 두 번째 값 반환
  if (data1 !== data2) {
    return data2;
  }
  // 값이 같으면 특수 마커 반환
  return "no-diff";
}

핵심 구현 포인트:

• diffObjects 내부에서 reduce 안에 diff를 재귀 호출한다.
• "no-diff" 는 두 값이 동일함을 나타내는 마커 문자열이다.
• _.isArray 로 배열인지 맵인지 판별해 빈 초기값([] vs {})을 결정한다.

구조적 공유(Structural Sharing)와 성능

• 불변 데이터에서 새 버전은 이전 버전과 대부분의 노드를 공유(structural sharing) 한다.
• diffObjects 진입 시 data1 === data2 이면 즉시 반환되므로, 실질적으로 변경된 경로만 탐색한다.
• 결론: 두 상태 버전의 diff 계산은 전체 트리를 순회하지 않고 매우 효율적으로 처리된다.

Information Path 추출

충돌 감지를 위해 중첩 맵의 모든 리프 노드 경로(information path)를 추출해야 한다.

function informationPaths(
  obj: Record<string, unknown>,
  path: string[] = []
): string[][] {
  return _.reduce(
    obj,
    (acc: string[][], v: unknown, k: string) => {
      if (_.isObject(v)) {
        return _.concat(
          acc,
          informationPaths(v as Record<string, unknown>, _.concat(path, k))
        );
      }
      return _.concat(acc, [_.concat(path, k)]);
    },
    []
  );
}

두 diff 간 충돌 감지

function havePathInCommon(
  diff1: Record<string, unknown>,
  diff2: Record<string, unknown>
): boolean {
  return !_.isEmpty(
    _.intersection(informationPaths(diff1), informationPaths(diff2))
  );
}

• informationPaths(diff1)과 informationPaths(diff2)의 교집합이 비어있으면 충돌 없음.
• 교집합이 존재하면 같은 필드를 수정하는 충돌 상태.

패치(Patch) 적용

비충돌 상태에서 previous → next의 변경사항을 current에 적용하는 방법:

// current에 diff(previous, next)를 재귀 병합
_.merge(current, diff(previous, next));

5.5 Implementing the Reconciliation Algorithm

SystemState 클래스

커밋 단계만 변경되며, SystemConsistency.reconcile에 조정 로직을 위임한다.

class SystemState {
  private systemData: Record<string, unknown>;

  get(): Record<string, unknown> {
    return this.systemData;
  }

  set(_systemData: Record<string, unknown>): void {
    this.systemData = _systemData;
  }

  commit(
    previous: Record<string, unknown>,
    next: Record<string, unknown>
  ): void {
    const nextSystemData = SystemConsistency.reconcile(
      this.systemData,
      previous,
      next
    );

    if (!SystemValidity.validate(previous, nextSystemData)) {
      throw new Error("The system data to be committed is not valid!");
    }

    this.systemData = nextSystemData;
  }
}

SystemConsistency 클래스 (핵심)

class SystemConsistency {
  static threeWayMerge(
    current: Record<string, unknown>,
    previous: Record<string, unknown>,
    next: Record<string, unknown>
  ): Record<string, unknown> {
    const previousToCurrent = diff(previous, current);
    const previousToNext = diff(previous, next);

    // 두 diff의 information path에 공통 경로가 없으면 안전하게 병합 가능
    if (!havePathInCommon(previousToCurrent, previousToNext)) {
      return _.merge(current, previousToNext) as Record<string, unknown>;
    }

    throw new Error("Conflicting concurrent mutations.");
  }

  static reconcile(
    current: Record<string, unknown>,
    previous: Record<string, unknown>,
    next: Record<string, unknown>
  ): Record<string, unknown> {
    // 참조 비교: 불변 데이터이므로 참조가 같으면 값도 반드시 같다
    if (current === previous) {
      return next; // Fast-forward
    }

    return SystemConsistency.threeWayMerge(current, previous, next);
  }
}

참조 비교(Reference Equality)의 중요성

불변 데이터에서는 참조 비교가 안전하다. 참조가 같으면 값도 반드시 동일하다.

• current === previous 를 값 비교(deep equal) 로 처리하면 중첩 해시맵 전체를 순회해야 하므로 비용이 크다.
• 불변 데이터에서는 참조 비교(===) 가 O(1)로 동일한 보장을 제공한다.

스레드 안전성 주의

• 위 SystemConsistency 구현은 단일 스레드(JavaScript 이벤트 루프) 환경에서는 정상 동작한다.
• 멀티스레드 환경에서는 reconcile 의 상태 확인과 systemData 갱신 사이에 컨텍스트 스위칭이 발생할 수 있어 스레드 안전하지 않다.
• 멀티스레드 환경에서의 스레드 안전 구현은 Chapter 8에서 다룬다.

챕터 5 요약

• OCC는 락 없이 동작 하여 높은 읽기/쓰기 처리량을 지원한다.
• 불변 데이터 + OCC = 초고효율. 구조적 공유 덕분에 diff 계산과 참조 비교 모두 빠르다.
• 계산 단계는 변경 없음. 동시성 처리 로직은 커밋 단계에만 집중된다.
• 조정 알고리즘은 Git의 머지 전략과 동일한 개념 (Fast-forward / Three-way merge / Abort)이다.
• 커밋 단계의 조정 코드는 범용적 이어서 어느 DOP 시스템에서도 재사용 가능하다.
• 실사용 시스템에서 충돌하는 동시 뮤테이션은 매우 드물기 때문에 Abort 전략은 실용적으로 충분하다.
• 구조적 diff 알고리즘은 대체(Replacement)와 추가(Addition)를 지원하며, 삭제(Deletion)는 미지원 이다.

6. 단위 테스트

데이터 지향 시스템에서 코드는 대부분 데이터 조작을 다룬다. 따라서 함수의 입력과 출력이 모두 데이터이고, 이는 단위 테스트를 매우 단순하게 만든다.

이 챕터가 다루는 것

• 테스트 케이스를 위한 최소 데이터 입력 생성 방법
• 함수 출력과 기대 출력의 비교 방법
• 테스트 케이스의 품질과 수량에 대한 가이드

6.1 데이터 지향 테스트 케이스의 단순함

핵심 원칙

• DOP(Data-Oriented Programming) 시스템의 코드는 대부분 데이터 조작을 다룬다
• 데이터를 다루는 함수의 테스트 케이스는 데이터 입력 생성 + 기대 출력 생성 + 비교가 전부다
• DOP에서는 대부분의 경우 Mock 함수가 필요 없다

테스트 케이스의 3단계 패턴

1. 데이터 입력(dataIn) 생성
2. 기대 출력(dataOut) 생성
3. f(dataIn)의 결과와 dataOut 비교

데이터 컬렉션 비교: _.isEqual (Lodash)

• 원시 값(string, number)은 ===로 비교 가능
• 맵(객체), 배열 같은 데이터 컬렉션은 재귀적 비교가 필요
• Lodash의 _.isEqual을 사용하면 재귀적 값 비교를 간단히 처리할 수 있다

import _ from "lodash";

// 같은 데이터 → true
_.isEqual(
  { name: "Alan Moore", bookIsbns: ["978-1779501127"] },
  { name: "Alan Moore", bookIsbns: ["978-1779501127"] }
);
// → true

// 다른 데이터 → false
_.isEqual(
  { name: "Alan Moore", bookIsbns: ["978-1779501127"] },
  { name: "Alan Moore", bookIsbns: ["bad-isbn"] }
);
// → false

테스트 케이스의 일반적인 패턴

const dataIn = {
  // 입력 데이터
};

const dataOut = {
  // 기대 출력 데이터
};

_.isEqual(f(dataIn), dataOut); // true이면 테스트 통과

핵심 인사이트: 데이터 조작 코드에 대한 단위 테스트를 작성하는 것은 매우 단순하다.

6.2 데이터 조작 코드에 대한 단위 테스트

예제 시스템: 도서관 검색 쿼리

class Catalog {
  static authorNames(catalogData: object, authorIds: string[]): string[] {
    return _.map(authorIds, (authorId) =>
      _.get(catalogData, ["authorsById", authorId, "name"])
    );
  }

  static bookInfo(catalogData: object, book: object): object {
    return {
      title: _.get(book, "title"),
      isbn: _.get(book, "isbn"),
      authorNames: Catalog.authorNames(catalogData, _.get(book, "authorIds")),
    };
  }

  static searchBooksByTitle(catalogData: object, query: string): object[] {
    const allBooks = _.get(catalogData, "booksByIsbn");
    const matchingBooks = _.filter(allBooks, (book) =>
      _.get(book, "title").includes(query)
    );
    return _.map(matchingBooks, (book) => Catalog.bookInfo(catalogData, book));
  }
}

class Library {
  static searchBooksByTitleJSON(libraryData: object, query: string): string {
    const catalogData = _.get(libraryData, "catalog");
    const results = Catalog.searchBooksByTitle(catalogData, query);
    return JSON.stringify(results);
  }
}

6.2.1 함수 호출 트리 (Tree of Function Calls)

개념

• 단위 테스트를 작성하기 전에 함수 호출 트리를 시각화하면 테스트의 품질과 수량을 결정하는 데 도움이 된다
• 루트: 테스트 대상 함수
• 자식 노드: 해당 함수가 호출하는 함수들
• 리프 노드: 애플리케이션 코드베이스에 속하지 않는 함수 (예: Lodash의 _.get, _.map 등)

Library.searchBooksByTitleJSON의 함수 호출 트리

flowchart TD
  A["Library.searchBooksByTitleJSON"]
  A --> B["_.get"]
  A --> C["JSON.stringify"]
  A --> D["Catalog.searchBooksByTitle"]
  D --> E["_.get"]
  D --> F["_.map"]
  D --> G["_.filter"]
  D --> H["Catalog.bookInfo"]
  H --> I["_.get"]
  H --> J["Catalog.authorNames"]
  J --> K["_.get"]
  J --> L["_.map"]

함수 호출 트리가 주는 인사이트

핵심 인사이트: 트리의 아래쪽 함수일수록 더 많은 테스트 케이스가 필요하지만, 데이터는 더 단순하다.

6.2.2 트리 하위 함수의 단위 테스트

최소 데이터(Minimal Data)를 사용하라

• 테스트에서 실제 전체 데이터를 사용할 필요는 없다
• 데이터의 유효성은 컨텍스트에 따라 달라진다
• 해당 함수가 접근하는 필드만 포함한 최소 데이터를 사용하면 조작이 훨씬 쉬워진다

// 전체 catalogData (불필요하게 크다)
const fullCatalogData = {
  booksByIsbn: { /* ... */ },
  authorsById: {
    "alan-moore": { name: "Alan Moore", bookIsbns: ["978-1779501127"] },
    "dave-gibbons": { name: "Dave Gibbons", bookIsbns: ["978-1779501127"] },
  },
};

// Catalog.authorNames에 필요한 최소 catalogData
const minimalCatalogData = {
  authorsById: {
    "alan-moore": { name: "Alan Moore" },
    "dave-gibbons": { name: "Dave Gibbons" },
  },
};

핵심 인사이트: 데이터가 작을수록 조작하기 쉽다.

Catalog.authorNames 테스트 케이스

const catalogData = {
  authorsById: {
    "alan-moore": { name: "Alan Moore" },
    "dave-gibbons": { name: "Dave Gibbons" },
  },
};

// 빈 배열
_.isEqual(Catalog.authorNames(catalogData, []), []);
// → true

// 단일 저자 ID
_.isEqual(Catalog.authorNames(catalogData, ["alan-moore"]), ["Alan Moore"]);
// → true

// 복수 저자 ID
_.isEqual(
  Catalog.authorNames(catalogData, ["alan-moore", "dave-gibbons"]),
  ["Alan Moore", "Dave Gibbons"]
);
// → true

// 존재하지 않는 ID → undefined 반환
_.isEqual(Catalog.authorNames({}, ["alan-moore"]), [undefined]);
// → true

_.isEqual(
  Catalog.authorNames(catalogData, ["alan-moore", "albert-einstein"]),
  ["Alan Moore", undefined]
);
// → true

• 리프에 가까운 함수일수록 테스트 케이스의 데이터는 단순하지만 케이스 수는 많아진다
• 다양한 엣지 케이스(빈 배열, 존재하지 않는 ID, 빈 catalogData 등)를 모두 커버해야 한다

6.2.3 트리 상위 노드의 단위 테스트

Catalog.bookInfo 테스트 케이스

• 이미 Catalog.authorNames에 대한 단위 테스트가 작성되어 있으므로, 하위 함수들이 올바르게 동작한다고 가정한다
• 따라서 최소한의 테스트 케이스만 작성하면 된다

const catalogData = {
  authorsById: {
    "alan-moore": { name: "Alan Moore" },
    "dave-gibbons": { name: "Dave Gibbons" },
  },
};

const book = {
  isbn: "978-1779501127",
  title: "Watchmen",
  publicationYear: 1987,
  authorIds: ["alan-moore", "dave-gibbons"],
};

const expectedResult = {
  authorNames: ["Alan Moore", "Dave Gibbons"],
  isbn: "978-1779501127",
  title: "Watchmen",
};

_.isEqual(Catalog.bookInfo(catalogData, book), expectedResult);
// → true

핵심 인사이트: 함수에 대한 단위 테스트를 작성할 때, 해당 함수가 호출하는 하위 함수들은 이미 단위 테스트로 검증되었다고 가정한다. 이는 테스트 케이스의 수를 크게 줄여준다.

6.3 쿼리(Query)에 대한 단위 테스트

Library.searchBooksByTitleJSON 테스트 시 주의점

이 함수는 결과를 JSON 문자열로 반환한다. 문자열 비교는 위험하다.

// 두 문자열은 다르지만, 직렬화하는 데이터는 동일하다!
const stringA = '{"title":"Watchmen","publicationYear":1987}';
const stringB = '{"publicationYear":1987,"title":"Watchmen"}';

stringA === stringB; // → false (잘못된 비교!)
_.isEqual(JSON.parse(stringA), JSON.parse(stringB)); // → true (올바른 비교!)

핵심 인사이트: 데이터를 다루는 함수의 단위 테스트에서 문자열 비교는 피하라. JSON 문자열을 반환하는 경우 JSON.parse로 역직렬화한 후 데이터로 비교하라.

Library.searchBooksByTitleJSON 테스트 케이스

const libraryData = {
  catalog: {
    booksByIsbn: {
      "978-1779501127": {
        isbn: "978-1779501127",
        title: "Watchmen",
        publicationYear: 1987,
        authorIds: ["alan-moore", "dave-gibbons"],
      },
    },
    authorsById: {
      "alan-moore": { name: "Alan Moore", bookIsbns: ["978-1779501127"] },
      "dave-gibbons": { name: "Dave Gibbons", bookIsbns: ["978-1779501127"] },
    },
  },
};

const bookInfo = {
  isbn: "978-1779501127",
  title: "Watchmen",
  authorNames: ["Alan Moore", "Dave Gibbons"],
};

// 매칭되는 쿼리
_.isEqual(
  JSON.parse(Library.searchBooksByTitleJSON(libraryData, "Watchmen")),
  [bookInfo]
);
// → true

// 매칭되지 않는 쿼리
_.isEqual(
  JSON.parse(Library.searchBooksByTitleJSON(libraryData, "Batman")),
  []
);
// → true

Catalog.searchBooksByTitle 테스트 케이스 + 버그 발견

• 이 함수는 JSON 문자열 대신 데이터를 직접 반환하므로, JSON.parse 불필요
• libraryData로 감쌀 필요 없이 catalogData만 사용 가능

// 소문자 쿼리 테스트 → 버그 발견!
_.isEqual(
  Catalog.searchBooksByTitle(catalogData, "watchmen"),
  [bookInfo]
);
// → false (버그!)

버그 수정: 대소문자 무시(Case-insensitive) 검색

static searchBooksByTitle(catalogData: object, query: string): object[] {
  const allBooks = _.get(catalogData, "booksByIsbn");
  const queryLowerCased = query.toLowerCase(); // 쿼리를 소문자로
  const matchingBooks = _.filter(allBooks, (book) =>
    _.get(book, "title").toLowerCase().includes(queryLowerCased) // 타이틀도 소문자로
  );
  return _.map(matchingBooks, (book) => Catalog.bookInfo(catalogData, book));
}

단위 테스트의 목적은 버그를 발견하는 것이다. 소문자 쿼리 테스트 케이스가 실제 버그를 찾아냈다.

6.4 뮤테이션(Mutation)에 대한 단위 테스트

쿼리 vs 뮤테이션 테스트의 차이

쿼리(Query):
  입력: 시스템 데이터 + 인자
  출력: 응답 데이터

뮤테이션(Mutation):
  입력: 현재 시스템 상태 + 인자
  출력: 다음 시스템 상태

핵심 인사이트: 뮤테이션의 주요 함수에 대한 단위 테스트 작성은 쿼리보다 더 많은 노력이 필요하다. 입력과 기대 출력 모두 시스템 상태를 나타내는 맵이기 때문이다.

예제 시스템: 회원 추가 뮤테이션

class System {
  static addMember(systemState: SystemState, member: object): void {
    const previous = systemState.get();
    const next = Library.addMember(previous, member);
    systemState.commit(previous, next);
  }
}

class Library {
  static addMember(library: object, member: object): object {
    const currentUserManagement = _.get(library, "userManagement");
    const nextUserManagement = UserManagement.addMember(
      currentUserManagement,
      member
    );
    return _.set(library, "userManagement", nextUserManagement);
  }
}

class UserManagement {
  static addMember(userManagement: object, member: object): object {
    const email = _.get(member, "email");
    const infoPath = ["membersByEmail", email];
    if (_.has(userManagement, infoPath)) {
      throw "Member already exists.";
    }
    return _.set(userManagement, infoPath, member);
  }
}

System.addMember의 함수 호출 트리

flowchart TD
  A["System.addMember"]
  A --> B["SystemState.get"]
  A --> C["SystemState.commit"]
  A --> D["Library.addMember"]
  D --> E["_.get"]
  D --> F["_.set"]
  D --> G["UserManagement.addMember"]
  G --> H["_.has"]
  G --> I["_.set"]

UserManagement.addMember 테스트 케이스

정상 케이스 1: 빈 상태에서 회원 추가

const member = {
  email: "jessie@gmail.com",
  password: "my-secret",
};

const userManagementStateBefore = {};

const expectedUserManagementStateAfter = {
  membersByEmail: {
    "jessie@gmail.com": {
      email: "jessie@gmail.com",
      password: "my-secret",
    },
  },
};

const result = UserManagement.addMember(userManagementStateBefore, member);
_.isEqual(result, expectedUserManagementStateAfter);
// → true

정상 케이스 2: 기존 회원이 있는 상태에서 추가

const jessie = { email: "jessie@gmail.com", password: "my-secret" };
const franck = { email: "franck@gmail.com", password: "my-top-secret" };

const userManagementStateBefore = {
  membersByEmail: {
    "franck@gmail.com": { email: "franck@gmail.com", password: "my-top-secret" },
  },
};

const expectedUserManagementStateAfter = {
  membersByEmail: {
    "jessie@gmail.com": { email: "jessie@gmail.com", password: "my-secret" },
    "franck@gmail.com": { email: "franck@gmail.com", password: "my-top-secret" },
  },
};

_.isEqual(
  UserManagement.addMember(userManagementStateBefore, jessie),
  expectedUserManagementStateAfter
);
// → true

부정적 케이스(Negative Test Case): 이미 존재하는 회원 추가 시 예외 발생

const jessie = { email: "jessie@gmail.com", password: "my-secret" };

const userManagementStateBefore = {
  membersByEmail: {
    "jessie@gmail.com": { email: "jessie@gmail.com", password: "my-secret" },
  },
};

const expectedException = "Member already exists.";
let exceptionInMutation: string | undefined;

try {
  UserManagement.addMember(userManagementStateBefore, jessie);
} catch (e) {
  exceptionInMutation = e as string;
}

_.isEqual(exceptionInMutation, expectedException);
// → true

핵심 인사이트: 부정적 테스트 케이스(실패 케이스)를 잊지 마라.

Library.addMember 테스트 케이스

• UserManagement.addMember는 이미 검증되었다고 가정하므로, 최소한의 케이스만 작성

const libraryStateBefore = {
  userManagement: {
    membersByEmail: {
      "franck@gmail.com": { email: "franck@gmail.com", password: "my-top-secret" },
    },
  },
};

const expectedLibraryStateAfter = {
  userManagement: {
    membersByEmail: {
      "jessie@gmail.com": { email: "jessie@gmail.com", password: "my-secret" },
      "franck@gmail.com": { email: "franck@gmail.com", password: "my-top-secret" },
    },
  },
};

_.isEqual(Library.addMember(libraryStateBefore, jessie), expectedLibraryStateAfter);
// → true

System.addMember 테스트 케이스

System.addMember는 반환값이 없다. 대신 시스템 상태를 직접 변경한다. 따라서 뮤테이션 실행 후 시스템 상태를 꺼내어 기대값과 비교한다.

class SystemState {
  private state: object = {};

  get(): object {
    return this.state;
  }

  commit(_previous: object, next: object): void {
    this.state = next;
  }
}

// 테스트
const systemState = new SystemState();
systemState.commit({}, libraryStateBefore); // 초기 상태 설정

System.addMember(systemState, jessie); // 뮤테이션 실행

_.isEqual(systemState.get(), expectedLibraryStateAfter);
// → true

핵심 인사이트: 시스템 상태도 결국 맵(객체)이다. 뮤테이션 실행 후 _.isEqual로 기대 상태와 비교할 수 있다.

챕터 6 요약

7. 기본 데이터 검증

DOP에서 데이터 검증은 불가능하거나 모순된 개념이 아니다. 오히려 시스템 경계에서의 데이터 검증은 권장 사항이다.

7.1 DOP에서의 데이터 검증 (Data validation in DOP)

핵심 원칙

• DOP Principle #4: 데이터 스키마(schema)와 데이터 표현(representation)을 분리하라
• DOP는 데이터 검증을 강제하지 않지만, 막지도 않는다
• 스키마는 독립적으로 존재하고, 데이터 표현도 독립적으로 존재한다
• 검증은 원하는 시점에 원하는 방식으로 자유롭게 수행할 수 있다

OOP vs DOP의 데이터 검증 비교

시스템 경계(System Boundaries)란

시스템 경계는 시스템이 데이터를 교환하는 영역으로 정의된다.

Client (Web Browser)
       |  (Data)
   Web Server
   /         \
(Data)      (Data)
DB        Web Service

현대 웹 서버 기준의 3가지 경계:

1. 클라이언트 경계 - 웹 브라우저 등 클라이언트와의 데이터 교환
2. 데이터베이스 경계 - DB와의 데이터 교환
3. 외부 서비스 경계 - 외부 웹 서비스와의 데이터 교환

두 가지 데이터 검증의 종류

• 경계 검증이 더 중요하다 - 경계에서 데이터가 유효하다면 시스템 내부에서 유효하지 않은 데이터가 등장할 가능성은 매우 낮다
• 경계 검증이 완료된 데이터는 내부에서 재검증할 필요가 없다

7.2 JSON Schema 개요 (JSON Schema in a nutshell)

JSON Schema란

• 데이터 표현과 독립적으로 데이터 스키마를 표현하는 언어 독립적 스키마 언어
• 공식 문서: https://json-schema.org (버전 2020-12 기준)
• 대부분의 프로그래밍 언어에서 검증 라이브러리를 사용할 수 있다

주요 JSON Schema 검증 라이브러리

기본 스키마 구조

검색 요청 데이터 예시:

const searchBooksRequest = {
  title: "habit",
  fields: ["title", "weight", "number_of_pages"]
};

스키마 작성 단계별 설명:

1. 최상위 타입 정의 (맵 = object)

const schema = {
  type: "object",
  properties: { /* ... */ }
};

1. 각 필드의 타입 정의

const schema = {
  type: "object",
  properties: {
    title: { type: "string" },
    fields: { type: "array" }
  }
};

1. 배열 요소의 타입 정의 (items)

const schema = {
  type: "object",
  properties: {
    title: { type: "string" },
    fields: {
      type: "array",
      items: { type: "string" }
    }
  }
};

1. 열거형 값 지정 (enum)

const schema = {
  type: "object",
  properties: {
    title: { type: "string" },
    fields: {
      type: "array",
      items: {
        enum: [
          "publishers",
          "number_of_pages",
          "weight",
          "physical_format",
          "subjects",
          "publish_date",
          "physical_dimensions"
        ]
      }
    }
  }
};

1. 필수 필드 지정 (required)

const searchBooksRequestSchema = {
  type: "object",
  properties: {
    title: { type: "string" },
    fields: {
      type: "array",
      items: {
        enum: [
          "publishers",
          "number_of_pages",
          "weight",
          "physical_format",
          "subjects",
          "publish_date",
          "physical_dimensions"
        ]
      }
    }
  },
  required: ["title", "fields"]
};

JSON Schema 사용 이유

• 언어 독립성: 어떤 언어에서도 동일한 스키마 사용 가능
• 높은 표현력: 범위 검증, 정규식 매칭 등 클래스로 표현하기 어려운 검증 조건을 지원
• 구성 가능성: 스키마 자체가 일반 맵(객체)이므로 변수로 저장하고 자유롭게 조합 가능

7.3 스키마의 유연성과 엄격성 (Schema flexibility and strictness)

선택 필드(Optional Fields) 처리

• JSON Schema에서 맵의 필드는 **기본적으로 선택(optional)**이다
• 필수 필드는 반드시 required 배열에 명시해야 한다

검색 응답 스키마 예시 (중첩된 스키마를 변수로 분리):

const bookInfoSchema = {
  type: "object",
  required: ["title", "available"],
  properties: {
    title: { type: "string" },
    available: { type: "boolean" },
    subtitle: { type: "string" },
    number_of_pages: { type: "integer" },
    subjects: {
      type: "array",
      items: { type: "string" }
    },
    isbn: { type: "string" },
    isbn_13: { type: "string" }
  }
};

const searchBooksResponseSchema = {
  type: "array",
  items: bookInfoSchema  // 스키마를 변수로 재사용
};

• 중첩된 스키마를 변수로 분리하면 가독성과 재사용성이 높아진다
• 클래스 정의와 달리 nullable 여부를 일일이 명시하지 않아도 된다

추가 필드 허용 여부 (additionalProperties)

• 기본적으로 스키마에 명시되지 않은 필드도 허용된다
• 엄격하게 제한하려면 additionalProperties: false를 설정한다

const booksFromDBSchema = {
  type: "array",
  items: {
    type: "object",
    required: ["title", "isbn", "available"],
    additionalProperties: false,  // 명시되지 않은 필드 불허
    properties: {
      title: { type: "string" },
      available: { type: "boolean" },
      isbn: { type: "string" }
    }
  }
};

Postel의 견고성 원칙 (Robustness Principle)

“Be conservative in what you send, be liberal in what you accept.” 보내는 데이터에는 엄격하게, 받는 데이터에는 유연하게 대처하라.

7.4 스키마 합성 (Schema composition)

스키마 합성이란

• 여러 스키마를 논리 연산자처럼 조합하는 기능
• 클래스 기반으로는 표현하기 어려운 복잡한 검증 조건을 표현 가능

합성 키워드

실제 사례: isbn_10 또는 isbn_13 필수 조건

• 2007년 이전 출판 도서: isbn_10 보유
• 2007년 이후 출판 도서: isbn_13 보유
• 두 조건 모두 만족하는 도서도 존재
• 조건: basicBookInfoSchema AND (mandatoryIsbn13 OR mandatoryIsbn10)

const basicBookInfoSchema = {
  type: "object",
  required: ["title"],
  properties: {
    title: { type: "string" },
    publishers: { type: "array", items: { type: "string" } },
    number_of_pages: { type: "integer" },
    weight: { type: "string" },
    physical_format: { type: "string" },
    subjects: { type: "array", items: { type: "string" } },
    isbn_13: { type: "array", items: { type: "string" } },
    isbn_10: { type: "array", items: { type: "string" } },
    publish_date: { type: "string" },
    physical_dimensions: { type: "string" }
  }
};

const mandatoryIsbn13 = {
  type: "object",
  required: ["isbn_13"]
};

const mandatoryIsbn10 = {
  type: "object",
  required: ["isbn_10"]
};

const bookInfoSchema = {
  allOf: [
    basicBookInfoSchema,
    {
      anyOf: [mandatoryIsbn13, mandatoryIsbn10]
    }
  ]
};

스키마 합성의 장점

• JSON Schema는 단순한 맵(객체)이므로 변수에 저장하고 자유롭게 재사용/조합 가능
• 클래스 정의보다 훨씬 높은 표현력
• 검증 로직이 명확하게 분리되어 읽기 쉽다

7.5 데이터 검증 실패 상세 정보 (Details about data validation failures)

검증 실패 시 상세 정보 얻기

• JSON Schema 검증은 단순한 true/false 이분법이 아니다
• 유효하지 않을 경우, 왜 유효하지 않은지 상세한 정보를 얻을 수 있다

Ajv 사용법 (TypeScript)

import Ajv from "ajv";

const searchBooksRequestSchema = {
  type: "object",
  properties: {
    title: { type: "string" },
    fields: {
      type: "array",
      items: { type: "string" }
    }
  },
  required: ["title", "fields"]
};

const invalidRequest = {
  myTitle: "habit",           // title 대신 myTitle로 오타
  fields: ["title", "weight", "number_of_pages"]
};

const ajv = new Ajv();
ajv.validate(searchBooksRequestSchema, invalidRequest);

// 에러 배열 구조
// ajv.errors =>
// [
//   {
//     instancePath: "",
//     schemaPath: "#/required",
//     keyword: "required",
//     params: { missingProperty: "title" },
//     message: "must have required property 'title'"
//   }
// ]

사람이 읽기 쉬운 형태로 변환

ajv.errorsText(ajv.errors);
// => "data must have required property 'title'"

다중 검증 실패 캐치

• 기본적으로 Ajv는 첫 번째 오류만 감지하고 중단한다 (성능 최적화)
• 모든 오류를 감지하려면 allErrors: true 옵션을 생성자에 전달한다

import Ajv from "ajv";

const invalidRequest = {
  myTitle: "habit",     // title 누락
  fields: [1, 2]        // 숫자 배열 (문자열이어야 함)
};

const ajv = new Ajv({ allErrors: true });  // 모든 오류 감지 모드
ajv.validate(searchBooksRequestSchema, invalidRequest);

ajv.errorsText(ajv.errors);
// => "data must have required property 'title',
//     data/fields/0 must be string,
//     data/fields/1 must be string"

JSON Schema 치트 시트

스키마 전체 구조 예시

const exampleSchema = {
  type: "array",           // 최상위 타입: 배열
  items: {
    type: "object",        // 배열의 각 요소: 객체(맵)
    properties: {
      myNumber: { type: "number" },
      myString: { type: "string" },
      myEnum: { enum: ["myVal", "yourVal"] },
      myBool: { type: "boolean" }
    },
    required: ["myNumber", "myString"],   // 필수 필드 명시
    additionalProperties: false           // 명시되지 않은 필드 불허
  }
};

유효한 데이터 예시

const validData = [
  {
    myNumber: 42,
    myString: "Hello",
    myEnum: "myVal",
    myBool: true
  },
  {
    myNumber: 54,
    myString: "Happy"
    // myEnum, myBool은 optional이므로 생략 가능
  }
];

타입 키워드 정리

챕터 7 요약

• DOP Principle #4: 데이터 스키마와 데이터 표현을 분리하라
• 시스템 경계(클라이언트, DB, 외부 서비스)에서의 검증이 가장 중요하다
• 경계 검증이 완료된 데이터는 내부에서 재검증할 필요가 없다
• JSON Schema는 언어 독립적이며 표현력이 높다
• JSON Schema는 단순한 맵(객체)이므로 변수로 저장하고 자유롭게 조합 가능하다
• 맵 필드는 기본적으로 선택(optional)이며, 필수 필드는 required로 명시해야 한다
• 외부 데이터 소스로부터 받은 데이터는 반드시 검증하는 것이 좋다
• 보내는 데이터에는 엄격하게(additionalProperties: false), 받는 데이터에는 유연하게 대처하라
• TypeScript/JavaScript에서는 Ajv 라이브러리를 사용한다
• Ajv는 기본적으로 첫 번째 오류만 감지하며, 모든 오류를 감지하려면 allErrors: true를 사용한다
• 고급 검증(범위, 정규식 등)은 Chapter 12에서 다룬다

8. 고급 동시성 제어

핵심 인사이트: 불변 데이터(Immutable Data)와 Atom을 조합하면, 뮤텍스(Mutex) 없이도 데드락 없는 안전한 동시성 제어가 가능하다.

8.1 The Complexity of Locks

전통적인 동시성 제어의 문제점

• 멀티스레드 환경에서 공유 데이터를 보호하기 위해 뮤텍스(Mutex) 같은 락(Lock) 메커니즘을 사용
• 락은 읽기(read)와 쓰기(write) 접근 모두를 보호해야 하는데, 이것이 시스템 복잡도를 크게 높임
• 락을 잘못 관리하면 데드락(Deadlock) 이 발생 – 예외 발생 시 락 해제를 빠뜨리거나, 두 락을 잘못된 순서로 해제하는 경우

왜 읽기에도 락이 필요한가?

• 락이 없으면 읽기 도중 다른 스레드에서 쓰기가 발생해 논리적으로 불일치한 데이터를 읽게 됨
• 이를 방지하기 위해 읽기 전에 데이터를 복제(clone)하는 방법도 있으나, 데이터가 크면 비용이 너무 커서 확장성이 없음

TIP: 읽기 락을 피하기 위해 데이터를 복제하는 방식은 확장성이 없다.

DOP에서 읽기가 항상 안전한 이유

• DOP에서는 데이터가 불변(immutable) 이기 때문에, 읽기 도중 다른 스레드에서 쓰기가 발생해도 읽고 있는 데이터 자체가 변경되지 않음
• 즉, 읽기는 항상 데이터 스냅샷(snapshot) 위에서 동작하는 것과 동일

TIP: 데이터가 불변이면, 읽기는 항상 안전하다.

8.2 Thread-Safe Counter with Atoms

Atom이란?

• Atom은 락 없이(lock-free) 동시성을 관리하는 메커니즘
• 데드락이 원천적으로 발생하지 않음

TIP: Atom을 사용하면 데드락은 절대 발생하지 않는다.

Atom의 3가지 메서드

뮤텍스 방식 vs Atom 방식 비교

뮤텍스 방식 (기존)

// 가상의 멀티스레드 JavaScript/TypeScript 환경 가정
const mutex = new Mutex();
let counter = 0;

function dbAccess() {
  mutex.lock();
  counter = counter + 1;
  mutex.unlock();
  // DB 접근 로직
}

function logCounter() {
  mutex.lock();
  console.log(`Number of database accesses: ${counter}`);
  mutex.unlock();
}

Atom 방식 (DOP)

const counter = new Atom<number>();
counter.set(0);

function dbAccess() {
  counter.swap((x) => x + 1); // x는 현재 값
  // DB 접근 로직
}

function logCounter() {
  console.log(`Number of database accesses: ${counter.get()}`);
}

• swap에 전달하는 함수의 인자 x는 counter.get()과 동일한 현재 값
• 읽기(logCounter)에는 아무런 락도 필요 없음

swap이 스레드 세이프한 원리

swap은 내부적으로 CAS(Compare-And-Set/Swap) 연산을 사용함

flowchart TD
    A["스냅샷 저장<br/>snapshot = state"] --> B["다음 값 계산<br/>nextState = f(snapshot)"]
    B --> C{"state == snapshot?"}
    C -- "Yes" --> D["state = nextState<br/>업데이트 성공"]
    C -- "No" --> A

1. 현재 상태를 스냅샷으로 저장
2. 스냅샷에 함수 f를 적용해 다음 상태 계산
3. 현재 상태가 스냅샷과 동일한지 원자적으로(atomically) 비교
4. 동일하면 업데이트 성공, 다르면 처음부터 재시도

Atom 클래스 구현

class Atom<T> {
  private state!: T;

  get(): T {
    return this.state;
  }

  set(state: T): void {
    this.state = state;
  }

  swap(f: (current: T) => T): T {
    while (true) {
      const stateSnapshot = this.state;
      const nextState = f(stateSnapshot);
      // atomicCompareAndSet: state가 stateSnapshot과 같을 때만 nextState로 교체
      if (atomicCompareAndSet(this.state, stateSnapshot, nextState)) {
        return nextState;
      }
      // 실패 시 재시도
    }
  }
}

• atomicCompareAndSet은 CPU 수준의 원자적 연산으로, 락 없이도 스레드 안전성을 보장
• Java에서는 java.util.concurrent.atomic.AtomicReference의 compareAndSet()이 이에 해당

Starvation(기아 현상) 가능성

• 이론상: 수천 개의 스레드가 Atom만 계속 swap하면 특정 스레드가 영원히 성공하지 못하는 기아 현상이 발생할 수 있음
• 실제로는: Atom을 swap한 후 스레드는 DB 접근, I/O 등 실제 작업을 수행하므로, 다른 스레드가 성공할 기회가 생김 – 실무에서 기아 현상은 거의 발생하지 않음

8.3 Thread-Safe Cache with Atoms

인메모리 캐시 개요

• DB 쿼리 결과를 메모리에 저장해 응답 속도를 향상시키는 패턴
• 문자열 맵(String Map) 으로 표현하는 것이 일반적 – key: 쿼리, value: 결과

TIP: 인메모리 캐시는 문자열 맵으로 표현하는 것이 일반적이다.

뮤텍스 방식 vs Atom 방식 비교

뮤텍스 방식 (기존)

const mutex = new Mutex();
let cache: Record<string, unknown> = {};

function dbAccessCached(query: string): unknown {
  const resultFromCache = cache[query];
  if (resultFromCache != null) {
    return resultFromCache;
  }

  const result = dbAccess(query);

  mutex.lock();
  cache = { ...cache, [query]: result }; // 불변 방식으로 업데이트
  mutex.unlock();

  return result;
}

Atom 방식 (DOP)

const cache = new Atom<Record<string, unknown>>();
cache.set({});

function dbAccessCached(query: string): unknown {
  const resultFromCache = cache.get()[query];
  if (resultFromCache != null) {
    return resultFromCache;
  }

  const result = dbAccess(query);

  // swap: oldCache를 받아 query-result 쌍이 추가된 새 맵을 반환
  cache.swap((oldCache) => ({
    ...oldCache,
    [query]: result,
  }));

  return result;
}

불변 데이터와 참조 비교(Reference Comparison)

• swap 내부의 atomicCompareAndSet이 맵을 비교할 때, 불변 데이터는 참조(reference)로 비교하므로 매우 빠름
• 가변 데이터였다면 값의 동등성(deep equality)을 확인해야 해서 비용이 큼

TIP: 데이터가 불변이면, 참조 비교는 안전하고(safe) 빠르다(fast).

8.4 State Management with Atoms

기존 SystemState 클래스의 문제점

class SystemState {
  private systemData: unknown;

  get(): unknown {
    return this.systemData;
  }

  set(systemData: unknown): void {
    this.systemData = systemData;
  }

  commit(previous: unknown, next: unknown): void {
    // 이 코드가 여러 스레드에서 동시에 실행될 수 있어 스레드 안전하지 않음
    this.systemData = SystemConsistency.reconcile(
      this.systemData,
      previous,
      next
    );
  }
}

• commit 내부의 reconcile 로직이 락으로 보호되지 않아, 두 스레드가 동시에 실행하면 데이터 불일치 발생 가능

Atom으로 스레드 안전하게 개선

class SystemState {
  private systemData: Atom<unknown>;

  constructor() {
    this.systemData = new Atom();
  }

  get(): unknown {
    return this.systemData.get();
  }

  set(data: unknown): void {
    this.systemData.set(data);
  }

  commit(previous: unknown, next: unknown): void {
    // reconcile을 swap 안에 감싸서 원자적으로 실행
    this.systemData.swap((current) =>
      SystemConsistency.reconcile(current, previous, next)
    );
  }
}

• swap에 reconcile을 감쌈으로써, CAS 메커니즘이 충돌을 감지하고 자동으로 재시도
• 락 없이 전체 시스템 상태를 스레드 안전하게 관리할 수 있음

챕터 8 요약

• 불변 데이터 + Atom의 조합은 DOP에서 동시성을 다루는 핵심 패턴
• Atom은 단순 카운터(Primitive 타입)뿐 아니라 복합 데이터(맵, 객체 등)에도 동일하게 적용 가능
• 전체 시스템 상태를 하나의 Atom 안에 보관함으로써, DOP의 고확장성 상태 관리 방식을 스레드 안전하게 만들 수 있음

9. 영속적 자료구조

거인의 어깨 위에 서서 (Standing on the Shoulders of Giants)

이 챕터는 데이터 불변성(Immutability)을 안전하고 확장 가능하게 유지하는 방법으로서 영속적 자료구조(Persistent Data Structures) 를 소개한다. Part 1에서 구조적 공유(Structural Sharing)와 불변 함수로 상태를 관리하는 방법을 다뤘다면, 이 챕터에서는 그 한계를 극복하는 실질적인 방법론을 다룬다.

9.1 영속적 자료구조가 필요한 이유 (The Need for Persistent Data Structures)

역사적 배경

• 2001년: Phil Bagwell이 영속적 자료구조의 효율적 구현 기반을 발견
• 2007년: Rich Hickey(Clojure 창시자)가 이를 Clojure 언어의 핵심 기능으로 채택
• Phil Bagwell은 2012년 타계했으며, 이 개념은 그의 중요한 학문적 유산

불변성을 보장하는 “순진한 방법” (Naive Way)

언어별로 불변 컬렉션을 제공하는 기본 방법이 있다.

Java의 경우

var myImmutableList = List.of(myList.toArray());
var myImmutableMap = Collections.unmodifiableMap(myMap);
// 수정 시도 시 → UnsupportedOperationException 발생

JavaScript / TypeScript의 경우

Object.freeze()를 사용하지만 얕은(shallow) 동결만 수행한다.

const a = [1, 2, 3];
Object.freeze(a);

const b = { foo: 1 };
Object.freeze(b);
// strict mode: TypeError 발생
// non-strict mode: 조용히 실패 (silent fail)

중첩 객체까지 동결하려면 재귀적 deepFreeze가 필요하다.

function deepFreeze<T extends object>(obj: T): Readonly<T> {
  const propNames = Object.getOwnPropertyNames(obj);
  for (const name of propNames) {
    const value = (obj as Record<string, unknown>)[name];
    if (value && typeof value === "object") {
      deepFreeze(value as object);
    }
  }
  return Object.freeze(obj);
}

핵심 인사이트: 수동으로 불변성을 보장하는 것은 가능하지만 번거롭다.

순진한 구조적 공유(Naive Structural Sharing)의 한계

핵심 인사이트: 대규모에서 순진한 구조적 공유는 메모리와 연산 모두에서 성능 문제를 유발한다.

핵심 인사이트: 불변 컬렉션(Immutable Collections)과 영속적 자료구조(Persistent Data Structures)는 다르다. 불변 컬렉션은 새 버전을 효율적으로 생성하는 방법을 제공하지 않는다.

9.2 영속적 자료구조의 효율성 (The Efficiency of Persistent Data Structures)

영속적 자료구조란?

• 정의: 수정될 때 항상 이전 버전을 보존하는 자료구조
• 불변성 + 효율적인 새 버전 생성을 동시에 달성

핵심 인사이트: 영속적 자료구조는 수정될 때 항상 이전 버전을 보존한다.

구조적 공유가 안전한 이유

핵심 인사이트: 데이터가 불변이면 공유해도 안전하다.

연결 리스트(Linked List)로 이해하는 구조적 공유:

[새 리스트]
  0 → [기존 리스트의 head를 가리킴]

[기존 리스트]
  1 → 2 → 3 → 4 → 5

• 기존 리스트가 불변임이 보장될 때, 새 head가 기존 head를 가리키면 됨
• 이 연산의 효율성은 리스트 크기와 무관하게 O(1)

트리 기반 구조: 효율적인 업데이트

리스트를 트리로 표현하면 대부분의 노드를 두 버전 간에 공유할 수 있다.

단계적 분할 전략

10만 개 항목의 리스트에서 단일 요소 업데이트 시 연산 비용 비교:

결론: 반복 분할 시 복잡도 = O(log₂N)

10만 항목에서 log₂(100,000) ≈ 16.6

flowchart TD
  Root["List (0~99,999)"]
  L1["List 1 (0~49,999)"]
  L2["List 2 (50,000~99,999)"]
  L2_1["List 2.1 (50,000~74,999)"]
  L2_2["List 2.2 (75,000~99,999) NEW"]
  L2_2_shared["List 2.2 (75,000~99,999) OLD (shared)"]

  Root --> L1
  Root --> L2
  L2 --> L2_1
  L2 --> L2_2
  L2_2 -.->|structural sharing| L2_2_shared

분기 계수(Branching Factor) 최적화: 2 → 32

핵심 인사이트: 분기 계수 32를 사용하면 영속 리스트의 요소 접근이 더욱 효율적이다.

현대 CPU 아키텍처와 캐시 라인 최적화

• 현대 CPU는 캐시 라인(Cache Line) 단위(32~64바이트)로 메모리를 읽고 씀
• 크기 32의 배열 복사 = 단 1쌍의 캐시 접근(읽기 1 + 쓰기 1)
• 크기 2인 배열 16개 복사 = 16쌍의 캐시 접근 (각각 다른 트리 레벨)

핵심 인사이트: 현대 CPU 아키텍처에서 영속 리스트 업데이트 성능은 각 레벨의 노드 수보다 트리 깊이에 훨씬 더 많은 영향을 받는다.

실용적 관점: 사실상 O(1)

• 현실에서 리스트 항목 수의 상한선을 고려
• 10억 개 항목 = 약 4GB 메모리 (4bytes/항목 기준)
• 100억 개 항목 기준: log₃₂(10B) ≈ 6.64
• 최대 7번의 연산으로 모든 항목에 접근 가능 → 사실상 상수 시간

핵심 인사이트: 영속 리스트는 사실상 상수 시간(near constant time)으로 조작할 수 있다.

9.3 영속적 자료구조 라이브러리 (Persistent Data Structures Libraries)

언어별 라이브러리 현황

Java: Paguro

• 영속적 맵: java.util.Map의 읽기 전용 메서드(get, containsKey)만 구현
• 쓰기 메서드(put, remove) 호출 시 → UnsupportedOperationException 발생
• Java 스트림 인터페이스 완전 지원
• 새 버전 생성 메서드: 벡터는 replace(), 맵은 assoc()

// 벡터 수정 버전 생성
var myVec = PersistentVector.ofIter(List.of(10, 2, 3));
var myNextVec = myVec.replace(0, 42);

// 맵 수정 버전 생성
var myMap = PersistentHashMap.of(Map.of("aa", 1, "bb", 2).entrySet());
var myNextMap = myMap.assoc("aa", 42);