ai-rules › handbook › ChatOps Reference

ChatOps Reference

`openclaw + Telegram` 운영 패턴을 공통 운영 모델에 연결하기 위한 참조 문서

guide 2026-04-03 docs/guide/CHATOPS_REFERENCE.md

작성일: 2026-04-03
목적: openclaw + Telegram 운영 패턴을 공통 운영 모델에 연결하기 위한 참조 문서

1. 위치

openclaw + Telegram은 공통 운영 모델에서 선택형 실험 기능이 아니라, 이미 AITEM에서 사용 중인 ChatOps reference implementation으로 본다.

이 문서의 목적은 두 가지다.

  • 기존 AITEM 운영 패턴을 버리지 않고 공통 모델에 편입한다
  • 다른 프로젝트가 같은 방식으로 붙을 수 있는 최소 기준을 제시한다

2. ChatOps의 역할

ChatOps는 실행 엔진이 아니라 사람과 에이전트 사이의 상호작용 계층이다.

권장 역할:

  • 수동 호출
  • 상태 질의응답
  • 승인 요청
  • blocker 알림
  • daily / weekly 요약 전달

권장하지 않는 역할:

  • 상태의 진실원
  • 유일한 작업 기록 저장소
  • 대규모 자동 수정 루프의 단독 트리거

즉, ChatOps는 인터페이스이고, 상태 원장은 별도로 유지해야 한다.

3. 권장 연결 구조

Scheduler
  -> Agent execution
  -> State update (`SESSION.md`, `WORKLOG`, `ops/agent-events.jsonl`)
  -> ChatOps delivery (`openclaw + Telegram`)
  -> Dashboard refresh

이 구조에서 Telegram 메시지는 결과 전달과 승인 응답 채널이고, 실제 운영 상태는 ops/와 handoff 문서에 남긴다.

4. 공통 패턴

4.1 Daily Scrum

  • 스케줄러가 Leader 또는 동등한 운영 역할을 깨운다
  • 결과를 문서와 이벤트에 기록한다
  • Telegram으로 요약을 보낸다

4.2 Approval Queue

  • approval_needed 이벤트가 생성되면 Telegram으로 전달한다
  • 사용자는 메신저에서 범위 승인 또는 거절을 응답한다
  • 승인 결과는 다시 상태 원장에 기록한다

4.3 Blocker Escalation

  • task_blocked가 일정 시간 이상 지속되면 Telegram으로 에스컬레이션한다
  • 사람이 돌아오면 메신저에서 상세 사유를 질의할 수 있다

5. 다른 프로젝트로 이식할 때 확인할 것

필수

  • 메신저가 없어도 상태가 남는가
  • 승인 결과가 문서나 이벤트로 다시 기록되는가
  • Telegram이 죽어도 스케줄러와 대시보드가 유지되는가

선택

  • 프로젝트별 요약 템플릿
  • 역할별 알림 라우팅
  • blocker severity별 채널 분기

6. 운영 원칙

  • ChatOps는 빠른 상호작용을 담당한다
  • 상태는 문서와 이벤트 원장에 남긴다
  • 승인 정책은 공통 ops/approval-matrix.json을 따른다
  • 프로젝트 차이는 override로만 조정한다

7. Migration Path

기존에 AITEM처럼 openclaw + Telegram을 이미 쓰는 프로젝트는 다음 순서로 공통 모델에 편입한다.

  1. 현재 ChatOps 메시지 패턴을 정리한다
  2. 어떤 메시지가 상태 원장에 다시 기록되는지 확인한다
  3. approval_needed, task_blocked, daily_scrum_completed 같은 핵심 이벤트를 공통 스키마로 맞춘다
  4. 프로젝트별 예외는 ops/approval-overrides/<project>.json으로 옮긴다

즉, 이식의 핵심은 메신저를 바꾸는 것이 아니라, 메신저 뒤에 있는 상태 모델을 공통화하는 것이다.

8. 결론

openclaw + Telegram은 공통 운영 모델의 보조 옵션이 아니라, 이미 검증된 ChatOps 레이어다.

다만 공통화의 기준은 ChatOps 자체가 아니라 다음 세 가지다.

  • 상태를 어디에 남기는가
  • 승인을 어떤 정책으로 해석하는가
  • 메신저와 대시보드가 같은 상태 원장을 보는가