[Stateless]무언가 잊어버린 듯한... 그러나 이어지는 이야기

Mr.Manager 2025. 1. 1. 06:00

2025. 1. 1. 06:00

728x90

여러분, 혹시 친구와 나눈 대화를 기억하지 못해서 당황했던 적 있으신가요?

"어? 네가 그 얘기 했었어? 난 기억이 안 나는데..."

이런 상황이 발생하면 뭔가 민망하지만, 상대는 이런 대화를 Stateless한 태도로 받아들일 수 있을지도 모릅니다.

오늘은 이런 "기억하지 않는 대화"와 비슷한 Stateless, 그리고 그와 연관된 Connectionless에 대해 이야기해볼까 합니다.

Stateless는 말 그대로 "상태를 기억하지 않는 것"입니다.
쉽게 말해, 여러분이 음식점에서 주문할 때를 떠올려봅시다.

직원은 여러분의 상태를 기억하지 않습니다.
다시 말해, 여러분이 누구인지, 이전에 뭘 주문했는지에 대한 정보는 그때그때 잊혀지는 거죠.
HTTP도 딱 이와 같습니다.

HTTP는 요청과 응답 사이에 상태를 저장하지 않습니다.
즉, Stateless한 프로토콜입니다.

Connectionless는 연결을 유지하지 않는다는 의미입니다.
마치 음식점에서 음식을 주문하고 나면, 직원이 테이블 옆에 서서 대기하지 않는 것과 비슷하죠.

직원이 계속 옆에 서 있으면 더 빨리 요구를 들어줄 수도 있겠지만,
그렇게 하면 다른 손님들에게 서비스를 제공하지 못하게 되는 문제가 생깁니다.

HTTP의 Connectionless도 마찬가지입니다.

클라이언트(브라우저)와 서버는 요청을 보낸 뒤 연결을 끊고, 다음 요청 때 다시 연결을 시작합니다.

"왜 기억을 안 하지?"라고 궁금할 수 있습니다.
그 이유는 간단합니다: 확장성과 효율성 때문이죠.

확장성:
상태를 기억하지 않으면 서버는 요청이 올 때마다 독립적으로 처리할 수 있습니다.
많은 사용자가 동시에 접속해도, 서로의 상태를 신경 쓰지 않아도 되니 시스템이 더 단순해지고 확장성이 높아집니다.
효율성:
상태를 저장하려면 많은 메모리와 자원이 필요합니다.
기억해야 할 정보가 많아질수록 서버는 더 느려지겠죠?
하지만 Stateless구조라면 이런 부담을 줄일 수 있습니다.

여기서드는 의문!

"확장성과 효율성을 위해 Stateless하고, Connectionless하면 요청 할 때마다 연결을 끊고 다시 맺을텐데,

성능의 문제가 생길 수 있지 않을까요?"

이를 해결하기 위해 "Keep-Alive"가 등장하게 됩니다.

음식점 상황을 다시 생각해 봅시다.

기본 HTTP 방식:
직원이 주문을 받을 때마다 떠났다가 다시 돌아옵니다.
HTTP Keep-Alive 방식:
"저 김치찌개 말고 밥도 추가요!"
직원이 "네, 계속 말씀하세요!"라고 하며 테이블을 계속 오갑니다.

Keep-Alive는 여러 요청을 처리할 때 연결을 유지한 채 대화를 이어가도록 해줍니다.
그 덕분에 매번 연결을 새로 맺을 필요가 없어 성능이 개선됩니다.

HTTP에서의 Keep-Alive와 TCP의 Keep-Alive는 어떤 차이가 있는지 알아보겠습니다.

이제 조금 더 깊이 들어가서, TCP Keep-Alive와 HTTP Keep-Alive의 차이를 알아봅시다.

TCP Keep-Alive:
TCP 레벨에서 네트워크 연결이 끊어졌는지 확인하는 작은 패킷을 주기적으로 보내는 기능입니다.
즉, "연결이 살아 있나?"를 체크합니다.
HTTP Keep-Alive:
HTTP 요청과 응답을 처리할 때 연결을 유지하는 기능입니다.
"새로운 연결을 맺지 말고 기존 연결을 재사용하자"는 뜻입니다.

비유하자면,