아키텍트에 대한 생각 (+MSA 유행에 대한 생각)

　최근에 아키텍트 교육을 받았다. 나름 리프레쉬가 되긴하는데 업무랑 병행하면서 좀 큰 교육을 받으려다보니 쉽지않았다. 그래도 교육을 듣고나서는 아키텍트에 대해서 막연하게 생각하던 내용들이 다소 정리가 되는 느낌이 들었다.

🏗 아키텍트?

　”아키텍트가 하는 일이 어떤것이냐”고 물었을때 답변이 조금씩 다른 것 같다. 누군가는 단어를 직역해서 설계를 하는사람이라고하고, 큰 그림을 그리는 사람이라며 추상적으로 답하는 사람도 있다. 이러나 저라나 아키텍트들이 추구하는 이념과 학문은 SW공학(Engineering)이다. 얼핏 학부시절 기억 속의 교수님께서는 “공학이라고 불리기에는 상대적으로 짧은 역사를 가졌다”며, “비슷한 개념을 찾다보니 건축에서 아이디어를 많이 가져왔으나 사실 건축이랑은 많이 다르다”고 하셨었다.

　아키텍트라는 단어를 들을때마다 저 말이 생각난다. 이 얘기를 들은 것도 거진 10년전이니 아직도 같은 생각이실지는 모르겠다. 어찌됐건 소수의 설계자가 큰 그림을 그리고 다수의 구현자들이 실체를 구현한다는 점에서 ‘아키텍트’란 표현은 직관적이다. 비즈니스 혹은 도메인과 개발사이의 위치함으로서, 시스템 이해관계자(System Stakeholder)의 요구조건들을 잘 정리해서 큰 그림을 그리는 역할을 한다.

👷‍♂️ Enterprise / Solution / Technical Architect

　많은 기업들이 클라우드를 시작하면서 최근에는 메가트랜드에 이르게되었다. 때문에 지금 시장에서는 아키텍트에 대하여 기대하는 역할들이 정해져있을 것 같다는 생각에, 아키텍트에 대한 전반적인 개념을 좀 찾아봤다.

• Technical Architect: 기술 구현단에서 활약하는 아키텍트이다. 기능과 기술에 대한 실질적인 접근방식을 고민한다.
• Solution Architect: 비즈니스 요구사항을 고민하고 제품과 서비스로 표현한다. 개념의 정의서부터 릴리즈에 이르기까지 연속적인 활동을 통해 제품을 관리한다.
• Enterprise Architect: Enterprise 라는 단어의 쓰임에 걸맞게 조직 또는 기업 전체의 정합성과 일관성을 검토한다.

　사실 각자의 역할에 대해서는 어렴풋이 느낌만 온다. 추상화 수준에 따라 분류한 수준이라고 생각이 드는데 현장에서는 TA와 SA의 경계가 모호할 것 같다. 특히 Solution Architect와 Proejct Manager는 분명히 다르지만 조직문화에 따라 두개 역할을 겸직하는 경우가 빈번할 것 같다(…) 이건 차차 경험이 쌓였을때 다시금 정리할 시간을 가지면 좋겠다.

🚢 MSA에 소극적인 견해들

　요샌 MSA와 같은 좀 더 유기적인 구조로 어플리케이션을 구성하면서 높은 가용성에 큰 가치를 두는 아키텍쳐가 유행이다. 하지만 글자그대로 ‘유행’이라, 아무래도 MSA에 대한 생각과 이견들이 많다. 교육간에 모 교수님께서는 클라우드 제공사들이 홈페이지에서 안내하는 패턴들에 대해서 의구심을 가지셨었는데, 실질적으로 현장에 적용되었을때 이게 제대로 적용이 될런지는 좀 더 고민을 해봐야하는 것 같다고 하셨다.

　데이터의 이동과 기능의 연계가 네트워크에 의존하다보니 데이터 정합성과 안정적인 환경에 대하여 특히 많은 고민이 필요하다는 점을 이유로 꼽으시며, “MSA는 결국 저품질로 개발하게한다. 앞으로 몇년간 큰 사고가 안나는지 지켜봐야한다”며 이 유행에 대하여 조심스러운 접근이 필요하다는 견해를 말씀주셨었다.

　지난 11월 15일, 전 Github의 CTO인 Jason Warner는 ‘지난 십년간 아키텍처적인 가장 큰 실수는 full-microserve 로 만든것’이라며 트윗을 올렸다. 그렇게 생각하는 이유에 대하여 아래와 같이 나열했다. 다소 의역을 섞었다.

A. 일반적으로 그 어떤 엔지니어링 팀들도 각각의 마이크로서비스들이 어떤 문제가 생길지 유추하는거보다, 하나의 큰 앱(가령 모든 사이트가 레일즈앱에 있는 경우)으로 작업하는 것을 더 쉬워한다.

B. 어쨌거나 규모가 커지게 되는 분산시스템에서는 각각이 리스크-프로필이 있는 수백개의 마이크로서비스들은 말할 것도 없고, 그 많은 마이크로서비스를 적용시키는 것을 충분히 추론하기 어렵다.

C. 만약 Fully-MSA로 아키를 짤생각이라면, 그러한 규모가 커지는 것에 대해서 제어할 수 있는 새로운 컨셉을 도입해야한다.

D. (이게 크다) 각각의 맞춤형 인프라 서비스 혹은 마이크로서비스는 IMV 부채의 가장 극단적인 버전이다. 코드는 부채인데, 서비스는 그보다 더 한 버전이다. 이게 뭔 뜻인지 생각해봐라. 이런 부채가 문자 그대로 '썩 가지고 싶지않은' 높은 레버리지(highest leverage)가 되려고 한다.

1. 모놀리식을 최대한 오랫동안 유지해라

2. 서비스는 앱단에서 시작하지말고 인프라 단에서 필요한 것으로부터 시작해라.

3. 모놀리식을 쪼개야한다면, 작게말고 크게 쪼개라.

4. 각 새로운 앱은 네 회사의 가상의 벽을 만드는 것이라고 생각해라.

5. 마이크로서비스보다 라이브러리를 선호해라.

😎 아키텍트의 역할…

　저 트윗의 요는 앱을 개발 및 유지보수 하는데 가장 중요한건 커뮤니케이션이라는 점에서 무지성으로 서비스 쪼개지 말자는게 포인트같다. MSA 책쓴 샘 뉴먼 아저씨도 특정 아키텍처가 은탄환이 될 수 없다고 했다. 이러한 맥락에서 사장됐었던 SOA가 슬금슬금 올라오는 것 같기도 하고…. 이러나 저러나 아키텍트는 이해관계자의 요구사항을 명세하여, 동료와의 원활한 커뮤니케이션을 할 수 있도록 환경을 구축하고, 공동의 목표를 달성하기위해 지속적으로 기획하고 조율하는 것이 그들의 역할인 것 같다.

참조

• https://www.coursera.org/articles/solutions-architect
• http://yr-architecture.com/difference-between-an-architect-designer-drafter/

2022 ⓒ ChillyMind