1화. AI가 짠 코드를 읽는 눈 — Python 또는 JS/TS 중 하나를 코드 리뷰 가능한 수준까지. 실습: AI가 생성한 테스트 코드의 버그 3개 찾기.

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 (연재 핵심)
10화. 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가 코드를 뚝딱 만들어도, 버그를 찾아내는 눈을 기르는 순간

 

테스터인데 AI가 쏟아내는 코드를 보면서 “이게 제대로 된 건가?” 싶어 불안한가요.

 

Python이나 JavaScript/TypeScript 중 하나를 코드 리뷰할 수 있는 수준까지 끌어올리면, AI의 빠른 생산성을 진짜 품질로 바꿀 수 있습니다.

 

이해하기 쉽게 비유하며, 실제 AI 생성 테스트 코드의 버그를 직접 찾아보는 실습까지 준비했습니다.

 

레고 설명서를 읽듯 코드 읽는 눈부터 시작하자

중학생 때 레고 설명서를 보면서 “이 조각은 여기 연결되고, 이 부분은 움직이게 하는구나” 하고 이해했던 기억이 있나요?

 

코드도 똑같아요.

 

설명서처럼 코드 한 줄 한 줄이 “이걸 이렇게 해라”는 지시사항입니다.

 

AI가 설명서를 대신 써주지만, 설명서에 잘못된 부분이 있으면 레고 작품이 무너지죠.

 

AI 시대 테스터는 코드를 처음부터 짜는 사람이 아니라, AI가 만든 코드를 제대로 읽고 검증하는 사람이 되어야 합니다.

 

Python은 비교적 읽기 쉽고, JS(JavaScript)/TS(TypeScript)는 웹 테스트(Playwright)에서 자주 쓰이니 둘 다 기본 감각을 익히는 게 좋습니다.

 

여기서는 실습 편의를 위해 Playwright 기반 JavaScript 코드를 중심으로 설명하겠습니다.

 

코드의 기본 구조를 먼저 잡아보자

코드를 볼 때 가장 먼저 보는 건 큰 그림입니다. 마치 레고 상자 뚜껑에 그려진 완성품 사진처럼요.

• import / require: “어떤 도구를 사용할 거야”를 알려주는 부분
• 테스트 함수: “이걸 실행해 볼게”라는 본체
• expect / assert: “이 결과가 나와야 정상이야”라는 확인 부분

예를 들어 Playwright 테스트 코드는 보통 이렇게 시작합니다.

const { test, expect } = require('@playwright/test');

test('로그인 테스트', async ({ page }) => {
  await page.goto('https://example.com/login');
  // ... 나머지 코드
});

이 구조를 익히면 AI가 아무리 복잡한 코드를 만들어도 “아, 이건 로그인 화면을 테스트하는구나” 하고 바로 감을 잡을 수 있습니다.

 

 

AI가 만든 테스트 코드에서 흔히 보이는 버그 3가지 실습

이제 직접 실습해 볼 차례예요. 아래는 AI에게 “Playwright로 로그인 기능을 테스트해 달라”고 요청했을 때 나올 법한 코드입니다.

 

일부러 3개의 버그를 넣었어요. 코드를 천천히 읽어보고, 어디가 이상한지 찾아보세요.

const { test, expect } = require('@playwright/test');

test('사용자 로그인 성공', async ({ page }) => {
  await page.goto('https://example.com');

  await page.click('#login-button');
  await page.fill('#username', 'testuser');
  await page.fill('#password', 'password123');

  await page.waitForTimeout(5000); // 로그인 대기

  const welcomeText = await page.textContent('.welcome');
  expect(welcomeText).toBe('환영합니다'); 

  await page.screenshot({ path: 'login-success.png' });
});

 

버그를 찾았나요? 하나씩 함께 풀어보겠습니다.

 

첫 번째 버그: await page.waitForTimeout(5000)
이건 “무조건 5초 기다려”라는 명령인데, 불안정한 테스트(플래키)의 주범입니다.

 

네트워크가 빠르면 2초면 충분한데도 5초를 기다리거나, 느리면 실패합니다.

 

제대로 된 방법은 waitForSelector나 waitForResponse처럼 실제 조건을 기다리는 거예요.

 

두 번째 버그: expect(welcomeText).toBe('환영합니다')
텍스트를 정확히 비교하는데, 실제 사이트에서는 “환영합니다, testuser님!”처럼 뒤에 이름이 붙거나 공백이 있을 수 있습니다. toContain('환영합니다')처럼 포함 여부를 확인하는 게 더 안전합니다.

 

 

세 번째 버그: 페이지 URL을 'https://example.com'으로 갔는데, 로그인 버튼과 입력창은 로그인 페이지에 있을 가능성이 큽니다.

 

goto 후 바로 로그인 페이지로 이동하거나, 로그인 링크를 클릭하는 단계가 빠졌어요.

 

영향 범위를 제대로 고려하지 않은 전형적인 실수입니다.

 

이처럼 AI 코드는 빠르게 나오지만, 이런 작은 구멍이 실제 실행에서 큰 문제를 만듭니다.

 

여러분도 AI에게 코드를 만들게 한 뒤, 위와 같은 눈으로 검토하는 연습을 반복해 보세요.

 

 

코드 읽는 눈이 품질 아키텍트의 기초가 된다

처음엔 코드가 낯설게 느껴지겠지만, 레고 설명서를 여러 번 보다 보면 자연스럽게 익숙해지듯, 매일 조금씩 PR diff와 테스트 코드를 읽다 보면 감이 생깁니다.

 

Python을 선호한다면 Pytest나 Selenium 코드로, JS/TS를 좋아한다면 Playwright로 연습하면 됩니다.

 

이 눈을 기르면 단순히 “테스트가 실패했어요”가 아니라 “이 부분이 이렇게 바뀌어서 실패하는구나, 이렇게 고치면 되겠네”까지 이야기할 수 있게 됩니다.

 

AI가 코드를 만드는 시대에, 그 코드를 제대로 읽고 다듬는 사람이 바로 진짜 품질을 설계하는 아키텍트입니다.

 

작은 실습 하나부터 시작해 보세요.

 

오늘 AI에게 테스트 코드 하나를 만들어 달라고 한 뒤, 위처럼 3가지 이상의 개선점을 찾아보는 거예요.

 

그 연습이 쌓일수록 시스템 전체를 보는 시야가 넓어질 겁니다.