홈앤서비스 SK BROADBAND

* 설계편은 원리편의 이론적 기반 위에서 설계 방법론을 전개합니다.

Intro. 이 책을 읽는 법
I.1 원리편은 무엇을 위해 기록되었는가
I.2 설계편은 무엇을 위해 기록되었는가
I.3 이 책은 어떤 독자를 위한 책인가
I.4 끝으로

PART 3. 세계를 설계하는 공학 - 실행 가능한 세계는 어떻게 만들어지는가
1, 2부가 증명한 것 - 지능은 실행의 충분조건이 아니다
런타임은 설계된 세계 위에서만 가동된다
당위가 아닌 방법론, 추상이 아닌 명세
온톨로지와 월드 DSL - 세계의 어휘와 문법
ESTC: 실행 가능한 세계를 위한 최소 좌표계
추정 상태와 확정 상태 - 실행의 환각을 막는 경계선
월드 모델 캔버스 - 지능의 전장을 설계하는 단 하나의 판
비즈니스의 보편적 실행 축과 에이전틱 전환
3부의 여정 - 이제 우리는 세계를 건설한다

Chapter 8. 세계가 집행하는 지능의 궤도 - ESTC와 월드 모델 캔버스
[Chapter Opening]
설계되지 않은 세계는 집행될 수 없다
기존의 설계도는 왜 에이전트 앞에서 침묵하는가
세계의 어휘, 형식, 골격: 실행 친화적 설계 언어
ESTC - 뉴럴과 심볼릭이 만나는 설계의 경계면
무질서한 세계: 공허를 부유하는 지능
혼돈을 질서로 바꾸는 청사진 - 월드 모델 캔버스
8.1 왜 설계도가 먼저인가 - 세계는 설계자가 부여한 질서 위에서만 작동한다
8.1.1 실행 계약은 허공에서 완결되지 않는다
① 후보는 전이 공간이라는 질서를 전제로 한다
② 가드는 상태와 제약이라는 법전을 전제로 한다
③ 결과는 확정 상태와 SSOT라는 대지를 전제로 한다
8.1.2 질서는 스스로 태어나지 않는다
① 런타임은 세계의 입법자가 아니다
② 설계의 균열: 지능의 결함인가, 세계의 부재인가
③ 창조의 도구: 설계자의 실행 언어
8.2 실행 친화적 설계 언어는 무엇을 갖춰야 하는가 - 기존 설계도 위에 어떤 층이 더 필요한가
8.2.1 사람이 읽는 설계도와 에이전트가 집행하는 설계도는 다르다
① 기존 설계도는 인간의 이해를 돕는 탁월한 지도다
② 그러나 집행의 기준은 설명과 다른 차원의 문제다
③ 설계의 패러다임 시프트
8.2.2 실행 설계는 무엇을 함께 닫아야 하는가
① 무엇이 존재하는가를 닫아야 한다 (Entity)
② 지금 무엇이 사실인가를 닫아야 한다 (State)
③ 무엇이 바뀔 수 있는가를 닫아야 한다 (Transition)
④ 언제 허용되는가를 닫아야 한다 (Constraint)
⑤ 네 질문의 유기적 결합: 실행의 사슬
8.2.3 설계는 런타임의 물리적 지지 기반이다
① 추론을 집행 후보로 승격시키는 기준면
② 직관을 설명 가능한 판정으로 바꾸는 기준면
③ 휘발되는 사건을 연속적인 세계로 묶어주는 기준면
8.2.4 실행 친화적 계층이 필요하다
8.3 ESTC는 세계의 문법이다 - 어휘와 형식 위에 세워지는 실행의 최소 골격
8.3.1 세계를 설계한다는 것은 세 층위를 쌓아 올리는 일이다
8.3.2 온톨로지: 세계의 어휘를 설계한다
① 온톨로지는 무엇을 식별할 것인가를 결정한다
② 왜 어휘가 모든 설계의 시작인가
③ 커머스 사례: 존재와 관계가 선행되어야 하는 이유
8.3.3 월드 DSL: 세계를 실행 가능한 형식으로 고정한다
① 왜 DSL이라는 형식이 필요한가
② 월드 DSL은 무엇을 고정하는가
③ 커머스 사례: 자연어 정책을 실행 명세로 고착화하기
8.3.4 ESTC: 세계를 움직이게 하는 최소 골격
① ESTC는 체크리스트가 아니라 결속된 구조다
② 심볼릭과 뉴럴 월드 모델이 교차하는 공통의 축
③ ESTC는 세계를 완성하는 최소 문법이다
8.3.5 도메인 위에서 드러나는 ESTC의 네 요소
① 엔티티: 무엇이 세계의 주인공인가를 고정한다
② 상태: 지금 어디에 와 있는가를 좌표화한다
③ 전이: 무엇이 다음 행동이 될 수 있는가를 형식화한다
④ 제약: 무엇이 허용되고 무엇이 막히는가를 닫는다
8.3.6 왜 ESTC가 최소 골격인가
① 하나라도 빠지면 런타임 루프는 무너진다
② 최소라는 것은 적다는 뜻이 아니라 더 줄일 수 없다는 뜻이다
③ 이제 이 골격이 런타임과 어디서 맞물리는지를 보아야 한다
8.4 ESTC와 뉴로심볼릭 런타임의 접합 - 설계와 실행은 어디서 서로를 참조하는가
8.4.1 1단계: 의도 파악과 관측·번역은 무엇을 읽는가
① 관측은 반드시 특정한 존재에 귀속되어야 한다
② 번역은 엔티티와 상태의 언어로 정렬되어야 한다
③ 규격화되지 않은 관측은 집행의 동력이 아닌 잡음일 뿐이다
8.4.2 2단계: 전이 후보는 무엇을 참조하는가
① 후보는 설계된 전이 형식을 참조한다
② 전이의 이름, 조건, 효과가 하나의 실행 단위로 구조화되어야 한다
③ 전이(T)가 없으면 NWM의 후보는 실행 단위로 승격되지 못한다
8.4.3 3단계: 가드는 무엇을 근거로 판정하는가
① 가드는 상태(S)를 판정의 좌표로 삼는다
② 가드는 제약(C)을 판정의 법전으로 삼는다
③ 판정은 상태(S)와 제약(C)의 교차점에서 완결된다
8.4.4 4~5단계: 실행·커밋과 SSOT 스냅샷은 무엇을 확정하는가
① 커밋(Commit)은 상태를 사실로 확정한다
② SSOT는 그 확정된 사실의 공식 기록면이다
③ 5단계의 스냅샷 게시가 다음 루프의 출발점을 만든다
8.4.5 6~7단계: 그라운딩과 재보정은 무엇을 되돌려받는가
① 그라운딩은 추정 상태(Belief)를 SSOT의 사실로 교정한다
② 재보정은 확정된 사실을 토대로 다음 루프의 전략을 조정한다
8.4.6 ESTC는 NWM과 SWM 모두의 공통 참조면이다
① ESTC는 SWM의 법전이자 NWM의 정렬면이다
② ESTC의 빈칸은 런타임의 치명적 결손으로 드러난다
③ 설계와 실행은 분리된 단계가 아닌 단일한 생태계다
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 4. 세계를 운영하는 기술 - 만들어진 세계는 어떻게 자라나는가
[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. 참고문헌