결정론적 규칙의 한계: 아키텍처 의도는 어떻게 지킬까?
진화적 아키텍처(Evolutionary Architecture)는 시스템이 변화에 적응하면서도 핵심 설계 원칙을 유지하도록 돕는 접근법이다. 이를 위한 핵심 도구가 **적합도 함수(Fitness Function)**인데, 전통적인 방식은 빌드 성공 여부, 테스트 커버리지 임계값, 순환 복잡도 수치 같은 측정 가능한 하드 메트릭에만 집중해왔다. 문제는 실무에서 아키텍처 품질을 위협하는 요소들이 이런 수치만으로는 포착되지 않는다는 점이다.
예를 들어 도메인 경계가 점진적으로 흐려지는 경계 충실도(boundary fidelity) 저하, 팀 간 API 계약이 암묵적으로 변질되는 시맨틱 계약 드리프트(semantic contract drift), 수년 전에 작성된 ADR(Architecture Decision Record)의 전제가 현재 시스템 현실과 괴리되는 문제들은 숫자로 표현하기 어렵다. 이 영역은 판단이 필요한 영역이며, 기존 자동화 도구가 다루지 못하는 사각지대다.
에이전틱 적합도 함수: 판단이 필요한 영역을 자동화하는 방법
이 문제를 해결하기 위해 제안된 접근법이 **에이전틱 적합도 함수(Agentic Fitness Function)**다. 핵심 아이디어는 버전 관리된 루브릭(rubric)을 기준으로 아키텍처 품질을 지속적으로 평가하는 피드백 루프를 구성하는 것이다. 루브릭은 단순한 통과/실패 기준이 아니라, 경계 명확성이나 계약 일관성 같은 항목을 점수화하거나 서술적으로 평가할 수 있는 구조화된 평가 기준이다.
실무 적용 관점에서 보면, 루브릭 자체를 코드처럼 버전 관리함으로써 아키텍처 거버넌스 기준이 시간이 지나도 추적 가능하고 팀 내에서 합의 가능한 형태로 유지된다. ADR을 작성할 때 해당 결정의 검증 기준(fitness criteria)도 함께 기록하고, 이를 정기적으로 현재 시스템 상태와 대조하는 파이프라인을 구성하면 아키텍처 의도가 실제 코드에 반영되고 있는지를 지속적으로 확인할 수 있다.
# ADR 기반 적합도 기준 예시 (rubric.yaml)
adr_id: ADR-012
intent: "주문 도메인은 재고 도메인을 직접 호출하지 않는다"
fitness_criteria:
- type: dependency_check
rule: "order/** → inventory/** 직접 의존 금지"
severity: critical
- type: contract_drift_review
check_interval: sprint
reviewer: architecture_guild
위처럼 ADR의 의도를 기계가 읽을 수 있는 형태로 명시하면, CI/CD 파이프라인에서 결정론적 규칙은 자동으로, 판단이 필요한 항목은 정기적인 리뷰 트리거로 연결하는 이중 구조를 만들 수 있다.
지속적 아키텍처 거버넌스를 위한 실무 시사점
이 접근법이 4년차 이상 백엔드 개발자에게 중요한 이유는, 아키텍처 거버넌스가 단발성 리뷰나 개인의 경험에 의존하는 방식에서 벗어날 수 있기 때문이다. 팀이 커지고 서비스가 MSA 구조로 분화될수록, 각 팀이 독립적으로 결정을 내리면서 전체 시스템의 설계 일관성이 무너지는 현상은 매우 흔하다.
에이전틱 적합도 함수 체계는 이를 막기 위한 지속적이고 교정 가능한(calibrated) 피드백 루프를 제공한다. 중요한 것은 완전 자동화보다 자동화 가능한 영역과 판단이 필요한 영역을 명확히 분리하고, 후자에 대한 리뷰 주기와 책임을 구조화하는 데 있다. 기존의 ArchUnit 같은 정적 아키텍처 테스트와 함께 사용하면 서로의 단점을 보완할 수 있다.
// ArchUnit으로 결정론적 경계 검증 (기존 방식)
@ArchTest
static final ArchRule orderShouldNotDependOnInventory =
noClasses().that().resideInAPackage("..order..")
.should().dependOnClassesThat()
.resideInAPackage("..inventory..");
이처럼 코드 레벨의 규칙 검증은 ArchUnit으로, 그 너머의 시맨틱 계약이나 ADR 가정 검증은 루브릭 기반 리뷰로 이원화하는 구조가 실용적인 출발점이 될 수 있다.
정리
- 전통적 적합도 함수는 측정 가능한 하드 메트릭만 다루며, 경계 충실도·시맨틱 드리프트·ADR 가정 검증 같은 판단 영역에는 한계가 있다.
- 버전 관리된 루브릭과 ADR을 연계해 아키텍처 의도를 지속적으로 검증하는 피드백 루프를 구성하면, 시스템이 성장해도 설계 원칙을 유지할 수 있다.
- 결정론적 자동화(ArchUnit 등)와 루브릭 기반 정기 리뷰를 이원화하는 것이 현실적이고 효과적인 아키텍처 거버넌스 전략이다.