백오피스 고객사관리 조회 API 속도개선

Problem

백오피스 고객사 목록 조회가 Pharos, Stella, Hiworks 3개 채널 API 응답 시간에 종속되어 전체 로딩 시간이 6초 이상 소요되고, 외부 API 결과를 취합하는 구조라 DB 검색·정렬·페이징 적용도 어려웠습니다.

Decision

목록 화면에 필요한 필드를 백오피스 기준 조회 모델로 구성하고, 채널 API 실시간 의존을 제거한 단일 DB 조회 구조로 전환해 검색·정렬·페이징을 DB 기준으로 수행하는 방향을 진행하고 있습니다.

• 6.16초 응답 구조 분석
• 채널 API 실시간 의존 제거
• 목록 전용 summary 테이블 검토
• 단일 DB 조회·검색·정렬·페이징 전환

급여장부 God Service 분리와 V2 전환

Problem

기존 급여장부는 HTTP DTO와 엔터티가 혼재되고, SalLgrService 중심의 비대한 서비스 구조로 인해 비즈니스 규칙 파악과 신규 요구사항 반영이 어려웠습니다.

Decision

정규직 급여장부 V2를 기준으로 Command/Query 유즈케이스를 분리하고, 도메인 모델과 HTTP DTO를 명확히 나누는 방식으로 점진 전환을 진행하고 있습니다.

• 등록/수정 저장 유즈케이스 통합
• HTTP DTO와 도메인 모델 분리
• Command/Query 서비스 분리
• V2 API 병행 운영

하이웍스-파로스 전자결재 콜백 정합성 설계

Problem

전자결재 기안은 팝업 종료, postMessage, 비동기 콜백 수신 시점이 서로 달라 기안 완료 여부와 업무 데이터 상태가 어긋날 수 있었습니다.

Decision

request_hash 기반 임시 전자결재 데이터와 기안완료 데이터를 분리하고, 콜백 미수신 시 하이웍스 문서 조회 API로 정합성을 보정할 수 있는 구조로 설계했습니다.

사원번호 채번 구조 개선

Problem

사원과 임시근로자 테이블의 사원번호 unique 제약이 분리되어 있고, 채번과 중복 검증이 유즈케이스 외부에 흩어져 동시 요청 시 중복 위험이 있었습니다.

Decision

유즈케이스별 동일 분산락 키를 적용하고, 자동 채번·수동 입력·중복 검증을 하나의 도메인 흐름으로 통합해 사원번호 생성 책임을 내부로 모았습니다.

핵심 쿼리 성능 개선

Problem

품목 목록 조회와 백오피스 고객사 조회에서 잘못된 조인과 비효율적인 조회로 사용자 대기 시간이 길어졌습니다.

Decision

조인 로직과 조회 조건을 재검토해 품목 목록 조회는 22초에서 0.6초로, 백오피스 고객사 조회는 6초에서 3초로 개선했습니다.

Oracle·MSSQL Slow Query 튜닝

Problem

서울대학교병원 CTMS와 디자인스킨 ERP 운영 과정에서 복잡한 조회와 실행 계획 문제로 일부 쿼리 응답 시간이 최대 23분까지 길어지는 병목이 발생했습니다.

Decision

실행 계획을 분석하고 인덱스, 조인 조건, DBMS별 힌트 적용을 재검토해 핵심 조회 쿼리를 최대 23분에서 0.6초 수준까지 개선했습니다.

급여 계산/저장 구조 리팩토링

Problem

지급항목 금액을 과세/비과세 상세 금액으로 분리 저장해야 하지만, 기존 저장 흐름은 단일 금액 중심이라 계산 context와 result 분리가 필요합니다.

Decision

V2 저장 흐름 이후 계산 context와 result 구조를 점진적으로 분해하고, legacy adapter로 기존 amt 호환성을 유지하는 방향을 검토하고 있습니다.

• 과세/비과세 상세 테이블 추가
• 기존 amt 호환성 유지
• SalCalcInput/Context/Result 분리
• Legacy adapter 기반 점진 전환