Step 09. 아키텍처를 밀어내는 진짜 압력 — Conway의 법칙과 조직

만화로 보는 요약 — 먼저 읽어보세요

시스템 경계는 조직의 대화 구조를 닮으므로, 원하는 구조가 있다면 팀과 커뮤니케이션 경계부터 함께 설계해야 한다.

면접 실전 질문: ① Conway의 법칙은 무엇을 말하는가? ② 역 Conway 전략이란 무엇인가? ③ 팀 경계와 서비스 경계가 어긋나면 어떤 비용이 생기는가?

이 장의 질문: 지금까지의 모든 장은 “설계자가 화살표를 배치한다”고 전제했다. 그런데 정말 그런가? 설계자보다 힘센 무언가가 이미 화살표를 배치하고 있다면?

1. 1968년의 관찰 — 시스템은 조직을 복제한다

또 1968년이다. 가르미슈에서 소프트웨어 공학이 태어나고 Dijkstra가 THE 시스템을 발표한 바로 그 해, Melvin Conway는 「How Do Committees Invent?」라는 논문을 Datamation에 싣는다. (원래 Harvard Business Review에 투고했다가 “주장을 입증하지 못했다”는 이유로 거절당했다 — 반세기 뒤 이 주장은 실증 연구의 단골 주제가 된다.) 결론 문장이 이후 “Conway의 법칙”으로 불리게 될 그것이다:

“시스템을 설계하는 조직은 — 넓은 의미에서 — 그 조직의 커뮤니케이션 구조를 복제한 설계를 내놓도록 제약되어 있다.”

‘법칙’이라는 이름은 Conway 자신이 아니라 Fred Brooks가 붙였다(『맨먼스 미신』, 1975). 통속적 요약은 업계 격언이 된 이 형태다: “컴파일러를 네 팀이 만들면, 4패스 컴파일러가 나온다.” (원논문의 실제 예시는 더 구체적이다 — 8인 조직에서 5명이 COBOL, 3명이 ALGOL 컴파일러를 맡자, 5단계 COBOL 컴파일러와 3단계 ALGOL 컴파일러가 나왔다.)

주의 깊게 읽어야 할 단어는 “커뮤니케이션 구조”다. 조직도(org chart)가 아니다. 법칙이 말하는 것은 공식 보고 라인이 아니라 실제로 누가 누구와 이야기하는가의 구조이고, 그 구조가 시스템의 모듈 경계로 복제된다는 것이다.

2. 법칙의 역학 — 왜 성립하는가

Conway의 논증은 신비주의가 아니라 간단한 기하학이다.

모듈 A와 모듈 B가 올바르게 맞물리려면, A의 설계자와 B의 설계자가 소통해야 한다. 인터페이스란 곧 합의이고, 합의는 대화의 산물이다. 뒤집으면 — 대화가 없는 곳에는 정교한 인터페이스가 생길 수 없고, 대화가 밀집한 곳에는 경계가 흐려진다. 따라서 시스템의 인터페이스 지도는 조직의 대화 지도를 따라 그려질 수밖에 없다. 설계 공간이 아무리 넓어도, 탐색 가능한 설계는 조직이 소통할 수 있는 설계뿐이다.

여기에 Brooks의 산수를 얹으면 규모의 문제가 보인다. n명이 서로 조율하려면 통신 채널이 n(n-1)/2개 필요하다 — 10명이면 45개, 50명이면 1,225개. 조직은 필연적으로 팀이라는 칸막이를 세워 채널을 쳐내고, 그 순간 법칙이 작동한다: 칸막이가 곧 미래의 모듈 경계다.

이것은 사변이 아니다. MacCormack, Rusnak, Baldwin의 하버드 연구(제품 아키텍처와 조직 아키텍처의 쌍대성 탐구, 2008~)는 같은 기능의 소프트웨어를 비교해 — 예컨대 분산된 오픈소스 조직과 한 건물의 상용 조직이 만든 제품들 — 느슨하게 결합된 조직이 유의미하게 더 모듈러한 제품을 만든다는 것을 보였다. 법칙은 “거울 가설(mirroring hypothesis)“이라는 이름으로 실증 문헌에 자리잡았다.

이 장의 위치가 이제 설명된다. Part 1은 화살표를 어떻게 배치할지 가르쳤지만, Conway는 화살표가 이미 누군가에 의해 배치되고 있다고 말한다 — 조직이라는 보이지 않는 설계자에 의해. 아키텍트가 그린 다이어그램과 조직의 대화 구조가 싸우면, 방치할 경우 이기는 쪽은 조직이다. 다이어그램은 위반해도 컴파일되지만, 소통 없는 인터페이스는 애초에 만들어지지 않기 때문이다.

3. Step 08의 숙제 — 수직 절단은 누가 정하는가

앞 장은 숙제를 남겼다: 헥사고날은 깊이 축(기술을 바깥으로)을 바로잡지만, “부분 취소 추가”가 모든 링을 관통하는 수직 절단의 문제는 남는다 — 그것은 육각형 내부를 도메인/컨텍스트로 쪼개는 별개의 결정이라고 했다. 그 결정의 실질적 주인이 누구인지, 이제 답할 수 있다. 조직이다.

세 가지 경계가 있다. 컨텍스트 경계(Step 07 — 모델과 언어가 갈리는 곳), 모듈 경계(코드가 갈리는 곳), 팀 경계(사람이 갈리는 곳). 시스템이 건강한 상태는 셋이 정렬된 상태다: 한 팀이 한 컨텍스트를 소유하고, 그 컨텍스트가 한 모듈에 산다. 이때 “부분 취소 추가”는 주문 팀의 스프린트 하나로 끝난다 — 변경이 팀 안에 갇힌다.

어긋나면 어떻게 되는가. 컨텍스트는 잘 그렸는데 팀이 기술 층으로 나뉘어 있다면(프론트 팀, 백엔드 팀, DB 팀 — Step 06에서 본 “층과 팀의 정렬”이 정확히 이것이다), 기능 하나마다 세 팀의 백로그 조율, 세 번의 회의, 세 팀의 배포 일정이 필요하다. 반대로 팀은 도메인별인데 코드가 한 덩어리라면, 팀들은 같은 파일 위에서 충돌한다. 두 경우 모두 경계 불일치의 비용은 조율(coordination)이라는 화폐로 청구된다 — 그리고 조율 비용은 Lehman의 엔트로피(Step 05)보다 빠르게 시스템을 멈춰 세운다.

Parnas의 기준(변경 가능성으로 잘라라)과 Conway의 법칙(대화 구조대로 잘린다)을 겹치면 이 장의 핵심 문장이 나온다:

아키텍처 경계 설계란 코드의 문제이기 이전에, “어떤 변경을 한 팀 안에 가둘 것인가”라는 조직 설계의 문제다.

4. 법칙을 도구로 — 역 Conway 전략

법칙이 물리학이라면 저항은 무의미하다. 남은 선택은 하나 — 이용하는 것이다.

원하는 아키텍처가 있다면, 조직을 먼저 그 모양으로 만들어라. 그러면 법칙이 (당신에 맞서던 바로 그 힘으로) 시스템을 그 모양으로 밀어준다. Thoughtworks 진영이 2010년대에 이 접근에 붙인 이름이 **역 Conway 전략(Inverse Conway Maneuver)**이다. 정산 컨텍스트를 독립 모듈로 만들고 싶은가? 정산 팀을 먼저 독립시켜라 — 자기 백로그, 자기 배포 권한과 함께.

이 전략을 실무 체계로 집대성한 것이 Skelton과 Pais의 『Team Topologies』(2019)다. 두 개념만 가져오자.

• 인지 부하(cognitive load)가 소유의 한계다. 한 팀이 책임질 수 있는 시스템의 크기는 팀원 수가 아니라 팀의 머리에 들어가는 양으로 결정된다. 모듈이 아무리 논리적으로 옳아도 한 팀의 인지 용량을 넘으면 그 경계는 유지되지 않는다 — 아키텍처를 팀에 맞춰 자르라(team-first)는 역발상이 여기서 나온다.
• 스트림 정렬 팀(stream-aligned team)이 기본형이다. 기능/도메인의 변경 흐름 하나에 팀 하나를 정렬하고, 나머지 팀 유형(플랫폼, 활성화, 복잡 하위시스템)은 이 팀들의 인지 부하를 덜어주기 위해 존재한다. 3절의 “정렬” 상태를 조직 쪽에서 만들어내는 설계다.

가장 유명한 실전 사례는 Amazon이다. “피자 두 판 팀”(팀은 피자 두 판으로 먹일 수 있는 크기까지)과, 2000년대 초의 소위 API 명령 — 모든 팀은 데이터와 기능을 오직 서비스 인터페이스로만 노출하고, 다른 팀의 저장소에 직접 접근하지 않는다. (이 일화의 전거는 공식 문서가 아니라 아마존 출신 Steve Yegge의 2011년 공개 회고라는 점은 밝혀두자.) 이것은 기술 지침처럼 보이지만 본질은 조직의 대화 구조를 API로 강제 표준화한 것이다 — 역 Conway 전략의 가장 과격한 집행이었고, 그 서비스 지향 조직이 훗날 AWS의 토양이 됐다는 해석이 널리 받아들여진다.

5. 다음 장의 문 앞에서 — 마이크로서비스의 진짜 계기

이제 앞 장 말미의 예고(“화살표가 아니라 팀이 문제”)를 회수하자.

2010년대 초, 성공한 서비스 기업들의 공통 고통은 내부 구조가 아니라 규모의 조율이었다. 100명이 하나의 코드베이스에 커밋한다. 배포 열차는 2주에 한 번 떠나고, 한 팀의 버그가 전원의 릴리스를 세운다. 릴리스 조율 회의에 참석하는 사람 수가 코드 리뷰어 수보다 많다. 헥사고날로 내부를 아무리 아름답게 갈라도 이 고통은 줄지 않는다 — 배포라는 사건이 전 조직의 단일 병목이기 때문이다.

그래서 마이크로서비스의 진짜 계기를 이 장의 언어로 적으면: 팀 자율성, 그리고 그것의 기술적 표현인 배포 독립성이다. 공정하게 적자 — 독립 확장과 장애 격리도 진짜 동기였고, 초대형 트래픽 기업에서는 동급 1순위였다. 그러나 모놀리스로도 수평 확장은 된다. 안 되는 것은 100명의 독립 배포다. 그래서 다수 기업의 실제 구속 조건은 기술이 아니라 조직이었고, 서비스 분리는 “확장을 위한 기술 선택”이기 이전에 “조율을 죽이기 위한 조직 선택”이었다. Werner Vogels(Amazon CTO)의 구호가 이 본질을 요약한다 — “You build it, you run it.” 만든 팀이 돌리고, 새벽에 깨는 것도 그 팀이다. 소유의 완결.

그러나 — 다음 장의 예고이자 경고 — 경계를 프로세스 밖으로 밀어내는 순간, 지금까지의 모든 장이 다루지 않은 완전히 새로운 물리학이 시작된다. 함수 호출은 실패하지 않지만 네트워크 호출은 실패한다. 한 프로세스의 트랜잭션은 원자적이지만 두 서비스 사이에는 원자성이 없다. 조직의 고통을 풀러 간 곳에서 분산의 고통이 기다린다 — 진자의 다음 반환점이다.

6. 흔한 오해 바로잡기

오해 1: “Conway의 법칙 = 조직도가 아키텍처가 된다.” 법칙의 대상은 공식 조직도가 아니라 실제 커뮤니케이션 구조다. 조직도는 그대로인데 두 팀이 매일 함께 점심을 먹으면 그 사이의 경계는 흐려지고, 같은 팀이라도 대화가 끊긴 두 소그룹은 갈라진 모듈을 만든다. 조직도를 바꾸는 것은 역 Conway의 시작일 뿐, 대화 구조가 따라 바뀌어야 완성된다.

오해 2: “역 Conway 전략은 일회성 조직 개편이다.” 시스템도 조직도 계속 변한다(Lehman 1법칙은 조직에도 적용된다). 역 Conway는 재조직 이벤트가 아니라 아키텍처 결정마다 ‘팀 경계는?‘을 함께 묻는 상시 규율이다. Team Topologies가 팀 간 상호작용 양식의 진화를 책 절반에 할애하는 이유다.

오해 3: “마이크로서비스로 쪼개면 팀이 자율적이 된다.” 인과가 거꾸로다. 자율적이지 않은 조직이 서비스만 쪼개면 — 예컨대 서비스 열 개가 하나의 DB를 공유하면(공통 결합의 서비스 확대판) — 배포는 여전히 전원 조율이고, 결과는 “분산 모놀리스”다: 모놀리스의 조율 비용에 네트워크의 물리학까지 얹은 최악의 조합. 조직의 경계 없이 기술의 경계만 세운, 힘과 형태의 불일치(Step 05)의 현대판이다.

오해 4: “Conway의 법칙은 숙명론이다.” 법칙은 “조직이 이긴다”고 말할 뿐 “조직을 바꿀 수 없다”고 말하지 않는다. 중력이 숙명이 아니라 비행기 설계의 전제이듯, Conway는 아키텍트가 설계에 넣어야 할 힘이다. 이 장의 요지는 비관이 아니라 설계 변수의 확장이다 — 아키텍트의 도구 상자에 조직이 추가된 것.

7. 요약, 그리고 다음 장으로

• Conway의 법칙(1968): 시스템 설계는 조직의 커뮤니케이션 구조를 복제한다. 메커니즘은 단순하다 — 인터페이스는 합의이고 합의는 대화의 산물이므로, 대화 지도가 곧 설계 공간의 제약이다. 실증 연구(거울 가설)가 이를 뒷받침한다.
• 다이어그램과 조직이 싸우면, 방치할 경우 조직이 이긴다. 따라서 경계 설계는 조직 설계다 — 컨텍스트·모듈·팀의 삼중 정렬이 목표이고, 불일치의 비용은 조율이라는 화폐로 청구된다.
• 역 Conway 전략: 원하는 아키텍처 모양으로 조직을 먼저 만들어 법칙을 아군으로 쓴다. Team Topologies — 인지 부하가 소유의 한계, 스트림 정렬 팀이 기본형. Amazon의 API 명령이 가장 과격한 집행 사례.
• 마이크로서비스의 진짜 계기는 조직이다: 팀 자율성과 배포 독립성. 기술 유행이 아니라 조율 비용에 대한 조직적 응답.
• 그러나 경계가 프로세스 밖으로 나가는 순간 새로운 물리학이 시작된다 — 다음 장.

다음 장 예고: 분산의 유혹과 대가. 네트워크는 신뢰할 수 없고, 지연은 0이 아니며, 두 서비스 사이에 원자성은 없다 — 8가지 오류와 CAP 정리라는 이름의 청구서. 그리고 그 청구서를 다 받아본 업계가 진자를 되돌린 곳, 모듈러 모놀리스까지.

원전