한국어 LLM 활용 과제

이 장에서 배울 것

이번 장에서는 한국어 데이터와 한국 업무 환경에서 LLM을 쓸 때 생기는 실무 문제를 다룬다. 핵심은 단순하다. 한국어 LLM 활용은 "영어로 잘 되는 것을 한국어로 번역하면 된다"의 문제가 아니다. 조사, 어미, 띄어쓰기, 존댓말, 문서 양식, 개인정보, 보안 정책, 평가 데이터 부족이 함께 얽힌 문제다.

이 장을 마치면 다음을 설명할 수 있어야 한다.

• 한국어의 언어 구조가 토큰 수와 검색 품질에 미치는 영향

• 한국어 업무 문서를 RAG에 넣을 때 보존해야 할 구조

• 글로벌 LLM, 국내 모델, 오픈 가중치 모델을 비교하는 기준

• 한국어 LLM 평가에서 공개 벤치마크와 실제 업무 품질이 달라지는 이유

• 한국어 답변 오류를 유형별로 분류하고 개선하는 방법

왜 이 주제가 중요한가

앞 장에서는 LLM 답변을 평가하고 hallucination을 줄이는 방법을 배웠다. 이제 그 기준을 한국어 문서에 적용해야 한다. 그런데 한국어 문서는 영어 문서와 다른 난점을 가진다.

예를 들어 "계약을 해지할 수 있습니다"와 "계약이 해지됩니다"는 비슷해 보이지만 법적 의미가 다르다. "근로자에게 지급한다"와 "근로자에게 지급할 수 있다"도 다르다. 조사 하나, 어미 하나가 권리와 의무를 바꿀 수 있다. 고객센터 챗봇이 이런 차이를 놓치면 단순한 문체 오류가 아니라 업무 사고가 된다.

토큰 비용도 중요하다. LLM은 글자 수가 아니라 토큰 수를 기준으로 입력을 처리한다. 한국어는 사용하는 토크나이저에 따라 같은 의미의 영어 문장보다 더 많은 토큰을 쓰는 경우가 있다. 한 분석에서도 GPT 계열 BPE 토크나이저에서 한국어를 포함한 CJK 텍스트가 영어 대응 문장보다 더 많은 토큰을 사용할 수 있음을 설명한다¹. 다만 모든 모델에서 항상 그렇다고 단정해서는 안 된다. 중요한 것은 실제로 사용할 모델의 토크나이저로 측정하는 습관이다. "컨텍스트 창이 크다"는 말만 믿고 긴 한국어 문서를 그대로 넣으면 비용, 속도, 검색 품질이 동시에 흔들릴 수 있다.

핵심 개념 설명

한국어는 의미 단위가 작게 흔들린다

한국어에는 조사와 어미가 많다. "회사에서", "회사에게", "회사의", "회사로부터"는 모두 "회사"가 들어가지만 문장 안 역할이 다르다. 임베딩 검색은 의미가 가까운 문서를 찾지만, 이런 미세한 차이를 항상 정확히 구분하지는 못한다.

띄어쓰기도 문제다. "장기요양보험료"와 "장기 요양 보험료"는 사람이 보기에는 거의 같은 말이지만, 검색 시스템에서는 다르게 쪼개질 수 있다. "개인정보처리방침", "개인 정보 처리 방침", "개인정보 처리방침"도 마찬가지다. 복합명사가 많은 공공·법률·금융 문서에서는 이런 차이가 검색 누락으로 이어질 수 있다.

존댓말과 높임 표현도 품질 요소다. 고객 응대에서는 "해라체" 답변이 무례하게 느껴질 수 있고, 사내 보고서에서는 지나치게 구어적인 표현이 신뢰를 떨어뜨린다. 한국어 LLM 평가는 사실 정확성뿐 아니라 문체의 일관성도 함께 봐야 한다.

청킹은 문서 구조를 자르는 일이 아니다

RAG에서 청킹은 문서를 작은 조각으로 나누는 과정이다. 하지만 한국어 업무 문서에서는 단순히 500토큰마다 자르면 안 된다. 조항 번호, 제목, 표, 붙임, 별지, 페이지 번호, 시행일, 개정 이력 같은 구조가 의미를 만든다.

예를 들어 사내 규정에서 다음 두 문장은 떨어져 있으면 안 된다.

제12조(휴가의 승인) 휴가는 부서장의 사전 승인을 받아야 한다.
단, 긴급한 사유가 있는 경우 사후 승인을 받을 수 있다.

두 번째 문장만 검색되면 "사후 승인 가능"이라는 답이 과도하게 일반화된다. 첫 문장만 검색되면 예외가 사라진다. 그래서 청킹은 문장 길이보다 의미 단위를 기준으로 해야 한다. 제목과 조항 번호를 메타데이터로 보존하고, 표는 행과 열의 관계를 잃지 않게 변환해야 한다.

모델 선택은 한국어 유창성만의 문제가 아니다

한국어를 자연스럽게 쓰는 모델이 항상 좋은 업무 모델은 아니다. 모델 선택 시 최소한 다음 기준을 함께 봐야 한다.

국내 모델이라는 이유만으로 보안 요구가 자동 충족되는 것은 아니다. 반대로 글로벌 모델이라고 해서 항상 사용할 수 없는 것도 아니다. 중요한 것은 계약 조건, 배포 위치, 로그 보관, 학습 사용 여부, 접근 통제, 마스킹 정책을 확인하는 일이다.

한국어 평가는 공개 순위만으로 부족하다

한국어 LLM 평가에서는 공개 리더보드가 도움이 된다. 하지만 리더보드 점수가 곧 우리 회사 업무 품질을 보장하지는 않는다. Open Ko-LLM Leaderboard2 논문은 기존 한국어 평가가 지나치게 학술 벤치마크에 치우치거나 영어 벤치마크 번역에 의존할 때 실제 사용 능력과 간극이 생길 수 있다고 지적한다². 그래서 한국어 고유의 언어 특성과 실제 사용 능력을 더 잘 반영하는 평가가 필요하다.

업무 도입에서는 별도 평가셋을 만들어야 한다. 실제 사내 문서 20개, 실제 사용자 질문 100개, 정답 또는 근거 문단, 금지 답변 기준을 준비하라. 공개 리더보드는 후보 모델을 줄이는 데 쓰고, 최종 판단은 조직의 문서와 질문으로 해야 한다.

쉬운 비유 또는 사례

한국어 RAG 시스템은 도서관 사서와 비슷하다. 좋은 사서는 책 제목만 보지 않는다. 목차, 장 번호, 각주, 부록, 개정판 여부를 함께 본다. "퇴직금 지급 기준이 뭐야?"라는 질문을 받았을 때, 예전 규정과 최신 규정을 구분하고, 본문과 별표를 함께 확인한다.

나쁜 RAG 시스템은 문서를 잘게 찢어 바구니에 넣은 뒤, 비슷해 보이는 종이 몇 장을 꺼내 답하는 사서와 같다. 종이에 "지급할 수 있다"가 보이면 "지급됩니다"라고 말한다. 표의 헤더를 잃어버리면 2023년 금액을 2024년 금액처럼 말한다. 문체는 자연스러울 수 있지만 근거는 틀릴 수 있다.

기업용 한국어 RAG 평가에서도 문서 파싱, 검색, 답변 생성 전 과정을 함께 봐야 한다. 국내 RAG 리더보드 사례는 금융, 공공, 의료, 법률, 커머스 등 분야별 문서를 대상으로 평가하며, RAG를 파서·리트리버·생성의 세 구성 요소로 나누어 본다³. 이 관점은 실무에 유용하다. 답변이 틀렸을 때 "모델이 나쁘다"로 끝내지 않고, 표 추출 실패인지, 검색 실패인지, 생성 단계의 과장인지 분리할 수 있기 때문이다.

직접 해보는 실습

아래의 짧은 한국어 문서를 사용해 오류 분류 실습을 해보자.

문서: 사내 교육비 지원 규정 발췌
제5조(지원 대상) 회사는 정규직 임직원에게 직무 관련 교육비를 지원할 수 있다.
제6조(지원 한도) 연간 지원 한도는 1인당 50만 원이다. 단, 정보보안 필수 교육은 한도와 별도로 전액 지원한다.
제7조(신청 절차) 임직원은 교육 시작 7일 전까지 부서장의 승인을 받아 신청해야 한다. 긴급한 업무상 필요가 있는 경우 교육 종료 후 3일 이내 사후 신청할 수 있다.
별지1. 신청서에는 성명, 사번, 부서, 교육기관, 교육명, 결제 영수증을 포함한다.

1단계: 네 가지 작업을 시킨다

LLM에 다음 작업을 요청한다.

1. 문서 요약

2. 키워드 5개 추출

3. "계약직도 지원받을 수 있나요?"에 답변

4. "정보보안 교육은 50만 원 한도 안에서 지원되나요?"에 출처 포함 답변

2단계: 오류를 분류한다

답변을 다음 기준으로 표시한다.

3단계: 개선 프롬프트를 적용한다

다음 문장을 시스템 지시 또는 개발자 지시에 추가해 비교한다.

문서에 명시된 내용만 답하라. "지원할 수 있다"는 재량 표현으로 해석하라. 대상이 명시되지 않은 경우 확대 해석하지 말라. 답변 끝에 조항 번호를 표시하라. 개인정보 항목은 예시로 재출력하지 말라.

4단계: RAG 설정을 바꿔 본다

같은 문서를 다음 세 방식으로 나눠 검색 결과가 달라지는지 본다.

• 방식 A: 300자 단위로 단순 분할

• 방식 B: 조항별 분할

• 방식 C: 조항별 분할 + 제목·조항 번호를 메타데이터로 저장

대부분의 경우 C가 가장 안정적이다. "정보보안 필수 교육" 질문은 제6조의 단서 문장까지 함께 검색되어야 정확히 답할 수 있다.

흔한 실수와 오류 분석

실수 1: 승인되지 않은 환경에 개인정보를 그대로 넣는다

상담 기록, 의료 기록, 고객센터 로그, 계약서에는 이름, 전화번호, 주소, 주민등록번호, 계좌번호, 사번이 섞여 있을 수 있다. 이런 데이터를 LLM에 입력하기 전에는 조직의 보안 정책, 서비스 계약, 데이터 보관·학습 사용 여부, 접근 권한, 로그 저장 방식을 확인해야 한다.

특히 승인되지 않은 외부 LLM이나 개인 계정에 원문을 그대로 넣는 것은 피해야 한다. 필요한 경우 개인정보를 마스킹하거나, 내부 승인된 도구를 사용하거나, 로컬·전용 배포 환경을 검토해야 한다. 원문 저장소, 전처리 단계, LLM 입력 로그, 평가 데이터셋에서 개인정보가 어떻게 처리되는지도 함께 확인하라.

실수 2: 자연스러운 문체를 정확성으로 착각한다

한국어 답변이 매끄러우면 맞는 말처럼 보인다. 하지만 "지원할 수 있다"를 "지원한다"로 바꾸는 순간 의미가 바뀐다. 한국어 LLM 평가에서는 유창성, 근거 충실성, 용어 해석을 분리해서 채점해야 한다.

실수 3: 국내 모델이면 보안이 해결된다고 본다

국내 기업이 만든 모델이라도 SaaS API로 쓰면 데이터가 외부로 나갈 수 있다. 로컬 모델이라도 운영 로그에 원문이 남으면 위험하다. 보안은 모델 국적이 아니라 배포 구조와 운영 절차의 문제다.

실수 4: 로컬 모델 비교 글을 그대로 믿는다

블로그의 모델 순위는 참고 자료일 뿐이다. 하드웨어, 양자화 방식, 프롬프트, 샘플 질문, 평가자 기준이 바뀌면 결과도 바뀐다. 특히 한국어에서는 존댓말 유지, 외국어 혼입, 행정 표현 해석, 긴 문서 근거 추적을 따로 실험해야 한다.

요약

한국어 LLM 활용은 번역 문제가 아니라 시스템 설계 문제다. 한국어의 조사, 어미, 띄어쓰기, 복합명사는 토큰화와 검색 품질에 영향을 준다. 업무 문서에서는 조항 번호, 표, 붙임, 별지, 개정 이력 같은 구조를 보존해야 한다. 모델 선택은 한국어 유창성뿐 아니라 RAG 적합성, 도구 호출, 배포 방식, 비용, 보안, 라이선스를 함께 봐야 한다. 공개 벤치마크는 출발점일 뿐이며, 최종 검증은 조직의 실제 문서와 질문으로 해야 한다.

퀴즈

1. 한국어 RAG에서 복합명사가 검색 실패를 일으킬 수 있는 이유는 무엇인가?

2. "지급할 수 있다"와 "지급한다"는 LLM 평가에서 어떤 오류 유형으로 구분할 수 있는가?

3. 국내 모델을 사용하더라도 개인정보·보안 검토가 필요한 이유는 무엇인가?

4. 공개 한국어 LLM 리더보드 점수만으로 업무 도입을 결정하면 안 되는 이유는 무엇인가?

5. 조항 기반 문서를 청킹할 때 조항 번호를 메타데이터로 저장하면 어떤 장점이 있는가?

체크리스트

• 한국어 문서의 띄어쓰기, 조사, 복합명사 변형을 점검했다.

• 문서를 길이 기준만이 아니라 제목·조항·표 구조 기준으로 나눴다.

• 표, 붙임, 별지, 개정 이력, 시행일을 메타데이터로 보존했다.

• 개인정보 마스킹 정책을 LLM 입력 전 단계에 적용했다.

• 후보 모델을 실제 업무 질문으로 비교했다.

• 유창성, 사실성, 근거 충실성, 문체 적합성을 따로 평가했다.

• 공개 벤치마크와 내부 평가셋의 차이를 기록했다.

• 답변 오류를 검색 실패와 생성 오류로 분리해 분석했다.

다음 장 연결

다음 장에서는 지금까지 배운 내용을 하나의 미니 프로젝트로 묶는다. 한국어 문서를 업로드하고, 청킹하고, 임베딩하고, 검색한 뒤, 출처가 있는 답변을 생성하는 RAG 챗봇을 만든다. 이번 장의 체크리스트는 다음 장 프로젝트의 평가 기준이 된다.

참고

¹Working with Chinese, Japanese, and Korean text in Generative AI pipelines

²Open Ko-LLM Leaderboard2: Bridging Foundational and Practical Evaluation for Korean LLMs

³RAG 리더보드 공개-금융, 공공, 의료, 법률, 커머스 한국어 RAG 성능 평가