Facebook 스크래퍼 GitHub: 아직 되는 것과 안 되는 것

GitHub에서 "facebook scraper"를 검색하면 가 나옵니다. 그중 지난 6개월 동안 푸시된 것은 뿐입니다.

2026년 GitHub에서의 Facebook 스크래핑은 바로 이 "있긴 있는데 실제로는 안 되는" 간극이 핵심입니다.

저는 저장소의 이슈 탭, Reddit의 불만 글, 그리고 실제 도구 출력까지 꽤 오랫동안 살펴봤습니다. 패턴은 일관됩니다. 별점이 높은 프로젝트들 상당수는 조용히 망가졌고, 유지보수자는 손을 뗐으며, Facebook의 스크래핑 방지 방어는 계속 더 정교해지고 있습니다. 개발자와 비즈니스 사용자들은 같은 검색 결과에 도착하고, 같은 저장소를 설치하고, 결국 같은 빈 출력에 부딪힙니다. 이 글은 2026년 기준 현실 점검입니다. 어떤 저장소가 여전히 시간을 들일 가치가 있는지, Facebook이 어떻게 그것들을 무너뜨리는지, 그리고 언제 GitHub 자체를 건너뛰어야 하는지를 솔직하게 정리했습니다.

사람들이 GitHub에서 Facebook 스크래퍼를 찾는 이유

이 검색 뒤에 있는 사용 사례는 예전부터 늘 있던 것들입니다. 도구가 자꾸 고장 나도 수요는 그대로예요.

• 리드 생성: 영업용으로 비즈니스 페이지의 연락처 정보(이메일, 전화번호, 주소) 추출
• 마켓플레이스 모니터링: 이커머스나 차익거래를 위해 상품 목록, 가격, 판매자 정보 추적
• 그룹 리서치: 시장 조사, OSINT, 커뮤니티 관리를 위한 게시물과 댓글 보관
• 콘텐츠 및 게시물 아카이빙: 공개 페이지의 게시물, 반응, 이미지, 타임스탬프 저장
• 이벤트 집계: 이벤트 제목, 날짜, 위치, 주최자 수집

GitHub가 매력적인 이유도 분명합니다. 코드가 보이고, 비용이 없고, 커뮤니티가 유지보수해 줄 것 같고(이론상), 필드와 파이프라인을 마음대로 제어할 수 있으니까요.

문제는 별점과 포크 수가 "지금 제대로 작동하는지"와는 별 상관이 없다는 점입니다. 별점 기준 상위 10개 정확한 구문 저장소를 보면, 이었습니다. 우연이 아니라, 이 영역의 기본 상태에 가깝습니다.

한 Reddit 사용자는 에서 6개월을 시도한 끝에, 외부 데이터 스크래핑 애플리케이션에 돈을 쓰거나 Python에 JS 렌더링과 상당한 컴퓨팅 파워를 더하지 않으면 "불가능했다"고 분명하게 말했습니다. 또 다른 사용자는 에서 "Facebook은 자동화를 강하게 차단해서 크롤링하기 더 어려운 편"이고, 브라우저 자동화는 "Facebook이 DOM을 계속 바꾸기 때문에 취약하다"고 요약했습니다.

사용 사례는 진짜입니다. 수요도 진짜입니다. 불만도 정말 큽니다. 이 글은 그 간극을 어떻게 건너갈지에 대한 이야기입니다.

GitHub의 Facebook 스크래퍼 저장소는 정확히 무엇인가요?

GitHub의 "Facebook 스크래퍼"는 보통 Python으로 작성된 오픈소스 스크립트로, Facebook 페이지, 게시물, 그룹, 마켓플레이스, 프로필의 공개 데이터를 프로그램으로 추출합니다. 모든 도구가 같은 방식으로 동작하는 건 아닙니다. 주된 구조는 세 가지입니다.

브라우저 자동화 스크래퍼 vs API 래퍼 vs 직접 HTTP 스크래퍼

는 직접 HTTP 방식의 대표 사례입니다. API 키 없이 직접 요청과 파싱으로 공개 페이지를 스크래핑합니다. 은 브라우저 자동화 사례이고, 는 예전 Graph API 시절의 도구로, 지금은 광범위하게 사용할 수 없는 공식 엔드포인트를 통해 페이지/그룹 게시물을 가져오던 스크립트를 보여줍니다.

이 저장소들이 보통 다루는 데이터는 게시물 텍스트, 타임스탬프, 반응/댓글 수, 이미지 URL, 페이지 메타데이터(카테고리, 전화번호, 이메일, 팔로워 수), 마켓플레이스 목록 필드, 그룹 또는 이벤트 메타데이터 등입니다.

2026년의 진짜 선택 기준은 언어 선호가 아닙니다. 어떤 실패를 감당할 수 있느냐예요.

2026년 Facebook 스크래퍼 GitHub 최신성 점검: 실제로 어떤 저장소가 작동할까?

저는 GitHub에서 별점이 높고 많이 추천되는 Facebook 스크래퍼 저장소들을 2026년 실제 데이터로 점검했습니다. README 주장만 본 게 아니라, 실제 커밋 날짜, 이슈 큐, 커뮤니티 보고를 기준으로 봤습니다. 이 섹션이 가장 중요합니다.

전체 최신성 점검 표

여기서 몇 가지가 바로 눈에 들어옵니다.

• "활성 포크"로 보이는 moda20조차 2024년 6월 이후로 푸시가 없습니다.
• 이슈 큐가 README보다 훨씬 빨리 실제 상태를 보여줍니다.
• kevinzg와 moda20은 둘 다 에서 Python ^3.6을 그대로 선언하고 있습니다. 의존성 기준선이 현대화되지 않았다는 신호입니다.

kevinzg/facebook-scraper

GitHub에서 가장 잘 알려진 Python Facebook 스크래퍼입니다. 에는 페이지 스크래핑, 그룹 스크래핑, 자격 증명이나 쿠키를 통한 로그인, 그리고 comments, image, images, likes, post_id, post_text, text, time 같은 게시물 수준 필드가 설명되어 있습니다.

하지만 운영 신호는 약합니다.

• 마지막 푸시: 2024년 6월 22일
• 열린 이슈: — "Example Scrape does not return any posts" 같은 제목 포함
• 유지보수자는 최근 이슈에 응답하지 않았습니다

판정: 부분적으로 고장. 소규모 공개 페이지 실험이나 필드명 참고용으로는 여전히 의미가 있지만, 프로덕션 용도로는 신뢰하기 어렵습니다.

moda20/facebook-scraper (커뮤니티 포크)

kevinzg의 가장 눈에 띄는 포크로, 추가 옵션과 extract_listing 같은 마켓플레이스용 헬퍼가 포함되어 있습니다( 참고).

를 보면 고장 양상이 아주 분명합니다.

• "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

한때 공개 Pages와 열린 Groups에서 게시물, 반응, 댓글, 메타데이터를 CSV로 모으는 아주 실용적인 Graph API 도구였습니다. 에는 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월에 라고 묻는 이슈가 하나 있습니다. 거의 다 말해줍니다.
• Mhmd-Hisham/selenium_facebook_scraper와 anabastos/faceteer: 현재 활동이 충분하지 않아 신뢰할 수 없습니다.

Facebook의 스크래핑 방지 방어: GitHub 스크래퍼가 상대해야 하는 것

이 주제에 대한 대부분의 글은 대충 "이용약관을 확인하라"는 식으로 끝냅니다. 별 도움이 안 됩니다.

Facebook은 주요 플랫폼 중에서도 스크래핑 방어가 가장 강한 축에 속합니다. 어떤 방어층이 있는지 이해해야, 작동하는 스크래퍼와 오후 내내 빈 출력만 보는 상황을 구분할 수 있습니다.

Meta의 은 코드베이스 전반의 정적 분석으로 스크래핑 경로를 식별하는 "Anti Scraping team", 경고장 발송, 계정 비활성화, 그리고 rate-limiting 시스템 활용을 설명합니다. 이건 가설이 아니라 조직 차원의 대응입니다.

랜덤화된 DOM과 CSS 클래스명

Facebook은 HTML 요소 ID, 클래스명, 페이지 구조를 의도적으로 랜덤화합니다. 한 사용자는 이렇게 말했습니다. "정상적인 스크래퍼로는 Facebook을 다룰 수 없다. 새로고침할 때마다 HTML이 바뀐다."

무엇이 깨지나: 지난주에 잘 되던 XPath와 CSS 선택자가 오늘은 아무것도 못 가져옵니다.

대응책: 가능하면 텍스트 기반 또는 속성 기반 선택자를 쓰세요. 고정된 선택자에 의존하기보다 페이지 내용을 읽는 AI 기반 파싱이 더 잘 버팁니다. 선택자 유지보수는 반복 비용으로 생각해야 합니다.

로그인 벽과 세션 관리

프로필, 그룹, 일부 마켓플레이스 목록 등 Facebook의 많은 화면은 로그인해야 볼 수 있습니다. 헤드리스 브라우저는 리디렉션되거나 단순화된 HTML만 받습니다. passivebot 마켓플레이스 스크래퍼의 에서도 가장 큰 불만 중 하나가 "login to view the content"입니다.

무엇이 깨지나: 익명 요청은 내용을 놓치거나 아예 리디렉션됩니다.

대응책: 실제 브라우저 세션에서 얻은 세션 쿠키를 쓰거나, 로그인된 세션 안에서 동작하는 브라우저 기반 스크래핑 도구를 사용하세요. 계정을 돌려 쓰는 방법도 가능하긴 하지만 위험합니다.

디지털 핑거프린팅

Meta의 엔지니어링 글은 무단 스크래퍼가 고 말합니다. 즉, 탐지의 핵심이 브라우저 품질과 행동 품질이라는 뜻입니다. 과 커뮤니티 토론에서도 anti-detect 브라우저와 일관된 핑거프린트를 계속 권장하고 있습니다.

무엇이 깨지나: 일반적인 Selenium이나 Puppeteer 설정은 쉽게 식별됩니다.

대응책: undetected-chromedriver 같은 도구나 anti-detect 브라우저 프로필을 사용하세요. 단순한 user-agent 위장보다 실제 같은 세션과 일관된 핑거프린트가 더 중요합니다.

IP 기반 rate limiting과 차단

Meta의 엔지니어링 글은 방어 전략의 일부로 rate limiting을 명시적으로 언급하며, 팔로워 목록 수를 제한해 더 많은 요청을 유도한 뒤 시키는 방식도 설명합니다. 실제로는 rate limit이 걸렸다는 보고가 있습니다.

무엇이 깨지나: 같은 IP에서 대량 요청을 보내면 몇 분 안에 속도가 제한되거나 차단됩니다. 데이터센터 프록시 IP는 종종 미리 차단되어 있습니다.

대응책: 데이터센터 프록시가 아니라 레지던셜 프록시를 회전시키고, 요청 속도도 무리하지 않게 조절하세요.

GraphQL 스키마 변경

일부 스크래퍼는 Facebook 내부 GraphQL 엔드포인트를 사용합니다. 원시 HTML보다 더 깔끔한 구조 데이터를 주기 때문입니다. 하지만 Meta는 내부 GraphQL에 대한 안정성 보장을 공개하지 않기 때문에, 이 쿼리들은 조용히 깨집니다. 에러 대신 빈 데이터를 돌려주는 경우가 많습니다.

무엇이 깨지나: 구조화된 추출이 조용히 아무것도 반환하지 않습니다.

대응책: 검증 체크를 추가하고, 스키마 엔드포인트를 모니터링하며, 알고 있는 정상 쿼리에 고정하세요. 유지보수는 필수입니다.

스크래핑 방지 방어 요약

GitHub 저장소가 실패할 때: 노코드 우회로

"facebook scraper github"를 검색하는 사람들 중 상당수는 개발자가 아닙니다. 비즈니스 페이지 이메일을 찾으려는 영업 담당자, 마켓플레이스 가격을 추적하는 이커머스 운영자, 경쟁사 조사를 하는 마케터인 경우가 많습니다. 이들은 Python 환경을 관리하거나, 망가진 선택자를 디버깅하거나, 프록시를 돌리고 싶지 않습니다.

이게 본인 이야기라면, 선택은 짧습니다.

Facebook 페이지 연락처 정보(이메일, 전화번호) 스크래핑

Page의 "소개" 섹션에서 이메일과 전화번호를 뽑는 일이면 GitHub 저장소는 과합니다. 의 무료 와 는 웹페이지를 스캔해서 결과를 Sheets, Excel, Airtable, Notion으로 내보냅니다. AI가 매번 페이지를 새로 읽기 때문에 Facebook의 DOM이 바뀌어도 깨지지 않습니다.

마켓플레이스 또는 비즈니스 페이지에서 구조화된 데이터 스크래핑

상품 목록, 가격, 위치, 비즈니스 정보를 추출할 때는 Thunderbit의 AI 웹 스크래퍼에서 "AI 필드 제안"을 클릭하면 됩니다. AI가 페이지를 읽고 가격, 제목, 위치 같은 열을 제안한 뒤, "스크래핑"만 누르면 끝입니다. XPath 유지보수도 없고, 코드 설치도 필요 없습니다. .

예약 모니터링(마켓플레이스 가격 알림, 경쟁사 추적)

"내 가격대에 맞는 마켓플레이스 목록이 뜨면 알려줘" 같은 지속 모니터링에는 Thunderbit의 가 유용합니다. 처럼 간단한 언어로 주기를 설명하고 URL을 넣기만 하면 됩니다. 크론 작업 없이 자동 실행됩니다.

여전히 GitHub 저장소가 맞는 경우

깊은 수준의 프로그래밍 제어, 대규모 추출, 맞춤형 데이터 파이프라인이 필요하다면 GitHub 저장소나 가 맞는 선택입니다. 결정 기준은 단순합니다. 간단한 추출이 필요한 비즈니스 사용자 → 노코드 우선; 데이터 파이프라인을 만드는 개발자 → GitHub 저장소 또는 API.

실제 출력 예시: 실제로 무엇을 얻게 될까?

경쟁 글들은 항상 코드만 보여주고 실제 출력은 보여주지 않습니다. 아래는 각 접근 방식에서 현실적으로 기대할 수 있는 결과입니다.

출력 예시: kevinzg/facebook-scraper(또는 활성 포크)

에서처럼, 스크래핑한 공개 게시물은 다음과 같은 JSON을 반환합니다.

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "Don't let this diminutive version...",
9  "text": "Don't let this diminutive version...",
10  "time": "2019-04-30T05:00:01"
11}

comments_full처럼 null이 될 수 있는 필드에 주목하세요. 2026년에는 더 많은 필드가 비거나 누락된 채 돌아올 가능성이 큽니다. 대개는 사소한 오류가 아니라 차단 신호입니다. 출력은 원시 JSON이므로 후처리가 필요합니다.

출력 예시: Facebook Graph API

Meta의 현재 는 GET /<PAGE_ID>?fields=id,name,about,fan_count 같은 페이지 정보 요청을 문서화하고 있습니다. 에는 followers_count, fan_count, category, emails, phone 같은 필드와 기타 공개 메타데이터가 포함되지만, 같은 적절한 권한이 있어야 합니다.

이건 대부분의 GitHub 스크래퍼 사용자가 기대하는 데이터 형태보다 훨씬 좁습니다. 페이지 중심이고, 권한이 필요하며, 임의의 공개 게시물이나 그룹 스크래핑을 대체하지는 못합니다.

출력 예시: Thunderbit AI 웹 스크래퍼

Facebook 비즈니스 페이지에서 Thunderbit이 제안한 열은 깔끔한 구조화 테이블로 나옵니다.

게시물과 댓글의 경우 출력은 다음과 같습니다.

구조화된 열, 형식이 정리된 전화번호, 바로 쓸 수 있는 데이터까지 — 후처리 단계가 없습니다. GitHub 도구의 원시 JSON과는 차이가 확실합니다.

Facebook 데이터 유형 × 최적 도구 매트릭스

2026년의 Facebook에서 모든 것을 잘 처리하는 단일 도구는 없습니다.

이 매트릭스를 보면 글 전체를 읽지 않아도 자신의 사용 사례로 바로 이동할 수 있습니다.

우리 팀에는 어떤 접근 방식이 맞을까?

• 리드를 뽑아야 하는 영업팀: Thunderbit의 이메일/전화 추출기나 AI 스크래퍼부터 시작하세요. 설정 없이 바로 결과를 볼 수 있습니다.
• 마켓플레이스를 모니터링하는 이커머스 팀: Thunderbit의 예약 스크래퍼나, 엔지니어링 리소스가 있다면 커스텀 Scrapy + 레지던셜 프록시 구성을 쓰세요.
• 데이터 파이프라인을 만드는 개발자: GitHub 저장소(활성 포크) + 레지던셜 프록시 + 유지보수 예산이 필요합니다. 계속 손을 봐야 합니다.
• 그룹 콘텐츠를 보관하는 연구자: 브라우저 기반 워크플로만 고려하세요(Thunderbit 또는 로그인된 Selenium), 그리고 반드시 컴플라이언스 검토를 하세요.

솔직한 결론은, 그리고 도 이겁니다. 하나의 신뢰할 만한 만능 솔루션은 없습니다. 필요한 데이터에 맞는 도구를 써야 합니다.

단계별: GitHub에서 Facebook 스크래퍼를 설정하는 방법(의미가 있을 때만)

최신성 점검을 읽고도 여전히 GitHub 방식으로 가고 싶다면, 괜찮습니다. 실제로 어떻게 하는지와 어디서 깨지는지까지 솔직하게 적어두겠습니다.

1단계: 적절한 저장소 선택하기(최신성 점검 활용)

위의 점검 표로 돌아가세요. 목표 표면에 맞는, 가장 덜 오래된 저장소를 고르세요. 무엇이든 설치하기 전에 Issues 탭을 확인하세요. 최근 이슈 제목이 README보다 현재 기능을 더 잘 알려줍니다.

2단계: Python 환경 설정하기

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

흔한 함정: 특히 Selenium/Playwright 버전에서 의존성 충돌이 납니다. kevinzg와 moda20 모두 에서 Python ^3.6을 선언하고 있는데, 이 오래된 기준선이 최신 라이브러리와 충돌할 수 있습니다. passivebot의 마켓플레이스 스크래퍼는 을 고정해 두었는데, 실험용으로는 괜찮지만 내구성을 보장하는 증거는 아닙니다.

3단계: 프록시와 탐지 회피 설정하기

간단한 테스트를 넘어서면 반드시:

• 레지던셜 프록시 회전을 설정하기(Facebook 전용 IP 풀을 제공하는 업체를 찾기)
• 브라우저 자동화를 쓴다면 undetected-chromedriver를 설치하거나 anti-fingerprinting을 구성하기
• 이 단계를 건너뛰지 않기 — 일반 Selenium이나 Puppeteer는 금방 표시됩니다

4단계: 작은 테스트 스크래핑을 실행하고 출력 검증하기

처음부터 큰 배치가 아니라 공개 페이지 하나로 시작하세요. 출력을 꼼꼼히 확인합니다.

• 빈 필드나 누락 데이터는 대개 Facebook 방어가 막고 있다는 뜻입니다
• 브라우저에서 실제로 보이는 페이지와 출력을 비교하세요
• 멋진 README보다 한 페이지라도 성공하는 테스트가 더 중요합니다

5단계: 오류, rate limit, 유지보수 처리하기

• 재시도 로직과 에러 처리를 넣기
• 선택자나 설정을 주기적으로 업데이트해야 한다는 점을 예상하기 — 이건 한 번 설정하고 끝나는 일이 아닙니다
• 스크래퍼 유지보수에 데이터를 쓰는 것보다 더 많은 시간을 쓰게 된다면, 노코드 경로를 다시 고려해야 한다는 신호입니다

Facebook 스크래핑의 법적·윤리적 고려사항

이 섹션은 짧고 사실 위주로 적겠습니다. 글의 핵심은 아니지만, 무시하는 건 무책임하니까요.

Facebook의 은 사용자가 "사전 허가 없이 자동화된 수단을 사용하여 우리의 제품에서 데이터를 접근하거나 수집해서는 안 된다"고 명시합니다. 2026년 2월 3일 업데이트된 Meta의 도 제재에 계정 정지, API 접근 제거, 계정 단위 조치가 포함될 수 있음을 분명히 합니다.

이건 이론이 아닙니다. Meta의 은 무단 스크래핑 조사, 경고장 발송, 계정 비활성화를 설명합니다. Meta는 스크래핑 업체(예: Voyager Labs 소송)에 대해서도 를 취해 왔습니다.

가장 안전한 관점은 다음과 같습니다.

• Meta의 약관은 명시적으로 스크래핑을 금지합니다
• 허가받은 API 사용이 무단 스크래핑보다 안전합니다
• 공개되어 있다고 해서 개인정보보호법 준수 의무(GDPR, CCPA 등)가 사라지지 않습니다
• 대규모 운영이라면 법률 자문을 받으세요
• Thunderbit는 공개적으로 이용 가능한 데이터 스크래핑을 위해 설계되었고, 클라우드 스크래핑 사용 시 로그인 요구를 우회하지 않습니다

핵심 요약: 2026년에 Facebook 스크래핑에서 실제로 통하는 것

2026년에는 대부분의 Facebook 스크래퍼 GitHub 저장소가 고장 나 있거나 신뢰하기 어렵습니다. 겁주기용 문장이 아니라, 커밋 날짜와 이슈 큐, 커뮤니티 보고가 일관되게 보여주는 사실입니다.

아직 살아 있는 몇몇 포크는 제한적인 공개 페이지 데이터에 대해서는 작동하지만, 지속적인 유지보수와 탐지 회피 설정, 그리고 언젠가 또 깨질 거라는 현실적인 기대가 필요합니다. Graph API는 유용하긴 하지만 범위가 좁습니다. 적절한 권한이 있을 때 페이지 수준 메타데이터를 다루는 정도이지, 대부분 사람들이 원하는 광범위한 공개 게시물이나 그룹 스크래핑은 아닙니다.

개발자 부담 없이 Facebook 데이터가 필요한 비즈니스 사용자라면, 같은 노코드 도구가 더 신뢰할 수 있고 유지보수도 덜합니다. AI가 매번 페이지를 새로 읽기 때문에 DOM 변경이 워크플로를 깨지 않습니다. 을 무료로 사용해 보고, Sheets, Excel, Airtable, Notion으로 내보낼 수 있습니다.

실용적인 추천은 이렇습니다. 먼저 최신성 점검 표부터 보세요. 개발자가 아니라면 노코드 옵션을 먼저 시도하세요. 개발자라면 기술적 자원과 유지보수할 인내심이 있을 때만 GitHub 구성을 선택하세요. 그리고 어떤 경로를 택하든, 모든 것을 한 번에 해결하는 단일 솔루션을 기대하기보다 필요한 데이터에 맞는 도구를 고르세요.

소셜 미디어 데이터 스크래핑과 관련 도구를 더 깊이 보고 싶다면, , , 가이드를 참고해 보세요. 에서 실습 영상도 볼 수 있습니다.

자주 묻는 질문

2026년에 GitHub에서 작동하는 Facebook 스크래퍼가 있나요?

네, 하지만 선택지는 제한적입니다. 가장 주목할 만한 것은 kevinzg의 원본 저장소를 포크한 입니다. 현재 상태는 위의 최신성 점검 표를 확인하세요. 공개 페이지 게시물과 일부 메타데이터를 부분적으로 스크래핑할 수 있지만, 이슈 큐를 보면 mbasic 문제와 빈 출력 같은 핵심 고장이 드러납니다. 대부분의 다른 저장소는 방치되었거나 완전히 망가졌습니다.

코딩 없이 Facebook을 스크래핑할 수 있나요?

네. 와 무료 이메일/전화번호 추출기를 사용하면 Python이나 GitHub 설정 없이도 브라우저에서 몇 번 클릭만으로 Facebook 데이터를 추출할 수 있습니다. AI가 매번 페이지를 읽기 때문에 Facebook 레이아웃이 바뀌어도 선택자를 직접 관리할 필요가 없습니다.

Facebook 스크래핑은 합법인가요?

Facebook의 은 허가 없는 자동 데이터 수집을 금지합니다. Meta는 계정 정지, 경고장, 을 통해 이를 적극 집행합니다. 합법성은 관할권과 사용 사례에 따라 다릅니다. 공개 비즈니스 데이터만 다루고, 개인 프로필은 피하며, 대규모 운영이라면 법률 자문을 받으세요.

Facebook Graph API로 아직 무엇을 얻을 수 있나요?

2026년의 는 매우 제한적입니다. 적절한 권한과 같은 권한이 있으면 id, name, about, fan_count, emails, phone 같은 제한된 페이지 수준 데이터에 접근할 수 있습니다. 대부분의 공개 게시물 데이터, 그룹 데이터(), 사용자 수준 데이터는 더 이상 API로 제공되지 않습니다.

Facebook 스크래퍼 GitHub 저장소는 얼마나 자주 깨지나요?

자주입니다. Facebook은 DOM 구조, 봇 방지 조치, 내부 API를 계속 바꾸기 때문에 공개된 주기는 없지만, 커뮤니티 보고를 보면 활성 스크래퍼가 몇 주마다 한 번씩 깨지는 일이 흔합니다. moda20 포크의 mbasic 소실 관련 이슈 큐가 최근 사례입니다. GitHub 저장소에 의존한다면 정기적인 유지보수와 출력 검증을 위한 예산을 잡아야 합니다.

더 알아보기