왜 멀티테넌트 퍼스널 프로필 솔루션이 꼬이는가

대부분 이 구조에서 실패하는 이유는 "SNS를 만들려다가 프로필 카드를 만들어야 했던" 범위 혼선입니다. 멀티테넌트로 가면서 사용자별 커스터마이징, 콘텐츠 관리, 팔로우/소셜 그래프를 동시에 욕심내면 순식간에 복잡도가 폭발합니다.

핵심 원칙은 **"SNS가 아니라 명함+포트폴리오의 살아있는 버전"**으로 범위를 고정하는 것입니다.

레퍼런스 플랫폼 분석

플랫폼 취할 장점 버릴 단점
싸이월드 미니홈피 공간 소유감, 방문자 개념 무거운 꾸미기, 폐쇄성
인스타그램 비주얼 중심, 링크 공유 알고리즘 종속, 피드 노이즈
X (트위터) 실시간성, 짧은 생각 표현 소음 과다, 맥락 없는 타임라인
링크드인 커리어 구조화 딱딱함, 허세 문화
Linktree 단순 링크 허브 너무 단순, 개성 없음
카카오스토리 지인 기반 공유 폐쇄적, 국내 한정

권장 설계 방향

1. 핵심 철학: "살아있는 명함"

SNS처럼 피드를 소비하는 게 아니라, 자신을 정의하는 카드 한 장이 핵심. 방문자는 구독하는 게 아니라 저장하고 공유하는 행동을 함.

2. 데이터 모델 (단순하게)

User
 ├── handle (고유 슬러그, @webjangee)
 ├── Profile Card
 │    ├── 이름/별명/한 줄 소개
 │    ├── 대표 이미지 (1장)
 │    ├── 태그 (최대 5개, 자신을 설명하는 키워드)
 │    ├── Links[] (SNS, 포트폴리오, 쇼핑몰 등)
 │    └── Sections[] (자유 블록)
 └── Updates (선택 모듈)
      └── 짧은 근황 업데이트 (트위터 감각, 타임라인 X)

3. 멀티테넌트 설계의 함정을 피하는 법

이전 ONE CARD가 꼬인 건 아마 테넌트별 스키마 분리나 권한 체계를 너무 일찍 복잡하게 잡았기 때문일 가능성이 높습니다.

권장 방식은 싱글 스키마 + handle 기반 라우팅입니다:

yourdomain.com/@webjangee     ← 공개 카드
yourdomain.com/edit           ← 로그인 후 편집

멀티테넌트를 "기업 고객별 분리 운영"으로 잡으면 복잡해지고, **"모든 사용자가 각자의 슬러그를 가진 단일 플랫폼"**으로 잡으면 훨씬 단순해집니다.

4. 차별화 포인트 3가지

① 업데이트 스트림이 아닌 "상태(Status)" 개념

  • 피드 타임라인 없음
  • 현재 나를 설명하는 상태값만 관리 ("요즘은 Flutter 공부 중", "책 집필 마무리 단계")
  • 최신 상태 1~3개만 카드에 노출

② QR + 링크 동시 공유

  • 명함 대체재 포지셔닝
  • 오프라인 명함에 QR 코드 인쇄 → 바로 카드로 연결
  • 이게 Linktree와 가장 큰 차별점

③ 지인 그룹별 카드 레이어 (ONE CARD의 핵심 재활용)

  • 공개용 / 지인용 / 비즈니스용 레이어를 하나의 계정에서 관리
  • 방문자가 코드/링크로 특정 레이어 접근
  • 소셜 그래프 없이 "공유 방식"으로만 관리 → 복잡도 폭발 방지

기술 스택 추천

웹장이 운영 환경 + Flutter 확장을 고려하면:

  • 백엔드: PHP (기존 역량) + REST API로 단순하게
  • 프론트 웹: HTML/CSS (카드 렌더링은 단순할수록 좋음)
  • 모바일: Flutter (편집 앱, QR 생성/스캔)
  • DB: MySQL, users + profiles + links + updates 테이블 4개로 시작
  • 호스팅: 서브도메인 대신 경로 기반 ( /@handle )으로 단순화

결론적으로

ONE CARD가 꼬인 건 범위 문제였을 가능성이 큽니다. 다시 만든다면:

  1. 소셜 그래프(팔로우/피드) 제거 → 명함+포트폴리오로 포지셔닝
  2. 멀티테넌트를 "기업 분리"가 아닌 "사용자별 슬러그"로 단순화
  3. 레이어 공개 설정으로 지인/비즈니스/공개 분리
  4. QR 코드 오프라인 연동으로 명함 대체재 포지셔닝