의사결정과 실행 간격을 비동기 워커로 자동화한 이야기

아이디어나 정책 결정이 나온 후, 그걸 실제 시스템에 반영하는 과정이 얼마나 번거로운지 아는가. 팀원들이 회의에서 "이 기능 켜자" "이 정책 적용하자"라고 결정하면, 누군가 수동으로 각 시스템에 명령을 날리고, 설정을 바꾸고, 배포를 해야 한다. 결정은 빠르지만 실행은 느리고, 그 사이 실수가 끼어든다.

이번 작업은 그 간격을 워커 패턴으로 줄이는 작업이었다. 의사결정 시스템(brainstorm)에서 나온 결정을 비동기 워커가 자동으로 감지하고 실행하도록 만들었다.

왜 워커 패턴이었나

처음엔 의사결정이 나면 바로 동기 호출로 처리하면 되지 않을까 생각할 수 있다. 하지만 결정의 영향 범위가 넓을수록 문제가 생긴다:

• 응답 시간 변동: 결정 하나가 10개 시스템에 영향을 주면, 가장 느린 시스템이 전체 응답 시간을 결정한다.
• 실패 처리: 중간에 한 시스템이 실패하면 롤백이 복잡하다.
• 재시도와 모니터링: 일시적 오류는 자동 재시도가 필요한데, 동기 호출 안에서는 복잡하다.

워커 패턴을 쓰면:
- 결정이 나는 순간 즉시 큐에 들어가고, 응답은 빠르다.
- 워커가 백그라운드에서 차분히 처리한다.
- 개별 스텝의 실패를 격리하고 재시도할 수 있다.

2개 파일의 역할

bot-action-worker.py — 워커 핵심 로직
- 큐에서 대기 중인 작업을 뽑아 처리하는 진입점
- 각 작업의 생명주기 관리 (시작 → 실행 → 완료 또는 재시도)
- 실패 처리 및 로깅, 메트릭 수집
- 다른 워커들이 상속할 수 있게 설계할 가능성

brainstorm_exec.py — 의사결정 실행 로직
- 결정 객체를 받아 "어떤 결정인지" 해석
- 필요한 액션들을 조합 (예: 기능 활성화, 알림 발송, 감사 로그 기록)
- 각 액션의 성공/실패를 추적

두 파일을 분리한 이유는 명확한 책임 분담이다. 워커의 일반적 패턴은 다른 곳에서도 쓸 수 있게 하고, 의사결정 해석 로직은 변화에 빠르게 대응할 수 있게.

팀 관점에서 본 변화

이걸 도입하면 팀의 의사결정 사이클이 짧아진다:

# Before: 수동 개입 필요
meeting_decision = "기능 X 켜기"
→ 누군가 수동으로 각 시스템에 명령 → 실수 위험 → 검증 필요

# After: 자동 워커
meeting_decision = "기능 X 켜기"
→ brainstorm_exec가 결정을 해석
→ bot-action-worker가 비동기로 실행
→ 감사 로그/알림 자동 생성

운영 관점에서는 우리팀이 아닌 다른 팀에서도 결정이 빨리 반영된다는 뜻이다. 지금까지는 "누구한테 언제 요청해야 하지?"였던 게 "결정만 하면 자동 처리"가 된다.

배운 점과 주의할 것

워커를 도입할 때 놓치기 쉬운 부분들:

• 멱등성(idempotency): 같은 결정이 두 번 실행되면? 워커 재시도나 중복 메시지로 같은 작업이 두 번 돌 수 있다. 각 액션은 "두 번 실행해도 안전하게" 설계해야 한다.
• 모니터링과 알림: 워커가 돌고 있는데 제대로 도는지 누가 알까? 로깅, 메트릭(처리량, 지연시간, 실패율), 알림이 필수다.
• 상태 추적: 결정이 "실행 중"인지 "완료"인지 "실패했다가 재시도 중"인지 팀이 알아야 한다.

또한, 워커 패턴은 "한 번의 결정"뿐만 아니라 "정기적 작업", "이벤트 기반 자동화" 등 여러 곳에 적용된다. bot-action-worker.py를 잘 설계하면 나중에 다른 자동화도 같은 기반 위에 쌓을 수 있다.

처음엔 단순히 "워커"라고 생각했지만, 결국 팀의 의사결정 신뢰도를 올리는 작업이었다. 결정과 실행 사이의 갭이 줄어들수록, 팀원들은 자신의 결정이 정말 반영된다는 확신을 가진다.

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

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

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