문서

방법론

이 데이터셋이 어떻게 수집되고, 처리되며, 안전하게 조회할 수 있도록 만들어지는지 — 그리고 그 한계가 어디에 있는지.

이것은 무엇인가요

이것은 공개 투명성 보고 데이터를 독립적이고 비공식적으로 집계한 것으로, 어떤 플랫폼이나 기업, 정부와도 제휴하지 않았습니다. 두 종류의 보고 자료를 하나의 조회 가능한 스키마로 통합합니다:

  • EU DSA 투명성 보고서
    유럽연합 디지털서비스법(DSA)에 따라 제공자가 게시하는 정기 콘텐츠 관리 통계로, DSA 제15조·제24조·제42조(각각 중개 서비스, 온라인 플랫폼, 초대형 플랫폼에 대한 보고 의무)가 요구하는 주기적 투명성 보고서입니다. 개별 처분 사유서(Statements of Reasons)를 다루는 별도의 실시간 DSA 투명성 데이터베이스와는 다릅니다. 제출자는 공통의 계층형 EU 템플릿을 사용하며, 각 제공자는 자신의 계층이 요구하는 보고 섹션만 작성합니다(이 데이터셋은 해당 섹션을 내부적으로 t3–t11로 색인합니다). 이는 EU 내 도달 범위로 인해 유럽연합 집행위원회가 공식적으로 지정한 초대형 온라인 플랫폼 및 검색 엔진(VLOPs / VLOSEs) — 더 자주, 더 상세히 보고하는 곳 — 과 함께 수십 개의 소규모 플랫폼을 아우릅니다. 실시간 집계와 대상 기간은 DSA 보고서 대시보드를 참조하십시오.
  • Google 정부 삭제 요청
    국가, 제품, 사유, 보고 기간별로 분류된, 콘텐츠 삭제를 요청하는 정부 요청에 대한 Google의 보고 집계치 — DSA 제출 자료가 아니라 Google이 오랫동안 자발적으로 작성해 온 자체 투명성 보고서입니다. Google 삭제 요청 대시보드에서 살펴보세요.

각 플랫폼이 자체 기초 보고서를 어디에 공개하는지는 보고서 위치 페이지에 정리되어 있으며, 원본 파일의 보관본 링크가 함께 제공됩니다.

데이터의 출처

모든 수치는 이를 공개한 플랫폼 또는 회사에서 비롯됩니다 — 이는 이 프로젝트가 산출한 추정치가 아니라 그들이 보고한 수치이며, 보고된 값을 변경하지 않고 그대로 재현한 것입니다. 여기에서의 기여는 집계와 구조화입니다. 개별적으로 공개된 보고서를 수집하고, 그 표를 추출하며, 비교와 질의가 가능하도록 하나의 스키마로 정규화하는 것입니다. 보고된 값 자체는 결코 수정되지 않습니다. 변환은 구조적인 것으로 — 추출, 집계 합계 행 표시, 언어 간 레이블 정규화, 파싱할 수 없는 행 제거 — 아래에 설명되어 있습니다.

보고서가 조회 가능해지는 과정

각 원본 보고서의 표는 추출되어, API가 읽기 전용(심층 방어)으로 열고 읽을 수만 있고 절대 쓸 수 없는 인터페이스를 통해서만 접근하는 데이터베이스에 적재됩니다 — 이는 스타 스키마로 구성되어 있습니다: DSA 보고서 표마다 하나의 수치 테이블(내부적으로 t3–t11로 색인됨)이 있고, 그 주위를 공유 조회 테이블(서비스, 카테고리, 섹션, 지표, 범위, 표면, 보고 기간)이 둘러쌉니다. 반복되는 레이블은 한 번만 저장되고 번호로 참조되므로, 동일한 카테고리나 플랫폼 이름이 한 곳에만 존재합니다. 그렇게 만들어진 테이블과 쿼리 가능한 모든 필드를 스키마 페이지에서 살펴보세요.

아홉 개의 보고서 표는 다음과 같이 해석됩니다: t3 회원국 명령 · t4 신고(신뢰할 수 있는 신고자 포함) · t5 / t6 자체 발의 조치(불법 콘텐츠 / 서비스 약관) · t7 이의 제기 & 재발 · t8 자동화 수단 사용 · t9 인적 자원 · t10 월평균 활성 수신자 · t11 정성적 설명.

보고서가 템플릿에 맞지 않는 경우

대부분의 플랫폼은 11개 섹션으로 고정된 워크북을 제출하며, 적재기는 각 시트를 그 이름에 있는 섹션 번호에 따라 배치합니다. 일부는 형식 변형을 제출합니다. 기반이 되는 템플릿 내용은 같지만 시트의 이름이 바뀌었거나 번호가 다시 매겨져 있습니다. 이러한 경우는 각 시트를 표준 섹션에 대응시키는 플랫폼별 명시적 대응표를 통해 매핑되므로, 수치는 여전히 올바른 보고서 테이블에 들어갑니다. LINE은 템플릿을 번호가 없는 다섯 개의 시트로 압축하며(섹션 1·3·4·5·11에 대응), Discord는 불법 콘텐츠에 대한 자체 발의 조치, 인적 자원, 활성 수신자 섹션을 생략하고 나머지의 번호를 다시 매기므로 그 시트들은 이름으로 대응됩니다(예를 들어 그 “Own Initiative TC”는 섹션 5가 아니라 서비스 약관에 관한 자체 발의 조치 테이블인 섹션 6입니다). 애초에 조화된 템플릿이 아닌 문서는 억지로 끼워 맞추지 않습니다. 매핑하면 원본에 없는 구조를 지어내게 되기 때문입니다. heise의 포럼 보고서는 독일어 자유 텍스트 카테고리를 사용한 제15조의 짧은 자유 형식 요약이고, WordPress.com은 다른 종류의 보고서(DMCA, 정부, IRU 요청)를 공개합니다. 이러한 것들은 t3–t11에 적재하지 않고 보관된 원본 파일로 유지합니다.

중복 집계 방지

DSA 템플릿은 합산 대상인 세부 항목 행 바로 옆에 집계 합계 행을 배치합니다 (예: 카테고리별 건수 옆에 전체 합계인 “All the entries” 카테고리, 인용/기각 결과 옆에 “Total number” 범위, 또는 Core·Ads 같은 표면별 행을 합산하는 “All” 표면). 그러한 열에 대해 단순히 SUM을 적용하면 세부 항목 그 합계까지 함께 세어 수치가 부풀려집니다. 적재기는 모든 집계 행에 is_total 표시를 붙이고 이를 필터링 가능한 차원으로 노출하므로, 쿼리가 의도적으로 단일 단위를 선택하여 — 합계만, 또는 세부 항목만 — 합계와 그 구성 요소를 함께 더하는 일이 결코 없도록 합니다. 대시보드의 대표 수치는 보고된 합계를 사용하고, 세부 항목 차트는 구성 요소 행을 사용합니다. 어떤 수치에 여전히 유의 사항이 있는 경우, API는 대시보드가 결과와 함께 표시하는 warnings 메모를 반환합니다.

여러 언어에 걸친 해석

비VLOP 플랫폼은 조화된 템플릿을 EU 공식 언어 중 어느 것으로든 제출할 수 있으므로, 동일한 템플릿 행이 서로 다른 텍스트로 들어올 수 있습니다(Decisions upheld / Décisions confirmées / Bestätigte Entscheidungen). 각 행은 표시를 위해 원어 레이블을 유지하되, 언어 중립적인 표준 레이블 — 표준 키 — 도 함께 부여받습니다. 이는 동일 구조의 보고서를 영어 기준에 맞추고 모호한 것은 모두 제외하는 번역 맵(“크로스워크”)을 통해 매칭됩니다. 쿼리는 표준 키로 그룹화하거나 필터링하여 언어 간에 동등한 항목끼리 비교할 수 있으며, 원어 텍스트도 여전히 표시됩니다 — 다만 모든 언어에 걸쳐 적용 범위가 아직 균일하지는 않습니다(알려진 한계 참조).

조회 방법

SQL 인터페이스는 없습니다. 쿼리는 구조화된 요청입니다. 즉 테이블 이름, 필드/연산/값 조건으로 이루어진 불리언 필터, 그리고 선택적인 그룹화, 집계, 정렬, 제한을 지정합니다. 서버는 모든 필드와 연산을 해당 테이블의 고정 레지스트리에 대조하여 검증하고, 이를 사전 점검된 단일 데이터베이스 조회(매개변수화된 SELECT)로 컴파일합니다. 여기서 입력은 항상 데이터로 취급되며 결코 명령으로 실행되지 않습니다. 쿼리에도 한계가 설정되어 있어—결과 크기 상한, 요청 크기 및 복잡도 제한, 키별 속도 제한—하나의 요청이 서비스를 고갈시킬 수 없습니다. 테이블을 가로지르는 “복합” 쿼리는 동일한 검증된 경계를 통해 공유 차원에서 둘 이상의 테이블을 결합합니다. 자연어 “Ask” 상자는 활성화된 경우 입력하신 질문을 (데이터셋의 스키마와 함께) 제3자 LLM(Anthropic의 Claude)에 보내 구조화된 쿼리를 초안으로 작성하게 하며, 이는 다른 쿼리와 마찬가지로 검증을 거친 후에 실행됩니다. 이 LLM 호출은 서비스가 입력을 자체적으로 외부에 전송하는 유일한 경우입니다. 또 다른 외부 경로는 옵트인이며 사용자가 지정하는 것으로, 쿼리에 첨부하는 선택적 callback_url이 사용자 자신의 결과를 사용자가 선택한 URL로 전달합니다. DSA 보고서 대시보드에서 사용해 보시거나, API 참조개인정보 안내를 읽어보세요.

재현성 & 인용

데이터베이스는 정적이고 읽기 전용인 스냅샷입니다. 각 스냅샷에는 불변의 데이터셋 버전이 부여됩니다. 이는 그 내용의 지문으로, 데이터가 바뀔 때마다 변경됩니다. ETagX-Dataset-Version 헤더로 전송되며, 모든 팩트 행은 그 출처 제출물의 report_id를 노출합니다. 하나의 수치는 세 가지—데이터셋 버전, 정확한 쿼리, 그리고 그것이 참조하는 report_id—가 함께 모여 고정됩니다. 따라서 이 세 가지를 모두 인용하면 해당 행을 다시 가져올 수 있습니다(버전과 report_id만으로는 출처 제출물을 식별할 뿐, 특정 수치를 식별하지는 않습니다). 정렬하거나 페이지를 나눌 때 결과는 항상 완전히 결정론적인 순서로 반환되므로, 저장된 추출본은 바이트 단위로 재현 가능합니다. 스냅샷의 빌드 날짜와 대상 기간은 각 대시보드의 “Cite as” 줄과 모든 내보내기의 헤더에 표시되며, 어떤 행의 report_id는 그 출처 제출물(플랫폼, 기간, 등급)을 식별합니다. VLOP가 아닌 플랫폼의 경우, 해당 제출물이 어디에 게시되는지는 보고서 위치 카탈로그에 플랫폼별로 나열되어 있습니다.

출처 표기: 수치는 그것을 보고한 플랫폼에 귀속시키고, 이 사이트는 접근 도구로만 인용하십시오.

예: YouTube, EU DSA transparency report (H2 2025), accessed via the Transparency Report API — dataset version 7f3c1a2b9d04, report_id 42, retrieved 2026-06-26. 실시간 스냅샷의 정확한 데이터셋 버전과 대상 기간은 DSA 보고서Google 삭제 요청 대시보드의 “Cite as” 줄에 표시됩니다.

알려진 한계

  • 실시간이 아닌 스냅샷
    수치는 스냅샷을 빌드할 당시 이용 가능했던 보고서를 반영합니다. 이후의 수정이나 새로 제출된 보고서는 다음 스냅샷(새 데이터셋 버전)에서만 나타납니다.
  • 원본 품질의 편차
    플랫폼마다 엄밀성과 서식이 다르게 제출합니다. 잘못 파싱된 쓰레기 행(헤더 셀, 빈 값, 일부 추출 과정에서 새어 나온 잡값)은 추측하지 않고 로딩 중에 제외되며, 교차 언어 크로스워크가 명확하게 매핑할 수 없는 템플릿 행도 마찬가지로 제외됩니다. 제외된 행의 정확한 개수와 크로스워크 적용 범위는 아직 공개되지 않았으므로, 전체적인 완전성은 정량화되어 있지 않습니다.
  • 일부 라벨은 정규화되지 않은 채 유지
    그리스어 추출물은 원본 데이터에 열이 어긋나 있어, 대부분의 그리스어 지표/범위 라벨은 잘못된 매핑을 무릅쓰기보다는 정확하되 매핑되지 않은 상태로 둡니다. 카테고리 라벨은 아직 여러 언어에 걸쳐 크로스워크되지 않았습니다.
  • 시연용 서비스
    이것은 포트폴리오/데모 프로젝트입니다. 출처에는 충실하지만 공식 기록은 아니므로 — 중요한 사안에 대해서는 항상 플랫폼이 직접 공개한 보고서(보고서 위치에서 링크됨)와 대조하여 확인하세요.

출처 & 코드

전적으로 공개 보고 자료로 구축되었습니다. 추출, 정규화, 크로스워크, 쿼리 계층에 이르는 전체 파이프라인은 github.com/krMaynard/transparency-report-api에서 오픈 소스로 공개되어 있습니다. 탐색을 시작하세요: DSA 보고서 · Google 삭제 요청 · 스키마.