토스 QA 글 읽으면서 든 생각 | 가설이 틀렸을 때

토스 테크 블로그에 최근 올라온 글을 읽었다. 제목이 “누군가는 토스를 테스트하는 동안, 우리는 테스트하는 법을 만듭니다.”인데, QA Platform 팀이 자체 QA 시스템을 만들어온 과정을 담아냈다.

처음 제목만 보고는 QA 엔지니어 얘기라 나랑 거리가 있겠다 싶었다. 근데 읽다 보니 중간에 나오는 한 대목에서 생각이 좀 멈췄다.

---

1️⃣ 이게 뭐냐?

토스는 매주 굉장히 많은 코드 변경이 올라오는 환경이라고 한다. 빠른 배포 속도를 유지하면서 품질도 함께 챙겨야 하는 상황인데, QA Platform 팀은 TestRail 같은 상용 도구 대신 아예 자체 플랫폼을 만들기로 했다.

그 결과물이 Tossion이라는 내부 QA 플랫폼이라고 한다. 테스트 케이스 작성부터 실행, 결과 기록까지 하나의 흐름으로 처리할 수 있도록 통합해둔 도구다. 여기에 PR 분석기라는 기능도 붙었는데, 코드 변경사항을 보고 버그 위험도와 테스트 우선순위를 자동으로 제안해준다. 문서를 기반으로 테스트 케이스를 자동 생성하는 tcgen도 있다.

배포 속도가 빠른 환경에서는 핫픽스 판단 — 지금 당장 고칠지, 다음 배포를 기다릴지 — 같은 결정도 반복적으로 생긴다. 이런 판단을 돕는 크래시 트렌드 대시보드도 만들었다고 한다.

겉으로 보면 꽤 정교하게 짜인 자동화 시스템처럼 보였다. 근데 이게 이 글에서 제일 중요한 부분은 아닌 것 같았다.

2️⃣ 내가 든 생각

글에서 가장 눈에 들어온 건 가설이 틀렸다는 부분이었다.

팀이 처음 세운 가정은 이런 거였다 — “테스트 케이스를 쉽게 만들 수 있으면 사람들이 테스트를 더 하게 될 것이다.” 도구 접근성을 높이면 자연스럽게 사용량이 늘어날 거라는 기대. 근데 실제로는 그렇지 않았다고 한다. 사람들이 원한 건 쉬운 도구가 아니라, 누군가가 빠르고 정확하게 대신 처리해주는 거였다는 것.

이 지점이 흥미로웠다. 디자이너 입장에서 이런 가정의 실수가 꽤 익숙한 패턴이기 때문인 것 같다. “이 기능을 더 쉽게 만들면 쓸 거야”, “UI를 개선하면 전환율이 오를 거야” — 근데 실제 사용자가 원하는 게 그게 아닌 경우가 있다. 쉬움의 문제가 아니라, 그 일 자체가 필요한지 다시 물어야 하는 경우.

👉🏻 도구를 더 쉽게 만드는 것과, 그 일을 대신 해결해주는 것은 다른 층위의 문제인 것 같다.

💡 여기서 드는 질문? 그럼 “도구”를 만드는 게 맞는 상황과 “서비스”가 맞는 상황은 어떻게 구분할 수 있을까?

팀은 이 가설이 틀렸다는 걸 인식하고 방향을 바꿨다. 도구를 제공하는 방향에서, 직접 핸들링하는 서비스 방향으로. 심지어 만들어두던 API Labs라는 기능을 8시간 만에 폐기하기도 했다고 한다. 잘못된 방향이라는 판단이 서면 빠르게 버린다는 결정이 쉽지 않아 보여서, 그 부분이 꽤 인상적으로 남았다.

⭐️ 마지막으로, 공부하면서 느낀 점

정리해보니 이 글에서 남은 건 QA 도구 이야기가 아니라, 가설이 틀렸을 때 어떻게 행동하는가에 가까웠다.

“쉽게 만들면 쓸 것이다”라는 가정은 얼핏 합리적으로 들리지만, 실제 사용자가 원하는 게 그게 아닐 수 있다는 것. 이걸 도구를 다 만든 뒤에 알게 되는 것보다, 일찍 인식하고 방향을 바꾸는 게 결국 더 빠른 길인 경우가 있는 것 같다.

공부 끝에 남은 건 “좋은 가설을 세우는 것만큼, 가설이 틀렸을 때 얼마나 빨리 버릴 수 있는가”라는 한 줄이다.

---

참고 원문: 누군가는 토스를 테스트하는 동안, 우리는 테스트하는 법을 만듭니다.