테스트/TDD 시니어 기술면접

레거시 시스템의 주요 장애물은 강한 결합, 전역 상태, 의존성 주입 부재, 낮은 응집도입니다. 먼저 Characterization Test로 기존 동작을 보호하고, Seam을 찾아 테스트 가능한 지점을 만듭니다. Sprout Method나 Wrap Method 패턴으로 새 기능은 TDD로 개발하고, 기존 코드는 Strangler Fig 패턴으로 점진적으로 교체합니다. 의존성 역전을 위해 Extract Interface와 Dependency Injection을 단계적으로 적용하며, 높은 위험도 영역부터 우선순위를 두어 테스트 커버리지를 확대합니다. 팀 전체의 TDD 역량 향상을 위해 페어 프로그래밍과 코드 리뷰를 활용합니다.

Test Pyramid은 단위 테스트를 기반으로 통합-E2E 순으로 줄어드는 구조로, 빠른 피드백과 낮은 비용을 강조합니다. Test Diamond은 통합 테스트에 무게를 두며 서비스 간 상호작용이 중요한 경우 적합합니다. Test Trophy는 통합 테스트를 가장 중시하며, 프론트엔드나 사용자 중심 애플리케이션에 유리합니다. 마이크로서비스에서는 서비스 내부는 Pyramid로 단위 테스트를 강화하고, 서비스 간 계약은 Contract Testing으로, 전체 플로우는 제한된 E2E로 검증하는 하이브리드 접근이 적절합니다. 각 서비스의 독립성과 배포 속도를 유지하면서도 시스템 전체의 안정성을 확보할 수 있습니다.

Outside-In TDD는 사용자 인터페이스나 API 등 외부 계층부터 시작해 안쪽으로 진행하며, 인수 테스트로 시작해 Mock을 활용합니다. 사용자 요구사항에 집중하고 필요한 인터페이스를 먼저 설계하는 장점이 있지만, 과도한 Mock 사용으로 리팩토링이 어려울 수 있습니다. Inside-Out TDD는 도메인 로직이나 핵심 알고리즘부터 시작해 바깥으로 확장하며, 실제 객체를 사용합니다. 견고한 도메인 모델을 만들고 테스트가 안정적이지만, 전체 통합 시점에 문제가 발견될 수 있습니다. 도메인이 복잡한 경우 Inside-Out이, 요구사항이 명확하고 협업이 중요한 경우 Outside-In이 적합하며, 실무에서는 두 접근을 혼합해 사용합니다.

Stub은 미리 정의된 응답을 반환하는 객체로, 상태 검증에 사용되며 외부 API 응답을 시뮬레이션할 때 적합합니다. Mock은 호출 여부와 인자를 검증하는 객체로, 행위 검증에 사용되며 이메일 발송이나 이벤트 발행 같은 부수 효과를 확인할 때 씁니다. Spy는 실제 객체를 감싸 호출을 기록하면서도 원래 동작을 수행하며, 부분적 검증이 필요할 때 유용합니다. Fake는 실제와 유사하게 동작하지만 단순화된 구현으로, 인메모리 데이터베이스나 테스트용 저장소를 만들 때 사용합니다. Mock은 '어떻게 호출되었는가'를, Stub은 '어떤 값을 반환하는가'를 중심으로 하며, 과도한 Mock 사용은 구현에 결합된 테스트를 만들 수 있어 주의가 필요합니다.

Example-Based Testing은 구체적인 입력-출력 쌍을 정의해 테스트하는 전통적 방식으로, 이해하기 쉽고 특정 엣지 케이스를 명시적으로 다룰 수 있습니다. Property-Based Testing은 입력 범위와 만족해야 할 속성을 정의하면 프레임워크가 다양한 입력을 생성해 검증하는 방식으로, 개발자가 예상하지 못한 케이스를 발견할 수 있습니다. 정렬 알고리즘에서 결과의 순서 속성, 인코딩-디코딩의 왕복 속성, 수학적 연산의 교환법칙 등을 검증할 때 특히 유용합니다. 파서, 직렬화 로직, 암호화, 금융 계산 등 수학적 속성이나 불변식이 명확한 도메인에 적합하며, QuickCheck나 Hypothesis 같은 도구를 사용합니다. 두 방식을 조합해 중요한 엣지 케이스는 Example로, 일반적 속성은 Property로 검증하는 것이 효과적입니다.

Mutation Testing은 원본 코드에 의도적으로 작은 변경(mutation)을 가해 변종(mutant)을 만들고, 테스트가 이를 감지하는지 확인하는 기법입니다. 연산자 변경, 상수 수정, 조건문 반전 등의 mutation을 적용하고, 테스트가 실패하면 killed, 통과하면 survived로 분류합니다. 코드 커버리지는 코드 실행 여부만 측정하지만, Mutation Score는 테스트의 결함 탐지 능력을 정량화합니다. 실무 도입 시 실행 시간이 길어 CI 파이프라인 부담이 크므로, 핵심 모듈에 선택적으로 적용하거나 증분 분석을 활용합니다. PIT, Stryker 같은 도구를 사용하며, 높은 Mutation Score를 목표로 하되 테스트 작성 비용과 균형을 맞춰야 합니다. survived mutants 분석을 통해 테스트 개선점을 찾을 수 있습니다.

Transaction Rollback은 각 테스트를 트랜잭션으로 감싸고 종료 시 롤백하는 방식으로, 가장 빠르지만 커밋 후 동작이나 다중 트랜잭션 시나리오를 테스트하기 어렵습니다. Database Cleanup은 테스트 전후로 데이터를 삭제하는 방식으로, 모든 시나리오를 테스트할 수 있지만 느리고 외래키 제약 처리가 복잡합니다. Test Container는 각 테스트마다 격리된 컨테이너를 실행해 완전한 격리를 제공하며 프로덕션 환경과 유사하지만, 시작 시간이 길어 전체 테스트 스위트 수준에서 사용합니다. 실무에서는 대부분 Transaction Rollback을 기본으로 하고, 커밋이 필요한 경우 Database Cleanup을, CI 환경에서는 Test Container를 조합해 사용합니다. 테스트 속도와 신뢰성의 균형을 맞추는 것이 중요합니다.

비동기 처리는 명시적 대기(Explicit Wait)를 사용해 특정 조건이 만족될 때까지 기다리고, 암묵적 대기나 고정 시간 sleep은 피합니다. 타이밍 이슈는 Retry 메커니즘과 적절한 타임아웃 설정으로 해결하며, 애니메이션은 테스트 환경에서 비활성화합니다. 외부 의존성은 Service Virtualization이나 Mock Server로 제어 가능한 환경을 만들고, 테스트 데이터는 각 테스트마다 독립적으로 준비합니다. 네트워크 불안정성은 Retry와 Circuit Breaker 패턴으로 대응하고, 브라우저나 디바이스 차이는 표준화된 환경에서 실행합니다. Cypress나 Playwright 같은 현대적 도구는 자동 재시도와 대기 기능을 내장하고 있으며, 실패 시 스크린샷과 비디오를 자동 저장해 디버깅을 돕습니다. Flaky Test는 발견 즉시 수정하고, 격리하거나 Quarantine해 CI 파이프라인을 안정화합니다.

테스트는 실행 속도와 범위에 따라 Unit, Integration, E2E로 계층화하고, 각 계층별로 별도 스위트를 구성합니다. 태깅 시스템으로 smoke, regression, critical, feature별로 분류해 상황에 맞게 선택적 실행이 가능하게 합니다. 로컬 개발 시에는 빠른 Unit 테스트만, PR 시에는 smoke와 관련 Integration, main 브랜치에는 전체 regression을 실행하는 다단계 전략을 사용합니다. 병렬 실행과 테스트 샤딩으로 전체 실행 시간을 단축하고, 실패한 테스트부터 재실행하는 Fail-Fast 전략으로 피드백을 빠르게 받습니다. 테스트 실행 시간과 실패율을 모니터링해 느린 테스트나 Flaky Test를 식별하고 지속적으로 개선합니다. Test Impact Analysis로 변경된 코드와 관련된 테스트만 선택적으로 실행해 효율을 높입니다.

먼저 TDD의 가치를 실제 프로젝트에서 증명하기 위해 작은 모듈이나 신규 기능에 파일럿으로 적용하고 결과를 공유합니다. 정기적인 Mob Programming이나 Kata 세션으로 안전한 학습 환경을 제공하고, 페어 프로그래밍을 통해 실무에서 자연스럽게 전파합니다. 코드 리뷰에서 테스트 품질을 중요한 기준으로 삼되, 처음에는 강제하지 않고 좋은 예시를 칭찬하며 동기를 부여합니다. 테스트 작성 시간이 초기에는 늘어나지만 버그 감소와 리팩토링 용이성으로 장기적 이득이 크다는 것을 메트릭으로 보여줍니다. 레거시 코드는 무리하게 전환하지 않고 새 코드부터 시작해 점진적으로 확대하며, TDD 챔피언을 각 팀에 육성해 자발적 확산을 유도합니다. 실패를 학습 기회로 삼는 안전한 문화를 조성하고, 경영진에게는 품질과 유지보수 비용 절감 효과를 설명해 지원을 확보합니다.