MediaCrawler 오픈소스 도구: 공개 콘텐츠 수집 가이드

로그인 상태와 브라우저 프로세스가 자꾸 끊기고, 수집 범위를 어디까지 허용해야 할지 판단하기 어렵다면 설치보다 사용 목적 확인이 먼저입니다. 가장 빠른 해법은 MediaCrawler 오픈소스 도구를 학습·연구용 공개 콘텐츠 수집에 한정하고, 프로젝트 고지와 대상 플랫폼 규칙을 확인한 뒤 작은 범위로 시험하는 것입니다.

2026년 8월 13일 기준으로 MediaCrawler는 Playwright와 저장된 로그인 상태를 활용해 여러 플랫폼의 공개 콘텐츠를 수집하는 프로젝트입니다. 다만 무조건적인 상업용 대량 수집 서비스가 아니며, 공식 저장소와 사용 고지, 대상 플랫폼 약관, 거주 지역의 법률을 함께 확인해야 합니다. 프로젝트의 사용 고지만으로 법적 허용 여부가 결정되지는 않습니다.

이 글은 Playwright와 다중 플랫폼 수집 구조를 배우려는 개발자, 연구형 데이터 파이프라인을 준비하는 데이터 엔지니어, 브라우저 자동화 환경을 장기간 운영할 기술 책임자에게 적합합니다. 단순히 기능 목록만 찾는 독자라면 공식 문서부터 확인하는 편이 빠릅니다.

주의: 공개되어 보이는 콘텐츠라도 자동 수집, 저장, 재가공, 상업적 이용이 모두 같은 권리를 의미하지는 않습니다. 수집 전에 목적, 필드, 보관 기간을 문서로 남기십시오.

마지막 업데이트: 2026년 8월 13일. 데이터는 같은 날 확인한 공식 저장소, 프로젝트 문서, 라이선스와 Playwright 문서를 기준으로 검토했습니다.

설치 전에 확인할 사용 목적과 합법적 범위

MediaCrawler를 설치하기 전에 가장 먼저 확인할 것은 “수집할 수 있는가”가 아니라 “수집해도 되는가”입니다. 공식 저장소는 학습과 연구 목적을 강조하고, 상업적 이용이나 플랫폼 운영을 방해하는 대규모 수집을 제한하는 내용을 포함합니다. 별도의 상업 계약이나 서면 허가가 없다면 기업 업무의 핵심 데이터 공급망으로 바로 편입하지 않는 편이 안전합니다. (프로젝트 라이선스)

다음 세 가지 제한을 먼저 점검하십시오.

• 권한 제한: 로그인 계정, 쿠키, 원격 디버깅 연결은 모두 계정 접근 권한과 연결됩니다. 여러 사람이 같은 상태를 공유하면 책임 추적이 어려워집니다.
• 운영 제한: 브라우저 자동화는 단순한 요청 반복보다 자원 사용량과 세션 의존성이 큽니다. 브라우저가 멈추거나 로그인 상태가 만료되면 작업도 중단될 수 있습니다.
• 데이터 제한: 공개 콘텐츠라도 작성자 식별 정보, 댓글, 이미지와 영상 주소를 필요 이상으로 저장하면 보관·삭제·접근 통제가 복잡해집니다.

수집 목적을 “특정 키워드의 연구용 표본 확인”처럼 좁히고, 대상 기간과 필드를 먼저 정하십시오. 댓글 전체, 창작자 전체 이력, 영상 원본처럼 범위가 커지는 항목은 별도 검토 대상으로 분리하는 것이 좋습니다.

첫 단계: Python, Node.js와 브라우저 환경 구성

공식 문서는 uv를 이용한 의존성 관리를 권장하며, Python은 3.11을 기준으로 안내합니다. 일부 플랫폼에는 Node.js가 필요하고, 공식 문서에는 Node.js 16 이상이 제시되어 있습니다. 표준 Playwright 방식에서는 브라우저 드라이버 설치가 필요하지만, 기존 Chrome에 CDP로 연결하는 방식에서는 설치 구성이 달라질 수 있습니다. (공식 설치 문서)

Playwright는 버전에 맞는 브라우저 바이너리를 사용하므로 라이브러리만 업데이트하고 브라우저 설치를 다시 하지 않으면 실행 오류가 생길 수 있습니다. 공식 문서도 Playwright 업데이트 뒤 브라우저 설치 상태를 함께 점검하도록 안내합니다. (Playwright 브라우저 관리 문서)

기본 설치 흐름은 다음과 같습니다.

1. Python 환경을 준비하고 프로젝트 저장소를 내려받습니다.
2. uv --version으로 패키지 관리 도구가 실행되는지 확인합니다.
3. uv sync로 Python 의존성을 동기화합니다.
4. 표준 Playwright 방식을 사용할 경우 uv run playwright install을 실행합니다.
5. Node.js가 필요한 대상 플랫폼이라면 설치 상태와 버전을 확인합니다.
6. 처음에는 하나의 플랫폼, 하나의 키워드, 최소 필드만 선택해 시험합니다.

설치 과정에서 실패하면 먼저 Python 버전, Node.js 의존성, 브라우저 바이너리, 운영체제 권한을 분리해 확인하십시오. 한 번에 여러 요소를 바꾸면 어느 단계에서 문제가 생겼는지 추적하기 어렵습니다.

지원 플랫폼과 다중 수집 방식의 범위

공식 저장소는 샤오홍슈, 더우인, 콰이쇼우, 비리비리, 웨이보, 티에바, 즈후를 지원 플랫폼으로 제시합니다. 플랫폼별로 키워드 검색, 지정 콘텐츠, 댓글, 창작자 페이지, 로그인 상태 캐시 등의 기능 표시가 제공되지만, 실제 동작 여부는 코드 변경과 대상 플랫폼의 화면·정책 변화에 따라 달라질 수 있습니다. 따라서 “지원”이라는 표현을 운영 성공률이나 장기 안정성 보장으로 해석하면 안 됩니다. (MediaCrawler 지원 플랫폼 안내)

MediaCrawler의 핵심은 일반적인 정적 요청 수집기가 아니라 브라우저 자동화에 가깝다는 점입니다. 프로젝트 문서는 Playwright를 통해 브라우저를 제어하고, 로그인 상태가 유지된 브라우저 문맥을 활용하는 구조를 설명합니다. Playwright 자체도 Python에서 동기·비동기 브라우저 자동화를 지원합니다.

로그인 상태 생성과 원격 접근 통제

MediaCrawler는 플랫폼과 실행 방식에 따라 로그인 상태가 필요할 수 있습니다. 공식 실행 예시는 QR 코드 로그인 옵션을 사용하며, 현재 저장소는 기존 Chrome을 CDP로 연결하거나 표준 Playwright 방식으로 전환하는 구성을 안내합니다. 따라서 “항상 로그인 없이 실행된다”고 보면 안 됩니다.

실행 순서는 다음처럼 잡는 것이 안전합니다.

1. 전용 테스트 계정 또는 허가된 계정을 준비합니다.
2. 로컬에서 브라우저를 열고 대상 플랫폼에 정상 로그인합니다.
3. QR 코드 등 공식 로그인 절차를 사용해 세션을 만듭니다.
4. 한 건의 지정 콘텐츠로 로그인 상태가 유지되는지 확인합니다.
5. 세션 파일과 쿠키가 저장되는 경로를 찾아 접근 권한을 제한합니다.
6. 검색이나 창작자 페이지처럼 범위를 넓히기 전에 로그와 결과를 검토합니다.
7. 세션 만료나 계정 이상이 발생하면 자동 재로그인을 반복하지 말고 작업을 멈춥니다.

CDP 방식을 사용할 때 공식 저장소는 원격 디버깅 주소와 연결되는 Chrome 구성을 설명합니다. 원격 디버깅 포트를 인터넷에 직접 노출하면 계정 세션을 탈취당할 위험이 커지므로 방화벽, 로컬 바인딩, 개인 터널, 접근 제어를 함께 사용해야 합니다. CDP는 브라우저를 제어하는 통로이지 인증 보안 기능이 아닙니다.

운영 경험: 원격 서버에 로그인 상태를 복사할 때는 쿠키 파일만 옮기지 말고, 누가 언제 복사했는지와 언제 폐기할지를 기록하십시오. 공유 계정 하나로 여러 작업을 실행하면 계정 이상 발생 시 원인을 특정하기 어렵습니다.

로그인 상태를 활용하면 편리하지만, 그만큼 민감한 자산이 늘어납니다. 쿠키, 브라우저 프로필, QR 로그인 세션, CDP 연결 정보, 작업 로그에 남은 주소를 비밀값으로 취급하십시오. 원격 브라우저 작업의 접근 권한과 관리 절차가 정리되지 않았다면 조직의 보안 정책과 함께 kvmboot 환경 안내를 확인한 뒤 구성 범위를 정하십시오.

저장 형식과 WebUI 미리보기 구성

현재 공식 저장소는 CSV, JSON, JSONL, Excel, SQLite, MySQL 저장을 지원한다고 안내합니다. 개인 연구나 짧은 검증에는 SQLite가 관리하기 쉽고, 후속 분석 도구와 연결해야 한다면 JSONL이나 CSV가 편리할 수 있습니다. 여러 작업자가 조회하거나 장기 파이프라인으로 연결할 때는 MySQL 같은 서버형 데이터베이스를 검토할 수 있지만, 데이터베이스를 사용한다고 해서 보관 책임이 사라지는 것은 아닙니다.

WebUI를 사용할 경우 공식 저장소는 플랫폼, 로그인 방식, 수집 유형을 시각적으로 설정하고 실행 상태와 로그를 확인하며 데이터를 미리 보고 내보낼 수 있다고 설명합니다. 개발 실행에서는 API 서버와 Vite 개발 서버가 각각 사용되므로, 원격 환경에서는 관리 화면을 외부에 바로 공개하지 않는 편이 좋습니다.

저장 전에 필드 목록을 먼저 줄이십시오. 작성자 식별자, 프로필 주소, 댓글 원문, 미디어 주소가 모두 필요한지 검토하고, 필요하지 않은 필드는 처음부터 저장하지 않는 방식이 가장 확실합니다. 로그에는 쿠키, 토큰, 전체 게시물 주소와 개인 식별 정보를 남기지 않아야 합니다.

장기 실행 환경과 중단 기준

MediaCrawler를 원격 서버에 배포하는 것은 기술적으로 가능하지만, 프로그램을 서버에 복사하면 끝나는 작업은 아닙니다. 브라우저 프로세스, 로그인 세션, 네트워크 상태, 저장 공간, 중단 복구를 함께 관리해야 합니다.

장기 실행 전에는 다음 조건을 확인하십시오.

• 브라우저 프로세스가 비정상 종료될 때 작업을 중단하거나 수동 검토로 전환합니다.
• 네트워크가 끊겼을 때 같은 항목을 무한 재시도하지 않도록 재시도 범위를 제한합니다.
• 세션 만료를 감지하면 새 로그인 시도를 자동 반복하지 않습니다.
• 저장 파일과 데이터베이스의 접근 계정을 작업자별로 분리합니다.
• WebUI와 API 관리 포트를 공용 인터넷에 노출하지 않습니다.
• 작업별 수집 범위, 시작 시각, 종료 시각, 결과 저장 위치를 기록합니다.
• 보관 기간이 끝난 원본과 로그를 삭제하고, 백업에도 같은 삭제 정책을 적용합니다.

특히 플랫폼 규칙이 바뀌거나, 계정에 이상 활동 알림이 오거나, 프로젝트의 라이선스와 사용 고지가 변경되면 즉시 중단해야 합니다. 이후에는 수집 범위를 축소하거나 공식 인터페이스, 허가된 데이터 제공 방식으로 전환하는 것이 우선입니다. 제한을 피하는 방법이나 인증·검증 절차를 우회하는 방법을 추가하는 것은 이 도구의 안전한 운영 범위를 벗어납니다.

원격 브라우저 작업을 별도 환경에서 운영해야 한다면 조직의 계정 정책, 네트워크 접근 규칙, 데이터 삭제 절차를 먼저 정리하십시오. 필요한 환경의 범위와 운영 기간이 확정되지 않은 상태에서 장기 서버를 먼저 계약하면, 사용하지 않는 브라우저 프로세스와 과도한 접근 권한만 남을 수 있습니다. 원격 관리 화면과 브라우저 세션을 외부에 공개하지 않도록 방화벽, 접근 제어, 계정별 권한을 먼저 설정하는 것이 안전합니다. 동일한 원격 환경을 검토할 때는 kvmboot 환경 안내에서 제공 범위를 확인하되, 실제 배포 전에는 조직의 보안 정책과 데이터 처리 기준을 별도로 검토해야 합니다.

선택하지 않는 편이 나은 상황

다음 조건이라면 MediaCrawler를 장기 핵심 수집 시스템으로 선택하지 않는 편이 낫습니다.

• 상업 서비스에 사용할 데이터 공급이 필요하지만 프로젝트 라이선스와 별도 허가를 확인하지 않은 경우
• 플랫폼의 공식 API나 허가된 데이터 제공 경로가 존재하는 경우
• 높은 안정성, 명확한 서비스 수준, 중단 없는 수집이 필요한 경우
• 여러 계정과 대규모 범위를 운영해야 하는 경우
• 원본 콘텐츠와 개인정보를 장기간 보관해야 하는 경우
• 물리적 브라우저 화면 확인과 계정 소유자 승인이 필요한 경우

반대로 Playwright 학습, 공개 페이지 구조 분석, 제한된 연구 표본 수집, 데이터 저장 파이프라인 실험이라면 적합성을 검토할 수 있습니다. 단, 적합하다는 뜻은 법적 사용이 자동으로 허용된다는 뜻이 아니라, 작은 범위에서 기술 구조를 검증하기 좋다는 의미입니다.

결정 기준을 한 줄로 정리하면 다음과 같습니다.

• 학습·연구 목적이고 범위가 작다: 로컬 또는 제한된 원격 환경에서 시험합니다.
• 공식 허가와 데이터 사용 근거가 있다: 필드 최소화와 접근 통제를 전제로 별도 검토합니다.
• 상업 대량 수집, 장기 안정성, 높은 처리량이 핵심이다: MediaCrawler에 바로 의존하지 말고 공식 API나 계약된 데이터 경로를 우선합니다.
• 계정 이상이나 규칙 변경이 발생했다: 수집을 멈추고 범위와 법적 근거를 다시 확인합니다.

결국 현재의 일반적인 서버 방식은 브라우저 세션을 직접 관리해야 하고, 원격 디버깅 포트와 쿠키를 보호해야 하며, 화면 확인과 장애 복구까지 운영자가 책임져야 한다는 단점이 있습니다. 반면 Mac 기반 원격 브라우저 환경은 실제 브라우저 프로필을 분리하고, 짧은 연구 기간에 맞춰 별도 작업 공간을 구성하는 선택지가 될 수 있습니다. 다만 대규모 상시 수집이나 플랫폼 제한을 피하기 위한 용도에는 적합하지 않으며, 합법적인 연구 범위 안에서 임시 Playwright 환경이 필요한 경우에만 kvmboot의 Mac 환경을 비교해 보는 것이 합리적입니다.