TestOps — 테스트 실행 인프라와 품질 관측

학습 목표

이 모듈 한 줄 요약 — "자동화를 매일 도는 운영 대상으로 다룬다". 만드는 것과 매일 돌게 유지하는 것은 다른 일이다. 느려지고, 가끔 실패하고, 아무도 결과를 안 보게 되는 것이 자동화가 죽는 전형적인 경로다. 그 상태를 숫자로 보고 손쓰는 법을 다룬다.

이 모듈을 마치면 자동화를 매일 도는 운영 대상 으로 다룰 수 있다. 먼저 TestOps 가 무엇을 책임지는지를 이웃 모듈과의 경계로 정의한다 — 모듈 14(CI/CD)는 파이프라인, 즉 "언제 무엇을 실행하는가"를, 모듈 55(자동화 아키텍처)는 프레임워크 구조, 즉 "코드가 어떻게 생겼는가"를 다룬다. 이 모듈은 "어제와 오늘의 결과가 왜 다른가, 깨진 것을 누가 고치는가" 를 다룬다. 레슨 1이 세 모듈의 경계표를 세우고, 뒤의 여섯 레슨이 그 표의 각 칸을 채운다.

실행 인프라 쪽에서는 러너·그리드·디바이스 팜의 용량을 산정하고, 셀프호스티드와 클라우드를 고르는 기준을 세우고, 동시 실행 수를 근거 있게 정하고, 실행이 밀릴 때 무엇부터 줄일지 미리 정해 둘 수 있다. 환경 쪽에서는 테스트 환경을 버전으로 관리 한다는 것이 무엇인지 — 구성·스키마·시드 데이터를 한 좌표로 묶는 일 — 를 이해하고, 초기화 전략과 데이터 수명 정책, 실행 전 프리플라이트를 설계할 수 있다.

운영 규칙 쪽에서는 플래키를 재현 가능한 정의로 못 박고, 집계·자동 격리·복귀 기준을 장부로 운영할 수 있다. 여러 실행에 걸친 추세를 보는 관측 지표를 고르고 대시보드를 보는 사람별로 나눌 수 있다. 커밋·빌드·환경·테스트 결과를 하나의 식별자로 묶어 "이 버전에서 무엇이 통과했는가"에 답할 수 있고, 마지막으로 실패를 제품 결함·환경 문제·테스트 결함으로 자동 분류하는 규칙을 신호와 오분류 비용까지 따져 쓸 수 있다.

완료 후 할 수 있는 것

• m14(파이프라인)·m55(프레임워크 구조)·m59(실행 운영)의 경계를 표로 설명하고, 들어온 요청을 세 모듈 중 어디의 일인지 분류할 수 있다
• SDET·TestOps 담당이 실제로 책임지는 산출물과 성공 지표를 구분해 쓸 수 있다
• 테스트 실행 수요에서 필요한 동시 실행 수와 러너 용량을 근거와 함께 산정할 수 있다
• 셀프호스티드 러너·클라우드 그리드·디바이스 팜을 각각 어느 조건에서 고르는지 판단할 수 있다
• 실행이 밀릴 때 줄일 순서(범위·빈도·병렬·보관)를 사전에 정의한 감축 계획으로 쓸 수 있다
• 테스트 환경을 구성·스키마·시드 데이터의 버전 좌표로 기술하고 그 좌표를 결과에 기록할 수 있다
• 환경 초기화 전략(매 실행·주기·더티)을 비용과 간섭 위험으로 비교해 선택할 수 있다
• 테스트 데이터의 수명·소유자·정리 책임을 정책으로 정하고 고아 데이터를 탐지할 수 있다
• 실행 전 프리플라이트 체크를 설계해 환경 문제로 생기는 대량 실패를 사전에 차단할 수 있다
• 플래키를 "같은 커밋에서 결과가 갈리는 테스트"로 정의하고 이력 기반으로 집계할 수 있다
• 자동 격리(quarantine) 규칙과 복귀 기준, 격리 상한(플래키 예산)을 운영 규칙으로 쓸 수 있다
• 격리가 쓰레기통이 되는 실패 양상을 알아보고 만료·소유자·주간 리뷰로 막을 수 있다
• 실행 시간·통과율·플래키율·커버리지·대기 시간의 추세 지표를 정의하고 보는 사람별 대시보드를 나눌 수 있다
• 커밋·빌드·환경·실행을 하나의 상관 식별자로 묶어 버전별 테스트 결과를 조회 가능하게 만들 수 있다
• 릴리스 판정에 붙일 테스트 결과 요약 형식과 아티팩트 보관 정책을 정할 수 있다
• 실패를 제품 결함·환경 문제·테스트 결함으로 자동 분류하는 규칙을 신호별로 설계할 수 있다
• 오분류의 비용을 방향별로 따져 자동 분류의 신뢰 구간과 사람에게 넘기는 기준을 정할 수 있다

채용시장에서의 위치

자동화 채용 공고의 요구사항을 모아 보면 "테스트 코드 작성"은 거의 모든 공고에 있고, "테스트 실행 환경 운영", "CI 안정화", "테스트 인프라 구축" 은 연차가 올라갈수록 비중이 커진다. SDET·테스트 플랫폼 엔지니어·QA 인프라 담당 같은 직함이 가리키는 일이 정확히 이 모듈의 범위다. 자동화 코드를 쓸 사람은 시장에 많지만, 매일 500개 테스트가 도는 파이프라인을 신뢰 가능한 상태로 유지해 본 사람 은 드물다. 그래서 면접에서 이 영역의 질문은 거의 항상 경험을 확인하는 형태로 나온다 — "자동화가 매일 20%씩 실패하는 상황을 어떻게 정상화했습니까", "실행이 2시간 걸리는데 30분으로 줄여야 하면 무엇부터 보겠습니까", "플래키 테스트는 어떻게 관리합니까", "이 빌드가 배포 가능하다고 어떻게 판단합니까".

이 모듈이 다루는 어휘 — 플래키율·격리·프리플라이트·상관 ID·추세 대시보드·트리아지 규칙 — 는 개발 플랫폼 조직과 QA 조직이 공유하는 말이다. 같은 말을 쓰면 테스트 인프라 요구를 플랫폼 팀에 전달하는 대화가 짧아지고, 테스트 결과를 릴리스 판정에 붙이는 협상이 숫자 위에서 진행된다. 특히 클라우드·AI 플랫폼 트랙으로 가는 경로에서는 "테스트를 쓰는 사람"과 "테스트가 도는 시스템을 운영하는 사람"의 차이가 연봉 구간을 가르는 지점이 된다. 자동화 경력 3년 이상에서 다음 단계를 찾고 있다면, 코드 숙련도를 더 올리는 것보다 이 운영 영역의 경험을 한 번 끝까지 해 보는 것 이 이력서에서 더 크게 작동한다.