HubSpot — Crucible: 쿠버네티스 위에서 7,000개 PR을 자율 생성하다

1. 왜 이 사례인가

클라우드 코딩 에이전트를 외부 SaaS로 도입하면 편리하지만, 기업 내부의 개발 환경과 도구 생태계를 에이전트에게 그대로 제공하기는 어렵습니다. HubSpot은 이 문제를 직접 해결하기로 했습니다. 수십만 개 마이크로서비스와 하루 100만 건 이상의 빌드를 처리하는 기존 쿠버네티스(Kubernetes) 인프라 위에 에이전트 실행 플랫폼을 자체 구축한 것입니다.

HubSpot Product Blog에 2026년 1월 23일 게재된 엔지니어링 블로그 포스트에 따르면, 이 플랫폼의 이름은 Crucible이며 배포 이후 6개월 만에 7,000개 이상의 완전 AI 생성 PR이 병합되었고, 50,000개 이상의 PR이 AI 코드 리뷰를 거쳤습니다.

이 사례가 눈길을 끄는 이유는 단순한 에이전트 활용법에 그치지 않고, 기업이 자체 에이전트 인프라를 어떻게 구축하는가에 관한 구체적인 아키텍처와 운영 경험을 공개했다는 점입니다. 빌드 캐시 전략, 에이전트 행동을 제어하는 훅(hooks) 시스템, 비결정론적 AI와 결정론적 코드 로직의 분리 방법 등 다른 조직에서도 참고할 수 있는 설계 결정들이 담겨 있습니다.

2. Problem

HubSpot 엔지니어링 조직이 에이전트 플랫폼을 구축하며 마주한 문제는 크게 두 가지였습니다.

첫째, 외부 클라우드 에이전트 서비스로는 HubSpot의 개발 환경을 재현하기 어려웠습니다. HubSpot은 수만 개에 달하는 마이크로서비스, 사내 전용 빌드·배포 시스템, 내부 도구 및 라이브러리로 이루어진 복잡한 엔지니어링 생태계를 갖추고 있습니다. 블로그 포스트 저자인 Stephan Lensky는 사내 전용 도구의 비중이 높아 외부 제공업체 환경으로 이를 복제하기가 상당히 어려울 것이라고 판단했습니다.

둘째, 에이전트가 사내 빌드 로그, 통합 테스트, 내부 서비스에 접근하는 긴밀한 피드백 루프가 필요했습니다. 에이전트가 PR을 생성할 때는 빌드 통과 여부와 테스트 실패 여부를 실시간으로 확인하고, 그 결과에 맞춰 다음 행동을 조정할 수 있어야 했습니다. 이를 구현하려면 에이전트가 사내 개발 도구 전반과 맞물려 돌아가야 했습니다.

초기 에이전트 운영 과정에서 반복해서 나타난 실패 패턴도 있었습니다. 에이전트가 빌드에 실패한 상태인데도 작업을 마쳤다고 판단하거나, 사용자에게 필요한 내용을 알리지 않거나, PR 생성 자체를 빠뜨리는 일이 발생했습니다.

확인된 사실: HubSpot의 기존 K8s 인프라 규모(하루 100만 건 빌드, ~3,000개 EC2 인스턴스, 수만 개 마이크로서비스), 외부 에이전트 서비스 대신 자체 플랫폼 구축을 선택, 6개월 운영 후 7,000+ AI 생성 PR 병합, 50,000+ AI 코드 리뷰.

3. Solution

HubSpot은 기존 K8s 인프라를 바탕으로 Crucible이라는 에이전트 실행 플랫폼을 자체 구축했습니다. Claude Code를 핵심 모델로 채택하고, 이를 사내 개발 환경에 통합하는 데 필요한 모든 작업을 직접 구현했습니다.

3.1 Crucible 아키텍처

Crucible은 네 가지 핵심 구성 요소로 이루어집니다.

프론트엔드: 실행 이력을 조회하고 전사 로그를 확인하는 내부 인터페이스
API 서버: 새 에이전트 실행 요청을 처리하고, 실행 상태와 결과(파일 변경 git diff)를 반환
쿠버네티스 Job: 에이전트 실행 1건이 K8s Job 리소스 1개에 1:1로 대응하며, API 서버가 Job을 동적으로 생성하고 모니터링
도커 이미지: Claude Code와 사내 개발 도구 일체를 미리 설치한 커스텀 이미지. 이미지 진입점(entrypoint)에서 대상 Git 리포지터리 클론과 실행 프롬프트를 통한 Claude 실행을 자동으로 처리

이 구조는 모든 에이전트 실행을 샌드박스로 격리해 확장이 쉬우며, 코드 변경뿐 아니라 PR 리뷰 같은 다양한 요청도 처리할 수 있습니다.

3.2 주요 엔지니어링 난제 해결

컨테이너 환경 재현: 사내 도구 대부분이 로컬 노트북 환경을 전제로 만들어져 K8s 컨테이너에서는 동작하지 않았습니다. 개발팀은 이들 도구가 컨테이너 환경에서도 정상 작동하도록 다수의 도구를 직접 수정했습니다.

빌드 속도: Java 빌드 시간이 10~15분에 달했습니다. 기존 빌드 인프라를 운영하며 얻은 경험을 살려 전용 K8s 노드 풀에서 에이전트를 실행하고 호스트에 빌드 캐시를 마운트했습니다. 그 결과 대부분의 리포지터리에서 첫 빌드 시간을 2~3분으로 단축했습니다.

리소스 튜닝: 리포지터리 크기에 따라 메모리를 비롯한 하드웨어 자원 요구량이 달랐습니다. 팀은 K8s가 제공하는 수직 확장(vertical scaling)의 이점을 활용해 이 문제를 원활하게 처리했습니다.

3.3 GitHub·Slack 통합: Sidekick

HubSpot은 Crucible 위에 GitHub와 Slack 연동 기능을 구현했습니다. 기존 사내 AI 어시스턴트인 Sidekick을 확장하여, GitHub 이슈나 Slack에서 @-멘션으로 에이전트를 호출하는 인터페이스를 제공합니다.

지원하는 워크플로는 세 가지입니다.

이슈 계획(Issue planning): GitHub 이슈에서 @SidekickAI create a plan을 멘션하면 에이전트가 구현 계획을 이슈 댓글로 남깁니다. 사용자는 이 계획을 검토·수정한 뒤 다음 구현 단계로 넘어갑니다.

자율 구현(Autonomous implementation): Sidekick에게 이슈를 배정하면 에이전트가 자율적으로 이슈를 구현하고 PR을 생성합니다. 이슈 세부사항, 커밋·푸시 지침, 사용자 소통 방식(댓글 게시 또는 PR 본문 편집)은 템플릿 기반 프롬프트로 구성됩니다.

PR 리뷰: PR이 새로 생성되거나 ready for review 상태로 바뀔 때, 또는 Sidekick을 리뷰어로 직접 지정할 때 자동으로 실행됩니다.

확인된 사실: Crucible 구성 요소(프론트엔드·API서버·K8s Job·Docker), Claude Code 기반, Sidekick GitHub·Slack @-멘션 연동, 빌드 시간 10~15분 → 2~3분, 6개월 이내 7,000+ AI 생성 PR, 50,000+ AI 리뷰.

3.4 에이전트 신뢰성 확보: 결정론 + 훅

자율 구현 워크플로에서는 세밀한 조정 작업이 가장 많이 필요했습니다. 개발팀은 두 가지 핵심 원칙을 적용했습니다.

비결정론적 변환과 결정론적 로직의 분리. 기능 구현 과정에서 LLM의 유연성이 필요한 영역과 결정론적 코드로 처리할 수 있는 영역을 엄격히 구분했습니다. 예를 들어 이슈 작업을 시작할 때 새 브랜치를 만들고 드래프트 PR을 생성하는 작업은 언제나 결정론적 코드로 먼저 실행합니다. 그런 다음 생성된 브랜치 이름과 PR 번호를 에이전트 프롬프트에 템플릿 값으로 넣어주며, 에이전트에게 이 작업을 맡기지 않습니다.

훅(hooks) 시스템으로 에이전트 행동 강제. Claude Code의 훅 기능을 활용해 에이전트의 동작을 여러 단계에서 제어합니다. 실제 적용 중인 훅의 예시는 다음과 같습니다.

커밋 메시지가 지나치게 길면 자동으로 차단
관례에 어긋나는 편집(예: Java 전체 한정 클래스명 사용)은 자동 차단하되, 두 번째 시도는 허용
빌드가 통과하고 변경 사항이 커밋·푸시되기 전에는 에이전트가 임의로 작업을 끝낼 수 없음

확인된 사실: 결정론적 로직과 AI 로직의 분리 적용, Claude Code 훅 시스템 활용, 커밋 메시지 길이·코딩 스타일·작업 완료 조건 강제, 정확한 Git 리포지터리를 찾기 위한 소형 에이전트 활용, PR 추적을 위한 브랜치 이름·PR 본문에 엔지니어 username 임베드.

4. Impact

HubSpot Product Blog(2026-01-23) 기준 제시 지표입니다.

지표	수치	비고
AI 생성 PR 병합 수	7,000건 이상	Crucible 배포 후 6개월 이내
AI 코드 리뷰 수	50,000건 이상	사람이 작성한 PR 대상
빌드 시간 단축	10~15분 → 2~3분	빌드 캐시 + 전용 노드 풀
기준일	2026-01-23	블로그 포스트 게시일

블로그 포스트는 대부분의 HubSpot 엔지니어가 Crucible과 Sidekick을 매일 활용해 작업 속도를 높이고 있다고 밝혔습니다. 또한 Crucible이 대규모 코드 마이그레이션 자동화나 빌드 실패 자동 수정 등 사내 여러 업무에 두루 쓰이고 있다는 점도 언급했습니다.

5. Insight

이 사례는 에이전트 인프라를 자체 구축하는 편이 언제 더 유리한가를 잘 보여줍니다.

내부 도구 생태계가 복잡할수록 자체 구축이 유리합니다. 외부 에이전트 서비스를 도입하려면 네트워크 접근, 인증, 내부 도구 재현이라는 세 가지 장벽을 넘어야 합니다. HubSpot처럼 사내 전용 빌드 시스템, 자체 라이브러리, 방대한 마이크로서비스 아키텍처를 갖춘 조직에서는 외부 서비스를 쓰기보다 자체 플랫폼을 꾸리는 편이 환경 재현 속도와 제어력 측면 모두에서 더 나을 수 있습니다.

빌드 속도는 에이전트 피드백 루프의 핵심 변수입니다. 에이전트가 빌드 결과를 확인하며 다음 행동을 결정하는 환경에서, 빌드에 10분씩 걸린다면 에이전트가 여러 차례 시도하기 어렵습니다. 전용 노드 풀과 빌드 캐시를 도입해 첫 빌드 시간을 2~3분으로 줄인 조치는 에이전트의 실질적인 생산성 개선으로 이어졌습니다.

결정론적 로직이 에이전트 신뢰성을 뒷받침합니다. LLM에 모든 과정을 맡기면 비결정성이 쌓이게 됩니다. HubSpot은 브랜치나 PR 생성처럼 반드시 수행해야 하는 작업은 일반 코드로 확실하게 처리하고, 창의적인 판단이 필요한 영역만 LLM에 넘겼습니다. 훅 시스템은 이러한 경계를 실행 시점에 강제하는 역할을 합니다.

복제 조건: 자체 K8s 인프라와 컨테이너 환경을 안정적으로 다루는 역량이 먼저 갖춰져야 합니다. 아울러 사내 개발 도구를 컨테이너 환경에 맞춰 수정하는 데도 적지 않은 엔지니어링 공수가 들어갔습니다. 따라서 이러한 투자를 회수하려면 에이전트를 활용하는 규모(엔지니어 수 × 사용 빈도)가 충분히 뒷받침되어야 합니다. 배포 6개월 만에 7,000건의 PR이 생성되었다는 수치는 이 같은 투자가 타당했음을 보여줍니다.

6. 원문에 없는 추정 (구현 가설)

6.1 에이전트 프롬프트 생성 파이프라인

근거: 포스트는 자율 구현 프롬프트가 템플릿에서 생성되며 이슈 세부사항, 커밋·푸시 지침, 사용자 소통 방법이 포함된다고 설명합니다. 또한 계획 단계의 이슈 댓글이 구현 단계의 프롬프트 입력이 됩니다.

이슈 제목과 본문만으로는 에이전트가 어떤 파일을 수정해야 하는지 파악하기 어렵습니다. 포스트에서 “파일에 대한 구체적인 참조를 포함한 상세 구현 계획이 에이전트에게 큰 도움이 된다”는 언급이 있는 것으로 보아, 계획 단계 에이전트가 이슈를 분석해 관련 파일 경로와 함수 서명을 구현 프롬프트에 포함하는 RAG 또는 코드 검색 레이어가 있을 가능성이 높습니다. 또한 사내 코딩 스타일 가이드와 기존 패턴 예시를 프롬프트에 포함하는 컨텍스트 주입 단계가 표준화되어 있을 것으로 추정됩니다.

6.2 코드 리뷰 에이전트의 피드백 분류

근거: 포스트는 PR 리뷰 에이전트가 50,000건 이상의 PR을 처리했으며, 코드 리뷰 품질 향상에 대한 별도 포스트를 예고합니다. 또한 에이전트가 생성한 코드에서 중복 코드와 패턴 불일치가 가장 많이 발견되는 문제라고 언급합니다.

리뷰 에이전트가 단순 스타일 지적과 기능적 오류 지적을 구분하지 못하면 리뷰어의 주의가 분산됩니다. 에이전트 리뷰가 실질적으로 활용되려면 코드베이스 전체의 기존 패턴을 벡터 저장소나 임베딩으로 보유하고, 현재 PR의 변경 사항이 기존 패턴과 얼마나 유사한 코드를 이미 가지고 있는지 판별하는 중복 탐지 레이어가 작동할 것으로 보입니다. 리뷰 댓글의 심각도를 자동으로 라벨링(예: blocking/non-blocking/suggestion)하는 구조가 엔지니어 수용률을 높이는 데 중요하며, 이 분류 정확도 데이터가 리뷰 에이전트의 파인튜닝 소재가 될 것으로 분석됩니다.

6.3 멀티 리포지터리 환경에서의 리포지터리 선택 에이전트

근거: 포스트는 GitHub 이슈에서 에이전트를 트리거할 때 올바른 Git 리포지터리를 선택하는 문제를 소형 에이전트를 통해 해결했다고 설명합니다.

HubSpot 규모의 조직에서 수만 개의 마이크로서비스 리포지터리가 있다면, 이슈 제목과 설명만으로 올바른 리포지터리를 자동 선택하는 것은 비결정적 문제입니다. 이 소형 에이전트는 이슈 내용에서 서비스명이나 기능 영역을 추출하고, 내부 서비스 레지스트리나 팀 소유권 메타데이터와 대조해 후보 리포지터리 목록을 좁히는 방식으로 작동할 개연성이 높습니다. 엔지니어가 이슈에 리포지터리를 명시할 수 있는 방법을 함께 제공해, 소형 에이전트의 추론이 불확실한 경우 수동 오버라이드가 가능한 구조를 갖추고 있을 것으로 추정됩니다.

7. 출처

HubSpot Product Blog — Cloud Coding Agents at HubSpot
https://product.hubspot.com/blog/cloud-coding-agents-at-hubspot
게시일: 2026-01-23 (블로그 본문 날짜, 저자: Stephan Lensky)