C# 아키텍처 마스터리 — 아키텍처로 팀 확장 (Conway’s Law & .NET) (파트 11)

Source: Dev.to

.NET에서의 Conway’s Law

“조직은 자신들의 커뮤니케이션 구조를 반영한 시스템을 설계한다.”
— 멜빈 콘웨이

이는 제안이 아니라 경험적 법칙이다. 팀 구조가 엉망이라면 아키텍처도 그럴 것이다.

Conway’s Law가 코드베이스에 나타나는 방식

• 하나의 거대한 Web 프로젝트 → 하나의 거대한 팀
• DbContext를 어디서든 공유 → 소유권이 어디서든 공유
• God 서비스 → 중앙 의사결정 병목
• 끝없는 머지 충돌 → 경계가 불분명

아키텍처는 팀이 어떻게 소통하는지를 드러낸다.

해결책으로서의 Clean Architecture

Clean Architecture는 다음을 도입한다:

• 명시적인 경계
• 명확한 소유 구역
• 안정적인 계약

이를 통해 가능해지는 것:

• 병렬 개발
• 조정 비용 감소
• 독립적인 의사결정

경계는 기술적인 것뿐 아니라 사회적인 도구이다.

Vertical Slice Architecture

Vertical Slice Architecture는 팀 규모 확장과 자연스럽게 맞는다.

슬라이스의 특징

• 기능을 처음부터 끝까지 담당
• 최소한의 의존성 보유
• 독립적으로 진화 가능

이는 기술 사일로가 아닌 제품 중심 팀을 반영한다.

공유 컴포넌트의 함정

공유 컴포넌트는 초기에는 효율적으로 보이지만 나중에 병목이 된다.

흔히 겪는 공유 문제점

• 공유 DbContext
• 공유 유틸리티 라이브러리
• 끝없이 커지는 공유 “core” 프로젝트

공유 코드는 공유 조정을 필요로 하며, 이는 규모에 맞지 않는다.

고성능 조직을 위한 Team Topologies

• Stream‑aligned 팀 – 기능을 담당
• Platform 팀 – 다른 팀을 지원
• Enabling 팀 – 실천을 개선

아키텍처는 이러한 역할을 지원해야 하며, 방해해서는 안 된다.

좋은 아키텍처 질문 vs 나쁜 아키텍처 질문

명확한 소유권은 도구보다 회의를 더 많이 줄여준다.

마이크로서비스 없이 규모 확장하기

팀을 확장하기 위해 마이크로서비스가 반드시 필요한 것은 아니다. 많은 .NET 팀이 다음으로 성공한다:

• 모듈형 모놀리식
• 명확한 경계
• Vertical slice
• 견고한 계약

마이크로서비스는 조직적 문제를 해결하기 위한 것이지, 단순히 기술적 문제만을 해결하는 것이 아니다.

경고 신호

• 변경에 다수 승인 필요
• 팀이 특정 코드를 건드리는 것을 회피
• 두려움에 기반한 개발 (“한 사람만 이 코드를 이해한다”)
• 온보딩이 느림

이것들은 모두 아키텍처적 증상이다.

팀 규모 확장 전 체크리스트

1. 경계가 명시적인가?
2. 소유권이 명확한가?
3. 팀이 독립적으로 작업할 수 있는가?
4. 계약이 안정적인가?
5. 아키텍처가 원하는 커뮤니케이션 패턴을 반영하는가?

답이 ‘아니오’라면, 먼저 아키텍처를 확장하라.

아키텍처가 미치는 광범위한 영향

아키텍처는 다음을 형성한다:

• 팀
• 커뮤니케이션
• 속도
• 문화

Conway’s Law를 뛰어넘을 수는 없지만, 이를 염두에 두고 설계할 수 있다.

작성자: Cristian Sifuentes – 조직이 .NET 시스템에서 아키텍처, 커뮤니케이션, 기술적 경계를 정렬하여 팀을 확장하도록 돕습니다.