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

이 부분은 소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)[1]의 2장에 나온 내용을 정리한 것이다.

아키텍처와 설계

저자는 아키텍처와 설계를 비교 설명한다. 이를 수행하는 아키텍트와 개발자의 역할이 다음과 같다고 이야기 한다.

아키텍트는 아래 사항을 수행한다

1. "비즈니스 요구사항"을 분석하여 "아키텍처 특성(Architecture Characteristics, ~bilities ~성)"을 도출/정의하고
2. 어떤 "아키텍처 패턴"과 "아키텍처 스타일"이 해당 문제 영역에 적절한지 선택하여
3. 각종 "컴포넌트(시스템 구성 요소)"를 만든다.

개발자는 다음 역살을 수행한다.

1. 아키텍트의 수행 결과인 "아티팩트(artifact 산출물)"이 전달되면, 컴포넌트의 "클래스 다이어그램(상세 설계)"를 그린 뒤
2. "UI 화면"을 만들고
3. 소스 코드를 개발/테스트 한다.

이 부분에 대해서는 이견이 있을 수 있다. 상세 설계에 해당한다고 보이는 부분도 아키텍처에서 중요하다고 할 수 있는 품질 속성(Quality Attribute, 이 책에서는 아키텍처 특성이라고 하고 있다.)과 관련될 수 있고 이 부분이 아키텍처와 관련된 산출물에 포함되어 설명될 수 있기 때문이다. 이 책에서는 이러한 내용은 명시되어 있지는 않지만, 아키텍트와 개발자의 소통의 중요성을 이야기 하면서 언급되고 있다.

기술 폭(Technical Breadth)

아키텍트이든 개발자 이든 자신이 알고 있는 기술 세부의 범위는 한정적일 수 밖에 없다. 그렇다면, 아키텍트의 이 범위가 어떻게 될까? 책의 저자는 "내가 알고 있는 것", 내가 모른다는 사실을 아는 것" 그리고 "내가 모른다는 사실조차 모르는 것"으로 지식을 설명한다.

저자는 여기에서 지식의 깊이(Depth)와 폭(Breadth)를 구분하면서 개발자는 이 기술의 폭을 넓혀야 한다고 주장한다. 이 지식의 폭을 넓혀야 하는 이유 중에 하나가 다양한 분야에 전문성을 유지하려고 하면, 어느 하나에도 전문성을 충분히 확보하지 못할 수 있기 때문이다. 두 번째는 김빠진 전문성(stale expertise)이 나타나 자신은 첨단이라고 이야기 하지만, 실상은 낡은 정보만 가지고 있는 경우가 생긴다는 것이다.

정도의 차이는 있을 수 있으나 자신의 전문성을 가지고 다른 분야에도 얕지만 넓은 지식을 가지는 T자형 인재 혹은 제너럴라이징 스페셜리스트(Generalizing Specialist)[2]가 좋은 인재상으로 이야기 된다. 여기서도 깊이와 폭으로 이해될 수 있다. 마치 스펙트럼으로 살펴 보면, 한 분야의 깊이만 아주 깊은 학교의 교수, 전문가를 한쪽 끝으로 생각할 수도 있고 넓이만 아주 넓은 강연자, 이야기꾼을 반대쪽 한쪽 끝으로 생각할 수 있다. 경력이 높은 개발자와 경험이 많은 아키텍트는 모두 이 사이에 있을 것이고 개발자는 스페셜리스트에 이키텍트는 제너럴리스트에 가까울 수 있다. 하지만, 이키텍트들도 획일적으로 한 포인트에 머무르는 것이 아니고, 이 깊이와 폭이 가지각색인 것을 쉽게 예상할 수 있다.  

트레이드오프 분석

저자들은 아키텍처 사고(Architectural Thinking)의 요체를 다양한 솔루션과 기술 간의 트레이드오프를 이해하고, 분석하고, 조율하는 것이라고 한다. 책에서는 간단하지만 좋은 비교를 통해서 이 부분이 담고 있는 내용이 어떤 것인지 설명한다. 대표적인 소프트웨어 아키텍처 설계 방법인 속성 주도 설계(ADD, Attribute Driven Design)[3]에서는 품질 속성을 요구사항으로 도출해 내고 여기에 맞는 설계 전략 혹은 아키텍처 패턴/스타일을 적용[4]하는데, 여기에서 다루게 되는 것이 결국은 트레이드오프가 된다고 볼 수 있다.

책[1]에서는 경매 시스템을 구현할 때 컴포넌트 간의 연결을 Queue 혹은 Topic을 사용하였을 때, 트레이드오프에 대해서 논의 한다. 실재 설계할 때에는 접근 방법이 다르지만, 여기서는 우선 두 기술의 장점/단점을 비교하여 트레이드오프가 두드러지게 하였다.

Queue/Topic의 장단점 비교

실재로는 어떻게 될까? 여러 요인이 있겠지만 시스템의 품질 속성과 같은 여러 요소들에 따라 더 적절한 기술을 선택해 가는 것이 아키텍처 설계가 된다.

아키텍처와 코딩 실무 간의 균형 맞추기

이 책의 저자 뿐 아니라 다른 책의 저자들도 이야기 하지만, 아키텍트도 개발자로서 코딩 실무를 놓지 말아야 한다는 이야기를 많이 한다. 저자는 특히 이러한 균형을 맞추는 여러가지 방법을 제안하고 있고, 아주 실용적인 예들이기도 하다.

1. 개념 증명(Proof of Concept, PoC)를 주주 해보자
2. 개발팀이 아주 중요한 유저 스토리 작업을 할 수 있도록 기술 부채(Technical Debt) 스토리나 이키텍처 스토리에 전념한다.
3. 개발 이터레이션을 하는 도중에 버그를 잡는다.
4. 개발팀 일상 업무를 간소화 하거나 자동화 하는 간단한 커맨드라인 도구나 분석기를 만든다. 아키텍처 컴플라이언스 보장을 자동화 하는 피트니스 함수 측정기로 쓸 수 있는 아치유닛(ArchUnit)을 이용할 수 있다.
5. 자주 코드 리뷰를 한다.

4번 자주 하고 있는 것 중에 하나이다. 또한, 5번은 코드의 흐름을 놓치지 않을 수 있는 좋은 접근 방법이기도 하다.

참고 문서

[1] 마크 리처즈, 닐 포드, "소프트웨어 아키텍처 101 (Fundamentals of Software Architecture)", 한빛 미디어, 이일웅 옮김, 2021

[2] 위르헌 아펄로, "매니지먼트 3.0" 에이콘, 조승빈 옮김. 2019

[3] 렌 베스, 폴 클레멘츠, 릭 캐즈먼, "소프트웨어 아키텍처 이론과 실제, 개정 3판" 에이콘, 전병선 옮김, 2015 

[3] "Software Architecture: 어떻게 설계 할 것인가?," https://technical-leader.tistory.com/35