“기획서는 없고, 피그마만 있는데요. 이걸로 충분하지 않나요?”
요즘 들어 가장 자주 듣는 말이다.
특히 실무 기획자 없이 대표나 디자이너가 직접 아이디어를 정리하는 스타트업일수록
“피그마로 다 만들었어요”라는 말이 빠지지 않는다.
그리고 나는 항상 그다음 질문을 던진다.
“이 피그마는 누구 기준으로 완성인가요?”
“각 화면에서 일어나는 행동 흐름은 어디에 적혀 있나요?”
그러면 대부분 조용해진다.
피그마는 분명히 강력한 도구다.
화면 설계, 구성 흐름, 사용자 동선까지 직관적으로 표현할 수 있고,
기획자와 디자이너가 협업하기에도 훌륭하다.
그래서 많은 스타트업이 피그마만으로도 충분히 ‘기획이 끝났다고’ 생각한다.
하지만 개발자 입장에서 피그마는 ‘그림’일 뿐이다.
기획이 아니라, 디자인이다.
행동을 추론하게 만드는 자료지, 로직을 정의하는 문서가 아니다.
피그마를 처음 열었을 때 개발자가 하는 생각은 이렇다:
- 이 버튼을 누르면 어떤 로직이 실행되나?
- 여기서 뒤로 가면 어디로 이동하나?
- 이 화면은 로그인 전에도 접근 가능한가?
- 이 리스트는 어떤 API에서 받아오는가?
- 예외 상황, 로딩 상태, 실패 응답 시에는 어떻게 보여줄 건가?
이런 건 피그마에 없다.
있어도 디자인 텍스트 박스로 적혀 있을 뿐,
실제 로직 구조나 처리 흐름이 포함되어 있지 않다.
특히 MVP 단계 스타트업은 ‘속도’에 집착한다.
그래서 피그마를 기준으로 바로 개발에 들어가려 한다.
“이대로 만들어주세요”라는 말로 프로젝트를 시작한다.
하지만 그 결과는 대부분 중간에서 멈추거나, 다시 돌아간다.
왜냐하면 개발은 ‘보이는 것’보다 ‘작동하는 것’이 훨씬 중요하기 때문이다.
디자인은 예쁘게 그릴 수 있지만,
실제로 동작하려면 상태 관리, API 연동, 조건 분기, 에러 처리 같은
수많은 보이지 않는 것들이 필요하다.
그런데 그게 전혀 정의되지 않은 상태에서
피그마만 가지고 개발을 시작하면, 개발자는 결국 추측에 의존하게 된다.
그리고 그 추측은 언제나 오해를 만든다.
실제 사례가 있다.
한 클라이언트는 피그마를 100% 기준으로 기획을 마쳤다고 했다.
화면 수도 많았고, 플로우도 나쁘지 않았다.
그래서 개발을 시작했는데,
3주 차쯤 다음과 같은 요구가 나왔다.
“이 버튼 누르면 알림이 가야 되는데요, 왜 안 되죠?”
“마이페이지엔 구독 내역도 보여줘야죠.”
“이건 당연히 들어가는 기능인데 왜 없죠?”
나는 그 기능들을 어디에도 본 적이 없었다.
디자인에도 없고, 문서에도 없고, 대화에도 없었다.
그리고 나서 나온 말이 그거였다.
“피그마만 보고도 충분히 알 수 있지 않나요?”
정확히 말하자면,
피그마는 화면 설명이고, 개발은 기능 설명이다.
이 둘은 겹치는 영역도 있지만, 완전히 다르다.
| 화면 흐름 | ✅ 화면 간 연결 관계 | ❌ 조건 분기, 접근 제어 |
| 구성 요소 | ✅ 버튼, 입력창, 목록 등 시각 요소 | ❌ 기능별 상태 변화 |
| 동선 설계 | ✅ 사용자 플로우 | ❌ 실제 행동 조건, API 구조 |
| 예외 처리 | ❌ 없음 | ✅ 실패, 빈 값, 오류 등 처리 방식 |
| 역할 분리 | ❌ 없음 | ✅ 사용자 유형별 기능 차등 제공 |
피그마는 보기엔 다 있어 보이지만, 실제론 반만 완성된 설계서다.
나머지 반은 반드시 말로 쓰여야 한다.
아니면 그 반을 개발자가 마음대로 채우게 된다.
그리고 그건 언제나 불만을 부른다.
개발이 시작되기 전, 피그마 외에 꼭 필요한 준비는 다음과 같다.
| 기능 명세서 | 화면별 기능 정의, 각 동작의 목적과 조건 |
| API 정의 문서 | 각 기능이 사용하는 데이터 구조, 요청/응답 포맷 |
| 예외 처리 계획 | 에러 발생 시 UI, 알림, 복구 플로우 |
| 사용자 시나리오 | 서로 다른 사용자 유형의 행동 경로 |
| 상태 정의 문서 | 버튼 클릭 시 상태 변화, 전환 조건 등 |
이 다섯 가지가 없으면, 개발자는 결국 피그마를 보면서
**“이건 이렇게 만드는 게 맞겠지”**라고 가정하고 코드를 짠다.
그게 당신이 원한 게 아니더라도.
정리하자면 이렇다.
피그마는 설명을 줄여주는 도구지, 설명을 대신해주는 도구가 아니다.
보이는 화면을 만들기 위한 시각적 자료일 뿐,
시스템을 구현하기 위한 문서는 따로 존재해야 한다.
스타트업에서 가장 많이 저지르는 실수는
“우리는 피그마까지 다 했으니, 이제 개발자만 있으면 돼요”라는 믿음이다.
개발자는 그림을 보며 코드로 바꾸는 사람이 아니다.
구조를 이해하고, 흐름을 설계하고, 데이터를 다루는 사람이다.
그걸 가능하게 만드는 건 피그마가 아니라
구조화된 기획서, 명세서, 그리고 협업의 정리 수준이다.