우리는 지난 50개의 포스팅을 통해 스프링 부트 생태계의 거대한 아키텍처와 다양한 기술 스택들을 낱낱이 해부하며 애플리케이션을 완성해 왔습니다. 하지만 현업에서 모든 비즈니스 로직을 다 짜고 나서 "기능 개발 다 끝났습니다!"라고 당당하게 말하는 주니어 개발자에게, 산전수전 다 겪은 시니어 개발자나 테크 리드가 가장 먼저 던지는 싸늘한 질문은 단 하나입니다.
"그래서, 테스트 코드는 다 작성하셨나요?"
수만 줄의 코드가 유기적으로 얽혀있는 실무의 거대한 마이크로서비스(MSA) 환경이나 대형 모놀리식(Monolithic) 환경에서, 자동화된 테스트 코드가 없는 애플리케이션은 브레이크가 고장 난 상태로 시속 200km로 달리는 스포츠카와 같습니다. 언제 어디서 누구의 코드와 충돌하여 대폭발을 일으킬지 모르는 시한폭탄인 셈입니다. 하지만 수많은 주니어 개발자들이 스프링 부트에서 테스트를 처음 작성할 때, 가장 무식하고 위험하며 성능을 갉아먹는 방법인 @SpringBootTest 애노테이션 하나에 무비판적으로 의존하는 치명적인 실수를 저지릅니다. "어라? 제 로컬 PC 노트북에서는 테스트가 완벽하게 다 초록불(Pass) 떴는데, 젠킨스(Jenkins)나 GitHub Actions 빌드 서버에만 올리면 DB 테스트가 깨지면서 빨간불(Fail)이 떠요!"라는 끔찍한 비명을 지르며 밤을 새우게 되죠.
이번 51단계 포스팅에서는 통합 테스트(Integration Test)와 슬라이스(Slice) 테스트의 명확한 경계와 철학을 긋고, 우리를 달콤하게 속이는 로컬 H2 인메모리 DB의 치명적인 한계와 배신을 부숴버리며, 실제 프로덕션(운영) 환경과 100% 동일한 완벽하게 격리된 DB 환경을 제공하는 테스트 진영의 구세주, Testcontainers (테스트컨테이너) 아키텍처에 대해 상세히 알아보겠습니다.
1. 무거운 망치를 함부로 휘두르지 마라: @SpringBootTest의 양날의 검
스프링 부트로 프로젝트를 처음 생성(Spring Initializr)하면 기본적으로 src/test/java 폴더 아래에 만들어져 있는 @SpringBootTest 애노테이션은 초보자에게는 매우 달콤한 마법의 단추입니다. 이 애노테이션을 테스트 클래스 상단에 붙이기만 하면, 스프링 부트 프레임워크는 실제 프로덕션 애플리케이션을 톰캣(Tomcat) 서버에 기동 할 때와 완전히 똑같이 수백, 수천 개의 모든 Bean(Controller, Service, Repository, Redis Configuration, Kafka Producer 등)을 스프링 컨텍스트(ApplicationContext) 메모리에 통째로 우겨넣어 버리는 거대한 작업을 시작합니다.
이것은 컴포넌트 간의 연동을 확인하기에는 엄청난 장점이지만, 동시에 개발 생산성을 파괴하는 최악의 단점이 됩니다. 당신이 단순히 장바구니에 아이템을 하나 담는 아주 간단한 컨트롤러의 로직 하나만을 테스트하고 싶은데, 스프링 컨텍스트 전체가 무겁게 로드되느라 테스트 한 번 실행에 10초~20초씩 금쪽같은 시간이 낭비되기 때문입니다. 실무 프로젝트에서 테스트 코드가 1,000개가 넘어간다고 상상해 보십시오. 만약 모든 테스트 클래스에 @SpringBootTest가 발려있고 컨텍스트 캐싱(Context Caching)이 자꾸 깨진다면, 전체 테스트 스위트(Suite)를 한 번 돌리는 데 30분, 1시간이 걸리게 됩니다. 결과적으로 개발자들은 코드를 수정할 때마다 기다리는 지루함을 견디지 못해 아예 로컬에서 테스트를 돌리지 않고 감으로 코딩을 한 뒤 서버에 배포해 버리는 끔찍한 악순환에 빠지게 됩니다. 따라서 실력이 뛰어난 시니어 개발자들은 이 무거운 쇠망치를 함부로 휘두르지 않습니다. 대신 목적에 맞게 스프링 컨텍스트를 아주 얇게 저며서(Slice) 필요한 녀석들만 가볍게 메모리에 로드하는 슬라이스 테스트(Slice Test) 기법을 적극 활용하여 초고속 피드백 루프를 완성합니다.
💡 목적별 슬라이스 테스트(Slice Test) 쪼개기 전략
- @WebMvcTest: 프레젠테이션 계층, 즉 컨트롤러(Controller)의 로직(URL 라우팅 매핑,
@Valid를 통한 파라미터 유효성 검증, JSON 직렬화/역직렬화)만을 순수하게 테스트하고 싶을 때 사용합니다. 무거운 DB 커넥션 풀이나 Service, Repository 계층의 Bean은 아예 메모리에 띄우지 않습니다. 의존하는 Service 객체는@MockBean을 사용하여 가짜 객체로 채워 넣습니다. 스프링 컨텍스트 로딩 시간이 1~2초 내외로 빛의 속도입니다. - @DataJpaTest: 영속성 계층, 즉 DB 쿼리와 Repository(JPA) 계층만 집중적으로 테스트할 때 사용합니다. 기본적으로 인메모리 DB(H2)로 자동 스위칭되며, Jpa 관련 설정만 로드합니다. 가장 강력한 장점은 이 애노테이션 내부에
@Transactional이 포함되어 있어서, 각각의 단위 테스트가 끝날 때마다 데이터를 자동으로Rollback(롤백)시켜 다음 테스트의 데이터 정합성에 전혀 영향을 주지 않는 완벽한 샌드박스를 만들어준다는 점입니다.
2. H2 데이터베이스의 치명적 배신: "왜 로컬에선 성공하는데 운영에선 터지죠?"
Repository 레이어나 통합 테스트를 작성할 때 수많은 레퍼런스 서적이나 옛날 블로그 강의들은 빠르고 가벼운 인메모리 DB인 H2 Database를 application-test.yml에 세팅하여 사용하라고 맹목적으로 추천합니다. H2는 테스트를 돌리기 위해 무거운 MySQL이나 Oracle을 컴퓨터에 일일이 설치할 필요도 없고, 설정 텍스트 몇 줄이면 휘발성 메모리 위에 DB가 뚝딱 만들어지니 초보자에게는 무척 편안한 안식처입니다. 하지만 현업 실무의 치열한 전장에서는 H2 DB를 사용한 테스트를 극도로 혐오하고 배척합니다.
그 이유는 너무나도 명백합니다. 우리의 실제 라이브 운영 환경(Production)은 H2가 아니라 MySQL, PostgreSQL, MariaDB 같은 거대하고 묵직한 실물 RDBMS를 사용하고 있기 때문입니다. 만약 당신이 네이티브 쿼리(Native Query)나 JPQL을 짤 때 MySQL 전용 특화 함수인 GROUP_CONCAT, DATE_FORMAT, 혹은 JSON 컬럼 처리 함수를 사용했다면 어떻게 될까요? 혹은 JPA가 생성하는 인덱스(Index)나 데이터베이스의 트랜잭션 격리 수준(Isolation Level), 테이블 락(Lock) 메커니즘이 MySQL과 H2가 미세하게 다르게 동작한다면 어떻게 될까요? 당신의 테스트 코드는 H2 환경에서 무조건 초록불(Success)을 띄우며 "완벽해!"라고 거짓말을 하겠지만, 그 코드가 젠킨스를 타고 프로덕션 서버에 배포되어 진짜 MySQL과 만나는 순간 곧바로 500 Internal Server Error를 뿜으며 장렬하게 폭파됩니다. 테스트 코드가 당신의 뒤통수를 치고 배신한 것입니다. 완벽하고 신뢰할 수 있는 테스트란, 반드시 '프로덕션과 100% 동일한 RDBMS 엔진과 버전을 가진 환경'에서 수행되어야만 진정한 가치가 있습니다.
3. 테스트 컨테이너(Testcontainers): 일회용 실물 DB를 소환하는 도커의 마법
"그렇다면 개발팀의 모든 신입 사원 PC마다 로컬에 MySQL 8.0을 깔라고 강요하고, 젠킨스 빌드 서버에도 공용 MySQL을 하나 띄워놓고 거기로 테스트 커넥션을 연결하란 말인가요?" 아닙니다. 그것은 테스트 실행 시 누군가가 넣은 데이터 때문에 다른 사람의 테스트가 실패해 버리는 '상태 의존성 오염(State Pollution)'이라는 또 다른 지옥의 문을 여는 행위입니다.
이 극악무도한 딜레마를 완벽하게 타파하기 위해 등장한 현대 클라우드 네이티브 백엔드 테스트의 절대 표준 아키텍처가 바로 Testcontainers (테스트컨테이너)입니다. Testcontainers는 당신의 자바 JUnit 테스트 코드와 OS 백그라운드에 깔려있는 Docker(도커) 데몬 엔진을 다이렉트로 연결하는 기적의 라이브러리입니다.
// 🚨 H2의 거짓말을 끝장내는 완벽한 DB 격리의 시작: Testcontainers 설정
@SpringBootTest
@Testcontainers // JUnit5 런타임에 내 PC의 도커(Docker) 엔진과 다이렉트 통신을 시작하라!
class OrderRepositoryTest {
// 💡 마법의 시작: 테스트가 구동될 때, 실제 운영 환경과 똑같은 MySQL 8.0.32 버전을 도커 컨테이너로 새로 띄워라!
@Container
static MySQLContainer<?> mySqlContainer = new MySQLContainer<>("mysql:8.0.32")
.withDatabaseName("testdb")
.withUsername("test")
.withPassword("test");
// 💡 도커가 띄운 MySQL은 매번 랜덤한 포트(Port) 번호를 가집니다.
// 이 랜덤한 접속 주소를 스프링 부트의 application.yml 설정값에 동적으로 덮어씌워 줍니다!
@DynamicPropertySource
static void overrideProperties(DynamicPropertyRegistry registry) {
registry.add("spring.datasource.url", mySqlContainer::getJdbcUrl);
registry.add("spring.datasource.username", mySqlContainer::getUsername);
registry.add("spring.datasource.password", mySqlContainer::getPassword);
registry.add("spring.datasource.driver-class-name", mySqlContainer::getDriverClassName);
}
@Autowired
private OrderRepository orderRepository;
@Test
@DisplayName("MySQL 환경에서 주문 데이터가 정상적으로 저장되는지 완벽 격리 테스트")
void saveOrder_Test() {
// 이 쿼리는 H2 장난감 DB가 아니라, 방금 도커에서 뜬 따끈따끈하고 깨끗한 진짜 MySQL로 날아갑니다!
Order savedOrder = orderRepository.save(new Order("맥북 프로", 3500000));
assertThat(savedOrder.getId()).isNotNull();
assertThat(savedOrder.getProductName()).isEqualTo("맥북 프로");
}
}Testcontainers의 소름 돋는 동작 원리 및 라이프사이클
위 코드를 작성하고 테스트 플레이(Run) 버튼을 누르면 내부적으로 엄청난 일들이 벌어집니다. JUnit이 실행되면서 Testcontainers 라이브러리가 백그라운드의 도커 데몬에게 "야, 지금 테스트용 MySQL 8.0 컨테이너 하나만 빨리 구워와!"라고 명령합니다. 도커는 눈 깜짝할 새에 완벽히 깨끗하고 독립적인 MySQL 8.0 인스턴스를 하나 구동하고 호스트 PC와 포트를 매핑합니다. 그리고 @DynamicPropertySource가 이 랜덤하게 생성된 포트 주소를 스프링 부트 환경 변수에 강제로 주입합니다. 스프링 부트는 원래 yml에 적혀있던 주소를 무시하고, 방금 생성된 도커 안의 MySQL로 커넥션을 맺습니다. 수백 개의 레포지토리 테스트가 '실제 MySQL 환경'에서 치열하게 검증됩니다. MySQL의 고유 문법이나 제약 조건, 락 메커니즘이 프로덕션과 100% 동일하게 작동합니다.
그리고 모든 테스트 클래스 실행이 종료되는 순간, Testcontainers 라이브러리는 도커에게 "임무 완료. 방금 띄운 MySQL 인스턴스 쓰레기를 메모리에서 통째로 날려버려!"라고 명령하여 컨테이너를 완전히 폭파(Destroy)시킵니다.
이로써 개발자는 H2의 달콤한 거짓말에 속을 필요도 없고, 로컬 PC나 서버에 번거롭게 MySQL 데몬을 직접 세팅할 필요도 없이, 언제 어디서(로컬이든 젠킨스든) ./gradlew test 명령어 한 방이면 완벽하게 독립적이고 무결한 프로덕션급 테스트 환경을 얻게 되었습니다. 진정한 테스트 마스터들은 데이터베이스뿐만 아니라 Redis, Kafka 브로커, Elasticsearch 등 사실상 운영 환경에 존재하는 거의 모든 외부 의존성 기술 스택을 이 Testcontainers를 활용하여 일회용 샌드박스로 완벽하게 격리해 냅니다.
정리하며
이번 51단계 포스팅에서는 무거운 @SpringBootTest 쇠망치의 남용이 가져오는 속도 저하와 생산성 파괴의 비극을 짚어보고, @WebMvcTest 같은 얇은 슬라이스 테스트의 쾌감, 그리고 H2 인메모리 DB의 환상을 처참히 박살 내며 운영과 100% 동일한 격리 샌드박스 환경을 구축해 내는 Testcontainers의 렌더링 기적을 뼈 때리게 파헤쳐 보았습니다. 테스트 코드를 잘 짠다는 것은 단순히 assertTrue 검증문을 예쁘게 타이핑하는 것이 아니라, 이처럼 외부 요인의 간섭을 차단하고 완벽하게 격리된 아키텍처를 세팅하는 능력에 달려있습니다. 자, 이렇게 DB 환경과 뼈대는 완벽하게 세팅되었습니다. 그렇다면 정작 테스트 코드 내부의 "논리적 흐름"은 어떻게 짜야 동료 개발자들이 내 코드를 보고 감탄을 금치 못할까요? TDD를 넘어 기획서의 인간 언어를 그대로 테스트 코드로 옮겨 적는 위대한 철학!
다음 52단계 포스팅에서는 "JUnit 5와 Mockito 심화: BDD(행위 주도 개발)의 Given-When-Then 철학과 엣지 케이스(Edge Case) 커버리지를 뚫어내는 단위 테스트의 정석"에 대해 아주 치밀하게 딥다이브 해보겠습니다!
