[책] 도메인 주도 설계 - 에릭 에반스 / 이대엽

Domain-Driven Design의 한글판.

이대엽님이 번역했다.

 

이 책에 대한 주위 사람들의 반응은 "어렵다", "읽다 포기했다"의 의견이 많았다.

나 또한 2007년 4월에 4번 읽다가 31쪽에서 중도 포기했다.

 

오늘부터 3년만에 다시 읽었다.

 

3년전 읽을 때 포스트잇에 적어놓은 메모가 있었다.

이 책이 어렵다고 느껴지는 이유는?

도메인 주도 설계가 좋은 책이라는 것은 켄트 벡을 비롯한 유명한 분들, 그리고 많은 책에서 언급되는 레퍼런스를 보았을 때는 틀림없는 사실인 것 같다. 하지만 마이클 샌들의 정의란 무엇인가(Justice)처럼 끝까지 읽은 사람이 적다는 것에는 뭔가 이유가 있지 않을까라는 생각에서 적었던 메모인 것 같다.

 

1. 내용이 어려운 것인가?

내용자체가 어려운데에는 책이 다루는 수준이 높아서 그럴 수도 있고 쉬운 내용이지만 책 자체가 어렵게 쓰여졌을 수도 있다.

또한 번역서이다 보니 한글로 번역하는 과정에서 이해하기 어려움이 추가되었을 수도 있다.

 

책의 수준이 높다면 경력을 좀 더 쌓고 보는 등의 방법으로 결국 독자의 수준을 높히고 접근하는 것이 바람직할 것이다. 

하지만 책 자체에 문제가 있다면 다른 방법으로 접근하는 것이 좋을 것이다.

한글판의 문제라면 원서를 본다던지, 동일한 주제를 다룬 다른 책을 대안으로 선택하는 방법일 것이다.

 

GoF의 디자인 패턴은 후자에 가까운데 원서의 경우 스몰토크, C++ 등의 익숙하지 않은 코드들이 보이면서 개념에 대한 집중도가 훝어질 수 있다. 예를들어 본인이 자바언어에 익숙하다면 "Java 언어로 배우는 디자인 패턴 입문"을 본다면 원서보다 더 잘 읽을 수 있을지도 모르겠다.

---

아직 원서까지 보지는 않아서 문제의 원인에 대해서는 잘 모르겠지만 3년이 지나고 다시 읽었는데 쉽게 읽기 어렵다는 느낌은 마찬가지 인 것 같다.

 

번역이 어려운지를 보는 방법에는 두 가지 방법이 있다. 추천의 글이 하나는 마틴 파울러의 것과 조영호 님의 것이 있는데

아마 마틴 파울러의 추천사는 영어로 되어 있었을 것이고, 조영호님의 경우 처음부터 한글로 되어 있었을 것이다.

 

이 책을 읽기전 본 책이 조영호님의 오브젝트였기에 나는 이미 조영호님의 문체나 설명 스타일에 대해서는 익숙해진 상태이다.

추천사를 읽어보면 중간 중간 걸리는 부분이 있기는 한데 그렇다고 아예 골똘히 생각할 만큼 멈추는 느낌은 아니다.

 

다른 방법은 읽기 어려웠던 문장을 내가 바꾸어보는 방법이 있다. 책의 내용만으로는 한계가 있어서 원서의 문장이 어땠는지 교차 검증이 필요할 수 있다.

 

서문 (xxxi)

도메인 모델링과 설계는 뛰어난 소프트웨어 설계자들 사이에서 적어도 20년 동안 매우 중요한 주제로 인식되고 있지만 놀랍게도 뭘 해야 하고 어떻게 하는지에 관해서는 기록된 바가 거의 없다. 분명하게 드러나지는 않았지만 객체 관련 커뮤니티에서 내가 "도메인 주도 설계"라고 칭하는 하나의 철학이 나타났다.

위의 국문을 내가 번역했다면 아래와 같이 표현했을 것이다.

도메인 모델링과 설계는 뛰어난 소프트웨어 설계자들 사이에서 적어도 20년 동안 매우 중요한 주제로 인식되고 있지만 놀랍게도 뭘 해야 하고 어떻게 하는지에 관해서는 기록된 바가 거의 없다. 객체 관련 커뮤니티에서 분명하게 드러나지는 않았지만 어떤 하나의 철학이 나타났다. 나는 그것을 "도메인 주도 설계"라고 불렀다.

이것은 긴 문장을 작은 문장으로 쪼갠 것이다. 코드 비유를 들면, 긴 코드 보다는 짧은 응집성 있는 코드가 읽기 편한 것과 비슷한 이치이다.

 

복잡성이라는 도전과제(xxxiii)

관료주의, 불명확한 목표, 자원 부족 등 다양한 이유로 프로젝트가 궤도에서 이탈한다. 그러나 얼마나 복잡한 소프트웨어를 만들어 낼 수 있는가를 결정하는 주된 요인은 설계 접근법에 있다. 복잡성을 감당할 수 없다면 개발자는 더는 쉽고 안전하게 변경하거나 확장할 수 있을 만큼 소프트웨어를 파악하지 못한다. (후략)

마찬가지로 위의 국문을 내가 번역했다면 아래와 같이 표현했을 것이다.

관료주의, 불명확한 목표, 자원 부족 등 다양한 이유로 프로젝트가 궤도에서 이탈한다. 그러나 얼마나 복잡한 소프트웨어를 만들어 낼 수 있는가를 결정하는 주된 요인은 설계 접근법에 있다. 개발자가 복잡성을 감당할 수 없는 수준이 되면 소프트웨어는 더 이상 쉽고 안전하게 변경하거나 확장할 수 없게 된다.

이것은 주어와 술어의 호응이 멀어지면서 머리에 문장이 잘 읽히지 않았던 것을 바꾼 것이다.

조건문(복잡성을 감당할 수 없다면) 다음에 주어(개발자는)가 나오는데 서술어는 "파악하지 못한다"이다.

보통 ~다면 다음에 서술에는 ~일 것이다 와 같은 추측성 술어로 마무리 하게 되는데 ~한다와 같이 단정적인 표현이 오면서 뭔가 어색한 느낌이 든다.

나는 주어 술어를 억지로 일치를 시키려기 보다는 주어 자체를 사람(개발자)에서 소프트웨어로 바꾸는 것으로 완화해보았다.

 

물론 번역을 하다보면 계약에 따라 원저자가 의역을 못하는 조항이 붙거나 경우에 따라서 글자 하나까지 못바꾸게 하는 경우가 있다고 들었다. 내가 번역을 한 것도 아니고 전문 번역가도 아니기에 나의 의역이 상황에 따라서는 불가능한 상황도 있을 것이다.

하지만 독자의 입장에서 볼 때, 국문으로 번역된 원서의 경우 책임은 번역자에게 있지 않나 생각해본다.

 

그렇다고 이대엽 님의 번역을 결과물을 폄하하려는 의도는 아니다. 책에서도 "개발은 반복주기를 토대로 진행"되어야 한다고 주장하듯이 책도 실제 결과물이 나오고 나서야 진정으로 독자의 관점에서의 피드백을 받을 수 있다. 첫 술에 배부를 수 없겠지만 다시 다시 출판되고 교정이 되면서 독자가 더 읽기 쉬운 책이 될 수 있다면 원저자 에릭 에반스도 좋아하지 않을까 생각해보았다.

 

참고로 내가 읽고 있는 책은 초판(2011년 7월 21일)의 2쇄발행(2016년 5월 19일)이다.