조직 기억을 재배선하다: Dynamic, Kinetic and Semantic

하나의 캠페인, 네 개의 시스템

마케팅팀이 SNS 캠페인을 올렸다. 24시간 만에 특정 제품군이 바이럴됐다. 문의가 쏟아진다.

이때 조직 안에서 무슨 일이 일어나야 하는가.

CRM에 신규 리드가 쌓인다. 그 리드가 구매로 전환되면 SCM의 재고가 소진되기 시작한다. 재고가 임계점 아래로 내려가면 ERP가 추가 발주를 처리해야 한다. 발주량 급증은 생산 일정을 바꾸고, HRM의 인력 배치 계획이 수정돼야 한다.

마케팅 캠페인 바이럴
        ↓
CRM: 신규 리드 급증 → 전환율 추적
        ↓
SCM: 재고 소진 경보 → 공급망 긴장
        ↓
ERP: 긴급 발주 승인 → 재무 처리
        ↓
HRM: 생산 인력 추가 배치 → 일정 재조정

이것은 하나의 사건에서 시작된 연쇄다. 그런데 현실에서 이 연쇄는 자동으로 흐르지 않는다. 각 팀이 각자의 시스템에서 각자의 속도로 반응한다. 그냥 시스템들을 연결하면 될까. 생각보다 문제가 깊다.

왜 단절됐는가 — 역사와 조직 경계

ERP, CRM, HRM, SCM의 경계를 거슬러 올라가면 1960–90년대 기업 조직도가 나온다.

재무팀, 영업팀, 인사팀, 물류팀은 서로 실시간으로 소통하지 않았다. 인보이스, 계약서, 주문서 같은 문서로 핸드오프했다. 각 부서는 자신의 업무를 처리하는 도구를 독자적으로 만들었다. ERP는 재무·생산 부서의 언어로, CRM은 영업팀의 언어로, HRM은 인사부의 언어로 설계됐다.

Conway's Law가 정확하게 작동한 결과다. 역방향도 작동했다. 소프트웨어가 조직 경계를 코드화하면서 그 경계를 더 단단하게 만들었다. SAP가 ERP 위에 CRM을 올려도 각 모듈의 언어가 통합되지 않는 이유다. 소프트웨어 경계를 허물려면 조직 경계를 허물어야 한다.

에이전트는 이 경계를 처음으로 모르는 "직원"이다. 캠페인이 재고에 영향을 미치는지 분석하려면 CRM과 SCM을 동시에 읽어야 한다. 에이전트는 부서 경계를 신경 쓰지 않는다. 그러나 시스템은 여전히 부서 경계를 기억하고 있다.

재배선의 두 레이어 — 기억과 실행

재배선에는 두 레이어가 있다.

첫째, 기억 재배선. ERP, CRM, HRM, SCM이 서로 말하게 만드는 것이다. 에이전트가 시스템 경계를 넘어 데이터를 읽을 수 있게 된다.

둘째, 실행 재배선. 조직이 어떻게 결정하고 실행하는가를 명시화하는 것이다.

기억 재배선만 되면 에이전트가 더 빠르게 분석하고 더 빠르게 멈춘다. 에이전트가 재고 소진을 감지했다. 발주를 넣어야 한다. 그런데 이 발주는 누가 승인하는가? 한도는 얼마인가? 어떤 조건이면 자동 처리가 가능한가? 이 정보는 ERP에 없다. 담당자 머릿속에 있고, 슬랙 채널에 흩어져 있다.

기억 온톨로지 (System of Record):
  엔티티 + 관계 = "무엇이 있는가, 어떤 상태인가"
  → ERP, CRM, HRM, SCM에 저장됨

실행 온톨로지 (System of Action):
  권한 + 프로세스 + 에스컬레이션 = "어떻게 결정하고 실행하는가"
  → 사람 머릿속, 슬랙, 이메일에 분산됨

연쇄가 자동으로 흐르려면 에이전트가 실행 온톨로지 위에서 작동해야 한다.

Dynamic — 데이터는 살아 움직인다

기억 재배선의 첫 번째 조건이다. 연결된 데이터가 "언제의" 데이터인지를 에이전트가 알아야 한다.

구체적 시나리오

캠페인이 터진 오전 9시, 에이전트가 SCM에서 재고를 조회한다. SAP에서 응답이 온다.

{ "item": "SKU-4421", "stock": 423, "warehouse": "ICN-A" }

타임스탬프가 없다. 이 423개는 언제 기준인가. SAP의 기본 재고 API는 마지막 배치 집계 기준값을 반환한다. 새벽 6시 배치였다면, 이미 3시간 동안 캠페인 주문이 들어왔을 것이다. 에이전트는 소진된 재고를 423개라고 믿고 발주량을 계산한다.

올바른 설계는 두 가지다. CDC(Change Data Capture)로 실시간 변경을 스트리밍하거나, API 응답에 타임스탬프와 불확실성 범위를 포함시킨다.

{
  "item": "SKU-4421",
  "stock": 423,
  "as_of": "2026-05-24T06:00:00Z",
  "volatility": "high",
  "ttl_seconds": 300,
  "note": "배치 기준값. 실시간 CDC 미적용."
}

에이전트는 이 응답을 받으면 "06:00 기준 423개였으나, 캠페인 진행 중이므로 현재 재고는 불확실합니다"라고 추론한다.

[!note] 구현 난이도: HARD (9–15개월)

SAP/Oracle CDC: Debezium 커넥터가 데이터베이스 트랜잭션 로그를 읽어 Kafka 토픽으로 스트리밍. SAP HANA는 엔터프라이즈 라이선스 + 커스텀 커넥터 튜닝이 필요하다. 3–4개월 소요.

Salesforce CDC: 네이티브 Change Events REST API 지원. 상대적으로 쉽지만 API 쿼터 관리가 필요하다. 1–2개월 소요.

Pace Layering 적용: 변동성에 따라 TTL을 다르게 설정한다. HRM 조직도(분기 단위) → TTL 90일. CRM 고객 정보(주 단위) → TTL 7일. SCM 재고(시간 단위) → TTL 5분. 시장 가격(분 단위) → TTL 실시간.

가장 흔한 실패: 타임스탬프 없는 API를 에이전트가 현재 상태로 오해하는 Temporal Hallucination. 특히 야간 배치를 낮에 참조할 때 발생.

Dynamic 설계의 세 원칙:

1. 타임스탬프를 붙인다. 에이전트가 읽는 모든 데이터는 언제의 데이터인지를 함께 받아야 한다.

2. 휘발성을 분류한다. Stewart Brand의 Pace Layering을 적용해 데이터 종류별 TTL 정책을 명시한다.

3. 불확실성을 명시한다. 오래된 데이터를 쓸 때 에이전트는 그 불확실성을 추론에 반영해야 한다.

→ Pace Layering — Stewart Brand

Kinetic — 실행 온톨로지 위에서 움직이다

Kinetic의 병목은 기술이 아니다. API는 이미 있다. 문제는 그 쓰기가 어떤 조건에서, 어떤 순서로, 누구의 승인 아래 일어나야 하는지가 기계가 읽을 수 있는 형태로 존재하지 않는다는 것이다.

구체적 시나리오

에이전트가 재고 소진을 감지하고 ERP에 긴급 발주를 생성하려 한다. 현실의 발주 프로세스는 이렇다.

재고 < 100 AND 캠페인 중
    → 발주 요청 생성
    → 금액 확인
         500만 원 이하: 물류팀장 자율 승인 (당일)
         500만 원 초과: CFO 결재 (1–2일)
         긴급(재고 < 20): 물류팀장 즉시 연락 → 유선 승인 후 처리
    → SCM 반영 → 공급사 발송

이 흐름은 어디에도 코드화되어 있지 않다. 물류팀장의 머릿속에 있다. 에이전트가 재고 23개를 감지하고 발주를 생성하면, 긴급 프로세스인지 일반 프로세스인지 알 수 없다. 최악의 경우 에이전트가 일반 프로세스로 ERP에 발주를 생성하지만, 실제로는 즉시 전화가 필요한 상황이었다.

실행 온톨로지는 이 흐름을 명시화한다. BPMN 2.0 형태로 표현하면:

<process id="emergency-reorder">
  <startEvent>재고 임계치 이하</startEvent>
  <gateway type="exclusive">
    <condition>재고 < 20</condition>
    <path to="urgent-call">긴급 유선 승인</path>
    <path to="normal-approval">일반 승인 흐름</path>
  </gateway>
  <userTask id="urgent-call" assignee="logistics-manager">
    즉시 전화 승인 요청
  </userTask>
  <serviceTask id="erp-create">ERP 발주 생성</serviceTask>
</process>

에이전트가 이 BPMN을 읽을 수 있다면, "재고 23개 → 긴급 프로세스 → 물류팀장에게 즉시 알림 → 승인 후 ERP 생성"을 스스로 판단한다.

[!note] 구현 난이도: VERY HARD (12–24개월)

실행 온톨로지 추출의 두 가지 접근:

방법 1. 수동 인터뷰 (6–9개월): 각 부서 담당자 인터뷰 → 프로세스 문서화 → BPMN 변환. 빠르지만 "실제로 하는 것"이 아닌 "해야 한다고 생각하는 것"을 포착하는 경향이 있다. ERP/CRM 감사 로그와 대조 검증 필요.

방법 2. 프로세스 마이닝 (8–12개월): Celonis, SAP Signavio 같은 도구가 시스템 감사 로그를 분석해 실제 실행 패턴을 역공학. "사람들이 실제로 어떻게 일하는지"를 데이터로 포착한다. 단, 과거 로그가 충분해야 하고 비정형 채널(슬랙, 이메일)은 여전히 사각지대다.

BPMN → 에이전트 연결: Camunda/Zeebe가 BPMN 프로세스를 실행하고, 에이전트는 Camunda API를 통해 현재 프로세스 상태를 조회하고 태스크를 완료 처리한다. 성숙한 패턴이지만 기업 도입 사례는 아직 적다.

가장 흔한 실패: 에이전트가 자신의 Bounded Context 안에서는 올바르게 행동했지만, 상위 프로세스가 다른 타이밍이나 알림을 기대해 운영 혼란 발생. 실행 온톨로지는 단일 시스템이 아니라 조직 전체 프로세스를 커버해야 한다.

실행 온톨로지가 없는 에이전트는 결국 고급 알림 시스템이다. 연쇄를 감지하지만 닫지는 못한다.

에이전트가 실행할 때 추가로 세 가지가 달라진다. 되돌릴 수 없는 행동이 생기고, 권한 설계가 필수가 되며, 감사 추적이 필요해진다. 4편 거버넌스의 Rail과 Checkpoint가 여기서 시작된다.

→ NIST SP 800-207, Zero Trust Architecture (2020)

Semantic — 언어 장벽은 기억과 실행 모두에 있다

에이전트가 "이번 캠페인 전환 고객의 첫 구매 금액이 재고 소진 속도에 영향을 미쳤는가"를 분석하려 한다. 이 질문에 답하려면 CRM과 ERP의 고객 데이터를 연결해야 한다.

구체적 시나리오

Salesforce CRM의 고객:

Account_ID: 0013X00001ZJxAB
Account_Name: ABC 주식회사
Type: Customer - Direct

SAP ERP의 고객:

BP_NUMBER: 100045
BP_NAME: ABC(주)
CUSTOMER_CLASS: Z001 (국내 일반)

같은 회사다. 그런데 ID가 다르고, 이름 표기도 다르며, 분류 체계도 다르다. 에이전트가 두 시스템을 연결하려면 MDM 골든 레코드가 필요하다.

MDM 골든 레코드:
  master_id: CORP-KR-00123
  canonical_name: ABC 주식회사
  refs:
    salesforce: 0013X00001ZJxAB
    sap_erp:    100045
    workday:    WD-EMP-CORP-00123

에이전트는 이 골든 레코드를 통해 "ABC 주식회사 = Salesforce Account = SAP BP = Workday 고객사"를 알게 된다. 이후 어느 시스템에서 조회해도 같은 개념을 다루고 있음을 안다.

실행 레이어에서 Semantic Gap은 한 겹 더 있다. "승인"이라는 단어가 시스템마다 다르다.

시스템	"승인"의 의미
CRM	리드 검증 완료 (영업 자격 확인)
ERP	구매 발주 결재 (재무 권한 확인)
HRM	인력 배치 확정 (조직 권한 확인)

에이전트가 "승인을 받아야 합니다"라는 프로세스 흐름을 읽을 때, 어느 시스템의 어떤 승인인지 명시되어 있지 않으면 잘못된 시스템에 잘못된 요청을 보낸다.

[!note] 구현 난이도: HARD (12–18개월)

MDM 구축 단계:

Phase 1 (3–4개월): 시스템별 엔티티 정의 감사. "고객"이 각 시스템에서 어떻게 정의되는지, 카디널리티는 어떻게 되는지 매핑. 이 단계에서 숨겨진 의미 충돌이 드러남.

Phase 2 (4–6개월): MDM 허브 구축. SAP MDG, Informatica MDM, 또는 커스텀 골든 레코드 구조 선택.

Phase 3 (5–8개월): 실행 컨텍스트별 언어 정의. "승인"이 각 Bounded Context에서 무엇인지 명시.

실패율: Phase 1에서 40–50% 프로젝트가 이탈. 시스템 간 의미 충돌의 규모가 예상보다 크기 때문.

주요 도구: SAP Master Data Governance, dbt Semantic Layer(분석 쿼리용), Neo4j/Memgraph(온톨로지 그래프 저장), Stardog(엔터프라이즈 지식 그래프).

가장 흔한 실패: 데이터 레이어 MDM은 완성했지만 실행 레이어의 언어 통합을 생략. 에이전트가 같은 회사를 올바르게 연결하지만, "발주 승인"이 어느 시스템의 어떤 액션인지 혼동해 잘못된 워크플로우를 트리거.

Semantic 설계의 핵심은 공통 언어의 명시화다. 2편의 Message Bus가 공통 명령 구조를 요구했듯, 에이전트가 기억과 실행을 모두 넘나들려면 두 레이어 모두에 공통 어휘가 필요하다.

→ Eric Evans, Domain-Driven Design (2003) → dbt Semantic Layer → W3C OWL, RDF — 온톨로지 표준

세 조건이 교차하는 순간

Dynamic, Kinetic, Semantic은 독립적인 문제가 아니다. 캠페인 시나리오에서 세 가지가 동시에 얽힌다.

에이전트에게 "이번 바이럴 캠페인에 대응해 재고 발주를 조정해야 하는가"를 물었다.

Semantic: CRM의 신규 리드가 ERP의 어떤 고객 세그먼트로 이어지는가. MDM 골든 레코드가 없으면 연결이 끊긴다. "발주 승인"이 이 맥락에서 어떤 시스템의 어떤 액션인지 알아야 한다.
Dynamic: 재고 데이터는 얼마나 신선한가. 캠페인 중 배치 기준값을 현재값으로 오해하면 Temporal Hallucination이 발생한다.
Kinetic: 재고 소진 감지 후 실행 온톨로지가 긴급 발주 조건인지 일반 발주 조건인지 판단한다. 권한 구조와 프로세스 흐름이 명시되어 있어야 에이전트가 연쇄를 닫을 수 있다.

재배선이 완성됐을 때 에이전트는 연쇄 전체를 닫는다. 그것이 빠른 개선의 실체다.

재배선 순서 — 무엇을 먼저 만드는가

순서가 있다. 이 순서를 어기면 에이전트는 빠르게 감지하고 느리게 실행하는 도구가 된다.

1. Semantic 먼저. MDM으로 기억 레이어의 공통 어휘를 확립하고, 실행 레이어의 Bounded Context별 언어를 정의한다. 이것 없이는 에이전트가 시스템 경계를 넘는 질문에 답할 수 없다. 12–18개월, 40–50% 실패율.

2. Dynamic 다음. 변동성 분류와 타임스탬프 API를 구축한다. Semantic이 "무엇"을 연결하는지 정의했다면, Dynamic은 "언제의" 데이터인지를 보장한다. 9–15개월.

3. 실행 온톨로지 명시화. 수동 인터뷰 또는 프로세스 마이닝으로 권한 구조, 프로세스 흐름, 에스컬레이션 경로를 BPMN 등의 형태로 코드화한다. 가장 어렵고 가장 오래 걸린다. 12–24개월.

4. Kinetic 마지막. 1–3이 갖춰진 다음에야 에이전트에게 실행 권한을 부여한다. 실행 온톨로지 없이 Kinetic을 열면 에이전트가 맞는 판단을 해도 조직 실행 구조 밖에서 움직인다.

전체 타임라인을 순차적으로 더하면 3–5년이다. 그러나 현실에서는 병렬 진행이 가능하고, 시스템별 범위를 좁혀 시작할 수 있다. 전사 MDM 대신 "이번 캠페인 도메인에서만"으로 범위를 좁히면 3–6개월에 MVP를 만들 수 있다.

2편의 Team Topologies 언어로 번역하면:

Platform Team이 만드는 것: Semantic Layer, Dynamic API, 실행 온톨로지, Kinetic 권한 모델. 이것이 단절된 기억과 실행을 함께 재배선하는 인프라다.

Stream-aligned(비서형 에이전트)가 하는 것: 그 인프라 위에서 도메인 질문을 던지고, 실행 흐름 안에서 판단하고, 허용된 범위에서 실행한다.

Brynjolfsson 외(QJE, 2025)가 측정한 에이전트의 생산성 향상은 이 인프라가 갖춰진 환경에서 발생한다.

빠른 개선은 기억 재배선과 실행 재배선이 함께 완성될 때 가능하다.

4편 거버넌스에서는 실행 온톨로지를 통제 가능하게 만드는 방법을 다룬다. Rail, Checkpoint, Guardrail은 에이전트가 실행 흐름 안에서 안전하게 움직이도록 경계를 보장하는 설계다.

Quantum Jump for Topology 1편. 고객 확보: Agent Web & Trust 2편. 업무 효율화: Team Topology & Message Bus 3편. 빠른 개선: Dynamic, Kinetic and Semantic 4편. 거버넌스: Rail, Checkpoint, Guardrail 5편. 측정: Hidden graph, Sensor, Observatory

참고

Eric Evans — Domain-Driven Design (2003)
Gregor Hohpe, Bobby Woolf — Enterprise Integration Patterns (2003)
Melvin Conway — "How Do Committees Invent?" (1968)
NIST SP 800-207, Zero Trust Architecture (2020)
Brynjolfsson, Li & Raymond — "Generative AI at Work", Quarterly Journal of Economics (May 2025)
Pace Layering — Stewart Brand
Debezium CDC — Change Data Capture
Camunda BPMN Engine
Celonis Process Mining
dbt Semantic Layer
W3C OWL — Web Ontology Language