아키텍처는 의사소통에 관한 문제다
MSA 기술과 적용 연구 9
DDD 보급의 리더격인 Vaughn Vernon의 링크드인 최근 글이다.
그는 말한다. 아키텍처의 핵심 요소는 의사소통이다. 나 역시 비슷한 취지의 글을 하두 많이 써서 오늘은 범위를 조금 좁혀서 얘기를 해보려고 한다.
4+1 아키텍처 뷰를 떠올리다
20년쯤 전에 UML을 한참 공부하고 활용할 때, UML을 만들고 유지하던 Rational 소속의 Philippe Kruchten이 쓴 <Architectural Blueprints—The “4+1” View Model of Software Architecture> 문서를 읽는 일은 꼭 필요한 일이었다. 아키텍처 청사진을 그릴 때 사용하라며 5가지 관점(view)로 아키텍처를 보라는 것이다. 그 가운데 Use Case 즉 쓰임새가 있다. 응용 프로그램을 위해서는 당연한 일이지만, 그 당시만 해도 기능을 분할하며 개발하는 일이 당연하게 우선시되었다. 지금도 훈련을 받지 않은 개발자는 기본적으로 기능 중심으로 사고하고 개발한다.
Rational은 UML 그리는 도구로 Rose라는 제품을 내놓았고, 확하게 1:1 대응으로 보기 어렵지만 최상단 디렉토리(폴더)에는 4+1View를 채택했다. 다만 이름이 조금 바뀌었다. Scenarios 대신에 Use Case View가 있었고, Development View 대신에 Component View가 있고, Deployment View 대신에 Physical View가 있었다. Process View는 없었다.
아키텍처 뷰를 바꾸고 싶은데
Rose는 이를 지원하지 않았다. View는 단순히 관점을 마음대로 그리라는 디렉토리가 아니다. Rose는 모델링 도구이기 때문에 그 하위 요소들에 대한 정의가 마련되어 있었는데, 내가 View를 정하려면 그런 구성요소를 체계적으로 정의해서 집어 넣어야 했다. 외산도구인 Rose가 그걸 지원할 리는 없고, 결국 Logical View 하위에 실질적인 View 구분을 다시 두어 원하는 방식으로 모델링을 하곤 했다.
나는 그때 내가 쓰던 방식을 Domain-Driven 이라고 생각한다. DDD 책이 나오기 이전이니까 책과는 무관하다. 실제 참여자와 참여자가 정하는 문제가 주도한다는 뜻이다. 4+1 중에 필수는 Data Model 이었고, 개발자들은 클래스 다이어그램 형태로 그리는 ERD에 거부감이 없었다. 그러나 프로젝트에 데이터 컨설팅 기업이 낀 경우는 상당히 거부감을 드러냈고, 대체로 애써 무시하려는 듯이 보이기도 했다. 하지만 클래스도를 열심히 그리고 데이터와 연결을 고려하지 않으면 모델링 과정에서 만들어내는 수많은 규칙이 모두 소실된다. 그리고 개발할 때 다시 논의되거나 개발자에게 맞겨지곤 했다.
그럴꺼라면 왜 UML을 써서 복잡하게 모델을 그리는가?
사업관리 관행과 검수 방식이 가로막은 의사소통
돌아보면 외주 개발은 그렇게 수명을 줄여(?)왔다. 나의 질문은 무시되었고, 그 배경에는 사업관리 관행이 있었다. 대규모 프로젝트를 주도하는 SI(System Integration) 업체의 분석가들은 UML 모델만 그리고 협업업체 개발자들이 와서 개발하는데, 그들은 UML을 배우거나 써본 일이 없다. 그런데 명분상으로는 그들이 볼 UML 설계서를 그리고, 실제로는 검수를 위해 프로그램 개발과는 아무 관련없는 고객사 품질 담당자가 판단한다.
나는 UML을 익히고 올바르게(?) 쓰는데 5년 가까운 시간을 보냈지만, 사회적 가치 생산을 위해서 빠르게 손절했다. 그만큼 당시 우리환경에서 UML은 그저 시도에 그치지 않았고, 중요한 의미가 담기기에는 지금 와서 돌아보니 더 긴 시간이 필요했다. 산업 초기였던 것이다.
아키텍처 관점으로 보는 MSA
사실 이 글을 쓰는 동기가 두 개인데, 하나는 앞서 말한 Vaughn Vernon의 관점이고, 두 번째는 <아키텍처 그림 가운데 있는 데이터> 편이다. 개발자 입장에서도 MSA를 보는 관점은 명확하게 일치하지 않는다. 그런데 MSA를 윗분(?)기 결정해서 적용하라고 하는 기업들도 상당하다는 점을 확인했다.
그래서 4+1 뷰를 둘러싼 옛 추억을 떠올려 MSA를 바라보는 다양한 시각을 간단히 그려낼 수 있다는 생각을 했다. 최근에 내가 그린 그림으로 예시를 들면 실전적이고 자연스러울 수 있겠다. 먼저 아주 최근에 그린 그림을 보자. 전형적인 아키텍처 구성도와는 거리가 멀지만 주요 정보(혹은 엔티티)의 상태 변화에 따라 사용자와 상호작용이 어떻게 되며, 업무 환경에서 프로세스는 어떻게 되는지를 보여주는 그림이다.
이 그림도 3개의 주요한 이해관계자 유형의 관점(Viewpoint)을 드러낸다. 하나는 당연히 개발자이고, 두 번째는 서비스 기획자 혹은 UX 담당자이며, 나머지는 업무 서비스 담당자(기획자 혹은 운영자)이다.
또 다른 예는 아래와 같은 식이다. MSA 환경에서 특정 업무 환경 혹은 주요 화면 타입에 대한 개념도인데 아키텍처 표현의 예로도 사용할 만하다.
여기서는 주로 개발자와 기획(운영)자 두 이해관계자의 관심사만 표현했다. 하지만, 다른 조직에서 하나의 서비스를 이용하는 맥락을 보여준다는 점에서는 구체적으로 파고들면 제휴 담당자나 IT 관리자 입장을 포착할 수도 있다.
시스템 소통의 전문가로서의 아키텍트
예전에 <모던 아키텍트>란 표현으로 글을 쓴 일이 있다. 그리고 <트레이드오프와 아키텍트 그리고 개발자의 소통 문제>편에서 상충관계를 해소하는데 아키텍트가 중요한 역할을 해야 한다 주장한 바 있다. 비즈니스 복잡도가 높아지는 현실에서 시스템 전반에 대해 다양한 관점으로 해설할 수 있는 역할을 하는 누군가는 굉장히 중요하다. 과거에 쓰인 서적의 아키텍트의 역할과는 꽤 다른 변화한 현실에 필요한 아키텍트가 필요하다. 시스템 소통 전문가 말이다.
MSA 기술과 적용 연구 시리즈
