AI 에이전트 실행 세계 2 : 설계편
- 저자
- 조쉬(이주환) 저
- 출판사
- 로드북
- 출판일
- 2026-08-14
- 등록일
- 2026-10-12
- 파일포맷
- 파일크기
- 41MB
- 공급사
- YES24
- 지원기기
- PC PHONE TABLET 웹뷰어 프로그램 수동설치 뷰어프로그램 설치 안내
책소개
설계되지 않은 도메인은 에이전트가 집행할 수 없다.감(感)으로 프롬프트를 짜는 것과, 설계도로 도메인을 명세화하는 것은 전혀 다른 일이다. 1권(원리편)에서 '왜'를 이해했다면, 이 책에서 '어떻게'를 완성한다. 저자가 창시한 ESTC 프레임워크(Entity·State·Transition·Constraint)와 이를 위한 도구인 월드 모델 캔버스(World Model Canvas)로 어떤 비즈니스 도메인이든 에이전트가 읽고 판단하고 실행할 수 있는 구조로 설계할 수 있다는 것을 보여준다. 커머스·마케팅·HR 세 도메인 설계 사례와 워크샵이 챕터마다 포함되어, 책을 덮는 순간 여러분 도메인에 맞는 설계 초안을 직접 만들 수 있도록 구성했다.
저자소개
실리콘밸리 소재 AI 스타트업 Swit Technologies Inc.의 창업자이자 대표다. 에이전틱 AI를 위한 ESTC(Entity·State·Transition·Constraint) 프레임워크와 월드 모델 캔버스(World Model Canvas)를 창시했으며, 베스트셀러 『AI 에이전트 생태계』를 집필했다. 현재 행정안전부 인공지능 기술자문단 위촉위원으로 활동하고 있다. 서울대학교 영어영문학과를 졸업하고, BU Questrom School of Business의 KIC Start MassChallenge 및 Stanford University Design Thinking 과정을 수료했다.
목차
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 STC는 모두 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-Loop11.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 ToolkitC.2 ESTC Runtime EngineC.3 World Model Anti-PatternsC.4 World Debt DetectorC.5 WorldLoops for OpenClawC.6 다섯 저장소의 관계Epilogue. 인간이 설계하는, AI '세계'E.1 LLM의 막다른 길, 그리고 세계의 귀환E.2 스케일링 이후, 다시 세계로E.3 워크플로우 세계를 시뮬레이션하라E.4 에이전트 중심에서, 세계 중심으로E.5 세계를 가진 조직: 위임의 시대로E.6 일의 과거에서, 일의 미래로E.7 프롬프트와 하네스를 넘어, 세계로E.8 인간이 해내야 할 마지막 과업References. 참고문헌
이 책을 대출한 회원이 함께 대출한 컨텐츠가 없습니다.