Planning · PM

올해 남은 두 달, 끝내고 싶은 네 가지를 정리하며

11월도 벌써 일주일이 지났습니다.올해가 끝나기까지 8주 남짓 남았어요.이쯤에서 "올해 안에 끝내고 싶은 일"을 한 번 적어 두려고 해요.목표를 많이 세우면 오히려 하나도 끝내지 못한다는 걸 이번 한 해 동안 여러 번 느꼈기 때문에, 이번에는 네 가지로 줄였습니다. aiatti 신규 버전 1차 정리FIVO 서비스 오픈1년 현황판(가칭) 만들기스팩브릿지 GitHub 공개 일의 성격이 서로 달라서 같은 방식으로 관리하면 안 될 것 같았어요.그래서 네 가지 모두 "무엇이 되면 끝인가"를 먼저 적고, 각각의 남은 일과 위험을 정리해 보겠습니다. 1. AIATTI 신규 버전, 우선은 "정리"부터aiatti는 공간 예약과 운영을 위한 통합 플랫폼입니다.여러 모듈을 조합해서 공간마다 필요한 방식으로 자유롭게 운영할..

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

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

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

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

AI가 만든 결과를 내가 이해하고 있다고 말하려면, 기획자의 확인 기준

AI로 목업을 만들고, 스팩브릿지를 만들고, 예약 시스템의 정책 문서를 쓰는 것이 요즘 제 일과의 대부분이에요.결과물이 나오는 속도는 예전과 비교가 되지 않습니다.그런데 결과물이 쌓일수록 같은 질문이 따라와요."이걸 내가 정말 이해하고 있나."화면이 그럴듯하게 나오면 이해한 것 같은 기분이 듭니다.정책 문서가 매끄럽게 정리되면 빠진 게 없다고 느끼기도 쉬워요.하지만 기분과 이해는 다르다는 걸, 설명 없는 목업 때문에 개발자와 소통이 막혔던 경험에서 한 번 배웠습니다.화면만 보면 다 정해진 것 같은데, 정작 정책은 제 머릿속에만 있었거든요.그러던 차에 GeekNews에서 제목부터 이 고민과 닮은 글을 봤습니다.오늘은 그 토론을 짧게 훑고, 코드를 읽지 못하는 기획자가 무엇을 근거로 "이해했다"고 말할 수 ..

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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