THE CODING ARCHITECT

(코딩하는 아키텍트)

우리가 만든 시스템에 개발자들이 거주할 수 있도록 한다면, 아키텍트는 의사 결정의 경향에 대해서 이해를 해야 합니다.

최소한 이것은 팀과 함께 시간을 보내는 것을 의미합니다. 이상적으로는 개발자들이 팀에서 또한 실제로 코딩을 하면서 보낸다는 것을 의미합니다.

페어 프로그래밍(둘이서 짝을 지어 프로그램을 짜는 것 : pair programming)을 연습하는 사람들에 대해서, 아키텍트가 페어의 멤버 중 한명으로 짧은 기간 동안 팀에 참여하는 것은 간단한 일이 됩니다.

이상적으로는, 일반적인 일이 무엇인지를 정말로 이해하기 위해서 일반적인 스토리로 일을 해야 합니다.

아키텍트가 팀에 실제로 앉아 있는 것이 얼마나 중요한 것인지 강조할 수 없습니다. 이것은 전화를 걸거나 단지 코드를 보는 것보다 훨씬 더 효과적입니다.

얼마나 자주 이런 일을 해야 하는지는, 여러분이 일하는 팀의 크기에 굉장히 밀접하게 달려 있습니다. 하지만, 키(key)는 그것이 일상적인 활동(routine activity)이어야 한다는 것입니다.

예를 들면, 여러분이 4개의 팀과 함께 일을 한다면, 매 4주마다 각 팀과 함께 하루 중 절반을 보내는 것이 함께 일하는 팀과의 인식을 함께 하고 커뮤니케이션을 향상시킬 수 있습니다.

A Principled Approach

(주의 접근법 : 원칙에 입각한 접근법)

규칙은 어리석은 자의 순종과 현명한 자의 인도를 위한 것입니다.

( Rules are for the obedience of fools and the guidance of wise men.)

 ----- Generally attributed to Douglas Bader

시스템 설계에서 의사 결정하는 것은 모두 장단점(trade-offs)이 있습니다. 그리고 마이크로서비스 아키텍처는 많은 장단점을 제공합니다. 데이터스토어를 선택할 때, 경험이 적은 플랫폼을 선택하지만, 더 좋은 확장성을 제공하나요?

2개의 다른 기술 스택이 우리 시스템에 있는 것이 좋습니까? 3개는 어떻습니까?

어떤 의사 결정은 우리가 이용할 수 있는 정보로 현장을 완전하게 할 수 있고, 이러한 경우가 가장 쉬운 의사 결정입니다.

그러나 불완전한 정보로 의사 결정을 해야만 하는 사항은 무엇이 있을까요?

의사 결정에 프레임(frame)을 적용하는 것이 도움이 될 수 있습니다. 의사 결정의 틀을 만드는데 도움이 되는 훌륭한 방법은 우리가 달성하고자 하는 목표에 기반하여 일련의 원칙(principles)과 실행 절차(practice)를 정의하는 것입니다.

순서대로 살펴봅시다.

Strategic Goals

(전략적인 목표)

아키텍트의 역할은 이미 충분히 위압적입니다. 따라서 다행스럽게도 우리는 일반적으로 전략적인 목표를 정의할 필요가 없습니다.

전략적인 목표는 회사가 어디로 가고 있는지, 고객을 행복하게 하는 최선의 방법을 어떻게 보여줄 것인지를 이야기해야만 합니다.

이것들은 고수준(high-level)의 목표가 될 것입니다. 그리고 기술은 전혀 포함되어 있지 않을 수도 있습니다.

그것들은 회사 수준이나 부서 수준에서 정의될 수 있습니다.

그 전략 목표들은 "새로운 시장을 개척하기 위한 동남 아시아로의 확장"이거나 "셀프 서비스를 통해 고객이 가능한 한 많은 것을 성취하게 하자"와 같은 것들이 될 수 있습니다.

핵심(key)은 여러분의 조직이 지향하는 곳이 어디인지, 따라서 기술이 거기에 정렬되어 있는지를 확인해야 하는 것입니다.

만약 여러분이 회사에서 기술적인 비전을 정의하는 사람이라면, 여러분 조직의 비기술적인 파트(또는 종종 우리가 비즈니스라고 부르는)와 더 많은 시간을 보내야 할 수도 있습니다.

비즈니스를 추진하는 비전은 무엇입니까? 그리고 그것이 어떻게 변화하나요?

Principles

(원칙)

원칙(principles)은 조금 더 큰 목표에 자신이 하는 일을 부합시키기 위해서 만든 규칙이고, 때때로 변화할 것입니다. 예를 들면, 만약 조직으로서 여러분의 전략적 목표 중 하나가 새로운 기능을 시장에 출시하기 위한 시간을 줄이는 것이라면, delivery team은 다른 팀과 독립적으로 준비되었을 때 언제라도 소프트웨어의 수명 주기(lifecycle)을 온전히 통제하는 원칙을 정의할 수 있습니다.

만약 또다른 목표가 여러분의 조직이 다른 나라에서 적극적으로 성장하는 것이라면, 데이터의 주권을 존중하기 위해서 전체 시스템을 로컬에서 배포할 수 있도록 이식성이 있어야 한다(portable)는 원칙을 구현하도록 결정할 수 있습니다.

여러분은 아마도 이것들을 짊어짐을 원하지는 않을 것입니다.

10보다 작은 숫자는 사람들이 기억할 수 있을만큼 충분히 작거나 작은 포스터에 적합한 좋은 숫자입니다. 더 많은 원칙을 가지고 있을수록, 서로 겹치거나 모순될 위험이 더 커집니다.

Heroku의 12가지 팩터는 Heroku 플랫폼에서 잘 동작하는 어플리케이션을 만들 수 있도록 도와주는 목표를 중심으로 구조화된 일련의 디자인 원칙들입니다. 그것들은 또한 다른 맥락에서 의미가 있을 수 있습니다.

원칙들 중 일부는 실제로 어플리케이션이 Heroku 상에서 동작하기 위해 필요한 동작에 근거한 제약 조건들입니다. 제약 조건은 실제로 변경하기 매우 어렵지만 (혹은 사실상 불가능), 반면에 원칙들은 선택하기로 결정한 것들입니다.

제약조건과 비교하여 정말로 변경할 수 없는 그러한 것들을 가리키도록 도와주기 위한 원칙들을 명시적으로 호출하도록 결정할 수 있습니다.

개인적으로, 때때로 도전적인 제약 사항들을 장려하고, 정말로 움직일 수 없는지를 보기 위해서 제약사항들을 같은 목록에 유지할 만한 가치가 있다고 생각합니다.

Practices

(실행 절차)

실행 절차(practice)들은 우리의 원칙이 어떻게 이행되고 있는지를 확인하는 것입니다.

작업 수행을 위한 상세하고 실용적인 지침 세트라고 할 수 있습니다.

종종 기술 중심적이고, 어떤 개발자도 이해할 수 있을 정도로 충분히 낮은 수준이어야 합니다. 실행 절차에는 코딩 가이드라인, 모든 로그 데이터가 중앙 집중식으로 보존되어야 할 필요가 있는지, 혹은 HTTP/REST가 표준 통합 스타일(standard integration style)인지 여부가 포함될 수 있습니다. 기술적인 특성으로 인해, 실행 절차는 원칙보다 더 자주 변경됩니다.

원칙(principles)과 마찬가지로, 가끔 실행 절차들도 조직의 제약 사항들을 반영합니다. 예를 들면, 단지 CentOS만 지원한다면, 실행 절차에 반영되어야 합니다.

실행 절차는 원칙을 뒷받침해야 합니다. Delivery Team이 시스템의 전체 수명주기(lifecycle)를 통제한다는 원칙은 모든 서비스가 격리된 AWS 계정에 배포되고, 리소스에 대한 셀프 서비스 관리(self-service management)와 다른 팀으로부터의 격리를 제공한다는 것을 의미합니다.

Combining Principles and Practices

(원칙과 실행절차의 결합)

한 사람의 원칙은 다른 사람의 실행 절차가 됩니다. 예를 들면, HTTP/REST의 사용을 실행 절차보다 원칙으로 부르기로 결정할 수 있습니다. 그리고 그것은 괜찮을 것입니다.

요점(key point)은 시스템이 어떻게 진화하는지를 가이드하는 포괄적인 아이디어를 가지고 있고, 그러한 아이디어를 어떻게 구현할지에 대해 사람들이 알 수 있도록 충분한 세부사항들을 가지고 있는 것에 대해서 가치가 있다는 것입니다.

아마도 단일 팀과 같이 충분히 작은 그룹에 대해서, 원칙과 실행 절차를 결합하는 것은 좋을 것입니다.

그러나 기술과 업무 실행 절차가 다를 수 있는 더 큰 조직에서는 공통된 일련의 원칙에 매핑되는 한, 다른 곳에서 다른 실행 절차를 원할 수도 있습니다.

예를 들면, .NET 팀은 일련의 실행 절차 중 하나를 가지고 있을 수 있고, Java 팀은 양쪽에 공통된 일련의 실행 절차를 가지고 있을 수 있습니다.

하지만, 원칙은 둘 모두 동일할 수 있습니다.

A Real-World Example

(실 세상의 예)

동료 Evan Bottcher는 고객 중 한명과 작업하는 과정에서 그림 2-1에서 보이는 다이어그램을 개발했습니다.

이 그림은 목표, 원칙, 실행 절차의 상호작용을 매우 분명한 형식으로 보여줍니다. 2년여 과정 동안, 맨 오른쪽에 있는 실행 절차는 상당히 규칙적으로 바뀌지만, 반면에 원칙은 꽤 고정적으로 유지됩니다.

이와같은 다이어그램은 한장의 종이에 멋지게 인쇄하여 공유할 수 있습니다. 그리고 각 아이디어는 일반적인 개발자가 기억하기에 충분히 간단합니다.

물론, 여기에는 각 요점 뒤에 더 세부 사항이 있지만, 요약된 형식으로 이것을 표현할 수 있다는 것은 매우 유용합니다.

<2-1. A Real-world example of principles and practices>

이러한 항목들 중 일부를 지원하는 문서를 가지고 있는 것이 좋습니다.

비록, 대체로 그러한 아이디어를 구체화하는 직접 볼 수 있고, 점검할 수 있고, 실행할 수 있는 예제 코드를 가진 아이디어를 좋아합니다.

더 나아가서 박스 밖에서 옳은 일을 하는 도구를 만들 수 있습니다. 즉시 그에 대해 더 깊이 논의할 것입니다.