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

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화. 테스터에서 품질 아키텍트로 — 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 하나만이라도 적용해 보세요. 처음엔 어색해도, 곧 시스템 전체를 보는 시야가 넓어지는 걸 느낄 수 있을 겁니다.

 

 

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