좋아 보이는 에이전트 스킬을 동료 깃허브 저장소에서 발견해서 따라 써보고 싶은데, 막상 적용하려고 하면 막막할 때가 있죠. SKILL.md 파일을 다운로드해서 어디다 저장할지 검색하고, 의존하는 스크립트까지 같이 챙겨오고, 며칠 뒤에 원본이 업데이트되면 또 수동으로 덮어쓰고... 😅 게다가 직접 만든 스킬을 동료에게 공유할 때도 비슷한 문제가 생깁니다. 스펙에 맞게 잘 작성했는지 확인하기도 쉽지 않고, 검색이 잘 되도록 메타데이터를 챙기는 일도 신경 쓸 게 한두 가지가 아니거든요. GitHub이 이 문제를 해결하려고 GitHub
소스 코드 저장소에 API 키나 토큰이 실수로 들어간 적, 한 번쯤 있으시죠? 당장 git rm으로 지우고 강제 푸시를 해도 깃 히스토리에는 흔적이 남고, 공개 저장소라면 봇이 몇 분 안에 그 키를 긁어가 버립니다. 악의적인 사용자가 발견하기 전에 깃허브가 먼저 찾아서 알려주면 좋겠다는 생각이 절로 들죠. 이번 글에서는 깃허브가 무료로 제공하는 Secret Scanning 기능이 어떻게 동작하고, 푸시 시점부터 사후 알림까지 어떤 방어선을 쌓아주는지 정리해 보겠습니다. Secret Scanning이 푸는 문제 비밀 정보가 저장소로
PR 하나에 파일 30개가 바뀌고 코드가 2,000줄 넘게 추가된 걸 리뷰해달라고 받아본 적 있으신가요? 😅 리뷰어 입장에서는 어디서부터 봐야 할지 막막하고, 작성자 입장에서는 피드백을 기다리는 시간이 길어지죠. "PR은 작게 만들어라"라는 원칙은 누구나 알고 있지만 실제로 지키기가 쉽지 않습니다. 큰 기능을 구현하다 보면 인증 레이어, API 엔드포인트, 프론트엔드 화면이 서로 물려 있어서 하나만 떼어내기 어렵거든요. 억지로 쪼개봤자 의존하는 브랜치끼리 rebase를 수동으로 맞추느라 시간을 허비하게 됩니다. 이 문제를 해결하기
오픈소스 프로젝트를 운영하다 보면 서버비, 도메인 비용, 컨퍼런스 참가비 같은 현실적인 지출이 생기기 마련입니다. GitHub Sponsors처럼 개인 개발자에게 후원하는 방법도 있지만, 프로젝트 자체의 재정을 관리하려면 조금 다른 접근이 필요하죠. 후원금이 얼마나 들어왔고 어디에 썼는지를 투명하게 공개할 수 있다면 후원자도 안심하고 기여할 수 있을 텐데요. Open Collective가 바로 이 문제를 해결하기 위해 만들어진 플랫폼이에요. 이번 글에서는 Open Collective가 어떤 플랫폼인지, 어떻게 활용할 수 있는지 하나
오픈소스 프로젝트에 후원해주시는 분들이 계신다면 README에서 제대로 소개해드리고 싶을 텐데요. GitHub Sponsors나 Open Collective 같은 플랫폼에서 후원자 목록을 가져와 직접 이미지를 만들려면 꽤 손이 많이 갑니다. 이런 작업을 한 방에 해결해주는 도구가 바로 SponsorKit이에요. 이전에 All Contributors로 오픈소스 기여자를 인정하는 방법을 알아봤는데요, 이번에는 후원자를 시각적으로 멋지게 표현하는 방법을 살펴보겠습니다. SponsorKit이란? SponsorKit은 여러 후원 플랫폼에서
Rust로 라이브러리를 만들어서 crates.io에 배포하고 있다면 릴리스할 때마다 반복해야 하는 작업이 꽤 많다는 걸 느끼셨을 거예요. Cargo.toml의 버전 올리고 체인지로그 정리하고 cargo publish 실행하고 git 태그 만들고 GitHub Release도 작성하고... 🤔 매번 수작업으로 하다 보면 빼먹는 단계가 생기기 마련이죠. release-plz는 이 과정을 통째로 자동화해주는 도구인데요. Conventional Commits 기반으로 버전을 알아서 올려주고, 체인지로그도 자동 생성하고, PR 하나 머지하면
GitHub에서 이슈를 만들고 PR을 열고 코드를 검색하는 일은 개발자의 일상이죠. 그런데 이런 반복 작업을 AI에게 시키면 어떨까요? MCP(Model Context Protocol)가 AI와 외부 시스템을 연결하는 표준으로 자리 잡으면서 GitHub도 공식 MCP 서버를 내놓았는데요. 설정해두면 VSCode나 Cursor의 AI 채팅에서 자연어로 요청하는 것만으로 GitHub의 이슈나 PR을 간편하게 다룰 수 있게 됩니다. 이번 글에서는 GitHub MCP 서버를 설치하고 실제로 활용하는 방법을 살펴볼게요. GitHub MCP
GitHub에서 이슈를 확인하려고 브라우저를 열고, PR을 만들려고 또 브라우저를 열고... 터미널에서 코딩하다가 브라우저와 터미널 사이를 왔다 갔다 하는 게 은근히 번거롭지 않으셨나요? GitHub REST API를 curl로 직접 호출하는 방법도 있지만 URL과 헤더를 매번 타이핑하는 건 솔직히 고통스럽죠. 그래서 GitHub이 만든 게 바로 gh라는 공식 CLI 도구입니다. 터미널을 떠나지 않고도 이슈부터 PR, 릴리스까지 다 처리할 수 있어요. 이번 글에서는 gh CLI의 설치부터 실무에서 자주 쓰는 핵심 명령어까지 살펴보겠
현대 소프트웨어 개발에서 의존성(Dependency)은 필수 불가결한 존재입니다. 직접 구현해야 하는 코드를 줄여 생산성을 높여주지만, 관리되지 않고 방치된 의존성은 보안 취약점이나 호환성 문제로 이어지기 쉽죠. 이번 글에서는 깃허브에서 제공하는 Dependabot을 통해 의존성 관리와 보안 업데이트를 어떻게 자동화할 수 있는지 알아보겠습니다. Dependabot이란? Dependabot은 깃허브에서 제공하는 보안 취약점 경보 및 의존성 업데이트 기능입니다. 초기에는 독립 서비스였지만, 2019년 GitHub에 인수된 후 현재는 깃
오픈소스 프로젝트를 만들고 유지하는 건 생각보다 손이 많이 갑니다. 주말마다 이슈를 처리하고, 새벽에 PR을 리뷰하고, 버전 업데이트에 맞춰 코드를 고치죠. 이렇게 매일 시간을 쏟는 개발자에게 "고마워요"라는 말 대신 커피 한 잔이라도 사줄 수 있다면 어떨까요? GitHub Sponsors는 바로 이 목적으로 만들어진 GitHub의 공식 후원 프로그램이에요. 오픈소스에 기여하는 개발자나 조직이 GitHub 안에서 바로 후원을 받을 수 있게 해주죠. 이번 글에서는 후원을 받는 쪽, 후원을 하는 쪽 양쪽 관점에서 GitHub Spons
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 GitHub Pages로 웹사이트를 호스팅할 수 있다고 배웠는데요. 하지만 요즘 웹 개발에서 HTML, CSS, JavaScript를 직접 작성하는 일은 드물죠? 대부분 React와 같은 프론트엔드 라이브러리와 Vite와 같은 빌드 도구를 사용하여 HTML, CSS, JavaScript를 생성해낼 것입니다. 이번 포스팅에서는 웹 프로젝트를 GitHub Actions를 사용하여 빌드하고, 빌드 결과물을 바로 GitHub Pages에 배포하는 방법에 대
GitHub Pages에 웹사이트를 배포하면 기본적으로 github.io 서브 도메인을 무료로 제공해주는데요. 대부분의 개인 프로젝트에서는 GitHub Pages의 기본 도메인을 사용해도 큰 지장이 없을 것입니다. 하지만 비즈니스를 위한 웹사이트를 호스팅할 때는 브랜딩이나 SEO(검색 엔진 최적화) 차원에서 커스텀 도메인을 원하게 되죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 배포한 웹사이트에 커스텀 도메인을 연결하는 방법을 알려드리겠습니다. 커스텀 도메인 구매 GitHub Pages에 커스텀 도메인을 연결
GitHub Pages는 깃허브에서 코드 저장소에 딸려오는 무료 호스팅 서비스입니다. GitHub Pages를 사용하면 정적 웹사이트, 블로그, 포트폴리오, 프로젝트 문서 등을 아주 손쉽게 웹에 배포할 수 있죠. 이번 포스팅에서는 간단한 실습을 통해서 GitHub Pages에 웹사이트를 배포하는 가장 기초적인 방법을 알려드리겠습니다. GitHub Pages란? GitHub Pages는 깃허브 저장소에 올려놓은 프로젝트를 최소한의 노력으로 웹에 호스팅해주는 서비스입니다. 깃허브에서 거의 초창기부터 무료로 제공하고 있는데 은근히 모르시
오픈소스 프로젝트를 운영하다 보면 코드 기여자에게만 공을 돌리기 쉽습니다. 하지만 문서 작성, 번역, 버그 리포트, 디자인, 아이디어 제안 등 다양한 방식으로 프로젝트에 기여하는 분들도 많죠. 이런 다양한 기여자들을 빠짐없이 인정해주고 싶은데, 어떻게 해야 할까요? 🤔 이번 포스팅에서는 All Contributors라는 도구를 소개해드리려고 합니다. All Contributors는 코드 기여뿐만 아니라 모든 형태의 기여를 인정하자는 철학을 담은 명세(specification)이자, 이를 자동화해주는 봇과 CLI 도구입니다. All
블로그를 운영하다 보면 독자와 소통하고 싶다는 생각이 들 때가 있습니다. 글에 대한 피드백을 받기도 하고 궁금한 점을 질문으로 남겨주시는 분도 계시죠. 때로는 본문보다 댓글에서 더 좋은 방법을 알게 되기도 하고요. 문제는 정적 블로그에 댓글 기능을 붙이려면 별도 서버나 데이터베이스가 필요하다는 겁니다. Disqus 같은 서비스를 쓸 수도 있지만 광고가 붙고 사용자 추적도 신경 쓰이고요. 이럴 때 쓸 만한 도구가 Giscus입니다. GitHub Discussions를 댓글 저장소로 쓰는 오픈소스 프로젝트인데요, 별도 서버 없이 댓글
깃허브(GitHub)는 개발자들이 소프트웨어 프로젝트를 관리하고 협업하는 데 필요한 다양한 기능을 제공하는 매우 인기있는 플랫폼인데요. 일상적인 개발을 할 때는 깃허브의 웹사이트를 통해서 대부분의 작업을 처리할 수 있지만 개발 과정을 자동화하거나 다른 개발 도구와 통합할 때는 프로그래밍적으로 접근해야 할 때가 있습니다. 이럴 때는 깃허브에서 제공하는 REST API를 사용하면 되는데요. 이번 포스팅에서는 터미널에서 curl로 깃허브의 REST API를 실제로 같이 호출해보면서 기본적인 API 사용 방법에 대해서 알아보겠습니다. 터미
새 프로젝트에 합류했는데 개발 환경 설정에만 하루 이상 걸린 적 있으신가요? Node.js 버전이 안 맞고, Python 패키지가 충돌하고, 데이터베이스 설치가 안 되고… 😅 이런 문제는 개발자라면 누구나 한 번쯤 겪어봤을 텐데요. Dev Container는 이런 골치 아픈 개발 환경 설정을 컨테이너 안에 통째로 담아서 해결합니다. 설정 파일 하나만 프로젝트에 넣어두면 팀원 누구나 동일한 환경에서 바로 작업을 시작할 수 있죠. 이번 글에서는 Dev Container가 뭔지, 어떻게 쓰는지 처음부터 차근차근 알아보겠습니다. Dev
GitHub Actions을 사용하다 보면 시간이 지남에 따라 워크플로우가 점점 복잡해지고, 그에 따라 중복되는 부분이 생기며 결국 워크플로우의 유지보수가 어려워지게 되는데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우를 재사용하여 이러한 중복 설정 문제를 해결해보도록 하겠습니다. 실습 워크플로우 생성 실습을 위해서 자바스크립트 프로젝트의 전형적인 워크플로우 파일을 하나 작성해보았습니다. main 브랜치로 새로운 커밋(commit)이 유입되면 애플리케이션을 빌드하여 배포하는 작업을 수행되도록 하겠습니다. 6개의 단계
많은 분들이 GitHub Actions을 사용하실 때 GitHub Marketplace에 공개된 액션을 사용하실텐데요. 만약에 필요한 액션을 찾지 못했거나 회사에 보안 상의 이유로 승인되지 않은 외부 액션을 사용할 수 없다면 어떻게 해야 할까요? 이번 글에서는 GitHub Actions에서 직접 액션을 만들어보고 워크플로우에서 사용하거나 GitHub Marketplace를 통해 공유하는 방법에 대해서 알아보겠습니다. 액션의 종류 GitHub Actions에서는 도커(Docker) 컨테이너 액션, 자바스크립트 액션, 복합(compos
GitHub Actions 워크플로우를 작성하다 보면 GitHub Pages에 배포하거나, PR에 댓글을 달거나, 이슈에 라벨을 붙이는 등 단순히 코드를 빌드하고 테스트하는 것 이상의 작업을 하게 되는 경우가 많죠? 이때 워크플로우가 GitHub API에 접근하려면 적절한 권한이 필요한데요. 이번 포스팅에서는 GitHub Actions에서 워크플로우의 권한을 제어하는 permissions 키워드에 대해 자세히 알아보겠습니다. GITHUB_TOKEN이란? GitHub Actions에서 워크플로우가 실행될 때마다 GitHub은 자동으로