03. HR 데이터 인프라 구축을 위한 데이터베이스 선택

HR 데이터를 관리하기 위해 데이터베이스 도입을 결정했다면,
어떤 데이터베이스를 선택하여 구축해야 할지, 어떤 환경에서 구현될 수 있는지, 또 어떤 것이 가장 효율적일지에 대한 고민을 하게 됩니다.

 

목적은 대규모 인프라 기반의 다중 사용자 환경이나 실시간 트랜잭션 처리를 필요로 하는 환경을 만드는 것이 아니었습니다.

대신, [01. HR 데이터 웨어하우스(DW) 구축 필요성] 게시글에서 언급한 것처럼,

여러 시스템에 흩어져 있는 데이터를 분석할 때, 수집·정리·병합하는 과정에서 상당한 시간 소요와 수작업이 반복될 수 있는 문제를 해결하고,

데이터를 하나의 구조로 통합하여 분석과 의사결정에 즉시 활용할 수 있는 환경을 만드는 것이었습니다.

01. HR 데이터 웨어하우스(DW) 구축 필요성

 

 

우선적으로, 현재 제 PC 환경이 데이터 웨어하우스 구축에 적합한지와 예상 데이터 규모를 어느 정도 수용할 수 있는지 검토했습니다.

※  '데이터 웨어하우스(DW) 구축 및 운영 환경 진단'에 대한 보다 상세한 검토 내용은 아래 링크의 게시글을 참고해주세요.

04. 데이터 웨어하우스(DW) 구축 및 운영 환경 진단

 

데이터웨어하우스(DW) 구현 환경은 다음과 같습니다.

구분	사양 상세
CPU	8코어급 프로세서
RAM	32GB
Storage	512GB SSD
운영 방식	소수 사용자(3~4명) 기반의 순차적 쿼리 실행 중심
데이터 규모	약 1억 건 내외

 

위와 같은 환경은 아래 권장 사양 기준에 비추어 볼 때,  8코어급 CPU 및 32GB RAM이라면,

일반적인 집계 중심 분석 기준으로 약 1억~5억 건 규모까지는 운영 가능한 환경으로 볼 수 있습니다.

(다만, 1억 건 내외의 데이터 규모로 예상되더라도  컬럼 수, 문자열 비율, 인덱스 개수, 데이터 타입, 수행하는 연산의 복잡도(JOIN, GROUP BY, 정렬 등)에 따라 요구 자원과 성능은 크게 달라질 수 있습니다. 즉, 단순히 “건수”만으로 환경 적합성을 단정할 수는 없으며, 데이터 구조와 사용 패턴을 함께 고려해야 합니다.)

 

※ 아래 표의 데이터 건수는 평균 행 크기(컬럼 수 및 데이터 타입)에 따라 크게 달라질 수 있습니다. 
더불어, 아래의 표는 SQL 엔진 기준이며 Pandas 등 메모리 적재 방식 도구는 데이터 크기보다 훨씬 많은 RAM(3~10배)이 필요할 수 있습니다.

데이터 규모 (DB 용량)	예상 데이터 건수	권장 사양
4 GB 미만	약 1,000만 건 이하	일반 PC (2~4코어, 8GB RAM 이상 권장)
4 GB ~ 32 GB	약 1,000만 ~ 1억 건	중상급 PC (4~8코어, 16GB RAM)
32 GB ~ 128 GB	약 1억 ~ 5억 건	고성능 PC(8코어 이상, 32~64GB RAM)
128 GB 이상	5억 건 이상	서버급 인프라 (16코어 이상, 128GB+ RAM)

 

또한 앞서 언급한 것과 같이, 향후 운영 환경은 다수 사용자의 동시 접속을 전제로 하지 않으며,

실시간 대규모 트랜잭션 처리(예: 수많은 사용자가 동시에 데이터를 입력·수정·조회하는 온라인 업무 시스템) 가 필요한 구조도 아닙니다.
즉, 단독 또는 소수 사용자 기반의 분석 중심 활용 환경에 해당합니다.

 

결론적으로,  기술 자체의 고도화 역시 충분히 중요한 요소이지만,
본 환경에서는 아래와 같은 ‘현재의 데이터 규모, 비용, 데이터 구조, 사용 방식, 팀 운영 형태 등 다양한 요소를 고려한 가장 적합한 환경을 선택하는 것’이 중요하다고 판단했습니다.  

• 데이터 규모의 적정성: 사내 개인 PC 사양 내에서 충분히 수용 가능하며, *서버급 인프라가 필수적인 규모인가?
• 비용 효율성: 고가의 서비스나 서버 유지비 없이도 사내 개인 PC 내에서 안정적으로 운영할 수 있는가?
• 기능의 실효성: 비용 부담은 없으면서도 분석에 필요한 핵심 기능(쿼리 성능, 정합성 등)이 충분히 제공되는가?

 

1. 데이터베이스별 기능 비교

위 운영 환경 진단과  더불어, 적합한 데이터베이스를 선정하기 위해 주요 데이터베이스의 기능을 간략히 비교하였습니다.

※ Oracle Database는 일반적으로 엔터프라이즈 환경에서 전문 DBA 운영 체계를 전제로 사용하는 경우가 많아 본 비교에서는 제외하였습니다.

구분	PostgreSQL	MySQL	MS SQL Server	SQLite
비용	무료	무료	유료	무료
보안성	매우 높음 (세분화된 권한 관리, 강한 표준 준수)	높음 (권한 관리 지원)	매우 높음 (엔터프라이즈 수준 보안 기능 제공)	낮음 (서버형 접근  제어 체계 없음)
설치/관리 난이도	중간	쉬움	중간	매우 쉬움
데이터 무결성	매우 높음 (강한 제약조건 지원, 데이터 타입 체크 엄격)	높음 (설정에 따라 유연)	매우 높음 (강한 무결성 지원)	중간 (기본적 무결성 지원)
Tableau 호환성	매우 좋음	좋음	매우 좋음	제한적 지원
확장성	매우 높음 (플러그인 및 기능 확장 용이)	높음 (복제 기반 확장 사례 다수)	높음	낮음 (단일 파일 구조로 서버 확장성 제한)

※ 본 비교표는 AWS RDS 비교 가이드, Microsoft SQL Server 문서,

PostgreSQL/MySQL 공식 매뉴얼, Tableau 공식 커넥터 지원 문서 등의 자료를 종합 분석하여 작성되었습니다.
표의 “높음 / 낮음”은 절대적 평가가 아닌 일반적인 기능 범위와 운영 환경을 기준으로 한 상대적 비교입니다.

 

2. PostgreSQL vs MySQL 상세 비교

무료로 사용 가능하면서 우수한 성능을 제공하는 대표적인 오픈소스 데이터베이스인 두 도구를 비교하면 다음과 같습니다.

비교 항목	PostgreSQL	MySQL
SQL 표준 준수	매우 높음 (표준 SQL에 가까움)	중간 (일부 비표준 문법 존재)
WITH절 (CTE)	초기 버전부터 지원 (복잡한 쿼리를 단계별로 나누어 작성 가능 → 가독성과 유지보수에 유리)	8.0 미만 버전은 미지원, 이후 버전은 지원 (서브쿼리 중첩으로 대체 → 가독성 저하)
윈도우 함수	강력하고 다양한 계산 함수 지원	8.0 이상부터 지원
데이터 무결성	엄격한 타입 체크 (데이터 입력 오류 사전 차단)	설정에 따라 상대적으로 유연 (오류 허용 가능성 존재)
분석 쿼리 성능	복잡한 분석 SQL에 강점	단순 읽기/쓰기에 강함

 

위의 PostgreSQL과 MySQL 비교를 바탕으로, HR 데이터 관리에 가장 적합한 데이터베이스로 PostgreSQL을 선택했습니다.

• 비용: 무료 오픈소스로 엔터프라이즈급 기능을 사용 가능합니다.
• 보안성: 민감 데이터의 특성을 고려한 강력한 접근 제어와 암호화 기능을 제공합니다.
• 분석 도구 연동: Tableau와 완벽히 호환되며 다양한 BI 도구를 지원합니다.
• 기능 및 성능: 복잡한 분석 쿼리 속도가 우수하며, 분석에 필요한 SQL 기능
  (WITH절, 윈도우 함수 등)을 오래전부터 안정적으로 지원해왔습니다.
• 무결성: 엄격한 타입 체크로 잘못된 데이터 입력을 원천 방지합니다.
  
  

3. 데이터 저장소 개념 비교 (Lake / Warehouse / Mart)

데이터 웨어하우스 구축 시 자주 접하게 되는 주요 용어들을 정리했습니다.

사실 대규모 인프라에서는 각 저장소를 별도의 독립된 시스템(S3, Redshift 등)으로 분리하여 관리하곤 합니다.

 

하지만 앞에서 확인했듯이, 현재 데이터 규모는 별도의 대규모 분산 저장 시스템이 필수적인 단계는 아닌 것으로 판단되어,

단일 데이터베이스(PostgreSQL) 내에서 업무 목적에 따른 논리적 영역(Domain)을 구분하여 관리하고 있습니다.

물리적으로는 통합된 인프라를 활용해 운영 효율을 높이되, 내부적으로는 기능별로 독립된 데이터 공간을 설계함으로써

계층화(Layering)를 구현하고 향후 시스템 확장에 유연하게 대응할 수 있는 구조를 갖추도록 하였습니다.

역할	원본 저장소 (Lake)	통합 데이터 저장소 (Warehouse)	분석용 데이터 저장소 (Mart)
범위	모든 소스 데이터	모든 소스 데이터 통합	특정 분석 목적 데이터
데이터 상태	Raw (원본 그대로)	Raw → Staging → 정제	정제 완료 (분석용 최종)
데이터 유형	정형 + 반정형 + 비정형 (JSON, 이미지, 로그 등 모두)	정형 + 반정형 (테이블 형태 + JSON 등 일부 구조화)	정형 데이터
처리 방식	ELT (저장 후 변환)	ETL (변환 후 저장)	웨어하우스 내 가공
포함 관계	독립적 시스템	중심 저장소	웨어하우스의 하위 집합
예시 기술	AWS S3, Azure Blob	PostgreSQL, Redshift 등	웨어하우스 내 스키마/뷰

※ 데이터 레이크(Lake) 환경에서는 데이터를 우선 원본 그대로 저장한 뒤, 필요할 때 변환하여 사용하는 방식(ELT)이 일반적으로 활용됩니다.
반면 데이터 웨어하우스(Warehouse)에서는 분석 목적에 맞게 데이터를 정제·가공한 후 저장하는 방식(ETL)을 사용하기도 하며, 최근에는 웨어하우스 내에서 직접 변환하는 ELT 방식도 함께 활용되고 있습니다.

4. 데이터 웨어하우스 내부 계층 구조

대규모 인프라에서는 Raw, Staging, Mart 등 각 단계를 물리적으로 분리하여 관리하는 경우가 많지만,

원본 데이터를 언제든 재추출할 수 있고 분석에 즉시 활용 가능한 데이터 위주의 사용 환경이라면, 상황에 맞춰 단계를 생략하거나 통합하는 유연한 운영이 가능합니다. (예: Raw 영역 제외)

 

따라서 본 환경에서는 Raw 영역 적재를 제외하고, 단일 DB 내에서 분석에 즉시 활용 가능한 정제된 데이터를 우선적으로 관리하는 방식을 고려하였습니다.

이는 DB 내부에 분석에 즉시 활용 가능한 '정제된 데이터'를 우선적으로 관리하여 운영 환경의 자원을 최적화하기 위함입니다.

필요한 경우, 파이썬 등 외부 도구를 활용해 데이터 전처리를 거친 후 적재할 수도 있습니다.

 

한편, 데이터 재추출이 어렵거나 데이터 손실 방지해야 하는 경우에는, 원본데이터를 그대로 보존하는 Raw 영역을 별도로 두어 관리할 수 있습니다.

구분	Raw (원본 영역)	Staging (정제 영역)	Mart (분석 영역)
관리 위치	예: 사내 시스템(Source)	DB 내 정제 테이블	DB 내 분석 테이블
역할	원본 그대로 저장	로드 및 중간 처리 영역	분석용 최종 데이터 생성
데이터 상태	소스에서 추출한 원본	클리닝, 타입 변환 등 적용	비즈니스 로직 반영 완료
예시	시스템에서 추출한 사원 정보	NULL 제거, 날짜 형식 통일	이직률 분석 테이블, 집계 리포트
수정 여부	X 수정 안 함 (원본 보존)	O 정제 작업 수행 가능	O 분석 목적에 맞게 가공