High Level Architecture 오해 : 추상적이고 실제 개발과 동떨어져 있다.

 

고수준 아키텍처(High-Level Architecture)에 관해 많은 사람들이 이런 이야기를 합니다. 

"고수준 아키텍처는 너무 추상적이고 실제 개발과 너무 동떨어져 있다"

이번 포스팅에서는 이 이야기가 과연 진실인지, 오해인지에 대해 알아보고자 합니다.

 

 

출처: Just Enough Software Architecture 표지 그림

 

고수준 소프트웨어 아키텍처(High-Level Architecture)는 시스템의 전체적인 구조와 주요 구성 요소를 설계하여 큰 그림을 제공하는 역할을 합니다. 그러나 많은 개발자와 이해관계자들은 이 아키텍처가 “추상적이고 실제 개발과 동떨어져 있다”라고 느끼는 경우가 많습니다. 이러한 인식은 주로 다음과 같은 이유로 발생합니다.

 

1. High Level Architecture - 추상적이라는 이유로 실용성을 의심받음

고수준 아키텍처는 일반적으로 시스템의 모듈, 데이터 흐름, 컴포넌트 간의 상호작용 등을 블록 다이어그램이나 간단한 설명으로 표현합니다. 이러한 표현은 세부 구현 방법을 제공하지 않으므로, 개발자 입장에서 구체적인 요구사항이 명시되지 않았다고 느껴질 수 있습니다.

이런 현상은 소프트웨어 아키텍트가 아키텍처를 필요 이상으로 간단하게 설명하거나, 반대로 너무 복잡하고 이해하기 어려운 모델을 제시하는 경우 발생합니다. 또한 고수준 아키텍처와 상세 설계 간의 명확한 연결 고리가 없는 경우에도 "형식적인 문서"로 여겨질 가능성이 높아집니다.

 

예를 들어, 고수준 아키텍처에서는 말 그대로 "시스템의 큰 그림(Big Picture)"을 제시하는 역할을 합니다. 따라서 주요 컴포넌트가 무엇이며, 각 컴포넌트들간의 역할과 상호작용, 데이터 흐름을 정의합니다.  또한 기술 스택이나, 플랫폼, 성능 요구사항과 같은 전반적인 기술적 방향을 제공합니다. 반면 상세 설계에서는 고수준 아키텍처의 구체적인 구현을 위해 각 컴포넌트나 모듈의 내부 동작, 알고리즘, 세부 설계에 필요한 데이터 구조, API 설계 등을 구체적으로 설명합니다. 이 과정에서 고수준 아키텍처에 대한 구체적인 구현과의 관계가 불명확하거나 잘못된 경우, 고수준 아키텍처는 추상적이란 이유로 실용성을 의심받게 되고, 개발 방향성 혼란, 반복 작업 발생, 아키텍처와 설계 간의 불일치 문제 등이 발생하게 됩니다. 

고수준 아키텍처와 상세설계간의 연결 고리 개념

 

해결 방안:

• 구체적인 설명 추가: 아키텍처 설계에 각 구성 요소의 역할과 기술 스택을 명확히 기술합니다. 예를 들어, “Backend” 모듈이라면 이를 “Spring Boot를 사용한 RESTful API 서버”로 정의해 개발자가 쉽게 이해할 수 있도록 해야 합니다.
• 참조 구현 제공: 추상적인 설계를 보완하기 위해 핵심 모듈의 참조 코드를 제공하거나, 프로토타입으로 기능을 검증합니다.
• 이 밖에도 다양한 해결 방안이 추가적으로 있을 수 있을 수 있습니다.

 

2. High Level Architecture - 실제 개발과의 괴리감

실제로 고수준 아키텍처가 작성되는 시점을 보면 프로젝트 초기 단계에서 작성되며, 실제 코드나 구체적인 세부사항을 포함하지 않기 때문에 구현단계에서 실질적인 도움을 제공하지 못할 수 있습니다. 특히 빠르게 변화하는 요구사항이 있는 프로젝트에서는 초기 설계가 충분히 변화에 대한 유연성을 반영하지 못한 채 고정된 구조를 제시함으로써 이러한 오해가 발생할 수 있습니다. 그러나 고수준 아키텍처는 컴포넌트의 구성과 역할이나 전체적인 데이터 흐름, 플랫폼이나 기술 스택을 명확하게 정의함으로써, 상세 설계 및 구현 단계에서 일관된 구조와 개발, 상호작용시 발생할 수 있는 여러 상황에 대한 기본적인 방향과 컴포넌트 간 역할을 제시함으로써, 개발단계에서 야기될 수 있는 혼선을 제거할 수 있습니다. 즉, 고수준 아키텍처는 코드 구현 자체를 위한 활동이 아니라, 코드 구현을 위한 큰 틀에서의 역할 정의와 배경, 전반적인 데이터 흐름을 표현하는 것이며, 이런 특징으로 인해 코드 구현과 실질적인 구체성이 떨어져 개발과 괴리감이 발생한다고 느끼게 되는 것입니다.

 

예를 들어, 프로젝트 초기에 고수준 아키텍처를 작성하여, 컴포넌트간 구성과 구조 그리고 역할이 정의되어 있지 않은 경우, 코드 구현 과정에서 신호(데이터) 처리에 대한 컴포넌트 역할이 정의되지 않아, 개별 모듈에서 따로따로 신호(데이터) 처리가 정의되는 경우, 해당 코드는 중복 개발될 수 있으며, 그 과정에서 타입이나 단위 등이 혼재되어 개발에 혼선을 야기할 수도 있습니다. 

 

따라서 고수준 아키텍처는 개발 초기에 요구사항에 대한 분석이 충분히 이뤄질 수 있는 프로세스를 기반으로 소프트웨어 컴포넌트 구조와 역할 등이 명확하게 제시되고, 필요한 상호작용이나 이를 지원하는 기술 스택과 플랫폼 등이 명확하게 제시되어, 상세 설계 및 구현을 뒷받침해 주는 역할을 해야 합니다. 

 

3. High Level Architecture -명확한 역할과 목적에 대한 이해 부족

고수준 아키텍처의 역할과 목적은 크게 보면 비용 절감이며, 따라서 아키텍처를 위한 아키텍처를 개발한다거나, 아키텍처로 인해 개발 비용이나 유지보수 비용이 증가한다면 이는 분명 잘못된 것입니다. 그러나 수많은 컴포넌트와 서비스, 데이터 흐름으로 복잡해 짐에 따라 고수준 아키텍처를 기반으로 각 요소들을 모듈화 하고, 명확한 인터페이스를 정의하고 연결함으로써 이러한 복잡성을 체계적으로 관리할 수 있습니다. 이를 통해 개발자 개개인의 임의적이고 비효율적인 코드 작성을 예방할 수 있습니다. 또한 고수준 아키텍처에서는 팀 전체가 공유할 수 있는 공통 언어를 기반으로 개발이 되기 때문에, 여러 개발자가 협업하는 대규모 프로젝트에서는 중복 작업을 줄이고, 명확한 역할 분담도 가능해집니다.

 

특히, Agile에서는 빠른 피드백과 개발 주기가 강조되기 때문에, 아키텍처에 대한 역할과 목적에 대해 부정적인 시각이 있는 것도 사실입니다만, Agile 환경에서도 아키텍처 자체는 필요하다고 언급하고 있으며, 필요한 만큼의 설계(Just Enough Architecture)를 통해 최소한의 방향성을 제시할 수 있습니다. 또한 바쁜 개발 일정 속에서 아키텍처 설계가 우선순위에서 밀려나기도 하는데, 결과적으로 개발 후반에 재작업 비용과 리스크를 급격하게 증가시킬 수 있습니다.

 

다음 그림에서 보면, 상세 설계 시 고수준 아키텍처가 없이 개발 편의에 맞춰서만 개발하다 보면, 중복되고 서로 다른 인터페이스를 갖는 소프트웨어 모듈들이 설계될 수 있지만, 고수준 아키텍처가 존재하면 이들 간의 개발 효율성을 향상하며 추후 유지보수 비용도 현저히 줄일 수 있는 장점을 가진다는 명확한 역할과 목적을 이해할 필요가 있습니다.

고수준 아키텍처 역할

 

참고로, 고수준 아키텍처는 리뷰 활동과 유사하게 기술적 부채 관점에서 접근해야 한다고도 볼 수 있습니다. 아래 내용을 추가로 참고하시면 도움이 될 수 있습니다.

소프트웨어 리뷰(검토)의 경제적 가치, 이익

---

마치며... "High-Level Software Architecture는 단순한 문서 작업이 아니다"

고수준 아키텍처에 대한 오해는 어찌 보면 경험의 부재에서 기인하는 것은 아닐까 하는 생각이 듭니다. 빠르게 개발해야 하는 현실에서 오는 경제적 이익에 급급한 것도 원인이 될 수 있습니다. 그럼에도 불구하고 고수준 아키텍처의 필요성만큼은 누구나 공감하는 사항이라 생각됩니다.

고수준 아키텍처에 대한 고민을 통해 알게 된 Jeorge Fairbanks의 저서 "Just Enough Software Architecture: Risk-Driven Approach"를 한번 읽어보는 것도 좋은 방법이라 생각되며, 모든 것을 완벽하게 설계하려 하지 말고, 현재 필요한 만큼의 아키텍처를 설계하는 노력을 하는 것도 좋을 듯합니다.

아울러, 아키텍처는 고정된 문서가 아니라, 변경과 진화를 고려한 유연한 청사진으로 인식되어야 하며, 이를 통해 설계 초기 단계에서부터 팀원들이 적극적으로 참여하도록 유도하며, 아키텍처 리뷰를 주기적으로 수행할 수 있도록 프로세스를 강화하는 것도 필수적인 사항이라 생각됩니다.