본문으로 건너뛰기
AslanWay
라이브러리

운영 모델·4

아키텍처는 결국 조직도를 닮는다

콘웨이가 1968년에 정리한 이야기입니다. 60년이 지났지만 목표 아키텍처를 그릴 때 '누가 누구와 대화할 수 있는가'를 먼저 확인하는 곳은 여전히 드뭅니다.

출처

How Do Committees Invent?

Melvin E. Conway · Datamation · 1968

원문 읽기

이 자료의 저자는 AslanWay가 아닙니다. 아래 요약은 원문 내용을 정리한 것이고, 이어지는 해설은 저희 의견이며 저자의 동의를 받은 것이 아닙니다.

이 자료의 주장

멜빈 콘웨이의 논문은 짧고, 핵심 주장은 한 문장입니다. 시스템은 그것을 만든 조직의 의사소통 구조를 그대로 닮게 된다는 것. 조직도에 그려진 선이 아니라 사람들이 실제로 쓰는 경로를 말합니다.

Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.

Melvin E. Conway, How Do Committees Invent? (1968)

논리는 문화론이 아니라 기계적입니다. 두 서브시스템 사이에 인터페이스를 두려면 각각을 맡은 사람들이 그 인터페이스에 합의해야 합니다. 대화가 쉬운 관계에서는 인터페이스가 풍부해지고, 대화가 어려운 관계에서는 얇고 뻣뻣해지거나 아예 중복 구현으로 대체됩니다.

덜 인용되는 두 번째 지적도 있습니다. 설계는 아는 것이 가장 적은 초기에 확정되는데, 그 설계를 만들어낸 조직은 나중에 바꾸기가 대단히 어렵다는 점입니다.

저희는 이걸 이렇게 씁니다

  • 목표 아키텍처가 '두 팀이 매일 협업한다'를 전제하는데 그 두 팀이 서로 다른 본부에 예산도 따로 쓰고 있다면, 그 아키텍처는 실현되지 않습니다. 보고 라인을 바꾸든 아키텍처를 바꾸든 둘 중 하나입니다.
  • 뒤집으면 쓸모가 생깁니다. 모듈형 시스템을 원한다면 상시 협의가 필요 없는 팀에 모듈을 맡기면 됩니다. Team Topologies의 플랫폼 팀과 스트림 정렬 팀 구분이 여기서 나옵니다.
  • 그래서 설계 단계에서 이걸 먼저 봅니다. 제안된 경계가 조직의 단층선을 가로지르면, 경계를 옮기거나 양쪽 모두에 권한을 가진 책임자를 명시적으로 세웁니다.

보고서와 실제 출시 사이에서 멈춘 프로그램이 있으신가요?

어디서 막혔는지 알려주세요. 영업일 기준 이틀 안에 저희 생각을 정리해 회신드립니다. 저희가 맞는 파트너가 아니라면 그것도 그대로 말씀드립니다.