배경 / 문제
서비스 운영 중, 지점별로 다른 기획 요구사항이 생기며 기능 커스터마이징 필요성이 대두되었다.
초기에는 각 지점마다 전체 소스를 복제해 별도 저장소로 운영하였는데, 다음과 같은 문제를 야기했다:
•
공통 기능 변경 시 모든 저장소를 개별 수정
•
코드 중복으로 인해 공수 및 유지보수 비용 증가
•
CI/CD 관리, 배포 이슈까지 이어짐
업무 배정의 핵심은 공통 코드를 단일 버전으로 병합하고, 지점별 특수 로직만 분리하는 구조로 개편하는 것이었다.
해결 방안 검토
전임 개발자는 API URI를 prefix 기준으로 분기하는 방향으로 접근 중이었다.
•
/api/a/…, /api/b/… 등 URI 레벨에서 기능 분리
•
단점: 프론트엔드도 URI 분기를 모두 인지하고, 환경 설정 필요 → FE/BE 모두 공수 증가
대신 선택한 접근 방식은 다음과 같다.
•
기존의 Spring Profile 환경변수 구분 기능 활용
•
공통 인터페이스는 유지하고, 구현체만 각 프로파일에 맞게 분리
•
프론트엔드는 단일 API URI 사용, 백엔드는 환경별로 자동 구현체 분기
결과 및 회고
Profile 설정에 따라 실제 DI되는 구현체가 자동으로 선택됨
FE는 단일 API만 호출하면 됨 → 프론트 부담 없음
public interface NodeService {
void insertNode(NodeInsertRequest nodeInsertRequest);
...
}
Java
복사
@Service
@Profile({"profile-A"})
public class AAreaSeparateImpl implements NodeService {
@Override
@Transactional
public void insertNodeInfo(NodeInsertRequest nodeInsertRequest) {
...
장비 저장
...
}
}
Java
복사
@Service
@Profile({"profile-B"})
public class BAreaSeparateImpl implements NodeService {
@Override
@Transactional
public void insertNodeInfo(NodeInsertRequest nodeInsertRequest) {
...
장비 저장
...
}
}
Java
복사
