세션과 토큰 로그인 설계 면접: 서버가 두 대가 되면, 로그아웃하면

이런 화면입니다

앱에서 한 번 로그인하면 그다음부터는 아이디를 다시 묻지 않습니다. 껐다 켜도, 며칠 뒤에 열어도 그대로입니다.

로그인은 한 번이고, 확인은 매 요청마다입니다. 서버는 이 사람이 누구인지를 매번 무엇으로 알아볼까요.

면접관이 이렇게 묻습니다

범위부터 좁힙니다

한 줄로 좁힙니다. 매 요청마다 이 사람이 누구인지 알아보고, 로그아웃하면 그 순간부터 못 들어오게 한다. 비밀번호 보관과 소셜 로그인 연동은 접고 로그인 이후의 유지에 집중합니다.

가장 많이 나오는 답

서버 메모리에 맵 하나를 두고, 표를 주면 사용자 번호를 찾습니다.

Map<String, Long> sessions = new HashMap<>();
sessions.put(token, userId);   // 로그인
Long me = sessions.get(token); // 매 요청

서버 한 대, 재시작 없는 개발 환경에서는 잘 돕니다.

그런데 여기서 깨집니다

서버를 두 대로 늘리면 메모리도 두 개가 됩니다. 1번 서버에서 로그인한 사람이 2번 서버로 가면 모르는 사람이 됩니다.

배포로 프로세스가 재시작되면 맵도 같이 사라지고, 모든 사용자가 한꺼번에 로그아웃됩니다.

떨어지는 답은 이런 모양입니다

• Redis에 담으면 된다고 답하고, 왜 그래야 하는지는 설명하지 못합니다.
• 로그아웃을 앱 화면에서 표를 지우는 것으로 끝냅니다.
• 만료된 행이 끝없이 쌓이는 것을 생각하지 못합니다.

면접관은 여기서 멈추지 않습니다

1. 요청마다 데이터베이스를 한 번 더 읽는 게 부담이면요?

   확인 비용과 즉시성 사이에서 무엇을 내줄지 말하는지 봅니다.

2. 수명이 긴 표가 탈취되면요?

   표가 새어 나간 뒤에 할 수 있는 일을 설계해 두었는지 봅니다.

3. 사용자가 수백만이고 요청이 초당 수만이면요?

   같은 선택이 규모 앞에서 어떻게 달라지는지 봅니다.