대규모 시스템이 확장성(scalability), 신뢰성(reliability/availability), 성능(performance) 등에서 직면하는 문제들을 이해하고 실전 엔지니어링 경험과 패턴들을 알 수 있도록 읽을거리(북마크 사이트 정보 제공)를 제공함.
왜 기업들이 고유의 디자인 시스템을 구축하는지, 디자인 시스템에서 배울 수 있는 것들, 디자인 시스템 구축 시의 도전과 해결책, 주요 예시 13개를 소개하면서 디자인 시스템을 만들기 위해서 필요한 고민들을 정리해 놓은 글.
개발자나 기술 조직은 변화하는 환경에 맞춰 스킬셋과 역할을 재정의해야한다는 내용의 글(기업이나 조직 입장은 AI 협업 개발 환경, 에이전트 생태계 설계, 새로운 인적자원 개발 전략이 필요하고, 개발자는 코드만 쓰는 개발자보다는 문제를 정의하고 설계하며 AI를 활용해 만드는 개발자로 진화가 필요)
Google이 사용하는 소프트웨어 엔지니어링 관행(코드베이스를 유지하고 건강하게 확장하기 위한 조직·문화·도구·프로세스)을 다루고 있으며, 규모, 시간, 비용 세가지 큰 축을 중심으로 이야기하며 느낄수 있는 교훈이 많이 담겨져 있는 무료 책.
스타트업에서 기술 리더(CTO)를 맡은 사람이 마주하는 다방면의 과제들(기술적인 것, 조직적인 것, 사람을 이끄는 것)에 대해 실질적인 가이드 라인을 제공.
스타트업이 처음 ‘짙은 재미’를 갖는 이유는 빠른 시행착오, 강한 주인의식, 높은 자율성 덕분이며, 회사가 커지고 조직이 복잡해질수록 이 재미는 자연스럽게 감소한다. 이를 막기 위해선 대기업 방식으로 빨리 전환하지 말고, 자율성과 주인의식을 유지할 수 있는 구조를 조직 내에서 설계해야 한다.
Google의 엔지니어링 문화에서 중요하게 다뤄지는 디자인 문서(Design Doc) 작성 관행을 정리한 글. 매뉴얼 수준이 아니라, 조직 내에서 중요한 설계 결정(trade-offs), 대안(alternatives), 설계 이유(reasoning)을 명확히 공유하는 수단으로 활용한다는 내용의 글.
소프트웨어 품질을 일반적으로 생각하는 것처럼 품질이 높으면 비용이 더 든다는 식으로 단순히 보면 안되고 내부 품질과 외부 품질을 나누어야 하고 내부 품질이 좋으면 향후 기능 추가·변경이 쉬워지고 비용이 낮아진다는 것이 핵심 주장의 글.
고품질 코드가 결함이 15배 적었고, 개발속도가 2배 빠르며, 문제 해결 시간이 좀 더 예측 가능했다고 함. 그래서 고품질 코드의 비즈니스 이점은 분명하다는 논문.
데이터가 들어오는 시점에 단순히 검증(validate)만 하는 것이 아니라, 데이터를 구조화(parsing)해서 더 이상 잘못된 상태(invalid state)를 갖지 않는 타입/구조로 변환하라는 설계 철학을 담고 있는 글.