AI가 밤새 코드를 고쳤습니다. 아침에 받아 든 제안은 여섯 가지였고, 사람이 검토한 뒤 실제로 반영한 것은 두 가지였습니다.
Google이 새 모델 Gemini 4 Argon과 함께 공개한 개발 사례입니다. 성능 개선 숫자만큼이나, 나머지 네 가지를 왜 버렸는지가 눈에 남습니다.
이번에는 코드를 찾는 일을 작은 모델에 맡기는 도구, 내 기기에서 실행하는 새 모델, 개발 도구를 연결하는 마켓플레이스도 나왔습니다. GitHub는 커밋에 적힌 작성자와 실제로 코드를 올린 계정을 따로 보여주기 시작했습니다.
10월 9~14일 공개 자료를 살폈습니다. 아래 소식은 모두 03 · 공식 확인으로, 개발사·연구팀의 발표와 문서를 확인한 수준입니다. 제품 사용이나 성능 실험을 직접 재현한 결과는 아닙니다.
Gemini 4 Argon — 밤새 만든 제안에도 버릴 것이 있었다
Google은 10월 13일 Gemini 4 Argon의 이용 범위를 개발자와 일반 사용자로 넓혔습니다. 개발자는 Google AI Studio와 Google Cloud의 API에서 사용할 수 있고, Gemini 앱에서는 Google AI Pro·Ultra 가입자에게 제공됩니다. 지난 호의 팀용 Gemini 계정 소식에 이어, 이번에는 그 안팎에서 사용할 모델이 새로 공개됐습니다. Google 공식 발표
API 출시 프로모션 가격은 100만 토큰당 입력 $2, 출력 $10이며 11월 30일까지 적용됩니다. 이후에는 입력 $4, 출력 $20의 표준 가격이 적용된다는 안내입니다. 장기 사용 비용을 계산한다면 두 가격을 나눠 봐야 합니다. Google Cloud 가격 안내
Google이 함께 공개한 실험 대상은 약 20만 줄의 ADK Python 저장소였습니다. 기존 코드의 성능을 개선하는 작업을 맡겼고, 저장소 규칙과 장기 실행 설정을 갖춘 두 번째 실행은 11시간 이어졌습니다. Google은 최종 반영한 변경으로 긴 세션의 메모리 기반 세션 준비 시간이 약 40%, 패키지 초기 import 시간이 21% 줄었다고 보고했습니다. 전체 에이전트 작업이 그만큼 빨라졌다는 뜻은 아닙니다.
제외된 제안 중에는 벤치마크에서는 빨랐지만 오래된 데이터를 돌려줄 수 있는 캐시가 있었고, 외부 라이브러리의 내부 구현에 기대는 변경도 있었습니다. 테스트를 통과하는 것과 유지보수자가 받아들일 만한 변경은 겹치지만, 같지는 않았습니다. Google은 채택한 두 가지와 버린 네 가지의 이유를 함께 공개했습니다. ADK 개발 기록
ColGrep — 코드를 찾는 데 큰 모델을 계속 부를 필요가 있을까
코딩 에이전트가 버그를 고치기 전에 파일 이름을 추측하고 검색어를 바꾸는 모습을 볼 때가 있습니다. 수정할 곳을 찾는 데도 여러 차례 모델 호출이 듭니다.
LightOn이 10월 12일 소개한 ColGrep-Agent-2B는 이 탐색을 로컬의 20억 파라미터 모델에 맡깁니다. 코드의 의미를 검색하고 참조를 따라간 뒤, 파일 경로·줄 범위·코드를 주 에이전트에게 돌려줍니다. 관련 논문은 10월 4일 먼저 공개됐고, 이번 게시물에는 Claude Code에 연결한 실험과 사용 방법이 담겼습니다. 연구 논문
연구팀은 Sonnet 5.5를 쓰는 Claude Code로 13개 저장소의 코드 검색 질문 52개를 평가했습니다. 검색을 ColGrep-Agent에 맡겼을 때 기본 검색 도구만 쓴 경우보다 API 토큰이 약 34% 줄었습니다. 로컬 모델이 쓴 토큰은 이 집계에 포함되지 않습니다.
대신 질문당 시간은 13.0초에서 21.6초로 늘었습니다. 정답률도 83.3%에서 80.8%로 달라졌습니다. 통계적으로 유의한 차이는 아니었지만, 연구팀 역시 의미 있는 정확도 하락을 배제할 수 없다고 적었습니다. 코드 검색 실험의 결과이며, 버그 수정 전체의 비용이나 성공률을 측정한 것은 아닙니다. LightOn 발표·실험 결과
Liquid AI — 내 기기에서 계속 일할 모델
Liquid AI는 10월 13일 LFM2.5-24B-A2B의 가중치를 공개했습니다. 총 240억 파라미터 중 토큰을 처리할 때 활성화되는 부분은 약 20억이며, 추론과 도구 호출을 수행하는 로컬 에이전트를 겨냥합니다. 입력 문맥 범위는 이전 모델의 약 3만 2천 토큰에서 약 13만 1천 토큰으로 늘었습니다.
발표에 실린 자체 평가에서는 도구 사용·지시 따르기에 강점이 있었지만, 코드 수정과 지식 중심 평가에서는 더 큰 비교 모델들이 앞서는 항목도 있었습니다. llama.cpp·MLX·vLLM 등으로 실행할 수 있어, 기기 안에서 반복적으로 맡길 일을 찾는 팀에는 시험할 선택지가 하나 더 생겼습니다. 실제 필요한 메모리와 속도는 양자화·문맥 길이·하드웨어 조건을 함께 봐야 합니다. 활성 파라미터 수만으로 실행 사양을 정할 수는 없습니다. Liquid AI 공식 게시물
Cursor — Origin에 배포와 모니터링 도구가 붙는다
코드를 보관하는 곳을 바꾸려면 배포, CI, 오류 추적까지 다시 연결해야 합니다. Cursor가 10월 13일 연 Origin App Marketplace는 이 주변 도구들을 모았습니다. Cloudflare·Vercel 같은 배포 서비스, Sentry, Linear 등을 포함해 20개가 넘는 앱이 연결되고, 외부 개발팀의 앱 제출도 받기 시작했습니다.
앱은 저장소에서 발생하는 이벤트를 받아 검사 결과나 PR 댓글·리뷰를 기록할 수 있습니다. 직접 만든 앱은 비공개로 개발한 뒤 공개하고, Cursor의 심사를 거쳐 마켓플레이스에 올립니다. Cursor 변경 기록
Origin 자체는 Cursor의 Git 저장소 서비스로 아직 초기 베타입니다. 유료 플랜에 단계적으로 제공되며, GitHub 저장소를 미러링하는 방식도 지원합니다. 이번 소식은 Origin을 처음 내놓았다는 발표가 아니라, 여기에 연결할 도구와 배포 경로가 넓어졌다는 업데이트입니다. Origin 공식 문서
GitHub — 커밋에 적힌 이름과 실제로 올린 계정을 따로 본다
커밋의 author·committer 이름과 이메일은 클라이언트가 적어 보내는 값입니다. 그 이름만 보고 누가 저장소에 코드를 올렸는지 확정할 수는 없습니다.
GitHub는 10월 12일, 푸시할 때 인증한 계정을 커밋별로 기록해 UI와 API에 표시하는 push attribution을 제한적 공개 프리뷰로 내놓았습니다. committer 이메일이 푸시한 계정의 검증된 이메일과 맞아야 한다는 저장소 규칙도 추가됐습니다.
현재는 GitHub Enterprise 고객이 담당 팀을 통해 참여를 요청하는 단계입니다. 자동화가 만든 커밋을 추적해야 하는 팀이라면 눈여겨볼 변화입니다. 다만 이 기록으로 확인되는 것은 푸시한 계정입니다. 사람이 변경 내용을 읽고 승인했는지까지 알려주는 기록은 아닙니다. GitHub 공식 변경 기록
L-Proof의 해석
작은 모델이 큰 모델의 시야를 정한다
지난 호에서는 AI에게 큰 일을 맡기기 위해 판단을 잘게 나누는 사례들을 소개했습니다. ColGrep의 사례는 그다음 질문을 남깁니다. 일을 나눠 맡긴 작은 모델이, 큰 모델에게 무엇을 보여줄지까지 정한다면 어떨까요.
검색 결과를 잘 추리면 큰 모델이 직접 검색을 반복하는 횟수를 줄일 수 있습니다. 반대로 관련 파일 하나가 빠지면, 이후의 답변이 아무리 논리적이어도 빠진 근거를 되찾지 못할 수 있습니다. 가령 수정할 함수는 찾았지만 그 함수를 다른 방식으로 쓰는 호출부를 놓친 경우입니다. 이는 이번 실험에서 확인된 사고가 아니라, 이런 구조를 도입할 때 생각해볼 실패입니다.
L-Proof가 더 눈여겨보는 것은 작은 모델이 어디까지 찾아봤는지 남기는 기록입니다. “이 파일을 고치면 된다”와 함께 “다른 호출부까지는 확인하지 못했다”가 전달되면, 주 에이전트는 검색을 넓힐 수 있습니다. 토큰을 아끼는 과정에서 재확인할 단서까지 지워버리는 것은 아닌지 보고 싶습니다.
내일의 유지보수까지 오늘의 목표에 들어 있을까
Argon의 개발 기록에서 거절된 변경은 단순히 코드를 못 짜서 생긴 것만은 아닙니다. 당장의 성능 목표에는 도움이 되더라도, 다음 라이브러리 업데이트나 일상적인 운영까지 생각하면 남겨두기 어려운 제안이 있었습니다.
여기서 사람의 역할을 “AI가 틀렸는지 확인한다”로만 설명하면 조금 좁습니다. 유지보수자는 얻는 속도에 비해 앞으로 떠안을 복잡함이 괜찮은지도 판단합니다. 빨라졌다는 증거가 있어도 그 변경을 거절할 수 있습니다.
L-Proof는 에이전트가 더 오래 일할수록, 이런 거절 이유가 다음 작업에 남는지가 중요해질 것으로 봅니다. 같은 종류의 제안을 매번 만들어내고 사람이 매번 잘라낸다면, 밤사이의 작업량은 늘어도 아침의 검토 부담은 줄지 않을 겁니다.
앞으로 보고 싶은 것은 AI가 제안을 몇 개 냈느냐에 더해, 지난번에 거절당한 이유를 다음 제안에서 얼마나 잘 반영했느냐입니다. 밤새 일한 흔적이 다음 날의 더 나은 판단으로 이어지는지 말입니다.