기준: 요즘IT 기고(2026년 11월 3일 게시, 항공 서비스 조직의 인하우스 IT 기획자 본인 경험) · 기간은 영업일 기준, 업무 틈틈이 · 분석 1주 · 설계 3일 · 구현 2일 · 검증 2주 · 도구 VS Code + Claude Code

"개발 리소스가 없어서 못 해요." 회사에서 데이터 화면 하나 만들자고 하면 자주 듣는 말입니다. 요즘IT에 실린 한 기고는 이 말을 조금 다르게 풀었습니다. 항공 서비스 조직의 인하우스 IT 기획자가 몇 년째 밀려 있던 예약 데이터 대시보드를 AI 코딩 도구로 직접 만들어 사내에 배포했다는 이야기입니다.
눈에 띄는 숫자는 기간입니다. 코드를 만드는 구현은 2일이었지만, 화면의 숫자가 맞는지 확인하는 검증에 2주가 들었습니다. 이 글에서는 글쓴이가 밝힌 과정을 따라 하기 좋은 순서로 정리합니다. 위 화면을 포함해 이 글의 대시보드 · 숫자 화면은 모두 설명을 위해 새로 만든 가상 예시이고, 원문 글의 그림이나 실제 회사 데이터가 아닙니다.
얼마나 걸렸고, 어디에 시간이 들었나요?
전체 약 4주 가운데 절반이 검증이었습니다. 글쓴이가 밝힌 기간은 분석 1주, 설계 3일, 구현 2일, 검증 2주입니다. 모두 영업일 기준이고, 본업을 하면서 틈틈이 진행한 기간입니다.

| 단계 | 기간(영업일) | 한 일 |
|---|---|---|
| 분석 | 1주 | DB 구조를 보고 실제로 쓰는 테이블 · 컬럼 찾기 |
| 설계 | 3일 | 어떤 지표를 어느 화면에 둘지 정하기 |
| 구현 | 2일 | AI 코딩 도구로 화면 · 쿼리 만들기 |
| 검증 | 2주 | 화면 숫자를 직접 뽑은 값과 대조 |
"코딩을 몰라도 이틀 만에 완성"이라는 이야기로 읽으면 안 됩니다. 이틀은 구현만의 기간이고, 그 앞뒤의 분석 · 설계 · 검증에 훨씬 많은 시간이 들었습니다. 서버와 권한도 사람의 도움을 받았습니다.
맨 처음엔 무엇부터 했나요?
데이터 지도부터 그렸습니다. 글쓴이는 DB 구조를 살펴보는 화면을 먼저 만들어 어떤 테이블과 컬럼이 실제로 쓰이는지 파악했습니다. 테이블은 100개 가까이 있었지만, 대시보드에 실제로 쓴 것은 10% 안팎이었다고 합니다.

이 단계에서 지킨 원칙이 하나 있습니다. DB는 읽기 전용 권한으로만 봤다는 점입니다. AI 코딩 도구가 쿼리를 만들고 실행하더라도 데이터를 바꾸거나 지울 수 없게 해 두는 것이 먼저입니다. 테이블이 많은 회사라면 "전부 이해하겠다"보다 "실제로 쓰는 10%를 찾겠다"가 현실적인 목표입니다.
지표는 어떤 기준으로 골랐나요?
"이 숫자를 보고 무엇을 바꿀 수 있나"가 기준이었습니다. 보기만 하고 아무 행동으로도 이어지지 않는 숫자는 첫 화면에서 뺐습니다.

그래서 첫 화면에는 판매와 바로 이어지는 지표만 두고, 나머지 상세 지표는 따로 볼 수 있게 나눴습니다. 대시보드를 처음 만들 때 흔히 하는 실수가 볼 수 있는 숫자를 다 올리는 것인데, 그러면 정작 매일 봐야 할 숫자가 묻힙니다.
AI에게 쿼리를 맡길 때 무엇을 알려 줘야 하나요?
네 가지를 함께 줍니다. 데이터 구조, 연결 방식, 집계 단위, 기대 결과입니다. 글쓴이는 이런 지침 없이 맡겼을 때 값이 맞지 않았고, 맥락을 준 뒤에야 값이 일치했다고 밝혔습니다.

- 데이터 구조: 어떤 테이블의 어떤 컬럼을 쓰는지. 앞에서 만든 데이터 지도가 여기서 쓰입니다.
- 연결 방식: 테이블을 어떻게 잇는지. 예를 들어 "중복을 먼저 없앤 뒤 조인한다".
- 집계 단위: 무엇을 하나로 셀지. 예약 한 건 기준인지, 승객 한 명 기준인지에 따라 숫자가 달라집니다.
- 기대 결과: 결과가 어떤 조건을 만족해야 하는지. 예를 들어 "부분 합을 더하면 전체와 같아야 한다".
글쓴이는 VS Code와 Claude Code를 썼다고 밝혔지만, 이 네 가지는 어떤 AI 코딩 도구에 맡기든 똑같이 통하는 내용입니다. 특히 집계 단위는 사람끼리도 자주 엇갈리는 부분이라, 말로 정해 두지 않으면 AI가 그럴듯하지만 다른 기준으로 숫자를 만듭니다.
화면의 숫자가 맞는지는 어떻게 확인했나요?
화면에 나온 숫자를 직접 뽑은 값과 하나씩 대조했습니다. 이 작업이 2주 걸린 검증 단계입니다.


위 두 화면은 그 과정을 보여 주려고 만든 가상 예시입니다. 글쓴이가 다음에 바꾸겠다고 한 점도 있습니다. 검증을 시작하기 전에 "합이 맞아야 하는 기준값"을 먼저 정해 두는 것입니다. 예를 들어 노선별 예약을 더하면 전체 예약과 같아야 한다는 식의 기준을 미리 적어 두면, 숫자가 틀렸을 때 바로 알아챌 수 있습니다.
서버와 권한은 누가 맡았나요?
서버 · 권한 · 보안은 인프라팀과 개발자에게 요청했습니다. 사내 배포에는 내부망과 VPN 같은 보안 조건이 따르기 때문에, 기획자 혼자 AI로 해결할 부분이 아니었습니다.

글쓴이의 결론은 AI가 개발자를 대신한다는 것이 아니었습니다. 개발자에게 넘기기 전에 먼저 만들어 보는 단계를 하나 더 만들어 준다는 것입니다. 이미 돌아가는 화면과 검증한 숫자를 들고 가면, 인프라팀 · 개발자와 이야기할 때도 무엇이 필요한지 분명해집니다.
한 번에 정리
- 기간: 분석 1주 · 설계 3일 · 구현 2일 · 검증 2주(영업일, 업무 틈틈이). 검증이 절반입니다.
- 데이터 지도부터: 테이블 100개 가까이 중 실제로 쓴 건 10% 안팎. 읽기 전용 권한으로만.
- 지표 기준: "이 숫자로 무엇을 바꿀 수 있나". 첫 화면엔 판매 직결 지표만.
- 쿼리 맡길 때 줄 4가지: 데이터 구조 · 연결 방식(중복 제거 후 조인) · 집계 단위(예약 · 승객 기준) · 기대 결과(부분 합 = 전체).
- 검증: 화면 숫자는 직접 뽑은 값과 대조하고, 합이 맞아야 할 기준값을 먼저 정해 둡니다. 서버 · 권한 · 보안은 사람에게 요청합니다.
다음 글에서는 AI 코딩 도구로 사내 도구를 만들 때 권한을 어떤 순서로 요청하면 좋을지 정리합니다.
출처
- 요즘IT 기고, 인하우스 IT 기획자 본인 경험(2026년 11월 3일 게시): https://yozm.wishket.com/magazine/detail/4021/
- 이 글의 대시보드 · 데이터 지도 · 숫자 대조 화면은 설명용으로 새로 만든 가상 예시입니다. 내용은 글쓴이 한 사람의 경험입니다.
- 영상으로 보기: AItoZ 유튜브 쇼츠 'AI로 사내 대시보드 만들기 — 비개발 기획자가 배운 4가지'
