GitHub

88 개의 포스트

github.blog/engineering

태그로 필터

github4분 읽기큐레이션 요약

각 토큰에서 더 많은 것을 얻기: Copilot이 컨텍스트 처리와 모델 라우팅을 개선하는 방법

GitHub Copilot은 에이전트형 작업이 길어질수록 단순히 토큰을 줄이는 것이 아니라, 반복되는 컨텍스트와 도구 정의를 효율적으로 재사용하고 작업에 맞는 모델을 선택해야 한다고 설명합니다. 이를 위해 VS Code에서는 프롬프트 캐싱과 지연된 도구 로딩을 개선하고, Auto 기능은 작업 난이도와 실시간 모델 상태를 바탕으로 적절한 모델로 라우팅합니다. 목표는 품질을 유지하면서 불필요한 비용과 지연을 줄이는 것입니다. ## 프롬프트 캐싱과 지연된 도구 로딩 - 긴 Copilot 세션에는 지침, 저장소 컨텍스트, 대화 기록, 도구 목록, 작업 상태 등 반복적으로 전달되는 정보가 많습니다. - **프롬프트 캐싱**은 반복되는 프롬프트 접두부의 모델 상태를 재사용해 매 요청마다 같은 내용을 다시 계산하지 않도록 합니다. - **도구 검색(tool search)**은 모든 도구의 전체 스키마를 처음부터 컨텍스트에 포함하지 않고, 모델이 필요할 때 관련 도구 정의만 불러옵니다. - MCP 도구, 터미널, 파일 조작, 워크스페이스 검색 등 도구가 많아질수록 이 방식의 효과가 커집니다. - 사용 가능한 도구의 범위는 넓게 유지하면서도, 현재 작업과 무관한 도구 정의가 매 턴마다 차지하는 토큰 비용을 줄일 수 있습니다. ## 작업별 모델 자동 선택 - Auto는 “현재 작업에 어떤 모델이 가장 적합한가?”를 자동으로 판단합니다. - 빠른 설명, 특정 파일의 간단한 수정, 여러 파일에 걸친 복잡한 변경은 요구되는 추론 수준이 서로 다르므로 동일한 모델을 사용할 필요가 없습니다. - 평가 결과 모든 작업에서 항상 최고 성능을 내는 단일 모델은 없었습니다. - 효율적인 모델이 더 적은 비용으로 같은 결과를 내는 경우가 많지만, 복잡한 추론이나 디버깅에서는 강력한 모델이 더 유리합니다. - Auto는 필요할 때만 더 강한 모델로 전환하고, 단순한 작업에는 효율적인 모델을 사용해 품질과 비용 사이의 균형을 맞춥니다. ## Auto의 라우팅 기준 Auto는 모델의 현재 상태와 작업의 특성이라는 두 가지 신호를 함께 사용합니다. - **실시간 모델 상태** - 모델의 가용성, 사용률, 응답 속도, 오류율, 비용을 동적으로 추적합니다. - 성능이 좋은 모델이라도 현재 과부하 상태이거나 응답 오류가 많다면 최적의 선택이 아닐 수 있습니다. - 따라서 작업을 처리할 능력뿐 아니라 현재 안정적으로 응답할 수 있는지도 고려합니다. - **HyDRA 기반 작업 인식 라우팅** - HyDRA는 추론 깊이, 코드 복잡도, 디버깅 난이도, 도구 오케스트레이션 필요성 등을 분석합니다. - 먼저 해당 작업의 품질 기준을 충족할 수 있는 모델들을 선별한 뒤, 그중 가장 적합한 모델을 선택합니다. - 게시글의 평가에서는 HyDRA가 품질과 비용 절감 수준을 조정할 수 있음을 보여줍니다. - 한 운영 지점에서는 Sonnet보다 높은 성능을 내면서 12.9% 비용을 절감했고, 다른 운영 지점에서는 품질을 균형 있게 유지하며 72.5%를 절감했습니다. - SWE-bench 평가에서 보수적 설정은 70.8% 해결률로 OpenRouter Auto와 동률을 기록하면서 3.3배 높은 절감 효과를 보였습니다. ## 캐시를 고려한 모델 전환 - 매 턴마다 모델을 바꾸면 유연성은 높아지지만, 기존 프롬프트 캐시가 깨져 오히려 비용이 증가할 수 있습니다. - 같은 모델을 계속 사용하면 대화의 프롬프트 접두부를 여러 턴에 걸쳐 재사용할 수 있습니다. - Auto는 다음과 같은 **자연스러운 캐시 경계**에서 주로 모델을 다시 선택합니다. - 첫 번째 요청: 아직 재사용할 캐시가 없는 시점 - 컨텍스트 압축(compaction) 이후: 이전 대화를 요약하면서 프롬프트 접두부가 초기화된 시점 - 그 사이에는 선택된 모델을 유지해 캐시가 축적되도록 합니다. - 즉, 모델 라우팅 자체의 이득뿐 아니라 모델 전환으로 발생하는 캐시 손실까지 함께 계산합니다. ## 여러 언어를 지원하는 라우팅 - Copilot은 영어뿐 아니라 다양한 언어로 사용되므로 라우팅 모델도 다국어 환경에서 작동해야 합니다. - 라우팅 모델은 CJK, 유럽 언어권 등을 포함한 16개 언어군의 대화 데이터로 학습되었습니다. - 19개 언어에서 추출한 VS Code Chat 텔레메트리 평가에서 언어군별 라우팅 정확도는 영어 기준선과 4포인트 이내의 차이를 보였습니다. - 언어군 사이에 통계적으로 유의미한 품질 격차도 나타나지 않았습니다. Copilot의 효율성을 높이려면 모든 정보를 매번 다시 보내거나 모든 작업에 가장 큰 모델을 사용하는 대신, 반복 컨텍스트는 캐시하고 도구는 필요할 때 불러오며 작업 난이도에 맞는 모델을 선택하는 것이 효과적입니다. 특히 긴 에이전트 세션에서는 모델 전환으로 캐시가 손실되지 않도록 하는 전략이 비용과 응답 속도 모두에 중요합니다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

Git worktree란 무엇이며, 왜 사용해야 할까요?

Git worktree는 하나의 저장소에서 여러 작업 디렉터리를 동시에 운영하게 해 주는 기능으로, 브랜치 전환과 `git stash` 없이 여러 작업을 병렬로 진행할 수 있게 한다. 특히 AI 에이전트와 개발 세션을 동시에 실행하는 환경에서 각 작업의 맥락을 보존하고 전환 비용을 줄여 주기 때문에 최근 주목받고 있다. 다만 의존성 저장 공간, 디렉터리 정리, 동일 브랜치 중복 체크아웃 등의 관리 부담은 남아 있다. ## 브랜치 전환과 `git stash`의 부담 - 기존 방식에서는 긴급한 버그를 처리하기 위해 현재 작업을 먼저 임시 저장해야 한다. ```bash git stash "wip feature login" ``` - 이후 `main` 브랜치로 이동하고 최신 변경 사항을 받은 뒤, 별도의 핫픽스 브랜치를 생성한다. ```bash git checkout main git pull origin main git checkout -b hotfix-bug ``` - 수정·커밋·푸시·병합이 끝나면 다시 원래 브랜치로 돌아가 `stash pop`을 실행한다. - 이 과정에서 다음과 같은 비용이 발생한다. - 작업 파일과 에디터 상태를 반복해서 다시 로드해야 함 - 변경된 의존성에 따라 `node_modules` 등을 재설치할 수 있음 - 복잡한 stash 충돌이 발생할 수 있음 - 현재 작업의 맥락을 잃기 쉬움 - 일부 개발자는 이를 피하기 위해 같은 저장소를 여러 번 clone하기도 하지만, 저장 공간과 관리 부담이 커진다. ## Worktree를 이용한 병렬 작업 - `git worktree add`를 사용하면 기존 작업 디렉터리를 그대로 둔 채 별도의 디렉터리에서 다른 브랜치를 체크아웃할 수 있다. ```bash git worktree add ../hotfix-workspace -b hotfix-bug main ``` - 이 명령은 다음 작업을 한 번에 수행한다. - 기존 프로젝트 옆에 `hotfix-workspace` 디렉터리 생성 - `main`을 기반으로 `hotfix-bug` 브랜치 생성 - 새 디렉터리에서 해당 브랜치 체크아웃 - 원래 에디터 창과 feature 브랜치의 파일 상태는 그대로 유지된다. - 새 디렉터리에서 독립적으로 수정하고 커밋·푸시할 수 있다. ```bash cd ../hotfix-workspace git add . git commit -m "fix broken submit button" git push origin hotfix-bug ``` - 작업이 끝나면 임시 worktree를 제거한다. ```bash cd ../main-project git worktree remove ../hotfix-workspace ``` - 따라서 stash 충돌 없이 여러 작업을 동시에 진행하고, 각 작업의 에디터와 파일 맥락을 보존할 수 있다. - VS Code 등 일부 개발 도구는 worktree를 직접 지원한다. ## Worktree가 최근 주목받는 이유 - Git worktree 자체는 2015년부터 존재했지만, 오랫동안 일반 개발자에게 널리 알려지지는 않았다. - 과거에는 대부분 다음과 같은 단순한 흐름을 사용했다. - feature 브랜치 생성 - 작업 - Pull Request 생성 - 병합 - 다음 작업 시작 - Git GUI가 worktree를 제대로 지원하지 않거나 부가 기능처럼 취급한 점도 확산을 막았다. - 최근에는 AI 도구와 에이전트가 여러 개발 세션을 동시에 실행하면서 병렬 작업이 크게 증가했다. - 코드 작성뿐 아니라 코드 리뷰와 자동화 작업도 병렬로 진행되면서, 세션마다 독립적인 작업 공간을 제공하는 worktree가 적합해졌다. - GitHub Copilot 앱을 비롯한 최신 개발 도구에서는 worktree가 기본 실행 방식으로 사용되기도 한다. ## Worktree 사용 시 주의점 - **의존성 저장 공간 증가** - 각 worktree가 프로젝트 의존성을 별도로 설치하면 `node_modules`나 Python 패키지가 반복 저장된다. - 여러 worktree를 동시에 사용하면 디스크 공간이 빠르게 줄어들 수 있다. - **디렉터리 정리 필요** - 작업이 끝난 worktree를 직접 삭제하지 않으면 부모 디렉터리에 임시 폴더가 계속 쌓인다. - 일부 앱은 이를 자동으로 처리하지만, 터미널 사용 시 직접 관리해야 한다. - **`.gitignore` 설정** - 저장소 내부에 worktree를 만들 경우 해당 폴더가 실수로 추적되지 않도록 `.gitignore`에 추가해야 한다. - 저장소 외부에 worktree를 생성하면 이 문제를 줄일 수 있다. - **동일 브랜치 중복 체크아웃 제한** - Git은 데이터 손상을 막기 위해 같은 브랜치를 여러 worktree에서 동시에 체크아웃하지 못하게 한다. ## GitHub Copilot 앱에서의 사용 - 새 세션을 만들 때 실행 위치를 선택할 수 있으며, 기본값으로 새 worktree를 사용할 수 있다. - 세션을 시작하면 앱에서 다음 정보를 확인할 수 있다. - 생성된 worktree 이름 - worktree의 경로 - 연결된 프로젝트 - 해당 worktree에서 발생한 변경 사항 - 사용자가 직접 Git 명령을 관리하지 않아도 병렬 세션을 쉽게 만들고 정리할 수 있다는 점이 장점이다. ## 상황에 따른 선택 - 작업을 자주 병렬로 진행하거나 AI 에이전트를 여러 개 실행한다면 worktree가 특히 유용하다. - 단일 작업을 순차적으로 처리하고 기존 브랜치·stash 방식이 익숙하다면 반드시 전환할 필요는 없다. - 두 방식을 함께 사용하면서 작업 유형에 따라 선택하는 것도 가능하다. - 병렬 작업이 많은 팀이나 개발자는 worktree를 도입하되, 의존성 공유와 임시 디렉터리 정리 전략을 함께 마련하는 것이 좋다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

초보자를 위한 GitHub Copilot CLI: 자주 사용하는 슬래시 명령어 개요

GitHub Copilot CLI의 슬래시 명령은 모델 선택, 컨텍스트 관리, 세션 재개, 변경 사항 확인 등을 터미널에서 직접 수행하게 해주는 핵심 제어 기능이다. `/`를 입력하면 사용 가능한 명령 목록을 확인할 수 있으며, 각 명령을 익히면 작업 흐름과 권한을 더 효율적으로 관리할 수 있다. 특히 모델과 토큰 사용량을 상황에 맞게 조절하면 속도와 결과 품질을 균형 있게 유지할 수 있다. ## 슬래시 명령의 역할 - 슬래시 명령은 Copilot CLI에 내장된 제어 기능이다. - Copilot의 동작을 지시하고, 변경 사항과 컨텍스트를 확인하며, 세션과 프로젝트를 관리한다. - 터미널에서 `/`를 입력하면 현재 지원되는 명령을 스크롤 목록으로 확인할 수 있다. ## 작업에 맞는 모델 선택: `/model` - `/model`을 입력하면 사용 가능한 모델 목록이 표시된다. - 모델마다 적합한 작업이 다르다. - 간단한 리팩터링이나 빠른 작업에는 가벼운 모델이 적합하다. - 기능 설계나 복잡한 추론에는 더 강력한 모델이 유리하다. - 모델 목록은 사용 중인 요금제나 조직 설정에 따라 달라질 수 있다. - 각 모델 옆의 비용 배수는 사용량과 비용 수준을 비교하는 기준이 된다. - 작업의 복잡도와 속도, 비용을 고려해 모델을 선택해야 한다. ## 컨텍스트와 토큰 관리 ### 현재 사용량 확인: `/context` - `/context`는 현재 세션의 컨텍스트 사용량을 보여준다. - 남은 토큰 수, 시스템이 사용하는 공간, 추가로 활용 가능한 버퍼를 확인할 수 있다. - 컨텍스트 창이 가득 차면 Copilot이 이전 대화와 정보를 충분히 참고하기 어려워진다. ### 대화 압축: `/compact` - `/compact`는 현재 대화를 요약해 컨텍스트 공간을 확보한다. - 기존 세션을 유지하면서 새로운 작업으로 넘어갈 때 유용하다. - 컨텍스트 한도에 가까워지면 Copilot CLI가 자동으로 압축할 수 있지만, 사용자가 직접 실행할 수도 있다. ### 세션 초기화: `/clear` - `/clear`는 현재 세션을 완전히 지운다. - 이전 대화의 영향을 받지 않고 새로운 작업을 시작할 때 사용한다. ## 이전 세션 재개: `/resume` - `/resume`은 과거에 진행한 세션 목록을 표시한다. - 로컬 세션과 원격 세션을 모두 확인할 수 있다. - 세션을 선택하면 이전 작업 기록을 검토한 뒤 중단한 지점부터 작업을 이어갈 수 있다. ## 변경 사항 확인: `/diff` - `/diff`는 현재 세션에서 발생한 최근 변경 사항을 보여준다. - Copilot이 수정한 파일을 검토하고, 의도하지 않은 변경이 없는지 확인하는 데 사용한다. - 변경 내용을 검증한 뒤 커밋이나 다음 작업으로 넘어가는 것이 좋다. ## 작업 디렉터리 변경: `/cwd` - `/cwd`를 사용하면 Copilot을 종료하지 않고 다른 저장소나 디렉터리로 이동할 수 있다. - 여러 프로젝트를 오가며 작업할 때 편리하다. - Copilot의 작업 범위를 현재 선택한 프로젝트에 맞게 조정할 수 있다. ## 도구 권한 초기화: `/reset-allowed-tools` - `/reset-allowed-tools`는 이전에 허용한 파일 수정 등의 도구 권한을 초기화한다. - 신뢰 수준이 다른 저장소로 이동했을 때 기존 권한을 재설정하는 데 유용하다. - 민감한 프로젝트를 다룰 때 권한을 다시 확인하는 안전 장치로 활용할 수 있다. ## 실용적인 활용 방법 - 작업을 시작하기 전에 `/`를 입력해 사용 가능한 명령을 확인한다. - 복잡한 기능 설계에는 `/model`로 추론 능력이 높은 모델을 선택한다. - 컨텍스트가 부족해지면 `/context`로 상태를 확인하고 `/compact`를 실행한다. - Copilot이 코드를 수정한 뒤 `/diff`로 변경 내용을 검토한다. - 다른 프로젝트로 이동할 때는 `/cwd`, 권한을 정리해야 할 때는 `/reset-allowed-tools`를 사용한다. - 슬래시 명령을 익히면 Copilot CLI를 단순한 코드 생성 도구가 아니라 세션·컨텍스트·권한을 통제하는 작업 환경으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

새로운 오픈 데이터셋으로 다국어 AI를 구축하는 연구자와 개발자를 가속화하다

GitHub는 비영어권 개발자 협업을 연구하고 다국어 AI를 개발할 수 있도록 **GitHub Multilingual Repositories Dataset**을 공개했다. 이 데이터셋은 저장소의 README, 가장 많은 댓글이 달린 이슈와 풀 리퀘스트를 분석해 언어 분류와 신뢰도, 저장소 메타데이터를 제공한다. GitHub는 이를 통해 언어별 개발자 커뮤니티의 대표성을 측정하고, 다양한 언어를 지원하는 AI 코딩 도구와 평가 세트를 만들 수 있다고 설명한다. ## 개발자 협업에서 다국어 데이터가 중요한 이유 - 개발자는 README에서 프로젝트 사용법을 설명하고, 이슈에서 문제를 논의하며, 풀 리퀘스트에서 코드를 리뷰한다. - 이러한 협업은 영어 중심으로 이루어지는 경우가 많지만, 실제로는 다양한 언어가 사용된다. - AI 코딩 도구가 개발 과정에 더 깊이 관여할수록, 특정 언어권의 개발자 콘텐츠만 학습·평가하는 방식에는 한계가 있다. - 특히 유럽 언어를 비롯한 일부 언어는 AI 학습 및 평가용 온라인 텍스트에서 상대적으로 부족하다. ## GitHub Multilingual Repositories Dataset의 구성 - 4,000만 개가 넘는 저장소를 대상으로 8,000만 개 이상의 분류 행을 제공한다. - 각 공개 저장소에 대해 다음 텍스트의 언어를 분류한다. - README - 댓글 수가 가장 많은 이슈 - 댓글 수가 가장 많은 풀 리퀘스트 - 각 텍스트에서 처음 150자만 분석하며, 20자 미만인 텍스트는 제외한다. - 다음 세 가지 언어 식별기의 결과를 모두 별도로 제공한다. - fastText - Google CLD3 - lingua-py - 각 분류 결과에는 신뢰도 점수가 포함되며, 신뢰도 0.5 초과인 결과만 수록된다. - 저장소 생성 시각, 디스크 사용량, 별 수, 포크 수, 주요 프로그래밍 언어, SPDX 라이선스, 이슈·풀 리퀘스트 수, 데이터 스냅샷 날짜도 제공한다. - 저장소 본문을 통째로 공개하는 데이터 덤프가 아니라, 다국어 콘텐츠가 있을 가능성이 높은 저장소를 찾기 위한 메타데이터 데이터셋이다. ## 여러 언어 분류기를 함께 제공하는 이유 - 언어 분류기마다 지원 언어, 적용 범위, 신뢰도 보정 방식이 다르다. - 특히 사용자가 적은 언어에서는 분류기별 결과 차이가 커질 수 있다. - GitHub는 세 분류기의 결과를 하나의 최종 언어 라벨로 합치지 않았다. - 사용자는 목적에 따라 정밀도와 재현율을 조절할 수 있다. - 높은 정밀도가 필요하면 세 분류기가 모두 같은 언어를 높은 신뢰도로 판정한 결과만 사용 - 폭넓은 탐색이 필요하면 하나의 분류기 결과만 사용 - 예를 들어 특정 언어의 신뢰도 높은 저장소 집합을 만들거나, 로망스어 계열 저장소를 넓게 탐색할 수 있다. ## 데이터셋으로 할 수 있는 일 - 특정 언어로 작성된 개발 문서나 협업 콘텐츠가 있는 저장소를 검색한다. - 언어별로 이슈, 풀 리퀘스트, README가 어떻게 사용되는지 연구한다. - 다국어 AI 코딩 도구, 문서 생성기, 코드 리뷰 보조 도구의 평가 세트를 만든다. - 언어별 개발자 지원이 부족한 영역을 데이터로 확인하고, 새로운 AI 기능의 언어 지원 확대를 제안한다. - 오픈 소스에서 유럽 언어 및 기타 저자원 언어가 얼마나 대표되는지 측정한다. ## 언어 식별의 한계와 사용상 주의점 - 소프트웨어 저장소의 텍스트는 짧고, 배지·템플릿·설치 명령·코드·사용자 이름이 섞여 있을 수 있다. - 150자의 샘플만으로 저장소 전체의 언어를 정확히 대표하기 어렵다. - 하나의 저장소 안에 여러 언어가 혼용될 수도 있다. - 분류기별 지원 범위와 신뢰도 보정이 다르므로 결과를 언어 식별의 정답 데이터로 간주해서는 안 된다. - 대신 사용자가 분류기별 결과와 신뢰도를 직접 확인하고 연구 목적에 맞는 기준을 설정하도록 설계됐다. - 저장소 수준의 메타데이터이므로 저장소 소유자나 기여자의 민감한 개인 특성을 추론하는 데 사용해서는 안 된다. ## CC0 공개와 향후 방향 - 데이터셋은 GitHub에서 **CC0-1.0** 라이선스로 공개되어 자유롭게 활용할 수 있다. - 연구자, 오픈 소스 유지 관리자, 모델 개발자가 이를 비판·확장하고 평가 세트와 도구를 구축하도록 장려한다. - GitHub는 다국어 개발자 커뮤니티를 더 잘 연구하고 지원하는 기반으로 이 데이터셋을 활용하기를 기대한다. - 궁극적으로 개발자가 실제로 사용하는 언어와 협업 방식을 반영하는 AI 도구를 만드는 것이 목표다. 실제로 활용할 때는 단일 분류 결과를 그대로 믿기보다 여러 분류기의 일치 여부와 신뢰도 기준을 함께 확인하는 것이 좋다. 특히 AI 평가 세트를 만들 때는 샘플을 직접 검수해 언어 혼용, 짧은 텍스트, 코드 포함으로 인한 오분류를 보완해야 한다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

GitHub Copilot CLI가 작업 위임을 더 선별적으로 하도록 만든 방법

GitHub는 Copilot CLI가 단순한 작업까지 불필요하게 서브에이전트에 위임해 발생하던 검색 반복, 도구 실패, 대기 시간을 줄이기 위해 위임 정책을 개선했다. 핵심은 좁고 명확한 작업은 메인 에이전트가 직접 처리하고, 독립적인 탐색·복잡한 조사·병렬 실행이 필요한 경우에만 서브에이전트를 활용하는 것이다. 그 결과 도구 실패가 23% 감소하고 P95 사용자 대기 시간이 5% 줄었으며, 품질 저하 없이 Copilot CLI 전체 트래픽에 적용됐다. ### 서브에이전트 위임은 항상 효율적이지 않다 - 서브에이전트는 복잡한 작업을 분해하고 여러 조사를 병렬로 수행하는 데 유용하다. - 하지만 단순한 파일 수정까지 위임하면 오히려 다음과 같은 비용이 발생한다. - 불필요한 에이전트 간 인계와 조정 - 동일하거나 겹치는 저장소 검색 - 메인 에이전트가 결과를 기다리는 시간 - 오래된 파일 경로, 잘못된 상대 경로, 워크스페이스 불일치에 따른 도구 실패 - 특히 메인 에이전트가 이미 충분한 맥락을 알고 있는데도 탐색 서브에이전트를 실행하면, 서브에이전트가 저장소를 다시 검색하면서 작업이 지연된다. ### 데이터 분석으로 불필요한 위임 패턴 식별 - GitHub는 에이전트의 전체 실행 궤적을 LLM으로 분석해 위임이 실제로 도움이 되는지 확인했다. - 분석 결과, 다음과 같은 작업에 서브에이전트가 과도하게 사용되고 있었다. - 범위가 좁고 명확한 작업 - 필요한 정보가 이미 핸드오프에 포함된 작업 - 파일을 찾고 읽은 뒤 한 곳을 수정하는 작업 - 이를 바탕으로 “간단한 탐색과 수정은 메인 에이전트가 직접 처리한다”는 방향을 개선 목표로 삼았다. ### 좁은 작업은 직접 처리하고 복잡할 때만 위임 - Copilot CLI의 새로운 정책은 가장 간단한 실행 경로에서 시작한다. - 파일 찾기 - 파일 읽기 - 특정 부분 수정 - 변경 사항 검증 - 다음과 같은 경우에는 서브에이전트 위임이 효과적이다. - 익숙하지 않은 대규모 저장소 탐색 - 서로 독립적인 코드 영역 조사 - 장시간 실행되는 명령 수행 - 여러 작업을 동시에 진행할 수 있는 경우 - 작업이 복잡하거나 불확실할 때 위임하고, 다시 작업 범위가 좁아지면 메인 에이전트가 직접 처리하도록 한다. - 서브에이전트는 메인 에이전트를 멈추게 하는 “일시정지 버튼”이 아니라, 독립 작업을 병렬화하는 도구로 사용해야 한다. ### 구체적인 핸드오프와 병렬 실행 - 서브에이전트를 실행할 때는 핸드오프에 다음 내용을 명확히 포함해야 한다. - 사용자가 요청한 전체 목표 - 메인 에이전트가 이미 파악한 정보 - 서브에이전트가 담당할 범위 - 반환해야 하는 결과의 형태 - 메인 에이전트는 서브에이전트의 결과를 기다리기만 하지 않고, 그동안 독립적으로 수행할 수 있는 작업을 계속 진행해야 한다. - 이 방식은 중복 검색과 순차적 대기를 줄이고, 실제로 병렬 처리가 가능한 작업에서 위임의 이점을 높인다. ### 오프라인 평가와 운영 환경 A/B 테스트 - GitHub는 자동 생성 회귀 테스트와 기존 벤치마크를 이용해 정책 변경을 먼저 오프라인에서 검증했다. - 이후 내부 사용자와 공개 사용자를 대상으로 A/B 테스트를 진행했다. - 평가 항목은 다음과 같았다. - 도구 안정성 - 사용자 응답성과 대기 시간 - 서브에이전트 사용량 - 최종 결과 품질 - 성능 향상은 개별 LLM 호출 자체를 빠르게 만든 결과가 아니라, 불필요한 서브에이전트 실행을 줄여 오케스트레이션 비용을 낮춘 결과였다. ### 측정된 개선 효과 - 세션당 도구 실패가 **23% 감소** - 검색 도구 실패: **27% 감소** - 편집 도구 실패: **18% 감소** - 사용자 대기 시간 개선 - P95: **5% 감소** - P75: **3% 감소** - 품질 저하는 관찰되지 않았다. - 개선된 위임 기능은 Copilot CLI 운영 트래픽의 100%에 배포됐다. - 사용자는 `/update` 명령으로 Copilot CLI **1.0.42 이상**으로 업데이트하면 적용된 기능을 사용할 수 있다. 간단한 작업에는 직접 실행을 우선하고, 서브에이전트는 독립성·복잡성·병렬성 때문에 실제 이득이 있을 때만 사용하는 것이 효율적이다. 이를 위해 위임 여부뿐 아니라 핸드오프의 구체성, 메인 에이전트의 병렬 진행 여부까지 함께 설계해야 한다.

원문 읽기(새 탭에서 열림)
github1분 읽기큐레이션 요약

비밀 스캔의 신뢰성 향상: 대규모 환경에서 오탐 줄이기

Mariko는 Microsoft의 Principal Applied Scientist로서 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발을 이끌고 있습니다. 특히 LLM 기반 시스템과 에이전트 워크플로를 연구하며, 최신 AI 연구를 실제 제품과 운영 환경에 적용하는 데 집중합니다. ### Microsoft에서의 역할 - Microsoft의 Principal Applied Scientist로 활동 - 사이버보안 운영을 위한 에이전트형 AI 워크플로 개발 주도 - AI를 실제 보안 업무와 운영 프로세스에 통합하는 역할 수행 ### 주요 연구 관심사 - LLM 기반 시스템 - 여러 단계의 작업을 자율적으로 수행하는 에이전트형 워크플로 - 최신 AI 연구를 현실적인 제품과 운영 환경에 적용하는 방법 ### 실무적 의미 - AI 에이전트가 사이버보안 운영을 자동화하거나 지원할 가능성을 보여줌 - 연구 성과를 실제 제품과 보안 업무에 연결하는 응용 중심의 접근을 강조함

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

언어 서버로 GitHub Copilot CLI에 진정한 코드 인텔리전스를 더하세요

GitHub Copilot CLI는 LSP(Language Server Protocol)를 연동하면 단순한 텍스트 검색이나 바이트코드 추출을 넘어, 코드의 타입·정의·참조를 의미론적으로 이해할 수 있다. 글에서는 이를 자동화하는 **LSP Setup 스킬**의 동작 방식과 설정 형식, 지원 언어 및 설치 절차를 소개하며, 결과적으로 더 정확하고 빠른 코드 분석이 가능해진다고 설명한다. ## 텍스트 검색 기반 코드 이해의 한계 - LSP가 없으면 Copilot CLI는 의존성 정보를 찾기 위해 다음과 같은 우회 작업을 수행한다. - Java JAR 파일 검색 및 임시 디렉터리 추출 - `.class` 파일에 대한 `grep` - Python의 `site-packages`나 TypeScript의 `node_modules` 파일 직접 탐색 - 이런 방식은 단순한 패턴 검색에 의존하므로 다음 정보를 정확히 처리하기 어렵다. - 제네릭 타입 - 메서드 오버로드 - 전이 의존성의 타입 - 컴파일된 바이트코드 내부의 의미 구조 - 반면 LSP의 `textDocument/definition` 요청은 심볼의 정확한 소스 위치, 해석된 타입, 메서드 시그니처를 반환한다. ## LSP Setup 스킬의 7단계 동작 ### 1. 언어 선택 - `ask_user`를 사용해 사용자가 LSP를 설정할 프로그래밍 언어를 선택한다. - 선택한 언어가 이후 설치 명령과 설정 생성을 결정한다. ### 2. 운영체제 확인 - macOS와 Linux에서는 `uname -s`를 사용한다. - Windows에서는 `$env:OS` 또는 `%OS%`를 확인한다. - 운영체제에 따라 LSP 서버 설치 방법을 다르게 적용한다. - macOS Java: `brew install jdtls` - Linux Java: Eclipse 등에서 다운로드 ### 3. LSP 서버 조회 - `references/lsp-servers.md`에 14개 언어의 정보가 미리 정리되어 있다. - 각 언어별로 다음 내용을 제공한다. - 운영체제별 설치 명령 - 실행 파일 이름 - 바로 사용할 수 있는 설정 예시 ### 4. 설정 범위 선택 - 사용자 전역 설정: - `~/.copilot/lsp-config.json` - 모든 저장소에 적용 - 저장소별 설정: - 저장소 루트의 `lsp.json` - 또는 `.github/lsp.json` - 특정 프로젝트에만 적용 - 두 설정이 모두 존재하면 저장소별 설정이 우선한다. ### 5. LSP 서버 설치 - 언어에 맞는 설치 명령을 자동으로 실행한다. - 예시는 다음과 같다. ```bash npm install -g typescript typescript-language-server brew install jdtls rustup component add rust-analyzer ``` ### 6. 설정 파일 생성 및 병합 - 설정은 `lspServers` 객체 아래에 서버별 항목을 둔다. ```json { "lspServers": { "java": { "command": "jdtls", "args": [], "fileExtensions": { ".java": "java" } } } } ``` - 주요 규칙은 다음과 같다. - `command`는 `$PATH`에 있거나 절대 경로여야 한다. - 일반적으로 표준 입출력 통신을 위해 `--stdio`를 `args`에 지정한다. - `fileExtensions`는 점으로 시작하는 확장자와 VS Code 언어 식별자를 연결한다. - 기존 설정은 삭제하지 않고 새로운 항목을 병합한다. - `jdtls`처럼 표준 입출력을 내부적으로 처리하는 서버는 별도 인자가 필요하지 않을 수 있다. ### 7. 설치 및 설정 검증 - `which <binary>` 또는 Windows의 `where.exe`로 실행 파일이 접근 가능한지 확인한다. - 설정 파일이 올바른 JSON인지 검증한다. ## 지원 언어와 확장 방식 - 스킬은 현재 14개 언어에 대한 사전 정의 서버 정보를 제공한다. - 미리 매핑되지 않은 언어를 만나면 적절한 LSP 서버를 검색하고 수동 설정 과정을 안내한다. - 따라서 지원 목록에 없는 언어도 서버만 확보하면 직접 추가할 수 있다. ## 설정 후 가능한 코드 인텔리전스 LSP 연동 후 Copilot CLI는 다음 작업을 수행할 수 있다. - 의존성 전체에서 타입을 정확히 해석 - 저장소에 소스 코드가 없는 외부 라이브러리의 정의로 이동 - 프로젝트 전반에서 심볼의 모든 참조 검색 - 함수·클래스·타입의 hover 문서 확인 - 메서드 시그니처와 타입 관계를 기반으로 코드 수정 및 분석 그 결과 불필요한 JAR 압축 해제나 `node_modules` 검색이 줄고, 잘못 해석한 API에 기반한 코드 생성도 감소한다. ## 설치 및 사용 절차 1. Awesome Copilot의 LSP Setup 스킬 페이지에서 ZIP 파일을 다운로드한다. 2. 다음 명령으로 `~/.copilot/skills/`에 압축을 푼다. ```bash unzip lsp-setup.zip -d ~/.copilot/skills/ ``` 3. 실행 중인 Copilot CLI를 `/exit`로 종료한 뒤 다시 실행한다. 4. “set up LSP for Java” 또는 “enable code intelligence for Python”처럼 요청한다. 5. 설정이 끝나면 Copilot CLI를 다시 시작한다. 6. `/lsp`로 서버 상태를 확인하고, 의존성 심볼의 정의 이동을 테스트한다. 프로젝트 규모가 크거나 외부 라이브러리 사용이 많은 경우에는 LSP Setup 스킬을 적용하는 것이 좋다. 특히 Java, TypeScript, Python처럼 타입과 의존성 관계가 복잡한 언어에서는 텍스트 검색보다 정확한 코드 분석과 안정적인 결과를 기대할 수 있다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

일회성 프롬프트에서 워크플로로: GitHub Copilot CLI에서 커스텀 에이전트를 사용하는 방법

GitHub Copilot CLI의 커스텀 에이전트는 반복적인 터미널 작업과 팀의 개발 규칙을 Markdown 기반 워크플로로 표준화하는 기능이다. 저장소에 에이전트 프로필을 두면 팀의 도구, 코딩·보안·접근성 기준, 출력 형식을 버전 관리하며 CLI·IDE·GitHub 전반에서 일관되게 사용할 수 있다. 따라서 일회성 프롬프트를 반복하는 대신 검토 가능하고 재사용 가능한 전문 에이전트를 구축할 수 있다. ## 커스텀 에이전트의 개념 - 커스텀 에이전트는 특정 작업에 특화된 Copilot 에이전트다. - Markdown 파일인 에이전트 프로필에 다음 내용을 정의한다. - 에이전트의 역할과 전문 영역 - 사용할 수 있는 도구 - 따라야 할 개발·보안·접근성 기준 - 실행 범위와 안전장치 - 결과물의 형식 - 일반적인 코드 정리 에이전트와 달리, 팀의 포맷 규칙·접근성 표준·리뷰 절차·보안 요구사항을 매번 동일하게 적용할 수 있다. - 프로필이 저장소에 포함되므로 코드처럼 리뷰·수정·공유·버전 관리가 가능하다. ## 에이전트 프로필 구성 프로필은 YAML frontmatter와 지침 본문으로 구성된다. - `name`: 에이전트 이름 - `description`: 에이전트의 목적과 역할 - `model`: 사용할 Copilot 모델 - `tools`: 코드베이스 검색, 파일 수정, 테스트 실행, 터미널, 웹 요청 등 허용할 도구 - 본문 지침: - 에이전트의 전문성 - 작업 절차 - 출력 형식 - 금지 사항과 안전 규칙 예를 들어 접근성 전문가 에이전트는 WCAG 2.1/2.2의 A·AA·AAA 등급을 기준으로 웹 UI를 검토하고, 디자인·개발·QA에 적용 가능한 실무 지침을 제공하도록 설정할 수 있다. ## GitHub Copilot CLI에서 사용하는 방법 - 터미널에서 GitHub Copilot CLI를 실행한다. - `/agent` 슬래시 명령을 사용해 원하는 커스텀 에이전트를 선택한다. - 대상 저장소의 `.github/agents` 디렉터리에 프로필을 만든다. - 파일 확장자는 `.agent.md`를 사용한다. 예: - `.github/agents/accessibility.agent.md` - `.github/agents/security-audit.agent.md` - CLI는 정의된 도구와 지침에 따라 스크립트 실행, API 호출, 저장소 분석 등을 반복 가능한 방식으로 수행한다. ## 자동화할 수 있는 보안 감사 글에서는 보안 점검을 대표적인 커스텀 에이전트 활용 사례로 제시한다. - 여러 저장소에서 팀의 표준 보안 도구를 실행한다. - `gitleaks`: 비밀·자격 증명 탐지 - `trivy`: 파일 시스템 및 컨테이너 취약점 검사 - `semgrep`: 정적 분석 - `gh`: GitHub 설정 및 의존성 검토 - `jq`, `git`: 결과 처리와 저장소 작업 - 결과를 `Critical`, `High`, `Medium`, `Low` 심각도로 분류한다. - 담당자와 다음 조치를 포함한 PR용 체크리스트로 출력한다. - 저장소에 이미 존재하는 설정 파일을 우선 사용한다. - `.semgrep.yml` - `.trivyignore` - `.gitleaks.toml` - 도구가 설치되지 않은 경우 결과를 추측하지 않고 “검사 범위의 공백”으로 기록한다. - 토큰이나 자격 증명 등 민감한 정보는 출력에서 마스킹한다. - `CODEOWNERS`가 없으면 경로별 기본 담당 팀을 매핑해 후속 조치를 명확히 한다. ## 커스텀 에이전트의 장점 - 반복 작업을 자동화해 명령어 재실행과 컨텍스트 재설명을 줄인다. - 팀 표준을 프롬프트가 아닌 저장소 파일로 관리할 수 있다. - 결과 형식과 품질 기준이 일관된다. - CLI에서 시작한 작업을 IDE와 GitHub의 리뷰·PR 흐름으로 자연스럽게 연결할 수 있다. - 에이전트 설정 자체를 코드 리뷰 대상으로 삼아 변경 이력과 책임 소재를 남길 수 있다. 반복적으로 수행하는 보안 검사, 접근성 검토, 테스트 실행, 로그 분석 같은 작업부터 `.github/agents`에 에이전트로 정의하는 것이 좋다. 특히 허용 도구, 민감 정보 처리, 실패 시 동작, 결과 형식을 명확히 작성하면 Copilot CLI를 단순한 명령어 생성기가 아니라 팀 표준을 실행하는 재사용 가능한 워크플로 엔진으로 활용할 수 있다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

초보자를 위한 GitHub: 자주 묻는 질문에 대한 답변

이 글은 GitHub 초보자가 자주 묻는 SSH 키와 Personal Access Token(PAT)의 개념, 생성 방법, 보안상 주의점을 설명한다. SSH는 컴퓨터의 개인 키와 GitHub에 등록한 공개 키를 이용해 인증하며, PAT는 명령줄이나 API 접근에 사용하는 권한 기반 자격 증명이다. 글의 후반부에서는 병합과 리베이스 차이도 다룰 예정이지만, 제공된 내용은 해당 질문의 제목에서 끝난다. ## SSH 키의 개념과 역할 - SSH 키는 다음 두 파일로 구성된 키 쌍이다. - **개인 키(private key)**: 컴퓨터에 보관하며 절대 공유하지 않는다. - **공개 키(public key)**: GitHub 등에 등록해도 된다. - GitHub는 등록된 공개 키와 사용자의 컴퓨터에 있는 개인 키가 일치하는지 확인해 인증한다. - SSH를 설정하면 GitHub에 코드를 push하거나 pull할 때 비밀번호를 반복해서 입력하지 않아도 된다. ## SSH 키 생성 및 ssh-agent 등록 - 터미널에서 Ed25519 방식의 키를 생성한다. ```bash ssh-keygen -t ed25519 -C YOUR_EMAIL@DOMAIN.COM ``` - 저장 경로를 물으면 기본 경로를 사용하기 위해 Enter를 누른다. - 개인 키를 보호할 passphrase를 설정한다. - `ssh-agent`는 개인 키를 안전하게 보관해 매번 passphrase를 입력하지 않도록 돕는다. - 생성한 키를 agent에 추가한다. ```bash ssh-add ~/.ssh/id_ed25519 ``` ## 공개 키를 GitHub에 등록하기 - 공개 키 내용을 확인한다. ```bash cat ~/.ssh/id_ed25519.pub ``` - 출력된 한 줄 전체를 복사한다. - GitHub에서 다음 순서로 등록한다. - 프로필 사진 → **Settings** - 왼쪽 메뉴의 **SSH and GPG keys** - **New SSH key** - 기기를 식별할 수 있는 제목 입력 - 복사한 공개 키 붙여넣기 - **Add SSH key** 클릭 - 개인 키는 GitHub에 업로드하지 않고 로컬 컴퓨터에만 보관해야 한다. ## Personal Access Token(PAT)의 용도 - PAT는 GitHub 도구, 명령줄, GitHub API에서 사용하는 별도의 인증 자격 증명이다. - 토큰마다 접근 가능한 저장소와 권한을 지정할 수 있다. - 필요할 때 폐기(revoke)할 수 있으며, 만료일도 설정할 수 있다. - PAT는 생성 직후 한 번만 표시되므로 비밀번호 관리자 등 안전한 장소에 즉시 저장해야 한다. - 터미널에서 GitHub 비밀번호를 요구할 때 비밀번호 대신 PAT를 사용할 수 있다. ## Fine-grained PAT 생성 - GitHub의 **Settings → Developer settings → Personal access tokens → Fine-grained tokens**로 이동한다. - 토큰 이름과 용도를 설명하는 설명을 입력한다. - 만료일을 지정한다. - 토큰이 접근할 저장소를 전체 또는 특정 저장소로 제한한다. - 필요한 권한을 추가하고 각 권한을 읽기 전용 또는 읽기·쓰기 모드로 설정한다. - 생성 전 설정을 검토한 뒤 토큰을 생성한다. - 권한 범위를 좁게 설정하면 토큰이 유출되었을 때의 피해를 줄일 수 있다. ## Classic PAT 생성 - **Settings → Developer settings → Personal access tokens → Tokens (classic)**으로 이동한다. - **Generate new token (classic)**을 선택한다. - 토큰 이름과 만료일을 지정한다. - 필요한 scope를 선택한다. - 토큰을 생성한 뒤 표시되는 값을 안전하게 복사한다. - Classic 토큰은 권한 범위가 더 포괄적일 수 있으므로, 가능한 경우 필요한 저장소와 권한을 세밀하게 제한할 수 있는 fine-grained 토큰을 우선 고려하는 것이 좋다. ## 실용적인 보안 권장 사항 - SSH 개인 키와 PAT를 다른 사람에게 공유하지 않는다. - PAT에는 필요한 저장소와 최소 권한만 부여한다. - 토큰에는 만료일을 설정하고 더 이상 사용하지 않으면 폐기한다. - PAT는 비밀번호나 소스 코드에 직접 기록하지 말고 비밀번호 관리자나 안전한 시크릿 저장소에 보관한다. - 제공된 글에는 병합(merge)과 리베이스(rebase) 설명이 이어질 예정이지만, 해당 내용은 포함되어 있지 않다.

원문 읽기(새 탭에서 열림)
github3분 읽기큐레이션 요약

초보자를 위한 GitHub: VS Code에서 Git과 GitHub 시작하기

VS Code는 Git과 GitHub 기능을 통합해 편집기를 벗어나지 않고 저장소 초기화, 브랜치 관리, 변경 사항 검토, 커밋과 푸시를 수행하게 해준다. 이 글은 Git과 GitHub의 차이를 설명하고, VS Code에서 로컬 폴더를 Git 저장소로 만들고 변경 사항을 GitHub에 올리는 초보자용 흐름을 단계별로 안내한다. 이를 통해 도구 간 전환을 줄이고 개발 작업의 생산성을 높일 수 있다. ## Git, GitHub, VS Code의 관계 - **GitHub**는 코드 저장소를 호스팅하는 서비스다. - **Git**은 소스 코드의 변경 이력을 관리하는 프로그램이다. - Git은 명령줄뿐 아니라 VS Code 같은 편집기에서도 사용할 수 있다. - VS Code는 Git 기능을 내장하고 있어 GitHub와 연계된 버전 관리 작업을 편리하게 수행할 수 있다. - 실습을 위해 Git과 VS Code를 먼저 설치해야 한다. ## 폴더를 Git 저장소로 초기화 - VS Code에서 **Explorer → Open Folder**를 선택해 코드가 들어 있는 폴더를 연다. - 왼쪽의 **Source Control** 아이콘을 클릭한다. - **Initialize Repository**를 선택하면 해당 폴더에 로컬 Git 저장소가 생성된다. - 하단 왼쪽에서 현재 브랜치 이름을 확인할 수 있으며, 기본 브랜치는 보통 `main`이다. - Command Palette에서 **Git: Rename Branch**를 실행해 브랜치 이름을 변경할 수 있다. - macOS: `Shift-Command-P` - Windows/Linux: `Ctrl-Shift-P` ## 파일 추적과 스테이징 - 저장소를 초기화하면 기존 파일 옆에 `U` 표시가 나타난다. - `U`는 **Untracked**, 즉 아직 Git이 추적하지 않는 파일이라는 뜻이다. - 파일 옆의 `+` 버튼을 클릭하면 해당 파일이 스테이징된다. - **CHANGES** 옆의 `+` 버튼을 누르면 변경된 모든 파일을 한 번에 스테이징할 수 있다. - 스테이징된 파일은 `A`로 표시된다. - `A`는 파일이 추가되었지만 아직 커밋되거나 GitHub에 업로드되지는 않았다는 의미다. ## 커밋 생성 - Source Control 패널 상단의 입력란에 변경 내용을 설명하는 커밋 메시지를 작성한다. - 필요하면 Copilot 아이콘을 사용해 커밋 메시지를 생성할 수 있다. - **Commit** 버튼을 누르면 스테이징된 변경 사항이 로컬 Git 저장소에 기록된다. - 커밋은 변경 사항을 GitHub에 업로드하는 것과는 다르며, 이후 별도의 푸시 작업이 필요하다. ## 브랜치 생성과 전환 - 주요 기능을 개발할 때는 `main` 브랜치에서 직접 작업하기보다 별도 브랜치를 만드는 것이 권장된다. - Command Palette에서 **Git: Create Branch…**를 실행한다. - 예를 들어 `new-features` 같은 브랜치 이름을 입력한다. - VS Code는 새 브랜치를 생성한 뒤 자동으로 해당 브랜치로 전환한다. - 현재 브랜치는 화면 하단 왼쪽에서 확인할 수 있다. ## 코드 변경 사항 확인 VS Code의 편집기 여백인 **gutter**는 코드 변경 유형을 시각적으로 표시한다. - 초록색 선: 새로 추가된 코드 - 파란색 표시: 기존 코드가 수정된 부분 - 빨간색 화살표: 코드가 삭제된 부분 - 변경된 파일은 Source Control 패널의 **CHANGES** 아래에 표시된다. - 파일에 마우스를 올리면 다음 작업을 수행할 수 있다. - 파일 열기 - 변경 사항 폐기 - 변경 사항 스테이징 - CHANGES 영역에서도 여러 파일의 변경 사항을 한꺼번에 검토하거나 스테이징할 수 있다. ## diff로 변경 내용 비교 - Source Control 패널에서 파일 이름을 클릭하면 변경 전후를 나란히 비교하는 diff 화면이 열린다. - diff 화면에서는 어떤 코드가 추가·수정·삭제되었는지 확인할 수 있다. - 오른쪽 위의 `…` 메뉴에서 **Inline View**를 선택하면 변경 전후 내용을 하나의 화면에서 볼 수 있다. - Inline View에서는 diff 화면 안에서 직접 코드를 수정할 수도 있다. ## 실용적인 작업 흐름 - VS Code에서 폴더를 연다. - Git 저장소를 초기화한다. - 기능별 브랜치를 만든다. - 코드를 수정하고 Source Control에서 변경 사항을 검토한다. - 필요한 파일을 스테이징한다. - 의미 있는 커밋 메시지와 함께 커밋한다. - 이후 변경 사항을 GitHub에 반영하려면 푸시 작업을 수행한다. 이 글은 제공된 내용 기준으로 diff 확인 단계 이후에서 본문이 중단되어 있으며, GitHub 원격 저장소 연결과 실제 푸시 절차는 포함되어 있지 않다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

GitHub, Gartner® 매직 쿼드런트™ 엔터프라이즈 AI 코딩 에이전트 부문에서 3년 연속 리더로 선정

코드 생성이 쉬워지면서 소프트웨어 개발의 병목은 코드 작성에서 리뷰·보안·거버넌스·배포로 이동했으며, GitHub는 이를 해결하려면 소프트웨어 개발 생명주기(SDLC) 전반에 AI 에이전트가 필요하다고 주장합니다. GitHub Copilot은 이슈 처리부터 코드 리뷰와 배포까지 지원하는 에이전트형 기능을 확장하고 있으며, Gartner의 2026년 보고서에서 3년 연속 ‘Leader’로 선정됐습니다. GitHub는 특히 실행 역량, 네이티브 통합, 보안·거버넌스 기능에서 강점을 보였다고 설명합니다. ## 코드 생성에서 소프트웨어 결과물 조율로 - 개발자는 더 이상 Copilot에 단순히 함수 작성을 요청하는 데 그치지 않고, 이슈를 에이전트에 할당한 뒤 작업을 맡길 수 있습니다. - 에이전트는 코드 작성뿐 아니라 관련 작업을 수행하고, 개발자는 결과를 검토·수정·승인하는 역할에 집중합니다. - Gartner는 2028년 비동기 AI 코딩 에이전트가 소프트웨어 엔지니어링 팀 생산성을 30~50% 향상할 것으로 전망했습니다. - 이는 2025년 AI 코드 보조 도구가 제공할 것으로 예상된 0~20%의 생산성 향상보다 큰 폭입니다. - 생산성 향상을 실현하려면 코드 생성뿐 아니라 계획, 테스트, 리뷰, 보안, 거버넌스까지 AI가 관여해야 한다는 것이 GitHub의 주장입니다. ## 엔터프라이즈 규모로 확산되는 GitHub Copilot - GitHub Copilot은 현재 14만 개 조직에서 사용되며, 전년 대비 사용자·조직 기반이 거의 3배로 증가했습니다. - 전체 성장률은 전년 대비 100%를 넘었고, 많은 사용자가 여러 AI 모델을 함께 활용하고 있습니다. - GitHub Copilot CLI 사용량도 전월 대비 거의 두 배씩 증가하고 있다고 설명합니다. - GitHub는 이러한 지표가 기업들이 Copilot을 단순 코드 자동완성 도구가 아니라 복합적인 개발 플랫폼으로 활용하고 있음을 보여준다고 평가합니다. ## Gartner ‘Leader’ 선정과 평가 - Gartner는 2026년 Enterprise AI Coding Agents Magic Quadrant에서 12개 공급업체를 평가했습니다. - 평가는 크게 다음 두 기준을 바탕으로 이뤄졌습니다. - 실행 역량(Ability to Execute) - 비전의 완성도(Completeness of Vision) - GitHub는 실행 역량 부문에서 가장 높은 위치에 배치됐으며, 3년 연속 Leader로 선정됐습니다. - Gartner가 말하는 Leader는 다음 특징을 갖춘 업체입니다. - 강력한 제품 실행력과 시장 방향을 형성할 수 있는 명확한 비전 - 편집기 내부를 넘어 계획·테스트·코드 리뷰·워크플로 자동화까지 지원하는 에이전트 기능 - 개발자와 기업 모두에게서 확보한 시장 반응 - 확장되는 생태계와 지속 가능한 비즈니스 모델 - 엔터프라이즈급 보안, 거버넌스, 운영 성숙도 ## GitHub Copilot의 차별화 요소 - **모델과 사용 환경의 선택권** - 여러 공급업체의 AI 모델을 지원합니다. - 코드 에디터, IDE, CLI뿐 아니라 GitHub 웹·데스크톱·모바일 앱에서도 Copilot을 사용할 수 있습니다. - **SDLC 전반의 통합** - 개발 시작 단계의 코드 작성에만 머물지 않습니다. - 이슈, 풀 리퀘스트, 코드 리뷰, GitHub Actions 등 개발 및 배포 과정 곳곳에 Copilot을 통합합니다. - **기업용 통제 기능** - 조직이 AI 사용 현황을 관찰하고 감사할 수 있도록 지원합니다. - AI가 생성하거나 수정한 코드의 사용을 보안 정책과 거버넌스 체계 안에서 관리할 수 있도록 합니다. - GitHub는 이러한 기능이 GitHub 플랫폼 내부의 네이티브 통합과 결합되어 기업 환경에서 AI 개발을 관리하기에 유리하다고 주장합니다. ## 앞으로의 계획 - 개발자가 사용하는 모든 GitHub 표면에서 에이전트형 워크플로를 더욱 확장할 예정입니다. - 여러 모델을 더 폭넓게 제공하고, 작업에 적합한 모델을 자동으로 선택하는 지능형 라우팅을 강화할 계획입니다. - 단순히 코드가 어떻게 생성되는지만이 아니라 GitHub에서 소프트웨어가 실제로 어떻게 개발·검토·배포되는지에 기반해 Copilot 성능을 개선하려 합니다. - 핵심 방향은 개발 생명주기 전체를 연결하는 AI-native 소프트웨어 개발 환경을 구축하는 것입니다. Gartner의 Leader 선정은 GitHub Copilot의 엔터프라이즈 경쟁력을 보여주는 지표지만, Gartner도 특정 업체나 최고 등급 업체만을 선택하라고 권고하지 않는다고 명시합니다. 따라서 도입을 검토할 때는 모델 선택권, 기존 저장소·CI/CD와의 통합성, 보안 및 감사 기능, 실제 팀의 리뷰·배포 프로세스 개선 효과를 함께 평가하는 것이 바람직합니다.

원문 읽기(새 탭에서 열림)
github2분 읽기큐레이션 요약

GitHub 소유 저장소에 대한 무단 접근 조사

Alexis Wales는 GitHub의 최고정보보호책임자(CISO)로서 플랫폼과 제품, 오픈소스 커뮤니티의 보안을 담당한다. 20년간 국방부와 CISA 등에서 국가 및 민간 부문의 핵심 네트워크를 방어해 왔으며, 공공·민간 협력을 통해 기술 보안 문제를 해결하는 데 주력하고 있다. 그녀의 목표는 전 세계 1억 5천만 명 이상의 개발자가 GitHub에서 안전하게 소프트웨어를 개발하고 배포하도록 지원하는 것이다. ### GitHub의 보안 리더십 - GitHub의 보안 전문가 팀을 이끈다. - GitHub 플랫폼과 제품의 보안을 강화한다. - 오픈소스 생태계와 커뮤니티를 보호한다. - 개발자들이 안전하게 소프트웨어를 만들고 배포할 수 있도록 지원한다. ### 국가 핵심 네트워크 방어 경험 - 약 20년 동안 국가 및 민간 부문의 중요 네트워크를 보호해 왔다. - 미국 국방부에서 보안 업무를 수행했다. - 국토안보부 산하 CISA에서도 근무하며 사이버 보안과 핵심 인프라 보호 경험을 쌓았다. ### 공공·민간 협력에 대한 관점 - 국가 기관과 민간 기업이 협력해야 가장 어려운 보안 위협에 효과적으로 대응할 수 있다고 본다. - 이러한 협력에 대한 관심은 국가 및 민간 네트워크를 방어한 경험에서 비롯되었다. - 일상적으로 사용하는 기술을 위협하는 보안 문제를 공동으로 해결하는 것을 중시한다. 실용적으로는 GitHub와 같은 개발 플랫폼의 보안을 강화하려면 기술적 방어뿐 아니라 공공기관, 기업, 오픈소스 커뮤니티 간의 지속적인 정보 공유와 협력이 필요하다는 점을 시사한다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

범용 접근성 에이전트 구축과 그 과정에서 얻은 교훈

GitHub는 개발자가 접근성 질문에 즉시 답을 얻고, 배포 전 단순하고 객관적인 접근성 문제를 자동 수정하도록 실험적인 범용 접근성 에이전트를 운영하고 있습니다. 이 에이전트는 3,535개의 풀 리퀘스트를 검토해 68%의 해결률을 기록했지만, 접근성을 자동으로 “해결”하는 만능 도구가 아니라 기존 엔지니어링 노력을 보완하는 역할로 설계되었습니다. 특히 조직이 축적한 구조화된 접근성 이슈와 수정 사례가 에이전트의 정확도와 실용성을 높이는 핵심 자산이 되었습니다. ## 접근성 에이전트의 목표와 성과 - GitHub Copilot CLI와 VS Code 통합 환경에서 접근성 관련 질문에 신뢰할 수 있는 답변을 제공합니다. - 프런트엔드 코드가 변경된 풀 리퀘스트를 자동으로 검사합니다. - 단순하고 판단 기준이 명확한 접근성 문제는 코드 제안 형태로 자동 수정할 수 있습니다. - 현재까지 3,535개의 풀 리퀘스트를 검토했으며, 68%의 해결률을 기록했습니다. - 가장 많이 발견된 문제는 다음과 같습니다. - 구조와 관계를 보조공학 기술이 명확히 이해하도록 표현하지 못한 문제 - 대화형 컨트롤의 이름이 불명확한 문제 - 중요한 상태 변화나 공지를 사용자에게 전달하지 못한 문제 - 이미지 등 비텍스트 콘텐츠에 텍스트 대안이 없는 문제 - 키보드 포커스 이동 순서가 논리적이지 않은 문제 예를 들어 시각적 배치와 DOM·스크린 리더 읽기 순서가 서로 다른 경우, 에이전트는 `row-reverse` 대신 DOM 요소 순서를 바꾸고 일반적인 `flex-direction: row`를 사용하라고 제안할 수 있습니다. ## 접근성을 바라보는 관점 - 사회적 장애 모델에 따르면 장애와 사용 장벽은 개인뿐 아니라 환경의 설계 방식에서도 발생합니다. - 디지털 서비스에서도 잘못 구성된 UI가 보조공학 사용자에게 장벽을 만들 수 있습니다. - 따라서 에이전트의 목표는 접근성을 독립적으로 완성하는 것이 아니라, 동료 개발자가 장벽을 더 빠르게 발견하고 제거하도록 돕는 것입니다. - 모든 상황을 자동으로 처리할 수 있는 “실버 불릿”으로 에이전트를 홍보하지 않았습니다. - 에이전트의 책임 범위를 현실적으로 정의한 덕분에 실험을 빠르게 시작하고 조직 내 동의를 얻을 수 있었습니다. ## 규제와 사전 투자 - 유럽 접근성법(EAA)이 시행되었고, 미국 장애인법(ADA) Title II도 2027년 4월부터 WCAG 2.1 AA 준수를 법적 완료 기준으로 삼을 예정입니다. - LLM 기반 에이전트는 접근성 트리를 읽고 이를 바탕으로 UI를 분석하거나 조작할 수 있습니다. - 조직이 아직 수동으로 접근성 문제를 식별하고 수정하는 체계를 마련하지 않았다면, 향후 에이전트를 구축할 때도 불리해집니다. - 자동화는 기존의 접근성 품질 관리 체계를 대체하는 것이 아니라, 이미 검증된 문제와 해결 방식을 활용해 확장하는 방식으로 효과를 냅니다. ## 구조화된 이슈 데이터의 가치 GitHub는 에이전트 도입 이전부터 접근성 문제를 일관되게 기록하고 검증하는 시스템을 운영했습니다. - 문제 신고용 구조화된 템플릿 - 재현 절차 - 심각도, 담당 서비스 영역, 적용 가능한 WCAG 성공 기준 등의 메타데이터 - 문제를 해결한 풀 리퀘스트와의 연결 - 수정 완료를 판단하는 명확한 수용 기준 - 모든 접근성 이슈를 하나의 저장소에 중앙화 이처럼 일관된 형식으로 축적된 이슈와 코드 변경 내역은 에이전트가 참고할 수 있는 고품질 학습·검색 자료가 되었습니다. LLM의 비결정적이고 유연한 매칭 능력도 비슷한 코드와 문구를 찾아내는 데에는 장점으로 작용했습니다. ## 일반적인 지침만으로는 부족한 이유 - 전문 영역에서 “접근성 모범 사례를 따르라”는 식의 짧고 추상적인 지침만으로는 충분하지 않습니다. - 주요 LLM은 접근성이 부족한 코드가 포함된 수십 년간의 자료로 학습되었기 때문에, 접근성 안티패턴을 생성하는 편향을 보일 수 있습니다. - 따라서 에이전트가 실제 조직의 코드 스타일과 문제 해결 관례를 반영한 구체적인 사례를 참고해야 합니다. - 수동으로 접근성 문제를 분류하고 수정한 기록은 다음 요소를 함께 포함합니다. - 실제 제품 맥락 - 조직의 코딩·문서화 규칙 - 적용된 WCAG 기준 - 문제를 해결한 코드 - 수정 여부를 검증하는 조건 - 이런 사례 기반 자료는 단순한 체크리스트보다 에이전트의 판단과 코드 제안에 훨씬 강력한 기반이 됩니다. ## 실용적인 결론 접근성 에이전트를 도입하려면 먼저 사람이 접근성 문제를 일관되게 기록하고, 재현 절차와 WCAG 기준, 실제 수정 사례를 축적하는 것이 좋습니다. 에이전트는 전문가의 판단을 대체하기보다 반복적이고 객관적인 문제를 빠르게 발견·수정하는 보조 수단으로 운영해야 하며, 그 한계를 명확히 정의할수록 조직 내 신뢰와 도입 효과가 커집니다.

원문 읽기(새 탭에서 열림)
github4분 읽기큐레이션 요약

기준을 높이다: 품질, 공동의 책임, 그리고 GitHub 버그 바운티 프로그램의 미래

GitHub는 버그 바운티 프로그램을 유지하되, 제출량 증가와 검증되지 않은 보고서 확산에 대응해 심사 기준을 강화하겠다고 밝혔다. AI·스캐너 사용 자체는 환영하지만, 연구자가 실제 영향을 재현하고 검증할 책임이 있다는 점을 강조한다. 또한 사용자가 악성 콘텐츠를 직접 선택·실행하는 경우에는 GitHub의 보안 경계를 우회한 취약점이 아니라 공유 책임 영역으로 보는 원칙을 설명한다. ## 제출량 증가와 품질 문제 - AI와 새로운 보안 도구로 보안 연구 진입 장벽이 낮아지면서 업계 전반의 버그 바운티 제출량이 크게 증가했다. - 정당한 취약점이 늘어난 긍정적 효과도 있지만, 다음과 같은 저품질 보고서도 급증했다. - 실제 동작하는 개념 증명(PoC)이 없음 - 검증되지 않은 이론적 공격 시나리오 - GitHub가 이미 공개한 부적격 항목에 해당 - 보안 영향이 구체적으로 입증되지 않음 - GitHub는 프로그램을 중단하는 대신 제출 품질을 높이는 방향으로 대응한다. ## 강력한 취약점 보고서의 조건 - **작동하는 PoC와 실제 보안 영향** - 단순히 “이론적으로 가능하다”고 설명하는 데 그치지 않아야 한다. - 공격자가 실제로 무엇을 할 수 있는지 재현해야 한다. - 보안 경계를 넘을 수 있다는 사실과 구체적인 결과를 보여줘야 한다. - **범위와 부적격 항목 확인** - 제출 전에 GitHub의 버그 바운티 범위와 부적격 목록을 검토해야 한다. - DMARC/SPF/DKIM 설정 문제, 사용자 열거, 공격 경로가 입증되지 않은 보안 헤더 누락 등은 부적격 사례다. - 이런 보고서는 “해당 없음(Not Applicable)”으로 종료될 수 있으며 HackerOne Signal과 평판에 영향을 줄 수 있다. - **제출 전 직접 검증** - 스캐너, 정적 분석 도구, AI가 발견한 결과라도 사람이 재현하고 확인해야 한다. - 검증되지 않은 오탐은 트리아지 리소스를 낭비하는 잡음에 불과하다. ## AI 활용은 허용되지만 책임은 연구자에게 있음 - GitHub는 AI를 보안 연구에 사용하는 것을 금지하지 않는다. - AI는 공격 표면을 탐색하고 후보 취약점을 찾는 생산성 도구로 활용될 수 있다. - 다만 AI가 생성한 결과도 다음 조건을 충족해야 한다. - 실제 환경에서 검증 - 재현 가능성 확인 - 작동하는 PoC 제공 - 구체적인 보안 영향 설명 - AI뿐 아니라 스캐너와 정적 분석 도구의 결과에도 동일한 기준이 적용된다. - 도구가 아니라 결과물의 정확성과 품질이 평가 대상이며, 보고서의 정확성에 대한 최종 책임은 연구자에게 있다. ## 간결하고 구조화된 보고서 작성 강한 보고서는 다음 세 요소를 포함해야 한다. - **짧은 문제 요약** - **명확한 재현 절차와 증거** - 스크린샷 - HTTP 요청 - 터미널 출력 등 - **영향 설명** - 공격자가 실제로 달성할 수 있는 결과를 구체적으로 기술 반대로 긴 이론적 서술, 이미 알려진 배경의 반복, AI가 생성한 불필요한 문장은 핵심 취약점을 묻히게 해 처리 속도를 늦춘다. ## GitHub의 공유 책임 보안 모델 GitHub는 악성 콘텐츠를 탐지하고 처리하기 위해 자동 스캐닝과 수동 검토 등 다양한 방어 체계를 운영한다. 그러나 모든 콘텐츠를 사전에 신뢰할 수 있는 것은 아니므로, 사용자와 GitHub가 보안을 함께 책임지는 공유 책임 모델을 적용한다. 사용자에게 기대되는 책임은 다음과 같다. - 신뢰할 저장소, 이슈, 코드를 신중하게 선택 - 코드·스크립트·워크플로 등 실행 가능한 콘텐츠를 실행하기 전 검토 - 저장소를 클론하는 행위가 해당 코드에 대한 신뢰를 선택하는 것임을 이해 - 토큰, 자격 증명, 로컬 보안 설정을 안전하게 관리 사용자가 악성 저장소를 직접 클론하거나, 악성 파일을 열거나, 신뢰하지 않는 코드를 AI 도구에 분석하도록 제공해야만 문제가 발생한다면, 이는 대체로 GitHub의 보안 통제를 우회한 사례로 간주되지 않는다. ## 공유 책임 영역의 대표 사례 - 사용자가 직접 AI 도구에 제공한 콘텐츠를 이용한 프롬프트 인젝션 - 사용자가 체크아웃한 저장소에서 Git 훅이나 필터가 코드 실행 - 사용자가 클론한 저장소에 포함된 악성 콘텐츠 - 사용자가 제공한 신뢰할 수 없는 입력을 처리하는 LLM의 예기치 않은 출력 이러한 연구도 가치가 있지만, 실제 보안 통제를 우회해 사용자가 악성 콘텐츠를 적극적으로 신뢰하지 않아도 피해가 발생하는지 입증해야 의미 있는 취약점 보고서가 된다. 실무적으로는 AI나 자동화 도구를 적극 활용하되, 제출 전 반드시 수동 재현과 영향 검증을 수행하는 것이 좋다. 보고서는 “요약-재현 절차-실제 영향” 중심으로 간결하게 작성하고, GitHub의 범위·부적격 목록과 사용자 신뢰가 전제된 보안 모델을 먼저 확인해야 한다.

원문 읽기(새 탭에서 열림)
github1분 읽기큐레이션 요약

지연에서 즉시로: GitHub Issues 탐색 성능 현대화

Alexander는 GitHub Issues 팀의 시니어 소프트웨어 엔지니어로, 개발자 업무 흐름을 더 빠르고 즉각적으로 만드는 방법을 찾는 일을 즐긴다. 컴퓨터 그래픽스, 머신러닝, 지리공간 소프트웨어 등 다양한 분야의 경험을 바탕으로 현재 역할을 수행하고 있다. ### 경력과 전문 분야 - GitHub Issues 팀에서 시니어 소프트웨어 엔지니어로 근무한다. - 컴퓨터 그래픽스, 머신러닝, 지리공간 소프트웨어 등 여러 기술 분야를 경험했다. - 한 분야에 국한되지 않은 폭넓은 배경이 현재의 문제 해결 방식에 영향을 준다. ### 개발자 경험 개선 - 일상적인 개발자 업무를 “즉각적으로” 느껴지게 만드는 창의적인 방법을 찾는 것을 중요하게 여긴다. - 기술 자체뿐 아니라 개발자가 도구를 사용하는 과정의 속도와 편의성에 관심이 있다. - GitHub Issues와 같은 개발 협업 도구의 사용자 경험을 개선하는 데 전문성을 발휘한다.

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