DSQL의 개발·운영 편의성과 도입 부담

결과 요약

이 실험은 DSQL을 도입할 때 인프라 운영 작업이 얼마나 줄고, 그 대신 애플리케이션과 운영 절차에 어떤 부담이 더해지는지를 정리했습니다. 최소 범위(MVP)로, 새 AWS 실행 없이 E001부터 E012까지 네 서비스(DSQL, RDS Multi-AZ, Aurora Provisioned, Aurora Serverless v2)를 실제로 만들고, 적재하고, 부하를 주고, 복구하고, 지우며 겪은 작업을 모았습니다. 계획의 작업별 시간 측정과 3회 재실행은 하지 않았으므로, 작업 시간 절감률은 계산하지 않았습니다.

인프라 쪽 작업은 DSQL이 뚜렷하게 적었습니다. DSQL 클러스터는 생성 요청 뒤 32초 만에 쓸 수 있었고 삭제는 약 2분이었습니다. Aurora Serverless v2(writer+reader)는 생성에 약 11분, 삭제에 약 15분이 걸렸습니다. DSQL에는 인스턴스 크기나 최소·최대 용량을 고르는 단계, 저장할 비밀번호, vacuum 같은 유지보수 설정, 읽기·쓰기 라우팅이 없었고, 2만 4천 TPS까지 부하가 늘어도 용량을 조정할 필요가 없었습니다.

반면 애플리케이션 쪽 부담은 DSQL에서 늘었습니다. 업무 SQL 35개 가운데 16개를 고쳐야 했고(E001), 커밋 시점 충돌을 다시 시도하는 코드가 필수였습니다(E004). 트랜잭션은 3,000행과 300초를 넘을 수 없어 적재·삭제·배치 코드를 나눠야 했고(E002, E008), 비동기 인덱스는 완료를 따로 확인해야 했으며, 외래 키 쪽 인덱스를 직접 만들어야 했습니다. 연결은 1시간마다 교체하고 IAM 토큰을 서명해야 했고(E003), 시점 복원이 없어 실수 복구는 백업 주기에 묶였습니다(E007).

프로덕션 사용 관점

DSQL은 “DB 서버를 운영하는 일”을 크게 줄여 줍니다. 용량 계획, 인스턴스 교체, 비밀번호 교체, vacuum, reader 라우팅을 신경 쓸 필요가 없었고, 클러스터 생성도 30초 남짓이었습니다. 대신 그 부담의 상당 부분이 애플리케이션으로 옮겨 갑니다. 기존 PostgreSQL 코드는 SQL 수정, 재시도, 트랜잭션 분할, 연결 교체를 다시 설계해야 하고, 시점 복원이 없는 만큼 백업 주기와 복구 절차를 따로 정해야 합니다. 새로 만드는 서비스가 처음부터 이 제약에 맞춰 설계한다면 이점이 크고, 저장 프로시저·대량 배치가 많은 기존 서비스를 옮기면 부담이 큽니다. 작업 시간은 측정하지 않았습니다.

확인할 질문

DSQL은 초기 도입·반복 운영의 작업 시간과 수정량을 얼마나 줄이거나 늘리는가?

실행 조건

추가 AWS 실행: 없음. E001–E012의 실행 기록, 도구 코드 변경 이력, 공개 보고서를 근거로 정리했습니다.
대상: D1 Aurora DSQL, R1 RDS PostgreSQL 16 Multi-AZ, A1 Aurora PostgreSQL 16 Provisioned, A2 Aurora PostgreSQL 16 Serverless v2(서울).
계획과 달라진 점: 작업별 실제 작업 시간·대기 시간 측정, 첫 구현과 독립 3회 재실행, 권한 오류 진단 시험, 기준 PostgreSQL 앱의 서비스별 diff 관리는 하지 않았습니다. 아래 표의 시간은 자동화 도구 로그에서 읽은 서비스 대기 시간입니다.

성능 결과

인프라 작업(자동화 로그 기준)

작업	DSQL	Aurora Serverless v2(writer+reader)	근거
생성 요청 → 사용 가능	32초	약 11분	E005–E009 실행 B, 2026-09-29
삭제 요청 → 삭제 완료	약 2분	약 15분	E002 2차·실행 B
용량 선택	없음	ACU 최소·최대, reader 승격 순위	E002
인증 준비	IAM 권한(`dsql:DbConnectAdmin`)	관리형 비밀번호(Secrets Manager)	E002
읽기 라우팅	없음(단일 엔드포인트, 즉시 최신)	reader 엔드포인트, 쓰기 직후 읽기는 writer	E005
부하 증가 대응	없음(24,541 TPS까지)	최대 ACU 안에서 자동, 상한 32 ACU	E002, E009
실수 복구	백업 볼트·역할 준비, 전체 백업 → 새 클러스터(129초)	시점 복원 → 새 클러스터 + 인스턴스(587초)	E007

애플리케이션과 절차에 더해진 작업(DSQL)

항목	필요한 변경	근거
SQL 호환성	35개 중 16개 수정: sequence·identity, `serial`, 인덱스 생성, 임시 테이블·파티션, PL/pgSQL·트리거, 격리 수준, `statement_timeout`, 서버 측 취소	E001
동시성	커밋 시점 충돌(`40001`) 재시도와 업무 ID로 커밋 여부 확인이 필수. READ COMMITTED 없음	E004
트랜잭션 크기·시간	3,000행, 300초 한도에 맞춰 적재·삭제·배치를 분할	E002, E008
인덱스	`CREATE INDEX ASYNC` 후 `indisvalid` 확인. 외래 키 쪽 인덱스 직접 생성	E002, E008
연결	1시간 연결 수명에 맞춘 교체, IAM 토큰 서명·캐시, 동시 첫 연결 시 서명 경합 방지	E002, E003
일시 오류	적재 중 `XX000 server unavailable` 재시도	E002
대량 삭제	느려서 측정 도구의 초기화 방식을 바꿔야 했음	E002
복구	시점 복원 없음. 백업 주기로 RPO 결정, 복원 뒤 새 엔드포인트·권한으로 전환	E007
진단	`SHOW max_connections`가 20을 반환(실제 쿼터는 1만)	E004

개발·운영 편의성

인프라 운영 측면에서 DSQL이 줄여 준 작업은 생성·삭제 대기, 용량 계획, 비밀번호 관리, 유지보수 설정, 읽기 라우팅입니다. 이 작업들은 반복 운영에서 매번 드는 일이라 서비스 수가 많을수록 효과가 커집니다.
애플리케이션 측면에서 늘어난 작업은 대부분 한 번 구현하면 재사용할 수 있는 코드(재시도, 트랜잭션 분할, 토큰 서명, 연결 교체)이지만, 기존 코드베이스에서는 전 영역에 걸친 수정이 필요합니다.
이번 연구의 부하 도구도 DSQL 대응을 위해 여러 번 고쳤습니다: server unavailable 재시도, 청크 단위 적재 재개, 비동기 인덱스 완료 대기, 외래 키 인덱스 추가, 트랜잭션 분할, 토큰 서명 잠금, 초기화 방식 변경.

비용

이 보고서 자체는 AWS 자원을 만들지 않았습니다. 인용한 실행의 비용은 각 보고서와 E010에 정리했습니다.

결론과 한계

DSQL은 인프라 운영 작업을 줄이고 애플리케이션 설계 부담을 늘립니다. 새로 설계하는 서비스는 이점이 크고, 기존 PostgreSQL 기능에 기대는 서비스는 이관 비용이 큽니다.
한계: 작업 시간을 측정하지 않았고, 사람이 실제로 쓴 시간과 학습 비용을 금액으로 비교하지 않았습니다. 대조군 쪽 반복 운영 작업(패치, 인스턴스 교체, 스토리지 증설)은 실행하지 않았습니다. 관측은 이번 연구에서 겪은 사례이며 모든 워크로드에 일반화되지 않습니다.

정리 기록

이 보고서는 새 AWS 자원을 만들지 않았습니다. 인용한 측정 실행 세 개는 각 보고서에서 잔여 리소스 0을 확인했습니다(2026-09-28 12:07:44, 2026-09-29 11:10:30, 10:20:27 UTC).