로그인·세션·JWT — 제작 외주에서 자주 깨지는 인증
외주 견적서에 “로그인”이 한 줄로만 적혀 있는 경우가 많습니다. 납품 시연에서는 아이디와 비밀번호를 넣고 들어가면 끝처럼 보입니다. 그런데 오픈 직후부터 문의가 쌓입니다.
앱에서 갑자기 로그아웃되고, 공용 태블릿에서 로그아웃해도 다른 기기 접속이 남고, 관리자 메뉴만 숨겼을 뿐 일반 계정으로 관리 기능이 열리는 식입니다. 화면이 아니라 로그인 이후를 어떻게 유지·차단·정리하는지에서 깨집니다.
앱과 웹을 같이 쓰는 서비스일수록 “로그인됨 / 안 됨” 두 칸으로는 부족합니다. 누가, 어떤 기기로, 얼마나 오래, 어떤 메뉴까지 쓸 수 있는지가 처음부터 설계에 들어가야 합니다.
로그인 이후를 어떻게 기억하나요?
사이트마다 방식이 조금 다릅니다. 크게 보면 세 가지 그림입니다.
| 방식 | 서버가 기억하는 것 | 사용자 기기 쪽 | 잘 맞는 경우 |
|---|---|---|---|
| 전통 세션 | 접속 표식(세션 ID) | 쿠키에 표식 | 웹 관리자, 같은 사이트 안 |
| 토큰(JWT 등) | 주로 토큰 내용으로 확인 | 요청마다 토큰 첨부 | 모바일 앱, API 중심 |
| 혼합 | 긴 갱신 수단은 서버 저장, 짧은 이용 권한은 토큰 | 둘 다 | 실무에서 흔함 |
“최신 방식 토큰을 쓴다”고 해서 자동으로 안전해지지는 않습니다. 만료 시간, 저장 위치, 갱신 방법, 로그아웃 때 서버에서 끊는지가 빠지면 오히려 추적이 더 어려워질 수 있습니다.
외주에서 자주 어긋나는 지점
이용 권한만 길고, 갱신 설계가 없다
토큰 만료를 며칠, 몇 달로 두면 구현은 쉽습니다. 대신 유출됐을 때 피해가 오래갑니다. 짧은 이용 권한과, 필요할 때만 새로 받는 갱신 수단을 나누는 편이 일반적입니다.
앱이 여러 API를 한꺼번에 부를 때 갱신이 겹친다
백그라운드에서 요청이 몰리면 “갱신 중” 요청이 동시에 나갑니다. 서버 규칙과 앱 동작이 안 맞으면 사용자는 이유 없이 강제 로그아웃됩니다. 동시에 여러 번 갱신하지 않도록 규칙을 정해야 합니다.
메뉴만 숨기고 권한은 없다
화면에서 관리 버튼을 안 보여 주는 것과, 서버가 관리 기능을 거절하는 것은 다릅니다. 일반 사용자·입점 판매자·상담 계정·최고 관리자는 각각 허용 범위가 달라야 합니다.
저장 위치가 헐겁다
브라우저나 앱에 오래 쓰는 비밀 값을 쉽게 꺼낼 수 있는 곳에 두면, 한 번의 화면 공격으로 피해가 커질 수 있습니다. 웹과 앱, WebView가 같이 쓸 때는 “토큰을 어디서 공유하는지”를 문장으로 남겨 두는 것이 좋습니다.
로그아웃이 화면만 초기화한다
기기에서 로그인 표시만 지우고 서버 쪽 갱신 권한이 살아 있으면, 이미 빠져 나간 값으로 다시 받을 여지가 있습니다. 로그아웃, 비밀번호 변경, 강제 로그아웃은 서버에서 끊는 절차가 포함되어야 합니다.
소셜 로그인만 있고 이후 정책이 없다
카카오·애플 등으로만 들어오게 해 두고, 계정 연결·탈퇴·재가입·비밀번호 재설정 링크 만료를 안 정하면 고객센터가 막힙니다. 재설정 링크는 짧은 유효와 1회 사용, 로그인 실패 횟수 제한도 인증의 일부입니다.
권장 흐름을 그림으로 잡으면
서비스 위험도에 따라 숫자는 달라지지만, 골격은 비슷합니다.
- 로그인 성공 후 짧은 이용 권한과 더 긴 갱신 수단을 발급한다.
- 매 요청마다 이용 권한의 유효·서명·역할을 서버에서 확인한다.
- 만료가 임박하거나 거절되면 갱신으로 다시 받는다. 동시에 여러 번 갱신하지 않는다.
- 갱신도 실패하면 재로그인하고 기기에 남은 정보를 정리한다.
- 로그아웃·비밀번호 변경 시 해당 사용자(또는 해당 기기)의 갱신 수단을 서버에서 폐기한다.
- 관리자 기능은 역할 허용 목록이 서버에 있어야 한다.
비밀번호는 원문 저장이 아니라 안전한 형태로 보관합니다. 관리자 계정은 더 강한 비밀번호와 접속 기록을 두는 편이 좋습니다.
검수할 때 물어보면 좋은 질문
“로그인 됩니다” 데모만으로는 부족합니다. 아래를 구체적으로 확인하세요.
- 이용 권한과 갱신 수단의 만료 시간은 각각 얼마인가
- 갱신 값이 도난 의심으로 재사용되면 어떻게 동작하는가
- 역할별 차단이 서버에서 강제되는가
- 동시에 로그인할 수 있는 기기 수 제한이 있는가
- 비밀번호 변경 후 기존 접속은 어떻게 되는가
- 앱 강제 업데이트와 토큰 버전이 맞지 않을 때 어떻게 안내하는가
- 탈퇴한 계정의 기존 권한은 바로 무효가 되는가
- 비밀 키·설정이 코드나 메신저에 박혀 있지 않은가
헐겁게 두면 무엇이 비싸지나
| 느슨한 선택 | 이후 비용 |
|---|---|
| 아주 긴 단일 토큰 | 유출 시 계정 도용 범위가 넓어짐 |
| 메뉴 숨김만 = 권한 | 관리 기능을 우회 호출 |
| 갱신 규칙 없음 | 예측 못 하는 강제 로그아웃, CS 증가 |
| 로그아웃 시 서버 미정리 | 공용 기기·탈취 잔존 |
| 개발·운영 키 혼선 | 테스트와 실서비스가 뒤섞임 |
인증은 기능 목록의 한 줄이 아닙니다. 주문·결제·개인정보 화면을 아무리 잘 만들어도, 여기를 우회하면 의미가 줄어듭니다.
이렇게 준비하면 좋아요
- □ 이용 권한 수명을 짧게 두고, 갱신 수단을 따로 두었는지 확인한다
- □ 로그아웃·비밀번호 변경 시 서버에서 접속을 끊는지 계약·검수에 넣는다
- □ 관리자·일반 사용자 역할이 서버 기준으로 나뉘는지 묻는다
- □ 로그인 실패 횟수 제한과 관리자 계정 정책을 정한다
- □ 웹·앱·WebView가 인증 정보를 어떻게 나누는지 한 장으로 받는다
- □ 탈퇴 즉시 기존 권한이 무효인지 시나리오로 테스트한다
이 글은 제작·운영 실무를 위한 안내이며, 법률 자문을 대신하지 않습니다. 규제나 분쟁 이슈는 전문가와 따로 확인하는 것이 좋습니다.
LB Contents는 앱·웹·쇼핑몰을 만들 때 로그인 화면만이 아니라 권한 유지, 역할, 로그아웃, 기기 정책까지 한 흐름으로 설계합니다. 기존 서비스 인증이 불안할 때도 점검 상담이 가능합니다.