이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 인턴 과제로 정적 분석 도구 도입을 맡으며 Shift-Left를 처음 적용했습니다. 기존에는 QA 단계에서야 버그가 발견됐는데, PR 단계에서 ESLint + SonarQube를 CI에 연동해 코드가 머지되기 전에 문제가 드러나도록 파이프라인을 바꿨습니다. 초반에 경고가 한꺼번에 800건 터져 팀원 불만이 있었고, severity 기준으로 Critical·Major만 블록하고 나머지는 표시만 하는 설정으로 점진 적용했습니다. 2개월 뒤 QA에서 발견되는 신규 버그 수가 43% 감소했고, 리뷰 피드백도 로직 중심으로 집중됐습니다. 이 경험으로 도구 도입의 마찰을 줄이려면 단계적 강도 조절이 중요하다는 것을 깨달았습니다.
TDD를 처음 써봤을 때 테스트를 먼저 쓰는 게 오히려 구현보다 더 어렵다는 걸 바로 느꼈습니다. 기능을 어떻게 호출할지 먼저 정해야 하니까요. 졸업 프로젝트에서 주문 계산 로직을 짤 때 테스트를 먼저 작성하는 방식을 적용해봤습니다. Red → Green → Refactor 사이클을 돌리면서, 테스트를 통과시키는 데 집중하다 보니 함수가 자연스럽게 작게 쪼개졌습니다. 처음엔 느렸는데, 구현하고 나서 경계값·예외 케이스를 추가로 검토하지 않아도 됐습니다. 이미 테스트에 그 케이스가 담겨 있었기 때문입니다. 리팩터링할 때 테스트가 회귀 방지망이 되니 변경이 두렵지 않았습니다. 모든 기능에 TDD를 쓸 순 없지만, 복잡한 로직일수록 설계를 피드백 받는 가장 좋은 방법이라고 봅니다.
개발을 시작하기 전에 완성의 기준을 명확히 안 정한 게 문제라는 걸 버그를 보고 나서야 알게 됐습니다. 기획서를 보고 개발했는데 QA에서 예상 동작이 다르다는 피드백이 반복됐습니다. 그래서 이후엔 기능을 시작하기 전에 수락 기준 3~5개를 직접 작성해서 기획·QA와 먼저 맞추는 방식을 도입했습니다. 예를 들어 "쿠폰 적용 시 할인 금액은 소수점 이하 버림" 같은 경계 동작을 미리 문서에 박았습니다. 이 기준이 나중에 테스트 케이스 초안이 되면서 QA 준비 시간도 줄었습니다. 처음엔 기준을 쓰는 게 번거롭게 느껴졌는데, 한 번 쓴 기준이 개발·QA·배포 후 지원 문의까지 재활용되는 걸 보고 습관이 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.