테스트 코드가 막막한 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-09-19

멘토링을 하면서 가장 많이 듣는 하소연 중 하나가 있습니다.

"테스트 코드를 짜야 한다는 건 아는데, 어디서부터 손대야 할지 막막합니다."

2년 차 백엔드 개발자 한 분은 회사 프로젝트에 테스트가 단 하나도 없어서 혼자 도입해보려다 일주일 만에 포기했다고 털어놨습니다. 강의나 책에서는 쉽다고 하는데, 막상 내 코드에 적용하려고 하면 시작조차 안 된다는 겁니다.

왜 그럴까요? 테스트 코드가 어려운 게 아닙니다. 테스트 코드에 대한 접근 방식이 잘못되었기 때문입니다.

모든 것을 검증하려는 강박

처음 테스트 코드를 작성하는 사람들의 90%는 같은 함정에 빠집니다. 컨트롤러부터 서비스, 리포지토리까지 완벽하게 감싸야 한다는 강박입니다.

어설프게 목(Mock) 객체를 열 개씩 엮다 보면, 내가 비즈니스 로직을 검증하는 건지 프레임워크 문법을 테스트하는 건지 헷갈리기 시작합니다. 결국 비즈니스 로직 하나 바꾸면 목 설정 스무 줄이 깨집니다. 테스트가 안전장치가 아니라 짐이 되는 순간입니다.

200명이 넘는 멘티들에게 저는 늘 같은 말을 합니다. 처음부터 전체를 검증하려 들지 마세요. 깨지기 쉬운 가장 복잡한 계산식, 딱 한 군데부터 시작하면 됩니다.

성공 케이스만 작성하는 습관

멘토링에서 코드 리뷰를 할 때 과제로 제출된 테스트 코드를 열어봅니다. 열 개 중 여덟 개는 정답 데이터만 넣고 검증을 끝냅니다.

주문 금액이 5만 원일 때 할인이 잘 들어가는지, 회원이 정상 로그인되는지만 확인합니다. 하지만 실서버에서 터지는 버그는 그런 얌전한 상황에서 나오지 않습니다. 재고가 0개일 때, 결제 승인 응답이 10초 동안 지연될 때, 사용자가 중복 클릭을 했을 때 시스템이 무너집니다.

테스트 코드는 내 코드가 정상 동작함을 증명하는 자랑용 문서가 아닙니다. 어디까지 버틸 수 있는지 한계를 시험하는 망치여야 합니다. 예외가 터져야 할 지점에 의도한 예외가 터지는지 확인하는 테스트 한 줄이, 의미 없는 성공 테스트 열 개보다 훨씬 값집니다.

도구가 아니라 경계를 먼저 보세요

프레임워크나 최신 라이브러리 사용법을 외운다고 테스트 코드가 잘 써지지 않습니다. 테스트 코드를 못 짜는 진짜 이유는 대부분 설계에 있습니다.

메서드 하나가 DB 조회, 외부 결제사 호출, 비즈니스 계산, 알림 전송까지 다섯 가지 일을 한 번에 하고 있다면 그 어떤 천재 개발자도 테스트를 못 짭니다. 테스트하기 어려운 코드는 대개 잘못 설계된 코드입니다.

외부 의존성이 있는 네트워크 호출과 순수하게 값만 계산하는 도메인 로직을 분리해 보세요. 경계가 나뉘면 테스트 코드는 거짓말처럼 술술 써집니다. 테스트 코드를 짠다는 행위는 결국 내 코드가 얼마나 단단하게 나뉘어 있는지 점검하는 사유의 과정입니다.

커버리지 100%라는 숫자에 매달릴 이유가 없습니다. 당장 내일 출근해서 내가 작성한 가장 불안한 조건문 하나에 테스트 한 줄을 걸어보세요. 퇴근길 발걸음의 무게가 달라질 겁니다.