PostgreSQL 주니어 테스트·코드품질 면접

단위 테스트에서는 데이터베이스 로직을 Mock이나 Stub으로 대체하여 빠른 실행과 외부 의존성 제거를 추구합니다. 이를 통해 특정 비즈니스 로직만 격리하여 테스트할 수 있고, 테스트 속도가 빠르며 CI/CD 파이프라인에서 유리합니다. 반면 통합 테스트에서는 실제 PostgreSQL 인스턴스(테스트용 컨테이너나 별도 스키마)를 사용하여 쿼리, 트랜잭션, 제약조건 등이 실제로 동작하는지 검증합니다. Mock을 사용하면 빠르지만 실제 DB 동작과 차이가 발생할 수 있고, 실제 DB를 사용하면 신뢰도가 높지만 테스트 속도가 느리고 환경 설정이 복잡합니다. 실무에서는 단위 테스트는 Mock을, 통합 테스트는 Docker 기반 테스트 DB를 사용하는 것이 일반적입니다.

트랜잭션 롤백 방식은 각 테스트를 트랜잭션 내에서 실행하고 테스트 종료 시 ROLLBACK하여 데이터를 원상복구하는 방법으로, 가장 빠르고 효율적이지만 트랜잭션 커밋을 테스트할 수 없다는 한계가 있습니다. 데이터베이스 초기화 방식은 매 테스트마다 테이블을 TRUNCATE하거나 DROP/CREATE하는 방법으로, 완전한 격리를 보장하지만 속도가 느립니다. 테스트 픽스처는 setUp 단계에서 필요한 데이터를 INSERT하고 tearDown에서 삭제하는 방식으로, 테스트에 필요한 데이터만 준비할 수 있지만 관리 코드가 복잡해질 수 있습니다. 실무에서는 트랜잭션 롤백을 기본으로 사용하고, 트랜잭션 동작 자체를 테스트해야 할 때만 데이터베이스 초기화를 사용합니다.

복잡한 쿼리를 테스트할 때는 먼저 예상 결과를 명확히 정의한 테스트 데이터를 준비해야 합니다. 정상 케이스뿐만 아니라 빈 결과, 단일 행, 다중 행, 중복 데이터 등 다양한 시나리오를 포함해야 합니다. 경계값 테스트는 0, 음수, 최대값, 날짜 범위의 시작/종료 등을 테스트 데이터에 포함시켜 WHERE 조건과 집계 함수가 올바르게 동작하는지 검증합니다. NULL 처리는 JOIN 대상 컬럼이나 집계 대상 컬럼에 NULL 값을 포함한 테스트 데이터를 준비하고, LEFT JOIN의 결과나 COUNT/SUM의 NULL 처리가 예상대로 동작하는지 확인합니다. 테스트 코드에서는 실제 쿼리 실행 결과와 기대값을 행 수, 특정 컬럼 값, 정렬 순서 등 여러 측면에서 비교하여 검증합니다.

데이터베이스 스키마 리팩토링은 먼저 개발 환경에서 충분히 테스트한 후 단계적으로 적용해야 합니다. 마이그레이션 스크립트는 UP(변경 적용)과 DOWN(롤백) 두 가지를 모두 작성하여 문제 발생 시 즉시 되돌릴 수 있어야 합니다. 컬럼 추가 시에는 NULL 허용 또는 DEFAULT 값을 설정하여 기존 데이터에 영향을 주지 않도록 하고, 타입 변경은 호환되지 않는 경우 새 컬럼을 추가한 후 데이터 마이그레이션을 거쳐 기존 컬럼을 삭제하는 다단계 접근을 사용합니다. 테이블 분리는 애플리케이션 코드가 양쪽 구조를 모두 지원하도록 수정한 후 데이터를 이관하고 기존 테이블을 제거하는 순서로 진행합니다. 모든 변경은 트랜잭션 내에서 수행하고, 운영 환경 적용 전에 백업을 필수로 수행해야 합니다.

성능 측면에서는 인덱스 활용 여부, N+1 쿼리 문제, 불필요한 SELECT * 사용, JOIN 순서와 조건, 서브쿼리 최적화 가능성을 확인해야 합니다. 보안 측면에서는 SQL 인젝션 취약점이 있는지 확인하고, 파라미터 바인딩이나 Prepared Statement를 사용하는지 검토합니다. 유지보수성 측면에서는 쿼리의 가독성, 매직 넘버나 하드코딩된 값 사용 여부, 주석 유무, 트랜잭션 범위의 적절성을 점검합니다. 또한 NULL 처리가 명확한지, 제약조건과 외래키가 적절히 설정되어 있는지, 롤백 가능성을 고려했는지도 확인합니다. 코드 리뷰 시에는 EXPLAIN ANALYZE로 실행 계획을 확인하고, 테스트 코드가 함께 작성되었는지도 검토해야 합니다.