MySQL 미드레벨 테스트·코드품질 기술면접

Mock 객체는 가장 빠르지만 SQL 문법이나 트랜잭션 동작을 검증할 수 없어 Repository 계층의 인터페이스 테스트에만 적합합니다. H2 같은 In-Memory DB는 빠른 속도와 격리성을 제공하지만 MySQL과 SQL 방언이 달라 프로덕션과 차이가 발생할 수 있습니다. Docker 컨테이너로 실제 MySQL을 띄우는 방식은 가장 느리지만 실제 환경과 동일한 테스트가 가능하여 통합 테스트나 복잡한 쿼리 검증에 적합합니다. 실무에서는 단위 테스트는 Mock이나 H2로 빠르게 실행하고, CI 파이프라인에서는 Docker MySQL로 통합 테스트를 수행하는 계층적 전략을 사용합니다. Testcontainers 라이브러리를 활용하면 Docker 기반 테스트를 쉽게 구성할 수 있습니다.

테스트의 @Transactional은 각 테스트를 격리하고 데이터베이스를 깨끗한 상태로 유지하는 장점이 있어 테스트 간 의존성을 제거합니다. 하지만 실제 커밋이 발생하지 않아 커밋 후 트리거되는 이벤트나 TransactionalEventListener의 AFTER_COMMIT 단계를 테스트할 수 없습니다. 또한 지연 로딩 예외나 플러시 타이밍 이슈를 놓칠 수 있습니다. 실제 커밋을 검증하려면 @Commit 어노테이션을 사용하거나, 테스트 메서드에서 명시적으로 커밋하고 @AfterEach에서 데이터를 정리하는 방식을 사용합니다. 또는 TransactionalTestExecutionListener를 커스터마이징하여 특정 테스트만 커밋하도록 설정할 수 있습니다. 실무에서는 대부분의 테스트는 롤백을 사용하고, 커밋 동작이 중요한 시나리오만 별도로 테스트합니다.

마이그레이션 스크립트는 프로덕션 복제본 데이터베이스에서 실행하여 실제 데이터 볼륨에서의 성능을 측정해야 합니다. 롤백 스크립트는 마이그레이션 후 즉시 실행하여 원래 상태로 복구되는지 데이터 정합성을 검증하는 자동화 테스트를 작성합니다. 인덱스 생성은 ALGORITHM=INPLACE, LOCK=NONE 옵션을 사용했는지 확인하고, 대용량 테이블에서 실행 시간과 락 발생 여부를 측정합니다. 데이터 마이그레이션 로직은 배치 단위로 처리되는지, 실패 시 재시도 가능한지, 트랜잭션 경계가 적절한지 검증합니다. CI 파이프라인에 마이그레이션 테스트 단계를 추가하여 빈 데이터베이스와 샘플 데이터가 있는 데이터베이스 양쪽에서 마이그레이션을 실행하고 검증합니다. 프로덕션 배포 전에는 스테이징 환경에서 실제 데이터 스냅샷으로 최종 검증을 수행합니다.

SQL 파일은 데이터베이스 종속적이고 스키마 변경 시 유지보수가 어렵지만, 대량의 초기 데이터 로딩에는 빠릅니다. 코드 기반 Fixture는 타입 안정성과 IDE 지원을 받지만, 보일러플레이트 코드가 많아질 수 있습니다. 데이터 빌더 패턴은 테스트에 필요한 속성만 명시적으로 설정하고 나머지는 기본값을 사용하여 가독성과 유지보수성이 좋습니다. 실무에서는 ObjectMother 패턴이나 TestDataBuilder 패턴을 사용하여 재사용 가능한 테스트 데이터 생성 함수를 만듭니다. 복잡한 연관 관계는 Fixture Monkey 같은 라이브러리로 랜덤 데이터를 생성하되, 테스트 의도와 관련된 속성만 명시적으로 설정합니다. 각 테스트는 자신이 필요한 데이터만 생성하는 Given 단계를 명확히 하여 테스트 간 결합도를 낮춥니다.

먼저 프로덕션 데이터의 통계적 분포를 분석하여 대표적인 시나리오들을 식별합니다. 테스트 데이터는 최소/평균/최대 볼륨과 균등/편향 분포를 포함하여 준비합니다. JUnit의 ParameterizedTest로 다양한 데이터 조건에서 쿼리를 실행하고, EXPLAIN 결과를 파싱하여 type이 ALL이 아닌지, Extra에 Using filesort가 없는지 자동으로 검증합니다. 실행 시간은 여러 번 측정하여 평균과 표준편차를 계산하고, 임계값을 초과하면 테스트를 실패시킵니다. MySQL의 Performance Schema나 프로파일링을 활성화하여 쿼리 실행 단계별 시간을 측정합니다. 리팩토링 전후의 쿼리를 모두 실행하여 성능 개선을 정량적으로 비교하는 벤치마크 테스트를 작성합니다. CI 파이프라인에서 nightly build로 대용량 데이터 성능 테스트를 실행하고, 성능 메트릭을 시계열로 저장하여 성능 회귀를 모니터링합니다.

ExecutorService로 고정된 스레드 풀을 생성하고, CountDownLatch로 모든 스레드가 준비될 때까지 대기했다가 동시에 실행되도록 합니다. 예를 들어 재고 100개에 200개의 동시 구매 요청을 보내고, 최종 재고가 0이고 성공한 구매가 정확히 100건인지 검증합니다. 비관적 락이나 낙관적 락의 동작을 검증하려면 트랜잭션 격리 수준을 명시적으로 설정하고, 예외 발생 횟수와 재시도 로직을 확인합니다. 테스트 신뢰성을 높이기 위해 충분한 반복 횟수를 설정하고, CyclicBarrier로 모든 스레드가 정확히 같은 시점에 시작하도록 합니다. Awaitility 라이브러리로 비동기 결과를 폴링하며 검증합니다. 실패한 경우 로그를 상세히 남겨 어떤 스레드에서 문제가 발생했는지 추적 가능하게 합니다. 로컬에서는 반복 횟수를 줄이고 CI에서는 충분한 횟수로 실행하여 간헐적 실패를 감지합니다.

코드 리뷰 체크리스트는 1) 쿼리에 적절한 WHERE 조건과 인덱스 사용 여부, 2) SELECT *이 아닌 필요한 컬럼만 조회, 3) Prepared Statement 사용으로 SQL Injection 방지, 4) 페이지네이션 누락 여부, 5) 트랜잭션 범위가 적절한지 확인합니다. N+1 쿼리는 Hibernate의 Batch Fetching이나 쿼리 카운터 라이브러리로 감지하고, 테스트에서 예상 쿼리 수를 검증합니다. SonarQube나 PMD 같은 정적 분석 도구로 SQL Injection 패턴을 탐지하고, Flyway나 Liquibase의 린트 도구로 스키마 변경을 검증합니다. ORM 사용 시 지연 로딩으로 인한 N+1, 영속성 컨텍스트 크기 증가, 불필요한 Dirty Checking을 주의해야 합니다. 실무에서는 쿼리 로그를 활성화하고 슬로우 쿼리 임계값을 낮게 설정하여 개발 단계에서 문제를 조기 발견합니다. 코드 리뷰 시 EXPLAIN 결과를 함께 공유하여 실행 계획을 검토하는 문화를 만듭니다.