프로젝트를 작업할 적에 상품명과 상세설명에서 핵심 키워드만 남기고 싶어서 불용어 제거를 먼저 적용했습니다. 그런데 실제로 돌려보니 잡음은 그대로 남고, 반대로 꼭 남아야 할 단어까지 같이 사라져 결과가 생각보다 좋지 않았습니다. 그래서 불용어를 무작정 지우는 방식에서 벗어나, 중요한 단어를 따로 보호하고 텍스트 정리 순서를 바꾸는 방식으로 수정했고, 그제야 쓸 만한 결과가 나왔습니다.
불용어 제거만으로는 해결되지 않았던 이유
처음에는 불용어 목록만 잘 만들면 텍스트가 자연스럽게 정리될 것이라고 생각했습니다. 자주 등장하지만 의미가 약한 단어를 빼면 상품명과 상세설명에서도 핵심 키워드만 남을 것 같았기 때문입니다. 하지만 실제 데이터는 그렇게 단순하지 않았습니다. 문장 안에는 조사, 특수문자, 눈에 잘 띄지 않는 유니코드 문자, 숫자와 단위 표현이 함께 섞여 있었고, 이 상태에서 불용어만 제거하면 결과가 생각보다 깔끔해지지 않았습니다. 어떤 행은 쓸모없는 표현이 남아 있었고, 또 어떤 행은 꼭 남아야 할 브랜드명이나 제품 성격을 보여주는 단어까지 함께 빠졌습니다. 문제는 불용어 목록의 양이 아니라, 처리 기준 자체였습니다.
특히 가장 불편했던 부분은 결과가 일정하지 않다는 점이었습니다. 같은 방식으로 처리했는데도 어떤 데이터는 괜찮고, 어떤 데이터는 핵심 단어가 지나치게 줄어들었습니다. 결국 텍스트를 바로 단어로 나누기 전에 먼저 정리하는 단계가 필요했습니다. 소문자 통일, 유니코드 제거, 조사 정리, 숫자와 단위 제거, 특수문자 제거 같은 전처리가 먼저 이뤄져야 불용어 제거가 제대로 작동할 수 있었습니다. 이걸 직접 겪고 나서야, 처음 결과가 왜 이상했는지 납득이 됐습니다. 불용어 제거는 한 줄로 끝나는 작업처럼 보이지만, 실제로는 앞단의 정리 과정이 받쳐줘야 결과가 안정됩니다.
중요한 단어를 보호하도록 바꾸니 결과가 달라졌습니다
가장 크게 바꾼 부분은 화이트리스트를 따로 둔 점입니다. 처음에는 불용어만 관리했는데, 이렇게 하면 지우면 안 되는 단어를 통제하기가 어려웠습니다. 그래서 중요한 단어는 별도로 보호하는 방식으로 바꿨습니다. 텍스트 전체가 화이트리스트와 완전히 일치하면 그대로 두고, 문장 안에 포함된 중요한 단어는 먼저 따로 보관한 뒤 나머지 정리를 진행하도록 수정했습니다. 이렇게 하니 불필요한 단어를 줄이면서도 핵심 키워드는 유지할 수 있었습니다. 덕분에 결과물이 보기 좋아지는 수준을 넘어, 이후 분류나 집계에 바로 쓸 수 있는 형태로 바뀌었습니다. 실제 코드 흐름도 불용어 파일과 화이트리스트 파일을 분리해 불러오고, 보호 단어를 따로 관리하는 구조로 작성되어 있습니다.
여기에 중복 제거까지 같이 넣으니 결과가 더 안정됐습니다. 상품명과 상세설명에는 같은 의미의 단어가 반복해서 들어가는 경우가 많습니다. 이때 불용어만 제거하면 문장은 짧아져도 키워드 목록은 여전히 산만할 수 있습니다. 그래서 이미 한 번 나온 단어는 다시 넣지 않도록 정리했습니다. 이 수정 하나로 결과가 꽤 달라졌습니다. 실제 실행 결과에서도 불용어 14,772개와 화이트리스트 66개를 불러와 300개 행을 처리하고, 최종적으로 키워드 결과를 저장했습니다.
불용어 제거는 많이 지우는 일이 아니라 기준을 잡는 일입니다
이번 작업을 하면서 느낀 점은 불용어 제거가 생각보다 훨씬 섬세한 작업이라는 점입니다. 처음에는 필요 없는 단어를 많이 지우면 해결될 줄 알았지만, 실제로는 무엇을 지울지보다 무엇을 남길지를 먼저 정해야 했습니다. 중요한 단어를 보호하지 않으면, 결과는 짧아져도 정작 쓸 수가 없습니다. 그래서 불용어 사전만 손보는 방식에서 벗어나, 화이트리스트를 따로 두고 텍스트 정리 순서까지 다시 잡는 방향으로 바꿨습니다. 그 뒤에야 결과가 일정해졌고, 다음 작업으로도 이어가기 쉬운 형태가 됐습니다.
불용어 제거를 시도했는데 결과가 깔끔하지 않거나, 중요한 키워드가 같이 사라져서 고민한 경험이 있다면 삭제 규칙만 늘리기보다 보호 기준과 처리 순서를 먼저 점검하는 것이 좋습니다. 저 역시 그 방향으로 수정한 뒤에야 원하는 결과를 얻을 수 있었습니다. 불용어 제거는 전처리의 첫 단계처럼 보이지만, 여기서 기준을 잘못 잡으면 뒤의 작업이 전부 흔들립니다. 완벽한 정답보다 문제를 확인하고 기준을 수정하는 과정이 결국 더 중요한 이유입니다.