SON Kiseok Technical Blog

분석 결과를 웹 서비스로 시스템화할 때 고려할 점

문제점

데이터 분석 프로젝트에서는 분석 결과를 보고서나 노트북 형태로 전달하는 것에서 끝나지 않고, 웹 화면이나 운영 시스템에 반영해야 하는 경우가 많습니다.

하지만 분석 결과를 곧바로 서비스로 만드는 과정에서는 다음 문제가 자주 발생합니다.

  • 분석 코드는 일회성 실행을 전제로 작성되어 있습니다.
  • 입력 데이터 경로와 컬럼 구조가 고정되어 있지 않습니다.
  • 분석 결과의 검증 기준이 명확하지 않습니다.
  • 웹 화면에서 필요한 조회 조건과 분석 결과 구조가 맞지 않습니다.
  • 운영 DB에 저장할 테이블 설계가 늦게 결정됩니다.
  • 분석가와 개발자가 같은 용어를 다르게 사용합니다.
  • 현업은 분석 결과뿐 아니라 수정, 이력관리, 엑셀 업로드 같은 업무 기능까지 요구할 수 있습니다.

이 경우 단순히 분석 코드를 서버에 올리는 것만으로는 시스템화가 어렵습니다.

원인

분석과 시스템화의 목적이 다르기 때문입니다.

분석의 목적은 주로 인사이트 도출입니다.

데이터 이해 -> 전처리 -> 모델링/집계 -> 결과 해석 -> 보고

반면 시스템화의 목적은 반복 가능한 운영입니다.

입력 표준화 -> 처리 자동화 -> 결과 저장 -> 화면 조회 -> 권한/로그/이력 관리 -> 장애 대응

분석 결과가 의미 있어도 운영 시스템에 넣으려면 데이터 구조, 실행 주기, 예외 처리, 저장 방식, 사용자 화면, 권한 기준이 추가로 필요합니다.

해결

분석 결과를 웹 서비스로 만들 때는 먼저 산출물을 세 가지로 나눠야 합니다.

  1. 분석 산출물
  2. 데이터 산출물
  3. 서비스 산출물

각 산출물은 다음처럼 구분합니다.

구분 내용
분석 산출물 분석 목적, 방법론, 모델, 해석, 지표
데이터 산출물 입력 데이터, 중간 데이터, 결과 테이블, 컬럼 정의
서비스 산출물 화면, API, 권한, 배치, 로그, 이력관리

이 구분이 없으면 분석 과제인지 개발 과제인지 범위가 흐려집니다.

실행 방법

1. 분석 결과의 사용 방식을 먼저 확인

아래 질문에 답해야 합니다.

분석 결과를 누가 보는가?
얼마나 자주 보는가?
조회만 하는가, 수정도 하는가?
결과를 저장해야 하는가?
이전 결과와 비교해야 하는가?
엑셀 다운로드가 필요한가?
업로드 기능이 필요한가?
운영 시스템에 다시 반영해야 하는가?

조회만 필요한 경우와 수정/이력관리가 필요한 경우는 시스템 범위가 완전히 달라집니다.

2. 입력 데이터 기준 정의

분석 코드를 운영하려면 입력 데이터 기준이 필요합니다.

확인 항목은 다음입니다.

  • 데이터 출처
  • 적재 주기
  • 기준일자
  • 필수 컬럼
  • 결측치 처리 기준
  • 코드값 정의
  • 데이터 변경 가능성
  • 수동 파일 업로드 여부

입력 데이터가 안정적이지 않으면 웹 화면을 먼저 만들어도 운영이 어렵습니다.

3. 결과 테이블 설계

웹 서비스에서 분석 결과를 조회하려면 결과를 DB 테이블로 저장하는 것이 일반적입니다.

예시 구조:

analysis_result
- result_id
- base_date
- target_type
- target_id
- metric_name
- metric_value
- rank_value
- created_at

하지만 모든 분석 결과를 key-value 형태로 저장하면 화면 개발과 검증이 어려워질 수 있습니다. 지표가 명확하고 화면 구조가 정해져 있다면 전용 결과 테이블을 설계하는 편이 낫습니다.

4. 분석 코드와 서비스 코드를 분리

분석 코드는 보통 Python, R, Notebook 형태로 작성됩니다. 웹 서비스는 Java/Spring Boot, FastAPI, Node.js 등으로 구현될 수 있습니다.

권장 구조는 다음입니다.

분석 코드
-> 결과 CSV 또는 DB 저장
-> 백엔드 API
-> 웹 화면 조회

분석 코드를 웹 요청마다 직접 실행하는 구조는 피하는 것이 좋습니다. 실행 시간이 길고, 장애 원인 분리가 어렵고, 동일 요청에 대해 결과가 달라질 수 있기 때문입니다.

5. 배치와 API 역할 분리

반복 분석이 필요하면 배치 작업으로 결과를 생성하고, 웹 API는 이미 생성된 결과를 조회하는 구조가 안정적입니다.

Batch: 데이터 수집, 전처리, 분석, 결과 저장
API: 결과 조회, 필터링, 다운로드
UI: 검색 조건, 차트, 테이블 표시

이 구조는 장애 대응에도 유리합니다. 분석 실패와 화면 장애를 분리해서 볼 수 있습니다.

6. 현업 요구사항 범위 분리

현업이 요청하는 내용은 분석과 업무 기능이 섞일 수 있습니다.

예시:

분석 범위:
- 고객 유형별 입금 패턴 분석
- 예측 결과 산출
- 지표별 순위 제공

업무 기능 범위:
- 엑셀 업로드
- 데이터 수정
- 이력관리
- 승인 프로세스
- ERP 반영

이 둘은 일정, 기술, 책임 범위가 다릅니다. 초기에 구분하지 않으면 분석 과제가 개발 프로젝트로 확대될 수 있습니다.

검증 방법

시스템화 가능 여부는 다음 기준으로 확인합니다.

  • 같은 입력 데이터로 같은 결과가 재현됩니다.
  • 결과 테이블 컬럼 정의가 문서화되어 있습니다.
  • 화면에서 필요한 조회 조건이 정의되어 있습니다.
  • 분석 실패 시 재실행 기준이 있습니다.
  • 결과 생성 시점과 화면 조회 시점이 구분됩니다.
  • 현업이 결과를 어떻게 사용할지 설명할 수 있습니다.
  • 운영 중 데이터 수정이 필요한지 여부가 확인되어 있습니다.

재발 방지 / 개선 방향

분석 결과 시스템화 프로젝트에서는 다음 문서를 먼저 만드는 것이 좋습니다.

  1. 분석 시나리오 정의서
  2. 입력 데이터 정의서
  3. 결과 데이터 정의서
  4. 화면 조회 조건 정의서
  5. 배치 실행 기준
  6. 오류 및 재처리 기준
  7. 분석 범위와 업무 기능 범위 구분표

이 문서가 있으면 분석가, 개발자, 현업, PM 간의 인식 차이를 줄일 수 있습니다.

포트폴리오 관점의 의미

이 주제는 단순 백엔드 개발이나 단순 분석이 아니라, 분석 결과를 운영 가능한 서비스로 연결하는 역량을 보여줍니다.

특히 다음 역량과 연결됩니다.

  • 분석가와 개발자 사이의 요구사항 번역 능력
  • 데이터 결과물을 API와 화면으로 연결하는 설계 능력
  • 분석 범위와 개발 범위 구분 능력
  • 배치, DB, API, UI 간 역할 분리 이해
  • 공공/기업 데이터 분석 프로젝트의 시스템화 경험

전체 글 보기