협업과 피드백을 위한 공유·코멘트·버전 관리

피그마를 혼자 쓰면 '디자인 도구'처럼 느껴집니다. 그런데 팀과 함께 쓰는 순간, 피그마는 회의실이 되고, 화이트보드가 되고, 작업 기록 창고가 됩니다. 누군가는 화면을 만들고, 누군가는 문구를 고치고, 누군가는 개발 가능성을 확인하고, 누군가는 "이 버튼은 여기보다 아래가 낫지 않을까요?"라고 코멘트를 남깁니다.

이 장의 핵심은 단순합니다. 피그마의 강점은 혼자 예쁘게 만드는 것보다 팀과 빠르게 합의하는 데 있습니다. 디자인 비전공자, 기획자, 개발자, 마케터가 같은 파일을 보면서 이야기할 수 있고, 같은 화면 위에 피드백을 남기며, 이전 상태로 되돌아갈 수 있습니다. 이 흐름을 제대로 만들면 회의 시간이 줄고, 수정 사항이 사라지지 않으며, "그때 왜 이렇게 바꿨죠?"라는 질문에도 침착하게 답할 수 있습니다.

이번 장에서는 피그마에서 파일을 안전하게 공유하는 방법, 코멘트로 리뷰 흐름을 만드는 방법, Branch와 Version History로 변경 이력을 관리하는 방법을 익힙니다.

협업은 파일을 보내는 일이 아니라 같은 기준을 보는 일입니다

많은 초보자가 협업을 이렇게 시작합니다.

"피그마 링크 드릴게요. 한번 봐 주세요."

이 말 자체는 틀리지 않습니다. 하지만 실무에서는 이 한 줄만으로는 부족합니다. 링크를 받은 사람이 어디를 봐야 하는지, 무엇에 대해 피드백해야 하는지, 수정해도 되는지, 보기만 해야 하는지 알 수 없기 때문입니다. 피그마 협업의 출발점은 링크 공유가 아니라 역할과 범위를 정하는 것입니다.

예를 들어 로그인 화면을 검토한다고 해 봅시다. 기획자는 문구와 화면 흐름을 봐야 합니다. 개발자는 입력창 상태, 버튼 비활성 조건, 화면 크기 대응을 확인해야 합니다. 디자이너는 간격, 컴포넌트 사용 여부, 스타일 적용 상태를 봐야 합니다. 같은 화면을 보더라도 각자가 보는 관점이 다릅니다.

그래서 좋은 협업 파일은 "여기 링크입니다"에서 끝나지 않습니다. 파일 안에서 무엇이 최신인지 알 수 있고, 리뷰할 구간이 표시되어 있으며, 코멘트가 정리되고, 변경 이력이 남아 있어야 합니다.

피그마에서 협업을 잘한다는 것은 다음 세 가지를 관리한다는 뜻입니다.

• 누가 볼 수 있고 수정할 수 있는가

• 어디에 어떤 피드백이 남았는가

• 무엇이 언제 왜 바뀌었는가

이 세 가지가 정리되면 팀은 훨씬 빠르게 움직입니다. 반대로 이 세 가지가 흐려지면, 디자인 파일은 금세 "누가 만졌는지 모르는 파일"이 됩니다.

팀, 프로젝트, 파일 구조 이해하기

피그마의 협업 구조는 크게 팀, 프로젝트, 파일로 나누어 이해하면 쉽습니다. 회사나 조직의 설정에 따라 이름과 권한 구조가 조금씩 다를 수 있지만, 기본 개념은 비슷합니다.

팀은 여러 사람이 함께 일하는 가장 큰 공간입니다. 예를 들어 Product Team, Marketing Team, Design System 같은 단위가 팀이 될 수 있습니다. 프로젝트는 팀 안에서 파일을 묶는 폴더에 가깝습니다. Mobile App, Web Renewal, Admin Dashboard처럼 업무나 제품 단위로 나눌 수 있습니다. 파일은 실제 디자인 작업이 이루어지는 문서입니다.

협업이 필요한 파일을 개인 Drafts에 계속 두는 것은 추천하지 않습니다. Drafts는 말 그대로 개인 초안 공간에 가깝기 때문입니다. 팀과 함께 봐야 하는 화면이라면 적절한 팀과 프로젝트 안으로 파일을 옮겨야 합니다. 그래야 팀원들이 파일을 찾기 쉽고, 권한도 일관되게 관리할 수 있습니다.

작업 구조를 처음 잡을 때는 너무 복잡하게 나누기보다, 팀원이 파일을 찾는 상황을 상상해 보세요. "이번 주 앱 회원가입 화면은 어디 있지?"라는 질문에 바로 답할 수 있어야 합니다. 파일 이름과 프로젝트 이름이 명확하면 협업의 절반은 이미 해결된 셈입니다.

TIP · 파일 이름은 검색되는 문장으로 짓기
final, new, copy 같은 이름은 시간이 지나면 아무 의미가 없어집니다. 대신 Mobile App Signup Flow, Admin Dashboard User Management, Landing Page Renewal처럼 제품, 영역, 목적이 드러나게 이름을 붙이세요. 날짜가 필요한 경우에는 2026-05처럼 뒤에 붙이는 방식이 좋습니다.

공유 권한 설정하기

피그마 파일 오른쪽 위에는 보통 Share 버튼이 있습니다. 이 버튼이 협업의 입구입니다. Share를 누르면 사람을 초대하거나, 링크 접근 범위를 정하거나, 보기와 편집 권한을 설정할 수 있습니다.

권한은 크게 보기 권한과 편집 권한으로 나누어 생각하면 됩니다. 보기 권한은 파일을 열어 확인하고 코멘트를 남기는 정도의 접근입니다. 편집 권한은 실제 레이어를 수정하고, 프레임을 옮기고, 컴포넌트를 바꾸는 권한입니다.

초보자가 가장 자주 하는 실수는 모든 사람에게 편집 권한을 주는 것입니다. 물론 빠르게 일할 때는 편해 보입니다. 하지만 실무에서는 위험합니다. 누군가 실수로 컴포넌트를 삭제하거나, Auto Layout 값을 바꾸거나, 최신 화면을 덮어쓸 수 있기 때문입니다. 편집 권한은 실제로 디자인 파일을 수정해야 하는 사람에게만 주는 것이 좋습니다.

상황별로 권한을 정하면 다음과 같습니다.

• 대표, PO, 기획자, 마케터가 화면을 검토하는 경우: 보기 권한과 코멘트 중심으로 공유합니다.

• 디자이너가 함께 화면을 수정하는 경우: 편집 권한을 부여하되 작업 범위를 정합니다.

• 개발자가 구현 정보를 확인하는 경우: 보기 권한 또는 Dev Mode 접근 권한을 상황에 맞게 제공합니다.

• 외부 클라이언트나 파트너에게 보여주는 경우: 링크 접근 범위를 제한하고, 필요한 페이지만 정리해서 공유합니다.

링크 공유 범위도 신중하게 정해야 합니다. 회사 내부 파일이라면 "링크가 있는 누구나 접근" 방식은 편리하지만 위험할 수 있습니다. 민감한 프로젝트라면 초대받은 사람만 접근할 수 있게 설정하는 편이 안전합니다.

권한 설정 박스 · 이렇게 판단하세요
보기만 해도 되는 사람에게는 편집 권한을 주지 않습니다.
외부 사람에게 공유할 때는 링크 접근 범위를 반드시 확인합니다.
중요한 파일은 개인 Drafts가 아니라 팀 프로젝트 안에 둡니다.
리뷰가 끝난 뒤 더 이상 접근이 필요 없는 사람은 권한을 정리합니다.

링크를 그냥 보내지 말고, 목적과 함께 보내기

좋은 공유는 링크 하나가 아니라 짧은 안내문과 함께 전달됩니다. 피그마 파일을 처음 여는 사람은 화면이 많으면 어디서부터 봐야 할지 모릅니다. 특히 기획자나 개발자는 디자인 파일 구조에 익숙하지 않을 수 있습니다. 그러니 공유할 때는 "무엇을 봐야 하는지"를 먼저 알려 주세요.

나쁜 예는 이렇습니다.

피그마 확인 부탁드립니다.
https://figma.com/...

이 메시지를 받은 사람은 곧바로 질문하게 됩니다. "어느 화면을 보면 되나요?", "전체 다 보면 되나요?", "언제까지 보면 되나요?", "코멘트로 남기면 되나요?"

좋은 예는 조금 더 구체적입니다.

회원가입 1차 화면 리뷰 부탁드립니다.
확인 범위는 Review / 2026-05-13 페이지의 상단 플로우입니다.
오늘 오후 5시까지 문구, 필수 입력 항목, 화면 흐름 위주로 코멘트 남겨 주세요.
디자인 디테일보다 정책과 누락된 예외 상황을 우선 확인해 주시면 됩니다.

이 정도만 적어도 리뷰 품질이 달라집니다. 피드백을 받는 사람은 원하는 의견을 얻고, 피드백을 주는 사람은 어디에 집중해야 할지 압니다.

피드백 요청 메시지 템플릿
무엇을 공유하는지: 예) 회원가입 화면 1차 시안입니다.
어디를 보면 되는지: 예) Review 페이지의 1번 플로우만 확인해 주세요.
무엇을 봐야 하는지: 예) 화면 흐름, 문구, 누락 상태를 중심으로 봐 주세요.
언제까지 필요한지: 예) 오늘 오후 5시까지 코멘트 부탁드립니다.
어떻게 남기면 되는지: 예) 피그마 Comment로 화면 위에 직접 남겨 주세요.

Comment로 화면 위에 피드백 남기기

피그마의 Comment 기능은 협업에서 가장 자주 쓰는 기능 중 하나입니다. 이메일이나 메신저로 "두 번째 화면의 오른쪽 아래 버튼 문구를 바꿔 주세요"라고 말하면 서로 헷갈리기 쉽습니다. 하지만 화면 위에 직접 코멘트를 꽂아 두면 위치가 명확해집니다.

피그마 상단 툴바에서 말풍선 모양의 Comment 도구를 선택하거나 단축키를 사용하면 코멘트 모드로 들어갈 수 있습니다. 그다음 의견을 남기고 싶은 위치를 클릭해 내용을 작성합니다. 작성된 코멘트는 화면 위에 핀처럼 표시됩니다. 팀원은 해당 코멘트를 눌러 내용을 확인하고 답글을 달 수 있습니다.

코멘트를 남길 때는 "이상해요", "별로예요"처럼 감상만 남기기보다, 무엇이 문제이고 어떤 방향을 원하는지 적는 것이 좋습니다. 디자인 리뷰에서 중요한 것은 취향 대결이 아니라 의사결정입니다.

예를 들어 다음 코멘트는 애매합니다.

버튼이 좀 이상합니다.

이 코멘트는 무엇을 고쳐야 하는지 알기 어렵습니다. 색인지, 위치인지, 문구인지, 크기인지 알 수 없습니다. 반면 다음처럼 쓰면 훨씬 명확합니다.

하단 CTA 버튼 문구가 다음으로 되어 있는데, 사용자가 무엇을 완료하는지 알기 어렵습니다. 인증번호 받기처럼 다음 행동이 드러나는 문구로 바꾸는 것이 좋겠습니다.

이 코멘트에는 위치, 문제, 제안이 모두 들어 있습니다. 피드백을 받은 사람은 바로 판단할 수 있습니다.

단축키 박스 · 코멘트와 이동
C: Comment 모드로 전환
V: Move 도구로 돌아가기
Shift + 2: 선택한 요소에 화면 맞추기
Space + 드래그: 캔버스 이동
+ / -: 화면 확대와 축소

단축키는 운영체제와 피그마 업데이트에 따라 일부 다를 수 있습니다. 자주 쓰는 단축키는 피그마 메뉴의 Keyboard shortcuts에서 확인해 두세요.

멘션, 답글, 해결 처리로 리뷰 흐름 만들기

코멘트가 많아지면 그것만으로도 또 하나의 일이 됩니다. 그래서 코멘트는 남기는 것보다 정리하는 방식이 더 중요합니다.

피그마 코멘트에서는 @이름 형식으로 팀원을 멘션할 수 있습니다. 특정 사람의 확인이 필요할 때는 멘션을 사용하세요. 예를 들어 정책 판단이 필요한 내용에는 기획자를, 구현 가능성 확인이 필요한 내용에는 개발자를, 시각적 판단이 필요한 내용에는 디자이너를 멘션하면 됩니다.

코멘트에 답글을 달 때는 한 코멘트 안에서 대화를 이어가는 것이 좋습니다. 같은 주제로 새 코멘트를 여러 개 만들면 나중에 흐름을 추적하기 어렵습니다. 특히 버튼 문구 하나를 두고 기획자, 디자이너, 개발자가 의견을 주고받는 경우에는 기존 코멘트의 답글로 이어가야 맥락이 유지됩니다.

수정이 끝난 코멘트는 해결 처리합니다. 해결 처리는 "이 의견을 무시한다"는 뜻이 아니라 "이 이슈는 현재 기준으로 처리되었다"는 뜻입니다. 해결된 코멘트는 필요할 때 다시 볼 수 있지만, 현재 남은 작업 목록에서는 빠집니다. 이렇게 하면 리뷰 후 남은 할 일이 훨씬 선명해집니다.

코멘트 정리 흐름은 다음처럼 잡을 수 있습니다.

• 리뷰 요청자가 확인 범위와 마감 시간을 안내합니다.

• 리뷰어는 화면 위에 코멘트를 남기고 필요한 사람을 멘션합니다.

• 담당자는 코멘트에 답글로 처리 방향을 남깁니다.

• 수정이 끝나면 담당자가 해결 처리합니다.

• 논의가 필요한 코멘트만 회의 안건으로 가져갑니다.

이렇게 하면 회의에서 모든 화면을 처음부터 다시 설명하지 않아도 됩니다. 이미 코멘트로 정리된 내용은 비동기로 처리하고, 정말 결정이 필요한 내용만 회의에서 이야기하면 됩니다.

협업 매너 박스 · 좋은 코멘트의 기준
사람을 평가하지 말고 화면의 문제를 말합니다.
"별로예요"보다 "사용자가 다음 행동을 알기 어렵습니다"처럼 씁니다.
수정 요청에는 이유를 함께 남깁니다.
결정이 필요한 내용에는 담당자를 멘션합니다.
처리된 코멘트는 방치하지 말고 해결 처리합니다.

리뷰 전 파일 정리 체크리스트

리뷰를 요청하기 전에 파일을 조금만 정리해도 피드백 품질이 올라갑니다. 정리되지 않은 파일은 리뷰어의 에너지를 빼앗습니다. 화면이 여기저기 흩어져 있고, 이전 시안과 최신 시안이 섞여 있고, 어떤 프레임을 봐야 하는지 표시되어 있지 않다면 좋은 피드백을 기대하기 어렵습니다.

리뷰용 파일은 "작업하던 파일"이 아니라 "보는 사람을 위해 정리된 파일"이어야 합니다. 물론 매번 완벽한 문서를 만들 필요는 없습니다. 다만 리뷰어가 길을 잃지 않게 최소한의 안내 표지판은 세워야 합니다.

리뷰 전에는 다음 항목을 확인하세요.

• 최신 화면이 어느 페이지나 섹션에 있는지 명확하게 표시했는가

• 검토 대상이 아닌 과거 시안이나 실험 화면을 분리했는가

• 프레임 이름이 Frame 1234처럼 방치되어 있지 않은가

• 화면 흐름이 왼쪽에서 오른쪽, 위에서 아래처럼 읽기 쉽게 배치되어 있는가

• 코멘트가 필요한 영역에 설명 메모나 안내 문구를 추가했는가

• 컴포넌트나 스타일이 깨진 부분은 없는가

• 프로토타입을 공유한다면 시작 화면과 주요 연결이 정상인지 확인했는가

특히 실무에서는 Review, Archive, Working, Components처럼 페이지를 나누는 방식이 자주 쓰입니다. Working에는 디자이너가 자유롭게 작업하는 화면을 두고, Review에는 팀원에게 보여줄 정리된 화면만 둡니다. Archive에는 이전 시안이나 보류된 안을 옮겨 둡니다. 이렇게 나누면 리뷰어가 엉뚱한 화면에 코멘트를 남기는 일을 줄일 수 있습니다.

TIP · 리뷰용 페이지를 따로 만들기
작업 중인 화면을 그대로 공유하면 피드백이 흩어집니다. 리뷰 전에는 Review / 날짜 페이지나 섹션을 만들고, 확인해야 할 화면만 복사하거나 정리해 두세요. 화면 위에 "검토 범위", "확인할 내용", "마감 시간"을 텍스트로 적어 두면 더 좋습니다.

Version History로 변경 이력 확인하기

협업 파일에서 가장 무서운 순간은 "누가 이걸 바꿨죠?"라는 질문이 나올 때입니다. 다행히 피그마에는 Version History가 있습니다. Version History는 파일의 변경 기록을 시간순으로 확인하고, 필요하면 특정 시점의 상태를 살펴볼 수 있는 기능입니다.

피그마에서는 파일 이름 근처의 메뉴나 파일 메뉴에서 Version History를 열 수 있습니다. 그러면 오른쪽에 시간대별 저장 기록이 나타납니다. 자동으로 기록되는 버전도 있고, 사용자가 직접 이름을 붙여 저장한 버전도 있을 수 있습니다. 중요한 변경 전후에는 버전 이름을 붙여 두면 나중에 훨씬 찾기 쉽습니다.

예를 들어 대규모 개편 전에는 다음처럼 버전명을 남길 수 있습니다.

Before signup flow redesign
회원가입 정책 변경 전 백업
v1.0 review submitted
개발 전달 전 최종안

버전 이름은 길게 쓸 필요가 없습니다. 다만 나중에 봤을 때 어떤 상태였는지 알 수 있어야 합니다. "최종", "진짜 최종", "최종 수정" 같은 이름은 피하는 것이 좋습니다. 실무에서 최종은 자주 최종이 아니게 됩니다.

Version History는 단순한 백업 기능이 아닙니다. 팀이 어떤 결정을 거쳐 현재 화면에 도달했는지 보여 주는 기록입니다. 예전 상태를 확인하면 "왜 이 버튼을 제거했는지", "언제 문구가 바뀌었는지", "개발 전달 후 어떤 수정이 들어갔는지"를 추적할 수 있습니다.

작업 안전 박스 · 중요한 수정 전에는 버전 이름 남기기
큰 구조 변경 전에는 수동으로 버전 이름을 남깁니다.
개발 전달 직전 상태는 별도로 표시해 둡니다.
클라이언트 리뷰 제출본도 버전으로 남겨 둡니다.
문제가 생기면 먼저 Version History에서 변경 시점을 확인합니다.

Branch로 안전하게 실험하기

팀 파일에서 바로 큰 수정을 하는 것은 위험할 수 있습니다. 특히 디자인 시스템 컴포넌트, 주요 화면 플로우, 이미 개발 중인 화면을 수정할 때는 더욱 그렇습니다. 이럴 때 사용할 수 있는 기능이 Branch입니다.

Branch는 원본 파일에서 갈라져 나온 작업 공간이라고 이해하면 됩니다. 나무의 줄기에서 가지가 뻗어 나오는 모습을 떠올리면 쉽습니다. 원본 파일을 바로 바꾸지 않고, 별도의 가지에서 수정안을 만든 뒤, 검토가 끝나면 다시 원본에 반영할 수 있습니다.

예를 들어 Button 컴포넌트의 구조를 바꿔야 한다고 해 봅시다. 원본에서 바로 수정하면 해당 버튼을 사용하는 수많은 화면에 영향이 갈 수 있습니다. 하지만 Branch를 만들면 별도 공간에서 버튼 구조를 바꿔 보고, 실제 화면에 적용했을 때 문제가 없는지 확인한 뒤, 팀 리뷰를 거쳐 원본에 반영할 수 있습니다.

Branch가 특히 유용한 상황은 다음과 같습니다.

• 디자인 시스템 컴포넌트를 수정할 때

• 이미 개발 중인 화면의 구조를 크게 바꿀 때

• 여러 수정안을 실험해 보고 하나만 반영해야 할 때

• 팀원이 같은 파일에서 동시에 큰 작업을 해야 할 때

• 원본 파일을 안정적으로 유지해야 할 때

피그마의 Branch 기능은 사용하는 플랜과 조직 설정에 따라 보이는 메뉴나 사용 가능 여부가 다를 수 있습니다. 사용할 수 있는 환경이라면 파일 상단의 브랜치 관련 메뉴에서 새 Branch를 만들고, 작업 후 리뷰와 병합 과정을 거치게 됩니다.

Merge는 '합치기'가 아니라 '검토 후 반영'입니다

Branch에서 작업을 마쳤다면 원본 파일에 반영해야 합니다. 이 과정을 Merge라고 합니다. Merge는 단순히 변경사항을 덮어쓰는 일이 아닙니다. 안전한 협업에서는 Merge 전에 무엇이 바뀌었는지 확인하고, 관련 팀원이 리뷰한 뒤, 원본에 반영합니다.

Branch 작업을 원본에 합치기 전에는 다음 질문을 확인해야 합니다.

• 이 변경이 영향을 주는 화면이나 컴포넌트는 무엇인가

• 기존 인스턴스나 Variant 구조가 깨지지 않는가

• 개발자에게 다시 전달해야 하는 변경인가

• 기존 코멘트나 결정 사항과 충돌하지 않는가

• Merge 후 이전 버전으로 돌아갈 필요에 대비했는가

Merge는 디자인 파일의 배포에 가깝습니다. 특히 디자인 시스템 파일에서는 버튼 하나의 변경이 여러 제품 화면에 영향을 줄 수 있습니다. 그러므로 "작업이 끝났으니 합친다"가 아니라 "검토가 끝났으니 반영한다"는 마음가짐이 필요합니다.

Branch 이름도 중요합니다. 이름만 보고 무엇을 고친 작업인지 알 수 있어야 합니다. test, new, edit처럼 모호한 이름은 피하고, signup-error-state-update, button-size-token-cleanup, profile-flow-review처럼 목적이 드러나는 이름을 사용하세요.

TIP · Branch 이름 짓기
영역-작업내용-목적 순서로 쓰면 찾기 쉽습니다.
예를 들어 signup-input-error-state, button-component-refactor, checkout-flow-review처럼 작성할 수 있습니다.
한 Branch에는 가능하면 하나의 큰 목적만 담으세요. 여러 주제가 섞이면 리뷰와 Merge가 어려워집니다.

코멘트를 수정 목록으로 바꾸기

피드백을 받는 것만으로는 일이 끝나지 않습니다. 실무에서 중요한 것은 코멘트를 수정 가능한 작업 목록으로 바꾸는 것입니다. 코멘트가 30개 달렸다고 해서 할 일이 30개라는 뜻은 아닙니다. 같은 문제를 여러 사람이 말했을 수도 있고, 지금 반영하지 않기로 한 의견도 있을 수 있습니다.

리뷰가 끝나면 먼저 코멘트를 분류하세요. 바로 수정할 것, 논의가 필요한 것, 이번 범위에서 제외할 것, 이미 반영된 것으로 나눕니다. 이때 피그마 코멘트 안에서 답글로 처리 방향을 남기면 나중에 맥락을 잃지 않습니다.

예를 들어 이렇게 정리할 수 있습니다.

• 반영: 버튼 문구를 다음에서 인증번호 받기로 변경

• 논의 필요: 약관 동의 화면을 별도 단계로 분리할지 여부

• 보류: 소셜 로그인 추가는 2차 범위에서 검토

• 확인 완료: 이메일 입력 오류 상태는 기존 정책 유지

이렇게 정리하면 피드백은 감상이 아니라 실행 계획이 됩니다. 특히 기획자와 개발자가 함께 보는 프로젝트에서는 코멘트를 그대로 두지 말고, 이슈 관리 도구나 작업 문서에 옮길 항목을 구분하는 것이 좋습니다. 피그마는 화면 위 피드백에 강하고, Jira, Linear, Notion 같은 도구는 일정과 담당자 관리에 강합니다. 각 도구의 역할을 나누면 협업이 더 깔끔해집니다.

회의 시간을 줄이는 피그마 리뷰 방식

피그마 코멘트를 잘 쓰면 회의가 짧아집니다. 회의를 없애자는 뜻이 아닙니다. 회의에서 다룰 가치가 있는 문제만 남기자는 뜻입니다.

좋은 리뷰 흐름은 보통 이렇게 진행됩니다. 먼저 담당자가 리뷰 범위와 마감을 정해 링크를 공유합니다. 팀원은 각자 가능한 시간에 파일을 열고 코멘트를 남깁니다. 담당자는 코멘트를 읽고 바로 처리할 수 있는 것은 수정합니다. 의견이 갈리는 내용만 회의 안건으로 정리합니다. 회의에서는 이미 코멘트로 확인된 내용을 반복 설명하지 않고, 결정이 필요한 쟁점만 이야기합니다.

이 방식의 장점은 명확합니다. 조용히 생각할 시간이 생기고, 말이 빠른 사람의 의견만 강해지는 일을 줄일 수 있습니다. 개발자는 구현 관점에서 차분히 확인할 수 있고, 기획자는 정책 누락을 꼼꼼히 볼 수 있습니다. 디자이너는 피드백을 화면 위치와 함께 받을 수 있어 수정이 쉬워집니다.

회의 후에는 결정된 내용을 다시 피그마 코멘트나 파일 안의 메모로 남겨야 합니다. 결정이 말로만 남으면 며칠 뒤 사라집니다. 피그마 파일 안에 기록이 남아 있으면 다음 리뷰 때 같은 이야기를 반복하지 않아도 됩니다.

리뷰 운영 박스 · 회의 전후로 이렇게 하세요
회의 전에는 코멘트로 먼저 의견을 받습니다.
회의에서는 의견이 갈리는 항목만 다룹니다.
결정된 내용은 코멘트 답글이나 파일 내 메모로 남깁니다.
반영된 항목은 해결 처리해 남은 이슈만 보이게 합니다.
다음 리뷰 범위와 마감을 마지막에 다시 정합니다.

협업 중 충돌을 줄이는 작업 습관

피그마는 여러 사람이 동시에 작업할 수 있는 도구입니다. 커서가 함께 보이고, 누가 어디를 보고 있는지도 확인할 수 있습니다. 이 실시간 협업은 매우 편리하지만, 동시에 조심해야 합니다. 같은 프레임을 여러 사람이 동시에 수정하면 의도치 않은 변경이 생길 수 있습니다.

여러 명이 한 파일에서 작업할 때는 영역을 나누는 것이 좋습니다. 예를 들어 한 사람은 회원가입 플로우, 다른 사람은 로그인 플로우, 또 다른 사람은 공통 컴포넌트를 맡는 식입니다. 같은 화면을 동시에 수정해야 한다면, 먼저 메신저나 코멘트로 "제가 이 프레임 수정하겠습니다"라고 알려 주세요. 사소해 보이지만 충돌을 크게 줄여 줍니다.

레이어 이름과 프레임 이름도 협업의 일부입니다. 혼자 작업할 때는 Rectangle 88이어도 당장 큰 문제가 없을 수 있습니다. 하지만 팀원이 파일을 열면 그 이름은 곧 혼란이 됩니다. 특히 개발자에게 전달될 화면에서는 레이어 구조가 너무 엉켜 있으면 의도를 파악하기 어렵습니다.

협업을 고려한 파일은 다음과 같은 습관을 가집니다.

• 주요 프레임에는 화면 목적이 드러나는 이름을 붙입니다.

• 실험 중인 요소는 리뷰 화면과 분리합니다.

• 공통 컴포넌트는 임의로 분해하지 않습니다.

• Auto Layout이나 Constraints를 바꿀 때는 영향 범위를 확인합니다.

• 큰 수정 전에는 버전 이름을 남기거나 Branch를 사용합니다.

이런 습관은 처음에는 번거롭게 느껴질 수 있습니다. 하지만 파일이 커질수록 차이가 커집니다. 정리된 파일은 새로운 팀원이 들어와도 빠르게 이해할 수 있고, 오래된 프로젝트를 다시 열어도 맥락을 잃지 않습니다.

외부 공유 시 조심해야 할 것들

외부 클라이언트, 파트너, 사용자 테스트 참여자에게 피그마 링크를 공유할 때는 내부 공유보다 더 신중해야 합니다. 피그마 파일 안에는 보이는 화면 외에도 이전 시안, 내부 메모, 정책 논의 흔적, 아직 공개하면 안 되는 기능이 들어 있을 수 있습니다.

외부에 공유하기 전에는 공유 범위를 줄이는 것이 좋습니다. 전체 작업 파일을 그대로 보내기보다, 외부 검토용 페이지나 별도 파일을 만들어 필요한 화면만 담는 방식이 안전합니다. 프로토타입으로 보여줄 경우에는 실제 캔버스 전체가 아니라 실행 화면 중심으로 안내할 수 있습니다.

또한 코멘트 권한도 확인해야 합니다. 외부 리뷰어가 코멘트를 남겨야 한다면 가능하도록 설정하되, 편집 권한은 주지 않는 것이 일반적입니다. 파일 안의 민감한 페이지가 보이지 않도록 정리하고, 필요 없는 에셋이나 내부용 메모는 제거하거나 별도 파일로 분리하세요.

외부 공유 체크 박스
내부 논의용 페이지가 포함되어 있지 않은지 확인합니다.
외부 검토에 필요한 화면만 별도 페이지나 파일로 정리합니다.
링크 접근 범위가 너무 넓게 열려 있지 않은지 확인합니다.
편집 권한이 아니라 보기 권한으로 공유합니다.
리뷰가 끝나면 링크 접근 권한을 다시 정리합니다.

실무 예시: 회원가입 화면 리뷰 흐름 만들기

앞 장들에서 우리는 프레임, 텍스트, 컬러, Auto Layout, Components, Variants, Variables, Prototype, 와이어프레임을 차례로 다뤘습니다. 이제 이 모든 결과물을 팀과 함께 검토하는 상황을 생각해 보겠습니다.

회원가입 화면 1차 시안을 만들었다면 먼저 Review / Signup v1 페이지를 만듭니다. 그 안에 검토할 화면만 순서대로 배치합니다. 각 프레임 이름은 01 Splash, 02 Email Input, 03 Verification Code, 04 Profile Setup, 05 Complete처럼 흐름이 보이게 정리합니다. 화면 위에는 작은 텍스트로 리뷰 안내를 적습니다.

예를 들어 안내 문구는 이렇게 쓸 수 있습니다.

검토 범위: 회원가입 기본 플로우 1차 시안
확인할 내용: 화면 흐름, 입력 항목, 오류 상태, CTA 문구
제외할 내용: 최종 비주얼 디테일, 애니메이션, 마케팅 문구
마감: 2026-05-13 오후 5시
피드백 방식: 화면 위에 Comment로 남기기

그다음 Share에서 기획자, 개발자, 디자이너에게 적절한 권한을 설정합니다. 기획자와 개발자는 보기 권한으로도 충분할 수 있습니다. 함께 디자인을 수정할 디자이너에게는 편집 권한을 부여합니다. 링크를 보낼 때는 리뷰 범위와 마감 시간을 다시 적습니다.

리뷰가 시작되면 기획자는 "휴대폰 인증이 필수인지 선택인지 정책 확인 필요"라는 코멘트를 남길 수 있습니다. 개발자는 "인증번호 재전송 제한 시간이 필요합니다"라고 남길 수 있습니다. 디자이너는 "오류 상태의 입력창 색상이 기존 Text Field Variant와 다릅니다"라고 남길 수 있습니다. 이 코멘트들은 모두 화면 위 특정 위치에 남기므로, 나중에 수정할 때 헷갈리지 않습니다.

리뷰 후 담당자는 코멘트를 분류합니다. 문구 수정처럼 바로 반영할 수 있는 것은 수정하고 해결 처리합니다. 정책 확인이 필요한 것은 기획자를 멘션해 답변을 기다립니다. 개발 영향이 큰 것은 회의 안건으로 옮깁니다. 큰 구조 변경이 필요하다면 Branch를 만들어 안전하게 수정안을 실험합니다. 수정 전에는 Version History에 Before signup review changes처럼 이름을 남깁니다.

이 흐름이 바로 실무 피그마 협업입니다. 단순히 화면을 공유하는 것이 아니라, 파일을 정리하고, 피드백을 모으고, 수정 방향을 기록하고, 변경 이력을 남기는 과정입니다.

피그마 협업에서 자주 생기는 문제와 해결법

협업 기능을 처음 쓰면 몇 가지 문제가 반복해서 생깁니다. 대부분 기능을 몰라서라기보다 약속이 없어서 생기는 문제입니다.

첫 번째 문제는 코멘트가 너무 많아져서 무엇부터 해야 할지 모르는 상황입니다. 이럴 때는 모든 코멘트를 즉시 수정하려 하지 말고 분류부터 해야 합니다. 반영, 논의 필요, 보류, 확인 완료로 나누면 우선순위가 보입니다.

두 번째 문제는 최신 화면이 어디인지 모르는 상황입니다. 이 문제는 페이지와 섹션 정리로 해결합니다. 리뷰용 페이지를 따로 만들고, 과거 시안은 Archive로 옮기세요. 최신 화면에는 Current, Review, Ready for Dev처럼 상태가 드러나는 라벨을 붙이면 좋습니다.

세 번째 문제는 누군가 실수로 중요한 요소를 바꾸는 상황입니다. 이때는 Version History로 변경 시점을 확인하고, 필요하면 이전 상태를 참고해 복구합니다. 앞으로 같은 문제가 반복되지 않도록 편집 권한을 정리하고, 큰 수정은 Branch에서 진행하는 규칙을 세우세요.

네 번째 문제는 피드백이 취향 싸움으로 번지는 상황입니다. 이때는 사용자 목표, 비즈니스 목표, 구현 제약을 기준으로 대화해야 합니다. "저는 이 색이 좋아요"보다 "이 색은 비활성 버튼과 구분이 어렵습니다"가 더 좋은 피드백입니다.

문제 해결 박스 · 협업이 꼬였을 때 먼저 볼 것
최신 화면 위치가 명확한지 확인합니다.
리뷰 범위와 마감 시간이 안내되었는지 확인합니다.
권한이 필요 이상으로 열려 있지 않은지 확인합니다.
해결된 코멘트와 남은 코멘트가 구분되어 있는지 확인합니다.
큰 수정 전 버전 기록이나 Branch가 있는지 확인합니다.

협업의 목표는 완벽한 파일이 아니라 빠른 합의입니다

피그마 파일을 정리하다 보면 어느 순간 정리 자체가 목적이 될 때가 있습니다. 모든 레이어 이름을 완벽하게 바꾸고, 모든 페이지를 아름답게 구성하고, 모든 코멘트를 문서처럼 정리하려고 합니다. 물론 정리는 중요합니다. 하지만 협업의 최종 목표는 완벽한 파일이 아닙니다. 팀이 같은 화면을 보고 빠르게 합의하는 것입니다.

좋은 협업 파일은 보는 사람이 길을 잃지 않습니다. 피드백을 남기기 쉽고, 남은 이슈가 보이며, 변경 이력이 추적됩니다. 그리고 무엇보다 팀원이 안심하고 의견을 낼 수 있습니다. "이거 혹시 제가 잘못 건드리면 어떡하죠?"라는 불안이 줄어들면, 더 많은 사람이 디자인 과정에 참여할 수 있습니다.

디자인은 디자이너 혼자 만드는 결과물이 아니라 팀이 함께 결정한 경험입니다. 피그마의 공유, 코멘트, Branch, Version History는 그 결정을 빠르고 안전하게 만드는 도구입니다.

다음 장에서는 이렇게 정리된 디자인을 개발자에게 전달하는 방법을 다룹니다. Dev Mode를 통해 간격, 색상, 에셋, 코드 힌트를 확인하고, 개발 핸드오프 과정에서 놓치기 쉬운 부분을 살펴보겠습니다.

핵심 요약

• 피그마 협업의 핵심은 링크를 보내는 것이 아니라 역할, 범위, 권한, 기록을 명확히 하는 것입니다.

• 팀과 프로젝트 구조를 정리하면 파일을 찾기 쉽고 권한 관리도 쉬워집니다.

• Share에서는 링크 접근 범위와 보기·편집 권한을 상황에 맞게 설정해야 합니다.

• 피드백 요청 메시지에는 검토 범위, 확인할 내용, 마감 시간, 코멘트 방식이 포함되어야 합니다.

• Comment는 화면 위에 직접 피드백을 남기는 기능이며, 멘션과 답글, 해결 처리를 함께 사용해야 흐름이 정리됩니다.

• 리뷰 전에는 최신 화면, 과거 시안, 검토 범위, 프레임 이름, 프로토타입 연결 상태를 정리해야 합니다.

• Version History는 변경 이력을 확인하고 중요한 시점으로 돌아볼 수 있게 해 주는 안전장치입니다.

• Branch는 원본 파일을 바로 건드리지 않고 큰 수정이나 실험을 안전하게 진행하는 방법입니다.

• Merge는 변경사항을 무작정 합치는 것이 아니라 리뷰 후 원본에 반영하는 과정입니다.

• 협업의 목표는 완벽한 파일이 아니라 팀이 같은 기준으로 빠르게 합의하는 것입니다.

실습 과제

이번 실습에서는 팀 리뷰용 링크를 공유하고, 코멘트 기반 수정 목록을 정리하는 흐름을 연습합니다. 실제 팀원이 없다면 혼자 두 역할을 번갈아 수행해도 좋습니다.

과제 1. 리뷰용 페이지 만들기

기존에 만든 로그인 또는 회원가입 화면 파일을 엽니다. 새 페이지나 섹션을 만들고 이름을 Review / 날짜 형식으로 지정합니다. 예를 들어 Review / 2026-05-13처럼 작성합니다.

그 안에 검토할 프레임만 복사해 순서대로 배치합니다. 프레임 이름은 01 Login, 02 Email Input, 03 Error State, 04 Success처럼 화면 흐름이 보이게 정리합니다. 과거 시안이나 실험 화면은 리뷰용 페이지에 넣지 않습니다.

과제 2. 리뷰 안내문 작성하기

리뷰용 페이지 상단에 텍스트 박스를 만들고 다음 내용을 적습니다.

• 검토 범위

• 확인할 내용

• 제외할 내용

• 피드백 마감 시간

• 피드백을 남기는 방식

예시는 다음과 같습니다.

검토 범위: 로그인 화면 1차 시안
확인할 내용: 입력 흐름, 오류 상태, 버튼 문구
제외할 내용: 최종 일러스트와 애니메이션
마감: 오늘 오후 5시
방식: 화면 위에 Comment로 남기기

과제 3. 공유 권한 설정하기

오른쪽 위 Share 버튼을 눌러 공유 설정을 엽니다. 실제 팀원이 있다면 보기 권한으로 초대합니다. 혼자 실습한다면 링크 공유 범위와 권한 옵션이 어디에 있는지 확인만 해도 됩니다.

다음 기준으로 권한을 점검하세요.

• 리뷰만 하는 사람에게 편집 권한을 주지 않았는가

• 링크 접근 범위가 의도보다 넓게 열려 있지 않은가

• 외부 공유가 필요한 경우 별도 파일이나 페이지로 정리했는가

• 리뷰가 끝난 뒤 권한을 회수할 수 있는지 확인했는가

과제 4. 코멘트 5개 남기기

Comment 도구를 사용해 화면 위에 최소 5개의 코멘트를 남깁니다. 실제 팀원이 없다면 스스로 리뷰어가 되었다고 가정하고 작성하세요.

코멘트는 다음 유형을 골고루 포함해 봅니다.

• 문구 수정 제안

• 화면 흐름 질문

• 오류 상태 누락 지적

• 개발 구현 확인 요청

• 디자인 일관성 확인 요청

좋은 코멘트 예시는 다음과 같습니다.

이메일 입력 오류 상태에서 안내 문구가 없습니다. 사용자가 무엇을 고쳐야 하는지 알 수 있도록 올바른 이메일 형식으로 입력해 주세요 문구를 추가하면 좋겠습니다.

과제 5. 코멘트를 수정 목록으로 정리하기

남겨진 코멘트를 읽고 아래 네 가지로 분류합니다. 피그마 파일 안에 작은 표를 만들어도 좋고, 별도 문서에 정리해도 좋습니다.

• 반영

• 논의 필요

• 보류

• 확인 완료

각 항목에는 담당자와 처리 방향을 함께 적습니다. 예를 들어 반영 / 디자이너 / 오류 문구 추가, 논의 필요 / 기획자 / 휴대폰 인증 필수 여부 확인처럼 작성합니다.

과제 6. 버전 이름 남기기

수정하기 전 Version History에서 현재 상태에 이름을 남깁니다. 이름은 Before review changes, 리뷰 수정 전, Login v1 review처럼 나중에 알아볼 수 있게 작성합니다.

그다음 코멘트 중 바로 반영할 수 있는 항목 2개를 수정하고, 해당 코멘트를 해결 처리합니다. 수정 후 다시 Version History에서 변경 시점을 확인해 보세요.

과제 7. Branch 흐름 상상해 보기

사용 중인 플랜에서 Branch 기능을 사용할 수 있다면 새 Branch를 만들어 큰 수정안을 실험해 보세요. 사용할 수 없다면 다음 질문에 답하면서 Branch가 필요한 상황을 정리해 봅니다.

• 원본 파일에서 바로 수정하면 위험한 부분은 무엇인가

• 이 수정이 영향을 주는 컴포넌트나 화면은 무엇인가

• 누가 리뷰한 뒤 원본에 반영해야 하는가

• Merge 전에 확인해야 할 기준은 무엇인가

이 실습을 마치면 피그마 파일은 단순한 디자인 화면이 아니라 팀의 의사결정 공간이 됩니다. 이제 여러분은 화면을 공유하는 사람을 넘어, 리뷰 흐름을 설계하는 사람에 가까워졌습니다.