인하우스 IT 기획자가 AI로 대시보드 만들며 배운 4가지

“솔루션 업체에 가능한지부터 확인해 봐야 한다.”

인하우스 IT 조직에서 일하다 보면 이런 말을 정말 자주 들으셨을 겁니다. 제가 말하는 IT 조직은 일반적인 IT 기업 안의 IT팀이 아니라, 본업을 돌아가게 만드는 사내 지원 조직에 가깝습니다. 그래서 새로운 걸 처음부터 설계하기보다, 이미 깔린 시스템 위에서 최대한 잘 돌아가게 만드는 일이 훨씬 많습니다.

제가 속한 산업군의 핵심 시스템은 PSS(Passenger Service System), 즉 항공 예약 시스템입니다. 호텔에는 객실 재고를 관리하고 아고다 같은 판매 채널에 연동하는 PMS(호텔 관리 시스템)가, 제조업에는 생산과 재무 등을 통합 관리하는 ERP(전사적 자원관리 시스템)가 있듯이, 각 업종마다 전 세계에서 통용되는 표준 솔루션이 있고 많은 조직이 이러한 표준 솔루션을 도입해서 쓰고 있습니다.

이 글에서는 이렇게 핵심 업무를 처리하고 원본 데이터가 쌓이는 시스템을 ‘원천 시스템’이라고 부르겠습니다.

대부분의 원천 시스템은 한번 도입하면 그 위에 다른 시스템이 쌓이기 때문에, 새로운 걸 하려면 솔루션 업체에 가능한지부터 확인해야 합니다. 제가 속한 항공 서비스 조직도 다르지 않습니다.

이 글은 그런 환경에서, 개발 리소스를 기다리는 대신 기획자인 제가 AI와 함께 직판(홈페이지와 앱) 데이터를 분석하는 대시보드를 직접 만든 경험을 기록한 글입니다. 제가 속해있는 산업군에 대한 이야기도, 요즘 쏟아지는 ‘AI가 대신 개발해 준 이야기(바이브 코딩)’도 아닙니다. 문제를 정의하고, 데이터 구조를 이해하고, 화면으로 설계하고, 결과물을 검증하는 과정에서 기획자가 실제로 무엇을 했는지에 대한 이야기입니다. AI는 도구일 뿐, 어떤 데이터를 어떤 순서로 보여줄지 판단하는 건 여전히 기획자의 몫이었습니다.

몇 년째 ‘있으면 좋지만 지금은 만들 수 없는 것’으로 남아 있던 대시보드를 업무 틈틈이 만들어 사내 배포까지 했습니다. 그런데 가장 오래 걸린 건 코드가 아니라 검증이었습니다. 데이터 구조를 이해하는 일, 지표를 고르는 기준, AI가 짠 코드의 검증, 그리고 사람에게 도움을 청해야 하는 지점까지, 만들며 배운 4가지를 정리했습니다.

넘치는 데이터 속 숨어 있는 필요 데이터

만들어야겠다고 생각한 대시보드로 보고 싶었던 건 홈페이지와 앱에서 예약하는 고객이 어떤 여정을 거치는지였습니다. 홈페이지를 운영하고 고도화하는 기획자로서 꼭 알아야 하는 데이터였습니다.

문제는 고객 한 명의 여정이 예약 하나로 끝나지 않는다는 점이었습니다. 예약, 결제, 취소, 부가서비스 구매, 체크인, 탑승까지 이어지고, 리드타임이나 노선, 채널(직판, 여행사 등)에 따라 그 흐름도 계속 달라집니다. 게다가 이 데이터들은 한곳에 예쁘게 모여 있지 않습니다. 홈페이지와 앱에서 일어난 예약과 구매는 홈페이지 데이터베이스에, 모든 판매 채널의 원본 데이터는 원천 시스템에, 결제 데이터는 수입관리 시스템에 따로 저장됩니다.

물론, 가시화된 데이터가 전혀 없었던 건 아닙니다. 원천 시스템의 원본 데이터는 이미 비즈니스 인텔리전스(BI) 툴을 통해 세일즈 관점에서 보고 있었지만, 그건 직판과 여행사 등 모든 판매 채널을 합친 실적 관점이었습니다. 홈페이지 데이터도 GA(구글 애널리틱스)와 빅쿼리(구글의 데이터 분석 도구)로 이미 보고 있었습니다. 다만 GA는 방문, 클릭, 유입 경로처럼 고객이 홈페이지에서 어떻게 행동했는지를 이벤트로 수집해서 보여주는데 특화된 도구입니다. 제가 보고 싶었던 건 그와 별개로, 실제 DB에 기록된 예약과 구매 결과를 노선, 동반 인원, 예약 시점 등과 같은 기준으로 나눠 보는 것이었습니다.

전체 채널을 합친 세일즈 숫자는 있어도, 홈페이지와 앱을 통해 예약하고 이용하는 고객의 흐름을 직관적으로 확인하고 비교할 수 있었던 화면은 없었던 셈입니다. 그래서 이번에는 읽고, 분석할 데이터의 범위를 홈페이지 DB로 정했습니다.

탑승(출입국)처럼 홈페이지와 앱이 관여하지 않는 단계의 데이터는 원천 시스템에 따로 있기 때문에, 대시보드는 홈페이지와 앱에서 일어나는 구간을 다루는 것으로 목적을 분명히 했습니다.

제가 아니더라도, 필요성은 모두가 알고 있었습니다. 항상 그렇듯 한정된 자원에서 문제는 늘 우선순위였습니다. 조직에서 개발 리소스는 언제나 운영 이슈와 핵심 프로젝트에 먼저 배정됐습니다. 게다가 이러한 자체 분석 대시보드를 만들려면 많은 비용과 리소스가 드는 일이었습니다. 그렇게 이 대시보드는 몇 년째 ‘있으면 좋지만 지금은 만들 수 없는 것’으로 남아 있었습니다.

1. 프롬프트보다 중요한 건 데이터 구조의 이해다

처음부터 운영에 쓸 대시보드를 만들겠다는 계획은 아니었습니다. 당시 저는 AI를 업무에 어떻게 활용해야 그 효과를 극대화할 수 있을지 스스로 스터디하며 이것저것 실험해보던 시기였습니다. 문서를 작성하는 수준을 넘어 ‘기획자가 AI를 활용해서 어디까지 직접 만들 수 있을까’를 시험해보고 싶었습니다. 마침 필요하다는 걸 모두가 알지만 계속 밀려나던 직판 데이터 분석 대시보드가 있었고, 개발 리소스가 배정되기를 기다리는 대신 일단 최소 기능 제품(MVP)부터 만들어보기로 했습니다. 본업이 아니라서, 업무 사이사이 시간이 날 때마다 틈틈이 진행한 작업이었습니다.

VS Code와 Claude Code를 열고 가장 먼저 한 일은 화면을 만드는 것이 아니라 데이터를 이해하는 것이었습니다. 어떤 데이터를 보여줄지부터 다시 정의해야 했습니다. 읽을 범위는 홈페이지 DB로 정했으니, 그 안에서 무엇을 어떻게 보여줄지를 정해야 했습니다. 예약 현황만 볼 것인지, 승객과 노선, 부가서비스 구매까지 하나의 흐름으로 볼 것인지를 먼저 결정했습니다.

문제는 데이터 구조였습니다. 접근할 수 있는 테이블이 100개 가까이 되는 상황에서 어떤 테이블을 써야 하는지부터 직접 찾아야 했습니다. AI에게 “SQL을 짜달라”고 요청해도, 어떤 테이블에 무슨 데이터가 있는지, 어떤 컬럼이 실제로 쓰이는지를 제가 모르면 AI도 정확한 쿼리를 만들어줄 수 없었습니다. 결국 테이블과 컬럼을 하나씩 분석하며 관계를 추론하는 일은 제가 직접 해야 했습니다. 여기에 데이터 자체가 암호화되어 있는 경우가 많아서 분석하고 이해하는데 어려움이 더 컸습니다.

같은 작업을 반복해야 하는 상황이 잦아지자 아예 데이터베이스 메타데이터를 탐색할 수 있는 화면을 직접 만들었습니다. 이렇게 분석해 보니 실제로 쓴 테이블은 전체의 10% 안팎이었습니다. 예약 정보를 담은 테이블이 모든 집계의 기준이었고, 여기에 승객, 여정, 부가서비스, 회원 정보 테이블을 연결하는 구조였습니다. 애당초 기획자인 저에게는 시스템의 읽기(Read) 권한만 부여되어 있기도 했지만, 잦은 조회와 테스트가 원본 운영 DB에 부하를 주지 않도록 처음부터 철저히 읽기 전용 환경을 바라보도록 설계했습니다.

필요한 데이터를 조합할 구조를 정리한 뒤에야 쿼리를 작성할 수 있었습니다. 원하는 결과가 한 번에 나오는 경우는 거의 없었습니다. 더미 데이터를 먼저 만들어 테이블이 어디서 연결되는지 파악했고, 그 뒤에는 정확한 데이터가 나올 때까지 쿼리를 수정하고 확인하는 일을 반복했습니다. AI가 코드를 짤 줄 안다고 해서 이 과정이 짧아지는 건 아니었습니다. 무엇을 연결해야 하는지, 그 결과가 맞는지를 판단하는 건 데이터를 직접 들여다본 사람만 할 수 있었습니다.

2. 예쁜 화면보다 행동으로 이어지는 지표가 먼저다

데이터 구조가 정리된 뒤에는 ‘이 데이터를 어떻게 보여줘야 실제 의사결정에 도움이 될까’를 고민했습니다. 기획자로서 저는 이 대시보드가 직판 홈페이지의 판매율을 높이는 데 도움이 되었으면 좋겠다고 생각했습니다. 그렇다면 현황을 보여주는 데서 끝나면 안 되고, 보는 사람이 개선안을 바로 떠올릴 수 있어야 합니다. 전체 채널의 실적을 보여주는 화면은 이미 BI 툴에 있었습니다. 제가 필요했던 건 어디를 고치면 판매율이 오를지를 가리키는 화면이었습니다.

그래서 지표를 고르는 기준도 ‘중요해 보이는가’가 아니라 ‘이 숫자를 보고 무엇을 바꿀 수 있는가’였습니다. GA4 같은 행동 분석만으로는 판매율을 높이는 개선안을 구체화하기에 부족하다고 생각했습니다. 노선별, 동반 인원 규모별로 구매하는 방식이 다르다면 개선도 그 기준에 맞춰 따로 해야 하기 때문입니다. 그래서 구매 패턴이 갈리는 지점마다 그에 맞는 분석이 따로 필요하다고 판단했고, 화면을 그 기준으로 나눠 설계했습니다.

첫 화면에는 판매와 직결되는 지표만 뽑아서 올리고, 더 보고 싶은 사람이 상세 화면으로 들어가게 했습니다. 상세 화면에서는 예약 비중과 매출 비중을 위아래 두 막대로 나란히 놓았습니다. 예약 건수는 적어도 매출 기여가 큰 구간을 찾으면, 개선에서 어디부터 손대야 하는지 우선순위를 바로 정할 수 있기 때문입니다. 노선, 동반 인원, 예약 시점별 등 세부 분석화면에 같은 방식을 반복해서 썼습니다.

* 산업군이나 서비스 성격에 따라 유의미한 데이터 관점은 달라지므로, 이 글에서는 기획 의도를 보여주기 위한 가상의 예시를 활용했습니다.

데이터가 얼마나 예쁘게 보이는지보다, 이 대시보드를 쓸 사용자가 필요한 정보를 얼마나 빠르게 찾고, 비교하고, 다음 질문으로 이어갈 수 있는지가 더 중요하다고 생각했습니다. 이 판단에는 그동안 UI/UX 기획과 서비스 정책 정의를 하며 쌓아온 경험이 가장 많이 쓰였습니다. 기획안을 개발자에게 전달하고 화면이 나오기를 기다리는 대신, 기획한 사람이 그대로 화면설계하고, 구현까지 할 수 있게 된 것 입니다.

3. 맥락을 주고 검증하는 건 기획자의 몫이다

구현까지 끝나고 나서 가장 오래 걸린 건 검증이었습니다. 본업을 하면서 짬짬이 진행한 기간이라, 영업일 기준 경과 기간으로 보면 분석에 1주, 설계에 3일, 구현에 2일이 걸렸고 검증에만 2주가 걸렸습니다. 전체 기간의 절반입니다.

방법은 단순했습니다. 대시보드에 나온 수치를 실제 DB에서 제가 직접 쿼리를 짜서 조회한 값과 대조했습니다. 화면에 숫자가 나오는 것만으로는 그 숫자가 맞는지 알 수 없었기 때문입니다.

대조해 보니 처음에는 값이 맞지 않았습니다. 테이블을 어떻게 연결할지 따로 지침을 주지 않고 AI에게 쿼리를 맡겼더니, 결과가 원본과 완전히 어긋나 있었고 중복된 값도 하나도 일치하지 않았습니다. 원인은 예약 한 건에 승객, 여정, 부가서비스가 여러 행으로 붙어 있는데, 이 관계를 고려하지 않고 테이블을 연결한 데 있었습니다. 그래서 메타데이터 화면에서 파악한 데이터 구조를 정리해서 전달하고, 기본키(PK) 기준으로 중복을 제거해 조인(JOIN)으로 묶으라는 지침을 더했습니다. 예약 기준으로 집계할지 승객 기준으로 집계할지 집계 단위도 못 박고, 기대하는 결과값 예시를 함께 주자 그 뒤에야 대조 결과가 맞았습니다.

대처 전: 지침 없이 맡긴 요청

“예약, 승객, 부가서비스 데이터를 합쳐서 노선별 예약 건수와 매출을 구하는 SQL을 짜줘.”

대처 후: 맥락을 정리해서 준 요청

• 데이터 구조: 예약 한 건에 승객과 부가서비스가 여러 행으로 연결됨
• 연결 방식: 각 테이블은 기본키(PK) 기준으로 중복을 제거한 뒤 조인(JOIN)으로 묶을 것
• 집계 단위: 예약 건수는 예약 기준, 매출은 승객 기준으로 집계할 것
• 기대 결과: 노선별 예약 건수를 모두 더하면 전체 예약 건수와 같아야 함

(실제 사용한 프롬프트가 아니라 설명을 위해 만든 예시입니다.)

AI가 SQL 문법을 틀린 건 아니었습니다. 제가 테이블 사이의 관계와 집계 기준을 충분히 알려주지 못한 게 원인이었고, 그 맥락을 정리해서 전달하자 AI도 맞는 쿼리를 만들어 냈습니다.

(지금 생각해보면 참 무식한 방법으로 검증을 한 것 같습니다. 다음에 진행하게 된다면 지표별 집계 단위와 ‘합계가 맞아야 하는 기준값’을 먼저 정해 두고, AI가 만든 쿼리가 그 기준에 맞는지부터 확인하는 방법으로 진행할 것 같습니다.)

4. AI는 개발자를 대체하지 않고, 단계를 하나 더 만든다

검증과는 별개로, 프론트엔드 개발과 서버 배포는 저에게 완전히 새로운 영역이었습니다. 특히 배포는 방법 자체를 몰랐습니다. 그동안 만든 바이브 코딩 프로젝트는 제 컴퓨터(로컬)에서만 실행해 봤을 뿐, 서버에 올려본 적이 없었습니다. 이번 MVP도 처음에는 로컬에서 혼자 데이터를 보고 분석하는 용도였습니다.

그러다 우연한 기회에 상위 의사결정자에게 시연할 일이 생겼는데, 직판 데이터를 한 화면에서 볼 수 있다는 점과 운영·기획 관점의 직관적인 화면 구성이 좋은 반응을 얻었습니다. 이후 내부 시연으로 범위를 넓혀 사내 배포까지 이어졌습니다. 사내 구성원이 함께 써야 했기 때문에 보안이 적용된 내부망 서버에 올려야 했고, 외부 오피스에서 근무하는 팀원은 VPN(가상사설망)이 있어야만 접속되는 환경이라는 점도 고려해야 했습니다.

먼저 내부 인프라팀과 협의해 서버를 할당받았습니다. 인프라팀에는 테이블 같은 데이터 세부 내용이 필요하지 않아서, 용도와 접속 범위만 정리해서 전달했습니다. 그다음 코드를 Git에 올리고, 할당받은 서버에 올리는 순서로 진행했습니다.

회원 정보를 연결할 때는 개발자에게 접근 권한을 요청했습니다.데이터를 누구에게 보여줄지도 정해야 했습니다. 예약과 구매 데이터는 모두가 접근할 수 있는 정보가 아니기 때문에, 암호화된 데이터에서 수치만 뽑아 대시보드에 올렸고, 판매 데이터를 볼 수 있는 관계자에 한해서만 배포했습니다. 대시보드를 만들었다고 해서 데이터를 아무에게나 열어 둔 것이 아니라, 원래 판매 데이터를 볼 수 있는 사람들에게만 더 빠르게 볼 수 있는 화면을 제공한 것이었습니다.

서버와 권한은 사내 담당자에게 요청해야 풀리는 일이었습니다. AI 덕분에 직접 해볼 수 있는 범위는 넓어졌지만, 그 범위를 넘어서는 부분은 사람과 소통하며 진행했습니다. 그래서 이건 ‘AI가 개발자를 대체했다’는 이야기는 아닙니다. 정확히는, 개발자와 인프라팀에 도움을 요청하기 전에 기획자가 먼저 빠르게 MVP를 만들어 직접 검증해볼 수 있는 단계가 하나 더 생긴 것에 가깝습니다.(당연히 데이터를 더 확장하고 검증하려면 다음 단계는 개발자의 도움과 인사이트가 필수적이라는 점을 부정하는 것은 아닙니다.)

이 경험으로 알 수 있는 것

AI가 쿼리를 짜주고 화면을 만들어주는 시대가 되었다고 해서 기획자의 일이 쉬워진 건 아닙니다. 이번에 가장 오래 걸린 건 코드를 만드는 일이 아니라 그 결과가 맞는지 확인하는 일이었고, 어떤 테이블이 어떻게 연결되는지, 어떤 숫자를 어떤 순서로 보여줄지 판단하는 건 끝까지 제 몫이었습니다. 대신 기획자가 직접 확인하고 실행해 볼 수 있는 범위가 넓어졌습니다.

레거시 시스템이 두꺼운 환경일수록 ‘있으면 좋지만 지금은 만들 수 없는 것’이 쌓입니다. 막대한 비용과 시간이 들고, 개발자가 붙지 않으면 시작조차 할 수 없다고 여겨지기 때문입니다. 이제는 개발자나 인프라팀에 도움을 요청하기 전에, 기획자 혼자서도 먼저 문제를 정의하고 데이터를 파악해서 직접 만들고 검증해 볼 수 있는 환경이 생겼습니다.

이제 “개발 리소스가 없어서 못 합니다”라고 결론 내리기 전에, “내가 지금 직접 확인해볼 수 있는 데까지는 어디일까?”를 한 번 더 질문해볼 수 있게 됐습니다. 병목되어 ‘언젠가는 만들어야할 것이 있다면’ 일단 한번 시작해보는게 어떨까요?

이 글은 AI의 도움을 받아 작성했습니다.

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.