11. 자료실·기타/테스트 관련 강좌

12화. 에이전트는 무엇을 대신하는가 — 에이전트형 테스트의 개념과 한계(수동 노력 최대 45% 절감 추정).

testmanager 2026. 7. 17. 07:54
반응형

AI 시대의 품질 아키텍트 : 테스터에서 시스템 품질 설계자로

Part 0. 오리엔테이션
0화. 30분 데모와 프로덕션 사이의 거리 — 현실 인식과 방향 제시

Part 1. 기초 체력
AI가 짠 코드를 읽고 검증할 수 있는 눈과 웹·API 원리 다지기
1화. AI가 짠 코드를 읽는 눈 — Python 또는 JS/TS 중 하나를 코드 리뷰 가능한 수준까지. 실습: AI가 생성한 테스트 코드의 버그 3개 찾기.
2화. 변경은 diff에서 시작된다 — Git과 PR 기반 협업, 변경 기반 테스트의 첫 단추. 실습: PR diff만 보고 영향 범위 추정해 보기.
3화. 웹은 어떻게 움직이는가 — HTTP, 쿠키·세션의 원리. 실습: 개발자도구로 요청·응답 해부.
4화. 인증의 지도 — OAuth·JWT·RBAC를 테스터 시선으로. 실습: 토큰 만료·권한 우회 시나리오 설계.
5화. API의 두 얼굴 — REST와 GraphQL의 차이와 테스트 관점. 실습: 같은 기능을 두 방식으로 호출·검증.

Part 2. 테스트 자동화
Playwright를 주력으로 깊이 익히기
6화. 왜 Playwright인가 — 도구 선택의 근거와 첫 테스트 작성.
7화. 플래키의 근원, 셀렉터와 대기 — 안정적 셀렉터와 비동기 대기 전략.
8화. 실패를 영상으로 읽는다 — Trace Viewer로 원인 추적.
9화. 계약을 테스트하라 — API·계약 테스트(OpenAPI/GraphQL schema 기반).
10화. 눈에 보이는 회귀, 모두에게 열린 화면 — 시각적 회귀와 접근성 자동 검사. (Selenium·Appium은 레거시·모바일 대응용으로 짧게 짚기)

Part 3. AI 활용·MCP (연재 핵심)
AI를 단순 도구가 아닌 차별화 무기로 만드는 구간
11화. 프롬프트로 테스트를 설계하기 — 명세·PR을 입력해 케이스를 생성·우선순위화하는 패턴 정립.
12화. 에이전트는 무엇을 대신하는가 — 에이전트형 테스트의 개념과 한계(수동 노력 최대 45% 절감 추정).
13화. 스스로 고치는 테스트, 그리고 그 한계 — 자가 치유와 AI Healer. 셀렉터·DOM 변경에서 75%+ 복구, 그러나 복잡한 로직 버그는 사람 몫.
14화. npx playwright init-agents — 첫 MCP 실습 — 접근성 트리 기반 Playwright MCP 시작하기.
15화. MCP로 통합을 검증하다 — MCP 기반 통합 검증 실습.
16화. 환각을 거르는 사람 — AI 결과의 환각·오탐을 걸러내는 인간 검증 체계 설계. 직무 특성상 가장 큰 강점이 되는 지점.

Part 4. 파이프라인·운영
개인기를 조직의 신뢰 시스템으로 연결
17화. 문 앞의 품질 게이트 — CI/CD 품질 게이트 구성.
18화. 플래키를 격리하라 — 불안정 테스트 격리와 실패 원인 자동 분류.
19화. 관측성을 테스트로 환원하기 — 로그·메트릭·트레이스(OpenTelemetry)를 테스트 사고로 끌어오기.
20화. 진짜 같은 가짜 데이터 — 테스트 데이터 합성과 마스킹.

Part 5. 비기능 영역
눈에 보이지 않는 품질 지키기
21화. 무게를 견디는가 — k6/JMeter로 부하·스트레스 테스트.
22화. 손안의 성능 — 모바일 성능 지표(FPS·시작속도·메모리·배터리).
23화. 공격자처럼 생각하기 — OWASP Top 10으로 본 보안 기본기.
24화. 코드를 스캔하는 도구들 — SAST·DAST·SCA(SonarQube·OWASP ZAP·Snyk) 실전.

Part 6. 전략·리더십·표준
아키텍트로서의 설계·운영·리더십
25화. 테스트 가능성을 설계에 심다 — Testability를 기획·개발 단계로 끌어올리기.
26화. 공통 언어로서의 BDD — Gherkin으로 기획·개발·QA를 한 문장에 모으기.
27화. AI를 지휘하는 운영 모델 — 20명 규모 팀을 위한 AI 오케스트레이션 가이드라인과 코칭.
28화. 표준과 AI를 잇다 — KOLAS 인정 요건·품질 표준을 AI 검증 체계로 연결하는 도메인 전문성.
29화. 데모를 프로덕션으로 옮기는 비용 — 30분 데모와 실전의 거리, 사람의 감독이 끝까지 필요한 이유를 균형 있게 정리.
30화. 테스터에서 품질 아키텍트로 

 


 

에이전트가 대신 뛰어주는 순간, 테스터는 더 큰 그림을 볼 수 있게 된다

 

AI 에이전트가 테스트를 대신해준다는 이야기를 들으면 “이제 사람이 할 일이 없어지나?” 하는 기대와 불안이 동시에 듭니다.

 

12화에서는 에이전트형 테스트의 개념을 이해하기 쉽게 풀고, 실제로 무엇을 대신할 수 있는지, 그리고 어디까지가 사람의 몫인지 현실적으로 짚어보겠습니다.

 

제대로 활용하면 수동 노력의 최대 45% 정도를 절감할 수 있지만, 완전 자동화는 아직 먼 이야기입니다.

 

 

로봇 청소기와 사람 집주인

집에 로봇 청소기를 들이면 매일 바닥을 쓸고 먼지를 빨아들입니다.

 

하지만 옷이 떨어져 있거나, 테이블 위 먼지는 치우지 못하죠.

 

로봇이 대신하는 건 반복적이고 규칙적인 일이고, 집 전체를 어떻게 관리할지는 결국 사람이 결정합니다.

 

에이전트형 테스트도 비슷합니다.

 

AI 에이전트(Playwright MCP, Browser-use, Claude Computer Use 같은 도구들)는 주어진 목표를 가지고 스스로 브라우저를 조작하고, 테스트를 실행하며, 문제를 찾아 나섭니다.

 

단순 반복 작업을 대신해주는 ‘로봇 청소기’ 역할을 하는 거예요.

 

 

에이전트가 잘 대신하는 일들

에이전트는 특히 아래 같은 영역에서 강력합니다.

 

먼저, 탐색적 테스트를 빠르게 수행합니다. “로그인 후 대시보드를 둘러보고 이상한 점을 찾아봐”라고 지시하면, 여러 경로를 스스로 클릭하며 예상치 못한 오류를 발견하기도 합니다.

 

두 번째는 회귀 테스트의 일부를 자동화합니다. PR이 올라오면 에이전트가 핵심 흐름을 돌면서 기존 기능이 깨졌는지 확인해줍니다.

 

세 번째는 테스트 데이터 생성과 기본 검증입니다. 다양한 입력값을 만들어 넣어보고, 명백한 오류(빈 화면, 크래시 등)를 즉시 보고합니다.

 

이런 작업들을 에이전트에게 맡기면 테스터가 직접 클릭하고 확인하던 시간이 크게 줄어듭니다.

 

실제 프로젝트에서 잘 다듬어 사용하면 수동 테스트 노력의 30~45% 정도를 절감할 수 있다는 경험적 추정이 나옵니다.

 

특히 반복적인 smoke test나 기본 기능 확인에서 효과가 큽니다.

 

 

그러나 에이전트가 아직 못 하는 일, 그리고 한계

로봇 청소기가 카펫 가장자리나 계단은 조심스럽게 피하듯, 에이전트도 명확하지 않은 상황에서는 자주 헤맵니다.

 

가장 큰 한계는 맥락 이해와 판단력입니다.

 

“이 오류가 사용자에게 치명적인가?” “비즈니스 규칙에 맞는가?” 같은 판단은 AI가 아직 잘 못합니다.

 

환각(hallucination)도 문제예요. 없는 버그를 만들어내거나, 실제 버그를 놓치기도 합니다.

 

또한 복잡한 비즈니스 로직, 보안 취약점의 미묘한 조합, 또는 “사용자가 정말 이렇게 사용할까?” 같은 사용자 경험 평가는 사람의 몫입니다.

 

에이전트는 빠르게 많은 시도를 하지만, 깊이와 정확성에서는 아직 인간을 따라오기 어렵습니다.

 

특히 프로덕션 환경과 비슷한 복잡한 상태(동시 사용자, 특정 네트워크 조건)에서는 에이전트의 예측 가능성이 떨어집니다.

 

그래서 “에이전트가 80%까지 해주고, 사람은 마지막 20%를 검증한다”는 운영 모델이 현실적입니다.

 

 

에이전트를 무기로 만드는 실전 접근

에이전트를 단순히 “더 해줘”라고만 지시하지 말고, 명확한 목표와 제한 조건을 주는 프롬프트를 연습하세요.

 

예를 들어 “로그인 흐름을 5가지 다른 방식으로 테스트하고, Trace를 남겨서 실패한 부분만 보고해”처럼 구체적으로 지시하면 결과물이 훨씬 나아집니다.

 

처음에는 작은 기능부터 에이전트를 투입해 보고, 사람이 검증하는 사이클을 반복하며 신뢰도를 높여가세요.

 

이렇게 하면 AI는 테스터의 시간을 해방시켜주고, 당신은 더 전략적인 품질 설계에 집중할 수 있습니다.

 

에이전트의 힘을 알되 그 한계를 명확히 아는 순간, 테스터는 단순 실행자가 아니라 AI와 함께 시스템 품질을 설계하는 진짜 아키텍트로 거듭납니다.

 

다음 화에서는 이런 에이전트가 스스로 고치는 ‘자가 치유’ 테스트까지 더 깊이 들어가 보겠습니다.

 

 

반응형