분석 API
대부분의 분석 통합은 비슷한 방식으로 시작합니다. 제품 팀은 애플리케이션 내에 데이터가 필요합니다. 누군가가 iFrame을 통해 대시보드를 삽입합니다. 배송이 가능합니다. 대체로 효과가 있어요. 사용자는 제품을 떠나지 않고도 차트를 볼 수 있습니다.
그때 첫 번째 커스터마이징 요청이 들어옵니다. 고객은 대시보드가 자신의 브랜드와 정확히 일치하기를 원합니다. 또 다른 경우에는 사용자가 현재 애플리케이션 내에서 무엇을 하고 있는지에 반응하는 필터가 필요합니다. 누군가가 사용자가 보고서를 탐색하는 대신 자연어로 질문할 수 있는지 묻습니다. 엔지니어링 팀은 iFrame이 기초가 아니라 임시 해결책임을 깨닫기 시작했습니다.
분석 API는 제대로 구축된 임베디드 분석 경험 아래에 위치한 것입니다. 이것이 분석이 제품의 네이티브 일부처럼 작동하도록 가능하게 합니다 — 애플리케이션 맥락에 반응하고, 사용자 권한을 존중하며, AI 생성 인사이트를 제공하고, 수천 개의 테넌트에 걸쳐 유지보수 부담 없이 확장할 수 있게 합니다.
이 가이드는 분석 API가 무엇인지, 어떻게 작동하는지, 그리고 API를 기반으로 구축할 때 어떤 변화가 달라지는지 설명합니다.
분석 API란 무엇인가요?
분석 API는 애플리케이션이 분석 기능에 프로그래밍적으로 접근, 임베딩, 상호작용할 수 있도록 하는 엔드포인트와 프로토콜의 집합입니다. 외부 대시보드 도구로 사용자를 안내하는 대신, 애플리케이션은 API 호출을 통해 데이터를 검색하고, 시각화를 불러오며, 필터를 적용하고, 인사이트를 반환합니다 — 이 모든 것이 제품 인터페이스 내에서 이루어집니다.
분석 API는 분석이 사용자가 탐색하는 목적지가 아니라 애플리케이션이 호출하는 함수로 만듭니다.
제품 및 엔지니어링 팀에게 이러한 변화는 구체적인 영향을 미칩니다. API를 통해 실행되는 분석은 사용자 행동에 의해 트리거되고, 특정 맥락에 맞게 범위를 지정하며, 현재 사용자의 권한으로 필터링되고, AI 시스템과 연결할 수 있습니다 — 사용자가 제품을 계속 사용할 필요 없이 아무것도 하지 않아도 됩니다.
전통적인 임베디드 대시보드와의 대조는 외관이 아니라 건축적입니다. iFrame은 제품 내부에 외부 도구의 UI를 불러옵니다. 분석 API는 분석 기능을 애플리케이션 로직에 통합하여 인터페이스, 데이터 접근 모델, 동작을 당신이 통제할 수 있으며, 분석 벤더가 직접 제어하지 않습니다.
분석 API의 작동 원리
분석 API는 애플리케이션으로부터 요청을 받아 분석 엔진을 통해 처리한 후 구조화된 결과를 반환합니다. 요청은 "이 사용자에 대해 이 지표를 알려줘"처럼 간단할 수도 있고, "이 데이터셋에 대해 쿼리를 실행하고, 필터를 적용한 뒤 결과를 차트 컴포넌트로 반환하라"처럼 복잡할 수도 있습니다.
요청 흐름
기능적으로 모든 분석 API 상호작용은 동일한 패턴을 따릅니다:
- 애플리케이션이 요청을 보냅니다 — 쿼리, 대시보드 로드 명령어, 필터 매개변수, 또는 자연어 질문
- API는 요청을 처리하며 사용자 인증을 하고, 데이터 접근 규칙을 강제하며, 쿼리를 실행합니다
- 분석 엔진은 연결된 데이터베이스, 창고 또는 API에서 데이터를 가져옵니다
- 결과는 구조화된 데이터, 렌더링된 컴포넌트, 또는 AI가 생성한 인사이트로 애플리케이션에 반환됩니다
- 애플리케이션이 자체 UI 컴포넌트나 분석 SDK를 사용해 출력물을 렌더링합니다

정적 대시보드 임베드와 다른 점은 모든 단계가 애플리케이션의 컨텍스트에 의해 결정된다는 점입니다. 사용자의 신원, 역할, 테넌트, 현재 워크플로우 상태 — 이 모든 것이 API를 통해 전달되어 반환되는 내용을 형성합니다. 분석은 단순히 제품과 함께 제공되는 것이 아니라 제품에 반응하는 방식으로 발전합니다.
핵심 API 기능
- 데이터 쿼리 엔드포인트 — 지표와 차원을 기반으로 원시 또는 집계된 데이터를 검색합니다
- 대시보드 및 시각화 엔드포인트 — 애플리케이션 내에서 차트를 동적으로 로드하거나 생성
- 필터링과 드릴다운 — 사용자 맥락, 매개변수, 상호작용을 프로그래밍적으로 적용합니다
- 인증 및 접근 제어 — 데이터가 반환되기 전에 권한을 강제합니다
- 실시간 및 캐시 데이터 처리 — 실시간 쿼리 또는 성능을 위한 최적화된 응답 지원
- AI와 대화형 엔드포인트 — 자연어를 쿼리로 번역하고 구조화된 인사이트를 반환합니다
분석 API 대 전통적인 BI 도구
전통적인 BI 도구는 데이터 팀과 분석가가 대시보드와 보고서를 통해 데이터를 탐색할 수 있도록 설계되었습니다. 분석 API는이 모델을 애플리케이션 내에서 실행되는 모델로 전환합니다 — 제품 경험의 일부로서 요청, 처리, 전달되는 방식으로, 별도의 목적지가 아닌 방식입니다.
실질적인 격차는 제품 팀이 전통적인 BI가 설계되지 않은 일을 하려 할 때 나타납니다: 실시간 사용자 컨텍스트에 대응하거나, 쿼리 수준에서 테넌트 수준의 데이터 격리 강제, AI 시스템과의 통합, 또는 제품 팀 자체 엔지니어가 만든 것처럼 보이고 행동하는 경험을 만드는 것입니다.
| 전통적인 BI | 분석 API | 왜 중요한가 | |
|---|---|---|---|
| 접근 모델 | 외부 대시보드 | 내장 인앱 | 사용자들은 데이터를 찾기 위해 제품을 떠나지 않습니다 |
| 상호작용 | 수동 탐사 | 프로그램 접근 | 분석은 사용자뿐만 아니라 워크플로우에 의해 트리거될 수 있습니다 |
| UI 제어 | 고정된, 도구 정의 | 완전 커스터마이즈 가능 | 제품의 설계 시스템과 정확히 일치합니다 |
| 통합 | iFrame 또는 볼트온 | 네이티브 SDK + API | 커스터마이징이나 상호작용의 깊이에 한계가 없습니다 |
| 데이터 전달 | 사전 구축된 보고서 | 주문형 쿼리 | 현재 사용자 상황에 기반한 실시간 결과 |
| 자동화 | 제한 | API 기반 | 경고, 트리거, AI 기반 행동을 활성화합니다 |
그 표에서 가장 중요한 행은 마지막 행입니다. 전통적인 BI 도구는 AI 사용을 위해 설계된 것이 아니라 인간 분석가를 위해 설계되었습니다. 반면 분석 API는 프로그래밍 접근을 위해 구조화되어 있어 AI 시스템이 이를 쿼리하고, 결과를 해석하며, 분석 경험을 수행하는 동일한 계층을 통해 인사이트를 생성할 수 있습니다. 이것이 대화형 분석을 가능하게 하는 아키텍처입니다.
분석 API의 유형
분석 API는 단일 인터페이스가 아닙니다. 완전한 분석 계층은 데이터 검색부터 시각화, AI 상호작용에 이르기까지 경험의 특정 부분을 다루는 여러 API 유형을 포함합니다. 플랫폼을 평가하거나 자체 분석 아키텍처를 설계할 때 어떤 유형이 중요한지 이해하는 것이 중요합니다.

1. 데이터 쿼리 API
데이터 쿼리 API는 정의된 지표와 차원을 기반으로 원시 또는 집계된 데이터를 검색합니다. 그것이 기반이며, 다른 모든 분석 API 유형은 궁극적으로 필요한 정보를 얻기 위해 데이터 쿼리 API에 의존합니다.
- 데이터셋 전반에 걸친 백엔드 분석 로직과 맞춤형 쿼리를 강화합니다
- 집계, 그룹화, 필터, 정렬 등을 프로그래밍적으로 적용하세요
- 시각화나 AI 계층이 소비할 수 있는 구조화된 데이터를 반환합니다
언제 사용할지: 애플리케이션이 차트, 표, 대시보드, AI 생성 요약, 자동 보고 파이프라인 등 어떤 목적으로든 데이터를 검색해야 할 때.
2. 시각화 API
시각화 API는 애플리케이션 내에서 데이터가 어떻게 제시되는지 제어합니다. API 응답과 애플리케이션 구성을 바탕으로 차트, 대시보드, 시각적 구성 요소를 렌더링합니다.
- 데이터 쿼리 결과를 기반으로 차트와 대시보드를 동적으로 생성합니다
- 애플리케이션 코드를 통해 레이아웃, 서식, 디스플레이 로직을 제어합니다
- 데이터 출력을 설계 시스템 내 프론트엔드 컴포넌트에 연결하세요
언제 사용할지: 분석 렌더링 계층이 대시보드 템플릿에 하드코딩되지 않고 애플리케이션의 논리 — 사용자 역할, 현재 상황, 테넌트 구성 — 에 의해 구동되어야 할 때.
3. 임베디드 분석 API
임베디드 분석 API는 제품 내에서 데이터 검색이나 시각화뿐만 아니라 제품 내 전체 분석 계층까지 제공하는 완전한 분석 경험을 제공합니다. 데이터 접근, 렌더링, 화이트라벨 제어, 다중 테넌시, 보안이 통합된 인터페이스로 결합되어 있습니다.
- 완전 브랜드화된 제품 내 분석 경험을 강화합니다
- 쿼리 수준에서 다중 테넌트 데이터 격리 강제
- 색상, 글꼴, UI 동작 전반에 걸친 화이트라벨 배포 지원
- 데이터 접근, 비즈니스 규칙, 프레젠테이션 간의 일관된 논리를 유지하세요
언제 사용해야 하는지: 분석이 핵심 제품 기능으로서 자신의 팀이 만든 것처럼 보이고 행동해야 할 때.
4. 대화형 분석 API
대화형 분석 API는 아키텍처가 진정으로 새로워지는 부분입니다. 자연어 입력을 구조화된 쿼리로 변환하고, 데이터를 대상으로 쿼리를 실행하며, 텍스트, 지표, 시각적 출력으로 결과를 반환하여 사용자가 탐색 대신 대화를 통해 분석과 상호작용할 수 있게 합니다.
- 자연어 질문을 데이터 쿼리로 변환하기
- KPI 요약, 맥락적 설명, 시각적 결과물을 반환합니다
- 후속 질문 및 반복 분석 지원
- 제품 내에서 채팅 기반 분석 경험을 활성화하세요
이 내용은 다음 섹션에서 자세히 다루는데, 대화형 API의 거버넌스 및 비용 통제 측면은 종종 간과되기 때문이며, 이는 운영 환경에서 매우 중요합니다.
대화형 분석 API란 무엇이며, 거버넌스란 실제로 무엇을 의미하나요?
대화형 분석 API는 사용자나 AI 시스템이 자연어를 통해 데이터와 상호작용할 수 있게 합니다. 사용자가 질문을 합니다. API는 이를 구조화된 쿼리로 변환합니다. 쿼리는 데이터 인프라에 대해 실행됩니다. 결과는 대시보드 내비게이션 없이 제품 내에서 텍스트, 차트, 요약, 추천 등으로 돌아옵니다.
변화는 분석이 내비게이션이 아닌 대화를 통해 접근할 수 있다는 점입니다. 사용자는 어떤 대시보드를 봐야 하는지 알 필요가 없습니다. 그들이 알고 싶은 것을 묻습니다.
기본적인 흐름은 직관적입니다. 덜 단순한 점이자 대부분의 대화형 분석에 대한 설명이 간과하는 부분은 다중 테넌트 SaaS 제품에서 안전하게 작동하려면 반드시 진실이어야 하는 점입니다.
대부분의 벤더가 해결하지 않는 거버넌스 문제입니다
AI가 사용자가 통제하지 못하는 자연어 입력을 기반으로 동적으로 쿼리를 생성할 때, 정적 대시보드에는 없던 세 가지 위험이 나타납니다:
- 세입자 간 데이터 유출. 만약 AI 계층이 쿼리를 실행하기 전에 사용자의 테넌트 컨텍스트에 스코프가 지정되어 있지 않으면, 회사 A 사용자가 회사 B 소유의 데이터를 받을 가능성이 있습니다. 이것은 가정이 아니며, 실제 AI 배포에서 발생한 실패 모드입니다.
- 통제 불가능한 토큰 비용. LLM 기반 대화형 분석은 토큰 사용이 통제되지 않으면 상당하고 예측 불가능한 API 비용을 발생시킬 수 있습니다. 복잡하고 다단계적인 질문을 하는 사용자는 표준 대시보드 부하보다 훨씬 더 많은 LLM 호출을 생성할 수 있습니다. 컨트롤이 없으면 깜짝 청구서로 나타납니다.
- 데이터 거버넌스 정책과 상충되는 답변들. 의미층 밖에서 작동하는 AI 모델은 기술적으로는 일관성이 있지만 사실과 다르게 답변할 수 있습니다 — 존재하지 않는 지표를 요약하거나, 결합해서는 안 되는 차원을 결합하거나, 제품이 핵심 용어 정의 방식과 충돌하는 결과를 제시하는 경우입니다.
운영 준비가 된 대화형 분석 API는 이 세 가지 모두를 다룹니다:
- 임차인 범위 지정은 실행 전에 시행되며, 실행 후에는 적용되지 않습니다. AI 계층이 생성하는 모든 쿼리는 사용자의 테넌트 컨텍스트를 선택적 매개변수로 포함합니다.
- 토큰 사용은 통제되고 예측 가능합니다. 비용 노출은 플랫폼 수준에 제한되어 있으며, 사용자 행동에 따라 달라지지 않습니다.
- AI는 의미층 내에서 작동합니다. 메트릭 정의, 승인된 차원, 거버넌스 규칙은 AI가 조회할 수 있는 부분에 내장되어 있으며, 자연어 입력으로 우회되지 않습니다.
대화형 분석 데모와 대화형 분석 배포의 차이는 이러한 통제가 존재하느냐에 있습니다. 기존 분석 계층에 AI를 덧붙이는 플랫폼들은 보통 거버넌스를 부차적으로 다루는 경우가 많습니다. API가 먼저 구축된 플랫폼, 즉 AI가 동일한 거버넌스 데이터 계층의 한 소비자인 플랫폼은 구조적으로 거버넌스를 처리합니다.
분석 API 아키텍처의 주요 구성 요소
분석 API는 독립적으로 작동하지 않습니다. 각 구성 요소가 특정 책임을 담당하는 계층화된 아키텍처 위에 위치합니다. 플랫폼을 평가할 때 계층을 이해하는 것이 중요합니다 — 어떤 계층이든 간극이 발생하면 운영 환경에서 문제가 되기 때문입니다.

API 계층
API 계층은 애플리케이션이 호출하는 쿼리, 대시보드, 필터, AI 상호작용용 엔드포인트를 노출합니다. 그것은 당신의 제품과 그 아래 모든 것을 연결하는 인터페이스입니다. 잘 설계된 API 계층은 기본 데이터 인프라의 복잡성을 추상화하여 애플리케이션 코드가 사용 사례 전반에 걸쳐 깔끔하고 일관성을 유지하도록 합니다.
의미층
의미층은 메트릭과 차원이 무엇을 의미하는지 정의하며, 모든 쿼리에서 그 정의를 일관되게 강제합니다. 이 기능이 없으면 한 대시보드의 '수익'이 다른 대시보드의 '수익'과 다른 곳에서 다르게 해석될 수 있습니다. 왜냐하면 서로 다른 논리로 다른 테이블에 쿼리가 닿기 때문입니다. 의미론적 층이 그것을 막아줍니다. 이것이 비즈니스 논리의 유일한 진실의 근원이며, AI가 의미 계층이 승인한 정의로만 작업할 수 있기 때문에 AI 생성 쿼리를 신뢰할 수 있게 만드는 요소입니다.
AI 계층
AI 계층은 자연어 입력을 API 계층이 실행할 수 있는 구조화된 쿼리로 변환합니다. 잘 설계된 시스템에서 AI 계층은 의미층을 우회하지 않고 그 위에서 작동합니다. 이것이 대화형 분석을 관리 가능하게 만드는 이유입니다: AI는 사용자가 접근할 수 있는 데이터에 한정된 의미 계층이 정의하는 지표와 차원만을 사용해 질문할 수 있습니다.
보안 계층
보안 계층은 누가 어떤 데이터에 접근할 수 있는지를 통제하며, UI 수준이 아닌 쿼리 수준에서 강제됩니다. 여기에는 토큰 또는 OAuth 기반 인증, 역할 기반 접근 제어, 테넌트 수준의 데이터 격리가 포함됩니다. 중요한 차이점은, UI 계층에서 강제되는 보안(요소 표시 또는 숨기기)은 우회할 수 있다는 점입니다. 쿼리 계층에서 보안이 강제되는 것은 불가능합니다 — 어떤 쿼리도 사용자가 볼 수 없는 데이터를 반환합니다.
Reveal의 보안 아키텍처를 참조하세요
배포 계층
배포 계층은 분석이 어디서 어떻게 실행될지 결정합니다 — 클라우드, 하이브리드, 온프레미스 중 하나입니다. 규제 산업의 SaaS 기업이나 데이터 상주 요건이 있는 엔터프라이즈 고객에게 배포 유연성은 기능 요청이 아니라 계약 요구사항입니다. 클라우드 배포만 지원하는 분석 API 아키텍처는 기업 시장의 의미 있는 부분에서 제외됩니다.
SaaS 제품에서의 분석 API 사용 사례
분석 API의 추상적인 이점 — 제품 내 일부로서 분석이 제공된다는 점—은 전통적인 BI 접근법이 제공할 수 없는 구체적인 기능을 살펴보면 구체적으로 드러납니다.
고객 대상 제품 분석
SaaS 팀은 대시보드, 지표, 셀프 서비스 탐색을 애플리케이션에 직접 내장하기 위해 분석 API를 사용합니다. 모든 고객은 제품을 떠나지 않고도 자신의 데이터를 실시간으로 볼 수 있으며, 엔지니어링 팀이 처음부터 맞춤형 분석 계층을 구축하지 않아도 됩니다. API는 데이터 접근을, SDK는 렌더링을 담당하며, 제품 팀은 경험을 통제합니다.
대규모 다중 테넌트 분석
분석 API는 공유 플랫폼에서 수백 또는 수천 명의 고객 간에 안전한 데이터 격리를 가능하게 합니다. 각 API 호출은 어떤 데이터를 반환할지 지정하는 테넌트 컨텍스트를 포함합니다 — 즉, 새로운 고객을 추가할 때 새로운 환경을 구축할 필요 없이 기존 아키텍처 내에서 프로비저빙만 하면 됩니다. 이것이 비즈니스에 맞춰 확장되는 분석과 새로운 기업 계약을 체결할 때마다 인프라 작업이 필요한 분석의 차이입니다.
AI 기반 제품 내 인사이트
분석이 AI 시스템이 프로그래밍적으로 접근할 수 있는 API 계층을 통해 실행될 때, 대화형 분석이 가능해집니다. 사용자가 질문을 하고, AI는 거버넌스된 데이터 계층에 대해 쿼리를 생성하며, 결과는 제품 내에서 사용자의 테넌트와 역할에 맞게 적용된 답변으로 돌아옵니다. 이 아키텍처는 제품과 별도의 AI 도구가 필요하지 않고도 자연어 쿼리, 자동화된 인사이트 서핑, AI 생성 요약을 가능하게 합니다.
워크플로우 통합 분석
분석 API는 사용자 상호작용뿐만 아니라 애플리케이션 로직에 의해 호출될 수 있습니다. 이로 인해 분석이 워크플로우에 내장될 수 있습니다: 지표가 임계값을 넘으면 트리거가 발생하고, 프로세스가 완료되면 자동 보고서가 생성되며, 이상 현상이 감지되면 알림이 전송됩니다. 분석은 단순히 사용자가 성과 평가할 때 보는 것뿐만 아니라 제품 작동 방식의 일부가 됩니다.
분석 API 없이는 문제가 발생하는데
팀이 분석 통합에서 겪는 대부분의 문제는 같은 근본 원인으로 추적됩니다: 분석이 아키텍처 문제보다는 UI 문제로 다뤄졌기 때문입니다. iFrame 임베딩, 독립형 BI 도구, 맞춤형 대시보드는 모두 사용자에게 데이터를 가시화하는 즉각적인 필요를 해결합니다. 분석이 제품의 네이티브 일부로 작동하는 근본 문제를 해결하지 못합니다.
일반적인 고장 패턴
- UI 계층 멀티테넌시. UI에서 테넌트별로 대시보드를 필터링하는 것, 쿼리 수준에서 격리를 강제하는 대신. 작동하다가 작동하지 않고, 실패하면 고객 데이터가 다른 고객에게 보이는 상태에서 실패합니다.
- iFrame 커스터마이징 한계. 첫 번째 버전은 빠르게 배송됩니다. 두 번째 버전은 우회 방법이 필요합니다. 세 번째 버전이 되면서, 엔지니어링 팀은 iFrame이 제품의 일부처럼 동작하도록 해킹 작업을 점점 늘어나고 있습니다.
- 서로 다른 의미를 가진 지표들. 의미층이 없으면, 서로 다른 쿼리가 같은 메트릭을 다르게 계산합니다. 두 개의 대시보드가 서로 다른 수익 수치를 보여줍니다. 고객 에스컬레이션이 이어집니다.
- 통제할 수 없는 AI입니다. 분석 계층에 AI 기능을 추가하는 것은 데이터 유출, 토큰 비용 예측 불가능성, 제품 데이터 모델과 모순되는 AI 반응 등 노출을 초래합니다.
- 인프라 작업이 필요한 확장성. 모든 새로운 엔터프라이즈 고객은 분석 아키텍처가 다중 테넌트 규모에 맞춰 설계되지 않았기 때문에 프로비저닝 프로세스를 실행합니다.
Reveal 분석 API를 어떻게 구현하는가
Reveal SaaS 제품과 ISV를 위한 API 우선 분석 계층으로 구축되어 분석이 별도의 시스템으로 나란히 있지 않고 애플리케이션 로직에 통합됩니다. API 계층, SDK, 시맨틱 계층, AI 기능은 하나의 아키텍처에서 연결된 구성 요소이지, 함께 작동하기 위해 별도의 도구를 만들어야 하는 것이 아닙니다.
실제 모습은 다음과 같습니다:
- 귀하의 애플리케이션은 대시보드를 불러오고, 데이터를 쿼리하며, AI 인사이트를 트리거하기 위해 Reveal의 API를 호출합니다 — 이는 제품이 이미 사용하는 동일한 인증 모델을 사용합니다
- SDK는 디자인 시스템을 통해 제품 내 분석 컴포넌트를 렌더링합니다 — iFrame이나 외부 인터페이스가 스며들지 않습니다
- 다중 테넌트 데이터 격리는 쿼리 수준에서 강제되며, 모든 API 호출에서 테넌트 컨텍스트는 선택 사항이 아닙니다
- Reveal AI 거버넌트 데이터 계층 내에서 동작하며, 자연어 쿼리는 실행 전에 사용자의 테넌트와 역할에 스코프가 부여됩니다
- 토큰 비용은 플랫폼 수준에서 통제되며, 무제한 LLM 사용에 얽매이지 않습니다
- 배포는 데이터가 있어야 할 곳 — 클라우드, 하이브리드, 또는 완전 온프레미스 — 에서 진행됩니다
독립 약국을 지원하는 SaaS 플랫폼 Scriptly는 일주일 만에 Reveal의 분석 API와 SDK를 제품에 통합했습니다. 고객들은 이제 Scriptly 플랫폼 내에서 각 약국의 자체 데이터에 적용되는 실시간 처방전 추세와 재고 데이터를 Scriptly 브랜드 내에서 접근할 수 있으며, 외부 도구 없이 경험에 참여할 수 있습니다. 이 기능은 영업 대화에서 측정 가능한 차별화 요소가 되었습니다. 스크립리 이야기를 읽어보세요
