점주님의 목소리에서 시작된 항해를 돌아보다

안녕하세요, 프로덕트팀에서 PM을 맡고 있는 신정현입니다.

저는 매거진 인턴작가로 활동했던 경력을 가지고 있는데요?! 너무 기대감을 높여 긴장되지만, 앞으로 페이타랩에서 항해를 함께할 동료분들께 조금이나마 도움이 되었으면 하는 바람으로 글을 시작합니다.

이 글에는 하나의 목표를 향해 때로는 순항하고 때로는 거친 파도를 넘었던, 저희 Squad의 솔직한 여정이 담겨 있습니다. 저의 애정이 듬뿍 담긴 첫 항해 일지를 지금부터 여러분과 함께 펼쳐보려 합니다. 🌊

Intro: 모든 것은 점주님의 목소리에서 시작되었다

“담당자님, 혹시 ‘오늘의 할인’ 같은 이벤트는 패스오더에서 어떻게 진행해야 하나요?”

패스오더의 여러 채널을 통해 점주님들이 가장 많이, 그리고 가장 간절하게 남겨주시는 질문이었는데요.

이미 점주님들께서는 더 많은 고객에게 매장을 알리고, 또 단골 고객으로 만들기 위해 저마다의 방법으로 다양한 이벤트를 꾸려나가고 계셨습니다.

하지만 패스오더에는 점주님들이 직접 이벤트를 만들고 알릴 수 있는 기능을 공식적으로 제공하지 않았어요. 그래서 점주님들은 아쉬운 대로 <한정 이벤트>라는 메뉴 카테고리를 만들거나, [할인 메뉴]처럼 메뉴명 가장 앞부분에 이벤트 문구를 덧붙이는 방식으로 소식을 전하고 계셨죠.

매장 설명을 통째로 이벤트 안내 문구로 바꾸는 건 물론이고, 때로는 이벤트만을 위한 임시 메뉴를 만들기도 하셨어요. 어떻게든 고객에게 더 좋은 혜택을 드리고자 하는 점주님들의 진심과 노력이 엿보이는 동시에, 기능의 부재가 낳은 불편함이 고스란히 느껴지는 지점이었습니다.

이런 점주님들의 목소리에서 우리는 더 이상 망설일 이유가 없다고 확신했습니다.

“점주님들이 원하는 이벤트를, 원하는 때에, 원하는 방식으로 직접 열 수 있는 환경을 만들어드리자!”

이것이 바로 ‘사장님 셀프 서비스’ 프로젝트가 시작된 이유입니다.

단순히 이벤트 생성 기능을 제공하는 것을 넘어, 저희는 패스오더 플랫폼 안에서 점주님과 고객이 서로 긍정적인 영향을 주고받으며 함께 성장하는 구조를 꿈꿨어요. 점주님이 오픈한 이벤트에 고객이 즐겁게 참여하고 만족스러운 경험이 주변에 공유되어 또 다른 고객의 방문으로 이어지는 그림, 그렇게 활성화된 매장은 더 많은 이벤트를 열게 되고, 결국 더 많은 고객과 매장이 패스오더 안에서 행복한 경험을 쌓아가는 것.

점주님들의 간절한 목소리에서 시작된 이 프로젝트가 어떤 과정을 거치게 되었는지 지금부터 그 치열했던 항해의 기록을 함께 나눠보려고 합니다.

Chapter 1. '진짜 문제'를 먼저 정의하기

'기능이 없다' 라는 현상을 넘어 문제의 본질 파고들기

‘사장님들이 직접 이벤트를 만들 수 있는 기능이 없다.’

이것은 명확한 ‘현상’이었지만, 우리가 풀어야 할 ‘문제의 본질’은 아니었어요. 단순히 없는 기능을 새로 만드는 것만으로는 부족했습니다. 우리는 이 기능이 왜 필요하고, 성공적으로 작동하기 위해선 어떤 그림을 그려야 하는지, 그 본질부터 파고들어야만 했죠.

저희 패스오더가 꿈꾸는 성장의 그림은 바로 '선순환 구조'에 있습니다.

’선순환 구조’란, 쉽게는 매장과 고객이 서로에게 좋은 영향을 주면서 함께 성장하는 구조를 말해요. ‘사장님 셀프 서비스’를 예시로 들면,

• 사장님 ↔ 유저: 사장님이 좋은 이벤트를 열면, 잠시 패스오더를 잊고 있던 고객이나 비회원 고객들이 매력을 느껴 앱으로 돌아오고 주문이 늘어나 매장이 활성화돼요.

• 유저 ↔ 유저: 이벤트에 만족한 고객은 이 경험을 친구나 동료에게 공유하고, 이 공유가 또 다른 고객을 불러오죠.

• 사장님 ↔ 사장님: 한 사장님의 성공적인 이벤트가 다른 사장님에게 긍정적인 자극을 주어 더 많은 매장이 패스오더와 함께하는 분위기를 만들어요.

이렇게 한번 흐름이 만들어지면 플랫폼은 스스로 성장하는 힘을 갖게 됩니다. 이것이 바로 패스오더 전체가 바라보는 미션이자 저희가 나아갈 방향이었어요.

이 큰 그림 속에서 사장님 셀프 서비스는 선순환 구조를 움직이는 중요한 하나의 톱니바퀴와 같았습니다. 사장님들께 스스로 매장을 홍보하고 고객을 유치할 수 있는 강력한 무기, 즉 ‘이벤트 기능’을 쥐여 드림으로써 선순환의 시작을 끌어내는 것이 저희의 역할이었죠. 점주님의 자발적인 참여가 곧 플랫폼 전체의 성장으로 이어지는 핵심적인 퍼즐 조각이었습니다.

왜 우리는 '사장님'이 아닌 '유저'의 경험에 먼저 집중했는가?

여기까지 들으시면, ‘그럼 당연히 사장님들이 이벤트를 만들 수 있는 기능부터 개발해야 하는 거 아니야?’라고 생각하실 수 있어요. 실제로 저희도 처음에는 그렇게 접근하려고 했습니다. 하지만 내부 구성원들과 머리를 맞대고 고민하던 중, 아주 중요하지만 간과하기 쉬운 질문에 도달했습니다.

“만약 사장님들이 열심히 이벤트를 만들었는데, 아무도 참여하지 않는다면…?”

이 질문 하나가 프로젝트의 방향을 완전히 바꾸어 놓았습니다.

아무리 좋은 이벤트라도 고객이 그 존재를 모르거나, 참여하는 과정이 불편하다면 아무 소용이 없으니까요. 사장님이 기대감을 안고 만든 이벤트가 유저들에게 외면받는다면 그 실망감은 패스오더라는 플랫폼 자체에 대한 불신으로 이어질 수 있었습니다.

그래서 저희는 과감한 결정을 내렸습니다. 바로 유저의 경험에 먼저 집중하는 것이었죠.

Sprint 1의 목표는 ‘사장님이 이벤트를 만드는 기능'이 아니라, '유저가 이벤트에 즐겁게 참여하는 환경'을 구축하는 것으로 재정의되었습니다. 이를 위해 기존에 이벤트를 진행하시던 매장들을 선별해 저희가 직접 관리자 페이지에서 이벤트를 설정해 드리고, 개발 리소스는 온전히 유저들이 앱 내에서 이벤트를 쉽게 발견하고 막힘없이 참여하는 흐름을 만드는 데 쏟아부었습니다.

Chapter 2. 우리는 'Squad'라는 이름으로 뭉친다

PM이 던진 'Why', 디자이너와 개발자가 함께 채워나간 'How'와 'What'

‘문제’를 정의하고 나니, 이제는 ‘어떻게 해결할 것인가’라는 더 큰 산을 넘어야 했습니다. 페이타랩에서는 이렇게 하나의 목표를 향해 달리는 사람들을 Squad 구성원이라고 불러요. 이번 ‘사장님 셀프 서비스’ Squad는 기획자(PM), 디자이너(PD), 개발자-Android, iOS, Web, 백엔드로 다양한 직군의 동료들이 모여 호흡을 맞추게 되었습니다.

모든 논의의 시작은 PM이 던진 ‘Why’였습니다. “왜 점주님들은 불편함을 감수하면서까지 이벤트를 하고 싶어 하실까?”, “이 기능을 통해 우리가 만들고 싶은 선순환 구조는 구체적으로 어떤 모습일까?” 와 같이 문제의 근원을 파고드는 질문들이었죠.

PM의 ‘Why’를 이어받아 디자이너는 ‘How’, 즉 ‘어떻게’ 사용자 경험을 설계할 것인지에 대한 고민을 시작했어요.

“사장님이 만든 이벤트를 고객들이 어떻게 하면 가장 쉽게 발견할 수 있을까?”, “수많은 매장 리스트 속에서 이벤트 진행 매장을 효과적으로 주목시키려면 어떤 배지와 필터가 필요할까?” 와 같은 질문에 대한 답을 찾기 위해 다양한 레퍼런스를 분석하며 사용자 관점에서 가장 편안한 흐름을 그려나갔습니다.

그리고 이 아이디어들에 개발자들의 ‘What’, 즉 기술적인 구현 방안을 더하며 구체적인 모양을 잡아갔습니다.

“이벤트 기간이 겹칠 때 어떤 걸 먼저 보여줘야 할까요?”, “쿠폰 유효기간 정책은 어떻게 처리해야 안정적일까요?”, “사장님이 메뉴 가격을 바꾸면, 진행 중인 이벤트는 어떻게 자동 처리되어야 할까요?” 등 촘촘한 질문들이 오고 갔고, 이 과정에서 기획서는 점점 더 단단해졌습니다.

이렇게 각자의 전문성을 바탕으로 ‘Why-How-What’의 퍼즐을 함께 맞춰나가는 과정에서 우리는 단순한 ‘동료’가 아닌 하나의 목표를 향해 달리는 ‘팀’이 되어가고 있었어요.

매일 15분: 짧은 스크럼으로 Squad의 방향을 맞추는 시간

이렇게 하나의 목표를 향해 뭉친 Squad에게는 매일 아침을 여는 특별한 시간이 주어지는데요. 바로 ‘데일리 스크럼’ 시간입니다.

매일 아침 15분 남짓한 짧은 시간 동안 각자 ‘어제 한 일, 오늘 할 일, 그리고 어려움을 겪고 있는 점’은 물론, 새롭게 생긴 문의 사항이나 더 좋은 방향을 위한 개선점까지 자유롭게 공유합니다. 단순한 업무 공유가 아니라 우리가 같은 목표를 향해 나아가고 있는지 점검하는 시간이죠.

개발 과정에서 예상치 못한 이슈가 생기면 즉시 모두에게 공유되어 해결책을 함께 모색하고, 디자이너의 작은 고민이 기획의 허점을 보완하는 실마리가 되기도 했습니다.

이 짧은 15분의 소통이 있었기에 저희는 거대한 목표를 향해 가면서도 길을 잃지 않고 유연하게 소통하며 전진할 수 있었습니다.

Chapter 3. 페이타랩 PM의 무기는 뭘까?

좋은 PM의 무기는 무엇일까요? 이번 Squad의 프로젝트를 진행하면서, 저는 PM의 무기가 거창한 것이 아니라 ‘어떻게 동료들과 명확하게 소통하고, 올바른 근거로 설득하며, 함께 나아갈 것인가’에 대한 끊임없는 고민, 그 자체라는 걸 다시 한번 느끼게 되었습니다.

'복잡한 정책', 어떻게 하면 모두가 쉽게 이해할 수 있을까

‘사장님 이벤트’ 기능은 생각보다 고려할 정책이 정말 많았어요. 이벤트 상태만 해도 ‘진행 중-대기-중단-종료’ 네 가지나 있었고, 메뉴 가격이 바뀌면 이벤트 메뉴는 어떻게 처리할지, 여러 이벤트를 동시에 진행할 수는 있는지 등··· 말로만 설명했다면 분명 어딘가에서 오해가 생겼을 거예요.

이때 PM의 첫 번째 무기는 바로 ‘잘 정리된 기획서(PRD)’였습니다. 복잡한 정책일수록 디자이너와 개발자가 헷갈리지 않도록 명확한 표와 구체적인 예시를 들어 설명했어요.

하지만 상세한 문서와는 별개로, 실시간으로 오고 가는 수많은 대화 속에서 효율적인 소통 방법이 필요했습니다. 이때 백엔드 개발자인 강현님께서 주신 아이디어가 실마리가 되었어요. 바로 복잡한 정책이나 기능에 우리만의 ‘이름’을 붙여주자는 것이었습니다.

예를 들어 저희 내부에서는 유저 개개인에게 특정한 사유로 특화된 매장을 ‘관심 매장’이라고 정의하고, 해당 매장의 500m 내에 있는 매장을 ‘주변 매장’이라는 용어를 사용해서 소통하기로 약속했어요. 이렇게 용어를 명확히 정의하고 나니 회의 때마다 이름만으로 명확하게 소통할 수 있었죠.

특히 이 방법은 역대급으로 복잡했던 CRM 기획에서도 빛을 발했습니다. 이번 프로젝트는 패스오더 역사상 N배 아니, NN배는 많다고 할 수 있을 정도로 수많은 분기 처리와 메시지 종류를 담고 있었거든요.

그래서 메시지마다 고유한 코드명을 부여했습니다. 아래 이미지처럼 코드명만 들어도 ‘아, 이탈 유저에게 처음 나가는 메시지구나!’ 하고 바로 이해할 수 있는 우리만의 언어 체계가 만들어졌습니다. 덕분에 수많은 CRM 메시지 속에서 길을 잃지 않고 정확하고 빠르게 소통하며 기획을 완성해 나갈 수 있었답니다.

이렇듯 이번 스쿼드를 통해 '복잡한 정책을 모두가 쉽게 이해하도록 만드는 것’은 단순히 문서를 잘 쓰는 것을 넘어 팀원 모두가 공유하는 ‘우리만의 언어’를 함께 만들어 나가는 과정이라는 것을 배울 수 있었습니다.

Chapter 4. "이대로는 일정 안에 못 끝나요!"

문제를 정의한 후 한 팀으로 똘똘 뭉쳐 솔루션을 구체화하는 과정은 순조로웠습니다. 기획과 디자인, 개발이 착착 진행되면서 우리의 배는 목표를 향해 순항하는 듯 보였어요. 하지만 안개가 걷히고 프로젝트의 전체 모습이 드러나기 시작했을 때, 우리는 예상치 못한 거대한 암초와 마주하게 되었습니다.

역사상 가장 큰 배포 규모와 마주하다

• 이벤트를 생성하고 종료하는 모든 과정: 백오피스 메뉴 관리, 이벤트 관리, 매장 관리

• 유저가 매장을 발견하는 모든 과정: 홈 화면, 지도, 검색, 더보기 페이지의 필터와 배지

• 주문을 결정하고 결제하는 과정: 매장 상세 페이지의 정보 탭, 새로 생긴 소식 탭, 메뉴판, 장바구니, 쿠폰 적용 로직

• 주문 이후의 경험: 주문 상세 내역, 재주문, 알림함, 그리고 이 모든 것을 뒷받침하는 CRM 시스템까지 🤯

Android, iOS, 내부 백오피스 등 거의 모든 영역에 걸쳐있는, 그야말로 역사상 가장 큰 규모의 배포였습니다.

개발이 막바지에 다다르고 QA를 시작하며 이 거대한 실체를 마주한 순간, Squad 전체에 긴장감이 감돌기 시작했습니다.

“이대로는 일정 안에 절대 못 끝나요!”

위기의 순간, 저희는 ‘누구의 책임’을 묻기보다 당장 우리가 ‘어떻게 함께 해결할 것인가’에 빠르게 집중했습니다. 저희가 선택한 방법은 ‘Squad QA’였어요. 한 명의 QA 담당자에게 모든 테스트 부담을 넘기는 대신 PM, 디자이너, 개발자 할 것 없이 모든 Squad 구성원이 정해진 시간에 모여 함께 테스트를 진행하는 것이었죠.

위기 속 긍정의 문화가 만든 시너지

QA 시간은 단순히 버그를 찾는 시간이 아닙니다. Android 개발자가 iOS 앱을 써보며 미처 생각지 못한 부분을 발견하고, 디자이너는 여러 기기에서 발생하는 미세한 UI 변화를 즉시 확인해 주었습니다. 백엔드 개발자는 전체적으로 데이터 흐름을 보며 병목 현상을 예측하고 개선해 나갔어요.

“이 부분 정책이 헷갈리는데 바로잡고 갈까요?”, “제가 이 부분은 더 잘 아니까 한번 들여다볼게요!”

서로의 영역을 넘나들며 문제를 해결하는 과정에서 ‘불가능’이라는 단어는 없었습니다.

각자의 업무에 집중하면서도 어려움을 겪는 동료가 있으면 “제가 도와드릴까요?” 라고 챙기는 긍정의 문화가 자리 잡았습니다.

이런 시너지가 가능했던 것은 우리가 함께 만들어 온 ’일하는 방식’ 덕분이었습니다.

• 데일리 스크럼: 위기 상황에서 매일 아침 15분의 스크럼은 더욱 빛을 발했습니다. 전날 발견된 치명적인 버그가 아침 일찍 공유되고 다 함께 우선으로 해결해야 할 사항들을 정하며 방향을 바로잡았습니다.

• 함께 책임지는 품질: 'Squad QA’ 시간을 통해 개발자는 본인이 개발하지 않은 영역의 문제를 발견하며 제품 전체에 대한 이해도를 높이고, 기획자와 디자이너는 미처 고려하지 못했던 예외 케이스를 발견하고 빠르게 정책을 보완할 수 있었어요. ‘품질은 우리 Squad 모두의 책임’이라는 인식이 있었기에, 더 촘촘하고 완성도 높은 결과물을 만들어낼 수 있었습니다.

이 위기는 우리에게 ‘함께’라는 가치를 다시 한번 깨닫게 해주었습니다.

우리는 단순히 각자의 일만 하는 전문가 집단이 아니라 하나의 목표를 향해 기꺼이 서로의 짐을 나누어 드는 단단한 팀으로서 진짜 ‘Squad’가 되어가고 있었습니다.

Chapter 5. 다음 항해를 위한 새로운 다짐

3,000라인이 넘는 코드 변경, 여러 서비스를 넘나드는 대규모 영향 범위. 구성원 모두가 숨 가쁘게 달려온 이번 항해는 성공적인 마무리에 닿았습니다. 하지만 저희에게 진짜 마무리는 배포 버튼을 누르는 순간이 아니라, 함께 모여 우리의 여정을 되돌아보는 ‘회고의 시간’이었습니다.

솔직하고 건설적인 회고 그리고 성장

우리는 성공의 기쁨을 나누는 동시에, 아쉬웠던 점들 또한 솔직하게 꺼내 놓았습니다.

“개발 공수 대비 일정이 너무 부족했어요.” (iOS 개발자 승현님)

“첫 기획이 너무 방대해서 Agile하지 못했던 점이 아쉬워요.” (백엔드 개발자 강현님)

“백오피스 빌드 시간이 20분이나 걸려서 개발 효율이 떨어졌습니다.” (Web 개발자 도운님)

누군가를 탓하는 목소리는 없었습니다. 대신 ‘어떻게 하면 다음엔 더 잘할 수 있을까?’에 대한 건설적인 제안들이 쏟아져 나왔어요.

그 결과 ‘개발 공수를 고려한 개발자 QA 일정 산정 기준 수립’, ‘개발 규모와 목표 대비 적정성 검토를 위한 킥오프 진행’, ‘백오피스 빌드 시간 단축 추진’ 등 구체적인 액션 아이템들을 다음 항해 지도에 그려 넣을 수 있었습니다. 이렇게 솔직하게 마주하고 함께 개선을 약속하는 과정이야말로 우리 Squad가 얻은 가장 큰 성장이었죠.

이번 프로젝트는 과정도, 기술적으로도 정말 어려운 도전이었습니다. 하지만 회고록에서 가장 많이 등장했던 단어는 놀랍게도 ‘감사’와 ‘긍정’이었어요.

“개발자분들의 ‘가능합니다, 해볼게요’라는 긍정적 태도에서 정말 많이 배웠어요.” (PM 정현님)

“긴 일정에도 모든 팀원들이 긍정적인 태도를 유지해 주셔서 감사했습니다.” (디자이너 아경님)

“팀 내 협업과 격려 분위기가 좋아 유대감이 깊어졌어요.” (iOS 개발자 승현님)

복잡한 정책에 대해 몇 번이고 다시 질문해도 친절하게 설명해 주는 동료, 슬랙과 피그마에 남긴 작은 코멘트 하나도 놓치지 않고 빠르게 피드백을 주는 동료, 단순히 긍정적인 마음가짐을 넘어 서로를 향한 존중과 배려가 있었기에 가능한 결과였습니다.

우리의 경험이 다른 Squad에 미치는 영향

페이타랩에서는 어떤 프로젝트도 완전히 맨땅에서 시작하지 않습니다. 우리의 성장은 Squad 안에만 머무르지 않습니다. 치열한 고민 끝에 만들어낸 결과물들은 이제 다른 동료들의 항해를 돕는 좋은 선례가 되고 있어요.

• 사례 1: Squad QA 효율을 높여준 QA 툴

  백엔드 개발자 강현님이 개발한 QA 툴 덕분에 우리는 수많은 테스트 케이스를 효율적으로 관리할 수 있었어요. 이 툴은 AI를 활용해 핵심 프로토타입을 구축한 뒤, 실제 QA 환경에 맞게 기능을 덧붙이고 다듬는 방식으로 개발 시간을 획기적으로 단축한 결과물이었습니다.

  QA 툴의 놀라운 효율성은 곧바로 공식 프로세스로 도입하자는 논의로 이어졌습니다. 이제 다른 Squad에서도 이 툴을 활용할 수 있도록 가이드라인을 마련했고, 덕분에 패스오더 전체의 QA 경험이 한 단계 더 성장하는 계기가 되었습니다.

• 사례 2: 도메인 설계 공유 세션

  복잡한 백엔드 설계를 팀원 전체와 공유했던 경험은 Squad의 이해도를 크게 높여주었습니다. 백엔드 개발자가 직접 API 설계 배경과 데이터 구조를 설명해 주자, 복잡하게 얽혀있던 ‘매장 이벤트’ 정책에 대한 모두의 그림이 정확히 하나로 얼라인 되었어요. 이후, 이 방식은 다른 프로젝트에서도 적극적으로 도입되어 모두가 시너지를 내는 좋은 과정으로 자리 잡아가고 있습니다.

저희 스쿼드 역시 마찬가지였어요. 프로젝트의 시작점에서 저희는 다른 스쿼드들이 먼저 항해하며 남겨둔 기록, 즉 ‘회고록’이라는 소중한 나침반을 펼쳐 들었습니다. 동료들 덕에 더 나은 길로 나아갈 수 있었던 것처럼 이제 우리의 경험이 또 다른 동료들의 항해에 새로운 지도가 되기를 바라는 마음입니다.

이렇게 치열한 고민 끝에 만들어낸 결과물들은 이제 패스오더 전체의 자산이 되어 또 다른 성장의 씨앗이 되고 있습니다.

Outro. 팀워크라는 돛을 달고, 다음 여정을 향해

‘최고의 복지는 동료’라는 말을 이번 프로젝트를 통해 온몸으로 실감했습니다.

서로를 믿고 어려운 문제 앞에서 기꺼이 함께 고민하며 길을 찾아 나서는 동료들이 있었기에 우리는 무사히 항해를 마칠 수 있었습니다.

점주님의 목소리에서 시작된 우리의 첫 번째 항해는 끝났지만, 우리는 이제 더 단단해진 팀워크와 소중한 교훈이라는 새로운 무기를 얻었습니다.

이제 ‘사장님 셀프 서비스 Sprint 2’라는 새로운 목적지를 향해 우리는 다시 한번 설레는 마음으로 닻을 올립니다.

Written by.

우리의 다음 항해에 함께하고 싶다면?