지금까지 본 것처럼, 마이크로서비스는 우리에게 많은 선택권을 주고, 그에 따라서 많은 결정을 내릴 수 있었습니다.
예를 들면, 얼마나 많은 다른 기술들을 사용해야만 했고, 다른 팀에서 다른 프로그래밍 관용구를 사용하게 했으며, 서비스를 분할하거나 통합해야만 했는가?
어떻게 이런 결정을 내릴 수 있을까요? 변화의 속도가 더 빨라지고, 이러한 아키텍처가 허용하는 더 유동적인 환경에서 아키텍트의 역할도 또한 변해야 합니다.
이 장에서는 아키텍트의 역할이 무엇인지에 대해서 상당히 개인적인 뷰를 가지고, 바라건데 상아탑에 대한 하나의 최종 공격을 시작하겠습니다.
Inaccurate Comparisons
(부정확한 비교)
당신은 계속해서 그 단어를 사용하고 있습니다. 나는 그 단어가 당신이 생각하는 것을 의미한다고 생각하지 않습니다.
----- Inigo Montoya, from The Princess Bride
아키텍트는 중요한 직업을 가지고 있습니다. 아키텍트는 고객이 필요로 하는 시스템을 제공하는데 도움이 되는 기술적 비전을 모아서 확보할 책임을 가지고 있습니다.
일부 지역에서, 아키텍트는 아키텍트의 역할과 기술적인 주역이 동일한 경우인, 단지 하나의 팀과 작업을 해야만 할 수 있습니다.
다른 지역에서는, 아키텍트가 전 세계의 여러 팀이나 심지어 전체 조직을 조율하며 전체 작업 프로그램에 대한 비전을 정의할 수도 있습니다.
아키텍트가 어떤 수준에서 작업을 하든, 그 역할을 고정하는 것은 까다롭습니다.
그리고 엔터프라이즈 조직에서 개발자가 분명한 직업상 진로를 종종 (아키텍트로) 보이고 있음에도 불구하고, 사실상 다른 어떤 것보다 더 많은 비판을 받는 역할을 합니다.
다른 어떤 역할보다 더 많이, 아키텍트는 구축된 시스템의 품질, 동료의 근무 조건, 변화에 대응하는 조직의 능력에 직접적인 영향을 미칠 수 있습니다. 그러나 우리는 종종 이 역할을 잘못하는 것처럼 보입니다.
왜 그럴까요?
이 산업계는 아직 어린 분야입니다.
우리가 잊어버린 것처럼 보이는 어떤 것이지만, 단지 약 70년 동안 컴퓨터로 인식하는 실행 프로그램을 만들었을 뿐입니다.
그러므로, 우리가 무엇을 하는지 설명하려고 시도하기 위해 지속적으로 다른 직업을 찾고 있습니다.
우리는 의사나 엔지니어가 아니지만, 배관공이나 전기 기술자도 아닙니다.
대신에, 우리는 사회가 우리를 이해하기 어렵게 만들거나 우리가 어디에 적합한지 이해하기 어렵게 만드는 어느 중간 영역에 빠지게 됩니다.
그래서 우리는 다른 직업에서 빌려왔습니다.
우리는 스스로를 소프트웨어 "엔지니어" 혹은 "아키텍트"로 부릅니다. 하지만, 우리는 그렇지 않습니다. 아닌가요?
아키텍트(건축가)와 엔지니어(기술자)는 우리가 단지 꿈꿀 수 있는 엄격함과 규율을 가지고 있습니다. 그리고 사회에서의 중요성을 잘 이해하고 있습니다.
나는 내 친구가 자격을 갖춘 아키텍트(건축가)가 되기 전 어느 날, 이야기 한 것을 기억합니다.
"내일 만약 내가 무엇인가를 만드는 방법을 술집에서 조언하고, 그것이 잘못되었다면, 설명하려고 할 것이다. 나는 법률 관점에서 자격을 갖춘 아키텍트(건축가)이고, 내가 잘못했다면 그에 대한 책임을 저야 하기 때문에 고소를 당해야 한다."라고 그 친구는 말했습니다.
사회에서 이러한 직업의 중요성은 사람들이 충족시켜야만 하는 자격 요건이 있음을 의미합니다. 예를 들면, UK(영국)에서는 아키텍트(건축가)로 불릴 수 있게 되려면 최소한 7년간의 학습이 필요합니다. 그러나 이러한 직업들은 또한 수천년 전의 지식 체계를 기반으로 합니다.
우리는 어떤가요? 그다지 좋지 않습니다.
어떤 이유로 좋아 보이는 것에 대해 거의 알지 못하는 것처럼, 대부분의 IT Certification(IT 자격증)이 가치가 없는 것처럼 보입니다.
우리 중의 일부는 인정받기 원하므로, 이미 업계의 갈망으로 인정받은 다른 직업에서 이름을 빌려왔습니다.
그러나 이것은 이중으로 해로울 수 있습니다.
첫째, 우리가 분명하게 하지 않을 때, 우리가 하고 있는 것을 안다는 것을 의미합니다.
빌딩과 다리가 결코 쓰러지지 않는다고 말하지는 않겠지만, 우리의 프로그램이 충돌할 횟수보다 훨씬 더 적게 쓰러져서 엔지니어(기술자)로서 비교하기에는 불공평합니다.
둘째, 유추는 매우 빠르게 심지어 매우 대충 흘낏 보는 것만으로도 실패하게 됩니다. 일이 잘 풀어지기 위해서, 만약 다리를 건설하는 것이 프로그래밍과 같았다면, 50미터 더 멀리 떨어진 반경에, 실제로는 화강암보다 진흙이 있었음을 우리는 발견했을 것입니다. 그리고 도로가 지나가는 다리를 건설하는 대신에 걸어다니는 다리를 건설했을 것입니다.
우리의 소프트웨어는 실제 아키텍트(건축가)나 엔지니어(기술자)가 처리해야 하는 것과 동일한 물리적인 규칙에 의해 제한받지 않습니다. 그리고 우리가 만든 것은 사용자의 요구사항에 유연하게 적응하고 진화하도록 설계되었습니다.
아마도 아키텍트(건축가)라는 용어는 가장 많은 해를 입었을 것입니다. 다른 사람들이 해석할 수 있도록 상세한 계획을 세운 사람들의 아이디어는 이것이 실행될 것이라고 기대했습니다.
일부 예술가, 일부 엔지니어(기술자), 일반적으로 단일 비전 생성을 감독하는 것의 균형(balance)은 물리학적인 법칙을 고려한 구조 공학자(Structural Engineer)의 간헐적인 반대를 제외하고, 다른 모든 관점은 보조적입니다.
우리 업계에서, 이러한 아키텍트에 대한 관점은 다음과 같은 몇 가지 무시무시한 업무로 이어집니다.
근본적으로 알 수 없는 미래에 대한 고려 없이, 다이어그램 이후 다이어그램, 문서의 페이지 이후의 페이지, 완벽한 시스템 구조를 알리기 위해 만들어진 뷰(view).
구현할 것이 얼마나 어려운 것인지, 혹은 실제로 동작할 것인지 아닌지에 대한 이해가 완전히 결여되어 있고, 우리가 더 많이 배울수록 변화하기 위해 어떤 능력도 가지지 못하게 합니다.
우리가 스스로를 엔지니어(기술자)나 아키텍트(건축가)와 비교해 볼 때, 모든 사람들에게 위해를 줄 위험이 있습니다. 불행하게도, 우리는 지금 아키텍트라는 단어에 매료되어 있습니다.
따라서, 우리가 할 수 있는 최선은 우리의 맥락에서 아키텍트가 무엇을 의미하는지를 재정의 하는 것입니다.
An Evolutionary Vision for the Architect
(아키텍트에 대한 진화(성장) 비전)
우리의 요구사항은 건물을 설계하고 건설하는 사람들보다 더 빠르게 변화하고 있습니다 - 우리가 처분하는 도구와 기술처럼. 우리가 만든 것들은 고정된 시점이 아닙니다. 한번 상용화되면, 우리의 소프트웨어는 사용되는 방법이 변경됨에 따라 지속적으로 발전할 것입니다. 우리가 만든 대부분의 것들에 대해서 한번 고객들의 손에 들어간 소프트웨어가 절대로 변경되지 않는 아티팩트(인공물)라기 보다는 반응하고 적응(react and adapt)해야 한다는 것을 받아들어야 합니다.
이처럼, 우리 아키텍트들은 완벽한 최종 제품을 만다는 것에서 생각을 바꾸고, 대신에 올바른 시스템이 등장할 수 있는 프레임워크를 만드는데 도움이 되도록 집중하고 더 많이 배우면서 계속적으로 성장해야만 합니다.
비록 다른 직업과 너무 많이 비교해 보라는 경고로 많은 부분을 썼지만, IT 아키텍트의 역할에 대해서 좋아하는 한가지 비유가 있습니다. 그리고 이 비유가 우리가 이 역할을 하기를 원하는 것을 더 잘 캡슐화한다고 생각합니다.
Erik Doernenburg는 처음에 우리의 역할을 환경을 건설하는 아키텍트보다 도시건설 계획자(town planner)로 생각해야 한다는 아이디어를 공유했습니다.
도시 건설 계획자의 역할은 전에 SimCity 게임을 해본 사람들 중 누구에게나 익숙해야 합니다. 도시 건설 계획자의 역할은 다양한 정보 소스를 살펴보고, 미래의 용도를 고려하여 오늘날 시민들의 요구사항에 가장 적합한 도시 배치를 최적화하는 것입니다.
도시가 어떻게 진화하는지에 대해 영향을 미치는 방식은 흥미롭습니다.
"특별한 건물을 여기에 세워라."라고 말하지 않고, 대신에 도시를 구역화합니다.
따라서 SimCity에서처럼, 도시의 일부를 산업 구역(industial zone)으로 나타내고, 다른 부분은 거주 지역으로 지정할 수 있습니다.
정확히 무슨 건물이 세워질지에 대한 의사 결정은 다른 사람들에게 달려 있지만, 제한이 있습니다. 만약 공장을 세우고 싶다면, 산업 구역에 있어야만 할 것입니다.
하나의 구역에서 무슨 일이 일어날지에 대해서 너무 많은 걱정없이, 도시 건설 계획자는 어떻게 사람들과 시설들이 하나의 구역에서 다른 구역으로 이동할 것인지에 대해 더 많은 시간을 보낼 것입니다.
한 명 이상의 사람이 도시를 생물(living creature)로 비유했습니다. 도시는 시간이 지나면서 변화합니다. 거주자가 다른 방식으로 사용하거나 외부의 힘이 도시를 사용함에 따라서 변화하고 진화합니다.
도시 건설 계획자는 이러한 변화를 예상하기 위해서 최선을 다하지만, 무엇이 일어날지에 대해 모든 측면에서 직접적으로 컨트롤하려고 하는 것이 쓸모 없는 일임을 받아들입니다.
소프트웨어와의 비교는 분명해야 합니다.
사용자가 우리의 소프트웨어를 사용하기 때문에, 우리는 반응하고 변화해야 합니다.
우리는 앞으로 일어날 모든 일을 예견할 수 없습니다. 그리고 모든 우발적인 상황(eventuality)에 대한 계획을 수립하기보다 모든 마지막 일을 지나치게 지정하는 충동을 피함으로써 변화를 허용하는 계획을 세워야만 합니다. 우리의 도시-시스템-는 사용하는 모든 사람에게 좋고 행복한 장소가 되어야만 합니다.
사람들이 자주 잊어버리는 한 가지는 우리 시스템이 단지 사용자만을 수용하는 것이 아니라, 거기서 일해야 하는 개발자와 운영자도 또한 수용하고, 필요 시 변경할 수 있는지 확인하는 사람들까지도 수용한다는 것입니다.
Frank Buschmann의 용어를 빌리자면, 아키텍트는 시스템이 개발자들도 거주할 수 있도록 보장하는 의무를 가집니다. 아키텍트처럼 도시 건설 계획자도 그 계획이 뒤따르지 않을 때도 알아야 합니다.
처방전이 적기 때문에, 올바른 방향으로 바꾸는 것을 최소화해야겠지만, 만약 누군가가 거주 지역에 하수 처리장을 세우기로 결정했다면, 그것을 막을 수 있어야 합니다. 도시 건설 계획자와 같은 아키텍트는 광범위한 행정 분야에서 방향을 결정할 필요가 있고, 제한된 경우에만 구현 세부 사항에 대해 매우 구체적으로 관여해야 합니다. 시스템에 목적에 맞도록 보장해야 하지만, 또한 시스템은 미래를 위한 플랫폼이기도 합니다. 또한 사용자와 개발자를 동등하게 행복하게 하는 시스템이 되도록 보장해야만 합니다.
이것은 꽤 큰 순서처럼 들립니다. 우리는 어디에서 시작해야 할까요?
Zoning
(영역 설정)
그래서 잠시 동안만 계속해서 도시 건설 계획자로서 아키텍트를 은유해보자면, 우리 영역은 무엇일까요?
이것은 우리의 서비스 경계나 낮은 수준(coarse-grained)의 서비스 그룹입니다. 아키텍트로서 영역 간에 무엇이 발생할지 보다 영역 내에서 발생하는 일들에 대해 훨씬 덜 걱정할 필요가 있습니다. 그것은 우리 서비스들이 서로 어떻게 이야기하는지에 대해서 생각하거나, 혹은 어떻게 우리 시스템 전체에 대한 상태를 적절하게 모니터링할 수 있는지에 대해서 보장하는데 시간을 보낼 필요가 있습니다.
영역 내에서 어떻게 들어가는가에 대한 방법은 다소 다릅니다.
많은 조직들은 팀의 자율성을 극대화하기 위해서 마이크로서비스를 채택했습니다. 10장에서 확대하여 살펴볼 것입니다.
만약 여러분이 그런 조직에 있다면, 올바른 지역적인 결정을 내리기 위해서 더 많이 팀에 의존할 것입니다.
그러나, 영역 사이, 혹은 전통적인 아키텍처 다이어그램에서 박스 사이에서 우리는 주의를 기울여야 합니다. 여기서 잘못되면, 모든 종류의 문제가 발생하고, 바로잡기 매우 어려울 수 있습니다.
각 서비스내에서, 영역을 소유한 팀이 다른 기술 스택이나 데이터 저장소를 선택하면 문제가 없을 수 있습니다. 물론, 다른 관심사가 여기에 끼어들 수도 있습니다.
10가지의 지원할 수 있는 다른 기술 스택을 가지고 있는 경우, 작업을 위한 올바른 도구를 팀이 선택하도록 하는 경향은 사람을 임대하거나 팀 사이에 사람들이 이동하기에 더 어렵게 된다는 사실에 의해 완화될 수 있습니다. 마찬가지로, 만약 각 팀이 완전히 다른 데이터 저장소를 선택한다면,팀의 규모에서 실행하기에는 충분히 경험하지 못했음을 알게 될 수도 있습니다.
예를 들면, 넷플릭스(Netflix)는 대부분의 데이터 저장소 기술로 카산드라(Cassandra)로 표준화되어 있습니다.
비록, 모든 경우에 적합한 것은 아니지만, 넷플릭스는 카산드라에 대한 도구화와 전문 지식을 구축하여 얻은 가치는 특정 작업에 더 좋을 수 있는 다른 여러 플랫폼을 지원하고 운영하는 것보다 더 중요하다고 생각합니다.
넷플릭스는 규모가 가장 강력한 최우선 요소일 수 있는 극단적인 경우이지만, 아이디어를 얻을 수 있습니다.
그러나, 서비스 사이에서는 사태가 어지러울 수 있습니다. 만약, 하나의 서비스가 HTTP REST를 노출하기로 결정했고, 또다른 서비스는 프로토콜 버퍼(protocol buffer)를 사용하고, 세번째 서비스는 Java RMI를 사용하기로 결정했다면, 소모하는 서비스(호출하는 서비스 : consuming service)가 다양한 스타일의 상호 교환을 이해하고 지원해야 하므로 통합은 악몽이 될 수 있습니다.
이것이 "박스 사이에서 어떤 일이 일어날지에 대해서 걱정해야 하고, 내부에서 무슨 일이 일어날지에 대해서는 자유로워야 한다"는 가이드라인을 준수하려고 노력하는 이유입니다.
댓글을 달아 주세요
댓글 RSS 주소 : http://www.yongbi.net/rss/comment/817