기획자의 작업대

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

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

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

피그마 개발 전달 기준, 화면 선별하는 법 피그마 개발 전달 기준, 화면 선별하는 법 기획자의 작업대 · 실무 가이드 스프린트 막바지에 화면 30장을 한꺼번에 개발자에게 넘긴 적이 있습니다. 일정이 촉박해서 "일단 다 넘기고 보자"는 생각이었는데, 그중 절반은 빈 값이나 에러 상태가 정의되지 않은 화면이었습니다. 개발자가 화면마다 "이 경우엔 뭘 보여줘야 하나요"를 하나씩 물어오기 시작하면서, 전달이 아니라 문답이 되어버렸습니다. 그날 이후로 화면을 넘기기 전에 반드시 확인하는 기준을 따로 만들어두게 됐습니다. 이번 글에서는 어떤 화면을 먼저 넘기고 어떤 화면은 보류해야 하는지, 그 기준을 어떻게 잡는지 정리해보겠습니다. 📌 목차 개발 전달 기준, 무엇을 봐야 할까 화면 선별 기준 적용해보기 실무 팁 3가지 마무리 FAQ 1. 개발 전달 기준, 무엇을 봐야 할까 화면을 넘길지 말지는 "다 그렸는가"가 아니라 "개발자가 이 화면만 보고 구현할 수 있는가"로 판단해야 합니다. 이 질문에 답하려면 세 가지 축을 확인하면 됩니다. ① 화면 상태가 다 정의됐는가 정상 상태 화면 한 장만으로는 부족합니다. 데이터가 없을 때, 로딩 중일 때, 에러가 났을 때 화면이 각각 어떻게 보이는지까지 있어야 합니다. 이 세 가지가 빠진 화면은 겉으로는 완성돼 보여도 실제로는 절반짜리 화면입니다. ② 인터랙션과 분기 스펙이 명확한가 버튼을 눌렀을 때 어디로 이동하는지, 조건에 따라 다른 화면을 보여줘야 하는지가 화면만 봐서는 알기 어려운 경우가 많습니다. 이 부분이 명확하지 않으면 개발자는 임의로 추측해서 구현하게 되고, 나중에 다시 고쳐야 할 확률이 높아집니다. ③ 예외 케이스까지 화면에 반영됐는가 이 글은 2026.09 기준으로 작성...

정책서가 필요한 이유, 피그마만으론 안 되는 것 정책서가 필요한 이유, 피그마만으론 안 되는 것 예전에 화면 프레임 한쪽에 "이 조건이면 예외 처리"라고 텍스트로 적어둔 적이 있습니다. 급하게 넘긴 화면이라 정식 문서로 뺄 여유가 없었고, 어차피 나만 보면 되는 메모라고 생각했습니다. 몇 주 뒤 화면을 리디자인하면서 그 프레임을 통째로 지웠는데, 예외 조건도 같이 사라졌습니다. 개발자가 "그때 말씀하신 예외 케이스, 어디 적혀 있나요"라고 물었을 때에야 그 메모가 정책서 역할을 하고 있었다는 걸 깨달았습니다. 이번 글에서는 피그마로 정책 내용을 관리하는 게 왜 한계에 부딪히는지, 그리고 화면과 정책 문서를 어떻게 나눠야 오래 버티는지 정리해보겠습니다. 📌 목차 1. 피그마로도 정책서를 만들 수는 있다 2. 그런데 왜 오래 못 버틸까 3. 화면과 정책, 이렇게 나눠보세요 4. 실무 팁 3가지 5. 마무리 6. FAQ 1. 피그마로도 정책서를 만들 수는 있다 먼저 짚고 넘어갈 부분이 있습니다. 피그마 안에서 정책 내용을 정리하는 것 자체는 충분히 가능합니다. 방법도 여러 가지입니다. ① 텍스트 프레임 화면 옆에 별도 프레임을 만들고 조건, 예외 케이스, 분기 로직을 텍스트로 적어두는 방식입니다. 화면과 같은 캔버스에 있어서 참조하기 편하다는 장점이 있습니다. ② FigJam 보드 포스트잇 형태로 정책 항목을 나열하고, 화살표로 조건과 결과를 연결하는 방식입니다. 브레인스토밍 단계에서 정책 초안을 잡을 때는 특히 유용합니다. ③ Dev Mode 주석 개발자에게 전달할 화면에 주석을 달아 특정 컴포넌트의 동작 조건을 설명하는 방식입니다. 화면과 설명이 1:1로 붙어 있어서 전달 누락이 적은 편입니다. 이 글은 2026.08 기준으로 작성되었으며, 피그마 기능은 계속 업...