Skip to content

14 Retrospective

Jump to bottom
dddd0ng edited this page Jan 12, 2026 · 1 revision

프로젝트 회고

곽동근

이번 프로젝트에서 맡은 역할

  • 급여 도메인 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 연결) 트러블슈팅 능력 향상

Clone this wiki locally