리액트 과제에 앞서 디자인패턴을 고민하고 Presentational and Container Component Pattern에 대하여 알아보던 중 stateful과 stateless에 대한 용어를 보게 되었다. HTTP특징을 나타낼 때 종종 쓰이기도 하는 용어인 만큼 이 상태유지와 무상태에 대한 용어를 정확히 이해할 필요를 느꼈다.
✏️ 요약
아주 간단히 정리해보자면
- Stateless(무상태) - 상태를 보존하지 않음
- Stateful(상태유지) - 상태를 유지함
이라고 볼 수 있겠다.
앞서 언급한 리액트 디자인 패턴에서
Container에서는 Redux와 같은 상태관리가 주로 이루어지기 때문에 Stateful이고
Presentational Component는 Container에서 받은 Props 데이터들로 보여주는 역할을 하기 때문에 Stateless라고 볼 수 있겠다.
✏️ HTTP와 Stateless. 무상태 프로토콜
근데 Stateless가 왜 HTTP의 특징이라는 것일까?
이는 수평 확장에 유리한 무상태의 장점 때문이다.
HTTP는 순간적으로 대량의 트래픽이 몰릴 경우 서버를 더 붙이는 방식으로 대처를 하게 되는데
이때 다른 서버를 가져와도 요청에 문제가 없어야 한다.
만약 A라는 서버가 사용자의 이전 요청을 저장하고 있는 Stateful 상태일때 B라는 서버로 교체를 하게 되면 B는 A가 알고 있던 이전에 요청사항을 알지 못해 문제가 생길 것이다.
Stateful과 Statelss는 보통 아래와 같은 식으로 비유된다
✏️ 예시
클라이언트는 손님, 서버는 점원으로 비유하고 아메리카노를 요청하는 상황이다.
Stateful
- 손님 : 아메리카노 주세요
점원 : 샷 몇개 드릴까요?- 손님 : 2샷이요
점원 : 시럽을 넣어드릴까요?- 손님 : 네
점원 : 요청하신 아메리카노 나왔습니다
위 대화에서 점원은 손님의 이전 요청, 아메리카노 주세요. 2샷 주세요 등을 기억하기 때문에 이전 요청을 다시 말하지 않아도 점원은 주문을 받을 수 있었다.
하지만 카페가 너무 바쁘다보니 한명의 점원이 카운터에 있는 손님을 전담하기 어려워서 내가 말할 때마다 다른 점원이 주문을 받는다고 생각해보자. 그러면 새로 바뀐 점원은 손님의 이전 요청을 기억하지 못하기 때문에 우리는 아래처럼 얘기해야한다.
Stateless
- 손님 : 아메리카노 주세요
점원1 : 샷 몇개 드릴까요?- 손님 : 아메리카노 주세요. 2샷이요
점원2 : 시럽을 넣어드릴까요?- 손님 : 아메리카노 주세요. 2샷이요. 시럽 넣어주세요
점원3 : 요청하신 아메리카노 나왔습니다
답답하고 번거로워 보이지만, 이렇게 요청할 경우 가게는 어떤 점원을 데려와서 카운터에 세워놔도 문제없이 주문을 받을 수 있다.
그렇기 때문에 가게는 확장에 용이하다는 장점을 가진다. 반대로 손님이 없으면 남는 점원을 빼면 그만이다.
또한 점원은 바쁜 와중에 손님의 이전 요청까지 기억하지 않아도 되기 때문에 >주문을 받는 행위< 에만 집중 할 수 있어 부담이 덜하다.
다시 서버와 클라이언트 이야기로 돌아와서, 이런 무상태 프로토콜은
- 서버는 비즈니스 로직에만 집중.
- 클라이언트는 UI, 사용성에만 집중.
할 수 있기 때문에 강력한 장점을 가진다.
하지만 Stateless의 한계도 있다.
예를 들어 유저 로그인의 상태를 유지해야 할 경우 이는 무상태 만으로는 설계할 수 없다.
그렇기 때문에 브라우저 쿠키와 서버, 세션등을 함께 사용하여 Stateful(상태유지)로 기능을 구현하기도 한다.
이 글에선 stateless와 stateful의 차이점을 알기 위해 작성하여 HTTP에 대한 정리는 여기서 마친다.
HTTP의 무상태성에 대해 얘기하면 꼭 따라오는 다른특징인 비연결성이 있는데, 이 또한 중요한 이야기니 더 자세히 알고싶으면 아래 타 블로그 글을 참고하자.
