바쁠수록 디자인을 관리해야 해요.

디자인 파일 그 이상인 Figma

by Learning by Doing Mar 13. 2025

진행 중인 강의 보러 가기 : https://litt.ly/lbyd

Littly

litt.ly

여러 회사를 다니면서 지켜본 결과, 생각보다 많은 팀들이 Figma를 효과적으로 관리하지 못하고 있더라고요. 이번 글에서는 Figma를 제대로 관리해야 하는 이유와 효율적인 관리 방법에 대해 설명해 드리려고 해요.

Figma가 없었던, 호랑이 담배 피던 시절

과거 Figma가 없었던, 호랑이 담배 피던 시절이 있었습니다. 그 때에는 기획자가 PPT로 와이어프레임을 그리고, 디자이너 분들이 Photoshop으로 디자인해주었어요. 그 때에는 지금과 달리 거의 모든 회사가 모두 동일한 문서들이 있었어요. 바로 스토리보드라는 제목의 파일입니다.

스토리보드 파일은 보통 PPT였고, 제품을 구현하기 위해서는 필요한 내용인 IA, 서비스/유저 흐름도, 와이어프레임 등이 담겨있었죠. 기획자가 이 스토리보드 파일을 만드는 것이 기획의 시작이었어요. 완성된 스토리보드를 바탕으로 디자이너와 개발자들이 실제 작업에 들어갔죠. 그래서 스토리보드를 잘 만드는 사람(문서의 형식과 내용이 꼼꼼한 사람)이 기획을 잘하는 사람으로 인식되었어요.

변화의 시대

언제부터 였는지는 기억이 잘 안나지만, 앱 서비스가 활성화되고 빠른 시장 출시가 기업 생존의 핵심 전략이 되면서, Sketch를 거쳐 Figma가 등장했어요. Figma의 등장은 그 때 당시만 하더라도 혁신이었어요.

"실시간 협업이 된다고?"

"이제 PDF 파일 안 줘도 되는거야?"

이제는 거의 모든 회사가 Figma로 화면 디자인을 하고 있어요. 생산성이 올라가면서 반대로 회사의 제품의 특성에 따라 필요로 하지 않는 내용들은 만들지 않게 되었습니다. 그러면서 자연스럽게 스토리보드의 중요성이 낮아졌어요. 빠른 출시를 하려면 문서 작업이 줄어야 시간이 확보할 수 있기 때문이죠. 또한 앱이나 웹 서비스가 많아지면서 기본적인 지식 수준이 많이 높아졌던 것도 한 몫했어요.

그 결과 디자인 파일은 단순이 디자인 파일 그 이상이 되었습니다. 소통의 채널로 굉장히 중요해졌어요.

소통의 도구인 디자인

소통의 도구가 되면서 디자인 파일에 대한 관리 니즈도 늘어났어요.

"이 내용 어디에 있죠? 검색해도 안나와요 ㅠㅠ"

"아, 여기 숨겨놓으셨구나! 표시 좀 해주세요~"

즉, 디자인 파일을 잘 관리하는 것이 개발자, 기획자, 디자이너 사이의 커뮤니케이션 비용을 크게 줄이는 방법 중 하나가 되었어요. 예를 들어볼까요?

IR 자료를 만들기 위해 최신 화면이 필요한데, Figma 디자인이 최신이 아니라면 어떻게 될까요?

새로 입사한 PO가 특정 페이지의 정책을 확인하고 싶을 때 어디를 봐야 할까요?

빠른 릴리즈와 문서의 최소화로 인해 디자인 파일은 이제 단순히 디자인팀이 관리하는 시안의 집합이 아닌 항상 최신 상태를 유지하면서 팀 전체의 소통 도구로 바라보게 된 것이죠.

Figma, 소통 채널로 효율적으로 관리하는 방법

제가 그동안 Figma를 관리했던 방법들을 소개해드릴게요. 알다싶이 정답은 없습니다. 이 방법을 참고해서 회사 구성원들, 같이 일하는 동료들과 제품의 특성을 반영해 리소스를 최소로 관리할 수 있는 방법을 이야기 나눠보세요!

1. 파일 구성과 썸네일 설정

앱이나 웹 서비스의 기능이 늘어날수록 페이지도 많아집니다. 파일명을 직관적으로 작성해도 어떤 디자인 파일인지 한눈에 파악하기 어렵죠. 그래서 저는 2가지 규칙을 정해서 운영했어요.

디자인 파일은 각 화면 단위로 분리하여 구성하세요

반드시 썸네일을 설정하고, 진행 상태도 함께 표시하세요

일부 회사에서는 하나의 화면을 프로젝트별로 관리하고 디자인 파일을 버전으로 관리하기도 하지만, 개인적으로는 관리 포인트가 늘어나는 것 같아 저는 그렇게 하지 않았어요.

2. 페이지 구성

각 화면 단위로 디자인 파일을 만든 다음, 페이지는 Cover, IA, Wireframe, User Scenario, Change logs 순으로 만들어 관리했어요.

여러 회사 경험을 통해 페이지 구성이 디자이너와 비디자이너 사이 커뮤니케이션 비용에 큰 영향을 미친다는 것을 알게 되었어요. 제 경험 상 Cover → IA → Wireframe/Idea → Design → User Scenario → Change Logs → Component/Source 순으로 구성했을 때 팀에서 가장 만족도가 높았고 속도가 제일 빨랐어요.

(PM/PO인 저 또한 디자이너와 함께 Wireframe/Idea 페이지에서 초안을 만들고 최종 파일을 Design 페이지에 반영하는 방식으로 일했을 때 서로 만족도가 높았어요.)

Design 페이지의 경우 {기능명_버전} 혹은 {추가된 화면명_버전}으로 페이지 이름을 설정해서 관리했는데 버전 히스토리를 보기에 매우 편리했습니다. Change Logs 같은 경우 Figma 내에 version 관리가 가능해서 이 기능으로 대체해도 무방할 것 같아요.

3. 화면 상세 설명의 명확성

Figma 디자인 파일은 모든 팀원이 볼 수 있다는 전제로 작성하는 것으로 했어요. 실제로 CEO가 IR 자료를 위해 봤었고, 개발자가 개발을 위해 봤었어요. QA가 검증을 위해 봤었고요.

그래서 디자인 화면 바로 옆에 상세 설명을 작성하고, 내용이 개발 정책인지, 사용자에게 전달될 효과인지 등을 명확히 구분하도록 했어요. 저는 각 카테고리를 나누고 아이콘으로 표시하는 방식이 가장 효과적이었습니다. 또한 화면 상세 설명은 어미를 줄인 형태(ex. 없음, 불가능, 가능 등)가 아닌 최대한 경어체로 작성하는 편이 2번 작업하지 않아도 되어서 좋았어요.