이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 테스트 코드 없이 진행하다 기능이 늘어날수록 어디가 깨지는지 알 수 없게 됐습니다. 그때부터 pytest로 단위 테스트를 쓰기 시작했고, CI에 연결해서 PR 병합 전에 테스트가 통과해야 하는 규칙을 팀과 정했습니다. 코드 리뷰에서는 기능 동작 외에 엣지 케이스가 처리됐는지를 먼저 확인하는 방향으로 기준을 세웠습니다. 정적 분석 도구로 flake8을 붙였더니 형식 지적이 사라지고 리뷰가 로직 중심으로 바뀌었습니다. 관측 쪽에서는 중요한 기능의 처리 결과를 로그로 남겨 문제 발생 시 재현하기 쉽게 했습니다. 테스트 커버리지가 올라가면서 기능을 수정할 때 다른 부분이 깨지는 걸 먼저 알 수 있는 안전망이 생겼습니다.
품질은 검수 단계보다 작성 단계에서 더 효과적으로 잡히는 자리라는 걸 그때 배웠습니다.
팀에서 PR 리뷰가 오래 걸리거나 형식적으로 되는 문제를 겪었습니다. 리뷰어가 어디를 봐야 할지 기준이 없어서 의견이 스타일 지적에 치우치는 경향이 있었습니다. PR 템플릿에 체크리스트를 추가했는데, 변경 이유·테스트 항목·엣지 케이스·롤백 방법을 작성자가 먼저 정리해 올리도록 했습니다. 리뷰어가 맥락을 이해하는 데 드는 시간이 줄었고, 의견이 스타일보다 로직과 엣지 케이스 중심으로 바뀌었습니다. 지표로 확인해보니 PR 사이클 평균이 이틀에서 하루로 줄었습니다. 한계는 체크리스트가 길어지면 형식적으로 채우는 경우가 생긴다는 것인데, 항목을 3~5개로 제한하는 것이 실질적이었습니다.
코드 품질은 리뷰 단계에서 설계 문제를 잡는 비용이 배포 후보다 훨씬 낮다는 것을 이 경험에서 배웠습니다.
배포 후 발생하는 오류를 빠르게 잡는 것도 품질 관리의 일부라고 생각했습니다. 기능을 배포하고 나서 예상치 못한 예외가 로그에 쌓이는 것을 다음날 아침에야 알게 되는 상황이 있었습니다. 배포 직후 30분 동안 오류율을 추적하는 모니터링을 붙였고, 임계치를 넘으면 알림이 오도록 설정했습니다. 이 구조를 갖추자 배포 후 빠르게 롤백하거나 핫픽스를 적용하는 속도가 달라졌습니다. 지속 가능한 품질 관리를 위해 리스크가 높은 신규 기능에는 피처 플래그를 붙여 문제가 생기면 배포 없이 끌 수 있는 비상구를 만들었습니다. 모든 기능에 다 적용할 수는 없었지만, 선별 적용하는 방식이 팀 부담을 줄였습니다.
품질은 배포 전 검증만이 아니라 배포 후 회복 속도까지 포함한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.