2022.08.03
조직 내부의 수많은 팩터들과 어떤 소프트웨어를 구축하는지에 따라 맥락이 달라지므로 아키텍처 특성, 도메인 고려 사항, 전략적 목표, 그 밖의 다양한 것들의 트레이드오프를 고려하고 분석한 마지막 결과로 아키텍처 스 타일을 선택하는 것이다.
사람들이 좋아하는 아키텍처 스타일은 여러 가지 팩터들로 인해 그때그떄 계속 변한다.
새로운 아키텍처 설계는 과거 아키텍처 스타일에서 발견된 결함이 반영된 경우가 많다. 예를 들어, 예전에 코드 재사용을 강점으로 내세운 아키텍처 될 수 있게 한 양분이기도 하다. 새로운 아키텍처 설계는 과거 아키텍처 스타일에서 발견된 를 구축했을 때 그 단점을 경험한 아키텍트는 코드 재사용에 함축된 의미를 진지하게 고민할 것이다.
끊임없는 변화는 소프트웨어 개발 생태계의 바람직한 특성이다. 시간에 따라 불변인 것은 하나도 없다. 생태계의 변화는 매우 무질서해서 어떤 종류의 변화가 닥칠지 예측조차 힘들다. 예를 들어, 수년 전만 해도 쿠버네티스가 무엇인지 거의 아무도 몰랐지만 지금은 전 세계 수천 명 개발자가 참석하는 콘퍼런스도 여럿 개최되고 있다. 하지만 이런 쿠버네티스조차 어쩌면 수년 후에는 아직 개발 중인 다른 도구에 의해 대체될지 모른다.
새로운 기능이 출현하면 아키텍처는 단순히 어떤 도구를 다른 도구로 대체하는 정도가 아닌, 완전히 새로운 패러다임으로 전환될 수 있다. 예를 들어, 과거 아키텍트나 개발자는 도커 같은 컨테이너가 혜성처럼 등장해서 소프트웨어 개발 전반을 뒤흔들 줄은 아마 상상도 못했을 것이다. 생태계가 지속적인 변화하면서 새로운 도구와 기능들 역시 수시로 등장한다. 아키텍트는 새로운 도구는 물론 새로운 패러다임 역시 예의주시해야 한다. 이미 갖고 있지만 뭔가 새롭게 보이는 것들도 있고, 묘한 뉘앙스 를 품고 있거나 장차 게임 체인저(game changer)가 될 만한 변경 사항이 있을지도 모른다. 모든 신기능이 전체 개발 세계를 뒤흔들 정도로 거창하진 않겠지만, 작은 변화라도 아키텍트의 목표와 정확히 부합하는 변경일 수도 있다.
생태계는 끊임없이 변할 뿐만 아니라 그 변화의 속도도 계속 빨라지고 있다. 새로운 도구는 새로운 엔지니어링 프랙티스를 창출하고 이는 다시 새로운 설계와 기능으로 이어진다. 변화는 도처에서 꾸준하게 일어나므로 아키텍트는 일정한 흐름(flux)의 상태에서 살아가는 셈이다.
비즈니스가 계속 진화하고 타 회사와 합병되면서 개발자가 소프트웨어를 개발하는 도메인 역시 도통 가만히 있는 법이 없다.
기술이 진화할수록 조직은 최소한 그 변화의 흐름의 일부라도 (특히 그것이 분명하고 중요한 이익을 가져올 때) 따라잡으려고 한다.
소프트웨어 개발과 연관된 많은 주변 요인들이 조직의 변화를 가져오는 경우도 있다. 예를 들어, 아키텍트와 개발자 모두 완벽하게 만족하는 도구가 있는데 라이선스 비용이 너무 비싼 까닭에 어쩔 수 없이 다른 도구를 알아봐야 하는 경우가 그렇다.
현재 유행하는 아키텍처 관점에서 조직이 어느 위치에 있든 아키텍트는 업계 동향을 잘 파악해 서 유행을 따르고 예외를 두어야 하는 경우를 현명하게 잘 결정해야 한다.
아키텍트는 아키텍처 스타일을 선택할 때 도메인 설계 구조의 원인이 될 만한 모든 요소를 종합적으로 고려해야 한다. 기본적으로 아키텍트는 주어진 도메인, 그리고 시스템을 성공적으로 구축하는 데 필요한 다른 모든 구조적 요소들을 설계한다.
아키텍트는 도메인에서 중요한 여러 가지 양상, 특히 어느 부분이 운영 아키텍처 특성에 영향을 미치는지 파악해야 한다. 아키텍트가 꼭 해당 분야의 전문가일 필요는 없지만, 자신이 설계하는 도메인에서 중요한 파트에 대해서 최소한의 지식은 갖고 있어야 한다.
아키텍처 아키텍트와 DBA는 서로 머리를 맞대고 데이터베이스 스키마 등 데이터에 관한 문제를 의논해야 한다. 신규 시스템이 이전에 그리고(또는) 현재 사용 중인 데이터 아키텍처와 상호작용할 경우, 아키텍트는 반드시 데이터 설계가 아키텍처 설계에 미치는 영향도를 미리 파악해야 한다.
갖가지 외부 패터들도 설계에 영향을 준다. 예를 들어, 특정 클라우드 벤더사의 이용료가 이상적인 설계를 가로막는 장애물이 되거나, 회사가 인수 합병에 참여할 계획을 수립하여 개방형 솔루션과 통합 아키텍처에 무게를 둘 수밖에 없는 경우 등이 있다.
소프트웨어 개발 프로세스, 운영팀과의 소통(또는 그런 소통의 결핍), QA 프로세스 등 프로젝트와 관련된 다양한 팩터들도 아키텍처 설계에 영향을 끼친다. 예를 들어, 애자일 성숙도가 결여된 조직에서 애자일에 기반한 엔지니어링 프랙티스에 의존하는 아키텍처 스타일을 도 입하면 시작부터 난관에 부딪힐 것이다.
아키텍처의 토폴로지와 잘 맞는 문제 영역이 있다. 예를 들어, 마이크로커널 아키텍처 스타일은 아키텍처적으로 플러그인 형태의 커스터마이징이 가능하므로 맞춤성이 필요한 시스템과 완벽하게 잘 어울린다.
반대로, 문제 영역과 아키텍처 스타일이 불협화음이 나는 경우도 있다. 예를 들어, 규모가 큰 모놀리식 구조로는 확장성이 우수한 시스템을 설계하기가 어렵다. 코드베이스의 커플링이 심한데 다수의 동시 유저를 지원하는 것은 무리이다. 의미적으로 커플링된 곳이 도처에 널려 있는 문제 영역도 고도로 분리된 분산 아키텍처와 안 맞다. 가령. 각 페이지가 이전 페이지의 콘텍스트에 따라 작동되는 멀티페이지 형태의 보험 회사 웹 애플리케이션을 마이크로서비스로 모델링하기는 어렵다. 이렇게 커플링이 높은 문제 영역은 서비스 기반 아키텍 처처럼 커플링 정도가 낮은 아키텍처가 적합한데, 억지로 잘 맞지도 않은 분산 아키텍처로 설 계하면 갖가지 설계 난제에 맞닥뜨리게 될 것이다.
아키텍트는 아키텍처 퀀텀 개념을 이용하여 단일 아키텍처 특성만으로도 설계에 부족함이 없는지, 아니면 시스템 파트별로 상이한 아키텍처 특성이 필요한지 판단해야 한다. 전자의 경우 (다른 팩터들 때문에 결국 분산 아키텍처로 굳어질 수 있지만) 모놀리스가 적합하다는 뜻이고, 후자의 경우 분산 아키텍처가 정답에 가깝다.
일반적으로 모놀리식 아키텍처는 하나 또는 소수의 관계형 데이터베이스를 전제로 하지만, 분산 아키텍처에서는 아키텍트가 어느 서비스가 어떤 데이터를 저장할지 결정해야 합니다. 즉, 워크플로를 구축하기 전에 전체 아키텍처의 데이터 흐름에 대해 충분히 숙고해야 한다.
데이터를 어떻게 분할할지 정한 다음에는 서비스 간 통신 방식을 동기로 할지, 비동기로 할지 결정해야 합니다. 동기 통신은 대부분 더 간편하긴 하지만 확장성, 안정성, 그 밖의 다른 아키텍처 특성에 부정적인 영향을 미칠 수 있다. 비동기 통신은 성능, 확장성 측면에서 우월하나, 데이터 동기화, 데드락, 경합 조건, 디버깅 등 골칫거리가 많다.
아키텍트는 가급적 설계, 구현, 디버깅 문제가 적은 동기 통신을 기본으로 하되, 필요한 경우에 비동기 통신을 함께 사용하는 것이 좋다.
동기 통신을 기본으로 사용하고 필요시 비동기 통신을 사용하세요