피그마 모달·팝업 설계, 기획자가 놓치는 7가지
기획서엔 있는데 화면엔 없는 것들
기획서에 "확인 모달 노출"이라고 한 줄 적어두고 디자이너에게 넘긴 적, 다들 한 번쯤 있을 겁니다. 문제는 QA 단계에서 터집니다. 오버레이를 클릭했을 때 닫히는지, 배경 스크롤은 잠기는지, 아무도 정의하지 않았기 때문입니다.
결국 개발자와 디자이너가 각자 판단해서 구현하고, 화면마다 동작이 미묘하게 달라집니다. 재작업은 그때부터 시작됩니다.
모달, 팝업, 토스트는 다르다
세 용어를 섞어 쓰는 팀이 생각보다 많습니다. 하지만 인터랙션 설계 관점에서는 명확히 구분해야 합니다.
- 모달(Modal) — 화면을 가리고 사용자의 다음 행동을 강제하는 요소. 확인/취소 없이는 뒤 화면으로 못 돌아갑니다.
- 팝업(Popup) — 정보 전달 목적이 강하고, 모달보다 닫힘 경로가 자유로운 경우가 많습니다.
- 토스트(Toast) — 사용자 행동을 막지 않고 일정 시간 후 자동으로 사라지는 알림입니다.
이 구분이 애매하면 디자이너와 개발자 모두 "이거 모달이에요, 팝업이에요?"를 매번 물어보게 됩니다. 용어를 기획서 초반에 정의해두는 것만으로도 커뮤니케이션 비용이 줄어듭니다.
흔한 실수 사례
실무에서 자주 보는 누락 패턴 세 가지입니다.
- ESC 키를 눌렀을 때 닫히는지 여부가 명세에 없어서, 웹은 닫히고 앱은 안 닫히는 상황이 발생합니다.
- 모달 위에 또 다른 모달(예: 확인 모달 위의 에러 모달)이 뜨는 상황을 고려하지 않아, 두 모달이 겹쳐서 렌더링되는 버그가 생깁니다.
- 모바일에서 모달을 풀스크린으로 전환할지, 바텀시트로 바꿀지 정의하지 않아 디자이너가 임의로 결정하고, 이후 다른 화면과 패턴이 달라집니다.
공통점은 하나입니다. "당연히 이렇게 되겠지"라고 생각한 부분이, 상대방에게는 전혀 당연하지 않다는 것입니다.
기획서에 반드시 넣어야 할 7가지 체크리스트
모달·팝업 화면 설계 시, 아래 7가지는 와이어프레임 옆에 텍스트로 함께 명시하는 걸 권장합니다.
| 번호 | 항목 | 확인 내용 |
|---|---|---|
| 1 | 트리거 조건 | 어떤 액션(버튼 클릭, 특정 조건 도달 등)으로 열리는가 |
| 2 | 닫힘 조건 | 오버레이 클릭, ESC, X버튼, 자동 닫힘 중 무엇을 허용하는가 |
| 3 | 포커스 이동 | 모달이 열릴 때/닫힐 때 포커스가 어디로 이동하는가 |
| 4 | 배경 스크롤 | 모달이 떠 있는 동안 배경 화면 스크롤을 잠글 것인가 |
| 5 | 중첩 처리 | 모달 위에 다른 모달이 뜰 수 있는가, 그렇다면 우선순위는 |
| 6 | 반응형 규칙 | 모바일에서 동일하게 뜨는지, 풀스크린/바텀시트로 바뀌는지 |
| 7 | 동시 노출 우선순위 | 여러 알림 조건이 동시에 발생하면 어떤 걸 먼저 보여줄 것인가 |
이 중 세 가지는 특히 자주 빠지면서도 영향이 큰 항목이라, 아래에서 좀 더 구체적으로 다뤄보겠습니다.
실무 팁 1. 닫힘 규칙은 문장으로 남긴다
"오버레이 클릭 시 닫힘"이라고만 쓰면 부족합니다. 입력 중인 폼이 있는 모달이라면, 오버레이 클릭 시 바로 닫을지 확인 절차를 한 번 더 거칠지까지 정해야 합니다.
권장 표현: "오버레이 클릭 시 닫힘 / 단, 입력값이 있는 경우 '변경사항이 저장되지 않습니다' 확인 팝업 노출 후 닫힘"처럼 조건까지 문장으로 풀어서 씁니다.
실무 팁 2. 포커스 이동, 기획 단계에서 정의한다
모달이 열리면 포커스가 모달 내부 첫 번째 요소로 이동해야 하고, 닫히면 원래 트리거 버튼으로 돌아가야 스크린리더 사용자가 화면을 잃지 않습니다.
이 부분은 개발 단계에서 별도 요청이 없으면 누락되기 쉬운 항목입니다. 기획서에 "포커스는 모달 진입 시 A 요소로, 종료 시 트리거 버튼으로 복귀" 정도로 한 줄만 남겨도 충분합니다.
실무 팁 3. 모바일 전환 기준은 미리 합의한다
모든 모달을 모바일에서 풀스크린으로 바꿀 필요는 없습니다. 짧은 확인 메시지는 그대로 두고, 입력 필드가 여러 개인 폼형 모달만 풀스크린이나 바텀시트로 전환하는 식의 기준을 세워두는 것이 효율적입니다.
이 기준을 디자인 시스템 문서나 기획 컨벤션에 한 번 정리해두면, 매 화면마다 반복해서 논의할 필요가 없어집니다.
마무리
모달과 팝업은 작은 컴포넌트처럼 보이지만, 닫힘 조건과 포커스 처리까지 챙기지 않으면 QA 단계에서 반드시 다시 논의됩니다. 오늘 다룬 7가지 체크리스트를 기획서 템플릿에 고정 항목으로 넣어두면 반복 확인을 줄일 수 있습니다. 결국 핵심은 "당연하다고 생각한 부분"을 문장으로 남기는 습관입니다.
여러분 팀에서는 모달·팝업 설계할 때 어떤 항목을 체크리스트로 쓰고 계신가요? 빠진 항목이 있다면 댓글로 공유해 주세요.
FAQ
Q1. 모달과 팝업, 기획서에서 용어를 통일해야 하나요?
네, 통일하는 것을 권장합니다. 팀마다 정의가 다르면 디자이너와 개발자가 매번 다시 확인해야 하고, 컴포넌트 명명 규칙도 흔들립니다. 프로젝트 초반에 용어 정의 문서를 한 장 만들어두면 이후 커뮤니케이션이 훨씬 수월해집니다.
Q2. 피그마 컴포넌트 상태(Variants)로 모달을 관리하면 어떤 장점이 있나요?
닫힘 버튼 유무, 폭 크기, 헤더 유무 같은 변형을 Variants로 묶어두면 기획서에서도 "어떤 상태를 쓸 것인지"만 지정하면 되어 협업 속도가 빨라집니다. 다만 상태 조합이 지나치게 많아지면 오히려 관리가 어려워지니, 실제로 자주 쓰는 조합 위주로 구성하는 것이 좋습니다.
Q3. 접근성 가이드는 어느 수준까지 기획서에 명시해야 하나요?
모든 세부 규격까지 기획서에 담을 필요는 없습니다. 다만 포커스 이동 방향, 키보드로 닫기 가능 여부처럼 사용자 경험에 직접 영향을 주는 항목은 기획 단계에서 최소한으로라도 명시해두는 것이 이후 수정 비용을 줄이는 데 도움이 됩니다.