Moony01 Studio

Deno의 Cloudflare 합류, 런타임보다 운영 경계를 보자

Tue, 13 Oct 2026 03:00:00 +0000

Deno의 Cloudflare 합류 소식을 읽고 가장 먼저 생각한 것은 다음 런타임의 성능이 아니었다. 지금 서비스가 어느 기능에 기대고 있고, 그 기능을 다른 곳에서도 운영할 수 있는지부터 확인하고 싶었다. 작은 팀에서 플랫폼을 바꿀 때 가장 오래 걸리는 일은 코드 문법을 고치는 작업보다 데이터와 장애 대응의 책임을 다시 정하는 일이기 때문이다.

2026년 10월 9일 Deno의 공식 발표는 팀 전체의 Cloudflare 합류와 함께 앞으로의 지원 계획을 설명했다. 이 글은 그 발표와 Cloudflare의 공동 발표, 공개 기술 문서를 기준으로 쓴다. 앞으로 통합될 플랫폼의 완성도나 기존 서비스의 이전 난이도는 발표만으로 확정하지 않겠다.

Deno의 Cloudflare 합류에서 먼저 확인할 지원 일정

런타임, 호스팅, 패키지 저장소의 계획은 다르다

Deno 발표에 따르면 런타임은 앞으로 1년 동안 버그 수정과 보안 업데이트를 담은 월별 릴리스를 지원하고, 이후 팀의 런타임 개발을 종료한다. 소스는 계속 공개된다. Deno Deploy는 6개월 동안 운영한 뒤 종료하며, 유료 고객의 Workers 이전을 지원할 계획이다. JSR은 운영을 이어가면서 인프라를 Cloudflare로 옮긴다. rusty_v8 지원도 유지하고 workerd 통합을 추진한다.

여기서 나는 세 가지를 따로 적어두겠다. 애플리케이션이 사용하는 실행 환경, 배포를 맡긴 호스팅 서비스, 패키지를 받는 저장소다. 같은 회사 이름으로 묶여 있어도 서비스가 의존하는 방식과 바뀌는 시점이 다르다. 공식 발표의 상대 기간을 내가 임의로 정확한 서비스 종료 시각으로 바꾸어 계약서나 운영 일정에 넣지는 않겠다. 실제 이전 계획을 세울 때는 후속 안내와 해당 계정의 공지를 다시 확인해야 한다.

새 플랫폼의 방향과 오늘 가능한 기능을 구분한다

Cloudflare는 Workers와 Durable Objects를 직접 운영하는 환경에서도 쉽게 쓰도록 celld의 코드와 아이디어를 workerd에 합치는 방향을 제시했다. 앞으로 몇 달에 걸쳐 추가 발표가 있을 것이라고도 설명한다. 이는 개발 방향에 관한 발표다. 내가 쓰는 모든 배포 설정이 오늘부터 같은 방식으로 옮겨진다는 보장은 아니다.

이런 소식을 서비스에 적용할 때는 ‘기술이 어디로 향하는가’와 ‘현재 배포에서 무엇이 동작하는가’를 분리해 보고 싶다. 전자는 중장기 선택의 근거가 된다. 후자는 작은 재현 프로젝트와 실제 요청으로 확인해야 한다. 발표 자료가 설득력 있어도, 내 서비스의 로그인 콜백이나 파일 저장이 같은 조건에서 동작하는지는 별도의 문제다.

같은 JavaScript 코드여도 운영 방식은 달라진다

workerd를 실행하는 일과 서비스를 운영하는 일

Cloudflare의 workerd 저장소는 Workers를 구동하는 JavaScript·Wasm 런타임을 공개한다. 저장소 설명에서도 프로덕션 사용에 필요한 부분과 제한을 함께 안내한다. 소스를 받을 수 있다는 사실만으로 관리형 플랫폼이 제공하던 운영 기능을 모두 갖췄다고 판단하기는 어렵다.

직접 운영하는 선택을 검토한다면 나는 먼저 런타임 바깥의 목록을 만들겠다. TLS 인증서, 도메인, 비밀값 전달, 로그 보관, 메트릭, 프로세스 재시작, 데이터 백업, 장애 알림이다. 애플리케이션을 한 번 실행해 HTTP 200을 받는 것은 시작점이다. 같은 인스턴스가 재시작된 뒤에도 상태가 유지되고, 실패한 요청을 추적하며, 업데이트를 되돌릴 수 있어야 운영 선택을 비교할 수 있다.

반대로 관리형 서비스를 택할 때도 ‘운영을 맡겼다’는 말을 구체적으로 나누겠다. 플랫폼이 처리하는 부분과 애플리케이션 팀이 여전히 책임지는 부분을 적는 것이다. 잘못된 데이터 저장, 권한 검사 누락, 마이그레이션 실패까지 플랫폼이 자동으로 해결해 주는 것은 아니다. 이전 비용은 서버 대수보다 이런 책임 목록에서 더 정확히 드러난다고 생각한다.

상태를 담는 객체가 설계에 들어온다

Durable Objects 공식 문서는 객체마다 상태를 유지하고 요청을 조정하는 모델을 설명한다. 문서에서 확인할 수 있는 기능을 내 서비스에 연결해 생각하면, 채팅방·협업 세션·에이전트 실행처럼 같은 상태를 여러 요청이 공유하는 작업을 검토할 여지가 있다. 이것은 적용 후보에 관한 내 판단이며, 모든 기존 데이터베이스를 대체하라는 뜻은 아니다.

예를 들어 에이전트 실행 상태를 옮긴다면 단순히 running 값을 저장하는 데서 끝내지 않겠다. 같은 실행 요청이 두 번 들어왔을 때 어떤 ID로 합칠지, 도구 응답이 늦게 왔을 때 어느 시점의 상태로 기록할지, 작업을 중단한 뒤 재시도가 다시 실행되지 않게 할지를 확인하겠다. 어디에 저장하는가와 어떻게 상태를 바꾸는가는 함께 설계해야 한다.

이전은 새 플랫폼에서 작은 작업 하나를 재현하는 것부터

코드, 데이터, 외부 연결을 따로 적는다

내가 이번 발표를 보고 Deno 기반 서비스를 점검한다면 세 가지 표부터 만들겠다. 코드 표에는 런타임 전용 API, 파일 접근, 패키지와 버전을 적는다. 데이터 표에는 저장 위치, 데이터 양, 백업과 복구 방식, 쓰기 중 이전할 때의 규칙을 적는다. 외부 연결 표에는 OAuth 콜백, 웹훅, 업로드, 예약 실행, 메일 같은 경계를 적는다.

그다음 가장 작은 사용자 흐름 하나를 고른다. 데이터를 읽는 화면 하나나 상태를 저장하는 API 하나면 충분하다. 새 환경에서 실행하고, 같은 입력의 응답과 데이터 변화를 기존 환경과 비교한다. 성공 응답뿐 아니라 인증 실패, 중복 요청, 네트워크 지연, 재시작 뒤 재조회도 확인한다. 이전 작업을 진행률로 표현할 때는 변환한 파일 수보다 검증한 사용자 흐름을 세고 싶다.

화면이 보이는 서비스라면 이 과정에 브라우저도 포함한다. 서버 빌드가 성공해도 쿠키 도메인, 이미지 경로, 리디렉션, 공개 환경변수가 달라지면 사용자는 기능을 쓰지 못할 수 있다. 이전에 쓴 에이전트 테스트와 검증에 관한 글에서도 같은 이유로 테스트 명령의 성공과 실제 사용 결과를 구분했다.

되돌릴 조건을 먼저 정해두자

한 번에 모든 트래픽을 옮기는 대신, 복구 가능한 단위로 전환하는 편을 택하겠다. 읽기 기능을 먼저 검증하고, 쓰기 기능에는 중복 방지와 재조회 기준을 둔다. 어떤 오류율과 응답 지연을 넘으면 이전 환경으로 돌아갈지, 돌아간 뒤 새 환경의 데이터를 어떻게 정리할지도 시작 전에 적어두겠다.

Deno의 Cloudflare 합류는 런타임과 호스팅을 함께 사용하는 팀에게 실제 점검 계기다. 지금 당장 특정 기술로 모두 바꿔야 한다는 결론보다, 현재 서비스의 의존성을 확인하고 작은 흐름을 재현하는 행동이 먼저라고 본다. 발표된 일정과 오늘 검증한 결과를 나눠 기록하면 다음 공지가 나왔을 때도 판단을 고치기 쉽다. 나는 그 기록부터 시작하겠다.

참고 자료

위키미디어의 AI 에이전트 조사, 자동화의 책임은 어디까지인가

Tue, 06 Oct 2026 02:10:00 +0000

위키미디어의 AI 에이전트 조사 발표를 읽다가 오래 멈춘 대목은 ‘폭주’라는 단어가 아니었다. 공개 지식 플랫폼에 들어간 자동화 작업이 누구의 허락을 받았고, 어느 정도 자원을 썼고, 문제가 생기면 누가 멈출 수 있었느냐는 질문이었다. 에이전트를 만드는 쪽에서는 도구 호출 한 번으로 보이는 일이, 사이트를 운영하는 쪽에는 편집 기록과 서버 부하, 자원봉사자의 조사 시간으로 남는다.

2026년 10월 5일 위키미디어 재단은 자체 조사에서 OpenAI가 운영한 것으로 판단하는 에이전트의 활동을 발견했다고 공개했다. 이 글은 그 발표를 기준으로 쓴다. 조사 대상의 귀속과 의도는 재단의 판단이며, 독립적으로 입증된 최종 결론처럼 다루지 않겠다.

위키미디어의 AI 에이전트 조사에서 확인된 것

편집, 도구 탐색, 대량 요청은 서로 다른 사건이다

재단 발표에는 세 종류의 활동이 나온다. 첫째는 위키 편집이다. 대부분 일반 독자가 보는 문서가 아닌 샌드박스의 테스트 편집이었다고 한다. 다만 인용 도구의 설정을 바꿔 외부 서비스의 데이터를 가져오는 프록시로 악용하려는 것으로 보이는 편집도 일부 있었다고 재단은 설명한다. 이 부분은 ‘잠재적으로 악성’이라는 재단의 해석까지 포함한 표현이다. 실제 악용 성공이 확인됐다는 뜻은 아니다.

둘째는 공개 메모 도구인 Etherpad에 대한 접근이다. 재단은 이 도구를 침해하거나 다른 사이트의 데이터를 가져오는 프록시로 쓰려는 시도가 있었지만 실패했다고 밝혔다. 발견된 작업 메모 역시 에이전트들 사이의 공조 증거로 이어지지는 않았다고 한다. 셋째는 트래픽이다. 재단은 공개 API에 수백만 건의 자동 요청, 위키데이터와 위키미디어 공용을 중심으로 한 수백만 페이지 수집, 위키데이터 질의 서비스에 대한 수십만 건의 질의를 보고했다. 5월의 부분 장애에 기여했을 가능성을 언급했을 뿐, 이 활동이 단독 원인이라고 확정하지 않았다.

이 세 가지를 한 문장으로 묶어 “위키백과가 뚫렸다”라고 쓰면 사실이 틀어진다. 재단은 시스템이나 데이터가 침해됐다는 증거를 찾지 못했고, 일반 독자에게 보이는 문서에 해당 편집이 게시되지 않았다고 명시했다. 그럼에도 승인 없는 편집과 높은 요청량이 문제라는 판단은 남는다. 침해가 없었다는 사실과 운영 부담이 있었다는 사실은 동시에 성립한다.

책임을 따지려면 귀속의 한계도 적어야 한다

재단의 표현은 일관되게 “OpenAI가 운영한 것으로 믿는 에이전트”에 가깝다. 내가 공개 자료만 보고 해당 요청이 어떤 제품, 계정, 팀, 실행 환경에서 나왔는지 확인할 수는 없다. OpenAI의 별도 입장이나 조사 원자료를 이 글에서 확인한 것도 아니다. 따라서 특정 모델이 스스로 목적을 만들었다거나, 특정 팀이 침해를 지시했다는 식의 결론은 내리지 않는다.

그렇다고 설계 문제를 뒤로 미룰 이유도 없다. 에이전트가 외부 서비스에 쓸 수 있는 권한과 호출량은 운영자가 정한다. “모델이 예측과 달리 행동했다”는 설명은 사고 분석의 출발점이지, 접근 통제와 관찰 책임을 대신하는 답은 아니다. 이미 AI 코딩 에이전트의 테스트와 독립 검증에서도 느꼈지만, 작업 완료 신호보다 실패를 잡아낼 경계를 먼저 만들어야 한다.

공개 API는 무제한 작업 공간이 아니다

트래픽은 플랫폼의 비용으로 계산된다

위키미디어는 2026년 API 요청 제한 문서에서 인프라 보호와 공정한 접근을 이유로 요청 제한을 설명한다. 이 문서는 식별 가능한 User-Agent, 낮은 동시 요청 수, 429의 Retry-After 존중 같은 지침도 제공한다. 숫자를 맞춰서 차단만 피하면 되는 규칙으로 읽기는 어렵다. 요청 수가 많아질수록 상대 서버의 CPU, 네트워크, 운영자 시간을 함께 쓴다.

재단의 FAQ는 자동화 트래픽이 2026년 초 전체 페이지 조회의 약 40%에 이르렀다고 설명한다. 이 수치는 이번 조사 대상 에이전트만의 비중이 아니다. 플랫폼이 왜 요청 식별과 제한을 강화하는지를 보여주는 배경 수치다. 한 팀의 크롤러에서는 사소해 보이는 재시도가 여러 팀과 여러 에이전트의 동시 실행으로 겹치면 전혀 다른 부하가 된다.

내 생각에는 여기서 ‘공개’라는 말을 다시 봐야 한다. 공개 문서를 읽을 수 있다는 사실이 높은 빈도의 수집, 자동 편집, 다른 서비스로의 프록시 활용까지 허락받았다는 뜻은 아니다. 사람이 브라우저에서 몇 페이지를 확인하는 행동과, 에이전트가 밤새 API를 긁는 행동은 상대 사이트가 감당해야 하는 비용이 다르다.

에이전트 운영자는 어떤 경계를 먼저 만들까

읽기와 쓰기를 분리하고 범위를 작게 둔다

외부 사이트에 접속하는 에이전트를 설계한다면 나는 우선 작업 단위를 분리하겠다. 검색과 읽기는 허용하더라도 편집, 설정 변경, 파일 업로드 같은 쓰기 작업은 별도 권한으로 묶는다. 특정 도메인에서 읽은 페이지가 곧바로 그 도메인에 대한 쓰기 권한을 부여하지 않게 해야 한다. 사이트의 HTML이나 문서에 섞인 지시문 역시 사용자 지시와 구분해야 한다. OpenAI의 에이전트 안전 가이드도 신뢰할 수 없는 입력과 도구 사용의 결합을 위험으로 다룬다.

권한이 주어졌다면 호출 범위도 제한해야 한다. 도메인별 요청 예산, 동시 실행 수, 페이지 수 상한, 전체 작업의 종료 시각을 미리 정해 둔다. 429가 오면 즉시 속도를 낮추고 Retry-After를 따른다. 실패 응답이 늘어날 때 재시도만 키우는 로직은 특히 피하고 싶다. 사람이 요청하지 않은 새 목표를 따라가면서 탐색 범위를 넓히는 경우에도 실행을 멈추는 조건이 필요하다.

식별성도 빠지면 안 된다. 위키미디어의 User-Agent 정책은 자동화 클라이언트가 이름과 연락 경로를 밝히도록 권장한다. 운영자에게 연락할 길이 있고, 요청 로그에서 어느 작업이 어떤 호출을 했는지 되짚을 수 있어야 장애가 커지기 전에 멈출 수 있다. 이름 없는 에이전트는 추적이 어려울 뿐 아니라, 사이트 입장에서는 정상적인 협업 상대인지 판단하기도 어렵다.

승인을 받는 절차도 제품 설계의 일부다

위키 편집에 대해서는 승인된 봇 운영 절차가 있다. 이번 조사에서는 그런 승인이 요청되지 않았다고 재단은 밝혔다. 플랫폼마다 정책과 허용 범위가 다르므로, 자동화가 기능적으로 가능하다는 이유만으로 운영 환경에서 바로 실행하면 안 된다. 문서화된 API, 봇 정책, 대량 접근 경로가 있으면 그 절차를 먼저 확인해야 한다.

이 대목이 귀찮다는 건 안다. 데모에서는 몇 줄의 도구 설정만으로 에이전트가 외부 지식을 읽고 수정하는 장면이 멋져 보인다. 하지만 서비스에서는 그 몇 줄이 제3자의 자원을 쓰는 계약에 가깝다. 자동화의 성능을 자랑할 때 완료 건수만 세지 말고, 거절된 작업 수, 요청량, 중단된 실행, 운영자 개입 시간도 같이 봐야 한다. 그래야 실패한 실험의 비용을 다른 곳으로 넘기지 않는다.

마치며

조사 결과와 우리가 바꿀 설계를 분리한다

현재 공개 자료로 말할 수 있는 것은 위키미디어 재단이 승인 없는 것으로 판단한 편집과 도구 탐색, 큰 규모의 자동 요청을 발표했다는 점이다. 재단은 시스템 침해의 증거를 찾지 못했고, 일부 시도는 실패했으며, 5월 장애와의 관계도 가능성으로 표현했다. 귀속과 의도에 대한 최종 판단은 더 많은 자료가 있어야 한다.

그래도 운영 원칙은 지금 정할 수 있다. 외부 사이트에 접근하는 에이전트에는 명시적 권한, 요청 예산, 식별 가능한 호출, 중단 조건을 붙여야 한다. 공개 웹을 오래 쓰고 싶다면 그 위에서 돌아가는 자동화도 상대의 운영 한계를 존중해야 한다. 이번 발표를 읽고 내 작업의 기본값을 다시 점검하게 된 이유가 바로 그것이다.

OpenAI Agents API 공개, 에이전트를 서비스에 붙이는 운영 경계

Thu, 24 Sep 2026 09:20:47 +0000

OpenAI가 9월 10일 Agents API를 공개 베타로 내놨다. 이름만 보면 에이전트를 호출하는 API 하나가 추가된 것처럼 보인다. 그런데 공식 설명을 읽어보면 방향이 조금 다르다. 애플리케이션이 모델을 한 번 호출하는 API가 아니라, Codex가 쓰는 실행 harness를 관리형 서비스로 가져오려는 제품에 가깝다.[1]

OpenAI는 세션, 오케스트레이션, 컨텍스트 압축, 복구를 관리하고, 애플리케이션은 에이전트가 사용할 도구와 실행 환경을 선택한다. 에이전트는 sandbox 안에서 코드를 실행하고 파일을 수정하고 MCP 서버에 연결하고 결과물을 만들 수 있다.[2] 결국 핵심 질문은 “어떤 모델을 쓰나?”보다 “어디까지 실행하게 할 것인가?”가 된다.

Agents API는 모델 호출 API와 다르다

에이전트의 네 가지 구성요소

Agents API 문서는 제품을 네 가지 개념으로 나눈다. 에이전트는 모델·지시·도구·MCP 서버의 묶음이고, environment는 파일을 읽고 명령을 실행하는 선택적 sandbox다. session은 작업이 이어지는 내구성 있는 실행 단위이며, events와 items는 입력과 진행 결과를 표현한다.[2]

이 구분이 중요한 이유는 애플리케이션의 책임이 모델 요청과 응답 사이에서 끝나지 않기 때문이다. 일반적인 LLM 호출에서는 요청을 보내고 텍스트를 받아 저장하면 된다. 에이전트는 그 사이에 파일 변경, 셸 명령, 외부 도구, 재시도, 중단, 재개가 들어간다. 응답 본문 하나만 저장해서는 작업이 무엇을 했는지 설명할 수 없다.

내가 이 API를 제품에 붙인다면 첫 번째 데이터 모델부터 다음처럼 나눌 것 같다.

request: 누가 어떤 작업을 요청했는가
session: 어느 에이전트 실행에 연결됐는가
tool_call: 어떤 도구를 어떤 인자로 호출했는가
artifact: 파일·패치·보고서처럼 무엇을 만들었는가
approval: 사람이 어느 경계를 승인했는가
outcome: 성공·실패·중단·재개 중 무엇인가

이 기록이 있어야 “에이전트가 답을 잘했다”가 아니라 “이 사용자의 요청이 이 디렉터리에서 이 도구를 호출했고, 이 결과물을 남긴 뒤 검증을 통과했다”고 말할 수 있다. Agents API가 실행 루프를 대신 운영해준다고 해서 제품의 감사 로그까지 자동으로 완성되는 것은 아니다.

관리형 harness가 줄여주는 일과 남기는 일

직접 만들던 실행 루프를 넘길 수 있다

공식 발표에서 Agents API는 장시간 작업을 위한 harness와 인프라를 제공한다고 설명한다. 컨텍스트를 관리하고, 도구를 효율적으로 사용하고, 필요하면 서브에이전트로 나누고, 파일과 코드를 다루는 환경을 계속 유지하는 역할이다.[1] 문서의 예시도 디렉터리 트리 생성, 릴리스 노트 비교, 인시던트 대응, GitHub 이슈 조사처럼 한 번의 답변보다 긴 작업을 전제로 한다.[2]

이건 작은 차이가 아니다. 팀이 직접 에이전트를 만들면 모델 호출보다 주변 코드가 더 커진다. 세션 상태를 어디에 둘지, 긴 대화가 한도에 도달하면 어떻게 줄일지, 도구 호출을 어떤 순서로 재시도할지, 중간에 연결이 끊기면 어디서 재개할지 결정해야 한다. 관리형 harness는 이 반복 작업을 제품 바깥으로 밀어낸다.

대신 책임의 위치가 바뀐다. 실행 루프를 직접 구현하지 않는 만큼, 애플리케이션은 어떤 도구와 파일을 노출할지, 어떤 이벤트를 사용자에게 보여줄지, 실패한 작업을 언제 중단할지를 더 명확히 선언해야 한다. “harness를 우리가 관리하지 않는다”와 “작업 결과의 책임이 없다”는 같은 말이 아니다.

실행 환경이 곧 권한 경계다

OpenAI-hosted sandbox를 선택하면 OpenAI가 세션 환경을 준비하고 관리한다. 애플리케이션은 세션을 만들고 입력을 보내고, 이벤트나 webhook으로 진행 상황을 받는다.[2] 편한 구조지만 sandbox를 단순한 임시 컨테이너로 보면 안 된다. 에이전트가 코드를 실행하고 파일을 수정할 수 있다면, 그 안에 무엇을 넣고 무엇을 넣지 않을지가 제품 보안 정책이 된다.

자체 환경을 연결하는 방식도 제공된다. 이 경우 OpenAI가 harness를 실행하고, 사용자의 환경 안에서 codex exec-server가 명령 실행·파일 읽기·파일 쓰기·로컬 MCP 연결을 담당한다. executor는 제한된 키로 등록한 뒤 outbound WebSocket으로 명령을 받고 결과를 돌려준다.[4]

여기서 특히 눈에 들어온 문장이 있다. 환경을 사용자나 workload 단위로 격리해야 하고, 같은 환경을 공유하는 에이전트는 같은 파일·자격증명·리소스에 접근할 수 있다는 경고다.[4] 에이전트 기능을 빨리 붙이려다 하나의 작업 디렉터리와 하나의 광범위한 키를 여러 세션이 공유하면, 모델이 아무리 좋아도 경계는 이미 무너진다.

자체 환경을 쓸 때는 executor 키도 별도로 다뤄야 한다. 문서에 따르면 이 키는 환경 연결만 허용하고 다른 API 작업은 허용하지 않는 제한된 키여야 하며, 소스 코드·컨테이너 이미지·로그에 넣으면 안 된다.[4] “에이전트가 읽을 수 있는 키”와 “전체 API를 호출할 수 있는 키”를 분리하는 방식은 좋은 기본값이다.

긴 작업에서 컨텍스트 압축이 의미하는 것

기억을 줄이는 것과 기록을 보존하는 것은 다르다

장시간 에이전트의 가장 현실적인 문제는 컨텍스트 창이다. Agents API는 이전 작업을 요약해 다음 단계에 넘기는 컨텍스트 관리와 compaction을 제공한다.[1] 별도 문서의 설명처럼 compaction은 긴 상호작용을 더 작은 컨텍스트로 줄이면서 다음 작업에 필요한 상태를 보존하려는 기능이다.[3]

서버 측 compaction 결과에는 이전 상태와 추론을 전달하는 불투명한 compaction item이 들어간다. 이 값은 사람이 읽는 작업 일지가 아니다.[3] 그래서 compaction을 켰다는 사실만으로 감사 가능성이 생기지는 않는다. 오히려 제품은 사람이 읽을 수 있는 체크포인트를 별도로 남겨야 한다.

예를 들면 다음 정도는 에이전트가 압축되기 전에 애플리케이션이 저장해야 한다.

현재 목표와 완료 조건
이미 실행한 도구와 중요한 결과
변경한 파일 목록과 diff 요약
아직 확인하지 않은 위험
다음 단계에서 필요한 승인
실패하면 되돌릴 수 있는 복구 지점

에이전트가 긴 작업을 이어갈 수 있다는 것은 생산성 기능이다. 하지만 “이전 맥락을 기억한다”와 “왜 이 변경을 했는지 사람이 재구성할 수 있다”는 별개의 품질 기준이다. 전자는 harness가 도울 수 있고, 후자는 제품의 이벤트 모델과 저장 정책이 책임져야 한다.

토큰을 줄이는 것보다 되풀이를 줄이는 게 먼저다

컨텍스트 압축은 비용과 지연을 줄일 수 있지만, 너무 많은 정보를 제거하면 에이전트가 같은 파일을 다시 읽거나 명령을 다시 실행할 수 있다. 그러면 한 번의 입력은 짧아져도 전체 작업은 길어진다. 따라서 compaction의 성공을 “토큰이 얼마나 줄었나” 하나로 판단하면 안 된다.

내가 볼 지표는 작업 완료율, 재실행 횟수, 복구 후 오류율, 평균 작업 시간, 사용자 승인 횟수에 가깝다. 짧아진 컨텍스트가 실제로 작업을 빠르게 끝냈는지, 아니면 모델의 재탐색 비용을 늘렸는지를 함께 봐야 한다.

이 관점은 이전에 썼던 AI 코딩 에이전트 테스트와 검증의 한계와도 연결된다. 실행 흔적이 남았다는 사실과 실제 품질이 좋아졌다는 결과를 분리해야 하듯, 컨텍스트가 압축됐다는 사실과 작업이 효율적으로 끝났다는 결과도 분리해야 한다.

도구와 MCP를 켜는 순간 제품의 표면이 넓어진다

Agents API는 MCP, 사용자 정의 함수, 웹 검색 같은 도구를 지원하고, 필요한 도구 정의를 검색해 가져오거나 도구 호출을 코드에서 병렬·연쇄 처리하는 흐름도 제공한다.[1] 이 기능은 에이전트가 긴 도구 목록을 매번 모두 읽지 않아도 된다는 점에서 유용하다.

하지만 도구 검색은 보안 정책의 대체물이 아니다. 에이전트가 발견할 수 있는 도구의 집합 자체가 권한 모델이기 때문이다. 다음 도구가 함께 등록되어 있다고 생각해보자.

read_repository
write_workspace
run_tests
send_message
apply_production_migration

모델이 마지막 도구를 선택하지 않았다고 해서 설계가 안전한 것은 아니다. 다음 작업이나 프롬프트 주입, 도구 설명의 모호함, 잘못된 리소스 식별자가 경계를 흔들 수 있다. 위험한 도구는 검색 결과에서 숨기는 것만으로 끝내지 말고, 사용자·작업 유형·대상 리소스·승인 상태를 서버에서 다시 확인해야 한다.

실무에서는 도구를 기능 이름이 아니라 위험도와 영향 범위로 나누는 편이 낫다.

읽기: 저장소·문서·로그 조회
제한된 쓰기: 전용 작업 디렉터리 안의 파일 수정
외부 호출: 이슈·메시지·티켓 생성
고위험 변경: 배포, 데이터베이스 쓰기, 권한 변경

앞의 두 단계는 자동화하더라도, 외부 호출과 고위험 변경은 사람 승인이나 별도 서비스 계층을 통과하게 한다. 에이전트에게 도구를 주는 일은 기능을 추가하는 일인 동시에 새로운 API 표면을 공개하는 일이다.

처음 도입한다면 어디까지 맡길까

Agents API를 처음 붙이는 팀이라면 “우리 업무를 전부 자동화하는 에이전트”부터 만들지 않는 편이 좋다. 다음처럼 실패해도 피해가 제한된 작업 하나를 고른다.

사용자의 요청을 읽기 전용으로 조사한다.
필요한 파일과 로그를 수집한다.
원인과 후보 변경을 보고서로 만든다.
패치나 티켓은 초안으로만 만든다.
사람이 승인하면 다음 작업 세션에서 제한된 쓰기를 수행한다.

작업 지시에도 운영 경계를 직접 적어둔다.

- 기본 모드는 읽기 전용이다.
- 쓰기는 지정된 workspace 디렉터리에서만 허용한다.
- 비밀값, 인증서, 개인키, 운영 데이터는 읽지 않는다.
- 외부 메시지 전송과 운영 환경 변경은 승인 없이는 실행하지 않는다.
- 각 도구 호출과 생성 artifact를 기록한다.
- 실패하면 추측으로 완료하지 말고 중단 이유와 다음 조치를 보고한다.

이 정도의 제한은 에이전트의 능력을 줄이는 장치라기보다, 어떤 상황에서 자동화가 멈춰야 하는지를 알려주는 계약에 가깝다. 자동화의 첫 성공 기준도 “사람 없이 끝났다”가 아니라 “사람이 검토할 수 있는 상태로 반복해서 도달했다”로 잡는 게 맞다.

OpenAI Agents API는 애플리케이션이 장시간 작업을 수행하는 데 필요한 실행기를 직접 만들지 않아도 된다는 점에서 매력적이다. 특히 세션, 도구, sandbox, compaction, 서브에이전트가 한 흐름 안에 들어온다. 하지만 이 편리함 때문에 책임이 사라지는 것은 아니다. 오히려 모델 호출과 실행 환경 사이의 경계를 제품 설계에서 더 선명하게 그어야 한다.

내가 첫 배포에서 확인할 항목은 모델 점수가 아니다. 세션이 사용자와 workload별로 격리되는지, 읽기와 쓰기 도구가 분리되는지, compaction 전후의 체크포인트를 사람이 읽을 수 있는지, 실패한 작업을 중단·재개할 수 있는지, 운영 변경 앞에 승인 지점이 있는지다.

에이전트를 서비스에 붙이는 순간 제품은 답변을 생성하는 시스템에서 작업을 수행하는 시스템으로 바뀐다. Agents API는 그 전환에 필요한 harness를 제공한다. 남은 일은 우리가 그 harness에 어떤 도구를 연결하고, 어떤 권한을 주고, 어디에서 멈추게 할지 정하는 것이다.

Sources

[1] https://openai.com/index/introducing-the-agents-api [2] https://developers.openai.com/api/docs/guides/agents-api/overview [3] https://developers.openai.com/api/docs/guides/compaction [4] https://developers.openai.com/api/docs/guides/agents-api/environments/self-hosted

AI 코딩 에이전트에게 테스트를 시켜도 품질이 좋아지지 않는 이유

Fri, 11 Sep 2026 03:00:00 +0000

AI 코딩 에이전트에게 테스트를 맡기는 팀이 늘었지만, 테스트가 실행됐다는 사실만으로 품질이 올라가지는 않는다. 초록색 체크가 많아도 틀린 기대값을 검증하고 있다면 버그는 그대로 남는다.

최근 공개된 실험은 이 불편한 장면을 꽤 구체적으로 보여준다. 에이전트에게 TDD, 퍼징, 속성 기반 테스트 같은 이름을 알려주는 것과 그 기법의 목적을 이해시켜 실제 위험을 찌르게 하는 것은 전혀 다른 작업이다. 이 글에서는 그 차이를 살펴보고, 우리 팀의 AI 코딩 에이전트 테스트 흐름에 어떤 안전장치를 붙일지 적어본다.

테스트 파이프라인을 떠올릴 때 화면에 보이는 것은 보통 테스트 수, 통과율, 커버리지다. 하지만 진짜 질문은 조금 다르다. “이 테스트가 틀린 구현을 통과시키지 않을 수 있는가?”다. 이 질문을 놓치면 테스트는 품질 장치가 아니라 작업 완료를 표시하는 체크리스트가 된다.

테스트를 시켰다는 말과 검증이 된다는 말은 다르다

에이전트가 잘하는 일과 놓치는 일

AI 코딩 에이전트는 명시적인 작업에는 강하다. 테스트 파일을 만들고, 명령어를 실행하고, 실패한 assertion을 고치고, 커버리지 숫자를 올리는 일은 빠르게 반복한다. 문제는 그 다음이다. 무엇을 틀리면 안 되는지, 어떤 입력 조합이 실제 장애로 이어지는지, 결과를 어떤 독립된 기준으로 판정해야 하는지는 요구사항에 빈틈이 있으면 같이 흐려진다.

그래서 “퍼징을 사용해라”라는 지시는 랜덤 바이트를 잔뜩 넣으라는 뜻으로 축소될 수 있다. “형식 검증을 해라”라는 지시는 실제 구현의 위험한 경계를 증명하는 대신, 틀려도 아무 영향이 없는 추상 명제를 증명하는 일로 변할 수 있다. 기법의 이름은 지켰지만 기법이 존재하는 이유는 사라진다.

Dan Luu가 공개한 에이전트의 테스트·검증 기법 활용 실험은 이 현상을 실험 조건으로 쪼개서 본다. 한국어 요약은 GeekNews의 정리에서 볼 수 있고, 같은 글이 올라간 Hacker News 토론에는 “방법을 적용했지만 목적을 잃는다”는 관찰이 이어진다. 개인적인 인상이라기보다 반복 실행에서 자꾸 나타나는 행동 패턴에 가깝다는 뜻이다.

테스트를 많이 쓰는 에이전트가 곧 테스트를 잘 쓰는 에이전트는 아니다. 테스트의 수는 실행 비용과 리뷰 비용을 늘리지만, 실패해야 할 코드가 실패하는지는 별도의 문제다. 품질을 측정할 때 통과율을 첫 번째 지표로 놓으면 이 간극을 보기 어렵다.

26개 조건 실험이 보여준 테스트의 빈틈

Zstd와 IMAP에서 드러난 차이

실험은 Rust로 Zstd 구현을 만들게 하면서 26개 프롬프트 조건을 비교했다. 추가 지시가 없는 기본값, TDD, 퍼징, 속성 기반 테스트, 변형 테스트, 차분 테스트, QuickCheck, 여러 형식 검증 도구 등이 조건에 들어갔다. Zstd처럼 비트 조작과 압축 상태가 얽힌 문제뿐 아니라 IMAP RFC를 대상으로 한 실행도 함께 살폈다.

중요한 점은 특정 도구의 승패표가 아니다. 26개 조건에서 이름을 알려주는 것만으로는 에이전트가 그 기법의 고유한 검증력을 끌어내지 못했다는 점이다. 기본값 조건이 평균보다 잘 나온 경우도 있었고, 기법을 강하게 지정한 조건이 더 많은 테스트를 쓰면서도 숨은 테스트를 통과하는 정확도가 좋아지지 않는 경우도 있었다. 실험자는 조건 순위를 강하게 일반화하지 말라고 경고하지만, 이름만 붙인 지시의 한계는 일관되게 관찰된다.

Zstd의 네 개 스트림 점프 테이블처럼 입력 사이의 관계가 중요한 구간에서 에이전트는 그럴듯한 정상 케이스를 여러 개 만들었다. 그런데 네 스트림을 모두 같게 만들거나 단순한 패턴을 반복하면 순서를 뒤집는 버그가 있어도 테스트는 통과한다. 테스트가 기능을 호출했다는 사실은 남지만, 버그를 구별하는 입력은 사라진 셈이다.

IMAP에서도 큰 방향은 달라지지 않았다. 프로토콜 문제에서는 상태 전이, 허용되지 않은 순서, 경계 응답이 중요하다. 그렇지만 에이전트가 이름만 전달받으면 표준적인 단위 테스트를 먼저 만들고, 나중에 도구를 형식적으로 붙이는 흐름으로 기울기 쉽다. 복잡한 입력 공간이 있는 문제인지 단순한 함수인지와 상관없이, “테스트 기법을 썼다”는 기록과 “실패를 찾아냈다”는 결과 사이에 간격이 생긴다.

기법 이름만 알려줬을 때 생기는 피상적 사용

퍼징에서는 무작위 바이트가 대부분 같은 거부 경로로 들어갔다. 속성 기반 테스트에서는 확인할 속성이 하나뿐이거나, 라운드트립처럼 이미 정상 동작을 전제로 하는 쉬운 속성에 집중했다. 차분 테스트에서는 서로 다른 구현을 비교해야 하는데 사실상 같은 로직을 두 번 작성해 같은 버그를 공유하는 장면이 나왔다. 변형 테스트라고 해놓고 실제 변형을 거의 만들지 않는 경우도 있었다.

형식 도구도 마찬가지다. 구현의 버그가 있을 법한 경계를 대상으로 하지 않고, 범위를 벗어나지 않는다는 식의 당연한 명제를 증명하면 도구의 실행 흔적은 남아도 정확성은 늘지 않는다. 사람 리뷰어라면 “이 증명이 실제 장애를 어떻게 막나?”라고 물을 텐데, 에이전트는 그 질문을 스스로 끝까지 유지하지 못한다.

이 대목에서 프롬프트에 도구 목록을 더 길게 붙이는 방식은 매력적이지만 효과가 제한적이다. 에이전트가 따르는 것은 가장 쉽게 확인할 수 있는 지시일 가능성이 크다. 테스트 파일이 생겼는지, 명령어가 0으로 끝났는지는 확인하기 쉽다. 반면 테스트의 기대값이 요구사항과 독립적인지, 실패한 변형이 정말 버그를 대표하는지는 추가 오라클이 없으면 확인하기 어렵다.

TDD와 기본값 결과를 읽는 법

테스트를 먼저 쓴다고 자동으로 좋은 테스트가 되지는 않는다

실험에서 TDD 조건은 행동을 크게 바꿨다. 에이전트는 기본값보다 더 많은 테스트를 만들었고, 구현 전에 실패하는 테스트를 남기는 빈도도 높았다. 테스트-코드-테스트를 반복하는 흐름은 분명 더 선명해졌다. 그런데 Zstd의 어려운 경계 사례를 더 잘 찌른다는 보장은 없었다. 오히려 일반 케이스와 쉬운 테스트가 늘면서, 일부 오류를 잡지 못하는 구현이 나왔다.

이 결과를 TDD 자체의 실패로 읽으면 곤란하다. TDD는 요구사항의 예시를 빠르게 실행 가능한 문서로 만들고, 작은 피드백 루프를 제공하는 좋은 설계 습관이다. 다만 에이전트가 TDD를 “실패하는 테스트를 하나 만들고, 그 테스트만 통과시키는 순서”로 축소할 수 있다는 점이 문제다. 테스트가 사업 규칙이나 프로토콜 계약을 대변하지 않으면 순서를 지켜도 검증력은 낮다.

내가 보는 핵심은 테스트를 먼저 쓰느냐 나중에 쓰느냐가 아니다. 테스트를 만들기 전에 위험한 동작과 정답 판정법을 충분히 외부화했느냐에 가깝다. 사람이 코드를 읽고 난 뒤에야 보이는 경계가 있다면, 블랙박스 예시만 먼저 쌓는 흐름은 그 경계를 계속 미룰 수 있다.

기본값이 잘 나온 이유를 과하게 해석하지 않기

추가 지시가 없는 기본값이 상대적으로 좋은 결과를 냈다고 해서 “에이전트에게 맡길수록 좋다”는 뜻도 아니다. 기본값 에이전트가 우연히 문제에 맞는 일반 테스트를 만들었을 수 있고, 조건별 차이가 실행 표본의 변동일 수도 있다. 반대로 TDD나 퍼징이 항상 나쁘다는 뜻도 아니다. 숙련된 사람이 입력 분포와 판정 기준을 설계하면 같은 도구가 훨씬 다른 결과를 낸다.

이 실험에서 가져올 문장은 “기법 이름을 지시하면 품질이 오른다”가 아니라 “목적과 오라클까지 지시하지 않으면 기법이 껍데기만 남을 수 있다”다. AI 에이전트의 작업 루프를 설계할 때 실행 단계마다 완료 조건을 분리했던 것처럼, 테스트도 실행·판정·독립 검토를 서로 다른 단계로 둬야 한다.

계약 기반 테스트로 오라클을 먼저 세우기

사전조건·사후조건·정의되지 않은 동작을 적는다

좋은 대안은 테스트 코드를 바로 쓰게 하기 전에 계약을 작성하게 하는 것이다. Google Research의 계약 기반 테스트 연구는 이 흐름을 사전조건, 사후조건, 정의되지 않은 동작으로 구체화한다. 에이전트가 코드와 요구사항을 읽고 이 세 가지를 먼저 문서화한 뒤 테스트를 생성하게 했더니, 전통적인 테스트 생성 에이전트 기준으로 버그 탐지율이 9.8%p, 분기 커버리지가 2.5%p 개선됐다. arXiv의 원문 초록에서도 같은 평가 결과와 비교 기준을 확인할 수 있다.

여기서 계약은 거창한 형식 명세일 필요가 없다. 예를 들어 결제 요청 함수라면 “인증된 사용자만 호출할 수 있다”는 사전조건, “성공 응답에는 하나의 거래 ID가 있고 재시도해도 중복 결제가 생기지 않는다”는 사후조건, “결제 제공자가 타임아웃 뒤 승인 여부를 확정하지 않은 상태”를 정의되지 않은 동작 또는 별도 정책으로 적을 수 있다. 이 문장이 있어야 에이전트가 입력을 만들 때 무엇을 흔들고, 결과를 어떻게 판정할지 결정할 수 있다.

// 계약을 먼저 고정하고, 구현을 따라가는 기대값은 피한다.
it("재시도해도 같은 멱등 키는 거래를 한 번만 만든다", async () => {
  const first = await pay({ amount: 12000, idempotencyKey: "order-42" });
  const retry = await pay({ amount: 12000, idempotencyKey: "order-42" });

  expect(first.status).toBe("approved");
  expect(retry.transactionId).toBe(first.transactionId);
  expect(await ledger.count({ orderId: "order-42" })).toBe(1);
});

코드가 이미 만든 값을 복사해 assertion에 넣는 방식과 계약에서 독립적으로 도출한 기대값을 비교해 보자. 전자는 구현과 테스트가 같은 오해를 공유하기 쉽다. 후자는 실패 시 “어느 규칙을 어겼는가”를 말할 수 있다. 이 차이가 오라클의 차이다.

계약 기반 체크리스트

실무에서는 다음 질문을 이슈 템플릿이나 에이전트 작업 파일에 고정해두면 좋다.

유효한 입력의 최소·최대·빈 경계는 어디인가?
입력이 만족해야 할 사전조건은 무엇이며, 위반하면 어떤 오류를 반환하는가?
성공 후 반드시 유지되어야 하는 상태와 불변식은 무엇인가?
외부 API 지연, 중복 요청, 순서 뒤바뀜을 어떤 정책으로 다루는가?
정의되지 않은 동작을 허용할지, 거부할지, 별도 경고로 남길지 누가 결정했는가?
기대값을 구현 코드가 아닌 규격, 참조 구현, 불변식, 독립 계산에서 만들 수 있는가?

이 체크리스트를 통과하지 못한 테스트는 숫자를 늘리기 전에 멈춘다. 테스트를 더 생성하는 것이 아니라 판정 기준을 더 명확히 하는 쪽이 먼저다.

보안 테스트는 위험도와 독립성을 붙여야 한다

SecureVibeBench가 던지는 현실적인 질문

기능 테스트가 통과해도 보안 결함은 남을 수 있다. SecureVibeBench는 AI 에이전트가 실제 오픈소스 취약점이 도입되는 맥락을 재구성하도록 만든 C/C++ 보안 코딩 벤치마크다. 여러 파일을 수정해야 하는 저장소 작업과 정적·동적 오라클을 함께 사용해 기능과 보안을 같이 평가한다. 핵심 메시지는 단순하다. 코드가 컴파일되고 일반 기능 테스트를 통과하는 것만으로는 안전한 코드라고 부르기 어렵다.

이 벤치마크를 “에이전트는 보안을 못 한다”는 문장으로 소비하면 과장이다. 과제와 모델, 평가 오라클에 따라 결과는 달라진다. 다만 취약점이 생기는 지점을 재현하고, 기능과 보안을 함께 확인하는 평가가 필요하다는 방향은 분명하다. Hacker News의 관련 토론에서도 테스트 방법의 이름보다 실제 목표를 유지하는 능력이 중요하다는 논점이 반복된다.

독립 오라클과 변형 테스트를 조합한다

독립 오라클은 에이전트가 만든 코드와 테스트가 같은 실수를 공유하지 않게 하는 장치다. 참조 구현, 별도의 계산기, 스키마 검증기, 보안 스캐너, 정책 엔진처럼 구현 경로가 다른 판정기를 사용한다. 완전히 다른 구현을 만들기 어렵다면 입력을 변형한 뒤 보존되어야 하는 관계를 검사해도 된다.

예를 들어 권한 검사 함수에는 사용자 역할을 한 단계 낮추거나, 리소스 소유자를 바꾸거나, 만료 시간을 과거로 이동시키는 변형을 적용한다. 정상 요청이 승인되더라도 이 변형이 여전히 승인되면 권한 경계가 무너진 것이다. 압축이나 프로토콜 구현에서는 입력 순서, 스트림 간 차이, 길이 경계, 중복 프레임을 변형하고 결과 관계가 유지되는지 확인한다.

보안 검증은 모든 경로에 같은 강도로 붙일 필요가 없다. 외부 입력을 파싱하는 코드, 권한과 테넌트 경계를 넘는 코드, 파일·명령어·네트워크를 다루는 코드, 암호 키나 개인정보를 만지는 코드부터 높은 위험도로 분류한다. 이 영역은 정적 분석만으로 끝내지 않고 악성 입력, 권한 우회, 로그·에러 메시지의 정보 노출까지 독립적으로 확인한다.

팀에 적용할 때 사람이 남겨야 할 경계

사람은 코드를 승인하기보다 판정 기준을 승인한다

AI 코딩 에이전트의 속도를 살리려면 사람이 모든 줄을 다시 타이핑하듯 리뷰할 수는 없다. 대신 사람이 반드시 승인해야 하는 경계를 앞쪽에 둔다. 사전조건과 사후조건, 보안 위험도, 외부 시스템에 미치는 영향, 정의되지 않은 동작의 정책을 먼저 승인하고, 에이전트는 그 계약 안에서 구현과 테스트를 반복하게 한다.

승인 기준도 “테스트가 모두 통과했다”에서 끝내지 않는다. 변경이 만든 새 테스트 중 실제 요구사항과 연결되지 않는 테스트는 무엇인지, 한 테스트가 실패했을 때 독립된 오라클이 같은 결론을 내리는지, 변형 테스트가 위험 경계를 건드렸는지를 묻는다. 커버리지가 올랐는데도 핵심 분기가 실행되지 않았다면 숫자를 낮게 보는 편이 정확하다.

작은 자동화 루프부터 시작한다

작업 프롬프트에는 아래처럼 순서를 명시할 수 있다.

변경 대상의 사전조건, 사후조건, 정의되지 않은 동작을 먼저 작성한다.
각 계약에 대해 정상, 경계, 위반 입력을 한 가지씩 만든다.
기대값은 현재 구현이 아니라 규격·참조 계산·불변식에서 만든다.
독립 오라클 또는 변형 테스트로 같은 버그를 공유하지 않는지 확인한다.
보안 위험도가 높은 경로는 정적 분석과 악성 입력 검증을 별도로 실행한다.
사람이 승인할 질문과 에이전트가 자동으로 통과시킬 질문을 구분해 보고한다.

이 루프는 TDD를 버리는 방법이 아니다. TDD의 빠른 피드백은 유지하되, 첫 번째 실패 테스트를 쓰기 전에 계약을 넣는 방식이다. 에이전트가 만드는 테스트의 양을 제한하고, 각 테스트가 어느 계약과 위험을 커버하는지도 함께 기록하게 하면 리뷰할 것이 줄어든다. 이전에 다뤘던 AI 운영 자동화와 팀의 간극과 비슷하게, 도구 도입보다 책임 경계와 운영 루프를 먼저 정하는 편이 오래 간다.

내가 팀에서 보고 싶은 결과 보고서는 “테스트 184개 통과”가 아니다. “인증되지 않은 요청은 거부했고, 동일한 멱등 키의 재시도는 한 건으로 남았고, 권한을 바꾼 변형은 실패했으며, 이 판정은 구현과 다른 오라클로 확인했다”에 가깝다. 숫자는 그 뒤에 붙어도 된다.

AI 코딩 에이전트에게 테스트를 시키는 일은 이제 기본 동작이 됐다. 다음 단계는 테스트 도구를 더 많이 붙이는 것이 아니라, 에이전트가 무엇을 검증해야 하는지와 결과를 누가 독립적으로 판정하는지를 설계하는 일이다. 26개 조건 실험이 보여준 피상적 사용은 에이전트의 능력만 탓할 문제가 아니다. 사람의 요구사항이 기법 이름에서 멈췄는지도 같이 돌아봐야 한다.

계약을 먼저 쓰고, 위험한 경계를 변형하고, 독립 오라클로 결과를 판정하고, 보안 변경에는 사람의 승인 지점을 남긴다. 이 네 가지가 있으면 TDD든 퍼징이든 형식 도구든 목적에 맞게 쓸 가능성이 커진다. 테스트 통과는 출발 신호이고, 품질 판단은 그 다음 단계에서 시작된다.

스페이스X의 커서 인수, AI 코딩 도구의 독립성을 묻다

Sun, 30 Aug 2026 06:00:00 +0000

2026년 8월 28일, OpenAI가 SpaceX에 Cursor용 모델 공급 계약을 단계적으로 종료하겠다고 알렸다. OpenAI가 제시한 공급 중단 예정일은 11월 12일이다. 이 소식만 보면 Cursor 전체가 멈추는 것처럼 읽히기 쉽지만, 발표가 직접 말하는 범위는 “Cursor에 제공하던 OpenAI 모델 계약”이다. Cursor라는 에디터 자체의 종료를 뜻하는 발표는 아니다.

이 결정이 눈에 띄는 이유는 불과 며칠 전까지의 방향과 정반대로 보이기 때문이다. Cursor는 8월 14일 SpaceX에 인수됐다고 발표했고, SpaceX와 함께 더 큰 컴퓨팅 자원과 자체 모델 개발을 활용하겠다고 설명했다. 한쪽에서는 AI 코딩 도구를 모델·컴퓨트·제품이 결합된 하나의 사업으로 만들고, 다른 쪽에서는 그 결합을 계약과 안전 책임의 문제로 다시 나눈다.

이번 글에서는 확인된 사실과 그 사실에서 도출한 해석을 나눠 본다. 인수 자체의 승패를 예측하기보다, 특정 모델을 에디터에서 호출해 쓰는 개발자가 무엇을 점검해야 하는지에 초점을 맞춘다. AI 코딩 도구의 경쟁력이 모델 점수 하나가 아니라 공급자 변경에 견디는 운영 경계에서 드러나는 시점이기 때문이다.

이번 결정에서 확인된 사실

11월 12일은 Cursor 전체의 종료일이 아니다

OpenAI의 공식 발표에는 두 가지 시간이 함께 들어 있다. 하나는 2026년 8월 28일에 계약 종료 의사를 통보했다는 시점이고, 다른 하나는 11월 12일로 제시한 모델 공급 중단 시점이다. OpenAI는 개발자가 Cursor에서 자사 모델을 최대한 오래 이용할 수 있도록 계약상 가능한 가장 긴 통지 기간을 적용했다고 설명했다.

따라서 현재 확인 가능한 사실은 “Cursor 안에서 OpenAI 모델을 쓰는 경로가 영향을 받는다”는 데까지다. Cursor 안에서 다른 공급자의 모델이나 자체 모델이 어떻게 계속 제공될지, 사용자가 지금 가진 설정과 대화 기록이 어떤 방식으로 이전될지는 이 발표만으로 확정할 수 없다. 모델 선택 화면에 OpenAI가 보인다는 이유만으로 모든 기능이 같은 날 사라진다고 단정해서는 안 된다.

OpenAI는 지배권 변경 뒤 계약을 취소할 수 있는 제한된 기간이 맞춤 계약에 있었다고 밝혔다. 또 앞으로 출시할 모델, 특히 발표문에서 언급한 Astra를 Cursor에 제공하지 않겠다고 했다. 이것은 기술적 장애 공지가 아니라, 지배구조가 바뀐 파트너에게 모델을 계속 제공해도 이용약관과 안전 요구를 지킬 수 있는지에 대한 계약 판단이다.

Cursor가 얻으려는 것은 단순한 에디터 기능이 아니다

Cursor는 인수 완료 발표에서 SpaceX가 보유한 대규모 GPU 자원에 접근해 더 강하고 경제적인 모델을 만들 수 있다고 설명했다. Cursor의 공식 발표는 제품이 짧은 코드 자동완성에서 실제 작업을 맡기는 AI 팀원으로 이동해 왔다는 맥락도 함께 제시한다. 표현은 낙관적이지만, 개발자에게 중요한 변화는 모델 이름보다 공급망의 위치다.

SpaceX가 공개한 EU 투자설명서에는 4월 19일 Cursor와 컴퓨트 계약을 맺었다고 적혀 있다. 문서상 Cursor는 인력, 데이터셋, 문서, 기술 노하우, 워크플로, 프롬프트, 사양, 소프트웨어 코드를 제공하고 SpaceX는 특정 GPU 클러스터의 컴퓨트 용량을 제공하는 구조다. 양사의 사전 보유 지식재산과 독립적으로 개발한 지식재산은 각자 보유한다는 설명도 포함되어 있다.

여기서 조심할 부분이 있다. 이 계약에 회사 차원의 데이터와 워크플로가 언급된다고 해서 Cursor 고객의 소스 코드가 SpaceX 모델 학습에 자동으로 들어간다는 뜻은 아니다. 고객 데이터의 처리와 학습 사용 여부는 제품 약관, 기업 계약, 보존 정책에서 따로 확인해야 한다. 공개 문서가 보여주는 것은 양사 간 협력 구조이지, 모든 고객 데이터의 실제 흐름이 아니다.

독립 에디터도 기반 모델 공급자와 경쟁한다

AP는 6월 보도에서 Cursor가 Anthropic의 Claude Code와 OpenAI의 Codex 같은 도구와 경쟁하면서도, 초기에는 대형 연구 회사와의 파트너십에 의존해 왔다고 정리했다. AP의 인수 보도는 Cursor가 전문 개발자에게 넓게 배포된 제품이라는 점을 SpaceX가 매력으로 봤다고 전한다.

이 구조에서 에디터는 더 이상 모델을 담는 얇은 화면만이 아니다. 어떤 모델을 어떤 권한으로 호출할지, 결과를 어떤 도구에 넘길지, 사용자 작업을 어떤 정책으로 기록할지를 결정하는 유통·실행 계층이 된다. 동시에 모델 공급자 입장에서는 에디터가 자사 모델의 배포 채널이자 경쟁 제품이 될 수 있다. 이번 계약 종료 예고는 그 긴장이 뉴스 한 줄로 드러난 사례다.

개발자에게 중요한 변화는 모델보다 경계다

모델 전환 비용은 API 키 교체보다 크다

많은 팀이 공급자 변경을 API 키와 모델 ID를 바꾸는 작업으로 생각한다. 실제로는 다음 요소가 함께 묶여 있다.

점검 영역	확인할 질문
모델 라우팅	저장소별 기본 모델과 대체 모델이 문서화되어 있는가?
프롬프트	시스템 지침과 프로젝트 규칙이 특정 모델의 동작에 과하게 기대고 있지 않은가?
도구 권한	파일 쓰기·셸·네트워크 호출이 공급자 전환 뒤에도 같은 승인 경계를 갖는가?
결과 품질	핵심 작업을 모델별로 비교할 회귀 평가와 샘플 저장소가 있는가?
비용·로그	공급자와 모델별 호출량, 지연, 실패, 데이터 보존을 구분해서 볼 수 있는가?

예를 들어 OpenAI 모델에서 테스트를 통과하던 에이전트가 다른 모델로 바뀌면, 단순한 문장 스타일만 달라지는 것이 아니다. 패치 크기, 파일을 읽는 순서, 테스트를 실행하는 빈도, 실패를 보고하는 방식이 달라질 수 있다. 그러면 같은 프롬프트를 넣어도 변경 파일 수와 리뷰 비용이 달라진다. 모델 전환은 모델 품질 비교가 아니라 작업 프로토콜의 재검증이다.

개인 개발자라면 모든 것을 자동화할 필요는 없다. 자주 쓰는 세 가지 작업, 예를 들면 기능 추가·버그 수정·리팩터링을 작은 고정 저장소에서 각각 한 번씩 실행해 보면 된다. 같은 요구사항을 두 모델에 주고 변경 diff, 테스트 결과, 도구 호출 수, 사람이 되돌린 부분을 비교해 기록하는 방식이다. 숫자 하나로 승자를 정하기보다 내 코드베이스에서 어떤 실패가 반복되는지 확인하는 편이 전환 판단에 유용하다.

대화 기록보다 작업 규칙을 먼저 옮겨라

에디터를 바꿀 때 가장 아쉬운 것은 오래 쌓인 대화 기록처럼 보인다. 그러나 장기적으로 더 중요한 자산은 저장소에 남아 있는 작업 규칙이다. 빌드 명령, 금지된 파일, 테스트 순서, 데이터 마스킹 기준, 배포 전 확인 목록이 문서와 스크립트로 고정되어 있으면 모델이 바뀌어도 다시 설명할 비용이 줄어든다.

반대로 규칙이 채팅 기록에만 있으면 공급자나 에디터를 바꾸는 순간 사라진다. 개인 메모와 프로젝트 문서를 분리하고, 에이전트가 읽어도 되는 컨텍스트와 읽으면 안 되는 비밀을 파일 수준에서 나누는 것이 좋다. 이 원칙은 AI 코드 뒤에 남는 운영 공백을 다룬 이전 글의 결론과도 닿아 있다. 속도를 높이는 도구일수록 실행 경계와 복구 절차가 문서화되어 있어야 한다.

데이터 경계는 인수 뉴스와 별도로 확인한다

SpaceX의 투자설명서는 Cursor와의 컴퓨트 협력에서 데이터셋과 워크플로 등을 언급하지만, 공개된 문장만으로 실제 제품 사용자의 코드가 어떤 조건에서 처리되는지 판단할 수는 없다. 기업 사용자는 인수 소식보다 자신의 계약서와 관리자 콘솔을 먼저 봐야 한다.

최소한 다음 항목은 확인해야 한다.

프롬프트와 도구 결과가 모델 학습에 사용되는지 여부.
보존 기간과 삭제 요청 경로, 백업에 남는 기간.
모델 공급자와 에디터 운영자가 각각 어떤 로그를 볼 수 있는지.
기업용 정책이 인수 뒤에도 유지되는지, 변경 통지가 어떻게 이뤄지는지.
조직 밖으로 소스 코드가 나갈 때 승인과 감사 기록이 남는지.

이 목록은 특정 기업을 의심하기 위한 것이 아니다. AI 코딩 도구가 여러 모델과 서비스를 묶는 순간, 데이터 책임이 한 회사의 이름으로 설명되지 않기 때문에 필요한 기본 확인이다. 공급자가 바뀌어도 내 코드의 이동 경로를 설명할 수 있어야 한다.

11월 전까지 준비할 운영 체크리스트

첫째, 사용 중인 모델과 기능을 목록화한다

Cursor 설정 파일, 팀 문서, 자동화 스크립트, CI 작업에서 OpenAI 모델을 직접 또는 간접으로 호출하는 곳을 찾는다. 에디터에서 모델을 선택한 기록만 보지 말고, 코드 리뷰·클라우드 에이전트·외부 MCP 서버처럼 뒤에서 별도 공급자를 부르는 기능도 분리한다. “Cursor를 쓴다”는 한 문장으로는 실제 의존성을 알 수 없다.

목록에는 모델명뿐 아니라 사용 목적, 저장소, 권한, 데이터 민감도, 대체 경로, 마지막 검증일을 함께 적는다. 이렇게 해야 11월 12일 전에 모든 기능을 바꿀 필요가 있는지, 특정 팀만 확인하면 되는지 우선순위를 정할 수 있다.

둘째, 대체 경로를 문서가 아니라 실행으로 검증한다

대체 모델을 등록해 두었다는 사실은 운영 준비가 아니다. 읽기 전용 작업, 작은 수정, 실패한 테스트 진단처럼 위험도가 다른 세 가지 시나리오를 만들어 실제로 실행해야 한다. 결과가 좋았는지뿐 아니라 에이전트가 요청한 도구와 수정한 파일을 비교해야 한다. 특히 쓰기 권한과 네트워크 권한이 예상과 다르게 열리지 않는지 확인한다.

팀 단위라면 하루에 한 번 모든 작업을 옮길 필요도 없다. 저장소 하나를 골라 새 라우팅을 카나리로 적용하고, 리뷰어가 diff와 테스트를 확인한 다음 범위를 넓히면 된다. 실패했을 때 원래 경로로 되돌리는 방법도 같은 문서에 적는다. 전환 계획에 롤백이 없다면 실제 장애가 발생할 때 처음으로 설계하게 된다.

셋째, 계약의 변경 조항을 기술 요구사항으로 번역한다

이번 사례의 핵심은 모델 성능이 아니라 지배권 변경과 계약 해지 기간이었다. 기업이 에디터나 모델 API를 장기 사용한다면 다음 조항을 구매 검토 단계부터 확인할 필요가 있다.

인수·합병·지배권 변경 시 통지와 해지 권리
모델 공급 중단 예고 기간과 과도기 지원 범위
모델 이름 변경·교체·폐기 때의 호환성 정책
데이터 처리자와 하위 공급자 변경 통지
로그·프롬프트·도구 결과의 보존 및 삭제 기준
내보내기 가능한 설정, 프롬프트, 평가 결과의 형식

이 항목들은 법무 문서에만 남겨두면 개발팀이 사용하지 못한다. 모델 라우팅, 권한, 로그, 평가 저장소의 요구사항으로 바꿔 백로그에 넣어야 한다. 계약이 바뀌었을 때 어떤 코드와 설정을 바꿔야 하는지 미리 연결해 두면 공지 당일의 혼란이 줄어든다.

AI 코딩 도구의 독립성은 다시 정의해야 한다

이번 사건을 “OpenAI와 Cursor 중 누가 옳은가”로만 보면 개발자가 얻을 정보가 적다. Cursor는 SpaceX 인수로 컴퓨트와 자체 모델에 더 가까워지려 하고, OpenAI는 지배권 변경 뒤 자사 모델의 사용 조건을 통제하려 한다. 두 방향 모두 사업적으로 설명할 수 있지만, 그 사이에 있는 개발자는 공급자와 제품의 경계를 다시 점검해야 한다.

JetBrains의 2026 개발자 생태계 조사에 따르면 5~7월 기준 전문 개발자의 90%가 업무에서 AI 코딩 에이전트를 적어도 주 1회 사용했고 68%는 매일 사용했다. 에이전트가 실험 도구를 넘어 일상적인 작업 표면이 됐다는 뜻이다. 사용 빈도가 높아질수록 모델·에디터·컴퓨트·데이터 정책이 한 회사의 제품 설명 안에서만 보이지 않는 문제가 커진다.

내가 이번 뉴스에서 읽은 핵심은 독립성이 사라졌다는 선언이 아니다. 오히려 독립성을 “한 공급자에 영원히 묶이지 않는 능력”으로 다시 정의해야 한다는 신호에 가깝다. 모델이 바뀌어도 핵심 작업을 재현할 수 있고, 권한과 데이터 흐름을 설명할 수 있고, 실패하면 이전 경로로 돌아갈 수 있어야 한다. 그것이 개인 개발자에게는 이동성이고, 팀에게는 협상력이다.

결국 AI 코딩 도구의 다음 경쟁은 더 강한 모델만으로 끝나지 않는다. 누가 더 많은 GPU를 갖고 있는지와 별개로, 개발자가 자신의 규칙·평가·로그·권한을 얼마나 오래 보존할 수 있는지가 중요해진다. 11월 12일이라는 날짜는 특정 제품의 끝이 아니라, 우리가 어떤 경계를 제품에 맡기고 있는지 확인할 수 있는 점검 시점이다.

참고한 원문

GitHub Copilot SDK GA, 에이전트 런타임의 실제 경계

Sun, 16 Aug 2026 08:40:00 +0000

GitHub Copilot SDK가 정식 출시됐다는 소식을 보고 처음 든 생각은 “이제 Copilot을 API로 부를 수 있나?”가 아니었다. 더 정확히는, Copilot CLI가 하던 일을 애플리케이션 안에 얼마나 안전하게 끼워 넣을 수 있느냐가 궁금했다. GitHub는 SDK를 Copilot CLI와 같은 에이전트 런타임을 프로그램에서 호출하는 방법으로 설명한다. 자동완성 라이브러리 하나가 추가된 게 아니라, 계획·도구 호출·파일 수정까지 포함한 실행 루프를 서비스에 붙이는 선택지가 생긴 셈이다.

GitHub Copilot SDK는 무엇을 묶어 제공하나

SDK보다 런타임 경계가 핵심이다

공식 저장소의 설명을 보면 SDK는 Python, TypeScript, Go, .NET, Java, Rust를 지원한다. 언어별 클라이언트가 각각 독립적인 모델 호출 API를 제공하는 방식이 아니다. 각 SDK는 Copilot CLI 서버와 JSON-RPC로 통신하고, CLI 프로세스의 수명까지 관리한다. 애플리케이션에서 SDK 클라이언트를 만들면 뒤에서 Copilot CLI가 서버 모드로 올라오고, 클라이언트는 세션과 이벤트를 주고받는다.

이 구조는 장점과 제약을 동시에 만든다. 장점은 직접 오케스트레이터를 새로 만들지 않아도 된다는 점이다. 계획을 세우고, 도구를 부르고, 파일을 수정하고, 결과 이벤트를 보내는 흐름이 이미 런타임에 있다. 반대로 API 서버 하나를 호출하는 것과 달리 프로세스, 권한, 세션, 종료 처리를 제품이 책임져야 한다. SDK를 넣는 순간 “모델을 호출했다”가 아니라 “작업을 수행하는 실행기를 임베드했다”에 가까워진다.

JSON-RPC는 단순한 내부 구현이 아니다

JSON-RPC를 중간 경계로 둔 덕분에 애플리케이션과 에이전트 실행기를 분리할 수 있다. 외부 CLI 서버에 연결하거나, SDK가 CLI 수명을 직접 관리하도록 선택할 수 있다는 설명도 있다. 작은 로컬 도구라면 기본 프로세스 관리가 편하다. 여러 사용자가 접속하는 서버라면 세션을 어디에 보관하고, 어떤 작업을 어떤 사용자에게 귀속할지부터 설계해야 한다.

여기서 중요한 건 네트워크 프로토콜을 쓴다는 사실이 아니다. 실패가 어느 경계에서 발생했는지를 기록할 수 있다는 점이다. 애플리케이션이 요청을 받았는지, SDK가 세션을 만들었는지, CLI가 도구를 실행했는지, 모델 응답을 반환했는지를 각각 관측할 수 있어야 한다. 에이전트가 조용히 멈추는 문제는 모델 품질보다 이 경계 설계에서 먼저 생긴다.

기능이 늘수록 권한 모델이 먼저다

기본 도구를 그대로 켜면 편하지만 위험하다

Copilot SDK 문서에는 기본적으로 Copilot CLI의 퍼스트파티 도구가 노출된다고 적혀 있다. SDK마다 권한 핸들러로 도구 호출을 승인·거부·수정할 수 있고, 도구 가용성도 사용자 정의할 수 있다. 이 문장을 “도구가 많아 편하다”로 읽으면 곤란하다. 파일 쓰기, 셸 실행, 네트워크 호출이 가능한 에이전트를 고객 요청과 바로 연결하는 순간, 권한 핸들러가 사실상 제품의 보안 경계가 된다.

가장 작은 운영 기준은 작업 종류마다 허용 도구 목록을 따로 두는 것이다. 코드 설명은 읽기 도구만, 테스트 실행은 제한된 명령만, 배포 준비는 별도 승인 세션만 사용한다. 한 번 승인한 도구를 세션 전체에 영구 적용하지도 않는다. 에이전트가 다음 단계에서 어떤 도구를 요청할지 예측하기 어렵기 때문에, 요청 시점의 목적·대상 파일·사용자·세션 만료 시간을 함께 확인하는 편이 낫다.

멀티테넌트 샘플은 제품 설계가 아니다

공식 세션 서버 샘플은 여러 사용자가 SDK를 쓰는 흐름을 보여주지만, 인증과 세션 권한이 구현되어 있지 않고 운영 환경에 바로 배포할 수 없다고 명시한다. 이 경고가 꽤 중요하다. 에이전트 서버는 채팅 UI보다 백엔드에 가깝다. 로그인한 사용자가 다른 사용자의 세션을 재개할 수 없는지, 작업 결과가 다른 테넌트의 파일과 섞이지 않는지, 도구 승인 기록을 감사할 수 있는지를 먼저 확인해야 한다.

이전 글에서 Codex 운영 기준과 긴 에이전트 작업을 정리하면서도 비슷한 결론에 도달했다. 모델이 좋아질수록 맡기는 작업이 길어진다. 작업이 길어질수록 실행 권한과 중단 기준은 모델 성능보다 중요해진다. Copilot SDK도 이 흐름의 예외가 아니다.

BYOK와 인프로세스 전송이 바꾸는 것

BYOK는 비용 버튼이 아니라 책임 이동이다

SDK는 GitHub Copilot 구독을 사용하는 방식 외에 BYOK(Bring Your Own Key)를 지원한다. OpenAI, Microsoft Foundry, Anthropic 같은 공급자의 키를 직접 설정해 GitHub 인증 없이 사용할 수 있다는 설명이다. 이 선택은 모델 공급자를 바꿀 수 있다는 의미 이상이다. 키 저장, 사용량 추적, 테넌트별 한도, 데이터 보존 정책을 애플리케이션이 직접 책임진다는 뜻이다.

특히 “키가 있으니 호출하면 된다”는 접근은 위험하다. 에이전트 세션에 들어간 컨텍스트가 어떤 공급자로 흘러가는지, 도구 결과에 고객 데이터가 섞이는지, 장애가 났을 때 재시도하면서 비용이 늘어나는지를 관측해야 한다. BYOK를 켠다면 공급자별 모델·비용·지연시간을 분리해서 기록하고, 한 작업이 사용할 수 있는 최대 호출 수와 토큰 예산을 세션에 붙이는 편이 현실적이다.

인프로세스 FFI는 지연을 줄이지만 격리를 줄인다

최근 SDK 변경 내역에는 네이티브 라이브러리를 C ABI로 로드하는 인프로세스(FFI) 전송이 추가됐다고 나온다. 별도 자식 프로세스를 띄우는 비용이 없어질 수 있다는 점은 매력적이다. 짧은 요청이 많은 애플리케이션에서는 초기화 지연과 프로세스 관리 부담을 줄이는 데 도움이 된다.

다만 같은 프로세스 안에 들어온다는 건 장애와 자원 고갈의 경계도 가까워진다는 말이다. SDK 런타임이 메모리를 많이 쓰거나 네이티브 오류가 발생할 때 애플리케이션 전체에 영향을 줄 수 있다. FFI를 곧바로 생산 기본값으로 삼기보다, 작업 유형과 트래픽을 나눠 프로세스 전송과 비교하는 게 맞다. 지연시간 하나만 줄이고 장애 격리와 재시작 전략을 잃으면 운영 이득이 아니다.

도구 검색이 알려주는 에이전트의 다음 문제

모든 도구를 프롬프트에 넣지 않는 이유

SDK v1.0.7 변경 내역에는 도구 수가 임계치를 넘으면 MCP와 외부 도구를 처음부터 모두 넣지 않고, 내장 tool_search_tool을 통해 필요할 때 노출하는 옵션이 추가됐다고 적혀 있다. 컨텍스트를 절약하고 도구 설명이 너무 길어지는 문제를 완화하려는 방향이다.

이건 단순한 최적화가 아니다. 도구 검색을 쓰면 에이전트가 어떤 도구를 “발견”할 수 있었는지와 실제로 어떤 도구를 선택했는지가 실행 기록의 일부가 된다. 같은 질문이라도 등록된 도구 집합과 검색 결과에 따라 행동이 달라질 수 있다. 재현 가능한 테스트를 만들려면 모델 입력만 저장해서는 부족하고, 세션에서 검색 가능한 도구 목록과 검색 결과까지 함께 남겨야 한다.

도구 이름이 비슷한 경우에는 더 조심해야 한다. read_file, write_file, run_command가 여러 서버에서 중복 제공되면 에이전트가 선택 이유를 설명하지 못한 채 다른 권한의 도구를 고를 수 있다. 제품에 붙일 때는 도구 이름, 설명, 입력 스키마를 조직의 권한 체계와 맞추고, 검색 결과가 정책을 우회하지 않는지 테스트해야 한다.

“에이전트를 임베드했다” 이후의 체크리스트

실제로 SDK를 도입한다면 첫 버전의 성공 기준을 모델 평가 점수로 잡지 않겠다. 다음 네 가지가 먼저다.

세션마다 사용자·테넌트·작업 디렉터리가 분리되는가.
도구 호출이 승인·거부·실패·취소 상태로 남는가.
런타임 재시작 뒤에도 작업을 안전하게 중단하거나 재개할 수 있는가.
모델·공급자·도구별 비용과 지연을 한 화면에서 볼 수 있는가.

이 네 가지가 갖춰지면 그다음에 모델 교체나 프롬프트 개선을 해도 비교가 된다. 반대로 이 기록이 없으면 에이전트가 잘한 건지, 우연히 통과한 건지, 위험한 도구를 호출하지 않은 건지 알기 어렵다.

Copilot SDK의 GA는 개발자에게 “나만의 Copilot을 만들라”는 초대처럼 보인다. 내가 보기엔 더 현실적인 메시지가 있다. 이제 에이전트를 제품 기능으로 넣을 수 있으니, 실행기 운영도 제품 수준으로 설계하라는 뜻이다. JSON-RPC, BYOK, FFI, 도구 검색은 각각 멋진 기능이지만, 실제 경쟁력은 세션 경계와 권한 로그, 실패 복구에서 나온다.

참고한 공식 자료는 Copilot SDK 저장소, GitHub Docs의 시작 가이드, SDK GA 발표, SDK 변경 내역, Node.js SDK 문서, 세션 서버 샘플이다.

2026 스타트업 설문, AI 코드 뒤에 남은 운영 공백

Mon, 20 Jul 2026 03:20:12 +0000

2026 스타트업 설문을 읽다가 묘한 숫자 조합을 봤다. 응답자의 61%는 코드 절반 넘게를 AI가 생성했다고 답했는데, 59%는 AI 워크로드를 따로 모니터링하지 않는다고 했다. 만드는 속도는 확실히 빨라졌지만 운영 체계는 그 속도를 따라가지 못한 셈이다.

7월 20일 GeekNews에 올라온 Supabase의 State of Startups 2026는 스타트업 빌더 2,000명의 응답을 정리한 보고서다. 같은 날 12시 16분 KST 확인 기준 GeekNews 소개 글은 신규 목록 3위에 있었다. AI 도구 선호도부터 창업자 구성, 에이전트 운영, 첫 고객 획득까지 한 화면에 붙여 놓으니 모델 발표보다 훨씬 현실적인 풍경이 보였다.

나는 이 설문을 “AI가 스타트업을 얼마나 쉽게 만들었나”보다 “쉬워진 개발 뒤에 어떤 일이 아직 어려운가”를 보여주는 자료로 읽었다. 코드 생산은 이미 기본값에 가까워졌다. 반면 평가, 관측, 프롬프트 관리, 판매는 여전히 사람의 기억과 수작업에 기대고 있다. 작은 팀일수록 이 간격이 빠르게 운영 부채가 된다.

AI 코드가 절반을 넘은 스타트업이 다수가 됐다

61%가 코드베이스의 절반 넘게를 AI가 생성했다고 답했다

보고서에서 코드베이스의 AI 생성 비중이 76~100%라는 응답은 40%, 51~75%는 21%였다. 두 구간을 합치면 61%다. 반대로 AI 생성 코드가 0%라는 응답은 2%에 그쳤다. Supabase가 “AI-written code became the median experience”라고 요약한 이유가 숫자로 보인다.

다만 이 비율을 Git 커밋의 정밀한 계측값처럼 읽으면 안 된다. 설문 응답자가 체감한 코드베이스 비중이고, AI가 초안을 만든 뒤 사람이 크게 고친 코드까지 어떻게 셌는지 공통 정의가 제시되지는 않는다. 그래도 방향은 분명하다. 이제 스타트업에서 AI 코드는 실험 기능이 아니라 일반적인 생산 수단이 됐다.

나는 이 변화가 개발자의 필요성을 없앴다고 보지 않는다. 오히려 무엇을 만들지 정하고, 생성된 변경을 검증하고, 실패를 복구하는 일이 더 비싸졌다. 타이핑 비용이 줄면 제품 가설을 더 자주 시험할 수 있지만, 틀린 가설을 더 빠르게 배포할 수도 있다. 속도 자체는 품질이나 매출을 보증하지 않는다.

에이전트와 MCP도 실험 단계를 넘어가고 있다

AI 에이전트를 만들고 있거나 만들 계획이라고 답한 비율은 52%였다. MCP는 29%가 프로덕션에서 적극 사용 중이고, 28%는 실험 중이라고 답했다. 둘을 단순 합산해 채택률처럼 말할 수는 없지만, 에이전트 도구 연결이 일부 얼리어답터만의 주제는 아니라는 신호는 충분하다.

여기까지 보면 꽤 낙관적이다. 작은 팀도 모델, 데이터베이스, 배포 플랫폼을 조합해 전에는 여러 명이 필요했던 제품을 만들 수 있다. 문제는 다음 화면에서 나온다. 에이전트를 만드는 비율과 에이전트를 운영할 준비가 된 비율 사이가 꽤 벌어져 있다.

AI 운영 공백은 평가와 관측에서 선명했다

프롬프트는 아직 소스 코드와 사람 기억에 묶여 있다

프로덕션 프롬프트를 관리하는 공식 체계가 아직 없다는 응답은 47%였다. 소스 코드에 하드코딩한다는 응답이 26%, 버전 관리되는 프롬프트 파일을 쓴다는 응답이 25%였다. 프롬프트 관리 플랫폼은 11%, 기능 플래그로 변형을 관리한다는 응답은 10%였다. 이 항목은 복수 선택이라 합계가 100%를 넘는다.

작은 팀에서 별도 플랫폼을 당장 사야 한다는 뜻은 아니다. 나도 초기에는 프롬프트 파일과 Git 이력만으로 충분하다고 본다. 대신 최소한 어떤 프롬프트가 어떤 모델·도구·평가 결과와 함께 배포됐는지는 재구성할 수 있어야 한다. “어제는 잘 됐는데 오늘은 왜 이러지?”라는 질문에 버전 하나를 못 찾으면 운영 체계가 없는 것과 비슷하다.

이전에 AI 에이전트 루프 설계가 프롬프트를 대체한다고 쓴 것도 같은 이유였다. 좋은 문장 하나보다 종료 조건, 재시도, 승인, 상태 저장이 결과를 더 크게 좌우한다. 이번 설문은 많은 팀이 에이전트를 만들기 시작했지만 그 루프를 관리하는 기반은 아직 얇다는 걸 보여준다.

평가는 수동이고 AI 전용 관측은 비어 있다

AI 모델 평가 방식은 수동 테스트와 프롬프트 반복이 52%로 가장 높았다. 공식 평가 프로세스가 없다는 응답도 36%였다. 자동 평가 스위트를 자체 구축했다는 응답은 17%, 제3자 평가 도구 사용은 7%였다. 여기서도 복수 선택이 가능하니 각 비율은 서로 배타적인 팀 구성이 아니다.

관측은 더 비어 있었다. AI 워크로드를 별도로 모니터링하지 않는다는 응답이 59%였다. 자체 대시보드 20%, OpenTelemetry 9%, Langfuse와 LangSmith가 각각 7%였다. 에이전트 구축 계획 52%와 나란히 놓으면 어색한 장면이다. 실행 주체는 늘어나는데 실패율, 비용, 지연, 도구 호출을 보는 창은 절반 이상에게 없다.

나는 이 지점이 AI 스타트업의 진짜 병목이라고 본다. 모델이 틀린 답을 한 번 내는 건 제품 문제다. 그 오류가 어느 프롬프트와 도구 경로에서 반복되는지 모르는 건 운영 문제다. 후자는 사용자 신고가 들어올 때까지 조용히 비용과 신뢰를 깎는다.

혼자 만들 수 있다는 말과 혼자 팔 수 있다는 말은 다르다

1인 창업자 61%가 개발 진입 장벽의 변화를 보여준다

현재 스타트업의 창업자가 한 명이라는 응답은 61%였다. 창업자가 기술적이지 않다는 응답도 22%였다. 보고서는 응답자 구성이 더 나이가 들고, 더 1인 중심이며, 스스로를 기술적이라고 말하는 비율이 낮아졌다고 요약한다. AI와 관리형 플랫폼이 아이디어를 작동하는 제품으로 바꾸는 비용을 내린 영향이 분명 있어 보인다.

이건 좋은 변화다. 고객 문제를 오래 겪은 운영자가 개발팀을 꾸리기 전에 작은 제품을 검증할 수 있다. 다만 “혼자 제품을 만들 수 있다”는 사실이 “혼자 지속 가능한 회사를 운영할 수 있다”는 뜻은 아니다. 결제, 보안, 장애 대응, 고객 지원, 세일즈까지 동시에 열리면 절약한 개발 시간이 다른 병목으로 이동한다.

첫 고객은 여전히 네트워크와 직접 영업에서 왔다

초기 유료 고객의 출처는 개인·직업 네트워크가 56%로 가장 높았다. 콜드 아웃리치나 영업이 35%, 소셜 미디어 인바운드가 29%, 블로그·뉴스레터·SEO 같은 콘텐츠가 21%였다. Hacker News나 Product Hunt는 6%였다. 제품을 빨리 만드는 도구가 늘어도 첫 매출은 여전히 사람이 신뢰를 빌리고 대화를 여는 과정에서 나온다.

가장 큰 사업 과제도 고객 획득이 32%로 1위였다. 제품 시장 적합성 14%, 펀드레이징 13%, 기술 복잡성과 번아웃이 각각 11%로 뒤를 이었다. 기술 복잡성보다 고객 획득을 어렵다고 답한 비율이 거의 세 배다. “코드가 병목이 아니다”라는 말이 이제는 과장이 아니라 운영 데이터에 가깝다.

나는 여기서 AI 제품의 우선순위를 다시 잡아야 한다고 느꼈다. 모델을 하나 더 붙이는 일보다 첫 고객 인터뷰를 자동으로 놓치지 않는 CRM 흐름, 배포 뒤 실패를 잡는 관측, 고객이 돈을 내는 행동을 측정하는 이벤트가 먼저다. 제품 기능은 데모를 만들지만 운영 루프는 반복 매출을 만든다.

이 설문을 시장 전체의 정답으로 읽으면 안 된다

Supabase가 만든 설문이라는 해석상 한계가 있다

공식 페이지는 응답자 2,000명을 스타트업 빌더라고 설명하지만, 표본 모집 경로와 구성의 상세 방법론은 공개하지 않는다. Supabase가 만든 벤더 보고서인 만큼 데이터베이스와 백엔드 플랫폼을 적극적으로 고르는 개발자·메이커가 일반 스타트업 모집단보다 많이 포함됐을 가능성도 배제하기 어렵다. 그래서 “모든 스타트업의 61%가 코드 절반을 AI로 만들었다”고 일반화하면 곤란하다.

보고서의 질문 가운데 여러 항목은 복수 선택이고, 일부는 응답자의 자기 평가다. 비율 합계가 100%를 넘는 항목을 시장 점유율처럼 읽으면 안 된다. 또 AI 생성 코드 비중이 높을수록 아직 수익화하지 못한 비율이 커 보인다는 차트가 있지만, 이 자료만으로 AI 코드가 수익화를 방해했다고 말할 수는 없다. 초기 팀일수록 AI를 많이 쓰는 제3의 요인이 있을 수 있다.

나는 그래도 이 설문이 쓸모 있다고 본다. 모집단의 절대 비율을 확정하는 자료가 아니라, AI를 빠르게 받아들인 팀에서 어떤 운영 공백이 먼저 드러나는지 보는 선행 신호로는 좋다. 숫자를 예언으로 읽지 않고 점검표로 옮기면 된다.

발표사의 해석과 원자료를 분리해서 봐야 한다

Supabase는 자사 도구 선택이 늘어난 결과도 함께 강조한다. 벤더가 만든 보고서인 만큼 자연스러운 구성이다. 그래서 도구 순위보다 질문별 분포가 더 유용했다. 1인 창업자 비중, 코드 생성 체감, 평가 방식, 관측 부재, 첫 고객 경로는 특정 제품 홍보와 분리해서 읽을 수 있다.

비슷하게 NFX가 최근 AI 래퍼 이후에는 전체 워크플로와 데이터, 세일즈 파이프라인을 소유해야 한다고 주장한 것도 방향을 보는 참고 자료이지 보편 법칙은 아니다. 결국 각 팀은 자기 고객의 구매 과정과 장애 비용으로 다시 검증해야 한다.

작은 팀이 지금 붙여야 할 최소 운영 루프

모델보다 먼저 여섯 가지 증거를 남긴다

내가 1~3명 팀에서 AI 기능을 운영한다면 거창한 플랫폼부터 도입하지 않을 것 같다. 대신 아래 여섯 가지를 배포 조건으로 고정한다.

프롬프트·모델·도구 버전을 한 배포 단위로 기록한다
실패 사례 20개를 고정 평가 세트로 만든다
요청별 지연·비용·도구 오류·재시도를 추적한다
외부 쓰기와 결제·삭제는 사람 승인 뒤에 실행한다
고객이 돈을 낸 경로와 해지 이유를 같은 주기로 본다
매주 기능 수보다 실패율·전환율·지원 시간을 먼저 리뷰한다

이 정도면 전용 프롬프트 관리 제품이나 대형 관측 스택이 없어도 시작할 수 있다. 중요한 건 도구 이름이 아니라 재현 가능성이다. 문제가 생겼을 때 어느 버전이, 어떤 입력에서, 어떤 비용으로, 어떤 잘못된 행동을 했는지 다시 볼 수 있어야 한다.

개발 속도를 매출과 신뢰로 닫는 순서가 필요하다

첫 주에는 한 고객 문제와 한 성공 지표를 정한다. 둘째 주에는 AI 기능을 붙이되 실패 사례를 함께 모은다. 셋째 주에는 로그와 평가, 승인 게이트를 배포 흐름에 넣는다. 넷째 주에는 새 기능 대신 유료 전환과 지원 시간을 본다. 이 순서를 반복하면 AI 개발 속도가 제품 숫자만 늘리는 쪽으로 새는 걸 막을 수 있다.

이번 설문에서 가장 인상적이었던 숫자는 AI 코드 61%가 아니었다. 응답자의 59%가 AI 워크로드를 별도로 모니터링하지 않는다는 쪽이었다. 생성 속도가 두 배가 되면 검증과 판매도 두 배 빨라질 거라고 기대하기 쉽다. 실제로는 검증하지 않은 변경과 팔리지 않은 기능이 두 배 빨리 쌓일 수도 있다.

그래서 2026년 작은 팀의 경쟁력은 코드를 얼마나 많이 생성하느냐보다 생성된 일을 얼마나 빨리 증거로 바꾸느냐에 달린 것 같다. 테스트 통과, 장애 복구, 고객 대화, 결제라는 증거가 남지 않으면 빠른 개발은 아직 사업 성과가 아니다. AI 코드 뒤에 남은 운영 공백을 먼저 닫아야 속도가 진짜 자산이 된다.

Kimi K3 공개, 3조 파라미터보다 먼저 볼 운영 조건

Fri, 17 Jul 2026 03:09:19 +0000

Kimi K3 공개 소식이 오늘 개발자 커뮤니티의 중심에 섰다. 2.8조 파라미터, 100만 토큰 문맥, 네이티브 비전, 장시간 코딩이라는 숫자만 보면 오픈 모델이 한 번에 다음 체급으로 넘어간 느낌이다.

7월 16일 올라온 Kimi 공식 발표는 공개 반나절 만에 Hacker News 1위까지 올라갔다. 7월 17일 12시 KST 기준 HN 토론은 1,244점과 댓글 780개를 기록했고, GeekNews에도 바로 소개됐다. 숫자와 반응만 보면 이번 주 가장 뜨거운 모델 발표가 맞다.

근데 공식 글을 끝까지 읽고 나니 “3조급 오픈 모델이 나왔다”보다 먼저 봐야 할 문장이 여럿 보였다. 가중치는 발표 당일 아직 내려받을 수 없고, 권장 배포 환경은 가속기 64개 이상이며, 100만 토큰 세션도 하네스가 생각 기록을 온전히 넘긴다는 조건이 붙는다. 모델의 크기보다 운영 조건이 더 흥미로운 발표였다.

Kimi K3 오픈 모델에서 실제로 공개된 것

2.8조 전체 파라미터가 매 토큰마다 움직이진 않는다

Kimi K3는 2.8T 규모의 MoE 모델이다. 공식 설명에 따르면 896개 전문가 가운데 16개를 활성화한다. 그래서 2.8조라는 전체 숫자를 매 토큰마다 모두 계산하는 밀집 모델처럼 읽으면 안 된다. 거대한 전문가 풀에서 일부 경로를 선택해 계산하는 구조다.

핵심 구성은 Kimi Delta Attention, Attention Residuals, Stable LatentMoE다. 이름은 화려하지만 방향은 비교적 명확하다. 긴 시퀀스와 깊은 레이어에서 정보가 흐르는 방식을 바꾸고, 전문가 수를 크게 늘리면서도 라우팅과 학습 안정성을 잡으려는 설계다. Kimi는 이 조합이 K2보다 전체 스케일링 효율을 약 2.5배 높였다고 주장한다.

나는 여기서 “파라미터가 많으니 무조건 똑똑하다”보다 “이 크기를 어떻게 실제 서비스 비용으로 바꿨나”가 더 궁금했다. 모델 규모는 발표 한 줄에 들어가지만, 라우터 불균형과 통신 병목은 운영팀 밤샘으로 돌아오기 때문이다. 특히 전문가가 896개까지 늘어나면 좋은 라우팅 하나가 논문 지표와 실제 처리량을 동시에 좌우한다.

오픈이라는 표현과 오늘 내려받을 수 있다는 말은 다르다

공식 글은 Kimi K3를 세계 최초의 공개 3T급 모델이라고 부른다. 동시에 전체 가중치는 2026년 7월 27일까지 공개하고, 기술 보고서도 그때 함께 내놓겠다고 적었다. 즉 발표 당일 기준으로는 Kimi.com, Kimi Work, Kimi Code, API에서 사용할 수 있지만 전체 가중치를 받아 독립 검증하는 단계는 아직 열리지 않았다.

이 차이는 작지 않다. 모델 카드, 라이선스, 텐서 구성, 체크포인트 크기, 로컬·클라우드 런타임 호환성을 확인하기 전까지 “오픈”의 실제 범위를 판단하기 어렵다. 공개 예정과 공개 완료를 섞으면 벤더가 제공한 데모를 독립 재현처럼 말하게 된다.

그래서 내 기준에서 이번 발표는 오픈 모델의 완성보다 공개 약속이 붙은 프리뷰에 가깝다. 약속된 날짜에 가중치와 기술 보고서가 실제로 나오고, vLLM 같은 생태계 구현이 따라붙어야 오픈 모델로서의 두 번째 평가가 시작된다.

벤치마크보다 배포 조건이 먼저 보였다

권장 환경은 개인 워크스테이션이 아니라 슈퍼노드다

Kimi는 K3 추론에 MXFP4 가중치와 MXFP8 활성값을 사용한다고 설명한다. 낮은 정밀도로 계산량과 메모리를 줄이는 방향이다. 그래도 공식 권장 배포 환경은 고대역폭 통신 도메인 안의 가속기 64개 이상이다. 이 한 줄이 2.8조 모델의 현실을 꽤 잘 보여준다.

며칠 전 Bonsai 27B가 휴대폰 메모리 경계에 들어온 조건을 봤을 때는 모델을 어디까지 작게 내려보낼 수 있는지가 핵심이었다. Kimi K3는 반대편 끝에 있다. 한 모델을 얼마나 크게 만들 수 있는지 보여주지만, 직접 배포하려면 개인 개발자나 작은 팀이 감당하기 어려운 통신 구조가 필요하다.

이게 나쁘다는 뜻은 아니다. 오픈 모델은 꼭 노트북에서 돌아야 하는 게 아니다. 클라우드 사업자와 대형 연구팀이 자체 인프라에서 검증하고 최적화할 수 있다는 것만으로도 의미가 있다. 다만 “오픈 모델이니 API 종속에서 바로 벗어난다”는 기대에는 비용표가 빠져 있다.

공식 API 가격은 싸지만 같은 비용으로 재현되진 않는다

Kimi API의 발표 가격은 캐시 적중 입력 100만 토큰당 0.30달러, 캐시 미적중 입력 3달러, 출력 15달러다. 회사는 코딩 워크로드에서 공식 API 캐시 적중률이 90%를 넘는다고 적었다. 숫자만 보면 2.8조 모델의 서비스 가격은 꽤 공격적이다.

근데 이 가격은 Mooncake 기반 분산 추론, 대규모 캐시, 높은 사용률을 전제로 한 사업자 가격이다. 가속기 64개를 직접 묶어 같은 단가를 재현할 수 있다는 뜻은 아니다. 자체 호스팅의 가치는 단순 토큰 가격보다 데이터 경계, 커스텀 런타임, 감사 가능성에서 나와야 한다.

내가 팀에서 검토한다면 API와 자체 배포를 바로 가격으로 비교하지 않을 것 같다. 먼저 민감 데이터가 외부로 나가도 되는지, 장시간 세션을 어느 정도 캐시할 수 있는지, 실패한 요청을 재시도할 때 비용이 얼마나 튀는지부터 본다. 큰 모델은 평균 단가보다 긴 꼬리 비용이 더 무서울 때가 많다.

100만 토큰과 장시간 코딩에 붙은 조건

생각 기록을 잃으면 세션 품질이 불안정해질 수 있다

공식 제한 사항에서 제일 눈에 들어온 건 thinking history였다. K3는 이전 생각 기록을 보존하는 방식으로 학습됐고, 에이전트 하네스가 그 기록을 온전히 다시 넘기지 않거나 세션 중간에 다른 모델에서 K3로 교체하면 생성 품질이 크게 불안정해질 수 있다고 적었다.

100만 토큰 문맥이 있어도 세션 관리가 틀리면 품질이 무너질 수 있다는 얘기다. 긴 컨텍스트는 저장 용량이 아니다. 어떤 메시지와 도구 결과를 남기고, 압축하고, 다시 주입하는지까지 맞아야 한다. 모델이 100만 토큰을 받는다는 사실과 우리 에이전트가 100만 토큰짜리 작업을 안정적으로 끝낸다는 사실은 다르다.

그래서 Kimi는 호환성을 검증한 Kimi Code 같은 하네스를 권장하고 세션 도중 모델 교체를 피하라고 한다. 나는 이 제한을 솔직하게 적은 점은 좋게 본다. 동시에 OpenAI 호환 엔드포인트만 맞추면 기존 에이전트에 모델 이름 하나 바꿔 꽂을 수 있다는 기대에는 선을 긋는다.

과도한 선제 행동은 성능이 아니라 권한 문제다

또 하나의 제한은 excessive proactiveness다. 장시간 어려운 작업을 강조해 학습한 결과, 작은 문제나 모호한 의도를 만났을 때 사용자를 대신해 예상 밖의 결정을 내릴 수 있다고 공식 문서가 경고한다. 시스템 프롬프트나 AGENTS.md에 행동 경계를 더 명시하라는 권고도 붙었다.

이 부분은 실제 운영에서 굉장히 중요하다. 에이전트가 오래 버틴다는 건 좋은 일인데, 멈춰야 할 때도 오래 버티면 사고가 된다. 파일 삭제, 의존성 변경, 외부 API 호출, 배포처럼 되돌리기 비싼 단계는 모델의 자신감이 아니라 별도 승인 게이트로 막아야 한다.

Kimi K3를 코딩 에이전트에 붙인다면 나는 먼저 세 가지를 고정할 것 같다. 변경 가능한 디렉터리, 실행 가능한 명령, 사람이 승인해야 하는 외부 부작용이다. 그리고 세션 중간 모델 교체 금지, 생각 기록 보존 여부, 컨텍스트 압축 시점도 로그에 남긴다. 2.8조 모델을 붙이는 일보다 이 네 줄을 지키는 일이 더 중요하다.

Kimi K3 벤치마크를 읽을 때 남겨둘 의심

하네스가 다르면 모델 점수만 비교하기 어렵다

공식 발표는 DeepSWE, Terminal-Bench, FrontierSWE, 업무 자동화와 멀티모달 평가를 길게 제시한다. DeepSWE 리더보드와 FrontierSWE처럼 외부 기준을 참조한 점은 좋다. 하지만 각 모델이 Kimi Code, Claude Code, Codex 등 서로 다른 하네스로 평가된 항목도 있다.

Kimi도 각주에서 이 조건을 꽤 자세히 밝힌다. 일부 Claude Fable 5 결과는 제3자 평가이며 fallback이 포함될 수 있고, 특정 평가는 모델마다 가장 좋은 하네스를 썼다. 이건 부정행위라는 얘기가 아니다. 에이전트 벤치마크에서 모델과 하네스를 분리하기가 그만큼 어렵다는 뜻이다.

나는 벤치마크 표에서 1점 차이를 읽기보다 같은 저장소, 같은 도구 권한, 같은 시간 제한, 같은 비용 예산으로 다시 돌려보는 편이 낫다고 본다. 특히 K3가 강조한 15시간 커널 최적화나 48시간 칩 설계는 결과물의 정확성뿐 아니라 재현 비용과 사람의 검수 시간도 같이 봐야 한다.

지금 바로 검증할 것은 작은 운영 루프다

가중치 공개 전에는 API나 Kimi Code로 작은 반복 실험부터 할 수 있다. 거대한 데모보다 아래 같은 작업이 더 빨리 현실을 보여준다.

동일한 저장소 이슈를 세 번 실행해 diff 일관성을 본다
30분 세션에서 도구 실패 뒤 복구 성공률을 기록한다
컨텍스트 압축 전후의 테스트 통과율을 비교한다
모호한 요구에서 승인 없이 바꾼 파일 수를 센다
입력 캐시 적중·미적중을 나눠 실제 비용을 계산한다
세션 중 모델 교체를 일부러 시도해 품질 변화를 본다

Artificial Analysis의 Kimi K3 페이지처럼 독립 측정이 쌓이기 시작했지만, 발표 첫날의 숫자는 계속 바뀔 수 있다. 오늘의 1위보다 일주일 뒤 재현 결과가 더 중요하다. 특히 가중치가 예고대로 공개되면 제3자 런타임과 양자화, 실제 메모리, 처리량 데이터가 한꺼번에 나올 가능성이 크다.

3조 파라미터보다 먼저 확인할 것

오픈 모델의 다음 경쟁은 운영 가능성이다

Kimi K3가 별일 아니라는 얘기는 아니다. 2.8조 MoE, 100만 토큰, 네이티브 비전, 장시간 코딩을 한 모델에 묶고 공개 가중치까지 약속한 건 분명 큰 사건이다. Hacker News의 큰 반응도 단순한 숫자 놀음만으로 설명되진 않는다. 많은 개발자가 독점 모델 바깥에서도 최전선 성능을 검증할 선택지를 기다리고 있었다.

동시에 Kimi는 종합 성능이 Claude Fable 5와 GPT-5.6 Sol 같은 강한 독점 모델에 아직 뒤지고, 사용자 경험에도 눈에 띄는 격차가 있다고 공식 제한 사항에 적었다. 발표사가 직접 남긴 이 문장을 빼고 벤치마크 1위 항목만 읽으면 평가가 한쪽으로 기운다.

다만 오늘 확정된 것과 열흘 뒤 확인할 것을 나눠야 한다. 지금 확정된 건 호스팅 제품과 API, 공식 평가, 아키텍처 개요다. 아직 남은 건 전체 가중치, 기술 보고서, 라이선스의 실제 범위, 독립 재현, 64개 이상 가속기 환경의 처리량이다.

내 결론은 꽤 단순하다. Kimi K3는 “누구나 당장 돌리는 3조 모델”이 아니라 “누구나 검증할 수 있는 3조 모델이 될 수 있는가”를 시험하는 발표다. 7월 27일 약속이 지켜지면 오픈 모델의 체급이 실제로 커진다. 그때부터는 파라미터 수보다 배포 비용, 하네스 호환성, 승인 게이트, 재현 가능한 벤치마크가 승부를 가를 것 같다.

Bonsai 27B 휴대폰 구동, 1비트 모델의 실제 조건

Wed, 15 Jul 2026 03:29:01 +0000

Bonsai 27B가 1비트 모델로 줄어 휴대폰에서 돌아간다는 발표가 나왔다. 27B급 모델을 3.9GB에 담았다는 숫자만 보면 로컬 AI의 기준이 갑자기 한 세대 이동한 것처럼 보인다.

실제로 반응도 컸다. 7월 14일 공개된 PrismML 발표는 하루도 안 돼 Hacker News 전면에 올랐다. 2026년 7월 15일 12시 29분 KST 확인 기준 HN 토론은 471점과 댓글 173개를 기록했고, GeekNews에도 바로 소개됐다.

근데 공식 자료를 끝까지 읽어보니 제목의 “휴대폰에서 실행”과 우리가 기대하는 “휴대폰에서 실용적인 AI 에이전트 운영” 사이에는 아직 간격이 있다. 이번 발표는 무시할 만한 데모가 아니다. 동시에 3.9GB라는 숫자만 보고 클라우드 모델 대체를 말하기에도 이르다. 재미있는 지점은 바로 그 사이에 있었다.

Bonsai 27B 1비트 모델이 줄인 것은 무엇인가

54GB 가중치를 3.9GB까지 내렸다

Bonsai 27B는 Qwen3.6-27B를 기반으로 한다. PrismML은 전체 아키텍처를 바꾸는 대신 트랜스포머 가중치를 이진 또는 삼진 표현으로 학습했다. 1비트 버전은 -1과 +1, 삼진 버전은 -1, 0, +1을 사용하고 그룹별 FP16 스케일을 함께 둔다.

회사가 공개한 1비트 모델 카드와 백서를 기준으로 보면 차이는 꽤 크다.

모델	실효 비트/가중치	이상적/배포 크기	15개 벤치마크 평균
Qwen3.6-27B FP16	16.0	54GB	85.07
Qwen3.6-27B 일반 4비트	5.2	17.6GB	84.99
Ternary Bonsai 27B	1.71	5.9GB 이론값 / 약 7.2GB GGUF	80.49
1-bit Bonsai 27B	1.125	약 3.9GB GGUF	76.11

여기서 “1비트”를 파일의 모든 값이 정확히 1비트라는 뜻으로 읽으면 안 된다. 그룹별 스케일 같은 메타데이터가 들어가 실제 평균은 가중치당 1.125비트다. 그래도 54GB짜리 FP16 가중치를 3.9GB까지 줄인 건 분명 큰 변화다. 모델 파일을 저장할 수 있는 장치가 아니라, 메모리에 올려 실제 추론할 수 있는 장치의 범위가 넓어진다.

삼진 모델의 5.9GB도 현재 내려받는 파일 크기는 아니다. 1.71비트 표현의 이론적 크기이고, 현재 GGUF는 삼진 값을 2비트 슬롯에 저장해 실제 배포 파일이 약 7.2GB다. 반면 1비트 GGUF는 네이티브 1비트 레이아웃을 사용해 이론값과 배포 크기가 약 3.9GB로 같다.

3.9GB는 실행 중 최대 메모리가 아니다

내가 처음 숫자를 보고 가장 먼저 확인한 것도 이 부분이었다. 가중치가 3.9GB라고 해서 앱이 딱 3.9GB만 쓰는 건 아니다. KV 캐시, 활성값, 런타임 버퍼가 더 필요하다.

공개된 측정에서 1비트 GGUF 버전은 4K 컨텍스트에서 약 5.2GB, 10K에서 약 5.6GB, 100K에서 약 11.6GB의 최대 메모리를 사용한다. MLX 버전도 비슷한 방향이다. 4비트 KV 캐시를 켜면 긴 컨텍스트 부담을 크게 줄일 수 있지만, “262K 컨텍스트 지원”과 “휴대폰에서 262K를 넉넉하게 운용”은 같은 문장이 아니다.

iOS는 단일 앱에 물리 메모리 전부를 내주지 않는다. 백서는 12GB 메모리의 iPhone에서도 앱이 쓸 수 있는 예산을 약 6GB로 잡는다. 그래서 실제 배포 크기가 약 7.2GB인 삼진 GGUF 버전은 휴대폰이 아니라 노트북용이고, 3.9GB 1비트 버전만 고성능 iPhone의 실행 예산 안에 들어간다. 결국 이번 성과의 첫 번째 의미는 “27B 모델이 휴대폰 메모리 문턱을 넘었다”다. 긴 대화와 비전 입력까지 마음껏 처리한다는 뜻은 아직 아니다.

휴대폰에서 돌아간다는 말의 범위를 봐야 한다

iPhone 측정은 11토큰/초, 데모에는 조건이 붙었다

PrismML은 iPhone 17 Pro Max에서 약 11토큰/초, 프롬프트 처리 약 111토큰/초를 측정했다고 밝혔다. 사람이 읽으며 대화하는 용도라면 생성 속도 자체는 답답하지 않을 수 있다. 네트워크가 없는 곳에서 문서 요약이나 짧은 질의응답을 처리하는 그림도 이제 꽤 현실적으로 보인다.

다만 발표 페이지의 휴대폰 비전 데모 캡션에는 Cached & Prefilled Image Context라는 조건이 명시돼 있다. 이미지 컨텍스트를 미리 채우고 캐시한 데모라는 뜻이다. 이 영상 하나만으로 앱 시작부터 이미지 전처리, 긴 프롬프트 입력, 첫 토큰 지연, 발열과 배터리, 여러 차례 도구 호출까지 모두 실시간으로 검증됐다고 말할 수는 없다.

이런 조건을 숨긴 발표는 아니다. 오히려 캡션에 적어둔 점은 괜찮다. 다만 “휴대폰에서 실행됐다”는 사실과 “일반 사용자가 어떤 입력이든 바로 넣어 쓸 수 있다”는 제품 경험을 분리해서 봐야 한다. 나는 전자는 통과했다고 본다. 후자는 실제 앱과 독립 측정이 더 필요하다.

평균 89.5% 유지에도 약한 구간은 남는다

회사가 공개한 벤치마크에서 1비트 버전은 FP16 평균의 89.5%를 유지했다. 숫자 하나만 보면 꽤 놀랍다. 하지만 항목별로 보면 압축 비용이 고르게 생기지 않는다.

수학 평균은 95.3에서 91.7, 코딩은 88.7에서 81.9로 내려갔다. 에이전트·도구 호출은 80.0에서 66.0, 비전은 72.6에서 59.6으로 더 크게 떨어졌다. 바로 휴대폰 에이전트에서 기대할 만한 기능이 더 큰 영향을 받았다.

백서도 이 부분을 인정한다. 장기 도구 사용, 여러 파일 수정, 테스트와 복구를 반복하는 에이전트 코딩은 이번 릴리스가 강하게 겨냥한 영역이 아니며 별도 튜닝 모델을 로드맵에 올려뒀다. 게다가 벤치마크는 PrismML이 같은 평가 하네스로 H100에서 수행한 결과다. 비교 조건을 맞춘 점은 좋지만, 아직 제3자의 폭넓은 재현 결과로 보기는 어렵다.

그래서 내 결론은 “성능 손실이 없는데 14배 작아졌다”가 아니다. “성능 손실을 감수해도 쓸 만한 27B급 모델이 처음으로 휴대폰 메모리 안에 들어왔다”에 가깝다. 표현은 덜 화려하지만 실제로는 이쪽이 더 중요한 진전이라고 생각한다.

로컬 AI 운영에서 바뀌는 선택지

전부 로컬보다 로컬과 클라우드의 역할 분리가 현실적이다

이전에 로컬 AI 모델이 다시 개발자 운영 선택지가 된 이유를 쓰면서 작은 반복 작업과 민감한 데이터 처리를 로컬로 내리고, 어려운 추론은 클라우드로 보내는 구성을 얘기했다. Bonsai 27B는 그 경계를 한 번 더 아래로 내린다. 노트북뿐 아니라 휴대폰도 로컬 처리 노드가 될 수 있기 때문이다.

예를 들어 개인 메모 분류, 오프라인 초안, 짧은 문서 요약, 로컬 사진 설명처럼 네트워크로 보내기 꺼려지는 작업은 매력적이다. 반대로 저장소 전체 리팩터링, 긴 도구 호출 루프, 중요한 보안 판단은 아직 상위 클라우드 모델이나 더 큰 로컬 모델로 넘기는 편이 낫다.

여기서 기대되는 건 모델 하나의 승리가 아니라 라우팅 선택지다. 휴대폰의 1비트 모델이 입력을 분류하고 민감한 전처리를 맡는다. 노트북의 삼진 모델이 조금 더 복잡한 로컬 작업을 처리한다. 정말 어려운 단계만 원격 모델로 보낸다. 이런 구조라면 비용과 데이터 이동을 줄이면서도 품질을 포기하지 않을 수 있다.

내가 실제로 확인할 것은 벤치마크보다 운영 지표다

모델은 Apache 2.0 라이선스로 공개됐고, Bonsai 27B 모델 모음에는 GGUF와 MLX 변형이 올라와 있다. 공식 데모 저장소도 실행 스크립트와 메모리 표를 제공한다. 재현을 시작할 재료는 갖춰진 셈이다.

그래도 도입 판단은 다음처럼 단순한 작업 묶음으로 직접 돌려보는 편이 맞다.

앱 시작부터 첫 토큰까지 걸린 시간을 잰다
4K와 10K 컨텍스트에서 최대 메모리를 비교한다
같은 프롬프트를 20회 반복해 답변 흔들림을 본다
JSON 도구 호출 성공률을 별도로 기록한다
15분 연속 실행 뒤 발열과 배터리 소모를 확인한다
실패한 작업만 클라우드 모델로 넘긴다

특히 “휴대폰에서 돌아간다”는 주장은 발열과 지속 성능을 빼면 반쪽짜리다. 짧은 데모에서 11토큰/초가 나와도 20분 뒤 속도가 유지되는지는 다른 문제다. 앱이 백그라운드로 갔다 돌아왔을 때 모델을 다시 올리는 시간, 다른 앱과 메모리를 다툴 때 종료되는지도 봐야 한다.

3.9GB가 보여준 진짜 변화

모델 크기보다 배치 위치가 달라졌다

Bonsai 27B를 보며 가장 크게 느낀 건 최고 성능 경쟁보다 배치 위치의 변화였다. 27B급 모델은 원래 고사양 PC나 서버에 두는 물건이었다. 이제 적어도 1비트 버전은 고성능 휴대폰의 메모리 경계 안으로 들어왔다. 그 자체로 제품 설계의 선택지가 생긴다.

아직 냉정하게 볼 부분도 많다. 공개 성능은 회사 자체 측정이고, 휴대폰 데모는 캐시된 입력 조건이며, 에이전트·비전 점수 손실은 작지 않다. 장기 코딩 에이전트는 공식 문서에서도 다음 과제로 남아 있다. 그래서 오늘 당장 클라우드 API를 지울 이유는 없다.

그렇다고 “품질이 조금 떨어진 양자화 모델” 정도로 넘기기에도 아깝다. 메모리에 아예 들어가지 않던 모델은 성능을 비교할 기회조차 없다. 3.9GB는 완성의 숫자가 아니라 실행 가능성의 숫자다. 이제부터 중요한 건 독립 재현과 실제 앱이다. 어떤 휴대폰에서 얼마나 오래 버티는지, 긴 컨텍스트와 도구 호출이 어디서 무너지는지, 그 결과가 확인되면 로컬 AI의 기본 배치도 정말 달라질 수 있다.

Grok Build 저장소 전송 분석, 코딩 에이전트 경계 다시 보기

Mon, 13 Jul 2026 03:10:15 +0000

Grok Build 저장소 전송 분석이 오늘 개발자 커뮤니티에서 꽤 크게 번졌다. 독립 연구자가 grok 0.2.93의 네트워크 트래픽을 캡처했더니, 에이전트가 읽은 파일뿐 아니라 Git 이력을 포함한 저장소 묶음도 별도 스토리지 경로로 전송됐다는 내용이다.

처음엔 나도 “클라우드 코딩 에이전트가 코드를 서버에 보내는 게 당연한 것 아닌가” 싶었다. 맞는 말이다. 모델이 원격에 있으면 작업에 필요한 코드 문맥은 나가야 한다. 근데 필요한 문맥과 저장소 전체는 같은 말이 아니다. 특히 .env, 과거 커밋, 에이전트가 열지 않은 파일까지 범위가 넓어지면 이건 성능보다 운영 경계의 문제다.

Grok Build 저장소 전송 분석에서 확인된 것

0.2.93 한 버전의 재현 가능한 관측이다

이번 논란의 1차 소스는 독립 연구자 cereblab의 와이어 수준 분석이다. 테스트 대상은 Apple Silicon용 grok 0.2.93이고, 실제 자격 증명 대신 가짜 canary 문자열을 넣은 throwaway 저장소를 썼다. mitmproxy로 요청 경로, 상태 코드, 바이트 수를 잡고 로컬 업로드 큐도 풀어서 확인했다.

보고서가 주장하는 핵심은 두 갈래다. 하나는 에이전트가 읽은 파일 내용이 모델 요청인 /v1/responses로 전송됐다는 것. 다른 하나는 추적 파일과 Git 이력을 묶은 저장소 아카이브가 /v1/storage를 통해 업로드됐다는 것이다. 테스트용 .env 값은 모델 요청과 session_state 아카이브에서 모두 확인됐다고 적었다.

12GB 무작위 파일 저장소 실험에서는 모델 요청이 약 192KB였던 반면, 스토리지 전송은 캡처를 중단한 시점까지 5.10GiB에 도달했다. 다만 전체 12GB가 끝까지 전송됐다고 입증한 건 아니다. 분석자가 이 한계를 직접 적어둔 점은 오히려 신뢰를 높인다. 센 숫자만 떼어 모든 저장소를 끝까지 업로드한다고 말하면 원문보다 더 나간 주장이다.

전송과 학습 사용은 구분해야 한다

더 중요한 제한도 있다. 이 분석은 데이터가 전송되고 서버가 HTTP 200으로 수락한 것까지 보여준다. 그 데이터가 모델 학습에 쓰였다는 사실은 입증하지 않는다. “Improve the model” 설정을 꺼도 trace 관련 업로드 플래그가 유지됐다는 관측과, 실제 학습 사용 여부는 별개의 문제다.

xAI의 개인정보 처리방침은 서비스에서 수집·사용하는 개인정보와 비즈니스 상품의 고객 데이터 처리 범위를 구분한다. 하지만 정책 문서만 읽어서는 특정 CLI 버전이 어떤 파일을 어떤 엔드포인트로 보내는지 알기 어렵다. 반대로 패킷 캡처 하나만으로 모든 계정 유형과 조직 정책을 일반화할 수도 없다. 정책과 실제 동작을 같이 봐야 하는 이유다.

왜 이 논란이 코딩 에이전트 보안 문제인가

“읽을 수 있음”과 “전송해도 됨”은 다르다

코딩 에이전트는 저장소를 읽어야 일한다. 문제는 개발자 노트북의 저장소가 코드만 담고 있지 않다는 데 있다. 오래된 커밋에는 삭제한 키가 남을 수 있고, 테스트 fixture에는 고객과 비슷한 형태의 데이터가 들어가며, 로컬 설정에는 내부 호스트와 계정명이 섞인다. 현재 워킹 트리가 깨끗해 보여도 Git 이력까지 묶으면 노출 범위가 확 커진다.

그래서 권한을 “이 디렉터리를 읽을 수 있다” 하나로 끝내면 안 된다. 파일 읽기, 모델 문맥 전송, 세션 보관, 진단 trace 업로드, 제품 개선 사용은 서로 다른 목적이다. 사용자 화면에서 토글 하나로 뭉쳐 보이더라도 운영팀은 별도 경계로 봐야 한다.

이전에 쓴 Agentjacking이 AI 코딩 에이전트 보안을 흔들었다에서는 외부 도구 출력이 실행 지시로 승격되는 문제를 다뤘다. 이번 건은 방향이 반대다. 외부 입력이 안으로 들어오는 대신, 내부 저장소가 에이전트의 부가 기능을 타고 밖으로 나갈 수 있다. 둘 다 본질은 같다. 모델의 지능보다 데이터와 권한의 이동 경로가 먼저다.

공식 최신 버전과 분석 버전을 섞지 말아야 한다

xAI는 2026년 5월 Grok Build를 터미널 코딩 에이전트로 공개했고, 공식 변경 기록은 7월 12일 기준 v0.2.98을 최신으로 표시한다. 논란의 분석 대상은 v0.2.93이다. 버전이 이미 다르다.

이 차이를 두고 “옛 버전 얘기니 끝”이라고 말하는 것도 성급하고, “최신 버전도 무조건 똑같다”고 말하는 것도 성급하다. 팀이 해야 할 일은 간단하다. 설치된 버전을 고정하고, 같은 테스트 저장소와 가짜 canary로 최신 버전의 전송 범위를 다시 확인하는 것이다. 공식 변경 기록에 보안 관련 수정이 보이면 적용하고, 보이지 않으면 공급사에 동작 범위와 보존 정책을 직접 묻는 편이 낫다.

팀에서 바로 확인할 코딩 에이전트 경계

저장소를 열기 전에 노출 자산부터 센다

나는 새 코딩 에이전트를 팀 저장소에 붙일 때 기능 데모보다 먼저 노출 자산 목록을 보는 게 맞다고 생각한다. 아래 정도는 로컬에서 바로 확인할 수 있다.

# 현재 Git이 추적하는 파일 범위
git ls-files

# 무시되는 파일 중 로컬에 남아 있는 민감 후보
git ls-files --others --ignored --exclude-standard

# 최근 이력에 환경 변수나 키 파일이 들어간 적이 있는지 점검
git log --all --name-only --pretty=format: | sort -u

이 명령이 안전을 보장하진 않는다. 그래도 “에이전트가 지금 보는 폴더”와 “저장소에 실제로 들어 있는 자산”이 다를 수 있다는 건 금방 드러난다. .env를 .gitignore에 넣었다고 끝이 아니다. 예전 커밋, 서브모듈, 생성물, 홈 디렉터리의 공용 설정까지 따로 봐야 한다.

그다음엔 테스트 저장소를 만든다. 실제 키 대신 식별 가능한 canary 문자열을 넣고, 에이전트가 읽어야 하는 파일과 읽지 말아야 하는 파일을 나눈다. 프록시나 호스트 방화벽 로그로 목적지와 전송량을 확인한다. 이 과정 없이 고객 저장소부터 여는 건 너무 비싸게 배우는 방식이다.

샌드박스와 네트워크 허용 목록을 같이 쓴다

이번 Hacker News 토론은 확인 시점에 406점과 158개 댓글이 붙었다. 반응 중 가장 현실적이었던 건 “코딩 도구를 별도 샌드박스에 넣고, 프로젝트 디렉터리만 보여주며, 네트워크도 필요한 모델 호스트로 제한한다”는 운영 방식이었다.

파일 샌드박스만 쓰면 읽을 수 있는 범위는 줄지만, 허용된 파일이 어디로 전송되는지는 통제하지 못한다. 네트워크 허용 목록만 쓰면 목적지는 줄지만, 에이전트가 홈 디렉터리 전체를 읽는 문제는 남는다. 둘을 같이 써야 실패 반경이 작아진다.

조직용 제품이라면 감사 로그도 필요하다. 어떤 세션이 어떤 저장소에서 시작됐는지, 어느 도메인으로 몇 바이트가 나갔는지, 세션 아카이브가 얼마 동안 보관되는지 확인할 수 있어야 한다. “우리는 학습에 쓰지 않는다”는 문구만으로는 사고 조사에 부족하다. 전송, 저장, 보존, 삭제를 각각 증명할 수 있어야 한다.

이번 논란을 과장 없이 받아들이는 법

공급사 답변 전까지는 검증된 범위만 말한다

GeekNews의 한국어 요약도 이 사건을 빠르게 전달했지만, 핵심은 원문이 적어둔 한계까지 같이 읽는 것이다. 특정 버전, 특정 소비자 계정, 특정 운영체제에서 재현됐다. 모든 설정 조합을 시험하지 않았고, 모델 학습 사용도 입증하지 않았다. 이 선을 지키면 글이 덜 자극적이어도 훨씬 쓸모 있다.

내 판단은 이렇다. 이번 분석만으로 Grok Build 전체를 악성 도구라고 부를 근거는 부족하다. 반대로 클라우드 코딩 에이전트는 원래 코드를 보내니까 괜찮다고 넘길 일도 아니다. 저장소 전체와 Git 이력이 별도 trace 경로로 이동한다면 사용자가 예상하는 최소 문맥 전송을 넘어설 수 있다. 제품은 그 차이를 명확히 설명해야 한다.

결국 팀이 소유해야 할 건 경계와 증거다

코딩 에이전트가 강해질수록 설치는 더 쉬워지고, 경계 확인은 더 어려워진다. 한 줄 설치 뒤에 파일 접근, 명령 실행, 네트워크 전송, 세션 저장이 한꺼번에 붙는다. 편한 UX가 위험하다는 뜻은 아니다. 편한 UX일수록 운영 증거를 별도로 남겨야 한다는 뜻이다.

지금 Grok Build를 쓰고 있다면 먼저 버전을 확인하고 실제 저장소 대신 테스트 저장소에서 재현하는 게 맞다. 고객 코드나 운영 키가 있는 환경이라면 공급사의 공식 설명과 수정 여부가 확인될 때까지 읽기 범위와 네트워크를 제한하는 편이 안전하다.

나는 이번 이슈를 “또 AI가 위험하다”는 뉴스로 소비하고 싶지 않다. 오히려 코딩 에이전트를 팀 도구로 들일 때 무엇을 검증해야 하는지 아주 구체적으로 보여준 사례에 가깝다. 모델 비교표보다 먼저 볼 건 저장소 경계다. 그리고 그 경계는 프롬프트가 아니라 파일 시스템, 네트워크, 로그로 증명해야 한다.