별자리 교차 분석 섹션과 공유 잠금 콘텐츠 추가
목차
최근에 점성술 보고서에 새로운 섹션을 추가하고, 그 섹션의 일부 콘텐츠를 사용자 공유 액션에 연계하는 작업을 진행했다. 간단히 말하면 "별자리 교차 분석(crossover)" 이라는 보너스 리딩을 만들고, 사용자가 친구와 보고서를 공유할 때만 그 콘텐츠가 해제되도록 설계한 것이다.
왜 공유 잠금을 했나: 사용자 증식과 가치 인식
이 작업의 핵심 이유는 두 가지였다.
첫째, 바이럴 루프를 만들려고 했다. 보고서가 잠재적으로 가치 있는데, 그 전체 내용을 무료로 처음부터 공개하면 공유 동기가 약해진다. 하지만 "이 특별한 섹션은 너의 친구와 공유한 뒤에 볼 수 있다"는 식의 제약을 걸면, 사용자가 자연스럽게 친구를 초대하게 되고, 그게 곧 우리 서비스의 신규 유저 유입이 된다. 별자리/호환성 주제라는 특성상 "나랑 너는 잘 어울려?" 하고 궁금한 감정이 공유 욕구를 자극하는 구조였다.
둘째, 콘텐츠의 차별성을 만들고 싶었다. 기본 리포트(점성술 해석)와 보너스 섹션(교차 분석, 특히 사랑/호환성)을 물리적으로 분리함으로써, 보너스가 "진짜 주는 가치"처럼 느껴지게 했다. 심리학적으로 희소성과 언락 기능은 강력한 인센티브다.
기술적 구현: DB 스키마부터 API 라우팅까지
변경 사항을 보면 꽤 광범위했다:
| 영역 | 파일 | 역할 |
|---|---|---|
| DB 스키마 | sql/schema.sql |
보너스 리딩 데이터/권한 저장 구조 추가 |
| API 계층 | src/app/api/reading/[uid]/bonus/route.ts |
보너스 콘텐츠 조회 엔드포인트 |
| API 계층 | src/app/api/reading/[uid]/share/route.ts |
공유 이벤트 처리 & 권한 부여 |
| 라이브러리 | src/lib/reading.ts |
보너스 로직 (권한 체크, 데이터 처리) |
| 프론트엔드 | src/app/r/[uid]/page.tsx, reading-panel.tsx |
보고서 렌더링 & 보너스 섹션 표시 |
내가 특히 주의한 부분은 공유 권한 검증 이었다. 단순히 "유저가 share API를 호출했다"고 해서 즉시 보너스를 풀면 안 된다. 사용자가 실제로 친구의 보고서를 보고 있는지, 그 친구가 자신의 공유 동의를 했는지를 먼저 확인해야 한다. 그래서 share/route.ts 에서는 다음과 같은 검증 단계를 거쳤다:
// 공유 권한 부여 흐름
1. 공유 요청 사용자 검증 (토큰/세션)
2. 대상 리포트의 owner 확인 (리포트 소유권 체크)
3. 기존 권한 상태 조회 (중복 해제 방지)
4. 보너스 언락 기록 저장 (감시·추적용)
이런 식의 검증 단계를 거쳤고, 특히 멱등성(idempotency)을 보장해서 여러 번 호출되더라도 중복으로 권한이 부여되지 않게 했다.
왜 이런 구조로?: 트레이드오프와 의사결정
처음에는 "모든 공유를 추적하고, 그때마다 실시간으로 권한을 부여하면 어떨까" 싶었다. 하지만 몇 가지 문제가 있었다:
- 중복 처리: 같은 사용자가 여러 번 share API를 호출할 수 있다. 멱등성을 보장하지 않으면 잘못된 데이터가 축적될 수 있다.
- 타이밍 이슈: 보고서 렌더링과 권한 부여가 분리되어 있으면, 한쪽이 지연될 때 사용자가 혼란스러울 수 있다.
- 감시 비용: 매번 권한을 확인하는 건 DB 쿼리를 증가시킨다.
그래서 다음과 같이 결정했다:
- 권한은 DB에 명시적으로 저장: 공유할 때마다 기록하고, 이후로는 그걸 참조. 데이터 일관성이 명확하고 감시(audit)도 쉽다.
- 프론트에서는 권한 상태만 조회: API에서 "너는 이 보너스를 볼 수 있는가?"만 응답하고, 렌더링 로직은 그 응답에만 의존하게 했다.
- 보너스 조회와 공유 액션 분리: 두 API를 다르게 설계함으로써 각각의 책임을 명확히 했다.
팀 입장에서 본 이 작업
이 기능을 구현하면서 팀과 함께 검토한 부분들이 있었다:
- 데이터 모델 리뷰: 스키마 변경이 있으므로 마이그레이션 전략을 함께 검토했다. 대규모 사용자 기반이 있으므로 downtime을 최소화하기로 했고, 프로덕션에서는 rolling update 로 배포했다.
- 공유 이벤트 추적: 보너스 해제 사유(어떤 리포트의 공유로 해제됐는지)를 남겨두기로 했다. 나중에 사용자 분석/리포팅할 때 필요하니까.
- 테스트 케이스: 특히 "공유 없이 직접 API 호출로 권한을 우회할 수 없는가"에 대한 테스트가 중요했다. 보안 관점에서 권한 체크를 철저히 했다.
배운 점
이 작업으로 얻은 교훈이 몇 가지 있다:
첫째, 공유 메커니즘은 복잡하다. 겉으로는 "공유하면 권한 부여"라고 간단해 보이지만, 실제론 공유 대상, 공유 권한, 중복 방지, 감시 기록 등이 얽혀 있다. 초기 설계에서 이런 엣지 케이스를 일찍 걸러내는 게 얼마나 중요한지 느꼈다.
둘째, 점성술/호환성 같은 감정 기반 콘텐츠는 강력한 공유 드라이버다. 일반적인 비즈니스 데이터나 도구와는 다르게, "너와 나의 궁합"이라는 주제는 자발적 공유를 자극한다. 이런 심리적 특성을 기술 설계에 반영하는 게 중요했다.
셋째, 보너스 콘텐츠 같은 게이미피케이션 요소는 유저 리텐션을 높일 수 있지만, 과도하면 서비스가 "조작당한다"는 느낌을 줄 수 있다. 그래서 보너스가 실제로 별자리 분석 관점에서 가치 있는 콘텐츠여야 한다는 점을 팀과 강조했다. 단순 "언락용" 콘텐츠는 사용자가 금방 알아챈다.
다음은 이 기능의 성과를 모니터링하고, 사용자 피드백을 받아서 보너스 섹션의 콘텐츠를 더 풍부하게 개선할 차례다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.