들어가며
안녕하세요, AI 플랫폼 팀 프론트엔드 개발자 이효린, 변수미입니다. 테스트 코드 작성이 늘 뒤로 밀리는 현실 속에서, 저희 팀이 AI로 이를 자동화해본 경험과 배운 점을 공유드리겠습니다.
개발을 어느정도 해보셨다면 테스트 코드, TDD(Test-Driven-Development)에 대해서 들어보고 궁금해했던, 더 나아가 내 프로젝트에 적용해보려 했던 경험이 다들 있으실 겁니다.
“아 테스트코드 짜야하는데..”
“이런 상황에서는 테스트코드가 꼭 필요할 것 같은데..”
특히, 저희 팀의 경우에는 아래와 같은 상황이기에 더더욱 테스트 코드 작성이 필요한 상황이었습니다.
- QA 팀이 없음
- 많은 기능을 짧은 시간에 만들어야 함
- 개발자들끼리 QA를 하는데, 놓치는 부분도 많고 그 리소스가 아까움
그럼에도 불구하고 저희는 선뜻 테스트코드를 작성하지 못하고 있습니다.
1. 테스팅을 실무에 도입하기 어려운 이유
이렇게나 필요한 상황인데 왜 테스트 코드를 못 쓰고 있었을까?
1-1. 구조적 / 조직적 요인
완벽한 코드로 마감 기한을 놓치기 vs 일단 돌아가는 코드라도 짜서 마감 기한 맞추기
실무에서 전자를 선택하는 개발자는 단 한 명도 없을 것입니다. 테스트 코드는 당장 눈앞의 기능 구현보다
나중을 위한 투자에 가깝습니다. 대부분의 프로젝트는 이번 주 데모 혹은 이번 릴리즈 가 더 중요합니다. 1-2. 기술적 요인
- 테스트하기 어려운 코드 구조
기존 코드가 의존성 덩어리로 얽혀 있는 경우, 테스트를 추가하기는 매우 어렵습니다. React 컴포넌트 안에 API 호출, 상태관리, DOM 조작이 다 섞여 있다면, mocking만 하다가 하루가 끝나기도 합니다.
- 테스트 환경 구축의 피로감
Vitest, Jest, Cypress, MSW, React Testing Library… 테스트 도구들은 많지만, 설정부터 쉽지 않습니다. 테스트 환경을 세팅하다가 “테스트보다 환경 설정이 더 오래 걸린다”는 말도 나옵니다.
- 유지보수의 어려움
테스트가 너무 세세하게 작성되어 있으면 코드 한 줄만 수정해도 테스트 수십 개가 깨집니다.
결국 “테스트가 발목을 잡는다”는 인식이 생겨, 다음부터는 아무도 테스트를 안 쓰게 됩니다.
1-3. 문화적 / 인식적 요인
- 가시적 성과가 없다
테스트 코드는 화면에 보이지 않습니다.
“이 기능 돌아간다”는 눈에 보이는 성과가 없다 보니, 테스트 작성은 성과 없는 일로 여겨집니다.
- 테스트 작성 역량 부족
대부분의 개발자는 기능 구현에는 익숙하지만, “무엇을, 어디까지 테스트해야 하는가”를 판단하는 데는 익숙하지 않습니다. 테스트의 단위를 잘못 잡으면
테스트는 귀찮고 쓸모없는 일이 되어버립니다.이번 글에서 “코드 품질을 위해서라면 테스트 코드를 써야 한다” 같은 원론적인 이야기를 하려는 게 아닙니다. 테스트 코드가 필요하다는 건 누구나 알고 있습니다. 문제는 ‘그걸 어떻게 현실적으로 적용할 수 있느냐’ 입니다.
그래서 이번 글에서는 저희 팀이 실제 프로젝트에서 적은 리소스로 빠르게 테스트 코드를 작성하고, 효율적으로 검증했던 경험을 공유드리려 합니다.
2. 우리 팀에서 정한 테스트 코드 규칙
테스트를 작성하기 전에, 먼저 어떻게 테스트를 작성해야 하는지에 대한 감이 잘 오지 않았습니다. 특히 공통적으로 아래와 같은 부분에 대해 질문이 나오곤 했습니다.
"모든 코드를 다 테스트해야 하나?"
"어디서부터 시작해야 하지?"
"어디서부터 어디까지 Mocking해야 하는 거야?"
이를 해소하기 위해 저희는 다음과 같이 두 가지의 규칙을 정했습니다.
2-1. 테스트 피라미드 모델
Mike Cohn이 그의 저서 Succeeding with Agile 에서 ‘테스트 피라미드 모델’이라는 개념을 고안했습니다.
이 피라미드의 목적은 다음과 같습니다.
“빠르고, 안정적이고, 유지보수하기 쉬운 테스트를 효율적으로 구성하자.”
그래서 저희는 피라미드 모델에 따라 전체 테스트 코드의 비율을 다음처럼 가져가는 것으로 결정했습니다.
- 단위 테스트: 70% - 빠르고 안정적, CI에서 항상 실행
- 통합 테스트: 20% - 핵심 사용자 플로우 중심
- E2E 테스트: 10% - 크리티컬 패스만(로그인, 결제 등)
2-2. 언제, 무엇을 검증할 것인가?
검증 방식 | 테스트 대상 | 이유 |
화면에 나오는 결과에 대해서만 검증 | React 컴포넌트 | 사용자 관점 테스트, RTL 철학과 부합 |
ㅤ | 순수 함수 / 유틸 | 의존성 없음 / Mock 불필요 |
코드 흐름 및 내부 로직 간의 상호 작용 검증 | 비즈니스 로직 클래스 | 객체 협력을 명확히 검증해야함 |
ㅤ | 복잡한 워크플로우 | 호출 순서와 조건 분기 검증 |
API 호출부에 대해서만 로직 검증, 그 외엔 화면에 나오는 결과 검증 | API 통신 | 실제 네트워크 흐름 유지 |
핵심 원칙
- 사용자가 보는 것(UI, 결과) → 화면에 나오는 결과에 대한 검증
- 객체 간 협력(함수 호출, 순서 중요) → 코드 흐름 및 내부 로직 간의 상호 작용 검증
- Mock은 최소한으로, 꼭 필요한 곳에서만!
3. Claude Code를 활용해 테스트 에이전트 만들기
이제 본격적으로 AI 에이전트를 활용해 테스트를 자동화하는 방법을 소개하겠습니다.
엑셈 에서는 AI 개발 도구로 Claude와 Cursor를 공식 지원하고 있어 Claude를 실무에 활용하고 있습니다. 따라서 아래에서는 Claude Code 기준으로 설명을 이어가겠습니다.
본 글은 Claude Code 기준으로 설명하지만, GPT-Codex·Copilot 등 다른 AI도 유사한 방식으로 적용 가능합니다.
전체 아키텍처
저희는 Claude Code를 기반으로 테스트 자동화 시스템을 구축했습니다. Claude Code는 명령줄에서 직접 실행되는 AI 에이전트로, 코드 작성부터 테스트 실행까지 자동화할 수 있습니다.
1단계: 프로젝트 컨텍스트 구축
AI 에이전트가 우리 프로젝트의 규칙과 구조를 이해할 수 있도록
CLAUDE.md 파일을 작성합니다. 저희가 작성한 파일을 간략하게 공유드리도록 하겠습니다.
- 테스트 시 mocking의 경우 네트워크 레벨부터 모킹을 하도록 작성하였습니다.
- 그 외의 i18n이나, Tanstack-Query는 실제 provider 값을 가져다 쓸 수 있도록 render 함수를 만들었고, 테스트 시 이를 가져다 쓸 수 있도록 작성했습니다.
2단계: 서브에이전트 생성
각 테스트 단계에 특화된 테스트 작성 에이전트를 생성합니다.
유닛 테스트 서브 에이전트
통합 테스트 서브 에이전트
통합 테스트에서 가장 발목을 잡았던 것은 모킹과 관련된 부분이었습니다. 이에 저희 팀만의 모킹 바운더리를 정했고, 이 바운더리 안에서 테스트 코드를 작성할 수 있도록 작성하였습니다.
각 에이전트는 CLAUDE.md를 읽고, 프로젝트의 컨벤션을 따라 테스트를 작성합니다.
라우팅 동작 방식
전체 동작 플로우
Claude Code가 CLAUDE.md를 읽고 프로젝트의 규칙을 이해한 후, 그 규칙에 맞게 테스트를 생성해주게 됩니다.
4. 실전 예제: util / 로그인 폼 통합 테스트
이제 생성한 서브에이전트를 바탕으로 실제 로그인 페이지를 예시로 테스트를 작성해보겠습니다.
유닛 테스트 자동 생성
요청:
lib/utils.ts 에 대한 테스트 코드 만들어줘. 요청을 받은 클로드코드는 다음과 같은 테스트코드 작성 계획을 세우고 동작을 실행하였습니다.
테스트 코드 및 파일이 생성되었습니다.
생성된 테스트 코드 중 일부입니다.
테스트를 실행시켜보면 모두 잘 통과되는 모습을 볼 수 있습니다.
통합 테스트
LoginForm.tsx 컴포넌트에 대한 테스트코드 작성을 요청하였습니다. 
테스트 코드 작성이 완료되었습니다.
이제 실행시켜 보면, 몇 개의 테스트가 실패한 것을 확인할 수 있습니다.
번외: 테스트가 실패한 경우
몇 개의 테스트가 실패했네요! 여기서 우리는 갈림길에 빠지게 됩니다.
- 테스트코드가 잘못 짜여진 것이다.
- 우리가 짠 코드가 잘못 짜여진 것이다.
무작정 AI에게 “실패한 테스트를 성공하게 고쳐줘”라고만 요청하면, 오류가 있는 기존 코드를 그대로 인정한 채 테스트만 수정해 통과시키는 문제가 발생했습니다.
이를 방지하기 위해, 저희는 에이전트에게 “테스트 실패 시, 우선 원인을 분석하고 기존 코드가 올바른지 검증한 뒤 수정 방향을 제안하도록” 규칙을 명시했습니다.
에이전트에게 테스트 실패 원인을 파악하라고 시켜보겠습니다.
다음과 같이 실패 원인을 파악할 수 있었습니다.
- Input 컴포넌트
이 경우에는 error 스타일과 type을 접근성에 맞지 않게 사용했기 때문에 테스트 통과에 실패했던 것이었습니다.
→ 컴포넌트 수정이 필요합니다.
- Form Validation
required 속성으로 브라우저가 빈 입력을 막아 빈 입력에 관한 테스트가 실패한 것이었습니다.
→ 브라우저의 정상 동작이기 때문에 테스트 코드를 수정해야 합니다.
파악한 원인을 기반으로 수정해보도록 하겠습니다.
앞서 클로드가 분석해준 내용을 토대로 컴포넌트 수정이 필요한 부분과 테스트 코드 수정이 필요한 부분을 나누어 개선 작업을 진행하였고, 이제 모든 테스트가 통과되는 것을 알 수 있었습니다.
5. Playwright MCP로 E2E 자동화 하기
앞서 에이전트를 활용해 유닛 테스트와 통합 테스트 코드를 자동으로 작성하고 실행하는 과정을 소개드렸습니다.
하지만 실제 서비스 품질을 보장하기 위해서는 E2E(End-to-End) 테스트 또한 필수입니다.
하지만 E2E 테스트 코드 작성이 생각보다 쉽지 않습니다.
- 테스트 시나리오를 정의하고,
- 각 화면 요소의 셀렉터를 찾아 클릭·입력·검증 로직을 직접 작성하고,
- 실패할 경우 스크린샷이나 비디오를 수집하고,
- 버그 리포트를 정리해야 합니다.
이 모든 과정은 시간이 오래 걸리고 유지보수도 번거롭습니다.
💡 이런 문제를 해결하기 위해 도입한 도구가 바로 Playwright MCP입니다.
Playwright MCP 소개
Playwright MCP는 자연어 기반으로 E2E 테스트를 자동 생성하고 실행할 수 있게 해주는 도구로, 테스트 실패 시 GitHub Issue까지 자동 등록할 수 있습니다.
즉,
테스트 작성 → 실행 → 결과 보고 → 이슈 관리의 모든 과정을 자동화할 수 있습니다.이번 자동화 시스템은 Microsoft에서 제공하는
@playwright/mcp 라이브러리를 기반으로 구현되었습니다.
이 라이브러리를 MCP 서버로 등록하면, ChatGPT나 Claude Code와 같은 에이전트가 직접 Playwright를 실행하고 테스트를 생성·수정·재실행할 수 있습니다.핵심 기능:
- 자연어로 테스트 시나리오 작성
- 자동 실행 및 결과 확인
- 실패 시 스크린샷/비디오 자동 캡처
- GitHub Issue 자동 등록
저희는 Claude Code를 기반으로 사용할 예정이기에 아래 명령어를 통해 MCP를 연결할 수 있습니다.
아래 명령어 한 줄이면 MCP 서버를 손쉽게 등록할 수 있습니다.
MCP가 연결되었음을 확인하였습니다.
따라서 Claude Code에서 “구글 가서 네이버 검색해줘” 라고 입력을 하게 된다면 직접 playwright를 실행해 네이버를 검색해줍니다.
실전 예제: 로그인 페이지 E2E 테스트
1단계: 자연어로 테스트 요청
이를 활용해 지금부터 E2E 테스트 코드를 작성해보겠습니다.
요청:
로그인 페이지 E2E 코드 작성해줘. 로그인 성공 후 홈 화면으로 라우팅 되는 시나리오는 꼭 포함해줘
2단계: Claude가 테스트 코드 작성
CLAUDE.md 파일에 적혀있는 것을 바탕으로 mocking 바운더리를 지키며 테스트코드를 생성해줍니다.
아래처럼 시나리오를 7개 가량 생성해주었습니다.
3단계: 자동 실행
테스트 코드 작성이 완료되면 Playwright MCP가 자동으로 테스트를 실행합니다.
테스트 7개가 실패하였습니다. 그 중 5개는 1번 문제로 인해, 2개는 2번 문제로 인해 발생하였습니다.
1번과 2번의 경우에는 테스트 코드가 잘못 작성 되어있던 것이기에 클로드가 수정을 시작하였습니다.
4단계: 실패 시 GitHub Issue 자동 등록
그런데 만일 테스트 코드가 아니라 우리 코드가 잘못 작성되었던 것이면 어떨까요?
테스트 코드가 잘못 작성된 것이라면 빠르게 수정 가능하지만, 우리 코드가 잘못 작성 됐을 경우에는 수정하는데에 오랜 시간이 걸리게 됩니다.
이런 경우를 대비해 GitHub Issue 자동 등록 시스템을 구축했습니다.
테스트가 실패하면 다음 프로세스가 자동 실행됩니다.
실패한 E2E 테스트:
E2E 테스트 실행이 완료되면 테스트 레포트가 생성되게 됩니다. 다음과 같은 테스트 실패가 발생하였습니다.
그렇다면
실제 생성된 GitHub Issue:
GitHub Issue로 자동 등록되는 것을 볼 수 있었습니다.
6. E2E 자동화 전체 플로우
7. 마치며
테스트 에이전트를 생성하기 전엔 “테스트 코드는 사치”라고 생각했습니다.
테스트 코드 작성을 위해 준비해야 할 과정들이 너무 많았고, 요구사항이 변경될 때마다 기존 테스트 코드를 일일이 수정해야 하는 높은 유지보수 비용도 큰 부담으로 느껴졌기 때문입니다.
하지만 AI 에이전트를 실험하면서, 이러한 반복적인 수정 작업을 일정 부분 자동화할 수 있다는 가능성을 확인했습니다. 이를 통해 테스트 코드 작성에 대한 심리적 부담을 크게 덜 수 있었습니다.
그래도 여전히 사람이 개입해야하는 부분은 존재합니다. AI 에이전트가 자동으로 코드를 생성하고 수정하더라도, 테스트의 의도나 맥락을 이해하고 ‘무엇을 검증해야 하는가’를 판단하는 일은 결국 개발자의 몫이기 때문입니다.
결론적으로 AI 에이전트는 만능이 아니지만, 테스트 코드 작성의 진입 장벽을 눈에 띄게 낮춰주는 도구임은 분명합니다.
"테스트 코드, 그거 꼭 해야 돼?"
이제 우리의 대답은 이렇습니다:
"네, 하지만 AI를 믿고 맡겨보는 건 어떨까요?"
참고 자료
요시이 다케후미, 『프런트엔드 개발을 위한 테스트 입문』 , 2024 블라디미르 코리코프 , 『단위 테스트』 , 2021 로이 오셔로브 , 블라디미르 코리코프, 『단위 테스트의 기술』, 2024 Playwright MCP - Microsoft Claude Code Documentation
함께 보면 좋은 아티클
