왜 아키텍처 테스트인가

컴파일러가 검증하지 못하는 것들

C# 컴파일러는 타입 안전성, 접근 제한자, 문법 오류를 잡아줍니다. 하지만 팀이 합의한 설계 규칙은 컴파일러의 영역 밖에 있습니다.

예를 들어, 다음과 같은 규칙을 생각해 보겠습니다:

• “도메인 엔티티는 반드시 sealed 클래스여야 한다”
• “Value Object는 불변이어야 한다”
• “도메인 레이어는 인프라 레이어에 의존하지 않아야 한다”
• “모든 Command는 중첩된 Request, Response 클래스를 가져야 한다”

이 규칙들은 컴파일이 잘 되는 코드에서도 쉽게 위반될 수 있습니다.

“컴파일러는 코드가 실행되는지를 검증하지만, 코드가 올바르게 설계되었는지는 검증하지 않습니다.”

수동 검증의 한계

대부분의 팀은 이런 규칙을 코드 리뷰로 검증합니다. 하지만 수동 검증에는 근본적인 한계가 있습니다.

금요일 오후, 100개의 파일이 변경된 PR이 올라왔다고 상상해 보세요. 리뷰어는 새로 추가된 OrderItem 클래스가 sealed인지, Create 팩토리 메서드가 있는지, 불변성이 지켜지는지를 일일이 확인해야 합니다. 파일 50개쯤 지나면 피로가 쌓이고, 놓치는 항목이 생깁니다.

문제	설명
일관성 부족	리뷰어마다 기준이 다르고, 피로도에 따라 놓치는 항목이 달라짐
확장성 한계	코드베이스가 커질수록 모든 규칙을 확인하기 어려움
지연된 피드백	PR 리뷰 단계에서야 발견되어 수정 비용이 높아짐
암묵적 지식	규칙이 문서화되지 않으면 새 팀원이 위반하기 쉬움

아키텍처 테스트의 가치

아키텍처 테스트는 설계 규칙을 실행 가능한 코드로 표현합니다. 이를 통해:

1. 자동화된 검증: CI/CD 파이프라인에서 매 커밋마다 규칙 위반을 검출합니다
2. 즉각적인 피드백: 개발자가 코드를 작성하는 시점에 위반을 알 수 있습니다
3. 살아있는 문서: 테스트 코드 자체가 아키텍처 규칙의 명세가 됩니다
4. 일관된 기준: 리뷰어의 컨디션과 무관하게 동일한 기준으로 검증합니다

// 이것은 규칙 문서가 아닙니다. 실행 가능한 검증입니다.
[Fact]
public void DomainClasses_ShouldBe_PublicAndSealed()
{
    ArchRuleDefinition.Classes()
        .That()
        .ResideInNamespace(DomainNamespace)
        .ValidateAllClasses(Architecture, @class => @class
            .RequirePublic()
            .RequireSealed(),
            verbose: true)
        .ThrowIfAnyFailures("Domain Class Visibility Rule");
}

“아키텍처 테스트는 팀의 설계 합의를 자동화된 검증으로 바꿔줍니다. 규칙이 코드로 표현되면, 위반은 컴파일 오류처럼 즉시 드러납니다.”

아키텍처 테스트 vs 단위 테스트

구분	단위 테스트	아키텍처 테스트
검증 대상	비즈니스 로직의 동작	코드 구조와 설계 규칙
검증 시점	런타임 동작	컴파일된 어셈블리의 구조
실패 원인	잘못된 로직	규칙 위반 (예: sealed 누락)
유지보수	요구사항 변경 시 수정	아키텍처 규칙 변경 시 수정

두 종류의 테스트는 보완적입니다. 단위 테스트가 “코드가 올바르게 동작하는가”를 검증한다면, 아키텍처 테스트는 “코드가 올바르게 구조화되어 있는가”를 검증합니다.

FAQ

Q1: 아키텍처 테스트가 단위 테스트를 대체하나요?

A: 아닙니다. 아키텍처 테스트는 코드의 구조를 검증하고, 단위 테스트는 코드의 동작을 검증합니다. 아키텍처 테스트가 Employee 클래스가 sealed인지를 확인한다면, 단위 테스트는 Employee.Create()가 올바른 결과를 반환하는지를 확인합니다. 두 종류의 테스트가 함께 있어야 구조와 동작 모두를 신뢰할 수 있습니다.

Q2: 소규모 프로젝트에도 아키텍처 테스트가 필요한가요?

A: 팀 규모나 코드베이스 크기보다 규칙의 중요도가 기준입니다. 소규모 프로젝트라도 “도메인 엔티티는 반드시 sealed여야 한다”와 같은 핵심 규칙이 있다면, 아키텍처 테스트로 자동화하는 것이 효과적입니다. 프로젝트가 성장하면 그 가치는 더욱 커집니다.

Q3: 아키텍처 테스트는 CI/CD에서 어떻게 실행하나요?

A: 아키텍처 테스트는 일반 xUnit 테스트와 동일한 방식으로 실행됩니다. dotnet test 명령에 의해 CI/CD 파이프라인에서 자동으로 실행되므로, 별도의 도구나 설정이 필요 없습니다.

Q4: 아키텍처 규칙을 위반하면 어떻게 되나요?

A: 규칙을 위반한 클래스와 위반 내용이 테스트 실패 메시지에 상세히 출력됩니다. 개발자는 로컬에서 테스트를 실행하여 PR을 올리기 전에 위반 사항을 바로 확인하고 수정할 수 있습니다.

---

다음 단계

설계 규칙을 자동으로 검증하려면 적절한 도구가 필요합니다. 다음 장에서는 .NET 생태계의 아키텍처 테스트 도구인 ArchUnitNET과 Functorium ArchitectureRules 프레임워크를 소개합니다.

→ 0.2 ArchUnitNET 소개