Al Agent가 스스로 설계하고, 실행하는 데이터 분석

왜 지금 데이터 분석에 AI Agent가 필요한가

안녕하세요. HEARTCOUNT의 Product Manager David입니다.

AI Agent의 시대입니다. 개인의 모바일 기기에서부터 개발자의 IDE, 그리고 시스템에 통합되는 거대한 구조까지, 일상과 업무의 모든 곳에 에이전트는 빠르게 침투해들어오고 있습니다.

통상 AI 에이전트는 “똑똑한 챗봇”으로 오해되곤 하지만, 그 본질은 훨씬 더 복잡합니다. AI 에이전트는 단지 주어진 질문에 답을 생성하는 모델이 아니라, 특정 목표를 달성하기 위해 스스로 작업을 계획하고, 필요한 도구를 선택하고, 실행 결과를 바탕으로 다음 행동을 결정하는 하나의 시스템입니다. 다시 말해 입력에 대한 출력을 만들어내는 단일 함수가 아니라, 생각하고, 행동하고, 수정하는 루프를 내재한 실행 단위라고 볼 수 있습니다.

이 구조에서 LLM은 단순한 답변 생성기(예를들어, ChatGPT, Claude)가 아니라 의사결정의 중심 역할을 맡습니다. 에이전트는 데이터를 조회하거나 API를 호출하고, 필요하면 다른 에이전트에 작업을 위임하며, 목표에 도달할 때까지 계획을 계속 수정해 나갑니다. 즉, AI는 더 이상 결과를 말해주는 존재에 머무르지 않고, 실제 작업을 수행하는 존재로 이동하고 있는 것입니다.

이 변화가 특히 중요한 이유는, 우리가 해결하려는 대부분의 문제가 한 번의 질문과 한 번의 답으로 끝나지 않기 때문입니다. 현실의 문제는 언제나 불완전한 정보, 반복적인 수정, 그리고 여러 단계의 실행을 포함합니다. 데이터 분석 역시 마찬가지입니다.

이러한 기대로 인해 국내외를 가리지 않고 많은 기업들이 에이전트 도입과 구축을 시도하고 있습니다. 다만 “에이전트면 다 된다”는 기대는 위험합니다. 2025년 6월 리포트에서 Gartner는 에이전틱 AI 프로젝트의 상당 비율이 비용 증가, 불명확한 비즈니스 가치, 리스크 통제 미흡 때문에 중단될 수 있다고 경고했고, 동시에 에이전트와 어시스턴트의 개념 혼용, 이른바 ‘agent washing’ 역시 문제로 지적했습니다.

데이터 분석으로 초점을 옮겨 봅시다. AI 데이터 분석의 시대가 열린 지금, 중요한 것은 단지 SQL을 생성하는 모델이 아닙니다. 질문을 해석하고, 필요한 데이터를 찾고, 쿼리를 만들고, 실행하고, 오류를 수정하고, 결과를 해석하는 흐름 전체를 어떻게 시스템으로 설계할 것인가가 더 중요해지고 있습니다.

단일 LLM 호출 만으로 데이터 분석이 어려운 이유

데이터 분석은 질문 한 번으로 끝나지 않는다

기존의 데이터 분석은 분석가 중심의 구조였습니다. 데이터를 이해하고, 질문을 정의하고, 적절한 쿼리를 작성하고, 결과를 해석하는 모든 과정이 개인의 역량에 의존했습니다. 같은 데이터라도 누구의 손을 거치느냐에 따라 전혀 다른 결론이 나오는 이유도 여기에 있습니다. 분석은 도구의 문제가 아니라, 결국 사람의 숙련도와 도메인 이해에 묶여 있었기 때문입니다.

SQL 생성만으로는 분석이 완료되지 않는다

LLM의 등장은 이 구조를 부분적으로 흔들었습니다. 자연어로 질문을 던지면 SQL을 생성하고 결과를 설명해주는 경험은 분명 진입 장벽을 낮췄습니다. 하지만 여전히 잘못된 쿼리가 생성되면 이를 검증하고 수정할 주체가 필요하고, 결과 해석의 책임 역시 사용자에게 남아 있습니다.

실행, 오류 수정, 해석까지 이어져야 한다

실제 분석 환경에서는 SQL이 실패하거나, 데이터가 없거나, 질문 자체가 모호한 경우가 반복적으로 발생합니다. 이때 중요한 것은 “정답을 한 번에 생성하는 능력”이 아니라, 문제를 해결할 때까지 과정을 이어가는 구조입니다.

AI 에이전트 구조는 이 지점에서 분석의 주체를 사람에게서 시스템으로 일부 이동시킵니다. 질문 해석, 컨텍스트 수집, SQL 생성, 실행, 오류 수정, 해석이라는 단계를 역할별로 분리하고, 각 단계를 반복 가능한 구조로 묶어줍니다. 이 과정에서 사람은 모든 과정을 직접 수행하는 존재가 아니라, 흐름을 감독하고 판단하는 위치로 이동하게 될 것입니다.

에이전트 시스템의 핵심 구조 이해하기

AI 에이전트 시스템은 보통 단일 모델이 아니라, 역할이 분리된 여러 구성요소와 이를 연결하는 제어 계층으로 이루어집니다. 아래는 AI 데이터 분석 맥락에서 에이전트 시스템의 핵심 구조를 정리한 표입니다.

구분	역할	데이터 분석에서의 역할	강점	주요 한계
단일 LLM 호출	한 번의 입력 → 한 번의 출력	간단한 SQL 생성, 요약, 설명	빠르고 단순함	스키마 오류, 실행 불가 쿼리, 오류 추적 어려움
에이전트	LLM + 도구 + 반복 루프	쿼리 생성 → 실행 → 오류 수정 → 재실행	실행과 피드백을 통해 신뢰도 개선	루프 과다, 잘못된 도구 선택, 비용 증가
멀티 에이전트	역할별 에이전트 협업	질문 해석, SQL 생성, 검증, 해석, 시각화 분업	단계별 전문화, 디버깅 용이	에이전트 간 불일치, 상태 충돌
오케스트레이터	실행 흐름 제어 계층	단계 순서, 분기, 재시도, 로그 관리	예측 가능성, 안정성, 디버깅 가능	설계 복잡도 증가, 과도한 제어
컨텍스트	에이전트가 판단과 실행을 위해 참조하는 상태·지식·기억	스키마, 지표 정의, 사용자 의도, 이전 결과 등 분석의 근거 제공	일관된 판단, 정확한 실행, 사용자 맞춤 분석 가능	컨텍스트 과다 시 혼란, 부족 시 오판

단일 호출, 에이전트, 멀티 에이전트의 차이

단일 LLM 호출은 가장 단순한 형태의 접근 방식입니다. 하나의 입력에 대해 하나의 출력을 생성하는 구조로, 설명이나 요약, 간단한 SQL 초안 생성 같은 작업에는 충분히 빠르고 효율적입니다. 하지만 데이터 분석 자동화처럼 실행과 검증이 필요한 문제에서는 한계가 분명합니다. 생성된 결과가 실제로 실행 가능한지, 스키마에 맞는지, 논리적으로 타당한지 확인하는 과정이 없기 때문입니다.

에이전트는 이 한계를 보완하기 위해 등장한 구조입니다. LLM이 도구를 사용할 수 있고, 실행 결과를 다시 입력으로 받아 다음 행동을 결정하는 반복 루프를 포함합니다. 예를 들어 SQL을 생성하고 실행한 뒤, 오류가 발생하면 이를 수정하고 다시 실행하는 흐름을 스스로 반복할 수 있는 것이죠. 이를 통해 단순히 “그럴듯한 답”이 아니라 실제로 동작하는 결과에 도달할 가능성이 높아집니다. 다만 반복 루프가 과도하게 길어지거나, 잘못된 도구를 선택하면 비용과 지연이 급격히 증가하는 문제가 발생할 수 있습니다.

멀티 에이전트는 이 과정을 더 세분화합니다. 하나의 에이전트가 모든 작업을 처리하는 대신, 질문 해석, 컨텍스트 수집, SQL 생성, 검증, 해석, 시각화 등 각 단계를 역할별로 나누어 처리합니다. 이렇게 분리하면 각 단계의 책임이 명확해지고, 개별 단계 단위로 테스트와 개선이 가능해집니다. 때문에 전체 시스템의 유지보수성과 디버깅 가능성이 크게 좋아집니다. 반면 여러 에이전트가 협업하는 구조에서 서로 다른 판단이나 상태 불일치가 발생할 수 있고, 이를 조정하는 비용이 추가로 필요합니다.

오케스트레이터가 필요한 이유

오케스트레이터는 이 모든 구조를 실제로 작동하게 만드는 제어 계층입니다. 각 에이전트를 어떤 순서로 실행할지, 어떤 조건에서 다음 단계로 넘어갈지, 오류가 발생했을 때 어떻게 재시도할지를 정의합니다. 이 계층이 존재해야 전체 흐름이 예측 가능해지고, 문제가 발생했을 때 원인을 추적할 수 있습니다. 오케스트레이터가 없는 멀티 에이전트 시스템은 단순히 여러 모델이 동시에 동작하는 상태에 그치지만, 오케스트레이션이 추가되면 하나의 일관된 “분석 실행 시스템”으로 동작하게 됩니다.

컨텍스트와 상태가 분석 정확도를 좌우하는 이유

컨텍스트는 에이전트 시스템에서 종종 간과되지만, 실제로는 가장 중요한 구성 요소 중 하나입니다. 에이전트는 매번 독립적으로 동작하는 것이 아니라, 이전 단계의 결과와 외부 지식을 기반으로 다음 행동을 결정해야 합니다. 이때 필요한 것이 바로 컨텍스트입니다. 컨텍스트는 단순한 입력 프롬프트를 넘어서는 개념입니다. 스키마 정보, KPI 정의, 사용자 질문의 의도, 이전 실행 결과, 심지어 과거 분석 히스토리까지 포함됩니다. 이러한 정보가 제대로 전달되지 않으면 에이전트는 올바른 결정을 내릴 수 없습니다. 실제로 에이전트 시스템에서는 컨텍스트를 저장하고 재활용하는 메모리 구조가 핵심 기능으로 다뤄지며, 이를 통해 과거 경험을 기반으로 더 나은 의사결정을 수행할 수 있습니다.

데이터 분석 AI 에이전트의 구조

위 개념 중 HEARTCOUNT 2.0 업데이트를 이해하기 위해 꼭 필요한, 멀티 에이전트와 오케스트레이터에 대해서 조금 더 자세히 살펴봅시다.

멀티 에이전트: 에이전트 간의 협력을 통한 의사결정

멀티 에이전트 구조는 하나의 AI가 모든 문제를 처리하는 방식이 아니라, 여러 개의 독립적인 에이전트가 협력하거나 때로는 서로 다른 판단을 내리며 문제를 해결하는 구조입니다. 각 에이전트는 자신의 목표와 판단 로직을 가지고 있고, 서로 결과를 주고받으며 전체 작업을 완성해 나갑니다. 구조적으로는 하나의 중심이 있는 트리(수직 구조)가 아니라, 여러 노드가 연결된 네트워크(수평 구조)에 가깝습니다.

멀티 에이전트 방식이 세상에 등장한 이유는 무엇일까요? 가장 핵심적인 이유는 현실의 문제가 하나의 사고 흐름으로 일관되게 풀리지 않기 때문입니다. 정보는 불완전하고, 중간에 판단이 바뀌기도 하며, 여러 방향의 접근이 동시에 필요합니다. 멀티 에이전트는 이러한 복잡성을 그대로 수용하는 구조입니다. 각 에이전트가 독립적으로 판단하고, 그 결과를 교환하면서 점진적으로 해답에 수렴합니다.

이 수평 구조의 가장 큰 특징은 분산된 의사결정입니다. 특정 중앙 모델이 모든 결정을 내리는 것이 아니라, 각 에이전트가 부분적인 판단을 수행하고, 그 결과가 전체 흐름을 구성합니다. 이로 인해 특정 단계에 대한 의존도가 낮아지고, 시스템 전체가 하나의 병목에 묶이지 않게 됩니다.

이와 유사한 개념이 서브 에이전트 구조입니다. 서브 에이전트는 하나의 상위 에이전트가 작업을 분해하고, 하위 단위에 실행을 위임하는 방식입니다. 구조적으로는 트리 형태를 가지며, 의사결정은 상위 에이전트에 집중됩니다. 각 서브 에이전트는 독립적인 주체라기보다는 특정 작업을 수행하는 기능 단위에 가깝습니다.

이 구조는 흐름이 명확하고 예측 가능성이 높습니다. 어떤 순서로 작업이 수행되는지 정의되어 있기 때문에 디버깅과 관리가 용이합니다. 대신 자율성과 병렬성이 제한되며, 복잡한 문제에 대해서는 유연하게 대응하기 어려울 수 있습니다.

실제 시스템에서는 이 두 구조가 분리되어 사용되지 않습니다. 대부분의 경우 상위에는 흐름을 제어하는 오케스트레이터가 존재하고, 내부에는 서브 에이전트들이 안정적인 실행을 담당합니다. 동시에 특정 복잡한 문제나 탐색이 필요한 영역에서는 멀티 에이전트 협업이 부분적으로 도입됩니다.

오케스트레이터: 협업을 ‘실행 가능한 구조’로 만드는 계층

위에서 언급하였듯이 멀티 에이전트 구조는 문제를 나누고 병렬로 처리할 수 있게 해주지만, 그 자체만으로는 안정적인 시스템이 되지 않습니다. 각 에이전트가 독립적으로 판단하고 움직이는 구조에서는 전체 흐름이 쉽게 흔들리고, 결과의 일관성을 유지하기 어렵습니다. 이 지점에서 등장하는 것이 오케스트레이터입니다.

오케스트레이터는 단순히 여러 에이전트를 연결하는 도구가 아니라, 전체 실행 흐름을 정의하고 통제하는 계층입니다. 중요한 것은 “에이전트를 여러 개 둔다”는 사실이 아니라, 그들이 어떤 순서로, 어떤 조건에서, 어떤 기준으로 동작하는지가 명확하게 정의되어 있다는 점입니다. 따라서 오케스트레이터로 인해 멀티 에이전트의 협업이 예측 가능한 실행으로 통제될 수 있습니다.

1) 결정론적 흐름 제어

여기서의 핵심 개념이 결정론적 흐름 제어입니다. 이는 결과가 항상 동일하다는 의미가 아니라, 다음 단계로 어떻게 넘어갈지가 시스템에 의해 명시되어 있다는 뜻입니다. 다시 말해, 에이전트에게 “알아서 해”라고 맡기는 것이 아니라, 시스템이 “어디까지를 어떻게 할지”를 정의하고, 에이전트가 그 안에서만 움직이도록 만드는 구조입니다.

이러한 구조는 디버깅을 용이하게 해 주는데요. 에이전트에 의해 어떤 결과가 도출되고 그 결과가 어떤 경로를 거쳐 생성되었는지를 추적할 수 있어야 할 때, 오케스트레이터는 각 단계의 입력, 실행, 결과를 연결된 흐름으로 관리하고, 필요하면 특정 단계부터 다시 실행할 수 있도록 할 수 있습니다.

2) 오류 처리와 재시도

또 하나 중요한 역할은 오류 처리와 재시도입니다. 오케스트레이터가 없는 구조에서는 오류가 발생했을 때 이를 대화로 보정하려고 시도하게 됩니다. 그러나 이 방식은 실패를 누적시키기 쉽고, 동일한 문제가 반복되는 구조를 만듭니다. 반면 오케스트레이션이 적용된 시스템에서는 오류가 특정 단계에서 감지되고, 정해진 루프에 따라 재시도되거나 보완됩니다. 입력을 다시 수집하거나, 다른 경로를 선택하거나, 일부 단계를 수정하는 방식으로 실패를 흡수합니다.

3) 상태 (State)

이 과정에서 중요한 또 하나의 개념이 상태(state)입니다. 상태는 오케스트레이터가 생성 및 관리하는 전체 흐름의 기억 및 중간 결과라고 볼 수 있습니다. 이전 단계에서 무엇을 해석했고, 어떤 결과가 나왔으며, 어떤 선택이 이루어졌는지가 다음 단계로 전달되어야 전체 흐름이 유지됩니다. 오케스트레이터는 이 상태를 관리하고, 각 에이전트가 동일한 맥락 위에서 작업할 수 있도록 합니다.

HEARTCOUNT 2.0의 데이터 분석 AI Agent

HEARTCOUNT는 이러한 AI Agent에 대한 이해와 철학을 바탕으로, 기존의 데이터 분석 서비스 HEARTCOUNT를 전면 개편한 HEARTCOUNT 2.0의 베타 버전을 공개했습니다.

데이터 분석은 질문 하나에 대한 답을 생성하는 문제가 아닙니다. 질문을 해석하고, 필요한 데이터를 찾고, 쿼리를 만들고, 실행하고, 결과를 검증하고, 다시 해석하는 연속된 과정으로 이루어져 있습니다. 앞서 살펴보았듯이, 이 분석의 흐름은 단일 LLM 호출로 안정적으로 처리되기 어렵습니다. 실제 분석 환경에서는 SQL이 실패하거나, 데이터가 없거나, 질문 자체가 모호한 경우가 반복적으로 발생하기 때문이에요. 이때 중요한 것은 “정답을 한 번에 생성하는 능력”이 아니라, 문제를 해결할 때까지 과정을 이어가는 구조입니다.

이러한 이유로 HEARTCOUNT 2.0은 단일 모델 중심 구조 대신, 역할이 분리된 여러 에이전트가 협력하고 이를 오케스트레이터가 제어하는 구조를 선택했습니다. 각 단계는 독립적으로 동작하지만, 전체는 하나의 흐름으로 연결되게 됩니다. 결과적으로 HEARTCOUNT 2.0에서의 분석은 “질문 → 답변”이 아니라 “질문 → 계획 → 실행 → 검증 → 해석 → 표현”으로 확장되었습니다. 사용자는 하나의 질문만 입력하지만, 내부에서는 분석 전체 과정이 자동으로 수행되도록 설계되어 있는 것이지요.

그럼, HEARTCOUNT 2.0의 AI Agent를 통한 분석 구조를 함께 살펴보겠습니다.

HEARTCOUNT 2.0의 오케스트레이터 중심 에이전트 아키텍처

사용자가 질문을 입력하면, HEARTCOUNT 2.0의 에이전트는 곧바로 분석을 실행하지 않습니다. 먼저 오케스트레이터가 이 질문이 어떤 유형의 작업인지 판단하고, 어떤 방식으로 분석을 진행해야 할지를 결정합니다.

이때 오케스트레이터는 두 가지 역할을 수행합니다.

먼저 오케스트레이터에는 라우터(router)라는 분기 에이전트가 존재하는데요. 이 라우터는 사용자의 질문과 컨텍스트를 바탕으로 어떤 분석 경로를 선택할지를 판단합니다. 단순한 질의로 바로 처리할 수 있는 경우와, 여러 단계의 실행과 검증이 필요한 경우를 구분하고, 그에 맞는 분석 흐름으로 분기하는 역할을 합니다.
또한 오케스트레이터는 중앙 제어 계층(central control layer)으로서 동작합니다. 선택된 경로 위에서 각 단계가 어떤 순서로 실행될지, 어떤 조건에서 다음 단계로 넘어갈지, 오류가 발생했을 때 어떻게 재시도할지를 정의합니다. 이때 중요한 역할을 하는 것이 바로 위에서 살펴 본 ‘상태(state)’입니다. 상태는 단순한 내부 데이터가 아니라, 현재까지의 분석 맥락과 중간 결과를 모두 포함하는 공유된 실행 컨텍스트입니다. 질문 해석 결과, 선택된 분석 방향, 생성된 SQL, 실행 결과와 같은 정보들이 상태로 누적되고, 각 단계는 이 상태를 기반으로 다음 행동을 결정합니다.
마지막으로 오케스트레이터는 오류 처리와 복구 전략(error fix & retrieval)을 담당합니다. 분석 과정에서 SQL 실행 실패, 데이터 없음, 예상치 못한 예외와 같은 문제가 발생하면 이를 즉시 감지하고, 사전에 정의된 방식으로 재시도하거나 대체 경로로 전환합니다. 예를 들어 SQL 생성 단계에서는 오류 메시지를 기반으로 쿼리를 자동 수정하여 다시 실행하고, 일정 횟수 이상 실패할 경우에는 분석을 종료하고 원인 설명을 사용자에게 전달합니다. 또한 분석이 더 이상 유효하게 진행될 수 없는 경우에는 실행을 중단하고 상태에 종료 사유를 기록함으로써, 전체 흐름이 예측 가능하게 관리되도록 합니다.

이러한 오케스트레이터의 구조 위에서 분석은 "하나의 실행 흐름”으로 동작합니다. 각 단계는 독립적으로 수행되지만, 이전 단계의 결과를 상태로 전달받아 다음 작업을 이어갑니다. 예를 들어 질문 해석 결과가 다음 단계의 SQL 생성에 반영되고, SQL 실행 결과는 다시 해석과 시각화 단계로 이어집니다. 이처럼 분석의 모든 과정이 끊기지 않고 연결되기 때문에, 최종 사용자가 확인하는 분석의 결과는 단순한 출력이 아니라 하나의 일관된 흐름의 산물로 구성됩니다.

HEARTCOUNT 2.0의 멀티 에이전트 구조: 역할 기반 분업 시스템

오케스트레이터 구조 위에서 실제 분석을 수행하는 것은 여러 개의 에이전트들입니다. HEARTCOUNT 2.0에서는 분석을 하나의 모델이 끝까지 처리하는 방식이 아니라, 역할별로 나뉜 에이전트들이 순차적으로 또는 병렬적으로 협력하는 구조로 설계되어 있습니다.

각 에이전트는 명확한 역할을 가지고 동작합니다. 질문을 해석하고 의도를 구조화하는 단계, 필요한 데이터와 스키마를 파악하는 단계, SQL을 생성하고 실행하는 단계, 실행 결과를 검증하고 보완하는 단계, 그리고 이를 차트와 설명으로 구성하는 단계까지, 분석의 전체 흐름이 여러 작업 단위로 나뉘어 있습니다. 이렇게 역할을 분리하면 각 단계의 책임이 명확해지고, 특정 단계에서 문제가 발생했을 때 해당 부분만 수정하거나 재실행할 수 있습니다. 또한 서로 독립적인 작업은 병렬로 처리할 수 있기 때문에, 전체 분석 속도와 안정성 모두를 개선할 수 있습니다.

현재 HEARTCOUNT 2.0의 베타 릴리즈에서는 이러한 멀티 에이전트 구조가 하나의 잘 정의된 분석 파이프라인 위에서 동작하고 있습니다. 사용자는 하나의 질문을 입력하면, 내부에서는 이 파이프라인을 따라 각 에이전트가 순차적으로 실행되며 결과가 생성됩니다. 4월 정식 출시 시 에이전트가 스스로 분석 계획을 수립하고, 필요한 하위 작업을 동적으로 구성하는 보다 자율적이고 강력한 분석 흐름 또한 확장될 예정입니다 (해당 기능은 4월 정식 출시에서 확인하실 수 있으며, 3월 25일 웨비나에서 데모로 공개될 예정입니다).

HEARTCOUNT 2.0의 분석 흐름 요약: 질문에서 결과까지

결과적으로 사용자는 데이터를 업로드하고 질문만 입력하면 바로 분석을 시작할 수 있습니다. 이 질문은 먼저 해석 단계를 거쳐 분석 가능한 형태로 구조화되고, 이후 실제 데이터에 대한 분석으로 이어집니다. 분석 과정에서는 적절한 SQL 쿼리문이 생성되고 해당 쿼리문을 실제로 실행하여 조회가 이루어지며, 필요할 경우 오류를 보정하거나 조건을 수정하는 과정을 거칩니다.

이후 분석된 데이터는 바로 사용자에게 제공하기 전에, 표현(차트, 테이블 생성)과 해석(내러티브 생성) 단계를 거치게 됩니다. 수치는 의미 있는 정보로 정리되고, 차트와 함께 구성되며, 사용자가 이해할 수 있는 형태의 설명으로 이어집니다. 이 과정에서 해당 분석 히스토리의 맥락이 유지되기 때문에, 결과는 단순한 데이터가 아니라 하나의 흐름으로 읽히게 됩니다.

요약하면, HEARTCOUNT 2.0에서의 분석 경험은 단지 “질문 → 결과”가 아니라 “질문 → 질문 해석 → 실행(분석) → 검증 → 결과 해석 → 표현”이라는 일련의 과정입니다.

사용자는 이 복잡한 과정을 직접 수행하지 않아도 되며, 최종적으로는 에이전트가 직접 작업한 데이터, 차트, 설명이 결합된 완성된 분석 결과를 확인하게 됩니다.

대용량 데이터도 빠르게 다루는 인브라우저 분석 구조

HEARTCOUNT 2.0은 또한 데이터 분석이 이루어지는 위치와 방식에 대해서 재정립하고자 했습니다.

왜 서버가 아니라 브라우저에서 분석하는가

기존의 데이터 분석 시스템은 서버 중심 구조를 기반으로 동작해왔습니다. 사용자는 데이터를 업로드하고, 서버에서 쿼리를 실행한 뒤, 그 결과를 다시 전달받는 방식이 일반적이었죠. 이 구조는 안정성과 확장성 측면에서는 장점이 있지만, 분석 과정에서 발생하는 지연과 반복적인 데이터 이동이라는 근본적인 한계를 가지고 있습니다.

HEARTCOUNT 2.0은 문제를 다른 방식으로 접근했습니다. 분석을 서버가 아닌 사용자의 브라우저 환경에서 직접 수행하는 인브라우저(In-Browser) 분석 구조를 선택한 것입니다.

DuckDB-WASM 기반 분석이 주는 사용자 경험의 차이

HEARTCOUNT 2.0은 브라우저에서 실행하는 DuckDB-WASM 기반의 SQL 실행 엔진을 활용하여, 사용자의 로컬 환경에서 수기가 수준의 데이터를 직접 쿼리하고 처리할 수 있도록 설계했습니다. 이를 통해 데이터를 서버로 전송하고 결과를 기다리는 대신, 이미 로컬에 존재하는 데이터를 기반으로 즉시 쿼리를 실행하고 결과를 확인할 수 있습니다. 분석의 흐름이 끊기지 않고 이어지며, 사용자는 보다 빠른 피드백을 기반으로 탐색적인 분석을 지속할 수 있습니다.

HEARTCOUNT 2.0은 이러한 기술적 선택을 통해, AI Agent 기반의 분석 흐름과 인브라우저 실행 구조를 결합한 새로운 형태의 분석 경험을 제공하고자 합니다. 인브라우저 데이터 분석의 자세한 아키텍처와 구현 방식에 대해서는 추후 테크 블로그를 통해 보다 깊이 있게 다루도록 하겠습니다.

HEARTCOUNT 2.0이 지향하는 다음 단계: Operational Decision Agent (ODA)

아무리 에이전트가 분석 역량이 좋다 하더라도, 결국 데이터 분석이 실제 의사결정으로 이어지기 위해서는 두 가지 전제가 필요합니다. 하나는 신뢰할 수 있는 데이터 소스를 기반으로 정확한 값을 가져오는 것이고, 다른 하나는 그 수치가 의미하는 바를 해석할 수 있는 비즈니스 맥락에 대한 이해입니다. 단순히 SQL을 생성하고 결과를 보여주는 것만으로는 부족하며, KPI(결과)와 이를 구성하는 Driver(원인), 실제로 조정 가능한 Lever(변수) 사이의 관계까지 연결되어야 비로소 분석이 ‘행동’으로 이어질 수 있습니다.

이 지점을 해결하기 위해 HEARTCOUNT 2.0은 ODA(Operational Decision Agent)를 준비하고 있습니다. ODA는 질문을 분석으로 바꾸는 데서 멈추지 않고, 지표의 변화가 어떤 운영 변수와 연결되어 있는지 구조적으로 이해하고, 그에 따라 실행 가능한 판단까지 이어지는 흐름을 설계하는 에이전트 구조입니다. 데이터 조회, 분석, 해석이 분절된 과정이 아니라 하나의 연속된 의사결정 체계로 작동하도록 만드는 것이 목표입니다.

ODA에 대한 자세한 내용은 다음 달 예정된 웨비나에서 먼저 소개드릴 예정이며, 이후 정식 출시를 통해 실제 제품에서 직접 경험하실 수 있습니다.

마치며

AI는 더 이상 결과를 만들어주는 도구에 머무르지 않고, 실제 작업을 수행하는 에이전트 시스템으로 이동하고 있습니다. 이 변화 속에서 데이터 분석 역시 질문에 대한 답을 생성하는 단계에서 벗어나, 실행되고 검증되며 이어지는 하나의 프로세스로 재구성되고 있음을 함께 살펴보았습니다.

HEARTCOUNT 2.0은 이러한 흐름 위에서 오케스트레이션, 멀티 에이전트, 인브라우저 분석을 결합해 분석 자체의 구조를 바꾸고자 했습니다. 앞으로 HEARTCOUNT를 통해 분석이 다만 더 빠르고 편해지는 것이 아니라, 더 실행 가능하고, 더 일관되며, 실제 의사결정으로 이어지는 방향으로 진화하는 것을 관심을 가지고 지켜봐주세요.

💖

무료 체험하기
HEARTCOUNT가 만들어가는 AI 에이전트 분석 경험이 궁금하다면 지금 바로 살펴보세요. 베타 버전에서 모든 기능을 무제한으로 무료 이용할 수 있습니다.

출처