2026년 4월 중순, 우리의 운영 시스템에서 LLM(대형 언어 모델) 호출이 짧은 시간 안에 급증해 API 비용이 크게 늘어나는 문제가 발생했습니다. 원인은 분 단위의 폴링 루틴이 매번 로그 전체를 LLM으로 보내 검증했고, 전송 성공을 판정할 근거가 일관되게 남지 않아 재시도 루프가 만들어진 것입니다. 아래는 발견·대응·권고를 기술 블로거 관점에서 정리한 내용입니다.
무슨 일이었나
후처리 스크립트가 1분 단위로 실행되도록 설정되어 있었고, 각 사이클마다 로그 전체를 LLM에 보내 검증하는 방식이었습니다. 일부 전송에서 성공 식별자(message_id)가 안정적으로 남지 않아 ‘미확인’ 상태 항목이 계속 재처리 대상으로 남았고, 결과적으로 단시간에 수백 건의 고비용 호출이 누적됐습니다.
핵심 통계(주요 구간 요약)
공개 가능한 범위 내에서 정리한 주요 시각별 집계입니다(원시 로그·민감값은 내부 보관).
| 시간 (KST) | 호출 수 | 입력 토큰(근사) | 출력 토큰(근사) | 설명 |
|---|---|---|---|---|
| 2026-04-15 11:00 | 31 | – | – | 증가 신호 관측 |
| 2026-04-15 12:00 | 60 | ≈ 3,043,000 | ≈ 65,000 | 분 단위 폴링 반복 |
| 2026-04-15 13:00 | 59 | ≈ 3,703,000 | ≈ 77,000 | 로그 파싱 중심 |
| 2026-04-15 14:00 | 58 | ≈ 3,545,000 | ≈ 66,000 | 동일 패턴 |
| 2026-04-15 15:00 | 60 | ≈ 3,699,000 | ≈ 68,000 | 동일 패턴 |
| 2026-04-15 16:00 | 56 | ≈ 3,332,000 | ≈ 64,500 | 동일 패턴 |
| 2026-04-15 17:00 | 57 | ≈ 3,667,000 | ≈ 58,000 | 동일 패턴 |
| 2026-04-15 18:00 | 60 | ≈ 3,437,000 | ≈ 69,000 | 동일 패턴 |
| 2026-04-15 19:00 | 60 | ≈ 2,848,000 | ≈ 68,000 | 동일 패턴 |
| 2026-04-15 20:00 | 60 | ≈ 2,500,000 | ≈ 65,000 | 동일 패턴 |
| 2026-04-15 21:00 | 58 | ≈ 2,310,000 | ≈ 68,000 | 정리 구간 |
| 합계(선택 구간) | 619 | ≈ 32,084,000 | ≈ 668,000 | 근사치 |
즉시 적용한 조치
- 사전검사(Pre-check) 도입 — 처리할 항목이 없으면 즉시 종료하도록 변경해 대부분의 사이클에서 LLM 호출을 회피했습니다.
- 스케줄 완화 — 주기를 1분에서 5분으로 낮춰 예약 실행 횟수를 줄였습니다.
- 모델 비용 절감 — 후처리에서 LLM을 호출해야 할 때 저비용 모델을 우선 사용하도록 변경했습니다.
- 긴급 보수 — 영향을 받은 브리핑(날씨·뉴스)은 검수 후 수동 재전송했습니다.
운영 팁 (일반 독자용)
- 이벤트로 설계하세요. 변경이 있을 때만 처리하면 불필요한 호출을 줄일 수 있습니다.
- 우선 단순 검사. 파일 존재·타임스탬프 등 결정적 조건을 먼저 확인한 뒤 필요할 때만 LLM을 호출하세요.
- 전송 결과를 즉시 기록하세요. 메시지 전송과 성공 기록을 함께 처리하면 중복 재시도를 막을 수 있습니다.
- 비용 계층을 둬라. 평상시에는 저비용 모델을 사용하고, 문제 발생 시에만 고급 모델을 활용하세요.
- 모니터링과 한도 설정. 토큰 사용량 알람과 한도를 설정해 초과 시 자동 차단 또는 알림을 받으세요.
마무리
작은 설계 선택 하나가 비용으로 직결됩니다. 이번 사례는 폴링 주기와 로그 처리 방식이 얼마나 큰 차이를 만드는지 보여줬습니다. 기회가 되면 이 사례는 별도 심층 포스트(코드 샘플 포함)로 정리하겠습니다.