Shared Ubiquitous 라이브러리 환경 분리 적용기

1. Shared Ubiquitous의 환경 간 간섭과 운영 리스크

제가 담당한 시스템은 MSA 구조로 이루어져 공통 도메인이나 유틸리티성 로직을 ‘Shared Ubiquitous’라는 라이브러리로 묶어 여러 서비스에서 공유해왔습니다.

문제는 이 라이브러리가 개발계와 운영계 구분 없이 동일한 버전을 바라보고 있었다는 점입니다. 개발 단계에서 기능을 수정하고 테스트를 위해 Nexus에 스냅샷이나 새 버전을 올리면, 같은 라이브러리를 참조하던 운영계 서비스까지 영향을 받는 구조였습니다. 이 때문에 의도치 않은 사이드 이펙트가 발생해 운영 중인 서비스에서 VOC가 들어오는 상황이 종종 있었습니다. 라이브러리 수정 하나에도 운영계 장애를 걱정해야 하다 보니, 요청 들어온 기능 개선이나 장애 대응을 위한 테스트 조처를 마음 놓고 진행하기 어려운 한계에 부딪혔습니다.

2. 해결을 위한 고민과 접근 방식

인프라 제약상 기존 저장소(Nexus)를 환경별로 분리할 수 없는 상황이었기 때문에, 저장소 분리 대신 환경별 버전을 명확히 분리하여 빌드하도록 하였습니다.

• Dockerfile의 다변화 및 빌드 타겟 분리:
  기존 단일 구조에서 벗어나 default, dev, prod 세 가지 환경에 맞춰 Dockerfile을 분리했습니다. 각 환경 특성에 맞는 버전을 주입하여 라이브러리가 타 환경에 섞이지 않도록 안정성을 확보하였습니다.
• Buildspec 파라미터화:
  해당 라이브러리를 끌어다 쓰는 개별 서비스들의 빌드 스크립트(Buildspec)를 수정했습니다. 빌드 시점에 -Penv=dev 또는 -Penv=prod 옵션을 주어, 개발 빌드 시에는 개발 전용 버전을, 운영 빌드 시에는 검증된 운영 전용 버전을 가져오도록 강제하였습니다. 이를 통해 물리적인 저장소 분리 없이 논리적인 환경 격리를 구현하였습니다.

3. 적용 후 달라진 점

이번 개선 작업을 통해 무엇보다 ‘환경 간 간섭’이 완전히 제거되었습니다. 이제 개발계에서 라이브러리를 아무리 자주 업데이트하고 테스트해도 운영 환경은 영향을 받지 않습니다. 덕분에 배포 전후로 발생하던 불필요한 VOC가 눈에 띄게 줄었고, 개발자들도 훨씬 공격적으로 기능을 검증할 수 있는 환경이 마련되었습니다.

4. 느낀 점

공통 라이브러리(Shared Library)는 코드 재사용 측면에서 강력한 도구지만, 명확한 관리 전략이 부재할 경우 오히려 시스템 전체의 리스크가 될 수 있다는 것을 체감했습니다. MSA 환경일수록 서비스 간의 독립성뿐만 아니라, 라이브러리 같은 의존성 자원에 대해서도 철저한 격리 전략이 필요함을 다시 한번 배울 수 있는 기회였습니다.

특히 사내 인프라 정책상 물리적인 저장소(Nexus) 분리가 어려운 제약 상황 속에서도, 버전 명명 규칙 체계화와 빌드 프로젝트 체계화라는 기술적 대안을 통해 실질적인 환경 격리를 구현해낼 수 있었습니다. 결국 완벽한 인프라 환경이 아니더라도, 빌드 타임의 세밀한 제어만으로도 운영 리스크를 획기적으로 낮출 수 있다는 확신을 얻었습니다.

kina.j