데이터 분석 에이전트는 겉으로 보면 가장 믿음직한 종류의 에이전트처럼 보인다. 말이 아니라 숫자를 다루기 때문이다. 하지만 바로 그 점이 함정이기도 하다. 문장이 틀리면 사람은 대체로 이상함을 느끼지만, 숫자가 틀리면 오히려 더 쉽게 속는다. 소수점 둘째 자리까지 반듯하게 나온 보고서는, 잘못된 조인과 오래된 테이블과 빠진 필터를 조용히 숨긴다. 그래서 데이터 분석 에이전트의 하네스는 "무엇을 계산하게 할까"보다 먼저 "어떻게 잘못 계산하지 못하게 할까"를 설계해야 한다.
좋은 데이터 분석 에이전트는 숫자를 많이 뽑는 에이전트가 아니다. 잘못된 숫자를 덜 뽑고, 애매한 결론을 함부로 말하지 않고, 사람이 해석해야 할 지점을 분명히 남기는 에이전트다.
데이터 분석 에이전트는 왜 특히 까다로운가
코딩 에이전트가 틀리면 테스트가 깨지고, 업무 자동화 에이전트가 틀리면 승인 단계에서 멈출 수 있다. 그런데 데이터 분석 에이전트는 틀려도 그럴듯한 표와 차트를 만든다. 이 점이 가장 위험하다.
예를 들어 사용자가 "지난 분기 이탈률이 왜 올랐는지 알려줘"라고 묻는다고 해보자. 이 질문에는 이미 여러 정의가 숨어 있다. 이탈률의 분모는 활성 고객인지 전체 고객인지, 기간 기준은 결제일인지 해지일인지, 원인은 상관관계인지 인과관계인지가 정해져야 한다. 에이전트가 이 질문을 곧바로 SQL 한 줄로 번역하면, 계산은 빨라도 분석은 틀릴 수 있다.
데이터 분석 하네스는 바로 이 지점에서 일을 시작한다. 질문을 바로 실행하지 않고, 먼저 정의를 고정하고, 접근 범위를 제한하고, 계산 경로를 기록하고, 결과를 검증한 뒤, 마지막에만 해석을 허용한다. 이 순서가 뒤집히면 분석 에이전트는 똑똑한 계산기처럼 보이지만 사실은 위험한 자동 완성기가 된다.
또 하나 중요한 점은 데이터 문제와 에이전트 문제를 구분하는 일이다. 데이터가 오래되었거나 스키마가 바뀌었거나 결측치가 갑자기 늘었는데, 이를 모르고 모델만 탓하면 엉뚱한 곳을 고치게 된다. 실제 하네스 테스트에서도 데이터 계층을 먼저 검증하지 않으면 데이터 실패를 에이전트 실패로 오해하기 쉽다.1
데이터 분석 하네스의 기본 구조
데이터 분석 에이전트의 실행 흐름은 가능한 한 짧고, 가능한 한 명시적이어야 한다. 가장 실무적인 구조는 다음과 같다.
질문을 분석 과제로 번역한다.
지표 정의와 데이터 범위를 확정한다.
읽기 전용 경로로 데이터에 접근한다.
SQL이나 Python 코드를 생성하되 제한된 환경에서만 실행한다.
결과를 수치 검증과 시각 검증으로 교차 확인한다.
리포트를 만들되 해석과 의사결정은 필요한 수준에서 사람에게 넘긴다.
이 구조에서 핵심은 "생성"과 "실행", "실행"과 "해석"이 서로 분리된다는 점이다. 모델이 쿼리를 만들 수는 있어도 곧바로 운영 데이터베이스를 뒤흔들어서는 안 된다. 차트를 그릴 수는 있어도 그 차트가 의미하는 비즈니스 결론까지 단독으로 확정해서는 안 된다.
질문 하나를 처리하는 데도 사실은 세 가지 서로 다른 일이 섞여 있다. 첫째는 데이터를 읽는 일이다. 둘째는 계산하는 일이다. 셋째는 의미를 붙이는 일이다. 하네스는 이 셋을 한 덩어리로 두지 않고 각각 다른 안전장치 아래 둔다.
데이터 접근 권한 설계
데이터 분석 에이전트에게 필요한 첫 번째 권한은 "데이터베이스 접속 권한"이 아니라 "얼마나 자세히 볼 수 있는가"에 대한 권한이다. 같은 고객 데이터라도 스키마만 보는 권한, 샘플 몇 줄을 보는 권한, 집계값만 보는 권한, 원시 행 데이터를 내보내는 권한은 전혀 다르다.
실무에서는 보통 권한을 다음과 같이 층으로 나누는 편이 안전하다.
메타데이터 권한: 테이블 목록, 컬럼명, 타입, 최근 갱신 시각, 소유자 정보만 볼 수 있다.
샘플 조회 권한: 마스킹된 예시 행이나 제한된 개수의 샘플만 볼 수 있다.
집계 조회 권한: 그룹별 합계, 평균, 건수처럼 비식별 집계 결과만 볼 수 있다.
원시 데이터 조회 권한: 승인된 범위 안에서만 행 단위 데이터를 읽을 수 있다.
반출 및 공유 권한: CSV 저장, 외부 전송, 대시보드 게시 같은 후속 행위를 수행할 수 있다.
좋은 하네스는 이 권한을 한 번에 열지 않는다. 처음에는 메타데이터와 제한된 샘플만 허용하고, 질문이 정당하며 목적이 분명할 때만 더 깊은 접근을 허용한다. "이탈 고객 명단을 뽑아줘"와 "이탈률 추이를 요약해줘"는 전혀 다른 수준의 위험을 가진 요청이다.
권한은 데이터베이스 계정 설계에도 반영되어야 한다. 분석 에이전트는 기본적으로 읽기 전용 계정을 써야 하고, 가능하면 짧게 만료되는 자격 증명으로 세션 단위 접근을 받아야 한다. 사람이 BI 도구에서 하던 버릇대로 광범위한 서비스 계정을 에이전트에게 넘기면, 분석 하네스는 시작부터 무너진다.
또한 데이터 소스별로 신뢰 등급을 나눌 필요가 있다. 운영 DB, 데이터 웨어하우스, CSV 업로드 파일, 외부 API는 같은 "데이터"처럼 보여도 품질과 책임 구조가 다르다. 하네스는 각 소스에 대해 스키마, 최신성, 결측률, 소유자를 알고 있어야 한다. 그렇지 않으면 에이전트는 숫자를 계산해도 그 숫자가 어느 세계의 숫자인지 모르게 된다.1
쿼리 생성과 검증
자연어를 SQL로 바꾸는 기능은 눈길을 끌지만, 실제로 중요한 것은 SQL을 얼마나 잘 쓰느냐가 아니라 SQL을 얼마나 함부로 쓰지 않느냐다.
데이터 분석 하네스에서 쿼리 생성은 보통 한 번에 끝내지 않는 편이 좋다. 안전한 흐름은 대체로 이렇다.
먼저 질문에서 지표 정의를 뽑아낸다.
필요한 테이블과 조인 경로를 후보로 제시한다.
초안 SQL을 생성한다.
정적 검사를 통해 금지 구문과 위험 패턴을 막는다.
EXPLAIN이나 제한 실행으로 비용과 스캔 범위를 확인한다.작은 샘플이나 집계 수준에서 먼저 결과를 본다.
최종 실행 전에 의미 검증을 거친다.
정적 검사에서는 최소한 몇 가지를 막아야 한다. DELETE, UPDATE, INSERT 같은 쓰기 연산은 당연히 차단해야 하고, 무제한 SELECT *, 카티전 곱을 유발하는 조인, 기간 조건 없는 대용량 조회, 승인되지 않은 스키마 접근도 막아야 한다. 에이전트가 쿼리를 "생성"하는 능력과 그 쿼리가 "운영에 적합한가"는 완전히 다른 문제다.
의미 검증도 중요하다. 예를 들어 매출 총합이 세그먼트별 합과 일치하는지, 비율 값이 0에서 100% 범위를 벗어나지 않는지, 고객 수가 음수가 아닌지 같은 상식적 검사는 기계적으로 돌릴 수 있다. 이런 검사는 단순해 보여도 현장에서 매우 강력하다. 잘못된 조인 하나가 만들어내는 기묘한 급등과 급락을 가장 빨리 잡아내기 때문이다.
가능하다면 생성기와 검증기를 분리하는 것이 좋다. 하나의 모델이 SQL을 만들고, 다른 검증 모듈이나 별도 에이전트가 정의·범위·비용·위험 패턴을 검사하는 구조다. 같은 모델이 만들고 같은 모델이 "좋아 보인다"고 말하는 구조는, 시험지를 낸 학생이 직접 채점하는 것과 비슷하다.
분석 코드 실행 환경
복잡한 데이터 분석에서는 SQL만으로 부족한 경우가 많다. 피벗, 통계 검정, 시계열 처리, 차트 생성, 이상치 탐지 같은 작업은 Python 코드 실행이 더 자연스럽다. 실제로 원시 데이터를 통째로 모델 컨텍스트에 넣는 것보다, 모델이 짧은 코드나 쿼리를 만들고 그것을 샌드박스에서 실행하는 방식이 더 확장 가능하고 정확한 경우가 많다.2
하지만 여기서 "코드 실행"은 마법이 아니라 위험한 권한이다. 따라서 데이터 분석 에이전트의 코드 실행기는 작은 연구실이 아니라, 잠금장치가 달린 실험실이어야 한다.
실행 환경에는 적어도 다음 조건이 필요하다.
네트워크 접근은 기본 차단하거나 엄격히 제한한다.
파일 시스템은 입력 데이터와 출력 폴더를 분리해 마운트한다.
메모리, CPU, 실행 시간에 상한을 둔다.
허용 라이브러리 목록을 명시한다.
세션 단위로 격리하고 종료 시 정리한다.
실행 로그와 산출물을 모두 남긴다.
간단한 내부 도구나 신뢰된 데이터셋에서는 제한된 네임스페이스 기반 실행도 가능하겠지만, 실제 제품 환경에서는 컨테이너나 관리형 코드 인터프리터 같은 격리 환경이 기본값이 되어야 한다.23 특히 외부 문서나 사용자 업로드 파일을 읽고, 그 결과를 바탕으로 코드를 생성하는 흐름이라면 더 강한 격리가 필요하다. 이런 경우에는 단순 컨테이너보다 더 강한 경계를 가진 실행 환경을 고려해야 한다는 지적도 많다.4
또 하나 놓치기 쉬운 점은 재현 가능성이다. 오늘은 pandas 2.2에서 돌아간 코드가 다음 달에는 라이브러리 버전 차이로 깨질 수 있다. 그래서 하네스는 실행 환경 버전, 패키지 목록, 데이터 스냅샷, 코드 해시를 함께 기록해야 한다. 데이터 분석은 대화가 아니라 실험에 가깝기 때문이다. 실험은 재현되어야 믿을 수 있다.
차트와 리포트 생성
많은 팀이 여기서 착각한다. 차트가 있으면 분석이 완성되었다고 느끼는 것이다. 하지만 차트는 증거가 아니라 표현 방식이다. 더 정확히 말하면, 차트는 증거를 보여주는 렌즈다. 렌즈가 왜곡되면 증거도 왜곡되어 보인다.
그래서 데이터 분석 하네스는 차트 생성도 통제해야 한다. 에이전트가 아무 차트나 예쁘게 그리는 것이 아니라, 질문과 데이터 타입에 맞는 차트만 선택하도록 해야 한다. 범주 비교인데 누적 면적 그래프를 쓰거나, 표본 수가 매우 작은데 선형 추세를 강조하거나, 절대값과 비율을 한 축에 섞어 그리면 보는 사람의 판단이 쉽게 흔들린다.
좋은 하네스는 차트와 함께 다음 정보를 항상 남긴다.
어떤 데이터 스냅샷을 사용했는가
어떤 필터와 집계 기준을 적용했는가
어떤 코드로 계산했는가
축과 단위는 무엇인가
표본 수와 결측치는 어떠한가
마지막 갱신 시각은 언제인가
이 정보가 빠진 차트는 예쁜 슬라이드일 수는 있어도, 믿을 만한 분석 산출물은 아니다.
리포트 생성에서도 같은 원칙이 적용된다. 에이전트는 숫자 요약, 표, 차트, 핵심 관찰점을 정리할 수 있다. 하지만 "왜 이런 현상이 생겼는가"를 단정하는 문장은 더 높은 검증 수준이 필요하다. 설명과 해석, 특히 원인 추정은 계산보다 훨씬 더 많은 맥락을 요구하기 때문이다.
잘못된 분석을 잡아내는 검증 루프
이 챕터의 핵심은 여기 있다. 분석 에이전트는 답을 잘 내는 시스템이기 전에, 잘못된 답을 걸러내는 시스템이어야 한다.
이를 위해서는 검증 루프가 여러 층으로 설계되어야 한다. 가장 바닥에는 데이터 검증이 있다. 데이터 소스의 최신성, 스키마 적합성, 결측률, 검색 정확도 같은 기본 품질이 확보되지 않으면, 그 위의 평가와 테스트는 모두 흔들린다.1
그 위에는 실행 검증이 있다. 쿼리가 금지 구문 없이 안전한지, 코드가 제한된 자원 안에서 끝나는지, 파일 접근이 허용 범위를 넘지 않는지 확인해야 한다. 그 다음에는 결과 검증이 온다. 결과가 정의된 불변조건을 만족하는지, 이전 기간과 비교해 비정상적으로 튀는 값이 아닌지, 다른 계산 경로로도 비슷한 결과가 나오는지를 본다.
실무에서 특히 효과적인 검증 방법은 다음과 같다.
이중 계산: 같은 지표를 SQL과 Python, 혹은 웨어하우스 집계와 데이터프레임 계산 두 경로로 비교한다.
불변조건 검사: 부분합의 합이 전체합과 맞는지, 비율의 분모가 0이 아닌지, 날짜 범위가 뒤집히지 않았는지 확인한다.
기준선 비교: 직전 배치, 기존 대시보드, 인간이 검증한 샘플 결과와 차이가 너무 큰지 본다.
이상치 경고: 표본 수가 너무 작거나 변동폭이 지나치게 크면 자동으로 경고를 붙인다.
행동 궤적 기록: 어떤 프롬프트에서 어떤 스키마를 읽고 어떤 쿼리를 실행했는지 남긴다.
여기서 중요한 것은 최종 답만 보는 것이 아니라, 그 답에 이르는 경로를 함께 보는 일이다. 관측 가능성과 검증은 따로 떨어진 주제가 아니다. 어느 테이블을 읽었는지, 어떤 가정을 세웠는지, 어디서 재시도했는지가 남아 있어야 실패 원인을 추적할 수 있다.
더 높은 신뢰가 필요한 환경이라면, 명시적 불변조건과 운영 텔레메트리를 함께 쓰는 방식이 유효하다. 단순히 "그럴듯해 보이는 답"을 통과시키는 것이 아니라, 미리 정한 기준으로 틀릴 수 있는 경로를 빠르게 반박하는 것이다.5 데이터 분석에서도 이 원리는 똑같다. 좋은 하네스는 에이전트를 칭찬하기보다, 틀렸을 때 빨리 잡아낸다.
사람이 해석해야 하는 지점
데이터 분석 에이전트를 도입하면 많은 팀이 묻는다. "그럼 이제 분석가가 필요 없나?" 오히려 반대다. 에이전트가 계산을 더 많이 맡을수록, 사람은 해석의 책임을 더 분명히 져야 한다.
사람이 반드시 개입해야 하는 지점은 대개 다음과 같다.
지표 정의를 바꾸는 결정: 활성 사용자, 전환, 이탈 같은 핵심 KPI의 정의 변경
인과 해석: "광고비 증가가 매출 상승의 원인이다" 같은 단정
고위험 개인 데이터 활용: 고객 리스트 추출, 민감 속성 결합, 외부 공유
정책·예산·조직 결정 연결: 가격 변경, 인력 감축, 프로모션 중단처럼 실제 행동으로 이어지는 판단
예외 상황 해석: 시스템 장애, 이벤트성 캠페인, 계절성 급변처럼 데이터만으로 설명되지 않는 맥락
에이전트는 "무슨 일이 있었는지"를 요약하는 데 강하다. 하지만 "왜 그런 일이 있었는지"와 "그래서 무엇을 해야 하는지"는 조직의 맥락, 책임, 윤리가 들어가는 문제다. 이 단계까지 자동화하려 하면 분석 자동화가 아니라 판단 외주가 되어버린다.
좋은 하네스는 그래서 리포트 문장도 층을 나눈다. 관찰 문장, 해석 문장, 권고 문장을 구분하고, 뒤로 갈수록 더 높은 승인 수준을 요구한다. 예를 들어 "지난 4주간 환불률이 2.1%에서 3.4%로 상승했다"는 관찰이다. "신규 결제 플로우 변경이 영향을 준 것으로 보인다"는 해석이다. "결제 플로우를 롤백하자"는 권고다. 세 문장은 비슷해 보여도 책임의 무게가 전혀 다르다.
실전에서 유용한 설계 원칙
마지막으로, 데이터 분석 에이전트 하네스를 설계할 때 기억할 만한 원칙을 정리해보자.
첫째, 원시 데이터보다 정의를 먼저 다뤄라. 질문이 모호하면 계산은 빨라질수록 더 위험해진다.
둘째, 읽기 권한과 반출 권한을 분리하라. 볼 수 있는 것과 내보낼 수 있는 것은 같은 권한이 아니다.
셋째, SQL 생성과 SQL 실행을 분리하라. 생성은 모델이 해도 되지만, 실행 허가는 하네스가 내려야 한다.
넷째, 코드 실행은 기능이 아니라 보안 경계로 설계하라. 분석용 파이썬은 편리한 도구이면서 동시에 가장 위험한 도구다.34
다섯째, 차트는 장식이 아니라 감사 가능한 산출물로 남겨라. 차트 파일, 생성 코드, 데이터 스냅샷, 필터 조건을 함께 저장해야 한다.
여섯째, 해석은 마지막까지 미뤄라. 계산이 끝났다고 의미가 확정된 것은 아니다.
결국 데이터 분석 에이전트 하네스의 목적은 하나다. 숫자를 더 빨리 꺼내는 것이 아니라, 잘못된 숫자가 의사결정 테이블에 올라오는 일을 줄이는 것이다. 좋은 분석 에이전트는 화려한 인사이트를 남발하지 않는다. 대신 데이터의 상태를 확인하고, 계산을 제한된 환경에서 실행하고, 결과를 여러 방식으로 검증하고, 마지막 판단을 사람이 감당할 수 있게 정리해 준다.
그럴 때 비로소 분석 에이전트는 "숫자를 뽑는 기계"가 아니라, "잘못된 분석을 막는 시스템"이 된다.
참고
1How to Test Your AI Agent Harness
2How to Build a Data Analysis Agent with Code Execution
3Execute code and analyze data using Amazon Bedrock AgentCore Code Interpreter
4AI agents for data analysis: Examples, security risks, and how to build your own
5Closing the verification loop: Observability-driven harnesses for building with agents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.