Skip to content

Instantly share code, notes, and snippets.

@leedc0101

leedc0101/01-github-agentic-workflows.md

Created February 16, 2026 01:04
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save leedc0101/2ffa04b764ee0969ba1f3c6f9e5184cb to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save leedc0101/2ffa04b764ee0969ba1f3c6f9e5184cb to your computer and use it in GitHub Desktop.
Download ZIP
frontend-briefing-2026-02-16-KST
Raw
01-github-agentic-workflows.md

Automate repository tasks with GitHub Agentic Workflows

아침에 리포지토리를 열었는데, 이런 상태라면 마음이 편할 겁니다.

  • 이슈가 분류되고 라벨이 붙어 있다
  • CI 실패가 조사되어, 수정 제안이 붙어 있다
  • 최근 코드 변경에 맞춰 문서가 업데이트되어 있다
  • 테스트를 개선하는 PR 두 개가 리뷰를 기다리고 있다

이런 미래를 목표로 한 것이 GitHub Agentic Workflows입니다. GitHub Actions 위에서 돌아가는 “리포지토리 자동화”인데, 사람이 쓰는 마크다운으로 원하는 결과를 적고, 그걸 코딩 에이전트가 실행합니다. 개인 1개 저장소부터 엔터프라이즈/오픈소스 규모까지를 목표로 합니다.

GitHub Next는 “AI 코딩 에이전트 시대에, 강한 가드레일을 갖춘 리포지토리 자동화는 어떤 모습이어야 하나?”라는 질문에서 시작했고, 그 기반으로 GitHub Actions를 선택했습니다. 에이전트를 Actions 안으로 가져오면, 수많은 저장소에 확장 가능하면서도 ‘언제/어디에 쓸지’는 사용자가 통제할 수 있기 때문입니다.

현재 GitHub Agentic Workflows는 **기술 프리뷰(technical preview)**로 제공됩니다.

AI 리포지토리 자동화: 단순함을 통한 변화

개념은 간단합니다.

  1. 원하는 “결과”를 마크다운으로 적는다

  2. 그 파일을 저장소의 워크플로로 추가한다

  3. GitHub Actions에서 코딩 에이전트가 실행한다

에이전트 워크플로는 일반 Actions 워크플로처럼 실행되지만, 샌드박싱 / 권한 / 통제 / 리뷰를 위한 추가 가드레일이 붙습니다. 실행 시에는 설정에 따라 Copilot CLI, Claude Code, OpenAI Codex 같은 서로 다른 엔진을 사용할 수 있습니다.

전통적인 YAML 워크플로만으로는 어렵거나 거의 불가능했던 자동화 범주를 노립니다.

  • 지속적인 트리아지: 새 이슈를 요약하고 라벨링하고 담당자에게 라우팅
  • 지속적인 문서화: README/문서가 코드 변경과 함께 따라오게 유지
  • 지속적인 단순화(리팩터링): 반복적으로 개선점을 찾고 PR을 생성
  • 지속적인 테스트 개선: 커버리지를 보고 가치 있는 테스트 추가
  • 지속적인 품질 위생: CI 실패를 먼저 조사하고 타깃 수정 제안
  • 지속적인 리포팅: 저장소 상태/활동/추세 보고서 생성

이런 흐름을 GitHub Next는 Continuous AI(CI/CD처럼 SDLC에 AI를 상시 통합)로 부릅니다.

중요한 포인트는 “기존 CI/CD를 대체”가 아니라 “보완”입니다. 빌드/테스트/릴리스 파이프라인을 대체하지 않고, 결정론적 워크플로가 다루기 어려운 ‘반복적이지만 주관이 섞인 작업’을 다루는 쪽에 초점을 둡니다.

가드레일과 통제(Guardrails & Control)

안전/통제는 필수라는 전제로 설계합니다.

  • 기본 권한은 읽기 전용(read-only)
  • 쓰기 작업은 명시적 승인이 필요
  • “safe outputs(안전 출력)”로 허용된 GitHub 작업(예: PR 생성, 이슈 댓글 추가)만 수행
  • 샌드박싱 실행, 도구 허용목록(allowlist), 네트워크 격리 같은 방어층

즉, 에이전트를 “계속 돌려도” 위험을 관리할 수 있게 만드는 것이 목표입니다.

일반 YAML 워크플로 안에서 코딩 에이전트 CLI를 직접 실행하는 방식도 가능하지만, 그 경우 작업 대비 과도한 권한을 주기 쉬운 반면, Agentic Workflows는 기본 read-only와 safe outputs 기반으로 더 촘촘한 제약/리뷰 포인트를 제공한다고 설명합니다.

간단한 예: 매일 리포지토리 리포트

예시로, 유지관리자를 위한 일일 상태 보고서 워크플로를 소개합니다.

보통은 코딩 에이전트에게 “이런 워크플로를 만들어줘”라고 요청해서 마크다운을 만들고, 검증한 뒤 저장소에 넣는 흐름을 권장합니다.

워크플로를 추가하면 .github/workflows 아래에 보통 두 파일이 생깁니다.

  • daily-repo-status.md (사람이 읽는 에이전트 워크플로)
  • daily-repo-status.lock.yml (GitHub Actions가 실제 실행하는 락 파일)

daily-repo-status.md는 대략 이렇게 구성됩니다.

  • 프론트매터(YAML): 트리거, 권한, 허용 출력, 사용할 도구
  • 본문(Markdown): “무엇을, 어떤 형식으로, 어디까지” 할지 자연어로 설명

팀을 위한 실무 가이드

에이전트 워크플로를 잘 쓰려면, “프롬프트를 완벽하게”보다 “성공 기준을 명확히”가 더 중요하다고 말합니다.

  • 낮은 위험 출력(댓글/드래프트/리포트)부터 시작
  • 기능 개발보다 리팩터링/테스트/단순화 같은 목표 지향 개선부터 시작
  • 리포트는 형식/톤/링크/중단 조건까지 구체화
  • PR은 자동 머지하지 않고, 항상 사람이 리뷰/승인
  • 워크플로 마크다운도 코드처럼 리뷰하고, 작게 유지하고, 의도적으로 진화

또한 런타임에 코딩 에이전트를 쓰면 비용이 든다는 점(예: Copilot 기본 설정에서 실행당 프리미엄 요청이 발생할 수 있음)도 언급합니다.

함께 만들자

GitHub Agentic Workflows는 기술 프리뷰이며, GitHub/Microsoft Research/Azure Core Upstream 협업으로 진행된다고 안내합니다. 문서/아키텍처/퀵스타트/갤러리 링크와 커뮤니티 피드백 채널도 제공합니다.

Raw
02-eternal-september-maintainers.md

Welcome to the Eternal September of open source. Here’s what we plan to do for maintainers.

오픈소스 협업은 신뢰 위에서 돌아갑니다. 오랫동안 그 신뢰를(완벽하진 않지만) 지켜준 자연스러운 필터가 있었는데, 바로 마찰(friction) 입니다.

1993년 유즈넷(Usenet)에는 매년 9월이면 새 학기가 시작되며 학생들이 몰려왔고, 커뮤니티는 그들을 온보딩했습니다. 하지만 다이얼업 ISP가 대중화되면서 “9월 유입”이 끊이지 않았고, 결국 끝나지 않는 9월(Eternal September) 이라는 말이 생겼습니다.

지금 오픈소스도 비슷한 상황을 겪고 있습니다. 이번에는 “새 사용자”뿐 아니라 기여의 양(볼륨) 자체가 폭발하고 있습니다.

기여 비용이 내려갈 때

메일링 리스트 시대에는 오픈소스에 기여하려면 실제 노력이 필요했습니다.

  • 구독하고
  • 눈팅하면서 문화와 규칙을 이해하고
  • 패치를 올바른 형식으로 만들고
  • 왜 중요한지 설명해야 했습니다

이런 노력이 품질을 보장하진 않지만, ‘진짜로 관여한 사람’이 들어오게 만드는 필터 역할을 했습니다.

물론 장벽이 높아 많은 사람을 배제하기도 했고, 많은 프로젝트는 더 환영받는 커뮤니티를 만들기 위해 장벽을 낮추려 노력했습니다.

큰 변화는 Pull Request였습니다. GitHub에서 PR로 기여하고, “Good First Issue” 같은 라벨로 진입점을 만드는 방식은 기여 접근성을 크게 올렸고, 커뮤니티는 성장했습니다. 좋은 변화였습니다.

하지만 마찰은 균형입니다.

  • 너무 높으면 사람이 못 들어오고
  • 너무 낮으면 신뢰가 흔들립니다

지금은 PR을 몇 초 만에 만들 수 있습니다. 생성형 AI는 코드/이슈/보안 리포트를 대량으로 만들어낼 수 있게 했습니다. 만드는 비용은 내려갔지만, 리뷰 비용은 내려가지 않았습니다.

대부분의 기여자는 선의로 움직인다는 점도 강조합니다. 하지만 볼륨이 리뷰 능력보다 빨리 커지면, 선의의 기여라도 유지관리자를 압도할 수 있고, 그러면 신뢰가 흔들립니다.

노이즈의 ‘새로운 스케일’

“저품질 기여”나 “AI 슬롭”이 완전히 새 문제인 것처럼 보이지만, 유지관리자는 예전부터 노이즈를 다뤄왔습니다.

  • Linux 커널은 “웹 오브 트러스트” 철학, 패치 제출 가이드, DCO 같은 체계를 갖췄습니다.
  • Mozilla, GNOME은 트리아지 체계를 발전시켰습니다.
  • 생성형 AI 이전에도 자동 스캐너가 대량 리포트를 보내는 파도가 있었습니다.

유지관리자의 질문은 결국 이겁니다.

“당신은 정말 나를 돕는 건가, 아니면 당신 자신을 돕는 건가?”

도구(정적 분석기, LLM 등)가 리포트/수정을 쉽게 만들어준다고 해서, 그 기여가 프로젝트에 가치 있다는 뜻은 아닙니다. 만드는 쪽은 이득(크레딧/가시성/CVE 등)을 얻는데, 유지관리자는 검증/유지보수 부담을 떠안는 이득의 불균형이 생깁니다.

예시로,

  • curl은 AI 생성 보안 리포트가 폭증해 검증에 시간을 너무 많이 쓰게 되자 버그 바운티를 종료했습니다.
  • 일부 프로젝트는 초대 기반(사전 논의 후 기여) 모델로 이동합니다.
  • AI 생성 기여에 대한 명시적 규칙을 도입하는 프로젝트도 늘고 있습니다.

이건 불균형에 대한 합리적 반응이라는 설명입니다.

GitHub는 무엇을 하려 하나

GitHub는 유지관리자 지속가능성을 핵심으로 보고, “문 앞에 들어오는 것”을 관리할 수 있도록 돕는 책임이 있다고 말합니다.

즉시 쓸 수 있는 완화책을 내놓는 동시에, 장기적으로 시스템적 개선을 추진합니다.

이미 제공한 기능들

이미 출시한 항목으로 다음을 소개합니다.

  • 저장소 단위 PR 제어(협업자만 PR 생성 / PR 완전 비활성화)
  • 이슈 댓글 핀 고정
  • “+1” 같은 잡음 댓글을 줄이기 위한 배너
  • PR diff 성능 개선
  • 이슈 탐색 속도 개선
  • 임시 상호작용 제한(특정 사용자 활동 제한)

또한 UI에서 PR 삭제(스팸/악성 PR 제거) 같은 기능도 예고합니다.

다음으로 탐색 중인 방향

벽을 세운다고 커뮤니티가 생기지는 않는다는 전제를 깔고, “유지관리자에게 더 많은 통제권”을 주면서도 커뮤니티의 장점을 보호하는 방향을 탐색합니다.

  • 기준 기반 게이팅: PR 전에 연결된 이슈를 요구하거나, 제출 규칙을 정의
  • 트리아지 도구 개선: CONTRIBUTING.md 같은 가이드 기준으로 자동 평가/우선순위 제시

여기서도 “결정을 대체”가 아니라 “결정을 돕는 도구”가 되어야 하며, 유지관리자가 항상 통제권을 갖는다고 강조합니다.

또한 제한이 선의의 첫 기여자에게 불리할 수 있다는 트레이드오프도 인정하고, 옵션/설정 가능 형태로 제공한다고 말합니다.

커뮤니티는 ‘사다리’를 만든다

커뮤니티는 벽을 만나면 사다리를 만든다고 표현합니다.

  • 초대 기반 워크플로로 이동
  • 트리아지/평판 점수용 GitHub Actions를 직접 제작

예로 Mitchell Hashimoto의 Vouch 프로젝트(신뢰 관리 시스템)를 소개합니다.

인센티브도 다뤄야 한다

차단과 제한만 만들면 “시장(bazaar)”이 아니라 “요새(fortress)”가 된다고 말합니다.

GitHub에서 ‘기여’는 코드 작성에 쏠려 있는데, WordPress는 문서/재현 단계/유저 테스트/커뮤니티 지원 같은 다양한 기여에도 크레딧(Props)을 줍니다.

GitHub도 이런 다양한 기여를 더 잘 드러내고 축하하는 방향을 고민하겠다고 합니다. 꾸준히 트리아지하거나 문서 PR을 머지해온 사람은 프로젝트의 목소리를 이해했다는 신뢰 신호가 될 수 있고, 이런 신호를 표면화하면 결정을 더 빨리 내릴 수 있다는 주장입니다.

무엇이 필요한지 알려달라

저품질 기여 문제에 대한 방향을 논의하기 위해 GitHub Community Discussion을 열었고, 유지관리자의 피드백을 요청합니다.

결론은 이렇습니다.

오픈소스의 ‘끝나지 않는 9월’은 더 많은 사람이 참여하고 싶어한다는 긍정적 신호입니다. 하지만 참여가 지속되려면, 초기 인터넷이 도구와 규범을 발전시켰듯 오픈소스도 더 나은 신호/도구/에너지를 좋은 방향으로 흐르게 하는 방법을 만들어야 합니다.

Raw
03-github-pr-access-settings.md

New repository settings for configuring pull request access

유지관리자가 저장소가 기여를 받는 방식을 더 세밀하게 제어할 수 있도록, PR 접근을 관리하는 새 설정 2가지가 추가되었습니다.

1) Pull Request를 완전히 끄기

저장소 설정에서 PR을 완전히 비활성화할 수 있습니다(위키/이슈/디스커션/프로젝트를 끄는 것과 같은 수준).

  • 비활성화하면 PR 탭이 보이지 않습니다.
  • 기존 PR도 볼 수 없고, 새 PR도 열 수 없습니다.

미러 저장소, 읽기 전용 코드베이스, 혹은 “코드는 공개하지만 기여 관리는 하지 않겠다” 같은 운영에 유용하다고 설명합니다.

2) 협업자(collaborator)만 PR 생성 가능하게 제한

PR 흐름은 유지하되, PR 생성은 협업자(쓰기 권한 보유자) 로 제한할 수 있습니다.

  • PR 탭은 계속 보입니다.
  • 모든 PR은 열람/댓글 가능
  • 새 PR 생성만 협업자에게 허용

중요한 개발 단계에서 기여 품질을 관리하거나, 누가 변경을 제출할지 더 강하게 통제해야 할 때 도움이 된다고 말합니다.

협업자는 저장소 설정의 Collaborators 탭에서 추가/제거할 수 있습니다.

적용 범위

  • 모든 공개/비공개 저장소에서 사용 가능
  • 경로: Settings > General > Features

모바일 앱은 UI 반영이 곧 오지만, 현재도 PR을 비활성화하면 “탭은 보이지만 새 PR 생성은 불가” 상태로 동작합니다(다른 설정은 동일).

추가로, 특정 사용자의 활동을 일시적으로 제한하려면 “temporary interaction limits” 기능을 계속 사용할 수 있다고 안내합니다.

Raw
04-copilot-jetbrains-agent-skills.md

New features and improvements in GitHub Copilot in JetBrains IDEs

이번 업데이트는 JetBrains IDE용 GitHub Copilot에 여러 개선을 추가합니다.

  • Agent Mode에서 Agent Skills 지원(프리뷰)
  • 인라인 채팅과 설정 UI 개선
  • 품질/안정성 개선

새로운 기능

Agent Mode에서 Skills 지원(퍼블릭 프리뷰)

Agent mode가 “스킬(skills)”을 지원합니다.

의도는 다음과 같습니다.

  • 반복되는 초기 설정을 줄이고
  • 프로젝트별 워크플로에 맞게 Copilot을 더 잘 맞추고
  • 필요할 때 스킬 관련 콘텐츠를 컨텍스트에 자동으로 로드

사용자는 프로젝트용 스킬을 직접 만들 수도 있고, 커뮤니티가 공유한 스킬을 사용할 수도 있다고 안내합니다.

주의:

  • JetBrains용 Copilot에서 Agent Skills는 현재 퍼블릭 프리뷰
  • 경로: Settings > GitHub Copilot > Chat > Agent 에서 활성화
  • Copilot Business/Enterprise는 관리자가 “Editor preview features” 정책을 켜야 쓸 수 있음

사용자 경험(UX) 개선

인라인 채팅 개선

  • 선택한 코드를 Copilot Chat의 컨텍스트 입력으로 빠르게 추가
  • 플로팅 코드 툴바에서 인라인 채팅을 바로 열기

설정 관리 개선

설정 페이지를 더 구조적으로 정리했다고 설명합니다.

  • 에이전트별 토글: Agent mode / Coding Agent / Custom Agent를 각각 켜고 끌 수 있음
  • 로그인 상태가 아니면 설정 화면에서 로그인 안내 표시

그 외 사용성 개선으로,

  • 파일 접기/펼치기 시 탐색이 더 부드러워져 대화 정리가 쉬움
  • Home/End 키로 프롬프트 내 커서 이동이 직관적
  • 채팅/디프(diff) 뷰를 더 읽기 좋게 재디자인

품질 개선

품질과 신뢰성 개선 항목으로 다음을 언급합니다.

  • 파일 처리 도구에서 안전 체크 강화
  • “다음 편집 제안(next edit suggestions)” 안정성 향상
  • 재시작 후에도 모드 설정이 유지

사용 방법 / 피드백

  • 최신 Copilot 플러그인을 설치해 시험해 달라고 안내
  • IDE 내 피드백 기능 또는 공개 피드백 저장소(이슈 트래커)로 의견을 받는다고 합니다
Raw
05-vercel-stale-if-error.md

Stale-if-error cache-control directive now supported for all responses

Vercel CDN이 Cache-Control 헤더의 stale-if-error 지시자를 모든 응답에 대해 지원합니다.

이 지시자는 “오리진(origin)에 요청이 실패했을 때, 캐시된 오래된(stale) 응답을 얼마나 오래(초 단위) 대신 서빙할지”를 정합니다.

stale-if-error가 설정되어 있고, 오리진이 에러를 반환하면 CDN은 에러를 그대로 돌려주는 대신 이전에 캐시해둔 응답을 제공할 수 있습니다.

예로 다음 같은 실패 상황에서 stale 응답이 제공될 수 있다고 설명합니다.

  • 500 Internal Server Error
  • 네트워크 실패
  • DNS 오류

효과는 단순합니다.

  • 상위 서비스가 일시적으로 불안정할 때도
  • 앱이 “완전히 실패”하지 않고
  • 가능한 범위에서 계속 응답하도록

즉, 사용자 입장에서 가용성을 높이는 캐싱 동작을 더 쉽게 구성할 수 있습니다.

자세한 내용은 Vercel 문서(stale-if-error 항목)를 참고하라고 안내합니다.

Raw
06-vercel-block-next-mdx-remote.md

New deployments with vulnerable versions of the third-party package next-mdx-remote are now blocked by default

Vercel에서 취약한 버전의 next-mdx-remote(서드파티 패키지)를 포함한 새 배포는 기본적으로 자동 실패(fail to deploy) 하도록 변경되었습니다.

Vercel은 호스팅 제공자와 무관하게, 해당 패키지를 패치된 버전으로 업그레이드할 것을 강하게 권장합니다.

이 자동 보호는 환경변수로 끌 수 있습니다.

  • DANGEROUSLY_DEPLOY_VULNERABLE_CVE_2026_0969=1

(문서 링크로 환경변수 설정 방법을 안내합니다.)

Raw
07-vercel-browserbase-marketplace.md

Browserbase joins the Vercel Agent Marketplace

Browserbase가 Vercel Marketplace에 추가되어, 팀이 인프라를 직접 운영하지 않고도 AI 에이전트를 위한 브라우저 자동화를 실행할 수 있게 되었습니다.

이 통합은 에이전트가 원격 브라우저에 Chrome DevTools Protocol(CDP) 로 연결하도록 해, 다음 같은 “실제 웹사이트 상호작용”이 필요한 워크플로를 가능하게 한다고 설명합니다.

  • 대시보드 로그인
  • 폼 입력
  • 동적 페이지 탐색

원클릭 통합으로 얻는 이점(글에서 언급한 핵심 기능)은 다음과 같습니다.

  • 단일 API 키로 설치/연결
  • CDP를 통해 원격 브라우저에 연결
  • 브라우저 기반 에이전트 워크플로의 운영 복잡도 감소
  • Vercel Sandbox 및 AI Gateway와 함께 사용 가능

또한 Browserbase용 Web Bot Auth 지원도 함께 언급하며, Vercel에 호스팅된 배포를 에이전트가 탐색할 때 보안 계층에 의해 중단되는 일을 줄여준다고 안내합니다.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment