11화. 프롬프트로 테스트를 설계하기 — 명세·PR을 입력해 케이스를 생성·우선순위화하는 패턴 정립.

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가 진짜 무기가 된다

 

테스터가 명세서나 PR만 보고 테스트 케이스를 직접 짜다 보면 시간도 많이 들고, 놓치는 부분이 생기기 마련입니다.

 

잘 다듬은 프롬프트를 활용하면 AI가 빠르게 케이스를 생성하고 우선순위까지 매겨줍니다.

 

이 패턴을 익히면 AI를 단순한 코드 생성 도구가 아닌, 테스트 설계의 강력한 파트너로 만들 수 있어요.

 

 

탐정에게 단서만 주면 범인을 찾듯, 프롬프트의 힘

중학생 때 추리 소설을 읽는다고 생각해 보세요.

 

작가가 “의심스러운 인물들, 사건 현장, 피해자 정보”만 주면 독자가 머릿속으로 여러 가능성을 그려보죠.

 

좋은 프롬프트도 마찬가지예요.

 

AI에게 명확한 단서(명세나 PR 내용)를 주면, 가능한 테스트 시나리오를 풍부하게 뽑아냅니다.

 

AI 시대 이전에는 테스터가 모든 케이스를 머리로 고민해야 했습니다.

 

이제는 AI가 빠르게 초안을 만들어주지만, 프롬프트가 모호하면 엉뚱한 결과가 나옵니다.

 

핵심은 “구체적이고, 역할 부여하고, 맥락을 충분히 주는” 것입니다.

 

 

명세나 PR을 입력할 때 효과적인 프롬프트 패턴

먼저 PR diff나 기능 명세를 복사해서 AI에게 전달합니다.

 

좋은 프롬프트 예시는 다음과 같아요.

 

“너는 경험이 많은 소프트웨어 테스터이자 품질 아키텍트다.

 

주어진 PR 변경 사항과 기능 명세를 바탕으로, 사용자 관점과 위험 관점에서 테스트 케이스를 만들어줘.

• 긍정 시나리오, 부정 시나리오, 경계값, 보안·성능 관련 케이스까지 포함
• 각 케이스에 위험도(높음/중간/낮음)와 우선순위를 매겨줘
• Playwright 코드 스니펫도 간단히 제안해

PR 내용: [여기에 PR diff나 명세 붙여넣기]

 

이렇게 하면 AI가 무작정 많은 케이스를 나열하는 대신, 중요한 것부터 정리해 줍니다.

 

특히 “위험도”를 명시적으로 요청하면, 실제 프로덕션에서 터질 가능성이 높은 부분에 집중할 수 있어요.

 

 

우선순위화하는 감각 키우기

AI가 생성한 케이스를 그대로 받아들이지 말고, 사람의 눈으로 다듬는 과정이 중요합니다.

 

예를 들어 로그인 기능 변경 PR이라면:

• 비밀번호 오류 5회 후 계정 잠금 시나리오는 위험도가 높아 최우선
• UI 레이아웃 변화는 시각적 회귀 테스트로 중간 우선순위
• 오래된 브라우저 지원은 낮은 우선순위로 미룰 수 있음

이렇게 위험도, 변경 영향 범위, 사용자 영향도를 기준으로 재정렬하면 테스트 효율이 크게 올라갑니다.

 

처음에는 AI에게 “이 케이스들을 위험도 순으로 재정렬해줘”라고 추가 프롬프트를 주는 것도 좋은 연습입니다.

 

 

실전에서 바로 써먹는 작은 습관

PR 리뷰를 할 때마다 위 패턴의 프롬프트를 사용해 보세요.

 

AI가 제안한 케이스를 Playwright 테스트로 빠르게 변환하고, Trace Viewer로 검증하는 흐름을 반복하면 자연스럽게 프롬프트 실력이 늘어납니다.

 

특히 복잡한 기능일수록 “중학생도 이해할 수 있게 비유를 들어 설명하면서 케이스 생성”처럼 지시를 추가하면, AI가 더 이해하기 쉬운 결과물을 줍니다.

 

이 프롬프트 설계 능력을 익히면 AI는 더 이상 ‘그냥 코드 짜주는 친구’가 아니라, 테스트 전략을 함께 고민하는 파트너가 됩니다.

 

명세 한 장만으로도 강력한 테스트 계획이 뽑혀 나오는 경험은 테스터를 품질 아키텍트로 성장시키는 큰 발판이 될 거예요.

 

이제 AI를 활용한 테스트 설계의 맛을 제대로 느껴보세요.

 

다음 단계에서는 에이전트가 대신할 수 있는 영역과 한계를 더 깊이 파헤쳐 보겠습니다.