IT 기획자에게 피그마가 필요한 이유: 디자인 툴이 아니라 협업 도구입니다
피그마를 처음 듣는 IT 기획자는 보통 이렇게 생각합니다.
반은 맞고, 반은 부족한 설명입니다. 피그마는 디자인 도구가 맞습니다. 하지만 IT 기획자에게 더 중요한 관점은 따로 있습니다. 피그마는 단순히 예쁜 화면을 만드는 도구가 아니라, 기획자, 디자이너, 개발자가 같은 화면을 보며 협업하는 도구입니다.
PPT로 화면설계서를 만들던 기획자에게 피그마는 처음에 낯설 수 있습니다. 슬라이드 대신 프레임이 있고, 문서 대신 캔버스가 있고, 파일 전달 대신 링크 공유와 댓글이 중심이 됩니다. 처음 보면 화면설계 도구계의 낯선 전학생처럼 보입니다.
하지만 관점을 바꾸면 훨씬 쉬워집니다. 피그마를 “디자인 제작 툴”로만 보지 말고, 화면 기준으로 의견을 모으고 결정하는 회의 공간으로 보면 됩니다.
IT 기획자에게 피그마는 디자인 실력을 보여주는 도구가 아니라, 화면을 기준으로 협업하는 실무 언어입니다.
📚 목차
피그마를 디자인 툴로만 보면 놓치는 것
피그마를 “디자이너가 쓰는 디자인 툴”로만 생각하면, IT 기획자는 자연스럽게 한 발 물러서게 됩니다.
“나는 색상 고르는 사람이 아닌데?” “나는 아이콘을 만드는 사람이 아닌데?” “나는 디자이너가 아닌데 왜 피그마를 봐야 하지?” 이런 생각이 드는 것은 자연스럽습니다.
하지만 실무에서 피그마를 사용하는 이유는 디자인 작업 자체에만 있지 않습니다. 피그마는 화면을 만들고, 공유하고, 댓글을 남기고, 프로토타입으로 흐름을 확인하고, 개발자가 구현 기준을 확인하는 과정까지 이어집니다.
| 피그마를 디자인 툴로만 볼 때 | 협업 도구로 볼 때 |
|---|---|
| 디자이너가 화면을 예쁘게 만드는 공간 | 기획자, 디자이너, 개발자가 화면 기준을 맞추는 공간 |
| 색상, 폰트, 아이콘 중심으로 봄 | 버튼, 흐름, 정책, 예외 케이스 중심으로 봄 |
| 기획자는 보기만 하면 된다고 생각함 | 기획자도 댓글과 질문으로 적극 참여함 |
| 디자인 최종본 확인에 그침 | 개발 전달 기준과 사용자 흐름까지 함께 확인함 |
피그마는 디자인 결과물을 보는 곳이 아니라, 화면을 기준으로 실무 결정을 쌓아가는 곳입니다.
IT 기획자에게 필요한 피그마의 진짜 역할
IT 기획자는 화면을 예쁘게 만드는 사람이 아니라, 기능과 정책이 사용자의 화면 안에서 제대로 작동하는지 확인하는 사람입니다.
피그마를 보면 기획자는 아래와 같은 질문을 할 수 있습니다.
- 이 화면은 어떤 사용자 흐름에 포함되는가?
- 버튼명은 실제 기능과 일치하는가?
- 필수 입력값과 선택 입력값이 구분되어 있는가?
- 저장, 취소, 삭제 후 이동 화면이 정의되어 있는가?
- 오류, 빈 화면, 로딩 화면, 권한 없음 화면이 준비되어 있는가?
- 개발자가 구현할 기준 화면은 어느 프레임인가?
이 질문들은 디자인 질문처럼 보이지만 사실은 기획 질문입니다. 버튼 하나에도 정책이 있고, 입력창 하나에도 검증 기준이 있고, 팝업 하나에도 사용자 행동 흐름이 숨어 있습니다.
피그마에서 기획자가 봐야 할 것은 “예쁜가?”보다 “이 화면이 기능과 정책을 정확히 담고 있는가?”입니다.
역할 1. 화면 기준 회의가 쉬워집니다
PPT로 회의할 때는 화면설계서, 정책서, 디자인 시안, 회의록이 따로 움직이는 경우가 많습니다. 그러다 보면 회의 중에 이런 말이 나옵니다.
“이 버튼은 디자인 시안 기준인가요, 기획서 기준인가요?”
“이 정책은 반영된 화면인가요?”
피그마를 활용하면 회의의 중심을 하나의 화면으로 모을 수 있습니다. 참여자들이 같은 화면을 보며 버튼, 입력창, 이동 흐름, 예외 화면을 함께 확인할 수 있습니다.
| 회의 상황 | PPT 중심 회의 | 피그마 중심 회의 |
|---|---|---|
| 화면 확인 | 슬라이드 또는 캡처 이미지를 기준으로 설명 | 실제 디자인 프레임을 기준으로 확인 |
| 수정 의견 | 말이나 회의록으로 정리 | 화면 특정 위치에 댓글로 남김 |
| 흐름 검토 | 문장과 화살표로 설명 | 프로토타입으로 직접 이동 확인 |
| 개발 기준 | 별도 전달 문서가 필요할 수 있음 | 개발 기준 프레임을 함께 지정 가능 |
회의에서 중요한 것은 말을 많이 하는 것이 아닙니다. 서로 같은 대상을 보고 같은 의미로 말하는 것입니다. 피그마는 이 기준점을 만들어 줍니다.
역할 2. 피드백이 흩어지지 않습니다
실무에서 피드백은 자주 흩어집니다. 누군가는 메신저에 쓰고, 누군가는 메일로 보내고, 누군가는 회의 때 말로만 전달합니다. 그러면 나중에 수정 이력을 찾을 때 작은 보물찾기 대회가 열립니다. 하지만 상품은 피로감뿐입니다.
피그마에서는 화면 위에 직접 댓글을 남길 수 있습니다. 특정 버튼, 특정 문구, 특정 영역에 의견을 달 수 있기 때문에 “어느 부분을 말하는지”가 명확해집니다.
| 흩어진 피드백 | 피그마 댓글 피드백 |
|---|---|
| 메신저에 “이 버튼 수정”이라고 남김 | 해당 버튼 위에 댓글로 수정 이유와 문구를 남김 |
| 회의록에 “오류 문구 변경”이라고 작성 | 오류 메시지 영역에 정확한 변경 문구를 남김 |
| 메일로 화면 캡처와 의견을 전달 | 피그마 링크와 댓글로 같은 화면에서 논의 |
좋은 피드백은 단순히 “수정해 주세요”가 아닙니다. 어떤 이유로, 어떤 기준에 따라, 어떤 문구로 수정해야 하는지 알려주는 피드백입니다.
“이 버튼은 기존 데이터를 수정하는 흐름이므로 ‘등록’보다 ‘저장’이 적합합니다. 문구 변경 검토 부탁드립니다.”
“검색 결과가 0건인 경우 빈 화면 문구가 필요합니다. ‘검색 결과가 없습니다. 다른 조건으로 다시 검색해 주세요.’ 문구를 검토해 주세요.”
역할 3. 사용자 흐름을 함께 검토할 수 있습니다
화면 하나만 보는 것은 비교적 쉽습니다. 하지만 실제 서비스에서는 사용자가 여러 화면을 이동합니다. 로그인하고, 목록을 보고, 상세로 들어가고, 수정하고, 저장하고, 다시 목록으로 돌아옵니다.
피그마의 프로토타입은 이런 화면 이동 흐름을 확인하는 데 도움이 됩니다. 기획자는 프로토타입을 통해 단순히 화면이 있는지 보는 것이 아니라, 사용자가 어떤 순서로 움직이는지 확인할 수 있습니다.
- 시작 화면이 명확한가?
- 주요 버튼 클릭 후 이동 화면이 맞는가?
- 취소, 닫기, 뒤로가기 흐름이 자연스러운가?
- 오류 발생 시 사용자가 다시 시도할 수 있는가?
- 권한이 없는 사용자는 어떤 화면을 보게 되는가?
특히 IT 기획자는 정상 흐름뿐 아니라 예외 흐름을 함께 확인해야 합니다. 정상 흐름은 대개 눈에 잘 보입니다. 문제는 실패, 오류, 빈 데이터, 권한 없음 같은 화면입니다. 이 친구들은 조용히 숨어 있다가 개발 막판에 고개를 듭니다.
“잘 되는 흐름”만 보지 말고, “실패했을 때의 흐름”까지 확인해야 합니다.
역할 4. 개발 전달 기준이 명확해집니다
개발자에게 화면을 전달할 때 가장 중요한 것은 기준입니다. 어떤 화면이 최종본인지, 어떤 프레임을 기준으로 개발해야 하는지, 버튼 상태와 예외 화면은 어디까지 준비되어 있는지 명확해야 합니다.
피그마를 협업 도구로 활용하면 개발자와 아래 항목을 함께 확인할 수 있습니다.
- 최종 개발 기준 프레임은 어느 것인가?
- PC, 태블릿, 모바일 화면이 각각 준비되어 있는가?
- 공통 버튼과 메뉴는 같은 컴포넌트를 사용하는가?
- 버튼의 기본, hover, disabled 상태가 정의되어 있는가?
- 오류 메시지와 빈 화면이 준비되어 있는가?
- 정책서로 보완해야 할 조건은 무엇인가?
피그마의 Dev Mode는 개발자가 디자인 파일을 확인하고 구현에 필요한 정보를 살펴보는 데 초점을 둔 인터페이스입니다. 기획자가 Dev Mode를 개발자처럼 깊게 사용할 필요는 없습니다. 하지만 개발자가 어떤 화면을 기준으로 구현 정보를 확인하는지 이해하면 회의가 훨씬 부드러워집니다.
“이 프레임을 개발 기준으로 지정하면 될까요?”
“이 버튼의 비활성 조건은 정책서에 따로 정리하겠습니다.”
“권한 없음 화면은 아직 없는데, 별도 프레임으로 추가하는 것이 좋을까요?”
역할 5. 화면과 정책의 빈틈을 찾기 쉬워집니다
피그마 화면을 보면 사용자가 보는 요소가 보입니다. 버튼, 입력창, 리스트, 팝업, 탭, 검색창, 필터 같은 것들입니다. 하지만 기획자가 봐야 할 것은 그 뒤에 숨어 있는 정책입니다.
| 화면 요소 | 기획자가 확인해야 할 정책 |
|---|---|
| 검색창 | 검색 가능 항목, 최소 입력 글자 수, 특수문자 허용 여부, 검색 결과 없음 처리 |
| 필터 | 기본값, 다중 선택 가능 여부, 초기화 기준, 저장 여부 |
| 저장 버튼 | 활성 조건, 클릭 후 처리, 성공 메시지, 실패 메시지, 이동 화면 |
| 삭제 버튼 | 삭제 권한, 확인 팝업, 복구 가능 여부, 삭제 후 이동 화면 |
| 목록 화면 | 정렬 기준, 페이징 방식, 빈 데이터 문구, 로딩 방식 |
피그마는 정책서를 대체하지 않습니다. 대신 정책서에 무엇을 써야 하는지 발견하게 도와줍니다. 화면을 보며 “이 경우는 어떻게 하지?”라는 질문을 만들 수 있기 때문입니다.
피그마 화면을 볼 때는 보이는 요소보다 보이지 않는 조건을 함께 확인해야 합니다.
기획자가 피그마에서 해야 할 일과 하지 않아도 되는 일
피그마를 배운다고 해서 IT 기획자가 디자이너가 되어야 하는 것은 아닙니다. 역할을 구분해야 부담이 줄어듭니다.
| 기획자가 하지 않아도 되는 일 | 기획자가 해야 하는 일 |
|---|---|
| 고급 디자인 시스템을 직접 설계하기 | 공통 UI가 일관되게 사용되는지 확인하기 |
| 아이콘을 직접 만들기 | 아이콘의 의미가 사용자에게 명확한지 확인하기 |
| 색상 조합을 세밀하게 조정하기 | 상태 구분이 화면에서 명확한지 확인하기 |
| 모든 컴포넌트를 직접 제작하기 | 반복 UI가 정책과 맞게 사용되는지 확인하기 |
| 디자인 퀄리티를 최종 책임지기 | 기능, 정책, 흐름, 예외 케이스를 검토하기 |
IT 기획자에게 필요한 피그마 역량은 제작 능력보다 해석 능력입니다. 화면을 읽고, 질문하고, 누락을 찾아내고, 협업자가 이해할 수 있게 의견을 남기는 능력입니다.
피그마를 잘 만드는 사람이 아니라, 피그마를 보고 좋은 질문을 하는 사람이 되는 것입니다.
피그마를 협업 도구로 쓰는 실무 흐름
IT 기획자가 피그마를 실무에서 활용한다면 아래 흐름이 가장 현실적입니다.
| 단계 | 기획자의 행동 | 확인 포인트 |
|---|---|---|
| 1단계 | 피그마 링크를 열고 전체 프레임 구조를 확인합니다. | 화면이 기능 흐름에 맞게 준비되어 있는가? |
| 2단계 | 주요 화면의 버튼과 입력값을 확인합니다. | 기능명, 버튼명, 필수값이 정책과 맞는가? |
| 3단계 | 프로토타입을 실행해 화면 이동을 확인합니다. | 클릭 후 이동 화면이 기획 의도와 맞는가? |
| 4단계 | 누락된 정책과 예외 케이스를 댓글로 남깁니다. | 오류, 빈 화면, 권한 없음, 로딩 화면이 있는가? |
| 5단계 | 개발자와 최종 기준 프레임을 확인합니다. | 개발 전달 기준이 명확한가? |
이 흐름만 익혀도 피그마를 “디자이너 도구”가 아니라 “기획자가 참여할 수 있는 협업 공간”으로 사용할 수 있습니다.
결론: 피그마는 디자인 툴이 아니라 화면으로 대화하는 협업 도구입니다
피그마는 분명 디자인 도구입니다. 하지만 IT 기획자에게는 그보다 더 넓은 의미가 있습니다. 피그마는 화면을 기준으로 기획자, 디자이너, 개발자가 같은 방향을 보게 만드는 협업 도구입니다.
PPT는 기획자의 생각을 정리하는 데 강합니다. 정책을 설명하고, 회의 자료를 만들고, 의사결정 흐름을 정리하는 데 여전히 유용합니다. 반면 피그마는 실제 화면과 사용자 흐름을 함께 검토하는 데 강합니다.
- 피그마를 디자인 툴로만 보면 기획자의 역할이 작아 보입니다.
- 피그마를 협업 도구로 보면 기획자가 해야 할 일이 선명해집니다.
- IT 기획자는 피그마에서 화면 구조, 흐름, 버튼, 입력값, 예외 케이스를 확인해야 합니다.
- 댓글 기능은 수정 의견과 기획 의도를 정확한 위치에 남기는 데 유용합니다.
- 프로토타입은 사용자 흐름과 예외 흐름을 검토하는 데 도움이 됩니다.
- 개발 전달 단계에서는 최종 기준 프레임과 정책 보완 항목을 확인해야 합니다.
정리하면, IT 기획자가 피그마를 배워야 하는 이유는 디자인을 직접 하기 위해서가 아닙니다. 화면을 더 정확히 읽고, 더 좋은 질문을 하고, 협업자와 같은 기준으로 이야기하기 위해서입니다.
피그마를 열었을 때 “내가 여기서 뭘 해야 하지?”라고 느껴졌다면, 먼저 디자이너의 눈이 아니라 기획자의 눈으로 보세요. 버튼 뒤의 정책, 화면 뒤의 흐름, 댓글 뒤의 의도를 찾는 순간 피그마는 낯선 툴이 아니라 실무 회의의 공용 지도책이 됩니다.
자주 묻는 질문
피그마는 디자인 도구이지만 디자이너만 쓰는 도구로 보기에는 부족합니다. 실무에서는 기획자, 디자이너, 개발자가 같은 화면을 보며 피드백을 남기고 화면 흐름을 검토하는 협업 도구로 활용됩니다.
기획자는 화면 구조, 버튼명, 입력값, 사용자 흐름, 오류 화면, 빈 화면, 권한 없음 화면, 개발 전달 기준을 확인해야 합니다. 화면을 예쁘게 만드는 것보다 기능과 정책이 제대로 반영되었는지 보는 것이 중요합니다.
단순히 “수정해 주세요”라고 남기기보다 수정 이유와 기준을 함께 적는 것이 좋습니다. 예를 들어 버튼명 변경 요청을 할 때는 어떤 기능 흐름 때문에 해당 문구가 더 적합한지 함께 설명하면 협업자가 이해하기 쉽습니다.
필요합니다. 피그마는 화면과 흐름을 확인하는 데 강하지만, 조건, 예외, 권한, validation, 데이터 처리 기준은 정책서나 Confluence 같은 문서에 정리하는 것이 좋습니다.
처음에는 프레임 찾기, 화면 확대와 이동, 프로토타입 실행, 댓글 남기기부터 익히는 것이 좋습니다. 그다음 개발 기준 프레임과 예외 화면을 확인하는 방식으로 실무 활용 범위를 넓히면 됩니다.