마이크로서비스가 수많은 선택의 기회를 제공하면서 변화의 속도가 빨라지고 아키텍처가 수용할 수 있는 환경이 더 유연해 지고있다. 이에 따른 아키텍트의 역할변화에 대해 알아보자.
부정확한 비교
아키텍트는 다르사람이 해석하고 실행할 수 있도록 세부 계획을 세우는 것이다. 예술가와 엔지니어의 균형감각을 유지하면서 물리적으로 불가능하다는 구조 공학자의 간헐적인 반대를 제외한 다른 관점들을 통합하여 단일한 비전이 정상적으로 형성되도록 감독하는 것이다. 아이티 업계의 이러한 관점은 고된 업무로 이어진다. 알 수 없는 미래에 대한 근본적인 고민 없이 완벽한 시스템 구축을 증명하려는 관점에서 작성된 끝없는 설계도와 문서 작업이 바로 그것이다. 이를 해결하기 위한 최선의 방안은 우리의 입장에서 아키텍트의 의미를 재정의 하는 것이다.
아키텍트에 대한 진화적 관점
아키텍트는 아ㅠ으로 발생할 모든 일을 예측할 수 없는 만큼, 모든 사태에 대해 미리 계획하기 보다는 과욕을 부리려는 충동을 절제하고 변화를 받아들이도록 해야 한다. 아키텍트가 만드는 시스템은 단지 사용자만을 수용하는 것이 아니며, 그곳에서 일하는 개발자와 운영자, 시스템을 변경한느 업무를 가진 모든 사람까지 수용해야한다. 또한 도시 설계자로서의 아키텍트는 방향 자체는 개괄적으로 설정하되, 특정 경우의 세부 구현에 대해서만 매우 구체적으로 관여해야 한다. 시스템이 현재의 목적에 들어맞을 뿐만 아니라 미래의 플랫폼으로서 적합하다는 것을 보장해야 하고, 사용자와 개발자가 똑같이 행복해지도록 해야 한다.
구역화
아키텍트는 구역 내의 일보다 구역 사이에서 발생하는 일을 더 걱정해야 한다. 즉 서비스 간 통신 방법에 대해 고민하거나 시스템의 전반적인 상태를 모니터링하는 데 더 많은 시간을 할애해야 한다.
원시적인 접근법
4.1 전략적 목표 : 높은 수준의 목표. 기술이 전혀 포함되지 않을 가능성이 큰 만큼 회사 또는 사업 부서 수준에서 정의
4.2 원칙 : 더 큰 목표를 위해 해야 할 일을 정렬하는 규칙
4.3 실천 사항 : 업무 수행을 위한 자세하고도 실질적인 지침. 기술 명세적이며 구체적이어야 한다.
4.4 원칙과 실천 사항의 결합
필수 기준
5.1 모니터링 : 서비스 간 경계를 넘어 시스템 상태를 일관되게 살펴볼 수 있어야 한다. 서비스 세부 상태가 아닌 시스템 전체 상태를 볼 수 있어야 한다.
5.2 인터페이스 : 인터페이스 기술의 개수는 최소한으로 유지하는 편이 좋다.
5.3 아키텍처 안정성 : 오동작하는 하나의 서비스가 전체를 망가뜨리게 해서는 안되며, 서비스들이 비정상적인 하위 호출로부터 자신을 잘 보호하도록 해야 한다.
코드를 통한 통제
실제 사용하는 서비스중 본보기가 될만한 서비스템플릿을 제공하는 것이 좋다.
기술 부채
조직에 따라 아키텍트가 관대한 지침을 제공하고, 팀 스스로 부채를 찾아내서 상환하는 방법을 결정할 수 있다.
예외 처리
충분히 많은 예외가 발견된다면 결과적으로 현실을 재인식시킬 수 있도록 원칙과 실천사항을 변경하는 것이 타당할 수 있다. 나중에 참조할 수 있도록 기록해둘 만하다.
중앙에서의 거버넌스와 지휘
아키텍트의 업무 중 하나가 기술 비전을 결정하는 것이라면, 거버넌스는 우리가 구축하는 결과물이 해당 비전과 일치함을 보장하고, 필요할 경우 비전을 진화시키는 것이다.
팀 만들기
사람들이 더 많은 책무를 맡기 전에 개별 서비스의 소유권을 부여함으로써 거들을 성장시키는 것은 그들 자신의 경력 목표를 성취하도록 돕는 훌륭한 방법이다.
