Wallet 패스, 만들어보신 적 있나요?
아이폰 Wallet 앱에 들어가는 탑승권, 영화 티켓, 쿠폰, 멤버십 카드 같은 걸 패스(Pass)라고 불러요. 사용자는 버튼 한 번이면 Wallet에 쏙 넣을 수 있지만, 만드는 쪽에선 꽤 번거로운 작업이었거든요. JSON 파일을 손으로 짜고, 이미지 크기를 하나하나 맞추고, 인증서로 서명까지 해야 아이폰이 받아줬으니까요.
그런데 애플 개발자 사이트에 Pass Designer라는 페이지가 열렸어요. 이름 그대로 Wallet 패스를 눈으로 보면서 디자인하게 해주는 애플 공식 도구예요. 디자이너나 기획자도 패스 모양을 직접 잡아볼 수 있게 됐다는 점에서 의미가 있어요. 그런데 이 도구가 정확히 무엇을 대신해주는지 이해하려면, 먼저 패스가 어떻게 생겼는지 알아야 해요. 그래서 이번 글에선 패스의 내부 구조부터 차근차근 정리해볼게요. 도구의 세부 기능과 지원 범위는 공식 페이지에서 꼭 직접 확인해보세요.
.pkpass 파일을 열어보면
Wallet 패스의 정체는 .pkpass 확장자를 가진 파일인데, 사실은 ZIP 압축 파일이에요. 압축을 풀어보면 대략 이런 것들이 들어 있어요.
pass.json: 패스의 모든 정보를 담은 설계도예요. 어느 회사 패스인지(passTypeIdentifier,teamIdentifier), 이 패스의 고유 번호(serialNumber), 바코드나 QR 정보(barcodes), 배경색과 글자색 같은 정보가 들어가요.- 이미지 파일들:
icon.png,logo.png,strip.png,thumbnail.png같은 이미지예요. 화면 해상도에 맞춰@2x,@3x버전도 따로 준비해야 해요. manifest.json: 패키지 안에 든 모든 파일의 이름과 해시값(SHA-1)을 적어둔 목록이에요.signature: manifest.json에 대한 전자서명이에요.- 컨퍼런스·밋업 티켓: QR 입장권을 Wallet에 넣어주면 참가자 경험이 확 좋아져요. 시간과 장소 정보(
relevantDate,locations)를 넣어두면 잠금 화면에 알아서 떠요. - 작은 매장의 멤버십·스탬프 카드: 앱을 따로 만들 여력이 없는 매장에 앱 없이 쓸 수 있는 가벼운 대안이 돼요.
- 구현 경로: 디자인은 Pass Designer로 잡고, 실제 생성은 서버에서 Node.js의
passkit-generator같은 라이브러리로 처리하는 조합을 생각해볼 수 있어요. 구글 월렛까지 같이 지원하면 안드로이드 비중이 높은 국내 환경에서도 커버리지를 챙길 수 있고요.
해시와 서명이 왜 필요한지 비유로 설명해볼게요. 해시는 파일마다 붙이는 지문이에요. 파일 내용이 한 글자만 바뀌어도 지문이 완전히 달라지죠. manifest.json은 “이 상자에는 이런 지문을 가진 파일들이 들어 있어요”라는 내용물 목록이에요. signature는 그 목록 위에 붙인 봉인 스티커고요. 이 스티커는 애플에서 발급받은 Pass Type ID 인증서로만 만들 수 있어요. 그래서 아이폰은 스티커가 진짜인지, 상자 내용물이 바뀌지 않았는지 확인한 뒤에야 패스를 받아줘요. 누군가 쿠폰 할인율을 몰래 바꿔치기하는 걸 막는 장치인 셈이에요.
디자인이 까다로웠던 이유
pass.json의 핵심은 스타일과 필드 배치예요. 패스 스타일은 탑승권(boardingPass), 쿠폰(coupon), 이벤트 티켓(eventTicket), 매장 카드(storeCard), 일반(generic)으로 나뉘고, 스타일마다 정보가 놓이는 자리가 달라요. 개발자는 headerFields, primaryFields, secondaryFields, auxiliaryFields, backFields 같은 영역에 키와 라벨, 값을 채워 넣어요. 문제는 이게 실제 화면에서 어떻게 보일지 결과물을 보기 전까지 감이 잘 안 온다는 거였어요. 글자가 잘리진 않는지, 로고가 너무 작진 않은지 확인하려면 매번 서명해서 기기나 시뮬레이터에 넣어봐야 했거든요.
Pass Designer 같은 시각적 도구가 반가운 이유가 바로 이거예요. 필드를 배치하고 색을 고르는 결과를 화면에서 바로 확인할 수 있으면, 디자이너와 개발자가 JSON을 주고받으며 핑퐁하는 시간이 확 줄어들어요.
다만 디자인은 시작일 뿐이에요. 사용자마다 다른 이름과 바코드를 넣어 패스를 대량으로 만들고, 서명하고, 나눠주는 건 여전히 서버가 할 일이에요. 패스는 발급한 뒤에도 바뀔 수 있어요. pass.json에 webServiceURL과 authenticationToken을 넣어두면 기기가 서버에 자신을 등록해요. 그다음 서버가 APNs 푸시를 보내면 기기가 새 패스를 받아오죠. 탑승 게이트가 바뀌었을 때 Wallet의 탑승권이 저절로 바뀌는 게 이 구조 덕분이에요. 이런 백엔드는 디자인 도구의 영역이 아니라는 점을 기억해두세요.
업계 맥락: 구글 월렛과는 철학이 다르다
구글 월렛(Google Wallet)은 접근 방식이 꽤 달라요. 애플이 “서명된 파일을 만들어 건네주는” 방식이라면 구글은 API 중심이에요. 패스의 공통 템플릿(Class)과 사용자별 패스(Object)를 구글 서버에 등록해두고, 사용자에겐 JWT로 서명된 'Save to Google Wallet' 링크를 건네는 식이죠. 정보를 바꿀 때도 구글 API로 Object만 수정하면 돼서 푸시 서버를 따로 구현할 필요가 없어요.
그동안 애플 쪽의 번거로움은 패스 생성과 배포를 대신해주는 서드파티 SaaS들이 메워왔어요. 애플이 디자인 도구를 직접 내놓은 만큼, 적어도 디자인 단계에서는 이런 서비스에 기댈 이유가 줄어들 수 있어요.
한국 개발자에게 주는 시사점
한국은 카카오톡 지갑, 네이버, 토스, 삼성 월렛처럼 자체 지갑 생태계가 강하고, 애플페이도 2023년에야 국내에 들어왔어요. 그래서 Apple Wallet 패스를 적극적으로 쓰는 국내 서비스는 아직 많지 않아요. 그런데 오히려 그래서 기회가 있다고 봐요.
마무리
한 줄로 정리하면, Pass Designer는 Wallet 패스 제작에서 가장 귀찮았던 디자인 확인 단계의 벽을 낮춰주는 도구예요. 다만 서명, 배포, 업데이트 같은 백엔드를 이해하고 있어야 제대로 써먹을 수 있어요.
여러분 서비스에 Wallet 패스를 붙인다면 어떤 용도로 쓰고 싶으세요? 이미 도입해보신 분이라면 가장 까다로웠던 부분이 뭐였는지도 궁금해요.
🔗 출처: Hacker News