HubSpot, 훅 제어로 AI PR 7천여 건 병합

요약

• 외부 도구 대신 자체 쿠버네티스 인프라 위에 에이전트 실행 플랫폼을 구축했습니다.
• 엄격한 규칙 통제와 빌드 가속으로 6개월 만에 AI 생성 풀 리퀘스트 7,000건을 합쳤습니다.
• 사내 개발 환경이 복잡할수록 자체 실행 환경과 확정적 코드의 통제가 필수적입니다.

외부 서비스를 쓰지 않고 자체 인프라를 택한 이유

개발 조직에 인공지능을 도입할 때 가장 손쉬운 선택지는 이미 잘 만들어진 외부 클라우드 서비스를 구독하는 것입니다. 하지만 회사의 고유한 개발 환경이 복잡할수록 이 방식은 금세 장벽에 부딪힙니다. HubSpot이 2026년 1월 23일 자사 제품 블로그에 엔지니어 Stephan Lensky의 글로 공개한 사례는 바로 이 지점에서 출발합니다.

HubSpot은 하루에 100만 건이 넘는 빌드를 처리하고, EC2 인스턴스 약 3,000대 위에서 수만 개에 달하는 마이크로서비스를 운영하고 있었습니다. 마이크로서비스는 커다란 소프트웨어를 작은 독립적인 서비스 단위로 쪼개어 운영하는 구조를 뜻합니다. 여기에 사내 전용 빌드와 배포 시스템, 자체 개발 도구와 라이브러리가 촘촘하게 얽혀 있었습니다. Stephan Lensky는 사내 도구를 워낙 많이 쓰고 있었기 때문에 외부 업체의 환경으로 이 복잡한 개발 환경을 복제하는 것은 꽤 어려웠을 것이라고 밝혔습니다.

더 큰 문제는 피드백 고리였습니다. 인공지능 에이전트가 코드를 제대로 고치려면 사내 빌드 로그를 직접 읽고, 통합 테스트를 실행하고, 내부 서비스에 접근해 빌드가 성공했는지 테스트가 실패했는지를 실시간으로 확인해야 합니다. 에이전트가 다음 행동을 스스로 판단할 수 있는 촘촘한 피드백 환경이 필요했던 것입니다.

초기 실험에서는 여러 실패가 이어졌습니다. 빌드가 실패한 상태인데도 작업을 다 끝냈다고 멋대로 판단하거나, 사용자에게 진행 상황을 제대로 알리지 않거나, 코드를 실컷 고쳐 두고 정작 코드 변경을 합쳐 달라는 요청인 PR(Pull Request)을 만드는 일 자체를 잊어버리는 식의 실수가 반복되었습니다. 결국 HubSpot은 기존 인프라 위에 직접 에이전트 실행 플랫폼을 만들기로 결정했습니다.

Crucible의 네 가지 뼈대

HubSpot이 구축한 자체 플랫폼의 이름은 Crucible입니다. 이 플랫폼은 Claude Code를 핵심 엔진으로 삼아 사내 개발 환경과 매끄럽게 맞물리도록 설계되었습니다. 전체 구조는 네 가지 핵심 구성 요소로 이루어져 있습니다.

첫째는 프런트엔드입니다. 엔지니어가 이전 실행 기록을 살펴보고, 에이전트와의 대화 기록과 로그를 한눈에 확인할 수 있는 사내 화면입니다.

둘째는 API 서버입니다. 새로운 에이전트 실행 요청을 접수하고, 현재 실행 상태와 최종 결과물인 파일 변경 내역(git diff)을 반환하는 중계 역할을 맡습니다.

셋째는 쿠버네티스 Job입니다. 쿠버네티스는 수많은 컨테이너를 배치하고 관리하는 시스템을 뜻하며, Job은 한 번 실행되고 끝나는 독립적인 작업 단위를 의미합니다. 에이전트 실행 1건마다 쿠버네티스 Job 1개가 일대일로 대응해 만들어지며, API 서버가 이를 동적으로 생성하고 감시합니다. 덕분에 모든 에이전트 작업은 서로 간섭하지 않는 안전한 격리 환경에서 돌아가고, 필요에 따라 실행 규모를 유연하게 늘릴 수 있습니다.

넷째는 도커 이미지입니다. 도커는 프로그램을 실행에 필요한 환경과 함께 상자처럼 묶어 내는 기술입니다. 이 이미지 안에는 Claude Code와 사내 개발 도구들이 미리 설치되어 있습니다. 실행이 시작되면 진입점 스크립트가 대상 Git 저장소를 복제해 오고 전달받은 지시문으로 Claude를 곧바로 구동합니다. 이 구조 덕분에 코드 작성뿐 아니라 PR 리뷰 같은 다양한 요청도 동일한 방식으로 처리할 수 있습니다.

15분 걸리던 빌드를 2~3분으로 줄인 세 가지 엔지니어링

플랫폼을 설계했다고 해서 곧바로 에이전트가 원활히 작동한 것은 아닙니다. 엔지니어링 팀은 현장에서 세 가지 난제를 해결해야 했습니다.

가장 먼저 맞닥뜨린 문제는 도구의 실행 환경이었습니다. 사내 개발 도구 대부분은 개발자의 개인 노트북 환경에서 돌아가는 것을 전제로 만들어져 있었습니다. 컨테이너 내부에서는 제대로 실행되지 않았기 때문에, 팀은 수많은 사내 도구를 직접 수정해 컨테이너 안에서도 정상 작동하도록 바로잡았습니다.

다음 문제는 빌드 속도였습니다. Java 기반 서비스의 빌드 시간은 보통 10~15분이 걸렸습니다. 사람이 작업할 때 15분은 잠깐 다른 일을 다녀올 수 있는 시간이지만, 에이전트에게 15분은 치명적인 병목입니다. 코드를 고치고 결과를 확인하는 과정을 여러 번 거쳐야 하는 에이전트가 매번 15분씩 기다린다면 자율 개발은 사실상 불가능해집니다. 팀은 기존 빌드 인프라 운영 경험을 살려 에이전트 전용 쿠버네티스 노드 풀을 따로 꾸리고, 호스트 머신에서 직접 마운트한 빌드 캐시를 연결했습니다. 노드 풀은 같은 목적의 서버들을 묶어 둔 그룹을 말하며, 빌드 캐시는 이전에 만든 결과물을 저장해 두고 재사용하는 장치입니다. 그 결과 대부분의 저장소에서 첫 빌드 시간이 2~3분으로 대폭 줄었습니다.

Crucible 도입 전후 빌드 시간 비교

마지막 문제는 자원 조율이었습니다. 다루는 저장소의 크기에 따라 필요한 하드웨어 자원, 특히 메모리 요구량이 제각각이었습니다. 팀은 쿠버네티스가 제공하는 수직적 확장 기능을 활용해, 작업 크기에 맞춰 필요한 메모리를 유연하게 할당하는 방식으로 문제를 풀었습니다.

Sidekick으로 이어지는 세 가지 일상 흐름

HubSpot은 이 실행 기반 위에 기존 사내 인공지능 비서였던 Sidekick을 확장해 GitHub과 Slack에 연결했습니다. 엔지니어는 별도의 복잡한 도구를 열 필요 없이, 평소 쓰던 GitHub 이슈나 Slack 대화창에서 Sidekick을 호출해 에이전트를 부려 먹을 수 있습니다. 일상적인 업무 흐름은 크게 세 가지로 나뉩니다.

첫 번째는 이슈 계획 흐름입니다. 엔지니어가 GitHub 이슈 본문에 @SidekickAI create a plan이라는 명령어를 남기면, 에이전트가 구현 계획을 작성해 해당 이슈의 댓글로 게시합니다. 엔지니어는 이 계획을 읽고 수정할 부분을 다듬은 뒤 다음 단계로 넘어갑니다.

실제로는 이 계획 단계에서 에이전트가 작업할 대상 코드의 위치를 정확히 짚어 낼 수 있도록, 이슈 내용을 분석해 관련 파일 경로와 함수 형태를 찾아내 프롬프트에 넣어 주는 코드 검색 과정이 돌아갔을 것입니다. 또한 사내 코딩 스타일과 기존 코드 패턴 예시를 함께 전달하는 과정도 거쳤을 가능성이 높습니다.

두 번째는 자율 구현 흐름입니다. 계획이 확정되고 이슈 담당자로 Sidekick을 지정하면, 에이전트가 스스로 코드를 고치고 테스트를 돌린 뒤 PR을 직접 만들어 냅니다. 이때 이슈의 상세 내용, 변경 사항을 커밋하고 푸시하라는 지시, 후속 댓글을 남기거나 PR 본문을 직접 수정해 사용자와 소통하는 방법 등이 정형화된 템플릿 프롬프트로 에이전트에게 전달됩니다.

세 번째는 PR 리뷰 흐름입니다. 사람이 작성한 새로운 PR이 올라오거나, 작업 상태가 “리뷰 준비 완료”로 바뀌거나, 리뷰어로 Sidekick이 지정되면 에이전트가 자동으로 검토를 시작합니다.

원문은 에이전트가 짠 코드에서 중복 코드와 기존 패턴과의 불일치가 가장 자주 발견된다고 짚었습니다. 따라서 리뷰 에이전트는 이미 존재하는 유사 코드를 검색해 대조하는 장치나, 지적 사항을 반드시 고쳐야 할 것과 단순 제안으로 나누는 분류 체계를 갖추었을 것입니다.

정해진 코드로 세운 규칙과 훅이라는 제동 장치

자율 구현 흐름이 안정적으로 돌아가게 만든 핵심 비결은 인공지능에 대한 과도한 기대를 버린 데 있습니다. 팀은 두 가지 신뢰성 원칙을 철저히 지켰습니다.

첫째는 인공지능의 유연함이 필요한 영역과 일반적인 코드로 처리할 영역을 엄격하게 나눈 것입니다. 인공지능 모델에 모든 과정을 맡기면 예상치 못한 실수가 겹치게 됩니다. HubSpot은 이슈 작업이 시작될 때 새로운 브랜치를 만들고 초안 PR을 올리는 필수 작업을 에이전트에게 맡기지 않았습니다. 항상 정해진 규칙을 따르는 사내 코드가 브랜치와 초안 PR을 먼저 만들고, 생성된 브랜치 이름과 PR 번호를 에이전트 프롬프트에 변수로 채워 넣어 주었습니다.

둘째는 Claude Code의 훅 기능을 활용해 에이전트의 행동을 강제한 것입니다. 훅은 정해진 시점에 자동으로 끼어들어 규칙을 검사하는 안전장치입니다. 현재 운영 중인 대표적인 훅 규칙은 다음과 같습니다.

커밋 메시지가 지나치게 길면 자동으로 저장을 차단합니다. Java에서 패키지 전체 경로를 길게 적는 것처럼 사내 관례에 어긋나는 코드 편집이 일어나면 첫 번째 시도에는 저장을 막고, 두 번째 시도에만 허용합니다. 그리고 가장 중요한 규칙으로, 사내 빌드가 통과하고 모든 변경 사항이 GitHub에 커밋되고 푸시될 때까지 에이전트가 임의로 작업을 끝마치지 못하게 강제로 붙잡아 둡니다.

이 밖에도 수만 개의 저장소 가운데 작업에 적합한 올바른 저장소를 고르는 일은 아주 작고 가벼운 전담 에이전트에게 맡겼습니다. 이 작은 에이전트는 이슈 본문에서 서비스 이름이나 기능 영역을 추출해 사내 서비스 목록과 담당 팀 정보와 대조하는 방식으로 후보 저장소를 좁혔을 것이며, 엔지니어가 이슈에 저장소를 직접 적어 주는 예외 경로도 함께 두었을 것입니다. 또한 나중에 생성된 PR을 추적하기 위해 브랜치 이름과 PR 본문에는 담당 엔지니어의 사용자 이름을 자동으로 새겨 넣도록 설계했습니다.

6개월 만에 병합된 7,000건의 PR과 남겨진 기준

Crucible이 배포된 지 6개월 만에, 인공지능이 처음부터 끝까지 만든 PR이 7,000건 이상 사내 코드베이스에 최종 병합되었습니다. 사람이 작성한 코드를 대상으로 에이전트가 코드 리뷰를 수행한 PR도 50,000건을 넘어섰습니다.

현재 대부분의 HubSpot 엔지니어는 매일 업무 속도를 높이기 위해 Crucible과 Sidekick을 사용하고 있습니다. 또한 이 플랫폼은 개별 기능 구현에 그치지 않고 대규모 코드 마이그레이션 작업을 자동화하거나, 빌드에 실패한 코드를 인공지능이 스스로 찾아내 수정하는 등 사내 여러 자동화 업무로 쓰임새를 넓혀 가고 있습니다.

이 사례는 인공지능 에이전트를 도입하려는 기업 리더와 실무자에게 명확한 기준을 제시합니다. 외부 서비스를 구독하는 것만으로는 해결하기 어려운 복잡한 사내 시스템을 지녔다면, 자체 인프라를 구축하는 편이 장기적으로 훨씬 강력한 통제력을 줍니다. 10분이 넘던 빌드 시간을 2~3분으로 줄여 피드백 고리를 확보하고, 훅 시스템으로 작업 완료 조건을 강제한 엔지니어링이 뒷받침되었기에 7,000건의 병합이라는 실질적인 숫자가 나올 수 있었습니다.

하지만 이 방식을 모든 조직이 무작정 따라 할 수는 없습니다. 쿠버네티스와 컨테이너 환경을 자체적으로 안정되게 운영할 수 있는 숙련된 인력이 먼저 준비되어 있어야 합니다. 또한 수많은 사내 도구를 컨테이너용으로 일일이 뜯어고치는 막대한 공수를 감당할 수 있어야 하며, 그 투자를 회수할 만큼 엔지니어 수와 사용 빈도가 충분한 규모를 갖추고 있어야 합니다. 플랫폼의 토대를 먼저 단단히 다져야만 에이전트도 비로소 일터의 믿음직한 동료로 기능할 수 있습니다.

---

출처

HubSpot Product Blog — Cloud Coding Agents at HubSpot — https://product.hubspot.com/blog/cloud-coding-agents-at-hubspot — 2026-01-23 (Stephan Lensky)