티어시

2026 QA 자동화 솔루션 현황

티어시(T-ASSI) — Mon, 14 Sep 2026 16:11:04 +0900

QA 자동화는 단순히 반복 테스트를 대신 실행하는 수준에서 점차 범위가 넓어지고 있습니다.

기존에는 Selenium이나 Playwright와 같은 도구를 이용해

사람이 자동화 스크립트를 작성하는 방식이 일반적이었다면,

최근에는 자연어로 테스트를 생성하거나 변경된 화면에 맞춰

테스트를 수정하고, AI가 직접 테스트를 수행·분석하는 솔루션까지 등장하고 있습니다.

특히 2026년에는 AI 기반 테스트 생성, Self-healing, Agentic Testing, LLM 품질 평가 자동화 등이

주요 QA 자동화 영역으로 확대되고 있습니다.

mabl은 테스트 생성부터 실패 분석과 자동 복구까지 AI를 적용하고 있으며,

Momentic과 Katalon 등도 자연어·AI Agent 기반의 테스트 생성 및 실행 기능을 제공하고 있습니다.

Selenium, Playwright, Appium 등 개별 테스트 도구가 궁금하다면

[2026 QA 테스트 도구·툴 현황]에서 별도로 확인할 수 있습니다.

2026 QA 자동화 솔루션은 어디까지 왔을까?

자동화 영역	주요 기능	대표 솔루션
AI 테스트 생성	요구사항·자연어를 기반으로 테스트 케이스와 자동화 테스트 생성	Katalon, Testim, mabl 등
Self-healing 테스트	UI 변경 등으로 깨진 테스트를 자동 보정·유지	mabl, Testim 등
Agentic Testing	AI Agent가 테스트 생성·실행·분석 과정에 직접 참여	Momentic, Katalon, mabl 등
AI 기반 실패 분석	테스트 실패 원인 분석 및 수정·결함 처리 지원	Katalon, mabl 등
LLM 품질 평가·검증 자동화	생성형 AI와 챗봇의 응답 품질을 자동 평가	티벨 T-LENS 등

※ 하나의 솔루션이 여러 자동화 영역을 동시에 지원할 수 있습니다.

2026 주요 QA 자동화 솔루션

Katalon

웹·모바일·API 등의 테스트 자동화를 지원하며,

최근에는 AI Assistant를 통해 요구사항 정제, 테스트 생성, 실행, 실패 분석, 버그 등록까지 이어지는 QA 워크플로우 자동화를 확대하고 있습니다.

mabl

AI 기반 테스트 생성과 실행뿐 아니라 애플리케이션 변경에 따른 테스트 복구, 실패 원인 분석 등을 지원합니다.

최근에는 사람이 모든 테스트를 직접 작성하고 관리하는 방식에서 더 나아가 Agentic Testing을 중심으로 자동화 범위를 확대하고 있습니다.

Testim

자연어를 활용한 테스트 생성과 AI·ML 기반 Smart Locator를 활용해 UI 변경에 따른 테스트 유지보수 부담을 줄이는 데 초점을 맞춘 자동화 솔루션입니다.

자연어 프롬프트를 활용하는 Agentic Test Automation 기능도 제공하고 있습니다.

Momentic

웹과 모바일 환경의 E2E 테스트를 자연어로 작성하고,

AI가 테스트를 생성·실행·유지하는 방식의 자동화 플랫폼입니다.

테스트 실패 시 원인을 분석하고 제품 변화에 따라 테스트를 수정하는 등

AI Agent 기반 QA 자동화에 초점을 맞추고 있습니다.

Functionize

기능 테스트를 중심으로 AI를 활용해 테스트 자동화와 유지보수를 지원하는 플랫폼입니다.

반복적인 사용자 흐름을 자동화하고 애플리케이션 변화에 대응하는 방식으로

테스트 유지 비용을 낮추는 데 활용할 수 있습니다.

티벨 T-LENS

T-LENS(TBELL LLM Evaluation and Scoring System)는

생성형 AI와 LLM 기반 서비스의 품질을 자동으로 평가·검증하기 위한 티벨의 솔루션입니다.

기존 QA 자동화가 웹이나 앱의 기능 동작을 반복 검증하는 데 초점을 맞췄다면,

T-LENS는 AI가 생성하는 응답의 품질 자체를 자동으로 평가하는 영역을 다룹니다.

LLM-as-a-Judge 방식을 활용해 챗봇이나 생성형 AI 서비스의 응답을 정량·정성 평가하고, 결과를 점수와 평가 사유 형태로 관리합니다.

이를 통해 다음과 같은 검증을 자동화할 수 있습니다.

AI·챗봇 응답 품질 평가
서비스 시나리오별 End-to-End 검증
모델·버전 변경 전후 품질 비교
신규 LLM 적용 시 품질 안정성 확인
서비스별 평가 지표를 활용한 반복 검증

AI 서비스가 늘어나면서 QA 자동화의 대상 역시

기능 동작에서 AI 응답과 결과 품질까지 확대되고 있다는 사례로 볼 수 있습니다.

QA 자동화 솔루션, 무엇을 보고 선택해야 할까?

QA 자동화 솔루션은 기능이 많다고 해서 모든 프로젝트에 적합한 것은 아닙니다.

1. 무엇을 자동화하려는가?

: 가장 먼저 자동화의 대상을 구분해야 합니다.

반복적인 웹·앱 기능 테스트인지, 테스트 케이스 생성인지, 실패 분석인지, 또는 LLM 서비스의 응답 품질 평가인지에 따라 필요한 솔루션이 달라집니다.

2. 기존 테스트 환경과 연결할 수 있는가?

: 이미 자동화 테스트나 CI/CD 환경을 운영하고 있다면 기존 테스트 자산과 연계할 수 있는지 확인해야 합니다.

새로운 솔루션 도입으로 기존 테스트를 모두 다시 작성해야 한다면 초기 구축 비용과 유지보수 부담이 커질 수 있습니다.

3. 자동화 이후 유지보수는 어떻게 할 것인가?

: 자동화 테스트 역시 서비스가 변경되면 수정이 필요합니다.

화면이나 기능 변경이 잦다면 Self-healing이나 AI 기반 테스트 유지보수 기능이 실제 운영 효율에 영향을 줄 수 있습니다.

4. AI의 판단이 필요한 영역인가?

: 모든 테스트에 AI가 필요한 것은 아닙니다.

동일한 입력과 결과를 반복 확인하는 테스트는 기존 자동화 방식이 효율적일 수 있지만,

화면 변화에 대응하거나 자연어를 이해하고 결과 품질을 판단해야 하는 테스트에서는 AI 기반 자동화의 활용 범위가 커질 수 있습니다.

QA 자동화는 어디까지 가능할까?

2026년 QA 자동화는 단순한 테스트 실행 자동화를 넘어가고 있습니다.

테스트 작성

→ 테스트 실행

→ 변경 대응

→ 실패 분석

→ 품질 평가

까지 자동화 범위가 확장되고 있습니다.

특히 생성형 AI 서비스가 늘어나면서 앞으로는 소프트웨어가 정상적으로 동작하는지 확인하는 자동화뿐 아니라,

AI가 만들어낸 결과가 적절한지 평가하는 자동화도 QA의 중요한 영역이 될 가능성이 높습니다.

결국 중요한 것은 모든 테스트를 자동화하는 것이 아니라,

반복적으로 발생하는 QA 업무 중 어디까지 자동화했을 때 실제 효율을 높일 수 있는지 판단하는 것입니다.

자주 묻는 질문

QA 테스트 도구와 QA 자동화 솔루션은 무엇이 다른가요?

: Selenium이나 Playwright처럼 자동화 테스트를 구현하기 위한 개별 기술·도구가 있는 반면,

QA 자동화 솔루션은 테스트 생성과 실행, 유지보수, 실패 분석 등 보다 넓은 QA 업무를 자동화하는 플랫폼 형태로 제공되기도 합니다.

AI가 QA를 완전히 자동화할 수 있나요?

: 현재는 모든 QA 과정을 AI에 맡기기보다는 테스트 생성, 반복 실행, 변경 대응, 실패 분석 등 자동화 효과가 높은 업무에 AI를 활용하는 방식이 현실적입니다.

사용자 경험이나 비정형적인 결과처럼 맥락에 따른 판단이 필요한 영역에서는 여전히 사람의 검토가 중요합니다.

LLM 서비스도 QA 자동화가 가능한가요?

: 가능합니다. 일반 소프트웨어의 기능 동작을 확인하는 방식과는 다르지만, 평가 기준과 데이터셋을 구성하면 LLM의 응답 품질을 반복적으로 평가할 수 있습니다.

티벨의 T-LENS처럼 LLM-as-a-Judge를 활용해 생성형 AI 서비스의 응답을 자동 평가하고 결과를 관리하는 방식도 활용되고 있습니다.

2026 QA 테스트 도구·툴 현황

티어시(T-ASSI) — Mon, 14 Sep 2026 16:10:15 +0900

QA 업무에서 사용하는 테스트 도구는 하나로 정해져 있지 않습니다.

웹 UI를 자동화할 때 사용하는 도구와

모바일 앱, API, 성능, 디바이스 호환성, 테스트 케이스 관리를 위해 사용하는 도구는 서로 다릅니다.

따라서 QA 툴을 선택할 때는 단순히 많이 사용되는 도구를 고르기보다

무엇을 테스트하려는지를 먼저 구분하는 것이 중요합니다.

분야별 대표 QA 테스트 도구

테스트 분야	대표 도구	주요 용도
웹 UI·E2E 테스트	Selenium, Playwright, Cypress	웹 기능 및 사용자 흐름 자동화
모바일 앱 테스트	Appium	iOS·Android 앱 자동화
API 테스트	Postman, SoapUI	API 요청·응답 및 기능 검증
성능·부하 테스트	JMeter, k6	부하·응답속도·성능 검증
브라우저·디바이스 테스트	BrowserStack, TestMu AI	다양한 브라우저·실기기 환경 검증
통합 테스트 자동화	Katalon, TestComplete	웹·모바일·API 등 통합 자동화
테스트 관리	TestRail, Jira	테스트 케이스·결함·진행 현황 관리

같은 분야에서도 지원 환경과 자동화 방식, 사용 난이도가 다르기 때문에

프로젝트 환경에 따라 적합한 툴이 달라질 수 있습니다.

2026 주요 QA 테스트 도구 목록

Selenium

대표적인 오픈소스 웹 브라우저 자동화 도구로, 브라우저 기반 기능 테스트와 회귀 테스트 등에 활용됩니다.

공식 사이트: Selenium

Playwright

Microsoft가 개발하는 웹 자동화 프레임워크로 Chromium, Firefox, WebKit 기반의 크로스브라우저 테스트를 지원합니다.

공식 사이트: Playwright

Cypress

웹 애플리케이션의 E2E 테스트와 컴포넌트 테스트에 활용되는 JavaScript 기반 테스트 도구입니다.

공식 사이트: Cypress

Appium

iOS와 Android를 비롯한 다양한 앱 플랫폼의 UI 자동화를 지원하는 오픈소스 도구입니다.

공식 사이트: Appium

Postman

API 개발과 테스트에 널리 활용되는 플랫폼으로 API 요청·응답 검증과 자동화된 API 테스트를 지원합니다.

공식 사이트: Postman

SoapUI

REST, SOAP, GraphQL 등 다양한 API의 기능 테스트에 활용할 수 있는 API 테스트 도구입니다.

공식 사이트: SoapUI

Apache JMeter

웹과 API 등을 대상으로 부하를 발생시켜 시스템의 성능과 안정성을 확인하는 오픈소스 성능 테스트 도구입니다.

공식 사이트: Apache JMeter

스크립트 기반으로 부하·성능 테스트를 수행할 수 있는 개발자 친화적인 오픈소스 도구입니다.

공식 사이트: Grafana k6

BrowserStack

실제 브라우저와 모바일 디바이스 환경에서 웹·앱의 호환성과 동작을 확인할 수 있는 클라우드 테스트 플랫폼입니다.

공식 사이트: BrowserStack

TestMu AI

기존 LambdaTest가 2026년 TestMu AI로 브랜드를 전환한 테스트 클라우드 플랫폼으로, 브라우저·실기기 테스트와 자동화 환경 등을 제공합니다.

공식 사이트: TestMu AI

Katalon

웹·모바일·API·데스크톱 환경의 테스트 자동화를 하나의 플랫폼에서 지원하는 통합 테스트 자동화 도구입니다.

공식 사이트: Katalon

TestComplete

웹·모바일·데스크톱 애플리케이션의 UI 및 기능 테스트 자동화를 지원하는 상용 테스트 도구입니다.

공식 사이트: TestComplete

TestRail

테스트 케이스와 테스트 실행 결과, 진행 상황 등을 관리하기 위한 웹 기반 테스트 관리 도구입니다.

공식 사이트: TestRail

Jira

본래 프로젝트·이슈 관리 도구이지만 QA 과정에서는 발견된 결함을 등록하고 개발·QA 간 처리 상태를 관리하는 데 널리 활용됩니다.

공식 사이트: Jira

어떤 QA 테스트 툴을 선택해야 할까?

QA 툴을 선택할 때는 먼저 테스트하려는 대상과 목적을 정리해야 합니다.

1. 무엇을 테스트할 것인가?

: 웹 서비스라면 Selenium, Playwright, Cypress와 같은 웹 테스트 도구를 검토할 수 있고,

모바일 앱 자동화가 필요하다면 Appium과 같은 모바일 테스트 도구가 필요합니다.

API 검증이 목적이라면 Postman이나 SoapUI, 성능과 부하를 확인하려면

JMeter나 k6처럼 목적에 맞는 툴을 선택하는 것이 좋습니다.

2. 자동화가 필요한가?

: 반복적으로 수행하는 회귀 테스트는 자동화 효과가 높을 수 있지만,

한 번만 수행하는 테스트까지 모두 자동화할 필요는 없습니다.

자동화 대상과 수동 테스트 영역을 먼저 구분한 뒤 필요한 도구를 선택하는 것이 효율적입니다.

3. 누가 사용할 것인가?

: 개발자와 자동화 엔지니어가 직접 코드를 작성할 수 있는 환경이라면

Selenium, Playwright, Appium, k6와 같은 코드 기반 도구를 활용할 수 있습니다.

반대로 다양한 숙련도의 QA 인력이 함께 사용하는 경우에는

Katalon이나 TestComplete처럼 테스트 작성과 관리 기능을 통합한 도구도 검토할 수 있습니다.

4. 기존 개발 환경과 연결할 수 있는가?

: 테스트는 독립적으로 수행되는 경우보다 CI/CD, 이슈 관리, 테스트 관리 시스템과 연계되는 경우가 많습니다.

현재 사용하고 있는 개발 도구와 연결할 수 있는지, 자동 실행과 결과 관리가 가능한지도 함께 확인해야 합니다.

자주 묻는 질문

가장 많이 사용되는 QA 테스트 도구는 무엇인가요?

테스트 목적에 따라 다릅니다.

웹 자동화에는 Selenium과 Playwright, 모바일에는 Appium,

API 테스트에는 Postman, 성능 테스트에는 JMeter와 k6 등이 대표적으로 활용됩니다.

Selenium과 Playwright는 어떻게 다른가요?

둘 다 웹 브라우저 자동화에 활용할 수 있습니다.

Selenium은 오랜 기간 다양한 언어와 브라우저 환경에서 활용돼온 대표적인 자동화 도구이고,

Playwright는 Chromium·Firefox·WebKit을 하나의 API로 지원하며 자동 대기, 트레이싱 등

현대적인 웹 테스트 기능을 기본 제공한다는 차이가 있습니다.

모바일 앱 QA에는 어떤 도구를 사용하나요?

모바일 앱의 UI 자동화에는 Appium이 대표적으로 활용됩니다.

실제 여러 기기에서 테스트해야 한다면

BrowserStack이나 TestMu AI와 같은 실기기 클라우드 환경을 함께 사용할 수도 있습니다.

QA 툴을 하나만 사용하면 되나요?

대부분의 프로젝트에서는 그렇지 않습니다.

예를 들어 웹 UI는 Playwright, API는 Postman, 성능은 k6,

테스트 케이스 관리는 TestRail처럼 목적에 따라 여러 도구를 함께 사용하는 경우가 많습니다.

결국 QA 테스트 도구를 선택할 때 중요한 것은 가장 유명한 툴을 고르는 것이 아니라

현재 프로젝트에서 무엇을 검증해야 하는지를 먼저 정하는 것입니다.

2026 국내 QA(품질보증) 아웃소싱 업체 현황

티어시(T-ASSI) — Mon, 14 Sep 2026 16:09:19 +0900

서비스 출시 전 품질 검증이 필요하거나 내부 QA 인력이 부족할 때 QA 아웃소싱 업체를 활용할 수 있습니다.

다만 국내 SW QA 업체는 모두 같은 형태로 운영되지는 않습니다.

QA 아웃소싱을 중심으로 다양한 테스트를 수행하는 기업부터

테스트 컨설팅, 시험·인증, 테스트 자동화, 산업 특화 검증을 중심으로 하는 기업까지 사업 영역에 차이가 있습니다.

2026년 국내 SW QA 업체를 주요 사업 성격에 따라 살펴보면 다음과 같습니다.

국내 SW QA 업체 유형

구분	주요 특징	대표 업체
종합 SW QA 전문기업	QA 아웃소싱부터 다양한 테스트 영역을 폭넓게 수행	티벨(TBELL), 와이즈와이어즈, 어니컴 등
SW 테스트·컨설팅 전문기업	테스트 수행과 테스트 설계·프로세스 컨설팅	STA테스팅컨설팅 등
SW 시험·인증 전문기업	시험성적서, SW·AI·데이터 품질 평가 및 인증	와이즈스톤 등
테스트 자동화·QA 솔루션 전문기업	테스트 자동화 플랫폼과 QA 솔루션 중심	HBsmith, 앱테스트에이아이 등
고신뢰·산업 SW 검증 전문기업	자동차·국방·원자력 등 산업 SW 안전성·신뢰성 검증	슈어소프트테크 등

※ 한 업체가 여러 영역을 함께 제공할 수 있으며, 위 구분은 각 기업의 주요 사업 성격을 이해하기 위한 분류입니다.

저희 티벨(TBELL)은 QA 아웃소싱을 기반으로 Web/App, AI·IoT, Embedded, 금융, 자동차 등

다양한 환경의 소프트웨어 테스트와 테스트 자동화를 제공하는 국내 SW QA 전문기업입니다.

2026 국내 SW QA 아웃소싱 업체 목록

2026년 5월 기준 공개된 국내 SW 테스팅 업체 자료를 바탕으로

중복 업체를 제외하면 다음과 같은 42개 국내 QA·소프트웨어 테스트 업체를 확인할 수 있습니다.

업체명	홈페이지
노츠	공식 홈페이지
더테스트	공식 홈페이지
두루이디에스	공식 홈페이지
리드워크	공식 홈페이지
메리티움	공식 홈페이지
멘토스	공식 홈페이지
모바일나인	공식 홈페이지
브이플러스랩	공식 홈페이지
비케이소프트	공식 홈페이지
비트코리아	공식 홈페이지
슈어소프트테크	공식 홈페이지
스플렉스	공식 홈페이지
써니즈	홈페이지·블로그
씨너지큐브	공식 홈페이지
아이엑스씨(IXC)	공식 홈페이지
앱테스트에이아이	공식 홈페이지
어니컴	공식 홈페이지
에스이앤티	공식 홈페이지
엔글	공식 홈페이지
엠스텍	공식 홈페이지
와이드넷엔지니어링	공식 홈페이지
와이즈스톤	공식 홈페이지
와이즈와이어즈	공식 홈페이지
이비웨어	공식 홈페이지
인피닉	공식 홈페이지
지엔네트웍스	공식 홈페이지
큐드(QOOD)	공식 홈페이지
컴즈	공식 홈페이지
코드마인드	공식 홈페이지
코어프로세스	공식 홈페이지
콘크릿	공식 홈페이지
큐게임즈	공식 홈페이지
큐앤피플	공식 홈페이지
테스트웍스	공식 홈페이지
티벨(TBELL)	공식 홈페이지
티유	공식 홈페이지
포이텍	공식 홈페이지
프라임투비	공식 홈페이지
화인폰	공식 홈페이지
HBsmith	공식 홈페이지
NCL	공식 홈페이지
STA테스팅컨설팅	공식 홈페이지

※ 업체 및 홈페이지 정보는 2026년 5월 공개 자료를 기준으로 정리했으며,

이후 업체명이나 서비스 범위, 홈페이지 주소가 변경될 수 있습니다.

QA 아웃소싱 업체를 선택할 때 확인할 점

국내에 다양한 QA 업체가 있는 만큼 단순히 업체 규모나 비용만으로 선택하기는 어렵습니다.

우선 우리 서비스와 유사한 프로젝트를 수행한 경험이 있는지 확인하는 것이 좋습니다.

같은 소프트웨어 QA라도 웹·앱, 게임, 금융, AI, IoT, 자동차 등

프로젝트 성격에 따라 테스트 환경과 필요한 경험이 달라질 수 있습니다.

또한 기능 테스트뿐 아니라 호환성, 회귀, API, 성능 테스트나 테스트 자동화 등

현재 프로젝트에 필요한 테스트 범위를 지원할 수 있는지 확인해야 합니다.

프로젝트 기간과 필요한 QA 인원에 맞춰 실제 인력 투입이 가능한지,

테스트 케이스와 결함 리포트 등 결과물이 어떤 형태로 제공되는지도 함께 비교할 필요가 있습니다.

결국 QA 업체 선정에서 중요한 것은 단순히 유명한 업체를 찾는 것이 아니라

우리 프로젝트에 필요한 테스트 범위와 해당 업체의 수행 역량이 맞는지 확인하는 것입니다.

국내 QA 아웃소싱 업체에는 어떤 곳이 있을까?

2026년 기준 국내에는 티벨(TBELL), 와이즈와이어즈, 어니컴, STA테스팅컨설팅, 와이즈스톤, 슈어소프트테크, 테스트웍스, 리드워크 등을 포함해 다양한 SW QA 전문기업이 있습니다.

업체별로 QA 아웃소싱, 테스트 컨설팅, 시험·인증, 테스트 자동화, 산업 특화 검증 등

사업 영역에 차이가 있기 때문에 필요한 QA 범위를 먼저 정한 뒤 여러 업체를 비교하는 것이 좋습니다.

QA 아웃소싱이란? 어떤 업무를 맡길 수 있을까?

티어시(T-ASSI) — Mon, 14 Sep 2026 09:56:08 +0900

QA 아웃소싱이라고 하면

외부 인력이 정해진 테스트 케이스를 받아 테스트를 수행하는 업무를 먼저 떠올릴 수 있습니다.

하지만 프로젝트마다 내부에서 준비된 QA 환경과 필요한 역할은 다릅니다.

이미 테스트 범위와 기준이 정해져 있다면 테스트 수행 업무를 중심으로 맡길 수 있고,

테스트 기준부터 필요한 경우에는 테스트 범위 설정과 설계부터 QA 전반을 맡길 수도 있습니다.

또한 내부 QA 인력이 있더라도

특정 기간이나 테스트 영역에 필요한 업무만 외부에서 보완하는 방식으로 활용할 수 있습니다.

QA 아웃소싱은 프로젝트에 필요한 QA 업무의 일부 또는 전체를

외부 전문 인력이나 업체를 통해 수행하는 방식입니다.

프로젝트 상황에 따라 어떤 방식으로 QA 아웃소싱을 활용할 수 있는지 살펴보겠습니다.

1. 테스트 수행 중심의 QA 아웃소싱

이미 내부에 테스트 범위와 테스트 케이스가 준비되어 있다면

정해진 기준에 따라 실제 테스트를 수행하는 업무를 맡길 수 있습니다.

예를 들어 출시를 앞두고 확인해야 할 테스트 케이스가 많거나,

여러 환경에서 같은 테스트를 반복해야 하는 경우가 있습니다.

이때는

준비된 테스트 케이스 수행
반복 테스트
필요한 환경에서의 테스트 수행
테스트 결과 기록

등 실행 업무를 중심으로 외부 QA 인력을 활용할 수 있습니다.

즉, 무엇을 테스트할지는 정해져 있지만

이를 수행할 인력이 부족한 경우에 활용할 수 있는 방식입니다.

2. 테스트 설계부터 QA 전반을 맡기는 방식

테스트가 필요하다는 것은 알고 있지만

무엇을 어디까지 테스트해야 하는지 정해져 있지 않은 경우도 있습니다.

이 경우에는 단순히 테스트를 수행하는 것보다 먼저 요구사항과 변경 내용을 확인하고

테스트할 범위와 기준을 정하는 과정이 필요합니다.

프로젝트에 따라 QA 아웃소싱 범위를

요구사항 확인 → 테스트 범위 설정 → 테스트 설계

→ 테스트 수행 → 결함 관리 → 회귀 테스트 → 결과 정리

까지 확대할 수 있습니다.

내부에 별도의 QA 담당자가 없거나 테스트 기준을 새롭게 마련해야 한다면

테스트를 수행하는 업무뿐 아니라

QA를 준비하고 설계하는 단계부터 외부 전문 인력과 함께 진행할 수 있습니다.

3. 필요한 테스트 영역만 선택해서 맡기는 방식

QA 아웃소싱이 항상 QA 업무 전체를 외부에 맡기는 것을 의미하지는 않습니다.

내부에서 QA를 진행하고 있더라도 프로젝트 상황에 따라

일부 테스트에 추가적인 인력이나 환경이 필요할 수 있습니다.

예를 들어

출시 전 특정 기간에 테스트가 집중되는 경우
여러 환경에서 반복적인 테스트가 필요한 경우
대규모 업데이트로 회귀 테스트 범위가 늘어난 경우
내부 인력만으로 대응하기 어려운 테스트 영역이 있는 경우

등에는 필요한 기간이나 테스트 영역만 정해 외부 QA를 활용할 수 있습니다.

기존 QA 업무는 내부에서 유지하면서 부족한 부분만 보완하는 방식입니다.

QA 아웃소싱 활용 방식 한눈에 보기

활용 방식	적합한 상황	맡길 수 있는 업무
테스트 수행 중심	테스트 기준은 있지만 수행 인력이 부족한 경우	테스트 수행, 반복 테스트, 결과 기록
QA 전반 수행	테스트 범위와 기준부터 필요한 경우	범위 설정, 테스트 설계,수행, 결함·회귀 관리
특정 영역 수행	일부 영역이나 기간에 추가 지원이 필요한 경우	필요한 기능·환경·기간의 테스트

필요한 업무 범위에 맞는 QA 아웃소싱 활용 방법

QA 아웃소싱이라고 해서 모든 QA 업무를 외부에 맡겨야 하는 것은 아닙니다.

이미 테스트 기준과 환경이 준비되어 있다면 테스트 수행 업무를 중심으로 맡길 수 있고,

테스트 범위와 기준부터 필요한 경우에는 테스트 설계부터 수행과 결과 정리까지 범위를 넓힐 수 있습니다.

내부 QA 인력이 있는 경우에도 특정 기간이나 테스트 영역에 필요한 업무만 외부에서 보완할 수 있습니다.

따라서 QA 아웃소싱을 검토할 때는 먼저

현재 내부에서 수행할 수 있는 QA 업무와 추가로 필요한 업무를 구분하고,

이에 맞춰 맡길 범위를 정하는 것이 중요합니다.

QA 외주 vs 테스트 인력, 어떤 방식이 필요할까?

티어시(T-ASSI) — Mon, 14 Sep 2026 09:49:42 +0900

QA 업무를 보완하는 방법은 현재 내부에서 어디까지 QA를 수행할 수 있는지에 따라 달라집니다.

테스트 계획과 기준이 이미 마련되어 있다면 수행 인력을 추가하는 것으로 충분할 수 있지만,

테스트 범위 설정부터 결과 관리까지 필요한 경우에는 전문적인 QA 역할이 필요할 수 있습니다.

테스트 인력과 전문 QA 업체는 어떤 상황에서 필요한지 살펴보겠습니다.

1. 테스트 인력이 필요한 경우

테스트 인력은 말 그대로

정해진 기준에 따라 테스트를 수행할 사람이 부족할 때 활용하기 적합합니다.

예를 들어 내부에 이미

테스트 계획과 범위가 정해져 있고
테스트 케이스가 준비되어 있으며
테스트 환경이 구축되어 있고
발견된 결함을 관리할 담당자가 있는 경우

라면 추가 인력을 투입해 테스트 수행량을 늘릴 수 있습니다.

여러 디바이스에서 동일한 기능을 반복해서 확인하거나,

출시를 앞두고 정해진 테스트 케이스를 짧은 기간 안에 수행해야 하는 경우가 대표적입니다.

즉 무엇을 어떻게 테스트할지는 정해져 있고, 실제로 수행할 인원이 부족한 상황에 가깝습니다.

2. 전문 QA 업체가 필요한 경우

반대로 테스트를 해야 한다는 것은 알고 있지만

범위와 기준을 정하는 것부터 필요한 상황도 있습니다.

어떤 기능을 우선적으로 확인해야 하는지,

변경된 기능이 기존 서비스에 어디까지 영향을 미칠 수 있는지,

어떤 환경에서 테스트해야 하는지 등을 함께 판단해야 하는 경우입니다.

이때는 단순히 테스트를 수행하는 인력뿐 아니라

요구사항 및 서비스 구조 파악
테스트 범위와 우선순위 설정
테스트 시나리오·케이스 설계
테스트 수행
결함 등록 및 관리
회귀 테스트
테스트 결과 정리

등 QA 프로세스 전반을 설계하고 관리할 역할이 필요할 수 있습니다.

전문 QA 업체는 프로젝트의 상황과 필요한 범위에 따라

이러한 업무를 함께 수행한다는 점에서 단순한 테스트 인력 보강과 차이가 있습니다.

3. 같은 인원이라도 역할은 다를 수 있습니다

예를 들어 출시 전까지 1,000개의 테스트 케이스를 수행해야 한다고 가정해보겠습니다.

테스트 케이스와 환경이 모두 준비되어 있다면

필요한 것은 정해진 기간 안에 테스트를 수행할 인력일 가능성이 높습니다.

반면 테스트 케이스가 없고

어떤 기능을 우선적으로 확인해야 하는지도 정해지지 않았다면 이야기가 달라집니다.

이 경우에는 사람을 추가하는 것보다 먼저

테스트 범위를 정하고 기준을 만드는 작업이 필요합니다.

결국 필요한 인원 수만으로 판단하기보다

현재 내부에서 어디까지 준비되어 있고, 어떤 QA 업무가 비어 있는지를 먼저 확인해야 합니다.

테스트 인력과 전문 QA 업체를 비교하면

구분	테스트 인력 보강	전문 QA 업체 활용
주요 목적	테스트 수행 인력 확보	QA 업무 및 테스트 범위 보완
테스트 범위	내부에서 주로 결정	프로젝트에 따라 함께 검토
테스트 케이스	준비된 TC 중심으로 수행	필요 시 설계부터 진행
결함 관리	내부 프로세스에 따라 수행	등록·관리·결과 정리까지 가능
적합한 상황	QA 체계는 있으나 인력이 부족한 경우	QA 범위·기준·수행까지 보완이 필요한 경우

테스트 인력과 전문 QA 업체의 차이는 단순히 몇 명이 투입되는지에 있지 않습니다.

이미 내부에서 QA를 계획하고 관리할 수 있다면

필요한 만큼 테스트 인력을 보강하는 것으로 충분할 수 있습니다.

반대로 테스트 범위와 기준을 정하고, 수행 결과와 결함까지 관리해야 한다면

단순한 인력 보강보다 QA 프로세스 전체를 수행할 수 있는 역할이 필요한 상황에 가깝습니다.

결국 판단 기준은 ‘몇 명이 더 필요한가’보다

‘현재 우리 팀에서 어떤 QA 업무까지 수행할 수 있는가’에 있습니다.

QA 인력이 부족할 때 해결하는 3가지 방법

티어시(T-ASSI) — Mon, 14 Sep 2026 09:42:44 +0900

테스트해야 할 기능은 늘어나는데 QA 인력은 그대로인 경우가 있습니다.

출시 일정은 정해져 있고, 새로운 기능과 수정 사항은 계속 추가되다 보면

한정된 QA 인력으로 모든 범위를 확인하기 어려워집니다.

이럴 때 단순히 테스트 항목을 줄이기보다

현재 인력과 일정, 필요한 테스트 범위에 따라 QA를 어떻게 보완할지 판단할 필요가 있습니다.

QA 인력이 부족할 때 고려할 수 있는 방법을 세 가지로 나누어 살펴보겠습니다.

1. 테스트 범위와 우선순위를 조정합니다

QA 인력을 바로 늘리기 어렵다면 먼저 현재 테스트 범위를 다시 확인할 수 있습니다.

모든 기능을 같은 수준으로 테스트하기보다

서비스에 미치는 영향과 변경 범위를 기준으로 우선순위를 정하는 방식입니다.

예를 들어

로그인·결제 등 서비스의 주요 기능
이번 배포에서 새롭게 추가되거나 변경된 기능
변경으로 영향을 받을 가능성이 높은 기존 기능
이전에 결함이 반복적으로 발생했던 영역

등을 우선적으로 확인할 수 있습니다.

다만 테스트 범위를 줄이는 것은

한정된 리소스를 중요한 영역에 집중하는 방법이지, 테스트 자체를 생략하는 방법은 아닙니다.

제외된 범위에서 발생할 수 있는 위험까지 함께 고려해야 합니다.

2. 필요한 기간에 테스트 인력을 보강합니다

특정 프로젝트나 출시 일정에 일시적으로 QA 업무가 집중된다면

필요한 기간 동안 테스트 인력을 추가하는 방법도 있습니다.

정해진 테스트 케이스가 있고 수행해야 할 범위가 명확하다면

인력을 보강해 반복적인 기능 테스트나 디바이스별 확인 등을 나누어 진행할 수 있습니다.

특히 테스트 기준과 방법은 내부에서 이미 갖추고 있지만

이를 수행할 인력이 부족한 경우 활용하기 적합합니다.

반면 테스트 범위나 기준부터 정해야 하는 상황이라면

단순히 인원만 늘리는 것으로는 부족할 수 있습니다.

인력이 늘어나더라도 무엇을 어떻게 확인해야 하는지가 명확하지 않으면

담당자마다 테스트 결과가 달라질 수 있기 때문입니다.

3. 전문 QA 업체를 활용합니다

내부에서 테스트 범위를 설계하거나 여러 환경을 검증하기 어렵다면

전문 QA 업체를 통해 필요한 영역을 보완할 수 있습니다.

단순히 테스트를 수행할 인력을 추가하는 것과 달리 프로젝트 상황에 따라

요구사항 및 테스트 범위 검토
테스트 시나리오·테스트 케이스 설계
기능 및 예외 상황 테스트
다양한 디바이스·OS·브라우저 환경 테스트
결함 관리 및 회귀 테스트
테스트 결과 정리

등 QA 업무 전반을 함께 진행할 수 있습니다.

특히 내부 QA 인력이 부족하거나 일정 기간 많은 테스트가 필요한 경우,

또는 내부에서 확보하기 어려운 테스트 환경과 경험이 필요한 경우 검토할 수 있습니다.

세 가지 방법을 비교하면

방법	적합한 상황	확인할 점
테스트 우선순위 조정	인력과 일정이 제한적일 때	제외되는 테스트 범위와 위험
테스트 인력 보강	테스트 기준은 있지만 수행 인력이 부족할 때	업무 분배와 테스트 기준
전문 QA 업체 활용	범위 설계부터 테스트 수행·관리까지 보완이 필요할 때	필요한 QA 범위와 역할

QA 인력이 부족하다고 해서 모든 상황에서 같은 방법이 필요한 것은 아닙니다.

이미 테스트 체계가 갖춰져 있다면 수행 인력을 보강하는 것으로 해결할 수 있고,

테스트 범위와 기준을 잡는 것부터 어려운 상황이라면

필요한 QA 업무 자체를 함께 보완해야 할 수 있습니다.

결국 먼저 확인해야 할 것은 현재 부족한 것이 단순히 테스트를 수행할 ‘인원’인지,

테스트를 계획하고 관리하는 ‘QA 역량’까지 포함하는지입니다.

QA 체크리스트, 우리 팀은 제대로 테스트하고 있을까?

티어시(T-ASSI) — Mon, 14 Sep 2026 09:36:25 +0900

테스트는 하고 있는데, 지금 방식으로 충분한 걸까?

QA를 진행하고 있더라도 테스트 범위와 기준이 명확하지 않거나,

일정에 따라 확인하는 항목이 달라지는 경우가 있습니다.

특히 기능과 업데이트가 늘어날수록

단순히 테스트를 하고 있다는 것보다 어떤 기준과 범위로 QA가 진행되고 있는지가 중요해집니다.

현재 우리 팀의 QA가 어떻게 진행되고 있는지 몇 가지 항목으로 확인해보겠습니다.

1. QA가 항상 출시 직전에 시작된다

개발 일정이 밀리다 보면 자연스럽게 QA 일정도 뒤로 밀립니다.

문제는 출시를 앞두고 짧은 기간 안에

많은 기능을 확인해야 하는 상황이 반복된다는 점입니다.

이 경우 새로 개발된 기능을 확인하는 데 집중하게 되면서 기

존 기능의 영향 범위나 다양한 사용 환경까지 충분히 테스트하기 어려울 수 있습니다.

QA 기간이 매번 출시 직전에 몰리고 있다면

테스트 범위가 일정에 따라 달라지고 있지는 않은지 확인할 필요가 있습니다.

2. 테스트 범위가 담당자마다 달라진다

같은 기능을 테스트하더라도 담당자에 따라 확인하는 항목이 달라질 수 있습니다.

한 사람은 정상 동작 위주로 확인하고,

다른 사람은 예외 상황이나 연결된 기능까지 확인하는 식입니다.

테스트 범위와 기준이 명확하지 않으면

누가 테스트하느냐에 따라 확인되는 품질의 범위도 달라질 수 있습니다.

테스트 케이스나 체크리스트가 있다면

현재 서비스와 맞게 관리되고 있는지도 함께 확인해야 합니다.

3. 변경된 기능만 확인하고 테스트를 끝낸다

기능 하나를 수정했다고 해서 영향이 그 기능에만 머무르는 것은 아닙니다.

예를 들어 로그인 인증 로직이 변경됐다면

로그인뿐 아니라 회원가입, 비밀번호 변경, 자동 로그인 등

연결된 기능에도 영향을 줄 수 있습니다.

따라서 변경된 기능을 확인한 뒤에는

영향을 받을 수 있는 기존 기능까지 범위를 넓혀 회귀 테스트가 필요한지 판단해야 합니다.

수정된 화면이나 기능만 확인하는 방식이 반복되고 있다면 예상하지 못한 영역에서 문제가 발생할 가능성이 있습니다.

4. 테스트 환경이 한정되어 있다

개발 환경에서는 정상적으로 동작하지만

실제 사용자 환경에서는 문제가 발생하는 경우가 있습니다.

특히 웹과 앱 서비스는

브라우저와 버전
OS와 버전
모바일 디바이스
화면 크기
계정 및 사용자 권한

등에 따라 서로 다른 문제가 나타날 수 있습니다.

따라서 서비스가 실제로 사용되는 환경과 비교했을 때

현재 QA에서 확인하고 있는 테스트 환경이 충분한지 살펴볼 필요가 있습니다.

5. 발견한 결함과 테스트 결과가 제대로 남지 않는다

테스트 과정에서 문제를 발견하고 수정했더라도

기록이 남아 있지 않으면 이후 비슷한 문제가 발생했을 때

다시 처음부터 확인해야 합니다.

어떤 환경에서 문제가 발생했는지, 어떻게 수정됐는지, 어떤 기능까지

다시 테스트했는지 등의 기록은

이후 QA에서도 활용할 수 있습니다.

테스트 결과와 결함 이력이 관리되고 있어야

반복적으로 발생하는 문제나 자주 영향을 받는 기능도 파악하기 쉬워집니다.

우리 팀의 QA를 확인해보면

확인 항목	체크
QA 일정이 항상 출시 직전에 몰린다	□
담당자마다 테스트하는 범위가 다르다	□
테스트 케이스가 없거나 최신 상태가 아니다	□
변경된 기능만 확인하고 테스트를 종료한다	□
회귀 테스트 범위가 명확하지 않다	□
브라우저·OS·디바이스 등 테스트 환경이 제한적이다	□
일정이 부족하면 테스트 범위부터 줄어든다	□
결함과 테스트 결과가 체계적으로 관리되지 않는다	□

체크되는 항목이 있다고 해서 현재 QA가 잘못되고 있다는 의미는 아닙니다.

다만 여러 항목이 반복적으로 나타난다면 QA를 수행하고 있는 것과 별개로

현재 인력과 일정 안에서 필요한 테스트 범위를 충분히 확보하고 있는지 살펴볼 필요가 있습니다.

서비스가 커지고 기능과 사용 환경이 다양해질수록 QA에서 확인해야 할 범위 역시 함께 늘어납니다.

결국 중요한 것은 현재의 QA 방식이

우리 서비스에서 발생할 수 있는 주요 문제를 충분히 확인할 수 있는 수준인지입니다.

QA 프로세스, 개발 단계별로 언제 시작할까?

티어시(T-ASSI) — Mon, 14 Sep 2026 09:21:18 +0900

"QA는 개발이 끝난 다음에 시작하면 되는 걸까?"

프로젝트에서 QA 일정을 잡다 보면 한 번쯤 고민하게 되는 부분입니다.

실제로 QA를 개발 완료 후 진행되는 테스트 단계로 생각하는 경우가 많지만,

QA가 언제부터 참여하느냐에 따라 확인할 수 있는 문제의 범위도 달라집니다.

그렇다면 QA는 어느 시점부터 시작하는 것이 좋을지,

개발 단계에 따라 살펴보겠습니다.

1. 기획·요구사항 단계 — 테스트할 기준을 확인합니다

QA는 실제 개발이 시작되기 전부터 참여할 수 있습니다.

기획서나 요구사항 정의서를 검토하면서

기능의 동작 조건과 예외 상황이 명확하게 정의되어 있는지 확인합니다.

예를 들어 비밀번호 찾기 기능이 있다면 단순히 비밀번호를 변경할 수 있다는 요구사항뿐 아니라,

본인 인증은 어떤 방식으로 진행하는지
인증번호의 유효시간은 얼마인지
인증에 반복해서 실패하면 어떻게 처리하는지
기존 비밀번호와 동일하게 변경할 수 있는지

등 실제 테스트에서 판단 기준이 될 조건까지 확인할 필요가 있습니다.

이 단계에서 모호하거나 누락된 조건을 확인하면

개발 이후 요구사항을 다시 해석하거나 기능을 수정하는 상황을 줄일 수 있습니다.

2. 개발 단계 — 변경 범위와 테스트를 준비합니다

개발이 진행되는 동안에는 구현이 끝날 때까지 기다리기보다

변경되는 기능과 영향 범위를 파악하고 테스트를 준비할 수 있습니다.

새로운 기능이 기존 기능과 어떻게 연결되는지 확인하고,

이를 바탕으로 테스트 시나리오와 테스트 케이스를 설계합니다.

예를 들어 결제 방식이 추가된다면 결제 화면만 보는 것이 아니라

장바구니, 쿠폰, 주문 생성, 결제 취소처럼 연결된 기능에 미칠 영향도 함께 고려해야 합니다.

개발과 동시에 테스트를 준비하면 기능 구현이 끝난 뒤

테스트 범위를 처음부터 정하는 시간을 줄이고, 테스트가 필요한 영역을 미리 구체화할 수 있습니다.

3. 테스트 단계 — 실제 환경에서 품질을 확인합니다

기능 구현이 완료되면 준비한 테스트 케이스를 기준으로 본격적인 테스트를 진행합니다.

정상적인 기능 동작뿐 아니라 예외 상황과 기능 간 연동, 브라우저·OS·디바이스 등

실제 사용자가 서비스를 이용할 수 있는 다양한 환경을 함께 확인합니다.

발견된 결함은 발생 환경과 재현 절차, 기대 결과와 실제 결과 등을 기록하여 관리하고,

수정된 이후에는 정상적으로 해결됐는지 다시 확인합니다.

이 단계에서는 단순히 많은 테스트를 수행하는 것보다

서비스의 중요 기능과 변경 범위를 고려해 필요한 테스트가 충분히 이루어지고 있는지 확인하는 것이 중요합니다.

4. 출시 전·후 — 변경으로 인한 영향을 다시 확인합니다

결함 수정과 기능 변경이 반복되면 기존에 정상적으로 동작하던 기능에도 영향을 줄 수 있습니다.

따라서 출시 전에는 주요 기능을 중심으로 회귀 테스트(Regression Test)를 진행하여

변경 사항으로 인해 새로운 문제가 발생하지 않았는지 확인합니다.

서비스가 출시된 이후에도 실제 운영 환경에서 발견된 문제와 사용자 피드백,

이후 업데이트 내용을 바탕으로 다음 테스트에서 확인해야 할 범위를 조정할 수 있습니다.

서비스가 지속적으로 업데이트된다면

QA 역시 한 번의 테스트가 아니라 변경과 함께 반복되는 과정이 됩니다.

개발 단계별 QA 업무를 정리하면

개발 단계	주요 QA 업무
기획·요구사항	요구사항 검토, 누락·예외 조건 확인
개발	변경·영향 범위 파악, 테스트 케이스 준비
테스트	기능·환경별 테스트, 결함 등록 및 관리
출시 전	수정 사항 확인, 주요 기능 회귀 테스트
출시 후	운영 이슈 확인, 다음 테스트 범위 반영

QA는 개발이 끝나는 시점부터 시작되는 것이 아니라,

기획부터 개발, 테스트, 출시까지 각 단계에서 확인해야 할 대상과 역할이 달라지는 과정입니다.

언제 QA를 시작하느냐에 따라

테스트 단계에서 확인할 수 있는 범위와 준비 수준도 달라질 수 있습니다.

QA 업무란? 실제 프로젝트에서 하는 일

티어시(T-ASSI) — Mon, 14 Sep 2026 09:19:22 +0900

QA 업무라고 하면 보통 개발된 기능을 테스트하고 버그를 찾는 일을 먼저 떠올립니다.

테스트는 QA의 중요한 업무 중 하나지만, 실제 프로젝트에서 QA가 하는 일은 이보다 조금 더 넓습니다.

요구사항을 검토하고, 테스트 범위를 정하고, 테스트 케이스를 설계하고,

발견된 결함과 수정 결과를 관리하는 것까지 QA 업무에 포함됩니다.

실제 프로젝트에서는 QA가 어떤 일을 하는지 살펴보겠습니다.

1. 무엇을 테스트해야 하는지 먼저 확인합니다

QA는 개발된 기능을 바로 테스트하기보다

먼저 요구사항과 변경된 기능을 확인하고 테스트할 범위를 정합니다.

예를 들어 회원가입 기능이라면 단순히 가입이 되는지만 확인하는 것이 아닙니다.

이미 가입된 이메일을 입력하면 어떻게 되는지
비밀번호에는 어떤 조건이 있는지
인증번호의 유효시간은 얼마인지
인증에 반복해서 실패하면 어떻게 처리되는지

이처럼 요구사항을 기준으로 정상적인 사용 흐름과 예외 상황을 확인하고,

이번 테스트에서 무엇을 검증해야 하는지 구체화합니다.

요구사항이 모호하거나 빠진 조건이 있다면

테스트를 시작하기 전에 확인하는 것도 이 과정에서 이루어집니다.

2. 테스트 케이스를 설계합니다

확인해야 할 범위가 정해졌다면 실제 테스트에 사용할 테스트 케이스(Test Case)를 작성합니다.

테스트 케이스에는 일반적으로 테스트 조건과 수행 절차, 예상 결과 등이 포함됩니다.

로그인 기능이라면 정상 로그인뿐 아니라

잘못된 비밀번호 입력
존재하지 않는 계정 입력
비활성 계정으로 로그인
필수 입력값 누락

등 여러 상황을 함께 확인할 수 있습니다.

누가 테스트하더라도 같은 기준으로 결과를 판단할 수 있도록 만드는 것이

테스트 케이스의 중요한 역할입니다.

3. 실제 환경에서 테스트하고 결함을 관리합니다

테스트 케이스를 기준으로 기능을 직접 실행하면서

예상한 결과와 실제 결과가 일치하는지 확인합니다.

웹이나 앱 서비스라면 기능뿐 아니라

브라우저, OS, 디바이스, 계정 권한 등 실제 사용 환경의 차이도 함께 고려해야 합니다.

문제가 발견되면 개발자가 같은 현상을 확인할 수 있도록

발생 환경, 재현 절차, 기대 결과와 실제 결과를 기록하고,

서비스에 미치는 영향에 따라 심각도와 처리 우선순위를 구분하기도 합니다.

즉 QA는 단순히 버그를 찾는 것에서 끝나는 것이 아니라,

발견된 문제를 재현하고 수정할 수 있는 형태로 관리하는 역할까지 수행합니다.

4. 수정된 기능과 기존 기능을 다시 확인합니다

발견된 문제가 수정되면 해당 문제가 정상적으로 해결됐는지 다시 확인합니다.

하지만 하나의 기능을 수정하면서 연결된 기존 기능에 영향을 줄 수도 있기 때문에

필요한 범위의 회귀 테스트(Regression Test)도 진행합니다.

예를 들어 로그인 인증 로직이 변경됐다면 로그인만 다시 확인하는 것이 아니라

회원가입, 비밀번호 변경, 자동 로그인처럼 같은 인증 로직과 연결된 기능에도 문제가 없는지 확인할 수 있습니다.

즉 수정된 부분만 보는 것이 아니라

변경으로 영향을 받을 수 있는 범위까지 함께 확인하는 것이 중요합니다.

QA 업무를 정리하면

실제 프로젝트에서 이루어지는 QA 업무는 다음과 같이 정리할 수 있습니다.

단계	주요 QA 업무
요구사항·범위 확인	요구사항 검토, 테스트 범위 및 우선순위 설정
테스트 설계	테스트 시나리오 및 테스트 케이스 작성
테스트 수행	기능 및 다양한 사용 환경에서 동작 확인
결함 관리	결함 기록, 재현 정보 전달, 수정 상태 확인
회귀 테스트	수정 사항 및 기존 기능 영향 확인
결과 정리	테스트 결과와 남아 있는 이슈 정리

결국 QA 업무는 개발이 끝난 서비스를 한 번 확인하는 작업이 아니라,

무엇을 어떤 기준으로 테스트할지 정하고 발견된 문제와 수정 결과까지 지속적으로 확인하는 과정입니다.

서비스의 기능과 사용 환경이 다양해질수록 테스트해야 할 범위는 넓어지고,

이를 일정한 기준으로 관리하는 일도 중요해집니다.

따라서 중요한 것은 우리 서비스에 필요한 테스트 범위를 충분히 검증하고

품질을 지속적으로 관리할 수 있는 QA 체계를 갖추고 있는지 확인하는 것입니다.

버그 생산 공장 ACH — Meta의 AI 테스트 자동화

티어시(T-ASSI) — Fri, 11 Sep 2026 13:06:37 +0900

일부러 결함을 만들어, 기존 테스트가 놓치는 빈틈을 찾는 방법.

테스트를 모두 실행했고,

결과도 전부 통과했다.

그렇다면 충분히 검증됐다고 볼 수 있을까?

테스트가 통과했다는 것은
이미 만들어진 테스트에서 문제가 발견되지 않았다는 뜻이다.

하지만 실제로 문제가 생겼을 때
지금의 테스트가 그 문제까지 잡아낼 수 있는지는 다른 문제다.

Meta는 이를 확인하기 위해
오히려 코드에 일부러 결함을 만들어 넣었다.

버그를 찾기 위해, 왜 버그를 먼저 만들었을까?

Meta의 ACH 사례를 통해
AI로 기존 테스트의 빈틈을 확인하고 보완하는 과정을 살펴본다.

[목차]

1. 테스트가 모두 통과하면 충분한 걸까?

1) 커버리지가 높으면 버그도 더 잘 잡을까?

테스트가 충분한지 확인할 때 자주 사용하는 지표 중 하나가

코드 커버리지(Code Coverage)다.

작성한 테스트가 실제 코드의 어느 범위까지 실행됐는지를 보여주는 지표로,
테스트되지 않은 코드를 찾고 어디에 테스트를 추가해야 할지 판단하는 데 유용하다.

그렇다면 커버리지가 높을수록
더 많은 버그를 발견할 수 있다는 뜻일까?

반드시 그렇지는 않다.

코드를 실행했다는 것과
그 코드에서 발생할 수 있는 문제를 검증했다는 것은 다르기 때문이다.

예를 들어 사용자 정보를 반환하는 기능을 테스트하면서
권한이 있는 사용자의 접근만 확인했다고 해보자.

관련 코드는 테스트를 통해 실행됐기 때문에 Coverage에는 포함된다.

하지만 권한이 없는 사용자의 접근을 제대로 차단하는지는 확인하지 못했을 수 있다.

코드는 실행됐다.

하지만 발생할 수 있는 모든 문제를 검증한 것은 아니다.

결국 Coverage만으로는
현재 테스트가 실제 결함을 얼마나 잘 발견할 수 있는지까지 알기 어렵다.

실제로 Meta의 ACH 연구에서는
새롭게 생성한 테스트의 약 49%가 Line Coverage를 높이지 않았지만,
기존 테스트가 놓치던 결함을 잡아냈다.

더 많은 코드를 실행하지 않았는데,
어떻게 더 많은 결함을 잡을 수 있었을까?

이를 확인하려면 먼저
Meta가 기존 테스트를 평가한 방법부터 살펴볼 필요가 있다.

2) Meta는 테스트를 확인하기 위해 일부러 버그를 만들었다

Meta가 활용한 방법은 오히려 반대 방향이었다.

테스트가 버그를 잡는지 확인하기 위해,
코드에 일부러 버그를 만들어 넣었다.

결함을 넣었는데도 기존 테스트가 모두 통과한다면,
현재 테스트가 그 문제를 발견하지 못한다는 뜻이다.

이렇게 정상 코드를 의도적으로 변경해 결함을 만들고,
기존 테스트가 이를 탐지하는지 확인하는 방법을 Mutation Testing이라고 한다.

Mutation Testing 자체는 새로운 개념이 아니다.

약 50년 동안 연구되어 온 테스트 기법으로,

기존에는 조건문이나 연산자 등을 정해진 규칙에 따라 변경하면서
현재 테스트가 결함을 얼마나 잘 탐지하는지 평가해왔다.

하지만 여기에는 문제가 있었다.

정해진 규칙으로 수많은 코드를 변경하다 보니
실제로 발생할 가능성이 낮은 결함까지 만들어질 수 있었고,

코드는 달라졌지만 실제 동작에는 변화가 없는
의미 없는 변경도 발생할 수 있었다.

무엇보다 중요한 것은,

수많은 결함 중 우리가 실제로 걱정하는 문제를
어떻게 만들어낼 것인가였다.

Meta는 이 지점에 LLM을 활용했다.

기존처럼 정해진 규칙으로 무작정 코드를 변경하는 대신,
실제로 우려하는 문제와 관련된 결함을 AI가 만들어내도록 했다.

그리고 그 시작은
AI에게 아무 버그나 만들어달라고 요청하는 것이 아니었다.

2. Meta는 기존 테스트의 빈틈을 어떻게 찾았을까?

1) AI에게 아무 버그나 만들라고 하지 않았다

ACH는 코드에서 무작정 결함을 만드는 것부터 시작하지 않는다.

먼저 정하는 것은
어떤 문제를 막고 싶은가이다.

Meta는 이를 Issue of Concern이라고 표현했다.

Concern은 과거에 발생했던 결함이나 요구사항,
기술적 제약, 법률·규제처럼 앞으로 발생하지 않도록 확인해야 할 문제를 의미한다.

Meta는 ACH를 실제 서비스에 적용하면서
주로 과거에 발생했던 Privacy 관련 결함을 활용했다.

한 번 발생했던 문제라면,
비슷한 문제가 다른 코드에서도 다시 발생할 수 있기 때문이다.

ACH는 과거 결함의 코드 변경 내용과 현재 코드를 LLM에 제공하고,
비슷한 유형의 문제가 현재 코드에서도 발생하도록 코드를 변경한다.

이렇게 원본 코드를 의도적으로 변경해 만든 코드를
Mutation Testing에서는 Mutant라고 한다.

과거 실제 결함

→ 어떤 문제가 발생했는지 분석

→ 현재 코드에 유사한 Mutant 생성

즉 AI에게 단순히

“이 코드에 버그를 만들어줘.”

라고 요청하는 것이 아니다.

“과거에 이런 문제가 발생했다면,
현재 코드에서는 비슷한 문제가 어떻게 발생할 수 있을까?”

를 만들어보게 하는 것이다.

이를 통해 ACH는 무작위로 많은 결함을 만드는 대신,
실제로 우려하는 문제와 관련된 결함을 중심으로 현재 테스트를 시험한다.

2) AI가 만든 버그가 다 쓸모 있는 것은 아니다

LLM이 Mutant를 만들었다고 해서
바로 새로운 테스트를 만드는 것은 아니다.

먼저 이 결함이 현재 테스트의
실제 빈틈을 보여주는지 확인해야 한다.

가장 먼저 확인하는 것은 코드가 정상적으로 빌드되는가이다.

LLM이 코드를 변경하는 과정에서 문법 오류가 생기거나
애초에 실행할 수 없는 코드가 만들어졌다면 테스트할 의미가 없다.

빌드에 성공한 Mutant에는
현재 사용하고 있는 기존 테스트를 그대로 실행한다.

여기서 기존 테스트가 실패한다면
이미 현재 Test Suite가 해당 결함을 발견할 수 있다는 뜻이다.

반대로,

코드에는 결함이 만들어졌는데

기존 테스트는 모두 통과했다.

이 Mutant는 현재 테스트가 잡지 못한 채 살아남은 것(Survived)이다.

즉 ACH가 찾으려는 것은 바로 이런 경우다.

문제가 생겼는데도 테스트가 통과한다면,
현재 검증에 빈틈이 있을 가능성이 있기 때문이다.

하지만 여기서도 바로 새로운 테스트를 만들 수는 없다.

코드가 변경됐다고 해서
실제 동작까지 반드시 달라지는 것은 아니기 때문이다.

이런 Mutant를 Equivalent Mutant라고 한다.

코드는 달라졌다.

하지만 실제 동작은 같다.

이 경우에는 아무리 테스트를 잘 작성해도
원본 코드와 Mutant의 차이를 동작으로 구분할 수 없다.

따라서 “기존 테스트가 잡지 못했다”는 이유만으로
테스트의 빈틈이라고 판단해서는 안 된다.

Meta는 이를 걸러내기 위해
별도의 LLM 기반 Equivalence Detector를 사용했다.

살아남은 Mutant가 실제 동작을 바꾸는 결함인지,
아니면 표현만 달라진 동등한 코드인지를 다시 판별한 것이다.

결국 새로운 테스트가 필요한 후보는
여러 단계를 거치면서 좁혀진다.

LLM이 Mutant 생성

↓

빌드 가능한가?

↓

기존 테스트를 통과하는가?

↓

실제 동작을 바꾸는 결함인가?

↓

현재 테스트가 놓치고 있는 Mutant

이렇게 살아남은 결함이 확인되면,
그제야 ACH는 이를 잡을 새로운 테스트를 만들기 시작한다.

3) 살아남은 버그를 잡는 새로운 테스트를 만든다

앞선 과정을 거쳐 살아남은 Mutant는
기존 테스트가 발견하지 못한 실제 동작의 변화를 보여준다.

이제 ACH는 이 결함을 잡을 수 있는
새로운 테스트를 LLM으로 생성한다.

이때 LLM에는 원본 코드와 Mutant뿐 아니라
기존에 작성된 테스트도 함께 제공된다.

어떤 코드가 변경됐고,
현재 테스트는 무엇을 확인하고 있는지 참고해

기존 테스트에는 없으면서
해당 Mutant를 발견할 수 있는 테스트를 작성하는 것이다.

하지만 테스트 코드가 만들어졌다고 해서
바로 필요한 테스트가 되는 것은 아니다.

새로운 테스트에는 명확한 조건이 있다.

원본 코드에서는 PASS

Mutant에서는 FAIL

정상적인 코드에서 실패한다면
올바른 동작을 검증하는 테스트라고 보기 어렵다.

반대로 Mutant에서도 통과한다면
처음 발견한 테스트의 빈틈을 메우지 못한 것이다.

정상 동작은 그대로 통과시키면서
기존 테스트가 놓쳤던 결함은 잡아내야 한다.

ACH는 이렇게 결함을 만들어 빈틈을 찾는 것에서 끝나지 않고,
그 빈틈을 메울 새로운 테스트까지 생성한다.

하지만 여기서도 한 가지 문제가 남는다.

AI가 만든 테스트를 그대로 믿어도 될까?

4) AI가 만든 테스트를 다시 테스트한다

새로운 테스트가 만들어졌다고 해서
바로 실제 코드에 적용되는 것은 아니다.

LLM이 만들었다는 이유만으로
결과를 신뢰하지 않는 것이 ACH의 중요한 원칙이다.

Meta는 이를 Assured LLM-based Software Engineering(Assured LLMSE)이라고 설명한다.

핵심은 간단하다.

AI가 만든 결과 중 직접 확인할 수 있는 것은
실제 실행을 통해 다시 검증한다.

ACH가 생성한 테스트에는 다음과 같은 조건이 적용된다.

Buildable
테스트 코드가 실제로 빌드되는가?

Valid Regression Test
정상적인 원본 코드에서 통과하는가?

Hardening
목표로 삼은 Mutant를 잡아내는가?

이 조건들은 LLM의 판단에 맡기지 않는다.

직접 코드를 빌드하고 테스트를 실행해 결과로 확인할 수 있기 때문이다.

하지만 테스트가 처음 설정한 Concern과 실제로 관련되어 있는지,
기존 프로젝트의 테스트 방식에 적합한지는
PASS와 FAIL만으로 판단하기 어렵다.

그래서 ACH가 생성한 테스트는
자동으로 코드에 반영되지 않는다.

CI와 Code Review를 거쳐
엔지니어가 테스트의 의미와 필요성을 최종적으로 판단한다.

AI는 테스트를 만들지만,
실제 코드에 들어갈지는 사람이 결정한다.

즉 ACH는 AI의 결과를 그대로 사용하는 자동화가 아니다.

실행으로 검증할 수 있는 것은 자동으로 확인하고,
의미에 대한 판단은 사람에게 남겨두는 구조다.

그렇다면 이렇게 만들어진 테스트는
실제 Meta의 서비스에서도 유용했을까?

3. 실제로 Meta의 테스트는 달라졌을까?

1) 1만 개가 넘는 클래스에 적용해봤다

Meta는 ACH를 연구 단계에서만 검증하지 않았다.

Facebook Feed, Instagram, Messenger, WhatsApp을 비롯한
7개 플랫폼의 실제 코드에 적용했다.

분석 대상은 총 10,795개의 Kotlin 클래스였다.

ACH는 이 코드들을 대상으로 Mutant를 만들고,
앞서 살펴본 과정을 거쳐 실제 테스트의 빈틈을 찾았다.

그 과정에서 숫자는 빠르게 줄어들었다.

분석한 Kotlin 클래스
10,795개

↓

빌드되고 기존 테스트를 통과한 Mutant
9,095개

↓

동등하지 않은 것으로 판단된 Mutant
4,660개

↓

최종 생성된 테스트
571개

많은 Mutant를 만드는 것 자체가 목적은 아니었다.

빌드할 수 없는 변경이나 기존 테스트가 이미 잡는 결함,
실제 동작을 바꾸지 않는 Mutant를 걸러내고
새로운 검증이 필요한 경우에 테스트를 생성한 것이다.

그렇다고 이 571개의 테스트가
모두 자동으로 실제 코드에 반영된 것도 아니다.

앞서 살펴본 것처럼 최종적으로는
Meta 엔지니어가 생성된 테스트를 직접 검토했다.

그 결과, ACH가 제안한 테스트의 73%를
엔지니어가 유용한 테스트로 받아들였다.

처음 ACH가 주로 다루려 했던 것은 Privacy와 관련된 문제였다.

하지만 실제 검토에서는 Privacy와 직접 관련되지 않은 테스트도
기존 테스트가 놓치던 Corner Case나 Coverage를 보완한다는 이유로 받아들여졌다.

즉 ACH가 만들어낸 테스트는 단순히 실행 가능한 코드에 그치지 않고,
실제 개발자가 기존 Test Suite에 추가할 가치가 있다고 판단한 경우가 상당수 있었다.

그리고 이 결과에서 더 흥미로운 점이 하나 있었다.

새로운 테스트가 버그를 더 잘 잡았다고 해서
항상 Coverage까지 높아진 것은 아니었다.

2) 커버리지가 늘지 않아도 버그는 더 잘 잡을 수 있었다

앞에서 한 가지 흥미로운 결과를 먼저 살펴봤다.

ACH가 생성한 테스트 가운데 약 49%는
Line Coverage를 높이지 않았다.

새로운 테스트를 추가했는데도
실행되는 코드의 범위는 이전과 달라지지 않았다는 뜻이다.

그렇다면 이 테스트들은
기존 테스트와 별다른 차이가 없었던 걸까?

그렇지 않았다.

Coverage는 늘어나지 않았지만,
기존 테스트가 놓쳤던 Mutant를 새롭게 잡아냈다.

이유는 앞에서 살펴본 것처럼
코드를 실행하는 것과 그 동작을 제대로 검증하는 것은 다르기 때문이다.

기존 테스트가 이미 특정 코드를 실행하고 있다면
같은 코드를 대상으로 새로운 조건을 검증해도 Line Coverage는 올라가지 않을 수 있다.

하지만 그 새로운 테스트가
기존에는 확인하지 않았던 동작의 변화를 잡아낸다면,

실행 범위는 그대로여도
결함을 탐지하는 능력은 달라질 수 있다.

Coverage

얼마나 많은 코드를 실행했는가?

Mutation Testing

실제로 결함이 생겼을 때 잡아낼 수 있는가?

Meta의 결과는 이 두 질문이 같지 않다는 것을 보여준다.

그렇다고 Coverage가 필요 없다는 의미는 아니다.

Coverage는 아직 테스트되지 않은 코드가 어디인지 확인하는 데 유용하고,
Mutation Testing은 이미 테스트하고 있는 코드에서도 실제 결함을 잡을 수 있는지 확인하는 데 도움이 된다.

ACH는 이 차이를 이용해
Coverage만으로는 드러나지 않던 테스트의 빈틈을 찾아냈다.

하지만 여기서 ACH의 역할을 정확히 구분할 필요가 있다.

ACH가 현재 코드에 숨어 있는 버그를
직접 찾아낸 것은 아니기 때문이다.

3) AI가 실제 버그를 찾아주는 시스템은 아니다

여기까지 보면 ACH가
AI로 실제 버그를 찾아내는 시스템처럼 보일 수도 있다.

하지만 ACH의 목적은 조금 다르다.

현재 코드에 숨어 있는 버그를 찾는 것이 아니라,
앞으로 발생할 수 있는 문제에 대비해 테스트를 강화하는 것이다.

ACH는 기본적으로 현재 코드를 정상 상태로 두고 시작한다.

그리고 과거에 발생했던 결함이나 Concern을 바탕으로
현재 코드에 의도적으로 새로운 결함을 만든다.

기존 테스트가 이를 잡지 못하면
해당 문제를 검증할 새로운 테스트를 추가한다.

즉 ACH가 찾는 것은 현재 코드의 버그 자체가 아니라,
버그가 생겼을 때 놓칠 수 있는 테스트의 빈틈에 가깝다.

물론 모든 과정을 AI에게 맡길 수 있는 것도 아니다.

LLM이 만든 Mutant가 처음 의도한 Concern을
정확하게 반영하지 못할 수도 있고,

생성된 테스트가 실제 프로젝트에서 필요한지 역시
실행 결과만으로 판단하기 어렵다.

그래서 Meta 역시 최종 단계에서는
엔지니어의 Code Review를 통해 테스트의 관련성과 필요성을 확인했다.

AI가 결함을 만들고, 테스트의 빈틈을 찾고,
필요한 테스트까지 제안한다.

하지만 무엇을 실제 테스트로 남길지는 사람이 결정한다.

흥미로운 점은 이렇게 만들어진 테스트의 약 절반이
Line Coverage를 더 높이지 않았다는 것이다.

더 많은 코드를 실행하지 않아도
기존에는 확인하지 못했던 문제를 새롭게 검증할 수 있었다.

결국 Meta가 AI를 활용한 지점은
단순히 테스트 코드를 더 빠르게 만드는 데 있지 않았다.

현재 테스트가 무엇을 놓치고 있는지 찾아내고,
새로 만든 검증이 정말 필요한지 다시 확인하는 것.

AI가 테스트에 들어오는 방식은 달라지고 있지만,
무엇을 검증해야 하는지 찾고 그 결과를 확인하는 과정은 여전히 남아 있다.

티어시