왜 기능 하나에 여러 팀이 달라붙는가
단순한 기능 하나를 추가하는 데 왜 팀 간 회의가 여러 차례 필요해질까? 코드를 오래 다뤄본 백엔드 개발자라면 이 상황을 경험해봤을 것이다. 처음에는 명확했던 도메인 경계가 시간이 지나면서 서서히 무너지는 현상, 바로 경계 드리프트(Boundary Drift) 가 원인이다. 특정 도메인의 로직이 점차 인접 모듈이나 다른 팀의 서비스로 스며들면, 변경의 영향 범위가 예측할 수 없을 만큼 넓어진다.
이 상태가 지속되면 개발자의 인지 부하(Cognitive Load) 가 급격히 증가한다. 변경 한 건을 처리하기 위해 여러 팀의 컨텍스트를 머릿속에 담아야 하고, 사이드이펙트를 파악하기 위해 코드베이스 전반을 탐색해야 한다. 이는 단순한 생산성 저하를 넘어, 시스템이 변화에 적응하는 능력 자체를 잠식한다. 진화적 아키텍처(Evolutionary Architecture) 의 핵심은 변화에 유연하게 대응하는 구조인데, 경계 드리프트는 그 토대를 조용히 허물어버린다.
변화 지역성을 복원하는 세 가지 전략
경계를 복원하고 변경이 특정 도메인 안에서 완결되도록 만드는 실용적인 소시오테크니컬 접근법 세 가지를 살펴보자.
① 책임 재배치(Redistributing Mechanics) 로직이 잘못된 위치에 놓여 있을 때, 해당 책임을 원래 소유해야 할 도메인으로 되돌린다. 예를 들어 주문 처리 로직이 결제 서비스 안에 흘러들어가 있다면, 이를 주문 도메인으로 끌어와 응집도를 높인다. 이 과정은 단순한 리팩터링이 아니라 팀 간 소유권 재정의까지 포함하는 소시오테크니컬 작업이다.
② 핵심 정책 노출(Exposing Essential Policy) 도메인 간 협력이 불가피할 때, 암묵적으로 공유되던 비즈니스 규칙을 명시적인 정책(Policy)으로 드러낸다. 아래처럼 의존 방향을 역전시켜 도메인이 정책 인터페이스를 소유하고, 외부는 이를 구현하는 방식으로 경계를 지킨다.
// 주문 도메인이 정책 인터페이스를 정의
public interface FraudCheckPolicy {
boolean isSuspicious(Order order);
}
// 리스크 도메인이 해당 정책을 구현
@Component
public class RiskBasedFraudCheckPolicy implements FraudCheckPolicy {
@Override
public boolean isSuspicious(Order order) {
return order.getAmount().compareTo(THRESHOLD) > 0;
}
}
이렇게 하면 정책 변경이 주문 도메인 내부에 파급되지 않으며, 각 팀이 독립적으로 배포할 수 있는 여지가 생긴다.
③ 예외 경로 리허설(Rehearsing Exception Paths) 정상 흐름만 설계하다 보면 예외 상황에서 경계가 무너지는 경우가 많다. 장애 시나리오나 보상 트랜잭션 흐름을 사전에 팀 간 워크숍 형태로 리허설하면, 예외 처리 책임이 어디에 있어야 하는지가 명확해지고 불필요한 커플링을 사전에 제거할 수 있다.
실무에서 이 개념을 적용할 때 주의할 점
경계 드리프트는 악의 없는 편의주의에서 비롯되는 경우가 많다. "여기서 바로 호출하면 빠르니까"라는 결정이 반복되면 기술 부채가 된다. 따라서 아키텍처 리뷰 시점마다 변경이 얼마나 많은 팀에 영향을 미치는가를 하나의 지표로 추적하는 것이 효과적이다.
또한 이 전략들은 기술적 해법인 동시에 팀 구조와 소유권 합의를 전제로 한다. 코드만 옮긴다고 해결되지 않는다. 책임 재배치가 실질적인 효과를 내려면, 해당 도메인을 소유한 팀이 그 책임을 실제로 받아들이는 조직적 합의가 함께 이루어져야 한다.
정리
- 경계 드리프트는 도메인 경계가 점진적으로 침식되는 현상으로, 인지 부하 증가와 팀 간 의존성 심화를 초래한다.
- 책임 재배치, 핵심 정책 노출, 예외 경로 리허설은 변화 지역성을 복원해 진화적 아키텍처를 가능하게 하는 핵심 전략이다.
- 기술적 리팩터링만으로는 부족하며, 소유권 재정의와 팀 간 합의가 병행되어야 지속 가능한 경계 관리가 이루어진다.