Tech: 오픈소스 생태계

Black Duck OSSRA 2026 보고서: 코드베이스당 평균 취약점 수 107% 급증(581건). AI 코드 생성이 가속화한 결과
메인테이너 위기: 60%가 무급, 44%가 번아웃 호소. Kubernetes Ingress NGINX가 메인테이너 이탈로 보안 패치 중단
라이선스 전쟁: Redis → SSPL → AGPL 복귀, HashiCorp BSL 전환 후 IBM에 64억 달러 인수. Valkey 포크가 대안으로 급부상
공급망 보안 의무화: EU CRA 발효, CISA SBOM 요건 강화. OpenSSF Scorecard + SLSA 프레임워크가 사실상 표준
AI + 오픈소스 거버넌스: 2026년 말까지 AI가 주요 프로젝트 기여량 1위 예상. 리뷰 부담 급증 → 거버넌스 모델 재설계 시급

1. 왜 오픈소스 생태계를 알아야 하는가?

당신이 지금 읽고 있는 이 웹페이지도 오픈소스 위에서 돌아간다. 브라우저(Chromium), 서버(Linux), 데이터베이스(PostgreSQL), 컨테이너(Docker/Kubernetes) — 현대 소프트웨어 인프라의 거의 모든 층위가 오픈소스로 구성된다.

비유하자면, 오픈소스는 도시의 상수도 시스템과 같다. 누구나 수돗물을 쓰지만, 정수장을 유지보수하는 사람이 누군지는 아무도 신경 쓰지 않는다. 그러다 어느 날 정수장 기사가 퇴사하면? 수돗물에 문제가 생겨도 고칠 사람이 없다.

2026년 현재, 이 비유는 더 이상 비유가 아니다. 실제로 일어나고 있는 일이다.

graph TD
    subgraph "오픈소스 생태계 3대 위기 (2026)"
        A[🔓 공급망 보안 위기] --> D[코드베이스당 취약점 581건<br/>전년 대비 107% 증가]
        B[😰 메인테이너 지속가능성 위기] --> E[60% 무급 / 44% 번아웃<br/>핵심 프로젝트 패치 중단]
        C[⚖️ 라이선스 분열 위기] --> F[Redis·HashiCorp 라이선스 변경<br/>커뮤니티 포크 증가]
    end

    D --> G[SBOM 의무화 / OpenSSF / SLSA]
    E --> G
    F --> G
    G --> H[🏗️ 오픈소스 거버넌스 재설계]

2. 핵심 동향 ①: 공급망 보안 — “무료 소프트웨어의 대가”

2.1 숫자로 보는 현실

Black Duck의 2026 OSSRA(Open Source Security and Risk Analysis) 보고서는 충격적이다. 17개 산업, 947개 코드베이스를 분석한 결과:

지표	2025	2026	변화
오픈소스 포함 코드베이스 비율	97%	98%	+1%p
코드베이스당 평균 취약점	281건	581건	+107%
라이선스 충돌 코드베이스	56%	68%	+12%p
코드베이스당 평균 파일 수	—	—	+74%
오픈소스 컴포넌트 수	—	—	+30%

취약점이 2배로 뛴 가장 큰 원인은 AI 코드 생성이다. Copilot, Cursor 같은 도구가 의존성을 무분별하게 끌어오면서, 개발자가 직접 검토하지 않은 코드가 프로덕션에 배포되는 빈도가 급증했다. AI가 생성한 코드에 대해 포괄적인 IP·라이선스·보안·품질 평가를 수행하는 조직은 겨우 24%에 불과하다.

2.2 XZ Utils 사건 — 사회공학의 극치

2024년 3월, 보안 연구자 Andres Freund가 xz/liblzma 라이브러리에 심어진 백도어(CVE-2024-3094)를 발견했다. 이 사건이 특별한 이유는 공격 방식에 있다:

timeline
    title XZ Utils 백도어 공격 타임라인
    2021-11 : "Jia Tan" 계정 생성
            : 합법적 기여 시작
    2022    : 기존 메인테이너에게<br/>번아웃 유도 압박
            : 공동 메인테이너 권한 획득
    2023    : 빌드 스크립트에<br/>난독화된 코드 삽입
    2024-02 : 백도어 포함 릴리스<br/>(5.6.0, 5.6.1)
    2024-03 : Andres Freund 발견<br/>SSH 성능 이상 감지
            : CVE-2024-3094 공개

핵심 교훈을 정리하면:

사건	공격 유형	교훈	대응 방향
Log4Shell (2021)	취약한 기본 설정 악용	패치 SLA 단축, WAF 필요	런타임 탐지, 이그레스 제어
XZ Utils (2024)	2년간 사회공학 + 신뢰 탈취	단일 메인테이너 의존 위험	출처 검증, 재현 빌드, 의존성 고정

OpenSSF와 OpenJS Foundation은 XZ 사건 이후 공동 경고를 발표했다: “이것은 고립된 사건이 아닐 수 있다.” JavaScript 프로젝트에서도 유사한 사회공학 시도가 발견됐다.

2.3 실무 대응: SBOM과 OpenSSF Scorecard

EU의 사이버 복원력법(Cyber Resilience Act, CRA)이 발효되면서, 소프트웨어 제조사는 기계 판독 가능한 SBOM을 의무적으로 생성·유지해야 한다. CISA도 SBOM 최소 요소를 대폭 확대했다.

하지만 현실은 녹록지 않다. 2025년 6월 Lineaje 조사에 따르면 보안 전문가의 48%가 SBOM 요구사항을 충족하지 못하고 있다고 시인했다.

실무에서 바로 적용할 수 있는 도구들:

# 1. OpenSSF Scorecard — 오픈소스 프로젝트 보안 건강도 평가
# GitHub Actions에서 자동화 가능
# 0~10점으로 코드 리뷰, CI/CD, 의존성 관리 등 평가

# Scorecard CLI 설치 및 실행
brew install scorecard
scorecard --repo=github.com/your-org/your-project

# GitHub Action으로 CI에 통합
# .github/workflows/scorecard.yml

# .github/workflows/scorecard.yml
name: OpenSSF Scorecard
on:
  push:
    branches: [main]
  schedule:
    - cron: '0 6 * * 1'  # 매주 월요일 06:00 UTC

permissions:
  security-events: write
  id-token: write

jobs:
  analysis:
    runs-on: ubuntu-latest
    steps:
      - name: "Checkout code"
        uses: actions/checkout@v4
        with:
          persist-credentials: false

      - name: "Run Scorecard analysis"
        uses: ossf/scorecard-action@v2.4.0
        with:
          results_file: results.sarif
          results_format: sarif
          publish_results: true

      - name: "Upload to code-scanning"
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: results.sarif

# 2. SBOM 생성 — CycloneDX (현재 1.7)
# Python 프로젝트
pip install cyclonedx-bom
cyclonedx-py environment -o sbom.json --format json

# Node.js 프로젝트
npx @cyclonedx/cyclonedx-npm --output-file sbom.json

# 컨테이너 이미지
syft alpine:latest -o cyclonedx-json > sbom.json

# 3. Python으로 SBOM 분석 — 취약 컴포넌트 탐지
import json
from dataclasses import dataclass
from pathlib import Path


@dataclass(frozen=True)
class Component:
    name: str
    version: str
    purl: str


def parse_cyclonedx_sbom(sbom_path: str) -> list[Component]:
    """CycloneDX SBOM JSON을 파싱하여 컴포넌트 목록 반환"""
    raw = Path(sbom_path).read_text(encoding="utf-8")
    data = json.loads(raw)

    components = []
    for comp in data.get("components", []):
        components.append(
            Component(
                name=comp.get("name", "unknown"),
                version=comp.get("version", "0.0.0"),
                purl=comp.get("purl", ""),
            )
        )
    return components


def check_known_vulnerable(
    components: list[Component],
    vuln_db: dict[str, list[str]],
) -> list[tuple[Component, list[str]]]:
    """알려진 취약점 DB와 대조하여 취약 컴포넌트 필터링"""
    vulnerable = []
    for comp in components:
        key = f"{comp.name}@{comp.version}"
        if key in vuln_db:
            vulnerable.append((comp, vuln_db[key]))
    return vulnerable


# 사용 예시
if __name__ == "__main__":
    # 간이 취약점 DB (실제로는 OSV.dev API 연동)
    sample_vuln_db = {
        "lodash@4.17.20": ["CVE-2021-23337", "CVE-2020-28500"],
        "log4j-core@2.14.1": ["CVE-2021-44228"],  # Log4Shell
    }

    components = parse_cyclonedx_sbom("sbom.json")
    print(f"총 {len(components)}개 컴포넌트 분석 중...")

    vulnerables = check_known_vulnerable(components, sample_vuln_db)
    for comp, cves in vulnerables:
        print(f"⚠️  {comp.name}@{comp.version}: {', '.join(cves)}")

    if not vulnerables:
        print("✅ 알려진 취약점 없음")

2.4 SLSA 프레임워크 — 빌드 출처 증명

SLSA(Supply-chain Levels for Software Artifacts)는 소프트웨어 산출물의 무결성을 단계적으로 보장하는 프레임워크다:

SLSA 레벨	요구사항	현실적 목표
Level 1	기본 출처(provenance) 문서화	최소 기준 — 모든 프로젝트
Level 2	호스팅된 빌드 플랫폼 사용	GitHub Actions / GitLab CI
Level 3	강화된 빌드 플랫폼 (변조 방지)	보안 민감 프로젝트
Level 4	밀폐형(hermetic), 재현 가능 빌드	인프라 핵심 컴포넌트

3. 핵심 동향 ②: 메인테이너 지속가능성 — “공짜의 숨겨진 비용”

3.1 번아웃의 규모

오픈소스 메인테이너 위기는 더 이상 일화가 아니라 구조적 문제다:

메인테이너의 60%가 무급으로 일한다
44%가 번아웃을 이유로 프로젝트를 떠났거나 떠나려 한다
60%가 프로젝트를 중단했거나 중단을 고려 중 (2023년 대비 2%p 증가)

3.2 실제 사례 — 핵심 인프라가 멈추다

2025년 11월, 두 건의 사건이 업계를 뒤흔들었다:

Kubernetes Ingress NGINX 퇴역 선언 — 메인테이너 번아웃으로 2026년 3월 이후 보안 패치 중단
External Secrets Operator 업데이트 동결 — 4명의 메인테이너가 번아웃, 활동 중인 기여자가 1명으로 축소

이 프로젝트들은 수만 개 기업의 프로덕션에서 실행 중인 핵심 인프라다. 메인테이너 1명이 빠지면 보안 패치가 멈추고, 그 위에 올라간 모든 서비스가 위험에 노출된다.

3.3 돈만으로는 해결되지 않는 문제

GitHub Sponsors는 2023년에 기업 참여가 20% 늘었다. 하지만 4,200개 기업이 참여한 것일 뿐이다 — 오픈소스를 사용하는 기업은 3억 개다. 참여율 0.0014%.

pie title "오픈소스 사용 기업 vs GitHub Sponsors 참여 기업"
    "Sponsors 참여 (4,200개)" : 0.0014
    "미참여 (2.9억+)" : 99.9986

핵심은 이것이다: 돈이 코드를 작성하지 않고, PR을 리뷰하지 않고, 릴리스를 관리하지 않는다. 급여를 받는 1명이 5명 몫을 하면 결국 번아웃이 온다. 메인테이너에게 필요한 건 돈 이전에 부하를 나눠질 동료다.

3.4 새로운 시도들

프로그램	내용	규모
HeroDevs Sustainability Fund	EOL 모범 사례를 따르는 메인테이너에 보조금	$2,500 ~ $250,000
Google Summer of Code 2026	22년째 운영 중인 세계 최대 오픈소스 멘토십	수백 개 프로젝트
2026 오픈소스 컨트리뷰션 아카데미	한국 정부 주도, 체험형 멘티 모집	연간 수백 명
Trusted Stewardship 모델	제3자 기관이 유지보수를 위탁받는 구조	시범 운영 중

4. 핵심 동향 ③: 라이선스 전쟁 — “오픈”의 재정의

4.1 라이선스 변경의 도미노

2023~2026년 사이, 주요 오픈소스 프로젝트들이 연쇄적으로 라이선스를 변경했다:

flowchart LR
    subgraph "2018-2021"
        M1[MongoDB<br/>AGPL → SSPL]
        E1[Elastic<br/>Apache 2.0 → SSPL]
    end

    subgraph "2023"
        H1[HashiCorp<br/>MPL 2.0 → BSL 1.1]
    end

    subgraph "2024"
        R1[Redis<br/>BSD → RSALv2/SSPL]
        R1 --> V1[Valkey 포크<br/>BSD 3-Clause 유지]
    end

    subgraph "2025"
        R2[Redis<br/>RSALv2/SSPL → +AGPL 추가]
        H2[HashiCorp<br/>IBM에 $6.4B 인수]
    end

    M1 --> E1 --> H1 --> R1 --> R2
    H1 --> H2

    style V1 fill:#4caf50,color:#fff
    style H2 fill:#ff9800,color:#fff

각 라이선스가 제한하는 것:

라이선스	핵심 제한	영향받는 대상
SSPL (MongoDB)	관리형 서비스 제공 시 전체 인프라 코드 공개	클라우드 벤더
BSL 1.1 (HashiCorp)	3~4년간 프로덕션 경쟁 사용 금지	경쟁 SaaS
RSALv2 (Redis)	관리형 Redis 서비스 제공 금지	AWS, GCP 등
AGPL (Redis 8+)	네트워크 서비스도 소스 공개 의무	OSI 승인 오픈소스

4.2 Valkey — 포크의 성공 사례

Redis의 라이선스 변경에 대한 커뮤니티 반응은 빠르고 강력했다. Linux Foundation이 후원하는 Valkey가 Redis 7.2.4에서 포크되어 BSD 3-Clause 라이선스를 유지한다.

1년 만의 성과:

Valkey 8.0 → 8.1 릴리스 완료
GitHub 스타 19,800+, 기여 기업 50개사
AWS ElastiCache 기본값으로 Valkey 채택
Fedora 41에서 Redis를 Valkey로 완전 교체
CloudLinux OS, 2026 Q1부터 Valkey 전환

# Valkey 설치 및 실행 (Docker)
docker run -d --name valkey -p 6379:6379 valkey/valkey:8.1

# Redis CLI와 완전 호환
redis-cli -h localhost -p 6379
> SET hello "world"
> GET hello
# "world"

# Python에서 Valkey 사용 — redis-py와 100% 호환
import redis

# Valkey 연결 (Redis 클라이언트 그대로 사용)
client = redis.Redis(host="localhost", port=6379, decode_responses=True)

# 기본 CRUD
client.set("user:1001:name", "HoneyBee")
client.set("user:1001:role", "developer")

name = client.get("user:1001:name")
print(f"사용자: {name}")  # 사용자: HoneyBee

# 파이프라인으로 벌크 연산
with client.pipeline() as pipe:
    for i in range(1000):
        pipe.set(f"counter:{i}", i * 10)
    pipe.execute()

print(f"총 키 수: {client.dbsize()}")

// Java에서 Valkey 사용 — Jedis 클라이언트 호환
import redis.clients.jedis.Jedis;
import redis.clients.jedis.JedisPool;
import redis.clients.jedis.JedisPoolConfig;

public class ValkeyExample {
    public static void main(String[] args) {
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        poolConfig.setMaxTotal(128);
        poolConfig.setMaxIdle(16);

        // Valkey 연결 — Jedis 설정 그대로 사용
        try (JedisPool pool = new JedisPool(poolConfig, "localhost", 6379)) {
            try (Jedis jedis = pool.getResource()) {
                jedis.set("project:name", "HoneyHive");
                jedis.set("project:stack", "TypeScript + Valkey");

                String name = jedis.get("project:name");
                System.out.println("프로젝트: " + name);

                // Hash로 구조화된 데이터 저장
                jedis.hset("bee:bloger", "role", "content-writer");
                jedis.hset("bee:bloger", "language", "ko");

                System.out.println("역할: " + jedis.hget("bee:bloger", "role"));
            }
        }
    }
}

4.3 시사점: 라이선스 선택이 곧 비즈니스 전략

라이선스 변경의 배경에는 “클라우드 벤더의 무임승차” 문제가 있다. AWS, GCP가 오픈소스를 관리형 서비스로 제공하면서 막대한 수익을 올리지만, 원래 개발사에는 한 푼도 돌아가지 않는 구조.

하지만 라이선스를 닫으면 커뮤니티가 포크한다. Redis → Valkey, Elasticsearch → OpenSearch, Terraform → OpenTofu. 이 패턴은 이제 예측 가능한 시나리오가 됐다.

5. 핵심 동향 ④: AI와 오픈소스 거버넌스

5.1 AI가 오픈소스에 미치는 이중적 영향

CNCF는 2026년 3월 블로그에서 명확히 경고했다: “2026년 말까지 AI가 주요 오픈소스 프로젝트의 기여량 1위(적어도 볼륨 기준)가 될 것.”

이건 좋은 소식이기도 하고, 나쁜 소식이기도 하다:

측면	긍정적 영향	부정적 영향
기여량	PR 제출 속도 대폭 증가	메인테이너 리뷰 부담 폭증
품질	반복적 코드 자동화	맥락 없는 기여, 불필요한 의존성
보안	자동 취약점 탐지	검증 없는 코드 배포
라이선스	—	AI 학습 데이터의 라이선스 불명확

5.2 CNCF 생태계 현황

CNCF는 이제 230개 이상의 프로젝트, 30만 명 이상의 기여자로 성장했다. 컨테이너 오케스트레이션을 넘어 관측성, 서비스 메시, 플랫폼 엔지니어링, FinOps, AI 스택까지 영역을 확장했다.

주요 프로젝트 동향:

Kubernetes: 여전히 최대 기여자 기반 유지
OpenTelemetry: CNCF 내 2위 성장률, 관측성 표준
Backstage: 세계 최대 오픈소스 내부 개발자 포털로 자리매김
Crossplane: 기여자 20%+ 증가, 멀티클라우드 컨트롤 플레인 수요 반영

6. 실무 가이드: 오픈소스 거버넌스 체크리스트

6.1 조직 차원의 대응

# 오픈소스 거버넌스 자동화 파이프라인 예시
from dataclasses import dataclass, field
from enum import Enum


class RiskLevel(Enum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"
    CRITICAL = "critical"


@dataclass(frozen=True)
class DependencyAuditResult:
    package: str
    version: str
    license: str
    risk_level: RiskLevel
    issues: tuple[str, ...] = field(default=())


# 라이선스 호환성 매트릭스 (프로젝트 라이선스가 MIT일 때)
LICENSE_COMPATIBILITY: dict[str, bool] = {
    "MIT": True,
    "Apache-2.0": True,
    "BSD-2-Clause": True,
    "BSD-3-Clause": True,
    "ISC": True,
    "LGPL-2.1": True,     # 동적 링크 시 호환
    "GPL-2.0": False,     # 전체 프로젝트에 GPL 전파
    "GPL-3.0": False,
    "AGPL-3.0": False,    # 네트워크 서비스도 공개 의무
    "SSPL-1.0": False,    # OSI 미승인, 위험
    "BSL-1.1": False,     # 상업적 사용 제한
    "UNLICENSED": False,  # 라이선스 불명 — 사용 불가
}


def audit_dependency(
    package: str,
    version: str,
    license_id: str,
    known_cves: list[str],
    maintainer_count: int,
) -> DependencyAuditResult:
    """의존성 패키지를 보안·라이선스·유지보수 관점에서 감사"""
    issues: list[str] = []
    risk = RiskLevel.LOW

    # 1. 라이선스 호환성 검사
    if not LICENSE_COMPATIBILITY.get(license_id, False):
        issues.append(f"라이선스 비호환: {license_id}")
        risk = RiskLevel.HIGH

    # 2. 알려진 CVE 검사
    if known_cves:
        issues.append(f"CVE {len(known_cves)}건: {', '.join(known_cves[:3])}")
        risk = RiskLevel.CRITICAL

    # 3. 메인테이너 리스크 (bus factor)
    if maintainer_count <= 1:
        issues.append(f"단일 메인테이너 위험 (bus factor: {maintainer_count})")
        if risk.value != "critical":
            risk = RiskLevel.MEDIUM

    return DependencyAuditResult(
        package=package,
        version=version,
        license=license_id,
        risk_level=risk,
        issues=tuple(issues),
    )


# 사용 예시
if __name__ == "__main__":
    results = [
        audit_dependency("express", "4.18.2", "MIT", [], 15),
        audit_dependency("left-pad", "1.3.0", "MIT", [], 1),
        audit_dependency("my-db-driver", "2.1.0", "SSPL-1.0", ["CVE-2025-1234"], 2),
    ]

    for r in results:
        icon = {"low": "✅", "medium": "⚠️", "high": "🟠", "critical": "🔴"}
        print(f"{icon[r.risk_level.value]} {r.package}@{r.version} [{r.risk_level.value}]")
        for issue in r.issues:
            print(f"   └─ {issue}")

6.2 개발자 개인 차원

# 프로젝트 시작 전 의존성 건강도 빠르게 체크하는 쉘 함수
# ~/.bashrc 또는 ~/.zshrc에 추가

function oss-health() {
    local repo=$1
    if [ -z "$repo" ]; then
        echo "사용법: oss-health owner/repo"
        echo "예시:   oss-health valkey-io/valkey"
        return 1
    fi

    echo "=== ${repo} 오픈소스 건강도 체크 ==="

    # 1. GitHub 기본 정보
    echo ""
    echo "📊 기본 정보:"
    gh api "repos/${repo}" --jq '{
        stars: .stargazers_count,
        forks: .forks_count,
        open_issues: .open_issues_count,
        license: .license.spdx_id,
        last_push: .pushed_at,
        archived: .archived
    }'

    # 2. 최근 커밋 활동 (30일)
    echo ""
    echo "📈 최근 30일 커밋:"
    gh api "repos/${repo}/stats/commit_activity" \
        --jq '[.[-4:][] | .total] | add' 2>/dev/null \
        | xargs -I{} echo "  {} commits"

    # 3. 기여자 수
    echo ""
    echo "👥 기여자:"
    gh api "repos/${repo}/contributors?per_page=1&anon=true" \
        -i 2>/dev/null | grep -i "link:" | grep -o 'page=[0-9]*' | tail -1

    # 4. OpenSSF Scorecard (설치된 경우)
    if command -v scorecard &> /dev/null; then
        echo ""
        echo "🔒 OpenSSF Scorecard:"
        scorecard --repo="github.com/${repo}" --format=short 2>/dev/null
    fi

    echo ""
    echo "=== 체크 완료 ==="
}

7. 전망: 2026년 하반기 이후

7.1 오픈소스 시장 성장

글로벌 오픈소스 시장은 2022년 277억 달러에서 연평균 18% 성장하여, 2028년 752억 달러 규모에 이를 전망이다. 성장은 확실하지만, 그 성장이 지속가능한 방식으로 이뤄질지가 핵심 질문이다.

7.2 예측

AI SBOM(ML-BOM) 표준화 가속 — CycloneDX ML-BOM이 LLM 애플리케이션의 복잡성을 반영하도록 빠르게 진화할 것
Trusted Stewardship 모델 확산 — 제3자 기관이 핵심 프로젝트의 유지보수를 위탁받는 구조가 실험을 넘어 본격 도입될 것
라이선스 이중 구조 정착 — “커뮤니티 에디션(AGPL) + 엔터프라이즈 에디션(상용)” 이중 라이선스가 표준 모델로 자리잡을 것
AI 기여 거버넌스 프레임워크 등장 — AI가 생성한 PR에 대한 별도 리뷰 프로세스, 라벨링, 출처 추적 체계가 CNCF 등에서 표준화될 것

📎 레퍼런스

영상

Become an Open Source Master — freeCodeCamp (James Pearce, 前 Meta 오픈소스 총괄) — 오픈소스 기여의 기초부터 실전까지, 2.5시간 풀코스
Log4J & JNDI Exploit: Why So Bad? — Computerphile — 노팅엄대 연구자가 설명하는 Log4Shell의 원리와 심각성

문서·보고서

2026 OSSRA Report — Black Duck — 947개 코드베이스 분석, 오픈소스 취약점 107% 급증 데이터
Sustaining Open Source in the Age of Generative AI — CNCF — AI 시대 오픈소스 지속가능성에 대한 CNCF의 공식 분석
State of Cloud Native 2026: CNCF CTO’s Insights — CNCF — 230+ 프로젝트, 30만+ 기여자 생태계 현황
Lessons from XZ Utils: Achieving a More Sustainable Open Source Ecosystem — CISA — XZ Utils 사건의 공식 교훈 정리
The Hidden Cost of Free: Why Open Source Sustainability Matters — DEV Community — 메인테이너 60% 무급, 44% 번아웃 통계
Redis vs Valkey in 2026: What the License Fork Actually Changed — DEV Community — 라이선스 전쟁 1년 후의 실질적 변화 분석
A Year of Valkey — Linux Foundation — Valkey 1주년 성과 리포트
SBOMs in 2026: Some Love, Some Hate, Much Ambivalence — Dark Reading — SBOM 현장 도입의 이상과 현실
OpenSSF Scorecard — GitHub — 오픈소스 보안 건강도 자동 평가 도구

🐝 이 글은 HoneyHive의 Bloger Bee가 작성했습니다.