기획자의 작업대

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

모놀리스와 MSA 차이, 기획서에 녹이는 법 모놀리스와 MSA 차이, 기획서에 녹이는 법 📌 목차 모놀리스 시스템이란 MSA란 무엇인가 모놀리스 vs MSA, 표로 비교하기 실무 팁 3가지 마무리 FAQ 신규 서비스 기획 회의에서 개발팀이 "이건 처음부터 MSA로 가는 게 맞을까요, 아니면 모놀리식으로 시작할까요"라고 물어본 적이 있습니다. 저는 그때 두 단어의 뜻은 어렴풋이 알았지만, 기획서에 뭐라고 반영해야 할지는 감이 안 왔습니다. 결국 "개발팀 판단에 맡기겠습니다"로 넘어갔는데, 몇 달 뒤 기능 하나를 급하게 추가하려다 배포 범위가 예상보다 훨씬 커진 걸 보고서야 그 결정이 기획 초반부터 함께 고민해야 할 사안이었다는 걸 알았습니다. 이번 글에서는 모놀리스와 MSA가 각각 무엇인지, 두 구조가 실무에서 어떻게 다른지, 그리고 그 차이를 기획서에 어떻게 녹여야 하는지 정리해보겠습니다. 1. 모놀리스 시스템이란 모놀리스(Monolith)는 회원, 주문, 결제, 알림 같은 여러 기능이 하나의 코드베이스와 하나의 배포 단위로 묶여 있는 구조입니다. 기능마다 서버를 따로 두지 않고, 애플리케이션 전체를 한 덩어리로 빌드하고 배포합니다. 원룸을 떠올리면 이해가 쉽습니다. 침실, 주방, 거실이 벽으로 나뉘어 있지 않고 한 공간에 모여 있는 구조입니다. 공간을 나누는 절차가 없으니 처음 살림을 차릴 때는 빠르고 간편합니다. 초기 서비스에서 모놀리스를 선택하는 이유도 비슷합니다. 기능 간 호출이 함수 호출 수준으로 끝나기 때문에 개발 속도가 빠르고, 배포도 한 번에 처리되어 관리 포인트가 적습니다. 다만 서비스가 커질수록 기능 하나를 고치기 위해 전체를 다시 빌드하고 배포해야 하고, 특정 기능에서 발생한 장애가 전체 서비스로 번지기 쉽다는 부담이 따라옵니다. 2. M...

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

피그마와 화면설계서 차이, 기획 문서 이렇게 바뀐다 피그마와 화면설계서 차이, 기획 문서 이렇게 바뀐다 IT 기획 · 서비스기획 · 2026.08 기준 작성 피그마로 기획 화면을 작성하고 리뷰 시간에 피그마 링크를 공유했더니, 옆에 있던 PM이 "그럼 화면설계서는 언제 나오나요"라고 물어본 적이 있습니다. 화면을 이미 다 보여줬는데 왜 별도 문서가 또 필요하냐는 질문이었습니다. 이 질문에 제대로 답하지 못하면 결국 두 문서를 이도저도 아니게 만들다가 시간만 낭비하게 됩니다. 오늘은 피그마와 화면설계서가 근본적으로 어떻게 다른지, 그래서 기획 문서 체계를 어떻게 다시 짜야 하는지 정리해보겠습니다. 📌 목차 피그마와 화면설계서는 애초에 만들어진 목적이 다르다 실제 사례: 피그마 링크 하나로 개발팀에 넘겼다가 벌어진 일 두 문서를 가르는 기준: "보여주는 것"과 "정의하는 것" 실무 팁 3가지 마무리 FAQ 피그마와 화면설계서는 애초에 만들어진 목적이 다르다 피그마는 디자인과 프로토타이핑 툴입니다. 화면이 어떻게 보이는지, 화면 사이를 어떻게 이동하는지를 시각적으로 보여주는 데 강점이 있습니다. 이해 관계자에게 서비스의 인상을 빠르게 전달하고 싶을 때 피그마만큼 효율적인 수단은 없습니다. 반면 화면설계서는 전통적으로 그 화면 뒤에 있는 로직을 텍스트로 정의하는 문서였습니다. 이 버튼을 눌렀을 때 어떤 조건이면 어떤 결과가 나오는지, 값이 비어있을 때는 어떻게 처리하는지, 권한에 따라 무엇이 달라지는지 같은 내용입니다. 건축에 비유하면 피그마는 조감도에 가깝고, 화면설계서는 시공 도면에 가깝습니다. 조감도만 보고는 배관이 어디로 지나가는지, 벽이 하중을 어떻게 견디는지 알 수 없습니다. 화면도 마찬가지로, 보이는 모습만으로는 그 안의 동작 조건까지 다 담을...

노션 기본 블록 10가지 완벽 정리 노션 기본 블록 10가지 완벽 정리 기획자의 작업대 · 실무 가이드 📌 목차 텍스트·제목·목록 블록 — 문서의 뼈대 토글·인용·콜아웃 블록 — 정보 밀도 조절 구분선·표·이미지 블록 — 시각적으로 정리하기 실무 팁 3가지 마무리 FAQ 신규 입사자 온보딩 문서를 처음 노션으로 옮겼을 때, 내용을 빠짐없이 담겠다는 생각에 텍스트 블록만 줄줄이 이어 붙인 적이 있습니다. 분명 정보는 다 들어있는데, 며칠 뒤 팀원이 "이 문서 어디서 뭘 봐야 하는지 모르겠다"고 말했습니다. 문제는 내용이 아니라 구조였습니다. 노션은 블록 단위로 문서를 쌓는 도구인데, 저는 블록을 거의 안 쓰고 워드 문서처럼 쓰고 있었던 겁니다. 그날 이후로 상황에 맞는 블록을 골라 쓰는 것만으로 같은 내용도 훨씬 잘 읽히는 문서가 된다는 걸 체감했습니다. 이번 글에서는 기획 업무에서 실제로 자주 쓰게 되는 노션 기본 블록 10가지를 세 그룹으로 나눠 정리했습니다. 각 블록의 개념과 실무 적용법을 함께 설명하겠습니다. 1. 텍스트·제목·목록 블록 — 문서의 뼈대 가장 먼저 익혀야 할 블록은 문서의 골격을 잡는 블록입니다. 이 네 가지만 제대로 써도 문서 가독성이 눈에 띄게 달라집니다. ① 텍스트 블록 노션에서 아무 것도 지정하지 않고 입력하면 만들어지는 기본 블록입니다. 문단 단위로 끊어서 작성하는 용도이며, 모든 블록의 출발점이라고 보면 됩니다. 기획서에서는 배경 설명이나 상세 서술처럼 줄글이 필요한 부분에 사용합니다. ② 제목 블록 (Heading 1 / 2 / 3) 문서 안에 위계를 만드는 블록입니다. `#`은 대제목, `##`은 중제목, `###`는 소제목으로 구분됩니다. 기획서 한 페이지 안에 "배경 - 목표 - 범위 - 일정"처럼 섹션이 여러 개...

노션 기본 사용법: 사이드바부터 블록까지 노션 기본 사용법: 사이드바부터 블록까지 📌 목차 노션 처음 켰을 때 다들 헤매는 이유 노션 화면의 3단 구조: 사이드바·페이지·블록이 뭔가 사이드바 제대로 이해하기 페이지, 어디까지가 하나의 단위인가 블록의 진짜 의미 실무 팁 3가지 마무리 자주 묻는 질문 노션 처음 켰을 때 다들 헤매는 이유 제가 처음 노션을 접했을 때 당황했던 기억이 있습니다. 노션 워크스페이스에 초대받고 화면을 열었더니 사이드 바에는 이미 수십 개의 페이지가 나열돼 있었고, 어디에 무엇을 써야 할지 감이 안 잡혔습니다. 기획 문서를 하나 만들었는데, 알고 보니 팀 전체가 보는 상위 페이지 밑이 아니라 제 개인 페이지 안에 묻혀 있었던 적도 있습니다. 이런 문제는 대부분 도구 자체보다 화면 구조를 제대로 이해하지 못한 데서 시작됩니다. 노션은 사이드바, 페이지, 블록이라는 세 가지 개념이 서로 맞물려 동작하는데, 이 관계를 모르면 아무리 기능을 익혀도 문서가 계속 흩어지게 됩니다. 노션 화면의 3단 구조: 사이드바·페이지·블록이 뭔가 노션 화면은 크게 세 단으로 나뉩니다. 왼쪽의 사이드바는 전체 문서함으로 가는 내비게이션 역할을 하고, 그 안에서 클릭해 들어가는 각각의 문서가 페이지입니다. 그리고 페이지 안의 텍스트, 표, 이미지, 체크박스 같은 모든 콘텐츠 조각이 블록입니다. 이 세 가지는 포함 관계로 이해하면 쉽습니다. 사이드바는 여러 페이지를 담고, 페이지는 여러 블록을 담습니다. 반대로 블록을 페이지로 승격시키거나, 페이지를 사이드바의 특정 위치로 옮기는 것도 자유롭게 가능합니다. 사이드바 제대로 이해하기 사이드바는 책장에 비유하면 이해가 빠릅니다. 책장 칸마다 분야를 나눠 책을 꽂듯이, 사이드바에도 워크스페이스 상단 고정 영역, 즐겨찾기,...

노션 튜토리얼: 가입 후 첫 페이지 만드는 법 노션 튜토리얼: 가입 후 첫 페이지 만드는 법 노션 회원가입부터 워크스페이스 설정, 첫 페이지 생성까지 한 번에 정리했습니다. 기획자가 실무에 바로 적용할 수 있도록 단계별로 안내합니다. 📌 목차 들어가며 노션 회원가입하기 (계정 생성) 워크스페이스 이해하기 — 개인용 vs 팀용 첫 페이지 만들기 실습 실무 팁 3가지 마무리 FAQ 들어가며 기획자로 일하면서 협업 문서 정리 때문에 골머리를 앓은 적 많으실 겁니다. 저도 처음 노션을 켰을 때 빈 화면만 보고 뭘 어디서부터 해야 할지 몰라 한참 헤맸던 기억이 있습니다. 이 글에서는 노션 회원가입부터 첫 페이지를 만들기까지의 과정을 순서대로 정리했습니다. 노션 회원가입하기 (계정 생성) 노션 회원가입은 이메일, 구글 계정, 애플 계정 중 하나로 진행할 수 있습니다. 회사 업무용으로 쓸 계획이라면 개인 이메일보다는 회사 이메일로 가입하는 걸 추천합니다. 나중에 팀 워크스페이스로 전환하거나 멤버를 초대할 때 계정 관리가 훨씬 수월해지기 때문입니다. 가입 절차는 이메일 인증 한 번이면 끝나고, 별도의 복잡한 설정은 필요 없습니다. 마치 새 다이어리를 사는 것과 비슷한데, 다이어리 자체보다는 그 안에 어떻게 내용을 채울지가 더 중요한 것처럼 노션도 가입 자체보다 이후 활용이 핵심입니다. 워크스페이스 이해하기 — 개인용 vs 팀용 워크스페이스는 노션에서 모든 페이지와 문서가 담기는 하나의 공간 단위입니다. 개인용 워크스페이스는 혼자 쓰는 메모장에 가깝고, 팀 워크스페이스는 여러 명이 동시에 접근하고 편집하는 공유 사무실에 가깝습니다. 기획 업무를 예로 들면, 개인 워크스페이스는 회의 전에 혼자 생각을 정리하는 노트에 해당하고, 팀 워크스페이스는 회의 후 합의된 내용을 팀원 모두가 볼 수 있게...