모바일 청첩장에 하객 포토 기능을 넣는 서비스가 늘고 있다. 하객들이 결혼식 당일 찍은 사진을 업로드하면 신랑·신부가 한곳에서 모아볼 수 있다는 콘셉트다. 그런데 이 기능을 실제로 설계해 보면, 단순히 "사진 올리기"만으로는 해결되지 않는 문제가 있다.
스마트폰으로 모바일 청첩장 하객 포토를 확인하는 커플
하객 포토, 왜 하나로 합치면 안 되는가
기존 서비스 대부분은 하객 포토 링크를 하나만 제공한다. 신랑 측 하객이든 신부 측 하객이든 같은 링크로 사진을 올리고, 모든 사진이 하나의 저장소에 쌓이는 구조다. 언뜻 보면 합리적이지만, 실제 결혼식 현장에서는 이 구조가 문제를 일으킨다.
가장 현실적인 리스크는 원치 않는 사진의 유입이다. 결혼식에는 양가의 다양한 관계가 얽혀 있다. 신랑의 전 연인이 이상한 사진을 올린다거나, 신부 측에서 공유하고 싶지 않은 사적인 장면이 신랑 측 저장소에 그대로 노출되는 상황이 발생할 수 있다. 하객 포토 기능이 오히려 갈등의 불씨가 되는 것이다.
또 하나의 문제는 사진 선별의 주체가 불명확해진다는 점이다. 수백 장의 사진이 한곳에 모이면, 누가 어떤 기준으로 최종 앨범에 넣을 사진을 고르는가? 신랑이 고르면 신부 측 사진이 빠질 수 있고, 신부가 고르면 그 반대가 된다.
프리아이브의 해법 — 양측 분리 수집, 개별 컨펌, 중앙 통합
프리아이브는 이 문제를 공유 링크 자체를 양측으로 분리하는 것으로 해결한다. 신랑 측 하객용 링크와 신부 측 하객용 링크를 각각 생성하고, 각 링크로 들어온 사진은 완전히 분리된 저장소에 쌓인다.
구분 | 기존 서비스 | 프리아이브 |
|---|---|---|
공유 링크 | 1개 (통합) | 2개 (신랑측/신부측 분리) |
사진 저장소 | 단일 | 양측 분리 → 중앙 통합 |
사진 선별 | 누군가 한 명이 전부 관리 | 각자 자기 측 사진 컨펌 |
리스크 관리 | 없음 | 원치 않는 사진 사전 필터링 |
핵심은 각자의 영역에서 먼저 검토한 뒤, 컨펌된 사진만 중앙 저장소로 모이는 구조다. 신랑은 신랑 측 하객 사진만 보고 컨펌하고, 신부는 신부 측 하객 사진만 보고 컨펌한다. 최종 앨범에는 양쪽 모두가 승인한 사진만 들어간다.
직접 이 기능을 설계하면서 느낀 점은, 하객 포토의 핵심이 "많이 모으는 것"이 아니라 "안전하게 모으는 것"이라는 점이다. 기존 서비스들이 하객 포토를 단순한 갤러리 기능으로 취급하는 반면, 실제로는 양가의 관계와 프라이버시가 얽힌 민감한 영역이다. 우리가 양측 분리 구조를 선택한 이유이기도 하다.
검수 프로세스 — 크로스 체크로 실수를 잡는다
양측 분리 구조는 하객 포토뿐 아니라 청첩장 자체의 검수 프로세스와도 연결된다. 모바일 청첩장은 대개 한 사람이 제작하지만, 결혼식 정보는 양가 모두에게 영향을 준다. 날짜를 잘못 적거나, 계좌 정보에 오류가 있으면 돌이킬 수 없다.
프리아이브에서는 한쪽이 청첩장을 제작하면, 다른 한쪽이 반드시 확인하는 크로스 체크 구조를 적용한다. 최종 배포 전에 양측 모두의 승인이 있어야만 공유 링크가 활성화된다. 이 구조 덕분에 날짜 오기입, 장소 주소 실수, 계좌번호 오타 같은 흔한 실수를 사전에 잡아낼 수 있다.
최종 배포의 분류 — 누가 어떤 버전을 받는가
양측 분리 설계의 마지막 퍼즐은 배포 분류다. 같은 결혼식이라도 신랑 측 하객과 신부 측 하객이 받는 청첩장의 세부 내용은 다를 수 있다. 예를 들어 혼주 인사말이 다르거나, 안내 동선이 다르거나, 축의금 계좌가 양가별로 분리되어 있는 경우다.
프리아이브는 하나의 청첩장을 기반으로 양측별 변형 배포가 가능하도록 설계했다. 공유 링크 자체가 분리되어 있기 때문에, 각 링크에 맞는 콘텐츠를 다르게 구성할 수 있다. 하객 포토 수집, 검수, 배포가 모두 하나의 양측 분리 아키텍처 위에서 일관되게 동작한다.
개인적으로는 이 구조가 단순한 기능 차별화를 넘어, 결혼 준비 과정에서 신랑·신부가 함께 참여하는 경험을 만든다고 생각한다. 한쪽이 일방적으로 제작하고 다른 쪽은 구경만 하는 기존 방식 대신, 양측이 각자의 역할을 가지고 협업하는 구조다. 이것이 프리아이브가 지향하는 방향이다.
