LLM 기반 서비스를 설계하다 보면 자연스럽게 모델 선택에 많은 관심이 쏠립니다. 어떤 모델이 더 정확한지, Multi-LLM 구성이 필요한지, 라우팅 전략을 어떻게 가져갈지와 같은 고민들이죠.
하지만 AI 스미싱 탐지 기능을 개발하며 우리가 먼저 마주한 질문은 조금 달랐습니다.
이번 글에서는 프롬프트 설계 철학을 중심으로, AI 스미싱 탐지 기능을 개선한 과정을 공유하고자 합니다.
프롬프트는 요청이 아니라 정책이다
LLM은 주어진 맥락 안에서 확률적으로 가장 그럴듯한 답을 생성합니다. 즉, 질문이 모호하면 답도 모호해질 수밖에 없습니다. 초기에는 스미싱 위험 요소를 상세히 나열하고, JSON 출력 형식까지 강제한 시스템 프롬프트를 사용했습니다.
표면적으로는 충분히 구조화되어 보였습니다. 그러나 내부 오픈 이후 운영 로그를 분석해보니 다음과 같은 현상이 반복되었습니다.
- 단축 URL이 포함된 정상 광고 메시지를 smishing으로 오판
- 행사 안내나 공지 메시지에 대한 과도한 경계 반응
- 판단 기준은 있지만 우선순위가 불명확
그때 깨달았습니다. 문제는 모델의 성능이 아니라, 판정 체계가 명확히 정의되지 않았다는 점이었습니다.
나열이 아니라 구조가 필요했다
초기 프롬프트는 다양한 위험 요소(URL, 긴급성 표현, 개인정보 요구, 사칭 가능성, 행동 유도 문구)를 포함하고 있었지만 모든 요소가 동일한 무게로 전달되고 있었습니다. 모델 입장에서는 단축 URL도, 민감정보 요구도 같은 “위험 요소”였던 것이죠.
우리는 기준을 다시 설계했습니다. 핵심은 Strong 신호와 Weak 신호를 명확히 구분하는 것이었습니다.
- 비밀번호·계좌번호·카드번호·주민번호 등 민감정보 입력·회신·전달 요구
- 앱 설치, APK·실행파일 다운로드, 원격제어 앱 설치 유도
- 결제 취소·환불·미납·계정 정지 등 금융 피해 상황 제시 후 즉시 조치 요구
- 비현실적인 고수익 제시 후 외부 채널(VIP방, 카카오톡 ID 등)로 유도
- 단축 URL 포함 (bit.ly, tinyurl 등)
- 광고·쿠폰·혜택·이벤트·기한 강조
- Web발신, 수신거부 번호 제공
그리고 명확한 판정 규칙을 정의했습니다. Strong 신호가 1개 이상이면 smishing, 0개이면 반드시 normal, 애매한 경우에는 normal. 프롬프트를 설명 문장이 아니라 판정 정책으로 재정의한 순간이었습니다.
Few-shot은 “설명”이 아니라 “맥락 제공”이다
개선 버전에서는 정상 메시지 예시를 충분히 포함했습니다. 광고, 쿠폰, 행사 안내, 승인 알림 등 실제 서비스 환경에서 자주 등장하는 정상 패턴을 명시적으로 제시한 것이죠.
감이 아니라 실험으로 확인하다
프롬프트 개선이 체감상 좋아 보였지만, 정량 검증이 필요했습니다. LangSmith Experiment를 활용해 동일 데이터셋(99건)에 대해 동일 모델(Upstage Solar Pro 2)로 프롬프트 버전만 바꾸어 비교 실험을 진행했습니다.
| Version | Accuracy | P50 Latency |
|---|---|---|
| 프롬프트 개선 전 | 0.63 | 0.92s |
| 프롬프트 개선 후 | 0.95 | 0.57s |
Strong/Weak 구조 도입 이후 정확도는 0.95를 기록했습니다. 맥락이 명확해지니 Latency도 0.92s에서 0.57s로 감소했습니다. 모델은 동일했습니다. 변경된 것은 프롬프트 구조뿐이었습니다.
모델 이전에 정의가 먼저다
최근에는 Multi-LLM 구성이나 모델 라우팅 전략이 자주 언급됩니다. 물론 복잡한 문제에서는 필요한 접근입니다. 그러나 텍스트 분류와 같이 판정 기준이 명확한 문제에서는 프롬프트 설계가 성능에 미치는 영향이 훨씬 큽니다. 모델을 늘리는 것은 아키텍처의 확장이지만, 응답 품질은 문제 정의의 명확성에서 시작됩니다.
- 1) 프롬프트는 요청이 아니라 정책이다.
- 2) 위험 요소는 나열이 아니라 구조화되어야 한다.
- 3) Strong 신호와 Weak 신호를 구분해야 한다.
- 4) 애매한 경우의 기본값(default)을 명확히 정의해야 한다.
- 5) 프롬프트는 실험과 검증의 대상이다.
LLM 응답이 기대와 다르다면, 모델을 교체하기 전에 먼저 질문을 점검해볼 필요가 있습니다. 복잡한 구조를 설계하기 전에, 우리가 정의한 한 줄의 문장을 먼저 돌아보는 것. 이번 AI 스미싱 프로젝트는 그 단순한 철학을 다시 확인하는 과정이었습니다.
