B컷 by 배민

QA팀을 맡고 있는 김은영입니다.

전사 서비스 품질은 도메인 단위로 나뉘어 있고, 각 도메인 담당자분들이 오너십을 갖고 자기 영역을 아주 잘 봐주고 계세요. 그래서 제 역할은 개별 검증을 챙기는 쪽은 아니에요. 도메인과 도메인 사이, 선후행 관계 사이에 숨어 있는 결함까지 걸러지도록 테트리스 조각을 맞추는 일이에요.

각자 자기 조각을 완벽하게 만들어도, 그 조각들이 서로 맞물리는지는 누군가 봐야 하잖아요. 그 자리에서 각자의 조각이 잘 맞춰질 수 있도록 지원하는 역할이라고 생각하시면 될 것 같아요.

가장 큰 차이는 문서화보다 속도와 임팩트를 먼저 본다는 거예요. 이걸 했을 때 비즈니스에 얼마나 영향을 주는지를 기준으로 판단해요. 그래서 저희 팀은 개발자적인 관점과 기획자적인 관점이 모두 필요해요. 물론 기획이나 개발을 모두 해야 한다는 의미는 아니고요, 오히려 그 균형감을 갖고 있는게 중요해요.

일반적인 QA는 SDLC(Software Development Life Cycle)라는 정해진 순서를 그대로 따라가요. 절차가 다 지켜져야 QA 단계로 넘어오는 형태죠. 그런데 저희는 반대로 접근해요. 시간이 한 시간밖에 없든 반나절밖에 없든, 그 안에서 최적의 결과를 뽑는 방법을 거꾸로 계산해요. 범위를 줄이거나 순서를 바꾸거나, 계속 계산하는 거예요.

예를 들면 이런 상황이에요. 배포 직전에 범위가 늘어났거나 검증 시간이 반나절밖에 안 남았을 때, 저희가 하는 건 “시간이 없어서 못 합니다”가 아니라 빠른 재정렬이에요. 이 변경이 사용자 경험에 실제로 얼마나 영향을 주는 부분인지, 지금 당장 확인해야 할 부분과 다음 단계에서 같이 보면 되는 부분은 뭔지를 나눠요. 그래서 “이 부분부터 먼저 확실하게 보고 가자”, “이 영역은 관련 팀과 계속 모니터링하면서 함께 보자”처럼, 리스크를 줄이면서도 서비스와 비즈니스 목표를 함께 달성할 수 있는 현실적인 방안을 제안하려고 합니다.

그렇다고 문서가 전혀 없다는 뜻은 아니에요. 다만 문서를 채우는 것 자체가 목적이 되면 정작 중요한 판단에 필요한 시간이 부족하거든요. 그래서 저희는 절차를 온전하게 지켰는가 보다는 지금 사용자에게 나가도 괜찮은가를 먼저 고민하려 해요. 이게 편하기만 한 방식은 아니에요. 매번 스스로 기준을 세워야 하니까요. 대신 QA가 배포를 통과시켜주는 사람이 아니라, 무엇을 어떻게 내보낼지 함께 정하는 사람이 되는 거죠.

팀원들이 각자 도메인에 떨어져서 일하다 보니, 같은 팀인데도 정작 협업으로 만나지 않는 한 함께 업무할 일이 많지는 않아요. 그래서 저희끼리도 화합에 대한 갈증이 있는 편이에요. 

그걸 풀어주는 게 한 달에 두 번 있는 팀 전체 밋업이에요. 함께 진행한 과제 이야기도 하고, 도메인별로 뭐가 힘들었는지 공유하고, 공통 프로세스로 만들면 좋을 것들을 제안하기도 해요. 외부 사례를 가져와서 우리한테 적용해보면 어떨지 얘기하는 시간도 만들어가고 있고요.

그중 반응이 제일 좋은 건 각자 도메인에서 알게 된 걸 나누는 시간이에요. “테스트 데이터 만드는 게 너무 귀찮아서 자동으로 만들어봤어요” 같은 이야기들이요. 기술블로그나 컨퍼런스에서 발표할 만한 굵직한 주제를 다루는 자리가 아니라, 아주 사소한 문제를 어떻게 해결했는지를 나누는 게 핵심이에요. 굵직한 걸 발표하는 자리가 되면 누구든 선뜻 말을 꺼내기 어려워지거든요.

그렇게 나온 이야기를 그냥 흘려보내지 않고 쌓아두기도 해요. 비슷한 불편이 여러 도메인에서 반복되면 “이건 아예 하나의 자동화 솔루션으로 만들자”로 이어지는 거죠. 테트리스에서 한 줄을 지우려면 조각이 모여야 하는 것처럼, 사소한 문제도 모아놓고 보면 만들 만한 게 보이거든요.

예전에는 자동화를 직접 코딩할 수 있는 사람을 찾았어요. 테스트 스크립트를 짤 수 있는지, 프레임워크를 다뤄봤는지가 중요한 기준이었죠. 그런데 지금은 코딩 자체는 AI가 상당 부분 해주는 시대잖아요. 그래서 “코드를 쓸 수 있는가”는 예전만큼 결정적인 기준이 아니게 된 거 같아요.

지금 저희가 찾는 건 빌더예요. 저희가 쓰는 빌더라는 말은 세 가지가 다 되는 사람인데요.

첫째, 반복되는 일을 보고 “이건 사람이 할 일이 아니다”라고 문제를 정의할 수 있는 사람. 

둘째, 그걸 어떤 구조로 만들면 되는지 설계할 수 있는 사람. 필요한 정보가 어디에 있고, 무엇을 자동으로 판단하게 만들 건지 그림을 그릴 수 있는 사람이죠.

셋째, 만들어놓고 끝이 아니라 실제로 팀이 잘 활용할 수 있도록 만드는 사람이에요. 

코드를 짜는 건 이 세 개 중 두 번째의 일부일 뿐이고, 그 부분은 AI가 도와주고 있어요.

실제 예를 들면, 저희는 과제 상태가 바뀔 때마다 사람이 슬랙에 일일이 공유하고 있었어요. 빌더의 일은 “그거 자동으로 보내면 되잖아요”에서 시작해요. 어떤 상태 변화가 누구에게 왜 중요한지 정리하고, 지라와 슬랙을 연결해서 알림이 자동으로 나가게 만들고, 팀이 그걸 신뢰하고 쓰게 되면 완성이에요. 배포할 때마다 스모크 테스트가 자동으로 돌게 만들어서 QA가 투입돼야 하는 상황인지를 시스템이 먼저 판단할 수 있도록 만든 것도 빌더의 모습이 잘 드러난 사례라고 생각해요.

그래서 면접에서도 무엇을 만들어봤는지보다 ‘왜 그걸 만들어야 한다고 생각했는지’를 더 많이 물어봐요. 도구는 계속 바뀌겠지만 ‘왜’를 고민하는 것은 계속 남을 테니까요.

먼저 저희가 봐야하는 것들이, 사람을 늘리는 속도보다 훨씬 빠르게 늘어나요. 기능이 하나 추가되면 그 기능에서 끝나는 게 아니라 기존 기능과의 조합까지 같이 봐야해요. 게다가 저희는 도메인이 서로 얽혀 있어서 피처 하나가 고객, 사장님, 라이더에게 동시에 영향을 줘요. 확인해야 할 조합은 기능이 늘어나는 속도보다 더 빨리 늘어나는데, 사람의 시간은 정직하게 늘어나잖아요. 이 격차를 사람 수로 메우는 건 어느 순간부터 불가능해졌어요.

게다가 이건 확인할 화면이 늘어나는 문제만은 아니에요. 도메인마다 정책과 맥락이 달라서, 한 도메인에 변경 사항이 생기면 영향을 받는 도메인의 영향 범위를 확인해야해요. 조합이 늘어나는 만큼 이 소통을 위한 비용도 함께 늘어나는데, 이건 사람이 늘어난다고 줄어 드는 비용은 아니에요. 그래서 영향 범위를 사람이 물어서 확인하는 게 아니라, 시스템이 먼저 짚어주는 방식으로 새롭게 접근해보고 있어요.

두 번째는  저희 QA의 병목이 실제로는 “테스트를 실행하는 시간”이 아니었다는 거예요. 정보를 모으고 판단하는 데 더 많은 시간을 들여왔어요. 과제를 파악하기 위해 여기저기 산재한 관련 정보를 파악하고, 배포의 리스크를 매번 사람이 모여 계산했어요. 이건 사람을 더 붙여도 안 줄어드는 종류의 일이에요. 정보를 한군데로 모으고 판단 근거를 시스템이 먼저 제시하는 방식으로 풀어야 줄어드는거죠.

세 번째는 사람의 시간을 어디에 쓸 것인가가 더 중요해졌어요. TC 작성이나 상태 보고처럼 형식이 정해진 반복 작업이 QA 시간을 꽤 많이 잡아먹고 있었어요. 근데 저희 팀원들이 제일 잘하는 건 그게 아니에요. 도메인을 이해하고, 이 변경이 비즈니스에 어떤 리스크인지 판단하고, 그래서 어떤 대안이 가능한지 제안하는 거죠. 그건 AI가 아직 어려워해요. 그러니까 저희가  AI 기반 자동화를 필요로 하는 이유는 사람을 줄이려는 게 아니라, 사람은 사람만 할 수 있는 판단에 시간을 쓰게 하려는 거예요.

그리고 이건 팀원들과 오래 함께 하고 싶은 욕심이기도 해요. 반복 작업만 계속하면 몇 년 뒤 정체 혹은 회의감이 느껴질 거예요. 반복을 시스템으로 바꿔본 경험이 남아야 하고, 그게 지금 QA 시장에서 제일 필요한 역량이라고 생각해요.

정말 간단한 것부터 말씀드리면, 과제 상태가 바뀔 때마다 슬랙이나 지라로 알림이 자동으로 나가게 만들었어요. 예전엔 사람이 일일이 챙겨야 했던 일이거든요. 

그리고 배포될 때마다 기본적인 스모크 테스트와 기능 테스트가 자동으로 작동하게 만들었어요. 그 결과 QA가 투입돼야 하는 상황인지 아닌지를 시스템이 먼저 판단해줘요. 저희 입장에서 이게 꽤 큰 변화예요. 예전엔 모든 배포에 일단 사람이 붙어 QA 투입 여부를 판단해줬다면, 지금은 진짜 사람이 필요한 배포에 집중할 수 있게 됐어요.

조금 더 큰 그림으로는 QA 엔지니어링 TF가 있어요. 서버 개발자와 QA 담당자가 같이 모여서 QA 업무를 시스템화하고, 그중 AI로 효율화할 수 있는 영역은 자동화하는게 목표예요. 세 갈래로 진행 중인데요, 먼저 흩어진 QA 과제 정보를 한 화면에 모으는 대시보드를 만들고, 코드베이스를 검색 가능하게 만들어서 AI가 판단 근거로 쓸 수 있게 하려고 해요. 마지막으로 이 두 가지 기능을 실제 과제 위에서 검증해볼 예정이에요.

일단 관련 정보가 여러 곳에 파편화되어 있어 과제를 파악하기 위해 여기저기 흩어진 정보를 일일이 모아서 확인해야 했어요. 그리고 위험도나 지연 여부를 판단할때도 관련 담당자들이 모여 직접 검토하다보니 시간이 많이 걸렸어요. 이렇게 흩어진 정보를 하나로 모으고, AI가 판단 근거를 먼저 짚어줄 수 있게 만들어서 검증의 신뢰성과 속도를 향상시키고자 했어요. 거기다 TC 작성이나 상태 보고처럼 형식이 정해진 반복 작업에 QA 시간을 꽤 많이 쏟고 있었고요. 이 세 가지를 개선해보자는 게 TF의 출발점이었어요.

그래서 지금 만들고 있는 건 크게 세 가지예요. 하나는 대시보드예요. 흩어져 있던 과제 정보를 한 화면에서 보고, 어떤 과제가 어느 단계이고 어디가 밀려 있는지 바로 보이게 하는 거죠. 또 하나는 코드베이스를 검색 가능하게 만드는 작업이에요. AI가 QA를 도와주려면 판단 근거가 있어야 하잖아요. “이 변경이 어디까지 영향을 주는가”를 코드에서 찾아올 수 있어야 영향 범위나 테스트 범위를 제안할 수 있거든요. 그리고 이 둘을 실제 과제 위에서 검증해보는 것까지가 세 번째예요. 데모로만 끝나면 의미가 없으니까요.

기대하는 것도 결국 같은 선상에 있어요. 과제를 파악하는 시간을 줄이고, 위험도나 우선순위를 감으로 판단하지 않고 같은 근거로 보게 되고, 반복 작업에 쓰던 시간을 진짜 검증과 판단에 쓸 수 있게 되는 거요.

사실 저한테 제일 인상 깊었던 건 속도였어요. 조직이 꾸려지고 3주 만에 동작하는 프로토타입이 나왔거든요. 개발과 QA가 같은 목표를 보면 이렇게 빨리 되는구나, 싶었어요.

지금은 AI가 진화하면서 사람의 역할도 진화하고 있다고 생각해요. 시스템이 반복 검증과 정보 수집을 하고, QA는 리스크를 판단하고 대안을 설계하는 쪽으로 옮겨가는 거죠. 그러면 “안 된다가 아니라 될 방법을 찾는 QA”가 특별히 잘하는 몇 사람의 특성이 아니라 팀의 일하는 방식으로 정착될 수 있다고 생각해요. 그게 제가 제일 바라는 그림이에요.

결국 QA가 배포 전에 통과해야 하는 관문이 아니라, 고객들이 빠르게 서비스를 만날 수 있도록 돕는 역할이 되게 하고 싶어요. “QA 일정 언제 잡을 수 있어요?”라는 질문을 여전히 자주 받는데요, QA가 필요한지 여부를 시스템이 우선적으로 판단해줄 수 있게 된다면 업무의 속도와 밀도가 달라질거라 확신해요.

내년에는 변경 영향도를 기반으로 시스템이 테스트 범위를 추천하고, 그 중 일정 부분의 테스트 수행까지 대신하는 수준을 목표로 하고 있어요. 그 목표가 달성되면 사람이 꼭 필요한 영역과 역할이 훨씬 선명해질 거라고 생각해요.

기본적으로 오지랖이 넓어서 “이게 정말 괜찮을까?”를 계속 의심할 수 있는 사람을 찾고 있어요. 이건 QA의 기본 소양이라고 생각해요.그런데 저희가 진짜 원하는 사람은 거기서 멈추지 않아요. 의심으로 끝나면 “이래서 못 한다”만 남거든요. 그 대신 될 수 있는 방법을 같이 찾아서 제안하는 사람이었으면 해요. 예를 들어 비즈니스 임팩트가 크면 “이 기능은 빼고 배포하자”, “하루만 더 쓰자”, “배포하고 나서 빠르게 고치자” 같은 대안을 스스로 내놓을 수 있어야 해요. 

그러려면 QA의 관점으로만 보면 다 안 된다는 결론이 나와요. 그래서 저희는 QA가 아니라 서비스의 관점으로 봐달라고 늘 얘기해요. 그러려면 개발, 비즈니스, QA 모두에 대해 균형 잡힌 이해가 필요한 것 같아요. 실제로 이런 균형을 갖추기가 쉽지 않으니, 전형 과정에서 아쉬움이 남는 경우가 많습니다. 기술적 이해도는 높지만 비즈니스적 임팩트를 연결해 생각해 보지 못하셨거나, 반대로 기획적 고민 대비 개발 언어나 클라우드 환경 같은 기술적 환경에 대한 이해가 깊지 않으신 경우가 그 예죠.

그리고 결과 자체보다 ‘왜 이걸 만들어야 하는지’에 대한 본질적인 고민이 담겨 있는 결과물이 훨씬 매력적입니다. 기술과 비즈니스를 아우르는 시각으로 ‘왜’라는 질문을 던질 줄 아는 분이라면 우리 팀과 최고의 시너지를 낼 수 있습니다.

정리해보면 “이게 괜찮을까”를 의심하되 거기서 멈추지 않고 대안까지 제안할 수 있는 사람, 서비스의 관점에서 생각할 수 있는 사람, 그리고 자기가 왜 그걸 만들었는지 스스로 설명할 수 있는 사람을 찾고 있어요. 이 세 가지를 다 갖춰야 한다는 게 아니라, 이 방향으로 계속 움직이려는 사람이면 저희랑 잘 맞을 거예요.

총 경력이 7년 이상이면 되고, 그 7년이 전부 QA 경력일 필요는 없어요. 개발, 기획 등 다양한 경험을 가지고 있는 분들도 지원이 가능해요. 

꼭 QA 전문가가 아니더라도, 기획이나 개발 실무를 하면서 사용자의 입장에서 서비스를 고민해본 분들이 오히려 위에서 얘기한 서비스의 관점에서 생각하는 QA를 잘 하실 수 있는 자질을 갖췄다고 생각해요.

또 실제 개발 경험이 있는 분들은 “이걸 왜 수기로 하지? 시스템으로 만들면 될 텐데”라는 생각을 하실 수 있거든요. 그런 생각들이 팀에 큰 도움이 돼요. 그래서 QA 경험은 없어도 개발을 전공했거나 관련 실무 경험이 있는 분들도 관심 갖고 지원해주셔도 좋을거 같아요.

다만 조건이 하나 있긴 해요. 사전과제가 있고 이 사전과제를 스스로 해독하여 해결해낼 정도의 기본적인 지식이 있다면 문제 없어요!

아무래도 채용을 위한 과제다 보니 내용을 말씀드릴 수 없지만 정답이 있는 과제는 아니에요. 저희가 실제로 하는 일과 비슷한 상황을 드리고, 그 상황을 어떻게 풀어가는지를 봐요. 사람마다 접근이 다를 수밖에 없고 그 차이를 보는 게 사전과제를 드리는 목적이에요.

2개의 기준으로 과제를 평가해요. 하나는 스스로 문제를 정의했는지예요. 요구사항이 친절하게 정리돼서 오는 일은 실무에도 없거든요. 다른 하나는 기준을 가지고 검토의 범위와 내용을 설명할 수 있는지예요. 이게 사실 제일 중요해요.

그래서 완성도보다 사고 과정을 봐요. 다 못 풀었어도 “여기까지 확인했고 여기서 막혔고 이렇게 접근하려고 했다”가 남아 있으면 충분히 좋은 결과예요. 반대로 결과는 깔끔한데 그 과정에 대한 설득력이 없다면 좋은 평가를 주기 어려운 거 같아요.

참고로 AI도구를 활용해도 괜찮은지 궁금하실 것 같아요. 쓰셔도 괜찮습니다만, 그 과정을 스스로 설명할 수 있어야 해요.

개발을 전공하고 개발자로 일하시다가 QA 직무로 입사하신 분이 있어요. 처음엔 스스로 봐야 할 범위를 정하는 걸 어려워하셨어요. 요구사항에 맞춰 개발하는 환경에서 일해오셨으니까요. 코드는 읽히는데 어디까지 봐야 하는지는 모르겠다고 하셨던 게 기억나요.

그러던 중 테스트 데이터를 자동으로 만들어주는 도구를 직접 만드셨어요. 그게 팀에서 실제로 잘 쓰이게 됐고, 그때부터 자신감이 붙으셨어요. 지금은 스스로 범위를 정하는 건 물론이고 일정이나 우선순위 조율도 깔끔하게 하고 계세요. 특정 도메인을 단독으로 리딩하면서 팀 전체가 쓸 수 있는 도구도 고민해주고 계셔요.

오히려 QA 경험이 없었기 때문에 모두가 당연하게 수기로 하고 있던 일에 “왜”라고 물어볼 수 있었다고 생각해요. 이런 새로운 시각이 팀에 큰 도움이 되고 있어요.

솔직히 말씀드리면 편하게 일할 수 있는 팀은 아니에요. 정해진 절차대로 흘러가지 않고, 매번 주어진 시간 안에서 스스로 기준을 세워야 하고, 혼자 끝낼 수 있는 일도 거의 없어요. 그래서 “명세대로 테스트하고 결과를 정리하는 일”을 찾으신다면 저희와는 맞지 않으실거예요.

대신 얻어가는게 분명히 있을 거에요. 지금 QA라는 직무 자체가 크게 변화하고 있잖아요. 반복 검증은 시스템의 역할이 되어가고, 사람은 문제를 정의하고 판단하는 역할로 그 무게중심이 옮겨가고 있다고 생각해요. 그리고 우아한형제들 QA팀은 그 변화를 직접 만들어가고 있어요. 

저희와 함께하시면 “테스트를 잘하는 사람”이 아니라 품질을 시스템으로 만들어본 사람이 돼요. 그리고 그 경험이야말로 AI 시대에도 유의미한 경험일 거라고 생각해요.

QA 경험이 없어도 괜찮아요. 개발, 기획, 마케팅을 하면서도 “이게 정말 괜찮을까?”라고 끝까지 의심해본 경험이 있고, 그 의심 끝에 “안 된다”가 아니라 될 방법까지 찾아본 분이라면 충분히 잘하실 수 있어요.

저희는 아직 조각 하나가 비어 있어요. 그 자리를 채워주실 분을 기다리고 있어요.