2025년 8월 13일·4분
분산 시스템 개념: SaaS 확장을 위한 Kleppmann의 아이디어
프로토타입을 신뢰할 수 있는 SaaS로 전환할 때 팀이 마주하는 현실적 선택들—데이터 흐름, 일관성, 부하 제어—을 통해 분산 시스템 개념을 설명합니다.
프로토타입을 신뢰할 수 있는 SaaS로 전환할 때 팀이 마주하는 현실적 선택들—데이터 흐름, 일관성, 부하 제어—을 통해 분산 시스템 개념을 설명합니다.
프로토타입은 아이디어를 증명합니다. SaaS는 실제 사용을 견뎌야 합니다: 최대 트래픽, 지저분한 데이터, 재시도, 그리고 고객이 알아차리는 모든 작은 문제들. 질문이 “작동하나?”에서 “계속 작동하나?”로 바뀌면 혼란이 시작됩니다.
실사용자가 생기면 “어제는 됐는데”가 보잘것없는 이유로 실패합니다. 백그라운드 작업이 평소보다 늦게 실행됩니다. 어떤 고객이 테스트 데이터보다 10배 큰 파일을 업로드합니다. 결제 제공자가 30초간 지연됩니다. 이들 중 어느 것도 이례적인 상황은 아니지만, 시스템의 일부가 서로 의존하면 파급효과가 커집니다.
복잡성은 보통 네 군데에서 드러납니다: 데이터(같은 사실이 여러 곳에 있고 엇나감), 지연(50ms 호출이 가끔 5초가 됨), 실패(타임아웃, 부분적 업데이트, 재시도), 그리고 팀(다른 사람들이 다른 일정으로 서로 다른 서비스를 배포함).
단순한 사고 모델이 도움이 됩니다: 컴포넌트, 메시지, 상태.
컴포넌트는 일을 합니다(웹 앱, API, 워커, 데이터베이스). 메시지는 컴포넌트 사이에서 일을 이동시킵니다(요청, 이벤트, 작업). 상태는 기억하는 것들입니다(주문, 사용자 설정, 청구 상태). 확장 시 고통은 보통 불일치에서 옵니다: 메시지를 구성요소가 처리할 수 있는 속도보다 빠르게 보내거나, 명확한 진실의 근원이 없이 상태를 두 곳에서 업데이트할 때입니다.
고전적인 예는 청구입니다. 프로토타입은 인보이스를 생성하고 이메일을 보내며 한 요청에서 사용자의 플랜을 업데이트할 수 있습니다. 부하가 걸리면 이메일이 느려지고 요청이 타임아웃되며 클라이언트가 재시도해서 인보이스가 두 개 생기고 플랜 변경은 하나만 적용되는 상황이 발생합니다. 신뢰성 작업은 이러한 일상적인 실패가 고객에게 보이는 버그로 번지지 않도록 막는 것이 대부분입니다.
시스템이 더 어려워지는 이유는 대부분 합의 없이 성장하기 때문입니다: 무엇이 반드시 정확해야 하는지, 무엇이 단지 빠르면 되는지, 실패했을 때 무엇을 할지에 대한 합의가 없습니다.
사용자에게 약속하는 범위를 먼저 그려보세요. 그 경계 안에서 매번 정확해야 하는 동작(돈 이동, 접근 제어, 계정 소유권)을 이름 붙이세요. 그다음 “결국에는 맞아도 되는” 영역(분석 카운트, 검색 인덱스, 추천)을 이름 붙이세요. 이 한 번의 분리는 모호한 이론을 우선순위로 바꿉니다.
다음으로 진실의 근원을 적어두세요. 사실들이 한 번, 내구성 있게, 명확한 규칙으로 기록되는 곳입니다. 나머지는 속도나 편의를 위해 만들어진 파생 데이터입니다. 파생 뷰가 손상되면 소스 오브 트루스에서 재구성할 수 있어야 합니다.
팀이 막힐 때 보통 다음 질문들이 무엇이 중요한지 드러냅니다:
사용자가 청구 플랜을 업데이트하면 대시보드가 지연될 수 있습니다. 하지만 결제 상태와 실제 접근 권한이 일치하지 않는 것은 용납할 수 없습니다.
사용자가 버튼을 클릭하고 바로 결과를 봐야 한다면(프로필 저장, 대시보드 로드, 권한 확인) 일반적인 요청-응답 API면 충분한 경우가 많습니다. 간단하게 유지하세요.
작업을 나중에 해도 된다면 비동기로 옮기세요. 이메일 전송, 카드 청구, 리포트 생성, 업로드 리사이징, 검색으로의 데이터 동기화 등이 여기에 해당합니다. 사용자는 이런 작업을 기다려서는 안 되며 API가 이런 작업 때문에 묶여 있어서는 안 됩니다.
큐는 할 일 목록입니다: 각 작업은 한 워커가 한 번 처리해야 합니다. 스트림(또는 로그)은 기록입니다: 이벤트는 순서대로 보관되어 여러 리더가 재생하거나 따라잡거나 나중에 프로듀서를 바꾸지 않고 새 기능을 빌드할 수 있습니다.
실용적인 선택 기준:
예: SaaS에 "인보이스 생성" 버튼이 있다고 합시다. API가 입력을 검증하고 인보이스를 Postgres에 저장합니다. 그다음 큐가 "인보이스 이메일 전송"과 "카드 청구"를 처리합니다. 나중에 분석, 알림, 사기 검사를 추가하면 InvoiceCreated 이벤트 스트림을 통해 각 기능이 구독하도록 하면 핵심 서비스가 미로가 되는 것을 피할 수 있습니다.
제품이 성장하면서 이벤트는 "있으면 좋은 것"에서 안전망이 됩니다. 좋은 이벤트 설계는 두 가지 질문으로 귀결됩니다: 어떤 사실을 기록할 것인가? 그리고 제품의 다른 부분이 추측 없이 어떻게 반응할 수 있는가?
작게 시작해서 비즈니스 이벤트 집합을 선택하세요. 사용자와 수익에 중요한 순간을 고르세요: UserSignedUp, EmailVerified, SubscriptionStarted, PaymentSucceeded, PasswordResetRequested.
이름은 코드보다 오래갑니다. 완료된 사실에는 과거 시제를 사용하고, 구체적으로 유지하며 UI 용어는 피하세요. PaymentSucceeded는 쿠폰, 재시도, 여러 결제 제공자를 나중에 추가하더라도 의미가 유지됩니다.
이벤트를 계약으로 취급하세요. 매 스프린트마다 바뀌는 필드가 잔뜩 들어있는 "UserUpdated" 같은 만능 이벤트는 피하세요. 오랫동안 지킬 수 있는 가장 작은 사실을 선호하세요.
안전하게 진화하려면 추가적인 변경(선택적 필드 추가)을 선호하세요. 변경이 깨지는 경우 새 이벤트 이름이나 명시적 버전을 발행하고, 구 소비자가 사라질 때까지 둘 다 발행하세요.
무엇을 저장해야 할까요? 데이터베이스에 최신 행만 보관하면 어떻게 그 상태에 도달했는지의 이야기를 잃습니다.
원시 이벤트는 감사, 재생, 디버깅에 좋습니다. 스냅샷은 빠른 읽기와 빠른 복구에 좋습니다. 많은 SaaS 제품은 둘 다 사용합니다: 주요 워크플로우(청구, 권한 등)에 대해 원시 이벤트를 저장하고 사용자 화면을 위한 스냅샷을 유지합니다.
일관성은 보통 다음과 같은 순간에 드러납니다: “플랜을 바꿨는데 왜 아직 Free라고 나오지?” 또는 “초대를 보냈는데 왜 아직 팀원이 로그인 못하지?”
강한 일관성은 성공 메시지를 받으면 모든 화면이 즉시 새로운 상태를 반영해야 함을 의미합니다. 결국 일관성(eventual consistency)은 변경이 시간이 지나면서 퍼지며 짧은 창 동안 앱의 다른 부분이 서로 다른 상태를 보일 수 있음을 의미합니다. 어느 쪽이 더 낫다는 개념은 없습니다. 불일치가 초래할 피해를 기준으로 선택하세요.
강한 일관성은 보통 돈, 접근, 안전과 관련된 부분에 적합합니다: 카드 청구, 비밀번호 변경, API 키 철회, 좌석 수 제한 강제 등. 결국 일관성은 활동 피드, 검색, 분석 대시보드, "마지막 접속", 알림 등에 적합한 경우가 많습니다.
지연을 허용한다면 이를 숨기지 말고 설계에 반영하세요. UI에 "업데이트 중…" 상태를 보여주거나 목록에 대해 수동 새로고침을 제공하고, 낙관적 UI를 사용할 때에는 깔끔하게 롤백할 수 있어야 합니다.
재시도는 일관성이 교묘해지는 지점입니다. 네트워크가 끊기고 클라이언트가 더블클릭하고 워커가 재시작합니다. 중요한 작업은 같은 행동을 반복해도 두 개의 인보이스나 두 번의 환불이 생기지 않도록 멱등으로 만드세요. 흔한 방법은 행동당 idempotency key를 사용하고 반복에 대해 원래 결과를 반환하는 서버 측 규칙을 두는 것입니다.
백프레셔는 요청이나 이벤트가 시스템이 처리할 수 있는 것보다 빠르게 도착할 때 필요한 것입니다. 그렇지 않으면 작업이 메모리에 쌓이고 큐는 커지고, 가장 느린 의존성(보통 데이터베이스)이 모든 실패 시점을 결정합니다.
간단히 말해: 프로듀서가 계속 말을 걸고 소비자가 익사하고 있는 상황입니다. 더 받아들이면 단지 느려지는 것이 아니라 타임아웃과 재시도의 연쇄 반응을 촉발해 부하가 곱해집니다.
경고 신호는 보통 장애 전에 보입니다: 백로그가 계속 늘고, 스파이크나 배포 뒤에 지연이 급증하고, 재시도가 시간 초과로 증가하고, 한 의존성이 느려지면 관련 없는 엔드포인트가 실패하고, 데이터베이스 연결이 한계에 도달합니다.
그 지점에 도달하면 꽉 찼을 때 어떤 규칙을 적용할지 명확히 정하세요. 목표는 모든 것을 어떤 대가를 치르더라도 처리하는 것이 아니라 살아남아 빠르게 복구하는 것입니다. 팀은 보통 한두 가지 제어책으로 시작합니다: 속도 제한(사용자 또는 API 키별), 정의된 드롭/지연 정책을 가진 유한 큐, 실패하는 의존성에 대한 회로 차단기, 대화형 요청이 백그라운드 작업보다 우선하도록 우선순위.
데이터베이스를 먼저 보호하세요. 커넥션 풀을 작고 예측 가능하게 유지하고, 쿼리 타임아웃을 설정하며, 애드혹 리포트 같은 비용이 큰 엔드포인트에 대해 강한 제한을 두세요.
신뢰성은 드물게 큰 재작성으로 해결됩니다. 보통 실패를 가시화하고, 격리하고, 복구 가능하게 만드는 몇 가지 결정에서 옵니다.
신뢰를 얻거나 잃게 하는 플로우부터 시작해 기능을 추가하기 전에 안전 장치를 넣으세요:
핵심 경로를 맵핑하세요. 가입, 로그인, 비밀번호 재설정, 결제 플로우에 대한 정확한 단계를 적으세요. 각 단계에 대해 의존성(데이터베이스, 이메일 제공자, 백그라운드 워커)을 나열하세요. 이렇게 하면 무엇이 즉시여야 하고 무엇이 "결국" 고쳐질 수 있는지 명확해집니다.
관찰성 기본을 추가하세요. 모든 요청에 로그에 나타나는 ID를 부여하세요. 사용자 고통과 맞닿는 소수의 지표를 추적하세요: 오류율, 지연, 큐 깊이, 느린 쿼리. 서비스 간 요청이 교차하는 곳에만 트레이스를 추가하세요.
느리거나 불안정한 작업을 분리하세요. 외부 서비스와 통신하거나 보통 1초 이상 걸리는 작업은 작업과 워커로 옮기세요.
재시도와 부분 실패를 설계하세요. 타임아웃은 발생한다고 가정하세요. 작업을 멱등하게 만들고, 백오프를 사용하며, 시간 제한을 설정하고, 사용자 측 행동은 짧게 유지하세요.
복구를 연습하세요. 백업은 복원할 수 있어야만 의미가 있습니다. 작은 릴리스와 빠른 롤백 경로를 유지하세요.
도구가 스냅샷과 롤백을 지원한다면(Koder.ai가 그러한 기능을 지원한다면), 이를 비상용 트릭으로 다루지 말고 정상적인 배포 습관에 포함하세요.
팀 온보딩을 돕는 작은 SaaS를 상상해 보세요. 흐름은 단순합니다: 사용자가 가입하고 플랜을 고르고 결제하고 환영 이메일과 몇 가지 시작 안내를 받습니다.
프로토타입에서는 모든 것이 한 요청에서 일어납니다: 계정 생성, 카드 청구, 사용자의 "paid" 플래그 변경, 이메일 전송. 트래픽이 늘고 재시도가 발생하고 외부 서비스가 느려지면 이 설계는 깨집니다.
신뢰성을 위해 팀은 핵심 동작을 이벤트로 바꾸고 추가 기록(append-only history)을 유지합니다. 그들은 몇 가지 이벤트를 도입합니다: UserSignedUp, PaymentSucceeded, EntitlementGranted, WelcomeEmailRequested. 이렇게 하면 감사 추적이 가능해지고 분석이 쉬워지며 느린 작업은 백그라운드에서 처리되어 가입을 차단하지 않습니다.
몇 가지 선택이 대부분의 작업을 수행합니다:
PaymentSucceeded에서 idempotency key를 사용해 권한을 부여하면 재시도로 인해 중복 권한이 부여되지 않습니다.결제가 성공했지만 접근 권한이 아직 부여되지 않았다면 사용자는 사기당한 느낌을 받을 수 있습니다. 해결책은 "모든 곳에서 완벽한 일관성"이 아닙니다. 지금 당장 일관되어야 할 것을 결정하고 UI에 EntitlementGranted가 도착할 때까지 "플랜 활성화 중" 같은 상태를 반영하는 것입니다.
나쁜 날에는 백프레셔가 차이를 만듭니다. 이메일 API가 마케팅 캠페인 동안 지연되면 옛 설계는 체크아웃이 타임아웃되고 사용자가 재시도해 중복 결제와 중복 이메일을 유발합니다. 개선된 설계에서는 체크아웃이 성공하고 이메일 요청은 큐에 쌓이며 제공자가 회복되면 재생 작업이 백로그를 비웁니다.
대부분의 장애는 하나의 영웅적인 버그 때문이 아니라 프로토타입에서 타당했던 작은 결정들이 습관이 되면서 생깁니다.
한 가지 흔한 함정은 너무 일찍 마이크로서비스로 분할하는 것입니다. 서비스들이 서로를 계속 호출하게 되고 소유권이 불분명해지며 변경에 다섯 번의 배포가 필요해집니다.
또 다른 함정은 "결국 일관성"을 면죄부처럼 쓰는 것입니다. 사용자는 용어에 신경 쓰지 않습니다. 그들은 Save를 클릭했는데 나중에 페이지가 오래된 데이터를 보여주거나 인보이스 상태가 왔다갔다하면 불만을 갖습니다. 지연을 허용한다면 사용자 피드백, 타임아웃, 각 화면에서의 "충분히 좋은" 정의가 필요합니다.
다른 반복되는 실수들: 재처리 계획 없이 이벤트를 발행하는 것, 사고 중에 부하를 곱하게 만드는 무한 재시도, 모든 서비스가 같은 데이터베이스 스키마에 직접 접근하게 해 한 변경이 여러 팀을 깨는 것.
“프로덕션 레디”는 새벽 2시에 지목할 수 있는 결정들입니다. 명확함이 기교보다 낫습니다.
먼저 소스 오브 트루스를 명시하세요. 각 핵심 데이터 타입(고객, 구독, 인보이스, 권한)에 대해 최종 기록이 어디에 있는지 결정하세요. 앱이 두 곳에서 "진실"을 읽으면 결국 서로 다른 사용자에게 다른 답을 보여주게 됩니다.
그다음 재시도를 살펴보세요. 중요한 동작은 언젠가 두 번 실행될 것이라 가정하세요. 같은 요청이 두 번 들어오면 중복 청구, 중복 발송, 중복 생성 등을 피할 수 있나요?
대부분의 고통스러운 실패를 잡아내는 작은 체크리스트:
플랫폼이 스냅샷과 롤백을 지원한다면(Koder.ai 같은), 이를 사고 시의 트릭이 아니라 정상적인 배포 습관으로 사용하세요.
프로토타입은 *"만들 수 있는가?"*에 답합니다. SaaS는 *"사용자, 데이터, 그리고 실패가 드러났을 때 계속 작동할 것인가?"*에 답해야 합니다.
가장 큰 변화는 설계가 다음을 고려하도록 바뀐다는 점입니다:
사용자에게 약속한 범위를 정하고 각 행동의 영향을 기준으로 라벨을 붙이세요.
먼저 매번 반드시 정확해야 하는 것부터 시작하세요:
그다음 나중에 결국 일관성 있게 맞춰도 되는 것을 표시하세요:
짧은 결정으로 문서화해서 모두가 같은 규칙을 따르도록 하세요.
각 "사실"을 한 번만 기록하고 최종으로 간주하는 한 곳을 선택하세요(작은 SaaS의 경우 종종 Postgres). 그것이 소스 오브 트루스입니다.
나머지는 속도나 편의를 위해 파생된 데이터입니다(캐시, 읽기 전용 뷰, 검색 인덱스 등). 좋은 테스트: 파생 데이터가 틀리면 소스 오브 트루스에서 추측 없이 재생성할 수 있나요?
사용자가 즉시 결과를 필요로 하고 작업이 작다면 request-response를 사용하세요.
다음 경우 비동기로 옮기세요:
비동기는 API를 빠르게 유지하고 타임아웃으로 인한 클라이언트 재시도를 줄입니다.
**큐(queue)**는 할 일 목록입니다: 각 작업은 한 워커가 한 번 처리해야 합니다(재시도 포함).
**스트림/로그(stream/log)**는 사건의 기록입니다: 여러 소비자가 재생해 기능을 만들거나 복구할 수 있습니다.
실용적 기본값:
PaymentSucceeded)에는 스트림/로그중요한 동작을 **멱등(idempotent)**하게 만드세요: 같은 요청을 반복해도 두 번째 청구나 두 번째 인보이스가 생성되지 않아야 합니다.
일반 패턴:
또한 가능한 곳에는 고유 제약(unique constraint)을 사용하세요(예: 주문당 한 건의 인보이스).
성사된 비즈니스 사실의 작은 집합을 발행하고, 과거 시제로 이름을 붙이세요. 예: PaymentSucceeded, SubscriptionStarted.
이벤트를 설계할 때 지켜야 할 점:
이렇게 하면 소비자가 발생한 일을 추측하지 않아도 됩니다.
백프레셔가 필요하다는 경고 신호:
우선 도입할 제어책:
스케일 전에 사용자의 고통과 맞닿는 기본적인 관찰성을 갖추세요:
서비스 간에 요청이 넘어갈 때만 트레이싱을 추가하세요; 모든 것을 계측하기 전에 무엇을 찾을지 알아야 합니다.
“프로덕션 레디”는 새벽 2시에 대답할 수 있는 결정들의 집합입니다. 명확함이 기교보다 낫습니다.
확인 목록:
플랫폼이 스냅샷과 롤백을 지원한다면(예: Koder.ai), 이를 사고 때만 쓰는 기술이 아니라 평상시 배포 습관으로 만드세요.