로그인과 세션

로그인했다는 말의 관찰 범위를 좁힙니다

행사 신청자 U01이 “로그인했는데 내 신청이 안 보여요”라고 문의합니다. 로그인 화면을 통과했는지, 신청 내역 요청에서 사용자 확인이 실패했는지, 다른 신청 번호를 조회했는지는 아직 모릅니다. 한 번 로그인했다는 기억을 현재 모든 요청의 성공 증거로 쓰면 재로그인만 반복하게 합니다. 이 레슨에서는 로그인 성공, 세션 유효성, 신청 조회를 시간 순으로 나누어 그립니다. 기획자의 결과물은 구현 코드를 추측한 그림이 아니라 확인 지점과 복귀 행동이 있는 흐름입니다.

이번 모듈은 실제 계정 없이 가명 자료와 정책 제안으로 연습합니다. 문서 실습 세 개와 JavaScript 브라우저 실습 하나를 사용하며 Node와 Python 3로 제공 예제를 실행할 수 있습니다. 미션 압축은 별도 연습 폴더에 풀고 그 루트에서 명령을 입력합니다. 시작본은 m03 미션 solution의 조사·데이터 계약을 보존하고 access-policy.json을 추가합니다. 실습 결과를 실제 서비스의 인증 성공으로 표시하지 않으며 비밀번호·쿠키·토큰 값을 입력하거나 공유하지 않습니다.

사용자 확인과 연속 요청을 분리합니다

로그인은 서비스가 사용자를 확인하는 과정입니다. 이 연습에서는 로그인 성공 뒤 서버가 세션을 만들고 이후 요청에서 그 세션을 확인하는 방식을 제안합니다. 세션은 로그인한 사용자의 요청을 이어서 식별하는 상태입니다. 쿠키는 브라우저가 다음 요청에 관련 값을 전달하는 수단이 될 수 있습니다. 쿠키가 존재한다는 사실만으로 서버가 현재 세션을 유효하다고 판정했다는 뜻은 아닙니다. 이 레슨은 다른 인증 방식을 배제하거나 실제 쿠키 설정을 확인한 결과가 아닙니다.

그림에는 로그인 요청→사용자 확인→세션 생성→신청 내역 요청→세션 확인→소유권 확인→조회 응답을 적습니다. 로그인 성공과 조회 성공 사이에 두 판단이 남습니다. 첫 판단은 현재 요청의 주체를 확인하는 것이고 다음 판단은 그 주체가 이 신청을 읽을 수 있는지 확인하는 것입니다. U01이라는 화면 표시가 남아 있어도 서버 판단을 생략하지 않습니다. 사용자 이름 표시와 서버가 인정한 주체는 서로 다른 관측 칸에 둡니다.

만료는 비밀번호 오류와 다른 사건입니다

사용자 확인에 실패한 로그인 시도는 세션이 만들어지지 않은 상황일 수 있습니다. 반대로 오전에 로그인한 뒤 오후 조회에서 만료가 확인되면 기존 세션으로 요청을 이어 갈 수 없는 상황입니다. 두 경우를 “비밀번호가 틀렸습니다”로 묶으면 사용자는 필요 없는 비밀번호 변경을 시도합니다. 계약에 로그인 실패와 SESSION_EXPIRED라는 조회 오류를 구분하고 각각 어느 화면에서 나타나는지 적습니다. 오류 코드 이름은 이번 제안이며 현재 제품에서 관찰한 값으로 취급하지 않습니다.

만료 조건은 서버에서 적용되어야 한다는 원칙을 제안서에 적습니다. 브라우저의 타이머나 쿠키 삭제만으로 만료를 구현했다고 판단하지 않습니다. 개발자에게 유휴 시간 기준인지 전체 로그인 유지 시간 기준인지, 로그아웃과 만료 뒤 이전 세션 요청을 거부하는지 확인합니다. 교육용 문서에서는 실제 제한 시간을 임의로 보안 정답처럼 정하지 않습니다. 확인할 담당자와 미확인 조건을 남기면 화면 문구와 서버 동작의 합의를 이어 갈 수 있습니다.

재로그인 뒤 무엇을 이어 갈지 정합니다

신청 내역 조회 중 만료되면 “로그인 확인이 필요합니다. 재로그인 후 신청 내역을 확인해 주세요”라고 안내합니다. 재로그인 뒤에는 최신 상태를 다시 조회합니다. 로그인 창을 닫았다는 사실을 조회 성공으로 기록하지 않습니다. 다른 계정으로 로그인했다면 본래 U01의 신청을 그대로 표시하면 안 되므로 새 주체에 맞게 다시 판정합니다. 화면에 남아 있던 다른 사람의 상태나 이전 응답을 재로그인 성공 화면의 근거로 재사용하지 않습니다.

제출 도중 만료 또는 응답 유실이 발생한 경우에는 복귀를 더 조심스럽게 정합니다. 로그인 뒤 자동으로 같은 신청을 새로 제출하면 이미 접수된 건을 중복 생성할 수 있습니다. m03의 재전송 계약을 유지하고 신청 내역에서 접수 여부를 먼저 확인하는 제안을 씁니다. 단순 조회는 다시 읽는 행동이지만 제출은 기록을 바꾸는 행동입니다. 로그인 복귀 흐름에서 두 행동을 같은 자동 재시도 상자로 그리지 않는 것이 업무 안전에 도움이 됩니다.

오류 기록을 안내와 연결합니다

이 연습의 만료 사례에는 요청 R07, 대상 A001, 오류 SESSION_EXPIRED, 시각과 화면을 기록합니다. HTTP 상태만으로 만료를 단정하지 않고 계약된 오류 코드와 서버 확인 결과를 함께 봅니다. 인증 필요와 권한 부족의 응답 표현은 서비스마다 달라질 수 있으므로 지원 담당자는 숫자 하나로 원인을 확정하지 않습니다. 상태가 안 보였다는 사용자 설명, 표시된 오류 문구, 개발자가 확인한 세션 결과를 별도로 적어 해석 과정을 남깁니다.

흔한 실수는 세션 값과 요청 ID를 같은 진단 번호로 취급하는 것입니다. 요청 ID는 한 시도의 기록을 찾기 위한 번호지만 세션 값은 사용자 요청을 인증하는 비밀일 수 있습니다. 지원에서는 요청 번호가 보이는지 묻고 없으면 없다고 기록합니다. 쿠키 화면 전체나 로그인 링크 전체를 요구하지 않습니다. 요청 ID도 로그와 연결되는 내부 자료이므로 담당자에게만 전달하고 공개 게시물에는 올리지 않는 운영 범위를 제안합니다.

동료가 흐름을 따라 판단할 수 있게 씁니다

완성 흐름도에는 로그인 실패, 유효 세션 조회, 만료, 재로그인 취소, 다른 계정 재로그인 다섯 갈림길을 둡니다. 각 갈림길에는 마지막 확인 결과와 사용자에게 보이는 행동을 붙입니다. “로그인 됨”이라는 한 칸 대신 “서버 세션 확인 통과”와 “본인 신청 조회 허용”을 두 칸으로 쓰면 개발자에게 확인할 책임이 선명합니다. 조사 근거 E003·E006은 결과 경로 불편의 근거이지 세션 만료가 실제 발생했다는 근거는 아니므로 제안 사례 표시를 유지합니다.

검토자는 만료 흐름에서 비밀번호 변경을 강요하는 문장이 없는지, 재로그인 후 최신 조회가 있는지, 계정 변경 때 소유권 재확인이 있는지 읽습니다. 화면 초안에는 로그인으로 이동하는 버튼과 내역으로 돌아오는 위치를 표시합니다. 아직 구현하지 않은 부분에는 미확인을 붙입니다. 코드나 서버 기록 없이 세션이 정상이라고 결론내리기보다 무엇을 관찰하면 정상 판정이 가능한지 적는 것이 신입에게 기대하는 기술 소통 능력입니다.

서버 만료 원칙은 OWASP 세션 관리 지침으로 확인할 수 있습니다. 더 읽기의 fetch 장은 HTTP 응답과 응답을 받지 못한 실패를 구별하는 보충 자료입니다. 이 레슨에서는 통신 코드 전체를 옮기지 않고 로그인 이후 어느 요청이 어떤 판단에서 멈췄는지 기록하는 데 사용합니다.