별도 관리하던 비즈니스 정의를 데이터셋 하나로 통합

데이터셋에서 컬럼 이름을 하나 바꿨는데 연결된 토픽이 조용히 깨져 대시보드 수치를 처음부터 다시 확인해야 했던 경험이 있을 것이다. 아마존 퀵사이트(Amazon QuickSight)는 이러한 동기화 문제를 해결하기 위해 비즈니스 맥락을 데이터셋 자체에 내장하는 데이터셋 강화(Dataset Enrichment) 기능을 도입했다. 이제 실무자는 데이터셋과 토픽이라는 두 개의 자산을 각각 관리하며 발생하던 정렬 오류에서 벗어날 수 있다.

기존의 레거시 토픽(Legacy Topics)은 데이터셋 위에 별도로 존재하는 객체로 관리되었다. 데이터셋과 토픽이 분리되어 있었기에 권한, 리니지, 버전 관리를 각각 따로 수행해야 하는 번거로움이 있었다. 특히 데이터셋의 이름을 변경하면 레거시 토픽이 조용히 깨지는 현상이 발생해 운영 리스크가 컸다. 컬럼 동의어가 어긋나거나 계산된 필드가 서로 달라지는 등의 불일치 문제가 빈번하게 나타났다.

데이터셋 강화는 컬럼 설명, 동의어, 계산된 필드, 커스텀 지침, 비즈니스 규칙을 데이터셋에 직접 내장한다. 권한과 리니지, AI 컨텍스트가 데이터와 함께 이동하며 이를 기반으로 구축된 상위 객체에 자동으로 상속되는 구조다. 관리 포인트가 하나로 합쳐지면서 단일 진실 공급원을 통한 거버넌스 체계를 구축할 수 있다. 비즈니스 정의가 데이터셋에 귀속되므로 데이터가 이동해도 맥락이 유지된다.

기술적으로는 데이터셋의 `SemanticModelConfiguration` 내에 컬럼 수준의 TableMap과 데이터셋 수준의 SemanticMetadata를 정의하는 구조를 가진다. 실무자는 보유한 데이터셋이 새 데이터 준비(new data prep) 경험으로 생성되었는지 먼저 확인해야 한다. 이 조건이 충족되어야 데이터셋을 재생성하지 않고 API만으로 기존 메타데이터를 마이그레이션할 수 있기 때문이다. 데이터셋 생성 방식에 따라 마이그레이션 경로가 완전히 달라지므로 사전 확인이 필수적이다.

SemanticModelConfiguration의 구조와 4단계 이전 프로세스

실무자 한 명이 수십 개의 컬럼 설명을 일일이 복사해 붙여넣는 단순 반복 작업에 꼬박 이틀을 소비하는 일이 빈번했다. 아마존 퀵사이트(Amazon QuickSight)는 이를 해결하기 위해 새 데이터 준비 경험에서 `semantic_model_configuration`이라는 데이터셋 시맨틱 모델 설정을 도입했다. 이 구조는 두 개의 계층으로 나뉜다. TableMap이라는 컬럼 레벨 메타데이터 계층에서는 개별 컬럼의 이름 변경이나 타입 정의 같은 세부 속성을 다룬다. 그 위 단계인 SemanticMetadata라는 데이터셋 레벨 메타데이터 계층에서는 데이터셋 전체를 관통하는 비즈니스 용어 사전이나 전역 규칙을 정의한다.

레거시 토픽의 메타데이터를 이식하는 과정은 총 4단계로 진행된다. 먼저 강화 대상이 될 데이터셋을 식별하고, 소스가 되는 레거시 토픽의 위치를 확인한다. 이후 파이썬 스크립트를 실행해 데이터를 옮기고 마지막으로 결과가 정확히 반영되었는지 검증한다. 이때 사용자는 퀵사이트 콘솔 URL의 끝부분에서 데이터셋 ID와 토픽 ID라는 고유 식별자를 추출해 스크립트에 입력해야 한다. 데이터셋 ID는 데이터셋 탭에서 자산을 선택했을 때 나타나는 UUID 형태의 문자열이며, 토픽 ID는 토픽 탭의 URL 끝단에서 확인 가능하다.

실제 마이그레이션을 수행하는 `enrich_dataset.py` 스크립트는 레거시 토픽에서 추출한 정보를 데이터셋의 시맨틱 모델 설정으로 매핑한다. 스크립트는 단순한 복사가 아니라 지능적인 변환 과정을 거친다. 레거시 토픽의 컬럼 설명과 동의어는 ColumnProperties라는 새로운 규격으로 변환되어 저장된다. 기존에 정의된 계산된 필드들은 데이터 준비 파이프라인 내의 CreateColumnsStep 항목으로 자동 삽입되어 데이터 처리 흐름에 직접 통합된다. 명명된 엔티티나 필터, 커스텀 지침들은 하나의 구조화된 CustomInstructions 텍스트 블록으로 묶여 AI가 참조하기 좋은 형태로 재구성된다.

이 자동화 스크립트를 적용하기 전에는 반드시 데이터셋의 생성 환경을 확인해야 한다. 데이터셋이 `DataPrepConfiguration`이라는 신규 데이터 준비 설정을 보유했을 때만 `update-data-set` API를 통한 직접 마이그레이션이 가능하다. 만약 기존의 클래식 경험으로 생성되어 `LogicalTableMap`이라는 구형 구조를 사용하는 데이터셋이라면 API를 통한 인플레이스 업그레이드가 불가능하다. 실무자는 현재 데이터셋이 어떤 설정을 사용하는지 먼저 살펴보고, 구형 구조라면 데이터셋을 새 환경에서 재생성한 뒤 마이그레이션을 진행할지 결정해야 한다.

내 데이터셋 상태에 따른 3가지 마이그레이션 시나리오

어떤 실무자는 API 호출 한 번으로 마이그레이션을 끝내지만, 다른 실무자는 데이터셋 전체를 처음부터 다시 만들어야 한다. 이 차이는 데이터셋을 처음 생성할 때 어떤 경험을 사용했느냐에 따라 갈린다. 클래식 경험으로 생성하고 별도의 시맨틱 레이어를 구축하지 않은 데이터셋이 첫 번째 사례다. 이 경우 대시보드나 필터에는 `TXN_DT`나 `CUST_ID` 같은 원시 컬럼명이 그대로 노출된다. 사용자가 챗봇에 매출액을 묻는 자연어 질문을 던져도 시스템은 매출이라는 단어를 어떤 컬럼과 연결할지 알 수 없어 아무런 결과도 내놓지 못한다. 이러한 상태의 데이터셋은 인플레이스 업그레이드가 불가능하며 원시 컬럼명으로만 쿼리할 수 있다.

클래식 경험으로 생성했지만 레거시 토픽을 통해 시맨틱 레이어를 운영 중인 경우는 더 까다롭다. 이 데이터셋들은 내부적으로 `LogicalTableMap`이라는 구형 테이블 매핑 구조를 사용한다. 문제는 이 구조가 새로운 시맨틱 모델 설정인 `SemanticModelConfiguration`을 지원하지 않는다는 점이다. 두 구조를 자동으로 변환해주는 마이그레이션 API도 존재하지 않는다. 따라서 기존 레거시 토픽의 메타데이터를 보존하려면 새 데이터 준비 경험을 통해 데이터셋을 완전히 재생성해야 한다. 재생성 후 메타데이터를 이전하는 과정을 거쳐야만 데이터셋 강화 기능을 사용할 수 있다.

반면 새 데이터 준비 경험으로 데이터셋을 생성하고 그 위에 레거시 토픽을 얹어 사용 중이라면 상황이 완전히 다르다. 이 데이터셋은 이미 `DataPrepConfiguration`이라는 최신 데이터 준비 설정 구조를 보유하고 있다. 이는 데이터셋 자체가 강화 기능을 수용할 수 있는 API 언어를 이미 구사하고 있다는 뜻이다. 따라서 데이터셋을 새로 만들 필요 없이 `update-data-set` API를 통해 시맨틱 모델 설정을 직접 주입할 수 있다. 세 가지 시나리오 중 유일하게 데이터셋 재생성 없이 즉시 마이그레이션이 가능한 경로다. 보유한 데이터셋의 설정 구조가 구형 매핑 방식인지 최신 준비 설정 방식인지 확인하는 것이 작업 시간을 결정하는 핵심 판단 기준이 된다.

단일 진실 공급원(Single Source of Truth)이 주는 실무적 이득

비즈니스 로직이 바뀔 때마다 왜 데이터셋과 토픽 두 곳의 컬럼 설명을 각각 수정하며 시간을 낭비해야 했을까. 아마존 퀵사이트(Amazon QuickSight)는 권한, 시맨틱, AI 컨텍스트를 데이터셋 자체에 내장하는 데이터셋 강화 기능을 도입했다. 이제 관리 포인트는 하나의 자산, 하나의 진실 공급원, 하나의 거버넌스 지점으로 단일화된다. 데이터셋에 내장된 비즈니스 맥락은 데이터와 함께 이동하며, 이를 기반으로 생성된 모든 상위 객체에 자동으로 상속된다. 데이터셋 이름 변경 시 연결된 토픽이 조용히 깨지던 과거의 동기화 문제를 해결하고 거버넌스 운영 비용을 낮춘 구조다.

토픽(Topic)의 역할은 개별 데이터셋의 정의 도구에서 다중 데이터셋 시맨틱 및 추론 레이어로 격상되었다. 여러 개의 데이터셋을 하나로 조합하고, 데이터 간의 관계를 정의하며, 공통의 비즈니스 지표를 작성하는 상위 계층으로 재정의된 것이다. 데이터셋 고유의 시맨틱 정보는 데이터셋 계층으로 내려보내고, 토픽은 데이터셋 간의 관계와 비즈니스 용어 매핑이라는 본연의 역할에 집중한다. 이는 단순한 기능 이동이 아니라 데이터의 성격에 따라 관리 계층을 명확히 분리하여 AI 기반 분석의 정확도를 높이는 아키텍처로의 전환이다.

이렇게 강화된 데이터셋들은 이제 하나의 대화에서 여러 데이터를 동시에 쿼리할 수 있는 교차 데이터셋 Q&A의 핵심 기반이 된다. 각 데이터셋이 스스로 시맨틱 컨텍스트를 보유하고 있어야만, 상위 토픽 레이어에서 이를 통합해 복합적인 질문에 답할 수 있기 때문이다. 결과적으로 정해진 규칙대로 작동하는 결정론적 BI 워크플로와 자연어 기반의 유연한 AI 분석을 동시에 지원하는 공유 시맨틱 기반이 마련되었다. 실무자는 동일한 비즈니스 규칙을 공유하는 환경에서 정교한 대시보드 수치와 AI의 분석 답변이 서로 일치하는 경험을 하게 된다.

한국 AI 실무자를 위한 도입 판단 기준

모든 데이터셋을 최신 버전으로 재생성하려는 팀과 API 호환성을 먼저 따져본 팀의 리소스 소모량은 완전히 다르다. 현재 보유한 데이터셋이 `LogicalTableMap`을 사용하는지 아니면 `DataPrepConfiguration`을 사용하는지부터 확인해야 한다. 클래식 퀵사이트 경험으로 구축된 레거시 데이터셋은 `LogicalTableMap`을 사용하며 이는 데이터셋 강화 기능을 지원하지 않는다. 현재로서는 인플레이스 업그레이드 경로가 없으며 `SemanticModelConfiguration`을 추가하거나 이를 변환하는 마이그레이션 API도 존재하지 않는다. 결국 데이터셋을 새 데이터 준비 경험으로 다시 생성해야만 강화 기능을 적용할 수 있다.

`SourceTableMap`, `TransformStepMap`, `DestinationTableMap`을 포함한 `DataPrepConfiguration`을 이미 보유한 상태에서 레거시 토픽만 얹어 사용 중이라면 시나리오 3에 해당한다. 이 조건에서는 데이터셋을 재생성할 필요 없이 `update-data-set` API를 통해 메타데이터를 직접 주입할 수 있다. 수동으로 UI에서 수십 개의 컬럼 설명을 일일이 입력하는 반복 작업 없이 파이썬 스크립트로 자동 마이그레이션이 가능하다. 데이터셋이 이미 최신 API 언어를 지원하는 상태이므로 리소스를 최소화하며 기능을 확장할 수 있다. API 기반 자동화 가능 여부가 전체 마이그레이션 공수를 결정하는 핵심 변수가 된다.

단순한 대시보드 수치 조회보다 자연어 쿼리(Q&A) 기능을 통한 데이터 탐색 비중이 높은 환경이라면 데이터셋 강화 도입은 필수적이다. 원시 컬럼명만 노출된 상태에서는 사용자가 매출과 같은 비즈니스 용어로 질문해도 시스템이 어떤 컬럼을 참조해야 할지 판단할 근거가 없는 제로 컨텍스트 상태가 된다. 예를 들어 이번 분기 매출이 얼마인지 묻는 질문에 대해 매출이라는 단어를 특정 컬럼에 매핑하는 규칙이 없다면 결과는 아무것도 반환되지 않는다. 데이터셋 내부에 동의어와 비즈니스 규칙을 직접 내장해야 AI가 정확한 컨텍스트를 파악해 답변을 내놓는다.

실제 실행에 앞서 퀵사이트 콘솔 URL에서 네 가지 필수 정보를 정확히 확보해야 한다. 퀵사이트 콘솔의 데이터셋 탭에서 대상 데이터셋을 선택한 후 브라우저 주소창 끝에 있는 UUID 형태의 데이터셋 ID를 복사한다. 이어서 토픽 탭에서 소스가 될 레거시 토픽을 선택해 URL 끝에 있는 문자열 형태의 토픽 ID를 확보한다. 여기에 AWS 계정 ID와 사용 중인 리전 정보를 더해 스크립트 실행을 위한 입력값으로 준비한다. 이 정보들이 정확하게 일치해야 API 호출 시 권한 오류 없이 메타데이터가 데이터셋의 `SemanticModelConfiguration`에 정상적으로 기록된다.

컬럼 이름 하나를 바꿨을 때 대시보드 수치가 조용히 깨져 당황했던 경험은 비즈니스 맥락이 데이터셋과 분리되어 있었기 때문이다. 데이터셋 강화 기능은 이러한 파편화된 정의를 SemanticModelConfiguration이라는 단일 지점으로 통합해 관리 포인트를 획기적으로 줄인다.

이제 실무자가 할 일은 보유한 데이터셋이 새 데이터 준비 경험으로 생성되었는지 확인하는 것이다. 이 조건에 따라 API 마이그레이션으로 끝낼지 아니면 데이터셋을 재생성할지 결정하는 것이 리소스 낭비를 막는 가장 확실한 기준이 된다.