github·2026년 7월 22일·3분 읽기큐레이션 요약

다음 장: GitHub 버그 바운티 프로그램 개편

GitHub은 버그 바운티 프로그램을 대량 제출보다 고품질·고영향 보안 연구 중심으로 재편한다. 이를 위해 우수 연구자 대상의 영구 VIP 프로그램을 도입하고, 공개 프로그램의 보상 체계와 제출 요건을 변경한다. 새 기준은 2026년 7월 27일 이후 제출된 보고서부터 적용된다. ## 프로그램 개편 배경 - 신규 연구자와 기존 연구자의 제출량 증가로 보고서 처리 대기열이 길어졌다. - 저품질 보고서와 AI로 생성된 보고서가 늘어나면서 중요한 취약점에 집중하기 어려워졌다. - GitHub은 “더 많이 제출할수록 더 많은 보상”이 아니라 “더 나은 취약점을 제출할수록 더 많은 보상”을 제공하는 방향을 택했다. ## 영구 VIP 프로그램 도입 - 지속적으로 고품질·고영향 취약점을 제보한 연구자를 위한 비공개 초대형 프로그램이다. - VIP 연구자에게는 다음 혜택이 제공된다. - 더 높은 보상금 - 더 빠른 응답 - GitHub 보안 엔지니어링 팀과의 긴밀한 협업 - VIP 보상 기준: - Low: **1,000달러** - Medium: **7,500달러** - High: **20,000달러** - Critical: **30,000달러 이상** - 다음 조건 중 하나 이상을 달성하면 VIP 자격을 얻을 수 있다. - Critical 취약점 1건 - High 취약점 2건 - Medium 취약점 4건 - Low 취약점 7건 - 구체적인 자격 기준은 GitHub의 공개 HackerOne 페이지에 게시될 예정이다. ## 공개 버그 바운티 보상 변경 - 공개 프로그램의 보상금은 다음과 같이 고정 금액으로 변경된다. - Low: **250달러** - Medium: **2,000달러** - High: **5,000달러** - Critical: **10,000달러** - 기존의 보상 범위 대신 심각도별 단일 금액을 사용한다. - 고정 금액은 연구자에게 예상 가능한 보상을 제공하고, GitHub의 내부 검토 부담과 불확실성을 줄이기 위한 조치다. - 기대 이상의 연구에는 별도의 재량 보너스가 지급될 수 있다. - 공개 프로그램은 신규 연구자가 탐색하고 실적을 쌓은 뒤 VIP 프로그램으로 진입하는 역할을 계속한다. ## 공개 제출에 신호 요건 적용 - 공개 프로그램에 HackerOne의 신호(signal) 요건이 도입된다. - 아직 충분한 실적이 없는 연구자는 제출 횟수가 제한된다. - HackerOne은 기준 미달 연구자에게 최대 **4회의 초기 제출 기회**를 제공한다. - 이는 신규 연구자를 배제하기 위한 장벽이 아니라, 실제 보안 연구 역량을 확인하고 저노력·AI 생성 보고서를 줄이기 위한 최소 기준이다. ## 유지되는 원칙과 적용 시점 - GitHub은 실제 보안 연구에 대한 신속한 보상과 명확한 커뮤니케이션을 계속 유지한다고 밝혔다. - 변경 시행 전에 제출된 보고서는 기존 보상 체계로 처리된다. - **2026년 7월 27일 이후 제출된 보고서**부터 새로운 보상 및 운영 구조가 적용된다. - 향후에는 응답 속도 개선, 심각도 판정 근거 명확화, 보안 커뮤니티와의 소통 확대도 추진한다. 이번 개편에 참여하려는 연구자는 단순히 보고서 수를 늘리기보다 재현 가능한 검증 절차, 명확한 영향 분석, 높은 심각도의 독창적인 취약점에 집중하는 것이 유리하다. 신규 연구자는 제한된 초기 제출 기회를 활용해 정확하고 완성도 높은 보고서를 제출하는 전략이 중요하다.

원문 읽기(새 탭에서 열림)

vulnerability-managementapplication-securitybug-bountyhackerone+2

github·2026년 7월 21일·3분 읽기큐레이션 요약

캔버스로 인터랙티브한 경험을 만드는 방법

캔버스 확장은 GitHub Copilot을 단순한 대화형 도구에서 시각적이고 상호작용 가능한 작업 공간으로 확장한다. 사용자는 정보를 직접 보고 클릭·편집하며 작업할 수 있고, 에이전트는 같은 캔버스를 실시간으로 갱신한다. 따라서 이슈 분류, 코드 구조 탐색, 워크트리 정리처럼 대화만으로 처리하기 어려운 작업을 더 직관적으로 수행할 수 있다. ## 캔버스의 작동 방식 - 캔버스는 GitHub Copilot 앱 안에서 에이전트와 개발자가 함께 사용하는 공유 인터페이스다. - 에이전트는 작업 과정에서 캔버스를 업데이트하고, 사용자는 클릭·편집·필터링 등으로 정보를 직접 조작할 수 있다. - 사용자의 상호작용은 에이전트에 전달되거나 캔버스 내부에서 로컬로 처리된다. - Copilot에 추가 기능이나 개선 사항을 요청하면서 캔버스를 작업 흐름에 맞게 계속 발전시킬 수 있다. - GitHub Copilot 앱의 에이전트 세션에서 `/create-canvas`를 입력한 뒤 원하는 인터페이스와 기능을 설명하면 생성할 수 있다. ## 시각적 이슈 트리아지 - 저장소의 GitHub Issue를 카드 형식으로 하나씩 보여준다. - 오른쪽으로 스와이프하면 처리할 이슈로, 왼쪽으로 스와이프하면 거절할 이슈로 분류할 수 있다. - 사용자의 선택에 따라 캔버스가 실시간으로 이슈를 적절한 그룹으로 이동시킨다. - 긴 대화나 명령 대신 빠른 제스처로 많은 이슈를 검토할 수 있다. ## 인터랙티브 코드베이스 다이어그램 - 프로젝트의 각 구성 요소를 노드로 표현하고, 컴포넌트 간 관계를 시각화한다. - 노드를 마우스로 이동하거나 마우스를 올려 세부 정보를 확인할 수 있다. - 필터를 사용해 코드베이스의 특정 계층이나 영역만 탐색할 수 있다. - 정적인 문서나 설명을 읽는 대신 아키텍처를 직접 탐색하면서 시스템 구조를 이해할 수 있다. ## 세션과 Git worktree 관리 - GitHub Copilot 앱의 활성 세션과 연결된 worktree를 한 화면에 표시한다. - 현재 사용 중인 worktree와 오래되었거나 고립된(orphaned) worktree를 구분한다. - 필요하지 않은 stale worktree를 버튼 클릭 몇 번으로 정리할 수 있다. - 여러 에이전트 세션을 동시에 사용하는 개발자에게 세션 상태와 작업 공간을 관리하는 시각적 제어판 역할을 한다. ## 에이전트 프롬프트 코치 - 과거 에이전트 세션의 프롬프트를 분석해 개선점을 제안한다. - 부족한 맥락, 맞춤법 오류, 문법·구문 문제 등을 찾아낸다. - 각 프롬프트를 더 명확하고 효과적으로 작성하는 방법을 안내한다. - 반복적인 피드백을 통해 에이전트가 더 일관된 결과를 내도록 프롬프트 작성 능력을 높일 수 있다. ## 여러 도구를 연결하는 지식 탐색 - Slack, Teams, 이메일, 문서 등 여러 업무 도구를 검색한다. - 특정 파일이나 주제와 관련된 지식이 있는 사람을 찾아준다. - 해당 인물과 주제의 연결 근거가 어디에서 발견되었는지도 함께 보여준다. - 조직 내 담당자나 관련 전문가를 빠르게 파악해 추가 질문과 협업으로 이어갈 수 있다. ## 활용 시사점 캔버스 확장은 AI와의 상호작용을 프롬프트와 응답의 연속에서 시각적 탐색·편집·실행 과정으로 바꾼다. 정보를 한눈에 비교하거나 직접 조작해야 하는 작업이라면 `/create-canvas`로 원하는 화면과 동작을 구체적으로 요청해 보는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

AI 에이전트slackgithub-copilotgithub-issues+3

github·2026년 7월 17일·1분 읽기큐레이션 요약

예스라고 말하는 대가가 달라졌다

Dalia는 GitHub의 Copilot Agent Control Plane 팀에서 소프트웨어 엔지니어로 일하고 있습니다. 주요 업무는 Copilot 고객을 위한 서브에이전트 거버넌스 계층을 구축하는 것입니다. ### 소속과 역할 - GitHub의 **Copilot Agent Control Plane 팀**에서 근무합니다. - 소프트웨어 엔지니어로서 Copilot 관련 인프라와 기능을 개발합니다. ### 담당 분야 - Copilot 고객이 사용하는 **서브에이전트(subagent)** 를 관리하고 통제하는 거버넌스 계층을 구축합니다. - 제공된 내용만으로는 해당 시스템의 구체적인 설계, 기능, 운영 방식은 확인할 수 없습니다.

원문 읽기(새 탭에서 열림)

github-copilotsoftware-engineeringsubagentscontrol-plane+1

github·2026년 7월 15일·4분 읽기큐레이션 요약

초보자를 위한 GitHub: GitHub 필수 기능 마스터를 위한 로드맵

GitHub는 코드 저장소를 넘어, 버전 관리와 협업을 배우고 오픈소스에 참여하기 위한 개발자의 기반이다. 이 글은 Git과 GitHub의 기본 개념부터 계정 보안, 저장소 생성, Markdown, 브랜치와 풀 리퀘스트를 활용한 협업 흐름까지 초보자가 익혀야 할 내용을 단계적으로 설명한다. 핵심은 변경 사항을 Git으로 관리하고, GitHub에서 브랜치와 풀 리퀘스트를 통해 안전하게 공유·검토·통합하는 것이다. ## 버전 관리와 Git의 기본 개념 - 버전 관리는 파일의 변경 내용을 시간순으로 기록해 무엇이 언제, 왜 바뀌었는지 확인하고 이전 상태로 되돌릴 수 있게 한다. - Git은 가장 널리 사용되는 버전 관리 시스템이다. - Git의 작업 영역은 다음 세 가지로 나뉜다. - **Working directory**: 실제 파일을 수정하는 공간 - **Staging area**: 다음 커밋에 포함할 변경 사항을 검토하고 준비하는 공간 - **Local repository**: 커밋된 변경 이력이 저장되는 공간 - 기본 흐름은 `git status`로 상태를 확인하고, `git add`로 변경 사항을 스테이징한 뒤, `git commit`으로 기록을 저장하는 방식이다. - “코드를 push한다”는 말은 로컬에 만든 커밋을 GitHub의 원격 저장소에 업로드한다는 뜻이다. ## GitHub 계정 보안과 프로필 관리 - GitHub 계정은 개발자 정체성과 포트폴리오 역할을 하므로 보안을 강화해야 한다. - **Settings → Password and authentication**에서 2단계 인증(2FA)을 활성화하면 비밀번호가 유출돼도 추가 인증 없이는 계정에 접근하기 어렵다. - 2FA 복구 코드는 기기를 잃어버렸을 때 계정에 다시 로그인할 수 있는 중요한 수단이므로 비밀번호 관리자에 안전하게 보관해야 한다. - 사용자 이름과 동일한 이름의 공개 저장소를 만들고 README를 추가하면, 해당 README가 GitHub 프로필에 표시된다. - 프로필 README에는 기술, 프로젝트, 관심 분야 등을 작성해 개발자 포트폴리오로 활용할 수 있다. ## 자주 사용하는 Git 명령어 - `git config --global user.name "..."`: 커밋에 기록할 사용자 이름 설정 - `git init`: 현재 폴더를 Git 저장소로 초기화 - `git clone <url>`: 원격 저장소를 로컬로 복제 - `git status`: 변경 사항과 스테이징 상태 확인 - `git add .`: 모든 변경 사항을 스테이징 - `git commit -m "message"`: 스테이징된 변경 사항을 커밋 - `git switch -c <branch>`: 새 브랜치를 만들고 해당 브랜치로 이동 - `git push`: 로컬 커밋을 GitHub에 업로드 - `git pull`: GitHub의 최신 변경 사항을 내려받고 병합 - `git merge <branch>`: 다른 브랜치의 변경 사항을 현재 브랜치에 통합 ## 첫 번째 GitHub 저장소 만들기 - 저장소(repository)는 프로젝트 파일과 변경 이력을 관리하고 여러 사람이 함께 작업하는 프로젝트의 중심 공간이다. - GitHub 대시보드에서 **New**를 선택한 뒤 저장소 이름과 공개·비공개 여부를 지정해 만들 수 있다. - README를 함께 생성하면 방문자가 프로젝트를 처음 이해하는 안내문 역할을 한다. - 필요에 따라 다음 항목도 추가할 수 있다. - **`.gitignore`**: 운영체제 파일, 의존성 폴더, 임시 빌드 결과물처럼 추적할 필요가 없는 파일을 Git에서 제외 - **라이선스**: 다른 사람이 코드를 어떤 조건으로 사용·수정·배포할 수 있는지 명시 - `.gitignore`를 사용하면 저장소에 실제 소스 코드와 중요한 파일만 남겨 프로젝트를 깔끔하게 유지할 수 있다. ## Markdown으로 문서 작성하기 - Markdown은 일반 텍스트에 간단한 기호를 추가해 제목, 목록, 링크, 코드 블록 등을 표현하는 가벼운 문서 형식이다. - GitHub의 README, 이슈, 풀 리퀘스트, 댓글 등 대부분의 텍스트 작성 영역에서 사용된다. - 일부 HTML 태그와 함께 사용해 문서를 읽기 쉽고 구조적으로 만들 수 있다. - 좋은 Markdown 문서는 프로젝트의 목적과 사용 방법을 빠르게 전달해 저장소의 접근성을 높인다. ## GitHub Flow를 이용한 협업 - GitHub Flow는 공유 프로젝트에 변경 사항을 안전하게 반영하기 위한 반복적인 작업 절차다. - 일반적인 순서는 다음과 같다. 1. 저장소를 로컬에 `clone` 2. 작업용 브랜치 생성 3. 코드나 문서 수정 4. 변경 사항 커밋 5. GitHub에 `push` 6. 풀 리퀘스트 생성 7. 검토와 승인 후 병합 - 기능별로 브랜치를 분리하면 기존 코드에 직접 영향을 주지 않고 독립적으로 작업할 수 있다. - 풀 리퀘스트를 통해 동료가 변경 내용을 검토하고, 테스트 결과나 새로운 동작을 확인한 뒤 병합할 수 있다. - 예를 들어 공유 AI 프롬프트를 수정할 때도 별도 브랜치에서 변경하고, 풀 리퀘스트로 결과를 검토한 후 병합하면 팀 전체가 개선된 프롬프트를 사용할 수 있다. 처음에는 모든 Git 명령어를 외우기보다 `status → add → commit → push` 흐름과 브랜치·풀 리퀘스트 과정을 반복해 익히는 것이 좋다. 또한 2FA를 설정하고, README와 `.gitignore`를 갖춘 저장소를 만들어 작은 프로젝트부터 GitHub Flow를 연습하면 협업과 오픈소스 참여로 자연스럽게 확장할 수 있다.

원문 읽기(새 탭에서 열림)

오픈 소스githubGitmarkdown+3

github·2026년 7월 10일·4분 읽기큐레이션 요약

더 나은 도구가 Copilot 코드 리뷰를 악화시켰습니다. 실제로 개선한 방법은 다음과 같습니다.

더 나은 코드 탐색 도구를 도입했지만, GitHub Copilot 코드 리뷰의 비용은 오히려 증가하고 발견하는 문제는 줄어들었다. 원인은 `grep`, `glob`, `view` 자체가 아니라, 코딩 에이전트용으로 작성된 도구 지침을 리뷰 작업에 그대로 적용한 데 있었다. 리뷰어처럼 PR diff에서 출발해 필요한 최소한의 코드만 확인하도록 지침을 바꾸자, 리뷰 품질을 유지하면서 평균 비용을 약 20% 낮출 수 있었다. ## 도구 교체가 예상과 다른 결과를 낳은 이유 - 기존 Copilot 코드 리뷰는 자체 코드 탐색 도구를 사용했다. - `list_dir`: 디렉터리 탐색 - `search_file`, `search_dir`: 파일 및 디렉터리 검색 - `read_code`: 코드 읽기 - 이 도구들은 검색 결과나 지정한 코드 범위뿐 아니라 주변 코드도 함께 반환했다. - 토큰 비용은 증가하지만, 도구 호출 횟수가 적고 자동으로 맥락을 확보하기 어려운 초기 모델에는 유용했다. - Copilot CLI는 여러 제품이 공유하는 Unix 스타일 도구를 제공했다. - `glob`: 후보 파일과 디렉터리 탐색 - `grep`: 텍스트, 심벌, 호출 지점 검색 - `view`: 특정 파일이나 코드 범위 읽기 - 인프라를 통합하면 도구 구현 중복을 줄이고, CLI와 클라우드 에이전트의 개선 사항을 코드 리뷰에도 공유할 수 있다는 장점이 있었다. - 그러나 단순히 기존 도구를 새 도구로 치환하는 방식으로는 충분하지 않았다. ## 벤치마크에서 드러난 성능 저하 - 공유 도구를 적용한 오프라인 벤치마크에서 다음 문제가 나타났다. - 평균 리뷰 비용 증가 - 유용한 리뷰 댓글 감소 - 전체적으로 효율성과 효과성 모두 저하 - 내부 추적 데이터는 최종 점수뿐 아니라 에이전트의 탐색 과정도 보여줬다. - 어떤 도구를 호출했는지 - 각 호출이 얼마나 많은 결과를 반환했는지 - 오류가 발생했는지 - 탐색이 문제의 증거로 좁혀졌는지, 아니면 범위를 넓혔는지 - 이를 통해 도구가 오작동한 것이 아니라, 에이전트가 도구를 사용하는 방식이 문제였음이 드러났다. ## 코드 리뷰가 저장소 탐색으로 변한 문제 - 에이전트는 PR의 변경 사항을 분석하기보다 저장소 전체를 이해하려는 것처럼 행동했다. - 전형적인 흐름은 다음과 같았다. - 넓게 검색 - 경로를 추측 - 많은 파일을 읽음 - 새로 발견한 내용을 바탕으로 다시 검색 - 불필요한 맥락을 계속 누적 - 이런 방식은 “저장소를 이해하거나 기능을 구현하라”는 작업에는 적합할 수 있다. - 하지만 코드 리뷰의 목적은 저장소 전체를 파악하는 것이 아니라, 변경 사항이 실제 문제를 만들었는지 판단하는 것이다. - 도구 결과는 일회성 출력이 아니다. - 반환된 파일 내용은 에이전트의 컨텍스트에 남는다. - 불필요한 코드는 이후 추론 비용을 높인다. - 관련 없는 정보가 많아지면 리뷰의 초점도 흐려질 수 있다. ## 코딩 에이전트와 코드 리뷰어의 탐색 방식 차이 - 일반적인 코딩 에이전트는 변경 전에 넓은 영역을 파악할 수 있다. - 다른 코드에 미칠 영향을 확인하기 위해 저장소 구조를 폭넓게 탐색한다. - 계획 수립, 파일 수정, 여러 차례의 대화형 작업을 전제로 한다. - 코드 리뷰어는 보통 훨씬 좁은 질문에서 시작한다. - 이 함수는 어디에서 호출되는가? - 이 설정 키가 다른 곳에서도 사용되는가? - 같은 패턴의 테스트나 헬퍼가 존재하는가? - 이 동작을 설명하는 데 필요한 가장 작은 코드 범위는 무엇인가? - 따라서 리뷰 에이전트는 다음 순서를 따라야 한다. - PR diff에서 출발 - 변경된 코드가 일으킬 수 있는 구체적인 의문을 제기 - 해당 의문을 검증할 최소한의 주변 코드만 탐색 - 문제의 증거가 부족하면 탐색을 확장하지 않고 결론 ## 도구보다 중요한 지침과 워크플로 - Copilot CLI와 클라우드 에이전트의 도구 지침은 대화형 코딩 작업에 맞춰져 있었다. - 동일한 `grep`, `glob`, `view`라도 지침이 다르면 에이전트의 행동이 달라진다. - 기존 지침은 넓은 저장소 탐색을 유도했지만, 코드 리뷰에는 다음 원칙이 필요했다. - 변경된 diff를 탐색의 중심으로 삼기 - 파일 경로를 추측하기보다 diff에서 확인된 심벌과 호출 관계를 활용하기 - 전체 파일보다 필요한 코드 범위만 읽기 - 새 정보를 얻을 때마다 탐색을 무작정 넓히지 않기 - 실제 문제를 판단하는 데 필요한 증거만 컨텍스트에 추가하기 - 지침을 리뷰 작업의 특성에 맞게 다시 작성한 결과, 도구는 그대로 유지하면서도 리뷰 비용을 약 20% 절감했다. - 글에서는 이 개선이 리뷰 품질을 유지한 상태에서 이루어졌다고 설명한다. ## 실용적인 결론 에이전트 도구를 교체할 때는 도구의 기능만 비교해서는 안 된다. 도구 사용 지침과 에이전트가 따라야 할 탐색 워크플로까지 작업 목적에 맞게 설계해야 하며, 특히 코드 리뷰에서는 “더 많이 읽기”보다 “변경 사항을 검증하는 데 필요한 최소한만 읽기”가 비용과 품질 모두에 유리하다.

원문 읽기(새 탭에서 열림)

AI 에이전트github-copilot코드 리뷰pull-requests+2

github·2026년 7월 9일·1분 읽기큐레이션 요약

GitHub가 모든 저장소에 지속적인 소유자를 부여한 방법

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 보안 프로그램을 이끌고 있습니다. 주요 업무는 취약점 관리, 보안 개발 수명주기(SDL) 도구, 개발자 중심의 보안 자동화이며, 조직이 안전한 선택을 쉽게 할 수 있는 시스템을 구축하는 데 집중합니다. ### 대규모 보안 프로그램 운영 - GitHub에서 대규모 보안 프로그램을 주도합니다. - 다양한 팀과 시스템에 적용할 수 있는 확장성 높은 보안 체계를 구축합니다. ### 주요 전문 분야 - **취약점 관리:** 보안 취약점을 식별하고 추적·개선하는 프로세스 - **보안 개발 수명주기 도구:** 개발 과정 전반에 보안을 통합하는 도구와 체계 - **보안 자동화:** 개발자의 업무 흐름 속에서 보안 조치를 자동화하는 기술 ### 개발자 중심의 보안 철학 - 보안을 별도의 부담으로 만들기보다 개발자가 자연스럽게 따를 수 있도록 설계합니다. - “안전한 선택이 가장 쉬운 선택”이 되도록 시스템과 자동화 기능을 구축합니다. - 대규모 환경에서도 일관되게 작동하는 실용적인 보안 솔루션을 지향합니다.

원문 읽기(새 탭에서 열림)

githubvulnerability-managementsecurity-automationsecure-development-lifecycle+1

github·2026년 7월 8일·4분 읽기큐레이션 요약

GitHub 에이전틱 워크플로로 리포지토리 간 문서화 자동화

Aspire 팀은 GitHub Agentic Workflows를 활용해 제품 코드 저장소와 문서 저장소가 분리된 환경에서도 기능 변경 직후 문서 PR을 자동 생성하는 시스템을 구축했다. 에이전트가 변경 사항과 이슈를 분석해 문서를 작성하지만, 실제 쓰기 작업은 제한된 별도 핸들러가 수행하도록 분리해 보안을 확보했다. 그 결과 Aspire 13.3·13.4에서 82개의 문서 PR이 제품 PR 병합 후 중앙값 44.8시간 내 생성됐고, 모두 해당 기능을 구현한 엔지니어의 검토를 받았다. ## 교차 저장소 문서화가 어려운 이유 - 제품 코드는 `microsoft/aspire`, 문서 사이트는 `microsoft/aspire.dev`에 있어 저장소와 배포 대상, 리뷰 절차가 분리되어 있다. - 기존 방식은 문서 작성자가 몇 주 뒤 닫힌 PR을 찾아 변경 내용을 역추적하는 구조였다. - 기능 작성자는 이미 다음 작업으로 넘어간 상태라 문서 작성에 필요한 맥락을 충분히 제공하기 어려웠다. - 저장소 전체에 쓰기 권한을 가진 광범위한 토큰은 보안상 부적절하므로, 단순한 크로스 리포지토리 자동화도 권한 설계가 병목이 된다. ## GitHub Agentic Workflows의 구조 - 워크플로를 YAML 대신 하나의 Markdown 파일로 작성한다. - YAML 형식의 frontmatter에 설정을 작성한다. - 아래에는 에이전트가 수행할 작업을 자연어 프롬프트로 작성한다. - 컴파일하면 일반 GitHub Actions 워크플로인 `.lock.yml` 파일이 생성된다. - 실행 시 에이전트는 제한된 도구와 프롬프트를 바탕으로 변경 사항을 분석한다. - 에이전트가 GitHub에 직접 쓰지 않는 점이 핵심이다. - 에이전트는 생성하려는 PR, 이슈, 댓글을 JSON 형태의 의도로 출력한다. - 별도의 `safe-outputs handler`가 허용된 작업만 실제로 실행한다. - 저장소와 작업 종류를 명시적으로 제한할 수 있어 보안 검토와 자동화의 균형을 맞춘다. ## 기능 PR에서 문서 PR로 이어지는 자동화 흐름 - `microsoft/aspire`의 `main` 또는 `release/*` 브랜치에 병합된 PR을 `pull_request: closed` 이벤트로 감지한다. - `merged == true` 조건을 적용해 실제 병합된 PR만 처리한다. - 에이전트가 실행되기 전에 Bash 기반의 결정론적 로직으로 문서 대상 브랜치를 결정한다. 1. 제품 PR의 마일스톤 제목을 확인한다. 예를 들어 `13.4`는 문서 저장소의 `release/13.4`로 매핑된다. 2. PR 본문에서 `Fixes`, `Closes`, `Resolves`로 연결된 이슈를 찾고, 해당 이슈의 첫 번째 비어 있지 않은 마일스톤을 확인한다. 3. PR의 base ref가 `release/X.Y` 또는 `release/X.Y.Z` 형식이면 이를 사용한다. 4. 어느 조건에도 해당하지 않으면 `main`을 사용한다. - 마일스톤과 문서 브랜치를 명확히 매핑해 에이전트가 대상 브랜치를 추측하지 않도록 한다. - 에이전트는 제품 diff와 연결된 이슈를 읽고 문서화가 필요한 변경인지 판단한다. - 문서가 필요하면 체크아웃된 `microsoft/aspire.dev` 작업 공간에 기존 문서 작성 규칙에 맞춰 초안을 작성한다. - 문서의 문체 - MDX 규칙 - Astro Starlight 컴포넌트 사용법 - 이후 `create_pull_request` safe output을 생성해 문서 PR 생성을 요청한다. ## 제한된 권한으로 PR 생성하기 - safe-outputs 핸들러는 실제 PR 생성 시 다음 제약을 적용한다. - PR 제목에 `[docs]` 접두사 사용 - `docs-from-code` 라벨 부착 - 자동 병합 없이 항상 draft PR로 생성 - base 브랜치는 `main` 또는 `release/*`로 제한 - 대상 저장소는 `microsoft/aspire.dev`로 고정 - 제품 PR의 리뷰 기록에서 해당 기능을 승인한 SME를 찾아 문서 PR 리뷰어로 요청한다. - 문서 리뷰가 기능 구현자의 맥락과 분리되지 않도록, 실제 기능을 승인한 사람이 문서도 검토하게 한다. - 별도 작업은 원본 제품 PR에 문서 PR 링크를 댓글로 남긴다. - 재실행 시 이전 `pr-docs-check` 댓글을 최소화해 중복 알림을 줄인다. - 기능을 병합한 엔지니어는 몇 분 안에 문서 초안을 확인할 수 있다. ## 보안 설계와 safe-outputs 계약 - GitHub 도구 세트를 `repos`, `issues`, `pull_requests` 등 필요한 범위로 제한한다. - `min-integrity: approved` 설정으로 무결성이 검증된 작업만 실행하도록 한다. - 허용 저장소를 `microsoft/*`처럼 제한할 수 있다. - 전용 GitHub App의 App ID와 private key를 사용해 일반적인 광범위 토큰 대신 작업별 권한을 부여한다. - App이 접근할 수 있는 저장소도 `aspire.dev`, `aspire`로 한정한다. - 에이전트의 분석 권한과 실제 변경 권한을 분리해, 에이전트가 임의로 저장소에 쓰거나 병합하지 못하게 한다. - 최종 문서 반영은 여전히 draft PR과 사람의 리뷰를 거친다. ## 측정된 결과 - Aspire 13.3과 13.4에서 문서 기능 PR 82개가 병합됐다. - 문서 PR은 제품 PR 병합 후 중앙값 44.8시간 뒤에 생성됐다. - 모든 문서 PR을 해당 기능을 구현한 엔지니어가 검토했다. - 별도의 인력 충원이나 새로운 프로세스 교육 없이 운영됐다. - 문서 작성 시점이 기능 출시 후 수 주가 아니라 기능 병합 직후로 앞당겨졌다. 기능 저장소와 문서 저장소가 분리되어 있다면, 에이전트에게 광범위한 쓰기 권한을 주기보다 **결정론적인 브랜치 선택 로직, 제한된 safe outputs, 초안 PR, 담당 엔지니어 리뷰**를 결합하는 방식이 실용적이다. AI가 문서를 작성하더라도 최종 병합은 사람이 담당하도록 설계하는 것이 안전성과 문서 품질을 함께 확보하는 방법이다.

원문 읽기(새 탭에서 열림)

AI 에이전트GitHub Actionsastrogithub-agentic-workflows+3

github·2026년 7월 8일·3분 읽기큐레이션 요약

GitHub Copilot이 GitHub Pages에서 DNS 설정을 전혀 필요 없게 만드는 방법

GitHub Copilot CLI와 Namecheap API를 연동하면 DNS 레코드를 직접 수정하지 않고도 GitHub Pages 사이트를 사용자 도메인에 연결할 수 있다. 글에서는 저장소 생성부터 도메인 등록, DNS 설정, HTTPS 적용 및 배포 확인까지 약 14분 만에 완료하는 과정을 소개한다. 핵심은 Copilot CLI의 Namecheap 스킬이 API를 통해 DNS 작업을 자동화하되, 실제 변경 전에는 사용자 승인을 받는다는 점이다. ## GitHub Pages 사이트 만들기 - 공개 GitHub 저장소를 생성한다. - Copilot CLI에 원하는 결과를 설명해 `index.html`과 랜딩 페이지를 만들도록 한다. - GitHub Pages 활성화도 Copilot CLI를 통해 처리할 수 있다. - 우선 `github.io` 주소로 사이트가 배포되며, 이후 사용자 도메인을 연결한다. ## 저렴한 도메인 등록 - 비싼 `.com` 도메인이 아니어도 사이드 프로젝트를 시작할 수 있다. - 글에서는 `.click` 최상위 도메인을 사용했다. - `ghpagesblog.click` 도메인을 약 2달러에 등록했다. ## Namecheap API 활성화 - Namecheap의 **Profile → Tools → Business & Dev Tools → Namecheap API Access**로 이동한다. - API를 활성화한다. - API를 호출할 컴퓨터의 공인 IP를 **Whitelisted IPs**에 추가한다. - 발급된 API 키를 안전하게 보관한다. - API 키는 이후 Copilot CLI가 Namecheap 계정과 DNS를 관리할 때 사용한다. ## Copilot CLI에 Namecheap 스킬 설치 - 다음 명령으로 Namecheap 자동화 스킬을 설치한다. ```bash gh skill install github/awesome-copilot namecheap --scope user ``` - Copilot CLI에 Namecheap 도메인 목록 조회 등을 요청하면 사용자 이름과 API 키를 입력하도록 안내한다. - 인증 정보가 설정되면 계정의 도메인 목록을 반환해 API 연결이 정상인지 확인할 수 있다. - API 키는 로컬에 저장되므로 보관 위치와 접근 권한에 주의해야 한다. ## DNS 레코드 자동 설정 - Copilot CLI에 특정 Namecheap 도메인을 GitHub Pages 사이트에 연결하도록 요청한다. - 자동화 스킬은 DNS를 변경하기 전에 사용자에게 승인을 요청한다. - 기존 Namecheap 주차(parking) 또는 리디렉션 레코드를 제거하고 GitHub Pages에 필요한 설정으로 교체한다. - 루트 도메인에는 GitHub Pages의 A 레코드를 설정한다. - `www` 서브도메인에는 GitHub Pages를 가리키는 CNAME 레코드를 설정한다. - 저장소에도 `CNAME` 파일을 커밋해 GitHub Pages가 해당 사용자 도메인에 응답하도록 구성한다. ## 배포 및 도메인 확인 - Copilot CLI는 설정이 끝났다고 가정하지 않고 도메인 해석 상태를 직접 확인한다. - DNS가 올바르게 GitHub Pages를 가리키는지 검증한다. - GitHub Pages의 사용자 도메인 설정과 실제 사이트 연결 상태를 함께 확인하는 방식이다. - 글의 목표는 DNS 전파와 HTTPS 적용을 포함한 전체 배포 과정을 수동 설정 없이 완료하는 것이다. 실용적으로는 GitHub Pages와 Namecheap을 사용하는 개인 프로젝트에서 이 방식을 활용할 수 있다. 다만 DNS 레코드 삭제·교체와 API 키 사용이 포함되므로, 자동화 도중 표시되는 변경 내용을 반드시 검토하고 승인하는 것이 좋다.

원문 읽기(새 탭에서 열림)

github-copilotdnsgithub-pagesnamecheap-api+2

github·2026년 7월 2일·1분 읽기큐레이션 요약

GitHub은 시크릿 스캐닝을 활용해 받은편지함을 0으로 만든 방법

Michael Recachinas는 GitHub의 스태프 보안 엔지니어로, 대규모 취약점 관리와 보안 개발 생명주기 도구를 이끌고 있다. 개발자가 보안상 올바른 선택을 쉽게 할 수 있도록, 대규모 환경에서 작동하는 보안 시스템과 자동화 기술을 구축해 온 전문가다. ### GitHub에서의 역할 - GitHub의 대규모 보안 프로그램을 주도한다. - 주요 업무는 다음과 같다. - 취약점 관리 - 보안 개발 생명주기(SDLC) 도구 - 개발자 중심의 보안 자동화 ### 전문성과 경력 - 대규모 시스템을 설계하고 운영한 경험을 보유하고 있다. - 보안 프로세스를 개발자의 업무 흐름에 자연스럽게 통합하는 데 집중한다. - 조직이 보안을 별도의 부담으로 느끼기보다, 안전한 선택을 쉽게 실행하도록 만드는 것을 목표로 한다. 제공된 내용은 기술 블로그 본문이 아니라 저자 소개에 해당하므로, 특정 기술이나 구현 방법에 대한 추가적인 요약은 어렵다.

원문 읽기(새 탭에서 열림)

githubvulnerability-managementapplication-securitysecurity-automation+1

github·2026년 7월 1일·1분 읽기큐레이션 요약

이번 주에 모든 GitHub 유지 관리자가 활성화해야 할 6가지 보안 설정

Joseph은 사이버보안과 AI 분야에서 개발자들이 안전한 소프트웨어를 만들도록 돕는 전문가다. 오픈소스 게임, 영상, 강연을 통해 보안 지식을 실용적으로 전달하며, 전 세계 개발자와 청중에게 큰 영향력을 미치고 있다. ### 사이버보안 및 AI 분야의 전문성 - 개발자가 보안을 고려해 소프트웨어를 구축할 수 있도록 콘텐츠와 소프트웨어를 개발한다. - 사이버보안과 AI를 결합한 실용적인 지식을 전달하는 인물로 소개된다. ### 오픈소스 보안 교육 - 오픈소스 게임 `gh.io/scg`를 제작했다. - 이 게임은 10,000명 이상의 개발자가 미래에도 활용 가능한 보안 역량을 익히는 데 기여했다. ### 대중적인 보안 콘텐츠 - Joseph의 영상 콘텐츠는 누적 280만 회 이상의 조회수를 기록했다. - 복잡한 보안 주제를 쉽게 설명하고, 개발자가 바로 적용할 수 있는 실용적인 조언을 제공한다. - 콘텐츠는 전 세계 audience를 대상으로 한다. ### 국제적인 강연 활동 - 최근 4년간 25개국에서 총 79회의 강연을 진행했다. - 전문적인 통찰력과 활기찬 무대 진행으로 청중의 관심을 끌었다. 개발자라면 Joseph의 오픈소스 게임이나 영상을 활용해 보안 개념을 실습 중심으로 익히고, 강연을 통해 최신 보안 동향과 적용 방법을 접할 수 있다.

원문 읽기(새 탭에서 열림)

AI오픈 소스cybersecuritysecure-software-development

github·2026년 6월 29일·2분 읽기큐레이션 요약

보안 권고 데이터베이스의 내부와 취약점 수가 기록을 경신할 때 벌어지는 일

Madison Ficorilli는 취약점 투명성 분야의 전문가로, GitHub에서 보안 관리자로 활동하며 자문 데이터베이스 큐레이션 팀을 이끌고 있습니다. 취약점 신고·대응·공개에 깊이 관여하며, OpenSSF와 CVE 프로그램에서도 관련 표준과 생태계 발전에 기여하고 있습니다. 그녀의 전문성은 GitHub와 카네기멜런대학교 SEI CERT에서의 사고 대응 및 취약점 조정 경험을 바탕으로 합니다. ### GitHub에서의 역할 - GitHub의 시니어 보안 관리자로 근무합니다. - 보안 권고 데이터베이스의 큐레이션 팀을 이끌고 있습니다. - 취약점 정보가 정확하고 일관되게 정리·공개되도록 관리합니다. ### 취약점 투명성과 공개 - 취약점 신고, 대응, 공개 절차의 개선을 주요 관심사로 삼고 있습니다. - 보안 취약점 정보를 투명하게 공유해 사용자와 오픈소스 생태계가 효과적으로 대응하도록 돕습니다. - 관련 오픈소스 보안 커뮤니티에서 협업과 표준화에 참여합니다. ### 오픈소스 및 CVE 생태계 기여 - Open Source Security Foundation(OpenSSF)의 관련 워킹 그룹 공동 의장으로 활동합니다. - CVE 프로그램 이사회 구성원으로서 취약점 식별자와 공개 체계의 발전에 관여합니다. - 기술적 대응뿐 아니라 취약점 관리 정책과 거버넌스에도 기여합니다. ### 이전 경력과 전문성 - GitHub에서 제품 사고 대응 분석가로 일하며 보안 사고 대응 경험을 쌓았습니다. - 카네기멜런대학교 소프트웨어공학연구소(SEI)의 CERT Coordination Center에서 취약점 조정 업무를 담당했습니다. - 이러한 경험을 통해 취약점 발견부터 조정, 대응, 공개까지 전 과정을 이해하고 있습니다. 그녀의 경력은 개별 기업의 보안 대응과 국제적인 취약점 공개 체계를 연결하는 데 초점을 둡니다.ીએમ

원문 읽기(새 탭에서 열림)

githubvulnerability-managementincident-responsecve+2

github·2026년 6월 26일·3분 읽기큐레이션 요약

Hubber로서 전환하기

GitHub의 Arthur Searle은 회사의 핸들 중심 문화와 원격 근무 환경, 성별 확정 의료 지원 덕분에 직장에서 비교적 안전하고 자연스럽게 트랜지션할 수 있었다고 말합니다. 이름·대명사 변경 과정의 행정적 마찰은 있었지만, 동료들의 존중과 지지를 통해 자신의 정체성으로 일하는 기쁨을 경험했습니다. 이 글은 트랜스젠더 구성원이 직장에서 겪는 어려움뿐 아니라, 포용적인 환경이 만들어내는 안도감과 기쁨도 함께 보여줍니다. ## IT 지원에서 보안 엔지니어로 - Arthur는 IT 지원과 운영 업무로 커리어를 시작한 뒤, 독학으로 코딩을 배웠습니다. - 동료의 추천으로 GitHub에 입사해 IT Engineering 팀에서 근무했습니다. - 보안 관련 문제와 풀 리퀘스트를 여러 보안 팀에 지속적으로 제기한 결과, 6개월 만에 Enterprise Security 팀으로 이동했습니다. - 주요 SaaS 플랫폼의 인프라를 코드로 이전하는 작업에 참여했고, 옥스퍼드대학교에서 버전 관리 관련 강연도 진행했습니다. ## 핸들 중심 문화가 만든 정체성의 연속성 - 입사 당시 법적 이름은 Ursula였지만, 온라인 핸들은 계속 `gleeblezoid`였습니다. - GitHub의 원격 중심 문화에서는 실명보다 핸들을 자주 사용하기 때문에, 이름을 바꾸더라도 기존의 업무 정체성과 관계를 유지하기 쉬웠습니다. - 다른 회사처럼 모든 사람이 외모와 실명만으로 서로를 식별하는 환경이었다면 트랜지션 과정이 더 어려웠을 것이라고 설명합니다. - 내부 시스템에서 이름과 대명사를 업데이트한 뒤, 대부분의 동료가 자연스럽게 새 이름을 사용했습니다. ## 의료 지원과 원격 근무의 장점 - GitHub는 직원 모두에게 성별 확정 의료와 관련된 복지 혜택을 제공합니다. - Arthur는 해당 혜택으로 다음과 같은 비용을 지원받을 수 있었다고 말합니다. - 음성 훈련 - HRT 처방약 - 상담 및 치료 - 원격 근무 덕분에 출근 복장이나 이동 중 다른 사람의 시선에 대해 걱정할 필요가 적었습니다. - 업무 소통 대부분이 Slack과 GitHub에 글로 남기 때문에, 음성 훈련이나 HRT로 목소리가 변하는 시기에 하루 종일 직접 말해야 하는 부담도 줄었습니다. - 만화 캐릭터 아바타처럼 외모와 성별 표현에서 자유로운 문화 역시 불필요한 추측과 판단을 줄였습니다. ## 직장에서 트랜스젠더로 살아가는 현실 - Arthur는 직장에서 커밍아웃하지 못하거나, 이름 변경 과정에서 행정적 문제를 겪는 트랜스젠더 동료들을 알고 있다고 말합니다. - 새로운 사람을 만날 때마다 자신의 정체성을 반복해서 설명해야 하는 경우도 있습니다. - 본인은 급여 시스템 등에서 법적 이름을 바꾸는 행정 절차를 제외하면 비교적 순조롭게 트랜지션할 수 있었습니다. - 동료들은 그를 특별히 다르게 대하지 않고, 원하는 이름과 대명사를 사용하며 일반적인 동료로 존중했습니다. ## 지지와 긍정적인 감정 - 트랜스젠더로 살아가는 일이 항상 쉽거나 사회적으로 받아들여지는 것은 아니지만, 경험이 고난만으로 정의되는 것은 아니라고 강조합니다. - 직장에서 처음 자신의 이름을 듣고 남성 대명사로 불렸을 때 큰 감동을 느꼈습니다. - 한 동료가 면도 키트를 보내준 일처럼, 동료들의 작은 배려가 강한 소속감과 기쁨을 만들었습니다. - 동료들은 Arthur와 관련된 농담과 밈을 공유하며 그의 트랜지션을 진심으로 축하하고 지지했습니다. - 그는 “항상 남성이었지만, 남성으로 살아가고 사회에 참여할 시간과 지원이 필요했다”고 말하며 글을 마무리합니다. 기업이 트랜스젠더 구성원을 지원하려면 의료비 보장뿐 아니라 이름·대명사 변경 절차, 원격·비동기 소통, 외모에 대한 판단을 줄이는 문화까지 함께 마련해야 합니다. 궁극적으로 중요한 것은 트랜지션을 특별한 사건으로만 다루지 않고, 구성원이 원하는 정체성으로 존중받으며 평범하게 일할 수 있도록 하는 것입니다.

원문 읽기(새 탭에서 열림)

githubslackversion-controlinfrastructure-as-code+3

github·2026년 6월 25일·4분 읽기큐레이션 요약

모델과 작업별 GitHub Copilot 에이전틱 하니스의 성능 및 효율성 평가

GitHub은 모델 자체의 지능뿐 아니라 도구·컨텍스트·작업 흐름을 조율하는 에이전틱 하니스(harness)가 실제 성능을 좌우한다고 주장합니다. 동일한 모델과 작업을 기준으로 비교한 결과, GitHub Copilot 하니스는 모델 제공업체의 하니스와 비슷한 작업 해결률을 유지하면서 대부분 더 적은 토큰을 사용하는 것으로 나타났습니다. 따라서 하나의 하니스를 개선하면 Copilot CLI, 앱, 코드 리뷰, IDE 등 여러 제품 경험이 함께 향상된다는 결론입니다. ## 에이전틱 하니스의 역할 - 모델은 기본적인 추론 능력을 제공하지만, 하니스가 그 능력을 실제 작업에 적용하는 방식을 결정합니다. - 하니스는 다음 요소를 조율합니다. - 사용할 도구 - 모델에 제공할 컨텍스트 - 작업 실행 순서와 워크플로 - 메모리 및 MCP 서버 활용 - GitHub Copilot의 하니스는 Copilot SDK의 공통 구성 요소입니다. - Copilot CLI, Copilot 앱, Copilot 코드 리뷰, VS Code·Xcode 등 다양한 GitHub 및 Microsoft 경험에서 공유됩니다. - GitHub은 좋은 하니스의 조건으로 빠른 속도, 낮은 토큰 사용량, 예측 가능성을 제시합니다. ## 벤치마크 비교 방법 - 공개 벤치마크와 GitHub·Microsoft 대규모 코드베이스에서 도출한 내부 벤치마크를 함께 사용합니다. - 통제된 실험 결과를 실제 사용 지표와 온라인 실험으로 보완합니다. - 비교 시 다음 조건을 동일하게 맞췄습니다. - 같은 모델 - 같은 벤치마크 작업 - 동일하게 정규화한 컨텍스트 윈도우 - 동일한 추론 수준 - 동일한 도구 선택 및 MCP 서버 - 비교 대상은 다음과 같습니다. - GitHub Copilot CLI - Claude 모델의 기본 하니스인 Claude Code - GPT 모델의 기본 하니스인 Codex CLI - 평가 모델은 Claude Sonnet 4.6, Claude Opus 4.7, GPT-5.4, GPT-5.5입니다. ## 사용한 벤치마크 - **SWE-bench Verified** - 오픈소스 Python 저장소의 사람이 검증한 버그 수정 500개 - 코딩 에이전트의 대표적인 산업 표준 벤치마크 - **SWE-bench Pro** - 여러 단계의 추론과 광범위한 코드 변경이 필요한 어려운 작업 - 실제 소프트웨어 엔지니어링에 가까운 복잡한 문제를 평가 - **SkillsBench** - 에이전트가 스킬을 얼마나 효과적으로 사용하고 호출하는지 평가 - **TerminalBench** - 개발자가 사용하는 명령줄·터미널 기반 작업 수행 능력 측정 - **Win-Hill** - Windows 컨테이너에서 실행되는 내부 벤치마크 - 운영체제와 실행 환경이 달라져도 성능이 유지되는지 검증 ## 토큰 효율 - 동일한 모델과 작업을 사용했을 때 Copilot 하니스는 대부분의 설정에서 더 적은 토큰을 소비했습니다. - 토큰 사용량이 줄었음에도 전반적인 작업 완료율은 다른 모델 제공업체 하니스와 비슷한 수준이었습니다. - Claude Sonnet 4.6과 Opus 4.7에서는 Copilot CLI가 비교된 모든 사례에서 더 나은 결과를 보였습니다. - GPT-5.4와 GPT-5.5에서도 대부분 Copilot CLI가 우세했지만, SWE-bench Verified에서는 각각 7%, 4% 낮은 성능을 기록했습니다. - 단순히 비용을 줄이는 것이 아니라, 작업 해결 능력을 유지하면서 토큰 소비를 낮추는 것이 핵심입니다. ## 작업 해결률 - 전체적으로 Copilot 하니스의 작업 해결률은 모델 제공업체 하니스와 대등했습니다. - SWE-bench Verified에서는: - Sonnet 4.6과 Opus 4.7에서 Copilot CLI가 더 높은 해결률을 보였습니다. - GPT-5.4와 GPT-5.5에서는 더 낮았습니다. - SWE-bench Pro에서는: - Sonnet 4.6에서만 Copilot CLI가 소폭 낮았습니다. - 나머지 모델에서는 더 나은 성능을 보였습니다. - SkillsBench에서는 Claude 모델에서 낮았지만 GPT 모델에서는 더 높았습니다. - Win-Hill에서는 모든 모델에서 같거나 더 나은 결과를 기록했습니다. - TerminalBench 2에서는: - Sonnet 4.6과 Opus 4.7에서 더 높았습니다. - GPT-5.5에서는 동률이었습니다. - GPT-5.4에서는 더 낮았습니다. - 저자들은 모델의 확률적 특성으로 인한 실행별 변동을 고려하면 이러한 차이는 실질적으로 “동등한 수준”이라고 해석합니다. ## 실행별 변동성과 비용 분석 - TerminalBench 2.0을 사용해 작업 해결률뿐 아니라 작업당 비용과 실행별 변동도 분석했습니다. - 벤치마크 결과는 한 번의 실행만으로 하니스 성능을 판단하기 어렵다는 점을 보여줍니다. - 같은 에이전트와 모델 조합도 실행마다 결과가 달라질 수 있습니다. - 평가에서는 더 많은 작업을 해결하면서 비용을 적게 쓰는 구성이 더 좋은 것으로 간주합니다. - Copilot CLI는 이러한 분석에서 모델 제공업체 하니스와 비교해 같거나 더 나은 해결률·토큰 효율을 보였습니다. ## 실용적인 의미 - 모델을 선택할 때 모델의 벤치마크 점수만 보지 말고 하니스의 도구 사용, 컨텍스트 관리, 토큰 효율도 함께 평가해야 합니다. - 여러 모델을 한 제품에서 사용해야 한다면, 특정 모델에 종속되지 않으면서 성능을 유지하는 공통 하니스가 유리합니다. - 실제 도입 전에는 SWE-bench 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

원문 읽기(새 탭에서 열림)

대규모 언어 모델AI 에이전트모델 컨텍스트 프로토콜github-copilot+3

github·2026년 6월 23일·2분 읽기큐레이션 요약

내 일을 자동화했더니 (더 나은 리더가 되었다)

Ashley Willis는 GitHub의 개발자 관계 부문을 이끄는 수석 디렉터로, 오픈소스와 개발자 커뮤니티를 중심으로 활동하고 있습니다. 기술을 더 인간적으로 만들고, 기여자를 지원하며, 소외된 목소리를 대변하는 리더십을 강조합니다. 또한 접근성과 회복력 있는 팀 구축을 통해 실제 사용자에게 도움이 되는 도구와 환경을 만드는 데 집중합니다. ### 개발자 관계와 오픈소스 리더십 - GitHub에서 개발자 관계(Developer Relations) 조직을 이끕니다. - 오픈소스 생태계와 커뮤니티에 대한 깊은 관심을 바탕으로 활동합니다. - 개발자의 참여와 기여를 촉진하는 환경을 만드는 데 주력합니다. ### 커뮤니티와 기여자 지원 - 기술을 사용하는 사람들의 경험을 중심에 둔 활동을 펼칩니다. - 오픈소스 기여자를 지원하고, 다양한 개발자들의 목소리를 확대합니다. - 기술 커뮤니티가 더 포용적이고 지속 가능하게 성장하도록 돕습니다. ### 포용성, 접근성, 팀의 회복력 - 소외되거나 충분히 대표되지 못한 집단의 목소리를 강조합니다. - 누구나 사용할 수 있는 접근성 높은 도구와 공간을 만드는 데 관심을 둡니다. - 변화와 어려움에 대응할 수 있는 회복력 있는 팀 문화를 구축합니다. ### 기술을 더 인간적으로 만들기 - 리더십과 기술 옹호 활동을 사람 중심의 관점에서 결합합니다. - 단순히 기능적인 도구를 넘어, 실제 사용자의 필요를 충족하는 기술을 지향합니다. - 개발자와 커뮤니티를 배려하는 태도를 기술 조직 운영의 핵심 가치로 삼습니다. 결국 이 글은 Ashley Willis를 기술 전문성뿐 아니라 사람, 커뮤니티, 포용성을 중시하는 개발자 관계 리더로 소개합니다. 기술 조직은 제품 개발과 함께 기여자 지원, 접근성, 다양한 목소리의 반영도 함께 고려해야 한다는 점을 시사합니다.

원문 읽기(새 탭에서 열림)

오픈 소스접근성githubdeveloper-relations

github·2026년 6월 19일·4분 읽기큐레이션 요약

내부 데이터 분석 에이전트를 구축한 방법

GitHub는 사내 데이터 웨어하우스에 자연어로 질문하면 SQL을 작성하고 결과를 해석해 주는 GitHub Copilot 기반 분석 에이전트 ‘Qubot’을 구축했다. Qubot은 대시보드나 정기 리포트의 대체재가 아니라, 데이터 모델·필터·쿼리 작성법을 몰라도 탐색적 분석을 수행하도록 돕는 도구다. 핵심 성공 요인은 데이터에 대한 구조화된 컨텍스트와 자동화된 평가 체계이며, 이를 통해 분석 정확도뿐 아니라 응답 속도도 크게 향상됐다. ## Qubot의 목적과 활용 범위 - GitHub의 여러 제품·엔지니어링 팀이 데이터 분석가의 도움 없이 제품 텔레메트리를 활용하도록 지원한다. - 사용자는 다음과 같은 탐색적 질문을 자연어로 입력할 수 있다. - 특정 기능의 유지율이 가장 높은 사용자 코호트는 무엇인가? - 지난주 특정 지표의 변화에 가장 큰 영향을 준 제품은 무엇인가? - 정기 보고서나 대시보드를 대체하지 않고, 데이터셋을 빠르게 이해하고 가설을 검증하는 데 초점을 둔다. - 데이터 분석 지원 요청을 줄이고, 데이터 웨어하우스를 사용해 본 적이 적은 직원도 의사결정에 필요한 데이터를 직접 탐색할 수 있게 한다. ## 세 가지 핵심 구성 요소 Qubot은 사용자 인터페이스, 컨텍스트 계층, 쿼리 엔진으로 구성된다. - **사용자 인터페이스** - Slack, VS Code, Copilot CLI에서 사용할 수 있다. - Slack에서는 채널에 질문을 올리면 GitHub.com에서 Copilot Cloud Agent가 실행된다. - 답변은 Slack에 바로 게시되며, 스레드에서 질문을 추가로 구체화할 수 있다. - 분석 결과는 Markdown 보고서로 작성되어 Pull Request에 저장된다. - VS Code와 Copilot CLI에서는 플러그인 설치 후 다른 에이전트·스킬·도구와 함께 사용할 수 있다. - **컨텍스트 계층** - 데이터의 관리 수준에 따라 서로 다른 정보를 제공한다. - Bronze 데이터에는 제품 팀이 제공한 이벤트 스키마와 메타데이터가 포함된다. - Silver 데이터에는 예시 쿼리, 사용 지침, 필수 필터 등이 포함된다. - Gold 데이터에는 해당 데이터셋을 소유한 팀이 정의한 비즈니스 규칙과 지표 정의가 포함된다. - ETL 파이프라인이 추가 신호와 파생 메타데이터를 자동으로 보강한다. - 에이전트는 실행 시점에 GitHub MCP Server를 통해 필요한 컨텍스트를 가져온다. - **쿼리 엔진** - GitHub의 주요 분석 엔진인 Kusto와 Trino를 MCP 서버로 연결한다. - Kusto는 최근 이벤트 데이터를 빠르게 탐색하는 데 적합하다. - Trino는 복잡한 조인과 장기간의 이력 분석에 적합하다. - 사용자가 엔진을 직접 선택하지 않아도 Qubot이 기본적으로 Kusto를 사용하고, 복잡한 질문에는 Trino로 자동 전환한다. ## 컨텍스트 에이전트와 지식 관리 - 컨텍스트 정보는 여러 저장소에 Markdown 형태로 관리된다. - 팀은 표준 템플릿을 사용하거나 관련 컨텍스트가 있는 저장소를 참조해 지식을 기여할 수 있다. - 컨텍스트 에이전트가 정보를 수집한 뒤 정리·정규화해 Qubot이 활용하기 쉬운 구조로 변환한다. - 데이터 모델 자체보다 데이터의 의미, 올바른 필터, 지표 정의, 사용 사례를 함께 제공하는 것이 에이전트의 분석 품질을 높이는 핵심이다. ## 자동화된 평가 프레임워크 - 컨텍스트나 에이전트 설정이 변경될 때마다 배포 전에 오프라인 평가를 수행한다. - 평가 대상은 정확도뿐 아니라 적절한 답을 찾는 데 걸리는 시간과 기존 기능의 회귀 여부다. - 평가 프레임워크는 다음 세 부분으로 구성된다. - **테스트 케이스**: 정답, 기준 SQL, 도메인, 난이도를 포함한 표준 질문 집합 - **실행 오케스트레이션**: GitHub CLI의 `gh agent-task create`를 이용해 테스트를 병렬 실행하고 JSON 결과를 저장 - **통계 집계**: 테스트별 완료율, 정확도, 평균·최소·최대 소요 시간을 계산 - 전체 과정은 테스트 정의 → 여러 차례 실행 → 결과 수집 → 통계 집계 → 설정 비교 순서로 진행된다. - 이를 통해 컨텍스트 추가나 에이전트 변경이 실제 품질 향상으로 이어지는지 검증할 수 있다. ## 도입 효과와 핵심 교훈 - Qubot은 수백 명의 사용자가 수천 건의 쿼리를 실행할 정도로 확산됐다. - 데이터·분석 Slack 채널에 반복적으로 들어오던 질문이 크게 줄었다. - 사용자는 간단한 질문을 직접 해결하고, 분석 전문가는 더 복잡한 문제에 집중할 수 있게 됐다. - Slack, VS Code, Copilot CLI를 함께 제공해 기술 수준과 업무 방식에 따른 진입 장벽을 낮췄다. - 실험 결과, 잘 구조화되고 큐레이션된 컨텍스트는 Qubot의 정확도를 높였을 뿐 아니라 올바른 답을 반환하는 속도도 약 3배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)

AI 에이전트모델 컨텍스트 프로토콜slackgithub-copilot+4