관리형 데이터베이스 선택 기준: 백업 복원·장애 조치·운영 비용 검증

1장. 데이터베이스는 살아났는데 주문 서비스는 여전히 죽어 있었다#

오전 9시 정각.

주문 데이터베이스의 주 인스턴스에 장애가 발생했습니다.

관리형 데이터베이스 서비스는 장애를 감지했고 오전 9시 4분에 대기 노드를 새로운 주 노드로 전환했습니다.

관리 콘솔에는 다음과 같이 표시됩니다.

Database
AVAILABLE

운영팀은 생각합니다.

4분 만에 복구됐다.

그런데 고객은 여전히 주문할 수 없습니다.

애플리케이션의 기존 연결 풀이 장애가 난 연결을 계속 재사용하고 있었기 때문입니다.

실제 주문 API가 정상화된 시간은:

09:12

였습니다.

따라서 두 개의 복구 시간이 존재합니다.

DB 인프라 전환
4분

실제 주문 서비스 재개
12분

이 차이를 이해하지 못하면 관리형 데이터베이스의 가용성을 실제 서비스 가용성과 혼동하게 됩니다.

2장. 관리형이라는 말은 “운영 책임이 사라진다”는 뜻이 아니다#

관리형 데이터베이스는 공급자가 많은 운영 작업을 맡아 줍니다.

예를 들어 서비스에 따라:

인프라 프로비저닝

일부 패치

모니터링 기반 기능

자동 백업 기능

복제

장애 전환

스토리지 관리

등을 제공할 수 있습니다.

하지만 공급자가 대신 결정하지 않는 것도 많습니다.

어떤 데이터를 반드시 보존해야 하는가?

몇 분의 데이터 손실까지 허용하는가?

몇 분 안에 주문 서비스를 복구해야 하는가?

잘못 삭제한 데이터는 어느 시점으로 복원할 것인가?

중복 결제를 어떻게 방지할 것인가?

복구된 데이터가 실제 업무적으로 맞는가?

관리형 서비스는 운영 도구를 제공하는 것과 업무 복구 결과를 보장하는 것을 구분해서 봐야 합니다.

3장. 먼저 데이터의 성격부터 나누자#

모든 데이터를 같은 데이터베이스에 넣어야 하는 것은 아닙니다.

예를 들어 서비스에 다음 데이터가 있다고 하겠습니다.

주문 원장#

주문

결제 상태

환불

상품 수량

필요한 성질:

트랜잭션

무결성

복구

장애 대응

세션 캐시#

로그인 상태

일시적 토큰

화면 캐시

필요한 성질:

낮은 지연

TTL

빠른 재생성

월간 매출 분석#

수개월~수년 데이터

대량 집계

기간 비교

필요한 성질:

대규모 스캔

집계

이력

같은 저장소로 모두 해결하려 하기보다 데이터의 역할을 먼저 나누는 것이 좋습니다.

4장. 제품보다 업무 요구를 먼저 적어야 한다#

다음 질문부터 적어 봅니다.

주문 데이터를 몇 분까지 잃어도 되는가?

DB 장애 후 몇 분 안에 주문을 재개해야 하는가?

잘못된 DELETE를 몇 시간 전까지 복원해야 하는가?

복원된 환경에서 권한과 연결을 누가 다시 설정하는가?

다른 지역이나 다른 계정에서도 복원 가능한가?

서버리스 재개 지연을 허용할 수 있는가?

이 요구가 있어야 실제 서비스를 비교할 수 있습니다.

5장. 관리형 DB 선택에 RPO와 RTO를 넣어야 한다#

업무 요구를 다음과 같이 정했다고 하겠습니다.

RPO
5분

RTO
30분

RPO는:

장애 시 최대 어느 정도의 데이터 손실을 허용할 것인가?

를 의미합니다.

RTO는:

장애 뒤 얼마 안에 업무를 다시 시작해야 하는가?

를 의미합니다.

관리 콘솔에:

자동 백업
ON

고가용성
ON

이라고 표시돼도 실제 RPO·RTO가 충족됐다는 뜻은 아닙니다.

6장. 자동 백업은 복구 가능성의 출발점일 뿐이다#

서비스에 자동 백업 기능이 있습니다.

그렇다면 최소한 다음을 더 확인해야 합니다.

보존 기간은 얼마인가?

어느 시점까지 복원 가능한가?

실제로 복원해 보았는가?

복원 시간은 얼마인가?

애플리케이션 권한은 그대로 사용할 수 있는가?

복원된 DB 주소는 기존과 같은가?

백업 자체가 삭제되면 어떻게 되는가?

기능 목록에 Backup이 있다는 사실만으로 복구 전략이 완성되지는 않습니다.

7장. 백업 성공과 복원 성공은 다르다#

매일 다음 메시지를 받는다고 하겠습니다.

Backup completed successfully.

하지만 1년 동안 한 번도 복원해 본 적이 없습니다.

실제 장애 날 다음 문제를 처음 발견할 수 있습니다.

복원 시간이 예상보다 길다.

복원된 DB에 필요한 권한이 없다.

애플리케이션 연결 정보가 다르다.

필요한 로그 보존 기간이 부족하다.

암호화 키를 찾을 수 없다.

따라서 백업 운영의 핵심 지표 중 하나는:

백업 생성 성공

뿐 아니라:

복원 시험 성공

이어야 합니다.

8장. 장애 전환과 시점 복원은 전혀 다른 기능이다#

주 데이터베이스에서 실수로 다음 SQL이 실행됐다고 하겠습니다.

DELETE FROM orders
WHERE ordered_at < DATE '2026-10-01';

운영자가 조건을 잘못 입력해 필요한 주문까지 삭제했습니다.

그리고 COMMIT했습니다.

복제본이 정상적으로 동기화되고 있다면:

Primary
주문 삭제

↓

Replica
주문 삭제 반영

이 될 수 있습니다.

이 상황에서 복제본으로 장애 전환한다고 삭제 전 상태로 돌아가는 것은 아닙니다.

9장. 복제는 고가용성이고 백업은 시간 복구에 가깝다#

단순화하면:

복제#

현재 상태를 여러 곳에 유지

주로:

노드 장애

읽기 확장

빠른 전환

에 사용됩니다.

백업·PITR#

과거 상태를 복원

주로:

실수 삭제

논리적 데이터 손상

장기 보존

재해 복구

에 사용합니다.

둘을 같은 기능으로 보면 안 됩니다.

10장. 주문 데이터 삭제 사고를 실제로 시험해 보자#

14시 7분에 잘못된 DELETE를 커밋했다고 하겠습니다.

목표:

14:06:50

상태로 복원하고 싶습니다.

시험 절차를 다음과 같이 만들 수 있습니다.

flowchart TD
    A["실수 DELETE 커밋"] --> B["복구 목표 시각 결정"]
    B --> C["별도 환경에 PITR"]
    C --> D["삭제 전 주문 확인"]
    D --> E["품목·결제 상태 검증"]
    E --> F["필요 데이터 추출 또는 서비스 전환"]

핵심은 운영 DB를 무작정 과거로 덮어쓰는 것이 아닙니다.

11장. 복원은 별도 환경에서 검증하는 편이 안전할 수 있다#

14시 7분에 잘못된 DELETE가 실행됐습니다.

그런데 14시 7분 이후에도 정상 주문이 계속 들어왔습니다.

운영 DB 전체를 14시 6분으로 되돌리면 그 이후 정상 주문까지 사라집니다.

따라서:

과거 시점 DB 복원
↓
잘못 삭제된 행 확인
↓
필요 데이터 추출
↓
현재 운영 DB와 비교
↓
선별 복원

을 선택할 수도 있습니다.

12장. 관리형 DB가 복원해 줘도 업무 판단은 남는다#

복원 서비스가 기술적으로 성공했습니다.

하지만 다음을 공급자가 대신 결정하지는 않습니다.

어떤 주문을 되돌릴 것인가?

복원 이후 들어온 정상 주문은 어떻게 유지할 것인가?

중복 결제가 있는가?

환불 상태는 어떻게 맞출 것인가?

복원 기능과 업무 복구 절차는 분리해야 합니다.

13장. 장애 전환 시간과 서비스 복구 시간을 별도로 기록하자#

예:

시각	상태
09:00	주 DB 장애
09:01	장애 감지
09:04	새 주 DB 쓰기 가능
09:07	애플리케이션 재연결 시작
09:12	주문 API 정상
09:14	결제 검증 완료

여기서:

DB 장애 전환
4분

입니다.

하지만 업무 RTO는 보수적으로:

14분

으로 볼 수도 있습니다.

어디를 업무 복구 완료 지점으로 정의하는지 미리 정해야 합니다.

14장. 연결 풀이 장애 전환을 따라가지 못할 수 있다#

애플리케이션은 DB 연결을 미리 여러 개 만들어 둡니다.

Connection Pool
20개

장애가 발생합니다.

새 DB는 이미 사용 가능합니다.

하지만 풀 안에는:

죽은 기존 연결

이 남아 있습니다.

애플리케이션이 계속 이 연결을 재사용하면 사용자 요청은 실패합니다.

15장. 관리형 서비스의 장애 전환 기능만 시험해서는 부족하다#

시험은 다음까지 이어져야 합니다.

DB 장애 유도
↓
새 주 노드 활성화
↓
기존 연결 실패
↓
연결 풀 폐기·재생성
↓
새 연결 성공
↓
주문 조회 성공
↓
새 주문 생성 성공

이 전체 시간을 측정해야 실제 RTO에 가깝습니다.

16장. DNS 전환도 즉시 모든 연결을 바꾸지는 않는다#

관리형 DB는 엔드포인트를 유지하면서 내부 대상이 바뀌는 구조를 사용할 수 있습니다.

그렇더라도 기존 TCP 연결이 자동으로 새 DB로 순간 이동하는 것은 아닙니다.

기존 연결은 실패할 수 있고 애플리케이션은 다시 연결해야 합니다.

따라서:

엔드포인트가 유지된다
=
애플리케이션 무중단

이라고 단정하면 안 됩니다.

17장. 장애 전환 중 가장 까다로운 것은 결과를 모르는 주문이다#

고객이 주문 버튼을 눌렀습니다.

서버에서:

INSERT 주문
↓
COMMIT

까지 성공했습니다.

그 직후 DB 연결이 끊겼습니다.

애플리케이션은 성공 응답을 받지 못했습니다.

사용자 화면:

주문 실패

그러나 DB:

주문 성공

일 수 있습니다.

18장. 타임아웃은 반드시 실패를 의미하지 않는다#

장애 시 요청은 여러 상태일 수 있습니다.

DB 도달 전 실패

DB 처리 중 실패

ROLLBACK됨

COMMIT 완료 후 응답 유실

COMMIT 결과 확인 불가

따라서:

timeout
=
재실행

만으로 처리하면 중복 주문이 생길 수 있습니다.

19장. 주문 요청에는 업무 식별자가 필요하다#

예를 들어:

request_id
=
ORDER-20261001-001782

를 사용합니다.

첫 요청이 이미 성공했다면 재시도 때:

새 주문 생성

이 아니라:

기존 request_id 결과 확인

이 가능해야 합니다.

20장. 장애 전환 시험에서는 중복과 누락을 함께 찾아야 한다#

장애 전에 다음 주문을 기록했다고 하겠습니다.

O100
성공 응답 확인

O101
응답 유실

O102
실패 응답

장애 전환 후 확인합니다.

O100
반드시 존재

O101
존재할 수도 있음
→ request_id로 확인

O102
실제 커밋 여부 확인

단순히 DB 접속 성공만 검사해서는 업무 복구를 검증할 수 없습니다.

21장. RPO를 실제 주문으로 검증하자#

장애 발생:

14:00

복원 후 마지막으로 확인 가능한 정상 주문:

13:52

입니다.

관측 데이터 손실:

14:00 - 13:52
=
8분

목표:

RPO
5분

이라면 실패입니다.

22장. 백업 기능이 있어도 RPO는 실패할 수 있다#

가능한 이유는:

보관 정책 부족

로그 전송 지연

복제 지연

복원 지점 선택 오류

PITR 범위 부족

등입니다.

자동 백업 ON이라는 설정값보다 실제 마지막 복구 거래가 더 중요한 증거입니다.

23장. RTO도 주문 API로 확인해야 한다#

장애:

14:00

새 DB 준비:

14:12

애플리케이션 연결:

14:25

새 주문 정상 처리:

14:42

이라면 업무 RTO 실측은:

42분

입니다.

목표가 30분이라면 실패입니다.

24장. DB 콘솔의 AVAILABLE 시각만으로 RTO를 계산하지 말자#

관리 콘솔에서:

14:12
AVAILABLE

이라고 표시됐습니다.

이것은 중요한 시각입니다.

하지만 사용자가 실제로 주문할 수 있었던 것은:

14:42

입니다.

따라서 최소한 다음을 분리해 기록하는 것이 좋습니다.

DB 복구 시각

애플리케이션 연결 시각

업무 기능 재개 시각

25장. 관리형 서비스의 책임과 애플리케이션 책임을 나눠 보자#

항목	관리 서비스가 제공할 수 있는 부분	사용자 측 책임
인프라	서버·스토리지 운영	용량·구성 선택
백업	백업 기능·복원 인터페이스	보존 정책·복원 시험
장애 전환	복제·전환 기능	연결 재시도·업무 검증
암호화	지원 기능	키·권한·정책 설정
모니터링	지표·로그	알림 기준·대응 절차
확장	용량 변경 기능	쿼리·비용·한계 관리

“관리형”이라고 해서 오른쪽 열이 사라지는 것은 아닙니다.

26장. 패치를 대신한다고 애플리케이션 호환성까지 보장되는 것은 아니다#

관리 서비스가 엔진 버전을 업그레이드한다고 하겠습니다.

공급자는 인프라 작업을 수행할 수 있습니다.

하지만 애플리케이션의:

SQL 문법

드라이버

확장 기능

ORM

실행 계획

이 새 버전에서도 문제없는지는 사용자가 확인해야 합니다.

27장. 유지보수 창도 서비스 요구와 맞아야 한다#

운영팀이 유지보수 시간을:

일요일 03:00

으로 정했습니다.

하지만 실제 서비스는 해외 사용자 때문에 24시간 주문이 발생합니다.

“새벽이니까 괜찮다”는 판단보다 실제 트래픽과 장애 허용 목표를 확인해야 합니다.

28장. 관리형이라고 성능 튜닝이 없어지는 것도 아니다#

공급자가 관리하는 것:

서버

스토리지

일부 운영 자동화

사용자가 여전히 관리해야 할 것:

잘못된 SQL

불필요한 조인

인덱스

긴 트랜잭션

핫 데이터

파티션 설계

입니다.

관리형 DB로 이전해도 SELECT *가 자동으로 최적화되는 것은 아닙니다.

29장. 자동 확장이 잘못된 데이터 모델을 치료해 주지는 않는다#

잘못된 쿼리가 매 요청마다:

1억 행

을 스캔한다고 하겠습니다.

컴퓨트를 자동으로 늘리면 일시적으로 버틸 수 있습니다.

하지만 비용이 크게 증가할 수 있습니다.

비효율적인 SQL
+
자동 확장
=
더 비싼 비효율

이 될 수도 있습니다.

30장. 그래서 성능과 비용을 함께 봐야 한다#

구성 A:

월 컴퓨트 비용
30만원

구성 B:

월 컴퓨트 비용
45만원

만 보면 A가 저렴합니다.

하지만 A의 장애 전환 시험:

50분

12분

업무 RTO:

20분

이라면 A는 요구 조건을 만족하지 못합니다.

가격이 싸다는 이유만으로 비교 후보가 동일하다고 볼 수 없습니다.

31장. 운영 비용은 인스턴스 가격 하나가 아니다#

총비용에는 다음이 포함될 수 있습니다.

컴퓨트

스토리지

I/O

복제본

백업 보관

스냅샷

데이터 전송

모니터링

복원 테스트 환경

개발·검증 환경

운영 인력

제품별 과금 구조가 다르기 때문에 단순한 시간당 인스턴스 가격만 비교하면 실제 비용을 놓칠 수 있습니다.

32장. 같은 조건에서 비용을 비교해야 한다#

구성 A:

단일 AZ

백업 1일

복제본 없음

구성 B:

다중 AZ

백업 30일

읽기 복제본 2개

인데 월 요금만 비교하면 당연히 왜곡됩니다.

다음 조건을 맞춰야 합니다.

같은 데이터 크기

같은 트래픽

같은 백업 보존

같은 가용성

같은 복구 목표

33장. 비용 비교에 복원 시험 비용도 포함할 수 있다#

매달 복원 훈련을 위해 별도 DB를 4시간 실행한다고 하겠습니다.

또 다른 지역에 백업 사본도 유지합니다.

이런 운영 비용은 평상시 인스턴스 비용만으로 보이지 않습니다.

하지만 실제 재해 복구 전략의 일부입니다.

34장. 서버리스는 “서버가 없다”는 뜻이 아니다#

서버리스 데이터베이스도 실제로는 공급자의 인프라에서 실행됩니다.

사용자 관점에서:

서버 프로비저닝

일부 용량 관리

를 덜 직접 수행한다는 의미에 가깝습니다.

따라서:

Serverless
=
무한 성능

Serverless
=
항상 가장 저렴함

으로 이해하면 안 됩니다.

35장. 자동 스케일링과 자동 일시중지는 다른 기능이다#

서버리스 서비스가 부하에 따라 컴퓨트 용량을 조절한다고 하겠습니다.

이것과:

유휴 시 0까지 내려가 완전히 일시중지

는 별도의 기능일 수 있습니다.

예를 들어 현재 Aurora Serverless v2는 지원 조건을 충족한 구성에서 최소 용량을 0 ACU로 설정해 자동 일시중지·재개를 사용할 수 있지만, 실제 지원 엔진 버전·구성·제약은 도입 시점의 문서에서 확인해야 합니다.

36장. 0까지 내려간다고 항상 좋은 것도 아니다#

야간 트래픽이 거의 없다고 하겠습니다.

일시중지되면 컴퓨트 비용을 줄일 수 있습니다.

하지만 새벽 첫 주문이 들어왔을 때:

DB 재개

연결 생성

첫 SQL 처리

에 추가 지연이 발생할 수 있습니다.

서비스 요구가:

첫 요청도 200ms 이내

라면 비용 절감보다 재개 지연이 더 중요한 문제가 될 수 있습니다.

37장. 열린 연결이 자동 중지 조건에 영향을 줄 수도 있다#

애플리케이션 연결 풀이 계속 DB 연결을 유지한다면 서비스의 자동 일시중지 조건과 충돌할 수 있습니다.

따라서 서버리스 비용 시험에서는:

웹 서버 연결 풀

모니터링 연결

배치 작업

관리 도구

까지 실제 환경과 비슷하게 구성해야 합니다.

38장. 야간 비용 시험도 실제 애플리케이션과 함께 해야 한다#

단순히 DB만 만들어 두고:

밤새 연결 없음

으로 시험하면 실제 서비스 비용을 재현하지 못할 수 있습니다.

실제 애플리케이션이:

health check

connection pool

monitoring

을 유지한다면 조건이 달라집니다.

39장. 제품의 최대 용량 숫자만으로 선택하지 말자#

제품 설명에는 흔히:

최대 저장 용량

최대 노드 수

최대 처리량

같은 숫자가 등장합니다.

하지만 실제 서비스가 필요한 것이:

500GB

초당 300 주문

이라면 최대 수십 TB라는 숫자가 의사결정의 핵심은 아닐 수 있습니다.

더 중요한 것은:

현재 부하에서 지연

장애 시 복구

비용

운영 복잡도

입니다.

40장. Aurora의 저장 구조 설명과 애플리케이션 정족수를 혼동하지 말자#

분산 저장 서비스는 내부적으로 여러 사본과 정족수 구조를 사용할 수 있습니다.

이것을 보고 애플리케이션 SQL마다:

R=3
W=4

같은 값을 직접 지정한다고 이해하면 안 됩니다.

서비스 내부 저장 아키텍처와 사용자가 선택하는 애플리케이션 일관성 설정은 다른 계층입니다.

41장. 내부 복제 사본도 독립 백업을 대신하지 않는다#

관리형 DB의 저장 계층이 여러 사본을 가진다고 하겠습니다.

스토리지 장치 하나가 고장 나도 데이터를 유지하는 데 도움이 됩니다.

하지만 사용자가:

DELETE

를 정상 커밋하면 논리적 변경은 모든 정상 사본에 반영될 수 있습니다.

따라서:

내부 복제
≠
과거 시점 백업

입니다.

42장. Google Cloud Spanner도 복구 기능을 기능별로 구분해서 봐야 한다#

현재 Google Cloud 문서에서 Spanner PITR은 구성된 버전 보존 기간 내의 과거 상태 복구에 사용되며 최대 보존 기간은 7일로 안내됩니다. 더 장기적인 보존에는 백업·내보내기 등의 별도 방법이 사용됩니다. 또한 백업은 최대 1년까지 보존할 수 있다고 안내됩니다.

여기서 중요한 것은 특정 숫자를 암기하는 것이 아닙니다.

PITR·백업·장기 보존은 서로 다른 복구 요구를 해결한다.

는 점입니다.

43장. 제품 사양은 반드시 도입 시점에 다시 확인해야 한다#

클라우드 서비스는 계속 바뀝니다.

다음 항목은 특히 변할 수 있습니다.

가격

지원 지역

지원 엔진 버전

최소·최대 용량

자동 중지 조건

백업 보존 범위

복제 기능

따라서 기술 문서에는:

현재 기능은 공급자 문서에서 확인한다.

는 원칙을 두는 것이 좋습니다.

44장. 기능 비교표보다 장애 시나리오 비교표가 더 유용하다#

다음 비교는 유용하지만 부족합니다.

기능	서비스 A	서비스 B
자동 백업	O	O
복제	O	O
서버리스	O	O

실제 선택에는 다음 표가 더 유용할 수 있습니다.

시험	서비스 A	서비스 B
DB 장애 전환	4분	2분
앱 정상화	12분	6분
PITR 복원	45분	28분
마지막 복구 데이터 손실	2분	1분
재연결 중 중복 주문	0	0

기능의 존재보다 실제 업무 결과를 비교합니다.

45장. 작은 PoC에서 바쁜 한 시간을 재현하자#

실서비스의 피크 시간을 분석합니다.

예:

주문 쓰기
초당 100건

상품 조회
초당 500건

보고서 조회
분당 20회

테스트 환경에서도 가능한 한 비슷하게 재현합니다.

단순히 주문 INSERT만 초당 100개 넣는 시험으로는 실제 경합을 확인하기 어렵습니다.

46장. 읽기와 쓰기를 함께 넣어야 실제 부하가 보인다#

서비스에서는 동시에:

주문 INSERT

주문 UPDATE

상품 SELECT

고객 조회

관리자 보고서 집계

가 발생합니다.

이런 혼합 부하에서는:

캐시

I/O

락

CPU

쿼리 스케줄링

이 서로 영향을 줄 수 있습니다.

47장. 동일한 데이터와 인덱스로 비교해야 한다#

서비스 A에는:

10GB 테스트 데이터

서비스 B에는:

500GB 운영 복제 데이터

를 넣고 성능을 비교하면 의미가 없습니다.

다음 조건을 최대한 맞춥니다.

데이터 건수

데이터 분포

인덱스

SQL

동시성

측정 시간

48장. 평균보다 p95·p99를 함께 기록하자#

관리형 DB 성능 시험에서도 평균만 보면 부족합니다.

예:

평균
50ms

p95
180ms

p99
1.2초

일 수 있습니다.

주문 서비스라면 일부 사용자의 긴 지연이 실제 경험을 크게 해칠 수 있습니다.

49장. 장애 조치 시험에서는 성공 주문을 미리 기록해 두자#

장애 전 다음 주문 ID를 따로 저장합니다.

O501
O502
O503

모두 사용자에게 성공 응답을 보낸 주문입니다.

장애 전환 후 반드시 다시 확인합니다.

O501 존재?

O502 존재?

O503 존재?

성공 응답을 받은 데이터가 사라졌다면 매우 중요한 문제입니다.

50장. 응답을 못 받은 주문도 따로 기록해야 한다#

장애 직전 주문 O504가 있습니다.

DB에서 COMMIT 여부가 불명확합니다.

장애 후:

request_id

로 조회합니다.

존재한다면 새 주문을 만들지 않습니다.

없다면 정책에 따라 재시도할 수 있습니다.

이 검증이 없으면 장애 시험 뒤 중복 주문이 생길 수 있습니다.

51장. 장애 테스트의 목적은 “전환 성공”이 아니다#

관리 콘솔:

Failover completed

이것은 하나의 증거일 뿐입니다.

업무 관점에서는 다음을 확인해야 합니다.

성공 주문 보존

중복 주문 없음

누락 주문 확인

새 주문 가능

결제 조회 가능

연결 풀 정상

여기까지 통과해야 실제 서비스 장애 조치 시험이라고 할 수 있습니다.

52장. 실수 삭제 시험도 별도로 해야 한다#

장애 전환 시험만 통과했다고 안심해서는 안 됩니다.

다음 상황도 만들어 봅니다.

DELETE FROM orders
WHERE order_id BETWEEN 1000 AND 2000;

그리고 COMMIT합니다.

그 뒤:

삭제 이전 시점 복원

복원 소요시간

복구 가능한 마지막 시점

권한 복구

앱 연결

을 시험합니다.

53장. RPO·RTO 시험표를 만들면#

목표:

RPO 5분
RTO 30분

시험 결과:

항목	결과
장애 발생	14:00
마지막 복구 거래	13:52
DB 복원 완료	14:25
앱 재연결	14:34
첫 정상 주문	14:42

RPO:

8분

RTO:

42분

둘 다 실패입니다.

54장. 실패한 이유를 각각 분리해야 한다#

RPO 실패 원인은:

로그 보존 부족

복제 지연

복원 지점 설정

일 수 있습니다.

RTO 실패 원인은:

복원 시간

권한 확인

DNS

연결 풀

애플리케이션 시작

업무 검증

일 수 있습니다.

둘을:

복구가 느렸다.

한 문장으로 합치면 담당자와 개선책을 찾기 어렵습니다.

55장. 서비스 선택 시 장애 책임 시간표를 만들어 보자#

단계	주 책임
인프라 장애 감지	공급자·운영
대기 노드 전환	공급자 기능·운영 정책
애플리케이션 재연결	개발·운영
미확정 요청 확인	애플리케이션
중복 방지	업무 설계
복원 데이터 검증	데이터·업무 담당
서비스 재개 승인	운영 조직

책임 경계를 적어 두면 장애 때 “누가 해야 하는지 몰라서” 시간을 잃는 일을 줄일 수 있습니다.

56장. 관리형 서비스의 SLA와 우리 서비스 SLO도 구분해야 한다#

공급자가 데이터베이스 서비스에 높은 가용성을 제공하더라도 애플리케이션 자체는:

잘못된 연결 설정

긴 재시도

코드 오류

잘못된 권한

외부 결제 장애

때문에 더 낮은 가용성을 보일 수 있습니다.

따라서 공급자 SLA를 그대로 우리 주문 서비스의 가용성이라고 볼 수 없습니다.

57장. 관리형 데이터베이스를 도입하면 모니터링이 없어지는 것도 아니다#

오히려 다음을 더 명확히 봐야 합니다.

CPU

메모리

스토리지

I/O

연결 수

락 대기

복제 지연

DB 지연

백업 상태

비용

공급자가 시스템을 운영해도 사용자 워크로드는 사용자가 가장 잘 알고 있습니다.

58장. 비용 알림도 운영 기능의 일부다#

자동 확장을 사용하는데 쿼리 오류로 부하가 급증했습니다.

시스템은 장애 없이 처리했습니다.

하지만 비용이 5배 증가했습니다.

기술적으로는:

가용성 성공

입니다.

사업적으로는:

비용 사고

일 수 있습니다.

따라서:

예산

비용 알림

일별 비용 변화

비정상 사용량

을 모니터링해야 합니다.

59장. 자동 확장은 비용 상한과 함께 설계하자#

가능하면 다음을 확인합니다.

최대 용량

자동 확장 범위

예산 알림

쿼리 제한

사용량 경보

무제한 확장처럼 보이는 기능도 실제로는 비용과 서비스 한계가 있습니다.

60장. 스토리지 증가 비용도 장기간 계산해야 한다#

현재 데이터:

500GB

월 증가:

100GB

1년 뒤 단순 예상:

1.7TB

입니다.

백업이 여러 세대 유지되고 복제본과 테스트 사본까지 있다면 총 저장량은 더 커질 수 있습니다.

61장. 백업 보존 기간을 줄이면 비용은 내려가지만 복구 범위도 줄어든다#

예:

보관 30일

에서:

7일

로 줄이면 비용을 낮출 수 있습니다.

하지만 10일 전에 발생한 논리적 오류를 발견하면 복구 지점이 없을 수 있습니다.

따라서 비용 절감과 복구 요구를 함께 봐야 합니다.

62장. 데이터 이동 비용도 고려하자#

분석 시스템이나 다른 지역으로 대량 데이터를 전송하면 별도의 전송 비용이 발생할 수 있습니다.

또 공급자를 바꾸려고 데이터를 외부로 꺼낼 때:

전송 시간

네트워크 비용

덤프 시간

다운타임

이 필요할 수 있습니다.

서비스 선택 시 진입 비용뿐 아니라 이탈 비용도 봐야 합니다.

63장. 관리형 서비스에서 탈출할 수 있는지도 시험해 보자#

다음 질문을 해봅니다.

데이터를 표준 형식으로 내보낼 수 있는가?

10TB 데이터를 내보내는 데 얼마나 걸리는가?

전용 기능에 얼마나 의존하는가?

애플리케이션 SQL이 다른 엔진에서도 동작하는가?

백업을 다른 환경에서 사용할 수 있는가?

필요한 이동 경로가 전혀 없다면 공급자 의존도가 커집니다.

64장. 그렇다고 공급자 종속 기능을 무조건 피할 필요는 없다#

전용 기능이:

운영 부담 감소

성능 향상

가용성 향상

개발 속도 향상

을 크게 제공할 수 있습니다.

중요한 것은:

종속이 존재한다.

는 사실을 알고 선택하는 것입니다.

장점과 이탈 비용을 함께 평가해야 합니다.

65장. 데이터베이스 이관 시험도 성능 시험만큼 중요하다#

현재 DB에서:

500GB

를 다른 환경으로 옮겨 봅니다.

측정할 것:

덤프 시간

전송 시간

복원 시간

인덱스 생성 시간

검증 시간

애플리케이션 전환 시간

입니다.

실제 이관 가능성을 한 번도 시험하지 않으면 공급자 변경이나 대규모 복구 때 처음 문제를 발견할 수 있습니다.

66장. 보안 책임도 관리형이라고 사라지지 않는다#

공급자가:

TLS 지원

저장 암호화

IAM 통합

감사 로그

같은 기능을 제공할 수 있습니다.

하지만 사용자가:

0.0.0.0/0 공개

관리자 권한 과다 부여

오래된 비밀번호 유지

감사 로그 미확인

을 하면 보안은 약해질 수 있습니다.

기능 제공과 안전한 설정은 다릅니다.

67장. 백업도 같은 계정에만 두는 것이 충분한지 검토하자#

운영 관리자 계정 하나가:

DB 삭제

백업 삭제

를 모두 할 수 있다고 하겠습니다.

그 계정이 탈취되면 운영 데이터와 백업이 함께 위험할 수 있습니다.

업무 중요도에 따라:

별도 계정

별도 프로젝트

별도 지역

삭제 보호

불변성 정책

등의 분리 전략을 검토할 수 있습니다.

68장. 장애 전환·복원·삭제 보호는 서로 다른 위험을 줄인다#

장애 전환#

서버 또는 노드 장애

PITR#

잘못된 UPDATE·DELETE

백업#

장기 보존·재해 복구

삭제 보호#

DB 자체의 실수 삭제

각 기능이 막는 사고 경로가 다릅니다.

69장. 데이터베이스 자체가 삭제된 경우까지 고려하자#

어떤 PITR 기능은 데이터베이스 내부 데이터 변경 복구에는 유용하지만 데이터베이스 리소스 자체가 삭제되는 사고는 별도의 보호가 필요할 수 있습니다.

예를 들어 현재 Spanner 문서도 PITR을 논리적 데이터 오류 복구에 사용할 수 있다고 설명하면서 데이터베이스 삭제에 대해서는 별도의 삭제 보호 및 다른 복구 옵션을 함께 고려하도록 안내합니다.

기능의 이름보다 어떤 사고를 보호하는지를 확인해야 합니다.

70장. 테스트 환경에서 장애를 반복 재현할 수 있어야 한다#

좋은 검증은 한 번의 성공 사례로 끝나지 않습니다.

예:

DB 장애 전환

복제본 장애

네트워크 단절

잘못된 DELETE

대량 쓰기 중 장애

유휴 후 서버리스 재개

백업 복원

을 반복해 봅니다.

71장. 실패 주입 뒤 반드시 업무 데이터까지 검증하자#

장애 전환 후:

DB 접속 성공

만 확인하지 않습니다.

다음도 봅니다.

마지막 성공 주문 존재

상품 품목 수 정상

결제 상태 정상

중복 주문 없음

새 주문 생성 성공

데이터베이스 상태보다 업무 결과가 최종 기준입니다.

72장. 작은 검증 환경의 결과도 그대로 운영에 대입하면 안 된다#

테스트:

데이터 10GB

운영:

데이터 5TB

라면 복원 시간이 크게 달라질 수 있습니다.

또 테스트의 동시 사용자가 10명이고 운영이 1만 명이라면 장애 전환 후 재연결 폭주도 달라집니다.

PoC는 선택 근거지만 운영 규모를 반영해 보정해야 합니다.

73장. 장애 직후 재연결 폭주도 시험해 보자#

DB가 복구됐습니다.

수천 개 애플리케이션 연결이 동시에 다시 접속합니다.

flowchart TD
    D["DB 복구"] --> A["앱 서버 1"]
    D --> B["앱 서버 2"]
    D --> C["앱 서버 N"]
    A --> R["대량 재연결"]
    B --> R
    C --> R

이때 DB CPU와 연결 제한이 다시 병목이 될 수 있습니다.

재시도에 지수 백오프나 지터를 사용하는 이유입니다.

74장. 모든 애플리케이션이 즉시 재시도하면 2차 장애가 생길 수 있다#

장애 중:

10만 요청

이 실패했습니다.

DB가 살아난 순간 모두 동시에 재시도하면 다시 과부하가 발생합니다.

따라서:

재시도 횟수 제한

백오프

지터

업무 멱등성

을 함께 설계하는 것이 좋습니다.

75장. 장애 전환 시험은 인프라와 애플리케이션 공동 시험이다#

DB 운영팀만 참여하면:

DB 정상

에서 시험이 끝날 수 있습니다.

하지만 실제로는:

DB

백엔드

결제

네트워크

모니터링

업무 담당

이 함께 검증해야 합니다.

서비스 복구는 여러 계층이 연결된 결과이기 때문입니다.

76장. 관리형 DB 비교표에 넣어야 할 항목#

업무 요구#

목표 RPO

목표 RTO

트랜잭션 요구

읽기·쓰기 부하

복구#

자동 백업

PITR

백업 보존

교차 지역·계정 복원

삭제 보호

가용성#

복제 구조

장애 전환

재연결 방식

복제 지연

성능#

p95·p99

I/O

확장 시간

최대 연결

비용#

컴퓨트

스토리지

I/O

백업

복제

전송

77장. 여기에 운영 책임을 한 열 더 넣자#

항목	서비스 지원	우리 팀 책임
백업 생성	자동 가능	정책·검증
복원	기능 제공	목표 시점·데이터 검증
Failover	자동화 가능	앱 재연결
확장	자동화 가능	비용·쿼리 효율
보안	기능 제공	설정·권한
모니터링	지표 제공	알림·대응
업그레이드	자동화 가능	호환성 검증

기능이 있다는 사실과 누가 최종 책임지는지를 함께 기록합니다.

78장. 가상 서비스 A와 B를 비교해 보자#

업무 요구:

RPO ≤ 5분

RTO ≤ 20분

월 비용 ≤ 60만원

시험:

항목	A	B
월 총비용	30만원	45만원
마지막 복구 손실	2분	1분
DB 전환	8분	4분
앱 정상화	50분	12분

A는 저렴하지만:

RTO 50분

입니다.

업무 조건을 충족하지 못합니다.

79장. 단순히 B가 더 좋은 제품이라는 뜻은 아니다#

A의 앱 정상화가 50분 걸린 이유가:

잘못된 연결 풀 설정

이라면 제품보다 애플리케이션 문제일 수 있습니다.

설정을 고친 뒤 A가 15분에 복구될 수도 있습니다.

따라서 테스트는 제품 점수 매기기가 아니라:

전체 시스템에서 요구 조건을 충족하는 구성을 찾는 과정

이어야 합니다.

80장. 비용도 구성 변경 뒤 다시 계산해야 한다#

A에서 RTO를 맞추기 위해:

추가 복제본

더 높은 용량

백업 분리

가 필요해졌습니다.

월 비용:

30만원
→
55만원

이 됐습니다.

이제 B의 45만원보다 비쌉니다.

초기 가격표만 비교했을 때와 결론이 달라집니다.

81장. 관리형 DB 선택의 실제 비교 단위는 “제품”보다 “구성”이다#

같은 서비스라도:

단일 인스턴스

다중 AZ

읽기 복제본

서버리스

프로비저닝

백업 7일

백업 35일

에 따라 비용과 복구 능력이 달라집니다.

그래서:

A 서비스 vs B 서비스

보다:

A의 구성 X

vs

B의 구성 Y

를 비교해야 합니다.

82장. 최저 가격 구성으로 PoC하고 운영 구성과 비교하면 안 된다#

PoC에서는:

최소 용량

복제 없음

짧은 백업

을 사용했습니다.

운영에서는:

고가용성

장기 백업

대형 스토리지

가 필요합니다.

PoC 월 비용을 운영 예상 비용으로 그대로 사용하면 크게 틀릴 수 있습니다.

83장. 요구사항별로 서비스가 다를 수도 있다#

주문 원장:

관리형 관계형 DB

세션:

관리형 키값·인메모리

분석:

DW·레이크 계열

처럼 역할을 분리할 수 있습니다.

모든 데이터를 하나의 DB 서비스로 통일하는 것이 운영을 단순하게 만들 수도 있지만 워크로드에 따라 비용과 성능이 나빠질 수도 있습니다.

84장. 저장소가 늘어나면 데이터 일관성 책임도 늘어난다#

여러 저장소를 사용하면 다음 문제가 생깁니다.

주문 DB
성공

캐시 무효화
실패

분석 이벤트
지연

따라서 다중 저장소 구조에서는 이벤트·재처리·캐시 정책도 함께 설계해야 합니다.

관리형 서비스의 개수가 많아질수록 자동으로 운영이 쉬워지는 것은 아닙니다.

85장. “운영 부담 감소”를 실제 시간으로 측정해 볼 수 있다#

자체 운영 DB에서는 매월:

패치
6시간

백업 점검
4시간

모니터링 유지
5시간

이 필요했습니다.

관리형 서비스로 이동한 뒤:

패치 검증
2시간

복원 시험
4시간

비용·성능 점검
3시간

이 되었다고 하겠습니다.

그렇다면 운영 시간 절감 자체가 실제 비용 비교 자료가 됩니다.

86장. 사람의 운영 시간도 총소유비용이다#

월 인프라 비용:

자체 운영
30만원

관리형
60만원

만 보면 자체 운영이 저렴합니다.

하지만:

DB 운영 인력

장애 대응

야간 호출

패치

백업 복구

에 드는 시간이 크게 다르다면 총비용은 달라질 수 있습니다.

87장. 직접 운영을 선택할 때도 같은 기준을 적용할 수 있다#

관리형 DB와 자체 운영을 비교할 때도:

RPO

RTO

복원 시간

장애 전환

보안

운영 시간

총비용

이라는 같은 기준을 사용하면 됩니다.

관리형이라고 무조건 좋은 것도, 자체 운영이라고 무조건 저렴한 것도 아닙니다.

88장. 관리형 DB 검증 시나리오를 하나로 묶어 보자#

flowchart TD
    A["정상 부하 시험"] --> B["성능·비용 측정"]
    B --> C["주 DB 장애 유도"]
    C --> D["DB 전환 시간 측정"]
    D --> E["앱 재연결 확인"]
    E --> F["중복·누락 주문 검사"]
    F --> G["실수 DELETE 수행"]
    G --> H["PITR 복원"]
    H --> I["RPO·RTO 검증"]
    I --> J["유휴·서버리스 비용 측정"]
    J --> K["이관·탈출 시험"]

이 결과를 같은 조건에서 비교하면 제품 설명보다 훨씬 구체적인 선택 근거를 얻을 수 있습니다.

89장. 실험 결과에는 조건을 반드시 남겨야 한다#

예:

데이터 크기
500GB

주문 쓰기
100 TPS

조회
500 QPS

동시 연결
200

백업 보존
30일

가용성
다중 장애 영역

테스트 지역
서울 사용자 기준

애플리케이션 버전
v3.8

이 조건이 있어야 결과를 다시 재현하고 비교할 수 있습니다.

90장. 가격 정보에는 기준일도 필요하다#

클라우드 가격은 변할 수 있습니다.

따라서 문서에:

월 43만 원

이라고만 적기보다:

2026-10 기준 가정

지역

인스턴스 구성

스토리지

I/O

백업 조건

을 함께 남기는 것이 좋습니다.

고정 비용처럼 책에 박아두는 것은 위험할 수 있습니다.

91장. 제품 스펙도 같은 원칙이다#

다음과 같은 숫자:

최대 스토리지

최대 ACU

최대 노드

PITR 기간

은 서비스와 버전에 따라 바뀔 수 있습니다.

따라서 기술 개념을 설명하는 본문에서는 원칙을 중심으로 설명하고 실제 도입 시 최신 공식 문서를 확인하는 것이 안전합니다.

92장. 관리형 DB 선택 체크리스트#

이 데이터의 업무 중요도는 어느 정도인가?
목표 RPO는 얼마인가?
목표 RTO는 얼마인가?
자동 백업 보존 기간은 충분한가?
PITR이 필요한 시점을 지원하는가?
실제 복원을 시험했는가?
복원된 마지막 거래를 확인했는가?
장애 전환 뒤 앱이 자동 재연결되는가?
오래된 연결을 어떻게 폐기하는가?
응답을 잃은 주문을 안전하게 재시도할 수 있는가?
중복 주문·중복 결제를 방지하는가?
서비스 장애와 논리적 삭제 사고를 각각 시험했는가?
백업 삭제 사고까지 고려했는가?
비용 비교 조건이 동일한가?
백업·복제·전송 비용까지 포함했는가?
서버리스 재개 지연을 측정했는가?
유휴 상태에서 실제 최소 비용을 측정했는가?
다른 환경으로 데이터 이관이 가능한가?
공급자 전용 기능 의존도를 알고 있는가?
기능·가격·용량을 최신 공식 문서에서 다시 확인했는가?

93장. 장애 훈련 기록에 남겨야 할 항목#

장애 발생 시각

장애 감지 시각

DB 전환 시각

애플리케이션 재연결 시각

첫 정상 조회 시각

첫 정상 주문 시각

마지막 보존 주문 ID

중복 주문 건수

누락 주문 건수

RPO 실측

RTO 실측

복원 비용

담당자

이 기록이 있어야 다음 훈련에서 개선 여부를 비교할 수 있습니다.

94장. 핵심 정리#

관리형 데이터베이스를 선택할 때 가장 흔한 오류는 기능 목록부터 비교하는 것입니다.

자동 백업 O

Failover O

Serverless O

암호화 O

이 표만으로는 실제 주문 서비스가 장애를 견딜 수 있는지 알 수 없습니다.

먼저 업무 요구를 정해야 합니다.

RPO

RTO

데이터 크기

트랜잭션 요구

트래픽

보존 기간

보안 요구

그다음 같은 조건으로 서비스를 시험합니다.

관리형 서비스의 장애 전환과 업무 복구도 구분해야 합니다.

DB 전환 완료
09:04

주문 API 정상
09:12

이라면 데이터베이스는 4분 만에 전환됐지만 사용자는 12분 동안 주문하지 못했습니다.

또한 복제본과 백업의 역할도 다릅니다.

복제본
→ 현재 상태의 고가용성

백업·PITR
→ 과거 상태의 복구

잘못된 DELETE가 정상적으로 복제됐다면 복제본으로 전환해도 삭제된 데이터가 돌아오지 않습니다.

장애 전환 중에는 결과 불명 요청도 반드시 확인해야 합니다.

DB에서는 COMMIT

사용자는 응답을 받지 못함

이라는 상황에서 같은 주문을 다시 만들면 중복 주문과 이중 결제가 발생할 수 있습니다.

그래서:

request_id

idempotency key

결과 조회

같은 업무 수준의 재시도 설계가 필요합니다.

비용도 단순 월 인스턴스 요금으로 비교하지 않습니다.

컴퓨트

스토리지

I/O

백업

복제

네트워크

복원 시험

운영 인력

까지 포함한 총소유비용을 봐야 합니다.

서버리스 역시:

자동 스케일링

자동 일시중지

0 용량

재개 지연

을 하나의 기능으로 생각해서는 안 됩니다.

제품과 설정에 따라 지원 조건이 다르고, 비용을 줄이는 대신 첫 요청 지연이 커질 수도 있습니다.

최종적으로 좋은 관리형 DB 선택은:

어떤 제품이 가장 유명한가?

에 답하는 일이 아닙니다.

우리 주문 서비스의 같은 장애를 넣었을 때 어느 구성이 목표 RPO와 RTO를 충족하고, 중복·누락 없이 복구되며, 감당 가능한 비용으로 운영되는가?

를 검증하는 일입니다.

그리고 관리형 서비스를 도입한 뒤에도 가장 중요한 질문은 남습니다.

데이터베이스가 다시 켜진 시점이 아니라 사용자가 실제로 다시 정상 주문할 수 있었던 시점은 언제인가?

그 시각을 측정할 수 있어야 관리형 데이터베이스의 가용성과 실제 서비스의 복구 능력을 같은 언어로 비교할 수 있습니다.