세션과 쿠키
로그인이 자꾸 풀린다는 문의의 정체예요. 브라우저에 남는 번호표(쿠키)와 서버의 명단(세션)이 짝을 이루고, 얼마나 오래 유지할지는 사장님이 정할 수 있어요.
쉽게 말하면
손님이 많은 가게의 대기 번호표를 떠올려 보세요. 손님이 이름을 말하면 계산대 뒤 명단에 적고, 손님 손에는 번호표 한 장을 쥐여 줘요. 다음에 그 손님이 번호표를 내밀면 명단과 맞춰 보고 "아, 아까 그분이시죠" 하고 바로 알아봐요. 여기서 손님 손의 번호표가 쿠키, 계산대 뒤의 명단이 세션이에요. 번호표를 잃어버리면 명단에 이름이 있어도 못 알아보고, 명단에서 지워지면 번호표가 있어도 소용없어요.
웹사이트는 원래 손님을 기억하지 못해요. 화면을 새로 열 때마다 처음 온 손님처럼 대해요. 그래서 로그인에 성공한 순간 서버가 명단(세션)에 적어 두고, 브라우저에 번호표(쿠키)를 심어요. 그 뒤로는 화면을 옮길 때마다 브라우저가 번호표를 자동으로 같이 보내서, 손님이 매번 비밀번호를 안 쳐도 되는 거예요.
| 쿠키 | 세션 | |
|---|---|---|
| 어디에 있나 | 손님의 브라우저 안에 있어요 | 내 서비스의 서버 쪽에 있어요 |
| 무엇이 적혀 있나 | 긴 무작위 번호 하나예요. 이름이나 비밀번호가 아니에요 | 그 번호가 누구인지, 언제 로그인했는지가 적혀 있어요 |
| 누가 지울 수 있나 | 손님이 지워요. 브라우저 정리, 시크릿 창 닫기로도 사라져요 | 내 쪽에서 지워요. 유지 시간이 지나면 자동으로 지워져요 |
| 지워지면 생기는 일 | 로그인이 풀려요. 같은 기기여도 다시 로그인해야 해요 | 번호표가 남아 있어도 못 알아봐요. 역시 로그인이 풀려요 |
이 표에서 하나만 기억한다면 이거예요. 로그인이 풀리는 길이 두 갈래라는 것. 손님 쪽 번호표가 사라져도 풀리고, 내 쪽 명단에서 지워져도 풀려요. "로그인이 자꾸 풀려요"라는 문의가 오면 이 두 갈래 중 어느 쪽인지부터 갈라야 해요.
로그인이 유지되는 순서
순서를 알아 두면 어디서 끊겼는지 짚을 수 있어요. 손님이 로그인 버튼을 누른 뒤 벌어지는 일은 네 걸음이에요.
- 1손님이 아이디와 비밀번호를 보내요. 여기까지는 손님이 한 일이에요.
- 2서버가 맞는지 확인하고 명단에 적어요. 무작위 번호를 하나 만들어 "이 번호는 이 손님"이라고 세션에 기록해요.
- 3브라우저에 번호표를 심어요. 서버가 답장에 쿠키를 실어 보내면 브라우저가 받아서 보관해요. 손님 눈에는 아무것도 안 보여요.
- 4그 뒤 모든 요청에 번호표가 따라가요. 화면을 옮기든 새로고침을 하든 브라우저가 알아서 쿠키를 붙여 보내고, 서버는 명단과 맞춰 보고 통과시켜요.
쿠키에는 비밀번호가 안 들어 있어요
쿠키에 담기는 건 뜻 없는 긴 번호 하나예요. 그런데도 조심해야 하는 이유가 있어요. 그 번호를 남이 훔치면 비밀번호 없이도 그 손님인 척 들어올 수 있거든요. 번호표만 있으면 명단이 통과시켜 주니까요. 그래서 로그인 있는 사이트는 자물쇠 연결이 선택이 아니라 필수예요. 자물쇠 없는 연결에서는 쿠키가 오가는 길에 훤히 노출돼요.
로그인이 자꾸 풀리는 이유
"자꾸 풀려요"는 원인이 하나가 아니에요. 증상을 조금만 자세히 물어보면 어느 갈래인지 대부분 갈라져요. 문의가 왔을 때 이 표에서 찾아보세요.
| 손님이 하는 말 | 실제로 벌어진 일 | 할 일 |
|---|---|---|
| 며칠 지나면 풀려요 | 유지 시간이 끝난 거예요. 고장이 아니라 정해 둔 대로 동작한 거예요 | 유지 시간을 늘릴지 정해요. 아래 기준을 보고 화면 성격에 맞춰요 |
| 브라우저를 닫으면 바로 풀려요 | 쿠키가 기간 없이 만들어져서 창을 닫는 순간 사라지는 설정이에요 | "로그인 유지"가 되도록 쿠키에 기간을 주라고 요청해요 |
| 폰에서는 되는데 컴퓨터에서는 풀려 있어요 | 정상이에요. 번호표는 브라우저마다 따로라서 기기마다 각각 로그인해요 | 고칠 게 없어요. 안내 문구로 설명만 해 주면 문의가 줄어요 |
| 어느 날 전부 한꺼번에 풀렸어요 | 서버 쪽 명단이 통째로 사라진 경우예요. 명단을 서버 메모리에만 두면 재배포 때마다 이래요 | 세션을 메모리가 아니라 데이터베이스 같은 남는 곳에 보관하라고 요청해요 |
| 시크릿 창에서는 매번 풀려요 | 정상이에요. 시크릿 창은 닫는 순간 쿠키를 전부 버리는 게 약속이에요 | 고칠 게 없어요. 이건 브라우저의 동작이라 내 쪽에서 못 바꿔요 |
장면 · 단골손님이 전화로 말했다
“어제 담아 둔 장바구니가 오늘 보니까 텅 비어 있어요.”
장바구니를 쿠키나 세션에만 담아 두면 이 전화를 받게 돼요. 손님이 브라우저를 정리했거나 유지 시간이 끝난 거예요. 사라지면 안 되는 것은 번호표가 아니라 장부(데이터베이스)에 손님 계정으로 저장해야 해요. 번호표는 잃어버리는 물건이라는 전제로 설계하는 거예요.
확인해 보세요
손님이 "폰에서는 로그인이 돼 있는데 노트북에서는 풀려 있어요"라고 문의했어요. 무엇이 잘못된 걸까요?
유지 시간을 정하는 기준
유지 시간은 개발자가 정해 주는 값이 아니라 사장님이 정하는 영업 방침이에요. 길게 잡으면 손님이 편하고, 짧게 잡으면 안전해요. 둘 다 가질 수는 없어서, 화면의 성격으로 갈라요.
문의는 줄어요. 대신 피시방이나 매장 공용 태블릿에서 로그인한 손님의 계정이 다음 사람에게 열린 채로 남아요. 사고가 나면 문의 몇 건과 비교가 안 되는 값을 치러요.
구경하고 담는 동안에는 안 풀려서 편하고, 카드 번호를 만지는 순간에만 한 번 더 확인해요. 은행 앱이 조회는 두고 이체 앞에서 다시 묻는 것과 같은 원리예요.
기준은 한 문장으로 줄어요. 그 화면이 뚫렸을 때 잃는 것이 클수록 짧게. 상품 구경은 뚫려도 잃을 게 없으니 길게 둬도 되고, 결제 수단과 개인정보 화면은 잃는 게 크니 짧게 두거나 그 앞에서 비밀번호를 다시 물어요.
로그아웃 버튼은 명단을 지우는 버튼이에요
제대로 된 로그아웃은 브라우저의 번호표만 버리는 게 아니라 서버 명단에서도 지우는 것이에요. 번호표만 버리면, 훔쳐 간 번호표가 어딘가에서 아직 통해요. 그리고 손님이 "비밀번호를 바꿨어요"라고 하면 그 계정의 명단을 전부 지워서 모든 기기에서 다시 로그인하게 하는 게 안전한 동작이에요.
AI에게 그대로 말하는 문장
세션이니 쿠키니 하는 말을 몰라도 돼요. 무엇을 지키고 무엇을 편하게 할지만 말하면 돼요. 왼쪽에서 내 상황을 찾아 오른쪽 문장을 그대로 보내세요.
| 내 상황 | 그대로 보낼 문장 |
|---|---|
| 손님이 자꾸 풀린다고 해요 | "로그인 유지 시간을 지금보다 길게 늘려 주세요. 지금은 며칠로 되어 있는지도 먼저 알려 주세요." |
| 브라우저를 닫으면 풀려요 | "브라우저를 닫아도 로그인이 유지되게 해 주세요. 로그인 화면에 '로그인 유지' 선택칸도 넣어 주세요." |
| 공용 컴퓨터 손님이 걱정돼요 | "오래 아무것도 안 하면 자동으로 로그아웃되게 해 주세요. 풀리기 전에 안내 문구를 먼저 보여 주세요." |
| 결제 화면이 걱정돼요 | "결제 수단과 개인정보 수정 화면에 들어갈 때는 로그인이 살아 있어도 비밀번호를 한 번 더 묻게 해 주세요." |
| 배포할 때마다 전부 풀려요 | "세션을 서버 메모리가 아니라 데이터베이스에 저장해서, 서버가 다시 시작돼도 로그인이 안 풀리게 해 주세요." |
| 비밀번호 바꾼 손님이 걱정돼요 | "비밀번호를 바꾸면 그 계정의 다른 기기 로그인을 전부 끊어 주세요." |
직접 해보기
내 서비스의 유지 시간부터 물어보세요
지금 만들고 있는 것이 있으면 첫 줄 문장부터 보내 보세요. "로그인 유지 시간이 지금 며칠로 되어 있나요." 현재 값을 알아야 늘릴지 줄일지 정할 수 있어요. 그 답을 듣고 나서 위 표의 문장 중 필요한 것을 이어서 보내면 돼요.
스튜디오에서 물어보기자주 묻는 것
- Q. 쿠키 동의 배너는 왜 뜨는 건가요? 저도 달아야 하나요?
- 쿠키가 로그인 유지에만 쓰이는 게 아니라 광고 추적에도 쓰이기 때문이에요. 유럽처럼 동의를 법으로 요구하는 곳이 있어서 해외 손님을 받는 사이트가 달아요. 로그인 유지처럼 서비스에 꼭 필요한 쿠키는 성격이 다르지만, 방문 분석이나 광고 도구를 붙였다면 손님 정보 다루기와 묶어서 한번 점검해 두는 게 좋아요.
- Q. 손님에게 "쿠키를 지워 보세요"라고 안내해도 되나요?
- 화면이 꼬였을 때 통하는 응급처치는 맞아요. 다만 그 손님의 로그인이 풀리고 담아 둔 것도 사라질 수 있다는 것까지 같이 안내해야 해요. 그리고 같은 안내를 자꾸 하게 된다면 그건 손님 브라우저 문제가 아니라 내 서비스 쪽을 고칠 신호예요.
- Q. 앱도 쿠키로 로그인을 유지하나요?
- 앱은 보통 쿠키 대신 토큰이라는 다른 번호표를 써요. 원리는 비슷한데 보관하는 곳과 다루는 법이 달라요. 웹과 앱이 같은 계정을 쓰게 만들 계획이면 토큰으로 로그인 유지하기를 이어서 읽어 보세요.
- Q. 카카오나 구글 로그인을 붙여도 세션이 필요한가요?
- 필요해요. 소셜 로그인은 "이 손님이 누구인지 확인하는 첫 관문"을 카카오나 구글에 맡기는 것이고, 확인이 끝난 뒤 우리 가게 안에서 기억하는 일은 여전히 세션과 쿠키가 해요. 관문 쪽 이야기는 소셜 로그인 연결 방식에 있어요.
더 깊이 (안 읽어도 괜찮아요)
번호표를 훔치는 두 가지 길 · 하나는 길에서 엿보기예요. 자물쇠 없는 연결에서는 오가는 쿠키가 그대로 보여서, 같은 와이파이의 남이 주울 수 있어요. 자물쇠 연결이 이 길을 막아요. 다른 하나는 화면 안에 심어진 나쁜 코드가 쿠키를 읽어 가는 거예요. 이건 쿠키를 만들 때 "화면 코드는 못 읽게" 표시를 붙이는 것으로 막는데, 개발자들이 HttpOnly라고 부르는 설정이에요. 로그인 쿠키에는 이 표시가 붙어 있는 게 기본이에요.
세션을 어디에 보관하느냐가 규모를 가른다 · 명단을 서버 한 대의 메모리에 두면 빠르지만 두 가지 값을 치러요. 서버가 다시 시작되면 명단이 통째로 사라져서 전 손님이 로그아웃되고, 서버를 여러 대로 늘리면 대마다 명단이 달라서 손님이 어느 대에 닿느냐에 따라 풀렸다 붙었다 해요. 그래서 손님이 늘면 명단을 서버 밖의 한 곳, 데이터베이스나 전용 보관소로 빼요. 배포할 때마다 전부 풀린다는 증상이 있다면 이 구조를 의심하면 돼요.
비유가 다른 지점 하나 · 가게 번호표는 손님이 눈으로 보고 건네지만, 쿠키는 손님이 모르는 사이에 브라우저가 자동으로 보내요. 이 자동이 편리의 근원이면서 동시에 한 가지 공격의 근원이기도 해요. 남의 사이트가 손님의 브라우저를 속여서 내 사이트에 요청을 보내게 하면, 브라우저는 습관대로 쿠키를 붙여 줘요. 그래서 요즘 브라우저와 개발 도구들은 다른 사이트에서 온 요청에는 쿠키를 안 붙이는 방향을 기본값으로 잡아 가고 있어요.
이것만 기억하세요
- ·쿠키는 손님 브라우저의 번호표, 세션은 서버의 명단이에요. 둘 중 하나만 사라져도 로그인이 풀려요
- ·"자꾸 풀려요"는 유지 시간 만료, 쿠키 삭제, 기기 다름, 서버 명단 소실 중 하나예요. 증상으로 갈라요
- ·유지 시간은 영업 방침이에요. 뚫렸을 때 잃는 게 큰 화면일수록 짧게 잡거나 비밀번호를 다시 물어요
- ·로그인이 있으면 자물쇠 연결은 필수예요. 번호표가 새면 비밀번호 없이도 뚫려요
- ·사라지면 안 되는 것은 쿠키가 아니라 데이터베이스에 저장해요. 번호표는 잃어버리는 물건이에요