MINERVA Phase C-10 — 개발 조직 설계 (Platform 팀 vs Domain 팀, 모듈 소유권)

Conway’s Law — 시스템은 조직을 닮는다 — 1.5명에서 50명으로 가는 동안의 4가지 팀 패턴과 모듈 소유권

Phase C-10은 Phase C의 마지막 — Phase A부터 C-9까지의 모든 인프라가 1.5명 개발 환경에서 50명 개발·1000명 사용자 환경으로 옮겨갈 때 무엇이 바뀌는가. 본 편은 조직 설계가 시스템 설계를 결정하는 Conway’s Law, Team Topologies 4 패턴(Stream-aligned·Platform·Enabling·Complicated subsystem), MINERVA의 4팀 구조, CODEOWNERS·PR·온콜 책임, 인터페이스 계약, 인지 부하 분산, 신규 팀원 onboarding, 자주 발생 함정을 정리한다.

Agent
저자

Kwangmin Kim

공개

2026년 05월 06일

1 왜 조직 설계가 시스템 설계인가

Conway’s Law

“조직이 시스템을 설계할 때 그 시스템은 그 조직의 의사소통 구조를 닮은 모양이 된다.” — Melvin Conway (1968)

조직과 시스템 모양은 한쪽 방향이 아니라 양방향으로 영향을 준다. 설계가 안 좋으면 조직 통신이 비효율, 통신이 분리되면 시스템도 분리.

따라서 시스템 설계 변경은 조직 설계 변경과 함께 — 그 반대도.

Phase A~C-9까지의 인프라가 1.5명·소규모에서는 1명이 모든 것을 알고 운영. 그러나 50명 개발·1000명 사용자가 되면:

1.5명 환경 50명 환경
한 사람이 BaseAgent·스킬·문서·운영을 다 안다 영역별 팀이 분리, 인터페이스 계약 필요
빠른 결정 — 회의 없이 코드 바로 push PR review·governance·on-call rotation
깊은 컨텍스트 (이 시스템 왜 이렇게?) 인지 부하 분산 — 한 사람이 모든 것 알 수 X
1인 1온콜 24/7 rotation·escalation·rollback 절차
사용자 5명 직접 대화 customer success·support 팀

조직 설계가 사전에 잘 잡혀야 — 시스템도 깨끗하게 진화.

2 Team Topologies 4 패턴

[Skelton & Pais 2019]가 제안한 모던 팀 구조:

[Stream-aligned team]
  비즈니스 가치 흐름 단위 — 사용자 그룹 또는 도메인을 끝까지 책임
  예: Sales 도메인팀, R&D 도메인팀

[Platform team]
  공통 인프라 제공 — 다른 팀이 self-service로 사용
  예: BaseAgent·하네싱·관측성·CI/CD

[Enabling team]
  특정 영역 전문성으로 다른 팀의 학습·도입 가속
  예: ML·데이터 사이언스 컨설팅, 보안 enabling

[Complicated subsystem team]
  복잡한 sub system을 깊은 전문성으로 운영 — 다른 팀이 의존
  예: 검색 엔진·임베딩 인프라·LLM provider 추상화

Stream-aligned team이 1차 — 가치 흐름. 다른 3가지는 stream-aligned team이 빨리 일하도록 지원.

3 MINERVA 4팀 구조

[Platform Team]       BaseAgent v2·하네싱·관측성·실험 파이프라인·생명주기
                       → C-2·C-3·C-6·C-9 인프라
        ↓ self-service

[Domain Teams]        Sales·R&D·Finance·Support 도메인별 스킬·콘텐츠·페르소나
                       → C-7 스킬·C-8 콘텐츠·C-4 개인화
        ↓ 사용자 직접 대응

[SRE Team]            SLO·incident·운영 dashboard·on-call rotation
                       → C-25 실행 제어·C-34 관측성

[Governance Team]     보안·compliance·거버넌스·red team
                       → C-36 보안·C-19 governance review

각 팀이 다른 인지 부하를 가짐 — 한 사람이 4팀의 모든 영역을 알 필요 X.

3.1 Platform Team — 공통 인프라

책임: - BaseAgent contract 정의·버전 관리 (02-1) - 하네싱 인프라 (C24) - 실험 파이프라인 (C19) - 스킬 레지스트리 (C28) - 관측성·CI/CD (C34·07-1)

SLA: - 인프라 99.9% 가용 - API breaking change는 deprecation 90일 후 - self-service 도구 제공 (스킬 등록·실험 등록·dashboard)

팀 크기 (예상): 5~10명.

3.2 Domain Teams — 가치 흐름

책임: - 도메인 페르소나·스킬 정의 (C18·C27) - 도메인 콘텐츠 큐레이션 (C31) - 도메인 사용자 피드백·실험 (C19) - 도메인 SLA (사용자 만족도)

SLA: - 사용자 thumbs_up_rate ≥ 0.55 - 신규 use case 도입 cycle ≤ 4주 - 도메인 dashboard 매주 review

팀 크기 (예상): 도메인당 3~5명. 4 도메인이면 12~20명.

3.3 SRE Team — 운영

책임: - SLO 정의·burn rate alert (C34) - Incident 대응·rollback (C25) - 비용 모니터링 (C35) - On-call rotation·post-mortem

SLA: - p1 incident 응답 < 15분 - post-mortem 5 영업일 내 작성 - 분기 회고로 회귀 방지

팀 크기 (예상): 3~5명 (24/7 rotation 가능 최소).

3.4 Governance Team — 보안·규정

책임: - 보안 review·red team (C36) - Compliance audit (GDPR·HIPAA·KISA) - Governance review (위험 변경 — pricing·외부·정책) - 분기 권한·secret rotation review

SLA: - 변경 review 5 영업일 내 - 분기 보안 회귀 통과율 100% - compliance audit 무위반

팀 크기 (예상): 2~4명. 외부 audit 파트너 포함.

4 Module 소유권 — CODEOWNERS

# .github/CODEOWNERS
# Platform team
/app/agents/base_agent.py        @platform-team
/app/harness/                    @platform-team
/app/experiments/                @platform-team
/app/observability/              @platform-team
/app/skills/registry/            @platform-team

# Domain teams
/skills/sales_*/                 @domain-sales
/skills/rnd_*/                   @domain-rnd
/skills/finance_*/               @domain-finance @governance-team
/skills/support_*/               @domain-support

# Knowledge collections
/config/collections/sales.yaml   @domain-sales
/config/collections/finance.yaml @domain-finance @governance-team

# SRE
/config/slo.yaml                  @sre-team
/config/alerts.yaml               @sre-team
/.github/workflows/               @sre-team @platform-team

# Governance
/config/access.yaml               @governance-team
/config/retention.yaml            @governance-team @platform-team
/scripts/red_team.py              @governance-team

# 모든 변경에 SRE notify (실행 영향)
/app/agents/                      @platform-team @sre-team

PR 자동 reviewer 할당 — 코드 변경 시 책임 팀이 즉시 알림. 사람 누락 X.

5 On-call Rotation

영역 1차 2차 escalation
Platform 인프라 down Platform on-call Platform lead
Domain SLA 위반 Domain on-call Domain lead → Platform
비용 spike SRE on-call SRE lead → CFO
보안 incident Governance on-call Governance lead → CISO
LLM provider 장애 Platform on-call Platform lead

각 팀별 on-call rotation — 한 사람이 모든 영역의 on-call X. 인지 부하·번아웃 회피.

6 인터페이스 계약

팀 간 의존은 명시적 계약. 코드 reading으로 추론하지 않게.

6.1 Platform → Domain

# app/skills/registry/contract.py — Platform 제공
class SkillContract(Protocol):
    """Domain team이 구현해야 할 contract."""
    skill_id: str
    version: str

    async def execute(self, **kwargs) -> dict: ...
    def required_tools(self) -> list[str]: ...


# Domain team이 이 contract를 구현
class SummarizeDoc(SkillContract):
    skill_id = "summarize_doc"
    version = "1.3.0"
    ...

contract 변경은 Platform team이 deprecation 절차 — 90일 알림 후 변경.

6.2 Domain → Platform

# app/skills/registry/feedback.py — Domain이 보내는 신호
class DomainFeedback(BaseModel):
    """Domain이 Platform에게 보내는 metric·issue."""
    domain: str
    issue_type: str                       # "skill_quality" | "knowledge_gap" | "infra_request"
    severity: str
    description: str


# Platform이 받아서 처리
@feedback_router.post("/feedback")
async def submit_feedback(feedback: DomainFeedback): ...

비공식 Slack 메시지 X — schema 있는 ticket. 추적·우선순위·SLA 명확.

7 인지 부하 분산

각 팀 멤버가 자기 도메인 + 인접 도메인 표면 정도만 알도록.

Platform team
├── 깊이: BaseAgent·하네싱·관측성 internals
├── 표면: 도메인 페르소나는 어떻게 작동하는지
└── 차단: 콘텐츠 도메인의 비즈니스 정책

Domain team
├── 깊이: 도메인 사용자·콘텐츠·페르소나
├── 표면: BaseAgent contract·skill registration 사용법
└── 차단: 하네싱·실험 인프라 internals

SRE
├── 깊이: SLO·incident·dashboard
├── 표면: BaseAgent의 latency 특성·실험 결과 영향
└── 차단: 도메인 콘텐츠 결정·skill 작성

Governance
├── 깊이: 보안·compliance·red team
├── 표면: 모든 팀의 권한 의존
└── 차단: 일반 운영·도메인 결정

이 분산이 새 팀원 onboarding 시간을 단축. 한 영역만 깊이 알면 즉시 기여 가능.

8 Cross-team 협업 패턴

8.1 Synchronous (회의)

회의 주기 참석 목적
Architecture review 분기 모든 팀 lead Phase C-10 인프라 진화
Incident post-mortem incident마다 영향 팀 회귀 방지
Roadmap planning 분기 lead·PO 우선순위 align
Domain sync 주간 Platform + Domain lead 인터페이스·요청

8.2 Asynchronous (도구)

도구 사용
GitHub PR 코드 리뷰·discussion
Slack channels #platform·#domain-*·#sre·#incident
Confluence·Notion 결정 기록·post-mortem 영구
Linear·Jira 작업 ticket·SLA

비동기 우선 — 회의는 동기 결정이 필요할 때만.

9 신규 팀원 Onboarding

체크리스트 — 일주일 내 첫 PR, 한 달 내 독립 기여:

# docs/onboarding.yaml
day_1:
  - 권한 부여 (RBAC role 매칭)
  - 개발 환경 setup (env_vars·VPN·docker compose)
  - architecture 개요 30분 (Phase A·B·C-1·C-2 영상)

week_1:
  - 자기 팀 영역 코드 read-through
  - 인터페이스 계약 (다른 팀 의존)
  - golden eval 작성 (작은 PR)

month_1:
  - 도메인 mid-sized 변경 리드
  - on-call shadow (다른 팀 lead 옆)

month_3:
  - 자기 영역 ownership
  - on-call rotation 진입
  - architecture review 발표 1회

각 단계별 산출물이 명시 — onboarding 진행 가시화.

10 자주 발생하는 함정

10.1 Silo

각 팀이 다른 팀 모르고 자기 영역만 봄 → 통합 시점에 인터페이스 깨짐.

해법: - 분기 architecture review 강제 (모든 팀 lead 참여) - Cross-team rotation (1년에 한 번 다른 팀 1주 shadow) - 인터페이스 계약 문서화

10.2 Bus Factor

한 사람만 BaseAgent internals 안다 → 그 사람 휴가·이직 시 마비.

해법: - 모든 핵심 영역 최소 2명 deep knowledge - pairing·code review로 지식 공유 - 분기 knowledge audit — bus factor 1인 영역 발견 시 즉시 plus 1

10.3 Shadow Team

공식 조직표에 없는 비공식 팀이 critical infra 운영 → governance·SLA 없음.

해법: - 분기 organization map 갱신·공유 - 새 영역 발생 시 즉시 ownership 결정 - 모든 critical service에 CODEOWNERS 강제

10.4 Platform Team의 Ivory Tower

Platform team이 도메인 사용자와 단절 → 이론적 인프라만 만들고 실제 사용 안 됨.

해법: - Platform PM이 분기마다 도메인 사용자 인터뷰 - 새 인프라 features는 도메인 팀과 co-design - Platform team 멤버도 도메인 dashboard 매주 review

10.5 Domain Team의 Reinventing

공통 인프라가 있는데 자기 도메인에 별도 구현 → 운영 부담·일관성 깨짐.

해법: - Architecture review에서 cross-team duplication 검출 - Platform team이 self-service 도구 친절히 (개발자 경험 ↑) - “build vs buy”가 아니라 “build vs use platform”

10.6 24/7 On-call Burnout

작은 팀이 24/7 rotation 책임 → 번아웃 → 사람 잃음.

해법: - On-call 최소 4명 (1주에 1번 이내) - 글로벌 분산 (US·EU·KR rotation으로 24/7 자연 커버) - 24/7 critical incident만 page, 나머지 다음날 처리

10.7 책임 회피 (Accountability Vacuum)

“내 영역 아닌데” → 회색지대 incident 대응 X.

해법: - 모든 코드 경로에 CODEOWNERS - “아무도 책임 안 지면 SRE가 임시 책임” — 이후 governance review로 ownership 결정 - Post-mortem에 “책임 회피” 항목 — 패턴 반복 시 조직 변경

10.8 Org Change without System Change

조직만 분리하고 코드는 monolith → “팀이 분리됐는데 같은 PR에서 충돌만 늘었음”.

해법: - 조직 변경 시 code modularization 동시 (Conway’s Law 반영) - 팀 분리 = module boundary clarification - 분리 어려운 module은 platform 또는 complicated subsystem team으로 흡수

11 정리

영역 핵심
Conway’s Law 시스템·조직 양방향 영향
Team Topologies Stream-aligned·Platform·Enabling·Complicated subsystem
MINERVA 4팀 Platform·Domain·SRE·Governance
모듈 소유권 CODEOWNERS·PR·on-call·SLA
인터페이스 계약 명시적 schema·deprecation 절차
인지 부하 깊이 + 인접 표면, 차단 영역 명시
Onboarding day-1·week-1·month-1·month-3 체크리스트
함정 silo·bus factor·shadow team·ivory tower·reinvent·burnout·vacuum·org-without-system

12 응용 분야

시나리오 핵심
1.5명 → 5명 전환 모듈 boundary 정리, CODEOWNERS 도입
5명 → 20명 전환 Platform·Domain 분리
20명 → 50명 전환 SRE·Governance 분리, 24/7 on-call
도메인 추가 새 Domain team or 기존 확장 결정
신규 팀원 onboarding 체크리스트로 가속
인터페이스 변경 deprecation 90일 + 영향 팀 사전 통보
Incident 회귀 post-mortem + ownership 명확화

13 관련 주제

선행 학습 (선수)

후속 (Phase C-10)

Cross-reference

Subscribe

Enjoy this blog? Get notified of new posts by email: