Serve live, governed data in AI-built apps with Amazon Quick

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Amazon Quick의 Live Data in Apps는 AI가 만든 앱에서 Quick Sight 데이터셋을 조회자 권한으로 실시간 쿼리해, 개인별 동의와 RLS·CLS를 적용하면서 데이터셋의 최신 지표를 제공한다.

📌 핵심 요약

• 기존 Quick Apps는 커넥터·문서·웹 검색·AI 추론을 조회 시점에 실행했지만, Quick Sight 데이터셋의 수치는 앱 빌드 시점의 스냅샷으로 고정됐다. Live Data in Apps는 게시된 앱을 열 때마다 빌드 중 작성한 SQL을 다시 실행한다.
• 쿼리는 앱 조회자의 권한으로 실행되며 기존 행 수준 보안(RLS)과 열 수준 보안(CLS)이 적용된다. 빌더는 제작 중 데이터셋별로 승인하고, 조회자는 최초 사용 시 데이터셋별로 동의하며, 서버는 매 쿼리에서 동의를 검증한다.
• SPICE와 Direct Query 데이터셋을 지원한다. SPICE는 데이터셋을 새로 고쳐야 앱에 갱신된 데이터가 반영되고, Direct Query는 별도 새로 고침이 필요하지 않다.
• 빌더와 조회자의 최소 역할은 Reader Pro (Professional)이며, 조회자는 인증된 Quick 사용자여야 한다. 라이브 데이터셋을 사용하는 앱은 익명·공개 접근을 지원하지 않고, 기반 데이터셋 접근 권한이 없으면 오류가 발생한다.
• AnyCompany의 영업 갱신 사례에서는 SaaS Sales와 Customer Renewals 데이터셋으로 이번 분기와 향후 6개월의 갱신 정보를 조회하고, 고객별 매출·마진, 고객 이메일 발송, 제품 전략 문서를 활용한 AI 분석을 하나의 앱에 결합한다.

🧩 주요 포인트

1. 빌드 시 SQL 작성·검증 → 조회 시 같은 SQL 재실행: 자연어로 앱을 만들면서 지표 갱신을 데이터셋의 현재 상태와 연결한다.
2. 조회자별 실행 권한·동의와 RLS·CLS 적용 → 같은 앱을 공유해도 사용자별 데이터 범위가 달라지며, 앱 공유만으로 데이터셋 접근 권한이 생기지는 않는다.
3. Direct Query의 서로 다른 데이터 소스 혼용 금지, 결과 전송 크기와 빌더의 초기 행 조회 제한, 열 이름 변경·삭제 시 쿼리 재구축 필요 → 앱 구성과 데이터 조회 범위를 이러한 제약에 맞춰 설계해야 한다.

🧠 상세 정리

1. 기존 앱의 스냅샷 한계와 새 기능

기존 Quick Apps는 Jira·Slack·Google Drive 같은 액션 커넥터, Spaces 문서, 웹 검색, AI 추론을 앱 제작 시점이 아니라 조회 시점에 실행할 수 있었다. 그러나 업무 지표를 담은 Quick Sight의 SPICE와 Direct Query 데이터셋은 앱에서 실시간으로 쿼리할 수 없어, 표시되는 숫자가 에이전트의 빌드 시점에 고정됐다. 이런 방식은 정적인 보고서에는 적합했지만, 현재 데이터와 사용자별 행 접근 권한을 반영해야 하는 앱에는 한계가 있었다. 새로 소개된 Live Data in Apps는 데이터 레이크·데이터베이스 등 분석 저장소에서 비롯된 관리형 구조화 데이터를 앱에 연결한다. Amazon Quick은 기업 데이터와 콘텐츠를 연결하는 AI 기반 통합 인텔리전스 서비스이며, Quick Apps에서는 자연어 설명으로 AI 에이전트가 웹 앱을 작성하고 배포하므로 직접 코딩하거나 DevOps 작업을 수행할 필요가 없다고 설명한다.

2. 실시간 쿼리의 작동 방식과 사용자별 효과

Live Data in Apps를 사용하는 게시된 앱은 사용자가 열 때마다 관리형 Quick Sight 데이터셋을 쿼리한다. 원문은 지원팀이 지난주에 종료한 티켓 수를 지역별로 확인하려고 매주 쿼리를 작성하고 차트를 내보내 Slack에 붙여 넣는 상황을 예로 든다. 사용자가 원하는 앱을 자연어로 설명하면 에이전트가 관련 정제 데이터셋을 찾아 빌드 중 SQL을 작성·검증하고, 게시된 앱은 이후 같은 SQL을 다시 실행한다. 쿼리는 조회자 본인의 권한으로 실행되므로 각 사용자는 허용된 데이터만 보게 되며, 최신성은 해당 데이터셋의 현재 내용에 따른다. 업무 운영 담당자는 수동 갱신·스냅샷 관리·맞춤형 API 연결 부담을 줄일 수 있고, 일반 사용자는 자신의 권한에 맞는 수치를 확인하며, 관리자는 기존 RLS·CLS와 서버 측 동의 검증을 그대로 활용한다.

3. 데이터셋·역할·인증·동의의 전제 조건

앱을 만들기 전에 이미 생성된 데이터셋에 접근할 수 있어야 하며, 해당 데이터셋에는 행 수준 보안(RLS)과 열 수준 보안(CLS)이 설정돼 있을 수도, 없을 수도 있다. 지원 모드는 인메모리 방식인 SPICE와 Direct Query이며, Direct Query에서 지원하는 구체적인 데이터 소스는 문서에서 확인하도록 안내한다. 앱을 만드는 빌더와 게시된 앱을 여는 사용자 모두 최소 Reader Pro (Professional) 역할이 필요하다. 빌더는 제작 과정에서 사용할 데이터셋을 승인하고, 조회자는 최초 사용 시 각 데이터셋에 대한 동의를 제공해야 한다. 라이브 데이터셋을 사용하는 앱의 조회자는 인증된 Quick 사용자여야 하며 익명이나 공개 접근은 지원하지 않는다. 원문은 이러한 인증 제약이 여러 계층에서 강제되고, 데이터셋 사용 동의도 서버가 매 쿼리마다 검증한다고 설명한다.

4. AnyCompany의 고객 갱신 업무 사례

AnyCompany는 고객에게 여러 SaaS 애플리케이션을 제공하며, 지역 영업 책임자가 계약 갱신을 검토하고 후속 조치를 취하는 업무를 사례로 제시한다. 이 업무에는 기업의 제품 전략 콘텐츠와 매출 데이터를 함께 확인하는 과정뿐 아니라 고객에게 연락하는 흐름도 필요하다. 원문은 고객별로 올바른 데이터를 가져오는 기존 구현 작업에 통상 한 달의 노력이 들 수 있다고 설명한다. Live Data in Apps를 사용하면 영업 책임자가 이미 접근 가능한 데이터셋을 바탕으로 앱을 만들고, IT를 기다리지 않고 다른 영업 책임자에게 공유할 수 있다는 것이 사례의 주장이다. 앱과 데이터는 보안을 고려해 설계된 AWS 인프라에 위치하며 고객의 RLS·CLS를 적용한다. 이후 설명은 에이전트가 앱을 만드는 빌드 흐름과 다른 사용자가 게시된 앱을 여는 조회 흐름으로 나뉜다.

5. 자연어 요청에서 데이터셋 승인과 앱 제작까지

제작자는 Amazon Quick의 왼쪽 탐색 메뉴에서 Apps를 선택하고 프롬프트 입력란에 원하는 앱을 자연어로 설명한다. 예시 요청은 이번 분기와 향후 6개월의 고객 갱신 목록을 만들고, 고객을 선택하면 SaaS Sales 데이터에서 해당 고객의 매출과 마진을 보여 달라는 내용이다. 에이전트는 SaaS Sales와 Customer Renewals 데이터셋을 발견하고 SQL을 작성한 뒤, 각 데이터셋의 이름을 제시하며 사용 승인을 요청한다. 이 사례에서는 두 데이터셋이 발견됐으므로 각각 별도로 동의를 받아야 하며, 승인 후 앱을 제작하고 미리보기를 표시한다. 제작자는 기능을 단계적으로 추가하면서 결과를 검증할 수 있고, 예시 앱은 주요 필터가 있는 갱신 목록과 거래별 매출 표시를 갖춘다. 또한 거래를 선택한 뒤 고객에게 해당 거래에 관한 이메일을 보내는 업무 흐름까지 연결한다.

6. 제품 전략 기반 AI 분석과 게시·공유

영업 책임자는 거래에 대한 판단이 제품 전략과 맞는지 확인하기 위해 자연어 프롬프트로 기업의 제품 전략 문서를 앱에 추가한다. 예시에서는 데이터셋의 고객 정보와 제품 전략을 함께 활용해 거래를 진행할지, 추가 할인을 제공할지 등을 AI가 요약하도록 요청한다. 이 분석은 SaaS Sales의 매출 데이터와 기업 콘텐츠를 하나의 화면에 결합하며, 결과를 표시하는 팝업 크기도 프롬프트로 조정한다. 원문은 완성된 앱이 기업 콘텐츠·데이터·커넥터를 적절한 보안과 함께 연결한다고 설명하고, 오른쪽 위의 더보기 메뉴에서 Manage integrations를 선택하면 사용 중인 통합 목록을 확인할 수 있다고 안내한다. 제작자가 결과에 만족하면 Publish를 선택해 게시하고, Quick 사용자나 그룹에 조회 권한으로 공유한다. 공유 이후의 데이터 접근은 조회자별 권한과 최초 사용 동의를 전제로 작동한다.

7. 조회자 동의와 지역별 데이터 접근

조회자가 앱에 처음 접근하면 앱이 데이터셋을 사용할 수 있도록 동의하는 화면이 표시된다. 사용자는 같은 앱을 열더라도 자신의 RLS·CLS 규칙에 따라 필터링된 데이터를 보게 되며, 쿼리도 그 조회자의 권한으로 실행된다. 사례에서 AMER 지역 접근 권한만 가진 영업 관리자는 AMER 데이터만 확인하고, EMEA와 AMER 모두에 접근할 수 있는 관리자는 두 지역의 데이터를 확인한다. 따라서 화면이나 앱을 공유했다고 해서 모든 사용자가 동일한 데이터 범위를 보는 것은 아니며, 실제 표시 범위는 기반 데이터셋의 보안 규칙을 따른다. 원문은 기반 데이터셋에 접근 권한이 없는 사용자에게 오류가 표시되는 예시도 제시한다. 결론에서는 조회자별 동의 절차 뒤에서도 백엔드가 매 쿼리마다 다시 검증하며 RLS·CLS를 개인별로 적용한다고 강조한다.

8. 최신성·결과 크기·데이터 소스의 운영 제약

쿼리는 앱 조회 시 실행되지만, 앱이 보여 주는 최신 데이터의 범위는 데이터셋이 보유한 내용에 의해 결정된다. SPICE를 사용하는 경우 데이터셋을 새로 고쳐야 갱신된 내용이 앱에 반영되고, Direct Query에서는 별도의 데이터셋 새로 고침이 필요하지 않다. 쿼리와 결과 크기에는 보호 제한이 있어 결과가 전송 가능한 크기를 넘으면 잘리거나 불완전한 데이터를 제공하는 대신 쿼리 범위를 좁히라는 메시지를 표시한다. 이런 경우 프롬프트를 수정해 집계 데이터를 요청하거나 페이지 나누기를 구현하도록 요청할 수 있다. 단일 앱에서는 SPICE 데이터셋 또는 동일한 데이터 소스의 Direct Query 데이터셋을 사용할 수 있지만, 서로 다른 소스의 Direct Query 데이터셋을 함께 사용할 수는 없다. 또한 Spaces나 커넥터와 마찬가지로 Quick이 사용자를 대신해 특정 데이터셋을 앱에서 이용하도록 일회성 동의를 제공해야 한다.

9. 빌드 단계의 행 제한과 데이터셋 변경 대응

빌더의 제작 및 행 조회 과정에는 초기 데이터 검색 행 수 제한이 있으며, 원문은 정확한 수치를 제시하지 않고 관련 문서를 참조하도록 한다. 이 제한을 지키면서 앱 로드 시 여러 페이지로 나눈 호출을 통해 전체 데이터를 가져오도록 제작 에이전트에 요청해야 한다고 설명한다. 데이터셋 검색 중 에이전트가 필요한 열을 놓치면 프롬프트에서 해당 열을 직접 지정할 수 있고, 원하는 데이터셋을 발견하지 못하면 검색 범위를 좁히거나 이름 또는 ID를 제공할 수 있다. 앱은 처음 받은 데이터를 바탕으로 열을 이해하므로, 빌더의 RLS 적용 결과가 빈 데이터이면 그 데이터셋으로 앱을 만들 수 없어 앱 소유자나 보안팀과 행 접근 권한을 해결해야 한다. 열 이름을 변경하거나 열을 삭제한 경우에는 갱신된 정보를 바탕으로 앱을 편집하고 쿼리를 다시 구축해야 한다. 원문은 시작 방법으로 관리형 Quick Sight 데이터셋을 이용한 앱 제작, Amazon Quick 문서 확인, 제품 내 피드백이나 AWS 팀을 통한 의견 전달을 제시한다.

🧾 핵심 주장 / 시사점

• 자연어로 앱을 만드는 편의성과 조회 시 SQL을 재실행하는 구조가 결합되면서, Quick Sight 데이터셋을 반복적으로 활용하는 업무를 앱으로 연결할 수 있다.
• 데이터 접근 통제는 공유된 앱의 화면이 아니라 조회자의 권한과 기존 RLS·CLS에 의해 결정되며, 동의는 접근 권한을 대신하지 않는다.
• 실시간 쿼리가 원천 데이터의 무조건적인 최신성을 뜻하지는 않는다. SPICE에서는 데이터셋 새로 고침이 필요하고, 앱 구성에는 데이터 소스와 조회량 제약도 반영해야 한다.

✅ 액션 아이템

• Live Data in Apps 적용 시 SPICE의 데이터셋 새로 고침 필요성과 Direct Query의 별도 새로 고침 불필요 조건을 반영함.
• 앱 공유 대상의 Reader Pro (Professional) 역할, Quick 인증, 데이터셋 접근 권한과 최초 사용 동의 조건을 확인함.
• Direct Query의 서로 다른 데이터 소스 혼용 금지와 결과 전송 크기·초기 행 조회 제한을 검토하고, 열 이름 변경·삭제 시 쿼리 재구축을 반영함.

❓ 열린 질문

• 사용할 SPICE 데이터셋의 새로 고침 상태가 앱에서 필요한 지표의 최신성을 충족하는가?
• 앱을 공유받을 Quick 사용자 모두가 Reader Pro (Professional) 역할과 필요한 데이터셋 접근 권한을 갖추고 최초 사용 동의를 제공할 수 있는가?
• 필요한 Direct Query 데이터셋들이 동일한 데이터 소스에 있으며, 조회 범위가 결과 전송 크기와 초기 행 조회 제한에 맞게 구성돼 있는가?