[사업 방향] 공개 SDK와 클라우드·내부 설치 서비스의 유료 경계

[easylogic]

결정할 질문

현재 공개 라이브러리를 유지하면서 어느 고객 결과와 운영 책임을 유료 가치로 삼을지 논의한다. 가격·라이선스 변경 공지가 아니다.

확인한 사실

• 루트 및 검토한 제품 패키지는 MIT를 명시한다. #260의 마지막 기록은 공개 패키지 31개의 배포 완료를 보고한다.
• 기존 설계는 SaaS와 내부 설치 동시 출시, 같은 배포 산출물, 내부 설치의 독립 동작을 전제로 한다.
• AFFiNE 공식 사례는 편집기와 서버의 범위를 구분한다. 다른 회사의 분리를 그대로 채택할 근거는 없다.

대안

대안	기대 가치	부담/검증 조건
공개 SDK + 운영·호스팅·지원 유료 — 우선 검토	개발자 확산과 신뢰, 내부 설치 선택	운영 효율·지원 비용·지불 이유 확인
향후 신규 기업 모듈에 별도 상용 범위	특정 관리 업무의 비용 회수	권리·기여·유지 경계 검토 필요. 현행 코드 변경을 전제하지 않음
고객별 구축 프로젝트 중심	초기 고객 요구에 대응	인력 의존, 제품 분기와 지원 비용 증가

현재 추천은 첫 대안으로 고객 가치를 검증하고, 고객별 변경은 설정/업무 조합/버전 있는 기능 모듈 순서로 처리하는 것이다. 상용 모듈이 필요한지는 비용·수요 증거 뒤에 판단한다.

논의할 내용

1. 구매자는 좌석, 관리형 운영, 배포 지원, 업무 결과 중 무엇에 비용을 지불하는가?
2. 클라우드와 내부 설치에서 제공할 지원 범위와 업데이트 책임은 어디까지인가?
3. AI·저장·게시·지원 비용이 늘 때 과금 단위가 이를 설명하는가?
4. 공개 SDK 사용자가 유료 서비스로 옮길 이유가 있는가?

결정 방법과 상태

PR-06의 공개 범위 목록과 PR-08의 비용표·구매자 피드백을 보고 제품 책임자가 결정한다. 초기 구매자 피드백 3건을 제안한다. 금액·계약·원가의 민감한 원자료는 공개하지 않고 요약만 남긴다.

상태: 제안 / 사업 검증 전 / 가격과 라이선스 미확정. 연구와 결정 관리.

연결된 실행 이슈

• PR-06
• PR-08

[easylogic]

비용 모델 v0.1을 추가했습니다. 실제 가격·원가·구매자 응답이 없는 준비 문서입니다.

이번 검토 제안은 다음과 같습니다.

1. 공개 SDK는 통합·확장 경로로 유지하고, 클라우드는 운영 대행, 내부 설치는 설치·업데이트·복원 지원의 지불 이유를 각각 확인합니다.
2. 클라우드의 팀/좌석 기본 단위와 사용량 한도, 내부 설치의 지원 환경·범위 단위를 우선 비교합니다. 모두 구현하거나 가격을 확정하자는 뜻은 아닙니다.
3. AI 원가와 지원 시간은 별도 변수로 확인합니다. 좌석 수가 같아도 두 비용이 늘 수 있습니다. 최초 설치와 반복 지원을 나누고, 기본 문서 접근은 외부 요금 조회 성공에 의존하지 않는 기존 원칙을 유지합니다.

결정에 필요한 입력은 구매자의 실제 구매 단위, 맡기려는 운영 책임, 설치·복원·업데이트 예행 시간, 공급자 비용입니다. 이를 확보한 뒤 요금 단위와 지원 범위를 선택합니다. DEC-02는 제안·미결정 상태이며 #296도 열어 둡니다.

[easylogic]

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

범위: 출시 인수 #322의 Note→Word→Slides→Site 네 제품, 기준 main 94a9496826d0ea5b1cd06714ff4da45aef7ec8af. 사용자 결정인 외부 alpha Yorkie Cloud와 SaaS·고객사 내부 설치 동시 출시를 유지한다. 가격·배포 승인이 아니다. 출시 제안에 같은 판단과 미검증 항목을 기록했다.

근거 구분: 기존 플랫폼 설계는 내부 설치의 기본 편집·저장에 외부 연결이 불필요하다고 정한다. 2026-09-23 조회한 Yorkie 공식 자체 설치 문서는 기본 메모리 서버가 내구성을 제공하지 않고 MongoDB 연결로 영속 저장한다고 설명한다. 이는 공식 문서 사실이다. 자체 설치가 실제 Wonffice 네 제품·복원·운영비 목표를 통과했다는 뜻은 아니다. Architecture PR #360, 출시 문서 PR #358은 설계·인수 문서를 정리 중이며 구현 근거가 아니다.

대안	장점	반대 근거·필수 확인
A. SaaS 외부 alpha Yorkie Cloud + 고객사 내부 설치 Yorkie 자체 설치/MongoDB — 권고, 미결정	Cloud alpha 선택과 내부 설치 독립 동작을 함께 유지할 수 있다. 같은 제품 adapter를 환경별로 설정한다	자체 설치·MongoDB의 백업/복원·권한·외부망 차단·지원 비용을 실제로 검증해야 한다. 월 약 5만 원 목표 충족은 불명
B. 고객사 내부 설치도 Yorkie Cloud 사용	배치 수를 줄일 수 있다	문서 원문이 외부 공급자로 나가고 외부망 장애에 의존한다. 기존 내부 설치 독립 동작·자료 처리 조건의 변경 승인과 고객 조건 확인이 필요하다
C. Yorkie Cloud의 SaaS alpha만 먼저 외부 제공	첫 외부 고객의 운영 경로를 줄인다	고객사 내부 설치의 동시 출시 결정을 어느 단계에 적용할지 사용자 결정이 필요하다. 내부 설치 인수 전 출시 약속을 할 수 없다

PM 권고 이유: A를 검증 기준 후보로 두고 로컬 자체 설치 Yorkie+MongoDB의 Note 저장·재시작·두 계정 수렴을 먼저 실행한다. 같은 후보에서 Cloud 연결을 별도로 시험하고 Word→Slides→Site로 확대한다. 고객사 내부 설치는 실제 외부망 차단·복원·권한 검사로 판단한다. 이는 새 협업 서버를 직접 개발하거나 Yjs/Automerge를 병행 구현하는 제안이 아니다. Cloud에 연결한 로컬 검사는 완전 오프라인 증거가 아니다.

결정 조건: 사용자가 첫 외부 alpha의 고객사 내부 설치 포함 여부와 내부 설치 협업 원문의 외부 전송 허용 여부를 정한다. Operator는 실제 공급자 한도·사용량·DB/파일/협업/백업/지원 비용을, Backend·Architecture는 두 배치의 공통 계약과 실현 가능성을, QA·Security는 정확한 후보의 권한·재시작·복원 결과를 제시한다. 계약·개인정보 검토와 사람 운영 책임자는 미정이다. 실행 증거와 사용자 결정 전에는 어느 안도 출시 준비 완료로 표시하지 않는다.

[easylogic]

Yorkie Cloud 토큰 전달 경계 — PM 제안 (2026-09-23)

2026-09-23 확인한 Yorkie Auth Webhook 공식 문서는 클라이언트 token을 Yorkie가 Webhook에 전달한다고 설명한다. #322 합성 검사는 public key만 사용한 연결·수렴이며 로그인/권한 검사가 아니다. 이는 공개 SDK 가격이나 라이선스 결정을 바꾸지 않는다.

• A. 원본 OIDC/API bearer를 Cloud에 전달: 발급 경로는 단순하다. 하지만 원본 bearer와 포함된 actor/tenant claim이 공급자에 전달될 수 있고, 보관·로그·지역·삭제 조건은 미확인이다.
• B. API가 [Backend][WP-05c] 실제 로컬 OIDC 로그인과 tenant membership 연결 #355 OIDC를 먼저 검증한 뒤 짧은 수명의 불투명 Yorkie 전용 capability를 발급 — PM 내부 구현 권고: 공급자에 원본 OIDC claim을 보내지 않고, [Backend][WP-09a] Yorkie Auth Webhook과 tenant 문서 권한 연결 #366 Webhook이 서버측 현재 세션·문서 ACL·저장 mode를 검사한다. 발급·회수·갱신, Webhook 지연·운영 지원 비용은 더 든다.

진행 기준: B를 #366의 설계·검증 대상으로 둔다. #366 PM 범위와 완료 기준을 따른다. 직접 OIDC 전달은 자동 대체안이 아니다. Security·개인정보 담당이 공급자 token 처리 조건과 claim 최소화를 확인하고, 실제 Cloud 후보에서 두 로그인 계정·권한 회수·401/403·재접속을 검증한 뒤 외부 고객 제공 범위를 다시 결정한다. 이 제안은 고객 데이터 제공, 유료 자원 구매, SaaS·내부 설치 동시 출시 변경, 외부 alpha 승인에 해당하지 않는다.