Week 20
기간: 2026.03.30 - 2026.04.03
커리큘럼: 최종 프로젝트 (HR 인사시스템 SaaS 플랫폼) - ERD 설계 및 도메인 구조화
1. Facts — 무엇을 했나?
< 성과관리·평가관리·면담관리 중심 ERD 설계 >
- 지난주에 정리한 요구사항을 바탕으로, Performance Management와 Evaluation 도메인의 핵심 엔티티를 ERD로 구체화했다.
kpi_template → goal → performance_record → performance_record_history흐름으로 이어지는 구조를 설계해, KPI 템플릿, 목표 계층, 실적 입력, 변경 이력 관리가 자연스럽게 연결되도록 구성했다.- 평가 영역에서는
evaluation_policy → evaluation → calibration_log구조를 통해 평가 정책, 다면평가 결과, 보정 이력이 분리되도록 설계했다. - 면담 관리에서는
meeting_record와meeting_action을 통해 정기 면담 기록과 후속 액션아이템을 함께 관리할 수 있도록 모델링했다. peer_assignment를 추가해 다면평가에서 동료 평가자 배정과 진행 상태 추적이 가능하도록 설계했다.
2. Feelings — 어떻게 느꼈나?
- 요구사항을 테이블 구조로 옮기면서, 문서로만 보던 기능들이 실제로 어떤 데이터 흐름을 가져야 하는지 더 선명하게 느껴졌다.
- 특히 목표와 실적, 평가와 보정, 면담과 액션이 각각 따로 노는 것이 아니라 서로 유기적으로 이어져야 한다는 점이 인상적이었다.
- 단순히 테이블을 나열하는 작업이 아니라, HRM SaaS의 운영 방식 자체를 설계하는 과정처럼 느껴져서 더 흥미로웠다.
- 이전보다 “무엇을 만들 것인가”보다 “어떤 관계와 흐름으로 관리할 것인가”를 생각하게 되어 설계 관점이 한 단계 더 깊어진 느낌이었다.
3. Findings — 무엇을 배웠나?
- KPI와 OKR은 결국 데이터 구조로도 구분되어야 한다는 점을 체감했다. KPI는 템플릿과 측정값 중심으로 운영되고, OKR 성격의 목표는 계층 구조와 상위-하위 목표 연결이 중요했다.
goal에parent_goal_id,owner_type,visibility,status같은 항목을 넣으면서, 조직/개인 단위 목표 관리와 공개 범위 제어가 함께 필요하다는 것을 배웠다.performance_record_history를 별도로 둔 이유처럼, HR 시스템에서는 단순 현재값보다 변경 이력과 감사 가능성이 중요하다는 점을 다시 확인했다.evaluation_policy에 가중치, 등급 방식, 편향 점검, 동료 평가 인원 기준을 포함하면서, 평가 제도는 기능이 아니라 정책 자체가 데이터로 관리되어야 한다는 점을 이해했다.meeting_record와meeting_action을 분리한 구조를 통해, 면담은 기록에서 끝나는 것이 아니라 후속 실행으로 이어져야 의미가 있다는 점을 정리할 수 있었다.
4. Future — 다음에 어떻게 활용할까?
- 이번 ERD를 바탕으로 도메인별 엔티티 관계를 더 정교하게 다듬고, 누락된 제약조건과 상태 전이를 점검할 계획이다.
- 다음 단계에서는
goal과evaluation중심으로 API 명세와 화면 흐름을 연결해, 실제 서비스 시나리오에 맞는 구조로 확장할 예정이다. performance_record_history,calibration_log같은 이력성 테이블은 감사와 추적 관점에서 중요하므로, 로그 정책과 변경 기준도 함께 정리할 필요가 있다.- 이후에는 이 ERD를 기반으로 권한 설계, 트랜잭션 경계, 멀티테넌시 적용 방식까지 이어서 검토해볼 생각이다.
- ERD 초안 - 성과관리·평가관리·면담관리 중심 서비스 (노란색 영역)
🧩 마무리 한 줄
“요구사항을 데이터 구조로 옮기며 HR SaaS의 뼈대를 만들었다 — 이제 이 ERD를 기준으로 실제 흐름을 채워갈 차례다!”
Eazy하게