본문으로 건너뛰기
고급약 7시간 (예상)

테스트 자동화 아키텍처 — gTAA·프레임워크 설계·보고와 로깅·테스트 용이성·도입 제안서

자동화를 스크립트가 아니라 시스템으로 설계한다. ISTQB의 일반 테스트 자동화 아키텍처(gTAA) 계층 분리, 빈 리포지터리에서 프레임워크를 설계하는 실습, 실패 하나를 5분 안에 진단하게 만드는 보고·로깅 설계, 개발팀에 훅·테스트 모드를 요구하는 테스트 용이성 협상, 팀을 설득하는 자동화 도입 제안서(ROI·파일럿 범위)를 다룬다.

★ 자동화의 수명은 코드가 아니라 구조가 결정한다.

학습 목표

이 모듈 한 줄 요약 — "자동화를 스크립트 묶음이 아니라 하나의 시스템으로". 시험 스크립트가 수백 개가 되면 구조가 없는 것이 가장 큰 비용이 된다. 무엇을 어느 층에 두고, 결과를 어떻게 남기고, 사람이 바뀌어도 굴러가게 하려면 어떤 모양이어야 하는지 — 설계의 문제로 다룬다.

이 모듈을 마치면 자동화를 스크립트 묶음이 아니라 하나의 시스템 으로 설계할 수 있다. ISTQB CT-TAE(CTAL-TAE) v2.0 실러버스의 일반 테스트 자동화 아키텍처(gTAA)가 말하는 네 가지 핵심 역량 — 테스트 생성·정의·실행·적응 — 이 각각 무엇을 책임지는지 이해하고, 계층이 섞였을 때 구체적으로 무엇이 깨지는지 설명할 수 있다. 빈 저장소에서 TypeScript + Playwright 프레임워크를 단계적으로 세워 설정·픽스처·페이지 객체·테스트 데이터·공통 단언의 자리를 잡고, 무엇을 만들지 않을 것인가 까지 결정할 수 있다. 실패 하나를 5분 안에 진단하도록 아티팩트·트레이스·상관 ID·단언 메시지를 설계하고, 개발팀에 안정 식별자·테스트 모드·시드 엔드포인트를 개발팀의 언어로 협상 할 수 있다. 마지막으로 도입 제안서를 쓰고 ROI 를 정직하게 — 유지보수를 0으로 잡지 않고 — 계산해 파일럿 범위와 실패 판정 조건을 미리 정할 수 있다.

모듈 11(자동화 전략)이 "무엇을 자동화할까"를, 모듈 13(UI 자동화)이 "어떻게 쓸까"를 다뤘다면 이 모듈은 "6개월 뒤에도 살아 있게 어떻게 구조를 잡을까" 를 다룬다.

완료 후 할 수 있는 것

  • gTAA 의 네 핵심 역량(test generation·definition·execution·adaptation)과 각 역량이 책임지는 범위를 설명할 수 있다
  • TAS·TAA·TAF 세 용어를 구분해 쓰고, TAF 계층(테스트 스크립트·비즈니스 로직·코어 라이브러리)을 설계할 수 있다
  • 계층 혼합이 만드는 구체적 비용 — 셀렉터 한 줄 변경이 수십 파일 수정이 되는 구조 — 을 진단할 수 있다
  • 빈 저장소에서 TypeScript + Playwright 프레임워크를 디렉터리·설정·픽스처까지 직접 세울 수 있다
  • 과잉 추상화의 신호를 알아보고 "만들지 않을 것" 목록을 근거와 함께 쓸 수 있다
  • 실패 하나를 5분 안에 진단하게 만드는 산출물(스크린샷·비디오·트레이스·네트워크·콘솔)을 선택하고 보존 정책을 정할 수 있다
  • 상관 ID 로 테스트 실행과 서버 로그를 이어 붙이고, 읽히는 단언 메시지를 설계할 수 있다
  • 개발팀에 요구할 테스트 용이성 항목을 관측성·제어성 관점으로 정리하고 PR 로 제안할 수 있다
  • 요구가 거절당했을 때의 대안(차선 셀렉터 전략·UI 경유 시딩·부분 적용)을 비용과 함께 제시할 수 있다
  • 자동화 도입 제안서를 쓰고 손익분기 시점을 유지보수 비용을 포함해 계산할 수 있다
  • ROI 계산이 거짓말이 되는 전형적 방식을 알아보고 자기 계산을 교차 검증할 수 있다
  • 파일럿 범위를 고르는 기준과 실패 판정 조건 을 착수 전에 문서로 못 박을 수 있다

채용시장에서의 위치

자동화 경력 3년차 이상 채용에서 갈리는 지점은 도구 숙련도가 아니다. "Playwright 를 써 봤다"는 지원자는 많고, "남이 쓴 자동화를 6개월 유지해 본 사람" 은 드물다. SDET·자동화 아키텍트·QA 엔지니어링 리드 공고가 요구하는 "테스트 프레임워크 설계 경험", "자동화 도입 주도 경험"이 정확히 이 모듈의 범위다. 면접에서는 보통 이렇게 묻는다 — "기존 자동화가 매일 깨지는 상황에 들어갔다면 첫 2주에 무엇을 보겠습니까", "개발팀이 data-testid 추가를 거절하면 어떻게 하겠습니까", "자동화 도입을 경영진에게 어떻게 설득하겠습니까". 세 질문 모두 코드 실력이 아니라 구조 판단과 협상 능력 을 본다.

자격증으로는 ISTQB CT-TAE(Advanced Level Test Automation Engineering, v2.0 — 2024)가 이 영역을 정면으로 다루는 거의 유일한 공인 체계다. 모듈 42 레슨 6의 자격증 지도에서 자동화 트랙의 상위 자격으로 소개한 그 자격증이고, 이 모듈의 l01·l04·l05 는 그 실러버스의 3장(테스트 자동화 아키텍처)·2장(인프라와 테스트 용이성)·4장(파일럿과 배포)에 각각 대응한다. 자격증 취득 자체보다, 실러버스가 쓰는 공통 어휘(gTAA·TAF 계층·관측성·제어성)를 써서 설계 결정을 설명할 수 있는 상태가 채용시장에서 값을 한다 — 같은 말을 쓰는 사람끼리는 설계 리뷰가 빨리 끝난다.

레슨 (5개)

  1. 고급약 40분

    gTAA — 계층 분리와 컴포넌트 설계

    ISTQB CT-TAE v2.0 실러버스의 일반 테스트 자동화 아키텍처(gTAA)가 정의하는 네 핵심 역량(테스트 생성·정의·실행·적응)과 각 역량의 책임 범위, 계층을 섞었을 때의 변경 비용, TAS·TAA·TAF 의 구분, TAF 계층(테스트 스크립트·비즈니스 로직·코어 라이브러리)의 경계와 공통 컴포넌트 판정 기준을 다룬다.

  2. 고급약 50분

    자동화 프레임워크 직접 설계 — 빈 리포지터리에서 완성까지

    레슨 1의 TAF 세 계층을 TypeScript + Playwright 저장소의 디렉터리와 코드로 옮긴다. 환경별 설정 분리, 픽스처와 테스트 데이터, 페이지·컴포넌트 추상화, 공통 단언, 격리와 재시도, 병렬 실행을 여섯 단계로 쌓으며 "이 구조가 없으면 나중에 무엇이 터지는가"로 설계 결정을 정당화한다.

  3. 고급약 45분

    보고·로깅 설계 — 실패 하나를 5분 안에 진단 가능하게

    자동화 실패 하나를 5분 안에 원인까지 좁히려면 리포트가 무엇을 담아야 하는지 설계한다. 실행 아티팩트(스크린샷·비디오·트레이스·HAR·콘솔·네트워크)의 수집 비용과 보관 정책, 상관 ID로 테스트 실행과 서버 로그를 잇는 방법, 사람이 읽는 단언 메시지, 플래키와 진짜 실패를 리포트에서 가르는 기준, 그리고 보는 사람에 따라 리포트를 층으로 나누는 법을 다룬다.

  4. 고급약 45분

    테스트 용이성 확보 협상 — 훅·테스트 모드·안정 식별자 요구하기

    테스트 용이성을 부탁이 아니라 요구사항으로 다루는 법을 다룬다. 개발팀에 요구할 네 묶음(안정 식별자, 테스트 모드와 훅, 상태 초기화 API, 관측 가능성)을 비용과 함께 정리하고, 설계 단계에 끼어드는 시점과 질문 형식, 거절당했을 때의 대안과 비용 비교, 테스트 훅이 프로덕션에 남지 않게 하는 가드, 그리고 테스트 용이성을 DoD와 수용 기준에 넣는 문구까지 만든다.

  5. 고급약 45분

    자동화 도입 제안서 — ROI 계산과 파일럿 범위

    자동화 도입을 승인받는 한 장짜리 제안서를 쓴다. 작성·리뷰·인프라·유지보수·플래키 대응·트리아지까지 포함한 총비용 모델로 손익분기 회차를 실제 숫자로 계산하고, 반복 빈도와 안정성과 실패 비용으로 파일럿 범위를 고르고, 성공·중단 판정 기준을 착수 전에 못 박고, 자동화가 답이 아닌 경우를 제안서에 함께 쓴다.