마이크로서비스는 얼마나 작아야 할까요? 인류학자 로빈 던바의 통찰을 통해 MSA의 적정 규모를 결정하는 3가지 인류학적 법칙을 공개합니다. 인지 부하 관리부터 콘웨이의 법칙, 그리고 ‘피자 두 판의 법칙’의 과학적 근거까지, 팀의 생산성을 극대화하는 던바의 수 활용 전략을 지금 확인하세요.
서론: 텍스트 너머 ‘인간’을 보는 아키텍처의 시작
영국의 인류학자 로빈 던바(Robin Dunbar)는 영장류의 뇌 크기와 사회적 집단의 규모 사이에 밀접한 상관관계가 있다는 사실을 발견했습니다. 그는 인간이 안정적인 사회적 관계를 유지하며 각 구성원의 맥락을 파악할 수 있는 인지적 한계치가 약 150명이라는 결론을 내렸는데, 이것이 바로 던바의 수(Dunbar’s Number)입니다.
현대 소프트웨어 공학의 정점인 마이크로서비스 아키텍처(MSA)를 설계할 때, 우리는 흔히 트래픽이나 데이터 정규화 같은 기술적 지표에만 매몰됩니다. 하지만 시스템은 결국 ‘사람’이 만들고 운영하는 것입니다. 우리가 첫 번째 포스팅에서 다루었던 소프트웨어 엔트로피를 낮추는 물리적 원리의 관점에서 볼 때, 진정한 무질서는 코드의 복잡성보다 코드를 관리하는 인간들 사이의 ‘인지적 마찰’에서 시작됩니다. 오늘은 MSA의 성공을 좌우하는 서비스 분할의 적정 규모를 던바의 수가 제시하는 3가지 법칙을 통해 심층 분석해 보겠습니다.
1. 인지 부하의 법칙: 뇌의 용량이 결정하는 팀과 서비스의 크기
MSA의 핵심 철학인 ‘자율성’은 하나의 팀이 서비스의 전체 맥락을 온전히 장악할 수 있을 때만 실현됩니다. 던바의 수는 이를 위한 물리적인 가이드라인을 제시합니다.
5명과 15명의 임계점
던바는 150명이라는 전체 규모 내에서도 인지적 친밀도에 따라 계층이 나뉜다는 점을 강조했습니다.
- 마법의 숫자 5와 15: 아마존의 ‘피자 두 판의 법칙(Two-Pizza Rule)’이 가리키는 6~10명의 팀 규모는 던바가 말한 ‘가장 친밀한 그룹(5명)’과 ‘신뢰하는 그룹(15명)’ 사이의 균형점입니다.
- 소통 비용의 폭발적 증가: 팀 규모가 이 범위를 넘어서면 소통 경로의 수 $C$는 다음과 같이 기하급수적으로 늘어납니다.$$C = frac{n(n-1)}{2}$$팀원이 5명일 때 경로는 10개지만, 15명이 되면 105개로 늘어납니다. 하나의 마이크로서비스는 이 소통 경로가 감당 가능한 수준, 즉 한 팀의 ‘인지 부하’ 내에서 설계되어야 합니다. 서비스가 팀의 인지 범위를 벗어나면 엔트로피는 통제 불능 상태가 됩니다.
2. 구조적 정렬의 법칙: 던바의 수와 콘웨이의 법칙이 만나는 지점
소프트웨어 설계는 그 소프트웨어를 만드는 조직의 소통 구조를 닮는다는 콘웨이의 법칙은 던바의 수와 만날 때 더욱 강력한 실천력을 얻습니다.
아키텍처와 조직의 동기화
- 인지적 일치성 확보: 만약 조직이 150명 이상의 거대 단위인데 하나의 거대한 모놀리식을 관리한다면, 정보의 병목과 오해는 피할 수 없습니다. 던바의 수를 초과하는 소통 구조는 시스템 내부에 보이지 않는 ‘결함의 구멍’을 만듭니다.
- 세포 분열을 통한 최적화: 조직을 던바의 수 단위(예: 10명 내외의 스쿼드)로 쪼개고 각 팀에 독립적인 마이크로서비스를 맡기는 것은, 인류학적으로 가장 최적화된 소통 구조를 시스템에 투영하는 작업입니다. 이는 인터페이스 분리 법칙(ISP)을 조직 차원에서 실천하는 것이며, 각 팀은 자신이 맡은 서비스의 인터페이스만 책임짐으로써 인지 비용을 최소화합니다.
3. 엔트로피 제어의 법칙: 서비스 비대화를 막는 세포 분열 전략
MSA를 운영하다 보면 초기에는 작았던 서비스가 시간이 흐르며 점점 커져 ‘미니 모놀리스’가 되는 현상을 목격하게 됩니다. 이는 던바의 수가 경고하는 인지 한계를 넘어섰다는 신호입니다.
비대해진 서비스가 주는 경고
- 기억의 유실: 서비스 로직이 너무 복잡해져서 팀원 중 누구도 전체를 파악하지 못하게 된다면, 그때부터 기술 부채와 복리 이자가 쌓이기 시작합니다. 코드를 수정하는 것이 두려워지고, 수정할 때마다 예상치 못한 곳에서 버그가 터져 나옵니다.
- 하인리히 법칙의 징후: 하인리히 법칙에 따르면, 대형 장애 1건 전에는 300번의 사소한 징후가 있습니다. 던바의 수를 넘어서는 복잡한 서비스는 팀원들의 주의력을 분산시켜 이러한 300번의 징후를 놓치게 만듭니다.
- 방어적 분할 전략: 따라서 서비스의 복잡도가 팀의 인지 범위를 넘어설 것 같으면, 방어적 프로그래밍 관점에서 서비스를 더 작은 단위로 쪼개는 결단이 필요합니다. 이것이 시스템의 무질서를 물리적으로 제어하는 유일한 길입니다.
실전 가이드: 던바의 수에 기반한 MSA 적정 규모 체크리스트
여러분의 시스템이 인류학적으로 건강한지 확인하기 위한 4가지 체크리스트를 제안합니다.
- 팀 규모: 현재 서비스를 담당하는 핵심 인원이 10명(피자 두 판) 이내인가?
- 맥락 파악: 신규 팀원이 서비스 전체 로직을 파악하는 데 2주 이내의 시간이 소요되는가?
- 소통 범위: 타 팀과의 의사소통 없이도 독립적인 배포가 80% 이상 가능한가? ([파레토 법칙] 적용)
- 장애 회고: 최근의 장애 원인이 “누군가 변경 사항을 몰랐기 때문”이었는가? 만약 그렇다면 서비스 분할이 필요한 시점입니다.
| 구분 | 인원 규모 | MSA 적용 전략 | 인지적 특징 |
| 핵심 스쿼드 | 5~10명 | 단일 서비스 책임 (Two-Pizza) | 깊은 맥락 공유, 높은 집중력 |
| 신뢰 그룹 | 15~30명 | 도메인 단위 서비스 그룹 관리 | 전문 지식의 상호 보완 |
| 부족(Tribe) | 50~150명 | 플랫폼 전체 서비스 연합체 | 안정적인 관계의 임계점 |
| 엔터프라이즈 | 150명 이상 | 계층화 및 추상화 인터페이스 도입 | 시스템적 통제와 표준화 필수 |
결론: 기술적 확장보다 중요한 것은 인간적 수용력이다
결론적으로 던바의 수는 MSA의 성공이 기술적 오케스트레이션 능력보다, 개발팀의 인지적 수용력에 달려 있음을 시사합니다. 아무리 유연한 클라우드 인프라를 갖추고 있더라도, 그 위에서 돌아가는 코드가 인간의 뇌가 이해할 수 있는 범위를 벗어난다면 그 시스템은 필연적으로 붕괴합니다.
여러분의 마이크로서비스는 지금 얼마나 큰가요? 팀원들이 코드 한 줄을 고칠 때마다 문서 전체를 뒤져야 하거나, 옆 자리 동료가 무엇을 하는지조차 모르는 상태인가요? 던바의 수라는 인류학적 잣대를 아키텍처에 들이대 보십시오. 본질로 돌아가 팀이 ‘온전히 이해하고 장악할 수 있는 규모’로 서비스를 정돈할 때, 비로소 기술은 인간을 억압하는 굴레가 아닌 창의성을 극대화하는 날개가 될 것입니다.