금요일 오후 매출 하락을 토요일에 알았다 — 금융 플랫폼 PM이 AI로 30분 모니터링을 만든 과정

금요일 오후에 매출이 빠지기 시작했어요. 토요일 오전에 데이터 배치가 돌아서야 인식했고, 토요일 오후가 되어서야 해결. 문제 발견부터 해결까지 하루 이상. 그 시간만큼 매출 손실이 고스란히 쌓였어요.

다수의 금융 파트너와 연결된 복잡한 퍼널에서는 작은 배포 오류나 외부 파트너사 이슈가 곧바로 그날의 매출 하락으로 이어질 수 있거든요. AFINIT의 FPJR(Financial Platform Journey Revamp) 프로젝트 런칭 직후, 퍼널 모니터링 시스템은 하루 단위로 작동하고 있었어요.

이 간극을 줄이기 위해 명확한 목표를 세웠다고 해요. "문제 발생 후 30분 이내 인지, 2시간 이내 해결."

병원을 갔을 때처럼 — X-ray로 빠르게, MRI로 정밀하게

목표를 달성하기 위해 도입한 게 'X-ray와 MRI 전략'이에요. (진짜 직관적인 비유더라고요.)

X-ray는 실시간 알림이에요. "지금 시스템 뼈대에 금이 갔나?"를 30분마다 빠르게 찍어 봐요. 사내에 구축된 SQL output을 Slack에 스케줄에 따라 전달해주는 Data Delivery Man이 데이터를 배달하면, AI로 만든 Agent가 1차 식별하여 이상 징후를 즉시 Slack 멘션으로 알려요.

MRI는 정밀 대시보드예요. AI Agent가 멘션을 보내면 "정확히 어디가, 왜 아픈가?"를 파악하기 위해 데이터를 깊게 쪼개요. Kibana 대시보드 그래프와 Tableau 대시보드에 시각화한 각 세부 퍼널의 메트릭을 통해 원인을 정밀 분석하는 거예요.

문제 발견(Discovery)과 원인 파악(Validate) 시간을 획기적으로 앞당길 수 있었다고 해요.

전략은 명확했지만 구현은 다른 문제. FPJR로 방대해진 데이터 스키마와 복잡한 로직을 모니터링하기 위해 수십 개의 SQL 쿼리와 Kibana 시각화 코드를 직접 짜는 건 막대한 리소스가 드는 일이었거든요.

AI를 "숙련된 동료"로 만드는 프롬프트 엔지니어링 3요소

이 생산성의 한계를 AI 도구(Cursor, Gemini, 사내 슬랙 Sidekick Agent — 별명이 '꼬부기'래요)로 돌파했어요. 그 과정에서 프롬프트 엔지니어링의 핵심 3요소를 정립했다고 해요. Claude 공식문서의 'Prompting best practices'에서 중요하다고 생각한 요소를 정리해서 적용한 내역이에요.

첫째, 구체적인 지시(Specific Instruction). AI에게 모호함은 적이에요. 보고 싶은 메트릭을 정의하고 원하는 결과물을 하나하나 알려줬대요. "SQL Query를 changeDB(CDC)를 활용해서 만들고 싶어. 내가 보고 싶은 메트릭은 Applied, SMS CL Approved 등이야." 이런 식으로. SQL query 작성이든, 슬랙 봇을 Monitoring Agent로 변환시키는 바이브 코딩이든 구체적인 지시가 필수였다는 거예요.

둘째, 결과물 예시 제공(Example Output). AI가 뱉어낼 결과물의 형식을 미리 지정해 주면 수정 시간을 획기적으로 줄일 수 있다고. "최종 결과물 예시는 @SlackMonitorService.java에서 뽑으려고 하는 시간별 메트릭 포맷이야." 이렇게 포맷을 명확하게 잡아주는 거예요. Timelion expression 예시를 먼저 보여주고 "이와 같은 문법 구조로 쿼리를 짜줘"라고 한 것도 같은 맥락이에요.

셋째, 충분한 배경정보(Context). 솔직히 이게 가장 중요하더라고요. FPJR 프로젝트로 테이블 구조가 어떻게 바뀌었는지, 특정 용어가 회사에서 어떤 의미로 쓰이는지 AI에게 사전에 학습시켰어요. 테이블 스키마를 txt 파일로 만들고, 맥락을 .md 파일로 정리해뒀대요. "이 메시지에서 total은 모든 숫자고, new_user는 CL Closed 이력이 없는 유저야. 이 맥락을 기억하고 이상 징후를 판단해." 이런 수준의 컨텍스트를 심어준 거예요.

핵심은 이 세 가지를 통해 실제로 작동하는 SQL query, Kibana query, 슬랙 모니터링 봇을 순식간에 만들었다는 점이에요. 해야 할 일은 오직 로직 검증과 결과 검증뿐이었다고.

Cursor로 SQL '딸깍', 꼬부기로 알림, Gemini로 Kibana — 각 도구를 적재적소에

세 가지 구체적인 구현 사례가 있어요.

Case 1: Cursor AI로 SQL 쿼리 완성. 복잡한 금융 퍼널 데이터 추출용 SQL 작성 시간을 Cursor AI로 획기적으로 단축했어요. 스키마 정보(Context)와 추출 목표(Instruction)만 입력하면 실행 가능한 쿼리가 즉시 생성돼서 Data Delivery Man이 바로 사용할 수 있었대요.

Case 2: Sidekick, 별명 꼬부기와 함께하는 모니터링. 슬랙 채널(#tc_fpjr_monitor)에 Sidekick Monitoring Agent가 상주하고 있어요. 30분마다 올라오는 데이터를 읽고, 사전 학습된 비즈니스 컨텍스트를 바탕으로 "신규 유저 세그먼트에서 이상 징후가 보인다"고 판단하면 즉시 담당자를 태그해서 알려요. 24시간 모니터링 화면을 쳐다보고 있을 필요가 없어진 거예요.

Case 3: Gemini로 Kibana 쿼리 정복. Kibana 쿼리(TimeLion 등)는 배우기 까다롭기로 유명하잖아요. "실시간 Loan Application Count를 과거 데이터와 비교하면서 지금이 정상인지 확인할 수 있는 쿼리를 짜줘"라고 Gemini에게 요청했더니 정확한 쿼리가 나왔고, 고도화된 MRI 대시보드를 손쉽게 구축할 수 있었다고.

여기서 얻은 진짜 수확은 모니터링 시스템 자체가 아니라 일하는 방식의 변화예요. 데이터 추출, 단순 모니터링, 지표 트래킹 같은 반복 업무에 하루의 절반을 쓰는 경우가 많았는데 — 안정적 성장을 위해 중요한 일이지만 반복적이었거든요 — 이제 AI로 반복 업무 비중을 획기적으로 낮추면서 안정성도 동시에 갖출 수 있게 됐다는 거예요.

SQL 작성뿐 아니라 Dynamic Rule 배포, Jira 요구사항 분석 등 다양한 영역에서 Self-served AI 워크플로우를 현업에 적용하고 있대요. PM이 직접 만드는 AI 워크플로우. AI가 실행을 담당해주니까, 기획과 기획에 대한 정확한 검증이 더 중요해지는 시대라는 건 맞는 말이에요. 근데 그래서 더 무서운 거 아닌가요. 검증할 줄 모르면 AI가 만들어낸 결과물을 그냥 믿게 되니까. 결국 도구가 아무리 좋아도, 그 도구 위에서 판단하는 건 사람이에요.