채널 메시지로 훅을 자동 실행하는 리스너 설계기

특정 채널에서 메시지가 올라오면 자동으로 훅을 실행하는 기능을 listener에 추가했다. 이 작업은 작지만 팀의 워크플로우를 꽤 바꾸는 지점이라 회고 삼아 정리해본다.

왜 채널 감지 자동화가 필요했나

처음엔 수동으로 진행되던 일들이 있다. 누군가 특정 채널에 메시지를 올리면, 다른 누군가 그걸 봤을 때 손으로 다음 단계를 실행한다는 뜻이다. 작은 조직일 때는 괜찮지만, 팀이 커지거나 반복되는 패턴이 명확해지면 이건 기술 부채가 된다.

기획팀이 #기획-브레인스토밍 채널에 아이디어를 정리하면, 개발 쪽에서도 그걸 감지해서 자동으로 뭔가 처리해야 할 필요가 생겼다. 매번 누군가 slack을 보고 손으로 run_brainstorm 훅을 실행하는 것보다, 채널의 메시지 자체가 신호가 되는 구조가 훨씬 낫다. 이렇게 되면:

• 타이밍 의존성 제거 (누가 봤나, 언제 봤나에 따라 달라지지 않음)
• 감시(監視) 비용 제거 (누군가 계속 채널을 모니터링할 필요 없음)
• 감사 추적 명확화 (언제 훅이 실행됐는지 로그에 남음)

Listener 패턴으로 설계하기

listener는 결국 이벤트 기반 아키텍처의 가장 단순한 형태다. 특정 조건(채널 감지)이 발생했을 때 특정 액션(훅 실행)을 자동 트리거한다. listener/listener.py 파일에 이 로직을 담아두면, 나중에 비슷한 패턴들을 쉽게 추가할 수 있다.

흐름이 대략 이렇다:

채널 메시지 이벤트 → listener.detect() 확인 → 규칙 매칭 → run_brainstorm() 호출

listener 관점에서 설계할 때 고민했던 부분들:

특히 규칙을 설정 파일로 분리한 건 중요한 결정이었다. 개발자가 코드를 건드리지 않고도 기획팀 리드가 필요한 채널들을 추가할 수 있으니까.

일반론: Listener 설계의 함정과 도구

이런 유형 작업을 몇 번 했으니 몇 가지 패턴을 정리해본다.

정규성과 지연성 사이의 트레이드오프: 채널 감지를 자주 폴링하면(예: 1초마다) 반응은 빠르지만 부하가 크다. 폴링 주기를 늘리면(예: 1분마다) 반응 지연이 생긴다. 우린 작은 조직이라 1분 주기로 충분했지만, 규모가 커지면 웹훅(webhook) 방식으로 전환해야 할 수도 있다.

규칙 복잡도 관리: 처음엔 "이 채널이면 이 훅"이지만, 나중엔 "이 채널 + 특정 키워드면 다른 훅", "이 사람이 쓴 글이면 다른 훅" 같은 조건들이 쌓인다. 일찍부터 규칙을 DSL이나 데이터 구조로 표현하는 게 좋다. 나중에 코드 문제가 아니라 설정 문제로 취급할 수 있으니까.

모니터링과 알림: 자동화할수록 "정말 작동하는가" 확인이 더 중요해진다. 내가 직접 하는 작업은 실패해도 본인이 안다. 하지만 자동화되면 조용히 실패할 수도 있다. 따라서:
- 훅 실행 성공/실패 로그 필수
- 실패 시 알림 (슬랙 메시지 or 메일)
- 주기적인 메트릭 확인 (지난주 실행 몇 번? 성공률?)

다음 스텝들

이걸 깔아두니 비슷한 패턴들이 계속 보인다. 예를 들어:
- 개발 완료 채널 → 자동 배포 체크리스트 생성
- 버그 리포트 채널 → 자동 이슈 생성
- 마케팅 요청 채널 → 자동 티켓 할당

listener를 확장할 때 핵심은 규칙을 코드가 아니라 설정으로 관리하는 것이다. 그래야 팀이 자유도를 느낀다.

🛒 이 글과 어울리는 추천 상품

• 사무의자 쿠팡에서 보기 →
• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.