Thoughtworks Technology Radar 26호 (39p PDF)
(thoughtworks.com)테크닉/도구/플랫폼/개발언어 및 프레임워크 분야의 최신 트렌드들을 Hold/Assess/Trial/Adopt 4단계로 시각화 및 설명하는게 특징
기묘한 시장 : 오픈소스의 변화하는 Economics
- 우리는 에릭 레이먼드의 "성당과 시장"의 팬이지만, 상용화 시도와 함께 복잡하게 변화하는 중
- ElasticSearch vs. OpenSearch 이나 Docker Desktop 같은 사례
- 반대로 페이스북이 Presto에 오픈소스 제품으로서 자금을 지원했기에 메인테이너들이 IP를 유지했고, 회사를 떠나 Trino로 리브랜딩했으니, 사실상 페북의 투자로 혜택을 봄
- 회사가 펀딩하지 않는 핵심 인프라가 많아지면서 상황은 더욱 혼란해짐
- Log4j 같은 사례에서 보듯, 중요한 보안버그가 발생했을 때에나 (오픈소스 개발자들의)무급노동에 얼마나 의존하고 있는지 알게 됨
- 경우에 따라선 GitHub Sponsor나 Patreon을 통해 취미 유지보수자(Hobbyist Maintainers)들에게 자금을 지원하면 차이를 만들기에 충분한 보상이 됨
- 다른 사람들에게는 자신의 하루 일과에 책임감이 더 추가되는 것처럼 느끼면서 번아웃이 되게 함
- 소프트웨어를 강력하게 지지하지만, Economics는 점점 이상해지고 있고, 올바른 균형을 찾는 쉬운 해결책은 없다는 것을 알고 있음
소프트웨어 공급망 혁신
- Equifax 데이터 유출, SolarWinds 공격, Log4J 취약점 같은 일들은 공급망 체인의 부실한 거버넌스 때문에 발생
- 팀들은 이제 프로젝트의 종속성을 검증하고 관리하는 일이 엔지니어링 프랙티스에 포함되어야 한다는 것을 깨닳음
- Supply chain Levels for Software Artifacts (SLSA)
- CycloneDX : Bill of Materials for Software / SaaS / Operations
- Syft : Software Bill of Materials 를 생성하는 CLI 도구 오픈소스
- 해커들은 보안분야에서 공격과 방어의 비대칭적 특성을 점점 더 많이 이용
- 공격자는 한개의 취약점만 찾으면 되지만, 방어자는 전체 공격 표면을 보호해야함
- 시스템을 안전하게 보호하기 위해 공급망 보안을 향상하는 노력이 중요함
왜 개발자들은 React에서 State Management를 계속 개발할까 ?
- 프레임워크가 대중화되면 결함을 개선하기 위한 일련의 도구들이 나오고 나서, 인기를 끄는 것들끼리 통합하는게 일반적
- 그런데 React State Management 는 이런 일반적인 경향을 따르지 않는 듯
- Redux가 출시된 이후로 약간 다른 방식으로 상태를 관리하는 도구 및 프레임워크들이 꾸준히 나오는 중
- 이유를 잘 모르겠는데 추측해 보자면..
- 자바스크립트 생태계가 선호하는 자연적인 이탈일까?
- React의 근본적인 결함인가?
- 개발자들이 실험해보기 좋은 재미있고 다루기 쉬운 문제일까?
- 문서 읽기 형식(웹브라우저)과 문서위에서 애플리케이션 인터랙션을 구현하는데 따른 영구적인 임피던스 불일치 때문일까 ?
- 계속 나오는 이유를 모르겠지만, 이 영구적인 문제를 해결하기 위한 다음 시도를 기대함
마스터 데이터 카탈로그에 대한 끝없는 모험
- 기업내 데이터를 수집 분류 하려는 노력은 계속 있었지만 복잡/중복/모호성 때문에 어려움
- Collibra, Datahub 같은 똑똑한 도구들이 출현
- 데이터 계보(Lineage) 및 메타데이터 전반에 걸친 일관된 접근을 제공하며, 거버넌스/관리/퍼블리싱등으로 확장 가능
- 이런 중앙집중식과는 반대로 데이터 메시 아키텍처를 기반으로 하는 연합 거버넌스 및 검색 으로 이동하는 움직임도 있음
[ Techniques ]
Adopt
- Four key metrics
- Single team remote wall
Trial
- Data mesh
- Definition of production readiness
- Documentation quadrants
- Rethinking remote standups
- Server-driven UI
- Software Bill of Materials
- Tactical forking
- Team cognitive load
- Transitional architecture
Assess
- CUPID
- Inclusive design
- Operator pattern for nonclustered resources
- Service mesh without sidecar
- SLSA
- The streaming data warehouse
- TinyML
Hold
- Azure Data Factory for orchestration
- Miscellaneous platform teams
- Production data in test environments
- SPA by default
[ Platforms ]
Trial
- Azure DevOps
- Azure Pipeline templates
- CircleCI
- Couchbase
- eBPF
- GitHub Actions
- GitLab CI/CD
- Google BigQuery ML
- Google Cloud Dataflow
- Reusable workflows in Github Actions
- Sealed Secrets
- VerneMQ
Assess
- actions-runner-controller
- Apache Iceberg
- Blueboat
- Cloudflare Pages
- Colima
- Collibra
- CycloneDX
- Embeddinghub
- Temporal
[ Tools ]
Adopt
- tfsec
Trial
- AKHQ
- cert-manager
- Cloud Carbon Footprint
- Conftest
- kube-score
- Lighthouse
- Metaflow
- Micrometer
- NUKE
- Pactflow
- Podman
- Sourcegraph
- Syft
- Volta
- Web Test Runner
Assess
- CDKTF
- Chrome Recorder panel
- Excalidraw
- GitHub Codespaces
- GoReleaser
- Grype
- Infracost
- jc
- skopeo
- SQLFluff
- Terraform Validator
- Typesense
[ Languages & Frameworks ]
Adopt
- SwiftUI
- Testcontainers
Trial
- Bob
- Flutter-Unity widget
- Kotest
- Swift Package Manager
- Vowpal Wabbit
Assess
- Android Gradle plugin - Kotlin DSL
- Azure Bicep
- Capacitor
- Java 17
- Jetpack Glance
- Jetpack Media3
- MistQL
- npm workspaces
- Remix
- ShedLock
- SpiceDB
- sqlc
- The Composable Architecture
- WebAssembly
- Zig
<성당과 시장>이 뭔지 궁금해서 찾아 보는데 번역본 전차책도 공짜로 출시되어있네요. 얼마전에 faker.js와 color.js 사건도 그러고, 오픈소스가 어떻게 돈을 벌 수 있을지(그리고 어떻게 지속가능한지)는 오픈 소스 생태계에 상당히 의존하게 된 요즘에는 갈수록 중요한 문제가 되어가고 있네요.