소프트웨어 아키텍처 101 - 엔지니어링 접근 방식으로 배우는 소프트웨어 아키텍처 기초

마크 리처즈, 닐 포드 지음, OREILLY, 이일웅 옮김, 한빛미디어

🗓 어떻게 읽었나

재밌었다. 전체보기를 제외하고 내 벨로그 글 태그 1순위를 차지하고 있는 설계에 대한 책이다. 재밌을 수밖에 없다. 지금까지 읽은 책 중 실무 예시가 가장 많이 떠올랐던 책이 아닐까 싶다.

• 기간: 2025.03.16 - 2025.05.22 (11주)
• 분량: 총 22장, 약 472페이지.
• 방식: 1주일에 1-3장
• 누구와 함께: 랜선 스터디

⭐️ 명언 모음

(내 생각은 괄호 안에 적었다.)

책 초반에 명언이 많이 나온다. 소프트웨어 설계 전반적인 내용을 다룰 때 나온 문장이다.

• 아키텍처는 구글링해도 안 되는 것이다.
  • (실무를 하면서 절실히 느낀다. 결국 직접 고민해야 한다. 구글이든 채찍피티 선생이든 도메인과 요구사항에 대한 배경지식을 일일이 설명하고 찾아보는 것보다, 사람이 직접 생각하는 게 빠르다. AI는 거들 뿐,.)
• 소프트웨어 아키텍처 제1 법칙: 소프트웨어 아키텍처의 모든 것은 다 트레이드오프다.
  • 제1 정리: 아키텍트가 트레이드오프 아닌 뭔가를 발견했다고 생각하면 그것은 그가 아직 트레이드오프를 발견하지 못했다는 증거일 가능성이 높다.
  • (완벽한 아키텍처는 없다. 그런게 있다면 알려줘,.)
• 소프트웨어 아키텍처 제2 법칙: ‘어떻게’ 보다 ‘ 왜’ 가 더 중요하다.
  • (’왜’의 결과물로 ‘어떻게’가 나오기 때문이다.)
  • (’어떻게’는 수십개가 존재할 수 있지만 ‘왜’는 하나뿐이기 때문이다.)
• 아키텍처에서는 틀린 답은 없고 값비싼 답만 있다.
  • (완벽한 아키텍처는 없다. 22)
• 최고의 아키텍처를 고집하지 말고 나쁜 것 중에서 제일 나은 아키텍처를 선택하세요.
  • (완벽한 아키텍처는 없다. 333)

그리고 이건 책 후반부에서 아키텍처 논쟁, 협상에 관한 내용을 다루면서 나왔던 말이다.

• 다른 모든 것이 실패하면 비용과 시간으로 설명하세요.
  • (반대로, 단점이 비용과 시간밖에 없는 아키텍처라면 꽤나 괜찮은 아키텍처란 의미도 될 것 같다. 물론 프로덕트 개발을 하면서 이것만큼 기초적이고 중요한 게 없는 것도 사실이다.)
• 고대 중국의 전략가 손자는 손자병법이라는 책에서 “적이 단합되어있으면 분열시켜라”라고 말했습니다. (Divide and Conquer)
  • (이 문장을 본 순간 손자병법을 읽고 싶어졌다.)
  • (물론 사람을 divide and conquer 하라는 게 아니고 요구사항 또는 필수 조건을 나눠서 생각해보라는 뜻에서 인용한 말이다.)
• 증명은 언제나 논쟁을 이긴다.
  • (펠리컨적 사고: 일단 해볼 것. 백 마디 말로 설명하는 것보다 직접 구현하고 테스트해보는 게 가장 설득력 있다.)
    

💭 기억에 남(기고 싶)은 내용

커플링에는 두 가지 종류가 있다. - 3장. 모듈성

• 정적 커플링: 소스 코드 레벨
• 동적 커플링: 런타임 레벨

아키텍처 특성을 식별할 때에는 암묵적 도메인 지식도 같이 고려해야 한다. - 4장. 아키텍처 특성 정의

• 예) 당일 펀드 종가는 무슨 일이 있어도 제시간에 마감되어야 한다는 요구사항이 있을 때
  • DON’T: 성능에만 집중
  • DO: 이런 걸 같이 고려해야한다.
    • 필요한 시점에 시스템을 사용할 수 없다면 얼마나 빠른지는 중요하지 않다.
    • 도메인이 더 커지고 펀드가 더 많이 유입된다면? 규모 확장이 가능해야 한다.
    • 펀드 종가 계산 도중 시스템이 멎지 않도록 안정성도 필요하다.
    • 계산이 85% 완료된 상태에서 다운되면? 즉시 복구해서 그 시점부터 다시 실행할 수 있어야 한다.
    • 속도뿐만 아니라 정확성도 중요하다.

분산 아키텍처의 오류 8가지 - 5장. 아키텍처 특성 식별

• 네트워크는 믿을 수 있다.
• 레이턴시는 0이다: 분산 아키텍처 할지 말지 결정하는 기준 중 하나가 된다. 모놀리식 아키텍처라고 항상 나쁜건 아니다.
• 대역폭은 무한하다: 꼭 필요한 데이터만 주고받을 것.
• 네트워크는 안전하다.
• 토폴로지는 절대 안 바뀐다: 작은 네트워크 작업에도 애플리케이션이 영향을 받기 쉬워졌다. (네트워크가 필요한 구간이 많아졌기 때문이다.)
• 관리자는 한 사람이다: 아니다.ㅋㅋ (실무를 하면서 많이 겪은 일이다.)
• 운송비는 0이다: 여기서 비용은 말 그대로 “money”를 의미한다.
• 네트워크는 균일하다: 전혀 그렇지 않다.

아키텍처 의사 결정을 내릴 때 - 18장, 19장, 30장

• 도메인, 기술적인 이슈뿐만 아니라 조직(사람들), 프로세스, 운영까지 전반적인 이슈를 모두 고려해야 한다.
  • 예) 우리 팀이 다 만들 때 vs. 2팀 이상이 함께 협업할 때
• +) 비용, 출시 시기, 유저 만족도 등의 비즈니스적 가치도 함께 고려하자.
• 의사 결정에도 안티패턴이 있다.
  • 무한 반복 회의: 이걸 막기 위해서는 '왜 그런 결정을 내렸는지'를 끊임없이 들춰봐야 한다.
  • 이메일 기반 아키텍처: 이메일에 아키텍처 결정 사항을 넣지 말아야 한다. 대신, 위키 링크로 대체하는 게 좋다. ‘왜’를 찾기 위해 수십 건의 이메일을 주고받은 이력을 뒤지고 있을 순 없으니까..!
• 아키텍처 리스크 분석
  • 리스크 자체의 레벨뿐만 아니라 그 리스크가 전체에 얼마나 큰 영향을 미치는지도 함께 고려한다.
  • 어떤 기술을 모른다는 것 자체가 리스크가 될 수 있다(!)

ADR 포맷 - 19장. 아키텍처 결정

아키텍처가 아닌 그 아키텍처를 택한 결정에 대한 보고서다. 즉, 이력을 남기기 위한 템플릿인데 언젠가 써먹어 보고 싶다.

• 제목: 아키텍처 결정을 간략히 기재
• 상태: 제안됨, 수락됨, 대체됨
• 콘텍스트: 왜 이렇게 결정할 수밖에 없었나?
• 결정: 결정, 그리고 그렇게 결정한 합당한 사유
• 결과: 이 결정이 어떤 영향을 끼치는가?
• 노트: 이 결정에 관한 메타데이터
  • 예) 원저자, 승인일, 승인자, 대체일, 최종 수정일, 수정자, 최종 수정 내역

🌞 결론

• 완벽한 아키텍처는 없다. ‘왜’를 먼저 생각하자.
• 좋은 아키텍처 의사 결정을 내리기 위해서는 넓은 시야가 필요하다.