애자일 소프트웨어 아키텍쳐를 향하여.

소개

이 글[1]은 2015년도 글이기는 해도, 최근에 발견했다. 애자일 과정과 기존의 Software Architecture 접근법에 대한 고찰이 포함되어 있어 참고할만한 글이다.

 

Towards an Agile Software Architecture

소프트웨어 아키텍처는 시스템의 골격(Skeleton)이다. 다른 기능적 요구 사항(Functionall Requirements)과 비기능적 요구 사항(Non-functional requirements)으로 시스템이 작동하는 방식을 정의한다. 한편으로 전통적인 워터폴 방식은 프로젝트 개발의 모든 단계에 강한 제약을 가하기 때문에 엄격하다. 반면에 애자일 접근법은 개발 단계 후반에도 변경 사항을 환영한다. 우리는 견고한 개발에서보다 유연한 개발로 전환하고 있지만, 소프트웨어 아키텍처는 골격(Skeleton)이라는 태생상 기본 특성으로 인해 변화에 민감하다. 따라서 애자일 접근법을 따라갈 때 핵심 요소는 지속 가능한 소프트웨어 아키텍처의 개념을 수용하는 것이다. 이는 프로젝트의 복잡성 증가와 함께 시스템 확장이 점진적이고, 쉽고, 유지 보수 가능한 방식으로 이루어질 수 있도록한다.

이 글에서는 기존의 워터폴 소프트웨어 아키텍처와 애자일 아키텍처 모두에서 작업 할 때의 경험을 다룬다. 나는 세 가지 영역에 중점을 둔 이들의 유사점과 차이점을 묘사한다.

 

• 소프트웨어 아키텍트 역할의 세부 사항
• 소프트웨어 아키텍처의 타임스팬(Timespan)
• 소프트웨어 아키텍처의 결과물

소프트웨어 아키텍처란 무엇인가?

소프트웨어 아키텍처에 대한 정의는 수백 가지가 있다 (실제로 새로운 본인의 정의를 직접 추가 할 수도 있음). 그 이유는 모든 사람이 자신의 상황에 따라 정의하기 때문이다. 나는 특히 IEEE의 정의를 좋아하는데, 기본 개념을 설명하고 머리에서 쉽게 그려 볼 수 있기 때문이다. 또한 소프트웨어 아키텍처의 생성 방식이 아니라 소프트웨어 아키텍처의 본질을 묘사하기 때문에 워터폴 및 애자일 프로세스에 모두 적용된다. 이 글의 나머지 부분에서 나는 이 정의를 언급 할 것이다.

 

구성 요소(Components) 서로와 그리고 환경(Environment)과의 관계(Relationship), 설계 및 진화(Evolution)를 안내하는 원칙으로 구현되는 시스템(System)의 기본 구조(Fundamental Organization)

 

워터폴 소프트웨어 아키텍처

기존의 워터폴 개발은 시작 날짜와 종료 날짜가 명확한 일련의 단계로 구성되며, 각 단계에는 특정 활동 세트가 포함된다. 모든 단계는 서로 연결되어 있으며 각각의 단계는 이전 단계에서 생성된 결과물에 크게 의존한다. 그림 1은 폭포 개발과 관련된 일반적인 단계를 보여준다.

 

 

전통적 워터폴 개발방식

소프트웨어 아키텍처에 대한 작업은 일반적으로 소프트웨어 요구 사항이 정의 된 후에 시작된다. 이 시점에서 시스템은 수행해야 할 작업에 대해 잘 정의되어 있다고 가정한다. 다음 단계는 소프트웨어 아키텍처를 정의하는 담당자와 이 단계의 실제 결과를 조사하는 것이다.

 

전통적인 소프트웨어 아키텍트

소프트웨어 아키텍처는 실제로 소프트웨어 아키텍트가 수행한다. 기술 지식과 경험이 풍부한 사람이다. 일반적으로 회사의 특정 수준에 도달한 후 승진 한 개발자이다. 이 사람은 소프트웨어 요구 사항을 분석하고 이러한 요구 사항을 기반으로 미래 시스템에 대한 특정 기술 결정을 담당한다. 많은 회사에는 일반적으로 프로젝트 당 하나의 소프트웨어 아키텍트가 있지만 일부 대기업에는 소프트웨어 설계자 팀이 함께 작업 할 수 있다. 이는 일반적으로 프로젝트 도메인이 복잡하거나 프로젝트의 기간이 더 큰 경우 (예 : 2-3 년 이상)이다. 모든 회사에 지정된 소프트웨어 아키텍트 역할이있는 것은 아니다. 많은 회사에서 이러한 책임을 경험 많은 개발자(Senior Developer)에게 위임한다. 이 글의 나머지 부분에서는 명시적으로 언급하지 않는 한 소프트웨어 아키텍트는 다른 누군가가 하지 않고 소프트웨어 아키텍트가 수행하는 특정 활동을 언급한다.

전통적인 소프트웨어 아키텍트는 다음과 같은 네 가지 주요 기능을 담당한다.

• 큰 그림에 초점을 맞춘다. - 소프트웨어 아키텍트는 시스템이 향후 몇 달 (때로는 몇 년)처럼 어떻게 보일지 고려해야한다. 또한 관련된 다른 모든 시스템 (예 : 타사 시스템 및 데이터 저장소)과 시스템 간의 통신이 어떻게 진행 될지 고려해야 한다.
• 규정 준수 지향 - 소프트웨어 아키텍트는 가능한 규정 준수 문제를 고려해야 한다. 이것은 입법 규범, 라이센스, 표준 또는 기타를 포함하여 미래의 시스템이 이러한 중요한 기준을 충족하도록 해야한다.
• 청사진을 생성한다. - 중요한 산출물은 다양한 관점에서 아키텍처를 설명하는 문서 및 다이어그램 모음이다. 개발 팀은 이러한 결과물을 사용하여 시스템 구축을 시작한다.
• 실무 경험이 많지 않음 - 소프트웨어 아키텍트의 목표는 개발 팀을위한 최종 문서를 작성하는 것이다. 소프트웨어 아키텍트는 일반적으로 개발자로서의 경험이 있지만 개발 프로세스에는 거의 관여하지 않으며 개발자가 설계 시스템을 구축하도록 유도한다. 어느 시점에서 그는 개발자는 남겨 두고, 다른 프로젝트로 이동할 수 있다. 

실제 사례의 고통 

나는 세계에서 가장 큰 맥주 회사 중 하나를 위한 소프트웨어 프로젝트를 진행하고 있다. 이 프로젝트를 완료하는 데 2-3 년이 걸렸으며 일반적인 워터폴 방식으로 수행 되었기 때문에 소프트웨어 아키텍트, 개발자, 테스터 등 여러 단계를 담당하는 사람들이있었다. 나는 소규모 팀의 개발자였으며 ​​소프트웨어 아키텍트로부터 시스템 개발 수행 방법에 대한 지시와 가이드라인을 받았다. 처음에는 소프트웨어 아키텍트가 우리를 지원하기 위해 팀에 있었지만 나중에 그 프로젝트의 작업량이 줄어들면서 다른 프로젝트로 옮겼다. 제안 된 소프트웨어 아키텍처는 정의된 경계에 맞지 않는 새로운 종속성이 등장함에 따라 어느 시점에서 따르기가 어려워졌다. 수석 개발자가 아키텍처 비전을 인수하려고 했지만이 프로젝트는 소위 스파게티 코드로 성장했다.이 프로젝트는 다른 곳에서 문제를 일으킬 수 있으므로 모든 사람이 변경을 두려워 했다. 불행히도 프로젝트를 정상 괘도에 올릴 수 있는 과감한 변화를하기에는 너무 늦었었다. 우리는 프로젝트를 출시했지만 나중에 결국 종료되었다.

애자일 접근법

기존의 워터폴 구조는 시작 날짜와 종료 날짜가 명확한 일회성 활동이지만, 애자일 소프트웨어 아키텍처는 진행중인 프로세스이므로 결코 끝나지 않을 수 있다. 이를 통해 필요한 경우 아키텍처 변경 사항을 정기적으로 적용 할 수 있다. 프로젝트의 변화를 환영하는 메커니즘 중 하나는 반복적이고 점진적인 개발을 적용하는 것이다. 스크럼에서는 이러한 반복을 스프린트라고하며 하나의 스프린트는 일반적으로 그림 2에 표시된대로 2-4 주 사이에 지속된다. 이러한 작은 간격을 사용하면 발생하는 모든 변경 사항에 대해 바로 바로 논의 할 것이다. 또한, 팀 협업에 중점을 두고 있으며 오해와 의사 소통이 원활치 않은 것을 방지하며 팀원 간의 문제를 즉시 해결한다.

스크럼의 일반적인 스프린트

애자일 접근법을 통해 프로젝트의 변화를 환영할 수 있지만 얼마나 빠르게 대응해야하는지 알려주지는 않는다. 소프트웨어 아키텍처는 시스템의 백본이므로 변경에 따라 움직인다. 예를 들어, 프로젝트 중간에 사용하는 플랫폼이나 언어를 변경할 수 있다고 생각하는가? 드물기는하지만 이러한 변경에는 많은 추가적인 이터레이션을 필요로 한다. 심지어 프로젝트의 시작 부분으로 돌아갈 수도 있다. 소프트웨어 아키텍처와 관련하여 일부 유형의 변경은 고통스럽고 구현하는 데 시간이 걸린다.

 

애자일 소프트웨어 아키텍트

스크럼은 세 가지 유형의 역할을 정의한다.

• 제품 소유자(Product Owner) - 특정 비즈니스 도메인에 대한 정보를 제공한다.
• 스크럼 마스터 - 팀의 의사 소통 및 협업 촉진 한다.
• 개발팀 - 사용자 스토리을 구현하고 작동하는 소프트웨어를 제작한다.

전통적인 소프트웨어 아키텍트 역할을 애자일 개발에 맞는 역할로 변환하기 위해 가능한 변형을 살펴 봐야한다. 스크럼 팀을 구성하는 한 가지 방법은 개발자 팀과 별도의 소프트웨어 아키텍트 팀이 긴밀하게 협력하는 것이다. 그림 3은 이 시나리오를 여러 스크럼 팀에 적용한 것을 보여준다.

 

열 개발팀과 함께 작업하는 별도의 소프트웨어 아키텍트 팀

이것이 팀을 구성하는 올바른 방법이지만 두 가지 문제가 있다.

• 소프트웨어 아키텍트 팀은 수요자(Demander)가 될 수 있지만 개발자 팀은 일반적으로 워터폴 접근 방식의 경우 생산자(Producer)입니다. 소프트웨어 아키텍트는 비전을 정의하고 개발자는 비전을 구현해야한다. 이는 개발자를 관여시키지 않고 정중하게 다루지 않으면 개발자 간의 동기를 감소시킬 수 있다.
• 위의 결과로 일부 개발자는 다른 개발자가해야 할 일을 선택할 수 있도록 소프트웨어 설계자 팀의 일원이되기를 원할 수 있다. Trustpilot은 핵심 팀과 개발 팀을 보유한 사례를 제시했지만, 이는 작업장과 공동 작업에 대한 도덕을 감소 시켰기 때문에 핵심 팀의 각 구성원을 하나의 개발 팀으로 옮겼다. 이는 긍정적인 결과를 낳았다.

또 다른 방법은 소프트웨어 아키텍트를 그림 4와 같이 개발 팀에 직접 배치하는 것이다.

각 개발 팀에는 하나의 소프트웨어 아키텍트가 있다.

이 경우 애자일 소프트웨어 아키텍트는 약간 다른 책임을 갖는다.

• 큰 그림과 현재의 균형 – 민첩한 소프트웨어 아키텍트는 전체 시스템의 큰 그림에 맞춰 개발하는 동안 발생하는 상황을 고려해야 한다.
• 실무 경험 – 애자일 소프트웨어 아키텍트는 개발자이며 시스템 구현 작업을 한다. 이것은 선택된 구조적 결정(architectural decision)에 대한 직접적인 피드백을 제공한다.
• 결정 사항을 설명할 수 있도록 프로토 타입을 제작 - 중요한 기술적 결정을 내려야 할 경우, 빠른 프로토타입을 통해이 결정이 가능한지 여부와 기존 시스템에 어떤 영향을 미치는지 알 수 있다. 또한 전체 개발 팀과의 커뮤니케이션은 개인 개별 활동이 아닌 공동 노력해야 하는 것으로 필수적이다.
• 지속 가능성에 초점 – 구조적 결정(architectural decision)이 지속 가능한 소프트웨어 아키텍처를 이끌어내는 것이 매우 중요하다. 이는 장기적으로 프로젝트를 지원할 것이다. 이것의 필수 부분은 개인적인 책임과 공감이다. 애자일 소프트웨어 아키텍트는 개발 팀의 일원이므로 위에서 설명한 의사 결정을 통해 직접적인 피드백을 받는다. 이는 워터폴에서 접근하는 방식과 달리 개인의 책임 수준을 높이며, 결정은 개발 팀에 전달되어 구현된다.

다른 개발 팀 (및 프로젝트)간에 구조를 공유하려는 경우 별도의 소프트웨어 설계자 팀과 함께 구조를 선택할 수 있다. 또한 많은 관점을 고려해야하는 복잡한 도메인에서 작업하는 경우, 이 구조를 적용 할 수도 있다. 그러나 이 경우 소프트웨어 아키텍트가 개발자와 긴밀하게 협력하고 지원하도록 해야한다. 애자일 방법론은 협업에 중점을 두므로 소프트웨어 아키텍트를 개발자와 분리하면 협업이 어려워진다. 결과적으로 개발 프로세스는 워터폴 모델에 가까워진다. 나는 개인적으로 팀 구성원 간의 의사 소통이 향상되기 때문에 각 개발 팀에 한 명의 소프트웨어 설계자가 존재하는 두 번째 변형을 선호한다. 선임 아키텍트(High level architects)는 여전히 서로 협력 할 수 있다 (꼭 그렇게 해야 한다).

 

애자일 소프트웨어 아키텍처의 타임스팬

애자일 소프트웨어 아키텍처의 중요한 측면은 언제 시작하는가 이다. 우리가 잘 정의 된 단계를 가지고있는 워터폴 모델과는 달리, 애자일 세계에서는 사람들이 시작 단계라 정의 하는 특정 항목이 없다. 일반적인 접근 방식 중 하나는 스프린트 #0을 진행하는 것이다. 개발 환경을 구성하고 프로그래밍 언어, 플랫폼, 데이터베이스 등과 같은 몇 가지 기본 결정을 내리는 특수 스프린트이다.

그러나 이러한 접근 방식의 일반적인 함정은 사람들이 항상 “거의 준비되었다”고하면서 이 기간을 연장하는 경향이 있다는 것이다. "일주일 더 있으면 정규 스프린트를 시작할 수 있다"라는 말이 종종 들린다. 많은 경우에, "사전 도움말 기능을 미리 구현하는 것이 정말 멋지므로"라며서 유저 스토리없이 시스템에 이미 작업하고있는 것을 알 수 있다. 이러한 상황에서는 스프린트 #0의 종료 날짜에 미리 동의해야 한다. 이는 스프린트 지속 시간 또는 그와 유사한 기간이 될 수 있다.

정규 스프린트가 시작될 때 아키텍처가 준비되지 않은 경우 어떻게 될지 궁금 할 것이다. 글쎄, 그래도 괜찮다. 실제로 준비되지 않았을 수 있다. 그리고 그것 또한 괜찮다. 소프트웨어 아키텍처는 지속적으로 진행되는 프로세스이다. 이것은 시스템의 골격이므로 항상 되돌아와 수정해야한다. 당신의 아키텍처가 필요한 것을 충분히 지원하지 않는다면 시스템을 개발할 여유가 없다. 사이먼 브라운(Simon Brown)의 말을 인용해 보자 :

 

기민한 팀(Agile Team)이 반드시 기민한 소프트웨어 아키텍처(Agile Software Architecture)를 만들지는 않는다.
그러나 좋은 아키텍처는 기민성(Agility)을 가능하게한다.

 

관리 원칙

우리가 사는 세상은 복잡하며 모든 비즈니스 영역도 마찬가지이다. 소프트웨어 아키텍처를 구축 할 때는 처음부터 작업을 너무 복잡하게하면 결과적으로 오류가 발생하기 쉽다. 의사 결정시 두 가지 원칙이 사실상의 표준이되었다.

 

• 바보야, 단순하게 해 (Keep It Simple, Stupid. KISS)
• 넌 그것을 필요로하지 않을 거야 (Your Aren't Gonna Need It. YAGNI)

이 두 가지 원칙이 지키려고 하는 것이 바로 그 순간에 특정 기능이나 결정이 필요한지 생각하게 하는 것이다. 나중에 결정을 연기 할 수 있다면 아키텍처를 단순하게 유지하여 더 오랜 시간 동안 쉽게 관리 할 수 ​​있다. 소프트웨어 아키텍처가 복잡 해지는 일반적인 방법 중 하나는 추상화를 도입하는 것이다. 이 형식은 데이터를 한 형식으로 복사하여 다른 형식으로 변환하는 새로운 고급 레이어 일 수도 있고, 코드 100 % 테스트 가능하게 하기 위해 많은 클래스, 인터페이스, 팩토리 등을 생성하는 것일 수도 있다. .

 

그러나, 이 두 가지 원칙을 적용 할 때 한 가지 함정은 우리가 마지막 순간까지 모든 것을 지연시키는 경향이 있다는 것이다. 그때에는 필요한 변경을 구현하기가 이미 너무 어려워 졌을 수 있다. 대신 우리의 임무는 훨씬 더 어렵다. 왜냐하면:

 

우리는 마지막 순간이 아닌 가장 적정한 시간(Most Responsible Time)에 결정을 내려야 하기 때문이다 

 

구조적 결정을 내리려고 할 때, 결정의 확실성이 높은 경우, 일반적으로하는 일이 시간이 많이 걸리지 않는 작은 준비를하는 것이다. 나는 또한 동료들과 상의하고 함께 토론한다.

 

실제 상황의 고통

온라인 페리 티켓 판매에 관한 프로젝트를 진행하고 있었다. 다른 4 개의 타사 시스템과 통신해야했기 때문에 복잡한 시스템이었다. 처음에는 주로 사용자 스토리를 기반으로 기능을 구현하는 데 중점을 두었다. 우리는 정교한 캐싱 메커니즘이 필요하다는 것을 알고 있었지만 그 순간에 필요하지 않았기 때문에 이를 지연시켰다. 당시 사용자 스토리에 집중해야 했다. 그러나 나중에 다른 타사 시스템과의 광범위한 통신으로 인해 시스템 속도가 느려졌다. 우리는 다른 선택의 여지 없이 사용자 스토리에 대한 작업을 중단하고 캐싱 메커니즘에 초점을 맞추어야 했다. 그 때에는 이미 구현하기가 어려웠다.

문서를 작성하는 방법

워터폴 접근 방식은 단계 간에 정보를 전송하는 데 문서가 사용되므로 각 단계에 관련된 사람들이 광범위하게 문서를 작성해야한다. 이 작업은 시간이 많이 걸리는 프로세스 일뿐만 아니라 잘못 설명된 기능으로 인해 오해로 이어질 수 있다. 또한 개발 속도가 빨라지면, 문서가 더 이상 이를 반영하지 않기 때문에 문서를 최신 상태로 유지하기가 어렵다. 코드 작성하기 위해 반복(Iteration)을 하는 애자일 접근법을 사용하면, 문서 작성도 유사하게 수행할 수 있다. 우리는 시스템의 중요한 측면만을 설명하고 시작한 다음 필요할 때 지속적으로 더 많은 정보를 추가한다.

 

문서화 내용(What to Document)

동일한 형식을 여러 형식으로 여러 번 문서화하지 말자. 예를 들어 코드에서 다이어그램을 생성하는 데 도움이되는 도구가 있다. 이 도구는 사용되지 않는 경향이 있으므로 별도의 다이어그램을 만드는 대신 매우 편리 할 수 ​​있다. 또한 시스템의 특정 측면을 설명하기 위해 시각적 산출물을 작성한 경우 단어로 동일한 내용을 설명하는 광범위한 텍스트 문서를 작성할 필요가 없다 (세부 사항을 추가하지 않으면 시각적으로 표현할 수 없음). 여기서 중요한 점은 당신과 당신의  팀은 사용 된 도면 표기법에 대한 일반적인 이해가 필요하다는 것이다.

 

문서화하는 방법

소프트웨어 아키텍처를 문서화 할 때 UML이 최선의 방법이라고 생각할 수 있다. UML은 표준이며 모든 사람이 알고 있으며 대학에서 이를 가르치므로 조직의 모든 사람을 통합할 수있는 도구 중 하나다. 내 경험에 따르면 실제로 UML을 사용하는 사람은 거의 없다. 그 이유 중 하나는 다른 관점에서 시스템을 설명하는 많은 방법이 있기 때문에 정기적으로 사용하지 않으면 좌절 할 수 있습니다.

애자일 세계에서 소프트웨어 아키텍처를 문서화하기위한 특정 도구는 없다. 화이트 보드 그림, Post-It 메모, 텍스트 문서, 위키 등을 사용할 수 있다 (아래 그림 참조). 실제로 2-3 개의 다른 산출물 형식만 사용하는 것이 더 안전하다. 그렇지 않으면 해당 형식을 저장하고 정보를 검색하기가 어려워 질 수 있습니다. 예를 들어, 그림을 그린 후에 화이트 보드 사진을 찍어야 디지털 버전의 다이어그램을 만들 수 있다. 그러나 나중에 편집해야하는 경우 디지털 방식으로 편집 할 것인지 화이트 보드에 다시 그릴 것인지 새 사진을 찍을 것인지 선택해야한다.

화이트 보드 도면 및 포스트잇 형태의 문서

 

결론

소프트웨어 아키텍처는 미래 시스템의 골격(Skeleton)을 정의한다. 이것은 선과 점이있는 다이어그램이 아니라 코드 자체를 포함하여 시스템 개발을 관리하는 완전한 결정 세트(Decision Set)이다. 모든 결정은 타협이므로 신중하게 고려해야 한다. 애자일 사고 방식은 요구 사항이 다소 안정적 일 것으로 예상되는 기존 워터폴 모델과 달리 프로젝트 후반에도 변화에 개방적이어야 한다. 그러나 시스템 골격의 변경이 항상 구현하기 쉽지는 않으며 개발 프로세스를 이전으로 되돌릴 수도 있다. 따라서, 마지막 순간까지 결정을 지연시키지 말고 그 시점에 필요하지 않은 것을 구현할 위험이 적더라도 가장 적정한 결정(Most Responsible Decision)을 내리는 것이 중요하다. 또한 애자일 소프트웨어 아키텍처는 모든 사람이 구축 할 수있는 지속 가능한 플랫폼을 만들기 위해 큰 그림과 "지금"을 복합적으로 혼합해야 한다.

 

번역의 결론

이 글을 읽으면서 가장 기억에 남은 문구는 가장 적정한 결정(Most Responsible Decision)이라 번역한 표현이다. 외국에 있을 때, 음주 관련 공익 광고 중에 "Drink Responsibly"라는 광고 카피가 기억에 남는다. 이는 자기가 감당할 정도로만 마셔서, 자신의 생활과 관계를 잘 유지할 수 있도록 하자는 뜻이라고 한다. 나는 이와 일맥 상통한다고 생각했다. 즉, 구조적 결정을 하는 시간과 범위를 가능한 미루는 것이 아니고 알맞고 발라야 한다는 것이다.

 

또한, 토론에 대한 언급도 좋았다. 나는 애자일 접근법이 소통으로 이루어 지는 부분이 매우 훌륭하다고 생각한다. 특히, 애자일 12원칙 중 "최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다."라는 구절을 매우 좋아 한다. 창발은 팀의 원할한 소통에서 나올 수 있다. 그러므로, 소통이 없는 팀에서는 좋은 아키텍쳐가 나오기 어렵다.

 

아쉬운 부분은 절차에 대한 이야기가 있지만, 어떻게 구조적 결정을 해야 하는지에 대한 기술적인 방법(Technical Method)에 대해서는 설명이 없다는 것이다. 이러한 부분은 아직 Design Pattern, Architectural Style, Aspect Driven Design(ADD) 혹은 AD를 활용해야 하는 것인지도 모르겠다. 이 부분은 숙제로 남겨두고 고민해도 좋겠다.

 

참고 문헌

[1] Boyan Mihaylov, "Towards an Agile Software Architecture," https://www.infoq.com/articles/towards-agile-software-architecture/?p13nId=6817&p13nType=followTopic#