[참가 보고] Merpay Tech Talk ~QA는 AI로 어떻게 진화할까? 메루카리 그룹의 AI × QA 실전~

원문 발행 2026. 11. 09. 20:44원문 언어 영어AI 한국어 번역Qiita AI 원문 보기

요약

Merpay는 'AI Native' 방침에 따라 QA 프로세스를 혁신하고, 자체 개발한 테스트 관리 툴 'MerQA'를 통해 전 과정을 자동화합니다. 이 시스템은 AI가 사양 검토부터 테스트 케이스 작성 및 실행까지 담당하며, 중앙 집중화된 자산을 활용해 엔지니어의 셀프 QA를 가능하게 합니다. 최종적인 종합 리뷰와 승인은 여전히 사람이 수행하는 구조로 진화하고 있습니다.

핵심 포인트

AI가 사양 검토, 테스트 설계, 케이스 작성 등 QA 전 단계를 지원합니다.
MerQA는 테스트 자산을 중앙 집중화하여 재활용성을 극대화했습니다.
정적 테스트 기능을 통해 실제 실행 없이 코드의 성공/실패를 추론할 수 있습니다.
로컬 환경에서 Claude Code 등을 활용해 브라우저 조작 및 증거 확보가 가능합니다.
AI는 루프(Loop)를 담당하고, 사람은 최종적인 종합 리뷰에 집중하는 것이 목표입니다.

이벤트: Merpay Tech Talk ~~QA는 AI로 어떻게 진화할까? 메루카리 그룹의 AI × QA 실전~~
주최: 주식회사 Merpay
발표자
yu-ga님 (Merpay QA): 테스트 관리 툴 'MerQA'를 개발한 사람
komatsuna님 (Merpay QA): MerQA의 테스트 설계 판정 메커니즘을 담당
taru님 (Merpay QA): QA Enablement team에서 회귀 테스트(Regression Test) 자동화를 담당
masamichi님 (Merpay QA Engineering Director): 모더레이터

발표별로 인상 깊었던 내용을 메모했습니다. 발언은 요약되었습니다.

회사 변화
메루카리의 'AI Native' 방침. 업무와 조직을 AI를 전제로 변화시키고 있음
직무나 부서의 경계를 넘는 방침. 품질 확인도 QA만의 일이 아니라 엔지니어들도 할 수 있도록 하고 싶음
당시 QA의 과제
테스트 관리 툴이 제품(Product)마다 달라서, AI 활용 방식도 사람마다 다름
테스트 설계, 케이스, 회귀 테스트, 지식(Knowledge)이 각기 다른 곳에 분산되어 있어 전체를 파악하는 것은 오직 QA만 할 수 있었음
AI를 전제로 하고, 누구나 QA를 할 수 있게 하며, 테스트 자산을 재활용할 수 있도록 직접 제작함
상사에게 PoC(Proof of Concept)를 보여준 것이 계기가 되어 회사 전체의 툴이 됨
AI가 먼저 작업을 수행하고, 사람은 답변/리뷰/수정을 함
흐름은 4단계
1. 사양(Specification): AI가 QA 관점에서 리뷰하여 질문 → 사람이 답변
2. 테스트 설계: AI가 작성 → 사람이 리뷰
3. 테스트 케이스: AI가 작성 → 사람이 리뷰
4. 실행 및 버그 기재: AI가 실행 → 사람이 증거(Evidence)를 확인
'프로젝트' 안에 회귀 테스트 지식과 건별 테스트 플랜을 모음
과거의 테스트 플랜과 지식을 다음 생성 시 참조함. 사용할수록 프로젝트에 맞는 케이스가 나옴
화면 외에도 로컬 AI 에이전트나 Slack 봇을 통해 MCP를 거쳐서도 사용 가능
정적 테스트(Static Test)
코드의 차분(Diff)과 테스트 케이스를 AI에게 전달하여, 실제로 실행하지 않고 성공/실패 여부를 추론시킴
실패로 판정된 케이스는 실제 실행 시 우선적으로 확인함
부족한 테스트 케이스 제안도 함
테스트 실행
실행처는 사내 에이전트 기반 또는 개인 PC의 Claude Code
E2E(End-to-End) 코드를 작성하는 것이 아니라, 브라우저나 실기에서 케이스를 하나씩 조작함
단계마다 증거를 남김. 실행할 수 없으면 이유와 함께 Blocked 처리함
증거 리뷰
다른 AI가 스크린샷/녹화/로그를 절차 및 기대 결과와 비교함
마지막 승인은 사람의 몫임
호텔 예약 샘플 사이트에서 실행해 봄
로컬 실행을 선택하면 Claude Code가 구동되어 브라우저를 조작함 (약 2분 소요)
결과는 Failed. 필수 항목이 미선택이라 다음 단계로 진행할 수 없었음
실패 원인이 케이스의 절차 때문인지, 제품(Product) 자체의 문제인지는 사람이 판단해야 함
테스트 자산이 MerQA에 모여들게 됨
엔지니어의 셀프 QA를 QA 엔지니어가 리뷰하는 사용 사례가 늘어남
사내 툴이라 인원당 과금(人数課金)이 없어, QA 외 다른 영역으로 확장하기 쉬움
사내 OSS로서 다른 QA 팀에서도 PR(Pull Request)이 들어옴
yu-ga님의 최근 프로젝트에서는 테스트 실행의 약 8할을 AI가 담당함 (개인 프로젝트 기준 수치)
사람이 만지면서 느끼는 위화감을 포착하는 기회가 줄었다고 느낌
'테스트 케이스를 실행했다'와 '사용하기 편리함을 확인했다'는 별개의 문제임
앞으로는 구현부터 QA까지 AI가 루프(Loop)하고, 사람은 마지막에 종합적으로 리뷰하는 형태를 목표로 함
테스트 설계를 자동화하는 데 가장 중요한 것은 프로세스임
8단계로 정리: 사양 입력 → 사양 Q&A → 테스트 분석/설계 → 설계 리뷰 → 테스트 케이스 작성 → 케이스 리뷰 → 실행 → 결과 보고
테스트 분석/설계와 테스트 케이스 작성을 분리함
분석/설계 단계에서 '무엇을, 어떻게 확인할지'를 먼저 확정함
케이스 리뷰는 기대값과 절차만 보면 됨
리스크에 맞춰 두 가지 플로우를 준비함
풀(Full): 설계와 케이스의 리뷰가 필수임
라이트(Light): 중간 단계의 리뷰를 생략하고, 사양 입력, 대상 서비스 선택, AI 질문 답변으로 진행함. 결과물은 마지막에 종합적으로 확인할 수 있음
관점별로 '어떤 계층에서 볼지'와 '어떤 테스트 레벨로 볼지'를 판정함
테스트 레벨은 5단계: 유닛(Unit), 서비스 API, 백엔드 플로우, 컨트랙트(Contract), UI 플로우
낮은 레벨에서 충분히 커버하고, 높은 레벨에서는 대표적인 움직임만 봄. 같은 것을 위에서 반복하지 않음
판정 플로우는 문서로 만들어 QA 리뷰를 거쳐 합의한 후, MerQA에 구현함

• 결과물을 보여주기
• 처음에는 테스트 케이스만 나오고, 무엇을 보고 있는지 알 수 없었다.
• 테스트 분석 및 설계 결과도 출력하도록 했다.

• 근거 관점에서는 사양서의 단어를 그대로 사용하게 한다. 환각(Hallucination) 방지 대책.
• QA가 경험으로 사용하는 자료를 AI에게도 전달한다.
• 팀의 노하우(Knowledge)
• 과거 테스트 케이스 (몇 년 치까지 통합)
• 코드 정적 분석을 통한 기존 사양
• 사양서 링크 주소
• 관련 PR

• 관련 PR과 사양서가 상충할 경우, 어느 쪽이 맞는지 질문 형태로 출력한다.
• 과거 사례 임포트 기능으로, 처음부터 질 높은 케이스를 만들 수 있도록 했다.
• 판단할 수 없을 때 침묵하며 결정하게 하지 않는다.
• 애매하면 넓게 포괄하는 방향으로 기울인다 (층위가 불분명하면 양쪽 모두, 레벨이 불분명하면 하단부터).
• '확인 필요' 표시를 달고, 사람이 수정하면 사라지도록 한다.

• 자동화 팀은 1명. 엔지니어 역시 여러 프로젝트를 겸임하고 있어, 자동화 시간을 확보하기 어려웠다.
• 백엔드 테스트 도구가 팀마다 제각각이라 상황을 파악하기 어려웠다.
• 앱의 자동화율은 약 14% 정도였고, 성공률도 불안정했다.
• 당시 목표는 '각 팀이 자동 테스트를 작성하고 유지보수할 수 있는 상태'였다.

• 백엔드
• 도구를 Scenarigo로 통일하여, 주기적 실행 결과를 사내 대시보드에서 일원 관리한다.
• 자주 사용하는 짧은 시나리오를 공통 기반으로 정리했다.
• 기존 시나리오의 이관 및 신규 작성은 AI로 진행했다.

• 클라이언트
• 자동화율은 약 70%에 도달했다 (측정 방식이 당시와 다름).
• 최근에는 주기적 실행 성공률이 90%를 넘는 주가 늘고 있다.
• AI 에이전트가 시뮬레이터나 실기(실물 기기)를 조작하며, 화면을 보면서 구현 및 수정한다.

• 가장 큰 것은, 유지보수할 수 있는 사람이 늘어난 것이다.
• 기능을 변경한 본인이 그 테스트를 고칠 기회가 늘었다.
• 성공률 개선은 AI뿐만 아니라 협력 체제 덕분이다.

• 각 도메인의 QA가 자신들의 회귀 테스트(Regression Test)를 관리하는 체제를 만들기 시작했다.
• 4년 전의 이상에, 마침내 가까워졌다.

• 테스트를 만드는 것이 쉬워진 만큼, 계속 늘어나는 테스트를 어떻게 품질 보증(QA)에 활용할지가 새로운 과제다.
• 단순히 개수를 늘리는 것만으로는 효율화되지 않는다. 변경과 관련된 테스트를 골라 실행하는 것이 중요하다.
• 테스트를 '어떤 기능을 검증하고 있는지'가 알 수 있는 자산으로 관리하고 싶다.
• 최종적으로는 '이 변경에 이 테스트를 실행했기 때문에, 여기까지 확인했다'고 설명할 수 있는 상태를 목표로 한다.

• MerQA는 어떻게 만들었나요? (yu-ga님)
• 코드는 거의 AI가 작성하고 있다. 처음에는 직접 확인했지만, 모델 성능이 올라가면서 그 빈도가 줄었다.
• 자신이 가장 큰 사용자로서 사용하며, 사용하기 불편한 곳을 고치는 루프를 돌렸다.

• 정적 테스트의 정확도는요? (yu-ga님)
• Claude Opus 5.5로, 실패로 판정된 케이스 중 약 90%가 실제로 실패하고 있었다.
• 기대 결과가 모호한 케이스는 판별할 수 없다.

• AI로 실행하지 못한 나머지 20%는요? (yu-ga님)
• iOS 시뮬레이터에서 푸시 알림이 오지 않는 등, 환경의 제약 때문이다.
• 인증 등의 사정으로 테스트 데이터를 자동 준비하기 어려워 사람이 준비해야 했다.

• 테스트 레벨 판별 정확도는요? (komatsuna님)
• 상당히 좋다. 틀려도 설계 리뷰에서 고칠 수 있다.

• 토큰(Token) 절감의 비결은요?
• 과거 테스트 케이스 전체를 분석시키는 것이 가장 많은 토큰을 사용한다.
• 가까운 케이스만 골라서 전달하도록 하고 있다. 아직 과제다.

• 자동 테스트끼리 테스트 데이터가 충돌하지는 않나요? (충돌 여부)
• PR 단위로 환경을 분리하는 등, 데이터 기반이 갖춰져 있어 자동 테스트에서는 거의 발생하지 않는다.
• 환경을 분리하기 어려운 처리는 시간을 정해 환경을 빌린다.

• 제가 테스트를 설계했을 때도, 사양서만으로는 판단할 수 없는 부분이 있었다. AI가 모호한 점을 임의로 결정하지 않고 질문으로 되돌려주는 설계에 납득했다.
• '케이스를 실행했다는 것'과 '사용하기 편리함을 확인했다는 것은 별개'라는 이야기가 인상 깊었다. AI에게 실행을 맡겨도, 직접 만져보고 생각하는 시간은 소중히 하고 싶다.
• 자동화 속도뿐만 아니라, 테스트를 고칠 수 있는 사람이 늘어났다는 이야기가 좋았다. QA에만 의존하지 않고, 개발자도 함께 품질을 지탱할 수 있는 시스템을 구상하고 싶다.
• 2차 행사에도 참가하고 싶습니다!
• 일시: 2026년 11월 25일 (수) 19:00~
• 이벤트: Merpay Tech Talk ~~AI로 진화하는 QA 자동화, 그 메커니즘과 실전~~

AI 자동 생성 콘텐츠

원문 바로가기

[참가 보고] Merpay Tech Talk ~QA는 AI로 어떻게 진화할까? 메루카리 그룹의 AI × QA 실전~

요약

핵심 포인트

댓글