Comming Soon

K 교수의 두 번째 객체지향 이야기 [자바 중심으로 살펴보는 객체지향 개념, 언어, UML 설계, CASE 도구]

  • 지은이김태균, 조장우
  • ISBN : 9791194409700
  • 45,000원
  • 2026년 07월 29일 펴냄
  • 페이퍼백 | 648쪽 | 188*250mm
  • 시리즈 : 프로그래밍 언어

책 소개

책 소개

"코드는 누구나 작성할 수 있다.
하지만 좋은 설계는 객체지향을 이해한 사람만이 만들 수 있다!"
수십 년 동안 소프트웨어 개발을 이끌어 온 객체지향의 본질과 실천법을 담은 결정판

많은 개발자가 객체지향 언어를 사용한다. 그러나 정작 객체지향이 무엇인지, 왜 객체지향적으로 설계해야 하는지 명확하게 설명할 수 있는 사람은 많지 않다. 클래스와 상속을 사용하는 것만으로는 객체지향 개발이라 할 수 없다. 진정한 객체지향은 복잡한 현실 세계를 모델링하고, 변화에 유연하게 대응할 수 있는 구조를 설계하는 데서 시작된다.

이 책은 객체지향의 탄생 배경과 철학부터 객체 모델링, UML 설계, 구현 기법까지 객체지향 개발의 핵심 과정을 체계적으로 설명한다. 단순히 개념을 나열하는 데 그치지 않고, 구조적 프로그래밍에서 객체지향으로 진화하는 과정을 실행 가능한 코드와 함께 생생하게 보여 준다.

객체지향 설계를 본격적으로 고민하는 학생에게는 탄탄한 지침서가 되고, 설계 역량을 키우고 싶은 개발자에게는 객체지향의 본질을 다시 돌아보게 만드는 안내서가 될 것이다.

출판사 서평

문법을 넘어 소프트웨어가 유연해지는 진짜 설계를 만나다
30년의 탐구와 통찰이 담긴 가장 솔직하고 정교한 객체지향 안내서

문법은 배웠다. 그런데 왜 설계는 여전히 막막할까?
자바나 C++ 문법은 능숙하게 다루는데, 왜 내 코드는 구조적 프로그래밍에 갇혀 있을까? 문법은 도구일 뿐, 도구를 다루는 것과 유연한 구조를 설계하는 것은 전혀 다른 영역이기 때문이다. 이 책은 단순한 API 사용법이나 추상적인 이론을 늘어놓지 않는다. 코드가 진화하는 과정 자체로 설계가 왜 필요한지 보여 준다. 고급 기술과 디자인 패턴도 외울 대상이 아니라 설계 문제의 해법으로 자연스럽게 만나게 된다.

이 책은 절대 편법이나 지름길을 말하지 않는다.
"동적 할당과 포인터라는 용어를 처음 접하는 사람은 당장 이 책을 덮어야 한다." 저자는 시작부터 타협 없는 경고를 던진다. 얄팍한 요령 대신 컴퓨터 과학의 탄탄한 기초 체력을 요구하는 정공법을 택했기 때문이다. 객체지향을 온전히 이해하는 과정은 험난한 설악산을 등반하는 것과 같다. 안개에 가려 전방 100미터만 보이는 고단한 고개를 끈기 있게 넘어야 한다. 그러나 마침내 정상에 올라서는 순간, 막혔던 시야가 트이며 세상을 완전히 새로운 객체의 눈으로 바라보는 지적 희열을 맛보게 된다. 이 책은 그 정상으로 가는 가장 정직한 길을 안내한다.

저자/역자 소개

지은이 소개

김태균
서울대학교 전산학 박사
전 부산외국어대학교 컴퓨터공학과 교수

조장우
KAIST 전산학 박사
현 동아대학교 소프트웨어대학 교수

지은이의 말

저자가 객체지향이라는 용어를 처음 접한 지 벌써 30년이라는 세월이 흘렀다. 10년이면 강산도 변한다는데 강산이 세 번이나 바뀌었을 기간에 객체지향에 관한 저자의 지식이 그리 많이 향상되지 않은 점이 부끄러울 따름이다. 저자의 얕은 지식에도 불구하고 이 도서를 통해 객체지향의 패러다임을 정리해 보고자 하는 시도를 독자들이 너그럽게 이해해 주기 바란다.

1980년대 중반에 프로그래밍 언어론을 공부하다가 우연히 마주친 스몰토크(Smalltalk)라는 객체지향 언어의 경이로움은 아직도 저자의 머리에 생생한 충격으로 남아있다. 스몰토크 언어의 기이한 문법과 어의는 도서의 지면에서나 접할 수 있는 개발 플랫폼 화면의 신기함과 어우러져서 저자가 깊은 좌절감에 빠지게 한 바가 있다. 그런데 드디어 객체지향이라는 용어에 대한 궁금증을 해소할 기회가 1990년에 찾아왔다. 도서를 통해 살짝 접할 수 있었던 C++ 언어의 활용법에 궁금해 하던 차에 저자의 학과에서 C++ 컴파일러를 구매한 것이다. 이때부터 시작됐던 20여 년 동안의 객체지향에 대한 탐구생활은 저자의 인생에서 가장 보람찬 기간이었다. 저자가 1990년 이후로 시도했던 C++, 자바를 이용한 몇몇 윈도 기반 애플리케이션의 구현 작업과 OMT, UML 방법론의 적용 경험은 많은 시행착오와 자기성찰을 통해 객체지향 패러다임의 실체를 이해할 수 있게 하는 계기가 됐다.

소프트웨어 공학에 대한 전반적인 통찰력과 각종 언어에 대한 경험이 매우 풍부한데도 저자가 객체지향 패러다임의 실체를 이해하고 정확히 적용하기 위해 많은 어려움을 겪지 않을 수 없었다. 지금 돌이켜보건대 그 이유는 객체지향에 대한 접근을 체계적으로 유도하는 도서가 부족했기 때문이다. 2000년대 초반까지 국내에서 찾아볼 수 있는 객체지향 관련 서적은 주로 객체지향 언어에 관한 것들이었다. 물론 요즘에는 내로라하는 전문가들이 객체지향과 관련한 좋은 도서를 저술하고 있지만 2000년대 초반까지만 하더라도 언어뿐 아니라 방법론 관점, 소프트웨어 공학적 관점, 그리고 철학적인 관점들을 종합적으로 다루는 서적이 절대적으로 부족했다. 객체지향 패러다임에 대한 총괄적인 지식 없이 단순히 객체지향 언어에 대한 지식만을 밑천으로 소프트웨어 개발을 시도했던 저자는 결국 좌충우돌식의 탐구생활과 시행착오를 겪을 수밖에 없었다. 저자의 경험으로 볼 때 저자가 겪은 시행착오는 아마도 객체지향을 이해하려고 하는, 혹은 이해한 모든 사람이 겪을 수밖에 없었던 어려움이라 할 수 있다. 한편으로 개발자 본인이 직접 겪는 시행착오는 개발자의 지식을 굳건히 해주는 자산이라고 할 수 있지만 다른 한편으로는 시행착오로 인한 고통과 인적 자원의 낭비는 실무에서 최대한 피해야 하는 난제가 아니라 할 수 없다. 결론적으로 이 도서를 집필하는 저자의 목적은 여러분이 겪을 산고를 최대한 줄이고자 하는 것이다.

우선 이 도서를 사들이고자 하는 예비 독자에 대한 주의 사항을 짚고 넘어가겠다. 일단 C 언어가 무엇인지 모르는 독자는 무조건 책을 덮기 바란다. 이 책이 프로그래밍 언어 입문서가 아니기 때문이다. C 언어를 배운 경우라도 포인터, 구조체, 동적 할당에 대한 이해가 부족하다고 생각되면 절대로 이 책을 읽지 말기 바란다. 이 책은 포인터, 구조체, 동적 할당에 대한 이해를 전제로 스토리를 이어 나가기 때문이다. 결국 C 언어에 대한 완벽한 이해가 있어야만 이 책을 읽었을 때 도움이 될 수 있다. 이 책을 읽기에 가장 적당한 수준의 독자는 C 언어를 완벽히 알고, 자료구조를 어느 정도 이해하며, 자바나 C++ 언어에 대한 입문서를 읽어본 후에 객체지향 과제 개발을 염두에 두고 있는 사람들이다.

'왜' 객체지향 패러다임을 마스터해야 하는가 생각해 보자. 그 이유는 간단하다. 소프트웨어의 개발과 유지 보수에 들이는 노력의 결과를 최대화하기 위한 것이다. 사실 요즘의 소프트웨어 개발은 객체지향 언어를 기반으로 이뤄지고 있기 때문에 개발자들이 C 언어와 같은 구조적 언어를 이용한 개발 환경에서 겪는 어려움을 느낄 기회가 적다. 물론 하드웨어에 임베디드된 소프트웨어의 개발과 같은 작업 환경에서는 아직도 C 언어가 차지하는 비중이 크기도 하지만 전반적으로 객체지향 기술로 인해 작업 환경이 좋아졌다고 볼 수 있다. 문제는 훌륭한 작업 환경이 훌륭한 제품을 보장하지 못한다는 것이다. 즉, 훌륭한 작업 환경은 훌륭한 제품 생산을 위한 필요조건이지 충분조건은 아니라는 것이다. 아무리 좋은 도구가 제공된다고 하더라도 그 도구를 자유자재로 다룰 수 있는 장인의 솜씨가 없으면 무용지물 아니겠는가? 객체지향과 관련된 개발 현실이 이와 유사한 사례가 많다. 자바나 C++가 단순히 C 언어의 대용으로 구현된 과제가 얼마나 많은가? 상속과 동적 바인딩. 다형 개념을 올바로 적용하지 못하고 C 언어로 구현할 때의 마음가짐으로 구현한 코드가 얼마나 많은가? 정말로 심각한 문제는 개발자 본인이 자기가 작성한 C++ 혹은 자바 코드가 전혀 객체지향의 특성을 반영하지 못하고 있기 때문에 생산성 향상과 유지 보수성 향상에 도움을 주지 못하고 있다는 사실을 깨닫지 못하는 상황이다. 즉, 자바로 구현했다고 해서 혹은 C++로 구현했다고 해서 이들이 모두 객체지향 시스템은 아니라는 것이 저자가 보는 문제의 본질이며, 진정한 객체지향 시스템의 구현이 어떠한 형태로 이뤄지는가를 보여주고자 하는 것이 저자의 집필 의도다.

객체지향 패러다임에 대한 이해는 마치 설악산과 같이 험한 산을 등반하는 것과 같다. 우리는 산의 중턱을 걷는 동안에 명산의 일부 경치만 볼 수 있을 뿐이다. 더욱이 그 경치들은 이미 입산을 할 때부터 엇비슷하며 큰 즐거움을 주지 못한다. 하물며 계속 올라가는 것은 얼마나 괴로운 일인가? 특히 초행일 때에는 그 고통이 엄청날 수밖에 없다. 그러나 정상에 올라섰을 때의 희열은 평생의 기억으로 남게 될 것이다. 저자가 객체지향의 험난한 산을 정복했을 때의 느낌이 바로 그런 것이었다. 객체지향의 정상에서 보면 모든 것이 보인다. 산 중턱에서는 단지 전방 100미터 내외의 길만 보이지만 정상에 올라서면 모든 길이 보이게 된다. 그 위에서 우리는 C 언어를 벗어버리고 객체지향 언어로 갈아입을 수밖에 없다. 그 위에서 구조적 기법을 버리고 객체지향 기법을 선택하지 않을 수 없다. 마치 도가 트이듯이 새로운 사고방식과 자세로 소프트웨어를 바라보게 되는 것이다. 아무쪼록 이 책을 통해 객체지향이라는 험한 산을 정복하고자 하는 독자들이 좀 더 빨리 그리고 정확하게 이 산을 정복할 수 있기를 희망한다.

이 책에서 다룰 내용을 소개하기 이전에 이 책의 특징을 먼저 짚고 넘어가게 하겠다. 이 책의 첫 번째 특징은 자바로 작성된 예제 코드가 많이 수록돼 있다는 것이다. 프로그래밍 언어를 위한 입문서나 특정 플랫폼을 위한 사용자 매뉴얼의 경우에는 상세한 구현 코드가 사용 예제로 당연히 포함된다. 반면에 추상적인 개념을 설명하는 이론 서적의 경우에는 일반적으로 사용 예제 코드가 포함되는 경우가 없다. 따라서 이론 서적에서는 두리뭉실한 이론과 학설만이 제시되고 구체적인 예제가 부족함으로 인해 정확한 이해를 어렵게 하는 경우가 많다. 이런 점을 고려해 이 책에서는 실행할 수 있는 예제 프로그램을 다수 포함함으로써 이론서가 갖는 모호성을 줄이려고 노력했다. 예제 프로그램은 대부분 자바로 작성됐으며 몇몇 경우에만 비교를 위해 C++로 작성됐다. 자바를 선택한 이유는 객체지향 언어의 대표 주자인 C++ 코드가 나름대로 장점도 있고 영향력이 크기도 하지만 C++의 태생적인 한계로 인해 문제점이 많기 때문이다. 간단히 말해 자바는 중천에 떠 있는 태양인 반면에 C++는 석양에 지는 해라고 볼 수 있다. 특히 2장에서는 자바의 특성을 요약해 봄으로써 자바에 익숙하지 않은 독자의 이해를 돕게 조치했다. 두 번째 특징은 객체지향 패러다임과 관련된 내용 중에서 주로 설계와 구현을 중점적으로 다뤘다는 것이다. 그 이유는 소프트웨어 개발 시에 프로그래머가 구체적으로 사용할 수 있는 실용적인 지식을 전달하기 위함이다. 전체 개발 공정에서 시스템 분석이 차지하는 비중도 중요하기는 하지만 저자의 경험 부족과 분석 과정 설명의 모호성으로 인해 분석에 관한 내용은 생략했다. 분석과 관련된 내용이 부족한 점에 대해서는 독자의 이해를 바라며, 분석에 대해서는 다른 문헌 참고하기를 바란다. 분석과 관련된 내용의 부재에도 불구하고 객체지향 개발 공정이 상향식 과정이라는 점에 비춰 볼 때 이 책에서 다루는 내용은 독자의 개발 능력을 향상하는 데 충분히 도움이 될 것이라고 확신한다. 마지막 특징은 이 책의 내용을 기술하는 과정에서 충분히 많은 보충 설명과 쉬운 용어를 사용했다는 것이다. 또한 문장의 중간 중간에 유머러스(humorous)한 내용을 첨가함으로써 지루함을 덜고자 노력했다. 이러한 내용 전개는 이해를 돕기 위함이다. 한편으로는 책의 내용이 저자의 주관에 너무 영향을 받아 학계에서 공인되지 않은 주장이 기술돼 있을 수도 있다. 이런 부분은 잘 선별해서 이해해야 하기를 부탁한다. 이 책은 번역서가 아니기 때문에 이러한 서술이 가능하며, 아무쪼록 독자의 마음에 들지 않더라도 양해해 주기를 바란다.

이 책의 구성을 간단히 설명하도록 하겠다. 1장에서는 객체지향의 역사를 다룬다. 새로운 분야의 지식을 이해하려면 그와 관련된 역사적 사건들을 이해할 필요가 있다. 역사를 살펴봄으로써 어떠한 방식으로 그 분야에 대한 전문가의 노력이 투입됐는가를 알 수 있고 또한 관심의 초점이 어떻게 변해 왔는가를 알 수 있다. 소프트웨어 공학의 관점에서, 객체지향 언어의 관점에서, 그리고 방법론과 도구의 관점에서 이 분야의 개척자들이 이뤄놓은 업적을 이해함으로써 객체지향 패러다임이 지향하는 근본적인 목적을 인식할 수 있다.

2장에서는 C 언어와 자바를 다룬다. 객체지향 패러다임을 다루는 책에서 뚱딴지같이 왜 C 언어를 언급하느냐고 의문을 제기할 독자가 있을 것이다. 이런 의문은 2장의 내용을 읽어보면 이해가 될 것이다. 스트롭스트룹이 C++ 언어의 전신으로 개발했던 첫 번째 객체지향 언어의 이름이 "C with Data Abstraction"이라는 점에서 볼 때 C 언어는 객체지향 언어와 공유하는 문법과 어의를 갖고 있다. 필드에서 일을 하는 개발자들이야 당연히 C 언어를 마스터했겠지만 그렇지 않은 학생이나 초보자들은 C 언어를 정확히 사용하는 법을 모르는 경우가 다반사이다. C 언어의 부정확한 사용은 객체지향 언어를 이해하는 데 걸림돌로 작용하게 되기 때문에 2장에서 객체지향 언어를 습득하기 위한 C 언어의 필수 지식을 전달하고자 한다. 2장의 내용을 통해 잘 짜여진 C 프로그램이 얼마나 부드럽게 자바 프로그램으로 변신할 수 있는가를 이해할 수 있게 될 것이다.

3장에서는 객체지향 패러다임의 기본 원리를 다룬다. 객체지향 패러다임은 소프트웨어 개발 시에 실세계 사물을 파악하는 관점의 변화를 요구한다. 객체지향은 특정 프로그래밍 언어나 특정 방법론에 얽매이지 않는 보편적 철학으로, 실제의 사물을 어떠한 방식으로 해석할 것인가에 대한 지침이다. 이에 대한 이해를 분명히 하지 않고서는 아무리 좋은 객체지향 언어여도 제 역할을 할 수 없다. 또한 객체지향 원리의 중요한 요소인 자료 추상화, 상속, 동적 바인딩, 다형 개념 등의 의미와 활용 방법을 기술한다. 3장의 내용은 철학적 관점에서 이 책의 가장 중요한 부분이다.

4장에서는 객체지향 언어의 기본 원리 외에 객체지향 언어에서 추가로 도입된 기술과 제도를 기술한다. 이 장에서 다루는 내용은 인터페이스, 추상 클래스, 예외 처리 기능, 시리얼라이제이션, 리플렉션, RMI, 디자인 패턴 등이다. 이들은 객체지향 언어를 사용할 때 반드시 이용돼야 할 중요한 기술로, 자바 예제와 함께 자세히 소개된다. 이들 기술은 C 언어와 같은 구조적 언어에서는 상상할 수 없었던 획기적인 기술이며, 이를 통해 개발자는 시스템 개발 시에 좀 더 다양한 선택의 폭을 갖게 된다. 4장의 내용은 주로 자바 예제를 통해 설명이 이뤄지기 때문에 자바를 좀 더 자세히 습득하는 기회가 될 것이다.

5장에서는 3장에서 다뤘던 객체지향의 기본 원리를 구체적으로 적용하는 방법을 다룬다. 아무리 훌륭한 이론이라도 그 이론을 실용적으로 적용할 수 있는 구체적인 방법이 제시되지 않으면 그 이론을 처음 접하는 초보자에게는 그림의 떡으로 비칠 수밖에 없다. 저자도 과거에 이론 서적을 독파하는 과정에서 구체적인 사례 부족으로 인한 어려움을 여러 번 겪은 바가 있다. 이러한 경험을 바탕으로 이론 서적의 문제점을 보완하고자 하는 차원에서 서술한 내용이 5장의 내용이다.

6장에서는 객체지향 방법론을 설명한다. 소프트웨어 개발을 처음 접하는 초보자의 측면에서 볼 때 가장 중요해 보이는 것이 객체지향 언어일 것 같지만 실제는 그렇지 않다. 객체지향 개념이 주는 최고의 가치는 소프트웨어를 개발할 때 어떠한 방식으로 시스템을 엮어 구축할 것인가에 대한 지침을 제공하는 것이다. 마치 하드웨어를 만들 때 기존에 만들어진 부품을 엮어 새로운 시스템을 구현하듯이 소프트웨어도 재사용을 통해 시스템을 만들어 보자는 것이 객체지향의 주된 목적이다. 객체지향 방법론은 문제에 대한 이해 및 솔루션 습득을 위한 체계적인 작업 지침을 제시한다. 이 장에서는 OMG(Object Management Group)에 의해 표준화된 객체지향 기법으로 선정된 UML(Unified Modeling Language) 방법론을 자세히 알아본다.

7장에서 다룰 내용은 객체지향 구현에 관한 것이다. 이 장에서는 객체지향 개념에 의한 사물의 이해가 어떠한 방식으로 객체지향 언어로 반영되는가를 보여준다. 특히 똑같은 목적의 프로그램을 자바와 C++로 작성한 예를 보임으로써 객체지향 원리를 적용한 프로그램의 스타일이 특정 언어와 관계없이 대동소이함을 확인시켜 줄 것이다. 이 장에서 제시되는 예제 프로그램은 이 책에서 다룬 여러 가지 내용을 아우르는 구체적 사례로, 이론적인 내용이 구체화하는 코딩 스타일을 보여주는 것이 목적이다. 아울러 이 장에서는 몇몇 객체지향 언어에 대한 소개도 있을 것이다. 이 장의 내용을 읽는 독자들은 객체지향 언어들의 문법적 차이가 별로 중요하지 않으며 객체지향 원리를 구현할 때 적용하는 능력이 훨씬 중요하다는 사실을 깨우치게 될 것이다.

8장에서는 객체지향 CASE 도구인 OODesigner의 사용법을 다룬다. 저자는 2000년경에 CASE 도구인 OODesigner를 개발해 퍼블릭 도메인(public domain)에 공개한 바 있다. OODesigner는 유닉스 버전, 자바 버전, PC 버전으로 구현된 바 있는데, 그중에서 가장 실용성이 있는 것은 PC 버전이다. 8장에서는 PC 버전의 사용법을 간단히 설명한다. 이 책에 포함된 모든 그림은 OODesigner로 작성된 것이다. 이러한 점에서 독자들은 도구의 활용 가능성을 짐작할 수 있을 것이다. 소프트웨어 생산성 향상을 위해서는 CASE 도구의 사용이 필요하다. 독자들도 언젠가는 실무에서 CASE 도구의 사용을 경험하게 될 시점이 있을 것이다. 현재 시점에서 볼 때 OODesigner의 성능이 최신 도구에 비해 매우 부족하다고 하더라도 OODesigner를 통해 상업적인 CASE 도구의 활용 방법을 예상할 수 있게 될 것이며, 이 도구에 대한 이해를 통해 좀 더 객체지향에 친숙해질 수 있을 것이다.

요즘 IT 업계에서 각광받고 있는 최신 기술로 손꼽을 수 있는 내용은 컴포넌트 기술(Component Technology)이다. 이는 2000년 이후로 관심의 초점이 되는 기술로서 DCOM(Distributed Component Object Model), EJB(Enterprise Java Beans), CORBA(Common Object Request Broker Architecture)라는 이름으로 우리 앞에 다가서고 있다. 객체지향 기술이 추구하는 최종 목표가 재사용을 최대화함으로써 소프트웨어의 개발 시에 하드웨어 조립 기술을 적용하자는 것이라는 점이라고 볼 때 컴포넌트 기술은 이를 구체화하기 위한 최신 기술이라 할 수 있다. 컴포넌트 기술 이전에 재사용은 소스코드 단위로 이뤄진다는 것이 한계였다. 즉, 소프트웨어의 재사용을 위해서는 재사용하고자 하는 소스코드의 기능을 이해하고 그 코드를 반드시 링크해야 하기 때문에 개발자에게 큰 부담이 됐다. 컴포넌트 기술은 재사용하고자 하는 소프트웨어를 바이너리 코드(binary code) 단위로 재사용하기 때문에 하드웨어 조립 방식을 흉내 낼 수 있게 한다. 컴포넌트 기술의 출발점이 되는 원리는 객체지향 개념이다. 독자들은 이 책에서 기술된 객체지향과 관련한 지식을 습득한 이후에 컴포넌트 기술을 이해하기 위해 노력하는 것이 바람직할 것이다.

이 책의 내용은 객체지향에 관한 모든 문제의 해답이 절대로 아니다. 이 책은 단지 객체지향 패러다임을 구성하는 이론적이고 실무적인 기본 지식을 정리한 것일 뿐이다. 따라서 한편으로는 이 책에서 거론된 내용이 객체지향에 대해 주마간산 식으로 훑기 때문에 깊이가 없다는 비난을 받을 여지도 없지 않다. 이러한 점에서 저자가 권하는 조언은 이 책에서 부족하게 다룬 내용을 독자 스스로 깨우치고 부족한 부분에 대한 좀 더 세부적인 지식은 다른 문헌을 통해 얻을 수 있는 역량을 키우라는 것이다. 결론적으로 이 책은 설악산을 오르기 위한 개략적인 지도일 뿐이며 더 빨리 올라가기 위한 노력은 여러분 스스로 기울여야 한다.

자, 그럼 지금부터 객체지향 패러다임을 이해하기 위한 여행을 떠나 보자.

목차

목차
  • 지은이 소개
  • 지은이의 말

  • 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 도구

       자바를 쓴다고 객체지향은 아니다.
       문법 너머의 설계를 알려주는 책.

     저자: 김태균, 조장우  |  페이지: 648쪽  |  정가: 45,000원  |  출간일: 2026년 7월 29일

     📖 지금 읽으러 가기
     교보문고 |  예스24  |  알라딘



바이브 코딩 시대, 코드를 짜는 건 AI에게 맡기더라도 설계하는 눈만큼은 내가 가져야 하잖아요.
그 첫걸음이 궁금하다면, 이 책에서 시작해 보는 건 어떨까요?


CC

크리에이티브 커먼즈 라이센스 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

도서 오류 신고

도서 오류 신고

에이콘출판사에 관심을 가져 주셔서 고맙습니다. 도서의 오탈자 정보를 알려주시면 다음 개정판 인쇄 시 반영하겠습니다.

오탈자 정보는 다음과 같이 입력해 주시면 됩니다.

(예시) p.100 아래에서 3행 : '몇일'동안 -> 며칠동안