Field Log · Entry

AI 사용률 90%인데 출시는 빨라지지 않았다: Block의 Stage 5와 그 대가 (7/7)

AI 사용 확산에서 저장소 준비 업무 위임 병렬 agent review cloud workspace company world model을 거쳐 Block Stage 5 조직과 인간 역할 질문으로 이어지는 과정

이번 글의 결론

Block에서는 약 90%의 engineer가 coding AI를 쓰고도 출시 속도가 빨라지지 않았습니다. 사용률은 impact가 아니었습니다.

전환의 시작은 model 교체가 아니라 50명의 AI Champions가 핵심 repository를 agent가 일할 수 있게 만드는 일이었습니다.

위임이 늘자 다음 병목은 code review와 laptop 자원이 됐고, agent reviewer와 격리 cloud workspace가 필요해졌습니다.

Stage 5에는 개별 repo 지식만으로 부족했습니다. 25,000개 repo의 service·dependency를 읽는 company world model과 Builderbot이 등장했습니다.

기술적 성공 직후 대규모 구조조정이 이어졌습니다. 발표는 둘의 단순 인과를 증명하지 않지만, 자동화의 이익과 비용을 누가 갖는지 묻습니다.

Agent 시대에도 경험은 저절로 쌓이지 않습니다. 문제 분해·환경 설계·검증 능력을 키우는 동시에, 직접 구현하고 실패를 추적하는 의도적 훈련을 남겨야 합니다.

앞의 6편에서는 Hermes와 OpenClaw를 한 workflow부터 구축하고 최적화했습니다. 마지막 편은 같은 원리를 조직 규모로 확장합니다.

이 글의 중심 자료는 Angie Jones의 2026년 발표 Building an Autonomous Engineering Org 녹취입니다. Repo readiness와 Champions program은 Block Engineering의 공식 글, Builderbot의 reviewer 역할은 후속 공식 글로 교차 확인했습니다.

자료 사이에는 세부 시점 차이가 있습니다. 발표 녹취는 program 시작을 2025년 중반으로 회고하고, Block Engineering 글은 2025년 8월이라고 적습니다. 이 글은 정확한 시작 월보다 실험 → repository 준비 → 위임 → 병렬화 → orchestration의 순서에 초점을 맞춥니다.

1. 90%가 AI를 쓰는데 왜 출시는 그대로였나

Block은 AI agent를 늦게 도입한 회사가 아니었습니다. 내부 coding agent Goose를 일찍 만들었고 MCP 초기 설계에도 참여했습니다. 발표 시점의 회고에 따르면 engineer 약 90%가 Goose나 Claude Code 같은 도구를 정기적으로 사용하고 있었습니다.

그런데 CEO가 본 사업 결과는 달랐습니다.

IDE 안 AI 사용 증가
code suggestion 증가
boilerplate 생성 증가

하지만

제품 출시 속도는 체감상 그대로

문제는 AI가 코드를 한 줄 더 빨리 쓰게 했지만, idea가 production에 도달하는 전체 flow는 바꾸지 못했다는 데 있었습니다.

Experimentation
  도구를 시험한다
        ↓
Adoption
  많은 사람이 자주 쓴다
        ↓
Impact
  고객 가치와 조직 outcome이 개선된다

Block은 Adoption에는 도달했지만 Impact를 증명하지 못했습니다. 이 구분은 개인 agent 운영에도 같습니다. Telegram에서 하루 50번 대화했다는 사실은 완료된 업무가 50개라는 뜻이 아닙니다.

2. Agentic Engineering은 AI가 code를 많이 쓰는 상태가 아니다

발표가 제시한 정의에서 engineer의 기본 역할은 다음처럼 바뀝니다.

문제와 제약을 이해한다
→ 검증 가능한 단위로 분해한다
→ agent에게 위임한다
→ 여러 작업과 의존성을 조율한다
→ 결과와 증거를 검토한다
→ production 책임을 진다

직접 typing하는 시간이 줄 수는 있습니다. 그러나 “요청 한 줄을 던지고 결과를 믿는 사람”이 목표는 아닙니다. 일이 성공할 수 있는 system을 설계하고 최종 판단을 책임지는 engineer에 가깝습니다.

이 정의에는 중요한 긴장이 있습니다.

구현을 직접 덜 해도 system 이해는 더 깊어야 함
agent를 더 많이 돌려도 review 기준은 더 엄격해야 함
속도가 빨라져도 customer outcome을 따로 측정해야 함
자율성을 높여도 책임 주체는 흐려지면 안 됨

3. 발표의 Stage 0~5 성숙도 Model

Stage	Engineer와 AI의 관계	관찰 가능한 산출물
0	AI를 사용하지 않음	기존 수작업 flow
1	autocomplete 중심	code suggestion
2	agent와 대화하지만 PR은 만들지 않음	설명·snippet·진단
3	task를 위임하고 결과를 review	agent-generated PR
4	여러 agent를 병렬 실행	동시 작업·PR 증가
5	complete task를 위임	사람의 단계별 안내 없이 shippable result

Stage 5를 “사람 없이 자동 deploy”로 읽으면 과장입니다. 발표의 핵심은 agent가 step-by-step handholding 없이 배포 가능한 수준의 결과를 만든다는 뜻입니다. Security·compliance·merge approval 같은 조직 governance가 사라진다는 뜻은 아닙니다.

당시 대다수 engineer는 Stage 1~2에 있었고 목표는 Stage 5였습니다. 한꺼번에 3,500명을 교육하는 방식 대신 다른 전략을 택했습니다.

4. 3,500명 전원 교육 대신 1%를 만든다

Jones는 online community의 1-9-90 법칙을 AI adoption에 적용했습니다.

1%   새 pattern을 만든다
9%   pattern을 적극 적용하고 고친다
90%  검증된 기본값을 사용한다

여기서 90%는 수동적인 사람을 낮춰 부르는 말이 아닙니다. 모든 engineer에게 빠르게 변하는 model·tool·prompt를 각자 연구하게 하면 중복 실험과 AI fatigue가 커진다는 조직 설계 판단입니다.

Block은 핵심 team과 repository를 대표하는 약 50명의 engineer를 AI Champions로 골랐습니다. 공개 자원봉사 모집이 아니라 manager·tech lead와 함께 전략적으로 선발했습니다.

선발 조건:

업무 시간의 최소 30%를 AI enablement에 쓸 수 있음
model의 비결정성과 실패에 쉽게 포기하지 않음
중요한 repository와 다양한 기술 stack을 대표함
개인 productivity hack이 아니라 team pattern으로 남길 수 있음

Block Engineering 글에 따르면 web·backend·mobile·hardware·data·infra, 작은 service부터 거대한 monorepo까지 범위를 의도적으로 섞었습니다. 한 stack에서만 잘되는 방법을 전사 표준으로 착각하지 않기 위해서입니다.

5. 가장 먼저 한 일은 repository readiness였다

Stage 2에서 3으로 가는 장벽은 model이 feature code를 전혀 못 쓰는 데 있지 않았습니다. Team convention과 architecture를 모르기 때문에 engineer가 결과를 신뢰하지 못했습니다.

Champions가 repository에 심은 asset은 다음과 같습니다.

AGENTS.md / context file
  build·test·architecture·convention

Rules
  허용·금지·security·style

HOWTOAI.md
  사람이 이 repo에서 agent를 쓰는 방법

Commands / Skills
  반복 workflow와 검증 절차

AI reviewer
  machine-generated change의 pre-review

Attribution
  어떤 change가 AI 도움을 받았는지 추적

Monorepo는 root 공통 규칙과 하위 service 규칙을 계층화했습니다. Web에서 잘되는 context pattern을 Android·iOS·JVM에 무리하게 강제하지 않았습니다.

이 시리즈의 Hermes·OpenClaw 편과 정확히 연결되는 지점입니다.

좋은 agent를 사오는 것보다, agent가 탐색·수정·검증할 수 있는 repository를 만드는 일이 먼저다.

AGENTS.md 하나만 추가한다고 readiness가 완성되지는 않습니다. Build가 깨져 있고 test가 flaky하며 owner가 없고 production feedback이 늦다면, agent는 그 혼란을 더 빠르게 증폭합니다.

6. Agent를 새 도구가 아니라 기존 업무 flow 안에 넣었다

Repository가 준비된 뒤 위임 입구를 사람들이 이미 쓰는 곳에 넣었습니다.

Slack
Jira / Linear
GitHub Issues

발표의 Slack 사례는 이렇습니다.

Engineer가 channel에서 bug를 논의
Goose가 repository를 조사해 실제 원인 위치를 찾음
해결 option 세 가지와 code snippet을 제시
사람들이 option 하나를 선택
Goose가 구현하고 PR link를 반환

진단·합의·구현·PR까지 약 5분이 걸렸다고 발표자는 설명합니다. 중요한 것은 “5분”이라는 demo 숫자보다 AI가 IDE라는 별도 섬에 있지 않았다는 점입니다.

사람이 agent tool의 새 UI를 배우는 대신, agent가 Slack·ticket·issue라는 기존 coordination surface로 들어왔습니다. Champions가 repository context를 미리 준비했기 때문에 다른 engineer는 고급 prompt 기법을 몰라도 위임할 수 있었습니다.

7. 3개월 후 지표: 크지만 Impact의 최종 증거는 아니다

발표는 Champions program 약 3개월 뒤 다음 변화를 보고합니다.

AI-authored code       +69%
reported time savings  +37%
automated PR           21배

이 숫자는 adoption과 throughput의 강한 신호입니다. 하지만 다음을 직접 증명하지는 않습니다.

고객에게 가치 있는 feature가 69% 늘었는가
lead time이 37% 줄었는가
defect·incident가 줄었는가
revenue·retention·사용자 만족이 올랐는가
engineer의 장기 역량과 만족이 좋아졌는가

발표의 시작 자체가 “AI 사용량은 많지만 출시는 빨라지지 않았다”였습니다. 그러므로 code와 PR 증가를 최종 outcome으로 다시 착각하면 같은 오류를 반복합니다.

조직 dashboard에는 적어도 다음 chain이 함께 있어야 합니다.

AI usage
→ accepted change
→ review time
→ merge lead time
→ deploy frequency
→ change failure / rollback
→ customer outcome

8. Stage 4에서 새 병목이 나타났다

한 engineer가 여러 agent를 병렬 실행하자 생성 속도는 더 빨라졌습니다. 동시에 사람과 laptop이 병목이 됐습니다.

Code review 병목

발표에 따르면 PR output이 약 3배로 늘면서 human reviewer가 따라가지 못했습니다.

agent가 PR 생성
→ AI reviewer가 issue 발견
→ agent가 issue를 자동 수정
→ 정리된 diff와 evidence를 사람에게 전달
→ 사람이 최종 review

목표는 사람을 review에서 제거하는 것이 아니라, typo·명백한 rule 위반·반복 수정 같은 noise를 먼저 걷어내 사람이 architecture·product risk·trade-off에 집중하게 하는 것입니다.

Block의 후속 글 Protecting Our Systems with Intelligence는 Builderbot reviewer가 local module뿐 아니라 전사 architecture·security·operation constraint와 change를 비교하고, 인간이 마지막 승인자가 되는 방향을 설명합니다.

Local compute 병목

Agent 네댓 개가 동시에 repository를 checkout하고 build·test를 돌리자 laptop memory와 CPU가 부족해졌습니다. 해결은 prompt tuning이 아니라 agent마다 격리된 cloud workspace를 주는 것이었습니다.

필요한 운영 요소:

isolated filesystem
compute quota
dependency cache
branch / worktree isolation
secret scope
timeout / cancellation
artifact and log retention
concurrency control

Multi-agent는 model API 호출 횟수를 늘리는 기능이 아니라 distributed build system과 비슷한 infrastructure 문제입니다.

9. Stage 5: Builderbot과 Company World Model

Block에는 약 25,000개의 repository가 있었습니다. Agent 하나가 자기 repo를 잘 안다고 해서 여러 product에 걸친 feature를 설계할 수는 없습니다.

그래서 machine-readable한 company world model을 만들었습니다.

어떤 service가 존재하는가
각 service는 어느 repository에 있는가
service owner는 누구인가
service 사이 dependency는 무엇인가
어떤 API와 data가 연결되는가
한 change가 어디까지 영향을 주는가
어떤 global policy를 지켜야 하는가

여기서 world model은 LLM weight 하나를 뜻하지 않습니다. 조직의 system topology와 policy를 agent가 query할 수 있는 형태로 만든 knowledge layer에 가깝습니다.

Builderbot은 이 context를 사용해 여러 agent에게 탐색을 나눕니다.

사용자 task
  → Builderbot이 영향 영역 탐색
  → 여러 agent가 codebase를 병렬 조사
  → 각 agent가 local plan과 evidence 반환
  → Builderbot이 cross-repo plan으로 결합
  → 구현·review·검증 workflow 조율

이 단계에서는 engineer뿐 아니라 다른 직원도 Slack에서 Builderbot을 mention해 bug fix나 feature를 요청할 수 있었다고 발표는 설명합니다.

10. 기술적 성공 뒤의 구조조정

발표의 마지막은 성공 metric으로 끝나지 않습니다. Stage 5에 도달한 직후 Block의 대규모 구조조정이 이어졌고, Jones는 자신이 만든 enablement가 동료의 해고에 영향을 준 것은 아닌지 자문합니다.

두 사실을 분리해서 봐야 합니다.

공식적으로 확인되는 사실

Block은 2026년 공식 conference recap에서 workforce를 40% 넘게 줄이는 restructuring을 설명했고, 약 2년간의 운영 현대화·management layer 축소와 함께 AI·automation tooling을 더 빠르고 lean한 조직을 가능하게 한 중심 요소로 제시했습니다. Block 공식 설명

발표자가 던진 질문

Jones는 agent로 사람들이 놀라운 일을 하게 만든 것이 결국 그들의 dismissal과 연결된 것은 아닌지 묻습니다. 이것은 성공을 이끈 당사자의 윤리적·개인적 성찰입니다.

이 발표만으로 증명되지 않는 것

Champions program의 특정 자동화가 특정 인원의 해고를 직접 야기했다는 causal chain은 발표에서 입증되지 않습니다. 조직 재편에는 strategy·cost·management structure·market pressure 같은 요인이 함께 작동합니다.

그러나 Block 스스로 AI와 automation을 leaner restructuring의 중심 요소로 설명한 이상, 둘을 완전히 무관한 사건처럼 분리하는 것도 정직하지 않습니다.

질문은 남습니다.

생산성 이익은 고객·주주·직원에게 어떻게 배분되는가?
절약된 시간은 더 나은 일과 학습으로 돌아오는가?
아니면 같은 output을 더 적은 사람에게 요구하는가?
자동화를 만든 사람은 그 조직 결과에 어떤 책임이 있는가?

11. 내 기술적 경험이 쌓이지 않는다는 불안

Agent에게 구현을 맡기면 두 문장이 동시에 참일 수 있습니다.

더 큰 문제를 더 빨리 해결한다.
직접 부딪쳐 얻던 일부 감각은 덜 쌓인다.

“이제 coding은 필요 없다”도 과장이고, “문제 분해도 coding과 완전히 같은 경험이다”도 과장입니다. 경험의 종류가 바뀌지만 자동으로 상위 skill이 생기지는 않습니다.

Agent가 대신하기 쉬운 경험

API 문법을 찾고 첫 implementation을 만드는 반복
boilerplate와 routine refactor
익숙한 test·format·migration 절차

더 중요해지는 경험

문제를 독립 task와 dependency로 나누는 능력
repository context와 tool contract 설계
실패 trajectory에서 원인을 분류하는 능력
test oracle과 release gate 설계
여러 system change의 영향 범위 판단
결과를 거부할 taste와 domain judgment

하지만 두 번째 목록은 agent를 호출하기만 한다고 생기지 않습니다. 의도적 학습 loop가 필요합니다.

12. Deskilling을 막는 개인 운영 규칙

1. 위임 전 10분 설계

Agent 답을 보기 전에 직접 씁니다.

내가 예상한 root cause
바뀔 가능성이 큰 파일
필수 test
가장 위험한 failure
완료 조건

결과와 내 예측의 차이가 학습 자료가 됩니다.

2. “설명 가능한 merge” gate

Diff를 merge하기 전에 다음 질문에 답하지 못하면 agent에게 다시 설명을 요구하거나 직접 조사합니다.

왜 이 abstraction이 필요한가
어떤 invariant가 바뀌었는가
왜 test가 failure를 잡는가
rollback은 무엇인가
다른 option을 버린 이유는 무엇인가

3. 새로운 domain은 처음 한 번 직접 구현

처음 접하는 protocol·framework·failure mode는 최소 vertical slice를 직접 만듭니다. 두 번째 반복부터 agent에게 넘기면 review할 기준이 생깁니다.

4. 실패 한 건을 code까지 추적

매주 agent failure 하나를 골라 prompt 수정으로 덮지 말고 source·runtime·test까지 파고듭니다.

잘못된 결론
→ 잘못 읽은 evidence
→ 잘못 선택한 tool
→ 부족한 context 또는 code defect
→ 재현 test
→ 수정

5. No-agent 연습 시간을 남긴다

업무 전체를 수동으로 되돌릴 필요는 없습니다. 주당 일정 시간을 정해 작은 feature·debugging·algorithm을 직접 끝냅니다. 비율보다 중요한 것은 calendar에 실제로 보호하는 것입니다.

6. 내 이름으로 결정 log를 쓴다

Agent summary를 그대로 저장하지 않고, 내가 이해한 trade-off와 선택 이유를 짧게 다시 씁니다. 나중에 같은 문제가 왔을 때 이 log가 진짜 경험 자산이 됩니다.

13. 조직은 생산성과 역량을 함께 측정해야 한다

Agent program dashboard에 code volume만 있으면 잘못된 행동을 유도합니다.

영역	측정 예
고객 가치	adoption, retention, task success, revenue·cost outcome
Delivery	lead time, deploy frequency, review time
품질	change failure, rollback, escaped defect, security finding
Agent 효율	accepted PR, cost per accepted change, retry, human correction
사람의 역량	incident ownership, design explanation, onboarding, skill growth
사람의 지속 가능성	workload, interruption, satisfaction, psychological safety
분배	절약된 시간·보상·고용 안정이 누구에게 돌아가는가

AI-authored code percentage가 오르면서 design 이해도와 incident 대응력이 떨어질 수도 있습니다. 둘을 함께 보지 않으면 단기 throughput을 장기 fragility와 교환합니다.

14. 이 시리즈를 하나의 식으로 닫는다

Hermes와 OpenClaw를 설치하며 시작한 이야기는 Block에서 같은 결론으로 확장됩니다.

AI tool 보급
≠ 생산성

운영 가능한 impact
= task contract
+ context와 repository readiness
+ 최소 권한 tool
+ memory와 skill
+ verification과 review
+ isolated execution
+ observability와 recovery
+ 명확한 인간 책임

개인에게는 AGENTS.md, Skill, sandbox, cron이었던 것이 조직에서는 repository 표준, workflow integration, AI reviewer, cloud workspace, company world model이 됩니다.

규모만 달라졌을 뿐 원리는 같습니다.

마지막 질문

발표자는 성공 story의 끝에서 세 질문을 남깁니다.

우리는 지금 무엇을 하고 있는가?
우리는 어디로 가고 있는가?
그곳이 정말 우리가 원하는 방향인가?

여기에 이 시리즈의 질문 하나를 더하고 싶습니다.

Agent가 더 많은 일을 대신할수록, 나는 어떤 판단과 경험을 의도적으로 내 것으로 남길 것인가?

좋은 agent system은 사람을 request 입력창으로 축소하지 않습니다. 사람이 더 중요한 문제를 선택하고, 더 선명한 기준을 만들고, 결과와 영향에 책임질 수 있게 해야 합니다. 그 조건이 빠진 자율화는 기술적으로 성공해도 우리가 원한 성공이 아닐 수 있습니다.