2nd/10_Wiki/Topics/Architecture/Automated Testing (자동화된 테스트).md

# [[Automated Testing (자동화된 테스트)]]

## 📌 Brief Summary
자동화된 테스트는 소프트웨어 도구를 사용하여 사전 정의된 테스트를 실행하고, 사람의 개입 없이 예상 결과와 실제 결과를 비교하는 프로세스이다 [1]. 소프트웨어 리팩토링의 맥락에서 자동화된 테스트는 기존 코드의 외부 동작이 변경되지 않았음을 보장하는 필수적인 '안전망'이자 실행 가능한 명세서 역할을 수행한다 [2-5]. 개발자가 버그 도입의 두려움 없이 안전하게 코드의 구조를 개선할 수 있도록 매우 빠른 피드백 루프를 제공하며, 지속적 배포(CI/CD)와 애자일 개발을 가능하게 하는 핵심 기반이다 [6-8].

## 📖 Core Content

*   **리팩토링의 필수 전제 조건 (Prerequisite for Refactoring)**
    안전한 리팩토링을 수행하기 위한 가장 기본적인 조건은 견고하고 자가 검사(Self-testing)가 가능한 자동화된 테스트 스위트를 구축하는 것이다 [9, 10]. "테스트가 없는 코드는 레거시 코드"라는 정의가 있을 정도로, 테스트의 부재는 안전한 코드 변경을 불가능하게 만든다 [11, 12]. 자동화된 테스트는 코드 변경에 따른 회귀 버그(Regression bugs)를 감지하는 강력한 결함 탐지기 역할을 한다 [5, 13]. 
*   **테스트 피라미드 (The Test Automation Pyramid)**
    효율적이고 유지보수 가능한 테스트 스위트를 구축하기 위한 구조적 모델이다 [14].
    *   **단위 테스트 (Unit Tests):** 피라미드의 가장 하단에 위치하며 전체 테스트의 대부분(약 70%)을 차지해야 한다. 개별 컴포넌트나 함수를 격리하여 테스트하며 밀리초 단위로 실행된다 [15, 16]. 
    *   **통합 테스트 (Integration Tests):** 중간 계층으로, 컴포넌트 간의 상호작용(API 통신, 데이터베이스 연동 등)이 올바르게 이루어지는지 검증한다 [17, 18].
    *   **엔드 투 엔드 테스트 (End-to-End Tests):** 피라미드 최상단으로 실제 사용자의 여정을 시뮬레이션한다. 가장 느리고 유지보수 비용이 비싸므로 전체 테스트의 소수(약 10%)로 유지해야 한다 [19].
*   **레거시 코드와 특성화 테스트 (Legacy Code & Characterization Tests)**
    의존성이 강하게 얽혀 있고 테스트가 없는 레거시 시스템을 리팩토링할 때는 '특성화 테스트'를 활용한다 [20]. 이는 코드가 '무엇을 해야 하는지'가 아니라 현재 '실제로 어떻게 동작하는지'의 스냅샷을 찍어 기존 동작이 변하지 않도록 보장하는 기법이다 [20, 21]. 
*   **테스트 격리를 위한 모조 객체 및 접점 활용 (Mocks, Stubs & Seams)**
    단위 테스트의 속도와 독립성을 확보하기 위해 데이터베이스나 네트워크 등 외부 의존성을 스텁(Stub)이나 모의 객체(Mock) 같은 테스트 대역(Test Doubles)으로 대체한다 [22, 23]. 레거시 코드에 이를 주입하기 위해 소스 코드를 편집하지 않고도 프로그램의 동작을 변경할 수 있는 '접점(Seam)'을 찾아 분리한다 [24-26].
*   **Red-Green-Refactor 사이클 (TDD)**
    자동화된 테스트는 테스트 주도 개발(TDD) 주기와 긴밀하게 결합된다. 실패하는 테스트를 먼저 작성(Red)하고, 이를 통과시키는 최소한의 코드를 작성(Green)한 뒤, 중복을 제거하고 구조를 개선(Refactor)하는 반복적인 과정을 거친다 [27-30].

## ⚖️ Trade-offs & Caveats

*   **역전된 테스트 피라미드 안티패턴 (The Inverted Test Pyramid Anti-Pattern):** 하향식으로 자동화 전략을 수립할 경우, 느리고 깨지기 쉬운(brittle) E2E 테스트 및 UI 테스트가 대부분을 차지하고 단위 테스트가 부족해지는 현상이 발생한다 [19, 31]. 이는 테스트 실행 시간을 몇 시간씩 지연시켜 지속적 통합(CI)의 이점을 없애고, 테스트 실패의 원인을 파악하기 어렵게 만들어 팀이 테스트 결과를 무시하게 만든다 [19].
*   **테스트 스위트 비대화 및 유지보수 비용 (Test Suite Bloat & Maintenance):** 중복되거나 더 이상 가치가 없는 테스트들이 쌓이면 테스트 스위트의 실행이 느려지고 관리 부채(Liability)가 된다 [32]. 프로덕션 코드와 마찬가지로 테스트 코드 역시 일급 시민(First-class code)으로 취급하여 리뷰하고, 리팩토링할 시간을 지속적으로 할당해야 한다 [33].
*   **구현에 지나치게 결합된 테스트 (Tests Coupled to Implementation):** 단위 테스트가 클래스의 내부 구조나 프라이빗 메서드에 지나치게 밀착되어 있으면, 기능 변경이 없는 단순 구조 리팩토링 시에도 테스트가 깨져(Flaky) 방해물이 될 수 있다 [34]. 이를 피하려면 구현 세부 사항이 아닌 "관측 가능한 외부 동작(Public Interface)"에 대해 테스트해야 한다 [35, 36].
*   **초기 학습 곡선과 시간 투자 (Learning Curve and Time Constraints):** 테스트를 작성하는 것은 추가적인 코드를 작성해야 하므로 초기에는 오버헤드처럼 느껴지며 일정을 지연시킬 수 있다 [37, 38]. 모조 객체 프레임워크(Mocking frameworks) 적용이나 접점(Seam) 설계 등의 테스트 기술 격차가 있을 경우, 잘못 설계된 깨지기 쉬운 테스트가 생성될 위험이 있다 [31].

## 🔗 Knowledge Connections

### Related Concepts

#### [관계 유형 A (소프트웨어 설계 및 아키텍처 원칙)]
- [[Test-Driven Development (TDD)]]
  - 연결 이유: Red-Green-Refactor 사이클을 통해 테스트 작성을 리팩토링과 구현의 필수적인 선행 과정으로 만들기 때문이다 [27, 29].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리팩토링이 단순한 사후 코드 정리가 아니라, 설계와 테스트가 유기적으로 통합된 애자일 개발의 핵심 사이클임을 깊이 이해할 수 있다 [28, 39].
- [[Test Automation Pyramid]]
  - 연결 이유: 소프트웨어 시스템 내에서 자동화 테스트(단위, 통합, E2E)의 적절한 비율과 책임을 정의하는 구조적 프레임워크이기 때문이다 [14, 15].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 리팩토링 시 빠른 피드백을 제공하는 단위 테스트의 비중을 왜 늘려야 하는지, 그리고 테스트 유지보수 비용을 어떻게 최적화하는지 파악할 수 있다 [40, 41].

#### [관계 유형 B (레거시 코드 제어 및 테스트 기법)]
- [[Characterization Tests (특성화 테스트)]]
  - 연결 이유: 테스트가 없는 레거시 코드를 리팩토링하기 전에, 현재 시스템의 '실제 동작'을 캡처하여 회귀 버그를 방지하는 안전망 역할을 하기 때문이다 [20, 21].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 명세가 부족한 기존 코드의 리팩토링 과정에서 리스크를 통제하고 의존성을 끊어내는 전략적 접근법을 배울 수 있다 [42].
- [[Seams (접점)]]
  - 연결 이유: 레거시 코드의 얽힌 의존성을 끊고 테스트 대역(Test Doubles)을 주입하기 위해 소스 코드 수정 없이 프로그램의 동작을 변경할 수 있는 논리적 위치이기 때문이다 [24, 25].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: 테스트하기 어려운 모놀리식 코드를 객체 지향적(Object Seam) 혹은 전처리기 방식(Preprocessing Seam)으로 분리하여 단위 테스트의 영역 안으로 가져오는 방법을 이해할 수 있다 [43, 44].
- [[Mocking and Stubbing (테스트 대역)]]
  - 연결 이유: 데이터베이스나 외부 API 등의 느리고 부수 효과가 큰 의존성을 가짜 객체로 대체하여, 리팩토링의 대상이 되는 단위를 완벽히 격리하고 테스트 속도를 높이기 때문이다 [22, 23].
  - 이 개념을 통해 더 깊게 이해할 수 있는 부분: '고립된 단위 테스트(Solitary Unit Tests)'를 작성하는 방법과 함께, 리팩토링 시 외부 환경의 영향 없이 내부 로직의 변경만을 안전하게 검증하는 방법을 이해할 수 있다 [45].

### Deeper Research Questions

- 역전된 테스트 피라미드(Inverted Test Pyramid) 패턴에 빠진 대규모 레거시 시스템을 안정적이고 빠른 단위 테스트 중심의 구조로 점진적으로 마이그레이션하는 최적의 전략은 무엇인가?
- 코드 리팩토링 시 내부 구조 변경에 의해 쉽게 깨지는 '구현에 밀착된 테스트'를 방지하고, '관측 가능한 동작'만을 테스트하도록 보장하는 테스트 설계 원칙은 무엇인가?
- 객체 지향 언어에서 제공하는 Object Seams를 활용할 수 없는 절차적 레거시 C 코드베이스에서 Preprocessing Seam이나 Link Seam을 활용하여 테스트 덮개를 씌우는 구체적인 방법과 한계는 무엇인가?
- AI 코딩 보조 도구(LLM)를 사용하여 누락된 레거시 시스템의 특성화 테스트(Characterization Tests)를 자동 생성할 때 발생하는 환각(Hallucination) 리스크와 이를 검증하기 위한 인간 개발자의 개입 범위는 어디까지인가?
- 테스트 대역(Mock/Stub)을 과도하게 사용하여 시스템의 결합도를 숨기는 '모의 객체 남용'이 오히려 리팩토링의 품질을 저해하는 사례와 그 방지책은 무엇인가?

### Practical Application Contexts

- **Implementation:** 새로운 기능 구현 전에 테스트를 추가하여 보호 구문을 세우고, Red-Green-Refactor 워크플로우에 따라 코드를 작성하며 내부 구조를 점진적으로 개선할 때 사용된다 [29, 30].
- **System Design:** 소프트웨어 아키텍처 설계 시부터 의존성을 주입(Dependency Injection)하기 쉬운 구조로 모듈을 분리하여, 빠르고 신뢰성 있는 단위 테스트 환경을 보장한다 [24, 46].
- **Operation / Maintenance:** CI/CD 파이프라인 상에 자동화 테스트 스위트를 배치하여, 개발자가 리팩토링을 수행하여 커밋할 때마다 몇 분 안에 회귀 버그 유무를 즉각 피드백받게 함으로써 배포 신뢰성을 유지한다 [7, 8].
- **Learning Path:** JUnit 등 단위 테스트 프레임워크 기초 숙지 -> Mockito/Wiremock을 활용한 외부 의존성 분리 훈련 -> 테스트가 없는 레거시 코드에 Sprout/Wrap 기법으로 테스트 덮개를 씌우는 고급 기법 학습 [47-50].
- **My Project Relevance:** 현재 유지보수 중인 레거시 시스템에서 코드를 구조적으로 변경하거나 기술 부채를 해결하기 위해, 가장 먼저 특성화 테스트를 작성하여 리팩토링의 안전망을 구축하는 과정과 직결된다.

### Adjacent Topics

- [[Continuous Integration (지속적 통합)]]
  - 확장 방향: 자동화된 테스트가 실제 빌드 및 배포 파이프라인에 편입되어 리팩토링과 코드 병합의 리스크를 줄여주는 DevOps의 핵심 실천법으로 지식을 확장할 수 있다 [7, 8].
- [[Technical Debt (기술 부채)]]
  - 확장 방향: 자동화된 테스트가 부재하여 발생하는 시스템 유지보수 비용의 증가와 이를 점진적 리팩토링으로 상환하는 비즈니스 관점의 관리 전략으로 이해를 넓힐 수 있다 [51, 52].

---
*Last updated: 2026-05-03*