에이전트 시대의 클라우드는 인간 중심으로 설계된 기존 클라우드를 단순히 확장하는 것이 아니라, 에이전트의 요구를 출발점으로 새롭게 설계해야 한다. 동시에 현재의 인간 중심 웹과 미래의 에이전트 중심 환경을 연결하는 번역 계층도 필요하다. Agents Week는 이러한 Agent Cloud의 구조와 실행 환경, 개발 생명주기, 보안, 웹의 변화를 다룬다.
### 인간 중심 클라우드의 한계
- 기존 클라우드와 웹은 사람이 직접 보고, 읽고, 클릭하고, 판단하는 상황을 전제로 설계됐다.
- 페이지는 사용자의 관심을 끌도록 구성되고, 대시보드는 사람이 탐색하고 조작하기 쉽게 만들어졌다.
- 에이전트는 사람처럼 피로하거나 산만해지지 않으며, 속도·구조화된 정보·시스템 접근성 등 다른 요구사항을 가진다.
- 따라서 인간용 도구를 에이전트에게 그대로 제공하는 방식에는 한계가 있다.
### Agent Cloud의 두 가지 역할
- 장기적으로는 에이전트를 위한 기본 구성 요소를 처음부터 설계하는 ‘에이전트 네이티브’ 클라우드가 되어야 한다.
- 단기적으로는 현재 존재하는 인간 중심 웹과 앞으로 등장할 에이전트 중심 웹 사이를 연결해야 한다.
- 즉, Agent Cloud는 새로운 실행·저장 환경인 동시에 기존 시스템과 에이전트 간의 변환 계층 역할을 수행해야 한다.
### Agents Week에서 다루는 주제
- 에이전트에 필요한 스토리지·컴퓨팅·실행 프리미티브
- 인간의 개입을 최소화한 에이전트 중심 소프트웨어 개발 생명주기(ADLC)
- 조직 내부의 시스템 오브 레코드에 에이전트와 직원이 안전하게 접근하는 방법
- 권한 관리와 안전한 제어를 통한 에이전트의 실제 업무 수행
- 정보 탐색, 서비스 접근, 결제 등을 포함한 에이전트 중심 웹의 변화
- 현재의 인간과 에이전트가 함께 일하는 현실적인 환경에서의 적용 방식
### 에이전트에게 직접 요구사항 묻기
- Agent Cloud가 무엇이어야 하는지 사람의 관점에서 추측하기보다, 에이전트에게 직접 질문해야 한다는 것이 글의 핵심 제안이다.
- 질문에는 다음과 같은 영역을 포함할 수 있다.
- 스토리지와 컴퓨팅
- 실행 및 데이터 저장 프리미티브
- 인간의 개입이 줄어든 개발 생명주기
- 조직 내 핵심 시스템에 대한 안전한 접근
- 웹에서의 정보 발견, 서비스 이용, 결제
- 독자들이 자신의 에이전트에게 질문하고, 그 답변과 통찰을 공유하도록 권한다.
에이전트용 인프라를 설계할 때는 기존 인간 중심 인터페이스를 자동화하는 데 그치지 말고, 에이전트가 빠르고 구조화된 방식으로 실행·접근·판단할 수 있는 기본 요소부터 정의해야 한다. 동시에 권한, 보안, 기존 시스템과의 호환성을 갖춘 연결 계층을 마련하는 것이 현실적인 출발점이다.
에이전틱 AI는 코드 제안만 하는 보조 도구와 달리, 도구 호출·설정 변경·머지 리퀘스트 생성·배포까지 수행할 수 있어 기존의 인간 중심 검토 방식만으로는 충분히 통제하기 어렵다. 따라서 조직은 모델 성능보다 에이전트의 신원, 권한 범위, 데이터 접근, 실행 기록을 관리하는 거버넌스 체계를 먼저 마련해야 한다. 핵심은 모든 작업을 막는 것이 아니라, 자율 실행과 인간 승인이 필요한 경계를 명확히 정하고 사후 감사가 가능하도록 만드는 것이다.
## 에이전틱 AI에 별도 거버넌스가 필요한 이유
- 기존 AI 코드 자동완성은 개발자가 제안을 보고 승인하거나 거부하므로, 모든 코드에 인간 검토가 개입한다.
- 에이전틱 AI는 테스트 실행, CI/CD 설정 변경, 파일 작성·삭제, 코드 푸시 등 여러 단계를 연속적으로 수행할 수 있다.
- MCP(Model Context Protocol)를 사용하면 에이전트가 외부 도구와 데이터에 연결되므로 접근 권한과 실행 범위가 더욱 중요해진다.
- 거버넌스의 핵심 질문은 다음과 같다.
- 에이전트가 무엇에 접근할 수 있는가?
- 어떤 작업을 수행하도록 승인되었는가?
- 실제로 어떤 작업을 했으며, 이를 사후에 증명할 수 있는가?
- 조사 결과에서도 AI 코드의 장기 유지보수와 기술 부채 증가가 주요 우려로 나타났다.
- 개발자·기술 리더의 73%가 AI 생성 코드의 장기 유지보수를 우려했다.
- 86%는 명확한 거버넌스가 없으면 기술 부채가 기존 개발 방식보다 빠르게 누적될 수 있다고 답했다.
- DevSecOps 전문가의 92%는 AI 생성 코드와 관련된 거버넌스 문제를 경험했다.
## MCP와 에이전트 권한 통제
에이전트가 외부 도구를 호출할 수 있게 되면 권한 관리가 가장 중요한 통제 지점이 된다.
- 에이전트와 작업 흐름의 중앙 카탈로그를 운영한다.
- 팀마다 임의로 통합 기능을 만들게 하지 않고, 관리자가 승인된 에이전트와 플로우만 조직에 배포한다.
- 기존 역할·그룹 구조와 연계해 프로젝트별 사용 범위를 관리한다.
- 복합 신원(composite identity)을 사용한다.
- 에이전트의 활동을 에이전트 자체의 작업으로만 기록하지 않고, 작업을 요청한 인간 사용자와 연결한다.
- 리소스 접근 시 에이전트와 요청 사용자 모두 인증·인가되어야 한다.
- 도구별 승인 정책을 설정한다.
- 안전한 도구는 자율 실행을 허용한다.
- 파일 작성, 리소스 삭제처럼 민감한 작업은 인간 승인 후 실행되도록 한다.
- 위험한 도구는 아예 차단할 수 있어야 한다.
- 프롬프트 가드레일을 마련한다.
- 웹페이지, 이슈 댓글, 외부 파일 등 신뢰할 수 없는 입력이 에이전트의 행동을 조작하는 프롬프트 인젝션을 탐지한다.
- 단순히 실행 결과를 기록하는 것을 넘어, 공격 시도를 실행 전에 차단해야 한다.
이러한 통제는 인간 사용자에게 적용하는 역할 기반·감사 가능·일관된 권한 모델과 동일한 수준으로 에이전트에도 적용되어야 한다.
## 데이터 privacy와 자체 호스팅
소스 코드를 외부 AI 서비스에 제공할 때는 데이터 처리와 소유권을 명확히 확인해야 한다.
- 공급자가 고객 코드를 모델 학습에 사용하는지 확인한다.
- 입력 데이터와 AI가 생성한 출력의 소유권을 확인한다.
- 하위 처리자(subprocessor)의 위치와 목록 변경 통지 정책을 검토한다.
- 규제 산업에서는 데이터가 조직 외부 인프라로 나가지 않아야 할 수 있으므로 자체 호스팅이 중요한 통제 수단이 된다.
- 자체 호스팅을 사용하면 다음을 함께 달성할 수 있다.
- 조직이 통제하는 인프라에서 에이전트 실행
- 팀별 사용량과 활동 추적
- 규제기관의 데이터 보관·처리 요구 충족
- BYOM(Bring Your Own Model)을 활용하면 내부 검증을 마친 모델을 연결하고, 특정 에이전트 플로우에만 지정할 수 있다.
- 민감한 작업은 신뢰할 수 있는 자체 모델에 고정한다.
- 상대적으로 덜 민감한 작업은 관리형 모델을 사용할 수 있다.
## 인간 검토가 필요한 지점 정의
거버넌스는 에이전트의 자율 실행을 전면 금지하는 것이 아니라, 자율성이 끝나고 인간 검토가 시작되는 지점을 결정하는 것이다.
- 대화형 작업
- 개발자가 실시간으로 제안을 확인하고 승인·거부한다.
- 일반적인 AI 코드 자동완성에 가까운 방식이다.
- 자동화·헤드리스 작업
- CI/CD 파이프라인에서 개발자의 실시간 관찰 없이 에이전트가 실행된다.
- 실행 전에 도구 승인 절차를 거치거나, 실행 직후 감사 로그를 통해 사람이 검토해야 한다.
### 검토 지점별 통제 방식
- 코드 리뷰
- 에이전트가 생성한 머지 리퀘스트라도 일반 코드와 동일하게 승인 정책을 적용한다.
- 지정된 담당자의 승인이 없으면 병합되지 않도록 한다.
- 테스트와 검증
- 필수 테스트, 보안 스캔, 품질 검사를 통과해야 다음 단계로 진행하도록 파이프라인에서 강제한다.
- 배포
- 운영 배포처럼 영향이 큰 작업은 명시적인 인간 승인을 요구한다.
- 도구 실행
- 도구별로 자율 실행, 승인 대기, 실행 차단 중 하나를 지정한다.
- 조직 정책
- 팀별 관행에 맡기지 말고 조직 전체의 AI 사용·승인·감사 정책으로 표준화해야 한다.
- 이렇게 해야 사용 방식이 일관되고, 감사 담당자가 AI 활용 과정을 검증할 수 있다.
## 실용적인 적용 방향
조직은 에이전트 도입 전에 승인된 에이전트 목록과 모델 목록을 만들고, 사용자·에이전트의 복합 신원, 프로젝트별 권한, 도구별 승인 정책, 데이터 처리 위치를 정의해야 한다. 이후 머지 승인, 보안 스캔, 배포 승인 같은 기존 개발 통제 지점을 에이전트 작업에도 동일하게 적용하고, 모든 실행을 추적 가능한 감사 로그로 남기는 것이 바람직하다.
Figma는 SIEM 경보 대응에 AI 에이전트를 도입해 과거 조사 기록 검색, 포렌식 분석, 보안 데이터 질의, 코드 수정과 PR 생성까지 자동화했다. 그 결과 경보의 해결까지 걸리는 시간을 71% 줄였으며, 온콜 엔지니어의 업무를 단순한 정보 수집에서 판단과 검토 중심으로 바꾸었다. 핵심은 기존 업무 흐름을 유지하면서 경보와 조사 지식을 지속적으로 축적·검색하는 시스템을 구축한 것이다.
## 보안 경보 대응의 병목
- Figma의 SIEM인 Panther는 클라우드 인프라, 엔드포인트, SaaS, ID 시스템을 점검한다.
- 문제가 감지되면 Slack에 경보를 게시하고 Asana 티켓을 생성한다.
- 기존 온콜 엔지니어는 다음 정보를 수동으로 모아야 했다.
- 같은 경보가 과거에 발생했는지
- 이전 조사에서 어떤 결론을 내렸는지
- 관련된 Slack 대화가 있는지
- 문제를 해결할 예정인 PR이 존재하는지
- 클라우드 환경과 개발 도구가 빠르게 변하면서 경보의 유형과 대응 방법도 계속 바뀌었다.
- 따라서 단순히 경보를 분류하거나 중복 제거하는 것만으로는 업무 부담을 충분히 줄일 수 없었다.
## 검색 시스템에서 에이전트 시스템으로의 확장
- 초기 목표는 새 경보가 발생했을 때 과거 온콜 엔지니어의 판단과 대응 기록을 찾아주는 retrieval layer를 만드는 것이었다.
- 이후 시스템은 다음 기능을 수행하는 에이전트 구조로 확장됐다.
- 경보 조사
- 보안 데이터 레이크와 감사 로그 질의
- 관련 코드 변경 작성
- PR 생성
- 과거 조사 결과를 기억하고 다음 대응에 활용
- Figma는 코드베이스에서도 에이전트를 활용해 Okta와 AWS 같은 민감한 도구의 설정 변경을 점검하고 있었다.
- 그러나 SIEM이 발견하는 광범위한 운영·인프라 문제까지 다루기 위해서는 코드 분석을 넘어선 별도의 시스템이 필요했다.
## RAG 계층: 경보에 기억을 부여하기
- Figma는 AWS Bedrock Knowledge Bases와 Amazon Kendra를 이용해 검색 증강 생성(RAG) 기반의 경보 분류 시스템을 구축했다.
- Panther 경보가 발생하면 Lambda 핸들러가 원본 payload를 표준화된 문서로 변환해 Kendra에 색인한다.
- 다음과 같은 구조화된 정보를 추출해 검색 속성으로 저장한다.
- `p_any_ip_addresses`에서 추출한 IP 주소
- `p_any_usernames` 및 공급자별 사용자 필드의 행위자 정보
- ARN에서 추출한 AWS 계정 ID
- 경보 제목, 심각도, 태그, 생성 시각
- 경보 유형, 상태, 조사 맥락의 존재 여부
- 예시 속성에는 `alert_id`, `alert_type`, `severity`, `status`, `created_at`, `has_investigation_context`가 포함된다.
## 의미 검색과 최신성 반영
- 새로운 유사 경보가 발생하면 경보 제목을 주요 검색 벡터로 사용해 Bedrock에 의미 검색을 요청한다.
- 검색 질의에는 조사 맥락이 있는 기록만 우선하도록 다음 조건을 추가한다.
```text
{경보 제목}
has_investigation_context=1
```
- 경보 제목은 일반적으로 탐지 규칙 이름과 행위자 사용자 이름으로 구성된다.
- 단순히 가장 유사한 기록을 찾는 것보다 최근 기록을 우선하도록 검색 결과를 편향시켰다.
- 대응 절차와 환경이 계속 변하기 때문에, 6개월 전의 정확히 같은 경보보다 이틀 전에 발생한 유사 경보가 실무적으로 더 유용할 수 있다.
- 이를 통해 검색 결과가 현재의 운영 방식과 최신 조사 관행을 더 잘 반영하게 된다.
## Slack 조사 기록의 자동 축적
- `investigation_context`는 온콜 엔지니어가 Slack 경보 스레드에 남긴 조사 결과와 판단을 의미한다.
- 조사 내용이 없는 종료 경보는 단순히 “닫혔다”는 사실만 제공하므로 재사용 가치가 낮다.
- Figma는 엔지니어가 기존처럼 Slack이나 Asana에 댓글을 남기기만 해도 해당 내용을 자동으로 원래 경보 문서에 추가한다.
- 기존 문서의 조사 맥락 배열에 새 댓글을 추가하고, `has_investigation_context` 값을 1로 변경한 뒤 문서를 재색인한다.
- 결과적으로 유용한 댓글 하나가 이후 발생하는 모든 유사 경보의 조사 비용을 낮춘다.
- 별도의 annotation 도구나 새로운 수동 입력 절차를 요구하지 않고 기존 업무 흐름에서 지식이 축적된다는 점이 중요하다.
## 실용적인 적용 방향
- 처음부터 완전한 자율 에이전트를 만들기보다, 과거 대응 기록을 검색하는 좁은 문제부터 시작하는 것이 현실적이다.
- 경보 데이터는 검색 가능한 구조화 필드와 사람이 작성한 조사 맥락을 함께 저장해야 한다.
- 최신 대응 기록과 조사 내용이 있는 기록을 우선하는 검색 전략이 필요하다.
- 별도의 문서화 작업을 추가하기보다 Slack·티켓 시스템의 기존 댓글을 자동으로 지식화하는 방식이 도입 장벽을 낮춘다.
- AI가 분석과 코드 변경을 수행하더라도 PR 검토와 최종 판단은 보안 엔지니어가 맡는 구조가 효과적이다.
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 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을 병합해야 한다.
Anthropic의 Claude Opus 5가 GitLab Duo Agent Platform에 출시되어 복잡하고 중요한 개발 작업에 더 깊은 추론 능력을 제공한다. GitLab 내부 평가에서 작업 해결률 93.3%를 기록해 Opus 4.8의 73.0%보다 크게 향상됐으며, 속도도 유지했다. 일상적인 작업에는 Sonnet 계열을, 대규모 리팩터링·장기 디버깅처럼 실패 비용이 큰 작업에는 Opus 5를 선택하는 전략이 권장된다.
## 복잡한 작업에서 강화된 추론과 정확성
- 여러 파일을 수정하는 기능 개발, 대규모 리팩터링, 장기간의 커밋 이력을 추적하는 디버깅에 적합하다.
- 내부 평가에서:
- Opus 5 작업 해결률: **93.3%**
- Opus 4.8 작업 해결률: **73.0%**
- 두 모델 모두 시도한 작업의 완료율은 **100%**
- 단순히 작업을 끝내는 것을 넘어, 결과가 검증된 올바른 해결책인지에서 큰 차이를 보였다.
- 부분적인 패치나 반복적인 재프롬프트가 줄어들어, 결과물을 바로 머지할 가능성이 높아진다.
- 예시로 5개 파일을 수정하고 새로운 공개 타입과 설정 필드를 추가해야 하는 CLI SSO 인증 기능을 완전히 구현하고 커밋한 뒤 머지 리퀘스트까지 생성했다.
## 코드 리뷰와 멀티 에이전트 협업
- 실제 버그를 잘 포착하면서도 오탐이 적어, 개발자가 불필요한 경고를 검토하는 시간을 줄인다.
- 여러 에이전트를 동시에 실행할 때 각 에이전트가 서로의 작업을 덮어쓰거나 충돌시키는 문제를 줄인다.
- Writer-verifier 패턴을 활용할 수 있다.
- 한 에이전트가 코드를 작성한다.
- 다른 에이전트가 결과를 검증한다.
- 검증을 통과한 결과만 최종 작업에 반영한다.
- 장시간 자율 실행하거나 여러 에이전트를 병렬로 운영하는 환경에서 특히 효과가 크다.
- GitLab Credits 사용량 상한을 설정해 병렬 에이전트 작업의 비용이 예산을 초과하지 않도록 제한할 수 있다.
## 깊은 추론을 유지하면서도 빠른 실행
- GitLab의 고난도 벤치마크에서 95번째 백분위 실행 시간은 다음과 같다.
- Opus 5: **768초**
- Opus 4.8: **784.98초**
- Sonnet 4.6: **982.57초**
- Opus 5는 Opus 4.8보다 **2.2% 빠르고**, Sonnet 4.6보다 **21.9% 빠르다**.
- 복잡한 장기 작업에서도 실행 시간이 지나치게 늘어지는 상황을 줄여 보다 예측 가능한 결과를 제공한다.
## 작업별 모델 선택
- 모든 개발 작업에 가장 강력한 모델을 적용하기보다 작업의 복잡도에 따라 모델을 선택해야 한다.
- **Sonnet 계열**
- 일상적인 개발 작업
- 빠른 코드 생성과 수정
- 비용 효율성이 중요한 반복 작업
- **Opus 5**
- 대규모 리팩터링
- 어려운 버그 추적
- 여러 파일과 시스템에 걸친 기능 구현
- 잘못된 판단을 다시 되돌리는 비용이 큰 작업
- 모델은 GitLab 인스턴스에서 직접 선택할 수 있다.
- 모델이 달라도 GitLab Duo Agent Platform의 컨텍스트 계층, 정책 검사, 감사 추적 인프라는 동일하게 적용된다.
## GitLab Duo Agent Platform에서의 이용
- Claude Opus 5는 GitLab Duo Agent Platform에서 사용할 수 있으며 GitLab Credits로 과금된다.
- 신규 사용자는 무료 체험을 시작할 수 있다.
- GitLab Premium 또는 Ultimate 구독자는 포함된 GitLab Credits를 활용해 Duo Agent Platform을 활성화할 수 있다.
복잡하고 실패 비용이 큰 작업에는 Opus 5를 우선 적용하고, 반복적인 일상 개발에는 Sonnet 계열을 사용하는 혼합 전략이 가장 실용적이다. 다만 제시된 성능 수치는 GitLab의 내부 평가 결과이므로, 실제 도입 전에는 팀의 코드베이스와 작업 유형을 기준으로 별도 검증하는 것이 좋다.
Figma는 하나의 보안 정책을 기반으로 AI 에이전트를 코드 작성, 풀 리퀘스트(PR) 리뷰, 과거 코드 감사에 활용한다. 핵심은 단순히 취약점을 많이 찾는 것이 아니라, 정밀도(실제 취약점 비율)와 재현율(실제 취약점 탐지 비율)을 함께 관리해 개발자의 신뢰를 확보하는 것이다. 특히 모든 PR에 적용되는 리뷰 시스템과 사람의 피드백·기존 취약점 재검증을 통해 정책을 지속적으로 개선한다.
## 에이전트 보안의 세 가지 적용 단계
- **코드 생성 단계**: 개발자가 코드를 작성하는 과정에서 취약점을 예방한다.
- **PR 리뷰 단계**: 변경된 코드를 검토해 배포 전에 문제를 탐지하고 수정하도록 한다.
- **과거 코드 감사 단계**: 오래된 모노레포 전체를 점검해 이미 배포된 취약점을 찾는다.
- 세 단계 모두 다음 내용을 포함한 공통 정책을 사용한다.
- 신뢰 경계
- 조직이 허용한 위험
- 과거 판단의 선례(precedent)
## 정밀도와 재현율을 함께 측정
- **정밀도(precision)**:
- 에이전트가 보고한 결과 중 실제 취약점의 비율이다.
- 높을수록 오탐(false positive)이 적다.
- **재현율(recall)**:
- 실제 존재하는 취약점 중 에이전트가 찾아낸 비율이다.
- 높을수록 미탐(false negative)이 적다.
- 취약점을 많이 보고하는 것만으로는 충분하지 않다.
- 오탐이 많으면 개발자가 도구의 결과를 무시하게 된다.
- 반대로 정밀도만 높이고 탐지 범위를 줄이면 중요한 취약점을 놓칠 수 있다.
## PR 리뷰를 먼저 구축한 이유
Figma는 코드 생성이나 전체 저장소 감사보다 개선 주기가 빠른 PR 리뷰부터 만들었다.
- **보편성**: 모든 PR이 리뷰 대상이 된다.
- **셀프서비스 구조**: 에이전트가 PR에 직접 댓글을 달고, 작성자가 해당 결과에 답변한다.
- **양방향 측정**:
- 정밀도는 작성자의 thumbs up/down 평가와 설명으로 측정한다.
- 재현율은 이미 취약점이 있었던 커밋에 리뷰어를 다시 실행해 놓친 문제를 세는 방식으로 측정한다.
- 이렇게 수집한 피드백은 에이전트가 따르는 보안 정책 개선에 반영된다.
## 여러 모델을 병렬로 사용
- Figma는 서로 다른 취약점을 놓치는 모델을 함께 사용한다.
- Claude Code의 Opus 4.8, xhigh 노력 수준
- Codex의 GPT-5.6 Sol, high 노력 수준
- 어느 한 모델이라도 문제를 보고하면 결과를 상위 단계로 전달한다.
- PR 하나의 리뷰 비용은 중앙값 약 0.50달러이며, 대부분의 PR에는 보고할 문제가 없어 비용이 크게 증가하지 않는다.
- Figma는 이 비용이 버그 바운티 지급이나 사용자 피해를 예방하는 효과에 비해 충분히 낮다고 판단한다.
## 실제로 탐지한 취약점 사례
- 복잡한 취약점:
- 주입된 샌드박스 객체가 호스트 영역의 `Function` 생성자에 접근할 수 있음을 추론했다.
- 이를 통해 데스크톱 클라이언트에서 코드 실행으로 이어지는 경로를 찾아냈다.
- 일반적인 접근 제어 취약점:
- 송장 조회 API가 호출자가 전달한 송장 ID만 확인하고 소속 조직을 검증하지 않았다.
- 인증된 사용자가 ID만 알면 다른 조직의 송장을 읽을 수 있는 IDOR(Insecure Direct Object Reference) 문제였다.
- 해결책은 송장 조회 시 인증된 사용자의 조직에 속하는지 함께 확인하는 것이다.
## 초기 도입과 신뢰 확보
- Anthropic이 Claude Code Security Reviewer를 공개한 2025년 8월, Figma는 즉시 도입했다.
- 처음에는 개발자 PR 댓글이 아닌 Slack과 Datadog로만 결과를 보내는 shadow mode로 운영했다.
- 리뷰어는 두 단계로 동작했다.
- 잠재적 취약점 탐색
- 적대적 검토를 통한 오탐 필터링
- 실제 보안 사고를 재현했을 때 근본 원인을 거의 그대로 찾아냈고, 애플리케이션 보안과 인프라 설정 오류 등 여러 영역에도 잘 일반화됐다.
- 그러나 첫 주에는 27개 결과 중 4개만 유효해 정밀도가 약 15%에 불과했다.
- Figma는 개발자에게 노출하기 위한 기준으로 70% 정밀도를 설정했다.
- 10개 중 7개가 유효해야 개발자가 결과를 읽을 것이라는 실용적 기준이다.
- 2주간의 관찰 기간 동안 정밀도가 70% 이상이고 심각한 오탐이 없을 때까지 PR 댓글을 보류했다.
- 이를 위해 최근 8주간의 PR에 리뷰어를 다시 실행하고, 보안팀이 오탐을 직접 분류했다.
- 과거 사례를 기반으로 에이전트가 따라야 할 정책을 작성했다.
- 여기서 **선례(precedent)**는 특정 상황에서 어떤 보고가 유효하거나 유효하지 않은지 설명하는 구체적인 사례다.
## 실용적인 결론
AI 보안 에이전트를 도입할 때는 처음부터 모든 개발자에게 결과를 노출하기보다 shadow mode로 운영하며 정밀도를 먼저 확보하는 것이 좋다. 모든 PR에 적용하고, 사람의 결과 평가와 알려진 취약점 재검증을 분리해 수집하면 신뢰성과 탐지력을 함께 개선할 수 있다.
캔버스 확장은 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`로 원하는 화면과 동작을 구체적으로 요청해 보는 것이 효과적이다.
AWS의 이번 주 주요 소식은 코딩 에이전트의 Lambda 설정 자동화와 Amazon Bedrock의 OpenAI GPT-5.6 모델 출시다. 이와 함께 S3 스토리지 비용 절감, Lambda 코드 저장 방식 개선, Cognito 사용자 가져오기 기능 등이 추가됐다. AWS는 AI 에이전트 개발과 서버리스 운영을 단순화하는 한편, 비용 효율성과 대규모 데이터 처리 기능도 강화하고 있다.
## AWSKRUG와 개발자 커뮤니티 협력
- AWS 팀이 서울을 방문해 AWS Korea User Group(AWSKRUG) 리더들과 교류했다.
- AWSKRUG는 주제·지역별 20개 밋업 그룹으로 구성된 한국 최대 규모의 클라우드 개발자 커뮤니티다.
- 매년 100회 이상의 행사를 개최하며, AWS Developer Experience 팀에 대한 피드백과 개선 요구를 공유했다.
## 코딩 에이전트의 원클릭 Lambda 설정
- Lambda 콘솔에서 제공하는 프롬프트를 AI 코딩 에이전트에 전달하면 AWS 서버리스 개발 환경을 자동으로 구성할 수 있다.
- AWS Serverless 스킬과 Serverless MCP 서버가 포함되어 서버리스 모범 사례를 에이전트에 기본 적용한다.
- Claude Code, Kiro, Cursor, GitHub Copilot, Codex, Devin Desktop, OpenCode 등을 지원한다.
- 다음 URL을 에이전트에 입력해 설정 가이드를 불러올 수 있다.
```text
fetch https://docs.aws.amazon.com/lambda/latest/dg/samples/aws-lambda-agent-setup.md
```
- AWS Agent Toolkit을 사용하면 에이전트에 최신 AWS 지식과 안전한 리소스 접근 권한을 제공할 수 있다.
```text
fetch https://raw.githubusercontent.com/aws/agent-toolkit-for-aws/refs/heads/main/setup-instructions/setup.md
```
## Amazon Bedrock의 OpenAI GPT-5.6 모델
- Amazon Bedrock에서 OpenAI의 GPT-5.6 계열 모델인 Sol, Terra, Luna를 사용할 수 있다.
- 모델별 용도는 다음과 같다.
- **Sol**: 최고 수준의 추론 성능을 제공하는 플래그십 모델
- **Terra**: 성능과 비용의 균형을 중시하는 모델
- **Luna**: 빠르고 비용 효율적인 추론에 적합한 모델
- Bedrock의 고성능·보안·신뢰성 중심 추론 엔진과 Responses API를 통해 접근할 수 있다.
## S3 저장 클래스의 당일 전환
- 이제 객체 생성 당일부터 S3 Standard-IA 또는 S3 One Zone-IA로 전환할 수 있다.
- 기존에는 S3 Standard에 최소 30일 보관해야 했다.
- 두 저장 클래스는 S3 Standard보다 최대 40% 저렴하면서도 필요할 때 밀리초 단위로 접근할 수 있다.
- 생성 직후 빠르게 사용 빈도가 낮아지는 백업, 로그 분석, 규정 준수 데이터를 저장하는 데 적합하다.
## Lambda 코드의 자체 S3 저장
- 사용자가 직접 관리하는 Amazon S3 버킷에 Lambda 소스 코드를 저장하고 이를 직접 참조할 수 있다.
- Lambda가 중간 복사본을 생성하는 과정이 사라진다.
- 이에 따라 Lambda 코드 저장 용량 제한을 없애고, 함수 생성·업데이트 후 활성화 시간을 줄일 수 있다.
## Cognito 비밀번호 해시 가져오기
- Amazon Cognito CSV 사용자 가져오기 과정에서 기존 시스템의 비밀번호 해시를 함께 등록할 수 있다.
- 사용자는 최초 로그인 시 비밀번호를 재설정하지 않고 기존 자격 증명으로 바로 로그인할 수 있다.
- CSV를 생성할 때 원본 시스템에서 사용한 비밀번호 해시 알고리즘을 지정해야 한다.
## SQS 20주년과 AI 에이전트용 개방형 프로토콜
- Amazon SQS가 공개 출시 20주년을 맞았다.
- 생산자와 소비자를 분리해 시스템 간 결합도를 낮추는 메시징 패턴이 여전히 핵심 가치다.
- Strands Agents SDK를 활용해 MCP, A2A, UTCP, AG-UI, x402 등 AI 에이전트용 개방형 프로토콜이 어떻게 연동되는지 소개했다.
- 특정 프레임워크에 종속되지 않고 여러 에이전트 시스템에 적용할 수 있는 통합 패턴을 다룬다.
## DynamoDB 대량 작업 자동화
- 오픈소스 Bulk Executor for DynamoDB가 테이블 전체 항목을 대상으로 하는 대량 작업을 단순화한다.
- 별도 코드를 작성하지 않고 다음 작업을 수행할 수 있다.
- `count`: 전체 항목 수 계산
- `find`: 조건에 맞는 항목 검색
- `delete`: 항목 대량 삭제
- `update`: 항목 대량 수정
- 대규모 테이블에서도 일괄 작업을 쉽게 실행할 수 있다.
## Kiro CLI를 활용한 AWS Support 자동화
- Kiro CLI의 MCP 통합으로 장애 조사, AWS 문서 검색, 지원 사례 생성 과정을 하나의 대화형 인터페이스로 처리할 수 있다.
- 주요 활용 사례는 다음과 같다.
- AWS Glue 작업 실패 분석
- AWS Lambda 콜드 스타트 원인 조사
- AWS WAF 오탐 분석
- 지원 담당자가 여러 도구를 오가며 수행하던 작업을 대화형 워크플로로 통합한다.
## Cost Explorer 요금 표시 오류
- 일부 고객의 Cost Explorer에서 예상 청구액과 비용·사용량 데이터가 부정확하게 표시되는 문제가 발생했다.
- 잘못된 예산 경고와 비용 이상 탐지 알림이 발생하거나 예상 비용이 부풀려질 수 있었다.
- 문제는 해결됐으며 AWS는 재발 방지와 청구 관련 장애 대응 개선을 위한 사후 검토를 진행 중이다.
- 자세한 내용은 AWS Health Dashboard에서 확인할 수 있다.
서버리스 개발자는 Lambda 에이전트 설정 프롬프트와 자체 S3 코드 저장 기능을 우선 검토할 만하다. 데이터 저장 비용이 중요한 환경에서는 S3의 당일 IA 전환을 활용하고, 대규모 DynamoDB 일괄 작업이나 AWS 지원 업무에는 Bulk Executor와 Kiro CLI를 적용하면 운영 효율을 높일 수 있다.
GitLab Orbit 해커톤은 코드·머지 리퀘스트·파이프라인·배포·소유권을 연결한 실시간 코드 그래프가 AI 에이전트의 시스템 이해 문제를 해결할 수 있음을 보여줬다. 1,576명이 참가해 265개 프로젝트를 만들었고, 참가자들은 변경 영향 분석, 테스트 최적화, 마이그레이션 비용 산정, 보안 취약점 추적 같은 반복적인 실무 문제에 집중했다. 특히 에이전트의 실행 속도뿐 아니라 근거와 책임성을 확보하는 것이 중요하다는 점이 강조됐다.
## GitLab Orbit와 해커톤 규모
- GitLab Orbit는 다음 정보를 관계형 그래프로 연결하고 최신 상태로 유지한다.
- 소스 코드와 의존성
- 머지 리퀘스트
- CI 파이프라인
- 배포 정보
- 팀과 코드 소유권
- AI 에이전트는 코드 작성에는 강하지만, 변경 사항이 시스템 전체에 미치는 영향 파악에는 취약하다.
- Orbit를 사용하면 “무엇이 이 변경에 의존하는가”, “어떤 테스트가 영향을 받는가”, “문제 발생 시 담당 팀은 누구인가” 같은 질문을 단일 쿼리로 처리할 수 있다.
- 해커톤에는 1,576명이 등록했고, 265개의 Showcase Track 프로젝트가 제출됐다.
- 별도로 26명의 기여자가 Orbit 코드베이스에 61개의 개선 사항을 병합했다.
## 개발자들이 가장 많이 해결하려 한 문제
- 70개 팀이 변경 사항의 잠재적 영향 범위를 분석하는 도구를 만들었다.
- 하위 호출자
- 영향받는 파이프라인
- 관련 팀과 소유자
- 30개 이상의 팀은 코드베이스 온보딩과 이해를 돕는 도구를 개발했다.
- 그 밖에도 다음 문제가 주요 주제로 등장했다.
- 장애의 근본 원인 분석
- 아키텍처 드리프트 탐지
- 불안정한 파이프라인 진단
- 여러 저장소에 걸친 CVE 추적
- 공통점은 기존에는 Git, CI, 배포 도구, 대시보드에 흩어진 정보를 사람이 직접 조합해야 했다는 점이다.
- Orbit는 단순히 에이전트를 자동화하는 것이 아니라, 실행에 필요한 시스템 맥락과 통제 수단을 함께 제공한다.
## 시스템 통합과 자동화
### Sankofa: 상황별 세 가지 에이전트
- 기술 구현 부문 우승작이다.
- 사용자의 업무 상황에 따라 세 에이전트가 작동한다.
- **Radar**: 머지 리퀘스트가 열리면 변경의 영향 범위와 관련 파이프라인, 담당 팀을 분석한다.
- **Guide**: 이슈가 할당되면 작업 시작에 필요한 요약 보고서를 작성한다.
- **Shield**: 보안 취약점이 발생하면 코드 그래프를 한 번 탐색해 취약점의 전파 경로를 추적한다.
- 취약점의 영향을 여러 저장소와 의존성에 걸쳐 수동으로 추적하던 작업을 자동화했다.
### Stayed Shipped: AI 코드의 실제 운영 여부 추적
- AI 에이전트가 지난달 병합한 변경 중 실제 운영 환경에 남아 있는 비율을 확인한다.
- 이후 시니어 개발자가 조용히 수정하거나 대체한 변경도 추적한다.
- 기존 대시보드가 제공하지 못하는 “AI가 만든 코드가 실제로 살아남았는가”라는 지표를 제시한다.
## 마이그레이션 비용과 작업 계획
### Carver: 레거시 마이그레이션 견적
- 디자인·사용성 부문 우승작이다.
- 사용자가 원하는 마이그레이션을 입력하면 Orbit의 의존성 그래프를 분석해 다음을 산출한다.
- 작업 단위 수
- 예상 기간
- 수행 순서
- 위험 요소
- 예시로 AngularJS에서 Angular로의 전환을 약 9주간의 인력 작업과 약 10달러의 생성 비용으로 추정한다.
- 테스트되지 않은 핵심 서비스처럼 위험도가 높은 부분은 별도로 표시한다.
- Orbit에서 실제 서비스를 찾지 못하면 임의의 수치를 만들지 않고 사용자에게 실제 코드 위치를 확인한다.
### Marshal: 조직 전체의 자율 마이그레이션
- 조직 단위 목표를 선언하면 영향받는 저장소를 찾고 작업 순서를 계획한다.
- 작업을 여러 웨이브로 나누어 머지 리퀘스트를 생성하고, 대상 저장소가 누락되지 않았는지 확인한다.
- Carver가 통제 가능한 견적과 설명에 집중한다면, Marshal은 최대한의 자율 실행을 지향한다.
## 영향 기반 테스트와 정밀한 리팩터링
### CrossCut: 변경에 필요한 테스트만 실행
- 영향력 부문 우승작이다.
- 머지 리퀘스트에서 변경된 심볼을 찾고, Orbit의 호출 그래프를 따라 실제로 영향을 받는 테스트를 계산한다.
- 모델의 추측 없이 그래프 탐색만으로 테스트 파이프라인을 구성한다.
- 대규모 또는 여러 저장소에 걸친 테스트 스위트에서 CI 실행량을 90% 이상 줄일 수 있다.
### OrbitWeaver: 의존성 순서를 반영한 리팩터링
- 벡터 유사도 검색이 아니라 정확한 영향 범위를 사용한다.
- 영향을 받는 모든 파일을 매핑하고 의존성 순서에 따라 수정한다.
- 단순한 의미적 유사성보다 실제 코드 그래프가 안전한 자동 리팩터링에 적합하다는 점을 보여준다.
## 시맨틱 웹과 에이전트 거버넌스
### Transcend: Orbit 위에 새로운 추론 계층 구축
- 아이디어 품질 부문 우승작이다.
- Orbit API를 단순히 호출하는 대신 OWL, SPARQL, RDF를 활용한 시맨틱 웹 기반 추론 엔진을 추가했다.
- 기본 API만으로는 어려운 다음 작업을 수행한다.
- 전이적 폐쇄 계산
- 코드베이스와 외부 지식 그래프의 조인
- 코드와 관련 논문, 저자, 발표 연도의 연결
- 예를 들어 코드베이스가 구현한 지식 그래프 임베딩 기법의 클래스명과 이를 뒷받침한 논문 정보를 함께 조회한다.
### Universal Agent OS: 에이전트의 책임성과 검증
- 에이전트 자체보다 에이전트를 통제하는 거버넌스 계층을 만든다.
- 다음 절차를 강제한다.
- 먼저 사용자 인터뷰 수행
- 코딩 전 계획 수립
- 의사결정 근거 보존
- 결과 검증
- AI가 작성하는 코드의 비중이 커질수록 빠른 실행보다 누가 어떤 근거로 결과를 승인했는지가 중요해진다는 문제의식을 담고 있다.
## Orbit 자체에 대한 커뮤니티 기여
- Contribute Track에서는 26명이 Orbit에 직접 61개의 머지 리퀘스트를 병합했다.
- 주요 개선 내용은 다음과 같다.
- C++20 concepts 지원
- Go 패키지 선언 지원
- Kotlin 코루틴 지원
- Ruby 람다 지원
- 온톨로지 수정
- CI에서 발생하던 SIGPIPE 버그 수정
- 첫 Orbit 쿼리 튜토리얼 작성
- `max_depth`와 `max_hops` 차이를 포함한 문서 정리
- 참가자들은 Orbit를 활용한 애플리케이션뿐 아니라 기반 플랫폼 자체도 개선했다.
실무에서는 AI 에이전트에 코드를 바로 작성하게 하기보다, 먼저 변경 영향 분석·관련 테스트 선택·소유 팀 확인·근거 기록을 Orbit로 연결하는 것이 효과적이다. 특히 대규모 저장소에서는 정확한 의존성 그래프가 CI 비용 절감과 안전한 리팩터링의 기반이 될 수 있다.
GitLab Duo Agent Platform의 새로운 **“Work item created” 트리거**는 작업 항목이 생성되는 즉시 플로우를 실행해 자동으로 분류하고 담당자를 배정한다. 이를 통해 사람이 일일이 팀원의 업무량과 가용성을 확인하던 과정을 없애고, 대규모 작업도 몇 초 안에 일관되게 라우팅할 수 있다. 예시에서는 GitLab Orbit과 두 개의 에이전트를 활용해 업무량이 가장 적은 팀원에게 새 이슈를 자동 배정했다.
## 수동 담당자 배정의 한계
- 새 이슈가 생성될 때마다 담당자가 팀원의 현재 업무량과 우선순위를 확인해야 한다.
- 회의, 휴가, 휴식 시간 등으로 인해 배정이 지연될 수 있다.
- 작업량이 증가하면 업무가 특정 팀원에게 몰리거나 초기 트리아지가 늦어진다.
- 기존 GitLab Duo Flow는 멘션, 수동 할당, 리뷰어 지정 등 사람의 행동이 있어야 시작할 수 있었다.
- 따라서 자동화된 배정 로직이 있어도 마지막 실행 단계는 수작업으로 남아 있었다.
## “Work item created” 트리거의 동작
- 프로젝트에서 새 작업 항목이 생성되는 순간 플로우를 자동 실행한다.
- 별도의 멘션이나 UI 조작 없이 백그라운드에서 지속적으로 동작한다.
- 조직이 정의한 조건에 따라 작업을 분류하고 적절한 담당자에게 라우팅한다.
- 개발자는 반복적인 배정 업무보다 판단과 창의성이 필요한 작업에 집중할 수 있다.
## 자동화로 얻는 효과
- **즉각적인 트리아지:** 작업 생성 직후 배정이 시작된다.
- **확장성:** 작업이 한 건이든 수백 건이든 담당자의 추가 개입 없이 처리한다.
- **균형 잡힌 배정:** 팀원의 현재 미해결 작업 수와 가용성을 기준으로 배정할 수 있다.
- **일관성:** 사람이 매번 판단하던 기준을 에이전트가 동일하게 적용한다.
- **반복 업무 감소:** 팀 리드가 업무량을 확인하고 수동으로 라우팅하는 시간을 줄인다.
## 두 에이전트로 구성한 자동 배정 플로우
예시 프로젝트는 `Intra-account-transfers`이며, 플로우 이름은 `Work item assigner`다.
- 프로젝트에서 “Work item created” 트리거를 활성화한다.
- 첫 번째 에이전트는 GitLab Orbit을 사용해 조직 내 각 리소스의 미해결 작업 수를 조회한다.
- 두 번째 에이전트는 업무량이 가장 적은 팀원을 식별하고 새 작업 항목의 담당자로 지정한다.
- 배정 절차와 도구 사용 방법은 각 에이전트의 프롬프트에 정의된다.
- 트리거가 플로우 전체를 실행하므로 별도의 수동 시작 작업이 필요하지 않다.
## 실행 과정과 결과
- 새 이슈를 생성하면 트리거가 즉시 `Work item assigner` 플로우를 실행한다.
- 플로우 활동 로그에서 각 단계의 진행 상황을 확인할 수 있다.
- 첫 번째 에이전트가 최상위 그룹 내 사용자의 미해결 작업 수를 집계한다.
- 두 번째 에이전트가 가장 적은 업무량을 가진 팀원을 선택한다.
- 예시에서는 William이 담당자로 선정되었고, 이슈에 자동으로 할당되었다.
## 확장 가능한 개선 방향
- **HR 또는 휴가 시스템 연동:** MCP를 통해 PTO 기간을 조회하고 휴가 중인 팀원을 배정 대상에서 제외할 수 있다.
- **캘린더 연동:** 회의 일정과 실제 가용 시간을 확인해 더 정확한 담당자 배정이 가능하다.
- 업무량뿐 아니라 전문 분야, 우선순위, 프로젝트 소속 등의 조건을 추가해 라우팅 기준을 고도화할 수 있다.
## 실용적인 결론
반복적인 이슈 배정이 병목이 되는 팀이라면 “Work item created” 트리거와 업무량 조회 에이전트를 결합하는 것이 효과적이다. 초기에는 미해결 작업 수처럼 단순하고 검증 가능한 기준으로 시작한 뒤, 휴가·캘린더·전문성 정보를 MCP로 추가하는 방식이 현실적이다.
GitLab Duo Agent Platform 도입 기업은 3년간 400%의 투자수익률(ROI)과 750만 달러의 순현재가치(NPV)를 달성했으며, 투자금 회수 기간은 6개월 이내로 분석됐다. 효과는 단순한 코드 생성 속도 향상에 그치지 않고, 개발자 온보딩·코드 리뷰·보안 취약점 수정·대규모 마이그레이션 등 소프트웨어 생명주기 전반에서 나타났다. 다만 수치는 4개 기업의 경험을 바탕으로 구성한 가상 조직의 사례이므로 모든 기업에 동일하게 적용된다고 보기는 어렵다.
## 분석 대상과 투자 구조
- Forrester Consulting은 금융 서비스, 소프트웨어 개발, 엔터테인먼트, 보험 업계의 의사결정권자 4명을 인터뷰했다.
- 인터뷰 결과를 바탕으로 다음과 같은 복합 조직을 구성했다.
- 연 매출 30억 달러
- 직원 3,000명
- GitLab Duo Agent Platform 사용자 수가 3년간 150명에서 250명으로 증가
- 3년간 위험 조정 비용은 약 190만 달러였다.
- 소비 크레딧: 130만 달러
- 구현 및 운영 관리: 58만 9,000달러
- 파일럿, 교육, 지원에 필요한 내부 인력 비용 포함
- 총 편익은 940만 달러로 산정됐다.
- 투자 대비 수익률: 400%
- 순현재가치: 750만 달러
- 투자금 회수 기간: 6개월 미만
## 도입 전: 수작업과 전문 인력 의존
- 빌드, 코드 리뷰, 보안 작업이 수작업 중심으로 운영됐다.
- 신규 개발자가 코드베이스나 사내 규칙을 이해하려면 선임 엔지니어의 직접적인 지원이 필요했다.
- 보안 취약점 수정은 관련 지식과 맥락을 가진 소수의 전문가가 처리할 때까지 대기열에 쌓였다.
- 개발자들은 코드를 작성하는 시간보다 코드 리뷰와 문제 해결에 더 많은 시간을 소모했다.
- 비공식적인 지식 공유와 특정 인력에 대한 의존성이 전체 개발 흐름의 병목으로 작용했다.
## 개발자 온보딩과 코드 이해 가속
- 신규 개발자의 온보딩 시간이 80% 단축됐다.
- IDE와 저장소에 통합된 에이전트형 채팅이 코드 구조, 프로젝트 규칙, 작업 맥락을 설명했다.
- 신규 인력이 선임 개발자를 매번 호출하지 않고도 낯선 코드베이스를 스스로 탐색할 수 있었다.
- 이 효과로 3년간 약 58만 2,000달러의 비용 절감이 발생한 것으로 추정됐다.
## 마이그레이션 기간 단축
- 온프레미스 GitLab에서 GitLab SaaS로 이전하는 대규모 마이그레이션을 수행했다.
- 당초 8개월로 계획했던 작업이 2개월 만에 완료됐다.
- 파이프라인 실패 원인을 진단하고 실시간으로 해결하는 데 GitLab Duo Agent Platform을 활용했다.
- 전체 일정이 75% 단축됐으며, 인건비 약 15만 7,000달러를 절감했다.
## 보안 및 QA 대응 효율 향상
- 보안 엔지니어와 QA 엔지니어는 업무 시간의 약 40%를 절약했다.
- 플랫폼이 오류와 취약점의 원인을 상황에 맞게 설명하고 수정 방안을 제안했다.
- 이로 인해 문제 해결 과정에서 선임 엔지니어에게 의존하는 정도가 줄었다.
- 3년간 약 130만 달러의 인건비 절감 효과가 산정됐다.
- 취약점 대응이 대기열 중심의 처리에서 즉각적인 진단과 수정 방식으로 바뀌었다.
## 개발자 생산성과 배포 속도 향상
- 각 개발자는 주당 업무 시간의 약 20%를 기능 개발에 더 사용할 수 있게 됐다.
- 에이전트형 채팅과 AI 에이전트가 다음 작업을 지원하거나 자동화했다.
- 코드 리뷰
- 테스트 작성 및 실행
- 오류 분석
- 트러블슈팅
- 전체 개발자에게서 발생한 생산성 향상 효과는 약 740만 달러로 추정됐다.
- 일부 기업에서는 수주가 걸리던 기능 릴리스가 수일 내 완료되는 사례도 보고됐다.
- 연구는 코드 생성 자체보다, 생성된 코드가 리뷰·테스트·보안 검증·배포로 이어지는 전체 흐름의 개선이 더 큰 경제적 효과를 만든다고 설명한다.
## 정량화되지 않은 추가 효과
- 여러 AI 개발 도구를 GitLab 기반 플랫폼으로 통합해 중복 비용을 줄일 가능성이 있다.
- 개발자 만족도와 업무 경험이 개선될 수 있다.
- 팀 간 지식 공유가 쉬워져 특정 전문가에 대한 의존성이 낮아질 수 있다.
- 이러한 효과는 이번 재무 모델에는 포함되지 않았다.
## 연구 결과를 해석할 때의 주의점
- 이 연구는 GitLab이 의뢰하고 Forrester Consulting이 수행했다.
- 결과는 인터뷰한 기업들의 경험과 이를 바탕으로 만든 복합 조직에 근거한다.
- Forrester는 다른 조직이 동일한 ROI를 얻을 것이라고 보장하지 않는다.
- 따라서 실제 도입 시에는 사용자 수, 기존 도구 비용, 교육·운영 인력, 보안 프로세스, 개발 병목을 기준으로 별도 측정해야 한다.
기업이 에이전트형 개발 플랫폼을 검토할 때는 코드 생성량만 평가하기보다 온보딩 시간, 리뷰·테스트 소요 시간, 취약점 수정 시간, 배포 주기, 마이그레이션 기간을 함께 측정하는 것이 바람직하다. AI의 투자 효과는 개별 개발자의 속도보다 소프트웨어 전체 생명주기에 얼마나 깊게 통합되는지에 따라 커진다.
GitLab 19.2에서 GitLab Duo CLI가 정식 출시되어, 코드 작성뿐 아니라 파이프라인 실패·테스트·보안 취약점·CI/CD 작업까지 터미널에서 처리할 수 있게 됐다. GitLab 프로젝트와 파이프라인, 에이전트 설정 및 권한 정보를 이미 알고 있어 별도 도구보다 더 일관된 컨텍스트를 제공한다. 대화형 모드와 CI·스크립트용 헤드리스 모드를 모두 지원하며, 터미널·GitLab UI·에디터 간 세션도 공유된다.
## 터미널 중심 개발의 필요성
- 기존 에이전트형 AI는 파일 편집과 코드 생성에 집중되어 있었다.
- 실제 소프트웨어 전달 과정에서는 다음과 같은 문제가 자주 발생한다.
- 파이프라인 실패
- 테스트 오류
- 의존성 문제
- CI 설정 오류
- 보안 취약점
- 이러한 문제의 핵심 컨텍스트는 로컬 코드보다 GitLab 프로젝트와 파이프라인에 있기 때문에, 일반적인 코딩 전용 CLI 도구로는 충분히 대응하기 어렵다.
- 외부 CLI 도구를 사용하면 조직 단위 관리자 제어, MCP 설정 진단, GitLab 전체 에이전트 생명주기와의 통합이 부족할 수 있다.
## GitLab Duo CLI의 주요 기능
- 터미널에서 코드 탐색, 리팩터링, CI/CD 정리, 파이프라인 장애 분석, 다단계 작업을 수행할 수 있다.
- GitLab UI, Duo CLI, 에디터 확장 기능 사이에서 세션과 대화가 공유된다.
- 브라우저에서 시작한 작업을 터미널에서 이어갈 수 있다.
- 동일한 프로젝트 맥락과 대화 내용을 유지할 수 있다.
- GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 사용할 수 있다.
- Self-Managed와 Dedicated 환경에서는 관리자가 인스턴스 단위로 접근을 활성화하거나 비활성화할 수 있다.
- `/doctor` 명령으로 설치·환경 설정을 점검하고, `/mcp` 명령으로 MCP 구성을 확인할 수 있다.
## 계획 모드와 빌드 모드
- **Plan 모드**
- 코드베이스와 관련 상황을 조사한다.
- 파일을 변경하지 않고 해결 방법을 먼저 계획한다.
- **Build 모드**
- 사용자가 승인한 뒤 실제 코드나 설정을 변경한다.
- 대화형 세션에서는 도구 실행 전에 승인을 요청하므로, 변경 사항을 검토하면서 작업할 수 있다.
## 헤드리스 모드와 자동화
- 헤드리스 모드는 사용자의 입력이나 승인 없이 실행되는 비대화형 방식이다.
- CI 러너, 셸 스크립트, 자동화 작업에 적합하다.
- 다음 명령으로 목표를 전달해 실행할 수 있다.
```bash
glab duo cli run --goal
duo run --goal
```
- 예를 들어 현재 셸에서 다음과 같이 특정 머지 리퀘스트의 파이프라인 실패 원인 분석과 수정안을 요청할 수 있다.
```bash
glab duo cli
> The pipelines in MR 23 are failing. Please help me fix them.
```
- Duo CLI는 관련 상황을 분석하고 수정안을 제안한 뒤, 적용 전에 검토할 수 있도록 한다.
## 설치와 실행 방식
- GitLab CLI를 사용하는 가장 간단한 방법은 다음 명령이다.
```bash
glab duo cli
```
- `glab`이 인증을 처리하므로 별도의 인증 절차를 줄일 수 있다.
- Duo CLI를 독립 도구로 설치하고 개인 액세스 토큰으로 실행하는 방식도 제공된다.
```bash
duo
```
- 두 방식 모두 대화형 모드와 헤드리스 모드 등 동일한 기능을 지원한다.
## 프로젝트 지침과 확장성
- Duo CLI는 프로젝트 또는 조직의 사용자 지정 지침을 따를 수 있다.
- 지원되는 지침 파일의 예시는 다음과 같다.
- `chat-rules.md`
- `AGENTS.md`
- `SKILL.md`
- 대화형 세션에는 사용자 정의 슬래시 명령을 추가할 수 있어 팀의 반복적인 작업 흐름을 확장할 수 있다.
## 실용적인 활용 방법
GitLab CLI를 이미 사용 중인 팀은 `glab duo cli`부터 도입하는 것이 좋다. 먼저 Plan 모드로 파이프라인이나 CI 설정 문제를 분석한 뒤 Build 모드에서 변경을 승인하고, 반복 작업은 `run --goal`을 이용해 CI나 스크립트에 연결하면 된다. 관리자는 Self-Managed·Dedicated 환경에서 접근 권한과 MCP 구성을 점검한 후 단계적으로 배포할 수 있다.
GitLab 19.2에서 Custom Flows가 정식 출시되며, 반복적인 소프트웨어 개발 절차를 AI 기반 워크플로로 정의하고 자동 실행할 수 있게 되었습니다. 팀은 이슈 구현, 파이프라인 오류 수정, 머지 리퀘스트 검토 같은 다단계 작업을 GitLab 이벤트나 Agentic Chat에서 시작하고, 사람은 승인과 중요한 판단에 집중할 수 있습니다. 이를 통해 개인의 기억과 수작업에 의존하던 런북을 일관된 자동화로 전환합니다.
## 다단계 개발 작업이 수작업으로 남는 이유
- 실제 소프트웨어 개발은 단일 명령으로 끝나지 않습니다.
- 작업 맥락 수집
- 코드 수정
- 머지 리퀘스트 생성
- CI 결과 대기
- 리뷰 의견 반영
- 기존의 AI 채팅은 답변만 제공하므로 각 단계의 실행과 인계는 사용자가 직접 처리해야 합니다.
- 사내 스크립트는 접근 권한, 트리거, 리뷰 정책이 변경되어도 자동으로 따라가지 못합니다.
- 그 결과 팀이 반복적으로 수행하는 절차가 자동화되지 못하고 개인의 경험이나 팀 내 구두 지식에 머물렀습니다.
## Custom Flows를 통한 워크플로 자동화
- Custom Flows는 한 번 정의한 다단계 작업을 GitLab 플랫폼에서 실행합니다.
- 다음과 같은 GitLab 이벤트를 트리거로 사용할 수 있습니다.
- 멘션
- 작업 할당
- 파이프라인 상태 변화
- 머지 리퀘스트 생명주기
- 워크 아이템 변경
- 워크 아이템 상태 변경
- 예를 들어 다음과 같은 자가 복구 파이프라인을 자동화할 수 있습니다.
- 실패한 테스트 분석
- 수정 코드 생성
- 변경 사항 커밋
- 팀에 결과 알림
- 복합 ID(composite identity)로 실행되므로 권한 범위를 제한하고 각 작업의 실행 주체를 추적할 수 있습니다.
- 민감한 단계에는 사람의 승인을 요구하는 human-in-the-loop 체크포인트를 추가할 수 있습니다.
## Agentic Chat에서 전문 플로우 실행
- 사용자가 Agentic Chat에 작업을 설명하면 요청 내용에 맞는 Foundational Flow를 추천합니다.
- 사용자는 실행을 승인한 뒤 대화 화면에서 진행 상황을 확인할 수 있습니다.
- 대표적인 전문 플로우는 다음과 같습니다.
- **Developer Flow**: 이슈나 변경 요청 구현
- **Code Review Flow**: 머지 리퀘스트 검토
- **Fix CI/CD Pipeline Flow**: 실패한 파이프라인 진단 및 수정
- 기존 채팅형 AI와 달리, 사용자가 각 중간 단계를 직접 클릭하거나 복사할 필요 없이 전체 작업이 GitLab 안에서 이어집니다.
## 코드 리뷰 자동화 제어
- 자동 코드 리뷰를 모든 머지 리퀘스트에 적용하지 않도록 제외 규칙을 설정할 수 있습니다.
- 봇이 작성한 머지 리퀘스트나 특정 브랜치 패턴을 검토 대상에서 제외해 불필요한 크레딧 소비를 막습니다.
- 사용자 정의 리뷰 지침을 통해 팀의 기준에 맞는 검토가 가능합니다.
- 따라서 어떤 머지 리퀘스트를 리뷰할지뿐 아니라 무엇을 중점적으로 검사할지도 지정할 수 있습니다.
## 설정과 확장 기능
- Custom Flow는 프로젝트 또는 AI Catalog에서 생성할 수 있습니다.
- 공개 범위를 정하고 필요한 프로젝트에서 활성화한 뒤, 적절한 GitLab 이벤트를 연결합니다.
- GitLab 19.2에서는 공개 플로우를 최대 100개 프로젝트에 일괄 활성화할 수 있습니다.
- 향후에는 Flow Creation Agent가 제공될 예정입니다.
- 사용자가 자연어로 원하는 작업 절차를 설명하면
- 전체 스키마를 직접 작성하지 않아도 실행 가능한 플로우 정의를 생성하는 방식입니다.
## 도입 시 고려할 점
- 이벤트 기반 플로우는 수행한 작업량에 따라 크레딧을 소비합니다.
- 처음부터 대규모 그룹 전체에 적용하기보다는 몇 개 프로젝트에서 먼저 테스트하는 것이 권장됩니다.
- 자동화 범위가 넓어질수록 권한 설정, 승인 단계, 제외 규칙을 함께 설계해야 합니다.
- GitLab Duo Agent Platform 무료 체험이나 Premium·Ultimate 구독에 포함된 GitLab Credits로 사용할 수 있습니다.
작업 절차가 반복적이고 팀마다 동일하게 수행된다면 Custom Flows로 먼저 인코딩하는 것이 좋습니다. 특히 이슈 구현, CI 오류 복구, 코드 리뷰처럼 단계가 명확한 업무부터 도입하고, 크레딧 사용량과 승인 지점을 확인한 뒤 적용 범위를 넓히는 방식이 실용적입니다.
더 나은 코드 탐색 도구를 도입했지만, 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% 절감했다.
- 글에서는 이 개선이 리뷰 품질을 유지한 상태에서 이루어졌다고 설명한다.
## 실용적인 결론
에이전트 도구를 교체할 때는 도구의 기능만 비교해서는 안 된다. 도구 사용 지침과 에이전트가 따라야 할 탐색 워크플로까지 작업 목적에 맞게 설계해야 하며, 특히 코드 리뷰에서는 “더 많이 읽기”보다 “변경 사항을 검증하는 데 필요한 최소한만 읽기”가 비용과 품질 모두에 유리하다.
