From Hierarchy to Intelligence: 잭 도시가 블록에서 중간 관리층을 AI로 대체하는 설계

관리자의 일 중 상당 부분은 정보를 위아래로 나르는 일입니다. 회사의 모든 업무 기록을 AI가 하나의 world model(회사가 지금 어떤 상태인지 늘 최신으로 유지되는 모형)로 묶으면, 그 전달 업무를 시스템이 맡고 사람은 고객 결과를 책임지는 일에 집중할 수 있다는 것이 잭 도시의 구상입니다. 실제로 해 보려면 사람을 줄이는 일보다, 업무가 기계가 읽을 수 있는 기록으로 남는 구조를 먼저 만들어야 합니다.

요약

티타임즈TV가 2026년 9월에 내놓은 영상으로, 트위터 공동 창업자 잭 도시가 이끄는 핀테크 기업 블록(Square, Cash App의 모회사)의 조직 실험을 다룹니다. 영상의 바탕은 세 가지입니다. 블록은 2026년 2월 약 1만 명이던 직원 가운데 4,000명 이상, 약 40%를 줄인다고 발표했습니다. 3월 말에는 도시가 Sequoia의 로엘로프 보타와 함께 에세이 “From Hierarchy to Intelligence”를 냈고, 이어 Sequoia 팟캐스트에서 구상을 더 자세히 설명했습니다. 핵심은 이렇습니다. 지금의 회사 위계는 로마군 이래 “사람이 정보를 층층이 나르는” 방식이었는데, 원격 근무 회사에서는 결정, 코드, 계획, 대화가 이미 디지털 기록으로 남습니다. AI가 이 기록으로 회사 전체의 world model을 만들면, 관리자가 하던 상황 공유와 조정을 시스템이 대신할 수 있다는 것입니다.

보도와 팟캐스트에서 밝힌 수치.

도시는 팟캐스트에서 조직을 피라미드가 아니라 원으로 그립니다. 가운데에 world model과 intelligence layer(능력을 조합해 고객에게 먼저 해법을 내미는 AI 계층)가 있고, 사람은 가장자리에서 고객 결과에 맞춰 시스템을 조정합니다. 사람의 역할은 세 가지로 줄어듭니다. 한 계층을 깊이 맡는 IC(Individual Contributor), 특정 고객 문제를 책임지는 DRI(Directly Responsible Individual), 직접 일하면서 사람을 키우는 player-coach입니다. 상시적인 중간 관리층은 두지 않습니다. 현재 CEO에서 가장 먼 직원까지 최대 5층인 조직을 올해 2~3층으로 줄이는 것이 목표이고, 도시는 극단적인 이상으로 남은 약 6,000명 모두가 자신에게 직접 보고하는 모습까지 언급합니다. 영상 마지막 챕터가 짚듯, 이 구상은 아직 초기 단계입니다. 도시와 보타도 일부는 실패한 뒤에야 작동할 것이라고 말합니다. 아래에서는 이 설계가 어떻게 작동하는지와, 다른 기업이 사업부 하나에서 시험해 보는 방법을 정리합니다.

피라미드와 원형 조직의 차이. AX Review가 개념을 새로 그린 도식입니다.

핵심 메커니즘

1. Span of control: 위계가 생기는 이유

무엇인가. 리더 한 명이 직접 볼 수 있는 인원에는 한계가 있고(에세이는 대략 3~8명으로 봅니다), 조직이 커질수록 그 한계 때문에 층이 쌓인다는 개념입니다.

어떻게 작동하나. 에세이는 로마군을 예로 듭니다. 8명이 한 막사 단위(contubernium)를 이루고, 이것이 80명, 480명, 약 5,000명 단위로 차곡차곡 묶입니다. 층이 늘면 리더 한 명이 보는 인원은 줄지만, 정보가 위아래로 오가는 데 시간이 더 걸립니다. 이후 프로이센 참모본부가 계획과 정보 처리를 맡는 참모(staff)를 따로 두면서 현장 지휘(line)와 참모를 나눴고, 1850년대 미국 철도의 대니얼 매캘럼이 최초의 조직도를 그렸으며, 테일러의 과학적 관리가 기능별 피라미드를 굳혔습니다. 저자들의 결론은, 회사가 위계로 자라는 것은 위계가 좋아서가 아니라 사람 말고 정보를 나를 다른 수단이 없었기 때문이라는 것입니다.

언제 쓰고 언제 안 쓰나. 조직 개편을 논의할 때 “이 층은 무슨 정보를 나르고 있나”를 묻는 틀로 씁니다. 안전·규제처럼 명확한 결재 책임선이 법으로 필요한 영역에는 그대로 적용하지 않습니다.

에세이가 든 로마군의 층 구조. 한 리더의 관리 폭이 층 수를 정합니다.

2. Company world model: 회사의 현재 상태를 AI가 늘 최신으로 유지

무엇인가. 지금 무엇을 만들고 있는지, 무엇이 막혀 있는지, 자원이 어디로 가는지, 무엇이 되고 무엇이 안 되는지를 AI가 계속 갱신하는 회사의 모형입니다.

어떻게 작동하나. 입력은 원격 근무 회사에서 이미 남는 기록입니다. 채팅, 메일, 문서, 코드, 설계, 녹화된 회의, 계획과 진행 상황이 여기에 해당합니다. AI가 이를 읽어 업무 항목과 그 상태로 정리하고, 누구든 “지금 이 프로젝트는 어디까지 왔나”, “무엇이 막혀 있나”를 직접 물어볼 수 있게 합니다. 예전에는 관리자가 팀 상황을 알고 그것을 위아래로 전달했는데, 이 역할을 world model이 가져갑니다. 그러면 가장자리에 있는 사람도 관리 층을 거치지 않고 필요한 맥락을 바로 얻습니다.

언제 쓰고 언제 안 쓰나. 업무가 대부분 디지털 기록으로 남는 조직에서 성립합니다. 중요한 결정이 구두나 오프라인 회의에서만 이뤄지는 조직은, 먼저 기록이 남는 방식으로 일하는 습관부터 만들어야 합니다.

Company world model이 관리자의 정보 전달을 대신하는 흐름.

작은 예시 (가상). 생산기술팀 팀장이 매주 금요일 본부장에게 올리던 진행 보고를 없애고, 본부장이 world model에 “이번 주 설비 증설 프로젝트에서 일정이 밀린 항목과 이유”를 직접 묻게 합니다. 답에는 근거가 된 회의록과 이슈 티켓 링크가 붙습니다.

3. Intelligence layer: 고객의 순간을 감지해 해법을 먼저 조합

무엇인가. 고객 데이터에서 특정 순간을 감지하고, 회사가 가진 기능을 조합해 고객이 요청하기 전에 해법을 내미는 계층입니다. 이를 위해 블록은 거래 데이터로 고객별·가맹점별·시장별 customer world model을 따로 만듭니다. 블록은 Cash App으로 구매자를, Square로 판매자와 가맹점 운영 데이터를 보고 있어서 양쪽을 함께 볼 수 있다고 설명합니다.

어떻게 작동하나. 세 단계입니다. 고객 데이터에서 순간을 감지하고, 있는 기능을 조합해 해법을 만들고, 먼저 제안합니다. 에세이의 예는 두 가지입니다. 계절적으로 매출이 꺼지는 시기를 앞둔 식당에는 단기 대출을 만들어, 상환을 결제 흐름에 맞춰 조정하는 조건으로 제안합니다. 다른 도시로 이사한 것으로 보이는 Cash App 사용자에게는 급여 이체 설정, 새 동네에 맞춘 카드 혜택, 바뀐 소득에 맞춘 저축 목표를 묶어 제안합니다.

언제 쓰고 언제 안 쓰나. 고객의 행동 데이터가 충분하고, 조합할 기능이 API처럼 잘게 나뉘어 있을 때 작동합니다. 제안이 고객에게 불이익을 줄 수 있는 금융·의료 분야에서는 규제 검토와 사람 승인을 거치게 해야 합니다.

Intelligence layer의 세 단계와, 조합에 실패했을 때 로드맵이 생기는 구조. 식당 예는 에세이의 사례입니다.

4. 네 가지 building block: 기능, 모형, 지능, 화면

무엇인가. 블록은 회사를 네 층으로 다시 정의합니다. capabilities(결제, 대출, 카드 발급, 뱅킹, 후불 결제, 급여처럼 화면 없이 쪼갠 금융 기능), world model, intelligence layer, interfaces(Square, Cash App, Afterpay, TIDAL, bitkey, proto 같은 전달 화면)입니다.

어떻게 작동하나. 기능은 신뢰성, 규제 준수, 성능으로만 평가합니다. intelligence layer가 이 기능들을 조합해 해법을 만들고, 화면은 그것을 전달하는 통로일 뿐입니다. 저자들은 가치가 화면이 아니라 모형과 지능에 있다고 봅니다. 가장 중요한 연결은 마지막입니다. intelligence layer가 필요한 기능이 없어서 해법을 못 만들면, 그 실패 자체가 무엇을 만들어야 하는지 알려 주는 신호가 됩니다. 제품 관리자의 가설이 아니라 고객의 실제 상황이 백로그를 채우는 셈입니다.

블록의 네 가지 building block. 아래 층의 기능을 위 층이 조합해 화면으로 내보냅니다.

5. IC, DRI, player-coach: 중간 관리자 대신 세 가지 역할

무엇인가. 상시적인 중간 관리층을 없애고, 사람의 역할을 세 가지로 나눕니다.

어떻게 작동하나. IC는 네 building block 중 한 층을 깊이 맡은 전문가로, world model이 주는 맥락을 바탕으로 자기 층 안의 결정을 내립니다. DRI는 여러 팀에 걸친 특정 문제나 고객 결과를 책임집니다. 에세이의 예는 “특정 세그먼트 가맹점의 이탈을 90일 동안 책임지는 사람”이고, DRI는 world model, 대출, 화면 팀에서 필요한 사람과 자원을 끌어올 권한을 가집니다. 문제가 끝나면 계속 맡거나 다른 문제로 옮깁니다. player-coach는 코드나 모형을 직접 만들면서 주변 사람을 키웁니다. 상황 공유는 world model이, 전략과 우선순위는 DRI가 맡으므로 player-coach는 상태 점검 회의와 우선순위 협상에 시간을 쓰지 않습니다. 도시는 팟캐스트에서 이를 “보고 관계”가 아니라 “배정”이라고 표현합니다.

언제 쓰고 언제 안 쓰나. 문제를 명확한 결과 지표와 기간으로 정의할 수 있을 때 DRI 방식이 작동합니다. 에세이는 Spotify(이후 전통적 관리로 되돌아감), Zappos(Holacracy 도입 후 대규모 이탈), Valve(수백 명을 넘으면 확장이 어려움)처럼 앞선 수평 조직 실험이 왜 어려웠는지도 함께 짚습니다. 저자들의 차이점은 사람이 아닌 시스템이 정보를 나른다는 데 있습니다.

중간 관리자의 일이 어디로 옮겨 가는지 정리한 비교.

도시가 팟캐스트에서 밝힌 조직 깊이의 현재와 목표.

통념과 다른 주장

흔히 이렇게 봅니다AI는 직원 한 명 한 명의 생산성을 높이는 도구이고, 조직 구조는 그대로 두면 된다.

저자는 이렇게 봅니다대부분의 기업이 AI를 생산성 도구로만 쓰지만, 진짜 변화는 사람들이 함께 일하는 방식 자체, 곧 정보가 흐르는 구조를 바꾸는 데서 온다.

근거위계는 사람 말고 정보를 나를 수단이 없어서 생겼다는 역사적 분석과, 원격 근무로 업무가 디지털 기록으로 남는 블록이 그 기록으로 world model을 만들 수 있다는 점을 듭니다.

흔히 이렇게 봅니다AI 중심 조직이라면 결국 AI가 결정을 내리게 된다.

도시는 이렇게 봅니다AI는 대부분의 결정을 내리지 않고, 결정에 쓸 맥락을 더 풍부하게 줄 뿐이다. 무엇을 만들지는 고객의 요청이 정하고, 그것이 회사의 전략과 가치에 맞는지는 사람이 판단한다.

근거팟캐스트에서 도시는 AI 출력을 입력이 아니라 정답으로 받아들이며 기본값대로 흘러가는 위험을 직접 언급했고, 보타는 경영진이 목표 함수(성장률, 1인당 매출총이익, NPS 등)를 정하고 가장자리의 사람이 방향을 고친다고 덧붙였습니다.

통념과 저자들의 관점 비교.

저자가 든 사례

블록의 40% 감원 결정

상황	한 일	결과	연결
2025년 말 연휴 동안 경영진이 최신 AI 모델을 써 보며 회사의 모습과 규모가 달라질 것이라고 판단	서비스를 온전히 유지할 최소 인원, 규제 준수에 필요한 최소 인원, 투자자 약속을 지키며 AI 중심으로 재건할 최소 인원의 세 기준으로 규모를 정하고 여유분을 더함	약 1만 명 중 4,000명 이상(약 40%) 감원, 논의에서 실행까지 약 3주. 도시는 계산 실수가 있었다고 인정	메커니즘 5 (조직 재설계의 출발점)

블록의 감원 결정 사례.

슬라이드 대신 프로토타입으로 회의

상황	한 일	결과	연결
회의가 슬라이드 중심으로 진행됨	팀이 시뮬레이션 데이터나 실제 데이터를 넣은 작동하는 프로토타입을 들고 와서 논의	도시는 프로토타입 중심 문화가 슬라이드 회의를 대체했다고 설명. Goose(블록의 에이전트 코딩 도구)와 Claude Code를 언급	메커니즘 5 (IC와 player-coach의 일하는 방식)

프로토타입 회의 사례.

식당의 비수기 대출과 이사한 Cash App 사용자

상황	한 일	결과	연결
계절적 매출 하락을 앞둔 식당 / 다른 도시로 이사한 사용자	대출과 결제 연동 상환을 조합 / 급여 이체·카드 혜택·저축 목표를 조합	고객이 요청하기 전에 먼저 제안 (성과 수치는 원문에서 밝히지 않음)	메커니즘 3, 4

에세이가 든 intelligence layer 사례.

기술 디테일: world model과 intelligence layer를 만들려면

Company world model을 만들려면, 업무 항목의 형식부터 정합니다 (메커니즘 2). 채팅, 메일, 문서, 이슈 티켓, 회의록을 그대로 쌓아 두면 검색은 되지만 “무엇이 막혀 있나”에는 답하지 못합니다. LLM이 각 기록을 읽어 아래 같은 업무 항목으로 정리하고, 같은 항목에 대한 새 기록이 올 때마다 상태를 갱신하게 합니다. 필드 이름은 설계 예시입니다.

{
  "item_id": "PRJ-설비증설-2공장",
  "type": "project",
  "owner": "user:kim.dri",
  "status": "blocked",
  "blocker": { "what": "인허가 서류 보완 요청", "since": "2026-10-20", "waiting_on": "team:legal" },
  "next_milestone": { "name": "설비 반입", "due": "2026-11-15" },
  "resources": ["team:facility", "vendor:V-221"],
  "evidence": ["slack:#plant2/1729381234", "meeting:2026-10-21-weekly", "jira:FAC-382"],
  "updated_at": "2026-10-24T09:12:00+09:00",
  "confidence": 0.82
}

evidence에 근거가 된 원본 기록의 ID를 반드시 남기고, 질문에 답할 때는 이 링크를 함께 보여 줍니다. 근거가 없는 상태 변경은 저장하지 않습니다. 업무 항목은 온톨로지(프로젝트, 팀, 설비, 공급사 같은 개념과 관계)에 연결해 두면, “이 공급사 때문에 막힌 프로젝트 전부”처럼 관계를 따라가는 질문에 답할 수 있습니다.

신선도와 권한을 처음부터 정합니다 (메커니즘 2). 원본 기록은 15~30분 간격으로 읽어 들이고, 업무 항목마다 updated_at을 보여 줘 오래된 정보를 믿지 않게 합니다. 질문한 사람이 원본 기록을 볼 권한이 없으면 그 항목은 답에서 빼고, 인사·보상 채널은 아예 수집 대상에서 제외합니다.

World model이 쓸 만한지 4주 동안 맞비교합니다 (메커니즘 2). 기존 주간 보고를 그대로 두고, 같은 기간 world model이 뽑은 “막힌 항목” 목록과 비교합니다. 사람 보고에 있는 막힌 항목 중 world model이 잡은 비율(재현율)이 90% 이상이고, world model만 잡은 항목 중 실제로 막힌 것의 비율(정밀도)이 80% 이상이 되기 전에는 보고를 없애지 않습니다.

Intelligence layer를 만들려면, 기능 목록을 API처럼 정리합니다 (메커니즘 3, 4). 조합의 재료가 되는 기능마다 이름, 입력, 전제 조건, 규제 제약을 적어 둡니다. LLM은 이 목록 안에서만 조합을 제안하고, 목록에 없는 기능이 필요하면 제안 대신 “기능 공백”을 기록합니다.

{
  "capability": "short_term_loan",
  "inputs": ["merchant_id", "amount", "term_days"],
  "preconditions": ["merchant_age_days >= 180", "no_default_12m"],
  "constraints": ["대출 심사 규정 준수", "고객 동의 필수"],
  "owner_team": "team:lending"
}

{
  "gap_id": "GAP-0142",
  "moment": "가맹점 3곳 이상이 같은 주에 재고 부족 신호",
  "needed_capability": "공급사 공동 발주",
  "occurrences_30d": 47,
  "linked_customers": 31
}

기능 공백은 30일 발생 건수 순으로 정렬해 매월 로드맵 회의의 첫 안건으로 올립니다. 이것이 “조합 실패가 로드맵이 된다”를 실제로 돌리는 방법입니다.

제안은 처음에 사람이 승인하고, 승인 사유를 남깁니다 (메커니즘 3, 통념 2). 첫 3개월은 intelligence layer의 모든 제안을 담당자가 승인·거절하고, 거절할 때는 사유를 한 줄 남깁니다. 승인률이 90%를 넘고 거절 사유가 특정 유형으로 정리된 제안만 자동 발송으로 넓힙니다. 도시가 경고한 “AI 출력을 기본값처럼 받아들이는” 문제를 막으려면, 승인 화면에 근거 데이터와 대안 하나를 함께 보여 줍니다.

현업 실행 디테일: 누가, 언제, 무엇을

사업부 하나에서 12주로 시험합니다. 블록은 회사 전체를 한 번에 바꿨지만, 대부분의 기업은 인원을 줄이기 전에 정보 흐름이 실제로 대체되는지부터 확인하는 편이 안전합니다.

역할	누가	맡는 일
스폰서	사업부장	시범 범위와 목표 지표 승인, 기존 보고 폐지 결정
world model 오너	데이터·AI 리드 1명 + 엔지니어 2명	기록 수집, 업무 항목 추출, 질의 화면, 정확도 측정
DRI	시범 문제마다 1명, 2명	90일짜리 고객 결과 하나를 책임
player-coach 후보	현 팀장 중 2~3명	직접 작업 비중을 늘리고 상태 회의를 줄임
인사·법무	HR 파트너, 법무 담당	역할 정의 변경, 기록 수집 범위와 동의 절차

시작 전에 모을 것. 사업부의 정기 보고와 회의 목록(누가, 얼마나 자주, 누구에게), 각 보고가 실제로 어떤 결정에 쓰이는지, 여러 팀에 걸쳐 있는 고객 문제 후보 5개, 수집할 채널·문서 저장소 목록과 접근 승인입니다.

12주 시범 일정 예시 (2주 단위).

기간	할 일	산출물
1주	정기 보고·회의를 모두 적고, 각각이 나르는 정보와 그 정보를 쓰는 결정을 표로 정리	정보 흐름 지도
2~4주	기록 수집과 업무 항목 추출, “무엇이 막혔나” 질의 화면	world model MVP
3~6주	기존 주간 보고와 world model의 막힌 항목 목록 맞비교	재현율·정밀도 표
5주	고객 문제 2개에 DRI 지정, 결과 지표와 90일 기한 확정	DRI 계약서 1장씩
7주	기준을 넘으면 주간 보고 1개 폐지, 팀장 2~3명을 player-coach로 전환	회의 시간 변화 기록
11~12주	지표 평가, 확대·보류 결정	한 장 보고서

DRI에게 줄 한 장짜리 계약서. 책임질 고객 결과(예: 특정 세그먼트 이탈률), 지금 수치와 90일 목표, 끌어올 수 있는 팀과 인원의 한도, 매주 world model에 남길 진행 기록, 중간 점검 날짜를 적습니다.

확인할 질문.

지금 있는 정기 보고 중, 아무도 그 보고로 결정을 내리지 않는 것은 무엇인가?
world model이 놓친 막힌 항목은 주로 어디서 생겼나(오프라인 회의, 개인 메시지, 기록 안 하는 팀)?
DRI가 다른 팀에서 사람을 끌어올 때 그 팀의 원래 일은 누가 조정하나?
player-coach로 바뀐 팀장이 육성할 시간을 실제로 확보했나, 아니면 실무만 늘었나?

진행 판정 기준 (예시). 막힌 항목 재현율 90% 이상·정밀도 80% 이상, 사업부 전체 상태 점검 회의 시간 40% 이상 감소, DRI 2명 중 1명 이상이 90일 목표의 절반을 달성하면 다른 사업부로 넓힙니다. 인원 조정은 이 기준을 넘긴 뒤 별도로 판단합니다.

AX 프로젝트에 쓸 때. 이 구상의 출발점은 감원이 아니라 world model입니다. 기업 AX에서는 프로세스 마이닝으로 실제 업무 흐름을 보고, 온톨로지로 프로젝트·팀·설비·고객 같은 개념과 관계를 정의한 뒤, 그 위에 업무 기록을 얹으면 회사 단위의 world model이 됩니다. 첫 적용처는 정기 보고가 많은 본사 기획·관리 조직이나, 여러 팀에 걸친 고객 문제(이탈, 클레임, 납기 지연)가 반복되는 사업부가 좋습니다. FDE는 world model과 첫 DRI 문제를 현업과 함께 만들고, 경영진은 보타가 말한 목표 함수(무엇으로 성공을 재는지)를 먼저 정해야 합니다.

AX 맥락에서 원형 조직으로 가는 순서.

원문 사례

항목	내용
영상	티타임즈TV, 2026년 9월 15일, 진행 이재원 기자. 챕터: 블록의 AI 조직 재설계 계획, AI로 조직을 설계하는 법, AI 기반 조직에서 사람의 역할, 아직 시작되지 않은 실험
에세이	Roelof Botha·Jack Dorsey, “From Hierarchy to Intelligence” (Sequoia, 2026년 3월 31일)
팟캐스트	Sequoia “Long Strange Trip” 12회, 진행 Brian Halligan, “Every Company Can Now Be a Mini-AGI”
감원	2026년 2월, 약 1만 명 중 4,000명 이상(약 40%). 기준: 서비스 유지·규제 준수·투자자 약속을 위한 최소 인원 + 여유분. 실행까지 약 3주
역사적 근거	로마군 8→80→480→약 5,000명 층 구조, 프로이센 참모본부(line과 staff 구분), 1850년대 매캘럼의 첫 조직도, 테일러의 과학적 관리, 1959년 매트릭스 조직, McKinsey 7-S
앞선 실험	Spotify(전통 관리로 회귀), Zappos(Holacracy 후 이탈), Valve(수백 명 이상 확장 어려움), Haier rendanheyi
네 가지 building block	capabilities, world model(회사·고객), intelligence layer, interfaces
세 가지 역할	IC, DRI(예: 가맹점 이탈 90일 책임, 팀 간 자원 동원 권한), player-coach
조직 깊이	현재 최대 5층 → 올해 2~3층 목표, 이상적으로는 약 6,000명 모두 CEO 직접 보고
언급한 도구	Goose(에이전트 코딩 도구), Claude Code
저자들이 밝힌 위험	전환은 초기 단계이고 일부는 실패 후 작동할 것, 예측형 world model은 아직 연구 과제, AI 출력을 기본값처럼 받아들이는 위험

핵심 개념

line과 staff: 현장에서 일을 실행하는 조직(line)과 계획·정보 처리로 이를 돕는 조직(staff)의 구분. 프로이센 군대에서 시작해 지금 회사 조직에도 남아 있습니다.
customer world model: 거래 데이터로 만든 고객별·가맹점별·시장별 모형. 원시 거래에서 시작해 원인과 예측까지 다루는 쪽으로 키워 간다는 것이 블록의 계획입니다.
mini AGI: 도시가 쓰는 표현. 회사 전체를 보고 체계가 아니라, 모형으로 만들어 질문할 수 있는 하나의 지능 시스템으로 본다는 뜻입니다.
목표 함수: 조직이 무엇을 최대화하려는지 정한 기준. 보타는 성장률, 1인당 매출총이익, NPS(고객 추천 지수)를 예로 들었습니다.
economic graph: 블록이 가진 가맹점과 소비자 사이의 거래 관계망. 저자들은 시간이 지날수록 쌓이는 블록의 핵심 자산으로 봅니다.

내 메모

TODO: 내 생각 추가

원문은 티타임즈TV의 영상 「AI가 조직의 중심, 사람은 가장자리에서 일한다는 잭 도시」입니다. 영상 자막을 직접 읽지 못해, 영상이 다룬 Roelof Botha·Jack Dorsey의 에세이 “From Hierarchy to Intelligence”(Sequoia), Sequoia 팟캐스트 “Every Company Can Now Be a Mini-AGI”, 감원 관련 보도를 함께 참고했습니다. 요약·메커니즘·사례는 이 자료들의 내용을 AX Review가 다시 정리한 것이고, 기술·현업 실행 디테일, JSON 설계 예시, 12주 시범 일정, 인포그래픽, 표는 새로 작성했습니다.