#Claude Code
52개의 포스트
![[특집] 에이전트의 추론은 '미드필'이다 — 캐시 대 새 입력, 그리고 HBM 4단의 역습](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fmfh-cover.webp&w=3840&q=75)
[특집] 에이전트의 추론은 '미드필'이다 — 캐시 대 새 입력, 그리고 HBM 4단의 역습
코딩 에이전트의 추론은 '프리필 다음 디코드'가 아니라, 이미 캐시된 긴 앞부분에 짧은 새 입력을 붙이는 '미드필'의 반복입니다. 코어닷투데이 Claude Code 로그 6만 1,931번 호출을 세어 보니 입력의 97.8%가 캐시에서 왔고, 새 입력은 중앙값 1,711개로 캐시된 앞부분(중앙값 20만 1,917개)의 119분의 1이었습니다. 이런 일감에서는 HBM의 용량보다 대역폭과 KV를 옮기는 능력이 값을 정한다는 것이 SemiAnalysis의 주장이고, 그래서 Rubin Ultra는 GPU당 HBM을 288GB에서 192GB로 줄였으며 프런티어 연구소들은 4단 HBM을 원합니다. 공개 설정 파일과 공식 자료로 계산한 토큰당 KV는 모델마다 0.9kB에서 389kB까지 400배 넘게 벌어졌고, A100에서 vLLM으로 KV 예산을 줄여 본 실험은 '동시 사용자가 일정 수를 넘기 전까지는 아무 일도 없다'는 모양을 재현했습니다. 메모리 회사 입장의 계산은 유료 구간이라 추정하지 않고, 산수와 열린 질문만 정리했습니다.
![[특집] 에이전트가 CPU를 먹는다 — GPU 한 장에 CPU 몇 개? 코딩 에이전트로 재 본 대기 시간](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Faec-cover.webp&w=3840&q=75)
[특집] 에이전트가 CPU를 먹는다 — GPU 한 장에 CPU 몇 개? 코딩 에이전트로 재 본 대기 시간
2026년 프런티어 연구소들은 강화학습에 쓸 CPU가 바닥나 클라우드 회사와 범용 서버를 놓고 다투고 있고, Microsoft의 OpenAI용 Fairwater 데이터센터는 295MW GPU 클러스터 옆에 48MW CPU·스토리지 건물을 붙였습니다(전력 약 1:6). 코어닷투데이가 Claude Code 로그 26일치(모델 응답 6만 2,600번, 도구 호출 7만 7,197번)를 세어 보니 메인 세션 활성 시간의 42%가 도구를 기다리는 시간이었고, 10초 넘는 도구 호출 8.6%가 도구 시간의 83%를 만들었습니다. 맥 한 대에서 로컬 모델로 코딩 에이전트를 돌려 테스트 수를 50개에서 6,410개로 늘리자 모델 시간은 그대로인데 모델 1초당 CPU초가 0.09에서 8.37로 커졌고, 병렬 실행은 기다림을 줄였을 뿐 CPU초를 줄이지 못했습니다. 이 비율로 계산하면 GPU 한 장 옆에 필요한 CPU 코어는 일감에 따라 10개 안팎에서 수백 개까지 벌어지며, 그 식과 계산기, 2026년 CPU 열 종의 정리를 함께 실었습니다.
![[특집] 당신의 게임이 하네스다 — 'LLM은 게임에 약하다'는 착각, 그리고 게임 자체를 AI 에이전트의 하네스로 만드는 일곱 가지 방법](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fgih-hero.webp&w=3840&q=75)
[특집] 당신의 게임이 하네스다 — 'LLM은 게임에 약하다'는 착각, 그리고 게임 자체를 AI 에이전트의 하네스로 만드는 일곱 가지 방법
2026년 9월 캐나다 캘거리의 인디 게임 행사에서 15년 차 게임 프로그래머 카일 쿠크슈텔이 45분 발표를 했다. 제목은 「당신의 게임이 하네스다」. 게임 업계에 퍼진 'LLM은 게임에 약하다'는 말을 그는 뒤집는다. 문제는 모델의 능력이 아니라 게임이 AI에게 읽히지 않는다는 것, 곧 맥락(context)의 문제라는 것이다. 처방은 AI가 아니라 게임 쪽에 있다 — 시드 하나, 한 모양의 오브젝트(나무도 개다), 텍스트로 재생되는 명령, 코드 밖의 데이터, 엔진과 분리된 시뮬레이션, 스크린샷 대신 픽셀 diff, 사람용 GUI 대신 텍스트 프로파일. 이 글은 그 처방을 하나씩 풀면서, 각각이 둠의 데모 파일(1993)과 에이지 오브 엠파이어의 '28.8 모뎀 위의 1,500명의 궁수', 스타크래프트 리플레이, 팩토리오의 디싱크 리포트에서 어떻게 이미 쓰였는지를 따라간다. 하네스라는 말이 테스트 하네스에서 2026년 '하네스 엔지니어링'까지 어떻게 왔는지, 같은 제미나이가 RAM을 텍스트로 받으면 포켓몬을 완주하고 픽셀만 받으면 0.48%에 머무는 이유, 게임 업계 52%가 AI를 해롭다고 보는 2026년의 반감과 한국 게임사 70%의 도입률까지 — 여섯 개의 인터랙티브 도구와 함께 정리했다.
코드를 쓰는 시간이 사라지면 무엇이 남나 — 「왜 Common Lisp가 이제 최고의 언어인가」 특집
2026년 10월, 「왜 Common Lisp가 이제 최고의 프로그래밍 언어인가」라는 짧은 글이 해커뉴스와 X를 뒤흔들었습니다. 논거는 단순합니다. LLM이 코드를 쓰는 시간은 몇 초로 줄었는데, 빌드하고 재시작하고 크래시 로그를 읽는 시간은 그대로이니, 이제는 피드백 루프의 길이가 개발 속도를 정한다는 것입니다. 그리고 돌아가는 프로그램을 멈추지 않고 함수를 바꾸고, 에러가 나면 죽는 대신 멈춰서 선택지를 내미는 언어가 이미 1994년에 완성돼 있었다는 것입니다. 이 글은 1960년 매카시의 논문에서 시작해 Lisp 머신, 조건 시스템, ANSI 표준, 폴 그레이엄의 Viaweb까지 글이 기대는 네 가지 성질의 역사를 되짚고, 아키텍처를 그림으로 풀고, 해커뉴스의 반론과 2026년 데이터(저자원 언어 벤치마크, 토큰 가격, npm 공급망 사고)로 주장을 검증합니다. 브라우저에서 도는 미니 Lisp, 피드백 루프 시뮬레이터, 조건 시스템 체험, 토큰 계산기, 연표 위젯 5개와 일러스트 8장.
![[특집] AI가 코드를 쓸수록 설계가 중요해진다 — 「도메인 주도 설계는 AI가 코드를 쓸 때 더 중요해진다」 완전 해부](/_next/image?url=https%3A%2F%2Ffiles.core.today%2Fstorage%2Fcoredot%2Fpublic%2Fblog%2Fddd-cover.webp&w=3840&q=75)
[특집] AI가 코드를 쓸수록 설계가 중요해진다 — 「도메인 주도 설계는 AI가 코드를 쓸 때 더 중요해진다」 완전 해부
2026년 8월 20일, 폴란드의 Go 백엔드 교육 회사 스리 닷 랩스의 공동창업자 미워시 스몰카가 올린 에세이 한 편이 두 달에 걸쳐 조용히 퍼졌다. 주장은 단순하다 — '에이전트를 어떻게 설정하고 어떤 LLM을 쓰는지는 해법에 대한 명확한 정신 모델만큼 중요하지 않다. 둘 중 하나를 골라야 한다면 나는 생각을 건너뛰느니 코드를 한 줄도 직접 쓰지 않겠다.' 이 글은 그 주장을 끝까지 파고든다. 2003년 에릭 에반스의 '파란 책'이 왜 나왔고 지식 탐구·유비쿼터스 언어·바운디드 컨텍스트가 정확히 무엇을 뜻하는지, 1985년 피터 나우르의 '이론 만들기'부터 2026년 OpenAI의 하니스 엔지니어링까지 어떤 계보 위에 서 있는지, 월 1달러를 아낀 에이전트 일화가 왜 팀 커뮤니케이션의 축소판인지, 그리고 Faros·METR·GitClear·LinearB의 2025~2026년 데이터가 '쓰기가 싸지자 읽기가 비싸졌다'를 어떻게 증명하는지를 사례와 함께 풀었다. 본 버논의 '에이전트는 아직 도메인 모델을 못 만든다'는 증언, 에반스의 2026년 기조연설, 네이버·카카오·삼성·토스의 AI 코딩 도입과 GeekNews의 차가운 반응까지 — 다섯 개의 인터랙티브 도구로 2026년 가을 한국의 독자가 이 글에서 가져갈 것을 정리했다.
에이전트 여럿, 저장소 하나 부록 — 도구 지도 2026: 언제 무엇을 쓰나
git worktree 위에는 CLI·에이전트 앱 내장 기능·관제 앱이 층층이 올라가 있고, 옆에는 GitButler·Jujutsu처럼 방식이 다른 도구와 Forgejo 같은 자체 호스팅이 있습니다. 2026년 9월 기준으로 공식 저장소와 문서에서 확인한 사실만으로 각 도구가 무엇이고 worktree와 어떤 관계인지, 언제 쓰고 언제 피할지를 정리하고, 결정 흐름도와 비교표로 '우리 팀은 무엇부터 깔까'에 답합니다.
에이전트 여럿, 저장소 하나 5편 — 두 에이전트에게 같은 일 시키고 좋은 것만 합치기
같은 기능을 Claude Code와 Codex에게 각자의 worktree·브랜치에서 동시에 맡기고, git log·diff A...B·range-diff·같은 테스트로 두 결과를 비교한 뒤 좋은 부분만 골라 합치는 법을 실제 출력으로 따라갑니다. 통째로 채택(squash), 커밋만 가져오기(cherry-pick -x), 파일 하나 가져오기(restore --source), 세 번째 에이전트에게 합치기를 맡기는 법과 뒷정리, 그리고 이 방법이 오히려 손해인 경우까지 다룹니다.
에이전트 여럿, 저장소 하나 6편 — 에이전트가 길을 잃지 않는 저장소
에이전트는 매번 기억 없이 새로 시작하고, Mac은 저마다 설치된 버전이 다릅니다. 규칙은 AGENTS.md와 CLAUDE.md(@AGENTS.md)에, 도구 버전과 명령은 mise.toml에, 비밀은 .env.example 견본에, 큰 파일은 LFS·S3에, 안전장치는 pre-commit 훅·CI·main 보호에 담아 저장소 자체가 규칙과 환경을 들고 다니게 만드는 법을 실제 실행 결과와 함께 정리합니다. 마지막엔 새 Mac에서 다섯 줄로 똑같은 환경을 되살립니다.
에이전트 여럿, 저장소 하나 3편 — 에이전트에 worktree 맡기기: Claude Code·Codex·Worktrunk
2편에서 손으로 만들던 worktree를 이제 도구에게 맡깁니다. Claude Code의 --worktree·.worktreeinclude·worktree.baseRef·격리 강제·정리 규칙·서브에이전트 isolation, Codex 앱과 CLI가 worktree를 다루는 방식의 차이, 그리고 Worktrunk(wt)로 만들기부터 병합·정리까지 한 바퀴를 실제 출력으로 따라갑니다.
에이전트 여럿, 저장소 하나 4편 — Mac을 바꿔 가며 이어서 작업하기
맥북에서 하던 일을 맥 스튜디오에서 이어 가는 방법을 Git만으로 정리합니다. 퇴근 전 WIP 커밋과 push, 출근 후 fetch와 switch, stash가 다른 Mac으로 건너가지 못하는 이유, 두 Mac이 같은 브랜치를 만졌을 때의 pull --rebase와 --force-with-lease, 다른 Mac에 두고 온 커밋 찾기, 그리고 Mac마다 한 번씩 해 둘 인증·includeIf 설정까지 git 2.55 실제 출력으로 따라갑니다.
에이전트 여럿, 저장소 하나 1편 — 폴더를 동기화하지 말고 Git으로 주고받기
Claude Code와 Codex를 동시에 여러 개 돌리고, 맥북과 사무실 Mac을 오가며 같은 프로젝트를 만지기 시작하면 가장 먼저 떠오르는 방법이 '저장소 폴더를 동기화하자'입니다. 이 글은 그 방법이 왜 조용히 작업을 잃게 만드는지 직접 재현한 실험으로 보여 주고, 원격 하나 → Mac마다 clone → 작업마다 worktree로 이어지는 전체 설계도와 세 원칙, 그리고 소스·비밀·대용량 파일·빌드 산출물을 각각 어디에 둘지 정리합니다.
에이전트 여럿, 저장소 하나 2편 — git worktree 완전 정복
저장소 하나에서 작업 폴더를 여러 개 꺼내 쓰는 git worktree를 처음부터 끝까지 다룹니다. add·list·remove·prune·lock·move를 git 2.55 실제 출력으로 따라가고, 커밋·브랜치·stash·설정은 공유되지만 파일·스테이징·HEAD는 폴더마다 따로라는 사실을 명령으로 하나씩 증명합니다. 같은 브랜치를 두 곳에서 꺼낼 수 없는 이유, worktree마다 node_modules·포트·.env를 따로 챙겨야 하는 함정, switch·stash·clone과의 비교까지 정리합니다.