p. 147

원문
The Builder object provides the director with an abstract interface for constructing the product.

책 번역

Builder 객체는 디렉터를 제공하고 제품을 복합하기 위해 필요한 추상 인터페이스를 정의합니다.

.....
Builder 객체는 Director 에게... 제공한다. with 이하를.. 이 맞음.

내용상으로도 builder 객체는 director 객체로부터 request를 받아서 요청받은 part를 만드는 녀석이다. 따라서 director 객체는 builder 객체에 의해서 제공될 수 있는 녀석이 아니다.

p. 148

원문
Unlike creational patterns that construct products in one shot, the Builder pattern constructs the product step by step under the director's control.

책 번역
한 번에 복합 객체를 생성하는 것처럼, 빌더 패턴은 디렉터의 통제 아래 하나씩 내부 구성 요소들을 만들어 나갑니다.

...아마, 일반적으로 creational pattern이 products를 한 번에 만들어 내는 반면, builder pattern은 단계적으로 만들어 나가는 것을 이야기하고 싶었던 것 같은데...
번역서는 조금 다르게 설명하고 있다

p. 470

원문
these are indicated with a horizontal arrow pointing to the receiving object. The name of the request is shown above the arrow.

책 번역
이것은 수신 객체를 가리키는 수평 화살표로 나타납니다. 요청의 이름은 화살표 아래에 나타납니다.

... above가 아래로 번역됨.

p. 302

번역

ConcreteHandler : 책임져야 할 행동이 있다면 스스로 요청을 처리하여 후속처리자에 접근할 수 있습니다.

원문

- handles requests it is responsible for.

- can access its successor.

- ......
 

Chain of Reponsibility에 관한 설명인데, 일반적으로 Concrete handler는 request를 처리했다면, successor에 접근할 필요는 없다.
원문은 두개를 서로 나눠서 표현했는데 번역한 사람이 합쳐버려서 다른 뜻으로 해석될 수 있게 되었다.

＜- 이 부분은 다시 책을 보니 괜찮게 설명한 것 같기도하고? 그렇다. 취향 문제일 수도 있겠다.
내 경우에는 둘이 나뉘어 있는 것이 병렬적인 요소라는 느낌이 더 강하게 전달되어 좋아보인다.

p. 437

번역

Equipment 연산은 장비의 가격을 알려주는 연산들입니다. 이 서브클래스들은 가격 정보 반환 연산을 재정의하여 특별한 장비의 가격을 처리하도록 합니다.
 

원문

The Equipment operations return the attributes of a piece of equipment, such as its power consumption and cost. Subclasses redefine these operations appropriately for specific types of equipment(e.g., a chassis, drives, and planar boards.

...
 

등등 내가 찾은 것만 한 50개는 될 것 같다. 후반으로 갈수록 이 현상은 점점 악화된다! 도저히 제 정신으로는 읽을수가 없을 정도. 살짝 읽으면 화가나고, 또 조금 읽으면 화가난다!

한 문단을 그냥 삭제해버린 경우도 있더라 p.276에서 GlyphFactory에 관한 내용이 그것. 이상한 문단이나 문장을 추가하기까지 하고...  dependent를 independent로 해석했던 경우도 있었다. 용어 하나를 다른 한글 표현으로 사용하기도 하고... 이런 것들이 한 두개씩만 존재하는 것이 아니다.
덕분에 '김정아' 이름 석자가 내 기억 속에서 사라지지 않을 것 같다.

내가 한글책으로 한 번 보고 원서로도 한 번 보는 공부를 하지 않았다면 발견하지 못하고 넘어갔을 내용들이다.

물론 번역하신 분의 노고에는 감사하다. 하지만, 번역하신 분은 이것으로 돈을 벌고 있지 않은가?  내가 그냥 책을 받은 것이라면 이해하겠다. 구매자인 나의 입장에서는 '제대로' 된 번역서로 빠르게 먼저 읽고 싶은 마음에서 구매한 것이다.


아아.... 몇 번을 배신 당한 것인지 모르겠다. 지치는 책이다.
 

2021.12.20 추가
 

지금와서는 이런 생각이 든다.
나는 어찌되었던 원서와 함께 보면서 결국 이 책을 '다' 읽었다.
책에 이상하다 싶은 부분을 새로 책에 적어 넣어서 내 책을 만들었다.
그 말은 어떻게든 도움이 되었다는 것이 아닐까?

그러면... 이렇게 권장하고 싶다. 원서와 함께 읽으시라.
틀렸다 싶은 부분을 보게 되면 오히려 이건 이러이러해서 오히려 이게 맞는 게 아닌가? 하면서 더 고민하게되고, 책을 번역한 사람과 토론을 하고 있는 것 같았다.
이게 맞지 않나? 하면서 책과 대화했던 것 같다.
짜증은 났지만(많이), 더 공부할 수 있는 길이 열릴지도 모른다.
더 비판적으로 내용을 바라볼 수 있다. 어떤 글을 읽어도 이 책이 맞는 말을 하고 있는 걸까? 의심하게 된다.

그런 측면에서 이 책은 더 좋은 책이고 더 재미있는 책일지도 모르겠다. 더 고민하면서 오히려 디자인 패턴이 기억 속에 잘 남았던 것 같다. 그렇게 생각하면 오히려 즐겁게 읽을 수 있을 것 같다.


처음에는 읽는 데 화가 좀 났을 뿐이지..(많이) 그래. 누구나 실수를 할 수 있지 않은가.
당장 나조차도 이렇게 올린 글에 틀린 부분이 수두룩 할 수 있다.
하지만, 내가 시간이 없고, 제대로 된 정보를 한글로 빠르게 보고 싶다.
라는 측면에서는....
그리고... 번역하신 분이 "그거야! 내가 그걸 의도한 거였어!!!" 라고 한다면... 나는 분노할 것 같긴 하다. (많이)
그래서 좋은 점수는 줄 수 없겠다. 따라서 점수는 바꾸지 않기로 결정했다.

GoF의 디자인 패턴 [번역본 ver 0.x] 정도면 좀 더 좋은 제목이 아닐까? 그럼 화도 덜 났을텐데 말이다.

소프트웨어 설계 및 디자인 패턴의 공부를 처음에 이 책으로 시작하는 것은 좋지 않은 것 같습니다. 물론 워낙에 유명한 책이고 책의 내용이 좋을 수는 있지만, 입문자에게는 맞지 않는 책인 것 같습니다.   최근에는 파이썬을 기반으로 소프트웨어 설계 및 디자인 패턴 등의 내용을 설명하는 책들도 있는 것 같은데, 현재 보인이 주로 개발에 사용하는 언어를 중심으로 예제를 포함하여 개념 설명이 같이 잘 되어 있는 책들을 먼저 보고나서 보는 것이 좋을 것 같습니다. 

디자인 패턴이란 쉽게 말해서 소프트웨어 설계를 하다보면 자주 마주치는 설계 유형을 모아서 이름을 짓고, 언제 활용할 수 있고 어떻게 활용할 수 있는지 모아둔 문제집? 같다고 할 수 있습니다.

이 문제집을 보면 프로그램 설계 문제를 잘 푸는데도 물론 도움이 됩니다. 그리고 개발자들과 의사소통 할 때 특히 유용합니다. 구태의연하게 '이렇게 저렇게 구현하면 어떨까요?' 라고 하는것보다 'A에서는 옵저버패턴 사용하고, B에서는 필터&파이프패턴 사용하는게 어떨까요?' 라고 말하는 식이죠.

그래서 팀원과의 원활한 의사소통을 위해서나, 당면한 설계 문제를 원활히 해결할 수 있기 위해서 개발자들이 꼭 읽어봐야할 책입니다.