Data Analysis Solution
One line — An analysis-driven process management platform that goes beyond monitoring-only SPC: users upload raw data and run statistical analyses (normality, t-test, ANOVA) directly through the UI, powered by a Python statistical engine exposed as APIs.
Overview
Traditional SPC(Statistical Process Control) systems focus on simple monitoring. This platform lets users upload raw data and perform statistical analyses directly. Core methods — normality tests, t-tests, ANOVA — are implemented as APIs with a UI for visualizing results, and the Python statistical engine, backend server and web UI are wired into one integrated architecture.
Impact
- Ensured consistency and automation of analysis results through standardized analysis APIs.
- Established an automated analysis framework inside the platform without external tools (e.g., Minitab).
- Enabled proactive response to process anomalies by embedding analysis into the existing ifacts SPC solution.
- Supported multiple file formats (CSV/JSON) and DB inputs, letting users analyze directly via the UI.
Tech stack
Key roles & achievements
⊙ UI & API design for analysis
- Benchmarked commercial tools (Minitab, JMP) to design an intuitive UI.
- Implemented a FastAPI-based REST API server to handle analysis requests.
- Exposed core statistical methods (normality tests, t-tests, ANOVA) as APIs.
⊙ Stable analysis-engine architecture
- Built a Process Manager to overcome Python GIL — state management + multi-core utilization.
- Ran each analysis request in a dedicated subprocess for stable parallelism.
- Developed inter-process health-check functionality.
⊙ Flexible data ingestion & preprocessing
- Parsers for multiple input formats (DB, JSON, CSV).
- Automated preprocessing — validation, missing-value handling, transformation.
Troubleshooting 1 — Python GIL & multi-core
Problem: Python’s GIL(Global Interpreter Lock) restricts CPU-bound work, so a multi-process approach is forced. When many users analyze simultaneously, CPU contention causes bottlenecks. But in a multi-process setup it is structurally hard to keep per-user state (Uvicorn just adds workers with round-robin) — uploading data and then requesting analysis may hit different processes, disconnecting the user’s state. Unlike Java, Python is weak at memory-shared session management across processes. And due to solution-team policy, external state stores (e.g., Redis) were not allowed — an internalized approach was required.
Solution: Implemented a Process Manager that centrally controls processes and manages per-user state. Acting like a gateway, it handles inter-process state delivery and connectivity, keeping a stateful context without external storage. By managing data import + analysis as a single unit in the DB keyed by user ID, session continuity is preserved — yielding a scalable, reliable distributed-computation structure that avoids the GIL bottleneck while using multi-core resources.
Troubleshooting 2 — Visualization CPU overload
Problem: Rendering 100,000+ points in the browser (e.g., a scatter plot of all points) overwhelmed it; transmitting large datasets risked heavy server load; and client PCs were overloaded — visualization became the biggest performance challenge.
Solution (theoretical, domain-specific): Commercial tools (Minitab, JMP) are Windows executables that process data locally or connect directly to a DB, overcoming browser limits — a clear recognition that this is a system-level limitation. Since a full system-level fix was infeasible, I applied a statistical-theoretical approach: the Glivenko–Cantelli theorem guarantees the empirical CDF (ECDF) almost surely converges to the true CDF. Because visualization aims to capture overall trends (not outliers), random sampling was adopted; sampled datasets showed no significant distributional difference, enabling efficient visualization.
한 줄 요약 — 단순 모니터링 위주의 기존 SPC 를 넘어, 사용자가 raw data 를 올려 통계 분석(정규성·t-검정·ANOVA)을 UI 에서 직접 수행하는 분석 중심 공정관리 플랫폼. Python 통계 엔진을 API 로 제공한다.
개요
전통적인 SPC(통계적 공정관리) 시스템은 단순 모니터링에 초점이 맞춰져 있다. 이 플랫폼은 사용자가 raw data 를 업로드해 통계 분석을 직접 수행할 수 있게 한다. 정규성 검정, t-검정, ANOVA 등 핵심 통계 기법을 API 로 구현하고 결과 시각화 UI 를 제공했으며, Python 기반 통계 엔진·백엔드 서버·웹 UI 를 잇는 통합 아키텍처를 설계·개발했다.
성과
- 표준화된 분석 API 로 분석 결과의 일관성·자동화를 확보.
- 외부 도구(예: Minitab) 없이 플랫폼 내부에 자동 분석 프레임워크 를 구축.
- 기존 ifacts SPC 솔루션에 분석 기능을 내장하여 공정 이상에 선제 대응 가능.
- 다양한 파일 포맷(CSV/JSON)·DB 입력을 지원하여 UI 에서 직접 분석.
기술 스택
핵심 역할 & 성과
⊙ 분석 기능 UI·API 설계
- Minitab, JMP 등 상용 도구를 벤치마킹하여 직관적인 UI 설계.
- 분석 요청을 처리하는 FastAPI 기반 REST API 서버 구현.
- 핵심 통계 기법(정규성 검정, t-검정, ANOVA)을 API 로 정의·노출.
⊙ 안정적인 분석 엔진 아키텍처
- Python GIL 제약을 넘기 위한 Process Manager 구현 — 상태 관리 + 멀티코어 활용.
- 각 분석 요청을 전용 subprocess 에서 실행하여 안정적 병렬 처리.
- 프로세스 간 health check 기능 개발.
⊙ 유연한 데이터 적재·전처리
- 다양한 입력 포맷(DB, JSON, CSV) 파서 구현.
- 데이터 검증·결측 처리·변환을 위한 자동 전처리 흐름 구축.
트러블슈팅 1 — Python GIL & 멀티코어
문제: Python 의 GIL(Global Interpreter Lock) 은 CPU-bound 작업을 제약하므로 멀티프로세스 방식이 강제된다. 여러 사용자가 동시에 분석을 요청하면 CPU 자원 경합으로 병목이 생긴다. 그런데 멀티프로세스 구조에서는 사용자별 state 유지 가 구조적으로 어렵다(Uvicorn 은 worker 만 늘리고 round-robin 으로 분배) — 데이터를 업로드한 뒤 분석을 요청하면 서로 다른 프로세스가 처리해 사용자 state 가 끊긴다. 또 Java 와 달리 Python 은 멀티프로세스에서 메모리 공유 기반 세션 관리가 약하다. 게다가 솔루션 팀 정책상 외부 상태 저장소(예: Redis)는 운영 부담·복잡도 때문에 허용되지 않아, 내재화된 방식 이 필요했다.
해결: 프로세스를 중앙에서 제어하고 사용자별 state 를 관리하는 Process Manager 를 구현했다. 게이트웨이처럼 동작하여 프로세스 간 state 전달·연결을 직접 처리함으로써 외부 저장소 없이 stateful context 를 유지한다. 사용자 ID 기준으로 data import + 분석을 DB 에서 하나의 단위로 관리해 세션 연속성을 보장했고, 결과적으로 GIL 병목을 피하면서 멀티코어를 활용하는 확장 가능하고 신뢰성 있는 분산 연산 구조 를 만들었다.
트러블슈팅 2 — 시각화 CPU 과부하
문제: 브라우저에서 10만 개 이상의 데이터(예: 전체 점을 그리는 산점도)를 시각화하면 브라우저가 감당하지 못했다. 대용량 전송 시 서버 부하도 컸고, 클라이언트 PC 도 심하게 과부하되어 사용자 경험이 나빠졌다 — 시각화가 가장 큰 성능 과제였다.
해결(이론적·도메인 접근): 상용 도구(Minitab, JMP)는 Windows 실행 앱으로 로컬에서 데이터를 처리하거나 DB 에 직접 연결해 브라우저 한계를 넘는다 — 즉 이는 시스템 레벨의 한계 임을 명확히 인지했다. 완전한 시스템적 해결이 불가능하므로 통계 이론적 접근을 적용했다. Glivenko–Cantelli 정리 는 경험적 누적분포(ECDF)가 참 누적분포(CDF)로 거의 확실하게(almost surely) 수렴함을 보장한다. 시각화의 목적은 전체 추세 파악이므로(이상치에 집착하지 않음) random sampling 을 채택했고, 표본 데이터의 분포가 거의 차이가 없어 효율적인 시각화가 가능했다.