2026년 8월 11일 AI 코딩 소식

라마 때 사내 도입을 막던 게 성능보다 라이선스 검토였다면 아파치 2.0이 그 관문을 없애 줘요 — 실질 차별점은 성능이 아니라 라이선스와 24GB 한 장에 들어가는 크기라, 사내 반입 심사나 장비 예산이 걸림돌이던 팀만 계산이 달라져요. 이미 큐원3.6 27B로 로컬 에이전트를 돌리고 있다면 갈아탈 근거는 메타가 만든 표 안에서도 약하고, 학습 데이터는 안 열려서 같은 모델을 직접 다시 만드는 건 여전히 안 돼요.

승인을 받아 뒀어도 그게 지금 쓰는 모델까지 덮는다는 보장이 없어요 — 문서에 적힌 CVP 적용 범위는 오푸스·소네트뿐인데 막혔다는 신고는 페이블에서도 나와요. 보안 점검 일정을 승인 상태에 걸어 두지 말고, 막힌 요청 ID와 화면을 모아 이의 신청으로 남겨 두는 편이 현실적이에요.

오래 쉬었던 장비에서 세션을 열었을 때 '크레딧을 켜라'는 안내가 뜨면 결제 설정부터 건드리지 말고 창을 다시 켜 보세요 — 등급을 못 읽은 것일 수 있어요. 안내대로 켰다가 접근은 그대로인데 요금만 붙었다는 신고가 아직 열려 있어요.

에이전트를 하루 반씩 굴려도 되는 조건이 그대로 드러나 있어요 — 맞았는지 기계가 바로 채점해 주고(Lean·수치 검사), 서브에이전트 30개가 헛수고해도 2개만 맞히면 되고, 검증 전담을 13개나 따로 뒀어요. 우리 코드에서 그 채점기는 테스트·타입·빌드라 그게 없는 영역에 같은 방식을 옮기면 실패만 쌓이고, 게다가 이건 미공개 연구용 모델이라 지금 쓰는 클로드 코드로 그대로 재현되는 이야기는 아니에요.

우리 API도 조회·생성엔 권한 검사를 붙여 놓고 취소·삭제 쪽만 비워 두기 쉬운데, 이제 그 구멍을 찾는 건 모의해킹 팀이 아니라 고객이 개인용으로 돌리는 에이전트예요 — 남의 자원 ID를 넣은 취소 요청이 200으로 통과하는지 오늘 한 번 찍어 볼 만해요.

보안 업무를 하다 모델 거절에 막혀 왔다면 이제 두 방식이 갈려요. 앤트로픽 CVP는 쓰던 오푸스·소네트의 안전장치만 풀어 주는 쪽이고, 데이브레이크는 블루에서 같은 걸 하면서 레드엔 아예 다른 모델을 따로 두는 쪽이에요. 다만 둘 다 조직 단위 신청·심사라, 개인이나 사내 보안팀이 곧장 붙일 수 있는 경로는 아직 없어요.

앱 안 세션에 개발 환경 설정을 맡기고 있다면 '성공' 메시지를 확인으로 치지 마세요 — 꾸러미 밖 터미널에서 같은 키·파일을 다시 조회하는 절차를 붙이거나, winget으로 받는 비-MSIX 설치본으로 갈아타는 쪽이 확실해요.

모델을 역할별로 쪼개 붙이는 건 지금 여기서도 많이 시도하는 구성인데, 깨진 자리가 모델이 아니라 엮은 방식이었다는 게 이 실험의 값이에요 — 검증을 '해도 되고 말아도 되는' 선택으로 두면 안 부르고, 넘기는 횟수에 상한이 없으면 값이 네 배로 뛰고, 사람이 직접 하면 되던 보안 작업이 넘겨서 시키는 순간 막혀요. 검증 강제, 넘김 횟수 상한, 보안·취약점 작업은 사람이 직접 거는 경로로 빼 두기부터 챙기는 게 순서예요.

환불 문서엔 '법이 요구하거나 약관에 적힌 경우 말고는 전부 환불 불가'로 적혀 있고, 카드사에 이의를 걸어 두면 그동안은 환불 처리 자체가 막힌다고도 돼 있어요 — 결제 화면과 실제 구독 기록이 어긋나면 카드사부터 부르기 전에 청구서 원본과 지원팀 답변을 먼저 챙겨 두는 편이 안전해요.

'여러분 데이터로 학습하지 않습니다'는 모델 자체를 다시 손보지 않는다는 말이지, 같은 데이터를 검색해 프롬프트 맥락으로 다시 꺼내 쓰지 않는다는 말이 아니에요. AI 도구를 들일 때는 '학습하나요' 말고 '어디에 얼마나 보관하고, 다른 요청의 맥락으로 다시 꺼내 쓰나요'를 계약서에서 따로 물어야 해요.

621점은 새 소식이라는 뜻이 아니라 같은 페이지가 반년 만에 다시 뜬 결과예요. 검토한다면 세 가지를 보세요 — 내 컴퓨터에서 도는 도구인데도 도커 계정 로그인을 요구하고, CLI는 무료지만 팀 단위 네트워크·파일 정책은 유료 Docker AI Governance 몫이고, 소스는 열려 있지 않아 깃허브엔 배포·이슈 저장소만 있어요(열린 이슈 247건).

긴 세션이 '200개 다 썼다'며 새 에이전트를 거절하는 일은 없어졌지만, 마지막 안전장치가 하나 사라진 것이기도 해요 — 내가 안 친 토큰이 한도를 먹는 경로는 이미 여럿이라(받은 세션 메시지, 상태 확인 한 번에 딸려 오는 배경 기록), 팬아웃을 크게 쓰는 팀이라면 CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS를 20보다 낮게 직접 박아 두는 쪽이 지출 예측에 나아요.

문서가 스스로 밝힌 한계는 '아주 짧은 글은 신호가 모자라 안 잡힌다'인데, 코드가 여기 해당하는지는 안 적혀 있어요. 오픈JDK처럼 AI가 쓴 줄을 막는 저장소에 낼 코드라면 범위를 확정한 기술 문서가 나오기 전까진 클로드 코드 결과물을 그대로 올리는 걸 한 번 더 볼 만해요.