레거시 사내 ERP 조회 지연(Latency) 병목 진단 프레임워크: 전면 재개발 전 확인해야 할 4구간 계측

[아키텍처 노트 안내]
본 문서는 제이앤코어 오픈 기술 Q&A 43번 문의(누적 데이터 증가로 인한 사내 ERP 조회 속도 저하 및 기존 개발사 연락 두절 상황에서의 DB 튜닝 가능 여부)를 바탕으로, 시스템 전면 재개발 여부를 판단하기 전에 수행해야 할 구간별 지연 계측(Latency Profiling) 및 성능 개선 프레임워크를 정리한 기술 문서입니다.

1. “30초 걸리는 조회를 0.3초로 줄일 수 있는가?”에 대한 엔지니어링 답변

수년간 사용한 사내 ERP나 재고·매출 관리 시스템에서 조회 버튼을 누른 뒤 화면이 20~30초씩 멈추는 현상은 많은 중소·중견기업이 겪는 대표적인 고통입니다. 기존 구축 업체와 연락이 끊긴 상태라면 실무진은 “DB 튜닝만으로 즉시 빨라질 수 있는지”, 아니면 “시스템 전체를 새로 개발해야 하는지” 갈림길에 서게 됩니다.

이 질문에 대해 코드를 열어보지도 않고 “무조건 0.3초로 줄여드립니다”라거나 “구형이라 새로 만들어야 합니다”라고 단정하는 것은 비전문적인 태도입니다.

사용자 눈에는 똑같은 ‘모래시계(로딩 중)’ 화면으로 보이지만, 실제로 시간이 소비되는 물리적 구간은 전혀 다를 수 있기 때문입니다.

[조회 버튼 클릭부터 화면 출력까지의 4대 지연(Latency) 발생 구간]
[구간 A] 요청 전처리 및 동적 쿼리 생성 (Application Server)
   ↓
[구간 B] 데이터베이스 탐색·조인·정렬 연산 (DB Execution Time: Full Table Scan, 비효율 Subquery)
   ↓
[구간 C] 대용량 결과셋 직렬화 및 네트워크 전송 (Payload Serialization & Network Transfer)
   ↓
[구간 D] 클라이언트 브라우저 파싱 및 수만 행 그리드 렌더링 (DOM Rendering & JS Blocking)

만약 실제 DB 쿼리(구간 B)는 0.5초 만에 끝났는데, 서버가 페이지네이션(Pagination) 없이 5만 건의 데이터를 한 번에 내려보내고 브라우저(구간 D)가 이를 표로 그리느라 25초 동안 멈춰 있는 것이라면 어떨까요? 아무리 고가의 DB 튜닝 전문가를 불러 인덱스를 재구성해도 체감 속도는 단 1초도 줄어들지 않습니다. 원인을 구간별로 분해(Decomposition)하는 계측이 선행되어야 하는 이유입니다.

2. 1단계: 재현 가능한 지연 프로파일(Reproducible Profile) 정의

성능 진단의 첫걸음은 “오전에 유독 느리다” 같은 정성적 표현을 동일한 조건으로 반복 실험할 수 있는 정량적 재현 시나리오로 바꾸는 것입니다.

개선 전후를 객관적으로 비교하기 위해 제이앤코어는 다음 5가지 기준점을 먼저 기록합니다.

계측 항목	기록 예시 (Baseline Spec)	엔지니어링 확인 목적
대상 화면 및 기능	`매출원장 관리 > 기간별 거래처 조회`	호출되는 백엔드 API 엔드포인트 또는 저장 프로시저(SP) 특정
검색 조건 파라미터	`조회 기간: 최근 1년 / 거래처: 전체 / 상태: 판매완료 포함`	인덱스(Index)를 타는 조건절(`WHERE`)인지 전체 탐색 조건인지 판별
반환 데이터 규모	`총 48,200행 × 28개 컬럼 (응답 크기 약 18.4MB)`	네트워크 전송량 및 클라이언트 렌더링 부하 산출
측정 시작~종료 기준	`조회 버튼 클릭 시점 ~ 그리드 첫 행 표시 완료 시점`	체감 응답 시간(Wall-clock Time)의 일관된 측정 기준 확립
구간별 소요 시간	`DB 쿼리 14.2초 / 응답 전송 3.1초 / 브라우저 렌더링 9.8초`	최우선 타격해야 할 병목 구간(Bottleneck) 식별

3. 2단계: 구간별 대표 병목 패턴과 비침습적(Non-invasive) 개선 전략

계측을 통해 가장 많은 시간을 소모하는 구간이 특정되면, 시스템 전체를 갈아엎지 않고도 적용할 수 있는 타겟 최적화를 수행합니다.

① 구간 B (DB 연산 병목): 인덱스 누락과 스칼라 서브쿼리(N+1) 제거

레거시 ERP에서 데이터가 수십만 건으로 늘어날 때 갑자기 속도가 꺾이는 가장 흔한 원인은 다음과 같습니다.

인덱스 무력화(Non-SARGable Query): 조회 기간 컬럼(order_date)에 인덱스가 걸려 있어도, 쿼리문에서 WHERE SUBSTRING(CONVERT(VARCHAR, order_date, 112), 1, 6) = '202610'처럼 컬럼을 함수로 감싸버리면 DB 옵티마이저는 인덱스를 포기하고 수백만 건 전체를 읽는 Full Table Scan을 수행합니다. 조건절을 범위 검색(order_date >= '2026-10-01' AND order_date < '2026-11-01')으로 교정하고 복합 인덱스를 재설계하는 것만으로 수십 초의 쿼리가 수 밀리초(ms) 단위로 단축됩니다.
행 단위 반복 서브쿼리: 조회 결과 1만 행을 가져오면서 각 행마다 현재 재고나 미수 잔액을 구하기 위해 SELECT 절 내부에서 서브쿼리를 1만 번 반복 실행하는 구조입니다. 이를 단일 집계 뷰나 해시 조인(Hash Join)으로 전환하면 DB 부하가 극적으로 감소합니다.

② 구간 C & D (전송 및 화면 렌더링 병목): 초기 조회 범위 제어와 서버 사이드 페이징

실무자가 화면을 열자마자 아무 조건 없이 ‘전체 기간’의 수만 건이 자동으로 조회되도록 설계된 경우가 많습니다. 정작 담당자가 당장 확인하려는 것은 **‘최근 7일간의 미처리 건’**인데도 말입니다.

기본 검색 기간(Default Filter) 강제: 화면 진입 시 기본 조회 범위를 당월 또는 최근 1개월로 제한하고, 장기 이력이 필요할 때만 조건을 확장하도록 변경합니다.
요약 그리드와 상세 조회의 분리: 목록 화면에서는 핵심 식별 컬럼 8~~10개만 서버 사이드 페이지네이션(1페이지당 50~~100행)으로 가볍게 불러오고, 행을 클릭했을 때만 무거운 상세 이력 데이터를 비동기로 호출하도록 분리합니다.

4. 3단계: 언제 ‘튜닝’을 멈추고 ‘분리 구축’을 선택해야 하는가?

모든 레거시 시스템을 튜닝만으로 영구히 살릴 수 있는 것은 아닙니다. 진단 결과 다음과 같은 구조적 한계가 확인된다면, 무리하게 구형 소스코드를 수선하는 것보다 **문제가 되는 조회·정산 모듈만 별도의 경량 웹 시스템으로 분리(Sidecar Architecture)**하는 것이 비용 대비 효과가 훨씬 높습니다.

소스코드 유실 및 암호화: 기존 개발사가 컴파일된 바이너리만 남기고 잠적하여 쿼리 수정이나 페이지네이션 적용 자체가 불가능한 경우 (DB 레벨의 인덱스 추가만 제한적으로 가능).
트랜잭션 락(Lock) 경합: 실시간 현장 입력(바코드 스캔, 수주 등록)이 일어나는 운영 테이블과 무거운 월말 통계 조회 쿼리가 서로 락(Lock)을 걸며 현장 업무까지 마비시키는 경우.

이러한 경우에도 수억 원을 들여 전사 ERP를 통째로 바꿀 필요는 없습니다. 기존 ERP의 입력 기능은 그대로 유지한 채, 조회와 통계·정산 병목이 발생하는 업무만 읽기 전용 복제본이나 덤프 파이프라인으로 연결된 독립 웹 화면으로 2~4주 만에 구축하면 현장의 고통을 가장 안전하고 빠르게 해소할 수 있습니다.

💡 사내 ERP 속도 저하 진단 및 병목 모듈 분리 상담

매일 수십 번씩 누르는 조회 버튼 앞에서 직원들이 수십 초씩 화면이 뜨기를 기다리고 있습니까?
기존 개발사와 연락이 끊겨 손도 대지 못한 채 고액의 전면 재개발 견적만 받아보고 계십니까?

가장 느린 화면 1~2개의 검색 조건과 현재 운영 환경(DB 종류, 소스코드 보유 여부)만 알려주시면, 제이앤코어 기술연구소가 DB 튜닝으로 해결할 수 있는 영역과 경량 웹 모듈로 분리해야 할 영역을 정직하게 진단해 드립니다.