구조가 아닌 관계의 문제
Brooks의 아키텍처론 재해석
『The Mythical Man-Month』 4장에서 브룩스는 시스템 아키텍처에 대해 본격적으로 논의합니다.
이 장의 제목은 “Aristocracy, Democracy, and System Design.” 제목부터 인상적입니다.
그는 시스템 아키텍처의 통일성을 확보하려면, '건축가(architect)'와 '구현자(implementer)'의 역할을 구분해야 한다고 주장합니다.
“건축가가 설계하고, 구현자는 그 설계를 따른다.”
이 말은 마치 르 코르뷔지에가 건물 설계를 지시하듯,
아키텍트는 사용자의 대리인이 되어 전체적인 구조와 인터페이스를 정의하고,
구현자는 그 지침에 따라 상세 구현을 맡는 방식입니다.
1970년대 IBM System/360이라는 매머드급 프로젝트에서는 이 방식이 유효해 보였을지 모릅니다.
실제로 브룩스는 10명의 아키텍트 팀과 150명의 구현자 팀을 분리해 운영했다고 서술합니다.
그러나 결과는 처참했습니다.
“구현팀에게 인터페이스 명세 책임을 넘기자, 일정은 더 늦어졌고 품질도 낮아졌으며, 아키텍처 통일성은 붕괴했다.”
이 실패 경험은 그에게 '개념적 일관성(conceptual integrity)'의 중요성을 각인시켰고,
나중에 이 개념은 소프트웨어 설계의 중심으로 자리 잡습니다.
하지만 이 구조, 지금도 유효할까요?
지금 시대에는 왜 이 방식이 어색한가
오늘날 개발 환경에서는 '아키텍트-구현자 분리 모델'이 점점 힘을 잃고 있습니다.
그 이유는 단순히 기술의 발전 때문만은 아닙니다.
구조보다는 관계의 방식이 변했기 때문입니다.
1. 소규모 팀 중심의 개발 문화
지금은 수백 명이 한꺼번에 참여하는 대형 시스템보다는,
몇 명의 개발자가 작은 서비스를 빠르게 개발하고 배포하는 시대입니다.
한 팀 안에서 기획, 아키텍처, 구현이 섞여 있고,
유기적인 협업이 중요한 문화 속에서 '위에서 설계하고 아래에서 구현한다'는 방식은 낯설게 느껴집니다.
2. API 우선 설계와 마이크로서비스
2000년대 초 아마존의 '베조스 API 선언' 이후,
팀 간 상호작용은 명확한 API 계약을 중심으로 이루어지기 시작했습니다.
오늘날 대부분의 시스템은 공개된 인터페이스(API)를 통해 동작하며,
각 서비스는 자율적으로 개발됩니다.
즉, 중앙 집중형 아키텍처 설계보다는 분산된 책임과 합의 기반의 설계 방식이 자리 잡고 있습니다.
3. 프로토타이핑과 반복적 개선의 문화
제품 개발은 더 이상 한 번의 완벽한 설계로 끝나지 않습니다.
빠르게 프로토타입을 만들어보고, 반응을 관찰하며 점진적으로 개선해 나갑니다.
이런 환경에서는 '처음부터 완벽한 아키텍처 설계'는 오히려 방해가 될 수 있습니다.
4. "건축가"가 아닌 "선임 개발자" 문화
현재 실무에서 아키텍트를 '직책'으로 부르는 경우는 드뭅니다.
대부분은 '시니어 엔지니어', '테크 리드', '스태프 엔지니어'와 같은 실무형 리더들이 아키텍처 설계를 병행합니다. 이들은 설계만 하는 것이 아니라, 코드 작성, 리뷰, 배포, 운영까지 직접 수행합니다. '설계와 구현의 통합'이 실무의 표준이 된 것입니다.
설계는 사람이 하는 일이다
그렇다면 브룩스의 주장은 시대에 뒤처진 것일까요?
꼭 그렇지는 않습니다.
그가 강조한 '개념적 일관성'은 지금도 여전히 중요합니다.
다만, 이를 확보하는 방식이 바뀌었을 뿐입니다.
브룩스는 아키텍처 설계와 구현을 분리해야 '사용자 중심의 통일성 있는 시스템'을 만들 수 있다고 봤습니다. 하지만 지금은, 그 통일성을 현장에 발을 담근 사람들이 직접 확보해야 한다는 생각이 지배적입니다.
실제로 우버에서는 400명의 엔지니어가 참여한 앱 리팩토링 프로젝트에서,
아키텍처 설계를 맡은 팀이 직접 프로토타입을 만들고,
이후 전체 개발 과정에서도 리뷰와 운영에 참여했다고 합니다.
설계를 만든 사람이 끝까지 책임지는 구조였던 것이죠.
이는 아키텍처 설계를 단지 '그림 그리는 일'로 보지 않고,
'관계 조율의 일환'으로 이해한 사례라고 볼 수 있습니다.
이처럼 지금의 설계는 구조보다 사람과 팀의 관계를 조직하는 일에 가깝습니다.
관계 중심 설계로의 전환
이제 아키텍처 설계는 '무엇을 어떻게 나눌 것인가'의 문제가 아니라,
'누가 누구와 어떤 방식으로 협업할 것인가'의 문제로 진화했습니다.
즉, 관계를 명확히 하기 위한 구조 설계가 중요해졌습니다.
시스템 구조는 팀 구조와 맞닿아야 합니다 (Conway's Law)
명확한 API 계약은 신뢰와 자율성을 보장합니다
설계자는 실무와 분리된 외부인이 아니라, "같이 책임지는 동료"여야 합니다
브룩스가 말했던 개념적 일관성은, 더 이상 위계에 의해 강제되지 않습니다.
그것은 공감과 협업, 그리고 반복적인 피드백 속에서 형성되는 것입니다.
『The Mythical Man-Month』의 아키텍처론은, 그 자체로 오래된 방식일 수 있습니다.
하지만 그가 강조한 '통일성', '사용자 중심성', '관계의 복잡성에 대한 인식'은 여전히 유효합니다.
지금의 실무는 그것을 실현하는 방식이 다를 뿐입니다.
설계와 구현은 분리되지 않고, 설계자는 일선에서 함께 시행착오를 겪으며 의미 있는 구조를 만들어 갑니다.
그러니 이제 우리는 브룩스의 이야기를 단지 '구조적 이상론'으로 읽을 것이 아니라, '관계적 설계의 시작점'으로 읽어야 할 때입니다.
→ 4편: 왜 팀 구조는 변하지 않았는가? — Tree와 커뮤니케이션
