책 소개
책 소개
"코드는 누구나 작성할 수 있다.
하지만 좋은 설계는 객체지향을 이해한 사람만이 만들 수 있다!"
수십 년 동안 소프트웨어 개발을 이끌어 온 객체지향의 본질과 실천법을 담은 결정판
많은 개발자가 객체지향 언어를 사용한다. 그러나 정작 객체지향이 무엇인지, 왜 객체지향적으로 설계해야 하는지 명확하게 설명할 수 있는 사람은 많지 않다. 클래스와 상속을 사용하는 것만으로는 객체지향 개발이라 할 수 없다. 진정한 객체지향은 복잡한 현실 세계를 모델링하고, 변화에 유연하게 대응할 수 있는 구조를 설계하는 데서 시작된다.
이 책은 객체지향의 탄생 배경과 철학부터 객체 모델링, UML 설계, 구현 기법까지 객체지향 개발의 핵심 과정을 체계적으로 설명한다. 단순히 개념을 나열하는 데 그치지 않고, 구조적 프로그래밍에서 객체지향으로 진화하는 과정을 실행 가능한 코드와 함께 생생하게 보여 준다.
객체지향 설계를 본격적으로 고민하는 학생에게는 탄탄한 지침서가 되고, 설계 역량을 키우고 싶은 개발자에게는 객체지향의 본질을 다시 돌아보게 만드는 안내서가 될 것이다.
출판사 서평
문법을 넘어 소프트웨어가 유연해지는 진짜 설계를 만나다
30년의 탐구와 통찰이 담긴 가장 솔직하고 정교한 객체지향 안내서
문법은 배웠다. 그런데 왜 설계는 여전히 막막할까?
자바나 C++ 문법은 능숙하게 다루는데, 왜 내 코드는 구조적 프로그래밍에 갇혀 있을까? 문법은 도구일 뿐, 도구를 다루는 것과 유연한 구조를 설계하는 것은 전혀 다른 영역이기 때문이다. 이 책은 단순한 API 사용법이나 추상적인 이론을 늘어놓지 않는다. 코드가 진화하는 과정 자체로 설계가 왜 필요한지 보여 준다. 고급 기술과 디자인 패턴도 외울 대상이 아니라 설계 문제의 해법으로 자연스럽게 만나게 된다.
이 책은 절대 편법이나 지름길을 말하지 않는다.
"동적 할당과 포인터라는 용어를 처음 접하는 사람은 당장 이 책을 덮어야 한다." 저자는 시작부터 타협 없는 경고를 던진다. 얄팍한 요령 대신 컴퓨터 과학의 탄탄한 기초 체력을 요구하는 정공법을 택했기 때문이다. 객체지향을 온전히 이해하는 과정은 험난한 설악산을 등반하는 것과 같다. 안개에 가려 전방 100미터만 보이는 고단한 고개를 끈기 있게 넘어야 한다. 그러나 마침내 정상에 올라서는 순간, 막혔던 시야가 트이며 세상을 완전히 새로운 객체의 눈으로 바라보는 지적 희열을 맛보게 된다. 이 책은 그 정상으로 가는 가장 정직한 길을 안내한다.
목차
목차
- 지은이 소개
- 지은이의 말
- 1장 객체지향 패러다임의 역사
- __1.1 소프트웨어 공학적 관점의 역사
- __1.2 객체지향 언어의 역사
- __1.3 객체지향 방법론과 객체지향 도구
- __1.4 독자가 주지해야 할 사항
- 2장 C 언어와 자바
- __2.1 포인터와 구조체
- ____2.1.1 참조에 의한 호출을 위한 경우
- ____2.1.2 배열에 대한 간접적인 접근 수단으로 사용하는 경우
- ____2.1.3 동적 변수의 접근 수단으로 사용하는 경우
- ____2.1.4 고수준의 추상화된 정보를 표현하기 위한 경우
- __2.2 잘 짜인 C 프로그램
- ____2.2.1 가장 엉터리지만 가장 자주 보게 되는 경우
- ____2.2.2 함수를 엉터리로 작성하는 경우
- ____2.2.3 범용성 있는 함수 작성의 경우
- ____2.2.4 구조체를 이용한 경우
- ____2.2.5 자료 추상화를 적용한 C 프로그램 스타일
- __2.3 C와 자바와의 관계
- ____2.3.1 typedef 선언문을 class 정의 문으로 바꾼다.
- ____2.3.2 함수 시그니처에서 첫 번째 형식 인자를 생략한다.
- ____2.3.3 함수 바디에 this라는 변수를 도입한다.
- ____2.3.4 생성자(constructor)를 만든다.
- ____2.3.5 메인 함수의 변환
- __2.4 자바의 특성 요약
- 3장 객체지향 패러다임의 기본 원리
- __3.1 기본 지식
- ____3.1.1 '객체지향' 용어에 대해
- ____3.1.2 '추상화'의 의미
- ____3.1.3 시스템을 해석하는 관점
- ____3.1.4 '객체'와 '클래스'
- ____3.1.5 '같은 것'과 '다른 것'에 대한 고찰
- ____3.1.6 공급자와 사용자
- ____3.1.7 객체의 부속품
- __3.2 자료 추상화
- __3.3 상속
- __3.4 다형 개념
- __3.5 동적 바인딩
- __3.6 객체지향 프로세스의 특성
- ____3.6.1 반복적인 프로세스
- ____3.6.2 솔기 없는 프로세스
- ____3.6.3 상향식 프로세스
- ____3.6.4 재사용에 대한 고려
- __3.7 객체지향의 기타 속성
- 4장 객체지향 기술의 심화 기능
- __4.1 추상 클래스
- __4.2 다중 상속
- __4.3 예외 처리 기능
- ____4.3.1 과거의 접근 방법
- ____4.3.2 예외 처리 문법
- ____4.3.3 예외 처리 방식
- ____4.3.4 예외 처리 기타 사항
- __4.4 인터페이스
- ____4.4.1 명세부로서의 의미
- ____4.4.2 사물을 보는 관점
- ____4.4.3 자바에서의 이용
- ____4.4.4 C++의 경우의 인터페이스
- ____4.4.5 컴포넌트 공학에서의 이용
- __4.5 리플렉션
- __4.6 시리얼라이제이션
- __4.7 RMI
- ____4.7.1 RMI 코딩 기본 절차
- ____4.7.2 서버에서 클라이언트 레퍼런스 사용
- ____4.7.3 클라이언트에서 다른 클라이언트 레퍼런스 사용
- __4.8 디자인 패턴
- ____4.8.1 템플릿 메서드 패턴
- ____4.8.2 데코레이터 패턴
- ____4.8.3 옵저버 패턴
- ____4.8.4 커맨드 패턴
- __4.9 객체지향 기타 원리
- ____4.9.1 결합도와 응집력
- ____4.9.2 디미터의 법칙
- ____4.9.3 단일 역할 원칙
- ____4.9.4 개방 폐쇄 원칙
- ____4.9.5 의존성 역전 원칙
- 5장 객체지향 패러다임의 실습
- __5.1 자료 추상화의 사용
- ____5.1.1 클래스의 필요성 인식 후 클래스 명칭 결정
- ____5.1.2 사용자 관점에서 클래스의 이용
- ____5.1.3 클래스의 명세 결정
- ____5.1.4 생산자 관점에서 클래스 자원 구현
- ____5.1.5 클래스 검증 및 확정
- __5.2 상속의 사용
- ____5.2.1 클래스 묶음의 인식
- ____5.2.2 클래스 묶음에 속하는 개별 클래스의 서비스 정의
- ____5.2.3 개별 클래스의 본질적인 데이터 멤버 정의
- ____5.2.4 데이터 멤버 중에서 공통적인 것의 구분
- ____5.2.5 상속 트리의 여러 대안 제시 및 평가
- ____5.2.6 선택된 상속 트리를 이용한 구현
- __5.3 동적 바인딩의 적용
- ____5.3.1 루트 클래스를 위한 멤버 함수 시그니처 모으기
- ____5.3.2 하위 클래스를 위한 메서드 구현
- ____5.3.3 사용자 관점에서 코드 작성 방식
- ____5.3.4 동적 바인딩의 처리를 위한 내부 메커니즘
- __5.4 다형 개념의 적용
- 6장 UML
- __6.1 다이어그램 개요
- ____6.1.1 유즈케이스 다이어그램
- ____6.1.2 클래스 다이어그램
- ____6.1.3 시퀀스 다이어그램
- ____6.1.4 협동도
- ____6.1.5 상태도
- ____6.1.6 행위도
- ____6.1.7 배치도
- __6.2 클래스 다이어그램의 이용법
- ____6.2.1 클래스 표기법의 이용
- ____6.2.2 일반화 표기법의 이용
- ____6.2.3 집합화/합성화
- ____6.2.4 의존관계
- ____6.2.5 일대일(1:1) 결합관계
- ____6.2.6 일대상수(1:K) 결합관계
- ____6.2.7 일대다(1:N) 결합관계
- ____6.2.8 다대다(M:N) 결합관계
- ____6.2.9 결합 클래스
- ____6.2.10 삼각관계
- __6.3 모델링 팁
- 7장 객체지향 구현
- __7.1 에덴동산 예제
- ____7.1.1 에덴동산 C++ 버전
- ____7.1.2 에덴동산 자바 버전
- __7.2 자바로 작성된 간단한 그래픽 편집기 예제
- __7.3 기타 객체지향 언어 소개
- ____7.3.1 스몰토크
- ____7.3.2 오브젝티브 C
- ____7.3.3 Ada
- __7.4 프로그래밍 팁
- 8장 OODesigner의 사용법
- __8.1 개요
- __8.2 다이어그래머 사용법
- __8.3 특이 기능
- ____8.3.1 갈라진 선분 긋기
- ____8.3.2 소스코드 편집 대화상자 기능
- ____8.3.3 화면 캡처 기능
- ____8.3.4 관련 클래스 요약 기능
- ____8.3.5 OLE 컨테이너 기능
- ____8.3.6 OLE 서버 기능
- 감사의 말씀
- 찾아보기
관련 블로그 글
AI가 코드를 짜주는 시대, 왜 다시 객체지향인가?
요즘 개발자 커뮤니티에서 빠지지 않는 키워드가 하나 있어요. 바로 바이브 코딩이에요.
"쇼핑몰 하나 만들어줘." 이렇게 자연어로 말만 하면 AI가 알아서 코드를 짜주는 개발 방식인데요. 오픈AI 공동 창립자 안드레이 카파시가 2025년에 처음 쓴 이 말이, 불과 1년여 만에 개발 생태계를 뒤흔드는 키워드가 됐어요.
커서, 클로드 코드, 깃허브 코파일럿 같은 AI 코딩 도구가 쏟아져 나오면서, 개발자 10명 중 9명이 이미 이런 도구를 사용하고 있어요. 심지어 코드 한 줄 안 써본 사람도 앱을 만들어내는 시대가 됐고요.
그런데 말이에요. 이 흐름 속에서 좀 불편한 질문 하나가 계속 떠오르고 있어요.
"AI가 코드를 다 짜주면… 개발자는 대체 뭘 해야 하는 거야?"
AI가 짜준 코드, 왜 자꾸 문제가 생길까? 🧩
바이브 코딩의 가능성은 분명 놀라워요. 프롬프트 몇 줄이면 화면부터 서버, 배포까지 한 번에 처리되니까요. 그런데 막상 써본 사람들 사이에서는 좀 다른 이야기가 나오고 있어요.
"AI로 빠르게 만들긴 했는데, 기능 하나 추가하려니까 코드가 전부 엉켜서 처음부터 다시 짜야 했어요." "사용자가 좀 늘어나니까 바로 서버가 터졌는데, 알고 보니 구조 자체가 잘못돼 있었어요." 바이브 코딩을 경험한 개발자들 사이에서 이런 이야기가 점점 많아지고 있거든요.
코드를 만드는 건 AI가 해줄 수 있어요. 하지만 그 코드가 올바른 구조인지, 나중에 기능을 추가해도 무너지지 않는 구조인지 판단하는 건 여전히 사람의 몫이에요. 전문가들은 이렇게 쌓이는 문제를 '기술 부채'라고 부르는데요. 코드를 '만드는' 비용은 거의 0원에 가까워졌지만, 잘못 만든 코드를 '고치고 유지하는' 비용은 오히려 폭발적으로 늘어날 수 있다는 거예요.
짜는 사람에서 설계하는 사람으로 🧭
그래서 요즘 이런 말이 나와요. "개발자의 경쟁력은 코드를 얼마나 잘 짜느냐가 아니라, 얼마나 잘 설계하느냐에 달려 있다"고요.
과거에는 "코드를 얼마나 빠르고 정확하게 짜는가"가 중요했잖아요. 그런데 AI가 그 부분을 대신하기 시작하면서, 이제는 "어떤 구조로, 왜 이렇게 만들어야 하는가"를 결정하는 능력이 더 중요해지고 있는 거예요. 실제로 글로벌 투자은행 모건스탠리도 AI가 개발자를 대체하기보다, 개발자의 역할이 설계와 시스템 통합 쪽으로 옮겨갈 거라고 분석했고요.
정리하면, 코딩 능력의 가치가 내려가는 만큼 설계 능력의 가치는 올라가고 있다는 건데요. 그 설계 능력의 뿌리에 있는 게 바로 객체지향이에요.
그런데 설계, 제대로 배운 적 있나요? 🫠
여기서 또 하나의 문제가 있어요. "객체지향이 중요한 건 알겠는데, 나는 그걸 제대로 배운 적이 없는데?" 하는 사람들이 정말 많다는 거예요.
자바 문법은 능숙하게 다루는데, 막상 설계를 시작하면 어디서부터 손을 대야 할지 모르겠고. 클래스와 상속을 쓰고 있긴 한데, "이게 정말 객체지향적인 코드인가?" 하는 의문이 떠나지 않고. 디자인 패턴이라는 걸 공부해봤지만, 외우기만 했지 실전에서 언제 써야 하는지 감이 안 오고.
이런 경험, 혹시 해본 적 없나요?
사실 이건 개인의 노력 부족이 아니에요. 대부분의 교재가 문법은 알려주면서 설계는 안 알려주기 때문에 생기는 문제거든요. 클래스 만드는 법, 상속 쓰는 법은 가르쳐주는데, "왜 이 구조가 좋은 구조인지", "이 클래스들의 관계를 어떻게 설계해야 나중에 변경이 쉬운지"는 다루지 않는 경우가 많아요. 도구는 쥐여줬는데 설계도를 그리는 법은 안 알려준 셈이죠.
문법과 설계 사이의 이 간극, 바이브 코딩 시대에는 더 치명적이에요. AI에게 올바른 방향을 지시하려면, 결국 내가 먼저 좋은 설계가 뭔지 알아야 하니까요.
그 간극을 메우는 책이 있어요 📘
이런 고민을 안고 있는 분들에게 『K 교수의 두 번째 객체지향 이야기』라는 책을 소개하려고 해요. 서울대와 KAIST 전산학 박사 출신 교수 두 분이 수십 년간 객체지향을 연구하고 가르쳐 온 경험을 648쪽에 녹여낸 책이에요.
이 책이 특별한 건, 문법이 아니라 '왜 이렇게 설계해야 하는가'를 알려준다는 거예요. C 코드가 자바로 진화하는 과정을 직접 보여주고, UML 설계도에서 코드로 변환하는 공식을 제시하고, 디자인 패턴을 외울 대상이 아니라 실제 문제의 해법으로 만나게 해줘요. 완성된 프로그램을 처음부터 끝까지 함께 만들면서, 나무가 아닌 숲을 보는 시야도 넓힐 수 있고요.
"코드는 누구나 작성할 수 있지만, 좋은 설계는 객체지향을 이해한 사람만이 만들 수 있다"는 저자의 말처럼, 이 책은 코드를 짜는 법이 아니라 설계하는 눈을 기르는 법을 알려주는 책이에요.

K 교수의 두 번째 객체지향 이야기
: 자바 중심으로 살펴보는 객체지향 개념, 언어, UML 설계, CASE 도구
자바를 쓴다고 객체지향은 아니다.
문법 너머의 설계를 알려주는 책.
크리에이티브 커먼즈 라이센스 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.


