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

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 방식으로 사용자와 게시물 정보 가져오기

1. /users/1을 GET으로 호출해 사용자 정보를 받습니다.
2. 그 사용자 id로 /posts?userId=1을 다시 호출해 게시물을 가져옵니다.
3. 응답에 기대한 필드(이름, 이메일, 게시물 제목)가 있는지, 상태 코드가 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의 두 얼굴을 제대로 알게 되는 순간, 테스트의 깊이가 한층 더 단단해질 겁니다.