엑셀 너머 대시보드 ① HTML 한 장과 다시 도는 판을 가르는 4개 층

먼저 결론

• 원천 엑셀은 입력물로만 쓰고, 받는 곳에서 끝냅니다.
• 저장소는 분석용 DB와 앱 상태용 DB로 나눕니다.
• 숫자 계산은 화면이 아니라 SQL 한곳에 모읍니다.
• 화면은 묻기만 하고, 서버에 올리면 권한과 개인정보가 따라옵니다.

HTML 한 장에는 데이터와 계산과 화면이 묶여 있었다

AI가 만든 HTML 대시보드는 데이터, 계산, 화면이 한 파일에 섞인 결과물입니다. 그래서 셋 중 하나만 바뀌어도 전체를 다시 만들어야 합니다.

이번 달 실적이 나오면 데이터를 다시 넣습니다. 기준이 바뀌면 계산을 다시 요청합니다. 표 하나를 옮기려 해도 파일 전체를 다시 받습니다.

숫자를 확인할 방법도 없습니다. AI가 합계를 어떻게 냈는지 파일 안에 숨어 있습니다. 엑셀 피벗과 숫자가 다르면 어느 쪽이 맞는지 따질 근거가 없습니다.

고객 정보가 든 엑셀을 넣었다면 그 정보가 HTML 안에 그대로 남습니다. 그 파일이 메일이나 메신저로 돌아다닙니다.

판을 만든다는 것은 이 셋을 떼어 놓는 일입니다. 데이터는 매달 갈아 끼우고, 계산은 규칙으로 한 번 정해 둡니다. 화면은 그 결과를 보여 주기만 합니다.

1. 엑셀은 읽자마자 다른 형식으로 바꿔야 했다

원천 데이터는 사내 시스템에서 내려받는 엑셀 파일입니다. 제 경우에는 실적 2종, 마감(지급·환수), 인사, 보증까지 5종이었습니다. 이 파일들을 정해진 폴더에 넣으면 프로그램이 읽어서 다음 층으로 넘깁니다.

엑셀을 원천으로 고른 이유는 데이터 담당자가 이미 매달 내려받는 파일이기 때문입니다. 새 데이터를 만들 필요가 없습니다. 하던 일의 마지막 단계만 "폴더에 넣기"로 바꾸면 됩니다.

파일 이름 규칙으로 종류를 자동으로 구분합니다. 처리한 파일은 날짜별 보관 폴더로 옮겨 이력을 남깁니다. 같은 달 파일을 다시 넣으면 교체할지 누적할지는 종류별로 정해 둡니다.

문제는 엑셀의 셀 형식이 제각각이라는 점입니다. 그대로 저장소로 쓰면 반드시 꼬입니다. 같은 계약번호 열이 어떤 달은 숫자로, 어떤 달은 문자로 읽히는 일이 실제로 있었습니다.

그래서 저는 엑셀을 읽자마자 정리된 형식으로 바꾸게 했습니다. 그 뒤로는 다시 엑셀을 열지 않는 구조입니다.

2. 실적과 계정은 같은 DB에 두면 안 됐다

저장소는 정리된 데이터를 쌓아 두는 곳입니다. 저는 두 가지를 나눠 썼습니다. 계약·실적처럼 양이 많은 데이터는 분석용 DB(DuckDB)에 둡니다. 사용자 계정·설정·예외 처리처럼 앱이 기억할 것은 앱 상태용 DB(SQLite)에 둡니다.

나눈 이유는 두 데이터가 바뀌는 주기와 방식이 다르기 때문입니다. 실적 데이터는 매달 통째로 다시 만들어도 됩니다. 사용자 계정은 다시 만들면 안 됩니다.

분석용 DB는 계약 단위 데이터를 바로 집계할 만큼 빠릅니다. 앱 상태 DB는 실적을 다시 적재해도 지워지지 않습니다. 둘을 나누면 실적 DB만 새로 만들어 서버에 올리는 배포도 쉬워집니다.

주의할 점도 있습니다. DB 파일은 한 프로그램이 쓰는 동안 다른 프로그램이 함부로 건드리면 안 됩니다. 저는 화면을 켠 채 데이터를 적재하다가, 화면이 예전 숫자를 보여 주는 문제를 겪었습니다. 이 과정은 2편에서 자세히 다룹니다.

3. 숫자 규칙은 SQL 파일 하나에 모았다

계산 층은 저장된 데이터를 보고용 숫자로 바꾸는 규칙 모음입니다. 저는 모든 집계 SQL을 파일 하나에 모았습니다. 원천 그대로(1단계) → 조직 분류를 붙인 것(2단계) → 보고용 표(3단계) 순서로 쌓습니다.

같은 "실적"이라도 보고마다 정의가 다릅니다. 대시보드는 자기계약을 포함하고, 평가는 제외하는 식입니다. 규칙이 화면마다 흩어져 있으면 두 화면의 숫자가 왜 다른지 찾을 수 없습니다.

한곳에 모으면 숫자가 이상할 때 볼 곳이 한 군데입니다. 규칙을 바꾸면 모든 화면에 같이 반영됩니다. 손계산과 대조하는 검증을 붙이기도 쉽습니다.

SQL은 AI가 잘 써 줍니다. 하지만 숫자의 정의는 AI가 정할 수 없습니다.

무엇을 포함하고 뺄지는 업무를 아는 사람이 먼저 문서로 정해야 합니다. 저는 정의를 문서로 남긴 뒤 SQL을 쓰게 했습니다. 결과는 한 사람의 한 달 값으로 손계산과 대조했습니다.

4. 화면이 계산을 모르면 디자인을 갈아엎어도 숫자는 남는다

화면은 사용자가 보는 대시보드입니다. 서버는 그 화면을 여러 사람이 접속할 수 있게 띄워 두는 컴퓨터입니다.

화면과 DB 사이에는 조회 함수가 한 겹 있습니다. "조직별 실적 줘" 같은 질문을 받아 계산 층의 결과를 돌려줍니다.

화면이 계산을 모르면 화면을 갈아엎어도 숫자 규칙은 그대로 남습니다. 저도 화면 구성과 디자인을 여러 번 바꿨습니다. 그때 고친 곳은 화면 파일뿐이었습니다.

메뉴 하나에 화면 파일 하나로 나눠 고칠 곳을 좁혔습니다. 로그인과 권한으로 사람마다 볼 수 있는 메뉴와 조직을 나눴습니다. 데이터를 새로 적재하면 화면은 손대지 않아도 갱신됩니다.

서버에 올리는 순간 내 PC에서는 없던 문제가 생깁니다. 누가 접속하는지, 서버에 개인정보가 올라가는지, 여러 명이 동시에 열면 버티는지를 모두 따져야 합니다. 이 부분은 3편에서 다룹니다.

판을 한 번 만들고 나니 데이터만 갈아 끼우면 보고가 나왔다

실제 프로젝트에서 이렇게 나눈 결과는 세 가지입니다.

신인 지원금 평가는 대상자 명단을 올리면 차월별 실적, 지급 여부, 환수 대상이 자동으로 계산됩니다. 마감 데이터가 새로 들어오면 별도 요청 없이 다음 차월이 채워집니다.

월별 평가 확정본은 마감 데이터를 적재할 때마다 그달 평가 결과를 따로 저장하게 했습니다. 나중에 기준이 바뀌어도 당시 확정 숫자를 다시 볼 수 있습니다.

마감보고는 조직별 집계표를 화면에서 바로 봅니다. 필요하면 엑셀로 내려받습니다.

엑셀을 AI에 넣어 HTML을 받는 방식은 첫 화면을 빨리 보기에는 좋습니다. 하지만 데이터, 계산, 화면이 한 파일에 묶여 있어 매달 같은 요청을 반복하게 됩니다. 원천, 저장소, 계산, 화면으로 층을 나누면 다음 달부터는 파일을 폴더에 넣는 것으로 끝납니다.

다음 편에서는 엑셀을 DB로 옮기고 숫자 규칙을 맞추면서 막혔던 일을 시간 순서대로 적습니다. 매달 반복하는 보고 하나를 원천, 계산, 화면으로 나눠 적어 두면 2편이 더 잘 읽힙니다.