01장: 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

[minkukjo]

[MinJunKweon]

느낀점

• 뒤로 갈수록 소프트웨어 공학책을 읽는 느낌
• 학부생 때 봤던 것들이 몇 개 있었는데, 그 당시엔 몰랐지만 이제와서 회사를 다니면서 겪은 경험들이 생각나면서 "이게 그런말이었군" 하면서 와닿은게 몇개 있었음

---

정리

• 이전과 다르게 CPU/MEMORY 자원은 더이상 애플리케이션을 제한하는 요소가 아님
  • 하드웨어가 충분히 발전했기 때문에 + 리소스 자원은 충분하기 때문에
• 오늘날의 애플리케이션들은 설계에 있어서 데이터의 양, 데이터의 복잡성, 데이터의 변화속도에 대응하는 것이 큰 문제로 떠오름
• 일반적으로 애플리케이션들에서 고민해야할 기능들을 나눌 수 있음
  • 데이터를 영구 저장할 수 있는 기능 ⇒ 데이터베이스
  • 읽기 속도 향상을 위해 수행 결과 저장 ⇒ 캐시
  • 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공 ⇒ 검색 색인
  • 비동기 처리를 위해 다른 프로세스로 메시지 전송 ⇒ 스트림 처리
  • 주기적으로 대량의 누적된 데이터를 분석 ⇒ 일괄 처리
• 데이터 시스템을 위처럼 추상화되었기 때문에 각 기능들에 대한 도구들을 선택해서 손쉽게 애플리케이션을 설계할 수 있음
• 하지만, 애플리케이션마다 요구사항이 다르기 때문에 어떤 도구와 어떤 접근 방식이 적합한지 생각해야함

데이터 시스템에 대한 생각

• 데이터베이스, 큐, 캐시 등등 확연히 다른 것들을 왜 **“데이터 시스템”**으로 묶어서 지칭하는지?

1. 오늘날 데이터 시스템들은 전통적인 분류에 딱 들어맞지 않음
   • 데이터 스토어지만 메시지 큐로 사용하는 레디스(Redis)
   • 메시지 큐지만 ****지속성(Durability)을 가지고 있는 아파치 카프카(Apache Kafka)
   • 사용 사례에 따라 도구들이 나오기 때문에 전통적인 분류 경계가 모호해지고 있음
2. 애플리케이션이 단일 도구만으로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 요구사항을 가지고 있음
   • 메인 DB와 캐시 계층이나 검색 서버 같은 것들을 묶어서 사용하기 때문
   • 캐시 계층이나 검색 서버의 데이터 동기화 책임은 보통 애플리케이션 코드에서 관리함

• 데이터 시스템을 설계할 때 까다로운 문제가 많이 생김
  • 데이터가 항상 최신을 유지하도록 하기 위한 설계?
  • 서버 중 일부가 성능이 저하되더라도 클라이언트에 일관되게 좋은 성능으로 제공하는 방법?
  • 기타 등등..

소프트웨어 시스템에서 중요하게 여기는 세 가지 관심사

• 신뢰성(Reliability)
  • 하드웨어나 소프트웨어 결함, 휴먼 에러 등등으로 인해 시스템이 중단되지 않도록 지속적으로 올바르게 동작해야한다.
• 확장성(Scalability)
  • 시스템의 양과 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야한다.
• 유지보수성(Maintainability)
  • 시간이 지남에 따라 여러 다양한 사람들이 시스템 상에서 작업할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야한다.

신뢰성(Reliability)

• 애플리케이션은 사용자가 기대한 기능을 수행함
• 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용할 수 있음.
• 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족함.
• 시스템은 허가되지 않은 접근과 오남용을 방지함.

결함과 장애

• 결함(Fault)는 잘못될 수 있는 일을 의미

  • 결함을 예측하고 대처할 내결함성(fault-tolerant) 또는 탄력성(resilient)을 지녔다고 말함

• 장애(Failure)는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우

  • 결함 확률을 0으로 줄이는 것은 불가능함
  • 하지만, 결함이 장애로 이어지지 않게끔 내결함성 구조를 설계하는 것이 가장 좋음

• 고의적으로 결함을 유도해서 내결함성 시스템을 훈련하고 테스트할 수 있음

  • Netflix의 카오스 몽키(Chaos Monkey) : 고의적으로 프로세스를 일부러 죽이거나 결함을 일으켜서 테스트 해보는 접근 방식

  몽키 테스트 : https://en.wikipedia.org/wiki/Monkey_testing
  Android에서도 Monkey라는 테스팅 툴이 있음 (https://developer.android.com/studio/test/monkey?hl=ko)
  화면을 임의로 터치, 스크롤, 제스쳐 등등해서 제대로 동작하는지 검증하는 테스트

하드웨어 결함

• 하드디스크가 고장나고, 램에 결함이 생기고, 대규모 정전사태가 일어나고, 네트워크 케이블을 잘못 뽑는 등등
  • 늘상 일어날 수 있는 결함들
• 하드디스크의 평균 장애시간은 약 10 ~ 50년으로 보고됐다.
  • 즉, 10,000개 디스크로 구성된 저장 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다고 예상해야함
• 하드웨어 구성에 중복(Redundancy)을 추가하는 방법
  • 디스크 RAID(Redundant Array of Independent Disks**)** 구성
• 서버는 이중 전원 디바이스와 핫 스왑(Hot-swap) 가능한 CPU를 사용

Hot swap : PC 전원이 켜져있는 상태에서 하드웨어를 분리할 수 있는 기능
Hot Plug : 핫 스왑의 반댓말로, PC 전원이 꺼져있는 상태에서 하드웨어를 분리해야함

• IDC는 UPS 같은 비상전원을 확보하고, 비상전력을 발전할 수 있는 발전기를 마련해야함

소프트웨어 오류

• 잘못된 입력이 있을 때 모든 애플리케이션 서버 인스턴스가 죽는 버그
• CPU 시간, 메모리, 디스크 공간, 네트워크 대역폭처럼 공유 자원을 과도하게 사용하는 일부 프로세스
• 시스템 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
• 작은 결함이 다른 구성의 결함을 야기하는 cascading failure
• 예방법
  • 시스템이 뭔가를 보장하길 기대하면서 지속적으로 체크해 차이가 생기는 경우 경고를 발생시킬 수 있음
  • 빈틈없는 테스트, 프로세스 격리, 프로세스 재시작 등등

인적 오류(Human Error)

• 오류의 가능성을 최소화하는 방향으로 시스템을 설계하라
  • 절 설계된 추상화, API, 관리 인터페이스를 사용하면 “옳은 일”은 쉽게하고, “잘못된 일”은 막을 수 있음
• 사람이 가장 많이 실수하는 부분에서 실수로 장애가 발생할 수 있는 부분을 분리하라
  • 실제 데이터를 사용하기 전에 개발환경 샌드박스를 제공하라
• 단위 테스트부터 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트하라
  • 정상적인 동작에서는 거의 발생하지 않는 코너 케이스를 다루는데 유용함
• 장애 발생의 영향을 최소화하기 위해 인적 오류를 빠르고 쉽게 복구할 수 있게 하라
  • 설정 변경 내역을 빠르게 롤백하고 새로운 코드를 서서히 롤아웃하게 만듦
  • 이전 계산이 잘못된 경우를 대비해 데이터 재계산 도구를 제공하라
• 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련하라
  • 모니터링은 조기에 경고 신호를 보내줄 수 있고 특정 가정이나 제한을 벗어나는지 확인할 수 있게함
  • 문제가 있을 때 메트릭은 문제를 분석하는 데 매우 중요함
• 조작 교육과 실습을 시행하라.

신뢰성이 중요한 이유?

• 중요하지 않은 애플리케이션도 사용자에 대한 책임이 있음
  • 일평생의 사진과 동영상을 저장한 사용자가 DB 오류로 인해 모두 날아가게 된다면?

확장성

• 현재 부하를 간결하게 기술해야함
• 부하 매개변수(Load Parameter)로 나타낼 수 있음
  • 웹 서버의 초당 요청 수
  • DB의 Read/Write IO Rate
  • 대화방 동시 활성 사용자 (Active user)
  • 캐시 적중률(Cache hit rate)
  • 등등
• 트위터의 타임라인 성능 개선 일화 (가상 면접 사례 인터뷰 책 - 뉴스피드 설계 참조 Chapter 11. 뉴스 피드 시스템 설계 System-Design-Interview#11)
• 성능을 기술해야함
  • 부하에 따라 성능이 변화하는 것을 측정하기 위해 성능을 기술할 수 있어야함
  • 일괄처리 시스템은 보통 처리량(Throughput)
  • 온라인 시스템은 보통 응답시간(Response Time)
• 응답 시간을 분석할 때는 분포로 생각해야함
  • 응답 시간은 보통 꽤 빠르지만 특이 값이 존재함
  • 백분위로 나타내서 percentile p95, p99, p999 분위의 응답 시간을 통해 구분 가능
• 서비스 수준 목표(SLO)와 서비스 수준 협약서(SLA)에서 백분위로 되어있는 성능을 자주 표기함
• 큐잉 딜레이(Queueing delay)도 상당한 부분을 차지함
  • 큐에서 대기하는 시간이 오래걸려서 실제 처리속도는 빠르지만 클라이언트 입장에서 오래 대기해야하는 상황
  • 이를 Head-of-line Blocking이라고 부름
  • 그러므로 클라이언트 쪽 응답시간을 측정하는 것이 중요함

부하 대응 접근 방식

• 용량 확장 (스케일 업) ⇒ 좋은 장비로 업그레이드
• 규모 확장 (스케일 아웃) ⇒ 장비를 여러 대로 분산시켜서 부하 처리가 가능하도록 구성
• 부하 분산 아키텍처를 비공유(Shared-nothing) 아키텍처라고 부름
• 탄력적(Elastic)으로 부하가 증가하면 감지해서 자원을 자동으로 추가할 수 있음

유지보수성

• 초기 개발이 아니라 지속해서 이어지는 유지보수에 소프트웨어 비용 대부분이 들어감
• 소위 레거시 시스템 유지보수 작업을 좋아하지 않음
• 다른 사람의 실수를 고쳐야 하거나 한물 간 플랫폼에서 작업해야함

유지보수성을 위한 소프트웨어 시스템 설계 원칙

• 운용성(Operability)
  • 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라
• 단순성(Simplicity)
  • 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라
• 발전성(Evolability)
  • 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라.

운용성

• 시스템 상태를 모니터링하고 상태가 좋지 않다면 빠르게 서비스를 복원
  • 런타임 동작과 시스템 내부에 대해 가시성 제공
• 시스템 장애, 성능 저하 등의 문제의 원인을 추적
• 보안 패치를 포함해 소프트웨어와 플랫폼을 최신 상태로 유지
• 다른 시스템이 서로 어떻게 영향을 주는지 확인해서 변경사항 손상을 입히기 전에 차단
• 미래에 발생 가능한 문제를 예측해서 예방 (e.g. 용량계획)
• 배포, 설정 관리 등을 위한 모범 사례와 도구를 마련
  • 표준 도구를 이용해 자동화와 통합을 위한 우수한 지원을 제공
• 애플리케이션을 특정 플랫폼에서 다른 플랫폼으로 이동하는 등 복잡한 유지보수 태스크를 수행
• 설정 변경으로 생기는 시스템 보안 유지보수
• 예측 가능한 운영과 안정적인 서비스 환경을 유지하기 위한 절차 정의
• 인수인계 방식을 확립
  • 좋은 문서와 이해하기 쉬운 운영 모델 제공

단순성

• 추상화를 통해서 직관적인 외관 아래로 많은 세부 구현을 숨길 수 있음.
• 좋은 추상화는 다른 다양한 애플리케이션에서도 사용 가능함
• 재사용은 비슷한 기능을 여러 번 재구현하는 것보다 더 효율적임

발전성

• 시스템 요구사항이 변화할 때 Agile 기법으로 민첩성을 높일 수 있음

[HaeUlNam]

• Data-intensive: 데이터 양, 데이터 복잡성, 데이터가 변하는 속도 등, 데이터가 주요 도전 과제인 애플리케이션
• compute-intensive: CPU 사이클이 병목인 경우
• Reliability
  • 무언가 잘못되더라도 지속적으로 올바르게 동작함
  • Fault-tolerant or Resilent: 결함을 예측하고 대처할 수 있는 시스템
    • 결함을 모니터링 할 수 있고, fallback을 어떤 시나리오대로 가져갈 것이냐가 정해져있다고 하면 resilent한 시스템이라고 볼 수 있을 것 같다.
  • 결함 확률을 0으로 줄이는 것은 불가능
    • Q. Availability 지표로서 결함 Percentage를 모니터링할 수 있는가?
      • System Availability 정의를 살펴보면 downtime을 측정하기 위한 지표라는 것을 알 수 있다.
      • 그리고 사실상 defect percentage는 측정하기 어려움. 장애 건 수나 BUG 티겟등으로 측정할 수는 있을 듯.
  • 하드웨어 결함
    • 무작위적이고 서로 독립적. 약한 상관관계
    • 최근까지 단일 장비의 전체 장애는 매우 드물기에, 새 장비에 백업을 매우 빠르게 복원할 수 있는 한, 장애 발생 시 중단시간은 대부분 치명적이지 않다.
  • 소프트웨어 오류
    • 소프트웨어 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다. 소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다.
      • Cascading failure
        • Summary of the Amazon EC2 and Amazon RDS Service Disruption in the US East Region - ****https://aws.amazon.com/ko/message/65648/
  • 인적 오류
    • 오류의 가능성을 최소화하는 방향으로 시스템을 설계하라. 제한적인 인터페이스로 이를 달성할 수 있지만, 지나치게 제한적이면 사람들은 좋은 점을 잊은 채 제한된 인터페이스를 피해 작업한다.
      • Q. 지나치게 제한적이라는 의미가 지나치게 구체적이라는 뜻일까?
    • 사람이 가장 많이 실수하는 장소에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라. 실제 사용자에게는 영향이 없는 테스트 환경 제공.
    • 단위 테스트, 전체 시스템 통합 테스트, 수동 테스트, 자동 테스트까지 철저히 테스트
    • 장애 발생의 영향을 최소화하기 위해 인적 오류를 빠르게 쉽게 복구할 수 있도록 하라.
      • Slow roll out
    • 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련
• Scalability
  • 현재 부하를 load parameter에 따라 기술하고, 부하가 증가했을 때 어떻게 될지를 논의해야 함.
  • Load parameter 종류들: QPS, Read/Write ratio, active user, cache hit ratio
  • Twitter 예시
    • 주요 동작
      • 트윗 작성 - 평균 초당 4.6K 요청, 피크일 때 초당 12K 요청
      • 타임라인 작성 - 평균 초당 300K 요청.
    • Twitter의 확장성 문제는 Fan-out 문제 때문에 발생한다. Fan-out은 개별 사용자는 많은 사람들을 팔로우하고 많은 사람이 개별 사용자를 팔로우하는 문제이다.
    • 방법 1) 포스트는 간단히, 타임라인을 만들 때 복잡성 처리: 타임라인을 만들 때 User에 해당하는 followee들과 그에 해당하는 tweet을 찾아야 한다.
      • 타임라인 조회 성능이 방법2보다 떨어짐.
    • 방법 2) 타임라인을 간단히 만들고, 포스트할 때 복잡성 처리: 포스트를 만들 때, 각각 팔로워 타임라인 캐시에 새로운 트윗 정보를 삽입.
      • 방법1보다 타임라인 조회 성능이 상승
      • 다만, 구현 복잡도가 더 늘어나고, Real-time에 데이터를 전달하려고 노력하는 것이 도전 과제임.
  • Percentile로 latency를 monitoring
    • 아마존의 경우 응답 시간이 100밀리초 증가하면 판매량이 1% 줄어들고, 1초가 느려지면 고객 만족도 지표는 16% 줄어드는 현상을 관찰했다.
    • SLO(Service Level Objective), SLA(Service Level Agreement)
  • 부하 대응 접근 방식
    • scaling up vs scaling out
    • stateless service vs stateful service
• Maintainability
  • Operability - 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라
  • Simplicity - 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 이해하기 쉽게 만들어라
    • 우발적 복잡도는 구현에서만 발생하는 것으로 정의
    • 우발적 복잡도를 제거하기 위한 최상의 도구는 추상화 - 좋은 추상화는 깔끔하고 직관적인 외관 아래로 많은 세부 구현을 숨길 수 있다.
  • Evolvability - 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라.

[2rohyun]

신뢰성

• 결함은 장애와 동일하지 않다. 결함 확률을 0으로 줄이는 것은 불가능하다. 따라서 대개 결함으로 인해 장애가 발생하지 않게끔 내결함성 구조를 설계하는 것이 가장 좋다.
• 예방책이 해결책보다 더 좋은 경우가 있다. 바로 보안문제다.
• 하드웨어 결함
  • 10,000 개의 디스크로 구성된 저장 클러스터는 평균적으로 하루에 한 개의 디스크가 죽는다고 예상해야 한다.
  • AWS 같은 일부 클라우드 플랫폼은 가상 장비가 별도의 경고 없이 사용할 수 없게 되는 상황이 상당히 일반적이다. 이런 플랫폼은 단일 장비 신뢰성보다 유연성과 탄력성을 우선적으로 처리하게끔 설계됐기 때문이다.
• 소프트웨어 오류
  • 소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다. 시스템의 가정과 상호작용에 대해 주의 깊게 생각하기, 빈틈없는 테스트, 프로세스 격리, 죽은 프로세스의 재시작 허용, 프로덕션 환경에서 시스템 동작의 측정, 모니터링, 분석하기와 같은 여러 작은 일들이 문제 해결에 도움을 줄 수 있다.
• 인적 오류
  • 오류의 가능성을 최소화하는 방향으로 시스템을 설계 (추상화)
  • 비 프로덕션 샌드박스 제공
  • 철저하게 테스트
  • 빠르고 쉽게 복구할 수 있게
  • 명확한 모니터링 대책 마련
  • 조작 교육과 실습

확장성

• 트위터 사례에서 사용자당 팔로워의 분포는 팬아웃 부하를 결정하기 때문에 확장성을 논의할 때 핵심 부하 매개변수가 된다.

성능 기술하기

• 하둡과 같은 일괄 처리 시스템은 보통 처리량에 관심을 가진다. 온라인 시스템에서 더 중요한 사항은 서비스 응답 시간
• 보통 응답 시간이 가장 느린 요청을 경험한 고객들은 많은 구매를 해서 고객 중에서 계정에 가장 많은 데이터를 갖고 있어서다.

유지보수성

• 운용성, 단순성, 발전성

[LOG-INFO]

끄적끄적

• 9p. 이 같은 소프트웨어 결함을 유발하는 버그는 특정 상황에 의해 발생하기 전까지 오랫동안 나타나지 않는다.

  • Old Gen이 서서히 차다가 며칠 지나서야 Minor GC Time을 증가시키는 경험을 했었음

• 10p. 실제 데이터를 사용해 안전하게 살펴보고 실험할 수 있지만 실제 사용자에게는 영향이 없는 비 프록덕션 샌드박스를 제공하라

  • Read Only 서비스에서 사용하기 좋음. Write는 구축하기 어렵고 비쌈.

• 10p. 단위 테스트부터 전체 시스템 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트하라

  • 전체 시스템 통합 테스트... 너무 비쌈....

• 10p. 장애 발생의 영향을 최소화하기 위해 인적 오류를 빠르고 쉽게 복구할 수 있게 하라.

  • FlagR 같은 오픈소스 이용할 수 있음. Feature On/Off & Slow Rollout & whitelist & blacklist & ....
  • 하지만 유지보수성이 많이 저하될 수 있는 위험 존재

• 14p. "전형적인" 응답 시간을 알고 싶다면 평균은 그다지 좋은 지표가 아니다.

  • P50, P95, P99와 같은 백분위값 사용하는 것이 좋음

• 15p. SLO / SLA

  • .

[minkukjo]

끄적 끄적

• 책이 아직 안오다보니 1장을 영어 원서로 읽어서 한국어 버전과 내용이 다를 수 있습니다.
• 초반부에 근래의 애플리케이션 개발이 CPU 자원과 같은 컴퓨팅 intensive에서 data intensive로 가고있다는 것이 인상깊었음
• 그러면서 DB 캐시, 메시지, 검색 인덱싱, 배치와 같이 우리가 자주 쓰는 서비스들을 짚고 넘어간 점도 좋았음

• 데이터 저장소 간의 경계가 모호해지고 있다는 점도 인상 깊었음.
• Redis는 데이터 저장소이면서, 메시지 큐로도 사용할 수 있음 ( pub-sub )

• 모든 데이터 저장소는 그들의 역할에 맞게 나누어짐을 보여준다는 그림도 인상적.

• 그러면서 시스템에서 어떻게 데이터 시스템 영역을 감추고, 일관된 데이터를 보장하는지에 대해 설명함

• 데이터 중심 애플리케이션을 디자인한다는 것은 우리는 개발자일 뿐 아니라, 데이터 디자이너 이기도 하다는 말에 공감

• 결국 이러한 설계에 있어 필요한 부분들은 다양한 요구사항, 다양한 상황에 의존적일 수 밖에 없음

• 그래서! 가장 중요한 것은 모다?

• Reliability!

• Scalability!

• Maintainability!

신뢰성

• 사실상 위 요약을 좀 더 풀어쓴 내용이었음
• fault tolerance가 모든 장애를 다 OK해주는게 아니라, 특정 타입의 에러에 대해 견고해져야한다는 뜻이므로 오해하지 말자

If the entire planet Earth (and all servers on it) were swallowed by a black hole, tolerance of that fault would require web hosting in space

• 얘기하면서 블랙홀을 예시로 드는데 좀 웃겼음 ㅋㅋ
• 결국 무작위로 앱 죽여서 테스트도 해볼 수 있다는 구절 보자마자, 카오스몽키가 떠올랐는데 아니나 다를까 언급함

The Netflix Chaos Monkey [4] is an example of this approach.

확장성

• 트위터 홈 타임라인 DB 설계
• fan-out 문제를 해결하기 위한 해결책을 제시

• 1. 간단하게 관계형 테이블로 설계하고 조인

• 2. 타임라인에 대한 캐시 유지

• 응답시간을 분포로 보여줘야한다까진 이해했는데, SLO SLA라는 내용이 나오는데 잘 이해는 안감.. (왜 굳이? 라는 느낌)

• 큐잉 딜레이도 고려 사항

유지보수성

• 레거시 극혐
• 회사에서 레거시 로직 건드릴 때가 제일 무서운 것 같음
  • 이걸 리팩토링 한다고 했을때 문제가 없는데 우리가 알아볼 수 있는 수준으로 리팩토링하는게 맞는지? 아니면 잘 돌아가는 코드니까 괜히 건드리지 않는게 맞는 것인지? 딜레마에 빠져있음...
  • 갑자기 급 여러분들의 의견은 어떤지 궁금함(?)
• Operability, Simplicity, Evolvability
• 물론 이것을 하기 위한 쉬운 솔루션같은건 없음 ㅋㅋ

“good operations can often work around the limitations of
bad (or incomplete) software, but good software cannot run reliably with bad opera‐tions

• 캬...
• 내용은 약간 "음.. 그래 당연하지 그렇게 해야지.."라는 잔소리 같은 느낌?

• Simplicity는 추상화를 예를 들면서, 복잡한 것들은 감추자! 인데 이것도 뭐... 당연한 얘기..지 않나?

총평

• 1장이라서 그런지 트위터 예시 말고는 대체로 다 뜬구름 잡는 느낌에 뻔한 이야기긴 했지만, 그래도 소프트웨어 개발의 중요점들을 다시 한 번 상기시킬 수 있다는 점에서 좋은 듯!