AI는 소프트웨어 테스트를 변화시키고 있습니다.

하지만 아마도 많은 QA 엔지니어들이 생각하는 방식과는 다를 것입니다.

AI는 단순히 Selenium 스크립트, Playwright 테스트, API 자동화 또는 성능 테스트 (performance testing)를 대체하는 것이 아닙니다.

더 큰 변화는 이것입니다:

SDET의 역할은 모든 테스트를 수동으로 작성하는 것에서 지능형 테스트 시스템을 설계, 가이드, 리뷰 및 검증하는 것으로 이동하고 있습니다.

저는 API 자동화, UI 테스트, CI/CD 및 성능 테스트 (performance testing) 분야에서 작업해 왔습니다. 한 가지 분명해지고 있는 사실은, 향후 몇 년 동안 테스트 프레임워크 (testing framework)를 아는 것만으로는 충분하지 않을 수 있다는 점입니다.

SDET는 AI 코딩 에이전트 (AI coding agents), 브라우저 에이전트 (browser agents), AI 지원 API 테스트 (AI-assisted API testing), 비주얼 AI (visual AI), 그리고 지능형 테스트 유지보수 (intelligent test maintenance)와 협업하는 방법을 이해해야 합니다.

다음은 2026년에 SDET가 배워야 한다고 믿는 7가지 AI 도구와 기술입니다.

1. GitHub Copilot — 테스트 자동화를 위한 AI 페어 프로그래머 (AI Pair Programmer)

GitHub Copilot은 더 이상 애플리케이션 개발자에게만 유용한 것이 아닙니다.

SDET에게 있어, 이는 자동화 저장소 (automation repository) 내부에서 AI 페어 프로그래머 (AI pair programmer) 역할을 할 수 있습니다.

SDET가 어디에 활용할 수 있을까요?

TypeScript로 작성된 Playwright 프레임워크 (framework)가 있다고 가정해 봅시다.

팀에서 새로운 결제 (checkout) API를 추가했습니다.

보통 여러분은 다음과 같은 과정을 거칠 것입니다:

1. API 문서를 읽습니다.
2. 요청 페이로드 (request payloads)를 생성합니다.
3. 긍정 테스트 (positive tests)를 작성합니다.
4. 부정 시나리오 (negative scenarios)를 추가합니다.
5. 테스트 데이터 (test data)를 생성합니다.
6. 어설션 (assertions)을 추가합니다.
7. 린팅 (linting) 문제를 수정합니다.

대신, AI에게 상세한 테스트 컨텍스트 (testing context)를 제공할 수 있습니다.

예를 들어:

결제 엔드포인트 (checkout endpoint)에 대한 Playwright API 테스트를 생성해줘. 성공적인 결제, 잘못된 제품 ID, 누락된 인증 토큰 (authorization token), 수량 0, 음수 수량, 그리고 중복 트랜잭션 요청을 포함해줘. 이 저장소의 기존 API 테스트 구조를 따라줘.

중요한 점은 AI가 코드를 작성한다는 것이 아닙니다.

중요한 점은 현대적인 코딩 에이전트 (coding agent)가 저장소의 컨텍스트 (context)를 이해할 수 있다는 것입니다.

에이전트는 기존 패턴을 조사하고 현재 프레임워크 (framework)를 따르는 코드를 생성하도록 도울 수 있습니다.

SDET 케이스 스터디 (Case Study)

700개의 자동화된 API 테스트를 포함하는 회귀 테스트 스위트 (regression suite)를 가정해 봅시다.

개발 팀이 새로운 인증 헤더 (authentication header)를 도입합니다:

X-Client-Version

영향을 받는 모든 API 헬퍼 (helper)를 수동으로 찾는 대신, AI 코딩 에이전트 (AI coding agent)가 저장소 (repository)를 조사하여 HTTP 헤더를 생성하는 요청 유틸리티 (request utilities)를 식별할 수 있습니다.

SDET는 여전히 변경 사항을 검토합니다.

하지만 초기 저장소 분석은 훨씬 더 빨라질 수 있습니다.

무엇을 배워야 할까요?

다음 방법들을 배우세요:

• 저장소 수준의 지침 (repository-level instructions) 작성하기.
• AI가 생성한 테스트 코드 검토하기.
• 프레임워크 컨텍스트 (framework context) 제공하기.
• 네거티브 테스트 시나리오 (negative test scenarios) 생성하기.
• 중복된 테스트 유틸리티 리팩터링 (refactor) 하기.
• 생소한 자동화 코드에 대해 AI에게 설명 요청하기.

미래의 기술은 단순히 프롬프팅 (prompting)을 하는 것이 아닙니다.

그것은 AI가 유용한 변경을 안전하게 수행할 수 있도록 충분한 엔지니어링 컨텍스트 (engineering context)를 제공하는 것입니다.

2. Playwright MCP 및 테스팅 에이전트 (Testing Agents) — 애플리케이션을 탐색할 수 있는 AI

이것은 테스트 자동화 엔지니어들에게 가장 흥미로운 발전 중 하나입니다.

전통적인 테스트 자동화는 다음과 같이 작동합니다:

사람이 애플리케이션 탐색 → 사람이 흐름 (flow) 식별 → 사람이 테스트 작성

AI 지원 브라우저 테스팅은 워크플로 (workflow)를 변화시킵니다.

다음과 같이 변할 수 있습니다:

AI가 애플리케이션 탐색 → AI가 테스트 플랜 생성 → AI가 테스트 생성 → 사람이 검토

Playwright의 AI 지향적 툴링 (tooling)은 에이전트 (agents)가 브라우저와 상호작용할 수 있게 해줍니다.

AI는 페이지를 조사하고, 요소 (elements)와 상호작용하며, 애플리케이션 흐름을 이해할 수 있습니다.

사용 사례 예시 (Example Use Case)

에이전트에게 다음과 같이 요청한다고 가정해 봅시다:

로그인 및 계정 복구 흐름을 탐색하세요. 중요한 기능적 및 네거티브 테스트 시나리오를 식별하세요.

에이전트는 다음과 같은 항목들을 탐색할 수 있습니다:

• 유효한 로그인.
• 잘못된 비밀번호.
• 빈 이메일.
• 잘못된 이메일 형식.
• 비밀번호 찾기.
• 잠긴 계정.
• 세션 동작 (session behaviour).

그 후 에이전트는 발견된 흐름을 Playwright 테스트로 변환하는 것을 도울 수 있습니다.

SDET 케이스 스터디 (Case Study)

당신의 회사가 새로운 관리자 포털 (admin portal)을 출시한다고 상상해 보세요.

총 25개의 페이지가 있습니다.

전통적으로 자동화 엔지니어(automation engineer)는 회귀 테스트 전략(regression strategy)을 구축하기 전에 애플리케이션을 수동으로 탐색하는 데 며칠을 소비할 수 있습니다.

AI 브라우저 에이전트(AI browser agent)는 초기 탐색을 수행할 수 있습니다.

그러면 SDET는 발견된 흐름(flows)을 검토하고 다음과 같이 질문할 수 있습니다:

비즈니스 핵심 시나리오 중 누락된 것은 무엇인가?

이 지점이 바로 SDET의 지식이 여전히 중요한 부분입니다.

AI는 UI를 이해할 수 있습니다.

하지만 잭팟 설정(jackpot configuration), 금융 한도(financial limit), 지급 규칙(payout rule) 또는 사용자 권한(user permission)을 변경하는 것이 중대한 비즈니스 영향을 미칠 수 있다는 점은 이해하지 못할 수도 있습니다.

SDET는 **리스크 컨텍스트 (risk context)**를 제공합니다.

무엇을 배워야 하는가?

다음 내용을 학습하세요:

• 모델 컨텍스트 프로토콜 (Model Context Protocol) 기초.
• Playwright 브라우저 자동화 (browser automation).
• AI 에이전트 도구 액세스 (tool access).
• 에이전트 생성 테스트 플랜 (test plans).
• AI 생성 셀렉터 (selectors) 검토.
• 브라우저 에이전트의 보안 리스크 (security risks).

저는 AI 브라우저 에이전트를 이해하는 것이 중요한 자동화 기술이 될 것이라고 믿습니다.

3. OpenAI Codex — 테스트 저장소를 위한 AI 소프트웨어 엔지니어링 에이전트

많은 테스터가 다음과 같이 AI를 사용합니다:

Selenium 테스트를 작성해줘.

이것은 AI 활용의 가장 낮은 단계입니다.

소프트웨어 엔지니어링 에이전트(software engineering agent)는 더 큰 작업 수준에서 작동할 수 있습니다.

예를 들어:

우리의 Playwright 테스트 프레임워크를 분석해줘. 중복된 API 인증 로직을 식별하고, 리팩토링 계획을 제안하며, 영향을 받는 테스트를 업데이트하고, 관련 테스트 스위트(test suite)를 실행해줘.

이는 코드 스니펫(code snippet)을 생성하는 것과는 매우 다릅니다.

에이전트는 엔지니어링 작업(engineering task)을 수행합니다.

실제 SDET 유스케이스 (Real SDET Use Case)

당신의 테스트 저장소(test repository)에 다음과 같은 내용이 포함되어 있다고 가정해 봅시다:

• 500개의 UI 테스트.
• 300개의 API 테스트.
• 여러 개의 헬퍼 파일 (helper files).
• 중복된 인증 메서드 (authentication methods).
• 오래된 유틸리티 함수 (utility functions).
• 일관성 없는 재시도 로직 (retry logic).

당신은 엔지니어링 에이전트에게 저장소를 조사하도록 요청할 수 있습니다.

에이전트는 반복되는 패턴을 식별하고 변경 사항을 제안하는 데 도움을 줄 수 있습니다.

SDET의 업무는 다음과 같은 질문을 검토하는 것이 됩니다:

• 이 변경 사항이 테스트 동작 (test behaviour)을 변경할 것인가?
• 재시도 (retries)가 실제 결함 (defect)을 숨길 수 있는가?
• 어설션 (assertions)이 약해지고 있는가?
• 테스트 격리 (test isolation)가 유지되고 있는가?
• 병렬 실행 (parallel execution)이 여전히 작동할 것인가?

사례 연구 (Case Study): 불안정한 테스트 (Flaky Test) 조사

CI 환경에서 40개의 테스트가 무작위로 실패한다고 가정해 봅시다.

실패는 오직 병렬 실행 (parallel execution) 중에만 발생합니다.

AI 에이전트는 다음 항목들을 조사할 수 있습니다:

• 테스트 픽스처 (Test fixtures).
• 공유 상태 (Shared state).
• 전역 변수 (Global variables).
• 테스트 데이터 생성 (Test data creation).
• 정리 로직 (Cleanup logic).
• 병렬 워커 설정 (Parallel worker configuration).

AI는 여러 테스트가 동일한 고객 계정을 사용하고 있다는 사실을 발견할 수 있습니다.

AI는 워커 (worker)당 격리된 테스트 데이터를 생성하도록 제안할 수 있습니다.

하지만 숙련된 SDET는 근본 원인 (root cause)을 검증해야 합니다.

AI는 조사를 가속화합니다. 엔지니어링 판단 (Engineering judgment)은 결론을 검증합니다.

무엇을 배워야 하는가?

AI 에이전트에게 다음과 같은 요청을 하는 연습을 하세요:

• 테스트 아키텍처 (test architecture) 분석.
• 불안정한 테스트 (flaky tests) 조사.
• 풀 리퀘스트 (pull requests) 리뷰.
• 중복된 자동화 코드 찾기.
• CI 실패 원인 설명.
• 테스트 유틸리티 (test utilities) 생성.
• 테스트 문서화 (test documentation) 개선.

AI를 단순한 코드 생성기로만 사용하지 마세요.

AI를 **테스트 엔지니어링 조사 어시스턴트 (test engineering investigation assistant)**로 사용하세요.

4. Postman Postbot — AI 지원 API 테스트

API 테스트는 AI가 SDET의 생산성을 즉각적으로 향상시킬 수 있는 분야 중 하나입니다.

Postman의 AI 어시스턴트인 Postbot은 테스트 스크립트와 트러블슈팅 (troubleshooting)을 포함한 API 워크플로 (workflows)를 도울 수 있습니다.

예시

다음과 같은 응답을 받았다고 가정해 봅시다:

{
  "transactionId": "TXN-98271",
  "status": "COMPLETED",
...

AI에게 검증 테스트 (validation tests)를 생성하도록 요청할 수 있습니다.

AI는 다음과 같은 항목에 대한 체크를 생성할 수 있습니다:

• HTTP 상태 (HTTP status).
• 응답 시간 (Response time).
• 트랜잭션 ID (Transaction ID).
• 트랜잭션 상태 (Transaction status).
• 금액 데이터 타입 (Amount data type).
• 통화 값 (Currency value).

하지만 역량 있는 SDET는 더 나아가야 합니다.

다음과 같이 요청하세요:

이 트랜잭션 API에 대한 네거티브 및 경계 시나리오 (negative and boundary scenarios)를 생성해 줘.

이제 AI는 다음과 같이 제안할 수 있습니다:

• 금액(Amount) = 0.
• 음수 금액(Negative amount).
• 극도로 큰 금액(Extremely large amount).
• 통화(Currency) 누락.
• 지원되지 않는 통화(Unsupported currency).
• 중복된 트랜잭션 ID(Duplicate transaction ID).
• 만료된 인증 토큰(Expired authentication token).
• 유효하지 않은 콘텐츠 타입(Invalid content type).

SDET 사례 연구 (Case Study)

150개의 REST API를 노출하는 마이크로서비스(microservice)가 있다고 가정해 봅시다.

API 문서가 존재하지만, 자동화된 커버리지(coverage)는 불완전합니다.

SDET는 AI를 사용하여 1차 단계의 테스트 설계(test design)를 수행할 수 있습니다.

입력(Input):

• API 명세(specification).
• 요청 스키마(Request schema).
• 응답 스키마(Response schema).
• 비즈니스 규칙(Business rules).

출력(Output):

• 긍정적 시나리오(Positive scenarios).
• 부정적 시나리오(Negative scenarios).
• 경계 테스트(Boundary tests).
• 인증 테스트(Authentication tests).
• 스키마 검증 아이디어(Schema validation ideas).

그 후 SDET는 실제 운영 리스크(production risk)를 기반으로 시나리오를 검토합니다.

중요한 경고

AI가 생성한 API 테스트가 완벽하다고 절대 가정하지 마십시오.

예를 들어, AI는 다음과 같이 테스트할 수 있습니다:

amount = -1

하지만 성능(performance) 또는 금융 시스템은 훨씬 더 흥미로운 경계값(boundaries)을 가질 수 있습니다:

2147483647

2147483648

999999999999

부동 소수점 정밀도(Floating-point precision).

중복 요청(Duplicate requests).

동시 요청(Concurrent requests).

멱등성 동작(Idempotency behaviour).

이것이 바로 도메인 지식(domain knowledge)이 여전히 중요한 이유입니다.

5. Applitools Visual AI — 지능형 시각적 테스트 (Intelligent Visual Testing)

전통적인 시각적 테스트(visual testing)는 너무 많은 허위 실패(false failures)를 발생시킬 수 있습니다.

아주 미세한 렌더링(rendering) 차이로 인해 픽셀 비교(pixel comparison)가 실패할 수 있기 때문입니다.

예를 들어:

• 폰트 렌더링 변경.
• 안티앨리어싱(Anti-aliasing) 차이.
• 브라우저 렌더링 변동.
• 동적 콘텐츠(Dynamic content).

Visual AI는 기본적인 픽셀 비교에만 의존하는 대신, 의미 있는 시각적 차이를 식별하려고 시도합니다.

사용 사례 예시 (Example Use Case)

이커머스(e-commerce) 결제 페이지를 가정해 봅시다.

기능 자동화 테스트(functional automation test)는 다음과 같이 확인합니다:

await expect(page.locator('#pay-button')).toBeVisible();

테스트는 통과합니다.

하지만 실제 페이지에는 심각한 UI 문제가 있습니다.

결제(Pay) 버튼이 보이기는 하지만 주문 합계(order total)와 겹쳐 있습니다.

기능 테스트는 여전히 통과합니다.

시각적 테스트(visual test)는 이러한 레이아웃 변경을 감지할 수 있습니다.

SDET 사례 연구 (Case Study)

다음 환경을 지원하는 애플리케이션을 고려해 보십시오:

• Chrome.
• Firefox.
• Safari.
• 데스크톱(Desktop).
• 태블릿(Tablet).
• 모바일(Mobile).

중요한 페이지가 50개 있다고 가정해 봅시다.

모든 시각적 조합을 수동으로 검증하는 것은 비용이 많이 듭니다.

Visual AI (시각적 AI)는 이러한 환경 전반에서 의미 있는 UI 차이를 식별하는 데 도움을 줄 수 있습니다.

주요 유스케이스 (Best Use Cases)

Visual AI는 특히 다음과 같은 경우에 유용합니다:

• 반응형 테스트 (Responsive testing).
• 교차 브라우저 검증 (Cross-browser validation).
• 디자인 시스템 테스트 (Design system testing).
• 컴포넌트 테스트 (Component testing).
• 이커머스 애플리케이션 (E-commerce applications).
• 대시보드 애플리케이션 (Dashboard applications).
• 현지화 테스트 (Localization testing).

SDET는 무엇을 배워야 하는가?

다음 사항을 이해해야 합니다:

• 시각적 체크포인트 (Visual checkpoints).
• 베이스라인 관리 (Baseline management).
• 동적 콘텐츠 처리 (Dynamic content handling).
• 레이아웃 검증 (Layout validation).
• 교차 브라우저 시각적 테스트 (Cross-browser visual testing).

기능적 어설션 (Functional assertions)을 스크린샷으로 대체하지 마십시오.

시각적 테스트를 추가적인 품질 계층 (Quality layer)으로 사용하십시오.

6. mabl — AI 네이티브 테스트 생성 및 유지보수

테스트 자동화에서 가장 큰 문제 중 하나는 테스트를 만드는 것이 아닙니다.

바로 유지보수 (Maintenance)하는 것입니다.

2,000개의 UI 테스트가 있다고 상상해 보십시오.

개발 팀이 DOM 구조를 변경합니다.

갑자기:

300개의 테스트가 실패합니다.

제품이 고장 난 것일까요?

아닐 수도 있습니다.

셀렉터 (Selectors)가 변경된 것입니다.

이 지점이 바로 AI 지원 테스트 유지보수가 흥미로워지는 부분입니다.

mabl과 같은 도구는 애플리케이션이 변경될 때 AI 기반의 테스트 생성, 실행, 실패 분석 및 복구에 집중합니다.

SDET 케이스 스터디 (Case Study)

매일 변경 사항을 출시하는 SaaS 제품을 생각해 보십시오.

애플리케이션 팀은 프론트엔드를 빈번하게 업데이트합니다.

전통적인 자동화 스위트 (Automation suite)는 상당한 유지보수 작업을 발생시킬 수 있습니다.

AI 네이티브 테스트 플랫폼은 이러한 반복적인 유지보수 작업을 일부 줄이는 데 도움을 줄 수 있습니다.

하지만 중요한 질문이 하나 있습니다.

모든 실패한 테스트가 자동으로 스스로를 치유(Self-healing)해야 할까요?

제 대답은 '아니오'입니다.

원래 버튼에 다음과 같이 적혀 있다고 가정해 봅시다:

Transfer Money (송금하기)

제품 변경 후, 애플리케이션에 다음과 같이 표시됩니다:

Delete Account (계정 삭제)

만약 셀프 힐링 (Self-healing) 시스템이 맹목적으로 다른 버튼을 찾아 계속 진행한다면, 테스트는 잘못된 동작을 수행할 수 있습니다.

SDET는 거버넌스 (Governance)를 정의해야 합니다.

예를 들어:

• 저위험 로케이터 (Locator) 변경은 자동으로 처리될 수 있습니다.
• 비즈니스 핵심 흐름 (Business-critical flows)은 사람의 검토가 필요합니다.
• 금융 관련 동작은 대상 요소를 자동으로 전환할 수 없습니다.
• 인증 (Authentication) 변경은 승인이 필요합니다.

무엇을 배워야 할까요?

다음 사항들을 이해해야 합니다:

• AI 지원 테스트 생성 (AI-assisted test creation).
• 셀프 힐링 (Self-healing) 개념.
• 테스트 실패 분류 (Test failure classification).
• 리스크 기반 자동화 (Risk-based automation).
• 사람의 승인 워크플로우 (Human approval workflows).

기술은 유용합니다.

하지만 거버넌스 (Governance) 또한 그만큼 중요합니다.

7. Testim — AI 지원 안정적 UI 자동화

UI 자동화 엔지니어들은 이 고통을 잘 알고 있습니다:

//*[@id="app"]/div[2]/div[4]/button

누군가 페이지 레이아웃을 변경합니다.

테스트가 실패합니다.

전통적인 자동화는 종종 셀렉터 (Selector)에 크게 의존합니다.

Testim과 같은 AI 지원 자동화 플랫폼은 애플리케이션이 변경될 때 테스트 안정성을 향상하도록 설계된 지능형 로케이터 전략 (Intelligent locator strategies)을 사용합니다.

예시

전통적인 테스트는 하나의 로케이터를 사용하여 로그인 버튼을 식별할 수 있습니다.

AI 지원 시스템은 대상 요소를 이해하기 위해 여러 요소 특성 (Element characteristics)을 사용할 수 있습니다.