들어가며

복잡계에 대해서 알게 되면서, 다른 분들께 소개 하기 시작하면서 어떻게 시작하지 고민하게 되었는데요. 돌아가시긴 했지만 당대의 유명한 물리학자라고 할 수 있는 스티븐 호킹 이야기를 안 할 수 없는 것 같습니다. 

" 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을 바치는 중요한 축으로 설명하는 거라고 생각이 듭니다. 그래서 이 정도만이라도 알고 계셔도  여러 책들을 읽어서 알게 되시는 기본적인 지식들을 아시는 것이라 할 수 있습니다. 그래서, 좀 아는 척하시기 딱 좋지 않을까 이렇게 생각돼서 소개드려봅니다.

참고 도서

[1] 아는척 하기 딱 좋은 복잡계 이야기, https://docs.google.com/presentation/d/1F6EffbTvYQxBiP2gN5dPaSflu3FlC8nOS0JFIRpeGjo/edit#slide=id.g2264d6f5244_0_56
[2] 위르헌 아펄로, "매니지먼트 3.0 - 새로운 시대, 애자일 조직을 위한 새로운 리더십", 에이콘 출판, 조승빈 옮김.
[3] 존 밀러, "전체를 보는 방법 - 박테리아의 행동부터 경제현상까지 복잡계를 지배하는 핵심 원리 10가지", 에이도스, 정형채,최화정 옮김
[4] 닐 존슨, "복잡하지만 단순하게 - 복잡한 세상에도 패턴은 있다", 바다출판사, 한국복잡계학회 옮김
[5] 제프리 웨스트, "스케일 : 생물.도시.기업의 성장과 죽음에 관한 보편 법칙", 김영사, 이한음 옮김

[6] 알버트 라슬로 바라바시, "링크: 21세기를 지배하는 네트워크 과학" 동아시아 

[7] 앨버트 라슬로 바라바시, "성공의 공식 포뮬러", 한국경제신문,  홍지수 옮김
[8] Mamagement 3.0 Foundation Workshop, https://management30.com/workshops/foundation-workshop/
[9] How Complexity Leads to Solutions (Cynefin Framework and the Structure-Behavior Model),  https://management30.com/blog/complexity-solutions-cynefin/
[10] Human vs Ants, https://youtu.be/ZHpu7ngQxwE?si=l7-PLmhJKSi9neR2

개요

소프트웨어 아키텍처에 대해서 학습을 하다가 보면, 정말 많은 문서 작업을 요구한다. 정말 이런 것들이 다 필요한 것일까? 정말 다 줄이고 하나만 남긴다면 무엇을 할 수 있을까? 아니면 아예 문서 작업을 하지 않으려 한다면 그래도 이건 꼭 해보자면 무엇을 이야기할 수 있을까?

애자일 하게 개발을 진행하는 조직에서 요구 사항도 취합되어 백로그에 유저 스토리들이 쌓여 있다고 해보자. 이렇게 개발하다 보면, 자연 스럽게 개발자 수준에서 설계도 되어 우리 팀의 아키텍처가 내재되어 나오게 된다. 

하지만, 위의 상황은 상당히 이상적이다. 여러 담당자들이 구현을 해 가다 보면, 이상하다고 느껴지는 부분이 생기곤 한다. 진행이 안되고 막혀 있다는 부분이 있다. 이러한 부분은 의사 결정이 필요할 수도 있고, 실험을 통해서 확인이 필요할 수도 있다. 여기서는 의사 결정을 해야 하는 경우에 대해서 다뤄보자. 이를 위한 것이 아키텍처 의사 결정이고 이를 기록하는 것이 아키텍처 의사 결정 레코드 (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 디자인 패턴, 쉬운 통합을 위한 결합도 최적화 전략" 에이콘출판, 이승범 (옮긴이)  

개요

리엔지니어링 패턴의 10장 다형성 적용한 조건문 변환은 객체 지향 리엔지니어링 패턴 중에서 조건문을 다형성으로 변환하는 데 중점을 둔다. 이러한 변환은 시스템의 유연성과 유지 보수성을 높이는 데 기여하며, 다양한 조건문을 대체할 수 있는 6가지 주요 패턴을 제시한다. 각 패턴은 특정 상황에서 반복적으로 발생하는 문제를 해결하기 위해 설계되었다.

주요 패턴 요약

  1. 자신 타입 체크 변환하기
    • 클래스의 타입을 검사하는 조건문을 각 타입에 맞는 서브클래스와 다형성 메서드 호출로 대체하여 확장성을 개선한다.
  2. 클라이언트 타입 검사 변환하기
    • 클라이언트 클래스에서 특정 프로바이더 타입을 검사하는 조건문을 제거하고, 각 프로바이더에 새로운 메서드를 추가하여 결합도를 줄인다.
  3. 상태 추출하기
    • 상태(State) 디자인 패턴을 적용하여 객체의 상태에 따라 다른 동작을 수행하도록 하며, 상태를 별도의 클래스 객체로 캡슐화하여 유지 보수성을 향상시킨다.
  4. 전략 추출하기
    • 전략(Strategy) 패턴을 적용해 알고리즘을 캡슐화하고, 조건문을 대체하여 다양한 전략을 동적으로 교체할 수 있도록 한다.
  5. 널 객체 도입하기
    • 널 값을 검사하는 조건문을 널 객체로 대체하여 클라이언트 코드의 간소화 및 가독성을 높인다.
  6. 조건문을 등록으로 변환하기
    • 도구와 클라이언트 간의 결합도를 낮추기 위해 조건문을 등록(Registration) 메커니즘으로 대체하여 모듈화와 유연성을 개선한다.

이 패턴들은 조건문을 다형성으로 변환하여 코드 중복을 줄이고, 향후 시스템 확장을 보다 유연하게 할 수 있도록 한다.

 

참고 문헌
[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"
[2] https://github.com/blcktgr73/OORP

리엔지니어링 패턴의 9장 책임 재배치는 기존 시스템의 클래스와 객체들이 지나치게 많은 책임을 갖거나, 너무 적은 책임만 수행하는 문제를 해결하는 방법론이다. 세 가지 주요 패턴에 대해 이야기 한다.

  1. 동작을 데이터 가까이 이동하기
    데이터 컨테이너에서 행동을 수행하는 클라이언트 클래스에 정의된 행동을 데이터가 있는 곳으로 이동하여 캡슐화를 강화하는 방식이다. 이를 통해 클라이언트가 데이터 구조에 대한 직접적인 의존을 줄이고, 코드 중복을 줄이는 효과가 있다. 이 패턴은 데이터 컨테이너를 더욱 객체답게 만들고, 클라이언트 코드의 유지 보수를 쉽게 한다.
  2. 탐색 코드 제거하기
    객체 간 탐색을 줄여 클래스 간 결합도를 낮추는 패턴이다. 특정 객체의 속성에 접근하기 위해 여러 단계를 거쳐야 할 경우, 탐색 코드를 데이터 컨테이너 내로 옮겨 캡슐화를 높인다. 이를 통해 클래스 간의 불필요한 종속성을 줄이고, 변경의 영향을 최소화할 수 있다.
  3. 신 클래스(God Class) 분할하기
    하나의 클래스에 지나치게 많은 책임이 집중된 경우, 이를 여러 작은 클래스로 분리하는 방법이다. 신 클래스는 여러 기능을 담당하며, 시스템의 모든 제어를 맡아 비대해진 클래스이다. 이를 분할하여 각 기능을 적절한 클래스에 배분함으로써 유지 보수성을 높이고, 객체 지향 설계를 강화할 수 있다.

이 세 패턴은 책임을 올바르게 분배하고, 코드의 응집도와 캡슐화를 개선하는 데 중점을 두고 있다.

 

참고 문헌
[1] Serge Demeyer et al., "Object-oriented Reengineering Patterns"
[2] https://github.com/blcktgr73/OORP

[1]의  9장에서는 API의 계약 문서화와 이해 관계자들과 커뮤니케이션을 위한 패턴을 다룬다.

1. API 설명

  • 설명: API의 기능, 메시지 구조, 동작의 의미 등을 문서화하여 클라이언트 개발자가 이해할 수 있도록 한다. OpenAPI와 같은 기술적 계약 설명 언어를 사용할 수 있다.
  • 주요 특징:
    • 상호 운용성 보장
    • 정보 은닉 유지
    • 확장성과 진화 가능성 지원
  • 포스의 충돌:
    • 지나치게 복잡한 설명은 유지보수에 어려움을 주고, 간단한 설명은 상호 운용성을 해칠 수 있음.
    • 정보 은닉과 상호 운용성 사이의 균형을 유지해야 함.

2. 요금 책정 플랜

  • 설명: API 사용량에 따라 요금을 청구하는 플랜을 정의하는 패턴. 구독 기반 요금제, 사용량 기반 요금제 등이 있으며, 고객의 사용량을 정확히 측정하고 요금 부과.
  • 주요 특징:
    • 경제적 측면, 정확성, 세분성, 보안 등의 고려 필요
    • 구독형, 사용량 기반, 시장 기반 등의 요금제 변형 가능
  • 포스의 충돌:
    • 사용량 측정과 청구의 정확성을 유지하면서, 비용 효율적인 방법을 찾아야 함.
    • 고객의 만족과 프로바이더의 수익성 사이의 균형 유지 필요.

3. 사용 비율 제한

  • 설명: 클라이언트가 API를 과도하게 사용하는 것을 방지하기 위한 패턴. 주기적으로 재설정되는 간격 기반 전송률 제한을 사용하여 과도한 요청을 차단하거나 제한.
  • 주요 특징:
    • 경제적 측면과 성능 보장
    • 남용 방지 및 신뢰성 유지
  • 포스의 충돌:
    • 너무 엄격한 제한은 사용자의 불만을 초래할 수 있으며, 너무 느슨한 제한은 시스템의 안정성을 해칠 수 있음.
    • 서비스 품질과 클라이언트의 자유로운 사용 사이의 갈등을 조율해야 함.

4. 서비스 수준 계약 (SLA)

  • 설명: API가 제공하는 서비스의 품질을 명시적으로 정의한 계약. 특정 서비스 수준 목표(SLO)를 포함하여, 이를 충족하지 못했을 때의 벌칙이나 보상 등을 규정.
  • 주요 특징:
    • 가용성, 성능, 보안, 법적 준수 등의 품질 특성 측정 가능
    • 소비자 관점에서의 매력도 향상
  • 포스의 충돌:
    • 높은 품질 보증은 프로바이더에게 높은 비용과 위험을 수반할 수 있음.
    • 클라이언트의 신뢰를 얻으면서도 비용 효율적인 방법을 찾아야 함.

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의  8장에서는 다룬 API 진화 패턴을 다룬다. 각 패턴에 대한 설명, 주요 특징, 그리고 충돌하는 요구 사항(포스)을 포함한다.

변경 사항 도입 패턴:

  1. 공격적 폐기
    • 설명: 이전 버전을 빠르게 폐기하고, 클라이언트에게 빠르게 신규 버전으로 전환하도록 강제.
    • 주요 특징:
      • 사용 빈도가 낮은 기능을 신속히 제거.
      • 유지 관리 비용 절감.
      • 최신 버전 채택 촉진.
    • 포스:
      • 신속한 혁신과 클라이언트 안정성 간의 균형.
      • 빠른 전환이 어려운 클라이언트와의 충돌 가능성.
  2. 실험적 미리 보기
    • 설명: 초기 버전을 미리 공개하여 클라이언트가 테스트하고 피드백을 제공할 수 있게 함.
    • 주요 특징:
      • 초기 채택과 피드백 장려.
      • 정식 출시 전 API를 개선할 수 있음.
    • 포스:
      • 불안정한 기능 노출의 위험.
      • 기능의 안정성과 클라이언트 기대치 관리 필요.
  3. 2개의 상용 버전
    • 설명: 기존 버전과 새로운 버전을 동시에 유지하여 점진적인 전환 지원.
    • 주요 특징:
      • 클라이언트의 중단 없는 전환 가능.
      • 역호환성 제공.
    • 포스:
      • 여러 버전을 유지 관리하는 데 필요한 자원 증가.
      • 새로운 기능과 이전 버전 지원 간의 균형.
  4. 제한적 수명 보장
    • 설명: API 버전의 지원 기간을 명확히 설정.
    • 주요 특징:
      • 버전 지원 종료 시점을 명확히 하여 클라이언트의 계획 수립 도움.
    • 포스:
      • 클라이언트의 기대치와 실제 지원 기간 간의 조율 필요.
      • 더 긴 지원이 필요한 클라이언트와의 충돌 가능성.
    •  

버전 표시 패턴:

  1. 버전 구분자
    • 설명: 명확한 버전 식별자를 사용하여 API 업데이트 구분.
    • 주요 특징:
      • 역호환성 관리.
      • 클라이언트가 특정 버전을 선택할 수 있게 함.
    • 포스:
      • 버전 관리 규칙의 엄격한 제어 필요.
      • 여러 버전이 동시에 사용될 때의 어려움.
  2. 시멘틱 버전 관리
    • 설명: 구조화된 버전 체계(예: major.minor.patch)를 사용하여 변경의 성격을 표시.
    • 주요 특징:
      • 버전 간 호환성 이해를 간편하게 만듦.
      • 중요한 변경 및 신규 기능을 명확히 신호.
    • 포스:
      • 새로운 기능 추가와 역호환성 유지의 균형 필요.
      • 일관된 버전 규칙 준수가 요구됨.

호환성 보장 패턴:

  1. 서비스 수준 계약(SLA)
    • 설명: API의 가용성, 성능 및 지원에 대한 명확한 기대치를 설정.
    • 주요 특징:
      • 클라이언트에게 안정성을 보장.
      • 신뢰성과 가동 시간 기준 설정.
    • 포스:
      • 안정성을 보장하면서 지속적인 개선을 하는 것의 충돌.
      • 높은 기준을 유지하기 위한 비용 부담.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의  7장에서는 주로 메시지 설계 품질을 개선하는 다양한 패턴과 접근 방식을 설명한다. API의 직관적 이해, 성능, 진화 가능성과 같은 품질 요소의 중요성을 설명하며, 성능과 보안, 확장성 등의 상충하는 요구 사항 사이에서 균형을 맞추는 방법을 다룬다. 패턴을 크게 나누면, 케시지 크기 및 요청 수 조정, 참조 관리 그리고 제어 및 표현 정도에 따른 패턴으로 구분할 수 있다. 각 패턴의 설명과 주요 특징, 그리고 패턴 적용 시 발생할 수 있는 주요 요구 사항인 '포스(force)' 충돌에 대해 요약한다.

메시지 크기 및 요청 수 조정하기를 위한 패턴

  1. 요청 번들
    • 설명: 여러 작은 요청을 하나의 큰 요청으로 묶어 클라이언트가 여러 번의 요청을 보내지 않도록 한다.
    • 주요 특징:
      • 네트워크 대역폭 절약
      • 응답 지연 시간 감소
      • 클라이언트 구현 단순화
    • 포스의 충돌:
      • 처리 복잡성 증가 vs. 성능 최적화
      • 클라이언트-서버 간 데이터 일관성 유지 필요
  2. 조건부 요청
    • 설명: 클라이언트가 이미 보유한 데이터와 서버의 데이터를 비교하여 변경된 데이터만 전송받도록 한다.
    • 주요 특징:
      • 네트워크 사용량 감소
      • 서버 및 클라이언트 간 데이터 일관성 유지
    • 포스의 충돌:
      • 효율성 vs. 추가 구현 복잡성
      • 상태 관리 필요성 증가
  3. 페이지네이션
    • 설명: 대량의 데이터를 청크로 나누어 클라이언트가 순차적으로 필요한 데이터만 가져오게 한다.
    • 주요 특징:
      • 대용량 데이터의 효율적 전송
      • 클라이언트의 메모리 사용 최적화
    • 포스의 충돌:
      • 데이터 최신성 vs. 성능 최적화
      • 네트워크 안정성과 리소스 사용 조정 필요

참조 관리의 대안으로서 패턴

  1. 임베디드 엔티티
    • 설명: 필요한 데이터를 응답 메시지에 직접 포함하여 클라이언트가 추가 요청 없이 필요한 모든 데이터를 얻도록 한다.
    • 주요 특징:
      • 관련 데이터의 한 번에 전송
      • 클라이언트-서버 간 추가 요청 최소화
    • 포스의 충돌:
      • 데이터 일관성 vs. 메시지 크기 증가
      • 전송 시간 증가와 대역폭 소비
  2. 링크된 정보 보유자
    • 설명: 관련 데이터를 직접 포함하는 대신, 해당 데이터를 참조하는 링크를 제공하여 필요 시 클라이언트가 추가 요청을 통해 접근할 수 있게 한다.
    • 주요 특징:
      • 메시지 크기 감소
      • 독립적 데이터 관리 가능
    • 포스의 충돌:
      • 효율성 vs. 추가 요청 필요성
      • 데이터의 최신성 유지 vs. 데이터 접근 지연

제어 및 표현의 정도에 따른 패턴

  1. 위시 리스트
    • 설명: 클라이언트가 요청 시 필요한 응답 데이터의 속성만 지정하여 선택적으로 데이터를 요청한다.
    • 주요 특징:
      • 데이터 전송 최적화
      • 클라이언트의 요구에 맞춘 맞춤형 응답 제공
    • 포스의 충돌:
      • 성능 최적화 vs. 클라이언트 복잡성 증가
      • 정확한 데이터 전달 vs. 데이터 취합의 어려움
  2. 위시 템플릿
    • 설명: 클라이언트가 중첩된 데이터 구조에서 필요한 부분만을 요청하여 더 세부적으로 응답을 조정할 수 있다.
    • 주요 특징:
      • 데이터 과다 전송 방지
      • 세밀한 데이터 제어 가능
    • 포스의 충돌:
      • 데이터 간결성 vs. 클라이언트-서버 간 데이터 처리 복잡성
      • 성능 향상 vs. 클라이언트의 정확한 요청 설계 필요

 

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

[1]의 6장은 API 설계와 관련된 내용으로, 특히 요청 및 응답 메시지에 포함되는 메시지 표현의 설계에 대한 다양한 패턴과 고려 사항을 다루고 있다. 클라이언트와 프로바이더 간의 상호 운용성, 성능, 보안, 유지보수성을 보장하기 위해 요청 및 응답 메시지의 표현을 설계하는 것이 중요하다. 또한, 메시지 표현은 데이터 구조의 복잡성과 효율성 간의 균형을 맞추어야 한다. 메시지 표현의 과제는 여러가지가 포함된다. 메시지 크기, 대화의 복잡성, 상호 운용성, 지연 시간, 처리량, 확장성, 유지보수성, 개발자 경험 등 다양한 요소를 고려해야 한다. 그리고, 클라이언트와 프로바이더의 독립적인 배포 가능성을 확보하는 것이 중요하다.

 

패턴 소개

1. 데이터 엘리먼트 (Data Element)

설명:
데이터 엘리먼트는 API 요청 및 응답 메시지에서 도메인 모델 개념을 표현하는 기본 구성 요소이다. 클라이언트와 프로

바이더 간의 통신을 위한 핵심 데이터 구조로 사용된다. 구조화된 데이터로서, 아토믹 파라미터, 파라미터 트리 등 다양한 형태로 존재할 수 있다.

 

주요 특징:

  • 도메인 모델의 복잡한 개념을 추상화하고 구조화하여 데이터 표현을 용이하게 함.
  • 클라이언트와 프로바이더 간의 느슨한 결합(loose coupling)을 촉진해 유지보수성 향상.
  • 데이터 계약(data contract)을 통해 클라이언트가 데이터 구조를 이해하고 상호작용할 수 있게 함.

포스 충돌:

  • 풍부한 기능 vs. 성능: 복잡한 도메인 모델을 노출할수록 클라이언트에게 더 많은 기능을 제공할 수 있지만, 그만큼 성능 저하와 유지보수의 어려움이 있을 수 있다.
  • 보안 vs. 구성의 용이성: 데이터를 많이 노출할수록 보안 위협에 노출될 가능성이 크며, 이에 따라 구성 및 처리 부담이 커질 수 있다.
  • 유연성 vs. 유지보수성: 다양한 표현을 제공하여 유연성을 높이려다 보면 유지보수의 어려움이 생길 수 있다.

 

2. 메타데이터 엘리먼트 (Metadata Element)

설명:
메타데이터 엘리먼트는 요청 및 응답 메시지의 데이터를 설명하거나 보충하는 추가 정보를 제공한다. 이는 메시지의 의미를 명확히 하거나 처리 효율성을 높이는 데 사용된다.

제어 메타데이터, 애그리게이티드 메타데이터, 출처 메타데이터 등 다양한 변형이 있다.

 

주요 특징:

  • 데이터의 의미, 출처, 상태 등의 추가 정보 제공으로 상호 운용성(interoperability)을 강화.
  • 메시지 수신자가 데이터를 더 잘 해석할 수 있도록 도움을 줌.
  • 클라이언트가 데이터 처리와 분석을 효율적으로 할 수 있도록 정보 제공.

 

  • 포스 충돌:
    상호 운용성 vs. 결합도: 메타데이터가 많아질수록 해석이 쉬워져 상호 운용성이 향상되지만, 클라이언트와 서버 간의 결합도가 높아질 수 있다.
  • 사용 편의성 vs. 성능: 메타데이터가 메시지 크기를 늘려 처리 성능을 저하시킬 수 있다.
  • 보안 vs. 관리 용이성: 메타데이터에 보안 정보가 포함될 때, 관리의 복잡성이 증가할 수 있다.

 

3. ID 엘리먼트 (ID Element)

설명:

  • ID 엘리먼트는 API의 엔드포인트, 동작, 메시지 표현을 고유하게 식별하기 위한 데이터 요소이다. 클라이언트가 특정 데이터를 정확히 요청하고 처리할 수 있도록 한다.
  • UUID, URI, URN 등 다양한 형태로 제공될 수 있으며, 글로벌 고유성과 로컬 고유성을 보장할 수 있다.

주요 특징:

  • 각 데이터 요소를 고유하게 식별하여 명확한 참조를 가능하게 함.
  • 글로벌 고유성(예: UUID)과 로컬 고유성(예: 특정 세션 내에서만 유효한 ID)으로 나뉨.
  • 분산 시스템에서도 안정적인 데이터 참조가 가능.

 

포스 충돌:

  • 노력 vs. 안정성: 로컬 ID는 생성이 쉽지만, 글로벌 고유성을 보장하기 어려울 수 있습니다. 반면, 글로벌 ID는 관리가 복잡하지만 안정적이다.
  • 가독성 vs. 보안: 사람이 읽기 쉬운 ID는 보안에 취약할 수 있으며, 무작위화된 ID는 보안은 좋지만 가독성이 떨어질 수 있다.
  • 구조화 vs. 간결성: 데이터베이스 키와 같은 구조화된 ID는 효율적이지만, 관리의 복잡성을 초래할 수 있다.

 

4. 링크 엘리먼트 (Link Element)

설명:

링크 엘리먼트는 메시지 내에서 데이터 요소 간의 관계를 명확히 하여, 클라이언트가 필요한 데이터를 찾고 추가 요청을 수행할 수 있게 합니다. 하이퍼미디어 컨트롤의 일환으로 사용된다. REST API에서 중요한 하이퍼미디어 제어 요소로, 다음 작업 단계나 관련 데이터 리소스를 탐색할 수 있게 한다.

 

주요 특징:

  • 데이터 요소 간의 명확한 관계를 정의하고, 클라이언트가 추가 요청을 수행할 수 있게 함.
  • 하이퍼미디어 패턴을 통해 클라이언트가 더 적은 정보로도 효율적으로 작업을 수행할 수 있게 함.
  • URI, URL 등을 사용해 명확한 데이터 참조를 제공.

 

포스 충돌:

  • 유연성 vs. 복잡성: 클라이언트가 다양한 경로를 탐색할 수 있게 하면 유연성이 높아지지만, 그만큼 메시지의 복잡성도 증가한다.
  • 명확성 vs. 성능: 링크를 사용하면 명확하게 데이터 간 관계를 표현할 수 있지만, 많은 링크는 페이로드 크기를 키워 성능 저하를 초래할 수 있다.
  • 보안 vs. 접근성: 링크를 통해 제공하는 데이터는 보안이 중요하지만, 쉽게 접근할 수 있게 하려다 보면 보안 취약점이 발생할 수 있다.

참고 문헌
[1]  올라프 짐머만 , 미르코 스토커 , 다니엘 뤼브케 , 우베 즈둔 , 세자레 파우타소 , "마이크로서비스 API 디자인 패턴: 쉬운 통합을 위한 결합도 최적화 전략" 에이콘. 이승범 역

여러 다른 글에서도 썼지만, 소프트웨어 아키텍처 설계에서 품질 속성(Quality Attribute)은 중요하게 간주되며 시스템의 성공과 연결된다고 이야기 된다. 그러나 이러한 품질 요구사항을 효과적으로 도출하는 것은 쉽지 않다. 이를 위해 품질 속성 워크숍을 진행한다. 하지만, 이 과정은 최소로 해도 하루에서 2주 가까이 소요되는 큰 작업이다.  이러한 것을 조금 더 작게 할 수 있는 '미니 품질 속성 워크숍(Mini Quality Attribute Workshop, Mini QAW, 미니 QAW)'이 유용한 도구로 활용될 수 있다.

미니 QAW 개요

미니 QAW는 전통적인 품질 속성 워크숍(Quality Attribute Workshop, QAW)의 간소화된 버전으로, 짧은 시간 내에 효율적으로 품질 요구사항을 도출하기 위해 고안되었다. 특히 애자일(Agile) 팀이나 경험이 적은 퍼실리테이터에게 적합하며, 몇 시간에서 반나절 정도의 시간으로 진행할 수 있다[1].


목적

미니 QAW의 주요 목적은 다음과 같다.
- 품질 요구사항 도출: 시스템의 주요 품질 속성을 이해하고, 이를 기반으로 아키텍처 설계에 반영합니다.
- 이해관계자 참여 촉진: 다양한 이해관계자의 의견을 수렴하여 시스템의 품질 목표를 명확히 합니다.
-효율적인 시간 활용: 짧은 시간 내에 핵심 품질 요구사항을 도출하여 프로젝트 진행 속도를 높입니다.

워크숍 구성 요소

미니 QAW를 성공적으로 진행하기 위해서는 다음과 같은 요소가 필요하다.

- 이해관계자: 시스템의 주요 사용자, 개발자, 관리자 등 다양한 관점을 제공할 수 있는 참여자들
- 퍼실리테이터: 워크숍을 이끌고 논의를 조율하는 역할을 담당하는 진행자
- 품질 속성 분류표: 성능, 보안, 가용성 등 다양한 품질 속성을 정리한 자료
- 시나리오 작성 도구: 시나리오를 작성하고 공유할 수 있는 도구나 템플릿

진행 방법

미니 QAW는 다음과 같은 단계로 진행된다.
1. 소개 및 품질 속성 이해: 퍼실리테이터가 워크숍의 목적과 품질 속성 분류표를 소개한다.
2. 이해관계자 공감 지도 작성: 참여자들이 부재 중인 이해관계자의 관점에서 품질 요구사항을 추정하여 작성한다.
3. 시나리오 브레인스토밍: 참여자들이 시스템의 품질 속성과 관련된 다양한 시나리오를 제시한다.
4. 시나리오 우선순위 결정: 제시된 시나리오에 대해 투표를 통해 우선순위를 정한다.
5. 시나리오 정제: 우선순위가 높은 시나리오를 구체화하고 상세하게 작성한다.

간단 사례

예를 들어, 온라인 도서 판매 시스템을 개발한다고 가정해보자. 이해관계자 공감 지도 작성 단계에서, 참여자들은 고객 서비스 담당자의 관점에서 "시스템이 24시간 안정적으로 운영되어야 한다"는 요구사항을 도출할 수 있다. 이러한 요구사항은 이후 시나리오 브레인스토밍과 정제 과정을 통해 구체화된다.


1. 소개 및 품질 속성 이해

퍼실리테이터는 워크숍의 목표를 소개하고, 품질 속성 분류표(예: 성능, 가용성, 보안 등)를 설명한다.

  • "이 워크숍은 온라인 도서 판매 시스템의 품질 목표를 정의하고, 우선순위가 높은 품질 속성을 도출하는 것이 목적입니다."
  • "품질 속성 예로는 페이지 로드 시간(성능), 시스템의 24시간 무중단 운영(가용성), 그리고 결제 정보 보호(보안)가 있습니다."

 

2. 이해관계자 공감 지도 작성

참여자들은 시스템과 관련된 이해관계자를 식별하고, 그들의 관점에서 품질 요구사항을 도출한다.

  • 이해관계자 식별: 고객, IT 운영팀, 서드파티 결제 제공자 등.
  • 예시: 고객 서비스 담당자 역할을 맡은 참여자는 다음과 같은 요구사항을 도출한다.
    • "고객은 사이트가 항상 사용 가능하길 원한다." → 가용성
    • "결제 실패 없이 빠르게 완료되길 바란다." → 성능 및 신뢰성
    • "고객 정보가 안전하게 보호되어야 한다." → 보안

 

3. 시나리오 브레인스토밍

참여자들은 각 품질 속성에 대한 구체적인 시나리오를 제안한다.

예시 시나리오:

  •    가용성: "시스템이 예상치 못한 서버 다운타임 발생 시, 1분 이내에 복구되어야 한다."
  •    성능: "사용자가 도서 검색을 실행할 때 결과는 2초 이내에 표시되어야 한다."
  •    보안: "사용자의 결제 정보는 암호화된 채널로만 전송되어야 한다."

 

4. 시나리오 우선순위 결정

참여자들이 제안된 시나리오 중 가장 중요한 항목에 투표한다.

우선순위 예시:

   1. "결제 정보 보호(보안)" → 온라인 결제 시스템의 핵심.

   2. "2초 이내의 검색 응답(성능)" → 고객 만족도에 큰 영향.

   3. "1분 이내 서버 복구(가용성)" → 사업 지속성에 필수.

5. 시나리오 정제

우선순위가 높은 시나리오를 구체화하여 시스템 요구사항으로 전환한다.

결제 정보 보호 시나리오:

  • 시나리오: 사용자가 도서를 결제할 때, 모든 결제 정보는 HTTPS 프로토콜을 사용해 암호화되어 전송된다.
  • 요구사항: 모든 결제 트랜잭션은 PCI DSS 표준을 준수해야 한다.

검색 성능 시나리오:

  • 시나리오: 사용자가 도서 제목을 입력하고 검색 버튼을 누르면 2초 이내에 검색 결과가 반환된다.
  • 요구사항: 데이터베이스 쿼리 성능 최적화와 캐싱 시스템을 도입한다.

결과물

미니 QAW를 통해 다음과 같은 결과물을 얻을 수 있다.

  • 우선순위가 매겨진 품질 속성 시나리오 목록: 시스템 설계 시 고려해야 할 주요 품질 요구사항
  • 이해관계자들의 품질 속성에 대한 공통된 이해: 팀 내에서 품질 목표에 대한 일치된 인식
  • 아키텍처 설계의 방향성 확보: 도출된 품질 요구사항을 기반으로 한 아키텍처 설계 지침

마무리

미니 QAW는 짧은 시간 내에 효율적으로 품질 요구사항을 도출하고, 이해관계자들의 참여를 촉진하는 유용한 워크숍이다. 이를 통해 시스템의 품질 목표를 명확히 하고, 아키텍처 설계의 방향성을 확보할 수 있다.

미니 QAW에 대해 더 자세히 알고 싶다면, [1], [2] 를 참고하도록 하자. 이러한 자료를 통해 미니 QAW의 구체적인 진행 방법과 실제 사례를 더욱 깊이 이해할 수 있을 것이다.

참고 문서

[1] Discover Quality Requirements with the Mini-QAW, https://re-magazine.ireb.org/articles/discover-quality-requirements-with-the-mini-qaw
[2] SATURN 2016 Talk: Discover Quality Requirements with the Mini QAW, https://www.youtube.com/watch?v=YGeqqYrCHHg

최근에 Facebook에서 Netflix Architecture[1]라는 포스팅을 본 적이 있다.  이미 댓글에서도 언급했지만, 실재로는 기술 스택(Tehcnology Stack)을 표현한 것이었고 아키텍처 혹은 시스템 아키텍처라고 보기는 어려웠다. 이 두 용어는  자주 사용되지만, 이 두 용어는 서로 다른 개념을 지칭한다. 아마도 이 둘을 혼동하는 이유는 밀접하게 연관되어 있기 때문일 것이다. 

Technology Stack (기술 스택)

기술 스택은 특정 소프트웨어 프로젝트 또는 애플리케이션을 구축할 때 사용되는 기술들의 집합을 의미한다. 이는 프로그래밍 언어, 프레임워크, 데이터베이스, 서버 환경, API 등을 포함할 수 있다. 기술 스택은 주로 개발에 사용되는 도구와 기술들의 "목록"으로 볼 수 있다. 종종 기성 상용품(Commercial Off The Shelf, COTS)인 경우도 많다.

예를 들어, 웹 애플리케이션을 개발하기 위해 다음과 같은 기술 스택을 사용할 수 있습니다:

  • 프론트엔드: React, Angular
  • 백엔드: Node.js, Ruby on Rails
  • 데이터베이스: PostgreSQL, MongoDB
  • 서버 환경: AWS, Azure

System Architecture (시스템 아키텍처)

시스템 아키텍처는 소프트웨어 시스템의 구조적 설계를 말한다. 일반적으로는 구조를 설명하기 위해 시스템의 컴포넌트와 그들이 서로 상호 작용하는 방식을 설명하는 것을 가리킨다. 이러한 설명은 시스템의 요구 사항을 어떻게 만족하는지를 보여 주기 위한 것이 하나의 용처이다. 

예를 들어, 시스템 아키텍처 설계에는 기술 스택 뿐 아니라, 앞에서 이야기 한 것 처럼 시스템의 요구 사항을 어떻게 만족하는지 보여 주기 위한 고려사항이 포함될 수 있다.

- 구성 요소의 배치: 서비스 지향 아키텍처(SOA), 마이크로서비스
- 데이터 흐름: 동기식 API 호출, 비동기식 메시징 시스템
- 보안 구조: 인증 및 권한 부여 방식

결론

기술 스택은 "무엇을" 사용할지에 대한 결정인 반면, 시스템 아키텍처는 "어떻게" 시스템을 구성하여 요구 사항을 만족하는지에 대한 계획이나 설명이다.  개발자와 설계자가 이 두 개념을 혼동하는 것은, 두 분야가 각각 다루는 세부사항과 전반적인 설계가 서로 긴밀히 연결되어 있기 때문일 수 있다. 아키텍처 설명하는데 기술 스택이 사용될 수 있고, 기술 스택이 아키텍처에서 설명하는 것이 부족할 수 있다는 것을 이해한다면 복잡하고 어려운 개발 업무를 효과적으로 진행할 수 있는 기반이 된다.

참고 문서

[1] Netflix Architecture, https://www.facebook.com/tipsbykavindu/photos/netflix-architecture-/536074732617368/?_rdr

+ Recent posts