데이터 대시보드

목표

• 원천 파일만 넣으면 집계, 마감보고, 평가, 대시보드가 한 번에 만들어질 것
• 숫자의 정의(무엇을 어떻게 셀지)를 한 곳에서 관리할 것
• 조회하는 사람은 설치 없이 브라우저로, 자기 조직 범위만 볼 것
• 나중에 사내 시스템에서 데이터를 자동으로 받아오는 방식으로 바꿀 수 있는 구조일 것

만든 과정

1. 엉킨 첫 버전을 정리하다 (2026년 4~5월) 처음 만든 버전은 기능을 붙여 가는 사이에 화면 도구, 저장 방식이 문서마다 달라져 있었습니다. 4월에 "정리하고 다시 만든다"로 방향을 정하고, 흩어진 설계 문서를 대조해 무엇이 서로 안 맞는지부터 정리했습니다. 따로 시험해 둔 데이터 처리 도구(DuckDB)로 결합 작업이 12시간에서 530초로 줄어드는 것을 먼저 확인했고, 5월에 통합 설계를 확정했습니다.

• 화면은 서버 하나로 관리자와 조회자를 모두 받을 수 있는 NiceGUI
• 저장은 월별 원천은 Parquet, 집계는 DuckDB, 사용자·권한·처리 이력은 SQLite로 역할을 나눔

2. 기존 엑셀과 1:1로 맞춰 보며 옮기다 (2026년 6월) 6월에 지금의 저장소로 다시 시작하고, 따로 돌던 데이터 적재 도구를 합쳤습니다. 단계마다 기존 엑셀 마감보고와 숫자가 같은지 1:1로 대조하는 것을 규칙으로 했습니다. 먼저 점검 항목과 비교 기준선(회귀 기준)을 만든 뒤에 대시보드와 평가 화면을 다시 정비했습니다.

3. 다른 사람이 쓸 수 있게 만들다 (2026년 8월) 혼자 쓰던 도구를 여러 사람이 쓰는 서비스로 바꾸는 단계였습니다.

• 코드에 박혀 있던 기본 계정과 비밀값을 모두 걷어 냈습니다.
• 실제 데이터 없이 시험할 수 있게 가짜 데이터 생성기를 만들었습니다.
• 메뉴 디자인을 하나의 체계로 통일하고, 목표 달성 현황 메뉴를 더했습니다.
• 나중에 회사 개발팀이 다시 만들 수 있도록 데이터와 서비스의 경계(계약)를 정한 전환 로드맵을 썼습니다.

4. 서버에 올리다 (2026년 9월)

• 대시보드를 새 버전으로 바꾸고, 컨테이너(Docker) 기반으로 버전 태그 하나면 시험 → 이미지 만들기 → 서버 반영이 이어지는 배포를 만들었습니다.
• 서버에는 개인정보 검사를 통과한 집계본만 보냅니다. 검사는 주민등록번호 형식까지 확인합니다.
• 회사 메일 인증과 회사 IP만 접속을 허용하는 이중 문을 달았습니다.
• 써 보는 사람이 화면에서 바로 의견을 남길 수 있는 버튼을 붙였습니다.

5. 장애를 겪고 안전장치를 넣다 (2026년 9월) 배포 직후 실제로 여러 사람이 열어 보면서 문제가 드러났습니다. 아래 "겪은 문제와 해결"에 정리했습니다.

지금 할 수 있는 것

권한은 두 갈래로 나눴습니다. 어떤 메뉴를 볼 수 있는가(평가 메뉴는 관리자가 따로 열어 줘야 보임)와 어느 조직까지 볼 수 있는가(지정된 화면은 본인 조직만)입니다.

데이터가 흐르는 길

사내 시스템에서 받은 원천 엑셀 (실적·마감·인사 등)
   ↓  적재 (별도 실행)
L1 월별 원천 저장 (Parquet)
   ↓
L2 조직 분류 — 부문·본부 규칙을 SQL 한 곳에서 부여
   ↓
L3 집계 테이블 — 보고·평가·대시보드용
   ↓
화면은 조회만
   ↓  배포할 때
개인정보 컬럼을 뺀 배포용 DB → 검사 통과 시에만 서버로 한 방향 전송

집계 SQL은 한 파일에 모았습니다. 숫자가 바뀌는 변경은 "무엇이 어떻게 달라지는지"를 작업 기록에 남기는 것을 규칙으로 했습니다.

AI와 함께 만든 방식

구현은 Claude Code가 맡고, 점검은 Codex가 따로 했습니다. 만든 AI가 스스로 검토하면 놓치는 것이 많아, 숫자와 권한이 걸린 이 프로젝트에서는 점검을 다른 도구로 분리했습니다. 화면 디자인은 Google Stitch로 시안을 먼저 만들었습니다.

• 규칙 파일을 정본으로: 데이터 저장 방식, 권한 구조, 배포 절차 같은 개발 규칙을 프로젝트 지침 파일 한 곳에 적고, AI가 매번 그 규칙을 읽고 일하게 했습니다.
• 반복 작업은 스킬로: 재시작, 작업 기록, 배포, 배포용 DB 만들기 같은 절차를 스킬로 만들어 같은 순서로 하게 했습니다.
• 평가 계산을 바꾸면 검토부터: 평가 SQL을 고치면 검토 담당 에이전트가 먼저 확인합니다.
• AI가 읽으면 안 되는 것은 막아 둠: 비밀값 파일과 원천 엑셀은 AI 도구가 열지 못하게 설정했습니다.
• Codex로 교차 점검: 전체 코드, 집계 로직의 오류 가능성, 권한과 개인정보 처리, 보안, 메뉴별 화면 배치를 Codex가 따로 점검했습니다. 이 프로젝트에서 가장 큰 위험은 숫자가 화면마다 다르게 나오는 것과 권한 밖 데이터가 보이는 것이었습니다.
• 점검 의견은 판정해서 받음: Codex와 외부 점검 의견은 그대로 받지 않고, Claude Code로 코드와 대조해 수용·보류·거절을 근거와 함께 표로 남겼습니다.
• Stitch로 화면 시안부터: 대시보드 카드·표·필터 배치를 메뉴별로 Google Stitch에서 시안으로 만들고, 받은 코드를 기준으로 화면 구성과 스타일을 옮긴 뒤 디자인 체계에 맞게 다듬었습니다.
• 보안 점검은 가짜 데이터로: 실제 데이터를 쓰지 않고 합성 데이터로 위험 동작을 재현해 확인했습니다.

지금 상태와 다음

• 서버에 시험 배포해 검증하는 파일럿 단계입니다. 보안 재점검에서 운영 전에 고칠 항목이 남아 있어, 실제 데이터 운영은 그 항목을 고친 뒤에 하기로 했습니다.
• 이 시스템의 목표는 영원히 혼자 운영하는 것이 아니라, 업무 규칙을 검증하고 회사 개발팀이 다시 만들 때 쓸 기준(계약)을 확보하는 것입니다. 화면 조회를 집계 테이블 전용으로 바꾸고, 데이터 접근 계층을 나누고, 데이터 입력을 바꿔 끼울 수 있게 하는 순서로 사내 인프라 이전을 준비하고 있습니다.