태그: #open-source

← 전체 글

• 첫 커널 패치 보내기 — 코드보다 절차가 관문인 이유

  커널에 첨 기여할 때 막히는 곳은 대개 코드가 아니라 절차입니다. 첫 패치가 반려되는 이유의 상당수는 로직이 아니라 형식이고, 그 형식은 전부 커널 트리 안에 문서로 들어 있습니다. 이 글은 scripts/checkpatch.pl과 scripts/getmaintainer.pl이 각각 무엇을 답해주는지, Signed-off-by가 왜 필수이며 무엇을 증명하는지, 커밋 메시지가 왜 75열이고 -

  2026-08-19 · 12 분 읽기 #linux#kernel#patch#git-send-email#checkpatch

• 커널 공부는 어디서 시작하는가 — 4,300만 줄 앞에서 길을 잃지 않는 법

  리눅스 커널을 공부하겠다고 마음먹은 사람이 가장 먼저 부딪히는 것은 개념이 아니라 규모입니다. 실제로 트리를 받아 세어 본 숫자로 커널이라는 코드베이스가 어떤 물건인지 먼저 보여 주고, 그중 몇 퍼센트를 평생 열어 볼 일이 없는지 정직하게 짚습니다. 그다음 현실적인 진입 경로를 읽기·관측·기여 세 갈래로 나눠 각각이 누구에게 맞는지, 왜 처음부터 순서대로 읽겠다는 계획이 거의 항상 실패하는지

  2026-08-19 · 30 분 읽기 #linux#kernel#kernel-source#learning#c

• 회사 밖 증거 — 무엇이 포트폴리오로 작동하고 무엇이 시간을 먹는가

  사내 성과의 약점은 검증할 수 없다는 것입니다. 비공개이고, 팀 단위이고, 남의 말로만 전달됩니다. 회사 밖 산출물은 링크 하나로 확인되지만 사내 경력을 대신하지는 않습니다. 무엇이 포트폴리오로 작동하고 무엇이 시간만 먹는지, 완결된 하나가 미완성 열 개보다 강한 이유, 공개 글쓰기가 아무도 읽지 않아도 회수되는 효용과 그 한계를 정리했습니다. 오픈소스 기여의 현실적인 진입로와 이력서에서 실

  2026-08-15 · 11 분 읽기 #career#side-project#portfolio#open-source#writing

• DeepSeek Harness의 플러그인 커널 구조 — 되감을 수 있는 에이전트는 무엇이 다른가

  DeepSeek이 공개한 오픈소스 코딩 에이전트 Harness는 모델도 도구도 UI도 전부 플러그인으로 만든 구조입니다. 그런데 실제로 흥미로운 부분은 플러그인이라는 단어가 아니라 두 가지 설계 결정입니다. 하나는 모든 실행을 추가 전용 이벤트 로그로 남겨 재개·분기·재생을 같은 스트림 위에서 처리한다는 것이고, 다른 하나는 플러그인 해제 시 부수 효과를 되돌리도록 강제한다는 것입니다. 이

  2026-08-14 · 15 분 읽기 #ai-agent#architecture#plugin-system#observability#open-source

• 지금 주목받는 오픈소스 (6) 스타 수가 말해 주지 않는 것

  스타 수는 인기 지표이지 위험 지표가 아닙니다. 오픈소스를 프로덕션에 들이기 전에 실제로 확인해야 하는 신호를 정리합니다. 최근 커밋과 릴리스 주기, 이슈 응답, 기여자 분포와 버스 팩터를 GitHub API로 직접 세는 방법, 라이선스가 자동 분류되지 않을 때 LICENSE 파일을 직접 읽어야 하는 이유, 그리고 도입 전 체크리스트를 담았습니다. 시리즈에서 실제로 확인한 사례를 근거로 삼았

  2026-08-12 · 10 분 읽기 #open-source#governance#supply-chain#risk#devops

• 지금 주목받는 오픈소스 (1) AI 에이전트와 LLM 도구

  LLM 애플리케이션 스택은 추론 서버, 오케스트레이션, 게이트웨이, 에이전트, RAG로 층이 갈라졌습니다. 각 층에서 실제로 쓰이는 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 프로젝트마다 무엇을 대체하는지, 성숙도가 어느 정도인지, 어떤 상황에서 쓰면 안 되는지를 함께 정리했고, 저장소 경로와 라이선스, 스타 수, 최근 푸시 날짜는 2026년 8월 12일 GitHub에서

  2026-08-12 · 10 분 읽기 #open-source#llm#ai-agent#ai-platform#rag

• 컨테이너 인프라의 세대교체 — 자리를 내준 11개 프로젝트가 남긴 것

  한때 컨테이너 인프라의 기본 구성이었다가 지금은 다른 것으로 대체된 프로젝트 11개를 공식 공지와 저장소 보관 상태만 근거로 정리합니다. rkt, dockershim, Classic Swarm, Docker Machine, Compose V1, Heapster, Apache Mesos, PodSecurityPolicy, CoreOS Container Linux, ingress-nginx, 그

  2026-08-12 · 19 분 읽기 #open-source#kubernetes#container#docker#infrastructure

• 지금 주목받는 오픈소스 (3) 인프라와 데이터베이스

  데이터베이스와 인프라 영역은 라이선스 변경과 포크가 판을 다시 짠 분야입니다. 분석 엔진, 임베디드 데이터베이스, 포스트그레스 확장, 쿠버네티스 오퍼레이터, IaC까지 실제로 자리를 잡은 오픈소스 11개를 스타 순위가 아니라 해결하는 문제별로 묶어 소개합니다. 무엇을 대체하는지, 어느 정도 성숙했는지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#database#infrastructure#postgresql#kubernetes

• 지금 주목받는 오픈소스 (5) 데이터와 ML 파이프라인

  데이터 파이프라인은 스케줄러 하나로 해결되지 않습니다. 적재, 변환, 오케스트레이션, 실행 엔진, 모델 수명 주기, 검색 저장소가 각각 다른 도구의 영역이 되었습니다. 이 층들에서 실제로 쓰이는 오픈소스 11개를 스타 순위가 아니라 담당 구간별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수, 최근 푸시는

  2026-08-12 · 9 분 읽기 #open-source#data-engineering#mlops#python#rust

• 언어와 런타임의 세대교체 — 공식 EOL 공지로 읽는 11개 프로젝트

  공식 종료 공지가 남아 있는 언어와 프레임워크, 런타임 11개를 정리합니다. Python 2, AngularJS, Vue 2, Nashorn, 자바 애플릿과 웹 스타트, Mono, Xamarin, PhoneGap, Atom, io.js, jQuery Mobile을 각각 무엇이었나, 왜 그때 옳았나, 무엇이 바뀌었나, 무엇이 그 자리에 왔나, 무엇을 남겼나, 지금도 쓰는 게 맞는 경우로 나눠

  2026-08-12 · 20 분 읽기 #open-source#javascript#java#python#framework

• 기본값에서 내려온 빌드 도구들 — 프론트엔드 툴체인 10개가 자리를 내준 이유

  한때 프론트엔드 프로젝트의 기본값이었다가 지금은 새 프로젝트에서 잘 고르지 않게 된 도구 10개를, 공식 폐기 공지와 저장소 보관 상태 같은 확인 가능한 근거만으로 정리합니다. Create React App, Bower, TSLint, Karma, Protractor, PhantomJS, LibSass와 node-sass, Moment.js, Rome, Grunt를 각각 무엇이었나, 왜 그때

  2026-08-12 · 16 분 읽기 #open-source#frontend#build-tools#deprecation#javascript

• 지금 주목받는 오픈소스 (4) 관측 가능성과 보안

  관측 데이터는 양이 곧 비용이고, 보안 도구는 파이프라인에 들어가지 못하면 쓰이지 않습니다. 계측 표준, 저장 엔진, eBPF 기반 런타임 감시, 공급망 검증까지 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 담당하는 층별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었습니다. 저장소 경로와 라이선스, 스타 수, 최근 푸시는 202

  2026-08-12 · 9 분 읽기 #open-source#observability#security#opentelemetry#ebpf

• 지금 주목받는 오픈소스 (2) 빌드·에디터·CLI·터미널

  패키지 설치, 린트, 번들링처럼 하루에 수십 번 반복되는 작업이 네이티브 언어로 다시 쓰이면서 대기 시간이 초 단위에서 밀리초 단위로 내려갔습니다. 빌드 도구, 에디터, 터미널, CLI 영역에서 실제로 자리를 잡은 오픈소스 12개를 스타 순위가 아니라 역할별로 묶어 소개합니다. 무엇을 대체하는지, 성숙도가 어느 정도인지, 언제 쓰면 안 되는지를 함께 적었고, 저장소 경로와 라이선스, 스타 수

  2026-08-12 · 9 분 읽기 #open-source#developer-tools#cli#rust#performance

• 무엇이 기술을 교체시키는가 — 우리 스택이 그 궤적 위에 있는지 점검하는 법

  자리를 내준 오픈소스 시리즈의 마지막 편입니다. 앞선 세 편에서 다룬 30여 개 프로젝트를 가로질러, 기술을 교체시키는 힘이 무엇인지 다섯 가지로 정리합니다. 플랫폼 흡수, 운영 부담, 유지보수 인력, 라이선스 변경, 문제 정의의 이동. 특히 라이선스 변경은 MongoDB와 Elastic, HashiCorp, Redis 사례를 어디에서 어디로 바뀌었는지 사실만으로 표에 정리하고, 그 결과 생

  2026-08-12 · 14 분 읽기 #open-source#architecture#license#migration#governance

• 데이터 저장소와 큐의 세대교체 — 라이선스, 포크, 그리고 Attic으로 간 프로젝트들

  데이터 계층에서 자리를 내주었거나 배포 조건이 바뀐 프로젝트 10개를 공식 발표문과 Apache Attic 기록만 근거로 정리합니다. Redis와 Elasticsearch, MongoDB의 라이선스 변경과 그로 인해 생긴 Valkey, OpenSearch 포크를 사실만으로 다루고, Kafka에서 ZooKeeper가 빠진 과정, Apache Attic으로 이관된 Sqoop과 Oozie, Gir

  2026-08-12 · 18 분 읽기 #open-source#database#kafka#redis#elasticsearch

• 버스 팩터는 아는 사람의 수가 아니라 결정할 수 있는 사람의 수다

  Nixpkgs 코어 팀이 10개월 만에 해산했습니다. 기여자가 수천 명인 저장소에서 위임된 의사결정 권한을 가진 사람은 두 명이었고, 그 두 명이 물러나자 해당 관할은 직접적인 주인이 없는 상태가 되었습니다. 이 사건을 근거로 의존성 위험을 평가할 때 스타 수와 커밋 수가 아니라 승인 권한을 가진 사람의 수, 위임 구조의 실효성, 에스컬레이션 경로를 봐야 하는 이유를 정리하고, GitHub

  2026-08-09 · 16 분 읽기 #devops#open-source#governance#nix#supply-chain

• 같은 회사 두 프로젝트가 AI 기여에 정반대 결론을 낸 이유 ♪ 들을 수 있어요

  OpenJDK는 2026년 4월에 생성형 AI로 만든 기여를 전면 금지했고, 같은 오라클 산하의 GraalVM은 같은 시기에 AI 코딩 어시스턴트 사용을 명시적으로 허용했습니다. 두 프로젝트는 같은 기여자 협약을 씁니다. 이 글은 세 문서를 나란히 놓고 읽습니다. OpenJDK 원문, GraalVM의 정책 파일, 그리고 둘 다 참고한 리눅스 커널 문서입니다. 결론은 이 차이가 AI에 대한 태

  2026-08-09 · 14 분 읽기 #culture#open-source#ai#policy#code-review

• GCC의 AI 정책과 오픈소스의 선택 — 15줄이라는 경계선은 무엇을 지키려는 것인가

  2026년 7월 29일 GCC 운영위원회가 AI 정책 작업 그룹의 권고안을 받아들였습니다. 핵심은 법적으로 유의미한 기여에 LLM 생성 콘텐츠가 포함되거나 그로부터 파생된 경우 받지 않는다는 것이고, 그 기준선은 GNU 유지보수자 지침의 약 15줄입니다. 다만 테스트 케이스는 예외이고, 연구·분석·버그 발견·패치 리뷰에 LLM을 쓰는 것 자체는 막지 않으며, AI 보조 작업에는 Assiste

  2026-07-31 · 23 분 읽기 #ai#open-source#gcc#licensing#governance

• 오픈소스 거버넌스가 무너질 때 — 루비 센트럴 사태와 세 개의 축

  2026년 7월 30일 André Arko가 "Ruby Central의 파괴적 유산"을 발표하면서, 2025년 9월에 시작된 RubyGems 저장소 접근 권한 분쟁이 열 달 만에 다시 표면으로 올라왔습니다. 이 글은 양쪽의 1차 진술을 나란히 놓고 확인 가능한 타임라인을 정리한 뒤, 왜 같은 형태의 위기가 core-js, event-stream, xz-utils, Nix, Redis, Ter

  2026-07-31 · 28 분 읽기 #open-source#governance#rubygems#supply-chain#licensing

• OPA는 지금 누가 유지하는가 — Styra 팀 Apple 합류, 그 후 11개월의 검증 가능한 기록

  2025년 8월 20일 OPA 창시자들과 Styra 팀원 다수가 Apple에 합류한다는 공지가 나왔고, 커뮤니티에는 "Apple이 OPA를 인수했다"는 소문이 돌았습니다. 1차 소스로 확인하면 실체는 다릅니다 — 회사나 자산을 인수했다는 발표는 어디에도 없고, 사람들이 이직했으며, OPA는 CNCF 졸업 프로젝트로 남았습니다. 이 글은 그 공지의 정확한 문구, 이후 11개월 동안 실제로 일어

  2026-07-17 · 21 분 읽기 #security#opa#authorization#open-source