편집 화면을 모달로 띄웠더니 "옆 데이터를 봐야 하는데 가린다"는 컴플레인이 들어온 적 있으신가요. 저도 SaaS 대시보드 외주에서 똑같이 당했습니다. 그 경험이 계기가 되어 다이얼로그 설계 기준을 처음부터 다시 정리하게 됐고, 지금은 외주 5건에 같은 가이드를 재사용 중입니다.
의사결정 트리: 모달을 열기 전에 먼저 물어야 할 것
모달을 열기 전에 스스로에게 딱 하나만 물어보면 됩니다. "사용자가 이 작업을 하면서 뒤에 있는 화면을 참조해야 하는가?" 이 질문에 '예'가 나오면 모달은 이미 틀린 선택입니다.
저는 이걸 직접 겪고 나서야 깨달았습니다. 상세 편집 화면을 모달로 구성했을 때 편집 완료율이 64%에 머물렀는데, 사이드 패널로 바꾼 후 79%까지 올랐습니다. 15%포인트 차이가 단순히 컴포넌트 하나를 바꿨을 뿐인데 나온 겁니다. 이게 의사결정 트리가 실제로 작동한다는 증거라고 생각합니다.
다이얼로그(Dialog)란 앱 콘텐츠 위에 겹쳐서 나타나는 모달 창으로, 사용자가 반드시 응답해야 사라지는 구조입니다. 여기서 모달(Modal)이란 뒤 콘텐츠와의 상호작용을 완전히 차단하고 현재 작업에만 집중하도록 강제하는 UI 패턴을 의미합니다. 이 구조 자체가 의도적으로 방해적(purposefully interruptive)이기 때문에 꼭 필요한 상황에서만 써야 합니다.
의사결정 흐름을 정리하면 이렇습니다.
- 컨텍스트 참조가 필요한가? → 필요하면 사이드 패널
- 작업 깊이가 깊고 스텝이 여러 단계인가? → 풀페이지
- 단순 확인·경고·빠른 선택인가? → 다이얼로그(모달)
- 모바일에서 위 조건에 해당하는가? → 보텀시트(Bottom Sheet)
이 네 가지 분기만 머릿속에 넣어두면, 적어도 잘못된 자리에 모달을 쓰는 실수는 막을 수 있습니다.
보텀시트 detents: 모바일에서 사이드 패널의 자리를 채우는 것
다이얼로그 설계 관련 자료들을 보면 데스크톱 기준으로만 설명하고 모바일 전환을 다루지 않는 경우가 많습니다. 일반적으로 데스크톱 사이드 패널이면 충분하다고 보는 시각도 있는데, 모바일에서는 상황이 완전히 다릅니다.
iOS 17부터는 Sheet detents API가 표준으로 자리 잡았습니다. 여기서 detents란 보텀시트가 멈출 수 있는 높이 지점을 미리 정의해 두는 기능으로, 사용자가 시트를 드래그할 때 지정된 높이에서 자연스럽게 고정되도록 합니다. 작은 크기(small), 중간 크기(medium), 전체 화면(large) 세 단계로 나뉘며, 개발자가 커스텀 값을 지정할 수도 있습니다. Android Material 3의 Bottom Sheet도 같은 방식으로 표준화되어 있습니다(출처: Material Design).
카카오뱅크·토스·당근마켓을 직접 써보면 보텀시트 detents가 얼마나 능숙하게 쓰이는지 체감할 수 있습니다. 계좌 상세를 반쯤 올려 보여주면서 뒤 화면의 잔액을 여전히 확인할 수 있게 두는 방식이 그겁니다. 데스크톱에서 사이드 패널이 하는 역할을 모바일에서는 보텀시트 detents가 대신하는 구조입니다.
제가 직접 써봤는데, 모바일 설계에서 이 분기를 빠뜨리면 데스크톱 가이드만 충실히 따라도 막상 모바일 QA 단계에서 다시 뒤집어야 하는 일이 생깁니다. 처음부터 데스크톱·모바일 분기를 함께 잡아두는 게 훨씬 효율적입니다.
컴포넌트 라이브러리 구성: Variants로 한 번에 정리하는 법
다이얼로그 설계 기준이 잡혔다면 이제 Figma 컴포넌트 라이브러리로 굳혀야 합니다. 기준이 문서에만 있으면 팀원이 다시 임의로 만들기 시작하고, 그 순간부터 Nested Modal 문제가 다시 생깁니다.
여기서 Nested Modal이란 모달 위에 또 다른 모달을 겹쳐 띄우는 패턴을 말합니다. 사용자 입장에서는 '지금 어느 레이어에 있는지' 감을 잃게 되고, 닫기 버튼을 눌러도 원하는 화면으로 돌아가지 못하는 혼란이 생깁니다. 한국 SaaS 시장에서는 아직도 이 패턴이 꽤 자주 보입니다. 제 경험상 이건 컴포넌트 라이브러리에 명시적인 금지 구조가 없을 때 반드시 발생합니다.
저는 외주 후 제 라이브러리를 다음과 같이 정리했습니다.
- 모달(Dialog): 소형 480px / 중형 640px / 대형 800px, 3종 Variants
- 사이드 패널: 360px / 560px, 2종 Variants
- 풀페이지: 1종
각 Variants에는 스크림(Scrim)이 포함되어 있습니다. 스크림이란 다이얼로그가 열릴 때 뒤 콘텐츠 위에 반투명하게 덮이는 어두운 오버레이 레이어를 말합니다. 시각적으로 '지금은 이 창에만 집중하세요'라는 신호를 주는 역할입니다. Material Design 가이드라인에서도 이 스크림 색상을 별도의 컬러 스타일로 관리하도록 권장합니다.
컴포넌트를 만들 때 Auto Layout과 Constraints를 꼼꼼히 잡아두면, 이후 크기를 바꿀 때 내부 버튼과 텍스트 영역이 비례를 유지하며 함께 움직입니다. 저는 이 부분에서 처음에 Constraints를 빠뜨려서 너비를 바꿀 때마다 버튼 위치를 수동으로 다시 잡아야 했습니다. 한 번 제대로 세팅하면 그 이후는 훨씬 수월해집니다.
디자인 시스템 문서: 1페이지 가이드가 팀 전체의 기준이 된다
컴포넌트 라이브러리와 함께 반드시 따라와야 하는 것이 의사결정 가이드 문서입니다. 컴포넌트가 '무엇을 쓸지'를 제공한다면, 가이드 문서는 '언제 쓸지'를 알려줍니다. 두 가지가 함께 있어야 팀원이 다른 판단을 내리는 일이 줄어듭니다.
저는 '컨텍스트 참조 필요 여부'를 첫 번째 질문으로 두고, 작업 깊이와 플랫폼(데스크톱·모바일) 분기를 그 아래에 붙인 1페이지 문서를 만들었습니다. 디자인 시스템 문서에 이 페이지를 추가한 뒤로 외주 5건에서 Nested Modal 발생률 0%를 유지하고 있습니다. 솔직히 이건 예상 밖이었습니다. 문서 한 장이 이렇게 실질적인 결과로 이어질 줄은 몰랐거든요.
Nielsen Norman Group의 연구에 따르면 모달 다이얼로그는 사용자의 현재 작업 흐름을 강제로 끊기 때문에 남용 시 오류율과 이탈률을 모두 높인다고 합니다(출처: Nielsen Norman Group). 제 외주 데이터에서 사이드 패널 35%, 풀페이지 25%, 모달 40%로 비율이 자리 잡힌 것도 이 원칙과 방향이 맞아 들어간 결과라고 봅니다.
향후 한국 시장을 위한 가이드라면 데스크톱·모바일 분기, 보텀시트 detents 처리, 사이드 패널 너비 표준 이 세 가지를 한 묶음으로 다루는 문서가 필요합니다. 지금 나와 있는 가이드 대부분은 이 중 하나만 다루거나 데스크톱에 머물러 있어서, 실무에서 그대로 쓰기에는 부족한 부분이 있습니다.
다이얼로그 설계는 '어떻게 만드냐'보다 '언제 쓰냐'가 더 중요합니다. 의사결정 트리 한 장을 팀 디자인 시스템에 붙여두는 것부터 시작해 보시길 권합니다. 컴포넌트가 아무리 잘 만들어져 있어도 언제 꺼내야 할지 기준이 없으면 결국 임의로 쓰이게 됩니다. 기준을 먼저 잡고, 그 기준에 맞는 컴포넌트를 Variants로 정리하는 순서로 접근하면 같은 실수를 두 번 반복하지 않아도 됩니다.