[1]은 웹 성능 최적화에 이야기 하고 있지만, 네트워크를 사용한 성능과 관련된 이론적인 부분을 많이 다루고, 여러 프로토콜에 대해 설명도 잘 되어 있어, 살펴 보고자 한다. 네트워크 성능에 가장 기본적인 지연시간(Latency)와 대역폭(bandwidth, 혹은 troughput)에 대해 이야기 한다.
레이턴시와 대역폭:
레이턴시는 데이터가 출발지에서 도착지까지 이동하는 데 걸리는 시간이다. 대역폭은 네트워크 경로에서 전송 가능한 최대 데이터 용량을 나타낸다. 이 두 요소는 웹 성능 최적화의 핵심 요소로, 서로 상호작용하며 웹 애플리케이션의 속도에 영향을 미친다. 아래 그림에서 볼 수 있듯이 레이턴시는 송신단과 수신단의 거리, 대역폭은 가장 성능이 낮은 링크의 영향이 큰 것을 예상할 수 있다.
레이턴시의 구성 요소:
전파 지연: 신호가 전송 매체를 통해 이동하는 데 걸리는 시간. 예를 들어 광섬유를 거치는 경우 빛의 속도.
전송 지연: 패킷이 링크를 통해 전송되는 시간. 전송할 데이터양과 연결하는 링크의 처리량에 따라 달라진다.
프로세싱 지연: 라우터 등이 패킷을 처리하는 데 걸리는 시간. 패킷 헤더의 정보를 처리하는데 필요한 시간.
큐잉 지연: 패킷이 처리 대기열에서 기다리는 시간.
이러한 것들이 합쳐져 전체 지연 시간이 된다.
광섬유와 네트워크 속도:
광섬유는 네트워크의 핵심 전송 매체로, 높은 대역폭을 제공하며 장거리 데이터 전송에서 중요한 역할을 한다. 빛의 속도가 빠르지만, 현실적 제약으로 인해 이상적인 속도에 도달하기 어렵다. 네트워크는 기술 발전으로 대역폭은 점차 증가하고 있으나, 레이턴시는 물리적 한계로 인해 큰 개선이 어려운 상황이다. 이를 극복하기 위해 프로토콜 최적화 및 캐싱, 프리페칭 등의 기술을 활용해야 한다. 대표적으로 이러한 상황에서 최적화 전략으로 Content Delivery Network(CDN)와 같은 기술을 활용해 데이터 전송 거리와 레이턴시를 줄이는 방법을 사용하고 있다.
라스트 마일
인터넷 트래픽의 대부분의 레이턴시는 대륙이나 바다를 건너는 메인 네트워크 구간이 아니라, 집이나 사무실에서 인터넷 서비스 프로바이더(ISP) 네트워크로 연결되는 마지막 구간(최종 몇 킬로미터)에서 발생한다. ISP의 연결 방식, 네트워크 토폴로지, 기술적 제한으로 인해 이 구간에서 지연이 크며, 네트워크 성능의 병목 현상이 자주 발생한다.
참고문서
[1] 일리아 그리고릭, "구글 엔지니어에게 듣는 네트워킹과 웹 성능 최적화 기법", 정해권, 오현주 공역, 인사이트(insight)
복잡계에 대해서 알게 되면서, 다른 분들께 소개 하기 시작하면서 어떻게 시작하지 고민하게 되었는데요. 돌아가시긴 했지만 당대의 유명한 물리학자라고 할 수 있는 스티븐 호킹 이야기를 안 할 수 없는 것 같습니다.
" I think the next century will be the century of complexity " " 나는 다음 세기는 복잡성의 세기가 될 것이라고 생각합니다."
이 분이 20세기 분이기 때문에, 지금 21세기가 복잡계의 세상이 될 것이라는 말씀을 하신거죠. 이게 상당히 의미 있다고 생각되는게, 물리학자로서 바라보는 흐름을 이야기 하신 것이라 이해합니다. 물리학은 뉴튼 물리학에서 시작해서, 상대성 이론 그리고 양자 물리학을 거쳐서 복잡성 과학에 기초해서 더 발전할 것이라는 기대와 특히, 학제간 연구 (Interdicipline Research)에 복잡성 과학의 적용이 많은 상황으로 이 부분을 언급하는 것이라고 생각합니다.
그런 의미에서도 우리가 복잡계를 알아두고, 혹은 조금이나마 아는척 할 수 있는 정도는 파악하는게 큰 의미 있다 생각이 됩니다.
관련 책소개
우선, 여기서 이야기드릴 내용[1]들은 이런 책들에서 나온 얘기들이에요. 사실 복잡계관련한 책은 더 많지만, 어떤 말씀들을 드릴까 고민을 하면서 항목들을 정리하다가 그 내용이 언급된 책들을 정리하다 보니 총 6권 정도가 되었습니다.
특히 매니지먼트 3.0[2]은 저에게 복잡계라는 주제를 처음 소개한 책입니다. 이 책은 애자일 그 마인드 셋에 기반해서 매니지먼트를 어떻게 할 것인가를 소개하는 책입니다. 즉, 기존의 관리를 이제 1.0 혹은 2.0이라고 하면 이제 애자일 매니지먼트를 3.0이라고 해서 설명하는 책이고, 이 책에서는 다른 애자일 책과는 다르게 이론과 실천법(Practice)들을 번갈아가며 소개하는데요. 여기서 복잡계에 대해서도 다룹니다.
그리고 전체를 보는 방법[3]도 이제 저희가 제가 이제 처음 거의 처음 복잡계 관련돼서 읽은 책중에 하나인데요. 뒤에 이야기 하겠지만, 집단 지성 혹은 전체주의(Holism)라는 부분에 대해서 소개를 하고 있습니다.
이제 복잡하지만 단순하게[4] 원제 Simply Complexity 이 책은 정말 잘 쓰여지고 여러 가지 정보를 다루고 있는 책이라고 생각합니다. 여러 분들이 한권만 읽겠다고 하면 이 책을 추천 드릴 것 같습니다. 그렇게 두껍지 않아서 읽는데 부담이 적고, 사례들도 많이 있고 흥미롭게 읽을 수 있을 것 같아서 권해드립니다.
반대로, 스케일[5] 은 굉장히 두꺼운 책이에요. 내가 복잡계 관련해서 좀 책을 봤어 하고 싶은 분은 도전해 보시는 것이 좋겠습니다. 특히, 이 책은 제가 좋아하는 TV 프로그램인 "알쓸신잡"에서도 정승제 교수가 "제프리 웨스트에 의하면..."이라고 이야기 하면서 인용하는 내용이 이책입니다. 간단히 설명하면 복잡계 특징을 가지는 사례들이 규모 변화에 대해서 설명하는 여러 내용이 포함되어 있습니다. 몇 가지 사례를 설명 드릴 겁니다.
링크[6]는 복잡계 네트워크 특히 이제 사람들 관계나 이런 것들에 대해서 기존 다른 네트워크와 복잡계 네트워크에 대해서 설명하고 있는 책입니다. 이를 기반으로 성공에 대해서 분석한 성공의 공식 포뮬라[7] 잠시 소개합니다.
문제를 바라보는 관점으로서의 복잡성
처음 말씀드린 것처럼 매니지먼트 3.0[2]에서 여러 원칙들과 이를 떠받드는 기반 원리에 대해서 설명하는데요. 아래 그림과 같은 마티(Martie)[8]의 오른쪽 다리가 Complexity Thinking입니다. 즉, 복잡성 기반으로 생각하는 것이 중요하다는 것입니다.
매니지먼트 3.0의 저자인 위르헌 아펄로는 구조, 행동 모델[8]을 통해서 문제를 어떻게 바라 보는지 자신만의 설명을 합니다. 행동 쪽에서는 질서(Order), 복잡(Complex), 혼돈(Chaos) 이렇게 나누고 있고,구조는 단순과 난해(Complicated)로 나누어서 설명합니다. 복잡에서 보면, 단순한 구조이면서 복잡한 것은 사람들과의 관계이고, 이것이 난해해지면, 도시 수준이 되는 것이라 볼 수 있습니다.
물론, 다른 유명한 의사 결정 프레임워크로서 커니빈 프레임워크(Cynefin Framework)도 소개합니다. 커네빈은 스코틀랜드 말을 기반으로 해서 스펠링으로 보면 발음에 대해서 알기 어렵습니다. 아는 척 하기 위해서 기억해 두셔야 합니다.
커네빈 프레임워크는 데이브 스노든이 이제 제안하는 의사결정 프레임워크인데 적어놓은 것처럼 관리자들이 상황을 인식하고 이 상황이 어떤 곳에 속하느냐를 인식을 하고 자신 및 사람들의 행동을 이해를 해서 의사결정을 돕기 위한 개념적인 프레임워크라고 할 수 있습니다. 문제를 어디에 포함된 것인지에 따라 다르게 접근하는 것으로 설명합니다.
여기서 얘기하는 4가지, 분명, 난해, 복잡, 혼돈만 있는 것은 아니고 디스오더라고 해서 여기 어느 곳에도 속하지 않은 상태도 있습니다. 하지만, 여기서 어느 한쪽으로 흘러가게 되어 있습니다.
분명인 경우에는 베스트 프랙티스를 사용하게 되는데요. 이 때는 문제에 대해서 인식(Sense)하게 되면 어느 Best Practice로 가야할지 분류(Categorize)를 하고 반응(Respond)하면 됩니다. 난해인 경우는 Good Practice로 인식(Sense)를 하게 되면 분석(Analyze)를 해서 실행(Practice)를 하면 됩니다.
복잡(Complex)인 경우는 노블 프렉티스(Novel Practice)라고 완전히 새로운 방법이 필요한 거죠. 그래서 접근하는 방법들이 좀 틀려요. 실험(Probe)하고 인식(Sense)해서 응답(Resond)해야 한다는 접근법을 제안합니다.
혼돈의 경우는 사고 상황과 같은 것을 고려할 수 있는데요. 이 때는 우선 행동(Action)해야 합니다. 우리가 죽을 수도 있는 상황이니까요. 그리고 나서, 인식(Sense)하고 응답(Respond)합니다. 이런 것들을 나눠서 하자는 게 이제 어떻게 보면 커네빈 프레임워크 그리고 복잡계를 고려한 접근법의 제한 사항이라 볼 수 있습니다.
정의 및 개념
제가 복잡계에 대해서 알게된 상황이나 애자일에 대해 연결된 부분을 이야기 드렸습니다. 그렇다면 도데체 복잡성이란 무엇일까요?
"복잡하지만 단순하게" 나온 얘기인데요, 이런 격언이 있다고 합니다.
"둘이면 좋아도 셋이면 너무 많다."
이 많다는 것이 복잡하다 이런 뜻이기도 한데요. 복잡성 혹은 복잡성 과학의 정의는 "상호작용"을 하는 "개체"들의 집합에서 발생하는 "창발(Emegence)"하는 특징 혹은 그 특징에 대해 연구하는 학문이라고 할 수 있습니다. 여기서, 여기서 상호작용은 이제 피드백 혹은 기억이라고 하고, 창발은 개체들에서 볼 수 없지만 그룹이나 전체로 보면 발견되는 것, 그러한 특징이라 할 수 있습니다.
크게 어떻게 보면은 또 복잡계는 두 개로 나눠서 설명을 합니다. 하나는 복잡 적응계(Complex Adaptive System, Adaptive Complex Syste) 혹은 복잡 비적응계(Non-adaptive Complex System)이다. 복잡 적응계는 피드백에 다르게 반응하고, 비적응의 경우는 다르게 반응하지 않는 것입니다. 개미와 같은 생명체는 전자이고 싱크대에서 물이 내려가면서 만드는 소용돌이를 후자로 분류합니다.
연구 사례에는 지구 온난화, 교통 체증, 시장 폭락, 바이러스, 암, 전쟁, 테러, 군중, 홍수, 폭염, 태풍, 가뭄, 인터넷 과부하, 대정전 사태가 소개됩니다. 대부분의 상황은 여러 존재들이 식량, 공간, 에너지, 권력, 부 등 "한정된 자원을 놓고 경쟁하는 상황"이 핵심이라고 볼 수 있습니다.
보통 책들에서는 두 가지 다 다루고 있는데 저희가 관심 있는 건 사실은 복잡적응계입니다. 생명체가 있다거나 이런 좀 관련돼 있는 개미 무리 같은 게 그런 게 될 수 있죠.
환원론 vs 전체론
복잡계를 얘기할 때 또 설명하지 않을 수 없는 것 중에 하나가 환원론(Reductionism)과 전체론(Holism)입니다.
자료[1]에 있는 것 처럼 오리에 대해서 살펴 봅시다. 이 오리를 분해해 보는 거죠. 입이 있고, 식도가 있고 이런 식으로 말입니다. 사실 그렇다면 왼쪽에 있는 것과 살아 있는 오른쪽 오리와 다르지 않을 수 있습니다. 이렇게 보는 것이 환원론입니다.
하지만, 전체론은 오리를 나눠봐도 살아 있는 것이 아니고 이러한 부분이 모여서 살아 있는 오리가 다르다는 것입니다. 이렇 듯, 복잡계에서는 여기서 말씀드린 것처럼 전체론으로 살펴보고 있습니다.
복잡계로서의 무리(Swarm)
전체를 보는 방법에서 재미있는 것 중에 하나는 복잡계로서의 무리 이 집단 지성에 대해서 다루는 챕터가 있습니다. 사실 흥미로운 비디오[10]를 찾아서 첨부했습니다. 개미와 같은 무리가 지능을 가진 것처럼 움직인다는 예입니다.
개미와같은 경우 여왕개미가 있어가지고 지시하는 대로 움직인다 이렇게 생각할 수 있겠지만 전혀 그렇지 않거든요. 벌 같은 경우도 분봉을 할 때 결국 이제 벌의 무리가 하나로 이렇게 성장을 하다가 다른 쪽으로 나가서 자리를 잡으려고 할 때 장소를 선별하거나 이런 것도 우리가 이제 그것들을 이제 선정을 하고 조사가 되면 중앙의 지시 없이 적절한 장소로 이동해서 나눠집니다.
그리고 벌집의 온도를 조정하는 것도 어떻게 보면 뭐 여왕벌이 더워, 그러니 조절해 이렇게 하는 게 아니고 벌들의 이제 다양한 센서들이 달라서 자기들이 특정한 온도로 이렇게 맞춰져 가게 되는 다양성에 의해서 안정화가 된다는 겁니다. 이런 것들이 단순한 규칙과 피드백들로 이루어 진다는 것입니다.
또 특징적인 것 중에 하나가 이제 자기 조직화 특징이 있습니다. 앞에서도 이야기 한 것 처럼 중앙 통제가 없어요. 자기가 이제 알아서 이렇게 되게 되는 거죠. 그래서 이 비디오를 보시면 어떤 물건을 이제 이상하게 생긴 물건을 이제 옮기는 건데 사람들이 몇 명의 사람들이 같이 움직이는 거 결국 사람들이 생각하는 거 하고 개미들이 이렇게 움직이는 거하고 보여주는 지성이 다르지 않다는 거죠.
최근에 드라마 중에 이제 삼채, 3 body problem도 삼채인이 인간들과 좀 다른 부분이 있는 것 같아요. 삼채인들이 인류를 버그 벌레라고 불렀긴 하지만 결국 그 삼체인들이 좀 굉장히 작은 크기 쌀알 크기라고 알려져 있고 마치 이런 자기들이 실제로 이런 곤충들처럼 굉장히 어려운 각박한 환경에서도 생존하고 인류보다 더 높은 지성을 키워왔던 그런 생명체로서 가능하지 않겠나 이런 생각이 듭니다. 그래서 어떻게 보면 이것이 물론 SF이지만 현실성 있는 가능성 있는 실현성이 있는 상상력이 아닌가 이런 생각이 듭니다. 그래서 이 비디오를 한번 살펴보시면 이 물건들을 옮기는 집단지성 개미들이 보여주는 집단지성에 놀라실 수도 있을 것 같습니다.
복잡계에서의 체계적 크기 변화(Scale)
이제 스케일[5]에 나온 얘기인데요. 복잡계의 체계적인 규모 변화에 대해서도 설명을 합니다.
그래서 복잡계의 특징으로서는 기본적으로 규모 변화에 대해서는 익스포넨셜(exponential)이다라는 것입니다. r^k로 이제 설명을 하는데 동물 크기 심장 박동 수 수명 이런 것들을 설명을 합니다. 그래서 실제로 이제 설명할 때 고질라가 실제 같은 크기가 가능하냐 라는 부분에 대해서 증명을 하는데 불가능하다라는 게 이제 그런 부분이에요. 이렇게 보면 이제 포유류로서의 그 크기 심장을 가지고 이렇게 그렇게 그 기관들을 가지면서 할 수 있는 뼈나 이런 것들 지금 가장 큰 크기를 가질 수 있는 포유류는 고래라는 거죠. 대략 34m 이 정도 되는 그런 고래 정도 크기가 최대이고 이거보다 클 수 있는 거는 불가능하다라는 부분에 대해서 또 설명을 하고 있어요.
그리고 도시의 크기와 창의성의 관계 같은 경우도 지수가 아까 여기 보여준 것처럼 약 k가 1.15 정도 보여주는 특징들을 살펴보실 수가 있습니다. 이런 것들이 이제 예로써 스케일이 굉장히 많이 나오는데 재미있는 것 중에 하나가 이 책도 제가 또 흥미롭게 봤던 알쓸신잡의 정재승 박사가 이제 설명할 때 보면 "제프리 웨스트에 의하면.." 이라고 얘기했던 그 부분이 이 스케일에 대해서 언급을 한 부분으로 아실 수가 있습니다.
이것도 굉장히 두꺼운 책이나 사실은 복잡하게 이런 정도 얘기만을 알고 계셔도 아는 척하기에는 딱 적절할 수 있다 이런 생각이 드네요.
복잡계 네트워크
복잡계 얘기를 할 때 복잡계 네트워크를 얘기를 안 할 수가 없을 것 같습니다. 이유 중에 하나는 이제 사람들이 얽혀 있는 네트워크이 그런 거기 때문에 저희가 또 애자이나 이런 쪽에 관심을 가지고 본다고 하면 그 얘기를 하지 않을 수 없고 이 이제 스케일 프리 네트웍크이라는 얘기가 이 스케일이나 링크 이제 성공의 공식 포뮬러[7]에 나옵니다.
[1]에서 보시는 것처럼 랜덤 네트워크(Randome network)나 이제 스케일 프리 네트워크(Scale-free network)을 비교할 수 있습니다. 스케일 프리 네트워크의 정의를 잘 살펴보면 연결 선의 수의 분포가 멱 법칙을 가집니다.그러니까 결국은 이 연결을 많이 가진 녀석들이 존재해요. 그래서 그걸 허브라고 하는데 이 허브들이 있고 해서, 연결이 끊어 지거나 네트워크가 망가지더라도 회복력이 좋습니다.
그리고, 실제 인간 네트워크이고 보면 좁은 세상 이제 법칙이라고 케빈 베이컨 법칙이라는 게 있습니다. 그래서 여섯 단계에 분리돼 있다. 결국 무슨 얘기냐면 여러분과 이제 몇 단계만 넘어가면 이제 다 안다는 거죠. 쉽게 얘기해서 내가 어떻게 보면은 미국 대통령을 어떻게 알 거냐 라고 하면 내가 아는 분 중에 어떻게 보면 고위 공직자분하고 연결이 돼 있고 그 고위 공직자가 이제 대통령하고 연결돼 있고 대통령이 미국 대통령하고 연결돼 있기 때문에 그런 단계들을 몇 개 넘어가 보면 알기 어려운 분도 연결될 수 있다는 것이죠.
이게 좁은 세상 어떻게 보면 인간 네트워크들이 이렇게 굉장히 좀 작다는 부분이기도 하고 이런 것 때문에 어떻게 보면은 이런 허브들이 많이 가져가게 되기 때문에 승자 독식이라는 부분, 그 다음에 빈익빈 부익부 이런 현상들이 생기는 부분들 그런 것들을 보실 수가 있습니다.
성공의 공식 포뮬라에서도 이제 그런 얘기들을 하는데 여러 법칙들 중에 여기 관련된 것들을 볼 수 있는 것은 1 법칙: 성과는 성공의 원동력이지만 성과를 측정할 수 없을 때는 연결망이 성공의 원동력이 된다 라는 것이죠. 그러니까 결국에 어떻게 연결돼 있는가 누구랑 연결돼 있는가 그런 부분들을 이제 성공의 공식 포뮬러에서 얘기를 하고 있거든요. 그리고, 제 4 법칙 같은 경우는 이제 팀이 성공하려면 다양성과 균형 결국 이제 네트워크들이 튼튼하게 하게 하려는 것이 필요하지만, 팀이 성과를 올리면 오직 단 한 사람만의 공을 독차지한다 이런 얘기가 또 나오게 되어 있습니다.
또 복잡계 네트워크인 스케일 프리 네트워크를 보실 때도 미국 비행기 망이 그런 특징을 가지고 있습니다. 그러니, 허브 공항들이 있습니다. 여기 보면은 아마 LA하고 시카고하고 뉴욕도 보일 겁니다.
다시, 조직의 네트워크를 살펴 보기 위해, 매니지먼 3.0으로 돌아보면 실제로 이제 권한(Hierarchy)이 존재하지만 네트워크 또 어떻게 보면 좀 다른 걸 수도 있습니다. 이런 상황에서 결국 허브가 되는 사람들이 있다는 것입니다.
마무리
이렇게 복잡계에 대해서 살펴 볼 때에도 사실은 제가 관심 있는 부분인 애자에서 시작해서 보게 됐습니다. 여기 있는 애자일 개발 선언문에서도 여러 가지 부분들을 이제 앞에 설명드렸던 것들을 이해를 할 수 있을 것 같습니다.
결국에는 이제 여기서 강조하는 것도 공정과 도구보다는 개인과 상호작용이 더 중요하다는 부분으 이제 복잡기 안에 있을 때 개인일 수밖에 없고 그거에 대해서 어떻게 보면 더 좋은 저희가 그 복잡한 상황들을 잘 이해하려면 상호작용에 집중해야 한다는 것으로 이해할 수 있습니다.
그리고, 저희가 문서보다는 저희가 작동하는 소프트웨어를 더 강조하는 부분과, 고객이라는 것도 저희 팀으로 본다거나 아니면 환경으로 본다고 하더라도 그 상호작용을 통해서 복잡계로 이해하면 협력을 더 할 수밖에 없는 것이라 생각됩니다.
커네빈 쪽으로 살펴보더라도 아니면 저희가 이제 복잡해서 커니벤 프로임 워크로 문제 해결할 때 대응하는 방식을 하더라도 복잡하다는 상황이라면 결국에는 뭔가 실험하고 거기에 대해서 어댑트 하는 부분들이 필요하다. 결국에는 이제 이런 것들이 저희가 복잡계 과학에서 보듯이 대응하는 방법으로 이제 대응하는 것들을 거기에 활용하는 것들을 복잡기를 가지고 조금 더 이런 것들이 왜 더 중요한지에 대해서 이해할 수 있는 그런 부분이 있기 때문에 어떻게 보면은 애자일과 애자일을 이해하는데 복잡계에 대한 것들이 기본적으로 이해되는 것들이 필요하다고 생각이 되고요.
다시 돌아가서 그런 의미에서 매니지먼트 3.0에서도 어떻게 보면 복잡계를 소개하고 또 매니지먼트 3.0을 바치는 중요한 축으로 설명하는 거라고 생각이 듭니다. 그래서 이 정도만이라도 알고 계셔도 여러 책들을 읽어서 알게 되시는 기본적인 지식들을 아시는 것이라 할 수 있습니다. 그래서, 좀 아는 척하시기 딱 좋지 않을까 이렇게 생각돼서 소개드려봅니다.
소프트웨어 아키텍처에 대해서 학습을 하다가 보면, 정말 많은 문서 작업을 요구한다. 정말 이런 것들이 다 필요한 것일까? 정말 다 줄이고 하나만 남긴다면 무엇을 할 수 있을까? 아니면 아예 문서 작업을 하지 않으려 한다면 그래도 이건 꼭 해보자면 무엇을 이야기할 수 있을까?
애자일 하게 개발을 진행하는 조직에서 요구 사항도 취합되어 백로그에 유저 스토리들이 쌓여 있다고 해보자. 이렇게 개발하다 보면, 자연 스럽게 개발자 수준에서 설계도 되어 우리 팀의 아키텍처가 내재되어 나오게 된다.
하지만, 위의 상황은 상당히 이상적이다. 여러 담당자들이 구현을 해 가다 보면, 이상하다고 느껴지는 부분이 생기곤 한다. 진행이 안되고 막혀 있다는 부분이 있다. 이러한 부분은 의사 결정이 필요할 수도 있고, 실험을 통해서 확인이 필요할 수도 있다. 여기서는 의사 결정을 해야 하는 경우에 대해서 다뤄보자. 이를 위한 것이 아키텍처 의사 결정이고 이를 기록하는 것이 아키텍처 의사 결정 레코드 (Architectural Decision Record)이다.
이렇게 Architect는 의사 결정자나 이해관계자(Stakeholder)가 결정할 수 있또록 정보를 제공하여 결정을 지원하거나, 책임이 자신에게 있다면 기술적인 결정을 해야 한다. 그렇다면, 무엇을 가지고 어떻게 할 수 있을까?
아키텍처 의사 결정 기록 (ADR)소개
이와 같은 경우를 위해 활용할 수 있는 것이 다음과 같은 아키텍처 의사 결정 기록(Architectural Decision Record, ADR)이다. [1]에서는 ADR의 아주 간단한 형식을 보여 준다.
[기능 또는 컴포넌트]에 해당하는 맥락에서, [요구 사항 또는 목표로 하는 품질 속성(Quality Attribute)]을 충족할 필요가 있다, 우리는 [이익]을 우선적으로 달성하기 위해 [선택된 옵션]을 채택하기로 결정하고 그리고 [대안]은 선택하지 않아서 그 선택에 따르는 [부정적인 결과]는 받아들인다.
이 내용은 아주 간단하게 기술되어 있다. 그렇기 때문에 다음과 같이 나누어 상세 한 부분을 살펴 볼 수 있다.
Problem Statement: "[기능 또는 컴포넌트]에 해당하는 맥락에서,"가 이 부분이다. 우리가 결정이 필요한 문제가 어떤 것인지 말한다. 위의 예에서는 간단하게 되어 있지만, 맥락을 잘 표현하기 위해서 더 상세히 설명해야 할 수도 있다.
Candidate Architecture: 위의 예에서는 [선택된 옵션]과 [대안]이 여기에 포함된다. 위의 예어서는 2개만 표현되어 있지만 3개 이상일 수 있다. 특히, 옵션들은 정말로 어떤 것을 선택할지 고민이 된다면 중요한 Architecture Problem일 수 있다.
요구 사항 및 품질 속성: 많은 경우, Problem Statement에 우리가 다루려고 하는 Functional Scenario가 이미 포함된다. 아키텍처 선택을 할 때 우리가 고려해야 하는 품질 속성의 중요도에 따라 의사 결정을 하는 것이 일반적이다.
보완 필요 부분: "부정적인 결과"를 받아 들인다고 했다. 하지만, 이 부분이 늘 쉽지는 않다. 그렇기 때문에 이 부정적인 결과에 대한 대책이 필요하기도 하다.
패턴들의 구조에서도 설명되지만 문제 기술도 필요하다. 위의 구조와 유사하지만 다음과 같은 형태도 사용한다
다른 형태의 ADR
위와 같이 간단한 형태에서 상세 내용을 기반으로 조정한 ADR이 포함해야 하는 항목을 다시 한번 정리해 보자.
Problem Statement
이 부분을 분리하는 경우는 ADR이 다루려고 하는 문제를 더 상세히 표현하려고 할 때 분리해서 설명하면 좋다. 그렇지 않고, 간단한 문장으로도 표현할 수 있다.
Candidate Architectures
우리가 실제로 고민해야 하는 Architecture적으로 중요한 결정 사항은 무엇일까? 대안들이 2개 이상일 때 Architecture 적으로 중요한 문제일 수 있다. 예를 들어 보자. 어려 이해관계자들이 요구 사항의 충돌이 있을 때, 이 부분을 조정하여 결정해야 하는 사항이다.
간단한 사례
간단한 사례로 "학교 프로젝트를 만들기 위한 발표 자료를 어떻게 준비할까?"를 예로 들어 ADR 형식으로 만들어 보자.
손으로 직접 그림 그리기
파워포인트 슬라이드 사용
큰 포스터로 만들기
장점 (만족하는 품질 속성)
창의적이고 독창적임. 준비 비용이 적음
수정이 쉽고 깔끔함 팀과 쉽게 공유 가능
시각적으로 강렬함 한눈에 보기 좋음
단점 (손해보는 품질 속성)
시간이 오래 걸림 수정이 어려움
컴퓨터가 필요함 디자인에 시간 소요
운반이 불편함 수정이 어려움 큰 공간 필요
이해관계자인 팀원들과 수정이 쉽고 깔끔하게 보이고, 팀원들과 쉽게 공유하고 의견을 주고받을 수 있기 때문에 파워포인트 슬라이드 사용하기로 의사 결정하였다. 이렇게 의사 결정 했을 때에는 디자인에 시간이 소요되고 컴퓨터가 필요하다는 것을 알고 있다. 다지안의 경우는 미리 제공되는 템플릿을 최대한 활용하여 시간을 절약하기로 하였고, 디자인 감각이 있는 팀원이 디자인은 전담하기로 역할 분담을 하였다. 발표에도 컴퓨터가 필요하기 때문에 컴퓨터가 필요하다는 것을 확인하였고 팀원 중 한명이 준비하기로 하였다.
아마도 다른 옵션들을 선택하는 경우도 있을 수 있다. 제약으로 컴퓨터를 사용하지 못할 경우도 있고, 포스터 세션처럼 운용될 수도 있어서 다른 옵션을 선택해야만 하는 경우도 있을 수 있다. 즉, 다른 옵션들도 의미 없이 그냥 만든 것이 아니고 많은 고민을 해야 하는 옵션들인 것이다.
결론
위에서 살펴 본 것과 같이 ADR에 대해서 살펴 보았고, 아주 간단한 사례를 통해서 여러 옵션들을 도출하고 이를 비교해서 의사 결정을 하는 사례도 살펴 보았다.
참고 문헌
[1] 올라프 짐머만, 미르코 스토커, 다니엘 뤼브케, 우베 즈둔, 세자레 파우타소, "마이크로서비스 API 디자인 패턴, 쉬운 통합을 위한 결합도 최적화 전략" 에이콘출판, 이승범 (옮긴이)
