책이 세상을 바꾼다

8.5 무엇을 열고 무엇을 고정할 것인가 — 뉴럴과 심볼릭의 설계 책임 배치

8.5.1 왜 역할 분담이 아니라 '책임 배치'가 중요한가

8.5.2 엔티티: 해석은 열되, 식별은 고정해야 한다

① 뉴럴은 대상을 해석(Interpretation)한다

② 심볼릭은 공식 타입과 식별자(Identity)를 고정한다

③ 핵심은 별칭(Alias)의 자유와 식별(Identity)의 고정 사이의 경계를 정하는 일이다

8.5.3 상태: 추정은 열되, 확정은 고정해야 한다

① 뉴럴은 현재 상태를 추정(Estimation)한다

② 심볼릭은 무엇이 공식 사실인지 확정(Finalization)한다

③ 핵심은 추정(Belief)과 확정(Committed State) 사이에 안전한 경계면을 두는 일이다

8.5.4 전이: 제안은 열되, 형식은 고정해야 한다

① 뉴럴은 다음 행동을 제안(Proposal)한다

② 심볼릭은 그 제안을 허용된 '전이 형식'으로 제한한다

③ 핵심은 생성의 자유를 남기되, 전이 집합의 경계를 고정하는 일이다

8.5.5 제약: 해석은 열되, 판정은 고정해야 한다

① 뉴럴은 정책의 맥락과 예외를 해석(Interpretation)한다

② 심볼릭은 최종 허용과 거부를 확정(Finalization)한다

③ 핵심은 무엇을 DSL의 규칙으로 내리고, 무엇을 예외 해석으로 남길 것인가를 정하는 일이다

8.5.6 프로덕션급 월드 모델은 혼합이 아니라 경계 설계다

8.6 월드 모델 캔버스 — 설계를 한 장의 세계로 펼쳐 보기

8.6.1 왜 캔버스가 필요한가

① 분해된 개념은 다시 통합되어야 한다

② 설계는 목록이 아니라 '관계망'이다

③ '구체화의 고통'을 거쳐 청사진을 만드는 작업대

8.6.2 캔버스는 정리표가 아니라 '실행 설계면'이다

① ESTC만 적는 표로는 부족하다

② 런타임 접합 항목까지 함께 올라와야 한다

③ 캔버스는 세 개의 레이어로 읽혀야 한다

8.6.3 월드 모델 캔버스 — 정의, 동역학, 운용의 3층 설계면

8.6.4 세 도메인으로 보는 월드 모델 캔버스

8.6.5 이제 캔버스를 채울 차례다

[Chapter Summary] 설계는 세계를 정의하고, 실행은 그 세계를 따라 닫힌다

[저자 핵심 메시지]

Chapter 9. 세계의 존재들 — Entity: 실행 단위를 선언하다

[Chapter Opening]

말뿐인 완료, 혹은 존재의 부재

파트 3의 첫 번째 말뚝: 존재의 선언

실행은 존재를 전제로 시작된다

이 장의 지형: 존재의 선언에서 집행의 앵커링까지

9.1 왜 세계는 존재부터 닫혀야 하는가

9.1.1 S·T·C는 모두 Entity에 종속된다

9.1.2 실행 실패의 진짜 원인은 존재의 부재다

9.2 엔티티란 무엇인가

9.2.1 명사·레코드·객체·리소스와의 4중 구분

① 명사(Noun) vs 엔티티: 명사는 '후보'일 뿐이다

② 레코드(Record) vs 엔티티: 레코드는 '흔적'일 뿐이다

③ 객체(Object) vs 엔티티: 객체는 '도구'일 뿐이다

④ 리소스(Resource) vs 엔티티: 리소스는 '통로'일 뿐이다

9.2.2 엔티티로 선언된 존재의 실행 특성 — TSAA 특성

9.2.3 엔터프라이즈에서 반복되는 세 가지 엔티티 유형

① 핵심 비즈니스 객체(Core Business Object): 세계의 골격

② 주체(Actor): 행위와 권한의 귀속점

③ 프로세스 인스턴스(Process Instance): 흐름의 실체화

9.2.4 존재의 경계는 어디서 그어지는가

9.2.5 이름이 아니라 동일성으로 식별하라

① 식별자의 두 축: 자연 키와 대리 키

② 외부 ID와 내부 기준 식별자(Canonical ID)의 매핑

③ NWM의 유사성과 SWM의 동일성: 식별의 원리적 분업

9.3 엔티티를 실행 단위로 만드는 요소들

9.3.1 속성 — 확정과 추정의 분리

9.3.2 관계 — 전이 판정에 영향을 주는가

9.3.3 타입·엔티티·인스턴스·객체 — 설계와 실행의 층위 구분

9.4 관측을 엔티티에 귀속시키기 — 해석(Resolution)과 앵커링(Anchoring)의 분업

9.4.1 NWM의 해석 — 지칭의 안개를 걷는다

9.4.2 SWM의 앵커링 — 후보를 실행의 지면에 고정한다

9.4.3 해석과 앵커링의 협업 — NSWM이 관측을 실행으로 바꾸는 방식

9.5 세 도메인으로 보는 엔티티 설계

9.5.1 도메인별 엔티티 관계 다이어그램

① 커머스 도메인

② 마케팅 도메인

③ HR 도메인

9.5.2 엔티티 설계 7가지 실패 패턴

9.6 워크샵 — 당신의 엔티티를 고정하라

Step 1. 진단 — 우리 시스템의 존재는 지금 닫혀 있는가

Step 2. 템플릿 — 내 도메인의 엔티티 맵 초안

Step 3. Before/After — 흔한 실패와 올바른 설계

Step 4. 체크리스트 — 엔티티 설계 완성도 자가 진단

이 워크샵이 끝난 후

[Chapter Summary] 존재가 정박될 때 실행은 실재가 된다

[저자 핵심 메시지]

Chapter 10. 세계의 좌표들 — State: 실행의 현재를 고정하다

[Chapter Opening]

말뿐인 진행, 혹은 좌표의 부재

에이전트 시대에 폭발하는 오래된 모호성

상태는 세계의 현재 좌표다

10.1 왜 세계는 상태로 닫혀야 하는가

10.1.1 상태는 실행의 중심 축이다

10.1.2 지능이 만든 함정: 자의적 좌표 보정

10.1.3 상태는 세계의 현재를 고정하는 장치다

10.2 상태(State)란 무엇인가

10.2.1 상태의 식별: 단계·플래그·속성·서술과의 구분

① 단계(stage)는 '순서'일 뿐이다

② 불리언 플래그(boolean flag)는 '단편'일 뿐이다

③ 속성값(attribute value)은 '재료'일 뿐이다

④ 서술(description)은 '인상'일 뿐이다

⑤ 진짜 상태는 누구인가?

10.2.2 상태의 본질: 행동 가능성의 좌표

① 상태는 키(Key)이고, 데이터와 다르다

② 상태의 유무가 실행 세계를 가른다

10.2.3 엔터프라이즈에서 반복되는 세 가지 상태 유형

① 생애주기 상태(lifecycle state) — 존재의 궤적

② 절차 상태(process state) — 프로세스 내 현재 위치

③ 운영/집행 상태(operational state) — 현재 집행 조건

10.2.4 상태의 경계는 어디서 그어지는가

10.3 상태를 실행 좌표로 만드는 요소들

10.3.1 유효 상태 집합

① 상태 설계의 3대 원칙

② 특수 상태의 역할: 시작·종료·예외

10.3.2 확정 상태와 추정 상태 — Fact와 Belief의 분리

10.3.3 관계 상태 — 단일 엔티티 밖에서 결정되는 좌표

10.3.4 타입·상태 정의·현재 상태값·표현 객체 — 층위 구분

① 상태 타입(State Type): 설계 아티팩트로서의 어휘

② 상태 정의(State Definition): 허용성과 전이의 규칙

③ 현재 상태값(Current State Value): SSOT에 기록된 실제 좌표

④ 런타임 표현 객체(Runtime State Object): 메모리 위의 실행 컨텍스트

10.4 관측을 상태에 귀속시키기

10.4.1 관측은 어떻게 상태 후보를 생성하는가

① 시스템 이벤트: 규격화된 강력한 신호

② API 응답: 능동적 요청에 따른 근거

③ 에이전트 NLU 결과: 확률적 해석과 단초

④ UI 액션: 명시적 의도와 집행의 분리

10.4.2 상태 커밋 — 언제 세계의 공식 좌표가 바뀌는가

① 유효성(Validity) 검증: 존재의 확인

② 전이 적법성(Legality) 검증: 이동의 정당성

③ SSOT 기록(Commit): 사실의 공인

10.4.3 NWM의 추정과 SWM의 확정 — 상태 갱신의 분업

10.4.4 상태 불일치와 드리프트 — 세계와 모델이 엇갈릴 때

① 외부 시스템 불일치(External Inconsistency)

② 에이전트 추론 오류(Inference Error)

③ 동시성 충돌(Concurrency Conflict)

10.5 세 도메인으로 보는 상태 설계

10.5.1 커머스 도메인 — Order / Payment / Shipment의 상태 공간

10.5.2 마케팅 도메인 — Campaign / AdSet / BudgetCell의 상태 공간

10.5.3 HR 도메인 — Candidate / Interview / Offer의 상태 공간

10.5.4 상태 설계의 7가지 실패 패턴

① "모든 불확실성을 PROCESSING으로 은폐하기" — 완전성(Completeness) 위반

② "결제된 세계와 취소된 세계의 동거" — 상호배타성(Mutual Exclusivity) 위반

③ "설계도에만 존재하는 고립된 섬" — 도달 가능성(Reachability) 위반

④ "닫힌 문을 다시 두드리는 오류" — 종료 상태(Terminal State) 미명시

⑤ "바벨탑이 된 상태 어휘" — SSOT의 개념적 분열

10.6 워크샵 — 당신의 상태 공간을 고정하라

Step 1. 진단 — 우리 시스템은 현재 좌표를 말할 수 있는가

Step 2. 템플릿 — 엔티티별 상태 맵(State Map) 초안

Step 3. Before/After — 흔한 상태 설계 실수 교정

Step 4. 체크리스트 — 상태 설계 완성도 자가 진단

워크샵을 마치며

[Chapter Summary] 상태는 설명이 아니라 실행의 좌표다

[저자 핵심 메시지]

Chapter 11. 세계의 변화들 — Transition: 실행의 인과를 새기다

[Chapter Opening]

좌표는 선명하나 세계는 움직이지 않는다

전이 설계의 부재가 만드는 두 가지 실패 양상

전이는 인과(Causality)의 설계다

이 장의 구성

11.1 왜 전이를 설계해야 하는가

11.1.1 상태-전이 쌍: 고정과 변화는 함께 설계된다

11.1.2 전이 없는 실행의 두 가지 실패 양상

11.1.3 상태의 의미는 허용된 변화의 구조 안에서 완성된다

11.2 전이란 무엇인가

11.2.1 전이의 구성 요소: 다섯 가지 축

① 출발 상태(Source State)

② 도착 상태(Target State)

③ 트리거(Trigger)

④ 가드(Guard)

⑤ 커밋 이후 효과(Post-Commit Effect)

11.2.2 전이는 인과(Causality)의 설계다

11.2.3 이벤트·트리거·전이·액션의 구분

① 이벤트(Event): 세계에서 발생한 사실의 기록

② 트리거(Trigger): 사건을 전이 요청으로 번역하는 장치

③ 전이(Transition): 허용된 변화의 공식 경로

④ 액션(Action): 세계에 가하는 실제적 집행

⑤ 전이 명세(Contract) — 허용된 변화를 한 줄의 계약으로 고정하기

11.2.4 NWM과 SWM의 역할 분담 — 전이를 추론하고, 판정하고, 커밋하는 두 레이어

① NWM은 전이 후보를 추론한다

② SWM은 허용 여부를 판정한다

③ 커밋은 SWM만 수행한다

11.3 트리거: 무엇이 전이를 촉발하는가

11.3.1 이벤트 기반 트리거: 외부 세계가 밀어넣는 신호

11.3.2 시간 기반 트리거: 세계가 스스로 움직이는 법칙

11.3.3 조건 기반 트리거: 복합 조건이 충족될 때

11.4 가드: 전이의 문턱을 설계하다

11.4.1 가드의 본질: 허용과 거부의 논리

① 선행 상태 조건(Pre-state Condition)

② 비즈니스 규칙 조건(Business Rule Condition)

③ 멱등성 조건(Idempotency Condition)

11.4.2 가드의 구현 패턴: 단순 조건에서 외부 검증까지

① 로컬 조건 가드(Local Condition Guard)

② 집계 조건 가드(Aggregate Condition Guard)

③ 외부 검증 가드(External Validation Guard)

④ 복합 가드(Composite Guard)

11.4.3 Human-in-the-Loop 전이: 사람이 가드가 되는 경우

11.5 전이는 어떻게 안전하게 커밋되는가

11.5.1 다중 에이전트 환경의 전이 충돌

11.5.2 전이의 원자성: 부분 성공은 허용되지 않는다

11.5.3 전이 이력과 감사 가능성: 인과의 장부를 기록하다

11.6 세 도메인으로 보는 전이 설계

11.6.1 커머스 도메인 — 전이 연쇄와 반품 분기

11.6.2 마케팅 도메인 — 자원 상태가 집행을 멈추는 전이

11.6.3 HR 도메인 — 관계 조건 전이와 Human-in-the-Loop

11.7 전이 설계의 실패 패턴

① "이벤트가 오면 바로 바뀐다" — 가드 없는 자동 전이

② "상태만 바꾸면 끝이다" — 전이 없는 상태 덮어쓰기

③ "한 함수가 다 한다" — 연쇄 전이의 단일 함수 통합

④ "시간이 지났는데 아무것도 안 바뀐다" — 시간 기반 트리거 누락

⑤ "왜 이 상태가 됐는지 모른다" — 전이 이력 미기록

11.8 워크샵 — 당신의 세계에 변화의 문법을 새겨라

Step 1. 진단 — 우리 시스템은 변화의 경로를 말할 수 있는가

Step 2. 템플릿 — 엔티티별 전이 맵(Transition Map) 초안

Step 3. Before/After — 흔한 전이 설계 실수 교정

Step 4. 체크리스트 — 전이 설계 완성도 자가 진단

워크샵을 마치며

[Chapter Summary] 전이는 허용된 인과의 설계다

[저자 핵심 메시지]

Chapter 12. 세계의 경계들 — Constraint: 전이가 넘을 수 없는 한계를 새기다

[Chapter Opening]

전이는 옳았다. 그러나 세계는 잘못되었다

Part 3의 실패 계보 — 경계 붕괴

제약은 세계의 불변 조건이다

이 장의 구성

12.1 왜 세계는 제약을 가져야 하는가

12.1.1 Guard와 Constraint의 경계 — 지역 판정과 전역 규칙

12.1.2 제약 없는 실행의 실패 양상 — 경계 붕괴(Boundary Collapse)

12.1.3 제약은 세계의 불변 조건이다

12.2 제약이란 무엇인가 — 네 가지 위치

12.2.1 불변 제약(Invariant Constraint) — 어떤 전이도 침범할 수 없는 상수

12.2.2 상태 기반 제약(State-based Constraint) — 특정 상태에서 성립하는 허용 조건

12.2.3 전이 기반 제약(Transition-based Constraint) — 변화의 순간에만 검사되는 조건

12.2.4 관계 제약(Relational Constraint) — 엔티티 간 정합성 조건

① 합계 제약(Aggregate Constraint)

② 참조 제약(Reference Constraint)

③ 배타 제약(Exclusivity Constraint)

12.3 제약은 언제 검사되는가

12.3.1 사전 검사(Pre-check) — 전이 요청 전에

12.3.2 커밋 시 검사(Commit-time Check) — StateCommitService 내에서

12.3.3 사후 검사(Post-check) — 커밋 이후 정합성 검증

12.3.4 삼중 가드 계층(Triple Guard Layer) — 다층 제약 집행의 구조

12.4 제약의 설계 원칙

12.4.1 제약의 선언 방식 — 판정 가능한 형식으로

12.4.2 제약 우선순위와 충돌

12.4.3 제약의 설계와 집행 원칙 — 처리 경로, 실무 레이어, 강제력

① 제약 위반의 처리 — 차단·보상·에스컬레이션

② 제약의 실무 레이어 — 데이터·절차·권한

③ 제약의 출처와 강제력 — 정책·불변식·규제

12.4.4 뉴럴 제약과 세계의 법칙은 다르다

① 범용 LLM의 제약은 잠재적이고, 기업의 제약은 명시적이어야 한다

② LLM 안에도 Rule과 Constraint가 있지 않은가

12.5 세 도메인으로 보는 제약 설계

12.5.1 커머스 도메인 — 금액·수량·순서의 불변 제약

① 금액 불변 제약

② 수량·순서 상태 기반 제약

③ 취소-환불 전이 기반 제약

④ 부분 반품의 관계 제약

12.5.2 마케팅 도메인 — 예산·기간·중복 집행의 제약

① 예산 합계 제약

② 집행 기간 상태 기반 제약

③ 중복 집행 배타 제약

12.5.3 HR 도메인 — 헤드카운트·처우·법규 준수의 제약

① 헤드카운트 관계 제약

② 처우 불변 제약

③ 법규 준수 전이 기반 제약

12.5.4 제약 설계의 7가지 실패 패턴

① "당연한 건데 왜 선언해야 하나" — 불변 제약 미선언

② "이 가드면 충분하다" — 전역 규칙의 가드 분산

③ "일단 커밋하고 나중에 보자" — 사후 검사 누락

12.6 워크샵 — 당신의 세계에 경계를 새겨라

Step 1. 진단 — 우리 시스템은 세계의 질서를 말할 수 있는가

Step 2. 템플릿 — 엔티티별 제약 맵(Constraint Map) 초안

Step 3. Before/After — 흔한 제약 설계 실수 교정

Step 4. 체크리스트 — 제약 설계 완성도 자가 진단

워크샵을 마치며

[Chapter Summary] 제약은 세계의 불변 조건이다

[저자 핵심 메시지]

[Part Intro]

설계된 세계는 저절로 유지되지 않는다

모든 운영 중인 세계는 엔트로피를 향해 기운다

NWM은 표류하고, SWM은 낡아간다

이제 중요한 것은 완성도가 아니라 유지 가능성이다

세계를 읽고, 개정하고, 조직으로 완성하다

구축의 마침표는 운영이라는 긴 문장의 시작이다

Chapter 13. 세계 붕괴의 징후와 진단 — 드리프트, 판독, 평가, 디버깅

[Chapter Opening]

세계는 설계된 이후에도 계속 움직인다

NWM은 오독하고, SWM은 뒤처진다

드리프트는 보이지 않는다 — 그래서 더 위험하다

이 장이 묻는 것

보이지 않는 세계는 운영될 수 없다

13.1 왜 운영 중인 세계는 다시 흐려지는가

13.1.1 완성된 설계와 변하는 현실의 간극

① 정적인 스냅샷, 동적인 현실

② 세계의 해상도 저하와 일반성 위기

13.1.2 NWM의 해석 드리프트와 SWM의 구조 지연

① 입력 — 해석 간극(Input — Interpretation Gap)

② 규칙 — 집행 간극(Rule — Execution Gap)

③ 신념 — 상태 간극(Belief — State Gap)

④ 정책 — 현실 간극(Policy — Reality Gap)

13.1.3 운영의 핵심은 오류 처리보다 정렬 상태의 판독이다

13.2 세계를 판독하는 핵심 도구들

13.2.1 상태 차이(State Diff) — 무엇이 달라졌는가

13.2.2 전이 추적(Transition Trace) — 왜 그렇게 바뀌었는가

13.2.3 감사 추적(Audit Trail) — 누가 무엇을 어떻게 바꾸었는가

13.2.4 궤적(Trajectory) — 반복되는 어긋남의 궤적은 무엇인가

13.3 운영을 위한 시뮬레이션과 디버깅

13.3.1 드라이 런(Dry Run) — 실행 전에 어긋남을 보기

13.3.2 리플레이(Replay) — 실패를 다시 읽기

13.3.3 샌드박스(Sandbox) — 수정 전의 세계를 격리해 시험하기

13.3.4 디버깅 콘솔(Debugging Console) — 로그가 아니라 세계를 디버깅하기

① 세계 내부를 직접 탐색하는 인터페이스

② 위험을 조기에 드러내는 관제면(Control Surface)

13.4 무엇을 평가해야 하는가

13.4.1 NWM 품질 — 세계를 얼마나 정확하게 읽고 있는가

① 해석 정확도(Interpretation Accuracy)

② 분류 일관성(Classification Consistency)

③ 추정 정합성(Estimation Coherence)

13.4.2 SWM 품질 — 세계의 규칙이 아직도 현실을 대변하는가

① 전이 유효성(Transition Validity)

② 제약 집행력(Constraint Enforcement Rate)

③ 정책 일관성(Policy Consistency)

13.4.3 공동 지표(Joint Metrics) — 두 레이어는 정말 하나의 세계로 작동하고 있는가

① 제안 수용률(Proposal Acceptance Rate)

② 커밋 완결률(Commit Completion Rate)

③ 루프 지연(Loop Latency)

④ 추정-확정 수렴률(Belief-to-State Convergence Rate)

13.4.4 실패 분류 체계(Failure Taxonomy) — 실패의 계보를 운영의 진단 체계로 되돌리기

① 환각(Hallucination) — 세계를 잘못 읽는 실패

② 탈주(Runaway) — 허용되지 않은 경로로 움직이는 실패

③ 붕괴(Collapse) — 세계의 경계 자체가 무너지는 실패

[Chapter Summary] 세계를 읽는 눈이 세계를 지킨다

[저자 핵심 메시지]

Chapter 14. 세계의 개정 — 월드 버저닝: 세계는 어떻게 자라는가

[Chapter Opening]

정확했던 세계가 낡기 시작하는 순간

세계가 거짓말을 시작할 때

개정은 패치가 아니라 구조적 갱신이다

세계는 네 축에서 함께 자란다

SWM과 NWM은 함께 다시 정렬되어야 한다

누가 세계를 바꿀 것인가

이 장이 다루는 것

진짜 운영은 개정에서 시작된다

14.1 왜 세계는 개정되어야 하는가

14.1.1 세계 허위화: 세계가 더 이상 참이 아니게 되는 순간

14.1.2 설계의 완결성과 현실의 개방성

14.1.3 월드 모델은 문서가 아니라 운영 자산이다

14.1.4 세계 부채: 미루면 어떤 비용이 쌓이는가

14.2 세계는 어디서부터 낡는가

14.2.1 세계 노화(老化)의 네 층위

① 비즈니스 변화

② 규제 변화

③ 기술 변화

④ 현장 학습

14.2.2 드리프트는 증상이고, 개정은 체제의 응답이다

14.2.3 패치는 세계를 고치지 못한다

14.3 다층적 세계 개정 — 질서를 복구하는 네 축의 원리

14.3.1 Entity — 존재의 경계를 다시 획정(劃定)하다

14.3.2 State — 좌표계를 다시 정렬하다

14.3.3 Transition — 허용된 경로를 다시 설계하다

14.3.4 Constraint — 경계를 다시 선언하다

14.4 세계를 안전하게 바꾸는 실험 구조

14.4.1 프로덕션 이전, 시뮬레이션

① 세계의 팽창과 직관의 붕괴

② 닥터 스트레인지의 시뮬레이션

14.4.2 샌드박스 — 개정안을 운영 이전에 검증하는 문턱

14.4.3 카나리 롤아웃(Canary Rollout) — 제한된 현실에서 먼저 검증하기

14.4.4 전체 전환과 하위 호환성(Backward Compatibility)

14.5 세계 버전 관리: 엔트로피를 이기는 운영

14.5.1 SWM 스키마 진화 — 설계된 세계의 새 버전을 개정하다

14.5.2 NWM 재정렬 — 학습된 세계를 새 버전에 맞추다

① NWM 재정렬의 세 축: 그라운딩, 다이내믹스, 제약 인식

② 비대칭성의 미학: 자기 교정이 가능한 재정렬 구조

14.5.3 한쪽만 바꾸면 왜 다시 어긋나는가

14.5.4 세계 변경은 코드 변경보다 무겁다

14.6 책임 배분표(Accountability Matrix) — 누가 세계를 바꾸는가

14.6.1 도메인 오너 — 누가 의미를 책임지는가

14.6.2 정책 오너 — 누가 정책과 예외를 책임지는가

14.6.3 월드 모델 엔지니어 — 누가 실행 품질과 운영 안정성을 책임지는가

14.6.4 월드 모델 거버넌스 위원회 — 누가 변경 승인과 리스크를 책임지는가

[Chapter Summary] 세계를 바꾸는 질서가 세계를 살린다

[저자 핵심 메시지]

Chapter 15. 세계를 가진 조직 — 모델에서 에이전트로, 에이전트에서 세계로

[Chapter Opening]

조직 AI는 개인용 AI와 전혀 다른 문제다

기업은 더 절실하지만, 더 느릴 수밖에 없다

1팀 1에이전트팀(One Team, One MAS)

개인 에이전트의 확산이 곧 조직 전환은 아니다

같은 세계 위에서 작동하는 실행 네트워크

그래서 조직은 점점 자신의 세계를 명시적으로 갖게 된다

15.1 에이전트는 기능이 아니라 구조를 바꾼다

15.1.1 자동화의 단위가 태스크에서 세계로 이동한다

15.1.2 에이전트는 앱 위에서 일하지 않는다, 세계 위에서 일한다

15.1.3 "무엇을 자동화할까"에서 "어떤 실행 세계를 설계할까"로

① 틀린 질문이 부르는 두 가지 실패

② 에이전트 시대의 올바른 질문

15.2 Agent OS, 세계를 집행하는 운영체제

15.2.1 왜 에이전트에게는 운영체제적 기반이 필요한가

15.2.2 Agent OS는 무엇을 제공하는가

① 공유 기준면, 실행 중재, 거버넌스의 세 층

② Agent OS의 본질은 앱 런처가 아니라 세계 집행기다

15.2.3 Agent OS는 모델 위가 아니라 조직 위에 놓인다

① 모델은 교체 가능한 층위이고, Agent OS는 영속적인 층위다

② Agent OS는 실행 인프라인 동시에 보안 경계면이다

③ 월드 모델, 에이전트 오케스트레이터, Agent OS는 서로 다른 층위다

15.3 세계 중심 조직(World-Centered Enterprise)

15.3.1 문서 중심 조직에서 세계 중심 조직으로

15.3.2 사람은 암묵적으로 이해했고, 에이전트는 명시적으로 요구한다

15.3.3 기업의 SSOT는 데이터 저장소를 넘어 세계의 공식 기록면이 된다

15.3.4 실행 가능한 조직의 구조적 조건

① 우리 조직의 실행 단위는 명확한가

② 우리 조직은 현재 좌표를 말할 수 있는가

③ 허용된 변화의 경로가 공식 구조로 존재하는가

④ 넘어서는 안 되는 경계가 실제로 집행되고 있는가

⑤ 기록과 복구는 설계되어 있는가

15.4 책을 닫으며

15.4.1 더 좋은 지능이 아니라 더 좋은 세계

15.4.2 엔터프라이즈 월드 모델 — 단계별 로드맵

① 시맨틱 레이어로 의미를 먼저 고정하라

② 의사결정을 위한 가벼운 시뮬레이션을 구축하라

③ 기술 조각을 하나의 운영 세계로 통합하라

15.4.3 AI의 미래는 분화와 협업으로 간다

[Chapter Summary] 더 좋은 세계가 더 좋은 조직을 만든다

[저자 핵심 메시지]

Appendix C. 실행 가능한 세계로 들어가기 — 월드 모델 오픈소스 실습 자료와 레퍼런스 구현체

C.1 World Model Canvas / Reference Toolkit

C.2 ESTC Runtime Engine

C.3 World Model Anti-Patterns

C.4 World Debt Detector

C.5 WorldLoops for OpenClaw

C.6 다섯 저장소의 관계

Epilogue. 인간이 설계하는, AI '세계'

E.1 LLM의 막다른 길, 그리고 세계의 귀환

E.2 스케일링 이후, 다시 세계로

E.3 워크플로우 세계를 시뮬레이션하라

E.4 에이전트 중심에서, 세계 중심으로

E.5 세계를 가진 조직: 위임의 시대로

E.6 일의 과거에서, 일의 미래로

E.7 프롬프트와 하네스를 넘어, 세계로

E.8 인간이 해내야 할 마지막 과업

References. 참고문헌

Chapter 2. 실행 좌표계의 부재 — LLM이 고정할 수 없는 상태·시간·공간·주체

[Chapter Opening]

좌표 없는 지능: '원점'을 고정하지 못하는 LLM

해피 패스(Happy Path)의 환상과 구조적 무지

컨텍스트의 착각: 기억은 늘어나도 실행은 증명되지 않는다

실행 좌표의 해부: 상태·시간·공간·주체

2.1 상태 좌표의 부재 — 컨텍스트는 기억일 뿐, 상태가 아니다

2.1.1 컨텍스트 윈도우의 착각

2.1.2 "어제 주문한 거 취소해줘"의 함정

① 문제 1: 상대시간의 함정 — "어제"는 계산돼야 한다

② 문제 2: 컨텍스트 단일성의 착각 — 레코드는 복수다

③ 문제 3: 상태가 허용하지 않으면 취소는 없다 — 상태 전이의 임계값

④ 컨텍스트는 후보를 만들고, 상태는 결정을 만든다

2.1.3 컨텍스트와 상태의 근본적 차이

① 사례: 세션이 끊긴 후의 재개 — 기억은 사라져도 실재는 남는다

2.2 시간 좌표의 부재 — "지금"이 없는 지능

2.2.1 절대 시간으로의 컴파일 실패

① 사례 1: "오늘" 이벤트 조회 — 지능은 날짜를 '추론'하고, 시스템은 날짜를 '확정'한다

② 사례 2: 시간 기반 권한 검증 — 권한은 고정된 속성이 아니라 '유동적 상태'다

③ 사례 3: 상대적 시간의 모호성 — 자정의 경계에서 흔들리는 지능

④ 사례 4: 시간 추적의 누적 오류 — 연산이 아닌 서사의 한계

2.2.2 타임스탬프의 필수성

2.2.3 시간 좌표가 없으면 감사 추적도 없다

2.3 공간·주체 좌표의 부재 — "어디"와 "누구"가 부유하는 실행

2.3.1 공간 좌표의 부재: 경로 탐색의 붕괴

① LLM의 텍스트 기반 공간 이해: 기하학적 실체의 부재

② 시스템의 좌표 기반 이해: 공간의 연산

③ 텍스트 서술 vs 좌표 연산: 공간 지능의 간극

2.3.2 주체 좌표의 부재: 추론된 '나'와 인증된 '나'

① 사례 1: "내 계좌로 환불해줘" — 주체 추론과 정책적 확정

② 사례 2: 동시 접속의 악몽 — 세션의 물리적 격리

③ 사례 3: 권한 위임의 문제 — '누가'를 증명하는 로그의 무게

2.3.3 공간 붕괴의 결과: 3D 비즈니스 공간 탐색 실패

① 지능의 1차원 컨텍스트 vs 비즈니스의 3차원 공간

② 공간 좌표 부재로 인한 4가지 실패 패턴

2.4 지능에서 실행으로: 좌표계의 탄생

2.4.1 실행의 환각: '했습니다'와 '수행됨' 사이의 심연

2.4.2 좌표의 확정: 실행을 위한 4대 원점

2.4.3 실행 판정의 최소식: 지능을 통제하는 설계의 지도

2.4.4 좌표가 살아있는 세계를 향하여

[Chapter Summary] 지능은 좌표를 추측하고, 세계는 좌표를 봉인한다

[저자 핵심 메시지]

Chapter 3. 지능이 거(居)할 세계 — 심볼릭과 뉴럴, 두 전통의 계보

[Chapter Opening]

지능의 좌표가 서는 곳

비즈니스에도 물리 법칙이 필요하다

환경과의 접지(Grounding): 실행 가능성을 판가름하는 척도

비즈니스 월드 모델: 논리적 물리 엔진(Logical Physics Engine)

오래된 미래: 월드 모델의 지적 유산

다중 에이전트는 '공통의 땅'을 요구한다

이 장의 로드맵

3.1 "월드 모델"이라는 단어의 출처 — 용어의 정직한 계보

3.1.1 개념의 기원: "내적 모델"이라는 오래된 직관

① 내적 모델(Internal Model): 예측과 제어의 언어

② 멘탈 모델(Mental Model): 사고와 판단의 언어

③ 월드 모델(World Model): 구조와 좌표의 언어

3.1.2 용어의 재등장: "행동하는 시스템"의 언어로 들어오다

3.1.3 대중화: LeCun 이후, '월드 모델'은 밈이 되었다

3.2 심볼릭 전통 — 설계된 세계 표현(The Logic of Structure)

3.2.1 심볼릭 월드 모델의 4대 기둥: 논리와 구조의 뿌리

① 상황 미적분(Situation Calculus): 상태와 행동의 형식 논리

② 구간 대수(Interval Algebra) — 시간을 구조화하는 논리

③ POMDP: 불완전한 세계에서의 실행

④ 계승 공리(SSA): 지속성 문제와 제약의 뼈대

3.2.2 심볼릭 월드 모델(SWM)의 최소 구성요소 — 정의된 세계를 '현재형'으로 세우는 기술

① 정의 계층 — 온톨로지와 월드 DSL: 세계의 어휘와 문법을 고정한다

② 현재 계층 — 상태와 SSOT: '가능한 세계'와 '현재 세계'를 분리한다

③ 현실 계층 — 전이와 확정(커밋): '가능성'을 '사건'으로 닫는다

3.2.3 가드(Guard): 실행을 닫는 세 겹의 판정(상태·주체·정책)

① 왜 가드가 필요한가: '추론된 나'와 '인증된 주체'의 분리

② 삼중 가드(Triple Guard): 실행의 정당성을 닫는 세 겹의 필터

③ "누가"는 왜 핵심인가: 추론을 사건으로 바꾸는 책임 좌표

④ 산업에 뿌리내린 월드 모델의 유전자: 가드와 명세

3.2.4 LLM·에이전트가 소환한 '심볼릭 월드 모델' 연구 흐름

① Text2World: "텍스트 → PDDL 세계 명세"를 실행으로 채점하다

② Agent2World: "월드 DSL"을 다중 에이전트로 생성·교정하다

③ DR.WELL: "심볼릭 계획 + 공유 WM"로 에이전트 동기화를 만든다

④ SWM 연구 흐름 요약: 실행의 안전망이자 지능의 훈련장

3.3 뉴럴 전통 — 학습된 세계 표현(The Logic of Learning)

3.3.1 LLM과 NWM, 그리고 월드 모델의 일반화

① LLM을 넘어 NWM으로: 뉴럴 월드 모델의 구성요소

② 물리 세계에서 논리 세계로의 확장

3.3.2 세계를 압축하는 법: 잠재 공간과 전이 예측

① 눈-기억-조종간: 압축과 시뮬레이션의 구조

② 꿈속의 학습(Dream Training)과 설명 불가능성

3.3.3 에너지로 세계를 판단하는 법: JEPA

① 생성하지 말고 예측하라: JEPA의 철학

② 에너지 함수: 정합성을 측정하는 저울

③ 실무 적용: 리스크 스코어링 레이어

3.3.4 꿈속에서 학습하는 법: DreamerV3

① 월드 모델, 배경에서 무대로

② RSSM: POMDP의 뉴럴 식 이식

③ 꿈속 학습(Dream Training)의 가치와 한계

3.3.5 몸을 가진 지능의 세계 표현: Embodied AI

① 센서모터 루프: 설명보다 행동이 먼저다

② 좌표가 없는 지능은 허용되지 않는다

③ ESTC: 비즈니스와 로봇의 공통 분모

3.3.6 뉴럴 전통의 공통 한계

① 감사 추적(Audit Trail) 불가

② 규칙 준수(Compliance) 보장 불가

③ 책임 귀속(Accountability) 불가

④ 공통 한계: '닫힘(closure)' 계층의 부재

[Chapter Summary] 지능은 꿈을 꾸고, 세계는 현실을 집행한다

[저자 핵심 메시지]

Chapter 4. 두 세계의 협업 — 뉴로심볼릭 런타임 설계

[Chapter Opening]

지능의 해부도를 덮으며: 분리된 두 스택의 초상

용어를 먼저 고정하자: 이 책이 말하는 '뉴로심볼릭'

질문은 단순하나, 대답은 결정적이다

원칙을 넘어 '설계'의 영역으로

이 장의 설계 지도

실행의 아키텍처를 향하여

4.1 두 세계의 해부와 협업 원칙

4.1.1 구성요소 대응: 6×6 맞물림 구조

① LLM ↔ 온톨로지·월드 DSL: 유연한 언어를 엄격한 타입으로

② 관측 ↔ 상태: 흐르는 관측을 멈춰있는 상태로

③ 그라운딩 ↔ SSOT·상태 저장소: 확률적 추측을 실재에 정박하기

④ 상태 추정 ↔ 제약: 신념의 자유와 제약의 충돌

⑤ 다이내믹스 ↔ 전이: 상상의 전개를 허용된 경로로

⑥ 플래너 ↔ 실행 및 커밋: 제안의 기획과 사건의 종결

4.1.2 협업의 4대 원칙

① 원칙 1: NWM은 후보를 만든다(Proposal)

② 원칙 2: SWM은 가능한 후보만 남긴다(Adjudication)

③ 원칙 3: SWM만 사건을 확정한다(Commit)

④ 원칙 4: NWM은 결과를 학습·갱신한다(Update)

4.2 세 월드 모델 비교: 해석과 집행의 분업 구조

4.2.1 모델별 세계 표현과 최종 판정 위치

4.2.2 ESTC 질문에 대한 응답 방식 비교

4.2.3 같은 시나리오, 다른 처리 방식

① 심볼릭 처리: 상태기계에 의한 즉각적 판정

② 뉴럴 처리: 모델 내부에서 닫히는 블랙박스 결정

③ 뉴로심볼릭 처리: 해석과 집행의 계층적 협업

4.3 협업 프로토콜 설계

4.3.1 뉴로심볼릭 런타임 루프

① 해석의 시선에서 집행의 발걸음까지: 7단계 심층 해부

② 순환하는 지능, 고정된 권한: 7단계 루프의 총괄

4.3.2 NWM → SWM: 전이 후보 계약

① 기존 4개 필드 구조의 한계와 프로덕션의 위기

② 완전한 계약 스키마: 8개 필드

③ 전이 후보 계약의 구현: 타입 정의와 실례

④ 계약의 의미: 후보를 보내는 것이 아니라, 해석의 책임을 함께 보낸다

4.3.3 SWM → NWM: 판정과 결과 계약

① 기존 5개 필드의 한계와 '침묵하는 피드백'

② 완전한 계약 스키마: 8개 필드

③ 판정과 결과(Verdict & Outcome) 타입 정의: 개념에서 규격으로

④ 계약의 의미: 판정 결과를 보내는 것이 아니라, 세계의 최신 사실을 돌려준다

4.4 실패를 설계한다

4.4.1 왜 실패 설계가 뉴로심볼릭의 핵심인가

4.4.2 시나리오 A: Guard 실패 → Planner 재계획

① 발생 조건과 인지적 불일치의 본질

② 적응적 재계획(Adaptive Replanning) 루프의 설계 원칙

③ Guard 실패 핸들러 구현

4.4.3 시나리오 B: Execution 실패 → Saga 보상

① 발생 조건과 문제의 본질

② 전략적 피드백: 일시적 장애와 영구적 장애의 구분

③ Saga 보상 트랜잭션 구현

④ 자동화의 경계: 보상의 실패(Failure of Compensation)

4.4.4 시나리오 C: Commit 실패 → 멱등 처리

① 발생 조건과 문제의 본질

② 방어 전략: 멱등성(Idempotency)의 강제

③ 멱등 커밋 핸들러 구현

4.4.5 소결: 실패는 설계의 '일급 시민'이다

4.5 왜 지금인가, 그리고 무엇이 남는가

4.5.1 LLM이 완성한 병목 해소, 그리고 여전히 남는 설계 과제

① 지식 공학의 병목: 수십 년간 막혀 있던 통로

② LLM이 뚫어낸 것: 번역 비용의 급감

③ 여전히 남는 과제: 범용 해석기와 도메인 세계의 결합

4.5.2 산학 최전선의 공통 결론: 융합의 필연적 재발견

① 오픈 월드(Open World) 적응력의 확보

② VisualPredicator — 로봇 계획의 효율과 해석 가능성

③ NeuroSymLand — UAV 착륙 안전의 엄밀성

④ NeSyS — 인터랙티브 월드 모델의 규칙 준수와 효율

4.5.3 실행 가능한 좌표계로서의 뉴로심볼릭

① 마케팅 월드 모델 사례: 작은 세계에서 시작하다

② 4장을 닫으며

③ 월드 모델 리니지: ESTC 메타프레임 위의 세 전통

[Chapter Summary] 해석의 세계와 집행의 세계가 도킹하다

[저자 핵심 메시지]

[Part Intro]

새 지능이 요구하는 질서

개념에서 현실로

정말 현실도 그렇게 움직여왔는가

실패의 비용이 큰 세계들의 공통된 선택

이름보다 먼저 존재했던 구조

이제 검증된 현장으로 들어간다

Chapter 5. 피지컬 AI, 위험한 세계의 첫 번째 증명 — 실패를 감당할 수 없는 시스템의 공통 구조

[Chapter Opening]

틀려도 되는 세계와 틀리면 안 되는 세계

왜 지능이 높아질수록 더 강한 질서가 필요한가

언어는 흐르고, 실행은 끊어진다

같은 압력, 다른 표면

5.1 실패의 비용이 달라지는 순간

5.1.1 실패는 어떻게 남는가

① 실패는 어떻게 기록되는가

② 왜 어떤 실패는 데이터가 아니라 사고가 되는가

③ 실패의 두 얼굴: 예측은 학습되고, 집행은 감사된다

5.1.2 공통 세계(Shared World)의 필연

① 왜 다중 에이전트는 각자의 세계로 흘러가는가

② 공통 세계는 왜 실행 계약의 기반이 되는가

5.1.3 사후 적응과 런타임 통제의 한계

① 적응으로 버티려 했던 단계 — 프로세스 피드백

② 통제로 막으려 했던 단계 — 런타임 거버넌스

③ 과도기적 해법이 남긴 결론

5.2 피지컬 AI — 몸을 가진 지능은 세계 밖에서 살 수 없다

5.2.1 몸을 입는 순간 지능은 위계(Hierarchy)를 요구한다

① 물리 세계의 생존 조건: 분리하라

② 상위의 헌법, 하위의 집행

③ 불가능한 붕괴를 미리 제거하다

5.2.2 행동이 없어도 세계는 경계를 만든다

① 정답지가 사라진 세계

② 잠재 행동(Latent Action): 변화의 흔적을 쫓다

③ 신체(Embodiment)를 넘어선 보편 문법

④ 종이접기도 세계의 경계 안에서만 계획된다

5.2.3 계획은 의미의 공간에서만 가능하다 — 추상화(Abstraction)의 힘

① 왜 픽셀 위의 계획은 실패했는가

② 계획 가능한 세계를 만든다는 것 — 추상 좌표계

③ JEPA가 보여준 것 — 계획은 픽셀 예측이 아니라 관계의 일관성 위에 선다

④ 객체, 사건, 목표를 함께 붙드는 세계

⑤ 몸이 사라져도, 계획은 남는다

5.2.4 피지컬 AI가 남긴 세 가지 유산

① 생존을 위한 최소 설계: 위계, 경계, 그리고 추상화

② 확장된 질서: 물리적 충돌에서 의미적 충돌로

[Chapter Summary] 위험한 세계는 먼저 세계를 고정한다

[저자 핵심 메시지]

Chapter 6. 비물리(Non-Physical) AI — 몸이 사라진 세계에서, 왜 월드 모델은 더 중요해졌는가

[Chapter Opening]

몸 없는(Bodyless) 실행은 가벼워지지는 않는다

비물리 세계는 왜 더 위험한가

텍스트는 고칠 수 있어도 상태는 고칠 수 없다

몸이 사라질수록 구조는 더 필요해진다

침묵의 세계는 왜 더 정교한 헌법을 요구하는가

6.1 의료 AI: 실험이 허용되지 않는 세계 — 왜 의료는 처음부터 월드 모델을 요구했는가

6.1.1 의료는 왜 '추천 시스템'이 될 수 없는가

6.1.2 의료 AI가 요구하는 네 가지 정수(精髓)

① 시간적 예측(Temporal Prediction)

② 개입 조건부 예측(Action-conditioned Prediction)

③ 반사실 시뮬레이션(Counterfactual Rollout)

④ 계획과 통제(Planning & Control)

6.1.3 구조적 결핍: 언어는 생명을 담보하지 못한다 — 의료에서 월드 모델이 등장할 수밖에 없었던 이유

6.1.4 치료를 '말'이 아니라 '시뮬레이션'으로 바꾸다 — 메디컬 월드 모델(MeWM)의 등장

6.1.5 의료가 먼저 도달한 결론 — 실행은 설명이 아니라 구조로 증명되어야 한다

6.2 산업 AI와 디지털 트윈 — 멈출 수 없는 시스템에서 실행을 어떻게 통제하는가

6.2.1 언어를 공정에 투입하기 전에, 경계를 먼저 세워라

6.2.2 FSM·시뮬레이션·LLM의 역할 분리

6.2.3 현실을 대신해 먼저 실패하는 두 번째 세계

① 디지털 트윈은 실행을 대신 받아주는 세계다

② 디지털 트윈은 복제본이 아니라 판정 공간으로 진화한다

③ 보이지 않는 물리 세계도 월드 모델을 요구한다

④ 현실은 한 번만 실행되고, 판단은 다른 세계에서 끝난다

6.2.4 산업이 먼저 증명한 결론 — 자율성은 지능이 아니라 책임의 배치에서 나온다

6.3 엔터프라이즈·디바이스 AI — 몸은 없지만, 실행의 무게는 더 무거운 세계

6.3.1 성공적으로 실패하는 세계 — 사고가 아닌 '기록'으로 남는 파괴

6.3.2 디바이스 네이티브 협상 에이전트 — 침묵으로써 완성되는 실행

① 협상은 언어 문제가 아니라 '공간'의 문제다

② 월드 모델은 '공유'보다 '격리'를 먼저 설계한다

③ 결정권은 지능이 아니라 세계 쪽에 있다

6.3.3 GUI 에이전트 — 화면은 상태를 말해주지 않는다

① 화면은 현상일 뿐, 상태가 아니다

② GUI 자동화도 결국 상태 머신으로 돌아간다

6.3.4 비물리 세계의 공통된 불안 — 침묵하는 폭주

6.4 에이전틱 워크플로우 — 비물리 세계의 '몸'

6.4.1 비물리 세계에서 에이전트의 몸은 워크플로우다

6.4.2 네비게이션 문제: 보이지 않는 미로로서의 워크플로우

① 워크플로우의 핵심은 경로 인식과 실행 가능성

② 사람 중심 UI = 에이전트 미로

③ 구조적 해법: 역할 분리 에이전트 팀 + 상태 기반 워크플로우

6.4.3 장기 실행과 상태 추적: 왜 '기억'이 아니라 '세계'인가

6.4.4 월드 모델: 결국 로봇과 유령은 같은 법칙을 따른다

[Chapter Summary] 침묵의 세계일수록 더 단단한 몸이 필요하다

[저자 핵심 메시지]

Chapter 7. 일반적 에이전트를 위한 세계의 조건 — AGI는 왜 세계를 품어야 하는가

[Chapter Opening]

지도 없이 멀리 갈 수는 없다

더 좋은 LLM이 모든 것을 해결해주지는 않는다

데이터가 많다고 세계가 생기지는 않는다

지능과 세계는 서로 다른 일을 한다

진짜 질문은 누가 지도를 그릴 것인가이다

7.1 월드 모델은 AGI의 필수 조건인가

7.1.1 AGI의 G — 두 개의 전혀 다른 의미

① 일반화(Generalization) — 너비의 언어

② 일반성(Generality) — 깊이의 언어

7.1.2 월드 모델은 안전장치가 아니라 존재 조건이다

7.2 에이전트 일반성은 세계의 내부 표현을 요구한다

7.2.1 '일반화'에도 월드 모델이 필요한가

7.2.2 '월드 모델을 쓰지 않는다'는 '월드 모델이 없다'는 뜻이 아니다

7.2.3 숨겨진 세계는 통제되지 않는다

7.3 정책 속에 숨은 세계 — 세계 없는 일반성의 환상과 위험

7.3.1 월드 모델 프리는 세계 부재가 아니라 세계 은닉이다

7.3.2 헌법을 가진 AI도 예외가 아니다

7.3.3 언어의 헌법과 실행의 헌법은 다르다

7.4 일반성의 대가 — 능력이 커질수록 세계는 정교해져야 한다

7.4.1 해상도가 낮은 세계는 위험한 추론을 강요한다

7.4.2 다중 에이전트에서는 해상도가 곧 합의다

7.4.3 일반성의 역설: 추상화가 아니라 정밀함이다

7.5 이름은 달랐지만, 모두가 찾고 있던 에이전트 공유세계

7.5.1 명명 폭발기: 이름이 많았다는 것의 의미

7.5.2 2023 / 연구실의 언어

① Voyager: 체화된 실행 환경

② Smallville: 공유된 마을

7.5.3 2026.01 / 산업계의 언어: AI 운영체제(OS)

7.5.4 2026.02 / 현장 엔지니어링의 언어

① 하네스(Harness): 에이전트 바깥 세계의 경계

② 에이전트-퍼스트 월드(Agent-First World): 에이전트보다 세계를 먼저

③ 매니지드 에이전트(Managed Agents): 하네스를 넘어 인터페이스로

7.5.5 2026.04 / 학계의 언어: 세계 중심 다중 에이전트 시스템(World-Centered MAS)

7.5.6 이름의 계보: 모두가 같은 곳을 향하고 있었다

7.6 발견(Discovery)에서 설계(Design)로

7.6.1 우리는 이미 세계의 윤곽을 발견했다

7.6.2 세계는 액세서리가 아니라 척추다

7.6.3 실행할 수 없던 것을 실행 가능하게 하라(Execute the Inexecutable)

7.6.4 설계편: 우리의 세계를 직접 설계하는 법

[Chapter Summary] 지도는 선택이 아니라 생존이다

[저자 핵심 메시지]

Appendix A. 기업 리더를 위한 에이전틱 전환 가이드 — 조직을 바꾸고 싶다면, 먼저 이 20가지를 물어라

A.1 에이전트와 에이전틱 AI는 다르다

A.2 LLM은 1D, 에이전트는 2D, 조직은 3D다

A.3 3D 조직은 LLM이나 에이전트만으로는 운영되지 않는다

A.4 조직 AI는 개인용 AI와 다르다

A.5 확률적 세계와 결정적 세계는 서로 다르게 움직인다

A.6 LLM API와 레거시 API를 패치하듯 붙이는 방식은 결국 무너진다

A.7 AGI의 G는 하나가 아니다

A.8 인터랙티브 환경, 하네스, 헌법, 월드 모델은 서로 다른 이름으로 같은 곳을 가리킨다

A.9 조직에도 물질처럼 상태가 있다

A.10 버그와 드리프트는 다르다

A.11 에이전트 시대의 진짜 전략 자산은 궤적 데이터다

A.12 AX에서 늦게 해도 되는 일과 먼저 선점해야 하는 일을 구분하라

A.13 자율성은 한 번에 주는 것이 아니라 단계적으로 닫아간다

A.14 에이전트는 도구이면서, 동시에 직원에 가까워진다

A.15 세계를 가진 조직은 세계 중심의 조직이다

A.16 도메인 전문가와 정책 소유자는 주변 인력이 아니라 중심 인력이다

A.17 세계의 구성요소를 말하지 못하면, 아직 세계를 가진 것이 아니다

A.18 뉴로심볼릭 협업은 기술 유행이 아니라 운영의 필연이다

A.19 Agent OS의 본질은 앱 런처가 아니라 세계 집행기다

A.20 세계 운영은 장애 대응이 아니라 현실과 설계 사이의 틈을 읽어내는 일이다

A.21 맺음말

Appendix B. 실무자를 위한 비즈니스 물리학 — 엔터프라이즈 뉴로심볼릭 월드 모델 프리뷰

B.1 세계의 수식(World Formula) — 두 수식, 세 층위

B.2 레이어 1 — 세계의 정의(World Definition)

M — Mission(세계 목적/범위)

E — Entity(공식 엔티티/온톨로지)

Σ — SSOT(공식 기록면/단일 진실 원천)

B.3 레이어 2 — 세계의 동역학(World Dynamics)

S — State(상태 공간)

T — Transition(허용된 전이)

C — Constraint(가드/제약/정책)

B.4 레이어 3 — 세계의 운용(World Operation)

O — Observation(관측과 번역)

V — Verdict(판정 및 결과 계약)

H — Human-in-the-Loop(인간 개입)

A — Audit/Learning(감사 로그/학습 훅)

B.5 세 레이어를 한 장으로 — 설계편을 읽는 지도

B.6 캔버스를 채운다는 것