이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
유닛 테스트는 pytest로 작성했고, 핵심 비즈니스 로직을 담당하는 함수부터 커버했습니다. 특히 경계 조건과 예외 케이스를 명시적으로 테스트하니 코드를 수정할 때 기존 동작이 깨지는 것을 바로 감지할 수 있었습니다.
CI 연동은 GitHub Actions로 구성했습니다. PR을 올릴 때마다 전체 테스트가 자동으로 실행되고, 실패하면 머지가 차단되는 구조를 팀에 제안했습니다. 처음에는 CI 설정에 시간이 걸렸지만 이후 리뷰 속도가 빨라지고 테스트 누락으로 인한 버그가 줄었습니다.
프로젝트 후반에는 커버리지 리포트를 CI에 추가했습니다. 어느 함수가 테스트되지 않았는지 시각적으로 확인할 수 있으니 팀원들이 자연스럽게 테스트를 추가하는 문화가 생겼습니다.
유닛 테스트와 CI를 도입하기 전후를 수치로 비교한 경험이 있습니다. 도입 전에는 PR 리뷰 중 리뷰어가 직접 실행해보면서 버그를 발견하는 경우가 많았는데, CI로 테스트가 자동화된 이후에는 리뷰에서 발견되는 런타임 오류가 눈에 띄게 줄었습니다. 리뷰 시간도 달라졌는데, 기존에는 코드 실행 검증에 시간을 쓰던 것을 이제는 로직 리뷰에 집중할 수 있어서 PR당 평균 리뷰 시간이 절반 정도로 줄었습니다. 테스트 커버리지를 측정했더니 핵심 비즈니스 로직은 85% 이상 커버됐는데, 나머지 15% 중 일부에서 나중에 버그가 발견됐습니다.
커버되지 않은 경로에서 버그가 나온다는 것을 데이터로 확인한 순간이었습니다. 반면 커버리지 수치를 높이기 위해 의미 없는 테스트를 추가하는 것은 비용만 들고 실제 품질에 도움이 안 된다는 것도 배웠습니다. 테스트와 CI의 효과는 버그 발생 시점을 개발 중으로 당기는 것에서 온다는 것을 이 경험에서 얻었습니다.
GitHub Actions로 CI를 구성하면서 여러 Python 버전에서 동시에 테스트해야 하는 상황이 있었습니다. 매트릭스 빌드 기능으로 python-version: [3.9, 3.10, 3.11]을 설정하면 세 버전이 병렬로 실행되어 호환성 문제를 한 번에 확인할 수 있었습니다. 처음에는 각 버전마다 별도 job을 만들었는데, 매트릭스로 바꾸니 설정 파일이 3분의 1로 줄었습니다. 시크릿 관리도 이때 처음 의식했는데, 테스트에 필요한 API 키를 yaml 파일에 직접 넣다가 레포지토리에 커밋해버린 적이 있었습니다. GitHub Secrets에 등록하고 ${{ secrets.API_KEY }}로 참조하는 방식으로 바꿔서 코드에 민감 정보가 노출되지 않도록 했습니다. CI 설정 파일이 코드 리포지토리에 함께 관리되니 인프라 변경 이력이 코드 커밋으로 남아서 팀원이 언제 어떻게 파이프라인이 바뀌었는지 알 수 있게 됐습니다.
CI는 자동화 그 자체보다 팀이 같은 기준으로 코드를 검증하는 프로세스를 만드는 것이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.