“자동화했는데 왜 버그가 나왔어요?”: 내 억울함을 설득하기

또 이 질문이다

오늘 아침 스탠드업 미팅. CTO가 물었다.

“자동화 커버리지 80%잖아. 그럼 왜 프로덕션에서 버그 나와?”

억울했다. 진짜 억울했다.

설명했다. 자동화는 회귀 테스트용이고, 80%는 단위 테스트 기준이고, 이번 버그는 엣지 케이스였다고.

CTO가 고개를 끄덕였다. 이해한 건지 모르겠다.

회의 끝나고 개발팀장이 슬랙을 보냈다. “자동화 더 늘려야 할까요?”

아니다. 문제는 자동화 양이 아니다. 이해의 문제다.

자동화 QA 4년 했다. 이 질문을 100번은 들었다. 이제는 설득하는 법을 알아야 한다. 내 시간을 위해서라도.

자동화가 뭔지부터 다시

가장 큰 오해. “자동화했으면 모든 버그를 잡는다.”

틀렸다.

자동화 테스트는 내가 짠 시나리오만 검증한다. 로그인 시나리오를 100개 짜면, 그 100개만 체크한다. 101번째 방법? 못 잡는다.

예를 들어보자.

우리 서비스에 로그인 자동화 테스트가 있다.

• 올바른 ID/PW 입력 → 성공
• 틀린 PW 입력 → 실패 메시지
• 빈칸 입력 → 경고 메시지
• SQL 인젝션 시도 → 차단

이게 다 통과했다. 초록불이다.

그런데 지난주 프로덕션에서 버그가 났다. 특수문자가 30개 이상 들어간 비밀번호를 입력하면 서버가 멈췄다.

내 테스트에 없었다. 특수문자 3개는 테스트했다. 30개는 생각 못 했다.

이게 자동화의 한계다. 내가 상상한 것만 테스트된다.

경영진은 이걸 이해 못 한다. “80% 커버리지면 충분하지 않아?”

그 80%가 뭔지 모른다. 코드 라인 커버리지인지, 기능 커버리지인지, 유저 시나리오 커버리지인지.

우리 회사는 코드 라인 기준이다. 코드의 80%를 테스트 코드가 실행했다는 뜻. 그게 모든 버그를 잡는다는 뜻은 아니다.

개발자들은 이해한다. 테스트 커버리지 100%도 버그를 보장 못 한다는 걸.

근데 경영진은 숫자만 본다. 80%면 A학점이라고 생각한다.

매뉴얼 테스트가 필요한 이유

두 번째 오해. “자동화했으면 매뉴얼 QA는 필요 없다.”

이건 더 위험한 생각이다.

지난달 우리 회사가 신입 QA 채용을 안 하려고 했다. “자동화 있는데 왜 필요해?”

내가 막았다. 1시간짜리 문서를 만들어서 설명했다.

자동화는 반복 작업에 강하다.

• 회귀 테스트: 매 배포마다 똑같은 시나리오 체크
• 스모크 테스트: 빌드 후 기본 기능 확인
• API 테스트: 엔드포인트 검증

근데 자동화가 못하는 게 더 많다.

탐색적 테스트 유저가 어떻게 쓸지 모르는 상황. 아무렇게나 눌러보는 거. 이건 스크립트로 못 짠다.

지난주 신기능 출시 전에 매뉴얼 QA 동료가 찾았다. 뒤로가기 버튼을 5번 연속 누르면 앱이 튕겼다. 내 자동화 스크립트엔 “뒤로가기 2번”까지만 있었다.

누가 5번을 누르나? 유저가 누른다. 짜증나서 막 누른다.

UX/UI 테스트 버튼이 너무 작다. 폰트가 안 읽힌다. 색상이 이상하다. 이건 사람 눈으로 봐야 한다.

Selenium으로 “버튼이 존재하는가?”는 체크할 수 있다. “버튼이 예쁜가?”는 못 한다.

작년에 디자인 개편했을 때. 자동화 테스트는 다 통과했다. 근데 매뉴얼 QA가 발견했다. 다크모드에서 글자가 안 보였다.

자동화는 “글자가 렌더링되는가?”만 체크했다. “글자가 보이는가?”는 체크 안 했다.

신규 기능 테스트 새 기능이 나오면 자동화 스크립트부터 짜야 한다. 그 전에 매뉴얼로 먼저 테스트한다. 뭘 자동화할지 모르니까.

경영진한테 설명했다. “자동화는 알고 있는 걸 반복하는 거예요. 매뉴얼은 모르는 걸 찾는 거고요.”

통했다. 신입 QA 2명 뽑았다.

자동화의 실제 가치

그럼 자동화는 왜 하나?

가치가 없는 건 아니다. 명확한 가치가 있다.

시간 절약 회귀 테스트를 매뉴얼로 하면 3일 걸린다. 자동화로 하면 3시간이다. 이건 큰 차이다.

매주 배포하는 우리 회사. 매뉴얼로만 하면 QA팀이 테스트만 한다. 자동화 덕분에 다른 일을 한다.

일관성 사람은 실수한다. 피곤하면 놓친다. 점심 먹고 오면 집중력이 떨어진다.

스크립트는 안 그렇다. 새벽 3시에 돌려도 똑같이 체크한다.

작년에 우리가 찾았다. 매뉴얼 테스트에서 5번 중 1번은 실수가 있었다. 체크리스트 항목을 건너뛰거나 결과를 잘못 기록하거나.

자동화는 그런 실수가 없다. 짠 대로 돌아간다.

빠른 피드백 개발자가 코드를 푸시한다. 5분 뒤 Jenkins가 자동화 테스트를 돌린다. 10분 뒤 결과가 슬랙으로 온다.

깨진 부분이 있으면 바로 안다. 개발자가 지금 뭐 하는지 기억하는 시점에.

매뉴얼로 하면? 다음날 아침에 QA가 출근해서 테스트한다. 개발자는 이미 다른 작업 중이다. 컨텍스트 스위칭 비용이 크다.

반복 작업에서 해방 QA의 가장 큰 스트레스. 똑같은 테스트를 100번 하는 거.

로그인 테스트. 기능이 안 바뀌었는데 매번 해야 한다. 1년 동안 200번 했다.

자동화하면? 스크립트가 한다. 나는 새로운 걸 테스트한다.

우리 팀 후배가 말했다. “자동화 배우고 나서 일이 재미있어졌어요. 반복 작업이 줄어서요.”

이게 자동화의 진짜 가치다. 모든 버그를 잡는 게 아니라, 알고 있는 버그를 효율적으로 체크하는 거다.

경영진 설득법

구체적으로 어떻게 설득하나?

1. 숫자로 말한다

경영진은 숫자를 좋아한다. 추상적 설명 싫어한다.

잘못된 설명: “자동화는 한계가 있어요.” 올바른 설명: “자동화로 회귀 테스트 200개 케이스를 체크합니다. 하지만 가능한 유저 시나리오는 10,000개 이상이에요.”

잘못된 설명: “매뉴얼 테스트도 필요해요.” 올바른 설명: “작년에 프로덕션 버그 30개 중 18개를 매뉴얼 QA가 찾았어요. 자동화는 12개였고요.”

내가 만든 대시보드가 있다.

• 자동화 테스트 커버리지: 코드 라인 80%
• 매뉴얼 테스트 커버리지: 유저 시나리오 45%
• 버그 발견율: 자동화 40%, 매뉴얼 40%, 프로덕션 20%

마지막 20%가 중요하다. “자동화해도 20%는 프로덕션에서 나옵니다.”

2. 비용으로 환산한다

“자동화 더 늘리면 버그가 줄어들까요?”

아니다. 수익률이 떨어진다.

현재 자동화 커버리지 80%. 여기서 90%로 올리려면?

• 추가 인력 1명 필요
• 3개월 소요
• 연간 유지보수 시간 2배

그래서 얻는 건? 버그 발견율 5% 상승 예상.

비용 대비 효과가 안 맞는다.

차라리 그 시간에 매뉴얼 QA를 더 하는 게 낫다.

이렇게 설명하면 경영진이 이해한다. 자동화가 만능이 아니라는 걸.

3. 사례를 든다

추상적 설명은 안 먹힌다. 구체적 사례가 필요하다.

“지난달 결제 버그 기억하세요? 자동화 테스트는 통과했어요. 왜냐면 ‘결제 성공’ 시나리오만 있었거든요. 근데 실제 버그는 ‘결제 중 네트워크 끊김’이었어요. 이건 매뉴얼 QA가 찾았습니다.”

“작년 UI 개편 때요. 자동화는 100% 통과했어요. 근데 유저 불만이 쏟아졌죠. 버튼이 너무 작아서요. 자동화는 ‘버튼이 클릭 가능한가?‘만 체크했거든요.”

사례가 3개 이상 쌓이면 패턴이 보인다. 경영진이 납득한다.

4. 대안을 제시한다

문제만 지적하면 안 된다. 해결책도 줘야 한다.

“자동화 커버리지를 더 올리는 대신, 리스크 기반 테스트를 강화하겠습니다.”

• 핵심 기능: 자동화 + 매뉴얼 둘 다
• 일반 기능: 자동화만
• 레거시 기능: 샘플링 테스트

“탐색적 테스트 시간을 주 4시간으로 정례화하겠습니다.”

• QA 전원이 동시에 신규 기능을 막 써보는 시간
• 발견된 버그는 즉시 자동화 스크립트에 추가

“테스트 피라미드를 재정비하겠습니다.”

• 단위 테스트: 70% (개발자 담당)
• 통합 테스트: 20% (QA 자동화)
• E2E 테스트: 10% (QA 매뉴얼)

대안이 있으면 경영진이 결정하기 쉽다.

개발팀 설득법

개발자들은 다르게 접근한다.

1. 코드로 보여준다

개발자는 말보다 코드를 믿는다.

Flaky 테스트 문제가 있었다. 간헐적으로 실패하는 테스트. 개발팀이 물었다. “테스트 문제 아니에요?”

맞다. 테스트 코드 문제였다.

# 문제 있는 코드
element = driver.find_element(By.ID, "submit")
element.click()

# 개선한 코드
wait = WebDriverWait(driver, 10)
element = wait.until(
    EC.element_to_be_clickable((By.ID, "submit"))
)
element.click()

코드를 보여주니까 이해했다. “아, 로딩 타이밍 문제였네요.”

테스트 코드도 코드다. 버그가 있다. 리팩토링이 필요하다. 개발자들은 이걸 이해한다.

2. 테스트 피라미드를 그린다

개발자들은 아키텍처를 좋아한다. 추상적 구조를 좋아한다.

화이트보드에 피라미드를 그렸다.

     /\      E2E (느림, 비쌈, 10개)
    /  \     
   /    \    Integration (중간, 50개)
  /      \   
 /________\  Unit (빠름, 쌈, 500개)

“E2E로 모든 걸 테스트하면 너무 느려요. 빌드 시간이 1시간 넘어요.”

개발자들이 고개를 끄덕였다. “맞아요. CI 너무 느려지면 안 되죠.”

“그래서 단위 테스트를 개발자가 더 짜주시면, QA는 통합 테스트에 집중할게요.”

이렇게 제안하니까 협력이 됐다.

3. 버그 우선순위를 함께 정한다

개발자와 QA가 싸우는 이유. 우선순위가 다르니까.

개발자: “이건 엣지 케이스예요. 무시해도 돼요.” QA: “아니요. 치명적 버그예요.”

이제는 함께 정한다. 매주 수요일 30분.

버그 티켓을 놓고 투표한다.

• Critical: 프로덕션 즉시 롤백 필요
• High: 다음 배포 전 수정 필요
• Medium: 다다음 배포
• Low: 백로그

의견이 다르면 토론한다. 데이터를 본다. 이 버그가 몇 명한테 영향을 주나? 얼마나 자주 발생하나?

개발자들이 납득하면 수정을 빨리 한다. 우선순위 싸움이 없으니까.

4. 자동화 한계를 함께 인정한다

개발자도 안다. 테스트가 완벽할 수 없다는 걸.

“이번 버그는 제 자동화 테스트가 못 잡았어요. 다음부터는 이 케이스도 추가하겠습니다.”

솔직하게 인정하니까 개발자도 솔직해졌다.

“저도 단위 테스트를 더 꼼꼼히 짤게요. 이 함수는 테스트 커버리지가 낮았어요.”

서로의 한계를 인정하면 협력이 된다. 책임 전가가 아니라 함께 개선한다.

내가 배운 것들

4년 동안 자동화하면서 깨달은 것들.

자동화는 도구다. 목표가 아니다.

초반에 나는 자동화 커버리지에 집착했다. 80%, 90%, 95%…

근데 중요한 건 버그를 줄이는 거다. 커버리지 숫자가 아니라.

지금은 전략적으로 접근한다. 뭘 자동화하고 뭘 매뉴얼로 하나?

• 자주 바뀌는 UI: 매뉴얼
• 핵심 API: 자동화
• 복잡한 비즈니스 로직: 둘 다

완벽한 테스트는 없다

처음엔 모든 버그를 잡으려고 했다. 불가능하다는 걸 배웠다.

QA의 목표는 버그 제로가 아니다. 리스크 관리다.

치명적 버그는 출시 전에 잡는다. 사소한 버그는 우선순위를 낮춘다. 자원이 한정돼 있으니까.

설득은 데이터로 한다

“자동화가 필요해요”보다 “자동화로 회귀 테스트 시간을 3일에서 3시간으로 줄였어요”가 낫다.

“매뉴얼 QA도 필요해요”보다 “작년 프로덕션 버그의 60%를 매뉴얼 QA가 찾았어요”가 낫다.

숫자가 없으면 의견이다. 숫자가 있으면 사실이다.

QA는 품질 파수꾼이 아니라 품질 조력자다

예전엔 내가 게이트키퍼라고 생각했다. “이 버그 있으면 출시 안 돼요.”

지금은 조력자라고 생각한다. “이 리스크가 있어요. 함께 결정해요.”

품질은 QA 혼자 만드는 게 아니다. 개발자, 기획자, 디자이너 모두의 책임이다.

QA는 그걸 보이게 만드는 사람이다.

마무리: 억울하지 않으려면

“자동화했는데 왜 버그 나와?”

이제 이 질문이 안 억울하다. 예상된 질문이니까.

대답이 준비돼 있다.

“자동화는 알려진 시나리오를 체크합니다. 이번 버그는 새로운 패턴이었어요. 지금 이 케이스를 자동화 스크립트에 추가했습니다.”

데이터를 보여준다.

• 이번 스프린트 자동화 테스트: 1,234개 통과, 3개 실패
• 매뉴얼 테스트: 신규 기능 45개 체크, 버그 7개 발견
• 프로덕션 버그: 2개 (하나는 인프라, 하나는 엣지 케이스)

“자동화 커버리지 80%는 코드 라인 기준입니다. 유저 시나리오 기준으로는 약 40%예요. 나머지는 매뉴얼과 프로덕션 모니터링으로 커버합니다.”

명확하게 설명하면 이해한다. 경영진도, 개발자도.

억울할 필요 없다. 자동화의 가치와 한계를 모두 보여주면 된다.

QA 자동화 엔지니어의 일은 모든 버그를 막는 게 아니다. 효율적으로 품질을 관리하는 거다.

그걸 설득하는 것도 내 일이다.

---

오늘도 자동화 스크립트 3개 추가했다. 지난주 놓친 케이스들. 완벽하진 않지만, 조금씩 나아진다.