Planning · PM

아침에 든 생각, AI를 협업자로 봐야 할까

오늘은 아침에 눈을 뜨자마자 생각이 많았습니다.알람이 울리기 전부터 머릿속에서 같은 질문이 계속 돌았어요.앞으로 기획자는 무엇을 하는 사람일까, 그리고 요즘 매일 함께 일하는 AI는 도구일까 동료일까 하는 질문이었습니다.정리가 안 된 채로 하루를 시작하기 싫어서, 일어난 김에 생각을 그대로 적어 보려고 해요. 예전에 기획자의 하루는 문서를 만드는 시간이 상당했습니다.화면을 그리고, 설명을 붙이고, 정책을 정리하고, 그 문서를 들고 개발자와 이야기하는 흐름이었어요.요즘은 AI에게 말로 설명하면 그럴듯한 화면 목업이 금방 나옵니다.초안을 쓰는 일, 정리하는 일, 표로 만드는 일은 눈에 띄게 빨라졌어요.이 변화가 편하기만 한 건 아니었습니다.제가 직접 겪은 일 중 하나가, 화면은 빨리 나오는데 그 화면에 대한..

AI 시대의 기획 커뮤니케이션, 설명 없는 목업과 스팩브릿지를 만든 이유

AI 도구를 쓰면서 기획하는 방식이 꽤 많이 달라졌습니다.가장 크게 느낀 변화는 "화면을 만드는 비용"이 눈에 띄게 줄었다는 점이에요.그런데 화면을 만들기가 쉬워지니, 예전에는 문제가 되지 않던 곳에서 새로운 문제가 생겼습니다.오늘은 그 이야기를 정리해 보려고 해요. 예전에 저는 파워포인트로 화면 기획서를 만들었습니다.화면 그림 옆에 번호를 붙이고, 번호마다 설명을 적는 방식이었어요.이 버튼은 언제 눌리는지, 값이 비어 있으면 어떻게 되는지, 권한이 없으면 무엇이 보이는지 같은 내용이 한 장 안에 같이 있었습니다.화면은 어설퍼도 설명이 있었기 때문에, 개발자가 문서를 보면 의도를 어느 정도 읽을 수 있었어요. 하지만, 내부에서 Claude로 화면 목업을 만들어 기획을 진행해 보니 상황이 달랐습니다.AI가..

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

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

Obsidian과 마크다운으로 기획 메모 정리하는 흐름

기획 메모는 늘 어딘가에 쌓이는데, 막상 필요할 때 찾으려면 어디에 적었는지 기억이 안 나는 경우가 많았어요.노트 앱, 메신저의 나에게 보내기, 종이 수첩, 문서 도구에 흩어져 있다 보니 같은 내용을 두 번 정리한 적도 있습니다.예약 시스템 기획을 하면서 용어 정리, 정책 후보, 개발자에게 물어볼 질문이 하루에도 몇 개씩 생기는데, 이걸 담을 그릇이 하나로 정해져 있어야겠다고 생각했어요.그래서 지금은 Obsidian과 마크다운 파일로 메모를 쌓고 있습니다.오늘은 도구 소개보다는, 제가 메모를 어떤 흐름으로 쌓고 블로그 글까지 이어 가는지를 정리해 보려고 해요. 첫째 이유는 포맷 종속이 없다는 점입니다.마크다운 파일은 결국 글자만 들어 있는 텍스트 파일이라서 어떤 편집기로 열어도 열려요.지금 쓰는 앱이 마..

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

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

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

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

생성형 AI 저작권과 윤리, 공부하며 정리한 쟁점

생성형 AI를 공부하다 보면 기술 이야기만큼 자주 만나는 주제가 저작권과 윤리입니다.서비스에 AI 기능을 넣는다면 이 문제를 피해갈 수 없을 것 같아서, 기사와 공개된 논의를 읽으며 쟁점을 정리해보았습니다.먼저 분명히 해둘 점이 있습니다.저는 법률 전문가가 아니고, 이 글은 공부한 내용을 정리한 메모일 뿐 법률 자문이 아닙니다.이 분야는 아직 논의 중인 부분이 많아서, 실제 서비스에 적용할 때는 반드시 전문가의 검토와 최신 공식 안내를 확인해야 한다고 생각해요. 가장 먼저 눈에 띄는 쟁점은 모델이 무엇으로 학습했느냐입니다.이미지나 글을 생성하는 모델은 방대한 데이터로 학습하는데, 그 안에 창작자가 만든 작품이 들어 있을 수 있다는 점이 논란의 중심이에요.창작자 입장에서는 허락 없이 자신의 작품이 학습에 ..

예약 시스템 어드민 화면, 정보 구조부터 잡기

예약 시스템 기획을 하다 보면 고객이 보는 예약 화면에 신경이 먼저 가기 쉽습니다.그런데 막상 서비스가 돌아가기 시작하면 매일 가장 오래 들여다보는 건 운영하시는 분들이 쓰는 어드민 화면이에요.예약이 아무리 잘 들어와도, 어드민에서 확인하고 고치고 처리하는 일이 불편하면 서비스는 금방 외면받습니다.이 글에서는 어드민 화면을 그리기 전에 정보 구조부터 잡으면서 정리한 생각을 기록해봅니다. 처음에는 기능 목록을 그대로 메뉴로 만들었습니다.예약 관리, 고객 관리, 서비스 관리, 직원 관리, 통계, 설정 같은 식이에요.틀린 구조는 아니지만, 이대로 두면 운영자의 하루와 메뉴가 맞지 않는다는 걸 곧 알게 됐습니다.그래서 운영하시는 분이 하루에 하는 일을 순서대로 적어봤습니다.가정 예시로 동네 미용실 원장님의 하루..