네이버 D2 「테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴)」 리뷰 — 목이 많아지는 것은 테스트의 문제가 아니라 설계의 신호

원문: 테스트는 어떻게 좋은 코드를 만드는가(feat. 험블 객체 패턴) — NAVER D2, 서동유, 2025-03-19

한 줄 요약

테스트가 괴로워지는 이유는 대개 “테스트하기 어려운 코드(전역 객체, 네트워크, 저장소)”를 설계로 격리하지 않고 강력한 목(mock)으로 덮어 버리기 때문이다. 목에는 비용 등급이 있고, 비싼 목(네트워크·글로벌 목)이 많다는 것 자체가 코드 스멜이다. 험블 객체 패턴은 테스트하기 어려운 부분을 작은 객체로 떼어내 인터페이스 뒤에 두는 것이고, 그렇게 하면 나머지 코드는 더미와 스텁만으로 테스트되며 SOLID 원칙의 대부분을 자연스럽게 따르게 된다.

배경: 테스트가 왜 점점 괴로워지나

백지에서 TDD를 시작하면 처음엔 잘 된다. 그러다 window.localStorage를 써야 하는 순간이 온다. Jest 문서를 뒤져 글로벌 객체를 모킹하는 법을 익히고, 그 기술로 도처의 전역 객체를 모킹하며 테스트를 밀어붙인다. 며칠 뒤, 테스트 한 줄마다 그보다 긴 목 초기화 구문을 쓰고 있고, 데이터 하나 바꾸려고 10계층 떨어진 JSON 파일을 고치고 있다.

원문의 진단은 “충분히 생각하지 않았다”이다. 좋은 테스트가 무엇인지, 좋은 설계가 무엇인지 청사진 없이 리팩터링을 “코드를 짧고 예쁘게”로만 이해했다는 것이다. 그리고 그 문제가 가장 먼저 드러나는 곳이 목 객체다.

핵심 아이디어 1: 목에는 등급이 있다

원문은 목을 피라미드 네 단계로 나눈다. 위로 갈수록 작성 시간이 오래 걸리고, 초기화 비용이 크고, 바뀐 상태를 추적하기 어렵다.

단계	무엇	비용
Network mock	목 서버·테스트 DB. 데이터 바꾸려면 테스트 밖 코드를 고쳐야 함	가장 높음
Global mock	window·document·싱글턴·jest.mock()으로 클래스 정의 덮어쓰기. 전후 초기화·복원 필요	높음
Object spying	jest.spy()로 메서드 감싸기. 호출 여부·인자 확인	중간
Dummy, Stub	테스트마다 선언하는 가짜 객체·데이터. 독립적이라 복원 불필요	가장 낮음

“코드에 jest.mock, beforeEach, afterAll, expect.toHaveBeen~이 얼마나 많은가? 단언컨대 적을수록 좋다.” E2E·통합 테스트에서는 고수준 목이 필수지만, 훨씬 많이 써야 하는 유닛 테스트에서 반복되면 피로와 기술 부채가 된다.

왜 사람들은 고수준 목을 고르는가. 비싼 목일수록 프로그램 코드를 안 고쳐도 되기 때문이다. 설계를 고치는 대신 목으로 덮는 선택은 그 순간엔 편하지만, 깨지기 쉬운 테스트를 낳고, 테스트가 깨지기 쉬우니 설계 변경이 더 어려워지고, 그래서 다시 고수준 목을 쓰는 악순환이 된다. 그래서 원문은 “고수준 목은 그 자체로 코드 스멜”이라고 한다.

핵심 아이디어 2: 험블 객체 패턴, 세 단계로 내려가기

정의는 “테스트하기 어려운 행위와 쉬운 행위를 분리하기 쉽게 하는 패턴”이지만, 원문은 이것을 예시로 세 단계에 걸쳐 보여 준다. localStorage에 값을 저장하는 MyClass가 출발점이다.

1단계: 그냥 클래스로 분리. localStorage 호출부를 StorageRepo 클래스로 뗀다. 그런데 MyClass 안에서 new StorageRepo()를 하면 테스트에서는 jest.mock으로 모듈을 통째로 바꿔야 한다. 여전히 글로벌 목 단계다. localStorage 자리를 StorageRepo가 대신했을 뿐이다. 원문의 표현으로, 두 클래스가 생성과 제거의 생애주기를 공유하는 한 운명 공동체이고 사실상 한 클래스다. 감춰진 것이지 격리된 것이 아니다.

2단계: 주입. StorageRepo를 생성자 인자로 받는다. 이제 테스트에서 인스턴스를 밖에서 만들어 넘기고 그 메서드를 스파잉하면 된다. jest.mock이 사라졌다. 한 단계 내려왔지만, 스파이로 호출 여부를 확인하는 테스트는 비효율적이고 다양한 케이스에 대응하기 어렵다.

3단계: 인터페이스. Repository 인터페이스를 선언하고 StorageRepo가 이를 구현한다. MyClass는 인터페이스를 받는다. TypeScript는 구조적 타이핑이라 implements 없이 객체 리터럴만으로 더미를 만들 수 있다. 이제 테스트는 더미 객체 하나로 끝나고, 스파이도 없다. 가장 중요한 점은 테스트가 MyClass 외의 어떤 구현에도 의존하지 않게 됐다는 것이다. 이 테스트는 오직 MyClass의 변경에만 반응한다. 저장소가 localStorage든 IndexedDB든 MyClass의 관심사가 아니다.

떼어낸 험블 객체(StorageRepo)는 여전히 전역 객체를 쓴다. 이것은 어떻게 테스트하나? 고수준 목이나 통합 테스트로 한다. 다만 테스트하기 어려운 코드가 소수의 객체에 모였으므로, 모든 코드를 고수준 목으로 테스트하는 것보다 훨씬 경제적이다. 이것이 “험블(겸손한)” 객체다. 로직은 최대한 비우고 어려운 일만 맡는다.

원문은 전역 객체의 모든 메서드에 인터페이스를 다시 선언하라는 뜻이 아니라고 못 박는다. 핵심은 테스트하기 힘든 코드를 분리하는 것이고, 그 코드가 복잡할수록, 여러 곳에서 쓰일수록 효과가 크다. JSON 직렬화만 추가돼도 테스트 난이도가 세 배가 된다는 예가 붙어 있다.

핵심 아이디어 3: Testable ≈ SOLID

험블 객체 패턴을 적용하면 SOLID 원칙의 상당 부분을 자연히 지키게 된다는 것이 후반부다.

• 단일 책임: “한 함수는 한 가지 일”이 아니라 “한 모듈은 변경 이유가 하나”다. 두 줄짜리 저장 코드에도 데이터 정제(기획자가 바꾸고 싶어 함)와 입출력(개발자가 결정)이라는 두 관심사가 있다. 책임을 생각할 때 “이 코드가 바뀐다면 누가 바꾸길 원하는가”를 물으라는 조언이 실용적이다. 외부 의존성 호출은 대체로 비즈니스 로직과 다른 관심사라서 험블 객체로 떼면 자연히 나뉜다.
• 개방 폐쇄: 인터페이스가 있으면 MyClass를 안 고치고 IndexedDB·fetch 저장소를 추가할 수 있다. “테스트하기 쉽게 고쳤을 뿐인데 보너스를 받은 기분”이라는 표현이 이 원칙의 체감이다.
• 리스코프 치환: 자동으로 충족되진 않지만, 더미 객체를 최대한 단순하게, 최소한의 메서드만 구현하게 관리하면 지키는 데 도움이 된다.
• 인터페이스 분리: 떼어낸 험블 객체를 다른 클래스(MotherClass)에서 재사용하고 싶어 기존 Repository에 메서드를 추가하면, 그 인터페이스로 만든 모든 더미가 깨진다. 별도의 MotherRepository를 선언하고 StorageRepo가 둘을 함께 구현하게 하라는 것이다.
• 의존관계 역전: MyClass와 StorageRepo의 의존이 모두 Repository 인터페이스를 향하게 됐다. 제어 흐름(MyClass → StorageRepo)과 의존 방향이 반대다. 험블 객체 패턴은 곧 의존관계 역전을 적용하는 패턴이라고 정리한다.

마무리는 클린 아키텍처의 인용이다. 행위를 테스트하기 쉬운 부분과 어려운 부분으로 나누면 아키텍처 경계가 정의된다. 그리고 “오버 엔지니어링을 피한다는 이유로 개선을 미루는 행위에는 이자가 붙는다.”

읽고 남는 질문

• 예시는 저장소 하나다. 실제 프런트엔드 컴포넌트는 라우터·전역 상태·API 클라이언트·타이머를 동시에 쓰는데, 그것을 전부 인터페이스로 주입하면 생성자가 비대해진다. 어디까지 험블 객체로 떼고 어디서 멈추는지에 대한 기준이 있으면 좋겠다.
• 험블 객체 자체의 테스트(통합·E2E)를 얼마나 촘촘히 해야 하는지가 없다. “로직을 최대한 비운다”가 전제인데, 실무에서는 험블 객체에 로직이 스며드는 것을 막는 규칙이 필요하다.
• 목 피라미드는 저자의 분류로 보인다. 표준 용어(Meszaros의 dummy/stub/spy/mock/fake)와 어떻게 대응되는지 한 줄 있었으면 혼동이 덜했을 것이다.

한 줄로 가져가기

목이 무거워지면 목을 더 잘 쓰는 법을 찾지 말고, 그 목이 덮고 있는 코드를 작은 객체로 떼어 인터페이스 뒤로 보내라. 그러면 테스트는 더미로 끝나고 설계는 SOLID에 가까워진다.