외주개발 테스트 자동화 가이드: MVP 출시 후 반복 버그를 줄이는 QA 범위와 견적 기준
외주개발 테스트 자동화 가이드: MVP 출시 후 반복 버그를 줄이는 QA 범위와 견적 기준
직접 답부터 하겠습니다. 외주개발 견적서의 ‘테스트 포함’이라는 문구만으로는 출시 후 반복 버그를 막기 어렵습니다. 발주사는 개발 착수 전에 ① 깨지면 안 되는 핵심 사용자 흐름, ② 수동 검수와 자동화 테스트의 경계, ③ 테스트 산출물 인수 기준, ④ 배포 후 버그 수정과 테스트 유지보수 책임을 별도 항목으로 정해야 합니다.
특히 예약, 결제, 매칭, 관리자 승인, SaaS 대시보드, CRM 자동화, AI 기능이 들어간 MVP는 기능 구현보다 ‘수정 후에도 기존 흐름이 계속 작동하는지’가 더 중요해지는 순간이 빠르게 옵니다. 첫 버전에서는 화면이 몇 개 없어 보여도 운영 정책이 바뀌고, 관리자 권한이 추가되고, 결제 실패 케이스가 생기면 매 배포마다 같은 기능을 사람이 반복 확인해야 합니다. 이때 회귀 테스트 목록과 자동화 기준이 없으면 유지보수 비용은 ‘버그 수정비’가 아니라 ‘매번 다시 확인하는 인건비’로 늘어납니다.
이 글은 대표, PM, 마케터, 운영 담당자가 외주사와 대화할 때 바로 사용할 수 있도록 QA 범위, Playwright·Cypress·Jest 같은 테스트 도구의 적용 기준, 견적 반영 방식, 계약서·인수인계·유지보수 조항을 실무 관점에서 정리합니다.
1. ‘테스트 포함’이 위험한 이유: QA, 검수, 회귀 테스트는 같은 말이 아닙니다
외주개발에서 가장 흔한 오해는 ‘개발사가 당연히 테스트해서 주겠지’입니다. 물론 개발자는 기능을 만들면서 기본 동작을 확인합니다. 그러나 그것이 곧 출시 가능한 QA, 인수 검수, 회귀 테스트 자동화를 의미하지는 않습니다. 발주사가 확인해야 할 것은 ‘테스트를 했는가’가 아니라 ‘어떤 기준으로, 어떤 산출물을 남겼는가’입니다.
| 구분 | 목적 | 발주사가 확인할 것 |
|---|---|---|
| 개발자 자체 확인 | 방금 구현한 기능이 의도대로 동작하는지 확인 | 개발 완료 보고만으로는 부족합니다. 재현 가능한 테스트 계정과 확인 절차가 필요합니다. |
| 인수 테스트 | 요구사항, 사용자 필요, 비즈니스 프로세스에 맞는지 판단 | ‘회원은 예약을 생성할 수 있다’가 아니라 ‘예약 가능 시간, 중복 예약, 취소 정책까지 충족한다’처럼 수용 기준이 필요합니다. |
| 회귀 테스트 | 변경 후 기존에 되던 기능이 깨지지 않았는지 확인 | 배포 전마다 반복 실행할 체크리스트와 자동화 대상이 필요합니다. |
| 단위·API 테스트 | 가격 계산, 권한, 상태 전환 같은 로직을 코드 수준에서 검증 | 프론트 화면이 없어도 백엔드 규칙이 맞는지 확인할 수 있어야 합니다. |
| E2E 자동화 | 사용자처럼 브라우저에서 핵심 흐름을 끝까지 실행 | 로그인부터 결제 완료, 관리자 승인, 알림 확인까지 연결된 흐름을 검증합니다. |
| CI 테스트 | 코드 변경 시 자동으로 테스트를 실행해 배포 전 실패를 감지 | GitHub Actions 등에서 실행 명령, 리포트, 실패 알림이 남아야 합니다. |
따라서 발주사는 견적 요청서에 ‘테스트 포함’이라고 쓰기보다 ‘핵심 흐름 8개에 대한 수동 인수 테스트 체크리스트 작성’, ‘결제·예약·권한 관련 API 테스트 작성’, ‘배포 전 E2E 자동화 5개 실행’처럼 범위를 분리해 요청해야 합니다. 계약 조항 자체를 먼저 정리하려면 외주개발 계약서 필수 조항 체크리스트도 함께 참고하면 좋습니다.
2. 테스트 자동화의 출발점은 도구가 아니라 핵심 시나리오입니다
Playwright, Cypress, Jest 중 무엇을 쓸지부터 정하면 대화가 기술 논쟁으로 흐릅니다. 발주사에게 더 중요한 질문은 ‘우리 서비스에서 깨지면 바로 손실이 나는 흐름은 무엇인가’입니다. 자동화는 이 흐름을 반복 가능한 검증 절차로 바꾸는 작업입니다.
발주사가 먼저 준비할 핵심 시나리오 예시
- 로그인·가입: 이메일 가입, 소셜 로그인, 비밀번호 재설정, 휴면·탈퇴 계정 처리
- 결제: 정상 결제, 결제 실패, 중복 요청, 영수증, 환불 요청, PG 테스트 모드
- 예약: 예약 가능 시간, 중복 예약 방지, 취소 마감, 관리자 확정, 알림 발송
- 매칭: 매칭 조건 입력, 후보 목록, 수락·거절, 재매칭, 상태 변경
- 관리자: 승인, 반려, 권한별 메뉴 접근, 데이터 수정 이력, 엑셀 다운로드
- SaaS 과금: 무료 플랜 제한, 유료 전환, 사용량 초과, 팀원 초대, 권한 변경
- CRM·자동화: 리드 생성, 단계 변경, 자동 알림, 담당자 배정, 중복 고객 병합
- AI 기능: 프롬프트 입력, 결과 저장, 금칙어·개인정보 처리, 실패 시 재시도 또는 대체 흐름
각 시나리오는 ‘정상 동작’만 쓰면 부족합니다. MVP에서 반복 버그를 줄이려면 최소한 정상 케이스, 실패 케이스, 권한 케이스, 데이터 경계 케이스를 나눠야 합니다. 예를 들어 예약 서비스라면 ‘사용자가 예약한다’가 아니라 ‘이미 예약된 시간에 다른 사용자가 예약을 시도하면 실패 메시지가 나오고 기존 예약은 유지된다’가 테스트 기준이 됩니다.
좋은 테스트 범위는 개발사가 임의로 추측한 기능 목록이 아니라, 발주사의 실제 운영 흐름을 기술적으로 검증 가능한 문장으로 바꾼 것입니다.
3. MVP 단계에서 어디까지 자동화해야 할까?
초기 MVP에서 모든 화면을 자동화하는 것은 대개 비효율적입니다. UI가 자주 바뀌는 단계에서는 테스트 코드도 함께 자주 깨집니다. 반대로 결제 금액, 권한, 예약 가능 여부, 관리자 승인 상태처럼 화면이 바뀌어도 비즈니스 규칙이 유지되어야 하는 영역은 초기에 테스트를 잡아두는 편이 좋습니다.
권장 우선순위
- 빌드·기본 테스트 자동 실행: 코드가 합쳐질 때 설치, 빌드, 기본 테스트가 통과하는지 확인합니다.
- 핵심 로직 단위 테스트: 가격 계산, 쿠폰, 권한, 상태 전환, 예약 가능 여부처럼 규칙이 명확한 부분부터 테스트합니다.
- 백엔드 API 테스트: 프론트 화면과 별개로 인증, 요청값 검증, 에러 응답, DB 상태 변경을 확인합니다.
- 핵심 E2E 흐름: 로그인 후 예약 생성, 결제 완료, 관리자 승인처럼 실제 사용자 경로를 브라우저에서 검증합니다.
- 배포 전 회귀 체크: 매 배포 전에 사람이 볼 항목과 자동으로 돌릴 항목을 구분합니다.
예산이 제한된 MVP라면 처음부터 수십 개 E2E 테스트를 만들기보다 ‘배포 전에 반드시 확인해야 하는 5~12개 수준의 핵심 경로’처럼 실행 가능한 묶음으로 시작하는 것이 현실적입니다. 이 숫자는 정답이 아니라 예산·일정·장애 비용에 따라 조정할 출발점입니다. 결제나 예약처럼 장애 비용이 큰 서비스는 더 적은 기능이라도 자동화 우선순위가 높고, 단순 소개형 웹사이트는 수동 검수와 시각 QA 중심으로 충분할 수 있습니다.
| 서비스 유형 | 우선 자동화할 흐름 | 수동 검수로 남겨도 되는 영역 | 주의할 점 |
|---|---|---|---|
| 기업 홈페이지·랜딩 리뉴얼 | 문의 폼 제출, 관리자 문의 확인, 주요 CTA 링크 | 문구, 이미지, 레이아웃 최종 감수 | 자동화보다 반응형·SEO·속도·폼 수신 확인이 중요할 수 있습니다. |
| 예약 서비스 MVP | 예약 생성, 중복 방지, 취소, 관리자 확정, 알림 | 예약 상세 화면의 미세한 UI 변경 | 시간대, 마감 시간, 동시 요청 테스트가 누락되기 쉽습니다. |
| 결제 포함 웹·앱 | 결제 성공·실패, 주문 상태, 환불 요청, 영수증 | 프로모션 배너, 안내 문구 | PG 테스트 모드, 웹훅 재처리, 중복 결제 방지 기준이 필요합니다. |
| 매칭 플랫폼 | 조건 입력, 후보 생성, 수락·거절, 상태 변경 | 추천 카드 UI 세부 표현 | 데이터가 쌓일수록 예외 케이스가 늘어 회귀 테스트 가치가 커집니다. |
| SaaS 관리자 대시보드 | 권한별 메뉴 접근, 팀원 초대, 플랜 제한, 데이터 CRUD | 차트 색상, 필터 위치 조정 | 관리자 화면은 내부용이라도 장애가 나면 운영 전체가 멈출 수 있습니다. |
| AI 기능 포함 서비스 | 입력 검증, 결과 저장, 실패 처리, 사용량 제한 | 응답 문장의 표현 품질은 별도 평가 | LLM 결과는 매번 달라질 수 있어 정답 비교보다 안전 조건과 후처리 검증이 중요합니다. |
4. Playwright·Cypress·Jest를 어떻게 구분해서 요구할까?
테스트 도구는 ‘누가 무엇을 검증하는가’에 따라 다르게 선택합니다. 발주사가 특정 도구를 강제할 필요는 없지만, 산출물과 실행 방식을 이해해야 견적서의 수준을 판단할 수 있습니다.
| 도구·방식 | 주로 검증하는 것 | 외주 계약서에 쓰는 방식 | 주의할 점 |
|---|---|---|---|
| Jest 또는 유사 단위 테스트 도구 | 함수, 계산 로직, 상태 전환, 일부 컴포넌트 | 가격 계산, 권한 판단, 예약 가능 여부 등 핵심 로직 단위 테스트 포함 | 화면 전체가 실제로 동작한다는 보장은 아닙니다. TypeScript 타입 체크는 별도 실행이 필요할 수 있습니다. |
| API 테스트 | 백엔드 엔드포인트, 인증, 요청값, 응답값, DB 상태 | 회원, 예약, 결제, 관리자 승인 API의 정상·실패 케이스 테스트 포함 | 외부 PG·문자·이메일은 샌드박스 또는 목 처리 기준이 필요합니다. |
| Playwright | 브라우저 기반 E2E, 여러 브라우저, trace 기반 실패 분석 | 핵심 사용자 흐름 E2E 자동화, CI 실행, HTML report와 trace 산출 | 녹화로 만든 테스트 코드는 초안일 뿐입니다. 안정적인 locator와 테스트 데이터 정리가 필요합니다. |
| Cypress | 프론트엔드 E2E, 컴포넌트 테스트, 브라우저 상호작용 | 로그인, 구매, 폼 제출 등 사용자 흐름 테스트와 CI 실행 포함 | E2E는 백엔드·테스트 인프라 준비가 필요해 단순 단위 테스트보다 유지 비용이 큽니다. |
| 수동 QA 체크리스트 | 디자인, 문구, 사용성, 예외 화면, 운영자 감수 | 브라우저·디바이스별 체크리스트와 결함 리포트 작성 | 사람이 반복 확인하므로 배포가 잦으면 비용과 누락 위험이 커집니다. |
공식 문서 관점에서도 E2E 테스트는 사용자가 실제로 앱을 쓰는 방식에 가깝지만, 백엔드와 외부 서비스 준비가 필요해 설정과 유지가 더 어렵습니다. 따라서 ‘E2E 자동화 100개’보다 ‘장애 비용이 큰 흐름 10개를 안정적으로 실행하고 실패 리포트를 남기는 구조’가 초기 외주개발에는 더 실용적입니다.
5. 견적서에는 ‘테스트 비용’이 아니라 작업 단위가 보여야 합니다
테스트 자동화를 요구하면 비용이 늘어납니다. 다만 그 비용이 비싼지 싼지는 ‘자동화 도구 이름’으로 판단할 수 없습니다. 같은 Playwright라도 단순 로그인 테스트 1개와 결제·예약·관리자 승인까지 연결된 E2E 테스트는 준비해야 할 데이터, 환경, 실패 분석 난이도가 다릅니다.
| 견적 항목 | 포함되어야 할 작업 | 발주사가 물어볼 질문 |
|---|---|---|
| QA 시나리오 설계 | 핵심 흐름 목록화, 정상·실패·권한 케이스 분리 | 우리 운영자가 확인해야 하는 업무 흐름이 반영됐나요? |
| 테스트 데이터 준비 | 테스트 계정, 관리자 권한, 샘플 상품·예약·결제 데이터 | 테스트를 다시 실행해도 데이터가 꼬이지 않나요? |
| 단위·API 테스트 작성 | 비즈니스 로직과 백엔드 응답 검증 | UI가 바뀌어도 유지되는 핵심 규칙을 검증하나요? |
| E2E 자동화 작성 | 브라우저에서 사용자 흐름 실행, 어설션, 실패 캡처 | 어떤 브라우저와 어떤 화면 크기에서 실행하나요? |
| CI 연동 | 테스트 명령, 환경 변수, 리포트 업로드, 실패 시 알림 | 배포 전 자동으로 실패를 막거나 최소한 확인할 수 있나요? |
| 테스트 안정화 | 불안정한 대기, 외부 API 의존성, 랜덤 데이터 문제 수정 | 가끔 실패하는 테스트를 누가 분석하고 고치나요? |
| 인수인계 문서 | 실행 방법, 테스트 계정, 폴더 구조, 실패 대응법 | 외주사가 빠져도 내부 또는 다른 업체가 실행할 수 있나요? |
견적서에서 피해야 할 표현은 ‘QA 포함’, ‘테스트 자동화 포함’처럼 범위가 보이지 않는 문장입니다. 더 나은 표현은 ‘회원가입·로그인·예약 생성·결제 성공·관리자 승인 5개 E2E 테스트를 Playwright로 작성하고, GitHub Actions에서 main 브랜치 병합 전 실행하며, 실패 시 HTML report와 trace를 산출한다’처럼 실행 가능한 문장입니다.
6. 계약서와 검수 기준에 꼭 넣어야 할 테스트 조항
테스트 자동화는 개발 산출물입니다. 따라서 소스코드와 마찬가지로 소유권, 저장소 접근권, 실행 환경, 유지보수 책임을 정해야 합니다. 특히 정부지원사업 MVP나 초기 스타트업 프로젝트에서는 결과보고서와 시연 영상만 남기고 테스트 코드는 인수하지 않는 경우가 있습니다. 이러면 출시 후 다른 개발자가 유지보수할 때 품질 기준을 다시 만들어야 합니다.
계약서에 넣을 수 있는 문장 예시
- 테스트 대상 핵심 흐름은 별첨 QA 시나리오 목록에 따른다.
- 자동화 테스트 코드는 본 프로젝트 소스 저장소에 포함하여 발주사에게 인수한다.
- 배포 전 실행할 테스트 명령과 CI 설정 파일을 제공한다.
- 테스트 계정, 관리자 권한, 샘플 데이터 생성 방법을 인수인계 문서에 포함한다.
- 외부 결제, 문자, 이메일, 지도 API 등은 테스트 모드 또는 목 처리 기준을 사전에 합의한다.
- 검수 중 발견된 결함은 심각도에 따라 수정 기한과 재검수 방식을 정한다.
- 기능 변경으로 인한 테스트 코드 수정은 유지보수 또는 추가 개발 범위로 별도 산정할 수 있다.
검수와 인수인계를 따로 정리하려면 외주개발 인수인계 체크리스트를 함께 확인해 보십시오. 테스트 코드, 테스트 데이터, CI 설정은 운영 문서와 함께 넘어와야 나중에 자산이 됩니다.
7. 출시 후 유지보수 책임: 버그 수정과 테스트 수정은 분리해야 합니다
출시 후 가장 자주 생기는 분쟁은 ‘이게 무상 하자보수인가, 추가 개발인가’입니다. 테스트 자동화가 있으면 이 기준을 더 명확히 만들 수 있습니다. 인수 당시 통과했던 테스트가 같은 조건에서 실패한다면 기존 기능 결함일 가능성이 높습니다. 반대로 운영 정책, 화면 구조, 권한 체계, 외부 API가 바뀌어 테스트가 실패한다면 테스트 코드 수정 자체가 유지보수 작업이 됩니다.
| 상황 | 해석 기준 | 권장 처리 |
|---|---|---|
| 인수 기준에 명시된 기능이 동일 조건에서 실패 | 하자보수 가능성이 높음 | 재현 절차와 테스트 리포트 기반으로 수정 요청 |
| 신규 정책 추가 후 기존 테스트 실패 | 요구사항 변경 가능성이 높음 | 기능 수정과 테스트 수정 견적을 함께 산정 |
| 외부 PG·문자 API 변경으로 실패 | 외부 의존성 변경 | 연동 수정, 테스트 모드 재설정, 운영 장애 기준 확인 |
| 테스트가 가끔만 실패 | 테스트 불안정 또는 환경 문제 | 대기 조건, 테스트 데이터, CI 자원, 외부 API 의존성 점검 |
| 운영자가 DB를 직접 수정해 데이터 꼬임 발생 | 운영 프로세스 문제 | 관리자 기능 보완, 권한 제한, 감사 로그, 데이터 복구 절차 검토 |
유지보수 계약을 맺을 때는 버그 수정 시간만 보지 말고 ‘회귀 테스트 실행’, ‘배포 전 검증’, ‘테스트 실패 분석’, ‘테스트 코드 업데이트’가 포함되는지 확인해야 합니다. 장애 대응 시간과 책임 범위는 외주개발 유지보수 SLA 설계 가이드처럼 별도 기준으로 정리하는 편이 좋습니다.
8. 발주사가 견적 요청 전에 준비할 체크리스트
외주사에게 ‘테스트 자동화도 포함해 주세요’라고 말하기 전에 아래 항목을 정리해두면 견적의 질이 달라집니다. 모든 항목을 완벽히 작성할 필요는 없지만, 모르는 부분을 빈칸으로 남겨 두면 외주사가 질문할 수 있습니다.
요구사항·운영 흐름
- 사용자 역할: 비회원, 회원, 관리자, 슈퍼관리자, 제휴사, 담당자 등
- 핵심 행동: 가입, 신청, 예약, 결제, 승인, 취소, 다운로드, 알림 확인
- 상태 값: 대기, 승인, 반려, 결제완료, 환불요청, 취소완료, 만료 등
- 권한 규칙: 누가 어떤 데이터를 보고 수정할 수 있는지
- 외부 연동: PG, 문자, 이메일, 지도, 회계, CRM, AI API, 사내 시스템
검수 기준
- 출시 전 반드시 통과해야 하는 시나리오 목록
- 지원 브라우저와 디바이스 범위
- 테스트 계정과 샘플 데이터 제공 방식
- 결함 심각도 기준: 차단, 높음, 보통, 낮음
- 수동 QA와 자동화 테스트의 역할 분리
- 배포 전 테스트 실행 시점과 담당자
산출물 기준
- 테스트 코드 저장 위치와 소유권
- 실행 명령: 예를 들어
npm test,npx playwright test처럼 재현 가능한 명령 - CI 설정 파일과 환경 변수 목록
- HTML report, 스크린샷, trace, 실패 로그 보관 방식
- 테스트 데이터 초기화 또는 시드 생성 방법
- 인수인계 문서와 재실행 방법
9. 외주사에게 꼭 물어볼 질문
좋은 개발사는 테스트 자동화를 무조건 많이 하자고 하지 않습니다. 예산과 출시 일정 안에서 장애 비용이 큰 흐름을 먼저 고르고, 바뀔 가능성이 큰 UI는 수동 검수로 남기는 식으로 균형을 잡습니다. 상담 때 아래 질문을 던져보면 업체의 품질 운영 수준을 비교할 수 있습니다.
- 이번 MVP에서 자동화해야 할 핵심 흐름을 몇 개로 보시나요? 그 이유는 무엇인가요?
- 수동 QA, 단위 테스트, API 테스트, E2E 테스트를 어떻게 나눌 계획인가요?
- 테스트 데이터는 어떻게 만들고, 반복 실행 시 어떻게 초기화하나요?
- 결제·문자·이메일 같은 외부 연동은 실제 호출, 샌드박스, 목 처리 중 무엇을 쓰나요?
- 테스트 실패 시 리포트, 스크린샷, trace 같은 증거가 남나요?
- CI에서 테스트가 언제 실행되나요? PR마다, 배포 전, 운영 배포 후 중 어디인가요?
- 테스트 코드도 발주사 저장소에 포함되나요?
- 출시 후 기능 변경이 있을 때 테스트 코드 수정은 유지보수 범위인가요, 별도 견적인가요?
- 자동화하지 않는 영역은 무엇이며, 그 이유는 무엇인가요?
- 테스트가 가끔 실패하는 경우 원인 분석과 안정화 책임은 누가 지나요?
이 질문에 대해 ‘저희가 알아서 합니다’만 반복한다면 위험 신호입니다. 반대로 ‘이 흐름은 장애 비용이 크니 자동화하고, 이 화면은 아직 UI가 바뀔 가능성이 높으니 수동 QA로 두자’고 설명하는 업체가 더 신뢰할 만합니다.
10. 테스트 자동화에서 자주 발생하는 실패 패턴
- 출시 마지막 주에 QA를 몰아서 한다: 일정이 밀리면 QA 시간이 가장 먼저 줄어듭니다. 핵심 시나리오는 개발 중간부터 확인해야 합니다.
- 스테이징 환경이 없다: 운영 DB나 실제 결제 환경에서 테스트하면 데이터 오염과 고객 피해가 발생할 수 있습니다.
- 테스트 데이터가 매번 달라진다: 오늘은 통과하고 내일은 실패하는 테스트가 됩니다. 시드 데이터와 초기화 절차가 필요합니다.
- 녹화 도구로 만든 코드를 그대로 둔다: 자동 생성 코드는 초안으로는 유용하지만, 안정적인 selector와 명확한 검증 문장을 사람이 보강해야 합니다.
- 화면 픽셀만 비교한다: 디자인 회귀 테스트가 필요한 경우도 있지만, MVP에서는 먼저 비즈니스 흐름과 데이터 상태가 맞는지 봐야 합니다.
- 테스트 커버리지 숫자만 본다: 커버리지가 높아도 결제 실패, 권한 우회, 중복 예약 같은 중요한 케이스가 빠질 수 있습니다.
- 테스트 코드 소유권을 놓친다: 테스트 자동화가 외주사 로컬 PC에만 있으면 인수인계된 것이 아닙니다.
- AI 생성 코드에 테스트가 없다: AI 코딩 도구로 구현 속도가 빨라질수록 사람이 의도한 비즈니스 규칙을 검증하는 테스트가 더 중요해집니다.
11. 참고한 기준과 문서
이 글은 특정 도구가 항상 우월하다고 주장하지 않습니다. 공식 문서에서 설명하는 테스트 유형과 CI·리포트 기능을 발주사 의사결정 관점으로 재구성했습니다.
- Playwright Auto-waiting: 자동 대기와 어설션 안정화 기준 참고
- Playwright Test generator: 테스트 녹화와 locator 생성 기능 참고
- Playwright Continuous Integration: CI 실행과 리포트 업로드 구조 참고
- Cypress Testing Types: E2E와 컴포넌트 테스트 비교 참고
- Cypress Continuous Integration: 커밋 기반 자동 테스트 흐름 참고
- Jest Getting Started: 단위 테스트와 TypeScript 프로젝트 주의점 참고
- ISTQB Regression Testing, ISTQB Acceptance Testing: 회귀 테스트와 인수 테스트 용어 기준 참고
FAQ
Q1. MVP 외주개발에서 테스트 자동화는 꼭 해야 하나요?
모든 화면을 자동화할 필요는 없습니다. 다만 로그인, 결제, 예약, 관리자 승인, 권한, 알림처럼 배포 때마다 깨지면 매출·운영에 직접 영향을 주는 흐름은 최소한 회귀 테스트 목록으로 정의하고, 반복 검수가 많은 흐름부터 자동화하는 것이 좋습니다.
Q2. Playwright와 Cypress 중 무엇을 계약서에 써야 하나요?
도구 이름보다 먼저 자동화할 사용자 흐름, 브라우저 범위, 실행 시점, 리포트 산출물을 정해야 합니다. 이미 외주사가 안정적으로 운영하는 도구가 있다면 그 도구를 쓰되, 테스트 코드와 CI 산출물을 발주사가 인수할 수 있어야 합니다.
Q3. 외주 견적서의 ‘테스트 포함’은 어디까지 확인해야 하나요?
수동 QA 1회인지, 체크리스트 작성인지, 단위·API 테스트인지, E2E 자동화와 CI 연동인지 분리해서 봐야 합니다. 견적서에는 테스트 대상 흐름, 환경, 실행 명령, 리포트, 유지보수 책임이 보여야 합니다.
Q4. 결제·예약 기능은 어떤 회귀 테스트를 자동화해야 하나요?
정상 결제와 정상 예약만으로는 부족합니다. 실패 결제, 중복 요청, 예약 마감, 취소·환불, 관리자 승인, 알림 실패, 권한 없는 접근, 외부 연동 재시도까지 우선순위를 정해야 합니다.
Q5. 출시 후 버그가 나오면 외주사가 무상으로 고쳐야 하나요?
인수 기준에 포함된 기능이 동일 조건에서 실패한다면 하자보수 범위로 볼 수 있습니다. 그러나 정책 변경, 신규 기능, 외부 API 변경, 운영 데이터 문제라면 유지보수 또는 추가 개발 범위가 될 수 있으므로 계약서에 심각도와 재현 기준을 정해야 합니다.
마무리: 테스트 자동화는 비용 항목이 아니라 운영 리스크 관리입니다
외주개발에서 좋은 테스트 자동화는 ‘코드를 더 많이 짜는 일’이 아닙니다. 대표와 운영자가 중요하게 보는 업무 흐름을 개발 산출물 안에 고정하고, 배포할 때마다 같은 기준으로 확인할 수 있게 만드는 일입니다. MVP라도 결제, 예약, 매칭, 관리자 업무, SaaS 과금, CRM 자동화, AI 기능처럼 장애 비용이 큰 서비스라면 견적 단계에서 QA 범위와 자동화 대상을 분리해 논의해야 합니다.
AgentMit은 단순 기능 구현뿐 아니라 기획 정리, UI, 백엔드, 관리자 화면, 자동화, AI 기능, 배포, 유지보수까지 연결해 MVP와 실서비스 개발 범위를 검토합니다. 외주 견적서에 ‘테스트 포함’이라고만 적혀 있어 불안하다면, 핵심 시나리오와 회귀 테스트 목록부터 함께 정리해 보십시오. 예약·매칭·결제·CRM·SaaS·AI 기능처럼 출시 후 수정이 잦은 서비스라면 AgentMit에 스코프 리뷰, MVP 견적, 테스트 포함 개발 범위 상담을 요청할 수 있습니다.
