빌드 설정 정리로 재현 가능한 개발 환경 확보
목차
빌드 설정 정리는 겉보기에 별거 아닌 작업처럼 보인다. 실제로 이번에 건드린 것도 비즈니스 로직 한 줄 없이 설정 파일 6개 수정, JSP 파일 제거, 버전 명시화가 전부다. 커밋 메시지만 보면 "그냥 잡무 처리했네" 하고 넘어갈 수 있는 작업. 근데 팀장 포지션으로 여러 프로젝트를 동시에 굴려보면서 느낀 건, 이런 작업을 제때 안 하는 게 나중에 가장 예측하기 힘든 장애의 씨앗이 된다는 거다.
이번 작업에서 처리한 내용은 크게 세 가지였다. kingdriver 경로와 test 경로에 남아 있던 JSP 파일 제거, implicit 의존성을 explicit으로 교체, 그리고 불필요한 빌드 단계 제거.
implicit 의존성이 왜 문제인가
버전을 명시하지 않은 의존성은 빌드 시점마다 다른 코드를 가져올 수 있다. "최신 버전 자동 사용"은 편리해 보이지만 실제로는 시한폭탄이다.
# 이전: 버전 미지정
dependency.version=LATEST
# 이후: 버전 고정
dependency.version=2.4.1
문제는 이게 터지는 타이밍이다. 로컬에서 멀쩡하게 돌아가던 게 CI 파이프라인에서 갑자기 실패하거나, 개발 서버는 괜찮은데 스테이징에서 동작이 달라지는 상황. 원인 추적해보면 빌드 시점이 달라서 라이브러리 버전이 다르게 들어간 경우가 꽤 많다. 특히 팀 규모가 커질수록 각자 로컬 캐시 상태가 달라서 "내 컴퓨터에서는 되는데"가 반복된다.
의존성 버전을 고정하면 이 변수가 하나 없어진다. 같은 설정 파일로 빌드하면 어디서 돌려도 같은 결과가 나와야 하는 게 기본인데, 그 전제가 깨져 있으면 디버깅 비용이 배로 든다.
| 항목 | 변경 전 | 변경 후 |
|---|---|---|
| 버전 관리 | implicit (자동) | explicit (고정) |
| 빌드 재현성 | 환경마다 다를 수 있음 | 동일 보장 |
| 의존성 업데이트 시기 | 빌드할 때마다 자동 | 명시적 결정 필요 |
| 수정 파일 수 | - | 6개 |
| 기능 영향 | - | 없음 |
트레이드오프는 있다. 버전을 고정하면 보안 패치나 버그픽스가 포함된 새 버전을 자동으로 받지 못한다. 그래서 의존성 업데이트를 "언제 할지 모르는 미래"로 미루면 안 되고, 주기적으로 올려주는 루틴이 필요하다. 자동화가 없으면 이게 결국 또 밀린다.
JSP 파일 정리가 왜 필요했나
kingdriver 경로와 test 경로에 남아 있던 JSP 파일들은 이미 실제로 사용되지 않는 파일들이었다. 이런 파일이 남아 있으면 몇 가지 문제가 생긴다.
- 빌드 시 포함 여부가 불분명해져서 배포 아티팩트 크기 관리가 안 됨
- 새 팀원이 봤을 때 현재 사용 중인 코드인지 아닌지 판단하기 어려움
- 보안 스캔 결과에 노이즈가 낌 (실제로 쓰지 않는 코드도 취약점 대상으로 잡힘)
특히 test 경로에 오래된 JSP가 남아 있으면 테스트 커버리지 통계도 왜곡된다. 테스트 대상이 아닌 파일이 포함되면 커버리지 숫자 자체를 신뢰하기 어려워진다.
제거 작업 자체는 단순하지만, 지우기 전에 확인하는 과정이 더 중요했다. 실제로 어딘가에서 참조하고 있지 않은지, include 체인에 연결된 파일은 없는지 확인하고 나서야 삭제했다. 검색 한 번 돌리고 grep으로 확인하는 과정이 귀찮아서 생략하면 나중에 런타임에서 404나 NullPointerException으로 돌아온다.
정기 루틴 없이는 계속 쌓인다
이번 작업이 필요했던 근본 원인은 이런 정리가 그때그때 안 됐기 때문이다. 처음에 JSP 하나 남겨두는 건 별것 아닌데, 그게 수십 개 쌓이면 건드리기 무서워진다. 의존성도 마찬가지로, 한 버전 올리는 건 쉬운데 열 버전 뒤처진 걸 한꺼번에 올리려면 breaking change가 여러 개 겹쳐서 어디서 깨진 건지 추적하는 데 시간이 훨씬 많이 든다.
자동화로 커버할 수 있는 영역은 자동화해두는 게 맞다.
- 의존성 버전 알림: 새 버전이 나오면 PR을 자동 생성하거나 알림을 받는 방식
- 보안 취약점 스캔: 주기적으로 돌려서 방치된 취약점 없는지 확인
- 빌드 상태 모니터링: 설정 변경 이후 즉시 빌드가 돌아서 결과 확인
자동화가 없으면 수동으로 챙기는 데 한계가 있고, 결국 "나중에 해야지"가 쌓인다. 이번 작업이 계기가 돼서 해당 영역 정기 점검 루틴을 잡기로 했다. 설정 파일 수준의 변경이 비즈니스 로직보다 덜 중요해 보이지만, 개발 환경이 흔들리면 그 위에 쌓는 모든 작업이 다 흔들린다. 재현 가능한 빌드를 유지하는 게 팀 전체 생산성에 직결되는 이유가 거기 있다.
댓글 0
첫 댓글 달아줘.