01. 모놀리식 그래프 문제 — Conway’s law @ 그래프

회사가 5명일 때 schema.graphql은 축복이다 — 모든 타입이 한 곳에 있고 IDE에서 점프할 수 있다. 회사가 500명일 때 같은 schema.graphql은 저주다 — 한 PR이 머지되려면 10팀의 리뷰가 필요하다.

이 문서는 왜 그렇게 되는지를 Conway’s law의 관점에서 설명한다.

한 줄 답

모놀리식 그래프의 한계는 서버 성능이 아니라 조직의 PR 큐다. 한 파일을 N개 팀이 공유하면 변경의 원자성과 팀의 자율성이 충돌한다. 이 충돌은 코드로는 풀리지 않는다 — 구조가 바뀌어야 한다.

Why — 왜 모놀리식 그래프가 깨지는가

Conway’s law 복습

“Organizations design systems that mirror their communication structure.” — Melvin Conway, 1967

이걸 그래프에 적용하면:

팀이 하나면 — 모놀리식 그래프가 가장 자연스럽다.
팀이 셋이면 — Order/User/Catalog 같은 기능 경계가 schema 안에 등장한다.
팀이 서른이면 — schema는 모든 팀의 정치적 합의가 된다.

GraphQL 스키마는 프로젝트의 ABI다. ABI를 N팀이 공유하면 변경의 비용이 N에 비례해 기하급수적으로 증가한다.

모놀리식이 깨지는 4가지 실체

1. PR 큐 직렬화 (Deployment coupling)

한 schema 파일을 모두가 수정하면 — 머지 충돌, 리뷰 대기, 배포 게이트가 한 줄로 늘어선다.

A팀: "Order에 새 필드 추가합니다" — PR #1234
B팀: "User에 새 필드 추가합니다" — PR #1235 (충돌!)
C팀: "Catalog에 필드 삭제" — PR #1236 (B팀 영향?)

→ 팀 간 독립 배포가 불가능. 한 팀의 배포가 다른 팀의 머지를 막는다.

2. 소유권 모호성 (Ownership ambiguity)

type User {
  id: ID!
  name: String          # User팀이 소유
  orders: [Order!]!     # Order팀이 소유?? User팀이 소유??
  reviews: [Review!]!   # Review팀이 소유??
}

User 타입은 누구 것인가? 모놀리식에선 답이 없다. 그래서 전사 위원회가 의사결정 권한을 갖게 되고, 위원회는 느리다.

3. 빌드 결합 (Build coupling)

한 팀의 변경이 컴파일 에러를 내면 전체 모노레포 빌드가 깨진다. CI 시간은 조직 크기에 비례해 늘어난다 — 어떤 회사는 30분 빌드를 본다.

4. 도메인 누수 (Domain leakage)

type Order {
  id: ID!
  items: [LineItem!]!
 
  # Order 팀이 알 필요 없는 promotion 로직이 새어들어옴
  appliedPromotions: [Promotion!]!
  loyaltyPoints: Int!
}

다른 팀의 필드를 내 타입에 끼워넣는 일이 일상이 된다 — bounded context가 무너진다.

How — 모놀리식이 견딜 수 있는 규모

Dunbar 임계와 비슷한 패턴

회사 크기	모놀리식 그래프?	비고
1~5명	★★★	그냥 monolith 써라. 빠르고 단순.
5~30명	★★	한 팀 안에서 모듈 분할로 견딘다 (e.g., `schema/user.graphql`).
30~150명	★	위원회·코드 오너십·디렉토리 분할로 겨우 버틴다.
150명+	✗	federation 또는 분리된 그래프가 거의 강제된다.

150명 ≈ Dunbar number. 모든 사람의 변경을 모든 사람이 추적할 수 있는 임계. 그 위로 가면 집단 인지가 깨진다.

모놀리식이 부분적으로 견디는 패턴

Codeowners 분할: 디렉토리별 CODEOWNERS 파일. 하지만 type 간 참조가 있으면 여전히 cross-팀 리뷰가 필요.
Modular schema: schema/order/*.graphql + schema/user/*.graphql로 파일을 분리. 빌드 타임에 한 파일로 합친다. 하지만 런타임 결합은 여전히 동일.
Backend for Frontend (BFF): 각 클라이언트마다 자기 그래프. 하지만 이건 그래프 자체의 통합을 포기한 셈.

What — 모놀리식 그래프의 4가지 안티패턴 시그널

당신의 회사가 모놀리식 그래프에서 이미 고통받고 있다는 신호다.

시그널	증상	원인
PR이 1주일 이상 떠 있다	머지 대기열 길이 ≥ 5	리뷰 권한이 한 팀에 집중
*새 필드 추가가 전사 회의가 된다*	매주 schema 리뷰 미팅	의사결정의 위원회화
다른 팀의 변경에 매번 영향받는다	CI 깨짐 알림 일평균 ≥ 3	빌드 결합
”그 필드 누가 만들었지?” 질문이 일상	`git blame`이 5명을 가리킴	소유권 분산

이 중 둘 이상이라면 — Federation을 진지하게 고려할 때다.

What-if — 모놀리식을 고집하면 일어나는 일

Case 1: GitHub의 결정 (2016~)

GitHub은 모놀리식 GraphQL을 공개 API v4로 채택했다. 그들은 외부 클라이언트에는 monolith가 맞다고 판단했다 — 외부인이 내부 팀 경계를 알 필요가 없으니까. 대신 내부 팀의 PR 큐는 GraphQL 인프라 팀이 정책으로 관리한다.

→ 모놀리식이 외부 일관성을 위해선 옳을 때가 있다는 사례.

Case 2: Netflix Studio Edge (2019~)

Netflix는 수십 개 백엔드 서비스를 Studio 직원 200명에게 노출해야 했다. 처음엔 BFF 한 개를 만들었는데 — BFF 자체가 병목이 됐다. BFF 팀이 모든 변경을 처리해야 했으니까.

→ 그래서 federation으로 전환. 각 백엔드 팀이 자기 subgraph를 직접 소유하게 했다.

Case 3: Airbnb의 반대 결정 (2020s)

Airbnb는 한때 federation을 검토했지만 내부 분석 결과 monolith가 더 빠르다고 결론냈다 — 그들의 조직은 기능별로 강하게 분리되지 않았고, 한 PR이 여러 서비스를 건드리는 경우가 많아서 federation의 팀 독립성 가정이 깨졌다.

→ federation은 조직이 이미 잘 분리됐을 때만 효과를 본다.

Insight — Conway’s law의 역방향

“Reverse Conway Maneuver” — 시스템을 원하는 조직에 맞춰 먼저 설계하면, 조직이 그 모양으로 따라온다. (Forsgren, Accelerate, 2018)

Federation을 도입하면 — 그래프가 팀 경계를 요구한다. 명확한 owner가 없으면 subgraph를 만들 수 없다. 그래서 federation 도입이 조직 정리의 강제력이 되기도 한다.

흥미로운 사실: Apollo가 2019년 federation v1을 발표하면서 가장 강조한 문구는 *“team autonomy”*였다 — 기술 문서인데 조직 용어가 헤드라인이었다.

“왜 facebook 본진은 federation을 안 쓰나?”

Meta는 monolith를 쓴다 (Relay + 거대한 단일 graph). 이유: 그들의 monorepo 문화는 전사 빌드/배포가 같이 가는 것을 전제로 한다. 즉, 조직 자체가 monolith처럼 굴러간다. Conway’s law의 재귀다.

요약 + Mermaid

모놀리식 그래프는 서버가 아니라 조직에서 깨진다. Dunbar 150명 · PR 큐 직렬화 · 소유권 모호성 · 빌드 결합 — 네 가지 증상이 모두 나타나면 federation이 필요하다. 하지만 조직이 강하게 분리되지 않았다면 federation이 오히려 짐이 된다.

📖 개요 02. Stitching → Federation 역사 — 2017 → 2019 → 2022