서론

• 프로그램이 작동하도록 만드는 것은 어렵지 않다.
• 프로그램을 제대로 만드는 일은 어렵다.
  • 소프트웨어를 제대로 만들게 되면 소수의 프로그래머만으로도 프로그램이 지속적으로 동작하게 만들 수 있다.
  • 아마 notion 개발 팀이 위 예시의 산 증인이 아닐까 생각된다.
    (전에 본 글에 따르면 노션은 급성장하는 스타트업임에도 불구하고 30여명의 직원으로 운영된다고 들었다. 관련된 정확한 정보를 알고 계시는 분은 댓글주세요🙂)

1장 설계와 아키텍처란?

• 설계(design)와 이키텍처(architecture)는 같다.
  • 아키텍처는 저수준의 세부사항과 분리된 고수준의 무언가를 가리킴.
  • 설계는 저수준의 구조 또는 결정사항등을 의미함.
  • 하지만 소프트웨어의 설계는 저수준의 세부사항과 고수준의 구조를 모두 포함한다.

목표는?

---

좋은 소프트웨어 설계의 목표는 다음과 같다.

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는 데 투입되는 인력을 최소화하는 데 있다.

사례 연구

---

• 시간이 지날 수록 엔지니어의 수는 증가된다.
• 시간이 지날 수록 추가로 작성되는 코드의 양은 준다.(loc)
  • 시간이 지날 수록 코드 라인당 비용이 늘어나게 된다.

위 지표들을 통해서 갈수록 회사의 성장은 힘들어질 것을 알 수 있다.
// 이 부분을 보고 소프트웨어 공학에서 배우는 소프트웨어 실패 곡선이 생각이 났다.

엉망진창이 되어 가는 신호

• 시간이 갈 수록 개발자의 생산성은 줄어든다.
• 개발자의 노력은 기능 개발보다 엉망이 된 상황을 대처하는데 더 쏟게된다.
• 시간이 갈수록 엉망이 된 코드가 이곳저곳으로 옮겨지게 되고 상황은 점차 악화된다.

경영자의 시각

• 시간이 지나면서 인건비는 늘어났지만(늘어난 엔지니어의 수로 인해) 그에 비해 새롭게 얻은 제품의 기능은 적다.
  • 시간이 지날수록 손해가 커진다.

무엇이 잘못되었나?

• 개발자들이 자주 오해하는 사실
  • "당장은 시장에 출시하는 게 먼저야, 코드는 나중에 정리하면 돼"
    • 당장의 시장의 압박에 더러운 코드를 작성한다고 하지만, 시장의 압박을 줄어들지 않는다.
    • 결국 코드는 정리되지 않고, 기능은 점점 추가된다.
    • 생산성은 0을 향해 수렴하게 된다.
  • "지저분한 코드는 단기간에 빠르게 갈 수 있고, 장기적으로 볼 때만 생산성이 낮아진다."
    • 코드를 엉망으로 만들면 깔끔하게 유지할 때보다 항상 더 느리다.

빨리 가는 유일한 방법은 제대로 가는 것이다.

• 전체 시스템을 처음부터 재설계하려는 생각을 할 수도 있다.
  • 현실은 장밋빛 미래와 다르다.

자신을 과신한다면 재설계하더라도 원래 프로젝트와 똑같이 엉망이 된다.

결론

---

• 개발 조직이 할 수 있는 최고의 선택지
  • 조직에 존재하는 과신을 인지하고 방지하는 것.
  • 소프트웨어 아키텍처의 품질을 심각하게 고민하고 고민하는 것.
• 좋은 소프트웨어 아키텍처의 조건
  • 비용을 최소화한다.
  • 생산성을 최대화한다.
• 이 책의 내용
  • 아키텍처와 설계가 무엇인지 설명한다.
  • 개발자가 장기간동안 수익을 창출하는 시스템을 만들 수 있도록 돕는다.

2장 두 가치에 대한 이야기

• 모든 소프트웨어 시스템은 두 가지 가치를 제공한다.
  1. 행위
  2. 구조
• 개발자는 두 가치를 모두 높게 유지해야한다.

행위

---

• 소프트웨어의 첫 번째 가치는 행위다.
• 구현하고 디버그하는 일이 개발자가 해야 할 일의 전부가 아니다.

아키텍처

---

• 소프트웨어의 두 번째 가치는 아키텍처다.
• 소프트웨어는 부드러움을 지니도록 만들어졌다.
  • 행위를 쉽게 변경할 수 있도록 만들어졌다.
  • 변경사항을 간단하고 쉽게 적용할 수 있어야한다.
• 소프트웨어는 변경이 쉬워야 한다.

  변경을 적용하는 데 드는 어려움은 변경의 범위에 비례해야지 변경의 형태와 관련이 없어야 한다.

• 소프트웨어 개발 비용의 증가는 변경사항의 범위와 형태의 차이에 있다.
  • 개발 비용은 요청된 변경사항의 크기에 비례한다.
• 아키텍처가 특정 형태를 다른 형태보다 선호할수록, 변경사항을 적용하기 어려워진다.
  • 아키텍처는 형태에 독립적이어야하고 그럴수록 더 실용적이다.

더 높은 가치

---

• 기능과 아키텍처, 둘 중 어느 것이 더 중요한 가치인가?
  • 동작하는 소프트웨어와 변경하기 쉬운 소프트웨어
  • 기능이 더 중요하다고 생각하는 태도는 잘못되었다.

1. 완벽하게 동작하지만 변경이 불가능한 프로그램
   • 당장은 동작하지만 요구사항이 변경된다면 쓸모없는 프로그램이 된다.
   • 거의 쓸모가 없다.
2. 동작하지 않지만 변경이 쉬운 프로그램
   • 당장은 동작하지 않지만 동작할 수 있도록 유지보수할 수 있다.
   • 계속 유용할 수 있다.

• 결론: 아키텍처가 기능보다 중요한 가치다.

아이젠하워 매트릭스

---

중요한 긴급함	중요함 긴급하지 않음
중요하지 않음 긴급함	중요하지 않음 긴급하지 않음

• 행위는 긴급하지만 매번 높은 중요도를 가지지 않는다.
• 아키텍처는 중요하지만 즉각적인 긴급성을 필요로 하지 않는다.
• 4가지 경우의 우선순위
  1. 긴급하고 중요한
  2. 긴급하지 않지만 중요한
  3. 긴급하지만 중요하지 않은
  4. 긴급하지도 중요하지도 않은
• 아키텍처는 1, 2순위를 차지하지만 행위는 1, 3순위를 차지한다.
• 개발자들은 기능의 긴급성이 아닌 아키텍처의 중요성을 설득해야할 책임을 가진다.

아키텍처를 위해 투쟁하라.

• 개발자에게 주어진 책임을 마땅히 수행하기 위해서 가장 중요하다고 믿는 가치를 위해 투쟁해야한다.
• 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 시스템에 변경사항을 적용하기 힘들어진다.
• 스스로 옳다고 믿는 가치를 위해 투쟁해라.