[소프트웨어 아키텍처 101] 챕터 1. 서론

1.1 소프트웨어 아키텍처란?

소프트웨어 아키텍처는 아키텍처 특성, 아키텍처 결정, 설계 원칙, 시스템의 구조로 구성된다.

시스템의 구조란 시스템이 구현된 (마이크로서비스, 레이어드, 마이크로커널 같은) 아키텍처 스타일들의 종류를 말한다. 시스템의 아키텍처를 완전히 이해하려면 아키텍처 특성, 아키텍처 결정, 설계 원칙도 알아야 한다.

아키텍처 특성은 소프트웨어 아키텍처를 다른 관점에서 바라본 것으로, 일반적으로 시스템의 기능과 직교하는 시스팀템의 성공 기준을 결정한다. 아래와 같은 특성이 시스템 기능에 관한 지식을 필요로 하는 것은 아니지만, 시스템이 올바르게 동작하기 위해서는 반드시 필요하다.

• 가용성
• 신뢰성
• 시험성
• 확장성
• 보안
• 민첩성
• 내고장성
• 탄력성
• 복구성
• 성능
• 배포성
• 학습성

아키텍처 결정은 시스템 구축에 필요한 규칙들을 정한 것이다.

가령, 아키텍트가 레이어드 아키텍처에서는 프레젠테이션 레이어가 데이터베이스를 직접 호출하지 못하게 비지니스와 서비스 레이어에서만 데이터베이스에 액세스할 수 있다고 결정하는 식이다. 아키텍처 결정은 시스템의 제약조건을 형성하며, 개발자가 해도 되는 것과 하지말아야 할 것을 알려준다.

어떤 상황 또는 제약 조건으로 아키텍처 결정을 구현할 수 없다면 변형이라는 것을 통해 깨트릴 수 있다.

아키텍처 결정에 대한 에외는 아키텍처 심사 위원회 혹은 최고 아키텍트가 검토하여 근거와 트레이드오프를 고려한 뒤 승인/거부한다.

설계 원칙은 가이드라인이다.

서비스 간의 통신은 비동기 메시징을 활용해야 한다는 설계 원칙이 있을 때,

모든 조건과 구현 방안을 아키텍처 결정으로 다룰 수는 없기에 특정 환경에서 개발자가 더 적합한 선택을 할 수 있도록 우선 권장하는 방법에 관한 가이드를 설계 원칙으로 제공하는 것이다.

1.2 아키텍트에 대한 기대치

역할, 직책, 직무에 상관없이 소프트웨어 아키텍트에게 바라는 핵심적인 요구사항은 다음 여덟가지로 정리할 수 있다.

• 아키텍처 결정을 내린다.
• 아키텍처를 지속적으로 분석한다.
• 최신 트렌드를 계속 유지한다.
• 아키텍처 결정의 컴플라이언스를 보장한다.
• 다양한 기술과 경험에 노출된다.
• 비지니스 도메인 지식을 보유한다.
• 대인 관계 기술이 뛰어나다.
• 정치를 이해하고 처세를 잘한다.

1.2.1 아키텍처 결정을 내린다

아키텍트는 아키텍처와 설계 원칙을 결정하고 팀, 부서뿐만 아니라 회사 전체의 기술 결정을 가이드하는 사람이다.

첫 번째 요구사항의 키워드는 가이드이다. 아키텍트는 기술 선택을 가이드하는 사람이지, 정해주는 사람이 아니다.

효과적인 아키텍처 결정을 하려면 아키텍트 자신이 내린 결정이 개발팀 스스로 옳은 기술 결정을 하도록 가이드하는 데 도움이 되는지, 아니면 개발팀을 위해 기술을 대신 선택해주는 게 더 나을지 자문해봐야 한다.

1.2.2 아키텍처를 지속적으로 분석한다

아키텍트는 끊임없이 아키텍처와 현재 기술 환경을 분석하고 이를 개선하기 위한 해결 방안을 제시한다.

이를테면, 3년 전에 정의한 아키텍처가 지금도 얼마나 현실성 있는지 평가하는 아키텍처 역동성(vitality)에 관한 요구사항이다.

아키텍트는 기술 변화와 문제 영역을 종합적으로 분석하여 아키텍처의 건전성을 추구해야 한다. 아키텍트라면 애플리케이션을 계속 적절하게 유지할 수 있는 능력을 갖고 있어야 한다.

1.2.3 최신 트렌드를 계속 따라간다.

아키텍트는 항상 최신 기술과 업게 트렌드를 따라가야 한다.

개발자는 자신이 매일 사용하는 기술을 항상 갈고 닦아 최신 상태로 유지해야 계속 일을 할 수 있다.

아키텍트가 결정한 것들은 대개 오래 지속되고 바꾸기도 어렵습니다. 핵심 트렌드를 이해하고 계속 쫓아갈 수 있어야 미래를 대비하고 올바른 결정을 내릴 수 있습니다.

1.2.4 아키텍처 결정의 컴플라이언스를 보장한다

아키텍트는 아키텍처 결정과 설계 원칙의 컴플라이언스를 보장해야 한다.

컴플라이언스 보장이란, 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙을 개발팀이 제대로 준수하고 있는지 지속적으로 확인한다는 뜻이다.

1.2.5 다양한 기술과 경험에 노출된다

아키텍트는 다양한 기술, 프레임워크, 플랫폼, 환경에 노출되어야 한다.

아키텍트가 모든 프레임워크, 플랫폼, 언어를 통달해야 할 필요는 없지만, 적어도 다양한 기술을 거리낌없이 쓸 줄은 알아야 한다. 요즘 환경은 대부분 복합적인 경우가 많아서 아키텍트라면 최소한 시스템이나 서비스가 어떤 언어와 플랫폼, 기술로 개발되었든지 다양한 시스템과 서비스를 연동하는 방법은 알고 있어야 한다.

유능한 아키텍트는 여러 가지 언어, 플랫폼, 기술을 경험할 기회를 적극적으로 모색하면서 기술의 깊이보다는 폭에 초점을 둔다. 여기서 기술 폭이란, 아주 자세히는 몰라도 본인이 잘 알고 있는 것과 연관 지어 알고 있는 것들을 말한다. 예를 들어, 한 가지 캐시 제품에 정통한 전문가가 되려고 하기보다는 10가지 캐시 제품을 어느 정도 다룰 줄 알고 각각의 장단점을 아는 게 더 중요하다.

1.2.6 정치를 이해하고 처세를 잘한다

아키텍트는 어느 수준 이상의 비지니스 도메인 전문가여야 한다.

유능한 소프트웨어 아키텍트는 기술은 물론이고 문제 영역의 비지니스 도메인도 잘 알고 있다. 비지니스 도메인 지식이 없으면 비지니스의 문제점, 목표, 요구 사항을 이해하기 어렵고, 따라서 비지니스 요구사항을 수용할 만한 효율적인 아키텍처를 설계하기도 어렵다.

1.2.7 대인 관계 기술이 뛰어나다.

아키텍트는 팀워크, 조정, 리더십을 포함한 대인 관계 기술이 뛰어나야 한다.

아키텍트는 개발팀을 기술적으로 이끌기만 하는 사람이 아니라, 개발팀을 리드해서 아키텍처를 구현하는 사람이므로 아키텍트라는 직책 또는 역할과 상관없이, 리더십 스킬은 소프트웨어 아키텍트로서 성공하기 위해 필수 요구 사항의 최소한 절반 이상은 차지한다.

강력한 리더십과 대인 관계 스킬은 자신을 다른 아키텍트와 차별화하는 유리한 강점이다.

1.2.8 정치를 이해하고 처세를 잘한다

아키텍트는 기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야 한다.

아키텍트가 내린 거의 모든 결정은 사람들의 반발에 부딪히게 마련이다. 아키텍처 결정을 실천하려면 당연히 시간과 비용이 들여야 하므로 제품 오너, 프로젝트 관리자, 비지니스 이해 담당자들의 뭇매를 맞게 될 수 밖에 없다. 또, 자기들의 방식이 더 낫다고 주장하는 개발자들의 공격도 피할 수 없다. 그래도 아키텍트는 회사에서 정치를 잘하면서 대부분의 결정을 사람들이 수용하도록 기본적인 협상 기술을 발휘해야 한다.

최종적으로 폭넓고 중요한 결정을 내리는 아키텍트 수준에 이르면 거의 모든 결정을 정당화하고 반대 세력에 맞서 싸울 준비를 갖추어야 한다.

1.3 아키텍처의 교차점 그리고...

1.3.1 엔지니어링 프랙티스

지난 몇 년 동안 엔지니어링 분야가 발전을 거듭했고 사람들은 소프트웨어 아키텍처의 프로세스 문제를 진지하게 고민했다.

여기서 엔지니어링 프랙티스와 소프트웨어 개발 프로세스는 구분해야 한다.

프로세스는 팀을 어떻게 구성하고 관리할지, 회의는 어떻게 하고 워크플로 조직은 어떻게 운영할지 등 사람을 조직하고 상호작용하는 총체적인 기법이다. 반면, 엔지니어링 프랙티스는 프로세스와 무관하게 가시적이고 반복 가능한 혜택을 주는 실천론이다. 예컨대, 지속적 통합(CI)은 특정 프로세스에 의존하지 않는 검증된 엔지니어링 프랙티스이다.

소프트웨어 개발의 아킬레스 건 중 하나는 추정(Estimation)이다. 얼마나 오래 걸리고, 얼마나 많은 리소스가 필요하고, 얼마나 많은 비용이 들어갈지 내다봐야 한다. 사람들은 원래 추정을 하는 데에 서툴기도 하고, 알려지지 않은 미지의 것들때문에 더 어렵다.

알려지지 않은 미지의 것들은 소프트웨어 시스템에서 필연이다. 프로젝트는 아무도 몰랐던 것들이 갑자기 불쑥 튀어나와 미궁에 빠지기 쉽다. 아키텍트는 알려지지 않은 미지의 것들을 설계할 수 없기 때문에 빅 디자인 업 프런트(Big Design Up Front, 일단 설계부터 확실하게!)방식으로 진행하기 어렵다.

아키텍트는 프로젝트 기술 리더를 겸하는 경우도 많기에 팀의 엔지니어링 프랙티스를 결정한다. 아키텍처를 선정하기 전에 문제 영역을 주의 깊게 살펴보는 것처럼 아키텍트는 아키텍처 스타일과 엔지니어링 프랙티스가 공생 관계망을 형성하도록 해야 한다.

1.3.2 프로세스

오랫동안 많은 기업들은 소프트웨어 개발과 운영은 별도 기능이라고 생각하여 비용 절감 차원에서 외주를 맡기는 경우가 많았다.

아키텍트는 운영을 외주화하여 비용을 줄이는 과정에서 비롯된 제약 때문에 어쩔 수 없이 방어적으로 설계할 수 밖에 없었고, 확장, 성능, 탄력성, 그 밖의 기능들을 내부적으로 처리할 수 있는 아키텍처를 구축하게 된 것이다.

그 대가로 아키텍처가 매우 복잡해지는 부작용이 생겼다.

마이크로서비스 아키텍처 스타일은 정립한 아키텍트들은 운영 관심사는 운영으로 처리해야 더 매끄럽다는 사실을 깨닫았습니다.

아키텍처와 운영 간에 연결고리를 맺어 설계를 단순화하고, 운영자가 가장 잘 처리할 수 있는 부분은 운영에 맡기게 됐습니다.

그 과정에서 아키텍트와 운영자는 리소스를 남용하면 뜻밖의 난관에 빠지게 된다는 사실을 깨닫고 서로 의기투합하여 마이크로서비스를 만들었다.

1.3.3 프로세스

소프트웨어 아키텍처는 소프트웨어 개발 프로세스에 거의 직교적이라는 공리가 있다.

프로세스는 소프트 웨어 아키텍처(구조)에 별다른 영향을 끼치지 않는다. 개발팀이 사용하는 소프트웨어 개발 프로세스가 소프트웨어 아키텍처에 (특히 엔지니어링 프랙티스 위주로) 일부 영향을 끼칠 수는 있지만, 역사적으로 이 둘은 거의 별개라고 간주되었다.

애자일 프로젝트를 하는 아키텍트는 반복적인 개발을 통해 의사 결정에 필요한 피드백을 더 빨리 받아보리라 기대할 수 있고 피드벡에 의존하는 실험과 다른 지식에 더욱 적극적으로 참여할 수 있다.

재구성(restructurging)은 애자일 방법론의 진면목을 볼 수 있는 중요한 아키텍처 분야 중 하나이다. 팀은 종종 아키텍처를 어떤 패턴에서 다른 패턴으로 바꾸어야 할 필요성을 깨닫는다.

예를 들어, 알기 쉽고 빨리 착수 가능한 모놀리식 아키텍처로 시작했지만 이제는 더 현대적인 아키텍처로 이동해야 한다고 생각하는 것이다.

애자일 방법론은 피드백 루프가 더 촘촘하고 스트랭글러 패턴, 기능 토글 등의 기법 덕분에 기획만 가득한 프로세스보다 이런 종류의 변경이 더 잘 지원된다.

1.3.4 데이터

많은 소프트웨어 아키텍처 도서는 외부 데이터 스토리지를 너무 가볍게 다루는 경향이 있다.

코드와 데이터는 공생 관계여서 상대방이 없으면 무용지물이다.

데이터베이스 관리자는 아키텍트와 협업하여 복잡한 시스템의 데이터 아키텍처를 구축하며, 관계 및 재사용이 애플리케이션의 포트폴리오에 어떤 영향을 미치는지 분석한다.

1.4 소프트웨어 아키텍처 법칙

소프트웨어 아키텍처의 범위는 거의 무한에 가까울 정도로 광할하지만 이 모든 것을 통합하는 요소는 존재한다.

다음은 우리가 소프트 웨어 아키텍처의 시행착오를 셀 수 없이 거치면서 배운 소프트웨어 아키텍처 제 1법칙이다.

소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.

만약, 아키텍트가 트레이드 오프가 아닌 뭔가를 발견했다고 생각했다면 그것은 아직 트레이드오프를 발견하지 못했다는 증거일 가능성이 높다.

우리는 원칙, 특성 등을 포함한 구조적 요소들을 초월한 용어로써 소프트웨어 아키텍처를 정의한다. 아키텍처는 이러한 구조적 요소들을 단순히 합쳐 놓은 것보다 더 넓은 개념으로, 아래 소프트웨어 아키텍처 제 2법칙에 반영되었다.

어떻게보다 왜가 더 중요하다.

• 소프트웨어 아키텍처는 고소득 직종임에도 해당 직업 자체에 대한 명확한 정의가 없다. 그 까닭은 그들의 업무를 정의할 수 없기 때문이다. GoF의 한 사람인 랄프 존슨는 그래서 아래와 같이 이야기하기도 했다.

아키텍처는 중요한 것들에 관한 것이다. 그게 무엇이든 말이다.

• 아키텍트의 역할 역시 방대하고 업무 범위도 계속 넓어지고 있다.
  • Soft Skills (Writing Skills, Presentational Skills…)
  • DevOps
  • Applying Abstraction
  • Patterns
  • Enterprise Architecture
  • Visualization
• 소프트웨어 개발 생태계가 워낙 빠르게 발전하며 소프트웨어 아키텍처 역시 끊임없이 변하고 있다.
• 소프트웨어 아키텍처 관련 자료는 역사적인 연관성을 강조한다.

느낀점

아키텍처란 예술과 마찬가지로 콘텍스트(문맥, 맥락)로서만 이해할 수 있다는 것입니다…. “만약, 여러분이 2002년도 데이터 센터로 돌아가, “안녕하세요, 제가 아키텍처의 혁명을 일으킬만한 획기적인 아이디어를 갖고 있습니다. 모든 서비스가 자신만의 분리된 머신에서 실행되고 심지어 데이터베이스도 따로 있지요. 그래서 윈도우 라이선스도 50개 필요하고, 서버 라이선스도 30개 더 구매해야 하고요, 데이터베이스 서버 라이선스는 최소 50개는 있어야 합니다.”

• 이처럼 시대적인 상황과 연관될 수 밖에 없는게 소프트웨어 아키텍처. 즉, 끊임없이 변화하며 우리 역시 이 변화에 대응하기 위해 계속해서 학습해야 한다는 것!
• 기존에는 소프트웨어 아키텍처를 단순히, 소프트웨어 아키텍처 구조로만 보았다. 이번 과를 읽으면서, 아키텍처 특성과 아키텍처 결정에 필요한 설계 원칙을 세워야함을 알게 됐다. 비록 내가 지금 아키텍트는 아니지만, 과연 이러한 내용들을 실무적으로 어떻게 적용해볼 수 있을까?의 관점에서 책을 읽었다.