개념
자동화는 작성된 날이 아니라 도는 날에 값을 낸다
자동화 테스트 300개를 짠 팀이 반년 뒤에 겪는 상황은 거의 정해져 있다. 테스트는 그대로 있다. 코드도 그대로다. 그런데 아침에 파이프라인을 보면 매일 다른 테스트가 깨져 있고, 누가 고칠지가 정해져 있지 않다. 어제는 통과한 테스트가 오늘은 실패하고, 그 차이가 제품 변경 때문인지 환경 때문인지 아무도 모른다. 사람들은 결국 빨간 배지를 보고도 그냥 지나가게 된다.
이 상황은 테스트 코드의 품질 문제가 아니다. 프레임워크를 더 잘 설계해도, 파이프라인 YAML 을 더 정교하게 써도 저절로 해결되지 않는다. 매일 도는 실행 자체를 운영 대상으로 보고 누군가 책임지지 않으면 발생하는 문제이기 때문이다. 그 책임을 가리키는 말이 TestOps 다.
TestOps 는 특정 도구의 이름이 아니다. "테스트 실행을 하나의 운영 서비스로 다룬다"는 관점이고, 그 관점이 요구하는 구체적인 일 — 용량 산정, 환경 상태 관리, 플래키 장부, 추세 관측, 버전 연계, 실패 트리아지 — 의 묶음이다. 데브옵스가 배포를 일회성 이벤트에서 반복 가능한 흐름으로 바꾼 것과 같은 전환을, 테스트 실행에 적용한 것으로 보면 된다.
세 모듈의 경계 — 이 표가 모듈 전체의 지도다
이 커리큘럼 안에서 자동화의 "운영"에 닿는 모듈은 셋이다. 세 모듈은 겹치는 단어를 쓰지만 답하는 질문이 다르다. 아래 표가 그 경계이고, 이 모듈의 남은 여섯 레슨은 모두 이 표의 마지막 열을 펼친 것이다.
| 비교 축 | m14 CI/CD 와 지속적 테스팅 | m55 자동화 아키텍처 | m59 TestOps (이 모듈) |
|---|---|---|---|
| 답하는 질문 | 언제 무엇을 실행하는가 | 코드가 어떻게 생겼는가 | 어제와 오늘이 왜 다른가 |
| 다루는 시간 단위 | 커밋 한 번 → 배포 한 번 | 저장소의 수명(수년) | 매일 아침, 그리고 매 실행 |
| 주 산출물 | 워크플로 정의, 트리거, 품질 게이트, 배포 조건 | 계층 구조, 픽스처, 페이지 객체, 리포트 설계 | 실행 용량 계획, 환경 버전 좌표, 플래키 장부, 추세 대시보드, 트리아지 규칙 |
| 변경되는 시점 | 파이프라인 구조를 바꿀 때 | 리팩터링·도구 교체할 때 | 매일 — 환경이 바뀌고 테스트가 늘고 수요가 는다 |
| 실패 하나를 보고 묻는 것 | 게이트가 제대로 막았는가 | 이 실패를 5분 안에 진단할 수 있는가 | 이 실패는 누가 고치는가, 어제도 깨졌는가, 환경 탓인가 |
| 성공을 재는 지표 | 리드타임, 게이트 통과율, 배포 빈도 | 수정 반경, 유지보수 비용, 중복률 | 신뢰도(플래키율), 대기 시간, 트리아지 소요 시간, 환경 가용률 |
| 주로 보는 화면 | 파이프라인 실행 그래프 | 코드 에디터, 실패 리포트 한 건 | 여러 실행에 걸친 추세 대시보드 |
| 전형적 결정 | "E2E 는 머지 후에만 돌린다" | "로케이터는 페이지 객체만 안다" | "동시 실행을 12로 올린다", "이 테스트를 격리한다" |
| 깨졌을 때 티켓이 가는 곳 | 플랫폼·릴리스 담당 | 자동화 개발자 | TestOps 당번 |
표를 읽는 실용적인 방법은 이렇다. 어떤 요청이 들어왔을 때 "이걸 하면 YAML 이 바뀌는가, 테스트 코드가 바뀌는가, 운영 규칙이 바뀌는가" 를 묻는다. 세 답이 각각 m14·m55·m59 를 가리킨다.
- "PR 에서는 스모크만, 야간에는 전체를 돌리자" → 트리거와 범위의 문제. m14
- "셀렉터 한 줄 바꿨는데 40개 파일을 고쳐야 한다" → 계층 구조의 문제. m55
- "야간 전체 실행이 2시간을 넘겨서 아침에 결과가 없다" → 용량과 감축의 문제. m59
- "같은 테스트가 3일 연속 랜덤하게 깨진다" → 집계와 격리의 문제. m59
- "이 실패 리포트만 봐도 원인을 알 수 있게 트레이스를 붙이자" → m55
- "이 실패가 제품 결함인지 환경 문제인지 자동으로 가르자" → m59
경계가 애매한 지점은 두 곳이다. 첫째, 플래키 는 m13 레슨 6과 m59 레슨 4가 같이 쓴다. m13 은 "이 테스트가 왜 흔들리는가"를 코드 차원에서 진단하고(대기 전략, 격리된 상태, 순서 의존), m59 는 "흔들리는 테스트들을 조직이 어떻게 관리하는가"를 운영 규칙으로 다룬다. 둘째, 관측 은 m14 레슨 6·m55 레슨 3과 m59 레슨 5가 같이 쓴다. m55 는 실패 한 건을 진단하는 리포트를, m59 는 수십 번의 실행에 걸친 추세를 본다. 같은 데이터를 보더라도 묻는 질문의 시간 폭이 다르다.
TestOps 가 실제로 소유하는 것 — 여섯 개의 자산
추상적으로 "운영한다"고 말하면 아무것도 손에 잡히지 않는다. TestOps 담당이 실제로 만들고 유지하는 산출물은 여섯 개다. 이 모듈의 레슨 2~7이 각각 하나씩 맡는다.
- 실행 용량 계획 — 몇 개를 동시에 돌릴 수 있고, 수요가 몰릴 때 대기가 얼마나 생기고, 밀릴 때 무엇부터 줄이는가. (레슨 2)
- 환경 버전 좌표와 상태 — 테스트가 어떤 구성·스키마·시드 데이터 위에서 돌았는지, 실행 전에 환경이 멀쩡한지. (레슨 3)
- 플래키 장부 — 어떤 테스트가 신뢰 가능하고, 어떤 테스트가 격리 중이고, 언제 복귀하는가. (레슨 4)
- 추세 대시보드 — 실행 시간·통과율·플래키율·대기 시간이 지난 30일 동안 어디로 가고 있는가. (레슨 5)
- 버전-결과 연계 — "이 커밋이, 이 환경에서, 이 결과를 냈다"를 하나의 식별자로 조회할 수 있는가. (레슨 6)
- 트리아지 규칙 — 실패가 제품 결함·환경 문제·테스트 결함 중 무엇인지 자동으로 얼마나 가를 수 있고, 어디서부터 사람이 보는가. (레슨 7)
없을 때 생기는 일은 예측 가능하다. 용량 계획이 없으면 테스트를 늘릴 때마다 아침 결과가 늦어지고, 환경 좌표가 없으면 "내 로컬에서는 통과한다"가 반복되고, 플래키 장부가 없으면 신뢰가 서서히 0으로 간다. 추세가 없으면 느려지는 것을 눈치채지 못하고, 버전 연계가 없으면 릴리스 회의의 "그래서 뭐가 검증됐나요"에 답할 수 없고, 트리아지 규칙이 없으면 아침 두 시간이 분류에 날아간다.
당번과 소유권 — "누가 고치는가"를 먼저 정한다
TestOps 의 일 중 기술이 아닌 부분이 하나 있는데, 실무에서는 그게 가장 자주 빠진다. 빨간 빌드의 소유자를 사전에 정하는 일 이다.
소유권 규칙은 길 필요가 없다. 보통 이런 형태로 한 장이면 된다.
빨간 빌드 소유 규칙
1. PR 파이프라인 실패 → 해당 PR 작성자. 머지 전에 해결한다.
2. 메인 브랜치 실패 → 마지막 머지 커밋의 작성자가 1차 확인(30분).
30분 안에 원인이 테스트·환경으로 판명되면 TestOps 당번에게 넘긴다.
3. 야간 전체 실행 실패 → TestOps 당번이 아침에 트리아지하고 분배한다.
4. 격리된 테스트 → 격리 시점의 소유자가 복귀까지 책임진다. 소유자 없는 격리는 금지.
5. 환경 장애 → TestOps 당번이 선언하고, 그 시간대 실패는 집계에서 제외 표시한다.당번(rotation)을 두는 이유는 일을 떠넘기기 위해서가 아니다. "아무도 아닌 사람"이 소유자가 되는 것을 막기 위해서다. 당번이 없는 조직에서 야간 실행 실패는 전원의 문제가 되고, 전원의 문제는 아무의 문제도 아니게 된다. 당번을 주 단위로 돌리고, 당번의 아침 첫 업무를 트리아지로 고정하면 분류 지연이 사라진다.
SDET 라는 자리는 실제로 무엇을 하는가
SDET(Software Development Engineer in Test)는 회사마다 범위가 다르게 쓰이는 직함이라 혼란이 많다. 공고 문구를 보고 추측하는 대신, 산출물로 구분하는 것 이 정확하다.
| 자리 | 주로 만드는 것 | 성공 판정 |
|---|---|---|
| 테스트 자동화 엔지니어 | 테스트 케이스 코드, 페이지 객체, 픽스처 | 커버하는 시나리오가 늘고 유지보수가 감당 가능하다 |
| SDET | 테스트를 쓸 수 있게 만드는 코드 — 프레임워크, 도구, 헬퍼, 테스트 모드·시드 API | 다른 사람이 테스트를 더 빠르고 안전하게 쓴다 |
| TestOps / 테스트 플랫폼 | 실행 인프라, 환경 운영, 관측·트리아지 시스템 | 매일 결과가 제 시간에, 믿을 수 있게 나온다 |
| 품질 엔지니어링 리드 | 전략, 게이트 기준, 조직 간 합의 | 품질 결정이 숫자 위에서 이뤄진다 |
작은 조직에서는 한 사람이 네 자리를 다 한다. 그래도 구분은 필요하다. 지금 내가 어느 모자를 쓰고 있는지 모르면 시간 배분이 무너지기 때문이다. 테스트를 새로 쓰는 일(자동화 엔지니어)과 어제 깨진 걸 고치는 일(TestOps)은 늘 경쟁하고, 후자는 긴급하고 전자는 중요하다. 당번 제도의 또 다른 효용이 여기 있다 — 당번인 주에는 운영을, 당번이 아닌 주에는 작성을 한다고 정해 두면 두 일이 서로를 잡아먹지 않는다.
성숙도 — 지금 어디까지 왔는지 보는 눈금
TestOps 를 한 번에 완성하려는 시도는 거의 실패한다. 순서가 있다. 다음 네 단계는 도입 순서이자 진단 눈금으로 쓸 수 있다.
1단계 — 돈다
자동화가 사람 개입 없이 정기적으로 실행된다. 결과를 누군가 본다.
(여기까지가 m14 의 범위)
2단계 — 믿는다
실패가 실패를 뜻한다. 플래키가 집계되고 격리되며 복귀한다.
빨간 빌드에 소유자가 있다. 환경 장애가 테스트 실패와 구분된다.
3단계 — 설명한다
추세가 보인다. 실행 시간·플래키율·대기 시간이 기록되고 악화를 감지한다.
"이 버전에서 무엇이 통과했는가"에 즉시 답한다.
4단계 — 조종한다
용량과 범위를 수요에 맞춰 조절한다. 실패 분류의 대부분이 자동이고,
사람은 모호한 것만 본다. 테스트 결과가 릴리스 판정에 기계적으로 들어간다.2단계를 건너뛰고 3단계를 만들면 — 즉 신뢰도를 세우기 전에 대시보드를 먼저 만들면 — 예쁜 화면에 믿을 수 없는 숫자가 올라간다. 그게 실무에서 가장 흔한 실패 순서다.
실무에서 왜 필요한가
자동화 도입이 좌초하는 지점은 거의 언제나 "작성 완료" 이후다. 도입 제안서를 쓰고 프레임워크를 세우고 테스트 200개를 짜는 일은 프로젝트로 다룰 수 있다 — 시작과 끝이 있고, 산출물이 눈에 보이고, 성과를 보고할 수 있다. 반면 매일 그것이 믿을 만하게 도는 상태를 유지하는 일은 프로젝트가 아니라 운영 이고, 운영은 담당자가 지정되지 않으면 아무도 하지 않는다.
조직 입장에서 이 모듈의 가치는 비용 구조에 있다. 자동화의 총비용은 작성 비용이 아니라 작성 비용 + 운영 비용이고, 운영 비용은 플래키율과 트리아지 시간에 거의 비례한다. 플래키율이 5%인 500개 테스트 묶음은 매 실행마다 25건의 가짜 실패를 만들고, 한 건당 분류에 5분이 들면 매 실행 2시간이 사람 시간으로 사라진다. 이걸 줄이는 작업은 테스트를 새로 짜는 작업보다 투자 수익이 크다. 그런데 눈에 덜 보이기 때문에 늘 뒤로 밀린다.
경계표가 필요한 이유도 같은 데 있다. "자동화 좀 봐 주세요"라는 모호한 요청이 "트리거를 바꿔 달라"·"구조를 고쳐 달라"·"운영 규칙을 정해 달라" 중 하나로 번역되지 않으면 담당자가 생기지 않고, 담당자 없는 요청은 아무 데도 도달하지 않는다.
채용시장에서의 위치
자동화 경력 3~5년 구간에서 지원자가 가장 많이 막히는 질문이 "그 자동화가 지금도 돌고 있습니까"다. 짠 경험은 설명할 수 있지만 유지한 경험을 말하지 못하면, 면접관은 그 자동화가 이미 죽었다고 가정한다. 반대로 "플래키율을 12%에서 2%로 내렸고 그 과정에서 격리 규칙을 이렇게 만들었다" 처럼 운영 경험을 숫자와 규칙으로 말할 수 있으면, 연차를 건너뛰는 평가를 받는 일이 흔하다.
직함으로는 SDET·테스트 플랫폼 엔지니어·QA 인프라 엔지니어 공고가 이 영역을 직접 가리킨다. 공고 문구에서 이 영역을 알아보는 단서는 "테스트 실행 환경 구축·운영", "CI 안정화", "테스트 인프라", "품질 지표 체계 수립" 같은 표현이다. 이런 문구가 있는 공고의 면접은 코딩 테스트 비중이 낮고 운영 시나리오 질문 비중이 높다 — "실행이 밀리면 무엇부터 줄이겠습니까" 같은 질문에 순서와 근거를 말할 수 있어야 한다. 이 모듈의 레슨 2와 7이 그 두 질문의 모범 답안에 해당한다.