오버레이 & 피드백

이 문서에서 가장 중요한 경고입니다. 클라이언트가 "팝업 띄워주세요"라고 하면 그대로 받아 적지 말고 반드시 되물으세요 — ①새 창인가요 ②화면 위 모달인가요 ③상단 알림 배너인가요? 이 셋은 개발 방식도, 공수도, 사용자 경험도 완전히 다릅니다.

"모달 띄워주세요"는 엄밀히 말하면 "다이얼로그를 모달 방식으로 띄워주세요"입니다. 모달의 핵심은 예쁜 상자가 아니라 뒤를 막는다는 점입니다. 사용자가 반드시 응답해야 넘어갈 수 있을 때만 쓰세요.

모달로 만들지 논모달로 만들지는 디자인 취향이 아니라 기획 결정입니다. 사용자의 흐름을 끊어야 하면 모달, 참고만 시키면 논모달입니다. 논모달을 남발하면 화면이 정신없어집니다.

다이얼로그는 모달일 수도 논모달일 수도 있습니다. 즉 "다이얼로그 = 물건", "모달 = 그 물건이 뒤를 막는 방식"입니다. 이 관계를 알면 세 단어(팝업·모달·다이얼로그)가 정리됩니다.

브라우저 기본 alert()는 디자인을 전혀 못 바꾸고 페이지 전체가 멈춥니다. 디자인 시안대로 나오게 하려면 "직접 만든 얼럿"이 필요하고, 이건 별도 작업입니다. 시안만 그려두고 "브라우저 기본으로 해주세요"라고 하면 시안과 다른 화면이 나옵니다.

버튼 문구를 "확인/취소"로만 쓰면 사용자가 무엇에 동의하는지 헷갈립니다. "삭제하기 / 그대로 두기"처럼 행동을 그대로 적는 게 원칙입니다. 위험한 행동 버튼은 빨간색으로 구분합니다.

한국 실무는 "딤 처리", Material Design은 "스크림", 개발 코드에서는 "backdrop"이라고 씁니다. 딤을 눌렀을 때 닫히는지 아닌지를 설계서에 반드시 적어야 합니다 — 이걸 안 적어서 생기는 QA 이슈가 매우 흔합니다.

모달을 "제대로" 만들었는지 판별하는 기준입니다. 이게 없으면 키보드·스크린리더 사용자는 모달 뒤의 보이지 않는 요소로 포커스가 넘어가 길을 잃습니다. 검수 때 Tab 키만 눌러봐도 바로 확인됩니다.

모바일 화면에서는 가운데 모달보다 바텀시트가 거의 항상 더 낫습니다. PC에서는 모달, 모바일에서는 바텀시트로 다르게 가는 경우가 많은데, 이 경우 두 벌을 만들어야 한다는 걸 일정에 반영해야 합니다.

iOS 고유 용어입니다. 안드로이드와 웹에서는 같은 걸 바텀시트로 만듭니다. 아이폰 쓰는 클라이언트가 "액션시트처럼"이라고 하면 이 모양을 말하는 겁니다.

툴팁 안에 버튼이나 링크를 넣으면 그건 툴팁이 아니라 팝오버입니다. 또 모바일에는 마우스 호버가 없어서 툴팁으로만 정보를 주면 모바일 사용자는 영영 못 봅니다. 중요한 정보는 툴팁에 넣으면 안 됩니다.

툴팁과의 구분 기준은 딱 하나 — 안의 내용을 조작할 수 있는가입니다. 조작 가능하면 팝오버, 읽기만 하면 툴팁입니다. 팝오버는 클릭으로 열고, 툴팁은 호버로 엽니다.

사용자의 작업을 방해하지 않는 가벼운 피드백에만 씁니다. 놓쳐도 괜찮은 내용이어야 합니다. 오류 메시지를 토스트로 처리하면 안 됩니다 — 사용자가 못 보고 지나갈 수 있고, 다시 볼 방법도 없습니다.

Material Design 용어이고, 실무에서는 토스트와 거의 구분 없이 섞어 씁니다. 굳이 나눈다면 버튼이 있으면 스낵바, 없으면 토스트입니다. 실행 취소를 붙이면 삭제 전 컨펌 다이얼로그를 없앨 수 있어 흐름이 훨씬 부드러워집니다.

토스트와의 차이는 지속 여부입니다. "서버 점검 예정", "결제 수단 만료 임박"처럼 사용자가 조치할 때까지 남아 있어야 하는 내용은 배너로 만듭니다. 닫기 버튼을 넣을지도 정해야 합니다.

폼 오류는 토스트가 아니라 인라인이 원칙입니다. "필수 항목을 입력하세요"를 토스트로 띄우면 어느 칸이 문제인지 알 수 없습니다. 오류는 언제나 문제가 있는 자리에 붙여야 합니다.

진행률을 알 수 있으면 프로그레스 바, 모를 때만 스피너입니다. 스피너가 3초 이상 도는 화면은 사용자가 "멈췄나?"라고 느끼므로, 그럴 땐 스켈레톤이나 안내 문구를 함께 씁니다.

실제 속도가 빨라지는 건 아니지만 체감 대기 시간이 줄어듭니다. 화면이 어떻게 채워질지 미리 보여주기 때문입니다. 요즘 서비스의 사실상 표준이라 시안에 로딩 상태도 같이 그려주는 게 좋습니다.

파일 업로드처럼 끝을 알 수 있는 작업에만 씁니다. 진행률을 모르면서 가짜로 채우면 신뢰가 깨집니다. 여러 단계 폼에서는 스텝 인디케이터와 함께 쓰기도 합니다.

외주 프로젝트에서 가장 자주 빠뜨리는 화면입니다. 시안에 없으면 개발자가 임의로 만들거나 그냥 빈 화면이 나옵니다. 빈 화면은 ①왜 비었는지 ②무엇을 하면 되는지 두 가지를 반드시 담아야 합니다. 견적·일정에 꼭 포함시키세요.

엠티 스테이트와 마찬가지로 시안에서 자주 누락됩니다. 좋은 에러 화면은 사과문이 아니라 다음 행동(다시 시도·홈으로·문의하기)을 줍니다. 개발자에게 던지는 기술 용어("500 Internal Server Error")를 사용자에게 그대로 보여주면 안 됩니다.

일부러 오래 보여주면 안 됩니다. "브랜드 노출"을 이유로 3초씩 잡아두는 경우가 있는데, 사용자에게는 그냥 느린 앱입니다. 준비가 끝나면 즉시 넘어가야 합니다.

한 문장으로 외우세요 — "다이얼로그(물건)를 모달(방식)로 띄웠는데, 그중 단순히 알리기만 하는 게 얼럿(종류)이고, 이 모든 걸 뭉뚱그려 부르는 잘못된 말이 팝업이다."