Rental Brain(CRM기반 렌탈ERP)

RentalBrain은 기업 고객(B2B) 대상 렌탈 자산을 관리하는 CRM 기반 ERP 시스템입니다. 담당자의 기억이나 감에 의존해 처리하던 AS/정기점검, 수납·제품 연체 관리를 시스템이 판단 기준을 가지고 자동으로 추적하도록 만드는 것이 목적입니다. "기존의 ERP가 아닌, 고객을 기억하고 판단하는 ERP"를 지향점으로 잡았습니다. Team_DevOops(6인)가 2025.11~2026.01 기간 진행했고, 저는 그중 AS/정기점검 스케줄링, 수납·제품 연체 자동화, CI/CD 설계 및 배포를 담당했습니다.

CI/CD 파이프라인(GitHub Actions → Elastic Beanstalk)은 정상적으로 돌아 배포 자체는 성공했는데, 정작 HTTPS 환경에서 프론트엔드의 API 요청이 계속 차단됐습니다. 원인을 추적해보니 프론트엔드와 백엔드의 Origin이 분리되어 있다는 걸 인지하지 못한 채 ALB 인증서와 CORS 설정을 구성한 게 문제였습니다. 프론트엔드/백엔드 ALB를 분리 구성하고, ACM 인증서를 리스너별로 명확히 연결한 뒤, Spring Security에서 전역 CORS 처리를 추가하고, CI/CD 런타임 설정을 자동화해서 해결했습니다. 부하 테스트에서 드러난 피드백 등록 API 성능 저하: QA 단계에서 nGrinder로 피드백 등록 API(POST /feedbacks/insertFeedback)를 부하 테스트했는데, 동시 요청이 늘어날수록 TPS가 2030 사이에서 불안정하게 요동치고 평균 응답 시간도 350700ms로 스파이크가 반복됐습니다. 단일 사용자 테스트에서는 드러나지 않던 문제였습니다. Hibernate SQL 로그를 확인해보니 Service 레이어에 @Transactional이 선언되어 있지 않아 트랜잭션이 Repository 레벨에서 단건으로 처리되고 있었고, 그 결과 flush/commit 타이밍이 최적화되지 못해 고부하 상황에서 DB 커넥션 점유 시간이 길어지는 게 원인이었습니다. Service 메서드에 @Transactional을 명시적으로 선언해 트랜잭션 경계를 Service 레벨로 옮기고 나서, TPS가 2428로 안정화되고 평균 응답 시간도 380450ms로 좁혀졌습니다.

Spring @Scheduled (AS/정기점검·연체 자동화) AS/정기점검이나 연체 관리는 "특정 시점이 되면 자동으로 판단해서 처리해야 하는" 성격의 로직이라, 별도 배치 프레임워크 없이도 Spring이 기본 제공하는 @Scheduled로 충분하다고 판단했습니다. 정기점검은 완료 처리와 다음 회차 생성을 하나의 흐름으로 30분마다, 연체 관리는 매일 오전 8시에 실행하도록 주기를 나눠서 업무 특성에 맞게 설계했습니다. GitHub Actions + AWS Elastic Beanstalk (CI/CD) 팀 규모상 별도 인프라 담당 없이 개발자가 직접 CI/CD를 관리해야 했기 때문에, 설정이 상대적으로 단순하고 롤백·환경 관리가 쉬운 Elastic Beanstalk를 선택했습니다. GitHub Actions로 main 브랜치 push 시 빌드→배포가 자동으로 이어지도록 구성해, 수동 배포 과정에서 발생할 수 있는 실수를 줄이고자 했습니다.

• @Scheduled 기반 스케줄러로 AS/정기점검, 수납 연체, 제품 연체를 자동화해서 담당자가 수기로 챙기지 않아도 시스템이 먼저 판단하고 생성하는 구조를 만들었습니다.
• GitHub Actions → Elastic Beanstalk CI/CD 파이프라인을 직접 설계·구축해, main 브랜치 push만으로 빌드부터 배포까지 자동화했습니다.
• 백엔드 전용 서브도메인 분리 + ALB/ACM/CORS 구조 정리로, HTTPS 환경에서 프론트-백엔드 간 통신이 안정적으로 이뤄지는 배포 구조를 확보했습니다.
• nGrinder 부하 테스트로 피드백 등록 API의 TPS 불안정(2030 → 2428)과 응답 시간 스파이크(최대 700ms → 450ms 이하)를 발견·개선해, 고부하 상황에서도 안정적인 처리량을 확보했습니다.