소프트웨어 아키텍처란 §
- 아키택처란 예술과 마찬가지로 콘택스트로서만 이해할 수 있음
- 아키텍트가 내린 결정은 대부분 그들이 그렇게 결정한 당시 환경에 기인한 것임
- 환경에 유리된 아키텍처를 설계하는 것은 의미도 없고, 유지불가능함
소프트웨어 아키텍처란? §
- 아키텍처 특성
- 아키텍처 결정
- 설계 원칙
- 시스템의 구조
시스템의 구조 §
- 시스템이 구현된 아키텍처 스타일의 종류를 의미한다
- 그러나 구조만으로는 아키텍처를 전체적으로 설명하기에는 부족하다
- 가령, 아키텍처를 설명해달라고 요청하자, 아키텍트가 단지 ‘마이크로서비스 아키텍처입니다’ 라고 대답하였다면, 그는 단지 시스템의 구조만 언급하였을 뿐, 시스템의 아키텍처를 이야기한 것이 아니다.
- 시스템의 아키텍처를 명확하게 이해하려면 나머지 세 가지 원칙 아키택처 특성, 아키텍처 결정, 설계원칙 을 알아야 한다
아키텍처 특성 §
- 일반적으로 시스템의 성공 기준을 결정한다
- 시스템이 올바르게 동작하기 위해서 반드시 필요한 것들을 의미
아키텍처 결정 §
- 시스템 구축에 필요한 규칙들을 정한 것
- 레이어드 아키텍처에서는 프레젠테이션 레이어가 데이터베이스를 직접 호출하지 못하게 비즈니스와 서비스 레이어에서만 데이터베이스에 엑세스 할 수 있다
- 아키텍처 결정은 시스템의 제약조건 을 형성하며, 개발자가 해도 되는것과 하지 말아야 하는 것을 알려줌
- 이를 통해 무언가 구현할 때 아키텍처 결정 때문에 이를 구현할 수 없다면, 해당 규칙 혹은 그 결정은 변형 이라는 것을 통해서 깨뜨릴 수 있다. 아키텍처 결정에 대한 예외는 아키텍처 심사 위원회가 검토하여(만약 위원회가 없다면 최고 아키텍트가 검토하여) 타당한 근거와 트레이드오프를 고려한 후 승인/거부한다
설계원칙 §
- 아키텍처 결정이 반드시 지켜야 하는 규칙이라면, 설계원칙은 가이드라인
- 마이크로서비스 아키텍처의 성능 향상을 위해 서비스 간 통신은 비동기 메시징을 활용해야 한다고 기술하는 것이 설계 원칙
- 모든 조건과 구현 방식을 아키텍처 결정으로 다룰 수 없기 때문에, 특정 환경에서 개발자가 더 적합한 통신 프로토콜을 선택할 수 있도록 우선 권장하는 방법에 대한 가이드를 설계원칙으로 제공하는 것
아키텍트에 대한 기대치 §
- 아키텍처 결정을 내린다
- 아키텍처를 지속적으로 분석한다
- 최신 트렌드를 계속 유지한다
- 아키텍처 결정의 컴플라이언스를 보장한다
- 다양한 기술과 경험에 노출된다
- 비즈니스 도메인 지식을 보유한다
- 대인 관계 기술이 뛰어나다
- 정치를 이해하고 처세를 잘한다
아키텍처 결정을 내린다 §
- 아키텍트는 기술 선택을 가이드하는 사람이지, 정해주는 사람이 아님
- 가령 어떤 아키텍트가 프런트엔드를 리액트로 개발하기로 결정하였다면, 이는 개발팀이 스스로 선택할 수 있게 가이드를 해준 것이 아니라, 기술 결정 을 해버린 것임
- 아키텍트는 개발자들이 프런트엔드 웹 개발용 리액티브 기반의 프레임워크를 사용하도록 기술 지도를 하고, 앵귤러, 엘름, 리엑트JS, 뷰와 같은 리액티브 기반의 웹 프레임워크 중 하나를 선정할 수 있도록 가이드함
- 이는 마치 지도자가 운동 선수를 지도하는 것과 비슷함. 아키텍트는 자신이 가이드를 해줄지, 아니면 개발팀을 위해 기술을 선택해주는 것이 더 나을지 스스로에게 자문해보아야 함
아키텍처를 지속적으로 분석한다 §
- 현재 기술 환경과 아키텍처를 지속적으로 분석하고, 이를 개선하기 위한 해결 방안을 제시하여야 함
- 이는 다음의 사건을 이야기함 : 자신이 3년 전에 정의한 아키텍처가 지금도 얼마나 현실성 있는지 평가하고 개선한다
- 테스팅과 릴리즈 환경을 고려햐여야 함. 민첩하게 코드를 수정할 수 있어도, 수정한 코드를 테스트하는 데 몇 주나 걸리고 릴리즈까지 수개월이 소비된다면 이는 민첩하다고 말할 수 없음
- 기술 변화와 문제 영역을 종합적으로 분석하여, 아키텍처의 건전성을 추구하여야 함
최신 트렌드를 계속 따라간다 §
아키텍처 결정의 컴플라이언스를 보장한다 §
- 아키텍트가 정의하고 문서화하여 전달한 아키텍처 결정과 설계 원칙들을 개발팀이 제대로 준수하고 있는지 지속적으로 확인하여야 함
다양한 기술과 경험에 노출된다 §
- 모든 프레임워크, 플랫폼, 언어에 통달해야 할 필요는 없지만, 적어도 다양한 기술을 거리낌없이 사용할 수 있어야 함
- 어떤 언어와 플랫폼, 기술로 개발되었든지 다양한 시스템과 서비스를 연동하는 방법을 알고 있어야 함
- 한 가지 기술이나 플랫폼에 올인하지 말고, 자기 자신의 컴포트 존을 점점 넓혀가는 것이 가장 좋다
- 기술 폭을 점점 넓혀가는 방식을 추천
- 이는 아주 자세히는 몰라도 자신이 잘 알고 있는 것과 연관지어서 아는 것을 의미한다
비즈니스 도메인 지식을 보유한다 §
- 어느 수준 이상의 비즈니스 도메인 전문가여야 한다
- 우리가 만나 본 가장 성공적인 아키텍트들은 폭넓은 실무 지식 뿐만 아니라 특정 도메인에 깊이 있는 지식을 보유한 사람들어있음
대인 관계 기술이 뛰어나다 §
- 아키텍트는 팀워크, 조정, 리더십을 포함한 대인 관계 기술이 뛰어나야 한다
- 단지 기술적으로 뛰어난 것만으로는 아키텍트 자리에 계속 앉아있기 어렵다
정치를 이해하고 처세를 잘한다 §
- 기업 내부의 정치적 분위기를 이해하고 적절하게 잘 처신할 줄 알아야 한다
- 자신이 한 결정이 회사의 다른 사람들에게 어떤 영향을 미칠 수 있는지 적절하게 잘 이해해야 한다
- 예를 들면 어떤 아키텍트가 자신이 소유한 데이터베이스에만 엑세스 할 수 있는, 데이터베이스 사일로를 구축하겠다고 결정하였다. 이는 회사 내 거의 모든 사람들에게 공격받게 될 것이다
- 회사의 다른 서비스들 또한 데이터베이스 사일로에 접근할 수 있어야 하기 때문. 다른 사람들은 즉각적으로 API 를 요구할 것이다
아키텍처의 교차점 그리고… §
엔지니어링 프랙티스 §
- 프로세스와 무관하게 가시적이고 반복 가능한 혜택을 주는 실천론
- 예컨데, 지속적 통합은 특정 프로세스에 의존하지 않는 검증된 엔지니어링 프랙티스임
- 엔지니어링 프랙티스에 집중하는 것은 중요함
- 소프트웨어 개발분야는 결과를 추정하기 어려움
- 사람들은 원래 추정을 하는데 어려움을 겪는다
- 알려지지 않은 미지의 것들 때문이기도 함
- 우리가 모른다는 것도 모르는 것들
- 이는 필연 적이다. 그래서 소프트웨어 아키텍트는 프로그램 구현을 시작하기 전에 프로그램의 디자인을 완성하는 방식으로 진행하기 어려움
- 결과를 추정하기 어렵기 때문에, 반복적인 프로세스가 소프트웨어 아키텍처와 잘 맞는다.
운영/데브옵스 §
- 오랫동안 개발과 운영은 별개의 영역이었고, 개발이 완료된 후에 운영은 외주를 맡기는 일이 잦았다.
- 그러다가 몇몇 회사들이 운영 문제를 아키텍처와 결합한 새로운 형태의 아키텍처를 실험하기 시작함
프로세스 §
- 역사적으로 소프트웨어를 구축하는 방법은 소프트웨어 아키텍처에 영향을 미치지 못한다고 간주되어왔음
- 이는 거짓임. 개발팀의 프로세스는 아키텍처 여러 파트에 영향을 미침
- 일례로, 애자일 프로세스를 진행중이라면 피드백을 더 빨리 받아보리라 기대하기 때문에 피드백에 의존하는 다른 실험에 더 적극적으로 참여할 수 있음
- 그렇기 때문에 우리는 애자일 방법론을 기반으로 하되, 필요시 예외를 도출할 것임
- 재구성은 아키텍처를 변경하는 것임. 예를 들면 팀은 모놀리틱 아키텍처로 시작했지만, 이제는 더 현대적인 마이크로서비스 아키텍처로 변경을 시도할 수 있음. 이를 재구성이라 하고 애자일은 피드백 루프가 더 촘촘하고 스트랭글러 패턴 과 기능 토글 등의 기법을 통해 이를 잘 지원할 수 있음
데이터 §
- 애플리케이션 개발에 데이터는 큰 비중을 차지하지만, 많은 아키텍처들이 이를 가볍게 다루는 경향이 있음
- DBA 는 아키텍처와 긴밀하게 협업하여, 복잡한 시스템의 데이터 아키텍처를 구축한다
소프트웨어 아키텍처 법칙 §
제 1원칙 §
- 소프트웨어 아키텍터의 모든 것은 다 트레이드오프이다
- 아키텍처가 트레이드오프가 아닌 뭔가를 발견했다면, 이는 그가 아직 트레이드오프임을 발견하지 못했다는 증거일 가능성이 높다
제 2법칙 §
- ‘어떻게’ 보다 ‘왜’ 가 더 중요하다
- 아키텍처는 자신이 전혀 모르는 기존 시스템을 들여다보면서 아키텍처의 구조적인 작동 원리는 알아낼 수 있지만, ‘왜’ 이렇게 했는지는 알아내기 어렵다