개발 slecs

시스템 식별자 하드코딩 11건을 설정 계층으로 통합

목차

오늘 sysId 하드코딩 11건을 auth-config 계층으로 전부 흡수했다. ORDER, CONTACT_DEPOSIT, BOARD_POLICY 세 도메인이 새로 편입됐고, DML 스크립트도 함께 나갔다.


왜 지금 이걸 정리했나

하드코딩된 sysId가 코드베이스 곳곳에 박혀 있다는 건 사실 팀 내에서 이미 꽤 오래된 기술 부채였다. 한두 군데면 "다음 스프린트에"라고 미룰 수 있지만, 이번에 ORDER 쪽 웹 레이어를 건드리다가 같은 값이 세 군데 이상 복붙된 걸 보고 그냥 손 떼기가 어려웠다.

sysId는 시스템 식별자 성격의 값이라 웬만해선 런타임 중에 바뀌지 않는다. 그래서 "어차피 고정값인데 뭐가 문제야"라는 반론이 나올 수 있다. 근데 그게 함정이다. 고정값이기 때문에 더 위험하다. 값이 바뀌는 시점이 오면(시스템 이전, 멀티테넌트 확장, 테스트 환경 분리 등) 어디를 고쳐야 하는지 아무도 모른다. grep 해보면 나오긴 하는데, 그 grep 결과를 신뢰할 수 있느냐가 문제다. 놓치는 파일이 반드시 생긴다.

이번에 ORDER, CONTACT_DEPOSIT, BOARD_POLICY 세 도메인 각각의 web 레이어에서 총 11건을 잡아냈다. 거기에 유틸 계층 2개 파일까지 포함됐다는 게 더 문제였다. 유틸이 sysId를 직접 알고 있으면 유틸의 재사용성이 도메인에 종속되는 구조가 되어버린다.


작업 구조와 변경 범위

영역 변경 파일 작업 내용
ORDER order/web/내부 클래스 sysId 하드코딩 → config 주입 방식으로 교체
CONTACT_DEPOSIT contactdeposit/web/내부 클래스 동일 패턴 적용
BOARD_POLICY board/web/내부 클래스 동일 패턴 적용 + 신규 DML
유틸 계층 utl/내부 클래스 × 2 sysId 직접 참조 제거, config 위임
DB DML_20260514_board_policy.sql BOARD_POLICY 관련 초기 데이터 삽입

세 도메인 중 BOARD_POLICY가 신규라서 DML도 같이 나갔다. ORDER와 CONTACT_DEPOSIT은 기존에 어느 정도 운영 중이던 도메인이라 코드 변경만으로 정리됐다.

유틸 쪽 파일 2개가 포함된 게 이번 작업의 핵심 포인트였다. 웹 컨트롤러에서 sysId를 쓰는 건 "이 컨트롤러가 이 시스템 전용이다"라는 의미라 어느 정도 감수할 수 있다. 근데 유틸이 sysId를 하드코딩하고 있으면 그 유틸을 다른 시스템에서 재사용하는 순간 조용히 잘못된 값으로 동작한다. 타입 에러도 안 나고, 컴파일도 잘 된다. 그냥 런타임에 이상한 데이터가 나올 뿐이다.

코드 패턴은 대략 이런 방향으로 정리했다.

// Before — 하드코딩
public class OrderController {
    private static final String SYS_ID = "SYS_001"; // 직접 박혀있음
    ...
}

// After — config 주입
public class OrderController {
    @Value("${app.auth.sys-id}")
    private String sysId;
    ...
}

설정 파일 한 곳만 바꾸면 전체 도메인에 반영되는 구조. 환경별(dev/stg/prod) 분리도 자연스럽게 가능해진다.


이런 작업을 팀 관점에서 어떻게 볼까

솔직히 이런 정리 작업은 기능 티켓도 아니고, QA 통과 기준도 명확하지 않아서 우선순위를 밀리기 쉽다. 근데 총괄 입장에서 보면 이게 쌓일수록 신규 팀원 온보딩 비용이 올라가고, 도메인 간 경계가 불명확해진다.

11건이라는 숫자는 많은 것 같지만, 실제로는 패턴이 반복돼서 하나 잡으면 나머지는 같은 방식으로 따라간다. 어렵다기보다는 "누군가 시간 내서 끊어내야 하는" 작업이다. 이번에 ORDER 쪽 작업하면서 발견한 김에 CONTACT_DEPOSIT, BOARD_POLICY까지 같이 흡수한 건, 나중에 각각 별도 PR로 처리하면 맥락을 다시 불러오는 비용이 더 든다는 판단에서였다.

코드리뷰 관점에서도 하드코딩 sysId는 리뷰어가 "이거 config로 빼면 어때요?" 코멘트 달기 좋은 지점이다. 이걸 컨벤션으로 못 박아두면 신규 기능 PR에서 같은 패턴이 또 등장하는 걸 미연에 방지할 수 있다.

DML까지 함께 나간 BOARD_POLICY 신규 도메인은 처음부터 올바른 구조로 시작했다는 점에서 작은 성과다. 기술 부채는 레거시에서만 쌓이는 게 아니라 신규 도메인을 "일단 빨리" 만들 때도 똑같이 쌓인다. 그 시작점을 잡아두는 게 장기적으로 훨씬 낫다.

끝.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.