테스트의 모든것

7화. 플래키의 근원, 셀렉터와 대기 — 안정적 셀렉터와 비동기 대기 전략.

testmanager — Fri, 10 Jul 2026 07:30:13 +0900

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화. 테스터에서 품질 아키텍트로

플래키 테스트의 뿌리를 뽑는 순간, 자동화가 진짜 믿음직한 동반자가 된다

테스트를 돌리다 보면 “이번엔 왜 실패하지?” 하며 한숨 쉬는 일이 반복됩니다.

특히 Playwright로 자동화를 시작한 초보 테스터가 가장 먼저 부딪히는 벽이 바로 플래키(flaky) 테스트예요.

이번 화에서는 그 불안정한 근원을 파헤치고, 안정적인 셀렉터와 비동기 대기 전략을 이해하기 쉽게 풀어보겠습니다.

흔들리는 다리와 단단한 기둥

상상해 보세요.

학교 체육시간에 줄넘기를 하는데, 줄이 너무 느슨하거나 바람이 불면 계속 실패합니다.

반대로 줄이 팽팽하고 타이밍을 잘 맞추면 성공률이 높아지죠.

플래키 테스트는 바로 그 느슨한 줄과 같습니다.

페이지가 완전히 로드되기 전에 버튼을 클릭하거나, 요소의 위치가 자주 바뀌는 셀렉터를 사용하면 테스트가 “가끔 성공하고 가끔 실패”합니다.

이 불안정성은 CI/CD 파이프라인에서 큰 골칫거리가 되고, 결국 팀이 자동화를 포기하게 만드는 주범이 됩니다.

플래키의 가장 큰 원인, 불안정한 셀렉터

많은 사람들이 XPath나 복잡한 CSS 선택자를 사용합니다.

예를 들어 div:nth-child(3) > button처럼 위치에 의존하면, 디자인이 조금만 바뀌어도 테스트가 깨집니다.

마치 친구 얼굴을 “세 번째 줄 네 번째 아이”로 기억하는 것과 같아요.

친구가 자리를 옮기면 바로 못 찾죠.

Playwright에서는 훨씬 단단한 방법을 권장합니다.

가장 추천하는 순서

먼저 getByRole()을 사용하세요. 접근성(ARIA) 역할을 기준으로 찾기 때문에 “로그인 버튼”, “검색 입력창”처럼 의미를 가진 요소를 안정적으로 잡아냅니다.

await page.getByRole('button', { name: '로그인' }).click();

다음으로 getByTestId()를 활용합니다.

개발자에게 “test-id='submit-button'” 같은 속성을 미리 넣어달라고 요청하면, 디자인이나 구조가 바뀌어도 흔들리지 않는 강력한 앵커가 생깁니다.

getByLabel(), getByPlaceholder(), getByText()도 유용합니다.

이처럼 의미와 의도를 기반으로 요소를 찾는 습관을 들이면, 셀렉터 때문에 실패하는 일이 크게 줄어듭니다.

비동기 세상의 타이밍, 스마트 대기 전략

현대 웹은 주문하면 바로 오는 게 아니라, 요리사(서버)가 준비할 때까지 기다려야 하는 레스토랑과 같습니다.

AJAX 호출, 애니메이션, 동적 로딩 때문에 페이지가 “거의” 로드된 상태에서 테스트가 진행되면 실패하기 십상입니다.

Playwright의 가장 큰 강점은 자동 대기(Auto-waiting)입니다.

click(), fill(), expect().toBeVisible() 같은 명령을 쓸 때 알아서 필요한 순간까지 기다려줍니다.

하지만 가끔 더 명확한 전략이 필요합니다.

page.waitForLoadState('networkidle') : 네트워크 요청이 잠잠해질 때까지 기다림
await expect(page.getByRole('heading')).toBeVisible({ timeout: 10000 }) :
특정 요소가 나타날 때까지 최대 10초 기다림
page.locator().first()이나 filter()를 활용해 조건에 맞는 요소를 정확히 지정

특히 SPA(Single Page Application)에서는 URL 변화나 특정 텍스트 등장까지 기다리는 것이 효과적입니다.

실전에서 바로 써먹는 안정화 팁

코드 작성할 때 “이 요소가 정말 안정적으로 보일까?”를 항상 자문해 보세요.

AI가 생성한 테스트 코드도 이 관점에서 검토하면 많은 플래키를 미리 잡아낼 수 있습니다.

Trace Viewer를 활용해 실패한 테스트를 영상처럼 돌려보면, 어느 순간 셀렉터가 실패했는지, 대기가 부족했는지 바로 파악됩니다.

처음에는 테스트가 조금 느려지더라도 안정성을 최우선으로 하다 보면, 전체 실행 속도도 오히려 빨라지는 마법을 경험하게 될 거예요.

플래키를 잡는 습관이 품질 아키텍트의 첫걸음

플래키의 근원을 이해하고 셀렉터와 대기 전략을 제대로 세우는 순간, 자동화 스위트는 단순한 스크립트가 아니라 신뢰할 수 있는 품질 지킴이가 됩니다.

이 기본기를 탄탄히 다지면 다음 단계에서 더 복잡한 시나리오도 자신 있게 다룰 수 있어요.

불안정한 테스트 하나하나를 잡아나가다 보면, 데모가 아닌 진짜 프로덕션 환경에서도 든든하게 버티는 시스템을 만들 수 있다는 자신감이 생길 겁니다.

6화. 왜 Playwright인가 — 도구 선택의 근거와 첫 테스트 작성.

testmanager — Thu, 9 Jul 2026 07:21:37 +0900

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화. 테스터에서 품질 아키텍트로

테스터가 Playwright를 선택하는 순간, 자동화가 진짜 안정적으로 변한다

AI 시대에 테스트 자동화를 시작하려는 테스터라면 “Selenium, Cypress, Playwright… 뭐부터 해야 하지?” 하고 고민하게 됩니다.

왜 하필 Playwright인지, 실제로 첫 테스트를 어떻게 작성하는지 중학생도 이해할 수 있게 차근차근 풀어보겠습니다.

오래된 자전거와 최신 전기 스쿠터

중학생 때 자전거를 타고 학교를 다녔다고 생각해 보세요.

오래된 자전거는 페달을 열심히 밟아도 속도가 잘 안 나고, 바퀴가 헐거워져서 자주 고장 납니다.

그런데 최신 전기 스쿠터는 버튼 하나로 부드럽게 출발하고, 언덕도 쉽게 올라가며, GPS까지 알려줘요.

Selenium은 그 오래된 자전거와 비슷합니다.

한때 최고였지만, 현대 웹의 복잡한 동작(비동기, Shadow DOM, 모바일)을 다루려면 많은 노력과 우회 코드가 필요하죠.

반면 Playwright는 전기 스쿠터처럼 만들어졌어요.

Microsoft가 개발한 이 도구는 Chromium, Firefox, WebKit(사파리)까지 한 번에 지원하고, 자동 대기 기능이 뛰어나서 테스트가 훨씬 안정적입니다.

Playwright를 선택해야 하는 현실적인 이유

Playwright가 빛나는 첫 번째 이유는 신뢰성입니다.

웹 페이지가 로딩되는 동안 “이 버튼이 나타날 때까지 기다려” 같은 코드를 일일이 쓰지 않아도 됩니다.

자동으로 스마트하게 기다려주기 때문에 ‘플래키(flaky)’ 테스트, 즉 가끔 성공하고 가끔 실패하는 불안정한 테스트가 크게 줄어듭니다.

두 번째는 속도와 효율입니다. 병렬 실행이 기본으로 지원되고, 브라우저를 가볍게 제어할 수 있어 테스트가 빠르게 끝납니다.

실제 프로젝트에서 Selenium 대비 2~3배 빠른 경우도 흔해요.

세 번째는 현대 웹에 최적화되어 있다는 점입니다.

API 테스트, 파일 업로드·다운로드, 모바일 에뮬레이션, 네트워크 가로채기까지 한 도구로 모두 처리할 수 있어요.

특히 AI가 코드를 생성해주는 시대에 Playwright의 명확한 API는 AI가 만들어준 코드를 읽고 수정하기도 훨씬 수월합니다.

마지막으로 커뮤니티와 지속적인 업데이트가 활발하다는 것도 큰 장점입니다. 테스터가 성장하면서 필요한 기능이 계속 추가되고 있어요.

첫 테스트, 직접 손으로 작성해 보기

이론만 듣는 것보다 직접 타보는 게 중요하죠. Node.js가 설치되어 있다면 터미널에서 아래 명령어만 입력하면 Playwright 환경이 준비됩니다.

npm init playwright@latest

설치가 끝나면 tests/example.spec.ts 같은 파일이 생깁니다. 첫 테스트를 이렇게 작성해 보세요.

import { test, expect } from '@playwright/test';

test('Google 홈페이지에서 검색이 제대로 되는지 확인', async ({ page }) => {
  await page.goto('https://google.com');

  // 검색창에 'Playwright' 입력
  await page.getByRole('textbox', { name: '검색' }).fill('Playwright');
  await page.getByRole('button', { name: 'Google 검색' }).click();

  // 결과 페이지에 Playwright 관련 내용이 있는지 확인
  await expect(page.getByRole('heading', { name: /Playwright/ })).toBeVisible();
});

이 코드의 아름다운 점은 읽기 쉽다는 거예요.

“페이지로 가라, 입력해라, 클릭해라, 이게 보이는지 확인해라”처럼 사람 말처럼 자연스럽습니다.

실행은 npx playwright test 한 줄이면 끝납니다.

브라우저가 자동으로 열리면서 테스트가 진행되는 모습을 직접 볼 수 있어요.

Trace Viewer로 실패를 영상처럼 분석하기

테스트가 실패하면 npx playwright show-trace trace.zip 명령으로 Trace Viewer를 열어보세요.

마치 CCTV 영상을 돌려보듯, 클릭 하나하나와 화면 변화를 타임라인으로 확인할 수 있습니다.

이 기능 하나만으로도 디버깅 시간이 절반 이상 줄어듭니다.

Playwright로 시작하는 자동화 여정

Playwright를 선택하는 순간, 테스터는 단순히 “버튼 클릭 자동화”를 넘어서 시스템 전체 동작을 안정적으로 검증하는 품질 파트너가 됩니다.

AI가 테스트 코드를 제안해도, Playwright의 명확한 구조 덕분에 쉽게 검토하고 다듬을 수 있어요.

첫 테스트를 성공시켜보세요.

그 작은 성공이 모여서 데모가 아닌 진짜 프로덕션 품질을 지키는 든든한 기반이 됩니다.

다음 단계에서는 더 강력한 셀렉터와 대기 전략을 함께 파헤쳐 보겠습니다.

5화. API의 두 얼굴 — REST와 GraphQL의 차이와 테스트 관점. 실습: 같은 기능을 두 방식으로 호출·검증.

testmanager — Wed, 8 Jul 2026 08:11:54 +0900

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화. 테스터에서 품질 아키텍트로

API의 두 얼굴을 알면 테스트가 훨씬 똑똑해진다

테스터라면 REST API만 알던 시대에서 GraphQL까지 마주하게 된 순간, “이걸 어떻게 테스트해야 하지?” 하고 당황한 적이 있을 겁니다.

같은 기능을 두 방식으로 부르고 검증하는 실전 감각을 익히면, API 품질을 더 깊고 효율적으로 지킬 수 있습니다.

레고 상자와 레고 카탈로그, API의 두 가지 방식

중학생 때 친구 집에서 레고를 같이 맞춰본 적 있나요?

한 친구는 “빨간 블록 4개, 파란 지붕 1개, 바퀴 2개 주세요”라고 하나씩 요청합니다.

또 다른 친구는 “자동차 완성품 세트 하나 주세요”라고 한 번에 말하죠.

REST API는 첫 번째 친구 방식이고, GraphQL은 두 번째 친구 방식입니다.

둘 다 레고(데이터)를 가져오지만, 요청하는 방법과 받는 결과가 완전히 다릅니다.

REST에서는 URL과 HTTP 메서드( GET, POST 등 )로 자원을 지정합니다.

예를 들어 사용자 정보를 가져오려면 /users/123처럼 요청하죠.

필요한 데이터가 여러 곳에 있으면 여러 번 요청해야 합니다.

GraphQL은 하나의 endpoint(/graphql)로 모든 걸 처리합니다.

“사용자 123번의 이름, 이메일, 그리고 그 사람이 작성한 게시물 제목 3개만 알려줘”처럼 정확히 원하는 것만 한 번에 요청할 수 있어요.

REST의 장점과 테스터가 주의할 점

REST는 직관적이고 이해하기 쉽습니다. 각 기능마다 URL이 명확하니, “이 API는 사용자 등록만 한다”처럼 역할이 뚜렷하죠.

하지만 테스터 입장에서는 여러 번의 요청을 연속으로 보내야 하는 경우가 많아집니다.

예를 들어 사용자 프로필 페이지 하나를 검증하려면 로그인 → 사용자 정보 → 게시물 목록 → 댓글 수 등을 따로 불러와야 해요.

요청이 많아지면 네트워크 지연이 쌓이고, 중간에 하나라도 실패하면 전체 흐름이 깨지기 쉽습니다.

또한 over-fetching(필요 이상으로 많은 데이터 받기)과 under-fetching(데이터가 부족해서 추가 요청)이 자주 발생해요.

테스터는 이런 불필요한 데이터 전송이 성능에 미치는 영향을 꼭 확인해야 합니다.

GraphQL의 매력과 숨은 함정

GraphQL은 “정확히 필요한 데이터만” 받을 수 있어요.

한 번의 요청으로 화면에 필요한 모든 걸 가져오니, 모바일처럼 네트워크가 느린 환경에서 특히 빛납니다.

테스터 관점에서는 schema(데이터 구조 명세)가 매우 중요합니다.

schema가 잘 정의되어 있으면, 요청한 필드가 실제로 존재하는지, 타입이 맞는지 자동으로 검증할 수 있어요.

하지만 한 번의 요청에 너무 많은 걸 물어보면 서버 부하가 커질 수 있고, 복잡한 쿼리를 잘못 만들면 “N+1 문제”처럼 비효율적인 데이터베이스 호출이 발생합니다.

또 권한 검증이 세밀하게 필요해요.

“이 사용자는 이 필드를 볼 수 있나?”를 매번 체크해야 하죠.

같은 기능을 두 방식으로 직접 불러보고 검증하기

이해를 더 단단히 하려면 직접 손으로 만져보는 게 최고입니다. 간단한 실습을 해보죠.

먼저 무료 공개 API를 활용합니다.

REST로는 JSONPlaceholder (https://jsonplaceholder.typicode.com), GraphQL로는 공개 GraphQL API (예: https://countries.trevorblades.com) 등을 써보세요.

또는 Postman이나 VS Code의 REST Client, GraphQL Playground를 사용하면 편합니다.

REST 방식으로 사용자와 게시물 정보 가져오기

/users/1을 GET으로 호출해 사용자 정보를 받습니다.
그 사용자 id로 /posts?userId=1을 다시 호출해 게시물을 가져옵니다.
응답에 기대한 필드(이름, 이메일, 게시물 제목)가 있는지, 상태 코드가 200인지, 데이터 타입이 올바른지 확인합니다.

GraphQL 방식으로 한 번에 가져오기
같은 정보를 GraphQL 쿼리로 작성해 보세요.

query {
  user(id: "1") {
    name
    email
    posts {
      title
    }
  }
}

한 번의 요청으로 모든 게 돌아옵니다. 응답에서 불필요한 필드가 섞이지 않았는지, schema 오류는 없는지, 그리고 성능상 더 빠른지 비교해 보세요.

실습할 때 특히 신경 써야 할 점은 오류 처리와 인증입니다.

REST에서는 404, 401 같은 HTTP 상태 코드를 잘 봐야 하고, GraphQL에서는 errors 배열 안에 상세 메시지가 들어옵니다.

둘 다 다르게 검증해야 해요.

실제 프로젝트에서 적용하는 감각

프로젝트에 따라 REST가 적합할 때도 있고 GraphQL이 더 나을 때도 있습니다.

테스터로서 중요한 건 “이 API가 어떤 방식을 쓰든, 사용자에게 안정적으로 데이터가 전달되는가”를 확인하는 눈입니다.

요청 횟수, 데이터 양, 응답 시간, 권한 우회 가능성, schema 변화에 따른 회귀 등을 꾸준히 체크하다 보면 자연스럽게 두 얼굴의 차이를 몸으로 느끼게 됩니다.

이 감각을 익히면 AI가 생성한 API 테스트 코드도 더 날카롭게 검토할 수 있고, 개발자와 대화할 때도 “이 부분은 GraphQL에서 N+1 문제가 될 수 있으니…”처럼 구체적인 피드백을 줄 수 있어요.

첫 실습부터 조금씩 시작해 보세요. API의 두 얼굴을 제대로 알게 되는 순간, 테스트의 깊이가 한층 더 단단해질 겁니다.

4화. 인증의 지도 — OAuth·JWT·RBAC를 테스터 시선으로. 실습: 토큰 만료·권한 우회 시나리오 설계.

testmanager — Tue, 7 Jul 2026 08:00:43 +0900

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화. 테스터에서 품질 아키텍트로

로그인 한 번으로 모든 문이 열린 듯하지만, 실제로는 열쇠와 자물쇠가 복잡하게 얽혀 있다

테스터가 인증 문제를 제대로 이해하지 못하면, “로그인됐으니 다 될 거야”라는 착각 속에서 심각한 보안 구멍을 놓칩니다.

OAuth, JWT, RBAC를 테스터 눈으로 풀어보고, 토큰 만료와 권한 우회 시나리오를 직접 설계해 보는 시간을 가져보세요.

쉽게 이해할 수 있게 비유하며, 실전에서 바로 써먹을 수 있는 관점을 정리했습니다.

집 열쇠와 출입증이 따로 노는 이유

집에 들어갈 때 현관 열쇠 하나만 있으면 모든 방이 열리나요?

아니죠. 현관은 공용 열쇠, 안방은 별도 열쇠, 중요한 금고는 비밀번호까지 필요합니다.

웹 인증도 똑같아요. 단순 로그인 하나로 끝나지 않고 여러 층위의 ‘열쇠’와 ‘자격 확인’이 작동합니다.

OAuth는 “다른 서비스의 문을 대신 열어달라”고 부탁하는 시스템입니다.

예를 들어 구글 계정으로 네이버나 카카오에 로그인하는 거예요.

내가 직접 비밀번호를 주는 대신, 구글이 “이 사람이 맞아요”라는 임시 출입증을 발급해 주는 방식입니다.

테스터 관점에서는 OAuth 흐름이 제대로 끊기지 않는지, 리다이렉트가 이상하지 않은지, 토큰이 안전하게 전달되는지를 집중해서 봐야 합니다.

JWT는 그 출입증 자체를 말합니다.

Json Web Token의 약자로, 서버가 사용자 정보를 작은 종이쪽지에 적어 서명까지 해서 주는 것입니다.

이 쪽지는 브라우저나 앱이 매번 서버에 보여주며 “나 이 사람 맞아요”라고 증명합니다.

구조는 Header·Payload·Signature 세 부분으로 나뉘는데, Payload에 사용자 아이디, 권한, 만료 시간 등이 들어갑니다.

테스터가 특히 주의할 점은 JWT가 한 번 발급되면 서버가 따로 기억하지 않는다는 것입니다.

그래서 만료 시간을 제대로 설정하지 않거나, 서명이 약하면 큰 문제가 생깁니다.

RBAC는 Role Based Access Control, 즉 “역할에 따른 권한 관리”예요.

일반 직원은 파일 보기는 되지만 수정은 안 되고, 관리자는 모든 걸 할 수 있는 식입니다.

코드상에서 “이 역할의 사용자는 이 API를 호출할 수 있다”는 규칙이 명확히 설계됐는지를 확인하는 게 테스터의 역할입니다.

토큰 만료와 권한 우회 시나리오 직접 설계해 보기

이제 실습입니다. 개발자도구와 Postman 같은 도구를 열고 직접 테스트 시나리오를 만들어 보세요.

먼저 토큰 만료 시나리오.

JWT에는 보통 exp(만료 시간)가 들어갑니다.

사용자가 로그인한 뒤 30분이 지나면 자동으로 로그아웃되게 설계하는 거죠.

하지만 실제로는 이렇게 깨지기 쉽습니다.

브라우저를 오래 켜두고 작업하다가 갑자기 “인증 만료” 오류가 뜨는 경우
토큰이 만료됐는데도 이전 캐시된 데이터로 계속 동작하는 경우
모바일 앱에서 백그라운드로 돌아갔다가 다시 들어올 때 토큰 갱신(refresh token)이 제대로 안 되는 경우

이런 상황을 미리 테스트 계획에 넣어 두면 사용자 불편을 크게 줄일 수 있습니다.

다음으로 권한 우회 시나리오.

RBAC가 제대로 안 되어 있으면 공격자가 일반 사용자 권한으로 관리자 메뉴에 들어갈 수 있습니다.

URL을 직접 바꿔서 /admin/dashboard로 접근해 보기
JWT Payload를 디코딩해서 role을 “admin”으로 조작한 뒤 다시 서명 없이 보내기 (서버가 검증을 제대로 하는지 확인)
다른 사용자 아이디를 가진 토큰을 빌려서 API 호출해 보기 (IDOR, Insecure Direct Object Reference)
OAuth로 로그인한 뒤 권한 스코프(scope)가 제대로 제한됐는지 테스트

이 시나리오들을 PR diff에서 인증 관련 코드가 바뀌었다는 걸 발견하면 바로 적용해 보세요.

개발자도구의 Application 탭에서 Storage → Cookies와 Local Storage를 열어 토큰이 어떻게 저장되고 사라지는지도 직접 관찰하면 감이 빨리 잡힙니다.

인증을 이해하는 순간, 보이지 않던 구멍이 보인다

OAuth로 문을 열고, JWT로 신원을 증명하고, RBAC로 “이 사람은 여기까지”를 제한하는 전체 흐름을 이해하면, 단순한 기능 테스트를 넘어 보안 품질까지 설계할 수 있습니다.

AI가 인증 코드를 빠르게 만들어줘도, 우리가 그 열쇠와 자물쇠의 연결을 제대로 검증하지 않으면 프로덕션에서 큰 사고가 납니다.

작은 변화 하나가 인증 체계를 흔들 수 있다는 걸 항상 기억하세요.

오늘부터 로그인 관련 PR이 올라오면 diff를 열고 “토큰은 어떻게 관리하나? 권한은 제대로 제한되나?”를 질문하는 습관을 들여보세요.

이 눈이 바로 테스터를 시스템 품질 아키텍트로 만들어주는 핵심입니다.

28화. 표준과 AI를 잇다 — KOLAS 인정 요건·품질 표준을 AI 검증 체계로 연결하는 도메인 전문성.

testmanager — Tue, 7 Jul 2026 07:27:33 +0900

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를 잇다: 건축물 안전 진단처럼, 식품 영양 성분 표시처럼

우리는 매일 수많은 제품과 서비스를 이용하며 알게 모르게 표준의 보호를 받고 있습니다.

건축물의 안전 진단 기준이 건물의 붕괴를 막고, 식품의 영양 성분 표시가 우리가 먹는 음식의 안전과 건강을 보장하듯이, 소프트웨어에도 그 품질을 가늠하는 엄격한 표준이 존재합니다.

특히 AI가 코드를 짜고 테스트를 자동화하는 시대에, 이러한 표준은 더욱 중요해지고 있습니다.

오늘은 자칫 딱딱하게 느껴질 수 있는 KOLAS 인정 요건이나 국제 품질 표준(ISO/IEC 25010 등)이 어떻게 AI 기반의 현대적 검증 체계와 연결되어 품질 아키텍트의 독보적인 전문성이 되는지 이야기해 보겠습니다.

표준: 보이지 않는 곳에서 품질을 지키는 약속

지난 연재에서 우리는 AI를 지휘하는 운영 모델을 통해 팀의 생산성을 극대화하는 방법을 알아보았습니다.

이제는 AI가 만들어내는 결과물과 우리가 개발하는 소프트웨어 전체의 신뢰성을 어떻게 확보할 것인가에 대한 질문에 답할 차례입니다.

여기에 바로 표준이 등장합니다.

표준은 특정 제품, 서비스, 프로세스 또는 시스템이 특정 요구사항을 충족하는지 확인하기 위한 합의된 규칙, 지침 또는 특성입니다.

이는 마치 전 세계 모든 나라의 운전자가 동일한 교통 신호를 이해하고 따르듯이, 모두가 동의하는 품질의 기준점이 됩니다.

소프트웨어 분야에서 표준은 단순히 규제를 넘어, 개발 과정의 효율성을 높이고, 제품의 품질을 보장하며, 궁극적으로는 사용자에게 신뢰를 제공하는 중요한 역할을 합니다.

특히 AI 기술이 빠르게 발전하면서, AI 시스템의 품질과 신뢰성을 어떻게 평가하고 보장할 것인가에 대한 논의가 활발해지고 있으며, 기존의 소프트웨어 표준을 AI에 적용하거나 새로운 AI 관련 표준을 만들어가는 노력이 계속되고 있습니다.

KOLAS: 소프트웨어 품질의 국제 공인 시험소

KOLAS(Korea Laboratory Accreditation Scheme)는 한국인정기구의 약자로, 시험, 검사, 교정 기관의 기술 능력을 국제 표준에 따라 평가하여 공인하는 제도입니다 .

쉽게 말해, 어떤 기관이 특정 제품이나 서비스의 품질을 시험하고 그 결과를 보고서로 발행할 때, 그 보고서가 국제적으로 신뢰할 수 있는 공신력을 갖도록 인증해 주는 시스템입니다.

마치 건축물의 안전 진단을 하는 기관이 국가로부터공인된 자격을 갖추어야 그 진단 결과가 신뢰를 얻는 것과 같습니다.

소프트웨어 분야에서 KOLAS 공인 시험기관은 소프트웨어의 품질을 국제 표준에 따라 시험하고, 그 결과를 공인 시험성적서로 발행합니다.

이 성적서는 ILAC-MRA(국제상호인정협정)에 따라 전 세계 주요 국가에서 통용되므로, 우리 기업이 개발한 AI 및 소프트웨어 제품이 해외 수출 시 품질을 증명하는 데 매우 중요한 역할을 합니다 .

품질 아키텍트에게 KOLAS 인정 요건에 대한 이해는, 소프트웨어의 품질을 단순히 내부적으로만 확보하는 것을 넘어, 국제적인 신뢰도를 갖춘 검증 체계를 구축하는 데 필수적인 전문성이 됩니다.

ISO/IEC 25010: 소프트웨어 품질의 영양 성분표

ISO/IEC 25010은 소프트웨어 제품의 품질 특성을 정의하는 국제 표준입니다.

이는 마치 우리가 식품을 구매할 때 영양 성분표를 보고 어떤 성분이 얼마나 들어있는지 확인하듯이, 소프트웨어의 품질을 여러 가지 관점에서 체계적으로 평가할 수 있도록 돕는 소프트웨어 품질의 영양 성분표와 같습니다 .

이 표준은 소프트웨어 품질을 다음과 같은 8가지 주요 특성과 하위 특성으로 분류합니다.

주요 품질 특성	설명 (비유)
기능 적합성 (Functional Suitability)	소프트웨어가 필요한 기능을 얼마나 정확하고 완전하게 제공하는가 (예: 계산기가 정확하게 계산하는가)
성능 효율성 (Performance Efficiency)	소프트웨어가 주어진 자원(시간, 메모리 등)을 얼마나 효율적으로 사용하는가 (예: 앱이 얼마나 빠르고 부드럽게 작동하는가)
호환성 (Compatibility)	소프트웨어가 다른 시스템이나 환경과 얼마나 잘 어울려 작동하는가 (예: 여러 운영체제나 브라우저에서 잘 실행되는가)
사용성 (Usability)	사용자가 소프트웨어를 얼마나 쉽고 효율적으로 사용할 수 있는가 (예: 앱의 메뉴가 직관적이고 사용하기 편리한가)
신뢰성 (Reliability)	소프트웨어가 주어진 조건에서 얼마나 오랫동안 오류 없이 안정적으로 작동하는가 (예: 앱이 자주 멈추거나 다운되지 않는가)
보안성 (Security)	소프트웨어가 정보와 데이터를 얼마나 잘 보호하고, 무단 접근을 막는가 (예: 개인 정보가 안전하게 관리되는가)
유지보수성 (Maintainability)	소프트웨어를 얼마나 쉽게 수정, 개선, 확장할 수 있는가 (예: 개발자가 코드를 이해하고 변경하기 쉬운가)
이식성 (Portability)	소프트웨어를 다른 환경으로 얼마나 쉽게 옮겨 설치하고 사용할 수 있는가 (예: PC용 프로그램을 모바일에서도 쉽게 사용할 수 있는가)

이러한 품질 특성들은 소프트웨어의 설계, 개발, 테스트 전 과정에서 고려되어야 할 중요한 지침이 됩니다.

품질 아키텍트는 ISO/IEC 25010과 같은 표준을 활용하여 소프트웨어의 품질 목표를 설정하고, 각 특성에 대한 측정 지표를 정의하며, 개발된 소프트웨어가 이러한 표준을 충족하는지 검증하는 역할을 수행합니다.

AI 검증 체계와 도메인 전문성: 표준을 AI에 연결하다

AI 기술이 소프트웨어 개발에 깊숙이 통합되면서, 기존의 품질 표준을 AI 시스템에 어떻게 적용하고 검증할 것인가가 중요한 과제로 떠오르고 있습니다.

AI 모델의 성능, 공정성, 투명성, 견고성 등은 기존 소프트웨어 품질 특성과는 다른 새로운 관점의 검증을 요구합니다.

예를 들어, AI 기반의 이미지 인식 시스템이 특정 인종이나 성별에 대해 편향된 결과를 내놓는다면, 이는 기능 적합성뿐만 아니라 공정성이라는 새로운 품질 특성에서 문제가 발생한 것입니다.

여기서 품질 아키텍트의 도메인 전문성이 빛을 발합니다.

우리는 단순히 AI 도구를 사용하는 것을 넘어, KOLAS 인정 요건이나 ISO/IEC 25010과 같은 품질 표준을 AI 검증 체계에 연결하는 역할을 해야 합니다. 이는 마치 식품 영양 성분표를 보고 단순히 숫자를 읽는 것을 넘어, 각 성분이 우리 몸에 어떤 영향을 미치는지 이해하고, 개인의 건강 상태에 맞춰 식단을 조절하는 전문가의 역할과 같습니다.

구체적으로 품질 아키텍트는 다음과 같은 역할을 수행할 수 있습니다.

•AI 시스템의 품질 목표 설정: ISO/IEC 25010과 같은 표준을 기반으로 AI 모델의 성능, 신뢰성, 보안성 등 품질 목표를 정의하고, 이를 측정할 수 있는 지표를 수립합니다.

•AI 모델의 편향성 및 공정성 검증: AI 모델이 특정 데이터에 편향되어 있거나, 특정 그룹에 대해 불공정한 결과를 내놓지는 않는지 도메인 지식을 활용하여 검증 시나리오를 설계하고 실행합니다.

•AI 시스템의 설명 가능성(Explainability) 평가: AI 모델이 왜 특정 결정을 내렸는지, 그 과정을 얼마나 투명하게 설명할 수 있는지 평가하여 신뢰성을 확보합니다.

•AI 검증 프로세스의 표준화: KOLAS 인정 요건과 같은 국제 표준에 맞춰 AI 모델의 학습 데이터 관리, 모델 개발 프로세스, 검증 방법 등을 표준화하고 문서화합니다.

•AI 기반 테스트 도구의 신뢰성 확보: AI가 생성한 테스트 케이스나 테스트 코드의 품질을 평가하고, AI 기반 테스트 도구가 표준화된 검증 절차를 따르도록 관리합니다.

품질 아키텍트의 독보적인 전문성: 표준을 통해 AI 시대를 이끌다

AI 시대의 품질 아키텍트는 기술적인 전문성뿐만 아니라, 국가적·국제적 품질 표준에 대한 깊이 있는 이해를 바탕으로 AI 시스템의 신뢰성을 확보하는 데 핵심적인 역할을 수행합니다.

우리는 AI의 잠재력을 최대한 활용하면서도, 그 위험을 최소화하고, 궁극적으로는 사용자에게 안전하고 신뢰할 수 있는 AI 기반 서비스를 제공해야 합니다.

표준은 이러한 목표를 달성하기 위한 강력한 지침이자 도구입니다.

KOLAS 인정 요건과 ISO/IEC 25010과 같은 품질 표준을 AI 검증 체계에 연결하는 것은 단순히 규제를 준수하는 것을 넘어, 소프트웨어 품질에 대한 우리의 시야를 넓히고, AI 시대에 필요한 새로운 전문성을 구축하는 과정입니다.

품질 아키텍트로서 우리는 이러한 표준을 적극적으로 활용하여 AI 기술의 건전한 발전을 이끌고, 소프트웨어 품질의 새로운 지평을 열어가는 선구자가 되어야 할 것입니다.

참고 자료

[1] Korea Laboratory Accreditation Scheme (KOLAS). "Accreditation Process."

[2] KAIT. "KOLAS Accredited Testing Laboratory for Software."

[3] ISO. "ISO/IEC 25010:2011 - Systems and software engineering."

25화. 테스트 가능성을 설계에 심다 — Testability를 기획·개발 단계로 끌어올리기.

testmanager — Mon, 6 Jul 2026 08:17:05 +0900

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화. 테스터에서 품질 아키텍트로

테스트 가능성을 설계에 심다: 점검구가 있는 건물처럼, 레고처럼

우리는 지난 연재들을 통해 소프트웨어의 기능이 잘 작동하는지, 성능은 어떤지, 보안에는 문제가 없는지 등 다양한 관점에서 품질을 측정하고 개선하는 방법을 알아보았습니다.

그런데 아무리 훌륭한 테스트 기술과 도구를 가지고 있어도, 정작 테스트하기 어려운 구조로 만들어진 소프트웨어라면 어떨까요?

마치 점검구가 없는 건물에서 배관 문제를 찾아내거나, 접착제로 붙여버린 레고 블록을 분해하려는 것과 같을 것입니다.

오늘은 테스트 가능성(Testability)이라는 개념을 통해, 기획과 설계 단계에서부터 테스트를 염두에 둔 구조를 만드는 것이 왜 중요한지, 그리고 품질 아키텍트로서 우리가 어떤 역할을 해야 하는지 이야기해 보겠습니다.

테스트 가능성: 소프트웨어를 얼마나 쉽게 테스트할 수 있는가

테스트 가능성은 말 그대로 소프트웨어나 그 구성 요소를 얼마나 쉽고 효과적으로 테스트할 수 있는지를 나타내는 척도입니다 .

테스트 가능성이 높다는 것은, 소프트웨어의 내부 동작을 쉽게 관찰하고, 원하는 상태로 제어하며, 테스트 결과를 명확하게 확인할 수 있다는 의미입니다.

이는 마치 잘 설계된 건물에 전기 배선이나 수도관을 점검할 수 있는 점검구가 곳곳에 마련되어 있어, 문제가 생겼을 때 쉽게 원인을 파악하고 수리할 수 있는 것과 같습니다.

반대로 테스트 가능성이 낮으면, 작은 기능을 테스트하는 데도 많은 시간과 노력이 들고, 버그를 찾아내기도 어려워집니다.

이는 마치 복잡한 기계의 부품 하나를 교체하기 위해 전체를 다 분해해야 하는 상황과 비슷합니다.

결국 테스트 비용이 증가하고, 출시 일정이 지연되며, 소프트웨어의 전반적인 품질 저하로 이어질 수 있습니다.

기획·개발 단계에서 테스트 가능성을 끌어올리는 이유

테스트는 소프트웨어 개발 생명주기(SDLC)의 후반부에 이루어지는 활동이라고 생각하기 쉽습니다. 하지만 테스트 가능성은 개발 초기 단계, 즉 기획과 설계 단계에서부터 고려되어야 합니다. 왜냐하면 소프트웨어의 구조와 아키텍처가 결정되는 시점이기 때문입니다. 마치 건물의 설계 단계에서부터 점검구의 위치나 배관의 경로를 정해야 나중에 유지보수가 쉬워지듯이, 소프트웨어도 초기 설계가 테스트 용이성에 큰 영향을 미칩니다.

1. 문제의 조기 발견과 비용 절감

테스트 가능성을 고려한 설계는 잠재적인 문제를 개발 초기 단계에서 발견할 수 있도록 돕습니다.

예를 들어, 특정 모듈이 너무 복잡하게 얽혀 있어 테스트하기 어렵다는 것을 설계 단계에서 파악하면, 이를 더 작고 독립적인 단위로 분리하여 설계할 수 있습니다.

이렇게 하면 나중에 코드를 다 작성한 후에 문제를 발견하여 수정하는 것보다 훨씬 적은 비용과 노력으로 해결할 수 있습니다.

마치 레고 블록을 조립하기 전에 어떤 블록이 서로 잘 맞고 분리하기 쉬운지 미리 확인하는 것과 같습니다.

2. 테스트 자동화의 용이성

테스트 가능성이 높은 소프트웨어는 테스트 자동화에도 유리합니다.

각 기능이 독립적으로 작동하고, 외부와의 의존성이 명확하게 분리되어 있다면, 자동화된 테스트 코드를 작성하기가 훨씬 수월해집니다.

이는 마치 각 부품이 명확하게 분리되는 레고 블록으로 만든 장난감이, 원하는 부분만 떼어내어 다른 부품으로 교체하거나 테스트하기 쉬운 것과 같습니다.

자동화된 테스트는 빠른 피드백을 제공하고, 회귀 테스트(Regression Test) 비용을 절감하여 개발 속도를 높이는 데 기여합니다.

3. 유지보수 및 확장성의 향상

테스트하기 쉬운 코드는 일반적으로 유지보수 및 확장성도 뛰어납니다.

테스트 가능성을 높이기 위해 코드를 모듈화하고, 각 모듈의 역할을 명확히 하며, 의존성을 줄이는 과정은 자연스럽게 코드의 가독성과 재사용성을 높이기 때문입니다.

이는 마치 잘 정리된 도구 상자에서 필요한 도구를 쉽게 찾아 사용할 수 있고, 새로운 도구를 추가하기도 쉬운 것과 같습니다.

테스트 가능성을 설계에 심는 구체적인 방법

그렇다면 기획과 설계 단계에서 테스트 가능성을 높이기 위해 구체적으로 어떤 노력을 해야 할까요?

1. 모듈화 및 낮은 결합도 유지

소프트웨어를 작고 독립적인 모듈로 나누고, 각 모듈 간의 의존성을 최소화해야 합니다.

마치 레고 블록처럼, 각 블록이 독립적인 기능을 수행하고 다른 블록에 미치는 영향이 적을수록 테스트하기 쉽습니다.

특정 모듈을 테스트할 때 다른 모듈의 영향을 받지 않도록 설계하는 것이 중요합니다.

2. 명확한 인터페이스 제공

각 모듈이나 컴포넌트가 외부와 상호작용하는 방식을 명확하게 정의하는 인터페이스를 제공해야 합니다.

이는 마치 건물의 각 방에 어떤 기능이 있고, 어떻게 사용해야 하는지 명확한 안내판이 붙어있는 것과 같습니다.

명확한 인터페이스는 테스트 코드가 해당 모듈을 쉽게 호출하고, 입력값을 전달하며, 출력값을 확인할 수 있도록 돕습니다.

3. 관찰 가능성(Observability) 확보

소프트웨어의 내부 상태를 쉽게 관찰할 수 있도록 로그, 메트릭, 트레이스 등의 정보를 충분히 제공해야 합니다.

지난 연재에서 다루었던 관측성(Observability)과 일맥상통하는 부분입니다.

마치 건물 곳곳에 설치된 센서와 모니터링 시스템이 건물의 상태를 실시간으로 보여주듯이, 소프트웨어도 내부 동작을 투명하게 보여줄 수 있어야 테스트 중 발생하는 문제를 정확하게 파악할 수 있습니다.

4. 제어 가능성(Controllability) 확보

테스트를 위해 소프트웨어의 특정 상태를 쉽게 설정하고 제어할 수 있어야 합니다.

예를 들어, 특정 시나리오를 테스트하기 위해 데이터베이스의 초기 상태를 쉽게 만들거나, 외부 시스템과의 연동을 모의(Mock)할 수 있는 기능을 제공하는 것입니다.

이는 마치 레고 블록을 조립하기 전에 원하는 색상과 모양의 블록을 미리 준비해두는 것과 같습니다.

5. 테스트 데이터 관리 용이성

테스트에 필요한 데이터를 쉽게 생성하고 관리할 수 있는 방법을 설계 단계에서부터 고려해야 합니다.

지난 연재에서 다루었던 테스트 데이터 합성 및 마스킹 기술도 여기에 해당합니다.

마치 요리사가 요리하기 전에 필요한 재료를 미리 손질해두는 것과 같아서, 테스트 데이터 준비에 드는 시간을 줄이고 테스트의 효율성을 높일 수 있습니다.

품질 아키텍트의 전략적 역할: 테스트 가능성을 설계하다

AI가 코드를 짜고 테스트를 자동화하는 시대에, 품질 아키텍트의 역할은 단순히 테스트를 실행하는 것을 넘어, 테스트하기 쉬운 소프트웨어를 설계하는 데 적극적으로 참여하는 것입니다.

우리는 기획자, 개발자와 함께 초기 단계부터 테스트 가능성을 논의하고, 설계에 반영될 수 있도록 가이드해야 합니다.

이는 마치 건물을 짓기 전부터 건축가와 함께 점검구의 위치와 배관 경로를 논의하고, 유지보수가 용이한 설계를 이끌어내는 것과 같습니다.

테스트 가능성을 설계에 심는 것은 단기적으로는 추가적인 노력처럼 보일 수 있습니다.

하지만 장기적으로는 소프트웨어의 품질을 향상시키고, 개발 비용을 절감하며, 시장 출시 시간을 단축하는 데 결정적인 역할을 합니다.

품질 아키텍트로서 우리는 이러한 전략적 사고를 바탕으로, 소프트웨어의 모든 단계에서 품질이 내재화될 수 있도록 이끌어야 합니다.

테스트 가능성을 높이는 것은 단순히 테스트 팀만의 책임이 아니라, 소프트웨어 개발에 참여하는 모든 이해관계자가 함께 고민하고 실천해야 할 중요한 가치입니다.

참고 자료

[1] GeeksforGeeks. "Software Testability."

3화. 웹은 어떻게 움직이는가 — HTTP, 쿠키·세션의 원리. 실습: 개발자도구로 요청·응답 해부.

testmanager — Mon, 6 Jul 2026 07:50:25 +0900

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 호출이 바뀌었으니 쿠키 처리도 확인해야겠네” 하고 자연스럽게 연결지어 생각하게 됩니다.

웹의 기본 언어를 이해하는 순간, 테스터는 단순히 화면을 클릭하는 사람이 아니라 시스템 전체 흐름을 읽는 품질 아키텍트로 한 걸음 더 다가갑니다.

2화. 변경은 diff에서 시작된다 — Git과 PR 기반 협업, 변경 기반 테스트의 첫 단추. 실습: PR diff만 보고 영향 범위 추정해 보기.

testmanager — Fri, 3 Jul 2026 07:46:07 +0900

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화. 테스터에서 품질 아키텍트로 — 30화의 회고와 다음 길 제시. 연재의 수미상관.

변경 한 줄이 시스템을 흔들 때, diff부터 읽는 눈이 품질의 첫걸음이다

테스터로서 AI가 빠르게 코드를 바꿔도 “이게 어디에 영향을 줄까?”를 제대로 파악하지 못해 불안한가요.

Git diff와 PR만 보고도 변경 범위를 가늠하는 눈을 기르면, 불필요한 테스트를 줄이고 중요한 곳에 집중할 수 있습니다.

이 글에서 그 실전 감각을 중학생도 이해하기 쉽게 잡아봅니다.

레고 한 조각을 바꿨는데 전체가 흔들리는 이유

중학생 때 레고로 큰 성을 쌓았다고 생각해 보세요.

빨간 블록 하나를 다른 색으로 바꾸기만 했는데, 그 블록이 성의 기둥 역할을 하고 있었다면?

주변 벽이 무너지고 지붕이 내려앉아요.

코드도 정확히 그렇습니다.

한 파일의 한 함수를 수정했는데, 그 함수를 다른 화면, 다른 API, 심지어 데이터베이스까지 여러 곳에서 쓰고 있다면 작은 변경이 큰 파장을 일으킵니다.

이걸 미리 알아차리는 가장 강력한 도구가 바로 diff입니다.

diff는 “이전 코드와 지금 코드가 어떻게 달라졌는지”를 줄 단위로 보여주는 변화 기록이에요.

PR(Pull Request)은 이 diff를 팀원들이 함께 검토하는 자리입니다.

AI 시대에는 AI가 코드를 빠르게 생성하지만, 그 변경이 실제 시스템에 미치는 영향을 판단하는 건 여전히 사람의 몫입니다.

Git은 왜 우리에게 ‘변화의 역사’를 알려줄까

Git을 처음 만난다고 해도 어렵게 생각하지 마세요.

마치 일기장처럼 “오늘 내가 뭐를 바꿨다”를 기록하고, 언제든 과거로 돌아갈 수 있게 해주는 도구예요.

개발자가 코드를 수정하면 Git은 그 변화를 commit(기록)으로 남깁니다.

그리고 PR을 올리면 팀원들이 “이 변경 괜찮아?” 하고 diff를 들여다보는 거죠.

테스터인 우리는 여기서 중요한 역할을 합니다.

diff만 봐도 “이 부분이 바뀌면 로그인 화면, 결제 기능, 사용자 데이터 저장까지 영향을 줄 수 있겠구나” 하고 영향 범위를 추정할 수 있어야 해요.

실제로 많은 버그는 “작은 변경이라고 생각했는데 의외로 넓게 퍼졌다”는 데서 옵니다.

diff를 잘 읽는 습관을 들이면 이런 함정을 미리 피할 수 있습니다.

PR diff만 보고 영향 범위 추정하는 실습

이제 직접 연습해 볼까요.

실제 PR diff를 보는 상황을 가정해 보겠습니다.

예를 들어, 개발자가 사용자 프로필 수정 기능을 바꿨다고 해요.

diff를 열어보니 다음과 같은 변화가 보입니다.

userProfile.js 파일에서 updateUser 함수의 로직이 수정됨
API 호출 부분에서 새로운 필드(age, gender)를 추가로 보내도록 바뀜
데이터베이스 스키마를 건드리지는 않았지만, 저장하는 데이터 구조가 조금 달라짐

이 diff만 보고도 우리는 이렇게 생각할 수 있어요.

먼저, 프로필 화면 자체는 물론이고, 이 프로필 데이터를 보여주는 다른 페이지(마이페이지, 커뮤니티 게시글 작성자 정보)에도 영향을 줄 가능성이 큽니다.

이어서, age와 gender 같은 새로운 정보가 추가되면 개인정보 보호 관련 법규나 동의 화면도 확인해야 해요.

특히 API가 바뀌었으니, 모바일 앱 버전과 웹 버전 모두에서 이 API를 호출하는 곳을 찾아 테스트해야 합니다.

만약 이전에 캐싱(임시 저장)을 사용하고 있었다면, 캐시가 제대로 갱신되는지도 봐야겠죠.

이처럼 diff를 읽다 보면 자연스럽게 “여기, 여기, 저기도 체크해야겠다”는 영향 범위 지도가 그려집니다.

처음에는 익숙하지 않지만, 몇 번 반복하다 보면 점점 빨라집니다.

변경 기반 테스트로 효율을 높이는 방법

diff를 통해 영향 범위를 파악했다면, 이제 테스트도 그 범위에 맞춰 집중합니다.

모든 기능을 처음부터 다시 테스트할 필요 없이, 바뀐 부분과 그 주변만 정밀하게 확인하는 거예요.

이게 바로 변경 기반 테스트의 핵심입니다.

AI가 코드를 많이 바꿔주는 시대일수록, 무작정 모든 걸 테스트하는 대신 smart하게 타겟팅하는 능력이 더 중요해집니다.

PR 검토할 때 diff를 먼저 열고, 관련 파일과 호출 관계를 따라가며 메모하는 습관을 들여보세요.

그러다 보면 자연스럽게 “이 변경은 안전해 보이지만, 이 부분은 위험하네” 하는 감이 생깁니다.

작은 변화를 놓치지 않는 눈으로

30분 데모에서는 한두 번의 클릭으로 끝나지만, 실제 프로덕션에서는 수많은 작은 변경이 쌓여 시스템을 만듭니다.

그 변화 하나하나를 diff로 읽고, 영향을 예측하는 눈을 기르는 것이 테스터에서 품질 아키텍트로 가는 첫 단추예요.

이 습관을 오늘 PR 하나만이라도 적용해 보세요. 처음엔 어색해도, 곧 시스템 전체를 보는 시야가 넓어지는 걸 느낄 수 있을 겁니다.

그 눈이 곧 안정적인 서비스를 지키는 든든한 기반이 됩니다.

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

testmanager — Thu, 2 Jul 2026 07:43:34 +0900

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가지 이상의 개선점을 찾아보는 거예요.

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

0화. 30분 데모와 프로덕션 사이의 거리 — 현실 인식과 방향 제시

testmanager — Wed, 1 Jul 2026 07:53:59 +0900

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부터 시작합니다. 함께 현실을 보고, 방향을 잡아봅시다.