피그마와 화면설계서 차이, 기획 문서 이렇게 바뀐다
피그마로 기획 화면을 작성하고 리뷰 시간에 피그마 링크를 공유했더니, 옆에 있던 PM이 "그럼 화면설계서는 언제 나오나요"라고 물어본 적이 있습니다. 화면을 이미 다 보여줬는데 왜 별도 문서가 또 필요하냐는 질문이었습니다.
이 질문에 제대로 답하지 못하면 결국 두 문서를 이도저도 아니게 만들다가 시간만 낭비하게 됩니다. 오늘은 피그마와 화면설계서가 근본적으로 어떻게 다른지, 그래서 기획 문서 체계를 어떻게 다시 짜야 하는지 정리해보겠습니다.
피그마와 화면설계서는 애초에 만들어진 목적이 다르다
피그마는 디자인과 프로토타이핑 툴입니다. 화면이 어떻게 보이는지, 화면 사이를 어떻게 이동하는지를 시각적으로 보여주는 데 강점이 있습니다. 이해 관계자에게 서비스의 인상을 빠르게 전달하고 싶을 때 피그마만큼 효율적인 수단은 없습니다.
반면 화면설계서는 전통적으로 그 화면 뒤에 있는 로직을 텍스트로 정의하는 문서였습니다. 이 버튼을 눌렀을 때 어떤 조건이면 어떤 결과가 나오는지, 값이 비어있을 때는 어떻게 처리하는지, 권한에 따라 무엇이 달라지는지 같은 내용입니다.
건축에 비유하면 피그마는 조감도에 가깝고, 화면설계서는 시공 도면에 가깝습니다. 조감도만 보고는 배관이 어디로 지나가는지, 벽이 하중을 어떻게 견디는지 알 수 없습니다. 화면도 마찬가지로, 보이는 모습만으로는 그 안의 동작 조건까지 다 담을 수 없습니다.
실제 사례: 피그마 링크 하나로 개발팀에 넘겼다가 벌어진 일
저는 예전에 신규 기능을 기획하면서 피그마 링크 하나만 개발팀에 전달한 적이 있습니다. 화면 구성도 꼼꼼히 잡았고 인터랙션도 프로토타입으로 다 만들어뒀으니 충분하다고 생각했습니다.
하지만 스프린트가 시작되자마자 질문이 쏟아졌습니다. "이 입력값이 비어있으면 어떻게 되나요", "이 버튼을 연속으로 두 번 누르면 중복 요청이 되나요", "이 상태는 언제 보여줘야 하나요" 같은 질문들이었습니다. 화면에는 나타나지 않는, 하지만 반드시 정의해야 하는 부분들이었습니다.
결국 개발 착수 이틀 만에 화면설계서를 별도로 다시 만들어야 했습니다. 피그마가 부족해서가 아니라, 애초에 피그마가 답할 수 있는 질문과 없는 질문이 나뉘어 있었던 것입니다.
두 문서를 가르는 기준: "보여주는 것"과 "정의하는 것"
실무에서 쓰기 좋은 기준은 이렇습니다. 화면에 눈으로 보이는 배치, 톤, 인터랙션 흐름은 피그마가 담당합니다. 반면 화면에 직접 드러나지 않는 상태값, 예외 처리, 데이터 소스, 권한 조건은 화면설계서가 담당합니다.
쉽게 말해 "이 결정이 화면을 눈으로 봐서 알 수 있는가"를 자문해보면 됩니다. 알 수 있다면 피그마에 반영하면 되고, 알 수 없다면 반드시 텍스트로 남겨야 합니다.
실무 팁 3가지
1. 상태값과 예외 처리는 반드시 텍스트로 남긴다
화면 하나당 상태(기본/로딩/에러/빈 값)와 예외 조건을 표로 정리해두면, 피그마 화면은 대표 상태 하나만 그려도 충분합니다.
모든 상태를 피그마 프레임으로 다 그리려고 하면 화면 수만 늘어나고 관리가 어려워집니다. 대표 화면은 피그마로, 나머지 상태와 조건은 화면설계서의 표로 정리하는 방식이 효율적입니다.
2. 피그마는 최신 화면, 화면설계서는 로직의 기준점으로 역할을 나눈다
화면은 자주 바뀌므로 피그마를 항상 최신 상태로 유지하고, 정책과 로직처럼 자주 바뀌지 않는 내용은 화면설계서에 못박아 둡니다.
피그마 코멘트에 로직 세부사항까지 다 적어두면 화면이 바뀔 때마다 코멘트도 같이 정리해야 해서 유지보수 부담이 커집니다. 로직은 별도 문서에 두고, 피그마에는 그 문서로 연결되는 링크만 남기는 편이 낫습니다.
3. 두 문서를 따로 관리하지 말고 하나의 워크플로우로 연결한다
피그마 프레임 이름과 화면설계서의 화면 ID를 동일하게 맞춰두면, 두 문서를 오갈 때 헷갈리지 않습니다.
예를 들어 화면설계서에 "LOGIN-01"이라는 ID를 부여했다면, 피그마 프레임 이름도 동일하게 맞추고 화면설계서 상단에 해당 피그마 프레임 링크를 걸어둡니다. 이렇게 하면 개발자가 어느 문서를 봐야 할지 헤매지 않습니다.
마무리
- 피그마와 화면설계서는 경쟁 관계가 아니라 역할이 다른 문서입니다.
- 화면에 드러나지 않는 로직과 예외는 반드시 텍스트로 정의해야 합니다.
- 두 문서를 연결하는 규칙을 만들어두면 유지보수 부담이 크게 줄어듭니다.
FAQ
화면 구성이 단순하고 예외 처리가 거의 없는 서비스라면 가능할 수 있습니다. 다만 상태값과 예외 조건이 많아지는 시점부터는 피그마 코멘트만으로 관리하기 어려워지므로, 최소한의 텍스트 문서는 남겨두는 것을 권합니다.
코멘트는 특정 화면 요소에 대한 논의에는 유용하지만, 전체 로직을 구조적으로 정리하고 나중에 다시 찾아보기엔 한계가 있습니다. 코멘트가 흩어져 있으면 신규 입사자나 협업 부서가 전체 맥락을 파악하기 어렵습니다.
피그마로 전체 화면 흐름을 먼저 보여준 뒤, 화면설계서로 세부 로직을 설명하는 순서를 추천합니다. 큰 그림을 먼저 잡고 세부 조건을 채워나가는 편이 이해하기 쉽습니다.