9화. 계약을 테스트하라 — API·계약 테스트(OpenAPI/GraphQL schema 기반).

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 계약을 테스트하는 순간, 개발자와 테스터 사이의 오해가 사라진다

 

Playwright로 UI 테스트를 익히던 테스터가 API 영역으로 눈을 돌릴 때, “이 데이터 구조가 정말 맞을까?” 하는 불안이 생깁니다.

 

OpenAPI나 GraphQL schema를 활용한 계약 테스트를 도입하면, 백엔드와 프론트엔드가 서로 약속한 ‘계약’을 자동으로 검증할 수 있어요.

 

이 기술을 익히면 데모에서만 빛나던 API가 프로덕션에서도 안정적으로 동작하는 기반을 마련합니다.

 

 

레고 설명서와 실제 조립품, 계약 테스트의 본질

중학생 때 레고 세트를 사서 설명서를 보면서 조립해 보세요.

 

설명서에는 “이 블록을 여기 연결하세요”라고 정확한 순서와 모양이 그려져 있어요.

 

그런데 실제로 조립한 결과물이 설명서와 다르면? 전체 작품이 흔들리거나 아예 무너집니다.

 

API의 계약도 마찬가지예요.

 

OpenAPI 스펙(REST)이나 GraphQL schema는 개발팀이 “이 API는 이런 요청을 받으면 이렇게 응답할 거야”라고 미리 적어놓은 설명서입니다.

 

계약 테스트는 이 설명서와 실제 API가 일치하는지 매번 확인하는 과정이에요.

 

프론트엔드가 기대하는 데이터 구조와 백엔드가 실제로 주는 데이터가 어긋나면, 화면이 깨지거나 오류가 발생하죠.

 

OpenAPI 기반 계약 테스트, 어떻게 시작하나

REST API를 주로 사용하는 팀이라면 OpenAPI(Swagger) 명세를 활용하는 게 가장 효과적입니다.

 

먼저 API 명세 파일(yaml 또는 json)을 최신으로 유지합니다.

 

이 파일에는 엔드포인트, 요청 파라미터, 응답 구조, 상태 코드 등이 자세히 정의되어 있어요.

 

계약 테스트 도구로는 Spectral, Dredd, 또는 Postman Collection + Newman, 그리고 Playwright의 API testing 기능을 함께 사용하면 강력합니다.

 

실제로 테스트할 때는 명세에 적힌 대로 요청을 보내고, 응답이 스키마와 정확히 맞는지 검증합니다.

 

필드 타입이 다르거나 필수 값이 빠졌는지, 추가로 들어오면 안 되는 필드가 있는지 자동으로 체크하죠.

 

이렇게 하면 백엔드 개발자가 스펙을 바꿀 때마다 프론트엔드 쪽에서 미리 문제를 발견할 수 있습니다.

 

 

GraphQL schema로 계약을 더 세밀하게 지키기

GraphQL을 쓰는 프로젝트에서는 schema가 핵심 계약서입니다.

 

쿼리와 뮤테이션, 타입 정의, 필수/선택 필드까지 모두 schema에 명시되어 있어요.

 

테스트에서는 실제 schema를 불러와서 클라이언트가 보낸 쿼리가 유효한지, 응답 데이터가 schema를 준수하는지 검증합니다.

 

도구로는 GraphQL Code Generator나 Apollo Client의 schema validation, 혹은 Jest + graphql-tools를 활용할 수 있어요.

 

Playwright 안에서도 API request를 직접 보내 schema와 비교 검증하는 코드를 쉽게 작성할 수 있습니다.

 

한 번의 요청으로 여러 데이터를 가져오는 GraphQL의 특성상, schema 변화가 화면에 미치는 영향을 빠르게 파악하는 데 특히 유용합니다.

 

 

실전에서 계약 테스트를 살아 숨쉬게 만드는 습관

CI/CD 파이프라인에 계약 테스트를 포함시키면 매번 PR이 올라올 때마다 자동으로 “계약이 깨졌나?”를 확인할 수 있어요.

 

개발자가 schema를 업데이트하면 테스트가 실패하면서 바로 피드백이 가는 구조를 만드는 거죠.

 

AI가 API 테스트 코드를 생성해줄 때도, OpenAPI나 GraphQL schema를 함께 입력하면 더 정확한 코드를 만들어줍니다.

 

테스터는 그 코드를 Trace Viewer로 돌려보고, 계약 위반 부분을 날카롭게 잡아낼 수 있어요.

 

이렇게 계약 테스트를 습관화하면, “API가 바뀌어서 프론트가 깨졌다”는 전형적인 실수를 크게 줄일 수 있습니다.

 

팀 전체가 하나의 명확한 설명서를 공유하며 움직이는 느낌이 들 거예요.

 

계약 테스트를 제대로 익히는 순간, 테스터는 단순한 검증자가 아니라 시스템 전체의 일관성을 설계하는 품질 아키텍트로 한 걸음 더 다가갑니다.

 

다음 단계에서는 이 기반 위에 시각적 회귀와 접근성 검사까지 확장해 보겠습니다.