엑셀 너머 대시보드 ③ 내 PC 밖 서버에 올리며 생긴 문제 4가지

먼저 결론

• 클릭하면 필터가 걸리는 화면을 만들었는데, 보안 처리 때문에 클릭 코드가 지워지고 있었습니다.
• 자동 배포를 만들고 보니 검사가 작업 브랜치에서는 한 번도 돌지 않고 있었습니다.
• 개인정보 검사를 켜자 화면 대부분이 빈 화면이 될 상황이라, 검사 기준을 다시 정했습니다.
• 배포 직후 여러 명이 동시에 접속해 서버가 멈췄고, 같은 계산을 한 번만 하도록 고쳤습니다.

1. 클릭 코드는 화면 프레임워크가 지우고 있었다

2026년 7월, 차트의 막대나 표의 행을 클릭하면 그 조직으로 필터가 걸리는 화면을 만들려고 했습니다. 상위 조직에서 개인까지 다섯 단계로 내려가며 보는 방식입니다.

이참에 화면과 데이터 사이를 API 구조로 바꾸는 시험도 같이 했습니다. "질문을 보내면 JSON으로 답하는" 구조입니다.

새 탐색 화면은 화면 프레임워크 위에 순수 자바스크립트로 그리고, 데이터는 API로 받게 했습니다. 기존 대시보드에도 트리맵, 월별 막대, 표의 행을 클릭하면 필터가 바뀌도록 연결했습니다.

그런데 생산성 화면의 히트맵은 행을 클릭해도 필터가 걸리지 않았습니다.

저는 HTML 안에 넣은 클릭 코드가 실행되지 않는다고 보고 원인을 찾았습니다. 화면 프레임워크가 HTML을 넣을 때 보안을 위해 클릭 코드 같은 스크립트를 지우고 있었습니다.

그래서 행에는 데이터 표시만 남겼습니다. 클릭은 페이지 전체에서 한 번 받아 어느 행인지 판별하는 방식으로 바꿨습니다.

새 화면의 핵심 숫자가 기존 요약 계산과 정확히 같은지 대조했습니다. 브라우저 자동 테스트로 로그인부터 필터 초기화까지 확인했습니다.

2. 검사가 한 번도 돌지 않고 있었다

9월 10일, 일부 관리자에게 보여 주려고 클라우드 서버(메모리 1GB)에 올리기로 했습니다. 목표는 버전 태그를 붙이면 검사, 이미지 빌드, 배포가 자동으로 이어지게 하는 것이었습니다.

AI에게 Docker 이미지와 태그 기반 배포를 만들게 했습니다. 더미 데이터를 넣고 컨테이너를 띄워 주요 화면이 모두 열리는 것을 확인했습니다. 다시 시작해도 계정과 로그인 상태가 남았습니다. 메모리는 156MB 정도로 서버 용량 안에 들어왔습니다.

그런데 기존 자동 검사를 살펴보니 main 브랜치에 올릴 때만 돌게 되어 있었습니다. 실제 작업은 다른 브랜치에서 하고 있었습니다.

검사는 한 번도 돌지 않고 있었습니다.

코드 검사 단계도 실패해도 통과로 처리되게 설정돼 있었습니다.

버전 태그를 잘못 붙이지 못하게 막는 장치도 만들었습니다. 그런데 이 장치가 정상 작업까지 막았습니다. 명령 안에 든 글 속의 "태그" 같은 글자를 실제 태그 명령으로 오인한 것입니다.

검사는 작업 브랜치에서도 돌게 하고, 실패하면 실제로 멈추도록 바꿨습니다. 태그 차단 장치는 글 속 문자열을 빼고 실제 명령 자리만 보도록 고쳤습니다. 그 뒤 막아야 할 경우 6가지와 통과시켜야 할 경우 9가지로 시험했습니다.

3. 개인정보 검사를 켜자 화면 대부분이 빌 뻔했다

서버에는 고객 개인정보가 올라가면 안 됩니다. 저는 규칙을 문서로만 두지 않기로 했습니다. DB를 서버로 보내기 전에 기계로 검사해, 걸리면 올리지 못하게 하는 것이 목표였습니다.

검사는 허용한 표 목록, 개인정보로 보이는 열 이름, 실제 값을 함께 봅니다. 주민등록번호는 생년월일, 성별 자리, 검증 숫자까지 맞춰 보고 실제 번호인지 판별합니다.

시험 삼아 이름이 평범한 숫자 열에 유효한 주민번호 하나를 숨겨 넣었더니 검사가 잡아냈습니다. 통과하지 못하면 만들던 파일까지 지워, 반쯤 만들어진 DB가 남지 않게 했습니다.

그런데 검사를 켜고 보니 화면 16개 중 13개가 빈 화면이 될 상황이었습니다. 서버에서 쓸 수 있는 데이터만으로는 그랬습니다. 화면 대부분이 집계된 표가 아니라 원천 데이터를 직접 읽고 있었기 때문입니다.

처음 계획은 집계된 표만 올리는 것이었습니다. 하지만 이 방식은 화면 코드를 대부분 다시 짜야 해서 당장 배포할 수 없었습니다.

그래서 원천 데이터를 올리되 고객을 식별하는 열은 지우기로 했습니다. 이름, 주민번호, 계좌, 주소, 연락처 열입니다. 영업 담당자 이름을 남겨도 되는지는 제가 정할 수 없는 문제라 승인을 받은 뒤 진행했습니다.

더미 데이터로 시험해 개인정보 열 57개가 지워지고 잔존 0건인 것을 확인했습니다. 9월 15일 다시 점검하다 차단 대상에서 빠진 열을 찾았습니다. 계약번호, 로그인 아이디, 직통번호를 추가했습니다. 같은 날 회사 IP에서만 접속되게 막았습니다.

4. 배포 직후 같은 계산이 사람 수만큼 겹쳤다

2편에서 다룬 것처럼 대시보드를 처음 여는 데 26초가 걸렸습니다. 이 시간은 연결 재사용과 결과 저장(캐시)으로 줄였습니다. 같은 조건의 조회는 저장된 결과를 바로 돌려줍니다.

9월 17일, 새 버전을 배포한 직후 서버가 로그인 화면조차 응답하지 않았습니다.

배포로 저장된 결과가 비워진 상태에서 여러 명이 동시에 대시보드를 열었습니다. 한 번에 14~47초씩 걸리는 계산이 겹쳤습니다. 응답이 없자 새로고침이 다시 겹치면서 CPU 2개가 꽉 찼습니다.

저는 같은 화면을 여러 명이 열면 같은 계산을 사람 수만큼 반복하는 것이 원인이라고 봤습니다. 그래서 같은 조건의 계산은 한 번만 하고, 나머지 요청은 그 결과를 기다려 받게 했습니다.

서로 다른 계산이 몰려도 동시에 2개까지만 돌게 했습니다. 로그인 같은 가벼운 요청이 밀리지 않게 하려는 것입니다.

같은 조건 20개를 동시에 보내 계산이 1번만 일어나는 것을 확인했습니다. 다른 조건 10개를 보냈을 때는 동시 계산이 2개를 넘지 않았습니다.

바꾼 것과 아직 못 한 것

바꾼 것은 네 가지입니다. 화면은 클릭을 직접 넣지 않고 한곳에서 받습니다. 검사는 작업 브랜치에서 돌고 실패하면 멈춥니다. 서버로 가는 DB는 기계 검사를 통과해야만 만들어집니다. 무거운 계산은 한 번만, 동시에 2개까지만 돕니다.

아직 못 한 것도 있습니다. 10월 보안 재점검에서 나온 보완 과제가 남아 있습니다. 사내 서버로 옮기는 일은 계획 문서만 있는 상태입니다.

내 PC에서 잘 되는 것과 여러 사람이 쓰는 것은 달랐다

네 가지 모두 혼자 쓸 때는 드러나지 않던 문제였습니다. 서버에 올리기 전에 확인할 것을 세 가지로 남깁니다.

• 개인정보: 규칙 문서만으로는 지켜지지 않아, 올리는 길목에 기계 검사를 뒀습니다.
• 접속 범위: 로그인만으로 충분하다고 보지 않고, 회사 IP에서만 열리게 막았습니다.
• 동시 접속: 혼자 쓸 때는 26초도 견딜 만했지만, 여러 명이 동시에 열자 서버 전체가 멈췄습니다.

화면을 만드는 일은 AI가 가장 빨리 도와주는 부분입니다. 서버에 올린 뒤에는 화면보다 더 큰 문제가 있었습니다. 누가 들어오는지, 무엇이 올라가는지, 몇 명이 동시에 여는지입니다.

지금 쓰는 대시보드가 있다면 그 안에 고객 정보가 들어 있는지부터 점검하는 것이 첫 순서입니다.