분석 API

대부분의 분석 통합은 동일한 방식으로 시작됩니다. 제품 팀이 애플리케이션 내부에 데이터를 필요로 합니다. 누군가 iFrame을 통해 대시보드를 임베드합니다. 배포됩니다. 대체로 작동합니다. 사용자는 제품을 떠나지 않고도 차트를 볼 수 있습니다.

그런 다음 첫 번째 커스터마이징 요청이 들어옵니다. 어떤 고객은 대시보드가 자사 브랜드와 정확히 일치하기를 원합니다. 또 다른 고객은 사용자가 애플리케이션에서 현재 하고 있는 작업에 반응하는 필터를 필요로 합니다. 누군가는 사용자가 리포트를 탐색하는 대신 자연어로 질문할 수 있는지 묻습니다. 그리고 엔지니어링 팀은 iFrame이 기반이 아니라 임시방편이었다는 것을 깨닫기 시작합니다.

분석 API는 제대로 구축된 임베디드 분석 경험의 근간에 자리 잡고 있는 것입니다. 이것은 분석이 제품의 네이티브 구성 요소처럼 동작하도록 하는 것으로, 애플리케이션 컨텍스트에 반응하고, 사용자 권한을 존중하며, AI가 생성한 인사이트를 제공하고, 유지 관리 부담이 되지 않으면서 수천 개의 테넌트에 걸쳐 확장됩니다.

이 가이드는 분석 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 도구는 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가 동일한 통제된 데이터 계층의 한 소비자인 플랫폼은 거버넌스를 구조적으로 처리합니다.

Reveal AI가 거버넌스를 어떻게 처리하는지 확인하세요.

분석 API 아키텍처의 핵심 구성 요소

분석 API는 단독으로 작동하지 않습니다. 각 구성 요소가 특정 책임을 처리하는 계층화된 아키텍처 위에 자리합니다. 계층을 이해하는 것은 플랫폼을 평가할 때 중요합니다 — 어떤 계층의 격차든 프로덕션에서 문제가 되기 때문입니다.

API 계층

API 계층은 애플리케이션이 호출하는 엔드포인트 — 쿼리, 대시보드, 필터, AI 상호 작용을 위한 — 를 노출합니다. 이것은 제품과 그 아래의 모든 것 사이의 인터페이스입니다. 잘 설계된 API 계층은 기반 데이터 인프라의 복잡성을 추상화하므로 애플리케이션 코드는 사용 사례 전반에 걸쳐 깔끔하고 일관성을 유지합니다.

시맨틱 계층

시맨틱 계층은 지표와 차원이 무엇을 의미하는지 정의하고, 그 정의를 모든 쿼리에 걸쳐 일관되게 적용합니다. 이것이 없으면 한 대시보드의 “매출”이 다른 대시보드의 “매출”과 다른 의미가 될 수 있습니다. 서로 다른 쿼리가 서로 다른 로직으로 서로 다른 테이블에 접근하기 때문입니다. 시맨틱 계층은 이를 방지합니다. 이것은 비즈니스 로직의 단일 진실 공급원이며, AI가 생성한 쿼리를 신뢰할 수 있게 만드는 것입니다 — AI는 시맨틱 계층이 승인한 정의로만 작업할 수 있기 때문입니다.

AI 계층

AI 계층은 자연어 입력을 API 계층이 실행할 수 있는 구조화된 쿼리로 변환합니다. 잘 설계된 시스템에서 AI 계층은 시맨틱 계층을 우회하지 않고 그 위에서 작동합니다. 이것이 대화형 분석을 통제 가능하게 만드는 것입니다. AI는 시맨틱 계층이 정의하는 지표와 차원만 사용하여, 사용자가 액세스할 수 있는 데이터로 범위가 지정된 질문을 할 수 있습니다.

보안 계층

보안 계층은 누가 어떤 데이터에 액세스할 수 있는지 제어하며, UI 수준이 아니라 쿼리 수준에서 적용됩니다. 여기에는 토큰 또는 OAuth 기반 인증, 역할 기반 액세스 제어, 테넌트 수준 데이터 격리가 포함됩니다. 결정적인 차이: UI 계층에서 적용되는 보안(요소를 표시하거나 숨김)은 우회될 수 있습니다. 쿼리 계층에서 적용되는 보안은 우회될 수 없습니다 — 어떤 쿼리도 사용자가 볼 수 없는 데이터를 반환하지 않습니다. Reveal의 보안 아키텍처 확인하기

배포 계층

배포 계층은 분석이 어디서 어떻게 실행되는지 — 클라우드, 하이브리드, 또는 온프레미스 — 를 결정합니다. 규제 산업의 SaaS 기업이나 데이터 레지던시 요구 사항이 있는 엔터프라이즈 고객을 보유한 기업에게 배포 유연성은 기능 요청이 아니라 계약 요건입니다. 클라우드 배포만 지원하는 분석 API 아키텍처는 엔터프라이즈 시장의 상당 부분에서 부적격 요인이 됩니다.

SaaS 제품에서의 분석 API 사용 사례

분석 API의 추상적인 이점 — 제품 옆이 아니라 제품의 일부로서의 분석 — 은 기존 BI 접근 방식으로는 할 수 없는, 분석 API가 가능하게 하는 구체적인 것들을 살펴보면 구체화됩니다.

고객 대면 제품 분석

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 기능은 함께 작동하도록 만들어야 하는 별도의 도구가 아니라 단일 아키텍처의 연결된 구성 요소입니다.

실제로는 이렇게 보입니다:

• 애플리케이션이 Reveal의 API를 호출하여 대시보드를 로드하고, 데이터를 쿼리하고, AI 인사이트를 트리거합니다 — 제품이 이미 사용하는 것과 동일한 인증 모델을 사용하여
• SDK가 iFrame이나 외부 인터페이스의 노출 없이 디자인 시스템을 사용하여 제품 내부에 분석 구성 요소를 렌더링합니다
• 멀티테넌트 데이터 격리는 쿼리 수준에서 적용됩니다 — 테넌트 컨텍스트는 모든 API 호출에서 필수입니다
• Reveal AI는 통제된 데이터 계층 내에서 작동합니다 — 자연어 쿼리는 실행 전에 사용자의 테넌트와 역할로 범위가 지정됩니다
• 토큰 비용은 플랫폼 수준에서 통제됩니다 — 무제한 LLM 사용의 대상이 되지 않습니다
• 배포는 데이터가 있어야 하는 곳에서 실행됩니다 — 클라우드, 하이브리드, 또는 완전한 온프레미스

독립 약국에 서비스를 제공하는 SaaS 플랫폼인 Scriptly는 Reveal의 분석 API와 SDK를 일주일 만에 자사 제품에 임베드했습니다. 이제 그들의 고객은 Scriptly 플랫폼 내에서 실시간 처방 트렌드와 재고 데이터에 액세스합니다 — 각 약국 자체 데이터로 범위가 지정되고, Scriptly의 브랜드 아래에서, 경험 속에 외부 도구가 전혀 없는 상태로. 이 기능은 영업 대화에서 측정 가능한 차별화 요소가 되었습니다. Scriptly 스토리 읽기