기획자의 작업대

노션 토글, 긴 기획서에서 왜 필요할까요? 노션 토글, 긴 기획서에서 왜 필요할까요? IT 서비스 기획서를 작성하다 보면 처음에는 단순했던 문서가 점점 길어집니다. 화면 설명에 입력 조건, 오류 메시지, 예외 처리, 개발 참고사항까지 추가되면 중요한 정책을 찾기도 어려워집니다. 기획 실무에서 겪는 문제 중 하나가 바로 이것입니다. 모든 내용을 빠짐없이 작성했는데도 정작 개발자나 QA 담당자가 필요한 정보를 찾는 데 시간이 걸리는 경우가 있습니다. 이럴 때 활용할 수 있는 기능이 노션(Notion)의 토글(Toggle) 입니다. 핵심 내용은 바로 보여주고, 상세 정책은 필요할 때 펼쳐 확인하도록 구성할 수 있습니다. 이번 글에서는 노션 토글의 기본 사용법부터 실제 회원가입 화면의 기능 명세서를 정리하는 방법까지 살펴보겠습니다. ※ 이 글은 2026.10 기준으로 작성되었으며, 노션의 기능과 메뉴는 변경될 수 있으므로 최신 내용은 공식 문서를 확인하시기 바랍니다. 목차 📌 목차 노션 토글이란? 노션 토글 만드는 방법 실제 IT 기획서에 토글 적용하기 긴 기획서를 구조화하는 방법 노션 토글 활용 실무 팁 3가지 자주 묻는 질문 1. 노션 토글이란? 노션 토글은 하나의 제목 아래에 여러 콘텐츠를 넣고, 필요할 때 펼치거나 접을 수 있는 블록입니다. 일반적인 텍스트 블록은 내용이 항상 표시됩니다. 반면 토글은 제목을 먼저 보여주고, 사용자가 클릭했을 때 상세 내용을 확인할 수 있도록 구성합니다. 일반 텍스트와 토글의 차이 일반 텍스트로 작성한 경우 회원가입 정책 이메일은 필수 입력 항목입니다. 이메일 형식이 올바르지 않으면 오류 메시지를 표시합니다. 이미 가입된 이메일은 사용할 수 없습니다. 비밀번호와 비밀번호 확인 값이 일치해야 합니다. 내용이 많아질수록 문서의 길이도 계속 늘어납니다. 토글을 적용한 경우 회원가입 정책 자세히 보기 ...

청년미래적금 가입조건·신청방법, 나는 대상일까 청년미래적금 가입조건·신청방법, 나는 대상일까 청년미래적금에 관심은 있지만 나이만 맞으면 되는지, 연봉은 어디까지 인정되는지 헷갈리기 쉽습니다. 청년도약계좌를 이미 가지고 있다면 갈아타기 순서도 고민이 됩니다. 저는 2026년 10월 7일 시작된 2차 모집의 공식 안내를 비교하면서 ‘가입 가능한 소득’과 ‘정부기여금을 받는 소득’이 다르다는 점 을 먼저 확인했습니다. 이번 글에서는 신청기간부터 짚고, 나이·소득·가입 유형을 순서대로 정리합니다. 2차 신청은 2026년 10월 7일~16일입니다. 7일은 출생연도 끝자리 홀수, 8일은 짝수, 12일~16일은 출생연도와 관계없이 신청합니다. 운영시간은 09:00~18:30이며 주말·공휴일은 제외됩니다. 출처: 금융위원회 2026.10.06 모집 안내 이 글은 2026.10 기준으로 작성되었으며, 최신 내용은 공식 문서를 확인하시기 바랍니다. 모집 일정·가입조건·금리 등은 변경될 수 있습니다. 📌 목차 청년미래적금이란? 청년미래적금 가입조건 일반형과 우대형 차이 나는 청년미래적금 대상일까? 2026년 청년미래적금 2차 신청기간 청년미래적금 신청방법 청년도약계좌가 있다면? 신청 전에 알아둘 점 자주 묻는 질문 1. 청년미래적금이란? 청년미래적금은 청년의 목돈 마련을 지원하는 3년 만기 자유적립식 적금 입니다. 매월 최소 1천원부터 최대 50만원까지 납입하며, 기여금 대상자는 일반형 6%, 우대형 12%의 정부기여금을 받을 수 있습니다. 구조는 내가 납입한 돈 + 은행 이자 + 정부기여금 + 이자소득 비과세 로 이해하면 쉽습니다. 다만 소득구간에 따라 정부기여금 없이 비과세만 적용되는 경우도 있습니다. 6%·12%는 은행 금리가 아니라 납입액에 대한 기여금 비율입니다. 출처: 서민금융진흥원 상품 안내 , 상품 세부 안내 2. 청년미래적금 가입조건 2-1. 나이: 신청일보다 계좌 개설일이 중요합니다 기본...

Jira 스프린트 계획, 기획자가 준비할 것 Jira 스프린트 계획, 기획자가 준비할 것 스토리 포인트 추정을 끝내고 개발을 시작했는데, “이메일 확인에 실패하면 어떻게 처리하나요?”라는 질문이 나옵니다. 화면은 준비됐지만 예외 정책이 비어 있어 작업이 멈추는 상황입니다. 저는 기획 관점에서 스프린트 계획을 볼 때, 티켓의 개수보다 팀이 같은 완료 모습을 떠올릴 수 있는지를 먼저 살펴보겠습니다. 이번 글에서는 가상의 회원가입 개선 사례로 회의 전에 준비할 정보와 회의에서 합의할 범위를 정리합니다. 이 글은 2026.10 기준으로 작성되었으며, 최신 내용은 공식 문서를 확인하시기 바랍니다. Jira Cloud의 Scrum 운영을 기준으로 설명하며, 메뉴와 필드는 관리 방식·권한·팀 설정에 따라 달라질 수 있습니다. 📌 목차 스프린트 계획에서 기획자의 역할 작업 목록보다 목표 먼저 정하기 요구사항 준비 상태 확인하기 우선순위와 의존 관계 살펴보기 팀과 이번 개발 범위 합의하기 합의 내용을 Jira에 기록하기 실무 팁 3가지 자주 묻는 질문 다음 회의 전에 할 일 1. 스프린트 계획에서 기획자는 무엇을 준비할까요? 기획자는 팀이 판단할 수 있도록 사용자 목적과 요구사항을 명확히 합니다. 무엇을 만들고 왜 필요한지, 어떤 제약이 있는지를 설명할 수 있어야 합니다. Scrum Guide는 스프린트 계획에서 가치, 이번에 완료할 작업, 수행 방법을 논의하도록 설명합니다. 목표는 팀이 함께 정하고, 선택할 작업과 구현 계획에는 개발자의 판단이 필요합니다. 기획자가 일정과 작업량을 혼자 확정하는 방식은 피해야 합니다. [1] 또한 ‘기획자’라는 직함이 곧 Product Owner를 의미하지는 않습니다. 우선순위 결정 권한이 누구에게 있는지 먼저 확인하고, 기획자는 맡은 범위에서 요구사항 설명과 의사결정을 지원합니다. 누구의 어떤 문제를 해결하는지 설명합니다. 우선순위의...

Jira 스토리 포인트, 기획자가 참여하는 법 Jira 스토리 포인트, 기획자가 참여하는 법 📌 목차 2점과 5점 사이에서 아무 말도 못 했던 순간 스토리 포인트는 시간이 아니라 상대적 난이도다 이메일 인증 스토리, 2점과 5점이 갈린 이유 추정 회의에서 기획자가 하는 3단계 실무 팁 3가지 마무리 FAQ 1. 2점과 5점 사이에서 아무 말도 못 했던 순간 회원가입 이메일 인증 스토리를 추정하는 회의였습니다. 개발자 한 분은 2점을 불렀고, 다른 한 분은 5점을 불렀습니다. 저는 개발 얘기라 제가 낄 자리가 아니라고 생각해서 그냥 지켜보기만 했습니다. 나중에 돌아보니 그 순간이 가장 중요한 순간이었습니다. 두 사람의 점수가 왜 달랐는지 물어봤다면, 스토리 설명에 빠져 있던 정보를 그 자리에서 채울 수 있었을 겁니다. 이번 글에서는 기획자가 추정 회의에서 할 수 있는 역할을 정리해보겠습니다. 2. 스토리 포인트는 시간이 아니라 상대적 난이도다 등산 코스 난이도에 비유하면 이해가 쉽습니다. "초급, 중급, 고급"은 실제 거리가 몇 km인지를 뜻하지 않습니다. 오르면서 체감하는 난이도를 나타냅니다. 스토리 포인트도 마찬가지입니다. "2점, 5점"은 몇 시간이 걸리는지가 아니라 팀이 느끼는 상대적인 복잡도입니다. 그래서 점수 자체보다 "왜 그 점수를 골랐는지"에 더 많은 정보가 담겨 있습니다. 기획자가 참여할 자리는 점수를 매기는 곳이 아니라, 그 이유를 듣고 놓친 부분을 찾는 곳입니다. 3. 이메일 인증 스토리, 2점과 5점이 갈린 이유 다시 이메일 인증 스토리로 돌아가 보겠습니다. 2점을 부른 개발자는 "이전 프로젝트에서 비슷한 인증 기능을 만들어본 적이 있다"고 했습니다. 5점을 부른 개발자는 ...

Jira 워크플로우, Done 기준 맞추는 법 Jira 워크플로우, Done 기준 맞추는 법 기획자의 작업대 · Jira 실무 가이드 📌 목차 회원가입 스토리가 Done인데 QA는 몰랐던 순간 상태값은 정의가 아니라 합의다 Done을 둘러싼 동상이몽, 회원가입 사례 우리 팀 상태값 맞추는 3단계 실무 팁 3가지 마무리 FAQ 1. 회원가입 스토리가 Done인데 QA는 몰랐던 순간 에픽 쪼개기 글에서 다뤘던 회원가입 이메일 인증 스토리가 있었습니다. 개발자가 코드를 배포하고 상태를 Done으로 바꿨는데, QA 담당자는 그 스토리를 아직 테스트해본 적도 없었습니다. "이거 Done 아니었어요?"라는 제 질문에 QA는 "저는 아직 시작도 안 했는데요"라고 답했습니다. 같은 상태값을 두고 서로 다른 걸 완료라고 생각하고 있었던 겁니다. 이번 글에서는 이런 상황을 막기 위해 상태값 기준을 팀이 어떻게 맞추면 되는지 정리해보겠습니다. 2. 상태값은 정의가 아니라 합의다 To Do, In Progress, Done 같은 상태 이름은 Jira가 기본으로 제공하다 보니 이미 정해진 뜻이 있는 것처럼 보입니다. 하지만 그 이름이 정확히 어느 시점을 가리키는지는 Jira가 정해주지 않습니다. 팀이 합의해야 하는 약속입니다. 릴레이 경주에 비유하면 이해가 쉽습니다. 바통을 넘기는 지점이 팀마다 다르면, 다음 주자는 언제 뛰기 시작해야 할지 알 수 없습니다. Done이라는 상태도 마찬가지입니다. 누군가에게는 배포가 끝난 시점이고, 누군가에게는 검증까지 끝난 시점입니다. 이 지점을 맞추지 않으면 계속 같은 오해가 반복됩니다. 3. Done을 둘러싼 동상이몽, 회원가입 사례 앞서 겪은 상황을 역할별로 풀어보면 아래처럼 서로 다른 기준으로 Done을 이해...

테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 테스트 케이스, QA 요청 받은 기획자가 처음 작성하는 법 기획자의 작업대 · 실무 가이드 📌 목차 테스트 케이스란? 기획서와 무엇이 다른가 화면이 아니라 기획서에서 출발해야 하는 이유 테스트 케이스 한 줄의 구성 기획서에서 케이스 뽑는 순서 실무 팁 3가지 마무리 FAQ 프로젝트 마무리 단계에서 QA 요청을 받은 적이 있습니다. 개발된 화면을 점검하는 게 아니라, 기획한 내용이 빠짐없이 반영됐는지 확인해 달라는 요청이었습니다. 막상 시작하려니 화면을 따라가야 할지, 기획서를 따라가야 할지부터 헷갈렸습니다. 빈 엑셀 시트를 열어 두고 첫 행에 무엇을 적어야 할지 한참 고민했던 기억이 납니다. 이번 글에서는 테스트 케이스를 처음 쓰는 기획자가 어디서 출발해야 하는지, 그리고 기획서를 케이스 목록으로 바꾸는 순서를 정리해 보겠습니다. 1. 테스트 케이스란? 기획서와 무엇이 다른가 테스트 케이스(Test Case, TC)는 "이 조건에서 이렇게 하면 이런 결과가 나와야 한다"를 한 줄씩 적은 확인 목록입니다. 기획서와 다루는 대상은 같지만 질문이 다릅니다. 기획서는 "어떻게 동작해야 하는가" 를 적고, 테스트 케이스는 "그렇게 동작하는지 어떻게 확인하는가" 를 적습니다. 요리로 비유하면 기획서는 레시피이고, 테스트 케이스는 시식 체크리스트입니다. 레시피에 "소금 한 꼬집"이 있다면, 체크리스트에는 "간이 짜지 않은가"가 들어갑니다. 같은 요리를 보지만 쓰는 사람의 역할이 다릅니다. 2. 화면이 아니라 기획서에서 출발해야 하는 이유 처음 TC를 쓸 때 가장 쉽게 빠지는 함정이 있습니다. 개발된 화면을 켜 놓고, 보이는 버튼과 입...

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