기획자의 작업대

피그마·Jira 연동, 기획 협업흐름 잡는 법 피그마·Jira 연동, 기획 협업흐름 잡는 법 📌 목차 화면, 이슈, 근거가 각자 따로 노는 순간 세 도구는 원래 역할이 다르다 실제로 겪은 어긋남 참조 구조로 연결하는 법 실무 팁 3가지 마무리 FAQ 1. 화면, 이슈, 근거가 각자 따로 노는 순간 피그마에 화면을 올리고, Jira에 이슈를 만들고, Confluence에 정책을 적어두면 협업이 저절로 될 거라 생각한 적이 있습니다. 막상 스프린트가 돌아가기 시작하니 세 곳의 내용이 서로 다른 이야기를 하고 있었습니다. 개발자는 Jira 이슈만 보고 작업했는데, 그 이슈에는 이틀 전 수정된 피그마 화면이 링크되어 있지 않았습니다. 결국 QA 단계에서 "이 버튼 위치가 왜 이렇게 됐냐"는 질문이 나왔고, 저는 세 곳을 오가며 어디서부터 어긋났는지 확인해야 했습니다. 이번 글에서는 피그마, Jira, Confluence가 각각 어떤 역할을 맡아야 하는지, 그리고 세 곳을 어떻게 연결해야 이런 어긋남이 줄어드는지 정리해보겠습니다. 2. 세 도구는 원래 역할이 다르다 세 도구를 연동한다고 하면 흔히 자동화 플러그인부터 떠올리지만, 그 전에 각 도구가 무엇을 담당하는지부터 명확히 해야 합니다. 역할이 겹치면 연동을 아무리 걸어도 정보가 어디 있는지 헷갈리는 문제는 그대로 남습니다. 도구 담당 영역 생명주기 Figma 화면의 최신 모습, 인터랙션, 스타일 자주 바뀜 Jira 지금 진행 중인 작업 단위, 담당자, 상태 작업이 끝나면 종료 Confluence 왜 이렇게 결정했는지에 대한 근거와 정책 사업 규칙이 바뀔 때만 갱신 정리하면 Figma는 "지금 화면이 어떻게 생겼는가", Jira는 "지금 무엇을 ...

피그마 Dev Mode란? 기획자가 알아둘 기능 피그마 Dev Mode란? 기획자가 알아둘 기능 📌 목차 피그마 Dev Mode란 무엇인가 기획자 관점에서 적용하는 법 실무 팁 3가지 마무리 FAQ 화면 시안을 캡처해서 슬랙으로 개발자에게 보낸 적이 있습니다. "이 여백 몇 px이에요", "이 회색 색상 코드가 뭐예요" 같은 질문이 하루 종일 따라왔고, 저는 매번 피그마를 열어 자로 재듯 확인해서 답을 보냈습니다. 나중에서야 피그마 안에 이런 질문 자체를 없애주는 모드가 따로 있다는 걸 알게 됐습니다. 바로 Dev Mode입니다. 이번 글에서는 Dev Mode가 정확히 무엇이고, 디자이너나 개발자가 아닌 기획자가 왜 이걸 알아둬야 하는지 정리해보겠습니다. 1. 피그마 Dev Mode란 무엇인가 Dev Mode는 피그마 화면 우측 상단 토글로 켤 수 있는 별도 작업 모드입니다. 평소 쓰는 디자인 모드가 "화면을 그리고 다듬는 용도"라면, Dev Mode는 "그 화면을 구현하는 데 필요한 정보를 뽑아내는 용도"에 가깝습니다. 비유하자면 인테리어 완성 사진과 시공 도면의 차이와 비슷합니다. 완성 사진만 보고는 벽 두께나 배관 위치를 알 수 없듯이, 디자인 모드 화면만 보고는 여백 값이나 색상 코드, 컴포넌트 상태값을 정확히 알기 어렵습니다. Dev Mode는 그 도면 역할을 합니다. Dev Mode의 핵심 구성 요소 기능 설명 Inspect 패널 선택한 요소의 여백, 크기, 색상, 폰트 등 스펙을 자동으로 보여줍니다. 코드 스니펫 CSS, iOS, Android 등 언어별 코드를 자동으로 생성해 보여줍니다. 에셋 추출 아이콘, 이미지 등을 개발에 필요한 해상도와 포맷으로 바로 내려받을 수 있습니다. 주석(...

피그마 개발 전달 기준, 화면 선별하는 법 피그마 개발 전달 기준, 화면 선별하는 법 기획자의 작업대 · 실무 가이드 스프린트 막바지에 화면 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) 문서 안에 위계를 만드는 블록입니다. `#`은 대제목, `##`은 중제목, `###`는 소제목으로 구분됩니다. 기획서 한 페이지 안에 "배경 - 목표 - 범위 - 일정"처럼 섹션이 여러 개...