Planning · PM/일하는 방법

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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