이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
모바일 프로젝트에 유닛 테스트를 처음 붙였을 때 무엇을 테스트해야 하는지 판단 기준이 없어서 처음에는 커버리지 수치를 맹목적으로 높이는 방향으로 갔습니다. 그러다 화면 로직보다 비즈니스 로직이 담긴 `ViewModel`과 `Repository` 계층을 먼저 테스트하는 게 실질 가치가 높다는 걸 코드 리뷰에서 배웠습니다.
GitHub Actions로 PR마다 빌드·테스트를 자동 실행하게 설정했고, 테스트가 깨지면 머지가 막히는 룰을 붙이니 팀 전체가 테스트를 진지하게 보기 시작했습니다. 초반 CI 파이프라인이 7분이 걸렸는데, 병렬 잡 분리와 캐시 설정으로 3분대로 줄였습니다. 테스트 자체보다 테스트를 고치는 비용을 같이 고려해야 한다는 것도 이 과정에서 배운 점입니다.
유닛 테스트를 처음 작성할 때 어디서부터 시작해야 할지 몰라서 UI부터 테스트하려다 막혀버린 경험이 있었습니다. UI 테스트는 설정이 복잡해서 빠르게 시작하기 어려웠고, 테스트 작성 자체를 멈추게 됐습니다.
이후엔 순수 함수처럼 입력이 같으면 출력이 항상 같은 로직부터 먼저 커버하는 방식으로 바꿨습니다. 할인 계산·유효성 검사 같은 비즈니스 로직 함수를 먼저 테스트하니 배포 전에 로직 버그를 잡는 경험이 생겼습니다.
이 경험으로 유닛 테스트는 복잡한 곳부터가 아니라 가장 순수한 로직부터 시작하는 것이 진입장벽을 낮춘다는 걸 배웠습니다. 첫 테스트가 가장 어렵습니다.
GitHub Actions를 도입하기 전엔 배포할 때마다 테스트를 수동으로 돌리다 빠뜨리는 경우가 생겼습니다. 급하게 배포할 때 테스트를 건너뛰고 나중에 버그가 나오는 패턴이 반복됐습니다. "이번엔 괜찮겠지"라는 판단이 사후 수정을 만들었습니다.
파이프라인을 만들고 머지 요청 시 자동으로 테스트가 돌게 설정하니 사람 판단에 의존하지 않아도 됐습니다. 테스트 실패 시 머지가 막히는 구조가 됐고, 수동 배포에서 놓쳤던 버그가 CI 단계에서 먼저 잡히기 시작했습니다.
이 경험으로 CI는 사람의 기억에 의존하던 것을 파이프라인이 대신하는 구조라는 걸 배웠습니다. 자동화가 실수를 줄였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.