UX를 고려한 LLM 앱 문의 응답 가이드

시작하며

voltup 어플리케이션으로 들어오는 고객 문의에 상담원이 어떻게 답해야 할지 가이드해 주는 AI 추천 시스템을 구축했습니다. 문의가 등록되면 상담원이 확인해야 하는 데이터와 최선의 답변 방향을 미리 정리해서 제시해 주는 것이 핵심 목표입니다.

고객 문의를 분석해 보면 상당한 비중이 FAQ 수준에서 즉시 답변 가능한 내용입니다. 하지만 다른 한편으로는 서비스의 최신 정책과 고객의 과거 이용 내역까지 복합적으로 확인해야만 답할 수 있는 고난도 문의도 존재합니다.

문의마다 필요한 작업의 결이 다르다 보니, 기존에는 상담원의 숙련도에 따라 답변 품질에 편차가 생기거나 단순 데이터 조회에 불필요하게 많은 시간이 소요되곤 했습니다.

바로 이 지점에서 LLM 기반 상담 가이드의 필요성이 드러납니다. 반복적인 답변은 표준화하고, 복잡한 판단이 필요한 문의에는 핵심 맥락을 미리 요약해 줌으로써 상담원 전체의 생산성과 답변 정확도를 동시에 끌어올릴 수 있기 때문입니다.

그래서 커버리지를 넓혀가는 단계적 로드맵을 다음과 같이 설정했습니다.

1단계. FAQ 중심의 기본 커버리지 확보: 단순 반복 문의를 빠르게 처리하여 상담원 1인당 처리 시간을 즉시 단축합니다.
2단계. 상담 유형별 데이터 및 대응 가이드 제공: 경험에 의존하던 판단 기준을 가이드화하여, 신입과 숙련자 간 답변 품질 편차를 줄이고 일관성을 확보합니다.
3단계. AI의 데이터 직접 조회 및 프로세스 단축: 여러 시스템(결제, 충전 로그, 이력 등)을 오가는 번거로움을 없앱니다. 상담원의 역할을 ‘일일이 조회하고 판단하는 사람’에서 ‘AI가 정리해 준 근거를 검토하고 승인하는 사람’으로 진화시킵니다.

이번 글에서는 이 중 2단계까지, 즉 FAQ 응답과 상담 가이드 자동 생성 시스템을 구축했던 과정과 생성된 가이드를 상담원에게 잘 전달하고 쉽게 적용하게 하려면 어떻게 해야할지 고민한 흐름을 공유합니다.

1단계: 파인튜닝 대신 컨텍스트 주입 (RAG)

가장 먼저 떠오른 방법은 모델 파인튜닝(Fine-tuning)이었지만, 실시간 정책 변경 대응이나 비용 측면에서 현실적으로 불가능에 가까웠습니다. 결국 LLM에 관련 컨텍스트(Context)를 주입하는 RAG(Retrieval-Augmented Generation) 방식을 취해야 했습니다.

어떤 컨텍스트를 넣어줘야 할지 고민해 보니 답은 단순했습니다. 고객 문의에 답하는 데 필요하다고 판단되는 질답 데이터를 함께 제공하고, 이를 기반으로 답변하도록 유도하는 것이었습니다.

우선 입력 데이터의 최소 포맷(JSON)부터 정의했습니다.

필수 필드: 문서 식별자(id), 질문/답변(q/a)
메타 데이터: 데이터 출처(source), 데이터 품질 평가 점수(score)

처음 구상한 구조는 간단했습니다. 이 데이터를 Vector DB에 저장해 두고, 고객 문의가 들어오면 임베딩 유사도 검색으로 상위 N개의 관련 문서를 뽑아 LLM에 전달하는 표준적인 RAG 방식이었습니다.

문제 발생: 인프라와 비용 부담

하지만 막상 구현하려 보니 Vector DB 도입에는 큰 걸림돌이 있었습니다.

Vector DB : 인프라 관리 포인트의 증가
팀 내에 기존에 운용 중인 Vector DB가 없었기에, 인프라를 완전히 새로 구축해야 하는 부담이 컸습니다.
임베딩 모델 : 인프라 관리 포인트 증가와 유료 API의 부담
오픈 소스 임베딩 모델을 구축해서 사용하는 것도 위와 동일하게 인프라를 새로 구축해야하는 부담이 있었습니다. 또한 그렇게 하지 않으려면 외부 유료 API를 사용해야 하는데 보안/외부 종속성/비용 전부 떠안고 갈 수는 없었습니다.

결론 : 초기 단계에서 인프라 관리 포인트를 이렇게까지 늘리고 싶지 않았고, 그렇다고 답변 품질을 포기할 수도 없는 상황이었습니다.

방향 전환: Vector DB 없는 ‘LLM 기반 검색’

고민 끝에 팀 내 DE(Data Engineer) 파트 James에게 조언을 구했습니다. James는 매력적인 대안을 제안해 주었습니다.

“참조하고 생성하는 데이터 양이 아주 많지 않고, 가이드 자체가 어느 정도 정형화된 패턴을 갖고 있다면 굳이 구축 공수가 큰 Vector DB를 둘 필요가 없습니다. 텍스트 위주의 적은 데이터는 .md 파일 단위로 관리하며 LLM이 참조하게 해도 충분합니다. 요즘 Vector DB는 PDF나 이미지 같은 비텍스트 다차원 데이터가 많거나, 데이터의 양이 매우 방대하여 LLM의 Context Window로 감당하기 어려울 때 주로 사용합니다.”

이 조언을 바탕으로 방향을 틀었습니다. RAG라는 큰 틀은 유지하되, LLM이 참조할 문서를 선출하는 단계를 ’LLM 자신의 판단’으로 대체(LLM-as-a-Retriever)하기로 했습니다.

참조 문서 선출: 왜 전통적 검색 대신 LLM을 택했는가?

키워드 매칭 기반의 Full-text 검색이나 N-gram 토크나이징 기반의 전통적인 키워드 검색 방식도 매력적인 대안이었습니다. 구현이 간단하고 처리 속도가 빠르기 때문입니다. 하지만 몇 가지 치명적인 한계점이 눈에 띄었습니다.

사용자 입력의 불완전성 실제 사용자의 질문에는 오타, 띄어쓰기 오류, 혹은 비표준어가 빈번하게 포함됩니다. 키워드 기반 검색은 정확한 단어 일치에 의존하기 때문에, 약간의 오타만 발생해도 관련 문서를 아예 찾아내지 못하는 조용히 실패(Silent Fail)할 가능성이 있습니다.
의도와 문맥 이해의 한계 사용자는 문서에 명시된 정확한 용어를 모른 채 "이거 어떻게 설정해?"와 같이 모호한 자연어로 질문하곤 합니다. 전통적 검색 알고리즘은 단어의 표상을 기반으로 하지만, LLM은 질문의 숨은 의도와 문맥을 이해할 수 있습니다.

따라서 LLM 자체의 추론 능력을 활용하여 참조 문서를 선출하는 'LLM-as-a-Retriever' 방식을 채택했습니다. LLM에게 전체 문서 목록과 각각의 요약을 먼저 제공하고, "사용자의 의도를 고려할 때 가장 적절한 문서가 무엇인지" 스스로 판단하게 한 것입니다.

그 결과, 오탈자가 포함된 질문이나 다소 모호한 자연어 입력에도 정확한 가이드 문서를 찾아내 연결해주는 뛰어난 유연성을 확보할 수 있었습니다.

문서 관리: Markdown(.md) 파일 단위로 단순하게 관리
검색 방식:
1. 전체 문서의 요약(Summary) 목록을 LLM에 전달
2. LLM이 고객 문의와 가장 관련이 깊은 문서 N개를 스스로 선택
3. 선택된 문서의 전체 본문(Full text)만 추출하여 최종 답변 생성 프롬프트에 주입

Vector DB와 임베딩 모델을 완전히 걷어내고, LLM이 직접 검색기 역할까지 수행하도록 만든 것입니다. 전체 문서 세트를 대상으로 이 방식을 테스트해 본 결과, Vector 유사도 검색 없이도 LLM이 맥락에 맞는 문서를 훌륭하게 골라내어 자연스러운 답변을 만들어냈습니다.

2단계: 참조 데이터(카탈로그) 구축

LLM이 참조할 카탈로그 문서의 형상을 간소화 하면 다음과 같습니다.

data class Catalog(
    val source: Source, // 참고 문서의 원본
    val category: Category?, // 문의 카테고리
    val summaryQa: String?, // 질 + 답을 요약한 것
    val q: String, // 질문 원문. 다만 전화 상담의 경우 LLM 요약
    val a: String, // 답변 원문. 다만 전화 상담의 경우 LLM 요약
    val score: Double, // 문서의 품질 점수
    val clusterSize: Long // 비슷한 문서가 병합된 수
)

참조 데이터는 3가지 소스를 활용했으며, 각 재료마다 카탈로그화 과정이 조금씩 달랐습니다.

답변 완료된 앱 문의
1. 이미 Q&A 구조였기에 요약(summaryQa)은 LLM에 맡기고, 카테고리도 기존 입력값을 그대로 활용했습니다. 단, 한 문의 안에 여러 질문이 섞여 있는 경우는 단일 문의 단위로 분리 정규화했습니다.
고객 전화 문의 STT 결과물
1. 가장 가공하기 어려운 재료였습니다. 대화 특성상 질문과 답변이 오가며 뒤섞이고 의미 없는 발화가 많았으며, 한 통화 안에서 여러 주제가 오가는 경우도 존재했습니다. 따라서 전사문(STT) 전체를 LLM이 파악해 구조화된 Q&A로 정리하도록 한 뒤, 그 결과를 다시 한번 요약하게 했습니다.
기존 상담원 운영 가이드
1. 이미 문의 예시와 답변 형태로 정돈되어 있어, 가공 공수가 가장 적게 들었던 재료입니다.
2. 만약 1단계 "FAQ 중심의 기본 커버리지 확보" 까지가 구현 목표라면 운영 가이드만 카탈로그화 하면 됩니다.

각 소스는 다음 파이프라인을 거쳐 정식 카탈로그로 변환됩니다.

단계	수행 작업
전처리	앱 문의 / 전화 STT 원본을 결정론적 규칙 기반으로 정제 (LLM 미사용)
LLM 정규화	공통 문서 스키마로 Q&A 정규화 및 문의 카테고리 매핑 (상담 가이드는 이 단계부터 합류)
클러스터링	비슷한 문서 병합 및 중복 제거
카탈로그 생성	1개 문서 = 1개 Markdown(.md) 파일로 출력

중복 문서의 클러스터링 처리 전략

수많은 문의 내역에는 동일하거나 유사한 내용이 반복해서 등장합니다. “회원 카드 어떻게 발급 받나요?” 같은 질문을 그대로 중복해서 방치하면 인덱스 토큰만 쓸데없이 낭비됩니다. 따라서 정규화가 끝난 문서들을 다음과 같이 클러스터링했습니다.

카테고리 블로킹 내 병합 전체 문서를 한 번에 비교하는 대신 소분류 카테고리 기준으로 모아둔 뒤, 그 안에서 LLM이 유사 문서를 병합하도록 했습니다. 토큰 비용을 최소화하기 위함입니다.

중복을 지우되 관련 정보를 버리지는 않았습니다. 몇 개의 문서가 하나로 합쳐졌는지를 clusterSize로 남겨두어, “자주 들어오는 주요 문의”라는 빈도 신호(Signal)로 활용했습니다. 반복을 노이즈가 아닌 유용한 통계 데이터로 재해석한 것입니다.

이 파이프라인을 거쳐 총 600여 개의 정제된 카탈로그 문서가 최종 생성되었습니다.

3단계: 상담 가이드 생성 파이프라인

가이드 생성 단계에서 가장 크게 신경 쓴 두 가지 원칙은 다음과 같습니다.

환각(Hallucination) 방지: AI가 판단할 수 없는 것은 “판단 불가”라고 명시하고, 제시되는 가이드의 정확도를 최우선으로 보장한다.
출처 투명성: 가이드 생성에 어떤 카탈로그 문서가 참조되었는지 상담원에게 명확한 소스를 표기한다.

전체 로직은 고객 문의 생성 이벤트를 비동기 수신하며 트리거됩니다. 상담원이 문의 상세 화면을 열었을 때는 이미 가이드가 준비되어 있도록 연동했습니다.

시스템 서비스화 단계에서 카탈로그 저장 및 조회 방식도 개선했습니다. 파인프라인 생성물인 .md 파일을 그대로 서빙하는 대신, 실제 서비스 백엔드에서는 RDB 테이블로 이관 후 메모리 캐싱(In-Memory Caching) 방식을 적용해 요청마다 I/O가 발생하는 것을 방지하여 빠른 응답 속도를 확보했습니다.

마지막으로 문의 답변의 서두와 말미는 거의 대부분 동일한 패턴이 반복되는것을 확인했습니다.

이 내용은 딱히 LLM 으로 생성할 필요가 없기 때문에 정적으로 생성되도록 했습니다.

그 사이에 들어갈 중간 내용만 LLM이 생성합니다.

인사 :

안녕하세요, 고객님.
LG U+ VoltUp 입니다.

클로징 멘트 :

추가로 궁금하신 점이 있으실 경우,
앱 내 1:1 문의하기 또는 고객센터(☎ 1660-0365)로 언제든지 연락 부탁드립니다.

감사합니다.
LG U+ VoltUp 드림.

4단계: 이용자를 고려한 산출물 설계

아무리 100% 정확한 가이드를 해 줄수 있다 하더라도, 실제로 이를 사용하는 상담원이 거부감 없이 직관적으로 쓸 수 없다면 의미가 없습니다. 결국 ‘어떤 형상으로 전달되어야 상담원의 업무 흐름을 방해하지 않고 매끄럽게 도움을 줄지’ 고민했습니다.

그동안 백엔드 개발자로 일해오면서는 사용자 질문(Q)에 대해 정확한 데이터(A)가 담긴 JSON 응답만 반환하면 백엔드의 역할은 완수되었다고 생각하는 경우가 많았습니다.

하지만 같은 개발팀인 tim에게 영감을 받아 최근에서야 간간이 적용해보고 있는 업무 습관이 있습니다.

가능하다면 시각적인 산출물을 확인 해보는 것
시각적인 산출물을 통해 UX 를 고려하고 그에 맞게 다시 산출물의 형태를 조정하는것

맨 처음 산출물의 형태는 아래와 같았습니다.

data class AgentGuide(
    val customerInquiryId: Long, // 원 문의 식별자
    val guide: String?, // 가이드 최종
    val sources: List<Source>, // 근거 문서
)

그리고 guide 의 실제 내용은 아래와 같이 모든 경우가 한 문자열로 합쳐져 나열되어 있었습니다.

[초기 guide 예시]

안녕하세요, 고객님. //<------- 인사
LG U+ VoltUp 입니다.

서비스 이용에 불편을 드려 죄송합니다. //<------- 고객이 불편한 상황을 겪은 경우에만 추가되는 멘트

[미납 요금이 확인되는 경우] //<------- 분기 1
고객님 계정에 미납 요금(미수금)이 발생하여 충전기 이용 및 결제가 제한된 것으로 확인됩니다.
미납 요금은 볼트업 앱에 등록된 결제카드로 정산해 주셔야 합니다.

[결제카드 등록 방법]
1. 볼트업 앱 로그인 후 [더보기] > [결제수단 관리]로 이동합니다.
2. 우측 상단 [추가하기]를 누릅니다.
3. 하단 팝업에서 [카카오페이 등록] 또는 [신용 / 체크카드 등록]을 선택합니다.
4. 약관 동의 및 카드 명의자 인증을 진행하여 등록을 완료하고 '주카드'로 설정합니다.

[미납 요금 결제 방법]
- 자동 결제: 정상적인 카드를 새로 등록하고 '주카드'로 설정하면 미납 금액에 대한 재결제가 자동으로 진행됩니다.
- 직접 결제: 볼트업 앱 [이용내역]에서 최근 미결제된 이용 건을 선택하여 직접 재결제를 진행합니다.

미납 요금 결제가 완료되면 즉시 서비스 정지가 해제되어 정상적으로 이용하실 수 있습니다.

[미납 요금이 없고 충전기 오류가 의심되는 경우] //<------- 분기 2
서비스 이용에 불편을 드려 죄송합니다.

고객님 계정 확인 결과 미납 요금 등 결제 제한 사유는 확인되지 않습니다.
충전기에서 카드가 인식되지 않거나 결제가 진행되지 않는 경우, 충전기의 일시적인 오류일 가능성이 있습니다.
번거로우시겠지만 현장에서 충전소명 및 충전기 번호를 확인하신 후 고객센터(1660-0365)로 연락해 주시면, 기기 리셋 등 조치를 도와드리겠습니다.

추가로 궁금하신 점이 있으실 경우, //<------- 클로징 멘트
앱 내 1:1 문의하기 또는 고객센터(☎ 1660-0365)로 언제든지 연락 부탁드립니다.

감사합니다.
LG U+ VoltUp 드림.

이 산출물로도 최초의 목적인

1단계. FAQ 중심의 기본 커버리지 확보
2단계. 상담 유형별 데이터 및 대응 가이드 제공
3단계. AI의 데이터 직접 조회 및 프로세스 단축

는 달성 가능합니다.

화면에서 상담원들이 적절하게 복사-붙여넣기를 해야 하겠지만, 어찌 보면 여기서 개발은 끝났다고 볼 수도 있었습니다.

하지만 실제 상담과 그 가이드로 PoC 사이트를 만들어 산출물을 확인해보니 이걸로는 약간 아쉽다고 느꼈습니다.

그래서

분기되는 상황별 가이드는 라디오 버튼으로 고를 수 있고
선택형 멘트는 체크박스 형태로 골라 완성된 답변을 조립 하는것처럼 만든다면

원래 형상처럼 복사-붙여넣기와 텍스트 편집을 안하고 클릭 몇번으로 가이드를 활용할 수 있을거라 생각했습니다.

이에 맞게 산출물의 형상을 조정했습니다.

data class AgentGuide(
    val customerInquiryId: Long, // 원 문의 식별자
    val ments: List<Ment>, // 선택형 공통 멘트
    val templates: AnswerTemplates, // 인사, 클로징 멘트
    val draftGroups: List<AnswerDraft>, // 분기 별 상황 + 대응
    val sources: List<Source>, // 근거 문서
)

동작 예시

문의는 실제 문의 내용을 각색한것입니다.

화면은 문의와 가이드를 잘 보여주기 위해 PoC 사이트를 제작한 화면입니다.

답변은 위에서 생성한 카탈로그 기반 AI 산출 가이드입니다.

FAQ 레벨의 답변을 할 때

상담원의 확인이 필요 할 때

마치며

이번 프로젝트를 진행하며 얻은 수확은 “기술의 화려함보다 문제와 데이터의 체급에 맞는 적절한 아키텍처 선택이 훨씬 중요하다”는 점이었습니다.

RAG 패턴을 적용할 때 당연히 Vector DB와 임베딩 모델을 먼저 떠올리기 쉽습니다. 하지만 관리 인프라 공수, 개인정보 보안 우려, 그리고 ’600여 개’라는 실제 가용 데이터의 크기를 종합적으로 고려했을 때, Vector DB를 배제하고 Summary 기반의 LLM Direct Selection을 선택한 것은 매우 실용적인 선택이었습니다. 결과적으로 인프라 관리 포인트를 새로 만들지 않으면서도 준수한 가이드 품질을 얻을 수 있었습니다.

기술적 아키텍처 결정 외에도, 개인적으로 이 프로젝트에서 가장 잘했다고 느낀 부분은 직접 PoC 사이트를 구축해 UI/UX를 체감하고 산출물 스펙을 개선해 나간 경험입니다.

이전이였다면 단순 텍스트로 합쳐진 가이드 데이터만 반환하고 “백엔드 개발은 끝났다”고 선을 그었을지도 모릅니다. 하지만 직접 PoC 화면을 확인해 보니, 단순 텍스트 복사-붙여넣기는 여전히 작업 피로도를 남긴다는 점을 발견할 수 있었습니다.

이러한 시각적 체험 덕분에 가이드 응답 구조를 재설계할 수 있었고, 상담원이 ’클릭 몇 번으로 답변을 완성하는 경험’을 만들어냈습니다. 백엔드 개발자로서 단순 데이터 전달을 넘어 “진짜 일하는 사람의 경험을 개선했다”는 뿌듯함을 배운 프로젝트였습니다.