GitHub/AI 에이전트

21 개의 포스트

github3분 읽기큐레이션 요약

GitHub Copilot 앱으로 첫 프롬프트 작성하기

GitHub Copilot 앱에서 첫 프롬프트를 작성할 때 완벽한 문장보다 작업 대상과 원하는 결과를 명확히 전달하는 것이 중요하다. 프로젝트를 연결한 뒤 자연어로 작은 작업부터 요청하고, 결과에 따라 프롬프트·모델·실행 방식을 점진적으로 조정하면 된다. 음성 입력, 모델 선택, 에이전트 및 원격 세션 같은 기능은 필요할 때 활용할 수 있다. ## 작업에 필요한 컨텍스트 연결 - Copilot이 코드를 수정하려면 먼저 작업 대상이 필요하다. - GitHub 저장소나 로컬 컴퓨터의 폴더를 에이전트 세션에 연결할 수 있다. - Copilot은 연결된 프로젝트의 코드와 파일을 살펴보고 요청과 관련된 부분을 찾아 작업한다. - 앱 홈 화면에서 기존 프로젝트를 선택하거나 새 프로젝트·로컬 폴더를 추가한다. ## 자연어로 원하는 작업 설명하기 - 별도의 문법이나 정해진 프롬프트 형식을 배울 필요가 없다. - 원하는 변경 사항을 평범한 문장으로 설명하면 된다. - 예시: `게임 목록에 가장 많이 투자된 순서 정렬 옵션을 추가해줘.` - 첫 요청이 충분하지 않으면 세부 조건을 추가하거나 수정 사항을 다시 요청할 수 있다. - 프롬프트는 한 번에 완성하는 것이 아니라 결과를 보며 반복적으로 다듬는 방식이다. ## 작업에 맞는 AI 모델 선택 - Copilot 앱에서는 작업을 처리할 AI 모델을 직접 선택할 수 있다. - 모델마다 복잡한 추론 능력이나 처리 속도 등 강점이 다르다. - 처음에는 기본 모델을 사용해도 충분하다. - 복잡한 작업이거나 결과가 기대에 미치지 못하면 다른 모델로 전환할 수 있다. - 모델 선택은 매번 사전에 세밀하게 설정해야 하는 항목이 아니라, 필요할 때 활용하는 도구다. ## 음성 입력으로 프롬프트 작성 - 프롬프트는 키보드로만 입력할 필요가 없다. - 내장 음성 입력을 사용하면 문제를 말로 설명하면서 긴 요청을 작성할 수 있다. - 음성은 프롬프트 입력창의 텍스트로 변환된다. - 전송 전에 내용을 검토하고 수정할 수 있어, 생각나는 대로 말한 뒤 정리하는 방식도 가능하다. ## 에이전트와 원격 세션 활용 - 세션 제목 메뉴에서 다른 에이전트를 선택하거나 원격 제어를 활성화할 수 있다. - 에이전트마다 작업 유형에 맞게 설정할 수 있으므로 목적에 맞는 에이전트를 고르면 된다. - 원격 세션을 사용하면 작업을 로컬 컴퓨터에서 시작한 뒤 웹이나 다른 기기에서 이어서 확인할 수 있다. - 노트북을 닫아도 세션의 진행 상황을 잃지 않고 나중에 다시 작업할 수 있다. - 이러한 설정은 첫 프롬프트 전에 반드시 구성할 필요는 없으며, 더 많은 제어가 필요할 때 선택하면 된다. ## 작은 작업부터 반복하기 - 이미 익숙한 프로젝트에서 작은 변경 사항부터 요청하는 것이 좋다. - 처음부터 모든 세부 사항을 예측하거나 완벽한 프롬프트를 작성할 필요는 없다. - 결과를 확인하면서 요청을 구체화하고, 필요하면 모델이나 세션 실행 방식을 바꾼다. - 핵심은 프로젝트를 선택하고 자연어로 작업을 요청해 실제 결과를 확인하는 것이다. 실용적으로는 “프로젝트 연결 → 작은 작업 요청 → 결과 검토 → 프롬프트 보완” 순서로 시작하는 것이 가장 쉽다. Copilot의 모델·음성 입력·원격 세션 기능은 기본 흐름에 익숙해진 뒤 작업 상황에 맞게 추가하면 된다.

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

코더에서 오케스트레이터로: 에이전트가 개발자의 역할을 어떻게 바꾸는가

한 번의 프롬프트로 코드를 만드는 시연과, 코드를 반복적·안전하게 배포하는 시스템을 구축하는 일은 다르다. AI 에이전트 시대의 개발자는 단순히 코드를 작성하는 사람을 넘어, 코드 생성부터 검증·리뷰·배포까지의 흐름을 설계하고 통제하는 ‘오케스트레이터’가 되어야 한다. 에이전트의 유연성과 CI·브랜치 보호·리뷰 같은 결정론적 통제를 결합해야 팀이 신뢰할 수 있는 개발 시스템을 만들 수 있다. ## 일회성 프롬프트에서 반복 가능한 워크플로로 - 한 번의 프롬프트는 빠르게 결과를 만들 수 있지만, 매번 안정적으로 재현되는 산출물을 보장하지는 않는다. - 실제 개발에는 다음 요소가 연결된 워크플로가 필요하다. - 작업을 시작하는 이벤트와 트리거 - 에이전트가 수행할 작업의 범위 - 코드 검증과 보안 검사 - 리뷰 및 승인 절차 - 안전한 병합과 배포를 위한 통제 - 따라서 개발자는 코드뿐 아니라 코드가 제안되고, 검증되고, 리뷰되고, 배포되는 시스템 자체를 설계해야 한다. ## 이벤트 기반 에이전트 흐름 - 익숙한 저장소 이벤트를 에이전트 작업의 시작점으로 활용한다. - 이슈에 특정 라벨 추가 - 예약된 야간 워크플로 실행 - 기타 GitHub 저장소 이벤트 - 이벤트가 GitHub Actions 워크플로를 실행하고, 사전에 범위를 정한 작업을 Copilot 에이전트가 수행한다. - 에이전트가 만든 결과는 풀 리퀘스트에 기록된다. - 이후 자동화된 검증 절차가 결과를 평가한다. - 린트 - 테스트 - 보안 스캔 - 빌드 검증 ## 에이전트의 유연성과 결정론적 통제 - 에이전트는 모호하고 맥락이 많은 작업을 처리하는 데 적합하다. - 반면 다음과 같은 규칙 기반 장치는 예측 가능하고 반복 가능한 품질 신호를 제공한다. - CI 검사 - CODEOWNERS - 필수 리뷰 - 브랜치 보호 규칙 - 브랜치 보호는 검증되지 않은 변경이나 승인되지 않은 병합을 막는다. - 위험도가 높은 변경에는 사람의 판단이 반드시 개입되도록 리뷰 요건을 설정할 수 있다. - 팀이 에이전트를 신뢰하려면 에이전트의 자율성을 무제한으로 허용하기보다, 명확한 결정론적 경계 안에서 운영해야 한다. ## 개발자의 역할 변화 - 개발자는 여전히 코드를 작성하지만, 동시에 다음을 책임진다. - 어떤 이벤트가 에이전트를 실행할지 정의 - 에이전트의 권한과 작업 범위 제한 - 에이전트와 검증·리뷰 단계 사이의 인계 설계 - 사람의 판단이 필요한 지점 결정 - GitHub Copilot은 이러한 자동화와 에이전트 운영을 한곳에서 관리하는 제어 평면 역할을 한다. - Copilot cloud agent 워크플로, GitHub Actions의 Copilot CLI, MCP를 통한 외부 도구·컨텍스트 연동은 같은 성숙 경로에서 선택할 수 있는 구현 방식이다. ## 작은 범위에서 시작하기 - 처음부터 전체 개발 프로세스를 자동화하기보다 범위가 명확하고 위험이 낮은 작업 하나를 선택하는 것이 좋다. - 예시: - 이슈 분류 - 문서와 테스트의 동기화 - 단순 유지보수 변경 - 기존 소프트웨어 개발 인프라에 Copilot을 단계적으로 도입하고, 실제로 필요한 다음 자동화 단계를 확인하며 확장한다. 실용적으로는 에이전트에게 제한된 권한을 부여하고, 모든 변경을 풀 리퀘스트와 자동 검사를 거치게 하는 방식이 적합하다. 즉, AI가 코드를 대신 작성하는 것보다 중요한 것은 사람이 통제 가능한 검증·승인·배포 체계를 설계하는 일이다.

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

하네스만 있으면 된다 (대부분)

AI 생산성의 핵심은 새로운 모델·MCP·프롬프트를 끊임없이 추가하는 데 있지 않고, 에이전트 하네스(harness)를 제대로 이해하고 활용하는 데 있다. 글은 GitHub Copilot의 여러 도구에서 공통으로 사용되는 하네스 중심의 단순한 워크플로를 제안하며, 자율 실행 환경에서 먼저 프로토타입을 만들고 요구사항의 복잡성을 조기에 발견하라고 권한다. 다만 자율성을 높일수록 샌드박스 등 안전한 실행 환경을 함께 마련해야 한다. ## 도구보다 하네스 이해하기 - GitHub Copilot CLI, Copilot 앱, VS Code, Visual Studio, JetBrains 등 다양한 도구가 있지만 핵심 상호작용 방식은 점점 비슷해지고 있다. - 하나의 하네스를 익히면 여러 Copilot 환경에서 같은 방식으로 작업할 수 있다. - 처음 시작한다면 UI 요소가 적고 프롬프트와 에이전트 동작에 집중할 수 있는 Copilot CLI가 적합하다. - 중요한 것은 어떤 도구를 선택했는지가 아니라, 에이전트가 작업을 수행하고 파일·명령·결과를 다루는 방식을 이해하는 것이다. ## 자율 실행과 안전한 환경 - `/allow-all` 또는 “Allow All” 설정을 사용하면 에이전트가 매번 사용자의 승인을 기다리지 않고 명령을 실행할 수 있다. - 모든 작업을 일일이 승인하면 생산성 향상이 줄어들고, 사용자가 승인 요청을 무심코 넘기게 될 위험도 있다. - 에이전트의 자율성은 생산성에 중요하지만, 잘못된 명령 실행이나 데이터 손실 같은 위험이 있다. - 특히 회사의 private 데이터가 있는 로컬 환경에서 YOLO 모드를 사용하는 것은 위험하다. - GitHub Codespaces나 개발 컨테이너처럼 격리된 샌드박스 환경에서 실행하는 것이 안전하다. ## 구현 전에 여러 프로토타입 만들기 - AI를 이용하면 과거에는 별도 프로젝트 단계였던 프로토타이핑을 짧은 프롬프트만으로 수행할 수 있다. - 예를 들어 날짜 선택기라면 다음과 같이 여러 시안을 한 번에 생성할 수 있다. ```text Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare. ``` - 여러 레이아웃을 비교하면 연·월·일을 단계적으로 확대하는 방식처럼 처음에는 생각하지 못했던 상호작용을 발견할 수 있다. - 이미지, 도형, 레이아웃 같은 시각적 결과물은 복잡한 요구사항을 긴 텍스트보다 빠르게 이해하게 해준다. - 시각적 프로토타이핑은 UI뿐 아니라 API 설계에도 적용할 수 있다. - 예를 들어 분석 데이터 다운로드 API에 대해 여러 구현 방식을 Mermaid 다이어그램으로 비교하면 요구사항과 제약을 조기에 파악할 수 있다. - 프로토타입은 에이전트 작업의 숨은 복잡성을 드러내며, 구현 후 재작업에 드는 시간과 토큰을 줄여준다. ## 모델과 대화 흐름 유지 - 대부분의 작업에는 중간 크기의 모델과 중간 수준의 reasoning을 사용하는 것이 적절하다고 제안한다. - 하나의 기능·버그·개선 작업을 진행하는 동안 모델과 reasoning 수준을 가급적 바꾸지 않는 것이 좋다. - 같은 모델과 설정을 유지하면 이전 대화가 캐시되어 후속 요청의 토큰 비용을 줄일 수 있다. - 모델을 자주 바꾸기보다 일관된 컨텍스트를 유지하는 것이 작업 효율에 유리하다. ## 실용적인 적용 순서 - Copilot CLI 등 하네스에 가까운 도구로 에이전트의 기본 동작을 익힌다. - 실제 로컬 시스템 대신 Codespaces나 개발 컨테이너에서 자율 실행을 활성화한다. - 구현 전에 HTML 목업, 다이어그램 등 여러 프로토타입을 생성한다. - 선택한 모델과 reasoning 설정을 작업 끝까지 유지한다. - 프로토타입으로 요구사항을 구체화한 뒤 계획과 구현 단계로 넘어간다. 어진 글의 본문은 “계획 수립” 섹션 초입에서 끝나므로, 이후 계획·구현 단계의 구체적인 내용은 제공된 자료만으로 확인할 수 없다.

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

초보자를 위한 GitHub Copilot 앱: 시작하기

GitHub Copilot 앱은 단순한 채팅 도구가 아니라, 프로젝트별 AI 에이전트 세션을 관리하고 코드 작성부터 리뷰·병합까지 지원하는 통합 개발 작업 공간이다. 여러 작업을 동시에 진행하고, 캔버스에서 UI를 직접 확인·수정하며, Agent Merge로 PR 리뷰와 CI 문제 대응까지 자동화할 수 있다. 글은 초보자가 프로젝트를 연결해 세션을 시작하고 실제 개발 workflow에 Copilot을 활용하는 방법을 소개한다. ## 프로젝트를 중심으로 시작하는 작업 - Copilot 앱의 각 에이전트 세션은 특정 프로젝트와 연결된다. - 기존에 작업한 GitHub 프로젝트를 선택하거나 GitHub 저장소·로컬 컴퓨터에서 새 프로젝트를 추가할 수 있다. - 프로젝트가 연결되면 에이전트가 코드베이스, 파일, 개발 도구에 접근한 상태로 작업을 시작한다. - 예를 들어 “기존 애플리케이션에 breadcrumb navigation을 추가해 달라”고 요청하면 에이전트가 다음 작업을 수행할 수 있다. - 관련 파일과 수정 위치 탐색 - 코드 변경 - 테스트 실행 - 변경 사항 검증 지원 - 세션 시작 전에 개발 환경과 파일을 수동으로 준비할 필요가 줄어든다. ## 여러 작업을 동시에 진행하는 세션 - 기존 세션을 중단하지 않고 다른 질문이나 작업을 위한 추가 세션을 만들 수 있다. - **Quick Chat**을 사용하면 Copilot 앱 홈 화면에서 별도의 대화를 시작할 수 있다. - 각 세션을 다음과 같이 독립적인 주제에 사용할 수 있다. - 새로운 기능 구현 - 코드베이스 구조 조사 - 가능한 구현 방식 비교 - Copilot 앱이나 worktree 사용법 질문 - 원래 작업 세션으로 돌아오면 이전 맥락과 변경 사항을 확인한 뒤 작업을 이어갈 수 있다. - 작업별로 대화를 분리하면 서로 다른 개발 흐름을 섞지 않고 진행 상황을 관리하기 쉽다. ## 캔버스를 이용한 UI 확인과 개선 - UI 작업에서는 코드 검토뿐 아니라 실제 화면을 직접 확인하는 것이 중요하다. - Copilot 앱의 **canvas**는 애플리케이션, 계획, 칸반 보드, 체크리스트 같은 작업 결과물을 대화 옆에서 시각적으로 보여주는 공유형 공간이다. - `/create-canvas Open this app in a browser canvas` 명령으로 별도 터미널이나 브라우저를 열지 않고 애플리케이션을 실행할 수 있다. - **Enable Canvas Dev Mode**를 켜면 캔버스에서 특정 UI 요소를 직접 선택할 수 있다. - **Pick & Polish** 기능을 사용하면 선택한 요소를 다음 요청의 컨텍스트로 전달해 다음과 같은 반복 개선이 가능하다. - 화면의 특정 요소 선택 - 수정 요청 작성 - 변경 결과 확인 - 추가 조정 반복 - 텍스트 기반 설명만으로 UI를 수정하는 것보다 시각적 결과를 기준으로 구체적인 피드백을 제공할 수 있다. ## Agent Merge를 활용한 PR 후속 작업 - 코드 변경이 끝난 뒤에는 pull request, CI, 코드 리뷰 과정이 이어진다. - Copilot 앱의 PR 옵션에서 **Agent Merge**를 활성화하면 에이전트가 PR 진행 상황을 모니터링한다. - 허용할 작업을 선택할 수 있으며, 주요 예시는 다음과 같다. - 리뷰 피드백 반영 - CI 실패 원인 해결 지원 - merge conflict 처리 - 리뷰 중 변경 요청이나 자동화된 검사 실패가 발생하면 Agent Merge가 대응 작업을 수행하고 PR을 병합 가능한 상태로 준비한다. - 필수 검사가 모두 통과한 뒤 사용자가 최종적으로 병합할 수 있다. ## AI 에이전트 기반 개발 workflow - Copilot 앱은 하나의 대화창보다 실제 소프트웨어 개발 과정에 맞춘 작업 공간을 제공한다. - 기본 workflow는 다음과 같이 구성된다. 1. 프로젝트 선택 2. 작업별 에이전트 세션 생성 3. 필요할 때 Quick Chat으로 조사·질문 4. 캔버스에서 실행 결과와 UI 확인 5. PR 생성 6. Agent Merge로 리뷰·CI·충돌 대응 7. 검사 통과 후 병합 - 사용자는 코드 작성뿐 아니라 탐색, 시각적 검증, 리뷰 대응까지 한 환경에서 이어서 진행할 수 있다. 새 기능이나 오래된 backlog 작업을 하나 선택해 프로젝트를 연결하고, 작업별 세션과 캔버스를 활용해 작은 범위부터 시작하는 것이 좋다. 다만 AI가 만든 변경 사항과 테스트 결과는 직접 검토한 뒤 PR을 병합해야 한다.

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

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

캔버스 확장은 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`로 원하는 화면과 동작을 구체적으로 요청해 보는 것이 효과적이다.

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

더 나은 도구가 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% 절감했다. - 글에서는 이 개선이 리뷰 품질을 유지한 상태에서 이루어졌다고 설명한다. ## 실용적인 결론 에이전트 도구를 교체할 때는 도구의 기능만 비교해서는 안 된다. 도구 사용 지침과 에이전트가 따라야 할 탐색 워크플로까지 작업 목적에 맞게 설계해야 하며, 특히 코드 리뷰에서는 “더 많이 읽기”보다 “변경 사항을 검증하는 데 필요한 최소한만 읽기”가 비용과 품질 모두에 유리하다.

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

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가 문서를 작성하더라도 최종 병합은 사람이 담당하도록 설계하는 것이 안전성과 문서 품질을 함께 확보하는 방법이다.

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

모델과 작업별 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 같은 표준 평가뿐 아니라 조직의 코드베이스와 터미널 작업을 반영한 내부 벤치마크를 반복 실행하는 것이 좋습니다. - 단일 실행 결과보다 해결률, 비용, 토큰 사용량, 실행 간 변동을 함께 비교해야 신뢰할 수 있는 판단을 내릴 수 있습니다.

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

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

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배 향상시켰다. - 따라서 데이터 문서, 지표 정의, 사용 규칙 같은 컨텍스트 자산을 단순한 문서가 아니라 분석 시스템의 핵심 구성 요소로 관리해야 한다. 실무적으로는 처음부터 모든 데이터를 자동 분석하려 하기보다, 자주 묻는 도메인부터 표준화된 컨텍스트와 기준 테스트를 구축하는 접근이 적합하다. 또한 여러 쿼리 엔진을 사용한다면 사용자가 엔진을 선택하지 않아도 되도록 에이전트가 질문 특성에 따라 자동 라우팅하도록 설계하는 것이 좋다.

원문 읽기(새 탭에서 열림)
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의 효율성을 높이려면 모든 정보를 매번 다시 보내거나 모든 작업에 가장 큰 모델을 사용하는 대신, 반복 컨텍스트는 캐시하고 도구는 필요할 때 불러오며 작업 난이도에 맞는 모델을 선택하는 것이 효과적입니다. 특히 긴 에이전트 세션에서는 모델 전환으로 캐시가 손실되지 않도록 하는 전략이 비용과 응답 속도 모두에 중요합니다.

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

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

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

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

“정답”이 결정적이지 않을 때 에이전트 행동 검증

자율 에이전트의 실행 과정은 환경, 타이밍, UI 상태에 따라 달라지므로 기존의 결정론적 테스트 방식만으로는 올바른 동작을 안정적으로 검증하기 어렵다. 에이전트가 실제 작업을 성공했는데도 실행 경로가 예상과 다르다는 이유로 테스트가 실패하는 ‘거짓 음성(false negative)’이 발생할 수 있다. 글은 고정된 스크립트 대신 필수 결과와 경로의 구조를 검증하는 독립적인 ‘Trust Layer’를 제안하며, 이를 통해 설명 가능하고 CI에 적합한 에이전트 검증을 구현할 수 있다고 주장한다. ## 에이전트 기반 검증에서 발생하는 문제 - Copilot Coding Agent가 UI, 브라우저, IDE 같은 실제 환경을 조작하면 실행 결과가 매번 동일하지 않다. - 네트워크 지연으로 로딩 화면이 오래 표시되거나, 반대로 즉시 화면이 나타날 수 있다. - 에이전트가 상황에 맞게 대기하고 작업을 완료했더라도, 테스트가 특정 시점이나 순서를 기대하면 실패한다. - 주요 문제는 다음과 같다. - **거짓 음성:** 작업은 성공했지만 테스트가 실패로 판정한다. - **취약한 인프라:** 렌더링, 타이밍, 네트워크 같은 환경 잡음이 결과에 영향을 준다. - **컴플라이언스 함정:** 올바른 결과를 냈어도 사전에 기록된 에이전트 행동과 다르면 회귀로 오인된다. - 에이전트의 정확성은 정해진 단계를 그대로 따르는 것이 아니라, 필수적인 결과를 안정적으로 달성하는지로 판단해야 한다. ## 기존 테스트 방식이 자율 에이전트에 맞지 않는 이유 - **Assertion 기반 테스트** - 모든 검증 조건을 사람이 직접 작성해야 한다. - 가능한 모든 대체 경로를 명세하기 어렵다. - **Record-and-replay** - 실행을 녹화된 순서와 비교하므로 사소한 타이밍·렌더링 변화에도 실패한다. - **시각적 회귀 테스트** - 스크린샷 차이는 감지하지만, 해당 변화가 작업의 의미나 최종 결과에 영향을 주는지는 이해하지 못한다. - **ML 오라클** - 많은 학습 사례가 필요하다. - 실패 판정의 근거를 설명하기 어려운 블랙박스가 되기 쉽다. - 이 방식들은 모두 “정확성은 특정한 관찰 상태와 순서를 재현하는 것”이라는 공통 가정을 갖는다. - 하지만 에이전트 시스템에서는 서로 다른 실행 경로가 동일한 올바른 결과로 이어질 수 있다. ## 필수 상태와 선택적 변형의 구분 에이전트 동작을 검증하려면 모든 상태를 동일하게 취급하지 말고, 성공에 반드시 필요한 요소와 환경에 따라 달라지는 요소를 분리해야 한다. - **필수 상태(Essential states)** - 성공을 위해 반드시 도달해야 하는 상태다. - 예를 들어 VS Code 검색 작업에서는 최종적으로 ‘검색 결과’ 화면에 도달해야 한다. - **선택적 변형(Optional variations)** - 로딩 스피너, 일시적인 로딩 화면, 장식적 UI 변화처럼 성공 여부와 직접 관련 없는 상태다. - **수렴 경로(Convergent paths)** - 단축키 사용, 메뉴 선택 등 서로 다른 절차가 동일한 최종 상태로 합쳐지는 경우다. - 로딩 화면이 나타났는지는 중요하지 않지만, 검색 결과가 표시되었는지는 작업의 성공을 결정한다. - 따라서 검증 대상은 실행 과정 전체가 아니라 성공을 보장하는 논리적 구조여야 한다. ## Dominator 분석을 활용한 필수 행동 추출 필수 상태와 부수적 상태를 자동으로 구분하기 위해 컴파일러 이론의 **Dominator 관계**를 활용할 수 있다. - 제어 흐름 그래프에서 노드 A가 노드 B를 지배(dominates)한다는 것은 시작점에서 B로 가는 모든 경로가 A를 거쳐야 한다는 뜻이다. - 에이전트의 실행 기록을 그래프로 표현하면 다음을 식별할 수 있다. - 모든 성공 경로에 공통으로 나타나는 필수 상태 - 일부 경로에만 등장하는 선택적 상태 - 서로 다른 실행 경로가 다시 합쳐지는 지점 - 이 분석을 통해 테스트가 확인해야 할 최소한의 성공 조건을 추출할 수 있다. - 또한 “왜 이 실행을 성공 또는 실패로 판단했는가”를 그래프 구조로 설명할 수 있어, 단순한 블랙박스 판정보다 신뢰성이 높다. ## 스크립트가 아닌 실행 그래프로 모델링 - 자율 에이전트의 행동은 고정된 1차원 스크립트보다 여러 분기와 수렴 지점을 가진 그래프로 보는 편이 적합하다. - 그래프 기반 모델은 특정 순서를 강제하지 않고, 서로 다른 행동 경로가 같은 필수 결과에 도달했는지를 평가할 수 있다. - 이 접근은 에이전트의 자유로운 문제 해결 능력을 유지하면서도, CI 파이프라인에서는 반드시 충족되어야 할 결과를 엄격하게 검증할 수 있는 기반이 된다. - 글에서 제안하는 Trust Layer는 이러한 실행 그래프를 바탕으로 우연한 환경 차이와 실제 기능 실패를 구분하는 역할을 한다. ## 실용적인 적용 방향 - 에이전트 테스트를 작성할 때 모든 중간 화면과 클릭 순서를 고정하지 않는다. - 대신 다음을 명확히 정의한다. - 반드시 도달해야 하는 최종 상태 - 작업 성공을 입증하는 핵심 데이터나 UI 상태 - 무시할 수 있는 로딩·렌더링 변화 - 허용 가능한 대체 실행 경로 - CI에서는 기록된 경로의 일치 여부보다 필수 상태의 도달 여부와 상태 간 논리적 관계를 검증하는 것이 적절하다. - 이를 적용하면 환경 변화로 인한 불필요한 실패를 줄이고, 에이전트가 실제로 작업에 실패한 경우에는 더 정확하게 감지할 수 있다.

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

AI 에이전트 해킹: GitHub Secure Code Game으로 에이전틱 AI 보안 기술 강화하기

에이전트형 AI는 파일 접근, 웹 검색, API 호출, 셸 명령, 다른 에이전트와의 협업까지 수행하므로 기존 LLM보다 훨씬 넓은 공격면을 가진다. GitHub Secure Code Game 시즌 4는 의도적으로 취약하게 만든 AI 비서 ‘ProdBot’을 통해 사용자가 공격자 관점에서 에이전트 보안 문제를 체험하도록 설계됐다. 핵심 목표는 단순히 특정 취약점을 외우는 것이 아니라, 실제 에이전트 시스템에서 위험한 설계와 공격 패턴을 발견하는 감각을 기르는 것이다. ## 에이전트형 AI의 등장과 보안 우려 - OpenClaw와 같은 개인용 AI 비서는 다음과 같은 작업을 수행한다. - 이메일과 일정 관리 - 웹 검색 및 브라우징 - 셸 명령 실행 - 플러그인 작성 - WhatsApp·Telegram 등을 통한 사용자 명령 처리 - 이러한 자율성과 편의성은 악성 입력과 결합될 경우 심각한 위험으로 이어질 수 있다. - 에이전트가 접근해서는 안 되는 파일을 읽도록 유도 - 악성 웹 페이지가 에이전트의 지시사항을 덮어씀 - 다중 에이전트 환경에서 한 에이전트의 오염된 데이터를 다른 에이전트가 신뢰 - 에이전트는 단순히 텍스트를 생성하는 모델이 아니라 실제 시스템과 상호작용하므로, 공격 결과가 데이터 유출이나 원격 코드 실행으로 확대될 수 있다. ## Secure Code Game의 발전 - Secure Code Game은 개발자가 의도적으로 취약한 코드를 공격하고 수정하면서 보안을 학습하는 무료 오픈소스 에디터 과정이다. - 시즌별 주제는 AI와 개발 환경의 변화에 맞춰 확장됐다. - 시즌 1: 일반적인 보안 코딩 - 시즌 2: JavaScript, Python, Go, GitHub Actions 등 여러 기술 스택 - 시즌 3: 악성 프롬프트와 LLM 보안 - 시즌 4: 자율적으로 행동하는 AI 에이전트 보안 - 지금까지 업계, 오픈소스, 학계에서 10,000명 이상의 개발자가 참여했다. - 시즌 4는 웹 브라우징, API 호출, 도구 사용, 에이전트 간 협업 등 에이전트의 실제 기능을 보안 학습에 반영한다. ## 에이전트 보안이 중요한 이유 - OWASP의 2026년 에이전트 애플리케이션 주요 위험에는 다음 문제가 포함된다. - 에이전트 목표 탈취 - 도구 오용 - 신원 및 권한 악용 - 영구 메모리 오염 - Dark Reading 설문에서는 사이버보안 전문가의 48%가 2026년 말까지 에이전트형 AI를 가장 큰 공격 벡터로 예상했다. - Cisco 보고서에 따르면 조직의 83%가 에이전트형 AI 도입을 계획했지만, 안전하게 배포할 준비가 됐다고 답한 비율은 29%에 불과했다. - 빠른 도입 속도와 낮은 보안 준비도의 격차가 새로운 취약점이 발생하는 환경을 만든다. - 따라서 방어 설계뿐 아니라 공격자가 어떤 방식으로 시스템을 악용하는지 직접 이해하는 것이 중요하다. ## ProdBot: 의도적으로 취약한 AI 비서 - 시즌 4의 실습 대상인 ProdBot은 터미널에서 실행되는 생산성 AI 비서다. - 다음 기능을 단계적으로 제공한다. - 자연어를 bash 명령으로 변환하고 실행 - 가상 웹 환경 탐색 - MCP 서버 연결 - 조직 승인 스킬 실행 - 세션 간 지속 메모리 저장 - 여러 전문 에이전트의 작업 조정 - 사용자의 최종 목표는 ProdBot이 노출해서는 안 되는 `password.txt`의 내용을 읽도록 만드는 것이다. - 모든 상호작용은 CLI에서 자연어로 진행되므로 별도의 AI나 프로그래밍 경험 없이도 실험할 수 있다. ## 다섯 단계로 확장되는 공격면 - **Level 1 — 셸 명령과 샌드박스** - ProdBot이 샌드박스 내부에서 bash 명령을 생성·실행한다. - 핵심 과제는 샌드박스 탈출 가능성을 찾는 것이다. - **Level 2 — 웹 접근** - 뉴스, 금융, 스포츠, 쇼핑 사이트로 구성된 가상 인터넷을 탐색한다. - 신뢰할 수 없는 웹 콘텐츠가 에이전트의 행동이나 지시를 오염시킬 수 있다. - **Level 3 — MCP 서버** - 주식 시세, 웹 브라우징, 클라우드 백업 등의 외부 도구 제공자와 연결된다. - 기능이 늘어나는 만큼 외부 도구의 권한과 입력 검증 문제가 새로운 진입점이 된다. - **Level 4 — 승인된 스킬과 지속 메모리** - 사전 제작된 자동화 플러그인을 실행하고 사용자 선호를 세션 간 기억한다. - 조직의 승인이나 기존 신뢰가 실제로 안전성을 보장하는지 검증해야 한다. - **Level 5 — 다중 에이전트 통합** - 6개의 전문 에이전트, 3개의 MCP 서버, 3개의 스킬, 가상의 오픈소스 프로젝트 웹이 결합된다. - 모든 에이전트가 샌드박스 처리되고 데이터가 사전 검증됐다는 가정을 공격 관점에서 시험한다. ## 실제 위협과 학습 목표 - 각 단계의 취약점은 에이전트 시스템이 기능을 추가하며 실제로 마주할 수 있는 공격 패턴을 반영한다. - 예로 언급된 `CVE-2026-25253`(CVSS 8.8, High, “ClawBleed”)는 악성 링크를 통해 인증 토큰을 탈취하고 OpenClaw 인스턴스를 완전히 장악할 수 있었던 원격 코드 실행 취약점이다. - 게임의 목적은 특정 익스플로잇 하나를 암기하는 것이 아니다. - 에이전트 아키텍처 검토 - 도구 통합 감사 - 외부 콘텐츠와 메모리의 신뢰성 평가 - 에이전트 간 데이터 전달 검증 - 이런 과정을 통해 실제 운영 환경에서 목표 탈취, 권한 남용, 프롬프트 오염, 도구 악용과 같은 패턴을 빠르게 식별하는 보안 감각을 기를 수 있다. 에이전트형 AI를 도입할 때는 기능 구현보다 먼저 도구 권한, 샌드박스 경계, 외부 입력 검증, 메모리 격리, 에이전트 간 신뢰 모델을 점검해야 한다. ProdBot 같은 공격·방어 실습을 통해 실제 시스템의 실패 가능성을 사전에 경험하는 것이 효과적인 준비 방법이다.

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

GitHub Copilot CLI, 세컨드 오피니언을 위해 여러 모델 제품군 결합

GitHub Copilot CLI가 주 모델과 다른 AI 계열의 모델을 활용해 작업을 검토하는 실험 기능 **Rubber Duck**을 공개했습니다. Rubber Duck은 계획 수립, 복잡한 구현, 테스트 작성 후처럼 오류를 조기에 발견하기 좋은 시점에 독립적인 피드백을 제공합니다. 평가 결과 Claude Sonnet과 GPT-5.4 기반 Rubber Duck 조합은 Sonnet과 Opus 단독 실행 성능 차이의 74.7%를 줄였습니다. ## 자신감 있는 실수가 누적되는 문제 - 코딩 에이전트는 일반적으로 다음 순서로 작업합니다. - 요구사항 분석 - 계획 수립 - 구현 - 테스트 - 문제 발생 시 반복 수정 - 초기 계획의 잘못된 가정이나 비효율은 이후 구현의 기반이 되어 오류를 연쇄적으로 키울 수 있습니다. - 에이전트가 자신의 결과를 스스로 검토하는 방식도 도움이 되지만, 동일한 모델은 같은 학습 데이터와 편향, 맹점을 공유합니다. - 따라서 자기 검토만으로는 발견하기 어려운 문제를 찾기 위해 다른 모델 계열의 관점이 필요합니다. ## 다른 모델 계열을 활용하는 Rubber Duck - Rubber Duck은 주 에이전트의 계획과 작업을 검토하는 전문 리뷰 에이전트입니다. - 현재 Claude 모델을 주 오케스트레이터로 선택하면 Rubber Duck은 GPT-5.4를 사용합니다. - 검토 결과는 다음과 같은 고가치 우려 사항을 짧고 집중적으로 제시합니다. - 주 에이전트가 놓친 세부 사항 - 다시 검토해야 할 가정 - 잠재적인 엣지 케이스 - 현재 Claude Opus, Sonnet, Haiku를 주 모델로 사용할 때 활성화할 수 있으며, 향후 다른 모델 조합도 실험할 예정입니다. ## 복잡한 작업에서의 효과 - SWE-Bench Pro의 실제 오픈소스 프로젝트 기반 대형 코딩 문제로 평가했습니다. - Claude Sonnet 4.6과 GPT-5.4 Rubber Duck 조합은 Claude Opus 4.6 단독 실행과 유사한 해결률을 기록했습니다. - Sonnet과 Opus의 성능 차이 중 74.7%를 줄였습니다. - 특히 다음 조건의 작업에서 효과가 컸습니다. - 3개 이상의 파일을 수정하는 작업 - 70단계 이상이 필요한 장기 작업 - 복잡한 리팩터링과 아키텍처 변경 - 성능 개선 폭은 일반적으로 Sonnet 기준 3.8%, 가장 어려운 문제에서는 4.8%였습니다. ## Rubber Duck이 발견한 오류 사례 - **스케줄러의 구조적 오류** - 스케줄러가 시작 직후 종료되어 작업을 하나도 실행하지 못하는 문제를 발견했습니다. - 수정하더라도 내부 작업 중 하나가 무한 루프라는 추가 문제도 확인했습니다. - **반복문으로 인한 데이터 손실** - 반복문이 매번 같은 `dict` 키를 덮어쓰는 버그를 찾았습니다. - 그 결과 Solr 검색 요청에서 네 개의 facet 범주 중 세 개가 조용히 사라졌습니다. - **파일 간 데이터 흐름 단절** - 여러 파일이 Redis 키를 읽지만 새 코드가 해당 키를 더 이상 기록하지 않는 문제를 발견했습니다. - 배포 후 이메일 확인 UI와 정리 작업이 조용히 고장 날 수 있는 상황이었습니다. ## 검토가 실행되는 시점 Rubber Duck은 필요성이 높은 체크포인트에서 자동으로 호출되거나 사용자가 직접 요청할 수 있습니다. - **계획 작성 후** - 잘못된 설계 결정을 구현 전에 발견해 후속 오류의 누적을 막습니다. - **복잡한 구현 후** - 여러 파일에 걸친 코드의 엣지 케이스와 구조적 문제를 점검합니다. - **테스트 작성 후, 실행 전** - 테스트 커버리지의 공백이나 잘못된 단정을 찾아냅니다. - **에이전트가 작업 루프에 빠졌을 때** - 진전이 없는 상황에서 새로운 관점을 제공해 막힌 지점을 해결합니다. - **사용자 요청 시** - 사용자가 언제든 작업을 비판적으로 검토하도록 요청할 수 있습니다. - Copilot은 피드백을 반영한 뒤 무엇이 어떻게 바뀌었는지 보여줍니다. ## 사용 방법과 적합한 활용 사례 - GitHub Copilot CLI를 설치한 뒤 `/experimental` 명령으로 실험 기능을 활성화합니다. - 모델 선택기에서 Claude 모델을 선택하고 GPT-5.4 사용 권한이 있어야 합니다. - Rubber Duck은 자동으로 호출되거나 “작업을 검토해 달라”고 요청해 수동 실행할 수 있습니다. - 특히 다음 작업에 적합합니다. - 복잡한 리팩터링 - 아키텍처 변경 - 실패 비용이 큰 고위험 작업 - 테스트 커버리지 검증 - 구현 전 계획에 대한 독립적인 의견 확인 Rubber Duck은 코딩 에이전트를 단순히 더 오래 실행하는 대신, 서로 다른 모델 계열의 관점으로 중요한 의사결정을 교차 검증하려는 접근입니다. 복잡하거나 영향 범위가 큰 작업에서는 계획 단계와 테스트 실행 전에 검토를 요청하는 것이 실용적인 활용법입니다.

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

Copilot Applied Science의 에이전트 주도 개발

GitHub Copilot Applied Science 팀의 Tyler McGoffin은 코딩 에이전트를 활용해 벤치마크 결과 분석에 필요한 지적 반복 작업을 자동화한 프로젝트 `eval-agents`를 만들었다. 핵심은 에이전트를 단순한 코드 생성기가 아니라 계획·구현·검증에 참여하는 협업자로 활용하고, 에이전트가 기여하기 쉬운 저장소 구조를 만드는 것이다. 그 결과 3일도 안 되어 5명이 11개 에이전트와 4개 스킬을 추가하고, 345개 파일에 걸쳐 약 2만 8천 줄의 변경을 만들어냈다. ## 반복적인 벤치마크 분석에서 `eval-agents` 탄생 - 연구자는 TerminalBench2, SWEBench-Pro 같은 코딩 에이전트 평가 벤치마크를 분석한다. - 각 평가 작업은 에이전트의 사고 과정과 행동을 담은 trajectory로 기록되며, 대개 수백 줄의 `.json` 파일로 저장된다. - 수십 개 작업과 여러 번의 벤치마크 실행을 합치면 분석 대상이 수십만 줄에 달한다. - 기존에는 Copilot으로 trajectory에서 패턴을 먼저 찾은 뒤 사람이 직접 조사해 읽어야 할 분량을 수백 줄로 줄였다. - 이 반복 과정을 에이전트가 자동 수행하도록 만든 도구가 `eval-agents`다. ## 프로젝트 설계 목표 - 에이전트를 쉽게 공유하고 사용할 수 있도록 구성한다. - 새로운 에이전트를 쉽게 작성할 수 있도록 한다. - 사람보다 코딩 에이전트가 프로젝트 기여의 주요 수단이 되도록 설계한다. - 특히 세 번째 목표를 적용하자 프로젝트 자체의 사용성과 협업성도 함께 좋아졌다. - 과학자와 엔지니어가 각자의 필요에 맞는 에이전트와 기능을 직접 추가할 수 있는 기반이 마련됐다. ## 코딩 에이전트를 중심으로 한 개발 환경 - 코딩 에이전트: Copilot CLI - 사용 모델: Claude Opus 4.6 - IDE: VS Code - Copilot SDK를 사용해 Copilot CLI의 도구, MCP 서버, 사용자 정의 도구와 스킬 등록 기능을 재활용했다. - 에이전트 실행 기반을 직접 처음부터 만들지 않아도 되어 에이전트 생성 속도를 높일 수 있었다. ## 효과적인 프롬프트 전략 - 에이전트는 범위가 명확한 작업에는 강하지만, 복잡하고 고차원적인 문제에는 충분한 안내가 필요하다. - 짧은 요구사항보다 문제를 고민하는 과정, 전제, 우려 사항을 자세히 설명하는 대화형 프롬프트가 효과적이다. - 바로 구현을 지시하기보다 계획 모드에서 조사와 설계를 먼저 진행하게 하는 것이 좋다. - 예를 들어 테스트가 에이전트의 변경에 맞춰 부적절하게 수정되는 문제를 해결하기 위해, 계획 모드에서 에이전트가 건드릴 수 없는 보호된 테스트 영역을 설계하도록 했다. - 그 대화의 결과로 사람이 승인해야만 수정할 수 있는 계약 테스트와 유사한 회귀 방지 장치가 만들어졌다. - 결론적으로 효과적인 인간 엔지니어에게 필요한 설명, 사고 유도, 검토 과정이 에이전트에도 동일하게 중요하다. ## 에이전트 우선 저장소를 위한 아키텍처 전략 - 에이전트 중심 프로젝트에서는 새 기능보다 코드 구조 개선, 리팩터링, 문서화, 테스트 작성이 더 중요한 기반 작업이 된다. - 명확한 이름과 파일 구조는 에이전트가 코드를 탐색하고 변경하기 쉽게 만든다. - 기능과 패턴을 문서화하면 에이전트가 프로젝트의 규칙과 설계 의도를 더 잘 따를 수 있다. - 발견된 문제를 테스트 케이스로 남기면 이후 에이전트의 변경으로 인한 회귀를 방지할 수 있다. - 에이전트가 기능을 빠르게 추가할수록 사람이 죽은 코드와 불필요한 복잡성을 정리하는 작업도 병행해야 한다. - 잘 관리된 저장소에서는 Copilot을 통한 기능 전달이 쉬워지므로, 과거에 미뤄두었던 유지보수 작업이 개발 생산성의 핵심 요소가 된다. ## 짧은 기간에 이루어진 협업 성과 - 처음 참여한 팀원 5명이 3일 이내에 프로젝트에 기여했다. - 새로 추가된 항목: - 에이전트 11개 - 스킬 4개 - 과학자의 추론 흐름을 표현하는 `eval-agent workflows` - 전체 변경 규모는 345개 파일에서 `+28,858/-2,884`줄이었다. - 이는 에이전트에게 적절한 개발 환경과 구조를 제공하면 새로운 기능과 협업을 매우 빠르게 확장할 수 있음을 보여준다. 에이전트를 효과적으로 활용하려면 좋은 프롬프트만으로는 부족하다. 계획 모드와 상세한 대화를 적극 활용하고, 문서·테스트·리팩터링을 지속해 에이전트가 이해하기 쉬운 저장소를 유지하는 것이 실용적인 출발점이다.

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