ChatOps: 채팅에서 운영하기

ChatOps란

ChatOps는 대화 중심 개발(conversation-driven development)이다. 팀원이 채팅방에서 명령을 입력하면 봇이 미리 만든 스크립트·연동을 실행한다. 배포, 서버 상태 조회, 알림 확인, 장애 대응, 담당자 호출이 모두 채팅방 안에서 일어난다. 이름은 GitHub이 사내 봇 Hubot으로 운영하던 방식에서 퍼졌다.

ChatOps는 도구를 대화의 한가운데에 둔다. 각자 터미널에서 조용히 치던 명령이 모두가 보는 방에서 실행되고, 결과가 그 자리에 남는다.

flowchart TB
  user["사람: /deploy api production"] --> chat["채팅 플랫폼"]
  chat --> bot["봇·앱<br/>(권한 확인, 명령 해석)"]
  bot --> be["실행 백엔드<br/>(CI/CD, 배포 서버, 클라우드 API)"]
  be --> rep["진행·결과를 같은 채널에 보고"]
  mon["모니터링·알림"] -->|"같은 채널로"| rep

구성 요소

요소	역할	예
채팅 플랫폼	대화와 기록이 쌓이는 곳	Slack, Microsoft Teams, Mattermost
봇·앱	명령을 해석하고 권한을 확인해 작업을 부른다	슬래시 명령을 받는 사내 앱, Hubot(Node.js)·Errbot(Python)·Lita(Ruby) 같은 오픈 소스 봇
실행 백엔드	무거운 작업을 백그라운드로 처리한다. 봇은 지시만 하고 실제 배포는 배포 서버가 한다	CI/CD 파이프라인, 배포 서비스, 클라우드 API
연동	외부 시스템의 이벤트를 채널로 끌어온다	GitHub·GitLab 알림(`/github subscribe owner/repo`), 모니터링 경보, 장애 관리 도구

얻는 것

효과	내용
투명성	"누가 이 명령을 돌렸지?"를 찾을 필요가 없다. 모든 실행과 결과가 한곳에 보인다
보면서 배우기	신입이 방에서 선배의 진단·배포 과정을 그대로 보고 같은 명령을 따라 한다. 문서보다 빠른 온보딩이 된다
실수 감소	손으로 치던 SQL·서버 명령을 테스트된 스크립트로 바꾼다. 위험한 작업에 확인 단계를 넣는다
셀프 서비스	다른 팀이 티켓을 주고받지 않고 봇에게 직접 요청한다(배포 상태, 담당자, 시스템 설명). 비개발 직군도 인프라 상황을 안다
감사 기록	채팅 기록이 "언제 누가 무엇을 했나"의 타임라인이 된다. 장애 회고의 재료다

도입 단계

한 번에 설치하는 제품이 아니라 팀이 조금씩 옮겨 가는 방식이다.

단계	모습
1. 시험	일부 팀이 그룹 채팅을 쓴다. 공식 소통은 아직 이메일이다
2. 주제별 방	이메일 스레드와 회의를 주제·프로젝트별 상시 채널이 대신한다. "모두가 아는 것을 모두가 안다"
3. 알림과 슬래시 명령	CI·배포·모니터링 알림이 채널로 들어오고, 기술 팀이 슬래시 명령을 쓰기 시작한다
4. 봇 자동화	반복 작업을 봇이 맡는다. 앱을 오가며 찾던 정보를 채팅 안에서 조회한다
5. 운영 콘솔로서의 채팅	계획된 일과 장애 같은 계획에 없던 일이 모두 채팅 흐름 위에서 처리된다. 봇·AI 에이전트가 진단과 조치를 거든다

처음에는 DNS 조회, 배포 상태 확인처럼 읽기 전용·부작용 없는 명령부터 붙인다. 익숙해진 뒤 쓰기 작업으로 넓힌다.

장애 대응에서

ChatOps가 가장 크게 효과를 내는 곳이 장애 대응이다. 장애마다 전용 채널을 열고, 경보·그래프·조치·결정을 모두 그 채널에 남긴다. 담당자 호출(on-call 페이징), 상태 페이지 갱신, 롤백 명령을 같은 곳에서 실행하면 회고 때 타임라인을 따로 복원할 필요가 없다. 장애 대응 단계와 포스트모템은 장애 대응과 포스트모템에 있다.

위험과 지킬 것

위험	대응
봇이 과한 권한을 가진다	명령마다 누가 실행할 수 있는지 정한다. 운영 배포는 승인자·확인 단계를 둔다. 봇 토큰은 최소 권한으로
비밀이 채팅에 남는다	명령 인자·출력에 키·토큰·개인정보가 찍히지 않게 한다. 채팅 기록은 오래 남고 검색된다
알림 피로	모든 이벤트를 채널에 쏟으면 아무도 안 본다. 행동이 필요한 알림만 보내고 채널을 용도별로 나눈다
같은 명령의 중복 실행	두 사람이 동시에 `/deploy`를 쳐도 안전하게 멱등적으로 만들거나 잠금을 건다
채팅이 유일한 기록	결정과 결과는 이슈·문서·포스트모템으로도 옮긴다. 채팅 플랫폼은 바뀔 수 있다

ChatOps라는 말은 2010년대 초 GitHub이 Hubot으로 배포와 조회를 채팅에서 하던 방식(Hubot이 배포 서버 Heaven에 지시)에서 퍼졌다. 당시 채팅 플랫폼으로는 Campfire, HipChat, Flowdock이 쓰였고, HipChat은 2019년 서비스를 끝내고 Slack으로 사용자를 넘겼다. 지금은 봇을 직접 띄우기보다 채팅 플랫폼의 앱·슬래시 명령과 각 서비스가 제공하는 공식 연동을 조합하는 경우가 많다.

정리

ChatOps = 채팅방 + 봇 + 실행 백엔드 + 연동. 운영 작업을 모두가 보는 곳에서 실행한다.
얻는 것은 투명성, 보면서 배우기, 스크립트화로 줄어든 실수, 셀프 서비스, 감사 기록이다.
읽기 전용 명령부터 시작해 쓰기 작업으로 넓힌다.
권한·비밀·알림 피로·중복 실행을 설계 단계에서 막는다.

버그 제보