PostgreSQL 미드레벨 테스트·코드품질 기술면접
새 면접Q. PostgreSQL을 사용하는 애플리케이션에서 Repository 계층의 단위 테스트를 작성할 때, 실제 PostgreSQL 인스턴스를 사용하는 방법과 In-Memory 데이터베이스(H2 등)를 사용하는 방법을 비교해주세요. 각각의 장단점과 함께, 어떤 상황에서 어떤 전략을 선택하는 것이 적절한지 설명해주세요.
테스트 실행 속도, 환경 일관성, PostgreSQL 고유 기능의 테스트 가능성을 중심으로 생각해보세요.
실제 PostgreSQL을 사용하면 운영 환경과 동일한 환경에서 테스트할 수 있어 PostgreSQL 고유 기능(JSONB, Array, Window Function 등)과 특정 SQL 문법을 정확히 검증할 수 있습니다. 하지만 테스트 실행 속도가 느리고 Docker나 Testcontainers 같은 추가 인프라가 필요합니다. In-Memory DB는 빠른 실행 속도와 간단한 설정이 장점이지만, PostgreSQL과 문법 차이로 인해 운영 환경에서 실패할 수 있는 위험이 있습니다. 일반적인 CRUD 로직은 In-Memory DB로 빠르게 테스트하고, PostgreSQL 고유 기능이나 복잡한 쿼리는 실제 PostgreSQL로 통합 테스트하는 하이브리드 전략이 효과적입니다. Testcontainers를 활용하면 Docker 기반 PostgreSQL을 테스트마다 격리된 환경에서 실행할 수 있어 데이터 오염 문제를 방지할 수 있습니다.
- • 실제 PostgreSQL 사용 시 환경 일관성과 고유 기능 테스트 가능
- • In-Memory DB는 빠르지만 문법 호환성 문제 존재
- • 하이브리드 전략: 단순 로직은 In-Memory, 복잡한 쿼리는 실제 DB
- • Testcontainers로 격리된 테스트 환경 구성 가능
CI/CD 파이프라인에서 빠른 피드백과 정확한 검증 사이의 균형을 맞추는 테스트 전략 설계 시 활용됩니다.
Testcontainers를 사용할 때 테스트 실행 시간을 단축하기 위해 컨테이너를 재사용하는 전략과 그로 인해 발생할 수 있는 문제점은 무엇인가요?
Q. 복잡한 비즈니스 로직에서 여러 테이블에 대한 INSERT, UPDATE를 수행하고 중간에 예외가 발생하면 롤백되어야 하는 서비스 메서드를 테스트할 때, 트랜잭션이 올바르게 롤백되는지 검증하는 테스트 전략을 설명해주세요. 특히 @Transactional 어노테이션이 테스트에 미치는 영향과, 실제 트랜잭션 동작을 정확히 검증하기 위한 방법을 제시해주세요.
테스트 메서드의 트랜잭션과 실제 서비스 메서드의 트랜잭션이 어떻게 상호작용하는지 고려해보세요.
Spring의 테스트에서 @Transactional을 사용하면 기본적으로 테스트 종료 후 자동 롤백되므로, 실제 서비스의 롤백 로직을 제대로 검증하지 못할 수 있습니다. 서비스 메서드의 트랜잭션 동작을 정확히 테스트하려면, 테스트 메서드에서 @Transactional을 제거하고 각 테스트마다 명시적으로 데이터를 정리하거나, @Rollback(false)를 사용하여 실제 커밋이 발생하도록 해야 합니다. 예외 발생 시 롤백을 검증하려면, 예외를 발생시킨 후 별도의 트랜잭션에서 데이터베이스를 조회하여 변경사항이 없음을 확인해야 합니다. TransactionTemplate을 사용하거나 별도의 @Transactional(propagation = REQUIRES_NEW) 메서드를 만들어 트랜잭션을 분리하면 검증이 가능합니다. 또한 TestEntityManager를 사용하여 flush와 clear를 명시적으로 호출하여 영속성 컨텍스트와 데이터베이스 간의 동기화 상태를 제어할 수 있습니다.
- • 테스트의 @Transactional은 자동 롤백으로 실제 동작 검증 방해
- • 실제 트랜잭션 동작 검증을 위해 테스트에서 @Transactional 제거 또는 @Rollback(false) 사용
- • 별도 트랜잭션에서 롤백 결과 확인 필요
- • TransactionTemplate이나 REQUIRES_NEW로 트랜잭션 분리
결제, 포인트 차감, 주문 생성이 함께 이루어지는 복잡한 비즈니스 로직의 원자성을 검증할 때 사용됩니다.
분산 트랜잭션이나 여러 데이터베이스에 걸친 트랜잭션을 테스트할 때는 어떤 전략을 사용하시겠습니까?
Q. PostgreSQL 데이터베이스를 사용하는 통합 테스트에서 테스트 데이터를 준비하는 방법으로 SQL 스크립트, 코드 기반 Fixture, Faker 라이브러리 사용 등이 있습니다. 각 방법의 장단점을 비교하고, 테스트 간 데이터 격리와 재현 가능성을 보장하기 위한 전략을 설명해주세요.
테스트 데이터의 가독성, 유지보수성, 테스트 독립성을 중심으로 생각해보세요.
SQL 스크립트는 대량의 초기 데이터를 빠르게 삽입할 수 있고 데이터 구조를 명확히 볼 수 있지만, 스키마 변경 시 유지보수가 어렵고 테스트 간 의존성이 생길 수 있습니다. 코드 기반 Fixture(Builder 패턴, Factory 패턴)는 타입 안정성과 IDE 지원을 받을 수 있고 재사용성이 높지만, 초기 작성 비용이 높습니다. Faker 라이브러리는 다양한 랜덤 데이터를 생성하여 엣지 케이스를 발견할 수 있지만, 테스트 재현성이 떨어질 수 있으므로 시드를 고정해야 합니다. 테스트 격리를 위해서는 각 테스트마다 @BeforeEach에서 필요한 데이터만 생성하고 @AfterEach나 트랜잭션 롤백으로 정리하거나, Testcontainers로 테스트마다 새 컨테이너를 사용하는 방법이 있습니다. 실무에서는 공통 데이터는 SQL 스크립트로, 테스트별 특정 데이터는 코드 기반 Fixture로 생성하는 하이브리드 방식이 효과적입니다.
- • SQL 스크립트는 빠르지만 유지보수 어려움
- • 코드 기반 Fixture는 타입 안정성과 재사용성 제공
- • Faker는 다양성 제공하지만 시드 고정 필요
- • 테스트 격리를 위해 각 테스트마다 데이터 생성 및 정리
대규모 E2E 테스트나 통합 테스트에서 일관되고 재현 가능한 테스트 환경을 구축할 때 사용됩니다.
외래 키 제약조건이 복잡하게 얽힌 테이블들의 테스트 데이터를 효율적으로 생성하고 정리하는 방법은 무엇인가요?
Q. Flyway나 Liquibase 같은 데이터베이스 마이그레이션 도구를 사용할 때, 마이그레이션 스크립트 자체를 테스트하는 전략을 설명해주세요. 특히 운영 데이터베이스에 적용하기 전에 스키마 변경이 기존 데이터와 호환되는지, 롤백이 가능한지를 검증하는 방법을 제시해주세요.
마이그레이션 전후의 데이터 무결성과 애플리케이션 호환성을 검증하는 방법을 고려해보세요.
마이그레이션 테스트는 운영 환경과 유사한 데이터를 가진 스테이징 환경에서 먼저 수행해야 합니다. Testcontainers로 운영 DB의 스냅샷을 복원하거나 익명화된 덤프를 사용하여 실제 데이터 패턴을 재현할 수 있습니다. 마이그레이션 적용 전후로 데이터 건수, 제약조건, 인덱스 상태를 비교하는 자동화된 검증 스크립트를 작성해야 합니다. NOT NULL 제약 추가나 컬럼 타입 변경 같은 위험한 변경은 단계별로 나누어(예: 먼저 NULL 허용 컬럼 추가 → 데이터 마이그레이션 → NOT NULL 제약 추가) Blue-Green 배포와 함께 진행합니다. 롤백 스크립트를 함께 작성하고 테스트하여 문제 발생 시 빠르게 복구할 수 있도록 준비합니다. CI 파이프라인에서 마이그레이션을 빈 데이터베이스와 샘플 데이터가 있는 데이터베이스 양쪽에 적용하여 멱등성과 호환성을 검증합니다.
- • 스테이징 환경에서 운영 데이터 패턴으로 테스트
- • 마이그레이션 전후 데이터 무결성 자동 검증
- • 위험한 변경은 단계별로 분리하여 적용
- • 롤백 스크립트 작성 및 테스트 필수
운영 중인 서비스의 스키마 변경 시 데이터 손실이나 서비스 장애를 방지하기 위해 사용됩니다.
수백만 건의 데이터가 있는 테이블에 새로운 인덱스를 추가하는 마이그레이션을 무중단으로 수행하는 방법은 무엇인가요?
Q. PostgreSQL의 복잡한 쿼리(다중 JOIN, 서브쿼리, 집계 함수 포함)에 대한 성능 회귀 테스트를 자동화하려고 합니다. 쿼리 실행 시간뿐만 아니라 실행 계획의 변화도 감지하여, 인덱스 누락이나 플랜 변경으로 인한 성능 저하를 조기에 발견하는 테스트 전략을 설계해주세요.
EXPLAIN 결과를 파싱하고 비교하는 방법과, 성능 기준선(baseline)을 설정하는 방법을 고려해보세요.
성능 테스트는 운영과 유사한 데이터 볼륨을 가진 환경에서 수행해야 하며, 테스트 실행 전 ANALYZE를 실행하여 통계 정보를 최신 상태로 유지합니다. EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON) 결과를 저장하고, 실행 계획의 주요 노드(Seq Scan vs Index Scan), 예상 비용, 실제 실행 시간을 추출하여 기준선과 비교합니다. pg_stat_statements를 활성화하여 실제 쿼리 실행 통계를 수집하고, 평균 실행 시간이 기준선 대비 20% 이상 증가하면 경고를 발생시킵니다. JMeter나 k6 같은 부하 테스트 도구로 동시성 테스트를 수행하여 락 경합이나 데드락 발생 가능성을 확인합니다. 실행 계획의 주요 변경사항(인덱스 미사용, Nested Loop에서 Hash Join으로 변경 등)을 감지하는 자동화된 스크립트를 CI에 통합하여 코드나 스키마 변경이 쿼리 성능에 미치는 영향을 즉시 파악합니다. 성능 테스트 결과는 시계열 데이터로 저장하여 추세를 모니터링합니다.
- • EXPLAIN ANALYZE 결과를 JSON으로 파싱하여 실행 계획 비교
- • pg_stat_statements로 실제 실행 통계 수집
- • 성능 기준선 대비 임계값 초과 시 경고
- • 부하 테스트로 동시성 문제 검증
- • CI 통합으로 성능 회귀 조기 발견
대규모 리팩토링이나 PostgreSQL 버전 업그레이드 시 성능 저하를 사전에 방지하기 위해 사용됩니다.
쿼리 성능 테스트에서 캐시 효과로 인한 불안정한 결과를 최소화하는 방법은 무엇인가요?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!