- HERO는 HR 데이터를 하나의 흐름으로 통합하고, 시각화된 대시보드와 역할 기반 기능 제공을 통해
인사 업무 효율과 조직 생산성을 향상시키는 HR 관리 시스템입니다.
"인사 데이터가 여기저기 흩어져 있어요." "현황을 보려면 여러 화면을 눌러야 해요." "결재나 근태 변경 알림을 놓치기 쉬워요."
- HR 데이터 분산으로 인한 전체 흐름 파악의 어려움
- 시각화 부족으로 인사 데이터 활용 한계
- 역할별 권한 관리 미흡으로 인한 보안·업무 비효율
- 이벤트(결재, 근태 변경 등)에 대한 즉각적인 인지 부족
-
📊 HR 통합 대시보드: 근태·급여·평가 데이터를 시각화하여 한 화면에서 제공
-
🔔 실시간 알림 시스템: 근태, 결재, 평가 등 주요 이벤트 발생 시 즉각적인 알림 제공
-
🧑💼 역할 기반 권한 관리: 관리자 / 부서장 / 사원별 기능 및 접근 권한 세분화
-
📈 데이터 기반 의사결정: 조직 현황과 변화 추이를 기반으로 합리적인 판단 지원
HERO는 프론트엔드와 백엔드, AI가 분리된 구조로 개발되었습니다.
아래 링크를 통해 각 레포지토리 및 배포 환경을 확인할 수 있습니다.
🖥️ 프론트엔드 레포지토리 : GitHub - HERO Frontend
🛠️ 백엔드 레포지토리 : GitHub - HERO Backend
🤖 AI 레포지토리 : GitHub - HERO AI
🌐 실제 배포 사이트 : 🔗 hero-hr.site
📄 프로젝트 소개
📝 요구사항 명세서
🗓️ WBS
🧩 DDD
🗄️ ERD
🖥️ 화면 설계서 / Wireframe
🕹️ 시스템 아키텍처
🔁 CI / CD
🧪 테스트 결과서
이번 프로젝트에서 맡은 역할
- 급여 도메인 DB 설계부터 백엔드 로직, 프론트 UI 연계까지 담당
- 관리자/사원 권한에 따른 기능 분리와 접근 제어를 고려하여 API 구조를 설계함
잘한점
- 급여, 수당, 공제, 배치, 명세서 등 복잡한 급여 구조를 단순한 CRUD가 아니라 실제 HR시스템에서 발생할 수 있는 상태변화와 업무 흐름 중심으로 모델링함
- 기능 구현 과정에서 단순히 동작 여부에 집중하기보다 데이터 흐름과 상태 간의 관계를 고려하여 구조적으로 접근함
아쉬운점
- 초기 설계 내용을 문서로 충분히 공유하지 못해서 팀 내 소통 비용이 발생한점이 아쉬움
- 기능 완성도를 높이려다 일정 관리가 다소 타이트해진 부분이 있음
- 시간 제약으로 인해 리팩토링을 충분히 진행하지 못한점이 아쉬움
배운점
- 문제가 발생했을 때 결과만 수정하는 것보다 원인을 이해하고 구조적으로 접근하는 것이 중요하다는 것을 체감함
- 팀 프로젝트에서는 개인의 이해보다 팀원이 이해할 수 있는 설명과 공유가 더 중요하다는것을 깨달음
- 도메인 이해 없이 기능을 구현하면 유지보수 비용이 급격히 증가할 수 있음을 느꼈고, 이후 핵심 비즈니스 로직은 코드보다 구조 설계에 더 집중하게 됨
- 프론트와 백엔드가 분리된 영역이 아니라 하나의 사용자 경험이라는 관점에서 개발을 진행해야 한다는것을 배움
- TypeScript를 사용하며 명확한 타입 정의가 런타임 오류를 줄이고 협업 시 이해도를 높인다는 것을 체감함
- 스토어(Pinia)를 통해 전역 상태를 무분별하게 사용하기보다 역할과 책임을 기준으로 상태를 분리, 관리하는 중요성을 배움
이번 프로젝트에서 맡은 역할
- 평가 도메인 UI/UX 설계
- 평가 도메인 DB 모델링
- 평가 도메인 기능 개발
- 파이썬 서버 구축 및 AI 기능 개발
잘한점
- 프로젝트 초기에 계획했던 3차 목표인 'RAG를 사용한 AI기능을 개발'까지 완료함.
- 기능 구현에 있어서 유효성 검사, 예외 처리 코드를 추가하여 에러 발생 가능성을 낮춤.
- 원활한 협업을 위해 사전에 약속한 코딩 컨벤션을 지키면서 코드를 작성함.
- 처음 사용하는 프레임워크인 Fast API와 RAG 지식을 공부하며 기능에 적용하기 위한 노력을 함.
아쉬운점
- 평가 가이드 위반을 탐지하는 기능에서 AI의 답변을 일정하게 추출하도록 기능 개발을 하지 못함.
- 회사 평가에 대한 지식이 부족하여 평가 프로세스가 어색한 부분이 있음.
배운점
- HR 시스템의 특징과 현업에서 사용되는 용어 및 평가 방식.
- 권한에 따른 사용자 기능 분할과 Security Config에서 경로 접근 권한 설정의 중요성.
- 스프링 스케줄러를 사용하여 원하는 시간에 원하는 서비스를 작동시키는 로직.
- Fast API의 서버 구축 방법 및 텍스트를 원하는 chunk 단위로 잘라 임베딩 시키고 벡터 데이터베이스에 저장하는 로직.
- RAG를 사용하여 주어진 데이터에서 원하는 값을 추출하는 로직.
이번 프로젝트에서 맡은 역할
- 결재 도메인 API 및 UI 구현
- 결재 연동 관련 도메인 API 검증 및 로직 수정
잘한 점
- 비즈니스 규칙을 적용하여 서비스 로직을 구성했으며, 예외처리 및 동시성 제어를 수행하여 기술적인 완벽을 기함.
- 이벤트 리스너를 활용함으로써 타 도메인과의 API 연동 과정에서 기능이 정상적인 동작을 하는지 검증한 점.
아쉬운 점
- 긴 시간이 주어졌음에도 기획단계에서 주제가 명확하지 않았음.
- 요구사항 및 해당 요구사항에 대한 비즈니스 규칙을 세심하게 검토하지 못했던 점.
- 주장에 대한 설득이 부족하다는 핑계로 아이디어를 제시하지 못함.
배운 점
- 코드 구현(API, 프론트) 전, 도메인 규칙과 기준을 명확히 세우지 않아 개발 후반부 수정 비용이 급증함.
- 명확한 기준 수립이 개발 효율과 완성도를 결정함을 체감.
- 막연한 기능 구현이 아닌, '어떤 문제를 해결하기 위한 기능인가'에 대한 명확한 목적의식이 필수적임을 학습.
- '요구사항 명세 → 프로세스 설계 → 구현'이라는 정석적인 순서의 중요성을 몸소 깨달음.
- 어떤 문제를 해결하기 이전에 해당 도메인에 대한 이해가 해결책을 끌어내는 열쇠라는 것을 깨닫음.
이번 프로젝트에서 맡은 역할
- 보안 중심 인증 시스템 설계: Spring Security 및 JWT 기반 이중 토큰(Access/Refresh) 체계 구축 및 AES-256 기반 개인정보 암호화 저장
- 비밀번호 재설정 프로세스: JWT 보안 토큰과 이메일을 연동하여 10분 유효 시간 제한을 적용한 비밀번호 변경 로직 구현
- 인사 데이터 관리 인프라: 신규 사원 추가, 계층형 조직도 조회 및 데이터 정합성 확보를 위한 인사 변동 로그(Audit Log) 시스템 구축
- 데이터 기반 승진 관리 시스템: 시간 가중치 기반 평가 알고리즘 개발 및 이벤트 리스너를 활용한 승진 후보 자동 선발·결재 프로세스 연동
- 자동화 발령 및 퇴직 프로세스: Spring Scheduler를 활용한 발령일 00시 직급 자동 업데이트 및 퇴직자 계정 권한 회수·개인정보 마스킹 처리
잘한 점
- 심층 방어 기반의 데이터 보안 확보: 민감한 인사 데이터에 대해 애플리케이션(AES-256) 및 데이터베이스(마스킹) 레벨의 보안 정책을 적용하여 시스템 안정성 강화
- 스케줄링 기반의 운영 정교화: Spring Scheduler를 활용해 데이터 효력 발생 시점(00:00)에 맞춘 자동 동기화를 구현하여 수동 작업 리스크 제거 및 인사 정보 현행성 확보
- 이벤트 기반의 시스템 결합도 해소: 결재 승인과 인사 업데이트 로직을 비동기 이벤트로 분리하여 각 도메인 간의 의존성을 낮추고 확장성 있는 구조 설계
아쉬운 점
- 코드 리뷰 프로세스의 지속성 부족: 프로젝트 후반부 일정 가속화로 초기 수립한 '전원 PR 리뷰' 규칙이 완벽히 유지되지 못한 점이 아쉽습니다. 차기 프로젝트에서는 체계적인 마일스톤 관리를 통해 개발 전 과정에서 코드 품질을 유지할 수 있는 환경을 구축하고자 합니다.
- 인사 데이터 활용의 고도화 미흡: 승진 심사 시 평가 데이터를 조회하는 기초 기능에 집중한 점이 아쉽습니다. 향후 가중치 알고리즘을 고도화하여 승진 후보자 추천 및 적정 부서 배치 등 데이터 기반의 인사 통계 기능을 강화할 계획입니다.
배운 점
- 목적 지향적인 프레임워크 활용: Spring Security, Scheduler, Event Listener 등 프레임워크의 핵심 기능을 비즈니스 요구사항에 맞춰 최적화하고 실제 서비스에 적용하는 기술적 숙련도 습득
- 도메인 분석과 설계의 유기적 관계 체감: 인사 시스템(HRIS)의 복잡한 로직을 구현하며, 도메인 이해가 부족한 설계는 큰 매몰 비용을 발생시킨다는 것을 체감했습니다. 이를 통해 코드 작성 전 요구사항을 명확히 정의하는 과정의 중요성을 깊이 깨달았습니다.
이번 프로젝트에서 맡은 역할
- 근태/휴가 DB 모델링
- 근태/휴가 도메인 기능 개발
- 근태/휴가 UI 설계
잘한점
- 근태/휴가 데이터 조회 기능을 구현할 때, 복잡한 조회는 JPA, 단순 조회는 MyBatis를 활용하여 상황에 맞게 분리 적용하였다.
- 다른 도메인에서 발생하는 이벤트를 이벤트 리스너 기반으로 연계하여, 도메인 간 흐름이 자연스럽게 이어지도록 로직을 구현했다.
- 설정 페이지에서 출근 시간을 재설정할 때, 지각 기준 시간도 함께 변경되도록 처리하여 정책 변경이 실제 근태 판정 로직에 일관되게 반영되게 했다.
아쉬운점
- 근태 기록에서 지연 출근 보고서가 제출되었을 때, 기존 ‘지각’ 상태를 ‘정상 출근’으로 자동 전환하는 도메인 내 처리 로직을 완성하지 못했다.
- 더미 데이터 구성 과정에서 휴가 데이터와 근태 데이터가 겹치는 케이스가 발생하거나, 서류 심사에서 반려되지 않아야 하는 대상에게도 반려 상태가 적용되는 등 케이스를 더 촘촘히 검증하지 못했다.
배운점
- JPA에서는 JPQL 문법을 통해 조회 쿼리를 구성할 수 있으며, 객체 중심으로 데이터 접근을 설계할 수 있다는 점을 익혔다.
- 프론트엔드에서 API로 받은 값을 페이지 단위로만 사용하는 것이 아니라, Pinia로 상태를 임시 저장/공유하여 여러 컴포넌트에서 재사용하고 관리할 수 있다는 점을 체감했다.
- 이벤트 리스너 어노테이션을 활용하면 도메인 간 결합도를 낮추면서도, 비즈니스 로직을 깔끔하게 확장할 수 있다는 점을 배웠다.
이번 프로젝트에서 맡은 역할
- 알림 도메인 UI/UX 설계
- 알림 도메인 DB 모델링
- 알림 도메인 기능 개발
- CI/CD 구축
- 시스템 아키텍처 구축
잘한점
- WebSocket 기반 실시간 알림 시스템을 이벤트 기반 아키텍처로 설계 및 구현
- 알림 타입별 분기 처리 및 관리자 알림 발송 등 확장 가능한 알림 도메인 설계
- AWS Elastic Beanstalk, RDS 등을 활용한 클라우드 인프라 설계 및 배포 환경 구성
- GitHub Actions를 활용하여 프론트엔드와 백엔드 자동 배포 파이프라인 구축
아쉬운점
- WebSocket 연결 끊김이나 재연결 시나리오에 대한 상황 대처 미흡
- 알림 성능 최적화 (대량 알림 발송, 캐싱 전략 등) 고려 부족
배운점
- GitHub Actions를 통한 CI/CD 파이프라인 구축 및 자동화 배포 경험
- WebSocket과 이벤트 기반 아키텍처를 활용한 실시간 통신 구현 방법
- AWS 클라우드 인프라(Elastic Beanstalk, RDS) 설계 및 운영 경험
- 배포 환경에서 발생하는 다양한 이슈(CORS, 타임존, DB 연결) 트러블슈팅 능력 향상
🦸 HERO - 보이는 인사관리, 통합 HR 대시보드
Made by Team C4