Planning · PM/일하는 방법

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

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

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

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

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

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

사업계획서 쓰기 - 문장보다 구조가 먼저

사업계획서라고 하면 왠지 거창한 문서가 떠오르는데, 막상 써보면 "내 생각을 남에게 설명하는 문서"라는 점에서 기획서와 닮아 있었습니다.쉬는 동안 지원사업 공고나 양식을 읽어보고, 연습 삼아 가상의 아이템으로 계획서를 써보는 과정을 거쳤어요.그때 가장 크게 배운 것은 문장을 다듬기 전에 구조를 먼저 잡아야 한다는 점이었습니다.오늘은 제가 정리한 구조와, 쓰면서 자주 했던 실수를 적어봅니다. 처음에는 첫 문단부터 멋지게 쓰려고 했습니다.그런데 문장을 다듬다 보면 어느새 같은 이야기를 반복하거나, 정작 중요한 내용이 빠져 있더라고요.구조를 먼저 잡고 칸마다 한두 줄 메모를 채워두면, 그다음에는 문장으로 풀기만 하면 됩니다.저는 글을 쓰기 전에 A4 한 장에 다섯 칸을 그립니다.문제, 해결, 시장, 모델, 실..

노코드 툴로 MVP 프로토타입 만들어보기

MVP 범위를 줄이고 나면 다음 고민은 "그럼 이걸 뭘로 만들지"입니다.저는 개발을 직업으로 하는 사람이 아니라서, 아이디어를 직접 손에 잡히는 형태로 만들어보려면 노코드 도구가 가장 현실적인 선택지로 보였어요.쉬는 동안 몇 가지 종류의 도구로 작은 프로토타입을 직접 만들어봤고, 그 과정에서 느낀 점을 정리합니다.특정 제품을 추천하는 글은 아니고, 도구의 종류와 고르는 기준에 대한 기록입니다. 처음에는 도구 이름을 비교하느라 시간을 많이 썼는데, 나중에 보니 이름보다 종류가 중요했습니다.제가 이해한 대로는 크게 세 갈래입니다. 첫째는 페이지 빌더형입니다.블록을 끌어다 놓아 소개 페이지나 신청 페이지를 만드는 도구입니다.고객이 처음 보는 화면을 빨리 만들 수 있고, 수요를 확인하는 용도로 좋습니다.둘째는 ..

아이디어 노트 쓰는 법 - 불편함을 모으는 습관

아이템을 찾는 일이 앉아서 머리를 쥐어짠다고 되는 일은 아니라는 걸 요즘 실감하고 있습니다.노트를 펴 놓고 "자, 아이디어를 내 보자" 하면 대개 비슷한 생각만 맴돌아요.반대로 이동 중에, 줄을 서다가, 앱을 쓰다가 문득 "이거 왜 이렇게 불편하지" 싶은 순간이 있었는데, 그건 대부분 기록하지 않아서 사라져 버렸습니다.그래서 요즘은 아이디어 대신 불편함을 모으는 노트를 쓰고 있어요.하루 5분이면 되는 아주 작은 습관인데, 두 주쯤 이어 가니 꽤 쓸모가 있어서 방법을 정리해 둡니다. 아이디어는 해결책 쪽에 가까운 말이고, 불편함은 문제 쪽에 가까운 말입니다.앞선 글에서 문제에서 출발하기로 했기 때문에, 해결책을 먼저 적는 노트는 방향이 맞지 않았어요.또 하나의 이유는 불편함이 훨씬 쉽게 적힌다는 점입니다...

원격 협업 시대의 온보딩 문서 만들기

작년부터 재택근무가 길어지면서, 신규 입사자 온보딩이 예전과는 완전히 다른 문제가 되었습니다.예전엔 옆자리 선배가 궁금한 거 있으면 바로 물어보고, 회의실에서 화이트보드에 구조도 그려주면서 설명해줬는데, 지금은 그게 불가능해요.저희 팀에 신규 입사자가 들어왔을 때, 첫 2주 동안 슬랙 DM으로만 30개 넘는 질문을 받았던 게 이 글을 쓰게 된 계기였습니다.이건 온보딩 문서가 없어서가 아니라, 있는 문서가 원격 환경에 맞지 않게 짜여 있어서 생긴 문제였어요. 사무실 근무 시절에는 온보딩 문서가 좀 부실해도 사람이 그 틈을 메워줬습니다.누군가 물어보면 바로 답해주고, 어깨너머로 보고 배우는 것도 많았어요.그런데 원격 환경에서는 이 즉시성이 사라집니다.질문을 슬랙에 남기고 답을 기다리는 동안 신규 입사자는 그..

서비스 기획자가 알아야 할 최소한의 SQL

기획자가 SQL을 알아야 하냐는 질문을 종종 받는데, 저는 "몰라도 일은 되지만, 알면 일이 훨씬 빨라진다"고 답합니다.저도 입사 초반엔 궁금한 숫자가 있으면 매번 데이터 분석팀에 요청을 넣고 며칠씩 기다렸어요.급하지도 않은 질문 같아서 요청하기 눈치 보였던 적도 많았습니다.SQL을 배우고 나서부터는 이런 자잘한 질문의 90% 이상을 제가 직접 확인할 수 있게 됐고, 이게 업무 속도에 생각보다 큰 차이를 만들었습니다. 기획자가 SQL을 직접 배워야 하는 가장 큰 이유는, 궁금한 걸 궁금한 시점에 바로 확인할 수 있다는 것입니다.회의 중에 "이 기능 쓰는 사용자가 몇 명이나 될까요?"라는 질문이 나왔을 때, "확인해서 다시 알려드릴게요"와 "잠시만요, 지금 바로 조회해볼게요"는 회의의 흐름을 완전히 다르게..

협업툴 Notion으로 기획 문서 관리하는 법

기획 문서를 어디에 정리할지는 팀마다 계속 바뀌는 고민거리인 것 같아요.저희 팀도 구글독스, 컨플루언스, 심지어 워드 파일을 이메일로 돌리던 시절을 거쳐서 지금은 노션으로 정착했습니다.정착하기까지 시행착오가 꽤 있었는데, 그 과정에서 정리한 노션 활용법을 공유해보려고 해요. 처음에 노션을 도입할 때 팀 내부에서 반대도 있었습니다."또 새 툴 배워야 하냐"는 반응이 많았어요.그런데 저희가 겪던 가장 큰 문제는 문서가 여기저기 흩어져 있다는 거였습니다.PRD는 구글독스에, 로드맵은 스프레드시트에, 회의록은 슬랙 채널에, 디자인 링크는 피그마 댓글에 흩어져 있어서, 새로 온 팀원이 "이 기능 관련 문서 어디 있어요"라고 물으면 저도 한참 찾아야 했어요.노션으로 옮긴 건 툴 자체가 특별해서가 아니라, 문서를 서..

PM 회의록, 효율적으로 남기는 방법

회의록을 잘 남기는 게 별거 아닌 것처럼 보이는데, 이게 안 되면 팀 전체의 실행력이 눈에 띄게 떨어진다는 걸 여러 번 경험했습니다.저도 예전엔 회의 내용을 슬랙에 텍스트로 대충 정리해서 올리는 정도였는데, 나중에 "그때 그거 누가 하기로 했었죠?"라는 질문에 답을 못 하는 상황이 반복되면서 방식을 바꾸게 됐어요.이번 글에서는 지금 저희 팀이 쓰고 있는 회의록 작성 방법을 정리해보려 합니다. 회의록을 왜 남기는지에 대한 합의가 없으면, 사람마다 다른 걸 기록하게 됩니다.어떤 사람은 논의 과정을 자세히 적고, 어떤 사람은 결론만 한 줄로 적어요.저희는 회의록의 목적을 "이 회의에 참석하지 않은 사람도 5분 안에 무슨 결정이 났는지 알 수 있게 하는 것"으로 명확히 정했습니다.이 목적을 정하고 나니 회의록에..

리모트 협업 툴 비교 (Notion, Jira, Confluence)

비대면 근무가 늘면서 협업 툴을 새로 정비해야 하는 상황이 왔습니다.저희 팀은 Notion, Jira, Confluence를 각각 다른 용도로 써봤는데, 이번 글에서는 실제로 써보면서 느낀 장단점을 정리해보려 해요.정답은 없고, 팀 성격에 따라 맞는 조합이 다르다는 게 결론이라는 점을 미리 말씀드립니다. Notion: 유연하지만 규칙이 없으면 무너진다Notion을 처음 도입했을 때는 다들 좋아했습니다.문서, 위키, 간단한 데이터베이스, 칸반보드까지 하나의 툴에서 다 되니까 편했어요.저희는 회의록, 기획 문서, 온보딩 가이드를 전부 Notion으로 옮겼습니다.문제는 3개월쯤 지나자 나타났어요.누구는 페이지 제목에 날짜를 앞에 붙이고, 누구는 뒤에 붙이고, 누구는 아예 안 붙였습니다.검색을 해도 비슷한 문서..

서비스 기획서 템플릿 - 내가 쓰는 방식

기획서를 쓸 때마다 매번 형식을 새로 고민하는 게 비효율적이라는 걸 느끼고, 제가 실제로 쓰는 템플릿을 정리해보기로 했습니다.요구사항정의서와 겹치는 부분도 있지만, 여기서는 좀 더 초기 단계, 즉 아이디어를 사업적으로 정리하는 단계의 기획서를 다룹니다. 1. 한 줄 요약 2. 문제 정의3. 시장/경쟁 상황4. 솔루션 개요5. 기대 효과와 리스크6. 필요한 리소스와 일정 1. 한 줄 요약먼저, 가장 위에 이 서비스/기능이 무엇인지 한 문장으로 씁니다."누구를 위해, 어떤 문제를, 어떻게 해결하는가"를 한 문장에 담으려고 노력해요.저는 이 문장을 쓰는 데 보통 제일 오래 걸립니다.한 줄로 못 요약된다는 건 아직 생각이 정리되지 않았다는 신호더라고요.막상 써보고 팀원에게 읽어달라고 했을 때 "그게 무슨 뜻이에..