PPT로 화면설계하던 기획자가 피그마를 배워야 하는 진짜 이유
IT 기획자에게 PPT는 익숙한 도구입니다. 화면설계서를 만들고, 정책을 정리하고, 회의 자료를 준비하고, 개발자에게 설명할 때도 PPT를 자주 사용합니다. 사각형 하나 그리고, 버튼 하나 만들고, 화살표로 흐름을 연결하다 보면 어느새 화면설계서가 완성됩니다.
그런데 최근 프로젝트에서는 이런 장면이 점점 많아지고 있습니다.
“수정 의견은 피그마에 댓글로 남겨 주세요.”
“개발자는 Dev Mode에서 확인하면 됩니다.”
PPT로 일하던 기획자 입장에서는 순간 멈칫할 수 있습니다. “나는 디자인하는 사람이 아닌데 피그마까지 배워야 하나?” “화면설계서는 PPT로 만들면 되는 거 아닌가?” “피그마를 모르면 실무에서 불편한 일이 생길까?”
결론부터 말하면, IT 기획자가 피그마를 디자이너처럼 깊게 배울 필요는 없습니다. 하지만 화면을 확인하고, 흐름을 검토하고, 피드백을 남기고, 개발자와 기준을 맞출 수 있을 정도는 익혀두는 것이 좋습니다.
피그마를 배운다는 것은 디자인을 잘하겠다는 뜻이 아니라, 화면 기준으로 더 정확하게 협업하겠다는 뜻입니다.
📚 목차
PPT 화면설계가 익숙한 기획자의 현실
PPT는 IT 기획자에게 여전히 유용한 도구입니다. 보고용 문서, 제안서, 일정표, 정책 정리, 회의 자료를 만들 때 매우 편합니다. 화면설계서를 만들 때도 PPT는 진입 장벽이 낮습니다.
특히 초반 기획 단계에서는 PPT가 빠릅니다. 대략적인 화면 구조를 잡고, 정책 메모를 붙이고, 업무 흐름을 설명하기에 좋습니다.
| PPT가 강한 상황 | 이유 |
|---|---|
| 초기 아이디어 정리 | 도형과 텍스트로 빠르게 구조를 잡을 수 있습니다. |
| 보고 자료 작성 | 슬라이드 순서대로 논리를 구성하기 좋습니다. |
| 정책 설명 | 표, 문장, 예시를 함께 넣기 쉽습니다. |
| 회의 자료 준비 | 발표 흐름에 맞춰 내용을 정리하기 편합니다. |
그래서 “PPT를 쓰지 말자”는 이야기가 아닙니다. PPT는 여전히 필요합니다. 다만 서비스 화면을 만들고, 디자이너와 수정 의견을 주고받고, 개발자와 구현 기준을 맞추는 단계에서는 피그마를 함께 이해하는 것이 점점 중요해지고 있습니다.
그런데 왜 피그마를 배워야 할까요?
피그마를 배워야 하는 이유는 단순히 “요즘 많이 쓰니까”가 아닙니다. 실무에서 화면을 기준으로 일하는 방식이 늘어나고 있기 때문입니다.
예전에는 기획자가 PPT 화면설계서를 만들고, 디자이너가 디자인 파일을 만들고, 개발자는 전달받은 문서와 이미지를 참고해 개발하는 방식이 많았습니다. 이 방식은 익숙하지만 중간에 해석 차이가 생기기 쉽습니다.
| 기존 방식에서 자주 생기는 문제 | 실무 영향 |
|---|---|
| 화면설계서와 디자인 화면이 다름 | 어느 문서가 최신 기준인지 헷갈립니다. |
| 피드백이 메신저, 메일, 회의록에 흩어짐 | 수정 이력이 추적되지 않습니다. |
| 화면 흐름이 문장으로만 설명됨 | 클릭 후 이동 화면을 오해할 수 있습니다. |
| 개발자가 구현 기준 화면을 찾기 어려움 | 개발 중 재질문이 늘어납니다. |
| 오류, 빈 화면, 권한 없음 화면이 빠짐 | 개발 후반에 예외 케이스가 발견됩니다. |
피그마는 이런 문제를 줄이는 데 도움이 됩니다. 하나의 화면을 기준으로 기획자, 디자이너, 개발자가 함께 보고, 댓글을 남기고, 흐름을 확인하고, 개발 기준을 맞출 수 있기 때문입니다.
이유 1. 화면 기준으로 협업하기 쉬워집니다
PPT 화면설계서는 보통 문서 중심입니다. 기획자는 화면 옆에 설명을 붙이고, 정책을 적고, 필요한 내용을 표로 정리합니다. 이 방식은 설명에는 좋지만, 실제 화면을 기준으로 협업할 때는 한계가 있습니다.
예를 들어 개발자와 회의할 때 이런 질문이 나올 수 있습니다.
- 이 버튼은 디자인 최종본 기준인가요?
- 이 화면은 모바일 기준인가요, PC 기준인가요?
- 이 팝업은 모든 사용자에게 보이나요?
- 오류 메시지는 화면 어디에 표시되나요?
- 이 화면 다음에는 어느 화면으로 이동하나요?
피그마를 사용하면 이런 질문을 화면 위에서 바로 이야기할 수 있습니다. 기획자, 디자이너, 개발자가 같은 화면을 보며 의견을 맞추기 때문에 “제가 말한 화면은 그 화면이 아닌데요” 같은 상황이 줄어듭니다.
“회원가입 완료 후 이동 화면은 이 프레임이 맞나요?”
“저장 실패 메시지는 버튼 하단이 아니라 입력 영역 아래에 노출하는 것으로 정리할까요?”
이처럼 피그마를 알면 회의 질문이 더 구체적이 됩니다. “이거 어떻게 되나요?”가 아니라 “이 버튼을 눌렀을 때 이 프레임으로 이동하는 것이 맞나요?”라고 물을 수 있습니다.
이유 2. 사용자 흐름을 더 잘 확인할 수 있습니다
화면설계에서 중요한 것은 한 화면만 예쁘게 보는 것이 아닙니다. 사용자가 어떤 순서로 이동하는지, 중간에 막히는 지점은 없는지, 정상 흐름과 예외 흐름이 모두 준비되어 있는지를 확인해야 합니다.
PPT에서도 화면 순서를 정리할 수 있습니다. 하지만 실제 사용자가 버튼을 클릭하며 이동하는 느낌을 확인하기에는 피그마의 프로토타입이 더 적합합니다.
| 검토 항목 | PPT로 볼 때 | 피그마 프로토타입으로 볼 때 |
|---|---|---|
| 로그인 성공 | 다음 슬라이드로 설명 | 버튼 클릭 후 이동 화면 확인 |
| 로그인 실패 | 별도 설명 박스로 작성 | 오류 메시지 화면 또는 상태 확인 |
| 취소 버튼 | 문장으로 이동 정책 설명 | 실제 연결된 이전 화면 확인 |
| 저장 후 이동 | “저장 후 목록 이동”이라고 작성 | 저장 버튼 클릭 후 목록 화면 이동 확인 |
기획자는 프로토타입을 보면서 이런 질문을 할 수 있습니다.
- 사용자가 첫 화면에서 다음 행동을 바로 이해할 수 있는가?
- 버튼 클릭 후 이동 화면이 기획 의도와 맞는가?
- 취소, 뒤로가기, 닫기 버튼의 흐름이 자연스러운가?
- 오류가 발생했을 때 사용자가 다시 시도할 수 있는가?
- 권한이 없는 사용자의 흐름이 준비되어 있는가?
이유 3. 피드백 위치가 명확해집니다
실무에서 피드백이 애매하면 수정이 늦어집니다. 특히 화면이 많고 버튼도 많고 상태값도 많은 프로젝트에서는 “어느 화면의 어느 요소를 말하는지”가 매우 중요합니다.
PPT나 메신저로 피드백을 주고받으면 이런 대화가 생길 수 있습니다.
“두 번째 화면이 로그인 뒤 화면인가요, 회원가입 뒤 화면인가요?”
“오른쪽 아래 버튼 말씀하신 건가요, 하단 고정 버튼 말씀하신 건가요?”
피그마에서는 화면의 특정 위치에 댓글을 남길 수 있습니다. 버튼 위, 입력창 옆, 문구 영역 근처에 바로 의견을 남기면 디자이너와 개발자가 어느 부분을 말하는지 바로 알 수 있습니다.
| 좋지 않은 피드백 | 좋은 피드백 |
|---|---|
| 여기 문구 수정해 주세요. | 비밀번호 오류 문구를 “비밀번호를 다시 확인해 주세요.”로 수정하면 좋겠습니다. |
| 버튼 이상합니다. | 신규 생성 흐름이므로 버튼명을 “저장”보다 “등록”으로 검토하면 좋겠습니다. |
| 이 화면 빠진 것 같아요. | 검색 결과가 0건일 때의 빈 화면이 필요합니다. 안내 문구와 다시 검색 버튼을 추가 검토해 주세요. |
기획자의 댓글은 단순한 수정 요청이 아니라 기획 의도를 전달하는 도구입니다. 댓글을 잘 남기면 회의 시간이 줄고, 수정 방향도 선명해집니다.
이유 4. 개발 전달 기준이 선명해집니다
IT 기획에서 개발 전달은 매우 중요합니다. 화면이 아무리 예쁘게 정리되어 있어도 개발자가 “무엇을 기준으로 구현해야 하는지” 모르면 문제가 생깁니다.
피그마를 이해하면 개발자와 이런 기준을 더 쉽게 맞출 수 있습니다.
- 최종 개발 기준 프레임은 무엇인가?
- PC와 모바일 화면이 각각 준비되어 있는가?
- 공통 컴포넌트가 일관되게 사용되었는가?
- 버튼의 활성, 비활성 상태가 정의되어 있는가?
- 오류, 빈 데이터, 로딩, 권한 없음 화면이 있는가?
- 정책 문서와 연결되어야 하는 부분은 무엇인가?
특히 개발자와 회의할 때 피그마 화면을 기준으로 말하면 질문이 구체화됩니다.
“이 프레임을 개발 기준으로 보면 될까요?”
“이 컴포넌트는 다른 화면에서도 공통으로 사용하는 구조인가요?”
“이 버튼의 비활성 조건은 정책서에 따로 정리하겠습니다.”
피그마의 Dev Mode는 개발자가 디자인을 확인하고 구현에 필요한 정보를 살펴볼 수 있도록 돕는 인터페이스입니다. 기획자가 Dev Mode를 깊게 다룰 필요는 없지만, 개발자가 어떤 기준으로 화면을 확인하는지 정도는 알아두면 커뮤니케이션이 훨씬 쉬워집니다.
이유 5. 정책 누락을 더 빨리 발견할 수 있습니다
기획자의 중요한 역할 중 하나는 보이지 않는 정책을 챙기는 것입니다. 화면에는 버튼과 입력창이 보이지만, 그 뒤에는 조건과 예외가 숨어 있습니다. 아주 조용히 숨어 있다가 개발 막바지에 튀어나오는 작은 두더지들입니다.
예를 들어 피그마에서 회원가입 화면을 본다고 가정해 보겠습니다. 화면에는 이름, 이메일, 비밀번호, 휴대폰 번호 입력란이 있을 수 있습니다. 하지만 기획자는 여기서 멈추면 안 됩니다.
| 화면에 보이는 요소 | 기획자가 확인해야 할 정책 |
|---|---|
| 이메일 입력란 | 필수 여부, 형식 검증, 중복 가입 처리, 오류 메시지 |
| 비밀번호 입력란 | 최소 길이, 특수문자 조건, 재입력 확인, 표시/숨김 기능 |
| 휴대폰 번호 입력란 | 인증 방식, 인증번호 유효 시간, 재전송 제한, 실패 횟수 |
| 가입 버튼 | 활성 조건, 클릭 후 처리, 성공 후 이동 화면, 실패 시 안내 |
피그마는 화면을 보며 정책 누락을 찾아내기 좋은 도구입니다. 하지만 정책 자체를 모두 담는 도구는 아닙니다. 따라서 피그마 화면을 보면서 빠진 정책을 발견하고, 별도 정책서나 Confluence 문서에 정리하는 방식이 좋습니다.
피그마는 화면과 흐름을 확인하는 도구, 정책서는 조건과 예외를 설명하는 문서로 함께 관리하는 것이 좋습니다.
기획자는 피그마를 어디까지 배워야 할까요?
기획자가 피그마를 배울 때 가장 많이 하는 걱정은 “어디까지 배워야 하지?”입니다. 처음부터 디자이너 수준으로 배워야 한다고 생각하면 부담이 커집니다.
기획자는 아래 정도를 목표로 시작하면 충분합니다.
| 학습 단계 | 할 수 있어야 하는 일 | 실무 활용 |
|---|---|---|
| 1단계 | 피그마 파일 열기, 화면 확대/축소, 프레임 찾기 | 공유받은 화면을 확인할 수 있습니다. |
| 2단계 | 프레임과 레이어 구조 이해하기 | 화면 요소가 어떻게 구성되어 있는지 볼 수 있습니다. |
| 3단계 | 프로토타입 실행하기 | 사용자 흐름과 화면 이동을 검토할 수 있습니다. |
| 4단계 | 댓글로 피드백 남기기 | 수정 요청과 기획 의도를 정확한 위치에 남길 수 있습니다. |
| 5단계 | 개발 기준 프레임 확인하기 | 개발자와 화면 기준을 맞출 수 있습니다. |
처음부터 오토레이아웃, 변수, 디자인 시스템, 고급 컴포넌트까지 모두 배울 필요는 없습니다. 초반에는 화면을 “만드는 능력”보다 화면을 “읽는 능력”이 먼저입니다.
피그마를 잘 만드는 사람이 아니라, 피그마 화면을 보고 좋은 질문을 할 수 있는 사람이 되는 것입니다.
피그마를 배운 기획자의 회의 방식은 이렇게 달라집니다
피그마를 이해하면 회의에서 쓰는 말이 달라집니다. 질문이 더 구체적이고, 피드백이 더 명확해집니다.
| 피그마를 모를 때 | 피그마를 이해했을 때 |
|---|---|
| 이 화면 다음은 어디죠? | 이 버튼 클릭 시 연결된 프레임이 목록 화면이 맞나요? |
| 오류 처리는 어떻게 하나요? | 필수값 누락 시 이 입력창 아래에 오류 메시지를 노출하는 기준이 맞나요? |
| 이 버튼 좀 바꿔 주세요. | 신규 등록 흐름이므로 버튼명을 “저장”보다 “등록”으로 변경 검토 부탁드립니다. |
| 개발자는 뭘 보면 되나요? | 개발 기준 프레임을 이 페이지의 Final 영역으로 보면 될까요? |
이것이 피그마를 배워야 하는 진짜 이유입니다. 도구를 하나 더 아는 것이 아니라, 같은 화면을 보며 더 정확한 질문을 할 수 있게 되는 것입니다.
결론: 피그마는 기획자의 경쟁력이 아니라 기본 협업 언어가 되어가고 있습니다
PPT로 화면설계서를 만들던 방식은 여전히 의미가 있습니다. 기획자의 생각을 정리하고, 정책을 설명하고, 의사결정 자료를 만드는 데 PPT는 좋은 도구입니다.
하지만 서비스 화면을 실제로 만들고 검토하는 단계에서는 피그마를 이해하는 것이 큰 도움이 됩니다. 화면 기준 협업, 프로토타입 검토, 위치 기반 댓글, 개발 전달 기준 정리까지 피그마는 기획자의 실무 커뮤니케이션을 더 구체적으로 만들어 줍니다.
- PPT는 기획자의 생각과 정책을 정리하는 데 강합니다.
- 피그마는 화면 기준 협업과 사용자 흐름 검토에 강합니다.
- IT 기획자는 피그마를 디자이너처럼 다룰 필요는 없습니다.
- 기획자는 프레임, 프로토타입, 댓글, 개발 기준 화면을 이해하는 것이 중요합니다.
- 피그마를 알면 개발자와 디자이너에게 더 구체적으로 질문할 수 있습니다.
정리하면, 피그마를 배운다는 것은 PPT를 버린다는 뜻이 아닙니다. PPT로 기획을 정리하고, 피그마로 화면을 함께 검토하는 방식으로 일하는 것입니다.
IT 기획자에게 피그마는 디자인 도구라기보다 협업 언어입니다. 이 언어를 조금만 알아도 회의에서 길을 잃지 않고, 화면과 정책 사이의 빈틈을 더 빨리 발견할 수 있습니다. 화면설계자의 손전등 하나가 추가되는 셈입니다.
자주 묻는 질문
PPT 화면설계 능력은 여전히 중요합니다. 다만 디자이너와 개발자가 피그마를 기준으로 협업하는 프로젝트라면, 기획자도 피그마 화면을 읽고 댓글을 남기고 흐름을 확인할 수 있어야 커뮤니케이션이 쉬워집니다.
그렇지 않습니다. 기획자는 색상, 아이콘, 고급 디자인 시스템을 완벽히 다루는 것보다 화면 구조, 사용자 흐름, 버튼명, 입력값, 예외 화면, 정책 누락을 확인하는 것이 더 중요합니다.
아닙니다. 피그마는 화면과 흐름을 확인하는 데 강하고, 화면설계서나 정책서는 조건과 예외를 정리하는 데 필요합니다. 실무에서는 피그마와 정책 문서를 함께 관리하는 방식이 안정적입니다.
먼저 프레임 목록을 보고 전체 화면 구성을 파악하는 것이 좋습니다. 그다음 프로토타입으로 화면 이동 흐름을 확인하고, 버튼, 입력값, 오류 메시지, 빈 화면을 검토하면 됩니다.
최종 개발 기준 프레임, 버튼 클릭 후 이동 화면, 오류 처리 방식, 빈 데이터 화면, 권한 없음 화면, PC와 모바일 화면 차이, 정책 문서가 필요한 부분을 확인하는 것이 좋습니다.