• 목록

무상태 서비스라는 말을 들으면 데이터를 저장하지 않는 프로그램을 떠올리기 쉽습니다. 하지만 회원과 주문 데이터를 사용하는 서비스도 애플리케이션 서버를 무상태로 구성할 수 있습니다.

핵심은 데이터의 존재 여부보다 특정 서버를 바꾸었을 때 다음 요청이 계속 처리될 수 있는지에 있습니다.

AI 생성 삽화 · 실사풍 연출 이미지입니다. 실제 고객 현장이나 실제 작업 결과를 촬영한 사진이 아닙니다.

핵심 정리
무상태는 시스템 전체에 데이터가 없다는 뜻이 아닙니다. 요청을 처리하는 특정 인스턴스의 이전 기억에 의존하는지 살펴보고, 계속 보존해야 하는 상태가 어디에서 관리되는지 구분합니다.

1. 서버를 바꾸는 질문으로 시작합니다

가상의 쇼핑 서비스를 생각해 보겠습니다. 첫 번째 요청은 서버 A에서 처리하고 다음 요청은 서버 B에서 처리했을 때 장바구니를 정상적으로 보여 줄 수 있는지 묻습니다.

장바구니가 A의 메모리에만 있다면 B는 그 내용을 바로 알 수 없습니다. 공용 저장소에서 조회하도록 설계했다면 다른 인스턴스도 필요한 상태를 확인할 수 있습니다.

이 예시는 실제 쇼핑몰의 권장 설계를 모두 담은 것은 아니지만 특정 서버의 기억에 의존한다는 의미를 이해하는 데 도움이 됩니다. 서버를 늘리는 상황뿐 아니라 배포나 장애로 기존 프로세스가 사라지는 상황에도 같은 질문을 적용할 수 있습니다.

무상태 여부를 설명할 때는 시스템 전체를 한 단어로 묶기보다 어떤 구성 요소와 어떤 요청에 대해 말하는지 범위를 먼저 정하는 편이 정확합니다.

2. 영속 데이터와 작업 중 임시 값을 구분합니다

Twelve-Factor의 프로세스 원칙은 계속 보존해야 할 데이터를 별도의 상태 저장 서비스에 두고, 프로세스의 메모리나 로컬 캐시가 다음 요청에도 남아 있을 것이라고 가정하지 않는 방향을 설명합니다. 여기서 요청을 처리하는 동안 계산 결과를 변수에 저장하는 것까지 금지하는 것은 아닙니다.

한 요청 안에서 사용하고 버리는 중간 값과 다음 요청의 정합성에 필요한 상태를 구분해야 합니다. 예를 들어 이미지 크기를 계산하는 중간 변수와 사용자가 업로드한 원본 파일은 보존 요구가 다릅니다.

원본이 특정 서버의 임시 경로에만 있다면 해당 서버 교체 뒤 접근할 수 있는지 따져 봐야 합니다. 학습할 때는 데이터마다 누가 쓰고 누가 읽는지, 언제까지 필요한지 적어 보면 임시 값과 영속 상태를 구별하기 쉽습니다.

3. 캐시가 사라졌을 때의 결과를 확인합니다

메모리에 데이터가 있다는 이유만으로 곧바로 애플리케이션을 상태 저장 서비스라고 분류하는 것은 충분하지 않습니다. 그 데이터가 사라졌을 때 다시 계산하거나 원본에서 가져올 수 있는지 살펴봐야 합니다.

가상으로 상품 설명을 짧게 캐시한 서버가 재시작되었다면 첫 조회가 느려질 수 있지만 원본 데이터가 남아 있다면 기능을 계속 제공할 수 있습니다. 반면 아직 다른 곳에 저장하지 않은 주문 내용을 같은 메모리에만 보관했다면 의미가 다릅니다.

이 구분에서는 성능 저하와 데이터 상실을 별도로 생각합니다. 캐시 재생성에 많은 시간이 걸리거나 동시에 요청이 몰리는 문제도 있을 수 있으므로 사라져도 된다는 말이 운영상 아무 영향이 없다는 뜻은 아닙니다.

어떤 저장소를 원본으로 인정하는지와 장애 시 처리 방식을 명확히 설명해야 합니다.

4. 같은 서버로 보내는 것과 보존은 다릅니다

사용자의 요청을 계속 같은 서버로 보내면 메모리 세션을 찾기 쉬울 수 있습니다. 그러나 서버가 사라졌을 때 그 안의 상태를 복구할 수 있는지는 별개의 질문입니다.

가상의 로그인 상태를 서버 A에만 두고 요청을 A로 고정했다고 생각해 보겠습니다. A가 정상일 때는 문제가 보이지 않다가 재시작이나 교체 때 갑자기 세션이 사라질 수 있습니다.

같은 목적지로 연결한다는 규칙이 상태의 복사본이나 복구 절차를 자동으로 만드는 것은 아닙니다. 그렇다고 모든 서비스가 동일한 세션 구현을 써야 한다는 결론도 아닙니다.

업무의 보존 요구와 인증 방식, 장애 시 사용자 경험을 검토해 선택해야 합니다. 설계 설명에는 정상 요청 경로뿐 아니라 해당 인스턴스를 제거했을 때의 동작도 함께 넣어야 숨은 의존성을 찾기 쉽습니다.

5. 상태 저장 워크로드가 필요한 경우도 있습니다

데이터베이스처럼 상태 자체를 관리하는 구성 요소까지 모두 무상태로 만들 수는 없습니다. Kubernetes의 StatefulSet은 안정적인 식별자와 저장소 연결 등이 필요한 워크로드를 관리하는 기능을 제공합니다.

이때 리소스 이름에 Stateful이 들어간다는 사실과 애플리케이션 데이터의 백업·복구가 완성되었다는 판단은 구분해야 합니다. 저장소가 유지되는지, 복제는 어떻게 하는지, 잘못 삭제한 데이터를 어디까지 되돌릴 수 있는지는 별도의 설계입니다.

학습용 구성도를 그린다면 요청 처리 계층과 데이터 보존 계층을 나누고 각각의 교체 조건을 적어 볼 수 있습니다. 상태 저장 워크로드는 나쁜 설계라는 뜻이 아니며 필요한 상태를 어디에서 책임질지의 문제입니다.

특정 도구를 사용했다는 사실보다 그 도구가 제공하는 보장과 제공하지 않는 보장을 설명하는 것이 중요합니다.

6. 외부 저장소로 옮긴 뒤의 책임도 살펴봅니다

상태를 공용 데이터베이스로 옮기면 애플리케이션 인스턴스 교체를 단순하게 만들 수 있지만 저장소에 대한 의존성이 생깁니다. 저장소 응답이 늦거나 접근할 수 없을 때 어떤 화면을 보여 줄지, 같은 데이터를 여러 요청이 바꿀 때 어떻게 처리할지 검토해야 합니다.

가상 장바구니 예시에서도 두 요청이 동시에 수량을 변경하면 저장 위치만 바꾸었다고 문제가 모두 해결되지는 않습니다. 이 단계에서는 정합성과 동시성, 접근 권한 등 다른 주제와 연결됩니다.

초급 학습에서는 모든 해결책을 한 번에 외우기보다 상태의 책임이 사라진 것이 아니라 다른 구성 요소로 이동했다는 점을 기억하면 좋습니다. 비용과 운영 부담도 함께 달라질 수 있으므로 무상태라는 이름만을 목표로 설계를 바꾸기보다 어떤 교체와 확장 문제를 해결하려는지 먼저 정합니다.

7. 작은 실험으로 서버 의존성을 점검합니다

학습 환경에서는 같은 애플리케이션을 두 인스턴스로 실행하고 요청을 번갈아 보내는 실험을 생각해 볼 수 있습니다. 먼저 한 인스턴스에서 만든 데이터가 다른 인스턴스에도 보이는지 확인하고, 그다음 기존 프로세스를 재시작했을 때 결과가 어떻게 달라지는지 기록합니다.

실제 운영 데이터로 무작정 서버를 중단하는 실험을 할 필요는 없습니다. 실험표에는 세션, 업로드 파일, 임시 계산 값, 캐시처럼 데이터 종류를 나누고 보존 위치와 복구 방법을 적습니다.

기대한 동작과 실제 결과가 다르면 특정 인스턴스에 남아 있던 가정을 찾아봅니다. 개념 정리의 마지막 질문은 이 서버가 없어져도 되는가 한 문장으로 끝나지 않습니다.

없어졌을 때 무엇이 유지되고 무엇이 다시 만들어지며 무엇을 복구해야 하는지까지 설명할 수 있어야 합니다. 면접이나 스터디에서는 무상태를 한 문장으로 정의한 뒤 구체적인 데이터 하나를 골라 설명해 보면 좋습니다.

예를 들어 업로드 파일은 어디에 보관하고 처리 중간 값은 어디에 두는지, 다음 요청이 다른 서버로 가도 되는지를 말합니다. 이어 저장소 장애라는 반대 상황을 질문하면 외부로 옮긴 상태의 책임까지 이해했는지 확인할 수 있습니다.

용어를 외우는 것보다 경계와 실패 조건을 설명하는 연습이 개념 정리에 도움이 됩니다.

8. 자주 묻는 질문

Q1. 무상태 서비스는 데이터베이스를 사용하지 않나요?

데이터베이스를 사용할 수 있습니다. 요청 처리 인스턴스의 로컬 기억에 의존하는지와 외부 저장소에서 영속 데이터를 관리하는지를 나눠 봅니다.

Q2. 메모리 캐시가 있으면 무조건 상태 저장인가요?

캐시가 사라졌을 때 원본에서 복원할 수 있는지와 요청의 정확성에 어떤 영향을 주는지 확인해야 합니다. 메모리 사용 여부만으로 판단하지 않습니다.

Q3. StatefulSet을 쓰면 백업도 해결되나요?

워크로드의 식별자나 저장소 관리와 백업·복구는 다른 과제입니다. 실제 보존과 복구 요구에 맞는 별도 구성을 확인해야 합니다.

Q4. 무상태 구조가 항상 더 좋은가요?

구성 요소의 역할과 보존 요구에 따라 다릅니다. 애플리케이션 교체를 단순하게 만드는 장점과 외부 저장소 의존성 등의 비용을 함께 검토합니다.

참고 자료

• The Twelve-Factor App: Processes
• Kubernetes 공식 문서: StatefulSets