AI 에이전트 도입, 블록은 어떻게 3,500명 엔지니어 조직을 바꿨나

핵심 메시지

• 90%의 엔지니어가 AI를 쓰는데도 제품이 더 빨리 출시되지 않았던 이유는, AI가 IDE 안에서 코드 보조에 머물렀기 때문이다.
• 엔지니어와 AI의 관계를 0~5단계로 나눈 성숙도 모델을 만들어, 모두를 '에이전트에 작업을 위임하고 검증하는' 5단계로 끌어올리는 것을 목표로 삼았다.
• 전원을 끌어올리는 대신 1·9·90 법칙에 기대어, 핵심 팀에서 뽑은 약 50명의 'AI 챔피언' 1%가 패턴을 만들고 저장소에 심어 나머지를 끌어올리게 했다.
• agents.md·규칙 파일·슬래시 커맨드·AI 코드 리뷰어 등으로 저장소를 'AI 친화적'으로 만들자, Slack·Jira·GitHub 이슈에서 곧바로 에이전트에게 작업을 위임할 수 있게 됐다.
• 자율 조직(5단계)에 도달한 직후 정리해고가 닥치면서, 발표자는 '우리가 향하는 곳이 정말 원하는 곳인가'라는 질문을 남긴다.

쉽게 이해하기

블록(Block)의 앤지 존스는 지난 몇 년간 3,500명 규모의 엔지니어링 조직을 '자율(autonomous)' 조직으로 바꾸는 일을 이끌었다. 블록은 LLM이 도구 호출을 지원하기도 전부터 자체 코딩 에이전트 '구스(Goose)'를 만들었고, 앤트로픽과 MCP 초기 설계 파트너로 협업해 구스를 MCP 클라이언트의 레퍼런스 구현으로 만들었다. 그 결과 몇 달 만에 약 90%의 엔지니어가 구스나 클로드 코드 같은 도구를 일상적으로 썼다.

문제는 숫자상 '올인'처럼 보이는데도 CEO는 엔지니어링이 AI를 전혀 안 쓴다고 확신했다는 점이다. 기능이 고객에게 더 빨리 도달하지 않았기 때문이다. 존스는 그 원인을 진단하며 AI 도입을 실험·채택·임팩트 세 단계로 구분했고, 90%가 '채택'은 했지만 여전히 IDE 안에서 질문하거나 보일러플레이트를 짜는 수준에 머물러 있었다고 봤다.

그래서 그는 엔지니어와 AI 에이전트의 관계를 측정하는 성숙도 모델을 만들었다. 0단계는 AI 미사용, 1단계는 자동완성, 2단계는 대화는 하지만 PR은 만들지 않는 단계, 3단계는 작업을 위임하고 결과를 리뷰, 4단계는 여러 에이전트를 병렬로, 5단계는 사람의 안내 없이도 출시 가능한 결과를 내는 단계다. 대다수는 1~2단계에 머물러 있었다.

존스는 3,500명 전원을 동시에 끌어올리려는 전략은 실패한다고 봤다. 온라인 커뮤니티의 1·9·90 법칙(1%가 창작, 9%가 상호작용, 90%가 소비)이 AI 도입에도 거의 그대로 적용된다고 본 것이다. 그래서 자원자를 받는 대신, 가장 중요한 저장소를 대표하는 약 50명의 엔지니어를 직접 골라 'AI 챔피언' 프로그램을 꾸렸다. 시간의 30% 이상을 투자할 수 있고, AI의 비결정적 특성에 쉽게 좌절하지 않는 사람들이었다.

핵심 전략은 저장소 자체를 'AI 친화적'으로 만드는 것이었다. 챔피언들은 agents.md·claude.md 같은 컨텍스트 파일, 가드레일 역할의 규칙 파일, 슬래시 커맨드와 에이전트 스킬, AI 코드 리뷰어, PR의 AI 기여 표기 등을 저장소에 심었다. 모노레포·모바일 등 저장소 형태에 따라 접근을 달리하되, 비슷한 저장소끼리는 자연스럽게 같은 도구와 패턴으로 수렴하게 했다.

이후 Jira·Linear·GitHub 이슈는 물론 Slack 대화에서도 에이전트에게 작업을 위임할 수 있게 됐다. 한 엔지니어가 Slack에서 버그를 언급하자 구스가 저장소를 뒤져 버그를 확인하고 세 가지 해결안을 코드 스니펫으로 제시했고, 팀이 옵션을 고르자 구스가 구현해 PR 링크를 돌려줬다. 진단부터 수정까지 약 5분이 걸렸다. 3개월 뒤 AI 작성 코드는 69% 늘고, 보고된 시간 절감은 37% 증가, 자동 PR은 21배로 늘었다.

4단계(병렬 멀티 에이전트)로 가자 새 문제가 생겼다. PR이 폭증해 코드 리뷰 병목이 생겼고, 챔피언들의 저장소 정비와 더 나은 모델 덕에 코덱스(Codex) 같은 AI 리뷰어를 전 저장소에 켜고, 지적된 문제를 다른 에이전트가 자동 수정·커밋하는 루프를 만들었다. 또 노트북이 메모리·CPU 부하를 못 견디자 에이전트마다 격리된 전용 클라우드 워크스페이스를 투입했다.

마지막으로 일부 챔피언들이 '빌더 봇(Builder Bot)' 오케스트레이터를 만들고, 2만 5천 개 저장소 전체를 기계가 읽을 수 있는 '회사 월드 모델'로 구축했다. 여러 에이전트가 시스템의 다른 부분을 병렬로 탐색하고 오케스트레이터가 종합해 여러 코드베이스를 가로지르는 계획을 세웠다. 이렇게 5단계에 도달했고, 엔지니어가 아닌 누구라도 Slack에서 빌더 봇을 호출해 버그를 고치거나 기능을 구현할 수 있게 됐다. 그러나 곧 정리해고가 닥쳤고, 발표자는 자신이 만든 자율 조직이 결국 무엇을 위한 것이었는지 자문하며 강연을 끝맺는다.

주요 인사이트

• 도입률(90%)은 성과의 대리 지표가 아니다. AI가 '코드 작성을 돕는' 단계에서 '작업을 위임받는' 단계로 넘어가야 출시 속도가 바뀐다.
• 전사 대상 교육보다, 핵심 저장소를 대표하는 소수(1%)를 전략적으로 선발해 패턴을 저장소에 '심게' 하는 편이 더 넓은 임팩트를 만든다.
• agents.md·규칙 파일·슬래시 커맨드 같은 저장소 자산은 1% 챔피언뿐 아니라 그 저장소에 기여하는 모든 엔지니어를 함께 끌어올린다.
• 에이전트를 늘리면 코드 리뷰 병목과 로컬 머신 부하라는 2차 문제가 따라온다. AI 리뷰어 자동 수정 루프와 격리된 클라우드 워크스페이스가 그 해법이 됐다.
• 여러 코드베이스를 가로지르는 자율 작업에는 '무엇이 어디에 있고 무엇에 의존하는지'를 담은 기계 판독 가능한 회사 월드 모델이 전제 조건이 된다.

자주 묻는 질문

관련 AI 소식