왜 프론트엔드 개발자들은 e2e 테스트를 작성하고 싶어하지 않을까

발행: 3일 전 (2026년 1월 13일 오후 05:13 GMT+9)

14 min read

I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (excluding the source line you already provided) here? Once I have the article text, I’ll translate it into Korean while preserving the original formatting, markdown, and any code blocks or URLs.

Source: …

소개

제목 때문에 이 글을 클릭했다면, 당신은 테스트 작성하기를 싫어하는 프론트엔드 개발자 중 한 명일 가능성이 높습니다 – 걱정 마세요, 저도 같은 입장입니다.

최근 설문 조사에 따르면, 대부분의 프론트엔드 팀이 테스트를 작성하지 않는다고 합니다. 그래서 저는 다음과 같은 질문이 떠올랐습니다:

왜 프론트엔드에서 테스트가 이렇게 보편적으로 혐오받을까요?
실제로 중요한 테스트 종류는 무엇일까요?
테스트를 더 빠르고 쉽게 작성할 수 있는 방법이 있을까요?

아래는 제가 본 주요 세 가지 이유이며, 이어서 E2E 테스트가 여전히 필수적인 이유와 이를 덜 고통스럽게 만드는 방법을 간략히 살펴보겠습니다.

Source: …

1️⃣ 테스트 작성이 느리고 보일러플레이트가 많아 보인다

DEV state of the web 2018

대부분의 개발자는 테스트를 혜택이라기보다 귀찮은 일로 여긴다. 테스트 파일이 기능 구현보다 길어지면 뭔가 이상하게 느껴진다.

가장 큰 동력 저해 요인은 보일러플레이트다.
실제로 관심 있는 “사용자 흐름”에 들어가기 전에, 여러 가지 관리 작업을 해야 한다:

브라우저 환경 정의하기.
API 호출을 모킹하기.
인증 상태 처리하기(전형적인 “각 테스트마다 로그인해야 하는” 고충).

무대를 잡는 데 시간을 다 쏟아부으면, 무엇을 테스트하려고 했는지 잊어버리게 된다. “빠르게 녹화하고 바로 실행” 옵션은 없고, 대신 헤드리스 브라우저용 인프라 코드를 작성해야 한다. 마치 실제 앱을 점검하기 위해 **“그림자 앱”**을 만드는 듯한 느낌이며, 엄청난 시간 낭비가 된다.

2️⃣ 개발자들은 무엇을 테스트해야 할지 모른다

백엔드에서 작업한다면 테스트는 보통 직관적입니다: 입력을 보내고, DB나 API 응답을 확인합니다. 이 과정은 이진적이고 깔끔합니다.

프론트엔드에서는 상황이 엉망입니다. 기능을 마치고 테스트를 작성하려고 앉으면, 수많은 질문이 떠오릅니다:

버튼이 파란색인지 테스트해야 할까?
로딩 스피너가 정확히 200 ms 동안 나타나는지 테스트해야 할까?
React 컴포넌트의 내부 상태를 테스트해야 할까, 아니면 사용자가 보는 것만 테스트해야 할까?
API가 실패하면 어떻게 될까? 모든 오류 토스트에 대해 테스트가 필요할까?

이로 인해 분석 마비가 발생합니다. 무엇이 중요한지에 대한 명확한 “청사진”이 없으면 우리는 다음 중 하나를 선택하게 됩니다:

모든 것을 테스트하려고 시도 – 유지보수 악몽을 초래하고,
아무것도 테스트하지 않음 – 압도당했기 때문에.

복잡한 UI와 씨름하며 몇 시간을 보낸 뒤, 마지막으로 원하는 것은 또 다른 세 시간을 들여 어떤 DOM 요소가 “충분히 중요”한지 추측하는 것이 아닙니다. 마치 어둠 속에서 다트를 던지는 느낌입니다.

3️⃣ Front‑end moves faster than back‑end

프론트‑엔드 코드는 끊임없이 변경됩니다: 버튼이 움직이고, 레이아웃이 조정되며, CSS 클래스가 이름이 바뀝니다. 2분 정도 걸리는 “작은” UI 변경 하나가 전체 테스트 스위트를 깨뜨릴 수 있습니다.

결국 기능을 배포하는 것보다 셀렉터를 업데이트하고 “깨진” 테스트를 고치는 데 더 많은 시간을 소비하게 됩니다. 결국 유지보수 부담이 너무 커져서 많은 팀이 개발 속도를 따라잡기 위해 테스트 작성을 중단하기도 합니다.

왜 E2E 테스트가 중요한가

E2E testing importance

프론트‑엔드에서는 E2E 테스트가 유닛 테스트보다 더 중요합니다. 버튼 컴포넌트에 100 % 커버리지를 달았다 하더라도 다음과 같은 상황을 알려주지는 못합니다:

API 로드에 실패했을 때.
투명한 div가 실수로 화면 전체를 가리고 있을 때.

결국 우리가 신경 쓰는 것은 단 한 가지, 사용자 경험이 깨졌는가? 입니다. E2E 테스트는 실제 사람을 실제 디바이스에 두고 시뮬레이션하여 “해피 패스”(예: 로그인, “지금 구매” 클릭)가 처음부터 끝까지 정상적으로 동작하는지 확인합니다. 이것은 금요일 오후에 “배포” 버튼을 눌러도 프로덕션 장애를 두려워하지 않고 집에 갈 수 있게 해 주는 안전망입니다.

현대 E2E 테스트의 문제점

도구인 Cypress와 Playwright가 모든 문제를 해결했다고 생각할 수도 있습니다. 확실히 경험을 개선했지만, 근본적인 고통 포인트는 여전히 남아 있습니다:

Flakiness – 테스트가 CI에서는 실패하고, 재실행에서는 코드 변경 없이 통과합니다. 이는 신뢰를 떨어뜨립니다: 코드가 깨졌나요, 아니면 API가 50 ms만큼 느려졌나요?
“Shadow App” Maintenance – 최신 도구를 사용하더라도 여전히 많은 스캐폴딩(환경 설정, 목업, 인증 처리)을 작성하게 되며, 이는 실제 앱과 동기화해야 하는 별도의 앱처럼 느껴집니다.

의미 있는 테스트를 더 빠르게 작성하는 방법

아래는 보일러플레이트를 줄이고 진정으로 중요한 부분에 집중할 수 있는 가벼운 접근 방식입니다:

선언형 테스트 러너 사용 (예: 내장 픽스처가 있는 Playwright Test).
자동 생성 선택자 활용 (data-test-id 속성)으로 깨지기 쉬운 CSS 선택자를 피합니다.
사용자 흐름을 한 번 기록‑재생하고, 러너가 테스트 골격을 생성하도록 합니다.
필요한 것만 모킹 – 전체 모킹 서버를 구축하는 대신, 테스트별로 네트워크 가로채기를 사용해 외부 API를 스텁합니다.
테스트를 작고 집중되게 유지 – 사용자 스토리당 하나의 테스트 (예: “로그인 → 장바구니에 추가 → 결제”).

이 패턴을 사용하면 특징당 5분 미만에 신뢰할 수 있는 E2E 테스트를 만들 수 있으며, 전체 “Shadow App”을 구축하는 부담이 없습니다.

TL;DR

프론트엔드 테스트는 느리고, 혼란스럽고, 깨지기 쉽습니다.
진정한 가치는 사용자 여정을 검증하는 E2E 테스트에 있습니다.
최신 도구가 도움이 되지만, 보일러플레이트와 플라키성을 최소화하는 전략이 여전히 필요합니다.

선언형·기록‑우선 접근 방식을 시도해 보세요 – 테스트 작성이 다시 즐거워질 수도 있습니다. 🚀

Modern E2E 도구의 문제점

오늘날 최고의 프레임워크조차도 빠르게 움직여야 하는 프론트엔드 개발자를 위한 것이 아니라 자동화 테스트 담당자를 위해 만들어진 듯한 느낌입니다. 이들은 테스트 방법에 초점을 맞추지만, 테스트를 유지하는 어려움은 도와주지 않습니다.

흔히 겪는 고통 포인트

구현 세부 사항에 얽힘 – 클래스를 이름 바꾸거나 data-testid를 변경하면 테스트 파일을 뒤져서 수정해야 합니다. 사실상 두 개의 앱을 동시에 유지보수하는 셈입니다.
가파른 학습 곡선 – 이러한 “모던” 도구를 제대로 사용하려면 async/await 패턴, 복잡한 로케이터, 그리고 헤드리스‑브라우저 컨텍스트 처리 방법을 배워야 합니다. UI가 깨지지 않도록 하고 싶은 프론트엔드 개발자에게는 너무 많은 요구사항이죠.

요약하면, 현재 E2E 테스트 상황은 번거롭고 깨지기 쉬운 느낌입니다.

Project: Symphony on GitHub

Symphony 소개

오랜 기간 동안 불안정한 셀렉터와 씨름하고 실제 코드베이스보다 Cypress 문서에 더 많은 시간을 보낸 끝에, 나는 더 나은 무언가를 만들기로 결심했다.

Symphony는 E2E 테스트를 프론트엔드 워크플로우의 자연스러운 일부처럼 느끼게 해 주는 도구다. 복잡하고 명령형인 코드를 작성해 버튼을 클릭하고 로더를 기다리는 대신, Symphony는 실제로 의미가 있는 방식으로 사용자 흐름을 정의하게 해준다. 이는 YAML‑based DSL를 사용한다—즉 테스트 단계를 평범하고 사람이 읽을 수 있는 영어로 기술한다는 의미다.

Symphony가 게임 체인저인 이유

Zero Boilerplate – 브라우저 컨텍스트를 설정하거나 거대한 beforeEach 블록을 만들 필요가 없다. 흐름을 정의하고 바로 실행한다.
Built for Speed – 기능을 구현하는 데 2분이 걸린다면, 테스트하는 데 20분이 걸려서는 안 된다.
Readable by Anyone – 테스트가 간단한 YAML 형식으로 작성되기 때문에, PM이나 디자이너도 테스트 파일을 열어 무엇을 검증하고 있는지 정확히 이해할 수 있다.

Symphony는 유지 보수의 악몽 없이 E2E 테스트의 안전성을 원하는 “게으른” 개발자(가장 좋은 유형의 개발자)를 위해 만들어졌다.