---
title: "IT 인텔리전스(IT Intelligence): 엔터프라이즈 IT에 빠진 데이터 계층"
url: https://raskell.io/ko/articles/it-intelligence/
author: Raffael Schneider
date: 2026-11-04
description: "비즈니스 인텔리전스는 회사가 어떻게 팔고 있는지 알려 줍니다. 그러나 회사의 IT가 어떻게 맞물려 있는지는 아무것도 알려 주지 않습니다. 제가 엔터프라이즈 컨텍스트 플랫폼을 만들기 시작한 이유입니다."
tags: [enterprise-architecture, context-engineering, legibility, knowledge-management, provenance, democratisation, oss, future-of-work]
lang: ko
translation_of: https://raskell.io/articles/it-intelligence/
---

# IT 인텔리전스(IT Intelligence): 엔터프라이즈 IT에 빠진 데이터 계층

## 요약

기업들은 자신이 어떻게 팔고 있는지 알기 위해 비즈니스 인텔리전스를 만들었지만, 어떤 IT를 가지고 있는지, 누가 그것을 소유하는지, 그것이 어떻게 연결되어 있는지는 값싸게 답하지 못합니다. 저는 그 빠진 계층을 IT 인텔리전스라고 부릅니다. 사실들은 서로 분리된 기록 시스템에 흩어져 있고, 그 사이의 지식은 구전 지식과 지식 사일로 속으로 사라집니다. 암묵적 지식, 정보 정치, 지식 은폐에 관한 연구가 그 이유를 설명하는 데 도움이 됩니다. 제가 만들고 있는 엔터프라이즈 컨텍스트 플랫폼은 모든 소스를 수집하고, 정확도를 점수로 매기며, 출처와 신뢰도를 지닌 엔티티들의 온톨로지로 정리해 웹 UI, REST, MCP로 제공합니다. IT 컨텍스트는 기본적으로 열려 있어야 하고 오픈 소스 위에 지어져야 합니다. 컨텍스트가 없는 에이전트는 비싸게 탐색하고, 일을 중복하고, 추측하지만, 공유된 모델은 재발견을 조회로 바꾸기 때문입니다. 에이전트가 더 많은 코드를 쓰고 일이 한 단계 높은 추상화 수준으로 올라가면서, 희소한 구현 역량을 중심으로 만들어진 조직이 다음 병목이 되고, 조직은 그 모양을 바꿔야 할 것입니다.

큰 회사에 지난 분기 독일에서 보험 계약을 몇 건 팔았는지 물으면 몇 초 만에 답이 나옵니다. 차트와 추세선, 채널별 내역까지 함께 나옵니다. 같은 회사에 어떤 애플리케이션이 고객의 건강 데이터를 처리하는지, 누가 그것을 소유하는지, 어떤 클러스터에서 돌아가는지, 그중 어느 것이 이미 언어 모델을 호출하고 있는지 물으면, 회의가 잡히고, 이어서 스프레드시트가 오고, 그 스프레드시트가 CMDB와 맞지 않아서 두 번째 회의가 잡힙니다.

기업들은 30년 동안 비즈니스 인텔리전스를 만들어 왔습니다. 그러나 자기 IT를 위한 같은 것은 한 번도 만들지 않았습니다. 저는 그 빠진 것을 **IT Intelligence**(IT 인텔리전스)라고 부르기 시작했고, 그것을 제공하는 플랫폼을 **Enterprise Context Platform**(엔터프라이즈 컨텍스트 플랫폼)이라고 부르기 시작했습니다.

## 그 공백을 드러낸 일 {#the-job-that-made-the-gap-visible}

한동안 저는 스위스의 한 금융 그룹에서 에이전틱 AI와 AI 플랫폼을 담당하는 엔터프라이즈 솔루션 아키텍트로 일했습니다. 대형 보험 사업과 은행을 함께 거느리고, 열 개가 넘는 마켓 유닛을 통해 운영되는 그룹입니다. 제 과제는 조화였습니다. 모든 마켓 유닛의 솔루션 아키텍처 지침, 정책, 설계가 엔터프라이즈 아키텍처가 정의한 역량(capability)을 제대로 해석하고 있는지 확인하는 일이었고, 그 역량은 다시 기업 전략에서 도출된 것이었습니다.

서류상으로는 깔끔한 사슬입니다.

*The chain as it is drawn*

```text
   ┌──────────────────────────┐
   │ corporate strategy       │
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ enterprise architecture  │  capabilities, principles, target landscape
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ solution architecture    │  directives, policies, reference designs
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ 10+ market units         │  actual systems, actual teams, actual budgets
   └──────────────────────────┘
```

실제로는 각각의 화살표가 사람이 문서로, 저마다 다른 속도로 하는 번역입니다. 전략은 1년 단위로 움직이고, 역량 맵는 누군가 시간이 날 때 움직이며, 솔루션 설계는 프로젝트마다, 시스템 자체는 매일 움직입니다. 하나의 역량이 열 개의 마켓 유닛에서 해석되고 나면 열 개의 해석이 생기고, 그것들이 어디서 갈라지는지 값싸게 볼 방법은 없습니다.

무엇이 좋은 상태인지 아는 것은 그 일에서 쉬운 부분이었습니다. 실제로 무엇이 있는지 아는 것이 어려운 부분이었습니다. 모든 검토는 고고학으로 시작했습니다. 어떤 애플리케이션이 존재하는지, 그것들이 어떤 플랫폼 서비스를 쓰는지, 어느 팀이 소유하는지, EA 리포지토리의 항목이 아직 코드 리포지토리와 일치하는지, 그 코드 리포지토리가 아직 클러스터에서 돌아가는 것과 일치하는지를 먼저 파헤쳐야 했습니다.

최근 저는 이 문제에 더 잘 맞는 역할로 옮겼습니다. 지금은 AI 및 데이터 부문 안에서 일하는 그룹 AI 아키텍트이고, 목표는 비슷합니다. 모든 마켓 유닛에서 AI를 조화롭게 쓰는 것입니다. 다른 점은 이제 데이터와 플랫폼을 바깥에서 검토하는 대신 그 바로 옆에 앉아 있다는 것입니다. 그 덕분에 제가 계속 있었으면 하고 바랐던 것을 만들기 시작할 수 있었습니다.

## 전에 작은 것을 하나 만든 적이 있습니다 {#i-built-a-small-one-before}

엔터프라이즈 솔루션 아키텍트가 되기 전에 저는 그룹의 웹 서비스 딜리버리 플랫폼을 맡은 플랫폼 엔지니어이자 솔루션 아키텍트였습니다. WAF, CDN, 그리고 트래픽 셰이핑을 하는 여러 인그레스 프록시로 이루어진 플랫폼으로, 회사가 내부 경계와 인터넷에 노출하는 모든 것에 웹 보안과 웹 딜리버리 역량을 함께 제공했습니다.

그 팀은 이것저것 시도해 보기 좋은 곳이었습니다. 그중 하나가 AI의 도움을 받은 WAF 규칙 큐레이션이었고, 동료 Milan Duric(밀란 두리치)과 저는 이것을 RSAC 2026에서 발표했습니다. 보안 분야 밖의 독자를 위해 덧붙이면, RSAC는 예전에 RSA Conference라고 불리던 세계 최대 규모의 보안 콘퍼런스 가운데 하나로, 매년 봄 샌프란시스코의 Moscone Center에서 열립니다. 2026년 행사에는 4만 명이 넘게 모였습니다. 실무자, 연구자, CISO들과 나란히, 그 무대에는 실리콘밸리와 정부, 때로는 할리우드의 유명 인사들도 자주 오릅니다. 저는 2024년과 2025년, 이전에 두 번 참석했고, 세 번째에 연사로 프로그램에 이름을 올린 것은 제가 조용히 자랑스럽게 여기는 일입니다. 저희 발표는 [Self-Learning WAF: Using Generative AI to Tame ModSecurity False Positives](https://path.rsaconference.com/flow/rsac/us26/FullAgenda/page/catalog/session/1753946922633001YdMq)였습니다. 콘퍼런스 자체에 관해서는 [RSAC 2026 참관기](https://raskell.io/articles/notes-from-rsac-2026/)에 썼습니다.

다른 하나는 돌이켜 보면 한 스쿼드의 권한 범위에 맞춘 작은 엔터프라이즈 컨텍스트 플랫폼이었습니다. 문제는 이 글이 다루는 것과 같았고, 크기만 더 작았습니다. 애플리케이션 팀들은 자기 웹 서비스가 어떻게 노출되어 있는지, 어떤 WAF 규칙이 적용되는지, 앞단의 CDN이 어떻게 동작하는지, 자기 DNS 레코드가 실제로 무엇을 하는지 알고 싶어 했습니다. 답은 프록시, WAF, CDN 제공자의 콘솔, DNS에 흩어져 있었고, 질문하는 팀들은 그중 어디에도 접근 권한이 없었습니다. 그래서 그들은 저희에게 물었고, 저희 한 주의 상당 부분은 질문에 답하고 변경을 손으로 수행하는 데 들어갔습니다.

저는 스쿼드 영역의 모든 데이터 구조를 **매니페스트**(manifest)로 형식화했습니다. 노출, WAF 정책, CDN 구성, DNS 레코드, 그리고 그것들이 서로 어떻게 연결되는지를 선언적으로 기술하고 Git에 저장한 것입니다. 매니페스트 위에는 세 개의 계층이 놓였습니다.

*The web delivery self-service, one squad's scope*

```text
   ┌──────────────────────────┐
   │ Web frontend             │  self-service portal: see what is
   │                          │  exposed and how, order changes
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ API backend              │  control plane: validates requests,
   │                          │  starts workflows
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ Durable workflows        │  create, adjust and remove resources,
   │                          │  do the operator work
   └──────┬────────────┬──────┘
          ▼            ▼
    manifests in Git    WAF, CDN, ingress proxies, DNS
    (source of truth)
```

포털은 매니페스트를 감싼 파사드였습니다. 팀은 자기 서비스를 찾아서, 그것이 어느 경계를 통해 도달 가능한지, 어떤 WAF 규칙이 적용되는지, CDN이 어떻게 캐시하고 전달하는지, 어떤 DNS 레코드가 어디를 가리키는지를 한곳에서 볼 수 있었고, CDN 벤더의 계정이 전혀 필요하지 않았습니다. 변경이 필요하면 포털에서 주문했습니다. 백엔드가 컨트롤 플레인 역할을 하며 요청을 검증하고 지속형 워크플로를 시작했고, 워크플로는 예전에 사람인 운영자가 하던 일을 했습니다. Git의 매니페스트를 갱신하고, 변경을 WAF, CDN, 프록시, DNS에 적용하고, 결과를 확인하고, 필요하면 롤백했습니다. 시간이 지나면서 워크플로는 전담 운영자가 필요했던 운영 업무를 사실상 전부 넘겨받았습니다.

밀란과 저는 이 시스템을 RSAC 2027 연사 모집에 발표 주제로 제출했습니다. 

이 경험에서 얻은 세 가지 교훈이 이 글에서 다루는 플랫폼으로 곧바로 이어집니다. 데이터를 형식화하는 것이 어려운 부분이자 가치 있는 부분이었습니다. 매니페스트가 존재하고 나자 포털과 워크플로는 쉬웠습니다. 데이터를 모두가 읽을 수 있게 만들자 질문 대부분이 나오기도 전에 사라졌습니다. 그리고 데이터를 신뢰할 수 있게 되자 자동화는 거의 저절로 따라왔습니다. 엔터프라이즈 컨텍스트 플랫폼은 같은 내기를 훨씬 큰 범위와 훨씬 높은 야심으로 거는 것입니다. 한 스쿼드의 권한 범위가 아니라 그룹 전체의 IT 지형이 대상입니다.

## 비즈니스 인텔리전스에는 아무도 만들지 않은 쌍둥이가 있습니다 {#business-intelligence-has-a-twin-nobody-built}

비즈니스 인텔리전스가 작동하는 이유는 지루하고 잘 알려진 아키텍처 덕분입니다. 운영 시스템이 데이터를 만들고, 파이프라인이 그것을 추출하고, 웨어하우스가 그것을 팩트(fact)와 디멘션(dimension)으로 모델링하며, 분석가와 대시보드가 그 모델을 조회합니다. 판매 보고서를 열두 개 지역의 재무 담당자(controller)에게 이메일을 보내 취합해야 한다고 주장하는 사람은 없습니다.

IT에는 운영 시스템은 모두 있지만 나머지는 하나도 없습니다. 데이터는 있습니다. 각자 한 조각씩만 아는 기록 시스템들에 흩어져 있을 뿐입니다.

| 시스템 | 대표적인 예 | 아는 것 | 모르는 것 |
|---|---|---|---|
| EA 리포지토리(애플리케이션 포트폴리오) | Ardoq, LeanIX | 애플리케이션, 역량, 비즈니스 소유권, 수명 주기 | 그 애플리케이션이 아직 그 모양으로 존재하는지 |
| 데이터 거버넌스 카탈로그 | Alation, Collibra, Microsoft Purview | 데이터 도메인, 데이터 소유자, 분류, 리니지(lineage) | 어떤 런타임이 실제로 그 데이터를 다루는지 |
| IT 서비스 관리와 CMDB | Jira Service Management, ServiceNow | 서비스, 구성 항목, 인시던트, 변경 | 그 뒤에 있는 아키텍처상의 의도 |
| 소스 코드 플랫폼(git 호스팅) | Bitbucket, GitHub, GitLab | 리포지토리, 팀, 코드, 의존성, 활동 | 어떤 리포지토리가 어느 애플리케이션에 속하는지 |
| 컨테이너 플랫폼 | AKS, EKS, OpenShift | 클러스터, 네임스페이스, 워크로드, 이미지 | 네임스페이스에 대해 누가 책임지는지 |
| 옵저버빌리티 플랫폼 | Datadog, Dynatrace, Grafana | 대시보드, 알림, 사람들이 실제로 지켜보는 것 | 지표가 비즈니스에 무엇을 의미하는지 |
| 내부 플랫폼 서비스 | 통합 플랫폼이나 메시지 브로커, WAF, API 게이트웨이, CDN | 통합 흐름, WAF 규칙, API 노출, CDN 구성 | 요청이 거치는 처음부터 끝까지의 경로 |

예시는 각 범주에서 흔히 보이는 제품들을 알파벳순으로 나열한 것입니다. 대부분의 대기업은 각 행에서 한두 개씩 쓰고 있으며, 그것이 어느 제품인지는 논지를 바꾸지 않습니다.

모든 행은 누군가에게 무언가에 대한 진실의 원천(source of truth)입니다. 그러나 어느 행도 혼자서는 아키텍트의 질문에 답하지 못합니다. 아키텍트가 실제로 던지는 질문은 한 번에 서너 개의 행을 가로지릅니다. “마켓 유닛 X에서 고객 대면 애플리케이션 가운데 WAF 정책 없이 게이트웨이를 통해 API를 노출하는 것은 어느 것이고, 누가 그것을 소유하는가?” 같은 질문입니다.

그 질문에는 답이 있습니다. 하지만 답은 행과 행 사이의 조인(join)에 있고, 오늘날 그 조인은 사람들의 머릿속에 있습니다.

## 구전 지식과 지식 사일로 {#tribal-knowledge-and-knowledge-silos}

열 개가 넘는 마켓 유닛을 거느리고, 각 유닛이 저마다의 플랫폼과 스쿼드, 때로는 서로 경쟁하는 서비스를 가진 그룹은 두 가지 서로 다른 방식으로 지식을 잃습니다. 둘은 서로 다른 처방을 필요로 하므로 구분해 두는 것이 좋습니다. 둘 다 수십 년의 연구가 뒷받침하고 있고, 그 연구는 흔한 경영 구호보다 훨씬 쓸모가 있습니다.

### 구전 지식: 한 번도 적힌 적 없는 것 {#tribal-knowledge-what-was-never-written-down}

**구전 지식**(tribal knowledge)은 한 번도 글로 적힌 적이 없는 지식입니다. 어느 팀이 오래된 통합 허브를 실제로 운영하는지. 왜 두 애플리케이션이 데이터베이스 하나를 공유하는지. 한 마켓 유닛의 게이트웨이가 조용히 다른 유닛을 거쳐 라우팅된다는 사실. 일부러 숨긴 것이 아닙니다. 아무도 그것을 말로 옮긴 적이 없고, 구조화된 데이터로 옮긴 적은 더더욱 없을 뿐입니다. 그것은 몇 사람 안에 살고 있고, 그 사람들이 떠나면 함께 떠납니다.

철학자 Michael Polanyi(마이클 폴라니)는 *The Tacit Dimension*에서 그 바탕에 있는 현상을 고전적으로 정식화했습니다. “우리는 말할 수 있는 것보다 더 많이 알 수 있다.” 경험 많은 엔지니어가 어떤 지형에 대해 아는 것 가운데 일부는 이 엄밀한 의미에서 암묵적입니다. 그들은 어떤 설계가 통하지 않으리라는 것을, 그 이유를 말할 수 있게 되기 훨씬 전에 알아봅니다. Ikujiro Nonaka(노나카 이쿠지로)와 Hirotaka Takeuchi(다케우치 히로타카)는 그런 지식을 전환하는 과정을 중심으로 조직 학습의 모델인 SECI 모델을 세웠고, 암묵지에서 형식지로 넘어가는 단계를 *표출화*(externalisation)라고 불렀습니다. 비판자들은 암묵적 지식의 상당 부분이 끝내 명문화되지 않는다고 지적하는데, 저는 양쪽 모두 옳다고 생각합니다. IT에서 구전 지식으로 통하는 것의 상당수는 전혀 깊이 암묵적이지 않습니다. 그것은 아무도 적어 달라는 요청을 받은 적이 없는 형식지입니다. 적어 둘 곳이 없었기 때문입니다. 네임스페이스를 누가 소유하는지는 얼마든지 말로 할 수 있습니다. 단지 어디에도 기록되어 있지 않을 뿐입니다.

James C. Scott(제임스 C. 스콧)은 여기에 경고를 더합니다. 그는 『국가처럼 보기』(*Seeing Like a State*)에서 오랜 경험으로 얻는 실천적 지식인 *메티스*(mētis)를 묘사하고, 복잡한 시스템을 위에서 읽을 수 있게(legible) 만들려는 계획이 바로 그 지식을 파괴하는 경향이 있다는 것을 보여 줍니다. 단순화된 지도가 영토 자체로 취급되기 때문입니다. 회사가 스스로를 읽을 수 있게 만들어 주겠다고 약속하는 플랫폼이라면 이 경고를 진지하게 받아들여야 합니다. 컨텍스트 모델(Context Model)은 시스템을 운영하는 사람들이 아는 모든 것을 결코 담지 못할 것이고, 담고 있는 척해서도 안 됩니다. 컨텍스트 모델이 할 수 있는 일은 형식화할 수 있는 부분을 값싸게 만들고, 나머지를 지닌 사람들을 가리키는 것입니다.

그 두 번째 일에도 이름이 있습니다. Daniel Wegner(대니얼 웨그너)의 *교류 기억*(transactive memory) 이론은 집단이 어떻게 기억하는지를 설명합니다. 모두가 *누가 무엇을 아는지*만 알고 있다면, 모두가 모든 것을 알 필요는 없습니다. 작은 팀은 그런 안내 목록을 자연스럽게 만들어 냅니다. 열 개의 마켓 유닛에 걸친 수천 명의 그룹은 그럴 수 없고, 바로 그 지점에서 구전 지식은 하나의 특이한 버릇에서 위험으로 바뀝니다. 소프트웨어 공학은 이 위험의 한 형태를 *트럭 팩터*(truck factor)로 직접 측정합니다. 프로젝트가 멈추기 전에 몇 명이 떠나야 하는지를 나타내는 수입니다. Avelino(아벨리누)와 동료들은 GitHub의 인기 오픈 소스 프로젝트 133개의 트럭 팩터를 추정했고, 65퍼센트가 2 이하라는 것을 발견했습니다. 기업 내부 코드가 더 나으리라고 믿을 근거는 없습니다. 그리고 컨텍스트 모델은 이미 커밋 이력을 읽고 있으므로, 그룹의 모든 애플리케이션에 대해 트럭 팩터를 계산할 수 있습니다.

### 지식 사일로: 적혀 있지만 손이 닿지 않는 것 {#knowledge-silos-written-down-but-out-of-reach}

**지식 사일로**(knowledge silos)는 정반대의 문제입니다. 지식은 도구나 스프레드시트나 위키 공간 어딘가에 형식화되어 저장되어 있지만, 그것을 필요로 하는 사람들이 쉽게 접근할 수 없습니다. 이 불만에는 유명한 문장이 따로 있습니다. “HP가 HP가 아는 것을 알기만 한다면.” 흔히 Hewlett-Packard의 전 CEO Lew Platt(루 플랫)의 말로 알려져 있지만, Carl Sieloff(칼 실로프)는 이 표현의 뿌리를 1980년대 회사 안에서 늘 나오던 불만에서 찾습니다.

사일로는 우연일 때도 있고 의도적일 때도 있습니다. 제가 보아 온 것에 비추어 그 이유를 짐작해 보면, 다음 몇 가지가 섞여 있습니다.

- **반사적인 접근 통제.** 규제받는 회사에서 “이것을 누가 읽을 수 있는가?”에 대한 기본 답은 “가능한 한 적은 사람”이고, 이 원칙은 시스템에 관한 메타데이터에도 마치 고객 데이터인 것처럼 적용됩니다.
- **사용자 수 단위로 매겨지는 라이선스.** EA 리포지토리나 데이터 카탈로그의 독자 한 명 한 명이 라이선스 비용이라면, 읽는 일은 예산 결정이 됩니다.
- **협상 카드로서의 지식.** 어떤 질문에 답할 수 있는 유일한 팀은 회의에 초대받고, 인원을 지키고, 예산을 정당화하는 팀입니다.
- **드러나는 것에 대한 두려움.** 열린 인벤토리는 기술 부채, 중복된 플랫폼, 섀도 IT를 보여 줍니다. 모두가 그것이 보이기를 반기지는 않습니다.
- **인터페이스의 부재.** 데이터가 API 없는 레거시 도구에 들어 있고, 내보내기라고는 누군가 분기마다 손으로 만드는 스프레드시트뿐입니다.
- **유닛 사이의 경쟁.** 두 스쿼드가 겹치는 플랫폼을 제공할 때, 자기 지형을 투명하게 만드는 것은 상대에게 논거를 건네주는 일처럼 느껴질 수 있습니다.

문헌은 이 짐작 가운데 일부를 뒷받침하고 일부를 복잡하게 만듭니다. Thomas Davenport(토머스 대븐포트), Robert Eccles(로버트 에클스), Laurence Prusak(로런스 프루삭)은 스물다섯 곳이 넘는 기업의 정보 관리를 연구해 1992년에 “Information Politics”(정보 정치)로 발표했습니다. 그들의 관찰은, 정보 기술이 위계를 평평하게 하고 정보를 자유롭게 하리라 기대되었지만 종종 정반대의 일을 했다는 것이었습니다. 정보가 조직의 화폐가 되자 관리자들은 그것을 내주기에는 너무 값지다고 여겼습니다. 그들이 발견한 가장 흔한 형태를 그들은 *정보 봉건제*(information feudalism)라고 불렀습니다. 각 부서가 자기 정보를 어떻게 모으고, 저장하고, 공유할지를 스스로 통제하는 형태입니다. 30년이 지나 모든 부서가 자기 SaaS 도구를 돌리는 지금, 그 묘사는 지금도 잘 들어맞습니다.

Catherine Connelly(캐서린 코넬리)와 동료들은 한 걸음 더 나아가 *지식 은폐*(knowledge hiding), 곧 누군가 요청한 지식을 일부러 내주지 않는 행동을 연구했습니다. 그들은 세 가지 형태를 찾아냈습니다. 회피적 은폐(결코 오지 않는 답을 약속하거나 일부만 주는 것), 모르는 척하기, 그리고 합리화된 은폐(그 정보를 왜 공유할 수 없는지 설명하는 것)입니다. 세 가지 모두 불신이 예측 변인이었고, 공유를 장려하는 분위기에서는 회피적 은폐가 덜 흔했습니다. 연구가 나왔을 때 저자 가운데 한 명은 실천적 결론을 직설적으로 말했습니다. 신뢰의 분위기가 없다면 소프트웨어가 아무리 좋아도 상관없고, 사람들은 그것을 쓰지 않을 것이라고 말입니다.

Gabriel Szulanski(가브리엘 슐란스키)의 기업 내부 모범 사례 이전 연구는 제 냉소적인 목록에 대한 유용한 균형추입니다. 여덟 개 기업에서 122건의 이전을 살펴본 그는, 지식을 “끈적하게”(sticky) 만드는 것이 대개 동기가 아니라는 것을 발견했습니다. 주된 장벽은 지식 자체와 관련된 것이었습니다. 받는 쪽 유닛에 그것을 흡수할 역량이 없었고, 그 관행이 왜 효과가 있는지 완전히 이해하는 사람이 없었으며, 원천과 수신자 사이의 관계가 힘겨웠습니다. 많은 사일로는 그저 쓰기 어려울 뿐이고, 그래서 사일로는 정치적 문제인 만큼 설계의 문제이기도 합니다.

Morten Hansen(모르텐 한센)은 제가 이 플랫폼에 필수적이라고 보는 구분을 더합니다. 120개의 제품 개발 프로젝트를 연구한 그는, 유닛 사이의 약한 연결이 팀이 다른 곳의 유용한 지식을 *찾는* 데는 도움이 되지만, 복잡한 지식을 이전하려면 관련된 사람들 사이에 강한 연결이 필요하다는 것을 보여 주었습니다. 그는 이것을 탐색과 이전의 문제(search-transfer problem)라고 불렀습니다. 컨텍스트 모델은 탐색을 위한 기계입니다. 한 마켓 유닛의 엔지니어에게 그가 필요로 하는 플랫폼이 다른 유닛에 이미 있고 누가 그것을 운영하는지 알려 줄 수 있습니다. 그것을 운영해 본 경험을 이전해 줄 수는 없습니다. 그것은 여전히 대화를 필요로 합니다.

마지막으로, 조직 안의 사일로는 지형 안의 사일로가 됩니다. Melvin Conway(멜빈 콘웨이)는 1968년에, 시스템을 설계하는 조직은 자기 커뮤니케이션 구조를 복제한 설계를 만들어 내도록 제약받는다고 관찰했습니다. 서로 대화하지 않는 열 개의 마켓 유닛은 서로 대화하지 않는 열 개의 통합 플랫폼을 만듭니다. Matthew Skelton(매슈 스켈턴)과 Manuel Pais(마누엘 파이스)는 『팀 토폴로지』(*Team Topologies*)에서 이것을 뒤집어 “역콘웨이 전략”(inverse Conway manoeuvre)을 내놓습니다. 원하는 아키텍처에 맞춰 팀 구조를 설계하라는 것입니다. 그러나 지금 가진 아키텍처를 먼저 보지 않고는 그것을 잘 해낼 수 없습니다. 인류학자에서 금융 저널리스트가 된 Gillian Tett(질리언 테트)는 『사일로 이펙트』(*The Silo Effect*)에서 더 넓은 논지를 폅니다. 사일로는 나쁜 의도만이 아니라 전문성과 전문화의 부산물이며, 사일로를 가장 잘 다루는 조직은 그것을 가로질러 볼 방법을 의도적으로 만드는 조직이라는 것입니다.

### 플랫폼이 할 수 있는 것과 할 수 없는 것 {#what-the-platform-can-and-cannot-do-about-it}

| 현상 | 연구가 말하는 것 | 컨텍스트 모델이 하는 일 | 할 수 없는 일 |
|---|---|---|---|
| 암묵적 지식 | 어떤 지식은 말로 할 수 없고(Polanyi), 가독성을 위한 계획은 실천적 지식을 파괴할 수 있다(Scott) | 형식화할 수 있는 것을 기록하고, 나머지를 아는 사람들과 연결한다 | 판단과 경험을 담아내는 것 |
| 기록되지 않은 형식지 | 표출화에는 놓일 자리와 형식이 필요하다(Nonaka와 Takeuchi) | 모든 사실에 자리와 소유자와 출처를 준다 | 사람들이 그것을 적게 만드는 것 |
| 집중된 지식 | 집단은 누가 무엇을 아는지 아는 데 의존하고(Wegner), 트럭 팩터는 낮다(Avelino 외) | “누가 무엇을 아는지” 목록을 명시적으로 만들고, 애플리케이션마다 트럭 팩터를 계산한다 | 지식 자체를 퍼뜨리는 것 |
| 정보 봉건제와 지식 은폐 | 정보는 화폐이고, 은폐는 불신과 함께 커진다(Davenport 외, Connelly 외) | 읽기를 기본으로 만들고, 숨기기를 눈에 보이는 예외로 만든다 | 스스로 신뢰를 만드는 것 |
| 끈적한 지식 | 장벽은 대개 흡수 역량과 인과적 모호성이다(Szulanski) | 컨텍스트를 찾고 이해하는 비용을 낮춘다 | 학습을 대신하는 것 |
| 탐색과 이전 | 약한 연결은 찾고, 강한 연결은 이전한다(Hansen) | 모든 마켓 유닛에 걸쳐 탐색을 해결한다 | 복잡한 지식을 이전하는 대화를 대신하는 것 |
| 시스템을 빚는 조직의 사일로 | 시스템은 커뮤니케이션 구조를 닮는다(Conway) | 지형을 있는 그대로 보여 주어 팀 설계를 의도적으로 할 수 있게 한다 | 누군가를 재조직하는 것 |

마지막 열은 세 번째 열만큼 중요합니다. Jeffrey Pfeffer(제프리 페퍼)와 Robert Sutton(로버트 서튼)은 이 일반적인 실패를 *지행 격차*(knowing-doing gap)라고 불렀습니다. 조직은 무엇을 해야 하는지 알면서도 그것을 하지 않는 경우가 많습니다. 지형을 담은 열린 지도는 아는 쪽을 메워 줍니다. 하는 쪽은 여전히 인센티브, 소유권, 리더십의 문제로 남고, 그래서 이 플랫폼은 데이터만큼이나 기여와 권한을 중심으로 설계되어 있습니다.

두 문제는 아키텍트에게 같은 증상을 낳습니다. 무엇이 있는지 아는 비용이 추측하는 비용보다 높으니 사람들은 추측합니다. 결정은 부분적인 그림 위에서 내려지고, 플랫폼은 중복되며, 조화는 일련의 조회가 아니라 일련의 협상이 됩니다.

## 문제를 있는 그대로 말하면 {#the-problem-stated-plainly}

**대기업은 자기 IT에 관한 질문에 값싸고 믿을 만하게 답하지 못합니다.** 미래에 관한 어려운 질문이 아니라 현재에 관한 평범한 질문을 말하는 것입니다. 무엇이 존재하는지, 누가 그것을 소유하는지, 그것이 어떻게 연결되는지, 무엇을 위한 것인지, 그리고 그것이 전략이 말한 모습과 일치하는지입니다.

다른 모든 것은 이 하나의 공백에서 나옵니다. 전략은 늦게, 그리고 왜곡된 채로 시스템에 닿습니다. 프로젝트 없이는 누구도 시스템을 전략에 비추어 확인할 수 없기 때문입니다. 플랫폼은 두 번 만들어집니다. 두 번째 것을 만드는 팀이 첫 번째 것을 찾지 못했기 때문입니다. 아키텍처 검토는 제안을 판단하는 대신 현재 상태를 재구성하는 데 시간을 씁니다. 운영 팀은 매주 같은 질문에 답합니다. 사람이 찾아볼 수 있는 어디에도 답이 없기 때문입니다. 그리고 사람 안에, 혹은 누군가의 접근 정책 뒤에 있는 지식이, 어떤 결정이 고려하는 선택지를 조용히 정해 버립니다.

에이전트는 이것을 시급한 문제로 만듭니다. 모든 엔지니어에게 코딩 에이전트를 배포하고 딜리버리 파이프라인에서 에이전트 팩토리를 돌리는 회사는, IT에 관한 결정을 내리는 행위자의 수를 크게 늘리려 하고 있으며, 그 모두가 컨텍스트 없이 출발합니다. 엔터프라이즈 컨텍스트가 없는 에이전트는 컨텍스트가 없는 사람이 하는 일을 더 빨리 할 뿐입니다. 추측하고, 중복하고, 이미 있는 것을 만듭니다. 대안은 그들에게, 그리고 그들 주변의 사람들에게, 회사 IT의 현재 상태가 알려져 있고 신뢰할 수 있으며 누구나 읽을 수 있는 한 곳을 주는 것입니다.

그렇다면 목표는 엔터프라이즈 IT의 현재 상태를 값싸게 알 수 있고, 그것에 근거해 행동할 수 있을 만큼 신뢰할 수 있으며, 그 위에서 무언가를 만드는 모든 사람과 모든 에이전트에게 열려 있게 만드는 것입니다.

## 하나의 문제, 세 개의 규모 {#one-problem-three-scales}

돌아보면 저는 몇 년 동안 같은 문제를 점점 커지는 규모에서 다뤄 왔고, 최근에야 그것에 이름을 붙였습니다.

| 역할 | 범위 | 아무도 값싸게 답하지 못한 질문 | 제가 만들거나 한 것 |
|---|---|---|---|
| 웹 서비스 딜리버리의 플랫폼 엔지니어이자 솔루션 아키텍트 | 한 스쿼드의 권한 범위: WAF, CDN, 인그레스 프록시, DNS | 내 웹 서비스는 어떻게 노출되고 보호되는가? | Git의 매니페스트, 셀프서비스 포털, 운영자의 일을 하는 지속형 워크플로 |
| 에이전틱 AI와 AI 플랫폼의 엔터프라이즈 솔루션 아키텍트 | 10개가 넘는 마켓 유닛에 걸친 솔루션 아키텍처 | 우리가 만드는 것이 엔터프라이즈 아키텍처와 전략의 의도에 맞는가? | 검토, 지침, 참조 설계. 매번 고고학에서 시작 |
| AI 및 데이터 부문의 그룹 AI 아키텍트 | 그룹 전체의 IT 지형 | 무엇이 있고, 어떻게 맞물려 있으며, 무엇을 바꿔야 하는가? | 엔터프라이즈 컨텍스트 플랫폼 |

각 단계에서 같은 패턴이 되풀이됩니다. 먼저 데이터를 형식화해야 하고, 그다음 모두가 그것을 읽을 수 있어야 하며, 그래야 비로소 그 위에서 워크플로든 에이전트든 일을 자동화할 수 있습니다. 웹 딜리버리 스쿼드에서는 그 패턴이 통했습니다. 엔터프라이즈 솔루션 아키텍트 역할에서는 그 패턴의 부재가 그 일의 가장 큰 비용이었습니다. 엔터프라이즈 컨텍스트 플랫폼은 그 패턴을 회사 전체에 적용하려는 시도입니다.

이것은 제가 여기에 써 온 글들과도 이어집니다. [컨텍스트가 곧 제품입니다](https://raskell.io/articles/context-is-the-product/)와 [에이전트 플랫폼 핸드북](https://raskell.io/articles/what-an-agent-actually-is/)의 나머지 글들은, 리포지토리 하나의 규모에서, 에이전트가 읽는 컨텍스트가 그것이 돌아가는 모델보다 더 중요하다고 주장합니다. [메모리는 쓰기 경로입니다](https://raskell.io/articles/memory-is-a-write-path/)는 컨텍스트가 어떻게 안전하게 다시 쓰이는지에 관한 글인데, 이는 데이터 세트가 어떻게 1차 소스가 되는가라는 질문과 같습니다. 엔터프라이즈 컨텍스트 웨어하우스에 관한 노트는 제가 무엇 하나 만들기 전에 이 아이디어를 회사 규모로 스케치한 것이었습니다. 그리고 이 사이트도 같은 것의 장난감 판본입니다. [이 사이트는 지도가 되어 가고 있습니다](https://raskell.io/articles/this-site-is-becoming-a-map/)에서 설명한 것처럼, 모든 페이지가 기계를 위해 한 번 더 발행됩니다. 엔터프라이즈 컨텍스트 플랫폼은 그 실들이 프로덕션에서 만나는 곳입니다.

## 제가 말하는 엔터프라이즈 컨텍스트 플랫폼 {#what-i-mean-by-an-enterprise-context-platform}

EA 리포지토리는 아키텍트가 아키텍트를 위해 관리하는, 큐레이션된 지형 기술서입니다. 엔터프라이즈 컨텍스트 플랫폼은 IT 부서 안에서 일어나는 모든 것을 위한 데이터 계층입니다. 무엇이 만들어지고, 배포되고, 노출되고, 변경되고, 고장 나고, 관찰되고, 소유되고, 결정되는지를, 그것이 일어나는 대로, 그것이 일어나는 시스템에서 가져옵니다. EA 리포지토리는 그 소스 가운데 하나이고 아키텍트는 그 사용자 가운데 하나입니다. 주된 소비자는 점점 에이전트가 되어 가고 있습니다.

제가 만들기 시작한 플랫폼에는 세 개의 계층이 있고, 핵심은 가운데 계층입니다.

*Enterprise Context Platform*

```text
   SOURCES                 CONTEXT MODEL              SURFACES
   EA repository ─────┐
   data catalogue ────┤    ┌────────────────────┐
   ITSM and CMDB ─────┤    │ entities           │ ──▶ Web UI
   source code ───────┼──▶ │ relationships      │ ──▶ REST API
   container platform─┤    │ provenance         │ ──▶ MCP, for agents
   observability ─────┤    │ confidence         │
   integration ───────┤    └─────────┬──────────┘
   WAF and exposure ──┤              ▼
   CDN ───────────────┘     analytics over the model
            ingest                   ▼
                            artifacts: analyses, business
                            cases, diagrams, ADRs
```

**수집(ingestion).** 각 소스에는 커넥터가 하나씩 붙습니다. 그중 일부는 정적이고 결정론적입니다. 컨테이너 플랫폼의 네임스페이스는 네임스페이스이고, 소스 코드 플랫폼의 팀은 팀이며, EA 리포지토리의 애플리케이션에는 ID가 있습니다. 일부는 도움이 필요합니다. `pol-adm-svc-v2`라는 리포지토리를 EA 리포지토리의 애플리케이션 “Policy Administration”에 연결하는 것은 판단의 문제이고, 수집이 AI의 도움을 받는 곳이 바로 여기입니다. 모델이 이름, README, 소유자, 배포 레이블, 설명을 바탕으로 연결을 제안하고, 얼마나 확신하는지와 그 이유를 기록합니다.

수집 계층은 또한 모든 소스의 모든 데이터 세트에 정확도 점수를 매깁니다. 모든 기록 시스템이 같은 신뢰를 받을 자격이 있는 것은 아닙니다. 컨테이너 플랫폼에서 실시간으로 가져온 인벤토리는 실제 상태(ground truth)에 가깝지만, 1년에 한 번 손으로 관리하는 애플리케이션 목록은 그렇지 않습니다. 점수는 선언되는 것이 아니라 계산됩니다. 신선도, 필수 필드의 완전성, 같은 엔티티에 대해 그 소스가 다른 소스와 얼마나 자주 일치하는지, 그 레코드 가운데 얼마나 많은 것이 아이덴티티 해석(identity resolution)을 통과하는지 같은 신호에서 계산됩니다. 소스 스코어카드가 기록하는 내용을 스케치하면 다음과 같습니다.

```yaml
# ingestion/scorecards/ea-repository.yaml (illustrative)
source: ea_repository
dataset: applications
last_ingested: 2026-10-29T03:00:00Z
scores:
  freshness: 0.62        # share of records touched in the last 180 days
  completeness: 0.81     # mandatory fields present
  agreement: 0.74        # facts confirmed by at least one other source
  resolvability: 0.88    # records matched to a Context Model entity
overall: 0.76
```

점수는 모델 안으로 전달됩니다. 점수가 높은 데이터 세트에서 도출된 관계는 점수가 낮은 데이터 세트에서 도출된 관계보다 높은 신뢰도로 출발하고, 모든 소유자는 자기 소스가 나머지와 비교해 어떤지 볼 수 있습니다.

**컨텍스트 모델(Context Model).** 이것이 온톨로지이자 플랫폼의 심장입니다. 소스에서 온 원시 레코드는 모델이 아닙니다. 모델은 그 레코드들로부터 추론해 낸 추상적인 엔티티들과 그것들 사이의 관계의 집합입니다. 애플리케이션(Application)은 리포지토리(Repository)들로 구현되고, 네임스페이스(Namespace) 안의 워크로드(Workload)로 배포되며, 팀(Team)이 소유하고, 역량(Capability)을 지원하며, 특정 분류의 데이터 객체(Data Object)를 처리하고, 엔드포인트(Endpoint)를 통해 노출되며, WAF 정책 뒤에 있고, 대시보드(Dashboard)가 지켜봅니다. 이런 의미에서 애플리케이션이란, EA 리포지토리의 레코드 하나, 코드 리포지토리 세 개, 네임스페이스 두 개, IT 서비스 관리의 비즈니스 서비스 하나가 알고 보니 같은 것이었을 때 얻게 되는 것입니다.

**표면(surfaces).** 모델은 웹 UI, REST API, MCP의 세 가지 방식으로 노출되고, 각각은 서로 다른 종류의 소비자를 위한 것입니다. 세 가지 모두의 뒤에는 같은 의미를 지닌 같은 엔티티가 있습니다. [컨텍스트가 곧 제품입니다](https://raskell.io/articles/context-is-the-product/)에서 주장했듯이, 이는 달이 갈수록 더 중요해집니다.

| 소비자 | 표면 | 그것으로 하는 일 |
|---|---|---|
| 모든 개발자와 엔지니어의 노트북에 있는 코딩 에이전트(로컬 Claude Code 인스턴스) | MCP | 코드를 한 줄 쓰기 전에 어떤 서비스가 API를 소유하는지, 어느 플랫폼에 배포해야 하는지, 참조 아키텍처가 무엇을 말하는지 묻습니다 |
| SDLC 안의 원격 에이전트 팩토리 | MCP | 같은 질문을, 노트북이 아니라 파이프라인에서 소프트웨어를 만들고 테스트하고 바꾸는 에이전트가 묻습니다 |
| 엔터프라이즈 아키텍트, 솔루션 아키텍트, 엔지니어 | 웹 UI | 무엇이 있는지 찾아보고, 한 도메인이 어떻게 맞물려 있는지 배우고, 설계 검토 전에 의존성을 살펴봅니다 |
| 컨텍스트를 필요로 하는 다른 시스템 | REST API | 싱크 시스템들이 컨텍스트 모델 데이터를 자기 프로세스로 가져갑니다. 포트폴리오 도구, 리스크 및 컴플라이언스 보고, 온보딩, 비용 배분 등입니다 |

첫 두 행이 이 플랫폼이 5년 뒤가 아니라 지금 존재해야 하는 이유입니다. 노트북 위의 코딩 에이전트는 모든 세션을 자기가 일하는 회사에 대해 아무것도 모르는 상태로 시작합니다. 컨텍스트 모델로 들어가는 MCP 엔드포인트를 주면, 에이전트는 어느 팀에 물어야 하는지, 다시 만드는 대신 어떤 플랫폼 서비스를 재사용해야 하는지, 자기가 막 택하려던 접근을 어떤 아키텍처 결정이 이미 배제했는지 알게 됩니다. 이것을 그룹의 모든 엔지니어와 모든 에이전트 팩토리로 곱하면, 컨텍스트 모델은 회사가 소프트웨어를 어떻게 만드는지에 관한 공유된 기억이 됩니다.

모델 위에는 분석이 놓이고, 바로 그곳에서 모델은 카탈로그이기를 멈추고 인텔리전스가 되기 시작합니다. 모델이 연결되어 있기 때문에 산출물을 만들어 낼 수 있습니다. 한 마켓 유닛의 아키텍처 분석, 겹치는 세 플랫폼을 통합하기 위한 비즈니스 케이스의 초안, 실제로 돌아가는 것에서 생성한 솔루션 아키텍처 다이어그램, 역량 커버리지에 관한 EA 뷰, 현재 상태와 선택지가 미리 채워진 아키텍처 결정 기록(ADR) 같은 것입니다. 같은 분석은 비즈니스 유스케이스도 스스로 찾아냅니다. 두 시스템이면 될 일을 다섯 시스템에 걸쳐 하는 프로세스, 네 개의 마켓 유닛에 중복된 구성 요소, 더 효율적으로(같은 결과, 더 적은 비용) 또는 더 효과적으로(더 나은 결과, 같은 비용) 만들 수 있는 솔루션 같은 것입니다. 예전에는 이런 발견을 하려면 마침 양쪽을 다 아는 누군가가 필요했습니다. 이제는 조회 하나와, 그것에 따라 행동할 의지가 있는 누군가가 필요할 뿐입니다.

## 왜 온톨로지가 어려운 부분인가 {#why-the-ontology-is-the-hard-part}

수집은 배관 공사입니다. 표면은 UI 하나와 API 두 개입니다. 진짜 결정은 컨텍스트 모델에 있고, 제가 가장 많이 생각을 바꾼 곳도 거기입니다.

엔티티 모델의 최소한의 단면은 대략 다음과 같습니다. 실제 스키마가 아니라 예시입니다.

```yaml
# context-model/entities.yaml (illustrative)
Application:
  identity: [ea_repository.application_id]
  derived_from: [ea_repository.application, itsm.business_service]
  relations:
    realised_by:   Repository      # many
    deployed_as:   Workload        # many
    owned_by:      Team            # one, accountable
    supports:      Capability      # many
    processes:     DataObject      # many, with classification
    exposed_via:   Endpoint        # many

Repository:
  identity: [source_code.repository_path]
  relations:
    belongs_to:    Application     # inferred, carries confidence
```

예상보다 중요한 것으로 드러난 세 가지가 있습니다.

**아이덴티티 해석이 일의 대부분입니다.** 같은 애플리케이션이 시스템마다 다른 이름을 가지고 있고, 때로는 이름이 아예 없습니다. 두 레코드가 언제 같은 엔티티인지 판단하는 것이 핵심 문제입니다. 결정론적 키가 그 일부를 해결합니다(EA 리포지토리의 애플리케이션 ID를 담고 있는 배포 레이블은 선물과 같습니다). 나머지는 추론이고, 추론은 눈에 보여야 합니다.

**모든 엣지는 출처와 신뢰도를 지닙니다.** API의 외래 키에서 나온 엣지는 모델이 README를 보고 제안한 엣지와 다른 종류의 사실입니다. 둘 다 쓸모가 있습니다. 둘을 똑같이 취급하는 것이야말로 아무도 믿지 않는 아름다운 그래프를 만드는 방법입니다. 각 관계는 그것이 어디서 왔는지, 마지막으로 언제 관찰되었는지, 그리고 그것이 단언된(asserted) 것인지, 도출된(derived) 것인지, 추론된(inferred) 것인지를 기록합니다. 저는 컨텍스트 웨어하우스에 대해서도 같은 주장을 했고, 그래프가 사람들이 그에 따라 행동하는 산출물을 만들어 내기 시작하면 이 주장은 더욱 강하게 성립합니다.

**모델은 의견을 가져야 하고, 그 의견은 엔터프라이즈 아키텍처의 것이어야 합니다.** 엔티티 유형, 관계 유형, 역량 맵는 중립적이지 않습니다. 기업 전략과 EA의 역량이 플랫폼에 들어오는 곳이 바로 거기입니다. 컨텍스트 모델이 EA가 쓰는 것과 같은 역량 분류 체계를 쓴다면, “모든 마켓 유닛에서 역량 X를 지원하는 시스템은 무엇인가”는 프로젝트가 아니라 조회가 됩니다. 그것이 제 이전 역할에서의 조화 문제가 데이터 문제로 바뀐 모습입니다. 이에 대해서는 에이전트가 읽을 수 있는 분류 체계에 더 적었습니다.

## 1차 소스와 2차 소스 {#primary-and-secondary-sources}

컨텍스트 모델 안의 모든 데이터가 같은 지위를 가지는 것은 아니며, 모델은 그것을 명시적으로 밝힙니다.

대부분은 **2차 소스**로 시작합니다. 그 데이터에 대해 권위를 가진 시스템에서 수집한 사본입니다. 네임스페이스 안에서 무엇이 돌아가는지에 대해서는 컨테이너 플랫폼이 권위를 가집니다. 리포지토리에 누가 접근할 수 있는지에 대해서는 소스 코드 플랫폼이 권위를 가집니다. 컨텍스트 모델은 그 사실들을 비추고, 점수를 매기고, 연결하지만, 소스와 의견이 다르면 소스가 이기고 수정은 소스로 갑니다.

일부는 **1차 소스**입니다. 컨텍스트 모델이 그 데이터에 대해 권위를 가진 곳입니다. 처음에 이것은 대부분 다른 어떤 시스템도 지니지 않은 것, 곧 엔티티 사이의 확인된 연결입니다. 이 세 리포지토리, 이 두 네임스페이스, 그리고 저 비즈니스 서비스가 하나의 애플리케이션이라는 것을 기록하는 곳은 그 밖에 없습니다. 팀이 그것을 확인하고 나면 그 사실은 컨텍스트 모델에만 있고 다른 어디에도 없습니다.

시간이 지나면서 더 많은 데이터가 2차에서 1차로 옮겨 갑니다. 어떤 데이터 세트가 큐레이션되고, 높은 점수를 받고, 모델을 통해 어디서나 쓰이는데, 원래 도구는 그것을 관리할 두 번째 장소라는 것 말고는 아무것도 더하지 않는다면, 합리적인 일은 컨텍스트 모델을 그 데이터의 권위 있는 원천으로 선언하고 사본을 은퇴시키는 것입니다.

*How a data set changes standing*

```text
   ┌──────────────────────────┐
   │ ingested from a source   │  secondary: the source wins
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ scored and connected     │
   │ in the model             │
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ curated by its owner,    │
   │ used through the model   │
   └─────────────┬────────────┘
                 ▼
   ┌──────────────────────────┐
   │ declared primary in      │  an explicit decision, with
   │ the Context Model        │  an owner and a date
   └──────────────────────────┘
```

이 이동은 언제나 데이터 세트마다 소유자와 날짜를 붙여 내리는 명시적인 결정이며, 그래서 모두가 사실을 어디서 고쳐야 하는지 압니다.

## 기본은 개방 {#open-by-default}

제가 가장 굳게 지키는 전제는 **엔터프라이즈 IT 컨텍스트는 민감하지 않다**는 것입니다. 어떤 애플리케이션이 존재하는지, 누가 소유하는지, 어떤 역량을 지원하는지, 어떤 플랫폼에서 돌아가는지, 어떻게 연결되는지. 이 모든 것은 회사의 누구에게나, 그리고 그들을 대신해 일하는 어떤 에이전트에게나 접근 가능해야 합니다.

여기서 IT 컨텍스트란 시스템 안의 데이터가 아니라 시스템에 관한 메타데이터를 뜻합니다. 고객 기록, 자격 증명, 시크릿은 IT 컨텍스트가 아니며 모델에 결코 들어가지 않습니다. 지형을 기술하는 모든 것은 들어갑니다.

이 논지는 누가 전체를 생각할 수 있느냐에 관한 것입니다. 컨텍스트가 제한되어 있으면 모든 사일로에 접근할 수 있는 소수만 전체를 볼 수 있고, 그들은 경계를 넘는 모든 결정의 병목이 됩니다. 컨텍스트가 열려 있으면, 한 마켓 유닛의 엔지니어가 자기가 막 만들려던 플랫폼 서비스가 다른 유닛에 이미 있다는 것을 알아챌 수 있습니다. 솔루션 아키텍트는 검토 전에 설계의 2차 효과를 볼 수 있습니다. 코딩 에이전트는 중복하는 대신 재사용할 수 있습니다. IT 컨텍스트를 민주화하는 것은, 모든 것을 볼 수 있는 소수를 기다리는 대신, 더 많은 사람과 더 많은 에이전트가 가장 큰 가치를 만드는 결정에 기여하게 하는 방법입니다.

## 열린 곳에서 만들고, 기여로 개선합니다 {#built-in-the-open-improved-by-contribution}

이 플랫폼은 전적으로 오픈 소스 기술 위에 지어집니다. 그 중심에는 어떤 벤더 제품도 없습니다. 이것은 의도적인 선택이었고, 비용 때문만은 아니었습니다.

회사 전체에 자기가 그린 지형의 그림을 믿어 달라고 요청하는 플랫폼은 그 그림이 어떻게 만들어지는지에 대해 투명해야 합니다. 모든 커넥터, 모든 점수 규칙, 모든 엔티티 유형, 모든 추론 프롬프트는 들여다보려는 누구든 읽고 이해할 수 있습니다. 누군가 왜 모델이 어떤 애플리케이션을 자기 팀의 것이라고 말하는지 물으면, 답은 블랙박스가 아니라 그가 따라갈 수 있는 소스와 규칙의 사슬입니다.

같은 개방성이 기여를 가능하게 합니다. 팀들은 자기 시스템을 위한 커넥터를 추가하고, 엔티티 유형을 제안하고, 매핑을 고치고, 자기 데이터 세트를 큐레이션할 수 있습니다. 그리고 그렇게 할 이유도 있습니다. 정확하고, 큐레이션되어 있고, 컨텍스트 모델 안에서 의미 있게 연결된 데이터 세트는 그룹의 모든 아키텍트, 모든 엔지니어, 모든 에이전트가 씁니다. 점수가 높고, 읽히며, 결국 권위 있는 원천으로 선언될 수도 있습니다. 낡은 데이터 세트는 점수가 낮고, 모두가 그것도 볼 수 있습니다. 인센티브는 모델 안에 들어 있습니다. 팀이 자기 데이터에 더 많은 정성을 들일수록 그 데이터는 그들 자신에게도, 다른 모두에게도 더 가치 있어집니다. 이 아이디어는 Zhamak Dehghani(자막 데가니)가 데이터 메시에서 *제품으로서의 데이터*(data as a product)라고 묘사한 것에 가깝습니다. 데이터를 아는 도메인이 그것을 소유하고, 큐레이션하고, 명시적인 품질 보증과 함께 다른 이들에게 제공한다는 것입니다. 컨텍스트 모델은 같은 원칙을 IT에 관한 메타데이터에 적용하며, 스코어카드가 그 품질 보증 역할을 합니다.

## 아키텍트에게 달라지는 것 {#what-it-changes-for-an-architect}

차이는 값싸지는 질문들에서 드러납니다.

| 질문 | 이전 | 컨텍스트 모델과 함께 |
|---|---|---|
| 마켓 유닛 X의 어떤 애플리케이션이 언어 모델을 쓰는가? | 설문, 2주 | 조회 하나, 그리고 확인이 필요한 낮은 신뢰도의 매칭 목록 |
| 네임스페이스 `claims-prod-07`은 누가 소유하는가? | 여기저기 물어본다 | 워크로드, 리포지토리, 애플리케이션을 거쳐 찾은 소유 팀 |
| 우리 AI 솔루션은 그룹 참조 아키텍처를 따르는가? | 설계를 하나하나 검토한다 | 실제 토폴로지를 마켓 유닛별로 참조 아키텍처와 비교한다 |
| 이 세 통합 플랫폼을 하나로 합치면 무엇이 영향을 받는가? | 워크숍 | 의존성 하위 그래프. 다이어그램과 비즈니스 케이스 초안으로 |
| 이 ADR은 아직 유효한가? | 아무도 모른다 | ADR의 가정을 현재 모델에 비추어 확인한다 |

이 답 가운데 완벽한 것은 없습니다. 하지만 모두 빈 페이지와 회의 초대보다는 나은 출발점입니다. 아키텍트의 일은 현재 상태를 모으는 것에서 그것을 판단하는 것으로 옮겨 가며, 이는 제가 아키텍트가 지금 하는 일에서 설명한 변화입니다.

## 컨텍스트에서 일로 {#from-context-to-work}

위의 표는 아키텍트의 관점이고, 이 플랫폼을 과소평가합니다. 아키텍트는 공백을 가장 먼저 알아채는 사용자일 뿐, 가장 큰 혜택을 받는 사용자는 아닙니다.

IT 부서의 일 대부분은 일상적인 일입니다. 무언가를 찾아보고, 시스템 사이를 번역하고, 팀 사이를 조율하고, 알려진 패턴을 따르는 변경을 수행하는 일입니다. 이것은 누가 소유하는지, 어디서 돌아가는지, 무엇이 여기에 의존하는지, 어떤 규칙이 적용되는지, 어떤 양식을 채워야 하는지, 누가 승인해야 하는지, 지난주에 무엇이 바뀌었는지. 오늘날 사람들이 그 일을 하는 이유는 그 일에 필요한 컨텍스트가 십여 개의 도구와 수백 명의 머릿속에 흩어져 있기 때문입니다. 에이전트는 그 대부분을 할 수 있지만, 그 컨텍스트를 읽을 수 있을 때에만 그렇고, 컨텍스트 모델이 제공하는 것이 바로 그것입니다.

| 오늘의 역할 | 대부분 컨텍스트 검색과 일상적 변경인 일 | 에이전트가 컨텍스트 모델에서 필요로 하는 것 |
|---|---|---|
| 서비스 데스크와 운영 | 인시던트 라우팅, 소유자 찾기, 표준 변경 적용 | 소유권, 의존성, 변경 이력, 런북 |
| 플랫폼 운영자 | 프로비저닝, 노출, 인증서, DNS, WAF 예외 | 매니페스트, 정책, 모든 리소스의 현재 상태 |
| 솔루션 아키텍트와 엔터프라이즈 아키텍트 | 현재 상태 분석, 원칙에 비춘 컴플라이언스 점검, 설계와 ADR의 첫 초안 | 지형, 역량 맵, 참조 아키텍처, 과거의 결정 |
| 보안과 컴플라이언스 | 증거 수집, 통제 점검, 노출 검토 | 무엇이 노출되어 있고, 무엇을 통해, 어떤 데이터 분류와 함께인지 |
| 엔지니어와 코딩 에이전트 | 만들기 전에 올바른 서비스, API, 플랫폼, 관례 찾기 | 위의 모든 것을, MCP를 통해, 에디터 안에서 |
| 포트폴리오와 IT 관리 | 인벤토리, 비용 배분, 합리화 후보 | 애플리케이션, 소유자, 사용량, 마켓 유닛 사이의 중복 |

저는 이것이 작은 규모에서 일어나는 것을 보았습니다. 웹 딜리버리 스쿼드에서 매니페스트가 존재하고 지속형 워크플로가 그것을 읽을 수 있게 되자, 워크플로는 전담 운영자가 필요했던 운영 업무를 사실상 전부 넘겨받았습니다. 자동화는 몇 년 전부터 가능했습니다. 빠져 있던 것은 안전하게 행동할 수 있을 만큼 좋은 컨텍스트였습니다.

IT 부서 전체의 규모에서 제대로 해낸다면, 이것은 IT 조직이 필요로 하는 인원을 상당히 줄입니다. 판단을 대체해서가 아닙니다. 아키텍트가 지금 하는 일에서 주장했듯이 판단은 오히려 더 값져집니다. 그보다는 컨텍스트를 얻는 비용이 비쌌기 때문에만 존재하던 일의 큰 몫을 없애기 때문입니다. 그것이 비즈니스 케이스이고, 더 나은 아키텍처 검토보다 훨씬 큰 비즈니스 케이스입니다. 회사가 그 변화의 사람 쪽 측면을 어떻게 다루느냐는 이 플랫폼이 답하지 않는 리더십의 질문이며, 블로그 글 하나가 줄 수 있는 것보다 더 많은 정성을 받아야 마땅합니다.

## 컨텍스트는 탐색보다 쌉니다 {#context-is-cheaper-than-exploration}

비즈니스 케이스에서 사람들이 알아채는 부분은 인원입니다. 그들이 놓치는 부분은 에이전트 자신에게 일어나는 일입니다.

엔터프라이즈 컨텍스트가 없는 에이전트도 어쨌든 일을 계속합니다. 탐색을 통해서입니다. 어떤 서비스를 누가 소유하고 무엇이 그것에 의존하는지 질문을 받으면, 노트북 위의 코딩 에이전트는 리포지토리를 검색하고, README를 읽고, 배포 파일을 grep하고, 접근 권한이 있다면 클러스터를 조회하고, 위키로 이어지는 링크를 따라가고, 찾아낸 모든 것을 놓고 추론합니다. 그 단계 하나하나가 도구 호출이고, 모든 도구 결과는 컨텍스트 윈도우에 들어가며, 점점 커지는 윈도우 전체가 이어지는 매 턴마다 다시 비용으로 청구됩니다. 그러고 나면 다음 노트북의 다음 에이전트가 같은 질문을 하고 같은 탐색을 처음부터 다시 하며, 그 뒤의 모든 에이전트도 그렇게 합니다.

그 차이는 자릿수로 보면 가장 쉽게 보입니다. 아래 숫자는 측정값이 아니라 제가 예시로 추정한 값입니다.

```text
Question: "Who owns payment-gateway, and what breaks if we change its API?"

Without a Context Model                    With a Context Model
---------------------------                --------------------
~25 tool calls (search, read, grep, ...)   1 to 2 MCP calls
~150,000 to 250,000 input tokens           ~3,000 to 6,000 input tokens
over the whole exploration                 one entity and its subgraph
answer: plausible, unverified              answer: sourced, scored, current
repeated by every agent that asks          computed once, read by everyone

1,000 engineers x 20 such questions a day x ~200,000 tokens
  = ~4 billion tokens a day spent rediscovering the same facts
```

토큰은 반올림 오차가 아닙니다. [추론의 경제학](https://raskell.io/articles/the-economics-of-inference/)에서 주장했듯이, 토큰은 소프트웨어 라이선스보다 전기에 가깝게 움직이는 계량 자원이고, 수천 명에게 에이전트를 배포하는 기업은 그것을 청구서에서 느끼게 될 것입니다. 컨텍스트 모델은 반복되는 탐색을 조회로 바꿉니다. 수집 계층이 비싼 일을 한 번 하고, 점수를 매기고, 최신 상태로 유지하며, 그 뒤의 모든 에이전트는 그 결과를 읽습니다. 캐시나 구체화된 뷰(materialised view)와 같은 수를, 회사가 자기 자신에 대해 아는 것에 적용한 것입니다.

두 번째 효과는 품질입니다. 컨텍스트 윈도우는 유한하고, 탐색에 쓰인 토큰은 실제 과제에 쓰이지 못한 토큰입니다. 깨끗하고 출처가 달린 하위 그래프에서 출발하는 에이전트는 검색에 우연히 걸린 것이 아니라 올바른 사실을 놓고 추론합니다. 또한 컨텍스트 없는 에이전트의 전형적인 실수도 멈춥니다. 이미 있는 서비스를 만들고, 회사가 은퇴시키고 있는 플랫폼을 고르고, 본 적 없는 아키텍처 결정에 어긋나는 실수입니다. 회사에 중요한 의미에서, 에이전트는 어떤 모델 위에서 돌아가든 회사가 이미 아는 것에서 출발함으로써 더 똑똑해집니다. 저는 리포지토리 하나에 대해 [컨텍스트가 곧 제품입니다](https://raskell.io/articles/context-is-the-product/)와 [검색은 계층이 아니라 도구입니다](https://raskell.io/articles/retrieval-is-a-tool-not-a-layer/)에서 같은 주장을 했습니다. 컨텍스트 모델은 그 주장의 엔터프라이즈 규모 판본입니다.

세 번째 효과는 제가 과소평가했던 것입니다. 커뮤니케이션이 더 명확해집니다. 오늘날 두 팀 사이에서 “결제 게이트웨이”에 관한 대화는 세 가지 다른 것에 관한 대화일 수 있고, 변경이 엉뚱한 것을 망가뜨리기 전까지 아무도 알아채지 못합니다. 컨텍스트 모델이 있으면 엔티티가 정의되는 곳이 하나, 각 엔티티의 식별자가 하나, 그리고 모두가 쓰는 어휘인 온톨로지가 하나 있습니다.

| 사이 | 이전 | 공유된 컨텍스트 모델과 함께 |
|---|---|---|
| 사람과 사람 | 같은 시스템에 대한 서로 다른 이름, 지형에 대한 서로 다른 그림 | 엔티티 하나, 식별자 하나, 가리킬 페이지 하나 |
| 에이전트와 사람 | 에이전트의 답은 그럴듯하지만 추적할 수 없다 | 답이 엔티티를 인용하고, 각 엔티티는 자기 2차 소스를 인용한다 |
| 에이전트와 에이전트 | 각 에이전트가 따로 탐색하고 산문으로 넘겨준다 | 에이전트들이 양쪽 모두 해석할 수 있는 엔티티 참조를 넘겨준다 |

이 가운데 어느 것도 원래의 소스를 가리지 않습니다. 컨텍스트 모델이 돌려주는 모든 사실은 자기 출처를 지니고 있습니다. 어떤 기록 시스템에서 왔는지, 마지막으로 언제 관찰되었는지, 그 소스가 어떤 점수를 받았는지입니다. 온톨로지는 공통 언어이고, 기록 시스템은 확인하고 싶은 누구에게나, 사람이든 에이전트든, 클릭 한 번 거리에 남아 있습니다.

## 새로운 추상화 수준 {#a-new-level-of-abstraction}

한 걸음 물러서 보면, 이것은 IT에서 익숙한 이야기입니다. 모든 큰 진보는 사람들이 문제를 푸는 수준을 옮겨 놓았습니다. 어셈블러 덕분에 프로그래머는 기계어를 쓰지 않아도 되었습니다. C 덕분에 레지스터로 생각하지 않아도 되었습니다. 객체 지향 언어와 관리형 언어 덕분에 메모리 관리를 그만두고 도메인을 모델링하기 시작했습니다. 프레임워크, 클라우드 플랫폼, 코드형 인프라는 배관의 계층 전체를 걷어 냈습니다. 매번 일은 사라지지 않고 위로 올라갔고, 그 일을 하던 사람들은 더 큰 문제를 풀기 시작했습니다.

코딩 에이전트는 다음 걸음이고, 더 큰 걸음입니다. 2025년 11월에 나온 Claude Opus 4.5 즈음의 모델 세대 이후로, Claude Code 같은 에이전트는 점점 더 많은 팀에서 코드의 대부분을 쓰고 있습니다. [요즘 제가 일하는 방식](https://raskell.io/articles/how-i-work-these-days/)에서 설명했듯이 제 팀도 그렇습니다. 이제 기술직 종사자가 주로 만들어 내는 것은 의도, 제약, 설계, 판단이고, 코드는 점점 줄어듭니다. 저는 [소스 코드는 새로운 어셈블리입니다](https://raskell.io/articles/semantic-artifacts-and-meaning-engines/)에서, 어셈블리가 그랬던 것처럼 코드가 로어링(lowering)의 대상이 되어 가고 있다고 주장했습니다.

그것이 일을 바꿉니다. 에이전트와 함께 일하는 엔지니어는 솔루션 아키텍트나 요구 사항 엔지니어나 비즈니스 분석가처럼 시간을 씁니다. 문제를 이해하고, 무엇을 만들어야 할지 결정하고, 에이전트가 만들 수 있을 만큼 잘 명세하고, 결과가 회복력 있고 확장 가능하며 올바른지 판단합니다. 기술적 배경은 여전히 필수적입니다. 그것이 판단을 가능하게 하기 때문입니다. 하지만 그들이 일하는 수준은 계층 하나만큼 통째로 위로 올라갔습니다.

그 수준에서 가장 중요한 입력은 컨텍스트입니다. 아키텍트처럼 일하는 엔지니어는 지형을 알아야 하고, 그가 명세한 것을 만드는 에이전트도 그것을 알아야 합니다. 그래서 저는 IT 인텔리전스와 새로운 추상화가 함께 간다고 생각합니다. 컨텍스트 모델은 더 높은 수준에서 일하는 것을 안전하게 만드는 것입니다. 사람과 에이전트 모두가 그것에 맞춰 설계하는, 공유되고 최신이며 출처가 달린 그림이기 때문입니다.

## 조직이 다음 병목입니다 {#the-organisation-is-the-next-bottleneck}

엔지니어가 아키텍트와 분석가처럼 일하고 에이전트가 구현의 대부분을 수행한다면, 예전에는 서로 다른 역할과 조직도의 서로 다른 칸에 있던 역량들이 같은 사람들에게 모이기 시작합니다. 엔지니어링, 아키텍처, 요구 사항, 분석이 수렴합니다. 그리고 그것들은 관리와 의사 결정과도 경쟁하기 시작합니다. IT 조직에서 중간 관리자가 하는 일의 상당 부분은 조율입니다. 누가 무엇을 아는지 알아내고, 팀 사이를 번역하고, 일의 순서를 정하고, 상태를 보고하는 일입니다. 컨텍스트 모델과 에이전트 무리는 바로 그런 일을 많이 합니다. 에이전트를 거느린 작은 팀이 문제를 이해하고, 해법을 설계하고, 만들고, 운영할 수 있게 되면, 희소한 구현 역량을 둘러싸고 큰 팀을 조율하기 위해 존재하던 계층들은 존재 이유의 상당 부분을 잃습니다.

대부분의 엔터프라이즈 IT 조직은 그 희소성을 중심으로 설계되었습니다. 만드는 일은 느리고 비쌌기 때문에, 조직은 그것을 배급하는 구조를 키웠습니다. 수요 관리, 프로젝트 포트폴리오, 연간 예산 주기, 아키텍처 검토를 위한 긴 대기열, 요구 사항과 설계와 구축과 운영을 위한 별도의 팀들입니다. 콘웨이의 법칙은 여기서 양방향으로 작용합니다. 그 구조들이 이 글 첫머리에서 묘사한 파편화된 지형을 만들어 냈고, 바뀌지 않는다면 앞으로도 에이전트의 속도로 그것을 계속 만들어 낼 것입니다.

만드는 일이 빠르고 싸지면 병목은 옮겨 갑니다. 무엇을 만들지 결정하는 일로, 그리고 만들어진 것을 비즈니스가 흡수하는 일로 옮겨 갑니다. 돈을 버는 사업 부문들, 곧 IT가 전달하는 모든 것의 기능적 소비자들은 이제 따라와야 합니다. 필요를 충분히 정확하게 표현하고, 더 빨리 결정하고, 새 솔루션이 도착하면 자기 프로세스를 바꾸고, IT를 기다리는 대기열로 여기기를 그만두어야 합니다. 예전에는 몇 분기가 걸리던 것을 몇 주 만에 전달할 수 있는 IT 부서의 가치는 그것을 활용하는 비즈니스의 능력만큼일 뿐입니다.

올바른 조직의 형태가 무엇인지 저는 아직 모릅니다. 그 성질 가운데 몇 가지는 꽤 확신합니다.

- **더 넓은 권한을 가진 더 작은 팀.** 각 팀이 하나의 문제를 이해에서 운영까지 소유하고, 에이전트가 구현의 대부분을 합니다.
- **비즈니스에 더 가까운 결정권.** 필요를 이해하는 사람과 이제 해법을 만들 수 있는 사람이 점점 같은 사람이 되거나 같은 테이블에 앉게 되기 때문입니다.
- **프로젝트가 아니라 제품과 성과에 따른 예산 배정.** 프로젝트는 희소한 구현 역량의 단위인데, 그 역량은 더 이상 희소한 것이 아니기 때문입니다.
- **검토 대기열이 아니라 자동화된 관문으로서의 거버넌스.** 설계 시점에 설계를 컨텍스트 모델에 비추어 점수 매기고, 정말로 사람이 필요한 것만 위로 올립니다. 임계값을 둔 설계 시점의 리스크와 아키텍처는 루프가 됩니다에서처럼입니다.
- **인프라로서의 회사에 대한 공유된 그림.** 컨텍스트 모델이 존재하는 이유가 바로 이것입니다.

이것은 정도의 변화가 아니라 종류의 변화입니다. 기술이 만들어지는 방식을 바꾸고, 이제 기술이 생산될 수 있는 속도로 그것을 흡수하려면 조직이 어떻게 만들어져야 하는지도 바꿉니다. IT 인텔리전스 없이 코딩 에이전트를 도입하는 회사는 잘못된 것을 더 빨리 만들게 될 것입니다. 둘 다 도입하되 조직을 바꾸지 않는 회사는 올바른 것을 만들고 나서 조직이 따라잡기를 기다리게 될 것입니다. 세 가지를 모두 하는 회사는 5년 뒤에 그렇지 않은 회사와 아주 다른 모습일 것입니다.

## 관련 연구, 그리고 이것이 아닌 것 {#related-work-and-what-this-is-not}

여기 있는 개별 아이디어 가운데 새로운 것은 없으며, 앞서 이루어진 작업은 인정받아야 마땅합니다.

**자동화된 EA 문서화.** TU Munich(뮌헨 공과대학교)와 University of Innsbruck(인스브루크 대학교)의 연구자들은 10년 넘게 엔터프라이즈 아키텍처 모델을 손이 아니라 자동으로 최신 상태로 유지하는 방법을 연구해 왔습니다. Farwick(파르비크)과 동료들은 2011년에 자동화된 EA 모델 유지 관리의 요구 사항을 정리했고, 2013년에는 회사 안의 어떤 정보 소스가 EA 모델을 채울 수 있는지, 그리고 그 데이터의 품질이 어떤지를 분석했습니다. 이는 위에서 설명한 수집과 점수 매기기의 문제입니다. Martin Kleehaus(마르틴 클레하우스)와 Florian Matthes(플로리안 마테스)는 이후 서비스의 런타임 계측이 EA 모델을 어떻게 최신 상태로 유지할 수 있는지 보여 주었습니다. 더 최근에는 Reitemeyer(라이테마이어)와 Fill(필)이 대규모 언어 모델과 지식 그래프가 엔터프라이즈 모델링에서 어떻게 결합되는지를 조사했습니다. 이 연구들은 컨텍스트 모델의 가장 가까운 학문적 조상이며, 이 문제가 오래된 것임을 보여 줍니다. 하지만 그 목표는 더 나은 EA 모델입니다. 여기서의 목표는 에이전트가 그 위에서 일할 수 있는 데이터 계층입니다.

**AI 컨텍스트 플랫폼.** 2026년, 업계는 같은 공백을 반대편에서 발견했습니다. 벤더들이 요약한 보고서에 따르면 Gartner는 *AI 컨텍스트 플랫폼*(AI context platforms)이라는 범주를 설명하기 시작했습니다. 의미적으로 조직된 지식을 구성하고, 관리하고, AI 에이전트에게 전달하는 소프트웨어입니다. 올해 몇몇 제품이 그 깃발 아래 출시되었습니다. TopQuadrant는 TQ Data Foundation을 명시적으로 엔터프라이즈 컨텍스트 플랫폼으로 내세웁니다. DataHub는 백 개가 넘는 데이터 시스템의 메타데이터를 그래프로 합쳐 MCP로 에이전트에게 제공하는 컨텍스트 플랫폼을 출시했습니다. Neo4j는 컨텍스트 엔진을 발표했습니다. 그리고 EA 도구 벤더인 Ardoq는 그래프 데이터베이스 GraphLake를 인수해 스스로 “엔터프라이즈 AI를 위한 EA 수준의 컨텍스트 그래프”라고 부르는 것을 만들고 있으며, 그 CEO는 엔터프라이즈 아키텍처가 “AI 스택의 나머지가 그 위에서 돌아가는 기반”이라고 선언했습니다.

저는 시장의 등장을 이 공백이 실재한다는 확인으로 받아들이며, “엔터프라이즈 컨텍스트 플랫폼”이라는 말에 손을 뻗은 사람이 저 혼자가 아니라는 것도 분명합니다. 그러나 차이는 중요하고, 그 차이가 이것을 또 하나의 EA 리포지토리나 또 하나의 데이터 카탈로그로 읽어서는 안 되는 이유입니다.

| | EA 리포지토리 | 데이터 카탈로그와 컨텍스트 제품 | 엔터프라이즈 컨텍스트 플랫폼 |
|---|---|---|---|
| 무엇을 기술하는가 | 아키텍트가 큐레이션한 애플리케이션 포트폴리오 | 분석용 데이터: 테이블, 지표, 리니지 | IT에서 일어나는 모든 것: 포트폴리오, 코드, 런타임, 노출, 운영, 결정 |
| 데이터는 어디서 오는가 | 대부분 수동 입력 | 데이터 플랫폼과 BI 도구 | 모든 기록 시스템과 모든 플랫폼, 정확도 점수와 함께 |
| 얼마나 최신인가 | 마지막 검토만큼 | 데이터 스택에 가깝게 | 소스만큼, 모든 사실에 “마지막 관찰” 시점과 함께 |
| 누구를 위한 것인가 | 아키텍트 | 분석가와 분석 에이전트 | IT의 모든 사람과 모든 에이전트, 어떤 역할이든 |
| 권위 | 리포지토리가 기록이다 | 소스를 비춘다 | 기본은 2차, 선언된 곳에서는 1차 |
| 접근 | 라이선스를 가진 사용자 | 라이선스, 대개 사용자 단위 | 기본적으로 모두에게 열림 |
| 기술 | 벤더 제품 | 벤더 제품 | 오픈 소스, 읽을 수 있고, 기여로 확장 가능 |

가장 가까운 이웃은 Backstage 같은 개발자 포털입니다. 그 소프트웨어 카탈로그는 소프트웨어 조직에 무엇이 존재하는지에 관한 하나의 모델을 줍니다. 컨텍스트 모델은 그 아이디어를 하나의 엔지니어링 조직에서 IT 부서 전체로, 그리고 카탈로그를 둘러보는 사람에서 일을 하는 에이전트로 확장한 것입니다.

## 트레이드오프와 반론 {#tradeoffs-and-objections}

**“이건 그냥 CMDB입니다.”** CMDB는 팀들에게 손으로 관리해 달라고 요청하는 기록 시스템이고, 그래서 현실에서 멀어집니다. 컨텍스트 모델은 기본적으로 도출되는 것입니다. 누가 무언가를 입력해 주기를 기대지 않습니다. 시스템들이 이미 말하고 있는 것을 읽고, 자기 의견을 소스와 분리해 둡니다. CMDB가 옳은 곳에서는 모델이 그것에 동의합니다. CMDB가 틀린 곳에서는 모델이 그 불일치를 보여 주며, 그것 자체가 쓸모 있습니다.

**“이건 커넥터가 더 많은 EA 리포지토리일 뿐입니다.”** EA 리포지토리는 포트폴리오 관점에서 매우 뛰어나며, 여기서 가장 중요한 소스 가운데 하나입니다. 하지만 그것은 아키텍트가 의도하고 큐레이션한 대로의 지형을, 1년에 몇 번, 라이선스를 가진 소수의 독자를 위해 기술합니다. 클러스터에서 무엇이 돌아가는지, WAF가 무엇을 통과시키는지, 어떤 코드 리포지토리가 실제로 애플리케이션을 구현하는지, 어젯밤 어떤 인시던트가 그것을 덮쳤는지, 어떤 변경이 진행 중인지 알지 못합니다. 컨텍스트 모델은 그 모든 것으로, 지속적으로, IT에서 일하는 모든 사람과 에이전트를 위해 만들어집니다. EA 리포지토리는 그것을 먹여 주는 소스이고, 둘은 같은 종류의 것이 아닙니다.

**“AI의 도움을 받는 수집은 환각된 아키텍처를 뜻합니다.”** 추론된 엣지가 사실로 제시된다면 그렇겠지요. 그렇지 않습니다. 추론된 관계는 자기 신뢰도와 근거를 지니고, 신뢰도가 낮은 것은 소유 팀의 확인을 기다리는 대기열에 들어가며, 확인되면 이름과 날짜가 붙은 단언된 사실이 됩니다. 이것이 없다면 저는 이 플랫폼을 믿지 않을 것이고, 다른 누구도 믿어서는 안 됩니다.

**“왜 직접 만듭니까?”** 일부는 온톨로지가 곧 제품이고, 기성품으로 산 온톨로지는 다른 누군가의 기업을 담고 있기 때문입니다. 일부는 소스들이 벤더 도구와 내부 플랫폼의 특정한 조합이어서 어떤 제품도 그것을 다 다루지 못하기 때문입니다. 일부는 사람들에게 믿고 기여해 달라고 요청하는 플랫폼은 그들이 읽을 수 있는 것이어야 하는데, 오픈 소스 스택은 그것을 허락하고 벤더 제품은 그렇지 않기 때문입니다. 그리고 일부는 누군가에게 예산을 요청하기 전에 이 아이디어가 성립하는지 알아야 했기 때문입니다. 직접 만든 플랫폼은 정직한 시험 가운데 가장 저렴한 것입니다.

**“IT 지형의 열린 지도는 공격자를 돕습니다.”** 제가 가장 자주 듣는 반론입니다. 이미 네트워크 안에 들어온 공격자는 시간만 충분하면 지형의 대부분을 파악할 수 있습니다. 오늘날 방어자와 만드는 사람들은 그러지 못하는 경우가 많습니다. 지도를 닫아 두는 것은 주로 공격자의 인내심이라는 이점을 지켜 줄 뿐입니다. 진짜 보호는 시스템 자체에, 곧 아이덴티티, 네트워크 통제, 시크릿 관리에 있어야 하며, 동료들이 무엇이 존재하는지 알기 어렵게 만드는 데 있어서는 안 됩니다. 특정 취약점이나 자격 증명처럼 하나의 세부 사항이 정말로 위험한 경우, 그것은 IT 컨텍스트가 아니며 모델에 들어가지 않습니다.

치르는 비용은 이렇습니다. 소스가 API를 바꾸면 커넥터가 깨지고, 아이덴티티 해석은 지속적인 관리가 필요하며, 접근이 진짜 제약입니다. IT 지형 전체를 보는 플랫폼은 IT 지형 전체에 대한 읽기 접근이 필요하고, 규제받는 금융 그룹에서 그것은 설정 변경이 아니라 대화입니다. 이에 대해서는 병목은 읽기 접근입니다에 썼습니다.

## 제가 경계하고 있는 실패 양상 {#failure-modes-i-am-watching-for}

- **예쁜 그래프.** 데모에서는 인상적이지만 실제 질문에는 하나도 답하지 못하는 UI. 시험은 아키텍트들이 요청받지 않고도 검토 전에 그것을 여는지입니다.
- **조용한 낡음.** 소스 커넥터가 실패하고, 모델은 지난달의 상태를 계속 보여 주며, 아무도 알아채지 못합니다. 모든 엔티티에는 “마지막 관찰” 시점이 필요하고, UI는 그것을 보여 주어야 합니다.
- **온톨로지의 무분별한 팽창.** 모든 팀이 자기만의 엔티티 유형을 원합니다. 모델은 한 사람이 화이트보드에서 설명할 수 있을 만큼 작게 유지되어야 합니다.
- **산출물에 대한 과신.** 생성된 비즈니스 케이스가 잘 읽히지만, 소유 팀만 알아챌 수 있는 방식으로 틀려 있습니다. 산출물은 답이 아니라 출처가 달린 초안입니다.
- **두 번째 그림자 리포지토리.** 사람들이 2차 데이터를 기록 시스템이 아니라 플랫폼에서 고치기 시작하면, 플랫폼은 자기가 고치려던 바로 그것이 됩니다. 2차 데이터의 수정은 소스로 돌아갑니다. 명시적으로 1차로 선언된 데이터만 컨텍스트 모델 안에서 관리됩니다.
- **예외로 깎여 나가는 개방성.** 필드 하나를 숨겨 달라고 요청하는 팀마다 그럴듯한 이유가 있습니다. 그런 요청을 충분히 들어주면 모델은 또 하나의 사일로가 됩니다. 예외에는 높은 기준과 공개된 목록이 필요합니다.
- **조작된 점수.** 점수가 지위를 띠게 되면, 누군가는 정확도가 아니라 점수를 최적화할 것입니다. 신호는 다른 소스와의 일치에 근거를 두어야 하며, 그것은 꾸며 내기 어렵습니다.

## 맺으며 {#closing}

비즈니스 인텔리전스는 회사를 경영진이 읽을 수 있게 만들었습니다. IT 인텔리전스는 회사를 그것을 만드는 모든 이들, 사람과 에이전트 모두가 읽을 수 있게 만듭니다. 그리고 소프트웨어가 만들어지는 수준이 위로 올라가면서, 회사에 대한 그 공유된 그림은 다른 모든 것이 그 위에 지어지는 토대가 됩니다. 제가 아키텍처를 위해 스케치한 루프에는 출발할 곳과 다시 내려앉을 곳이 필요하고, 컨텍스트 모델은 그 둘 모두가 되고자 합니다.

## 참고 문헌 {#references}

지식, 암묵적인 것과 형식적인 것:

- Michael Polanyi, *The Tacit Dimension*, Doubleday, 1966; reissued by the University of Chicago Press, 2009, with a foreword by Amartya Sen.
- Ikujiro Nonaka and Hirotaka Takeuchi, *The Knowledge-Creating Company*, Oxford University Press, 1995; 두 사람의 [SECI 모델](https://en.wikipedia.org/wiki/SECI_model_of_knowledge_dimensions) 개요.
- James C. Scott, *Seeing Like a State*, Yale University Press, 1998, 메티스에 관한 9장.
- Daniel M. Wegner, "Transactive Memory: A Contemporary Analysis of the Group Mind", in B. Mullen and G. R. Goethals (eds.), *Theories of Group Behavior*, Springer, 1987; Wegner 자신이 쓴 [교류 기억 요약](https://dtg.sites.fas.harvard.edu/DANWEGNER/wjh/tm.htm).
- Guilherme Avelino, Leonardo Passos, Andre Hora and Marco Tulio Valente, [A Novel Approach for Estimating Truck Factors](https://arxiv.org/abs/1604.06766), ICPC 2016.
- [Tribal knowledge](https://en.wikipedia.org/wiki/Tribal_knowledge), Wikipedia, 용어와 그 쓰임에 관하여.

사일로, 은폐, 이전:

- Thomas H. Davenport, Robert G. Eccles and Laurence Prusak, "Information Politics", *Sloan Management Review* 34(1), 1992, pp. 53 to 65.
- Catherine E. Connelly, David Zweig, Jane Webster and John P. Trougakos, [Knowledge hiding in organizations](https://doi.org/10.1002/job.737), *Journal of Organizational Behavior* 33(1), 2012, pp. 64 to 88; Queen's University의 더 짧은 [연구 요약](https://smith.queensu.ca/insight/content/research-brief-knowledge-hiding-in-organizations.php).
- Gabriel Szulanski, "Exploring Internal Stickiness: Impediments to the Transfer of Best Practice Within the Firm", *Strategic Management Journal* 17, Winter Special Issue, 1996, pp. 27 to 43.
- Morten T. Hansen, [The Search-Transfer Problem: The Role of Weak Ties in Sharing Knowledge across Organization Subunits](https://doi.org/10.2307/2667032), *Administrative Science Quarterly* 44(1), 1999, pp. 82 to 111.
- Carl G. Sieloff, ["If only HP knew what HP knows": the roots of knowledge management at Hewlett-Packard](https://doi.org/10.1108/13673279910259385), *Journal of Knowledge Management* 3(1), 1999.
- Gillian Tett, *The Silo Effect: The Peril of Expertise and the Promise of Breaking Down Barriers*, Simon and Schuster, 2015.
- Jeffrey Pfeffer and Robert I. Sutton, *The Knowing-Doing Gap*, Harvard Business School Press, 2000.

자동화된 EA 문서화:

- Farwick, Agreiter, Breu, Ryll, Voges and Hanschke, "Requirements for Automated Enterprise Architecture Model Maintenance", ICEIS 2011.
- Farwick, Breu, Hauder, Roth and Matthes, "Enterprise Architecture Documentation: Empirical Analysis of Information Sources for Automation", HICSS 2013.
- Roth, Hauder, Farwick, Breu and Matthes, "Enterprise Architecture Documentation: Current Practices and Future Directions", Wirtschaftsinformatik 2013.
- Martin Kleehaus and Florian Matthes, [Automated Enterprise Architecture Model Maintenance via Runtime IT Discovery](https://doi.org/10.1007/978-3-030-49640-1_13), in *Intelligent Systems Reference Library* 188, Springer, 2021, pp. 247 to 263.
- Reitemeyer and Fill, [Applying Large Language Models in Knowledge Graph-based Enterprise Modeling: Challenges and Opportunities](https://arxiv.org/abs/2501.03566), 2025.

AI 컨텍스트 플랫폼(2026):

- Gartner, *Market Overview for AI Context Platforms*, 13 August 2026, and *How to Navigate the Emerging AI Context Platform Market*, 1 September 2026; 저는 [초록](https://www.gartner.com/en/documents/8486545)과, [Atlan의 것](https://atlan.com/know/ai-agent/context-layer/gartner-impact-radar-ai-context-platform/) 같은 벤더 요약만 읽었습니다.
- TopQuadrant, [TopQuadrant Launches Enterprise Context Platform to Build Trusted AI](https://www.einpresswire.com/article/893232971/topquadrant-launches-enterprise-context-platform-to-build-trusted-ai), 18 February 2026.
- DataHub, [Announcing the DataHub Context Platform](https://datahub.com/?p=14496), 2026.
- Neo4j, [Neo4j Context Engine](https://neo4j.com/?p=433599), October 2026.
- Ardoq, [Ardoq Acquires GraphLake to Establish the EA-Grade Context Graph for Enterprise AI](https://www.ardoq.com/news/ardoq-graphlake-context-graph-enterprise-ai), 8 June 2026.
- [Backstage software catalog](https://backstage.io/docs/features/software-catalog), 이 아이디어의 개발자 포털 판본.

조직과 아키텍처:

- Melvin E. Conway, [How Do Committees Invent?](http://www.melconway.com/Home/Committees_Paper.html), *Datamation* 14(4), 1968, pp. 28 to 31.
- Matthew Skelton and Manuel Pais, *Team Topologies*, IT Revolution, 2019.
- Zhamak Dehghani, [Data Mesh](https://www.thoughtworks.com/insights/books/data-mesh), O'Reilly, 2022.
- Jeanne W. Ross, Peter Weill and David C. Robertson, *Enterprise Architecture as Strategy*, Harvard Business School Press, 2006.
- Michael Nygard, [Documenting Architecture Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions), ADR의 기원.

콘퍼런스:

- [RSAC Conference](https://www.rsaconference.com/About/FAQ), San Francisco.
- Raffael Schneider and Milan Duric, [Self-Learning WAF: Using Generative AI to Tame ModSecurity False Positives](https://path.rsaconference.com/flow/rsac/us26/FullAgenda/page/catalog/session/1753946922633001YdMq), RSAC 2026, session NCS-W01.

기술:

- Anthropic, [Introducing Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5), November 2025.
- [Model Context Protocol](https://modelcontextprotocol.io/), 에이전트 엔드포인트 뒤에 있는 프로토콜.