169
6
장
이해 가능성을 위한 설계
6.4
시스템 설계
대형 시스템을 보안 경계로 구분한 컴포넌트로 분리해도 여전히 모든 코드 및 해당 보안 경계
내의 서브컴포넌트를 이해해야 한다. 게다가 컴포넌트로 분리했다 하더라도 여전히 개별 컴포
넌트가 크고 복잡한 경우도 비일비재하다. 이번 절에서는 모듈, 라이브러리,
API
같이 보다 작
은 소프트웨어 컴포넌트를 기준으로 불변성을 이해하는 소프트웨어 구조화 기법에 대해 설명
한다.
6.4.1
서비스 요구사항에 애플리케이션 프레임워크를 활용하기
앞서 설명했듯이 프레임워크는 재사용 가능한 기능을 제공한다. 여러분의 시스템은 인증 프레
임워크, 승인 프레임워크,
RPC
프레임워크, 오케스트레이션 프레임워크, 모니터링 프레임워
크, 소프트웨어 릴리스 프레임워크 등 다양한 프레임워크를 사용하고 있을 것이다. 이런 프레
임워크는 상당한 유연성을 제공하지만 너무
과도한
경우도 많다. 사용할 수 있는 프레임워크와
각 프레임워크를 설정하는 방법의 조합 방법이 너무 많으면 애플리케이션/서비스 개발자, 서비
스 소유자,
SRE
, 데브옵스 엔지니어 등 서비스를 다루는 엔지니어가 어려움을 느낄 것이다.
구글은 이런 복잡성을 관리하기 위한 고수준의 프레임워크를 구현하는 것이 유용하다는 사실
을 깨달았다. 이런 프레임워크를
애플리케이션 프레임워크
라고 부른다. 때로는
풀 스택
full
-
stack
이나
배터리를 내장한
batteries
-
included
프레임워크라고 부르기도 한다. 애플리케이션 프레임워크는 개별
기능을 위한 고유한