지능을 전기처럼 쓰는 시대를 AI Architect 관점에서 읽기

이 글은 전종홍의 『지능을 전기처럼 쓰는 시대 - AI 네이티브 핸드북 2026』을 요약하고, SW Architect·AI Architect로서 AI Agent 구축 사업과 Enterprise AI 도입을 지원하는 필자의 관점에서 분석한 글이다. 책의 주장과 필자의 해석을 구분해 기술했다. 페이지 표기는 검토한 PDF v1.5.6의 PDF 뷰어 기준이다.

원문과 출처

저자: 전종홍
검토한 판: v1.5.6, 2026년 10월 26일 개정, 458쪽
공식 배포 페이지: 지능을 전기처럼 쓰는 시대 - AI 네이티브 핸드북 2026
원문 PDF: 공식 PDF 열기
판 이력: GitHub v1.5.6 Release
라이선스: CC BY-NC-ND 4.0

공식 PDF 주소는 저자가 갱신하는 최신판을 가리킨다. 따라서 이 글의 페이지 번호와 세부 표현을 정확히 대조하려면 위 판 이력의 v1.5.6을 기준으로 보는 편이 좋다.

표지 출처: 전종홍, 『지능을 전기처럼 쓰는 시대 - AI 네이티브 핸드북 2026』 v1.5.6, CC BY-NC-ND 4.0.

먼저 결론: AI 경쟁력은 발전소보다 배선에서 갈린다

책은 파운데이션 모델을 발전소, MCP와 A2A를 송전망, AI Agent를 가전제품에 비유한다. 이 비유로 4차 AI산업혁명, 인프라, AX, 설계 원칙, 산업 변화, Agent 사회와 국가 전략까지 하나의 지도에 올린다.

내가 이 책에서 가장 중요하게 읽은 결론은 다음과 같다.

좋은 모델을 확보하는 것만으로 AI Native가 되지 않는다. 지능을 업무에 연결하는 권한, 맥락, 검증, 기록, 비용, 중단과 복구 체계를 함께 설계해야 한다.

기업이 전기를 잘 쓴다는 말이 발전소를 직접 보유했다는 뜻은 아니다. 필요한 곳에 안정적으로 공급하고, 사용량을 계량하며, 사고가 나면 차단하고, 다른 공급원으로 전환할 수 있다는 뜻에 가깝다. Enterprise AI도 마찬가지다. 모델의 벤치마크 순위보다 지능을 업무 성과로 바꾸는 운영체계가 지속적인 차이를 만든다.

이 관점은 내가 맡고 있는 일과 직접 연결된다.

AI Architect: 모델·데이터·인프라 중심 설계에서 권한·검증·복원력까지 포함한 실행 아키텍처로 확장한다.
AI Agent 사업: 기능 데모보다 완료 조건, Tool 권한, 증적과 운영 인수 기준을 먼저 설계한다.
Enterprise AI 도입: 라이선스 배포가 아니라 업무 흐름과 책임, 교육, 평가 체계를 함께 바꾼다.
AI 기반 SW 개발: 코드 생성 속도보다 검증 용량과 의도 보존을 관리한다.
DDD·MSA·Cloud Native: Agent의 업무 경계와 소유권, 계약, 관찰 가능성을 명시한다.

1. 책의 전체 지도

458쪽의 내용은 크게 일곱 층으로 읽을 수 있다.

부	책의 질문	실무에서 남는 질문
1부. 4차 AI산업혁명	왜 지능을 새로운 에너지로 보는가?	일시적 도구 유행과 구조적 변화를 어떻게 구분할까?
2부. 지능 에너지 시스템	모델·컴퓨트·MCP·A2A·토큰 경제는 어떻게 연결되는가?	어떤 구성요소를 소유하고 어떤 것은 구매할까?
3부. AX의 여정	AI-Ready에서 AI-Native로 어떻게 이동하는가?	기존 업무 최적화와 업무 재설계의 경계는 어디인가?
4부. 사고법과 설계 원칙	AI를 전제로 무엇을 다시 설계해야 하는가?	가치·신뢰·확률·조합을 어떤 기준으로 결정할까?
5부. 산업별 혁명	산업마다 지능을 어떻게 검증하고 적용하는가?	범용 모델, RAG, 특화 모델 중 무엇이 필요한가?
6부. Agent가 만드는 세상	Agent의 권한·기억·보안·협업은 어떻게 달라지는가?	사람은 어디서 승인하고 언제 중단시켜야 하는가?
7부. 지능 에너지 사회	법·노동·격차·국가 전략은 어떻게 바뀌는가?	기업의 전환을 사회적 책임과 어떻게 연결할까?

책의 장점은 기술 스택과 조직 전환을 따로 설명하지 않는 데 있다. 모델이 좋아지는 속도, 전력과 GPU, 프로토콜, 업무 프로세스, 검증, 노동과 책임을 하나의 시스템으로 본다.

2. 핵심 주장 다섯 가지

2.1 AI Native는 기능 수가 아니라 가치 구조의 변화다

책은 AI를 자동차의 에어컨처럼 덧붙이는 상태와 엔진처럼 핵심 가치 구조에 넣는 상태를 구분한다. AI Native는 AI가 핵심 가치를 만들고, 사용 결과와 사람의 수정이 다시 개선으로 이어지는 상태다(PDF p.134-136).

이 정의에서 중요한 것은 ‘AI를 많이 쓴다’가 아니다. 다음 네 가지가 함께 바뀌는가다.

가치 구조: AI가 고객이 선택하는 핵심 이유에 기여하는가?
업무 통합: 입력, 판단, 실행, 예외 처리가 한 흐름으로 이어지는가?
학습과 측정: 실제 사용과 사람의 수정이 다음 품질 개선으로 연결되는가?
복원력: 모델 장애와 오판 때 우회·중단·복구할 수 있는가?

여기서 복원력이 특히 중요하다. AI 의존도가 높을수록 대체 경로와 수동 운영 절차가 더 필요하다. AI가 없으면 멈춘다는 사실은 Native의 증거가 아니라 취약성의 신호일 수도 있다.

2.2 AX의 네 단계는 서열이 아니라 투자 판단 도구다

책은 AX를 Ready → Enabled → First → Native로 구분한다(PDF p.140-143).

단계	의미	다음 단계로 갈 증거	멈추거나 보완할 신호
Ready	데이터·권한·책임·기준선 준비	실제 업무 실험과 평가 기준이 준비됨	데이터 출처와 사고 책임자가 불명확함
Enabled	기존 업무 일부를 AI가 보조	품질·시간·비용 개선이 반복됨	검토와 오류 비용이 편익을 넘어섬
First	AI를 전제로 흐름과 역할 재설계	예외·사람 개입을 포함한 전체 흐름이 안정됨	병목만 이동하거나 책임이 흐려짐
Native	AI가 핵심 가치와 학습 구조에 결합	가치·단위경제성·안전·복원력이 함께 유지됨	특정 모델 장애가 사업 중단으로 이어짐

이 사다리를 조직 전체의 인증 등급처럼 쓰면 안 된다. 같은 회사에서도 회계는 Enabled, 고객 지원은 First, 특정 디지털 제품은 Native가 적절할 수 있다. 규제와 실패 비용 때문에 일부러 Enabled에 머무는 선택도 성숙한 결정이다.

Architect가 해야 할 일은 모든 업무를 Native로 끌어올리는 것이 아니라, 업무별로 적정 단계와 승급 증거를 정의하는 것이다.

2.3 코드 생성이 빨라질수록 검증이 병목이 된다

책은 AI가 만드는 속도와 사람이 확인하는 속도 사이의 간격을 ‘검증 격차’로 설명한다(PDF p.214-216). 생성량이 늘면 리뷰해야 할 결과도 늘어난다. 사람이 검토한다고 적어 두는 것만으로 안전해지지 않는다. 반복되는 정상 결과는 오히려 주의를 느슨하게 만든다.

책이 제안하는 방향은 단순히 리뷰 시간을 늘리는 것이 아니다.

구현 전에 사양과 완료 조건을 합의하는 Verification-first
변경 의도, 테스트 증거, 위험, 사람이 볼 지점을 함께 제출하는 PR Contract
거대한 변경을 작은 단위로 나누는 리뷰 방식
보안·성능·정확성을 서로 다른 관점에서 검사하는 전문 검증 체계
AI 관여 범위와 사람이 직접 확인한 내용을 남기는 서명

AI 기반 SDLC의 생산성은 생성한 코드 줄 수가 아니라 다음 식으로 봐야 한다.

실제 생산성 = 채택된 결과의 가치
            - 검토 비용
            - 재작업 비용
            - 장애와 복구 비용
            - 장기 유지보수 비용

2.4 Agent의 성능은 모델보다 하네스에서 갈린다

책은 Agent = Model + Harness라는 관점으로 하네스를 다섯 계층으로 정리한다(PDF p.327-332).

하네스 계층	아키텍처 책임
Tool Orchestration	사용할 도구, 순서, 오류 처리와 복구 경로
Verification Loops	진행 중 품질 검사, 테스트, 독립 평가
Context & Memory	필요한 맥락의 선택, 결정·기억의 보존과 갱신
Guardrails	최소 권한, 샌드박스, 예산 상한, 승인 지점
Observability	Trace, 텔레메트리, 감사 로그, 비용과 결과 연결

나는 여기에 책이 추가로 강조한 네 항목을 ‘하네스의 계약층’으로 묶고 싶다.

목적과 완료 조건: 무엇이 되면 끝이고, 무엇을 해서는 안 되는가?
능력과 권한의 분리: 할 수 있는 Tool과 실제로 해도 되는 행동은 무엇인가?
완료와 성과의 분리: 절차가 끝났는가, 사용자가 원하는 결과가 만들어졌는가?
차단 이후의 복구: 호출 차단, 중단 확인, 영향 확인, 복구, 재개의 전 과정이 있는가?

프롬프트에 “운영 DB를 지우지 마”라고 쓰는 것은 통제가 아니다. 운영 DB에 닿지 못하도록 권한을 분리하는 것이 통제다. 좋은 하네스는 Agent를 설득하는 문장이 아니라 Agent가 선을 넘기 어려운 실행 환경이다.

2.5 멀티 Agent의 병목은 지능이 아니라 조율 비용이다

멀티 Agent는 병렬 처리와 전문화를 제공하지만 Agent 수만큼 성과가 선형 증가하지 않는다. 같은 파일 수정, 상충하는 가정, 중복 조사, 오류 전파, 토큰 비용과 사람의 조율 시간이 늘어난다(PDF p.334-338).

책이 강조한 가장 실무적인 지점은 핸드오프다. 다른 Agent에게 결과만 넘기면 다음 Agent는 이미 폐기된 길을 다시 시도하거나 가정을 사실로 받아들인다. 최소한 다음 네 가지가 함께 전달되어야 한다.

의도: 원래 무엇을 달성하려 했는가?
시도: 무엇을 해 보았고 어떤 길을 버렸는가?
증거: 무엇이 사실이고 무엇이 아직 가정인가?
종료: 어떤 조건을 만족하면 끝인가?

DDD 관점에서 보면 이것은 Agent 간 Anti-corruption Layer이자 Context Mapping 문제다. A2A로 메시지를 보낼 수 있다는 사실과 업무 의미를 손실 없이 인계한다는 사실은 다르다. 프로토콜 연결은 상호운용성의 시작이지 의미적 계약의 완성이 아니다.

3. 내 관심사와 담당업무에 주는 의미

3.1 AI Architect: 모델 선정표보다 ‘지능망’ 설계가 중요해진다

전통적인 AI 아키텍처 문서는 모델, 데이터 파이프라인, API, 벡터 DB와 인프라를 중심으로 작성한다. Agentic AI에서는 다음 산출물이 추가되어야 한다.

영역	반드시 답할 질문	권장 산출물
Outcome	어떤 업무 성과가 나면 성공인가?	Outcome Contract, 기준선
Boundary	Agent가 맡지 않을 일과 Bounded Context는 무엇인가?	Agent Card, Context Map
Authority	조회·초안·변경·결제 중 어디까지 가능한가?	권한 원장, Tool Allowlist
Evidence	완료와 품질을 무엇으로 증명하는가?	Eval Set, PR Contract, 승인 기록
Handoff	다른 Agent에게 어떤 의미와 상태를 넘기는가?	Handoff Contract, 상태 스키마
Observability	판단·호출·비용·결과를 어떻게 추적하는가?	Trace Schema, KPI Dashboard
Resilience	모델·도구 장애 때 어떻게 멈추고 우회하는가?	Kill Switch, Fallback, Runbook
Lifecycle	모델·프롬프트·기억 변경과 폐기를 어떻게 관리하는가?	재검증 조건, Retirement Plan

앞으로 Architecture Decision Record에는 “왜 이 모델을 골랐는가”만 아니라 “어떤 업무 권한을 어디서 집행하고, 실패했을 때 누가 무엇을 멈추는가”가 들어가야 한다.

3.2 AI Agent 제안·수행: PoC 성공 기준부터 바꿔야 한다

Agent PoC는 데모 성공률이 높다. 데이터와 예외를 좁히고 사람이 옆에서 보정할 수 있기 때문이다. 운영 전환에서 문제가 되는 것은 보통 모델 밖이다.

실제 데이터의 품질과 접근권한
업무 시스템과 Tool의 실패 처리
승인과 책임 주체
검증 가능한 완료 조건
비용 상한과 재시도 정책
로그·감사·사고 대응
모델·Tool 변경 시 회귀 평가
공급자 중단과 계약 종료 시 전환

따라서 RFP와 제안서의 성공 기준도 “정확도 90%” 한 줄로 끝나면 안 된다. 성공 작업당 총비용, 사람 검토 시간, 재작업률, 중단·복구 시간, 권한 위반 건수를 함께 측정해야 한다.

3.3 Enterprise AI 도입: 사용 교육보다 업무 재설계가 먼저다

ChatGPT Enterprise, Claude Enterprise, Gemini Enterprise를 배포하고 프롬프트 교육을 하면 사용량은 늘어난다. 그러나 기존 보고·승인·평가 구조가 그대로라면 Enabled 단계의 부분 최적화에 머물기 쉽다.

변화관리는 세 층으로 설계해야 한다.

Platform: 승인된 모델, 데이터 경계, 계정, Tool, 로그와 비용
Process: AI가 초안을 만들고 사람이 판단할 지점, 예외와 이의제기 경로
People: 역할별 교육, 검토 시간, 새로운 책임과 권한, 주니어 성장 경로

특히 중요한 것은 검토 업무를 ‘남는 시간에 하는 일’로 두지 않는 것이다. 생성량이 늘면 검토 용량도 늘려야 한다. Agent 운영과 최종 품질 책임이 직무에 추가됐다면 평가와 보상에도 반영해야 한다(PDF p.318-320).

3.4 AI 기반 SW 개발: 작성 중심 SDLC를 증거 중심 SDLC로 바꾼다

AI 코딩 Agent가 요구사항, 코드, 테스트, 문서를 동시에 만들면 산출물의 양은 더 이상 진척의 좋은 대리변수가 아니다. 단계마다 다음 증거가 필요하다.

단계	AI 시대의 Gate	통과 증거
Discover	자동화할 가치와 실패 비용이 명확한가?	기준선, 기대 성과, 비자동화 대안
Specify	의도·제약·완료 조건이 검증 가능한가?	Spec, Acceptance Criteria, 금지 조건
Design	데이터·권한·의존성·복구가 설계됐는가?	Data Flow, Threat Model, 권한 원장
Build	Agent의 변경 범위가 격리됐는가?	샌드박스, 작은 변경, 생성 이력
Verify	다른 관점의 독립 검증을 통과했는가?	테스트, 보안·성능 리뷰, 원문 대조
Release	중단·롤백·관찰이 실제로 작동하는가?	Runbook, Kill Switch 훈련, Trace
Operate	가치와 위험을 함께 측정하는가?	성공 작업당 비용, 재작업률, 사고 기록
Retire	권한·기억·데이터를 안전하게 회수하는가?	폐기 승인, Export/Delete 증적

핵심 산출물은 코드가 아니라 의도에서 운영 결과까지 이어지는 증거 사슬이다.

3.5 DDD와 Cloud Native: Agent도 경계·계약·소유권이 필요하다

Cloud Native가 컨테이너 수를 늘리는 일이 아니듯 AI Native도 Agent 수를 늘리는 일이 아니다. DDD와 MSA의 교훈은 Agent 설계에도 그대로 적용된다.

Agent는 하나의 명확한 업무 책임과 Owner를 가져야 한다.
Tool 권한은 Bounded Context 안에서 최소화해야 한다.
다른 도메인으로 넘길 때 의미와 상태를 명시적 계약으로 변환해야 한다.
장기 기억은 사실·추정·타인의 진술을 구분하고 유효기간을 가져야 한다.
이벤트와 Trace는 실행의 원인과 결과를 연결할 수 있어야 한다.
되돌릴 수 없는 행위는 승인, 보상 트랜잭션과 영향 반경 제한이 필요하다.

Agent가 자연어를 이해한다는 이유로 경계를 흐리면 초기 데모는 빨라진다. 그러나 운영 단계에서는 암묵적 결합과 책임 공백이 폭발한다.

4. 프로젝트에 바로 쓰는 AI-Native Architecture Canvas

책의 논지를 현장 질문으로 재구성하면 다음 한 장이 된다.

항목	핵심 질문
Business Outcome	고객·현업의 어떤 결과를 바꾸며 현재 기준선은 무엇인가?
Remove Test	AI를 빼면 가치가 얼마나 남고 운영은 계속 가능한가?
Workflow	기존 단계를 빠르게 할 것인가, 흐름과 역할을 다시 설계할 것인가?
Owner	업무 결과, 기술 운영, 데이터, 보안의 책임자는 누구인가?
Data & Memory	어떤 데이터를 쓰며 출처·권리·유효기간·삭제 기준은 무엇인가?
Model & Routing	과업별 모델 선택과 대체 경로는 무엇인가?
Tools & Authority	할 수 있는 기능과 실제 허용된 행동을 어디서 분리·집행하는가?
Autonomy	제안, 초안, 승인 후 실행, 자율 실행 중 어느 수준인가?
Evidence	완료·품질·정책 준수를 무엇으로 증명하는가?
Handoff	의도·시도·증거·종료 조건을 어떤 형식으로 넘기는가?
Unit Economics	토큰값이 아니라 성공 작업당 총비용은 얼마인가?
Resilience	차단, 영향 확인, 복구, 재개와 공급자 전환이 가능한가?
Learning	사람의 수정과 운영 결과가 어떤 승인 절차로 개선에 반영되는가?
Retirement	권한·기억·데이터·예약 작업을 어떻게 회수하고 폐기하는가?

이 Canvas에 답하지 못하는 Agent는 운영 제품이라기보다 모델의 가능성을 보여 주는 프로토타입에 가깝다.

5. 내가 현장에 적용할 90일 실행안

1-30일: 지능 사용 현황과 증거 공백을 찾는다

부서별 AI 도구, Agent, 자동화 업무를 하나의 Inventory에 등록한다.
업무별 현재 AX 단계와 목표 단계를 정한다.
시간·비용·품질·재작업의 현재 기준선을 측정한다.
데이터·Tool·외부 모델·Owner를 연결한 Context Map을 만든다.
장애와 오판 때 중단할 사람과 수동 대체 경로를 확인한다.

31-60일: 하나의 고가치 흐름에 하네스를 만든다

반복적이고 완료 조건이 분명하며 되돌리기 쉬운 업무를 고른다.
목적, 금지 조건, 비용 상한, 사람 승인 지점을 명세한다.
Eval Set과 실패 사례를 먼저 만들고 기준선을 확정한다.
최소 권한, Tool Allowlist, Trace와 Kill Switch를 구현한다.
모델 2개 이상을 같은 업무 표본으로 비교한다.

61-90일: 기능이 아니라 업무 흐름을 다시 설계한다

AI가 빨라진 단계 뒤에 새 병목이 생겼는지 Value Stream을 다시 측정한다.
사람의 검토 시간과 재작업을 포함해 성공 작업당 총비용을 계산한다.
Incident Drill로 차단부터 복구·재개까지 실제 시간을 잰다.
사용자·Builder·Owner·감사자별 교육을 분리한다.
확대, 개선, 유지, 중단 중 하나를 증거로 결정한다.

90일 뒤 남아야 할 것은 ‘Agent를 만들었다’는 발표가 아니다. 어떤 조건에서 이 Agent를 믿을 수 있고, 얼마의 비용으로 운영하며, 언제 멈춰야 하는지 설명하는 증거다.

6. 비판적으로 읽기

강점 1. 기술과 조직을 하나의 운영 시스템으로 본다

모델, 컴퓨트, 프로토콜, 비용, 업무, 검증, 노동과 정책을 연결해 설명한다. 특히 부록의 10가지 기본 조건, 지능망의 일곱 설비, 증거 점검 40문은 경영·아키텍처·운영 대화를 이어 주는 좋은 출발점이다(PDF p.419-429).

강점 2. ‘증거’를 성숙도의 조건으로 둔다

문서가 있다는 주장보다 운영 로그, 비교 평가, 훈련 결과, 승인 기록처럼 다른 사람이 확인할 수 있는 증거를 요구한다. 평균 점수보다 고위험 업무의 공백과 답이 갈리는 지점을 먼저 보라는 제안도 실무적이다.

강점 3. 모델 중심 사고를 하네스와 운영 책임으로 확장한다

모델이 좋아지면 일부 프롬프트와 컨텍스트 장치는 얇아질 수 있다. 그러나 권한, 감사 기록, 책임, 중단과 복구는 모델 성능이 대신 해결하지 못한다. 이것은 기술 문제가 아니라 조직의 의사결정이기 때문이다.

한계 1. 전기 비유는 강력하지만 AI의 차이를 가릴 수 있다

전기는 같은 규격 안에서 비교적 균질하고 결정적으로 동작한다. 반면 AI의 출력은 모델·데이터·프롬프트·컨텍스트·도구·시점에 따라 달라진다. 전기를 연결하듯 지능을 꽂으면 된다고 받아들이면 다음을 놓치기 쉽다.

같은 입력에도 결과가 달라지는 확률성
데이터와 맥락에 따른 성능 편차
추천과 판단에 섞이는 공급자의 이해관계
사용 과정에서 생기는 책임과 권리 문제
자동화가 조직 행동과 역량을 되바꾸는 효과

따라서 ‘지능망’에는 전력망보다 더 두꺼운 의미·검증·책임 계층이 필요하다.

한계 2. 사례의 증거 수준이 서로 다르다

책은 국제표준, 학술 연구, 공식 문서, 기업 자체 발표, 언론 보도, 미래 시나리오를 폭넓게 사용하고 각각의 한계를 표시하려 노력한다. 그래도 독자는 숫자를 같은 무게로 읽으면 안 된다. 도입 결정에 사용할 때는 원출처, 표본, 평가 조건과 이해관계를 다시 확인해야 한다.

한계 3. 사다리는 편리하지만 실제 전환은 왕복한다

Ready에서 Native까지의 네 단계는 대화에 유용하지만 현실의 시스템은 일직선으로 이동하지 않는다. 모델 변경, 규제, 사고, 비용 상승으로 First에서 Enabled로 돌아갈 수 있고, 한 흐름 안에서도 단계가 섞인다. 단계 이름보다 승급과 후퇴의 조건을 운영 규칙으로 두는 편이 중요하다.

한계 4. AI Native가 언제나 목표는 아니다

차별화가 없는 범용 업무, 실패 비용이 큰데 검증 이익이 작은 업무, 변화가 드물고 규칙이 명확한 업무는 기존 자동화나 Enabled가 더 경제적일 수 있다. AI를 빼도 충분히 잘 돌아가는 시스템이라면 그것이 나쁜 아키텍처라는 뜻은 아니다.

맺으며: Architect는 발전소 구매자가 아니라 지능망 설계자다

이 책의 전기 비유가 가장 잘 작동하는 지점은 ‘모델이 모든 것’이라는 생각을 깨는 데 있다. 발전소가 좋아져도 낡은 배선, 없는 계량기, 느슨한 권한, 작동하지 않는 차단기로는 안전하고 경제적인 시스템을 만들 수 없다.

AI Architect의 역할도 달라진다. 좋은 모델을 선택하고 API를 연결하는 데서 끝나지 않는다.

어떤 업무에 지능을 공급할지 정한다.
가치 흐름과 책임 경계를 다시 그린다.
Agent의 능력과 권한을 분리한다.
생성 속도에 맞는 검증 용량을 설계한다.
비용과 품질을 성공 작업 단위로 계량한다.
장애와 오판 때 멈추고 복구할 수 있게 한다.
공급자를 바꿔도 업무와 기억을 이어 갈 수 있게 한다.

결국 AI Native의 핵심은 AI가 없는 시스템을 낡았다고 부르는 데 있지 않다. 지능을 써야 할 곳과 쓰지 말아야 할 곳을 구분하고, 쓸 때는 조직이 감당할 수 있는 권한과 증거와 복원력을 함께 설계하는 것이다.

모델은 계속 바뀐다. 그러나 목적, 책임, 권한, 검증과 복구의 구조는 조직이 직접 만들어야 한다. AI 시대의 경쟁력은 가장 큰 발전소를 가진 조직보다, 가장 좋은 지능망을 운영하는 조직에서 나올 가능성이 크다.