Editor’s Note
이 글은 블룸에이아이 동료들의 AI 활용 경험을 모아 전하는 시리즈입니다.
작은 실험부터 전두엽이 짜릿해지는 인사이트까지, 현장에서 직접 부딪히며 배운 이야기들을 솔직하게 풀어냅니다.
✒️
Writer: BY | 개발그룹 FX 팀장
경량 모델로도 맞춤법 교정과 문체 변환 기능을 구현할 수 있을까요?
실제 해피톡 채팅상담 내 기능 구현은 LLM API를 사용하는 방식으로 최종 결정된 상태였지만, 실험을 통해 경량 모델이 어느 정도까지 가능한지 가볍게 검증해 봤습니다.
이 실험의 계기가 된 기묘한 일화로 시작하니 재밌게 봐주세요!
🧙♂️꿈 속 조언에서 시작된 실험
현재 ‘해피톡 채팅상담’에서는 ‘친절하게 말하기’를 비롯해 맞춤법과 문장 표현을 자동으로 교정해주는 AI 어시스턴트 기능을 제공하고 있습니다.
이 기능은 FX팀에서 진행한 AI 기능 개발 프로젝트인데요.
이야기의 시작은 해당 기능을 개발하기 전, 프로젝트 타임라인을 확인하던 무렵입니다.
하루를 마무리하고 잠들기 전, 노션(Notion)에 정리된 AI 프로젝트 계획서를 살펴보고 있었어요. <AI 맞춤법 교정>과 <친절한 응대>라는 항목을 확인했죠.
그리고 ‘LLM API 사용해서 처리하면 되겠지’라고 생각하며 잠들었는데, 꿈 속에 삼국지연의에 나오는 ‘화웅*’이 나타나 제게 이렇게 말을 하는 겁니다.
“자네는 왜 닭을 잡는데 소 잡는 칼을 쓰려 하는가?*”
AI 기능을 구현한다고 하면 자연스럽게 LLM API(소 잡는 칼)부터 떠올리게 됩니다.
하지만 꿈 속 화웅의 조언처럼 실제 필요는 단순했죠.
띄어쓰기를 고치고
맞춤법을 바로잡고
말투를 상황에 맞게 바꾸는 것
이 정도는 ‘닭 잡는 일’인데, 매번 소 잡는 칼을 꺼내는 것이 맞을까요?
🧐맞춤법과 말투, 생각보다 더 중요하다
맞춤법과 문체 교정은 채팅상담 시 상담사들이 매일 마주하는 문제입니다. 사소해 보이지만 실제 현장에서는 결코 가볍지 않습니다.
맞춤법과 띄어쓰기 오류
상담 중 발생하는 맞춤법이나 띄어쓰기 오류는 작은 실수라도 대외 문서에서는 신뢰도 하락으로 이어질 수 있습니다.
사람이 직접 교정하려면 시간과 에너지가 소모되고 업무 흐름에도 영향을 줍니다.
문체와 톤의 문제
문체 역시 마찬가지입니다. 같은 문장이라도 상황에 따라 ‘친절한 상담 톤’과 ‘친근한 친구 톤’은 완전히 다릅니다.
만약 AI가 이 과정을 대신해 상황에 맞게 문장을 다듬어 줄 수 있다면, 상담사의 부담을 줄이고 응대 품질을 일정하게 유지하는 데 큰 도움이 될 수 있습니다.
이런 문제 의식에서, 맞춤법 교정과 문체 변환을 AI로 개선해보는 시도는 상담 솔루션으로서 매우 자연스럽고 올바른 방향이라고 생각했습니다.
👨💻사용한 경량 모델과 구현 과정
꿈 속 화웅의 조언에 따라, 기능 구현에 LLM API 호출 대신, 경량 모델을 직접 활용해보기로 했습니다. 이번 실험에서 사용한 모델은 이렇습니다.
맞춤법 교정 모델 : KE-T5 (1.3GB). 한국전자기술연구원의 범용 언어처리 모델.
문체 변환 모델 : Polyglot-Ko 1.3B (5GB)
👉 이런 조그마한 녀석들도 AI 모델입니다.
각 모델을 적용한 결과 아래와 같은 기능들이 구현됐습니다.
CPU/GPU 모드 기반
맞춤법 교정 기능 정상 동작
문체 변환 기능(단, GPU 성능 영향 큼)
Neural / Hanspell / Hybrid 모드 선택
Hanspell + 모델 기반 파이프라인 구축
띄어쓰기, 맞춤법, 문법 오류 교정 확인
기능 자체는 모두 동작했지만 성능과 속도는 실행 환경의 영향을 크게 받았습니다.
아키텍처 개요
전체 구조는 비교적 단순하게 구성했지만, 성능을 유지하기 위한 전환 로직과 모니터링이 포함되어 있습니다.
┌───────────────────────────────────────────────────────────────────┐
│ Streamlit Frontend │
│ (http://localhost:8501) │
│ - 60초 타임아웃 │
│ - GPU 상태 실시간 모니터링 │
└───────────────────────┬───────────────────────────────────────────┘
│ HTTP/REST
┌───────────────────────▼───────────────────────────────────────────┐
│ FastAPI Backend │
│ (http://localhost:8000) │
├───────────────────────────────────────────────────────────────────┤
│ - /api/v1/correct │
│ - /api/v1/refine-tone (+Few-shot) │
│ - /api/v1/device/status │
│ - /api/v1/device/switch │
└───────────────────────┬───────────────────────────────────────────┘
│
┌───────────────────────▼───────────────────────────────────────────┐
│ Hybrid Model Service │
├───────────────────────────────────────────────────────────────────┤
│ - 성능 모니터링 (60초 임계치) │
│ - 실시간 GPU/CPU 전환 │
└───────────────────────┬───────────────────────────────────────────┘
│
┌───────────────────────▼───────────────────────────────────────────┐
│ Polyglot Model Service │
├───────────────────────────────────────────────────────────────────┤
│ - KE-T5 Grammar Pipeline (GPU/CPU) │
│ - Polyglot-Ko Tone Converter │
│ - Hanspell API Integration │
│ - Few-shot Prompt Engineering │
│ - 중복 어미 후처리 │
└───────────────────────────────────────────────────────────────────┘🐔닭 잡는 칼, 되긴 되지만
맞춤법 교정 결과 (CPU or GPU)
입력 : 오늘 날시가 좋네여. 놀러갈께요.
출력
오늘 날씨가 좋네요. 놀러 갈게요.
실제로 몇 가지 테스트한 문장들을 표로 정리했습니다.
대부분의 일반적인 맞춤법·띄어쓰기 오류는 의도한 대로 교정됐습니다. 하지만 일부 문장은 교정이 되지 않거나 의도와 다른 결과가 나오기도 했습니다.
문체 변환(GPU 필요)
[친절한 톤 테스트]
입력 1 : 내일까지 보고서 제출해.
친절한 톤 예상
내일까지 보고서를 제출해 주시면 감사하겠습니다.
친절한 톤 실제 결과
내일까지 보고서를 제출해 주시기 바랍니다.
[친근한 톤 테스트]
입력 2 : 검토 부탁드립니다.
친근한 톤 예상
한번 봐줄래?
친근한 톤 실제 결과
이거 좀 봐줘~
문체 변환은 GPU 성능에 크게 좌우되며, 낮은 사양의 GPU 환경에서는 사실상 사용이 어렵다는 점도 확인했습니다.
실제 테스트를 기준으로 성능 요구사항을 정리해보면 이렇습니다.
맞춤법 교정
CPU: 1~2초 (동작은 하지만 느림)
GPU GTX1650: 0.5~0.8초
GPU RTX4090 예상: 0.4초 이내
문체 변환
GPU GTX1650: 30초 이상
GPU RTX4090 예상: 2~3초
RTX4090 + vLLM + 양자화 적용 시: 0.4~1초 예상
맞춤법 교정 정도는 공개된 경량 모델로 충분히 실용 가능하다는 결론을 얻었습니다.
🚨여기서 짚고 가야 할 점
한 가지, 이 지점에서 중요한 깨달음이 하나 있었는데요. <Polyglot-Ko 1.3B>는 애초에 ‘문체 변환’을 위해 만들어진 모델이 아니라는 점입니다.
Polyglot은 한국어 말뭉치를 대량으로 학습한 자유 생성용 언어 모델에 가깝습니다.
그래서 실제 테스트에서는
블로그·커뮤니티 문체가 그대로 튀어나오거나
“친절하게” 같은 지시와 무관한 문장이 생성되거나
출력 제어가 거의 불가능한 경우
이런 현상이 반복적으로 발생했습니다.
이는 구현상의 문제가 아니라 모델 설계 목적에 따른 구조적 한계라고 판단했습니다.
이 지점에서 “경량 모델이면 다 될 줄 알았다”는 초기 인지 실패를 빠르게 인정하고 방향을 틀게 됩니다.
🔄문체 변환에는 Instruction 모델이 맞다
문체 변환은 본질적으로 이런 요청입니다.
“의미는 유지하고, 지시한 톤·역할·스타일로 다시 써라”
이건 단순 생성이 아니라 조건부 생성 + 지시 이행 문제입니다.
일반 LM(Polyglot 계열 ): 통계적으로 그럴듯한 문장 생성
Instruction 모델 : 지시를 따르는 생성
이 차이는 생각보다 큽니다.
이후 실험에서는 Instruction-tuned 모델 계열로 전환했고, 로컬 개발 환경에서는 3B급 Instruction 모델이 속도와 문체 반영 측면에서 가장 현실적인 균형점이었습니다.
다만 이는 로컬 환경 기준의 판단이며, 실제 상용 서비스 환경에서는 고성능 GPU 인프라를 전제로 7B 이상 Instruction 모델을 검토하는 것이 자연스럽다고 봅니다.
그러나, 더 중요한 건 모델보다 ‘설계’
Instruction 모델은 문체 지시는 잘 따르지만, 출력 제어라는 또 다른 난이도를 함께 가져옵니다. 실제로 한자·외국어 혼입 / 불필요한 사과 표현 / 과도한 부연 설명 등의 문제가 발생했죠.
그래서 이 프로젝트에서는 출력 길이 제한 / 표현 필터링 / 후처리 로직 / 규칙 기반 폴백과 같은 서비스 차원의 제어 설계를 함께 적용했습니다.
이 과정을 통해 “좋은 모델을 쓰는 것”만으로는 부족하고, 제어까지 포함해 설계해야 비로소 서비스가 된다는 점을 체감했습니다.
🔑LLM API가 현실적이지만, 선택지는 열어두자
이번 실험의 결론은 명확합니다. ‘지금 시점에서 서비스를 운영한다는 전제’라면, LLM API가 가장 합리적인 선택입니다.
그 이유는 분명합니다. 맞춤법 교정과 같이 출력 제어 요구가 낮은 영역에서는 경량 모델로도 충분히 실용적인 성능을 확인할 수 있었지만, 문체 변환처럼 지시 이행이 중요한 작업에서는 Instruction 모델이 사실상 필수였습니다.
이 두 조건을 모두 만족하면서 안정적인 품질과 속도를 확보하려면, 현재로서는 LLM API가 가장 현실적인 선택지가 맞습니다.
정리하면 다음과 같습니다.
맞춤법 교정은 경량 모델로도 충분히 가능했고
문체 변환은 Instruction 모델이 구조적으로 필요했으며
운영 관점에서는 LLM API가 가장 효율적인 해법이었습니다.
다만 이는 ‘지금’에 대한 판단입니다. 외부 API에 대한 의존은 장기적으로 비용 상승이나 정책 변경 같은 리스크로 이어질 수 있습니다.
따라서 현재의 합리적 선택을 유지하되, 동일한 성능을 보다 경제적으로 구현할 수 있는 대안에 대해서는 완전히 가능성을 닫아둘 필요는 없다고 판단했습니다.
✒️세 줄 요약
맞춤법 교정은 경량 모델로도 충분히 실용적인 성능을 낼 수 있습니다.
문체 변환은 자유 생성 모델이 아닌 Instruction 모델이 구조적으로 필요합니다.
AI 기능의 성패는 모델 선택뿐 아니라, 출력 제어를 포함한 서비스 설계와 운영 판단에 달려 있습니다.
주석
화웅(華雄)
삼국지연의에 등장하는 장수. 동탁 휘하에서 활약했으나 관우에게 단칼에 베인 인물로 유명.
소 잡는 칼 / 닭 잡는 칼
割鷄焉用牛刀(할계언용우도). ‘닭 잡는데 어찌 소 잡는 칼을 쓰겠는가’ '라는 말.
삼국지연의에서 여포가 출격하려고 하자, 동탁 휘하 장수 화웅이 스스로 나서며 한 말.
Share article