상태가 꽃이라면 왜 Stateless를 권하는가?
어떻게 하면 모델링을 잘할 수 있을까?
지난 글에서 <상태도는 설계의 꽃이다>라고 했는데, 프로그래밍 서적이나 글을 보면 Stateless를 권하는 내용을 쉽게 볼 수 있습니다. 어찌 된 일일까요?
Stateless Architecture는 좋은 것인가?
마침 ByteByteGo에도 Stateless Architecture 개요 보기 이미지가 올라왔습니다. 그걸 보고 상태를 다루는 상반된 입장에 대한 글을 씁니다.
정답을 바로 말하면 재미가 없으니 왜 Stateless Architecture를 말하는지부터 따져 보겠습니다.
네트워크 기반에서 함께 구동하기 위한 필요조건
사실 웹에 적합한 구조를 다룰 때부터 Stateless는 등장합니다. 10년 전에 자주 듣던 REST를 사전에서 찾아볼까요? Stateless를 포함하는 문장이 둘 있습니다.
REST has been employed throughout the software industry to create stateless, reliable web-based applications.
첫 번째는 소프트웨어 업계 전반에서 REST를 채택하여 Stateless로 신뢰할 수 있는 웹 기반 응용 프로그램을 만든다고 합니다.
두 번째 문장을 볼까요? REST 아키텍처의 주요 제약 중에 하나로 Stateless를 꼽습니다.
Stateless – A specific client does not consume server storage when the client is "at rest"
응용 프로그램의 특정 클라이언트가 요청을 하지 않을 때에는 서버 저장소를 점유하지 않아야 한다는 것이죠. 웹은 기본적으로 불특정 다수의 접근과 소통을 구축합니다. 그래서, 물리적으로 다른 위치에서 서로 다른 기기로 그리고 지구적 규모로 연결된 네트워크를 타고 비트를 운반하는 방식으로 구동합니다. 그렇기 때문에 통신이 제대로 이어지는 일이 애초부터 쉬운 일은 아니었습니다. 그래서, 걸핏하면 끊기는 일을 줄여야 신뢰할reliable 수 있습니다. 그렇게 하기 위해서 Stateless가 필요하다고 할 수 있습니다. 이 경우 Stateless를 제 말로 풀면 이렇게 말할 수 있습니다.
통신하는 프로그램 사이에서 서로의 상태를 알 필요가 없게 구현되어야 한다.
앞서 인용한 두 번째 영문에 힌트가 있듯이, 클라이언트가 서버에 보낸 요청을 받아 응답을 주는 동안만 상태를 필요한 만큼 공유한다고 하겠습니다. 그 외에의 상태를 알 필요가 없어야 웹 프로그램을 만들고 유지할 수 있다는 것이죠.
웹에서는 객체의 상태가 무용한가?
그렇다면,
웹에서는 객체의 상태가 무용하다는 말일까요?
그렇지 않습니다. 인용한 ByteByteGo의 Stateless Architecture 그림을 잘 보시면 주로 서버와 클라이언트 사이의 관계를 다룹니다. 혹은 브라우저와 서버 사이의 관계를 다루기도 하죠. 객체 지향에서 말하는 객체는 서버나 클라이언트라는 컨테이너Container에 살고 있는 프로그램을 정의하는 단위입니다. 그래서 저는 컨테이너 수준에서는 Stateless Architecture가 보편적이고, 객체 수준에서는 상태를 알아서 잘 다뤄주고 숨길 때 클라이언트가 편리하게 해당 객체를 호출하여 협업할 수 있다고 믿습니다.
고로 상태라고 말할 때, 무엇의 상태인지 주체와 추상화 수준을 분명하게 묻고 따질 필요가 있습니다.
지난 어떻게 하면 모델링을 잘할 수 있을까? 연재
3. 모델링을 Actor로 시작한다는 의미는 무엇인가?
5. 사고와 인식과 표현의 주체인 임자로 욕망을 바라보기
6. 모델을 그리기 전에 '생각의 종이'부터 준비하세요
7. 순차도로 사태를 하나씩 것과 곳과 쪽으로 차려내기
8. 객체 모델링에서 메시지 그리고 Collaboration
9. 모델링을 통해 구조에 결정적 영향을 주는 요소 찾기
11. 상태도는 객체 설계의 꽃이다
