E2E 테스트 자동화: AI가 바꾼 것과 남은 것
1분 읽기
들어가며
E2E 테스트에 관심을 가지고 다양한 글과 영상들을 참고하고 있습니다. 유독 2025년을 기점으로 E2E 자동화 도입 사례들이 눈에 띄게 늘었습니다. 스타트업부터 대규모 팀까지, E2E 테스트 자동화에 대한 실제 경험을 공유하는 글들이 많아졌습니다.
불과 얼마 전까지만 해도 리소스가 부족한 소규모 팀에서는 현실적으로 시도하기 어려웠던 E2E 테스트가, 어떻게 이제는 누구나 도입할 만한 가성비 좋은 선택지가 되었을까요?
"필요하지만 비싼" 선택지였던 E2E 테스트
지난 몇 년간 E2E 테스트 자동화는 "필요하지만 비싼" 선택지였습니다. 흔히들 '코드 품질을 위해 테스트 코드를 써야한다'는 원론적인 이야기를 하지만, 선뜻 테스팅을 실무에 도입하기 어려웠던 이유는 명확했습니다.
- 높은 초기 작성 비용
- 테스트 환경 구축의 피로감
- 비즈니스 마감 기한의 압박
- 리소스 한계
- 지옥 같은 유지보수
- 가시적인 성과의 부재
- 테스트 작성 역량 부족 (판단 기준의 부재)
- ...
테스트 코드를 붙잡고 있는 동안에는 새로운 기능은 나오지 않습니다. 테스트 코드가 완성된다고 해서 프로덕트 자체가 당장 바뀌는 것도 아닙니다. E2E 테스트는 배포 후 발생할 치명적인 장애를 예방하는 '나중을 위한 투자'이지만, 비즈니스 관점의 ROI를 따져야 하는 회사에서는 '당장 눈앞의 기능 구현'을 원할 것입니다.
TDD를 정립한 켄트 벡(Kent Beck)의 말처럼, 테스트 코드는 코드 수정에 대한 불안감을 해소하고 안정적인 구조 변경을 가능하게 하는 개발자의 최후의 '안전망'이 되어줍니다.
하지만 당장 이번 주 배포와 데모가 급한 현실 속에서, 기껏 공들여 짜놓은 테스트 코드가 UI 마크업 조금 바뀌었다고 허무하게 깨져버리면 개발자는 좌절할 수밖에 없습니다. 깨진 코드를 고치는 데 더 많은 공수가 들어가고, 테스트 실패로 배포마저 지연되기 시작하면 결국 테스트는 안전망이 아닌 팀의 '짐'이 되어버립니다.
MCP와 AI가 허문 장벽
- 과거: 눈과 손이 없던 AI
- 현재: 눈과 손을 얻은 AI 에이전트
- ✌🏻👁️✌🏻 ...
2024년 11월, Anthropic이 오픈소스로 공개한 MCP(Model Context Protocol)는 테스트 생태계의 판도를 바꾸었습니다.
AI에게 텍스트 창을 넘어 "내 컴퓨터 안의 코드를 읽고(File System), 모르는 건 인터넷에 검색하며(Brave), 직접 브라우저를 띄워 테스트해 보고(Playwright), 잘못된 건 코드를 고쳐서 깃허브에 올려라(GitHub)"라고 할 수 있는 종합 선물 세트