Go 시니어 테스트·코드품질 기술면접

일반적으로 70% 단위 테스트, 20% 통합 테스트, 10% E2E 테스트 비율을 권장하지만, 마이크로서비스 특성상 통합 테스트 비중을 25-30%까지 높입니다. 단위 테스트는 비즈니스 로직과 알고리즘에 집중하며, 외부 의존성은 모두 mock/stub으로 처리합니다. 통합 테스트는 실제 DB, 메시지 큐와의 상호작용을 검증하되 testcontainer를 활용해 격리된 환경에서 실행합니다. E2E 테스트는 핵심 사용자 시나리오만 선별하여 CI/CD 파이프라인에서 병렬 실행합니다. 테스트 실행 시간 단축을 위해 통합 테스트는 build tag로 분리하고, 개발자 로컬에서는 단위 테스트만 빠르게 실행하도록 구성합니다. 또한 contract testing(Pact 등)을 도입해 서비스 간 인터페이스 검증을 통합 테스트에서 분리하여 독립적으로 실행 가능하게 합니다.

먼저 Golden Master Testing 또는 Characterization Test를 작성해 현재 시스템의 동작을 있는 그대로 캡처하여 리팩토링 중 회귀를 방지합니다. 다음으로 Strangler Fig 패턴을 적용해 새로운 기능은 TDD로 개발하고, 기존 코드는 수정이 필요할 때만 테스트를 추가합니다. 데이터베이스 결합 코드는 Repository 패턴으로 분리하고 인터페이스를 도입해 비즈니스 로직을 순수 함수로 추출합니다. 의존성 주입을 위해 생성자 함수에서 인터페이스를 받도록 리팩토링하고, 단위 테스트에서는 mock을 주입합니다. 큰 함수는 Extract Method 리팩토링으로 작은 단위로 분해하여 각각 테스트를 작성합니다. 팀 전체가 TDD에 익숙하지 않다면 페어 프로그래밍과 코드 리뷰를 통해 학습 곡선을 완화하고, 테스트 커버리지 목표를 단계적으로 높여갑니다(예: 신규 코드 80% → 전체 60% → 전체 80%).

Mock은 호출 검증에 집중하며 특정 메서드가 정확한 인자로 호출되었는지 확인할 때 사용합니다(예: 이메일 발송 서비스). Stub은 미리 정의된 응답을 반환하며 외부 API 응답을 시뮬레이션할 때 사용합니다. Fake는 실제 동작하는 간단한 구현체로 인메모리 DB처럼 동작하며 통합 테스트에서 유용합니다. Spy는 실제 객체를 감싸서 호출을 기록하며 부분적 검증이 필요할 때 사용합니다. testify/mock이나 gomock은 복잡한 인터페이스의 mock을 빠르게 생성하고 호출 검증 코드를 간결하게 작성할 수 있지만, 테스트가 구현 세부사항에 결합되어 리팩토링 시 깨지기 쉽습니다. 수동 구현은 코드가 길어지지만 필요한 동작만 구현하여 테스트 의도가 명확하고 유지보수가 쉽습니다. 일반적으로 간단한 인터페이스는 수동으로, 복잡한 인터페이스는 라이브러리를 사용하되 행위 검증보다 상태 검증을 우선합니다.

코드 리뷰 체크리스트는 기능 정확성, 테스트 커버리지, 에러 처리, 성능, 보안, 가독성 순으로 우선순위를 둡니다. 작성자는 PR 설명에 변경 이유와 영향 범위를 명확히 작성하고 self-review로 명백한 실수를 먼저 제거합니다. 리뷰어는 24시간 내 1차 피드백을 제공하며, nitpick과 blocking issue를 구분합니다. 형식적 리뷰를 방지하기 위해 golangci-lint, gofmt, go vet을 CI에서 자동 실행하여 스타일 논쟁을 제거합니다. PR 크기는 400줄 이하로 제한하고, 큰 변경은 설계 리뷰를 먼저 진행합니다. Go 특화 포인트로는 error wrapping 일관성, context 전파, goroutine leak 가능성, race condition, 불필요한 포인터 사용을 중점 검토합니다. 팀 내 코딩 컨벤션 문서를 만들고 정기적으로 업데이트하며, 반복되는 리뷰 코멘트는 linter 규칙이나 문서로 전환합니다.

라인 커버리지는 실행된 코드 줄을 측정하지만 모든 분기나 조건을 검증하지 않습니다. 브랜치 커버리지는 if/else 같은 분기를 모두 테스트했는지 확인하며 더 엄격합니다. 뮤테이션 커버리지는 코드를 의도적으로 변경했을 때 테스트가 실패하는지 확인하여 테스트의 실효성을 검증합니다. 높은 커버리지에도 버그가 발생하는 이유는 edge case 미검증, assertion 부족, 통합 지점 미테스트 때문입니다. 개선 방법으로 경계값 분석(boundary value analysis)과 등가 분할(equivalence partitioning)을 적용하고, property-based testing(gopter)으로 예상치 못한 입력을 테스트합니다. go-mutesting으로 뮤테이션 테스트를 실행하여 테스트의 견고성을 확인합니다. 커버리지 목표는 팀 합의로 정하되, 핵심 비즈니스 로직은 95% 이상, 유틸리티 코드는 70% 이상으로 차등 적용합니다. codecov 같은 도구로 PR별 커버리지 변화를 추적하고, 커버리지가 감소하는 PR은 자동으로 차단합니다.

첫 단계로 현재 함수의 입출력을 기준으로 Approval Test를 작성하여 다양한 입력에 대한 현재 동작을 캡처합니다. 다음으로 Extract Method 리팩토링으로 의미 있는 작은 함수들을 추출하되, 한 번에 하나씩만 추출하고 테스트를 실행하여 동작이 유지되는지 확인합니다. 전역 변수 의존성은 함수 파라미터로 명시적으로 전달하도록 변경하고, 의존성 주입 패턴을 적용합니다. 에러 처리는 Go 1.13 error wrapping으로 통일하고, sentinel error나 custom error type으로 명확히 정의합니다. 추출된 작은 함수들은 각각 단위 테스트를 작성하여 독립적으로 검증합니다. 복잡한 조건문은 Early Return 패턴으로 중첩을 줄이고, 매직 넘버는 상수로 추출합니다. SRP(Single Responsibility Principle)를 적용해 각 함수가 하나의 책임만 갖도록 분리하며, 최종적으로 원래 함수는 여러 작은 함수를 조합하는 orchestrator 역할만 하도록 만듭니다. 모든 리팩토링은 작은 커밋으로 나누어 진행하고 각 커밋마다 테스트를 통과시킵니다.

testcontainers-go를 사용하면 개발자 로컬과 CI 환경에서 동일한 테스트를 실행할 수 있고, 테스트마다 깨끗한 상태의 의존성을 제공받아 격리가 보장됩니다. 단점은 컨테이너 시작 시간이 추가되고 Docker 환경이 필요하다는 것입니다. 실제 인프라 사용은 프로덕션과 동일한 환경에서 테스트하지만 테스트 간 간섭과 데이터 정리가 복잡합니다. 권장 전략은 로컬과 CI에서는 testcontainers를 사용하고, staging 환경에서는 실제 인프라로 E2E 테스트를 실행합니다. 테스트 데이터는 test fixture 파일(JSON/YAML)로 관리하거나 factory 패턴으로 생성하며, 각 테스트 시작 시 seed 데이터를 주입합니다. 테스트 격리는 각 테스트마다 별도 데이터베이스 스키마나 네임스페이스를 사용하거나, 트랜잭션을 시작하고 테스트 후 롤백합니다. 병렬 실행은 t.Parallel()을 사용하되 공유 리소스 접근은 뮤텍스로 보호합니다. CI에서는 testcontainers 이미지를 미리 pull하여 시작 시간을 단축하고, 테스트를 패키지별로 분산 실행합니다.