이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 코드 품질 지표를 처음으로 체계화해본 경험이 있습니다. 이전에는 테스트가 통과하면 충분하다고 생각했는데, 커버리지 수치만 높고 의미 있는 케이스를 전혀 검증하지 않는 코드를 본 뒤 지표의 한계를 실감했습니다. 그래서 단순 커버리지 외에 핵심 비즈니스 로직 경로 커버율과 변경이 많은 파일의 복잡도 지표를 추가로 추적했습니다.
SonarQube를 CI에 연결해 PR마다 자동으로 분석 결과가 달리도록 세팅했고, 이후 팀원 모두가 코드 리뷰 전에 정적 분석 결과를 먼저 보는 문화가 자연스럽게 생겼습니다. 지금도 지표는 목표가 아닌 경보 신호로 쓰는 게 적합하다는 관점을 유지하고 있습니다.
품질 지표를 활용하면서 가장 크게 실감한 한계는 숫자가 높다고 품질이 보장되지 않는다는 것이었습니다. 테스트 커버리지 90%를 달성했는데도 실제 배포 후 버그가 나온 적이 있었습니다. 살펴보니 커버리지는 행 단위로 측정되는데, 정상 흐름만 지나가고 예외 경로를 전혀 검증하지 않은 것이 원인이었습니다. 또한 PR마다 SonarQube 결과를 달았지만, 숫자가 나쁘지 않으면 경고 내용을 실제로 읽는 팀원이 줄어드는 상황도 생겼습니다. 지표가 알람이 아니라 통과 기준이 되는 순간 형식화가 시작됩니다. 이후에는 지표 수치보다 새로 발생한 항목에 집중하도록 리뷰 방식을 바꿨습니다.
품질 지표는 문제를 찾는 보조 도구이지, 지표 자체가 목표가 되면 안 된다는 것을 이 경험에서 배웠습니다.
코드 품질 지표에서 시작해 런타임 성능 지표까지 추적 범위를 넓힌 경험이 있습니다. SonarQube로 정적 분석을 하다 보면 코드 구조는 깔끔한데 실제 응답이 느린 경우가 생겼고, API 응답 시간 P95와 단일 요청에서 발생하는 DB 쿼리 수를 별도로 추적하기 시작했습니다. CI에서 임계값을 넘으면 경고를 띄웠는데, 처음 발견한 문제는 N+1 쿼리 패턴이었습니다. 코드 리뷰로는 잘 보이지 않다가 쿼리 수 지표로 즉시 드러났습니다. 지표를 추가하자 팀원들이 코드를 머지하기 전에 직접 쿼리 수를 확인하는 행동 변화가 생겼습니다.
지표가 바꾸는 것은 숫자가 아니라 행동이라는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.