객체 모델링 공부하게 책 하나 추천해주세요

역사는 반복된다. 올해도 어김없이 그 패턴이 돌아왔다.
OOO 공부하게 책 하나 추천해주세요.
이틀 전에 즉흥적으로 답했던 내용을 글로 쓰면서 더 많은 분에게 전달을 시도한다.

결론부터 말하면

세 권을 추천했다.
  • 도메인 주도 설계이하 DDD중에서 빌딩 블록 관련 내용
  • UML을 활용한 객체지향 분석 설계 중에서 1부 개념
  • UML, 실전에서는 이것만 쓴다
DDD 책을 추천한 이유는 10년이 훨씬 지난 내용이지만 아직도 생생하게 쓰이고 있다는 점이다. 또한, 그 중에서 중에서 빌딩 블록으로 추린 이유는 실제 구현과 연결지으면 실효가 높기 때문이다. 두번째 언급한 UML을 활용한 객체지향 분석 설계는 UML의 아버지로 불리는 원로 Grady Booch의 책이고, 3판까지 나올 정도로 고전이다. 필자가 역자와 지인 관계라서 1부만 읽었는데, Grady Booch의 명성이 드러나는 아름다운 설명이라고 느꼈다. 단, 개념 잡기는 좋으나 실제 구현과 연결짓는 일에는 신통치 않다.
세번째 책은 UML 표기법을 요즘 공부한다면 뭘로 해야 할까 할 때 떠올린 책이다 . 두 권 정도가 떠오르는데, 하나는 이미 언급한 UML을 활용한 객체지향 분석 설계 5장 표기를 읽는 방법이고, 다른 하나는 UML, 실전에서는 이것만 쓴다 가 아닐까 싶었다. 그러나, 필자가 UML, 실전에서는 이것만 쓴다를 읽어본 것은 아니고, 그저 평판으로 '꼭 추천해야 한다면'이란 단서를 달았을 경우의 선택이다.

20년이 지난 지식의 기록

모델링[1] 자체를 알려주는 책이 있는지는 모르겠다. 방법을 제안한 책은 많은데, 문제는 대략 20년전에 번성했고 이후로 발전이 별로 없다는 점이다. 당시 현황을 짐작할 수 있는 그림 한장을 위키피디아에서 흔적을 찾을 수 있다.
presentation
객체지향 방법론과 표기법의 역사
위 그림을 보면 2005년 UML 버전은 2.0으로 바뀌었다. 사람이 소프트웨어에 대한 자기 생각을 표현할 도구로 쓸 때 UML은 1.4에서 거의 완성되었다. 따라서, 2000년 즈음해서는 책도 많았고, 배울 수 있는 문서나 교육등 지식체가 많았다. 하지만, 필자의 직업 생활 범주 안에서DDD 책 이후에 특별히 객체 지향 모델링에 대해 큰 영향을 끼친 책은 기억하지 못한다.

여하튼 배워야 한다면?

철 지난 책 세 권이 꽃 길을 만들어줄리는 없다. 마이크로 서비스 공부에 대해 이야기할 때 했던 이야기의 반복일 수도 있겠지만, 학습자 스스로 소화한 결과물을 확인하며 한발씩 나아가야 한다. 그래서, 내 판단 중에 무엇이 쓸모가 있고, 어떤 것에 부족함이 있는지 알아서 채워가야 한다. 그리고, 실전에서 써먹으려면 전에도 말했다시피 난관에 부딪힐 때 핵심만 살리기 신공을 익혀야 한다. 어차피 우리 삶이란 시간과 자원 제약 하에서 실행되어야 하니까.

함께 하면 좋다

유투브 강좌 스타 백기선님의 자기 개발 노하우도 (그룹) 스터디라고 했다. 필자는 요즘은 책도 원격으로 함께 읽는 중인 터라 서로 엮는 것이 습관이 되어서 DDD에 관심을 보이던 사무실내 다른 동료를 기억해냈다. 그 친구에게 제안하면서 몇 가지 배운 바가 있어 공유한다.
필자: 객체지향 모델링 공부해야 한다고 해서 OO님에게 DDD 책 추천해줬는데, 같이 읽는건 어때? (동시에 그 친구 책상을 봤더니 DDD 책이 아니라 도메인 주도 설계 구현이었다.) 동료: ... 저는 주로 Bounded Context에 대해서 보는데요.
여기서 배운 바는 범위를 좁혀서 학습하는 방법이 효과를 얻기 유리할 것이라는 추정이다. 답한 동료는 시스템간 데이터 교환을 주로 다루고 있기 때문에 Bounded Context에 초점을 두는 태도는 매우 적절한 일로 평가할 수 있다. 반면, 객체지향 모델링은 목표를 분명히 하지 않을 경우 매우 포괄적인 범위라서 초점이 흐려질 우려가 있다.
아무튼 결정은 각자의 몫이고, 함께 하면 좋다는 생각에 이 글을 써서 생각을 더 면밀하게 남기고 나눈다.

Popit에서 찾을 수 있는 글

글 쓰는 과정에서 찾아 보니 필자가 모델링에 대해 다룬 내용들은 꽤나 있었다. 뜨끈뜨끈한 최신작 상품 정보 관리 라이브사이클 정의은 물리적 데이터 보관/편집 단위와 논리적 관리 단위의 대응 관계를 다룬 글로 모델링 관점 으로 굳이 분류해보면 중급(advanced)에 해당한다고 하겠다. 비슷하게 모델링 중급 글로 볼 수 있는 글은 몇 개 더 있다.
  • 상태 모델링은 언제 필요한지를 보여주는 글
  • 문제와 이미 정의한 해결책을 대강 대응시켜보는 모델링
  • 프로그램 혹은 객체의 책임을 유사한 덩어리를 묶어보는 모듈화(모델링), 사례 2
  • 모델 결과 요소와 코드의 연결을 다룬 글
  • BoundedContext의 실전 쓰임새를 다룬 글 (BoundedContext 개념 소개)
  • 다형성에 대한 설명
모델링 방법 자체에 대해 소견을 밝힌 글도 있다.
  • UML 모델 그릴 필요가 있을까?
앞서 중급을 언급했으니 초급도 있어야 구색이 맞는데, 다행히 모델링 초급 글도 있다. :)
  • 어느 중국 개발자의 모델링 시작하기
  • 구조 모델링 예제(두레이 서비스 대상)

객체란 무엇인가?

마무리는 요즘 유행하는 '~란 무엇인가?' 패러디이다. 스스로 꼭 물어볼 필요가 있다. 먼저 이런 질문을 해봐야 한다.
내가 배우려는 객체란 무엇인가? 그걸 배워서 뭘 하길 바라나? 배우기 전인 지금은 못하는 것인가?
그리고, 20년전 필자가 모델링을 공부할 때 기억을 떠올려 보며 기억나는 핵심적인 지침 몇 개를 남겨본다.
  • 구조 모델링행위 모델링으로 검증하라. (반대도 가능)
  • 인스턴스와 클래스 대응 관점을 개발하라.
  • 클래스를 정의할 때는 가급적(혹은 반드시) 인스턴스를 만들어 보면서 한다.

주석

[1] 모델링을 어떤 문제를 선택적으로 추상화하고 구체화하는 결정하고, 그 내용을 표현하는 행위라고 정의하면 인간 지적활동을 상당부분이 그에 해당한다. 그래서, 그걸 책 한 권으로 배울 수는 없을 것이라 생각한다.