아키텍처 드라이버로 설계 결정을 정렬하는 법

요구사항 가운데 설계를 바꾸는 것

복잡한 시스템에서 기능을 구현하는 일만으로는 충분하지 않다. 시스템이 어떤 가치를 우선하고 어떤 제약 안에서 동작해야 하는지를 설계에 반영해야 한다.

아키텍처 드라이버(Architecture Drivers)는 많은 요구사항 중 아키텍처 결정에 직접 영향을 주는 항목을 골라 정제한 결과물이다. 시스템의 구조, 기술 스택 선택, 컴포넌트 분할 방식에 근거를 제공한다. 모든 요구사항이 같은 무게를 갖지 않으므로, 비즈니스 목표와 기술 환경을 함께 고려해 실제 드라이버를 식별해야 한다.

이 과정 없이 설계를 시작하면 후반에 구조적 결함이 드러나거나 품질 속성의 충돌로 비용이 커질 수 있다. 드라이버는 설계 판단을 일관되게 유지하게 하는 기준이자, 시스템이 향해야 할 방향을 잡는 장치다.

설계 판단을 이끄는 요구사항의 성격

아키텍처 드라이버는 세 가지 핵심 요소가 맞물려 형성된다.

기능이 규정하는 시스템의 역할

기능적 요구사항은 시스템이 무엇을 해야 하는지 정의한다. 비즈니스 유즈케이스와 사용자 시나리오가 여기에 속한다.

모든 기능이 아키텍처를 결정하지는 않는다. 그러나 핵심 로직이나 데이터 흐름을 규정하는 기능은 드라이버가 된다. 대규모 데이터 처리나 복잡한 알고리즘이 필요한 기능은 시스템 분할 방식과 통신 방식에도 큰 영향을 준다.

품질 속성이 요구하는 동작 방식

품질 속성은 시스템이 어떻게 동작해야 하는지를 말하는 비기능적 요구사항이다. 가용성, 성능, 보안성, 유지보수성, 확장성이 대표적이다.

이 속성들은 서로 충돌할 수 있다. 극단적인 보안성을 추구하면 성능이 저하될 수 있고, 높은 가용성을 확보하려면 시스템 복잡도가 증가할 수 있다. 따라서 아키텍트는 우선순위를 정해 품질 속성을 드라이버로 정제해야 한다.

선택의 범위를 고정하는 제약

제약 조건은 아키텍트가 선택할 수 있는 범위를 제한하는 요인이다. 예산, 일정, 법적 규제 같은 비즈니스 제약과 특정 OS 사용, 기존 레거시 시스템 연동, 특정 벤더 솔루션 사용 같은 기술적 제약이 포함된다.

요구사항과 달리 제약은 타협하기 어려운 경우가 많다. 그래서 설계 초기에는 특히 강한 아키텍처 드라이버로 작용한다.

요구를 설계 근거로 다듬는 흐름

드라이버는 한 번에 완성되지 않는다. 요구사항을 수집하고, 영향이 큰 항목을 골라 모호함을 줄인 뒤 우선순위를 정하는 반복 과정이 필요하다.

⤢✕

드라이버는 단순한 선언이 아니라 품질 속성 시나리오처럼 구체적으로 표현되어야 한다. “시스템은 빨라야 한다”보다 “피크 타임에 1만 명의 동시 접속자가 발생했을 때, 결제 요청은 2초 이내에 완료되어야 한다”가 설계 판단에 사용할 수 있는 요구사항이다.

충돌하는 품질 속성에 근거를 남긴다

드라이버를 정의할 때는 충돌하는 요구사항 사이에서 균형을 정해야 한다. 모든 가치를 동시에 극대화할 수는 없고, 어떤 가치를 선택하면 다른 가치의 일부를 포기해야 할 수 있다.

예를 들어 마이크로서비스 아키텍처(MSA)의 선택 근거가 변경 용이성과 확장성이라면, 통신 지연과 데이터 일관성 유지의 어려움이 대가가 될 수 있다. 아키텍트는 이런 선택의 근거를 드라이버로 문서화하고 이해관계자와 합의해야 한다. 이는 특정 기술을 왜 선택했는지 설명하는 논리적 근거가 된다.

드라이버를 팀의 설계 원칙으로 바꾸기

정제된 드라이버는 설계 원칙(Design Principles)으로 구체화된다. “확장성을 최우선으로 한다”는 드라이버는 “모든 서비스는 Stateless하게 설계하며, 메시지 큐를 통한 비동기 통신을 기본으로 한다”는 지침으로 이어질 수 있다.

설계 원칙은 개발팀이 공유하는 기준이 된다. 아키텍처 리뷰와 코드 리뷰에서도 의사결정의 잣대로 활용할 수 있다. 프로젝트가 진행되면서 드라이버는 바뀔 수 있지만, 초기에 세운 견고한 드라이버는 시스템의 정체성을 지키는 기반이 된다.

Sources

Software Architecture in Practice (Bass et al.)
Clean Architecture (Robert C. Martin)
IEEE Standard 1471: Recommended Practice for Architectural Description of Software-Intensive Systems