Planning · PM/서비스 기획

FIVO를 만들며 정한 것들, 플레이가 주고 관리는 부

FIVO(피보)를 만들기 시작한 건 10월 28일입니다.오늘이 11월 1일이니 아직 나흘, 길게 봐야 닷새쯤 된 프로젝트예요.그래서 이 글은 끝났다는 보고가 아니라 중간 기록입니다.AI와 함께 작은 앱을 만들어 보니, 만드는 일 자체는 예전보다 훨씬 가벼워졌습니다.대신 무엇을 만들고 무엇을 뺄지 결정하는 일이 기획자의 몫으로 더 크게 남더라고요.앞서 읽은 글들, 그러니까 Harness Engineering 101 글이나 AI 네이티브 핸드북 글에서 본 이야기와도 닿아 있다고 느꼈어요.도구가 많은 걸 대신해 줄수록, 사람이 정해야 하는 것의 무게는 오히려 커진다는 쪽으로요.그런데 결정은 코드보다 더 빨리 잊힙니다.화면은 남는데 이유는 남지 않아요.그래서 지금까지 정한 것들과 그 이유를 한 번 적어 두려고 ..

FIVO 구상 노트, 운동을 플레이리스트처럼 조합한다면

요즘 개인 프로젝트로 FIVO(피보)라는 운동 앱을 구상하고 있어요.아직 만들기 시작하기 전이고, 머릿속과 목업에만 있는 단계입니다.그래서 이 글은 완성된 앱의 소개가 아니라, 무엇을 왜 이렇게 만들어 볼 생각인지를 먼저 적어 두는 구상 노트예요.이 앱을 구상하게 된 배경에는 요즘 AI 기획 환경이 있습니다.AI로 만드는 비용이 낮아지면서 기획자도 작은 앱 하나쯤은 직접 만들어 볼 수 있게 됐다고 느껴요.스팩브릿지를 만들면서는 화면만으로는 의도가 전해지지 않는다는 문제를 계속 붙들고 있습니다.2022년 9월 이후 예약 시스템을 기획하면서는 정책과 예외가 구조를 좌우한다는 걸 여러 번 겪었어요.그래서 작은 앱을 처음부터 끝까지 직접 기획하고 만들어 보며 판단 근거를 쌓아 보고 싶었습니다.머리로 아는 것과 ..

테넌트 온보딩 설계, 가입부터 첫 예약까지의 길

예약 시스템을 기획하면서 한동안은 예약을 하는 고객의 화면만 열심히 그렸던 것 같아요.그런데 고객이 예약할 수 있으려면 그 전에 업장이 먼저 서비스에 들어와서 준비를 마쳐야 합니다.이 준비 과정을 온보딩이라고 부르는데, 테넌트 구조의 서비스에서는 이 길이 생각보다 훨씬 중요하더라고요.업장이 가입만 해 놓고 아무 설정도 못 한 채 떠나면, 그 테넌트에게는 예약이 영원히 생기지 않기 때문입니다.오늘은 업장이 가입해서 첫 예약을 받기까지의 길을 어떻게 설계하면 좋을지 정리해 보려고 합니다.아래 예시는 모두 설명을 위해 가정한 것이고, 실제 수치나 사례가 아닙니다. 온보딩 설계의 첫 단계는 목적지를 정하는 일이라고 생각해요.저는 목적지를 "가입 완료"가 아니라 "첫 예약이 실제로 들어온 순간"으로 잡았습니다.가..

예약 시스템의 정산과 환불 정책, 테넌트에게 돈이 흐르는 길

예약 서비스를 기획하다 보면 결제 화면까지는 금방 그려집니다.그런데 그 돈이 그 뒤에 어디로 가는지 묻는 순간부터는 이야기가 갑자기 어려워집니다.플랫폼이 받는 돈은 얼마이고, 업장은 언제 얼마를 받는지, 고객이 취소하면 누구 몫에서 빠지는지를 정해야 하거든요.테넌트 구조의 예약 시스템에서는 이 질문이 더 무거워요.업장마다 취소 규정이 다르고, 정산을 받고 싶은 주기도 다르기 때문입니다.세금, 법률, 결제대행사(PG)의 세부 규정은 제가 단정할 수 있는 영역이 아니라서, 그런 부분은 "확인 필요"로 따로 표시해두었습니다.본문의 금액과 비율은 모두 설명을 위한 가정 예시이고, 실제 서비스의 수치가 아닙니다. 가장 단순하게 그리면 돈은 고객의 결제, 플랫폼의 수수료 차감, 테넌트로의 정산이라는 세 정류장을 지..

예약 데이터에서 놓치기 쉬운 것, 시간대·중복 예약·동시성

예약 시스템 기획서를 쓰다 보면 정상 흐름은 꽤 매끈하게 정리됩니다.고객이 시간을 고르고, 예약이 생성되고, 알림이 나가고, 방문하면 끝나는 흐름이에요.그런데 개발자와 이야기를 하다 보면 "그럼 두 명이 동시에 같은 시간을 누르면요?" 같은 질문이 나오고, 그제야 기획서에 비어 있던 부분이 보이곤 합니다.이 글은 제가 예약 데이터를 기획하면서 놓치기 쉽다고 느낀 세 가지인 동시성, 시간대, 이력 보관을 정리한 기록입니다. 가장 먼저 만나는 문제가 동시성입니다.가정 예시를 들어볼게요.미용실 디자이너 한 분의 오후 3시 슬롯이 하나 남아 있습니다.고객 A와 B가 거의 같은 순간에 이 슬롯을 보고 예약 버튼을 누릅니다.두 사람 모두 화면에서는 "예약 가능"으로 보였기 때문에, 시스템이 아무 장치 없이 둘 다 ..

예약 알림 설계, 알림톡·문자·푸시 선택 기준

예약 시스템을 기획하면서 처음에는 알림을 "나중에 붙이는 부가 기능" 정도로 생각했습니다.그런데 예약 흐름을 한 줄로 그려보니, 알림이 빠지면 흐름이 이어지지 않는 지점이 생각보다 많더라고요.예약이 잘 됐는지 고객이 믿을 수 있는 것도, 노쇼가 줄어드는 것도, 운영하시는 분이 새 예약을 놓치지 않는 것도 결국 알림이 맡는 일이었습니다.이번 글에서는 알림을 언제, 어떤 채널로, 어떤 문구로 보낼지 정리하면서 세운 기준을 기록해봅니다. 채널을 고르기 전에 "언제 알려야 하는가"부터 적는 게 순서가 맞다고 느꼈습니다.채널은 나중에 바꿀 수 있지만, 시점이 빠져 있으면 서비스 경험에 구멍이 나기 때문이에요.예약 한 건의 생애주기를 따라가며 적어보면 대략 이런 목록이 나옵니다.예약 완료 직후에는 "예약이 접수되었..

권한 모델 기획, 테넌트 관리자·직원·고객의 역할 나누기

예약 시스템에는 생각보다 다양한 종류의 사람이 들어옵니다.업장을 운영하는 사장님, 현장에서 일하는 직원, 예약하는 고객, 그리고 서비스 전체를 관리하는 플랫폼 운영자까지요.이들이 한 시스템을 같이 쓰기 때문에 "누가 무엇을 볼 수 있고, 무엇을 바꿀 수 있는가"를 정리하는 권한 모델이 꼭 필요해집니다.기획 초반에는 "사장님은 다 되고 직원은 일부만 되고"처럼 감으로 정리하기 쉬운데, 막상 화면과 데이터를 하나씩 따져보면 이야기가 복잡해져요.이번 글은 권한 모델을 기획하면서 제가 정리해 본 순서를 기록한 것입니다. 권한을 사람마다 하나하나 부여하면 관리가 금방 무너집니다.그래서 많은 서비스가 쓰는 방식이 역할 기반 접근 제어, 줄여서 RBAC예요.사람에게 직접 권한을 주는 대신 "역할"을 만들고, 역할에 ..

예약 노쇼를 줄이는 정책 설계, 보증금·리마인드·취소 규정

예약 서비스를 기획하면서 운영하시는 분들 이야기를 들어보면, 거의 빠지지 않고 나오는 하소연이 노쇼입니다.예약해 놓고 아무 연락 없이 오지 않는 고객 때문에 빈 시간이 생기고, 그 시간은 되돌릴 수 없으니까요.예약 시스템이 단순히 "예약을 받는 도구"를 넘어서려면, 이 문제를 어떻게 줄여줄 수 있는지가 중요한 기능이라는 생각이 들었어요.이번 글은 노쇼를 줄이기 위한 정책 선택지를 정리하고, 고객 경험과 어떻게 균형을 잡을지 고민한 내용입니다.숫자는 모두 설명을 위한 가정입니다. 노쇼의 비용은 "그 시간의 매출이 사라진다"에서 끝나지 않는다고 느꼈어요.가상의 예를 들어볼게요.커트와 염색을 하는 작은 미용실에서 염색 예약 한 건이 노쇼가 났다고 해보겠습니다.염색은 두세 시간짜리라서, 그 시간 동안 직원은 대..

예약 가능 시간 계산 로직 기획하기, 영업시간·휴무·버퍼타임

예약 서비스에서 고객이 가장 먼저 보는 화면은 "오늘 몇 시에 예약할 수 있나요?"에 대한 시간 목록입니다.화면만 보면 버튼 몇 개가 나열된 단순한 UI인데, 그 버튼이 어떻게 만들어지는지 따져보면 꽤 많은 규칙이 숨어 있어요.예약 시스템 기획을 하면서 이 부분을 정리하다 보니, 기획서에서 가장 자주 수정되는 곳이 바로 여기였습니다.그래서 이번 글에서는 예약 가능 시간을 계산할 때 어떤 입력 값이 필요하고, 어떤 예외가 생기는지 제가 정리한 순서대로 적어보려고 합니다. 예약 가능 시간을 계산할 때 저는 "열려 있는 시간을 찾는다"보다 "닫혀 있는 시간을 하나씩 빼나간다"로 생각하는 쪽이 편했어요.하루 24시간에서 시작해서, 영업하지 않는 시간, 쉬는 시간, 이미 예약된 시간, 휴무일을 차례로 지워나가면 ..

예약 시스템의 핵심 도메인 모델, 업장, 서비스, 자원, 슬롯

예약 시스템은 겉으로 보면 "날짜와 시간을 고르는 화면"이지만, 그 뒤에는 몇 가지 개념이 서로 연결된 구조가 있습니다.이 연결을 처음부터 제대로 잡아두지 않으면, 나중에 요구사항이 하나 추가될 때마다 구조 전체를 흔들게 돼요.오늘은 제가 정리한 핵심 도메인 모델을 미용실 예시로 줄글로 풀어보려고 합니다.엔티티 관계도를 그릴 수도 있지만, 먼저 말로 설명할 수 있는지 확인하는 편이 이해가 빨랐어요. 가상의 미용실을 하나 떠올려볼게요.이름은 그냥 "A 미용실"이라고 하고, 디자이너 두 분과 샴푸실 하나가 있다고 합니다.메뉴는 커트, 염색, 펌 세 가지예요.손님이 앱에서 "토요일 오후 2시 커트"를 예약하려고 합니다.이 한 문장 안에 개념이 줄줄이 들어 있어요.미용실이라는 장소, 커트라는 메뉴, 담당 디자이..

멀티테넌트란, 기획자가 알아야 할 데이터 격리 수준

예약 시스템 기획을 시작하고 얼마 지나지 않아 "이 서비스는 멀티테넌트 구조예요"라는 말을 들었습니다.용어는 알겠는데, 기획자인 제가 이걸 얼마나 알아야 하는지가 애매했어요.개발 방식은 개발자가 정하는 영역이니까 몰라도 되나 싶었지만, 몇 번 이야기를 나누다 보니 이 구조가 정책 질문과 직접 이어진다는 걸 알게 됐습니다.오늘은 제가 이해한 만큼, 기획자 눈높이에서 데이터 격리 수준을 정리해보려고 해요.기술적으로 엄밀한 설명은 아니라서, 정확한 구현은 개발자와 꼭 확인하셔야 합니다. 하나의 서비스를 여러 고객(테넌트)이 함께 쓰되, 서로의 데이터는 섞이지 않게 하는 구조입니다.아파트에 비유하면 이해가 쉬워요.건물은 하나인데 집마다 현관문이 있고, 다른 집의 내부는 볼 수 없죠.건물을 같이 쓰니까 관리비는 ..

테넌트 구조 예약 시스템, 기획을 시작하며 정리한 용어들

예약 시스템 기획을 시작하고 가장 먼저 한 일은 화면을 그리는 게 아니라 용어 사전을 만드는 것이었습니다.같은 단어를 쓰는데 사람마다 떠올리는 대상이 다르면, 회의는 길어지는데 결론은 나지 않아요.특히 여러 업장이 함께 쓰는 테넌트 구조에서는 "누구의 것인가"를 구분해야 해서 용어가 더 중요합니다.오늘은 제가 정리해둔 용어들을 하나씩 풀어보려고 해요.업종마다 다르게 부르는 말이 있으니, 이건 정답이 아니라 "이렇게 맞춰두면 편하더라"에 가까운 기록입니다. 가장 먼저 헷갈린 단어가 테넌트였습니다.테넌트는 서비스를 빌려 쓰는 "단위"를 말합니다.쉽게 말하면 이 서비스에 가입해서 자기 데이터와 설정을 갖는 하나의 주체예요.반면 업장(점포)은 실제로 손님이 찾아가는 물리적 장소입니다.둘이 항상 1대 1이면 문제..