[12일차] HR 데이터 설계, 모델링은 이렇게 시작하자

노랑별이 2025. 5. 12. 17:44

데이터를 다룬다는 것은 단순히 엑셀 파일을 정리하거나, 차트를 그리는 수준이 아니다. 그보다 더 앞단에서, '어떻게 데이터를 구조화할 것인가'를 고민하는 것이 중요하다. 바로 그 출발점이 데이터 모델링이다.

나는 HR 데이터를 제대로 다룰 수 있는 HR 애널리스트가 되고 싶다. 그리고 그 첫걸음은 데이터를 저장하고 설계하는 데이터베이스 구조를 이해하는 것에서 시작된다고 믿는다. 지난 6개월간의 데이터 분석 부트캠프와 전 직장에서의 HR 경험을 통해 이 중요성을 깨닫게 되었다. 오늘은 데이터 모델링의 기본 개념과 HR 데이터를 어떻게 모델링할 수 있는지에 대해 정리해본다.

데이터 모델링이란 무엇인가?

데이터 모델링은 데이터를 어떤 구조로 저장할 것인지 설계하는 작업이다. 쉽게 말해, 현실 세계의 개념(사람, 조직, 업무 등)을 테이블과 필드로 어떻게 표현할지 정리하는 것이다.

가장 기본적인 구성은 개체(Entity), 속성(Attribute), 관계(Relationship) 세 가지다.

개체: 예) 직원(Employee), 부서(Department), 채용공고(Job Posting)
속성: 직원의 이름, 입사일, 부서코드 등
관계: "한 부서는 여러 명의 직원을 가질 수 있다"는 관계

데이터 모델링은 현실의 구조를 데이터베이스에 옮겨 놓는 일이다. 그리고 그 모델링이 잘못되면 분석도, 보고도, 활용도 엉망이 되기 쉽다. 이전 직장에서는 이런 체계적인 데이터 설계 없이 여러 엑셀파일로 HR 데이터를 관리했는데, 한 가지의 일을 할 때 여러 엑셀 파일에 작업하느라 누락되는 부분이 종종 있어 많은 어려움을 겪었다.

HR 데이터에 모델링을 적용하면?

부트캠프에서 처음 HR 데이터를 분석할 때, 우리는 데이터가 어떻게 설계되어야 활용하기 좋은지 생각하지 않고 분석부터 시작했다. 하지만 분석이 진행될수록, 테이블 간의 연결이 자연스럽지 않으면 불필요한 중복이 생기고, 통계가 왜곡된다는 것을 알게 되었다.

예를 들어, 다음과 같은 구조를 생각해볼 수 있다.

주요 테이블(예시)

employees (사번, 이름, 부서ID, 직급ID, 입사일, 상태)
departments (부서ID, 부서명, 위치)
positions (직급ID, 직급명, 직급레벨)
attendance (근무ID, 사번, 날짜, 출근시간, 퇴근시간, 근무유형)
performance (사번, 평가년도, 평가점수, 평가등급)
trainings (교육ID, 교육명, 분류, 교육일자)
training_history (사번, 교육ID, 수료여부)

이렇게 테이블을 정규화(normalization)하면 중복 없이 데이터를 체계적으로 관리할 수 있다. 예를 들어 직급명이 변경되었을 때, 하나의 테이블만 수정하면 전체 데이터에 반영되기 때문에 유지보수가 편해진다.

HR 데이터 모델링에서 자주 마주치는 실수

중복 데이터
하나의 테이블에 모든 정보를 다 넣으면 관리가 어렵고 데이터 오류가 생기기 쉽다. 예: 직원 테이블에 부서명, 직급명, 교육명까지 다 들어가면 비효율적이다. 전 직장에서 이런 방식으로 데이터를 관리했었는데, 데이터가 늘어날수록 일관성을 유지하기 어려웠다.
관계 누락
예를 들어 직원-교육 간의 관계는 '수강 내역'을 통해 연결돼야 한다. 단순히 교육 테이블만 존재하고 수강 이력을 따로 저장하지 않으면 분석이 불가능해진다.
정규화 부족
데이터를 분석하기 위해선 불필요한 중복을 줄이고, 외래키(Foreign Key)를 활용해 테이블 간 연결을 명확히 해야 한다. 이를 통해 쿼리도 더 간결하게 작성할 수 있다.

실무에서 쓸 수 있는 설계 원칙 3가지

사람 중심의 구조 설계
HR 데이터는 '사람'이 중심이다. 직원 테이블은 항상 핵심 개체로, 다른 모든 데이터(근태, 교육, 평가 등)는 이 사번을 기준으로 연결되어야 한다. 부트캠프에서 진행했던 프로젝트에서도 이 원칙을 적용했더니 분석이 훨씬 용이해졌다.
시간 정보를 반드시 포함
모든 HR 이벤트는 시간 축을 가지고 있다. 입사일, 퇴사일, 교육일, 평가일 등 시간 정보가 없으면 트렌드 분석이나 시점 기준 분석이 불가능하다. 이전 직장에서는 이런 시간 정보가 누락된 경우가 많아 정확한 이직률 계산이나 근속 분석에 어려움을 겪었다.
상태 정보를 함께 저장
예: 퇴사자 구분, 수료 여부, 평가 등급 등. 상태 값은 필터링과 집계에 꼭 필요하다. 부트캠프에서 배운 데이터 필터링 기법들을 이렇게 설계된 데이터에 적용하면 효율적으로 분석을 수행할 수 있다.

데이터 모델링과 보안의 균형

HR 데이터는 민감한 개인정보를 많이 포함하고 있어 보안이 매우 중요하다. 모델링 단계에서부터 데이터 접근 권한을 어떻게 관리할지, 어떤 정보를 암호화할지 고려해야 한다. 이는 단순히 기술적인 문제가 아니라 내부 정책과 법적 규제(개인정보보호법 등)와도 밀접하게 연관되어 있다.

예를 들어, 직원의 주민등록번호나 계좌번호 같은 민감 정보는 별도 테이블로 분리하고 접근 권한을 엄격하게 관리하는 방식을 고려할 수 있다. 이런 부분도 데이터 모델링 단계에서 미리 고려해야 한다.

마치며

나는 앞으로 직접 ERD(Entity-Relationship Diagram)를 그려보고, 이를 바탕으로 SQL 쿼리를 작성하는 연습을 할 것이다. 최근에는 dbdiagram.io 같은 도구를 사용하면 쉽게 ERD를 만들 수 있고, 이를 토대로 HR 데이터베이스를 가상 설계해보는 연습도 가능하다.

부트캠프에서 배운 SQL 지식과 이전 직장에서의 HR 경험을 결합하여, 실제로 내가 분석했던 가상 HR 데이터의 ERD를 그려봤더니 데이터 간의 관계가 훨씬 명확하게 이해되었다. 이런 훈련을 반복하면, 실무에 들어가서도 데이터 구조를 빠르게 파악하고 정확하게 활용할 수 있을 것이다.

나는 더 많은 HR 데이터를 다루고 싶고, 복잡한 업무 흐름을 정돈된 데이터베이스로 바꾸는 설계자가 되고 싶다. HR 전문성과 데이터 분석 역량을 결합해 조직의 의사결정에 실질적인 가치를 제공하는 HR 애널리스트가 되는 것이 나의 목표이다. 나는 데이터를 쌓는 사람, 연결하는 사람, 구조화하는 사람이 될 것이다.