| 항목 | 기록 |
|---|---|
| 문제 | 대용량 입고 통계 추출이 운영 DB 조회와 담당자 수작업에 의존했다. 분석 질의가 길어질수록 결과 확인과 재현도 어려워졌다. |
| 기존 방식과 비용 | 약 4억 행 기준 대표 연간 그룹 집계는 원격 운영 MySQL에서 1,658.234초가 기록됐다. |
| 제안/판단 | 운영 트랜잭션 DB와 분석 질의를 분리하고, 분석 전용 저장·실행 경로를 둬 장시간 집계가 운영 업무와 경쟁하지 않도록 했다. |
| 기술 선택 | DuckDB 기반 OLAP과 SQL. 대량 분석에는 컬럼형 로컬 분석 엔진을 선택했고, 운영 DB는 트랜잭션 처리 경로로 유지했다. |
| 구현 범위 | 대용량 데이터를 분석용으로 운영하고, 대표 집계의 성능을 기록했다. 내부 스키마와 쿼리 전문은 공개하지 않는다. |
| 내 기여 | DuckDB·OLAP 도입, 분석 데이터 경로 구성, 성능 검증과 운영 문서화를 직접 수행했다. |
| 정량 결과 | 대표 연간 그룹 집계 1,658.234초→1.314초(99.92% 감소), 대표 분기 집계 249.435초→0.309초(99.88% 감소). |
| 연결 데이터 | OLAP 규모 (DATA-SCALE-OLAP) · DuckDB 연간 집계 (DATA-IMPROVEMENT-DUCKDB-ANNUAL) · DuckDB 분기 집계 (DATA-IMPROVEMENT-DUCKDB-QUARTERLY) · 후속 MCP 플랫폼 사례 |
| 측정 한계 | 두 성능 값은 각각 단일 실행 기록이다. MySQL은 Ncloud 원격 환경(네트워크 지연 포함), DuckDB는 로컬 환경에서 측정했으므로 평균·중앙값이나 엔진만의 순수 성능 차이로 일반화하지 않는다. |
| 공개 주의사항 | SQL, 테이블·컬럼명, 사용자명, 요청 본문, 사내 URL 및 로그 원문은 공개하지 않는다. 화면은 집계값과 흐름만 마스킹해 사용한다. |
근거
지표는 포트폴리오 정본 data/metrics.yml(2026-08-31 기준)의 DATA-* 항목이다. 원본 응답·행 데이터는 저장하지 않는다.
- DATA-IMPROVEMENT-DUCKDB-ANNUAL · 대용량 연간 그룹 집계: 1,658.234초 → 1.314초
- DATA-IMPROVEMENT-DUCKDB-QUARTERLY · 대용량 분기 집계: 249.435초 → 0.309초
- DATA-SCALE-OLAP · OLAP 데이터 규모: 436,586,806행
측정값
| 항목 | 이전 | 이후 | 비고 |
|---|---|---|---|
| 대용량 연간 그룹 집계 | 1,658.234초 | 1.314초 | 99.92% 감소 |
| 대용량 분기 집계 | 249.435초 | 0.309초 | 99.88% 감소 |
약 4억 행 기준 단일 측정. MySQL은 원격 운영 환경, DuckDB는 로컬 환경에서 측정했다. 반복 실행의 평균·중앙값이 아니다. 측정일 2026-08-31 기준. 정본: 포트폴리오 data/metrics.yml.
공개 범위
이 글은 포트폴리오 정본의 공개 요약이다. 원본 업무 데이터와 회사·약국·서버·공급사 식별정보는 뺐다. SQL, 테이블·컬럼명, 사용자명, 요청 본문, 사내 URL 및 로그 원문은 공개하지 않는다. 화면은 집계값과 흐름만 마스킹해 사용한다.