2026년 9월 7일 AI 코딩 소식

돈도 접근 권한도 제한이 없는 조직에서마저 반나절짜리 과제는 성공한 것조차 절반 넘게 사람이 끼어들어야 했으니, 에이전트에 일을 넘길 때 '몇 시간짜리인가'보다 '어디서 확인하고 끼어들 것인가'를 먼저 정해 두는 편이 나아요. 공개된 수치도 대부분 얼마나 썼는지를 보여 줄 뿐 무엇이 나왔는지는 담고 있지 않아서, 사내 도입 근거로 옮길 땐 성과 쪽 지표를 따로 세워야 해요.

에이전트를 쓰는 팀에서 실제로 문제가 되는 것은 두 번째 규칙이에요. 리뷰 의견을 받아 에이전트에 다시 돌리면 diff가 통째로 바뀌어 앞서 주고받은 리뷰가 무의미해지거든요. ‘리뷰에 올리기 전 담당자가 먼저 읽는다’와 ‘리뷰가 시작되면 재생성 대신 손으로 고친다’ 두 줄은 그대로 팀 규칙으로 옮겨 쓸 만해요. 다만 같은 정책이 글쓰기 쪽에 새로 붙인 ‘AI 탐지기가 사람 글로 판정해야 한다’는 조건은 오탐 보고가 이어지는 만큼 코드 규칙과 같은 무게로 가져오진 마세요.

에이전트에 도구 권한을 줄 때 프롬프트 인젝션 방어를 보안 경계로 삼으면 안 되는 이유가 이 계산에 있어요. 1~2%짜리 실패율은 한 번 시도할 때는 안전해 보여도 공격자가 자동으로 다시 던지면 시간 문제가 되니, 모델 방어는 빈도를 낮추는 장치로만 잡고 되돌릴 수 없는 동작에는 승인 절차를, 자격 증명에는 범위 제한을 따로 걸어 두세요.

사내에 클로드 코드를 깔아 두고 `allowedMcpServers` 로 서버를 걸러 왔다면, 2.1.259 이후로 판올림한 기계에서 막아 뒀던 관리 서버가 다시 붙었는지부터 확인하고 `deniedMcpServers` 로 옮기세요. 도구를 쓰더라도 읽기 전용으로만 돌리는 게 좋아요. `--fix --write` 는 `managed-settings.d/` 에 설정 파일을 직접 쓰는데, 만든 지 하루 된 패키지에 관리 설정 쓰기를 맡기는 셈이거든요.

모델 성능이 매달 곧게 올라간다는 전제로 도입 로드맵을 잡아 두었다면 다시 점검해 볼 만해요. 회사의 연구 방향을 정하는 사람이 공개적으로 속도를 줄이자고 적었고, 오픈AI는 8월에 애스트라 내부 작업을 스스로 멈춘 적도 있어요. 특정 회사 모델 하나에 도구를 몰아 두었다면 대체 경로를 미리 확인해 두세요.

기본 갱신 채널이 latest 라, 무엇이 바뀌었는지 모르는 채로 설치돼요. 공식 문서는 stable 채널을 '대략 한 주 뒤처지고 큰 회귀가 있는 판은 건너뛴다'고 설명하니, 권한 규칙이나 훅에 기대는 팀이라면 관리 설정에 autoUpdatesChannel 을 stable 로 두고 minimumVersion 으로 바닥을 잡아 두는 편이 검토할 시간을 벌어요.

에이전트가 '기계로 검증했다'며 결과를 내놓으면 어느 단계가 검사됐는지부터 갈라 보세요. 여기서 기계가 검사한 건 논리식이 모순이라는 것뿐이고, 그 논리식이 원래 문제를 옳게 옮겼는지는 검사를 안 받은 한 쪽짜리 글에 걸려 있어요. 테스트가 다 통과했다는 말도 테스트가 요구사항을 옳게 옮겼을 때만 뜻이 있으니, 에이전트가 함께 써 준 테스트일수록 그 옮김을 직접 읽어 보세요.

클로드 코드·API에 업무를 걸어 둔 팀에는 앤트로픽이 '분기마다 실적을 설명하는 회사'가 되는 시점이 한 달쯤 뒤로 밀린 거라, 상장 때문에 한도나 요금이 조여질 일은 당분간 없어요. 다만 예정대로 9월 말에 서류가 공개되면 한도 정책·데이터 보존·모델 지원 종료가 위험 요인으로 어떻게 적히는지 처음 확인할 수 있으니, 계약 갱신이나 내년 원가 계획은 그 서류를 읽고 정하는 편이 나아요.

이 다툼은 합의금을 나누는 쪽 이야기여서 앤트로픽이 더 물어야 할 돈도, 클로드나 클로드 코드에 생기는 변화도 없어요. 다만 법원이 승인하고 저작물 50만 건을 목록으로 확정한 뒤에도 책 한 권의 권리자가 누구인지 당사자끼리 정리되지 않는다는 게 확인됐어요. 사내 말뭉치나 미세조정 데이터를 라이선스로 들여올 때 계약서 한 장을 권리 확인으로 삼지 말고, 상대가 권리자인 근거(권리가 언제 누구에게 돌아갔는지, 계약이 넘긴 범위가 어디까지인지)를 자료마다 따로 남겨 두는 편이 안전해요.