계정 ID가 바뀌면 주소(ARN)가 바뀐다

리소스 ID만 유지하면 다른 계정에서도 대시보드가 그대로 작동할 것이라고 믿는다. 하지만 아마존 퀵(Amazon Quick, AI 기반 BI 서비스) 환경에서는 리소스 ID보다 주소인 ARN이 우선한다. 아마존 퀵의 리소스 식별자(ARN)는 `arn:aws:quicksight:region:account-id:resource-type/resource-id` 구조를 가진다. 여기서 서비스 식별자로 'quicksight'를 명시한다. 이는 기존 IAM(Identity and Access Management) 정책과 CLI 명령의 호환성을 유지하기 위한 선택이다. 사용자는 기존의 자동화 스크립트를 수정하지 않고도 아마존 퀵 리소스를 제어할 수 있다.

ARN의 핵심은 계정 ID가 주소의 일부라는 점이다. 개발 계정에서 운영 계정으로 대시보드를 옮기면 리소스 ID가 동일해도 전체 ARN은 완전히 바뀐다. 도시를 옮기면 집 번호가 같아도 주소가 바뀌는 것과 같다. AWS 생태계는 바뀐 ARN을 기준으로 리소스를 식별한다. 이전 계정의 주소는 새로운 계정에서 더 이상 유효하지 않다.

권한은 리소스 ARN과 주체(Principal) ARN 사이의 관계형 데이터로 저장된다. 개발 계정에서 특정 팀에 부여한 권한은 '계정 A의 주체'가 '계정 A의 리소스'에 접근한다는 연결 고리다. 계정을 이동하면 리소스의 ARN이 변경된다. 주체 ARN 역시 새로운 계정 ID를 포함하게 된다. 결과적으로 기존의 권한 연결 고리는 끊어지며, 운영 환경 접속 시 'Access Denied' 오류가 발생한다.

이 단절을 해결하기 위해 `StartAssetBundleImportJob` API를 사용한다. 특히 `OverrideParameters` 설정이 중요하다. 이 기능을 통해 임포트 과정에서 데이터 소스 연결 파라미터를 변경하거나 권한 설정을 강제로 덮어쓸 수 있다. 리소스가 생성된 후 권한을 따로 부여하는 시간차를 없애 보안 공백을 제거하는 방식이다.

마이그레이션의 성패는 의존성 관리와 권한 일괄 설정에 달렸다. 모든 의존성 리소스를 포함해 내보내고, 임포트 단계에서 대상 계정의 주체 ARN에 맞게 권한을 재설정하는 워크플로우가 필요하다. 이를 통해 계정 이동 시 발생하는 권한 설정의 반복 작업을 자동화할 수 있다.

에셋 번들 API를 통한 ARN 자동 변환

"분명히 다 옮겼는데 연결이 끊겨 있다." 개발 환경의 대시보드를 운영 환경으로 이동하면 ARN(Amazon Resource Name)이 바뀐다. 계정 ID가 ARN의 핵심 구성 요소이기 때문이다. 아마존 퀵(Amazon Quick)은 이 반복적인 수정 작업을 없애기 위해 `StartAssetBundleExportJob` API를 제공한다. 이 API는 대시보드와 그에 연결된 모든 의존성 리소스를 하나의 패키지로 묶어 내보낸다. `IncludeAllDependencies=True` 옵션을 설정하면 API가 리소스 간의 연결 관계를 추적한다. 대시보드에서 시작해 연결된 데이터셋, 그리고 그 데이터셋이 참조하는 데이터 소스까지 전체 의존성 트리를 한 번에 캡처한다. 관리자가 리소스 ID를 일일이 대조하며 리스트를 만들던 수동 작업이 사라진다.

실제 ARN 변환은 `StartAssetBundleImportJob` API가 대상 계정에서 실행되는 시점에 수행된다. API는 번들 내부에 저장된 리소스 참조 값을 읽어 들인다. 이후 이를 대상 계정의 ID로 치환하여 새로운 ARN을 생성하고 리소스를 배치한다. 대시보드가 참조하는 데이터셋의 주소가 새 계정의 주소로 즉시 업데이트되는 구조다. 리소스 간의 연결 고리를 API가 내부적으로 수정하므로 사용자는 변환 과정을 인지할 필요가 없다. 수동 작업에서 흔히 발생하는 오타나 참조 누락 가능성을 원천적으로 차단한다.

다만 번들에 포함되지 않은 외부 리소스를 참조할 때는 제약이 생긴다. 대시보드만 내보내고 데이터셋을 제외하면 API는 변환할 대상 ARN을 찾지 못한다. 결과적으로 운영 계정에 생성된 대시보드는 여전히 소스 계정의 ARN을 호출한다. 대상 계정의 권한으로는 다른 계정의 리소스에 접근할 수 없으므로 리소스를 찾지 못하는 오류가 발생한다. 모든 의존성을 포함해 내보내는 워크플로우가 마이그레이션의 성패를 결정한다. 상세한 ARN 구성 방식은 Amazon Quick Sight Resource ARNs 문서에 명시되어 있다.

자동 변환 기능은 편리하지만 운영 환경의 기존 자원을 활용해야 하는 상황에서는 충돌이 일어난다. 운영 계정에 이미 최적화된 데이터 소스가 설정되어 있다면 동일한 리소스를 중복 생성할 필요가 없다. 이때 `StartAssetBundleImportJob` API의 `OverrideParameters` 기능을 활용한다. 임포트 과정에서 데이터 소스의 연결 파라미터나 자격 증명, 리소스 ID 동작을 강제로 변경한다. API가 자동으로 생성하려는 새 ARN 대신 이미 존재하는 운영 리소스의 ARN을 매핑하도록 지시한다. 이를 통해 인프라 중복 없이 기존 환경에 대시보드를 즉시 안착시킬 수 있다.

기존 방식과 달라진 지점

관리자가 가장 먼저 마주하는 혼란은 리소스와 사용자의 소속 기준이 서로 다르다는 점이다. 아마존 퀵의 에셋 ARN에는 네임스페이스 구성 요소가 포함되지 않는다. 대시보드나 데이터셋 같은 리소스는 계정 내에서 유일한 식별자로 정의되며 계정 전체에서 공유된다. 에셋 ARN은 네임스페이스라는 계층을 거치지 않고 계정 ID에서 리소스 타입으로 바로 연결된다. 반면 사용자와 그룹 같은 주체는 네임스페이스 수준에서 엄격하게 격리된다. 리소스의 정체성은 계정이 결정하고 사용자의 정체성은 네임스페이스가 결정한다. 이는 자원 관리의 중앙집중화와 사용자 관리의 분산화를 동시에 꾀한 설계다.

주체 ARN의 상세 구조를 보면 네임스페이스가 경로의 핵심 요소로 작동한다. arn:aws:quicksight:region:account-id:principal/namespace/user형태로 구성된다. 동일한 사용자 이름인 nikki_wolf가 HR 네임스페이스와 Marketing 네임스페이스에 각각 생성된 상황을 가정한다. HR 네임스페이스의 nikki_wolf와 Marketing 네임스페이스의 nikki_wolf는 서로 다른 ARN을 가진 완전히 다른 주체다. 네임스페이스가 ARN 내에 포함되어 있어 식별자 자체가 완전히 달라지기 때문이다. 사용자 이름이라는 표면적 정보보다 네임스페이스라는 소속 정보가 우선하는 설계다. 관리자는 권한 설정 시 단순한 사용자 이름이 아니라 반드시 네임스페이스가 포함된 전체 ARN을 입력해야 오류를 막을 수 있다.

이러한 분리 구조는 단일 리소스를 여러 조직에 효율적으로 배포하는 기반이 된다. 하나의 대시보드 ARN에 서로 다른 네임스페이스 소속 주체들을 동시에 등록해 권한을 부여할 수 있다. 예를 들어 전사 공지용 대시보드 하나를 만들어 HR, Marketing, Sales 네임스페이스 사용자 모두에게 권한을 주는 방식이 가능하다. 대시보드 자체는 특정 네임스페이스에 귀속되지 않고 계정 수준에서 독립적으로 존재한다. 관리자는 각 네임스페이스의 전체 주체 ARN을 개별적으로 지정해 접근 제어를 수행한다. 특정 네임스페이스의 사용자에게 권한을 줘도 다른 네임스페이스의 동일 이름 사용자는 접근할 수 없다. 네임스페이스는 에셋의 위치를 정하는 것이 아니라 주체의 정체성을 결정하는 기준이다. 멀티테넌시 환경에서 데이터 격리와 자원 공유의 충돌을 ARN 수준에서 해결한 결과다.

OverrideParameters로 제어하는 배포 효율

설정 하나 바꾸려고 콘솔을 몇 번이나 오갔는지 모른다. StartAssetBundleImportJob API의 OverrideParameters는 임포트 과정에서 데이터 소스 연결 파라미터와 자격 증명을 직접 변경한다. 리소스 ID 동작 방식도 이 단계에서 제어한다. 개발 환경에서 정의한 연결 정보를 운영 환경의 엔드포인트와 인증 정보로 즉시 교체한다. 관리자가 임포트 후 콘솔에 접속해 데이터 소스 설정을 일일이 수정하던 반복 작업이 사라진다. 배포 파이프라인 내에서 연결 정보 최적화가 완결된다.

리소스는 생겼는데 아무도 못 들어가는 공백 시간이 늘 골칫거리였다. OverridePermissions 기능을 사용하면 리소스 임포트와 동시에 권한 설정이 수행된다. 리소스가 생성된 직후부터 권한이 부여된 상태로 배포된다. 리소스 생성과 권한 부여 사이의 시간적 간극에서 발생하는 보안 공백을 제거한다. 관리자가 사용자 목록을 대조하며 권한을 매핑하는 수동 단계를 생략한다. 배포 즉시 정의된 사용자 그룹이 대시보드에 접근할 수 있는 가용성을 확보한다.

사용자가 늘어날 때마다 권한을 추가하는 일은 단순 반복 노동에 가깝다. 아마존 퀵은 와일드카드 주체 ARN을 지원하여 이 문제를 해결한다. `arn:aws:quicksight:region:account-id:principal/namespace/*` 형태의 ARN을 권한 설정에 사용한다. 특정 네임스페이스에 속한 현재 사용자는 물론 향후 추가될 모든 사용자에게 일괄적으로 권한을 부여한다. 개별 사용자 ARN을 추적해 리스트를 업데이트할 필요가 없다. 권한 관리의 단위를 개별 계정에서 조직 네임스페이스 단위로 격상시킨다.

운영 환경에 이미 구축된 데이터 소스를 중복으로 생성하는 실수는 흔하다. OverrideParameters를 활용하면 임포트되는 에셋을 기존 QA나 운영 환경에 이미 구성된 데이터 소스에 그대로 매핑한다. 번들에 포함된 데이터 소스를 새로 만드는 대신 기존 리소스 ID를 참조하도록 경로를 변경한다. 불필요한 리소스 증식을 막고 기존의 검증된 연결 설정을 그대로 유지한다. 마이그레이션 워크플로우가 단순한 리소스 복제가 아니라 환경 맞춤형 연결 설정 과정으로 전환된다. 인프라의 파편화를 막고 관리 지점을 단일화하는 실무적 장치다.

한국 SaaS 기업의 멀티테넌트 BI 구현 전략

과거의 멀티테넌트 구현은 고객사마다 AWS 계정을 분리하거나 애플리케이션 단에서 복잡한 필터링 로직을 짜야 했다. 아마존 퀵(Amazon Quick)의 네임스페이스 체계는 단일 계정 내에서 사용자나 그룹을 논리적으로 격리한다. 고객사별로 네임스페이스를 할당하면 동일한 사용자 이름이 존재해도 서로 다른 주체(Principal)로 인식한다. 운영 효율과 데이터 격리라는 상충하는 목표를 단일 계정 구조로 해결한 사례다.

에셋(Asset)은 네임스페이스에 종속되지 않고 계정 수준에서 생성된다. 공통 공지사항이나 표준 분석 템플릿 같은 대시보드는 단 하나만 생성하면 된다. 이를 각 고객사 네임스페이스에 속한 주체들에게 개별적으로 공유한다. 하나의 리소스로 다수 테넌트를 관리하는 중앙 집중형 배포 구조가 가능해진다.

개발 환경에서 만든 대시보드를 운영 환경으로 옮겼을 때 발생하는 Access Denied 오류는 ARN의 계정 ID 변경 때문이다. 이를 해결하기 위해 `StartAssetBundleExportJob` API에서 `IncludeAllDependencies=True` 설정을 사용해 데이터셋과 데이터 소스를 포함한 전체 의존성 트리를 패키징한다. `StartAssetBundleImportJob` API의 `OverrideParameters`를 통해 운영 환경에 이미 존재하는 데이터 소스로 연결을 덮어쓴다. `OverridePermissions`를 함께 사용하면 임포트와 동시에 권한 설정이 완료되어 리소스가 권한 없이 방치되는 시간을 없앤다.

신규 고객사 확장 시 발생하는 권한 설정 부하는 와일드카드(Wildcard) ARN으로 해결한다. 네임스페이스 경로 끝에 와일드카드를 부여하면 해당 네임스페이스 내의 모든 현재 및 미래 사용자가 즉시 접근권을 갖는다. 관리자가 사용자를 추가할 때마다 개별 권한을 부여하는 수동 작업을 제거한다. 마이그레이션 시 모든 의존성을 포함해 내보내고 임포트 단계에서 권한을 일괄 설정하는 워크플로우를 구축하면 SaaS 운영 비용을 낮출 수 있다.

개발 환경의 대시보드를 운영 환경으로 옮길 때 발생하는 Access Denied 오류는 ARN에 포함된 계정 ID가 변경되기 때문에 일어난다. StartAssetBundleImportJob API의 OverrideParameters 기능을 활용하면 데이터 소스 연결과 권한 설정을 임포트 단계에서 즉시 덮어쓸 수 있다. 모든 의존성을 포함해 내보내고 임포트 시점에 권한을 일괄 설정하는 워크플로우를 구축하는 것이 마이그레이션의 핵심이다. BI 운영의 효율은 이제 관리자의 수동 설정 숙련도가 아니라 API 기반 배포 자동화의 정교함에서 결정된다.