Skip to content

Release Proposal

easylogic edited this page Oct 1, 2026 · 56 revisions

work_id: wonffice-release-master artifact_type: release_proposal status: 미완료 owner_role: Planner source_request: "출시 준비 전체 관리와 모든 역할의 공통 보고 규칙" last_updated: 2026-10-01

Wonffice 출시 제안과 준비 상태

Current owner workflow and verified local evidence — 2026-10-01

The current execution/acceptance record is Local Alpha Verification, linked to the existing #322 tracker. Development remains local Git until final release; GitHub holds Issues/Wiki/Discussions. Planner and Execute are the active Works. Normal code PRs and the retired Review Work are not current local integration gates. Original acceptance, focused tests, Node/pnpm preflight, privacy/security and final release protections remain required.

Verified bounded Note recovery and explicit C-copy milestones are integrated locally at 2a7f9de6 and cb3f8cc7. The latest exact integrated evidence is17 focused units,13 affected mocked desktop cases and2 real PostgreSQL save/copy cases, with final candidate preflight exit0. These results do not satisfy the full #357 two-writer/process-restart/fault/privacy matrix, all four product collaboration, admin or external alpha requirements. #357 and #322 remain open. Yorkie upstream/parser work stays paused; snapshot children #405/#406/#407 and admin foundation #408 preserve their parent requirements.

The older dated sections below are retained historical records. Their specialist, main-only task PR and separate Review instructions are superseded by the current owner workflow; their original product/release criteria are not waived. No release date, deployed version, image digest or external launch approval is established here.

이 문서는 Product Master PM의 단일 출시 제안이다. 기술 실행 증거의 기준은 기존 #322다. 새 출시 추적 이슈를 만들지 않는다. 날짜·버전·이미지 확정이나 배포 승인을 대신하지 않는다.

첫 취합: 2026-09-20. 역할 보고 기준 main은 eeb0ab67390b2898e85d8aa1e028ce5b6a993ff2이며, 취합 중 Note PR #283이 0d97e1f00948aafd27bd6bdf4ac2b9a2f9f51e60으로 병합됐다. 어느 커밋도 공식 출시 후보로 지정하지 않았다. PR별 검사 버전은 서로 다르므로 합산해 통합 통과로 표시하지 않는다.

제품 방향 갱신: 단일 전략 기준에 사용자 비전을 반영했다. 가까운 사업 목표는 첫 alpha 완성 후 소수 실제 사용자에게 외부 서비스로 제공하는 것이다. 현재 표의 내부 alpha는 기술 인수 관리 단계이며 외부 제공 목표를 취소하는 뜻이 아니다. 외부 제공 시의 단계 명칭·대상 기능·운영 약속은 실제 후보를 바탕으로 정리한다. 기존 인수 조건과 SaaS·내부 설치 결정을 유지하며 새 beta 요구를 자동으로 추가하지 않는다. 첫 고객군·핵심 업무는 미확정이고 교육팀은 준비 가설이다.

#379 병합 이후 #367→#380 선행 재확인 — 2026-09-23 10:42 UTC

Note 코덱 PR #379은 main 4cf34c45e118fb8808a14ea2f94d21ecdb02a993에 병합됐다. #367 문서 API draft PR #382는 현재 기존 로컬 QA 후보 aad0ad94f18eb5664e4ab41636cd6bc773ccf9ca head다. 10:42 UTC의 PostgreSQL·API container CI는 성공했지만 다른 검사는 진행 중이었으며, #379가 포함된 새 main 기준 최종 head 재검증이 필요하다. 이전 #367 문단의 “공개 PR 없음”과 #379 draft 표기는 그 문단 작성 시점 기록이다.

#380 head ca10a0d460ccc08d55534c8028237c59d8e10fbe의 녹색 CI는 이전 main 기준이다. #382의 0004_document_snapshots가 먼저 병합된 뒤 0005_platform_operators를 정확한 새 main에서 다시 검증한다. 합성 DB 복원 보고는 유지되지만 현재 결합 후보·실제 설치 복원·독립 QA/Security·사람 승인 절차는 미완료/미확인이다. 내부 alpha 준비 지속·외부 alpha 보류, SaaS·내부 설치 동시 출시 방향은 유지한다.

#367 문서 API 로컬 독립 QA — 2026-09-23 10:25 UTC

Mento의 #367 QA 요약은 **로컬 clean commit aad0ad94f18eb5664e4ab41636cd6bc773ccf9ca**에 한정된다. Node 22·격리 PostgreSQL 0001–0004·실제 Keycloak 두 합성 PKCE 계정·14102 API에서 Note 문서 생성/동일 idempotency 재시도/receipt/list/open, 같은 회사 다른 계정 읽기, 다른 회사·viewer 쓰기 거부, 오래된 revision·잘못된 receipt·공동편집 mode 충돌, API 재시작과 같은 token membership 회수를 통과했다고 보고했다. 원문은 output/mentor/wonffice-367-document-api-qa.md; PM은 재실행하지 않았다.

준비 상태: 이 로컬 후보의 검사한 문서 API 시나리오만 준비 완료다. 공개 #367 PR/최종 CI·Yorkie key/권한·#357 Note UI와 네 제품 동일 후보 인수는 미완료다. 로컬 후보는 코덱 3bb61e99를 포함하지만 draft PR #379 현 head a45a45c0 이후 #367 통합 새 head 검사는 별도로 필요하다. 추가 diff가 타입/패키지 선언뿐이라는 소스 대조를 QA 전용으로 사용하지 않는다.

출시 제안·남은 위험·담당: 외부 alpha 보류. Backend Master는 #367 0004_document_snapshots 공개 후보를 정하고 #379과 합친 head를 QA/Security에 인계한다. #367 0004가 main에 들어간 뒤 #380 0005를 새 main에서 재검증한다. Security의 receipt snapshot 사본 보관/삭제·tenant 종료·백업 복원 정책과 실제 담당은 미확인이다. 합성 자료 정리는 실제 고객 데이터 수명 결정이 아니다. 사용자/전문 담당이 그 정책 책임과 승인 절차를 정해야 한다.

플랫폼 운영자 PR #380 정확한 head·복원 경계 — 2026-09-23 10:38 UTC

대상은 원격 main 0ffcd77f535c4e4cd080cef65c0178c2cfbd9c78와 #376/draft PR #380 head ca10a0d460ccc08d55534c8028237c59d8e10fbe다. 운영자 grant·회수·감사와 최소 조회 API 후보의 이 head 실행 CI 10개는 모두 성공했다. Backend는 Node 22 preflight, 격리된 합성 PostgreSQL에서 새 grant·감사 테이블을 새 DB로 복원하고 회수된 grant가 복원 뒤에도 거부되는 검사를 통과했다고 PR에 보고했다. PM이 그 로컬 검사를 재실행한 것은 아니다. 따라서 해당 head의 CI 범위는 준비 완료, 합성 DB 복원은 담당 실행 보고, #376 전체와 실제 설치 운영은 미완료다.

병합 선행·재검증: #367의 0004_document_snapshots를 먼저 main에 반영하고 #380의 0005_platform_operators를 그 main에서 다시 검증한다. 현재의 녹색 CI는 이 순서가 실제로 합쳐진 DB/서비스 후보의 결과가 아니다. #380은 draft이며 독립 QA/Security·Architecture/Operator 검토, 실제 설치 백업 보존·복구 절차는 미완료다. 새 합성 복원 결과로 실제 설치의 보존 기간이나 재해 복구를 완료 처리하지 않는다. Backend가 순서와 최종 후보를, Operator가 실제 설치 복원과 비공개 grant 절차를, QA/Security가 정확한 후보의 회수·감사·고객 문서 차단을 검증한다. #377 회사 구성원 API와 #378 운영 화면은 별도 미완료다.

표시·사람 권한 경계: owner_provisioned는 첫 owner bootstrap 여부만 뜻한다. /v1/operator/status의 바깥 HTTP 200이어도 본문 ready.httpStatus=503이면 서비스는 미준비다. #378은 조회 시각·재확인, 실패와 준비 상태를 구분한다. tenant 이름은 고객 메타데이터이므로 최소 노출·감사·보존 검토가 필요하다. 첫 실제 운영자 grant의 사람 승인권자·담당은 미확인이고 실제 계정은 발급하지 않았다. 고객 자료 예외 접근은 현재 기본 금지이며 변경은 사용자 결정과 Security 검토가 필요하다.

출시 제안: 내부 alpha 통합 준비를 계속하고 외부 alpha는 보류한다. 네 제품의 실제 PostgreSQL/Fastify/UI/Yorkie 저장·두 계정 인수, SaaS·내부 설치 운영 검증과 사람 책임 결정이 완료되기 전 #380 단독 통과를 출시 준비 완료로 바꾸지 않는다. MR-44의 KDP 출판 후보는 고객 증거가 없는 별도 시장 가설이라 이번 alpha 범위에 넣지 않는다.

Site 첫 데이터 생성과 #373 인수 선행 — 2026-09-23 09:55 UTC

#375는 main 41df1b86 독립 브라우저에서 새 빈 Site의 데이터 → 새 데이터가 자료를 만들지 않는데 저장됨을 보인 재현이다. 최신 main 0ffcd77f의 관련 Site 소스는 같지만 최신 commit의 UI 재실행은 미확인이다. 기존 데이터의 빈 본문 편집 #325/PR #339와 다르다.

출시 제안·준비 상태: 기존 Site Developer를 #375 주 담당으로 연결한다. P2 제안은 유지하되 #373의 dataset 생성·행·저장/재열기 인수 전에 해결할 Site 경로 선행 조건이다. #375 로컬 첫 사용 경로와 #373 인증 서버·Yorkie 통합은 별도 검증한다. #367/#366 선행 및 Note→Word→Slides→Site 순서는 바꾸지 않는다. 정확한 수정 후보의 새 Site UI QA와 네 제품 동일 후보 두 계정 인수는 미완료다. 공식 통합 후보가 없어 지금은 제품 전체 출시 차단 여부 미확인이며, 공식 후보에서 같은 문제가 남으면 Site dataset·외부 alpha 인수는 미완료다.

남은 위험·다음 담당·결정: 저장됨 오표시는 데이터 생성 실패를 숨긴다. Site Developer는 기존 PR 파일 소유를 조율해 #375를 고치고, QA는 실제 새 Site 생성→행 입력→저장·재열기·출력과 #373 통합 후보의 같은 경로를 검증한다. PM은 #322에 후보별 결과를 연결한다. 현재 범위를 바꾸거나 #376~#378 관리자 업무를 재배정할 사용자 결정은 없다.

#374 공통 진입의 현 head QA 보고 — 2026-09-23 09:54 UTC

Mento는 draft PR #374 head 8522dc18b02f8cbb549ed0042de57dd63c0fdcba에서 실제 합성 Keycloak·API 두 계정 로그인/로그아웃, viewer 관리 거부→사용자 허용, 계정 전환, BFCache 이전 본문 차단, Note 직접 URL fail closed, Node 22 preflight와 CI 8/8 통과를 보고했다. PM은 원시 QA 로그를 재실행하지 않았고 공개 인수 링크는 미확인이다. 이 보고는 검사한 공통 진입 경로에 한정한다. #367 문서 권한·#378 실제 두 관리자 업무·네 제품 저장/협업 인수는 미완료이며 draft·승인 리뷰 부재로 외부 alpha 제안은 보류다.

#374 직접 URL 차단 제목 초점 — 2026-09-23 10:10 UTC

Design Engineer 실행 결과는 PR #374 head 8522dc18b02f8cbb549ed0042de57dd63c0fdcba의 Note·Word·Slides·Site 직접 URL 차단 화면 4/4에서 첫 초점이 제목 대신 body에 남았음을 보였다. 첫 Tab으로 복귀 버튼 도달과 화면 이동은 4/4다. #369의 제목 초점 완료 기준은 미완료이므로 기존 Developer가 같은 PR 범위에서 수정하고 QA가 정확한 수정 head를 재검증한다. CI 8/8과 다른 두 계정 진입 통과 보고는 이 실패나 #367 문서 권한·#378 실제 두 관리자 업무·외부 alpha 인수를 대체하지 않는다.

첫 alpha의 두 관리자 실제 업무 — 2026-09-23 09:30 UTC

사용자는 첫 alpha에 회사 관리자와 별도 Wonffice 전체 서비스 운영자 둘 다 필요하다고 확정했다. 기준 원격 main은 0ffcd77f535c4e4cd080cef65c0178c2cfbd9c78. #355/PR #370은 09:24 UTC 병합돼 OIDC 신원·현재 tenant membership 백엔드 단위가 준비 완료다. #369/draft PR #374의 현재 head 8522dc18b02f8cbb549ed0042de57dd63c0fdcba는 09:45 UTC 실행 CI가 모두 성공했으나 draft·승인 리뷰 없음이다. 앞선 a0ca106b의 UI QA를 이 head의 독립 인수로 전용하지 않는다. #374는 공통 로그인·회사 역할 진입 후보이며 실제 관리 업무와 별도 서비스 운영자 grant는 미완료다. 아래의 “관리자 유형/첫 업무 답 대기”는 이 사용자 결정 이전 상태다.

첫 alpha 최소 업무 제안 완료 경계 담당·선행
회사 owner/admin: 자기 회사의 기존 구성원·역할 확인, editor/viewer 역할의 제한 변경·회수 현재 회사 membership을 매 요청 재조회하고 다른 회사·회수 계정은 거부한다. owner 강등·admin 승격·새 계정 초대는 이번 화면에서 제외한다. 변경과 거부를 고객 원문·token 없이 감사한다 Backend Master의 제한된 구성원 API → 기존 Developer의 Office 관리 화면 → QA·Security 동일 후보
플랫폼 운영자: 기존 감사 CLI로 준비된 tenant의 상태와 서비스 health 확인 (issuer,subject)에 묶인 별도 서버 grant를 매 요청 확인하고 회수 직후 거부한다. tenant owner/admin과 상호 자동 승격하지 않고, 운영 권한만으로 고객 문서에 접근하지 못한다 Backend Master의 독립 grant·상태 API → 기존 Developer의 Office 운영 화면 → QA·Security 동일 후보. 최초 grant의 사람 승인권자 미확인

초기 tenant/owner 부여는 #355의 비공개 감사 CLI와 사람 승인 절차를 재사용한다. 배포·장애 조치와 운영 로그는 Operator의 별도 절차로 추적하며 이번 화면에 전체 로그나 고객 자료를 추가하지 않는다. 결제·전역 고객 문서 열람·고급 관리 대시보드도 제외한다. 공통 #369/PR #374는 로그인 뒤 서버가 허용한 관리 범위 선택과 직접 URL 차단을 맡는다. 중복 확인 뒤 Backend 플랫폼 운영자 grant·상태 API #376, 회사 구성원 권한 API #377, Developer 두 관리자 Office 첫 업무 UI #378을 별도 단위로 기록했다. 순서는 #376·#377 서버 계약과 #369 공통 진입 → #378 화면 → QA/Security 동일 후보 인수다. #367 문서 API와 서버 파일 소유를 조율한다. 이슈 등록은 구현·검증 완료가 아니다.

출시 제안: 내부 alpha 통합 준비를 계속하고 외부 alpha 제공을 보류한다. 두 관리 경로의 실제 권한 변경·회수·401/403/5xx·계정 전환, 네 제품 동일 후보 저장/협업, Yorkie Cloud와 SaaS/내부 설치 운영 인수는 미완료다. 최초 플랫폼 운영자 grant의 실제 승인권자·담당, 고객 자료 예외 접근 허용 여부(기본 금지), 지원·계약·결제·개인정보 책임, 환경·예산은 사용자 결정/담당 확인이 필요하다. 사람 승인 절차 전 실제 운영자 계정 발급을 하지 않는다. SaaS·내부 설치 동시 출시 결정은 유지한다.

최신 사용자 결정: 외부 alpha 전 네 제품의 실제 저장·공동편집 인수

Mento가 전달한 사용자 결정에 따라 외부 alpha의 대상은 Note·Word·Slides·Site 네 제품 모두다. 순서는 Note → Word → Slides → Site다. 각 제품에서 실제 로컬 PostgreSQL·Fastify API·제품 UI·서로 다른 두 계정·Yorkie 연결을 끝까지 실행해 검증한다. Note 한 제품의 성공을 네 제품의 성공으로 기록하지 않는다. 외부 alpha에서는 Yorkie Cloud를 사용한다. 내부 통합 테스트에서도 실제 Yorkie를 사용한다. 첫 합성 기능 시험은 분리된 로컬 Yorkie를 우선 검토하되 자체 설치를 필수 공급자로 확정하지 않고 외부 Yorkie도 허용한다. 로컬 Yorkie 인증 없는 합성 수렴은 Wonffice 로그인·권한 인수가 아니다. 최종 통합 후보·프로젝트 키·Cloud Auth Webhook 설정은 미확인이다. Cloud 연결 검사를 완전 오프라인 검사로 부르지 않는다.

데이터 경계: Yorkie가 동시편집 상태와 협업 원문을 소유한다. 자체 API/worker와 PostgreSQL은 사용자·회사·권한·문서 메타데이터 등 일반 업무 데이터를 소유한다. 이미지·첨부는 별도 파일 저장소를 쓴다. 인증과 접근 제어는 Wonffice 책임이다. PostgreSQL의 이전 snapshot 저장이 활성 협업 문서를 덮어쓰지 않아야 한다. 자체 협업 서버를 새로 만들지 않는다. 기존 Yjs/Automerge 코드를 자동 삭제하거나 병행 구현 대상으로 정하지 않는다.

제품별 동일한 인수 조건

제품·순서 PostgreSQL 메타데이터·API/UI와 Yorkie 원문 재열기 Yorkie 두 계정 동시편집·재접속 상태
Note — 1 실행 근거 필요 수렴·영속 결과 근거 필요 미완료
Word — 2 실행 근거 필요 수렴·영속 결과 근거 필요 미완료
Slides — 3 실행 근거 필요 수렴·영속 결과 근거 필요 미완료
Site — 4 실행 근거 필요 수렴·영속 결과 근거 필요 미완료

각 제품에서 브라우저·API 재시작 후 저장 내용, 연결 단절·복귀, 중복/누락, 저장 실패 표시, 구조 변경과 사용자별 undo/redo, 권한 회수 후 읽기·쓰기 차단, 이전 snapshot 덮어쓰기 방지를 검사한다. 동일한 통합 후보 commit과 제품·DB·Yorkie 버전, 환경, 합성 자료, 실행 로그, 독립 QA 결과를 연결한다. 로컬 인수와 SaaS·내부 설치 외부 환경 인수는 별도다. 브라우저 로컬 저장·DB 단위 검사·협업 어댑터 문서·개별 PR 통과만으로 전체 인수를 완료 처리하지 않는다.

선행·담당과 현재 판단

순서 범위 다음 담당·상태
1 #351/PR #352의 tenant DB·migration·복원 기반과 #355의 실제 OIDC·membership #352는 main e8f2821b에 병합됐고 #351은 닫혔다. 정확한 head 84d56f4a의 CI·독립 DB QA는 tenant DB 기반 범위에서 준비 완료다. #355 인증과 제품 통합 인수는 남았다. WP-05 전체 미완료
2 Note 본문/API/UI/인증과 Yorkie 저장·동시편집·권한 경계 Backend Master·Architecture가 계약과 소유 범위를 합의하고 Developer/UI와 연결. 미완료
3 같은 계약을 Word → Slides → Site에 적용 각 제품 기존 담당·이슈와 대조 후 최소 구현 단위로 연결. 미완료
4 네 제품 로컬 통합 후보의 독립 인수와 사용자 실행 가이드 QA Tester·Operator·Technical Writer. 후보 미지정, 검사 미완료
5 SaaS·내부 설치의 별도 환경·비용·운영·지원 조건 Operator·Security·Support 보고 → Product Master PM 종합 → 사용자 최종 결정. 미확인/미완료

현재 제안은 준비를 계속하고 외부 alpha 제공을 보류하는 것이다. SaaS·내부 설치 동시 출시 결정은 유지한다. 다국가 소수 사용자와 월 약 5만 원의 DB·파일·협업 운영비는 검증할 제약이다. Railway/Render는 비교 후보이며 공급자·지역·요금제를 확정하지 않았다. 실제 공급자 한도·비용, 내부 시험의 Yorkie 최종 배치·키/Webhook 설정, 비공개 지원 창구·사람 운영 책임자, 정확한 출시 후보와 실행 증거는 미확인이다. 외부 인프라 구매·계정·배포·고객 약속은 별도 사용자 결정 대상이다.

이 단락은 이전의 '제품 범위 답변 대기'와 '협업 공급자 미선택/후속'이라는 과거 상태보다 최신이다. 아래 역할별 기록은 당시 확인한 범위를 보존하며 현재 통합 인수를 대신하지 않는다. 출시일은 정하지 않았다. 기존 #322의 WP-01/02/05/06과 두 배포 형태 조건을 함께 추적한다.

로컬 수직 통합 실행 계획 — #322의 2026-09-23 PM 인계

단일 출시 추적 #322의 실행 계획은 Note를 첫 검증 단위로 두고 Word→Slides→Site에 같은 인수 계약을 순서대로 적용한다. 외부 alpha 전 네 제품 모두의 실제 PostgreSQL/Fastify UI·Yorkie/두 계정·복구 인수는 유지한다. 현재 원격 main b59a84432946541a5684ca40ed07d2342807c661(#360 협업 계약 문서 병합)은 공식 통합 후보가 아니며 후보 commit·이미지 digest·인스턴스/설정 식별자는 미지정/미확인이다. 개별 PR의 head와 검사 결과를 한 후보로 합산하지 않는다.

단계·담당 경계 진입/인계 기준 현재 상태
Backend Master: #351/PR #352 → #355 → #367 문서 API → #366 Yorkie 권한 병합된 DB 기반 뒤 실제 OIDC/membership, 본문/revision/멱등 receipt/권한 API와 Yorkie snapshot 금지 계약. Architecture·Security 검토를 받는다 #352 최신 head 84d56f4a45593b9cb4fa33955c98eed3b832681f: main e8f2821b 병합. GitHub CI와 이 head 독립 QA의 DB 13/13·단위 3/3 준비 완료. 이는 DB 기반만 해당한다. #355/#367/#366 구현 미완료
Note Developer: #357 확정 Backend DTO/API 뒤 단일 작성자 snapshot의 저장·재열기·실패/복구·로컬 원본 보존·C 사본/링크 제한. #357은 Yorkie 공동편집을 포함하지 않는다. 공통 세션 #361은 기존 Developer 소유 snapshot UI/API 미완료
후속 WP-09 Note Yorkie: #366 서버 권한과 #368 제품 adapter Backend는 #366의 문서↔Yorkie ID·Auth Webhook·권한/회수, 기존 Developer는 #361 공통 모델/undo, Note Developer는 #368 Note adapter/UI를 소유한다. #367 문서 API와 #357 snapshot UI가 선행한다. #360 문서 계약은 main에 병합됨 #366/#368 이슈는 열려 있고 구현·검증 미완료. 다른 역할의 진행 과제를 중복 배정하지 않음
QA Tester: 동일 후보의 독립 인수 Backend의 기동·합성 계정/권한, #357 snapshot UI와 별도 WP-09 Note 제품 재현 절차를 받아 실제 DB/API/UI/Yorkie 두 계정의 저장·동시편집·재접속, 브라우저/API 재시작 뒤 영속성, 선택한 Yorkie 배치에서 가능한 장애·복원, 실패·중복 요청·undo/redo·권한 회수·오래된 snapshot 차단을 검사. 제품별 로그를 #322에 연결 후보·실행 미완료
Operator: 시험 환경·증거 묶음 같은 후보의 DB·선택한 Yorkie 공급자 배치/버전, 로컬 구성의 기동/종료·백업/복원, 외부 구성의 안전한 연결·비밀 제외 설정과 로그를 QA/PM에 연결. 실제 제품 배포는 별도 로컬 Yorkie/DB의 분리·기동 확인 절차만 범위 한정 준비 완료. 시험 시 접근 경계·서비스 상태를 다시 확인해야 하며 공식 후보·복원 증거 미확인

Mento의 #322 합성 두 클라이언트 검증 보고에 따르면, 사용자 제공 public key를 값 공개 없이 사용한 Yorkie Cloud 브라우저 SDK 0.7.23에서 서로 다른 client ID의 두 독립 브라우저가 합성 문서의 동시 변경을 수렴했고, 새 브라우저로 다시 연결해 내용을 확인했다. 이 공급자 SDK·합성 문서 범위는 준비 완료다. 로그인 사용자를 구분하거나 제품 UI를 실행한 검사는 아니다. public key만으로 합성 문서 연결·수정이 가능했으므로 OIDC·Auth Webhook·PostgreSQL/API 권한·회수, 네 제품 UI·같은 후보의 두 로그인 사용자·제품 재접속/영속성은 미완료/미검증이다. Node SDK 직접 실행의 HTTP 464 원인은 미확인이다. 키 값은 Wiki에 기록하지 않는다.

Wonffice 로그인 후 사용자·관리자 진입 — 최신 사용자 결정, 2026-09-23

사용자는 로컬 Yorkie의 합성 공동편집 시험에는 Yorkie 자체 인증이 필수가 아니며, Wonffice 서비스에는 실제 인증과 사용자/관리자 진입 구분이 필요하다고 명시했다. PM의 이전 “첫 내부 alpha 관리자 화면 제외” 제안은 이 진입 범위에서 철회한다. 사용자에게 확인 중인 항목은 여기서 말하는 관리자가 고객사 tenant 관리자, Wonffice 플랫폼 운영자, 둘 다 중 무엇인가이다. 확인 전 이 권한을 한 화면·역할로 합치지 않는다. Site 제품의 페이지·데이터·발행 Admin은 서비스 권한 관리 화면이 아니다.

플랫폼 설계는 tenant owner/admin/editor/viewer와 서버 측 현재 membership을 정의한다. WP 인수 문서는 두 배포 형태의 초기 관리자·로그인을 요구한다. 고급 관리 기능의 동시 구현 제외는 유지하되, 로그인 후 역할별 목적지 선택/거부 UI는 첫 제품 요구로 제안한다. 로그인 전 사용자/관리자 선택은 이동 의도일 뿐 권한이 아니다. 같은 OIDC 로그인 뒤 #355 서버가 신원·현재 회사별 역할과 별도 플랫폼 운영 권한을 각각 검증해 화면/API 접근을 결정한다. 단일 역할은 허용된 목적지로, 복수 역할은 허용된 목적지만 전환한다. 플랫폼 운영 권한만으로 고객 문서를 열 수 없게 한다. 직접 URL·캐시·브라우저 입력으로 관리자 권한을 얻지 못한다. 만료·회수·다른 회사 전환을 재검사한다.

범위·단계 준비 상태 다음 담당·의존 관계
#352 tenant DB 정확한 head CI·독립 PostgreSQL QA와 main 병합은 이 DB 기반 범위 준비 완료 Backend 완료. 제품 인증·전체 저장 인수는 아님
첫 제품의 Wonffice 로그인/역할 진입 미완료. 현재 5186 화면은 로컬 브라우저 자료함이며 인증된 서비스 화면이 아님 Backend Master #355 OIDC·membership·초기 owner 계약 → Product Designer의 공통 진입 UX → #369 Office 호스트 UI를 기존 Developer가 구현 → QA·Security의 같은 후보 두 계정·tenant·회수 검증. 관리자 업무 메뉴는 사용자 답 뒤 확정. 로그인·회사 선택 UI는 #355 뒤 선행 가능하지만 직접 문서 URL 전체 인수는 #367 보호 문서 API 뒤
로컬 Yorkie 합성 공동편집 인증 없는 합성 수렴·재시작 검사는 협업 기능 범위. 실제 로컬 저장/재시작 보존은 미검증 Operator가 분리한 로컬 Yorkie를 첫 내부 기능 후보 배치로 확인 → 제품 담당/QA. 원격 Cloud도 허용하나 필수 로컬 공급자로 고정하지 않음
외부 alpha Yorkie Cloud 권한 미완료. 로컬 합성 성공을 권한 완료로 전환하지 않음 #355→#367→#366 capability/Auth Webhook·권한 회수, Operator의 안전한 Cloud callback, QA·Security 같은 후보 검증. Operator의 발신자 인증 미확인 보고에 따라 인증 확인 전 공개 ingress 금지

#355→#367→#369 공통 진입 계약 — 2026-09-23 보완

최신 원격 main f0ad4c7b1c6c06b8ecf2405f9de87e18a76f0908에서 Office main.tsx는 WorkspaceHome을 즉시 mount하고, host.tsx의 제품 직접 주소는 서버 인증 전에 로컬 본문을 읽는다. 이는 현재 로컬 미리보기 구현 사실이며 인증된 서비스의 통과 근거가 아니다. Design Engineer의 코드 검토와 #369 보완 기준에 따라 인증 후보의 홈과 네 제품 직접 URL은 서버의 신원·활성 tenant/역할·해당 문서 접근 확인 전에 목록·본문을 mount·읽기·잠깐 표시하지 않아야 한다. 401, 로그인한 사용자의 403, 네트워크/5xx, 활성 회사 0개, 허용 회사의 문서 0개는 각각 구분한다. #347의 테스트 PR 병합은 이 실행 검증을 대신하지 않는다.

#355 PM 계약 보완은 현재 사용자에게 허용된 활성 회사 목록과 회사별 역할을 서버가 제공하도록 요청한다. 초기 미커밋 작업본의 목록 공백 보고 뒤, Backend PR #370 head 7bd353111ae268e3660f5a23209e14cc8c94d87c의 /v1/me는 검증한 신원과 활성 tenants[{tenantId,name,role}]·nextCursor를 반환한다. PM이 이 불변 커밋 소스를 읽어 DTO 존재를 확인했다. PR은 열렸고 Backend의 로컬 OIDC/PostgreSQL 실행 보고와 PostgreSQL CI 성공은 있지만, 2026-09-23 07:33 UTC 기준 API container smoke·전체 unit CI 실패와 독립 QA/Security 인수는 미완료다. 선택한 회사와 문서 접근은 매번 서버가 다시 확인한다. Security가 보고한 마지막 owner 감소 가능성은 위 로컬 커밋의 grant/revoke 경로가 owner 변경을 거부하도록 수정됐다. PM이 소스를 읽었지만 실제 회귀 검사를 재실행하지 않았다. PR #370의 실패 CI 수정·정확한 head의 독립 QA/Security 확인 전에는 owner 불변식을 준비 완료로 표시하지 않는다. Backend #355 DTO 뒤 Developer #369는 로그인·회사/역할 선택 화면을 먼저 만들 수 있다. 그러나 네 제품 직접 문서 URL의 전체 완료는 #367 보호 문서 열기·문서 ID/tenant/ACL API가 선행이다. #367 전에는 로컬 UUID·URL로 접근을 추정하지 않고 fail closed로 둔다. #355→#367→#369의 직접 URL gate 뒤 QA·Security가 같은 후보를 인수한다. A 계정의 본문을 본 뒤 로그아웃·B 계정 전환과 브라우저 뒤로/앞으로 가기·기록 복원·다른 탭 복귀에서 이전 본문이 순간적으로도 노출되지 않는지 실제 브라우저에서 확인한다. 이 검증이 없으면 #369 전체 완료로 표시하지 않는다. 이 보완으로 관리자 업무 메뉴나 외부 alpha 범위를 늘리지 않는다.

관리 업무의 최소 범위는 사용자 답변 대기: tenant 관리자의 구성원 보기·추가/정지·역할 변경과 플랫폼 운영자의 설치·키·장애 권한은 다른 경계다. 최초 tenant owner 부여는 Backend #355의 안전한 운영 계약으로 검토하고, 결제·전역 대시보드·고급 설정은 자동 포함하지 않는다. Product Designer의 진입 UX 초안은 설계 제안 준비 완료, 실제 관리자 유형·첫 행위와 구현 이슈/제품 UI는 미확인/미완료다. 공통 진입 UI는 중복 확인 후 #369로 분리했다. 관리자 업무 구현은 유형·첫 행위 답변과 중복 확인 뒤 정한다. 실제 운영 사람·비공개 지원 창구도 미확인이다. SaaS·내부 설치 동시 출시 결정과 외부 alpha 보류는 유지한다. 근거·정정은 #355 PM 댓글과 #366 PM 댓글이다.

Yorkie Cloud Auth Webhook 토큰 경계 — PM 제안, 2026-09-23

Yorkie 공식 보안 문서는 클라이언트 token을 Cloud가 Auth Webhook에 전달하고, Webhook 응답으로 허용·거부한다고 설명한다(조회 2026-09-23). 이는 공급자 문서 사실이며 Wonffice 실제 권한 검증 결과가 아니다. PM은 #366의 진행 기준으로 #355 OIDC 검증 후 짧은 수명의 불투명 Yorkie 전용 capability를 발급하고, #366 Webhook이 현재 세션·문서 ACL·mode를 서버에서 재검사하는 안을 제안했다. 원본 OIDC/API bearer를 Yorkie Cloud에 전달하는 안은 기본 구현 기준에서 제외한다. 대안·반대 근거·결정 조건은 Discussion #288에 기록했다. 이 판단은 Product Master PM의 내부 설계 제안이며 Cloud 사용·외부 제공 승인이나 제품 실행 완료가 아니다.

순서는 #352 기반 → #355 인증/소속 → #367 문서 메타데이터·revision API → #366 Auth Webhook/서버 권한과 #357 Note snapshot UI → #368 Note Yorkie adapter → 동일 후보 QA다. #366은 capability 만료·폐기, Webhook 호출자 인증과 접근 경계, 401/403·재접속·Watch 권한 회수의 실제 동작을 검증해야 한다. 공급자의 token 보관·로그·지역·삭제 조건, 개인정보 검토 담당, 두 로그인 사용자와 네 제품의 인수는 미확인/미완료다. 고객 자료나 비밀 키를 공개 문서에 기록하지 않는다. SaaS·내부 설치 동시 출시 방향과 외부 alpha 보류는 유지한다.

PR #359 head 15722e3a487322f79378d6b3af7aa5bc8c51f0f2의 독립 Slides 휴지통 A 거부 뒤 B 보존·재열기 브라우저 여정 1/1은 그 로컬 UI 범위에서 준비 완료다. PR은 draft이고 #347 선행, #361 부분 교체 실패, 서버·Yorkie·두 계정 인수는 미완료다. Design Engineer의 #322 검토에 따르면 현행 저장됨은 로컬 브라우저 저장만 뜻한다. 서버 확인 전 입력·재접속·권한 회수의 UI 계약은 미완료다. PMF MR-24의 음악 크레딧 후보는 고객 증거가 없으므로 이 alpha 범위나 출시 필수 작업으로 올리지 않는다. Technical Writer의 PR #358 문서 CI는 범위 한정 준비 완료지만, 실제 DB/API/Yorkie 기동·재시작·합성 두 계정·제품별 저장/복구의 재현 안내는 Backend·Operator·QA 입력 전 미완료다. Backend의 분리된 로컬 Yorkie/MongoDB 실행 보고와 Operator 점검은 분리·기동·DB 연결 확인 절차에 한해 준비 완료다. 시험 시 Yorkie 서비스의 접근 경계·상태를 다시 확인해야 한다. 합성 문서의 재접속·재시작 보존, 공식 통합 환경, API/UI·두 계정·네 제품의 동일 후보 인수는 미완료다. 로컬 통합 계획 작성은 준비 완료지만 공식 후보는 미확인이다. 외부 Yorkie도 내부 시험에 사용할 수 있다. 최종 배치·키/Webhook 설정, 실제 운영자·외부 제공 조건은 미확인이다. 외부 서비스 사용 허용은 고객 데이터 사용이나 운영 배포 승인이 아니다. 사용자에게 필요한 첫 외부 alpha의 고객사 내부 설치/배치 결정은 아래 기존 선택안에서 계속 추적한다.

PostgreSQL 저장 기반 독립 QA — 2026-09-23

대상은 #351의 tenant·migration·복원 기반과 PR #352 head 01b576cab077349e202969cf528dbe6e12a38aad다. QA 결과 인계에 따르면 QA Tester가 별도 작업 공간에서 추적 파일 3,045개를 head와 대조하고 PostgreSQL 16.13 임시 DB에서 기존 test:postgres 13/13을 통과했다. migration 경합·rollback, tenant RLS·pool context, 새 DB dump/restore 뒤 내용 hash·RLS를 확인했다. PM이 검사를 재실행한 것은 아니다. head의 PostgreSQL CI와 전체 CI도 성공했다. 초기 샌드박스 공유 메모리 거부는 추가 권한으로 같은 명령을 재실행해 통과했으며 제품 실패로 분류하지 않는다.

범위 상태 남은 위험·다음 담당
head 01b576ca의 DB 격리·migration·새 DB 복원 QA 준비 완료 QA의 실행 보고에 한정. Backend Master가 보고와 PR #352를 검토하고 승인·최신 main 반영을 처리
PR #352 병합 준비 완료 main e8f2821b에 병합. 이 행은 tenant DB 기반만 해당. #355 인증·#367 API·#357 UI는 미완료
네 제품 PostgreSQL/API/UI/Yorkie 동일 후보 인수와 SaaS·내부 설치 실행 미완료 공식 후보 commit·이미지 digest·환경 식별자는 미확인. 후보 지정 뒤 QA Tester가 제품별 실제 두 계정·재시작·권한·복구를 별도 검증

이 범위의 DB QA 통과는 제품 본문 저장이나 전체 alpha 준비 완료를 뜻하지 않는다. 출시 제안은 외부 alpha 보류를 유지한다. 사용자에게 필요한 배치·운영 결정은 아래 Yorkie 선택 및 담당 확인과 같다.

Note 로컬 복구 목록 재시도 — 별도 결함 #364

QA Tester가 별도 git archive 42e9a88a6cd8d3ffc002d14cd29ef6905a3769c1의 Note UI에서 합성 IndexedDB UnknownError를 주입했다. 원격 main 94a9496826d0ea5b1cd06714ff4da45aef7ec8af의 관련 workspace.tsx blob은 같지만, 최신 main 전체를 실행한 결과는 아니다. 복구 초안 목록 첫 읽기는 실패했고, 장애를 해제해도 화면의 다시 시도는 목록을 재조회하지 않았다. 오류가 사라지고 저장됨으로 표시됐지만 초안 행은 0개였다. 정상 새 탭에는 초안 1개가 보였고 원본·초안 삭제는 관찰되지 않았다. 재현·완료 기준은 #364에 기록했다.

범위 상태 남은 위험·다음 담당
제한된 Note 로컬 목록 실패→재시도 재현과 중복 구분 준비 완료 QA의 합성 장애·실제 UI 관찰에 한정. #314/PR #359의 Office 휴지통 열기와 #357의 서버 저장·이전 UI와는 다른 경로
PR #365 head f879a28462b8ecbe31f9c09412756669de08b7d0의 #364 로컬 복구 목록 수정·검사 준비 완료 Note Developer의 Note Chromium 6/6·preflight 보고, QA Tester의 같은 head 독립 Chromium 6/6(비동기 IndexedDB 실패 뒤 목록 읽기 1→2, 초안·원본 보존), 원격 CI 8개 성공을 대조했다. PM은 로컬 검사를 재실행하지 않았다. 이 개별 head의 합성 오류 범위에 한정한다.
#365 검토·병합과 #364의 공식 통합 후보 회귀 미완료 PR은 draft를 해제했으나 GitHub review가 없고 열려 있다. 정확한 통합 후보에서 Note→Word→Slides→Site 및 서버·Yorkie 경로를 재검증해야 한다. Note Developer·PR 검토 담당→후보 담당·QA Tester 순으로 인계한다. 기존 버그 수정 순서는 바꾸지 않는다.
실제 고객 발생률·서버/Yorkie 경로·공식 alpha 후보의 출시 차단 여부 미확인 정확한 후보와 제품 경로에서 QA가 재검증하고 PM이 #322의 복구 인수와 연결

출시 제안은 내부 alpha 준비 지속·외부 alpha 제공 보류로 유지한다. 이 결함은 기존 복구 인수에 속하며 새 기능이나 별도 출시 필수 조건을 추가하지 않는다. 사용자 결정 대기는 위 Yorkie 배치·제공 단계와 실제 운영 책임자 확인으로 유지한다.

Note 공유 브라우저 프로필과 로컬 자료 — #357 PM 정책 제안

원격 main 94a9496826d0ea5b1cd06714ff4da45aef7ec8af의 Note 원본·복구 초안은 브라우저 로컬 저장소에 있으며 계정별 보호가 없다. 이는 소스와 Security의 정적 검토다. 교차 계정 노출을 실행 재현한 결과나 운영 사고로 기록하지 않는다. #357의 PM 제안에 범위와 대안을 남겼다.

PM은 내부 alpha의 두 계정 인수를 별도 브라우저 프로필·합성 자료로 진행하고, 첫 외부 alpha에는 개인별 프로필만 지원하는 A안을 임시 권고한다. 같은 프로필에서 UI 목록만 숨기는 것을 자료 격리로 약속하지 않는다. 대안 B는 공유 프로필의 계정 전환을 지원하되 계정별 로컬 자료 보호·정리·복구가 같은 후보에서 검증된 뒤 제공하는 안이다. A는 고객 준비 부담과 동일 프로필 접근 위험이 남고, B는 구현·검증·자료 처리 정책이 더 필요하다. 두 계정의 동시편집·권한·재접속·복구라는 기존 네 제품 인수 조건은 어느 안에서도 줄지 않는다.

Security & Privacy의 후속 검토는 A를 임시 지원 범위 제안으로 사용할 수 있다고 보되, 별도 프로필 안내를 기술적 계정 격리 증거로 취급하지 않는다. 대외 문구 후보는 “공유 브라우저 프로필은 지원·검증되지 않으며, 서버 이전 뒤에도 로컬 사본이 남을 수 있습니다”다. 같은 OS 사용자와 수동으로 내려받은 백업의 접근·정리 위험도 남는다. 실제 고지·삭제 정책은 사용자와 지정된 전문 검토자가 확정해야 한다.

로컬 원본·복구 초안·미확정 전송 자료는 서버 생성 응답만으로 자동 삭제하지 않는다. 같은 계정의 서버 재조회와 본문·revision/hash·ID 매핑 확인 전에는 이전 완료로 표시하지 않는다. 계정 전환 시 다른 계정의 로컬 자료를 자동 표시·업로드하지 않는다. 이전 완료 뒤 남는 사본의 안내·보관·정리와 취소/되돌리기는 사용자·Security 결정 전 미확정이다. 준비 완료는 소스·설계 검토와 선택안 작성 범위다. #357 구현·계정별 보호·동일 후보 QA는 미완료, 실제 고객의 공유 기기 사용·노출 범위·외부 alpha 차단 여부는 미확인이다. 다음 담당은 Security·PM의 정책 검토 → 사용자 제공 범위 결정 → 기존 Backend/Note Developer #357 구현 → QA 검증 → PM의 #322 재평가다. 현재 외부 alpha 보류 제안은 유지한다.

Note 이전 중 pageId 충돌 — #357의 복구 범위

PM의 #357 판단 제안은 로컬 Note와 서버 문서의 pageId 충돌 때 자동 덮어쓰기·병합·전체 참조 재작성을 하지 않는 것이다. 먼저 응답 유실된 생성 요청의 receipt를 확인한다. 실제 충돌이면 로컬 원본을 보존하고, 사용자가 이전 중단 또는 사본으로 만들기를 선택하게 한다. 사본의 새 ID와 자기 참조만 바꾸고 다른 페이지의 참조가 자동 이전됐다고 말하지 않는다. 읽기 권한 없는 충돌 대상의 내용·제목·ID는 노출하지 않는다. 현 로컬 가져오기 코드와 Architecture 계약을 대조한 설계 제안은 준비 완료다. Backend API·Note UI·동일 후보 QA는 미완료, 실제 고객의 교차 페이지 연결 필요와 출시 차단 여부는 미확인이다. 다른 페이지의 참조까지 자동 복구해야 한다는 고객 근거가 생기면 후속 범위로 재검토한다. 새로운 출시 조건을 추가하지 않으며 외부 alpha 보류와 Yorkie·운영 책임의 사용자 결정 대기는 유지한다.

Note pageId 충돌의 비노출·링크 보존 상충 — PM 선택안

#357의 PM 선택안은 pageId가 추측 가능한 문자열을 허용한다는 소스와 Architecture·Security의 설계 검토를 대조했다. 생성자가 읽을 수 없는 문서의 ID가 이미 점유됐다면 제목·ID를 숨긴 409 PAGE_ID_CONFLICT도 점유 사실을 알릴 수 있다. 현재 서버 문서 API는 없으므로 설계 위험이며 확인된 취약점이나 새 출시 gate로 표시하지 않는다.

PM은 첫 alpha에서 가시성과 생성 권한이 일치한다고 Backend·Security가 입증한 공간에만 기존 pageId 보존을 제안한다. Security의 후속 권고는 일반 생성에 서버 발급 난수 ID를 쓰고 기존 ID 보존 이전은 namespace 조회 권한이 확인된 별도 절차로 제한하는 것이다. 이를 입증하지 못한 부분 가시성 공간은 이전을 멈추거나 서버의 새 ID로 명시적 사본을 만드는 안을 검토한다. 새 ID 사본은 원본 ID를 쓰는 다른 페이지 참조를 자동 보존하지 않으므로 사용자에게 제한을 알려야 한다. 단순히 충돌 대상의 제목·ID를 숨기는 일만으로 존재 비노출이 성립한다고 주장하지 않는다. 같은 key/receipt로 불확실한 생성을 먼저 확인하고 로컬 원본은 유지한다. Backend·Architecture·Security가 namespace·응답 계약을, Note Developer가 확정 계약 뒤 UI를, QA가 두 계정·두 tenant의 점유/미점유 응답과 참조·receipt를 검증한다.

준비 완료: 소스·설계 상충과 선택안 작성. 미완료: Backend 계약·Note 구현·동일 후보 QA. 미확인: 고객의 기존 링크 의존, 부분 가시성 공간 사용, 실제 충돌 빈도와 출시 영향. 지원 범위와 고객 가치의 최종 선택은 PM이 증거를 받아 제안하며, 외부 alpha 제공과 사업 출시는 사용자 결정이다. 현재 네 제품 인수 미완료와 외부 alpha 보류를 유지한다.

후속 PM 진행 기준 — 2026-09-23 UTC: Backend의 #357 계약 검토와 Security 보완을 근거로, 첫 alpha의 일반 생성·부분 가시성 공간은 C(원래 ID 점유 여부와 관계없이 항상 서버 난수 pageId의 명시적 사본)를 계약 후보로 정했다. B(기존 ID 보존 이전)는 첫 alpha 지원 범위로 약속하지 않는다. 숨김·휴지통·복구를 포함한 namespace 전체 점유 가시성과 생성 권한이 검증되고 실제 고객이 교차 페이지 링크 보존을 필요로 할 때 재검토한다. 사본의 자기 참조만 옮기며 다른 페이지의 옛 링크 제한은 고지한다. 결정자는 Product Master PM이다. 후속은 Backend·Architecture·Security의 계약 검증 → Note Developer #357 UI → QA의 동일 후보 점유/미점유·두 계정·두 tenant 검증 → PM의 #322 재평가다. 고객의 링크 의존·지원 비용과 최종 외부 제공 범위는 미확인이며 실제 출시 결정은 사용자에게 있다. API·Note UI·QA 미완료, 외부 alpha 보류는 유지한다.

제품별 개발 Work의 단일 담당 인계 — 2026-09-23

사용자가 Note·Word·Slides·Site 제품별 개발 Work를 추가했다. 각 Work가 main 94a9496826d0ea5b1cd06714ff4da45aef7ec8af에서 기존 이슈·PR과 파일 경계를 읽고 인계했다. 이는 역할 배분이며 네 제품 alpha 범위나 출시일 변경이 아니다. GitHub PR은 모두 easylogic 계정으로 게시되므로 계정만으로 역할 담당을 판별하지 않는다. 이미 진행한 PR은 그 PR의 기존 작업 담당 한 곳이 마무리하며 새 Work가 같은 파일을 다시 구현하지 않는다.

제품/공통 기존 진행 작업의 단일 주 담당 새 Work가 맡을 후속 범위·선행 상태
Note #279/PR #305 기존 담당, #343 기존 Developer, #281 공통 선택 계약은 기존 Developer. #357은 구현 착수·PR이 없어 Note Developer로 인계 Note Developer가 apps/note·office-note의 제품 저장/복구 UI·codec·제품 검사. #351/PR #352 DB, #355 인증, Backend 문서 API와 Architecture DTO/세션 계약이 먼저 필요. Yorkie 제품 adapter는 공통 계약 뒤 별도 기존 이슈 대조 #357 및 네 제품 통합 미완료
Word #300/PR #334와 #318/PR #320은 각 기존 PR 담당이 완료. #303 통합 사용자 여정은 QA Tester Word Developer는 선행 계약 이후 Word 전용 UI·codec·DOCX/재열기·Yorkie 제품 경로를 맡음. 제품 연결 #371의 파일 소유와 착수는 계약 확정 뒤 확인 서버·협업 통합 미완료
Slides #298/PR #310, #301/PR #347, #302/PR #342는 각 기존 PR 담당. #314/PR #359는 Design Engineer, #321/PR #324는 문서 담당 Slides Developer는 #372를 기존 PR 통합·계약 확정 뒤 맡아 덱 UI·codec·저장/재열기와 Yorkie 제품 경로. PR #347과 #342의 slide-features.spec.ts 충돌과 #359의 #347 선행을 먼저 처리. #303 독립 검증은 QA 서버·협업 통합 미완료
Site #299/PR #316, #325/PR #339, #331/PR #340, #332/PR #345는 각 기존 PR 담당. #343 공통 명령은 기존 Developer, #327/PR #335는 문서 담당 Site Developer는 #373을 선행 PR 통합·계약 확정 뒤 맡아 Site UI·codec·행/페이지/중첩 Note·정적 출력의 제품 경로. 실제 게시·방문자 자료는 별도 범위·권한 결정 전 착수하지 않음 서버·협업 통합 미완료
공통 자료함·문서 교체 #319/PR #323 및 #314/PR #359는 기존 담당. #361의 단일 구현 주 담당은 기존 Developer Architecture가 원자성·쓰기 차단 계약을 검토하고, 기존 Developer가 공통 DocumentSession/Editor.loadDocument를 소유. 제품 Work는 공통 수정 이후 각 adapter/UI 경로를 검증. #359와 공유 파일의 기준·소유를 합의한 후 #361을 수정 #361 합성 위험 확인, 구현·독립 QA 미완료; 실제 발생·출시 차단 미확인

제품별 서버·Yorkie 연결 소유 — 2026-09-23 대조

최신 원격 main 41df1b8618d395d998de4402dee67760fdd564fa와 #322의 네 제품 범위를 대조했다. Word·Slides·Site의 현행 DocumentSession은 브라우저 IndexedDB snapshot을 사용한다. 각 제품 담당의 코드 조사에서도 실제 인증 문서 서버 저장·Yorkie adapter는 확인되지 않았다. #357·#368은 Note 전용이며 #303은 검사, #322는 추적이다. 따라서 Word #371, Slides #372, Site #373을 제품별 독립 구현 단위로 분리했다. 이슈 등록은 계약 확정이나 개발 착수가 아니다. 공통 Backend #367 문서/저장 mode와 #366 Yorkie 권한, Office #369 진입, Note 첫 통합 계약을 선행으로 둔다. Backend·Architecture의 DTO·초기화 제안은 확정 계약이 아니므로 구현 착수·완료로 세지 않는다. Word → Slides → Site 순서와 각 제품 두 계정·재접속·회수·구조/사용자별 undo·서버 저장 확인을 #322에서 따로 판정한다. 현재 세 제품은 미완료다.

#355 PR #370의 이전 head 7397dd685cb96e22c2365d00a02df7fedec4e1e2는 2026-09-23 08:29 UTC에 실행 CI가 성공했다. 새 head 0ed6ea407790ef1a71ed8810ba77b4eefabad1f3의 일부 검사는 08:37 UTC에 진행 중이었다. PR은 draft이며 최신 head의 CI 완료·독립 QA/Security/최종 인수는 미완료다. 과거 7bd3531 실패와 7397dd6 성공을 최신 결과로 옮기지 않는다. 로컬 Yorkie의 합성 수렴·재접속·재시작 보존은 Operator 내부 보고의 구성 요소 증거로만 기록하며 제품 권한·Cloud·네 제품 인수와 합치지 않는다. 외부 alpha는 보류한다.

공통 편집 엔진·공통 UI·제품 간 연결은 기존 Developer, PostgreSQL·Fastify·OIDC·Yorkie 서버 측은 Backend Master, 저장/협업 계약은 Architecture, 독립 통합 검증은 QA Tester가 계속 맡는다. PR #360은 계약 문서이고 PR #358은 인수 문서이며 제품 실행 증거가 아니다. Word #371·Slides #372·Site #373은 기존 이슈 중복 대조 뒤 최소 제품 단위로 등록했다. Backend/Architecture/Note 선행 계약이 확정되기 전에는 각 제품 구현을 자동 착수하지 않는다.

#355 인증 후보의 최신 범위 판정 — 2026-09-23 08:55 UTC

대상은 main 41df1b8618d395d998de4402dee67760fdd564fa 위 #355/PR #370 head 7a8e6ed2a123816f651b36c002c3ca7e7a93f1fe다. 08:55 UTC 조회에서 실행된 GitHub CI는 PostgreSQL 격리·복원, API 컨테이너, lint·타입·단위, Note와 editor-react E2E, npm 소비자 모두 성공했다. 문서 deploy는 skip이다. CI 상태는 이 head에서 준비 완료이며 PR은 여전히 draft, 리뷰 승인 없음, #355는 열려 있다. 위 07:33 실패·08:37 진행 중 기록은 각 과거 head의 시점 기록이다.

Mento의 output/mentor/wonffice-355-mentor-evidence.md에 따르면 독립 로컬 QA는 dd28e6526ddbf7454400599b507c5dc04f086fe1 코드 후보에서 두 실제 Keycloak PKCE 계정의 독립 브라우저 세션, tenant 격리, Bob의 admin 부여 뒤 같은 token 200→회수 뒤 403 및 /v1/me 목록 제거를 확인했다. PM의 커밋 비교에서 dd28e652→현재 head의 변경은 로컬 Office Keycloak callback·origin·logout redirect 등록 스크립트와 실행 문서뿐이며 인증/membership 런타임 코드는 같다. 이전 코드의 독립 인증 경계 증거는 확인됐지만, 새 스크립트와 #369 Office UI를 포함한 현재 head의 독립 재실행·Security 최종 리뷰는 미완료/미확인이다. 별도 Operator 로컬 시험은 #369 작업본 5186의 /api/me 무인증 401과 원 preview 복원을 확인했으며, 두 계정 UI 로그인은 Developer 보고다. 작업본이므로 공식 통합 후보 인수로 세지 않는다.

출시 제안: 내부 alpha 통합 준비를 계속하고 외부 alpha 제공은 보류한다. #355 단위의 CI 통과를 #367 문서 API·#366 Yorkie 권한·#369 직접 문서 URL 보호·Note/Word/Slides/Site 동일 후보 검증으로 확대하지 않는다. ready 503과 공식 통합 후보·SaaS/내부 설치 환경 미지정이 남는다. Backend는 #370의 최종 head와 새 로컬 설정을 QA·Security에 인계하고, QA·Security는 그 불변 후보의 로그인·회수·owner/tenant 경계를 확인한다. Developer는 #369의 실제 비관리자 거부와 직접 URL·계정 전환을 #367 선행 뒤 인수한다. Operator는 리뷰·필수 검사·보호 정책 충족 때만 병합을 판단한다. PM은 #322에 결과를 모은다. 관리자 유형·첫 업무 및 계약·결제·개인정보·지원 담당과 운영 환경은 사용자 결정/담당 확인이 필요하다. SaaS·내부 설치 동시 출시 결정은 유지한다.

Yorkie 배치 선택 제안 — 고객사 내부 설치의 독립 동작

2026-09-23 확인한 Yorkie 공식 자체 설치 문서는 기본 서버가 메모리에 저장해 재시작 내구성이 없고, 영속 저장에 MongoDB 연결을 사용한다고 설명한다. Yorkie 제품 문서는 Cloud와 자체 설치를 별도 배치 형태로 제시한다. 최신 플랫폼 설계 b59a8443는 내부 설치의 기본 편집·저장 요구와 Yorkie 실행 형태를 함께 검증하도록 정했다. 내부 설치 Yorkie 구성은 아직 미검증이다. 공급자 문서 확인과 역할별 검토는 실행·복원·비용 검증이 아니다. Architecture PR #360은 2026-09-23 main에 병합된 계약 문서이고, 출시 문서 PR #358은 아직 열려 있다. 문서 병합은 제품 인수 근거가 아니다.

선택안 기존 결정과의 관계 검증·운영 부담
A. SaaS 외부 alpha는 Yorkie Cloud, 고객사 내부 설치는 Yorkie 자체 설치+MongoDB — PM 권고안, 미결정 Cloud alpha 결정과 내부 설치의 독립 동작을 각각 충족할 수 있는 구성. 같은 제품 adapter의 환경 설정을 바꾸는 안이며 자체 협업 서버를 개발하는 뜻이 아님 로컬 자체 설치의 재시작·백업·복원, 내부 설치의 권한·장애·업데이트·지원 비용, Cloud 환경의 별도 동작을 모두 실행 검증해야 함
B. 고객사 내부 설치도 Yorkie Cloud 연결 협업 원문이 외부 공급자로 전송되고 네트워크에 의존하는 하이브리드 설치. 기존 독립 동작 요구를 바꾸는 별도 사용자 결정 필요 고객 계약·자료 지역·보관/삭제·네트워크 차단 때 동작과 비용 확인 필요
C. Cloud alpha만 먼저 제공하고 고객사 내부 설치 제공을 뒤로 미룸 첫 외부 alpha의 범위를 좁힐 수 있으나 기존 SaaS·내부 설치 동시 출시 결정의 단계 적용을 분명히 해야 함 실제 내부 설치 인수 전 대외 약속 금지. 날짜와 제공 범위 변경은 사용자 결정 필요

제안: A를 다음 구현·검증의 기준 후보로 삼되 확정하지 않는다. 먼저 로컬 Yorkie 자체 설치+MongoDB에서 Note 저장·재시작·두 계정 수렴을 검증하고, 같은 후보의 Yorkie Cloud 경로를 별도로 확인한다. 이후 Word→Slides→Site 및 고객사 내부 설치의 복원·외부망 차단 검사를 연결한다. 현재 로컬 Yorkie 경로·Cloud 공급자 데이터 처리 조건·고객사 설치 제공 단계와 비용·사람 운영 책임은 미확인, 네 제품 통합 인수는 미완료다. 월 약 5만 원 목표의 충족은 공급자 한도·사용량·저장·백업·지원 시간 근거가 없어 판단하지 않는다. Cloud에 연결한 로컬 시험은 오프라인 검증으로 기록하지 않는다.

사용자 결정 필요: 첫 외부 alpha에 고객사 내부 설치 제공까지 포함하는지, 포함한다면 A의 자체 설치 Yorkie+MongoDB를 기준으로 삼을지 또는 B의 외부 Cloud 의존을 예외로 허용할지. 어느 안도 현재 배포 승인은 아니다. 내부 설치의 공급자·고객 자료 처리 조건은 개인정보 전문 검토 담당도 미정이다.

1. 출시 제안

현재 제안은 내부 alpha 준비를 계속하고, alpha 인수 완료 선언과 외부 고객 출시는 보류하는 것이다. 기존 WP-02·05·06의 핵심 실행 근거가 남아 있다. 기능 아이디어가 부족해서 보류하는 것이 아니다.

단계 대상·목적 포함 범위 제외·후속 상태
첫 alpha의 내부 기술 인수 — 현재 관리 대상 내부 개발·QA·운영 검증자. 핵심 저장·실행 계약과 두 환경 설치 검증 #322의 기준점·transaction 복구, WP-02 핵심 계약, 같은 이미지의 두 환경 설치·로그인, 네 제품의 실제 DB/API/UI·Yorkie 저장·공동편집·재접속·권한·복구 외부 고객 서비스 약속, 유료 판매, 새 PMF 기능, 독립 상주 Agent, 모바일 검사 미완료
첫 alpha의 소수 사용자 외부 제공 — 가까운 사업 목표 기존 오피스 사용자. 세부 고객군·첫 핵심 업무는 미확정 Note·Word·Slides·Site의 로컬 통합 인수 뒤 실제 제공할 범위·미지원 항목·후보 빌드와 운영 조건을 명시. #322의 기존 기술 인수와 구분해 확인 새 제품·자동 연결·기존 beta/RC 기능을 첫 alpha의 새 필수 조건으로 추가하지 않음 미완료
이후 beta — 기존 후속 정책 외부 고객의 실제 업무 효용과 운영 조건 검증. 첫 alpha 외부 제공을 beta로 자동 전환하지 않음 alpha 인수 이후 실제 고객 업무 효용, 격리·복구·지원 범위. 두 배포 형태 전체 Office 호환·새 제품군·확인되지 않은 연동 약속 미완료
RC·정식 출시 범위가 고정된 서비스를 운영 가능한 상태로 제공 기존 정책의 공동 편집·권한 회수·업데이트·실패 복구·두 환경 인수·관측과 사용자 출시 결정 미승인 신규 기능 미완료

정책 근거: 출시 단계, 제품 범위. 과거 문서의 구현 상태보다 최신 병합·검사 기록을 우선한다. SaaS와 내부 설치의 동시 출시 결정을 유지한다. 1.0.0-alpha.1 등 정책의 버전 예시는 실제 출시 버전이 아니다.

지금 출시를 선언하면 서버 저장·권한·복구와 지원 책임을 입증하지 못한 채 사용자에게 준비 상태를 잘못 전달할 위험이 있다. 보류하면 고객 검증 시점이 늦어지고 개발·운영 비용이 계속 든다. 이를 줄이기 위해 승인된 기술 작업과 고객 과제 설계를 진행하고, 새 기능을 필수로 늘리지 않는다. 출시 날짜는 증거가 없는 상태에서 만들지 않는다.

2. 준비 상태

역할별 취합

아래는 역할의 보고와 연결 이슈를 취합한 결과다. PM이 각 검사를 재실행했다는 뜻이 아니다. ‘다음 담당’은 역할 간 인계이며 실제 운영 권한·당번 지정과 구분한다.

역할·대상 상태 확인 결과·근거 남은 위험 다음 담당
Operator — Note 수정 main 통합 준비 완료 #283 병합 commit 0d97e1f00948aafd27bd6bdf4ac2b9a2f9f51e60. main CI 8개 job 및 문서 배포 성공을 PM도 GitHub에서 확인 이 commit은 공식 출시 후보가 아님. 서버 인수로 확대하지 않음 Operator가 후속 PR 통합 확인
Operator — 후보·운영 증거 미완료 #322 증거 묶음 인계 기준 수락. 열린 PR 처리와 #329 안정성 작업 남음 후보 산출물·두 환경·운영 복원 근거 및 실제 사람 책임자/권한 미확인 Operator가 증거 묶음 준비 → PM 범위 확인 → QA
Architecture — #271 정책 편집 구현 검증 준비 완료 PR #344 head ffac84163b332281e2af3721b352d0eede19942f. 로컬 단위 8,715/기존 skip17·React/DOM44·Note16 통과 보고. PM은 해당 head CI 성공 확인 PR 미병합. WP-02 전체 인수와 제품 전체 출시는 별도 미완료 기존 검토/병합 역할 → QA, Architecture는 #350 계약 검토
Backend Master — API 실행 기반 검증 준비 완료 PR #333 최신 head e92fb3b3ee911aabda1348e1c1d8ece0cbcb06fd. 최신 main 반영 보고. PM도 해당 head CI·컨테이너·문서 빌드 성공 확인 PM 재조회 시 병합 commit 895f0cf20582ccfe5aa0d797121740befa825365 확인. main CI 8개·컨테이너·문서 배포 성공과 #330 종료를 PM 확인. 제품 배포·서버 저장/복원 인수 아님 Backend 저장 기반 → Operator 운영·QA 인수
Backend Master — 서버 전체 인수 미완료 인증·DB·tenant·문서 저장·데이터 이전·백업/실제 복원·선택형 협업 연결은 미완료. 자체 협업 서버 개발은 사용자 결정상 해당 없음 예상 사용량·용량·실제 외부 운영 조건 미확인. ready 503이며 고객 트래픽 준비가 아님 Backend Master 구현 → QA 검증 → Operator 운영 인계
QA Tester — 통합 alpha 인수 미완료 #322 QA 인계. 개별 head 사전 검사와 통합 후보 검사를 분리 공식 후보·digest·환경 미확인. 제품 전체 통합 검사 미완료 Operator 후보 묶음 → PM 범위 고정 → QA
Developer — 기존 결함 수정 미완료 #301/PR #347 게시 및 브라우저 14개·preflight 통과 보고. CI 완료 확인 후 다음 구현 #343 인계 수락 #343 수정·검증 미완료. PR340/345는 미병합이며 호스트 수정 복제 금지. 정확한 통합 head 검증 필요 Developer → 검토/병합 역할 → QA
Design Engineer — #331 새 head 로컬 검증 준비 완료 PR #340, 새 head e8072a09f6b9e693d51ef1620dde8665098f71ac. main 0d97e1f00948aafd27bd6bdf4ac2b9a2f9f51e60 동기화 후 preflight·단위 1,184개·Chromium 8개 통과 보고 PM이 해당 새 head CI 성공 확인. OPEN이며 독립 QA·최신 백엔드 main과의 통합 결과 미확인. 이전 head의 CI 성공을 전용하지 않음 Developer #343 통합 → QA 정확한 head 검증
Design Engineer — #332 구현·로컬 검증 준비 완료 PR #345, head 262b286e68aabab22641154b6cf79fe2b5204cfe, 기준 main 0d97e1f00948aafd27bd6bdf4ac2b9a2f9f51e60. preflight·단위 997개·Chromium 4개 통과 보고. 별도 문서 재열기까지 내용·주소 보존 확인 보고 PM은 로컬 검사를 재실행하지 않음. OS IME·다른 브라우저·스크린리더 미검증, 모바일은 현재 범위 제외 코드 검토·QA
Design Engineer — #332 CI·통합 미완료 PM이 PR #345 해당 head의 CI 성공 확인. PR OPEN·미병합이며 통합 인수는 미완료 PR #339와 같은 호스트 파일 변경. 함께 반영한 commit에서 두 동작의 입력·저장·재열기 재검증 필요. 특정 검토자 미지정 기존 검토/병합 역할 → QA
Technical Writer — #341 문서·로컬 검증 준비 완료 PR #346, head fabdc7b628dea078eb4355009853641b241aac14. preflight·집중 검사 132개(기존 skip 10)·packed 예제 36개/31패키지·사이트 빌드·브라우저 예제와 링크 검증 보고 소스 문서 기준이며 새 npm/제품 배포 아님. PM은 해당 로컬 검사를 재실행하지 않음 Technical Writer → 코드 검토
Technical Writer — 문서 통합·게시 미완료 PM이 #346 해당 head CI 성공 확인. OPEN·미병합. #348/PR #349 head 5b78a17ca5d526230a17ab3ffd91af0fbe8e2b3b의 협업 문서 로컬 검증 보고 추가. #349 CI 최종 결과 미확인 후보 버전 정합성·실제 게시·서비스 설치 가이드 실행 미확인 Technical Writer·기존 검토/병합 역할 → Operator/QA
UI/UX Researcher — 실제 사용자 업무 검증 미완료 사용자 검증 인계. 실제 대상 사용자 관찰 0건. 기존 연구자 합성 관찰 기준 42e9a88a6cd8d3ffc002d14cd29ef6905a3769c1, 범위 조회 main 0d97e1f00948aafd27bd6bdf4ac2b9a2f9f51e60 사용자 빈도·공식 후보 검증으로 확대하지 않음. 대상 고객·핵심 업무·모집 담당 미확인 PM이 고객/과제/담당·후보 인계 → UX 관찰 설계·실행 기록
Product Designer — 전략 위험 미완료 개별 전략 점검은 완료 보고. #289/#296의 고객·구매자·비용 증거 부족 전략 점검 완료를 수요 검증으로 오인할 수 있음 Product Designer·PMF → PM
Product Market Fit — MR-06/07 공개 근거 인계 준비 완료 MR-06·MR-07, 인계 계약. 후보·도입 위험·지표 제안과 MR-07의 UX 설계 검토를 PMF 기능 지도에 반영 외부 계정 실행과 실제 고객 성과 아님. 교육 우선 가설 유지. 전문 매체와 다중 전달처 미디어 제작팀은 조건부 후보 PM이 #289 고객/업무/접근 경로 확인
Product Market Fit — 사용·구매·유지 검증 미완료 인터뷰·업무 관찰·유료 실험 0건. 실제 사용/지불 의사·고객 일정은 미확인 고객 업무 총시간 비교와 실제 외부 편집 환경 미검증. 자료·계약·결제·지원·운영 책임 미확인 고객 접근 범위 확정 후 UX·PMF, 실제 자료 담당은 사용자 확인
Go-to-Market / Growth — 모집·도입 준비 미완료 main 895f0cf2 기준 소개·모집/측정 초안은 준비 완료라는 역할 보고. 실제 모집·체험 미실행. 기존 #289·PMF 근거 재사용 고객 검증된 가치·접근/동의 기록·체험 URL·예산·외부 접촉 권한 미확인 PM 준비 범위 → Growth·UX·Support, 실제 사람/권한은 사용자 확인
Customer Success / Support — 도입·지원 미완료 첫 사용·저장/재열기·백업 안내와 접수/분류/인계/고객 해결 확인 초안 준비 완료 보고 일반 고객 안내 통합·실제 고객 적용 미완료. 비공개 채널·사람/대체 담당·응답 정책 미확인. 무응답을 해결로 세지 않음 Support 접수 절차·Writer 도움말 → UX/QA → PM
Security & Privacy — 데이터 준비 미완료 main 895f0cf2의 로컬 저장·백업·삭제 경계와 API 실행 기반을 소스/문서로 검토한 보고는 준비 완료. 실제 공격성 검사·침해 재현 없음 고객 자료 서버 저장·인증·보관/삭제·통합 복원 미완료. 전문 검토자·외부 공급자 조건 미확인 Backend #351 등 구현 근거 → QA/Security, 운영 조건은 Operator
Mento — 역할 책임 지침 준비 완료 역할 분담과 공통 규칙 작성 보고. 특정 제품 버전 검사는 해당 없음 실제 담당 지정과 각 역할 적용 여부는 별도 PM이 담당·보고 기준 유지
Product Master PM — 출시 판단 미완료 이 제안, 기존 #322 연결, 11개 관련 역할에 공통 규칙 전달. 5분 반복 작업 갱신 후보·외부 조건·책임자 미확인 PM이 새 근거 취합 → 사용자 출시 결정

Operator 추가 보고: Node 22.22.0 사전 검사, 관련 단위 721개, 데스크톱 Note 시나리오 16개 통과 및 #282·#278·#280 종료를 보고했다. 로컬 검사는 Operator 보고이며 PM이 재실행하지 않았다. PM이 직접 확인한 것은 위 main의 병합 상태와 두 GitHub 실행의 성공 상태다. 제품 alpha 전체 상태는 미완료를 유지한다.

추가 결함·계약 검토 인계

항목 상태 근거·범위 다음 담당
슬래시 표 명령의 /표 잔존 #343 미완료 QA 보고. PR340 head 5baae2757a9b874b81ce22d7b2f37e8c47fa78a3의 관측. #331 포인터와 #332 포커스는 다른 문제. 공식 후보 차단 판정은 미확인 Developer 로컬 통합 head faea10685665c0bbe99587d4f6d052873ead90f0(parent PR340 e8072a09)의 브라우저15·Note단위351·preflight·독립 코드검토 통과 보고. QA에 직접 인계. #340 미병합으로 main 대상 PR 대기. main+#343 단독 Site 포인터는 기존 #331로 실패하므로 통합 통과와 구분
undo/redo 재생 실패 시 history index 복구 미완료 Architecture의 네 실패 주입 사례에서 문서·선택은 복구되나 index가 남고 후속 redo가 Ax→Axx로 중복되는 메모리 재현 보고. PM은 최신 main wrapper를 읽음. 독립 #350, P1 제안 Developer #350 수락. #343을 독립 검증·선행 반영 대기로 보존하고 다음 우선 수정. Architecture에 #344 코어 소유권·실패 fixture 직접 확인 → QA 독립 검증
기존 YjsAdapter의 실제 Yjs update 미확인 #348 재현 보고: 로컬 packed consumer/yjs13.6.32의 plain-node update 예외 및 nested-map 미반영. 문서화가 runtime 해결은 아님 Backend Master에 영향·배포본 구분·중복·최소 수정 범위 검토 요청. 공급자 선택이나 새 서버 구현 승인 아님

위 인계는 새 alpha 필수 조건 추가가 아니다. #343은 기존 이슈를 재사용한다. undo/redo는 #249 transaction 내부 복구와 외부 wrapper 이력 위치가 다른 범위임을 확인해 #350으로 분리했다. 실제 파일/서버 손실·자연 발생 빈도·공식 후보 차단 여부는 미확인이다. Developer는 #343 로컬 통합 검증을 보고했고 #350을 다음 우선 수정으로 수락했다. #343의 정식 PR은 #340 선행 반영을 기다린다. Architecture의 분석은 완료됐으며 재현 자료 연결을 요청했다.

#343 독립 QA 갱신 — 2026-09-20

준비 완료: 로컬 faea10685665c0bbe99587d4f6d052873ead90f0(부모 PR340 e8072a09)의 독립 QA. PM이 QA 근거를 확인했다. 별도 archive 추적 파일 3,018개 일치, Node22.22.0·macOS·Chromium에서 Note10/Site5 브라우저와 Note351 단위 검사가 통과했다. 브라우저 실패·skip·retry 0이다. PM이 검사를 재실행한 것은 아니다.

표 검색어 제거·즉시 입력·단계별 undo/redo·저장·같은 URL 재열기의 해당 경로를 확인한 결과다. 전체 서식/모든 행 보존·UI 저장 실패·OS IME·여러 inline run 검색어는 미확인이다. 미완료: 선행 PR340 반영과 #343 최종 main PR, #339/#340/#345/#343 통합본 b6dcf013fb4821c913c6f7d345cb2210248713d0의 독립 QA. Design Engineer의 통합본 로컬 검사 보고를 이번 독립 QA와 합산하지 않는다. 다음 담당은 Developer 최종 PR/head → QA 확인이다. #343은 OPEN이며 공식 후보의 출시 준비 판정은 별도다.

담당 공백과 외부 조건

2026-09-20 사용자 확인: 담당자와 비공개 문의 창구는 미정이다. 초기에는 사용자 1인이 운영할 가능성을 준비 가정으로 둔다. 계약·결제·개인정보 전문 검토·고객 지원과 대체 담당·운영/장애 대응의 개별 책임과 권한은 아직 확정되지 않았다. 사용자 1인을 모든 항목의 책임자 또는 전문 검토자로 자동 지정하지 않는다. 준비 상태는 미확인을 유지하고, 지정 상태는 미정으로 기록한다.

Support는 최소 접수·분류·응답 가능 시간·부재 시 대응안을, Operator는 경보·장애 판단·복원·부재 시 대응안을, Security & Privacy는 최소 자료 취급안과 전문 검토가 남는 항목을 기존 보고서에서 준비한다. 24시간 대응이나 대체 인력을 가정하지 않는다. PM은 운영 부담과 범위를 모아 선택 가능한 안을 제안한다. 외부 접촉·유료 제공·운영 실행 승인은 별도다.

항목 상태 필요한 확인 적용 시점·다음 담당
계약·이용 조건·고객 약속 미확인 검토 책임자, 제공 범위와 약속을 검토한 근거 외부 고객 제공 전 PM → 사용자 지정 담당
결제·청구·환불 미확인 유료 제공 여부, 사업 책임자, 처리 절차 유료 제공을 선택할 때. 내부 alpha에 결제 개발을 새 필수로 넣지 않음
개인정보·데이터 취급 미확인 Security & Privacy와 연결할 전문 검토 책임자. 처리 목적/역할·허용 자료·보관/삭제·백업 복원·공급자 조건·사고/요청 접수의 범위와 책임 실제 데이터 사용 범위 확정 전 PM → 사용자 지정 담당
고객 지원 미확인 비공개 문의 채널, 실제 응대/대체 담당, 운영시간·응답 목표·긴급 인계와 자료 수집/접근/보관/삭제 외부 고객 제공 전 PM → 사용자 지정 담당
인프라 접근·장애 대응 미확인 Operator 역할과 별도로 실제 환경·접근 권한·연락 경로·복원 실행 책임·장애 대응 권한 두 환경 검증·운영 인계 시 Operator → 사용자 확인
운영 비용·모니터링 미확인 운영 예산·실제 비용, 관측 절차와 경보 수신자. Operator 역할만으로 실제 담당 지정이 된 것은 아님 Operator가 환경/비용/관측 근거 → PM이 사용자 결정 항목 취합
사용량·용량·외부 운영 조건 미확인 예상 동시 사용자·문서 크기·업로드량, 운영 OIDC/S3/협업 공급자 조건. 측정 없이 서버 규모나 SLA를 확정하지 않음 PM 사용량 가정 → Backend Master·Operator 측정/조건 확인
고객 관찰 모집·진행 미확인 외부 접촉 권한, 모집·진행 책임자, 대상과 데이터 범위 #289 외부 실행 전 PM → 사용자 지정 담당

Growth·Customer Success / Support·Security & Privacy의 작업 역할은 확인했다. 이 역할 배정은 계약 당사자·실제 지원 사람·전문 법률/개인정보 검토자·운영 권한의 지정 증거가 아니다. 세 역할의 상세 초안은 각 작업의 로컬 보고서에 보존돼 있으며 이 위키에는 준비 상태와 인계만 요약했다. 비공개 고객 원문이나 보안 검토의 상세 가설은 전재하지 않는다.

이 표는 법률 적합성 판단이 아니라 준비 책임의 확인 목록이다. 확인 전 외부 조건을 준비 완료로 표시하지 않는다. 적용이 없다는 근거가 확인된 경우만 해당 없음으로 바꾼다.

1인 운영 준비안 — Security & Privacy 인계

2026-09-20 보고, 코드 기준 895f0cf2. 상태는 초안 작성 준비 완료 / 실제 적용 미완료다. PM은 해당 역할의 기존 보고서를 확인했다. 운영 설정·고객 접촉·실제 자료 처리는 실행하지 않았다.

  • 비공개 문의 창구 하나와 접수대장 하나를 준비하는 안이다. 기본 접수는 회신 수단, 제품·버전, 발생 시각, 기대·실제 결과와 영향으로 제한한다. 원문·전체 백업·인증정보를 기본 수집하지 않는다.
  • 합성 재현으로 부족할 때만 목적·최소 자료 범위·열람자·보관 위치·삭제 예정일을 정해 받는 안이다. 지원 자료 열람과 고객 본문 접근 권한을 구분한다.
  • 지원 첨부의 해결 확인 후 7일 내 삭제, 원문 없는 접수대장의 종료 후 30일 삭제 필요성 검토는 역할이 제안한 미승인 기간이다. PM이 운영 정책으로 채택하지 않았다. 전문 검토 대상으로 보존하며 법정 기간이나 서비스 문서·감사 기록·백업 보관 정책으로 사용하지 않는다.
  • 요청자와 대상 권한을 확인하고 원본·독립 사본·참조·공유·초안·백업별 처리 범위를 기록하는 안이다. 실제 권한·삭제·복원 후 삭제 재적용은 미구현 또는 미검증이며 휴지통 이동은 삭제 완료 근거가 아니다.

남은 위험은 실제 담당·창구·부재 처리 미정, 전문 검토 미완료, 운영 권한과 자료 처리 검증 부족이다. 다음 담당은 Support·Operator의 최소안 취합 → PM이 운영 부담과 선택안을 정리 → 사용자 담당/창구 결정 및 지정된 전문 검토다. 사용자의 추가 답변을 지금 반복 요청하지 않는다. 기존 alpha 조건은 늘리지 않는다.

1인 운영 준비안 — Customer Success / Support 인계

2026-09-20 최소 지원안 v0.3을 PM이 확인했다. 초안 작성은 준비 완료, 운영 개설·검증은 미완료이며 문의량과 실제 처리 능력은 미확인이다.

결정 항목 검토 중인 제안 남은 확인·다음 담당
비공개 창구 지원 전용 메일 주소/별칭 하나. 대안은 비공개 웹 폼 하나 보유 계정·주소·권한·비용·자료 취급 조건 미확인. 개인 Git 이메일을 지원 주소로 쓰지 않음. 사용자 결정 후 Support·Security 확인
확인 시간 평일 하루 한 번 30분을 접수 확인·분류·회신 준비에 배정 사용자의 실제 가용 시간 미확인. 진단·수정 시간 및 고객 응답/해결 기한은 별도. 미승인 제안이며 외부 약속 아님
부재 처리 가능한 경우 수신만 유지하고 확인·조치 보류. 창구 유지 불가 시 접수 중단 안내 대체 담당 미정. 예고 없는 부재의 즉시 공지·대응은 보장할 수 없음. 실제 채널 확인 후 Writer·Operator 구체화
장애 조치 Support의 진단 인계와 사람 권한자의 배포·복원·계정 조치를 구분 실제 권한자 미정 또는 부재이면 조치 대기로 기록. Operator 최소안과 함께 PM 취합

1인 부재 중 처리 공백과 문의량 초과가 남은 위험이다. PM은 Operator의 운영안까지 모아 하나의 선택안으로 제시한다. 이번 취합으로 계정·외부 공지·새 자동화·출시 조건을 만들지 않는다.

필수와 후속, 중복 정리

  • alpha 필수는 #322의 기존 조건과 위 최신 사용자 요구의 로컬 DB·실시간 공동편집 통합 검증이다. WP-02·05·06 및 WP-09 연결의 미완료를 우선 드러낸다. #330은 WP-05의 첫 실행 기반이며 전체를 대신하지 않는다.
  • 이슈와 연결 PR은 한 작업으로 센다. 예: #330/PR #333, #282/PR #283, #331/PR #340. 둘을 별도 기능이나 준비율 분모로 세지 않는다.
  • #303은 제품 사용자 시나리오 검사 묶음, #322는 출시 인수 추적이다. 서로 대체하거나 중복으로 닫지 않는다. 현재 조사에서 닫아도 되는 동일 범위 중복 이슈는 확인하지 못했다.
  • #289~297, #337의 제품·PMF 제안은 후속 또는 검증 후보다. 새 브랜드·변환·프로젝트·전달 기록을 alpha 필수로 자동 추가하지 않는다.
  • 기존 편집 결함은 해당 단계의 지원 흐름과 후보 재현 결과로 차단 여부를 정한다. P1/P2 라벨이나 열린 상태만으로 모두 alpha 필수 또는 모두 후속으로 분류하지 않는다.
  • 병합·배포는 기존 절차를 따른다. PM이 연구 결과를 이유로 개발자의 승인 범위를 확대하지 않는다.

3. 남은 위험과 재검토 기준

위험 현재 처리 다시 판단할 근거
저장·권한·복구 미완료 alpha 인수 완료와 외부 출시 제안 보류 #322의 해당 후보·두 환경 실행 증거
서로 다른 PR 검사 결과를 통합 완료로 오인 검사마다 head·환경·범위를 유지 불변 후보 commit·산출물·환경을 묶은 QA 결과
고객 가치와 운영 비용 미확인 PMF 연구를 가설로 유지 실제 업무 관찰·구매자 응답·지원/운영 측정
계약·결제·개인정보·지원 담당 미확인 사용자 결정 항목으로 노출 책임자 지정과 대상 범위별 검토 기록
공유 호스트 변경의 통합 회귀 #332와 PR #339의 같은 파일 변경을 연결. #314 진행은 PR #323 통합 상태 고려 해당 수정들이 반영된 commit에서 입력·포커스·저장·재열기 검사. 각 PR 단독 통과로 대체하지 않음
연구가 출시 범위를 계속 늘림 범위 변경 제안은 별도로 관리 PM의 영향 분석과 사용자의 범위 결정

후보 준비 순서: 기술 핵심 조건 준비 → Operator가 commit·포함 PR·산출물 digest·두 환경·실행/복원 기록 제출 → PM이 대상 범위와 미지원 범위를 고정 → QA 통합 인수 → PM이 출시/보류 영향 정리 → 사용자 결정 → 승인 범위에서 Operator 실행과 QA 확인. 아직 존재하지 않는 이미지·환경을 임의로 지정하지 않는다.

외부 고객 연구의 준비 범위

MR-10을 고객 조사 계획 v0.4에 연결했다. 첫 고객 과제는 접근 가능한 기존 오피스 사용자의 최근 문서 하나를 현재 방식과 같은 종료 조건으로 비교하는 제안이다. 원본 보존부터 실제 필요한 검토·수신 형식·복구까지 기록한다. 교육 자료와 운영 안내는 동순위 후보이며 실제 고객 접근 근거가 없으므로 시장을 확정하지 않는다. 연구 계획 준비 완료, 고객 실행·수요 검증 미완료. 네 제품의 Yorkie 기술 인수와는 별개다. 다음 담당은 PM의 고객·업무 선택 → UX·QA·Growth·Support·Operator의 기존 역할 검토이며 사람의 자료 취급·연락 책임은 미확인이다.

고객 조사 계획 v0.2는 교육 반복 제작팀을 준비 대상으로 통일했다. B2B는 비교 후보로 보존한다. 한 페이지 안내문·세 장 발표의 작성→일정/장소 변경→저장·재열기 과제 초안을 재사용한다. 실제 과제/빌드/접근 경로/고객 접촉·자료 처리 담당이 정해지기 전 외부 실행은 하지 않는다. 이는 내부 alpha 출시 대상이나 필수 조건을 바꾸는 결정이 아니다. 모집 인원·예산·무료/유료·일정·지원 약속은 아직 미확인이다.

4. 사용자 결정이 필요한 항목

  1. 담당자와 문의 창구는 미정이라는 사용자 답변을 반영했다. 우선 1인 운영에 맞는 최소안을 준비한다. 이후 사용자 본인이 맡을 항목, 외부 전문 검토가 필요한 항목, 비공개 문의 창구와 응답 가능 범위를 구체적인 안으로 결정한다. 내부 연락처나 계약 원문은 공개 Wiki에 기록하지 않는다.
  2. 운영의 실제 접근·장애 대응 책임자와 외부 고객 조사 담당, 운영 예산과 경보 수신자를 확인한다. AI 역할 배정만으로 사람의 책임·계정 권한이 생기지 않는다.
  3. 첫 alpha 외부 제공의 세부 고객군·핵심 업무·무료/유료 여부·사용 데이터·지원 범위를 결정한다. 현재는 교육 반복 제작팀을 준비 가설로 두며 확정 고객이 아니다. 외부 제공이라는 이유로 beta 단계 전환을 요구하지 않는다.
  4. 출시일과 최종 출시는 후보 증거를 갖춘 뒤 결정한다. 지금은 배포 승인을 요청하는 단계가 아니다.

출시 후 지표와 평가 시점 — 제안

T0는 사용자가 승인한 해당 단계의 실제 제공 시작 시점이다. 실제 T0는 아직 없다. 관찰 책임은 다음과 같이 제안하며 실제 담당 확인이 필요하다.

시점 지표·평가 책임·근거
내부 alpha 제공 직후 네 제품의 로컬 저장·공동편집 인수 및 두 환경 로그인·재열기·복원 핵심 결과 Operator 실행 증거 + QA. #322 기준
T0+24시간 실패한 저장/재열기 건수와 전체 시도 수, 데이터 유실·권한 문제, 복원 결과 Operator·QA. 분모/재시도/미수집을 명시. 미수집을 0으로 쓰지 않음
T0+7일 반복 오류·복구 시간·지원 투입 시간. 고객 beta라면 독립 업무 완료와 전체 소요 시간 Operator·지원 담당·QA·PM. #297의 기술 성공과 업무 완료 분리
고객 beta T0+14일 다른 실제 업무의 재사용, 이탈 이유, 구매자 반응, 고객별 지원·운영 비용 PM·PMF·지원 담당. #289/#296/#297 재사용

MR-06의 뉴스레터 후보는 채택 시 발행 주기별 유지 관찰을 제안한다. beta 14일 점검은 중간 관찰이며 월간 발행 고객의 4주기 유지 결과를 대신하지 않는다. 주기가 도래하지 않은 고객을 이탈로 세지 않는다. MR-07의 최소 2개 제작 주기 제안도 해당 고객 주기가 실제 도래한 뒤 판단한다. 서로 다른 후보의 주기를 합쳐 단일 유지율로 계산하지 않는다. 실제 수집·외부 고객 실행·결제는 아직 없고 새 개발 조건으로 추가하지 않는다.

데이터 유실·회사 간 자료 노출·설치/저장 불능·복구 실패는 기존 출시 정책에 따라 즉시 보류·대응 판단으로 연결한다. 임의 임계값이나 새로운 수집 기능을 확정하지 않는다. 예약 알림과 분석 플랫폼은 이번 역할 추가로 새로 만들지 않는다.

Design Engineer 정정: PR #345 head 262b286e68aabab22641154b6cf79fe2b5204cfe의 독립 QA 4개 통과 보고를 반영한다. 해당 head의 독립 검사와 #339/#340/#343/#345 전체 통합 검증은 구분한다. 후자는 미완료다.

모든 역할 공통 보고 규칙

기존 이슈·PR을 먼저 확인한다. 보고에는 대상 범위/버전 | 상태 | 확인 결과 | 근거 | 남은 위험 | 다음 담당을 쓴다. 상태는 아래 네 가지로 통일한다.

  • 준비 완료: 명시한 범위와 버전의 완료 근거가 있다. 제품 전체 완료로 확대하지 않는다.
  • 미완료: 필요한 작업 또는 검증이 남아 있음을 확인했다.
  • 미확인: 판단할 근거·버전·외부 조건·담당 정보가 부족하다.
  • 해당 없음: 선택한 단계/범위에 적용하지 않는 이유가 확인됐다.

새 아이디어는 범위 변경을 PM에게 제안한다. 확인하지 않은 외부 조건을 완료로 표시하지 않는다. 담당 공백과 담당 미확인을 구분해 PM에게 알린다. 최종 결과는 항상 출시 제안·준비 상태·남은 위험·사용자 결정 항목을 포함한다.

역할 간 직접 협업

기존 승인 범위의 자료·질문·검토·검증·수정 협업은 필요한 역할 작업끼리 직접 메시지로 진행한다. PM은 범위·우선순위·일정 변경, 담당 충돌과 출시 차단 문제를 종합한다. 메시지에는 이슈/PR/정확한 버전, 범위, 완료 기준 또는 필요한 답변, 선행 조건, 회신 대상을 넣는다. 기존 이슈와 상대 작업 상태·담당을 먼저 확인한다. 단순 수신 확인의 재회신과 같은 공지의 재전파는 하지 않는다. 협업 메시지로 구현·병합·배포 권한을 확대하지 않는다.

Clone this wiki locally