로그인 버튼 하나에 숨겨진 기술들

월요일 아침, 지윤은 회사 업무 사이트를 열었습니다.

아이디와 비밀번호를 적고 로그인 버튼을 누르자, 잠시 뒤 자기 이름과 할 일이 화면에 나타났습니다. 업무 목록을 열고 다른 메뉴로 이동해도 비밀번호를 다시 묻지는 않았죠.

지윤은 문득 궁금해졌습니다.

사이트는 비밀번호가 맞는지 어떻게 확인할까요? 그리고 로그인 버튼은 한 번 눌렀는데, 다음 화면에서도 어떻게 나라는 걸 알아볼까요?

지윤의 출근 첫 로그인을 따라가며, 웹에서 흔히 사용하는 비밀번호·세션 방식의 구조를 살펴보겠습니다. 모든 서비스가 같은 방식으로 구현되는 것은 아니지만, 이 흐름을 알면 다른 로그인 방식도 이해하기 쉬워집니다.

1. 비밀번호가 출발하기 전에 보호된 연결을 만듭니다

지윤이 보는 웹 화면을 실행하는 브라우저는 클라이언트입니다. 로그인 버튼을 누르면 브라우저는 아이디와 비밀번호를 서버가 정해 둔 API 형식에 맞춰 보냅니다. 이때 입력창에 비밀번호가 점으로 가려지는 것과, 전송되는 정보가 보호되는 것은 다른 문제입니다. 화면의 점은 옆 사람이 읽지 못하게 가리는 표시일 뿐이죠.

웹에서는 보통 HTTPS 연결로 로그인 정보를 전달합니다. HTTPS는 HTTP 통신을 TLS로 보호하는 방식입니다. 브라우저는 인증서 등을 확인하며 서버와 연결하고, 통신 내용을 암호화해 전송 중 엿보기와 변조 위험을 줄입니다. 다만 가짜 사이트도 HTTPS를 쓸 수 있으므로 연결이 보호된다는 사실과 접속한 곳을 믿어도 된다는 판단은 구분해야 합니다. 지윤의 비밀번호가 안전하게 도착하려면 봉투가 잠겨 있어야 할 뿐 아니라 받는 주소도 맞아야 하는 셈입니다. 이 원리는 Cloudflare의 TLS 기술 설명에서 확인할 수 있습니다.

2. 서버는 보관한 비밀번호를 꺼내 읽는 대신 일치 여부를 검사합니다

이제 서버가 비밀번호를 확인할 차례입니다. 적절히 설계된 비밀번호 시스템은 원문을 그대로 보관하거나, 언제든 꺼내 읽으려고 복호화 가능한 형태로 저장하지 않습니다. 대신 전용 비밀번호 해싱 방식으로 계산한 검증값을 보관합니다. 회원가입 때 만든 검증값과 로그인 때 입력한 값으로 계산한 결과가 맞는지 확인하는 방식입니다.

여기에는 사용자마다 다른 무작위 값인 솔트와, 추측을 반복하는 비용을 높이는 계산 방식도 사용합니다. 단순히 빠른 해시를 한 번 계산하는 것과는 다릅니다. 서버가 이런 검사를 통해 요청한 계정의 사용자임을 확인하는 과정을 인증이라고 부릅니다. 다만 인증에 성공했다고 모든 자료를 열람할 수 있는 것은 아닙니다. 다른 직원의 급여를 볼 수 있는지는 별도의 권한 확인이 필요하죠. 비밀번호 저장과 검증의 구체적인 원칙은 OWASP 비밀번호 저장 가이드가 설명합니다.

3. 로그인 다음부터는 세션을 가리키는 표를 보여 줍니다

지윤이 메뉴를 옮길 때마다 서버에 새 요청이 갑니다. HTTP 요청은 기본적으로 각각 독립적이므로, 서버에는 이번 요청을 로그인한 지윤과 연결할 방법이 필요합니다. 대표적인 방법은 서버에 세션이라는 이용 상태를 만들고, 브라우저에는 그 상태를 찾는 세션 ID를 쿠키로 전달하는 것입니다. 안내 데스크에서 신원을 확인한 뒤 임시 출입표를 받는 것과 비슷합니다.

이후 브라우저는 쿠키의 적용 범위와 정책에 맞는 요청에 그 표를 함께 보냅니다. 서버는 세션이 유효한지 확인하고 지윤의 화면을 보여 줍니다. 비밀번호를 매번 다시 입력하지 않아도 되는 이유입니다. 세션 ID가 노출되면 악용될 수 있어 쿠키 보호와 만료 관리가 중요하고, 로그아웃도 서버의 세션 종료까지 고려해야 합니다. 실제로는 토큰 등 다른 구조도 쓰이지만, 이번 예시는 MDN의 세션 관리 설명에 나오는 대표적인 서버 세션 방식입니다.

4. 다른 계정으로 로그인하거나 비밀번호를 아예 쓰지 않을 수도 있습니다

지윤이 다른 서비스에서 '외부 계정으로 로그인'을 누른다면 확인을 맡는 곳이 달라질 수 있습니다. 서비스가 신원 제공자의 인증 결과를 검증해 자체 로그인을 만드는 방식입니다. 여기서 자주 나오는 OAuth는 정확히는 제한된 자원 접근 권한을 위임하는 틀이고, 로그인 신원 확인에는 그 위에 인증 기능을 더한 OpenID Connect 같은 프로토콜을 사용합니다. 외부 계정의 비밀번호를 새 서비스에 그대로 넘기는 구조로 이해하면 안 됩니다. 이 차이는 OpenID Foundation의 설명에 잘 드러납니다.

패스키는 또 다른 접근입니다. 서비스가 보관한 공개키로, 인증기가 개인키를 사용해 만든 서명을 검증합니다. 기기의 PIN이나 생체 확인은 키 사용을 승인하는 데 쓰일 수 있으며, 지문 자체를 사이트에 보내는 것은 아닙니다. 지윤이 보는 버튼은 작지만 그 뒤에는 연결 보호, 신원 확인, 상태 유지와 권한 검사가 나뉘어 있습니다. 다음에 로그인 화면을 만났을 때는 버튼 하나보다, 그 버튼이 연결하는 여러 확인 절차가 보일지도 모릅니다. 패스키의 작동 방식은 FIDO Alliance 공식 안내를 참고했습니다.