AI 경쟁의 병목은 모델 밖으로 옮겨가고 있다

Cursor 뉴스가 보여준 것: 모델 선택은 공급망 의존성이다

Cursor는 2026년 8월 14일 SpaceX의 일부가 됐다고 발표했다. 이어 OpenAI는 8월 28일 SpaceX에 Cursor로의 자사 모델 공급 계약을 종료할 의사를 통보했다고 밝혔다. OpenAI가 제안한 공급 중단일은 11월 12일이다.

여기서 확인된 사실은 Cursor 서비스 전체의 종료가 아니다. OpenAI 모델 공급 계약을 종료하려는 의사와 제안된 일정이며, Cursor에는 자체 모델과 다른 공급자 모델이 존재한다. 따라서 ‘Cursor를 더 이상 쓸 수 없다’거나 ‘모든 모델이 사라진다’고 확대 해석해서는 안 된다.

다만 모델을 바꾸는 일이 단순히 메뉴에서 다른 항목을 고르는 일로 끝나지는 않을 수 있다. 프롬프트, 프로젝트 규칙, 자동 실행 흐름, 코드 리뷰 기준이 특정 모델의 동작 특성에 맞춰져 있다면 결과물의 수정 범위·속도·비용이 달라질 수 있다. 도구 이름뿐 아니라 실제 모델 공급자와 인증·과금 경로를 의존성 목록에 기록해야 하는 이유다.

• 통합 제공 모델인지, 직접 API 키를 쓰는 방식인지 구분한다.
• 대체 모델과 승인 담당자, 비용 상한을 함께 기록한다.
• 도구 전용 설정은 저장소 문서와 자동 테스트로 옮긴다.

EDITOR'S NOTE11월 12일은 Cursor 서비스 종료일이 아니라 OpenAI가 제안한 모델 공급 종료 시점이다.

대체 모델 검증은 ‘선택’이 아니라 복구 훈련이다

모델 공급 경로가 바뀔 가능성에 대비하려면 최근 자주 수행한 대표 과제부터 고르는 편이 좋다. 예를 들어 로그인 버그 수정, 테스트 생성, 대규모 리팩터링처럼 결과를 확인할 수 있는 작업을 하나씩 선정한다. 같은 저장소와 지시, 같은 테스트 조건에서 현재 모델과 대체 모델을 비교해야 한다.

비교 결과는 단순한 만족도보다 완료 여부와 복구 비용에 초점을 맞춘다. 테스트 통과 여부, 사람이 고친 시간, 잘못 수정된 파일 수, 실제 비용을 남기면 전환 논의를 추측이 아닌 기록으로 할 수 있다. 한 번의 실험이 모든 업무를 대표하지는 않으므로, 결과를 일반화하지 않는 태도도 필요하다.

중요한 것은 대체 모델이 존재한다는 사실보다 해당 모델로 업무를 끝까지 통과시킬 수 있는지다. 실패했을 때 어느 체크포인트에서 재개할지, 누가 새 모델 사용을 승인할지까지 정리하면 공급망 이슈는 운영 계획이 된다. 서비스 중단을 전제로 단정하기보다 사전 점검으로 대응하는 접근이다.

• 대표 과제 1개를 대체 모델로 끝까지 실행한다.
• 완료율·수정 시간·비용·실패 원인을 남긴다.
• 기존 작업의 재개 지점과 의사결정 담당자를 정한다.

MCP의 다음 과제는 연결 수보다 장기 작업의 추적성이다

MCP 로드맵은 단발성 도구 호출을 넘어 장기 작업, 중간 개입, 에이전트 신원과 기업 보안으로 관심을 넓히고 있다. 2026년 7월 사양에는 더 가벼운 세션 구조, 서버 버전과 기능을 확인하는 discovery, 캐시 가능한 목록 결과가 포함됐다. 장기 실행 작업을 위한 Tasks는 공식 확장으로 이동했다.

장기 작업에서는 요청을 보낸 뒤 결과를 기다리는 것만으로 충분하지 않다. 진행 상태를 확인하고, 작업 방향을 조정하고, 연결이 끊긴 후 안전하게 재개할 수 있어야 한다. 로드맵이 제시한 에이전트 메시징, HTTP 전송 통합, 신원과 보안은 이런 운영 문제와 맞닿아 있다.

이는 MCP가 곧바로 모든 장기 작업 문제를 해결한다는 뜻은 아니다. 프로토콜 기능과 별개로 각 팀은 중복 실행 방지, 승인 흐름, 결과 검증을 설계해야 한다. 새 기능을 기다리기 전에 현재 자동화가 어디에서 멈추고 어떻게 재개되는지부터 확인할 수 있다.

• task_id로 업무 단위를 식별한다.
• 대기·수집·검토·완료·실패 상태를 구분한다.
• 장기 작업의 진행 기록과 재개 기준을 남긴다.

장기 자동화에는 다섯 가지 운영 계약이 필요하다

매일 밤 고객 문의를 모아 아침 보고서를 만드는 자동화를 생각해 보자. 실행 시간이 길어질수록 단순 요청·응답 방식은 중복 발송과 작업 유실을 만들기 쉽다. 이때 필요한 첫 번째 계약은 같은 요청이 반복돼도 결과를 중복 처리하지 않게 하는 task_id다.

두 번째와 세 번째는 상태와 재개 지점이다. 수집·요약·검토 단계 중 어디에서 멈췄는지 보여야 하며, 자료 20개 중 15개를 처리한 뒤 끊겼다면 16번째부터 이어갈 수 있어야 한다. 처음부터 재실행하는 방식은 비용과 오류 가능성을 함께 높일 수 있다.

네 번째는 권한 분리, 다섯 번째는 증거 보존이다. 읽기와 외부 발송 권한을 분리하고, 발송처럼 되돌리기 어려운 행동에는 사람 승인을 두는 편이 안전하다. 사용 자료, 제외 항목, 생성 파일, 검토 결과를 남겨야 나중에 결과가 틀렸을 때 원인을 확인할 수 있다.

• task_id
• 상태
• 재개 지점
• 권한
• 완료 증거

EDITOR'S NOTE다섯 칸 중 빈칸이 있다면 자동화 범위를 늘리기 전에 그 운영 공백부터 메우는 편이 낫다.

AI 사이버 방어 서한은 ‘예언’이 아니라 지금의 보안 부채를 줄이라는 요구다

OpenAI, Anthropic, Google, Microsoft 등을 포함한 100곳 이상의 조직은 AI 사이버 방어 역량을 높이자는 공개서한에 서명했다. 서한은 향후 몇 달 동안 AI를 이용한 공격이 더 넓고 정교해질 수 있다고 전망하며, 인력과 예산이 부족한 필수 서비스의 위험을 언급한다. 이는 서명 조직의 전망이지 발생 시점이 확정된 사건은 아니다.

공개서한의 제안은 기존 보안 수준의 한계를 인정하고, 방어자에게 AI 도구와 검증된 수정 방법을 제공하며, 기업과 정부가 위협 정보와 대응 자원을 함께 움직이자는 것이다. 실무에서는 오래된 취약점, 과도한 권한, 잘못된 설정, 미패치 소프트웨어를 우선적으로 다루라는 요구로 읽을 수 있다. AI가 생성한 코드도 예외 없이 테스트와 보안 검사를 통과해야 한다.

서한 자체가 조직별 강제 일정이나 정량 투자 약속을 제시한 것은 아니다. 후속 보도에서는 서명 수보다 실제 배포 대상, 취약점 수정 속도, 수정 후 재검증 비율을 보는 편이 더 중요하다. 외부 연결을 늘리는 자동화일수록 최소 권한과 승인 절차를 먼저 적용해야 한다.

• 읽기만 필요한 연결에 쓰기 권한이 없는지 확인한다.
• AI 생성 코드에 테스트와 보안 검사를 적용한다.
• 취약점 수정 뒤 실제로 닫혔는지 재검증한다.