SAP GUI 100% 의존 환경에서 React 기반 웹 게이트웨이로 전환했습니다. 회계·인사·재고·구매·영업 5개 모듈을 RFC로 연동하고 협력사 47개사에 셀프서비스를 개방한 12개월 프로젝트.
SAP GUI 의존도 100% — 사내 PC가 아니면 업무 불가, 외부 협력사는 시스템 접근 자체가 불가능해 모든 발주·입고를 메일·전화로 처리. 모바일 미지원으로 출장 시 결재 적체가 일상이었습니다.
SAP 표준을 깨지 않으면서 외부 협업을 가능하게 만드는 게이트웨이 패턴.
SAP 표준 트랜잭션을 그대로 유지하고 외부에는 Spring Boot 게이트웨이만 노출. 표준 업그레이드 영향도 최소화.
SAP RFC는 호출당 평균 400-800ms. 자주 조회되는 마스터 데이터는 Redis로 5분 TTL 캐싱해 응답시간을 1/4로.
사내는 AD 기반 SSO로 무중단 인증, 외부 협력사는 별도 IDP로 분리해 보안 경계를 명확히.
한꺼번에 5개를 띄우지 않고 구매 → 재고 → 영업 → 회계 → 인사 순서. 각 단계마다 2개월 안정화.
5개 모듈 라우팅 + RBAC 권한 매트릭스 + 한/영 i18n. SAP UI 패턴을 차용하되 모바일 우선으로 재설계.
SAP JCo로 RFC 호출, 자주 쓰는 마스터는 Redis 캐싱. 트랜잭션 경계는 BAPI 단위로 명확히 끊음.
표준 트랜잭션 유지. 커스텀 BAPI 14개 신규, Z 테이블 최소화로 업그레이드 영향도를 줄임.
사내 AD + 외부 IDP 이중 트러스트. 모든 RFC 호출은 MS-SQL Audit 테이블에 로깅 (SOX 대응).
롤아웃 후 6개월 운영 평균 (2024.03-08). 식별 정보는 익명 처리되었으며 모든 수치는 비율 또는 시스템 지표값입니다.
RFC 호출 캐싱과 권한 매핑 레이어를 게이트웨이 안에서 분리한 설계가 응답속도를 안정화시켰습니다. 마스터 데이터 조회는 Redis 5분 TTL로 평균 320ms, 트랜잭션 호출은 캐시 우회로 안전성을 유지. 이중 트러스트(AD + External IDP) 덕분에 협력사 온보딩이 평균 1일 이내로 단축되었습니다.
ABAP과 Spring Boot 간 트랜잭션 경계 — 특히 CommitWork 처리. 초기에는 BAPI 호출 후 자동 커밋을 가정했다가 잠금 누수가 발생했고, 명시적 BAPI_TRANSACTION_COMMIT을 별도 단계로 분리하면서 라운드트립이 한 번 더 늘었습니다. 최종적으로는 BAPI 묶음을 ABAP 함수 모듈로 한 번 더 래핑해 해결.
처음부터 SAP Gateway / OData 서비스를 노출해서 풀어냈을 것입니다. JCo + 커스텀 BAPI 14개를 만드느라 4개월이 소요됐는데, OData를 썼다면 메타데이터 기반으로 React Query와 자연스럽게 연결됐을 것이고 상태관리 코드량도 30~40% 줄었을 것으로 추정합니다.