진화적 아키텍처

287

9

장

아키텍처 실천

개의 상세 조건을 추가했다. 예를 들면 가동 시간 메트릭 중 하나는 모든 서비스의 가용성이

99

.

999

여야 한다는 조건이 달려 있었다. 최종적으로 확정된 개발 항목은 총

62

개였다.

이내 아키텍트는 이 방식에 몇 가지 문제가 있음을 깨달았다. 첫째, 프로젝트에서 이러한

62

개 속성을 일일이 검증할 수 있는가? 아키텍트가 정책을 만들 수는 있지만 모두가 이를 지속적

으로 따를 수 있을 것인가? 이러한 모든 속성을 수동으로 확인하는 것은 일회성 작업이라 해도

상당히 어려운 도전이 될 것이 분명했다.

둘째, 시스템의 모든 부분에 엄격한 가용성 지침을 적용하는 것이 이치에 맞는가? 관리자의 화

면에

99

.

999

%를 띄우는 것이 그렇게 중요한가? 포괄적인 정책은 종종 지독한 오버엔지니어링

을 낳는 원인이 되기도 한다.

이러한 문제를 해결하기 위해 엔터프라이즈 아키텍트는 피트니스 함수로 기준을 정의하고 신

규 프로젝트용 배포 파이프라인 템플릿을 만들었다. 아키텍트는 보안 등의 핵심 기능을 자동

으로 확인하는 피트니스 함수를 배포 파이프라인에 내부에 설계하고, 서비스용 피트니스 함수

(가용성 등)는 개별 팀의 몫으로 남겨두었다.

9.5

미래 전망 미래 전망

진화적 아키텍처의 미래 상태는 무엇일까? 모든 이가 진화적 아키텍처의 개념과 관행에 익숙

해지면 일상적으로 이를 비즈니스에 반영하고 고도화시켜 데이터 주도 개발처럼 새로운 역량

을 개발할 수 있다

피트니스 함수의 난도는 점점 높아지고 해야 할 일은 더욱 늘어난다. 그러나 문제를 ...