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가 “완성!”이라고 내놓는 30분 데모는 반짝반짝 빛납니다.
기능은 보이고, 화면은 예쁘고, 속도도 빠르죠.
하지만 실제 사용자 수천 명이 동시에 접속하고, 예상치 못한 네트워크 지연이 생기고, 오래된 기기에서 접근하면? 그때부터 이야기가 달라집니다.
오류가 쏟아지고, 데이터가 꼬이며, 보안 구멍이 드러나요.
이게 바로 30분 데모와 프로덕션 사이의 거리예요.
많은 팀이 이 거리를 과소평가하다가 큰 비용을 치릅니다.
저는 테스터로 수많은 프로젝트를 겪으면서 이 간극을 뼈저리게 느꼈고, 이제는 그 간극을 좁히는 ‘품질 아키텍트’로서 팀을 이끌고 있습니다.
현실을 직시해야 변화가 시작된다
학생 때 레고로 로봇을 만들 때를 떠올려 보세요.
작은 조각 몇 개로 예쁜 모양은 금방 나오지만, 실제로 움직이게 하려면 관절을 어떻게 연결할지, 무게 중심은 어디에 둘지, 배터리는 얼마나 갈지 미리 계산해야 해요.
계산 없이 그냥 붙이면 로봇은 몇 초 만에 고장 납니다.
AI 시대의 소프트웨어도 마찬가지입니다.
AI가 코드를 빠르게 만들어주고, 테스트 케이스도 제안해주지만, 그 결과물이 실제 운영 환경에서 버틸 수 있는지는 별개의 문제예요.
- 사용자가 갑자기 폭주할 때 서버는 어떻게 견딜까?
- 오래된 브라우저나 느린 인터넷에서는 화면이 제대로 보일까?
- 누군가 악의적으로 공격하면 데이터는 안전할까?
- 6개월 후 기능이 바뀌었을 때 기존 테스트는 여전히 믿을 수 있을까?
이런 질문에 답하지 못하면, 아무리 멋진 AI 도구를 써도 결국 ‘데모용 장난감’에 그칩니다.
진짜 품질 아키텍트는 이런 질문을 미리 던지고, 시스템 전체에 답을 설계하는 사람입니다.
이 연재에서 함께 걸을 길
이 시리즈는 테스터인 당신이 시스템 품질 설계자로 한 걸음씩 나아갈 수 있도록 돕기 위해 만들었습니다.
중학생도 이해할 수 있게 비유를 많이 쓰면서, 실전에서 바로 써먹을 수 있는 내용만 담을 거예요.
먼저 Part 0에서는 현실을 정확히 인식하는 데 집중합니다.
데모와 프로덕션의 차이를 직시하고, 앞으로 배울 방향을 함께 그려보죠.
이어서 기초 체력을 다지는 Part 1에서는 AI가 만든 코드를 읽는 눈, Git으로 변경을 관리하는 습관, 웹과 API가 어떻게 움직이는지, 인증의 기본 원리를 차근차근 익힙니다.
마치 자전거 타기를 배울 때 균형 잡는 법부터 배우는 것처럼요.
Part 2에서는 Playwright라는 든든한 도구를 깊이 파고들어 테스트 자동화를 내 것으로 만듭니다.
불안정한 테스트(플래키)를 잡는 방법, 실패 영상을 통해 원인을 빠르게 찾는 기술까지.
Part 3이 연재의 핵심입니다.
AI를 단순 도구가 아닌 ‘차별화 무기’로 만드는 방법. 프롬프트로 테스트를 설계하고, 에이전트가 대신할 수 있는 부분과 사람이 끝까지 해야 할 부분을 명확히 구분합니다.
특히 AI의 환각을 걸러내는 인간 검증 체계를 만드는 법은 여러분의 가장 큰 경쟁력이 될 거예요.
이후 파이프라인, 비기능 품질(성능·보안·부하), 그리고 전략과 리더십까지.
30화에 걸쳐 테스터에서 품질 아키텍트로 성장하는 전체 여정을 함께 그려나갈 계획입니다.
지금, 한 걸음 내디뎌보세요
30분 데모가 빛나는 순간은 누구나 만들 수 있습니다.
하지만 그 빛이 실제 사용자에게까지 오래도록 지속되게 하는 것은, 현실을 직시하고 체계적으로 준비한 사람만이 할 수 있어요.
이 연재를 따라오다 보면, 당신도 “데모는 예쁘지만 실전은 다르다”는 말을 더 이상 한숨으로 하지 않게 될 겁니다.
대신 “이렇게 설계했으니 버틸 수 있어”라는 자신감으로 바뀔 거예요.
첫걸음, Part 0부터 시작합니다. 함께 현실을 보고, 방향을 잡아봅시다.