CLI 도구를 쓰다 보면 인증 토큰을 어디에 둘지가 늘 고민입니다. GitHub CLI는 GH_TOKEN, Cloudflare Wrangler는 CLOUDFLARE_API_TOKEN 같은 환경 변수를 지원하는데요. 편하다고 셸 설정 파일이나 .env 파일에 토큰을 넣어두면 어느 순간 평문 시크릿이 로컬 디스크 여기저기에 흩어집니다. 1Password에는 이런 문제를 줄여주는 Shell Plugins 기능이 있습니다. CLI가 인증 정보를 필요로 할 때 1Password가 토큰을 꺼내 환경 변수로 주입하고, 사용자는 지문이나 Appl
GitHub Actions로 배포나 테스트를 자동화하다 보면 API 키, 데이터베이스 비밀번호, 배포 토큰 같은 시크릿을 다루게 됩니다. 처음에는 GitHub Secrets에 하나씩 넣어두면 충분해 보이는데요. 프로젝트가 늘어나고, 시크릿을 여러 저장소에서 공유하고, 키를 주기적으로 교체해야 하는 순간부터 관리가 조금씩 복잡해집니다. 이럴 때 1Password를 시크릿의 원천 저장소로 두고, GitHub Actions에서는 실행 시점에 필요한 값만 읽어오게 만들 수 있습니다. GitHub에는 1Password에 접근하기 위한 서비스
GitHub Actions는 무료로 시작할 수 있고 워크플로우 한두 줄이면 배포까지 굴러가니 정말 편하죠. 그런데 편한 만큼 위험도 가까이에 있는데요. 워크플로우 한 줄을 잘못 쓰면 저장소의 모든 비밀이 외부로 흘러나가거나, 누군가의 PR 제목이 곧바로 러너에서 셸 명령으로 실행되는 일도 일어납니다. 실제로 PR 제목에 백틱과 셸 명령을 끼워 넣어 러너의 환경 변수와 토큰을 탈취한 사례가 종종 보고되고 있고, 인기 액션의 메인 브랜치가 손상되어 수많은 저장소에서 비밀이 유출되는 사고도 잊을 만하면 한 번씩 터집니다. 다행히 깃허브가
좋아 보이는 에이전트 스킬을 동료 깃허브 저장소에서 발견해서 따라 써보고 싶은데, 막상 적용하려고 하면 막막할 때가 있죠. 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
오픈소스를 운영하다 보면 스타가 늘거나 이슈가 쌓이는 일에는 어느새 익숙해지는데요. 그러던 어느 날 저장소 Security and quality 탭에 처음 보는 빨간 알림이 뜨고 "당신의 패키지에서 보안 취약점을 발견했습니다"라는 제보가 들어오면 이야기가 달라집니다. 머릿속이 하얗게 변하면서 "이걸 이슈로 답해야 하나? 일단 코드부터 고쳐서 푸시할까?" 하는 생각이 먼저 떠오르죠. 😅 이건 결코 남의 일이 아닌데요. 2021년 전 세계 서버를 떨게 한 Log4j의 Log4Shell 같은 대형 사건도 있었지만, 멀리 갈 것도 없이
지난 포스팅에서는 저장소의 특정 브랜치를 배포 디렉토리로 지정하여 아주 쉽고 빠르게 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 사용 방법에 대해서 알아보겠습니다. 터미