자율 엔지니어링 조직으로의 AX 전환

AI 도입률 90퍼센트. 숫자만 보면 성공 사례다.
그런데 CEO가 이렇게 말했다면 어떨까. 엔지니어링팀이 AI를 전혀 안 쓰고 있는 것 같다고. 제품이 빨라지지 않았다고. 토큰 비용은 분명히 올라갔다. 사용률도 높았다.

그런데 새로운 기능을 시장에 출시하는 속도는 그대로였다.

이 이야기의 무대는 결제 회사 블록이다. Angie Jones가 이끌었던 자율 엔지니어링 조직 전환기를 따라가 본다.

시작하기 전 필자의 가정

필자는 이른바 전자결재와 관련된 상용제품을 개발해 본 경험이 없다.

그러나 요즘 IT 트렌드, 그리고 이와 관련된 소프트웨어 개발 조직에서의 경험을 바탕으로 몇가지 가정을 하고 블록의 AX 전환 과정을 상상해 보려고 한다.

첫째로 블록은 돈을 다루는 회사이다. 금융은 해당 산업 종사자들만 알고 있는 업계 표준이 있고 대표적인 규제 산업중 하나이다. 즉 소프트웨어를 개발할 때 따라야 할 규칙이 많다는 이야기 이다. 실제로 블록은 전자상거래등 관련 경험이 많은 인력들로 구성되어 있었다고 한다. 기본적인 룰에 대한 문서화 되어 있지 않은 암묵지가 많을 수 있다는 가정을 한다.

다음은 새롭게 개발되는 소프트웨어에 대한 각 단계별 시험 및 품질 관리가 어느 정도 수준으로 이미 이루어졌다고 가정한다. 특정 하드웨어를 사용하지 않고 클라우드 사업자의 인프라를 사용하여 테스트 시험 배포의 모든 과정이 어느정도 자동화 되어 있어 이 부분에서는 병목이 발생하지 않는다고 가정한다.

마지막으로 그들의 소프트웨어는 모노리틱 구조가 아닌 마이크로 서비스 구조로 이루어져 있다고 가정한다. 마이크로 서비스구조의 소프트웨어는 각 서비스 별로 별도의 레포를 구성하고 다른 레포에 종속적이지 않도록 별도로 배포가 가능한 기본단위로 이루어 진 구조를 가정했다.

블록이라는 회사

블록은 트위터 공동창업자 잭 도시와 짐 맥켈비가 2009년에 만든 회사다. 처음 이름은 Square였다. 2021년에 블록으로 이름을 바꾸면서 결제 사업 하나만 하는 회사가 아니라 지주회사 형태로 몸집을 키웠다.

포트폴리오를 보면 확실히 지주회사답다. 판매자용 결제 단말기와 POS, 대출까지 아우르는 Square. 개인간 송금과 주식·비트코인 투자, 대출을 제공하는 소비자용 앱 Cash App. 선구매 후결제 서비스 Afterpay. 음악 스트리밍 TIDAL. 비트코인 자가보관 지갑 Bitkey. 비트코인 채굴 사업 Proto. 그리고 2026년 전 시장에 확대 출시된 판매자용 AI 비서 Square AI까지.

여기서 중요한 건 이 회사가 그냥 IT 회사가 아니라는 점이다. 은행업, 자금송금업, 가상자산업, 대출업, 증권중개업. 다섯 개 규제 영역을 동시에 걸치고 있다.

기술 스택은 AWS 중심으로 보인다.

Amazon EKS 기반 이중 클러스터 구조로 가용영역 장애에 대비하고, CloudPlat이라는 자체 클라우드 추상화 레이어를 만들어 Kubernetes, Istio, Kafka, MySQL, DynamoDB를 판매자·소비자 앱 전반에 표준화된 방식으로 공급한다. 언어는 Kotlin, Java, Ruby, NodeJS, React. 암호화는 AWS KMS 위에 자체 개발한 애플리케이션 계층 암호화를 얹었다.

규제가 이렇게 촘촘한 회사가, 3500명 규모의 엔지니어링 조직을 자율 조직으로 바꾸겠다고 나섰다. 그게 이 이야기의 출발점이다.

AX 전환 여정

블록은 LLM에 도구 호출 기능이 생기기도 전부터 자체 코딩 에이전트 Goose를 만들었다. 앤트로픽의 MCP 초기 파트너로도 참여했고, Goose는 MCP 클라이언트의 표준 구현체가 됐다. 몇 달 만에 엔지니어의 90퍼센트가 Claude Code 같은 도구를 정기적으로 썼다. 겉으로는 완벽한 도입이다.

그런데 CEO는 달랐다. 배포 속도가 전혀 빨라지지 않았다고 지적했다. 데이터로는 토큰 사용량이 분명히 늘었는데, 실제 임팩트로는 이어지지 않았다. 타임 투 마켓은 변화없이 운용비용만 증가한 셈이다.

신기능 출시 속도를 높이기 위해 성숙도 모델을 도입했다. 실험, 채택, 임팩트라는 세 단계를 여섯 개 스테이지로 세분화했다.

Stage 0은 아예 AI를 안 쓰는 상태. Stage 1은 자동완성만 쓰고 에이전트 모드는 안 쓰는 상태. Stage 2는 에이전트와 대화는 하지만 PR을 만들지는 않는 상태. Stage 3은 단일 작업을 위임하고 결과물을 검토하는 상태. Stage 4는 여러 에이전트를 동시에 병렬로 돌리는 상태. Stage 5는 에이전트에게 전체 과업을 맡기고 사람의 밀착 케어 없이도 배포 가능한 결과물이 나오는 상태.

당시 대다수 엔지니어는 Stage 1, 2에 머물러 있었다. 목적지는 Stage 5였다.

3500명을 동시에 교육하는 건 불가능에 가깝다. 그래서 1-9-90 법칙을 썼다. 커뮤니티의 1퍼센트가 기여하고 9퍼센트가 참여하고 90퍼센트가 소비한다는 그 원리다. 전사 지원자를 받는 대신, 각 핵심 팀에서 영향력이 크고 시간의 30퍼센트 이상을 투자할 수 있는 엔지니어 50명을 직접 선발했다. 백엔드, 프론트엔드, 모바일, 데이터, 인프라, 모노레포, 마이크로서비스까지 모든 영역을 포함시켰다.

리포지토리 자체도 에이전트 친화적으로 바꿨다. AGENTS.md, CLAUDE.md 같은 컨텍스트 파일을 추가하고, Slash 명령어와 에이전트 스킬, AI 리뷰어, PR 상의 AI 기여 표시를 구축했다. Slack, Jira, Linear, GitHub Issues 같은 기존 업무 채널에서 바로 에이전트를 호출할 수 있게 만들었다. 버그를 발견하면 Slack에서 Goose를 호출하고, 코드 분석과 해결책 세 가지를 받고, 팀원끼리 합의한 뒤 실행 명령을 내리면 5분 만에 PR이 만들어지는 식이었다.

챔피언 프로그램 3개월 후 결과는 이랬다. AI가 작성한 코드 69퍼센트 증가. 시간 절감 보고 37퍼센트 증가. 자동화된 PR 생성 21배 증가.

예상 병목 지점에 대한 해결

숫자가 좋아지면 다음 문제가 온다. 그게 Stage 4였다.

코드 리뷰

에이전트가 만드는 PR이 폭증하니 이번엔 코드 리뷰가 막혔다. 사람이 검토할 수 있는 속도보다 PR이 생성되는 속도가 훨씬 빨랐다.

블록이 여기서 유리했던 지점이 있다. 금융 서비스를 오래 해온 회사라 이미 코드 품질에 관한 관행이 있었다. PCI 컴플라이언스, 사기 탐지 패턴, 정산 주기, 분쟁·차지백 처리 같은 도메인 지식을 채용 단계부터 필수 역량으로 평가해왔다. 규제 제약 안에서 일한 경험을 코드 작성 단계부터 요구해온 조직이라는 뜻이다.

이런 축적된 리뷰 기준이 있었기 때문에, CodeEx 같은 도구와 자동 수정 루프를 결합해서 에이전트가 1차 리뷰와 오류 수정을 담당하도록 만드는 전환이 가능했다. 사람이 처음부터 리뷰 기준을 새로 정의할 필요 없이, 이미 있던 품질 기준을 도구로 옮기는 작업에 가까웠던 셈이다.

테스트

또 하나의 한계는 하드웨어와 환경이었다. 엔지니어 노트북의 메모리와 CPU로는 에이전트를 여러 개 동시에 돌릴 수 없었다. 그래서 전용 클라우드 워크스페이스를 만들어 각 에이전트가 격리된 환경에서 실행되도록 했다.

이 워크스페이스가 그냥 빈 공간이 아니었다는 점이 중요하다. 블록은 이미 Cash App 플랫폼팀 차원에서 AWS Fault Injection Service를 활용해 스테이징 환경에서 가용영역 전원 장애 같은 실제 장애 시나리오를 인위적으로 발생시켜 검증하는 체계를 갖고 있었다. 여기에 더해 공유 EKS 플랫폼에서 단일 장애점을 없애기 위한 이중 클러스터 구조, 그리고 CAPE 팀이 제공하는 CloudPlat이라는 표준화된 추상화 계층도 이미 존재했다.

에이전트가 대량으로 코드를 쏟아내는 상황에서, 이렇게 이미 완성돼 있던 플랫폼 특화 검증 구조가 그대로 안전망 역할을 한 셈이다. 결과물을 검증할 인프라를 새로 짓지 않고, 원래 있던 신뢰성 체계 위에 에이전트의 실행 환경을 얹은 것에 가깝다.

Goose의 개발

블록은 앤트로픽이나 오픈AI 한쪽에 종속되지 않았다. 자체 오픈소스 코딩 에이전트 Goose를 Rust로 만들어 Apache 2.0으로 공개했다.

15개 이상의 LLM 공급자를 지원한다. Anthropic, OpenAI, Google Gemini, Groq, Mistral, Cohere, 로컬 Ollama 모델까지 세션 단위로 골라 쓸 수 있다. MCP를 네이티브로 지원해서 GitHub, PostgreSQL, Slack, Jira 등 70개 이상의 확장 기능과 연동된다.

2026년에는 Goose 프로젝트 자체가 리눅스 재단 산하 Agentic AI Foundation으로 이관됐다. 블록은 여전히 핵심 메인테이너로 남아 있지만, 거버넌스는 재단 체제로 넘어간 상태다.

다만 이 부분은 분명히 해둘 필요가 있다. Goose의 MCP 기반 표준화는 개발 자동화의 일관성과 추적 가능성을 확보하려는 시도이긴 하지만, 규제 대응이라기보다는 개발 생산성 측면의 접근에 더 가깝다. 즉 코드 리뷰나 테스트 영역에서 봤던 컴플라이언스 축적물이 Goose 자체의 설계 철학까지 그대로 이어졌다고 보기는 어렵다. 오히려 특정 벤더에 묶이지 않겠다는 실용적 판단이 더 크게 작용한 결과에 가깝다.

회사내 모든 협업 tool을 Goose와 연결

마지막 단계는 오케스트레이션이었다. 여러 에이전트를 총괄 조정하는 BuilderBot을 만들었다. 전체 25,000개 리포지토리의 의존성과 구조를 다루는 회사 전체의 월드 모델도 함께 구축했다. 에이전트들이 개별 리포지토리 단위가 아니라 시스템 전체를 이해하고, 여러 리포지토리에 걸친 작업을 수행할 수 있게 만든 것이다.

여기까지 오니 그림이 완성됐다. 엔지니어뿐 아니라 회사 구성원 누구든 Slack에서 BuilderBot을 태그하기만 하면 버그를 고치거나 새 기능을 구현할 수 있는 수준. 아이언맨의 자비스가 이런 모습이었을 거다. 부르면 답이 온다. 코드를 아는지 모르는지는 더 이상 중요하지 않다.

마치며

여기서 이야기가 예상 밖으로 흘러간다.

Angie Jones는 자율 엔지니어링 조직 구축이라는 목표를 완벽히 달성했다고 느낀 직후, 대규모 구조조정 소식을 들었다. 조직 규모는 1만 명 이상에서 6천 명 수준으로 재편됐다. 회사는 이걸 개발자 생산성 향상과 인텔리전스 네이티브 운영으로의 전환이라는 말로 설명했다.

이전까지 느꼈던 자부심은 곧 고뇌로 바뀌었다. 이게 내 잘못인가. 동료들이 커리어 최고의 성과를 내도록 도운 결과가 결국 그들의 해고였나. 우리는 무엇을 위해 이 작업을 했나.

그가 남긴 마지막 질문은 이거였다. 우리는 지금 무엇을 하고 있는가. 어디로 향하고 있는가. 그리고 그곳이 정말 우리가 도달하고자 하는 목적지가 맞는가.

숫자는 좋아졌다. 코드는 늘었다. 리뷰는 빨라졌다. 그런데 그 끝에서 누군가는 자리를 잃었다.

AX 전환이라는 말을 쓸 때, 이 질문도 같이 챙겨야 하지 않을까.