Perry와 Wolf 모델로 보는 소프트웨어 아키텍처의 구조와 설계 근거

아키텍처를 설명할 때 빠지기 쉬운 한 축

Perry와 Wolf가 1992년에 제안한 모델은 소프트웨어 아키텍처를 Elements, Form, Rationale이라는 관점으로 나눈다. 시스템을 구성하는 대상, 그 대상이 맺는 구조, 그리고 그 구조를 선택한 이유를 함께 봐야 한다는 접근이다.

건축학의 관점을 소프트웨어 설계에 옮긴 이 모델은 이후 여러 아키텍처 프레임워크가 다루는 핵심 문제의 이론적 토대가 됐다. 구현물만 나열하거나 다이어그램만 남겨서는 아키텍처를 충분히 설명할 수 없다는 점에서 여전히 유효하다.

시스템을 이루는 대상: Elements

Elements는 시스템을 구성하는 기본 빌딩 블록이다. 모델은 이를 처리 요소, 데이터 요소, 연결 요소로 구분한다.

처리 요소는 데이터를 변환하고 처리한다. 서비스, 마이크로서비스, 컴포넌트, 모듈, 함수처럼 입력을 받아 출력을 만드는 능동적 구성요소가 여기에 속한다.

데이터 요소는 처리 요소가 사용하거나 만들어 내는 정보다. 데이터베이스, 파일, 메시지, 입출력 매개변수 등이 대표적이며, 시스템 안에서 정보의 저장과 전달을 담당한다.

연결 요소는 처리 요소와 데이터 요소 사이의 관계를 규정한다. 프로시저 호출, 메시지 큐, 파이프, 이벤트는 구성요소가 통신하고 상호작용하는 방식을 정한다.

마이크로서비스 아키텍처에 대입하면 개별 마이크로서비스는 처리 요소이고, 각 서비스의 데이터베이스는 데이터 요소다. REST API와 Kafka, RabbitMQ 등의 메시지 브로커는 연결 요소로 볼 수 있다.

⤢✕

Form은 관계와 제약을 드러낸다

Form은 요소가 서로 어떻게 연결되고 배치되는지를 나타낸다. 같은 요소를 사용하더라도 Form이 달라지면 시스템의 동작 방식과 품질 특성이 달라진다.

여기에는 요소 배치와 관계를 제한하는 제약조건이 포함된다. 계층 구조, 접근 제어, 의존성 규칙이 그 예다. 토폴로지는 요소의 물리적·논리적 구성 방식으로, 계층형 구조와 클라이언트-서버, 파이프-필터, 이벤트 기반 구조 등이 해당한다. 요소 간 속성과 관계도 Form의 일부다. 동기·비동기 통신, 단방향·양방향 흐름, 강결합·약결합이 이에 해당한다.

Form은 확장성, 성능, 보안, 유지보수성 같은 품질 속성에 직접 영향을 준다. 팀 간 협업에서 구조를 논의하는 기준점이 되며, 시스템이 바뀌고 진화할 수 있는 범위도 규정한다.

마이크로프론트엔드에서는 팀별 UI 영역 분리와 공유 상태 최소화가 제약조건이 된다. iframe, Web Components, JS 런타임 통합 같은 컴포지션 패턴은 토폴로지이며, 이벤트 기반 통신과 느슨한 결합은 요소 간 관계의 성격을 보여 준다.

⤢✕

설계의 이유를 남기는 Rationale

Rationale은 아키텍처 결정을 선택한 이유와 논리적 근거다. 구조도를 읽을 때 “무엇이 연결됐는가” 다음에 “왜 이 구조를 골랐는가”를 답하게 하는 관점이다.

비즈니스 목표와 사용자 요구는 Rationale의 출발점이 된다. 시장 출시 기간 단축, 사용자 경험 개선, 비용 효율성 같은 요구가 설계 선택에 영향을 준다. 성능, 확장성, 보안, 유지보수성, 가용성에 대한 품질 속성 요구도 마찬가지다. 예를 들어 5초 이내 응답시간, 99.99% 가용성, 10만 동시 사용자 지원은 선택 가능한 구조를 제한한다.

기술적·조직적·재정적 제약도 함께 기록해야 한다. 기존 레거시 시스템과의 통합, 특정 기술 스택의 채택, 팀 역량은 설계 결과를 설명하는 중요한 맥락이다.

이 근거가 남아 있으면 이후 변경 과정에서 과거 결정의 맥락을 확인할 수 있다. 아키텍처 평가와 검토의 기준을 만들고, 새 팀원과 이해관계자가 설계 의도를 이해하는 데도 도움이 된다. 시간이 지난 뒤에도 왜 특정 선택을 했는지 잊지 않게 한다.

Rationale은 Architecture Decision Records, ADR, 품질 속성 시나리오, 트레이드오프 분석과 민감도 분석으로 문서화할 수 있다.

⤢✕

설계 과정에서 관점을 연결하는 법

요구사항을 분석할 때는 먼저 Rationale을 정리한다. 비즈니스 목표, 품질 속성, 제약조건을 식별하는 단계다. 금융 거래 시스템이라면 보안과 트랜잭션 무결성이 우선 Rationale이 될 수 있다.

그다음 필요한 처리·데이터·연결 요소를 선택한다. 마이크로서비스는 처리 요소, NoSQL DB는 데이터 요소, REST API는 연결 요소로 볼 수 있다. 이후 요소 간 관계와 배치 패턴, 즉 Form을 설계한다. 이벤트 기반 아키텍처, CQRS 패턴, 계층화된 보안 모델 같은 선택이 여기에 속한다.

산업별 시스템에서도 같은 틀을 적용할 수 있다. 금융 시스템은 트랜잭션 처리 서비스, 계정 데이터, 암호화된 통신 채널을 요소로 두고 다중 계층 보안 아키텍처와 분산 트랜잭션 패턴을 Form으로 선택할 수 있다. 이때 규제 준수, 데이터 무결성, 보안 우선이 Rationale이 된다.

전자상거래 플랫폼에서는 카탈로그 서비스, 주문 프로세싱, 사용자 프로필, 결제 게이트웨이가 Elements가 될 수 있다. 마이크로서비스 아키텍처, 이벤트 소싱, CQRS는 Form의 선택이며, 확장성, 피크 트래픽 처리, 쇼핑 경험 최적화가 이를 뒷받침한다.

의료정보 시스템은 환자 기록 저장소, 진단 지원 서비스, 상호운용성 커넥터를 요소로 구성할 수 있다. 모듈형 아키텍처, 표준 기반 인터페이스, 데이터 분리는 Form에 해당하고, 규제 준수(HIPAA 등), 데이터 개인정보 보호, 시스템 안정성이 Rationale이다.

클라우드 네이티브 환경에서는 컨테이너화된 마이크로서비스, 클라우드 저장소, 서비스 메시가 Elements가 된다. Kubernetes 기반 오케스트레이션, 서버리스 패턴, 탄력적 스케일링은 Form의 사례이며, 운영 효율성, 클라우드 비용 최적화, 빠른 배포가 설계 근거가 된다.

DevOps와 CI/CD 파이프라인도 같은 방식으로 읽을 수 있다. 빌드 서버, 테스트 환경, 배포 도구는 Elements이고, 파이프라인 구조와 자동화된 워크플로우는 Form이다. 빠른 피드백 루프, 품질 보증, 배포 위험 감소가 Rationale을 이룬다.

⤢✕

다른 아키텍처 프레임워크에서의 확장

Kruchten의 4+1 View Model은 Perry와 Wolf 모델의 개념을 확장해 논리, 프로세스, 개발, 물리, 시나리오 관점을 제시한다. Elements는 각 뷰에서 서로 다른 방식으로 표현된다.

SEI 아키텍처 접근법은 품질 속성 시나리오를 통해 Rationale을 구체화하고, 아키텍처 전술(Tactics)을 통해 Form을 체계화한다.

C4 모델은 컨텍스트, 컨테이너, 컴포넌트, 코드라는 서로 다른 추상화 수준에서 Elements와 Form을 표현한다. 특히 Elements를 계층적으로 분해해 보여 주는 데 초점을 둔다.

Perry와 Wolf 모델은 간결하지만, 복잡한 시스템을 구조와 결정 배경으로 나누어 읽는 기준을 제공한다. Elements, Form, Rationale은 30년이 지난 현재도 아키텍처 문서화, 검토, 평가에서 함께 다룰 수 있는 관점이다.