텍스트 마이닝 Text mining
데이터 분석을 하다 보면 숫자보다 더 다루기 까다로운 것이 바로 텍스트 데이터입니다.
텍스트는 사람의 언어이기 때문에 불규칙하고, 중의적이며, 때로는 오류도 많습니다.
그래서 체계적인 전처리 과정과 분석 절차가 필수인데요.
오늘은 텍스트 데이터 분석의 기본적인 흐름을 차근차근 정리해 보겠습니다.
분석의 출발점은 데이터입니다.
수집 경로:
웹 크롤링(뉴스, 블로그, SNS), 설문 응답, 콜센터 상담 기록, 공개 데이터셋 등
AI Hub (https://aihub.or.kr/)
긴급 신고, 상담 대화, 감정 대화, 의료·법률 상담 등 한국어 특화 대규모 데이터 제공
공공데이터포털 (https://www.data.go.kr/)
민원 상담 기록, 행정 전화 기록, 공공 행정 관련 텍스트 데이터 제공
국립국어원 말뭉치 (https://corpus.korean.go.kr/)
구어, 문어, 학습자 말뭉치 등 현대 한국어 대규모 코퍼스 제공
ETRI 개방형 언어자원 (https://aiopen.etri.re.kr/service_dataset.php)
한국어 음성·텍스트 데이터, 대화/질의응답 데이터 제공
NSMC (네이버 영화 리뷰) (https://github.com/e9t/nsmc)
한국어 감성 분류용 영화 리뷰 데이터셋 제공
Kaggle (https://www.kaggle.com/)
고객센터 대화, 리뷰, 감정 분류 등 전 세계 다양한 공개 데이터셋 제공
Hugging Face Datasets (https://huggingface.co/datasets)
대화(DailyDialog, MultiWOZ), 감정, QA 등 다양한 오픈소스 데이터셋 제공
주의사항:
개인정보(이름, 전화번호, 주소 등)를 반드시 비식별화해야 하고,
활용 목적에 대한 동의도 필요합니다.
수집한 텍스트는 대부분 불필요한 정보가 섞여 있습니다.
따라서 데이터 분석에 맞게 가볍게 다듬는 과정이 필요합니다.
원칙: “필요한 만큼만”
지나친 정제는 중요한 의미까지 사라지게 만듭니다.
따라서 목적에 맞게 필요한 정도만 정제하는 것이 핵심입니다.
사람이 입력한 텍스트에는 맞춤법이나 띄어쓰기 오류가 많습니다.
도구: pykospacing, 네이버 맞춤법 검사기 API 등 자동화 도구 활용
예시
- 입력: 오늘너무춥네진짜
- 교정: 오늘 너무 춥네 진짜
반복 문자 축소: 감정을 표현하기 위해 과도하게 반복된 글자를 줄임
- 예시: ㅋㅋㅋㅋㅋ → ㅋ
- 예시: 좋아아아아 → 좋아
이모지/특수문자 처리: 분석 목적에 따라 제거 또는 변환
예시: ❤️ → <이모지> 또는 삭제
대소문자 통일(영문): Hello, HELLO → hello
숫자/날짜 표준화:
- 예시: 2025년 8월 28일 → 2025-08-28
- 예시: 010-1234-5678 → <전화번호>
문장에서 의미적으로 크게 도움이 되지 않는 단어 제거
공통 불용어: "은", "는", "이", "가", "그리고"
도메인 특화 불용어: 특정 데이터셋에서 자주 등장하지만 의미가 없는 단어
예시: 신고 데이터 → “신고”, “기사님”
제거 전: 기사님 여기 불 좀 꺼주세요
제거 후: 불 꺼주세요
같은 의미를 가진 단어를 하나의 표현으로 통일
예시
- 부산역, Busan Station → 부산역
- 휴대폰, 핸드폰 → 휴대폰
- 서울대, 서울대학교 → 서울대학교
한국어는 조사와 어미가 많아서 단어 변형이 다양합니다.
형태소 분석기 (Mecab, Komoran, Okt 등) 사용 → 단어의 뿌리 형태를 추출
예시
- 입력: 먹었다, 먹고, 먹는 중
- 처리: 먹다
위치·인명·시설명은 분석에 중요한 단서이므로 삭제하면 안 됨
예시
- 원문: 광주 동명동에서 화재가 발생했어요
- 처리: 광주 동명동(지명) 유지, 화재(사고유형) 유지
개인정보 패턴을 탐지하여 마스킹 처리
예시
- 전화번호: 010-1234-5678 → <전화번호>
- 주민등록번호: 901010-1234567 → <주민번호>
- 계좌번호: 123-456-789012 → <계좌번호>
사람 이름, 주소, 기관명 등은 NER 모델로 탐지 후 마스킹
예시
- 원문: 홍길동이 서울 강남구에서 신고했어요
- 처리: <이름>이 <지역>에서 신고했어요
동일하거나 거의 동일한 문장이 여러 번 등장할 경우 제거
MinHash / Cosine Similarity 활용
예시
- 문장1: 불이 나서 연기가 심해요
- 문장2: 불이 나서 연기가 심합니다
→ 의미적으로 동일 → 하나만 남김
너무 짧거나 지나치게 긴 텍스트 제거
예시
- “네”, “아”, “응” 같은 짧은 문장 → 제거
- 10,000자 이상인 문서(로그 오류 등) → 제거
텍스트 데이터를 다룰 때 가장 먼저 하는 일은
“토큰화(Tokenization)”,
즉 문장을 작은 단위로 쪼개는 작업입니다.
이 과정이 잘 되어야 피처 추출, 키워드 분석, 분류, 요약, 질의응답(QA)까지 모든 단계가 탄탄해집니다.
그렇다면 토큰화는 어떻게 선택해야 할까요?
전통적인 머신러닝 모델을 쓴다면 형태소 분석(+n-gram),
최신 Transformer 모델을 쓴다면 서브워드 토큰화가 보통 최선입니다.
방법: 공백 기준으로 단순히 단어를 나눔
장점: 빠르고 간단
한계: 한국어처럼 조사·어미가 많은 언어에는 부정확
예시
- 원문: 광주 동명동에서 차 사고가 났고 운전자가 의식을 잃었어요
- 결과: [광주, 동명동에서, 차, 사고가, 났고, 운전자가, 의식을, 잃었어요]
- 문제: “동명동에서”, “잃었어요”처럼 뿌리 단어(표제어)를 잃음
언제 쓰나? 데이터 감 잡기, 빠른 베이스라인 실험
방법: 문장을 명사, 동사, 형용사 같은 자립 형태소와 조사, 어미 같은 문법 형태소로 분리
장점: 한국어 의미를 잘 보존, 불필요한 조사 제거로 깔끔
도구: Mecab, Komoran, Okt 등
예시
- 원문: 광주 동명동에서 차 사고가 났고 운전자가 의식을 잃었어요
- 결과:
[광주/NNP, 동명동/NNP, 차/NNG, 사고/NNG, 나다/VV, 운전자/NNG, 의식/NNG, 잃다/VV] → 지명, 사고 유형, 증상 같은 핵심 정보가 뚜렷하게 드러남
언제 쓰나? 전통 ML 파이프라인(TF-IDF + SVM/로지스틱) 키워드 분석, 규칙 기반 분류
방법: 단어를 더 작은 부분 문자열로 쪼개는 현대 LLM의 표준 방식
대표: BERT(WordPiece), RoBERTa(BPE), SentencePiece(Unigram)
장점: 신조어, 오탈자에도 강함 / 사전 크기 작아 효율적
예시 (BERT 토크나이저)
- “의식소실” → ['의', '##식', '##소', '##실']
- “동명동” → ['동', '##명', '##동']
언제 쓰나?
BERT, RoBERTa 같은 Transformer 모델 파인튜닝 시, 최신 모델을 활용한 정확도 최우선 작업
방법: 문단을 문장 단위로 나눔
도구: 한국어 kss 라이브러리 활용
예시
- 원문: 차에 불이 나요. 연기가 심해요! 운전자가 반응이 없습니다.
- 결과: ["차에 불이 나요.", "연기가 심해요!", "운전자가 반응이 없습니다."]
언제 쓰나? 요약, QA, 검색 기반 응답(RAG) 등에서 문장별 의미 단위가 필요할 때
방법: 연속된 n개의 단어를 묶어 하나의 단위로 분석
장점: 단일 단어로는 잡히지 않는 관용구 포착
예시: “의식 소실”, “호흡 곤란”, “가스 냄새”
언제 쓰나? 전통 ML 기반 TF-IDF 분류에서 성능 향상
빠른 테스트: 단어 단위 → 형태소
전통 ML: 형태소 + bi-gram
최신 딥러닝: 서브워드 + Transformer
요약·QA: 문장 분할
신조어·오탈자 많은 도메인: 서브워드 or 형태소+커스텀 사전
원문: 광주 동명동에서 차 사고 발생, 운전자가 의식 소실 상태입니다.
① 단어 단위
[광주, 동명동에서, 차, 사고, 발생,, 운전자가, 의식, 소실, 상태입니다.]
→ 빠르지만 조사·어미 때문에 일관성이 떨어짐
② 형태소 단위
[광주/NNP, 동명동/NNP, 차/NNG, 사고/NNG, 발생/NNG, 운전자/NNG, 의식/NNG, 소실/NNG, 상태/NNG]
→ 주제·키워드 분석에 유리
③ 서브워드 단위
['광', '##주', '동', '##명', '##동', '차', '사고', '발생', '운전자', '의', '##식', '소', '##실', '상', '##태', '##입니다']
→ 신조어·오탈자에도 강력, Transformer 파인튜닝에 최적
정리하면, 토큰화는 분석 목적에 맞게 선택해야 한다는 점입니다.
전통 ML은 “형태소 + n-gram”, 최신 모델은 “서브워드”, 요약·QA는 “문장 단위”가 정석이죠.
텍스트 데이터, 그대로는 모델이 이해할 수 없습니다.
따라서 텍스트를 숫자 벡터로 바꿔야 하는데, 이 과정을 벡터화(Vectorization)라고 합니다.
벡터화 방식은 크게 전통적 표현과 분산 표현(임베딩)으로 나눌 수 있습니다.
개념: 단어 사전에 있는 단어 = 1, 없으면 = 0으로 표시
특징: 희소 행렬(거대한 0의 바다), 차원 폭발 문제가 큼
예시
- 사전: [불, 연기, 의식, 소실]
- 문장: “연기 심해요” → [0, 1, 0, 0]
언제 쓰나? 거의 안 씀, 다만 규칙 기반/소규모 태스크에 간단하게 활용 가능
개념: 단어가 몇 번 등장했는지 카운트
특징: 간단하고 빠른 베이스라인
예시
- 문장1: “불이 나요 연기가 심해요” → [불:1, 연기:1, 의식:0, 소실:0]
- 문장2: “운전자가 의식 소실 상태” → [불:0, 연기:0, 의식:1, 소실:1]
언제 쓰나? 데이터 구조를 빨리 파악할 때 TF-IDF와 비교용
개념:
- 단순 빈도에 “중요도” 가중치를 줌 특정 문서에서만 자주 나오면 ↑ 강조
- 모든 문서에서 흔하면 ↓ 패널티
특징: 길이 정규화 효과 있음, 텍스트 분류 전통 베이스라인으로 강력
예시
- “불”, “연기” 같은 긴급 단어는 중요도↑
- “그리고”, “하지만” 같은 흔한 단어는 중요도↓
언제 쓰나? 전통 ML (SVM/로지스틱/랜덤포레스트) 분류 키워드 기반 탐색, 피처 중요도 분석
개념: 단어를 해시값으로 매핑 → 고정된 차원 크기
특징: 메모리 절약, 스트리밍 데이터 처리에 유리
단점: 해시 충돌 가능 (서로 다른 단어가 같은 위치 차지)
언제 쓰나? 실시간/대규모 데이터 처리 (예: 로그 스트리밍 분석)
쉽게 말하면: 비슷한 단어와 문서를 같은 공간에 가깝게 놓아주는 방법
언제 쓰나:
- 검색 시스템: “연기 심함”이라고 검색하면, “화재 발생, 연기 확산” 같은 문서도 찾아줌
- 문서 유사도 비교: 표현은 달라도 같은 주제끼리 묶어줌
예시
- 쿼리: “연기 심함 대피 필요”
- 가까운 문서: “가스 누출 의심, 대피 안내” (단어는 다르지만 같은 주제로 인식)
쉽게 말하면: 많은 문서를 읽고, 안에 숨어 있는 “주제(topic)”를 뽑아내는 기법
언제 쓰나: 뉴스, 상담 기록 같은 방대한 문서를 자동으로 주제별로 나눌 때
예시
- 토픽 A (화재): 불, 연기, 화재, 대피
- 토픽 B (의료): 의식, 호흡, 심장, CPR
- 토픽 C (교통사고): 차량, 추돌, 차선, 구급대
- 어떤 문서는 A=0.6, B=0.3 → “화재 중심, 의료 보조 신호”
차이점 LDA: “확률” 기반, 긴 문서에 강함 NMF: 더 단순하고, 짧은 문장에도 비교적 안정적
이제는 단순히 “단어가 몇 번 나왔는지”가 아니라, 단어와 문장의 의미까지 벡터에 담아내려는 시도입니다.
Word2Vec: 주변 단어를 보고 의미를 학습
FastText: 단어를 더 작은 조각으로 쪼개서 학습 → 신조어나 오탈자에도 강함
예시
- “병원” ↔ “의원, 응급실” (비슷한 위치에 놓임)
- “불” ↔ “화재, 연기”
언제 쓰나: 딥러닝 초기 입력, 단어 의미 비교
Sentence-BERT, Ko-SBERT 같은 모델이 대표적
문장 전체를 하나의 좌표로 표현
예시
- 쿼리: “운전자가 의식을 잃었어요”
- 가까운 문장: “말을 못하고 반응이 없습니다”
→ 표현은 달라도 같은 의미라서 벡터 공간에서 가깝게 위치
언제 쓰나: 검색, 질문-답변 매칭, 중복 문장 탐지
BERT, RoBERTa 같은 모델이 대표적
같은 단어라도 문맥에 따라 다른 벡터를 줌
예시
- “은행에 갔다” → 금융기관 의미
- “강 옆의 은행” → 나무 의미
→ 표면적으로 같은 “은행”이라도 문맥에 따라 다른 벡터 생성
언제 쓰나: 정확도가 중요한 분류, QA, 추론
주제 구조 탐색/요약: LDA/NMF (+ 토픽 라벨링)
의미 유사 단어/키워드 확장: Word2Vec/FastText
검색·QA·유사 문장: Sentence-BERT / Ko-SBERT
정확도 최우선 분류: BERT/RoBERTa 파인튜닝
라벨이 순서형: 회귀+임계값 또는 CORAL
희소·고차원 완화: LSA(Truncated SVD)
텍스트 데이터를 숫자로 바꿨다면, 이제 본격적으로 분석 단계로 들어갑니다.
흐름은 보통 데이터를 살펴보기 → 모델 만들기 → 성능 평가하기 → 잘못된 부분 분석하기 → 서비스에 적용하기 순서입니다.
먼저 데이터를 직접 살펴봅니다.
길이 분포: 글이 너무 짧거나 긴 건 걸러냄
라벨 분포: 어떤 분류(라벨)에 데이터가 몰려 있는지 확인
단어·구 빈도: 어떤 표현이 자주 쓰이는지 확인 (“의식 소실”, “호흡 곤란” 등)
품사 분포: 명사/동사 비율로 데이터 성격 파악
중복·이상치: 복붙 문장, 말도 안 되게 긴 문장 제거
시각화: 단어/문장을 벡터로 바꾼 뒤 2차원에 그려서 라벨별로 잘 구분되는지 확인
목표와 상황에 맞게 모델을 고릅니다.
(1) 간단한 전통 모델 (TF-IDF → 분류기)
로지스틱 회귀: 빠르고 안정적
선형 SVM: 텍스트 분류에 강력
나이브 베이즈: 아주 빠른 베이스라인
- CNN/LSTM: 사전학습 모델 쓰기 어려울 때
- Transformer (BERT, RoBERTa 등): 최신 방식, 정확도 최우선
프롬프트 학습, LoRA 같은 경량 파인튜닝
가중치, Focal Loss, 데이터 증강(역번역, 유의어 치환)
모델이 잘 일반화되는지 확인하는 과정입니다.
데이터 분할: 학습/검증 세트 나눌 때 라벨 비율 유지
교차 검증: 여러 번 나눠 학습해서 안정적인 성능 확인
하이퍼파라미터 탐색: 학습률, 배치 크기 등을 여러 번 시도
조기 종료: 성능이 더 이상 좋아지지 않으면 학습 중단
단순 정확도만 보는 건 위험합니다.
정확도: 전체 중 맞춘 비율
Precision/Recall/F1: 특히 불균형 데이터에서 중요
- Macro F1: 클래스별 성능 평균 → 소수 클래스 중요할 때
- Micro F1: 전체 데이터 기준 → 전반 성능
혼동행렬: 어떤 라벨끼리 헷갈리는지 확인
순서형 라벨: 긴급도(하<중<상)처럼 순서가 있는 경우 QWK, Spearman, MAE 활용
지표만 보는 게 아니라 틀린 이유를 직접 살펴봅니다.
잘못 분류된 사례를 모아 유형별로 분류
- 너무 짧음, 오탈자 심함, 신조어, 언어 혼용, 라벨 정의 애매 등
라벨 가이드라인이 애매하면 수정하고 재라벨링
데이터 누수(중복, 템플릿 문장)가 없는지도 반드시 확인
모델을 실제 서비스에 적용할 때는 안정성이 더 중요합니다.
파이프라인화: 전처리 → 모델 → 후처리를 자동화
입력 검증: 빈 텍스트, 너무 긴 텍스트 걸러내기
모니터링: 성능 저하, 입력 데이터 분포 변화 감시
재현성: 시드 고정, 버전 기록, 실험 로그 관리
배포 전략: A/B 테스트나 점진적 배포로 안정성 확보
정리하면,
데이터 분석은 데이터를 이해하고
→ 모델을 고르고
→ 제대로 검증하고
→ 틀린 부분을 분석해서 보완하고
→ 서비스에 안정적으로 배포하는 과정입니다.
데이터 분석과 모델링이 끝나면, 이제는 실제 서비스와 비즈니스에 적용하는 단계입니다.
단순히 “성능이 몇 % 나왔다”로 끝나는 게 아니라,
현실 문제를 해결하는 시스템으로 녹여내는 것이 목표입니다.
설명: 들어오는 텍스트(채팅, 신고문, 댓글 등)를 실시간으로 자동 분류
예시
- 고객센터 채팅 → “배송 문의 / 환불 요청 / 불만 접수 / 칭찬” 카테고리로 자동 분류- 긴급 신고문 → “화재 / 교통사고 / 응급 의료” 등으로 실시간 태깅
효과: 상담원이 더 빠르게 대응, 우선순위 높은 사건 먼저 처리 가능
설명: 사용자 텍스트(리뷰, 피드백)를 분석해 취향이나 필요를 파악 → 맞춤형 추천 제공
예시- 리뷰에서 “향이 좋고 오래가요” → 향수/디퓨저 추천- “화면이 크고 배터리가 오래감” → 태블릿/대화면 스마트폰 추천
효과: 고객 만족도 향상, 재구매 유도
설명: 텍스트에서 부정적 감정, 혐오, 위험 신호를 조기에 잡아냄
예시- 신고문: “연기가 나고, 사람이 의식을 잃었어요” → 긴급도 상(High) 경보 발령- 리뷰: “너무 답답하고 죽고 싶다” → 자살 위험 감지, 긴급 상담 연결- SNS: “폭탄 설치했다” → 테러 위협 키워드 탐지
효과: 사회 안전, 고객 보호, 위기 대응 강화
문서 요약: 긴 보고서나 회의록을 자동 요약
질의응답(QA): 고객이 묻는 질문에 자동으로 답변
트렌드 분석: 민원/후기 데이터를 모아 사회적 이슈나 제품 불만 사항 파악
정리
분석 모델은 단순히 성능 수치로 끝나는 게 아니라,
실시간 분류로 빠른 대응을 돕고,
추천 시스템으로 개인화된 경험을 주며,
위험 감지로 안전과 위기 대응을 강화합니다.
즉, 현실 문제를 해결하는 서비스로 이어질 때 가장 큰 가치가 생깁니다.
텍스트 데이터 분석은
데이터 수집 → 전처리 → 토큰화 → 벡터화 → 모델링 → 응용이라는 긴 여정을 거칩니다.
숫자보다 훨씬 복잡하고 다루기 어려운 것이 언어지만,
바로 그만큼 가능성도 무궁무진합니다.
오늘 정리한 흐름은 텍스트 분석의 “뼈대”에 해당합니다.
실제 프로젝트에서는 이 기본기를 토대로, 도메인에 맞는 전처리와 모델을 더해 나가야 하죠.
데이터 분석은 결국 현실의 문제를 해결하는 도구입니다.
“정확도 몇 %”라는 숫자를 넘어,
사람의 삶을 더 편리하고 안전하게 만드는 것이 진짜 목적이라는 점을 잊지 않으셨으면 합니다.
앞으로는 여러분이 직접 데이터를 모으고, 작은 모델을 돌려보고,
그 결과가 서비스나 사회에 어떤 가치를 만들 수 있을지 상상해보세요.
언어를 다루는 일은 곧 사람을 이해하는 일입니다.
텍스트 데이터 분석의 여정이 여러분의 새로운 가능성을 열어주는 계기가 되기를 바랍니다.