기획자의 작업대

AI 시대 기획자, 대체되지 않는 법 3가지 AI 시대 기획자, 대체되지 않는 법 3가지 📌 목차 "이거 AI가 다 하지 않아?"라는 말을 들었을 때 AI가 대체하는 영역 vs 대체 못 하는 영역 실제 사례로 보는 경계선 실무 팁 3가지 마무리 FAQ 1. "이거 AI가 다 하지 않아?"라는 말을 들었을 때 얼마 전 회의에서 개발자 한 분이 "이 정도 기획 문서는 이제 AI가 초안 정도는 다 뽑아주지 않냐"고 농담 반 진담 반으로 말한 적이 있습니다. 그 자리에서는 웃으며 넘겼지만, 집에 오는 길 내내 그 말이 계속 걸렸습니다. 실제로 요구사항 몇 줄만 넣어도 PRD 뼈대 정도는 순식간에 나오는 시대이니, 완전히 틀린 말도 아니었기 때문입니다. 그날 이후로 "그럼 나는 뭘 해야 하지"라는 질문을 스스로에게 계속 던지게 됐고, 그 정리 과정을 이번 글에 담아봤습니다. 2. AI가 대체하는 영역 vs 대체 못 하는 영역 AI가 잘하는 일과 못하는 일을 나눠보면 생각보다 경계가 뚜렷합니다. AI는 정리, 요약, 초안 생성, 유사 사례 리서치처럼 패턴이 있는 반복 작업에 강합니다. 요구사항 문서의 형식을 갖추거나, 회의록을 정리하거나, 비슷한 기능의 화면 구성을 나열하는 일은 이미 상당 부분 대신할 수 있습니다. 반면 AI가 대신하기 어려운 영역도 분명합니다. 이번 분기에 어떤 기능을 먼저 개발할지 트레이드오프를 판단하는 일, 개발팀과 디자인팀 사이에서 서로 다른 이해관계를 조율하는 일, 그리고 그 결정에 대해 책임을 지는 일입니다. 이 세 가지는 우리 조직의 맥락과 정치적 지형, 과거의 실패 경험까지 알아야 판단할 수 있는데, AI는 이런 맥락을 갖고 있지 않습니다. 결국 AI는 "무엇을 만들지"에 대한 ...

Jira 에픽 쪼개기, 스토리 나누는 기준 Jira 에픽 쪼개기, 스토리 나누는 기준 📌 목차 회원가입 스토리 하나가 계속 늘어났던 순간 크기가 아니라 완결성으로 나눈다 실제 사례로 보는 회원가입 에픽 쪼개기 우리 팀 에픽에 적용하는 3단계 실무 팁 3가지 마무리 FAQ 1. 회원가입 스토리 하나가 계속 늘어났던 순간 회원가입 기획서를 쓸 때 화면 하나, 스토리 하나면 충분하다고 생각했습니다. 그런데 개발 단계에 들어가니 인증 방식, 오류 처리, 약관 동의 같은 조건들이 하나씩 튀어나오면서 스토리가 계속 늘어났습니다. 처음 잡은 스토리 하나로는 감당이 안 됐고, 그제야 에픽을 어떻게 쪼개야 하는지 제대로 고민하게 됐습니다. 돌아보면 문제는 쪼개는 타이밍이 아니라 쪼개는 기준이 없었다는 것이었습니다. 이번 글에서는 에픽을 스토리로 나눌 때 크기가 아니라 어떤 기준으로 잘라야 하는지, 그 기준을 실제 사례에 적용하는 과정까지 정리해보겠습니다. 2. 크기가 아니라 완결성으로 나눈다 에픽을 스토리로 쪼개라는 말을 들으면 흔히 "더 작게 나누면 된다"고 생각합니다. 하지만 작게 나누는 것과 제대로 나누는 것은 다른 문제입니다. 작게만 나누면 서로 의존하는 조각들이 생기고, 하나가 늦어지면 나머지도 같이 멈춥니다. 레고에 비유하면 이해가 쉽습니다. 에픽은 완성된 세트 전체이고, 스토리는 그 세트 안에서 조립을 멈춰도 그 자체로 서 있는 하나의 구조물입니다. 바퀴 하나, 창문 하나 같은 낱개 블록은 태스크에 가깝습니다. 스토리를 나눌 때 기준으로 삼아야 할 것은 크기가 아니라 "혼자서도 서 있을 수 있는가"입니다. 2일차 용어 정리 글 에서 "회원가입 개선"을 에픽의 예시로 든 적이 있습니다. 그 글이 에픽과 스토리가 무엇인지 정의하는 ...

Jira 기획자 가이드, 8편을 순서대로 읽는 법 Jira 기획자 가이드, 8편을 순서대로 읽는 법 기획자의 작업대 · Jira 시리즈 허브 📌 목차 다시 Jira로 돌아와서 헷갈렸던 이야기 8편을 5단계로 나눈 지도 내 상황에서 어느 글부터 볼까 개정 현황과 알아둘 점 실무 팁 3가지 마무리 FAQ 1. 다시 Jira로 돌아와서 헷갈렸던 이야기 예전에 Jira를 쓰면서 관련 글을 정리해 둔 적이 있습니다. 한동안 Jira를 쓰지 않는 프로젝트에 있다가 다시 Jira를 쓰는 프로젝트로 돌아오니, 아는 도구였는데도 또 헷갈렸습니다. 그래서 예전 글을 지금의 Jira Cloud 웹 버전 기준으로 다시 점검하고, 8편을 한 번에 볼 수 있는 지도로 묶었습니다. 이 글은 8편을 처음부터 끝까지 읽으라고 만든 목차가 아닙니다. 지금 막힌 지점에서 필요한 글로 바로 들어가도록 길을 안내하는 글입니다. 2. 8편을 5단계로 나눈 지도 지하철 노선도를 떠올려 보시면 쉽습니다. 모든 역을 외우는 사람은 없고, 지금 있는 역과 가야 할 역만 찾으면 됩니다. 7일 시리즈가 한 개의 노선이라면, Confluence 연동 글은 다른 노선으로 갈아타는 환승역에 해당합니다. 단계 글 한 줄 요약 ① 이해 Jira 입문 Jira가 어떤 일을 하는 도구인지, 상태와 우선순위 같은 기본 구조를 기획자 눈높이로 정리했습니다. 2일차 용어 정리 Issue, Epic, Story, Task가 각각 무엇을 가리키는지 구분합니다. ② 운영 3일차 스프린트·백로그 "요청이 있다"와 "개발이 시작됐다"가 왜 다른지, 두 개념의 차이로 설명합니다. ...

글은 다 썼는데 안 예쁜 노션 정리법 글은 다 썼는데 안 예쁜 노션 정리법 📌 목차 왜 다 쓴 문서가 안 예뻐 보일까 레이아웃을 이루는 3요소 — 다단·여백·구분선 적용 방법 — 실제로 손보는 순서 실무 팁 3가지 마무리 FAQ 기획서를 다 쓰고 나서 노션 페이지를 쭉 훑어봤는데, 이상하게 눈에 잘 안 들어오는 경우가 있습니다. 내용은 빠진 게 없는데도 문서가 답답해 보이고, 스크롤을 몇 번 내려야 원하는 부분을 찾을 수 있습니다. 저도 기획 문서를 노션으로 옮기고 나서 이런 경험을 했습니다. 텍스트만 위에서 아래로 쭉 나열하다 보니, 분명 다 쓴 문서인데 팀원들이 "이거 어디 있는 내용이었죠"라고 되묻는 일이 잦았습니다. 문제는 내용이 아니라 레이아웃이었습니다. 이번 글에서는 다단, 여백, 구분선 세 가지만 정리해도 문서가 눈에 띄게 정돈되는 방법을 다룹니다. 1. 왜 다 쓴 문서가 안 예뻐 보일까 노션은 기본적으로 블록을 위에서 아래로 쌓는 구조입니다. 제목, 문단, 리스트를 순서대로 넣기만 해도 문서 형태는 갖춰지지만, 정보량이 많아질수록 세로로만 길게 늘어진 문서가 됩니다. 세로로 긴 문서는 읽는 사람이 지금 어느 구간을 보고 있는지 스스로 계속 확인해야 합니다. 구간을 나누는 시각적 장치가 없으면, 내용이 정확해도 훑어보기 어려운 문서가 됩니다. 반대로 성격이 다른 정보를 나란히 배치하거나, 구간이 바뀌는 지점을 표시하거나, 답답한 구간에 숨 쉴 공간을 주는 것만으로도 같은 내용이 훨씬 정리되어 보입니다. 이 세 가지 장치가 바로 다단, 여백, 구분선입니다. 2. 레이아웃을 이루는 3요소 — 다단·여백·구분선 세 요소는 각각 다른 역할을 합니다. 다단은 성격이 다른 정보를 좌우로 배치해서 비교하거나 병렬로 보여줄 때 쓰는 장치이고, 여백...

노션 단축키 정리, 문서 작성 시간 줄이는 법 노션 단축키 정리, 문서 작성 시간 줄이는 법 📌 목차 회의록 쓰다가 슬래시 메뉴만 몇십 번 열었던 날 노션 단축키의 두 축 — 마크다운 단축키와 커맨드 단축키 단축키 있을 때와 없을 때, 같은 문서를 써봤습니다 카테고리별 단축키 정리 실무 팁 3가지 마무리 FAQ 1. 회의록 쓰다가 슬래시 메뉴만 몇십 번 열었던 날 주간 회의록을 노션으로 정리하던 날이었습니다. 안건마다 제목을 달고, 액션 아이템은 체크박스로, 참고 자료는 토글로 접어 넣다 보니 슬래시( / ) 메뉴를 여닫는 손이 쉴 틈이 없었습니다. 회의가 끝나고 문서를 다시 보니 내용은 다 들어있는데, 정작 회의 시간보다 회의록 정리에 들인 시간이 더 길게 느껴졌습니다. 손이 마우스와 메뉴 사이를 계속 오갔기 때문입니다. 그날 옆자리 동료가 # 하나로 제목 블록을 만들고, > 하나로 토글을 여는 걸 보고서야 단축키를 거의 안 쓰고 있었다는 걸 깨달았습니다. 이번 글에서는 실무에서 바로 써먹을 수 있는 노션 단축키를 카테고리별로 정리했습니다. 2. 노션 단축키의 두 축 — 마크다운 단축키와 커맨드 단축키 노션 단축키는 크게 두 종류로 나뉩니다. 하나는 마크다운 단축키 로, 문장을 입력하면서 특정 기호를 치면 그 자리에서 블록이 바뀌는 방식입니다. # 을 치고 스페이스를 누르면 제목 블록이 되는 식입니다. 다른 하나는 커맨드 단축키 로, cmd/ctrl 같은 조합키를 눌러 실행하는 방식입니다. 텍스트 서식을 바꾸거나 페이지를 이동할 때, 이미 써놓은 글자를 선택한 상태에서 쓰는 경우가 많습니다. 두 방식은 쓰이는 시점이 다릅니다. 마크다운 단축키는 "새 블록을 만들 때", 커맨드 단축키는 "이미 있는 내용을 다룰 때" 쓴다고...

노션 표·이미지·파일·링크 삽입법 노션 표·이미지·파일·링크 삽입법 📌 목차 표 삽입하기 — 항목과 값을 짝지어 보여줄 때 이미지 삽입하기 — 설명보다 한 장이 빠를 때 파일 첨부하기 — 원본 문서를 그대로 남겨야 할 때 링크 삽입하기 — 페이지를 연결하는 법 실무 팁 3가지 마무리 FAQ 기획서 하나에 요구사항 표, 화면 캡처, 참고 PDF, 관련 페이지 링크를 한꺼번에 넣어야 했던 적이 있습니다. 표는 일단 텍스트로 나열하고, 이미지는 캡처해서 대충 붙이고, PDF는 링크만 남겨뒀습니다. 결과물을 리뷰받는 자리에서 팀장이 "이 파일 원본은 어디 있냐"고 물었는데, 정작 저도 어느 메신저로 공유했는지 기억이 안 났습니다. 표·이미지·파일·링크를 각각 다르게 다뤄야 한다는 걸 그때 처음 실감했습니다. 이번 글에서는 노션에서 이 네 가지 요소를 어떻게 삽입하고, 언제 어떤 방식을 골라야 하는지 정리했습니다. 1. 표 삽입하기 — 항목과 값을 짝지어 보여줄 때 슬래시( / )를 입력하고 "표"를 선택하거나, | 세 개를 입력하면 표 블록이 만들어집니다. 요구사항, 일정, 담당자처럼 항목과 값이 짝을 이루는 정보는 줄글보다 표로 정리할 때 훨씬 빠르게 읽힙니다. 항목 내용 담당 화면 설계 결제 플로우 와이어프레임 기획팀 API 명세 결제 승인/취소 엔드포인트 정의 개발팀 표 블록은 열 너비 조정, 셀 색상 지정, 정렬까지 가볍게 지원합니다. 다만 항목이 계속 늘어나거나 상태별 필터링이 필요해지는 시점부터는 표 블록으로는 한계가 있습니다. 이때는 표를 데이터베이스로 전환하는 편이 관리가 훨씬 수월합니다. 2. 이미지 삽입하기 — 설명보다 한 장이 빠를 때 이미지를 넣는 방법은 세 가지입니다. 파일을 드래그해서 바로 끌어다 ...

노션 하위 페이지로 문서 계층 잡는 법 노션 하위 페이지로 문서 계층 잡는 법 📌 목차 노션 페이지 계층의 개념 — 상위 페이지와 하위 페이지 계층이 꼬였던 사례와 정리 기준 적용 방법 — 하위 페이지 만들기와 구조 설계 실무 팁 3가지 마무리 FAQ 신규 프로젝트 하나를 노션으로 관리하기 시작했을 때, 처음에는 페이지 하나로 충분했습니다. 그런데 기획서, 회의록, 레퍼런스가 쌓이면서 어느새 페이지가 스무 개를 넘어갔고, 필요한 문서를 찾는 데만 한참씩 걸리는 상황이 됐습니다. 사이드바를 열어도 어떤 페이지가 어디에 속해 있는지 한눈에 안 보였습니다. 하위 페이지를 그때그때 손에 잡히는 대로 만들어 넣은 게 문제였습니다. 이번 글에서는 노션 페이지가 늘어날 때 계층을 어떻게 잡아야 문서를 오래 써도 헤매지 않는지 정리했습니다. 1. 노션 페이지 계층의 개념 — 상위 페이지와 하위 페이지 노션 문서는 기본적으로 페이지 하나에 하위 페이지가 딸려 있는 트리 구조입니다. 상위 페이지 안에서 하위 페이지를 만들면, 그 하위 페이지는 다시 자기 하위 페이지를 가질 수 있습니다. 이 구조를 어떻게 쓰느냐에 따라 문서가 폴더처럼 정돈되기도 하고, 뒤죽박죽 쌓인 창고처럼 되기도 합니다. 사이드바 계층과 인라인 하위 페이지 하위 페이지를 만드는 방법은 크게 두 가지입니다. 하나는 사이드바에서 상위 페이지 아래에 바로 추가하는 방식이고, 다른 하나는 본문 중간에 페이지 블록을 삽입해서 인라인으로 넣는 방식입니다. 두 방식 모두 결과적으로는 "하위 페이지"지만 역할이 다릅니다. 사이드바 쪽 하위 페이지는 독립적으로 찾아 들어가는 문서에 가깝고, 인라인 하위 페이지는 상위 페이지 본문 흐름 속에서만 의미가 있는 문서에 가깝습니다. 이 차이를 모르고 아무 데나 넣으면, 나중에 필요한 문서를 사이드바에서도 본...