npm에서 라이브러리를 하나 고를 때 무엇을 보시나요? 저는 스타 수만 보고 정하지는 않습니다. 저장소에 들어가서 이슈에 답이 잘 달리는지, 릴리스가 꾸준한지, 기여자가 몇 명이나 되는지를 훑어보죠. 그런데 그렇게 살펴봐도 손에 남는 건 "괜찮아 보인다"는 인상뿐입니다. 왜 이걸 골랐냐고 누가 물으면 딱 떨어지는 근거를 대기가 어렵고, node_modules에 딸려 들어온 수백 개의 간접 의존성을 하나하나 같은 눈으로 볼 수도 없고요. 눈으로 하는 판단은 저 혼자 쓰고 끝나는 데다, 개수가 늘어나면 금방 감당이 안 됩니다. 게다가
맥으로 개발을 하다 보면 디스크가 슬금슬금 차오릅니다. 저장 공간 경고가 뜰 때쯤 확인해보면 대개 이런 상태예요. 460GB짜리 디스크에서 남은 공간이 24GB 남짓입니다. 문제는 무엇을 지워야 할지 모르겠다는 거죠. 사진이나 영상을 지우자니 아깝고, ~/Library 안쪽은 열어봐도 알 수 없는 이름의 폴더뿐입니다. 😅 맥 청소 앱은 예전부터 많았습니다. 그런데 이 바닥은 유독 미심쩍은 광고와 연 3만~5만 원짜리 구독으로 얼룩져 있어서 선뜻 손이 가지 않죠. "잡동사니 12GB를 발견했습니다" 같은 문구는 봤어도, 정확히 무슨
오픈소스 프로젝트를 운영하다 보면 서버비, 도메인 비용, 컨퍼런스 참가비 같은 현실적인 지출이 생기기 마련입니다. GitHub Sponsors처럼 개인 개발자에게 후원하는 방법도 있지만, 프로젝트 자체의 재정을 관리하려면 조금 다른 접근이 필요하죠. 후원금이 얼마나 들어왔고 어디에 썼는지를 투명하게 공개할 수 있다면 후원자도 안심하고 기여할 수 있을 텐데요. Open Collective가 바로 이 문제를 해결하기 위해 만들어진 플랫폼이에요. 이번 글에서는 Open Collective가 어떤 플랫폼인지, 어떻게 활용할 수 있는지 하나
AI 코딩 에이전트 시장이 점점 뜨거워지고 있죠. Claude Code나 OpenCode 같은 도구가 이미 많은 개발자의 워크플로우에 자리 잡았는데요, 오늘은 조금 다른 접근 방식을 취하는 도구를 하나 소개해드리겠습니다. 바로 Block(구 Square)이 만든 오픈소스 AI 코딩 에이전트, Goose입니다. Goose는 2025년 1월에 처음 공개된 이후 빠르게 성장해서, 지금은 GitHub 스타 27,000개 이상, 기여자 400명 이상의 대규모 오픈소스 프로젝트가 되었습니다. 2025년 12월에는 Linux Foundation
오픈소스 프로젝트에 후원해주시는 분들이 계신다면 README에서 제대로 소개해드리고 싶을 텐데요. GitHub Sponsors나 Open Collective 같은 플랫폼에서 후원자 목록을 가져와 직접 이미지를 만들려면 꽤 손이 많이 갑니다. 이런 작업을 한 방에 해결해주는 도구가 바로 SponsorKit이에요. 이전에 All Contributors로 오픈소스 기여자를 인정하는 방법을 알아봤는데요, 이번에는 후원자를 시각적으로 멋지게 표현하는 방법을 살펴보겠습니다. SponsorKit이란? SponsorKit은 여러 후원 플랫폼에서
AI 코딩 도구가 개발자의 일상에 깊숙이 자리 잡은 지금, 많은 분들이 Claude Code, GitHub Copilot, Cursor 같은 도구들을 사용하고 계실 겁니다. 그런데 이런 도구들은 대부분 유료이고 소스 코드도 공개되어 있지 않죠. 그래서 오늘은 코드가 투명하게 공개되어 있고 다양한 모델 공급자(provider)를 지원하는 오픈소스 AI 코딩 에이전트, OpenCode를 소개해 드리겠습니다. 기본 사용법과 권한 설정뿐 아니라 2026년 7월 공개된 Desktop v2의 변화까지 함께 살펴볼게요. OpenCode란? Op
오픈소스 프로젝트를 만들고 유지하는 건 생각보다 손이 많이 갑니다. 주말마다 이슈를 처리하고, 새벽에 PR을 리뷰하고, 버전 업데이트에 맞춰 코드를 고치죠. 이렇게 매일 시간을 쏟는 개발자에게 "고마워요"라는 말 대신 커피 한 잔이라도 사줄 수 있다면 어떨까요? GitHub Sponsors는 바로 이 목적으로 만들어진 GitHub의 공식 후원 프로그램이에요. 오픈소스에 기여하는 개발자나 조직이 GitHub 안에서 바로 후원을 받을 수 있게 해주죠. 이번 글에서는 후원을 받는 쪽, 후원을 하는 쪽 양쪽 관점에서 GitHub Spons
혹시 오픈 소스 프로젝트를 시작하시면서 어떤 라이선스를 선택할지 몰라서 고민해본 적이 있으신가요? 깃허브에서는 코드 저장소를 생성할 때 항상 어떤 라이선스를 사용하지 물어보죠. 이번 포스팅에서는 MIT, Apache, GPL 등 널리 사용되는 오픈 소스 라이선스를 소개해드리고, 각 라이선스를 언제 선택하면 좋은지 알아보겠습니다. 오픈 소스 라이선스란? 오픈 소스 라이선스는 오픈 소스 소프트웨어가 어떻게 사용될 수 있는지 명시해주는 문서입니다. 개발자는 오픈 소스 라이선스를 통해서 소프트웨어의 소스 코드를 사용, 수정, 배포할 수 있
오픈소스를 운영하다 보면 스타가 늘거나 이슈가 쌓이는 일에는 어느새 익숙해지는데요. 그러던 어느 날 저장소 Security and quality 탭에 처음 보는 빨간 알림이 뜨고 "당신의 패키지에서 보안 취약점을 발견했습니다"라는 제보가 들어오면 이야기가 달라집니다. 머릿속이 하얗게 변하면서 "이걸 이슈로 답해야 하나? 일단 코드부터 고쳐서 푸시할까?" 하는 생각이 먼저 떠오르죠. 😅 이건 결코 남의 일이 아닌데요. 2021년 전 세계 서버를 떨게 한 Log4j의 Log4Shell 같은 대형 사건도 있었지만, 멀리 갈 것도 없이
오픈소스 프로젝트를 운영하다 보면 코드 기여자에게만 공을 돌리기 쉽습니다. 하지만 문서 작성, 번역, 버그 리포트, 디자인, 아이디어 제안 등 다양한 방식으로 프로젝트에 기여하는 분들도 많죠. 이런 다양한 기여자들을 빠짐없이 인정해주고 싶은데, 어떻게 해야 할까요? 🤔 이번 포스팅에서는 All Contributors라는 도구를 소개해드리려고 합니다. All Contributors는 코드 기여뿐만 아니라 모든 형태의 기여를 인정하자는 철학을 담은 명세(specification)이자, 이를 자동화해주는 봇과 CLI 도구입니다. All
주변에 보면 경력과 무방하게 오픈 소스 기여에 관심이 있는 개발자 분들이 참 많은 것 같아요. 오픈 소스에 기여한 이력은 인터넷에 공개되어 있기 때문에 개인의 인지도를 높이는 데 도움이 되고, 오픈 소스 경험이 있는 개발자를 우대하거나 적극적으로 채용하는 기업들도 있으니까요. 뿐만 아니라, 오픈 소스 커뮤니티에서 활동하고 있는 전 세계의 개발자들과 협업하면서 글로벌 네트워크를 넓힐 수 있다는 점도 큰 매력인 것 같습니다. 무엇보다 자신이 작성한 코드가 무료로 많은 사람들에게 해택을 준다는 것은 개발자로서 정말로 보람된 경험이죠. 그