[코드가 환경을 모르는 구조 6/7] 컨테이너는 왜 폭발하는가

문제 상황

• 실제 DB·메시지 큐·검색엔진을 쓰는 통합 테스트의 장점은 크지만, 10분을 넘는 실행 시간과 불안정성 때문에 개발자가 돌리지 않게 되는 문제
• Spring TestContext의 컨텍스트 키가 @MockBean, @DirtiesContext, 일부 동적 프로퍼티로 쉽게 달라져 컨텍스트와 Testcontainers가 복제되는 현상
• 멀티모듈 환경에서 dirty context가 누적되며 CI 메모리와 Docker 데몬 부담이 커지고, 테스트 스위트가 점점 무력화되는 흐름

원인 분석

• Testcontainers의 본질적 병목은 Docker 기동 자체보다 컨텍스트 분화로 인한 컨테이너 수 증가
• 컨텍스트 캐시 미스와 명시적 캐시 제거가 새 컨테이너 생성을 반복 유발
• 속도가 느려질수록 통합 테스트를 스킵하게 되고, 신뢰 저하가 더 큰 부식으로 이어지는 구조

해결 방법

• Gradle BuildService를 빌드 수준 싱글턴으로 사용해 MySQL 컨테이너 하나를 빌드 전체에서 공유
• 모듈별 논리 DB를 분리하고 Liquibase로 각 스키마를 초기화해 격리 유지
• 테스트는 자기 스키마와 시나리오만 알게 하고, 접속 정보와 생애주기는 BuildService가 주입·관리

성능/운영 포인트

• 첫 Task에서 지연 기동, 마지막 Task 후 자동 정리로 컨테이너 생애주기 단순화
• 멀티모듈에서도 컨테이너 복제를 줄여 CI 시간을 단축하는 방향
• configuration cache, parallel 실행, 서로 다른 빌드 동시 실행 시 범위 차이 점검 필요