UIpac

블로그를 다시 정리하며 - PM으로서의 생각 기록

오랜만에 이 블로그의 예전 글들을 처음부터 끝까지 다시 읽어봤습니다.2019년, 처음 스프린트를 리드하면서 삐걱거렸던 이야기부터, 최근 AI 에이전트 시대의 PM 역할을 고민하던 글까지.쭉 읽고 나니 묘한 기분이 들었어요.같은 사람이 쓴 글인데, 문체도 관심사도 꽤 많이 달라져 있더라고요. 사실 이 블로그를 정리하게 된 계기는 단순합니다.방치해둔 글이 너무 많았어요.초안으로 써두고 발행하지 않은 글, 예전에 쓴 글인데 지금 보니 틀린 내용이 섞여 있는 글, 카테고리도 뒤죽박죽이었습니다.언젠가 정리해야겠다고 생각만 하다가, 최근에 시간이 좀 나면서 "이번엔 진짜 정리하자"고 마음을 먹게 됐어요.글을 하나씩 다시 읽으면서 남길 건 남기고, 손볼 건 손보고, 아예 빼야 할 건 빼는 작업을 하고 있는데, 이게 ..

AI 시대, 사람만이 할 수 있는 기획의 영역

요즘 "AI가 PM을 대체할 것인가"라는 질문을 정말 자주 받습니다.콘퍼런스에서도, 사내 회의에서도, 심지어 이 블로그 방문자분들 댓글에서도 비슷한 질문이 계속 나와요.저는 이 질문에 매번 조금씩 다르게 답해왔는데, 이번 기회에 제 생각을 한 번 제대로 정리해보려고 합니다.결론을 먼저 말하면, 저는 "대체된다"보다는 "역할이 재배치된다"는 쪽에 가깝게 생각하고 있어요.다만 그 재배치가 어디서, 왜 일어나는지를 구체적으로 짚어보고 싶었습니다. 먼저 솔직하게 인정해야 할 게 있어요.요구사항 문서를 정리하고, 여러 대안을 나열하고, 회의록을 요약하고, 유사 사례를 조사하는 일 - 이런 건 이제 AI가 사람보다 빠르고, 어떤 경우엔 더 꼼꼼하게 해냅니다.저도 최근 몇 달간 PRD 초안을 AI한테 먼저 뽑아달라고..

AI 에이전트 시대, PM의 역할은 어떻게 바뀌나

요즘 "코드를 AI가 대신 짜주는 시대에 기획자는 뭘 하나요?"라는 질문을 자주 듣습니다.저도 같은 질문을 스스로에게 몇 번이나 던졌어요.저는 서비스 기획과 PM 일을 해왔고, 지금은 예약 시스템 기획을 하면서 AI 공부를 꾸준히 이어가고 있습니다.그 정도의 경험으로 업계 전체를 전망할 수는 없어서, 이 글은 예측보다는 제가 직접 느낀 변화를 중심으로 정리한 개인적인 생각입니다.틀릴 수 있다는 점을 먼저 말씀드리고 시작할게요. 가장 먼저 느낀 변화는 만들어보는 일의 문턱이 낮아졌다는 점입니다.예전에는 아이디어가 있어도 화면 하나 보여주려면 디자이너와 개발자의 시간이 필요했습니다.요즘은 코딩 도구에게 설명하고 작은 동작 예제를 만들어서, 말로는 전달하기 어려운 흐름을 바로 눈으로 보여줄 수 있습니다.저처럼..

MCP와 도구 호출, 서비스 기획자 관점으로 정리

AI 이야기를 따라가다 보면 요즘 "MCP"라는 단어를 자주 만납니다.도구 호출이라는 말과 함께 나오는 경우가 많은데, 처음에는 개발자들만 쓰는 용어 같아서 그냥 지나쳤어요.그런데 예약 시스템 기획을 하면서 "서비스의 기능을 AI가 쓸 수 있게 열어두면 어떨까?"라는 질문이 자꾸 나오다 보니, 기획자도 어느 정도는 이해하고 있어야겠다는 생각이 들었습니다.이번 글은 제가 이해한 만큼을 기획자 눈높이로 정리한 노트입니다.개발 세부 사항이나 특정 제품의 사양은 단정하지 않고, 개념과 기획할 때 필요한 판단 위주로 적었어요. 먼저 도구 호출부터 이야기해보겠습니다.언어 모델은 기본적으로 글을 받아서 글을 내놓는 존재입니다.그래서 "내일 오후 3시에 빈 자리 있어?" 같은 질문을 받아도, 실제 예약 시스템에 접속해..

예약 시스템에 AI 에이전트를 붙인다면, 설계 원칙

예약 시스템 기획을 하다 보면 "AI가 대신 예약해주면 되지 않나요?"라는 이야기를 자주 듣게 됩니다.말로 하면 간단한데, 막상 설계하려고 하면 따져볼 것이 한두 가지가 아니에요.이번 글은 예약 시스템에 AI 에이전트를 붙인다고 가정했을 때, 제가 기획자로서 지켜야 한다고 생각하는 설계 원칙을 정리한 것입니다.실제로 만들어서 운영한 경험을 쓰는 글은 아니고, 그동안 예약 도메인과 AI를 함께 공부하며 정리한 가설에 가깝습니다.그래서 확정된 정답이라기보다 "이런 선을 먼저 그어두면 좋겠다"는 메모로 읽어주시면 좋겠습니다. 에이전트를 붙인다고 하면 모든 걸 맡기고 싶은 마음이 먼저 듭니다.하지만 처음에는 할 일을 아주 좁게 정하는 것이 안전하다고 생각해요.예를 들어 가상의 반려동물 미용실이 있다고 해보겠습니..

AI 코딩 도구를 쓰며 달라진 기획서 쓰는 법

요즘 기획서를 쓰다 보면 읽는 사람이 한 명 더 늘었다는 느낌이 듭니다.개발자와 디자이너 말고, 코딩 도구 속에서 문서를 읽고 코드를 만들어주는 AI도 제 기획서의 독자가 된 거죠.저는 개발자가 아니라서 직접 서비스를 만들 수는 없지만, 코딩 보조 도구를 가지고 작은 화면이나 동작을 만들어보는 일은 조금씩 해보고 있습니다.그러다 보니 "내 기획서가 사람에게는 충분해 보여도 AI에게는 부족하구나" 하는 순간을 여러 번 만났어요.이번 글은 그 경험을 바탕으로, 기획서를 쓰는 방식이 어떻게 달라지고 있는지 정리해본 기록입니다.특정 도구의 세부 기능을 설명하는 글은 아니고, 문서를 쓰는 사람의 관점에서 정리했습니다. 사람 개발자는 기획서가 조금 모호해도 맥락을 읽어서 되묻거나 알아서 보완해줍니다."예약 취소는 ..

2024년의 방향 정리, 예약 시스템 기획과 AI 공부 사이에서

벌써 5월입니다.연초에 세운 계획을 슬슬 다시 열어봐야 할 시기인 것 같아서 이번 글에서는 올해의 방향을 한 번 정리해보려고 합니다.요즘 가장 자주 하는 고민은 시간을 어디에 쓰느냐입니다.한쪽에는 맡고 있는 예약 서비스 기획이 있고, 다른 쪽에는 꾸준히 이어가고 싶은 AI 공부가 있어요.둘 다 재미있고 둘 다 의미가 있다 보니, 오히려 "어느 하나를 줄여야 하나" 하는 마음이 들 때가 있습니다. 먼저 두 갈래를 각각 어떻게 이해하고 있는지 적어보겠습니다.첫 번째는 도메인 기획의 깊이입니다.예약 서비스는 겉으로 보면 단순해 보여도 파고들수록 정책이 많이 얽혀 있습니다.영업시간과 휴무, 서비스 소요시간, 직원별 일정, 취소 규정, 알림, 권한 같은 것들이 서로 연결되어 있어요.이걸 제대로 알아야 "이 정책을..

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

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

GPTs로 나만의 기획 보조 도구 만들어본 기록

2023년 11월에 GPTs라는 기능이 공개됐어요.코드를 쓰지 않고도 나만의 맞춤형 챗봇을 만들 수 있다는 소개였습니다.처음에는 솔직히 "결국 프롬프트를 저장해두는 기능 아닌가" 하고 가볍게 생각했어요.그런데 예약 서비스 기획을 하면서 비슷한 요청을 ChatGPT에 반복해서 붙여 넣고 있다는 걸 깨달았습니다.매번 "너는 꼼꼼한 기획 리뷰어야, 아래 문서를 읽고..." 하고 같은 문장을 복사하고 있었거든요.그 반복을 줄여보고 싶어서 몇 주 동안 이것저것 만들어봤습니다.이 글은 그 기록입니다.제품의 세부 사양을 정리하는 글은 아니고, 만들어보며 느낀 개념과 경험 위주로 적어봤어요.화면 구성이나 제한 사항은 계속 바뀌는 것 같아서, 정확한 내용은 공식 안내를 보시는 게 맞습니다. 제가 이해한 GPTs의 핵심은..

ChatGPT 1년, 공부 기록과 다음 계획

이번 주가 지나면 ChatGPT가 공개된 지 딱 1년이 됩니다.작년 이맘때 처음 접속해서 "오, 이게 되네?" 하고 신기해하던 기억이 아직 생생한데요.벌써 1년이라니 시간이 참 빠르다는 생각이 듭니다.그래서 이번 글은 새로운 기술 소식을 정리하기보다는 제가 지난 1년 동안 무엇을 공부했고, 그게 일하는 방식에 어떤 변화를 줬는지 돌아보는 기록으로 남겨보려고 합니다.거창한 성과가 있는 건 아니고, 예약 시스템 기획을 하면서 틈틈이 공부한 흔적을 모아보는 정도예요. 돌이켜보면 공부는 대략 네 단계로 이어졌습니다.처음은 그냥 써보는 것이었습니다.질문을 던지고, 글을 다듬게 하고, 아이디어를 뽑게 하면서 "어떤 일에 잘 맞고 어떤 일에 안 맞는지" 감을 잡는 시기였어요.이때 가장 크게 배운 건 그럴듯하게 틀린 ..

멀티모달이 왔다, 이미지를 이해하는 모델로 무엇을 할 수 있나

이번 가을에 가장 눈에 띄는 소식은 이미지를 함께 이해하는 모델이 실제로 쓸 수 있는 형태로 나오기 시작했다는 점이었습니다.그동안 ChatGPT를 쓰면서 글자로만 대화하는 데 익숙해져 있었는데요.사진을 한 장 올리고 "이게 뭐야?" 하고 묻는 장면이 현실이 된다는 게 꽤 낯설면서도 설레었습니다.저는 요즘 예약 시스템 기획을 하면서 AI 공부를 같이 하고 있어서, 이런 소식이 나오면 늘 같은 질문으로 돌아옵니다."이게 예약 서비스에서는 어디에 쓰일 수 있을까?"오늘은 아직 확정된 사실보다는 공부하면서 정리한 생각이 많다는 점을 먼저 말씀드리고 시작하겠습니다. 멀티모달은 말 그대로 여러 형태의 정보(글, 이미지, 소리 등)를 함께 다루는 것을 말합니다.이번에 화제가 된 것은 그중에서도 이미지를 입력으로 받아..

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

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