GitHub/ai-agent

13 개의 포스트

github

GitHub Copilot 앱으로 첫 프롬프트 작성하기 (새 탭에서 열림)

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

github

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

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

github

하네스만 있으면 된다 (대부분) (새 탭에서 열림)

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 설정을 작업 끝까지 유지한다. - 프로토타입으로 요구사항을 구체화한 뒤 계획과 구현 단계로 넘어간다. 어진 글의 본문은 “계획 수립” 섹션 초입에서 끝나므로, 이후 계획·구현 단계의 구체적인 내용은 제공된 자료만으로 확인할 수 없다.

github

초보자를 위한 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을 병합해야 한다.

github

캔버스로 인터랙티브한 경험을 만드는 방법 (새 탭에서 열림)

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

github

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

github

내부 데이터 분석 에이전트를 구축한 방법 (새 탭에서 열림)

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

github

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은 코딩 에이전트를 단순히 더 오래 실행하는 대신, 서로 다른 모델 계열의 관점으로 중요한 의사결정을 교차 검증하려는 접근입니다. 복잡하거나 영향 범위가 큰 작업에서는 계획 단계와 테스트 실행 전에 검토를 요청하는 것이 실용적인 활용법입니다.

github

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`줄이었다. - 이는 에이전트에게 적절한 개발 환경과 구조를 제공하면 새로운 기능과 협업을 매우 빠르게 확장할 수 있음을 보여준다. 에이전트를 효과적으로 활용하려면 좋은 프롬프트만으로는 부족하다. 계획 모드와 상세한 대화를 적극 활용하고, 문서·테스트·리팩터링을 지속해 에이전트가 이해하기 쉬운 저장소를 유지하는 것이 실용적인 출발점이다.

github

Squad가 리포지토리 내에서 협업하는 AI 에이전트를 실행하는 방법 (새 탭에서 열림)

Squad는 GitHub Copilot 기반의 여러 AI 에이전트를 저장소 안에 직접 구성해, 설계·구현·테스트·문서화를 협업 방식으로 수행하게 하는 오픈소스 도구다. 복잡한 오케스트레이션 인프라나 고급 프롬프트 설계 없이 `squad init`만으로 팀을 구성할 수 있으며, 저장소 파일을 공유 메모리로 활용한다. 다만 완전한 자동화가 아니라 사용자가 최종적으로 모든 변경 사항과 풀 리퀘스트를 검토하고 병합해야 한다. ## 저장소 안에 구성되는 AI 개발팀 - 전역 설치: ```bash npm install -g @bradygaster/squad-cli ``` - 저장소별 초기화: ```bash squad init ``` - 초기화하면 리드, 프런트엔드 개발자, 백엔드 개발자, 테스터 등 역할별 에이전트가 생성된다. - 사용자는 자연어로 작업을 요청하고, 코디네이터 에이전트가 적절한 전문가에게 작업을 분배한다. - 각 전문가는 별도의 브랜치와 파일을 사용해 구현, 테스트, 문서화 등을 병렬로 진행한다. ## 에이전트 간 작업 조정과 독립적 검토 - 예를 들어 JWT 인증을 요청하면: - 백엔드 에이전트는 refresh token과 bcrypt를 포함한 인증 기능을 구현한다. - 테스트 에이전트는 테스트 코드를 작성하고 실행한다. - 문서화 에이전트는 변경 내용을 정리해 풀 리퀘스트를 생성한다. - 테스트 실패 시 원래 구현자가 자기 코드를 스스로 수정하지 못하도록 검토 프로토콜을 적용할 수 있다. - 다른 에이전트가 별도의 컨텍스트에서 문제를 수정하므로, 자기검토보다 독립적인 리뷰에 가깝다. - 사용자는 중간 결과를 모두 검토하기보다 내부 검증 과정을 통과한 풀 리퀘스트를 검토할 수 있다. - 에이전트가 잘못된 가정을 할 수 있으므로, 최종 검토와 병합은 여전히 사람이 담당한다. ## `decisions.md`를 활용한 공유 메모리 - 실시간 대화나 벡터 데이터베이스 대신 저장소의 `decisions.md`에 아키텍처 결정을 기록한다. - 라이브러리 선택, 명명 규칙, 데이터베이스 연결 방식 같은 결정이 구조화된 블록으로 누적된다. - 이 방식의 장점: - 결정 사항이 지속적으로 보존된다. - Git으로 버전 관리할 수 있다. - 에이전트가 어떤 근거로 작업했는지 추적할 수 있다. - 연결이 끊기거나 세션이 재시작되어도 컨텍스트를 복구할 수 있다. - 저장소 파일을 팀의 “공유 두뇌”로 사용하는 비동기 협업 모델이다. ## 컨텍스트 분할 대신 컨텍스트 복제 - 한 에이전트가 설계, 구현, 테스트, 관리까지 모두 맡으면 컨텍스트 창이 메타 작업으로 가득 차고 환각 가능성이 커진다. - Squad의 코디네이터는 실제 작업을 수행하지 않고 전문가를 호출하는 얇은 라우터 역할을 한다. - 각 전문가는 별도의 추론 호출과 컨텍스트 창을 사용한다. - 지원 모델에서는 에이전트 하나당 최대 약 200K 토큰의 컨텍스트를 활용할 수 있다. - 하나의 컨텍스트를 여러 역할이 나누는 대신, 각 에이전트가 필요한 저장소 컨텍스트를 독립적으로 복제해 병렬 추론한다. ## 파일 기반의 명시적 에이전트 기억 - 에이전트의 기억은 모델 가중치나 숨겨진 세션 상태에 의존하지 않는다. - `.squad/` 폴더에 다음과 같은 텍스트 파일을 저장한다. - **Charter**: 에이전트의 역할과 정체성 - **History**: 에이전트가 과거에 수행한 작업 - **Team decisions**: 팀 전체가 공유하는 결정 사항 - 이 파일들은 코드와 함께 버전 관리되므로 에이전트의 행동 근거를 확인할 수 있다. - 저장소를 복제하면 코드뿐 아니라 프로젝트에 맞게 온보딩된 AI 팀의 기억도 함께 가져올 수 있다. ## 다중 에이전트 개발의 진입 장벽 완화 - 기존 다중 에이전트 시스템은 오케스트레이션 계층, 프레임워크, 벡터 데이터베이스 등을 직접 구성해야 하는 경우가 많다. - Squad는 CLI 명령 두 번으로 저장소에 사전 구성된 팀을 추가한다. - 복잡한 프롬프트 설계나 별도의 중앙 인프라 없이 바로 작업을 위임할 수 있다. - 저장소에 남는 결정 기록과 에이전트 이력 덕분에 동작을 비교적 쉽게 점검하고 재현할 수 있다. 실용적으로는 반복적인 구현·테스트·문서화 작업이 많은 저장소에서 Squad를 시도해볼 만하다. 다만 AI가 생성한 모든 변경 사항을 자동 병합하기보다는, 풀 리퀘스트와 테스트 결과를 사람이 확인하는 협업 도구로 사용하는 것이 적절하다.

github

‘텍스트로서의 AI’ 시대는 끝났다. 실행이 새로운 인터페이스다. (새 탭에서 열림)

이 글은 AI가 단순히 텍스트를 주고받는 도구를 넘어, 계획을 세우고 도구를 호출하며 실제 작업을 수행하는 실행 계층으로 발전하고 있다고 주장합니다. GitHub Copilot SDK를 사용하면 애플리케이션에 Copilot CLI의 검증된 계획·실행 엔진을 직접 내장할 수 있습니다. 이를 통해 개발자는 고정된 자동화 스크립트나 자체 오케스트레이션 계층을 만들지 않고도, 제약 조건 안에서 적응적으로 동작하는 에이전트형 시스템을 구축할 수 있습니다. ## 텍스트 기반 AI에서 실행 기반 AI로 - 기존 AI 사용 방식은 텍스트를 입력하고 텍스트를 받은 뒤, 사용자가 다음 행동을 직접 결정하는 구조였습니다. - 실제 운영 소프트웨어는 다음과 같은 실행 루프를 필요로 합니다. - 작업 계획 수립 - 도구 호출 - 파일 및 시스템 변경 - 명령 실행 - 오류 복구 - 실행 중 상황 변화에 따른 대응 - 따라서 AI의 핵심 인터페이스가 텍스트가 아니라, 제약 조건과 관찰 가능성을 갖춘 실행으로 바뀌고 있습니다. ## 여러 단계 작업을 에이전트에 위임 - 기존 스크립트는 작업 단계가 고정되어 있을 때는 유용하지만, 상황에 따라 흐름이 바뀌거나 오류 복구가 필요하면 취약해집니다. - Copilot SDK를 사용하면 애플리케이션이 구체적인 절차 대신 작업의 의도와 제약 조건을 전달할 수 있습니다. - 예를 들어 “이 저장소를 릴리스 준비 상태로 만들어라”라고 요청하면 에이전트가 다음을 수행할 수 있습니다. - 저장소 구조 탐색 - 필요한 작업 계획 수립 - 파일 수정 - 명령 실행 - 실패 발생 시 대안 적용 및 복구 - 고정된 예외 처리를 직접 작성하지 않고도, 규모가 커지는 업무 흐름에 적응하는 자동화를 구현할 수 있다는 점이 핵심입니다. ## 구조화된 런타임 컨텍스트 활용 - 시스템 로직을 프롬프트에 계속 추가하면 프롬프트가 복잡하고 취약해지며, 테스트와 유지보수가 어려워집니다. - Copilot SDK는 컨텍스트를 텍스트가 아닌 구조화되고 조합 가능한 도구와 데이터로 제공합니다. - 애플리케이션은 다음과 같은 방식으로 실행 환경을 확장할 수 있습니다. - 도메인 전용 도구 및 에이전트 스킬 정의 - Model Context Protocol(MCP)을 통한 도구 연결 - 실행 시점에 필요한 컨텍스트 검색 - 예를 들어 에이전트가 직접 다음 정보를 조회할 수 있습니다. - 서비스 소유 팀 - 과거 의사결정 기록 - 의존성 그래프 - 내부 API 스키마 - 권한과 안전 제약 조건 - MCP는 에이전트가 실제 시스템과 권한이 부여된 데이터에 근거해 행동하도록 연결하는 기반 역할을 합니다. ## IDE 밖에 실행 기능 내장 - AI 기능은 더 이상 IDE나 터미널 안에서만 제공될 필요가 없습니다. - Copilot SDK를 활용하면 다음과 같은 애플리케이션에 에이전트 실행을 통합할 수 있습니다. - 데스크톱 애플리케이션 - 사내 운영 도구 - 백그라운드 서비스 - SaaS 플랫폼 - 이벤트 기반 시스템 - 파일 변경, 배포 이벤트, 사용자 동작 등을 감지한 뒤 애플리케이션에서 Copilot을 프로그래밍 방식으로 호출할 수 있습니다. - 결과적으로 AI는 별도의 보조 창이 아니라 제품 내부에서 실행되는 인프라가 됩니다. ## 애플리케이션 아키텍처의 변화 - Copilot SDK는 Copilot CLI를 구동하는 계획·실행 엔진을 애플리케이션의 프로그래밍 가능한 계층으로 제공합니다. - 개발자는 매번 오케스트레이션 로직을 새로 구축하기보다, 애플리케이션이 달성해야 할 목표와 실행 가능한 범위를 정의하는 데 집중할 수 있습니다. - 다만 실제 운영 환경에서는 도구 권한, 안전 제약, 실행 결과 관찰, 오류 처리 등을 명확히 설계해야 합니다. Copilot SDK는 AI를 “답변을 생성하는 기능”에서 “실제 업무를 수행하는 시스템 구성 요소”로 확장하려는 접근입니다. 반복 작업이나 복잡한 운영 흐름에 적용할 때는 의도 중심의 에이전트 실행, MCP 기반의 구조화된 컨텍스트, 명확한 권한·안전 제약을 함께 설계하는 것이 좋습니다.

github

GitHub 에이전틱 워크플 (새 탭에서 열림)

GitHub Agentic Workflows는 자연어로 작성한 Markdown 지시를 GitHub Actions에서 코딩 에이전트가 실행하도록 해 저장소 업무를 자동화하는 기술이다. 이슈 분류, 문서 갱신, 테스트 보강, CI 실패 분석처럼 기존의 결정론적 YAML 워크플로로는 처리하기 어려운 작업을 자동화하면서도, 권한·샌드박스·검토 절차를 통해 통제할 수 있도록 설계됐다. GitHub는 이를 CI/CD를 대체하는 것이 아니라 보완하는 “Continuous AI”로 소개하며, 2026년 2월 기술 프리뷰로 공개했다. ## Markdown으로 정의하는 에이전트 기반 저장소 자동화 - 원하는 결과를 일반 Markdown으로 설명하고, 이를 저장소의 자동화 워크플로로 등록한다. - 워크플로는 GitHub Actions에서 실행되며, 설정에 따라 다음과 같은 코딩 에이전트를 사용할 수 있다. - Copilot CLI - Claude Code - OpenAI Codex - 기존 개발팀이 이미 사용하는 GitHub Actions의 권한 관리, 로그, 감사 기능, 저장소 컨텍스트를 그대로 활용한다. - 복잡한 절차를 직접 YAML로 세부 구현하기보다, 사람이 의도와 목표를 설명하고 에이전트가 저장소를 분석해 작업을 수행하는 방식이다. ## 지속적인 저장소 관리에 활용되는 작업 - **이슈 트리아지** - 새 이슈를 요약하고 라벨을 붙인다. - 관련 담당자나 적절한 처리 경로로 이슈를 분류한다. - **문서 유지 관리** - 코드 변경 사항을 분석해 README와 기술 문서를 최신 상태로 갱신한다. - **코드 단순화** - 반복적으로 개선 가능한 코드를 식별한다. - 개선안을 pull request로 생성해 사람이 검토하도록 한다. - **테스트 개선** - 테스트 커버리지를 평가한다. - 가치가 높은 테스트를 추가하도록 제안하거나 pull request를 만든다. - **품질 관리** - CI 실패 원인을 조사한다. - 문제에 맞는 구체적인 수정안을 제안한다. - **정기 보고** - 저장소의 건강 상태, 활동량, 주요 추세를 정기적으로 분석하고 보고서를 작성한다. ## Continuous AI와 기존 CI/CD의 관계 - GitHub는 에이전트 기반 자동화를 소프트웨어 개발 생명주기에 AI를 지속적으로 결합하는 **Continuous AI**라고 부른다. - Agentic Workflow는 빌드, 테스트, 릴리스처럼 결과가 명확하고 결정론적인 CI/CD 파이프라인을 대체하지 않는다. - 대신 다음과 같이 판단과 분석이 필요한 작업을 담당한다. - 어떤 이슈가 중요한지 판단 - 문서와 코드의 불일치 탐색 - 실패 원인 분석 - 개선 가치가 높은 테스트나 리팩터링 선별 - 따라서 기존 CI/CD는 안정적인 검증과 배포를 담당하고, Agentic Workflow는 저장소 운영과 엔지니어링 작업의 지능화를 담당하는 구조다. ## 권한과 안전장치 - 안전성과 통제는 설계의 핵심 요소로 제시된다. - 워크플로는 기본적으로 **읽기 전용 권한**으로 실행된다. - 파일 수정, 이슈 변경, pull request 생성 등 쓰기 작업은 명시적인 승인이 필요하다. - 쓰기 작업은 **safe outputs**를 통해 사전에 허용된 형태로 제한하고, 사람이 검토할 수 있도록 한다. - 샌드박스 실행, 권한 제어, 감사 로그, 실행 기록 등을 활용해 의도하지 않은 동작과 프롬프트 인젝션 공격에 대비한다. - 결과적으로 에이전트가 자율적으로 작업하더라도, 실행 시점과 변경 범위를 저장소 관리자가 정의한 경계 안에 둘 수 있다. ## 실제 적용 사례와 기대 효과 - Home Assistant에서는 대규모 이슈를 분석해 반복적으로 나타나는 문제와 사용자에게 영향이 큰 이슈를 파악하는 데 활용한다. - CNCF는 문서 자동화와 조직 차원의 팀 보고를 개선하는 데 사용하고 있다. - Carvana는 여러 저장소에 걸친 엔지니어링 작업에 에이전트를 적용하면서도 내장된 제어 기능을 활용하고 있다. - 개인 저장소부터 오픈소스 프로젝트와 대기업 규모의 복잡한 시스템까지 적용 범위를 확장할 수 있다. - 반복적인 관리 업무를 줄이고, 사람이 중요한 판단과 검토에 집중하도록 돕는 것이 주요 목표다. 실제로 도입할 때는 읽기 전용·보고서 생성처럼 위험이 낮은 작업부터 시작한 뒤, 사람이 검토하는 pull request 생성 단계로 확장하는 것이 적절하다. 빌드와 배포 파이프라인은 기존 CI/CD로 유지하고, Agentic Workflow는 분석·분류·문서화·개선 제안처럼 판단이 필요한 업무에 사용하는 편이 안전하다.

github

실무에서의 지속적인 AI: 에 (새 탭에서 열림)

소프트웨어 개발에는 테스트·빌드처럼 규칙으로 자동화할 수 있는 작업뿐 아니라, 코드의 의도와 맥락을 해석해야 하는 작업도 많다. GitHub가 제안하는 **Continuous AI**는 CI를 대체하지 않고, 자연어로 정의한 기대사항을 에이전트가 지속적으로 검토하도록 해 문서 불일치, 성능 회귀, 버그 추세 분석 같은 판단 중심 업무를 자동화한다. 다만 에이전트의 권한과 산출물을 명시적으로 제한해 개발자의 검토와 통제를 유지하는 것이 핵심이다. ## CI가 해결하지 못하는 판단 중심 업무 - CI는 테스트, 빌드, 포맷팅, 정적 분석처럼 결과를 이진적으로 판단할 수 있는 작업에 적합하다. - 테스트가 통과했는지 - 빌드가 성공했는지 - 정해진 린트 규칙을 위반했는지 - 반면 다음과 같은 문제는 단순한 규칙이나 휴리스틱만으로 판단하기 어렵다. - 문서의 설명과 실제 구현이 서로 다른 경우 - 접근성 린터는 통과하지만 사용자에게 여전히 혼란스러운 문구 - 메이저 버전 변경 없이 의존성의 플래그 동작이 바뀐 경우 - 반복문 안에서 정규식을 컴파일해 발생하는 미묘한 성능 저하 - 실제 제품과 상호작용해야만 드러나는 UI 동작 변화 - 이런 문제는 코드가 의도와 일치하는지, 사용자 경험이나 성능에 문제가 없는지를 해석해야 한다. - GitHub Next는 코드 생성 중심의 AI에서 나아가, 개발자의 인지 부담이 큰 반복 업무를 대신 처리하는 방향을 제시한다. ## Continuous AI의 개념 - Continuous AI는 CI를 대체하는 새로운 제품이 아니라 자동화 패턴이다. - 핵심 구조는 다음과 같다. - **자연어 규칙** - **에이전트의 추론** - **저장소 안에서의 지속적 실행** - 개발자는 코드에 대해 “무엇이 참이어야 하는가”를 자연어로 정의한다. - 에이전트는 저장소를 분석한 뒤 다음과 같은 검토 가능한 산출물을 만든다. - 수정 제안 - 풀 리퀘스트 - 이슈 - 댓글 또는 토론 - 프로젝트 활동·품질 관련 인사이트 - 예시로는 다음과 같은 워크플로가 있다. - 문서와 구현의 차이를 찾아 원인을 설명하고 수정안 제시 - 매주 프로젝트 활동, 버그 증가 추세, 코드 변경량이 급증한 영역 요약 - 핵심 경로의 성능 회귀 탐지 - 사용자 흐름에서 의미상 회귀가 발생했는지 확인 - 실제 워크플로는 한 문장으로 완성되지 않는다. 개발자와 에이전트가 의도, 제약 조건, 허용 가능한 결과를 반복적으로 조정하며 만든다. ## YAML과 자연어의 역할 분담 - 문제가 명확한 규칙으로 표현된다면 YAML, 스키마, 린터, 기존 CI가 여전히 가장 적합하다. - 그러나 “문서와 코드가 불일치하면 찾아서 수정하라”와 같은 요구는 정규식이나 스키마만으로 의미를 보존하기 어렵다. - 자연어는 코드의 의미와 개발자의 의도를 설명하는 데 유리하다. - 따라서 Continuous AI는 YAML 기반 CI를 대체하는 것이 아니라, CI가 다루기 어려운 의미·맥락 중심의 자동화를 보완한다. ## 권한과 안전한 산출물 - 에이전트는 기본적으로 저장소에 읽기 전용 권한만 가진다. - 명시적으로 허용하지 않는 한 다음 작업을 수행할 수 없다. - 이슈 생성 - 풀 리퀘스트 생성 - 파일이나 콘텐츠 수정 - **Safe Outputs**는 에이전트가 만들 수 있는 산출물과 조건을 명시하는 결정적 계약이다. - 워크플로를 정의할 때 개발자는 에이전트가 어떤 결과를 만들 수 있는지와 그 제약을 지정한다. - 예상 밖의 동작에 대비해 다음 안전장치를 둔다. - 출력 정제 - 명시적 권한 관리 - 전체 활동 기록 및 감사 가능성 - 제한된 권한으로 인한 예측 가능한 영향 범위 - 따라서 목표는 AI가 개발을 자율적으로 장악하는 것이 아니라, 개발자가 정한 경계 안에서 반복적인 판단 업무를 수행하게 하는 것이다. ## 개발자의 검토를 유지하는 방식 - 에이전트는 자율적으로 커밋을 확정하는 대신, 개발자가 검토할 수 있는 형태로 결과를 제출한다. - 가장 일반적인 출력은 풀 리퀘스트이며, 기존의 코드 리뷰 방식과 자연스럽게 연결된다. - 개발자는 AI가 생성한 결과를 검토하고, 자신의 판단과 취향을 최종적으로 유지한다. - 장기적으로는 개발자가 계속 직접 수행할 일과 AI에 위임할 일을 구분하는 것이 중요하다. 실무에서는 먼저 읽기 전용 분석과 보고서 생성부터 도입하고, 결과의 품질이 검증된 뒤 이슈 생성이나 풀 리퀘스트 작성 권한을 제한적으로 부여하는 방식이 안전하다. 결정적 규칙은 CI에 남기고, 의도·맥락·해석이 필요한 업무만 자연어 기반 에이전트 워크플로로 확장하는 것이 바람직하다.