데이터관리 프로그램 개발, 업무용 DB와 분석용 DB의 차이

2018.06.16 조회 6415

우리비엔씨는 업무 데이터를 쌓고 분석해야 하는 기업과 연구기관을 위해 데이터베이스 설계부터 응용 프로그램까지 데이터관리 프로그램을 개발합니다. 데이터관리 프로그램의 품질은 화면보다 데이터베이스 설계에서 먼저 갈리고, 그중에서도 업무용 DB(OLTP)와 분석용 DB(OLAP)를 구분해 설계하는 것이 출발점입니다. 이 글은 두 설계가 어떻게 다른지, 우리 회사에는 무엇이 필요한지 비교해 정리했습니다.

기상자료 패턴분석 프로그램 화면 - 관측소별 관측 데이터, 평년값 비교, 추세선 산점도와 관측 차트

기상자료 패턴분석 프로그램: 수십 년치 관측 데이터를 적재해 두고, 기간과 관측소를 고르면 평년값 비교와 추세선 분석이 바로 나옵니다

데이터관리 프로그램, 왜 DB 설계부터 이야기할까

데이터관리 프로그램은 겉으로 보면 입력 화면과 조회 화면의 묶음입니다. 하지만 같은 화면이라도 뒤에 있는 데이터베이스를 어떻게 설계했느냐에 따라 1년 뒤의 속도, 집계의 정확도, 새 기능을 붙이는 비용이 크게 달라집니다. 적은 양의 데이터를 다룰 때도, 한 프로젝트에서 수십억 건 규모의 데이터를 다룰 때도 이 원칙은 같습니다.

그래서 우리비엔씨는 상담 초기에 ‘이 데이터를 주로 입력하고 처리하는가, 아니면 쌓아 두고 분석하는가’부터 여쭤봅니다. 이 질문에 따라 설계 방식이 완전히 달라지기 때문입니다.

업무용 DB와 분석용 DB 한눈에 비교

구분	업무용 DB (OLTP)	분석용 DB (OLAP)
목적	데이터를 빠르고 정확하게 생성·처리	누적된 데이터를 시계열이나 특정 관점으로 다시 보고 분석
주된 작업	한 건씩 입력, 수정, 삭제, 조회	많은 데이터를 한꺼번에 집계·비교
설계 방식	중복을 줄이도록 테이블을 잘게 나눔(정규화)	사실 테이블과 차원 테이블로 묶어 다차원 분석이 쉽게(스타 스키마)
대표 화면	주문 등록, 입출고 전표, 고객 정보 관리	월별 추이, 지역별·품목별 피벗, 경영 대시보드
잘못 설계하면	입력이 느려지고 데이터가 서로 어긋남	보고서 하나 뽑는 데 몇 분씩 걸리고 숫자가 맞지 않음

업무용 DB: 지금 일어나는 일을 정확하게

주문 한 건, 입고 한 건이 들어올 때마다 바로 저장되고 다른 사용자에게도 즉시 보여야 합니다. 같은 정보가 여러 곳에 흩어지지 않도록 테이블을 나누고 관계를 정확히 잡는 것이 핵심입니다.

분석용 DB: 쌓인 데이터를 다른 각도로

분석용 DB는 ‘무엇을 얼마나’를 담은 사실 테이블을 가운데 두고, 기간·지역·제품·담당자 같은 분석 관점을 차원 테이블로 둘러싸는 형태로 설계합니다. 이렇게 해 두면 “분기별, 지역별로 운임이 어떻게 변했나” 같은 질문에 빠르게 답할 수 있습니다.

분석용 DB 설계 예시(스타 스키마): 가운데 사실 테이블과 기간·지역·제품·직원 등 차원 테이블

둘 사이를 잇는 ETL과 집계 영역

실무에서는 두 DB가 따로 놀지 않습니다. 업무용 DB나 엑셀·TXT·CSV 같은 원천 데이터를 추출해 정제하고 통합한 뒤, 업무 영역별 집계 데이터로 다시 만들어 보고서와 대시보드로 보여 주는 흐름이 필요합니다. 이 과정을 ETL(추출·변환·적재)이라고 부르며, 우리비엔씨는 DW·DM·BI·OLAP·ETL 구축 기법을 적용해 이 흐름을 자동화합니다.

이때 놓치기 쉬운 것이 데이터 표준과 코드 변환 매핑입니다. 부서마다 같은 거래처를 다른 이름으로 적거나, 시스템마다 코드 체계가 다르면 아무리 좋은 분석 화면도 숫자가 맞지 않습니다. 설계 단계에서 이 기준부터 함께 정합니다.

프로그램 안에서는 이렇게 보입니다

잘 설계된 데이터는 프로그램 화면에서 엑셀 피벗처럼 자유롭게 묶고 펼쳐 볼 수 있습니다. 아래는 회원별 운동 기록을 일자·운동 분류·운동명 기준으로 집계한 화면입니다. 항목을 끌어다 놓는 것만으로 관점을 바꿀 수 있고, 결과는 바로 엑셀로 내보낼 수 있습니다.

데이터관리 프로그램의 피벗 집계 화면 - 일자, 운동 분류, 운동명별 세트수, 볼륨, 무게, 시간 합계

프로그램 안의 피벗 집계 화면: 일자·분류·항목별 합계와 소계를 바로 확인하고 엑셀로 내보냅니다

자주 묻는 질문

Q. 업무용 DB와 분석용 DB를 꼭 따로 만들어야 하나요?

규모가 크지 않다면 하나의 데이터베이스 안에 업무 테이블과 집계(요약) 영역을 함께 두는 방식으로도 충분합니다. 데이터가 많아지고 분석 요구가 늘어나면 그때 분석용 DB를 분리합니다. 처음부터 나중의 분리를 염두에 두고 설계하는 것이 비용을 줄이는 방법입니다.

Q. 엑셀로 관리하던 데이터도 옮길 수 있나요?

네. 엑셀, TXT, CSV 원천 데이터를 올리는 전용 업로드 기능을 만들어 기존 자료를 그대로 적재합니다. 옮기는 과정에서 거래처명이나 코드처럼 제각각인 값은 데이터 표준과 코드 매핑으로 정리합니다.

Q. 데이터가 계속 쌓이면 프로그램이 느려지지 않나요?

설계 단계에서 데이터가 늘어날 것을 감안해 테이블과 인덱스를 잡고, 이미 느려진 시스템은 쿼리 튜닝으로 개선합니다. 느려지는 원인과 튜닝 방법은 아래 ‘함께 보면 좋은 개발 사례’의 데이터베이스 글에 자세히 정리해 두었습니다.

이 글을 처음 쓴 2018년에도 ‘최대한 쉬운 말로 써 보자’고 다짐했던 기억이 납니다. OLTP, OLAP 같은 말은 몰라도 괜찮습니다. 지금 어떤 데이터를 어떻게 관리하고 계신지, 그리고 그 데이터로 무엇을 알고 싶으신지만 말씀해 주시면 설계는 저희가 맡겠습니다.