exe.dev의 VM 기반 봇이 알림을 넘어 CI 변경 제안까지 처리한다

이 사례의 핵심은 크론을 가상 머신으로 옮긴 일이 아니라, 봇의 역할을 문제 발견에서 변경 실행 직전까지 넓힌 데 있다고 봅니다. 기존 봇은 모델 목록의 불일치를 찾아 Slack에 알렸고, 새 봇은 제안된 diff와 CI에 변경을 대기시키는 버튼까지 제공합니다. 사람이 알림을 보고 다시 저장소를 열어 수정하는 단계를 줄인 셈이죠.

자동화는 흔히 “무엇이 잘못됐는지 알려주기”에서 끝납니다. 하지만 알림이 쌓이면 결국 사람이 처리해야 할 미결 작업만 늘어날 수 있습니다. 이 봇은 발견한 문제를 검토 가능한 변경안으로 바꿔 다음 행동을 쉽게 만듭니다. 그래서 생산성 개선의 기준은 봇이 얼마나 많은 메시지를 보내느냐보다 사람이 완료까지 거쳐야 하는 단계가 얼마나 줄었느냐에 가까워야 한다고 봅니다.

기사에 따르면 변경은 바로 배포되는 것이 아니라 CI 시스템에 대기열로 보내집니다. 이 경계는 중요합니다. 봇이 반복 작업을 준비하더라도 결과를 확인하고 실제로 진행할 통제권은 기존 개발 절차에 남길 수 있기 때문입니다. 다만 변경안이 틀렸거나 검사 기준이 부족하면 검토 부담이 다른 형태로 옮겨갈 수 있으니, 자동화가 늘수록 diff의 근거와 실패 시 되돌리는 방법도 분명해야 할 겁니다.

VM을 택한 이유도 단순히 크론이 낡아서라기보다, 작은 봇을 원하는 방식으로 운영하기 쉬워서라고 읽힙니다. 기사에서는 VM 비용이 저렴하다면 맞춤형 봇 서버가 덜 고통스러울 수 있다고 말합니다. 이 방식은 봇의 상태와 인터페이스를 유연하게 다루는 데 유리할 가능성이 있지만, 반대로 서버 관리와 배포 책임도 생깁니다. 비용뿐 아니라 운영자가 감당할 복잡성까지 비교해야 지속 가능한 선택이 되겠죠.

봇이 다른 봇들과 함께 모노레포에 있고 지속적으로 배포된다는 점은, 봇을 일회성 스크립트가 아니라 제품처럼 다루려는 방향으로 보입니다. 공통 코드와 배포 흐름을 공유하면 수정과 관리가 쉬워질 수 있지만, 여러 봇이 같은 배포 체계에 묶이는 만큼 변경이 다른 자동화에 미치는 영향도 살펴야 할 겁니다. 자동화의 신뢰성은 실행 속도보다 변경을 추적하고 통제할 수 있는지에 달려 있습니다.

결국 이 사례가 보여주는 건 더 똑똑한 봇보다 더 잘 설계된 업무 흐름입니다. 반복적으로 생기는 불일치를 찾아내고, 검토 가능한 수정안을 만들고, 기존 CI·CD 절차로 넘기는 연결이 갖춰질 때 자동화는 실제 일을 덜어줍니다. 앞으로 봇의 가치는 사람 대신 얼마나 많이 결정하느냐보다, 사람이 안전하게 결정을 내리고 완료까지 가는 길을 얼마나 짧게 만드느냐로 평가될 가능성이 큽니다.