Swift 리드·아키텍트 테스트 및 코드품질 기술면접

먼저 Strangler Fig 패턴을 적용해 새로운 기능은 처음부터 테스트 가능한 아키텍처(MVVM, Clean Architecture 등)로 작성하고 최소 70% 커버리지를 의무화합니다. 기존 코드는 비즈니스 크리티컬한 영역(결제, 인증 등)과 버그 발생 빈도가 높은 부분을 우선 식별하여 Characterization Test를 작성한 후 리팩토링합니다. ViewController에서 비즈니스 로직을 추출할 때는 Protocol을 활용한 Dependency Injection을 도입해 Mock 객체로 테스트 가능하게 만듭니다. 팀에는 테스트 작성 가이드라인과 예제를 제공하고, 코드 리뷰에서 테스트 품질을 필수 체크 항목으로 추가합니다. 3개월 단위로 커버리지 목표(30% → 50% → 70%)를 설정하고 메트릭을 추적하며, CI에서 커버리지 하한선을 점진적으로 상향 조정합니다.

먼저 네트워크 레이어를 Protocol로 추상화하고 Mock 구현체를 제공해 실제 네트워크 호출을 제거합니다. Combine 스트림 테스트는 expectation이나 Swift Concurrency의 async/await 기반 테스트를 활용하되, 타임아웃을 짧게 설정해 빠른 피드백을 얻습니다. 복잡한 Publisher 체인은 작은 단위로 분리하여 각각 독립적으로 테스트하고, 통합 테스트에서는 End-to-End 시나리오를 검증합니다. 시간 의존적인 로직(debounce, delay 등)은 Scheduler를 주입 가능하게 만들어 TestScheduler를 사용해 가상 시간으로 테스트합니다. 테스트 실행 순서에 의존하지 않도록 각 테스트의 setUp/tearDown에서 상태를 완전히 초기화하며, 불안정한 테스트(flaky test)는 즉시 수정하거나 격리합니다.

먼저 코드 리뷰의 목적을 명문화합니다(버그 발견, 지식 공유, 아키텍처 일관성 유지 등). 레벨별 체크리스트를 제공하여 자동화 가능한 항목(포매팅, lint)은 CI에서 처리하고, 리뷰어는 비즈니스 로직, 에러 핸들링, 테스트 품질, 성능 등 고차원 이슈에 집중하게 합니다. PR 크기를 400줄 이하로 제한하고, 큰 기능은 여러 PR로 분할하여 리뷰 품질을 높입니다. 건설적 피드백 문화를 위해 '질문형 코멘트'를 권장하고, 좋은 코드에 대한 칭찬도 포함시킵니다. 주니어 개발자의 PR은 시니어가 반드시 리뷰하고, 중요한 아키텍처 변경은 2명 이상의 승인을 필수화합니다. 월 1회 '좋은 리뷰 사례'를 공유하는 세션을 운영하여 학습 효과를 극대화합니다.

첫 단계로 현재 동작을 보존하는 Characterization Test를 작성합니다. 주요 입력값과 엣지 케이스에 대해 현재 출력을 기록하여 Golden Master Test Suite를 구성합니다. 두 번째로 클래스의 public interface는 유지하면서 내부 메서드를 작은 private 메서드로 추출하고, 각 메서드가 단일 책임을 갖도록 분리합니다. 세 번째로 식별된 책임별로 새로운 클래스를 생성하고, 기존 클래스는 이들을 조합하는 Facade 역할로 전환합니다. 네 번째로 새로 분리된 각 클래스에 대해 단위 테스트를 작성하고, 기존 Characterization Test가 여전히 통과하는지 확인합니다. 각 단계마다 작은 커밋으로 나누어 진행하며, 문제 발생 시 즉시 롤백 가능하도록 합니다. 마지막으로 Feature Flag를 활용해 일부 사용자에게만 리팩토링된 코드를 적용하고 점진적으로 확대합니다.

통합 테스트의 목적이 컴포넌트 간 상호작용 검증이므로, 가능한 실제 구현체를 사용하되 외부 의존성은 제어 가능한 형태로 만듭니다. CoreData는 In-Memory Store를 사용해 실제 CoreData 스택을 테스트하되 디스크 I/O를 제거합니다. UserDefaults는 테스트용 suite name을 사용해 격리하고, 각 테스트 후 초기화합니다. Keychain은 테스트 환경에서 접근 가능하므로 실제 Keychain을 사용하되, 테스트용 prefix를 붙여 관리하고 tearDown에서 삭제합니다. 원격 API는 URLProtocol을 활용한 Mock 서버나 Stub을 사용해 네트워크 불안정성을 제거하고, 다양한 응답 시나리오(성공, 실패, 타임아웃)를 재현 가능하게 만듭니다. 전체 플로우는 Given-When-Then 패턴으로 작성하여 가독성을 높이고, 각 시나리오별로 독립적인 테스트 케이스를 구성합니다.

먼저 테스트 피라미드 원칙에 따라 UI 테스트는 핵심 사용자 시나리오(회원가입, 결제 등)로 최소화하고, 나머지는 단위 테스트와 통합 테스트로 전환합니다. UI 테스트는 여러 시뮬레이터에서 병렬 실행하도록 CI 환경을 구성하고, Xcode Cloud나 Firebase Test Lab 같은 클라우드 기반 테스트 인프라를 활용합니다. 간헐적 실패는 암묵적 대기 대신 명시적 대기(waitForExistence)를 사용하고, 애니메이션을 비활성화하며, 테스트 간 상태 공유를 제거하여 해결합니다. 테스트 데이터는 setUp에서 API Mock이나 deeplink를 통해 빠르게 구성하고, UI 조작을 최소화합니다. 스모크 테스트와 풀 테스트를 분리하여, PR 단계에서는 5분 이내의 스모크 테스트만 실행하고, 머지 후에는 전체 테스트를 실행합니다. 테스트 실패 시 스크린샷과 로그를 자동 수집하여 디버깅을 용이하게 합니다.

테스트 커버리지(목표 70% 이상, 단 커버리지만을 위한 무의미한 테스트는 지양), Cyclomatic Complexity(메서드당 10 이하), 파일 크기(400줄 이하 권장), 의존성 깊이(레이어 간 순환 참조 제로)를 기본 메트릭으로 설정합니다. 코드 중복률(5% 이하)과 기술 부채 비율(SonarQube 등 활용)도 추적합니다. 다만 메트릭은 팀의 목표이지 개인 평가 지표로 사용하지 않으며, 메트릭 개선 자체가 목적이 되지 않도록 주의합니다. 예를 들어 커버리지 목표 달성을 위해 의미 없는 테스트를 작성하는 것을 방지하기 위해 코드 리뷰에서 테스트 품질을 함께 검토합니다. 메트릭 대시보드를 공개하여 투명성을 확보하고, 월별 트렌드를 추적하여 지속적 개선 문화를 만듭니다. 정량적 메트릭과 함께 코드 리뷰 피드백, 버그 발생률, 배포 빈도 같은 정성적 지표도 함께 고려합니다.

Stub은 미리 정의된 응답을 반환하는 객체로, 네트워크 API 호출 시 특정 JSON 응답을 반환하도록 설정할 때 사용합니다. Mock은 호출 여부와 인자를 검증하는 객체로, 분석 이벤트 전송 객체가 올바른 파라미터로 호출되었는지 확인할 때 적합합니다. Spy는 실제 객체를 래핑하여 호출을 기록하는 객체로, 기존 동작을 유지하면서 메서드 호출 횟수를 추적할 때 사용합니다. Fake는 실제 구현을 단순화한 동작하는 객체로, In-Memory 데이터베이스가 대표적 예시입니다. 과도한 Mocking은 구현 세부사항에 테스트가 결합되어 리팩토링 시 테스트가 깨지는 문제(Fragile Test)를 야기하고, 실제 통합 시 발생할 수 있는 문제를 놓칠 수 있습니다. 따라서 가능하면 실제 객체나 Fake를 사용하고, 제어하기 어려운 외부 의존성에만 Mock/Stub을 적용하는 것이 좋습니다.

XCTest의 measure 블록을 사용해 이미지 필터 적용 시간을 측정하되, 테스트 환경의 일관성을 위해 고정된 크기와 포맷의 샘플 이미지를 사용합니다. 첫 실행은 워밍업으로 제외하고, 10회 이상 반복 측정하여 평균과 표준편차를 계산합니다. Baseline을 설정하여 이전 성능 대비 10% 이상 저하 시 테스트 실패로 처리하고, CI에서 자동으로 감지되도록 합니다. 성능 테스트는 실제 디바이스나 일관된 시뮬레이터 환경에서 실행하며, 백그라운드 프로세스의 영향을 최소화합니다. 시간 복잡도뿐 아니라 메모리 사용량(XCTMemoryMetric)과 CPU 사용률도 함께 측정하여 다차원적으로 성능을 평가합니다. 성능 테스트 결과는 시계열 데이터로 저장하고 대시보드에서 시각화하여 장기적 트렌드를 추적합니다. 다만 성능 테스트는 실행 시간이 길므로 일반 PR에서는 skip하고, nightly build나 릴리스 브랜치에서만 실행하도록 분리합니다.

먼저 테스트 부재로 인한 비용을 정량화합니다. 프로덕션 버그 수정 시간, 핫픽스 배포 빈도, 고객 이탈률 등을 측정하여 품질 문제의 비즈니스 임팩트를 데이터로 제시합니다. 테스트를 모든 코드에 적용하는 대신, 비즈니스 크리티컬한 영역(결제, 인증, 핵심 전환율)에 집중하는 Risk-Based Testing 전략을 채택합니다. 새로운 기능 개발 시 테스트 작성 시간을 별도로 산정하여 일정에 반영하고, 테스트가 있는 코드와 없는 코드의 버그 발생률을 비교하여 효과를 입증합니다. 테스트 작성이 익숙하지 않은 팀을 위해 페어 프로그래밍과 테스트 워크샵을 운영하고, 좋은 테스트 예시를 공유합니다. 단기적으로는 스모크 테스트와 E2E 테스트로 빠른 안전망을 구축하고, 중장기적으로 단위 테스트 커버리지를 점진적으로 높입니다. 테스트 자동화로 절감된 QA 시간을 측정하여 투자 대비 효과(ROI)를 지속적으로 공유합니다.