QA 전달 전에 개발자가 먼저 검증해야 하는 이유

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

개발자는 변경 사항의 예상 동작을 직접 확인한 뒤 QA에 전달해야 한다. QA 티켓이 미처 생각하지 못한 경계 사례를 찾을 수는 있지만, 기본 동작의 실패까지 개발 과정에서 당연히 거치는 단계로 보고 다른 직군에 맡겨서는 안 된다. 기능을 구현한 사람도 동작을 증명할 책임을 나눈다.

조직마다 역할은 다르다. 테스터와 QA를 구분하는 곳도 있고 수동 테스트, 자동화, 더 넓은 품질 업무를 한 역할이 맡는 곳도 있다. 업무 경계가 달라도 원칙은 같다. QA가 아무 검증도 하지 않은 기능을 처음 실행하는 사람이 되어서는 안 된다.

QA는 뻔한 경로보다 바깥을 찾게 한다

개발자는 구현 선택과 의도한 정상 흐름을 알고 있다. 그 지식으로 예상 동작과 자신이 확인할 수 있는 최소한의 사례를 전달 전에 검증해야 한다. 시스템에 따라 자동화 테스트나 의도적인 손 검증을 할 수 있다. 테스트 코드가 모든 검증을 해결하지는 않는다.

그러면 QA는 한정된 시간을 경계 조건, 드문 조합, 극단적인 입력, 구현자가 예상하지 못한 제품 동작에 더 쓸 수 있다. 이런 사례를 드러낸 티켓은 안전망을 강화한다. 정상 경로를 한 번도 실행하지 않아 생긴 티켓과는 성격이 다르다.

AI는 테스트를 생성하고 후보 사례를 제안할 수 있지만 개발자의 검증 판단을 대신하지 않는다. 변경이 어떻게 실패할 수 있는지 설명하지 못하면 생성된 테스트가 의미 있는지, 해피 패스만 반복하는지 평가할 수 없다.

수정해서 바로 돌려보내는 반복은 다른 팀까지 막는다

검증 없는 전달은 비싼 순환을 만든다. QA가 A 문제를 찾으면 개발자는 A만 고쳐 곧바로 돌려보내고, 이어서 B가 나타나며, 뒤의 수정이 A를 다시 깨뜨린다. 매번 QA는 같은 검증을 반복해야 한다.

영향은 두 사람에게 그치지 않는다. 일주일로 계획한 QA 자원을 반복 수정이 더 오래 점유하면 다음 팀의 배포도 막힌다. 선행 기능을 기다리는 작업이 늦어지고 일정이 밀리며, 최초 개발자는 코딩을 끝냈다고 생각하는 동안 회사의 전달 속도는 느려진다.

QA는 준비되지 않은 변경을 반복해서 전달하는 개발자의 작업을 기피하게 될 수 있다. 이런 전달은 제품 품질을 위해 가장 가까이 협력해야 하는 두 직군 사이의 신뢰를 무너뜨릴 수 있다.

수정한 뒤에는 검증하고 돌려보낸다

QA가 이슈를 전달했을 때 그 부분만 고치고 테스트 없이 곧바로 빌드를 돌려보내서는 안 된다. 수정한 뒤에는 상황에 맞는 자동화 테스트나 손 검증을 거쳐 다시 전달해야 한다. 그렇지 않으면 같은 수정과 재전달이 반복되어 QA의 시간을 쓰고 다른 팀의 일정까지 늦출 수 있다.

목표는 QA 티켓이 하나도 나오지 않게 하거나 티켓이 나오면 부끄러워하는 것이 아니다. 복잡한 소프트웨어에는 예상하지 못한 결함이 생길 수 있다. 다만 기본 정확성에 도달하는 과정을 티켓이 대신 끌고 가는 일을 당연시해서는 안 된다. 개발자와 QA는 하나의 제품 안전망을 만들며, 각자 검증한 작업과 서로 다른 관점을 보태야 한다.