이탈 경로 제공과 나간 뒤 남는 내용

지금 나가도 작성한 내용은 남을까요?

친구들과 갈 공방 체험을 예약하려고 신청서를 작성하고 있습니다. 참석 인원을 바꾸던 중 한 친구의 일정을 다시 확인해야 한다는 생각이 듭니다. 신청을 마치기 전에 잠깐 멈추고 싶습니다.

마지막으로 저장한 초안에는 참석 인원이 2명입니다. 초안은 아직 제출하지 않은 작성 중 신청서입니다. 지금 화면에서 인원을 3명으로 바꿨지만 이 변경은 저장하지 않았습니다. 이 상태로 나가면, 바꾼 3명도 남을까요?

이 확인창만 보고 고를 수 있나요?

아래는 이 상황을 설명하기 위해 만든 화면입니다. 신청서를 나가려 하자 ‘취소하시겠습니까?’라는 질문과 ‘예 / 아니요’가 나타났습니다. 3명을 남겨 두고 잠깐 떠나려는 사람이라면 어느 쪽을 고를 수 있을지 생각해 보세요.

이 장면에서는 아직 신청서를 제출하지 않았고 예약도 성립하지 않았습니다. 저장된 초안은 2명, 현재 화면은 3명입니다. 그 사실을 알고 있어도 ‘예’가 무엇을 취소하고 어디까지 지우는지 알 수 있나요? 판단하기 어렵다면 어떤 설명이 더 필요한지 적어 보세요.

떠났다가 다시 열어 보세요

이번에는 선택한 뒤 무엇이 남는지 설명하는 화면을 살펴봅니다. 목표는 현재의 3명을 남겨 두고 신청서를 나갔다가 다시 여는 것입니다. 각 선택의 설명을 읽고 하나를 골라 보세요. 목록으로 이동했다면 초안을 다시 열어 인원과 신청 여부를 확인합니다.

이 체험의 저장과 삭제는 준비된 가상 값에만 적용됩니다. 실제 예약이나 외부 전송은 없고, 예시 값은 이 페이지를 새로고침하면 초기화됩니다.

다시 연 초안을 확인해 보세요

다시 연 초안에는 몇 명이 남았나요? ‘초안 저장 후 나가기’를 골랐다면 저장 성공을 확인한 뒤 목록으로 이동하고, 다시 열었을 때 3명이 보입니다. 그러나 초안을 저장한 것만으로 신청이 제출되지는 않습니다. 신청 여부는 여전히 ‘아직 신청하지 않음’입니다.

다른 선택도 비교하고 싶다면 ‘예시 처음으로’를 눌러 저장된 2명과 작성 중인 3명으로 돌아가 보세요. 여기서 ‘변경 버리고 나가기’를 고르면 인원을 3명으로 바꾼 이번 변경을 버리고, 마지막으로 저장한 2명은 남습니다. 방금 저장한 3명을 지우는 기능과 혼동하지 않도록 처음 상태에서 비교합니다.

‘계속 작성하기’는 확인창을 닫고 3명이 입력된 신청서로 돌아갑니다. 확인창의 ‘닫기’를 누르거나 Escape 키를 눌러도 같은 결과입니다. 신청서 전체를 떠나는 것과 그 위에 뜬 확인창만 닫는 것은 다른 행동입니다.

출구와 함께 남는 내용을 설계합니다

방금 화면에서는 세 가지를 따로 봐야 합니다. 마지막으로 저장한 초안, 지금 수정 중인 내용, 실제 신청 여부입니다. “변경 버리기”는 지금 고친 내용에만 영향을 주고, “초안 저장”은 보관된 값을 바꿉니다. 어느 선택도 이 예시의 신청서를 제출하지는 않습니다.

저장된 두 명, 작성 중인 세 명, 아직 비어 있는 제출 자리

닫힌 파란 폴더의 두 명은 마지막 저장본, 열린 종이의 세 명은 아직 저장하지 않은 현재 변경을 뜻합니다. 비어 있는 받침은 아직 제출하지 않았다는 별도 조건입니다. 이 비유에서 세 곳을 나누어 본 뒤, 변경 버리기와 초안 저장이 어느 곳을 바꾸는지 아래 가상 화면에서 확인해 보세요.

이탈 경로 제공(Provide Exit Points)은 사용자가 원치 않는 작업을 그만두거나 이전 상태로 돌아갈 방법을 마련하는 설계 원칙입니다. Nielsen의 사용자 통제와 자유 휴리스틱에 연결해 이해할 수 있습니다. 휴리스틱은 화면의 문제를 살필 때 쓰는 경험적 점검 원칙이며, 특정 결과를 수치로 보장하는 공식은 아닙니다. Nielsen, 사용자 통제와 자유

자신의 화면에서는 출구마다 무엇을 닫고 어떤 내용이 남는지 한 문장으로 먼저 적어 보세요. 그런 다음 실제 동작과 대조합니다. 저장되지 않은 변경을 지우는 기능이라면 그 범위를 알려야 하고, 초안 전체를 삭제하는 기능이라면 그 사실에 맞게 이름을 바꿔야 합니다.

이번 변경안은 버튼 문구, 현재 상태 안내, 선택 구성을 함께 바꿨습니다. 이해하기 쉬워졌는지를 확인할 수는 있지만 문구 하나의 효과로 나눠 말할 수는 없습니다. 처음 보는 사람에게 떠난 뒤 남을 내용을 설명해 달라고 부탁하고, 실제 결과와 맞는지 비교해 보세요.

잘못 시작한 작업을 그만두거나 일정을 확인하러 떠나는 것도 사용자가 원하는 결과일 수 있습니다. 이탈을 줄였는지만 보면 이런 선택을 놓칩니다. 나가고 싶었던 사람이 원하는 내용을 남기고 실제로 나갈 수 있었는지도 살펴보세요.

뒤로와 닫기와 취소는 무엇이 다를까요?

비슷한 자리의 버튼이라도 바꾸는 대상이 다를 수 있습니다. 아래 구분은 이름을 외우기 위한 사전보다 실제 동작을 확인하는 기준입니다. 제품마다 쓰는 말이 다르므로 버튼의 이름과 결과를 함께 살펴보세요.

‘뒤로’는 이전 단계나 화면으로 이동합니다. 이미 저장하거나 제출한 일을 자동으로 취소한다는 뜻은 아닙니다. ‘닫기’는 지금 보고 있는 창을 닫습니다. 앞의 확인창에서는 닫기가 신청서를 유지했지만, 다른 편집창에서는 저장 여부를 따로 정해야 합니다.

‘취소’에는 무엇을 취소하는지 대상이 필요합니다. 아직 확정하지 않은 변경을 버릴 수도 있고, 처리 중인 작업을 멈추려는 것일 수도 있습니다. 앞의 ‘변경 버리고 나가기’는 아직 저장하지 않은 3명 변경을 버리는 선택입니다. 이미 성립한 예약을 철회하는 ‘예약 취소’와는 다릅니다.

‘실행 취소’는 이미 적용한 특정 변경을 되돌립니다. 예를 들어 3명으로 저장한 바로 그 변경을 되돌리는 기능을 제공한다면, 저장된 값과 다시 열었을 때의 값이 모두 2명으로 돌아가야 합니다. 어떤 변경까지 되돌릴 수 있는지, 가능한 시간은 얼마인지도 정해야 합니다. 앞의 체험에는 이 기능을 넣지 않았으며, 여기서는 뜻을 구별하기 위한 예로 듭니다.

‘나가기’는 화면이나 작업을 떠난다는 목표를 말합니다. 그 말만으로 저장할지 버릴지까지 정해지지는 않습니다. 나중에 초안이나 버전 기록에서 내용을 되찾는 ‘복구’도 별도 기능입니다. 실제로 남겨 둔 데이터와 이를 되찾을 권한이 있어야 하므로, 보관 기간이 지나 실제로 삭제된 내용까지 복구할 수 있다고 안내해서는 안 됩니다.

그렇다고 나갈 때마다 모든 선택을 물어야 할까요? 세 가지 선택도 읽는 부담을 늘립니다. 바꾼 내용이 없는 화면이나 안전하게 자동 저장이 끝난 화면은 확인창 없이 닫을 수 있는지 검토해 보세요. 자동 저장 중인 상태를 완료로 착각하지 않도록, 저장이 끝났는지와 어디에서 얼마나 오래 다시 열 수 있는지는 확인해야 합니다.

저장에 실패해도 내용과 선택지는 남겨 둡니다

‘초안 저장 후 나가기’를 눌렀는데 저장되지 않았다면 어떻게 해야 할까요? 저장 성공으로 처리해 목록으로 보내면 사용자는 3명이 남아 있다고 생각할 수 있습니다. 아래 도판에서 성공과 실패 뒤의 화면을 비교해 보세요.

저장에 성공했을 때만 저장된 초안을 3명으로 바꾸고 목록으로 이동합니다. 실패했을 때는 작성 중인 3명을 그대로 두고 ‘저장하지 못했습니다’라고 알립니다. 마지막으로 저장한 초안은 여전히 2명입니다. 사용자는 다시 저장하거나 계속 작성할 수 있고, 이번 변경을 버리고 나갈 수도 있어야 합니다.

저장하는 도중 창을 닫는 경우도 생각해야 합니다. 창은 사라져도 서버, 즉 저장 요청을 처리하는 다른 컴퓨터에서는 작업이 계속될 수 있습니다. 닫기 버튼만으로 작업이 중단됐다고 표시해서는 안 됩니다. 실제로 중단하는 기능이 필요하다면 취소를 요청한 상태, 취소가 끝난 상태, 이미 저장돼 취소하지 못한 상태를 구별해야 합니다.

저장 결과를 아직 모른다면 실패했다고 단정하지 않습니다. 결과를 확인하는 기능이 있는 서비스라면 먼저 그 결과를 확인할 경로를 마련하세요. 이런 처리는 실제 저장 방식에 맞춰 정해야 합니다. 문구만 고친 뒤 저장 실패나 늦게 도착한 결과를 시험하지 않으면, 안내와 실제로 남은 내용이 어긋날 수 있습니다.

돌아가서 고쳐도 이어서 쓸 수 있게

앞 단계로 돌아갔더니 입력한 내용이 모두 비어 있다면, 출구는 있어도 작업을 이어 가기 어렵습니다. GOV.UK Design System의 뒤로 링크 지침은 직전에 보았던 페이지를 당시 상태로 다시 보여 주도록 안내합니다. 복잡한 경로에서는 어디로 돌아가는지 링크 이름을 더 구체적으로 쓸 수도 있습니다.

GOV.UK의 입력 내용 확인 패턴은 각 답을 고칠 수 있는 경로를 제공하고, 이미 쓴 값을 채워 놓도록 합니다. 수정을 마치면 남은 단계를 처음부터 반복하기보다 확인 화면으로 돌아가게 합니다. 다만 바꾼 답 때문에 새로운 질문이 필요해지면 그 질문에 답한 뒤 돌아가야 합니다.

공방 신청서에서 인원을 고치는 화면도 같은 관점으로 점검할 수 있습니다. 돌아갔을 때 어디를 고칠지 알 수 있는지, 다른 답은 그대로 있는지, 수정 뒤 신청 내용을 다시 확인할 수 있는지 봅니다. 오래된 초안을 열었다면 일정이나 이용 가능 여부처럼 달라졌을 수 있는 정보도 다시 확인해야 합니다.

화면 안의 ‘이전’ 링크만 시험하지 말고 브라우저의 뒤로 가기도 확인해 보세요. 어느 화면으로 돌아가며 입력이 어떻게 남는지 살피는 것입니다. 이탈을 막으려고 브라우저의 뒤로 가기를 무력화하는 방식은 사용자의 선택권을 해칩니다.

이미 보낸 것은 어디까지 되돌릴 수 있을까요?

봉투를 우체통에 넣기 직전이라면 아직 손에 쥐고 멈출 수 있습니다. 손을 놓은 뒤에도 같은 방법으로 되돌릴 수 있다고 약속할 수는 없습니다. 디지털 화면에서도 행동이 어느 단계까지 진행됐는지에 따라 가능한 취소가 달라집니다.

Gmail의 ‘보내기 취소’는 이 범위를 살펴볼 수 있는 사례입니다. 현재 컴퓨터용 공식 도움말은 보낸 직후 Undo를 누를 수 있고, 취소 기간을 5초·10초·20초·30초 중에서 정할 수 있다고 안내합니다. 이 내용은 2026년 10월 2일에 확인한 문서 기준입니다.

기능의 출발점은 2009년 출시 글에 설명돼 있습니다. 담당 디자이너 Michael Leggett는 메일을 잠시 보류해 전송 전에 붙잡는 방식이며, 이미 나간 메일을 회수하는 것은 아니라고 썼습니다. 당시의 5초를 지금의 고정 시간으로 읽으면 안 됩니다. 현재 선택 시간은 앞의 도움말로 구분해 확인해야 합니다.

여기서 가져올 기준은 버튼 이름보다 실제로 되돌릴 수 있는 범위를 확인하는 것입니다. 짧은 취소 기회를 ‘언제든 상대 수신함에서 메일을 지울 수 있음’으로 설명하면 다른 약속이 됩니다. 우편 장면은 이런 경계를 떠올리는 비유이며, Gmail의 처리 방식을 그대로 보여 주는 그림은 아닙니다.

공방 신청서도 제출 전 초안을 떠나는 일과 확정된 예약을 철회하는 일을 구분해야 합니다. 철회에 비용이나 마감이 있다면 실제 정책대로 실행 전에 알려 주세요. 되돌릴 수 없는 처리가 시작된다면 그 전에 내용을 확인할 기회를 주고, 이후에 가능한 조치도 안내합니다.

키보드로 나왔다가 이어서 쓰기

앞에서 본 확인창처럼 다른 화면 위에 뜨고 잠시 바깥 화면의 조작을 막는 창을 모달 대화상자라고 합니다. 마우스로 닫을 수 있어도 키보드로는 창 안에 갇힐 수 있으므로, 키보드만으로 나오는 방법도 마련해야 합니다.

이때 초점은 지금 키보드로 조작할 수 있는 위치를 뜻합니다. W3C의 APG 모달 패턴은 창이 열리면 그 안으로 초점을 옮기고, Tab과 Shift+Tab으로 창 안의 버튼 사이에 초점을 옮기며, Escape로 창을 닫도록 안내합니다. 보이는 닫기 조작도 포함하도록 권합니다. 닫은 뒤에는 보통 창을 열었던 버튼으로 초점을 돌리되, 그 버튼이 없어졌거나 다음 작업이 다른 곳에서 이어지면 알맞은 위치로 보냅니다.

우리 예시에서 Escape는 확인창만 닫습니다. 작성 중인 3명은 그대로 두고 ‘신청서 나가기’ 버튼으로 초점을 돌립니다. 목록으로 이동한 뒤에는 이미 사라진 그 버튼을 찾게 하지 않고, 목록 제목처럼 결과와 다음 행동을 읽을 수 있는 위치로 이어 줍니다. 닫기 키에 변경 폐기까지 몰래 묶지 않는 것이 중요합니다.

웹 접근성 기준인 WCAG 2.2의 2.1.2는 키보드로 들어간 요소에서 키보드로 빠져나올 수 있어야 한다고 요구합니다. 일반적인 키나 표준적인 방법이 아닌 별도 방법이 필요하면 그 방법을 안내해야 합니다. 앞의 APG는 구현에 참고하는 패턴이며, WCAG의 이 조항이 모든 창에서 Escape라는 한 키만을 의무화하는 것은 아닙니다.

모달 안에서 초점이 도는 것 자체와 빠져나올 수 없는 문제는 다릅니다. 키보드로 닫을 수 있는지, 닫은 뒤 내용을 이어 읽고 조작할 수 있는지 확인하세요. 터치 화면에서도 닫기를 찾고 누를 수 있어야 합니다. 이 항목을 통과했다고 전체 접근성이 확인된 것은 아니므로 이름, 초점 표시, 상태 전달 등도 함께 점검합니다.

확인해볼 질문

이번에는 사진을 편집하다 나가는 화면을 떠올려 보세요. 사진을 잘라 화면에 적용했지만 파일로 저장하지 않은 상태라면, ‘닫기’, ‘변경 버리기’, ‘실행 취소’를 각각 어떤 결과로 설계하겠나요? 각 버튼을 누른 직후 원본 파일과 편집 화면이 어떻게 달라지는지 적어 보세요. 편집기를 나가는 선택이라면 다시 열었을 때 무엇이 남을지도 적고, 버튼 이름과 설명을 맞춰 보세요.

• 출구마다 닫히는 화면, 중단되는 작업, 남는 내용을 한 문장으로 설명할 수 있나요?
• ‘취소’가 이번 변경을 버리는 일인지, 이미 확정된 요청을 철회하는 일인지 구별되나요?
• 뒤로 이동했을 때 기존 입력과 수정할 위치가 적절히 남아 있나요?
• 저장 후 나가기에서 저장이 실패해도 현재 내용을 잃지 않고 다음 행동을 고를 수 있나요?
• 실행 취소의 시간이나 범위가 끝났는데도 여전히 되돌릴 수 있는 것처럼 안내하지 않나요?
• 키보드로 출구에 도달하고, 닫은 뒤에도 알맞은 위치에서 작업을 이어 갈 수 있나요?

출구 하나를 골라 직접 나갔다가 돌아와 보세요. 이름을 보고 예상한 내용과 실제로 남은 내용이 다르다면, 저장 방식을 고쳐야 하는지 안내를 고쳐야 하는지부터 나눠 볼 수 있습니다. 나가기 전의 설명과 나간 뒤의 결과가 같은 뜻을 갖도록 맞추는 것이 출발점입니다.

근거의 범위

개념은 Nielsen의 휴리스틱, 뒤로 이동과 수정은 GOV.UK의 공식 설계 지침, 보내기 취소는 Gmail의 공식 문서에 근거했습니다. 접근성은 W3C의 패턴과 WCAG 성공기준을 구분해 읽었습니다. 공방 신청서와 사진 편집 과제는 이해를 돕는 가상 예시입니다. 공식 문서 확인은 해당 서비스의 계정에서 직접 동작을 시험한 결과나 이 변경안의 효과를 측정한 결과와는 구별합니다.