<div id="readability-page-1" class="page"><div>안녕하세요. 토스인컴 QA Manager 정수호, FE Assistant 노치현입니다.QA 업무를 하다 보면 하루에도 몇 번씩 비슷한 질문을 받습니다.<blockquote id="2eea360d-33e3-80a3-8ac0-d2676779dffb">"이 테스트 데이터는 어떻게 만들어요?"
"이 API는 Swagger에서 어떻게 호출하나요?"
"이 상태를 바로 확인할 방법은 없을까요?"</blockquote>질문을 받을 때마다 저는 자연스럽게 Swagger를 열었어요. 필요한 API를 찾고, request body를 설명하며, "여기에는 이 값을 넣고, 이건 true로 바꿔야 해요"라고 말하곤 했죠.QA 팀에서는 익숙한 일이었습니다.하지만 같은 설명을 반복할수록 한 가지 생각이 들었습니다."이 테스트 API들, 왜 QA만 이렇게 어렵게 쓰고 있는 걸까?"<hr><h2 id="2eea360d-33e3-8032-bb1e-e2fb4451466b">Swagger에는 이미 모든 게 있었습니다</h2>사실 테스트에 필요한 API는 이미 모두 존재했습니다. Swagger 문서 안에, 꽤 잘 정리된 형태로요.
문제는 API의 유무가 아니라 경험이었습니다.QA Manager에게는 익숙하지만, 개발자나 기획자가 ‘지금 이 상태를 한 번만 확인해보고 싶을 때’ 선뜻 손을 대기에는 진입 장벽이 높았습니다. 그래서 QA 팀 안에서 이런 질문이 나왔습니다.<blockquote id="2eea360d-33e3-806f-9680-c6f2e79ddc3b">"Swagger에 흩어져 있는 Test API들을 한곳에 모아두면 어떨까?""그리고 그걸 버튼으로 만들면 어떨까?"</blockquote>이 질문에서 QA Platform이 시작됐습니다.<h2 id="2eea360d-33e3-800d-b3d0-d9033117b719">QA Platform은 '새로운 API'를 만들지 않습니다</h2>QA Platform은 새로운 테스트 API를 만들지 않습니다. 기존에 Swagger에 이미 존재하던 Test API들을 그대로 사용합니다.우리가 한 일은 단순합니다.즉, API를 더 추가한 것이 아니라 API를 사용하는 방식을 바꾼 것에 가깝습니다.이 도구는 QA 팀이 아이디어부터 설계, 개발까지 100% 직접 진행한 내부 플랫폼입니다. QA가 실제로 불편했던 지점에서 출발했고, QA가 매일 쓰는 기준으로 설계했습니다.<h2 id="2eea360d-33e3-80e7-bd77-f71ba6dcc3c8">Phase 1: Swagger Test API를 모두의 도구로</h2>(예시)<figure id="2eea360d-33e3-8073-9cf4-db6634bec866"><img src="https://static.toss.im/ipd-tcs/toss_core/live/c464cada-3bf1-4f09-bd42-a71750a910c7/%E1%84%86%E1%85%A9%E1%84%8F%E1%85%B5%E1%86%BC%E1%84%8F%E1%85%A6%E1%84%8B%E1%85%B5%E1%84%89%E1%85%B3_%E1%84%92%E1%85%A1%E1%86%AB%E1%84%87%E1%85%A1%E1%86%BC%E1%84%8C%E1%85%A5%E1%86%A8%E1%84%8B%E1%85%AD%E1%86%BC_(1).gif" alt=""></figure>Phase 1의 목표는 아주 명확했습니다.<blockquote id="2eea360d-33e3-8064-8c02-f61bd31e9097">“Swagger에 있는 Test API를
누구나, 설명 없이도 실행할 수 있게 만들자.”</blockquote>기존에는 테스트 데이터를 만들기 위해 Swagger를 열고, JSON을 작성하고, 여러 API를 순서대로 호출해야 했습니다. 작은 실수 하나로 다시 처음부터 해야 하는 일도 많았죠.QA Platform에서는 이 과정을 이렇게 바꿨습니다.Swagger 문서를 열 필요도 없고, JSON을 직접 작성할 필요도 없습니다. 
“이 버튼을 누르면 어떤 테스트가 되는지”가 UI만 봐도 바로 보이게 만들었습니다.<h3 id="2eea360d-33e3-80e9-a328-d8fad8b48fac">Normal 모드와 Swagger 모드</h3>모든 사용자가 같은 수준의 제어를 원하지는 않습니다. 그래서 QA Platform은 두 가지 입력 방식을 제공합니다.덕분에 QA 외 구성원은 부담 없이 테스트를 실행할 수 있고, QA 매니저와 엔지니어는 필요한 만큼 깊게 제어할 수 있습니다.<h3 id="2eea360d-33e3-80c2-b20a-cd321bbbe5cf">작은 UX가 만든 큰 차이</h3>(예시)<figure id="2eea360d-33e3-806e-8100-cb25d5e90233"><iframe src="https://www.youtube.com/embed/ed4aFdHOUCU" frameborder="0" allowfullscreen="" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"></iframe></figure>QA Platform은 테스트 도구지만,
우리는 ‘매일 쓰는 화면’이라는 점을 많이 의식했습니다.아주 사소해 보이는 기능들이지만, 반복 작업에서 체감되는 시간은 꽤 달라졌습니다.
무엇보다 “이거 한 번 눌러볼까?”라는 마음의 장벽이 눈에 띄게 낮아졌죠.<h2 id="2eea360d-33e3-802a-a949-dc611882b323">Phase 2: 자동화도 버튼으로</h2><figure id="2eea360d-33e3-806f-9199-dac7b14e5fa8"><iframe src="https://www.youtube.com/embed/vtuKkzcaRyc" frameborder="0" allowfullscreen="" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"></iframe></figure>Phase 1이 "Test API를 누구나 실행할 수 있게 만드는 것"이었다면,
Phase 2는
"이미 만들어진 자동화도 누구나 실행할 수 있게 만드는 것"입니다.지금도 자동화 스크립트는 존재합니다. 다만 실행은 QA 팀 중심으로 이루어지고 있고, 환경 설정과 사용 방법에는 여전히 장벽이 있습니다. Phase 2에서는 이 자동화 자산을 QA Platform 안에 녹였습니다.Test API를 누르듯, 누구든 자동화를 실행할 수 있게 되었습니다.<h2 id="2eea360d-33e3-802b-b204-c86ed934a7fa">Phase 3: 테스트 관리까지 하나로</h2>(예시)<figure id="2eea360d-33e3-8056-8ee7-fead0a7286fc"><img src="https://static.toss.im/ipd-tcs/toss_core/live/8c111ec3-53fb-4198-8a0b-fee48c8962f4/%E1%84%90%E1%85%A6%E1%84%89%E1%85%B3%E1%84%90%E1%85%B3%E1%84%80%E1%85%AA%E1%86%AB%E1%84%85%E1%85%B5%E1%84%89%E1%85%B5%E1%84%89%E1%85%B3%E1%84%90%E1%85%A6%E1%86%B7_(1).gif" alt=""></figure>최종적으로 QA Platform이 향하는 곳은 테스트의 전 과정을 한곳에서 관리하는 구조입니다.외부 도구에 의존하기보다, 우리 조직의 테스트 방식에 맞는 통합된 테스트 관리 시스템을 3월 초까지 만들고자 합니다.<h2 id="2eea360d-33e3-8020-8a0e-c8349ed0774a">마치며 — 테스트가 바뀌자, 속도가 바뀌었다</h2>테스트가 어려울 때, 제품은 자연스럽게 느려집니다.누가 테스트를 할 수 있는지가 제한되고,
테스트를 한 번 돌리기까지 여러 단계를 거쳐야 하고,
“이거 지금 바로 확인해볼 수 있을까?”라는 질문 앞에서
쉽게 “네”라고 답하지 못하게 됩니다.그 순간부터 팀은 확신 대신 추측으로 움직이기 시작합니다.검증 대신 대기 시간이 늘어나고, 속도는 점점 줄어듭니다.우리가 QA Platform을 만들면서 가장 크게 체감한 변화는 어떤 기능이 추가되었기 때문이 아니라,
테스트가 쉬워졌다는 사실 그 자체였습니다.Swagger 문서를 열지 않아도 되고, 어떤 API를 써야 하는지 외울 필요도 없고,
JSON을 직접 작성하지 않아도 되고, 여러 API를 순서대로 호출할 필요도 없어졌습니다.버튼 하나로 테스트를 실행할 수 있게 되자, 사람들은 테스트를 더 자주 하기 시작했습니다.테스트가 더 이상 “시간을 내서 해야 하는 특별한 작업”이 아니라,
생각이 떠오르면 바로 할 수 있는 일상적인 행동이 되었기 때문입니다.그리고 그 순간부터, 제품의 속도도 함께 달라지기 시작했습니다.확인하고 나서 움직이던 팀이, 확인하면서 움직이는 팀이 되었고,
테스트는 발목을 잡는 절차가 아니라 다음 선택을 빠르게 만들어주는 도구가 되었습니다.테스트가 쉬워진 순간, 제품은 더 빨라졌습니다.<h2 id="2eea360d-33e3-80a6-9536-cf623b59e752">품질을 대하는 우리의 관점</h2>우리는 오랫동안 품질을 ‘마지막에 확인하는 것’으로 다뤄왔습니다.
기능이 만들어지고, 흐름이 완성된 뒤, 문제가 없는지 점검하는 역할 말이죠.QA Platform을 만들면서 이 관점은 조금씩 바뀌기 시작했습니다.
테스트 API를 QA만이 아니라 누구나 실행할 수 있게 되자, 개발자는 기능을 만들자마자 직접 검증할 수 있었고,
QA는 반복적인 세팅 작업에서 벗어나 더 중요한 흐름과 리스크에 집중할 수 있었습니다.품질은 더 이상 ‘마지막 단계의 체크리스트’가 아니었습니다.
처음부터 흐름 안에 자연스럽게 녹아 있는 요소가 되었고, 의사결정의 속도를 높이는 근거가 되었습니다.QA Platform을 통해 만들고자 했던 것은 테스트를 대신 수행해주는 도구가 아닙니다. QA의 일을 자동으로 처리해주는 기계도 아닙니다.
우리가 만든 것은 품질을 자연스럽게 설계할 수 있는 환경이었습니다.누가 하느냐가 아니라, 누구나 할 수 있도록 만드는 구조였습니다.
그래서 우리는 이렇게 말할 수 있게 되었습니다.
품질은 확인하는 것이 아니라, 설계하는 것입니다.QA Platform은 QA 팀이 직접 느낀 불편함에서 출발해, QA팀이 직접 기획하고, 설계하고, 개발한 도구입니다.하지만 이 플랫폼이 향하는 곳은 QA만을 위한 영역이 아닙니다.
테스트를 특정 역할의 책임으로 두지 않고, 팀 전체의 일상적인 행동으로 만드는 것.
그로 인해 더 빠르게 실험하고, 더 확신 있게 전진하는 팀이 되는 것.그것이 우리가 QA Platform을 만들며 끝까지 놓지 않았던 방향이었습니다.QA Platform을 만들면서 스스로에 대해 하나 분명히 알게 된 게 있습니다.
저는 누군가의 시간을 줄여주고, 불편함을 없애주는 일을 할 때 가장 즐겁다는 점이었습니다.누군가가 “이거 설정하는 데 10분 걸렸는데, 이제 버튼 한 번이면 되네요”라고 말할 때
“이건 QA한테 물어볼 필요가 없어졌어요”라는 말을 들을 때
플랫폼에 새로운 버튼 하나, 자동화 하나가 추가될 때보다 그 반응들이 훨씬 더 기억에 남았습니다.QA Platform은 거창한 목표에서 시작된 프로젝트는 아니었습니다.그저 매일 반복되던 질문, 매번 설명해야 했던 API 호출, “이거 한 번만 확인하고 싶은데…”라는 말 앞에서 느꼈던 답답함에서 출발했죠. 그리고 그 불편함을 “이건 어쩔 수 없지”로 넘기지 않고 “없앨 수 있지 않을까?”라고 생각해본 결과물이 지금의 QA Platform입니다. 앞으로도 이 플랫폼은 기능이 더 많아질 수도 있고, 모양이 바뀔 수도 있고, 지금과는 전혀 다른 모습이 될 수도 있습니다.하지만 한 가지는 분명합니다.다른 사람의 시간을 아껴주고,
테스트 앞에서의 망설임을 줄여주는 방향으로만
계속 발전시킬 생각이라는 점입니다.QA Platform은 QA 팀이 만들고 있지만, QA만을 위한 도구는 아니라고 생각합니다.조금 더 편하게 확인할 수 있고, 조금 더 빨리 실험할 수 있고,
조금 더 자신 있게 다음 선택을 할 수 있다면
그 자체로 이 플랫폼의 역할은 충분하다고 믿습니다.앞으로도 저는 이 플랫폼을 통해 누군가의 하루를 조금이라도 가볍게 만드는 일에 계속 힘을 쓰려고 합니다.</div></div>

토스테크

안녕하세요. 토스인컴 QA Manager 정수호, FE Assistant 노치현입니다.
QA 업무를 하다 보면 하루에도 몇 번씩 비슷한 질문을 받습니다.
"이 테스트 데이터는 어떻게 만들어요?"
"이 API는 Swagger에서 어떻게 호출하나요?"
"이 상태를 바로 확인할 방법은 없을까요?"
질문을 받을 때마다 저는 자연스럽게 Swagger를 열었어요. 필요한 API를 찾고, request body를 설명하며, "여기에는 이 값을 넣고, 이건 true로 바꿔야 해요"라고 말하곤 했죠.
QA 팀에서는 익숙한 일이었습니다.
하지만 같은 설명을 반복할수록 한 가지 생각이 들었습니다.
"이 테스트 API들, 왜 QA만 이렇게 어렵게 쓰고 있는 걸까?"
Swagger에는 이미 모든 게 있었습니다
사실 테스트에 필요한 API는 이미 모두 존재했습니다. Swagger 문서 안에, 꽤 잘 정리된 형태로요.
문제는 API의 유무가 아니라 경험이었습니다.
어떤 API를 써야 하는지 알아야 하고
어떤 값을 넣어야 하는지 이해해야 하고
여러 API를 정해진 순서로 호출해야만 비로소 하나의 테스트 환경이 만들어졌습니다.
QA Manager에게는 익숙하지만, 개발자나 기획자가 ‘지금 이 상태를 한 번만 확인해보고 싶을 때’ 선뜻 손을 대기에는 진입 장벽이 높았습니다. 그래서 QA 팀 안에서 이런 질문이 나왔습니다.
"Swagger에 흩어져 있는 Test API들을 한곳에 모아두면 어떨까?""그리고 그걸 버튼으로 만들면 어떨까?"
이 질문에서 QA Platform이 시작됐습니다.
QA Platform은 '새로운 API'를 만들지 않습니다
QA Platform은 새로운 테스트 API를 만들지 않습니다. 기존에 Swagger에 이미 존재하던 Test API들을 그대로 사용합니다.
우리가 한 일은 단순합니다.
흩어져 있던 Test API를 한 화면에 모으고
어떤 값을 넣어야 하는지 UI로 드러내고
순서가 필요한 호출은 하나의 버튼으로 묶었습니다
즉, API를 더 추가한 것이 아니라 API를 사용하는 방식을 바꾼 것에 가깝습니다.
이 도구는 QA 팀이 아이디어부터 설계, 개발까지 100% 직접 진행한 내부 플랫폼입니다. QA가 실제로 불편했던 지점에서 출발했고, QA가 매일 쓰는 기준으로 설계했습니다.
Phase 1: Swagger Test API를 모두의 도구로
(예시)
Phase 1의 목표는 아주 명확했습니다.
“Swagger에 있는 Test API를
누구나, 설명 없이도 실행할 수 있게 만들자.”
기존에는 테스트 데이터를 만들기 위해 Swagger를 열고, JSON을 작성하고, 여러 API를 순서대로 호출해야 했습니다. 작은 실수 하나로 다시 처음부터 해야 하는 일도 많았죠.
QA Platform에서는 이 과정을 이렇게 바꿨습니다.
Test API를 기능별로 정리하고
꼭 필요한 입력만 폼 형태로 노출하고
버튼 클릭 한 번으로 실행합니다
Swagger 문서를 열 필요도 없고, JSON을 직접 작성할 필요도 없습니다. 
“이 버튼을 누르면 어떤 테스트가 되는지”가 UI만 봐도 바로 보이게 만들었습니다.
Normal 모드와 Swagger 모드
모든 사용자가 같은 수준의 제어를 원하지는 않습니다. 그래서 QA Platform은 두 가지 입력 방식을 제공합니다.
Normal 모드
UI 폼 기반 입력
Test API를 처음 쓰는 사람도 바로 실행 가능
Swagger 모드
JSON 직접 입력
복잡한 케이스나 기존 request 재사용 가능
덕분에 QA 외 구성원은 부담 없이 테스트를 실행할 수 있고, QA 매니저와 엔지니어는 필요한 만큼 깊게 제어할 수 있습니다.
작은 UX가 만든 큰 차이
(예시)
QA Platform은 테스트 도구지만,
우리는 ‘매일 쓰는 화면’이라는 점을 많이 의식했습니다.
자주 쓰는 섹션은 드래그해서 상단에 배치시킬 수 있고
최근에 사용한 userNo, userId가 저장되어 손쉽게 요청할 수 있고
화면 크기에 따라 레이아웃이 자연스럽게 바뀝니다.
아주 사소해 보이는 기능들이지만, 반복 작업에서 체감되는 시간은 꽤 달라졌습니다.
무엇보다 “이거 한 번 눌러볼까?”라는 마음의 장벽이 눈에 띄게 낮아졌죠.
Phase 2: 자동화도 버튼으로
Phase 1이 "Test API를 누구나 실행할 수 있게 만드는 것"이었다면,
Phase 2는
"이미 만들어진 자동화도 누구나 실행할 수 있게 만드는 것"입니다.
지금도 자동화 스크립트는 존재합니다. 다만 실행은 QA 팀 중심으로 이루어지고 있고, 환경 설정과 사용 방법에는 여전히 장벽이 있습니다. Phase 2에서는 이 자동화 자산을 QA Platform 안에 녹였습니다.
자동화 목록을 보고
필요한 파라미터만 입력한 뒤
버튼으로 실행하고
결과를 바로 확인하는 경험
Test API를 누르듯, 누구든 자동화를 실행할 수 있게 되었습니다.
Phase 3: 테스트 관리까지 하나로
(예시)
최종적으로 QA Platform이 향하는 곳은 테스트의 전 과정을 한곳에서 관리하는 구조입니다.
테스트 케이스 정의
실행 이력 관리
결과 추적
커버리지 파악
외부 도구에 의존하기보다, 우리 조직의 테스트 방식에 맞는 통합된 테스트 관리 시스템을 3월 초까지 만들고자 합니다.
마치며 — 테스트가 바뀌자, 속도가 바뀌었다
테스트가 어려울 때, 제품은 자연스럽게 느려집니다.
누가 테스트를 할 수 있는지가 제한되고,
테스트를 한 번 돌리기까지 여러 단계를 거쳐야 하고,
“이거 지금 바로 확인해볼 수 있을까?”라는 질문 앞에서
쉽게 “네”라고 답하지 못하게 됩니다.
그 순간부터 팀은 확신 대신 추측으로 움직이기 시작합니다.
검증 대신 대기 시간이 늘어나고, 속도는 점점 줄어듭니다.
우리가 QA Platform을 만들면서 가장 크게 체감한 변화는 어떤 기능이 추가되었기 때문이 아니라,
테스트가 쉬워졌다는 사실 그 자체였습니다.
Swagger 문서를 열지 않아도 되고, 어떤 API를 써야 하는지 외울 필요도 없고,
JSON을 직접 작성하지 않아도 되고, 여러 API를 순서대로 호출할 필요도 없어졌습니다.
버튼 하나로 테스트를 실행할 수 있게 되자, 사람들은 테스트를 더 자주 하기 시작했습니다.
테스트가 더 이상 “시간을 내서 해야 하는 특별한 작업”이 아니라,
생각이 떠오르면 바로 할 수 있는 일상적인 행동이 되었기 때문입니다.
그리고 그 순간부터, 제품의 속도도 함께 달라지기 시작했습니다.
확인하고 나서 움직이던 팀이, 확인하면서 움직이는 팀이 되었고,
테스트는 발목을 잡는 절차가 아니라 다음 선택을 빠르게 만들어주는 도구가 되었습니다.
테스트가 쉬워진 순간, 제품은 더 빨라졌습니다.
품질을 대하는 우리의 관점
우리는 오랫동안 품질을 ‘마지막에 확인하는 것’으로 다뤄왔습니다.
기능이 만들어지고, 흐름이 완성된 뒤, 문제가 없는지 점검하는 역할 말이죠.
QA Platform을 만들면서 이 관점은 조금씩 바뀌기 시작했습니다.
테스트 API를 QA만이 아니라 누구나 실행할 수 있게 되자, 개발자는 기능을 만들자마자 직접 검증할 수 있었고,
QA는 반복적인 세팅 작업에서 벗어나 더 중요한 흐름과 리스크에 집중할 수 있었습니다.
품질은 더 이상 ‘마지막 단계의 체크리스트’가 아니었습니다.
처음부터 흐름 안에 자연스럽게 녹아 있는 요소가 되었고, 의사결정의 속도를 높이는 근거가 되었습니다.
QA Platform을 통해 만들고자 했던 것은 테스트를 대신 수행해주는 도구가 아닙니다. QA의 일을 자동으로 처리해주는 기계도 아닙니다.
우리가 만든 것은 품질을 자연스럽게 설계할 수 있는 환경이었습니다.
누가 하느냐가 아니라, 누구나 할 수 있도록 만드는 구조였습니다.
그래서 우리는 이렇게 말할 수 있게 되었습니다.
품질은 확인하는 것이 아니라, 설계하는 것입니다.
QA Platform은 QA 팀이 직접 느낀 불편함에서 출발해, QA팀이 직접 기획하고, 설계하고, 개발한 도구입니다.
하지만 이 플랫폼이 향하는 곳은 QA만을 위한 영역이 아닙니다.
테스트를 특정 역할의 책임으로 두지 않고, 팀 전체의 일상적인 행동으로 만드는 것.
그로 인해 더 빠르게 실험하고, 더 확신 있게 전진하는 팀이 되는 것.
그것이 우리가 QA Platform을 만들며 끝까지 놓지 않았던 방향이었습니다.
QA Platform을 만들면서 스스로에 대해 하나 분명히 알게 된 게 있습니다.
저는 누군가의 시간을 줄여주고, 불편함을 없애주는 일을 할 때 가장 즐겁다는 점이었습니다.
누군가가 “이거 설정하는 데 10분 걸렸는데, 이제 버튼 한 번이면 되네요”라고 말할 때
“이건 QA한테 물어볼 필요가 없어졌어요”라는 말을 들을 때
플랫폼에 새로운 버튼 하나, 자동화 하나가 추가될 때보다 그 반응들이 훨씬 더 기억에 남았습니다.
QA Platform은 거창한 목표에서 시작된 프로젝트는 아니었습니다.
그저 매일 반복되던 질문, 매번 설명해야 했던 API 호출, “이거 한 번만 확인하고 싶은데…”라는 말 앞에서 느꼈던 답답함에서 출발했죠. 
그리고 그 불편함을 “이건 어쩔 수 없지”로 넘기지 않고 “없앨 수 있지 않을까?”라고 생각해본 결과물이 지금의 QA Platform입니다. 앞으로도 이 플랫폼은 기능이 더 많아질 수도 있고, 모양이 바뀔 수도 있고, 지금과는 전혀 다른 모습이 될 수도 있습니다.
하지만 한 가지는 분명합니다.
다른 사람의 시간을 아껴주고,
테스트 앞에서의 망설임을 줄여주는 방향으로만
계속 발전시킬 생각이라는 점입니다.
QA Platform은 QA 팀이 만들고 있지만, QA만을 위한 도구는 아니라고 생각합니다.
조금 더 편하게 확인할 수 있고, 조금 더 빨리 실험할 수 있고,
조금 더 자신 있게 다음 선택을 할 수 있다면
그 자체로 이 플랫폼의 역할은 충분하다고 믿습니다.
앞으로도 저는 이 플랫폼을 통해 누군가의 하루를 조금이라도 가볍게 만드는 일에 계속 힘을 쓰려고 합니다.

토스인컴 QA Platform: ‘누구나 테스트할 수 있는’ 도구의 시작

댓글