쇼핑몰과 운영서버 간 공급 모듈 통신 초기 세팅
목차
쇼핑몰 플랫폼과 운영서버 사이에 공급 모듈 통신 연결 작업을 처음 세팅했다. 규모 자체는 크지 않았는데, 막상 건드려보니 고려할 지점이 꽤 있었다.
공급 모듈이라는 게 대부분 사내 운영 흐름의 핵심 어딘가에 박혀 있다. 재고 동기화든 발주 상태 반영이든, 쇼핑몰 프론트와 백오피스 운영서버가 같은 데이터를 바라보게 만들어야 사용자 화면과 실제 재고 사이의 괴리가 생기지 않는다. 이번 작업이 그 연결고리의 초기 세팅에 해당했다. 기능 자체가 없던 영역이라 설계보다 "이 구조에서 어떻게 붙이는 게 맞나"를 먼저 정리하는 데 시간을 더 썼다.
Spring MVC + MyBatis 구조에서 공급 모듈 붙이기
프로젝트 구조는 Spring MVC + MyBatis, 뷰는 JSP. 수정한 파일은 내부 클래스 두 개와 common.js다.
내부 클래스 쪽은 역할이 명확하게 나뉘어 있었다. 하나는 요청 파라미터 검증·바인딩, 다른 하나는 비즈니스 로직과 쿼리 결과 매핑. 이 구조에서 공급 모듈 통신을 끼워 넣으려면 요청 진입 시점에서 파라미터가 제대로 들어왔는지부터 걸러야 한다. null이나 빈 값이 그냥 내려가면 SQL에서 터지는 게 아니라 운영서버 쪽 처리 중간에 조용히 실패하는 경우가 있어서, 바인딩 시점에 명시적으로 검증을 넣었다.
// 파라미터 검증 - 빈 값·null 처리를 입구에서 막음
if (StringUtils.isBlank(param.getSupplyCode())) {
throw new IllegalArgumentException("supplyCode는 필수값입니다.");
}
MyBatis XML 쪽 쿼리는 동적 조건이 들어가는 부분에서 <if test> 분기를 좀 정리했다. 기존에 유사한 쿼리가 있었는데 공급 모듈용으로 그대로 복붙하면 컬럼 매핑이 어긋나는 지점이 생겨서, ResultMap을 새로 잡고 명시적으로 매핑했다.
common.js 수정은 화면 쪽 공통 유틸 함수 조정이었다. 특별한 건 없었고, 기존 흐름에 영향 안 가도록 함수 하나 추가하는 수준.
실제로 고민한 것들
트랜잭션 범위가 제일 신경 쓰였다. 운영서버와 통신이 얽히는 경우, 내 서버 DB를 먼저 쓰고 운영서버 쪽 처리가 실패하면 롤백 범위를 어디까지 잡아야 하는지가 애매하다. 이번 세팅에서는 운영서버 통신 결과를 받아서 로컬 DB에 반영하는 순서로 처리했고, 어노테이션으로 트랜잭션 경계를 명확하게 지정했다. 외부 시스템 호출을 트랜잭션 안에 물리면 커넥션 점유 시간이 늘어나서 나쁜데, 초기 세팅 단계라 우선 안전한 방향으로 잡아뒀다. 트래픽이 붙으면 재검토할 포인트다.
예외 처리 방향도 선택이 필요했다. RuntimeException을 그냥 위로 전파할 건지, 잡아서 응답으로 변환할 건지. 운영서버 쪽 타임아웃이나 일시적 오류를 사용자 화면에 그대로 노출하면 안 되니까, 이번엔 공급 모듈 호출 레이어에서 잡아서 정해진 에러 응답으로 내려주는 방식을 택했다. 다만 catch에서 그냥 삼키면 운영 디버깅이 안 되니까, 예외 로그는 반드시 남기도록 했다.
| 처리 방식 | 장점 | 단점 |
|---|---|---|
| RuntimeException 전파 | 코드 단순, 상위 핸들러에서 일괄 처리 | 사용자에게 의도치 않은 에러 노출 가능성 |
| 레이어에서 잡아서 변환 | 응답 형태 통제 가능 | 예외 흐름이 명시적으로 안 보임 |
로그 전략은 입출력 핵심값을 INFO로 남기는 방식. 운영에서 문제가 생겼을 때 파라미터가 뭐가 들어왔는지, 쿼리 결과가 어떻게 나왔는지 추적할 수 있어야 한다. DEBUG로 남기면 운영 로그 레벨에서 안 찍히는 경우가 많아서, 중요한 분기점 전후는 INFO로 박았다.
배포는 로컬 기동 확인 → 개발 DB 반영 → 배포 순서로. 공급 모듈 연동이라 개발 DB에서도 운영서버 엔드포인트를 어디 바라보게 할지 확인이 필요했다. 환경별로 URL이 달라서 common.js에서 분기 처리한 부분도 이 시점에 같이 확인했다.
총괄 포지션에서 이런 초기 세팅 작업을 직접 하면, 나중에 팀원이 이 모듈 위에 기능을 쌓을 때 구조 질문을 받는 사람이 나라는 걸 알고 들어가게 된다. 그래서 코드 자체보다 "이 구조로 잡은 이유"를 주석이나 커밋 메시지에 남기는 걸 더 신경 썼다. 트랜잭션 경계나 예외 처리 선택 근거가 코드에 없으면, 나중에 수정하는 사람이 맥락 없이 바꿀 수 있다.
작은 세팅이지만 이런 연동의 초기 설계가 나중에 고치기 제일 귀찮은 부분이 된다. 빠르게 붙이고 넘어가는 것보다 조금 더 명시적으로 잡아두는 게 맞다고 판단했다.
댓글 0
첫 댓글 달아줘.