개인·팀·조직 지식 통합: 중앙집중 대신 federation

들어가며: 합치는 게 왜 어려운가

6편까지는 한 프로젝트 안의 이야기였다. 이제 시야를 넓힌다. 한 사람이 캔 지식, 한 팀이 쌓은 결정, 여러 팀의 인사이트를 개인 → 팀 → 다(多)팀 → 조직으로 합쳐 하나로 만들어야 한다.

업계는 여기에 답을 판다. **"단일 진실 공급원(single source of truth)"**이다. Google은 2026년 Gemini Enterprise의 Agent Registry를 "엔터프라이즈의 단일 진실 공급원"으로 내세운다.¹ 매력적으로 들린다. 그런데 이건 잘못된 목표다.

어려움은 저장이 아니다. 부분적 관점들을, 그것을 참으로 만든 맥락째로, 평탄화하지 않고 위로 올리는 것이 어렵다. A팀에서 "고객은 빠른 응답을 원한다"가 참인 건 그 팀의 고객·제약 안에서다. 그걸 조직 위키에 한 줄로 박아 넣는 순간 맥락이 날아가고, B팀은 그 한 줄을 자기 맥락에 잘못 적용한다. 그래서 결론은 이렇다.

• 이건 중앙집중 문제가 아니라 federation 문제다. 목표는 단일 진실 공급원이 아니라 단일 종합 공급원이다.
• 지식 창조는 사다리를 오른다(개인→그룹→조직). 이 시리즈의 ADR/Wiki 파이프라인이 그 사다리의 구현이다.
• 자발적 수평 구조는 딜리버리 압력에 무너진다. 그래서 집계는 회의가 아니라 워크플로우에 배선해야 한다.

중앙집중이 아니라 federation이다

데이터 진영이 같은 문제를 먼저 풀었다. Zhamak Dehghani의 data mesh는 federated computational governance를 제시한다. 도메인(팀)이 로컬에서 HOW를 정하고, 얇은 federation이 WHAT(전역 표준)만 정하며, 그 전역 규칙은 중앙 위원회가 아니라 플랫폼이 계산적으로 강제한다.²

이걸 지식에 그대로 옮기면 그림이 분명해진다. 팀 위키와 ADR은 그 팀이 소유한 채 로컬에 남는다. 중앙은 모든 세부를 복제하는 곳이 아니라, 상호운용 표준(엔티티 ID 체계, 권한 규칙, 승격 게이트)만 강제하는 얇은 층이다. 이건 사실 Hermes 엔티티 모델 + permission-before-search 설계와 같은 것인데, 이제 그 뒤에 이름 있는 거버넌스 이론이 붙는 셈이다.

그래서 "단일 진실 공급원" 대신 **"단일 종합 공급원(single source of synthesis)"**이 맞다. 중앙은 진실을 보관하지 않고 종합한다. 한 프로젝트에서는 이걸 아주 물리적으로 지켰다. 회의록 본문은 원본 협업 도구에 남기고, 저장소에는 포인터와 백링크만 뒀다. 결정 노트에 이유를 짧게 적었는데, 요지는 사본은 늙는다는 것이었다. 중앙이 무언가를 보관하기 시작하는 순간 그 사본은 원본보다 먼저 stale 해지고, 그래서 중앙은 콘텐츠가 아니라 인덱스만 들고 있어야 한다. 단일 진실 공급원도 물리·연합·가상의 형태가 있지만, 조직 프로세스와 거버넌스 없이 그 자체를 위해 만들면 "비싸기만 하고 쓸모없다."¹

솔직히 적자면, 내가 통과한 한 프로젝트에서는 정반대 결정을 내렸다. 단일 팀이 소유하는 한 저장소 안에서는 문서 디렉터리를 정본으로 못 박았고, 코드와 문서가 충돌하면 문서가 이긴다는 중앙집중 규칙을 그대로 박았다. 결정자가 한 명이고 소유 경계가 없는 곳에서 federation은 그냥 과잉설계였다. 그러니 federation이 SSOT를 대체한다는 식으로 읽으면 곤란하다. 깨지는 축은 팀 대 조직이 아니라 소유권 경계다. 하나의 소유 도메인 안에서는 중앙 SSOT가 맞고, federation은 그 경계를 넘는 순간에 비로소 값을 한다.

지식 창조는 사다리를 오른다

이 사다리에는 이론적 엔진이 있다. Nonaka와 Takeuchi의 SECI 모델이다. 지식은 암묵지와 명시지의 변환 나선(Socialization → Externalization → Combination → Internalization)으로 창조되고, 그 나선은 개인 → 그룹 → 조직 → 조직 간으로 올라가도록 설계됐다.³

이 시리즈가 한 일이 정확히 이 나선의 구현이다.

Nonaka가 말한 Ba(지식이 창조되는 공유 맥락/공간)는 여기서 git + 마크다운이다. 즉 이 시리즈의 파이프라인은 SECI 나선을 마크다운으로 돌리는 한 구현이라고 말할 수 있다.

자발적 수평 구조는 무너진다

그런데 사다리를 올리는 사회적 구조는 깨지기 쉽다. 이 시리즈를 정직하게 지키려면 가장 유명한 실패를 봐야 한다. Spotify 모델이다.

2012년 백서의 길드(guild, 관심 기반 자발적 모임)와 챕터(chapter, 직능 기반)는 "팀을 가로지르는 수평 지식 공유"의 교과서적 형태였고, 수많은 회사가 베꼈다. 그런데 정작 Spotify에서 이건 스냅샷이지 청사진이 아니었다. Jeremiah Lee의 "Spotify's Failed #SquadGoals"가 보여주듯, 길드·챕터의 지식 공유는 늘 스쿼드의 딜리버리에 밀렸다. "자율성은 팀을 효과적으로 만들었지만, 자율적인 팀들의 집합은 종종 효과적이지 못했다."⁴

교훈은 분명하다. 사람이 자발적으로 모이기를 기대하는 지식 집계 층은 딜리버리 압력에 진다. Communities of Practice도 마찬가지다. 진짜 커뮤니티가 없으면 그 산출물(공유 레퍼토리)은 썩는다.⁵ 그래서 집계는 "월간 지식공유 회의"가 아니라 워크플로우 자체에 배선해야 한다. 이게 이 시리즈가 ADR feed-forward(6편)에 집착한 이유다.

엔지니어 네이티브 집계 메커니즘

그러면 어떻게 워크플로우에 배선하는가. 엔지니어에게 익숙한 메커니즘이 이미 있다.

• Team Topologies의 3가지 상호작용 모드. Skelton과 Pais는 팀 간 지식이 Collaboration / X-as-a-Service / Facilitating이라는 명시적 채널로 흐른다고 본다.⁶ 특히 플랫폼 팀 사고가 핵심이다. 지식 기질을 self-serve 내부 프로덕트로 노출하면(위키를 X-as-a-Service로), 다른 팀이 회의 없이 가져다 쓴다.
• InnerSource의 Trusted Committer. 오픈소스 협업 방식을 사내에 적용해, 기여(PR)를 공유의 단위로 삼는다. Trusted Committer는 외부 팀의 기여를 검토하고 전문성을 옮기는 cross-team 스튜어드다.⁷ 이게 project → team → org 승격을 검토하는 인간 게이트, 즉 이 시리즈의 승격 리뷰 게이트를 PR 단위로 구현한 것이다.
• After-Action Review(AAR). 미 육군이 만든 사후 검토(무엇을 하려 했나 → 실제 무엇이 → 왜 차이 → 무엇을 유지/개선)는 중앙 lessons-learned DB로 흘러든다.⁸ 그 구조(배경→무엇→왜→교훈)는 ADR(맥락→문제→옵션→결정)과 사실상 동형이고, 중앙 DB는 조직 단위 결정/인사이트 인덱스 그 자체다.

이 세 가지의 공통점은 공유가 자발적 선의가 아니라 워크플로우의 부산물로 나온다는 것이다. PR을 머지하면 지식이 옮겨가고, 회고를 적으면 교훈이 인덱스에 쌓이는 식이다.

AI 에이전트도 같은 사다리를 재발명하고 있다

흥미로운 2025~2026년 신호. AI 에이전트 메모리가 이 사회적 사다리를 독립적으로 데이터 모델로 재발명하고 있다. 멀티 스코프 메모리는 모든 쓰기를 user_id / agent_id / org_id 같은 스코프로 태깅하고, org_id는 문자 그대로 "공유 조직 맥락"이 되어 검색 시점에 종합된다.⁹ 사람의 개인→팀→조직 사다리와 같은 모양이다.

내가 본 한 프로젝트도 같은 방향으로 결정했다(아직 구현 전이다). 에이전트의 모든 recall을 협업 단위 단위로 스코프 태깅하고, 세션 연속성과 세션 복구를 다른 저장소에 다른 책임으로 분리한다는 방향이었다. 둘을 섞으면 거짓 복구가 난다고 결정 노트에 적어 뒀다. 다만 메모리 substrate를 도구가 거저 주지는 않더라. 에이전트를 거치지 않은 사람의 행동은 자동으로 기록되지 않아서, 그 맥락은 도메인이 직접 밀어 넣어야 했다. "저장소에 있겠지"라는 가정이 가장 위험한 staleness였다.

이게 시사하는 바가 크다. 사람과 에이전트가 같은 staleness 문제, 같은 identity-resolution 문제를 동시에 겪는다는 뜻이고, 그래서 둘 다를 떠받치는 durable substrate(엔티티 모델 + 스코프 태깅된 출처 + federated governance)는 특정 도구가 아니다. 단, federation은 리터러시가 팀 간에 평준화돼야 작동한다. 2026년 조사에서 기업 리더의 72%가 AI 리터러시를 필수라 하면서 59%가 자기 조직에 역량 격차가 있다고 답했다.¹⁰ 한 팀만 잘 알아서는 종합이 안 된다.

flowchart TB
  subgraph D1["팀 A 도메인"]
    A1[Wiki/ADR 로컬 소유]
  end
  subgraph D2["팀 B 도메인"]
    B1[Wiki/ADR 로컬 소유]
  end
  subgraph D3["팀 C 도메인"]
    C1[Wiki/ADR 로컬 소유]
  end
  FED["얇은 federation<br/>엔티티 ID · ACL · 승격 게이트"]
  A1 --> FED
  B1 --> FED
  C1 --> FED
  FED --> SYN["단일 종합 공급원<br/>(중앙 인덱스, 복제 아님)"]
  SYN -. SECI 나선: 개인→팀→조직 .-> SYN

Tanzu의 균형 팀이 관점을 한 명에게 몰아넣지 않고 "먼저 다 꺼내 놓고 테마로 묶는" 방식, 삼성SDS가 팀마다 'AI Crew'를 두어 팀별 암묵지를 발굴·확산하는 방식 모두, 조직 지식을 중앙화하는 대신 연합하는 같은 정신이다.

정리

• 개인→팀→조직 지식 통합은 저장 문제가 아니라 federation 문제다. 부분적 관점을 맥락째로, 평탄화 없이 올려야 한다. 목표는 단일 진실 공급원이 아니라 단일 종합 공급원이다.
• data mesh의 federated computational governance가 모델이다. 도메인이 HOW를, 얇은 federation이 WHAT(엔티티 ID·ACL·승격 게이트)만 강제한다. = Hermes 엔티티 모델에 붙는 이름 있는 이론.
• 지식 창조는 SECI 나선으로 사다리를 오른다. 이 시리즈의 ADR(Externalization)→Wiki(Combination)가 그 구현이고, git+마크다운이 Ba다.
• 자발적 수평 구조는 딜리버리 압력에 무너진다(Spotify 길드). 그래서 집계는 워크플로우에 배선한다. Team Topologies의 X-as-a-Service, InnerSource의 Trusted Committer, AAR의 lessons-learned DB가 엔지니어 네이티브 메커니즘이다.
• AI 에이전트 메모리도 user/agent/org 스코프로 같은 사다리를 재발명 중이다. 사람과 에이전트가 같은 문제를 겪으므로, durable substrate는 도구가 아니라 엔티티 모델 + 스코프 태깅 + federation이다.
• 다만 이 글의 이상을 내 프로젝트가 다 지켰느냐고 물으면, 아니다. 어떤 프로젝트에서는 깨끗한 federation 친화 설계를 포기하고 기존 스키마와 제약을 그대로 상속했다. 결정 노트에 "솔직히"라는 단어까지 넣어 트레이드오프로 남겼다. 범위가 작고 마감이 빠를 때는 federation의 이상보다 기존 중앙 자산을 재사용하는 쪽이 이긴다. federation은 옳은 방향이지만, 항상 옳은 선택은 아니다.

마지막 글에서는 이 시리즈 전체를 닫는다. 지금까지 만든 모든 산출물(인테이크·as-is 맵·위임 결정·데이터 계약·ADR·federation 규칙)이 클로드 코드·Codex·Multica가 다 바뀌어도 살아남는 이유, 즉 도구가 아니라 기질에 사는 법.

참고 자료

federation vs 중앙집중

• Data Mesh Principles (Zhamak Dehghani, martinfowler.com)
• The truth about the single version of truth (Peter Baumann)

지식 창조 · 커뮤니티

• SECI model (Nonaka & Takeuchi)
• Introduction to Communities of Practice (Wenger-Trayner)

팀 간 지식 흐름 메커니즘

• Team Topologies key concepts (Skelton & Pais)
• Trusted Committer pattern (InnerSource Commons)
• After-action review

실패 사례 · 2026 신호

• Spotify's Failed #SquadGoals (Jeremiah Lee)
• State of AI Agent Memory 2026 (Mem0)