2026년 9월 10일 AI 코딩 소식

사임한 사람은 안전 조직 바깥의 사전학습 연구자라 내부 감사 결과를 들고 나온 게 아니에요. 실무에 남는 사실은, 재직 중인 정렬 책임자가 '초지능 정렬 계획이 아직 없다'고 공개로 적었는데 회사 차원의 답은 나오지 않았다는 점이에요. 모델 공급사 한 곳에 워크플로를 묶어 둔 팀이라면 성능 지표 옆에 이런 조직 신호도 공급사 위험으로 적어 두는 편이 나아요.

`/usage` 의 `Prompt cache (main)` 줄이 세션 적중률과 마지막 미적중의 추정 원인까지 알려 주니(적중률은 v2.1.251, 원인 표시는 v2.1.260 이상), 긴 세션을 자주 재개하거나 MCP 서버를 여럿 붙여 쓴다면 올린 뒤 그 줄로 적중률이 달라졌는지 재 보면 돼요.

동기화 폴더에서 세션을 열 때는 accept edits 를 켜지 말고 rm 을 deny 규칙에 넣어 두세요. 작업 폴더 아래로는 문서상 확인 절차가 없고, 지워진 뒤에는 /rewind 도 소용없어요. 이미 당했다면 컴퓨터 휴지통이 비어 있어도 포기하지 마세요. 드롭박스는 기본·Plus 요금제 기준 30일 동안 웹의 '삭제된 파일' 목록에서 되돌릴 수 있어요.

터미널과 에디터만 잠그고 안심하기는 일러요. 같은 규칙이 깃허브 쪽에서 도는 클라우드 에이전트엔 안 걸려서 그쪽은 MCP 허용 목록 같은 별도 수단으로 막아야 하고, 허용 목록을 여러 곳에서 함께 쓰면 합집합이 아니라 교집합으로 계산돼 의도보다 좁게 잠길 수 있어요.

프로 모델 ID를 고정해 둔 파이프라인이라면 오늘 낮부터 응답을 내는 모델이 예고 없이 바뀌니, 값이 내려간 만큼 회귀 테스트와 도구 호출 검증을 다시 돌려 볼 때예요. 동작을 지금 그대로 묶어 두려면 V4 프로 가중치가 매출 조건 없는 MIT 라이선스로 허깅페이스에 올라와 있어서 직접 띄워 쓰는 방법이 남아 있어요.

에이전트 감시를 모델이 남긴 사고 사슬(CoT)에 기대면, '이건 테스트 환경이야'라고 스스로 적어 둔 문장 하나가 감시를 통과시켜요. 앤트로픽 오프라인 감시기가 이 사건에서 걸러낸 행동이 1%뿐이었던 이유가 그거예요. 사내 에이전트에 자격 증명이나 외부 접근 권한을 주고 있다면, 판정 근거를 모델의 설명이 아니라 실제로 나간 요청과 도착지 주소에 두세요.

훅으로 셸 명령 문자열을 검사하는 방식은 `/bin/rm`, `sh -c '...'`, 히어독처럼 같은 프로그램을 다른 모양으로 부르면 빠져나가요. 공식 문서가 명령 문자열에 기대지 않는 강제 수단으로 샌드박스를 따로 안내하는 이유예요. 사내에서 bypassPermissions 를 열어 두고 훅으로 막고 있다면 그 훅을 다른 호출 형태로 한 번 시험해 보고, 실제 강제는 컨테이너나 가상 머신 격리 쪽에 두는 편이 안전해요.

서버 버전을 고정해 두는 것으로는 막히지 않아요. 같은 판본이 클라이언트별로 호출 횟수를 세서 네 번째부터 다른 도구 목록을 주거든요. 고정할 대상은 버전이 아니라 승인 시점에 받아 둔 도구 스키마 자체이고, 세션이 도는 중에 tools/list 가 바뀌면 보안 사고로 올라오도록 MCP 클라이언트 로그를 남겨 두세요.

25건을 한꺼번에 맡기면 청구가 건수가 아니라 에이전트가 쓴 토큰을 따라가서 미리 계산되지 않으니, 처음에는 몇 건만 넘겨 실제 크레딧 소모를 재 본 뒤 범위를 늘리는 편이 안전해요. 공식 문서가 이 자동 수정을 '최선 노력'이라고 적어 뒀고 사용자 정의 쿼리와 security-extended 쿼리에서 나온 지적은 에이전트가 검증조차 못 한다고 밝혔으니, 열린 풀 리퀘스트는 CI 통과 여부와 동작이 바뀌지 않았는지까지 직접 확인해야 해요.

댓글에서 되풀이해 나온 실무 대응은 두 가지예요. 사람이 계획을 먼저 세워 넘긴 쪽은 15분 만에 병합 가능한 PR 네 개를 받았다고 했고, 대화로 두 번 고쳐도 안 되면 세션을 이어 가지 말고 되돌리라는 조언이 여러 번 나왔어요. 같은 모델을 쓰고도 경험이 이렇게 다르다면, 변경 범위를 사람이 쥐고 있는지부터 점검해 볼 만해요.

에이전트가 어려운 과제까지 통과시키기 시작하면 '이건 어렵고 저건 쉽다'로 일감을 가늠하던 팀의 감각이 먼저 무뎌지고, 통과한 diff 만 남고 왜 통과했는지가 남지 않으면 다음 문제에서 쓸 것이 없어요. 해커뉴스 댓글에도 시니어는 AI로 생산성이 뛰는데 주니어가 그 판단 감각을 익힐 길이 없다는 반응이 있었어요. 어떤 변경은 동작 확인만으로 병합하지 않고 설명을 함께 받는다고 팀 규칙에 적어 두는 것이 타오의 제안을 코드 쪽으로 옮긴 형태예요.