💡 내가 발견한 이슈가 수정 포인트가 크다면?

※ 이 글은 개인적인 경험과 주관을 바탕으로 작성되었습니다.
 

📌 Introduction

QA의 하루는 프로젝트의 단계에 따라 크게 달라집니다.

• 초기: 기획서 검토 및 기획서를 바탕으로 Test Case 작성
• 중반: 개발이 완료된 기능을 작성된 Test Case를 바탕으로 검증
• 후반: Regression 테스트와 통합 테스트를 통해 사이드 이펙트 여부와 핵심 기능 정상 동작 여부 확인

 
프로젝트 중반, 작성한 Test Case를 기반으로 테스트를 진행하다 보면 Jira에 버그를 등록하게 됩니다. 이때 가끔 개발자나 기획자로부터 "해당 부분은 오래된 구조(legacy)라 수정 범위가 너무 크지만, 발생 빈도가 낮으니 이번에는 Close 처리하자"는 피드백을 받기도 합니다.
 
이런 상황에서 고민이 생깁니다.

• 수정 범위가 크지만 소수의 사용자만 겪는 문제
• 소수의 사용자를 위해 리소스를 투자하여 수정

과연, 어떤 것이 더 합리적일까요?

이번 글에서는 이 고민을 중심으로 이야기를 풀어보고자 합니다.
 

📌 책에서 배운 QA의 태도

QA를 준비하며 읽었던 『테스트 너머의 QA 엔지니어링』에서 인상 깊었던 문장이 있습니다.
 
"품질을 위해 버그를 발견하고 예방해야 하는 QA 엔지니어에게 더 중요한 것은 제품의 품질을 사수하고 높이려는 목적에만 맹목적으로 매몰되지 않는 것이다."
"QA 엔지니어가 모든 버그를 다 고치라고 요구할 수는 있지만, 모든 말이 정답이라는 태도는 구성원의 전문성을 무시하는 고집일 뿐이다."
"QA 엔지니어는 기업 내 ‘기업 안의 고객’이 되어, 기업·동료·고객 모두에게 최고의 만족을 제공하기 위한 중간 지점을 찾아야 한다."
 
사실 책을 처음에 읽었을 때는 크게 와닿지 않았으나, 실무 경험을 겪고 나서 위 내용이 떠올랐던 이유는, 실제 현업에서도 품질 절대주의와 현실적인 제약 사이에서 균형을 잡아야 하는 순간이 많기 때문입니다. 기업의 최우선 목표는 인력·시간·비용 등 리소스를 최소화해 최대의 이익을 내는 것입니다. 그렇기 때문에 QA의 역할은 ‘품질을 무조건 지켜야 한다’가 아니라, 품질과 리소스 사이에서 가장 합리적인 선택을 제안하는 것이 되어야 합니다.
 
예를 들어, 회사 개발자 동료분께서 이렇게 말씀해 주신 적이 있습니다.
“빈번하게 발생하지 않는 문제지만 수정 범위가 너무 크면, 이를 해결하는 데 들어가는 리소스가 상당히 많아요. 단순히 개발자만의 문제가 아니라, QA, 기획, 디자인 등 여러 직군이 투입되고, 이 과정에서 의견 조율과 커뮤니케이션 비용도 무시할 수 없습니다. 결국 이런 복잡한 상황을 고려하다 보면, 당장 이번 릴리즈에서는 해당 이슈를 Close 처리하고 차후에 더 좋은 환경에서 수정하는 방향으로 가는 경우가 꽤 있어요. 사실 이런 일은 어느 회사에서나 흔히 겪는 일입니다."
 
이 말은 곧, QA가 발견한 버그라 하더라도 그 수정이 전체 프로젝트에 주는 영향과 가치를 냉정하게 판단해야 한다는 것을 의미합니다.
 

📌 수정 포인트가 큰 경우, QA의 판단 기준

수정 범위가 크고 복잡한 이슈는 단순한 버그 수정과 달리 신중한 분석과 협의가 필요합니다.
QA는 아래와 같은 기준을 바탕으로 영향과 우선순위를 평가하고, 효과적인 의사결정을 돕습니다.
 
1. 영향도 분석

• 수정 범위가 넓어질수록, 해당 변경이 다른 기능들에 미치는 파급효과가 커짐
• 수정 포인트가 크면 단순한 기능 개선을 넘어 광범위한 재검증이 필요

2. 사용자 영향 범위

• 빈번하게 발생하고 많은 사용자에게 영향을 미치는 버그는 즉시 수정 대상
• 반면, 드물게 발생하고 소수 사용자에게만 영향을 주는 이슈는 수정 시기와 범위를 신중하게 결정
• 보통 ‘발생 빈도 × 영향도’로 우선순위 산정

3. 리소스와 리스크 균형

• 수정 작업에 개발, QA, 기획, 디자인 등 여러 직군의 시간과 노력이 얼마나 필요한지 평가
• 리소스 대비 효과가 낮다고 판단되면, 차기 릴리즈나 리팩터링 시점에 미루는 전략도 고려

 

📌 마무리

QA는 단순히 버그를 발견하는 사람을 넘어,

• 영향 범위를 분석하고,
• 리소스 대비 효과를 고려하며,
• 협업을 통해 최적의 선택을 이끌어내는 조율자입니다.

모든 버그를 다 고치는 것이 이상적이지만, 현실에서는 제품 안정성, 일정, 리소스, 비즈니스 목표를 모두 고려한 중간 지점을 찾는 것이 더 큰 가치일 때가 많습니다. 따라서 QA에게 "버그 수정 여부를 합리적으로 판단하고 설득할 수 있는 힘" 역량 역시 중요하다고 생각합니다.