모바일 청첩장 UX/UI 설계 시작

모바일 청첩장 서비스를 하나씩 직접 써보면서, 기능 목록이 아닌 사용 경험에 집중해봤다. 결론부터 말하면, 대부분의 서비스가 "기능은 다 있는데 쓰기가 불편하다." 지도도 있고 갤러리도 있고 RSVP도 있다. 그런데 만드는 과정이 매끄럽지 않다. 프리아이브의 UX/UI 설계는 이 지점에서 시작했다.

기존 서비스의 UX 문제점 : 세 가지 패턴

경쟁사 서비스를 분석하면서 반복적으로 발견한 UX 문제점은 크게 세 가지로 정리된다.

첫째, 편집 흐름이 선형적이지 않다. 대부분의 서비스가 "템플릿 선택 → 정보 입력 → 미리보기 → 공유"라는 단계를 따르지만, 실제로는 중간에 되돌아가야 하는 상황이 빈번하다. 사진을 넣었더니 레이아웃이 깨지고, 텍스트를 바꿨더니 폰트 크기가 안 맞고, 색상을 변경하려면 처음부터 다시 시작해야 하는 경우도 있다. 편집 중 실시간 미리보기가 되지 않는 서비스도 여전히 존재한다.

둘째, 커스터마이징의 깊이가 얕다. 개발자들이 직접 모바일 청첩장을 코딩하는 가장 큰 이유가 여기에 있다. 기존 서비스의 템플릿은 사진과 텍스트만 교체할 수 있는 수준이다. 색상 팔레트를 바꾸거나, 섹션 순서를 조정하거나, 폰트를 선택하는 것조차 제한적이다. Velog에 올라온 한 개발자의 후기에 따르면, "니즈를 생각하기에 앞서 두 가지 질문을 던져봤다 — 이 청첩장은 누구를 위한 것인가, 그리고 그 사람은 왜 이 청첩장이 필요한가"라는 본질적인 질문에서 시작한 설계가 기존 서비스에는 부재하다.

셋째, 모바일 최적화가 미흡하다. 모바일 청첩장이라는 이름을 달고 있으면서 정작 모바일에서의 편집 경험이 좋지 않은 서비스가 많다. 데스크톱 에디터를 그대로 축소한 듯한 인터페이스, 터치 영역이 너무 작은 버튼, 스크롤이 끊기는 미리보기 — 이런 문제들이 사용자를 데스크톱으로 내몬다.

프론트엔드 개발을 10년 해온 입장에서 가장 답답했던 것은 세 번째다. 모바일 퍼스트를 표방하면서 편집 UX는 데스크톱 기준인 서비스가 너무 많다. 모바일 청첩장의 최종 소비 환경은 100% 모바일이다. 그런데 만드는 과정은 PC에서 해야 편하다? 이건 설계 단계에서부터 잘못된 것이다. 우리가 에디터를 모바일 네이티브 수준으로 설계하겠다고 결심한 이유이기도 하다.

프리아이브의 설계 원칙 : "제한된 자유"

UX 설계에서 가장 먼저 정한 원칙이 있다. "제한된 자유(Constrained Freedom)"라는 개념이다. 모든 것을 바꿀 수 있게 하면 사용자는 오히려 막막해한다. Figma가 캔버스 위에서 무한한 자유를 주면서도 컴포넌트와 오토 레이아웃이라는 제약을 제공하는 것과 같은 맥락이다.

우리가 설계한 에디터의 핵심 구조는 이렇다.

프리셋 기반 커스터마이징. 색상은 자유롭게 고르는 것이 아니라, 전문 디자이너가 설계한 컬러 팔레트 중에서 선택한다. 각 팔레트는 메인 색상, 보조 색상, 배경 색상, 텍스트 색상이 조화롭게 구성되어 있어서 어떤 조합을 골라도 디자인이 깨지지 않는다.

섹션 단위 편집. 청첩장 전체를 하나의 긴 페이지로 보는 것이 아니라, 인사말·갤러리·지도·계좌번호·방명록 등 독립된 섹션으로 분리한다. 각 섹션의 순서를 드래그로 변경할 수 있고, 필요 없는 섹션은 비활성화할 수 있다. 섹션 내부에서만 편집이 이루어지기 때문에 전체 레이아웃이 깨질 위험이 없다.

실시간 미리보기. 편집 화면과 미리보기가 분리되지 않는다. 편집하는 그 화면이 곧 최종 결과물이다. WYSIWYG(What You See Is What You Get) 방식이지만, 편집 모드에서는 각 섹션에 편집 아이콘이 오버레이된다. 터치하면 해당 섹션의 편집 패널이 바텀시트로 올라온다.

개발자들이 직접 만드는 이유에서 배운 것

레퍼런스 조사 중 인상적이었던 것은, 개발자들이 직접 모바일 청첩장을 만드는 사례가 정말 많다는 점이다. Velog, 티스토리, 개인 블로그에 올라온 제작기를 분석해보면 공통된 동기가 있다.

"명색이 개발자인데, 모바일 청첩장은 내가 만들어야지." 이 한 문장이 많은 것을 말해준다. 기존 서비스로는 자신이 원하는 결과물을 만들 수 없다는 뜻이다. Next.js, React, styled-components 등 최신 기술 스택으로 청첩장을 만들고, GitHub에 오픈소스로 공개하는 개발자도 있다. 한 개발자는 "갤러리가 모바일 청첩장의 꽃"이라며 사진 애니메이션에 공을 들였고, 다른 개발자는 "결혼식 후에 더욱 특별한 페이지로 만들어 영원히 의미 있는 공간으로 만들겠다"는 비전을 제시했다.

이 사례들에서 우리가 배운 것은 두 가지다. 하나는 디자인 자유도에 대한 욕구가 강하다는 것이고, 다른 하나는 결혼식 이후에도 유지되는 청첩장에 대한 수요가 분명하다는 것이다.

개발자가 직접 모바일 청첩장을 코딩하는 데 평균 2~4주가 걸린다. 디자인까지 혼자 하면 그 이상이다. 이 시간을 투자하는 이유는 기존 서비스가 "내 것"이라는 감각을 주지 못하기 때문이다. 프리아이브의 에디터가 목표하는 것은, 코딩 없이도 "직접 만든" 느낌을 줄 수 있는 수준의 커스터마이징이다. 개발자가 2주 동안 코딩해서 얻는 결과물의 80%를, 30분 만에 만들 수 있게 하는 것. 이것이 우리 UX 설계의 북극성 지표다.

기술 스택 결정 과정

UX 설계 방향이 정해지면 기술 스택이 따라온다. 우리가 선택한 핵심 기술과 그 이유는 다음과 같다.

특히 Next.js의 App Router를 선택한 것은 청첩장의 특성과 관련이 있다. 청첩장은 한 번 만들면 수백~수천 명이 조회하는 콘텐츠다. SSG(Static Site Generation)로 빌드하면 서버 부하 없이 빠른 로딩을 보장할 수 있다. 동시에 방명록이나 RSVP처럼 동적인 부분은 클라이언트 컴포넌트로 분리하여 최적의 성능을 확보한다.

위시켓·크몽에서 본 시장의 단면

흥미로운 발견이 하나 더 있었다. 위시켓에서 "모바일 청첩장 1페이지 UI/UX 기획 및 디자인" 프로젝트가 50만 원 예산으로 올라왔는데, 지원자가 15명이었다. 크몽에서는 모바일 청첩장 프론트엔드 개발 포트폴리오가 활발하게 거래되고 있다. 이것이 의미하는 것은, 모바일 청첩장의 UX/UI에 대한 수요가 공급을 초과하고 있다는 것이다.

개인이 외주를 맡기면 50만~200만 원이 든다. 템플릿 서비스를 쓰면 무료~2만 원이지만 커스터마이징이 제한된다. 이 사이의 간극을 채우는 것이 프리아이브의 포지션이다. 무료이면서 전문가 수준의 결과물을 만들 수 있는 에디터.

UX 설계에서 가장 경계하는 것이 "개발자의 자기 만족"이다. 기술적으로 멋진 것과 사용자에게 좋은 것은 다르다. 우리 팀이 세운 원칙은, 모든 UX 의사결정을 "결혼을 앞둔 20~30대 커플"의 시선에서 검증하는 것이다. 기술 스택은 수단이고, 목표는 "스마트폰으로 10분이면 완성되는 청첩장"이다. 다음 글에서는 축의금 관리 기능의 설계 과정을 공유하겠다.

참고 자료

• 그래도 명색이 개발자인데, 모바일 청첩장은 내가 만들어야지 — Velog

• 모바일 청첩장 오픈소스 프로젝트 소개

• 모바일 청첩장 프로젝트 — 첫걸음: 요구사항 분석

• 결혼식 후 더욱 특별하게 — 모바일 청첩장 DIY

• 온라인 청첩장을 만들고 — Jaewon Heo

• 모바일 청첩장 1P UI/UX 기획 및 디자인 — 위시켓

• 결혼식 청첩장 Github blog로 세련되게 만들기