왜 그래프와 상태 머신인가
대규모 글로벌 서비스에서 데이터베이스 인시던트가 발생했을 때, 수동으로 복구 절차를 밟는 것은 시간이 걸리고 휴먼 에러가 개입할 가능성이 높다. Stripe 엔지니어링 팀은 이 문제를 해결하기 위해 전 세계에 분산된 데이터베이스 인프라 전체를 그래프(Graph) 로 모델링하는 접근을 택했다. 노드(Node)는 개별 데이터베이스 인스턴스나 클러스터를, 엣지(Edge)는 복제 관계나 의존성을 나타낸다. 이렇게 구조화된 그래프 위에서 탐색 알고리즘을 실행하면, 어떤 장애가 어느 범위까지 영향을 미치는지, 그리고 어떤 순서로 복구를 진행해야 하는지를 기계적으로 계산할 수 있다.
상태 머신(State Machine)은 복구 작업의 각 단계를 명확한 상태(State)와 전이(Transition)로 표현하기 위해 도입되었다. 예를 들어 DETECTED → PLANNING → EXECUTING → VERIFYING → RESOLVED와 같은 흐름을 상태 머신으로 정의하면, 각 전이 조건과 실패 시 롤백 경로를 코드 레벨에서 명시적으로 관리할 수 있다. 이는 복구 로직이 암묵적인 if-else 분기로 흩어지는 것을 방지하고, 전체 자동화 파이프라인의 예측 가능성을 높인다.
핵심 설계 패턴
Stripe의 접근 방식에서 주목할 점은 두 기술의 역할 분리다. 그래프 탐색은 "무엇을 해야 하는가(What)"를 결정하고, 상태 머신은 "어떻게 실행하는가(How)"를 제어한다. 그래프 알고리즘이 최적의 복구 계획(Remediation Plan)을 산출하면, 상태 머신이 그 계획을 단계별로 안전하게 실행한다.
[Graph Search]
인프라 노드/엣지 → BFS/DFS 탐색 → 복구 계획 생성
[State Machine]
DETECTED
↓ (plan computed)
PLANNING
↓ (approved)
EXECUTING
↓ (success / failure)
RESOLVED / ROLLBACK
이러한 설계는 Java 백엔드 관점에서도 직접 적용 가능한 패턴이다. 예를 들어 Spring StateMachine 라이브러리나 직접 구현한 상태 머신을 통해 복잡한 비즈니스 프로세스나 장애 복구 워크플로우를 모델링할 수 있다. 아래처럼 상태 전이를 명시적으로 선언하면 로직의 가시성이 크게 올라간다.
transitions
.withExternal()
.source(States.PLANNING)
.target(States.EXECUTING)
.event(Events.APPROVE)
.action(remediationExecutor::run);
복구 계획 자체도 그래프 탐색 결과로 자동 생성되기 때문에, 엔지니어가 인시던트 발생 시 직접 판단해야 하는 영역을 최소화한다. 이는 온콜(On-call) 부담을 줄이고, 새벽에 발생하는 장애에 대한 초기 대응 속도를 극적으로 향상시킨다.
실무 적용 시 고려할 점
이 아키텍처를 자체 시스템에 도입하려면 먼저 인프라를 그래프로 정확히 모델링하는 작업이 선행되어야 한다. 데이터베이스 간 복제 관계, 서비스 의존성, 장애 전파 경로 등을 노드와 엣지로 정의하는 것 자체가 상당한 도메인 이해를 요구한다. 모델이 실제 인프라와 동기화되지 않으면 잘못된 복구 계획이 생성될 수 있으므로, 그래프 상태를 최신으로 유지하는 파이프라인도 함께 설계해야 한다.
상태 머신 설계에서는 실패 전이(Failure Transition) 와 멱등성(Idempotency) 이 핵심이다. 자동화된 복구 작업이 중간에 실패했을 때 안전하게 재시도하거나 롤백할 수 있어야 하며, 같은 작업이 중복 실행되더라도 부작용이 없어야 한다. 특히 데이터베이스 페일오버처럼 돌이키기 어려운 작업일수록 이 두 가지 원칙이 중요해진다.
정리
- 데이터베이스 인프라를 그래프로 모델링하면, 장애 범위 파악과 복구 계획 산출을 알고리즘으로 자동화할 수 있다.
- 상태 머신은 복구 실행 흐름을 명시적으로 관리하여 예측 가능성과 안전성을 높인다.
- 자동화 도입 시 그래프 모델의 최신성 유지, 실패 전이 설계, 멱등성 보장이 선결 조건이다.