This post is also available in the following languages. Japanese, English

분석 에이전트의 힘으로 분석을 하나로 연결하다! 전문 조직에서 도전하는 생성 AI 시대의 업무 혁신과 역할 전환

LY Corporation의 기술 컨퍼런스인 Tech-Verse 2026의 공식 기사입니다.

안녕하세요. AI 에이전트로 분석을 ‘하나로 잇는’ 프로젝트 ‘PJ One Piece’의 프로덕트 매니저 하시모토와 프로덕트 오너 오카다입니다.

PJ One Piece는 생성형 AI를 활용해 비즈니스 질문부터 데이터 분석, 인사이트 정리, 다음 액션 검토까지 연결하는 분석 AI 에이전트 프로젝트입니다. 선행 도입 후 기존에 의뢰부터 결과 회신까지 평균 약 2주가 걸리던 분석을 약 10분 만에 실행할 수 있게 되었으며, 그 덕분에 사업부 내에서 월 수백 건의 분석이 실행되고 있습니다.

이 글에서는 생성형 AI를 활용해 비즈니스와 데이터의 단절, 분석 프로세스 내 단절, 도메인 간 단절을 어떻게 하나로 연결하려고 하는지, 그 과정에서 데이터 사이언티스트의 역할이 어떻게 변화하고 있는지 소개합니다.

프로젝트 출범 배경인 세 가지 단절

PJ One Piece의 출발점에는 분석 업무에서 발생하는 다음 세 가지 단절이 있었습니다.

비즈니스와 데이터의 단절
분석 프로세스 내 단절
도메인 간 단절

이 세 가지 단절은 비즈니스 질문이 데이터에 도달하지 못하고, 분석 프로세스가 본래 목표를 잃고 예상치 못한 방향으로 흘러가고, 도메인별 지식을 재활용하기 어렵게 만들었습니다. 단절의 심각도는 사업마다 달랐지만 각 단절이 서로 영향을 주고받으며 해당 사업의 데이터 활용 속도와 품질에 영향을 미쳤습니다.

각 단절을 조금 더 자세히 살펴보겠습니다.

먼저 ‘비즈니스와 데이터 간 단절’입니다. DWH(data warehouse)와 BI(business intelligence)가 정비되어 데이터에 접근할 수 있는 상태가 됐더라도, 사업 현장에서 필요한 시점에 필요한 수준의 정보를 스스로 데이터에서 얻기에는 여전히 장벽이 높았습니다. SQL을 어떻게 작성해야 하는지, 어떤 테이블과 컬럼을 사용해야 하는지, 어떤 지표와 정의를 기준으로 봐야 하는지, 수많은 변동 속에서 의미 있는 정보를 어떻게 찾아내야 하는지, 얻은 수치를 어떻게 해석하고 활용하는지 등 아직도 판단해야 할 사항이 많이 남아 있었습니다. 데이터 기반을 마련해도 데이터 활용의 마지막 1마일(last mile)이 여전히 남아 있던 것입니다.

다음은 ‘분석 프로세스 내 단절’입니다. 이 단절은 과제 정의에서 시작해 분석 설계, 분석 실행, 리뷰, 액션까지 이어지는 흐름이 담당자나 도구, 실행 시점의 차이 때문에 분리되면서 맥락이 쉽게 끊기는 상태를 의미합니다. 의뢰자의 사업 배경이나 의사 결정 목적이 충분히 문서화되지 않았거나 분석 설계 의도가 실행이나 리뷰 단계로 제대로 전달되지 않으면 인식에 차이가 발생하고 재작업을 하게 됩니다. 또한 단절되면 각 공정 간에 대기 시간이 발생하면서 리드타임이 실제 작업 시간 이상으로 길어집니다. 그 결과 분석 품질이 들쭉날쭉해지고, 인사이트가 액션으로 이어지는 속도도 떨어지는 문제가 발생했습니다.

마지막은 ‘도메인의 단절’입니다. 사업 도메인이 바뀌면 분석 담당자도 바뀌고, 서비스의 전제 조건과 KPI 정의, 비교해야 할 관점, 테이블 구조, 시책과 사용자 행동의 맥락도 달라집니다. 그 결과 어떤 도메인에서 뛰어난 분석 기법이나 분석 패턴이 만들어져도 해당 도메인 내부에만 머무르고 다른 도메인에서는 잘 활용되지 못했습니다. 시책 평가와 퍼널 분석, 사용자 이해, 원인 분석, 효과 측정 등 구조가 유사한 분석은 많았지만 도메인별 배경 지식이나 테이블 정의 및 사용 규칙, 과거 의사 결정 근거, 리뷰 관점, 결과를 통해 얻은 학습이 각각 분리되어 있으면 분석 자산을 조직 전체로 확산하기 어렵습니다.

PJ One Piece는 AI를 기반으로 업무, 지식, 데이터, 사람의 역할, 조직 구조를 재설계해서 이 세 가지 단절을 ‘하나로 연결’하는 것을 목표로 삼았습니다. 그 중심에 있는 것이 자율적으로 분석을 수행하는 AI 에이전트, 즉 분석 에이전트입니다.

분석 에이전트로 분석을 ‘하나로 연결하다’

여기서 말하는 분석 에이전트는 데이터 사이언티스트가 평소 수행하는 ‘질문을 정리한다’, ‘필요한 데이터를 찾는다’, ‘집계·분석한다’, ‘결과를 해석한다’, ‘다음 액션으로 연결한다’라는 흐름을 사내 시스템을 활용하면서 수행하는 에이전트를 말합니다. 사용자가 채팅 화면과 같은 진입점에서 자연어로 요청하면 에이전트는 목적을 해석해 분석 계획을 수립한 뒤 다양한 도구를 활용해 정보를 수집하고 결과를 정리합니다.

이 분석 에이전트가 지향하는 ‘하나로 연결하기’란 데이터 분석을 둘러싼 일련의 활동과 자산을 연결하는 것을 의미합니다. 이는 앞서 설명한 세 가지 단절에 대응합니다.

첫 번째는 비즈니스와 데이터를 연결하는 것입니다. 사업 담당자가 데이터 사이언티스트에게 요청하고 결과를 기다리는 데 그치지 않고 스스로 질문을 만들어 분석을 수행하고 다음 액션까지 고민할 수 있는 상태를 목표로 합니다. 예를 들어 SQL이나 테이블 정보 같은 복잡한 기술적 요소를 의식하지 않고, “지난주 캠페인은 매출에 효과가 있었는가? 다음에는 어떤 유입 경로를 개선해야 하는가?”라고 자연어로 질문하는 것만으로 분석을 시작할 수 있도록 만듭니다.

두 번째는 분석 프로세스를 연결하는 것입니다. 에이전트는 SQL이나 집계 결과 같은 부분적인 결과만 반환하는 것이 아니라, 사용자의 목적과 과정 맥락을 유지한 채 의사 결정에 필요한 논점을 정리하고, 캠페인 대상이나 비교 기간을 확인하며, 집계 및 전문 분석을 수행하고, 결과를 해석해 시각화하거나 보고서 형태로 정리해서 사용자가 목적을 달성할 수 있도록 지원합니다. 필요하다면 추가 분석도 제안하며 사용자가 다음 액션을 고민할 수 있는 단계까지 함께합니다.

세 번째는 도메인 간 연결입니다. 분석 에이전트라는 형태로 분석을 형식지화하면 분석 지식 자체를 재사용 가능하고 지속적으로 개선할 수 있는 자산으로 만들 수 있습니다. 질문 정리, 요구 사항 정의, 지표 및 비교 축 선택, 리뷰 관점, 추가 분석 판단과 같은 과정을 로그로 남기고 이를 이용해 어디에 전제 조건이 부족한지, 어디에서 재작업이 발생하기 쉬운지 파악해 분석 프로세스를 개선합니다. 자주 등장하는 분석 프로세스는 다른 담당자나 다른 도메인에서 재사용할 수 있도록 스킬로 일반화합니다.

분석 에이전트를 뒷받침하는 전체 구조는 크게 다섯 가지 컴포넌트로 정리할 수 있습니다.

사용자와의 접점이 되는 애플리케이션
사용자의 목적을 달성하기 위해 추론과 도구 활용을 수행하는 LLM 기반 에이전트
SQL 실행, Python 실행, 사내 문서 조사, 시각화 등을 담당하는 도구
도메인 지식, 스킬, 테이블 정보 등을 제공하는 지식 베이스
분석 에이전트 전체 로그와 사용자 피드백, 모니터링, 평가를 담당하는 측정 시스템

지식 영역은 프로덕트 도메인별로 추가할 수 있는 플러그인 구조로 설계했으며, 실행 로그와 피드백도 개선에 활용하기 때문에 사용할수록 지식과 분석 패턴이 축적되는 구조입니다. 즉, PJ One Piece의 분석 에이전트는 단순한 LLM 채팅 애플리케이션이 아니라 애플리케이션과 에이전트, 도구, 지식, 측정을 결합한 분석 실행 플랫폼으로 설계했습니다.

분석을 ‘하나로 연결하기’ 위한 설계와 기술

이 세 가지 연결을 실현하려면 분석을 단순히 자동화하는 것만으로는 충분하지 않습니다. 데이터 분석을 둘러싼 일련의 활동과 자산을 하나의 시스템으로 설계해야 합니다. 분석 에이전트를 구현하고 운영하는 과정에서 나타난 기술 과제를 네 가지로 정리해 살펴보겠습니다.

1. 비즈니스 질문을 분석 가능한 맥락으로 변환하기

첫 번째 과제는 사용자의 자연어 질문을 명확한 분석 요구 사항으로 변환하는 것입니다. 여기서는 사용자에게 상세한 분석 요구 사항을 작성하게 하는 것이 아니라 에이전트 측이 도메인 지식과 테이블 정보를 참조해 부족한 전제 조건만 확인하는 방식으로 설계했습니다.

‘지난주 캠페인은 매출에 효과가 있었는가?’라는 질문에는 대상 정책, 기간, KPI, 비교 대상, 어떤 단위로 분석할지, 제외 조건 등 많은 전제가 포함되어 있습니다. 만약 전제가 모호하다면 비즈니스와 데이터 사이는 여전히 단절된 상태로 남습니다.

다만 사용자가 매번 이러한 내용을 빠짐없이 프롬프트에 작성하는 것은 현실적이지 않습니다. 사용자가 작성해야 하는 것은 ‘무엇을 알고 싶은가’이지, 데이터 구조나 분석 설계를 숙지하고 있다고 전제하고 상세한 지시를 하는 것이 아닙니다. 따라서 사업 측의 자연스러운 질문을 출발점으로 삼아 질문의 배경을 보완하고 분석 요구 사항으로 변환하는 구조가 필요합니다.

이를 위해 서비스 이해, KPI 정의, 집계 시 주의사항, 정책 정보 탐색 방법, 리뷰 시 확인해야 할 전제 조건을 매번 프롬프트에 넣는 게 아니라 도메인별 지식으로 관리하고 있습니다. 아울러 어떤 테이블과 컬럼이 있으며, 어떤 테이블을 어떤 상황에서 사용해야 하는지와 같은 테이블 정보도 정비합니다.

이 설계를 통해 사용자는 SQL이나 테이블 구조를 몰라도 자신의 질문에서 분석을 시작할 수 있습니다. 한편 에이전트 측은 사업 배경과 테이블 정보를 참조하면서 확정할 수 있는 항목과 모호하기 때문에 사용자에게 확인해야 하는 항목을 구분하고, 확인이 필요한 항목만 추가 확인해 적은 사용자 부담으로 분석 요구 사항을 구체화할 수 있습니다. 이는 비즈니스와 데이터를 연결하기 위한 토대입니다.

2. 필요한 데이터에 안전하고 확실하게 도달하기

다음 과제는 분석에 필요한 데이터에 안전하고 확실하게 도달할 수 있도록 만드는 것입니다. 에이전트가 데이터를 정확하게 사용하려면 상세한 테이블 정보를 제공해야 하는데요. 대규모 데이터를 보유한 도메인에서는 분석에 사용하는 테이블이나 컬럼이 많아서 관련 설명과 이용 시 주의 사항을 모두 포함하면 분량이 상당히 많아집니다. 이를 처음부터 모두 LLM 입력에 포함하면 컨텍스트가 비대해지고 필요한 정보를 놓치기 쉽습니다. 또한 입력 토큰이 늘어나 비용이 증가하고 응답 속도와 추론 안정성도 악화됩니다.

이에 저희는 테이블 목록과 같은 분량이 적은 정보와 테이블별 상세 정보를 분리하고, 이를 단계별로 공개해 필요한 정보에 도달할 수 있도록 했습니다. 에이전트는 먼저 테이블 목록만 참조해 사용할 테이블을 좁힌 다음, 사용할 테이블의 상세 정보를 확인한 뒤, SQL을 작성하기 전에 필요한 설명과 컬럼 정의, 샘플, 파티션 조건, 이용 시 주의사항을 파악합니다. 모든 것을 처음부터 읽게 만드는 게 아니라, 필요한 시점에 필요한 지식으로 이동할 수 있게 만드는 구조입니다.

또한 업무 시스템이나 DWH의 테이블은 분석할 때 그대로 사용하기 쉬운 형태라고 할 수 없습니다. 목표 집계에 도달하기까지 여러 추출 조건이나 JOIN이 필요하다면 SQL 생성 복잡도가 단번에 높아질 것입니다. 따라서 DB에 있는 테이블을 그대로 다루지 않게 만들었습니다. 분석 용도에 최적화한, 트랜잭션 데이터에 각종 속성을 결합한 와이드 테이블을 논리적 뷰 또는 실제 테이블로 만들고, 이를 에이전트에 공개하는 접점으로 삼았습니다. 이렇게 하면 에이전트는 간단한 추출 조건이나 집계만으로 많은 집계를 실행할 수 있으므로 SQL 생성 복잡도가 낮아지고 실수를 최소화할 수 있습니다.

또한 SQL은 실행 전후에 반드시 시스템 측에서 확인합니다. SELECT만 가능하도록 제한, 공개된 테이블 정의 및 사용 규칙과 대조, 파티션 조건, 민감 정보나 개인정보 제한, 결과 행 수 제어 등을 시스템에서 확인 후 보장해서 에이전트가 잘못된 SQL을 실행하거나 과도한 데이터를 얻게 되는 위험을 낮춥니다. 이러한 가드레일 덕분에 에이전트가 안전한 환경에서 비교적 자유롭게 분석을 수행할 수 있습니다.

3. 분석 설계부터 실행 및 해석까지 컨텍스트 유지하기

세 번째 과제는 분석 설계부터 집계, 시각화, 해석, 리뷰의 맥락이 끊기지 않도록 하는 것입니다. SQL만 생성할 수 있다고 해서 분석 프로세스가 하나로 연결되는 것은 아닙니다. 어떤 대상을 비교해야 하는지, 어떤 축과 분석 단위로 살펴봐야 중요한 인사이트를 얻을 수 있는지, 이 결과로 사용자의 목적을 달성할 수 있는지, 이 분석으로 무엇을 알 수 없었는지(어떤 추가 분석이 필요한지)까지 다룰 필요가 있습니다.

이를 위해 멀티 에이전트 구성을 채택했습니다. 분석 에이전트는 사용자와의 상호작용을 담당하면서, 전체 맥락을 관리하는 에이전트가 분석 계획을 수립하고, 필요에 따라 컨텍스트를 분리한 서브 에이전트에 작업을 위임하는 슈퍼 바이저형 멀티 에이전트 구성입니다. 메인 에이전트는 요청 내용, 분석 목적, 지금까지 파악한 내용, 다음에 판단해야 할 논점을 지속적으로 유지하고, 통계 검정, 시계열 분석, 클러스터링, 리뷰와 같은 전문 작업은 역할을 제한한 서브 에이전트로 분리합니다.

이와 같이 구성하면 전체 맥락은 메인 에이전트에서 유지하면서, 컨텍스트를 압박할 정도의 시행착오가 필요한 작업이나 전문 지식을 요구하는 작업, 독립적인 시각이 필요한 작업은 지식과 컨텍스트를 서브 에이전트 측에 국한한 상태로 실행할 수 있습니다. 전체 설계와 전문 작업을 분리함으로써 맥락을 유지하면서도 심층 분석이나 독립적인 리뷰로 연결할 수 있습니다.

또한 분석 에이전트의 작업은 일반적인 단발성 채팅 응답보다 오래 걸리는 경우가 있는데요. 이때 조사 과정에서 밝혀진 내용, 분석 설계, 사용 가능한 데이터와 사용할 수 없는 데이터, 중간에 발견된 제약 조건 등의 진행 상황을 적절히 공유해서 사용자가 도중에 방향이나 확인해야 할 관점을 수정할 수 있게 지원합니다.

4. 분석 에이전트를 공통 자산으로 만들어 조직 전체가 함께 발전시키기

마지막 과제는 분석 에이전트를 단순한 개별 업무 지원 도구에서 끝내지 않고, 조직이 지속적으로 육성할 수 있는 분석 역량으로 만드는 것입니다. 중요한 것은 그 과정에서 축적된 도메인 지식, 분석 기술, 리뷰 관점, 결과 해석 방법, 개선 과정에서 얻은 학습을 다음 분석이나 다른 도메인에서도 활용할 수 있는 형태로 전환하는 것입니다.

이때 중요한 역할을 하는 것이 사용 로그와 피드백입니다. 로그를 통해 어떤 입력에 어떤 출력을 반환했는지, 실행 중 에이전트가 어떤 동작을 수행했는지, 어떻게 전제를 확인했는지, 어떤 분석 설계를 작성했는지, 어떤 SQL을 생성했는지, 어떤 분석에서 오류가 발생했는지 등을 파악할 수 있습니다. 또한 사용자와 분석 담당자의 피드백을 결합해서 프롬프트나 도구, 데이터, 스킬 중 어느 부분을 개선해야 하는지 개선 백로그로 정리할 수 있습니다.

반복 등장하는 분석은 스킬 형태로 재사용할 수 있게 만듭니다. 시계열 분석이나 클러스터링 분석처럼 여러 도메인에서 활용할 수 있는 범용 스킬도 있을 것이고, 특정 서비스의 월간 보고서 작성이나 정책 모니터링처럼 도메인 특화 스킬도 있을 것입니다. 어느 경우든 확인해야 할 전제 조건과 비교 축, 주의사항, 결과 해석 방법까지 포함해 명문화합니다.

이와 같은 스킬과 개선 백로그를 축적해서 도메인별로 분리돼 있던 지식과 분석 패턴을 조직 전체가 활용할 수 있는 분석 역량으로 전환할 수 있습니다. 분석 에이전트를 단일 애플리케이션이 아니라 여러 진입점에서 동일한 데이터 정의 및 사용 규칙, 스킬, 리뷰 관점을 사용할 수 있는 실행 플랫폼으로 다루면 사용할수록 지식과 분석 자산이 축적되고 대응 가능한 분석 영역과 품질도 지속적으로 확대됩니다.

분석 한 건의 공수는 2주에서 10분으로: 선행 도입으로 확인한 사업 가치

PJ One Piece의 분석 에이전트는 일부 서비스 사업부에서 선행 도입해 프로덕트 오너부터 현장 구성원에 이르기까지 폭넓게 활용하고 있습니다. 선행 도입하면서 가장 큰 임팩트가 있었던 부분은 사업부 내에서 데이터를 활용하는 인원 자체가 빠르게 늘었다는 점입니다. 덕분에 현재는 사업부 구성원의 절반 이상이 사용하는 분석 플랫폼으로 성장했습니다. 이제 데이터 사이언티스트만 사용하는 도구가 아니라 모든 사용자가 일상 업무 속에서 ‘우선 물어보는’ 진입점이 되었습니다.

또한 가장 눈에 띄게 달라진 것은 분석 리드타임입니다. 사람이 직접 대응하던 시절에는 요청부터 결과 회신까지 평균 약 2주가 걸렸지만, 분석 에이전트는 약 10분 만에 결과를 제공합니다. 이제 전일 실적을 상세 분석한 결과를 다음 날 오전 회의나 정책 검토에서도 충분히 활용할 수 있게 되었습니다.

사업부 내 분석 건수도 크게 변화했습니다. 분석 팀이 직접 대응하던 시절에는 월 10건 정도가 현실적인 상한선이었지만, 현재는 사업부 내에서 수백 건 규모의 분석이 수행되고 있습니다. 분석 건수가 증가한 것 자체도 중요하지만, 그보다 더 중요한 것은 과거에는 ‘굳이 분석 요청할 정도는 아니다’, ‘대기 순번이 있으니 나중으로 미루자’고 판단하던 질문들을 실제로 분석할 수 있게 되었다는 점입니다.

정책 기간 동안 매출이나 주문 수는 어떻게 변화했는가
현재 어떤 상품이 어떤 사용자에게 인기가 있는가
어떤 유입 경로나 세그먼트에서 수치가 움직이고 있는가

위 질문들을 하나하나 살펴보면 반드시 고도의 분석이라고 할 수는 없습니다. 하지만 사업 의사 결정 과정에서는 자주 등장하며 타이밍이 중요한 질문인데요. 이를 분석 조직의 리소스에 의존하면 모든 분석을 수행하기도 어렵고, 수행하더라도 대기 시간이 발생해 정보의 신선도가 떨어집니다. 분석 에이전트는 이러한 데이터 활용의 병목을 해소하고 있습니다.

데이터 사이언티스트의 역할은 어떻게 변하는가

분석 에이전트를 도입하면서 나타난 또 하나의 큰 변화는 데이터 사이언티스트의 가치와 생산성이 향상되었다는 점입니다. 사업 부서가 스스로 분석을 진행할 수 있게 되면 데이터 사이언티스트의 일이 줄어드는 것이 아니라, 담당해야 하는 업무의 성격이 변화합니다. 즉, 분석 에이전트는 데이터 사이언티스트의 업무를 대체하는 것이 아니라 요청 기반 분석에 머물기 쉬운 전문성을 사업 과제 발굴과 분석 역량 체계화로 확장시키는 역할을 합니다.

기존에는 분석 요청을 받아 요구 사항을 확인하고, SQL을 작성하고, 데이터를 집계하고, 시각화하고, 인사이트를 정리하는 업무가 데이터 사이언티스트 업무의 상당 부분을 차지했습니다. 물론 이러한 역량은 앞으로도 여전히 중요하겠지만, 분석 에이전트가 분석 실행을 담당하게 되면서 데이터 사이언티스트가 모든 분석 요청을 직접 해결해야 할 필요는 줄어들고 있습니다.

대신 현재는 사업 상위 단계의 전략 수립이나 기획 프로세스에 참여하면서 스스로 중요한 과제를 발견하고 제안하며 해결하는 활동이 늘어나고 있습니다. 다시 말해, 이미 드러난 문제를 해결하는 역할에서 잠재적인 사업 과제를 정의하고 해결하는 역할로 이동하고 있습니다.

또한 데이터 사이언티스트의 생산성 역시 크게 향상되었습니다. 분석 프로젝트의 생산성은 분석 에이전트 도입 이전과 비교해 약 2배 수준으로 향상되었습니다. 개별 프로젝트에 투입되는 공수를 줄이는 동시에 더 많은 프로젝트를 수행할 수 있게 되었습니다.

이러한 역할 변화와 생산성 향상 덕분에 분석 에이전트와 같은 재사용 가능한 분석 자산을 구축하는 활동에도 시간을 투자할 수 있게 되었습니다. 이는 단기적인 프로젝트 처리와는 별개로, 분석 역량을 지속적으로 향상시키기 위한 투자입니다. 범용 스킬이나 도메인 특화 스킬, 분석용 테이블, 리포트 형식 등을 정비하면 이후 분석은 더욱 빠르고 안정적으로 수행될 수 있습니다.

즉, 사업 부서는 스스로 분석을 수행할 수 있게 되었고, 데이터 사이언티스트는 요청 분석에 사용하던 시간을 더 중요한 과제 해결이나 분석 에이전트 자체를 발전시키는 활동에 투자할 수 있게 되었습니다. 여기에 생성형 AI 시대에 분석 조직의 새로운 가치가 있다고 생각합니다. 중요한 것은 무엇을 AI에 맡기고 무엇을 사람이 담당할지 설계하는 것입니다. AI가 강점을 발휘하는 영역은 하고자 하는 일이 명확하고, 필요한 정보에 AI 스스로 접근할 수 있으며, 이후에는 정보를 수집하면서 사고하고 실행할 수 있는 영역입니다. 반면 사람이 담당해야 하는 것은 정말로 해결해야 할 중요한 질문을 식별하고, 어느 정도의 어려움이 있더라도 바람직한 해결책을 향해 나아가는 일이라고 생각합니다.

마치며

PJ One Piece라는 이름은 분석을 ‘하나로 연결하고 싶다’는 의지를 담고 있습니다. 생성형 AI의 등장으로 분석을 수행하는 방식은 크게 변화하기 시작했습니다. 여기서 정말 중요한 것은 ‘AI로 어디까지 자동화할 수 있는가’가 아니라, ‘비즈니스 질문과 데이터, 분석 프로세스, 도메인 지식을 어떻게 연결하고, 거기서 얻은 인사이트를 다음 의사 결정과 다음 분석으로 어떻게 이어갈 수 있는가’입니다.

생성형 AI 시대의 분석 조직에 요구되는 것은 단순히 AI에게 분석을 맡기는 것이 아닙니다. AI가 역량을 발휘할 수 있도록 업무와 지식, 데이터, 그리고 사람의 역할을 설계하는 것이 중요하다고 생각합니다.

저희는 앞으로도 분석을 일회성 작업으로 끝내지 않고 조직에 지식과 실행력이 지속적으로 축적되는 구조로 발전시켜 나갈 것입니다. 이를 통해 데이터 활용을 일부 전문가만의 영역이 아니라, 비즈니스를 움직이는 많은 사람들의 힘으로 바꾸어 나가고자 합니다.