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화. 테스터에서 품질 아키텍트로
웹 페이지가 “한 번 클릭”으로 바뀌는 순간, HTTP와 쿠키가 실제로 하는 일
테스터로서 화면은 예쁘게 나오는데 왜 로그인이 풀리고, 장바구니가 사라지고, 새로고침할 때마다 상태가 초기화되는지 답답한가요.
HTTP 요청·응답과 쿠키·세션의 기본 원리를 중학생도 이해할 수 있게 풀어보면, 개발자도구만으로도 버그의 실마리를 빠르게 잡을 수 있습니다.
식당에서 음식 주문하는 것처럼 웹은 대화한다
상상해 보세요. 여러분이 식당에 들어가서 “치킨 1인분 주세요”라고 종이에 적어 종업원에게 건넵니다.
종업원이 주방에 전달하고, 잠시 후 치킨이 나와요.
이 과정이 바로 HTTP입니다.
- Request(요청): 브라우저가 서버에게 “이 페이지 보여줘”, “로그인해줘”, “장바구니에 물건 넣어줘”라고 보내는 편지예요.
- Response(응답): 서버가 “여기 페이지입니다”, “로그인됐어요”, “장바구니 업데이트됐습니다” 하고 답장을 보내는 거죠.
이 편지는 보통 매우 빠르게 오가지만, 내용이 길거나 사진이 많으면 조금 늦어집니다.
개발자도구의 Network 탭을 열면 이 편지들이 실시간으로 쌓이는 모습을 그대로 볼 수 있어요.
왜 새로고침하면 장바구니가 사라질까? 쿠키와 세션의 역할
식당에서 자리에 앉아 “아까 주문한 치킨 아직 안 나왔어요”라고 다시 말할 필요가 없도록, 종업원이 “3번 테이블 손님”이라고 기억해 주는 시스템이 필요하죠.
웹에서도 마찬가지예요.
쿠키는 브라우저가 자신의 컴퓨터에 작은 메모지를 저장해 두는 것입니다.
“내가 누구인지(아이디), 로그인 상태, 장바구니에 뭐가 들었는지” 같은 정보를 조금씩 적어둡니다.
서버가 “이 메모지 다시 가져와”라고 하면 브라우저가 쿠키를 함께 보내줘요.
세션은 서버 쪽에서 그 정보를 더 안전하게 관리하는 방법입니다.
서버가 “이 사람은 3번 손님”이라고 표를 만들어 관리하고, 브라우저에게는 세션 ID(작은 번호표)만 쿠키로 줍니다.
이렇게 하면 중요한 정보(비밀번호, 개인정보)는 서버에만 남아 안전해요.
로그인이 풀리거나 상태가 사라지는 버그는 대부분 이 쿠키와 세션이 제대로 주고받지 못하거나, 만료되거나, 다른 기기에서 충돌할 때 발생합니다.
개발자도구로 직접 요청과 응답을 해부해 보자
실제로 연습해 볼 시간입니다. 크롬 브라우저에서 F12 키를 눌러 개발자도구를 열고, Network 탭으로 이동하세요.
- 아무 사이트(예: 네이버나 테스트 쇼핑몰)에 들어가 보세요.
- 페이지가 로드되면서 수많은 요청이 쌓입니다. 가장 위에 있는 문서 타입(HTML)을 클릭해 보세요.
- Headers를 보면 Request URL, Method(GET/POST), Status Code(200 성공, 404 없음, 500 오류 등)를 바로 확인할 수 있어요.
- 로그인 버튼을 눌러보거나 물건을 장바구니에 담아보세요. 새로 생긴 요청 중 Cookies 탭을 클릭하면 어떤 정보가 오가는지 볼 수 있습니다.
- Response 탭에서는 서버가 실제로 준 내용을 들여다볼 수 있어요.
특히 Status Code가 401(인증 실패), 403(권한 없음), 429(너무 많은 요청) 같은 숫자가 뜨면 바로 “여기 문제가 있구나” 하고 알 수 있습니다.
AI가 만든 코드라도 이 부분을 직접 눈으로 확인하는 습관이 테스터의 큰 힘입니다.
작은 대화의 차이가 큰 안정성을 만든다
HTTP는 stateless(기억하지 않는) 특성을 가지고 있지만, 쿠키와 세션이 그 기억을 이어주는 다리 역할을 합니다.
이 원리를 이해하면 “왜 이 화면에서만 이상하지?” 하는 버그의 원인을 훨씬 빠르게 찾아낼 수 있어요.
개발자도구 Network 탭을 매일 조금씩 열어보는 것만으로도 웹이 어떻게 움직이는지 감이 잡힙니다.
처음엔 요청이 너무 많아 당황스럽겠지만, 중요한 요청 몇 개만 집중해서 보면 충분해요.
이 눈을 기르면 PR diff를 볼 때도 “이 API 호출이 바뀌었으니 쿠키 처리도 확인해야겠네” 하고 자연스럽게 연결지어 생각하게 됩니다.
웹의 기본 언어를 이해하는 순간, 테스터는 단순히 화면을 클릭하는 사람이 아니라 시스템 전체 흐름을 읽는 품질 아키텍트로 한 걸음 더 다가갑니다.