2026년 10월 13일 AI 코딩 소식

에이전트에게 코드·테스트·검토 초안을 맡기면서도 측정은 직접 하고, 알려진 문제 목록과 도움받은 사실을 커밋 설명에 함께 남긴 방식은 팀에서 에이전트 작업을 들일 때 참고할 만해요. 성능 수치는 노트북 한 대에서 특정 작업 부하로 잰 결과라 그대로 일반화하지는 마세요.

벤치마크 상단 점수는 구독 전용인 원더 풀의 값이고, API 로 쓰는 원더는 DeepSWE 78.8·SWE-Marathon 53.1 로 오푸스 5.5 보다 높지만 Terminal-Bench 52.0·ProgramBench 50.0 으로는 낮게 적혀 있어요. 모두 메타 자체 측정이니, 긴 작업 위주의 팀이라면 자기 저장소 과제로 원더와 쓰던 모델을 같은 가격대에서 비교해 보는 것이 먼저예요.

direnv 로 저장소마다 GH_TOKEN 같은 값을 바꿔 쓰거나 프록시 설정이 세션마다 다르다면, ~/.codex/config.toml 의 [features] 에 daemon_auto_start = false 를 넣고 codex app-server daemon stop 뒤에 pid-update-loop 프로세스가 남았는지도 확인해 보세요. 이슈 보고로는 데몬만 멈추면 업데이트 검사기는 계속 돌아요.

확인된 것은 '손으로 쓴 코드 금지'라는 내부 지시가 보도됐고 에픽이 그 지시를 부인하지 않았다는 점까지예요. AI 가 만든 오류를 어떤 안전장치로 바로잡는지는 보도에도 드러나지 않았으니, 팀에 비슷한 목표를 세운다면 AI 생성 비율보다 리뷰·테스트로 결함을 잡는 체계를 먼저 정해 두는 편이 안전해요.

금지 대상이 'AI가 쓴 코드'가 아니라 '도움을 받은' 코드라 초안·리뷰 보조까지 걸릴 수 있고, 검출 수단 없이 사후 되돌림과 제재로 집행돼요. 에이전트로 만든 패치를 업스트림에 올리기 전에 그 저장소의 정책 문서와 CONTRIBUTING 을 먼저 확인하세요. QGIS 는 본체 저장소만 해당해요.

통제된 환경에서 가장 쉬운 침투 조건으로 잰 결과라 당장의 위협으로 읽을 필요는 없어요. 다만 저자들이 제안한 방어책은 지금 점검할 수 있어요. 사내망·연구실의 안드로이드 기기, 젯슨 보드, 로컬 추론 서버에 ADB(5555 포트)나 인증 없는 추론 엔드포인트가 열려 있지 않은지, 기기끼리 오가는 트래픽과 수 GB 짜리 전송을 감시하고 있는지 확인해 보세요.

엔터프라이즈 조직이라면 커밋 작성자 이름만 보고 리뷰·감사를 판단하던 절차를 푸시 사용자 기준으로 바꿀 수 있는지 검토할 만해요. 다만 'Committer must match pusher' 를 켜기 전에 CI·자동화 도구·공용 계정처럼 커미터 이메일과 푸시 계정이 다른 작업 흐름이 있는지 먼저 찾아 두세요. 공지는 이런 경우를 어떻게 처리하는지 설명하지 않아요.

gVisor 는 VM 이 아니라 사용자 공간에서 시스템 호출을 가로채는 방식이라 도커 안 도커가 안 되니, 테스트에 컨테이너가 필요한 에이전트라면 VM 요금(2.5배)으로 다시 계산하세요. 해커뉴스 댓글이 짚었듯 샌드박스는 호스트만 지키고 에이전트에 넘긴 토큰은 지키지 못하므로, 작업별로 범위를 좁힌 단기 자격 증명을 함께 설계해야 해요.

옮길지 검토한다면 내 코드베이스에서 직접 비교해 보세요. 해커뉴스에서는 큰 코드베이스에서는 아직 부족하다는 반론, 많이 쓰면 오히려 약 5배 비싸다는 반론, 격리 영역 제공사도 결국 믿어야 한다는 반론이 나왔어요. OpenCode Go 는 중계라 뒤의 제공사도 세션을 본다고 저자가 직접 적었으니, 사내 코드를 넣기 전에 어느 단계가 데이터를 보는지 확인하세요.

원문 전문이 확인되지 않아 권고는 보류해요. 확인된 논점은 해커뉴스 토론의 '사람이 검증하는 속도가 병목'이라는 지적으로, 에이전트 산출물이 늘수록 리뷰 체계를 먼저 점검해야 한다는 실무 과제와 맞닿아 있어요.