자동화 봇 운영현황을 문서에 담다
목차
한 이커머스 서비스 (이미지·스트림 기반 콘텐츠)의 자동화 시스템이 꽤 복잡해졌다. 탤런트 145명, 그들을 관리하는 봇 4종, 주기적으로 도는 cron 작업들, 그리고 사용자 요청 인터페이스. 이 모든 것이 제각각 문서화되거나 머릿속으로만 떠다니던 상황을 한 번에 정리하는 작업을 했다.
분산된 운영 정보를 한데 모으다
팀이 작을 때는 상관없다. 개발자 한두 명이 모든 봇을 만들고 운영하니 당연히 다 안다. 하지만 팀이 커지고 서비스가 자라면서 문제가 생겼다. 새 팀원이 온라인했을 때 "어, 이 봇이 뭐 하는 거지?" 라는 질문이 반복되고, 운영 중 이슈가 생기면 slack 로그를 뒤져야 했다. 특히 cron 작업의 리소스 쿼터 한도 같은 건 누가 정확히 알고 있는지도 불분명했다.
그래서 운영 현황 전용 문서를 꾸려 잡기로 했다. 단순히 "봇 A는 이렇게 작동한다" 수준이 아니라, 실제 운영 중에 발생하는 제약사항들 — 시간당 몇 개 작업까지 동시 실행 가능한가, 탤런트 정보가 언제 동기화되는가, 검증 프로세스는 어떻게 되는가 — 이런 것들을 한곳에 모아 두는 것이다.
145개 항목을 검증하며 정렬하다
| 구성 | 현황 |
|---|---|
| 탤런트/콘텐츠 | 145개 |
| 검증 완료 | 143개 |
| 검증 대기/미확인 | 2개 |
| 자동화 봇 | 4종 |
| 정정 사항 | stale 정보 |
숫자로 보면 단순해 보이지만, 145개를 하나하나 훑어서 현재 상태와 맞추는 작업은 꽤 수고로웠다. 특히 2개를 제외한 143개가 검증되었다는 건 뭐냐면, 데이터베이스의 기록과 실제 운영 상황이 일치하는지 확인했다는 뜻이다.
봇 실수나 시스템 버그로 일부 항목의 상태가 오래전 정보로 남아 있었다. 예를 들어 특정 탤런트가 이미 비활성화되었는데 자동화 시스템이 여전히 그들의 정보를 최신으로 유지하려고 했다든가, 어떤 요청이 이미 처리되었는데 상태가 "pending" 으로 박혀 있다든가. 이런 stale 정보들을 찾아내서 정정했다.
봇 실수 수집이 만드는 패턴 인식
문서 작성 중 가장 소중한 부분은 "봇실수집 완료" 항목이었다. 이건 단순히 "이 봇이 이런 실수를 했다" 를 나열하는 게 아니라, 같은 류의 버그가 또 다른 봇에서 반복되는 걸 막기 위한 일종의 학습 기록이다.
예를 들어:
- 타이밍 이슈: 특정 시간에 데이터 동기화가 겹칠 때 race condition 발생
- 리소스 고갈: 동시성 관리를 안 해서 메모리/연결 한계 도달
- 알림 누락: 에러 처리는 했는데 팀에게 알림만 안 보낸 경우
- 재시도 로직 무한루프: 실패 시 계속 재시도하다가 시스템 부하
이런 패턴들을 정리해 두면, 새로운 봇을 만들 때나 기존 봇을 수정할 때 "아, 이런 실수는 피해야지" 라는 체크리스트가 된다. 코드 리뷰할 때도 "앞서 봇3에서 있던 타이밍 이슈처럼 여기도 race condition 가능성이 있네" 라고 지적할 수 있다.
Cron 쿼터 한도 관리의 현실
자동화가 늘어나면서 꼭 마주치는 문제가 바로 리소스 제약이다. cron 작업은 서버 CPU, 메모리, 네트워크 대역폭을 모두 쓴다. 너무 많은 작업을 동시에 돌리려고 하면 메인 서비스까지 영향을 받는다.
이번 문서에 담은 내용:
- 시간대별 cron 작업 할당 (피크 시간대는 가벼운 작업만)
- 동시 실행 상한선 (예: 동시에 최대 8개까지만)
- 작업 우선순위 (탤런트 업데이트 > 통계 수집 > 로그 정리 순)
- 응급 모드 (서비스 부하가 높으면 자동화 작업 중단)
이 정보가 문서화되지 않으면 어떻게 될까? 새 팀원이 "사용자 요청 처리 자동화를 추가하고 싶은데 매 분마다 돌리면 되겠지?" 라고 할 때, 기존 팀원은 "아니다, 그건 안 된다" 고만 할 수 있다. 하지만 문서에 "왜" 그럴 수밖에 없는지, "어디까지" 가능한지 명시되어 있으면 팀 전체가 같은 제약을 이해하고 설계할 수 있다.
운영 문서의 생명력
이 작업을 하면서 느낀 점은, 운영 문서가 일회성 산출물이면 안 된다는 것이다. 봇이 새로 추가되면 업데이트되어야 하고, 쿼터 한도를 변경하면 바뀌어야 하고, 또 다른 실수가 발생하면 그것도 기록되어야 한다. 단순히 "현황을 기록했다" 는 것만으로는 부족하다. 이 문서가 팀의 의사결정 기준점이 되어야 할 때, 스테일하게 방치되면 오히려 해롭다.
그래서 이번 문서 갱신과 함께 정기적 리뷰 주기도 함께 만들었다. 매월 한 번씩 탤런트 데이터와 맞춰 보고, 새 봇이 배포되면 그 당일에 추가하고, 실수가 발생하면 그날로 stale 정정을 한다. 문서가 제 역할을 하려면 "살아있는 기록" 이어야 한다는 게 배운 점이다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.