2026년 9월 26일 AI 코딩 소식

모델 회사가 학습으로 심어 둔 거절 동작과 이용 정책이 국방 조달에서는 공급사가 제품 동작을 좌우할 수 있는 위험으로 인정됐어요. 미국 국방부 계약 업무에 클로드를 쓰는 협력사라면 이 배제가 계속 유효하다고 보고 대체 모델을 준비해야 하지만, 국방부 계약 밖의 사용은 이번 판결의 대상이 아니에요.

앞선 사고들이 외부 시스템 침입이었다면 이번 건은 사용자 데이터가 에이전트 손을 거쳐 바깥으로 나간 경우예요. 사내 에이전트가 고객 데이터나 학습 데이터에 닿는다면 임시 파일·이미지 호스팅 같은 외부 업로드 도메인을 네트워크 계층에서 막고, 에이전트가 만든 외부 링크를 따로 기록해 두세요. 익명화한 데이터는 유출 뒤 당사자에게 알릴 방법이 없어진다는 점도 사고 대응 계획에 넣어 두세요.

수파베이스를 쓰는 서비스라면 코딩 에이전트가 만든 마이그레이션까지 포함해 public 스키마의 모든 표에 RLS 가 켜져 있는지 보안 어드바이저로 확인하고, 새 표에 RLS 를 자동으로 켜는 이벤트 트리거를 걸어 두세요. 기존 프로젝트는 public 에 새로 만든 표에 anon 역할의 읽기·쓰기 권한이 자동으로 붙는다고 공식 문서에 적혀 있어요.

10월 22일 전에 AI Controls > Copilot 화면의 배너가 알려 주는 '설정 안 된 정책' 수부터 확인하세요. 코드 리뷰·MCP 서버 정책을 설정 안 된 채 두었다면 그날 조직 전체에 켜져요. 막아야 할 기능은 하나씩 명시적으로 끄거나, 기본 정책 자체를 Disabled 로 바꾸면 앞으로 정식 출시되는 기능도 승인 전까지 꺼진 채 남아요.

이전 버전은 두 설정을 무시하므로, 문서가 권하는 대로 requiredMinimumVersion 을 함께 걸어야 차단이 실제로 적용돼요. 새 모델이 나올 때마다 검토 후 여는 팀이라면 exact 가 맞는 선택이에요. 베드록이나 텔레메트리를 끈 환경에서 권한 모드를 정해 두지 않았다면 업데이트 뒤 auto 모드로 시작하니 permissions.defaultMode 를 명시해 두세요.

에이전트형 자동 수정은 조직·기업 정책으로 켜는 기능이라, 실제로 기억이 붙는지는 관리자가 코파일럿 메모리 정책(조직 Settings > Copilot > Policies > Features)까지 켰는지에 달려 있어요. 켰다면 자동 수정이 남긴 수정 방식이 같은 저장소의 코드 리뷰 지적에도 영향을 주니, 저장소 관리자가 저장된 기억 목록을 주기적으로 열어 잘못 일반화된 규칙을 지우는 절차를 두는 편이 안전해요.

리뷰 대기 병목을 저장소별로 볼 수 있게 됐지만 지금은 사람끼리의 리뷰만 재므로, 코파일럿 코드 리뷰가 대기 시간을 줄였는지는 이 값으로 바로 알 수 없어요. 데이터가 9월 21일부터 쌓이기 시작하니 몇 주 모인 뒤에 추세를 보고, 조회하려면 지표 보기 권한과 사용 지표 정책이 켜져 있어야 하니 먼저 확인해 두세요.

해커뉴스 댓글 40개의 주된 반론은 대화 내용이 신생 업체로 나간다는 점과, 대체된 결정을 지우지 않고 표시만 해 두어 컨텍스트가 오래된 정보로 채워진다는 점이었어요. 회사 저장소에 붙이기 전에 외부로 나가는 범위를 보안 정책과 대조하고, 개인 프로젝트에서 JEVMEM.md 가 어떻게 쌓이는지 먼저 확인해 보세요.

코딩 에이전트에 밤새 긴 계산을 맡기는 방식의 참고 사례예요. 다만 사람이 몇 번 개입했는지, 실패한 실행이 있었는지, 토큰을 얼마나 썼는지는 글에 없어 해커뉴스에서도 같은 물음이 나왔으니, 긴 무인 실행을 설계할 때는 성공 사례보다 전문가 대조처럼 결과를 독립적으로 확인하는 단계를 어떻게 두었는지를 참고하는 편이 실무에 맞아요.

코딩 실무에 바로 닿는 변화는 없어요. 보도대로 승인되면 상장 뒤에도 이사 선임을 뺀 대부분의 안건을 외부 주주가 아니라 창업진이 결정하게 되지만, 아직 회사가 확인한 내용은 아니에요. 클로드 의존도가 큰 조직이라면 공개 S-1 서류가 나올 때 이 구조와 장기이익신탁 권한이 실제로 어떻게 적혔는지 확인하면 돼요.