Block은 3,500명을 안 가르쳤다 — 50명으로 조직 전체를 자율화한 AI 챔피언 전략

원문: https://www.youtube.com/watch?v=0yuMz3_4Gns
채널: AgentOS | 길이: 11:16 | 처리일: 2026-07-14

---

0. 맥락: 헤드라인과 그 뒤에 숨겨진 이야기

0-1. 발단

• 2026년 2월, CNN 비즈니스 헤드라인: "블록이 AI 때문에 직원을 절반 가까이 해고했다. CEO는 대부분의 회사가 똑같이 하게 될 거라고 말했다."
• 이 헤드라인이 나오기 몇 달 전, Block에서 이 전환을 처음부터 끝까지 설계한 Anji Jones가 전 과정을 발표로 공개했다.
• Block은 Jack Dorsey의 Square, CashApp, Afterpay를 운영하는 회사다.

0-2. Block의 조기 출발

• LM이 툴 콜링(AI가 직접 도구를 쓰는 기능)을 지원하기도 전부터 자체 코딩 에이전트 Goose를 만들고 있었다.
• MCP(Model Context Protocol)가 나올 때 Anthropic의 디자인 파트너로 초기 설계에 참여했다.
• Goose가 MCP 클라이언트의 **레퍼런스 구현(공식 모범 사례)**이었다.

---

1. 핵심 문제 발견: 실험 → 도입 → 임팩트는 다르다

1-1. 표면적 성공, 실질적 실패

• Anji Jones는 2025년 상반기 마케팅·법무·재무까지 전사 12,000명의 AI 도입을 총괄했다.
• 이후 CTO로부터 미션 수령: "엔지니어링 조직 전체를 에이전트 기반으로 바꿔라"
• 도입 몇 달 만에 엔지니어의 90%가 Goose와 Claude Code를 일상적으로 사용 → 서류상 완벽한 성공.
• 그런데 CEO는 정반대로 확신: "우리 엔지니어들 AI 안 쓰고 있는 게 분명하다" — 기능이 나가는 속도가 그대로였기 때문.

1-2. 둘 다 맞았다 — 이것이 진짜 문제

• 수치상 90% 사용은 맞고, 고객에게 기능이 나가는 속도가 그대로라는 CEO 감각도 맞았다.
• 3단계 구분:
  1. 실험: AI를 써보게 만들기
  2. 도입: 다 같이 쓰게 만들기
  3. 임팩트: 성과로 이어지기 ← 완전히 다른 단계
• 블록은 도입까지는 성공했지만, 다들 IDE 안에서 질문하고 보일러플레이트 코드만 만드는 수준에 멈춰 있었다.

---

2. 6단계 성숙도 모델: AI 실력이 아닌 에이전트와의 관계 측정

단계	정의
0단계	AI 아예 안 쓰는 상태
1단계	자동 완성만 쓰는 상태
2단계	채팅은 하지만 PR(실제 코드 반영)까지는 안 가는 상태
3단계	작업을 통째로 맡기고 결과를 검수
4단계	에이전트 여러 개를 동시에 운영
5단계	사람이 안 붙어 있어도 배포 가능한 결과물이 나오는 상태

• 블록의 3,500명 대부분이 1~2단계 사이였다.
• 목표: 전원 5단계

---

3. 3,500명을 가르치지 않고 50명을 선택한 이유

3-1. 상황의 어려움

• 참고할 플레이북이 없었다.
• 이번 주 베스트 프랙티스가 다음 주에 구식이 됐다.
• 조직은 AI 필요감이 이미 누적되어 있었고, "AI 아니면 도태"라는 톱다운 압박에 사람들이 이미 지쳐 있었다.

3-2. 1-9-90 법칙 적용

• 온라인 커뮤니티에서 콘텐츠를 만드는 사람은 1%, 댓글 달고 반응하는 사람이 9%, 보기만 하는 사람이 90%.
• 엔지니어의 AI 적응도 정확히 이 분포를 따른다 — AI 전략이 개인 레벨업에 의존하면 절대 임팩트를 볼 수 없다.

3-3. AI 챔피언 50명 선발 방식

• 자원자를 받은 것이 아니다 — 일주일 동안 테크리드·매니저들을 만나서 지명했다.
• 선발 조건 3가지:
  1. 업무 시간의 30% 이상을 여기에 쓸 수 있을 것
  2. AI가 뜻대로 안 될 때 포기하지 않을 것 (실제로 자주 안 됐다)
  3. 회사에서 가장 중요한 저장소들을 대표할 것 — Square, CashApp, Afterpay부터 프론트, 백엔드, 모바일, 인프라까지 전부

---

4. 50명이 제일 먼저 한 일: 사람이 아닌 저장소를 바꾸다

4-1. 왜 저장소가 핵심인가

• 2025년 중반 모델들은 기능 하나는 짜줬다.
• 하지만 팀의 컨벤션, 코드 스타일, 하면 안 되는 것들을 몰라서 결과물을 믿을 수 없고, 못 믿으니까 일을 못 맡겼다.
• 막혀 있던 건 모델 성능이 아니라 신뢰였다.

4-2. AI 친화적 저장소(AI-Friendly Repository) 4가지 구성 요소

1. 컨텍스트 파일 — agents.md, claude.md 같은 저장소 안내서
2. 규칙 파일 — 에이전트가 넘지 말아야 할 가드레일
3. 슬래시 커맨드 + 스킬 — 반복 작업을 담은 자동화 도구
4. AI 코드 리뷰어 + PR AI 작성 표시 — 코드 리뷰에 AI 통합, PR에 AI 작성 명시

4-3. 왜 이게 강력한가

• 저장소는 팀 전원이 매일 지나다니는 길목이다.
• 1%가 여기에 지식을 심어두면, 나머지 90%는 아무것도 안 배워도 그냥 혜택을 받는다.
• 개인의 실력을 올리는 것이 아니라 팀의 바닥을 올리는 것이다.

4-4. 수렴의 패턴

• 위에서 표준을 강제로 내려보낸 것이 아니라, 챔피언마다 자기 저장소에 맞는 것을 찾게 했더니 비슷한 팀끼리 알아서 같은 패턴으로 수렴했다.
• 모노레포: 루트에 공통 컨텍스트, 서비스별 세부 규칙을 상속
• 웹 vs 모바일: 아예 접근 방식을 다르게 설계

---

5. 위임의 입구를 만들다: 일이 들어오는 3곳에 에이전트를 심다

5-1. 엔지니어에게 일이 들어오는 3가지 입구

1. Jira 같은 이슈 트래커
2. GitHub 이슈
3. Slack

5-2. Slack 안에서 버그 수정 5분 완료 — 실제 사례

1. 엔지니어 1이 Slack에서 버그 발견 공유
2. 엔지니어 2: "나도 못 봤어"
3. 엔지니어 3: Slack 안에서 Goose 호출 → "이 버그 본 적 있어? 확인해줘"
4. Goose: 저장소 접근 → "맞음, 여기 버그. 구현 방법 3가지 옵션"
5. 엔지니어 1, 2: "옵션 1 좋아"
6. 엔지니어 3: "Goose, 옵션 1 구현해줘"
7. Goose: 구현 완료 → PR 링크 반환

• 버그 발견부터 수정 PR까지 5분, 전부 Slack 안에서 완료.

5-3. 에이전트가 스프린트 멤버가 되다

• 에이전트가 스프린트 정식 멤버로 투입되자, 팀이 할 일이 넘쳐서 티켓을 두 번이나 더 당겨왔다.
• 이것이 성공처럼 보이지만 — 백로그가 비워지는 속도 = 같은 일에 필요한 사람이 줄어드는 속도다.

---

6. 4단계: 병렬 에이전트와 두 가지 병목

6-1. 코드 리뷰 병목 → 자동 수정 루프

• 위임이 되는 조직에서 에이전트 개수를 늘리는 건 거의 공짜였다.
• 그러자 병목이 이동: 한 사람이 PR을 쏟아내니 코드 리뷰가 밀려서 터졌다.
• 해법: Codex 리뷰어를 전체 저장소에 켜고, 리뷰어가 문제를 지적하면 또 다른 에이전트가 자동으로 수정해서 커밋 — 자동 수정 루프 구성.
• 사람이 PR을 열어볼 때쯤엔 웬만한 지적 사항이 이미 정리된 상태.
• AI 리뷰어를 초반엔 강제로 켜지 않았다 — 초기엔 리뷰 품질이 너무 형편없어서 엔지니어들 화만 뒀기 때문. 저장소가 준비되고 모델이 좋아진 다음에야 켰다. 순서가 있었다.

6-2. 하드웨어 병목 → 클라우드 작업 공간

• 에이전트를 4~5개씩 돌리니 노트북 메모리와 CPU가 버티지 못했다.
• 에이전트마다 격리된 클라우드 작업 공간을 하나씩 제공하는 데 투자 → 어디서든 병렬로 구동 가능.

6-3. 3개월 챔피언 프로그램 성과

• AI가 작성한 코드 69% 증가
• 엔지니어가 체감한 시간 절약 37% 증가
• 자동으로 만들어진 PR 21배

---

7. 5단계: 오케스트레이터와 회사 전체 지도

7-1. 빌더봇(Builderbot)

• 에이전트가 많아지자 이를 지휘할 오케스트레이터 빌더봇을 직접 만들었다.

7-2. 회사 전체 지도 (25,000개 저장소 분석)

• 저장소 25,000개를 전부 분석해서 어떤 서비스가 어디 있고 뭐가 뭐에 의존하는지 기계가 읽을 수 있는 형태로 만들었다.
• 에이전트 여러 대가 시스템 곳곳을 병렬로 탐색하고, 오케스트레이터가 그것을 모아 여러 코드베이스에 걸친 실행 계획을 짠다.

7-3. 진짜 자율화 달성

• 이제 엔지니어가 아니어도, GitHub 계정이 없어도 회사의 누구든 Slack에서 빌더봇을 불러 버그를 고치고 기능을 만들 수 있게 됐다.
• 발표자 표현: "꿈 같았다. 그러나 그것이 악몽이 됐다."

---

8. 결말: 꿈이 악몽이 되는 순간

8-1. 발표의 마지막 1분

• 그리고 그 헤드라인이 나왔다: 블록이 AI 때문에 직원을 절반 가까이 해고.
• 발표는 답 없이 질문 3개로 끝났다:
  • "우리는 지금 무엇을 하고 있는가?"
  • "우리는 어디로 향하고 있는가?"
  • "그것이 우리가 원하는 목적지가 맞는가?"

8-2. 기술적 성공이 인간적 재난이 되는 구조

• 아까 티켓을 두 번 더 당겨오던 스프린트 — 그것이 정확히 "더 적은 사람으로 더 많은 결과를 낸다"는 문장이 현실이 되는 장면이었다.
• 교과서에서 아는 것과 내가 몇 년을 갈아 넣은 프로젝트의 결과로 눈앞에서 보는 것은 완전히 다른 얘기다.

---

9. 거시적 맥락: 이건 블록 하나의 얘기가 아니다

9-1. Dario Amodei의 발언 재해석

• Anthropic CEO Dario Amodei가 파이낸셜 타임즈 인터뷰에서: "향후 5년 안에 초급 사무직의 절반이 자동화될 수 있다"
• 이것이 예언이 아니라 그냥 관찰이었을 수 있다 — Fable 모델을 무제한으로 쓰는 내부자의 눈에는.

9-2. 모델 가격의 하락 곡선

모델	입력 단가	출력 단가
Opus 4.1	$75/M	높음
Fable 5 (현재 최상급)	$10/M	$50/M
Opus 4.5	$5/M	$25/M

• 최상의 모델인데 전 세대 출시가보다 싸다 — 성능은 올라가는데 단가는 세 대마다 내려온다.
• "비싸서 아무나 못 쓴다"는 반론이 오래 못 갈 이유.

9-3. OpenAI 서울 공고

• 현재 OpenAI 채용 페이지에 서울 공고: "Forward Deployed Engineer (전방 배치 엔지니어)"
• 역할: 가장 전략적인 고객사 곁에서 최신 모델을 실제 운영 시스템에 배포하는 전 과정을 이끄는 것.
• 성공 기준: 측정 가능한 업무 임팩트 — 한국 기업의 병목에 AI를 밀어넣는 게 직업이고, 그 임팩트의 다른 이름이 블록에서 본 그 효율이다.

---

10. 6단계 진단: 여러분 팀은 지금 몇 단계인가

단계	질문
0	AI를 전혀 쓰지 않는가?
1	자동 완성만 쓰는가?
2	채팅은 하지만 PR까지 안 가는가?
3	작업을 통째로 맡기고 결과를 검수하는가?
4	에이전트 여러 개를 동시에 돌리는가?
5	사람 없이도 배포 가능한 결과물이 나오는가?

• 대부분은 1~2단계 사이다.
• 이 전환을 당하는 쪽이 아니라 아는 쪽, 대비하는 쪽이 되기 위한 시작은 지금 내 위치를 아는 것이다.

---

핵심 요약 (20줄)

1. 2026년 2월, Block(Square/CashApp)이 AI로 인해 직원 절반 가까이 해고했다는 헤드라인이 나왔다.
2. 이 헤드라인의 배경에는 Anji Jones가 2년간 설계한 3,500명 엔지니어링 조직 AI 전환의 전 과정이 있다.
3. 핵심 교훈: 실험(써보게 만들기) → 도입(다 같이 쓰게 만들기) → 임팩트(성과로 이어지기)는 완전히 다른 단계다.
4. 90%가 AI를 써도 고객에게 기능이 나가는 속도가 그대로였다 — 사용량과 성과 사이의 간극이 핵심 문제였다.
5. 6단계 성숙도 모델은 AI 실력이 아닌 에이전트와 엔지니어의 관계로 측정한다 (0=미사용 → 5=완전 자율).
6. 1-9-90 법칙: 에이전트를 적극 활용하는 1%, 반응하는 9%, 보기만 하는 90% — AI 전략이 개인 레벨업에 의존하면 임팩트 없다.
7. 해법: 3,500명을 교육하는 대신 50명 AI 챔피언을 지명했다 — 자원자 모집이 아닌 직접 지명.
8. 챔피언 선발 조건: 업무 시간 30% 투입 가능 + 실패해도 포기 안 함 + 핵심 저장소 대표.
9. 챔피언들이 제일 먼저 한 일은 교육이 아니라 저장소를 AI 친화적으로 바꾸는 것이었다.
10. AI 친화적 저장소 4요소: 컨텍스트 파일(agents.md) + 규칙 파일(가드레일) + 슬래시 커맨드/스킬 + AI 코드 리뷰어.
11. 저장소는 팀 전원이 매일 지나는 길목 — 1%가 심어두면 90%는 아무것도 안 배워도 혜택을 받는다.
12. 세 가지 업무 입구(Jira, GitHub, Slack) 모두에서 새 도구 배움 없이 에이전트에게 즉시 일을 넘길 수 있게 만들었다.
13. Slack 안에서 Goose 호출 → 버그 발견부터 수정 PR까지 5분 완료가 표준이 됐다.
14. 에이전트를 스프린트 멤버로 넣자 할 일이 넘쳐 티켓을 두 번이나 더 당겨왔다 — 이것이 고용 감소의 신호였다.
15. 4단계에서 두 가지 병목: 코드 리뷰 과부하(자동 수정 루프로 해결) + 하드웨어 부족(클라우드 작업 공간 투자).
16. AI 리뷰어는 저장소가 준비되고 모델이 좋아진 다음에야 켰다 — 순서가 핵심이다.
17. 5단계: 오케스트레이터 빌더봇 + 25,000개 저장소 지도 → 엔지니어 아닌 누구든 Slack에서 버그 수정/기능 추가 가능.
18. 결말: 꿈이 악몽이 됐다 — Dario Amodei의 "초급 사무직 절반 자동화"는 예언이 아니라 관찰이었을 수 있다.
19. 모델 가격은 세 대마다 내려간다 — Fable 5는 현재 최상급이면서 Opus 4.1 출시가보다 싸다.
20. 전환을 당하는 쪽이 아닌 아는 쪽에 서기 위한 시작은 6단계 표에서 내 팀의 위치를 확인하는 것이다.