한 달 안에 새 서비스를 만들 때, QA는 일을 이렇게 나눴습니다

안녕하세요, 다들 잘 지내시나요? 날씨가 많이 추워졌네요 🌪️

저는 요즘 회사에서 새로운 도메인의 서비스를 처음부터 만드는 프로젝트에서 QA를 맡고 있습니다. 아직 끝나지는 않았지만 마무리가 보여서 지금까지 한 것을 정리해 둡니다.

킥오프 때 가장 큰 고민은 "이 많은 기능을 언제 다 테스트하지?"였습니다. 일을 주 단위로 쪼개고 전략을 세워 실행해 보니 일정 안에 들어왔어요. 이 글은 그 과정에서 사람이 다 봐야 했던 케이스를 자동화로 옮겨 사람 손을 줄여 보려 한 기록입니다.

---

한 달, 새로 만드는 도메인 기능

회사는 지금 외부 상담 챗봇 서비스(SaaS)를 쓰고 있습니다. 잘 쓰고 있긴 한데, 회사 데이터와 더 깊게 엮고 AI 기능도 우리 방식대로 키워 보고 싶다는 요구가 있었어요. 그래서 이 서비스를 직접 만들기로 했습니다. 주어진 시간은 한 달이었습니다. 공격적으로 가기로 했죠.

그런데 만들어야 할 게 꽤 많았습니다. 이 서비스를 매일 쓰는 분들은 고객을 응대하는 CS 담당자분들이거든요. 새로 만든 도구 때문에 그분들 일이 느려지면 안 됐습니다. 외부 서비스를 그대로 베끼자는 게 아니라, 적어도 지금만큼은 일할 수 있어야 한다는 기준이었어요. 그 기준을 맞추려다 보니 상담 화면부터 매크로, 태그, AI 봇, 고객이 보는 채팅 화면, 알림, 통계까지 요구사항이 줄줄이 붙었습니다.

여기서 걱정이 하나 생겼습니다. "이걸 다 만든 다음에 마지막에 한꺼번에 테스트하면 어떻게 되지?"

 

기존 서비스를 고치는 일이라면 주마다 조금씩 실제 사용자에게 내보내면서 확인할 수 있잖아요. 그런데 이번에는 서비스를 처음부터 새로 만드는 일이라, 기능은 주마다 나와도 실제로 내보내는 건 마지막 한 번뿐이었습니다. 마지막 주에 모든 기능의 문제와 수정이 한꺼번에 몰릴 게 뻔해 보였어요. 그 안에 어떤 변수가 숨어 있을지도 모르고요.

게다가 같은 기간에 저는 이 서비스가 내놓는 AI 답변의 품질을 따로 검증하는 일도 하고 있었습니다. 말 그대로 손이 모자랐어요.

그래서 목표를 하나로 정했습니다.

마지막에 몰릴 문제와 수정을 주마다 미리 나눠서 처리하고, 사람이 다시 봐야 하는 케이스는 자동화로 옮기자.

 

한 주를 셋으로 나눴습니다

그렇게 나온 게 일주일짜리 작은 사이클이었습니다. 기능이 개발된 다음 주에 QA가 세 가지를 같이 합니다.

개발	그다음 주에 QA가 하는 일
1주차 기능이 나온다	1주차 기능을 검증하고 그 기능의 자동화 코드를 쓰고, 2주차 기능의 테스트케이스와 요구사항을 준비한다
2주차 기능이 나온다	2주차 기능을 검증하고 1주차 기능은 자동화로 다시 확인하고, 3주차 기능을 준비한다
3주차 기능이 나온다	3주차 기능을 검증하고 1주차와 2주차 기능은 자동화로 다시 확인한다

 

 

이렇게 하면 기능이 나올 때마다 그다음 주에 바로 걸러집니다. 한 번 검증한 기능은 그 뒤로 자동화가 지켜보고요. 마지막 주에 볼 것이 "처음 보는 기능 전부"에서 "아직 자동화가 못 지키는 것"으로 줄어드는 거죠.

물론 "처음엔 사람이 확인하고, 그다음부터는 자동화로 다시 확인한다"는 새로운 이야기가 아닙니다. 많은 QA 팀이 이미 그렇게 하고 있을 거예요. 이번에 제가 다르게 한 건 사람이 하는 검증의 깊이를 일부러 얕게 잡았던 부분입니다.

 

사람은 기본 동작만 확인합니다

한 주 안에 검증도 하고 자동화 코드도 쓰고 다음 주 준비까지 하려면, 손으로 하는 테스트를 평소처럼 촘촘하게 할 수가 없었습니다.

첫 기능 묶음 중 상담 화면 기능의 테스트케이스를 요구사항대로 꼼꼼히 뽑아보니 53건이 나왔어요. 항목 하나하나, 경계값 하나하나를 다 나눴더니 그렇게 되더라고요. 이 규모로 매주 기능 서너 개씩을 쓰고 돌리는 건 불가능했습니다.

그래서 주마다 하는 검증은 기능이 기본적으로 동작하는지만 보기로 정했습니다. QA에서는 이런 가벼운 확인을 sanity 테스트라고 부르는데요, 이번에는 요구사항 한 줄에 정상 흐름 테스트케이스 한 건을 기준으로 삼았어요. 그렇게 53건이 25건이 됐습니다.

 

 

여기서 이런 질문이 나올 것 같아요. "그럼 빠진 케이스는 그냥 안 보는 건가요?"

아닙니다. 빼낸 경계값과 세부 동작은 버리지 않고 "배포 전 통합 테스트 후보" 목록에 따로 모았습니다. 배포 직전에 전체 기능을 한 번에 점검할 때 그 목록으로 테스트케이스를 만듭니다. 주중에 가볍게 확인한 기능도 그다음 주부터는 자동화가 더 자세한 흐름으로 매번 다시 돌려요.

정리하면 역할이 이렇게 나뉩니다.

누가	무엇을	언제
사람	새 기능이 기본적으로 동작하는지	기능이 나온 다음 주
자동화	앞 주차 기능이 여전히 잘 되는지, 자세한 흐름으로	그다음 주부터 매주
사람	미뤄 둔 경계값과 세부 동작, 기능끼리의 연결	배포 직전

 

---

다시 확인하는 일은 자동화가 맡습니다

이제 자동화 이야기입니다. 이 방식은 다음 주에 자동화 코드가 준비돼 있어야 돌아갑니다. 자동화가 늦으면 그 주의 재확인을 결국 사람이 해야 하니까, 셋으로 나눈 한 주가 다시 한 덩어리로 뭉쳐 버리거든요.

제가 가장 신경 쓴 건 두 가지였습니다. 다음 주 자동화가 막히지 않게 미리 깔아 두는 것, 그리고 제품 문제가 아닌 환경 문제로 테스트가 깨지는 일을 줄이는 것이요

 

AI는 화면을 보고, 저는 구조를 정했습니다

솔직히 고백하자면 저는 자동화 코드를 능숙하게 짜는 사람은 아닙니다. 그래서 역할을 이렇게 나눴어요.

AI (Claude Code)	저
화면을 읽고 버튼이나 입력창 같은 요소를 찾는다	무엇을 자동화할지, 어떤 결과가 나와야 하는지 정한다
테스트 코드를 쓴다	테스트를 어떤 단위로 나눌지 정한다
테스트를 돌리고 실패 원인을 분류해 온다	어떤 사용자가 어떤 상태로 필요한지 정리하고 만들어 둔다

 

코드는 AI가 썼고 저는 그 코드가 무엇을 확인해야 하는지, 무엇을 딛고 서 있어야 하는지를 정했습니다. 아래 이야기는 대부분 뒤쪽이에요.

테스트케이스 한 줄이 테스트 하나가 되도록

처음에는 시간이 없어서 긴 시나리오 두 개부터 만들었습니다. 고객이 문의하고 상담원이 받아서 답하고 상담을 끝내기까지 14단계짜리 하나, AI 봇이 먼저 답하고 사람에게 넘기는 7단계짜리 하나였어요.

다만 시나리오라고 해서 처음부터 끝까지 한 덩어리로 만들지는 않았습니다. 시나리오의 단계 하나하나가 테스트케이스 엑셀의 한 줄입니다. 그래서 엑셀 한 줄마다 그 줄의 동작과 확인만 담은 코드를 하나씩 따로 만들었어요. 예를 들어 "고객 문의가 수신함에 뜬다"라는 줄이면, 문의를 보내고 수신함에 떴는지 확인하는 코드 하나입니다. 이 글에서는 이걸 케이스 코드라고 부를게요. 시나리오는 케이스 코드를 순서대로 부르기만 합니다.

 

이렇게 나눠 둔 게 나중에 쓸모가 있었습니다. 시나리오 두 개만으로는 다시 확인되는 테스트케이스가 생각보다 적었거든요. 그래서 범위를 넓히기로 했는데, 이미 한 줄 단위로 쪼개 둔 덕분에 새로 설계할 것 없이 같은 방식으로 22건을 더 붙일 수 있었습니다. 엑셀 한 줄이 테스트 하나라서 결과도 엑셀과 그대로 맞고요.

코드 전체로 보면 이렇게 네 층으로 나뉩니다.

 

화면을 다루는 코드는 pages/ 층에 따로 모아 두었습니다. 화면마다 버튼과 입력창을 찾는 법, 그 화면에서 하는 조작을 한 파일에 담는 방식인데요, 보통 POM(Page Object Model)이라고 부릅니다. 개발 중인 서비스라 화면은 언제든 바뀔 수 있는데요 실제로 AI 봇의 안내 화면이 바뀌었을 때도 그 화면의 파일 하나만 고치면 됐었습니다. 테스트와 케이스 코드는 손댈 필요도 없었습니다. 👍

어떤 고객으로 테스트할지는 케이스가 정합니다

고객 문의를 받는 서비스다 보니 누가 문의하느냐가 테스트마다 달랐습니다. 저는 이걸 테스트케이스의 문의 내용으로 정리했어요.

 

예를 들어 "수강기간은 어디서 확인하나요?" 같은 질문은 비회원으로 충분합니다. 반대로 상담원 화면에 고객 이메일과 휴대폰 번호가 제대로 뜨는지 보려면 회원이어야 하죠. 이걸 코드보다 먼저 케이스 기준으로 정해 두니, AI가 코드를 쓸 때도 "이 케이스는 새 회원"처럼 고르기만 하면 됐습니다.

자주 쓰는 준비물은 미리 깔아 뒀습니다

상담 기능은 확인 하나를 하려 해도 준비할 게 많습니다. 상담원 화면에 뜨는 고객 정보를 보려면 먼저 회원을 만들어 로그인하고, 고객 화면에서 문의를 보내고, AI 봇이 상담원에게 넘겨줄 때까지 기다려야 해요. AI가 되물으면 한 번 더 보내야 하고요. 손으로 하면 확인보다 이 준비에 시간이 더 들었습니다.

제가 쓴 자동화 도구(Playwright)에는 픽스처라는 기능이 있습니다. 테스트가 "나는 새 회원이 필요해"라고 이름으로 요청하면, 그 테스트에만 준비해 주고 끝나면 치워 주는 장치예요.
자동화를 시작한 첫 주에 자주 쓰는 준비물을 미리 이렇게 만들어 두었습니다.

이제는 테스트가 "새 회원이 필요해"라고 이름만 부르면 이 준비가 저절로 끝납니다. 회원을 만들고 상담을 상담원에게 넘기는 준비부터 끝난 뒤 정리까지 포함해서, 테스트 한 건이 21초에서 40초 사이에 끝나요.

이 준비물 덕분에 다음 주 자동화도 빨라졌습니다. 22건을 더 붙일 때 고객과 상담원 준비는 이미 있던 것을 그대로 썼거든요. 새 테스트를 추가할 때 고민할 건 "이 케이스가 무엇을 확인하나"뿐이었습니다.

환경 때문에 깨지지 않게

자동화를 돌리다 보면 제품에는 문제가 없는데 실패하는 경우가 꽤 있잖아요. 로그인이 풀렸다거나, 다른 사람이 만든 데이터가 섞였다거나요. 이런 실패가 쌓이면 빨간불이 뜰 때마다 "이거 진짜 문제야?"를 사람이 다시 확인해야 합니다. 그러면 한 주를 셋으로 나눈 의미가 없어집니다.

그래서 환경 때문에 생길 만한 실패를 미리 막아 두었습니다.

걱정한 것	미리 해 둔 것
개발 서버에 테스트에 맞는 데이터가 없고, 있는 데이터도 다른 사람이 언제든 고칠 수 있다	테스트가 필요한 회원, 매크로, 상담을 직접 만들고 끝나면 지운다
같은 서버를 다른 사람들도 함께 쓴다	테스트용 매크로는 나만 보이게 만든다. 회원 탈퇴는 테스트 전용 이메일로 시작하는 계정만 하도록 막았다
상담원 로그인이 테스트 도중에 풀린다	로그인이 30분 안에 풀릴 예정이면, 테스트를 시작하기 전에 멈추고 다시 로그인하라고 알린다
상담이 누구에게 배정될지가 그날 접속한 상담원에 따라 바뀐다	돌리기 전에 확인할 목록을 두었다. 접속한 상담원은 한 명이어야 하고 그 상담원이 더 받을 수 있는 상담 수에 여유가 있어야 한다
AI 봇이 매번 다르게 답한다	상담원을 연결해 달라고 했는데 AI가 되물으면 같은 요청을 다시 보낸다. AI는 최대 세 번까지만 되묻게 되어 있다
여러 테스트가 같은 상담원 계정을 함께 쓴다	한 번에 하나씩 돌린다. 실패해도 자동으로 다시 돌리지 않는다. 다시 돌려서 통과하면 한 번 실패했다는 사실이 가려지기 때문

---

지금까지 돌아간 것과 남은 것

아직 프로젝트 중간이라 "그래서 마지막에 문제가 얼마나 줄었나"는 말씀드릴 수가 없습니다. 대신 사람이 다시 봐야 하는 일이 얼마나 줄었는지는 말씀드릴 수 있어요.

첫 기능 묶음이 나온 다음 주에 그 기능의 테스트케이스 86건을 기본 동작 위주로 돌려서 80건이 통과했습니다. 같은 주에 그 기능의 자동화 코드를 썼고 다음 기능 묶음의 테스트케이스도 준비했어요. 그다음 주부터는 그 기능을 자동화가 다시 확인하기 시작했습니다.

지금은 첫 주차 케이스의 60% 정도를 자동화로 옮겼습니다. 이 케이스들은 사람이 다시 손으로 돌리지 않고, 자동화가 실패라고 알린 것만 사람이 다시 봅니다. 추가로 붙인 22건을 한 번 돌리는 데 11분쯤 걸리는데, 회원을 만들고 상담을 상담원에게 넘기는 준비까지 포함한 시간이에요. 자동화 코드 변환이 100%는 아닙니다. 남은 케이스는 무엇이 막고 있는지로 나눠 두었어요.

 

이 밖에 상담원이 서너 명 필요하거나 사람이 직접 판단해야 하는 케이스는 자동화하기 어려워서 따로 보류해 뒀어요.
다 하려고 하지는 않았습니다. 지금 돌릴 수 있는 것부터 돌리고 나머지는 이유를 붙여 쌓아 두는 쪽을 택했어요.

 

배운 것

1. 막막한 일도 쪼개고 순서를 정하면 일정 안에 들어온다

킥오프 때는 기능 목록 전체가 한꺼번에 보여서 막막했습니다. 그래서 한 주를 셋으로 나눴습니다. 새 기능은 사람이 기본 동작만 봤습니다. 다시 확인하는 일은 자동화에, 경계값은 배포 전 통합 테스트에 맡겼어요.

실제로 첫 기능 묶음은 그다음 주에 사람이 86건을 확인해 80건이 통과했고 같은 주에 자동화 코드를 썼습니다. 그다음 주부터는 자동화가 22건을 11분 만에 다시 확인했어요. 이때 줄인 건 검증의 횟수가 아니라 한 번 검증할 때의 깊이였습니다. 횟수를 줄였다면 결국 마지막 주에 몰렸을 겁니다.

2. 모든 팀원이 AI를 쓰니 프로젝트 전체가 빨라졌다

이번 프로젝트에서는 팀원 모두가 AI를 활용해 일했습니다. 디자인은 처음부터 프로토타입으로 진행했고 백엔드는 초반에 그 프로토타입을 MVP 수준의 완성도로 만들어 줬어요. 덕분에 QA는 기능이 다 나오기 전부터 MVP를 보며 요구사항과 의도를 파악할 수 있었습니다.

테스트케이스와 자동화 구조를 미리 잡을 수 있었던 것도, 다음 주 자동화가 막히지 않은 것도 이 속도 덕이 컸습니다. QA인 저도 자동화 코드를 AI와 함께 썼고요.

 

3. QA는 결국 유저 관점으로 돌아와야 한다

이 서비스를 매일 쓸 CS 담당자분들과 직접 인터뷰하며 요구사항을 하나하나 확인했습니다. 그러면서 QA는 결국 유저 관점에서 다시 생각해야 한다는 걸 되새겼어요. 이 글에서는 다루지 못했고 따로 글로 정리하겠습니다.

 

 

아직 모르는 것

이 방식이 정말 마지막 몰림을 줄였는지는 배포가 끝나야 알 수 있습니다. 배포 전 통합 테스트에서 나온 문제 수와 배포 직전 수정량을 보고, 그 결과는 따로 정리해 보려고 해요. 자동화가 못 덮은 케이스도 아직 남아 있고요.

혹시 비슷하게 짧은 기간에 새 서비스를 통째로 검증해야 하는 상황이시라면, 손으로 하는 테스트를 줄이는 걸 너무 겁내지 않으셨으면 합니다. 대신 줄인 만큼을 어디로 넘길지는 꼭 정해 두시고요.

피드백은 언제나 감사합니다! 🙇‍♂️