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화. 테스터에서 품질 아키텍트로
MCP로 여러 조각을 하나로 연결해 보는 순간, 통합의 진짜 약점이 보인다
UI 테스트와 API 테스트를 따로 익혔지만, “이 기능이 실제로 전체 시스템에서 잘 돌아갈까?” 하는 불안이 남아 있다면, MCP 기반 통합 검증이 답입니다.
Playwright MCP 에이전트를 활용해 프론트엔드와 백엔드, 외부 서비스까지 자연스럽게 연결 검증하면, 데모에서는 보이지 않던 통합 문제를 빠르게 잡아낼 수 있어요.
AI 에이전트가 직접 움직이며 테스트하는 실습을 통해 통합 품질을 한 단계 끌어올려보겠습니다.
퍼즐 조각을 맞추는 로봇 조수
큰 퍼즐을 맞추는 상황을 떠올려보세요.
한 조각 한 조각은 예쁘게 잘려 있지만, 실제로 다 맞춰보면 연결 부분이 안 맞거나 색이 어긋나는 경우가 많습니다.
혼자서 모든 조각을 하나씩 시험하다 보면 시간이 오래 걸리고, 중요한 연결 부위를 놓치기 쉽죠.
MCP 에이전트는 바로 그 퍼즐 조수를 맡아줍니다.
접근성 트리를 기반으로 브라우저를 조작하면서, 동시에 API 호출까지 확인하고, 여러 서비스 간 데이터 흐름을 스스로 따라가며 검증합니다.
단순 UI 클릭이 아니라 “로그인 → 주문 → 결제 → 재고 업데이트”처럼 실제 사용자 여정 전체를 통합적으로 테스트하는 거예요.
MCP로 통합 검증을 시작하는 실습 흐름
14화에서 npx playwright init-agents로 기반을 마련했다면, 이제 본격적으로 활용할 차례입니다.
먼저 Planner 에이전트에게 통합 시나리오를 지시해 보세요.
“e-commerce 사이트에서 사용자 로그인 후 상품을 장바구니에 담고, 결제까지 완료되는 전체 흐름을 테스트 계획으로 만들어줘.
각 단계에서 API 응답도 함께 검증해.”
Planner가 접근성 트리와 API 계약을 고려한 단계별 계획을 세우면, Generator 에이전트가 실제 Playwright 코드를 생성합니다.
여기서 MCP의 강점이 드러납니다. 에이전트는 단순히 화면을 클릭하는 게 아니라:
- 프론트엔드 화면 변화와
- 백엔드 API 호출 결과를
- 동시에 관찰하며
불일치(예: 화면에는 성공이라고 나오는데 실제 재고는 줄지 않은 경우)를 찾아냅니다.
실습할 때는 Trace Viewer를 반드시 켜두세요.
에이전트가 어떤 순서로 움직였는지, 어느 지점에서 API 응답이 늦었는지, 데이터가 제대로 전달되었는지 영상처럼 되감아볼 수 있습니다.
특히 외부 서비스(결제 게이트웨이 등)와의 연동은 Mock을 적절히 섞어 안정적으로 테스트하는 연습을 해보는 게 좋습니다.
통합 검증에서 빛나는 MCP의 실전 감각
MCP 기반 접근은 기존의 개별 테스트와 달리 엔드투엔드(E2E) 관점을 자연스럽게 가져옵니다.
AI 에이전트가 스스로 “다음 단계로 넘어가도 될까?”를 판단하면서 움직이기 때문에, 테스터가 모든 클릭과 확인을 일일이 코딩하지 않아도 됩니다.
물론 완벽하지 않습니다.
복잡한 비즈니스 규칙이나 예상치 못한 에지 케이스는 여전히 사람의 최종 검토가 필요해요.
하지만 MCP를 활용하면 통합 테스트 작성 시간이 크게 줄고, 실제 운영 환경과 가까운 시나리오를 빠르게 탐색할 수 있다는 게 가장 큰 장점입니다.
이 실습을 반복하다 보면 AI 에이전트가 단순한 코드 생성기를 넘어, 통합 문제를 능동적으로 탐지하는 파트너로 느껴질 겁니다.
PR이 올라올 때마다 “이 변경이 다른 서비스에 미치는 영향은?”을 MCP에게 물어보는 습관을 들여보세요.
통합을 지키는 눈이 품질 아키텍트의 힘
MCP로 통합 검증을 익히는 순간, 테스터는 더 이상 개별 기능만 보는 사람이 아닙니다.
시스템 전체가 어떻게 연결되고, 어디서 균열이 생길 수 있는지 설계 단계부터 고려하는 품질 아키텍트의 시야를 갖게 됩니다.
이 능력이 쌓이면 데모와 프로덕션 사이의 거리가 한층 더 좁혀집니다.
다음 화에서는 AI가 만든 결과를 얼마나 믿을 수 있는지, 환각을 걸러내는 인간 검증 체계를 함께 다뤄보겠습니다.