TL;DR

  • AI 코딩 에이전트 시대에도 Unit Tests의 핵심 가치인 저렴하고 빠른 피드백 루프가 유지되므로, 이를 폐기할 근거는 아직 부족함.
  • E2E·통합 테스트는 사용자 경험에 가까운 동작을 검증하지만, 같은 검증을 Unit Tests만큼 저렴하게 수행하지는 못함.
  • Unit Tests의 가치는 버그 탐지뿐 아니라 실행 가능한 명세·문서·설계 피드백·변경을 위한 기반에도 있음.
  • Unit Testing에 대한 반감의 상당 부분은 테스트 자체보다 구현에 지나치게 밀착되고 모킹이 과도한 방식에서 비롯됨.
  • AI는 코드 생산의 경제성을 바꿨지만, Unit Tests를 가치 있게 만든 소프트웨어 개발의 요소까지 바꿨다고 보기는 어려움.

AI 코딩 에이전트 시대의 테스트 논쟁

  • 코딩 에이전트 시대에 필요한 테스트는 우선순위에 따라 전체 E2E 테스트, 통합 테스트라는 주장이 제기됨. E2E 테스트는 Playwright 같은 도구로 모킹 없이 수행하거나 테스트 계정을 사용해 프로덕션에서 실행할 수도 있다는 의견임.
  • 이 주장을 접한 뒤 금기와 Unit Tests에 대해 세 시간 동안 생각하게 됨.
  • 금기는 강한 감정 반응을 일으키며, 소셜 미디어에서는 이른바 ‘분노 유발(rage bait)’로 널리 퍼질 가능성도 있음.
  • Paul Graham의 에세이 [What You Can’t Say](What You Can’t Say)는 이런 감정을 설명하는 문장을 담고 있음.

사람들을 화나게 하는 발언은 사람들이 믿어질까 걱정하는 발언임.

  • 어떤 생각이 유난히 강하고 불균형해 보이는 감정 반응을 일으킨다면, 그 이유를 물어볼 만함. “Unit Tests는 죽었다”는 주장도 그런 사례임.
  • Unit Tests가 늘 존재해 온 소프트웨어 엔지니어링 관행을 공격하는 것처럼 느껴지지만, 오늘날 말하는 현대적 자동 Unit Testing 없이 만들어진 소프트웨어가 대부분임.
  • 이 관행은 Kent Beck과 Erich Gamma 등이 대중화한 xUnit 계열 프레임워크와 함께 1990년대 후반에 주류가 됐으며, Google도 이를 체계적으로 채택하기 시작한 시점은 2005~2006년 무렵임.

오래된 반론

  • Unit Tests에 대한 반론은 AI 이전에도 여러 차례 논의된 주장임.

Unit Tests는 품질 보증(QA) 연극임. 통합 테스트, E2E 테스트, 행동 테스트가 사용자가 실제로 경험하는 방식에 더 가까운 품질 보증을 제공하므로 Unit Tests는 대체됐으며 제거해야 함.

  • 이 주장은 AI 유무와 관계없이 독성이 강한데, 어느 정도 사실이기 때문임.
  • 통합 테스트나 E2E 테스트로 동일한 동작을 다수 검증할 수 있지만, Unit Tests만큼 저렴하게 수행할 수는 없음.
  • 이 논리를 끝까지 밀어붙이면 더 비싸고 불안정한 Unit Tests를 처음부터 다시 발명하는 셈임.
  • Unit Tests의 진짜 가치는 버그를 잡는 데만 있지 않음. 코드가 바뀌어도 가정이 여전히 성립하는지 확인하는 저렴하고 빠르며 국소적인 피드백 루프를 만들고, 그 가정에 대한 확신을 제공하는 데 가장 큰 이점이 있음.
  • Unit Testing과 테스트 주도 개발(TDD)은 이 때문에 오랫동안 다소 오해받아 왔음.
  • 첫째, QA 측면에 지나치게 집중해 다른 역할을 간과하는 경향이 있음. Unit Tests는 다음 역할도 수행함.
  • 실행 가능한 명세
  • 문서
  • 설계 피드백
  • 변경을 위한 기반
  • 둘째, Unit Tests를 주로 런던 학파(London School)의 관점에서 바라보는 경향이 있음. 실제로 사람들이 Unit Testing에서 싫어하는 요소 상당수는 구현에 밀착되고 모킹이 과도한 테스트 방식임.
  • 제대로 된 Unit Testing에서는 아키텍처 경계를 제외하면 모킹을 많이 사용하지 않아야 함.
  • Unit Testing의 런던 학파와 디트로이트 학파(Detroit School) 사이의 철학적 차이는 Martin Fowler의 글 [Mocks Aren’t Stubs](Mocks Aren’t Stubs)에서 더 살펴볼 수 있음.

AI가 Unit Tests의 전제를 바꿨는가

  • AI가 소프트웨어 작성 방식을 근본적으로 바꿔 Unit Tests의 전제를 무너뜨리고 쓸모없게 만들었는지가 핵심 질문임.
  • AI가 코드 생산의 경제성을 완전히 바꿨다는 점은 분명하지만, Unit Tests를 가치 있게 만든 소프트웨어 개발의 요소까지 바꿨다고 보기는 어려움.
  • 반대 방향을 주장하는 의견도 있음. Nate Berkopec은 @thorstenball의 의견에 동의하며, 모델이 작성하는 Unit Tests는 형편없고 최선의 경우에도 전체 코드 줄 수만 두 배로 늘린다고 밝힘.
  • Nate Berkopec은 E2E·블랙박스·골든 마스터 테스트를 중심에 두고 필요한 경우에만 낮은 수준의 테스트를 추가하는 역전된 접근 방식이 더 잘 맞는다고 밝힘.
  • 첫 번째 원칙에서 생각하고, 바퀴를 다시 발명하며, 오래된 가정에 도전하는 태도가 혁신을 이끈다고 믿으며 이를 계속해야 함.
  • 언젠가 모든 프로젝트에서 find . -name '*.test.ts' | xargs rm을 실행할 수 있기를 바라지만, 적어도 지금은 그때가 아님.
  • https://pbs.substack.com/profile_images/1905366180376006656/kYntWlPf_normal.jpg