신뢰는 암호화 설명이 아니라 '느낌·통제·관계'로 — 그리고 멀티테넌시

이 제품은 사람의 가장 약한 순간 + 사랑하는 사람의 목소리·얼굴을 다룬다. 그래서 "내 데이터 어디 가지?"가 곧 제품의 생사. 논의로 나온 결정들:

1. "외부 저장이 무섭다"의 진짜 해법은 E2EE — 단, 조건부

서버에 올라가되 사용자 기기에서 암호화해서 서버는 암호문만 본다("우리도 못 봐요"). 펜던트 메타포와 정확히 맞음. 그러나 정직한 트레이드오프:

• 열쇠 분실 = 영구 복구 불가 → 위기 때 여는 앱(§15)엔 치명적 → 패스키/복구코드 백업 필수.
• 서버가 내용을 못 보니 §12 오디오 트랜스코딩·썸네일·푸시 본문 미리보기 불가.
• 기여자(계정 없음)는 주인 공개키로 암호화하는 하이브리드 방식 필요. → 결정: 지금 구현하지 않음. 차별점/로드맵으로. (구현 시 lib/storage가 암호문만 저장하도록 바꾸면 라우트는 그대로.)

2. 평균 사용자에겐 "이해"가 아니라 "느낌"이 신뢰를 만든다

핵심 통찰: 99%는 개인정보처리방침도 E2EE도 안 읽는다. 그래서 암호화를 설명해 불안을 없애려는 건 방향이 빗나간다. 작동하는 레버:

• 방어적으로 말하지 않기 — "안전합니다!"를 앞세우면 오히려 불안 유발. 가치(펜던트)를 앞세우고 안전은 조용히.
• 관계가 신뢰를 나른다 — 기여 링크가 사랑하는 사람에게서 오므로 신뢰는 브랜드가 아닌 관계에서. (이미 제품에 내장.)
• 요구 최소화 — 실명·전화·연락처·위치 안 받음 → "줄 게 없으면 무서울 것도 없다".
• 보이는 통제 — 쉬운 내보내기/삭제가 통제감의 핵심.

3. 그래서 실제로 구현한 것 (53e25d5)

• 내보내기: GET /api/export → 순수 Node ZIP(lib/zip.ts, store 방식)으로 manifest.json + 미디어 파일. 검증: 유효 zip에 음성 m4a + 사진 png 포함.
• 전체 삭제: DELETE /api/account → 미디어 실삭제 + 사용자 삭제(FK cascade) + 세션 정리. 검증: 삭제 후 보관함 401, 같은 이메일 재로그인 시 빈 보관함(0).
• 잔잔한 안심 한 줄 + 맥락 있는 권한 안내(녹음할 때만 마이크).
• 수익성 입장: 광고·데이터판매는 이 제품엔 금물(신뢰 파괴). → 별도 monetization 항목.

4. 멀티테넌시 — "100만 명 각자 소유" 가능한가 (실증)

데이터 모델은 1인 1보관함, 사용자별 완전 격리. 실제로 검증:

A(demo) box != B(새 사용자) box
B의 새 보관함: 항목 0
B 쿠키로 A의 사진 → 404
쿠키 없이 → 401
A 본인 → 200

→ "각자 소유"는 설계 기본값. 사용자 수는 제약 아님. 단, 진짜 소유의 전제 = 진짜 로그인(카카오, 완료) + 프로덕션 부품 교체(실 Postgres·R2·공유 rate-limit·푸시 큐). 이건 코드 구조가 아니라 로컬 부품 문제 — stack-decisions 참고.

한 줄

적게 요구하고, 관계가 신뢰를 나르게 하고, 통제권을 눈에 보이게 — 이 셋이 대부분의 불안을 녹인다. E2EE는 그 위에 얹는 "보험 + 자랑거리"지, 평균 사용자의 전환 레버가 아니다.