피그마가 처음이라면 이것부터 보세요: PPT와 비교해서 쉽게 이해하기
피그마가 처음이라면 이것부터 보세요: PPT와 비교해서 쉽게 이해하기
피그마를 처음 열어본 IT 기획자는 대개 비슷한 생각을 합니다. “슬라이드는 어디 있지?”, “왜 화면이 이렇게 넓지?”, “도형은 어디서 그리지?”, “이 많은 레이어는 누가 이렇게 쌓아둔 거지?”
PPT에 익숙한 사람에게 피그마는 처음에 조금 낯설 수밖에 없습니다. 이유는 간단합니다. PPT는 슬라이드 중심으로 생각하는 도구이고, 피그마는 화면과 캔버스 중심으로 생각하는 도구이기 때문입니다.
피그마가 어려운 이유는 기능이 많아서일까요?
아닙니다. PPT와 다르게 생각해야 하기 때문입니다.
이번 글에서는 피그마를 처음 접하는 IT 기획자를 위해 PPT와 비교하면서 설명하겠습니다. 디자인 전문 용어를 줄이고, 화면설계와 개발자 협업 관점에서 이해할 수 있도록 정리했습니다.
피그마가 처음에 어렵게 느껴지는 이유
피그마가 어렵게 느껴지는 이유는 사용자가 부족해서가 아닙니다. 그동안 PPT에 익숙해진 작업 방식과 피그마의 작업 방식이 다르기 때문입니다.
PPT에서는 보통 이렇게 생각합니다.
- 1번 슬라이드에는 표지를 만든다.
- 2번 슬라이드에는 개요를 넣는다.
- 3번 슬라이드에는 화면설계 이미지를 넣는다.
- 슬라이드 순서대로 설명한다.
- 필요하면 화살표와 설명 박스를 추가한다.
반면 피그마에서는 조금 다르게 생각합니다.
- 하나의 서비스 화면을 프레임으로 만든다.
- 화면 안에 버튼, 입력창, 텍스트, 이미지가 레이어로 쌓인다.
- 여러 화면을 캔버스 위에 나란히 배치한다.
- 버튼과 화면을 프로토타입으로 연결한다.
- 수정 의견은 화면 위 특정 위치에 댓글로 남긴다.
PPT는 “문서를 넘기며 설명하는 방식”에 가깝고, 피그마는 “화면을 펼쳐놓고 함께 검토하는 방식”에 가깝습니다.
PPT와 피그마의 가장 큰 차이
PPT와 피그마는 둘 다 화면 위에 텍스트와 도형을 배치할 수 있습니다. 그래서 겉보기에는 비슷해 보입니다. 하지만 실무에서 쓰이는 목적은 꽤 다릅니다.
| 구분 | PPT | 피그마 |
|---|---|---|
| 기본 목적 | 보고, 발표, 문서 작성 | 화면 설계, 디자인 협업, 프로토타입 검토 |
| 작업 방식 | 슬라이드 순서대로 구성 | 캔버스 위에 화면을 자유롭게 배치 |
| 화면 단위 | 슬라이드 | 프레임 |
| 구성 요소 | 도형, 텍스트 박스, 이미지 | 레이어, 컴포넌트, 인스턴스 |
| 이동 흐름 | 슬라이드 순서 또는 하이퍼링크 | 프로토타입 연결 |
| 피드백 | 슬라이드 단위 댓글 | 화면 특정 위치에 댓글 |
| 기획자 활용 | 기획 의도와 정책 설명 | 화면 구조, 흐름, 예외 케이스 검토 |
이 차이를 모르고 피그마를 보면 자꾸 PPT처럼 사용하려고 합니다. 피그마 화면을 PPT 슬라이드처럼 한 장씩 정리하려고 하거나, 모든 설명을 화면 안에 텍스트 박스로 넣으려고 하는 식입니다.
피그마를 PPT처럼 쓰려고 하면 화면은 복잡해지고, 협업 장점은 줄어듭니다.
슬라이드와 프레임의 차이
PPT 사용자가 피그마를 이해할 때 가장 먼저 알아야 할 개념은 프레임입니다.
PPT의 슬라이드는 발표 자료의 한 장입니다. 반면 피그마의 프레임은 실제 서비스의 한 화면에 가깝습니다.
| 개념 | 쉽게 설명하면 | 예시 |
|---|---|---|
| PPT 슬라이드 | 보고서 또는 발표 자료의 한 페이지 | 목차, 개요, 일정표, 화면 설명 |
| 피그마 프레임 | 실제 서비스의 한 화면 | 로그인 화면, 회원가입 화면, 목록 화면, 상세 화면 |
예를 들어 로그인 기능을 기획한다고 가정해 보겠습니다. PPT에서는 로그인 화면을 한 슬라이드에 넣고, 그 옆에 설명을 적는 방식으로 작성할 수 있습니다.
피그마에서는 로그인 화면 자체를 하나의 프레임으로 만들고, 비밀번호 찾기 화면, 회원가입 화면, 오류 화면 등을 다른 프레임으로 구성합니다. 그리고 이 프레임들을 프로토타입으로 연결해 실제 사용 흐름처럼 확인할 수 있습니다.
프레임은 “디자인 영역”이라기보다 “기능 흐름을 구성하는 화면 단위”로 이해하면 쉽습니다.
도형과 레이어의 차이
PPT에서는 사각형, 원, 선, 텍스트 박스 같은 도형을 많이 사용합니다. 화면설계서를 만들 때도 도형으로 버튼을 만들고, 텍스트 박스로 안내 문구를 넣고, 화살표로 흐름을 표시합니다.
피그마에서도 화면 구성 요소가 있습니다. 다만 피그마에서는 이 요소들이 레이어로 관리됩니다.
| PPT 관점 | 피그마 관점 | 기획자가 이해할 점 |
|---|---|---|
| 도형 | Shape Layer | 버튼, 카드, 영역 박스 등으로 사용됩니다. |
| 텍스트 박스 | Text Layer | 버튼명, 안내 문구, 오류 메시지를 확인합니다. |
| 이미지 | Image Layer | 배너, 아이콘, 프로필 이미지 등을 확인합니다. |
| 그룹 | Group 또는 Frame | 여러 요소가 하나의 영역으로 묶여 있는지 봅니다. |
기획자는 모든 레이어 이름을 외울 필요는 없습니다. 다만 화면을 볼 때 “이 버튼이 어떤 요소로 구성되어 있는지”, “문구가 실제로 수정 가능한 텍스트인지”, “아이콘과 버튼 영역이 분리되어 있는지” 정도는 이해하면 좋습니다.
PPT의 도형이 화면을 그리는 재료라면, 피그마의 레이어는 화면을 구성하는 구조입니다.
하이퍼링크와 프로토타입의 차이
PPT에서도 하이퍼링크를 사용하면 특정 슬라이드로 이동할 수 있습니다. 그래서 “피그마 프로토타입도 그냥 링크 연결 아닌가?”라고 생각할 수 있습니다.
비슷한 부분도 있지만, 실무에서 느끼는 차이는 큽니다. 피그마의 프로토타입은 화면 간 이동을 실제 앱이나 웹 서비스처럼 확인하기 위한 기능에 가깝습니다.
| 구분 | PPT 하이퍼링크 | 피그마 프로토타입 |
|---|---|---|
| 주요 목적 | 슬라이드 이동 | 사용자 화면 흐름 확인 |
| 사용 방식 | 텍스트나 도형에 링크 연결 | 버튼, 카드, 메뉴 등을 다른 프레임과 연결 |
| 확인 포인트 | 어느 슬라이드로 가는지 | 사용자가 어떤 화면을 거치는지 |
| 기획자 활용 | 발표 흐름 보조 | 정상 흐름, 예외 흐름, 뒤로가기 흐름 검토 |
IT 기획자에게 프로토타입은 단순히 “클릭되는 화면”이 아닙니다. 사용자의 행동 흐름을 검토하는 도구입니다.
- 로그인 성공 후 어느 화면으로 이동하는가?
- 로그인 실패 시 어떤 메시지가 나오는가?
- 취소 버튼을 누르면 이전 화면으로 가는가?
- 저장 후 목록 화면으로 돌아가는가, 상세 화면에 남는가?
- 필수값 누락 시 사용자가 다음 단계로 넘어갈 수 있는가?
이런 질문을 프로토타입을 보며 확인하면 문서로만 검토할 때보다 누락을 줄일 수 있습니다.
댓글과 피드백 방식의 차이
PPT에도 댓글 기능이 있습니다. 슬라이드에 의견을 남기고, 답글을 달고, 수정 내용을 논의할 수 있습니다.
피그마의 댓글도 비슷해 보이지만, 실무에서는 조금 더 화면 중심적으로 쓰입니다. 특정 버튼, 특정 문구, 특정 영역 위에 바로 댓글을 남길 수 있기 때문입니다.
| 상황 | PPT 댓글 | 피그마 댓글 |
|---|---|---|
| 수정 위치 | 슬라이드 단위로 전달되는 경우가 많음 | 화면의 특정 요소에 직접 남길 수 있음 |
| 협업 방식 | 문서 검토 중심 | 화면 검토 중심 |
| 기획자 장점 | 설명 추가가 쉬움 | 어느 요소를 말하는지 명확함 |
예를 들어 “저장 버튼 문구를 등록으로 바꿔 주세요”라고 피드백을 남긴다고 해보겠습니다. PPT에서는 어떤 버튼인지 설명이 필요할 때가 많습니다. 하지만 피그마에서는 해당 버튼 위에 직접 댓글을 남길 수 있습니다.
“이 버튼명은 ‘저장’보다 ‘등록’이 더 적합합니다. 신규 데이터 생성 흐름이므로 등록으로 변경 검토 부탁드립니다.”
이렇게 남기면 단순 수정 요청이 아니라 기획 의도까지 함께 전달됩니다. 댓글 하나가 작은 정책 메모가 되는 셈입니다.
IT 기획자는 피그마를 어떻게 바라봐야 할까?
피그마를 처음 배우는 IT 기획자가 가장 조심해야 할 생각은 “나도 디자이너처럼 잘 만들어야 하나?”입니다.
기획자의 역할은 다릅니다. 피그마에서 기획자가 해야 할 일은 화면을 예쁘게 꾸미는 것이 아니라, 화면을 기준으로 기능과 정책을 점검하는 것입니다.
| 기획자가 하지 않아도 되는 것 | 기획자가 해야 하는 것 |
|---|---|
| 색상 조합을 완벽하게 고르기 | 버튼명과 기능이 맞는지 확인하기 |
| 아이콘을 직접 디자인하기 | 아이콘 의미가 사용자에게 명확한지 확인하기 |
| 모든 컴포넌트를 직접 만들기 | 공통 UI가 일관되게 쓰이는지 확인하기 |
| 고급 오토레이아웃을 완벽히 다루기 | 반응형 또는 모바일 화면에서 정책이 달라지는지 확인하기 |
| 디자인 시스템을 처음부터 설계하기 | 화면과 정책서가 서로 맞는지 확인하기 |
처음에는 피그마를 “만드는 도구”가 아니라 “읽는 도구”로 접근하는 것이 좋습니다. 화면을 읽고, 흐름을 읽고, 빠진 정책을 읽는 것입니다.
예쁘게 만드는 것이 아니라, 화면을 정확하게 읽고 질문할 수 있는 상태가 되는 것입니다.
피그마를 PPT처럼 쓰면 생기는 문제
피그마를 처음 사용할 때 PPT 방식 그대로 접근하면 아래와 같은 문제가 생길 수 있습니다.
- 화면 안에 설명 문구가 너무 많아져 실제 UI와 정책 설명이 섞입니다.
- 프레임 이름이 정리되지 않아 개발자가 어떤 화면을 봐야 하는지 헷갈립니다.
- 프로토타입 연결 없이 화면만 나열되어 사용자 흐름을 확인하기 어렵습니다.
- 예외 화면이 빠져 개발 단계에서 추가 확인이 반복됩니다.
- 수정 의견이 댓글이 아니라 별도 메신저로 흩어져 이력이 남지 않습니다.
그래서 피그마에서는 화면 안에 모든 설명을 다 넣기보다, 화면은 화면답게 정리하고 정책은 문서로 보완하는 방식이 좋습니다.
피그마에는 화면과 흐름을 정리하고, Confluence나 별도 정책서에는 조건과 예외 기준을 정리하면 협업이 안정적입니다.
2일차 핵심 정리
- 피그마가 어려운 이유는 PPT와 작업 방식이 다르기 때문입니다.
- PPT는 슬라이드 중심, 피그마는 프레임과 캔버스 중심입니다.
- PPT의 도형은 피그마에서 레이어 개념으로 이해할 수 있습니다.
- PPT의 하이퍼링크는 피그마의 프로토타입과 비슷하지만 목적이 다릅니다.
- 기획자는 피그마를 디자인 제작 도구보다 화면 검토 도구로 먼저 이해하면 좋습니다.
피그마를 처음부터 어렵게 볼 필요는 없습니다. PPT를 잘 다루던 기획자라면 이미 화면을 구성하고 설명하는 감각을 가지고 있습니다. 다만 피그마에서는 슬라이드 순서가 아니라 화면 구조와 사용자 흐름을 중심으로 생각해야 합니다.
정리하면 이렇습니다. PPT는 기획자의 생각을 문서로 정리하는 도구이고, 피그마는 그 생각을 화면 기준으로 함께 검토하는 도구입니다.
피그마는 낯선 괴물이 아니라 작업 방식이 다른 동료입니다. 처음엔 말이 조금 안 통할 뿐입니다. 프레임, 레이어, 프로토타입, 댓글만 이해해도 대화는 꽤 잘 풀립니다. 실무 도구계의 새 전학생 정도로 생각하면 됩니다.
자주 묻는 질문
더 어렵다기보다 목적과 작업 방식이 다릅니다. PPT는 슬라이드 기반 문서 작성에 익숙하고, 피그마는 화면과 캔버스 기반 협업에 익숙합니다. 그래서 처음에는 낯설지만, 프레임과 레이어 개념을 이해하면 훨씬 쉬워집니다.
비슷하게 이해할 수는 있지만 완전히 같지는 않습니다. PPT 슬라이드는 발표 자료의 한 장이고, 피그마 프레임은 실제 서비스의 한 화면에 가깝습니다. 로그인 화면, 목록 화면, 상세 화면처럼 기능 흐름의 단위로 이해하면 좋습니다.
반드시 그럴 필요는 없습니다. 기획자에게 더 중요한 것은 화면 구조, 사용자 흐름, 버튼명, 입력값, 오류 메시지, 예외 화면을 확인하는 것입니다. 디자인 제작보다 화면 검토와 협업 피드백에 먼저 익숙해지는 것이 좋습니다.
PPT 하이퍼링크는 주로 슬라이드 이동을 위한 기능입니다. 피그마 프로토타입은 사용자가 실제 서비스에서 버튼을 클릭하며 이동하는 흐름을 확인하기 위한 기능에 가깝습니다. 그래서 정상 흐름, 취소 흐름, 오류 흐름을 검토하는 데 유용합니다.
프레임, 레이어, 프로토타입, 댓글 기능부터 익히는 것이 좋습니다. 이 네 가지를 알면 피그마 파일을 열고 화면을 확인하고, 이동 흐름을 검토하고, 필요한 피드백을 남길 수 있습니다.