긴 연휴를 앞둔 금요일, 나는 노트북을 닫으면서 에이전트에게 레거시 웹훅 핸들러 (legacy webhook handler)를 마이그레이션해 달라고 요청했습니다. 에이전트는 컴파일이 가능하고 테스트를 통과하며, 내가 확인하지 않고는 변경하고 싶지 않은 피스처 (fixture)에 대한 메모를 남긴 diff를 가져왔습니다. 이것이 현재 에이전트들이 제안되는 작업의 형태이며, Anthropic의 Claude Sonnet 5가 Duo Agent Platform에 도착함에 따라 GitLab이 목표로 하는 작업의 형태이기도 합니다.

실제로 도입된 내용

GitLab은 GitLab의 AI Gateway를 통해 라우팅되는 방식으로, 플랫폼이 지원하는 모든 티어와 모든 배포 모델에 걸쳐 Duo Agent Platform에 Claude Sonnet 5를 추가했습니다. GitLab은 이 모델을 에이전트가 이미 CI/CD 루프 내에서 수행하는 작업, 즉 다단계 작업 (multi-step tasks), 리뷰를 견딜 수 있는 코드, 그리고 벤더가 대규모로 실행하기에 저렴하다고 부를 수 있는 워크플로 (workflows)를 위해 배치했습니다.

GitLab이 여러분이 주목하기를 바라는 숫자는 벤치마크 (benchmark) 수치입니다. Sonnet 5는 GitLab 자체 평가 스위트 (evaluation suite)에서 모든 벤치마크 작업을 완료한 첫 번째 모델입니다. 이전 모델인 Sonnet 4.6은 그중 93.8%를 완료했습니다. 이 부분을 주의 깊게 읽으십시오. 이것은 여러분의 것이 아니라 GitLab의 벤치마크이며, 벤치마크는 천장이 아니라 바닥이기 때문입니다.

AI Gateway를 거치는 것이 실제로 제공하는 이점

이미 Duo를 사용하고 있다면, 모델의 변경만큼이나 전달 방식의 세부 사항도 중요합니다. AI Gateway는 요청이 이를 처리할 Anthropic 엔드포인트 (endpoint)에 도달하기 전에 거치는 단일 홉 (hop)이며, 이 홉이 있다는 것은 평범한 화요일의 개발자가 실제로 체감할 수 있는 몇 가지 의미를 갖습니다.

이는 한 곳에서 여러분이 어떤 모델 버전을 사용하는지 결정한다는 것을 의미합니다. 벤더가 포인트 릴리스 (point release)를 배포할 때, 모든 사용자가 설정을 다시 작성할 필요 없이 게이트웨이를 해당 버전으로 지정할 수 있습니다. 또한 한 곳에서 로깅 (logging), 할당량 (quota), 그리고 (셀프 매니지드 환경의 경우) 인증 (authentication)을 처리한다는 것을 의미합니다. 아울러 거버넌스 (governance)가 요구될 때, 플랫폼 팀이 모든 팀에게 에디터 설정을 변경하라고 요청하지 않고도 특정 프로젝트를 특정 모델에 고정할 수 있음을 의미합니다.

이러한 패턴은 GitLab만의 고유한 것이 아닙니다. 서드파티 모델 (third-party model)을 래핑(wrap)하는 모든 진지한 플랫폼은 현재 어떤 형태로든 게이트웨이 (gateway)를 운영하고 있습니다. 그것이 에디터 플러그인 내부의 모델 선택기 (model picker)이든, 벤더가 운영하는 추론 프록시 (inference proxy)이든, 혹은 프롬프트 (prompt)가 제공업체의 로그에 남는 것을 방지하기 위해 사람들이 운영하는 점점 늘어나는 셀프 호스팅 OSS 게이트웨이 (OSS gateways)이든 말입니다. 흥미로운 변화는 게이트웨이 패턴이 이제 미리보기 기능 (preview feature)이 아닌 기본 가정 (default assumption)이 되었다는 점입니다.

일상에서 나타나는 모습

개발자 경험 (DX)을 중시하는 사람이 관심을 갖는 지점은 루프 (loop)의 지루한 중간 단계입니다. 에이전트 (agent)가 수행하는 다단계 작업은, 당신이 확신을 가지고 노트북을 덮느냐, 아니면 에이전트가 조용히 함수 이름을 지어내지는 않았는지 확인하기 위해 10분마다 다시 확인하느냐를 결정짓는 지점입니다. 만약 GitLab의 평가 수치가 실제 환경에서도 유지된다면, 후자의 상황은 점점 드물어질 것입니다.

어떤 모델을 사용하든 상관없이 가져가야 할 두 가지 습관:

• 에이전트 실행 과정을 CI 로그가 있는 것과 동일한 장소에서 확인할 수 있도록 만드세요. 에이전트를 확인하는 유일한 방법이 에디터를 다시 여는 것이라면, 당신은 계속해서 자신의 흐름을 방해하게 될 것입니다.
• 벤더의 벤치마크 (benchmarks)를 약속이 아닌 스모크 테스트 (smoke test)처럼 취급하세요. 모델을 백로그 (backlog)에서 가장 까다로운 티켓 두 개, 즉 오래된 커밋과 지저분한 테스트가 포함된 티켓에 적용해 보고, 모델이 그것들을 어떻게 처리하는지 확인하십시오.

거친 단면들 (The rough edges)

GitLab이 Sonnet 4.6에 대해 인용한 93.8%라는 수치는 정직한 보고이며, 동시에 벤더 자체 제품군에서의 완전한 통과가 당신의 모노레포 (monorepo)로 직접 연결되지는 않는다는 점을 상기시켜 줍니다. 호스팅된 모델의 변경이 고전적인 문제점들을 해결해주지는 않습니다. 불안정한 테스트 스위트 (flaky test suite)는 여전히 불안정합니다. 문서화가 부족한 서비스는 여전히 새로운 에이전트를 혼란스럽게 합니다. 이미 포화 상태인 머지 큐 (merge queue)는 PR 리뷰 뒤에 있는 모델이 더 똑똑해졌다고 해서 갑자기 빨라지지 않습니다.

또한 플랫폼 종속 (platform lock)이라는 명백한 사실도 존재합니다. 일단 팀이 Duo의 모델 라우팅 (model routing)에 맞춰 에이전트 워크플로 (agent workflows)를 작성하고 나면, 동일한 워크플로를 다른 플랫폼으로 옮기는 것은 단순히 프롬프트 (prompts)를 다시 쓰는 것이 아니라 배관 (plumbing) 자체를 다시 설계해야 함을 의미합니다. 이것은 새로운 현상은 아니며, 그렇다고 해서 참여를 주저해야 할 이유는 아니지만, 18개월 후에 아무도 당황하지 않도록 미리 언급해 둘 가치가 있습니다.

다음으로 주목하고 있는 것

두 가지입니다. 첫째, GitLab이 향후 몇 주 동안 자체 Duo 파이프라인 (pipelines)에서 Sonnet 5를 실행하는 팀들로부터 벤치마크 (benchmark) 수치가 아닌 실제 환경의 수치를 공개할지 여부입니다. 그것이 바로 엔지니어가 실행에 옮길 수 있는 데이터입니다. 둘째, "모든 배포 모델 (all deployment models)"라는 설명이 셀프 매니지드 (self-managed) 고객들에게도 깔끔하게 유지될지 여부입니다. 왜냐하면 AI 게이트웨이 (AI Gateway)는 셀프 매니지드 환경이 보통 SaaS와 달리 화요일 아침에 골치 아픈 방식으로 갈라지는 접점이기 때문입니다.

이미 Duo 에이전트를 새로운 모델로 전환했다면, 여러분의 일상적인 업무 중 어떤 것이 더 조용해졌는지(수월해졌는지), 그리고 어떤 작업은 여전히 너무 느려서 기다리느라 창을 전환해야 하는지 알려주시면 감사하겠습니다.