리뷰가 흩어져 있다는 것은 구체적으로 무엇을 의미하는가

같은 제품에 대한 고객의 발화라도 자사몰 리뷰, 쿠팡·네이버쇼핑 같은 오픈마켓 리뷰, 앱스토어·구글플레이 리뷰, 인스타그램·블로그 후기, 커뮤니티 게시글까지 채널마다 형식과 접근 방법이 전혀 다릅니다. 자사몰 리뷰는 관리자 페이지에서 직접 다운로드할 수 있는 경우가 많지만, 오픈마켓 리뷰는 판매자센터의 다운로드 기능이나 API를 거쳐야 하고, 커뮤니티 게시글은 대부분 공식 API가 없어 별도 수집 방식이 필요합니다. 이 채널별 차이를 무시하고 "리뷰 수집"을 하나의 작업으로 뭉뚱그리면, 실제 착수 단계에서 채널마다 새로 방법을 찾느라 일정이 계속 밀립니다.

자체 파이썬 크롤러는 언제 유리한가

자사몰처럼 구조가 고정돼 있고 수집 대상이 명확한 채널은 파이썬 크롤러(requests·BeautifulSoup, 또는 동적 페이지라면 Selenium·Playwright 계열)로 직접 구축하는 편이 유연합니다. 원하는 필드(평점, 작성일, 옵션명, 원문 전체)를 정확히 원하는 형태로 뽑아낼 수 있고, 수집 주기를 자체 서버 스케줄러로 원하는 대로 조정할 수 있습니다.

다만 이 유연성에는 대가가 따릅니다. 대상 사이트가 페이지 구조를 바꾸면 크롤러가 즉시 깨지고, 로그인이 필요한 페이지나 봇 차단이 걸린 페이지는 우회 로직을 계속 손봐야 합니다. 채널이 3~4개를 넘어가는 순간부터는 크롤러 유지보수 자체가 별도 인력을 필요로 하는 작업이 됩니다.

전문 솔루션은 언제 자체 크롤러보다 나은가

SNS·커뮤니티처럼 이미 대규모로 흩어진 비정형 텍스트를 다뤄야 한다면, 처음부터 직접 크롤러를 짜기보다 이미 수집 인프라를 구축해둔 전문 솔루션을 쓰는 편이 착수 속도 면에서 유리합니다. 예를 들어 썸트렌드(Sometrend)는 트위터(X)·블로그·인스타그램·뉴스뿐 아니라 뽐뿌·네이트판·중고나라 등 커뮤니티 게시판까지 이미 대규모로 수집해두고, 특정 키워드에 대한 언급을 전날 기준까지 조회할 수 있게 해줍니다. 자사 브랜드명이나 제품명을 키워드로 등록해두면, 별도 크롤러 없이도 SNS·커뮤니티 반응을 지속적으로 추적할 수 있습니다.

자사몰·CS처럼 내부 데이터베이스에 있는 정형 데이터까지 이런 솔루션이 대신 모아주지는 않는다는 점은 감안해야 합니다. 결국 실무에서는 SNS·커뮤니티는 전문 솔루션으로, 자사몰·CS는 자체 익스포트나 경량 크롤러로 이원화하는 조합이 현실적인 경우가 많습니다.

크롤링을 시작하기 전에 반드시 확인할 것

어떤 방식을 택하든 수집을 시작하기 전에 대상 플랫폼의 이용약관과 robots.txt를 먼저 확인해야 합니다. 자동화된 수집을 명시적으로 금지하는 플랫폼도 있고, API를 공식 제공하는 경우 그 API의 호출 한도·이용 조건을 따르는 것이 크롤링보다 우선입니다. 이 확인을 생략하고 무단으로 대량 수집을 하면 계정 차단이나 법적 분쟁으로 이어질 수 있어, 인프라를 설계하는 초기 단계에서 반드시 짚고 넘어가야 하는 절차입니다.

수집한 데이터는 어떤 형태로 저장해야 다음 단계에서 쓸 수 있는가

채널마다 원본 형식이 다르더라도, 저장할 때는 채널명·작성일·평점(있는 경우)·원문 텍스트를 공통 필드로 갖는 표준 스키마로 통일해야 합니다. 이 표준화를 건너뛰고 채널별로 제각각 저장하면, 다음 편에서 다룰 형태소 분석·감성 분석 단계에서 채널마다 전처리 코드를 새로 짜야 하는 비효율이 발생합니다. 표준 스키마는 이후 텍스트 마이닝 파이프라인 전체의 기초가 되므로, 수집 단계에서부터 설계해두는 편이 전체 작업 시간을 줄여줍니다.

모든 채널을 한 번에 수집하려는 시도는 왜 실패하는가

처음 VOC 인프라를 구축할 때 흔히 저지르는 실수는 존재하는 모든 채널을 동시에 수집 대상으로 삼는 것입니다. 자사몰, 오픈마켓 서너 곳, 앱스토어 양쪽, SNS 여러 개, 커뮤니티까지 한 번에 파이프라인을 만들려고 하면 채널별 예외 처리에 시간이 분산되어 어느 채널도 제대로 마무리되지 않는 상태로 몇 주가 지나가는 경우가 많습니다.

실무에서는 리뷰 절대량이 가장 많은 채널 한두 개(대개 자사몰과 주력 오픈마켓)부터 표준 스키마로 먼저 완성하고, 그 파이프라인이 안정적으로 돌아가는 것을 확인한 뒤 다음 채널을 순차적으로 붙여나가는 방식이 훨씬 안정적입니다. 채널을 늘릴 때마다 기존 표준 스키마에 맞춰 새 채널의 필드를 매핑하는 작업만 반복하면 되므로, 처음 한 채널을 제대로 설계해두는 것이 이후 확장 속도를 결정합니다. 이 단계에서 욕심을 부려 전 채널을 동시에 붙이려다가 파이프라인 자체가 지연되는 것보다, 채널 하나를 완성해 실제로 다음 단계(형태소 분석·감성 분석)까지 데이터를 흘려보내 보고 그 결과가 쓸모 있는지 먼저 검증하는 편이 조직 전체의 신뢰를 얻는 데도 유리합니다.