기획자의 작업대

피그마 사용법, 기획자 화면설계 기본 기능 피그마 사용법, 기획자 화면설계 기본 기능 IT 서비스 기획자가 알아야 할 피그마 기본 기능을 쇼핑몰 마이페이지 실습을 통해 정리합니다. 화면설계서를 작성할 때 중요한 것은 디자인 도구를 얼마나 능숙하게 사용하는지가 아니라 기획 의도를 얼마나 명확하게 표현하는지입니다. 실무에서 화면설계서를 작성하다 보면 버튼 하나를 추가하거나 메뉴 위치를 변경하는 것만으로도 기존 화면과 기능 설명을 함께 수정해야 하는 경우가 많습니다. 저는 이런 작업에서 중요한 것이 화면 요소의 역할을 명확하게 구분하고 변경하기 쉬운 구조로 관리하는 것이라고 생각합니다. 이번 글에서는 피그마의 모든 기능을 배우기보다 IT 기획자가 화면설계서를 작성할 때 자주 사용하는 기능 부터 익히겠습니다. 1일 차에 만든 쇼핑몰 마이페이지를 그대로 활용하므로 실습 결과물이 다음 글로 이어집니다. 📌 목차 피그마 작업 화면 이해하기 기획자가 사용하는 기본 도구 프레임과 레이어 구조 관리하기 기능 설명 작성하기 쇼핑몰 마이페이지 실습 실습 결과물 검수 실무 팁 3가지 자주 묻는 질문 마무리 1. 피그마 작업 화면 이해하기 피그마에서 화면설계서를 작성하려면 먼저 작업 화면의 구조를 이해해야 합니다. 기획자가 주로 사용하는 영역은 왼쪽 패널, 툴바, 캔버스, 오른쪽 속성 패널입니다. 영역 주요 역할 기획자 활용 예시 왼쪽 패널 페이지와 레이어 관리 화면 ID 및 기능별 영역 관리 툴바 도구 선택 프레임, 도형, 텍스트 생성 ...

피그마 반응형 화면설계서, 기획자 관점 작성법 피그마 반응형 화면설계서, 기획자 관점 작성법 피그마로 쇼핑몰 마이페이지의 PC·모바일 화면을 설계하고, IT 서비스 기획자 관점에서 기능과 반응형 정책을 정의하는 과정을 알아봅니다. 반응형 웹 프로젝트를 진행하다 보면 PC 화면을 모바일에서 어떻게 보여줄지 결정해야 하는 상황을 자주 만납니다. PC에서 사용하던 메뉴를 모바일에서는 어떻게 제공할지, 주문 내역 테이블을 작은 화면에서도 유지할지, 어떤 정보를 먼저 보여줄지 고민하게 됩니다. 저는 이런 화면설계 작업에서 화면을 그리는 것만큼 화면이 바뀌는 조건과 기능의 동작을 정의하는 일 이 중요하다고 생각합니다. 이번 글에서는 피그마(Figma)를 활용해 쇼핑몰 마이페이지의 PC·모바일 화면설계서를 처음부터 작성해 보겠습니다. 디자이너를 위한 시각 디자인 강좌가 아닙니다. IT 서비스 기획자가 화면 구조를 만들고 기능과 정책을 정리하는 과정에 집중하겠습니다. 📌 목차 기획자가 피그마를 사용하는 이유 반응형 화면설계에서 정의할 내용 실습 전 준비 사항 쇼핑몰 마이페이지 화면설계 실습 반응형 정책 작성 방법 실무 팁 3가지 자주 묻는 질문 마무리 1. 기획자가 피그마를 사용하는 이유 IT 서비스 기획자의 화면설계서는 사용자가 어떤 정보를 확인하고, 어떤 기능을 실행하며, 그 결과 어떤 화면으로 이동하는지 설명하는 문서입니다. 피그마를 사용하면 PC와 모바일 화면을 하나의 작업 공간에 배치하고 비교할 수 있습니다. 또한 화면 구성 요소와 정책을 함께 관리하면서 디자이너, 개발자와 협업할 수 있습니다. 디자이너와 기획자의 관점은 다릅니다 구분 디자이너 관점 기획자 관점 ...

피그마 학습, 기획자는 어디까지 배울까 피그마 학습, 기획자는 어디까지 배울까 기획자의 작업대 · 실무 가이드 처음 피그마를 켰을 때, 왼쪽 사이드바에 늘어선 아이콘들을 보고 뭐부터 눌러야 할지 몰라 한참을 멍하니 있었던 기억이 있습니다. 그 주 주말에 유튜브 강의를 몇 개나 정주행했는데, 막상 실무에 들어가 보니 배운 내용을 모두 사용하지는 않았습니다. 반대로 어떤 동료는 딱 필요한 기능 몇 가지만 익히고도 개발자, 디자이너와의 커뮤니케이션에서 전혀 막힘이 없었습니다. 그 차이를 겪고 나서, "얼마나 배워야 충분한가"에 대한 기준이 사람마다 다르다는 걸 알게 됐습니다. 이번 글에서는 기획자 입장에서 피그마를 어디까지 배워야 실무에 지장이 없는지, 단계별로 정리해보겠습니다. 📌 목차 피그마 학습이 끝없이 느껴지는 이유 기획자를 위한 3단계 학습 로드맵 실무 팁 3가지 마무리 FAQ 1. 피그마 학습이 끝없이 느껴지는 이유 피그마 강의나 공식 문서를 펼쳐보면 배울 게 끝이 없어 보입니다. 컴포넌트, 오토레이아웃, Variables, 플러그인, 디자인 시스템 구축까지 목록이 계속 이어지기 때문입니다. 이건 피그마가 하나의 툴이 아니라 성격이 다른 두 가지 역할을 한 앱 안에 담고 있기 때문입니다. 하나는 화면을 그리고 다듬는 "디자인 제작" 기능이고, 다른 하나는 그 결과물을 팀과 주고받는 "협업" 기능입니다. 자동차에 비유하면 운전면허와 레이싱 기술의 차이와 비슷합니다. 도로에서 안전하게 이동하는 데 필요한 건 면허 수준의 지식이지, 트랙에서 최고 속도로 코너를 도는 레이싱 기술이 아닙니다. 둘 다 같은 차를 다루지만, 훈련 목적과 범위가 완전히 다릅니다. 기획자에게 피그마가 끝없이 느껴지는 이유는, 이 둘을 구분하지 않고...

PPT 기획자가 피그마에서 자주 하는 실수 7가지 PPT 기획자가 피그마에서 자주 하는 실수 7가지 기획자의 작업대 · 실무 가이드 📌 목차 슬라이드 감각 그대로 피그마를 켰던 날 PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT 기획자가 자주 하는 실수 7가지 실무 팁 3가지 마무리 FAQ 1. 슬라이드 감각 그대로 피그마를 켰던 날 처음 피그마로 화면 기획서를 만들던 날, 저는 습관대로 화면을 한 장씩 새로 그렸습니다. PPT에서 슬라이드를 복제하고 텍스트만 바꾸던 방식 그대로, 피그마에서도 프레임을 복사해서 문구만 고쳐나갔습니다. 문제는 열 번째 화면쯤에서 터졌습니다. 버튼 색을 하나 바꿔야 하는데, 그 버튼이 들어간 화면이 몇 개인지조차 파악이 안 됐습니다. 결국 화면을 하나하나 열어서 같은 버튼을 스무 번 넘게 고쳐야 했습니다. 디자이너가 그 모습을 보고 "컴포넌트로 만들어두지 그러셨어요"라고 했을 때, 저는 그게 정확히 뭘 의미하는지도 몰랐습니다. 이번 글에서는 저처럼 PPT 감각으로 피그마를 시작한 기획자가 자주 걸리는 실수 7가지를 정리해보겠습니다. 2. PPT와 피그마는 애초에 만들어진 목적이 다르다 PPT는 한 장 한 장이 독립된 결과물입니다. 슬라이드끼리 데이터를 공유하지 않아도 발표라는 목적은 그대로 달성됩니다. 반면 피그마는 화면끼리 서로 연결되고 재사용되는 것을 전제로 설계된 도구입니다. 비유하자면 PPT는 낱장으로 인쇄하는 전단지에 가깝고, 피그마는 부품을 조립해서 완성하는 가구 설계도에 가깝습니다. 전단지는 한 장씩 새로 디자인해도 상관없지만, 가구는 같은 나사와 경첩을 여러 군데서 재사용해야 조립도 수리도 쉬워집니다. 이 차이를 모르고 PPT 하던 방식 그대로 피그마를 쓰면, 화면은 늘어나는데 관리는 점점 힘들어지는 상황을...

피그마·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 기준으로 작성...

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