<div id="readability-page-1" class="page"><div>
  <p><span>Written by</span>
    KimCoding

    
      <br>
      <span>on&nbsp;</span><time datetime="2022-02-14 00:00:00 +0900">February 14, 2022</time>
    
  </p>

  <h2>(리뷰)팀 토폴로지 -  빠른 업무 플로우를 만드는 조직 설계</h2>
  

  <p><img src="https://coderk.github.io/assets/images/new/2022-02-14-39-background.jpeg" loading="lazy"></p>

<blockquote>
  <p>콘웨이의 법칙이라고 가장 많이 알려진 구절은 다음과 같다.</p>

  <p>‘조직은 자신의 커뮤니케이션 경로를 반영한 설계를 하도록 제약 받는다.’</p>

  <p>콘웨이는 초기 전자 컴퓨터 시스템을 구현한 기업들을 관찰했다. 콘웨이가 말한 법칙이란 조직 커뮤니케이션의 실제 경로(플래깅이 언급한 가치 창출 구조)와 조직이 개발한 소프트웨어 아키텍처 사이의 강한 관성, 혹은 알란 켈리(Allan Kelly)가 준동형의 힘(homorphic force)이라 부른 것을 의미한다. 준동형의 힘은 소프트웨어 아키텍처와 팀 구조 사이의 모든 것을 동일한 형태로 만드는 경향이 있다. 다시 말해, 실현 가능한 소프트웨어 아키텍처를 올바로 선택해 구현하려면 팀 커뮤니케이션에 관한 이해부터 선행돼야 한다. 만일 만들고자 하는 이론적 시스템 구조와 실질적 조직 모델이 상충하면 둘 중 하나를 바꿔야 한다.</p>

  <p><cite>팀 토폴로지 &gt; 부활한 콘웨이의 법칙 - P.45</cite></p>
</blockquote>

<p>올해 4번째로 읽은 책은 <a href="https://book.naver.com/bookdb/book_detail.nhn?bid=17689088">팀 토폴로지</a>.</p>

<p>콘웨이는 일찍이 “조직은 자신의 커뮤니케이션 경로를 반영한 설계를 하도록 제약받는다”라고 했다. 소프트웨어 아키텍처는 소프트웨어를 개발하는 조직의 커뮤니케이션 역학을 거스르지 못한다는 뜻이다.</p>

<p>소프트웨어를 설계할 때는 조직 커뮤니케이션 구조를 함께 고민해야 한다. 기술, 사람, 그리고 기술과 사람 사이에 존재하는 역학까지. 아키텍트는 설계의, 기술적, 사회적, 환경적 측면을 모두 다뤄야 한다. 이게 안 되면 문제의 아주 지엽적인 면만 겨우 건드리거나, 문제랑 동떨어진, 현실성 없는 해결책을 만들 수밖에 없다. 그렇게 설계는 실패한다.</p>

<p>이 책은 콘웨이 법칙을 재조명하며, 이 법칙을 등한시한 소프트웨어가 실패하는 이유를 살핀다. 그리고 콘웨이 법칙을 고려한 조직 설계 대안을 제시한다. 1장의 문제 정의는 공감 가는 내용이 정말 많았다. 내가 책을 쓰면 이렇게 썼을 것 같다 싶을 정도. 책에서 제안하는 몇 가지 팀 설계와 협업 모델을 보고 영감도 얻었다.</p>

<p>그런데 번역이 너무 아쉽다. 번역만 아니면 인생 도서에 올릴 책인데. 문장을 여러번 곱씹어야 겨우 저자의 의도를 이해할 수 있더라. 나중에 번역을 개선한 개선판이 나와주면 좋겠다.</p>


</div></div>

Huns.me

콘웨이의 법칙이라고 가장 많이 알려진 구절은 다음과 같다.
‘조직은 자신의 커뮤니케이션 경로를 반영한 설계를 하도록 제약 받는다.’
콘웨이는 초기 전자 컴퓨터 시스템을 구현한 기업들을 관찰했다. 콘웨이가 말한 법칙이란 조직 커뮤니케이션의 실제 경로(플래깅이 언급한 가치 창출 구조)와 조직이 개발한 소프트웨어 아키텍처 사이의 강한 관성, 혹은 알란 켈리(Allan Kelly)가 준동형의 힘(homorphic force)이라 부른 것을 의미한다. 준동형의 힘은 소프트웨어 아키텍처와 팀 구조 사이의 모든 것을 동일한 형태로 만드는 경향이 있다. 다시 말해, 실현 가능한 소프트웨어 아키텍처를 올바로 선택해 구현하려면 팀 커뮤니케이션에 관한 이해부터 선행돼야 한다. 만일 만들고자 하는 이론적 시스템 구조와 실질적 조직 모델이 상충하면 둘 중 하나를 바꿔야 한다.
팀 토폴로지 > 부활한 콘웨이의 법칙 - P.45
올해 4번째로 읽은 책은 팀 토폴로지.
콘웨이는 일찍이 “조직은 자신의 커뮤니케이션 경로를 반영한 설계를 하도록 제약받는다”라고 했다. 소프트웨어 아키텍처는 소프트웨어를 개발하는 조직의 커뮤니케이션 역학을 거스르지 못한다는 뜻이다.
소프트웨어를 설계할 때는 조직 커뮤니케이션 구조를 함께 고민해야 한다. 기술, 사람, 그리고 기술과 사람 사이에 존재하는 역학까지. 아키텍트는 설계의, 기술적, 사회적, 환경적 측면을 모두 다뤄야 한다. 이게 안 되면 문제의 아주 지엽적인 면만 겨우 건드리거나, 문제랑 동떨어진, 현실성 없는 해결책을 만들 수밖에 없다. 그렇게 설계는 실패한다.
이 책은 콘웨이 법칙을 재조명하며, 이 법칙을 등한시한 소프트웨어가 실패하는 이유를 살핀다. 그리고 콘웨이 법칙을 고려한 조직 설계 대안을 제시한다. 1장의 문제 정의는 공감 가는 내용이 정말 많았다. 내가 책을 쓰면 이렇게 썼을 것 같다 싶을 정도. 책에서 제안하는 몇 가지 팀 설계와 협업 모델을 보고 영감도 얻었다.
그런데 번역이 너무 아쉽다. 번역만 아니면 인생 도서에 올릴 책인데. 문장을 여러번 곱씹어야 겨우 저자의 의도를 이해할 수 있더라. 나중에 번역을 개선한 개선판이 나와주면 좋겠다.

(리뷰)팀 토폴로지 - 빠른 업무 플로우를 만드는 조직 설계

댓글