개념
병목이 옮겨갔다 — 코드 생성에서 신뢰 생성으로
지난 20년간 소프트웨어 개발의 병목은 대체로 코드를 만드는 일 이었다. 기능 하나를 붙이려면 사람이 설계하고 쓰고 리뷰해야 했고, 그 속도가 곧 제품의 속도였다.
AI 지원 개발 도구가 이 전제를 흔들고 있다. 코드 생성이 빠르고 싸지면서 병목이 다른 곳으로 이동했다.
이제 어려운 것은 소프트웨어를 만드는 일이 아니라, 그것을 믿어도 된다고 말할 근거를 만드는 일 이다.
QA에게 이건 나쁜 소식이자 좋은 소식이다. 나쁜 소식은 변경량이 폭증한다는 것이고 — 우리가 검증해야 할 것이 훨씬 빨리 늘어난다 — 좋은 소식은 병목이 우리 쪽으로 왔다는 것 이다. 병목에 있는 직무는 사라지지 않는다. 다만 일하는 방식이 바뀐다.
이 레슨과 다음 레슨은 그 변화의 한 갈래를 다룬다. 이미 조직이 가지고 있는 자동화 자산 — 수백에서 수만 개에 이르는 Selenium·Playwright 스크립트 — 을 버리지 않고 AI 기반 실행 모델로 옮기는 방법 이다.
절차적 자동화의 구조적 한계
모듈 13에서 우리는 UI 자동화를 배웠다. 로케이터를 안정적으로 잡고, 대기 전략을 세우고, 페이지 객체로 중복을 줄였다. 그 기법들은 여전히 유효하다. 다만 이 접근 전체가 공유하는 성질이 하나 있다.
절차적 자동화는 구현 세부사항을 코드에 새긴다.
driver.findElement(By.id("submit-btn")).click();
wait.until(ExpectedConditions.visibilityOfElementLocated(By.css(".order-total")));
assertEquals("₩45,000", driver.findElement(By.css(".order-total")).getText());이 세 줄은 무엇을 확인하려는지 를 말하지 않는다. 대신 어떻게 확인할지 만 말한다. 사람이 읽으면 "주문 총액이 맞는지 보는구나"라고 유추할 수 있지만, 그 유추는 코드 어디에도 적혀 있지 않다.
그래서 화면이 바뀌면 테스트가 깨진다. submit-btn이 checkout-submit이
되면, 의도는 하나도 변하지 않았는데 코드는 실패한다. 이 유지보수 비용은
오랫동안 감수할 만했다 — 애플리케이션의 변경 속도가 관리 가능했기 때문이다.
그 전제가 무너지는 중이다. AI가 생성하는 코드가 늘면 UI 변경의 양과 속도가 함께 는다. 유지보수 비용이 선형으로 늘어나는 구조에서, 변경량이 몇 배가 되면 자동화 팀은 따라가지 못한다.
기존 스위트는 부채인가 자산인가
여기서 조직이 흔히 저지르는 판단 실수가 있다. 낡은 자동화 스위트를 기술 부채로 규정하고 통째로 버리는 것 이다.
모듈 11(레슨 4)에서 자동화 부채를 배웠다. 거기서 우리는 "자동화 테스트가 많을수록 좋다"는 말이 틀렸고, 유지보수되지 않는 테스트는 자산이 아니라 부채라는 것을 확인했다. 그 결론은 지금도 맞다. 하지만 부채인 것은 스크립트이지, 그 안에 담긴 지식이 아니다.
성숙한 자동화 스위트 안에는 이런 것들이 들어 있다.
| 코드에 박혀 있는 것 | 실제로는 무엇인가 |
|---|---|
| 어떤 워크플로를 테스트했는가 | 조직이 중요하다고 판단한 고객 여정 |
| 어떤 값을 검증했는가 | 문서에 없을 수도 있는 요구사항과 비즈니스 규칙 |
| 왜 이 순서로 실행했는가 | 시스템 동작에 대한 운영 지식 |
| 왜 이 케이스가 존재하는가 | 과거에 실제로 터진 결함의 역사 |
| 어떤 데이터로 테스트했는가 | 경계·예외에 대한 도메인 전문성 |
자동화 테스트 하나하나는 누군가가 "이건 중요하다"고 내린 결정의 기록 이다. 검증문 하나하나는 요구사항을 붙잡아 둔 것이다. 이 관점에서 보면 Selenium 스위트는 테스트 프레임워크라기보다 조직 지식의 저장소 에 가깝다.
수천 개의 테스트를 지우는 것은 코드를 지우는 게 아니라 그 결정들의 기록을 지우는 것 이다. 그리고 그 지식을 다시 만들려면 처음 만들 때만큼, 혹은 그보다 더 오래 걸린다.
전환의 목표를 한 문장으로: 코드를 옮기는 것이 아니라, 코드에 갇힌 의도를 꺼내 다시 표현하는 것.
4단계 전환 프레임워크
이 관점 위에서 전환 과정은 네 단계로 구성된다.
① AI 준비도 분석 코드가 무엇에 의존하는지 전부 파악
↓
② AI와의 질의응답 코드 바깥에 있는 의도를 복원
↓
③ AI-First 테스트 정의 생성 절차 → 의도로 재표현
↓
④ 실행·검증 루프 돌려보고, 부족한 맥락을 되먹임
↑___________________________|각 단계를 순서대로 본다.
1단계 — AI 준비도 분석: 테스트가 무엇에 기대고 있는가
전환을 시작하기 전에, AI(그리고 사람)가 이해해야 할 것은 테스트가 무엇을 하는가 만이 아니다. 무엇에 의존하는가 가 더 중요하다. 분석 대상은 테스트 스크립트만이 아니라 페이지 객체, 헬퍼 라이브러리, 셋업·티어다운, 픽스처, 설정 파일, 유틸리티 코드 전부다.
여기서 찾아야 할 것이 다섯 갈래다.
(1) 숨은 가정(Hidden Assumptions)
문서 어디에도 적혀 있지 않지만 테스트가 조용히 기대고 있는 것들이다.
- 특정 환경 변수가 설정돼 있을 것
- 데이터베이스에 미리 심어둔 데이터가 있을 것
- 앞선 테스트가 만들어둔 공유 상태가 남아 있을 것
- 특정 기능 플래그가 켜져(또는 꺼져) 있을 것
- 야간 배치 작업이 이미 돌았을 것
이 목록은 자동화 엔지니어가 로컬에서 잘 되는데 CI에서만 깨지는 현상의 원인 목록이기도 하다. 오래된 스위트일수록 이런 가정이 많고, 대부분은 아무도 기억하지 못한다.
(2) 외부 종속성
API, 데이터베이스, 큐, 인증 시스템, 서드파티 서비스. 전환 시 이것들을 재사용 가능한 서비스로 바깥에 빼낼 수 있는가 를 평가한다. 모듈 4에서 배운 MCP 엔드포인트나 별도 유틸리티가 그 자리를 맡는다.
(3) 동적 런타임 데이터
테스트가 실행 중에 만들어내는 것들 — 사용자 계정, 토큰, 임시 레코드, 거래 번호. 이 흐름을 식별해두지 않으면 전환된 테스트는 첫 실행에서 "로그인할 계정이 없다"에서 멈춘다.
(4) 테스트 간 의존성
큰 스위트에는 숨은 실행 순서 요구가 흔하다. "테스트 C는 테스트 B가 만든 주문을 쓴다" 같은 것이다. 이런 관계를 찾아내 분리 가능한 지점 을 표시한다. 모듈 10에서 배운 테스트 독립성 원칙이 여기서 다시 나온다.
(5) 검증 로직
검증문이 UI에만 있는 것이 아니다. API 응답, DB 레코드, 로그, 리포트에 흩어져 있다. 이걸 모으는 것이 왜 중요한가? 검증문이 곧 "성공이란 무엇인가"의 정의 이기 때문이다. 전환 후에도 이 정의는 보존돼야 한다.
이 단계의 산출물은 AI 준비도 평가서와 전환 로드맵 이다.
2단계 — AI와의 질의응답: 코드 바깥의 지식 복원
전환 프로젝트에서 가장 놀라운 사실은 이것이다. 프레임워크 전체를 분석하고 나서도, 중요한 것들이 여전히 문서화돼 있지 않다.
- 이 워크플로는 왜 하필 이 순서로 실행되는가?
- 이 검증문은 어떤 비즈니스 규칙을 확인하는 것인가?
- 어떤 조건에서 이 워크플로는 실패해야 마땅한가?
- 이 대기 시간 5초는 무엇을 기다리는 것인가?
예전에는 이 답을 얻으려면 원래 작성한 엔지니어나 제품 담당자를 찾아다녀야 했다. 이미 퇴사했다면 답은 영영 사라졌다.
AI는 이 과정의 방향을 뒤집는다. 사람이 수년치 코드를 역설계하는 대신, AI가 분석한 뒤 "이 테스트를 확신 있게 전환하려면 무엇을 알아야 하는가" 라는 질문 목록을 만든다. 사람은 답만 하면 된다.
이 차이는 생각보다 크다. 빈칸을 찾는 일과 빈칸을 채우는 일은 난이도가 다르다. 실제로 대부분의 테스트는 놀랄 만큼 적은 설명만으로 의도가 복원된다. 정말로 아무도 모르는 소수의 테스트가 남는데, 그 사실 자체가 중요한 발견이다 — 아무도 이유를 모르는 테스트가 지금 CI에서 매일 돌고 있다는 뜻 이기 때문이다.
QA 실무 팁: 이 단계에서 나온 질문과 답변은 전환에만 쓰고 버리지 말고 테스트 문서로 남긴다. 전환을 하지 않기로 결정하더라도, 이 질의응답 만으로 스위트의 가치가 올라간다.
3단계 — AI-First 테스트 정의 생성
가정·종속성·의도가 확보되면 변환을 시작한다. 여기서 중요한 운영 원칙이 하나 있다. 전부를 한꺼번에 바꾸지 않는다.
AI에게 테스트를 복잡도 순으로 줄 세우게 하고, 단순한 것부터 전환한다. 복잡한 것은 사람 검토 대상으로 표시해 남긴다. 이렇게 하면 가치가 빨리 나오고 위험은 뒤로 미뤄진다 — 모듈 11에서 배운 점진적 자동화 전략 과 같은 사고다.
변환의 본질은 절차를 의도로 바꾸는 것 이다.
| 절차적 표현 (기존) | 의도 표현 (전환 후) |
|---|---|
#submit-btn을 클릭한다 | 주문을 확정한다 |
.order-total이 보일 때까지 기다린다 | 주문 결과가 화면에 나타날 때까지 기다린다 |
텍스트가 정확히 ₩45,000인지 확인한다 | 주문 총액이 장바구니 합계와 배송비를 반영한 값인지 확인한다 |
오른쪽이 왼쪽보다 구현 세부사항을 덜 담고 있다. 그런데 역설적으로 그래서 더 견고하다. 버튼 id가 바뀌어도 "주문을 확정한다"는 여전히 유효하기 때문이다.
여기서 나오는 산출물은 테스트 코드 가 아니라 구조화된 테스트 정의 다. 그 형식과 실행 방식은 다음 레슨에서 자세히 다룬다.
4단계 — 실행·검증 루프
정의를 만들었다고 전환이 끝난 게 아니다. 돌려보고, 검증하고, 다듬는 루프가 남아 있다.
런타임 데이터 준비 — 1단계에서 식별한 계정·토큰·시드 데이터를 재사용 가능한 서비스로 빼두고, 실행 시점에 주입한다.
전환 루프 — 첫 실행은 거의 항상 실패한다. 이때 중요한 것은 실패를 대하는 방식이다.
실패 발생
↓
AI가 증거(스크린샷·로그·실행 궤적)를 검토
↓
"무슨 정보가 없어서 판단하지 못했는가?"
↓
답을 테스트 정의에 보강
↓
재실행이 루프의 성질을 놓치면 안 된다. 이 루프는 애플리케이션만 테스트하는 것이 아니라 전환 자체를 테스트한다. 실패가 앱의 결함인지, 정의의 불충분함인지를 매번 가르는 것 — 그 판단이 QA의 일이다. 모듈 18c(AI 교차검증)에서 배우는 태도가 여기서 그대로 필요하다.
그래서 이건 어디까지 믿을 만한가
이 프레임워크는 매력적이지만, 커리큘럼의 태도대로 한 겹 의심하고 넘어가자. 이 주장을 펴는 쪽은 대체로 도구를 파는 쪽이기도 하다.
의심할 지점 1 — "덜 적을수록 견고하다"는 어디까지 참인가. 의도 표현이 UI 변경에 강한 것은 맞다. 하지만 정밀함이 반드시 필요한 검증도 있다. 금액·세금·정산 금액이 "합리적으로 보이는가"로 판정되면 안 된다. 정확히 45,000원이어야 한다. 어디에 의도를 쓰고 어디에 정확한 값을 쓸지 가르는 것은 여전히 사람의 판단이다.
의심할 지점 2 — 비결정성이라는 대가. 런타임에 판단하는 실행 모델은 같은 입력에도 다른 경로를 밟을 수 있다. 모듈 18b(레슨 5)에서 배운 문제가 그대로 따라온다. 실패했을 때 재현이 어려운 테스트 는 디버깅 비용이 크다.
의심할 지점 3 — 비용 구조가 다르다. Selenium 테스트 1,000개를 매 커밋마다 도는 것과, 판단이 개입하는 실행을 매 커밋마다 도는 것은 비용이 다르다. 유지보수 시간은 줄어도 실행 비용은 올라갈 수 있다. 어느 쪽이 더 큰지는 조직마다 다르다.
의심할 지점 4 — 규제 도메인의 증거 요구. 모듈 25에서 봤듯 안전·인증이 걸린 도메인에서는 "이 요구사항을 이 방법으로 검증했다"는 추적 가능한 증거가 필요하다. 실행 경로가 매번 달라지는 검증을 그 증거로 제출하려면 별도의 설계가 필요하다.
결론적으로, 전환은 전부/전무의 문제가 아니다. 어떤 테스트를 의도 기반으로 옮기고, 어떤 테스트를 결정적 스크립트로 남길지 가르는 것 이 현실적인 목표다. 그 판단 기준은 다음 레슨에서 표로 정리한다.
ROI를 어떻게 말할 것인가
이런 전환을 제안할 때 경영진에게서 가장 자주 나오는 질문은 "토큰 비용이 얼마나 드나"이다. 그런데 그건 대개 가장 중요하지 않은 지표 다.
더 유용한 질문은 이것들이다.
| 질문 | 어떻게 재는가 |
|---|---|
| 얼마나 많은 엔지니어링 시간이 사라졌는가 | 로케이터 수정·오탐 조사에 쓴 시간(스프린트당) |
| 얼마나 빨라졌는가 | UI 변경 후 자동화가 다시 초록이 되기까지 걸리는 시간 |
| 신뢰도가 올라갔는가 | 오탐(false failure) 비율, 자동화 결과를 무시하는 빈도 |
| 커버리지가 넓어졌는가 | 이전에는 비싸서 못 하던 검증(시각적 이상, UX 혼란)의 수 |
모듈 11(레슨 3)에서 배운 자동화 ROI 계산이 여기서 그대로 쓰인다. 다만 분모에 실행 비용(토큰) 이라는 항목이 새로 하나 붙을 뿐이다. 많은 팀에서 유지보수 절감만으로도 정당화된다 는 결과가 나오지만, 그건 계산해봐야 아는 것이지 전제할 것이 아니다.
이 레슨이 말하는 병목의 이동 을 우리 조직의 숫자로 확인하는 방법 — 리드타임을 작업·대기·재작업으로 쪼개고 암달의 법칙으로 개선 한계를 계산하는 것 — 은 레슨 13에서 다룬다. 전환 파일럿의 ROI를 말하기 전에 그 숫자부터 재 두면 기대치를 과장하지 않게 된다.
실무에서 왜 필요한가
자동화 스위트를 오래 운영해본 조직에는 반드시 "손대기 무서운 영역"이 있다. 아무도 이유를 모르지만 지우면 뭔가 터질 것 같은 테스트들. 이 레슨의 1·2단계는 전환을 하지 않더라도 그 자체로 가치가 있다. 숨은 가정과 복원된 의도를 문서로 남기는 순간, 그 영역은 더 이상 블랙박스가 아니다.
그리고 이 작업은 QA가 조직에서 위치를 바꾸는 계기가 되기도 한다. 자동화 엔지니어의 일이 "스크립트를 고치는 사람"에서 "조직이 무엇을 중요하게 여기는지 정의하고 관리하는 사람" 으로 이동하기 때문이다. 어떤 테스트가 어떤 비즈니스 규칙을 지키고 있는지 말할 수 있는 사람은 회의실에서 다른 무게를 갖는다.
현실적인 조언도 하나 붙인다. 전환은 전면 프로젝트로 시작하지 않는 게 좋다. 가장 유지보수 비용이 큰 스위트 하나(대개 UI 회귀 스위트)를 골라 20~30개 테스트로 파일럿을 돌리고, 절감 시간과 실행 비용을 실측한 뒤 확대 여부를 정한다. 그 실측값이 곧 다음 단계의 근거가 된다.
채용시장에서의 위치
"AI 시대에 테스트 자동화 엔지니어는 사라지는가"라는 질문이 업계에서 자주 나온다. 이 레슨의 내용은 그 질문에 부분적인 답을 준다.
사라지는 것은 직무가 아니라 작업이다. 로케이터를 고치고 대기 시간을 조정하는 작업의 비중은 줄어든다. 대신 늘어나는 것은 이런 일들이다.
- 이 시스템에서 무엇이 중요한지 정의하는 일
- "성공"과 "실패"의 기준을 판정 가능하게 만드는 일
- AI가 만든 정의와 판정을 검증하는 일
- 어디에 의도를 쓰고 어디에 정확한 값을 쓸지 가르는 일
개발 쪽에서 "코드만 짜는 개발자에서 제품 맥락을 이해하는 개발자로"라는 말이 나오는 것과 정확히 같은 이동이다. 테스트 쪽 버전은 이렇게 말할 수 있다 — 스크립트를 쓰는 사람에서, 무엇을 신뢰할 수 있는지 정의하는 사람으로.
채용 관점에서 실질적인 조언은 이것이다. "AI 도구를 써봤다"는 이제 변별력이 약하다. 변별력이 있는 것은 "기존 자산을 어떻게 다뤘는가" 다. 면접에서 이렇게 말할 수 있으면 층이 다르다 — "레거시 회귀 스위트 1,200개 중 유지보수 비용 상위 80개를 골라 의도 기반으로 전환했고, 전환 과정에서 아무도 이유를 모르던 테스트 14개를 발견해 그중 9개는 삭제, 5개는 규칙을 문서화했습니다."