Vibe Programming Lab

버전이 바뀐 플러그인을 AI 에이전트에게 옮기게 할 때, 답변 점수가 높다는 사실만으로 실제 수정이 안전하다고 말할 수 있을까요? 이번 논문은 점수 상승과 구체적인 계약 위반 사례가 함께 존재할 수 있음을 보여줍니다. 핵심은 “스킬이 효과 있다/없다”의 단정이 아니라, 무엇을 시험했고 무엇은 아직 시험하지 않았는지를 평가표에서 분리하는 일입니다. Beiming Liu 외 연구진의 「Evaluating Agent Skills for Version-Specific Plugin Migration: A Retrospective Study」(arXiv:2609.30120v1, 2026년 9월 24일 공개)는 한 플러그인 마이그레이션 스킬을 정적 진단 과제에 적용한 후향 연구입니다. 본문 §4.1은 22개 정적 과제에서 층화 추출한 16개를 비교합니다. 스킬 없음/있음 두 조건에서 과제마다 두 번씩 실행해 64개 보고서를 만들고, 328개의 기준별 판정을 매겼습니다. 반복 보고서와 기준 판정 수를 독립적인 마이그레이션 과제 수로 세면 안 됩니다. 평균은 올랐지만, 무엇의 평균인가 표 1의 원래 루브릭 평균은 스킬 없음 93.83, 스킬 있음 98.75로 차이는 4.92점입니다. 이는 0~100점 보상 척도의 점수 차이지, 상대 개선율도 아니고 “마이그레이션 성공률이 4.92% 상승”했다는 뜻도 아닙니다. 16개 과제 중 6개는 상승, 2개는 하락, 8개는 두 조건 모두 100점이었습니다. S1 하나가 42.5점을 보탰고, 이를 제외하면 나머지 15개 과제의 평균 차이는 2.42점입니다. 논문이 제시한 과제 단위 부트스트랩 95% 구간은 [0.31, 10.86], Wilcoxon 검정의 p값은 0.0797입니다. 이 숫자는 관찰된 과제들에 대한 탐색적 요약으로 읽는 편이 정확합니다. 천장 효과가 크고 한 과제의 기여가 두드러지며, 연구진도 후향적 단일 사례라는 범위를 설명합니다. 이 구간을 다른 플러그인·모델·운영체제에 그대로 일반화할 수 없습니다. 원 루브릭 평...

생성형 AI 데모에서 말하는 아바타가 실제 업무에 쓸 수 있는 기능인지 판단하려면, 먼저 세 질문을 분리해야 한다. 누구에게 열려 있는가, 조직이 자기 브랜드에 맞게 바꿀 수 있는가, 발표 자료의 품질 주장이 우리 업무에서도 성립하는가. Google DeepMind는 9월 24일 Gemini 3.8 Live에 Live Avatar를 결합했다고 발표했다. 핵심은 실시간 대화 능력에 저지연 스트리밍 영상과 음성을 붙여, 사용자를 보고 듣고 말하는 시각적 대화 경험을 제공한다는 설명이다. 아래 내용은 공식 발표를 읽고 만든 도입 판단 도구이지, 제품을 직접 시험한 리뷰가 아니다. 발표의 사용자 경험 설명을 입력·대화·출력으로 정리했다. 내부 모델 아키텍처 도식은 아니다. 출처: blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-8-live-with-live-avatar . 먼저 ‘사용 가능’과 ‘만들 수 있음’을 나누자 발표는 Gemini 3.8 Live with Live Avatar가 Gemini Enterprise에서 제공된다고 적는다. 하지만 조직의 실제 계약, 관리자 설정, 계정별 활성화 여부까지 이 문장 하나로 확인되는 것은 아니다. 더구나 조직이 참조 이미지로 브랜드 맞춤 아바타를 생성하는 기능은 현재 기업 허용목록(allowlisting)을 통해서만 이용 가능하다고 명시했다. 기본 제공 아바타를 쓸 수 있다는 설명과 우리 브랜드의 얼굴을 새로 만들 수 있다는 권한은 별개다. 따라서 구매 담당자는 데모 화면보다 먼저 테넌트에서 기능이 활성화됐는지, 맞춤 생성이 필요한 경우 누가 허용목록 신청을 승인하는지 확인해야 한다. 고객 응대나 안내 영상 같은 구체적인 사용처가 있다면, 정해진 캐릭터 라이브러리만으로 요구를 충족할 수 있는지도 함께 따져보자. 기능의 존재와 우리 조직의 접근 권한을 혼동하면, PoC 일정과 제안서가 허용되지 않은 기능을 전제로 설계될 수 있다. ...

1M 토큰 컨텍스트는 모델 카드에서 보면 멋진 상한처럼 보입니다. 하지만 실제 서비스에서 중요한 질문은 “이 요청을 넣을 수 있는가”가 아니라 “그 상태를 얼마나 오래 메모리에 보관하고, 다음 요청이 다시 쓸 때 어떤 비용을 낼 것인가”입니다. Together AI의 「Serving DeepSeek-V4: why million-token context is an inference systems problem」은 DeepSeek-V4를 바로 그런 서빙 시스템의 문제로 설명합니다. 이 글의 원문은 DeepSeek-V4의 1M 컨텍스트가 Compressed Sparse Attention(CSA), Heavily Compressed Attention(HCA), Sliding Window Attention(SWA)을 섞는 하이브리드 구조에서 나온다고 설명합니다. 따라서 V4의 장점은 “긴 입력을 받는다”에서 끝나지 않습니다. 추론 엔진이 서로 다른 KV 상태를 저장하고, 배치하고, 회수하고, prefix 재사용 때 복원하는 방법까지 맞아야 실현됩니다. 아래 내용은 Together의 NVIDIA HGX B200 초기 bring-up 설명을 기준으로 한 분석이며, 제가 V4를 독립 실행해 재현한 결과는 아닙니다. 1M 토큰보다 먼저 바뀐 것은 KV 캐시의 단위다 autoregressive 디코딩은 앞서 읽은 컨텍스트를 KV 캐시에 남겨 두고 새 토큰을 생성할 때 그 상태를 다시 읽습니다. 원문이 제시한 단순화된 관계는 KV cache ∝ layers × tokens × kv_heads × head_dim × bytes 입니다. 긴 컨텍스트에서는 토큰 수가 늘어나는 것만 문제가 아닙니다. 각 요청이 더 많은 메모리를 점유해 동시성을 제한하고, 매 디코드 단계에서 읽어야 할 상태가 커져 메모리 대역폭과 처리량에도 부담을 줍니다. 이전 최적화가 줄인 항은 서로 달랐습니다. GQA는 KV head 수를, MLA는 head 차원의 표현을 줄이고, FP8·MXFP4·NVFP4...

대형 언어 모델을 여러 곳에서 호출하는 팀은 모델 선택보다 청구서 해석에서 먼저 막히곤 합니다. 같은 요청을 더 싼 모델로 보내면 절약될 것 같지만, 답이 업무에 쓸 수 있을 만큼 정확한지도 확인해야 합니다. 가장 싼 응답이 틀려 재시도하거나 사람이 고친다면 처음의 단가 비교는 의미가 없어집니다. 그렇다고 품질이 높은 모델만 고정하면 과금 단가와 실제 생성 비용의 차이를 놓칠 수 있습니다. 2026년 9월 23일 arXiv에 제출된 「Learning the Cost of Reliable Inference」는 이 문제를 ‘품질 기준을 만족하는 제공자들 사이의 조달’로 모델링합니다. 제안은 순차적 조달 플랫폼과 역 2등 가격 경매를 결합해, 추정 품질 기준을 통과한 후보 중 경쟁을 이용해 요청을 라우팅하는 방식입니다. 핵심은 무조건 최저가 모델을 찾는 일이 아닙니다. 먼저 품질 자격을 정하고, 그 자격 안에서 경쟁이 충분한지 따져야 합니다. 가격표와 실제 비용 사이 API 가격표는 고객이 지불하는 요금이고, 제공자가 요청을 처리하는 생성 비용은 별개의 값입니다. 논문의 기본 분석은 제공자가 현재의 생성 비용 추정치를 입찰하는 전략을 가정합니다. 실험에서 공개 가격을 1.25로 나눠 생성 비용을 추정한 설정은 이 입찰 전략과 별개입니다. 따라서 경매가 잘 작동하면 구매자는 경쟁 후보의 가격 신호를 활용할 수 있습니다. 그러나 그 결과는 입찰 전략, 품질 추정, 후보 수에 달려 있습니다. ‘경매를 쓰면 언제나 싸다’는 결론은 논문에서 나오지 않습니다. 연구진은 GSM8K와 GPQA 질문으로 실험을 구성했습니다. 각 실험은 질문 70,000개를 표집하고 30회의 독립 실행을 수행했으며, 원 데이터셋 규모는 각각 1,319개와 546개 문제였습니다. 표본 질문 수와 고유 문제 수는 다릅니다. 이 실험 설정에서 최종 패스의 라우팅은 최적 제공자에 최소 96% 집중됐다고 보고합니다. 이는 해당 시뮬레이션 조건의 결과이지, 임의의 실서비스 트래픽에 대한 보장은 아닙니다...

코딩 에이전트가 긴 작업을 이어갈 때 대화 이력을 요약하면 입력은 짧아진다. 문제는 그 요약을 다음 요약의 재료로 쓰면서, 원래 무엇을 확인했고 무엇을 추정했는지 경계까지 흐려질 수 있다는 점이다. 그렇다고 모든 이력을 계속 보내면 이미 읽은 도구 출력에도 반복해서 비용을 지불한다. 2026년 9월 22일 공개된 프리프린트 CliffCompaction 은 다른 선택을 한다. 자연어로 다시 설명하는 대신 원문 일부를 남기고 나머지를 버린다. 다음 압축에서는 이전 압축본도 버린다. 핵심은 더 좋은 요약문을 만드는 것이 아니라, 잊어도 복구할 수 있는 정보와 반드시 별도로 보존해야 할 상태를 가르는 것 이다. 이 글은 논문과 공개 코드의 검토이며, 모델 실행이나 비용 절감의 독립 재현 결과가 아니다. 아래 적용 판단표는 논문 메커니즘에서 도출한 편집자의 운영 제안이다. 1. 압축본을 고치는 대신 다음 창으로 넘어간다 논문 §2의 절차는 세 단계다. 문맥이 임계값까지 자라도록 두고, 넘으면 도구 호출·출력처럼 긴 부분을 축소한다. 그 뒤에는 원래 기록을 매번 고치지 않고 새 대화를 붙인다. 다음 압축 시점에는 이전 압축본을 재압축하지 않고 버린 뒤, 그 이후에 쌓인 대화 구간으로 새 압축본을 만든다. 처음의 시스템·작업 지시와 최근 대화 보존 규칙은 별도로 적용된다. 따라서 “항상 전체 원본에서 새 요약을 만든다”는 설명도 정확하지 않다. 과거 모든 대화를 매번 재검토하는 장기 기억 장치가 아니다. 저자들은 남긴 정보의 충실도를 택하는 대신, 먼 과거를 대화 안에서 회상하는 능력을 희생하는 설계라고 설명한다. 이전 압축본을 재요약하지 않는다. 시스템·작업 지시와 최근 대화 보존 규칙은 별도로 적용된다. 출처: arxiv.org/html/2609.26779v1 . 논문 §2.2에서는 500자를 넘는 도구 결과를 버리고 짧은 결과를 유지한다. 도구 호출은 이름·경로·핵심 인수 같은 짧은 흔적으로 남기고, 긴 파일 내용은 작업공간에서 필요할 때 다시 읽는 ...

작업 트리를 따로 만들었으니 에이전트도 격리됐다고 생각하기 쉽다. 하지만 다른 디렉터리에서 명령을 실행한다는 사실은 그 명령이 홈 폴더, 사내 개발 서버, Git 인증 정보에 접근하지 못한다는 뜻이 아니다. 파일 배치의 분리와 실행 권한의 제한은 별개의 일 이다. GitHub는 2026년 9월 23일 Copilot 앱의 로컬 샌드박싱을 공개 프리뷰로 발표했다. 프로젝트별로 파일·네트워크·인증 정보 정책을 요청하고, 운영체제가 요청한 정책을 강제할 수 없으면 샌드박스 없이 계속 실행하는 대신 셸을 오류로 중단하는 기능이다. 다만 스위치를 켰다고 모든 접근이 차단되는 것은 아니다. 기본 허용 범위, 실행 중인 세션의 상태, 예외 실행을 함께 읽어야 한다. 1. 작업 트리와 샌드박스는 다른 질문에 답한다 작업 트리는 동시 작업의 브랜치와 파일을 분리한다. 반면 로컬 샌드박스는 에이전트가 호출하는 도구를 운영체제의 제한된 실행 환경 안에 넣는다. 공식 문서도 작업 트리만으로는 명령이 컴퓨터의 다른 위치에 접근하는 것을 막지 못한다고 설명한다. 이번 기능은 Copilot 앱의 로컬 저장소·작업 트리 세션 에 적용된다. 클라우드 샌드박스 세션이나 원격 호스트에서 실행되는 세션에는 적용되지 않으며, Copilot CLI의 샌드박스 설정과도 별개다. 같은 Copilot이라는 이름 때문에 앱에서 바꾼 정책이 CLI까지 전파된다고 생각하면 안 된다. 작업 트리 자체는 다른 위치의 접근을 제한하지 않는다. 앱의 로컬 세션과 CLI 설정을 구분한다. 출처: docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing . 이 구분은 Codex worktree의 공유 상태를 살펴본 글 과 연결된다. 그 글은 체크아웃을 나눠도 남는 Git 상태의 공유를 다뤘다. 여기서는 Copilot 앱에서 명령의 파일·통신·인증 접근을 어떻게 제한할지를 다룬다. 2. 켜짐과 최소 권한은 같지 않다 로컬...

LLM 서버에서 긴 요청을 동시에 처리하다 보면 모델 가중치보다 생성 중 쌓이는 KV 캐시가 먼저 병목이 될 수 있다. 토큰 일부를 제거하는 정책을 적용해도 GPU의 가용 블록 수가 늘지 않는다면 어디를 봐야 할까? vToken 논문은 토큰이 논리적으로 사라지는 일과 그 토큰이 차지했던 물리 블록을 다른 요청에 재할당하는 일 을 분리한다. 이 글은 논문 v1의 설계와 수치를 실제 적용 판단에 쓰기 위한 해설이며, 저자의 시스템을 독립 재현한 성능 보고가 아니다. 토큰은 지웠는데 블록은 왜 남아 있나 PagedAttention 계열은 KV 캐시를 고정 크기 블록으로 관리한다. 토큰 제거 정책이 블록 가운데 몇 토큰만 지우면, 살아 있는 토큰 하나 때문에 블록 전체가 여전히 할당 상태다. 따라서 논리적으로 사용하지 않는 슬롯이 생겨도 다른 요청에 쓸 수 있는 블록으로 곧장 돌아오지 않는다. 논문은 동일한 토큰 제거 결정을 적용하면서 물리 회수 백엔드만 끈 Naive-Evict 를 비교 대상으로 삼는다. 기본 vLLM은 토큰 제거 자체를 하지 않는 별도 기준이므로, 이 세 가지를 섞어 비교하면 효과의 원인을 잘못 읽게 된다. 그림 1. 논리적 제거와 물리 블록 반환의 차이. 토큰 분포는 설명용이며 실제 실험 데이터가 아니다. 출처: arxiv.org/pdf/2608.13263 . 논리 주소와 물리 주소 사이에 무엇을 두었나 vToken은 요청별 토큰 테이블에 논리 토큰 ID, 현재 블록·오프셋, 생존 상태를 기록한다. 제거 정책은 evict_token 으로 더 이상 필요하지 않은 토큰을 표시한다. 이때 즉시 GPU 메모리를 반환했다고 가정하면 안 된다. 회수 관리자는 살아 있는 토큰을 다른 블록에 모을 이득과 임시 목적지 공간을 먼저 계산하고, 비동기 복사 완료 후 위치 매핑을 바꾸며 빈 블록을 반환한다. 다음 attention이 옮겨진 데이터를 읽기 전에 CUDA 이벤트로 의존성을 맺는다. 저자 구현은 vLLM v0.18.0, PyTorch v2.10....

JavaScript에서 .p12 나 .pfx 인증서 묶음을 열어 개인 키와 인증서를 따로 써야 하면, 지금까지는 openssl pkcs12 프로세스를 실행하거나 별도 패키지를 검토하는 일이 흔했다. Node.js 26.10.0은 node:crypto 에 parsePKCS12() 를 추가해 이 구조를 JavaScript의 키·인증서 객체로 돌려준다. 다만 모든 TLS 설정을 바꾸는 기능은 아니다. 필요한 것이 TLS 연결뿐인지, 파싱한 키를 다른 코드로 넘겨야 하는지부터 구분해야 한다. 이 글의 실용 산출물은 적용 판단표와 반환값 점검 순서다. Node.js 공식 릴리스 노트는 해당 API 추가를 26.10.0의 변경으로 기록한다. 공식 문서의 “Added in”도 v26.10.0으로 표시한다. 이는 이 기능이 모든 배포 환경에서 사용 가능하다는 뜻이 아니다. 애플리케이션이 실제 실행되는 Node 버전과 배포 이미지의 버전을 먼저 확인해야 한다. 그림 1. TLS 연결 설정과 JavaScript 객체 접근은 다른 요구다. 키·인증서 신뢰 검증은 파싱과 별도로 수행한다. 출처: nodejs.org/api/crypto.html#cryptoparsepkcs12buffer-passphrase . 먼저 고를 것: TLS 연결인가, 자바스크립트 객체인가 tls.connect() 나 HTTPS 서버 설정에서 PFX를 pfx 옵션으로 넘기면 되는 경우라면 기존 TLS 경로가 계속 맞을 수 있다. 새 API는 TLS 경로를 대체하라고 소개된 것이 아니라, PKCS#12 내부의 키와 인증서가 JavaScript 코드에 필요할 때 쓸 수 있도록 여는 함수다. Node 소스 변경 설명에 따르면 TLS가 쓰던 SecureContext::LoadPKCS12 도 같은 파싱 로직을 사용하지만, 이전에는 결과가 SSL 컨텍스트 안에서 소비되어 JavaScript에 나오지 않았다. 필요한 일 먼저 검토할 경로 확인할 점 PFX를 TLS 연결에 제공 기존 tl...

긴 대화를 그대로 보냈는데도 캐시 적중률이 떨어진다면, 먼저 모델 가격표가 아니라 요청의 앞부분을 비교해야 한다. 도구 이름은 같아도 스키마나 배열 순서가 달라졌을 수 있고, 지시문을 수정하면서 재사용 가능한 접두부를 끊었을 수도 있다. OpenAI는 2026년 9월 22일 「Better prompt caching for GPT-6」에서 캐시 진단과 명시적 경계, 도구·지시문 변경 시 재사용을 보존하는 방법을 공개했다. 이 글의 실전 산출물은 변경 유형별 캐시 진단표 다. 원문의 권장사항을 요청 변경→확인할 증거→수정 후보→재검증 순서로 정리했다. API 성능을 직접 측정한 보고서가 아니라 공식 발표에 근거한 편집자 분석이다. 1. 30분과 최대 90%는 무엇의 조건인가 공식 발표는 GPT-6 계열에서 30분 창 안에 재사용되는 적격 공유 접두부 에 캐시 할인을 제공한다고 설명한다. 또 캐시된 입력 토큰에 대해 최대 90% 할인 을 언급한다. 모든 요청이 30분 동안 반드시 적중한다는 보장도, 전체 청구액이 90% 줄어든다는 뜻도 아니다. 할인 대상은 캐시된 입력이며 출력 토큰과 캐시되지 않은 입력까지 같은 비율로 줄어드는 것은 아니다. 실무에서는 세 항목을 따로 보자. 재사용 가능한 앞부분이 있는지, 실제 요청에서 캐시된 입력 비중이 얼마인지, 최종 비용과 응답 지연이 어떻게 변했는지다. 캐시 적중률만 높아도 불필요하게 긴 문맥을 계속 보내면 전체 비용 최적화와는 어긋날 수 있다. 그림 1. 할인 범위와 청구액은 다르다. 전체 비용 90% 절감을 보장하는 수치가 아니다. 출처: openai.com/index/better-prompt-caching-for-gpt-6 . 2. tools_changed를 보면 도구 삭제부터 멈춘다 새 대시보드는 캐시·비캐시 입력 구성을 보여 주며, 진단 도구는 최근 응답과 요청을 비교해 모델·도구·설정·입력의 변경을 찾도록 돕는다. 발표의 예시는 reason: tools_changed 와 함께 comparison_r...

모델 선택을 이야기할 때 보통 품질과 가격표를 먼저 본다. 그런데 실제 서비스 트래픽을 모아 보면 다른 장면이 나온다. Vercel이 공개한 AI Gateway Production Index의 2026년 7월 보고서는 6월 데이터를 기준으로 오픈웨이트 모델이 게이트웨이 토큰의 29%를 처리했지만 지출 비중은 4% 미만이었다고 말한다. 이 숫자는 "오픈웨이트가 더 싸고 무조건 낫다"는 결론이 아니다. 토큰 사용량과 지출은 서로 다른 축이고, Vercel의 집계는 작업 품질이나 고객별 비용을 보여주지 않는다. 그래도 어떤 일을 어떤 모델에 맡길지 다시 나눠 볼 근거는 된다. 그림 1. 토큰량과 지출은 서로 다른 축이다. Vercel의 6월 집계를 같은 비율로 읽으면 안 된다. 출처: vercel.com/blog/ai-gateway-production-index-july-2026 . 토큰은 늘었지만 평균 가격은 거의 움직이지 않았다 Vercel에 따르면 AI Gateway의 토큰 사용량은 전월보다 29%, 지출은 27% 늘었다. 두 증가율이 비슷했기 때문에 6월의 토큰당 평균 가격은 거의 평평했다. 5월에는 지출이 사용량보다 두 배 넘게 빠르게 늘면서 토큰당 비용이 약 20% 올랐지만, 6월에는 그 현상이 이어지지 않았다. 이 수치는 모델 가격표의 단순 비교가 아니다. 실제 게이트웨이에서 어떤 모델이 어떤 비중으로 호출됐는지에 대한 집계다. 프롬프트 길이, 캐시, 출력 토큰, 할인 조건이 다른 서비스의 청구서를 그대로 설명해 주지는 않는다. 오픈웨이트의 사용량과 지출 사이에 큰 간격이 있었다 보고서에서 오픈웨이트 모델은 4월 토큰량의 11%에서 6월 29%로 올라갔다. 지출에서는 4% 미만이었다. Vercel은 이 흐름의 큰 부분을 DeepSeek의 성장으로 설명한다. DeepSeek는 6월 토큰량의 22.6%를 차지해 Google의 24%에 근접했고, Anthropic이 가장 큰 비중을 유지했다. 그림 2. Vercel은 Deep...

Pull request가 많은 저장소에서는 목록 화면 자체가 작은 운영 도구입니다. 누가 리뷰해야 하는지, 어떤 PR이 막혀 있는지, 이번 주에 끝내야 할 변경이 무엇인지 한 화면에서 골라내야 합니다. GitHub는 2026년 9월 21일(한국 시간 22일) 저장소의 새 Pull requests 페이지를 모든 사용자에게 제공하기 시작했습니다. 변경 안내에 따르면 새 화면에는 필터 입력 보조, 고급 검색의 AND · OR , 접을 수 있는 사이드바, compact 표시, 상태 검사 수와 unread 업데이트 같은 맥락 정보가 들어갑니다. 기능 목록만 보면 UI 개편입니다. 실제로는 리뷰 큐를 만드는 방법이 바뀐 셈입니다. 검색창에 무엇이든 길게 넣기보다, 먼저 리뷰 목적을 정하고 그 목적에 맞는 필터를 조합하는 편이 덜 흔들립니다. 그림 1. PR 목록을 리뷰 목적, 검색 조건, 목록 신호, 상세 검토의 순서로 다루는 실무 흐름. 출처: github.blog/changelog/2026-09-21-refreshed-repository-pull-requests-page-generally-available . 새 화면에서 달라진 것 GitHub의 공식 변경 안내는 새 저장소 PR 페이지의 초점을 “찾고 행동하기 쉽게 만드는 것”으로 설명합니다. 필터 입력 보조는 올바른 qualifier를 찾는 데 도움을 주고, 고급 검색은 AND 와 OR , 중첩 검색을 지원합니다. 사이드바는 Authored by me , Involves me 같은 자주 쓰는 범주를 빠르게 여닫게 합니다. 목록을 좁히는 기능만 늘어난 것은 아닙니다. compact presentation mode는 한 화면에 더 많은 PR을 보여 주고, status check count·stack indicator·unread update 같은 정보는 목록을 열기 전에 우선순위를 판단할 단서를 줍니다. 여러 PR을 골라 닫거나 라벨과 milestone을 바꾸는 bulk action도 공식 안내에 포함돼 ...

코딩 에이전트의 비용을 줄이려면 쉬운 작업을 싼 모델에 맡기면 된다고 생각하기 쉽습니다. 그런데 긴 대화와 파일 기록을 넘기고, 결과를 다시 큰 모델이 읽어야 한다면 모델 단가 차이보다 문맥 재처리 비용이 더 커질 수 있습니다. 이번에 검토한 Jev Engineering for Coding Agents 는 논문이 아니라 2026년 9월에 독립 편집된 작업 노트입니다. TypeSafe 창업자의 설계 메모를 바탕으로 했지만 TypeSafe가 발행하거나 보증한 문서는 아닙니다. 그래서 이 글은 노트의 아키텍처를 사실처럼 받아들이지 않고, 공개된 식을 다시 계산하고 공식 TypeSafe 문서와 FastContext 논문으로 범위를 대조합니다. 모델이 아니라 문맥을 어디서 다시 읽는가 작업 노트가 던지는 질문은 단순합니다. KV 캐시가 없다면 코딩 에이전트를 어떻게 설계할 것인가. 지금의 에이전트는 대화를 뒤에 계속 붙입니다. 앞부분의 캐시를 재사용하면 싸지만, 중간을 바꾸거나 다른 모델로 넘기면 긴 문맥을 다시 처리해야 합니다. 노트의 대안은 상태와 문맥을 분리하는 것입니다. 도구 호출, 파일, 테스트 로그, 계획을 주소 가능한 chunk로 저장하고, 매 턴 현재 질문에 필요한 길이만 골라 모델 앞에 놓습니다. TypeSafe 공식 문서는 Jev를 코드를 쓰는 생성 모델이 아니라, typed question과 state를 받아 choice·score·noul 같은 구조화된 결과와 확률을 반환하는 System One 모델로 설명합니다. 즉, 아래 구조는 현재 제품의 완성 기능 목록이 아니라 이 primitive를 코딩 에이전트 하네스에 적용한 설계 제안입니다. 그림 1. 작업 노트의 제안은 transcript 누적 대신 질문마다 문맥을 조립하고 Jev가 구조화된 제어 결정을 내리게 한다. 현재 제품 기능이 아니라 제안 구조다. 출처: drive.google.com/file/d/17h982xvsL3E7b80iGmOCfKp9qTOW9ohv/view . 라우팅 ...