[IT 도서 리뷰] 클린 아키텍처 (1부 소개)

책 정보

---

https://www.yes24.com/Product/Goods/77283734

클린 아키텍처 - YES24

목적

---

• 스터디를 통해 현업에서 사용되는 아키텍처에 대해 익히는 것
• 객채 지향 프로그래밍, 함수형 프로그래밍, SOLID 등 공부했지만, 얕게 했던 것들 깊게 익히기

 

1장 설계와 아키텍처란?

---

• 설계와 아키텍처 사이의 차이?
  • 아무런 차이가 없음
  • 아키텍처: 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용
  • 설계: 저수준의 구조 또는 결정사항 등을 의미할 때가 많음
• 목표는?
  • 소프트웨어 아키텍처의 목표: 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 것
• 사례 연구
  • 개발자의 수는 늘어났지만, 코드 생산성은 정체되어 있는 경우 -> 엉망진창이 되어가는 신호
  • 시스템을 급하게 만들거나, 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면, 생산성이 바닥을 치게 된다. -> 아키텍처가 필요한 이유
• 엉망진창이 되어 가는 신호
  • 코드와 설계의 구조를 깔끔하게 만들려는 생각을 전혀 하지 않으면 -> 파국
• 경영자의 시각
  • 인건비는 늘었지만, 생산성이 낮아짐
• 무엇이 잘못되었나?
  • 토끼와 거북이 -> 지나친 과신이 가진 어리석음
  • 거짓말 2가지
    •  '코드는 나중에 정리하면 돼. 당장은 시장에 출시하는 게 먼저야!'
      • 하지만, 이전에 작성한 코드로 돌아가 정리하는 일은 일어나지 않음 (다음 기능, 또 다음 기능이 기다린다.)
      • 결국 생산성은 0을 향해 수렴
    • '지저분한 코드를 작성하면 단기간에는 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다'
      • 엉망으로 만들면 깔끔하게 유지할 때보다 항상 느림
      • (TDD적용/미적용 사례를 통해 걸린 시간 차이를 예시로 듦)

2장 두 가지 가치에 대한 이야기

---

• 행위와 아키텍처
  • 모든 소프트웨어 시스템이 제공하는 2가지 가치
  • 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임이 있음 - > But, 한가지 가치에만 집중하고 나머지 가치는 배제하는 경우가 많다는 것이 문제!!!
• 행위
  • 프로그래머를 고용하는 이유: 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서
  • 프로그래머는 이에 따라 요구사항을 만족하도록 코드를 작성
  • 많은 프로그래머가 이러한 활동이 전부라고 생각한다. (요구사항을 기계에 구현 & 버그 수정)
  • 슬프지만 틀렸다.
• 아키텍처
  • '소프트웨어'는 '부드러운' (soft)와 "제품' (ware)의 합성어 -> 소프트웨어는 '부드러움을 지니도록' 만들어짐.
    • 즉, 소프트웨어는 반드시 '부드러워'야 한다.
  • 다시 말해 변경하기 쉬워야 한다.
  • 소프트웨어 개발 비용의 증가를 결정짓는 주된 요인이 변경사항의 범위와 형태의 차이에 있음
  • 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는 게 더 힘듦
    • 따라서 아키텍처는 형태에 독립적이어야 하고, 그럴수록 더 실용적이다.
• 더 높은 가치
  • 행위 or 아키텍처 중 어떤 것이 가치가 더 높을까?
  • 동작하도록 만드는 것이 중요한지 or 시스템을 더 쉽게 변경할 수 있도록 하는 것이 중요한지
  • 업무 관리자에게 묻는다면 동작하는 것이 더 중요하다고 대다수가 대답할 것임
    • 개발자는 동조하는 태도를 취하면 안된다!
• 아이젠하워 매트릭스
  • 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 긴급한 경우는 거의 없다
  • 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아니다.
  • 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하는 경우는 절대 없다.
  • 우선순위
    • 긴급하고 중요한
    • 긴급하지는 않지만 중요한
    • 긴급하지만 중요하지 않은
    • 긴급하지도 중요하지도 않은
  • 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 일이 흔한 실수
  • 업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력이 없음 -> 개발자를 고용하는 이유!!!
  • 아키텍처의 중요성을 설득하는 일은 소프트웨어 개발팀이 마땅히 책임져야 함!
• 아키텍처를 위해 투쟁하라
  • 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해진다!

후기

---

• 아직 현업에서 일해보지 못해서 행위와 아키텍처의 딜레마가 확 와닿지는 않지만, 어떤 방향으로 가야할지 생각하게 되었음.
• 소프트웨어의 정의로 "soft'와 'ware'를 통해 부드러운(변경이 쉬운) 프로덕트를 개발하는 것이 중요하다고 했던 부분이 인상 깊음.
• 살다보면 긴급하면서 긴급한게 많아보이는데,,,, 잘 모르겠다.