Building an Autonomous Engineering Org — Angie Jones (Block / Agentic AI Foundation)

원문: https://www.youtube.com/watch?v=whue9_YquGA
채널: AI Engineer (컨퍼런스 원본 발표) | 길이: 17:36 | 처리일: 2026-07-14
관련 노트: [[2026-07-14-AgentOS-Block-AI챔피언전략]] (한국어 요약본)

---

1. 발표자와 배경

1-1. Angie Jones는 누구인가

• Block(Square, CashApp, Afterpay, Tidal)의 3,500명 엔지니어링 조직을 자율적 조직으로 전환한 당사자.
• 2025년 상반기: 마케팅·디자인·재무·법무 포함 전사 12,000명 AI 도입 총괄.
• 이후 CTO로부터 미션: "에이전트 기반 엔지니어링 조직 구축"
• 현재: Agentic AI Foundation 설립.

1-2. Block의 아주 이른 시작

• LLM이 Tool Calling을 지원하기도 전에 자체 코딩 에이전트 Goose 개발 시작.
• MCP(Model Context Protocol) 초기 출시 시 Anthropic의 디자인 파트너로 참여.
• Goose가 MCP 클라이언트의 레퍼런스 구현이 됐다.
• 내부에서 가장 호기심 많은 엔지니어들이 업계 최초로 코딩 에이전트를 사용했다.

---

2. 핵심 문제: 사용량 ≠ 임팩트

2-1. 역설적 상황

• 몇 달 후 엔지니어의 약 90%가 Goose와 Claude Code를 정기적으로 사용.
• 서류상 완벽한 성공, 하지만 CEO는 확신했다: "엔지니어링이 AI를 전혀 안 쓰고 있다."
• CEO의 근거: "우리가 더 빠르게 출시하고 있지 않으니까."
• Angie는 숫자(메트릭 + 토큰 청구서)를 가지고 있었다. AI를 쓰고 있다는 것은 확인됐지만 — CEO도 옳았다. 기능이 고객에게 더 빠르게 전달되지 않고 있었다.

2-2. AI 도입의 3단계

1. 실험(Experimentation): AI를 써보게 만들기 → 90%가 써보고 있었으므로 통과
2. 도입(Adoption): 다 같이 사용하게 만들기 → 대부분이 IDE 안에서 질문하거나 보일러플레이트 코드 작성 수준
3. 임팩트(Impact): 실제 성과로 이어지기 → 여기까지 가려면 AI를 어떻게 빌드하고 출시하는지에 통합해야 한다

---

3. "에이전트 기반 엔지니어링 조직"의 정의

3-1. 가장 단순한 정의

"엔지니어들이 AI 에이전트를 엔지니어링 성과를 만들어내는 주요 수단으로 활용하는 조직"

3-2. 이것이 의미하는 것

• 에이전트를 코드 여기저기 써주는 보조 도구가 아닌 엔지니어링 워크플로우의 핵심 멤버로 대우.
• 문제 분해 → 작업 위임 → 결과 검토 및 검증 — 이 세 가지가 기본 작동 방식이 되어야 한다.
• 엔지니어가 에이전트에게 지시하는 것이 **기본 운영 방식(default way of operating)**이 되어야 한다.

---

4. 성숙도 모델: 에이전트와의 관계로 측정

Steve Yegge의 'Gastown 아티클'에서 영감을 받아 재구성.

단계	정의
0단계	AI 도구를 워크플로우에 전혀 사용하지 않음
1단계	AI를 자동 완성에만 사용, 에이전트 모드 미사용
2단계	에이전트와 대화는 하지만 PR 생성은 안 함
3단계	에이전트에게 태스크를 위임하고 결과를 검토
4단계	여러 에이전트를 병렬로 운영
5단계	완전한 태스크를 위임하고 에이전트가 인간 가이드 없이 출시 가능한 결과물 생성

• 2025년 상반기 말, 엔지니어 대부분이 1~2단계 사이였다.
• 목표: 5단계

---

5. 3가지 장애물과 1-9-90 법칙

5-1. 장애물

1. 실험적 환경: 플레이북이 없었다. 이 주의 베스트 프랙티스가 다음 주에 새 도구/모델이 나오면 구식이 된다. → AI 피로감 형성.
2. AI 피로(AI Fatigue): 빠른 변화 속도에 따른 학습 피로.
3. 톱다운 압박: "AI 아니면 도태"라는 리더십의 강요에 사람들이 이미 지쳐 있었다.

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

• 디지털 커뮤니티: 콘텐츠를 만드는 1%, 상호작용하는 9%, 수동적으로 소비하는 90%.
• 이것이 엔지니어의 AI 도입과 거의 완벽하게 매핑된다.
• AI 전략이 모든 개인이 스스로 레벨업하는 데 의존한다면, 광범위한 임팩트를 절대 볼 수 없다.
• 전략 전환: 3,500명 전원에 집중하는 대신, 가장 중요한 팀의 1% = 파워 유저들로 구성된 집단을 만드는 데 집중.

---

6. AI 챔피언 프로그램: 50명 선발

6-1. 선발 방식

• 자원자 모집이 아니었다 — 전략적 선발이 필요했다.
• 1주일 동안 테크리드와 매니저들과 대화하며 50명을 직접 핸드픽했다.

6-2. 선발 기준 3가지

1. AI 도입에 업무 시간의 최소 30% 투자할 의지
2. AI의 비결정론적 특성에 좌절하지 않을 것 — "박스에서 꺼내자마자 작동하지 않을 때도 포기하지 않을 것" (실제로 자주 작동하지 않았다)
3. 가장 중요한 저장소들을 대표할 것 — Square, CashApp, Afterpay, Tidal, 프론트엔드·백엔드·모바일·데이터·인프라 전체

6-3. 다양한 저장소 커버

• 크고 지저분한 레거시 모노레포부터 작은 서비스, 모바일 앱까지 다양한 규모와 형태 포함.
• 이 다양성이 "무엇이 실제로 스케일되는가"를 빠르게 압력 테스트할 수 있게 해줬다.

---

7. 저장소를 AI 친화적으로 만들기

7-1. 왜 저장소인가

• 2025년 6월 시점, 모델들은 기능을 작성할 수 있었지만 팀의 컨벤션과 표준에 맞지 않는 코드를 생성할 확률이 높았다.
• 개발자들이 에이전트에게 작업을 위임할 만큼 신뢰하지 않았다.
• 이론: 저장소에 AI를 직접 임베드하면, 에이전트 성능이 좋아지는 것은 물론 팀 전체가 혜택을 받는다 — 1%뿐만 아니라.
• 저장소는 코드를 기여하는 모든 엔지니어의 중앙 레퍼런스 포인트다.

7-2. AI 친화적 저장소의 표준 구성 요소

1. 컨텍스트 파일 (agents.md, claude.md) — 에이전트가 코드베이스를 이해하고 탐색하며 기여하는 데 필요한 저장소 안내서
2. 규칙 파일 — 에이전트에게 가드레일을 제공하는 파일
3. 반복 가능한 워크플로우 — 슬래시 커맨드, 나중엔 에이전트 스킬
4. AI 코드 리뷰어 — 무엇이 중요한지, 무엇을 리뷰해야 하는지에 대한 지침 포함
5. PR에 AI 기여 표시 (AI Attribution)

7-3. 팀별 맞춤화, 자연스러운 수렴

• 하나의 크기가 모두에게 맞는 솔루션을 강요하지 않았다.
• 각 챔피언이 자신의 저장소에 맞는 방식을 찾게 했더니, 비슷한 형태와 규모의 팀들이 자연스럽게 같은 패턴으로 수렴했다.
• 모노레포: JVM 개발자들이 이미 상속 패턴에 강해서 루트에 공유 컨텍스트/규칙을 두고 서비스 레벨에 더 구체적인 것을 레이어링.
• 웹 vs 모바일: Android와 iOS도 때로는 다른 접근법이 필요했다.
• 엔지니어들이 이것을 좋아했다 — 톱다운 지시가 아닌 자신들이 선택할 수 있었기 때문.

---

8. 위임의 입구를 심다

8-1. 3가지 업무 입구

엔지니어들이 요구사항을 받는 3곳 모두에서 에이전트에게 작업을 위임할 수 있게 만들었다:

1. Jira, Linear 같은 이슈 트래커
2. GitHub 이슈
3. Slack (비공식 채널)

8-2. Slack 내 5분 버그 수정 — 실제 사례

"실화입니다."

1. 엔지니어 1: Slack에서 제품 버그 발견 → "이 버그 본 사람?"
2. 엔지니어 2: "나도 못 봤어"
3. 엔지니어 3: Slack에서 @goose 호출 → "이 버그 전에 본 적 있어? 버그인지 확인해줘"
4. Goose: 저장소에 접근, 파일 다운로드 → "맞아요, 여기 버그 있어요. 근데 구현 방법 옵션도 3개 드릴게요" (코드 스니펫 포함)
5. 엔지니어 1: "옵션 1 좋아" / 엔지니어 2: "나도"
6. 엔지니어 3: "Goose, 옵션 1 구현해줘"
7. Goose: 구현 완료 → PR 링크 반환

• 논의 → 진단 → 이슈 생성 → 정렬 → 수정까지 5분, 전부 Slack 안에서.
• 엔지니어들은 Linear/Jira 티켓 및 GitHub 이슈도 에이전트에게 할당해서 처음부터 끝까지 구현하게 할 수 있었다.

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

• 팀이 처음 이렇게 했을 때, 팀이 할 일이 동나서 티켓을 두 번이나 더 당겨와야 했다.
• 엔지니어링 매니저들과 제품팀이 이 플로우를 매우 좋아했다.
• 챔피언들이 이미 저장소의 기반을 잡아놨기 때문에 모든 작동이 가능했다 — 위임이 사람들이 이미 일하는 방식에 자연스럽게 통합됐기 때문.

---

9. 3개월 후 성과 (챔피언 프로그램)

지표	변화
AI 작성 코드	69% 증가
보고된 시간 절약	37% 증가
자동화된 PR	21배 증가

---

10. 4단계: 다중 에이전트 병렬화와 새로운 병목

10-1. 병렬화는 거의 무료였다

• 설정이 잘 되어 있어서 4단계로 이동하는 것 자체는 비용이 거의 없었다.
• 그러나 새로운 도전 과제들이 등장했다.

10-2. 병목 1: 코드 리뷰 대기

• 엔지니어들이 PR을 3~4배 생산하는데, PR이 코드 리뷰를 기다리며 쌓였다.
• AI 추가 전에도 코드 리뷰 유지가 힘들었는데, 지금은 더 심각해졌다.
• 해결책: 봇이 PR 리뷰를 도와야 했다.
  • 초기에는 AI 코드 리뷰어 성능이 너무 형편없어서 선택 사항으로 뒀었다 (엔지니어들 화나게 만들었음).
  • 챔피언들의 저장소 준비 작업 + 더 나은 모델 + Codex가 더 좋은 결과를 냈다.
  • 모든 저장소에 Codex를 활성화, 자동 수정 루프 생성: Codex가 이슈를 발견하면 다른 에이전트가 자동으로 수정하고 커밋.
  • 사람이 PR을 볼 때쯤엔 이미 꽤 깔끔한 상태.

10-3. 병목 2: 하드웨어 한계

• 병렬 에이전트들이 서로 충돌하고, 엔지니어 노트북이 메모리/CPU 한계에 도달.
• 해결책: 각 에이전트가 격리된 환경에서 실행되는 전용 클라우드 작업 공간에 투자.
• 이로써 어디서든 병렬 실행 가능.

---

11. 5단계: 자율적 엔지니어링 조직 — Builder Bot과 회사 세계 지도

11-1. Builder Bot (오케스트레이터)

• AI 챔피언들 포함 소수의 엔지니어 그룹이 자체 오케스트레이터 Builder Bot 구축.
• Builder Bot이 자율적 엔지니어링 조직 달성에 필요했다.

11-2. 회사 세계 모델 (Company World Model)

• 25,000개 저장소 코드베이스 전체를 기반으로 회사 세계 모델 구축.
• 모든 서비스와 그 연결 관계에 대한 기계 가독 가능한 뷰.
• 오케스트레이터와 위임받은 에이전트들이 필요에 따라 컨텍스트를 가져오고 구현하면서 전체 지형을 이해할 수 있게 됐다.

11-3. 5단계 달성

• 여러 에이전트들이 시스템의 다른 부분을 병렬로 탐색, 각자 이해를 구축한 후 합류.
• 오케스트레이터가 여러 코드베이스에 걸친 계획을 수립.
• 5단계 달성: 엔지니어들이 완전한 태스크를 위임하고, 에이전트가 인간 핸드홀딩 없이 출시 가능한 결과물 생성.
• 심지어 엔지니어로 제한되지 않았다: 회사의 누구든 Slack에서 Builder Bot을 호출해 버그를 수정하거나 새 기능을 구현할 수 있었다. GitHub 계정도 필요 없었다.

---

12. 결말: 꿈이 악몽이 되다

12-1. 해고

"이것은 꿈 같았다. 그것이 악몽이 될 때까지."

• 물론 모든 해고는 힘들지만, 이번 해고는 다르게 느껴졌다.
• 수많은 질문들이 떠올랐다:
  • "이게 내 잘못인가?"
  • "직원들이 커리어에서 가장 놀라운 일을 할 수 있게 했는데, 그것이 결국 그들의 해고로 이어진 건가?"
  • 바로 전날까지 자랑스러웠다. 우리가 일하는 방식에 경외감을 느꼈고, 자율적 엔지니어링 조직을 성공적으로 구축했다는 성취감이 있었다.
  • "그래서, 무엇을 위해서?"

12-2. 발표의 마지막 3가지 질문 (답 없이)

"여러분 모두에게 몇 가지 질문을 남기겠습니다."

1. "우리는 무엇을 하고 있는가?"
2. "우리는 어디로 향하고 있는가?"
3. "우리가 원하는 곳이 맞는지 확신하는가?"

---

13. 이 발표에서 배울 점 (단계별 플레이북)

단계별 핵심 액션

목표	핵심 액션
도입 → 임팩트	AI를 IDE 안에서 꺼내 빌드/배포 워크플로우에 통합
1~2단계 → 3단계	AI 친화적 저장소 구축 (컨텍스트 파일, 규칙, 슬래시 커맨드)
3단계 → 전체 조직	3가지 업무 입구(Jira/GitHub/Slack)에 에이전트 위임 경로 구축
3단계 → 4단계	AI 코드 리뷰어 + 자동 수정 루프 + 클라우드 작업 공간
4단계 → 5단계	오케스트레이터 + 회사 전체 세계 모델

성공의 핵심 원칙

1. 자원자가 아닌 지명: 챔피언을 전략적으로 선택하라.
2. 사람이 아닌 저장소를 바꿔라: 팀의 바닥을 올리는 것이 목표.
3. 강제가 아닌 자율 수렴: 팀마다 맞는 것을 찾게 하면 비슷한 팀끼리 수렴한다.
4. 기존 업무 흐름에 통합: 새 도구를 배우게 하지 말고, 이미 일하는 방식 안에 위임을 심어라.
5. 순서가 핵심: AI 리뷰어는 저장소 준비와 모델 성능 향상 후에야 켰다.

---

핵심 요약 (20줄)

1. Angie Jones는 Block(Square/CashApp)의 3,500명 엔지니어링 조직을 2년간 자율적 조직으로 전환한 당사자이며 현재 Agentic AI Foundation을 이끈다.
2. 핵심 역설: 90%가 AI를 쓰고 있었지만 고객에게 기능이 나가는 속도는 그대로였다 — 사용(Adoption)과 임팩트(Impact)는 완전히 다른 단계다.
3. 에이전트 기반 엔지니어링 조직 정의: 엔지니어들이 AI 에이전트를 엔지니어링 성과를 만드는 주요 수단으로 활용하는 조직.
4. 6단계 성숙도 모델 (Steve Yegge 'Gastown 아티클' 기반): 에이전트와 엔지니어의 관계로 측정 (0=미사용 ~ 5=완전 자율 배포).
5. 1-9-90 법칙: AI 전략이 모든 개인의 자기 레벨업에 의존한다면 광범위한 임팩트는 영원히 안 온다.
6. 해법: 3,500명 교육 대신 50명 AI 챔피언을 전략적으로 핸드픽 — 자원자 공모가 아닌 테크리드·매니저와 1주일 면담 후 직접 지명.
7. 챔피언 조건: 업무 시간 30% 이상 투입 + 비결정론적 AI에 좌절하지 않을 것 + 가장 중요한 저장소 대표.
8. 챔피언들이 제일 먼저 한 일: 저장소를 AI 친화적으로 변환 (사람 교육이 아님).
9. AI 친화적 저장소 5요소: ①컨텍스트 파일(agents.md) ②규칙 파일 ③슬래시 커맨드/스킬 ④AI 코드 리뷰어 ⑤PR AI 기여 표시.
10. 강제 표준화 대신 팀별 자율 탐색을 허용했더니 비슷한 팀끼리 자연스럽게 동일 패턴으로 수렴했다.
11. 3개의 업무 입구(Jira/GitHub/Slack) 모두에 에이전트 위임 경로를 구축 — 새 도구를 배우지 않아도 기존 방식 안에서 위임 가능.
12. Slack 안에서 버그 발견 → Goose 호출 → 진단 → 3가지 구현 옵션 제시 → 선택 → 구현 → PR까지 5분 완료.
13. 3개월 챔피언 프로그램 성과: AI 작성 코드 +69% / 시간 절약 체감 +37% / 자동 PR 21배.
14. AI 코드 리뷰어는 초기에 선택 사항으로 뒀다 — 품질이 나빠 엔지니어들 화나게 만들었기 때문. 저장소가 준비되고 모델이 좋아진 후에야 전면 도입. 순서가 핵심.
15. 4단계 병목: 코드 리뷰 과부하 → 자동 수정 루프(Codex 리뷰 → 다른 에이전트 자동 수정) / 하드웨어 부족 → 격리된 클라우드 작업 공간.
16. 5단계: 오케스트레이터 Builder Bot + 25,000개 저장소 전체를 분석한 회사 세계 모델(Company World Model).
17. 달성: 엔지니어가 아닌 누구든 Slack에서 Builder Bot 호출 → 버그 수정/기능 구현 가능. GitHub 계정도 불필요.
18. 그러나 결말: 해고 발표. "직원들이 커리어 최고의 일을 할 수 있게 했는데, 그것이 그들의 해고로 이어진 건가?"
19. 발표 마지막 질문 3개 (답 없이): "우리는 무엇을 하고 있는가? 어디로 향하는가? 그것이 우리가 원하는 곳인가?"
20. 이 발표는 AI 조직 전환의 완전한 플레이북이자, 기술적 성공이 인간적 재난으로 이어지는 구조에 대한 날카로운 질문이다.