일반 화면에서는 계정에서 나갈 수 있었어요. 그런데 관리자 화면으로 들어가면 같은 입구가 보이지 않았어요. 관리 화면이 별도의 상단 구조를 사용하면서 일반 메뉴를 숨겼기 때문이에요. 기능이 사이트 어딘가에 있다는 사실과 지금 화면에서 사용할 수 있다는 사실이 달랐어요.
계정을 끝내려는 사람이 일반 화면으로 먼저 돌아가야 한다면, 관리 화면에서 하던 일과 무관한 이동이 하나 생겨요. 다른 계정으로 다시 들어가거나 작업을 마무리하려는 순간에도 현재 화면에서는 답을 찾을 수 없었어요. 작은 버튼의 부재가 화면 전체의 출구를 막고 있었죠.
같은 계정이라도 화면의 입구는 달랐어요
처음 확인할 때는 어느 사이트의 관리자 화면인지부터 구분해야 했어요. 여러 서비스가 계정 정보를 함께 사용한다고 해서 화면까지 같은 것은 아니었어요. 이미 로그아웃이 있는 다른 서비스나 일반 상단 메뉴를 고치면 정작 문제를 겪는 관리자 화면은 그대로 남을 수 있었어요.
실제 DS의 관리 화면은 공통 관리자 헤더를 사용하고 있었어요. 개별 관리 페이지마다 버튼을 붙이는 대신 그 공통 헤더에 로그아웃을 두기로 했어요. 어느 섹션에 있든 같은 위치에서 작업을 끝낼 수 있게 하려는 선택이었어요. 한 페이지에만 보이는 출구로는 같은 문제가 다른 화면에서 반복돼요.
넓은 화면에서는 아이콘과 문구를 함께 두고, 좁은 화면에서는 공간에 맞춰 표시를 줄였어요. 모습이 작아져도 버튼의 이름은 읽을 수 있어야 했고, 처리 중에 여러 번 눌러 같은 동작을 겹치지 않게 했어요. 계정에서 나가는 동안 무엇이 진행되는지도 버튼의 상태로 알리도록 했어요.
이 문제를 화면별로 살펴보면 일반 메뉴를 그대로 복제하는 답도 쉽게 떠올라요. 하지만 관리자 화면에는 자료를 판단하는 작업의 구조가 이미 있었어요. 전체 메뉴를 다시 붙이면 해결할 문제보다 큰 변화가 생겨요. 필요한 출구를 현재 구조 안에 두는 쪽이 요청 범위와 맞았어요.
버튼의 존재를 확인할 때도 지금 누구로 들어와 있는지와 함께 봤어요. 로그인하지 않은 화면의 버튼이나 일반 사용자의 메뉴를 확인해 놓고 관리자 문제를 해결했다고 말할 수는 없어요. 제보된 상황과 같은 입구를 거쳐 같은 행동을 해야 확인이 이어져요.
7월과 8월의 기록을 붙여 읽은 이유도 여기에 있어요. 구현과 운영 확인은 다른 날짜에 있었지만 사용자의 문제는 하나였어요. 각 날짜의 완료 문장만 모으는 대신, 버튼을 준비하고 실제로 나가기까지 어느 확인이 이어졌는지를 같은 글 안에 남겼어요.
버튼을 만든 날과 실제로 나간 날
7월의 첫 수정에서는 버튼과 동작을 구현하고 관련 확인을 마쳤어요. 하지만 실제 운영 관리자 계정에서 클릭해 로그인 화면으로 돌아가는 확인은 남아 있었어요. 이 단계의 끝을 로그아웃 문제가 완전히 해결된 날로 적으면 사용자가 겪은 흐름을 한 단계 건너뛰게 돼요.
8월에는 그 변경을 운영에 반영하고 관리자 화면에서 다시 확인했어요. 기존 관리자 계정으로 들어가 오른쪽 상단에 로그아웃 버튼이 있는지 보고, 실제로 눌렀어요. 그 뒤 로그인 화면으로 돌아온 상태까지 확인한 보고가 남아 있어요. 버튼이 보이는 장면과 세션을 끝낸 뒤의 장면이 이어진 거예요.
같은 버튼을 두 번 만들었다고 두 사건으로 세지 않았어요. 7월에 준비한 입구가 8월 실제 사용 확인까지 이어진 하나의 과정으로 남겼어요. 좁은 화면과 모든 계정 상태를 장기간 사용한 결과는 별도지만, 제보된 관리자 화면에서 계정을 끝내는 최소 흐름은 확인됐어요.
사용자가 얻은 변화는 새로운 관리 기능이 아니었어요. 현재 화면에서 작업을 마무리하고 다음 계정으로 들어갈 수 있는 길이 생겼다는 것이었어요. 관리 페이지로 들어올 때는 일반 메뉴를 숨길 수 있어도, 그 안에서 필요한 기본 행동까지 사라져서는 안 된다는 점을 이 작은 출구에서 다시 확인했어요.
