왜 지금 프론트엔드 테스트인가 — AI 시대의 안전벨트

「프론트엔드 테스트 제대로 하기」 시리즈의 1편입니다. 전체 목차 보기 · 용어집

“테스트요? 지금도 잘 돌아가는데요.”

한 번쯤 해봤거나, 들어봤을 말이죠. 저도 오랫동안 그랬습니다. 눈으로 보고, 손으로 클릭해보고, “어 되네” 하면 그걸로 충분하다고 생각했어요. 그런데 기능이 늘고, 코드를 고칠 때마다 “이거 고치면 저쪽이 안 터지나?” 하는 불안이 스멀스멀 올라오기 시작하면, 그때가 바로 테스트가 필요해지는 순간입니다.

이 글은 새 시리즈 「프론트엔드 테스트 제대로 하기」의 첫 편이에요. 단위 테스트부터 Playwright E2E, 접근성 검증, CI 자동화, 그리고 AI를 활용한 테스트까지 — 하나의 데모 앱을 함께 만들며 테스트를 한 겹씩 쌓아갈 겁니다. 첫 편인 오늘은 코드 대신, “왜 테스트인가"와 “우리가 앞으로 뭘 함께 만들 건가"를 정리해볼게요.

이 시리즈의 눈높이 — 출발점과 도착점

시작하기 전에, 우리가 어디서 출발해서 어디까지 갈지 약속해둘게요.

전제하는 건 딱 두 가지입니다. JavaScript/React 기초, 그리고 터미널에서 npm 명령어를 실행할 수 있는 정도. 테스트 경험은 0이어도 괜찮습니다. 낯선 용어는 처음 나오는 그 자리에서 바로 풀어서 설명할 거예요. “이 정도는 알겠지” 하고 건너뛰지 않겠습니다.

그리고 도착점. 이 시리즈를 완주하면 여러분은 —

• 무엇을 얼마나 테스트할지 스스로 전략을 세우고
• 단위부터 E2E까지 테스트를 직접 설계·작성하고
• flaky 테스트의 원인을 짚어 고치고, 접근성과 CI 게이트까지 갖추고
• AI가 만든 코드와 테스트를 검증할 줄 아는

개발자가 됩니다. 면접에서 “테스트 어떻게 하세요?“라는 질문에 자기 경험으로 답할 수 있는 수준 — 겸손하게 말해도 중수, 실무 기준으로는 꽤 앞선 쪽입니다. 챕터 하나가 레벨 하나예요. 가볍게, 한 계단씩 올라가 봅시다.

테스트, 왜 짜야 할까

테스트를 “버그 잡는 도구"로만 생각하면 절반만 아는 거예요. 테스트가 진짜로 주는 건 이런 것들입니다.

• 자신감: 코드를 고쳐도 “통과했으니 괜찮다"는 안전벨트가 생깁니다. 리팩터링이 무섭지 않아져요.
• 살아 있는 문서: 잘 쓴 테스트는 “이 함수는 이렇게 동작한다"를 코드로 보여줍니다. 주석보다 정직하죠 — 주석은 낡은 채로 거짓말을 하지만, 테스트는 틀리는 순간 빨간불로 항의하거든요.
• 디버깅 시간 절약: 문제가 생겼을 때 “어디서 깨졌는지"를 테스트가 먼저 짚어줍니다.
• 설계 피드백: 테스트하기 어려운 코드는 대개 설계가 꼬여 있다는 신호예요.

피라미드냐, 트로피냐

“그럼 테스트를 뭐부터, 얼마나 짜야 하죠?” 여기서 두 가지 유명한 그림이 등장합니다.

• 테스트 피라미드: 아래에 빠르고 많은 단위 테스트, 위로 갈수록 느리고 적은 통합·E2E 테스트.
• 테스트 트로피: 프론트엔드에서는 “사용자처럼 동작하는” 통합·컴포넌트 테스트의 가치를 더 크게 보는 관점.

정답은 “상황에 따라 다르다"지만, 이 시리즈는 아래(단위)에서 위(E2E)로 차근차근 올라갑니다. 기초 체력을 먼저 기르고, 그 위에 사용자 시나리오를 얹는 순서예요.

AI 시대에, 테스트는 더 중요해졌습니다

여기가 요즘 제가 가장 하고 싶은 이야기예요.

AI가 코드를 엄청난 속도로 만들어줍니다. 문제는, AI가 만든 코드가 종종 “그럴듯하게 틀린다“는 거예요. 컴파일도 되고 화면도 뜨는데, 엣지 케이스에서 조용히 어긋나거나 접근성을 슬그머니 빠뜨립니다. 사람이 눈으로 다 잡기엔 코드가 너무 빨리, 너무 많이 쏟아져요.

그래서 테스트가 AI 시대의 안전벨트가 됩니다. “AI야 이거 만들어줘"의 짝은 “그럼 이게 진짜 맞는지 어떻게 검증하지?“거든요. 생성은 AI가, 검증의 마지막 책임은 사람과 테스트가 지는 구조. 이 시리즈 후반부(5장)에서는 아예 AI에게 테스트를 짜게 하고, 그 테스트를 우리가 검증하는 방법까지 다뤄볼 거예요.

“이거 금방 되겠지” 하고 짠 테스트가 로컬에선 초록불인데 CI(코드를 올릴 때마다 자동으로 검사를 돌려주는 서버 — 나중에 함께 만듭니다)에서만 빨간불이 켜진다면, 축하합니다. flaky 테스트의 세계에 입문하신 거예요. 괜찮아요, 나중에 같이 탈출합니다.

접근성도, 결국 테스트입니다

이 블로그를 오래 보신 분이라면 눈치채셨을 거예요. 접근성과 테스트는 생각보다 가깝습니다.

“버튼을 역할(role)로 찾는” 좋은 테스트는, 동시에 “스크린 리더도 이걸 버튼으로 인식하는가"를 검증합니다. 즉 잘 짠 테스트가 곧 접근성 검증이 되는 지점이 있어요. 이 시리즈는 그 교집합을 적극적으로 활용합니다. axe-core로 접근성 위반을 자동 검사하고, role 기반 쿼리로 “사용자처럼” 테스트하는 법을 함께 익혀갈게요.

이 시리즈에서 함께 만들 것

말로만 하면 재미없죠. 우리는 React + Vite + TypeScript로 작은 실전 앱(폼·목록·검색·비동기 요청이 있는 대시보드)을 만들고, 거기에 테스트를 얹어갈 겁니다. 각 편의 코드는 companion 데모 저장소(frontend-testing-lab)의 태그로 제공돼서, git checkout step-N으로 그 편의 상태를 그대로 따라올 수 있어요. 완성된 앱이 궁금하다면 라이브 데모에서 설치 없이 바로 만져볼 수 있고, StackBlitz로 열면 브라우저에서 코드까지 살펴볼 수 있습니다.

전체 로드맵은 이렇습니다.

• 0장. 왜/무엇을 — 왜 테스트인가(지금 이 글) · 무엇을 얼마나(전략·커버리지의 함정)
• 1장. 단위 테스트 — 프로젝트 세팅 & Vitest · 단위 기초 · 비동기/에러 · 테스트 더블(mock)
• 2장. 컴포넌트 테스트 — Testing Library · 폼/상호작용 · MSW 네트워크 모킹 · 접근성을 테스트에 녹이기
• 3장. E2E & Playwright — 첫 시나리오 · 로케이터/flaky · 픽스처/병렬 · 트레이스 디버깅 · axe로 접근성 E2E · 시각적 회귀
• 4장. 자동화 & 품질 — GitHub Actions CI · 커버리지 읽는 법
• 5장. AI 시대의 테스트 — AI로 테스트 생성 · Playwright × AI · AI가 만든 코드의 함정 · 회고

마치며

테스트는 “언젠가 여유 생기면 하는 것"이 아니라, 지금 나를 덜 불안하게 만드는 도구예요. 특히 AI가 코드를 쏟아내는 요즘은, 빠르게 만드는 능력만큼 빠르게 검증하는 능력이 실력이 됩니다.

다음 편에서는 본격적으로 데모 앱을 세팅하고 첫 테스트를 초록불로 만들어볼게요. expect(우리의_다음_한_걸음).toBe('세팅과 첫 테스트') — 함께 가봅시다.

다음 편: 무엇을 얼마나 테스트할까 — 커버리지 100%의 함정

낯선 용어가 있었다면 — 용어집에 전부 한 줄씩 정리돼 있어요.