Skip to content

Open-source

  • Published on
    커널에 첨 기여할 때 막히는 곳은 대개 코드가 아니라 절차입니다. 첫 패치가 반려되는 이유의 상당수는 로직이 아니라 형식이고, 그 형식은 전부 커널 트리 안에 문서로 들어 있습니다. 이 글은 scripts/checkpatch.pl과 scripts/get_maintainer.pl이 각각 무엇을 답해주는지, Signed-off-by가 왜 필수이며 무엇을 증명하는지, 커밋 메시지가 왜 75열이고 --- 줄 아래는 왜 체인지로그에 남지 않는지, 왜 첨부가 아니라 본문 인라인이어야 하는지를 커널 공식 문서를 근거로 정리합니다. 마지막으로 리뷰 문화 — 무뚝뚝한 답장의 의미와, 답하지 않으면 무시당한다는 문서의 명시적 경고를 다룹니다.
  • Published on
    리눅스 커널을 공부하겠다고 마음먹은 사람이 가장 먼저 부딪히는 것은 개념이 아니라 규모입니다. 실제로 트리를 받아 세어 본 숫자로 커널이라는 코드베이스가 어떤 물건인지 먼저 보여 주고, 그중 몇 퍼센트를 평생 열어 볼 일이 없는지 정직하게 짚습니다. 그다음 현실적인 진입 경로를 읽기·관측·기여 세 갈래로 나눠 각각이 누구에게 맞는지, 왜 처음부터 순서대로 읽겠다는 계획이 거의 항상 실패하는지 설명합니다. 마지막은 전제 조건입니다. C와 포인터와 빌드 시스템은 정말로 필요하고, 어셈블리 전문성과 하드웨어와 학위는 필요하지 않다는 것을 근거와 함께 정리했습니다. 이 글은 운영체제 이론을 다시 가르치지 않습니다. 커널의 동작을 설명하는 글이 아니라, 그 동작을 구현한 코드를 직접 찾아 읽기 시작하기 위한 지도입니다.
  • Published on
    사내 성과의 약점은 검증할 수 없다는 것입니다. 비공개이고, 팀 단위이고, 남의 말로만 전달됩니다. 회사 밖 산출물은 링크 하나로 확인되지만 사내 경력을 대신하지는 않습니다. 무엇이 포트폴리오로 작동하고 무엇이 시간만 먹는지, 완결된 하나가 미완성 열 개보다 강한 이유, 공개 글쓰기가 아무도 읽지 않아도 회수되는 효용과 그 한계를 정리했습니다. 오픈소스 기여의 현실적인 진입로와 이력서에서 실제로 힘을 갖는 흔적이 무엇인지, 종료 조건 없는 프로젝트가 왜 증거가 되지 못하는지도 다룹니다. 고용 계약과 관할에 따라 공개 범위가 다르다는 점, 여가 시간이 구조적으로 없는 사람에게 이 기준이 왜 불공정한지까지 적었습니다. 커리어를 움직이는 선택 시리즈의 8편입니다.
  • Published on
    DeepSeek이 공개한 오픈소스 코딩 에이전트 Harness는 모델도 도구도 UI도 전부 플러그인으로 만든 구조입니다. 그런데 실제로 흥미로운 부분은 플러그인이라는 단어가 아니라 두 가지 설계 결정입니다. 하나는 모든 실행을 추가 전용 이벤트 로그로 남겨 재개·분기·재생을 같은 스트림 위에서 처리한다는 것이고, 다른 하나는 플러그인 해제 시 부수 효과를 되돌리도록 강제한다는 것입니다. 이 구조가 무엇을 가능하게 하는지, 그리고 플러그인 생태계에 대한 오래된 반론이 왜 여전히 유효한지 정리합니다.
  • Published on
    한때 프론트엔드 프로젝트의 기본값이었다가 지금은 새 프로젝트에서 잘 고르지 않게 된 도구 10개를, 공식 폐기 공지와 저장소 보관 상태 같은 확인 가능한 근거만으로 정리합니다. Create React App, Bower, TSLint, Karma, Protractor, PhantomJS, LibSass와 node-sass, Moment.js, Rome, Grunt를 각각 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우의 여섯 항목으로 나눠 봅니다. 이 도구들은 대부분 자기 시대에는 정답이었고, 남긴 아이디어는 후속 도구 안에 그대로 들어가 있습니다. 상태 정보는 모두 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    데이터 계층에서 자리를 내주었거나 배포 조건이 바뀐 프로젝트 10개를 공식 발표문과 Apache Attic 기록만 근거로 정리합니다. Redis와 Elasticsearch, MongoDB의 라이선스 변경과 그로 인해 생긴 Valkey, OpenSearch 포크를 사실만으로 다루고, Kafka에서 ZooKeeper가 빠진 과정, Apache Attic으로 이관된 Sqoop과 Oozie, Giraph, Tajo, 회사 종료 후 리눅스 재단으로 간 RethinkDB, 상표 문제로 이름을 바꾼 PrestoSQL과 Trino를 살펴봅니다. 각 항목은 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠 정리했습니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    한때 컨테이너 인프라의 기본 구성이었다가 지금은 다른 것으로 대체된 프로젝트 11개를 공식 공지와 저장소 보관 상태만 근거로 정리합니다. rkt, dockershim, Classic Swarm, Docker Machine, Compose V1, Heapster, Apache Mesos, PodSecurityPolicy, CoreOS Container Linux, ingress-nginx, 그리고 HashiCorp 라이선스 변경과 OpenTofu를 다룹니다. 각 항목은 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠 봅니다. 인프라 계층의 교체는 성능보다 운영 부담과 표준화, 그리고 유지보수 인력이 원인인 경우가 많습니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    공식 종료 공지가 남아 있는 언어와 프레임워크, 런타임 11개를 정리합니다. Python 2, AngularJS, Vue 2, Nashorn, 자바 애플릿과 웹 스타트, Mono, Xamarin, PhoneGap, Atom, io.js, jQuery Mobile을 각각 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠 봅니다. 이 계층에서는 종료 날짜가 공식 문서에 명확히 적히는 경우가 많아 상태 확인이 비교적 쉽습니다. io.js처럼 갈라졌다가 다시 합쳐진 사례, Mono와 Atom처럼 코드가 다른 프로젝트의 기반으로 남은 사례도 함께 다룹니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    자리를 내준 오픈소스 시리즈의 마지막 편입니다. 앞선 세 편에서 다룬 30여 개 프로젝트를 가로질러, 기술을 교체시키는 힘이 무엇인지 다섯 가지로 정리합니다. 플랫폼 흡수, 운영 부담, 유지보수 인력, 라이선스 변경, 문제 정의의 이동. 특히 라이선스 변경은 MongoDB와 Elastic, HashiCorp, Redis 사례를 어디에서 어디로 바뀌었는지 사실만으로 표에 정리하고, 그 결과 생긴 OpenSearch와 OpenTofu, Valkey 포크를 함께 짚습니다. 이어서 우리 조직의 스택이 같은 궤적 위에 있는지 확인하는 관측 가능한 신호 목록과 GitHub API 점검 명령, 그리고 지금 옮길지 기다릴지를 가르는 판단 기준을 제시합니다. 상태 정보는 2026년 8월 12일에 원문에서 직접 확인했습니다.
  • Published on
    LLM 애플리케이션 스택은 추론 서버, 오케스트레이션, 게이트웨이, 에이전트, RAG로 층이 갈라졌습니다. 각 층에서 실제로 쓰이는 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 프로젝트마다 무엇을 대체하는지, 성숙도가 어느 정도인지, 어떤 상황에서 쓰면 안 되는지를 함께 정리했고, 저장소 경로와 라이선스, 스타 수, 최근 푸시 날짜는 2026년 8월 12일 GitHub에서 직접 확인한 값을 그대로 적었습니다. Open WebUI의 브랜딩 제한 조항처럼 OSI 승인 오픈소스가 아닌 경우도 숨기지 않고 표시합니다.
  • Published on
    데이터 파이프라인은 스케줄러 하나로 해결되지 않습니다. 적재, 변환, 오케스트레이션, 실행 엔진, 모델 수명 주기, 검색 저장소가 각각 다른 도구의 영역이 되었습니다. 이 층들에서 실제로 쓰이는 오픈소스 11개를 스타 순위가 아니라 담당 구간별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수, 최근 푸시는 2026년 8월 12일 GitHub에서 직접 확인한 값입니다. 오픈소스 코어와 상용 관리형 제품의 경계가 어디인지도 함께 짚습니다.
  • Published on
    패키지 설치, 린트, 번들링처럼 하루에 수십 번 반복되는 작업이 네이티브 언어로 다시 쓰이면서 대기 시간이 초 단위에서 밀리초 단위로 내려갔습니다. 빌드 도구, 에디터, 터미널, CLI 영역에서 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수, 최근 푸시는 2026년 8월 12일 GitHub에서 직접 확인했습니다. Bun의 LGPL 정적 링크 조건이나 Zed의 GPL 병존처럼 재배포에 영향을 주는 라이선스 조건도 함께 다룹니다.
  • Published on
    스타 수는 인기 지표이지 위험 지표가 아닙니다. 오픈소스를 프로덕션에 들이기 전에 실제로 확인해야 하는 신호를 정리합니다. 최근 커밋과 릴리스 주기, 이슈 응답, 기여자 분포와 버스 팩터를 GitHub API로 직접 세는 방법, 라이선스가 자동 분류되지 않을 때 LICENSE 파일을 직접 읽어야 하는 이유, 그리고 도입 전 체크리스트를 담았습니다. 시리즈에서 실제로 확인한 사례를 근거로 삼았고, 저장소 정보는 2026년 8월 12일 GitHub에서 직접 확인한 시점 값입니다.
  • Published on
    데이터베이스와 인프라 영역은 라이선스 변경과 포크가 판을 다시 짠 분야입니다. 분석 엔진, 임베디드 데이터베이스, 포스트그레스 확장, 쿠버네티스 오퍼레이터, IaC까지 실제로 자리를 잡은 오픈소스 11개를 스타 순위가 아니라 해결하는 문제별로 묶어 소개합니다. 무엇을 대체하는지, 어느 정도 성숙했는지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는 2026년 8월 12일 GitHub에서 직접 확인한 값이며, pgvector가 선언하는 PostgreSQL 라이선스처럼 GitHub이 자동 분류하지 못하는 경우는 LICENSE 파일을 직접 읽어 확인했습니다.
  • Published on
    관측 데이터는 양이 곧 비용이고, 보안 도구는 파이프라인에 들어가지 못하면 쓰이지 않습니다. 계측 표준, 저장 엔진, eBPF 기반 런타임 감시, 공급망 검증까지 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 담당하는 층별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는 2026년 8월 12일 GitHub에서 직접 확인했으며, 이 분야에 특히 많은 AGPL과 부분 상용 라이선스가 자체 호스팅 서비스 제공에 어떤 의미인지도 함께 정리합니다.
  • Published on
    OpenJDK는 2026년 4월에 생성형 AI로 만든 기여를 전면 금지했고, 같은 오라클 산하의 GraalVM은 같은 시기에 AI 코딩 어시스턴트 사용을 명시적으로 허용했습니다. 두 프로젝트는 같은 기여자 협약을 씁니다. 이 글은 세 문서를 나란히 놓고 읽습니다. OpenJDK 원문, GraalVM의 정책 파일, 그리고 둘 다 참고한 리눅스 커널 문서입니다. 결론은 이 차이가 AI에 대한 태도 차이가 아니라 검토 부담을 누구에게 청구할 것인가에 대한 설계 차이라는 것이고, 그 축을 알면 우리 리포의 정책도 쓸 수 있습니다.
  • Published on
    Nixpkgs 코어 팀이 10개월 만에 해산했습니다. 기여자가 수천 명인 저장소에서 위임된 의사결정 권한을 가진 사람은 두 명이었고, 그 두 명이 물러나자 해당 관할은 직접적인 주인이 없는 상태가 되었습니다. 이 사건을 근거로 의존성 위험을 평가할 때 스타 수와 커밋 수가 아니라 승인 권한을 가진 사람의 수, 위임 구조의 실효성, 에스컬레이션 경로를 봐야 하는 이유를 정리하고, GitHub API로 직접 셀 수 있는 지표와 그 한계를 함께 다룹니다. 원문 발표문의 표현을 그대로 인용해 무엇이 사실이고 무엇이 해석인지 구분합니다.
  • Published on
    2026년 7월 29일 GCC 운영위원회가 AI 정책 작업 그룹의 권고안을 받아들였습니다. 핵심은 법적으로 유의미한 기여에 LLM 생성 콘텐츠가 포함되거나 그로부터 파생된 경우 받지 않는다는 것이고, 그 기준선은 GNU 유지보수자 지침의 약 15줄입니다. 다만 테스트 케이스는 예외이고, 연구·분석·버그 발견·패치 리뷰에 LLM을 쓰는 것 자체는 막지 않으며, AI 보조 작업에는 Assisted-by 트레일러를 요구합니다. 이 글은 정책의 실제 요구 사항, 그 배경에 있는 저작권 양도와 DCO 문제, 리눅스 커널·Debian·NetBSD·Gentoo·QEMU가 각각 어디에 선을 그었는지, 그리고 기여자에게 실제로 달라지는 것을 정리합니다.
  • Published on
    2026년 7월 30일 André Arko가 "Ruby Central의 파괴적 유산"을 발표하면서, 2025년 9월에 시작된 RubyGems 저장소 접근 권한 분쟁이 열 달 만에 다시 표면으로 올라왔습니다. 이 글은 양쪽의 1차 진술을 나란히 놓고 확인 가능한 타임라인을 정리한 뒤, 왜 같은 형태의 위기가 core-js, event-stream, xz-utils, Nix, Redis, Terraform에서 반복되는지를 구조로 분석합니다. 핵심은 세 개의 축입니다 — 상표를 누가 갖고, 패키지 인프라를 누가 통제하며, 유지보수자에게 누가 돈을 주는가. 이 셋이 서로 다른 주체에게 흩어져 있을 때 위기는 시간 문제입니다. 같은 시기에 종료된 Artichoke Ruby가 이 사태와 무관하다는 사실도 확인해 적었습니다.
  • Published on
    2026년 6월 24일 curl 8.21.0은 한 릴리스에 CVE 18개를 발행하며 프로젝트 기록을 새로 썼습니다. 그런데 18개 전부가 Low 아니면 Medium이고, High 등급은 2023년 10월 이후 한 건도 없습니다. 이 숫자 뒤에는 AI 슬롭 보고서에 시달리다 2026년 1월 말 버그바운티를 폐지한 프로젝트가, 3월부터는 정반대로 "거의 전부 AI를 썼는데 품질은 높은" 보고서 홍수를 맞고 있는 이야기가 있습니다. 이 글은 curl이 직접 공개하는 vuln.json 데이터로 기록 주장을 검산하고, 18개 CVE가 실제로 고친 것(커넥션 재사용 클러스터, HTTP/3 early data, QUIC busy-loop, 10년 묵은 super cookie), CVE가 되지 못한 버그를 둘러싼 MITRE 분쟁, 그리고 libcurl을 어딘가에 깔고 있는 — 사실상 모든 — 팀이 이 흐름에서 무엇을 준비해야 하는지 정리합니다. 결론부터: 패닉할 이유는 없지만, 스캐너 노이즈와 패치 케이던스는 확실히 달라집니다.
  • Published on
    2024년 초 Flux의 원 개발사 Weaveworks가 문을 닫았을 때, GitHub 디스커션에는 "이 프로젝트의 미래는 위험한가?"라는 질문이 올라왔습니다. 2년 반이 지난 2026년 6월 30일, Flux는 2.9.0을 릴리스했습니다. 이 글은 그 사이에 실제로 일어난 일을 검증 가능한 1차 자료로 재구성합니다 — 릴리스 케이던스가 어떻게 흔들렸다 회복됐는지(v2.0부터 v2.9까지 릴리스 간격 실측), 지금 코어 메인테이너 9명이 어디에 소속돼 있는지(CORE-MAINTAINERS 파일 기준 ControlPlane 3명), 돈이 어디서 나오는지(오픈코어 모델과 그 경계선), 그리고 Flux 2.9가 실제로 담은 것(CLI 플러그인 시스템, SSA 필드 무시 규칙, 포스트퀀텀 SOPS)을 봅니다. 결론은 양면적입니다 — 프로젝트는 살아남았고 케이던스는 회복됐지만, 유지보수 동력의 상당 부분이 한 회사의 상업적 성공에 걸려 있다는 구조적 리스크는 여전히 남아 있습니다.
  • Published on
    2026년 4월 25일 minio/minio 저장소가 GitHub에서 아카이브됐고, 7월 14일에는 mc 클라이언트 저장소까지 읽기 전용이 됐습니다. 격앙된 스레드는 많지만 이 글은 분노가 아니라 기록을 따라갑니다 — 2025년 5월 콘솔 기능 제거, 9월 Docker Hub 이미지 중단, 10월 15일 마지막 릴리스와 소스 코드 전용 배포 선언, 12월 유지보수 모드, 2026년의 아카이브 연쇄까지 전부 저장소의 커밋·릴리스 노트·레지스트리 메타데이터로 검증한 타임라인입니다. 흔한 오해와 달리 라이선스는 끝까지 AGPLv3였다는 점, 그리고 high 등급 CVE-2025-62506의 수정이 공식 공개 이미지로는 끝내 배포되지 않았다는 점도 확인합니다. 후반부는 대안 셋 — Garage(v2.3.0, 복제 전용 설계), SeaweedFS(주 단위 릴리스, 창시자 집중), Ceph RGW(Tentacle 20.2.0, 운영 무게) — 의 2026년 7월 기준 실제 상태와, 지금 MinIO를 쓰고 있다면 남은 선택지 정리입니다.
  • Published on
    2025년 8월 20일 OPA 창시자들과 Styra 팀원 다수가 Apple에 합류한다는 공지가 나왔고, 커뮤니티에는 "Apple이 OPA를 인수했다"는 소문이 돌았습니다. 1차 소스로 확인하면 실체는 다릅니다 — 회사나 자산을 인수했다는 발표는 어디에도 없고, 사람들이 이직했으며, OPA는 CNCF 졸업 프로젝트로 남았습니다. 이 글은 그 공지의 정확한 문구, 이후 11개월 동안 실제로 일어난 일 — 월간 릴리스 케이던스 유지, Regal과 OPA Control Plane의 이관 후 활동, EOPA의 기증 후 아카이브(2026-06-26), styra.com DNS 소멸, 그리고 오늘자 MAINTAINERS.md 기준 opa 영역 메인테이너 전원의 Apple 소속화 — 를 GitHub API와 원문 문서로 직접 검증해 정리합니다. 벤더 한 곳에 기대던 open core 도구의 사용자가 이 사건에서 무엇을 점검해야 하는지도 함께 다룹니다.
  • Published on
    OpenBao v2.0.0 GA(2024-07-17)로부터 정확히 2년이 지났고, 사흘 전에는 v2.6.0이 나왔습니다. 이 글은 "BUSL 배신" 대 "지속가능성" 같은 진영 논리를 걷어내고, 양쪽 프로젝트의 릴리스 노트·체인지로그·커밋만으로 포크가 실제로 어디서 갈라졌는지 확인합니다. OpenBao는 Vault Enterprise 전용이던 네임스페이스를 v2.3.1에서 오픈소스로 가져왔고, v2.6.0에서는 업스트림에 없는 네임스페이스 단위 암호학적 봉인까지 얹었습니다. 반대로 스토리지 백엔드·클라우드 시크릿 엔진·내장 seal은 공격적으로 들어내는 중이라, Vault에서의 이주가 드롭인이라는 기대는 위험합니다. Vault 쪽에서는 IBM 인수 완료(2025-02-27) 후 라이선서가 IBM으로 바뀌고 Vault 2.0(2026-04-14)이 나왔으며, CE는 최신 마이너에만 패치가 나오는 구조가 체인지로그에서 그대로 관찰됩니다. 어느 쪽을 고르든 근거는 감정이 아니라 이 문서들이어야 합니다.
  • Published on
    2026년 7월 13일 태그된 Nix 2.35.0의 첫 번째 하이라이트는 "Sources are copied to the store more lazily"입니다. 이 한 줄이 닫은 이슈 #3121은 2019년 10월 7일 Eelco Dolstra 본인이 열었고, 2026년 6월 9일에 닫혔습니다 — 2,437일. 흥미로운 건 정작 머지된 물건이 Dolstra의 lazy trees가 아니라는 점입니다. 그의 PR #6530은 3년을 열려 있다가 머지 없이 닫혔고, 후속인 #13225는 지금도 충돌 상태로 열려 있습니다. 대신 들어간 것은 Sergei Zimmerman의 #15711 — 제목이 "maybe 3rd time's the charm"이고, diff는 14개 파일에 +180/-37입니다(lazy trees v1은 56개 파일에 +1363/-364였습니다). 이 글은 그 사이에 무슨 일이 있었는지 — Determinate Nix가 같은 기능을 다운스트림에서 먼저 출시하고 5퍼센트에서 20퍼센트로 단계 롤아웃한 것, Lix가 아예 플레이크 기능 동결을 택한 것 — 을 정리하고, 무엇보다 이번 변경이 고치지 않은 것을 정직하게 짚습니다. 복사는 사라졌지만 트리 전체를 훑고 NAR 해시를 계산하는 일은 그대로이고, 릴리스 노트가 이걸 직접 "unavoidable"이라고 적었습니다.
  • Published on
    2026년 5월, Redis 8.8과 Valkey 9.1이 엿새 간격으로 나왔습니다. Redis 8.8에는 antirez가 직접 만든 새 코어 자료구조 Array가 들어갔습니다 — 인덱스 자체가 의미를 갖는 데이터(센서의 분 단위 슬롯, 예약 시스템의 칸 번호, 파일의 줄 번호)를 위한 희소 인덱스 컨테이너로, 명령어 18개와 슬라이스 기반 희소 인코딩, 서버 사이드 집계와 정규식 grep까지 포함합니다. server.h의 객체 타입 번호로 보면 스트림(5.0) 이후 처음 늘어난 코어 타입이고, 같은 시기 Valkey의 소스에는 이 타입이 없습니다 — 포크가 실제로 갈라진 지점입니다. 다만 GA 릴리스에 들어갔는데도 공식 문서는 여전히 preview라고 못 박고 있고, 리스트보다 메모리를 더 쓰며, 희소 스캔의 최악 복잡도는 인구수가 아니라 구간 폭에 비례합니다. 이 글은 Array가 정확히 무엇이고, 내부를 어떻게 만들었고, 벤더 벤치마크가 말하지 않는 것이 무엇이며, 언제 쓰지 말아야 하는지를 1차 출처만으로 정리합니다.
  • Published on
    GitHub을 떠나 Codeberg·Forgejo·자체 호스팅으로 옮겼다는 글이 부쩍 늘었습니다. Ghostty, Zig, Gentoo의 이탈, 잦은 장애, Microsoft의 CoreAI 편입, 2026년 4월 AI 학습 기본값 전환이 배경입니다. 이 글은 실제 1차 자료를 근거로 무엇이 사람들을 움직이는지, Codeberg와 Forgejo가 실제로 무엇을 주는지, 그리고 GitHub을 떠날 때 진짜로 잃는 것(네트워크 효과·CI·발견 가능성)이 무엇인지 균형 있게 정리합니다. GitHub 성토가 아니라 정직한 개발자 관점의 글입니다.
  • Published on
    HashiCorp 공동창업자 Mitchell Hashimoto가 성공한 창업자의 자리에서 다시 내려와, 터미널 에뮬레이터 Ghostty를 1.0도 안 된 언어 Zig로 만드는 이유를 최근 인터뷰를 근거로 정리한다. 그는 15년간 CLI를 만들고도 터미널이 어떻게 동작하는지 몰랐고, 무뎌진 감각을 다시 세우려 GPU와 데스크톱, Zig로 내려갔다고 말한다. Zig는 0.15에서 출력 인터페이스가 통째로 바뀔 만큼 아직 불안정하지만, 그는 그 파괴적 변경을 오히려 반긴다. 오픈소스 유지보수에 대해서는 유지보수자가 사용자에게 어떤 의무도 없다는 단호한 입장을 편다. 나는 그 원칙에 대체로 동의하면서도, 그렇게 말할 수 있는 위치 자체가 하나의 특권임을 함께 짚는다.
  • Published on
    Microsoft Research가 공개한 Flint는 에이전트를 시각화하는 언어가 아니라, AI 에이전트가 데이터로부터 보기 좋은 차트를 안정적으로 만들게 해주는 중간 언어입니다. 컴파일러가 스케일·축·색·레이아웃 같은 낮은 수준의 결정을 데이터와 시맨틱 타입으로부터 대신 유도하고, 하나의 명세를 Vega-Lite·ECharts·Chart.js로 컴파일합니다. 이 글은 Flint가 실제로 무엇이고 어떤 문제를 푸는지, 그리고 에이전트 전용 시각화 언어가 정말 필요한 발상인지 아니면 과잉설계인지 정직하게 따집니다.
  • Published on
    tts-bench는 개발자 5uck1ess가 만든 로컬 벤치마크로, 손에 있는 하드웨어에서 55개 TTS 모델을 비교한다. 평가를 세 렌즈로 나눈다. 속도(TTFA·RTF·메모리), 청취(모든 모델을 귀로 판단), 점수(UTMOS·WER·SIM)다. 가장 흥미로운 건 주관성에 대한 정직함이다. "가장 좋게 들리는" 단일 점수는 없다. 품질은 당신의 귀와 용도에 달렸기 때문이다. 이 글은 이 도구가 실제로 무엇을 재는지, 객관 지표가 어디서 돕고 어디서 오도하는지, 그리고 내 워크로드에 맞는 TTS를 어떻게 고를지 정리한다.
  • Published on
    AI 생성 코드가 급증하면서 코드리뷰가 개발 파이프라인의 최대 병목이 되었습니다. 사람 코드와 AI 코드의 결함 패턴 차이, 스펙 대조와 테스트 우선 검증 중심의 리뷰 전략 재설계, AI 1차 리뷰와 인간 최종 판단의 조합, OSS 메인테이너의 AI 기여 정책, 팀 정책 템플릿과 측정 지표까지 정리합니다.
  • Published on
    2018년 MongoDB의 SSPL 전환을 시작으로, 2021년 Elastic, 2023년 HashiCorp, 2024년 Redis가 차례로 Apache/MIT를 떠나 BSL·SSPL·RSALv2 같은 비-OSI 라이선스로 갔다. 그 결과 OpenSearch·Valkey·OpenTofu·OpenBao 같은 커뮤니티 포크가 줄지어 태어났고, 2024년 8월 Elastic은 AGPL로 돌아왔다. 이 글은 BSL 물결의 7년사를 정리하고, OSI 정의와 "source-available" 논쟁, AWS "strip-mining" 내러티브의 진위, Sustainable Use License / Fair Source 운동, 그리고 한국·일본 기업의 입장과 우리 회사가 라이선스를 바꾸거나 마이그레이션할 때 고려할 의사결정 프레임을 깊게 들여다본다.
  • Published on
    2026년 5월 기준 프로덕션 ML 파이프라인을 떠받치는 오픈소스 MLOps 스택을 끝까지 본다. 실험 추적(MLflow 3.0, W&B, Comet, Neptune.ai, Aim), 파이프라인 오케스트레이션(Kubeflow, Metaflow, Flyte, ZenML), 모델 레지스트리, 서빙(BentoML 1.4, Seldon Core 2, KServe, Triton, Ray Serve), 피처 스토어(Feast, Hopsworks, Featureform), 데이터 버저닝(DVC, lakeFS, Pachyderm), 모니터링(Evidently, Arize, WhyLabs), 그리고 LLMOps까지 한 글에서 깊이 정리한다.
  • Published on
    Google Workspace 월 18달러, Microsoft 365 E3 월 36달러. 직원 200명이면 연 5억 원. 데이터는 미국 클라우드에 산다. EU 정부와 한국 공공기관, 일본 자치체가 줄줄이 셀프호스트로 갈아타는 2026년의 풍경을, NextCloud Hub 10·ownCloud Infinite Scale·Seafile 12·Collabora Online·OnlyOffice 8·CryptPad·Etherpad·LibreOffice 25.2까지 — 진짜 운영 가능한 오픈소스 워크스페이스 스택을 한 권으로 정리한다.
  • Published on
    Unity·Unreal의 상속 중심 객체 모델은 30년간 산업을 지배했지만, 2026년의 모던 게임 엔진은 다른 방향을 본다. Entity-Component-System은 '데이터와 동작을 분리'하고 '캐시 친화적 메모리 배치'로 멀티코어 시대의 답을 찾는다. Bevy는 그 답을 Rust 위에서 만든다. 0.15+ 버전, 플러그인 아키텍처, wgpu 렌더링, BSN 신 포맷 제안, bevy_ui와 Avian 물리, '첫 게임 30분' 핸즈온, 다른 엔진과의 정직한 비교까지 — Year of Bevy는 아직인지, 이미 도착했는지 한 호흡으로 본다.
  • Published on
    오픈소스에 어떻게 기여하는가 - 첫 PR을 여는 법부터 메인테이너가 되기까지. 학습, 커리어, 네트워크라는 현실적 보상과 환상을 솔직하게 짚고, 프로젝트 선택, 코드 리뷰 생존법, 커뮤니케이션 에티켓, AI 시대의 책임 있는 기여까지 실전 중심으로 다룬다.
  • Published on
    MIT·Apache 2.0가 여전히 90%를 차지하는 세계에서, 2018년 MongoDB가 SSPL을 들고 나오면서 시작된 '반란'은 2026년 어디까지 왔는가. Elastic은 AGPL로 돌아왔고, Redis도 SSPL을 거쳐 AGPL로 회귀했으며, HashiCorp는 BSL로 갔다가 OpenTofu 포크에 추월당했다. Sentry는 FSL을 발명했고, FUTO는 '소스 퍼스트'를 자칭한다. 이 글은 이 8년의 라이선스 반란기를 — 왜 시작되었고, 누가 무엇을 잃었으며, 2026년 스타트업이 라이선스를 고를 때 무엇을 봐야 하는지 — 한 호흡으로 정리한다.
  • Published on
    오픈소스 메인테이너가 실제로 돈을 받는 9가지 채널 — GitHub Sponsors, Polar.sh, Open Collective, Tidelift, Patreon, Ko-fi, Liberapay, Thanks.dev, Algora — 를 정직하게 비교한다. 컨버전이 실제로 나오는 채널은 어디인지, 기업의 Open Source Pledge와 VC 백 오픈소스 회사는 어떻게 다른지, '기업 돈 받아도 되는가' 논쟁까지 메인테이너 시점에서 깊이 다룬다.
  • Published on
    2026년 GitHub에서 폭발적으로 성장한 오픈소스 프로젝트들을 실무자 시선으로 정리한다. OpenClaw, n8n, Langflow/Dify/Flowise, Ollama가 무엇이고 왜 뜨는지, 언제 써야 하고 어떤 리스크가 있는지, 그리고 뜨거운 프로젝트를 도입 전에 검증하는 방법까지 다룬다.
  • Published on
    2020년대 초반엔 모든 게 클라우드로 갔다. 그런데 2025-2026년이 되니 다시 자기 집 책상 밑으로 컴퓨터를 끌고 들어오는 사람이 늘었다. Tailscale이 WireGuard 메시 VPN을 무료로 풀어준 순간 NAT 뚫기 지옥이 사라졌고, Coolify 4가 Heroku/Vercel 같은 PaaS 경험을 Docker 한 호스트에 얹어주고, Dokku는 여전히 한 줄 push로 앱을 띄우고, Immich가 Google Photos를 갈아치우고, Vaultwarden이 Bitwarden 서버 비용을 0으로 만들고, Pi-hole이 가정의 DNS를 깨끗하게 만든다. 이 글은 2026년의 셀프호스팅 스택을 한 호흡으로 — 메시 네트워킹·앱 호스팅 PaaS·신원·콘텐츠·모니터링·하드웨어·위협 모델까지 — 정리한다.
  • Published on
    시니어·스태프 엔지니어가 더 크게 성장하지 못하는 진짜 이유는 기술력 부족이 아니라 영향력 설계의 부재다. 기술 글쓰기 2.0, 컨퍼런스 발표, 오픈소스 메인테이너 경험, 개인 브랜드, 멘토/멘티 네트워크까지 2025-2026년 실전 플레이북을 500줄로 정리한다.
  • Published on
    첫 PR부터 메인테이너가 되는 실전 경로. GitHub Sponsors, Open Collective, Tidelift 수입 모델. Faker.js, colors.js, XZ 백도어 사건이 남긴 교훈. 라이선스(MIT/Apache/GPL/AGPL/MPL/Elastic) 선택 완전 가이드. Rust/Kubernetes/Node.js 거버넌스 비교. OSS에서 스타트업으로(MongoDB, Elastic, HashiCorp, Supabase). 한국 OSS 씬 현실과 글로벌 기여법, 번아웃 예방까지.
  • Published on
    2025년 가장 뜨거운 IT 트렌드! AI Agent/MCP 혁명, Rust의 부상, WebAssembly 2.0, Edge Computing, Local-first 소프트웨어, 오픈소스 라이선스 논쟁, 개발자 도구 혁신, 스타트업 동향, 빅테크 전략 — 해커뉴스 핫토픽 분석.
  • Published on
    Tencent HunyuanVideo(13B)와 Lightricks LTX-2(19B)의 아키텍처, 학습 방법론, 성능 벤치마크를 심층 분석하고, Wan 2.1/CogVideoX/Mochi 등 오픈소스 비디오 생성 모델 생태계 전체를 비교하며 실전 활용 가이드를 제공한다.