Checkout.com의 HAL, PR 18%를 쓰다

요약

• Checkout.com은 사내 인공지능 에이전트에 작고 명확한 단위의 개발 업무를 맡겼습니다.
• 전체 코드 변경 요청의 18%를 에이전트가 만들었지만 자동 머지는 허용하지 않았습니다.
• 도구의 자율성에 기대기보다 사람이 쉽게 검토할 수 있는 통제 절차를 세워야 합니다.

개발자를 가로막는 실제 병목은 어디에 있었나

글로벌 결제 기업 Checkout.com의 엔지니어링 블로그에서 수석 아키텍트이자 엔지니어링 부사장인 Adrian Asher가 공개한 글은 인공지능 도구에 관한 흔한 기대와 정반대의 길을 보여줍니다. 많은 조직이 개발자 열 명분의 몫을 한 번에 해낸다는 화려한 시연에 주목하지만, 실제 금융 결제를 다루는 환경에서는 그런 방식의 자율성을 받아들이기 어렵습니다. 작은 코드 오류 하나가 대규모 결제 장애로 이어질 수 있기 때문입니다.

도입 전 개발 조직을 지치게 한 문제는 코드를 입력하는 속도가 아니었습니다. 개발 흐름 곳곳에 숨어 있는 마찰이 더 큰 문제였습니다. 무엇을 만들어야 할지 모호하게 적힌 티켓을 마주하면 요구사항을 확인하고 합의하는 데에만 최대 일주일이 걸리기도 했습니다. 티켓은 개발자가 처리해야 할 작업 단위와 명세를 적어 둔 작업 카드입니다.

정작 코드를 고쳐서 검토를 요청해도 문제는 이어졌습니다. 개발자가 코드 변경 검토 요청인 PR(풀 리퀘스트)을 열어 두면, 동료들이 검토하는 사이에 기준이 되는 main 브랜치에 다른 코드들이 계속 합쳐졌습니다. 그 결과 변경 사항이 뒤처지고 충돌이 쌓이는 브랜치 부패가 일어났습니다.

지속적 통합을 뜻하는 CI 환경에서 자동 검사가 실패하기라도 하면 PR은 방치되기 일쑤였습니다. 결국 검토하려는 시점에는 바로 합칠 수 없는 상태가 되어 다시 손을 대야 했습니다.

여기에 서비스 운영 중 수시로 들어오는 점검 작업이 개발자의 집중을 끊었습니다. 특히 금요일 오후에 취약점 경고가 쏟아지면 실제 위험과 단순한 알림이 뒤섞여 있어 선별 작업에만 반나절이 걸렸습니다. 사내 대시보드에 필터 하나를 추가하는 일처럼 범위가 좁고 명확한 작업들은 늘 규모가 큰 핵심 과제나 긴급한 문제에 밀려 몇 주씩 대기 목록에 머물렀습니다.

스스로 관리하는 PR을 만들다

Checkout.com은 이러한 마찰을 줄이기 위해 사내 AI 코딩 에이전트인 Agent HAL을 개발 파이프라인 안에 직접 연결했습니다. 이후 HAL이라고 불린 이 에이전트는 대화창 안에서 질문을 기다리지 않고, 개발팀이 매일 쓰는 도구 안에서 정해진 세 가지 통로로만 일을 받습니다. 특정 라벨이 붙은 티켓, 주기적으로 실행되는 예약 작업, 그리고 자신이 이미 열어 둔 PR에서 일어난 활동이 그 통로입니다.

HAL이 내놓는 결과물은 언제나 사람이 검토할 수 있는 PR 형태입니다. 에이전트는 초안만 던져 두고 떠나지 않습니다. 자신이 생성한 PR의 전체 수명주기를 끝까지 관리합니다.

스스로 코드 변경을 먼저 검토하고, CI 검사가 실패하면 무엇이 잘못되었는지 진단하여 수정 커밋을 올립니다. main 브랜치에 다른 개발자의 코드가 합쳐질 때마다 변경 사항을 최신 상태로 맞추는 리베이스를 이어갑니다. 리베이스는 작업 중인 브랜치의 기준점을 최신 main 브랜치 끝으로 옮겨 충돌을 없애는 작업입니다.

실제 시스템에서는 티켓 라벨이나 스케줄러가 동작 신호를 보내면 HAL이 작업 브랜치를 만들고 코드를 수정했을 것입니다. PR이 열린 뒤에는 CI 시스템이 실패 신호를 보낼 때마다 에이전트가 오류 복구 루프를 돌며 수정 코드를 덧붙였을 가능성이 높습니다. 덕분에 사람이 검토를 시작하는 순간에는 모든 자동 검사가 통과되어 있고 충돌도 없어 바로 main 브랜치에 합칠 수 있는 상태가 유지됩니다.

HAL의 작업 및 머지 흐름

요구사항을 묻고 검증자를 분리하다

좋은 결과물은 선명한 명세에서 시작합니다. HAL은 정해진 일정에 따라 새로 들어온 티켓을 읽고 개발을 시작할 준비가 얼마나 되었는지 준비도 점수를 매깁니다. 그리고 그 점수를 티켓에 다시 기록합니다.

티켓 내용이 너무 부실하고 맥락이 부족하면 섣불리 코드를 짜지 않습니다. 대신 무엇이 부족한지 구체적인 세부 내용을 요구합니다. 에이전트가 명확한 정보를 계속 묻기 때문에 조직의 작업 대기 목록인 백로그는 자연스럽게 다듬어집니다.

실제 구현에서는 대기 목록에 적힌 설명의 구체성이나 완료 조건, 관련 명세를 확인하여 점수를 산출했을 것입니다. 기준에 미치지 못하면 질문을 댓글로 남겨 작업을 멈추고, 명세가 충분히 선명해진 티켓만 골라 구현 단계로 넘겼을 것입니다.

새로운 기능 개발도 작은 단위라면 HAL이 훌륭하게 처리합니다. 몇 주 동안 대기 목록에 놓여 있던 사내 대시보드 필터 추가 작업이 대표적입니다. HAL이 티켓을 넘겨받자 그날 오후에 PR이 열렸고, 동료 검토를 거쳐 같은 날 머지까지 끝났습니다. 새로운 API 엔드포인트를 추가하거나 웹 화면의 일부를 바꾸는 작업도 같은 방식으로 처리됩니다.

코드를 다 짰다고 해서 곧바로 PR이 열리지는 않습니다. 코드를 작성한 페르소나와 완전히 분리된 별도의 리뷰 페르소나가 새로운 맥락과 시스템 지침을 바탕으로 변경 사항을 먼저 검증합니다. 같은 맥락 안에서 명세를 읽고 코드를 작성하고 스스로 채점까지 맡기면, 잘못 이해한 내용을 확신을 갖고 두 번 반복하는 오류에 빠지기 때문입니다. 작성된 코드가 티켓의 명세를 충족하지 못하면 HAL은 부족한 점을 밝히고 작업을 멈춥니다.

금요일 오후의 취약점 알림을 넘기다

유지보수 업무에서도 HAL은 마찰을 덜어 줍니다. 서비스 운영 중에 보안 취약점 알림이 도착하면 HAL이 티켓을 가져와 경고 내용을 확인합니다. 외부 라이브러리 의존성을 업데이트하고 안전한 버전을 고정한 뒤, 테스트를 실행하고 PR을 열어 알림을 해제합니다.

검토하는 엔지니어의 일은 매우 단순해집니다. 변경된 부분이 라이브러리 버전뿐인지 확인하고, 테스트 결과 로그를 가볍게 훑어본 뒤 승인 버튼을 누르면 됩니다.

실제로는 라이브러리 설정 파일 외에 다른 코드가 바뀌지 않도록 제한하는 장치를 두고, 테스트 로그를 PR 설명에 자동으로 붙여 검토를 도왔을 것입니다. 같은 작업이 여러 소프트웨어 저장소에 걸쳐 정기적으로 실행되기 때문에, 금요일 오후마다 개발자를 괴롭히던 보안 알림 처리 시간은 반나절에서 짧은 확인 작업으로 줄었습니다.

통제할 수 없는 자율성은 두지 않는다

Checkout.com은 에이전트의 작동 원칙으로 자율성이 아닌 통제를 선택했습니다. HAL이 수행한 모든 실행은 어떤 지시를 받아 시작되었는지 추적할 수 있습니다. 엔지니어는 필요할 때 단 한 번의 조작으로 에이전트를 즉시 멈출 수 있으며, 사람이 남긴 피드백은 다음 실행에 반영됩니다.

거버넌스 규칙도 엄격합니다. 무엇을 만들지 결정한 사람은 그 작업이 어떻게 만들어졌는지를 최종 승인할 수 없습니다.

가장 중요한 안전장치는 자동 머지 금지입니다. HAL이 생성한 PR도 사람이 직접 작성한 PR과 똑같은 품질 관문을 통과해야 합니다. 단위 테스트와 통합 테스트를 거쳐야 하고, 보안 검사를 통과해야 하며, 이름이 지정된 승인자의 리뷰를 받아야 합니다.

어떤 PR도 자동으로 합쳐지지 않습니다. 결제 기업에서는 충분한 검토 없이 도장만 찍는 승인을 결코 받아들일 수 없기 때문입니다. 조직이 믿는 대상은 에이전트라는 인공지능 모델이 아니라, 코드가 거쳐 가는 검증 절차 그 자체입니다.

개발자가 되찾은 시간의 의미

2026년 6월 17일 기준으로 Checkout.com 전체에서 새로 열린 PR의 18%를 HAL이 생성하고 있습니다. 머지가 완료된 비율이 아니라 열린 PR 기준의 수치이지만, 전체 변경 요청의 5분의 1에 가까운 물량을 에이전트가 만들어 내고 있다는 뜻입니다.

Checkout.com은 이 성과를 작성된 코드 줄 수나 속도만으로 평가하지 않습니다. 핵심은 인지적 부담을 덜어낸 데 있습니다. 맥락은 적게 필요하지만 처리에 드는 번거로움이 컸던 반복 업무를 백그라운드 에이전트에 넘김으로써, 엔지니어들은 미뤄 두던 일의 짐을 벗고 온전히 집중해야 할 본연의 개발 업무를 지킬 수 있게 되었습니다.

작은 일상 업무 몇 가지를 거대 언어 모델이 처리할 수 있는지 시험해 보려던 작은 실험은 이제 Checkout.com이 소프트웨어를 배포하는 핵심 방식이 되었습니다.

이 사례가 주는 교훈은 분명합니다. 인공지능을 도입할 때 모든 것을 스스로 판단하는 전능한 자율 에이전트를 기대할 필요는 없습니다. 오히려 해야 할 일의 범위를 좁고 명확하게 제한하고, 기존 검증 절차 안에 에이전트를 조용히 녹여 넣을 때 실제 생산성이 나옵니다. 사람이 안심하고 검토할 수 있는 단단한 절차를 만드는 것이 성공적인 도입의 첫걸음입니다.

---

출처

Checkout.com Engineering Blog — How our AI coding agent generates 18% of our PRs — https://www.checkout.com/blog/how-agent-hal-ships-software-checkout-com — 2026-06-17