React Native 시니어 테스트 및 코드품질 기술면접
새 면접Q. React Native 앱에서 Testing Pyramid를 어떻게 구성하시겠습니까? 각 계층(Unit, Integration, E2E)별로 적절한 테스트 비율과 각 계층에서 사용할 도구, 그리고 React Native의 특성을 고려한 테스트 전략을 설명해주세요.
네이티브 모듈과의 통합, 비동기 처리, UI 렌더링 등 React Native만의 특성을 고려해보세요.
Unit 테스트 70%, Integration 테스트 20%, E2E 테스트 10% 비율로 구성합니다. Unit 테스트는 Jest와 React Native Testing Library를 사용해 비즈니스 로직, 커스텀 훅, 유틸리티 함수를 테스트합니다. Integration 테스트는 네이티브 모듈과의 통합, API 통신, 네비게이션 플로우를 테스트하며 Mock을 최소화합니다. E2E 테스트는 Detox나 Maestro를 사용해 핵심 사용자 시나리오만 검증합니다. React Native의 경우 네이티브 브릿지 통신이 있어 통합 테스트의 중요도가 일반 웹보다 높으며, 실제 디바이스나 시뮬레이터에서의 검증이 필수적입니다. CI/CD 파이프라인에서는 Unit과 Integration은 모든 커밋마다, E2E는 릴리즈 브랜치에서만 실행하도록 구성합니다.
- • Testing Pyramid 비율: Unit 70%, Integration 20%, E2E 10%
- • 각 계층별 적절한 도구 선택 (Jest, RNTL, Detox/Maestro)
- • React Native 특성(네이티브 브릿지, 플랫폼별 차이)을 고려한 전략
- • CI/CD 파이프라인에서의 테스트 실행 전략
대규모 React Native 앱에서 빠른 피드백과 안정성을 동시에 확보하기 위한 테스트 전략 수립 시 활용됩니다.
E2E 테스트의 실행 시간이 너무 길어져 개발 속도가 저하되는 상황에서 어떻게 최적화하시겠습니까?
Q. 시니어 개발자로서 주니어 개발자의 React Native 코드를 리뷰할 때 중점적으로 확인하는 항목들은 무엇이며, 코드 리뷰를 통해 팀의 코드 품질을 향상시키기 위한 구체적인 방법을 설명해주세요.
단순한 버그 찾기를 넘어서 팀 전체의 코드 품질 향상과 지식 공유 관점에서 생각해보세요.
첫째, 성능 관련 이슈를 우선 확인합니다. 불필요한 리렌더링, 메모리 누수, 무거운 연산의 메인 스레드 블로킹 여부를 체크합니다. 둘째, 플랫폼별 차이를 적절히 처리했는지, 네이티브 모듈 사용 시 에러 핸들링이 되어있는지 확인합니다. 셋째, 컴포넌트의 재사용성과 단일 책임 원칙 준수 여부를 검토합니다. 넷째, 테스트 가능성을 고려한 구조인지 확인하고 필요한 테스트가 작성되었는지 체크합니다. 코드 리뷰 시 단순히 지적하기보다는 왜 문제인지 설명하고 개선 방향을 제시하며, 반복되는 이슈는 린팅 룰이나 문서화로 자동화합니다. 또한 좋은 코드도 적극적으로 칭찬하여 팀의 베스트 프랙티스를 공유합니다.
- • 성능, 플랫폼 호환성, 아키텍처 관점의 체계적 리뷰
- • 교육적 피드백과 개선 방향 제시
- • 반복 이슈의 자동화 및 문서화
- • 긍정적 피드백을 통한 베스트 프랙티스 공유
팀의 코드 품질 기준을 수립하고 주니어 개발자의 성장을 돕는 동시에 프로덕션 안정성을 확보할 때 필요합니다.
코드 리뷰에서 주니어 개발자와 의견 충돌이 발생했을 때 어떻게 해결하시겠습니까?
Q. React Native에서 TDD(Test-Driven Development)를 적용할 때의 장점과 한계점은 무엇이며, 특히 네이티브 모듈이나 복잡한 UI 인터랙션을 개발할 때 TDD를 어떻게 적용하시겠습니까?
React Native의 네이티브 브릿지와 비동기 특성, 플랫폼 의존성을 고려해보세요.
TDD의 장점은 요구사항을 명확히 하고, 리팩토링 안전성을 확보하며, 테스트 가능한 구조로 설계를 유도한다는 점입니다. 하지만 React Native에서는 네이티브 모듈의 실제 동작을 테스트하기 어렵고, 복잡한 애니메이션이나 제스처는 E2E 테스트 없이 검증이 어렵다는 한계가 있습니다. 네이티브 모듈 개발 시에는 인터페이스를 먼저 정의하고 Mock을 활용한 Unit 테스트를 작성한 후, 실제 구현을 진행합니다. 이후 Integration 테스트로 실제 네이티브 코드와의 통합을 검증합니다. 복잡한 UI는 비즈니스 로직과 프레젠테이션을 분리하여 로직 부분만 TDD로 개발하고, UI 인터랙션은 Storybook으로 시각적 검증을 병행합니다. 완전한 TDD보다는 핵심 비즈니스 로직에 집중하는 하이브리드 접근이 효과적입니다.
- • TDD의 장점: 명확한 요구사항, 리팩토링 안전성, 테스트 가능한 설계
- • React Native의 한계: 네이티브 모듈, 애니메이션, 제스처 테스트의 어려움
- • 네이티브 모듈은 인터페이스 우선 설계 후 Mock 활용
- • 비즈니스 로직과 UI 분리, 하이브리드 접근법
복잡한 결제 모듈이나 실시간 채팅 기능처럼 안정성이 중요한 핵심 기능을 개발할 때 TDD 적용 여부를 결정하는 상황에서 활용됩니다.
TDD를 처음 도입하는 팀에서 개발 속도 저하에 대한 우려가 있을 때 어떻게 설득하고 도입하시겠습니까?
Q. 레거시 React Native 프로젝트에서 테스트 커버리지가 거의 없는 상태로 대규모 리팩토링을 진행해야 하는 상황입니다. 안전하게 리팩토링을 진행하기 위한 단계별 전략과 각 단계에서 적용할 테스트 기법을 설명해주세요.
테스트가 없는 코드를 리팩토링하기 전에 먼저 해야 할 일이 무엇인지 생각해보세요.
첫 단계로 Characterization Test(특성화 테스트)를 작성하여 현재 동작을 보존합니다. 기존 코드의 입출력을 있는 그대로 테스트로 기록하여 안전망을 확보합니다. 두 번째로 Golden Master Testing을 활용해 주요 시나리오의 스냅샷을 확보합니다. 세 번째로 가장 중요하고 변경이 잦은 비즈니스 로직부터 순차적으로 리팩토링하며, 각 단계마다 회귀 테스트를 실행합니다. 네 번째로 리팩토링된 부분에 대해 적절한 Unit/Integration 테스트를 추가하여 커버리지를 점진적으로 높입니다. 큰 변경은 Feature Flag를 활용해 점진적으로 배포하고, 모니터링을 강화하여 프로덕션에서의 이상 징후를 빠르게 감지합니다. 전체 리팩토링을 한 번에 진행하지 않고 Strangler Fig Pattern을 적용해 단계적으로 진행합니다.
- • Characterization Test로 현재 동작 보존
- • Golden Master Testing과 스냅샷 활용
- • 점진적 리팩토링과 회귀 테스트
- • Feature Flag와 Strangler Fig Pattern 활용
수년간 유지보수된 React Native 앱을 최신 아키텍처로 마이그레이션하거나 기술 부채를 해결할 때 필수적인 접근법입니다.
리팩토링 중 예상치 못한 버그가 프로덕션에서 발견되었을 때 어떻게 대응하시겠습니까?
Q. React Native 앱에서 REST API 통신, Redux 상태 관리, AsyncStorage 영속성이 함께 동작하는 기능의 통합 테스트를 작성할 때 고려해야 할 사항과 Mock 전략을 설명해주세요.
무엇을 실제로 테스트하고 무엇을 Mock 처리할지, 그리고 테스트의 독립성을 어떻게 보장할지 생각해보세요.
통합 테스트에서는 실제 Redux 스토어를 사용하고 API는 MSW(Mock Service Worker)나 nock으로 Mock 처리합니다. AsyncStorage는 @react-native-async-storage/async-storage의 mock을 사용하되, 각 테스트 전후로 clear하여 독립성을 보장합니다. 테스트 시나리오는 실제 사용자 플로우를 따라 작성하며, API 호출 후 Redux 상태 변경, AsyncStorage 저장, UI 업데이트까지 전체 흐름을 검증합니다. 네트워크 에러, 타임아웃 등 예외 상황도 함께 테스트합니다. waitFor, findBy 등 비동기 유틸리티를 활용해 상태 변경을 기다리며, act 경고가 발생하지 않도록 주의합니다. 테스트 데이터는 Factory 패턴이나 Fixture를 활용해 일관되게 관리하고, 테스트 간 의존성이 생기지 않도록 각 테스트마다 초기 상태를 설정합니다.
- • 실제 Redux 스토어 사용, API는 MSW로 Mock
- • AsyncStorage Mock과 테스트 독립성 보장
- • 사용자 플로우 기반 시나리오 테스트
- • 비동기 처리와 예외 상황 검증
로그인 후 사용자 정보를 가져와 저장하고 화면에 표시하는 등 여러 레이어가 협력하는 기능의 안정성을 검증할 때 사용됩니다.
통합 테스트가 너무 느려서 개발 생산성이 떨어질 때 어떻게 개선하시겠습니까?
Q. React Native 프로젝트에서 코드 품질을 자동으로 관리하기 위한 도구 체인(ESLint, Prettier, TypeScript, Husky 등)을 어떻게 구성하시겠으며, 팀 전체가 일관된 코드 스타일을 유지하도록 하기 위한 전략을 설명해주세요.
개발자의 로컬 환경, CI/CD 파이프라인, 코드 리뷰 프로세스 전반에서 자동화를 고려해보세요.
TypeScript를 strict 모드로 설정하여 타입 안정성을 확보하고, ESLint는 airbnb 또는 @react-native-community 설정을 기반으로 프로젝트에 맞게 커스터마이징합니다. Prettier는 ESLint와 충돌하지 않도록 eslint-config-prettier를 사용하여 통합합니다. Husky와 lint-staged를 활용해 커밋 전에 변경된 파일만 린트와 포맷을 자동 실행하고, commitlint로 커밋 메시지 규칙도 강제합니다. CI/CD 파이프라인에서는 린트, 타입 체크, 테스트를 필수로 통과하도록 설정하며, SonarQube나 CodeClimate 같은 정적 분석 도구로 코드 품질 메트릭을 추적합니다. VSCode 설정 파일(.vscode/settings.json)을 저장소에 포함시켜 팀원 모두가 동일한 에디터 설정을 사용하도록 합니다. 또한 ADR(Architecture Decision Record)을 작성하여 중요한 코딩 컨벤션 결정의 배경을 문서화합니다.
- • TypeScript strict 모드, ESLint, Prettier 통합 구성
- • Husky와 lint-staged로 커밋 전 자동 검증
- • CI/CD 파이프라인에서 필수 품질 게이트 설정
- • 에디터 설정 공유와 ADR 문서화
여러 개발자가 협업하는 프로젝트에서 코드 리뷰 시간을 줄이고 일관된 코드 품질을 유지하기 위해 필수적입니다.
자동화 도구가 개발 속도를 저하시킨다는 팀원의 불만이 있을 때 어떻게 대응하시겠습니까?
Q. 테스트 커버리지 80%를 달성했지만 여전히 프로덕션 버그가 자주 발생하는 상황입니다. 테스트 커버리지의 한계점과 실제로 의미 있는 테스트를 작성하기 위한 기준, 그리고 커버리지 지표를 어떻게 활용해야 하는지 설명해주세요.
단순히 코드를 실행하는 것과 실제로 중요한 동작을 검증하는 것의 차이를 생각해보세요.
테스트 커버리지는 코드 실행 여부만 측정할 뿐 테스트의 품질이나 의미 있는 시나리오 검증 여부는 보장하지 않습니다. 높은 커버리지에도 버그가 발생하는 이유는 엣지 케이스 누락, 통합 테스트 부족, 실제 사용자 시나리오와 다른 테스트, 비즈니스 로직이 아닌 보일러플레이트 코드 위주의 테스트 때문입니다. 의미 있는 테스트를 위해서는 사용자 관점의 시나리오를 테스트하고, 엣지 케이스와 에러 상황을 반드시 포함하며, Mutation Testing을 활용해 테스트가 실제로 버그를 잡아내는지 검증합니다. 커버리지는 절대 목표가 아닌 최소 기준선으로 활용하고, 핵심 비즈니스 로직은 100%, UI 컴포넌트는 낮은 커버리지를 허용하는 등 차등 적용합니다. 프로덕션 버그 발생 시 해당 케이스를 테스트로 추가하는 회귀 방지 프로세스를 정착시킵니다.
- • 커버리지는 테스트 품질을 보장하지 않음
- • 사용자 시나리오, 엣지 케이스, 에러 상황 중심 테스트
- • Mutation Testing으로 테스트 효과성 검증
- • 영역별 차등 커버리지와 회귀 방지 프로세스
테스트 전략을 수립하고 실제로 프로덕션 안정성을 높이는 테스트 문화를 구축할 때 필요한 관점입니다.
팀에서 커버리지 80% 달성을 KPI로 설정하려고 할 때 어떤 의견을 제시하시겠습니까?
아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!