대시보드 요구가 들어오면 제품 담당자는 종종 두 선택지 사이에서 멈춥니다. 개발 우선순위를 기다릴지, AI를 활용해 업무 부서가 먼저 만들지의 문제입니다. 이때 “AI가 화면과 SQL을 작성할 수 있는가”만 보면 판단을 잘못하기 쉽습니다.
AI로 대시보드를 직접 만들 수 있는 범위는 있습니다. 다만 그 범위는 화면 난이도가 아니라 데이터의 의미를 누가 정의할 수 있는지, 조회 결과를 누가 검증할 수 있는지, 잘못된 숫자가 어떤 업무 결정을 망칠 수 있는지에 따라 정해야 합니다.
AI 대시보드는 빠른 프로토타입 도구가 될 수 있지만, 운영 의사결정에 쓰이는 순간부터는 데이터 제품으로 다뤄야 합니다. 아래 순서는 업무 부서가 직접 만들기 시작해도 되는 일과 개발팀 또는 외부 전문 인력에게 넘겨야 할 일을 가르는 구현 청사진입니다.
시작점은 화면 요구가 아니라 결정 질문이다
“매출 현황을 보고 싶다”는 요구만으로는 대시보드를 설계할 수 없습니다. 먼저 이 화면을 본 사람이 어떤 행동을 바꿔야 하는지 정합니다.
예를 들어 예약 서비스의 담당자가 보고 싶은 것이 채널별 예약 현황인지, 특정 구간의 취소 증가 원인인지, 부가서비스 구매 기회인지에 따라 필요한 데이터와 집계 기준이 달라집니다. 같은 예약 건수라도 예약 생성 시점 기준인지, 결제 완료 기준인지, 이용 완료 기준인지에 따라 값이 달라질 수 있습니다.
첫 산출물은 화면 시안이 아니라 지표 정의서여야 합니다. 지표마다 다음을 한 줄씩이라도 정리합니다.
- 지표가 답해야 하는 업무 질문
- 분자와 분모, 집계 단위
- 기준 날짜와 시간대
- 포함·제외 조건
- 취소, 환불, 중복, 테스트 데이터 처리 방식
- 원본 데이터의 테이블과 컬럼 후보
- 수치를 보고 결정할 수 있는 담당자와 행동
이 문서가 없다면 AI는 그럴듯한 차트와 SQL을 만들 수 있어도, 조직이 같은 숫자를 보고 같은 의미로 해석하게 만들지는 못합니다.
직접 구축을 고려해도 되는 조건은 비교적 분명합니다. 데이터 범위가 한정돼 있고, 업무 담당자가 지표의 정의와 예외를 설명할 수 있으며, 결과를 기존 보고서나 원본 조회로 대조할 수 있을 때입니다. 반대로 “매출”, “활성 고객”, “전환” 같은 단어를 부서마다 다르게 쓰는 상태라면 구현 전에 정의를 합의해야 합니다.
데이터 구조를 읽을 수 있어야 AI가 만든 SQL도 검토할 수 있다
레거시 데이터베이스에는 이름이 비슷한 테이블과 더 이상 쓰지 않는 컬럼이 섞여 있을 수 있습니다. 접근 가능한 테이블이 많다고 해서 모두 대시보드에 필요한 것은 아닙니다. 한 사례에서는 약 100개 테이블을 살펴본 뒤 실제 분석에 쓴 테이블이 전체의 약 10% 수준이었습니다.
이 단계에서 만들어야 할 산출물은 데이터 관계도와 기준 엔터티 목록입니다. 기준 엔터티는 집계의 출발점이 되는 단위입니다. 예약 대시보드라면 예약 한 건인지, 승객 한 명인지, 결제 한 건인지부터 정해야 합니다.
특히 다음 관계는 SQL 오류를 자주 만듭니다.
- 예약 1건에 승객 여러 명이 연결되는 구조
- 주문 1건에 상품 행과 할인 행이 여러 개 붙는 구조
- 고객 1명에 이벤트 로그가 반복적으로 쌓이는 구조
- 취소·변경 이력이 원 거래와 별도 행으로 관리되는 구조
AI가 여러 테이블을 연결할 때 이런 일대다 관계를 고려하지 않으면 금액이나 건수가 부풀려질 수 있습니다. 화면의 숫자가 자연스럽게 보여도 맞는 숫자라는 뜻은 아닙니다.
업무 부서가 직접 만들려면 최소한 다음 질문에 답할 수 있어야 합니다.
- 이 지표는 어느 테이블의 어느 행을 한 건으로 세는가.
- 조인 뒤 행 수가 늘어나는 이유는 무엇인가.
COUNT,COUNT DISTINCT, 금액 합계를 각각 언제 써야 하는가.- 취소·환불·수정 이력은 어느 시점의 값으로 반영하는가.
- 원본 조회 결과와 다르면 어느 단계부터 비교할 것인가.
이 질문에 답하기 어렵다면 SQL 작성을 AI에 맡기는 것보다 데이터 엔지니어 또는 개발팀과 기준 모델을 먼저 만드는 편이 낫습니다.
직접 구축의 경계는 ‘읽기 전용’과 ‘되돌릴 수 있음’에서 정한다
업무 부서가 AI를 활용해 만들기 좋은 첫 대시보드는 원칙적으로 읽기 전용 분석 화면입니다. 운영 DB의 데이터를 수정하지 않고, 조회 범위도 필요한 테이블과 컬럼으로 제한합니다.
권한 설계에서는 화면 사용자와 데이터 조회 계정을 구분해야 합니다. 대시보드가 많은 사람이 보는 화면이라고 해서 그 화면을 실행하는 계정에 광범위한 데이터베이스 권한을 줄 이유는 없습니다. 조회 계정은 필요한 데이터만 읽도록 최소 권한으로 구성하고, 가능하면 운영 트랜잭션 처리와 분리된 분석용 환경을 사용합니다.
SQL에는 또 다른 경계가 있습니다. 사용자가 입력한 기간, 조직, 상품명 같은 값을 SQL 문자열에 이어 붙이면 입력값이 쿼리 문법으로 해석될 위험이 생깁니다. 값은 파라미터로 바인딩하고, 정렬 기준이나 대상 컬럼처럼 파라미터로 처리할 수 없는 구조 선택은 애플리케이션이 관리하는 허용 목록에서 고릅니다.
다음 조건 중 하나라도 해당하면 개발팀 또는 외부 전문 인력의 검토를 거치는 편이 안전합니다.
- 고객 식별 정보, 결제 정보, 인사 정보처럼 접근 자체가 제한돼야 하는 데이터가 포함된다.
- 대시보드에서 승인, 가격 변경, 재고 조정, 고객 상태 변경 등 쓰기 작업을 실행한다.
- 여러 원천 시스템의 데이터를 실시간 또는 준실시간으로 결합해야 한다.
- 부서별 권한, 행 단위 데이터 제한, 접근 기록 관리가 필요하다.
- 수치 오류가 계약, 정산, 규제 보고, 고객 안내로 이어질 수 있다.
- 조회량이 많아 운영 시스템 성능에 영향을 줄 가능성이 있다.
이 항목들은 AI 활용의 금지 조건이라기보다, 프로토타입을 운영 시스템으로 승격하기 전에 설계 책임자를 분명히 해야 하는 조건입니다.
검증은 배포 직전 단계가 아니라 별도 작업으로 계획한다
AI가 만든 SQL은 테스트 데이터에서는 맞아 보이지만, 실제 데이터의 중복·누락·상태 변경을 만나면 달라질 수 있습니다. 한 구축 사례에서도 구현보다 SQL 검증에 더 긴 시간이 들었고, 특히 일대다 테이블을 그대로 연결한 초기 쿼리에서 원본 값과 맞지 않는 문제가 나타났습니다.
검증 산출물은 지표별 대사 기록입니다. 화면을 보며 “대체로 맞는다”고 판단하지 말고, 각 핵심 지표에 대해 독립 쿼리 또는 기존 기준 보고서와 비교한 결과를 남깁니다.
검증 순서는 다음과 같이 잡을 수 있습니다.
- 작은 기간과 제한된 조건으로 표본을 고른다.
- 기준 엔터티의 원본 건수를 먼저 확인한다.
- 조인을 하나씩 추가하면서 행 수와 합계가 어떻게 변하는지 기록한다.
- 대시보드 쿼리와 독립 검증 쿼리의 결과를 대조한다.
- 취소, 환불, 중복, 미완료 상태 등 예외 사례를 따로 확인한다.
- 값이 다를 때 어느 정의가 업무상 올바른지 지표 정의서에 반영한다.
여기서 중요한 점은 검증자가 쿼리 작성자와 같은 판단을 반복하지 않는 것입니다. 가능하면 업무 담당자는 지표 정의와 예외 처리의 타당성을 확인하고, SQL을 이해하는 담당자는 조인과 집계 방식을 검토합니다. 둘 중 한 역할이 비어 있으면 화면이 맞아 보여도 운영 판단의 근거로 쓰기 어렵습니다.
운영 전 승인 경계를 문서로 남긴다
대시보드가 배포된 뒤에는 숫자가 바뀌는 이유를 설명할 수 있어야 합니다. 데이터 적재 지연, 원천 시스템의 상태 변경, 지표 정의 수정, 권한 변경이 발생하면 같은 화면도 전날과 다른 값을 보일 수 있습니다.
운영 전에는 다음 네 가지를 정해 둡니다.
- 데이터 책임자: 원본 데이터의 의미와 상태값을 확인할 사람
- 지표 책임자: 지표 정의 변경을 승인할 사람
- 기술 책임자: 쿼리, 권한, 배포 변경을 검토할 사람
- 업무 승인자: 이 수치를 근거로 어떤 결정을 내려도 되는지 정할 사람
업무 부서가 직접 만든 대시보드라도 이 네 역할을 한 사람이 모두 맡아야 한다는 뜻은 아닙니다. 다만 책임자가 비어 있으면 오류가 발견됐을 때 수정할 사람도, 수치를 일시 중단할 사람도 불분명해집니다.
첫 배포는 모든 지표를 담은 완성형 화면보다, 정의와 검증이 끝난 소수의 핵심 지표에서 시작하는 편이 관리하기 쉽습니다. 이후 사용자가 실제로 내린 결정, 반복적으로 제기된 해석 질문, 데이터 불일치 사례를 모아 다음 범위를 결정합니다.
AI 대시보드 구축을 시작하기 전 회의에서는 “무엇을 만들어 줄 수 있는가”보다 이 질문부터 합의해 보십시오. 이 숫자가 틀렸을 때 누가 어떤 결정을 멈추고, 어떤 원본 데이터까지 돌아가 확인할 것인가. 그 답이 정리된 업무라면 직접 구축의 출발선에 가깝습니다. 답이 없다면 코드를 더 빨리 만드는 일보다 데이터 정의와 책임 경계를 먼저 설계해야 합니다.
