위키미디어 재단 연간 계획/2025-2026년/제품 및 기술 OKR

This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 100% complete.

앞으로의 1년

세상이 변하고 있지만, 위키미디어 재단은 우리의 사명, 즉 위키미디어 프로젝트의 유용한 정보를 인터넷에서 무료로 제공하고 유지하는 것이 여러 세대에 걸친 노력이 되기를 바란다는 것을 확신합니다. 우리는 앞으로도 많은 세대가 무료 지식을 계속 이용할 수 있기를 바랍니다.

인터넷은 빠르게 변화하고 있습니다. 새로운 세대는 소셜 비디오와 AI 경험을 통해 정보를 얻고 있으며, 이전 세대에 비해 위키백과를 아는 사람이 적습니다. 우리는 우리 사이트를 방문하는 사람의 수와 편집하는 사람의 수가 감소하는 것을 보고 있습니다. 한편, 인터넷 전반의 플랫폼은 AI와 검색 서비스를 뒷받침하기 위해 위키미디어 콘텐츠에 의존하고 있습니다. 이러한 역학 관계는 주요 과제이지만, 우리가 함께 만드는 신뢰할 수 있는 무료 지식이 왜 그렇게 중요한지 분명히 보여줍니다. 세상은 그 어느 때보다 신뢰할 수 있고 인간이 검토한 지식의 출처가 필요하며, 위키미디어 프로젝트는 이를 제공할 수 있음을 계속해서 보여주고 있습니다.

내년에 이러한 과제에 대처하기 위해 우리는 지속 가능하게 위키미디어 콘텐츠를 활용할 수 있는 경로를 구축하고, 새로운 세대가 시간을 보내는 온라인 소셜 공간에 위키미디어 콘텐츠를 제공할 것입니다. 독자들이 다시 돌아와 깊이 관여하고 자신에게 의미 있는 방식으로 기여하고 싶어하도록 자체 사이트를 개선할 것입니다. 그리고 새로운 기술을 빠르게 실험할 수 있는 능력에 투자하여 개발 속도가 세상이 변화하는 속도에 맞출 수 있도록 할 것입니다.

인프라 목표는 플랫폼과 사용자 경험을 통해 이러한 과제를 해결하고 운동 참여자 대다수에게 도달하는 데 어떻게 기여할 것인가입니다. 이는 단순한 프로젝트 목록이 아니라, 자원봉사자 성장을 촉진하고, 자원봉사자들이 신뢰할 수 있는 백과사전적 콘텐츠를 제작할 수 있도록 지원하며, 우리의 사명에 자금을 지원하고, 변화하는 인터넷 환경에 맞춰 우리의 서비스를 발전시키기 위한 일련의 지침입니다. 네 가지 전략적 기둥에 대한 자세한 내용은 여기에서 확인하실 수 있습니다.

자원봉사자 성장에 연료 공급하기

자원봉사자 커뮤니티는 위키미디어 프로젝트 성공의 핵심 동력이며, 우리는 이 커뮤니티가 건강하고 성장하기를 바랍니다. 하지만 지난 한 해 동안 프로젝트에 참여하는 신규 및 기존 편집자 수가 지속적으로 감소하는 모습을 보였습니다. 재단은 기존 자원봉사자들의 요구를 더 잘 이해하고 더욱 효과적으로 대응하기 위해, 기존에 연 1회 실시하던 커뮤니티 위시리스트를 상시 접수 방식으로 개편했습니다. 이를 통해 사용자들의 요구와 프로젝트 아이디어가 재단의 여러 팀 업무에 반영될 수 있습니다. 희망 사항을 "중점 분야"로 분류하고, 그중 세 가지 중점 분야를 연간 계획의 주요 성과 항목에 통합했습니다. 또한, 재단 팀이 위키 안팎에서 커뮤니티 구성원들과 연중 나누는 수많은 대화를 보완하기 위해 시범적으로 제품 및 기술 자문 위원회를 구성했습니다. 또한, 젊은 세대가 공통된 관심사에 대해 쉽고 모바일 친화적인 방식으로 소통할 수 있는 다른 온라인 소셜 공간에 적극적으로 참여하고 있다는 점을 고려하여, 프로젝트에 새로운 세대를 참여시킬 수 있는 기회를 모색했습니다.

내년에는 모바일 우선의 새로운 편집 방식("구조화된 작업")을 확대하고 새로운 기여자가 생산적인 모바일 편집을 쉽게 할 수 있도록 하는 지능형 워크플로("편집 확인")를 추가하여 새로운 세대가 기여를 더 쉽고 매력적으로 느낄 수 있도록 하여 자원봉사자 성장을 촉진할 것입니다. 기존 자원봉사자의 참여를 높이고 유지하기 위해 권장하는 작업과 작업을 제공하고 위키 활동을 쉽게 구성할 수 있는 중앙 허브에 표시할 것입니다. AI를 신중하게 사용하여 자원봉사자의 작업을 강화하고 항상 사람에게 정보를 제공하고 투명성을 우선시할 것입니다. 신규 및 숙련된 자원봉사자 모두를 위해 성공적인 캠페인과 위키프로젝트에서 영감을 받아 사이트에서 연결하고 함께 작업할 수 있는 길을 구축하여 마음이 맞는 편집자를 찾고 관심사와 관련된 콘텐츠를 개선할 수 있도록 할 것입니다(이 위시리스트 중점 영역과 일치).

신뢰할 수 있는 백과사전적 콘텐츠 제공

AI가 생성하는 콘텐츠가 인터넷에서 급증함에 따라, 세상은 그 어느 때보다 신뢰할 수 있는 백과사전적 콘텐츠를 필요로 합니다. 저희는 자원봉사자들이 새로운 콘텐츠를 제작하고, 기존 콘텐츠의 신뢰성을 유지하며, 새로운 요구와 선호도를 가진 새로운 세대의 독자들에게 신뢰할 수 있는 콘텐츠를 제공할 수 있는 역량을 강화하고자 합니다.

자원봉사자들이 새로운 콘텐츠를 제작할 수 있도록 기존의 가이드 도구와 워크플로(예: 콘텐츠 번역 도구)를 기반으로 구축하여 크고 작은 커뮤니티 모두 중요한 콘텐츠를 다룰 수 있도록 할 것입니다. 기존 콘텐츠의 신뢰성을 유지하기 위해, 숙련된 자원봉사자들이 주의가 필요한 작업을 찾는 데 사용하는 도구를 확장하여 증가하는 업무량을 더 잘 관리할 수 있도록 지원할 것입니다. 이를 통해 자원봉사자들이 더 쉽게 문서를 업데이트하고 도움이 되지 않는 수정 사항을 되돌릴 수 있게 됩니다(이 위시리스트 중점 영역과 일치).

또한 IP 주소 이외의 새로운 신호를 표면화하여 악의적인 행위자를 식별하고, 선의의 편집자를 잘못 차단하는 것을 최소화하는 방식으로 사용자를 차단하여 담당자가 콘텐츠를 방어할 수 있도록 돕겠습니다.

새로운 세대에게 백과사전적인 콘텐츠를 제공하기 위해, 새로운 유형의 독자들이 문서를 쉽게 이해하고, 관심 있는 정보를 찾을 수 있도록 돕고, 독서에 적극적으로 참여할 수 있도록 돕는 기능을 구축할 것입니다. 이러한 변화는 새로운 위키백과 독자들이 헌신적인 위키백과 독자가 되고, 일부는 기부자가 되도록 장려하기 위한 것입니다(이 위시리스트 중점 분야와 연계).

신뢰할 수 있는 콘텐츠를 제공한다는 것은 또한 전체 인터넷이 위키미디어 콘텐츠를 활용하는 "지식 서비스" 모델을 지원하는 것을 의미합니다. 이 모델에서 우리의 인프라는 우리 웹사이트에 오는 사람들에게 귀중한 리소스일 뿐만 아니라 검색 및 AI 회사에도 귀중한 리소스이며, 이들은 자사 제품에 대한 기초적인 입력 및 출력으로 우리의 콘텐츠에 자동으로 액세스합니다. 이런 종류의 회사는 우리 인프라에 지속 불가능한 부하를 점점 더 가하는 여러 용도 중 하나일 뿐입니다. 작년에 스크래퍼 도구와 봇에서 오는 요청 볼륨이 크게 증가하면서 이러한 추세를 바로잡는 것이 더욱 시급해졌습니다. 우리는 개발자와 재사용자가 지식 콘텐츠에 액세스할 수 있는 지속 가능한 경로를 확립하여 봇보다 인간이 우선시되도록 해야 합니다.

'무료'의 미래에 자금 지원

제품 및 기술 부서는 우리 운동이 지속 가능하도록 하는 데 중요한 역할을 합니다. 내년에는 기금 모금 팀과 긴밀히 협력하여 기부자들이 점점 더 명확하고 보람 있는 경험을 할 수 있도록 할 것입니다. 사이트와 모바일 앱에서 독자들이 기부를 통해 위키백과에 대한 감사를 표현할 수 있는 기회를 구축하고 기부자들이 인정받는다고 느낄 수 있는 새로운 방법을 구축하여 매년 기부를 계속할 수 있도록 할 것입니다.

변화하는 인터넷 형성

전 세계 모든 사람에게 무료 지식을 제공하기 위해, 우리는 그들이 있는 곳에서 그들이 학습하는 데 도움이 되는 경험을 제공해야 합니다. 18~24세의 사람들은 이전 세대보다 위키백과에 대한 인지도와 사용률이 낮습니다. 그들은 주로 단편 비디오 플랫폼, 신뢰할 수 있는 온라인 인물, 소셜 게임 경험, 그리고 점점 더 늘어나는 AI 애플리케이션에서 배우고 상호 작용합니다. 올해, 우리는 이러한 청중이 온라인에서 시간을 보내는 장소에서 위키백과를 사용할 수 있도록 하여 위키백과를 신뢰할 수 있고 인간이 만든 지식의 출처로 알 수 있도록 할 것입니다. 우리는 인기 있는 비디오 플랫폼에서 우리의 입지를 확대하고, 위키백과 콘텐츠를 확산하고, 그러한 공간에서 커뮤니티를 생성할 것입니다. 그리고 우리는 위키백과 지식을 게임 및 소셜 플랫폼으로 가져오기 위한 아이디어를 탐구할 것입니다.

인프라 내에서는 위키 경험, 신호 및 데이터 서비스, 그리고 미래 사용자라는 세 가지 작업 포트폴리오(버킷)로 나뉩니다. 이 버킷은 작년과 재작년과 동일합니다.

이 모든 것을 종합해 볼 때, 우리는 이 계획이 인터넷 역사상 중요한 순간을 맞이하여 모든 세대가 무료 지식 콘텐츠를 계속 접하고 형성할 수 있도록 준비했다고 믿습니다. 우리의 목표와 주요 결과는 이 계획의 구조와 내용을 더 자세히 보여주며, 더 광범위한 커뮤니티에서 질문과 아이디어를 듣기를 기대합니다.

우리의 가치에 기반한 위키미디어 프로젝트와 자원봉사자를 위한 인프라 구축, 개선 및 유지

"재단은 해당 프로젝트에서 얻은 유용한 정보를 영구적으로 무료로 인터넷에 공개하고 보관할 것입니다."

제품 및 기술 팀은 위키미디어 프로젝트를 지원하는 인프라를 구축, 개선 및 유지하는 데 연중 내내 지속적인 우선순위를 두고 있습니다. 위키미디어 프로젝트 호스팅, 오픈소스 소프트웨어 및 디자인 시스템 개발, 그리고 데이터 제품 및 AI 모델 인프라의 유지 및 개선에 투자합니다.

저희의 핵심 업무 중 일부는 대규모 인기 웹사이트 개발 및 호스팅의 기본 원칙에 집중되어 있습니다. 저희는 위키미디어 프로젝트를 저희가 직접 구매, 설치, 관리하는 서버와 하드웨어를 통해 데이터 센터에 호스팅합니다. 이 서버와 하드웨어는 고속 네트워크를 통해 서로 연결되고 인터넷 전체와도 연결됩니다. 필요한 경우 용량을 모니터링하고 추가하며, 노후화된 장비는 교체합니다. 예를 들어, 올해는 버지니아주 애쉬번과 텍사스주 캐롤턴에 있는 데이터 센터의 용량을 확장하고 하드웨어를 교체할 계획입니다.

저희는 오픈 소스 소프트웨어(특히 미디어위키)를 설계하고 개발합니다. 또한 기존의 다양한 제3자 오픈 소스 애플리케이션, 라이브러리 및 프레임워크를 사용하고 배포합니다. 소프트웨어의 중요한 버그는 우선순위에 따라 수정합니다. 오픈 소스 소프트웨어를 유지 관리하려면 오픈 소스 소프트웨어 개발, 사이트 안정성 엔지니어링(SRE), 제품 관리, 프로그램 관리, 디자인 등에 대한 전문 지식을 갖춘 고도로 숙련된 인력이 필요합니다. 저희 직원들은 소프트웨어와 시스템을 최신 상태로 유지하고 끊임없이 변화하는 환경에 적응하기 위해 노력합니다. 여기에는 보안 패치의 이점을 계속 누리고 새로운 타사 소프트웨어와 원활하게 작동하도록 코드를 현대화하는 작업이 포함됩니다. 예를 들어, 미디어위키는 PHP로 작성되었으며, 작년에 PHP 7.4에서 8.1로 마이그레이션하면서 코드와 사이트 및 서비스를 호스팅하는 인프라를 모두 변경해야 했습니다. 올해는 이러한 노력을 바탕으로 8.1 업그레이드에서 얻은 교훈과 개발된 도구를 활용하여 8.3으로 마이그레이션할 것입니다. 업데이트를 통해 독자에게는 시스템 속도가 빨라지고, 직원과 자원봉사자에게는 사용이 편리하며, 모든 사용자에게는 보안이 강화될 것입니다. 또한 언어 업데이트와 함께 제공되는 보안, 성능 및 지원 개선을 통해 향후 개발 시간도 단축될 것입니다.

프로젝트와 콘텐츠가 현재와 앞으로도 인터넷에서 계속 이용 가능하도록 하기 위해 저희 팀은 사이트와 서비스의 고가용성을 보장하기 위해 상당한 노력을 기울이고 있습니다. 이러한 노력의 한 측면은 재해 또는 악의적인 이벤트 발생 시 재해 복구에 중점을 두고 있습니다. 예를 들어, 중요한 데이터의 백업을 유지하고 이를 통해 복구할 수 있도록 보장합니다. 마찬가지로, 연 2회 데이터 센터 간 사이트 전환을 자동화하고 발견된 문제를 해결하는 능력을 테스트합니다. 또한, 유입되는 트래픽 유형과 양의 변화하는 추세를 파악하고 이에 적응하는 데 중점을 두고 있습니다. 예를 들어, 자동 스크래퍼가 전례 없이 증가함에 따라, 저희는 인프라의 책임 있는 사용에 대한 규범을 수립하기 위해 체계적인 접근 방식을 취하고 있으며, 사이트와 서비스에 대한 인간 사용자의 접근을 보장하는 데 우선순위를 두고 있습니다.

모든 작업이 사전에 계획되는 것은 아닙니다. 사이트 중단, 보안 보고서 또는 보안 사고, 또는 프로젝트에 대한 대규모 문서 훼손 공격과 같은 예상치 못한 새로운 이벤트 및 사건에도 대응합니다. 전 세계적으로 성능과 접근성 장애(인터넷 연결 문제 또는 검열 차단 포함)를 모니터링하고 발견되는 모든 이상 징후를 조사합니다. 이러한 예상치 못한 사건이나 반복적인 문제 패턴으로 인해 직원들은 추가적인 부정적인 영향을 완화하거나 완전히 방지하기 위한 단기 후속 프로젝트를 우선시합니다. 예를 들어, 이러한 노력은 성능 최적화, 병목 현상 영역의 아키텍처 재설계, 그리고 용량 증가를 통해 위키미디어 프로젝트가 주요 뉴스 이벤트(예: 유명 인사 사망)로 인한 전 세계 트래픽 급증을 견뎌낼 수 있도록 하는 데 매우 중요했습니다. 마찬가지로, 최근 트래픽 관리를 위한 도구 및 시스템의 사용성이 개선되어 변화하는 상황에 더욱 빠르고 효과적으로 대응할 수 있게 되었습니다. 이러한 적응형 작업은 종종 단기간에 발생하는 새로운 이벤트에 대응하고 프로젝트와 콘텐츠의 가용성을 유지하는 데 필수적입니다.

제품 및 기술 목표

여기에 제시된 목표는 초안 형태이며, 의견 제시 및 토론을 위해 열려 있습니다.

목표는 높은 수준의 방향을 나타냅니다.
"주요 결과"(KR)는 목표 달성의 성공 여부를 추적하는 측정 가능한 방법을 나타냅니다.
각 KR에 대한 기본 "가설"은 연관된 주요 결과를 달성하기 위해 우리가 시도하는 실제 작업을 나타냅니다. 이는 이 문서와 관련 프로젝트 또는 팀의 위키 페이지에서 일년 내내 통찰력을 얻음에 따라 업데이트됩니다.
는 재단이 커뮤니티 위시리스트에서 우선시하는 작업을 나타냅니다.

위키 경험 (WE)

기여자 경험 (WE1)

목표: 자원봉사자들에게 매력적인 기회가 제공되고 자신의 영향력을 이해하게 되면서 기여도가 높아집니다. 토론
- 맥락: 이 목표는 3가지 기둥으로 구성된 새로운 기여자 전략을 실현하기 위한 기반이 될 것입니다. 1) 자원봉사자에게 위키 내 활동을 구성할 수 있는 중앙화된 방법 제공, 2) 자원봉사자가 잠재력을 발휘할 수 있도록 더 작고 개별적인 작업 제공, 3) 기여를 더 의미 있게 만들기. 2025/26년 회계연도에는 자원봉사자들이 위키 활동을 중앙 집중적으로 구성할 수 있도록 돕는 기본 인프라를 제공할 계획이며, 특히 숙련된 편집자와 관리자에게 초점을 맞춘 개입을 시작할 것입니다. 이후 몇 년 동안 모든 기여자 역할에 개입을 추가하고 더 많은 문제 공간을 포함할 것입니다. 또한 편집 확인 및 구조화된 작업에 계속 투자하여 확장 가능한 방식으로 AI를 사용하는 방법에 대한 기반을 구축할 것입니다. 편집 프로세스 중 가이드로, 그리고 자원봉사자들에게 매력적인 기회를 제시하는 방법으로 사용할 것입니다. 마지막으로 자원봉사자들이 미치는 영향을 더 잘 보이게 하여 그들에게 더 의미 있는 경험을 제공하는 데 투자할 것입니다.
  - 주요 결과 WE1.1: 누적 편집 수가 ≤100인 편집자가 모바일 웹에 건설적인 편집을 게시하는 비율을 [i] 통제된 실험을 통해 측정한 결과 4% [ii] 증가시킵니다(2분기 말까지).
    - i. "건설적 편집" = 게시된 후 48시간 이내에 되돌려지지 않은 위키백과 주요 이름공간의 페이지에 대한 편집입니다.
    - ii. T389403#10960480
    - 신규 자원봉사자들은 편집을 성공적으로 시작하는 데 어려움을 겪습니다. 특히, 화면 공간이 제한적이고 주의가 종종 분산되는 모바일 기기를 사용하는 사람들입니다.
    - 어떤 사람들은 건설적으로 기여하는 데 필요한 맥락, 인내심, 시행착오에 지쳐 있습니다. 다른 사람들은 아직 시도할 수 있는 강력한 기회를 만나지 못했습니다.
    - WE 1.1은 다음을 통해 이러한 문제를 해결할 것입니다:
      - 편집 제안 표면화
      - 실행 가능한 편집 내 지침 제공
      - 더욱 구체적인 작업 편집 워크플로 구축
    - 이러한 노력의 핵심은 진행 중인 편집 내용과 기존 콘텐츠를 개선할 수 있는 방법을 감지하는 확장 가능한 방법의 필요성입니다. 이러한 역량을 강화하기 위해, 저희는 머신러닝을 지속적으로 실험하여 다양한 직종과 경력 수준에 걸쳐 편집자에게 최상의 서비스를 제공하는 방법을 학습할 것입니다.
    - 제안된 KR 점수 매기기 방법론: 플랫폼별로, 통제 실험을 통해 배포 및 평가한 개입 중 올해 초에 설정한 건설적 편집 목표를 충족하거나 초과한 개입의 비율을 계산할 것입니다. phab:T379285#10782051을 참고하여 아이디어를 얻어보세요.
      - 참고: 2025년 6월 30일 현재, WE 1.1에는 두 개의 통제된 실험이 계획되어 있습니다.
  - 주요 결과 WE1.2: 4분기 말까지 위키 협업 건수가 전년 동기 대비 55% 증가했습니다.
    - 기여자들은 종종 서로 협업할 기회를 찾는 데 어려움을 겪습니다. 특히 자신이 관심 있는 주제와 업무에 관한 협업에서 더욱 그렇습니다. 이는 신규 사용자에게 위키에서 혼자라는 느낌을 줄 수 있으며, 숙련된 편집자에게는 번아웃으로 이어질 수 있습니다. 또한 협업 활동의 영향은 종종 불분명하여 위키에서 협업에 참여하거나, 조직하거나, 지원하려는 사람이 줄어들 수 있습니다.
    - 우리는 다음을 수행하여 협력의 가치를 더 명확하게 알리고자 합니다:
    1. 위키에서 협업 활동의 영향을 공유하는 새로운 방법을 만듭니다.
    2. 협력 활동의 영향에 대한 운동 전반의 데이터 수집 시작
    3. 협업 기여를 추적하기 위한 기본 인프라를 설정하여 향후 기여를 인정하고 보상할 수 있는 혁신적인 새로운 방법을 제공할 수 있습니다.
    - 협업은 CampaignEvents 확장 프로그램에서 이벤트 등록을 통해 생성된 새로운 활동으로 측정됩니다. 목표는 이 KR이 끝날 때까지 확장 도구의 사용자가 늘어나고 협업 영향을 표면화하는 새로운 방법이 생길 것입니다. 이를 통해 기존 인프라를 위키에서 작업을 인정하고 보상하는 다른 방법(예: 영향 모듈, 감사 등)에 연결할 수 있는 좋은 위치에 놓이게 됩니다.
    - 위시리스트 중점 분야: 커뮤니티 위시리스트/중점 분야/기여자 연결
  - 주요 결과 WE1.3: 3분기 말까지 신규 관리자를 대상으로 한 홈페이지를 접한 기여자의 10%가 2주 연속으로 홈페이지를 방문했습니다.
    - 저희는 자원봉사자들에게 기여 기회를 더 효과적으로 제공할 수 있다고 믿습니다. 장기적으로는 홈페이지가 모든 편집자가 자신의 작업을 정리하고, 새로운 기회를 찾고, 그 영향을 이해하는 데 도움이 될 것이라고 생각합니다. 2025/26년 회계연도의 목표는 숙련된 편집자들이 평소에는 접하기 어려웠을 중재 업무를 맡을 수 있는 새로운 기회를 제공하는 것입니다.
    - 먼저, 경험이 풍부한 편집자들이 신규 편집자들과 마찬가지로 홈페이지에 얼마나 많이 참여하는지 파악하여 이 이론을 테스트해보겠습니다.
    - 그런 다음 해당 유형의 검토 작업을 처음 접하는 기여자에게 구체적인 검토 활동(자세한 내용은 추후 결정)을 표면화하여, 새로운 KR에 따라 백로그를 줄여 숙련된 편집자의 부담을 줄이는 것이 목표입니다.
    - 홈페이지 컨셉이 성공하면, 커뮤니티의 요구에 맞춰 이 페이지를 모듈화할 계획입니다. 이러한 모듈에는 편집자들이 자신의 영향력을 더 쉽게 이해할 수 있도록 하는 등의 기능이 포함될 수 있습니다.
    - 방법론에 대한 참고 사항:
    - 우리는 청중을 정의하기 위한 가설을 세울 것이며, 이는 WE1.3.1의 일부가 될 것입니다.
    - "감독자"는 Research:Develop a working definition for moderation activity and moderators에서 시작된 정의를 따르지만, 양적 정의를 좁히기 위해서는 후속 작업이 필요할 것입니다.
    - 두 번째 주는 각 사용자의 첫 방문 시점을 기준으로 정해집니다. 이 경우, 특정 기간 동안 홈페이지를 방문하고 7~14일 후에 최소 한 번 이상 재방문한 모든 신규 관리자를 검토합니다.
    - 위시리스트 중점 분야: 커뮤니티 위시리스트/중점 분야/작업 우선순위
  - 주요 결과 WE1.4: 주시 목록에 있는 고유 방문자의 비율과 편집 내용을 보려고 클릭하는 최근 변경 사항의 비율을 개선합니다.
    - 저희의 목표는 100개 이상의 수정 사항을 가진 편집자들이 자신의 관심사와 관련된 수정 사항을 더욱 효율적으로 찾고 열람할 수 있도록 돕는 것입니다. 작업 우선순위 집중 영역을 살펴보고, 이 영역에 대한 의견을 전달하며, 자원봉사자들로부터 이러한 영역 개선 방안에 대한 추가 피드백을 구할 것입니다. 각 페이지의 "일자리 찾기" 효율성을 개선함으로써 성공을 측정할 수 있으며, 이는 클릭률 지표로 정의됩니다.
  - 핵심 성과 지표 WE1.5: 기여자 전략에 명시된 목표 달성을 위한 진행 상황 추적에 필요한 7가지 최우선 지표[1]를 정의하고 운영화한다. 이를 위해 대시보드를 구축하고 월간 운영자 지표를 운영합니다.
    [1] 유지 편집자, 건설적 활성화, 건설적 편집, 신규 가입자 계정 유지율, 활동 기간별 활동적인 편집자, 경험 수준별 활동적인 편집자.
    - 기여자 경험 전략은 3~5년에 걸친 노력을 통해 신규 및 기존 기여자 모두의 “자원봉사자 증가 촉진”과 “유지율 및 활성화 증대”를 목표로 하며, 이를 위해 세 가지 주요 활동 영역을 추진합니다:
    1. 자원봉사자들이 추천을 받고, 자신의 업무와 관심사를 관리하며, 위키에서 일어나는 일을 확인하고, 자신의 영향력을 이해하는 방식을 간소화합니다.
    2. 적절하게 구조화된 업무를 제공하여 명확성을 높이고, 자원봉사자들이 참여하는 업무의 흐름을 최적화함으로써 잠재력을 발휘할 수 있도록 지원합니다. 여기에는 체계적인 지침 제공과 반복적 업무 자동화에 대한 지속적인 투자가 포함되며, 특히 모바일 웹 환경에 중점을 둡니다.
    3. 자원봉사자들에게 그들의 영향력을 보여주며 기여의 의미를 부여하고, 인간적 유대감을 형성할 수 있는 통로와 긍정적 피드백을 기반으로 한 환경에 투자함으로써 기여를 의미 있게 만듭니다.
    - 측정 전략 프로젝트는 이 변화 이론을 추적하기 위한 광범위한 지표 네트워크를 설계했습니다. 프로젝트는 성공의 주요 측정 기준(“핵심 지표”)은 유지된 편집자 수로 삼아야 하며, 이를 건설적 활성화 및 기여자의 재방문 의도와 같은 좁은 범위의 지표와 활성 편집자 및 양질의 콘텐츠와 같은 광범위한 “하류” 지표로 보완해야 한다고 결론지었습니다. 이러한 지표들이 대시보드에서 가시화되고 운영 가능하도록 하여 전략 실행 진척도를 추적할 수 있도록 해야 합니다.
  - 주요 결과 WE1.6: 정성적 피드백에 따르면, 3분기 말까지 관심 목록 사용자는 업무를 더 쉽게 정리하고 순찰 또는 편집 조치를 더 효과적으로 취할 수 있게 되었습니다.
    - 저희 목표는 100건 이상의 편집 작업을 보유한 편집자들이 자신의 관심사와 관련된 편집 내용을 더욱 효율적으로 찾을 수 있도록 돕는 것입니다. 이를 위해 작업 우선순위 설정 영역을 살펴보고, 해당 영역의 요구 사항을 전달하며, 자원봉사자들로부터 이러한 기능을 개선하는 방법에 대한 추가적인 피드백을 수렴할 예정입니다.
  - 핵심 결과 WE1.7: 주요 목표: 통제된 A/B 테스트를 기반으로 자격을 갖춘 신규 및 주니어 기여자의 모바일 편집 세션의 편집 완료율을 10% 이상 상대적으로 증가시키는 것.[i]
    [i] 적격 편집 세션 = 누적 편집 횟수가 100회 이하인 로그인 사용자가 VE의 "준비" 상태에서 최소 2초 이상 머무른 편집 세션.
    가드레일: 통제된 A/B 테스트 결과에 따르면 신규 및 주니어 기여자가 게시한 모바일 편집물 중 건설적인 편집률에 의미 있는 감소는 나타나지 않았습니다.
    - 하루에 15만~20만 명 정도가 모바일 웹에서 "편집"을 클릭하고, 편집 인터페이스가 로드될 때까지 기다린 후, 최소 2초 동안 둘러보고는 아무것도 하지 않고 페이지를 떠납니다. 키보드 입력도, 툴바 탭도… 아무것도 하지 않는 것입니다.
    - WE 1.7은 이러한 "호기심 어린 클릭"에 대해 명확하고 설득력 있으며 체계적인 편집 제안을 제공하여 클릭하는 사람들이 자신이 방문하기로 선택한 자료인 위키백과를 조금 더 나은 곳으로 만드는 데서 오는 만족감, 기쁨, 그리고 의미를 경험할 수 있도록 할 것입니다.
  - 주요 결과 WE1.8: 4분기 말까지 모바일 웹 계정 생성 완료율을 전체적으로 5% 상대적으로 증가시키는 것을 목표로 하며, 성공 여부는 최소 3개의 통제된 실험에서 각각 최소 2%의 상대적 개선을 달성하는 것으로 측정합니다.
    - 계정 생성은 위키미디어 프로젝트에 의미 있는 참여를 위한 관문이지만, 신규 참여자에게는 여전히 시대에 뒤떨어진 경험입니다. 현재의 계정 생성 과정은 인지적 부담이 크고, 제공되는 정보가 제한적이거나 혼란스러우며, 현대적인 기대에 부응하지 못하는 구식 인터페이스 패턴에 의존하고 있습니다. 그 결과, 많은 잠재적 참여자들이 커뮤니티에 참여할 기회조차 갖기 전에 포기합니다.
    - 이 계획은 계정 생성 과정을 현대화하고, 선의의 기고자들이 불편함 없이 참여할 수 있도록 하며, 동기 부여가 가장 높은 시점에 가입을 유도하는 사려 깊은 실험들을 도입하는 것을 목표로 합니다. 이러한 노력은 신규 참여자 활성화, 유지 및 편집자 다양성 증진을 위한 장기적인 토대를 마련합니다.
    - 현재 가입률을 기준으로 모바일 위키백과 계정 생성률이 5% 상대적으로 증가하면 매달 수천 개의 신규 계정이 추가되고, 수백 명의 신규 편집자가 계속해서 이용하게 될 것으로 추산합니다.
  - 주요 성과 WE1.9: 4분기 말까지 목표 설정, 신입 사원 성장 지원, 인정 제도에 대한 구체적인 제품 제안을 각각 하나씩 제시하여 주니어 개발자들이 지속적으로 참여하고 발전할 수 있도록 지원합니다.
    - 배경: 최근 참여율이 증가했음에도 불구하고, 신입 기여자들의 유지율은 여전히 낮은 것으로 알려져 있습니다(데이터). 신입 기여자 유지율 저하 문제를 해결하기 위한 근본적인 과제는 편집자들이 지속적으로 기여에 대한 동기를 유지할 수 있도록 플랫폼을 개발하는 것이라고 생각합니다. 즉, 기여에 대한 장벽을 낮추는 것뿐만 아니라, 기여 경험을 보람 있게 만들어야 합니다. 하지만 이는 결코 간단한 문제가 아닙니다. 예를 들어, 편집자들은 각기 다른 동기를 가지고 프로젝트에 참여하며, 초기 참여도를 높일 수 있는 게임화와 같은 전략은 장기적인 유지에 도움이 되지 않을 수도 있습니다.
    - 지금이 중요한 이유: 지금까지 기여자 제품 팀은 참여/활성화에 대한 기술적 장벽을 줄이는 데 주로 집중해 왔지만, 향후 유지에 더욱 초점을 맞춘 프로젝트들(예: 진행 시스템 및 인정 시스템)이 예정되어 있습니다. 본 연구 과제는 이러한 구현 작업에 앞서, 기여자들의 다양한 동기를 효과적으로 지원하고 장기적인 유지를 높이기 위해 플랫폼을 어떻게 설계해야 하는지에 대한 명확한 권장 사항을 제품 팀에 제공하는 것을 목표로 합니다. 이는 기여자 전략에서 신규 및 주니어 편집자와 관련된 핵심 질문과도 연결됩니다.
    - 제안된 KR 평가 방법론: 각 프로젝트(목표 설정, 진행 시스템, 인정)에 대해 설계에 영향을 미치는 구체적인 권장 사항을 최소 하나 이상 제시할 것입니다. 연구는 실험적인 작업이며 프로젝트는 KR 진행 과정에서 발전할 수 있지만, 관련 제품 팀과 긴밀하게 소통할 것입니다. 실제로 이러한 권장 사항에는 신규 참여자에게 가장 동기를 저해하는 요소(피해야 할 사항), 가장 만족스러운 요소(강조해야 할 사항), 해결해야 할 여정의 일반적인 "걸림돌", 이러한 문제를 극복하기 위한 전략 등에 대한 통찰력이 포함될 수 있습니다. 이러한 권장 사항은 제품 관리자가 설계 및/또는 엔지니어링을 위한 명확한 다음 단계를 파악하는 데 도움이 되어야 합니다.
  - 핵심 성과 WE1.10: 4분기 말까지 새로운 가이드형 문서 작성 흐름을 구현하여, 통제된 실험을 통해 모바일 환경에서 주니어 편집자가 작성한 문서의 생존율이 다른 방식으로 작성된 문서보다 배포된 각 위키에서 5% 더 높도록 하고, 생존 문서의 총량은 동일하거나 더 높게 유지되도록 합니다.
    - 문서 작성 지침 도입 계획은 편집자들이 커뮤니티 정책 및 콘텐츠 품질에 부합하는, 잘 구성된 위키백과 기고문을 작성할 수 있도록 지원하는 새로운 접근 방식을 개발하는 것을 목표로 합니다. 초기 단계로, 지난 분기에 특정 유형의 문서에 대한 지침을 담은, 커뮤니티에서 편집 가능한 개요를 기반으로 하는 새로운 문서 작성 워크플로가 구현되었습니다. 4분기에는 시범 위키들을 대상으로 A/B 테스트를 실시하여 그 효과를 평가할 계획입니다. 이 지침은 커뮤니티의 요구에 따라 달라지기 때문에, 실험 준비 과정에서는 시범 위키 커뮤니티와의 협력을 통해 시스템을 그들의 필요에 맞게 조정해야 합니다.

필수 지식 (WE2)

목표: 다양한 언어와 주제에 걸쳐 더욱 중요한 지식을 쉽게 접근 가능하게 하고 잘 설명하여 보여줍니다. 토론
- 객관적 맥락: 이 목표는 특정 주제와 언어에 대한 기여자의 관심과 잘 설명된 중요한 지식에 대한 독자의 요구에 부응하는 콘텐츠 성장을 촉진합니다. 중요한 지식은 사용 가능한 위키백과 언어 프로젝트에 필요한 주제의 폭과 깊이를 제공하는 문서 세트입니다. 이는 커뮤니티에서 주목할 만한 점, 관련성, 예상 독자층, 문서 간 연결을 참조하여 정의합니다.
- 우리는 사회 기술적 접근 방식을 취하여 기능, 도구 및 사회적 프로세스의 효과를 개선할 것입니다. 제안된 작업, 미디어 검색 및 콘텐츠 번역과 같은 영향력 있는 제품 기능을 기반으로 구축할 뿐만 아니라 소규모 언어 위키백과의 온보딩 및 개발을 용이하게 할 것입니다. 우리는 위키프로젝트 및 캠페인과 같은 협업적 설정을 통해 공유 콘텐츠 목표를 위해 작업할 기여자를 모집, 교육 및 지원하는 위키미디어 조직자를 지원할 것입니다. (우리는 분기마다 최소 300명의 조직자가 활동한다고 추정합니다.) 또한 소스 자료에 대한 장벽을 제거하기 위해 가장 관련성 있는 게시자와 관계를 개발할 것입니다. (우리는 현재 세계 최고의 구독 전용 데이터베이스 100개 이상과 파트너십을 맺고 있습니다.)
- 우리의 개입이 중요한 지식에 긍정적인 영향을 미치도록 하기 위해, 커뮤니티에서 우선순위를 둔 콘텐츠의 증가와 그 콘텐츠의 품질을 모두 측정할 것입니다. 또한, 전환율과 인용 및 이미지 수와 같은 요소를 살펴볼 것입니다.
  - 주요 결과 WE2.1: 2분기 말까지 기여자가 위키백과에서 중요한 콘텐츠의 상태를 개선하는 데 도움이 되는 3가지 개입을 실험하고 평가합니다.
    - 이 KR은 위키백과에서 이미지 발견, 콘텐츠 번역, 새로운 문서의 가이드 생성과 같은 편집 메커니즘 내의 콘텐츠 갭을 강조할 것입니다. 또한 소규모 언어 커뮤니티를 위한 콘텐츠 생성 활동을 지원하기 위한 사회 기술적 개입을 구현하고 테스트할 것입니다. 성공은 각 가설 내에서 측정됩니다.
  - 주요 결과 WE2.2: 4분기 말까지 추상 위키백과 비전을 대규모로 지원할 수 있음을 검증하는 데 필요한 플랫폼 역량을 구축합니다. 시스템이 위키데이터와 자연어 생성을 사용하여 풍부한 다국어 백과사전 콘텐츠를 출력하고, 위키미디어 커뮤니티의 제어를 받으며, 광범위한 출시 과정에서도 우수한 성능을 유지한다는 것을 보여주면 성공으로 판단할 수 있습니다.
    - 이제 위키데이터를 사용하여 위키백과에 기본적인 일반 텍스트 콘텐츠를 출력할 수 있게 되었으므로, 다음 단계는 추상 위키백과를 대규모로 지원할 수 있는 플랫폼 기능을 지속적으로 구축하는 것입니다. 플랫폼은 커뮤니티에서 제어할 수 있는 풍부한 다국어 콘텐츠를 지원해야 하며, 대규모 환경에서도 뛰어난 성능을 유지해야 합니다. 이는 0에서 1로 나아가는 과정에서 중요한 이정표입니다.
  - 주요 결과 WE2.3: 4분기 말까지 커뮤니티 구성원들이 초록 문서를 조기에 생성할 수 있도록 새로운 위키의 초기 버전을 배포하고, 이를 콘텐츠 위키에 통합하는 프로토타입을 개발합니다.
    - 이 KR은 내년 추상 위키 플랫폼 기능을 테스트할 수 있는 기반을 마련합니다. 새로 구축되는 독립형 위키는 위키함수(Wikifunctions) 기반으로 구축된 추상 문서 라이브러리를 호스팅하며, 향후 추상 문서를 위키백과에 통합하는 데 필요한 플랫폼 기능을 제공할 것입니다.
  - 핵심 성과 지표 2.4: WMF와 WMDE가 위키데이터 핵심 사용 사례를 지원하는 기술 인프라 개선에 대한 성공 기준을 2분기 말까지 정립하고, 2025-2026 회계연도까지의 지표 및 목표를 포함하도록 조정한다.
    - WMF 위키데이터 플랫폼 (WDP) 팀은 2025년 8월에 설립되어 직원으로 구성되었습니다. WMF와 WMDE의 기술 및 제품 소유자가 수년간 개발해 온 프로그램에 새롭게 추가된 이 목표는 사용 사례, 종속성 및 핵심 성공 기준에 대한 조율을 통해 소유권을 이전하려는 우리의 의도를 반영합니다. 이 핵심 성과 지표(KR)는 문제 영역에 대한 상호 이해의 기반을 마련할 것이며, 이를 바탕으로 향후 회계 연도(2026년 5월)까지 구축해 나갈 것입니다.
  - 핵심 성과 WE2.5: 4분기 말까지 백엔드 대체 시스템이 블레이즈그래프와 병행하여 구축되었으며, 일부 사용자의 전환을 지원할 수 있습니다. 본 핵심 성과 지표에서 "마이그레이션 준비 완료"는 2026-2027 회계연도 1분기에 진행될 마이그레이션 시범 단계를 지원할 수 있는 상태를 의미합니다.
    - WE2.4의 일환으로 성공 기준을 정의하는 작업이 진행됨에 따라 이제 실행 단계로 전환합니다. 향후 두 분기 동안 블레이즈그래프 전환과 관련된 모든 변수를 마이그레이션 계획에 명시하고, 파일럿 출시에 필수적인 변수를 결정하여 새로운 RDF 데이터베이스에 구현하고, 파일럿 페르소나 이후의 모든 요구 사항에 대한 마이그레이션 일정을 정의할 것입니다. 2026년 7월로 예정된 새로운 WDQS 백엔드 출시까지의 모든 작업은 이 계획에 명시된 요구 사항을 기준으로 진행될 것입니다.

소비자 경험 (WE3)

목표: 여러 세대의 독자가 위키백과에 참여하고 지속적으로 참여함으로써 유지율과 기부 활동이 눈에 띄게 증가합니다. 토론
- 객관적 맥락: 이 목표는 혁신적인 콘텐츠 형식을 통해 새로운 독자를 유지하고, 익숙한 독서 경험을 강화하여 핵심 독자를 확보하고, 독자와의 연결을 강화하고 기부를 다양화하여 장기적인 지속 가능성을 보장하는 데 중점을 둘 것입니다. AI 요약이나 개인화된 래빗 홀과 같은 새롭고 실험적인 기능을 통해 콘텐츠를 더 쉽게 발견할 수 있도록 하는 작업을 계속하는 것이 포함될 것입니다. 또한 독서 깔때기에서 더 깊은 독서 경험의 품질을 유지하고 개선하고 독서 목록과 기타 비편집 참여를 통해 독서 큐레이션을 탐구하는 작업도 포함될 것입니다. 기부자의 경우 이 작업은 플랫폼 내에서 수익원을 다양화하는 데 계속 중점을 둘 것입니다.
  - 주요 결과 WE3.1: 2분기 말까지 플랫폼당 한 가지 기능에 대한 A/B 테스트를 통해 측정한 결과, 로그아웃한 독자 유지율이 실질적으로 크게 증가했음을 입증합니다.
    - 이 KR은 종종 새로운 기술과 형식을 사용하여 새로운 탐색 및 콘텐츠 학습 방식을 최적화하는 경험에 대한 투자를 계속하는 데 중점을 둘 것입니다. 기존 콘텐츠를 새롭고 매력적인 방식으로 제시합니다. 이 회계연도에는 새로운 기능을 실험하는 동시에 위키와 플랫폼에서 성공적인 실험을 확장하는 데 중점을 두고자 합니다. KR의 작업은 모바일 및 데스크톱 웹사이트, iOS 및 안드로이드 앱에 걸쳐 있으며 콘텐츠 검색(탐색 진입점 및 추천) 및 적응형 학습 형식(기계 지원 요약, 콘텐츠 리믹싱)에 중점을 둡니다.
    - 위시리스트 중점 분야: 새로운 소비자 경험
  - 주요 결과 WE3.2: 기부자와의 더 깊은 연결을 촉진하고 2분기 말까지 기부자의 마찰을 줄이는 제품 개입을 통해 배너나 이메일이 아닌 방법을 통한 기부 건수를 플랫폼당 전년 대비 5% 증가시킵니다.
    - 이 KR에서는 기부를 위한 새로운 진입점과 독자를 기부자로 전환하고 위키와의 연결을 강화하여 유지할 수 있는 다른 기회를 계속 탐색합니다. 여기에는 더 개인화된 콘텐츠가 포함됩니다. KR은 기금 모금 팀과 협력하여 앱과 웹에서 새로운 진입점을 도입하고 기존 진입점을 반복하는 데 중점을 둘 것입니다.
  - 주요 결과 WE3.3: 2분기 말까지 플랫폼당 한 가지 기능에 대한 A/B 테스트를 통해 측정한 결과, 로그인한 독자 유지율이 실질적으로 크게 증가했음을 입증합니다.
    - 이 KR은 기존 및 숙련된 독자를 위한 독서 및 학습 경험을 개선하는 데 중점을 두고, 현재 독자를 유지하고 사이트와의 연결을 강화하여 더 많은 것을 배울 수 있도록 하며 기부 및 편집 경로를 취할 준비가 되어 있고 열려 있도록 합니다. 여기에서의 작업은 웹 및 앱에서 독서 경험을 개선하는 데 중점을 두고(가독성 개선, 더 나은 탐색 및 발견) 큐레이션 및 개인화 제공(독서 목록, 개인화된 제안, 사용자 및 문서 기록 등)을 구축하고 반복합니다.
  - 주요 결과 WE3.4: 4분기 말까지 현재 캐시 사이트 배포 기준에 부합하는 소규모 캐시 사이트 배포(PoPs)에 대한 모든 확인된 장애 요소를 제거합니다. 이는 당사의 현재 서비스 품질 및 보안 기준을 충족해야 합니다.
    - 이 KR은 캐싱 인프라를 단순화하고 기준 배포 시간을 평균 약 1년에서 최대 4분의 1로 줄여 캐싱 사이트 배포 프로세스를 개선함으로써 독자의 웹사이트 성능을 개선하고 지연 시간을 줄일 수 있다는 개념을 증명하는 데 중점을 둘 것입니다. 여기서의 초점은 단순화를 완료하고, PoC를 배포하고, 보안 검토를 수행하고, 퍼블릭 클라우드에 에지 캐시를 배포할지 여부에 대한 의사 결정 브리핑을 완료하는 것입니다. 지연 시간을 줄이면 페이지 뷰가 입증되고 독자 기반이 지리적으로 더 다양해질 수 있습니다.
  - 주요 결과 WE3.5: 기증자 식별 개선 - 모든 동의한 로그인 독자가 기증자 상태를 통해 식별되어 개인화된 경험을 제공할 수 있도록 4분기 말까지 보장합니다.
    - 모든 로그인 독자가 기증자 신분을 통해 식별될 수 있도록 기증자 식별 전략을 구현하여 더욱 맞춤화되고 매력적인 경험을 제공할 것입니다. 향후 더욱 효과적인 개인화 및 활성화 이니셔티브를 지원하기 위해 4분기까지 기증자 식별 활동을 우선적으로 진행할 예정입니다.
  - 주요 결과 WE3.6: 이해관계자와 커뮤니티와 협력하여 정의된 목표와 기준 지표를 개발하고, 2030년까지의 업무 지침을 마련하여 4분기 말까지 위키백과 독자와 다양한 플랫폼에 걸친 소비자 경험을 위한 전략을 마무리, 게시, 전달합니다.
    - 소비자 전략에 대한 작업은 계속 진행될 것이며, 전략을 회사 내부와 커뮤니티에 구축하고 전달하는 것과 소비자를 위한 핵심 지표와 각각의 기준을 정의하고 확립하는 데 중점을 둘 것입니다.
  - 핵심 성과 WE3.7: 4분기 말까지 기부자와의 더욱 깊은 관계를 형성하고 기부 과정의 불편함을 줄이는 제품 개선을 통해 플랫폼별 전년 대비 비배너 또는 이메일 방식의 기부 건수를 10% 증가시킨다.
    - 본 지식 공유 과제(KR)에서는 기부를 위한 새로운 진입점을 지속적으로 모색하고, 독자를 기부자로 전환하고, 위키와의 연결을 강화하여 기부자를 유지할 수 있는 다양한 기회를 개발하는 데 중점을 둘 것입니다. 특히, 개인 맞춤형 콘텐츠를 제공하는 데 집중할 예정입니다. 본 KR은 모금팀과의 협력을 통해 앱과 웹에서 새로운 진입점을 도입하고 기존 진입점을 개선하는 데 주력할 것입니다.
  - 핵심 결과 WE3.8: 4분기 말까지 테스트 환경에서 유지율 또는 활성 독자 지표 개선을 보인 플랫폼(웹 및 앱)별 실험을 최소 하나 이상 확장하고, 해당 기능에 적합한 가이드라인을 설정하여 모니터링합니다.
    - 본 연구 과제(KR)는 1분기/2분기 실험 결과를 바탕으로 웹과 앱 전반에 걸쳐 참여도 높은 독자 유지율(또는 관련 지표) 향상에 효과적인 것으로 나타난 기능들을 확장하는 데 중점을 둘 것입니다. 여기에는 웹상의 읽기 목록 기능 확장(계정 생성 및 내부 추천율 향상), iOS 앱의 활동 탭 기능 확장(계정 생성 및 유지율 향상), 그리고 안드로이드 앱(이미 출시됨)의 활동 탭 기능에 대한 장기적인 운영 환경 분석을 통해 유지율 개선 효과를 검증하는 것이 포함됩니다.
  - 주요 결과 WE3.9: 4분기 말까지 테스트 환경에서 로그아웃한 일반 독자의 유지율 또는 지표 개선을 보인 플랫폼(웹 및 앱)당 최소 하나 이상의 실험을 확장하고, 해당 기능에 적합한 가이드라인을 모니터링합니다.
    - 본 지식 공유 과제(KR)에서는 현재 위키 프로젝트에 참여하지 않는 신규 및 기존 사용자에게 높은 가치를 제공하는 것으로 입증된 성공적인 실험들을 확장할 것입니다. 특히 로그아웃 상태에서의 사용자 경험을 개선하여 지식 검색, 콘텐츠 발견, 시각적 표현, 공유 방식(지식, 콘텐츠, 관심 주제) 등을 지원하는 데 중점을 둘 것입니다. 본 KR은 모바일 웹 및 앱 플랫폼(iOS 및 안드로이드) 전반에 걸쳐 적용됩니다.
  - 핵심 결과 WE3.10: 4분기 말까지 각 플랫폼(웹 및 앱)에서 로그아웃 상태의 일반 독자 유지율 또는 기타 지표에서 대조군 대비 실질적으로 유의미한 개선을 보여주는 실험을 최소 한 번 이상 수행한다(일반 독자 유지율은 웹의 경우 21일 누적 유지율, 앱의 경우 14일 누적 유지율로 정의함).
    - 저희는 현재 위키 프로젝트에 참여하지 않는 신규 및 기존 사용자 모두에게 위키백과의 가치를 전달하는 실험에 지속적으로 투자하고 있습니다. 콘텐츠 검색(예: 미네르바 목차, 의미 검색, 질의응답), 시각적 표현(예: 시각적으로 매력적인 링크 카드), 공유 방식(예: 공유 기능)에 중점을 두고 로그아웃 상태의 사용자 경험 개선을 테스트할 예정입니다. 본 연구 과제는 웹(모바일 및 데스크톱, 특히 모바일 사용자 비중을 고려하여 모바일에 중점)과 앱(iOS 및 안드로이드)을 포괄합니다.

안전과 보안 (WE4)

목표: 저희의 시스템은 기본적으로 편집자의 계정과 개인 정보를 더 잘 보호하는 동시에, 편집자와 사용자가 악의적인 활동을 방지하고 대응할 수 있는 확장된 권한을 가진 더 많은 경로를 제공합니다. 토론
주요 결과 WE4.1: 2분기 말까지 모든 위키에 실행 가능하고 작동하는 인시던트 보고 시스템을 배포하여 커뮤니티에서 사용하고 수용하도록 합니다.
- 사용자 안전과 웰빙을 보장하는 것은 당사 플랫폼의 근본적인 책임입니다. 많은 관할권에는 당사와 같은 온라인 플랫폼이 플랫폼에서 괴롭힘, 사이버 괴롭힘 및 기타 유해한 콘텐츠를 모니터링하고 조치를 취하도록 요구하는 규정이 있습니다. 이를 해결하지 못하면 플랫폼이 법적 책임과 규제 제재를 받을 수 있습니다.
- 우리는 쉽게 발견할 수 있고 직관적인 보고 메커니즘을 통해 사용자가 즉각적인 해악 위협을 보고할 수 있도록 권한을 부여하여 그러한 사건에 대해 알아내고 필요한 경우 신속한 조치를 취할 수 있도록 하고자 합니다. 이는 사용자가 플랫폼에 기여할 때 안전하다고 느끼게 하는 단계입니다. 우리는 위키에 사건 보고 시스템을 구현하여 이를 수행하고 있습니다.
주요 결과 WE4.2: 2분기 말까지 2가지 개선 사항을 배포함으로서 악용 방지 도구의 정확성과 효율성을 강화합니다.
- 당사와 커뮤니티는 위키에서 인증되지 않은 악의적인 활동을 더 잘 감지하고 방지해야 합니다. 이를 위해 플랫폼에서 사용할 수 있는 신호의 수와 품질을 높이고, 이러한 신호를 확장된 권한을 가진 사용자에게 제공하는 도구에 결합하며, 의심스러운 활동에 안전한 자동화된 제한을 할 수 있는 곳을 식별함으로써 이를 할 것입니다.
- 또한, 위키백과와 다른 프로젝트의 접근성을 동시에 개선할 수 있는 기회도 있습니다. 예를 들어, 한 프로젝트는 사용자가 퍼즐을 풀 때까지 로그인을 막는 위키의 매우 전통적인 자체 관리형 보안 문자를 사용자에게 거의 도전하지 않는 위험도 점수 서비스로 대체하는 것입니다. 대신, 이 서비스는 의심스러운 수준의 계정에 자동으로 태그를 지정하여 기능을 비활성화하는 데 사용할 수 있으며, 권한이 높은 관리자가 이 상태를 볼 수 있도록 하여 업무를 지원합니다.
- 일반적으로 위키미디어 프로젝트는 악의적인 행위자의 남용을 완화하기 위해 IP 주소 차단에 크게 의존하고 있습니다. 이는 악용을 막는 데 점점 더 비효율적이며, IP 및 IP 범위 차단에 영향을 받는 선의의 사용자에게 부정적인 영향을 미칩니다. 이번 KR에서는 기존 기능을 개선하고 악의적인 행위자를 보다 정확하고 효과적으로 차단할 수 있는 새로운 도구를 제공하여 IP 및 IP 범위 차단으로 인한 부수적인 피해를 줄이는 것을 목표로 합니다.
- 저희는 효과를 측정하기 위해 어뷰징 방지 작업에 참여하는 자원봉사자들의 정성적인 피드백과 IP 차단이 적용된 비율, IP 평판 및 브라우저 신호 기반 완화 조치의 채택률, 사용자가 차단되었을 때 사람일 가능성이 있는 상호작용의 비율, 어뷰징 방지 도구의 새로운 신호 채택률과 같은 정량적 지표를 살펴볼 것입니다.
- 이 KR의 작업에는 다중 계정 및 금지 회피 탐지 및 완화 개선, 부수적 피해 가능성에 대한 정보 표면화, 봇 탐지 강화, 어뷰징 방지 지원자에 대한 신호 표면화, 어뷰징 방지 도구 인터페이스의 효율성 개선, 어뷰징 관련 지표 개선, 조사를 위한 의심스러운 계정 활동 제안을 검사관에게 제공하는 등의 내용이 포함되어 있습니다.
주요 결과 WE4.3: 4분기 말까지 SRE 인력 개입이 필요한 대규모 공격 건수를 50%(전년 동기 대비) 줄입니다.
- 대규모 봇넷의 증가와 더 빈번한 공격을 포함한 인터넷 환경의 진화는 대규모 남용을 제한하는 기존 방법을 쓸모없게 만들었습니다. 이러한 공격은 인프라에 요청을 범람시켜 사이트를 사용할 수 없게 만들거나, 커뮤니티가 대규모 훼손 행위를 퇴치할 수 있는 능력을 압도할 수 있습니다. 또한 이는 권한이 높은 편집자와 기술 커뮤니티에 부당한 부담을 줍니다.
- 우리는 이런 공격을 자동으로 탐지하고, 견뎌내고, 완화하거나 중단시킬 수 있는 능력을 긴급히 개선해야 합니다.
- 올해 우리는 주로 우리를 향한 정기적인 공격에 가담하는 IP 주소와 네트워크를 자동으로 감지하는 데 주력하고, 지속적으로 해로운 이러한 개체가 우리 시스템에 가할 수 있는 부하를 줄이는 데 주력할 것입니다.
주요 결과 WE4.4: 2분기 말까지 모든 프로젝트의 100%에 임시 계정을 배포하여 미등록 편집자의 개인 식별 정보가 0.1% 미만의 사용자에게 노출되도록 합니다.
- 임시 계정은 등록되지 않은 편집자의 개인 식별 정보(IP 주소)를 대중의 시야에서 보호하고 점검 목적으로 필요한 사람에게만 접근을 제한함으로써 개인 정보 보호 및 안전을 개선하는 것을 목표로 합니다. 이 프로젝트는 사용자 안전을 크게 개선하는 것 외에도 다양한 규제 요구 사항을 준수하는 데도 중요합니다.
주요 결과 WE4.5: 3분기 말까지 생성형 AI가 신뢰와 안전에 미치는 영향을 평가하고, 위키미디어 프로젝트의 기회를 활용하고 위협을 방지하기 위한 제품 개입을 결정합니다.
- AI 사용, 특히 생성형 AI는 인터넷 전반에서 빠르게 증가하고 있습니다. AI가 보편화됨에 따라 신뢰와 안전에 대한 기회와 위협이 동시에 등장하고 있습니다. 예를 들어, 콘텐츠 제작이 더 쉽고 저렴해졌지만 관리가 더 까다로워졌습니다. 마찬가지로, 연구는 훨씬 적은 노력으로 수행할 수 있지만 AI 환각을 식별하기는 더 어렵습니다.
- 이 프로젝트는 위키미디어의 생태계의 신뢰와 안전 측면에 대한 인공지능의 영향을 평가함으로써 ML/AI의 인권 영향 평가에 기반을 둔다. 이 사항은 다음과 같습니다.
  - 확장된 권리를 가진 사용자와 협의
  - 생성 인공지능의 도움을 받은 남용과 잠재적인 완화 사례를 확인.
  - 확장된 권한으로 사용자의 부담을 줄일 수 있는 머신러닝 기회를 파악합니다.
  - 실험을 수행하여 우리가 무엇을 집중해야 하는지 알아내기 위해 최대한의 효과를 낼 수 있도록 합니다.
주요 결과 WE4.6: 4분기 말까지 사용자가 보안 또는 개인정보에 민감한 작업을 수행할 수 있는 권한은 2단계 인증을 활성화한 계정에서만 100% 수행할 수 있도록 기술적으로 강제합니다.
- 특히 민감한 권한이 있는 사용자를 위해 위키의 사용자 계정 보안을 강화해야 합니다. 2단계 인증(2FA)을 활성화한 사용자만 민감한 작업을 수행할 수 있도록 하는 것이 핵심입니다. 2FA에 대한 감사 및 수동 시행의 필요성을 우회할 수 있는 보다 확장 가능한 권한 시행 시스템을 구축하고 플랫폼에서 2FA를 활성화해야 하는 권한을 확대할 것입니다.
- 그 일환으로 인증 및 복구 시스템을 개선하여 우리(WMF)와 사용자가 2단계 인증에 대해 보다 엄격한 태도를 보다 쉽게 지원할 수 있도록 할 것입니다. 모든 사용자가 원하는 대로 2단계 인증을 활성화하고 민감한 권한이 부여되기 전에 2단계 인증을 활성화할 수 있도록 플랫폼 전반에서 2단계 인증의 일반 가용성을 확대할 것입니다. 또한 계정 복구 및 지원 시스템에서 발생하는 운영 부하를 줄여 계정 로그인과 관련된 초기화 및 복구 프로세스를 간소화하는 데에도 관심을 기울일 것입니다. 또한 2단계 인증 구현의 사용 편의성을 개선하여 사용자가 계정을 보호하고 실수로 계정이 잠기는 것을 방지할 수 있는 더 많은 옵션을 제공할 계획입니다.
4분기 7차 핵심 결과: 4분기 말까지 봇 탐지 테스트를 공개적으로 마무리합니다.
- 이번 핵심성과지표(KR)는 이 시범 운영 결과를 평가하고, WMF 내부에서 이 시스템을 모든 위키에 걸쳐 유지 및 확장할지 여부를 결정하며, 시범 운영 결과와 향후 방향을 공개적으로 발표하기 위한 집중적인 1/4 기간 프로젝트입니다.
핵심 성과 WE4.8: 4분기 말까지 임시 계정 점검을 간소화하여 악용 사례를 더 신속하게 식별하고 해결할 수 있도록 합니다.
- 임시 계정의 목적은 선의의 미등록 편집자들이 안전하게 참여할 수 있도록 지원하는 것입니다. 그러나 임시 계정 도입으로 인해 일부 계정 훼손 방지 워크플로가 복잡해졌습니다. 임시 계정을 이용한 훼손 행위를 지속적으로 관리하기 위해, 관리자들이 선의적이든 악의적이든 임시 계정 활동을 더 쉽고 빠르게 파악하고 대응할 수 있도록 지원할 예정입니다.
  관리자들에게 관련 임시 계정들의 클러스터를 보여주는 한편, 조기 발견 및 신속한 대응을 개선할 수 있는 다른 방안들도 모색할 것입니다.
핵심 성과 WE4.9: 자원봉사 조사관들이 위키에서 발생하는 비정상적인 활동을 억제하고 차단할 수 있도록 지원하며, 이들이 신고된 계정을 적극적으로 검토하여 4분기 말까지 해당 계정에 대한 완화 조치 비율이 20% 증가하는 것을 측정합니다.
- 3분기와 4분기에는 제안된 조사 기능이 보여준 전략적 잠재력을 인정하여 봇 감지와는 별개로 새로운 신호를 배포하는 데 투자하고, 최초 MVP 출시 이후 SI 사용자들이 요청했던 다양한 효율성 및 편의성 개선 기능을 우선적으로 개발하는 데 시간을 할애할 예정입니다.
4분기 10월 주요 성과: 4분기 말까지 hCaptcha 봇 감지 범위를 계정 생성의 18%에서 100%로, 위험도가 높은 수정의 경우 18%에서 90%로 확대할 예정입니다.
- 3분기에 hCaptcha 시범 운영을 완료했습니다. 이 시범 운영 기간 동안 계정 생성 시 hCaptcha를 활성화했으며, 이후 데스크톱 위키텍스트 편집기를 사용하는 신규 사용자와 영어 위키백과를 포함한 8개의 대형 위키백과로 적용 범위를 확대했습니다. 시범 운영 결과를 바탕으로 hCaptcha를 더 많은 편집 인터페이스와 위키로 확장하고 있습니다. 최우선 과제는 현재 모든 위키에 hCaptcha를 적용하는 것이지만, 토론 도구나 업로드 기능 등 새로운 영역에도 hCaptcha를 적용하고, hCaptcha로 보호할 사용자 범주를 확대하는 데에도 집중할 것입니다.
4분기 11주차 핵심 결과: 4분기 말까지 단계적 배포 방식을 통해 영어 위키백과에서 IRS 시범 운영을 완료하여 로그인 사용자 중 최소 50%에게 도달하고 5개의 새로운 보고 지표를 도출합니다.
- 저희는 경험이 부족한 커뮤니티 구성원들이 잠재적인 위험 행위를 커뮤니티에서 관리하는 담당자에게 더 쉽게 신고할 수 있도록 설계된 사건 신고 시스템(IRS)을 영어 위키백과에서 시범 운영하고 있습니다. 드물지만 심각한 경우에는 WMF 신뢰 및 안전팀에 직접 신고할 수 있는 양식도 제공합니다.
- 이번 시험은 주로 첫 번째 사용 사례, 즉 시스템에 과부하를 주지 않으면서 편집자가 잠재적으로 부적절한 행동을 신고할 수 있도록 지원하는 기능을 최적화하는 데 중점을 둘 것입니다.
- 시범 운영 기간 동안에는 새로운 신고 건수를 모니터링하고, 신고가 올바르게 전달되는지 확인하며, 즉각적인 문제점을 파악하는 데 집중할 것입니다. 또한 모든 커뮤니티 구성원과 긴밀히 협력하여 버그를 수정하고 프로세스를 간소화할 예정입니다. 예를 들어, 사용자 경험을 개선하고 사람들이 더욱 간편하게 신고를 제출할 수 있도록 하는 방안을 모색 중이며, 시범 운영 기간 동안 이러한 방안들을 적용하고 효과를 측정할 수도 있습니다.
주요 결과 WE4.12: 4분기 말까지 영어 위키백과 정책상 금지된 콘텐츠를 자동으로 탐지하는 분류기 파이프라인을 구축하고, 커뮤니티 데이터셋을 기반으로 검증된, 적어도 한 가지 유형의 금지 콘텐츠를 탐지하는 분류기가 자원봉사자 업무 부담을 줄이는 데 미치는 영향을 평가할 것입니다.
- 저희는 유해 콘텐츠 제거에 필요한 작업량을 줄여 자원봉사자와 UWER(유아 콘텐츠 검토자)을 지원하고, 이를 통해 자원봉사자들이 더욱 어려운 사례에 집중할 수 있도록 돕고자 합니다.
- 이번 분기에는 다양한 유형의 콘텐츠에 대한 탐지 파이프라인 구축을 위한 반복 가능한 프로세스를 정의하는 경험을 쌓고, 대규모 프로젝트에서 이러한 파이프라인을 안전하게 평가하는 첫걸음을 내딛고자 합니다(A/B 테스트, 로그 전용 모드 배포 등). 우선 위협 콘텐츠나 개인정보 유출과 같이 차단해야 할 가능성이 매우 높은 콘텐츠에 집중할 예정입니다.
- 저희는 악의적인 행위에 대한 대응 시간을 단축하는 데 도움이 되는 UWER 및 자원봉사자를 지원하는 악용 방지 도구의 전면적인 개편의 일환으로 2026-2027 회계연도에 이러한 계획을 확대 추진할 예정입니다.

인프라의 책임 있는 사용(WE5)

목표: 개발자와 재사용자는 선별된 경로를 통해 지식 콘텐츠에 액세스하여 인프라의 지속 가능성과 책임감 있는 콘텐츠 재사용을 보장합니다. 토론
- 객관적인 맥락: 이 목표는 책임감 있는 콘텐츠 재사용을 위한 경로를 구축하는 데 초점을 맞춥니다.
- 위키미디어는 웹에서 가장 큰 규모의 인간이 정리한 지식 컬렉션을 보유하고 있습니다. 이로 인해 우리의 지식 인프라는 인간뿐만 아니라 자동 데이터 소비자에게도 귀중한 목적지가 되었습니다. 우리의 콘텐츠는 검색 엔진, 소셜 미디어 플랫폼, 전자상거래에 공급되고 AI가 등장한 이후로 대규모 머신 러닝 모델을 훈련하는 데 사용됩니다. 소비자는 API를 사용하여 페이지를 스크래핑하고 콘텐츠를 다운로드하여 데이터를 소싱합니다. 일반적으로 출처를 명시하지 않습니다. 인증되지 않은 트래픽의 세계에서 우리는 한 사용자를 다른 사용자와 확실하게 구별할 수 없으므로 인프라를 책임감 있게 사용하고 강제할 수 있는 능력이 크게 제한됩니다. 자동 콘텐츠 소비에 대한 경계를 설정하는 동시에 커뮤니티를 계속 지원할 수 있는 방법은 무엇일까요? 사용자를 선호하고 지원되는 채널로 유도하려면 어떻게 해야 할까요? 책임감 있는 콘텐츠 재사용을 장려하기 위해 어떤 지침이 필요할까요? 응집력 있는 개발자 경험을 향해 나아가고 자원 봉사 개발자, 직원 및 재사용자 모두의 요구를 충족하는 제품을 구축하려면 어떻게 해야 할까요? 이러한 질문이 모두 새로운 것은 아니지만, 이러한 질문을 다루는 시급성은 기하급수적으로 커졌습니다. 2024년 이후로 요청량이 극적으로 증가했으며, 대부분의 증가는 AI 기반 워크플로 및 제품에 대한 교육 데이터를 수집하는 스크래핑 봇에서 비롯되었습니다. 인프라에 대한 부하는 지속 가능하지 않으며 지식에 대한 인간의 접근을 위험에 빠뜨립니다. 우리는 지금 당장 건강한 균형을 재정립하여 위키미디어 프로젝트를 효과적으로 지원하고 사명의 지속적인 성공을 가능하게 해야 합니다.
  - 주요 결과 WE5.1: 4분기 말까지 프로그래밍 방식 액세스 채널에 대한 요청의 50%가 알려진 개발자나 애플리케이션에 기인할 수 있습니다.
    - 현재 자동화된 트래픽에 대한 책임자를 식별하는 방법이 제한적이며, 위키와 달리 사용자에게 연락하거나 액세스를 규제하는 방법도 제한적입니다. 외부 자동화된 트래픽의 양이 상당히 증가했는데, 이는 지속 가능하지 않으며 지식에 대한 인간의 액세스를 위험에 빠뜨립니다. 대량 스크래핑 및 API 사용에 대해 계층화된 액세스 수준에 따라 인증 및 승인을 요구함으로써 알려진 계정에 기인하는 자동화된 트래픽의 비율을 늘리는 것을 목표로 합니다. 이를 통해 대규모로 콘텐츠를 재사용하는 사람을 식별하여 인프라를 보호하고 공정한 사용에 대한 거버넌스를 개선하는 동시에 요구 사항을 보다 효과적으로 충족할 수 있습니다. 또한 커뮤니티 구성원의 우선 액세스를 보호하고 개발자에게 새로운 기능을 제공하는 보다 응집력 있는 개발자 환경으로 기술 커뮤니티를 보다 잘 지원하는 방법도 모색할 것입니다.
  - 주요 결과 WE5.2: 4분기 말까지 위키미디어 웹 API 엔드포인트의 70%가 공통 인프라로 지원될 것입니다.
    - 저희는 모든 위키미디어 개발자에게 더욱 일관되고 안정적이며 검색하기 쉬운 웹 API를 제공함으로써 개발자 경험과 지속가능성을 개선하고자 합니다. 핵심 API 기능을 위한 중앙 집중식 인프라를 도입하여 API 제공을 간소화하고, OpenAPI 사양 및 문서, 개발자 식별 및 접근 제어, API 정책 시행, 라우팅, 버전 관리, 오류 처리 등에 대한 일관된 경로와 거버넌스를 구축할 것입니다. API 제공을 간소화함으로써 위키미디어의 사명을 수행하는 데 필요한 도구, 봇, 연구 프로젝트 및 기능을 더욱 빠르고 쉽고 만족스럽게 개발할 수 있도록 지원할 것입니다. 올해는 기초 인프라 및 기능 구축에 중점을 두고 있으며, 최소 기능 제품(MVP) 목표는 API 엔드포인트의 70%가 API 인프라의 세 가지 주요 영역, 즉 일관성과 품질을 보장하는 API 구축 방식, 위키미디어 개발자에게 API를 제공하는 방식, 그리고 API 접근을 관리하고 제어하는 데 사용되는 기본 인프라의 활용 방식 중 하나 이상의 기능을 채택하는 것입니다. 이러한 접근 방식은 API 인프라 유지 관리 비용을 절감하고, 악의적인 행위자에 대응하기 위한 가시성과 접근 제어 기능을 강화하며, 더욱 강력한 개발자 커뮤니티를 육성함으로써 여러 세대에 걸쳐 지속 가능한 임무 수행을 지원합니다.
  - 주요 결과 WE5.3: 4분기 말까지 웹, 앱, 음성 어시스턴트, 대규모 언어 모델(LLM)을 위한 새로운 저작권 표시 체계가 공개되어 위키미디어 사이트 전반에 적용될 예정이며, 측정 가능한 참여도를 유도하는 두 가지 재사용 데모가 배포되고, 한 외부 재사용 파트너사가 모범 사례에 따른 저작권 표시 방식을 채택할 것입니다.
    - 위키미디어 콘텐츠의 적절한 출처 표시를 늘리기 위해 책임 있는 재사용을 장려하는 명확한 모범 사례 지침을 제공합니다. 여기에는 주요 플랫폼(웹, 앱, 음성, 멀티미디어)에 대한 출처 표시에 대한 프레임워크를 만들고 위키미디어 콘텐츠의 모범적인 적용 사례를 강조하는 최소 두 가지 실제 사례를 보여주는 것이 포함됩니다. 산출물의 예로는 미디어 조직이 위키미디어 공용 이미지를 출처 표시하도록 장려하고, 검색 엔진이 관련 위키미디어 데이터를 보다 효과적으로 표시하도록 하거나, AI 보조원이 위키백과 지식을 투명하고 책임감 있는 방식으로 통합하여 신뢰성에 대한 신뢰를 높이는 것이 있습니다. 출처 표시 관행을 강화하면 대중의 인식이 높아지고 위키미디어 프로젝트에 대한 참여가 촉진될 뿐만 아니라, 지식을 리믹스하고 오용을 억제하는 책임감 있고 새로운 방식을 확립하는 데 도움이 됩니다.
  - 주요 결과 WE5.4: 요청 속도 측면에서 스크래퍼가 생성하는 트래픽 양을 20%, 대역폭 측면에서 30% 줄입니다.
    - 스크래핑은 항상 존재했습니다. 검색 엔진은 수십 년 동안 사용자에게 정보를 제공하기 위해 위키피디아에 의존해 왔습니다. 하지만 최근에는 데이터를 스크래핑하는 또 다른 큰 동기가 생겼습니다. 인터넷에서 찾을 수 있는 가장 큰 큐레이팅된 다국어 지식 콘텐츠 세트이며 대규모 언어 모델을 훈련하는 기본 도구입니다. 이는 백과사전 콘텐츠와 이미지를 생성하는 머신 러닝 모델에 매우 귀중한 멀티미디어 저장소인 위키미디어 커먼즈에 모두 해당됩니다.
    - 그 결과, 작년에 스크래퍼 트래픽과 관련 사이트 안정성 사고가 상당히 증가했습니다. 사이트 안정성 엔지니어는 인프라를 보호하기 위해 사례별로 크롤러의 속도 제한 또는 금지를 반복적으로 시행해야 했습니다. 스크래핑이 너무 두드러져서 2024년에 나가는 대역폭이 50% 증가했습니다. 게다가 최근 분석에 따르면 가장 비싼 요청(캐싱 서버에서 처리할 수 없고 대신 주 데이터베이스에서 처리되는 요청)의 최소 65%가 봇에 의해 수행되는 것으로 나타났습니다.
    - 우리의 컴퓨팅 리소스는 트래픽 양에 비해 극히 제한적입니다. 따라서 우리는 그 리소스를 누구에게 제공할지 우선 순위를 정해야 하며, 인간의 소비를 선호하고, 우리의 제한된 리소스를 이용해 위키미디어 프로젝트와 기여자들을 지원하는 것을 우선시하고자 합니다.

제품 성과로 가는 경로 가속화(WE6)

목표: 위키미디어 개발자는 빠르고 자신 있게 자신들의 제품을 최종 사용자에게 제공합니다. 토론
- 객관적인 맥락: 4가지 전략적 기둥을 효과적으로 달성하려면 위키미디어 개발자는 가능한 한 일찍 양질의 제품을 제공하는 고레버리지 활동에 시간과 노력을 투자해야 합니다. 지나치게 복잡한 워크플로, 표준 툴링 부족, 지속 불가능한 시스템 구성 요소가 이러한 결과를 방해합니다.
- 이 작업은 미디어위키를 플랫폼으로 발전시키고 개발 및 배포를 지원하는 소프트웨어를 개발하는 지난 2개 연간 계획에서 얻은 추진력을 기반으로 합니다. 올해의 작업은 보다 안정적인 개발자 환경 제공, 사전 프로덕션 워크플로 간소화, 플랫폼 및 인프라 위험 감소에 중점을 둘 것입니다.
  - 주요 결과 WE6.1: 4분기 말까지 테스트 위키를 넘어서는 열차 차단 버그 수가 10% 감소
    - 2024년에는 미디어위키 배포를 막는 비상 상황이 발생하여 개발자가 작업을 다시 살펴봐야 했던 경우가 144회였습니다. 이러한 사례 중 많은 경우 버그는 테스트 위키에 배포한 후에 발견되었으며, 이는 문제가 수십억 명의 잠재적 사용자에게 전달되었다는 것을 의미합니다. 버그가 존재한다는 사실을 통제할 수는 없지만, 버그를 일찍 발견하면 영웅적인 작업이 덜 필요하다는 것을 의미합니다. 또한 개발자가 실제 프로덕션에 들어갈 때 화재가 발생하지 않을 것이라는 확신을 가질 수 있게 됩니다.
    - 개발자가 개발 및 배포 라이프사이클 전반에 걸쳐 코드를 자신 있게 전달하고 테스트하는 데 필요한 환경을 제공함으로써 이러한 버그를 더 일찍 포착할 것입니다. 또한 이러한 개선 사항이 개발자 속도의 희생으로 이루어지지 않도록 해야 합니다.
  - 주요 결과 WE6.2: 4분기 말까지 생산 준비 검토 체크리스트의 4단계를 SRE 개입 없이 실행할 수 있음
    - 현재 프로덕션에 새로운 서비스나 기능을 배포하려면 각 단계가 일반적으로 SRE의 지원을 필요로 하는 24단계 목록에 따라 달라집니다. 우리는 개발 주기 초기에 개입하고 개발 팀 자체의 역량을 구축하기 위해 SRE 앰버서더 프로그램을 만들었지만, 많은 작업은 완전히 셀프 서비스 가능해야 합니다. 현재 이는 수동적이고 반복적이며 자동화가 가능하고 개발 팀의 수에 따라 선형적으로 확장되는 작업입니다. 이는 장기적으로 SRE 팀에서 지속 가능하지 않습니다.
    - 과거에는 이 작업의 많은 부분이 플랫폼과 상호 작용하기 위한 공유 공통 라이브러리와 모범 사례 세트를 유지함으로써 개발 팀에서 추상화되었습니다. 이러한 작업은 새로운 쿠베르네테스 인프라로 이전하면서 중단되었으며 직접 대체할 수 있는 것이 없습니다. 오늘날 우리가 사물을 빌드하고 배포하는 방식에 적용되는 유사한 라이브러리, 문서 및 교육을 제공함으로써 새로운 서비스나 기능을 프로덕션에 배포하기 전에 SRE에서 필요한 참여 양을 줄일 수 있다고 믿습니다.
  - 주요 결과 WE6.3: 4분기 말까지 위키백과 페이지 뷰의 100%가 Parsoid를 통해 제공됩니다
    - Parsoid는 위키텍스트 진화와 플랫폼의 미래 보호를 위한 향상된 기능을 제공합니다. 두 개의 파서를 동시에 유지하는 것은 기술 부채와 복잡성을 증가시키기 때문에 장기적으로 지속 가능하지 않습니다. 또한 위키함수와 같은 일부 새로운 프로젝트의 성공은 Parsoid가 널리 사용 가능한지에 달려 있습니다.
    - 우리는 더 작은 프로젝트로의 롤아웃을 확장해 왔고 올해는 위키백과를 위한 준비가 될 것입니다. Parsoid를 통해 모든 위키백과 페이지 뷰 읽기를 제공하는 것이 가장 중요한 다음 마일스톤입니다. 롤아웃 자체 외에도 이 작업에는 성능 문제를 해결하고 독자와 편집자에게 미치는 영향에 대해 효과적으로 전달하는 것도 포함됩니다.
  - 주요 결과 WE6.4: 2분기 말까지 위키 배포 및 확장을 계속하는 우리의 능력을 위협하는 것으로 확인된 위험 중 최소 두 가지가 완화되거나 허용 가능한 수준으로 감소되었습니다.
    - 몇 가지 목표형 이니셔티브를 통해 당사 플랫폼과 공공 프로젝트의 성장과 지속 가능성에 잠재적 위협이 될 수 있는 여러 가지 확장성, 안정성, 보안 위험을 줄이거나 완화할 것입니다.
    - 예를 들어, 우리는 공용의 핵심 데이터베이스 구조를 리팩토링하여 향후 몇 년 내에 사용 가능한 서버 하드웨어의 용량에 의해 성장이 제한되지 않도록 할 것입니다. 또한 미디어위키와 관련 서비스를 구동하는 프로그래밍 언어인 PHP를 보다 현대적인 버전으로 업그레이드할 것입니다. 발견된 다른 위험은 인프라를 보호하고 강화하기 위한 추가 보안 조치를 구현해야 할 가능성이 높습니다.
  - 주요 결과 WE6.5: 4분기 말까지 확장 가능한 위키 간 코드 협업 및 로그인한 사용자 지원의 실현 가능성과 향후 단계를 결정합니다.
    - 위키의 핵심 특징 중 하나는 협업을 통한 콘텐츠 제작입니다. 위키미디어 운동의 맥락에서 협업에 필요한 사항은 프로젝트의 발전 과정과 규모가 큰 프로젝트에서 발생하는 문제점들에 따라 매우 특수한 양상을 보입니다.
    - 코드 협업(위키 간 또는 위키 내)은 정당한 요구 사항이며 반드시 수용되어야 합니다. 이는 단일 문제가 아니라 코드(주로 템플릿 및 모듈)와 관련된 여러 문제가 중첩되는 문제 영역에 속하며, 이 영역의 문제를 해결하려면 가장 영향력 있는 우선순위에 대한 공통된 이해가 필요합니다.
    - 실험적인 사고방식을 바탕으로, 소규모의 통제된 환경에서 위키 간 협업을 개선할 수 있는 공유 코드 라이브러리를 테스트하는 보다 효율적인 접근 방식을 모색하고 있습니다. 이를 위해 기술적 타당성 및 범위 탐색 단계를 거쳐 소규모 반복 방식으로 실험을 진행하고, 얻은 인사이트를 통해 문제 해결 방안을 결정할 것입니다. 이러한 과정과 진행 상황을 위키미디어 해커톤 2026에서 발표할 예정입니다.
    - 마찬가지로, 로그인한 사용자의 경험을 개선하려면 성능 향상이 어디에서 발생하는지, 어떤 제품 개발 작업이 요구 사항을 충족해야 하는지, 그리고 다음 회계연도에 이러한 작업을 지속 가능하게 수행하려면 어떤 접근 방식이 필요한지 파악해야 합니다. 이 분야에 대한 연구를 통해 다음 회계연도에 플랫폼 개발 작업을 신속하게 시작할 수 있을 것입니다.
  - 주요 결과 WE6.6: 4분기 말까지 개발자는 10분 이내에 미디어위키 핵심 CI 결과를 얻을 수 있습니다.
    - 현재 우리의 CI 주기 시간 중앙값은 24분 이상이지만, DevEx 업계에서 고성과 팀의 표준은 10분 이하입니다.
    - 이러한 격차를 해소하기 위해 CI 워크플로우를 최적화하고, 브라우저 테스트 실행 방식, 기본 테스트 프레임워크 및 구성 최적화를 통해 주요 병목 현상을 해결할 계획입니다.
    - CI 대기 시간 중앙값을 24분에서 10분으로 단축함으로써, 테스트 및 문제 수정에 필요한 빠른 피드백 루프를 확보하여 반복 개발 속도를 크게 향상시킬 수 있습니다. 또한, 이 지표를 개선하면 병합 시간이 단축되어 변경 사항이 준비된 후 배포 가능해지는 시간이 줄어들고, 이는 OW5의 최상위 지표인 "제품 개발을 더 쉽고 빠르게" 만드는 데 직접적으로 기여합니다.
  - 주요 결과 WE6.7: 2026-27년 회계연도 1분기 말까지 개발자는 미디어위키 코드가 병합된 후 1일 이내에 제품 환경에서 테스트할 수 있습니다.
    - 현재 개발자들은 평균적으로 코드를 병합한 후 약 4일 후에 제품 환경에서 테스트할 수 있습니다. 이 시간을 단축하면 개발자들은 더 빨리 테스트를 진행할 수 있고, 테스트 환경을 개선함으로써 테스트를 통해 제품 환경에 배포되는 버그를 줄일 수 있다는 확신을 가질 수 있습니다.

신호 및 데이터 서비스(SDS)

메트릭(SDS1)

목표: 의사결정권자는 보다 신뢰할 수 있고 시기적절한 지표를 사용하여 제품 및 전략적 의사결정을 내립니다. 토론
- 객관적인 맥락: 재단은 운동에 가장 효과적으로 기여하기 위해 어디에 노력을 집중해야 할지 결정하기 위해 지표를 활용합니다. 그러나 일부 데이터 파이프라인은 고장이 발생하기 쉬워 전달이 지연됩니다. 데이터 문제가 발생하면 파악 및 해결에 너무 많은 시간이 소요됩니다. 또한, 많은 데이터 세트가 추세를 쉽게 탐색할 수 있도록 최적화되어 있지 않으며, 데이터 해석에 중요한 것으로 나타난 차원들이 누락되어 있습니다. 이러한 문제로 인해 지표 평가 속도가 느려지고 제한됩니다.
- 2025-26년 회계연도에 우리는 현재 파이프라인의 데이터 품질 격차를 해소하고, 데이터 품질 문제를 모니터링하고 해결하기 위한 인프라와 프로세스를 구축하고, 의사 결정권자가 추세를 이해할 수 있도록 하는 도구를 제공하기 위한 구체적인 연간 계획 사용 사례에 중점을 둘 것입니다.
- 한 가지 활용 사례는 인간과 봇 트래픽을 측정하는 방법입니다. 지난 몇 년간 자동화된 트래픽이 증가하면서 사람들이 위키미디어 프로젝트와 얼마나 상호작용하고 기여하는지 파악하기가 더욱 어려워졌습니다. 저희는 계획 및 제품 결정에 중요한 요소인 인간과 봇 트래픽 패턴을 평가하는 능력을 향상시키고자 합니다.
  - 주요 결과 SDS1.1: 1분기 말까지 조회수 지표를 사용하는 분석가들은 데이터 품질의 기준 측정값과 자동화된 트래픽 탐지 휴리스틱스의 성능 측정값에 접근할 수 있습니다
    - 이 KR에서 탐구한 가설을 통해 우리는 현재 자동화된 트래픽 감지 휴리스틱의 갭을 파악하고 페이지뷰 트래픽을 적절하게 분류하지 못하는 부분을 파악하는 것을 목표로 합니다. 이러한 통찰력은 페이지뷰 메트릭을 생성하고 분류하는 파이프라인을 개선하는 데 도움이 될 것입니다. 또한 데이터 정확도의 개선을 모니터링하고 측정하기 위해 데이터 품질 메트릭을 정의할 것입니다.
    - 이 KR은 여기에 식별된 필요한 파이프라인 개선을 구현하는 데 초점을 맞춘 후속 KR의 토대를 마련할 것입니다. 이 단계에서 확립된 데이터 품질 지표는 이러한 미래 개선 사항의 효과를 평가하는 벤치마크 역할을 할 것입니다.
  - 주요 결과 SDS1.2: 1분기 말까지 미디어위키 콘텐츠 히스토리 데이터 세트의 내용이 주간 배송 보장(SLO)을 통해 파일 내보내기로 제공될 예정입니다. 내보낸 파일 데이터는 기존 XML 덤프 1 내보내기 파이프라인과 동등한 수준을 유지할 것입니다.
    - FY24/25 KR 1.4의 목표는 가장 관련성 높은 3개 다운스트림 파이프라인에 대한 매월 업데이트되는 mediawiki_wikitext_history 및 mediawiki_wikitext_history_current 데이터 세트에 대한 종속성을 제거하고 주간 SLO가 보장된 대체 데이터 세트를 제공하는 것입니다.
    - 회계연도 24/25년 KR 1.4가 가장 관련성 높은 종속 파이프라인의 안정성 문제를 완화하는 데 도움이 되었지만, 신뢰할 수 없는 레거시 입력 소스를 사용하는 파이프라인이 여전히 남아 있습니다. 이러한 파이프라인과 파일 기반 입력 소스도 위키텍스트 히스토리 데이터 세트 자체로 마이그레이션해야 합니다.
  - 핵심 성과 SDS1.3: 2분기 말까지 봇 탐지에 신호 1개를 추가로 통합하고 이상 징후에 대한 자동화된 경보를 생성합니다.
    - 재단 전역에서 팀들은 인간 독자와 자동화된 트래픽의 차이를 식별할 수 있는 능력을 바탕으로 제품 및 자금 지원 결정을 내리고 있습니다. 데이터 플랫폼은 봇 탐지 신호와 배치 분석의 중앙 저장소 역할을 합니다. 1분기/2분기에 걸쳐 수립한 가설을 통해 자동화된 트래픽 분석을 정교화하기 위한 새로운 봇 탐지 신호를 도입하고, 신규 신호 도입 프로세스를 효율적이고 반복 가능하게 만드는 작업을 시작할 계획입니다.
  - 핵심 성과 SDS1.4: 2분기 말까지 의사 결정권자들이 조직 지표가 제공하는 인사이트의 현재 상태를 명확히 이해하게 됩니다. 위키미디어 생태계와 시장 내 광범위한 인터넷 동향 및 과제 모두에 대한 지표 분석을 포괄하는 이사회 회의용 프레젠테이션 자료를 제공할 경우 성공으로 간주합니다.
    - 우리 조직의 지표에서 얻은 통찰력은 재단 전반에 걸쳐 수많은 의사결정에 활용됩니다. 여기에는 제품 개발 방식, 인프라 자원 배분, 자금 조달 전략 등이 포함됩니다. 동시에 인터넷 환경은 진화하고 있으며, 특히 자동화된 트래픽이 우리 지표에 영향을 미치고 있습니다. 재단 리더십은 12월 이사회 회의에 임할 때, 내부 지표와 외부 동향에 대한 확신 있는 분석을 바탕으로 위키미디어 생태계 내 위협과 기회에 대한 명확한 설명을 제시하는 것이 목표입니다. 다음과 같은 사항에 대해 확신을 주는 통찰력, 지표 및 데이터 포인트를 수집함으로써 이 이야기를 전달할 수 있습니다:
      - 독자 수치에 대한 내부 지표 (조회수)
      - 우리 기여자 생태계의 트렌드
      - 외부 데이터와 경쟁자의 추세
      - 내부 및 외부 연구 및 신뢰할 수 있는 연구의 통찰력
  - SDS1.5의 핵심 결과: 2025-2026년 회계연도 4분기 말까지, 분석 기반 봇 탐지 기능은 하나의 신뢰할 수 있는 분류 기준에 맞춰 보정된 두 가지 신호를 통합할 것입니다.
    - 1분기/2분기에 SDS1.3은 사건 감지 시간의 큰 격차를 해소하고 봇 감지를 위한 추가 신호를 분석했습니다. 그 결과 다음과 같은 사실을 알게 되었습니다.
      - 현대적이고 실현 가능한 신호에는 여러 가지 주의사항과 불확실성이 따르며, 이러한 점들을 측정 지표에 반영해야 합니다.
      - 우리 모델의 품질을 평가하고 향후 반복 작업을 가능하게 하는 신호에 대한 견고한 분석을 수행하려면 레이블이 지정된 데이터, 즉 정의상 신뢰할 수 있고 가급적 독립적인 시스템에서 가져온 데이터(이전에는 "정답 데이터"라고 불렀음)가 필요합니다.
      - 현재 상태를 정량화하고 향후 개선 사항의 우선순위를 정하기 위해서는 이 분야를 전문으로 하는 제3자의 지식과 검증이 필요합니다.
    - 3분기/4분기에는 다음과 같은 세 가지 주요 결과물을 발표할 예정입니다.
      - 기존 레이블 외에도 최소 2개 이상의 새로운 신호를 기반으로 계산된 수치적 신뢰도 점수를 페이지뷰 측정 지표에 추가하여 분석가가 해당 신호의 미묘한 차이를 정량화하고 전달할 수 있도록 합니다.
      - 신뢰할 수 있는 라벨을 선별하고, 가급적이면 해당 분야를 전문으로 하는 제3자 기관에서 제공하는 라벨을 활용하여 현재 성과를 평가하고 새로운 신호를 더 잘 이해하십시오.
      - 클라이언트 측 신호를 실용화합니다. 이는 내부적으로 개발된 탐지 방법 중 가장 유망한 방식입니다.
  - 핵심 결과 SDS1.6: 독자층, 기여자, 콘텐츠 주제 영역 전반에 걸쳐 일관된 내용을 다루는 운동 통찰 보고서를 정기적으로 제공합니다. 4분기 말까지 다음 사항들을 달성하면 성공으로 간주합니다.
    - 일관된 전달 속도
    - 이해관계자들에게 가장 가치 있는 콘텐츠
    - 미래 자동화 분야
    - 오늘날 위키미디어 운동의 건전성을 나타내는 중요한 신호들이 여러 시스템과 팀에 분산되어 있습니다. 독자 수 추이, 기여자 현황, 브랜드 인지도, SEO/AEO, 경쟁사 정보 등은 일관된 프로세스나 시스템 없이 개별적으로 모니터링되고 있어, 이를 종합적으로 해석하는 데 어려움을 겪고 있습니다. 현재 월별 지표 모니터링 프로세스가 있지만, 경영진의 의사 결정에 필요한 범위와 초점을 충족시키지 못하고 있습니다. '운동 동향 보고서'는 위키미디어 운동의 주간 동향을 간결하게 정리하여 경영진과 제품 팀에 공유하는 정보 보고서입니다. 이 보고서는 발생한 모든 일을 나열하기보다는 다음과 같은 질문에 일관되게 답변합니다.
      - 지난 한두 주 동안 의미 있는 변화는 무엇이었나요?
      - 우리가 의문을 제기하는 기존 트렌드에 대해 새롭게 알게 된 점이 있을까요?
      - 지금 그게 왜 중요하나요?
      - 무엇에 주의를 기울이거나 조치를 취해야 할까요?
    - 본 보고서는 상황 인식을 지원하고 심층 분석을 제시할 수 있는 장을 제공하기 위해 작성되었습니다. 초기 징후를 파악하고, 다양한 데이터 소스에서 관련 추세를 연결하며, 의사 결정에 필요한 정보를 제공하는 출발점을 마련합니다.

실험 플랫폼(SDS2)

목표: 제품 관리자는 위키백과에서 제품 기능 변경의 영향을 빠르고 쉽고 확실하게 평가할 수 있습니다. 토론
- 객관적 맥락: 제품 기능 개발에 대한 데이터 기반 의사 결정을 가능하게 하고 가속화하기 위해 제품 관리자는 기능을 정의하고, 사용자의 치료 대상을 선택하고, 영향 측정을 확인할 수 있는 실험 플랫폼이 필요합니다. 출시에서 분석까지의 시간을 단축하는 것은 매우 중요합니다. 학습 타임라인을 단축하면 실험이 가속화되고 궁극적으로 혁신이 가속화되기 때문입니다. 수동 작업과 측정에 대한 맞춤형 접근 방식은 속도에 대한 장벽으로 확인되었습니다. 이상적인 시나리오는 제품 관리자가 엔지니어와 분석가의 수동 개입이 거의 없거나 전혀 없이 실험 출시에서 발견까지 도달할 수 있다는 것입니다.
- 다음 회계연도에는 위키백과에 집중할 것입니다. 핵심 경험이 실험에 관심이 있는 곳이기 때문입니다(조직 전략에 따라 위키피디아에 더욱 집중하고 있습니다). 또한 어떤 팀과 프로젝트에 참여하고 있는지 더 명확하게 집중하고 알릴 수 있기 때문입니다. 다른 팀도 실험 플랫폼 구성 요소를 사용했고 앞으로도 계속 사용할 수 있지만, 이 목표의 초점은 그러한 사용이 아닙니다.
  - 주요 결과 SDS2.1: 2분기 말까지 실험 플랫폼을 사용하여 최소 2개의 전체 실험 주기를 완료할 수 있도록 합니다.
    - 조직이 데이터 기반 제품 의사 결정을 점점 더 강조함에 따라, 전문 기술을 보유한 팀뿐만 아니라 모든 제품 팀이 실험에 참여할 수 있도록 해야 합니다. 제품 팀은 다음과 같은 작업을 수행할 수 있도록 하는 공유된 표준, 도구 및 인프라가 필요합니다.
      - 전 세계 사용자 기반에서 아이디어를 빠르게 테스트하세요
      - 표준화된 지표를 사용하여 제품 변경의 영향 측정
      - 운동 이해관계자들과 결과를 투명하게 공유하세요
    - "활성화된 팀 수"에서 "완료된 실험 수"로 초점을 전환하는 이유:
    1. 전략적 정렬: 이는 플랫폼의 주요 성공 지표입니다.
    2. 데이터 기반 접근 방식: 진행 중인 사용자 조사에 따르면 조직 전체에서 팀 준비 상태가 다양한 반면, 웹 팀은 두 가지 특정 실험에 관심을 표명했습니다.
    3. 리소스 최적화: MVP 플랫폼 출시에는 적극적인 온보딩이 필요하므로, 단기적으로는 여러 팀에 걸쳐 광범위한 네트워크를 구축하는 것보다 실험 기회에 집중하는 것이 더 효율적입니다. 정식 출시를 목표로 하고 있으며, 가능하다면 팀 교육에 재투자하지 않을 계획입니다.
    4. 미래 지향: 전체 실험 주기를 통해 얻은 피드백은 부분적이거나 불완전한 도입을 통해 얻은 결과보다 플랫폼 개선에 더 효과적으로 반영될 것입니다. 정식 출시를 향해 나아가면서, 실험 완료에 집중함으로써 재개발이 필요한 일시적인 접근 방식에 대한 투자를 피할 수 있습니다.
    - 현재 여러 팀의 니즈와 요구사항을 파악하기 위해 사용자 리서치를 진행하고 있습니다. 2025년 5월 하반기에 제품 팀의 니즈를 명확히 파악하기 위해 설문조사와 인터뷰를 진행할 예정입니다. 리서치가 완료되면 다음 KR 목표와 우선순위를 설정하는 데 사용할 수 있는 실험 일정을 마련할 예정입니다.
  - 핵심 성과 SDS2.2: 3분기 말 이전에 최소 하나의 웹 실험 결과를 성장책에서 분석하고 확인할 수 있습니다.
    - 오랜 고된 과정을 거쳐 마침내 성장책을 실험 플래그 지정, 자동 분석 및 대시보드 기능을 제공하는 제3자 실험 솔루션으로 통합하기로 결정했습니다. 이 솔루션은 가드레일 메트릭을 지원합니다. 실험 플랫폼은 실험을 정의하고 배포하는 UI(1)와 실험 분석 파이프라인(5)을 성장책으로 대체할 계획입니다.
    - 이러한 통합과 관련된 위험 때문에 실험 플랫폼 팀은 성장책을 먼저 실험 분석 파이프라인으로 통합해야 한다고 생각합니다. 이는 기존 시스템에 지장을 주지 않으면서 가장 큰 위험 요소를 제거하기 위한 것입니다.
    - 2024/25년 회계연도 SDS2 프로젝트에서 내린 아키텍처 설계 결정과 성장책의 모듈식 구조 덕분에 실험실의 구성 요소를 순서에 상관없이 교체할 수 있게 되었습니다. 즉, WMF 직원은 xLab UI를 사용하여 실험을 정의하고 배포하는 동시에 성장책으로 분석할 수 있습니다. 또한, 기존 실험 분석 파이프라인과 성장책의 파이프라인을 병렬로 실행할 수 있어 실제 시나리오에서 사용자 수용 테스트(UAT)를 수행하고 두 결과를 나란히 비교할 수 있습니다.
  - 핵심 성과 SDS2.3: 4분기 말까지 모든 새로운 테스트 키친 실험이 그로스북(GrowthBook)에 구성되었습니다.
    - WMF 직원들이 GrowthBook을 사용하여 실험 결과를 분석할 수 있도록 지원한 후, 실험 플랫폼 팀은 실험 구성 옵션을 평가하기 위해 디자인 스프린트를 진행했습니다. 그 결과, 실험 구성의 핵심 정보원으로 GrowthBook을 사용하고, 기기 구성의 핵심 정보원은 테스트 키친 UI(TKUI)로 유지하기로 결정했습니다.
      GrowthBook을 실험 구성의 핵심 정보원으로 사용함으로써 다음과 같은 목표를 달성하고자 합니다.
      - 실험 진행 시 조정 작업을 줄이세요
      - 보다 빈번하고 반복 가능한 실험을 가능하게 합니다.
      - 기기와 실험을 명확하게 구분하십시오.
      - 도구보다는 측정 기준에 초점을 맞춘 사고방식으로 나아가십시오.
  - 핵심 성과 SDS2.4: 4분기 말까지 20개 제품 팀 중 최소 14개 팀이 테스트 키친을 활용하여 OKR 이니셔티브에 대한 전략적 의사 결정을 내렸습니다.
    - SDS2.1 프로젝트를 통해 중요한 통찰력을 얻었습니다. 실험 플랫폼을 구축하는 것만으로는 충분하지 않다는 것입니다. 제품 및 기술 팀은 플랫폼 도입에 있어 여러 가지 장벽에 직면합니다. 팀원들은 플랫폼의 가치를 인지하고 있음에도 불구하고, 시간, 인프라, 장비 또는 자신감 부족으로 시작하는 경우가 많습니다. 또한, 심도 있는 파트너십을 통해 해결해야 할 기술적 난관에 부딪힐 수도 있습니다.
    - KR SDS2.4는 구축에서 도입 확대로 초점을 전환합니다. 플랫폼 온보딩 과정에서 팀과 지속적으로 협력하고, 기술적 장벽을 극복하며, 실질적인 마이그레이션 지원을 제공함으로써 제품 팀을 위한 통합 플랫폼인 테스트 키친에서 실험을 통합하고, 엔지니어링 및 분석 지원에 대한 의존도를 줄이는 빠르고 자율적인 테스트 주기를 구현하고자 합니다.
    - 이 KR은 SDS2.2를 두 부분으로 나누기로 결정한 후 계획되었으며, 이로 인해 번호가 변경되었습니다. SDS2.3은 실험 분석을 위한 성장책에 이어지는 차기 KR입니다.

미래 청중 (FA)

미래 청중 (FA1)

목표: 위키미디어 재단은 변화하는 인터넷에서 우리 운동이 새로운 대상 고객에게 다가갈 수 있도록 돕기 위한 전략적 투자에 대한 권장사항을 갖추고 있습니다. 토론
- 객관적인 맥락: 기술과 온라인 사용자 행동(예: 소셜 앱을 통한 정보 수집 선호도 증가, 짧은 비디오 에듀테인먼트의 인기, 생성적 AI의 부상)의 지속적인 변화로 인해 위키미디어 운동은 독자와 기여자를 유치하고 유지하는 데 어려움을 겪고 있습니다. 이러한 변화는 또한 새로운 방식으로 정보를 만들고 전달하여 새로운 청중에게 서비스할 수 있는 기회를 제공합니다. 그러나 운동으로서 우리는 어려움을 극복하거나 새로운 기회를 잡기 위해 추구할 수 있는 다양한 잠재적 전략의 이점과 상충 관계에 대한 명확한 데이터 기반 그림을 가지고 있지 않습니다. 예를 들어, 우리가...
  - 챗봇 같은 대규모의 새로운 기능에 투자할까요?
  - 위키미디어의 지식과 기여 경로를 인기 있는 제3자 플랫폼에 가져오시겠습니까?
  - 다른 것?
- 위키미디어가 여러 세대에 걸친 프로젝트가 되도록 하기 위해, 우리는 위키미디어 재단과 위키미디어 운동이 미래의 청중을 유치하고 유지하기 위해 추구해야 할 유망한 전략을 더 잘 이해하고 추천하기 위한 가설을 테스트할 것입니다.
  - 주요 결과 FA1.1: 잠재 청중의 실험적 통찰력과 권장 사항의 결과로, 3분기 말까지 잠재 청중 팀이 아닌 팀이 소유한 목표 또는 주요 결과 중 적어도 하나가 다음 해 연간 계획 초안에 포함됩니다.
    - 2020년부터 위키미디어 재단은 미래 세대의 지식 소비자와 지식 기여자에게 서비스를 제공하고 미래 세대를 위한 번영하는 무료 지식 운동으로 남을 수 있는 우리의 능력에 영향을 미칠 수 있는 외부 동향을 추적해 왔습니다. 소규모 R&D 팀인 잠재 청중은 다음을 수행합니다:
      - 이러한 추세를 해결하는 방법을 모색하기 위해 신속하고 시간 제한이 있는 실험(회계연도당 최소 3번의 실험 목표)을 수행합니다.
      - 실험에서 얻은 통찰력을 바탕으로 WMF가 추진해야 할 새로운 비실험적 투자에 대한 권장 사항을 제시합니다. 즉, 전체 팀 또는 팀들이 수행해야 할 새로운 제품이나 프로그램을 정기적인 연간 계획 기간 동안 제시합니다.
    - 이 주요 결과는 잠재 청중 외부 팀이 소유하고 잠재 청중 권장 사항에 의해 추진되는 목표 또는 주요 결과 중 최소 하나 이상이 다음 회계연도의 연간 계획 초안에 나타나는 경우 충족됩니다.

소셜 비디오(FA2)

목표: 젊은층(<25세)은 자신이 온라인에서 시간을 보내는 플랫폼에서 위키백과 콘텐츠를 좋아하고, 배우고, 참여하고, 공유합니다. 토론
- 객관적인 맥락: 이번 회계연도에 잠재적 청중이 단편 영상을 실험한 결과, 이 플랫폼을 통해 대규모로 젊은 청중에게 다가갈 수 있음을 보여주었습니다. 하지만 우리의 브랜드 건강 데이터에 따르면, 현재 투자는 Z세대 청중 사이에서 위키백과에 대한 인지도와 친밀도가 감소하는 것을 상쇄하기에 충분하지 않습니다.
- 이 세대에 효과적으로 다가가 참여시키기 위해서는 다양한 전략을 구사하고, 유료 마케팅과 인플루언서 마케팅, 창의적인 캠페인, 트렌드에 대한 대응, 이러한 채널에서의 실험 수준 향상 등의 분야에서 참여를 크게 늘려야 한다고 생각합니다.
- 우리는 현재 직면하고 있는 과제를 극복하기 위해 보다 많은 투자가 필요할 것으로 예상합니다. 특히 참여를 창출하기 위한 커뮤니케이션 및 마케팅 노력과, 이러한 플랫폼에서 위키백과의 브랜드와 콘텐츠의 존재감을 높이기 위한 새로운 제품과 경험을 만드는 데 있어 부서 간 협업이 필요합니다.
  - 주요 결과 FA2.1: 상반기 말까지 자체 채널 전체에서 단편 비디오 콘텐츠를 통해 950만 뷰를 창출합니다.
    - 올해, 우리는 틱톡, 인스타그램, 유튜브의 @Wikipedia 채널에서 단편 영상을 출시한 지 3개월 만에 약 100만 뷰의 도달 범위를 달성했습니다. 다음 회계 연도가 시작될 때까지 우리는 자체 채널에서 더 많은 팔로워를 확보하고 더 많은 시청자에게 도달하기 위해 실행할 수 있는 효과적이고 매력적인 콘텐츠에 대한 더 많은 통찰력을 기대합니다.
    - 올해 상반기에 야심찬 목표를 설정함으로써, 우리는 더 큰 영향력을 발휘하고, 업무를 용이하게 하기 위한 새로운 전략/프로세스를 만들고, 이 목표를 달성하기 위한 추가적인 자원을 옹호할 수 있기를 바랍니다.
  - 주요 결과 FA2.2: 2025/26 회계연도 말(2026년 6월)까지 틱톡 플랫폼 외부 팔로워 수를 중간 규모(10만~25만 팔로워)에서 대규모(25만~100만 팔로워)로 성장시키기
    - 현재 저희는 TikTok 팔로워 수가 중간 단계(10만~25만 팔로워)에 있으며, 2025/26 회계연도 말(2026년 6월)까지 대규모 단계(25만~100만 팔로워)에 도달하는 것을 목표로 하고 있습니다. 마이크로, 중간, 대규모 단계는 업계에서 관객 규모와 도달 범위를 측정하는 표준 지표입니다. 이를 위해 Z세대 팔로워 유치를 강화하는 콘텐츠 전략을 세밀하게 조정하고, 커뮤니티 관리를 통해 전반적인 가시성을 높일 것입니다. 상반기 성과를 바탕으로 하반기에 전술적 조정을 단행해 성장을 가속화하고 이 목표를 달성할 계획입니다.
  - 주요 결과 FA2.3: 미래 청중의 새로운 학습/미디어 소비 방법을 겨냥한 오프 플랫폼 제품을 출시하고 협업적인 제품 브랜딩 및 마케팅 캠페인을 통해 시장에 출시합니다.
    - 잠제적 청중은 일반적으로 최소한의/유기적 마케팅으로 소규모 실험을 진행합니다. 올해는 플랫폼 외부의 젊은 청중을 타겟으로 하는 더 대규모의 신제품 + 마케팅 캠페인을 위한 시간을 따로 마련하고자 합니다.

제품 및 엔지니어링 지원(PES)

제품 및 엔지니어링 지원(PES1)

목표: WMF 제품 및 엔지니어링 팀의 효율성이 향상되어 프로세스가 개선되었으며, 기업 문화에 긍정적인 변화가 촉진되었습니다. 토론
- 객관적 맥락: 이 목표는 위키미디어 재단의 업무 방식을 더 빠르고, 더 똑똑하고, 더 좋게 만드는 것입니다. 이는 모두 우리가 일하는 방식에 대한 것입니다. 즉, 프로세스에서 마찰과 장애물(비효율성과 오류)을 줄이고 더 빨리 영향을 달성하는 것을 의미합니다. 이 목표는 또한 부서와 조직 전체에서 채택할 수 있는 업무 방식을 배우는 것입니다.
  - 주요 결과 PES1.1: 2분기 말까지 이해관계자 팀이 신뢰성 관련 작업의 우선순위를 정하는 데 있어 정보에 입각한 결정을 내리기 위해 SLO를 정의하고 사용하는 방법에 대한 학습을 극대화하는 것을 목표로 하는 우선순위 지정 기준을 기반으로 6개 프로덕션 서비스에 대한 SLO를 정의합니다.
    - 서비스 수준 목표(SLO)는 팀이 충족하기 위해 협력하는(그리고 크게 초과하지 않는) 목표 서비스 수준(신뢰성/성능)에 대한 이해 관계자 팀 간의 합의입니다. 예를 들어, 개발 팀이 신뢰성 또는 성능 작업을 우선 순위로 지정하거나 우선 순위를 낮춰야 하는 시점이나 문제를 구성하는 것이 무엇인지 결정하는 데 도움이 됩니다. 팀은 즉각적인 것(알림/인시던트 대응/중요한 버그)과 그렇지 않은 것을 식별하는 데 신경을 써야 합니다. 목표는 목표를 협상하고 공유되고 명확한 우선 순위를 알려서 기능 간 마찰을 줄이는 것입니다.
  - 주요 결과 PES1.2: 2분기 말까지 커뮤니티 신호(위시리스트 포함)는 WMF가 3~4분기 제품 워크스트림의 우선순위를 최소 5개로 정하도록 영향을 미쳤습니다.
    - 우리의 목표는 팀들이 증거에 기반한 커뮤니티 요청에 따라 작업을 우선적으로 수행할 때 식별하고 축하하는 것입니다.
    - 두 가지 계획된 가설이 위시리스트에만 집중되어 있습니다. 이 가설은 신뢰를 개선하고, 프로세스를 간소화하며, 직원과 자원봉사자의 참여를 높이기 위해 고안되었습니다. 또 다른 가설은 마을 펌프 등에서 충분히 가치 있는 신호가 있는지, 그리고 AI가 신호 수집을 지원할 수 있는지 알아보기 위해 고안된 실험입니다.
  - 주요 결과 PES1.3: 외부 소비자, 기부자, 기여자로부터 검증을 받은 두 가지 초기 단계의 부서 간 실험이 재단에서 연간 계획에 통합되었습니다.
    - 이 작업은 조직 전체에 적용 가능한 실험과 실험 과정을 만드는 것입니다.
    - 재단은 검증된 두 가지 초기 단계 실험을 연간 계획에 통합하여 부서 간 실험 문화를 강화합니다. 이 이니셔티브는 제품 및 기술 부서 기능 팀을 넘어 협업을 촉진하여 조직의 다른 부서(예: 커뮤니케이션 및 진전)와의 혁신을 장려합니다. 검증되지 않은 새로운 아이디어를 시딩하고 실험 프로세스를 간소화함으로써 팀은 생산성을 높이고 영향력을 확대합니다. 성공은 매년 두 가지 부서 간 실험을 완료하고 이를 향후 OKR 작업에 통합하고 실험 관행 채택을 늘려 측정합니다. 결과물의 예로는 새로운 편집자의 성장과 생산성을 높이기 위한 새로운 프로토타입, 독자와 기부자가 위키백과와 더욱 긴밀하게 연결되도록 하는 실험적 기능이 있습니다. 확인된 구체적인 기회 중 하나는 위키백과의 25주년을 기념하기 위해 작은 기능 탐색을 연결하는 것입니다.
  - PES 1.4의 주요 결과: 4분기 말까지 P&T 팀의 Codex 도입률이 10% 증가할 것으로 예상됩니다.
    - 표준화된 UI 라이브러리인 Codex는 사용자 정의 UI 구성 요소를 제작하는 데 드는 유지 관리 부담과 제품 UI 구현에 필요한 시간을 크게 줄여줍니다. 또한 Codex는 디자인과 구현에 대한 공통된 용어를 제공하여 디자인과 엔지니어링 팀 간의 효율성을 높여줍니다.
    - Codex는 채택률이 증가하지 않고 널리 사용되지 않으면 효용성이 떨어질 것입니다. 현재 일부 사용 사례에 필요한 도구가 아직 준비되지 않아 Codex가 제대로 채택되거나 널리 사용되지 않고 있습니다. 또한 더 적극적인 홍보 및 인지도 제고가 필요할 수 있습니다. 팀들이 Codex를 자연스럽게 도입할 수 있도록 지원하는 것이 중요하며, 현재로서는 도입을 가로막는 장애물을 먼저 해결하지 않으면 모든 팀이 Codex를 도입할 수 없습니다. 따라서 이 작업은 우선순위가 높습니다.
    - 이는 다음과 같은 의미를 가질 것으로 예상됩니다:
      - 탐색 - 각 팀이 겪고 있는 어려움이 무엇인지 파악하는 것? 우리가 아직 인지하지 못한 사용 사례와 장애 요인은 무엇인가?
      - 개선 사항 - 예시: 우리는 PHP 코덱스 1.0이 서버 측 도입을 막고 있던 장애물을 해소할 것이라는 것을 알고 있습니다.
      - 지표 심층 분석 - 예시: 1분기에 설정된 기준 지표는 유기적 도입이 제대로 이루어지지 않는 부분을 어떻게 보여주는가 (그리고 과거 OOUI 도입 경험에서 얻을 수 있는 교훈은 무엇인가)?
    - 본 연구 과제(KR)는 공식적인 사용(즉, 문서화된 지침을 따르는 도입)과 부분적 또는 단편적인 사용(예: 팀이 구성 요소의 일부만 사용하거나 CSS만 사용하는 경우)을 구분하여 추적하는 데 중점을 둘 것입니다. 후자의 유형의 도입은 기본 구성 요소를 그대로 사용하는 것보다 유지 관리 비용이 더 많이 발생합니다.
  - 핵심 성과 PES1.5: 서비스 SLO의 20%가 4분기 말까지 영향력 있는 의사 결정으로 이어집니다.
    - 서비스 수준 목표(SLO)는 서비스 안정성 데이터를 기반으로 우선순위를 결정하는 데 사용되는 도구입니다. 예를 들어, 서비스 장애 발생 시 즉각적인 조치가 필요한지 여부를 판단하는 데 활용됩니다. SLO는 책임자가 명확하고 모든 구성원이 활용할 때 가장 효과적입니다. 이를 위해서는 모든 서비스에 SLO를 도입하는 방향으로 개발 문화를 전환해야 합니다. 지난 몇 분기 동안 서비스 팀과 함께 SLO를 수립하고 테스트해 온 경험을 바탕으로, SLO의 가치를 명확히 하고 이러한 문화를 지속적으로 확산할 수 있는 기회를 포착했습니다.
      - 현재 저희는 19개의 SLO를 보유하고 있습니다.
      - 우리는 SLO(서비스 수준 목표)를 활용할 가능성이 가장 높은 서비스에 인센티브를 제공하고자 합니다. 현재 기준으로 약 3~4개(총 19개 중 약 20%)의 "영향력 있는 결정"이 나온다면 좋겠지만, 앞으로 더 많은 결정이 필요할 것으로 예상합니다. 분모는 증가하겠지만, 이는 적절한 서비스를 대상으로 하는 데 더 큰 동기를 부여할 것입니다.
      - 4분기는 타임박스의 마지막 분기입니다. 여러 주기의 데이터를 확보해야 하기 때문이며, 각 분기를 하나의 주기로 간주합니다. 또한, 이를 통해 툴링을 강화하고 SRE 알림 시스템을 시범 운영하는 등의 작업을 진행할 수 있습니다.
    - 성공은 다음과 같은 모습입니다:
      - 영향력 있는 결정이란 "현재 이 서비스가 충분히 안정적인가, 아니면 수정 작업을 우선시해야 하는가?"를 의미합니다. 즉, 오류를 발견하고 수정 작업을 우선시하지 않아도 괜찮다고 판단하는 것만큼이나, 오류를 발견하고 수정 작업을 우선시하는 것도 중요한 결정입니다.
      - 우리는 의사 결정이 다양하기를 바랍니다(예: 아키텍처 vs. 조직 vs. 구현; 또는 찬성 vs. 반대). 이는 SLO의 가치를 확산하고 문화를 변화시키는 데 목적이 있기 때문입니다. 모든 결정이 같은 유형이거나 같은 팀에서 나온다면, 비록 좋은 결정일지라도 이러한 목표를 달성할 수 없습니다.
      - KR 목표를 달성하지 못하더라도, 그 이유에 대한 귀중한 정보를 얻을 수 있을 것이라고 예상합니다(예: 잘못된 서비스를 목표로 삼고 있다는 사실).
      - 중요: SLO의 80%에 대해 영향력 있는 결정이 없다는 것은 해당 SLO의 실패 상태를 의미하지 않습니다. 왜냐하면 대부분의 경우 서비스는 실패해서는 안 되기 때문입니다.
  - 핵심 성과 PES1.6: 위험 분석 프레임워크에 따르면, 핵심 미배정 서비스의 20%가 4분기 말까지 배분 확정되었습니다.
    - 명확한 코드 및 서비스 소유권은 위키미디어 재단의 기술 인프라가 안정적이고 확장 가능하며 안전하게 유지되도록 보장하는 데 매우 중요합니다. 현재 소유권 관련 공백을 해소하면 책임성이 향상되고, 팀 간 협업이 강화되며, 효과적인 의사 결정이 신속해지고, 플랫폼의 안정성, 보안 및 지속 가능성에 대한 위험이 감소할 것입니다. 또한, 위키미디어 관계자와 자원봉사자들이 핵심 서비스 유지 및 지원에 대한 책임자를 명확히 이해할 수 있도록 도와줄 것입니다.
      - 소유자가 없는 핵심 서비스가 약 20개 정도 있는 것으로 추산됩니다.
      - 저희는 3분기/4분기 동안 4개월에 걸쳐 4명의 담당자를 배정할 수 있을 것으로 예상합니다. 처음 2개월 정도는 성공적인 운영을 위한 사전 준비 작업에 집중할 것입니다.
      - 본 연구 과제(KR)의 가설 검증 작업의 일환으로, 중요도를 판단하기 위한 위험 분석 프레임워크를 개발할 계획입니다.
  - PES1.7의 주요 성과: 4분기 말까지 요청 사항의 85%에 대해 10영업일 이내에 답변을 드렸으며, 이행하기로 약속한 작업에 대한 월간 업데이트를 게시하고 있습니다.
    - 상반기에 위시리스트 우선순위 지정 시스템을 개편한 만큼, 자원봉사자들이 위시리스트에 대한 답변을 꾸준히 받고, 매달 진행 예정인 활동, 보류 또는 차단된 활동, 그리고 계획 중인 활동에 대한 업데이트를 받을 수 있도록 하고자 합니다. 이를 위해 월별 응답 시간 평균을 측정하여 평가하고, 최소 한 달 동안 이 평균을 유지하는 것을 목표로 합니다.

가설

1분기

WMF 연간 계획의 (1분기)는 7월부터 9월까지입니다.

위키 경험 (WE) 가설 [ WE 주요 결과 ] 토론
가설 단축명	1분기 텍스트	세부사항 및 토론
WE1.1.1	외부 사이트에서 텍스트를 붙여넣는 신규 사용자에게 자신이 추가하려는 콘텐츠를 직접 작성했는지 확인하라는 메시지를 표시하면 신규 지원자가 게시하는 새 콘텐츠 편집 중 WP:COPYVIO(및 관련 정책)를 이유로 되돌려지는 비율이 10% 이상 감소할 것입니다.
WE1.1.2	"향상된 톤의"의 초기 베타 버전을 제공하면, 새로운 제안된 편집 형식이 검토자들의 검토 부담을 증가시키지 않고 새로운 기여자를 위한 건설적인 편집을 증가시키는 의미 있는 방법인지 알 수 있습니다.
WE1.1.3	숙련된 기여자를 대상으로 하는 새로운 제안 모드를 시각 편집기(모바일 + 데스크톱)에 베타 기능으로 배포하고 그 안에 3개 이상의 새로운 편집 제안이 포함된 경우, 통제된 실험을 통해 신규 지원자의 경험을 평가하기 전에 조정이 필요한 부분이 있다면 무엇인지 파악할 것입니다.
WE1.1.4	만약 우리가 통제된 실험을 통해 en.wiki에 참조 확인을 배포하면, 신규 편집자가 게시하는 건설적인 편집이 10% 이상 증가하고, 이 기능을 더 널리 사용할 수 있도록 검토자와 중재자 사이에서 충분한 지지가 있는지 확인할 수 있습니다.
WE1.1.5	신규 가입자를 대상으로 디자인 프로토타입을 통해 진행 시스템을 실험하면 어떤 유형의 마일스톤, 안내, 인정이 가장 동기 부여가 되는지 파악하고 이러한 인사이트를 활용하여 향후 파일럿 위키 실험을 위한 디자인을 완성할 수 있습니다.
WE1.1.6	사용자 조사와 데이터 분석을 통해 모바일 웹 편집의 주요 기술적, 사회적, 행동적 장벽과 이를 가능하게 하는 요인을 조사하면, 핵심 지식 격차를 해소하고 25/26 회계연도 하반기 및 그 이후의 제품 투자 우선순위를 자신 있게 결정할 수 있는 실행 가능한 인사이트를 3개 이상 도출할 수 있습니다.
WE1.2.1	위키에 공동 작업 기여 데이터를 표시하는 개념 증명을 만들면 최소 30명의 기여자로부터 피드백을 수집할 수 있으며, 응답자의 70%가 이 기능이 유용하고 공동의 성장을 촉진하는 데 도움이 될 수 있다고 답했습니다.
WE1.3.1	이전 조사에서 파악한 요구 사항을 활용하여 가장 영향력 있는 X개의 검토 모듈의 초기 모형을 디자인하고 공유하면 모더레이션 작업을 위한 홈페이지를 해당 모듈과 함께 수정할 수 있습니다.
WE1.3.2	새로운 홈페이지를 수정하여 모더레이터 모듈을 조건적으로 렌더링하면 모더레이터의 홈페이지 사용 가능성을 증명할 수 있습니다.
WE1.4.1	T396489에 명시된 여러 개선 사항을 적용하면 대규모 위키에서 느린 최근 변경 사항 쿼리를 X% 줄일 수 있습니다. 그러면 중재자 도구는 특별한 데이터베이스 성능 문제 없이 해당 위키에 홈페이지 모듈을 배포할 수 있습니다.	T400696
WE2.1.1	해당 지역의 트래픽이 많은 위키백과에 중앙 공지 배너를 통해 소규모 위키의 원어민 사용자를 초대하여 추천 편집 및 기타 성장 기능에 기여하도록 하면, 이 접근 방식이 새로운 원어민 사용자를 끌어들이는지, 그리고 이들이 이러한 편집 도구를 사용하여 중요한 콘텐츠를 개선하는지 평가할 수 있습니다.
WE2.1.2	새로운 편집자를 위해 맞춤형 번역 제안을 개발하고 발표한다면, 우리는 이 접근 방식이 현재의 접근 방식과 비교해 더 나은 번역 결과를 만들어 낼 수 있는지 테스트 할 수 있을 것입니다. 이것은 새로운 편집자들이 직면한 알려진 도전을 해결합니다. 더 관리 가능한 콘텐츠를 번역하는 데에 초점을 맞추는 것은 번역 과정에 대한 압도적 인 인 소개가 덜 가능하고 더 접근성이 높을 수 있도록 하는 것입니다. 좋은 기사 및 섹션 후보자는 포맷 및 전체 길이를 보면 제한된 복잡성을 보일 수 있습니다.
WE2.1.3	새로운 문서와 문단을 만들 때의 편집자 경험(동기, 불만 사항, 더 나은 지원 방법에 대한 새로운 아이디어에 대한 반응 등)을 파악하면 사용자의 요구와 행동을 파악하여 제품, 디자인 및 엔지니어링에 기사 작성 환경을 개선하는 데 필요한 실행 가능한 인사이트와 전략을 제공할 수 있습니다.
WE2.1.4	참여형 워크숍이나 인터뷰를 통해 세 개의 중형 위키백과가 지식 격차와 중요성에 어떻게 접근하는지 살펴본다면, 각 커뮤니티에 적합한 '핵심 지식'에 대한 작업 정의 또는 프레임 개념을 발견할 수 있을 것입니다.
WE2.2.1	만약 우리가 파르소이드의 배포를 따라가 대부분의 위키낱말사전과 일부 저 트래픽 위키백과를 통합한다면, 우리는 더 큰 위키에 자신있게 배포할 수 있는 테스트를 얻을 수 있을 것이다.
WE2.2.2	만약 우리가 위키함수를 HTML 테이블, 스타일링, 링크를 출력하도록 하면, 우리는 단순한 변환을 넘어 위키낱말사전에 새로운 지식을 생성하는 능력을 나타내는 함수를 통해 보여 줄 것입니다.
WE2.2.3	임베디드 함수 호출에 위키데이터 항목를 지원하는 기능을 추가하면 위키데이터를 사용하여 포괄적인 문장을 생성할 수 있는 200개 이상의 새로운 함수를 활성화하여 위키미디어 프로젝트에서 더 쉽게 사용할 수 있도록 할 것입니다.
WE2.2.4	만약 우리가 추상적인 콘텐츠가 어디에 머물고 어떻게 위키백과와 상호작용할지에 대한 계획을 세우는다면, 우리는 고품질의 백과사전 콘텐츠의 제공을 높이기 위해 추상적인 위키백과의 플랫폼을 구현할 준비가 될 것입니다.
WE2.2.5	만약 우리가 Abstract Content에 필요한 인용에 대한 제품 요구에 대해 제품 & 기술 팀들 사이에서 정의하고 사회화한다면, 우리는 Abstract 콘텐츠에 첨부된 기원 정보를 전달하기 위해 위키미디어 간 작업을 수행할 수 있을 것입니다. 이는 위키에서 성공적인 취용에 결정적입니다.
WE2.2.6	만약 우리가 백엔드 내부 요청 형식을 더 표현적이고 간결하게 만들면 시스템의 안정성을 높일 수 있고, 이를 통해 더 넓은 배포를 지원할 수 있습니다.
WE2.2.7	위키데이터와 위키함수 호출을 사용하여 자연어 스니펫을 생성하는 프로토타입 조각을 제공하면 프로젝트의 준비 상태를 보여줄 수 있으며, 인간이 함수에 대해 너무 많이 생각할 필요가 없도록 AI 훈련에 사용할 준비가 된 것입니다.
WE2.2.8	위키데이터 서술 가져오기에 한정어를 제공하면 위키데이터에 있는 백과사전 콘텐츠의 약 50%를 포함하는 다면적인 사실(주제/술어/값 이상의 표현이 필요한 사실)을 생성할 수 있게 됩니다.
WE2.2.9	검색된 위키데이터 엔티티의 캐싱을 제공하면 위키데이터 콘텐츠 기반 함수의 평균 실행 시간이 50% 이상 단축되어 시간 초과와 사용자 불만을 줄일 수 있습니다.
WE2.2.10	위키데이터 어휘 센스 구성 요소를 위키펑션 UI에 제공하면 기여자가 플랫폼/위키펑션에서 나가지 않고도 관련 어휘를 식별하고 선택할 수 있어 문맥 전환이 줄어들고 언어 관련 함수를 더 빠르고 성공적으로 생성할 수 있습니다.
WE2.2.11	위키펑션의 위키백과 통합에 대한 다그바니 커뮤니티의 사용성 결과를 살펴보면, 편집자가 테스트 중에 문서에 함수를 삽입할 때 심각한 사용성 문제가 거의 발생하지 않거나 전혀 발생하지 않는 것을 관찰할 수 있습니다.
WE3.1.1	iOS 앱에서 탭 브라우징 기능의 개선된 버전을 A/B 테스트하면 탭 사용자의 며칠 사용량이 5% 증가하는 것을 볼 수 있을 것입니다.
WE3.1.3	사용자가 기사 페이지 내에서 관련 이미지 또는 동영상 콘텐츠를 탐색할 수 있는 새로운 방법을 제공하면 이 기능을 접한 사용자 중 최소 3%의 클릭률이 증가할 것으로 예상됩니다.
WE3.1.4	위키에 지식 네트워크를 통한 여러 개념을 독자들에게 보여준다면, 우리는 더 나아가 발전하기 위한 개념의 우선 순위를 제시할 것입니다.
WE3.1.5	웹 독자에게 해당 언어로 제공되지 않는 위키백과 콘텐츠의 기계 번역 버전을 볼 수 있는 옵션을 제공하면, 페이지 상호 작용의 3% 증가로 측정되는 읽기 활동이 증가하여 독자를 현지 언어 위키로 유도하고 현지 편집 활동이 증가할 가능성이 있는지 알아볼 것입니다. 이는 사전 동의가 있는 13개 위키백과에서 6개월 이내로 통제된 A/B 테스트 설정으로 제공되며, 위키백과 편집자가 이미 사용할 수 있는 개방형 기계 번역 서비스를 사용합니다.
WE3.2.1	모금팀과 협력하게 되면 사용자 테스트를 통해 iOS 연말 결산에 더욱 매력적이고 통합적이며 개인화된 기부자 슬라이드를 개발할 것입니다. 2분기에는 개선된 연말 결산이 2024년 연말 결산보다 기부금을 5% 더 늘렸는지 평가하는 가설을 수립할 예정입니다.
WE3.2.2	캠페인을 진행하지 않는 시장에서 안드로이드 앱 독자에게 위키백과 사용에 따라 기부에 대한 선택적 맞춤형(금액 및 빈도) 알림을 설정하도록 하면 해당 시장에서 앱 메뉴 기부가 5% 증가하는 것을 볼 수 있습니다.
WE3.2.3	로그아웃한 사용자를 대상으로 A/B 테스트 실험을 실행하여 모바일과 데스크톱 모두에 대해 기부 진입점의 미묘한 변형을 표시하면, 처리 경로를 통한 기부 건수가 대조군에 비해 2% 더 많은 것을 관찰할 수 있습니다.
WE3.3.1	2024년 연감에서 2025년 연감에 iOS 사용자가 요청한 중저 난이도의 개인화 요소를 추가하면 사용성 테스트 또는 베타 테스트를 통해 측정한 결과 만족도가 작년에 비해 3% 증가할 것으로 예상됩니다.
WE3.3.2	만약 우리가 안드로이드에서 기존의 편집 탭을 개인화된 활동 허브로 확장한다면, 읽기 및 편집하지 않는 참여에 대한 통찰력을 포함하면, 원래 버전과 비교해 탭에 대한 다일간의 참여가 5% 증가할 수 있습니다.
WE3.3.3	계정 소유자를 위해 Android 앱에 잠금 해제 가능한 아바타를 하나 이상 도입하면(특정 수의 기사 저장과 같은 의미 있는 독자 행동을 통해 획득) 로그인한 사용자의 관련 행동에 대한 반복 참여가 며칠 동안 10% 증가할 것입니다.
WE3.3.4	로그인한 독자에게 비공개 읽기 목록에 기사를 저장할 수 있는 기능을 제공하면 이 기능을 사용하는 독자의 내부 추천 트래픽이 5% 증가하고 모든 사용자의 참여도가 통계적으로 유의미하게 증가하는 등 사이트 참여도가 높아질 것으로 예상됩니다.
WE3.3.5	웹 독자들이 위키백과에서 콘텐츠를 수집/큐레이팅할 수 있는 사용자 연구를 수행하면, 참여자의 최소 10%가 두 가지 이상의 서로 다른 유형의 콘텐츠(예: 문서, 발췌문, 미디어)를 컬렉션에 저장할 것입니다.
WE3.4.1	우리가 하이브리드 PoP/CDN 배포를 위해 노력한다면, 그것은 필요에 따라 완전한 PoP와 미니 PoP (물리 및 클라우드) 를 모두 가져오도록 할 수 있게 해, 앞으로의 프로토타입 미니 PoM 배포의 기초를 마련할 수 있게 해 줄 것입니다.
WE3.6.1	로그아웃한 사용자의 잔존율에 대한 A/A 테스트를 실행하면 향후 분기에 사용할 수 있는 잔존율 기준선을 설정할 수 있습니다.
WE3.6.2	로그인한 리더에 대한 정의를 만들어 게시하면 WE 3.3 KR과 관련된 모든 팀과 가설에서 이 정의를 사용할 수 있습니다.
WE3.6.3	독자들의 진화하는 요구와 인터넷에서 지식의 변화하는 본질에 대한 대화에 커뮤니티를 참여시키면 독자들에게 서비스를 제공하는 방법에 대한 공유된 초점을 구축하고 멀티미디어, 검색 및 발견, 머신러닝을 비롯한 다양한 아이디어를 테스트할지 여부와 방법에 대해 함께 노력할 수 있습니다.
WE3.6.4	만약 우리가 독자들이 위키백과와 다른 지식 플랫폼을 언제, 왜, 어떻게 사용하는지 뒤에 있는 다양한 동기, 행동, 필요를 조사한다면, 소비자 전략을 알리고 발전시키기 위해 사용할 수 있는 연구결과를 얻을 수 있을 것입니다.
WE4.1.1	최소한의 실행 가능한 비응급 플로우를 프로토타입으로 만들고 확장된 권한을 가진 사용자와 함께 개발하면서 반복적인 피드백 루프를 열어두면 이러한 그룹이 이 플로우의 확장 배포를 지원할 것입니다.	Project page
WE4.2.1	계정 생성과 관련된 hCaptcha 위험 수준을 신뢰할 수 있는 기능 담당자에게 공개하면 불량 행위자를 식별하는 데 필요한 시간이 줄어들고 플랫폼에서 생성된 불량 행위자 계정의 탐지 횟수가 늘어날 것입니다. 계정에 차단이 적용되는 비율, hCaptcha 위험 수준과 계정의 차단이 전반적으로 일치하는지, 기능 담당자의 정성적 피드백을 살펴봄으로써 가설의 성공 여부를 측정할 수 있습니다.
WE4.2.2	검사관이 후속 조치를 취할 수 있도록 추천 조사를 생성하면 불량 행위자 계정을 식별하는 데 필요한 시간이 줄어들고 식별되는 불량 행위자 계정의 수가 증가하는 것을 볼 수 있습니다. '제안된 조사' 기능을 정기적으로 사용하고, 제안된 조사를 통해 식별된 계정에 적용된 완화 조치가 증가하고, 정성적인 설문조사 피드백을 통해 이 기능이 성공적이라는 것을 알 수 있습니다.
WE4.2.3	hCaptcha 계정 생성 평가판의 데이터를 분석하면 계정 생성 유입 경로, hCaptcha의 퍼즐 및 점수 효과를 파악하고 계정 생성 시 hCaptcha의 추가 출시를 알리는 데 필요한 데이터를 확보할 수 있습니다.
WE4.2.4	만약 우리가 모든 위키에 UserInfoCard(유저 정보 카드)를 배포한다면, 우리는 권한을 가진 사용자와 검토자들이 더 효율적으로 나쁜 배우 계정을 식별하고 완화시킬 수 있게 해 줄 것입니다.	Project page
WE4.2.5	우리가 연구를 수행하고, 커뮤니티와 협의하고, 기술적 해결책을 조사한다면, WMF 위키에서 사용할 수 있는 구조화된 블록 이유를 정의할 수 있습니다.
WE4.2.6	데이터 플랫폼에 OpenSearch 기반 클러스터를 배포하는 기능을 개발하면, 제품 기능 엔지니어링 팀은 이 기능을 통합하는 시스템을 개발할 수 있게 되며, 다른 검색 기반 시스템으로부터 상당한 자율성, 복원력, 독립성을 확보할 수 있게 됩니다. 이 시스템의 첫 번째이자 주요 테넌트는 IPoid 서비스가 될 것입니다.
WE4.2.7	시범적으로 여러 프로덕션 위키백과에 hCaptcha Enterprise 통합을 배포하면, hCaptcha Enterprise의 남용 방지, 봇 탐지, 사용성 및 접근성 측면에서의 효과와 가치에 대한 데이터를 수집할 수 있을 것입니다.
WE4.3.1	SRE의 남용 방지를 위한 엣지 규칙 엔진인 requestctl에 새로운 에지 유니크 쿠키에 대한 지원을 통합하면 DDoS와 콘텐츠 재사용을 더 효과적으로 방어할 수 있습니다.
WE4.4.1	파일럿의 피드백을 바탕으로 개선을 이루고 모든 프로젝트에 임시 계정을 배포하면 모든 프로젝트의 등록되지 않은 사용자의 개인 식별 정보(IP 주소)가 모든 (등록된) 사용자의 0.1% 미만에게만 노출되는 것을 방지할 수 있습니다.	Project page
WE4.4.2	관련 운동 이해 관계자(위키 커뮤니티와 글로벌 기능 담당자 포함)와 명확하고 적절한 시기에 소통한다면 남아 있는 모든 위키에 배포하고, 마지막 순간에 발견된 작업 부하를 줄이고, 배포 롤백을 방지할 수 있습니다.
WE4.4.3	점검자가 IP 주소를 기준으로 임시 계정의 활동을 필터링하고 볼 수 있게 하면 임시 계정을 모든 위키에 성공적으로 적용할 수 있습니다.
WE4.4.4	IP 공개 액세스 정책에 따라 임시 계정의 IP 공개 액세스가 취소되도록 허용하고, 이 기능을 더 많은 곳에 적용하면 모든 위키에 임시 계정을 성공적으로 적용할 수 있습니다.
WE4.5.1	악성 행위자가 생성적 AI의 도움을 받아 저지르는 악의적 행위(스팸, 괴롭힘, 장기적 악용, 공개되지 않은 유료 편집, 허위 정보 캠페인 등) 사례를 파악하기 위해 정성적 연구를 수행하면 커뮤니티 모델에 대한 위험을 평가하고 다양한 유형의 생성적 AI 지원 악용을 완화하기 위한 아이디어를 얻을 수 있습니다.
WE4.6.1	Zendesk에서 비밀번호 재설정을 위한 계정 동기화 프로세스를 자동화하면 T&S의 부담이 줄어들고 더 많은 2FA 재설정 요청을 처리할 수 있습니다.
WE4.6.2	사용자가 여러 인증 요소를 등록하도록 지원하고 권장하면 2FA를 활성화한 사용자는 계정이 잠길 가능성이 줄어듭니다.
WE4.6.3	확인된 이메일 주소가 있는 모든 사용자가 계정에 대해 2FA를 켤 수 있도록 허용하지만, 이 변경 사항을 사용자에게 적극적으로 알리지 않으면 복구 지원 데스크 업무량은 지속 가능한 수준으로 유지될 것입니다.
WE5.1.1	인증된 세션과 익명 세션에 서로 다른 스토리지 백엔드를 사용하면 인증 페이지에서 CSRF 방지를 위해 생성된 익명 세션으로 Sessionstore에 과부하가 걸리지 않으므로 DDoS 공격과 대용량 스크래퍼로부터 Sessionstore를 보호할 수 있습니다.	T398814
WE5.1.2	미디어위키 세션 쿠키를 암호화 서명이 포함된 구조화된 형식으로 변경하면 세션의 존재를 스크래퍼에 대한 보호 요소로 사용할 수 있으며, 성능이 뛰어나고 확장성이 뛰어난 방식으로 에지에서 세션의 신뢰할 수 있는 검증을 활성화할 수 있습니다.	T398815
WE5.1.3	쿠버네테스 기반의 로컬 개발 환경을 사용하여 API 게이트웨이에 대한 속도 제한 솔루션을 만들면 최소 3개의 다른 속도 제한 서비스의 성능과 기능을 비교하여 프로덕션 트래픽으로 테스트할 수 있는 가장 좋은 옵션을 결정할 수 있습니다.	T398913
WE5.2.1	개발자의 정보 요구 사항을 더 잘 충족하도록 REST API 샌드박스 UI를 재설계하면 사용성 테스트를 통해 검증된 대로 문서의 명확성이 향상됩니다.
WE5.2.2	rest.php 아래의 모든 API를 중앙 게이트웨이를 통해 라우팅하면 중앙 집중식 API 관리 수단이 활성화되고 REST API 트래픽과 사용 패턴을 지속적으로 측정하여 향후 결정과 조치에 도움이 되는 통찰력을 얻을 수 있습니다.
WE5.2.3	미디어위키 REST API에 대한 모니터링 대시보드와 알람을 구현하면, 특히 중요한 수정 중에 시스템 동작에 대한 가시성을 개선하고 문제를 더 빨리 발견할 수 있는 지속 가능하고 유용하며 복제 가능한 방법을 보여줄 수 있습니다.
WE5.3.1	기존 가이드라인을 업데이트하는 동시에 UX 속성 가이드라인을 확장하고 간소화하면 내부적으로 테스트하고 반복적으로 개선하여 보다 폭넓은 대중적 사용을 준비할 수 있는 핵심적인 개선 가이드라인 세트가 확립됩니다.
WE5.3.2	제3자 콘텐츠 재사용자와 최종 사용자에게 위키백과를 귀속시키는 이점을 보여주는 피치를 만들면, 1분기 말까지 귀속 사례 연구나 데모에 최소 한 명의 추가 재사용 파트너가 등장하는 데 동의함으로써 WME4.1 및 WME4.2를 지원할 수 있습니다.
WE5.4.1	대부분의 웹 요청에 엣지 유니크 쿠키가 포함되면 봇과 위조된 요청을 식별하기가 더 쉬워집니다.
WE5.4.2	알려진 고객을 식별하는 확장 가능한 방식을 구축하면 검증된 출처의 봇에 대한 일반적인 속도 제한에 대한 예외를 허용하고 규칙을 체계적으로 시행할 수 있습니다.
WE5.4.3	CDN에서 텍스트 요청 필터링을 허용 목록/거부 목록 방식을 중심으로 재구성하면 봇에 대한 일반적인 속도 제한을 더욱 엄격하게 적용하고 트래픽 필터링을 간소화할 수 있습니다.
WE5.4.4	통합 측정 전략을 개발하면 '인프라의 책임 있는 사용'에 대한 다년 전략을 평가하고, 지표 개발 및 보고 역량을 안내하는 로드맵을 정의할 수 있습니다.
WE6.1.1	매일의 이미지 빌드를 배포 서버로 옮기고 선택한 배포 작업으로 트리거되는 이미지 업데이트를 추가하면 제약 조건을 파악하고 보다 지속적인 배포를 수행하는 데 필요한 시간에 대한 기준을 확립할 수 있습니다.
WE6.1.3	병합 전 테스트 환경에 위키팜을 추가하면 여러 위키를 사용하여 패치를 격리하여 테스트해야 하는 프로덕션 환경에서 개발하는 개발팀이 사전 프로덕션에 대한 확신을 갖고 결함 유출을 줄일 수 있습니다.
WE6.2.1	서비스가 프로덕션에 투입 가능한 것으로 간주되기 위한 전제 조건과 셀프서비스 가능한 작업을 명확히 정의한 프로덕션 준비 체크리스트를 검토하고 공개하면 SRE와 개발 팀 간의 기대치를 맞춰 전반적인 운영 효율성과 확장성을 개선할 수 있습니다.
WE6.2.2	개발자를 위해 많은 번거로운 작업을 추상화한 Golang과 Node.js 라이브러리를 만든다고 발표하면, 개발자들은 피드백과 관심을 제공할 것입니다.
WE6.2.3	체크리스트/워크시트를 만들면 개발자는 데이터 지속성 디자인 검토를 미리 완벽하게 준비할 수 있습니다.
WE6.3.1	1분기에 언어 변형을 지원하는 위키를 제외하고 트래픽이 적은 위키백과 70개 이상을 출시한다면 상위 10개 위키에 대한 최종 출시에 대한 확신이 커질 것이며, Parsoid를 통해 제공되는 페이지 뷰에 더 큰 영향을 미칠 것입니다.
WE6.4.1	공용의 링크 테이블을 분할하여 자체 클러스터에 배포하면 공용의 데이터베이스 성장이 지속 가능할 가능성이 높아집니다.	T398709
WE6.4.2	SRE가 미디어위키 엔지니어링 팀에 문서 작성, 필요한 인프라(예: PHP 패키지, 컨테이너 이미지) 준비, 지침 및 검토 제공 등의 지원을 제공한다면, 그들은 2분기 시작 전에 자신 있게 PHP 8.3 프로덕션 업그레이드를 시작할 수 있을 것입니다.	T360995
WE6.4.3	시스템 권한이 높은 사용자가 SSH에 로그인할 때 물리적인 두 번째 요소(하드웨어 보안 키)가 필요한 경우 손상된 노트북으로 인해 심각한 보안 침해가 발생할 위험을 줄일 수 있습니다.
WE6.4.4	미디어위키 사이트의 모든 페이지 뷰를 표준 도메인을 통해 제공함으로써 도메인을 통합하면, 모바일 하위 도메인 넘겨주기를 제거하여 플랫폼 복잡성과 검색 엔진 최적화(SEO) 위험을 줄일 수 있습니다. 완료율은 표준 도메인의 모바일 방문에 대한 넘겨주기를 100%에서 0%로 줄이는 방식으로 측정됩니다.	T214998
WE6.4.5	미디어위키 엔지니어링 팀이 PHP 8.3 업그레이드와 관련된 미디어위키의 문제를 적극적으로 모니터링하고 해결한다면 SRE 팀은 2분기 시작 전에 PHP 8.3 업그레이드를 진행할 수 있게 됩니다.	T360995

신호 및 데이터 서비스(SDS) 가설 [ SDS 주요 결과 ] 토론
가설 단축명	1분기 텍스트	세부사항 및 토론
SDS1.1.1	페이지뷰 데이터세트에서 자동화된 트래픽 감지 휴리스틱의 효율성을 분석하면, 성능을 설명하는 데이터 품질 지표를 개발하고 이러한 휴리스틱에 대한 추가 투자가 필요한지 확인할 수 있습니다.
SDS1.2.2	현재의 'Dumps 1' 인프라에서 미디어위키 콘텐츠 파이프라인을 활용하는 데이터 파이프라인으로 XML Dumps 프로세스를 마이그레이션하면 SLO를 보장하고 'Dumps 1' 기반 XML 내보내기를 끌 수 있습니다.
SDS1.2.3	미디어위키 콘텐츠 기록 및 이벤트 플랫폼/이벤트 게이트에 대한 SLO를 검토하고 검토하면 고객, 측정항목, 관련 이해 관계자를 검증하고 SLO에 필요한 개선 사항을 파악할 수 있습니다. 이를 통해 주간 배송 보장에 대한 차이점을 명확히 하는 데 도움이 됩니다.
SDS2.1.1	실험을 수행하는 팀과 긴밀히 협력한다면, 앞으로 시스템을 보다 셀프서비스적으로 만드는 방법과 그들이 직면할 수 있는 개념적 또는 기술적 과제가 무엇인지 알아낼 수 있을 것입니다.
SDS2.1.2	이벤트 로깅에 대한 디버깅을 개선할 수 있다면 제품 팀은 실험에서 예상대로 이벤트 데이터가 수집되고 있다는 것을 알 수 있고, 실험 소유자의 확신도 높아질 것입니다.
SDS2.1.3	실험 플랫폼의 A/B 테스트 시스템(xLab) 구성 요소와 관련 미디어위키 부분에 대한 로깅 및 관찰성을 개선하면 시스템 성능에 대한 기준을 설정하고 실험 관련 오류에 대응할 수 있습니다.
SDS2.1.4	한 달에 한 번(제품 운영 회의, 디자인 팀 회의, 팀 간 프레젠테이션을 통해) 조직 전체에 실험 스토리와 결과를 공유하면 실험 플랫폼이 자연스럽게 도입될 것입니다.
SDS2.1.5	xLab에서 만든 계측 도구에 위험 범주를 변경하는 속성 세트가 포함되어 있다는 사실을 사용자에게 알리면 계측 사용자가 데이터를 과도하게 수집하는 것을 막을 수 있고 어떤 속성 조합에 개인 정보 검토가 필요한지에 대한 명확성이 높아집니다.

잠재적 청중 (FA) 가설 [ FA 주요 결과 ] 토론
가설 단축명	1분기 텍스트	세부사항 및 토론
FA1.1.1	1) Letterboxd, Goodreads, RateMyMusic 등 다른 플랫폼의 미디어 수집가가 위키백과만의 지식으로 컬렉션을 강화할 수 있는 방법을 제공하거나, 2) 이러한 미디어 수집가에게 흥미로운 소셜 미디어 공유 자료를 제공하면, 위키백과의 플랫폼 외부 영향력을 확대할 수 있을 것입니다.
FA2.1.1	1분기에 팀 규모를 늘리고 현재 제작 프로세스의 효율성을 높일 수 있는 기회를 감사하고 파악하여 짧은 영상 콘텐츠를 제작할 수 있는 내부 역량을 키운다면, 2024-5 회계연도에 제작된 콘텐츠에서 얻은 교훈을 바탕으로 2025-6 회계연도 2분기에 제작된 콘텐츠의 전년 대비 도달 범위를 높일 수 있을 것입니다.

제품 및 엔지니어링 지원 (PES) 가설 [ PES 주요 결과 ] 토론
가설 단축명	1분기 텍스트	세부사항 및 토론
PES1.1.1	Prometheus에서 SLI(서비스 수준 지표)에 대한 메트릭을 정의하는 데 xLab, Charts, ToneCheck를 지원하고 Pyrra에 해당 SLO(서비스 수준 목표)를 탑재하면 여러 복잡한 시나리오에서 툴의 한계와 특수한 경우를 파악할 수 있으며, SLO 템플릿에 필요한 반복 작업을 명확히 파악할 수 있습니다. 이는 KR에 계획된 6개의 SLO를 더 잘 지원하는 데 도움이 됩니다.
PES1.1.2	두 세트의 SLO 알림 대시보드를 시범 운영해 보면, 서비스 소유자가 자신의 약속을 명확하게 이해할 수 있도록 적절한 도구를 구현하는 것이 얼마나 어려운지, 그리고 특정 SLO에 대한 단일 뷰만 제공하는 다른 도구로 마이그레이션해야 하는지 여부를 알게 될 것입니다. 한 대시보드는 분기별 보고서(오류 예산에 대한 실제 서비스 수준 계약이 설정된 보고서)를 위한 것이고, 더 작은 동적 대시보드("롤링"이라고 함)는 일상 운영 및 알림을 위한 것입니다.
PES1.1.3	위키함수 프로젝트의 SLO(서비스 수준 목표) 초안 작성을 위해 추사 위키백과 그룹을 계속 지원한다면, 현재 중요한 사용자 워크플로에 추가 중인 복잡한 기능인 위키 문서 렌더링에 대한 SLO 목표 목록(서비스 수준 지표 지표와 함께)을 정의하는 방법을 배우게 될 것입니다. 또한 SRE에서 제공하는 대시보드와 모니터를 사용하여 관련 오류 예산을 시각화하고 알림을 보내는 방법도 배우게 될 것입니다.
PES1.1.4	미디어위키 콘텐츠 기록 프로젝트에 대한 서비스 수준 목표(SLO)를 검토하고 반복하여 데이터 플랫폼 그룹을 지원하면, 일괄 처리 및 스트림 처리 서비스를 조합하여 데이터 세트를 업데이트하고, 일관되게 유지하고 다운스트림 사용자에게 제공할 때 서비스 소유권을 지원하기 위해 SLO를 활용하는 방법을 배울 수 있습니다.
PES1.2.1	위시리스트에 3가지 타겟 개선 사항을 만들면 위시리스트에 참여하는 고유한 참여자가 30% 더 늘어날 것입니다.
PES1.2.2	들어오는 요구사항을 분류하고 72시간 이내에 유지 관리자(예: 제품 관리자)를 할당하면(거부, 설명, 유지 관리되지 않는 서비스 표시 등 포함), 유지 관리자 표와 새로운 요구사항을 교차 참조하여 가장 관련성 있는 제품 팀이나 개인에게 "유지 관리자 범주"를 할당합니다. 그러면 유지 관리자(예: 제품 관리자)는 10일 이내에 요구사항을 평가하고 응답할 수 있습니다.
PES1.2.3	우리가 대규모 커뮤니티 신호를 식별하기 위한 시범 작업을 수행한다면, 우리는 커뮤니티 정보를 바탕으로 우선순위를 정하는 노력에 더 많은 자원봉사자의 의견을 통합할 수 있을 것입니다.
PES1.2.4	1분기에 3개 팀을 대상으로 분기별 희망사항 및 커뮤니티 신호 검토 프로세스를 시범적으로 운영한다면, 제품 관리자들이 커뮤니티 신호를 분기 및 연간 계획 프로세스에 통합하도록 할 것입니다.
PES1.3.1	1분기 말까지 커뮤니케이션 부서와 제품 팀과 함께 3개의 기능적 계획 세션을 조정하여 WP25 이니셔티브에 대한 메시징, 창의적 요구 사항, 캠페인 일정을 조정하면 3가지 캠페인 실험(25YiR, 이스터 에그, 위키런) 모두에 대한 창의적 브리핑을 마무리할 수 있습니다.
PES1.3.2	디자인 및 기능 엔지니어링 담당자들로 운영위원회를 구성하면 Codex 기여에 대한 인지도, 사용률, 기여의 질, 그리고 양이라는 기준 지표를 정의할 수 있을 것입니다. 이러한 기준 지표를 평가하여 얻은 통찰력은 Codex 기여자 기반의 성장과 다각화를 위한 로드맵을 수립하는 데 도움이 될 것입니다.

2분기

WMF 연간 계획의 (2분기)는 10월부터 12월까지를 포함합니다.

위키 경험 (WE) 가설 [ WE 주요 결과 ] 토론
가설 단축명	2분기 내용	세부사항 및 토론
WE1.1.1	페이스트 체크 A/B 테스트 시작 후 2주 이상 경과 시점에 사전 설정된 선행 지표 세트를 분석하면, 해당 기능의 영향 평가를 확신하기 전에 조정 또는 조사해야 할 엔드투엔드 경험의 측면이 있는지 여부를 식별할 수 있습니다.
WE1.1.4	영어 위키백과에서 에서 통제된 실험을 통해 참고 자료 확인 기능을 배포하면, 신규(또는 비교적 새로운) 자원봉사자들이 게시하는 건설적인 편집이 4% 이상 증가하는 것을 확인할 수 있을 것이며, 이 기능을 더 광범위하게 활성화하기 위해 검토자 및 운영진 사이에서 충분한 지지가 있는지 여부를 파악할 수 있을 것입니다.
WE1.1.7	사전 결정된 선행 지표 세트를 분석하면 톤 체크 A/B 테스트 시작 후 2주 이상 경과 시점에 이를 분석하면, 해당 기능의 영향 평가를 확신하기 전에 조정하거나 조사해야 할 엔드투엔드 경험의 측면이 무엇인지(있는 경우) 식별할 수 있을 것입니다.
WE1.1.8	게시된 문서에 검증 모델을 적용하면, 편집자가 문서의 톤을 개선하는 데 도움을 줄 수 있는 고품질(정확도 ≥ 70%) 제안 풀을 구축하는 데 필요한 10,000개 이상의 톤 문제(각각 확률 점수 0.8 이상)를 식별할 수 있는지 여부를 파악할 수 있습니다.
WE1.1.10	편집 필터 (그리고 다른 소도구,스크립트,틀,공지)를 편집하는 10명의 영어와 프랑스어 위키백과의 경험 있는 자원봉사자를 인터뷰하며, 순찰/검토 워크플로우를 자동화하기 위해, 커뮤니티가 작성한 편집 검토의 가치 제안을 형성하는 데 도움이 될 ≥3가지 패턴/요구를 식별할 것입니다.
WE1.1.11	만약 500명 이상의 성공적인 신규 사용자[i]를 대상으로 설문조사를 실시하고, 더 넓은 성공적인 신규 사용자 집단을 대표하는 고품질 데이터를 확보한다면, 우리는 온보딩 경험의 어떤 측면을 개선할지 우선순위를 정하는 데 활용할 수 있는 4개 이상의 실행 가능한 통찰력을 도출할 수 있을 것입니다.
WE1.1.12	10개 신규 언어별로 각각 3명 이상의 자원봉사자가 30개 이상의 샘플 편집을 평가할 수 있도록 한다면, 자원봉사자들이 모델 예측과 얼마나 자주 일치하는지 파악할 수 있으며, 이를 바탕으로 톤 체크 도입을 제안할 신규 위키를 선정할 수 있을 것입니다.
WE1.1.13	영어 위키백과에서 신규 봉사자 100%에게 “링크 추가” 기능을 확대 적용할 경우, 신규 사용자의 건설적 참여 유도 및 유지율이 향상되어 신규 봉사자들의 건설적 편집이 4% 이상 증가할 것입니다.
WE1.2.3	중소 규모 위키에서 이벤트 등록 기능을 사용하기 위해 이벤트 주최자 권한이 필요하다는 요건을 제거하면, 회계 연도 말까지 중소 규모 위키에서 최소 X건 이상의 이벤트*가 추가 생성될 것입니다. 기준치/목표치 계산을 기다리고 있습니다
WE1.2.4	만약 우리가 적어도 2가지 개선으로 협업 기여 MVP를 반복한다면 이벤트 등록을 통해 더 많은 협업이 만들어질 것입니다.
WE1.2.5	위키미디어 커먼스의 이벤트 등록 기능에 대해 2분기 초에 하나의 도입 전략을 수립한다면, 최소 1건의 대규모 캠페인 주최자와 함께 이를 테스트하고 5명의 지역 주최자가 해당 기능을 사용할 수 있도록 할 수 있을 것입니다.
WE1.3.3	신규 편집자에게 운영자 대시보드를 노출하는 실험을 진행할 경우, 방문한 기여자 중 10%가 2주 연속으로 해당 대시보드를 이용합니다.
WE1.4.1	T396489에 정의된 개선 사항을 적용하면 대규모 위키에서 느린 최근 변경 사항 쿼리를 최소 30% 이상 줄일 수 있습니다. 이를 통해 커뮤니티 테크 팀은 최근 변경 사항 데이터베이스에 과부하를 주지 않고도 감시 목록 라벨을 배포할 수 있게 됩니다.
WE1.4.3	최근 변경과 감시 목록을 측정하면 사람들이 얼마나 자주 페이지에 클릭하는지 기준을 정의할 수 있습니다.
WE1.5.1	7가지 기여자 지표를 탐색할 수 있는 대시보드를 구현하고 dbt를 활용해 최소 한 가지 지표의 계산 방식을 표준화한다면, 기여자 제품 팀이 지표 인사이트를 자체적으로 활용할 수 있도록 지원하고 지표 계산 로직 저장 방식을 표준화할 수 있습니다.
WE1.5.2	2분기에 누가 관리자인지에 대한 정의에 포함할 관리 조치들을 결정한다면, 운동 인사이트 팀은 3분기/4분기에 월간 활성 관리자 지표를 구축할 수 있습니다.
WE2.1.3	새로운 문서와 문단을 만들 때의 편집자 경험(동기, 불만 사항, 더 나은 지원 방법에 대한 새로운 아이디어에 대한 반응 등)을 파악하면 사용자의 요구와 행동을 파악하여 제품, 디자인 및 엔지니어링에 기사 작성 환경을 개선하는 데 필요한 실행 가능한 인사이트와 전략을 제공할 수 있습니다.
WE2.2.12	위키함수를 파르소이드가 활성화된 위키에 적용하면, 점차 확대되는 적용 범위에서도 시스템의 성능과 사용성이 유지되는지 계속 테스트할 수 있을 것입니다.
WE2.2.13	위키낱말사전 커뮤니티와 활용 가능한 활용법 표 기능을 공유한다면, 기능 사용에 관한 귀중한 피드백과 향후 출시 계획에 적용할 수 있는 사용자 페르소나에 대한 통찰력을 얻을 수 있을 것입니다.
WE2.2.14	커뮤니티의 데이터박스 작업(위키데이터를 정보상자에 활용하는 연구)을 살펴보고 위키함수가 도움이 될 수 있는지 조사한다면, 정보상자에서 위키함수를 활용한 첫 번째 실험 사례를 확인할 수 있을 것입니다.
WE2.2.15	위키함수에서 오류 메시지를 생성하고 번역할 수 있다는 점을 커뮤니티에 알린다면, 유용한 오류 메시지의 수가 증가할 것입니다.
WE2.2.16	사용 가능한 의미 기능을 커뮤니티에 시연하면, 문법 기능이 50% 증가할 것입니다.
WE2.2.17	위키함수에서 위키데이터 진술을 보기 위한 맞춤형 컴포넌트를 제공한다면, 사용자들은 위키데이터에서 가져온 데이터를 더 잘 이해할 수 있고 부담감을 덜 느낄 수 있을 것입니다.
WE2.2.18	10배에 달하는 메모리 사용량 급증을 방지할 수 있다면, 오케스트레이터는 위키데이터 객체를 더 효과적으로 처리할 수 있게 되어 추상 위키백과 플랫폼으로서 위키함수의 유용성을 뒷받침할 수 있을 것입니다.
WE2.2.19	사용자가 입력값을 포함한 특정 함수 호출에 대한 직접 링크를 공유할 수 있도록 하면, 기여자들은 함수 동작을 더 쉽게 재현하고 검증하며 논의할 수 있게 됩니다. 이는 디버깅 속도를 높이고 테스트 워크플로를 개선하며 위키함수 커뮤니티 전반에 걸친 협업적 문제 해결을 지원할 것입니다.
WE2.3.1	새로운 위키 생성 결정을 최종 확정하고 커뮤니티와 함께 이름을 결정한다면, 이 새로운 위키 생성을 이해관계자들에게 더 폭넓게 알리고 잠재적인 제품명 변경에 대한 실무 준비를 할 수 있을 것입니다.
WE2.3.2	만약 우리가 우리의 백엔드 및 NLG 기능을 테스트하는 데 가능한 최소한의 경험을 포함하는 추상 위키 프로토타입을 위한 MVP를 정의하고 반복적으로 설계할 수 있다면 3분기에 라이브 프로토타입의 계획을 세우고 출시할 수 있을 것입니다.
WE2.3.3	커뮤니티와 소통을 시작하고 추상적 위키의 사용자 경험에 대한 잠재적 디자인을 탐구한다면, 3분기에도 작업을 계속 진행할 수 있을 것입니다.
WE2.4.1	WMDE 및 WMF 팀으로부터 위키데이터와 WDQS 사용 사례를 수집한다면, 인프라 개선을 위한 제품 요구사항을 정의할 수 있을 것입니다.
WE2.4.2	위키데이터 및 WDQS에 대한 기존 서비스 수준 목표(SLO)를 기반으로 핵심 성과 지표(KPI)의 통합 보고 뷰를 생성한다면, 핵심 위키데이터 사용 사례를 지원하는 기술 인프라 개선을 위한 성공 기준을 명확히 제시하고 추적할 수 있을 것입니다.
WE2.4.3	분기 내에 실제 운영 환경에 부합하는 기준으로 Blazegraph의 대체 스토리지 솔루션을 평가하고 벤치마킹할 수 있다면, 데이터 기반의 마이그레이션 결정을 내리고 구체적인 로드맵을 수립할 수 있을 것입니다. 여기에는 일정과 자원 요구 사항이 포함됩니다.
WE3.1.1	탭 브라우징 기능의 개선된 버전을 A/B 테스트하면, 탭 사용자들 사이에서 다일 사용률이 5% 증가할 것입니다.
WE3.1.3	사용자가 문서 페이지 내에서 관련 이미지 콘텐츠를 탐색할 수 있는 새로운 방식을 제공하고, 로그아웃 상태의 일부 독자를 대상으로 여러 위키 사이트에서 A/B 테스트를 진행할 경우, 해당 기능을 접한 사용자들 사이에서 최소 3%의 클릭률을 확인할 수 있을 것입니다.
WE3.1.4	위키에 지식 네트워크를 통한 여러 개념을 독자들에게 보여준다면, 우리는 더 나아가 발전하기 위한 개념의 우선 순위를 제시할 것입니다.
WE3.1.5	웹 독자들에게 자신의 언어로 제공되지 않는 위키백과 콘텐츠의 기계 번역 버전을 볼 수 있는 옵션을 제공하면, 페이지 상호작용이 3% 증가하는 것으로 측정되는 읽기 활동이 증가하는지 확인할 수 있습니다. 이는 독자들을 현지 언어 위키로 끌어들이고 현지 편집 활동 증가 가능성을 가져올 것입니다. 이는 사전 동의를 얻은 13개 위키백과에서 최대 6개월간 통제된 A/B 테스트 환경으로 제공되며, 위키백과 편집자에게 이미 공개된 기계 번역 서비스를 활용할 것입니다.
WE3.1.6	의미 기반 검색 및 기사 내 Q&A 기능을 구현한 프로토타입을 데모 인터페이스로 제작하여 기존 접근 방식과 새로운 탐색적 접근 방식을 대비시킨다면, 리더 팀은 각 접근 방식이 다양한 사용자 여정에서 어떻게 작동하는지 질적으로 평가하고 추가 개선을 위한 격차나 기회를 도출할 수 있을 것입니다.
WE3.1.7	위키백과에서 독자들이 검색 및 탐색 도구를 어떻게 활용하는지, 그리고 외부 검색을 통해 위키백과 내 지식을 찾는 방식에 관한 기존 연구를 검토한다면, 독자 팀에게 ≥3개의 실행 가능한 권고사항과 인사이트를 제공할 수 있을 것입니다. 이를 통해 독자의 기대와 요구 사항 간 격차를 해소하기 위한 검색 및 발견 기능의 MVP(최소 기능 제품) 범위를 설정하는 데 도움을 줄 수 있습니다.
WE3.1.8	외부 참가자를 대상으로 두 가지 의미 기반 검색 프로토타입(자연어 검색, Q&A)을 평가하면, 사용자가 개선된 검색 도구의 가치를 인지하는지 파악할 수 있으며, 리더스 팀에게 검색 및 발견 MVP 추진 방향에 대한 권고안을 제공할 수 있습니다.
WE3.1.9	정성적 연구를 통해 10~20명의 비정기적 위키백과 이용자에게 의미론적 검색을 통한 콘텐츠 발견을 위한 고충실도 디자인 컨셉을 제시할 경우, 해당 기능에 대한 긍정적 반응을 확인할 수 있을 것이며, 검색어에 대한 인간이 작성한 짧은 발췌문을 기반으로 하는 검색 및 발견 MVP를 진행하는 데 필요한 확신을 얻을 수 있을 것입니다.
WE3.1.10	비관리형 사용자 연구에서 10명의 일반 독자에게 새로운 이미지 탐색 경험의 라이브 프로토타입을 보여준다면, 해당 기능의 향후 개선을 위한 최소 한 가지 이상의 UX 개선점을 발견할 수 있을 것입니다.
WE3.1.11	검색에서 키워드 일치 기준을 완화하면 자연어 질의를 더 잘 지원할 수 있으며, 이를 통해 제품팀이 해당 기능을 평가하고 의미론적 검색 영역에서 업무 설계, 우선순위 설정 및 실행 과정에 이를 반영할 수 있게 됩니다.
WE3.1.14	기본적으로 모든 섹션을 열도록 하는 내비게이션을 도입한 모바일 사이트 버전을 A/B 테스트하면 세션 시간 증가를 시사하는 초기 지표를 확인할 수 있을 것입니다. (전체 A/B 테스트 결과는 3분기에 보고드리겠습니다.)	T409163
WE3.2.5	안드로이드에 사용자 영향력을 강조하고 통합 기부자 메시징을 포함하는 ‘연간 리뷰’ 기능을 도입하면 새로운 기부 행동을 유도할 수 있으며, 2024년 대비 앱 메뉴에서 5% 증가를 확인할 수 있을 것입니다.
WE3.2.6	iOS 연례 리뷰에서 기부자 슬라이드를 더욱 통합적이고 개인화된 형태로 제작하면, 2024년 대비 기부금이 5% 증가할 것입니다.
WE3.3.3	안드로이드 앱에서 계정 보유자를 대상으로 최소 한 가지 이상의 잠금 해제 가능한 아바타를 도입할 경우(예: 일정 수의 기사 저장 등 의미 있는 독자 행동을 통해 획득 가능), 로그인 사용자의 관련 행동에 대한 반복 참여도가 여러 날에 걸쳐 10% 증가할 것입니다.
WE3.3.4	로그인한 독자에게 기사를 개인 읽을 문서 목록에 저장할 수 있는 기능을 제공하면, 해당 기능을 사용하는 독자의 내부 유입 트래픽이 5% 증가하고 모든 사용자에게 통계적으로 유의미한 증가가 나타남으로써 사이트 참여도가 높아질 것으로 예상됩니다.
WE3.3.6	만약 합의된 확장성 및 가용성 요구사항을 충족하는 서비스와 필요한 데이터 보충을 통해 기사 주제 추론 데이터를 제공할 수 있다면, 이 데이터에 의존하는 향후 맞춤형 독자 경험을 지원하기 위한 필수 기술 기반을 마련하게 될 것입니다.
WE3.3.7	데이터 플랫폼의 처리 기능을 활용하여 맞춤형 편집기 매트릭과 영향 데이터를 집계하고 정의된 SLO를 가진 적절한 서비스를 통해 집계된 데이터를 서비스한다면, 우리는 검토 WE3.3.1 및 활동 탭 WE3.3.2의 미래 반복을 향상시킬 수 있습니다.
WE3.3.9	안드로이드용 '연간 리뷰'를 출시하고, 참여도가 높은 사용자에게 맞춤 독서 목록 저장 시 보상을 제공하는 A/B 테스트를 진행할 경우, 보상을 제공받은 독자 그룹의 앱 유지율이 제공받지 않은 그룹 대비 1% 증가할 것으로 예상됩니다.
WE3.3.10	연간 리뷰의 맞춤형 문서 통찰력을 보려면 계정 생성을 요구하는 방안을 A/B 테스트할 경우, 계정 생성이 요구된 사용자의 전체 유지율이 요구되지 않은 사용자에 비해 1% 증가할 것으로 나타납니다.
WE3.3.11	iOS용 ‘활동’ 탭의 개선된 버전을 A/B 테스트할 경우, 읽기, 편집 및 기타 참여 행동을 강조하는 이 버전은 프로토타입 버전 대비 로그인한 독자의 탭 재방문률이 5% 증가할 것으로 예상됩니다.
WE3.4.1	우리가 하이브리드 PoP/CDN 배포를 위해 노력한다면, 그것은 필요에 따라 완전한 PoP와 미니 PoP (물리 및 클라우드) 를 모두 가져오도록 할 수 있게 해, 앞으로의 프로토타입 미니 PoM 배포의 기초를 마련할 수 있게 해 줄 것입니다.
WE3.5.1	제품·기술팀과 기금모금팀이 협력하여 플랫폼 내 기부자 식별을 위한 기술적 접근법을 평가하고 문서화한다면, 개인정보 보호, 실행 가능성, 영향력을 균형 있게 고려한 단기 및 장기적 해결책을 제안할 수 있을 것입니다. 이러한 공유된 이해는 의사결정 방향을 일치시키고, 플랫폼 간 지속적인 기부자 인식을 가능하게 하며, 향후 기금모금 관련 기능에서 보다 타겟팅된 실험을 수행하는 데 도움이 될 것입니다.
WE3.6.3	독자들의 변화하는 요구와 인터넷 상 지식의 변모하는 본질에 관한 대화에 지역사회를 참여시킨다면, 독자 서비스 방안에 대한 공동의 초점을 형성하고 다양한 아이디어(멀티미디어, 검색 및 발견, 머신러닝 관련 아이디어 포함)의 시험 여부와 방법에 대해 협력할 수 있을 것입니다.
WE3.6.4	독자들이 위키백과 및 기타 지식 플랫폼을 언제, 왜, 어떻게 사용하는지에 숨겨진 각기 다른 동기, 행동 양식, 요구 사항을 연구한다면, 소비자 전략을 위한 우선순위 분야와 구체적인 실행 방안을 제안할 수 있을 것입니다.
WE3.6.5	제품·기술팀과 기금모금팀이 플랫폼 내 기부 기회 다각화 및 기부 독자 관리·인정 방안에 대한 공동 전략을 수립할 경우, 소비자 전략 및 기금모금 전략과 연계된 명확하고 일관된 목표와 지표를 설정할 것입니다.
WE3.6.6	통합 측정 전략을 수립하면 소비자의 다년간 전략을 평가할 수 있게 되며, 지표 개발 및 보고 역량을 안내할 로드맵을 정의할 수 있습니다.
WE4.1.1	비응급 상황용 최소한의 실행 가능한 절차의 프로토타입을 개발하고, 확장된 권한을 가진 사용자와 함께 개발하는 동안 반복적인 피드백 루프를 열어두면, 해당 그룹들이 이 프로세스의 확대 적용을 지원할 것입니다.
WE4.1.3	10월 말까지 7개 위키백과(프랑스어, 독일어, 스페인어, 헝가리어, 이탈리아어, 폴란드어, 포르투갈어)를 업데이트하면, DSA 요건에 따른 새로운 법적 고지문 도입 1단계를 완료하게 됩니다.
WE4.1.4	사고 보고 시스템 MVP를 최소 15개 위키에 배포하고, 특히 규모가 크고 복잡한 커뮤니티에 중점을 둔다면, 커뮤니티가 의도된 대로 이를 사용하는 모습을 관찰할 수 있을 것이며, 비상 상황이 아닌 사고 보고를 위한 작동 모델을 입증하게 될 것입니다.
WE4.1.5	학대 사건이 보고되는 위키에 대해 학대 처리 절차가 마련되지 않은 경우, 해당 위키에 대한 사건 보고 시스템을 도입하도록 장려하고, 그러한 위키의 사용자들이 명확하고 실행 가능한 지원 경로를 확보할 수 있도록 하기 위한 사건 보고 흐름도를 설계한다면, 이는 해당 위키에서 사건 보고 시스템의 채택을 촉진할 것입니다.
WE4.2.3	hCaptcha 계정 생성 평가판의 데이터를 분석하면 계정 생성 유입 경로, hCaptcha의 퍼즐 및 점수 효과를 파악하고 계정 생성 시 hCaptcha의 추가 도입를 알리는 데 필요한 데이터를 확보할 수 있습니다.
WE4.2.5	연구를 수행하고, 커뮤니티와 협의하며, 기술적 해결책을 탐구한다면, 모든 WMF 위키에서 활용 가능한 체계적인 차단 사유 집합을 정의할 수 있을 것입니다.
WE4.2.6	데이터 플랫폼에 OpenSearch 기반 클러스터를 배포할 수 있는 역량을 개발하면, 제품 기능 엔지니어링 팀은 이 기능을 통합하는 시스템을 상당한 자율성, 복원력 및 다른 검색 기반 시스템과의 격리 상태로 개발할 수 있게 될 것입니다. 이 시스템의 첫 번째이자 주요 사용자는 IPoid 서비스가 될 것입니다.
WE4.2.7	여러 운영 중인 위키백과 사이트에 hCaptcha Enterprise 통합을 시범 운영으로 배포하면, 악용 방지, 봇 탐지, 사용성 및 접근성 측면에서 hCaptcha Enterprise의 효과와 가치에 대한 데이터를 수집할 수 있을 것입니다.
WE4.2.8	hCaptcha 프록시의 가용성과 관측 가능성을 개선하여 프로덕션 환경에 적용 가능한 상태로 만든다면, 1분기 내에 제품을 위키백과에 제공해 보다 안정적이고 신뢰할 수 있는 서비스를 제공할 수 있을 것입니다.
WE4.2.9	hCaptcha SDK를 네이티브 모바일 앱에 통합하고, 네이티브 앱 사용자 경험을 평가하며, 계정 생성 API의 일부로 hCaptcha 챌린지 활성화 여부를 평가한다면, 계정 생성 API에 대한 hCaptcha의 추가 도입을 결정하는 데 충분한 이해를 얻을 수 있을 것입니다.
WE4.2.11	위험도가 높은 편집 시나리오에서 봇 탐지를 위해 hCaptcha를 활성화하면, hCaptcha가 자동화된 악용을 줄일 수 있음을 확인할 수 있습니다.
WE4.2.16	관련 WMF 팀과 협의하면, 비공개 데이터에 대한 보다 세분화된 사용자 접근 권한을 관리하고 비공개 방어적 소프트웨어 규칙의 배포를 지원하기 위한 합의된 계획을 수립할 수 있을 것입니다.
WE4.2.17	편집자 기록 프로토타입에서 잠재적 악용 행위의 신호 최소 2개를 식별하기 위해 실생활의 예시를 분석하고 검사관을 인터뷰하면, 제품 안전 및 무결성팀은 추후 이러한 신호들을 ‘추천 조사’ 기능에 통합할 수 있게 될 것이며, 해당 신호들이 가치를 제공할 것이라는 확신을 더 높은 수준으로 가질 수 있을 것입니다.
WE4.3.2	HTTP 클라이언트 행동을 요약하는 JA4H 지문을 배포하면 봇 트래픽을 더 효과적으로 식별하고 분류할 수 있을 것입니다.
WE4.4.1	파일럿 테스트 참가자의 피드백을 바탕으로 개선을 이루어내고 모든 프로젝트에 임시 계정을 도입한다면, 등록되지 않은 사용자의 개인 식별 정보(IP 주소) 노출을 전체 프로젝트에서 전체(등록된) 사용자의 0.1% 미만으로 제한할 수 있을 것입니다.
WE4.4.2	운동의 이해 당사자 (위키 커뮤니티와 글로벌 고급 권한 보유자)와 명확하고 적절한 시기에 소통한다면, 남은 모든 위키에 배포할 수 있게 될 것이며, 막판에 발견된 작업량을 줄이고 배포의 롤백을 피할 수 있을 것입니다.
WE4.4.5	임시 계정을 이용해 훼손 행위를 하는 악성 사용자를 순찰자가 식별하는 데 드는 마찰을 줄인다면, 임시 계정이 허용되는 모든 위키에서 복구율이 증가하지 않음을 측정함으로써 훼손 행위 증가를 방지할 수 있을 것입니다.
WE4.4.6	If we sunset the LiquidThreads extension, we will unblock Temporary Accounts being deployed to all projects that currently use this extension.
WE4.6.1	Zendesk에서 비밀번호 재설정을 위한 계정 동기화 프로세스를 자동화하면 T&S의 부담이 줄어들고 더 많은 2FA 재설정 요청을 처리할 수 있습니다.
WE4.6.3	확인된 이메일 주소를 가진 모든 사용자가 자신의 계정에 2단계 인증을 활성화할 수 있도록 허용하되, 이 변경 사항을 사용자에게 적극적으로 알리지 않는다면, 복구 지원 데스크의 업무량은 지속 가능한 수준을 유지할 수 있을 것입니다.
WE4.6.4	2단계 인증 시스템의 사용자 경험 개선 작업을 계속하고 패스키 지원을 추가한다면, 더 많은 사용자가 여러 인증 요소를 등록하게 되어 계정 접근 권한을 잃는 위험으로부터 더 잘 보호받을 수 있을 것입니다.
WE4.6.5	지역 또는 글로벌 그룹 구성원이 충족해야 하는 요구사항을 명시하기 위한 일반적인 프레임워크를 설계하고 구축한다면, 이 프레임워크를 활용하여 임시 계정 IP 뷰어 그룹 구성원이 기존 정책 요구사항을 준수하도록 강제할 것입니다.
WE4.6.6	확장된 권한을 가진 사용자(UWER)가 사용자 스크립트에 어떻게 의존하는지 연구한다면, UWER 커뮤니티가 지지할 수 있는 계획을 제안할 수 있을 것입니다. 이를 통해 사용자 스크립트 시스템을 의미 있게 보호할 수 있는 하나 이상의 중대한 기술적 개입을 수행할 수 있을 것입니다.
WE4.6.7	모바일 로그인 경험을 웹 플랫폼과 일치시키기 위해 네이티브 모바일 앱에 필요한 사용자 경험 및 기술적 변경 사항을 평가하고, OAuth와 같은 대체 메커니즘을 탐구함으로써 통합의 실행 가능성을 판단할 수 있습니다. 이는 사용자에게 보다 안전하고 일관된 경험을 제공하기 위함입니다.
WE4.6.8	1분기에 만든 Zendesk 및 MediaWiki 형식의 영향을 모니터링한다면, 우리는 향후 4분기에 대한 기술적 개입을 제안할 수 있습니다.
WE5.1.2b	API 게이트웨이에 개발자 식별 및 인증을 위한 여러 방법을 통합하면, 서로 다른 사용자 집단에서 오는 요청을 정확히 식별함으로써 각 요청에 적절한 속도 제한을 할당할 수 있습니다.
WE5.1.3b	REST 게이트웨이의 최소 3개 경로에서 속도 제한에 대한 시뮬레이션을 수행하면, 리소스 소비 측면에서 속도 제한의 실행 가능성을 검증하고 사용자 영향 최소화로 적용 가능한 초기 제한값 세트를 정의할 수 있습니다.
WE5.1.4b	제안된 API 사용자 세분화 메커니즘을 더 광범위한 데이터 세트와 식별된 그룹에 대한 수동 검토를 통해 검증한다면, 사용자 코호트를 최종 확정하고 계산에 사용된 방법론을 개선하며 그 효과를 더 잘 이해할 수 있을 것입니다.
WE5.1.5	미디어위키 플랫폼 팀과 트래픽 식별 및 속도 제한 분야에서 협력한다면, 플랫폼 팀이 해당 기능을 생성하고 배포하는 것을 지원함으로써 프로덕션 환경에서 드라이 런 테스트를 위한 속도 제한을 적용할 수 있을 것입니다.
WE5.2.1b	새로운 REST API 탐색기의 잠재적 사용자와 소통한다면, 이는 새로운 디자인이 사용하기 쉬운지, 개발자의 사고 방식과 부합하는지 여부를 나타내는 핵심 사용성 통찰력을 파악하는 데 도움이 될 것입니다.
WE5.2.2b	중앙 API 게이트웨이를 통해 Action API를 라우팅하면 트래픽과 사용 패턴을 일관되게 측정하여 향후 의사 결정과 실행에 필요한 통찰력을 얻을 수 있습니다.
WE5.2.4	2개의 API에 대한 표준 문서 패턴을 구현하면, 우리는 콘텐츠 지침을 정비하고, API 소유자가 지침을 채택하기 위해 필요한 것을 이해하고, 나머지 위키미디어 API 문서에서 지침을 구현하는 데 필요한 노력을 수치화할 수 있습니다.
WE5.2.5	미디어위키 REST API에 OpenAPI 사양 린팅 규칙을 정의하고 적용하는 실험을 수행한다면, 위키미디어와 우리 커뮤니티 전반에 걸쳐 공개되는 API의 품질과 일관성을 개선하기 위해 API 스타일 가이드를 프로그래밍 방식으로 강제 적용하는 방법을 제시할 수 있을 것입니다.
WE5.2.6	사이트맵 API에 대한 접근 제어를 도입하여 신뢰할 수 있는 봇만 접근할 수 있도록 하면 전략적 연계를 강화하고 악의적인 스크래핑 위험을 줄일 수 있습니다.	phab:T406921
WE5.3.1	기존 지침을 업데이트하면서 UX 기여도 분석 지침을 확장하고 간소화한다면, 내부 테스트를 거쳐 반복적으로 개선되어 더 광범위한 공개 사용을 준비할 수 있는 핵심 개선 지침 세트를 마련할 수 있을 것입니다.
WE5.3.1b	UX 가이드라인 초안과 데모를 공개하고 반복 개선해 나간다면, 내부 테스트를 거쳐 점진적으로 다듬어 더 넓은 공개 사용을 준비할 수 있는 핵심 프레임워크를 구축할 수 있을 것입니다.
WE5.3.2	위키백과 출처를 제3자 콘텐츠 재사용자와 최종 사용자에게 명시하는 것의 이점을 보여주는 프레젠테이션을 제작한다면, 최소한 한 곳 이상의 추가 재사용 파트너가 1분기 말까지 출처 표시 사례 연구 또는 데모에 참여하는 데 동의하도록 유도함으로써 WME4.1 및 WME4.2를 지원할 수 있습니다.
WE5.4.2b	확장 가능한 방식으로 알려진 클라이언트를 식별할 수 있다면, 검증된 출처의 봇에 대해 일반적인 속도 제한에 예외를 허용하고 규칙을 체계적으로 시행하는 방향으로 나아갈 수 있습니다.
WE5.4.5	개별 클라이언트 유형별로 맞춤화된 속도 제한을 적용하기 시작하면, 크롤링이 인프라에 주는 부담을 줄일 수 있을 것입니다.
WE5.4.6	2분기 말까지 상위 N개 스파이더를 알려진 봇으로 분류하면, 이들이 사용하는 리소스 양을 제한할 수 있습니다.
WE5.4.7	미디어 인프라에서 허용되는 표준화된 썸네일 크기 세트를 정하고, 가장 비용이 많이 드는 크기들을 미리 생성하며 다른 이미지 크기 생성에 대한 속도 제한을 적용한다면, 미디어 서비스 인프라의 부하를 줄일 수 있을 것입니다.
WE6.1.2	위키팜을 병합 전 테스트 환경에 추가하면, 개발 팀이 프로덕션 환경을 대상으로 개발할 때 여러 위키를 활용해 패치를 독립적으로 테스트할 수 있게 됩니다. 이를 통해 개발 팀은 프로덕션 이전 단계에서 더 큰 확신을 얻을 수 있으며, 결과적으로 결함 유출이 줄어들 것입니다.
WE6.2.1	서비스가 프로덕션 준비 완료 상태로 간주되기 위한 전제 조건을 명확히 정의하고 자체 처리 가능한 작업과 함께 프로덕션 준비 체크리스트를 검토 및 공개하면, SRE와 개발 팀 간의 기대치를 일치시켜 전반적인 운영 효율성과 확장성을 개선할 수 있습니다.
WE6.2.2	개발자들을 위해 많은 번거로운 작업을 추상화하는 Golang 및 nodejs 라이브러리 제작을 발표하면, 그들은 피드백과 관심을 표하며 반응할 것입니다.
WE6.2.4	만약 우리가 데이터 지속성 설계 검토를 적극 지원하고 적용한다면 생산으로 이어지는 포장된 경로를 식별할 수 있습니다.
WE6.3.2	새로운 지표를 개발하고, Parsoid의 캐시 인프라를 개선하며, 상위 10개 위키백과에 배포한다면, 신뢰도 프레임워크의 성능 기준을 수립할 수 있을 것입니다. 이는 다른 대규모 위키에 배포할 준비 상태를 검증하고, 대규모 트래픽을 처리할 수 있는 능력을 입증하는 데 도움이 될 것입니다.
WE6.3.3	2분기에 핵심 언어 변형 지원 개선 사항을 구현하고 최소 3개 언어 변형 위키에 Parsoid를 성공적으로 배포할 경우, 나머지 모든 언어 변형 위키에 자신 있게 확장하기 위해 필요한 주요 기술적 과제를 파악하고 해결할 수 있을 것입니다.
WE6.4.6	SRE가 미디어위키 엔지니어링 팀에 지원(용량 및 트래픽 관리, 구성 변경 준비 및 검토, 문제 조사 및 해결을 위한 협업)을 제공한다면, 우리는 함께 2분기에 프로덕션 환경 PHP 8.3 업그레이드를 완료하고 향후 업그레이드 시 SRE에 대한 핵심 경로 의존성을 최소화하기 위한 권장 사항 세트를 문서화할 것입니다.	T360995
WE6.4.7	글로벌 루트 권한을 가진 전체 사용자의 최소 90%가 위키미디어 운영 서버 접근 시 하드웨어 기반 SSH 키를 사용하도록 전환한다면, 해킹된 노트북으로 인한 심각한 보안 침해 위험을 줄일 수 있습니다.
WE6.4.8	미디어위키 엔지니어링 팀이 PHP 업그레이드와 관련된 미디어위키 내 문제를 적극적으로 모니터링하고 해결한다면, 이는 SRE 팀이 2025년 11월까지 프로덕션 환경의 PHP 8.3 업그레이드를 완료할 수 있도록 할 것입니다.	T360995

신호 및 데이터 서비스(SDS) 가설 [ SDS 주요 결과 ] 토론
가설 단축명	2분기 텍스트	세부사항 및 토론
SDS1.2.1	현재 ‘Dumps 1’ 인프라에서 XML 덤프 프로세스를 미디어위키 콘텐츠 파이프라인을 활용하는 데이터 파이프라인으로 이전하면 서비스 수준 목표(SLO)를 보장하고 ‘Dumps 1’ 기반 XML 내보내기를 중단할 수 있습니다.
SDS1.2.2	미디어위키 콘텐츠 히스토리 및 이벤트 플랫폼/이벤트 게이트의 서비스 수준 목표(SLO)를 검토하고 워크스루를 수행하면, 고객, 지표 및 관련 이해관계자를 검증하고 SLO에 필요한 개선 사항을 식별할 수 있습니다. 이는 주간 납품 보증의 미비점을 명확히 하는 데 도움이 될 것입니다.
SDS1.3.1	클라이언트 측 신호를 도입하고 서버 측 웹 요청 로그와 비교하여 감사하면, 추가적인 봇 패턴을 발견할 수 있으며 이를 특성화할 수 있습니다.
SDS1.3.2	현재 봇 대 인간 비율을 기준선으로 가정하고, 이 분포의 변화에 대한 자동화된 경보를 생성한다면, 예측 불가능한 자동 트래픽 패턴의 탐지 시간을 몇 주에서 몇 분으로 단축할 수 있을 것입니다.
SDS1.3.3	웹 요청에 대한 백필 메커니즘을 자동화하고 이를 5월 로그에 적용하면, 향후 사고에 대한 대응 시간을 수개월에서 수일로 단축하고 “5월 페이지뷰 증가” 사고를 해결할 수 있습니다.
SDS1.3.4	봇 분류 결과에 대한 정기적이고 운영화된 내부 감사 프로세스를 구축한다면, 솔루션에 대한 신뢰를 확보하고 자동으로 탐지되지 않는 트래픽 패턴의 변화를 예측할 수 있을 것입니다.
SDS1.3.5	기본 클라이언트 측 신호를 분석하여 우리의 휴리스틱에 통합하면, 데이터 플랫폼에서 추가적인 봇 패턴을 탐지할 수 있을 것입니다.
SDS1.3.6	Spur.us IP 평판 정보를 가져와 분석하고 우리의 휴리스틱에 통합하면, 데이터 플랫폼에서 추가적인 봇 패턴을 탐지할 수 있을 것입니다.
SDS1.3.7	가장자리에서 하나의 신호를 가져와 분석하고 우리의 휴리스틱에 통합하면, 데이터 플랫폼에서 추가적인 봇 패턴을 탐지할 수 있을 것입니다.
SDS1.4.1	위키미디어 생태계 내 추세에 대한 기존 분석(페이지뷰, 기여자 및 독자 지표, 트래픽 등)을 재확인한다면, 우리는 가장 중요한 운동 통찰력을 위한 핵심 논점을 확신 있게 뒷받침할 수 있을 것입니다.
SDS1.4.2	위키미디어 생태계 내 추세에 대한 기존 분석(페이지뷰, 기여자 및 독자 지표, 트래픽 등)을 재확인한다면, 우리는 가장 중요한 운동 통찰력을 위한 핵심 논점을 확신 있게 뒷받침할 수 있을 것입니다.
SDS2.1.1	실험을 진행하는 팀과 긴밀히 협력한다면, 향후 시스템을 더욱 셀프 서비스화하는 방법과 그들이 직면할 수 있는 개념적·기술적 과제를 파악할 수 있을 것입니다.
SDS2.1.2	이벤트 로깅에 대한 더 나은 디버깅 기능을 구현할 수 있다면, 제품 팀은 실험이 예상대로 이벤트 데이터를 수집하고 있음을 확인할 수 있어 실험 담당자의 신뢰도를 높일 수 있습니다.
SDS2.1.3	실험 플랫폼의 A/B 테스트 시스템(xLab) 구성 요소와 관련 미디어위키 부분에 대한 로깅 및 가시성을 개선하면 시스템 성능에 대한 기준선을 설정하고 실험 관련 장애에 대응할 수 있을 것입니다.
SDS2.1.4	매월 한 번씩 조직 전체에 실험 사례와 결과를 공유한다면(제품 운영 회의, 디자인 팀 회의, 팀 간 발표를 통해), 실험 플랫폼의 자연스러운 채택이 이루어질 것입니다.
SDS2.1.5	사용자에게 xLab에서 생성된 그들의 도구가 위험 범주를 변경하는 속성 집합을 포함한다고 알리면, 도구 사용자들이 데이터를 과도하게 수집하는 것을 억제하고 어떤 속성 조합이 개인정보 보호 검토를 필요로 하는지에 대한 명확성을 높일 수 있습니다.
SDS2.1.6	성장 팀이 실험 연구소와 협력하여 두 가지 사용 사례(버킷팅 기능에 대한 통찰력을 얻기 위한 A/B 테스트와 KPI 유사 지표 지원 학습을 위한 장기적 계측)를 계측한다면, GrowthExperiments의 맞춤형 실험 설정을 대체하기 위한 요구 사항을 충분히 충족하는지 평가할 수 있습니다.

잠재적 청중 (FA) 가설 [ FA 주요 결과 ] 토론
가설 단축명	2분기 텍스트	세부사항 및 토론
FA1.1.4	[전년도 회계연도에서 이어짐] 로블록스(Roblox)에 새로운 위키백과 경험을 구축한다면, 이것이 젊은 세대(알파 세대)에게 우리 브랜드를 소개하는 효과적인 방법이 될 수 있는지 확인할 수 있을 것입니다.
FA1.1.2	itch.io에 새로운 위키백과 경험을 위한 중앙 허브를 구축한다면, 50명 이상의 관심 있는 비위키백과 사용자로 구성된 피드백 제공자 집단을 성장시킬 수 있을 것입니다. 이를 통해 게임에서 효과적인 요소와 그렇지 않은 요소를 파악하는 데 도움이 될 것입니다.
FA2.2.1	단편 동영상 플랫폼 전반에 걸쳐 커뮤니티 관리에 투자한다면, 2025년 12월 2분기 말까지 (2025년 12월)까지 TikTok 신규 시청자 비중이 전분기 대비 30% 증가할 것이며, 모든 SFV 플랫폼에서 외부 콘텐츠에 남긴 브랜드 댓글에 총 50,000건의 상호작용(좋아요 및 답글)을 확보할 수 있습니다. 이는 현재 도달하지 못하는 대상과의 가시성 향상과 참여도 증진에 기여할 것입니다.
FA2.2.2	위키백과 크리에이터 파트너십 프로그램의 내부 전략 및 대외 공유 자료(크리에이터에게 제공하는 가치 개요, 파트너십 기준, 계약 절차, 크리에이터 콘텐츠가 자사 채널 및 크리에이터 채널에 노출되는 방식 포함)를 개발하고 승인을 받으면, 지식 콘텐츠로 소셜 미디어 전반에 걸쳐 새로운 관객층에 도달하는 데 도움이 될 견고한 크리에이터 전략을 수립할 수 있을 것입니다.

제품 및 엔지니어링 지원 (PES) 가설 [ PES 주요 결과 ] 토론
가설 단축명	2분기 텍스트	세부사항 및 토론
PES1.1.5	Sloth/Pyrra에 미디어위키 콘텐츠 히스토리 및 위키함수 서비스 수준 목표(SLO)를 도입하면, 추가로 2개의 SLO가 프로덕션 환경에 적용됩니다.
PES1.1.6	기존 SLO의 소급 데이터를 활용해 Sloth를 시범 운영하면, 오류 예산 창에 대한 고정 창 접근 방식에 적합한 도구가 Pyrra인지 Sloth인지(혹은 다른 도구인지) 파악할 수 있습니다. 이를 통해 서비스 소유자가 SLO 지표를 자율적으로 관리하고 의사 결정에 활용할 수 있도록 지원하는 방법을 학습하게 될 것입니다.
PES1.2.4	1분기에 3개 팀과 함께 분기별 희망사항 및 커뮤니티 신호 검토 프로세스를 시범 운영한다면, 제품 관리자들이 커뮤니티 신호를 분기별 및 연간 계획 수립 과정에 통합하도록 유도할 수 있을 것입니다.
PES1.2.5	위시리스트 확장 기능에 태그 분류 및 투표 기능을 추가한 개선 사항에 필터링 및 정렬 기능을 더하면, 이 세 가지 개선 사항으로 위시리스트의 고유 참여자가 최소 30% 이상 증가할 것입니다.
PES1.3.3	사용자 상호작용을 기반으로 플랫폼에서 최소 5가지의 즐거운 개입을 생성하면, 포털 페이지와 생일 모드 가젯의 트리거를 정의할 것입니다. 사용성 테스트를 통해 어떤 개입이 우리 브랜드와 긍정적인 연상을 형성하는지 파악할 수 있습니다. 이 가설은 10월 말 위키컨퍼런스 북아메리카 행사 종료 시까지 완료될 예정입니다.
PES1.3.4	커뮤니케이션 부서 구성원과 협력하여 위키백과의 역사, 현재, 미래를 탐구하는 몰입형 웹사이트를 제작하면, 캠페인 대상 지역의 18~34세 온라인 관객 참여를 유도할 수 있습니다. 이는 소셜 공유 및 기타 온라인 활동을 통해 위키백과와의 유대감을 증진시킬 것입니다. 이는 커뮤니케이션 부서의 핵심 성과 지표인 브랜드 인지도 10% 포인트 상승에 기여하는 동시에, 콘텐츠에 대한 역동적인 접근 방식이 브랜드 호감도를 향상시키는지 여부를 알려줄 것입니다.

3분기

WMF 연간 계획의 (3분기)는 2026년 1월부터 3월까지를 포함합니다.

위키 경험 (WE) 가설 [ WE 주요 결과 ] 토론
가설 단축명	3분기 텍스트	세부사항 및 토론
WE1.1.3	편집팀이 VE 내에서 URL 매개변수를 통해 초기 편집 제안 세트를 제공하고 10명 이상의 신규 사용자와 순찰대원을 초대하여 피드백을 요청하면, 통제된 실험을 통해 개입의 효과를 평가하기 전에 어떤 개선이 필요한지 파악할 수 있습니다.
WE1.1.4	만약 통제된 실험을 통해 en.wiki에 참조 확인 기능을 배포한다면, 신규 자원봉사자들이 게시하는 건설적인 편집 내용이 4% 이상 증가하는 것을 확인할 수 있을 것이며, 이 기능을 더 널리 활성화하기 위해 점검자와 조정자 사이에서 충분한 지지가 있는지 알아볼 수 있을 것입니다.
WE1.1.12	Tone Check를 확장하려는 10개 언어 각각에 대해 3명 이상의 자원봉사자가 각각 30개 이상의 샘플 편집 내용을 평가하도록 하면, 자원봉사자들이 모델 예측에 동의하는 빈도를 파악하고 Tone Check를 배포할 새로운 위키를 결정할 수 있을 것입니다.
WE1.1.14	AI 모델이 중립적이지 않은 언어를 사용하는 것을 감지했을 때, 신규 자원봉사자들에게 글의 어조를 고려하도록 유도한다면, WP:NPOV(및 관련 정책) 위반을 이유로 신규 자원봉사자들이 게시한 새로운 콘텐츠 편집 내용이 되돌려지는 비율이 4% 이상 감소할 것입니다.
WE1.1.17	만약 우리가 '어조 수정' 구조화된 작업에 대한 작업 생성 엔진을 개발하고, 어떤 콘텐츠를 포함하거나 제외해야 하는지에 대한 최근 학습 내용을 통합하고, 작업 목록을 자동으로 갱신하는 파이프라인을 제공한다면, 생성된 작업에 대한 정성적 평가와 이러한 유형의 작업이 신규 편집자의 건설적인 편집 활동에 도움이 되는지 여부를 테스트하는 A/B 실험을 수행할 수 있을 것입니다.
WE1.1.18	Revise Tone 구조화된 작업 A/B 테스트 시작 후 약 2주 후에 미리 정해진 선행 지표들을 분석하면, 해당 기능의 영향을 확신 있게 평가하기 전에 조정하거나 조사해야 할 전체적인 사용자 경험의 측면이 무엇인지(있다면) 파악할 수 있을 것입니다.
WE1.1.19	모바일 웹에서 사용자가 처음 탭한 편집 아이콘과 관계없이 모든 기사 섹션을 편집할 수 있도록 하면, 신규 사용자의 모바일 편집 포기율이 #% 감소할 것입니다. 이는 사용자가 편집하려는 콘텐츠를 더 쉽게 찾을 수 있기 때문입니다.
WE1.1.20	성장팀에서 "링크 추가" 작업을 최소 10개 이상의 위키백과로 확장하면, 선행 지표 분석을 통해 해당 작업이 예상대로 수행되고 있는지 확인하고 추가 검토가 필요한 위키를 파악할 수 있습니다.
WE1.1.21	새로운 링크 추가 모델 버전을 새로 추가된 위키와 현재 링크 추가 기능을 사용 중인 위키 모두에 배포하면, 성장 팀은 이전에 링크 추가 기능이 없었던 위키에도 이 기능을 구조화된 작업으로 추가할 수 있으며, 이미 이 기능을 사용하고 있는 위키는 최신 학습 데이터와 향상된 오프라인 성능을 갖춘 업데이트된 모델을 받게 됩니다.
WE1.1.22	초기 "위키백과에 오신 것을 환영합니다" 인증 이메일을 개선하면 이메일 주소를 인증하는 신규 계정 비율이 증가할 것입니다. 이를 통해 성장팀은 후속 이메일을 통해 해당 계정들과 다시 소통하고 토론 페이지 알림을 받을 수 있도록 할 수 있습니다.
WE1.1.23	다양한 영어 위키백과 문서 150개를 표본으로 삼아, 시중에 나와 있는 범용 인공지능(GenAI) 모델을 활용하여 편집 제안을 생성하고 순위를 매겨보면, 이러한 범용 모델이 대규모로 처리할 수 있는 편집 작업 유형을 파악하고, 제안의 유용성을 대략적으로나마 경험적으로 이해할 수 있습니다. 이러한 초기 분석 결과를 통해 특정 작업 유형이 범용 모델(미세 조정 여부와 관계없이)로 대규모 처리가 가능한지, 아니면 보다 특화된 접근 방식이 필요한지 평가할 수 있으며, 궁극적으로 "단일 모델로 다양한 제안 생성"이라는 방향이 타당한지 검증할 수 있습니다.
WE1.1.24	만약 신규 자원봉사자가 외부 사이트에서 텍스트를 복사하여 붙여넣을 때, 해당 콘텐츠를 직접 작성했는지 확인하는 메시지를 표시하도록 하면, 신규 자원봉사자가 게시한 새 콘텐츠 편집 내용 중 저작권 침해(및 관련 정책)를 이유로 되돌려지는 비율이 4% 이상 증가할 것으로 예상됩니다.
WE1.2.6	이벤트 등록을 통해 목표 설정 기능을 개발하면 이벤트 등록을 통한 협업이 더욱 활발해질 것입니다.
WE1.3.3	신규 편집자에게 관리자 대시보드를 보여주는 실험을 진행했을 때, 대시보드를 방문하는 기여자의 10%가 2주 연속으로 방문하는 것으로 나타났습니다.
WE1.3.4	만약 유해성/선의 모델이 없는 150개 이상의 위키백과에 '위험 되돌리기' 필터를 적용한다면, 개인 조정자 대시보드를 사용하는 기여자의 관리자 점검 횟수가 대시보드에 접근할 수 없는 기여자에 비해 증가하는 것을 확인할 수 있을 것입니다.
WE1.5.1	7가지 기여자 지표를 탐색할 수 있는 대시보드를 구현하고 dbt를 활용해 최소 한 가지 지표의 계산 방식을 표준화한다면, 기여자 제품 팀이 지표 인사이트를 자체적으로 활용할 수 있도록 지원하고 지표 계산 로직 저장 방식을 표준화할 수 있습니다.
WE1.5.3	데이터 엔지니어링 팀이 3분기 말까지 편집 유형 데이터 제품을 상용화하면 측정하기 "복잡한" 6가지 관리자 작업이 "간단한" 작업으로 바뀌게 되어 운동 통찰력은 다음 단계로 월간 활성 조정자 지표를 정의할 수 있게 됩니다.
WE1.5.4	현재 이용 가능한 조정자 지표를 활용한 프로토타입 대시보드를 제작하면 4분기 말까지 완전한 대시보드를 제공할 수 있을 것입니다.
WE1.6.1	사용자 지정 주시 목록 라벨 기능을 도입할 경우, 첫 달에 주시 목록에 100개 이상의 페이지를 보유한 사용자 중 5%가 해당 라벨을 사용할 것으로 예상합니다.
WE2.2.13	위키낱말사전 커뮤니티에 동사 활용표 기능의 활용 가능성을 알리면 편집자들의 이해도와 사용 편의성에 대한 초기 의견을 수렴하여 향후 개선 방향을 설정할 수 있을 것입니다.
WE2.2.20	Parsoid가 활성화된 위키에 위키함수를 배포하면, 점진적으로 확대되는 배포 환경에서도 시스템의 성능과 사용성이 유지되는지 지속적으로 테스트할 수 있습니다.
WE2.2.21	평가기에서 제한된 수의 재진입 함수를 허용하면 평가된 구현에 대한 의존도를 높여 백엔드에서 가장 성능이 뛰어난 부분을 활용할 수 있습니다.
WE2.2.22	작곡 언어에 대한 명시적인 인터프리터를 작성하면 오케스트레이터의 성능이 향상되고, 추가적인 성능 향상 기능을 구현하기도 더 쉬워집니다.
WE2.2.23	기여자들이 여러 함수에서 전체 구성 블록을 재사용할 수 있도록 하면 반복적인 작업을 줄이고 특히 유사한 언어 기능에 대해 새로운 구현을 생성하는 속도를 크게 높일 수 있습니다.
WE2.2.24	명확한 문서 구조와 진입점을 정의하면 함수 생성자는 관련 지침을 더 쉽게 찾고 함수 생성 과정에서 발생하는 어려움을 줄일 수 있습니다.
WE2.2.25	함수 생성 과정에서 가장 큰 불편을 초래하는 부분을 체계적으로 파악하면, 함수 생성 및 반복 작업을 더욱 효율적으로 만들어주는 몇 가지 핵심적인 개선 사항을 찾아낼 수 있습니다.
WE2.2.26	요약 위키백과에 대해 팝업을 통한 간편하고 로컬 참조 솔루션을 도입하면, 보다 복잡한 솔루션이 필요한지 여부를 판단할 수 있는 초기 인용 메커니즘을 구축할 수 있습니다.
WE2.3.4	만약 우리가 추상 위키백과 플랫폼의 초기 버전을 개발하고 출시한다면, 여러 언어에 걸쳐 작동하는 생태계의 기술적 실현 가능성을 입증할 수 있을 것입니다.
WE2.3.5	구체적인 추상적 콘텐츠 사례를 통해 자원이 부족한 소수의 위키백과 언어 커뮤니티와 소통함으로써, 해당 커뮤니티의 로컬 위키 외부에서 생성된 콘텐츠가 수용 가능한지 여부를 검증하고 채택에 필요한 조건을 파악할 수 있습니다.
WE2.3.6	추상 위키백과 콘텐츠가 지역 위키백과 내에서 어떻게 표시되고 제공되는지, 그리고 지역 커뮤니티가 통합 결정을 내리는 방식을 설계한다면, 제안을 공유하고 합의에 도달하여 4분기 개발 작업을 자신 있게 계획할 수 있을 것입니다.
WE2.5.1	eqiad에 블레이즈그래프 대체 후보를 배포하고 기존 평가 작업에 프로덕션 WDQS 트래픽 재생 분석을 추가하면 새 백엔드가 기존 백엔드와 유사한 성능을 보이고 실제 SPARQL 쿼리를 지원하며 주변 생태계(UI, 모니터링, 온보딩 및 실시간 인덱스 업데이트 파이프라인)가 준비되면 제한적인 실시간 트래픽 노출에 적합한지 확인할 수 있습니다.
WE2.5.2	위키데이터 플랫폼에 대한 접근 지침을 정의하면 백엔드 마이그레이션 시 WDQS 서버에 가해지는 부하를 더 효과적으로 제어할 수 있을 것입니다.
WE2.5.3	새로운 백엔드 시스템을 테스트할 사용자 페르소나 그룹을 정의하면 블레이즈그래프 전환의 파일럿 단계 및 후속 단계를 위한 준비를 갖출 수 있습니다.
WE2.5.4	마이그레이션 계획을 단일 문서로 작성하면 마이그레이션의 모든 측면에 대해 의견을 조율하고 실행을 추진할 수 있습니다.
WE2.5.5	만약 우리가 위키데이터 되돌리기 위험 모델을 저지연 추론에 최적화하고 LiftWing에 안정적이고 확장 가능한 방식으로 배포한다면, 위키미디어 엔터프라이즈 팀은 되돌리기 위험 신호를 제품 파이프라인에 통합하여 고객에게 시의적절하고 고품질의 모델 결과를 제공할 수 있을 것입니다.
WE3.1.8	외부 참여자를 대상으로 두 가지 의미 검색 프로토타입(자연어 검색, 질의응답)을 평가하면 사용자들이 개선된 검색 도구에 가치를 느끼는지 여부를 파악하고, 독자팀에 검색 및 발견 MVP 개발을 위한 권장 사항을 제공할 수 있습니다.
WE3.1.12	대표적인 질의와 관련 검색 결과에 대한 주석으로 구성된 벤치마크 데이터셋을 수집하면, 오프라인(즉, 사용자 연구 없이)에서 다양한 검색 모델의 검색 결과 품질에 대한 평가를 수행할 수 있습니다.
WE3.1.15	키워드, 자연어, 의미 기반 검색을 결합한 하이브리드 검색 MVP를 안드로이드 앱에서 테스트하면 만족도, 응답 시간, 사용자 유지율에 부정적인 영향을 주지 않으면서 전체 검색 참여도를 10% 향상시키는 접근 방식과 디자인 패턴을 신속하게 파악할 수 있습니다.
WE3.1.16	질의응답 모델에 대한 요구사항을 정의하면, 모델 결과물을 생성하여 커뮤니티와 공유하고 피드백을 수집하여 실제 운영 환경에 적용할 수 있습니다.
WE3.1.17	검색 기능이 미디어위키 엔드포인트를 포함하여 의미론적 쿼리 처리를 지원하는 안정적이고 성능이 뛰어난 벡터 검색 인프라를 제공한다면, 머신러닝 및 연구팀에서 임베딩을 생성하고 모델을 시스템에 통합하여 MVP의 임베딩 기반 검색 기능을 구현할 수 있을 것입니다.
WE3.1.18	기존 OpenSearch 스택과 호환되는 Qwen3 임베딩 추론 서비스를 배포하면 모바일 앱은 Qwen3를 통해 문서 청크 및 쿼리 임베딩을 생성하는 실험을 할 수 있으며, 이는 OpenSearch의 내장 모델에서 생성된 임베딩보다 우수한 성능을 보일 것입니다.
WE3.3.6	만약 합의된 확장성 및 가용성 요구사항을 충족하는 서비스와 필요한 데이터 보충을 통해 기사 주제 추론 데이터를 제공할 수 있다면, 이 데이터에 의존하는 향후 맞춤형 독자 경험을 지원하기 위한 필수 기술 기반을 마련하게 될 것입니다.
WE3.4.1	우리가 하이브리드 PoP/CDN 배포를 위해 노력한다면, 그것은 필요에 따라 완전한 PoP와 미니 PoP (물리 및 클라우드) 를 모두 가져오도록 할 수 있게 해, 앞으로의 프로토타입 미니 PoM 배포의 기초를 마련할 수 있게 해 줄 것입니다.
WE3.5.2	기부자에게 기부자 자격을 나타내는 배지를 제공하면, 참여를 선택한 기부자 중 최소 70%가 연계된 설문조사에서 긍정적인 반응을 보일 것입니다.
WE3.6.5	제품 및 기술 부서와 모금 부서가 플랫폼 내 기부 기회를 다양화하고 기부하는 독자를 관리 및 인정하는 공동 전략을 수립하기 위해 협력한다면, 소비자 및 모금 전략과 연계된 명확하고 일관된 목표와 지표를 설정할 수 있을 것입니다.
WE3.6.6	통합 측정 전략을 수립하면 소비자의 다년간 전략을 평가할 수 있게 되며, 지표 개발 및 보고 역량을 안내할 로드맵을 정의할 수 있습니다.
WE3.6.7	로그아웃한 사용자의 유지율에 대해 2차 A/A 테스트를 실행하면 향후 분기에 활용할 수 있는 유지율의 계절적 추세를 파악할 수 있습니다.
WE3.6.8	만약 우리가 1) 영어 위키백과를 처음 접하거나 자주 이용하지 않는 독자 및 비독자, 그리고 2) 현재 영어 위키백과 독자 집단을 동시에 대상으로 설문조사를 실시하여 이들의 정보 탐색 욕구와 행동을 체계적으로 비교한다면, 이들 집단의 인구통계학적 특성, 온라인 정보 욕구, 그리고 사용하는 온라인 플랫폼에 대한 핵심적인 통찰을 얻을 수 있을 것이며, 이를 통해 독자층 확대를 위한 잠재적 기회와 기존 독자층에 대한 잠재적 위협 요인을 파악할 수 있을 것이다.
WE3.8.1	활동 탭에 추가 모듈을 추가하고 이를 모든 사용자에게 확대 적용하면, 출시 전 대비 iOS 앱 계정 생성률이 전체적으로 5% 증가할 것으로 예상됩니다.
WE3.9.1	위키백과 iOS 앱의 시각적 기반, 구성 요소 기본값 및 탐색 동작을 애플의 리퀴드 글래스 디자인 언어에 맞춰 업데이트하고, 동시에 OS 버전 전반에 걸쳐 우선순위가 높은 대체 기능에 대한 디자인과 동작을 명확하게 정의한다면, 후속 엔지니어링 구현이 더 명확해지고 위험 부담이 줄어들 것이며, 애플이 사용자에게 전환을 강제할 때 앱이 플랫폼 네이티브 앱처럼 느껴질 것입니다.
WE3.10.1	개인 맞춤형 기능, 최신 정보임을 명확히 알려주는 표시, 그리고 반복 가능한 위키백과 고유 패턴(예: 주제별 하위 항목, 시간 제한 하이라이트, 상호작용 요소)을 활용하여 구축한 탐색 피드 디자인 프로토타입을 사용자 테스트한다면, 일반 독자 참여자들은 제안된 피드의 목적을 더 잘 이해하고, 더 빠르게 핵심 내용을 파악하며, 일상적인 사용 의향을 더 강하게 보일 것입니다. 우리가 권장하는 시각적 디자인은 이해하기 쉽고 위키미디어 운동의 취지에 부합하는 것으로 평가될 것입니다.
WE4.1.3	2분기 말까지 6개의 위키백과(영어, 프랑스어, 독일어, 스페인어, 이탈리아어, 폴란드어)를 업데이트하면 DSA 요구 사항에 따른 새로운 법적 고지문 배포 1단계가 완료됩니다.
WE4.2.5	연구를 수행하고, 커뮤니티와 협의하고, 기술적 해결책을 조사하면 모든 WMF 위키에서 사용할 수 있는 구조화된 차단 사유 세트를 정의할 수 있을 것입니다.
WE4.6.8	1분기에 구축한 젠데스크 및 미디어위키 양식의 영향을 모니터링하면 향후 분기에 계정 복구 프로세스의 나머지 부분을 더 효율적으로 자동화할 수 있는 기술적 개선 방안을 제안할 수 있습니다.
WE5.1.3c	게이트웨이를 통해 라우팅되는 모든 API에 속도 제한을 적용하면 인증된 사용자와 커뮤니티 사용자에게 더 높은 제한을 부여하는 사용자 클래스 기반 요청을 통해 백엔드 인프라에 도달하는 익명 API 요청 수를 줄일 수 있습니다.
WE5.1.5	OAuth 2.0 구현의 지속 가능성과 신뢰성을 개선한다면, 더 많은 개발자들이 OAuth를 사용하도록 설득하고, 중요한 애플리케이션에서 OAuth를 안정적으로 사용할 수 있다는 확신을 심어줌으로써 위키백과 모바일 앱의 마이그레이션을 지원할 수 있을 것입니다.
WE5.1.5b	OAuth 2.0 클라이언트 생성 및 관리에 대한 개발자 경험을 개선하면, 새로운 애플리케이션에서 OAuth 1.0 사용을 단계적으로 중단하고 API 인증을 위한 권장 옵션으로 OAuth 2.0을 장려함으로써 OAuth 2.0을 사용하는 애플리케이션 수를 늘릴 수 있을 것입니다.
WE5.2.2c	현재 API 게이트웨이를 통해 전달되는 모든 API를 공통 게이트웨이로 재라우팅하면 기존 API 게이트웨이를 완전히 폐지하고 위키미디어 커뮤니티용 HTTP/웹 API의 일관성을 유지할 수 있습니다.
WE5.2.6	사이트맵 API에 대한 접근 제어를 도입하여 신뢰할 수 있는 봇만 접근할 수 있도록 하면 전략적 연계를 강화하고 악의적인 스크래핑 위험을 줄일 수 있습니다.
WE5.2.8	만약 우리가 모든 API 확장 기능과 미디어위키 코어 내의 독립적인 기능을 위한 전용 API 모듈을 만든다면, 독립적인 관리 및 버전 관리를 통해 더 높은 품질의 문서를 강제할 수 있게 될 것입니다.
WE5.2.9	API 등록과 사양 정의 프로세스에 대한 관심사를 더 잘 분리하면 API 관리의 복잡성을 단순화하고 API 작성자에게 더 나은 개발자 경험을 제공할 수 있습니다.
WE5.2.10	v2 API 통합 및 기능 부족 부분에 초점을 맞춘 의견 청취 투어를 진행한다면 v2 구현을 더욱 신속하게 진행할 수 있을 것입니다.
WE5.2.11	현재 API 포털에 있는 문서들을 표준화하기 위한 프로세스를 실험하고 확립한다면, 정보 소스를 통합하고 문서의 일관성을 향상시킬 수 있습니다.
WE5.3.1b	UX 가이드라인 초안과 데모를 공개하고 반복적으로 개선해 나가면, 내부 테스트 및 반복적인 수정을 거쳐 더 폭넓은 공개 사용에 대비할 수 있는 핵심 프레임워크를 구축할 수 있을 것입니다.
WE5.3.2b	위키미디어 출처 표기를 실험하는 파트너 시범 프로그램을 구축하면, 재사용자들이 출처를 표기함으로써 위키미디어에 대한 참여와 기여를 촉진하는 상호 유익한 효과를 보여줄 수 있습니다.
WE5.4.6	2분기 말까지 상위 N개의 스파이더를 알려진 봇으로 분류하면 해당 봇들이 사용하는 리소스 양을 제한할 수 있습니다.
WE5.4.8	개별 클라이언트 유형별로 미디어 파일에 대한 사용량 제한을 적용하기 시작하면 인프라에 가해지는 크롤링 부담을 줄일 수 있습니다.
WE5.4.9	주거용 프록시의 IP 평판 데이터를 봇 탐지 기능에 추가하면 스크래퍼 차단 능력이 향상될 것입니다.
WE5.4.10	비표준 썸네일 크기 생성을 허용하지 않으면 백엔드 미디어 서비스 인프라에 가해지는 부담을 줄일 수 있습니다.
WE5.4.11	2025년 12월에 발생한 스크래핑/DDoS 공격 사건에서 신뢰도가 높은 두 가지 신호를 식별하여 SRE에 전달하면 SRE는 향후 유사한 사건에 대해 더욱 효과적인 자동화된 완화 규칙을 개발할 수 있을 것입니다.
WE5.4.12	이미지 요청의 출처와 요청을 확인할 수 있다면, 요청량 제한에 대해 더욱 정확한 판단을 내릴 수 있습니다.
WE6.1.2	위키팜을 병합 전 테스트 환경에 추가하면 여러 위키가 필요한 프로덕션 환경용 개발 팀이 패치를 격리된 환경에서 테스트할 수 있어 프로덕션 전 단계에서 더 큰 확신을 얻고 결함 발생률을 줄일 수 있습니다.
WE6.1.3	향후 90일 내에 가장 불안정한 Selenium 테스트 5개를 해결하면 개발자들이 자동화된 브라우저 테스트를 배포 전 워크플로의 중요한 부분으로 인식하고 신뢰도를 높일 수 있을 것입니다.
WE6.2.4	데이터 영속성 설계 검토에 적극적으로 참여하고 지원한다면, 실제 운영 환경으로의 전환을 위한 확실한 경로를 확보할 수 있을 것입니다.
WE6.2.5	SLO 그룹과 협력하고 현재 SLO와 함께 작업하는 팀으로부터 피드백을 수집함으로써, 프로덕션 준비 체크리스트의 부족한 부분과 개선 사항을 파악할 뿐만 아니라, SLO 도입 및 온보딩을 직접적으로 촉진하는 방식으로 체크리스트를 조정할 수 있을 것입니다.
WE6.2.6	hCaptcha 프록시 서비스의 출시 및 중요도 높은 항목에 대해 프로덕션 준비 체크리스트를 시범 운영함으로써 추적되지 않은 기술 부채를 파악하고 가시적인 작업 백로그를 생성하여 프레임워크의 가치를 입증하는 동시에 서비스 전반에 걸쳐 일관된 도입을 위한 반복 가능한 프로세스를 구축할 것입니다.
WE6.2.7	SRE 팀의 의견과 기여를 통해 프로덕션 준비 체크리스트를 공동으로 개선함으로써, 실제 운영상의 요구 사항을 충족하고, 공동 소유권을 구축하며, 팀이 채택할 가치가 있다고 느끼는 실용적인 도구를 만들 수 있도록 하겠습니다.
WE6.2.8	SLO 그룹, hCaptcha 프록시 시범 운영 및 SRE 협업에서 얻은 피드백을 분석하여 어떤 체크리스트 항목과 프로세스 단계에 더 명확한 지침이나 지원 자료가 필요한지 파악하고, 12월 휴가 전에 도입이 가능하도록 프레임워크를 간소화하기 위한 다음 단계를 결정할 것입니다.
WE6.2.9	Node.js 서비스 유틸리티를 도입하면 서비스 메시 라우팅 또는 OpenTelemetry 게시 중 하나를 검증된 방식으로 배포할 수 있습니다.
WE6.3.2	새로운 측정 기준을 개발하고, 파소이드의 캐시 인프라를 개선하고, 상위 10위권 위키백과 두 곳에 배포하면, 신뢰도 프레임워크에 대한 성능 기준을 마련할 수 있습니다. 이를 통해 다른 대형 위키에 배포할 준비가 되었는지 검증하고, 대규모 트래픽을 처리할 수 있는 능력을 입증할 수 있을 것입니다.
WE6.3.3	2분기 내에 핵심적인 언어 변형 지원 개선 사항을 구현하고 최소 3개의 언어 변형 위키에 Parsoid를 성공적으로 배포하면, 나머지 모든 언어 변형 위키에 Parsoid를 자신 있게 배포하는 데 필요한 주요 기술적 과제를 파악하고 해결할 수 있을 것입니다.
WE6.3.4	파소이드 읽기 뷰의 읽기 환경 전반에 걸쳐 QA, 식별, 우선순위 지정 및 버그 수정 작업을 수행한다면, 읽기 환경의 품질을 유지하고 위키 전반에 걸친 추가 확장을 위한 발판을 마련할 수 있을 것입니다.
WE6.3.5	파서 캐시 적중률의 TTFB(Time To First Byte) 지표를 기존 수준의 110% 이하, 파서 캐시 미스율의 TTFB 지표를 기존 수준의 150% 이하로 목표로 설정하면, 중국어 및 영어 위키백과를 제외한 모든 위키백과에 3분기 말까지 성능 문제 없이 배포할 수 있습니다. 이는 영어 위키백과 배포 준비 상태를 검증하고, 캐시 용량을 파악하여 대규모 트래픽 처리에 대비하는 데 도움이 될 것입니다.
WE6.4.4	미디어위키 사이트의 모든 페이지 조회수를 정규 도메인을 통해 제공하도록 도메인을 통합하면 모바일 서브도메인 넘겨주기를 제거하여 플랫폼 복잡성을 줄이고 SEO 위험을 낮출 수 있습니다. 완료율은 정규 도메인에 대한 모바일 방문 넘겨주기 비율을 100%에서 0%로 줄이는 것으로 측정됩니다.
WE6.4.7	만약 우리가 전 세계 루트 액세스 권한을 가진 모든 사용자의 최소 90%가 위키미디어 프로덕션 서버 접속에 하드웨어 기반 SSH 키를 사용하도록 전환한다면, 해킹당한 노트북으로 인해 심각한 보안 침해가 발생할 위험을 줄일 수 있을 것입니다.
WE6.4.8	미디어위키 엔지니어링 팀이 PHP 업그레이드와 관련된 미디어위키의 문제를 적극적으로 모니터링하고 수정한다면, SRE 팀은 2025년 11월까지 프로덕션 환경의 PHP 8.3 업그레이드를 완료할 수 있을 것입니다.

신호 및 데이터 서비스(SDS) 가설 [ SDS 주요 결과 ] 토론
가설 단축명	3분기 텍스트	세부사항 및 토론
SDS1.5.1	봇 분류 결과에 대한 정기적이고 운영화된 내부 감사 프로세스를 구축한다면, 솔루션에 대한 신뢰를 확보하고 자동으로 탐지되지 않는 트래픽 패턴의 변화를 예측할 수 있을 것입니다.
SDS1.5.2	100% 샘플링과 요청 식별자를 사용하는 테스트 키친 장비를 배포하면 클라이언트 측 이벤트를 전송했는지 여부와 관계없이 모든 요청을 캡처하고 봇 동작을 분석할 수 있습니다.
SDS1.5.3	클라이언트 측 기본 신호를 분석하고 이를 휴리스틱에 통합하면 데이터 플랫폼에서 추가적인 봇 패턴을 감지할 수 있습니다.
SDS2.2.4	제품 안전 및 무결성 부서에서 성장책과 FerretDB를 검토하면 제품 출시 전에 중대한 위험 요소를 파악하고 완화하거나 해결할 수 있을 것입니다.
SDS2.2.5	테스트 키친 JS 및 PHP SDK에 실험 노출을 기록하는 메서드를 추가하면 모든 이벤트를 노출 이벤트로 처리할 필요가 없어지므로 성장책에서 실험 할당 쿼리 성능이 향상되고 더욱 정확한 실험 결과를 얻을 수 있습니다.
SDS2.4.2	모니터링된 스트레스 테스트를 통해 트래픽 등록을 안전하게 확대하면 독자팀 실험의 통계적 검정력이 향상되어 실험 기간이 단축되고 의사 결정에 대한 신뢰도가 높아질 것입니다.

잠재적 청중 (FA) 가설 [ FA 주요 결과 ] 토론
가설 단축명	3분기 텍스트	세부사항 및 토론
FA1.1.1	만약 우리가 itch.io에 새로운 위키백과 경험을 위한 중앙 허브를 구축한다면, 위키백과 사용자가 아닌 50명 이상의 관심 있는 사용자층으로부터 피드백을 받을 수 있을 것이고, 이는 게임에서 무엇이 효과적이고 무엇이 효과적이지 않은지 배우는 데 도움이 될 것입니다.
FA1.1.2	앱 기반 콘텐츠 검색 기능을 세 가지로 나누어 짧은 실험을 통해 테스트해 보면, 차세대 앱 사용자들을 효과적으로 유치하고 유지하는 방법에 대한 권장 사항을 앱 팀과 공유할 수 있습니다.
FA1.1.3	틱톡 필터 4개를 만들어서 우리 틱톡 계정에 게시하면, 플랫폼 외부에서 위키백과 콘텐츠 생성을 얼마나 효과적으로 장려할 수 있는지 알 수 있을 것입니다.
FA1.1.6	디스코드에서 공유되는 위키백과 링크에 대해 서로 다른 3가지 미리보기 버전을 만들면 측정 및 실행 전략에 대한 내부적인 합의를 도출하고 디스코드의 제품 엔지니어링 팀과 협업할 수 있습니다.
FA2.2.1	만약 우리가 숏폼 비디오 플랫폼 전반에 걸쳐 커뮤니티 관리에 투자한다면, 2025년 2분기 말(12월)까지 틱톡에서 신규 시청자 비율이 전분기 대비 30% 증가할 것이며, 모든 숏폼 비디오 플랫폼에서 외부 콘텐츠에 달린 브랜드 댓글에 대한 참여도(좋아요 및 답글)가 총 5만 건에 달할 것입니다. 이는 가시성을 높이고 현재 도달하지 못하고 있는 잠재 고객과의 소통을 강화하는 데 도움이 될 것입니다.
FA2.2.2	위키백과 크리에이터 파트너십 프로그램에 대한 내부 전략과 외부 공유 자료(크리에이터에게 제공하는 가치, 파트너십 기준, 계약 절차, 그리고 크리에이터 콘텐츠가 위키백과 소유 채널과 크리에이터 채널 전반에 걸쳐 어떻게 표시될지에 대한 개요 포함)를 개발하고 승인을 받으면, 소셜 미디어를 통해 지식 콘텐츠를 활용하여 새로운 사용자층에 도달하는 데 도움이 되는 강력한 크리에이터 전략을 수립할 수 있을 것입니다.

제품 및 엔지니어링 지원 (PES) 가설 [ PES 주요 결과 ] 토론
가설 단축명	3분기 텍스트	세부사항 및 토론
PES1.3.5	커뮤니티에서 제공하는 이스터 에그 설정 기능을 활용하고, 독자 경험팀을 상시 코드 리뷰 담당자로 활용한다면 2월 15일에 출시하여 프로젝트의 영향력을 추적할 수 있을 것입니다.
PES1.3.6	위키백과 25주년(25YoW)을 기념하는 맞춤형 소셜 미디어 게시물을 제작한다면, 기존 홍보팀 템플릿과 유사한 수준의 노출 효과를 얻을 수 있을 뿐 아니라, 홍보팀의 역량 강화에 기여할 수 있음을 입증할 수 있습니다. 벤치마킹은 Truth Collective에서 동일 프로젝트에 대해 게시한 글들을 기준으로 진행할 예정입니다.
PES1.4.1	Codex를 주로 사용하지 않는 4~5개 팀(OOUI를 주로 사용하는 팀 포함)과 미팅을 진행하면, 해당 팀들이 현재 및 향후 프로젝트에서 Codex를 도입하는 데 있어 걸림돌이 될 수 있는 요소들을 파악할 수 있을 것입니다.
PES1.4.2	Codex PHP를 더 사용하기 쉽고 1.0 버전을 출시할 수 있을 만큼 안정적으로 만들면, 여러 팀에서 서버 생성 UI에 Codex PHP를 도입할 것입니다. 그렇게 되면 Codex PHP를 사용하는 프로젝트 수가 3개에서 5개로 늘어날 것입니다.
PES1.5.1	Sloth를 프로토타입에서 Pyrra를 대체하는 솔루션으로 업그레이드하고 기존 서비스를 통합하면 통합된 SLO 대시보드 세트를 구축하고, 알림 기능을 개선하며, SLO 온보딩 경험을 간소화할 수 있습니다.
PES1.5.2	위키함수 및 미디어위키 콘텐츠 기록에 대한 SLI 지표를 지속적으로 도입하고 위키데이터 쿼리 서비스 및 편집 검사에 대한 지표를 확인하면, 대시보드 보고 및 서비스 소유자 참여와 관련된 문제, 즉 눈에 띄지만 해결되지 않은 SLO 보고서에 대한 문제를 해결할 수 있을 것입니다.

4분기

WMF 연간 계획의 4분기(Q4)는 2026년 4월부터 6월까지를 포함합니다.

위키 경험 (WE) 가설 [ WE 주요 결과 ] 토론
가설 단축명	4분기 텍스트	세부사항 및 토론
WE1.3.3	신규 편집자에게 운영자 대시보드를 노출하는 실험을 진행할 경우, 방문한 기여자 중 10%가 2주 연속으로 해당 대시보드를 이용합니다.
WE1.5.1a	DBT를 사용하여 기여자 대시보드에 새로운 지표를 추가하면 기여자 제품 팀이 편집 트렌드에 대한 더욱 실질적인 인사이트를 얻을 수 있게 됩니다.
WE1.5.5	Airflow를 사용하여 DBT 모델 업데이트를 정해진 일정에 따라 자동화하면 운동 통찰에서 최신 정보를 활용하여 해당 모델에 대한 분석 및 보고서를 작성할 수 있습니다.
WE1.5.6	워크플로를 문서화하고 팀별 기본 출력 위치 및 dbt 모델에 대한 액세스 제어를 설정하면 운동 통찰 및 기타 팀의 팀 구성원 간에 dbt 사용을 확장할 수 있습니다.
WE1.5.7	MAM 대시보드를 지정된 대로 확장하면 기여자 전략에 대한 의사 결정에 도움이 되는 중재자 파이프라인 상태에 대한 더 완전한 그림을 얻을 수 있습니다.
WE1.6.1	사용자 지정 관심 목록 라벨 기능을 도입할 경우, 첫 달에 관심 목록에 100개 이상의 페이지를 보유한 사용자 중 5%가 해당 라벨을 사용할 것으로 예상합니다.
WE1.7.2	모바일 앱에서 신규 사용자를 대상으로 앱 내 웹뷰 편집 흐름의 디자인 프로토타입을 테스트하여, 게시 전 이탈을 유발할 수 있는 가장 위험한 마찰 요인(특히 컨텍스트 전환, 편집 내용 이해, 편집자 표시 관련 문제)을 파악하고, 이를 바탕으로 이 접근 방식을 통해 신규 편집자를 대규모로 성공적으로 온보딩하기 전에 해결해야 할 우선순위를 정할 것입니다.
WE1.7.4	다양한 영어 위키백과 문서 150개를 표본으로 삼아, 시중에 나와 있는 범용 인공지능(GenAI) 모델을 활용하여 편집 제안을 생성하고 순위를 매겨보면, 이러한 범용 모델이 대규모로 처리할 수 있는 편집 작업 유형을 파악하고, 제안의 유용성을 대략적으로나마 경험적으로 이해할 수 있습니다. 이러한 초기 분석 결과를 통해 특정 작업 유형이 범용 모델(미세 조정 여부와 관계없이)로 대규모 처리가 가능한지, 아니면 보다 특화된 접근 방식이 필요한지 평가할 수 있으며, 궁극적으로 "단일 모델로 다양한 제안 생성"이라는 방향이 타당한지 검증할 수 있습니다.
WE1.7.5	통제된 실험에서 비정형적인 교정 작업을 정형적인 어조 수정 작업으로 대체하면, 초보 편집자가 수행하는 어조 수정 작업의 완료율이 교정 작업을 통해 수행하는 수정 작업의 완료율보다 더 높을 것입니다.
WE1.7.6	독자들이 배우고자 하는 동기와 기여 기회를 연계하고, 기여를 호기심을 충족하거나 이미 보유한 지식을 공유하는 방법으로 제시하는 두 가지 구조화된 워크플로를 디자인 프로토타입을 통해 테스트한다면, 독자들이 스스로 기여자가 되는 것을 상상하도록 영감을 주는 접근 방식을 파악하는 데 도움이 될 것입니다.
WE1.7.7	누적 편집 횟수가 100회 이하이고 모바일 시각 편집기 또는 소스 편집기에서 2초 이상 머무른 후 모바일 편집 세션을 중단하는 사용자를 대상으로 이탈 설문조사를 실시하면 이러한 행동의 원인에 대한 패턴을 파악하고 모바일 웹 편집 완료율을 높이기 위해 어떤 개선 사항에 우선순위를 두어야 할지 결정할 수 있습니다.
WE1.7.8	모바일 시각 편집기에 접속하는 초보 개발자에게 즉시 실행 가능한 편집 제안을 제공하면, 건설적인 편집 내용이 게시되는 편집 세션의 비율이 10% 이상 증가할 것입니다.
WE1.7.9	만약 우리가 en.wiki에서 모바일 웹을 처음 사용하는 신규 사용자에게 시각편집기를 기본적으로 활성화하는 제안을 위키에 게시한다면, 이를 실현하는 데 필요한 단계를 정의할 것입니다.
WE1.8.2	로그아웃 상태에서 편집할 때 표시되는 경고 메시지를 개선하면, 해당 경고 메시지를 접한 모바일 신규 사용자의 계정 생성률이 대조군 대비 최소 2% 이상 증가할 것입니다.
WE1.8.3	계정 생성 양식을 개선하면 해당 양식에 접속한 모바일 사용자의 등록 완료율이 대조군 대비 최소 2% 증가할 것입니다.
WE1.8.4	모바일 웹 헤더에 사용자 계정 버튼을 추가하면 모바일에서 생성되는 신규 계정 수가 대조군 대비 최소 2% 증가할 것입니다.
WE1.8.5	모바일 웹에서 로그아웃한 사용자에게도 읽기 목록을 제공하면, 대조군 대비 회원가입률이 최소 2% 이상 증가할 것입니다.
WE1.9.2	2026년 커뮤니티 인사이트 조사에 편집자 동기에 영향을 미치는 요인에 대한 주요 질문을 도입하면 4분기 말까지 편집자 발전과 인정에 초점을 맞춰 기여자 전략 구현에 도움이 될 수 있는 ≥5개의 연구 인사이트를 제공할 수 있습니다. [i] 역량(도구 및 리소스 사용 능력), 자율성(플랫폼 탐색 및 정보에 입각한 의사 결정 능력), 관계성(커뮤니티 참여, 지원 및 가치 부여 느낌)의 관점에서 정의됩니다.
WE1.9.3	최소 두 곳의 가맹단체와 함께 모바일 우선 온보딩 가이드라인을 공동으로 설계한다면, 6월 말까지 주최측이 모바일 우선 신규 참가자 유지에 가장 큰 걸림돌로 인식하는 부분이 무엇인지 파악할 수 있을 것입니다.
WE1.10.3	선정된 몇몇 커뮤니티와 협력하여 해당 위키에 맞는 문서 작성 지침 워크플로를 맞춤 설정하면, 편집자들은 각 커뮤니티의 콘텐츠와 정책에 맞춘 지침을 받을 수 있습니다.
WE1.10.5	문서 가이드라인 A/B 테스트에 필요한 모든 프로덕션 단계 요건(보안 검토, 법률 자문, 계측, 커뮤니티 개요 검토 및 번역, 실험 구성 포함)을 완료하면 4분기 말 이전에 실험을 시작하여 완료하고, 주니어 편집자가 작성한 문서의 30일 생존율에 대한 문서 가이드라인의 영향에 대한 통계적으로 의미 있는 데이터를 생성하기 시작할 것입니다.
WE2.2.13	위키낱말사전 커뮤니티에 동사 활용표 기능의 활용 가능성을 알리면 편집자들의 이해도와 사용 편의성에 대한 초기 의견을 수렴하여 향후 개선 방향을 설정할 수 있을 것입니다.
WE2.3.7	초기 기여자들과 함께 기여 워크플로에서 작지만 빈번하게 발생하는 마찰 지점을 파악하고 해결한다면, 추상 위키백과의 기초를 다지고 있는 핵심 커뮤니티의 참여도를 높이고 유지할 수 있습니다.
WE2.3.8	요약 위키백과 콘텐츠를 로컬 위키백과에 문서 단위로 선택적으로 통합할 수 있는 기능을 구현하면, 이 모델이 실제로 어떻게 작동하는지 보여주고 1분기에 시범 커뮤니티 참여를 유도할 수 있습니다.
WE2.3.9	기존 미디어위키 계측 기능에 더해 추상 위키백과에 대한 기본적인 계측 기능을 구현하면 사용자들이 추상 위키백과 어떻게 상호작용하는지 더 잘 이해하고 개선점을 파악할 수 있을 것입니다.
WE2.3.10	위키함수를 통해 위키미디어 공용의 이미지를 요약 문서에 표시하는 것을 지원한다면, 커뮤니티에서 위키백과 문서에 흔히 사용되는 시각적 요소를 통합할 수 있게 됩니다.
WE2.3.13	콘텐츠의 가용성, 생산 및 소비를 유연한 주제 분류 체계에 맞춰 분석할 수 있는 역량을 구축한다면, 콘텐츠 트렌드를 더욱 명확하게 파악하고 이를 통해 유용한 통찰력을 얻을 수 있을 것입니다.
WE2.3.16	Rust 평가 도구가 Node 평가 도구와 기능적으로 동등해지고 Node 평가 도구가 단계적으로 폐지된다면, 막대한 유지 관리 부담을 없애고 엔지니어링 리소스를 확보할 수 있을 것입니다.
WE2.5.4	마이그레이션 계획을 단일 문서로 작성하면 마이그레이션의 모든 측면에 대해 의견을 조율하고 실행을 추진할 수 있습니다.
WE2.5.6	선택된 쿼리 세트에 대해 WDQS v1과 v2 간의 출력 비교를 자동화하는 기능을 개발한다면, 새로운 서비스의 정확성에 대한 신뢰도를 높일 수 있을 것입니다.
WE2.5.7	마이그레이션 관련 메시지 전달 계획을 수립하면, 위키데이터 커뮤니티와 변경 사항 예상 시점 및 준비 방법에 대한 의견을 조율하여 새로운 엔드포인트로의 원활한 전환을 경험할 수 있을 것입니다.
WE2.5.8	설계 문서에 설명된 분리형 아키텍처 구축을 시작하면 분기 내내 점진적으로 가치를 제공하고 2027년 회계연도 1분기까지 시범 운영 그룹을 지원할 수 있는 서비스를 확보할 수 있을 것입니다.
WE3.1.15	키워드, 자연어, 의미 기반 쿼리를 혼합한 하이브리드 검색 MVP를 안드로이드 앱에서 테스트하면 만족도, 응답 시간, 사용자 유지율에 부정적인 영향을 주지 않으면서 전체 검색 참여도를 10% 증가시키는 접근 방식과 디자인 패턴을 신속하게 파악할 수 있습니다.
WE3.1.16	질의응답 모델에 대한 요구사항을 정의하면, 모델 결과물을 생성하여 커뮤니티와 공유하고 피드백을 수집하여 실제 운영 실험에 반영할 수 있습니다.
WE3.1.17	검색 기능이 미디어위키 엔드포인트를 포함하여 의미론적 쿼리 처리를 지원하는 안정적이고 성능이 뛰어난 벡터 검색 인프라를 제공한다면, 머신러닝 및 연구팀에서 임베딩을 생성하고 모델을 시스템에 통합하여 MVP의 임베딩 기반 검색 기능을 구현할 수 있을 것입니다.
WE3.3.6	만약 합의된 확장성 및 가용성 요구사항을 충족하는 서비스와 필요한 데이터 보충을 통해 기사 주제 추론 데이터를 제공할 수 있다면, 이 데이터에 의존하는 향후 맞춤형 독자 경험을 지원하기 위한 필수 기술 기반을 마련하게 될 것입니다.
WE3.4.1	우리가 하이브리드 PoP/CDN 배포를 위해 노력한다면, 그것은 필요에 따라 완전한 PoP와 미니 PoP (물리 및 클라우드) 를 모두 가져오도록 할 수 있게 해, 앞으로의 프로토타입 미니 PoM 배포의 기초를 마련할 수 있게 해 줄 것입니다.
WE3.5.3	만약 우리가 미디어위키에 동의 기반 기부자 세그먼트 저장 기능을 구현하고 안정적인 CiviCRM과 MW 간의 동기화를 구축한다면, 제품 및 모금 부서는 이번 분기 말까지 웹과 앱 전반에 걸쳐 플랫폼 상에서 기부자 세그먼트를 성공적으로 식별하고 구분할 수 있을 것입니다.
WE3.5.5	모바일 웹에서 로그아웃한 기부자에게 기본적으로 탭 시 짧고 즐거운 상호작용이 실행되는 지속적인 감사 배지를 제공하는 경우(C), 단순 팝업 메시지가 포함된 배지를 제공하는 경우(B) 및 기부 후 배지를 전혀 제공하지 않는 경우(A)에 비해 21일 누적 유지율이 1% 향상될 것으로 예상됩니다. 또한, (C) 그룹의 기부자 중 더 많은 비율이 (B) 그룹보다 향후 최소 한 번 이상 재방문 시 배지를 다시 탭하는지 추적하여, 재미있는 상호작용이 재참여 루프를 생성하는지 여부를 확인할 것입니다.
WE3.6.9	파악된 이해관계자들과 협력하면 개발 요구사항, 상호 의존성, 일정에 대한 필수 정보를 수집하여 모든 관련 이해관계자의 승인을 받는 소비자 전략 측정 계획에 대한 의사결정 보고서를 작성할 수 있습니다.
WE3.6.10	로그인한 독자의 유지율에 대한 A/A 테스트를 실행하면 향후 분기에 사용할 수 있는 유지율 기준선을 설정할 수 있습니다.
WE3.6.11	기존 데이터를 분석하여 어떤 사용자 요인이나 행동이 유지율과 상관관계가 있는지 파악하면, 어떤 제품 개선 사항이나 전략이 유지율을 높일 수 있는지에 대한 이해를 문서화할 수 있습니다.
WE3.6.12	번역된 위키백과 콘텐츠 양을 늘리는 것이 페이지 조회수의 직접적인 증가로 이어지는지 측정하는 실험을 통해 향후 번역에 대한 전략적 투자 방향을 제시할 수 있을 것입니다.
WE3.7.2	데스크톱에서 헤더에 기부 링크가 있는 모든 프로젝트에 새로운 "하트" 기부 버튼 디자인을 적용하면, 이전 클릭률 실험에서 얻은 긍정적인 결과에 따라 해당 링크를 통한 총 기부액은 감소하지 않을 것입니다.
WE3.8.2	만약 웹상에서 독서 목록 기능을 선택 참여형 베타 기능으로 제공하고, 모든 신규 사용자 계정에도 이 기능을 필수로 포함시킨다면, 설문 조사에서 최소 50%의 사용자가 해당 기능을 유용하다고 평가할 것입니다.
WE3.8.3	앱에 사용자들이 독서 목표를 달성하도록 동기를 부여하는 임시 '25번째 생일 독서 챌린지' 위젯을 추가하면, 챌린지에 참여한 첫 14일 동안의 사용자 중 일반 사용자(2주 이내 재방문)에서 활성 사용자(2일 이내 재방문)로의 전환율이 기준치인 16.8%보다 5% 더 높아지는 것을 확인할 수 있습니다.
WE3.9.3	모바일 웹에서 이미지 탐색 캐러셀과 상세 보기 기능을 광범위하게 도입하면 캐러셀의 클릭률(CTR)을 5% 이상으로 유지할 수 있을 것입니다.
WE3.9.4	iOS 앱에 "어느 것이 먼저였을까?"라는 일일 퀴즈 게임을 추가하여 테스트해 보면, 로그아웃한 사용자 중 15%가 여러 날에 걸쳐 게임에 다시 참여하는 것을 확인할 수 있습니다.
WE3.10.3	독자들에게 위키상의 지식 네트워크를 탐색하는 몇 가지 개념을 제시하면, 향후 개발이 필요한 개념들의 우선순위 목록을 얻을 수 있을 것입니다.
WE3.10.5	독자에게 향상된 공유 옵션을 제공하면 대화 상자를 보는 독자의 [33%]가 로그아웃 독자 유지에 영향을 주지 않고 향상된 공유 작업을 완료합니다.
WE3.10.6	모바일 앱의 탐색 피드를 재설계하면 출시 후 14일 이내에 로그아웃한 고유 사용자당 여러 날에 걸쳐 탐색 피드 참여도가 실질적으로 10% 증가하는 것을 확인할 수 있습니다.
WE3.10.7	일반 사용자들이 가장 자주 느끼고 중요하게 생각하는 미충족 요구 사항(사용자 평가 기준)과 초기 단계의 아이디어 중 가장 유용하고 바람직한 아이디어를 파악한다면, 2026-2027년 회계연도에 A/B 테스트에 어떤 아이디어를 우선적으로 적용하여 사용자 유지율을 높일 수 있을지 결정할 수 있을 것입니다.
WE3.10.8	미네르바에 페이지 미리보기 기능을 추가하면 로그아웃 상태의 독자 유지율이 실질적으로 크게 향상될 것으로 예상됩니다.
WE4.6.13	이메일 주소가 인증되지 않은 사용자에게 이메일 주소 인증을 권장하면, 이 알림을 받은 활성 사용자 중 10%가 이메일 주소 인증을 시도할 것입니다.
WE4.6.16	전역 그룹에 대한 그룹 구성원 제한을 시행하는 데 필요한 지원을 확보한다면, 이를 활용하여 전역 그룹에 대한 2단계 인증(2FA) 요구 사항을 강제할 수 있을 것입니다.
WE4.6.17	추가적인 사용자 그룹에 대해 2단계 인증(2FA) 요구 사항을 발표하고 시행하면, 민감한 접근 권한을 가지고 있지만 2단계 인증을 사용하지 않는 사용자의 수는 0으로 줄어들 것입니다.
WE4.6.18	개인 위키에 2단계 인증(2FA)을 적용하는 기능을 구축하면 개인 정보에 접근 권한이 있는 사용자 계정을 보호할 수 있을 것입니다.
WE4.6.19	민감한 작업에 대해 재인증을 요구하고 다른 보안 강화 조치를 시행하면 사용자 스크립트를 악용하는 공격자에 대한 취약성이 줄어들 것입니다.
WE4.6.20	사용자 스크립트에 악성 코드가 있는지 사전에 검사한다면, 공격자가 사용자 스크립트를 악용하는 것에 대한 취약성을 줄일 수 있습니다.
WE4.6.21	고급 권한을 가진 직원 계정 수를 줄이고 해당 권한 유지 기간을 단축하면 직원 계정을 대상으로 하는 공격으로 인한 피해 발생 가능성을 줄일 수 있습니다.
WE4.8.1	특별 기부 페이지에 연결된 계정 패널을 포함하여 관련 임시 계정을 감지하고 표시하는 메커니즘을 도입하면 관리자는 악의적인 임시 계정 활동을 더 빠르고 정확하게 식별할 수 있습니다.
WE4.8.3	최근 점검 시간이 예전보다 길어졌다는 불만 사항을 조사해 보면, 임시 계정 도입과 관련이 있는지 여부를 판단할 수 있을 것입니다.
WE4.10.1	hCaptcha를 단계적으로 더 많은 위키(특수:계정생성, 데스크톱 위키텍스트 편집기)에 적용하면 모든 프로젝트에서 봇 탐지 범위를 확대할 수 있습니다.
WE4.10.2	시범 운영 중인 위키의 시각적 편집, 토론 도구, 파일 업로드 마법사 및 모바일 편집 경로에 hCaptcha 봇 감지 기능을 적용하면 위키미디어 재단 위키에서 hCaptcha를 통해 인증된 작업 비율이 35% 증가할 것으로 예상됩니다.
WE4.10.3	차단된 편집 알림에 대한 hCaptcha 위험 점수 수집 시스템을 도입하면 IP 범위 차단으로 인한 부수적인 피해를 더 잘 파악할 수 있습니다.
WE4.11.1	만약 우리가 단계적 배포 방식을 통해 영어 위키백과에 사건 보고 시스템(IRS)을 도입한다면, 처음에는 소규모로 시작하여 로그인한 사용자의 최소 50%까지 확장함으로써, 새롭게 수집된 지표 데이터를 통해 영어 위키백과에 IRS를 도입해야 할지 여부를 충분히 판단할 수 있을 것입니다.
WE4.12.1	만약 우리가 영어 위키백과의 커뮤니티 검증을 거친, 검토 대상(WP:기록보호자) 콘텐츠 데이터셋을 사용하여 최소 2개의 콘텐츠 정책 모델의 성능을 최적화하고 비교한다면, 자동 검토 또는 검토 대상일 가능성이 매우 높은 콘텐츠에 플래그를 지정하는 데 적합한 모델 또는 모델 조합을 추천할 수 있을 것입니다.
WE4.12.2	LiftWing에 gpt-oss-safeguard-20b, CoPE-A-9B, CoPE-b-12b 모델을 호스팅하고 각 모델의 성능을 PSI 팀의 초기 평가 요구 사항에 맞게 최적화하면 PSI 팀은 세 가지 모델을 테스트하고 동작을 비교할 수 있습니다.
WE5.1.3e	API 요청 분석을 위한 데이터 제품을 개발하면 API 요청 분석 및 세분화가 간소화되고, 제품 분석팀은 이 새로운 데이터를 더욱 세분화하고 집계하여 API 분석 대시보드 프로토타입을 제작할 수 있게 됩니다.
WE5.1.3f	사용자 에이전트만 제공하는 요청에 대한 API 요청 속도 제한을 줄이면 사용자 에이전트만 사용하는 사용자들이 보다 책임감 있는 방식으로 전환하도록 유도하여 인증되고 알려진 클라이언트 수를 늘릴 수 있습니다.
WE5.2.2c	현재 API 게이트웨이를 통해 전달되는 모든 API를 공통 게이트웨이로 재라우팅하면 기존 API 게이트웨이를 완전히 폐지하고 위키미디어 커뮤니티용 HTTP/웹 API의 일관성을 유지할 수 있습니다.
WE5.2.5b	린터 아키텍처와 핵심 린팅 규칙 세트를 확정하면 OpenAPI 설명의 품질을 향상시키고 API 개발 프로세스의 CI 워크플로에 해당 규칙 준수를 프로그램적으로 보장하는 기능을 도입할 수 있습니다.
WE5.2.8b	다양한 사용 사례를 보여주는 API 모듈을 최소 3개 이상 추가 도입한다면(독립형 서비스 API 1개, 기능 팀 소유 확장 API 1개, 내부 모듈 1개 이상), 사용성을 개선하고 API 플랫폼의 미래를 위한 기반을 마련할 수 있을 것입니다.
WE5.2.11b	API 포털 문서 마이그레이션을 완료하면 API 포털 시스템을 완전히 폐지할 수 있게 되어 API 문서 검색이 간소화되고 문서 일관성이 향상되며 API 지원 시스템의 수가 줄어들 것입니다.
WE5.2.12	개발자를 위한 통합된 진입점 구축에 필요한 설계 및 탐색 작업을 조기에 반복적으로 진행한다면 2026-2027년 회계연도에 엔지니어링 작업을 효과적으로 가속화할 수 있을 것입니다.
WE5.2.13	덤프 웹사이트에 기존 사용자 에이전트 정책을 적용하기 시작하면 덤프 사용자와 사용 사례를 더 잘 이해할 수 있을 뿐 아니라 개발자 경로 전반에 걸쳐 보다 일관된 액세스 기대치를 보장할 수 있습니다.
WE5.3.2b	위키미디어 출처 표기를 실험하는 파트너 시범 프로그램을 구축하면, 재사용자들이 출처를 표기함으로써 위키미디어에 대한 참여와 기여를 촉진하는 상호 유익한 효과를 보여줄 수 있습니다.
WE5.3.3	콘텐츠 재사용자에게 표준적이고 간편한 검색 경로를 제공하면 위키미디어 저작권 표시 프레임워크의 신뢰 신호를 채택하는 데 필요한 노력을 줄이고, 최적화되지 않은 검색 경로의 표준화를 방지하며, 저작권 표시 채택률을 안정적으로 측정할 수 있게 됩니다.
WE5.3.3b	고유 기여자 수를 계산하는 데이터 파이프라인을 구축하고 이를 미디어위키에 제공하는 방법을 개발하면, 기여자 수를 어트리뷰션 API 사용자에게 신호로 제공할 수 있을 것입니다.
WE5.3.3c	페이지 조회수를 기반으로 한 단순한 "상대적 추세" 측정 지표를 제공하는 API와 이벤트 스트림을 설계하고 구현하면, 어트리뷰션 API가 이를 신뢰도 및 참여도 측정 지표로 활용할 수 있게 되어 모바일 앱 프로토타이핑이 가능해집니다.
WE5.3.4	만약 우리가 "적격 트래픽"(특정 관심 결과)을 정의하고 플랫폼 및 유입 경로별로 추천인을 구분한다면, 제품 및 파트너십 결정에 중요한 후속 참여 및 기여 결과에서 체계적인 차이를 발견할 수 있을 것입니다.
WE5.3.4b	일관된 트래픽 상태 지표 세트를 구축하면 단순히 페이지 조회수만으로는 설명할 수 없는, 시간 경과에 따른 그리고 유입 경로별 위키미디어 유입 트래픽의 의미 있는 변화를 안정적으로 감지하고 설명할 수 있습니다.
WE5.3.4c	실제 가시성 충격을 자연 실험으로 분석하면 콘텐츠 품질 및 유지 관리 결과에서 측정 가능한 변화를 확인할 수 있으며, 이는 가시성과 콘텐츠 건전성 간의 관계를 뒷받침합니다.
WE5.4.2c	CDN에서 애플리케이션 레이어 지문을 사용하여 iOS 및 안드로이드용 공식 위키미디어 모바일 앱을 식별할 수 있다면, requestctl에 알려진 클라이언트로 추가하여 예외 및 사용자 지정 속도 제한을 설정함으로써 원활한 사용자 경험을 보장할 수 있습니다.
WE5.4.8b	응답 크기 집계를 기반으로 멀티미디어 파일 요청에 대한 속도 제한을 두면 사용 가능한 대역폭을 사용자에게 공정하게 할당할 수 있습니다.
WE5.4.10	비표준 썸네일 크기 생성을 허용하지 않으면 백엔드 미디어 서비스 인프라에 가해지는 부담을 줄일 수 있습니다.
WE5.4.12	온사이트 미디어 트래픽과 외부 재사용 트래픽을 구분하는 신호를 생성하면 SRE는 외부 소스에서 발생하는 비용이 많이 드는 미디어 요청에 대한 속도 제한을 통해 부하가 높을 때 온사이트 트래픽의 우선순위를 높일 수 있습니다.
WE5.4.12b	미디어위키에서 이미지 출처 정보를 얻을 수 있다면, 해당 정보를 리퍼러 및 할당된 X-Is-Browser 점수와 같은 다른 식별자와 함께 사용하여 위키 사용자에 대한 접속 제한을 완화하거나 변경할 수 있습니다.
WE5.4.13	WE5 목표 지표(요청률, 대역폭, 사용자 에이전트 준수)에 대한 정기적인 처리 및 보고 체계를 구축하면 핵심 성과 지표(KR) 전반에 걸친 진행 상황을 추적하고 대량 스크래핑 차단 및 사용자 에이전트 정책 시행의 효과를 평가하는 데 도움이 될 것입니다.
WE5.4.14	WAF 소프트웨어를 CDN 인프라에 덜 종속적으로 만들면 내부 또는 외부를 막론하고 더 많은 사용 사례를 지원할 수 있을 것입니다.
WE5.4.15	위키 사용자가 포함된 대규모 NAT를 식별하고 분류할 수 있다면, 이 정보를 활용하여 IP 주소별로 속도 제한 및 기타 방어 조치를 더욱 엄격하게 적용함으로써 스크래핑의 영향을 완화할 수 있습니다.
WE5.4.16	자동화된 트래픽을 생성하는 특정 운영자에 대한 위협 모델을 구축할 때, 그들의 의도, 투자 수준 및 사용 기술을 포함시키면 SRE 팀이 스크래퍼 및 기타 공격자를 식별하는 능력을 향상시킬 수 있습니다.
WE5.4.17	웹 요청 트래픽에 대한 거의 실시간 분석을 통해 지속적인 스크래핑 캠페인을 감지할 수 있다면, 데이터 레이크에서 규칙을 추출하여 엣지 서버로 자동 배포함으로써 해당 스크래핑을 차단/제한할 수 있을 것입니다.
WE6.3.3	2분기 내에 핵심적인 언어 변형 지원 개선 사항을 구현하고 최소 3개의 언어 변형 위키에 파소이드를 성공적으로 배포하면, 나머지 모든 언어 변형 위키에 파소이드를 자신 있게 배포하는 데 필요한 주요 기술적 과제를 파악하고 해결할 수 있을 것입니다.
WE6.5.1	독자 유지 전략을 바탕으로 로그인한 사용자를 위한 성능 문제와 콘텐츠 캐싱 취약성을 조사 및 감사하고 목록화한다면, 목록화된 문제 중 어떤 것이 가장 큰 가치를 제공하는지 파악하여 적절한 우선순위 프레임워크를 통해 ST6.4를 자신 있게 계획할 수 있습니다.
WE6.5.2	만약 우리가 위키 간 코드 협업 플랫폼을 실험적으로 운영하고, 최소 4개의 인도 커뮤니티에서 테스트를 진행한다면, 커뮤니티 개발자들이 여러 위키에서 모듈을 재사용할 수 있도록 지원하는 방법을 배우고, 5월 첫째 주에 열리는 해커톤에서 이러한 결과에 대한 긍정적인 피드백을 받을 수 있을 것입니다. 이 실험은 루아 모듈에만 국한되며, WMF의 GitLab 인프라와 통합될 것입니다.
WE6.6.1	브라우저 테스트 작업의 실행 시간을 10분 미만으로 줄이면 해당 작업이 병목 현상을 일으키지 않게 되어 MW 코어 메인 테스트 빌드의 피드백 시간을 단축할 수 있습니다.
WE6.6.2	단위 테스트 작업의 실행 시간을 10분 미만으로 줄이면 병목 현상을 해소하고 MW 코어 메인 테스트 빌드의 피드백 시간을 단축할 수 있습니다.

신호 및 데이터 서비스(SDS) 가설 [ SDS 주요 결과 ] 토론
가설 단축명	4분기 텍스트	세부사항 및 토론
SDS1.5.1	봇 분류 결과에 대한 정기적이고 운영화된 내부 감사 프로세스를 구축한다면, 솔루션에 대한 신뢰를 확보하고 자동으로 탐지되지 않는 트래픽 패턴의 변화를 예측할 수 있을 것입니다.
SDS1.5.2	100% 샘플링과 요청 식별자를 사용하는 테스트 키친 장비를 배포하면 클라이언트 측 이벤트를 전송했는지 여부와 관계없이 모든 요청을 캡처하고 봇 동작을 분석할 수 있습니다.
SDS1.5.3	기본 클라이언트 측 신호를 분석하여 우리의 휴리스틱에 통합하면, 데이터 플랫폼에서 추가적인 봇 패턴을 탐지할 수 있을 것입니다.
SDS1.5.4	휴리스틱 알고리즘을 비공개 저장소로 옮기면 악의적인 공격자로부터 우리가 사용하는 정확한 논리와 데이터 소스를 보호할 수 있습니다.
SDS1.5.5	평가한 두 가지 신호를 기반으로 페이지뷰 지표에 수치 점수를 추가하면 트래픽에 대한 더욱 완전하고 세밀한 분석을 제공할 수 있습니다.
SDS1.5.6	평가한 두 가지 신호를 기반으로 페이지뷰 지표에 수치 점수를 추가하면 트래픽에 대한 더욱 완전하고 세밀한 분석을 제공할 수 있습니다.
SDS2.2.4	제품 안전 및 무결성 부서에서 성장책과 FerretDB를 검토하면 제품 출시 전에 중대한 위험 요소를 파악하고 완화하거나 해결할 수 있을 것입니다.
SDS2.2.5	테스트 키친 JS 및 PHP SDK에 실험 노출을 기록하는 메서드를 추가하면 모든 이벤트를 노출 이벤트로 처리할 필요가 없어지므로 성장책에서 실험 할당 쿼리 성능이 향상되고 더욱 정확한 실험 결과를 얻을 수 있습니다.
SDS2.2.8	독자 성장의 향후 A/B/C 테스트를 GrowthBook에서만 분석하는 방식으로 엔드 투 엔드 사용자 수용 테스트(UAT)를 수행하면, 어떤 부분이 실제 서비스에 적용 가능한 기준을 충족하고 어떤 부분이 광범위한 출시 전에 개선 및 추가 콘텐츠가 필요한지 파악할 수 있습니다.
SDS2.3.1	GrowthBook의 API를 검증하고 자체 API에 맞게 수정하면 GrowthBook을 표준 실험 제어 플랫폼으로 사용할 수 있으며, GrowthBook API를 정기적으로 폴링하면 GrowthBook에 구성된 실험을 빠르고 쉽게 배포할 수 있습니다.
SDS2.3.2	GrowthBook에 사용자 지정 유효성 검사를 구현하면 사용자가 플랫폼의 제약 조건을 위반하는 방식으로 실험을 실수로 잘못 구성하는 것을 방지할 수 있습니다.
SDS2.3.3	GrowthBook 사용자(사람, WMF의 자동화 스크립트, 신뢰 관계가 구축된 제휴사, 그리고 향후 NDA 검증을 거친 최종 사용자)에 대한 역할 기반 요구 사항을 확인하고, DPE에 정기적으로 보고하여 더 이상 사용하지 않는 사용자의 자동 프로비저닝 해제를 보장하고, 역할 기반 접근 방식과 권한 및 시스템 상호 작용에 대한 사용자 기대치를 설명하는 문서를 업데이트하면 사용자 온보딩이 더욱 예측 가능해지고 유료 라이선스 좌석 수를 초과하지 않도록 추가적인 안전장치를 마련할 수 있습니다.
SDS2.4.2	모니터링된 스트레스 테스트를 통해 트래픽 등록을 안전하게 확대하면 독자팀 실험의 통계적 검정력이 향상되어 실험 기간이 단축되고 의사 결정에 대한 신뢰도가 높아질 것입니다.
SDS2.4.3	캐시 분할을 사용하지 않는 실험에 대한 지원을 도입하면 팀들은 현재의 트래픽 제한(모든 위키의 10%, enwiki의 0.1%)을 넘어 자바스크립트 전용 기능을 테스트할 수 있게 되어, 테스트 키친 도입을 가로막는 주요 장벽 중 하나를 제거할 수 있습니다.

제품 및 엔지니어링 지원 (PES) 가설 [ PES 주요 결과 ] 토론
가설 단축명	4분기 텍스트	세부사항 및 토론
PES1.4.2	Codex PHP를 더 사용하기 쉽고 1.0 버전을 출시할 수 있을 만큼 안정적으로 만들면, 여러 팀에서 서버 생성 UI에 Codex PHP를 도입할 것입니다. 그렇게 되면 Codex PHP를 사용하는 프로젝트 수가 3개에서 5개로 늘어날 것입니다.
PES1.5.3	SLO 기반 알림 기능을 활성화하고 분기별 보고서를 자동으로 생성할 수 있도록 하면 서비스 소유자는 SRE의 개입 없이도 서비스 안정성 데이터에 대응할 수 있게 됩니다.
PES1.5.4	2026-2027년 회계연도에 SLO 및 프로덕션 준비와 관련된 역할과 책임에 대해 SRE 앰배서더와 명확한 기대치를 설정하고, TPgM 및 목표 소유자에게 이러한 기대치를 숙지시키며, SLO 워킹 그룹의 운영 방식을 정의한다면, 1분기부터 "일상적인" SLO 및 프로덕션 준비 작업에 대한 지지와 확장성을 확보할 수 있을 것입니다.
PES1.6.2	만약 우리가 서비스 카탈로그에 관리자들을 참여시키면, 그들은 "명백한" 후보들을 카탈로그에 채워 넣을 것이고, 우리는 최소 2개 이상의 중요한 미배정 서비스에 대한 담당자를 파악하고 찾아낼 수 있을 것입니다.

잠재적 청중 (FA) 가설 [ FA 주요 결과 ] 토론
가설 단축명	4분기 텍스트	세부사항 및 토론
FA1.1.2	앱 기반 콘텐츠 검색 기능을 세 가지로 나누어 짧은 실험을 통해 테스트해 보면, 차세대 앱 사용자들을 효과적으로 유치하고 유지하는 방법에 대한 권장 사항을 앱 팀과 공유할 수 있습니다.
FA1.1.6	디스코드에서 공유되는 위키백과 링크에 대해 서로 다른 3가지 미리보기 버전을 만들면 측정 및 실행 전략에 대한 내부적인 합의를 도출하고 디스코드의 제품 엔지니어링 팀과 협업할 수 있습니다.
FA2.2.1	만약 우리가 숏폼 비디오 플랫폼 전반에 걸쳐 커뮤니티 관리에 투자한다면, 2025년 2분기 말(12월)까지 틱톡에서 신규 시청자 비율이 전분기 대비 30% 증가할 것이며, 모든 숏폼 비디오 플랫폼에서 외부 콘텐츠에 달린 브랜드 댓글에 대한 참여도(좋아요 및 답글)가 총 5만 건에 달할 것입니다. 이는 가시성을 높이고 현재 도달하지 못하고 있는 잠재 고객과의 소통을 강화하는 데 도움이 될 것입니다.
FA2.2.2	위키피디아 크리에이터 파트너십 프로그램에 대한 내부 전략과 외부 공유 자료(크리에이터에게 제공하는 가치, 파트너십 기준, 계약 절차, 그리고 위키피디아 소유 채널과 크리에이터 채널 전반에 걸쳐 크리에이터 콘텐츠가 어떻게 표시될지 등을 포함)를 개발하고 승인을 받으면, 소셜 미디어를 통해 지식 콘텐츠를 활용하여 새로운 사용자층에 도달하는 데 도움이 되는 강력한 크리에이터 전략을 수립할 수 있을 것입니다.

함께 계획하기

2025년 1월 업데이트.

연간 계획은 위키미디어 재단이 내년에 이루고자 하는 바를 설명한 것입니다. 우리는 계획을 참여적이고, 열망적이며, 달성 가능하게 만들기 위해 열심히 노력합니다. 우리는 매년 기여자들에게 계획을 형성하면서 자신의 관점, 희망 및 구체적인 요청을 공유해 달라고 요청합니다. 우리가 그러한 의견을 구하는 방법 중 일부는 커뮤니티와의 제품 팀 대화, 커뮤니티 위시리스트, 공용 대화 시리즈와 같은 커뮤니티 대화, 컨퍼런스 및 이와 같은 위키 페이지를 통한 것입니다.

2025년 7월부터 2026년 6월까지의 다음 연간 계획에서는 세상과 인터넷의 빠른 변화와 그것이 우리의 무료 지식 사명에 어떤 영향을 미치는지 고려하여 다세대 비전에 가장 잘 부합하는 방법을 고민하고 있습니다.

작년에 말씀드렸듯이, 우리는 우리를 차별화하는 것에 집중해야 합니다. 즉, 인터넷과 새로운 세대의 관심을 끌기 위해 경쟁하는 플랫폼에서 허위 정보와 잘못된 정보가 만연하더라도 신뢰할 수 있는 콘텐츠를 제공할 수 있는 능력입니다. 여기에는 불평등, 차별, 편견으로 인해 발생할 수 있는 누락된 정보에 대한 범위를 확대하여 모든 인간 지식의 총체를 모아 전 세계에 전달하는 사명을 달성하는 것이 포함됩니다. 우리의 콘텐츠는 인공 지능과 풍부한 경험으로 주도되는 변화하는 인터넷에서 필수적이어야 합니다. 마지막으로, 우리는 제품에 대한 공유 전략을 구축하고 기금을 모금하여 이 운동을 지속 가능하게 자금 지원할 방법을 찾아야 합니다. 그래야 장기적으로 이 작업을 지원할 수 있습니다.

내년에 노력을 집중할 곳에 대한 선택과 균형을 이루기 위해 우리는 여러 질문을 모으고, 한정된 자원을 어떻게 배분하여 최대의 효과를 낼 수 있을지 고민했습니다.

여기서 정한 우선순위에 따라 제품 및 기술 부서가 어떤 기능이나 서비스를 구축할지 구체적으로 관심이 있다면, 3월에 구체적인 목표와 주요 결과에 대해 의견을 제시할 시간이 있을 것입니다. (참고로 현재 연간 계획에 대한 목표와 주요 결과가 있습니다.)

우리의 기술 환경이 직면한 과제와 기회, 그리고 다음 연간 계획에서 설정해야 할 방향에 대해 고민해보고 싶으시다면, 아래 질문을 함께 고려해 보시기 바랍니다.

우리는 커뮤니티 대화, 수집한 데이터, 진행한 연구 인터뷰 등 다양한 방법으로 이러한 질문에 대한 정보를 지속적으로 수집합니다. 이런 것들 중 많은 것에 대해 질문하고 배우는 것은 이번이 처음이 아니며, 이미 많은 것에 대한 작업을 해왔습니다! 지금 다시 질문하고 계속해서 배우고 싶습니다. 계획의 이 단계에서는 이것이 우리에게 가장 중요한 사항이기 때문입니다.

질문:

지표 및 데이터
- 데이터와 지표가 편집자로서의 당신의 작업을 더 잘 지원할 수 있는 방법에는 어떤 것이 있을까요? 편집, 독서 또는 정리에 대한 데이터를 생각해 보세요. 시간을 어떻게 보낼지 또는 무언가에 주의가 필요한지 선택하는 데 도움이 될 수 있을까요? 이는 당신 자신의 활동이나 다른 사람들의 활동에 대한 데이터일 수 있습니다.
편집
- 편집이 가장 보람차고 재미있게 느껴질 때는 언제인가요? 가장 답답하고 힘들 때는 언제인가요?
- 우리는 기여자들이 자신의 작업에 대해 더 많은 피드백과 인정을 받기를 바랍니다. 그래야 아무도 위키에 투자한 노력을 알아차리지 못하는 것처럼 느껴지지 않습니다. 어떤 종류의 피드백과 인정이 당신에게 동기를 부여합니까? 무엇이 편집을 계속하도록 격려합니까?
- 위키가 너무 커서 편집자는 매일 어떤 위키 작업에 시간을 할애하는 것이 가장 중요한지 결정하기 어려울 수 있습니다. 어떤 정보나 도구가 시간을 어떻게 보낼지 선택하는 데 도움이 될까요? 새로운 기회를 찾고, 작업을 관리하고, 자신의 영향을 이해할 수 있는 중앙의 개인화된 장소가 있으면 유용할까요?
- 우리는 위키에서의 협업 경험을 개선하여 기여자들이 서로를 더 쉽게 찾고 함께 프로젝트를 진행할 수 있도록 하려고 합니다. 백로그 드라이브, 에디터톤, 위키 프로젝트, 심지어 두 명의 편집자가 함께 작업하는 방식이든 말입니다. 더 많은 기여자들이 서로를 찾고, 연결하고, 함께 작업할 수 있도록 어떻게 도울 수 있다고 생각하십니까?
읽기/학습
- 위키는 사람들이 세계 어느 곳에 살고 있는지에 따라 더 빨리 로드되거나 더 느리게 로드됩니다. 성능 개선이 가장 필요하다고 생각하는 세계 지역이 있습니까?
- 새로운 세대의 독자들이 위키백과 콘텐츠를 흥미롭고 매력적으로 느낄 수 있도록 어떻게 도울 수 있을까요? 우리는 과거에 대화형 콘텐츠와 비디오에 대한 아이디어를 논의했고, 올해는 차트와 기존 위키백과 콘텐츠를 표면화하는 새로운 방법을 실험하는 데 집중했습니다. 위키미디어만의 새로운 방식으로 기존 콘텐츠를 사용하기 위해 이 트랙을 계속하려면 어떻게 해야 할까요?
중재자자
- 점검자나 관리자와 같은 고급 자원봉사자 역할에 더 많은 사람들이 참여하기를 원하게 하려면 위키백과에서 어떤 부분이 바뀌어야 할까요?
- 편집이나 사용자에 대한 어떤 정보나 맥락을 통해 점검이나 관리 결정을 더 빠르고 쉽게 내릴 수 있을까요?
외부 동향
- 위키미디어 밖의 세상에서 당신이 알아차린 가장 중요한 변화는 무엇입니까? 이는 기술, 교육 또는 사람들이 배우는 방법의 추세일 수 있습니다.
- 위키미디어 운동 외에, 당신은 어떤 다른 온라인 커뮤니티에 참여합니까? 다른 커뮤니티 플랫폼의 도구와 프로세스에서 어떤 교훈을 얻을 수 있습니까?
- 당신은 위키미디어 작업 안팎에서 AI 도구를 어떻게 사용하고 있나요? 당신은 AI가 무엇에 유용하다고 생각하시나요?
공용
- 백과사전적 지식 창출을 지원하는 지속 가능한 프로젝트를 만들기 위해 공용 커뮤니티와 함께 어떤 결정을 내릴 수 있을까요?
위키데이터
- 앞으로 위키데이터가 어떻게 발전하길 원하시나요? 신뢰할 수 있는 백과사전 콘텐츠를 구축하는 데 가장 유용한 방법은 무엇일까요?

토론

–– Selena Deckelmann