MSA 프로젝트 시 꼭 필요한 인력이 있나요?

MSA 프로젝트 시작 전 또는 PoC 때 항상 듣는 질문 중 하나다.

어떤 아키텍트들이 있어야 하고 그들의 역할이 무엇인지, 그러한 아키텍트들을 구할 수 있는지?

 

이미 예상하고 있겠지만 프로젝트 상황에 따라 모두 다르기에 정답은 없다. 준비된 아키텍트들이 기다리고 있는 경우는 당연히 없고(그 만큼 여기저기 잘 팔리기 때문), 이론만 또는 교육만 수강하고 실전 경험이 거의 없는 각 아키텍트들도 구하기 쉽지 않다. 아래 열거하는 역할자들이 모두 있으면 좋겠지만 그렇지 않다면 최소한 그러한 역할자를 지정하거나, TBD로 두고라도 시작하면 할일을 놓지지 않는데 도움이 될 것 같다.

 

 

위의 그림은 어떠한가? 이해하기 쉽지 않은가?

위의 그림을 먼저 설명하는 이유는 이미 알고 있는 개발조직 또는 역할자 이기 때문이다. 이를 바탕으로 MSA에서의 역할자를 생각하면 훨씬 이해가 빠를 것이다.

 

조직 마다, 도메인 마다 조금씩 다르긴 하지만 대략적으로 위와 같은 역할자가 필요하다는데는 동의할 것이다. 부르는 이름이 좀 다르거나 통합(겸직) 또는 세부화된 역할일 수 있지만 모두 필요하다. 이해했다면 각 역할자가 하는 일에 대해서도 큰 이견이 없을것이라 생각한다.

 

그러면 이러한 Monolith의 역할자를 바탕으로 MSA에서는 어떤 부분이, 어떤 역할자가 달라질까? 어떤 아키텍트가 추가될까? 역할이 늘어날까? 인원이 더 필요할까?

 

 

이전 Monolith 공정도에 분석단계의 ‘서비스 정의 워크샾’과 ‘기본설계’ 단계가 추가되었다.

그리고 AA(Application Architect) 또는 Modeler 라는 아키텍트가 추가되었다.

물론 MSA 이전에도 OOAD, CBD, MDD 등 특정 모델링 기법이나 도구를 활용하는 경우 모델러가 투입되기도 했지만 대부분의 그렇지 않은 프로젝트는 정보공학이나 익숙한 방법론으로 모델러 없이 진행하는 경우가 많았다. 아래 역할자들은 MSA에서 추가 고려해야할 부분을 중심으로 설명한다.

 

• PM
  기존 역할과 동일
• PL
  TOBE Microservice 담당 개발팀이 보통 파트별로 할당되고 그 파트리더는 Product Manager 또는 Scrum Master라고도 불리며 개발팀 리더 역할을 한다. 아래 설명하는 아키텍트들이 많은 경우 아키텍쳐를 담당할 별도의 PL을 두기도 한다.
• 응용총괄
  응용팀의 공통된 의견을 조율하여 고객 또는 아키텍쳐팀과 의사소통하는 역할을 하게되므로 MSA프로젝트에서 가이드, 교육, 협의 등을 위해 반드시 필요하다.
• QA
  MSA프로젝트의 품질 담당자라면 당연히 MSA에 대한 사전 지식이 필요하다. 어떤 Task와 산출물에 영향을 미치는지 알지 못하고 어떻게 품질을 체크하겠는가
• 분석설계자
  서비스정의 워크샾 부터 고객사 현업/IT와 함께 서비스를 식별, 검증, 정의해야하는 키맨으로 MSA 장단점을 잘 알고 제안/설득/설계 할 수 있어야 한다.
• 개발자
  분석설계자는 업무별로 구성하는게 맞겠지만 설계자는 업무별 보다는 개발 Layer별로 할당하는게 좋을 수 있다. UI, API, Publisher/Subscriber, Batch 등 프로그램 유형 별로 개발 기술이 많이 다르고 Learning Curve가 필요하므로 생산성을 위해 Layer별 개발팀 구성을 권장한다.
• Application Architect 또는 Modeler
  착수단계부터 QA와 함께 단계/Task/산출물/도구 협의 및 정의와 함께 MSA 관련 정의 기법 등에 대한 정의가 필요하다. 워크샾을 하게되는 경우 Facilitator 의 역할을 수행하고 MSA 관련 교육도 진행한다. 아울로 기본설계 및 상세성계 표준 수립, 가이드, 통합, 검토한다.
• UI Designer
  기존 역할과 동일
• Data Modeler
  논리 데이터 모델링 가이드
  기존에는 통합 데이터 모델링 관점이었다면 MSA에서는 Data Ownership을 고려한 서비스별 데이터 분산을 반드시 고려한 모델링이 필요하다. 특히, 반정규화나 데이터 정합성 측면
• SWA
  기존 역할 처럼 개발(코딩) 표준, 가이드, 통합, 검토의 역할 + MSA 에서의 Inner Archi, Outer Archi 측면도 함께 고려해야한다. 필요한 경우 Inner/Outer/CICD 등 세분화된 담당자를 고려해야한다. PoC까지 해야하는 경우에는 SWA 세분화가 반드시 필요하다. (한명이 병렬로 검증하기도 어렵고 각 주제별 깊이도 다르기 때문)
• TA (IA)
  Outer Architecture
  Cloud 설계/구축, 표준/가이드
  On-Premise, Public/Private Cloud, VM, Container 등의 장단점을 바탕으로 서비스별 특징에 맞춰 제안할 수 있어야 함
• DBA
  RDB, NoSQL, Cache, Search 등 서비스별 특징에 맞춰 DB를 제안/설계/구축/가이드 할 수 있어야 함
• 보안담당자
  기존 보안 요구사항 + Cloud 보안

 

Gartner의 MSA Component를 기준으로 역학자를 매핑해 보면 다음과 같다.

앞의 공정별 또는 Inner/Outer 측면의 역할자들이 모두 있으면 좋겠지만 그렇지 않다면 최소한 그러한 역할을 할 담당자를 별도로 지정하거나, TBD로 두고라도 시작해야 각 부분에서 해야할 일을 놓치지 않을 것이다.

제일 중요한 문제는 MSA를 위해 이와 같은 아키텍트, 전문가 몇 명이 투입된다고 MSA프로젝트가 절대 성공할 수 없음을 아는 것이 첫 걸음이다.