Notion 공개 페이지에서 모든 편집자의 이메일 주소가 노출되는 문제

Who Should Read

Notion을 팀 협업 도구로 사용하면서 공개 페이지를 운영하거나 직원들이 편집에 참여하는 기업의 개발자 또는 IT 담당자. 특히 이메일 주소 노출이 스팸, 피싱, OSINT(공개 출처 정보 수집) 공격으로 이어질 수 있어 보안을 신경 쓰는 팀에게 즉시 확인이 필요하다.

Core Mechanics

• Notion에서 페이지를 웹에 공개(publish to web)하면, 그 페이지의 HTML 메타데이터에 해당 페이지를 편집한 모든 Notion 사용자의 이름, 프로필 사진, 이메일 주소가 자동으로 포함된다.
• 이 동작은 Notion 공식 문서(help/public-pages-and-web-publishing)에 작은 주석 형태로 문서화되어 있었으나, 사용자들이 인지하기 매우 어려운 위치에 묻혀 있었다.
• Notion의 Max라는 직원이 HN에 직접 댓글을 달아 '문서화되어 있고 게시 시 경고도 하지만, 그것만으로는 충분하지 않다'고 인정했다. 현재 공개 API 엔드포인트에서 개인정보(PII)를 제거하거나 GitHub처럼 이메일 프록시 방식으로 대체하는 방향을 검토 중이라고 밝혔다.
• 이 문제는 최소 5년 이상 존재해 온 것으로, HN 커뮤니티의 한 사용자는 5년 전에 자신의 Notion 공개 페이지를 통해 익명이 해제(deanonymized)된 경험이 있다고 공유했다.
• Notion 측은 '1분짜리 수정'이라는 일부 추측에 대해 그렇지 않다고 직접 해명했다. 내부적으로 수정이 간단하지 않음을 시사한 것으로, 데이터 구조나 API 호환성 문제가 얽혀 있을 가능성이 있다.
• 이 문제는 단순히 Notion만의 이슈가 아니라, 서버가 사용자 데이터를 중앙 집중적으로 저장하는 구조 자체의 근본적인 한계라는 시각도 있다. 한 사용자는 '데이터를 애초에 저장하지 않는 것이 올바른 해결책'이라며, 사용자별로 데이터를 분산 저장하는 아키텍처를 고민했으나 그룹 협업, 오프라인 대응, 스크래핑 방지 등의 문제로 현실적으로 매우 어렵다고 분석했다.

Evidence

• Notion의 직원 Max가 직접 HN에 댓글을 달아 문제를 공식 인정했다. '문서화되어 있고 게시 시 경고도 하지만 그것만으로는 충분하지 않다'며, 공개 엔드포인트에서 PII(개인 식별 정보)를 제거하거나 GitHub의 이메일 프록시 방식을 도입하는 방향을 검토 중이라고 밝혔다.
• 이 문제가 최소 5년간 존재했다는 경험담이 공유됐다. 한 HN 사용자는 5년 전 자신의 Notion 공개 페이지를 통해 익명이 해제된 적이 있다고 직접 언급했으며, 이는 이 취약점이 오래된 문제임을 보여준다.
• 공식 문서에 이미 안내가 되어 있다는 점을 두고 '그럼 괜찮은 거 아니냐'는 시각과, '아무도 못 보는 구석에 숨겨놓은 건 고지라고 볼 수 없다'는 반론이 맞섰다. 대부분의 커뮤니티 반응은 후자 쪽에 동의하는 분위기였다.
• '1분이면 고칠 수 있는 것 아니냐'는 의견에 대해 Notion 직원이 직접 그렇지 않다고 해명했다. 구체적인 이유는 밝히지 않았지만, 이미 공개된 API나 데이터 구조와의 호환성 문제가 있을 것으로 추측되었다.
• 일부 사용자들은 이번 사건을 계기로 Notion이 'AI 올인원 앱'으로 방향을 바꾼 것에 대한 실망감을 표출했고, 보안과 프라이버시보다 기능 추가에 집중하는 SaaS 서비스 전반의 문제를 지적하는 댓글도 달렸다.

How to Apply

• 현재 Notion 공개 페이지를 운영 중이라면, 해당 페이지의 HTML 소스나 메타데이터를 직접 확인해서 편집자들의 이메일 주소가 노출되고 있는지 즉시 점검해야 한다. 노출이 확인되면 해당 페이지를 비공개로 전환하거나, 편집자를 별도의 워크스페이스 계정으로 분리하는 조치를 먼저 취하는 것이 안전하다.
• 회사 직원들이 편집한 Notion 페이지가 외부에 공개되어 있다면, 직원들의 회사 이메일 주소가 수집되어 스피어 피싱(특정 대상을 노린 피싱)이나 스팸 공격에 악용될 수 있다. 공개 페이지 목록을 감사(audit)하고, 불필요한 공개 설정을 즉시 비공개로 되돌리는 것을 권장한다.
• Notion API나 공개 페이지를 활용한 서비스를 개발 중이라면, 현재 API 응답에 포함된 사용자 정보 필드를 재확인하고, 이 정보를 외부에 그대로 노출하는 코드가 없는지 점검해야 한다. Notion이 향후 이메일 프록시 방식으로 변경할 경우 API 응답 구조가 바뀔 수 있으므로, 관련 변경 공지를 주시할 필요가 있다.

Terminology

관련 논문

• Mindwalk – 코딩 에이전트 세션을 코드베이스 3D 맵 위에서 재생하는 시각화 도구

  Claude Code나 Codex 같은 AI 코딩 에이전트가 세션 중 코드베이스의 어떤 파일을 탐색하고 수정했는지를 3D 지도 형태로 시각화해서 재생해주는 로컬 도구다. 에이전트가 작업을 어떻게 이해했는지 한눈에 파악할 수 있다.

• Ghost Font: 사람은 읽을 수 있지만 AI는 읽기 어려운 안티-AI 폰트 실험

  움직임(모션)을 이용해 글자를 표현해서 AI 모델이 정적 이미지 분석으로는 메시지를 해독하지 못하게 막는 실험적 프로젝트인데, 커뮤니티에서는 이미 GPT-5.6, Claude Opus 등으로 해독에 성공한 사례가 속출해 실효성 논쟁이 뜨겁다.

• GPT-5.6, Grok 4.5, Claude, Muse Spark 등 12개 모델이 동일한 앱 4개를 빌드한 결과 비교

  12개 LLM 모델에게 레이캐스터 미로, 루빅스 큐브, 계산기, Game of Life 앱을 각각 5번씩 만들게 해서 성공률·비용·속도를 비교한 실전 벤치마크다. GPT-5.6 Sol이 전반적으로 가장 일관된 결과를 냈고, Grok 4.5는 가성비 면에서 눈에 띄었다.

• Databricks가 수백만 라인 실제 코드베이스로 Coding Agent를 벤치마킹한 결과

  Databricks가 자사 실제 코드베이스를 기반으로 여러 AI 코딩 에이전트의 성능과 비용을 직접 측정했고, 모델 토큰 가격과 실제 태스크 비용이 전혀 다르다는 점, 그리고 오픈소스 모델이 이제 최상위 수준에 도달했다는 점을 확인했다.

• Reasoning에서 Uncertainty 추정하기: LLM의 다국어 및 교차언어 MCQA 성능 대규모 연구

  LLM이 저자원 언어 질문을 받을 때 영어로 추론하게 하면 불확실성 추정 성능이 고자원 언어 수준으로 올라온다.

• LLM-as-a-Verifier: 범용 Verification 프레임워크

  LLM의 토큰 확률 분포를 활용해 discrete 점수 대신 continuous 점수를 뽑아내면, 추가 학습 없이 코딩·로봇·의료 에이전트 평가 정확도를 SOTA로 끌어올릴 수 있다.

Related Resources

• 원본 트윗 (weezerOSINT)
• Notion 공식 문서 - Public pages and web publishing