리뷰 감성 분석은 많은 입문자가 가장 먼저 떠올리는 자연어 처리 프로젝트다. 사용자가 남긴 문장을 읽고 긍정인지 부정인지 판단하는 일은 얼핏 단순해 보인다. 하지만 막상 손을 대 보면 금세 알게 된다. 텍스트는 표 데이터보다 훨씬 제멋대로다. 같은 칭찬도 사람마다 표현이 다르고, 같은 불만도 돌려 말하거나 비꼬아 말할 수 있다. 그래서 이 프로젝트는 "텍스트를 숫자로 바꾸는 법"만 배우는 연습이 아니라, 사람이 남긴 말의 흔들림을 제품에서 다룰 수 있는 신호로 바꾸는 설계 연습이 된다.
이 장에서는 전자상거래 서비스의 상품 리뷰를 예로 들어 감성 분석 프로젝트를 처음부터 끝까지 설계해 본다. 단순히 긍정과 부정을 맞히는 데서 멈추지 않고, 그 결과를 요약 카드, 리뷰 필터, 모더레이션, 상담 우선순위 같은 서비스 기능으로 확장하는 흐름까지 함께 본다. 여기서 중요한 것은 모델 자체보다 질문이다. 우리는 무엇을 긍정이라고 부를 것인가, 짧은 한 줄 리뷰와 긴 불만 글을 같은 방식으로 다룰 것인가, 그리고 분류 결과를 누가 어떤 화면에서 어떻게 사용할 것인가.
왜 리뷰 감성 분석이 좋은 자연어 프로젝트인가
이 프로젝트가 좋은 이유는 텍스트 문제의 핵심 요소가 거의 다 들어 있기 때문이다. 데이터 수집, 문장 정제, 토큰화, 벡터화, 분류 모델, 임계값 조정, 해석, 운영까지 한 번에 이어진다. 게다가 결과가 사람 눈에 바로 보인다. 모델이 틀리면 왜 틀렸는지 비교적 쉽게 이해할 수 있고, 성능 개선 아이디어도 빠르게 떠오른다.
예를 들어 이런 리뷰를 보자.
"배송은 빨랐는데 배터리가 너무 빨리 닳아요."
이 문장은 긍정일까, 부정일까. 배송만 보면 칭찬이다. 제품 성능만 보면 불만이다. 전체 만족도로 보면 부정에 가까울 수 있지만, 배송 품질 분석에는 오히려 긍정 데이터가 된다. 바로 이 지점이 감성 분석의 재미이자 함정이다. 텍스트는 한 문장 안에서도 여러 신호가 섞인다. 그래서 감성 분석은 언제나 "무엇을 위한 감성 분석인가"부터 정해야 한다.
리뷰 분석 프로젝트는 특히 서비스 기능과 잘 연결된다. 상품 상세 페이지에서는 최근 감성 흐름을 보여 줄 수 있고, 고객센터에서는 강한 부정 리뷰를 빠르게 확인할 수 있으며, 운영팀은 욕설이나 공격적 표현이 포함된 글을 모더레이션 큐로 보낼 수 있다. 실제로 감성 분석 애플리케이션은 단건 분석, CSV 대량 업로드, 신뢰도 점수, 히스토리 저장, 대시보드 같은 형태로 금방 제품 기능으로 확장된다.1
먼저 문제를 한 줄로 정확히 바꾼다
"리뷰 감성 분석을 하자"는 아직 머신러닝 문제가 아니다. 적어도 다음 네 가지는 먼저 정해야 한다.
입력은 무엇인가: 리뷰 본문만 쓸 것인가, 제목과 평점을 함께 쓸 것인가
출력은 무엇인가: 긍정·부정 이진 분류인가, 긍정·중립·부정 3분류인가
단위는 무엇인가: 리뷰 전체 감성인가, 문장별 감성인가, 상품 속성별 감성인가
사용 목적은 무엇인가: 대시보드 요약인가, 리뷰 필터링인가, 자동 응답인가
예를 들어 초반 프로젝트라면 이렇게 정의하는 편이 좋다.
"상품 리뷰 텍스트를 입력받아 긍정, 중립, 부정 중 하나로 분류하고, 그 결과를 상품 페이지 요약과 운영 모니터링에 사용한다."
이 문장에는 이미 중요한 선택이 들어 있다. 리뷰 한 건이 하나의 입력 단위이고, 중립 클래스를 별도로 둔다. 또 결과를 의사결정에 쓴다는 뜻이므로 단순 정확도보다 해석 가능성과 안정성이 중요해진다.
많은 초보 팀이 여기서 욕심을 낸다. 감성, 감정, 주제, 요약, 욕설 탐지, 스팸 탐지까지 한 번에 넣고 싶어진다. 하지만 첫 버전은 가능한 한 문제를 좁게 잡는 편이 좋다. 감성 분류 하나만 제대로 설계해도 배울 것이 많다. 그 위에 기능을 하나씩 얹는 것이 더 빠르다.
라벨은 별점보다 생각보다 복잡하다
리뷰 프로젝트에서 가장 편한 라벨은 별점이다. 4점과 5점은 긍정, 1점과 2점은 부정, 3점은 중립처럼 나누면 손쉽게 대규모 학습 데이터를 만들 수 있다. 시작점으로는 꽤 괜찮다. 하지만 그대로 믿으면 곤란하다.
별점과 텍스트 감성은 종종 어긋난다. 사용자가 "제품은 좋은데 배송이 너무 늦었어요"라고 쓰고 3점을 줄 수도 있고, "그럭저럭 쓸 만함"이라고 적고 4점을 줄 수도 있다. 어떤 사람은 성격상 후한 점수를 주고, 어떤 사람은 만족해도 5점을 거의 주지 않는다. 그래서 별점은 값싼 약식 라벨이지, 완벽한 정답은 아니다.
실무에서는 보통 이렇게 접근한다. 먼저 별점을 이용해 넓은 학습 세트를 만든다. 그다음 샘플을 뽑아 사람이 직접 읽으며 라벨 품질을 점검한다. 이때 특히 많이 보는 것은 경계 사례다. 짧은 리뷰, 반어 표현, 상품은 칭찬하지만 배송은 불만인 문장, 의미 없는 반복 문장, 광고성 리뷰 같은 것들이다.
라벨 품질 점검에서 자주 발견되는 문제는 다음과 같다.
텍스트 없이 별점만 있는 경우
"굿", "별로", "추천", "환불"처럼 지나치게 짧은 경우
복합 감성이 섞여 있어 전체 라벨이 애매한 경우
번역체 문장, 이모지, 오탈자 때문에 해석이 흔들리는 경우
별점은 높지만 본문은 거의 불만이거나, 그 반대인 경우
이 단계는 귀찮아 보여도 매우 중요하다. 모델이 이상한 예측을 하는 이유의 절반은 알고리즘보다 라벨 품질에 있다. 정답이 흐리면 모델도 흐리다.
텍스트 전처리는 청소가 아니라 의미 보존 작업이다
입문자는 전처리를 "문자 다 지우고 깨끗하게 만드는 일"로 생각하기 쉽다. 하지만 리뷰 텍스트에서는 너무 과한 정제가 오히려 의미를 없애 버린다. 예를 들어 "안 좋아요"에서 조사와 어미를 마구 지우다가 부정 표현이 깨지면 감성의 방향이 바뀔 수 있다. "ㅋㅋ", "ㅠㅠ", "별로예요", "재구매는 글쎄요" 같은 표현도 겉보기에는 지저분해 보여도 감정 신호로는 강력하다.
그래서 전처리의 목표는 문장을 예쁘게 만드는 것이 아니라, 모델이 학습하기 쉬운 형태로 바꾸면서도 감성 신호는 최대한 보존하는 것이다.
리뷰 프로젝트에서 흔히 거치는 전처리 절차는 이렇다.
먼저 중복 리뷰와 비어 있는 리뷰를 제거한다. 그다음 HTML 태그, 이상한 제어 문자, 복붙 과정에서 생긴 깨진 문자를 정리한다. URL, 전화번호, 주문번호처럼 감성과 직접 관련 없는 토큰은 마스킹하거나 제거한다. 이후 토큰화를 수행하고, 필요하면 불용어 처리를 한다. 다만 불용어 사전은 기계적으로 쓰지 말고 직접 확인해야 한다. 한국어에서는 부정 표현과 연결되는 조사, 부사, 어미가 중요한 경우가 많기 때문이다.
예를 들어 "전혀", "안", "못", "너무", "진짜", "재구매", "환불" 같은 단어는 감성을 세게 흔든다. 이런 단어를 불용어로 없애면 모델이 눈이 어두워진다. 반대로 상품 코드, 길게 반복된 특수문자, 의미 없는 스팸성 패턴은 제거하는 편이 낫다.
토큰화도 목적에 따라 다르다. 전통적 모델에서는 단어 단위, 형태소 단위, 문자 n-gram이 자주 쓰인다. 오탈자가 많고 띄어쓰기가 불안한 리뷰에서는 문자 단위 조각이 의외로 잘 버티기도 한다. 딥러닝이나 사전학습 모델에서는 모델이 기대하는 토크나이저를 그대로 쓰는 경우가 많다. 이때는 사람이 직접 문장을 자르기보다, 사전학습 단계에서 쓰인 분절 방식을 따르는 편이 안정적이다.
데이터 탐색에서 먼저 확인할 것들
텍스트라고 해서 탐색이 덜 중요한 것은 아니다. 오히려 더 중요하다. 먼저 라벨 분포를 본다. 긍정 리뷰가 80%이고 부정 리뷰가 20%라면, 정확도만 높은 모델은 쉽게 만들 수 있다. 하지만 그런 모델이 실제로 부정 리뷰를 잘 잡는지는 별개다.
다음으로 리뷰 길이를 본다. 한두 단어짜리 리뷰가 많은지, 긴 서술형 리뷰가 많은지 확인해야 한다. 짧은 리뷰가 많으면 TF-IDF와 선형 모델이 놀랄 만큼 잘 작동할 수 있다. 반대로 문맥이 긴 불만 리뷰가 많다면 임베딩 기반 모델이 더 유리할 수 있다.
또 자주 등장하는 표현도 살펴봐야 한다. 긍정 리뷰에는 "만족", "좋아요", "추천", "재구매"가 많고, 부정 리뷰에는 "환불", "불량", "실망", "느림" 같은 단어가 몰릴 수 있다. 이 분석은 단순히 재미있는 워드클라우드를 만드는 데서 끝나지 않는다. 라벨 누수와 데이터 편향을 발견하는 데 도움이 된다. 예를 들어 리뷰 본문에 "별 다섯 개" 같은 표현이 많다면 모델이 실제 감성을 배우는 것이 아니라 별점 언어를 베끼는 것일 수 있다.
상품군별 차이도 꼭 봐야 한다. 화장품 리뷰의 긍정 표현과 전자제품 리뷰의 긍정 표현은 다르다. 전자제품에서는 "발열", "배터리", "속도"가 중요하지만, 의류에서는 "핏", "색감", "재질", "사이즈"가 중요하다. 이런 차이를 무시하면 전체 평균은 괜찮아 보여도 특정 카테고리에서 계속 틀리는 모델이 나온다.
TF-IDF는 여전히 강력한 출발점이다
텍스트 프로젝트를 처음 하면 많은 사람이 곧바로 BERT나 LLM을 떠올린다. 물론 강력한 도구다. 하지만 입문 프로젝트에서는 TF-IDF 같은 전통적 벡터화가 여전히 좋은 출발점이다. 이유는 세 가지다.
첫째, 빠르다. 수만 건 리뷰를 몇 분 안에 숫자 벡터로 바꾸고 바로 베이스라인을 만들 수 있다. 둘째, 해석이 쉽다. 어떤 단어가 어떤 클래스에 강하게 작용하는지 살펴보기 좋다. 셋째, 비용이 적다. CPU 환경에서도 충분히 실험할 수 있다.
TF-IDF의 직관은 간단하다. 문서 안에서 자주 나오지만 모든 문서에 흔한 단어는 덜 중요하게 보고, 특정 문서나 특정 클래스에서 상대적으로 특징적인 단어에는 더 큰 가중치를 준다. 그래서 "좋아요"처럼 흔한 단어도 어느 정도 유용하지만, "재구매", "환불", "불량", "찢어짐"처럼 특정 감성과 강하게 묶인 단어는 더 선명한 신호가 된다.
이 표현 방식은 로지스틱 회귀, 선형 SVM, 나이브 베이즈 같은 기본 분류기와 잘 맞는다. 실제로 리뷰 분류에서는 TF-IDF와 로지스틱 회귀 조합이 베이스라인으로 매우 자주 쓰인다.1
다만 한계도 분명하다. TF-IDF는 단어의 순서와 문맥을 깊게 이해하지 못한다. "좋다"와 "안 좋다"는 일부 설정에서 꽤 다르게 잡히지만, 긴 문장 속 미묘한 반전이나 반어 표현은 놓치기 쉽다. "기대 안 했는데 생각보다 괜찮네요" 같은 문장은 단순 단어 빈도만으로는 애매할 수 있다.
임베딩은 문장을 좌표로 바꾸는 방식이다
전통적 벡터화가 단어 카운트 중심이라면, 임베딩 기반 표현은 문장의 의미를 더 압축된 좌표로 바꾸려는 접근이다. 비슷한 의미의 문장은 가까운 위치로, 다른 의미의 문장은 먼 위치로 보내는 식이다.
예를 들어 "배송이 빨라서 만족해요"와 "생각보다 빨리 와서 좋았어요"는 단어가 완전히 같지 않아도 의미는 비슷하다. TF-IDF는 이런 유사성을 제한적으로만 포착하지만, 좋은 임베딩은 이 둘을 비교적 가까운 공간에 놓을 수 있다. 그래서 표현이 다양하고 문맥이 중요한 리뷰 데이터일수록 임베딩 기반 방식이 힘을 발휘한다.
임베딩에는 크게 두 길이 있다. 하나는 사전학습된 문장 임베딩이나 단어 임베딩을 뽑아 전통적 분류기 위에 얹는 방법이다. 다른 하나는 BERT류 같은 사전학습 언어 모델을 분류 작업에 맞게 미세 조정하는 방법이다. 후자는 문맥을 잘 읽고 표현력이 좋지만, 학습과 추론 비용이 더 크다. 전자는 구현이 가볍고 운영하기 쉽지만, 특정 도메인에 아주 섬세하게 맞추기는 어렵다.
최근에는 사전학습 모델과 LLM 기반 접근이 감성 분석에서 강한 성능을 보이는 경우가 많다. 특히 문맥, 다국어, 미묘한 표현, 복합 감성 처리에서 장점이 크다.23 다만 모든 프로젝트에서 무조건 이기는 것은 아니다. 짧고 반복적인 리뷰가 많고 레이블이 선명한 경우에는 전통적 모델이 비용 대비 훨씬 좋은 선택일 수 있다.
기본 분류 모델은 작지만 배울 것이 많다
베이스라인 모델로는 로지스틱 회귀가 가장 무난하다. 입력은 TF-IDF 벡터, 출력은 긍정·중립·부정 확률이다. 이 조합이 좋은 이유는 빨리 돌아가고, 계수 해석이 가능하며, 임계값 조정도 쉽기 때문이다.
예를 들어 부정 클래스에서 가중치가 높은 단어를 보면 "환불", "고장", "실망", "최악", "느림" 같은 단어가 위쪽에 뜰 수 있다. 긍정 클래스에서는 "만족", "추천", "재구매", "예쁨", "튼튼"이 보일 수 있다. 이런 결과는 운영팀과 대화하기에도 좋다. 모델이 무엇을 보고 판단하는지 대략 감을 잡을 수 있기 때문이다.
나이브 베이즈는 더 단순하지만 종종 놀랄 만큼 잘 작동한다. 특히 단어 분포가 감성에 따라 꽤 선명하게 갈릴 때는 빠른 베이스라인으로 좋다. 선형 SVM도 좋은 후보지만, 확률 해석을 바로 쓰기에는 추가 보정이 필요할 수 있다.
이 단계에서 중요한 것은 최고 성능이 아니라 정상 작동 여부다. 전처리가 맞는지, 라벨이 너무 시끄럽지 않은지, 특정 클래스가 완전히 무시되지 않는지 확인하는 것이다. 기본 모델이 전혀 의미 있는 패턴을 못 잡는다면, 더 큰 모델을 올리기 전에 데이터와 라벨을 다시 봐야 한다.
딥러닝 모델은 언제 꺼내야 할까
딥러닝 모델, 특히 BERT 계열 분류기는 리뷰 감성 분석에서 강력한 선택지다. 문맥을 더 잘 읽고, 부정 표현이나 긴 문장 안의 방향 전환도 비교적 잘 잡는다. "처음엔 실망했는데 교환 후에는 만족합니다"처럼 한 문장 안에서 감성이 움직이는 경우, 단순 bag-of-words보다 유리한 경우가 많다.
하지만 딥러닝 모델을 쓰는 이유를 막연히 "요즘은 다 이거 쓰니까"로 잡으면 곤란하다. 실제 선택 기준은 성능, 비용, 지연 시간, 해석 가능성의 균형이다.
전통적 모델과 딥러닝 모델을 비교할 때는 보통 이런 차이가 난다.
전통적 모델은 학습과 추론이 빠르고 비용이 낮으며, 어떤 단어가 영향을 주는지 설명하기 쉽다
딥러닝 모델은 문맥 이해와 일반화 능력이 좋지만, 느리고 비싸며 운영 복잡도가 커진다
사전학습 언어 모델은 적은 전처리로도 성능이 잘 나오지만, 데이터 양과 하드웨어 조건에 따라 실무 부담이 달라진다
LLM 기반 접근은 프롬프트만으로 빠르게 실험할 수 있지만, API 비용과 응답 일관성, 지연 시간 문제를 따져야 한다
최근 비교 연구에서도 전통적 머신러닝과 사전학습 LLM 기반 접근을 함께 평가하며, 작업 성격에 따라 강점이 다르다는 점을 보여 준다.2 또 LLM은 제로샷·퓨샷으로 빠르게 적용할 수 있고 문맥 이해에 강하지만, 일관된 대량 추론과 비용 관리 측면에서는 더 가벼운 분류 모델이 여전히 유리한 경우가 많다.34
한마디로 정리하면 이렇다. 리뷰가 짧고 반복적이며 대량 처리 비용이 중요하면 TF-IDF + 선형 모델이 강하다. 리뷰가 길고 표현이 다양하며 문맥 해석이 중요하면 BERT류 모델이 유리하다. 빠른 프로토타이핑이나 복합 라벨링이 필요하면 LLM을 실험해 볼 수 있다. 중요한 것은 유행이 아니라 문제의 구조다.
평가는 정확도보다 운영 목적에 맞춰야 한다
리뷰 감성 분석에서 가장 흔한 실수는 정확도만 보고 만족하는 것이다. 예를 들어 긍정 리뷰가 전체의 75%라면, 대충 긍정만 찍어도 정확도가 높게 나올 수 있다. 하지만 우리가 정말 궁금한 것은 부정 리뷰를 얼마나 잘 찾는가, 중립과 불만을 얼마나 덜 헷갈리는가, 운영에서 놓치면 안 되는 리뷰를 얼마나 잡는가다.
그래서 이 프로젝트에서는 정밀도, 재현율, F1 점수를 더 중요하게 봐야 한다. 특히 부정 리뷰를 고객 응대나 모더레이션 큐로 보내려면 재현율이 중요할 수 있다. 반대로 자동 숨김이나 강한 경고를 걸려면 정밀도가 더 중요하다.
여기서 한 가지 꼭 기억할 점이 있다. 감성 분석의 출력은 보통 확률이다. 그런데 많은 팀이 0.5를 기준으로 기계적으로 잘라 버린다. 실무에서는 그보다 "어떤 리뷰를 우선 처리할 것인가"가 더 중요하다. 예를 들어 상위 5%의 강한 부정 리뷰만 운영자가 직접 본다면, 그 상위 구간의 정밀도가 실제 KPI에 더 직접적일 수 있다.
모델 비교를 할 때는 클래스별 성능도 봐야 한다. 특히 중립 클래스는 자주 애매하다. 긍정과 부정은 강한 단서가 있지만, 중립은 정보성 문장과 짧은 사실 서술이 섞여 있어 흔들리기 쉽다. 이때는 중립을 억지로 넣기보다, 1차 버전은 이진 분류로 만들고 중립은 임계값 기반의 회색 지대로 처리하는 전략도 괜찮다.
예를 들어 긍정 확률과 부정 확률이 모두 낮고 차이도 작으면 "판단 유보" 또는 "중립 후보"로 두는 식이다. 이런 설계는 모델을 더 정직하게 만든다. 애매한 문장을 애매하다고 말할 수 있는 모델이 실무에서는 더 신뢰받는다.
잘못 분류된 리뷰를 읽는 시간이 가장 값지다
성능표를 오래 바라보는 것보다 오분류 사례 100개를 읽는 편이 더 많은 것을 알려 준다. 잘못 분류된 리뷰를 보면 데이터와 모델의 약점이 그대로 드러난다.
예를 들어 이런 유형이 자주 튀어나온다.
반어 표현: "아주 훌륭하네요, 하루 만에 고장 나서요"
복합 감성: "디자인은 예쁜데 마감이 아쉽네요"
도메인 표현: "발열은 있지만 이 가격이면 납득 가능"
맥락 의존 표현: "두 번째 구매인데 이번엔 좀 별로였어요"
짧은 문장: "쏘쏘", "그냥 그래요", "음…"
이 오분류 분석을 통해 개선 방향이 나온다. 전처리를 덜 해야 하는지, 상품 카테고리 정보를 함께 넣어야 하는지, 중립 라벨 정의를 바꿔야 하는지, 아니면 아예 속성별 감성 분석으로 문제를 쪼개야 하는지 판단할 수 있다.
특히 리뷰 감성 분석은 전체 감성 하나로 모든 것을 설명하기 어려운 경우가 많다. "배송은 좋지만 제품은 별로" 같은 문장은 상품팀과 물류팀이 서로 다르게 읽어야 한다. 그래서 프로젝트가 커지면 결국 속성 기반 감성 분석, 즉 배송·품질·가격·디자인처럼 항목별로 감성을 나누는 방향으로 확장되기 쉽다. 하지만 첫 버전에서는 전체 감성 분류부터 안정적으로 만드는 편이 좋다.
감성 점수는 분류 결과가 아니라 기능의 재료다
이 장에서 가장 중요한 대목은 여기다. 감성 분석의 가치는 "이 리뷰는 부정입니다"라는 한 줄 예측 그 자체에 있지 않다. 그 결과를 어떤 기능으로 번역하느냐에 있다.
가장 쉬운 확장은 상품 페이지 요약이다. 특정 상품의 최근 30일 리뷰를 모아 긍정 비율, 부정 비율, 자주 언급된 키워드, 대표 불만 문장을 보여 줄 수 있다. 사용자는 리뷰 수백 개를 다 읽지 않아도 대략적인 분위기를 이해할 수 있다.
다음은 필터링 기능이다. 사용자가 "부정 리뷰만 보기", "배송 관련 불만만 보기", "최근 한 달의 긍정 리뷰 보기"처럼 걸러 볼 수 있다. 이 기능은 검색 경험을 크게 개선한다. 감성 분류가 정확할수록 사용자는 자신의 관심사에 맞는 리뷰를 더 빨리 찾는다.
또 하나는 모더레이션이다. 강한 부정 감성, 욕설, 공격적 표현, 혐오 표현, 광고성 반복 문장을 함께 탐지하면 운영팀의 검수 우선순위를 만들 수 있다. 여기서는 감성만으로 충분하지 않다. 하지만 감성 점수는 위험도 계산의 좋은 재료가 된다.
고객 지원으로도 이어질 수 있다. 예를 들어 부정 확률이 높고 신뢰도도 높으며, 주문 후 3일 안에 작성된 리뷰라면 빠른 대응 후보로 보낼 수 있다. 반대로 긍정 리뷰는 마케팅 활용 동의를 받아 후기 카드나 추천 문구 후보로 연결할 수 있다.
실제 제품형 감성 분석 서비스는 단건 분석, 대량 CSV 업로드, 모델별 비교, 신뢰도 점수, 분석 히스토리, 대시보드 차트, 키워드 하이라이트 같은 기능으로 확장되곤 한다.1 이 흐름을 보면 감성 분석은 알고리즘 데모가 아니라 운영 도구라는 점이 선명해진다.
배포를 생각하면 모델보다 인터페이스가 더 중요해진다
노트북에서 잘 돌아가는 감성 모델과 서비스에서 쓰는 감성 기능은 다르다. 제품 안에서는 예측 결과만 필요한 것이 아니다. 입력 검증, 응답 시간, 실패 처리, 버전 관리, 재분석, 히스토리 저장이 함께 필요하다.
예를 들어 가장 단순한 API는 이렇다. 입력으로 리뷰 텍스트를 받는다. 출력으로 감성 라벨, 확률, 사용한 모델 버전, 처리 시각을 돌려준다. 여기에 여유가 있으면 감정 라벨, 핵심 키워드, 하이라이트 구간도 붙일 수 있다. 실제 구현 사례에서도 감성 라벨뿐 아니라 confidence score, emotion detection, highlighted text, 일괄 분석, 기록 저장 같은 구성이 함께 등장한다.1
이 구조를 제품 관점에서 보면 세 가지 계층으로 나뉜다.
분석 계층: 텍스트를 받아 예측하는 모델 서비스
애플리케이션 계층: 인증, 기록 저장, 상품 연결, 배치 요청 처리
사용자 계층: 대시보드, 리뷰 목록, 필터, 분석 결과 화면
이렇게 나누면 모델을 바꾸더라도 화면과 운영 로직을 덜 흔들 수 있다. 오늘은 TF-IDF 로지스틱 회귀를 쓰다가 내일 BERT로 바꿔도, API 계약만 잘 지키면 프론트엔드와 관리자 화면은 그대로 갈 수 있다.
LLM은 언제 감성 분석에 써야 할까
생성형 AI 시대에는 "그냥 LLM으로 다 하면 되는 것 아닌가?"라는 질문이 자연스럽다. 실제로 LLM은 감성 분석에서 꽤 매력적이다. 프롬프트만으로 제로샷 분류를 시도할 수 있고, 긍정·부정·중립뿐 아니라 감정 종류, 이유 요약, 개선 포인트까지 한 번에 뽑을 수 있다.34
예를 들어 이런 식의 확장이 가능하다. 단순 감성 라벨 외에 "왜 부정인지 한 문장으로 요약", "배송/품질/가격 중 어느 속성의 불만인지", "운영자에게 즉시 전달이 필요한지"까지 함께 생성하게 할 수 있다. 이건 전통적 분류기보다 훨씬 풍부한 출력이다.
하지만 LLM을 곧바로 운영 핵심 경로에 넣을 때는 주의가 필요하다. 첫째, 비용이 크다. 리뷰 수가 많아질수록 단가가 민감해진다. 둘째, 지연 시간이 길 수 있다. 상품 페이지에서 실시간 응답이 필요하면 부담이 된다. 셋째, 출력 형식이 흔들릴 수 있다. 정해진 JSON 형식으로 늘 깨끗하게 나오도록 제어해야 한다. 넷째, 같은 리뷰에 대한 판정 일관성이 중요할 때는 가벼운 분류 모델이 더 다루기 쉽다.
그래서 현실적인 전략은 종종 하이브리드다. 대량의 일반 리뷰는 가벼운 분류 모델로 처리하고, 애매한 리뷰나 VIP 고객 불만, 긴 서술형 리뷰만 LLM으로 재분석하는 방식이다. 이렇게 하면 비용과 성능을 모두 챙길 수 있다.
이 프로젝트에서 초보자가 자주 하는 실수
리뷰 감성 분석은 친숙해 보여서 오히려 실수가 잦다.
첫 번째 실수는 전처리를 너무 세게 하는 것이다. 감정 표현, 이모지, 부정 부사까지 싹 지우면 모델이 배울 단서가 사라진다. 두 번째는 별점을 무조건 정답으로 믿는 것이다. 별점은 편리하지만 noisy label일 가능성이 크다. 세 번째는 정확도만 보는 것이다. 클래스 불균형과 중립 클래스 문제를 함께 봐야 한다. 네 번째는 모델 성능만 보고 서비스 기능 설계를 미루는 것이다. 감성 분석은 분류 그 자체보다 결과를 어디에 쓸지가 더 중요하다.
또 하나 흔한 실수는 해석 없이 점수만 보여 주는 것이다. 운영팀은 "이 리뷰는 부정 0.91입니다"만으로는 행동하기 어렵다. 왜 부정인지, 어떤 키워드가 강하게 작용했는지, 어느 상품군에서 비슷한 패턴이 반복되는지 함께 보여 줘야 한다.
한 번에 정리하는 리뷰 감성 분석 프로젝트의 흐름
이 장의 흐름을 다시 묶어 보자. 먼저 비즈니스 목적을 정한다. 상품 리뷰를 감성별로 분류해 요약, 필터링, 모더레이션, 고객 대응에 활용하는 것이 목표다. 다음으로 리뷰 단위와 출력 클래스를 정하고, 별점 기반 약식 라벨과 수동 검수 샘플을 조합해 데이터셋을 만든다.
그다음 텍스트를 정제하되 감성 신호는 보존한다. 토큰화와 불용어 처리도 기계적으로 하지 말고 도메인에 맞게 조정한다. 이후 TF-IDF로 빠른 베이스라인을 만든다. 로지스틱 회귀나 나이브 베이즈로 기본 성능과 데이터 품질을 점검한다. 그다음 필요하면 임베딩 기반 표현과 BERT류 분류기로 확장해 문맥 이해 성능을 높인다.
평가 단계에서는 정확도보다 클래스별 정밀도, 재현율, F1을 보고, 운영 목적에 따라 임계값을 조정한다. 이후 오분류 리뷰를 읽으며 라벨 정의와 전처리, 모델 구조를 개선한다. 마지막으로 결과를 요약 카드, 감성 필터, 운영 큐, 고객 대응 플로우로 연결한다. 여기까지 가야 비로소 감성 분석이 "데모"에서 "제품 기능"으로 바뀐다.
이 장의 핵심
리뷰 감성 분석은 자연어 처리 입문 프로젝트이지만, 본질은 단순 분류가 아니다. 사람의 말을 서비스에서 쓸 수 있는 신호로 바꾸는 설계 문제다. 그래서 좋은 프로젝트는 텍스트를 벡터로 바꾸는 데서 끝나지 않는다. 라벨이 믿을 만한지, 전처리가 의미를 지우지 않았는지, 전통적 벡터화와 임베딩 중 무엇이 현재 목적에 맞는지, 그리고 그 결과를 어떤 화면과 운영 흐름에 연결할지까지 함께 생각해야 한다.
처음에는 TF-IDF와 로지스틱 회귀만으로도 충분히 좋은 출발을 할 수 있다. 그 위에 필요할 때 임베딩, BERT, LLM을 얹으면 된다. 중요한 것은 더 복잡한 모델이 아니라 더 명확한 문제 정의와 더 나은 기능 설계다. 리뷰 한 줄에서 시작한 감성 점수가 결국 상품 페이지를 바꾸고, 운영 우선순위를 정하고, 고객 경험을 개선하는 순간, 머신러닝은 비로소 제품이 된다.
참고
1GitHub - Vanshika-Agrawal65/sentiment-analysis-project
2Sentiment Analysis of Product Reviews Using Machine Learning and Pre-Trained LLM
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.