법률 상담 게시판 통합 수집 자동화 소개 영상
문제
이 고객사는 법률사무소의 블로그 마케팅을 돕는 서비스를 운영합니다. 블로그로 잠재 의뢰인을 만나려면 사람들이 실제로 검색하고 묻는 법률 문제를 주제로 삼아야 하는데, 그 신호가 가장 진하게 모이는 곳이 법률 상담 Q&A 게시판이었습니다. 네이버 지식iN, 아하, 로톡 같은 곳에는 이혼, 형사, 부동산, 상속처럼 분야별로 일반인이 던지는 생생한 질문이 매일 쌓입니다.
문제는 이 게시판들을 사람이 직접 도는 방식이 버티지 못한다는 점이었습니다. 담당자가 매일 여러 사이트를 열어 새 질문을 훑고 어떤 주제가 자주 나오는지 눈으로 세는 일은 시간도 오래 걸리고 놓치는 것도 많았습니다. 게시판마다 글이 올라오는 속도도, 화면을 보여주는 방식도 제각각이라 한 사람의 감에 의존하는 순간 기준이 흔들렸습니다.
더 까다로운 조건은 이 게시판들이 데이터를 내주는 방식이 전부 다르다는 것이었습니다. 어떤 곳은 검색 결과가 그대로 HTML에 담겨 있고 어떤 곳은 깔끔한 REST API를 열어 두었고 어떤 곳은 목록 페이지 자체가 사라져 개별 글만 남아 있었습니다. 세 곳을 각각 다른 코드로 긁으면 유지보수가 금방 감당하기 어려워집니다. 그래서 접근 방식의 차이는 안으로 숨기고 밖에서는 하나의 흐름으로 다루는 구조가 필요했습니다.
접근
기능
접근 방식이 다른 게시판을 하나의 인터페이스로
게시판마다 데이터를 내주는 방식이 HTML, REST API, 서버 렌더링 데이터로 제각각이지만 위에서 보면 모두 "질문 목록을 돌려주는 수집기" 하나로 보이게 했습니다. 공통 인터페이스 하나에 각 게시판 수집기를 끼워 넣는 구조라, 새 게시판이 늘어도 바깥 흐름은 그대로입니다.
각 게시판은 성격에 맞는 방법으로 붙였습니다. 검색 결과가 HTML에 담긴 곳은 페이지를 읽어 필요한 조각만 파싱하고 REST API를 여는 곳은 커서 방식으로 넘겨 가며 분야별로 모으며 목록 페이지가 사라진 곳은 개별 글 페이지에 남아 있는 공개 렌더링 데이터에서 제목과 분류를 읽어 냈습니다. 방법은 달라도 결과물은 제목, 링크, 출처라는 같은 형태로 맞춰 나옵니다.
기능
목록이 사라진 게시판도 공개 데이터로 수집
목록 페이지가 없어진 곳은 개별 질문 페이지가 서버에서 미리 그려 내려보내는 공개 데이터를 활용했습니다. 최근 글 번호를 가늠해 거슬러 올라가며 유효한 질문만 모으고 빈 번호가 연달아 나오면 그 지점에서 멈춰 불필요한 요청을 만들지 않습니다.
수집한 원본 질문은 곧바로 정리 단계로 넘어갑니다. 여기서 AI가 각 질문을 읽고 블로그 정보성 글의 주제로 쓸 법한 키워드와 분야를 뽑아냅니다. 질문 하나하나를 따로 부르면 비용과 지연이 커지므로 열댓 개씩 묶어 한 번에 처리했고 분야는 미리 정한 목록 안에서만 고르게 해 결과가 흔들리지 않도록 했습니다. 같은 키워드가 다시 나오면 새로 쌓지 않고 빈도만 올려 어떤 주제가 자주 묻히는지 자연스럽게 드러나게 했습니다.
기능
AI 배치 분류로 질문을 키워드로 정리
모인 질문을 AI가 묶음 단위로 읽어 블로그 주제로 쓸 키워드와 분야, 그렇게 고른 이유를 함께 정리합니다. 광고성 표현은 걸러 내고 일반인이 검색할 법한 실용적인 주제만 남기며 같은 키워드는 빈도를 누적해 우선순위를 매깁니다.
이 전체 과정은 사람이 지켜보지 않아도 매일 새벽 스스로 돕니다. 게시판마다 요청 사이에 간격을 두어 상대 서버에 부담을 주지 않고 일시적인 오류는 간격을 늘려 가며 다시 시도합니다. 한 게시판에서 문제가 생겨도 그 게시판만 실패로 기록될 뿐 나머지 수집은 그대로 이어지고 실행마다 어디서 얼마를 모았는지 기록이 남아 나중에 확인할 수 있습니다.
기능
매일 무인으로 도는 증분 수집과 실패 격리
매일 정해진 시각에 오케스트레이터가 게시판을 차례로 돌며 새로 올라온 질문만 증분으로 모읍니다. 게시판별로 실행이 분리되어 한 곳의 장애가 전체를 멈추지 않고 실행 이력과 실패 사유가 감사 기록으로 남습니다.
전체 구조는 다음과 같습니다.
글로 요약하면 이렇습니다. 접근 방식이 다른 게시판들에서 모은 질문은 공통 수집기를 거쳐 같은 형태로 정규화되어 원본 DB에 쌓이고 AI가 묶음 단위로 읽어 키워드와 분야를 붙입니다. 같은 키워드는 빈도가 누적되어 키워드 DB에 정리되고 콘텐츠 기획은 이 키워드를 초안 주제의 출발점으로 씁니다. 전 과정은 매일 새벽 오케스트레이터가 무인으로 실행합니다.
결과
담당자가 여러 상담 게시판을 직접 돌며 어떤 질문이 자주 나오는지 눈으로 세던 일이 사라졌습니다. 매일 새벽 자동으로 수집되고 분야별로 정리된 질문 키워드가 한곳에 쌓이므로, 콘텐츠 기획은 빈 화면이 아니라 실제로 사람들이 묻는 주제 목록에서 출발합니다. 자주 반복되는 주제가 빈도로 드러나 무엇을 먼저 다룰지 판단하기도 쉬워졌습니다.
운영 관점의 변화도 큽니다. 한 게시판의 화면 구조가 바뀌거나 일시적으로 접속이 막혀도 그 게시판만 실패로 남고 나머지 수집은 이어지며 어디서 무엇이 실패했는지 기록으로 확인됩니다. 새 게시판을 붙이는 일도 공통 인터페이스에 수집기 하나를 더하는 수준이라, 수집 범위를 넓히는 데 드는 부담이 작아졌습니다.
이 프로젝트에서 다룬 기술적 결정들은 아래 글에서 더 자세히 풀었습니다.
- 법률 Q&A 크롤러 아키텍처: 접근 방식이 다른 게시판을 공통 인터페이스로 흡수한 방법
- 사라진 목록 페이지 수집하기: 목록이 없어진 사이트에서 공개 렌더링 데이터로 질문 모으기
- LLM 배치 키워드 추출: 질문을 묶음으로 분류해 비용과 지연 낮추기
- 매일 도는 증분 수집 설계: 시간 범위 필터와 조기 종료로 새 글만 모으기
- 크롤러 실패 격리와 감사 로그: 한 곳의 장애가 전체를 멈추지 않게
- 법률 마케팅 키워드 발굴: 실제 상담 질문에서 콘텐츠 주제를 찾는 이유
자주 묻는 질문
법률 게시판을 크롤링해도 되나요?
이 시스템은 누구나 볼 수 있게 공개된 질문 제목과 분류만, 사람이 열람하는 것보다 완만한 속도로 모읍니다. 게시판마다 요청 사이에 간격을 두고 로그인이 필요한 영역이나 개인정보는 다루지 않습니다. 수집한 데이터는 콘텐츠 주제를 기획하기 위한 참고 자료로만 쓰이며 원문을 그대로 옮기거나 재게시하지 않습니다.
게시판 화면이 바뀌면 수집이 멈추지 않나요?
영향은 해당 게시판 하나로 격리됩니다. 게시판별로 수집기가 분리되어 있어 한 곳의 개편이 전체 수집을 멈추지 않고 실패는 감사 기록에 바로 드러납니다. 접근 방식이 바뀐 게시판은 그 수집기만 손보면 되고 나머지는 그대로 돕니다.
수집한 질문으로 무엇을 하나요?
질문 자체를 발행하는 것이 아니라 어떤 주제가 자주 묻히는지 파악하는 데 씁니다. AI가 질문을 분야별 키워드로 정리하고 빈도를 누적하므로, 콘텐츠 담당자는 이 목록을 보고 어떤 정보성 글을 먼저 준비할지 정합니다. 실제 글은 사람이 검토하고 다듬는 초안 단계를 거칩니다.
새로운 게시판을 추가하기 어렵나요?
공통 수집기 인터페이스가 있어 새 게시판은 그 규격에 맞는 수집기 하나를 더하는 일로 끝납니다. 바깥의 정규화, AI 분류, 저장 흐름은 손대지 않아도 되므로, 수집 대상을 넓히는 작업이 매번 처음부터 만드는 일이 되지 않습니다.