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

> AI가 코드를 쏟아내는 시대일수록 테스트가 더 중요해졌습니다. 「프론트엔드 테스트 제대로 하기」 시리즈의 첫 글로, 테스트가 주는 것과 피라미드·트로피 전략, 그리고 앞으로 함께 만들 커리큘럼을 정리합니다.

**Published:** 2026-07-03 | **Updated:** 2026-07-05

---


> 「프론트엔드 테스트 제대로 하기」 시리즈의 **1편**입니다. [전체 목차 보기](/series/프론트엔드-테스트-제대로-하기/) · [용어집](/posts/frontend-testing-glossary/)

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

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

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

---

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

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

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

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

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

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

---

## 테스트, 왜 짜야 할까

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

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

{{< img src="images/contents/why-test.jpg" alt="안전벨트처럼, 테스트가 개발자 코드를 고쳐도 안심할 수 있게 해 줄 수 있습니다." caption="사진: <a href='https://unsplash.com/ko/사진/블랙-가죽-시트에-오렌지와-화이트-벨트-_g5Wb1X7WGM' target='_blank' title='새 창에서 열림'>Unsplash</a>의 <a href='https://unsplash.com/ko/@lovesyautopics' target='_blank' title='새 창에서 열림'>Remy Lovesy</a>">}}

---

## 피라미드냐, 트로피냐

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

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

{{< img src="images/contents/pyramid-vs-trophy.png" alt="테스트 피라미드(아래 단위 테스트가 넓고 위로 갈수록 좁아지는 E2E)와 테스트 트로피(통합·컴포넌트 테스트를 크게 강조)를 나란히 비교한 다이어그램" >}}

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

---

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

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

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

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

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

---

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

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

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

---

## 이 시리즈에서 함께 만들 것

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

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

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

{{< img src="images/contents/roadmap.png" alt="0장 개관부터 5장 AI 테스트까지, 시리즈의 다섯 챕터 커리큘럼을 한눈에 보여주는 로드맵 다이어그램" >}}

---

## 마치며

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

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

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

> 낯선 용어가 있었다면 — [용어집](/posts/frontend-testing-glossary/)에 전부 한 줄씩 정리돼 있어요.