GitHub 2011–2020: Hubot이 채팅을 배포 콘솔로 바꾸다

2011년까지 GitHub의 작은 팀은 Campfire 채팅에서 인프라를 운영했고, 그들의 봇은 '더 크고 더 지저분하게' 자라 있었다. 그들은 봇을 처음부터 다시 작성해 Hubot으로 오픈소스화했다. 코드를 배포하고, CI 서버를 앞에서 처리하며, 운영 명령을 회사 전체에 보이게 만드는 봇이었다.

도구를 채팅방 안에 두는 것: 코드를 배포하고 CI를 실행하며 오류가 급증하면 마지막 배포자에게 알림을 보내는 봇 — 모든 행동이 가시적이고 감사 가능하며 모두에게 열려 있다.

Hubot은 '/deploy my-feature' 같은 명령을 듣는다. 엔지니어들은 채팅에서 배포하고, 예외 발생률이 급증하면 봇은 내부 Haystack 대시보드 링크와 함께 마지막 배포자에게 알림을 보내 암묵적으로 책임을 부여한다. 2011년에 오픈소스화되었고, 2020년까지 GitHub은 여전히 ChatOps를 통해 주당 120–150회의 프로덕션 배포를 실행했으며, 카나리 롤아웃과 배포당 수백 개의 풀 리퀘스트를 일괄 처리했다.

GitHub의 배포는 누구나 실행하고 모두가 볼 수 있는 채팅 명령이 되었다. 같은 주간 배포 횟수로 이제 훨씬 더 많은 변경을 배포하며, 롤백은 '신뢰의 문화'를 구축할 수 있을 만큼 낮게 유지되었고, ChatOps라는 용어는 팀들이 이 패턴을 모방하면서 업계 전반으로 퍼졌다.

2011년 GitHub은 매우 큰 서비스를 운영하는 작은 회사였고, 그들의 팀은 Campfire 채팅에 살았다. 그들의 봇은 '더 크고 더 지저분하게' 자라 있었기에, 그들은 봇을 처음부터 다시 작성해 오픈소스화했다. Hubot은 '놀라운 Campfire 봇'으로서 그들을 웃게 했고, 그들의 코드를 배포했으며, CI 서버의 인터페이스 역할을 했다.

이 관행은 GitHub이 ChatOps라고 부르는 것으로 성장했다. 엔지니어들은 채팅에서 '/deploy my-feature'를 실행하고, Hubot은 인증, 스테이징, 카나리 롤아웃을 처리한다. 배포 후 예외가 급증하면 Hubot은 GitHub의 내부 예외 대시보드인 Haystack 링크와 함께 마지막 배포자에게 알림을 보낸다 — '이 알림의 즉각적인 이점은 암묵적으로 책임자를 지정한다는 것이다'.

2020년까지 이 패턴은 성숙했다. GitHub의 배포 팀은 '일련의 Hubot 명령'으로 시작된 배포를 설명했으며, github.com을 위해 주당 120–150회의 프로덕션 배포를 실행했고, 한 주에 400개 이상의 풀 리퀘스트를 배포했으며, 프로세스에 대한 신뢰가 충분해 롤백이 낮게 유지되고 개발자들은 병합 후 다음으로 넘어갈 수 있었다.

'누가 프로덕션을 건드릴 수 있는가'라는 병목을 제거했다 — 어떤 엔지니어든 채팅에서 배포할 수 있었고, 그 행동은 회사 전체에 보였다.

봇은 책임을 암묵적으로 만들었다. 오류가 급증하면 마지막 배포자에게 알림이 가므로, 문제는 분류를 기다리는 대신 주인을 찾는다.

모든 명령이 공유 채널에서 실행되었기 때문에 배포는 감사 가능하고 가르칠 수 있게 되었다 — 새 엔지니어들은 채팅을 보며 운영을 배웠다.

Hubot을 오픈소스화한 것은 내부의 편의를 업계 패턴으로 바꾸어 ChatOps라는 용어를 대중화했다.

내부 도구는 행동의 사회적 비용을 낮출 때 이긴다. 운영을 채팅에 두는 것은 배포를 가시적이고 감사 가능하며 안전하게 위임할 수 있게 만들었다 — 인터페이스의 변화가 문화를 바꾼 것이다.

ChatOps는 널리 모방된 관행이 되었고, Hubot은 Slack, Discord, Teams용 어댑터를 갖춘 커뮤니티 프로젝트로 성장했다. GitHub에서는 배포 파이프라인이 계속 진화했다 — IssueOps와 GitHub Actions가 나중에 같은 아이디어 위에 구축되었다 — 반면 사람들이 이미 공유하는 도구에서 인프라를 실행할 수 있게 하는 근본 원칙은 GitHub이 배포하는 방식의 중심에 남아 있었다.