오브젝트 — 코드로 이해하는 객체지향 설계¶

정의¶

한국어로 쓰인 객체지향 설계 입문서 중 가장 자주 권장되는 책. "책임 주도 설계(Responsibility-Driven Design)" 관점에서 OO를 처음부터 다시 짠다 — 데이터·상속·다형성 같은 문법 항목이 아니라 객체 간의 협력과 책임 분배를 중심에 두고 절·장이 흘러간다.

"메시지가 객체를 결정한다. 행동이 상태를 결정한다." (3장 절 제목)

책 메타데이터¶

항목	값
저자	조영호
출판	위키북스 (2019)
분량	약 700페이지, 15장 + 부록 4편
언어	한국어
선행 도서	같은 저자의 객체지향의 사실과 오해 (위키북스, 2015) — 짧고 비유 중심, 입문용
관계 도서	오브젝트 = 같은 주장에 대한 본격 코드 기반 해설
공식 페이지	https://wikibook.co.kr/object/

핵심 메시지 (목차에서 그대로 도출)¶

메시지	출처 절	풀이
자율성을 높이자	1.03	객체가 자기 데이터를 스스로 책임지게 → 캡슐화 = "잘못된 상태를 막는 것"
메시지가 객체를 결정한다	3.02	클래스부터 그리지 말고, 어떤 메시지가 필요한지부터 → 그 메시지를 잘 처리할 객체를 찾는다
행동이 상태를 결정한다	3.02	필드부터 그리지 말고, 행동(책임)부터 정한 뒤 필요한 상태만 갖는다
데이터보다 행동을 먼저 결정하라	5.01	4장의 "데이터 중심 설계"가 왜 망가지는지 보여준 뒤, 역순으로 재정렬
묻지 말고 시켜라 (Tell, Don't Ask)	6.02	getter로 꺼내 와 호출자가 처리하지 말고, 객체에게 일을 시켜라
명령-쿼리 분리 (CQS)	6.04	한 메서드는 상태를 바꾸거나 값을 돌려주거나, 둘 중 하나만
new는 해롭다	8.02	구체 클래스 직접 생성은 결합도를 만든다 → DI/Factory로 분리
객체 합성이 클래스 상속보다 더 좋다	11.03	GoF Design Patterns 원칙을 한국어 시나리오(핸드폰 과금)로 재증명
서브클래싱 ≠ 서브타이핑	13.03	코드 재사용용 상속과 타입 호환용 상속은 다르다 → LSP

이 9개가 책 전체를 관통하는 골격. 나머지 챕터는 모두 이 메시지를 영화 예매·핸드폰 과금 두 시그니처 예제로 반복 증명한다.

챕터 흐름 (4부 구조)¶

목차에는 부 구분이 없지만 흐름상 4부로 묶을 수 있다.

부 (논리적)	장	목적
I. 도입 — 무엇이 문제인가	들어가며·1·2	절차지향 코드의 한계 → 영화 예매 시스템으로 첫 OO 구현
II. 책임 관점으로 재정렬	3·4·5·6·7	데이터 중심 설계의 함정 → 책임 주도 설계 → GRASP → 메시지·인터페이스 → 객체 분해
III. 유연성을 만드는 도구	8·9·10·11·12·13	의존성 관리 → OCP·DIP → 상속의 한계 → 합성 → 다형성 → LSP
IV. 큰 그림	14·15·마치며	일관된 협력 패턴 → 디자인 패턴·프레임워크 → 앞으로
부록	A·B·C·D	계약에 의한 설계(DbC), 타입 계층 구현 기법, 동적 협력 vs 정적 코드, 참고문헌

5권 도서 오각형 — OO 설계 학습의 5권 세트¶

OO 설계 핵심 5권이 서로 다른 단위·시점에서 같은 OO 결론을 가리킨다.

책	관점	단위	시점	언어
(이 책) entity-object 오브젝트	책임 주도 설계 (목적지)	객체·협력·역할	처음부터 잘 설계	Java
entity-effective-java Effective Java	90 권고 (매뉴얼)	메서드·필드·생성자	매번 짤 때	Java
entity-refactoring 리팩터링 2판	카탈로그 (가는 길)	1단계 변환	이미 짠 코드	JS (2판)
entity-clean-code Clean Code	미시 규칙 + 휴리스틱	줄·이름·함수	매 라인	Java
entity-tdd TDD	사이클 (만드는 과정)	사이클 1회 (분)	코드 짜기 전	Java + Python

오브젝트 의 자리 : OO 설계의 목적지 를 가장 풍부한 한국어 시나리오 (영화 예매·핸드폰 과금) 로 그려냄. 다른 4권이 매번·1단계·1줄·1사이클 단위라면 오브젝트 는 객체·협력 단위의 큰 그림.

추천 학습 순서 (5권 전체): 1. Clean Code 2·3·4·10장 — 가장 빠른 효과 (줄·이름) 2. Effective Java 2·3·8·10장 — Java 권고 90 개 3. 리팩터링 3장 (24 악취) + 6장 (기본) — 기존 코드 개선 어휘 4. 오브젝트 1~5장 + 11장 — OO 설계 큰 그림 (이 책) 5. TDD 1·2부 — 테스트가 설계 끌어내기 6. 5권 교차 참조

시그니처 예제 (책 전반에서 반복)¶

예제	등장	무엇을 보여주는가
티켓 판매 애플리케이션	1장	첫 절차지향 → OO 리팩터링 과정 (책의 출발점)
영화 예매 시스템	2·3·4·5·6장	할인 정책/조건의 다형성, 데이터 중심 설계의 함정
핸드폰 과금 시스템	10·11·14장	상속의 폭발적 조합 문제 → 합성으로 해결, 일관된 협력 패턴
강의 평가	12장	상속의 데이터 관점 vs 행동 관점

→ 두 시그니처 예제(영화 예매·핸드폰 과금)는 책을 통째로 관통하므로, 한 번 익혀두면 인용·발표 자리에서 바로 꺼내 쓸 수 있는 자산.

책의 주제 → 위키 기존 페이지 매핑¶

책 주제	장	위키 기존 페이지
객체지향 4원칙 (캡슐화·상속·다형성·추상화)	2·12	concept-oop
디자인 패턴 23개 + 프레임워크	15	concept-design-patterns
Strategy 패턴 (할인 정책 다형성의 직접 사례)	2.03	concept-design-patterns (전략 패턴 섹션)
Template Method / Factory	5·9	concept-design-patterns
도메인 모델 / 분석·설계·구현 모델	부록 C	src-kakaopay-ddd (DDD 실전), concept-spring-core (IoC)
의존성 주입 / IoC	9	concept-spring-core (Spring DI), concept-design-patterns (Factory)
계약에 의한 설계 / 사전·사후조건 / 불변식	부록 A	(신규 후보 — `concept-design-by-contract`, 미작성)
리스코프 치환 원칙 (LSP)	13	(신규 후보 — `concept-solid`, 미작성)
개방-폐쇄 원칙 (OCP) / 의존성 역전 (DIP)	9	(신규 후보 — `concept-solid`, 미작성)
GRASP (책임 할당 9패턴)	5	(신규 후보 — `concept-grasp`, 미작성)

→ 신규 concept 후보 4개 (DbC·SOLID·GRASP·DDD 모델 종류) — 사용자가 책 노트·발췌 보내주면 그때 ingest. 백로그에도 등록.

위키 기존 페이지에 보강할 인용 후보¶

페이지	어디서 인용	효과
concept-oop	"본질: 객체가 자기 데이터에 책임을 진다" 옆에 책 출처 명기	위키의 OO 정의에 한국어 표준 인용 추가
concept-design-patterns	"객체 합성이 클래스 상속보다 더 좋다" 인용 (11.03)	GoF 원칙의 한국어 출처
concept-design-patterns Strategy 섹션	영화 예매 할인 정책을 사례로 추가	추상 사례 → 친숙한 한국어 사례

같은 인사이트 패턴 — "데이터부터 그리면 망한다"¶

영역	"데이터 먼저" 함정	"책임/행동 먼저" 해법	참조
객체 설계	필드부터 그리고 getter/setter 양산 → 빈혈 모델	메시지·책임부터 → 필요한 상태만	(오브젝트 3·4·5장)
DB 풀 운영	풀 크기 기본값 가정 → 운영 사고	부하 측정·트랜잭션 점유 시간 먼저	concept-db-connection-pool
VARCHAR 길이	255 신화로 그냥 시작	인덱스·utf8mb4 바이트 계산 먼저	concept-varchar-length-prefix
API 계약	DTO 필드 먼저 다 만들기	Tolerant Reader 가정·진화 시나리오 먼저	concept-api-backward-compatibility

→ 공통 원리: 정적 구조(데이터·필드·기본값)에서 출발하면 동적 행동(변경·부하·진화)을 못 견딘다. 행동·시나리오부터 정의한 뒤 정적 구조를 유도하는 것이 변경에 강한 설계의 공통 원칙.

누구에게·언제 권할 책인가¶

독자	효과
OO 입문을 막 뗀 신입~3년차	4원칙(캡슐화·상속·다형성·추상화)을 안다고 생각했는데, "왜 그렇게 해야 하는가" 가 비로소 연결됨
Spring·JPA만 익숙한 5~10년차	프레임워크 위에서 코드를 짜 왔지만 "내가 도메인 모델링을 못 하는 것 같다" 는 의심이 든 시점
DDD 책으로 좌절한 사람	Evans/Vernon의 DDD가 추상적이라 어렵게 느꼈다면, 오브젝트가 그 앞 단계의 누락된 기반을 채워준다
신입 교육 자료를 짜는 사람	영화 예매 시스템 예제를 통째로 신입 교육 모듈로 재사용 가능

빠른 진단 — 이 책을 펴야 할 신호¶

getter/setter가 클래스의 80% 이상이고, "캡슐화는 했는데?" 라는 생각이 든다
Strategy/Template Method 같은 패턴 이름은 알지만 언제 꺼내야 할지 직감이 없다
상속을 쓸 때 항상 찜찜한데 합성으로 갈아탈 자신이 없다
DI 컨테이너 없이 객체 생성·연결을 직접 해 본 적이 별로 없다 (new 의존도가 높다)
LSP·OCP·DIP를 외웠지만 코드 리뷰에서 적용 사례를 못 짚는다

위 중 2개 이상이면 1~5장 + 11장만 먼저 읽어도 가치 있다.

한계·주의¶

분량이 크다 (700페이지) — 절·장이 반복적이라 한 번에 다 못 읽음. 3장·5장·11장·13장이 가장 응축돼 있어 그것부터 발췌 가능.
한국어 전용 — 영어판 없음. 해외 동료와 같은 책으로 토론은 어려움.
Java 7~8 기준 코드 (2019년 출판) — record·sealed 같은 신문법은 안 다룸. 메시지·책임 관점은 언어 버전과 무관해서 큰 문제 아님.

원본 출처¶

raw/object/toc.md — 사용자가 입력한 목차 (2026-06-20)
raw/object/오브젝트 실전 강의 교재 1~15장.md + 부록 A·B·C — 18편 강의 교재 (사용자 입력 1·2·3장 + 본 세션 작성 4~15장·부록, 약 4,000줄)
통합 인덱스: src-object-lecture
책 본문 직접 인용 아닌 강의용 재구성