자동화 봇 상태 관리를 디스코드 로그와 파일로 이원화해 신뢰성 확보
목차
자동화 봇의 상태 추적 방식을 전면 개선했다. 기존 방식에서 discord_review_log와 review_state.json 기반으로 재설계하면서, 분산 시스템에서 단일 소스(source of truth)를 확보할 수 있게 됐다.
왜 상태 관리를 뜯어고쳤나
자동화 시스템은 언뜻 간단해 보이지만, 실제로는 여러 단계의 작업을 거치고 장시간 실행되곤 한다. 특히 리뷰나 승인 같은 비즈니스 로직이 들어가면, 각 단계에서 "현재 이 작업이 어디까지 왔는가"를 정확히 파악해야 한다.
문제는 봇이 크래시 되거나 네트워크가 끊기면, 어떤 액션이 이미 실행됐는지 재실행됐는지 구분하기 어렵다는 것이었다. 또한 사후에 문제를 추적할 때 봇 로그만으로는 누가 언제 뭘 승인했는지 시간 순서대로 재구성하기 어려웠다.
새로운 접근: 로그와 상태 파일의 이원화
| 역할 | 이전 방식 | 개선 후 |
|---|---|---|
| 실행 기록 | 봇 내부 로그 (재시작 시 휘발) | Discord에 기록된 discord_review_log (영구 저장) |
| 현재 상태 | 메모리 또는 임시 추적 | JSON 파일 기반 review_state.json (인간이 읽을 수 있음) |
| 신뢰 근거 | 단일 소스 불명확 | 로그와 상태 파일로 교차 검증 |
discord_review_log: Discord에 남는 실행 이력. 누가 어떤 판단을 내렸는지, 언제 어떤 액션이 트리거됐는지의 기록review_state.json: 현재 진행 중인 작업의 상태를 JSON으로 저장. 봇이 재시작돼도 마지막 상태를 복구할 수 있게 함
이 패턴이 주는 것들
이런 변경을 하면서 느낀 게, 자동화 시스템의 신뢰성은 코드의 정확성만 아니라 관찰성(observability)에 크게 달렸다는 것이다. 팀원이나 사용자가 "이 봇이 뭐 했는지" 스스로 확인할 수 있으려면, 실행 기록과 상태가 명확하고 접근 가능해야 한다.
특히 Discord 같은 공개 채널에 로그를 남기면:
- 모든 팀원이 봇의 동작을 실시간으로 볼 수 있음
- 사후 감시(audit trail) 역할
- 버그 발생 시 원인 재현이 훨씬 수월함
JSON 파일 기반 상태는 한 걸음 더 나아가, 필요하면 수동 개입도 가능하다. 상태가 꼬였을 때 직접 고칠 수 있고, 스크립트가 어떤 가정 하에 움직이는지도 투명하게 보인다.
자동화 워커 설계의 원칙
이 작업을 하면서 정리된 생각:
- 상태는 외부에: 프로세스 메모리나 임시 저장소에만 두면 안 된다
- 로그는 영구하게: 누구나 접근 가능한 채널(또는 파일)에 기록해야 한다
- 재현 가능성: 같은 상태에서 다시 실행하면 같은 결과가 나와야 한다 (멱등성)
자동화는 "일단 한 번 돌리면 되는" 수준이 아니라, 팀의 신뢰를 얻어야 매일 사용된다. 그 신뢰는 "봇이 뭐 했는지 누구나 확인할 수 있다"는 데서 나온다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.