품질은 예산의 문제다

당신이 밤새워 살리려는 그 릴리스는 몇 달 전에 이미 결정되어 있었다.

릴리스를 일주일 앞둔 시점이다. QA는 최소한의 기능 커버리지라도 확보하려고 밤을 새운다. 버그 하나가 발견될 때마다 일정이 흔들린다. 새로운 질문이 나올 때마다 범위가 흔들린다. 리스크 하나를 제기할 때마다 누군가 이해관계자에게 이미 해둔 약속이 흔들린다.

회의실에서 오가는 대화는 테스트에 관한 것이다.

왜 QA가 이걸 잡지 못했을까? 왜 이 시나리오에 회귀 테스트 케이스가 없었을까?

하지만 이 릴리스의 결과는 누군가 첫 회귀 테스트 스위트를 실행하기 훨씬 전부터 결정되어 있었다. 품질은 막판에 갑자기 무너지지 않는다. 여러 차례의 트레이드오프를 거치며 조금씩 깎여 나간다. 프로젝트 자원의 대부분은 테스트가 시작되기도 전에, 주로 기능을 만드는 데 이미 투입되었기 때문이다.

테스트를 더 한다고 품질이 올라가지 않는 이유

테스트는 중요하다. 피드백을 제공하고, 리스크를 드러내며, 확신의 근거를 만들고, 회귀를 방지하고, 시스템의 동작을 검증한다.

하지만 테스트가 설계가 부실한 시스템에 품질을 주입할 수는 없다. 아키텍처가 취약하다면 테스트가 통과하더라도 변경은 여전히 위험하다. 일정이 비현실적이었다면 커버리지는 얕을 수밖에 없다. 범위가 팀의 역량을 넘어섰다면 결함 밀도는 그 간극을 그대로 드러낸다.

테스트는 목표와 현실 사이의 간극을 보여줄 수 있다. 하지만 그 간극 자체를 메우지는 못한다.

따라서 품질이 기대에 미치지 못해 "왜 QA가 이걸 잡지 못했지?"라는 질문이 나올 때, 그보다 먼저 물어야 할 질문이 있다.

우리가 기대한 품질을 달성할 만큼 충분한 자원을 배정했는가?

품질 예산

모든 프로젝트에는 유한한 품질 예산이 있다. 재무제표에 기록되는 항목은 아니다. 시간과 에너지, 주의력을 어디에 얼마나 배분하는지에 관한 실제적인 제약이다.

그 예산은 서로 경쟁하는 여러 영역에 나뉘어 투입된다.

기능 개발
아키텍처 설계
자동화 테스트 작성
관측 가능성 개선
코드 리팩토링
코드 리뷰
기술 부채 해소
배포 안정성 개선

범위는 10주 분량인데 주어진 일정은 8주뿐인 팀을 생각해 보자.

아무도 품질을 줄이겠다고 결정하지는 않는다. 하지만 캘린더에 잡혀 있던 설계 리뷰 회의는 취소된다. 대신 슬랙에 문서 링크가 올라오고, "괜찮아 보여요" 두어 개가 달리며 끝난다. 새 모듈을 테스트하기 쉽게 만들었을 리팩토링은 "런칭 이후"로 미뤄진다. 자동화 백로그는 계속 쌓인다.

6주 차가 되면 투입된 노력의 90%가 기능 출시에 집중되어 있다. 시스템을 튼튼하게 만드는 데 남은 10%가 QA가 물려받는 전부다.

품질은 프로젝트 막바지에 뒤늦게 사들일 수 없다. 처음에 배정하지 않은 품질 예산을 나중에 초과해서 쓸 수는 없다. 팀이 개발 막바지에 불안정성을 발견한다면, 그것은 반드시 테스트의 실패를 의미하지 않는다. 앞서 내린 자원 배분 결정이 만들어 낸 결과일 수 있다.

품질이 모자랐던 게 아니라, 품질에 쓸 시간을 처음부터 남겨 두지 않았던 것이다.

QA가 짐처럼 느껴지는 이유

품질은 어느 한 역할의 산출물이 아니다. 시스템 전체가 만들어 내는 결과다. 계획을 세우는 방식, 범위를 협상하는 방식, 마감을 정하는 방식, 인센티브를 설계하는 방식, 트레이드오프를 공유하는 방식이 모두 품질에 영향을 준다.

리더십이 지속 가능성보다 속도에 보상하면 시스템은 속도에 최적화된다. 로드맵 약속이 엔지니어링 역량을 무시하면 시스템에는 취약성이 쌓인다. 품질에 관한 논의가 릴리스 시점에만 이루어지면 시스템은 리스크를 QA에게 떠넘긴다.

그런 환경에서 테스트는 병목처럼 보인다.

테스터가 느려서가 아니다. 이미 쌓인 리스크에 제동을 걸 수 있는 마지막 수단이 검증이기 때문이다. QA는 일정 압박에 맞서는 눈에 보이는 마찰이 된다.

하지만 마찰은 문제의 원인이 아니다. 시스템이 균형을 잃었다는 신호다.

초기부터 예산이 아키텍처의 명확성, 자동화, 점진적인 검증, 지속적인 피드백에 배분되었다면 테스트는 대립이 아니라 확인의 과정으로 느껴졌을 것이다.

이러한 트레이드오프는 단순한 철학적 문제가 아니다. 자원이 제한된 상황에서 범위를 늘리면 달성 가능한 품질은 줄어든다. 품질을 높이려면 범위를 줄이거나 일정을 늘려야 한다. 속도를 높이려면 더 큰 리스크를 감수해야 한다.

품질은 팀이 부주의해서만 떨어지는 것이 아니다. 트레이드오프를 선택하면서 그에 따르는 비용을 충분히 인정하지 않기 때문에 떨어진다. 그리고 그 선택이 일찍 이루어질수록 결과는 더 늦게, 더 눈에 띄지 않는 형태로 나타난다.

대신 던져야 할 질문

어느 시점에선가, 의식하든 그렇지 않든 모든 팀은 '이 정도면 충분하다(good enough)'는 기준을 정한다.

그 기준은 시장의 마감, 투자자의 기대, 로드맵 약속, 경쟁 압박, 리더십의 리스크 감수 성향에 의해 만들어진다.

문제는 그 기준이 끝내 명시되지 않을 때 발생한다. 품질은 사후 대응의 대상이 되고, 테스트는 방향을 안내하는 수단이 아니라 릴리스를 막는 관문이 된다. QA가 던지는 질문은 추진력이 아니라 마찰로 받아들여진다.

품질은 마지막에 얼마나 많이 테스트했느냐의 문제가 아니다. 프로젝트 초기에 무엇에 투자하기로 결정했느냐의 문제다.

품질은 부서가 아니다. 개발 단계도 아니고, 체크리스트도 아니다.

품질은 예산의 문제다. 그리고 모든 프로젝트는 의식하든 그렇지 않든 그 예산을 결정한다.

그러니 다음 기획 회의에서는 일정이 확정되기 전에 세 가지를 물어보자.

우리는 품질을 위해 어떤 자원을 배정하고 있는가?
이번 릴리스에서 '이 정도면 충분하다'는 것은 무엇을 의미하는가?
범위와 기대치는 우리가 실제로 가진 자원과 일치하는가?

이 질문을 일찍 던지면 테스트는 계획이 올바르게 실행되었는지 확인하는 과정이 된다.

너무 늦게 던지면 테스트는 애초에 계획이 현실적이지 않았다는 사실을 확인하는 과정이 된다.