비전공자도 쉽게 배우는 피그마: 기획자 실무 활용 A to Z

저는 피그마(Figma)를 처음부터 “그림 그리는 툴”로 보진 않았어요. 오히려 요구사항을 시각화하고 팀이 같은 화면을 보게 만드는 협업 도구라고 생각했습니다. 그래서 이번 글에서는 “피그마를 기획자가 어떻게 써야 일이 빨라지는가”에 초점을 맞춰, 제가 실무에서 굴리며 다듬은 루틴과 템플릿을 공유해 보려고 합니다.

1) 문서보다 먼저, 한 화면에서 합의 만들기

기획서가 아무리 정교해도 회의 때 서로 다른 화면을 떠올리면 합의가 늦어지더라고요. 그래서 저는 피그마 한 화면에서 흐름·요구사항·제약을 동시에 보여주는 방식으로 시작합니다.

Flow 페이지: 사용자 여정(진입 → 행동 → 결과)을 간단한 박스와 화살표로 먼저 그립니다. 이름은 “F-01 가입 플로우”처럼 접두어로 정렬 가능하게.
Wire 페이지: 플로우의 각 노드를 와이어프레임으로 펼칩니다. 처음엔 회색 사각형·텍스트만. 색과 아이콘은 나중.
Notes 레일: 화면 오른쪽 240px 가량을 비워 “요구/제약/오픈이슈” 섹션을 세로로 고정해 둡니다. 누구든 열면 같은 위치에서 맥락을 읽게 됩니다.

이렇게 하면 회의에서 “이건 어디서부터 시작하죠?”라는 질문이 줄고, 플로우 → 화면 → 논의가 한 번에 이어집니다.

2) 기획자에게 필요한 오토 레이아웃의 ‘딱 세 가지’

오토 레이아웃을 깊게 파기보다, 기획에 필요한 최소만 씁니다.

간격 통일: 카드, 리스트에 Gap 8/12/16 같은 통일된 숫자만 사용. 팀에서 정한 단위 외엔 쓰지 않기.
Padding 규칙: 상하/좌우를 12·16 등으로 고정해 “가변 텍스트에도 영역이 흔들리지 않게” 만듭니다.
Direction 전환: 모바일 세로 리스트를 데스크톱 가로 카드 그리드로 바꿀 때 방향만 바꿔도 덜 무너지도록 설계합니다.

이 세 가지만 지켜도 회의 중 즉석 수정이 쉬워지고, 디자이너가 상세 디자인으로 넘길 때 구조가 안정적입니다.

3) 컴포넌트는 ‘재사용’보다 ‘의사소통’을 위해 만든다

기획 단계의 컴포넌트는 미학보다 의미가 중요합니다. 저는 아래처럼 이름을 붙입니다.

cmp/btn/primary/cta : 주요 행동 버튼
cmp/input/email/with-helper : 헬퍼 텍스트 포함 입력
cmp/alert/error/inline : 인라인 에러 알림

이렇게 해두면 개발이 “이건 어떤 상태들이 있죠?”라고 물을 때, Variants로 enabled/disabled/loading을 바로 보여줄 수 있습니다. 말로 5분 설명할 걸, 토글로 10초 만에 합의합니다.

4) 주석은 ‘문장’보다 ‘형식’이 답이다

예전엔 주석을 문단으로 썼는데, 나중에 제가 쓴 것도 못 찾겠더라고요. 그래서 형식을 고정했습니다.

[REQ] 사용자 이메일은 선택 입력 (A/B 테스트중)
[VAL] 이메일 형식 정규식: RFC5322 간소화 버전
[ERR] 중복 이메일 입력 시 <inl-err-01> 노출
[EVT] 제출 클릭 시 event_signup_submitted 트래킹
[Q] 7일 미접속 유저도 동일 플로우? (오픈)

REQ/VAL/ERR/EVT/Q 같은 접두어만 팀과 합의해 두면, 긴 문서보다 검색이 빠르고, PM·개발·데이터가 각자 필요한 정보만 훑어가기도 좋습니다.

5) 댓글 규칙: 이슈 트래킹은 “@사람 + 라벨 + 기한”

피그마 댓글은 금방 흘러가요. 그래서 이슈성 댓글은 꼭 이렇게 남깁니다.

[BUG] @dev_lee 데스크톱 1280에서 CTA가 접힘. 재현 스크린샷 첨부. DUE 9/5

라벨: [BUG], [BLOCK], [DECISION], [QUESTION]
책임자 명시: @멘션으로 소유권 분명히
기한: DUE 표기(팀 채널에 리마인드 봇 연동해도 좋음)

나중에 회고할 때도 “무엇이 막혔고, 누가 풀었는지”가 딱 보입니다.

6) 페이지 설계: ‘한 파일, 한 프로젝트, 같은 숨결’

프로젝트마다 파일 구조를 동일하게 가져가면, 합류한 사람이 길을 잃지 않습니다. 제가 쓰는 기본 골격은 이렇습니다.

00_COVER: 목표, 범위, KPI, 담당자, 최근 업데이트 날짜
10_FLOW: 사용자 여정 다이어그램
20_WIRE: 와이어프레임(스크린 번호는 W-101 같은 3자리로)
30_SPECS: 데이터·룰·에러 메시지 표
90_ARCHIVE: 폐기안, 이전 버전

스크린 번호와 커버의 업데이트 로그만 지켜도 “최신안이 어디죠?”가 사라집니다.

7) 텍스트 시스템: 오류 메시지는 초기에 ‘표’로 만든다

에러 문구가 가장 늦게 정해지고 가장 오래 남더라고요. 그래서 초기에 표로 못 박습니다.

코드	상황	메시지	노출 위치	트래킹
inl-err-01	이메일 형식 불일치	올바른 이메일 형식을 입력해 주세요.	입력 필드 하단	err_email_format
dlg-err-02	서버 타임아웃	요청이 지연되고 있어요. 잠시 후 다시 시도해 주세요.	모달	err_signup_timeout

피그마에 이 표를 붙여두면 디자이너는 위치를, 개발은 코드·키를, 데이터는 이벤트 명세를 한 번에 확인합니다.

8) 디자인 시스템과의 거리 조절

기획 단계에서 디자인 시스템을 100% 반영하려다 속도가 죽을 때가 있습니다. 그래서 저는 “구조는 따르고, 시각은 대충” 원칙을 씁니다.

버튼·입력 필드는 시스템의 높이와 간격만 맞춘 더미 컴포넌트 사용
색상·아이콘은 나중에 디자이너가 교체할 수 있도록 토큰 이름만 메모
새로운 패턴이 필요하면 [PROPOSED] 태그로 제안 영역 분리

속도와 일관성을 동시에 지키는 타협점이더군요.

9) 실수담: “그 화면, 나만 알아보는 번호였네”

한 번은 저만 쓰던 화면 번호 체계 때문에 QA가 혼란을 겪었습니다. 저는 내부 문서에선 “가입-1”, 피그마에선 “S-12”라고 부르고 있었거든요. 그 뒤로 피그마 번호가 진리가 되게 했습니다. 슬랙·지라·테스트 케이스까지 모두 S-12로 통일. 작은 합의가 큰 비용을 막았습니다.

10) 제 루틴, 그대로 가져가셔도 됩니다

커버 작성(10분): 목표·KPI·범위·담당자·업데이트 날짜
플로우 러프(30분): 박스+화살표, 메이저 분기만
와이어 러프(60분): 사각형+텍스트, Notes 레일 확보
주석 표준화(30분): REQ/VAL/ERR/EVT/Q로 첫 패스
컴포넌트화(30분): 버튼/입력/알림만 우선
코멘트 수습(20분): [DECISION] 합의는 본문으로 승격, 나머진 기한 지정

이 루틴으로 움직이면 첫 주에 “보여줄 수 있는 상태”가 금방 나옵니다. 이후는 팀의 피드백 속도로 가속이 붙고요.

피그마는 결국 팀이 같은 장면을 보게 만드는 무대라고 느꼈습니다. 그 무대 위에서 누가 무엇을 언제 바꾸는지 선명해질수록, 기획은 덜 말하고 더 빨리 합의할 수 있습니다. 오늘 공유한 루틴이 여러분 팀의 속도를 조금이라도 올려주면 좋겠어요.

저작자표시 비영리 변경금지 (새창열림)

기획꿈나무의 IT 이야기