AI VIDEO BRIEFING

블록 Builderbot과 Goose: 대규모 코드베이스를 다루는 AI 에이전트·루프 엔지니어링

스퀘어·캐시앱의 모기업 블록이 만든 Builderbot은 수억 줄 코드를 넘나드는 AI 에이전트 오케스트레이션 계층이다. 에이전틱 검색, 루프 엔지니어링, MCP 기반 도구 계층, 사람 검토 유지 원칙을 정리했다.

출처: Eye on Tech2026년 6월 25일AI 보조 요약

블록(Block)의 Builderbot: 수억 줄 코드를 다루는 대규모 AI 에이전트 오케스트레이션 영상 대표 이미지

핵심 메시지

Builderbot은 수억 줄 코드와 수천 개 코드베이스를 넘나들며 장애 대응과 코드 기여를 돕는, 블록 내부용 에이전트 오케스트레이션 계층이다.
핵심은 모델 재학습이 아니라 전체 코드의 인덱스를 만들고, 에이전트가 도구 호출 루프 안에서 스스로 검색을 반복하는 '에이전틱 검색'이다.
가장 중요한 혁신은 LLM이 도구를 호출하고 결과를 받아 다시 판단하는 '내부 루프'이며, 장애 대응 같은 큰 작업은 이를 블록처럼 쌓은 '외부 루프'로 구성한다.
모든 도구를 MCP로 연결해 모델을 현실에 '접지(grounding)'시키면 환각이 크게 줄어든다. 다만 정의가 중복된 데이터 해석은 여전히 어렵다.
중요한 서비스의 변경은 여전히 사람이 검토한 뒤 배포하며, 위험이 낮은 등급부터 점진적으로 자동화 범위를 넓혀간다.

쉽게 이해하기

블록에서 AI 역량을 총괄하는 브래드 액슨은 Informa TechTarget의 'IT Ops Query' 팟캐스트에서 내부 도구 Builderbot을 소개했다. 블록은 스퀘어, 캐시앱, 애프터페이, 타이달 등을 운영하며, 지난해 오픈소스 에이전트 프레임워크 Goose를 리눅스 재단의 새 '에이전틱 AI 재단' 창립 프로젝트 중 하나로 내놨고 Anthropic의 모델 컨텍스트 프로토콜(MCP) 공동 개발에도 참여했다.

Builderbot은 '아무 엔지니어나 다른 팀 시스템에 기여할 수 있을까', '장애가 났을 때 사람이 개입하기 전에 근본 원인을 찾아 고치기 시작할 수 있을까'라는 실험에서 출발했다. 이를 위해서는 블록이 어떻게 돌아가는지에 대한 넓은 맥락이 필요했고, 하나의 컨텍스트 창에 담기 어려운 거대한 코드베이스를 탐색하는 알고리즘을 개발해야 했다.

액슨은 별도 학습 없이 프런티어 모델을 그대로 쓰되, 용도에 따라 여러 프런티어 모델을 바꿔가며 쓰는 데서 큰 가치를 얻는다고 밝혔다. 초기의 검색 증강 생성(RAG) 방식은 잘 통하지 않았고, 대신 에이전트가 '잘못된 검색어를 썼으니 다시 시도하자'며 스스로 재검색하는 에이전틱 검색이 효과적이었다. 요즘 모델은 끈질겨서 제대로 된 인덱스만 있으면 넓은 영역에서도 필요한 것을 찾아낸다는 설명이다.

장애 대응에서는 여러 외부 벤더의 종단 간(end-to-end) 솔루션을 시험했지만, 범용 도구인 Builderbot이 더 나은 성과를 냈다. 완벽한 장애 대응 절차를 코딩하는 것보다, 내부 시스템에 대한 충분한 맥락을 주는 것이 더 중요했기 때문이다. 그 결과 최초 대응 시간은 최대 45분에서 5분으로 줄었고, 복구 시간은 절반으로 단축됐다.

품질 관리를 위해 블록은 내부적으로 '역량 계층(capabilities layer)'이라 부르는 도구 묶음을 MCP로 구성한다. 모델이 도구를 사용하는 한 환각은 드물어 코드에 대해서는 거의 틀리지 않지만, 같은 개념(예: 스퀘어의 '결제')을 정의한 표가 여러 개인 지저분한 데이터에서는 '맞지만 원하던 답은 아닌' 숫자를 내놓기 쉽다. 그래서 중요한 코드 병합과 이사회 보고용 쿼리는 여전히 사람이 검토한다.

주요 인사이트

종단 간 자동화를 특수 목적 도구로 정교하게 설계하기보다, 회사 내부 맥락을 충분히 갖춘 범용 에이전트가 실제 장애 대응에서 더 좋은 성과를 낼 수 있다.
수천만 줄 규모의 단일 코드베이스와 수억 줄·수천 개 코드베이스는 '다른 모양'의 해법을 요구한다. 규모가 커질수록 컨텍스트 창을 넘는 탐색 능력이 관건이 된다.
레거시가 오래될수록 AI의 가치가 크다. 언어를 몰라도 전체 그림을 이해하는 AI가 있으면 포트란 같은 옛 시스템도 다룰 수 있어, 사실상 정책·절차 문제만 풀면 된다.
모델은 인내심 있게 모든 줄을 읽어 사소한 버그를 사람보다 잘 잡지만, 다른 시스템과의 상호작용 같은 '큰 그림'은 놓치기 쉬워 사람 검토가 여전히 필요하다.
AI를 대화 초반부터 끌어들이면 디자이너·영업·PM이 실제 시스템에서 곧바로 프로토타입을 만들어 공유하게 되어, 40페이지 문서 대신 매달 수천 개의 프로토타입이 오간다.

자주 묻는 질문

Builderbot과 Goose는 어떤 관계인가?

Goose는 블록이 오픈소스로 공개한 에이전트 프레임워크로, LLM이 도구를 호출하고 결과를 받아 다시 판단하는 '내부 루프'를 담당하는 저수준 에이전트 하니스다. Builderbot은 그 위에서 수억 줄 코드와 수천 개 코드베이스를 넘나들며 에이전트를 대규모로 조율하는 오케스트레이션 계층이다.

'에이전틱 검색'은 기존 RAG와 무엇이 다른가?

초기의 검색 증강 생성(RAG)은 블록의 방대한 코드에서 잘 통하지 않았다. 대신 전체 코드의 인덱스를 만들고, 에이전트가 도구 호출 루프 안에서 '검색어가 틀렸으니 다시 찾자'며 스스로 반복 검색하게 했다. 끈질긴 모델이 넓은 영역에서도 필요한 것을 찾아내는 방식이다.

Builderbot은 장애를 자동으로 고쳐 배포하는가?

아니다. 보통 근본 원인을 찾아 수정안을 담은 풀 리퀘스트까지 만들지만, 실제 병합·배포는 사람이 결정한다. 블록은 고객에게 가장 중요한 '티어 0' 서비스는 아직 자동 변경을 하지 않고, 위험이 낮은 티어부터 AI 검토를 붙여 점진적으로 자동화 범위를 넓히고 있다.

코드와 데이터에서 AI 품질 차이가 나는 이유는?

모델은 도구를 쓰는 한 코드에 대해서는 거의 틀리지 않는다. 그러나 데이터는 같은 개념을 정의한 표가 여러 개인 경우가 많아, 문법적으로 옳은 SQL이라도 '맞지만 정작 필요했던 숫자는 아닌' 답을 내기 쉽다. 이는 모델보다 LLM 주변 엔지니어링(라우팅) 문제라는 설명이다.

원문과 출처

이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.

YouTube 원본 영상 보기 ↗