요약

  • 2026년 8월 24일, IAB는 서비스, 제3자 인증 시스템 또는 네트워크에 부과되는 연령 확인이 민감한 데이터를 집중시키고, 개인정보 보호를 저해하며, 암호화에 압력을 가하고, 위험한 우회를 조장하고, 인터넷을 조각화할 수 있다고 경고했습니다.
  • 이 성명은 더 좁은 목표를 제시합니다. 사이트 간에 연결될 수 없고, 사용자 활동을 보고하지 않으며, 방문한 사이트를 연령 발급자에게 숨기고, 중앙화된 민감 데이터 저장소를 만들지 않고, 개방형 상호운용 인터페이스를 통해 전달되는 최소한의 목적별 연령 신호입니다.
  • IAB는 현재 기기 기반 방식이 가장 유망하다고 보지만, 그 방식이 기기와 운영체제 벤더에게 상당한 영향력을 주며 공유 기기에 대한 강력한 지원이 필요하다고 명시적으로 말합니다.
  • 이 성명은 법률도, 인증도, IETF 표준도, 배포 명령도 아니며 아키텍처 조언입니다. RFC 9998은 별개의 워크숍 보고서로, 참가자의 의견이 자동으로 IAB나 W3C 입장이 되지 않습니다.
  • 실행 가능한 구현에는 대체 수령증이 필요합니다. 기기, 운영체제, 브라우저, 인증 방식 또는 공급자가 바뀌더라도 아동 보호 결과와 최소 신호 의미론이 그대로 유지되어야 합니다.

확인의 주체가 바뀌면 통제권도 바뀐다

대부분의 연령 확인 논쟁은 정확성에서 출발합니다. 어떤 시스템이 기준선 위의 사람과 아래의 사람을 정확히 구분할 수 있는가? 이는 필요하지만 너무 늦게 시작되는 질문입니다. 검증자가 답을 내기 전에 이미 아키텍처는 누가 물어볼 수 있는지, 어떤 증거를 요구할 수 있는지, 결과가 어디에 저장되는지, 어떤 활동이 드러나는지, 그리고 장치가 고장 났을 때 누가 접근을 거부할 수 있는지를 결정해 놓았습니다.

확인을 각 웹사이트에 두면 사이트가 직접 또는 수탁자를 통해 수집자가 됩니다. 네트워크 인프라에 두면 접속 제공자가 서비스를 식별하고 차단을 집행할 방법이 필요해지며, 트래픽 가시성에 대한 압력이 생깁니다. 기기에 두면 신원이 모든 목적지로 전달될 필요는 없지만, 기기 또는 운영체제 계층이 중대한 신호를 중개할 능력을 갖게 됩니다.

이 셋은 동일한 중립 스위치의 세 가지 구현이 아닙니다. 각각은 통제권, 책임, 침해 노출, 협상력을 서로 다른 주체에게 배정합니다. 한 경계에서의 개인정보 개선이 다른 경계에서의 의존성을 만들 수 있습니다. 규제자는 반복적인 신원 제출을 줄이면서, 의도하지 않게 한 플랫폼의 인터페이스를 합법적 접근의 대가로 만들 수 있습니다.

바로 그래서IAB의 최근 성명이 중요합니다. 이 성명은 완성된 프로토콜을 제시하지 않습니다. 대신 발주 질문 자체를 바꿉니다. 오늘 시급한 규칙을 어떤 벤더가 만족시킬 수 있는지 묻는 대신, 어떤 기술을 쓰든 반드시 유지되어야 하는 시스템 속성은 무엇인지 묻습니다.

왜 서비스 경로와 네트워크 경로를 IAB가 우려하는가

공지 메일링 리스트 사본은 성명 전문을 담고 있으며 8월 24일자로 기록하고 있습니다. IAB는 온라인에서 아동을 보호하려는 목적을 공유하며 시작합니다. 반대하는 것은 그 목표가 아니라, 실패했을 때 모두에게 더 취약한 인터넷만 남기는 아키텍처입니다.

제3자 연령 확인 서비스는 신원과 자격 데이터의 고가치 저장소가 될 수 있습니다. 모든 사이트에 연령 확인을 요구하면 수집 지점이 곱해지고, 신원 도용 노출이 넓어지며, 사용자에게 어디를 둘러보든 신원 확인이 일상이라는 인식을 심어줍니다. 사이트가 생년월일 대신 범주형 결과만 받더라도, 더 큰 시스템은 여전히 상관 분석, 로그, 발급자의 지식, 재사용에 대한 통제를 필요로 합니다.

네트워크 차단은 문제를 다른 곳으로 옮깁니다. 승인된 확인을 수행하지 않는 서비스를 차단하려면 접속 제공자가 대상을 식별하고 경로 안에서 집행 결정을 내려야 합니다. IAB는RFC 7754를 인용하는데, 그 기술 분석은 차단 위치, 입도, 암호화, 부수 피해, 투명성, 구제를 보이지 않는 컴플라이언스 세부 사항이 아니라 아키텍처 질문으로 다룹니다.

우회는 부수적 참고 사항이 아닙니다. 낯선 무료 VPN, 사기성 자격 증명, 회색시장 애플리케이션으로 옮겨가는 어린 사용자는 하나의 관문을 벗어나는 대가로 더 위험한 중개자를 받아들일 수 있습니다. 그러므로 어떤 방식은 형식적 적용 범위에서는 좋은 점수를 받으면서도, 보호하려던 사람들이 마주치는 위험을 오히려 악화시킬 수 있습니다. 확인 건수나 차단 요청 수를 세는 것은 안전을 측정하는 것과 같지 않습니다.

관할권이 문제를 증폭시킵니다. 각국이 서로 다른 제출 요건, 인증 공급자, 집행 장소를 요구하면 서비스는 모든 변형을 구축하기보다 철수할 수 있습니다. 명목상 국지적인 규칙이 접근의 전 세계적 형태를 바꿉니다. 조각화는 지도 위에 그려진 정책 불일치에 그치지 않고, 사라진 서비스, 호환되지 않는 클라이언트, 동일한 인터넷을 통과하는 불평등한 경로가 됩니다.

일곱 가지 속성이 신호를 좁힌다

성명은 어떤 기술이 선택되든 살아남아야 할 일곱 가지 속성을 제시합니다. 이 방식은 목적별 연령 신호 이상을 공개해서는 안 됩니다. 사용자의 활동을 보고해서는 안 됩니다. 신호는 사이트 간에 연결될 수 없어야 합니다. 연령을 확인한 주체는 그 사람이 어떤 사이트를 방문하는지 알아서는 안 됩니다. 설계는 중앙화된 민감 데이터 저장소를 만들어서는 안 되고, 어떤 연령대의 사용자에게든 다른 중대한 해나 부담을 가해서는 안 되며, 폐쇄형 인터페이스에 의존해서는 안 됩니다.

함께 보면 이 속성들은 분리를 기술하며, 새로운 신원 슈퍼 서비스를 기술하지 않습니다. 발급자는 속성을 확인할 만큼은 알 수 있지만 열람 일지를 얻어서는 안 됩니다. 서비스는 한 연령 규칙을 적용할 만큼은 알 수 있지만 자동으로 시민 신원을 받아서는 안 됩니다. 두 서비스는 자신들의 신호를 내구성 있는 사이트 간 식별자로 합칠 수 없어야 합니다. 구현은 결과를 전달할 수 있지만, 발급자, 관찰자, 정책 선택자, 전면 관문을 조용히 하나의 장부에 합쳐서는 안 됩니다.

“최소”라는 단어에도 스키마가 필요합니다. 하나의 제한 기능에 대한 이진 기준값이 생년월일, 정확한 나이, 신분증 종류, 가구 관계, 이전 검증 이력을 노출할 권한은 아닙니다. 목적 제한은 필드와 프로토콜 수준에서 검증 가능해야 합니다. 그렇지 않으면 최소화는 더 많은 것을 드러내는 페이로드 위에 쓰인 약속에 머뭅니다.

개방형 인터페이스 역시 구체적입니다. 하나의 클라이언트에 대한 소스 코드 공개는 상호운용 가능한 계약과 같지 않습니다. 쓸모 있는 표준에는 요청과 응답에 대한 공통 의미론, 버전 협상, 오류 동작, 개인정보 속성, 적합성 시험, 독립 구현 경로가 필요합니다. 서비스가 추론할 수 있는 것과 발급자, 기기, 중개자가 알아서는 안 되는 것을 명시해야 합니다.

이 속성들 중 어느 것도 정책 자체가 현명하다는 것, 방식이 아동을 효과적으로 보호한다는 것을 증명하지 않습니다. 이들은 연령 기반 규칙을 선택한 관할권을 위한 아키텍처 제약을 세울 뿐입니다. 이 경계가 중요합니다. 엔지니어링 조언는 권한 부여를 주장하지 않고도 어떤 명령이 위험을 만드는지 보여줄 수 있습니다.

신원을 로컬에 둘 수 있어 기기 경로가 유망하다

IAB는 현재 기술 성숙도를 감안할 때 기기 기반 방식이 가장 유망하다고 평가합니다. 이 단서가 중요합니다. “가장 유망”은 “선택됨”도 “입증됨”도 아닙니다. 어떤 프로토콜, 운영체제, 브라우저, 자격 발급자, 공급자도 이 성명에서 승인되지 않았습니다.

매력은 분명합니다. 사용자는 기기에 보관된 맥락에서 연령 속성을 한 번 확인하고, 이후 서비스에는 필요한 좁은 신호만 건네줄 수 있습니다. 서비스는 전체 신원을 받지 않고, 발급자는 각 목적지를 알지 못하며, 반복 확인은 동일한 중앙화된 흔적을 만들지 않습니다. 사용자가 소유한 하드웨어가 모든 거래를 지켜보는 중개자의 서버 대신 교환을 중개할 수 있습니다.

이것은 통제가 없는 아키텍처가 아니라 다른 통제 구조입니다. 기기 플랫폼은 어떤 인증 방식이 자격을 갖는지, 가구 역할을 어떻게 표현하는지, 대체 브라우저가 동등한 접근을 받는지, 오류를 어떻게 항소하는지, 어떤 관할권을 지원하는지 결정할 수 있습니다. 인터페이스를 갱신하거나 버전을 퇴역시킬 수도 있습니다. 서비스는 결과에 얼마나 무게를 둘지 결정합니다. 발급자는 여전히 수용 가능한 증거가 없는 사용자를 배제할 수 있습니다.

공유 기기는 이 간극을 빨리 드러냅니다. 여러 가족 구성원이 쓰는 태블릿은 기기를 한 사람의 연령과 동일시할 수 없습니다. 한 가구에는 서로 다른 법적 규칙과 안전 요구를 가진 어른, 10대, 어린이가 함께할 수 있습니다. 프로필 전환이 혼란스럽거나 불가능하거나 쉽게 우회된다면, 우아한 개인정보 모델은 일상 사용에서 실패합니다. 그래서 성명은 이를 제품의 광택이 아니라 강력한 다중 사용자 지원으로 명시적으로 지적합니다.

개방형 인터페이스 조건이 기기 중개가 기기 주권이 되는 것을 막습니다. 적합한 어떤 기기, 운영체제, 브라우저든 이 교환을 구현할 수 있어야 합니다. 웹사이트는 정의된 신호를 요청해야 하며, 한 플랫폼의 계정, 월렛, 독점 검증 의례를 요구해서는 안 됩니다. 이 구분은 API 다이어그램에서는 작지만 시장에서는 헌법적입니다. 하나는 구현이 경쟁하게 하고, 다른 하나는 컴플라이언스를 유통상의 이점으로 바꿉니다.

워크숍 보고서와 IAB 성명은 서로 다른 기록이다

IAB와 W3C는 2025년 10월에 워크숍을 개최했습니다.공식 그룹 페이지에 따르면 그 목적은 기술적·아키텍처적 선택을 검토하고 공동 이해를 쌓는 것이었으며, 단일 후보 해법을 반드시 찾는 것이 아니었습니다. 고려 요인에는 개인정보, 형평성, 중앙화, 우회, 비용, 정확성, 관할권, 검열이 포함되었습니다.

논문 공모도 범위 경계를 표시했습니다. 어떤 콘텐츠를 제한해야 하는지에 대한 규제 선택은 범위 밖이었고, 워크숍은 제한이 인터넷과 웹 아키텍처와 상호작용하는 방식에 초점을 맞췄습니다. 참가는 초청에 의해, 수정된 채텀하우스 규칙 아래 이루어졌고, 약속된 산출물은 보고서였습니다.

그 보고서가 2026년 6월RFC 9998이 되었습니다. 이는 Internet Standards Track 사양이 아니라 IAB 스트림의 정보성 문서입니다. 더 중요한 것은, 기술된 견해는 참가자의 것으로 반드시 IAB나 W3C의 입장을 반영하지 않으며, 워크숍 합의의 주장으로 편집되지 않았다고 명시한다는 점입니다.

이 구분은 빌린 권위를 막습니다. 워크숍은 유용한 우려를 드러낼 수 있지만 그것을 기관적 결론으로 만들지는 않습니다. IAB는 나중에 어떤 분석을 정식 성명에 채택하거나, 다른 부분을 기각하거나, 문제를 다르게 틀 수 있습니다. 8월 24일 문서가 뉴스인 이유는 그것이 IAB 자체의 현재 입장이기 때문입니다. RFC 9998은 맥락과 증거를 제공하며, 모든 워크숍 기여를 그 입장으로 바꿔주는 지름길이 아닙니다.

RFC 7841은 스트림과 카테고리 라벨이 왜 중요한지 설명합니다. 모든 RFC가 표준 관련인 것은 아니고, 비-IETF 스트림 문서는 IETF 전체 Last Call과 IESG 승인을 거치지 않습니다. 내구성 있는 공개 기록은워크숍 관찰,IAB 성명,후보 사양,승인 표준,인증된 구현,법적 명령,배포를 별개 상태로 보존해야 합니다.

IAB는 접근을 입법하지 않고도 아키텍처를 조언할 수 있다

RFC 2850은 IAB를 IETF의 위원회이자 Internet Society의 자문기구로 정한다. 이 헌장은 이사회에 장기 아키텍처 감독, 표준 절차 감독, 항소, 연락, 조언 기능을 부여합니다. 또한 그 보고서가 IETF 커뮤니티와 IESG에 조언할 수 있는 워크숍을 상정합니다.

RFC 9281은 더 새로운 표준 절차 지도에서 동일한 역할 배분을 유지합니다. IAB는 아키텍처와 절차를 검토하고 일반적으로 기술적, 아키텍처적, 절차적, 정책적 조언을 제공합니다. IAB는 국가 입법부도, 서비스의 법적 의무를 담당하는 규제기관도 아닙니다.

이 한계가 성명을 약하게 만들지는 않습니다. 조언은 의존성이 굳어지기 전에 결정을 바꿀 만큼 시의적절할 때 가치가 있습니다. IAB는 기술별 명령이 암호화에 압력을 가하거나 신원을 중앙화한다는 것을 보여줄 수 있지만, 그 명령을 제정하거나 폐지할 권한은 주장하지 않습니다. 규제자는 공개적 결과를 지정하면서 합법성, 범위, 구제, 효과에 대한 책임을 유지할 수 있습니다. 표준 기구는 상호운용 가능한 인터페이스를 정의합니다. 벤더는 그것을 구현합니다. 서비스는 합법적 규칙을 적용합니다. 사용자는 오류를 니닐 수 있습니다.

각 주체는 자신의 행위만 증명할 수 있으므로 역할에는 별도의 수령증이 필요합니다. IAB 성명은 아키텍처 입장을 증명합니다. 표준 문서는 사양이 이름이 붙은 지위에 도달했음을 증명합니다. 인증은 구현이 명시된 시험을 통과했음을 증명합니다. 법률은 입법부가 한 관할권을 위해 문안을 제정했음을 증명합니다. 운영 증거는 방식이 측정된 조건에서 작동했음을 증명합니다. 어떤 배지도 다른 것을 대체할 수 없습니다.

RFC 3935가 마지막 제약을 더합니다. IETF 표준은 적합성을 주장할 때 무언가를 수행하는 방법을 기술하지만, 사용을 명령하거나 감시하지 않습니다. 미래의 연령 신호 표준조차 그 자체로 법적 권한, 정책적 현명함, 성공적인 배포를 확립하지 않습니다.

개방형 인터페이스에는 대체 수령증이 필요하다

IAB는 서둘러 배포된 시스템이 경제적 인센티브와 광범위한 의존성이 형성된 뒤에는 제거하기 어려워진다고 경고합니다. 인터넷 아키텍처에서 IAB는 이를 골화(ossification)라고 부릅니다. 결과 기반 명령과 상호운용 인터페이스는 더 나은 방식이 성숙하면 그 자리를 남겨두기 위한 것입니다.

그 원칙은 대체가 입증될 때만 작동합니다. Daniel Kade가 제안한 수령증은 다섯 부분이 연결되어 있습니다.

첫째, 결과를 공급자와 무관하게 정의합니다. 어느 사용자, 서비스, 관할권이 범위에 드는지, 어떤 접근 결과가 요구되는지, 어떤 안전상 이익이 기대되는지, 어떤 오류 및 항소 의무가 적용되는지. “벤더 X를 쓴다”는 결과가 아닙니다.

둘째, 신호 계약을 지문으로 남깁니다. 최소 필드, 기준값 의미론, 결합 맥락, 수명, 재전송 방어, 비연결성 속성, 버전, 실패 상태. 후속 구현은 사적인 신원 저장소를 복제하지 않고 동일한 공개 계약을 구현할 수 있어야 합니다.

셋째, 구현 다양성을 시험합니다. 적어도 두 개의 독립적으로 통제된 기기, 운영체제 또는 브라우저가 적합한 신호를 생성하거나 전달할 수 있어야 합니다. 서비스는 각각을 위해 별도의 독점 통합을 필요로 해서는 안 되고, 대체 구현이 기존 사업자의 계정 체계가 없다는 이유만으로 법적 인정을 잃어서는 안 됩니다.

넷째, 마이그레이션을 시험합니다. 인증 공급자, 기기, 브라우저를 따로따로 바꿔보십시오. 신원 제출이 확대되는지, 가구 상태가 안전하게 유지되는지, 서비스가 신호를 계속 해석하는지, 사용자가 항소 경로를 유지하는지, 기존의 상관 분석 식별자가 무용해지는지 관찰하십시오. 첫 공급자 교체 전에만 작동하는 표준은 문서화된 문법이지 상호운용성이 아닙니다.

다섯째, 검토 트리거를 붙입니다. 높은 오판 거부, 침해 집중, 차별적 배제, 비효율적인 안전, 암호화 압박, 서비스 철수, 과도한 공급자 집중의 증거는 구현 선택을 다시 열어야 합니다. 이 트리거는 아동 안전을 버리겠다는 약속이 아닙니다. 동일한 목표를 덜 유해한 방식으로 달성할 수 있는 능력을 보호합니다.

수령증은 주장할 수 있는 것도 제한합니다. 통과했다고 해서 모든 사용자가 안전하다거나, 모든 관할권이 동의하거나, 우회가 끝났다는 것이 증명되지 않습니다. 보여지는 것은 더 좁지만 본질적인 것입니다. 공개적 결과가 하나의 기술적 통제자의 인질이 아니라는 것입니다.

출처

  1. IETF Datatracker: IAB 연령 기반 제한 및 온라인 안전 성명
  2. IETF 공지 메일링 리스트의 IAB 성명 사본
  3. IAB 공지 색인
  4. IETF Datatracker: IAB 성명 등록부
  5. RFC 9998: IAB/W3C 콘텐츠 접근 연령 기반 제한 워크숍 보고서
  6. RFC 9998의 RFC Editor 지위 페이지
  7. RFC 9998에 대한 IAB 공지
  8. IETF Datatracker: AGEWS 워크숍 기록
  9. AGEWS 워크숍을 위한 IAB 논문 공모
  10. RFC 7754: 인터넷 서비스 차단 및 필터링을 위한 기술적 고려사항
  11. RFC 7754의 RFC Editor 지위 페이지
  12. RFC 2850: Internet Architecture Board 헌장
  13. RFC 9281: IETF 표준 절차에 관여하는 주체들
  14. RFC 3935: IETF의 사명 선언문
  15. RFC 7841: RFC 스트림, 헤더 및 보일러플레이트