GitHub는 에이전트를 프로덕션 배포로 이어지는 작업 사슬에 더 가깝게 두고 있다. 이는 코딩 보조에만 관한 이야기가 아니다. agent apps는 GitHub 안에서 기능 범위 설정, 보안 검토, 롤아웃, 출시를 지원하는 용도로 제시된다.

Copilot이 Slack과 Microsoft Teams에도 들어가면서 업무를 논의하는 곳과 실행하는 곳의 경계는 더 얇아진다. 컨텍스트 전환을 줄일 수 있지만, 책임성을 처음부터 설계해야 하는 이유이기도 하다.

코드 생성에서 소프트웨어 전달 흐름으로

GitHub의 agent apps 안내는 네 가지 앱으로 범위 설정부터 보안, 롤아웃, 출시까지 SDLC 전반의 기능 작업을 설명한다. 여기서 중요한 점은 에이전트를 단순 코드 생성기가 아니라 여러 단계를 잇는 구성 요소로 위치시킨다는 것이다.

그렇다고 에이전트가 전 과정을 소유해야 한다는 뜻은 아니다. 범위 설정에는 정확한 요구사항이, 보안에는 근거가, 롤아웃에는 관찰이, 릴리스에는 책임 있는 결정이 필요하다.

협업 도구가 새로운 컨텍스트 계층이 된다

Slack의 새 GitHub Copilot 경험과 Teams의 공동 에이전트 작업은 에이전트를 팀 커뮤니케이션 계층으로 가져온다. 질문, 결정, 작업 상태를 더 가까이 둘 가능성이 있다.

하지만 대화는 완전한 시스템 오브 레코드가 아니다. 채팅의 결정은 맥락이 부족하거나, 나중에 바뀌거나, 승인되지 않았을 수 있다. 영향이 큰 행동은 이슈, 풀 리퀘스트, 정책, 변경 기록 같은 구조화된 산출물로 연결돼야 한다.

모호한 자율성 대신 검문 지점을 설계하라

좋은 파일럿은 작업을 상태별로 나눈다. 에이전트는 이슈를 요약하고, 보안 체크리스트를 제안하거나, 롤아웃 계획을 준비할 수 있다. 상태 변경이나 영향 있는 도구 호출은 사람이 승인한다.

• 범위 설정: 요구사항과 누락 정보를 정리하고 제품 책임자가 확인한다.
• 보안: 검토 지점을 제안하되 독립적인 보안 검토를 거친다.
• 롤아웃: 계획과 관찰 지표를 작성하되 변경은 소유자가 승인한다.
• 릴리스: 상태를 종합하되 최종 결정은 책임자가 내린다.

SDLC를 복잡하게 만들지 않는 시작법

이슈 분류나 릴리스 노트 준비처럼 측정 가능한 병목 하나를 선택하라. 입력 데이터 범위를 제한하고 원본 산출물 링크를 요구하며, 응답 수가 아니라 사용자의 수정 비율을 평가하라.

반복 작업을 줄이면서도 누가 무엇을 결정했는지 흐리지 않을 때 다음 SDLC 단계로 확장할 가치가 있다.

5분 요약

• GitHub의 agent apps는 코드 생성뿐 아니라 SDLC 여러 단계를 겨냥한다.
• Slack과 Teams는 협업 맥락을 제공하지만 유일한 의사결정 기록이 되어서는 안 된다.
• 에이전트 행동은 산출물과 소유자 승인 지점에 연결해야 한다.
• 측정 가능하고 위험이 낮은 병목부터 시작하라.

참고 자료

• Cloudflare AI Search: give your agents a search engine for your data
• The next generation of MCP
• Building an open Agentic Internet: readable, discoverable, callable, and payable
• How to bring your software delivery workflow into GitHub with agent apps
• The new GitHub Copilot experience in Slack
• Shared agentic work with GitHub Copilot in Microsoft Teams
• Introducing Agent Plugins
• Introducing the new v0 API