비기술 창업자가 자동화 QA를 요구해야 하는 이유

#automation #management #startup #testing

MVP를 출시하고 나서 사용자 피드백보다 버그 리포트가 먼저 쏟아진 경험이 있다면, 그건 개발팀의 실력 문제가 아닐 가능성이 높다. 테스트 없이 출시했기 때문이다.

비기술 창업자 입장에서 QA는 흔히 "개발자들이 알아서 처리하는 것"으로 여겨진다. 하지만 일정이 촉박할 때 가장 먼저 줄어드는 것도 QA 공수다. 문제는, 그 결과가 고스란히 창업자와 사용자에게 돌아온다는 점이다. 그래서 QA를 "요청하는 것"이 아니라 "요구하는 것"이 필요하다.

테스트 없는 MVP가 만드는 실제 위험

버그가 있는 MVP를 출시하면 단순히 사용자 경험이 나빠지는 데서 그치지 않는다. 초기 사용자는 재방문하지 않는다. 스타트업 초기 유저의 이탈은 데이터 포인트 손실이기도 하다.

더 구체적으로 보면:

회원가입 플로우 버그: 사용자가 가입 도중 이탈하면, 창업자는 이것이 UX 문제인지 버그인지 구분하기 어렵다.
결제 흐름 오류: 결제 완료 직전에 앱이 멈추면 단순한 버그를 넘어 신뢰 문제가 된다.
기기/OS 버전 불일치: 개발자의 환경에서는 완벽하게 동작하지만, 특정 Android 버전이나 Safari에서만 깨지는 경우는 수동 테스트로 잡기가 어렵다.

소프트웨어 개발에서 버그 수정 비용은 발견 시점이 늦어질수록 기하급수적으로 증가한다는 것은 오래된 업계 통설이다. IBM의 Systems Sciences Institute 연구에서도 production 단계에서 발견된 결함의 수정 비용이 설계 단계 대비 수 배에 달한다는 점을 지적한다. 일찍 잡을수록 싸다. 이것이 자동화 QA의 핵심 논리다.

IT 외주 개발 계약서에 QA 조항을 어떻게 명시해야 하는지 모른다면, 계약 전에 반드시 확인할 내용이 있다.

Playwright MCP와 자동화 QA가 실제로 하는 것

Playwright는 Microsoft가 만든 오픈소스 E2E(End-to-End) 테스트 프레임워크다. 브라우저를 코드로 제어해서 실제 사용자처럼 앱을 조작하고, 기대 동작과 다를 경우 테스트를 실패시킨다. 공식 문서에서 확인할 수 있듯이, Chromium·Firefox·WebKit 세 엔진을 동시에 지원하고, 모바일 뷰포트 시뮬레이션도 내장되어 있다.

MCP(Model Context Protocol)는 AI 에이전트가 도구와 통신하는 방식을 표준화한 프로토콜이다. Playwright MCP는 이 프로토콜을 통해 AI 에이전트가 브라우저를 직접 조작하고 테스트 시나리오를 생성·실행할 수 있도록 한다.

비기술 창업자에게 이것이 중요한 이유는 단순하다. 테스트를 작성하는 데 엔지니어 공수가 줄어든다. 기존에는 QA 시나리오를 테스트 코드로 옮기는 작업 자체가 병목이었다. Playwright MCP 환경에서는 AI가 시나리오 초안을 생성하고, 이를 실제 테스트로 실행하는 루프가 짧아진다.

예를 들어 회원가입 E2E 테스트는 이런 구조가 된다:

import { test, expect } from '@playwright/test';

test('회원가입 플로우 검증', async ({ page }) => {
  await page.goto('/signup');
  await page.fill('[name="email"]', 'test@example.com');
  await page.fill('[name="password"]', 'SecurePass123!');
  await page.click('button[type="submit"]');

  // 가입 완료 후 대시보드로 리디렉션 확인
  await expect(page).toHaveURL('/dashboard');
  await expect(page.locator('h1')).toContainText('환영합니다');
});

이 테스트는 CI 파이프라인에 연결되면 코드가 배포될 때마다 자동으로 실행된다. 사람이 직접 클릭해서 확인하지 않아도 된다.

Vina의 자동화 E2E 테스트 접근 방식

포텐랩 QA 담당 Vina가 프로젝트에서 구조화하는 방식을 설명하면 다음과 같다.

Step 1. 핵심 사용자 여정(Critical Path) 식별

모든 기능을 테스트하려면 공수가 과도하게 든다. 대신 앱이 제공해야 하는 핵심 흐름만 우선 추린다. 이커머스라면 "검색 → 상품 클릭 → 장바구니 → 결제"가 핵심이다. 이 여정이 깨지면 나머지 기능이 아무리 잘 동작해도 의미가 없다.

Step 2. Playwright 테스트 파일 구성

tests/
├── auth/
│   ├── signup.spec.ts
│   └── login.spec.ts
├── checkout/
│   ├── cart.spec.ts
│   └── payment.spec.ts
└── smoke/
    └── critical-path.spec.ts

smoke 폴더의 테스트는 배포마다 반드시 통과해야 하는 최소 기준점이다.

Step 3. CI 파이프라인 연결

GitHub Actions 기준으로 배포 전 단계에 테스트 실행을 강제한다:

name: QA Gate
on: [pull_request]

jobs:
  e2e:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci
      - run: npx playwright install --with-deps
      - run: npx playwright test tests/smoke/

이 설정이 있으면 PR(Pull Request)마다 smoke 테스트가 돌고, 실패하면 merge가 차단된다. 개발자가 "테스트했어요"라고 말해도, 파이프라인이 통과하지 않으면 배포할 수 없다.

Step 4. 실패 리포트를 사람이 읽을 수 있는 형식으로

Playwright는 --reporter=html 옵션으로 테스트 결과를 시각적 HTML 리포트로 생성한다. 어느 단계에서 어떤 요소가 예상과 달랐는지 스크린샷과 함께 기록된다. 창업자가 개발 언어를 몰라도, 어느 화면에서 무엇이 깨졌는지는 읽을 수 있다.

비기술 창업자가 외주 파트너를 평가할 때 어떤 기준을 적용해야 하는지는 벤더 기술 검증 체크리스트를 참고하면 도움이 된다.

AI 서브에이전트가 버그 탐지 루프를 단축하는 방식

포텐랩은 Claude Code Max를 팀 개발 환경 기본값으로 사용한다. 여기서 AI 서브에이전트(subagent)가 QA 과정에서 하는 역할은 단순 코드 생성이 아니다.

핵심은 오케스트레이션이다. 오케스트레이터 에이전트가 테스트 실패 로그를 분석하고, 관련 코드 파일을 검색하고, 수정 후보를 제안하는 과정을 서브에이전트에게 위임한다. 이 루프는 다음처럼 동작한다:

CI에서 테스트 실패 발생
오케스트레이터가 실패 로그와 해당 컴포넌트 코드를 서브에이전트에게 전달
서브에이전트가 원인 추정 및 수정 diff 생성
개발자가 diff를 검토하고 적용 여부 결정

이 방식이 흥미로운 이유는, 개발자가 디버깅에 쓰는 시간 중 많은 부분이 "어디서 왜 깨졌는지 파악하는 것"이기 때문이다. 에이전트가 그 탐색 과정을 먼저 수행하면, 개발자는 판단과 결정에만 집중할 수 있다.

TDD(Test-Driven Development) 원칙과 결합하면 더 견고해진다. 기능 구현 전에 테스트를 먼저 작성하면, AI가 생성하는 코드가 애초에 테스트 통과를 목표로 작성된다. 바이브 코딩 방식의 함정을 피하고 싶다면, 이 TDD + 자동화 QA 조합이 MVP를 프로덕션 수준으로 끌어올리는 구조적 방어선이 된다.

창업자가 개발 파트너에게 확인해야 할 QA 체크리스트

계약 전이든, 개발 중간이든, 다음을 직접 물어보는 것이 합리적이다:

자동화 E2E 테스트를 작성하는가? 단순히 "테스트합니다"가 아니라, Playwright 또는 동급 도구로 작성된 테스트 파일이 실제로 존재하는가.
CI 파이프라인에 QA 게이트가 있는가? 배포 전에 테스트가 자동으로 실행되고, 실패 시 배포가 막히는 구조인가.
창업자가 읽을 수 있는 테스트 결과물을 제공하는가? HTML 리포트, 스크린샷, 실패 로그 요약 중 어느 형태로든.
핵심 사용자 여정(critical path)에 대한 smoke 테스트가 별도로 구성되어 있는가?
인수인계 시 테스트 코드가 포함되는가? 개발이 끝났을 때 소스코드만 받으면, 다음 개발자가 QA 기준을 파악할 방법이 없다.

출시 전 전체 체크리스트가 필요하다면 IT 외주 QA 런칭 체크리스트도 함께 확인해보길 권한다.

자동화 QA는 개발팀에 대한 불신이 아니라, 창업자가 "제품이 동작한다"는 것을 숫자가 아닌 시스템으로 확인하는 방법이다. 포텐랩은 Playwright MCP 기반 E2E 자동 QA와 AI 서브에이전트 오케스트레이션을 팀 표준으로 운영하고 있다. MVP를 출시하기 전에, 혹은 지금 진행 중인 개발 프로젝트의 QA 구조를 점검하고 싶다면 dev@potenlab.dev로 문의하거나 포텐랩 웹사이트에서 무료 초기 상담을 신청할 수 있다.

더 보기: potenlab.dev