<div id="readability-page-1" class="page"><div>매주 토스는 다시 태어납니다. 지난주의 토스와 이번 주의 토스는 같아 보여도 같지 않습니다. 누군가는 화면을 고치고, 누군가는 새 기능을 얹고, 누군가는 눈에 보이지 않는 코드 한 줄을 바꿉니다. 한 번 내보낼 때마다 평균 300~400건의 코드가 바뀝니다.우리에게는 늘 있는 변경이지만, 사용자에게는 그렇지 않습니다. 급한 송금을 보내야 할 때도, 대출을 빠르게 비교해야 할 때도, 결제가 급한 순간도 있습니다. 그저 평범한 하루일 수도 있습니다. 그 순간 버튼 하나가 눌리지 않으면, 사용자의 하루가 통째로 어긋납니다.토스에게 품질은 반드시 지켜야 하는 가치이며, 사용자와의 약속입니다.그래서 매주, 이 앱이 사용자 손에 닿기 전에 누군가는 멈춰 서서 묻습니다. "이거, 정말 내보내도 괜찮을까?"그 '누군가'가 바로 저희입니다. 안녕하세요. 토스 QA Platform 팀입니다. 올해 수많은 제품을 검증해 왔지만, 정작 우리 이야기를 글로 꺼내는 건 이번이 처음입니다. 앞으로 걸어온 이야기와, 아직 풀지 못한 숙제들을 하나씩 풀어보려 합니다.<h2 id="38aa360d-33e3-8091-a35e-f4376972ec30">매주, 토스를 내보내기 전에 </h2>우리 일은 토스 앱 릴리즈를 책임지는 데서 시작합니다. 토스는 매주 새로운 버전을 배포하며, 각 버전에는 수백 개의 변경 사항이 담겨 있습니다. 그 변화 속에서도 사용자에게 안전하게 닿도록 품질을 챙기는 것이 일의 출발입니다.한 주는 이렇게 흘러갑니다. 새 릴리즈 후보(Release Candidate)가 올라오면 먼저 토스닥터(Toss Doctor)로 스모크 테스트(Smoke Test)를 수행합니다. 로그인부터 탈퇴까지 핵심 기능이 제대로 도는지 빠르게 확인하고, 동시에 PR(Pull Request) 분석기가 짚어낸 변경 사항을 살피며 영향 범위를 중심으로 테스트합니다. 이후 토스체커(Toss Checker)로 리그레션 테스트(Regression Test)를 수행해, 이번 주 변경 사항이 기존에 안정적으로 동작하던 기능을 훼손하지 않았는지 서비스 전반을 점검합니다. 출시 뒤에도 끝이 아닙니다. 크래시(Crash) 지표를 지속적으로 모니터링하고, 문제가 발생하면 핫픽스(Hotfix)로 신속하게 대응할지, 다음 배포에서 더 안전하게 해결할지 판단합니다. 핫픽스는 사용자에게 또 한 번의 업데이트를 요구합니다. 그래서 우리는 ‘빨리’보다 ‘정말 지금 필요한가’를 먼저 묻습니다. 필요할 때는 즉시 대응하지만, 그렇지 않다면 더 안전한 해결 방법을 선택해야 합니다.&nbsp;같은 문제가 되풀이되지 않도록, 직접 만든 대시보드로 크래시와 핫픽스를 추적합니다.우리의 일은 릴리즈에만 머물지 않습니다. 품질이 필요한 곳이라면 어디든 갑니다. 이제 막 QA를 시작한 제품 팀에는 무엇부터 봐야 할지 길을 잡아 주고, 팀원들이 매일 쓰는 사내 도구의 품질을 보증하고, QA 프로세스를 세우고 싶은 팀에는 그 체계를 함께 설계합니다. 특정 팀이 아니라 토스 전체의 품질을 끌어올리는 것. 그것이 우리가 있는 이유입니다.그래서 목표는 하나입니다. 누구나 쉽게 테스트 케이스(Test Case)를 만들고, 빠르고 정확하게 테스트할 수 있어야 한다. 그것이 토스 앱의 품질을 지키는 방법이라고 봅니다.<h2 id="38aa360d-33e3-80eb-b466-c385ccf4dad5">단순한 테스트를 넘는다는 것 </h2>팀에는 슬로건이 하나 있습니다. "단순 테스트를 넘어, 토스 품질의 표준을 세운다." 
처음 들으면 광범위해서 잘 와닿지 않을 겁니다. 그런데 표준이란 게 왜 있어야 할까요?토스 팀은 매주 사용자에게 새 기능을 내놓습니다. 그때마다 품질을 판단하는 기준이 사람마다 다르면 안 됩니다. 누가 보든, 언제 보든, 같은 기준으로 걸러져야 합니다. 그래서 표준을 이렇게 정의했습니다.하나, 이번 주도 다음 주도 믿을 수 있게 배포하는 것(Reliable Releases, Every Time). 한 번 잘 배포하는 것은 누구나 할 수 있습니다. 어려운 것은 매주, 빠짐없이, 같은 수준의 신뢰를 사용자에게 전달하는 일입니다. 둘, 결함을 예리하게 짚어내는 것(Ensure Test Quality). 테스트는 많이 한다고 좋은 게 아닙니다. 진짜 사고가 될 결함을 정확히 골라내는 것이 실력입니다. 그래서 '무엇을 놓쳤나'에 집중합니다.셋, 그걸 효율적으로 해내는 것(Assuring Quality Efficiently). 같은 일을 사람이 손으로 반복하는 방식만으로는 매주 쏟아지는 변화를 따라갈 수 없습니다. 그래서 우리는 ‘잘하는 것’만큼 ‘지치지 않는 것’도 중요한 표준으로 생각합니다.이 셋을 매주 빠짐없이 지켜내는 것. 그것이 우리가 말하는 토스 품질의 표준입니다.그리고 올해, 여기서 한 발 더 나아가기로 했습니다. 테스트가 스스로 동작하는 범위를 넓혀가는 일입니다. 모든 걸 AI에 맡기겠다는 뜻은 아닙니다. 맡겨도 될 판단은 AI에 맡기고, 사람은 정말 사람이 봐야 할 곳에만 집중하기로 했습니다.<h2 id="38aa360d-33e3-808e-ab2e-d36890e3f7ea">우리만의 플레이그라운드 </h2>매주 테스트할 일은 늘어만 갔습니다. 사람 손으로 하나하나 따라가기엔 버거운 양이었습니다. 마침 그때 AI가 빠르게 발전했고, 그 AI를 테스트에 제대로 써 보고 싶었습니다.그런데 상용 도구만으로는 한계가 있었습니다. 우리의 업무를 도구가 정해 놓은 방식에 맞춰야 했고, 새로 나온 AI 기능도 필요할 때 바로 붙여 보고, 아니면 과감히 떼어낼 만큼 유연하게 활용하기 어려웠습니다. 토스의 배포 속도와 일하는 방식에 맞추려 할수록, 늘 어딘가 어긋났습니다.그래서 직접 만들었습니다. 우리만의 플랫폼, 토션(Tossion)입니다.토션은 QA Platform 팀의 정체성을 만들어가는 과정에서 시작됐습니다. QA인 우리가 더 효과적으로 일하고, 품질에 대한 이상을 온전히 구현하고 실험해볼 ‘우리만의 공간’이 있으면 좋겠다는 마음에서 출발했습니다.토션의 첫 모습은 TestRail을 대체하는 일이었습니다. 기존 상용 도구에 있던 테스트의 전 과정, 케이스 작성부터 실행과 결과 기록까지를 토션으로 온전히 이관했습니다. 그 과정에서 제각각 쓰이던 여러 봇도 토션에 최적화된 하나의 봇, 토스버틀러(Toss Butler)로 통합했습니다. 단순히 도구를 교체한 것이 아니라, 우리가 일하는 방식에 꼭 맞도록 새롭게 빚어낸 결과였습니다.옮겨오고 나니, 더 필요한 것들이 보이기 시작했습니다.<figure id="38aa360d-33e3-80ca-9bce-e0868eba2adc"><img src="https://static.toss.im/ipd-tcs/toss_core/live/cdbca218-52e9-436f-8b90-ddf5f82078fd/%E1%84%89%E1%85%B3%E1%84%8F%E1%85%B3%E1%84%85%E1%85%B5%E1%86%AB%E1%84%89%E1%85%A3%E1%86%BA_2026-06-25_%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE_3.37.15.png" alt=""></figure>가장 먼저, 매주 쏟아지는 PR을 전부 들여다볼 순 없으니 "여기를 집중해서 보라"고 짚어주는 PR 분석기(PRCheck)를 더했습니다. 개발자가 무엇을 왜 바꿨는지, 그 변경이 어디에 영향을 주고 무엇을 테스트해야 하는지를 버그 위험도와 테스트 우선순위까지 체계적으로 확인할 수 있게 했습니다.규모가 큰 변경이나 새 기능이 들어올 때마다, 테스트 케이스를 높은 완성도로 더 빠르게 작성해야 한다는 갈증도 커졌습니다. 그래서 PRD와 디자인 문서, 곳곳에 흩어진 맥락 정보를 모아 테스트 케이스를 자동으로 만들어 주는 tcgen을 추가했습니다. 처음부터 손으로 쓰는 대신, 탄탄한 초안을 빠르게 받아 검토에 집중할 수 있도록 말입니다.매뉴얼 테스트와 자동화 테스트의 결과를 한자리에서 보고 싶다는 바람으로, 자동화 테스트 플랫폼도 붙였습니다. 이제 같은 테스트 수행 페이지에서 두 결과를 나란히 확인할 수 있습니다.<figure id="38aa360d-33e3-8008-8873-c26228997b8d"><img src="https://static.toss.im/ipd-tcs/toss_core/live/5b22e3a7-cfeb-4e08-ac35-170cf051413d/%E1%84%83%E1%85%A6%E1%84%86%E1%85%A9_%E1%84%90%E1%85%B3%E1%84%85%E1%85%A6%E1%86%AB%E1%84%83%E1%85%B3.png" alt=""></figure>여기서 더 나아가, 발생하는 크래시를 단순한 건수가 아니라 토스에 맞는 지표와 추세로 읽어내기 위해 크래시 트렌드(Crash Trend) 대시보드를 만들었습니다. 핫픽스를 통제하기 위해 원인을 분류하고 '재발 방지' 대책을 남기는 데 초점을 둔 핫픽스 대시보드도 함께 마련했습니다.<figure id="38aa360d-33e3-80c8-99a2-f48e0adad9ea"><img src="https://static.toss.im/ipd-tcs/toss_core/live/2ede8d3c-eaeb-4414-940d-0cb463ad7ea3/%E1%84%83%E1%85%A6%E1%84%86%E1%85%A9-timeline.png" alt=""></figure>이렇게 적고 보니 생소한 도구가 참 많습니다. 그런데 이건 따로따로 만든 게 아닙니다. "매주 쏟아지는 변화를 효율적으로 풀어내 보자"는 하나의 의지에서 가지처럼 뻗어 나온 결과입니다.다만 오늘은 여기서 멈추려 합니다. 도구 하나하나가 저마다의 사연을 갖고 있어서, 앞으로 이 시리즈에서 하나씩 차근차근 소개하려고 합니다.<h2 id="38aa360d-33e3-80fb-858d-d3d7e4ac17b5">우리가 놓친 진짜 속마음</h2>이런 도구들을 만들면서, 한 가지 가설을 세웠습니다. 테스트 케이스를 빠르게 만들어 제공하면 사람들이 테스트를 훨씬 쉽게 하겠지, 테스트에 대한 허들이 낮아지겠지. 실제로 현장에서는 이런 이야기를 자주 들었습니다. “테스트 케이스를 좀 더 쉽게 작성할 방법은 없나요?” 자주 들리는 이야기였기에, 그 불편함만 덜어드리면 많은 분들이 반길 것이라고 생각했습니다.그래서 tcgen을 만들어 공개했습니다. 그런데 생각만큼 사람들은 관심을 가지지 않았습니다. 분명 필요하다는 목소리가 있었는데, 왜 안 쓸까?<figure id="38aa360d-33e3-8021-ae8f-f2ced63a7305"><img src="https://static.toss.im/ipd-tcs/toss_core/live/44af7e31-37e3-4c40-b9b4-41a5cd0deaf9/QA_voices_chat.png" alt=""></figure>한참을 고민한 뒤에야 알았습니다. 사람들이 속으로 바란 건 '테스트를 쉽게 하는 것'이 아니었습니다. 누군가 빠르고 정확하게 테스트를 대신 해 주고, 그 품질까지 책임져 주는 것. 그게 진짜 속마음이었습니다.도구를 쥐어주는 건, 결국 "이제 당신이 하세요"라는 말이었던 거죠. 우리는 짐을 덜어 준다고 생각했는데, 받는 쪽에서는 새 숙제였던 겁니다. 좋은 삽을 줬다고 해서, 사람들이 각자 구덩이를 파고 싶어 하는 건 아니었습니다.이 깨달음이 저희의 하반기 방향을 바꿨습니다.그래서 직접 핸들링하기로 했습니다. 사람이 매번 붙지 않아도 10X의 효율을 내고, 품질은 우리가 끝까지 책임지는 쪽으로. 어떻게 보면 더 험난한 길을 선택한 셈인데, 저희는 그게 맞다고 생각했습니다.<h2 id="38aa360d-33e3-8036-9d6d-c2b35df9868a">그럼에도 계속 고민이 되는 이유 </h2>AI로 많은 시도를 했고 많은 숙제를 풀었습니다. 그런데도 고민은 사라지지 않습니다.가설은 늘 반은 맞고 반은 틀립니다. 앞서 말한 tcgen이 그랬습니다. 게다가 AI는 따라잡기 버거울 만큼 빠르게 바뀝니다. 어제의 최선이 오늘은 낡은 방식이 되기도 합니다. 그 속도 안에서 QA가 익숙한 방식을 고집하는 순간, 품질을 지키기 위해 만든 도구가 오히려 변화의 속도를 늦추기 시작합니다.그래서 ‘만들었다’에 안주하지 않기로 했습니다. 한번은 API 테스트를 쉽게 하려고 API Labs를 만들었지만, 맞지 않는 방향임을 알고 8시간 만에 걷어냈습니다. 공들여 만든 것도 아니다 싶으면 버리고, 방향은 언제든 바로 틀 수 있어야 합니다.그래서 시스템도 그렇게 설계했습니다. 토션, 토스닥터와 토스체커, 직접 만든 스킬들은 완성된 결과물이 아닙니다. 더 나은 방법이 있다면 미련 없이 대체할 수 있도록, 처음부터 ‘언젠가 바뀔 것’을 전제로 만들었습니다.AI는 다양한 문제를 해결해주지만, '무엇이 품질인지', '무엇을 끝까지 지켜야 하는지'까지는 정해주지 않습니다. 도구는 AI가 더 빨리 만들어 줄 수 있어도, 그 도구가 계속 쓸모 있도록 방향을 잡고 기준을 다시 세우는 일은 여전히 우리의 몫입니다.
<h2 id="38aa360d-33e3-805b-8e94-f8cf65776e96">우리의 이야기를 시작합니다</h2>지금까지 저희가 누구이고, 무엇을 만들었고, 무엇을 시도하며 배워왔는지 짧게 풀었습니다. 이제 그 하나하나를 제대로 꺼내려 합니다.다음 주에도 토스는 어김없이 다시 태어납니다. 화면이 또 바뀌고, 수백 개의 변경이 또 쌓일 것입니다. 그 앞에서 이번 주처럼 또 멈춰 서서 묻겠습니다. "이거, 정말 내보내도 괜찮을까?"누군가는 토스를 테스트합니다. 그리고 저희는 그 테스트하는 법을 만듭니다.
</div></div>

토스테크

매주 토스는 다시 태어납니다. 지난주의 토스와 이번 주의 토스는 같아 보여도 같지 않습니다. 누군가는 화면을 고치고, 누군가는 새 기능을 얹고, 누군가는 눈에 보이지 않는 코드 한 줄을 바꿉니다. 한 번 내보낼 때마다 평균 300~400건의 코드가 바뀝니다.
우리에게는 늘 있는 변경이지만, 사용자에게는 그렇지 않습니다. 급한 송금을 보내야 할 때도, 대출을 빠르게 비교해야 할 때도, 결제가 급한 순간도 있습니다. 그저 평범한 하루일 수도 있습니다. 그 순간 버튼 하나가 눌리지 않으면, 사용자의 하루가 통째로 어긋납니다.
토스에게 품질은 반드시 지켜야 하는 가치이며, 사용자와의 약속입니다.
그래서 매주, 이 앱이 사용자 손에 닿기 전에 누군가는 멈춰 서서 묻습니다. "이거, 정말 내보내도 괜찮을까?"
그 '누군가'가 바로 저희입니다. 
안녕하세요. 토스 QA Platform 팀입니다. 올해 수많은 제품을 검증해 왔지만, 정작 우리 이야기를 글로 꺼내는 건 이번이 처음입니다. 앞으로 걸어온 이야기와, 아직 풀지 못한 숙제들을 하나씩 풀어보려 합니다.
매주, 토스를 내보내기 전에 
우리 일은 토스 앱 릴리즈를 책임지는 데서 시작합니다. 토스는 매주 새로운 버전을 배포하며, 각 버전에는 수백 개의 변경 사항이 담겨 있습니다. 그 변화 속에서도 사용자에게 안전하게 닿도록 품질을 챙기는 것이 일의 출발입니다.
한 주는 이렇게 흘러갑니다. 새 릴리즈 후보(Release Candidate)가 올라오면 먼저 토스닥터(Toss Doctor)로 스모크 테스트(Smoke Test)를 수행합니다. 로그인부터 탈퇴까지 핵심 기능이 제대로 도는지 빠르게 확인하고, 동시에 PR(Pull Request) 분석기가 짚어낸 변경 사항을 살피며 영향 범위를 중심으로 테스트합니다. 이후 토스체커(Toss Checker)로 리그레션 테스트(Regression Test)를 수행해, 이번 주 변경 사항이 기존에 안정적으로 동작하던 기능을 훼손하지 않았는지 서비스 전반을 점검합니다. 
출시 뒤에도 끝이 아닙니다. 크래시(Crash) 지표를 지속적으로 모니터링하고, 문제가 발생하면 핫픽스(Hotfix)로 신속하게 대응할지, 다음 배포에서 더 안전하게 해결할지 판단합니다. 핫픽스는 사용자에게 또 한 번의 업데이트를 요구합니다. 그래서 우리는 ‘빨리’보다 ‘정말 지금 필요한가’를 먼저 묻습니다. 필요할 때는 즉시 대응하지만, 그렇지 않다면 더 안전한 해결 방법을 선택해야 합니다. 같은 문제가 되풀이되지 않도록, 직접 만든 대시보드로 크래시와 핫픽스를 추적합니다.
우리의 일은 릴리즈에만 머물지 않습니다. 품질이 필요한 곳이라면 어디든 갑니다. 이제 막 QA를 시작한 제품 팀에는 무엇부터 봐야 할지 길을 잡아 주고, 팀원들이 매일 쓰는 사내 도구의 품질을 보증하고, QA 프로세스를 세우고 싶은 팀에는 그 체계를 함께 설계합니다. 특정 팀이 아니라 토스 전체의 품질을 끌어올리는 것. 그것이 우리가 있는 이유입니다.
그래서 목표는 하나입니다. 누구나 쉽게 테스트 케이스(Test Case)를 만들고, 빠르고 정확하게 테스트할 수 있어야 한다. 그것이 토스 앱의 품질을 지키는 방법이라고 봅니다.
단순한 테스트를 넘는다는 것 
팀에는 슬로건이 하나 있습니다. "단순 테스트를 넘어, 토스 품질의 표준을 세운다." 
처음 들으면 광범위해서 잘 와닿지 않을 겁니다. 그런데 표준이란 게 왜 있어야 할까요?
토스 팀은 매주 사용자에게 새 기능을 내놓습니다. 그때마다 품질을 판단하는 기준이 사람마다 다르면 안 됩니다. 누가 보든, 언제 보든, 같은 기준으로 걸러져야 합니다. 그래서 표준을 이렇게 정의했습니다.
하나, 이번 주도 다음 주도 믿을 수 있게 배포하는 것(Reliable Releases, Every Time). 한 번 잘 배포하는 것은 누구나 할 수 있습니다. 어려운 것은 매주, 빠짐없이, 같은 수준의 신뢰를 사용자에게 전달하는 일입니다. 
둘, 결함을 예리하게 짚어내는 것(Ensure Test Quality). 테스트는 많이 한다고 좋은 게 아닙니다. 진짜 사고가 될 결함을 정확히 골라내는 것이 실력입니다. 그래서 '무엇을 놓쳤나'에 집중합니다.
셋, 그걸 효율적으로 해내는 것(Assuring Quality Efficiently). 같은 일을 사람이 손으로 반복하는 방식만으로는 매주 쏟아지는 변화를 따라갈 수 없습니다. 그래서 우리는 ‘잘하는 것’만큼 ‘지치지 않는 것’도 중요한 표준으로 생각합니다.
이 셋을 매주 빠짐없이 지켜내는 것. 그것이 우리가 말하는 토스 품질의 표준입니다.
그리고 올해, 여기서 한 발 더 나아가기로 했습니다. 테스트가 스스로 동작하는 범위를 넓혀가는 일입니다. 모든 걸 AI에 맡기겠다는 뜻은 아닙니다. 맡겨도 될 판단은 AI에 맡기고, 사람은 정말 사람이 봐야 할 곳에만 집중하기로 했습니다.
우리만의 플레이그라운드 
매주 테스트할 일은 늘어만 갔습니다. 사람 손으로 하나하나 따라가기엔 버거운 양이었습니다. 마침 그때 AI가 빠르게 발전했고, 그 AI를 테스트에 제대로 써 보고 싶었습니다.
그런데 상용 도구만으로는 한계가 있었습니다. 우리의 업무를 도구가 정해 놓은 방식에 맞춰야 했고, 새로 나온 AI 기능도 필요할 때 바로 붙여 보고, 아니면 과감히 떼어낼 만큼 유연하게 활용하기 어려웠습니다. 토스의 배포 속도와 일하는 방식에 맞추려 할수록, 늘 어딘가 어긋났습니다.
그래서 직접 만들었습니다. 우리만의 플랫폼, 토션(Tossion)입니다.
토션은 QA Platform 팀의 정체성을 만들어가는 과정에서 시작됐습니다. QA인 우리가 더 효과적으로 일하고, 품질에 대한 이상을 온전히 구현하고 실험해볼 ‘우리만의 공간’이 있으면 좋겠다는 마음에서 출발했습니다.
토션의 첫 모습은 TestRail을 대체하는 일이었습니다. 기존 상용 도구에 있던 테스트의 전 과정, 케이스 작성부터 실행과 결과 기록까지를 토션으로 온전히 이관했습니다. 그 과정에서 제각각 쓰이던 여러  봇도 토션에 최적화된 하나의  봇, 토스버틀러(Toss Butler)로 통합했습니다. 단순히 도구를 교체한 것이 아니라, 우리가 일하는 방식에 꼭 맞도록 새롭게 빚어낸 결과였습니다.
옮겨오고 나니, 더 필요한 것들이 보이기 시작했습니다.
가장 먼저, 매주 쏟아지는 PR을 전부 들여다볼 순 없으니 "여기를 집중해서 보라"고 짚어주는 PR 분석기(PRCheck)를 더했습니다. 개발자가 무엇을 왜 바꿨는지, 그 변경이 어디에 영향을 주고 무엇을 테스트해야 하는지를 버그 위험도와 테스트 우선순위까지 체계적으로 확인할 수 있게 했습니다.
규모가 큰 변경이나 새 기능이 들어올 때마다, 테스트 케이스를 높은 완성도로 더 빠르게 작성해야 한다는 갈증도 커졌습니다. 그래서 PRD와 디자인 문서, 곳곳에 흩어진 맥락 정보를 모아 테스트 케이스를 자동으로 만들어 주는 tcgen을 추가했습니다. 처음부터 손으로 쓰는 대신, 탄탄한 초안을 빠르게 받아 검토에 집중할 수 있도록 말입니다.
매뉴얼 테스트와 자동화 테스트의 결과를 한자리에서 보고 싶다는 바람으로, 자동화 테스트 플랫폼도 붙였습니다. 이제 같은 테스트 수행 페이지에서 두 결과를 나란히 확인할 수 있습니다.
여기서 더 나아가, 발생하는 크래시를 단순한 건수가 아니라 토스에 맞는 지표와 추세로 읽어내기 위해 크래시 트렌드(Crash Trend) 대시보드를 만들었습니다. 핫픽스를 통제하기 위해 원인을 분류하고 '재발 방지' 대책을 남기는 데 초점을 둔 핫픽스 대시보드도 함께 마련했습니다.
이렇게 적고 보니 생소한 도구가 참 많습니다. 그런데 이건 따로따로 만든 게 아닙니다. "매주 쏟아지는 변화를 효율적으로 풀어내 보자"는 하나의 의지에서 가지처럼 뻗어 나온 결과입니다.
다만 오늘은 여기서 멈추려 합니다. 도구 하나하나가 저마다의 사연을 갖고 있어서, 앞으로 이 시리즈에서 하나씩 차근차근 소개하려고 합니다.
우리가 놓친 진짜 속마음
이런 도구들을 만들면서, 한 가지 가설을 세웠습니다. 테스트 케이스를 빠르게 만들어 제공하면 사람들이 테스트를 훨씬 쉽게 하겠지, 테스트에 대한 허들이 낮아지겠지. 
실제로 현장에서는 이런 이야기를 자주 들었습니다. “테스트 케이스를 좀 더 쉽게 작성할 방법은 없나요?” 자주 들리는 이야기였기에, 그 불편함만 덜어드리면 많은 분들이 반길 것이라고 생각했습니다.
그래서 tcgen을 만들어 공개했습니다. 그런데 생각만큼 사람들은 관심을 가지지 않았습니다. 분명 필요하다는 목소리가 있었는데, 왜 안 쓸까?
한참을 고민한 뒤에야 알았습니다. 사람들이 속으로 바란 건 '테스트를 쉽게 하는 것'이 아니었습니다. 누군가 빠르고 정확하게 테스트를 대신 해 주고, 그 품질까지 책임져 주는 것. 그게 진짜 속마음이었습니다.
도구를 쥐어주는 건, 결국 "이제 당신이 하세요"라는 말이었던 거죠. 우리는 짐을 덜어 준다고 생각했는데, 받는 쪽에서는 새 숙제였던 겁니다. 좋은 삽을 줬다고 해서, 사람들이 각자 구덩이를 파고 싶어 하는 건 아니었습니다.
이 깨달음이 저희의 하반기 방향을 바꿨습니다.
그래서 직접 핸들링하기로 했습니다. 사람이 매번 붙지 않아도 10X의 효율을 내고, 품질은 우리가 끝까지 책임지는 쪽으로. 어떻게 보면 더 험난한 길을 선택한 셈인데, 저희는 그게 맞다고 생각했습니다.
그럼에도 계속 고민이 되는 이유  
AI로 많은 시도를 했고 많은 숙제를 풀었습니다. 그런데도 고민은 사라지지 않습니다.
가설은 늘 반은 맞고 반은 틀립니다. 앞서 말한 tcgen이 그랬습니다. 게다가 AI는 따라잡기 버거울 만큼 빠르게 바뀝니다. 어제의 최선이 오늘은 낡은 방식이 되기도 합니다. 그 속도 안에서 QA가 익숙한 방식을 고집하는 순간, 품질을 지키기 위해 만든 도구가 오히려 변화의 속도를 늦추기 시작합니다.
그래서 ‘만들었다’에 안주하지 않기로 했습니다. 한번은 API 테스트를 쉽게 하려고 API Labs를 만들었지만, 맞지 않는 방향임을 알고 8시간 만에 걷어냈습니다. 공들여 만든 것도 아니다 싶으면 버리고, 방향은 언제든 바로 틀 수 있어야 합니다.
그래서 시스템도 그렇게 설계했습니다. 토션, 토스닥터와 토스체커, 직접 만든 스킬들은 완성된 결과물이 아닙니다. 더 나은 방법이 있다면 미련 없이 대체할  수 있도록, 처음부터 ‘언젠가 바뀔 것’을 전제로 만들었습니다.
AI는 다양한 문제를 해결해주지만, '무엇이 품질인지', '무엇을 끝까지 지켜야 하는지'까지는 정해주지 않습니다. 도구는 AI가 더 빨리 만들어 줄 수 있어도, 그 도구가 계속 쓸모 있도록 방향을 잡고 기준을 다시 세우는 일은 여전히 우리의 몫입니다.
우리의 이야기를 시작합니다
지금까지 저희가 누구이고, 무엇을 만들었고, 무엇을 시도하며 배워왔는지 짧게 풀었습니다. 이제 그 하나하나를 제대로 꺼내려 합니다.
토션(Tossion) : 우리만의 플랫폼은 어떻게 시작됐나
토스닥터(Toss Doctor) : 배포 전 마지막 관문은 무엇을 지키나
토스체커(Toss Checker) : 늘어나는 회귀를 어떻게 자동으로 감당하나
지능형 AI 봇 : 흩어진 도구를 한곳에서 어떻게 엮나
다음 주에도 토스는 어김없이 다시 태어납니다. 화면이 또 바뀌고, 수백 개의 변경이 또 쌓일 것입니다. 그 앞에서 이번 주처럼 또 멈춰 서서 묻겠습니다. "이거, 정말 내보내도 괜찮을까?"
누군가는 토스를 테스트합니다. 그리고 저희는 그 테스트하는 법을 만듭니다.

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

댓글