오늘 눈여겨본 세 가지는 모두 ‘AI 코딩 도구’를 다루지만, 각각 다른 질문을 던집니다 — 무엇을 만들 수 있나, 한 요청에 무엇을 태우나, 무엇을 밖으로 내보내나. 데모로 보면 다 멋지지만, 제품에 넣으려면 이 세 경계부터 확인해야 하죠. 각 항목은 사실을 짧게 밝히고, 한 줄 판단과 이번 주 확인할 일을 남깁니다.

오늘의 핵심

1. Terry Tao, 코딩 에이전트로 24개 레거시 애플릿을 몇 시간 만에 이식했습니다

• 사실: 2026년 7월 11일, 수학자 Terence Tao(UCLA)가 본인 블로그에 코딩 에이전트 활용기를 공개했습니다. 오래된 Java 1.0 애플릿 약 24개를 JavaScript로 이식했는데, 손으로 짰다면 수개월 걸릴 일을 몇 시간에 끝냈다고 합니다. 이식 과정에서 에이전트가 원본 코드의 버그 2개를 찾았고, 이식본에서는 그가 사소한 버그 1개만 발견했습니다. 특수상대성 시공간 다이어그램, Gilbreath 추측 시각화 같은 새 인터랙티브 도구도 만들었고요. 다만 그는 에이전트가 “노골적이거나 미묘한 버그”를 만들 수 있고, 고수준 설계 판단과 도메인 지식은 여전히 사람 몫이며, 결과물을 논문의 ‘보조 시각 자료’로만 취급해 실패 시 손해를 감수 가능한 범위로 한정했다고 분명히 적었습니다.
• 한 줄 판단: 에이전트가 코드를 쓰는 시대에도, ‘어디까지 믿고 어디를 검증하나’의 경계는 여전히 사람이 긋습니다. 규모(24개·수개월어치)가 곧 난이도였던 일을 에이전트가 압축했지만, 이게 안전했던 이유는 Tao가 결과물을 ‘보조 자료’로 한정해 실패 비용을 미리 낮춰 뒀기 때문입니다. 도구가 아니라 경계 설정이 핵심이에요.
• 이번 주 할 일: 그동안 손 못 대던 레거시 유틸이나 내부 도구 이식을 에이전트로 한 번 파일럿해 보시길 권합니다. 다만 실패 비용이 낮은 것(내부용·시각 보조)부터 고르시는 게 좋습니다 — 돈·데이터·물리가 걸린 코드는 ‘무엇을 믿고 무엇을 검증할지’ 경계를 먼저 정한 뒤에 붙이는 편이 안전합니다.

2. “Claude Code는 프롬프트를 읽기 전에 이미 33k 토큰을 쓴다”는 측정

• 사실: 컨설팅사 systima.ai가 각 도구와 모델 사이에 로깅 프록시를 끼워 측정한 결과를 공개했습니다. 사용자 프롬프트가 도착하기 전 기본 오버헤드가 Claude Code는 약 33k 토큰(시스템 프롬프트 ~6.5k + 툴 스키마 ~24k(27개 툴) + 스캐폴딩 ~2k), OpenCode는 약 7k(~2k + ~4.8k(10개 툴))라는 주장입니다. 둘 다 claude-sonnet-4-5로 고정하고 소규모(n=3)로 쟀습니다. ⚠️ 다만 systima는 ‘LLM 비용 최적화’ 컨설팅을 파는 회사라 이해상충 여지가 있고, 저자 스스로 멀티스텝·병렬 툴콜 작업에서는 요청 수가 늘며 총비용이 수렴한다는 단서를 달았습니다.
• 한 줄 판단: 에이전트의 진짜 ‘입력’은 프롬프트가 아니라, 매 요청에 딸려 나가는 시스템 프롬프트 + 툴 스키마입니다 — 툴을 많이 붙일수록 이 고정비가 커지죠. 특정 숫자(33k)는 한 번의 측정치일 뿐 도구·버전에 따라 달라지지만, ‘툴 스키마가 토큰 예산의 큰 몫을 차지한다’는 방향 자체는 누구나 재현해 확인할 수 있는 사실입니다.
• 이번 주 할 일: 자주 쓰는 에이전트의 첫 요청 토큰을 사용량 대시보드나 프록시로 한 번 실측해 보시면 좋습니다. 다만 툴을 줄여 오버헤드를 깎으면 그만큼 에이전트가 할 수 있는 일도 줄어드는 트레이드오프라, 목표는 ‘비용 최소화’보다 한 요청에 무엇을 태우는지 아는 것에 두시길 권합니다.

3. AI 코딩 CLI가 리포를 통째로 보낸다? — Grok CLI 와이어 분석 논쟁

• 사실: 한 개발자가 mitmproxy로 xAI의 Grok build CLI 트래픽을 캡처해 분석을 공개했습니다. 주장에 따르면 .env 비밀 파일 내용이 그대로 전송·보관되고, 사용자가 열지도 않은 리포 전체가 git 번들로 업로드되며(예: 12GB 리포에서 5.1GiB가 /v1/storage로 이동, 정작 모델 처리엔 192KB만 사용), 목적지는 grok-code-session-traces라는 GCS 버킷이라고 합니다. ‘모델 개선’ 토글을 꺼도 업로드가 계속됐다는 주장도 담겼습니다. ⚠️ 이는 xAI 공식 발표가 아니라 커뮤니티 분석이며, 위 수치·동작은 xAI가 확인해 준 사실이 아닙니다. 환경변수로 끌 수 있다는 코멘트 역시 미검증입니다.
• 한 줄 판단: 요점은 “Grok이 나쁘다”가 아니라, AI CLI에 코드를 통째로 넘기기 전에 ‘무엇이 밖으로 나가는지’를 직접 관측할 수 있어야 한다는 것입니다. 그럼의 편집 기준에선 AI도 입출력 경계가 명확해야 제품에 넣을 수 있죠. 업로드 범위가 문서에 없고 토글로도 안 꺼진다는 주장이 나올 수 있는 구조 자체가 이미 신뢰 비용입니다. (구체 수치는 미확인이니 단정하지 않습니다.)
• 이번 주 할 일: 사내에 새 AI 코딩 도구를 들이기 전, mitmproxy 같은 프록시로 첫 세션이 어떤 엔드포인트에 무엇을 보내는지 한 번 떠 보시길 권합니다. 다만 프록시 검사에는 인증서 설정·시간 품이 들고, 비밀값이나 독점 코드가 걸린 환경이 아니라면 과할 수 있으니 다루는 코드의 민감도에 맞춰 판단하시면 됩니다.

그래서, 무엇이 바뀌나

세 소식을 관통하는 흐름은 AI 코딩 도구를 데모가 아니라 제품 부품으로 다루려면, 세 개의 경계를 먼저 봐야 한다입니다. Tao는 역량의 경계(무엇을 맡기고 무엇을 검증하나), 토큰 측정은 비용의 경계(한 요청에 무엇을 태우나), Grok CLI 논쟁은 신뢰의 경계(무엇을 밖으로 내보내나)를 각각 건드립니다. 그럼의 편집 기준으로 보면 셋 다 같은 원칙의 변주예요 — AI도 역할·입출력·검증·복구 경계가 있어야 제품에 넣을 수 있다. 공개된 기술사에서 새 런타임이나 프레임워크를 프로덕션에 올릴 때마다 물었던 질문(“뭘 믿고, 뭐가 나가고, 청구서는 어디서 오나”)이, 이번엔 코딩 에이전트를 향해 되풀이되는 셈입니다. (데일리 트렌드를 고르는 기준도 같은 렌즈고, 어제가 ‘경계를 어디에 긋느냐’였다면 오늘은 그 경계를 AI 도구에 어떻게 적용하느냐입니다.)

참고 / 출처

• Old and new apps, via modern coding agents (Terence Tao)
• Claude Code vs OpenCode: token overhead (systima.ai)
• What xAI’s Grok build CLI sends to xAI: a wire-level analysis (gist, ⚠️ 커뮤니티 분석·미확인)