실무에서 바로 쓰는 피그마 운영 습관

좋은 피그마 파일은 다시 열었을 때 설명하지 않아도 보인다

피그마를 처음 배울 때는 기능 하나하나가 크게 느껴집니다. 프레임을 만들고, Auto Layout을 걸고, Components를 만들고, Prototype을 연결하는 것만으로도 충분히 많은 일을 해낸 것 같습니다. 하지만 실무에서는 한 가지 질문이 더 붙습니다.

"이 파일을 다른 사람이 열어도 바로 이해할 수 있을까?"

초보를 벗어나는 기준은 기능을 많이 아는 것이 아닙니다. 팀이 신뢰할 수 있는 파일을 만드는 것입니다. 버튼을 예쁘게 만드는 것도 중요하지만, 그 버튼이 어디에 있는지, 최신 버전이 무엇인지, 더 이상 쓰면 안 되는 컴포넌트는 무엇인지, 개발자에게 전달된 화면은 어떤 것인지 명확해야 합니다.

좋은 피그마 파일은 책상 정리와 비슷합니다. 물건이 많아도 제자리에 있으면 어지럽지 않습니다. 반대로 화면이 몇 개 없어도 이름이 Frame 123, Rectangle 88, Copy of Copy로 가득하면 작은 수정에도 시간이 오래 걸립니다. 이 장에서는 파일을 오래 유지하고, 팀에서 재사용하며, 다음 프로젝트에도 다시 꺼내 쓸 수 있게 만드는 운영 습관을 정리합니다.

파일 운영 기준: 페이지가 곧 팀의 지도다

피그마 파일을 열었을 때 가장 먼저 보이는 것은 페이지 목록입니다. 페이지 구조가 정리되어 있으면 팀원은 "어디서 봐야 하지?"라는 질문 없이 바로 작업 위치를 찾을 수 있습니다. 반대로 페이지 이름이 날짜별로만 쌓여 있거나, 개인 이름과 임시 페이지가 뒤섞여 있으면 파일은 빠르게 창고가 됩니다.

실무에서는 페이지를 "작업 단계"와 "역할"에 따라 나누는 방식이 가장 안정적입니다. 숫자를 앞에 붙이면 페이지 순서가 흐트러지지 않아 편합니다.

모든 프로젝트가 이 구조를 그대로 따라야 하는 것은 아닙니다. 중요한 것은 팀이 "어떤 페이지에 무엇이 있는지" 같은 기준을 공유하는 것입니다. 작은 프로젝트라면 Cover, Design, Components, Archive 정도로 시작해도 충분합니다. 페이지가 너무 많으면 오히려 찾기 어려워지므로, 처음에는 단순하게 시작하고 프로젝트가 커질 때만 나누는 편이 좋습니다.

TIP | Cover 페이지는 파일의 현관입니다
00_Cover에는 파일 이름만 크게 쓰지 말고, 이 파일을 처음 여는 사람이 알아야 할 정보를 함께 둡니다. 프로젝트 목적, 담당자, 마지막 업데이트 날짜, 현재 상태, 관련 문서 링크, 개발 전달 여부를 적어 두면 회의 때마다 설명하는 시간을 줄일 수 있습니다.

페이지 안에서는 섹션을 적극적으로 사용합니다. 섹션은 화면들을 묶는 큰 박스입니다. 예를 들어 로그인, 온보딩, 홈, 마이페이지처럼 기능 단위로 섹션을 나누면, 넓은 캔버스에서도 길을 잃지 않습니다. 작업 상태를 섹션 이름에 함께 적는 것도 좋습니다.

상태 이름은 팀마다 다를 수 있습니다. 다만 WIP, Review, Ready for Dev, Released, Deprecated처럼 한눈에 의미가 드러나는 단어를 쓰면 좋습니다. 피그마 파일은 그림만 담는 곳이 아니라 의사결정의 현재 위치를 보여 주는 지도이기 때문입니다.

네이밍 규칙: 이름은 미래의 동료에게 보내는 메모다

레이어 이름을 정리하는 일은 귀찮습니다. 지금 당장은 디자인에 아무 영향도 없어 보입니다. 하지만 파일이 커지고 협업자가 늘어나면 이름은 곧 속도가 됩니다. 개발자가 Dev Mode에서 레이어를 확인할 때, 기획자가 특정 화면을 찾을 때, 디자이너가 컴포넌트를 교체할 때 이름이 정리되어 있으면 불필요한 질문이 줄어듭니다.

가장 피해야 할 이름은 피그마가 자동으로 붙여 준 이름을 그대로 두는 것입니다. Frame 42, Group 17, Rectangle 9는 만든 사람에게도 며칠 뒤에는 의미가 없습니다. 모든 레이어를 완벽하게 이름 붙일 필요는 없지만, 화면 구조를 이해하는 데 중요한 프레임, 컴포넌트, 버튼, 입력창, 아이콘, 이미지 영역은 반드시 의미 있는 이름을 붙입니다.

화면 프레임은 기능 / 화면 / 상태 순서로 이름을 붙이면 찾기 쉽습니다. 예를 들어 Order / Checkout / Empty, Order / Checkout / Error, Order / Complete / Success처럼 적으면 어떤 흐름의 어떤 상태인지 바로 보입니다. 디자인 파일이 개발 명세와 연결될 때도 이 방식은 유용합니다.

컴포넌트 이름은 종류와 역할이 드러나야 합니다. 버튼이라면 Button / Primary, Button / Secondary, Button / Text처럼 나눌 수 있습니다. 입력창이라면 Input / Text, Input / Password, Input / Search처럼 구분합니다. Figma의 Assets 패널에서는 슬래시(/)를 기준으로 컴포넌트가 그룹처럼 정리되므로, 이름을 잘 붙이는 것만으로도 작은 라이브러리 구조가 만들어집니다.

단축키 박스 | 이름 정리 루틴
⌘ R 또는 Ctrl R로 선택한 레이어 이름을 바꿀 수 있습니다. 여러 레이어를 정리할 때는 중요한 프레임부터 이름을 붙이고, 그다음 컴포넌트와 인터랙션 요소를 정리하세요. 모든 사각형의 이름을 바꾸는 것보다, 팀원이 실제로 찾게 될 대상을 먼저 정리하는 것이 실무적입니다.

네이밍에서 중요한 또 하나의 기준은 언어입니다. 한 파일 안에서 Button, 버튼, Btn, button_new가 섞이면 검색이 어려워집니다. 팀이 한국어를 주로 쓰더라도 컴포넌트와 속성 이름은 영어로 통일하는 경우가 많습니다. 개발 코드와 연결하기 쉽기 때문입니다. 반대로 화면 제목이나 기획 설명은 한국어가 더 이해하기 쉬울 수 있습니다. 핵심은 어느 쪽이든 한 파일 안에서 기준을 유지하는 것입니다.

컴포넌트는 한곳에 모으고, 임시 요소는 임시라고 표시한다

Components는 반복 UI를 재사용하기 위한 기능입니다. 그런데 컴포넌트를 아무 곳에서나 만들고 그대로 두면 시간이 지날수록 "진짜 버튼이 어디 있지?"라는 문제가 생깁니다. 그래서 실무 파일에서는 메인 컴포넌트의 위치를 분명히 정합니다.

가장 단순한 기준은 05_Components 페이지에 메인 컴포넌트를 모아 두는 것입니다. 화면 디자인 페이지에는 인스턴스만 사용하고, 원본은 Components 페이지에서 관리합니다. 이렇게 하면 버튼의 높이, 입력창의 상태, 카드의 구조가 바뀔 때 원본을 찾기 쉽습니다.

컴포넌트 페이지 안에서는 종류별 섹션을 만듭니다.

작은 프로젝트에서는 이 정도까지 세분화하지 않아도 됩니다. 하지만 버튼과 입력창처럼 반복 사용이 많은 요소는 초반부터 따로 관리하는 것이 좋습니다. 나중에 정리하려고 하면 이미 수십 개 화면에 복사본이 흩어져 있을 가능성이 높습니다.

컴포넌트를 만들 때는 "완성된 것만 컴포넌트로 만든다"는 생각을 조금 내려놓아도 됩니다. 실무에서는 반복될 것 같다면 일찍 컴포넌트로 만들고, 이름에 상태를 표시해 관리하는 편이 낫습니다. 예를 들어 아직 검토 중인 컴포넌트라면 WIP / Button / Primary처럼 표시합니다. 확정되면 Button / Primary로 정리합니다.

Deprecated는 삭제가 아니라 안내다

파일을 운영하다 보면 더 이상 쓰지 않는 컴포넌트가 생깁니다. 예전 버튼, 바뀐 카드, 폐기된 입력창, 리브랜딩 전 컬러 시스템이 대표적입니다. 이때 가장 위험한 행동은 조용히 삭제하는 것입니다. 삭제된 컴포넌트가 과거 화면에서 사용 중이었다면 인스턴스 연결이 끊기거나, 개발자가 왜 화면이 달라졌는지 추적하기 어려워질 수 있습니다.

Deprecated는 "사용 금지"라는 뜻입니다. 실무에서는 더 이상 새 화면에 쓰면 안 되지만, 기록과 호환성을 위해 일정 기간 남겨 두는 대상을 말합니다. Deprecated 처리는 다음처럼 진행합니다.

1. 컴포넌트 이름 앞에 Deprecated /를 붙입니다.

2. 컴포넌트 위에 설명 텍스트를 두고 대체 컴포넌트 이름을 적습니다.

3. 사용 중단 날짜와 이유를 기록합니다.

4. 99_Deprecated 페이지나 별도 섹션으로 이동합니다.

5. 새 화면에서는 대체 컴포넌트만 사용하도록 팀에 공유합니다.

예를 들어 기존 버튼을 더 이상 사용하지 않는다면 Deprecated / Button / Primary / Old처럼 이름을 바꿉니다. 그리고 옆에 "2026-05-13 이후 사용 금지. Button / Primary로 교체"라고 적습니다. 이렇게 하면 파일을 여는 사람은 이 요소를 삭제해야 하는지, 유지해야 하는지, 교체해야 하는지 바로 판단할 수 있습니다.

TIP | 지우기 전에 한 번 더 확인하세요
실무 파일에서 삭제는 마지막 단계입니다. 특히 컴포넌트, 스타일, 변수, 프로토타입 시작점은 다른 화면과 연결되어 있을 수 있습니다. 삭제하기 전에는 이름을 Deprecated로 바꾸고, 일정 기간 팀이 문제없이 전환했는지 확인한 뒤 정리하는 편이 안전합니다.

디자인 QA: 눈썰미가 아니라 체크리스트로 검수한다

디자인 QA는 화면이 예쁜지 보는 과정이 아닙니다. 화면이 약속한 기준대로 만들어졌는지 확인하는 과정입니다. 여기서 QA는 Quality Assurance, 즉 품질 보증을 뜻합니다. 실무에서는 디자이너만 QA를 하는 것이 아니라 기획자, 개발자, PM도 각자의 관점에서 화면을 검수합니다.

좋은 QA는 감으로 하지 않습니다. "뭔가 이상한데요"라는 말보다 "버튼 상하 패딩이 기준보다 4px 작습니다"라는 말이 훨씬 빠르게 문제를 해결합니다. 그래서 디자인 QA에는 체크리스트가 필요합니다.

간격 검수에서는 먼저 큰 덩어리를 봅니다. 화면 좌우 마진이 일정한지, 섹션 사이 간격이 규칙적인지, 카드 내부 패딩이 통일되어 있는지 확인합니다. 작은 아이콘의 1px 차이를 먼저 잡기보다 화면 전체의 리듬을 먼저 보는 것이 좋습니다.

컬러와 폰트는 스타일 또는 Variables를 기준으로 확인합니다. 색을 눈으로 비슷하게 맞추면 나중에 미묘하게 다른 회색이 파일 안에 여러 개 생깁니다. 폰트도 마찬가지입니다. 본문처럼 보이는 텍스트가 어떤 곳은 15px, 어떤 곳은 16px, 어떤 곳은 17px이면 개발자는 어떤 값을 기준으로 삼아야 할지 헷갈립니다.

상태 검수는 초보자가 가장 많이 놓치는 부분입니다. 버튼이 눌릴 수 없는 상황, 입력값이 틀린 상황, 데이터가 아직 없는 상황, 네트워크 오류가 난 상황이 실제 서비스에서는 자주 발생합니다. 기본 화면 하나만 예쁘게 만들면 사용자는 예외 상황에서 길을 잃습니다.

반응형 검수에서는 프레임 크기를 직접 바꿔 봅니다. 카드가 늘어나는지, 버튼이 화면 밖으로 밀려나는지, 하단 영역이 고정되어야 하는지 확인합니다. Auto Layout의 Hug, Fill, Fixed 설정과 Constraints가 의도대로 작동하는지 보는 과정입니다.

접근성 검수는 "더 많은 사람이 사용할 수 있는가"를 확인하는 과정입니다. 글자와 배경의 대비가 너무 낮지 않은지, 버튼 터치 영역이 너무 작지 않은지, 오류를 색만으로 표시하지는 않는지 확인합니다. 예를 들어 입력 오류를 빨간 테두리만으로 표현하면 색을 구분하기 어려운 사용자는 문제를 알아차리기 어렵습니다. "이메일 형식이 올바르지 않습니다" 같은 문구를 함께 제공해야 합니다.

QA 루틴 박스 | 5분 안에 보는 빠른 검수 순서
1분 동안 화면 전체의 정렬과 간격을 봅니다. 1분 동안 색상과 폰트가 스타일 기준을 따르는지 봅니다. 1분 동안 버튼, 입력창, 빈 상태, 오류 상태를 확인합니다. 1분 동안 프레임 크기를 바꿔 반응형이 깨지는지 봅니다. 마지막 1분 동안 Dev Mode에서 개발자가 헷갈릴 이름이나 설명이 없는지 확인합니다.

플러그인은 조수이지 책임자가 아니다

피그마 플러그인은 반복 작업을 줄여 주는 좋은 도구입니다. 아이콘을 빠르게 불러오고, 더미 이미지를 넣고, 표를 만들고, 텍스트 대비를 확인하고, 레이어 이름을 정리할 수 있습니다. 하지만 플러그인이 많아질수록 파일은 편리해지는 동시에 위험해질 수도 있습니다.

가장 먼저 확인해야 할 것은 보안과 데이터입니다. 회사 프로젝트, 고객 정보, 출시 전 화면이 담긴 파일에서 플러그인을 사용할 때는 해당 플러그인이 어떤 데이터를 처리하는지 주의해야 합니다. 특히 화면 내용을 외부 서버로 보내 처리하는 플러그인은 팀 정책을 확인한 뒤 사용해야 합니다. 내부 정보가 들어간 화면에서는 실제 고객 이름, 전화번호, 이메일을 그대로 더미 데이터처럼 넣지 않는 것도 중요합니다.

두 번째는 결과물의 일관성입니다. 아이콘 플러그인에서 가져온 아이콘은 출처마다 선 두께, 모서리, 시각적 무게가 다를 수 있습니다. 이미지 플러그인으로 넣은 사진도 톤이 제각각이면 서비스 분위기가 흔들립니다. 플러그인은 빠른 시작을 도와주지만, 최종 판단은 사람이 해야 합니다.

아이콘은 플러그인에서 가져온 뒤 바로 화면에 흩뿌리지 말고 Icon / Search, Icon / Close, Icon / Back처럼 컴포넌트로 등록해 두는 것이 좋습니다. 그래야 같은 아이콘을 여러 곳에서 재사용하고, 크기나 색상 규칙을 유지할 수 있습니다.

이미지는 화면을 그럴듯하게 만들어 주지만, 너무 완벽한 광고 사진만 넣으면 실제 서비스 데이터와 차이가 커집니다. 쇼핑 앱 카드라면 밝은 사진, 어두운 사진, 긴 상품명, 품절 이미지처럼 현실적인 변수를 함께 넣어 보아야 합니다. 디자인은 가장 예쁜 데이터 하나가 아니라 가장 흔한 데이터와 가장 불편한 데이터도 견뎌야 합니다.

더미 데이터는 기획자와 개발자에게 특히 유용합니다. "홍길동"만 반복해서 넣은 화면보다, 길이가 다른 이름과 다양한 날짜, 긴 주소, 0원, 999,999원 같은 값을 넣은 화면이 실제 문제를 더 빨리 드러냅니다. 단, 실제 고객 정보나 운영 데이터를 무심코 붙여 넣는 일은 피해야 합니다.

접근성 플러그인은 색 대비를 빠르게 확인하는 데 도움이 됩니다. 하지만 숫자만 통과했다고 좋은 UI가 되는 것은 아닙니다. 버튼이 무엇을 하는지 문구가 명확한지, 오류가 났을 때 해결 방법을 알려 주는지, 터치 가능한 영역이 충분한지도 함께 봐야 합니다.

TIP | 플러그인 사용 전 3초 질문
이 플러그인이 내 파일 내용을 외부로 보낼까? 결과물이 우리 팀의 스타일과 맞을까? 나중에 이 작업을 다시 설명할 수 있을까? 이 세 가지 질문에 답할 수 있으면 플러그인은 강력한 조수가 됩니다.

반복 작업을 줄이는 단축키 루틴

실무 속도는 손이 빨라서만 올라가지 않습니다. 같은 작업을 같은 방식으로 반복할 때 올라갑니다. 매번 메뉴를 뒤지고, 레이어를 찾고, 패널을 헤매면 집중력이 끊깁니다. 단축키는 외워야 하는 시험 문제가 아니라 자주 가는 길에 놓는 지름길입니다.

처음부터 모든 단축키를 외울 필요는 없습니다. 화면을 만들고 정리하고 검수하는 데 자주 쓰는 것부터 몸에 익히면 됩니다.

단축키 박스 | 기본 제작 루틴
F는 Frame, T는 Text, R은 Rectangle, V는 Move 도구입니다. 화면을 새로 만들 때는 F로 프레임을 만들고, T로 텍스트를 넣고, R로 임시 박스를 만든 뒤, V로 다시 선택 모드로 돌아오는 흐름을 반복합니다.

단축키 박스 | Auto Layout 루틴
선택한 레이어에 Auto Layout을 적용할 때는 Shift A를 사용합니다. 버튼, 카드, 리스트 아이템처럼 내부 간격이 중요한 요소는 수동으로 맞추기보다 먼저 Shift A를 눌러 구조를 만든 뒤 패딩과 gap을 조정하는 습관을 들이세요.

단축키 박스 | 복제와 측정 루틴
⌘ D 또는 Ctrl D는 복제입니다. Option 또는 Alt를 누른 채 드래그하면 빠르게 복사할 수 있습니다. 요소를 선택한 상태에서 Option 또는 Alt를 누르고 다른 요소에 마우스를 올리면 간격을 확인할 수 있어, QA할 때 매우 자주 사용합니다.

단축키 박스 | 속성 복사 루틴
Mac에서는 ⌘ Option C로 속성을 복사하고 ⌘ Option V로 붙여 넣을 수 있습니다. Windows에서는 보통 Ctrl Alt C, Ctrl Alt V 조합을 사용합니다. 같은 스타일의 카드나 버튼을 빠르게 맞출 때 유용하지만, 컴포넌트로 관리해야 할 요소를 속성 복사로만 해결하지 않도록 주의하세요.

단축키 박스 | Actions 검색 루틴
⌘ / 또는 Ctrl /를 누르면 Actions 검색을 열 수 있습니다. 정확한 메뉴 위치가 기억나지 않을 때 명령어를 검색해서 실행하는 방식입니다. Create component, Add auto layout, Show layout grids, Outline stroke, Rename layers처럼 자주 쓰는 명령을 검색해 실행하면 메뉴를 헤매는 시간이 줄어듭니다.

Actions 검색은 피그마의 숨은 내비게이션입니다. "그 기능이 어디 있었더라?" 하고 생각나는 순간 메뉴를 하나씩 열지 말고 검색합니다. 기능 이름의 일부만 입력해도 관련 명령이 나타납니다. 이 습관은 Figma UI가 조금 바뀌어도 작업 속도를 지켜 줍니다. 메뉴 위치는 바뀔 수 있지만, 명령의 이름과 역할은 비교적 오래 유지되기 때문입니다.

즐겨찾기식 작업 팁도 만들어 둘 수 있습니다. 피그마에 모든 명령을 개인 즐겨찾기처럼 고정하지 않더라도, 팀 파일 안에 자주 쓰는 리소스를 모아 두면 사실상 즐겨찾기처럼 작동합니다. 예를 들어 00_Cover나 별도 Toolbox 섹션에 자주 쓰는 컴포넌트, 아이콘 세트, 체크리스트, 플러그인 이름, 참고 링크를 모아 둡니다. 그러면 새 팀원이 들어와도 "어디서 시작해야 하는지" 바로 알 수 있습니다.

오래 유지되는 파일은 매일 조금씩 정리된다

파일 정리는 프로젝트 끝에 몰아서 하는 일이 아닙니다. 마지막에 한꺼번에 정리하려고 하면 이미 무엇이 최신이고 무엇이 임시인지 기억나지 않습니다. 실무에서는 작업 중간중간 작게 정리하는 습관이 훨씬 강력합니다.

이 습관의 핵심은 "지금 이 화면의 상태가 무엇인지"를 남기는 것입니다. 화면이 완성됐는지, 검토 중인지, 개발 전달됐는지, 폐기됐는지 보이지 않으면 팀원은 매번 물어봐야 합니다. 반대로 상태가 보이면 피그마 파일은 회의록이자 작업판이 됩니다.

주간 정리 시간은 길 필요가 없습니다. 15분이면 충분합니다. 새로 생긴 임시 페이지를 확인하고, 이름 없는 프레임을 정리하고, 중복 버튼이 생겼는지 보고, 오래된 시안을 Archive로 옮깁니다. 이 작은 정리가 쌓이면 파일은 오래 버팁니다.

운영 팁 | 정리의 목표는 완벽이 아니라 신뢰입니다
모든 레이어가 완벽하게 이름 붙은 파일보다, 최신 화면과 폐기 화면이 명확히 구분된 파일이 더 실무적입니다. 팀이 헷갈리지 않고 다음 행동을 결정할 수 있다면 좋은 운영입니다.

혼자 작업해도 팀 파일처럼 만든다

많은 초보자가 "나는 아직 혼자 작업하니까 운영 기준은 나중에 필요하겠지"라고 생각합니다. 하지만 혼자 만든 파일도 며칠 뒤에는 낯선 파일이 됩니다. 과거의 내가 만든 Frame 77을 미래의 내가 해석해야 하는 순간이 옵니다.

그래서 혼자 연습할 때도 팀 파일처럼 만드는 것이 좋습니다. 페이지를 나누고, 화면 이름을 붙이고, 버튼을 컴포넌트로 만들고, 사용하지 않는 시안을 Archive로 옮겨 봅니다. 이 습관이 몸에 익으면 실제 프로젝트에 들어갔을 때 훨씬 안정적으로 협업할 수 있습니다.

특히 기획자와 개발자에게 이 습관은 큰 장점이 됩니다. 기획자는 화면의 의도와 상태를 명확히 남길 수 있고, 개발자는 구현 기준을 빠르게 확인할 수 있습니다. 디자이너가 아니어도 신뢰할 수 있는 피그마 파일을 만들 수 있다는 뜻입니다.

피그마 실력은 멋진 화면 하나를 만드는 능력에서 끝나지 않습니다. 그 화면이 수정되고, 공유되고, 구현되고, 다시 개선되는 과정까지 버티게 만드는 능력으로 확장됩니다. 실무에서 오래 쓰이는 파일은 처음부터 완벽해서가 아니라, 계속 정리되고 검수되고 개선되기 때문에 살아남습니다.

핵심 요약

• 초보를 벗어나는 기준은 많은 기능을 아는 것이 아니라, 팀이 신뢰할 수 있는 피그마 파일을 만드는 것이다.

• 페이지 구조는 파일의 지도이므로 Cover, Design, Components, Ready for Dev, Archive, Deprecated처럼 역할이 보이게 나눈다.

• 네이밍 규칙은 협업 속도를 높인다. 화면, 컴포넌트, 주요 레이어에는 의미 있는 이름을 붙이고 한 파일 안에서 언어와 형식을 통일한다.

• 컴포넌트 원본은 한곳에서 관리하고, 더 이상 쓰지 않는 요소는 바로 삭제하지 말고 Deprecated 처리해 대체 요소와 이유를 남긴다.

• 디자인 QA는 감이 아니라 체크리스트로 한다. 간격, 색상, 폰트, 상태, 반응형, 접근성, 개발 전달 항목을 반복해서 확인한다.

• 플러그인은 작업을 빠르게 돕는 도구이지만, 보안, 라이선스, 스타일 일관성, 데이터 처리 방식을 반드시 확인해야 한다.

• 단축키와 Actions 검색은 반복 작업을 줄여 준다. 자주 쓰는 명령은 메뉴에서 찾기보다 검색하고, 팀 리소스는 즐겨찾기처럼 모아 둔다.

• 파일 운영은 프로젝트 마지막 청소가 아니라 매일 조금씩 하는 관리다. 상태를 표시하고, 정리하고, 기록하는 습관이 좋은 협업을 만든다.

실습 과제: 기존 피그마 파일을 실무형 구조로 리팩터링하기

이번 실습의 목표는 새 화면을 만드는 것이 아닙니다. 이미 만든 피그마 파일 하나를 골라 팀에서 다시 사용할 수 있는 구조로 정리하는 것입니다. 이전 장에서 만든 모바일 앱 화면 파일이나, 개인 포트폴리오용으로 만든 화면 파일을 사용해도 좋습니다.

1단계: 페이지 구조 정리하기

기존 파일을 열고 페이지 목록을 확인합니다. 이름이 불분명하거나 임시로 만든 페이지가 있다면 역할에 따라 다시 나눕니다. 최소한 00_Cover, 03_Design, 05_Components, 90_Archive는 만들어 봅니다. 개발 전달까지 연습하고 싶다면 06_Ready for Dev도 추가합니다.

00_Cover에는 프로젝트 이름, 파일 목적, 담당자, 마지막 업데이트 날짜, 현재 상태를 적습니다. 관련 기획 문서나 프로토타입 링크가 있다면 함께 적습니다.

2단계: 화면과 섹션 이름 붙이기

디자인 페이지 안의 화면을 기능별 섹션으로 묶습니다. 로그인, 홈, 상세, 마이페이지처럼 사용자가 이해할 수 있는 단위로 나누면 됩니다. 각 화면 프레임에는 기능 / 화면 / 상태 형식으로 이름을 붙입니다.

예를 들어 로그인 기본 화면은 Login / Sign in / Default, 로그인 오류 화면은 Login / Sign in / Error, 홈 빈 상태는 Home / Feed / Empty처럼 정리합니다.

3단계: 컴포넌트 원본 모으기

파일 안에서 반복되는 버튼, 입력창, 카드, 네비게이션을 찾습니다. 원본으로 삼을 요소를 하나 정하고 컴포넌트로 만든 뒤 05_Components 페이지로 이동합니다. 기존 화면에서는 가능하면 해당 컴포넌트의 인스턴스를 사용하도록 교체합니다.

이미 비슷한 버튼이 여러 개 있다면 하나로 합칠 수 있는지 확인합니다. 단, 화면마다 미묘하게 다른 이유가 있다면 무조건 합치지 말고 Variant나 속성으로 관리할 수 있는지 생각해 봅니다.

4단계: Deprecated 처리 연습하기

더 이상 쓰지 않을 컴포넌트나 예전 시안을 하나 골라 삭제하지 말고 Deprecated 처리합니다. 이름 앞에 Deprecated /를 붙이고, 옆에 대체 요소와 사용 중단 이유를 적습니다. 그런 다음 99_Deprecated 페이지나 90_Archive 안의 Deprecated 섹션으로 옮깁니다.

이 단계는 실제 실무에서 매우 중요합니다. 삭제보다 안내가 먼저입니다.

5단계: 디자인 QA 체크리스트로 검수하기

정리한 화면 중 3개를 골라 QA를 진행합니다. 간격, 정렬, 컬러, 폰트, 상태, 반응형, 접근성, 개발 전달 항목을 하나씩 확인합니다. 문제가 발견되면 화면 옆에 작은 메모를 남기거나 코멘트를 달아 수정 내용을 기록합니다.

검수할 때는 프레임 크기를 직접 바꿔 보고, 긴 텍스트를 넣어 보고, 빈 데이터 상태와 오류 상태가 있는지 확인합니다. 화면이 가장 예쁜 순간만 보는 것이 아니라, 실제 서비스에서 흔히 생기는 불편한 순간까지 확인해야 합니다.

6단계: 단축키와 Actions 루틴 적용하기

작업 중 최소 세 가지 단축키를 의식적으로 사용합니다. 예를 들어 Shift A로 Auto Layout을 적용하고, ⌘ R 또는 Ctrl R로 레이어 이름을 바꾸고, ⌘ / 또는 Ctrl /로 Actions 검색을 열어 필요한 명령을 실행합니다.

자주 쓰는 플러그인이나 체크리스트가 있다면 00_Cover 또는 Toolbox 섹션에 적어 둡니다. 다음에 파일을 열었을 때 바로 이어서 작업할 수 있으면 성공입니다.

완료 기준

• 페이지 구조가 역할별로 정리되어 있고, 첫 페이지에서 파일 목적과 상태를 알 수 있다.

• 주요 화면 프레임에 의미 있는 이름이 붙어 있다.

• 반복 UI 중 최소 3개 이상이 컴포넌트로 정리되어 있다.

• 더 이상 쓰지 않는 요소 하나 이상이 Deprecated 처리되어 있다.

• 선택한 화면 3개에 대해 디자인 QA를 수행하고 수정 또는 메모를 남겼다.

• 개발자가 Dev Mode에서 확인했을 때 화면 이름, 주요 레이어, 컴포넌트 상태를 이해할 수 있다.

이 과제를 마치면 파일은 단순한 연습물이 아니라 다시 열어도 이해할 수 있는 작업물이 됩니다. 피그마에서 중요한 것은 완벽한 첫 시안이 아니라, 함께 고치고 오래 사용할 수 있는 구조입니다. 그 구조를 만드는 사람이 실무에서 신뢰받는 작업자입니다.