multimodal 모델로 운영 모니터링 캡처 자동 분석

결제·정산 현장에서 "직관 알림"이 유독 중요한 이유

결제 운영에서 알림은 사실상 두 계층으로 존재한다. 하나는 명시적 규칙 기반 알림—트랜잭션 실패율 5% 초과, API 응답 지연 500ms 돌파, PG 연결 오류 3회 연속 같은 것들이다. 이쪽은 임계값만 잘 잡으면 심각한 장애를 상당 부분 커버한다. 문제는 두 번째 계층이다. "뭔가 이상한데 숫자로 딱 잡히지 않는" 신호—특정 PG사 응답이 사흘에 걸쳐 220ms → 280ms → 350ms로 완만하게 올라가는 케이스가 전형적이다. 기준치인 500ms를 아직 넘지 않았으니 알림은 조용하다. 하지만 월말 정산 집중 구간에 이 상태가 유지되면 타임아웃이 폭증한다.

결제·정산 플로우는 은행 점검 시간, 카드사 배치 마감, 내부 정산 배치 스케줄이라는 고정 리듬 위에서 돌아간다. 이 리듬이 조금씩 어긋날 때가 가장 위험한데, 그 어긋남은 단일 시점 임계값 알림으로는 보이지 않는다. 추세가 그래프에 보일 뿐이다. 작은 팀에서 엔지니어 1명이 매일 아침 Grafana를 10~15분씩 훑는 비용은 단순히 시간 문제가 아니다. 집중도가 떨어지는 날, 레이아웃에 익숙해져서 변화를 놓치는 날, 그 15분이 정말 필요한 날 다른 일에 밀리는 날—모두 현실이다. 우리가 multimodal 모델을 파이프라인에 끌어들인 것은 이 공백을 메우기 위해서였다.

파이프라인 설계: 단순함을 먼저 검증한다

구조는 의도적으로 최소화했다.

크론 (매일 06:00)
  → Playwright로 대시보드 전체 스크린샷
  → 이미지 base64 인코딩
  → Multimodal 모델 API 호출 (이미지 + 프롬프트)
  → 응답 텍스트 → 슬랙 #ops-morning 채널

06:00을 택한 데는 이유가 있다. 우리 정산 배치는 새벽 2~4시에 집중되고, 카드사 전문 수신은 새벽 5시 전후에 마감된다. 06:00 캡처는 이 모든 배치가 끝난 직후 상태를 찍기 때문에 "정산 결과가 제대로 반영됐는가"를 시각적으로 확인하는 첫 관문이 된다. 캡처 시점을 도메인 리듬에 맞추는 것이 범용 솔루션과의 가장 큰 차이다.

프롬프트는 두 원칙으로 썼다. 첫째, "없으면 없다고 말해달라"를 명시한다. 초기 버전에서 이 문구 없이 테스트했을 때, 평온한 날에도 "다소 높아 보이는 수치가 관찰됩니다"류의 두루뭉술한 경고가 나왔다. 이 문구 하나로 노이즈가 체감상 절반 이하로 줄었다. 둘째, 결제·정산 도메인 용어를 프롬프트에 직접 넣는다. "PG사별 응답 패턴", "정산 배치 완료 여부", "오류율 분포"를 명시하자 모델의 응답이 일반적인 시각 묘사에서 도메인 해석으로 이동했다. API 비용은 이미지 1장 기준 약 $0.010.02 수준이다. 하루 한 번 호출이면 월 $0.30.6—엔지니어가 매일 10분을 절약한다면 월 3시간 이상의 주의력을 되찾는 셈이고, 비용 대비 효과는 계산할 필요도 없다.

실제로 동작한 것: 수치와 사례 두 가지

사례 1 — 배치 충돌 패턴 발견. 특정 시간대(오전 2:00~3:30)에 결제 요청 수가 평소 대비 약 30% 낮아지는 현상을 모델이 이틀 연속으로 "이 구간 트래픽이 눈에 띄게 낮습니다. 다른 시간대 대비 유독 좁은 바 높이가 관찰됩니다"라고 보고했다. 수동 확인 결과, 내부 정산 배치가 같은 시간대에 DB 락을 잡으면서 신규 요청이 큐에 쌓이고 있었다. 실패율이 올라간 게 아니라 요청 자체가 지연된 형태라 규칙 기반 알림은 조용했다. 배치 스케줄을 03:30 이후로 밀었고, 해당 구간 처리량이 정상화됐다.

사례 2 — 색상 변화를 통한 임계값 근접 조기 경고. Grafana 에러율 패널은 정상(초록) → 주의(노란) → 경고(주황) 순으로 색이 바뀐다. 어느 날 모델이 "에러율 패널이 전날 초록에서 오늘 노란색으로 전환되어 있습니다. 임계값에 근접 중인 것으로 보입니다"라고 알려왔다. 실제 에러율은 1.8%로, 주황 전환 기준인 3%에 아직 여유가 있었다. 하지만 하루 전 대비 추세가 가팔랐고, 팀이 선제적으로 특정 PG사 연동 로그를 들여다봤다. 해당 PG사의 응답 포맷이 조용히 바뀌어 파싱 오류가 누적되고 있었다. 임계값 알림이 울리기 전에 원인을 잡은 케이스다.

실패한 것: 트레이드오프를 숨기지 않는다

숫자 정밀도는 믿지 마라. 모델이 "응답 시간이 약 240ms 수준"이라고 읽은 값이 실제로는 180ms였던 경우가 있었다. Y축 눈금을 이미지에서 읽는 작업은 모델에게 생각보다 까다롭다. 특히 Grafana처럼 축 범위가 자동으로 스케일되는 패널에서 오차가 커진다. 결론은 명확하다. "P95 응답이 450ms를 넘으면 알림"처럼 정확한 수치 판단이 필요한 경우는 무조건 규칙 기반으로 처리해야 한다. 모델은 "올라가고 있다", "이전보다 낮아 보인다"는 방향성 판단에서 가치를 발휘한다.

레이아웃 변경이 해석 품질을 급락시킨다. 대시보드 패널 위치를 바꾸거나 새 패널을 추가했을 때, 모델이 엉뚱한 패널을 지목해서 설명하는 경우가 발생했다. 모델은 이미지의 공간 맥락을 매번 새로 해석하기 때문에, 레이아웃 변경 직후 며칠은 응답을 반드시 수동으로 검토해야 한다. 우리는 대시보드 변경 PR에 "ops-morning 채널 수동 검토 3일" 태스크를 자동으로 붙이는 규칙을 추가했다. 할루시네이션 기준선 측정도 필수다. 3개월 운영 후 집계해보니 모델이 실제로 존재하지 않는 패턴을 언급한 경우가 약 7%였다. 이 숫자를 알고 있기 때문에 "모델 보고는 1차 단서, 확인은 사람"이라는 원칙을 팀 내에서 지킬 수 있다. 측정 없이 운영하면 과신하거나 무시하거나 둘 중 하나로 흐른다.

다음 실험: 패널 단위 분석과 정산 특화 컨텍스트 주입

현재 파이프라인의 가장 큰 약점은 대시보드를 통째로 넘긴다는 점이다. 관심 영역이 희석되고, 모델이 덜 중요한 패널에 주의를 뺏긴다. 다음 버전에서 시도할 방향은 세 가지다.

패널 단위 크롭: Playwright로 전체를 찍은 뒤, 패널별 좌표를 기반으로 개별 이미지를 자른다. "결제 성공률 패널", "PG사별 응답 시간 패널" 각각에 특화된 프롬프트를 붙이면 관심 영역이 명확해지고 응답 품질이 올라간다. 직전 수치 컨텍스트 주입: 프롬프트에 "어제 이 시간 P95는 210ms였다"처럼 수치를 텍스트로 함께 넣으면, 모델이 절대값을 이미지에서 읽지 않고 상대 변화에 집중하게 된다. 이미지 정밀도 문제를 우회하는 가장 현실적인 방법이다. 정산 완료 체크리스트화: "다음 항목이 모두 정상으로 보이면 '정산 정상'이라고 답하라"는 형식의 프롬프트로 구조화된 출력을 만든다. 슬랙에 단순 텍스트 대신 ✅/⚠️ 기반 요약을 올려서 팀이 5초 안에 상태를 파악하는 것이 목표다.

지금 당장 써먹을 실행 시사점

실험을 통해 검증한 다섯 가지를 정리한다. 순서대로 적용하면 된다.

1. 프롬프트에 "없으면 없다고 말해달라"를 첫 줄에 넣어라. 이 한 줄이 노이즈를 절반으로 줄인다. 모델은 기본적으로 무언가를 찾으려 하므로, 명시적인 허가를 줘야 "이상 없음"을 반환한다.

2. 도메인 용어를 프롬프트에 그대로 쓴다. "결제 오류율", "PG사 응답 패턴", "정산 배치 완료 여부"처럼 팀이 실제로 쓰는 단어를 그대로 넣으면 응답이 일반 시각 설명에서 도메인 해석으로 전환된다.

3. 숫자 정밀도가 필요한 알림은 반드시 규칙 기반으로 처리한다. 모델은 방향성(올라감/내려감/이상 없음) 판단에 쓰고, 임계값 판단은 메트릭 시스템에 맡기는 분업을 고수한다.

4. 대시보드 레이아웃 변경 후 3일은 수동 검토를 루틴에 넣는다. 이를 자동화하려면 대시보드 변경 이벤트와 내부 태스크 생성을 연동하면 된다.

5. 할루시네이션 비율을 측정하고 팀 내에 수치로 공유한다. 슬랙 메시지에 👍/👎 리액션을 달고 월 단위로 집계하는 것으로 시작할 수 있다. 숫자를 모르면 신뢰 수준을 조정할 수 없다.

multimodal 분석은 기존 모니터링 알림을 대체하는 것이 아니다. 임계값 알림이 잡지 못하는 완만한 추세와 시각적 패턴을 사람 대신 언어로 해석해주는 보조 레이어다. 이 역할을 명확히 정의하고, 숫자 판단은 기존 시스템에 맡기는 분업을 지키는 것—이것이 과신을 막는 가장 실용적인 원칙이다.