마케팅 메시지는 고객군 분석, 문구 작성, 채널 선택, 발송, 결과 확인이 각각 분리되어 있어 반복 작업이 많고 담당자의 경험에 따라 품질 편차가 발생합니다.
Smart Messaging System은 이 과정을 하나의 흐름으로 연결한 사내 마케팅 도구입니다. 고객의 채널 수신 동의와 채널별 비용을 바탕으로 발송 경로를 구성하고, AI가 브랜드 톤에 맞는 문구 작성과 검수를 보조합니다. 발송 이후에는 채널·비용·고객·성과별 통계를 대시보드에서 확인할 수 있습니다.
| 구분 | 내용 |
|---|---|
| 개발 기간 | 2026.07.01 - 2026.07.10 |
| 참여 인원 | 4명 |
| 개발 형태 | Spring Boot 기반 서버 사이드 렌더링 웹 서비스 |
| 담당 영역 | AI 문구 추천·검사, RAG, 전송 이력, 템플릿 관리 |
| 기능 | 설명 |
|---|---|
| 수신자 선택 | 고객 조건 검색과 선택 목록 임시 저장, 대량 수신자 관리 |
| 메시지 발송 | RabbitMQ를 이용한 비동기 대량 발송과 채널별 대체 발송 |
| AI 문구 추천·검사 | 입력 조건과 브랜드 톤을 반영한 문구 추천, 규칙·외부 필터·LLM 기반 단계별 검수 |
| 템플릿 관리 | 채널별 메시지 템플릿 등록·조회와 관리자 수정·삭제 |
| 전송 이력 | 발송 내역 검색·필터·정렬, 결과와 대체 발송 흐름 상세 조회 |
| 통계·대시보드 | Spring Batch 사전 집계를 이용한 발송·채널·비용·고객·성과 분석 |
flowchart LR
U["마케터"] --> WEB["Thymeleaf UI"]
WEB --> APP["Spring Boot"]
subgraph APP_LAYER["Application"]
APP --> API["Controller / Service"]
API --> AI["AI 추천·검사"]
API --> SEND["발송·대체 발송"]
API --> BATCH["통계 Batch"]
end
API --> ORACLE[("Oracle DB")]
API --> REDIS[("Redis Draft")]
SEND --> MQ["RabbitMQ"]
MQ --> CHANNEL["Kakao / SMS·LMS / AWS SES"]
BATCH --> ORACLE
AI --> QDRANT[("Qdrant")]
AI --> GEMINI["Gemini"]
AI --> MODERATION["OpenAI Moderation"]
AI --> FILTER["한국어 비속어 필터 API"]
| 분류 | 기술 |
|---|---|
| Backend | Java 17, Spring Boot 3.5.16, Spring Security, Spring Batch, Spring AOP |
| AI | Spring AI 1.1.8, Gemini, OpenAI Moderation API, Qdrant |
| Data | Oracle, MyBatis, Redis |
| Messaging | RabbitMQ, Kakao API, SOLAPI, AWS SES |
| Frontend | Thymeleaf, JavaScript, HTML, CSS |
| Test·Docs | JUnit 5, Mockito, MockMvc, Swagger |
| 영역 | 담당 내용 |
|---|---|
| AI 문구 추천·검사 | 서버 규칙, 비속어 필터, OpenAI Moderation, RAG, Gemini를 결합한 단계별 검수 흐름 구현 |
| AI 성능 개선 | 독립적인 외부 호출 병렬화, 전용 Executor 분리, RAG 프롬프트와 추천 재시도 비용 축소 |
| RAG | 마케팅 문구 적재·검색 API, Qdrant 연동, 추천·검사 프롬프트 컨텍스트 구성 |
| 전송 이력 | 검색·다중 필터·정렬·페이징 목록과 상세 모달, 대체 발송 흐름 집계 구현 |
| 템플릿 관리 | 관리자 전용 수정·삭제 API와 화면, Spring Security 권한 검증, soft delete 적용 |
| 품질 검증 | Service·Controller·MyBatis XML·Thymeleaf 단위 테스트와 AI 응답시간 벤치마크 수행 |
마케팅 문구는 혜택·조건·채널에 맞춰 반복해서 작성해야 하고, 발송 전에는 변수 형식, 개인정보, 유해 표현, 브랜드 톤까지 확인해야 합니다.
이에 AI가 마케터의 판단을 대신하기보다 문구 후보 생성, 아이디어 확장, 발송 전 위험 요소 점검과 문맥 검토를 보조하도록 설계했습니다.
LLM 하나에 모든 판단을 맡기지 않고 검사의 성격에 따라 책임을 분리했습니다.
- 확정적인 규칙과 확률적인 판단 분리
서버 규칙은 모델 응답으로 제거하거나 완화할 수 없도록 유지했습니다.- 외부 필터의 탐지 결과만
LLM이 문맥상 오탐 가능성을 재검토하도록 했습니다.
- 생성 결과 재검증
Gemini가 생성한 문구를 그대로 반환하지 않고 서버 규칙을 통과한 후보만 제공했습니다.
- RAG의 역할 제한
RAG는 최종 판단 기준이 아닌 브랜드 톤 참고자료로만 사용했습니다.- 검색된 상품명·혜택·기간·조건이 새로 추가되지 않도록 제한했습니다.
- 비속어 필터,
Moderation,RAG검색을 차례로 호출해 외부 시스템의 대기 시간이 전체 응답시간에 누적됐습니다. - 추천 결과가 서버 규칙을 통과하지 못하면
Gemini재호출이 반복되어 호출 횟수에 따라 응답시간 편차가 커졌습니다.
-
검사 파이프라인의 Critical Path 단축
- 비속어 필터,
Moderation,RAG검색 사이에 결과 의존성이 없다는 점을 확인했습니다. - 세 작업을
CompletableFuture로 동시에 실행해 대기시간이 합산되던 구조를 가장 오래 걸린 작업을 기다리는 구조로 변경했습니다.
- 비속어 필터,
-
AI 외부 I/O 실행 자원 분리
- 외부 API와 Vector DB 호출이 공용 스레드 풀을 점유하지 않도록 전용
aiTaskExecutor를 구성했습니다. - 풀 크기와 대기 큐를 제한해 AI 요청 증가가 다른 비동기 작업의 실행 자원까지 잠식하지 않도록 했습니다.
- 외부 API와 Vector DB 호출이 공용 스레드 풀을 점유하지 않도록 전용
-
동일 요청 내 중복 RAG 검색 제거
- 병렬 단계에서 생성한
RagPromptContext를Gemini검사 단계에 직접 전달했습니다. - LLM 검사 과정에서 같은 RAG 검색이 다시 실행되지 않도록 해 불필요한 외부 호출을 제거했습니다.
- 병렬 단계에서 생성한
-
추천 재시도로 발생하는 추가 지연 제한
- 생성 후보가 서버 규칙을 통과하지 못할 때마다
Gemini를 다시 호출해 응답시간 편차가 커질 수 있었습니다. - 첫 응답에서 규칙을 통과한 후보가 있으면 즉시 반환하고, 최대 재시도 횟수를 설정값으로 분리해 기본값을 2회로 제한했습니다.
- 외부 LLM의 1회 호출 시간 자체를 줄인 것은 아니지만, 하나의 요청에서 반복될 수 있는 추가 호출 횟수에 상한을 두었습니다.
- 생성 후보가 서버 규칙을 통과하지 못할 때마다
-
단계별 병목 측정
- AOP 로깅으로 서버 처리, 외부 API, 외부 AI의 소요시간을 구분해 개선 전후의 병목 변화를 확인했습니다.
동일한 payload를 개선 전후 각각 100회 호출하고 첫 요청을 warm-up으로 제외해 비교했습니다.
| 구분 | 평균 응답시간 | p50 응답시간 |
|---|---|---|
| 검사 A | 3,479.6ms → 3,033.2ms 12.8% 감소 |
2,520.3ms → 1,681.2ms 33.3% 감소 |
| 검사 B | 3,843.6ms → 3,321.1ms 13.6% 감소 |
2,532.3ms → 2,157.0ms 14.8% 감소 |
외부 LLM의 응답 편차 자체를 제거하기보다 서버에서 통제 가능한 직렬 대기, 중복 검색, 실행 자원과 재시도 비용을 줄이는 데 초점을 맞췄습니다.
- PR #30 - AI 메시지·템플릿 검사 1차 서버 룰 API 구현
- PR #34 - 한국어 비속어 필터 API 연동
- PR #40 - OpenAI Moderation API 연동
- PR #42 - Spring AI 문구 추천 및 검사 기능 구현
- PR #56 - AI 추천·검사 RAG 연동
- PR #80 - AI 추천 및 검사 성능 개선
- 공개된 Hmall 캠페인·이벤트 문구와 현대홈쇼핑 공식 SNS 게시글을 활용해
LLM에 브랜드 톤과 문장 구조를 참고할 맥락을 제공했습니다. RAG가 정책을 직접 판단하거나 사용자 입력에 없는 정보를 생성하지 않도록 추천·검사를 보조하는 참고 계층으로 역할을 제한했습니다.
- Hmall의 공개 캠페인·이벤트 문구와 현대홈쇼핑 공식 SNS 게시글 등 공개 마케팅 자료를
embedding해Qdrant에 적재했습니다. - 원본
doc_id를deterministic UUID로 변환해 재색인할 때도 같은 문서를 식별하도록 구성했습니다. - 필요한 내용과
metadata만 프롬프트에 전달하고 내부 상태·URL·검색 점수는 제외했습니다. - 참고 문구의 상품명·기간·혜택을 복사하거나 새로 생성하지 못하도록 프롬프트 규칙을 적용했습니다.
- 검색에
timeout을 적용하고 실패하면 RAG 없이 추천·검사를 이어가는 fallback을 적용했습니다.
- 제목·본문·태그 검색과 여러 필터, 정렬 조건을 함께 처리할 조회 구조가 필요했습니다.
- 각 전송 기록의 채널과 태그를 개별 조회하면 목록 크기에 따라 쿼리가 증가하는 문제가 있었습니다.
- 실제 발송 시도만 기준으로 집계하면 같은 차수에 여러 채널이 표시되거나 건수가 중복될 수 있었습니다.
- 검색, 채널·상태·광고 여부·다중 태그·기간 필터, 정렬, 서버 페이징을 하나의 조회 흐름으로 구성했습니다.
- 현재 페이지의 전송 기록 ID로 채널과 태그를 배치 조회해 N+1 조회를 방지했습니다.
%,_,!가 포함된 검색어를escape하고 정렬값과 페이지 범위를 서버에서 정규화했습니다.- 대체 발송 흐름을 실제 시도 순서가 아닌 설정된
priority_order기준으로 표시했습니다. - 발송 시도를 채널별로 먼저 집계한 뒤 라우팅 정보와 결합해 중복 집계를 제거하고 미시도 채널은 0건으로 표시했습니다.
- 상세 모달의 키보드 접근과
focus trap,JSON오류 응답까지 함께 처리했습니다.
| 영역 | 작업 내용 | 관련 PR |
|---|---|---|
| AI 서버 규칙 검사 | 템플릿 변수 형식·지원 여부와 개인정보 패턴 검사, 심각도 기반 결과 결정 및 오탐 방지 | PR #30 - AI 메시지·템플릿 검사 1차 서버 룰 API 구현 |
| 한국어 비속어 검사 | 한국어 비속어 필터 API를 연동하고 탐지 결과 변환 및 예외 처리 적용 | PR #34 - 한국어 비속어 필터 API 연동 |
| 콘텐츠 안전성 검사 | OpenAI Moderation API를 연동해 유해 표현을 분류하고 API 장애 시 fallback 처리 |
PR #40 - OpenAI Moderation API 연동 |
| AI 문구 추천·검사 | Spring AI와 Gemini를 이용한 조건 기반 문구 생성 및 문맥 검사 구현 |
PR #42 - Spring AI 문구 추천 및 검사 기능 구현 |
| AI 클라이언트 안정화 | Spring AI 설정 초기화 순서를 조정해 Gemini 클라이언트 생성 오류 해결 |
PR #46 - Gemini 클라이언트 설정 초기화 오류 수정 |
| AI DTO 구조 개선 | AI 요청·응답 DTO를 record로 전환하고 광고 필수 문구의 검증 책임 조정 |
PR #47 - DTO record 전환 및 광고 필수 문구 검증 제거 |