# [[Scaled Agile Framework (SAFe)]]

## 📌 Brief Summary
Scaled Agile Framework(SAFe) 환경에서의 자동화 테스트는 단순한 수동 테스트의 대체를 넘어, 여러 팀에 걸쳐 가치를 지속적으로 전달하기 위한 필수적인 내장 품질(Built-in Quality) 관행입니다 [1]. 단일 스크럼 팀의 규모를 뛰어넘어 5~12개의 애자일 팀으로 구성된 애자일 릴리스 트레인(ART, Agile Release Train) 전체의 작업을 조정해야 하므로, 모든 통합 지점에서의 오류 가능성에 대비하는 전략이 필요합니다 [2]. SAFe는 자동화 테스트를 테스트 주도 개발(TDD), 동료 리뷰(Peer Review), 코드 공동 소유권 등과 함께 품질을 보장하기 위한 핵심 기둥으로 간주합니다 [2].

## 📖 Core Content
*   **책임의 분산 및 시스템 팀의 역할**
    SAFe 환경에서 자동화 테스트에 대한 책임은 조직 전반에 분산됩니다. 개발자는 완료 조건(DoD)의 일부로 단위 테스트를 작성 및 유지 관리하고, 테스터는 통합 및 인수 테스트 자동화에 집중합니다 [3]. 시스템 팀은 테스트 환경, CI 파이프라인, 테스트 데이터 관리 등 인프라를 지원하여 테스트 자동화가 원활하게 이루어지도록 돕습니다 [3]. 특히 시스템 팀은 프로덕션 구성과 일치하는 안정적인 통합 테스트 환경을 제공함으로써 역 테스트 피라미드(Inverted Test Pyramid) 안티 패턴을 방지합니다 [4].
*   **ART(Agile Release Train) 규모의 CI 파이프라인**
    수십 명의 개발자가 동일한 코드베이스에 매일 코드를 푸시하는 상황에서 지속적 통합(CI)과 지속적 제공(CD)을 실현하게 해주는 기본 메커니즘이 바로 자동화 테스트입니다 [5]. 개별 팀이 자체 CI 프로세스를 유지하는 한편, 시스템 팀은 전체 ART를 관통하는 통합 인프라를 조정하여 팀 단위의 빌드들이 일관성 있는 전체로 연결되도록 합니다 [6].
*   **테스트 코드의 1급 시민 대우 (First-Class Code)**
    자동화된 테스트 코드는 프로덕션 코드와 동일한 품질 자산으로 취급되어야 합니다 [7]. 동료 리뷰를 거치고, 코딩 표준을 따르며, 취약해질 경우 리팩토링의 대상이 되어야 합니다 [7]. 완료 조건(DoD)에 자동화 테스트 관련 요구사항을 공식화하고, 내장 품질(Built-in Quality) 체크리스트를 활용해 ART 내 모든 팀의 테스트 기대치를 표준화합니다 [8].
*   **Shift-Left 테스트와 지속적인 피드백 루프**
    테스트 생성과 실행을 개발 주기 후반으로 미루지 않고 초기 단계로 당겨야 합니다 [9]. 개발 중에는 TDD를 활용하고, 공유 브랜치에 코드가 병합될 때마다 통합 테스트를 거치며, 정기적인 회귀 테스트를 통해 부작용을 포착합니다 [9]. SAFe의 '검사 및 적응(Inspect and Adapt)' 이벤트는 이러한 테스트 지표를 정기적으로 검토하고 개선 영역을 식별하는 훌륭한 계기를 제공합니다 [10].

## ⚖️ Trade-offs & Caveats
*   **역 테스트 피라미드 안티 패턴 (Inverted Test Pyramid)**
    단위 테스트나 통합 테스트 대신 GUI 및 E2E(End-to-End) 테스트에 지나치게 의존하면, 테스트 스위트가 느려지고 작은 변화에도 쉽게 깨져(brittle) 유지 보수 비용이 높아집니다 [11]. 이 경우 테스트를 작성하는 시간보다 고치는 데 더 많은 자원이 소모되는 역효과가 발생합니다 [11].
*   **공유 테스트 환경의 병목 현상**
    여러 팀이 동일한 테스트 환경을 동시에 사용하여 테스트를 실행하면 실패가 연쇄적으로 일어날 수 있으며, 어떤 코드 변경이 문제를 일으켰는지 판별하기 매우 어려워집니다(거짓 실패 발생) [11]. 이를 방지하기 위해서는 코드화된 인프라(Infrastructure as Code) 등을 통해 환경을 독립적으로 프로비저닝해야 합니다 [6].
*   **유지보수 예산의 부재 및 취약한 테스트(Flaky Tests)**
    자동화 테스트를 지속적인 관행이 아닌 일회성 프로젝트로 취급하면, 유지보수되지 않은 테스트 코드가 곧 부채로 전락합니다 [11]. 간헐적으로 통과와 실패를 반복하는 '취약한 테스트'를 방치하면 개발자들은 테스트 결과를 신뢰하지 않게 되며, 결국 자동화 이니셔티브 전체의 실패로 이어집니다 [11, 12]. 
*   **비현실적인 기대와 기술 격차**
    초기부터 수동 테스트 노력이 '0'으로 수렴할 것이라고 기대하는 것은 환상이며, 자동화는 수동 테스트를 대체하는 것이 아니라 사람의 노력을 보완하는 것임을 명심해야 합니다 [11]. 또한, 충분한 자동화 전문 지식이 없는 팀이 복잡한 프레임워크를 도입하려고 하면 개발이 오히려 정체될 수 있습니다 [11].

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