실수와 장애를 방어하는 Amazon QuickSight AAB API

BI 대시보드를 실수로 삭제하거나 데이터셋 설정을 잘못 변경해 과거 상태로 되돌리지 못하면 작업 손실과 비즈니스 의사결정의 공백이 발생한다. 이러한 위험을 시스템적으로 방어하기 위해 Amazon QuickSight는 `AssetsAsBundle` (AAB) API를 통해 BI 자산을 프로그램 방식으로 백업하고 복구하는 기능을 제공한다.

Amazon QuickSight는 자연어 쿼리와 인터랙티브 대시보드를 제공하는 AI 기반 BI 서비스다. 관리 대상인 핵심 자산은 대시보드, 분석(Analyses), 데이터셋, 데이터 소스로 나뉜다. AAB API는 이 자산들을 묶음 형태로 내보내고 가져올 수 있는 고수준 인터페이스다. 이를 활용해 전체 환경을 백업하거나 다른 계정으로 이전하는 워크플로를 구축할 수 있으며, CI/CD 파이프라인에 통합해 배포 자동화를 구현할 수 있다.

특히 금융 서비스, 헬스케어, 에너지와 같이 데이터 거버넌스 규제가 엄격한 산업군에서는 리전 전체 장애와 같은 서비스 중단 상황에서도 비즈니스 연속성을 유지하기 위해 백업 전략이 필수적이다. AAB API 기반의 백업은 우발적인 삭제를 방지하고, 의도치 않은 수정 발생 시 특정 시점으로 복구하는 롤백 체계를 구축하는 수단이 된다.

실무적으로 중요한 지점은 BI 자산의 의존성 구조다. 데이터 소스가 데이터셋을 만들고, 데이터셋이 분석을 거쳐 최종적으로 대시보드로 이어지는 체인을 형성하고 있다. AAB API는 이러한 의존 관계를 고려하여 자산을 번들링하므로, 복구 시 누락 없이 전체 환경을 재구성하여 즉시 작동하게 만든다.

이제 실무자는 조직의 재해 복구(DR) 요건에 따라 백업 범위를 결정해야 한다. 모든 자산을 백업해 버전 관리를 수행할 것인지, 핵심 대시보드와 의존 자산만 선택해 복구 시간을 단축할 것인지 판단해야 한다. 서비스 중단 시 허용 가능한 최대 복구 시간과 데이터 손실 가능 범위를 정의하는 것이 AAB API 도입의 첫 단계다.

SPICE 엔진과 리전 구조로 보는 QuickSight 작동 원리

QuickSight는 데이터 처리 속도를 높이기 위해 SPICE(Super-fast, Parallel, In-memory Calculation Engine)를 사용한다. SPICE는 외부 데이터를 암호화한 뒤 퀵사이트 리전 내 여러 가용 영역(AZ, Availability Zone)에 복제하여 저장한다. 데이터가 물리적으로 분리된 여러 영역에 분산 저장되므로 특정 가용 영역에 장애가 발생해도 서비스 중단 없이 데이터를 읽어올 수 있는 고가용성 구조를 갖는다.

계정 정체성 관리 영역은 자산 저장소와 별개로 작동한다. QuickSight는 사용자가 정의한 단일 리전에서 사용자 및 그룹 ID 정보를 관리하는 ID 관리 리전 체계를 가진다. 모든 사용자의 인증 정보와 그룹 권한 설정, 계정 수준의 메타데이터는 이 특정 리전에 저장된다. 분석 리포트나 대시보드 자산이 여러 리전에 분산되어 있더라도, 로그인과 권한 확인은 오직 이 ID 관리 리전을 통해서만 이루어진다. 따라서 인증 정보가 집중된 이 지점이 재해 복구 계획의 핵심 변수가 된다.

리전 간 의존성은 실제 접속 환경의 병목 지점이 된다. 예를 들어 대시보드 자산은 eu-west-1 리전에 있고 메인 ID 관리 리전이 us-east-1인 경우, 시스템은 먼저 us-east-1에서 신원을 확인한 후 eu-west-1에서 데이터를 불러온다. 두 리전이 모두 정상 작동해야 대시보드 화면이 출력된다. 어느 한쪽 리전에서 장애가 발생하면 자산 파일이 남아 있어도 접속이 불가능하다. 따라서 자산 백업뿐 아니라 ID 관리 리전의 가용 상태를 고려한 복구 시나리오가 필요하다.

현재 계정의 ID 관리 리전을 파악하는 것이 재해 복구 계획의 시작이다. AWS CLI를 통해 계정 설정을 조회하면 메인 리전 정보를 확인할 수 있다.

aws quicksight describe-account-settings --region us-east-1

위 명령어를 실행했을 때 200 상태 코드가 반환되면 ID 관리 리전이 us-east-1인 것이며, 에러가 발생하면 실제 설정된 다른 리전(예: eu-west-1)을 지정해 다시 조회해야 한다. 규제 산업군에서는 이 리전 의존성을 기반으로 RTO(Recovery Time Objective, 복구 목표 시간)를 산정하고, 어느 리전의 인증 체계부터 복구할지 결정하는 기준으로 삼는다.

핵심 자산 vs 전체 자산 백업 전략 비교

인프라 구조를 이해했다면, 이제 비즈니스 요구사항에 맞는 백업 범위를 설정해야 한다. 핵심 자산 선택 전략은 비즈니스 결정에 필수적인 특정 대시보드와 연결된 의존 자산만 골라 백업하는 방식이다. 재무, 물류, 구매 팀처럼 운영에 즉각적인 데이터가 필요한 조직이 주로 사용하며, 복구 범위가 좁아 관리 포인트가 적고 복구 속도가 빠르다는 이점이 있다.

반면 전체 자산 백업 전략은 인스턴스 내의 모든 자원을 통째로 저장한다. 이 방식은 체계적인 버전 관리와 전체 재해 복구(DR) 목적으로 활용된다. 특히 작업자의 실수로 데이터가 잘못 수정되었을 때 해당 자산을 이전 상태로 되돌리는 인플레이스 롤백(In-place rollback)을 구현할 수 있으며, 특정 자산만 선택해 복구하는 유연성도 제공한다.

전체 백업은 커버리지가 넓지만 운영 비용이 발생한다. 모든 자산을 일관성 있게 백업하고 복구하려면 자산 간의 순서를 맞추고 상태를 확인하는 정교한 오케스트레이션(Orchestration) 워크플로 설계가 필요하기 때문이다. 최대의 안전성을 얻는 대신 시스템 관리자의 구현 공수가 늘어나는 트레이드오프가 존재한다.

최종적인 전략 선택은 산업군이 요구하는 재해 복구 요건과 서비스 중단 허용 시간에 따라 결정한다. 데이터 손실이 치명적인 금융이나 의료 환경이라면 전체 백업을 통한 완전한 복구 체계를 갖추는 것이 적합하며, 운영 효율성과 빠른 복구 속도가 우선인 환경이라면 핵심 자산 중심의 전략이 실용적인 대안이 된다.

AAB API 구현 시 주의해야 할 제약 사항과 권한

AAB API를 사용해 자산을 백업하고 복구하는 구체적인 과정은 `StartAssetBundleExportJob`으로 내보내기를 시작하고 `DescribeAssetBundleExportJob`으로 상태를 확인하는 순서로 이뤄진다. 복구 시에는 `StartAssetBundleImportJob`을 호출해 자산을 가져오고 `DescribeAssetBundleImportJob`으로 완료 여부를 체크한다.

다만 모든 데이터 소스가 백업 대상은 아니다. Adobe Analytics, File, GitHub, Jira, Salesforce, ServiceNow, Twitter 및 로컬 매니페스트 파일을 사용하는 Amazon S3 데이터 소스는 제외된다. 이들이 포함된 상태로 내보내기를 요청하면 `InvalidParameterValueException` 에러가 발생하며 작업이 중단된다. 따라서 API 호출 전 사용 중인 데이터 소스 목록의 호환 여부를 전수 조사해야 자동화 파이프라인의 중단 리스크를 막을 수 있다.

데이터셋 수준의 제약도 존재한다. SageMaker ML 모델 추론을 통해 생성된 ML 컬럼이 포함된 데이터셋은 AAB API로 백업할 수 없다. ML 기반 예측 지표가 포함된 대시보드를 운영 중이라면 해당 데이터셋은 데이터 생성 로직 자체를 코드로 관리하는 별도의 전략을 세워야 한다.

자산과 더불어 접근 권한 설정도 중요하다. `IncludePermissions` 플래그를 true로 설정하면 자산을 내보낼 때 사용자 및 그룹의 접근 권한 정보를 함께 묶을 수 있다. 이 설정을 누락하면 자산은 복구되지만 모든 사용자의 접근 권한을 관리자가 다시 지정해야 하므로 복구 시간이 늘어난다. 특히 엄격한 접근 제어가 필요한 규제 산업에서는 이 플래그 설정이 RTO를 단축하는 결정적 기준이 된다.

한국 기업의 BI 운영을 위한 실무 적용 가이드

AssetsAsBundle(AAB) API는 분석 자산은 처리하지만 실제 사용자와 그룹 정보는 다루지 않는다. 따라서 실무자는 `DescribeUser`와 `DescribeGroup` API를 조합하고 `DescribeGroupMembership` API를 사용해 사용자-그룹 매핑 정보를 별도로 기록해 백업해야 한다. 여기에 `DescribeAccountCustomization` API를 사용해 계정 커스터마이징 설정까지 저장해야 완전한 복구 환경이 만들어진다.

실무 워크플로에서는 이러한 과정을 CI/CD 파이프라인에 통합하여 운영한다. AAB API를 통해 BI 자산을 코드처럼 관리하면 릴리스 관리와 교차 계정 마이그레이션이 단순해진다. 개발 계정에서 분석물을 검증한 뒤 운영 계정으로 이전해야 하는 경우, AAB API로 번들을 생성해 타겟 계정에 임포트하는 자동화 경로를 구축한다. 특정 시점의 상태를 번들로 저장해 두면 문제 발생 시 즉시 이전 버전으로 롤백하는 버전 관리 체계를 도입할 수 있으며, 이는 수동 작업으로 인한 설정 누락이나 휴먼 에러를 방지한다.

최종적인 복구 자동화 수준은 RTO에 따라 결정한다. RTO가 매우 짧아야 하는 금융이나 의료 산업은 모든 백업 과정을 스크립트로 자동화하고 정기적인 복구 모의 훈련을 수행해야 한다. 이때 Amazon QuickSight 재해 복구 가이드와 내부 보안 정책을 대조하여 복구 가능 여부와 소요 시간을 객관적으로 판단한다. 서비스 중단 시 허용 가능한 최대 다운타임과 복구 비용 사이의 균형점이 백업 범위와 자동화 수준을 결정하는 최종 판단 기준이 된다.

BI 대시보드 삭제 후의 당혹감은 개인의 실수가 아니라 시스템적인 복구 체계의 부재에서 온다. AssetsAsBundle API를 활용한 자산 번들링은 BI 운영을 단순한 시각화 관리가 아닌, 인프라 수준의 재해 복구 영역으로 전환한다. 특히 금융이나 의료처럼 엄격한 DR 요건이 필요한 산업군일수록 복구 시간 목표에 맞춘 정교한 백업 범위 설정이 필수적이다. 지금 즉시 서비스 중단 시 허용 가능한 최대 다운타임을 정의하고, 그 기준에 따라 핵심 자산과 전체 자산 중 어떤 백업 전략을 택할지 결정하는 것으로 실무적인 방어선을 구축하면 된다.