지난 호에서는 모델을 바꾸기 전에 맡길 일을 나눠야 한다고 썼습니다. 어떤 모델이 가장 높은 점수를 받았는지보다, 어떤 일을 어떤 기준으로 맡길지 먼저 정해야 한다는 이야기였습니다.

이번 주에는 먼저 Gemini 4 Argon 이야기를 짚고 넘어가려 합니다.

Google은 9월 30일 Argon을 발표했고, 최대 출력 한도를 기존 64K에서 1M 토큰으로 확대했다고 설명했습니다. 긴 작업을 한 번에 수행할 가능성을 보여주는 변화라 저 역시 관심 있게 보고 있습니다.

다만 지금 제가 Argon에 대해 덧붙일 수 있는 이야기는 많지 않습니다. 초기 접근 대상이 제한돼 있고, 저는 내부 사용자도 아니며 직접 사용해 검증할 수 있는 상태도 아닙니다.

발표 자료만 다시 요약하고 “좋아 보인다”고 적는 건 L-Proof에서 굳이 할 필요가 없다고 봤습니다.

릴리스 자체의 정보는 관심 있는 분이라면 이미 접했을 가능성이 높습니다. 직접 접근할 수 있거나 실제 사용 사례와 검증 자료가 더 쌓였을 때, 그때 다시 제 판단을 붙여 다뤄보겠습니다.

그래서 이번 호에서는 조금 다른 질문을 골랐습니다.

모델을 바꿨을 때도 우리의 작업 방식은 남을 수 있을까?

이번 주 소식들을 보다 보니 모델 자체보다 그 주변에 쌓이는 것에 더 눈이 갔습니다. Qwen Code는 하나의 모델에 묶이지 않는 실행 환경을 만들고 있고, GitHub는 코드 리뷰를 기존 워크플로에 연결할 수 있게 했습니다. Cloudflare는 운영 오류의 맥락을 에이전트에 넘기고, Anthropic의 취약점 대시보드는 AI가 찾은 결과를 사람이 처리하고 추적하는 별도의 흐름을 보여줍니다.

좋은 모델은 계속 바뀔 겁니다. 그렇다면 개발팀이 오래 가져가야 할 자산은 모델 이름보다 작업을 전달하는 방식, 맥락을 쌓는 방법, 검증 기준과 기록에 더 가까울 수 있습니다.

조사 범위는 한국 시간 9월 30일~10월 5일 작성 시점까지입니다. 아래 내용은 공식 자료를 확인한 수준이며, 제품의 성능과 품질을 직접 비교 테스트한 결과는 아닙니다.

1. Qwen 생태계에서 보이는 두 가지 분리 — 실행 환경과 모델

PROOF LEVEL 03 · 공식 확인

사실 요약

Bilibili는 9월 30일 Qwen3.5를 기반으로 만든 번역 모델군 Index-Translate를 공개했습니다. 텍스트 모델은 150개 언어를 대상으로 하며 2B·9B·35B-A3B 프리뷰가 제공됩니다. 단순 번역뿐 아니라 용어, 서식, 내용 보존 같은 지시를 따르는 것을 주요 평가 대상으로 삼고 있습니다.

10월 3일에는 GGUF·FP8·NVFP4 양자화 빌드가 추가됐고, 10월 4일에는 35B-A3B용 무료 OpenAI 호환 API와 평가 데이터·스크립트가 공개됐습니다.

이번 발표를 계기로 Qwen Code도 같이 볼 만합니다. 현재 공식 문서에서 Qwen Code는 Qwen 모델만 사용하는 도구로 설계돼 있지 않습니다. OpenAI 호환 API, Anthropic, Gemini, Vertex AI를 별도 provider로 설정할 수 있고, Ollama·vLLM·LM Studio처럼 OpenAI 호환 인터페이스를 제공하는 로컬 서버도 연결할 수 있습니다.

개발자에게 중요한 점

여기서는 두 방향이 같이 보입니다.

Qwen Code에서는 하나의 작업 환경에 여러 모델을 넣을 수 있고, Index-Translate에서는 범용 기반 모델을 특정 업무에 맞는 별도 모델로 발전시킵니다.

한쪽에서는 모델을 갈아끼울 수 있게 만들고, 다른 쪽에서는 기반 모델을 더 좁은 용도에 맞게 파고듭니다.

이런 구조가 자리 잡으면 개발자는 프로젝트 지침이나 도구 연결, 승인 과정 같은 건 유지한 채 밑에서 쓰는 모델만 바꾸거나, 특정 작업만 별도 모델에 넘기는 선택을 할 수 있습니다.

물론 여러 API를 연결할 수 있다는 것과 서로 다른 모델이 같은 품질로 동작한다는 건 전혀 다른 이야기입니다.

Lee's Take

오픈 모델을 평가할 때 이제는 원본 모델의 벤치마크만 보기 어렵다고 생각합니다.

그 모델 위에서 무엇이 만들어지고 있는지도 봐야 합니다.

Index-Translate가 흥미로운 것도 Qwen3.5가 번역 벤치마크에서 몇 위였기 때문만은 아닙니다.

다른 팀이 그 모델을 재료로 삼아서 번역이라는 좁은 문제에 맞는 모델과 평가 기준, 로컬 실행 경로, API까지 만들고 있습니다.

반대로 Qwen Code에서는 모델 자체를 갈아끼울 수 있는 부품에 가깝게 보려는 방향이 보입니다.

그래서 앞으로는 이런 질문도 같이 보려고 합니다.

이 모델이 가장 좋은가? 그리고 이 모델을 바꿔도 우리의 작업 방식은 얼마나 남는가?

직접 확인해볼 것

지금 쓰는 코딩 에이전트에서 모델에 묶여 있는 것과 모델을 바꿔도 남는 것을 한번 나눠볼 수 있습니다.

프롬프트, 프로젝트 규칙, MCP·도구 연결, 테스트, 승인 절차 중 무엇이 특정 공급자에 묶여 있는지부터 보면 됩니다.

원문: Bilibili Index-Translate 공식 저장소 참고: Qwen Code Model Providers 공식 문서

2. Copilot 코드 리뷰 API — AI 기능보다 연결 지점이 늘어난다

PROOF LEVEL 03 · 공식 확인

사실 요약

GitHub는 10월 2일 Copilot 코드 리뷰를 REST·GraphQL API로 요청할 수 있게 했습니다. 요청마다 리뷰 effort level도 지정할 수 있습니다. 대상은 Copilot Pro·Pro+·Max·Business·Enterprise입니다.

같은 공지에 포함된 Balanced 기본값 변경은 9월 28일부터 적용된 별도 변화입니다. 이번 호에서 새롭게 볼 부분은 API를 통해 리뷰를 요청할 수 있게 된 것입니다.

개발자에게 중요한 점

코드 리뷰 기능 자체는 새 개념이 아닙니다.

제가 더 눈여겨본 건 Copilot 리뷰를 GitHub 화면 안에서 사람이 직접 누르는 기능으로만 두지 않고, 팀이 이미 사용하는 스크립트나 워크플로에서 호출할 수 있게 됐다는 것입니다.

모든 PR을 똑같이 리뷰하게 할 필요는 없습니다.

결제나 인증 코드를 수정했을 때만 강한 리뷰를 걸 수도 있고, CI가 통과한 뒤에만 AI 리뷰를 호출할 수도 있습니다. 큰 diff만 따로 보게 하는 것도 가능합니다.

이쯤 되면 모델이 리뷰를 얼마나 잘하는지와 별개로 언제 AI를 부를 것인지도 팀 설계의 일부가 됩니다.

Lee's Take

저는 AI 개발 도구에서 기능 자체보다 기존 시스템과 어디에서 연결되는지를 더 보게 됩니다.

팀마다 위험하다고 보는 변경이 다르고, 테스트나 배포 순서도 다릅니다. AI가 이 흐름 바깥에서 따로 움직이면 결국 사람이 다시 상황을 설명해야 합니다.

반대로 리뷰 요청을 팀의 조건 안에 넣을 수 있다면 모델이 나중에 바뀌어도 “어떤 변경을 어떻게 검토한다”는 규칙은 남습니다.

저라면 제품 이름보다 이 규칙을 먼저 쌓겠습니다.

팀에 적용한다면

처음부터 모든 PR에 AI 리뷰를 붙이기보다, 어디에서 특히 필요한지부터 정하는 편이 낫습니다.

인증·결제처럼 위험도가 높은 경로나 큰 변경, 테스트 실패가 있었던 PR처럼 조건을 좁혀 시작할 수 있습니다.

원문: GitHub — Copilot code review API support

3. Cloudflare Issues — 에이전트에게 코드보다 먼저 맥락을 넘긴다

PROOF LEVEL 03 · 공식 확인

사실 요약

Cloudflare는 9월 30일 Workers의 오류 모니터링 기능 Issues를 공개 베타로 발표했습니다.

Issues는 반복되는 예외, 5xx 응답, 오류 로그를 하나의 이슈로 묶고 오류·스택 추적·로그·트레이스·Worker 버전 등의 정보를 보여줍니다. 일정 발생 횟수를 넘거나 잠잠했던 문제가 다시 나타났을 때 Automations를 통해 Claude Code·Cursor·Devin 또는 일반 webhook 등에 이 정보를 전달할 수 있습니다.

Cloudflare는 에이전트가 추가 로그를 조사하고 코드와 테스트 변경을 제안하거나 PR을 여는 흐름을 설명합니다. 다만 운영 반영은 사람이 PR을 검토하고 배포하는 구조로 안내하고 있습니다.

개발자에게 중요한 점

코딩 에이전트가 저장소를 읽을 수 있다고 해서 운영 장애의 원인까지 자동으로 아는 건 아닙니다.

어느 버전부터 문제가 시작됐는지, 특정 사용자나 세션에 몰렸는지, 얼마나 자주 반복됐는지는 코드 저장소 밖에 있습니다.

Cloudflare Issues에서 제가 본 핵심은 에이전트를 더 똑똑하게 만드는 게 아니라 문제가 발생한 환경의 맥락을 구조화해서 넘기는 방식입니다.

이건 프롬프트를 잘 쓰는 문제와도 조금 다릅니다.

사람이 매번 로그를 찾아 복사하고 상황을 설명하는 대신, 처음부터 시스템이 어떤 정보를 넘길지 정해두는 문제입니다.

Lee's Take

에이전트를 많이 쓰게 될수록 컨텍스트를 공급하는 파이프라인도 팀의 자산이 될 것 같습니다.

모델은 바꿀 수 있습니다. 하지만 어떤 로그를 남길지, 어떤 배포 정보와 연결할지, 어디부터 문제로 볼지는 서비스 운영자가 정해야 합니다.

좋은 모델을 붙였는데도 사람이 매번 상황 설명부터 해야 한다면 자동화의 병목은 모델이 아닐 수 있습니다.

앞으로 에이전트 도입 사례를 볼 때 저는 이것도 같이 보려고 합니다.

이 에이전트는 일을 시작할 때 필요한 맥락을 어디서 받는가?

제가 먼저 볼 부분

최근 버그 하나만 떠올려도 금방 확인할 수 있습니다.

코드만 넘겼을 때 빠지는 게 무엇이었는지 보면 됩니다. 배포 버전인지, 로그인지, 사용자 상태인지, 재현 조건인지.

그중 다음번부터 자동으로 붙일 수 있는 정보가 있다면 그게 먼저 개선할 부분입니다.

원문: Cloudflare — Detect and send production issues straight to your agent

4. Anthropic 취약점 대시보드 — 발견보다 오래 남는 것은 처리 과정이다

PROOF LEVEL 03 · 공식 확인

사실 요약

Anthropic의 공식 취약점 공개 대시보드는 10월 2일 기준 Claude 계열 모델이 발견한 후보 가운데 591개 오픈소스 프로젝트의 6,157건을 공개했다고 집계하고 있습니다. 회사가 파악한 upstream 패치 완료 건수는 516건입니다. 마지막 갱신은 10월 2일 19:47 UTC입니다.

대시보드에는 더 앞선 단계도 표시됩니다. 29,439개의 발견 후보가 사람의 분류 과정을 거치고, 그중 일부가 외부 보안 업체의 리뷰와 검증, 유지보수자 보고 단계로 이동합니다. Anthropic은 독립적인 사람의 triage와 review를 현재 처리 속도의 제한 요인으로 설명합니다.

516건의 패치는 6,157건을 단순히 나눠 모델의 성공률을 계산할 수 있는 지표가 아닙니다. disclosed, acknowledged, patched upstream은 서로 다른 단계입니다.

개발자에게 중요한 점

모델이 더 많은 취약점을 찾으면 병목도 뒤로 이동합니다.

후보를 분류하고, 재현하고, 우선순위를 정하고, 담당자에게 전달하고, 수정 여부를 확인해야 합니다.

모델은 바뀌어도 이 과정은 없어지지 않습니다.

그래서 산출물 수만 보는 평가에는 한계가 있다고 봅니다.

무엇이 제안됐고, 무엇이 검증됐고, 실제로 무엇이 해결됐는지까지 남아야 합니다.

Lee's Take

이번 대시보드에서 제가 가장 흥미롭게 보는 숫자는 6,157도 516도 아닙니다.

숫자 사이에 단계가 있다는 사실입니다.

AI가 발견했다는 것과 사람이 쓸 수 있는 결과가 됐다는 것은 다릅니다. 보고했다는 것과 실제 문제가 해결됐다는 것도 다릅니다.

모델 성능이 높아질수록 이런 상태 관리는 오히려 더 중요해질 겁니다.

산출물이 적을 때는 사람이 기억으로 관리할 수도 있습니다. 수천 건이 되면 얘기가 달라집니다.

에이전트를 많이 쓰는 조직이 쌓아야 할 것도 프롬프트 모음만은 아닐 겁니다.

무엇이 제안됐고, 무엇을 믿었고, 무엇을 수정했고, 무엇이 실제로 해결됐는지 남기는 기록.

저는 이쪽이 더 오래 남는 자산이라고 봅니다.

한번 붙여볼 상태값

복잡하게 시작할 필요는 없습니다.

제안됨 → 검토됨 → 적용됨 → 확인됨

AI가 만든 결과에 이 정도 상태만 붙여도 생각보다 많은 게 보입니다. 코드 수정뿐 아니라 조사, 문서 작성, 운영 자동화에도 그대로 써볼 수 있습니다.

원문: Anthropic — Coordinated vulnerability disclosure dashboard

지난 호에서는 모델을 바꾸기 전에 맡길 일을 나눠야 한다고 이야기했습니다.

이번에는 그다음을 생각해봤습니다.

모델을 바꿔도 남아야 할 것은 무엇일까요?

Qwen Code에서는 모델과 실행 환경을 분리하는 방향을 볼 수 있습니다. Index-Translate는 범용 모델 위에서 특정 업무를 위한 전문 모델과 평가 체계가 만들어지는 사례입니다. GitHub는 AI 리뷰를 기존 개발 흐름에 연결할 수 있는 API를 열었고, Cloudflare는 운영 환경의 맥락을 에이전트에게 전달하는 구조를 만들고 있습니다. Anthropic은 모델이 만든 결과를 사람이 처리하고 추적하는 흐름을 보여줍니다.

네 사례를 놓고 보면 모델 바깥에 남는 건 크게 세 가지입니다.

작업을 전달하는 규칙, 일을 수행할 때 필요한 맥락, 그리고 결과를 판단하는 기준입니다.

어떤 모델이 가장 좋은지는 계속 바뀔 겁니다. 다음 달에는 지금 쓰는 모델보다 더 좋은 선택지가 나올 수도 있습니다.

그때마다 개발 프로세스까지 처음부터 다시 만들어야 한다면 우리는 모델을 사용한 게 아니라, 모델에 작업 방식을 종속시킨 셈입니다.

반대로 모델을 바꿔도 프로젝트 규칙과 도구 연결, 테스트, 승인선, 운영 데이터와 평가 기록이 남는다면 새로운 모델은 기존 시스템에 넣어 비교할 수 있는 하나의 선택지가 됩니다.

그래서 이번 주에는 새로운 모델을 하나 더 시험하기 전에 이것부터 보려고 합니다.

내가 지금 쌓고 있는 것 중 다음 모델에서도 가져갈 수 있는 것은 무엇인가.