IT 기획자의 피그마 적응기: PPT에서 화면 협업 도구로
PPT만 쓰던 IT 기획자를 위한 피그마 입문: 화면설계가 쉬워지는 첫걸음
요즘은 PPT보다는 피그마라는 툴로 기획서를 작성하기를 요청하는 프로젝트가 많아 지고 있습니다.
제가 처음 피그마를 접한 때가 2019년이었는데요 그 때는 알려 지지 않은 툴을 배울 기회가 있어 재미있게 기획서를 작성했습니다. 하지만 다른 프로젝트로 가서는 PPT로 작성하다 보니 잊혀지고 있던 툴이었습니다.
순간 머릿속에 작은 회의실 종이 울리고 예전에 배운 피그마 툴을 다시 찾고, 시간이 없는데 하면서 기획서를 작성했습니다.
아마도 처음 피그마를 접하는 분들은 까다롭다고 느끼시겠지만, 괜찮습니다. 처음부터 피그마를 디자인 전문가처럼 다룰 필요는 없습니다. IT 기획자에게 중요한 것은 예쁜 화면을 만드는 능력이 아니라, 화면을 정확히 읽고 개발자·디자이너와 같은 기준으로 이야기하는 능력입니다.
이번 글에서는 PPT에 익숙한 IT 기획자를 위해 피그마를 최대한 쉽게 설명하겠습니다. 피그마라는 낯선 도구를 PPT 개념과 비교해 보면 생각보다 겁낼 필요가 없습니다. 도구 이름만 바뀐 것이 아니라, 일하는 방식이 조금 더 화면 중심으로 바뀐 것뿐입니다.
피그마는 무엇인가요?
피그마는 웹사이트, 모바일 앱, 관리자 페이지 같은 디지털 화면을 설계하고, 팀원들과 함께 검토하고, 화면 흐름을 확인할 수 있는 협업형 디자인 도구입니다.
피그마를 너무 어렵게 생각할 필요는 없습니다. IT 기획자 관점에서 피그마를 한 문장으로 설명하면 다음과 같습니다.
여기서 중요한 단어는 “디자인”보다 “협업”입니다. 기획자가 피그마를 배운다는 것은 디자이너처럼 색상과 그래픽을 정교하게 다룬다는 뜻이 아닙니다. 화면 구조를 보고, 사용 흐름을 확인하고, 정책 누락을 찾아내고, 개발자에게 필요한 기준을 더 정확하게 전달하는 것입니다.
PPT가 보고서와 발표 자료를 만드는 데 익숙한 도구라면, 피그마는 실제 서비스 화면을 중심으로 협업하기 좋은 도구입니다.
PPT와 피그마는 무엇이 다를까요?
PPT와 피그마는 둘 다 화면 위에 도형, 텍스트, 이미지 등을 배치할 수 있습니다. 그래서 처음에는 비슷해 보입니다. 하지만 두 도구의 목적은 다릅니다.
| 구분 | PPT | 피그마 |
|---|---|---|
| 주요 목적 | 발표, 보고, 문서 작성 | 화면 설계, 디자인 협업, 프로토타입 검토 |
| 작업 단위 | 슬라이드 | 프레임 |
| 화면 흐름 | 슬라이드 순서 또는 하이퍼링크로 표현 | 프로토타입으로 실제 클릭 흐름처럼 연결 |
| 협업 방식 | 파일 공유, 댓글, 공동 편집 | 실시간 공동 편집, 화면 위 댓글, 링크 공유 |
| 개발 협업 | 별도 설명 문서가 필요한 경우가 많음 | 화면 기준으로 요소, 간격, 흐름 확인 가능 |
| 기획자 활용 포인트 | 기획 의도와 정책 정리 | 화면 구조, 사용자 흐름, 예외 케이스 검토 |
PPT는 생각을 정리하고 보고하는 데 강합니다. 반면 피그마는 여러 사람이 같은 화면을 보면서 “이 버튼을 누르면 어디로 가는가?”, “오류 메시지는 어디에 나오는가?”, “빈 데이터일 때는 어떤 화면을 보여주는가?” 같은 질문을 하기 좋습니다.
PPT는 문서 중심 도구에 가깝고, 피그마는 화면 중심 협업 도구에 가깝습니다.
PPT 사용자라면 피그마를 이렇게 이해하세요
피그마가 어렵게 느껴지는 이유는 완전히 새로운 도구처럼 보이기 때문입니다. 하지만 PPT에서 쓰던 개념과 연결하면 훨씬 쉽게 이해할 수 있습니다.
| PPT에서 익숙한 개념 | 피그마에서 비슷한 개념 | IT 기획자 관점 설명 |
|---|---|---|
| 슬라이드 | 프레임 | 하나의 화면 단위입니다. 로그인 화면, 목록 화면, 상세 화면처럼 생각하면 됩니다. |
| 도형 | 레이어 | 버튼, 입력창, 텍스트, 이미지 등 화면을 구성하는 요소입니다. |
| 그룹 | 그룹 또는 프레임 | 여러 요소를 묶어서 하나의 영역처럼 다루는 방식입니다. |
| 마스터 슬라이드 | 컴포넌트 | 반복해서 쓰는 버튼, 헤더, 메뉴 등을 재사용하기 위한 원본입니다. |
| 복사한 도형 | 인스턴스 | 컴포넌트를 복제해서 쓰는 요소입니다. 원본과 연결되어 있어 관리가 쉽습니다. |
| 하이퍼링크 | 프로토타입 | 버튼 클릭 시 어떤 화면으로 이동하는지 연결하는 기능입니다. |
| 댓글 | 댓글 | 화면 특정 위치에 바로 피드백을 남길 수 있습니다. |
가장 먼저 기억해야 할 것은 프레임은 PPT의 슬라이드와 비슷하지만 완전히 같지는 않다는 점입니다.
PPT의 슬라이드는 보통 발표 순서에 따라 배치됩니다. 하지만 피그마의 프레임은 실제 서비스 화면 단위에 가깝습니다. 예를 들어 로그인 화면, 회원가입 화면, 비밀번호 찾기 화면, 메인 화면이 각각 하나의 프레임이 될 수 있습니다.
PPT 슬라이드가 “보고서의 한 장”이라면, 피그마 프레임은 “서비스의 한 화면”입니다.
IT 기획자가 피그마를 배워야 하는 이유
IT 기획자가 피그마를 배워야 하는 이유는 단순히 요즘 많이 쓰는 도구이기 때문만은 아닙니다. 더 중요한 이유는 개발자와 디자이너가 보는 화면 기준에 기획자도 함께 올라타야 하기 때문입니다. 회의실 책상 위에 같은 지도를 펼치는 셈입니다.
1. 화면 기준으로 대화할 수 있습니다
PPT로 화면설계서를 만들 때는 화면 설명과 정책 설명이 분리되는 경우가 많습니다. 문서에는 “저장 버튼 클릭 시 저장 처리”라고 적혀 있지만, 실제 화면에서는 저장 버튼의 위치, 상태, 비활성 조건, 오류 메시지 위치가 명확하지 않을 수 있습니다.
피그마를 사용하면 화면을 보면서 바로 질문할 수 있습니다.
- 이 버튼을 클릭하면 어느 화면으로 이동하나요?
- 저장 실패 시 오류 메시지는 어디에 표시되나요?
- 필수값을 입력하지 않으면 어떤 안내 문구가 나오나요?
- 데이터가 없을 때 빈 화면은 준비되어 있나요?
- 모바일과 PC에서 같은 정책을 사용하나요?
2. 화면 흐름을 더 쉽게 확인할 수 있습니다
PPT에서도 하이퍼링크를 사용하면 화면 이동을 표현할 수 있습니다. 하지만 피그마의 프로토타입은 사용자가 실제로 버튼을 클릭하며 화면을 이동하는 것처럼 흐름을 확인하기 좋습니다.
기획자에게 프로토타입은 매우 유용합니다. 사용자가 어떤 순서로 화면을 지나가는지, 중간에 빠진 화면은 없는지, 뒤로가기나 취소 버튼을 눌렀을 때 흐름이 자연스러운지 확인할 수 있기 때문입니다.
3. 피드백 위치가 명확해집니다
PPT나 문서로 피드백을 주고받을 때는 이런 일이 자주 생깁니다.
“어떤 두 번째 화면인가요?”
“아까 회의 때 봤던 그 화면이요.”
“그 화면이 여러 개인데요?”
피그마에서는 화면의 특정 위치에 댓글을 남길 수 있습니다. 그래서 “어느 화면의 어느 부분을 말하는지”가 훨씬 명확해집니다. 피드백이 허공에 둥둥 떠다니지 않고, 화면 위에 착지합니다.
4. 개발 전달 기준을 맞추기 좋습니다
개발자에게 화면을 전달할 때 가장 중요한 것은 기준입니다. 어떤 화면이 최종본인지, 어떤 프레임을 기준으로 개발해야 하는지, 예외 화면은 어디에 있는지 명확해야 합니다.
피그마를 잘 활용하면 개발자와 이런 기준을 함께 확인할 수 있습니다.
- 최종 개발 기준 프레임은 무엇인가?
- 반응형 화면 또는 모바일 화면이 따로 있는가?
- 공통 컴포넌트는 어떤 기준으로 쓰는가?
- 오류, 빈 데이터, 로딩 화면이 준비되어 있는가?
- 정책 문서는 어디에 연결되어 있는가?
기획자가 처음 알아야 할 피그마 용어 5가지
처음부터 피그마의 모든 기능을 외우려고 하면 금방 지칩니다. IT 기획자라면 우선 아래 5가지만 이해해도 실무 회의에서 훨씬 편해집니다.
| 용어 | 쉬운 설명 | 기획자가 봐야 할 것 |
|---|---|---|
| 프레임 | 하나의 화면 단위 | 이 화면이 어떤 기능의 어떤 단계인지 확인합니다. |
| 레이어 | 화면을 구성하는 개별 요소 | 버튼, 입력창, 문구, 이미지가 빠지지 않았는지 봅니다. |
| 컴포넌트 | 반복해서 쓰는 UI 원본 | 공통 버튼, 메뉴, 헤더가 일관되게 쓰이는지 확인합니다. |
| 프로토타입 | 화면 간 이동 흐름 | 클릭 후 이동 화면, 취소, 뒤로가기 흐름을 확인합니다. |
| 댓글 | 화면 위에 남기는 피드백 | 수정 요청을 정확한 위치에 남깁니다. |
프레임 → 레이어 → 프로토타입 → 댓글 → 컴포넌트 순서로 익히면 좋습니다.
피그마를 처음 볼 때 확인해야 할 포인트
피그마 파일을 처음 열면 화면이 넓고 요소가 많아서 어디를 봐야 할지 막막할 수 있습니다. 이때는 디자이너처럼 모든 요소를 세밀하게 보려 하지 말고, 기획자 관점에서 아래 순서로 확인하면 됩니다.
1. 화면 목록을 먼저 봅니다
어떤 프레임들이 있는지 먼저 확인합니다. 로그인 화면, 회원가입 화면, 목록 화면, 상세 화면, 오류 화면처럼 기능 흐름에 필요한 화면이 모두 있는지 봅니다.
2. 사용자의 이동 흐름을 봅니다
사용자가 첫 화면에서 어떤 버튼을 누르고, 다음에 어떤 화면으로 이동하는지 확인합니다. 이때 프로토타입 연결이 되어 있다면 직접 실행해 보는 것이 좋습니다.
3. 버튼과 입력값을 확인합니다
IT 기획자는 버튼과 입력값을 특히 잘 봐야 합니다. 버튼은 사용자의 행동을 만들고, 입력값은 정책과 validation을 만듭니다.
- 필수 입력값은 표시되어 있는가?
- 버튼명은 기능과 일치하는가?
- 저장, 취소, 삭제 버튼의 위치가 명확한가?
- 비활성 상태가 필요한 버튼은 없는가?
- 입력 오류 시 안내 문구가 있는가?
4. 예외 화면을 확인합니다
실무에서 자주 빠지는 것이 예외 화면입니다. 데이터가 없을 때, 오류가 발생했을 때, 로딩 중일 때, 권한이 없을 때의 화면이 준비되어 있는지 확인해야 합니다.
빈 화면, 오류 화면, 로딩 화면, 권한 없음 화면, 삭제 확인 팝업, 저장 실패 메시지
5. 정책 문서와 연결해서 봅니다
피그마에 화면이 있다고 해서 기획이 끝난 것은 아닙니다. 화면에는 보이는 요소가 담기지만, 정책 문서에는 보이지 않는 기준이 담깁니다.
예를 들어 회원가입 화면에 휴대폰 번호 입력란이 있다면, 정책 문서에는 이런 내용이 필요합니다.
- 휴대폰 번호는 필수값인가?
- 번호 형식은 어떻게 검증하는가?
- 이미 가입된 번호라면 어떤 메시지를 보여주는가?
- 인증번호 유효 시간은 몇 분인가?
- 인증 실패 횟수 제한이 있는가?
따라서 피그마는 화면을 보는 도구이고, 정책서는 기준을 설명하는 문서라고 이해하면 좋습니다. 둘은 경쟁 관계가 아니라 한 팀입니다. 화면과 정책이 따로 놀면 프로젝트는 금세 삐걱거립니다.
결론: 피그마는 PPT를 대체하는 도구가 아니라 협업 방식을 바꾸는 도구입니다
PPT는 여전히 좋은 도구입니다. 보고서, 제안서, 회의 자료, 정책 설명 문서를 만들 때 강력합니다. IT 기획자에게 PPT는 오래된 동료 같은 존재입니다.
하지만 서비스 화면을 만들고, 디자이너와 수정 의견을 주고받고, 개발자와 구현 기준을 맞춰야 하는 상황에서는 피그마가 더 적합할 때가 많습니다.
- PPT는 문서와 발표 중심 도구입니다.
- 피그마는 화면과 협업 중심 도구입니다.
- 피그마의 프레임은 PPT의 슬라이드처럼 이해하면 쉽습니다.
- 기획자는 피그마를 디자이너처럼 다룰 필요는 없습니다.
- 기획자에게 중요한 것은 화면 구조, 사용자 흐름, 정책 누락을 확인하는 능력입니다.
결국 IT 기획자에게 피그마는 “예쁜 화면을 만드는 도구”라기보다 개발자와 디자이너가 같은 화면을 보며 이야기하기 위한 협업 언어에 가깝습니다.
PPT로 생각을 정리했다면, 이제 피그마로 화면을 함께 읽는 연습을 해보면 됩니다. 처음부터 멋진 디자인을 만들 필요는 없습니다. 우선 프레임을 보고, 흐름을 확인하고, 버튼과 정책을 점검하는 것부터 시작하세요. 그렇게 하면 피그마는 낯선 외계 도구가 아니라 실무 회의의 든든한 지도책이 됩니다.
자주 묻는 질문
꼭 디자이너 수준으로 배울 필요는 없습니다. 하지만 화면을 확인하고, 프로토타입을 실행하고, 댓글로 피드백을 남길 수 있을 정도는 익혀두는 것이 좋습니다. 특히 개발자와 화면 기준으로 회의하는 일이 많다면 피그마 이해도는 실무 효율을 높이는 데 도움이 됩니다.
PPT로도 화면설계는 가능합니다. 다만 피그마는 화면 단위 관리, 프로토타입 연결, 실시간 피드백, 개발 협업 측면에서 더 편리한 부분이 있습니다. PPT는 문서 정리에 강하고, 피그마는 화면 중심 협업에 강하다고 이해하면 좋습니다.
프레임, 레이어, 프로토타입, 댓글 기능을 먼저 익히는 것이 좋습니다. 이 네 가지만 알아도 화면을 보고, 흐름을 확인하고, 수정 의견을 남기는 기본 협업이 가능합니다.
그렇지 않습니다. 피그마는 화면을 보여주는 데 강하지만, 정책서에는 조건, 예외, 권한, validation, 데이터 처리 기준 같은 내용이 필요합니다. 실무에서는 피그마 화면과 정책 문서를 함께 관리하는 방식이 안정적입니다.
먼저 프레임 목록을 보고 전체 화면 구성을 파악하세요. 그다음 프로토타입으로 이동 흐름을 확인하고, 버튼·입력값·오류 메시지·빈 화면 같은 실무 포인트를 점검하면 됩니다.