한글 문서·데이터로 AI 제대로 쓰기: 한국 기업이 알아야 할 토큰·문서·모델의 진실

개인이 ChatGPT로 보고서 초안을 잘 뽑는다고 해서, 회사의 한글 문서와 데이터를 AI로 처리하는 일이 똑같이 잘 풀리지는 않습니다. 한국어는 영어와 토큰 경제학이 다르고, 한글 PDF·표·스캔 문서는 파싱 단계에서 무너지며, 맥락 관리 방식도 영어 기준 그대로 가져오면 비용과 정확도가 동시에 깨집니다. 한국어로 AI를 제대로 쓰려면 무엇을 알아야 하는지, 데이터와 구조를 정리했습니다.

핵심부터 말하면 이렇습니다. 셋을 알아야 합니다. 같은 분량이어도 한국어는 토큰을 더 먹습니다. 한글 문서는 추출 단계에서 더 자주 깨집니다. 한국어 성능은 모델마다 편차가 큽니다. 이 세 가지를 모르면 “AI가 우리 회사 문서를 잘 못 읽는다”는 결론에 도달하지만, 진짜 원인은 모델이 아니라 문서가 들어가는 파이프라인에 있는 경우가 대부분입니다.

한국어는 영어와 토큰 경제학이 다르다

가장 먼저 이해해야 할 사실은 한국어가 영어보다 토큰을 더 많이 소비한다는 점입니다. LLM은 글자를 그대로 읽지 않고 ‘토큰’ 단위로 쪼개 처리하는데, 영어는 1토큰이 약 4글자에 해당하는 반면 한국어는 BPE 계열 토크나이저에서 사실상 글자당 1토큰에 가깝게 잡힙니다. 즉 1,000자 한국어 텍스트가 영어 대비 훨씬 많은 토큰으로 변환됩니다(PromptCost, LLM Tokenization Explained).

추정이 아니라 실제로 잰 값입니다. 한국어처럼 교착어이면서 음절 단위가 많은 언어는 토크나이저의 ‘비옥도(fertility, 단어당 토큰 수)‘가 높게 나옵니다. 한 연구는 한국어 비옥도를 모델별로 GPT-4o 약 1.5, Gemma-2 약 1.9, Llama-3.1 약 2.3으로 측정했고, 영어는 대략 1.2~1.4 수준입니다(KORMo: Korean Open Reasoning Model, arXiv). CJK(한중일) 문자는 학습 코퍼스에서 상대적으로 드물고 영어처럼 효율적으로 병합되지 않기 때문에, 같은 ‘의미’를 담아도 토큰 수가 더 많아진다는 것이 일관된 결론입니다.

이 차이가 기업에 미치는 영향은 두 가지입니다. 첫째, 비용입니다. API는 토큰 단위로 과금되므로, 한국어 문서 처리는 동일 분량의 영어보다 입력·출력 비용이 구조적으로 더 듭니다. 둘째, 컨텍스트 한도입니다. 모델의 컨텍스트 창이 20만 토큰이라 해도, 한국어 문서는 영어 기준으로 환산한 것보다 더 적은 분량밖에 못 담습니다. 긴 계약서·규정집을 통째로 넣는 설계는 영어 사례를 보고 따라 하면 한국어에서 먼저 한도에 부딪힙니다.

실무 시사점은 명확합니다. “토큰을 아끼는 설계”가 한국어에서는 선택이 아니라 기본입니다. 불필요한 반복 프롬프트 제거, 문서 사전 요약·청크 분할, 캐싱 활용 같은 것이 영어권보다 더 큰 비용 절감으로 돌아옵니다.

한글 문서·표·PDF는 ‘읽기’ 전에 ‘추출’에서 깨진다

두 번째로 흔한 오해는 “AI가 표를 못 읽는다”는 것입니다. 실제로는 AI가 표를 못 읽는 게 아니라, 표가 AI에게 전달되기 전에 이미 깨져 있는 경우가 대부분입니다. 한글 문서, 특히 HWP에서 출발한 PDF, 셀 병합이 많은 행정·재무 양식, 스캔본은 텍스트 추출 단계에서 구조가 무너집니다.

한국 문서는 표가 유난히 복잡하다는 점이 실무자들 사이에서 공통적으로 지적됩니다. 셀 병합, 표 안의 표(nested table), 머리글이 여러 줄인 양식이 흔해서, PDFMiner 같은 일반 PDF 라이브러리로는 표 구조를 거의 살리지 못합니다. 이런 복잡한 한글 표를 처리하려면 Naver Clova OCR, Upstage 같은 한국어 특화 OCR로 텍스트와 표를 함께 추출하는 접근이 권장됩니다(AutoRAG, 한국어 OCR 비교).

여기서 기업이 놓치는 지점이 있습니다. 같은 PDF라도 (1) 텍스트가 살아 있는 디지털 PDF, (2) HWP/오피스에서 변환된 레이아웃 PDF, (3) 종이를 스캔한 이미지 PDF는 완전히 다른 처리 경로가 필요합니다. 1번은 라이브러리로 충분하지만, 2·3번은 OCR과 레이아웃 인식이 들어가야 합니다. 회사 문서를 한 가지 방식으로만 처리하다가 “AI가 우리 양식을 못 읽는다”고 결론 내리는 일이 여기서 발생합니다.

우리가 구축한 거래처등록 자동화 사례가 이 문제를 정확히 다룹니다. 거래처가 보내온 사업자등록증·통장 사본 PDF를 파싱하고, 그 값으로 등록 시스템을 브라우저 자동화로 채우되, 추출이 애매하거나 검증이 필요한 항목은 자가복구 로직으로 재시도하고 최종 승인만 사람이 누르도록 설계했습니다. 핵심은 “모델을 더 좋은 걸로 바꾸는 것”이 아니라 추출-검증-복구의 파이프라인을 한글 문서 특성에 맞게 짜는 것이었습니다. 같은 원리로 영상 분석은 1시간 걸리던 작업을 3분으로(95% 단축), 회의록은 STT에서 액션 아이템 추출까지 자동으로 연결했습니다.

한국어 성능은 모델마다 다르다. 벤치마크로 골라야 한다

“GPT가 제일 똑똑하니까 한국어도 제일 잘하겠지”는 위험한 가정입니다. 한국어 성능은 영어 종합 성능 순위와 정확히 일치하지 않으며, 모델·버전·작업 유형에 따라 순위가 바뀝니다. 그래서 한국어 작업을 본격적으로 돌릴 때는 한국어 벤치마크를 직접 확인해야 합니다.

대표적인 평가가 업스테이지와 NIA가 운영해 온 Open Ko-LLM Leaderboard입니다. 이 리더보드는 Hugging Face의 글로벌 Open LLM Leaderboard 구조를 따르되 한국어로 평가하며, Ko-Hellaswag(상식 추론), Ko-ARC(과학·상식), Ko-MMLU(다영역 지식), Ko-CommonGen V2(문장 생성), Ko-TruthfulQA(사실성)로 구성된 Ko-H5 벤치마크를 사용합니다(Open Ko-LLM Leaderboard, arXiv). 후속 버전인 Open Ko-LLM Leaderboard2는 기존 과제를 실제 활용 능력에 더 가까운 과제로 교체하고, 한국어 고유 특성을 반영한 네이티브 한국어 벤치마크 4종을 새로 도입했습니다(Open Ko-LLM Leaderboard2, ACL Anthology).

여기서 핵심은 ‘리더보드 1등 모델을 쓰자’가 아닙니다. 우리 회사가 하는 작업 유형과 가까운 벤치마크를 보고 고르자는 것입니다. 사실성이 중요한 고객 응대라면 TruthfulQA 계열, 전문 지식 질의라면 MMLU 계열, 자연스러운 문장 생성이라면 CommonGen 계열 점수가 의미 있습니다. 작업과 무관한 종합 1등 점수를 보고 모델을 정하면, 정작 우리 업무에서는 더 싼 모델이 더 잘하는 상황을 놓치게 됩니다.

실전에서는 한 가지 모델로 통일하기보다, 작업별로 다른 모델을 라우팅하는 편이 비용과 품질 모두에서 유리한 경우가 많습니다. 단순 분류·추출은 가볍고 싼 모델로, 복잡한 추론·생성은 상위 모델로 나누는 식입니다. 이런 선택은 감이 아니라 사내 데이터로 직접 측정해서 정해야 합니다. 우리 회사가 어떤 작업부터 손대야 하는지 가늠하기 어렵다면, 무료 AI 진단으로 현재 업무 중 자동화 적합도가 높은 지점을 먼저 짚어볼 수 있습니다.

한국어 맥락 관리: 프롬프트보다 ‘Context Engineering’

개인이 AI를 쓸 때는 그때그때 프롬프트를 잘 쓰는 것으로 충분합니다. 하지만 회사가 AI로 일하는 방식을 바꾸려면, 매번 다시 설명하지 않아도 AI가 회사의 맥락(용어, 규정, 직전 결정, 데이터 위치)을 가지고 일하도록 만드는 컨텍스트 엔지니어링이 필요합니다. 한국어 환경에서는 이게 특히 중요한데, 앞서 본 토큰 비용 때문에 “맥락을 매번 통째로 집어넣는” 방식이 빠르게 비싸지기 때문입니다.

좋은 한국어 프롬프트의 기본 원칙은 단순합니다. 우리는 이를 T.I.G.E.R 프레임으로 정리합니다 — Task(무엇을), Input(어떤 자료로), Goal(어떤 결과를), Example(예시), Refine(다듬기). 특히 한국어는 주어 생략·존대·동음이의가 많아 모델이 맥락을 잘못 잡기 쉬우므로, 출력 형식과 예시를 명시적으로 주는 것이 영어보다 더 큰 차이를 만듭니다. 프롬프트 설계의 더 자세한 원칙은 프롬프트 5원칙에서 다룹니다.

하지만 프롬프트 잘 쓰기만으로는 회사가 바뀌지 않습니다. 한국 기업의 AI 실패는 대개 세 가지 패턴으로 나타납니다. (1) 개인별로 각자 ChatGPT를 쓰지만 노하우가 흩어져 개인 분산되고, (2) 한 번 잘 된 작업이 다음에 재현되지 않아 축적되지 않으며, (3) AI 결과가 실제 업무 시스템과 연결되지 않아 단절됩니다. 맥락 관리를 시스템으로 만든다는 것은, 한국어 용어집·업무 규칙·문서 위치를 AI가 항상 참조하는 자산으로 만들어 이 세 단절을 메우는 일입니다.

우리가 구축한 통합운영 사례에서는 위키 150여 건을 3개 에이전트가 공유 맥락으로 참조하도록 묶어, 재계약 196건 같은 반복·연결·누적 업무를 사람의 재설명 없이 처리하도록 했습니다. 결재는 30분에서 3분으로(12개 도구·자가복구), 영업 대시보드의 음성 기록은 30분에서 5분으로 줄었습니다. 공통점은 “더 좋은 프롬프트”가 아니라 “맥락이 시스템에 박혀 있는가”였습니다.

자동화할 일과 사람이 쥘 일을 먼저 가른다

한국어·한글 문서 처리를 자동화하기 전에 반드시 선행되어야 하는 판단이 있습니다. 무엇을 AI에게 넘기고 무엇을 사람이 쥐느냐입니다. 이 선을 긋지 않으면, 한국어 처리 기술이 아무리 좋아져도 엉뚱한 곳을 자동화하다 신뢰를 잃습니다.

원칙은 단순합니다. AI에게 넘길 일은 ✓반복되고 ✓연결되고 ✓누적되고 ✓복구 가능한 작업입니다. 사람이 쥘 일은 ✗최종 결정, ✗신뢰가 걸린 판단, ✗창의가 필요한 작업입니다. 한글 문서 처리에 대입하면, 표 추출·데이터 정규화·1차 분류는 AI가 맡되, 그 결과를 근거로 한 최종 승인과 예외 판단은 사람이 쥐는 구조가 됩니다. 거래처등록 자동화에서 “최종 승인만 사람”으로 둔 것이 바로 이 원칙입니다.

이 판단이 중요한 이유는 데이터가 말해줍니다. 한국 기업의 AI 도입률은 32%로 아시아·태평양 평균 24%를 앞섰지만(Dell Technologies·IDC, 디지털데일리 보도), 글로벌 차원에서 보면 도입과 ‘성과’는 다른 문제입니다. 맥킨지 조사에 따르면 AI를 도입한 조직의 약 3분의 2는 아직 전사적으로 AI를 확장하지 못했고, AI로 전사 수준의 EBIT(영업이익) 변화를 본다고 답한 곳은 39%에 그쳤으며 그마저도 대부분 영향이 5% 미만이라고 답했습니다(McKinsey, The State of AI 2025). 도입은 했지만 성과로 이어지지 못하는 ‘스케일링 갭’의 본질이, 바로 무엇을 어떻게 자동화할지 선을 긋지 못한 데 있습니다.

한국어 AI를 제대로 쓴다는 것은 결국 기술과 판단을 함께 갖추는 일입니다. 토큰·문서·모델의 한국어 특성을 이해하고, 그 위에 자동화 경계와 맥락 관리 시스템을 얹어야 비로소 “회사가 AI로 일하는 방식”이 됩니다. 우리 회사가 지금 어느 단계에 있는지 궁금하다면, 무료 AI 진단으로 현재 위치와 다음 한 걸음을 확인하실 수 있습니다.

자주 묻는 질문

한국어로 AI를 쓰면 영어보다 비용이 더 드나요?

네, 구조적으로 더 듭니다. LLM은 토큰 단위로 과금되는데, 영어는 1토큰이 약 4글자인 반면 한국어는 사실상 글자당 1토큰에 가깝게 잡혀 같은 분량이라도 토큰 수가 훨씬 많습니다(PromptCost). 한 연구에서 한국어 단어당 토큰 수(비옥도)는 모델별로 1.52.3 수준으로, 영어(1.21.4)보다 높게 측정됐습니다(KORMo, arXiv). 그래서 한국어 환경에서는 문서 사전 요약, 청크 분할, 캐싱 같은 토큰 절약 설계의 효과가 영어권보다 더 큽니다.

AI가 우리 회사 한글 표·PDF를 잘 못 읽는데 모델을 바꾸면 되나요?

대개 모델 문제가 아니라 추출 단계 문제입니다. 셀 병합이 많고 표 안에 표가 들어가는 복잡한 한글 양식이나 스캔본 PDF는, 모델에 전달되기 전 텍스트 추출에서 이미 구조가 깨집니다. 일반 PDF 라이브러리로는 한국 문서의 복잡한 표를 살리기 어려워, Naver Clova OCR이나 Upstage 같은 한국어 특화 OCR로 텍스트와 표를 함께 추출하는 접근이 권장됩니다(AutoRAG). 모델 교체보다 추출-검증-복구 파이프라인을 문서 특성에 맞게 설계하는 것이 우선입니다.

어떤 모델이 한국어를 가장 잘하나요?

하나로 단정하기 어렵고, 작업 유형에 따라 달라집니다. 한국어 성능은 영어 종합 성능 순위와 일치하지 않으므로, Open Ko-LLM Leaderboard 같은 한국어 벤치마크에서 우리 작업과 가까운 항목(사실성·전문지식·문장생성 등)을 직접 확인해야 합니다(Open Ko-LLM Leaderboard, arXiv). 실전에서는 단순 추출은 가벼운 모델, 복잡한 추론은 상위 모델로 작업별 라우팅하는 편이 비용·품질 모두에 유리한 경우가 많습니다.

한국어 프롬프트는 영어와 다르게 써야 하나요?

원칙은 같지만 한국어에서 더 신경 써야 할 부분이 있습니다. 한국어는 주어 생략, 존대, 동음이의가 많아 모델이 맥락을 잘못 잡기 쉬우므로, 출력 형식과 예시를 명시적으로 주는 것이 영어보다 더 큰 차이를 만듭니다. Task·Input·Goal·Example·Refine(T.I.G.E.R) 구조로 작성하면 안정적입니다. 자세한 원칙은 프롬프트 5원칙을 참고하세요.

개인이 잘 쓰는 것과 회사가 AI로 일하는 건 뭐가 다른가요?

개인은 매번 프롬프트를 잘 쓰면 충분하지만, 회사는 매번 다시 설명하지 않아도 AI가 회사 맥락(용어·규정·데이터 위치)을 갖고 일하도록 시스템화해야 합니다. 한국 기업의 AI 실패는 보통 개인별로 노하우가 흩어지고(개인 분산), 잘 된 작업이 재현되지 않으며(축적 안 됨), AI 결과가 업무 시스템과 끊기는(단절) 세 패턴으로 나타납니다. 맥킨지 조사에서도 AI 도입 조직의 약 3분의 2가 아직 전사 확장에 이르지 못했다고 분석합니다(McKinsey, State of AI 2025). 이 단절을 메우는 것이 컨텍스트 엔지니어링과 자동화 경계 설계입니다.