프론트엔드에서 테스트 코드를 꼭 짜야할까요?

최근 우테코 코치이신 제이슨과 커피챗을 했습니다.(이라고 하고 브런치 카페를 가긴했지만) 커피챗을 하면서 제가 이런 질문을 드렸습니다. “왜 우테코에서는 테스트를 짜라하고, 자꾸 TDD를 하라고 강요하는거에요?” 라는 질문을요.

제이슨이 해주신 대답은 마치 머리를 한 대 맞은 것처럼 인상 깊었습니다.

"테스트를 짜는 이유는 그 기술을 익히라는게 아니라 문제를 잘게 쪼개고 피드백을 자주 받는 환경을 만들라는 것입니다. 또 TDD는 철학이고 문화에요. 단순히 테스트를 먼저 짠다고 해서 TDD가 되는건 아니에요.”

이 대답을 듣고, 지금껏 테스트를 기술로만 접근하고 있었던 제 관점이 완전히 뒤집혔습니다. TDD는 단순한 개발 방식이 아니라, 문제 해결 방식 자체를 바꾸는 철학이라는 걸 처음으로 체감할 수 있었습니다.

그렇다면 제이슨이 말한 “테스트는 기술이 아닌 철학”이라는 말은 구체적으로 어떤 의미일까요? 그리고 우리는 왜 테스트를 해야 할까요?

이번 글에서는 그 질문에 대해, 제가 지금까지 경험하고 느낀 바를 정리해보려 합니다.

테스트를 왜 해야 할까요?

제가 생각하는 테스트코드의 장점은 다음과 같아요.

안전한 리팩토링의 든든한 파트너

리팩토링 관점에서 테스트 코드는 내가 수정한 코드가 어디까지 영향을 미치는지 즉시 알려줍니다. 테스트 코드가 없다면 이를 확인하기 위해 사람이 직접 모든 기능을 검증해야 하죠. 잘 짜여진 테스트 코드 하나면 이런 반복적이고 지루한 작업을 대신해줍니다.
실제로 『리팩토링 2판』에서도 “한 단계를 변경할 때마다 테스트를 실행하라”고 강조하는 이유가 바로 여기에 있습니다. 잘 작성된 테스트는 리팩토링의 속도와 자신감을 동시에 높여주는 든든한 파트너라는 생각이 들었습니다. (실제로 켄트백과 마틴 파울러처럼요..)

팀의 우선순위를 보여주는 도구

테스트 코드는 일종의 개발자의 시선을 담고 있습니다. 모든 기능을 빠짐없이 테스트하는 경우는 드물고, 보통 개발자가 중요하다고 판단한 부분에 더 집중해 작성되기 마련이죠. 따라서 어떤 부분이 테스트되고 있는지를 보면 이 프로젝트에서 무엇을 중요하게 생각하는지가 드러납니다.
예를 들어 새로운 팀원이 프로젝트에 합류했을 때, 테스트 코드를 먼저 보면 “이 기능이 중요한 핵심 로직이구나”를 자연스럽게 파악할 수 있습니다.
요즘 제가 자주 떠올리는 표현이 출제자의 의도인데요, 시험 문제에서도 출제자의 의도를 파악하면 더 정확하게 접근할 수 있듯, 테스트 코드 역시 “이 기능이 왜, 어떻게 보호되어야 하는가?”에 대한 개발자의 의도를 명확하게 보여준다고 생각합니다.
따라서 테스트 코드는 단순한 검증 도구가 아니라 팀의 우선순위와 판단 기준이 반영된 문서라는 생각이 들었습니다.

피드백 루프의 단축

제이슨의 말씀처럼, TDD의 핵심은 빠른 피드백입니다. 기능을 작성하고 몇 시간 후에야 오류를 발견하는 것이 아니라, 몇 분 내에 문제를 인식하고 바로 수정할 수 있다면, 개발의 속도와 품질 모두를 끌어올릴 수 있다고 생각합니다.
따라서 테스트는 단순히 버그를 찾기 위한 수단이 아니라, 더 나은 설계를 이끄는 가이드라고 생각합니다.

그럼 TDD는 언제 필요할까요?

저도 똑같은 고민을 했었는데요. 제이슨이 해주신, 그리고 저의 리뷰어였던 해먼드가 해주셨던 말을 통해 TDD는 하나의 기술 스택이 아니라 문화고 철학이라는 것을 깨닫게 되었습니다.
TDD를 잘하려면 결국 우리에게 뚜렷한 목표가 있어야 하고, 우리는 그 목표를 향해 달려가며 작은 단위로 문제를 해결하고, 그 목표를 향해 달려가던 중 지금 상황에 맞는 더 나은 목표로 전환할 수 있는 유연함이 필요합니다.
사실 따지고 보면 우리는 이미 현실 세계에서 TDD의 철학을 실천하고 있는 셈입니다. 문제를 잘게 쪼개고, 피드백을 자주 받으며 점진적으로 개선해 나가는 이 방식은 TDD가 말하는 핵심 가치와도 일치하기 때문입니다.

그래서 테스트가 필수.. 일까요?

제 생각에는 모든 상황에서 테스트가 필수는 아니라고 생각합니다. 테스트를 공부하기까지 또 이를 익히기 까지는 러닝커브가 존재하고, 테스트를 작성하느라 드는 시간에 프로덕트 개선이나 사용자 피드백을 반영하는 것이 더 의미 있는 시점도 있기 때문입니다.

특히 초기 개발 단계에서는 요구사항이 계속 변하고, 설계도 자주 바뀌는데 이러한 상황에서 테스트 코드를 미리 작성하면 오히려 테스트코드가 발목을 잡는 상황이 있을 수 있을거라 생각합니다. 또 완벽한 테스트를 작성해야 한다는 부담감이 개발 속도를 늦출 수도 있고요.
하지만 프로젝트가 어느 정도 안정화되고, 핵심 비즈니스 로직이 명확해진다면 테스트 코드의 가치는 배로 커진다고 생각합니다. 유지보수와 리팩토링, 그리고 협업의 효율까지 모두 높여주니까요.

프론트엔드에서 하나만 테스트하라면?

단위, 통합, E2E 중 하나를 선택하라고 한다면 저는 통합 테스트를 고르겠습니다.

단위 테스트는 개별 함수나 컴포넌트 단위로 잘게 나눠 검증하는 장점이 있지만, 프론트엔드에서는 컴포넌트들이 서로 어떻게 상호작용하는지가 더 중요한 경우가 많다고 생각해요. E2E 테스트는 사용자 흐름을 검증할 수 있지만, 실행 시간이 오래 걸리고 유지가 어렵다는 단점이 있습니다.

통합 테스트는 이 둘의 중간 지점에서 실제 사용자 시나리오와 가까우면서도 빠른 피드백을 받을 수 있다는 점에서 가장 현실적인 선택지라고 생각합니다.

마치며

단위와 통합의 경계선은 어디일까? msw도 어떻게보면 실제 api 연결 전 프론트에서 할 수 있는 테스트가 아닌가? 그렇다면 나는 테스트라는 것을 어디까지로 정의 내릴 것인가? 등등..의 생각들이 끊임없이 이어지지만 이에 대한 답들은 천천히 하나씩 풀어가보도록 하겠습니다.