Teams
・
.
.
QA는 수문장입니다
모디팩토리 QA 팀장 Ryan 인터뷰
게임 업계에서 10년의 내공을 쌓은 QA 베테랑은 왜 낯선 AI와 에듀테크의 세계로 뛰어들었을까요? 럭스로보 P&O실의 Ryan은 완벽하게 갖춰진 거대한 시스템에 머무는 대신, 스스로 시스템을 구축하고 품질의 기준을 세워가는 '성장의 길'을 택했습니다. 효율적인 이슈 관리 시스템을 직접 설계하고, 하드웨어와 소프트웨어를 아우르는 복합적인 프로덕트 환경에서 유관 부서와 건강한 시너지를 만들어가는 Ryan.
Ryan이 생각하는 진짜 QA의 의미와 타협 없는 품질 관리 노하우를 만나보세요.
이런 분이라면 Ryan의 인터뷰를 꼭 읽어보세요!
✅ 성장통을 겪고 있는 주니어~미들급 QA 담당자
✅ 새로운 도메인으로의 이직이나 도전을 앞둔 실무자
✅ 초기 시스템 구축이 필요한 스타트업 구성원
Part 1. 게임 업계 베테랑의 AI 입문기
간단한 자기소개와 함께, 현재 QA 팀의 주요 업무와 역할을 소개해 주세요.
모디팩토리 QA 팀장, Ryan
안녕하세요. 럭스로보 P&O실에서 QA를 담당하고 있는 Ryan입니다.
현재 럭스로보에서 서비스 중인 모디팩토리를 비롯하여 교육용 All-in-One 서비스인 MODI, 주거 공간에 적용되는 AIoT 서비스 및 주차 통합 시스템 등 다양한 프로젝트의 SW/HW 제품 전반에 대한 QA를 담당하고 있습니다.
주요 업무로는 프로젝트별 요구사항 분석과 테스트 계획 및 설계, 기능 검증, 이슈 관리, 배포 전 품질 리스크 검토 등을 수행하고 있습니다. 이와 더불어 프로젝트별로 일관된 품질 기준을 적용할 수 있도록 QA 프로세스와 운영 기준을 정립하고, 유관 부서와 협업하며 안정적인 제품과 서비스를 제공하기 위한 품질 관리 업무를 진행하고 있습니다.
게임 업계에서 약 10년이라는 긴 시간 동안 QA 내공을 탄탄하게 쌓으셨습니다. 이후 에듀테크 및 AI 중심의 기업인 럭스로보에 합류하시게 된 특별한 계기나 기대했던 점은 무엇이었나요?
게임 업계에서 약 10년간 근무했지만, 사실 제가 경험한 업무가 게임 QA에만 국한되어 있지는 않았습니다. 소속되어 있던 팀의 특성상 게임 관련 HW/SW QC를 비롯하여 Web QA, PC방 관리 프로그램 QA, Esports 관련 업무 등 다양한 분야의 업무를 담당했습니다. 특히 약 10년의 경력 중 절반에 해당하는 5년 동안 이러한 업무들을 경험하면서, 하나의 도메인에 국한되지 않고 다양한 제품과 서비스를 접할 수 있었습니다.
그러던 중 AI, AIoT, 에듀테크 분야를 중심으로 사업을 전개하는 럭스로보를 알게 되었고, 지금까지 쌓아온 다양한 QA 경험을 활용하면서도 새로운 기술과 도메인을 경험할 수 있는 기회라고 생각했습니다. 물론 게임과 AI, AIoT, 에듀테크는 제품의 특성과 사용 환경이 서로 다르지만, 사용자에게 안정적인 제품과 서비스를 제공한다는 QA의 본질적인 목적은 크게 다르지 않을 것이라고 생각했습니다.
그동안 쌓아온 경험을 새로운 환경에서도 활용할 수 있을지 직접 확인해 보고 싶었고, 동시에 익숙하지 않은 기술과 제품을 경험하면서 QA로서의 역량을 더욱 넓혀갈 수 있을 것이라는 기대를 가지고 럭스로보에 지원하게 되었습니다.
Part 2. 타협 없는 품질을 이뤄내기까지
입사 당시 럭스로보의 QA 환경은 어땠나요? 새로운 테스트 기준과 체계적인 프로세스를 도입해 나가는 과정이 쉽지만은 않았을 것 같습니다.
입사 당시에도 럭스로보 내부의 프로세스에 따라 QA 업무는 진행되고 있었습니다. 다만, QA 정책이나 프로세스, 이슈 관리 방식, 프로젝트별 운영 기준 등이 여러 곳에 분산되어 있어 전체적인 운영 체계를 파악하기 어려운 상황이었습니다. 무엇보다 이러한 기준들을 한곳에서 확인하고 참고할 수 있는 공간이 마련되어 있지 않았습니다.
그래서 입사 후 가장 먼저 진행한 업무는 럭스로보의 여러 프로젝트에서 공통적으로 활용할 수 있는 QA 프로세스와 운영 기준을 정립하는 것이었습니다.
기존에 운영되던 프로세스와 정책을 검토하고, 분산되어 있거나 서로 다르게 적용되고 있던 기준들을 하나의 체계로 정리하는 작업을 진행했습니다. 이 과정에서 중요하게 생각했던 것은 단순히 새로운 기준을 만드는 것이 아니라, 기존 업무 방식을 최대한 이해하고 실제 프로젝트에서도 무리 없이 활용할 수 있는 프로세스를 마련하는 것이었습니다. 약 한 달 동안 QA 프로세스를 재구성하고 운영 기준을 재정립했으며, 이후 모디팩토리 프로젝트의 유관 부서 구성원들에게 해당 내용을 발표하고 공유했습니다.
현재까지도 정립한 QA 프로세스와 운영 기준을 바탕으로 업무를 진행하고 있습니다. 저는 QA 프로세스가 단순히 문서로 존재하는 것이 아니라, 실제 업무에서 누구나 이해하고 활용할 수 있는 기준이어야 한다고 생각합니다. 이번 경험 역시 그러한 환경을 마련하기 위한 과정이었다고 생각합니다.
Ryan이 직접 프로세스를 구축하고, 현재 시스템에 이식하셨는데요. 이 프로세스가 정착된 후 유관 부서와의 협업이나 실제 업무 효율에 어떤 긍정적인 변화가 있었나요?
현재 여러 플랫폼과 프로젝트의 QA 업무를 담당하고 있다 보니, 프로젝트별 테스트 일정이 겹치거나 출장 등으로 인해 직접 QA를 수행하기 어려운 상황이 발생하기도 합니다. 기존에는 이러한 상황에서 담당자가 변경되면 업무를 이어가기 위한 별도의 설명이나 인수인계가 필요할 수 있었지만, QA 프로세스와 운영 기준을 정립한 이후에는 이러한 의존도를 줄일 수 있는 환경을 마련했습니다.
테스트 환경과 필요한 정보가 준비되어 있다면, 제가 직접 수행하지 않더라도 정해진 프로세스와 테스트 케이스를 바탕으로 다른 담당자가 QA 업무를 이어갈 수 있도록 구성한 것입니다. 이를 위해 이슈 리포트 작성 가이드와 테스트 케이스 템플릿을 마련했으며, QA 프로세스 및 운영 정책도 정기적으로 업데이트하고 있습니다.
또한, 관련 내용을 한곳에서 확인할 수 있도록 구성하여, 유관 부서에서도 QA 진행 방식이나 이슈 관리 기준 등에 대한 확인이 필요할 때 별도로 문의하지 않고 문서를 참고할 수 있도록 했습니다. 이러한 변화는 단순히 업무를 문서화했다는 것보다, 특정 담당자의 경험이나 기억에 의존하지 않고 공통된 기준을 바탕으로 협업할 수 있는 환경을 마련했다는 점에서 의미가 있다고 생각합니다.
여러 프로젝트의 이슈를 효과적으로 관리하기 위해 버그 트래킹 시스템(BTS)을 직접 구축하셨다고 들었습니다. 이 시스템을 기획하시게 된 배경과 실제 활용 성과가 궁금합니다.
당시에는 프로젝트별로 발생한 이슈를 체계적으로 관리하고 추적할 수 있는 환경이 마련되어 있지 않았습니다. 그로 인해 이슈 히스토리와 미해결 이슈들이 여러 곳에 흩어져 있었으며, 과거 발생한 문제나 현재 남아 있는 이슈의 상태를 파악하기가 어려운 상황이었습니다.
이러한 문제를 해결하기 위해 기존에 사용했던 Jira와 Confluence의 운영 경험을 바탕으로 이슈 관리 환경을 구축하고자 했습니다. 다만 별도의 BTS를 도입하게 되면 추가적인 비용뿐만 아니라 새로운 도구에 적응하고 운영하기 위한 리소스도 필요했기 때문에, 기존에 회사에서 사용하고 있던 Notion을 활용하는 방안을 검토했습니다. Notion의 데이터베이스 기능을 활용하면 Jira와 유사한 방식으로 이슈를 등록하고, 담당자 지정, 상태 변경, 수정 현황 및 이력 관리가 가능할 것으로 판단했습니다.
이에 따라 Notion 데이터베이스를 기반으로 Issue Report 보드를 직접 설계하고 구축했습니다. 이후 단순한 이슈 관리를 넘어 프로젝트별 Notion 페이지를 구성하여, 하나의 페이지에서 프로젝트의 시작 단계부터 QA 진행 현황, 이슈 관리, 최종 마무리 단계까지 확인할 수 있도록 운영 환경을 확장했습니다.
그 결과 기존에 분산되어 있던 이슈를 한곳에서 관리하고, 이슈별 담당자와 진행 상태, 변경 이력을 지속적으로 추적할 수 있는 환경을 마련했습니다. 또한 별도의 BTS 도입 없이 기존 협업 도구를 활용함으로써 추가적인 도구 도입 및 학습 부담을 줄일 수 있었습니다. 이 경험은 단순히 이슈 관리 도구를 구축한 것이 아니라, 기존 QA 업무에서 발생하던 비효율을 파악하고, 주어진 환경과 리소스 안에서 직접 개선 방안을 마련했다는 점에서 의미가 있다고 생각합니다.
하드웨어와 소프트웨어가 맞물려 돌아가는 복합적인 프로덕트를 다루다 보면, 시뮬레이션에서는 발견하지 못한 이슈를 마주할 때가 있을 것 같은데요. 그동안 럭스로보에서 테스트를 진행하며 가장 기억에 남는 아찔했던 순간이나 극적으로 해결했던 이슈가 있다면 하나만 들려주세요.
사실 이러한 부분은 지금도 QA를 진행하면서 종종 마주하고 있습니다. 소프트웨어 중심의 제품이 아닌, 하드웨어와 소프트웨어가 함께 동작하는 제품을 테스트할 때마다 느끼는 차이점이 있습니다. 소프트웨어의 경우 개발 환경에서 문제를 재현하고, 원인을 분석하여 수정한 후 다시 검증하는 과정을 비교적 유연하게 진행할 수 있습니다.
하지만 하드웨어가 연동되는 제품은 상황이 조금 다릅니다. 소프트웨어와 하드웨어가 정상적으로 연동되는지, 각 기능이 의도한 대로 동작하는지도 중요하지만, 문제의 원인이 소프트웨어가 아닌 하드웨어 자체의 결함일 가능성까지 고려해야 하기 때문입니다.
펌웨어 수정으로 해결할 수 있는 문제라면 수정된 버전을 전달받아 재검증을 진행할 수 있지만, 하드웨어 자체에 결함이 있는 경우에는 부품을 교체하거나 협력사를 통해 새로운 장비를 제공받아야 하는 상황도 발생할 수 있습니다. 이러한 경우에는 QA뿐 아니라 개발 일정과 협력사의 대응 일정까지 영향을 받을 수 있다는 점이 기존에 경험했던 소프트웨어 중심의 QA와는 상당히 다르게 느껴졌습니다.
특히 인상 깊었던 부분은 QA 과정에서 발견한 문제가 단순한 기능 수정으로 끝나는 것이 아니라, 하드웨어 교체나 외부 협력사의 대응까지 필요한 문제로 이어질 수 있다는 점이었습니다. 이를 경험하면서 테스트 계획을 수립할 때 정상적인 검증 기간만 고려해서는 안 된다는 것을 느꼈습니다. 하드웨어 결함으로 인한 장비 교체, 협력사 대응, 재검증 등 예상하지 못한 상황이 발생할 가능성까지 고려하여 일정을 산정하고, 사전에 리스크를 파악하는 것이 중요하다는 것을 배웠습니다.
결국 HW/SW 통합 제품의 QA에서는 기능을 검증하는 역량뿐 아니라, 문제 발생 시 필요한 대응 과정과 일정에 미치는 영향까지 고려하는 능력도 중요하다는 것을 느꼈습니다.
QA는 품질을 위해 개발팀에게 피드백을 전달하고, 때로는 일정과 품질 사이에서 의견을 조율해야 하는 포지션입니다. 개발 조직과 건강한 시너지를 내면서도 '품질'이라는 타협할 수 없는 기준을 지켜내는 Ryan만의 커뮤니케이션 노하우가 궁금합니다.
저는 사우분들이 많은 시간과 노력을 들여 만들어낸 결과물이기 때문에, 발견한 이슈를 가볍게 판단하거나 전달하지 않으려고 합니다.
우선 테스트 계획 단계에서 준비한 환경을 기준으로 문제가 재현되는지 확인하고, 이슈가 발생한 위치와 상황을 분석하여 재현에 필요한 조건과 과정을 검증합니다. 이후 이슈 리포트를 작성하는데, 이 과정에서 제가 중요하게 생각하는 몇 가지 원칙이 있습니다.
첫 번째는 제목만 보고도 다른 사람이 어떤 문제인지 파악할 수 있어야 한다는 것입니다.
두 번째는 문제가 발생하는 순간을 확인할 수 있는 영상이나 이미지를 반드시 첨부하는 것입니다.
세 번째는 재현 단계를 가급적 5단계 이내로 간결하게 작성하는 것입니다.
사람은 누구나 길고 복잡한 설명보다 간결하고 명확한 정보를 이해하기 쉽다고 생각합니다. 물론 복잡한 이슈의 경우 예외가 필요하지만, 가능한 한 불필요한 설명을 줄이고 핵심 정보만 전달하려고 노력합니다. 이러한 원칙을 지키는 것만으로도 개발자가 이슈를 이해하고 재현하기 위해 추가로 확인해야 하는 내용을 줄일 수 있으며, 서로 불필요한 커뮤니케이션을 반복하지 않는 데 도움이 된다고 생각합니다.
또한 이슈에 대한 의견이 다를 때에는 단순히 QA의 판단이 옳다고 주장하기보다는, 해당 문제가 어떤 조건에서 발생하고 사용자와 서비스에 어떤 영향을 미칠 수 있는지 객관적인 근거를 바탕으로 설명하려고 합니다. 결국 제가 생각하는 좋은 커뮤니케이션은 단순히 상대방을 설득하는 것이 아니라, 서로가 같은 정보를 바탕으로 문제를 이해하고 합리적인 판단을 내릴 수 있도록 돕는 것입니다.
Part 3. 한계 없는 제너럴리스트가 정의하는 '진짜 QA’
QA의 관점에서, 과거 게임 도메인과 현재 모디팩토리를 비교했을 때 체감하시는 가장 큰 차이점, 혹은 반대로 '본질적으로 같다'고 느끼시는 지점은 무엇인가요?
처음에는 게임과 모디팩토리가 서로 다른 도메인이기 때문에 QA를 진행하는 방식에도 많은 차이가 있을 것이라고 생각했습니다.
하지만 실제로 모디팩토리를 비롯한 여러 프로젝트의 QA 업무를 진행하면서, 플랫폼과 제품의 특성에는 차이가 있지만 사용자에게 안정적인 서비스를 제공해야 한다는 QA의 본질적인 목적은 동일하다는 것을 느꼈습니다.
물론 게임에서는 플레이 흐름과 사용자 경험이 중요하고, 모디팩토리에서는 핵심 기능의 동작뿐 아니라 작업 결과의 정확성과 안정성이 중요하다는 차이가 있습니다. 그러나 요구사항을 분석하고, 발생 가능한 리스크를 예측하며, 이를 바탕으로 테스트를 설계하고 검증하는 기본적인 QA 프로세스는 크게 다르지 않았습니다.
실제로 이전 게임 프로젝트에서 쌓아온 QA 경험과 프로세스를 모디팩토리에도 적용할 수 있었으며, 제품 특성에 맞게 검증 범위와 우선순위를 조정하면서 QA 업무를 수행할 수 있었습니다. 이러한 경험을 통해 QA에서 중요한 것은 특정 플랫폼에 대한 경험만이 아니라, 제품을 이해하고 품질 리스크를 판단하여 적절한 검증 방법을 설계하는 능력이라는 생각을 더욱 확고히 하게 되었습니다.
Ryan이 생각하시는 '실력 있는 QA'의 핵심 역량은 무엇이라고 생각하시나요?
저는 QA가 배포 전 발생할 수 있는 품질 리스크로부터 골대를 지키는 수문장과 같은 역할을 한다고 생각합니다. 이러한 역할을 수행하기 위해서는 무엇보다 자신이 담당하는 프로젝트와 제품에 대한 높은 이해도가 필요합니다.
단순히 요구사항에 맞게 동작하는지를 확인하는 것을 넘어, 사용자의 관점에서 어떤 문제가 발생할 수 있는지, 그 문제가 제품과 서비스에 어떠한 영향을 미칠 수 있는지 판단할 수 있어야 합니다.
또한, 언제나 최상의 상황만을 가정하기보다는 발생 가능한 다양한 예외 상황과 리스크를 사전에 예측하고, 제한된 시간과 리소스 안에서 무엇을 우선적으로 검증해야 하는지 판단할 수 있어야 한다고 생각합니다.
결국 제가 생각하는 실력 있는 QA의 핵심 역량은 제품에 대한 이해를 바탕으로 리스크를 예측하고, 합리적인 판단을 통해 품질 확보에 기여하는 능력입니다. 저 역시 이러한 역량을 갖추기 위해 끊임없이 고민하고 있으며, 스스로를 실력 있는 QA라고 평가하기보다는 맡은 역할과 책임을 묵묵히 수행하면서 더 나은 품질을 위해 노력하는 QA가 되고자 합니다.
최근 QA 직무에서도 테스트 자동화와 AI 툴 활용이 중요한 화두로 떠오르고 있습니다. 향후 조직에 도입하고 싶거나 현재 눈여겨보고 있는 테스트 자동화 기술이나 트렌드가 있으신가요?
테스트 자동화는 사실 AI가 등장하기 이전부터 QA 업계에서 꾸준히 화두가 되어 왔던 부분이라고 생각합니다. 과거에도 Python이나 Selenium 등을 활용하여 테스트 자동화 환경을 구축하고 운영하는 사례들이 있었지만, 이를 활용하기 위해서는 프로그래밍에 대한 이해와 별도의 학습이 필요했습니다.
또한, 자동화 환경을 구축한 이후에도 테스트 환경의 변화나 제품 업데이트에 따른 코드 수정, 유지보수 등에 적지 않은 리소스가 소요된다는 어려움이 있었습니다. 그렇기 때문에 자동화가 무조건 효율적인 것은 아니었으며, 주로 반복 수행이 많거나 검증 절차가 비교적 명확하고 안정적인 업무를 중심으로 활용하는 것이 현실적이라고 생각했습니다.
하지만 최근 AI 도구의 발전으로 이러한 환경에도 많은 변화가 생겼다고 느끼고 있습니다. 이전에는 직접 코드를 작성하고 수정해야 했던 부분들을 이제는 AI의 도움을 받아 구현할 수 있게 되었고, 프로그래밍에 대한 이해도가 높지 않더라도 테스트 자동화를 시도하고 활용할 수 있는 환경이 마련되었다고 생각합니다.
저 역시 이전부터 관심을 가지고 있던 Maestro, Appium, Playwright 등의 테스트 자동화 도구들을 AI와 함께 활용해 보고 있습니다. 특히 AI를 통해 테스트 스크립트를 생성하거나 수정하고, 오류의 원인을 분석하는 과정에서 기존보다 자동화 구현에 필요한 부담이 줄어들었다는 점을 체감하고 있습니다.
물론 AI가 작성한 코드라고 해서 무조건 신뢰할 수 있는 것은 아닙니다. 해당 테스트가 의도한 검증 목적에 맞게 동작하는지, 실제로 올바른 결과를 판단하는지는 QA가 직접 확인해야 한다고 생각합니다. 앞으로도 모든 테스트를 자동화하기보다는 반복 수행이 많고, 자동화를 통해 실질적인 효율을 얻을 수 있는 영역부터 단계적으로 적용해 보고 싶습니다.
결국 제가 가장 주목하고 있는 부분은 특정 자동화 도구 자체보다는, AI를 활용하여 기존에 시간과 기술적인 제약으로 시도하기 어려웠던 테스트 자동화를 보다 현실적으로 활용할 수 있게 되었다는 점입니다.
마지막으로, 품질의 기준을 세워가기 위해 노력하는 주니어 QA 담당자들에게 전하고 싶은 조언이 있다면 부탁드립니다.
모디팩토리 QA 팀장, Ryan
