2024-12-01

content/blog/개발자에서 아키텍트로/00장-서론.md

@@ -0,0 +1,20 @@
+---
+title: 00장 서론
+date: 2024-12-01 20:12:87
+category: 개발자에서 아키텍트로
+tags: []
+draft: true
+---
+
+## 머리말(조지 페어뱅크스)
+
+- 이 책은 애자일의 가치에 대한 깊은 이해를 기초로 시작하며, 아키텍처를 설계할 때 애자일과 접목할 수 있는 기술을 설명합니다.
+- 팀 단위로 자발적으로 설계 작업을 진행하며, 일주일 단위로 반복해서 진행 할 수 있는 활동들을 소개합니다.
+- 애자일 이전, 관료적인 소프트웨어 개발에서는 설계를 언제 어떻게 해야 하는지 규율화 되어 있었습니다. 기존 개발방식에서 벗어나고 싶었던 리더들은 애자일이 어리숙한 카우보이코딩이 아니라고 호소했지만, 안타깝게도 저자가 경험했던 소위 `애자일` 방식의 사례들은 모두 성공적이지 않았습니다.
+- 빠른 피드백과 반복이라는 애자일의 방법론을 활용하면서도, 높은 품질을 달성할 수 있는 여러 설계 기법을 다룰겁니다.
+
+## 이 책에 대하여
+
+- 소프트웨어 아키텍처는 멋진 소프트웨어를 만드는 단단한 기반입니다. 훌륭한 아키텍처가 소프트웨어의 성공을 보장하지는 않지만 `나쁜아키텍처는 필연적으로 실패를 가져옵니다`.
+- 사람을 우선으로 생각하면 더 나은 설계를 할 수 있고, 최종적으로는 더 나은 소프트웨어를 만들 수 있습니다.
+- 이 책은 화이트보드 앞에 서서 복잡한 질문에 여러가지 도형과 선을 그리면서 답변해야 하는 사람들에게 어울립니다. 또한 소프트웨어 설계를 처음 접하는 사람에게도 완벽한 안내서입니다.

content/blog/개발자에서 아키텍트로/01장-소프트웨커-아키텍트가-되다.md

@@ -0,0 +1,176 @@
+---
+title: 01장 소프트웨커 아키텍트가 되다
+date: 2024-12-01 21:12:51
+category: 개발자에서 아키텍트로
+tags: ['PART1 소프트웨어 아키텍처']
+draft: true
+---
+
+- 소프트웨어 아키텍트는 시스템을 구현 가능한 작은 조각으로 나누는 동시에 전체 시스템이 일관성 있게 동작하도록 큰 그림을 그립니다.
+- 아키텍트는 품질에 영향을 주는 다양한 `품질 속성` 사이에서 균형을 잡아야 하며 어쩔 수 없이 늘어나는 기술 부채도 관리합니다.
+- 아키텍트는 팀원들의 설계 역량을 개발합니다. 아키텍트에게 최고의 팀은 아키텍트로 채워진 팀입니다.
+
+## 1.1. 소프트웨어 아키텍트가 하는 일
+
+- 아키텍트는 소프트웨어가 언제 어떻게 전달되는지 결정하는 사람입니다. 또한 소프트웨어가 비즈니스 목표에 부합하도록 만드는 사람입니다.
+
+### 1.1.1. 엔지니어링 관점에서 문제 정의하기
+
+- 소프트웨어 아키텍트는 프로덕트 매니저, 프로젝트 매니저, 그리고 모든 이해관계자와 협업하면서 비즈니스 목표와 요구사항을 만들어갑니다.
+- 아키텍트는 시스템의 품질 속성을 정의할 뿐만 아니라 소프트웨어 아키텍처가 정해진 방향으로만 갈 수 있도록 `제약`과 기능을 꾸준히 확인해야 합니다.
+
+### 1.1.2. 시스템은 분리하고 책임은 위임하기
+
+- 아키텍트는 소프트웨어 시스템을 여러 조각으로 나누고 조각마다 품질 속성과 요구사항을 달성하도록 전략을 만듭니다.
+- 작게 나누면 원인을 파악하기 쉽고, 테스트하기 쉽고, 설계도 쉽습니다. 물론 시스템을 나눈 만큼 다시 모아서 제대로 동작하게 하는 작업도 필요합니다.
+
+### 1.1.3. 큰 그림 그리기
+
+- 아키텍트는 작은 설계 결정사항이 가져올 미래도 예측하면서 넓은 의미의 시스템 관점도 가져야 합니다. `트레이드오프`를 생각해야 합니다.
+
+### 1.1.4. 품질/속성 트레이드오프를 고려하기
+
+- 소프트웨어 시스템은 결코 완벽하게 나누어 떨어지지 않습니다. 타협해야만 합니다.
+
+### 1.1.5. 기술 부채 관리하기
+
+- 비즈니스 요구사항과 기술 선택을 잇는 일도 합니다. 기술 부채가 관리 가능한 수준으로 최적의 위치를 잡아가도록 해야 합니다.
+  - 기술 부채는 소프트웨어 시스템의 현재 설계와 소프트웨어가 지속적으로 가치를 창출하기 위해 가져야만 하는 바람직한 설계 사이의 간극입니다.
+- 아키텍트는 기술 부채를 시각화하고 이해관계자 모두에게 이를 어떻게 관리해야 하는지 도와주는 일을 합니다.
+
+### 1.1.6. 팀의 이키텍처 설계 역량 키우기
+
+- 아키텍처 전문가라면 팀원에게 많은 지식을 나눠주어 멋진 소프트웨어를 개발하게 할 책임이 있습니다.
+- 지식을 전달할 때는 팀원과 함께 설계하고, 이를 가르치기 위한 문서를 만들고, 건설적인 비평을 나눠야 합니다.
+
+## 1.2. 소프트웨어 아키텍처란 무엇인가?
+
+- 스프트웨어 아키텍처란 한 소프트웨어를 어떻게 구성해야 하는지 그리고 필요한 품질 속성을 어떻게 증진해야 하는지에 대한 중요한 결정들과 다른 소프트웨어와는 구별되는 특징들을 모아놓은 집합입니다.
+
+### 1.2.1. 필수 구조 정의하기
+
+- 구조를 만드는 일은 곧 요소들끼리 관계를 만드는 일입니다.
+  - 관계는 연관된 요소들이 함께 동작해서 특정 작업을 완수하는 단위입니다.
+- 모듈은 설계 시점에 의미 있는 요소이며 컴포넌트는 런터임 시점에 의미 있는 요소입니다.
+- 일반적인 주제에서 구조적으로 뭔가 쌓아올리는 블록을 표현하고 싶다면 컴포넌트나 모듈이 아니라 `요소`라고만 말하는 편이 더 좋습니다.
+
+| -                    | 요소                                                                        | 관계                                                |
+| -------------------- | --------------------------------------------------------------------------- | --------------------------------------------------- |
+| 모듈                 | 클래스, 패키지, 레이어, 저장 프로시저, 모듈, 설정 파일, 데이터베이스 테이블 | 사용한다, 사용을 허락한다, 의존한다                 |
+| 컴포넌트와 커넥터C&C | 오브젝트, 커넥션, 스레드, 프로세스, 계층, 필터                              | 호출한다, 구독한다, 연결한다, 송출한다, 응답한다    |
+| 자원 할당            | 서버, 센서, 랩톱, 로드 밸런서, 팀, 사람, 도커 컨테이너                      | 구동한다, 책임이 있다, 개발한다, 저장한다, 지불한다 |
+
+#### 모듈
+
+- 이 타입은 설계할 때 만들기 시작해서 주로 코딩할 때 다루게 됩니다. 모듈은 파일 시스템상의 어떤 형태로 표현할 수 있으며 소프트웨어가 동작하지 않아도 상관없습니다.
+
+#### 컴포넌트와 커넥터(C&C)
+
+- 이 타입은 소프트웨어가 실제 동작할 떄부터 의미 있습니다. 소프트웨어가 실행하기 시작하면 컴포넌트 간에 커넥션을 만들고 프로세스를 생성하거나 오브젝트를 초기화합니다.
+- 모듈 타입과 다른 점이라면, C&C는 시스템이 동작하지 않으면 사라진다는 점입니다.
+- C&C 타입은 프로그램이 실제 실행하면서 만드는 로그파일이나 데이터베이스 기록만으로 파악할 수 있습니다.
+
+#### 자원 할당
+
+- 이 타입은 모듈과 C&C가 서로 어떤 관계에 있는지 물리적인 요소로 보여주고자 할 때 만듭니다.
+- 자원 할당 타입은 `매핑 구조`라고도 부르는데, 여러 요소가 서로 어떻게 매핑되는지 나타낼 수 있기 때문입니다.
+
+### 1.2.2. 직접 해보기: 요소, 관계, 구조
+
+- 요소의 이름은 구체적으로 짓습니다. 이름을 지을 때 요소가 가진 관계를 고려하는 것도 잊지 마세요.
+- 모듈 타입으로 구조를 만들때
+  - 어떤 메서드나 클래스가 사용되는가?
+  - 클래스가 다른 패키지나 네임 스페이스에 있는가?
+  - 패키지 매니저나 빌드 스크립트에는 어떤 의존성이 있는가?
+- C&C 타입으로 구조를 만들 때
+  - 소프트웨어를 실행할 때 다른 프로세스나 시스템에 어떤 관계가 만들어지는가?
+  - 시스템은 어디에서 호출하는가?
+  - 응답에 따라 동작이 어떻게 바뀌는가?
+- 자원 할당 타입으로 구조를 만들 때
+  - 여러 가지 부분을 만들 때 누가 어떤 역할을 하는가?
+  - 소프트웨어가 어떻게 배포되는가?
+
+### 1.2.3. 품질 속성과 시스템 속성 도출하기
+
+- 품질 속성은 해당 소프트웨어 시스템 이해관계자들이 소프트웨어를 평가하는 데 도드라지는 특성을 말합니다.
+  - 품질 속성은 사용자가 소프트웨어를 사용할 때 직접 느낄 수 있습니다.
+- 소프트웨어 아키텍처에 집중하면 스프트웨어 시스템에 대한 여러 가지 미사여구를 제치고 품질 속성만 고려해서 설계할 수 있습니다.
+
+## 1.3. 팀에서 아키텍트가 되려면
+
+### 1.3.1. 개발자에서 소프트웨어 아키텍트로
+
+#### 프로젝트 포트폴리오를 정리할 때 의미 있는 질문
+
+- 이해관계자들은 누구였고 주요 비즈니스 목표는 무엇이었는가?
+- 최종적으로 어떤 결과가 나왔는가?
+- 어떤 기술을 사용했는가?
+- 가장 큰 리스크는 무엇이었고, 어떻게 극복했는가?
+- 다시 시작할 수 있다면 어떤 점을 다르게 하겠는가?
+
+## 1.4. 훌륭한 소프트웨어 만들기
+
+1. 소프트웨어 아키텍처는 큰 문제를 작게 나누고 관리하기 쉽게 만듭니다.
+2. 소프트웨어 아키텍처는 사람들이 협업하는 방법을 보여줍니다.
+3. 소프트웨어 아키텍처는 복잡한 아이디어를 설명할 때 사용하는 사전입니다.
+4. 소프트웨어 아키텍처는 가능과 스펙 너머로 시야를 넓혀줍니다.
+5. 소프트웨어 아키텍처는 값비싼 실수를 줄여줍니다.
+6. 소프트웨어 아키텍처는 애자일을 가능하게 합니다.
+
+## 1.5. 사례 연구: 라이언하트 프로젝트
+
+## 1.6. 마치며
+
+---
+
+## 스터디
+
+- 인프콘에서 옮긴이의 발표가 인상 깊었고, 광휘님의 추천을 통해서 스터디를 시작하게 됨
+- 아키텍처 관련 공유를 팀에서 많이 받았고, 좋은 길잡이가 될 것이다.
+- 14쪽에 있는 이 책에 대하여에서 소프트웨어 아키텍처는 설계 배운다고 알려준다. 추상적 내용보단 현실, 접근 방향에 대해 알려준다.
+- 책의 구성은 아키텍트가 하는 일 → 아키텍처 설계 → 설계 할때 문제 상황과 38가지 팀 활동에 대해 알려준다.
+- 3부에서 활동을 경험해 보면 좋을거 같다.
+  - 3부와 이론을 병행해서 읽는 방식 스터디를 제안해 봅니다.
+- 소프트웨어 아키텍트가 되다
+  - 무슨 일을 하는지
+    - 제가 언제부터 소프트웨어 아키텍트였는지 모르지만 동료가 언제 처음으로 아키텍트라고 불렀는지는 기억합니다.
+      - 아이텐티티 → 내가 잘하는 일을 꾸준히 하다보면 아이텐티티가 된다 → 동료가 소프트웨어 아키텍트로 부르게 될 정도면 어떤 일을 했을까?
+        - 세문님에게 그런 것을 느꼈다. 비즈니스적 과제를 하기 위한 계획보단 시스템이나 플랫폼을 만드는데 전체 구조가 그려지고, 단계적으로 어떻게 갈지 비전이 있고, 그래서 내가 어떤 역할을 맡아야 하는지 명확하다.
+        - 광휘님에게도 그런 것을 느꼈다.
+    - 소프트웨어 아키텍트는 프로그램 외에도 여러가지 일을 함.
+      - 엔지니어 관점에서
+        - 일관성 있게 동작하게 큰 그림
+        - 품질 속성 사이에서 균형을 잡으며 기술 부채 관리
+        - 설계 역량 개발
+    - 아키텍트는 비즈니스 목표에 부합하게 만드는 사람
+    - 프로덕트 매니저 → 기능 피쳐 vs 아키텍트는 + 품질 속성을 또 하나는 일로 만듦
+      - 품질 속성:
+    - 소프트웨어를 분명한 책임이 있는 포지션 단위로 나누고 나눠서 게임할 수 있게 한다
+      - 책임 단위로 나누고 책임 단위로 운영 → 효율적이고 순조롭게
+    - 트레이드오프
+      - 소프트웨어 개발은 하나를 얻으면 하나를 잃는게 자주 발생
+      - 합리적 결정을 할 수 있어야 한다
+        - 철학이 중요하다.
+          - 안정성 vs 효율
+          - 거절이 중요하다
+            - Yes / No가 빠르게 결정 되지만 감정이 상하지 않아야 한다
+    - 최고의 팀은 모두가 소프트웨어 아키텍트이다
+      - 경험이 뒷받침 되어야 하지 않나
+      - 프로덕트에 대한 이해와 커뮤니케이션이 중요하다
+      - 기능과 서비스에 대해 제대로 이해하지 못하고 기능 구현하는 경우가 있는데 그렇다면 소프트웨어 설계하기 힘들다.
+    - 기술부채
+      - 현재와 지속을 위한 설계 사이의 간극
+      - 아키텍트를 이를 어떻게 관리하지를 알려준다
+  - 팀 역량 키우기
+    - 팀원과 함께 설계 → 문서 → 건설적 비평
+  - 필수 구조 정리하기
+    - 소프트웨어는 구조가 있다 → 정렬된 형태 → 구조는 요소들 간의 관계를 만드는거다
+  - 모듈과 컴포넌트의 차이
+    - 모듈은 설계 시점의 의미
+    - 컴포넌트는의 런타임 시점의 의미
+    - 블록은 그냥 요소라고 표현하고 컴포넌트, 모듈이라는 용어는 명확하게 사용하라
+  - 품질 속성
+    - 이해 관계가 평가하는 도드라지는 특성
+      - 확장성, 가용성, 유지보수성, 테스트 가능성 등
+  - 3~5년마다 의미있는 수준의 소프트웨어를 설계할 기획
+    - 운이 좋다면 8~15개 설계 할 수 있다

content/blog/개발자에서 아키텍트로/02장-디자인-싱킹-기초.md

@@ -0,0 +1,81 @@
+---
+title: 02장 디자인 싱킹 기초
+date: 2024-12-01 23:12:88
+category: 개발자에서 아키텍트로
+tags: ['PART1 소프트웨어 아키텍처']
+draft: true
+---
+
+- 소프트웨어 시스템을 설계하는 일은 문제 해결을 하는 동시에 아직 발견하지 못한 문제를 찾아가는 일입니다.
+- 디자인 싱킹은 문제 해결의 모든 기준을 `인간`에 두고, 창의적이고 분석적으로 문제를 풀어나가는 접근법입니다.
+  - 의사결정을 할 때 문제의 본질에 집중할 수 있습니다.
+  - 소프트웨어를 만드는 목적이 바로 사람들을 돕는 일이라는 점입니다.
+
+## 2.1. 디자인 싱킹의 네 가지 원칙
+
+- 디자인 싱킹은 문제를 해결하려는 과정이라기보다는 `문제와 해결책 그리고 이에 영향을 받는 사람들의 관점에 대해 생각하는 방식`이라고 할 수 있습니다.
+
+### 디자인 원칙 4가지(HART)
+
+1. 인간중심의 원칙: 모든 디자인은 사회적이다
+2. 모호함의 원칙: 모호함을 유지하라
+3. 재디자인의 원칙: 모든 디자인은 다시 디자인한 것이다
+4. 촉각의 원칙: 손에 잡히는 디자인이 대화를 이끌어낸다.
+
+### 2.1.1. 모든 디자인은 사회적이다
+
+- 설계에 대한 모든 의사결정은 사람이 이해할 수 있어야 하고 다른 사람과 공유할 수 있어야 합니다.
+- 소프트웨어를 만드는 일은 다분히 사회적인 활동입니다. 팀을 고려하지 않고 학문적으로만 접근한 상아탑 같은 설계는 허구입니다.
+
+### 2.1.2. 모호함을 유지하라
+
+- 설계를 확정하기 전까지는 당분간 모호하게 놔두는 방법을 쓸 수도 있습니다.
+- 아키텍트는 `최소한의 아키텍처`를 만들어야 합니다.
+  - 최소한의 아키텍처는 달성해야 하는 가장 중요도 높은 품질 속성만 제시해 이 품질 속성을 방해하는 위험 요소는 줄이며, 그 외에 설계에 대한 모든 의사결정은 하위 설계자들이 알아서 결정하게 합니다.
+- 모호함을 유지하면 주변 상황이 바뀌더라도 소프트웨어를 제 때 공급할 수 있습니다.
+
+### 2.1.3. 모든 디자인은 다시 디자인한 것이다
+
+- 지금까지 겪는 문제는 어떤 팀이 이미 겪은 문제일 수 있습니다.
+
+### 2.1.4. 손에 잡히는 디자인이 대화를 이끌어 낸다
+
+- 그림으로 그리고, 코드로 구현하세요.
+- 프로토타입을 만들어서 사람들이 품질 속성과 아키텍처를 직접 경험할 수 있게 하세요.
+- 단순한 모델을 만들어서 아키텍처의 한 부분을 보여주세요.
+- 공감할 수 있는 메타포를 만드세요.
+- 시스템 흐름의 일부를 직접 동작해보세요.
+
+## 2.2. 디자인 마인드셋 장착하기
+
+- 디자인 마인드셋은 이해하기, 탐색하기, 실현하기, 평가하기입니다
+
+### 2.2.1. 문제 이해하기
+
+- 이해한다는 건 곧 공감이며 이는 요구사항의 하나이기도 합니다.
+- 문제를 이해하려면 시스템을 직접 다루는 사람과 그 사람이 필요로 하는 것을 알아야 합니다.
+
+### 2.2.2. 아이디어 탐색하기
+
+- 통상적인 디자인 싱킹에서 브레인스토밍과 포스트잇은 시작이자 끝입니다.
+- 소프트웨어 아키텍처를 탐색한다는 것은 여러 구조를 조합하다가 품질 속성을 최대한으로 끌어 올릴 최선의 조합을 찾는다는 의미입니다.
+
+### 2.2.3. 실현하기
+
+- 아이딜어를 실현하기는 다른 사람에게 아이디어를 전달하는 방법뿐만 아니라 아이디어 자체를 시험해볼 수 있는 기회도 제공합니다.
+
+### 2.2.4. 평가하기
+
+- 아키텍처의 전체 또는 부분만 평가할 수도 있고, 모델 한 개만 하거나, 아이디어만 평가할 수도 있습니다.
+- 평가하기는 아키텍처에 대한 논의가 끝난 후의 일이지만 또 다른 시작을 의미합니다.
+
+### 2.2.5. 직접해보기: 이해하기, 탐색하기, 실천하기, 평가하기
+
+- 문제를 제대로 이해하기 위해 사람들과 협업한 적이 있나요? 이때 특별한 방법론을 사용했나요?
+- 아이디어를 탐색하기 위해 다른 사람들과 어떻게 협업했나요? 그리고 제시한 아이디어에 이어서 어떤 대안을 생각해봤나요?
+- 여러분이 이해관계자 또는 일하는 방식을 변경했을 때 어떻게 했나요?
+- 스스로의 설계는 어덯게 평가했나요? 가설을 테스트하기 위해 어떤 기술을 사용했나요?
+
+## 2.3. 생각-실행-확인하기
+
+### 2.3.1. 지속적인 학습을 위한 선순환

content/blog/바바라 민토, 논리의 기술/10장-피라미드-원칙으로-문서-작성하기.md

@@ -73,7 +73,7 @@ draft: true
 
 ### 중점과 대시 붙이기
 
-## 그룹 간의 전화 지원하기
+## 그룹 간의 전환 지원하기
 
 ### 스토리 말하기
 

content/blog/바바라 민토, 논리의 기술/11장-피라미드-원칙으로-프레젠테이션하기.md

@@ -15,9 +15,9 @@ draft: true
 ### 프레젠테이션을 할 때는 두가지 종류의 슬라이드 사용
 
 - 텍스트
-  - 90%
-- 도표(차트, 표, 혹은 다이어그램)
   - 10%
+- 도표(차트, 표, 혹은 다이어그램)
+  - 90%
 
 #### 역할