소프트웨어 아키텍처의 필요성을 느끼고 있는 터에 참으로 고대하던 책이었습니다.

'소프트웨어 아키텍처' 말은 많았지만 정작 참고할 만한 책(한글판)이 없었지요.

이미 원서를 가지고 있었지만, 짧은 영어실력에 두꺼움과 빽빽한 영어에 질려 책장에 고이 모셔두기를 수개월, 드디어 번역서가 나왔네요.

오늘 받아 1장까지 자세하게 읽어 보았습니다.

그런데 읽다가 내용이 너무 이상한 부분이 많아 원문과 비교를 해보았습니다.

영어실력은 짧지만 의미가 이상하다는 것은 분명했습니다. 아니면 너무 의역을 과하게 하여 의미의 왜곡이 있는지도 모릅니다.

1장에서 7군데를 찾았습니다. 확인 좀 부탁 드립니다.

• 15p 1번줄~ 아키텍처 기반 시스템 개발  이 단계는 개발자가 아키텍처에서 표현한 구조와 외부 인터페이스를 정확히 이해할 수 있도록 지원하는 과정이다. 개발자가 아키텍처를 명확이 이해하고 그것을 통해 대화가 이뤄질 수 있도록 우선적으로 수행해야 한다. (오역?)

             This activity is concerned with keeping the developers faithful to the structures and interaction protocols constrained by the architecture. Having an explicit and well-communicated architecture is the first step toward ensuring architectural conformance.

• 15p 6번줄~ 아키텍처 준수 여부 확인 마지막 단계는 아키텍처를 바탕으로 구현돼 실제 운영되고 있는 시스템을 관리할 때 아키텍트가 해야 하는 역할이다. (오역?)

             Finally, when an architecture is created and used, it goes into a maintenance phase.

• 16p 9번줄~ 예를 들어 네트워크 사용량이 걱정이라면 아키텍트는 각 개발팀에게 최소 네트워크 사용량을 제시해 줘야 하고, 주요 구간의 소요 시간을 계산해 제시해야 한다. (오역?)

             For example, if network utilization is an area of concern, the architect should produce (and enforce) for each development team guidelines that will result in a minimum of network traffic. If performance is a concern, the architects should produce (and enforce) time budgets for the major threads.

• 16p 22번줄~ 만약 상용 제품이나 도구가... (없는 내용 추가?)
• 16p 27번줄~ 데이터 변화는 데이터 생성이나 ... (오역?)
• 16p 30번줄~ 병렬 처리 시스템 ... (오역?)

• 17p 1번줄~ 각 시스템의 행위나 프로세스는 ... (오역?)

역자님들 위 내용 한번 검토해 주시기를 부탁 드립니다.

번역하신 분들께 감사 드리고요, 여전히 저에게 좋은 책이라 생각됩니다.

단, 반드시 원서와 함께 하시길 추천합니다.

추가 :

역자님, 답변 감사합니다. 제가 지금 3장을 보고 있습니다.
부분적으로 이해할 수 없는 번역이 자주 눈에 띕니다. 저한테는 원서가 필요한 상황입니다. 의견을 수집하셔서 보완하시길 부탁드립니다.
- 추가 확인 요청1 : 62p 13줄
  계층으로 구분된 시스템 사진을 그림 3.4에서 볼 수 있다.
  What we have is a picture of a system partitioned into layers.
     이어 나오는 설명은 그림 3.4에 관한 설명이 아닙니다. 그리고, 여기서의 그림은 실제 책에 없는 그림을 상상하고 있는 것이라 생각됩니다.
- 추가 확인 요청2 : 3장에서 IMS(Inertial Measurement Set에 대한 2가지 번역
  관성 측정 집합, 내부 측정 집합(???, 그림3.4, 표3.4),

앞 부분의 번역 의심 부분에 대한 역자의 답변을 올립니다.

안녕하십니까? 역자입니다. 우선 번역본 책에 대해서 많은 관심을 가져주셔서 정말 감사합니다. 아래와 같이 답변 드립니다.

1. 이 단계에서 아키텍트가 해야하는 행동으로 의역을 했습니다. 아키텍트 행동이 강조되어야 한다고 생각을 했기 때문입니다. 그런데 의역된 문장이 다소 아키텍트가 개발자를 가르치거나 감시하려한다는 뉘앙스가 풍기는 것은 문제가 있네요... 그러나 분명 오역은 아닙니다. 'structure and interaction protocol'은 직역보다 '구조와 외부 인터페이스'로 해석하는 것이 2, 3장과의 연결에 더 적합한 표현으로 생각됩니다. "Having ~" 이하의 문장은 앞의 문장에서 아키텍트와 개발자의 관계를 표현하다보니 많이 의역이 되었습니다. 궁극적으로는 아키텍트가 수립한 아키텍처를 개발자분들이 개발할 수 있도록 지원하는 것이 이 단계에서 제일 중요한 문장입니다.(아키텍트가 해야하는 일 중에 가장 중요한 일이지요...) 아키텍트와 개발자 분과 관계를 논한 것은 아니니 독자분들의 오해가 없으시길 진심으로 바랍니다.

2. 이 문장 역시 아키텍트가 해야할 일 관점으로 의역을 한 부분입니다. '아키텍처 준수 여부 확인'은 제목이구요...

3. 헉 이런... "만약 성능이 주요 이슈라면" 이라는 부분이 없나요?... 있는데요? 책을 보시면서 착각 하신듯... ^^

4. 앞문장의 'commercial product and tool'이라고 있습니다. 앞 문장과 연결을 부드럽게 하기 위해 약간 의역했습니다.

5. "데이터 변화는 데이터 생성이나 소비 중 한 곳에서 발생할 가능성이 있기 때문이다. (이렇게 하면 변경용이성이 좋아진다.)" () 한문장을 빼고 번역을 했네요.. 문장을 이해하시는데는 문제가 없을 것으로 보이나 보다 정확한 번역을 하지 못한것에 대해서 사과드립니다. 이는 에이콘출판사의 정오표에 올려놓도록 하겠습니다.

6. 원문은"For Parallel-processing system, the architecture should feature well-defined processes or tasks that do not mirror the module decomposition structure" 이렇게 되어 있습니다. 직역을 하면 "병렬처리 시스템에서 아키텍처는 모듈 분할 구조를 그대로 모방하지 않은 프로세스와 태스크를 잘 정의하여 표시해야 한다." 다시 말하면 모듈 뷰는 코드를 표현한 구조로서 병렬처리 시스템에서 하나로 표현되지만 이것이 실행될 때는 병렬처리 시스템에서 여러개의 스레드나 프로세스로 발생하니까 모듈 뷰를 그대로 컴포넌트와 커넥터(런타임 뷰)로 쓰지 말라는 의미입니다. (흔히 런타임 뷰에서 저지르는 중대한 실수입니다.) 그걸 간략하게 의역하여 "아키텍처는 모듈을 하나의 컴포넌트나 커넥터로 표시해서는 안 된다." 이렇게 했습니다. 물론 뒤에 이유는 나오구요.. 흠.. 너무 많이 의역했다고 나무라시면 독자님들께 사과드립니다. 간략한 문장으로 이해를 돕고자 하다보니 오버를 한 것으로 이해해주십시오.

7. 위의 문장은 "모든 태스크나 프로세스는 문서화되어야 한다. 이를 통해 특정 프로세서에 할당된 태스크나 프로세스를 실행시점이라도 쉽게 변경할 수 있다."로 변경하도록 하겠습니다. 혼란을 드려서 죄송합니다. 이는 에이콘출판사 도서정보 페이지 정오표에 올려놓겠습니다.


독자님께서도 아시겠지만 이 책의 원본을 보시면 네이티브들이 읽기에도 버거울 정도의 문장으로 되어 있습니다. 저 또한 10번 정도 읽어야 이해가 가는 부분이 많으니까요.. 그래서 번역본은 다소 의역을 했습니다. 어떤 부분은 의역이 많이 되어 독자분들의 혼란을 주는 곳도 분명 있겠지만 많은 독자분들이 아키텍처를 보다 쉽게 이해하게 하기 위해 노력하다가 발생한 문제로 이해해주시기 바라겠습니다. 마지막으로 좋은 지적을 해주신 독자분께 정말로 감사하단 말씀 전합니다. 앞으로도 더욱 노력하는 역자가 되겠습니다. 감사합니다.

http://www.acornpub.co.kr/book/swarchitect의 정오표 페이지 에서 오탈자나 번역 오류 등 책 내용에 대한 보강 정보를 제공해드리겠습니다.

에구 답변을 댓글에 달아 드렸는데...

다시 올립니다.

-----------------------------------------------------------------------------

책이 좀 굽어 있길래.. 좀 이상하다 싶었는데..

페이지 한장한장 좀 드껍다 싶드라구요

정확히 표현 하자면..얇은 도화지로 된 느낌이네요..

책 넘김도 이상하고... 제 책만 그런건지 모르겟네요..

어쨋든 종이질이 이건좀 아니다 싶네요..

좀 세심한 배려 부탁드립니다.

아키텍트가 먼지 아직 잘모르겠고 아직 큰 관심사항은 아니라서 

이 책 전반적인 내용에 관해서 모두읽어보진 않았고

실제 어플리케이션 제작할때 코더로서 도움이 될만한 챕터만 읽었는데

바로 2부 5장 품질목표 달성편이다.

여기에서는 설계전술이라는 말이 나오는데 여기서 나오는 전술은 개발하는 사람이라면

모두 잘알지는 못하더라도 이런걸 고민해야한다는 정도는 알아야한다고 생각한다.

설계전술은 대략 이렇게 이루어져 있다.

1.가용성 설계전술

      가용성은 특히 분산컴퓨팅에서는 지긋지긋하게 나오는 말이다. 보통 마스터노드에서 

      데이타노드들이 보낸 하트비트를 폴링하고 있다가 각각의 노드상태를 점검하고 대처하면서

      가용성을 높힌다.

      가. 결함 탐지   

             -   핑/에코   : 공통작업을 담당하는 컴포넌트 그룹간 통신일경우 사용됨. 성능확인용도등

             -   하트비트 : 한컴포넌트가 다른컴포넌트에 정기적으로 신호를 보낸다.받지못하면 코디네이터한테 알린다.

             -   예외처리 : 보통 하나의 프로세스 안에서 일어난 결함을 처리한다. 

      나. 결함 복구

            -   투표하기 : 투표자는 같은 값을 컴포넌트들에게 주고  각각 연산하여  투표자에게 준다. 

                                  다른 값을 던진놈 제외.

            -  활성중복:  중복노드들이 동시에 이벤트에 응답할때 하나의 응답만 사용하고 나머지 폐기.

                                 중복노드들이 있으니까 한꺼번에 불능에 빠지는일은 없겠지.. 

            -  비활성중복 : 이중중복( dual redundancy) 라는데 실감이 안간다..

            -  예비 

            - 그림자 동작

            - 상태 재동기화

            - 체크포인트/롤백

2. 변경용이성 설계전술

3. 성능 설계전술

4. 보안 설계전술

5. 시험용이성 설계전술

6. 사용편의성 설계전술

P.S

변역자분들이 이 책을 번역하면서 내용을 이해했고 (과연 ? ) 양심이 있다면

이 책에 대한 실무적인 차원에서의 생생한경험을 공유하는  세미나를  매년 해야한다고 협박해본다. 

우리나라는  너무 지식나눔에 인색하다.