GitHub에서 "facebook scraper"를 검색하면 475개 저장소가 나옵니다. 그런데 이 중 최근 6개월 안에 업데이트된 저장소는 62개뿐입니다.
즉, "있어 보이는 것"과 "실제로 돌아가는 것" 사이의 간극이 바로 2026년 GitHub 기반 Facebook 스크래핑의 현실입니다.
저는 저장소 이슈 탭, Reddit 불만 글, 그리고 실제 결과물을 오래 살펴봤습니다. 패턴은 아주 분명합니다. 상위 스타를 받은 프로젝트 상당수는 조용히 깨져 있고, 유지보수자는 손을 뗐으며, Facebook의 차단 방어는 계속 더 정교해지고 있습니다. 개발자와 비즈니스 사용자들은 같은 검색 결과에 도달해, 같은 저장소를 설치하고, 똑같이 비어 있는 출력을 마주합니다. 이 글은 2026년 기준 현실 점검입니다. 어떤 저장소가 아직 시간을 들일 가치가 있는지, Facebook이 무엇으로 이들을 무너뜨리는지, 그리고 언제 GitHub를 아예 건너뛰어야 하는지 솔직하게 짚어보겠습니다.
사람들이 GitHub에서 Facebook Scraper를 찾는 이유
이 검색 뒤에 있는 활용 사례는 예전부터 늘 비슷했습니다. 도구는 자꾸 망가져도, 수요는 줄지 않습니다.
- 리드 생성: 영업용 연락처 수집을 위해 비즈니스 페이지의 이메일, 전화번호, 주소 추출
- 마켓플레이스 모니터링: 이커머스나 차익거래를 위한 상품 목록, 가격, 판매자 정보 추적
- 그룹 리서치: 시장 조사, OSINT, 커뮤니티 관리를 위한 게시글과 댓글 아카이빙
- 콘텐츠 및 게시글 보관: 공개 페이지의 게시글, 반응, 이미지, 타임스탬프 저장
- 이벤트 집계: 이벤트 제목, 날짜, 위치, 주최자 정보 수집
GitHub가 매력적인 이유도 분명합니다. 코드가 공개되어 있고, 비용이 들지 않으며, 이론상 커뮤니티가 유지보수해주고, 필드와 파이프라인을 마음대로 제어할 수 있으니까요.
하지만 스타 수와 포크 수가 "지금도 잘 돌아간다"는 뜻은 아닙니다. 별점 기준 상위 10개 정확히 일치하는 저장소를 보면, 2026년 4월 기준 모두 12개월 이상 업데이트가 없었습니다. 우연이 아니라 거의 표준에 가깝습니다.
한 Reddit 사용자는 2025년 11월 스레드에서 6개월간 시도한 끝에, 외부 데이터 스크래핑 애플리케이션에 돈을 내거나 Python과 JS 렌더링, 상당한 컴퓨팅 자원을 함께 써야만 가능했다고 말했습니다. 또 다른 사용자는 2026년 4월 토론에서 Facebook은 "자동화를 강하게 차단하기 때문에 스크래핑이 특히 어렵다"고 했고, 브라우저 자동화는 "Facebook이 DOM을 계속 바꾸기 때문에 매우 취약하다"고 정리했습니다.
수요는 واقعی합니다. 불만도 정말 많습니다. 이 글은 그 간극을 어떻게 다룰지에 대한 이야기입니다.
GitHub의 Facebook Scraper 저장소는 정확히 무엇인가요?
GitHub에서 말하는 "Facebook scraper"는 보통 Python으로 작성된 오픈소스 스크립트로, Facebook 페이지, 게시글, 그룹, 마켓플레이스, 프로필의 공개 데이터를 프로그램으로 추출합니다. 모두 같은 방식으로 작동하는 것은 아닙니다. 주된 구조는 크게 세 가지입니다.
브라우저 자동화 스크래퍼 vs API 래퍼 vs 직접 HTTP 스크래퍼
| 접근 방식 | 대표 스택 | 장점 | 단점 |
|---|---|---|---|
| 브라우저 자동화 | Selenium, Playwright, Puppeteer | 로그인 벽을 처리할 수 있고 실제 사용자 행동을 흉내 낼 수 있음 | 느리고 리소스를 많이 쓰며, 설정이 조금만 부실해도 쉽게 탐지됨 |
| 공식 API 래퍼 | Meta Graph API / Pages API | 안정적이고 문서화되어 있으며 승인받으면 규정 준수 가능 | 매우 제한적임 — 대부분의 공개 게시글/그룹 데이터는 더 이상 제공되지 않음 |
| 직접 HTTP 스크래퍼 | requests, HTML 파싱, 비공개 엔드포인트 | 동작할 때는 빠르고 가벼움 | Facebook의 페이지 구조나 봇 차단 방식이 바뀌면 바로 깨짐 |
kevinzg/facebook-scraper는 대표적인 직접 HTTP 방식 예시입니다. API 키 없이 직접 요청과 파싱으로 공개 페이지를 긁어옵니다. apurvmishra99/facebook-scraper-selenium은 브라우저 자동화 예시입니다. minimaxir/facebook-page-post-scraper은 오래된 Graph API 시절의 도구로, 예전에는 공식 엔드포인트를 통해 페이지/그룹 게시글을 가져올 수 있었지만 지금은 그 접근성이 크게 줄었습니다.
이 저장소들이 다루는 대표 데이터는 게시글 텍스트, 타임스탬프, 반응/댓글 수, 이미지 URL, 페이지 메타데이터(카테고리, 전화번호, 이메일, 팔로워 수), 마켓플레이스 목록 필드, 그룹/이벤트 메타데이터 등입니다.
2026년에는 언어 취향이 핵심이 아닙니다. 어떤 실패를 감당할 수 있느냐가 더 중요합니다.
2026 Facebook Scraper GitHub 최신성 점검: 실제로 작동하는 저장소는?
저는 GitHub에서 가장 스타가 많고 가장 자주 추천되는 Facebook scraper 저장소들을 2026년 실제 데이터로 점검했습니다. README의 주장만 본 것이 아니라, 실제 커밋 날짜, 이슈 큐, 커뮤니티 보고서를 함께 확인했습니다. 이 섹션이 가장 중요합니다.
전체 최신성 점검 표
| 저장소 | 스타 수 | 마지막 업데이트 | 열린 이슈 수 | 언어 / 런타임 | 현재도 추출 가능한 것 | 상태 |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | 제한적인 공개 페이지 게시글, 일부 댓글/이미지, 페이지 메타데이터 | ⚠️ 부분적으로 깨짐 / 오래됨 |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | kevinzg와 동일 + 마켓플레이스 보조 메서드 | ⚠️ 부분적으로 깨짐 / 오래된 포크 |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Python 2/3 시절, Graph API 의존 | 역사적 참고용 | ❌ 방치됨 |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | 페이지 스크래핑용 브라우저 자동화 | ❌ 방치됨 |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | 브라우저 자동화를 통한 마켓플레이스 목록 수집 | ⚠️ 취약함 / 특수 용도 |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | 일반 Selenium 스크래핑 | ❌ 방치됨 |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | 자동화 중심 | ❌ 위험함 / 검증 부족 |
눈에 띄는 점은 몇 가지입니다.
- 가장 활발해 보이는 포크(mod a20)조차 2024년 6월 이후 업데이트가 없습니다.
- 진짜 상태는 README보다 이슈 큐가 훨씬 빨리 드러냅니다.
- kevinzg와 moda20 모두 pyproject.toml에서 여전히 Python ^3.6을 선언하고 있습니다. 의존성 기준이 현대화되지 않았다는 신호입니다.
kevinzg/facebook-scraper
GitHub에서 가장 잘 알려진 Python Facebook scraper입니다. README에는 페이지 스크래핑, 그룹 스크래핑, 자격 증명 또는 쿠키를 통한 로그인, 그리고 comments, image, images, likes, post_id, post_text, text, time 같은 게시글 단위 필드가 설명되어 있습니다.
하지만 운영 신호는 약합니다.
- 마지막 업데이트: 2024년 6월 22일
- 열린 이슈: 438개 — "Example Scrape does not return any posts" 같은 제목 포함
- 유지보수자는 최근 이슈에 응답하지 않았습니다
판정: 부분적으로 깨짐. 소규모 공개 페이지 실험이나 필드명 참고용으로는 쓸 만하지만, 프로덕션용으로 신뢰하기는 어렵습니다.
moda20/facebook-scraper (커뮤니티 포크)
kevinzg의 가장 눈에 띄는 포크로, 추가 옵션과 extract_listing 같은 마켓플레이스 중심 보조 기능이 있습니다(README 참조).
이슈 큐를 보면 문제가 명확합니다.
- "mbasic is gone"
- "CLI 'Couldn't get any posts.'"
- "https://mbasic.facebook.com is no longer working"
단순화된 mbasic 프론트엔드가 바뀌거나 사라지면, 그 위에 의존하던 스크래퍼는 한꺼번에 무너집니다.
판정: 가장 유명한 포크이긴 하지만, 2026년 기준으로도 오래되었고 매우 취약합니다. GitHub 기반 해결책을 꼭 써야 한다면 가장 먼저 시도해볼 가치는 있지만, 안정성은 기대하지 않는 편이 좋습니다.
minimaxir/facebook-page-post-scraper
한때는 Graph API를 이용해 공개 페이지와 공개 그룹의 게시글, 반응, 댓글, 메타데이터를 CSV로 수집하는 실용적인 도구였습니다. README에는 Facebook 앱의 App ID와 App Secret을 사용하는 방법이 여전히 설명되어 있습니다.
하지만 2026년 현재는 사실상 역사적 유물입니다.
- 마지막 업데이트: 2019년 5월 23일
- 열린 이슈: 53개 — "HTTP 400 Error Bad Request", "No data retrieved!!" 포함
판정: 방치됨. Meta가 이후 크게 좁혀버린 API 권한 모델에 강하게 묶여 있습니다.
기타 주목할 만한 저장소
- passivebot/facebook-marketplace-scraper: 마켓플레이스 용도로는 유용할 수 있지만, 이슈 큐에는 "login to view the content", "CSS selectors outdated", "Getting blocked"가 있습니다. 마켓플레이스 스크래핑이 무엇 때문에 무너지는지 한 줄로 보여주는 사례입니다.
- apurvmishra99/facebook-scraper-selenium: 2020년 9월에 올라온 "Does it work with new Facebook layout?"라는 이슈 하나만 봐도 거의 다 설명됩니다.
- Mhmd-Hisham/selenium_facebook_scraper와 anabastos/faceteer: 현재 활동이 너무 적어 신뢰하기 어렵습니다.
Facebook의 안티 스크래핑 방어: GitHub 스크래퍼가 상대해야 하는 것
이 주제에 대한 많은 글은 그냥 "약관을 확인하라"는 식의 뭉뚱그린 경고로 끝납니다. 그건 별 도움이 안 됩니다.
Facebook은 대형 플랫폼 중에서도 가장 공격적인 안티 스크래핑 체계를 갖춘 편입니다. 어떤 방어층이 있는지 이해하는 것이, 동작하는 스크래퍼와 오후 내내 빈 출력만 보는 상황을 가르는 차이입니다.
Meta의 2025년 2월 엔지니어링 포스트는 코드베이스 전반의 정적 분석으로 스크래핑 벡터를 찾아내는 "Anti Scraping 팀"을 운영하고, 중단 요구 서한을 보내고, 계정을 비활성화하며, 속도 제한 시스템에 의존한다고 설명합니다. 이건 가정이 아니라 실제 조직적 방어 전략입니다.
랜덤화된 DOM과 CSS 클래스 이름
Facebook은 HTML 요소 ID, 클래스 이름, 페이지 구조를 의도적으로 자주 바꿉니다. r/webscraping 댓글 중에는 이렇게 말한 사람도 있습니다. "정상적인 스크래퍼로는 Facebook에서 아무것도 할 수 없다. 새로고침할 때마다 HTML이 바뀐다."
무엇이 깨지나: 지난주에 잘 되던 XPath와 CSS 선택자가 오늘은 아무것도 못 가져옵니다.
대응: 가능하면 텍스트 기반 또는 속성 기반 선택자를 쓰세요. 딱딱한 셀렉터에 의존하기보다, 페이지 내용을 읽어들이는 AI 기반 파싱이 더 잘 버팁니다. 다만 셀렉터 유지보수는 계속 드는 비용이라고 보는 것이 맞습니다.
로그인 벽과 세션 관리
프로필, 그룹, 일부 마켓플레이스 목록 등 Facebook의 많은 영역은 로그인 없이는 볼 수 없습니다. 헤드리스 브라우저는 리디렉션되거나 내용이 줄어든 HTML만 받는 경우가 많습니다. passivebot 마켓플레이스 scraper의 이슈 탭에서도 가장 큰 불만 중 하나가 "login to view the content"입니다.
무엇이 깨지나: 익명 요청은 내용을 못 가져오거나 아예 리디렉션됩니다.
대응: 실제 브라우저 세션에서 가져온 세션 쿠키를 사용하거나, 로그인된 세션 안에서 동작하는 브라우저 기반 스크래핑 도구를 쓰세요. 계정 회전도 가능은 하지만 위험합니다.
디지털 지문 추적
Meta 엔지니어링 포스트는 비인가 스크래퍼가 "보통 사용자가 제품을 사용하는 방식을 흉내 내며 자신을 숨긴다"고 설명합니다. 이는 곧 브라우저 품질과 행동 품질이 탐지의 핵심이라는 뜻입니다. 3월과 2026년 4월 토론에서도 anti-detect 브라우저와 일관된 지문 유지가 계속 권장되고 있습니다.
무엇이 깨지나: 일반적인 Selenium이나 Puppeteer 설정은 쉽게 식별됩니다.
대응: undetected-chromedriver나 anti-detect 브라우저 프로필 같은 도구를 사용하세요. 단순한 user-agent 위조보다, 실제 같은 세션과 일관된 지문이 더 중요합니다.
IP 기반 속도 제한과 차단
Meta 엔지니어링 포스트는 방어 전략의 일부로 rate limiting을 명시적으로 언급하며, 팔로워 목록 수를 제한해 더 많은 요청을 유도하고 그 요청이 다시 속도 제어를 발동하게 만든다고 설명합니다. 실제로는 10개 그룹에 10초 간격으로 게시했더니 곧바로 rate limit이 걸렸다는 보고도 있습니다.
무엇이 깨지나: 같은 IP에서 대량 요청을 보내면 몇 분 안에 속도 제한이나 차단이 걸립니다. 데이터센터 프록시 IP는 사전에 막혀 있는 경우도 많습니다.
대응: 데이터센터 프록시가 아니라 residential proxy 회전을 쓰고, 요청 간격을 무리하지 않게 두세요.
GraphQL 스키마 변경
일부 스크래퍼는 Facebook 내부 GraphQL 엔드포인트를 사용합니다. HTML보다 더 깔끔한 구조화 데이터를 돌려주기 때문입니다. 하지만 Meta는 내부 GraphQL의 안정성을 보장하지 않으므로, 이런 쿼리는 에러를 내지 않고 조용히 깨져서 빈 데이터를 반환하는 경우가 많습니다.
무엇이 깨지나: 구조화 추출이 아무 결과도 내지 않습니다.
대응: 검증 체크를 추가하고, 스키마 엔드포인트를 모니터링하며, 확인된 쿼리에 고정하세요. 유지보수는 필수입니다.
안티 스크래핑 방어 요약
| 방어 계층 | 스크래퍼를 어떻게 망가뜨리는가 | 실전 대응책 | |---|---|---|---| | 레이아웃 변경 / 불안정한 셀렉터 | XPath와 CSS 셀렉터가 아무것도 못 가져오거나 일부만 가져옴 | 회복력이 높은 앵커를 선호하고, 실제 페이지 출력으로 검증하며, 유지보수를 전제로 설계 | | 로그인 벽 | 로그인 없는 요청은 내용을 못 가져오거나 리디렉션됨 | 유효한 세션 쿠키나 브라우저 세션 도구 사용 | | 지문 추적 | 일반 자동화가 인위적으로 보임 | 실제 브라우저, 일관된 세션 품질, anti-detect 수단 사용 | | 속도 제한 | 빈 출력, 차단, throttling | 느린 처리 속도, 작은 배치 크기, residential proxy 회전 | | 내부 쿼리 변경 | 구조화 추출이 조용히 빈 데이터를 반환 | 검증 체크 추가, 쿼리 유지보수 전제 |
GitHub 저장소가 실패할 때: 허용된 대안을 선택하세요
깨진 저장소를 봤다고 해서, 플랫폼의 제어를 우회할 다른 방법을 찾는 것이 정답은 아닙니다. 먼저 비즈니스 질문을 분명히 하세요. 필요한 것이 페이지 분석인지, 광고 투명성인지, 공개 연락처 디렉터리인지, 상품 카탈로그인지 말입니다. 이런 수요 중 상당수는 공식 Meta 제품, 권한이 부여된 API, 또는 Meta가 아닌 공개 소스로 해결할 수 있습니다.
예를 들어, Graph API는 앱과 사용 사례에 필요한 권한이 있을 때만 사용하세요. Meta 연구 프로그램은 자격 요건을 충족할 때만 활용하고, 광고 정보는 Meta Ad Library가 제공하는 범위 안에서 보세요. 리드 조사, 가격 확인, 지역 비즈니스 탐색에는 직접 약관과 개인정보 의무를 검토할 수 있는 독립적인 공개 웹사이트가 더 적합한 경우가 많습니다.
실제 출력 샘플: 실제로 무엇을 얻는가
대부분의 경쟁 글은 코드 조각만 보여주고, 실제 결과물은 보여주지 않습니다. 아래는 각 접근 방식에서 현실적으로 기대할 수 있는 출력입니다.
출력 예시: kevinzg/facebook-scraper (또는 활성 포크)
README 예시에서 공개 게시글을 스크래핑하면 다음과 같은 JSON이 반환됩니다.
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
comments_full처럼 null이 될 수 있는 필드를 주목하세요. 2026년에는 더 많은 필드가 비거나 누락될 것으로 예상해야 합니다. 이런 경우는 보통 사소한 오류가 아니라 차단 신호입니다. 출력은 raw JSON이며, 후처리가 필요합니다.
출력 예시: Facebook Graph API
Meta의 현재 Pages API 문서에는 GET /<PAGE_ID>?fields=id,name,about,fan_count 같은 페이지 정보 요청이 나와 있습니다. Page reference에는 followers_count, fan_count, category, emails, phone 같은 공개 메타데이터 필드가 포함되어 있지만, 이는 Page Public Content Access 또는 Page Public Metadata Access 같은 올바른 권한이 있어야만 가능합니다.
이건 대부분의 GitHub scraper 사용자가 기대하는 데이터 형태보다 훨씬 좁습니다. 페이지 중심이고, 권한으로 제어되며, 임의의 공개 게시글이나 그룹 스크래핑을 대신할 수는 없습니다.
Facebook 데이터 유형 × 접근 경로 매트릭스
| Facebook 데이터 유형 | 시작점으로 가장 적합한 것 | 핵심 제한 |
|---|---|---|
| 조직이 관리하는 자산 | 공식 Meta 관리 도구 및 승인된 API | 권한과 제공 필드가 상황에 따라 달라짐 |
| 광고 관찰 데이터 | Meta Ad Library | 노출되는 필드와 필터 범위 내에서만 사용 가능 |
| 리드 조사를 위한 공개 비즈니스 정보 | 허용된 비-Meta 디렉터리 또는 퍼블리셔 사이트 | 출처의 약관과 개인정보 의무를 확인해야 함 |
| 비공개, 닫힌 그룹, 로그인 필요, 계정 전용 자료 | 자동 수집하지 말 것 | 대신 승인된 경로를 찾을 것 |
단계별 가이드: GitHub에서 Facebook Scraper를 설정하는 방법(의미가 있을 때만)
최신성 점검을 읽고도 여전히 GitHub 경로를 가고 싶다면, 그 선택도 이해합니다. 아래는 현실적인 진행 방식입니다. 어디서 깨지는지도 솔직하게 적었습니다.
1단계: 올바른 저장소 선택하기(최신성 점검 활용)
위의 점검 표로 돌아가세요. 타깃 표면에 가장 맞고, 가장 덜 오래된 저장소를 고르세요. 설치 전에 꼭 Issues 탭을 확인하세요. 최근 이슈 제목이 README보다 현재 기능 상태를 더 잘 말해줍니다.
2단계: Python 환경 구성하기
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
자주 생기는 문제는 의존성 버전 충돌입니다. 특히 Selenium/Playwright 버전이 그렇습니다. kevinzg와 moda20 모두 pyproject.toml에서 Python ^3.6을 선언하고 있는데, 이 오래된 기준은 최신 라이브러리와 충돌할 수 있습니다. passivebot의 마켓플레이스 scraper는 playwright==1.40.0으로 고정되어 있는데, 실험용으로는 괜찮아도 내구성을 증명하는 것은 아닙니다.
3단계: 프록시와 탐지 회피 설정하기
간단한 테스트를 넘어서면 아래를 고려하세요.
- residential proxy 회전 설정하기(Facebook 전용 IP 풀을 제공하는 업체를 찾는 것이 좋음)
- 브라우저 자동화를 쓴다면 undetected-chromedriver 설치 또는 anti-fingerprinting 설정
- 이 단계를 건너뛰지 마세요. 일반 Selenium이나 Puppeteer는 금방 탐지됩니다
4단계: 소규모 테스트 스크래핑 후 출력 검증하기
처음에는 대량이 아니라 공개 페이지 하나로 시작하세요. 결과를 꼼꼼히 확인합니다.
- 비어 있는 필드나 누락 데이터는 보통 Facebook 방어가 막고 있다는 신호입니다
- 브라우저에서 실제로 보이는 내용과 결과를 비교하세요
- 멋진 README보다, 한 페이지를 제대로 가져오는 테스트가 훨씬 중요합니다
5단계: 오류, 속도 제한, 유지보수 대응하기
- 재시도 로직과 오류 처리를 넣으세요
- 셀렉터나 설정을 정기적으로 업데이트할 가능성을 열어두세요. 이건 한 번 하고 끝나는 일이 아니라 계속 관리해야 하는 작업입니다
- 스크래퍼를 유지보수하는 데 데이터를 쓰는 것보다 더 많은 시간을 쓰고 있다면, 노코드 방식으로 바꿀 신호입니다
Facebook 스크래핑의 법적·윤리적 고려사항
플랫폼 약관, 개인정보 규정, 계약 의무, 데이터 보호법이 모두 적용될 수 있습니다. 공개적으로 보인다는 사실이 자동 수집을 허가하는 것은 아닙니다. 수집 최소화를 지키고, 목적과 법적 근거를 문서화하며, 상업적이거나 대규모 프로그램이라면 법률 자문을 받으세요.
브라우저 확장 프로그램, 로그인된 세션, 또는 “공개”라는 라벨을 Meta 제품에서 자동 수집해도 된다는 허가로 해석하지 마세요.
핵심 정리: 2026년 Facebook 스크래핑에서 실제로 통하는 것
저장소 활동성, 이슈 큐, 그리고 현재 플랫폼 규칙이 스타 수나 오래된 README보다 중요합니다. 비즈니스 질문이 자신이 관리하는 자산과 관련되어 있다면, 공식 Meta 도구와 승인된 API부터 시작하세요. 시장 조사, 리드 조사, 가격 비교 같은 목적이라면, 허용된 비-Meta 소스가 더 쉽게 문서화되고 관리됩니다.
FAQ
2026년에 GitHub에서 제대로 작동하는 Facebook scraper가 있나요?
예, 하지만 선택지는 많지 않습니다. 가장 눈에 띄는 것은 kevinzg 원본 저장소를 포크한 moda20/facebook-scraper입니다. 현재 상태는 위의 최신성 점검 표를 확인하세요. 공개 페이지 게시글과 일부 메타데이터는 부분적으로 가져올 수 있지만, 이슈 큐를 보면 mbasic 문제와 빈 출력 같은 핵심적인 깨짐이 보입니다. 그 외 대부분의 저장소는 방치되었거나 완전히 망가졌습니다.
코딩 없이 Facebook을 스크래핑할 수 있나요?
수동 조사를 위해서는 Facebook 자체 검색 도구와 관리 도구를 사용하세요. 반복 가능하거나 프로그램화된 작업이 필요하다면 공식 API와 그 권한 범위를 검토하거나, 허용된 비-Meta 소스를 기준으로 워크플로를 다시 설계하세요. 노코드의 편의성이 플랫폼, 개인정보, 계약 의무를 없애주지는 않습니다.
Facebook을 스크래핑하는 것은 합법인가요?
Facebook의 이용약관은 허가 없는 자동 데이터 수집을 금지합니다. Meta는 계정 차단, 중단 요구서 발송, 그리고 소송을 통해 이를 적극 집행합니다. 합법성은 관할권과 사용 사례에 따라 다릅니다. 공개 비즈니스 데이터만 다루고, 개인 프로필은 피하며, 대규모 운영이라면 법률 전문가와 상담하세요.
Facebook Graph API에서 아직 얻을 수 있는 데이터는 무엇인가요?
2026년 기준 Graph API는 매우 제한적입니다. Page Public Metadata Access 같은 적절한 권한이 있어야 id, name, about, fan_count, emails, phone 같은 제한된 페이지 수준 데이터에 접근할 수 있습니다. 대부분의 공개 게시글 데이터, 그룹 데이터(Groups API는 deprecated 됨), 사용자 수준 데이터는 더 이상 API로 제공되지 않습니다.
Facebook scraper GitHub 저장소는 얼마나 자주 깨지나요?
매우 자주 깨집니다. Facebook은 DOM 구조, 안티봇 대책, 내부 API를 계속 바꾸기 때문에 공식적인 주기는 없지만, 커뮤니티 보고를 보면 활성 스크래퍼는 몇 주 간격으로 깨지는 경우가 많습니다. moda20 포크의 mbasic 이슈 큐는 최근 사례입니다. GitHub 저장소에 의존한다면 정기적인 유지보수와 출력 검증 예산을 반드시 잡아야 합니다.
더 알아보기
