보험·금융 토픽 자동보충이 일주일간 멈춘 원인과 재발 방지법

지난주 모니터링 대시보드를 확인하다가 이상한 신호를 포착했다. 토픽 자동보충 시스템이 6월 3일부터 0건을 발행하고 있었다. 보험/금융 도메인의 자동 발행 기능이 일주일을 꼬박 작동하지 않은 것. 문제는 생각보다 단순했다—봇 시스템이 마이그레이션되면서 디렉터리 경로가 /opt/X-bot에서 /opt/bots/X로 바뀌었는데, 우리의 자동화 스크립트들은 여전히 이전 경로를 참조하고 있었던 것이다.

그 경로는 어디에 숨어있었나

이 종류의 버그가 까다로운 이유는 '조용하게' 실패한다는 점이다. 스크립트가 존재하지 않는 경로를 찾으면서 에러를 뱉지 않고, 그냥 침묵한다. 크론 작업은 정해진 시간에 계속 실행되고 있었지만, 봇을 찾을 수 없으니 실제 발행은 일어나지 않았다.

변경해야 할 지점은 두 군데였다:

한쪽만 고쳤으면 여전히 일부 케이스에서는 작동하지 않았을 것이다. 두 스크립트가 서로 다른 타이밍과 환경에서 동작하기 때문이다. cron-claude-auth-check는 크론 환경에서 사전 인증을 담당하고, topic-replenish.py는 실제 발행 로직을 수행한다. 이들이 서로 다른 경로를 참조하면 어디선가 항상 실패한다.

침묵하는 장애, 감지하는 방법

여기서 배운 교훈이 있다. 자동화 시스템이 실패했을 때 로그를 남기지 않으면, 그것은 마치 시스템이 성공한 것처럼 보인다. 우리가 이 문제를 며칠 늦게 발견한 이유도 "크론이 정상적으로 도는 것처럼 보였기" 때문이다.

# 문제가 있는 패턴
bot_path = "/opt/X-bot/runner"
if os.path.exists(bot_path):
    execute(bot_path)
# 경로가 없으면 조용히 pass됨

더 나은 접근:

# 개선된 패턴
bot_path = "/opt/bots/X/runner"  # 정확한 경로 참조
try:
    execute(bot_path)
except FileNotFoundError as e:
    log_error(f"Bot not found at {bot_path}: {e}")
    raise  # 시스템이 인지하도록 강제

실패를 명시적으로 로깅하고 던지는 것이 얼마나 중요한지를 다시 한번 느꼈다.

좀 더 근본적인 이야기

조직이 커지면서 여러 팀이 봇 인프라를 관리하게 되고, 어느 팀이 언제 경로를 바꿀지 다른 팀은 알 수 없다. 이런 상황에서 경로 변경(마이그레이션)은 모든 의존자를 동시에 업데이트해야 하는 일이 된다.

혼자 작업할 때는 "음, 봇 폴더 바꾸면 여기도 고쳐야지" 하고 한 번에 처리할 수 있다. 하지만 마이그레이션 공지가 나왔을 때는 여러 팀이 있고, 각 팀은 자신의 스크립트/설정에서 경로를 참조하고 있을 수 있다.

우리 팀의 경우 _lib 아래 두 개 파일이 있었지만, 다른 팀도 비슷하게 봇 경로를 어딘가에 갖고 있을 수 있다. 체크리스트가 필요해 보인다:

• 크론 설정 파일들 (_lib/cron-*)
• 자동화 스크립트 (_lib/*.py 등)
• 설정 파일 (config.yml, .env, 등)
• 아키텍처 문서/매뉴얼 (경로 예시)
• 팀의 온보딩 가이드

하나라도 빠지면 누군가는 계속 이전 경로로 자동화를 돌리고 있을 것이다.

다음

이건 "경로를 잘못 입력했다"는 차원의 버그가 아니다. 이건 시스템이 복잡해지면서 각 계층이 독립적으로 경로를 관리하게 되는 아키텍처 문제다. 더 좋은 방법은:

• 경로를 하드코딩하지 말고 환경 변수로 주입하기
• 환경 변수가 없으면 fail-fast하기 (조용히 실패하지 말기)
• 마이그레이션 시 사전에 영향범위를 명확히 하고 체크리스트 만들기
• 자동화 시스템의 장애를 능동적으로 감지할 수 있는 모니터링 추가하기

이번엔 다행히 6일 안에 고칠 수 있었지만, 이런 '침묵하는 장애'는 한 번의 근본적인 구조 개선으로 예방하는 게 훨씬 비용이 적다.

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

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

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