Merge pull request #45 from danmooozi/mono

* wynter: 유익한 내용이네요.
* max: 함께 자라기 읽어보겠습니다.
* eden: 공부할 게 너무 많다.

ch19_아키텍처_결정/ch19_mono.md

@@ -0,0 +1,148 @@
+# 19.아키텍처 결정
+
+아키텍트에게 기대하는 핵심 가치 중 하나는 아키텍처 결정을 내리는 것입니다. 아키텍처 결정을 하려면 충분한 정보를 수집하고 결정을 정당화, 문서화한 다음 이해관계자들과 효과적으로 소통해야 합니다.
+
+## **19.1** 아키텍처 결정 안티패턴
+
+아키텍처를 결정하는 것도 기술입니다. 따라서 아키텍트가 결정을 내릴 때 아키텍처 안티패턴에 빠지는 일도 드물지 않습니다. 
+
+### **19.1.1** ‘네 패를 먼저 보여주지마’ 안티패턴
+
+아키텍트가 잘못된 선택을 하는 것을 두려워한 나머지 아키텍처 결정을 회피하거나 미루는 현상을 말합니다.
+
+이 안티패턴은 두 가지 방법으로 극복할 수 있습니다. 첫째, 어떤 중요한 아키텍처 결정을 내리기 전, 미지막으로 책임질 수 있는 순간까지 기다리는 것입니다. 아키텍트가 자신의 결정을 정당화하고 검증하기 위해 충분한 정보를 수집할 때까지 기다리지만, 개발팀을 마냥 붙잡아 두거나 분석 마비 ****안티패턴에 빠질 정도로 오래 기다리지는 않음을 의미합니다.
+
+둘째, 개발팀과 지속적으로 협력하면서 아키텍트가 결정한 내용을 원래 의도한 대로 추진합니다. 세부적인 기술에 관한 모든 이슈를 아키텍트 혼자 전부 다 알 수는 없기 때문에 개발팀의 협력은 절대적으로 필요합니다. 그래야 나중에 문제가 생겨도 아키텍트가 아키텍처 결정을 변경하면서 재빠르게 대응할 수 있습니다.
+
+### 19.1.2 ‘무한반복 회의’ 안티패턴
+
+‘네 패를 먼저 보여주지마’ 안티패턴을극복하면 이어서 ‘무한반복 회의’ 안티패턴으로 이어집니다. 사람들이 어떤 결정을 왜 했는지 모르고 주구장창 회의만 계속 하는 것입니다.
+
+‘무한반복 회의’ 안티패턴이 발생하는 이유는 아키텍트가 자신이 내린 결정을 정당화하는 데 실패했기 때문입니다. 아키텍처 결정을 정당화하려면 그 결정을 내리게 된 기술적, 비즈니스적 근거를 제시하는 것이 중요합니다.
+
+어떤 아키텍처 결정이건 그것을 정당화할 때에는 비즈니스 가치를 제시하는 것이 중요합니다. 그렇게 해야 그 아키텍처 결정을 정말 다른 무엇보다 우선해야 하는지 한 번 더 돌아볼 수 있습니다. 그럴 만한 비즈니스 가치가 없다면 좋은 아키텍처 결정이 아니니 한발짝 물러나 재고해보는 것이 좋습니다.
+
+가장 일반적인 비즈니스 정당화로는 비용, 출시 시기, 유저 만족도, 전략적 포지셔닝 등이 있습니다. 이 네 가지 관점에서 비즈니스적으로 정당화할 때에는 무엇이 비즈니스 이해관계자에게 중요한지 숙고해봐야 합니다. 
+
+### 19.1.3 ‘이메일 기반 아키텍처’ 안티패턴
+
+아키텍트가 아키텍처 결정을 하고 그 결정을 온전히 정당화한 다음은 ‘이메일 기반 아키텍처’ 안티패턴이 등장할 차례입니다. 사람들이 아키텍처 결정을 놓치거나 잊어버리고 심지어는 그렇게 결정됐다는 사실조차 알지 못해 아키텍처 결정을 구현하지 못하는 상태입니다. 아키텍처 결정을 효과적으로 전달하는 문제와 관련된 안티패턴입니다.
+
+이 안티패턴을 방지하고 아키텍처 결정을 효과적으로 전달하려면 어떻게 해야 할까요? 첫째, 이메일 본문에 아키텍처 결정을 포함시키지 않습니다. 이메일 본문에 아키텍처 결정을 기재하면 그 결정에 관한 여러 경로의 기록 체계가 파생되고 (정당화 사유를 비롯한) 중요한 세부 사항들이 이메일에서 누락되기 쉬운 까닭에 고질적인 ‘무한반복 회의’ 패턴이 재발합니다.
+
+둘째, 아키텍처 결정에 정말 관심있는 사람들에게만 통지합니다. 일례로, 이메일 본문에 다음과 같이 쓰면 효과적이겠죠. 
+
+또 아키텍처 결정에 관한 세부 내용을 확인 가능한 링크를 제공하면 모든 정보를 일원화하여 관리할 수 있는 체계가 완성됩니다.
+
+## **19.2** 아키텍처적으로 중요한
+
+아키텍처 결정에 기술적인 내용이 포함되면 그것은 아키텍처 결정이 아니라, 기술 결정이라고 단정짓는 아키텍트들이 많지만 반드시 그런 것은 아닙니다. 아키텍트가 어떤 기술을 사용하기 로 결정을 했고 그 기술을 어떤 아키텍처 특성을 직접 지원하기 위해 선택한 것이라면 이는 아키텍처 결정이 맞습니다.
+
+그는 아키텍처적으로 중요한 결정이란 구조, 비기능 특성, 의존성, 인터페이스, 구현기술에 영향을 미치는 결정이라고 보았습니다. 
+
+구조는 사용 중인 아키텍처의 패턴이나 스타일에 영향을 미치는 결정들입니다.
+
+비기능 특성은 개발 또는 유지보수 중인 애플리케이션이나 시스템에 중요한 아키텍처 특성들입니다. 만약 어떤 기술을 선택하느냐에 따라 성능이 달라지고 성능이 애플리케이션의 중요한 팩터일 경우, 이러한 기술 선택이 곧 아키텍처 결정이 됩니다.
+
+의존성은 전체 확장성,모듈성,민첩성,시험성, 안정성 등에 영향을 미치는 시스템 내부의 컴포넌트와（또는） 서비스 간의 커플링 지점을 가리킵니다.
+
+인터페이스는 게이트웨이, 통합 허브, 서비스 버스, API 프록시를 통해 서비스와 컴포넌트에 （를） 액세스하고 조정하는 수단을 말합니다.
+
+구현 기술은 원래 그 자체는 기술적인 것이지만, 아키텍처의 많은 부분에 영향을 미치는 플랫폼, 프레임워크, 도구, 프로세스에 관한 결정입니다.
+
+## **19.3** 아키텍처 결정 레코드
+
+아키텍처 결정을 가장 효과적으로 문서화하는 방법은 바로 아키텍처 결정 레코드 입니다.
+
+### **19.3.1** 기본구조
+
+ADR의 기본 구조는 제목, 상태, 콘텍스트, 결정, 결과, 이렇게 주요 5개 섹션으로 구성됩니다. 여기에 컴플라이언스와 노트라는 추가 섹션을 덧붙입니다. 
+
+![image](https://github.com/user-attachments/assets/278a75da-cbd9-4573-b24b-f35602931f01)
+
+제목
+
+ADR 제목은 일련 번호와 함께 아키텍처 결정을 짤막한 문구로 표현합니다. 예를 들어, 주문 서비스와 결제 서비스가 서로 비동기 메시징을 사용하기로 결정했다면 ‘42. 주문 서비스와 결제 서비스 간의 비동기 메시징 사용’ 정도의 제목을 씁니다. 아키텍처 결정의 성격과 콘텍스트의 모호함을 해소할 수 있을 정도로, 짧고 간결하게 기술합니다.
+
+상태
+
+ADR 상태는 제안됨**Proposed,** 수락됨**Accepted,** 대체됨**Superseded**으로 표시합니다. ‘제안됨’은 해당 결정이 상위 레벨의 의사 결정권자 또는 아키텍처 거버넌스 협의체의 승인을 득해야 하는 상태입니다. ‘수락됨’은 결정이 승인되어 구현할 준비가 된 상태입니다. 
+
+‘대체됨’은 결정이 번복되어 다른 ADR에 의해 대체된 상태로, 이전 ADR 상태는 수락됨 상태여야 합니다. 제안됨 상태의 ADR은 다른 ADR로 대체되는 일 없이 수락됨 상태가 될 때까지 계속 수정됩니다.
+
+대체됨 상태는 어떤 결정이 내려졌고, 당시 왜 그런 결정을 했는지, 새로운 결정은 무엇이고 어쩌다 변경을 하게 됐는지 등에 관한 이력을 보관하는 강력한 수단입니다. 
+
+일반적으로 어떤 ADR이 대체되면 그 ADR을 대체한 결정이 병기되며, 반대로 다른 ADR을 대체한 결정은 자신이 대체한 ADR이 병기됩니다. 예를 들어, ADR 42는 이미 전에 승인됐지만 이후 결제 서비스의 구현체 및 위치가 바뀌어 두 서비스 간 통신 방식을 REST로 변경하기로 했다면（ADR 68）상태는 다음과 같습니다.
+
+```
+ADR 42. 주문 서비스와 결제 서비스 간의 비동기 메시징 사용
+상태: 68로 대체됨
+ADR 68. 주문 서비스와 결제 서비스 간의 REST 사용
+상태:수락됨, 42를 대체함
+```
+
+이렇게 ADR 42와 ADR 68를 서로 연관 지어 이력을 남기면 나중에 ADR 68에 대해 “메시징을 사용하는 게 어떨까요?” 같은 불필요한 질문이 나올 일은 없겠죠.
+
+ADR 상태 섹션은 아키텍트 본인이 아키텍처 결정을 승인할 수 있는 기준, 상급 아키텍트의 승인이나 아키텍처 검토 위원회, 또는 다른 아키텍처 관리 협의체의 승인을 받고 진행해야 하는지 등의 문제를 두고 자신의 상사나 수석 아키텍트와 대화를 하도록 만들기 때문에 중요한 측면도 있습니다.
+
+콘텍스트
+
+ADR 콘텍스트 섹션은 불가항력적인 요소를 특정합니다. 다시 말해, ‘어떤 사정 때문에 그렇게 결정할 수밖에 없었나?’입니다. 아키텍트는 이 섹션에서 특수한 상황이나 문제점을 이야기하고 다른 대안에 대해 상술합니다. 
+
+콘텍스트 섹션은 아키텍처를 문서화하는 수단이기도 합니다. 아키텍트는 콘텍스트를 기술함으로써 곧 아키텍처를 기술하는 것입니다. 이는 분명하고 간결하게 특정 아키텍처 영역을 문서화하는 효과적인 방법입니다. 
+
+앞 절의 예로 돌아가 콘텍스트를 읽어보면 이렇습니다. ‘현재 주문의 *총* 결제 금액을 주문 서비스가 처리하려면 반드시 결제 서비스에 정보를 전달해야 하는데 이는 REST 또는 비동기 메시징을 통해 수행할 수 있다’ 이 간결한 한 문장에 시나리오는 물론 대안까지 들어있습니다.
+
+결정
+
+ADR 결정 섹션에는 아키텍처 결정과 그렇게 결정하게 된 사유를 전부 밝힙니다. 마이클 나이가드는 수동적인 어조 대신, 매우 긍정적이고 당당한 어조로 아키텍처 결정을 설명하는 훌륭한 방법을 강조합니다. 예를 들어, 서비스 간에 비동기 메시징을 사용하기로 결정했다면 ‘서비스 간의 비동기 메시징이 최선의 선택이라고 생각합니다’ 보다는 ‘서비스 간에는 비동기 메시징을 사용할 것입니다’라고 기술해야 그 결정을 설명하는 문장으로서 설득력이 있습니다. 전자는 아키텍트의 의견만 기술된 문장으로, 어떤 아키텍처 결정을 했는지, 심지어 정말 그렇게 결정했는지 확실하지 않습니다.
+
+결정 섹션의 가장 큰 강점은 아키텍트가 방법how보다 이유why에 더 무게를 실을 수 있다는 것입니다. 사실 왜 그런 결정을 내렸는지 이해하는 것이 그것이 어떻게 작동되는지 이해하는 것보다 훨씬 더 중요합니다. 아키텍트와 개발자는 콘텍스트 다이어그램을 보고 작동 원리를 짐작할 수는 있지만 왜 그렇게 결정했는지는 도통 알 수가 없습니다. 결정을 내린 이유와 그런 결정을 할 수밖에 없었던 사연을 알고 나면 사람들은 문제의 맥락을 더 잘 이해하고 행여 다른 문제가 생기지 않도록 리팩터 링을 통해 실수를 예방할 수 있습니다.
+
+결과
+
+ADR 결과 역시 아주 강력한 섹션입니다. 이 섹션에는 아키텍처 결정의 전체적인 영향도를 기술합니다. 아키텍트가 어떤 결정을 하더라도 *좋은* 영향과 나쁜 영향은 공존하기 마련입니다. 아키텍처 결정이 어떤 영향을 미치는지 구체적으로 기술함으로써 아키텍트는 결정의 장점보다 그 영향이 더 중요한지 되돌아보게 됩니다.
+
+이 섹션은 아키텍처 결정에 관한 트레이드오프는 물론, 분석 결과도 문서화할 수 있으므로 유용합니다. 트레이드오프는 비용 기반일 수도 있고 다른 아키텍처 특성과의 트레이드오프일 수도 있습니다.
+
+컴플라이언스
+
+**ADR**의 컴플라이언스 ****섹션은 표준 섹션은 아니지만 우리는 반드시 추가하라고 권장합니다. 이 섹션은 컴플라이언스 관점에서 아키텍트가 아키텍처 결정을 어떻게 측정/관리하는 게 좋을지 생각하게 만듭니다. 아키텍트는 본인의 결정에 대한 컴플라이언스 체크를 수동으로 할지, 아니면 피트니스 함수로 자동화할지 결정해야 합니다. 피트니스 함수로 자동화할 수 있으면 피트니스 함수를 작성하는 방법, 그리고 컴플라이언스 측면에서 이 아키텍처 결정을 판단하기 위해 코드베이스에 다른 변경은 필요 없는지 등의 내용을 이 섹션에 기재합니다.
+
+노트
+
+노트 섹션 역시 표준 섹션은 아니지만 가급적 추가하는 게 좋습니다. 이 섹션에는 다음과 같이 ADR에 관한 다양한 메타데이터가 포함됩니다. 
+
+- 원저자
+- 승인일
+- 승인자
+- 대체일
+- 최종수정일
+- 수정자
+- 최종수정내역
+
+ADR을 （깃 같은） 버전 관리 시스템에 저장할 때에도 저장소에서 지원되지 않는, 부가적인 메타 정보가 있으면 유리하므로 ADR을 어디에, 어떻게 저장하더라도 이 섹션은 추가하는 것이 좋습니다.
+
+### **19.3.2 ADR** 저장
+
+이렇게 작성한 ADR은 어딘가에 저장을 해야 합니다. 저장 위치와 상관없이 각 아키텍처 결정은 자체 파일이나 위키 페이지도 갖고 있어야 합니다. 일부 아키텍트들은 ADR을 소스 코드와 함께 깃 리포지터리에 보관하는 것을 선호합니다. 깃 리포지터리에 ADR을 보관하면 버전 관리 및 추적은 간편하지만, 규모가 큰 조직에서는 몇 가지 주의할 점이 있습니다. 
+
+첫째, 아키텍처 결정을 확인해야 하는데 어떤 이들은 깃 리포지터리에 액세스할 수 없는 경우가 있습니다.
+
+둘째, 애플리케이션 깃 리포지터리를 벗어난 콘텍스트가 있는 ADR을 깃에 저장하는 것은 적절하지 않습니다. 그러므로 ADR은 위키 （또는 위키 템플릿） 또는 다른 문서 렌더링 소프트웨어 에서 쉽게 접근 가능한 공유 파일 서버의 공유 디렉터리에 저장하는 것이 좋습니다.
+
+![image](https://github.com/user-attachments/assets/d364e455-e141-431d-8b4f-69c80145b749)
+
+ADR을 위키에 저장（우리는 이것을 권장합니다）하면 앞서 기술한 것과 동일한 구조가 적용되어 각 디렉터리 가 곧 네비게이션 랜딩 페이지가 됩니다. ADR 하나가 각각의 네비게이션 랜딩 페이지 （application, integration, enterprise）에 단일 위키 페이지로 표시됩니다.
+
+### **19.3.3 ADR** 로문서화
+
+소프트웨어 아키텍처의 문서화는 언제나 어려운 주제입니다. 아직 이렇다 할 소프트웨어 아키텍처 문서화 표준은 없습니다. 어쩌면 그래서 더 더욱 ADR이 필요한 건지도 모르겠습니다. 
+
+ADR은 소프트웨어 아키텍처를 효과적으로 문서화하는 수단으로 활용할 수 있습니다. ADR 콘텍스트 섹션은 아키텍처 결정이 필요한 시스템의 특정 영역을 기술하는 더 없이 훌륭한 장소인 데다 어떤 대안들이 있는지 기술하기에 적절한 곳입니다. 하지만 무엇보다 중요한 섹션은, 아키텍처 결정을 내린 사유가 기술된 결정 섹션입니다.이 섹션 하나만 봐도 ADR은 현존하는 최고의 아키텍처 문서화 포맷입니다.
+
+### **19.3.4 ADR** 로 표준화
+
+이 세상에 표준을 좋아하는 사람이 있을까요? 일반적으로 표준은 그것이 유용해서 라기보다 사람들이 일하는 방식을 통제하는 용도로 더 많이 사용되는 것 같습니다. 그러나 ADR을 표준화하면 이런 나쁜 관행이 바뀔 수도 있습니다. 
+
+ADR 결과 섹션은 어떤 표준이 타당하며 반드시 지켜져야 하는지를 아키텍트 스스로 검증하기에 적합한 기회입니다. 아키텍트는 이 섹션에서 자신이 작성 중인 표준의 의미와 결과가 무엇인지 심사숙고해야 합니다. 이로써 막상 결과를 분석해보니 이 표준은 적용하면 안 되겠다. 결정을 뒤바꿀 수도 있겠죠.