2026년 10월 14일 AI 코딩 소식

API 로 옮길 계획이면 12월 1일 정가(입력 4달러·출력 20달러)로 비용을 잡고, temperature 가 무시되고 명시적 컨텍스트 캐시를 쓸 수 없다는 점, 6만 4천 토큰을 넘는 출력은 백그라운드 실행과 15분 이상의 HTTP 제한 시간이 필요하다는 점을 먼저 확인하세요. 개인 계정으로 안티그래비티에서 쓰려면 Pro 가 아니라 Ultra 구독이 필요해요.

Scion 을 따라 할 대상으로 보기보다, 에이전트가 사람보다 훨씬 자주 체크아웃·병합하면 git 미러와 전체 체크아웃 방식이 먼저 한계에 닿는다는 신호로 읽는 게 좋아요. 에이전트 CI 를 늘리고 있다면 희소 체크아웃(sparse checkout)이나 API 조회로 로컬 저장소 없이 끝낼 수 있는 작업부터 골라 보세요.

확인된 사실은 30달러도 안 되는 개발 보드가 AI 연구소 임원 회의실에 꽂혀 있었다는 점, 그리고 검찰이 피의자의 AI 도구 질의 기록을 증거로 내세웠다는 점이에요. 사내에서 쓰는 AI 에이전트·챗봇 질의도 회사 기록으로 남아 조사에 쓰일 수 있다는 전제로 사용 정책과 기록 보관 범위를 점검해 둘 만해요.

Business·Enterprise 는 관리자가 기본값을 꺼 두지 않았다면 새 모델이 자동으로 켜지니, 막아야 하는 조직은 코파일럿 설정의 모델 정책을 먼저 확인하세요. 연간 결제로 묶인 기존 Pro·Pro+ 는 새 모델을 받지 못한다고 문서에 적혀 있고, 할인가가 12월 1일에 끝나니 그 뒤 비용은 다시 확인해야 해요.

커서에서 클로드나 GPT 를 주로 쓴다면 새 요금제의 사용량 배수는 사실상 그록 모델 몫이라, 옮기기 전에 최근 사용 기록에서 다른 회사 모델 비중부터 확인하고 지출 상한을 걸어 두세요. 기존 프로·프로+ 구독을 언제까지 유지할 수 있는지는 아직 공지가 없으니, 연간 결제 갱신은 공지를 본 뒤 정하는 편이 안전해요.

급한 정책 변경을 모든 기기에 확실히 걸 수 있지만, 그 대가로 깃허브 접속이 안 되는 순간 VS Code 에서는 코파일럿이 통째로 멈춰요. 오프라인 작업이나 사내망 장애가 잦은 팀이면 켜기 전에 공지하고, 이미 sandbox 키를 쓰고 있다면 버전을 고정해 둔 개발자 기기가 최소 버전 아래인지 먼저 확인하세요.

공식 발표가 대상 도구로 이름을 댄 것은 구글 AI 스튜디오뿐이고 한국이 출시 시장에 들어가는지는 확인되지 않았어요. 지금 단계에선 만든 사람 혼자만 쓸 수 있으니 사내 배포 수단이 아니라 개인 실험용으로 보고, 팀에 퍼뜨릴 앱은 기존 개발자 계정과 심사를 거치는 쪽으로 계획하는 게 맞아요.

어느 정도를 '되풀이'로 보는지, 한도가 얼마나 낮아지는지는 글에 없어요. 에이전트나 로그 수집 단계에 이전 추론을 그대로 다시 적거나 번역하게 하는 지시가 있다면 지금 빼 두세요. 또 문서상 소네트 5.5·하이쿠 5.5 의 thinking 블록은 만든 계정이나 연결된 계정에서만 쓰이고 다른 계정에서는 오류 없이 빠지니, 여러 조직 키로 대화를 이어 붙이는 구조라면 응답 품질이 바뀌지 않는지 확인하세요.

Origin 을 시험 중인 팀이라면 깃허브에서 쓰던 CI·리뷰·보안 도구가 마켓플레이스 목록에 있는지 먼저 확인해 보세요. API 가 초기 베타라 연동 앱을 직접 만든다면 바뀔 수 있다는 전제로 운영 배포 흐름과 떼어 두는 편이 안전해요.

앤트로픽 키를 쓰는 팀이라면 일반 API 키 말고 서비스 계정 키와 사용자 키도 이제 푸시 단계에서 막힌다는 점을 알아 두세요. 다만 깃허브 문서상 저장소 단위 푸시 보호는 GitHub Secret Protection 이 있어야 하고 기본으로 꺼져 있으니, 조직의 비공개 저장소는 설정을 직접 확인하세요. 두 키는 유효성 검사가 없어서 경고가 뜨면 키가 아직 살아 있는지 앤트로픽 콘솔에서 직접 확인하고 폐기해야 해요.

사내 MCP 서버에서 작은 모델이 자주 틀린다면 모델을 바꾸기 전에 서버 응답부터 보세요. 목록 응답에 전체 개수와 다음 페이지 여부를 넣고, 필터는 서버에서 처리하고, 이름으로도 조회하게 하고, 오류 메시지에 고치는 방법을 적는 것이 이 실험에서 효과를 본 항목이에요. 다만 한 회사의 한 영역 실험이라 자기 서버에서 직접 재 보는 것이 먼저예요.

게임이 아니어도 GUI·시뮬레이션처럼 결과가 코드 밖에 드러나는 시스템이라면, 에이전트에게 코드를 더 읽히기보다 상태 재현·명령 재생·텍스트로 된 측정값부터 마련하는 편이 반복을 빠르게 해요. 다만 HN 에서는 한 덩어리 객체 구조가 큰 게임에선 버티지 못한다는 반론도 나왔으니 규모에 맞춰 골라 쓰세요.

같은 해결률에서도 모델마다 덧붙이는 코드가 40%가량 차이 나니, 에이전트 도입 후 리뷰 부담이 늘었다면 해결률 대신 변경량도 함께 보고 모델을 고를 만해요. 다만 이 수치는 크기만 재고, 해결 여부는 원 벤치마크 결과를 그대로 가져온 것이라 자기 코드베이스의 리뷰 결과로 다시 확인해야 해요.

두 글쓴이 모두 일을 맡기면 배울 기회를 잃을 수 있다는 점에는 동의해요. 팀에서 에이전트를 쓸 때 결과만 받아도 되는 일과, 사람이 직접 읽고 검토하며 이해를 쌓아야 하는 일을 종류별로 나눠 두면, 히키의 우려와 반론이 말하는 '감독 있는 사용'을 함께 실무 규칙으로 옮길 수 있어요.