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

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를 열고 “토큰은 어떻게 관리하나? 권한은 제대로 제한되나?”를 질문하는 습관을 들여보세요.

 

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