오래된 SW 엔지니어의 평생 공부

스타워즈는 우리나라에서 크게 흥행하지는 않았지만, 프랜차이즈 영화로서는 인지도는 상당하다.  "May the Force be with you"는 스타워즈에서 제다이 기사들이 해어질 때 주로 쓰는 인사 말이다. "포스가 그대와 함께하길" 정도로 해석이 된다. 포스(Force)는 중국 무협 소설의 내공과 비슷한 것이라고 이해할 수 있다. 그렇다면, 소프트웨어 아키텍처에서의 포스(Force)는 무엇일까?

소프트웨어 아키텍처에 대해서 카네기 멜론 대학의 Software Engineering Institute를 이야기 하지 않을 수 없다. SEI 출신의 학자들 책인 'Software Architecture in Practice 소프트웨어 아키텍처 이론과 실제'[1]는 21년도에 4판까지 나와 있다. 이 책에서는 소프트웨어 아키텍처에서 "포스(force)"는 아키텍처 결정에 영향을 미치는 다양한 요소나 영향력을 의미한다. 이러한 포스는 기술적 요구사항, 비즈니스 전략, 사용자 요구 사항, 제약 조건 및 환경적 요인 등을 포함할 수 있다. 이 포스는 이 책의 특징인 품질 속성(Quality Attribute)로 정제되어 설계에 활용된다.

이외의 여러 문헌을 보았지만, 특히 패턴과 관련된 몇권의 책들에서 포스가 언급된다. 살펴 보았던 패턴 관련 문헌 중 가장 오래된 문헌은 브라이언 푸트와 조셉 요더의 "Big Ball of Mud"[2] 의 아래 내용이다.

By recognizing the forces and pressures that lead to architectural malaise, and how and when they might be confronted, we hope to set the stage for the emergence of truly durable artifacts that can put architects in dominant positions for years to come. The key is to ensure that the system, its programmers, and, indeed the entire organization, learn about the domain, and the architectural opportunities looming within it, as the system grows and matures.
아키텍처의 불쾌감을 유발하는 '포스과 압력'을 인식하고, 언제 어떻게 직면할 수 있는지 파악함으로써 향후 수년간 아키텍트를 지배적인 위치에 올려놓을 수 있는 아주 내구성 높은 산출물이 창발할 수 있는 발판을 마련할 수 있기를 바란다. 핵심은 시스템과 프로그래머, 나아가 전체 조직이 시스템이 성장하고 성숙함에 따라 해당 도메인과 그 안에서 다가오는 아키텍처 기회에 대해 학습하도록 하는 것이다.

이 글의 결론 부분에서 이야기하는 산출물은 패턴으로 볼 수 있다. 이 때, 포스는 패턴의 사용을 이끌어내는 여러 요소가 있다는 것을 이야기 한다고 볼 수 있다.

다른 책들의 경우는 객체 지향 리엔지니어링 패턴 "Object Oriented Reengineering Patterns"[3]에서는 각 장에서 패턴을 설명하기 전에 개요와 "포스: 주요한 요구사항(Forces)" 섹션이 있다. 즉, 관련된 패턴들이 공유하는 주요한 요구 사항들에 대해서 설명을 하고 패턴에 대해서 설명한다. 각 패턴이 집중하는 부분에 따라, 트레이드오프(Tradeoffs)가 존재하며 이에 따른 장점(Pros)와 단점(Cons)을 설명한다.

Patterns of API Design[4]의 경우도 여러 패턴을 다루는데, 여러 가지 포스/주요한 요구 사항 사이의 충돌(coflicting)이 있고, 이를 해소/해결(resolution)이 필요하다고 보고 있다. 또한 여기에는 트레이드오프(tradeoff)가 있다고 본다. 이러한 과정을 설계 결정(design decision) 혹은 아키텍처 결정(architecturla decision)이라고 한다. 책의 3장에서는 이러한 예제를 보여주는데, 다음과 같은 아키텍처 의사 결정 기록(architectural decision record, ADR) 형식을 제안한다.

[기능 또는 컴포넌트]에 해당하는 맥락에서,
[요구 사항 또는 목표로 하는 품질 속성(Quality Attribute)]을 충족할 필요가 있다,
우리는 [이익]을 우선적으로 달성하기 위해
[선택된 옵션]을 채택하기로 결정하고
그리고 [대안]은 선택하지 않아서
그 선택에 따르는 [부정적인 결과]는 받아들인다.


여러 아키텍처 책 혹은 디자인 패턴 책에서 언급하는 포스에 대해서 살펴 보았다. 앞에서 언급한데로 아키텍처에 영향을 미치는 드라이버(driver), 주요한 요구 사항, 혹은 품질 속성으로 보기도 한다. 이러한 부분은 아키텍처 결정에 어떤 영향을 미치는지 설명하는데 사용되기도 하고 패턴을 선택하는데도 사용되므로 이에 대해 이해하고 적절한 설계 결정, 즉 선택을 위해 고려되어야 한다.

참고문헌
[1] Len Bass, Paul Clements, Rick Kazman, "Software Architecture in Practice", SEI series in software engineering.
[2] Brian Foote and Joseph W. Yoder, "Big ball of mud", Pattern Languages of Program Design, volume 4, pages 654–692. Addison Wesley, 2000.
[3] Serge Demeyer, Stéphane Ducasse, Oscar Nierstrasz, "Object Oriented Reengineering Patterns"
[4] Olaf Zimmermann, Mirko Stocker, Daniel Lubke, Uwe Zdun, Cesare Pautasso, "Patterns for API Design: Simplifying Integration with Loosely Coupled Message Exchanges",  Addison-Wesley Signature Series