라벨이 Claude Code인 게시물 표시

AI 산출물은 한 건씩 보지 말고 스무 개를 한 줄로 세워라

이미지
오전에 저장소 하나를 열어서 산출물 열여덟 개의 제목만 뽑아 세로로 늘어놨다. A가 아니라 B였다 A했고 B였다 기대한 것과 결과가 어긋났다 열여덟 개 중 열다섯 개가 이 셋 중 하나였다. 종결 어미까지 세어보니 열일곱 개가 같은 형태였다. 질문형도 명사구도 인용도 없었다. 한 건씩 볼 때는 아무 문제가 없었다. 각각은 검사를 통과했고, 통과 기록도 남아 있다. 검사기가 제목을 안 읽고 있었을 뿐이다. 이 글은 그날 하루 동안 같은 저장소에서 연달아 나온 여섯 가지를 순서대로 적은 것이다. 여섯 개가 다 다른 사고처럼 보이는데, 다시 보면 전부 한 자리에서 나왔다. 설계와 구현과 검증을 다 맡기고 나서 사람이 무엇을 안 봤는가 하는 자리다. 검사기는 본문만 읽고 있었다 이 저장소에는 산출물 문체를 훑는 검사기가 있다. 금지 표현 목록이 열 개 항목으로 나뉘어 있고, 각 항목마다 걸러낼 패턴이 나열돼 있다. 그중 일곱 번째 항목이 이렇게 적혀 있다. AI 결론형 정형구 : 가 아니라 ~다 · 데 있다 · 한 셈이다 · 결국 ~것이다 → 사실만 쓰고 결론 라벨을 떼면 대개 좋아진다. 그러니까 가 아니라 ~다 는 명시적으로 금지된 문형이다. 문서에 적혀 있고, 이유도 적혀 있고, 대안도 적혀 있다. 발행된 제목 중 셋이 정확히 그 문형이었다. AX 는 도구를 사는 일이 아니라 권한을 자르는 일이다 깨진 유리창 이론은 마음가짐이 아니라 순찰 인력에서 시작했다 네 번째 리팩토링에서 AI가 아니라 내가 문제였다 검사기가 고장 난 게 아니다. 검사기는 본문 파일을 훑는다. 제목은 파일 맨 위 메타데이터에 있고, 그 영역은 훑는 범위 밖이었다. 규칙은 있었고 실행도 됐는데 산출물의 한 조각이 검사 밖에 있었다. 검사기를 만들 때는 본문이 산출물의 전부처럼 보였을 것이다. 제목은 나중에 붙는 짧은 문자열이니까 검사할 게 없어 보인다. 실제로는 제목이 열여덟 개 중 열여덟 개에 붙고, 목록 화면에서는 제목만 보인다. 읽는 사람이 제일 먼저...

Orca 로 worktree 세 개에 에이전트를 나눠 띄웠다

이미지
worktree 는 파일을 갈라준다. .git 은 안 갈라준다. 그 한 층 차이에서 다른 브랜치의 변경이 충돌도 없이 내 작업 트리에 얹혔다. 터미널을 세 개 열어놓고 쓰다 보면 10분쯤 지나서 어느 창이 무슨 작업이었는지 헷갈린다. 한쪽에서 로그인 버그를 잡고, 다른 쪽에서 테스트를 만들고, 나머지 창에서 리팩터링을 시키는데, 셋이 같은 폴더를 보고 있으니 결국 같은 파일을 건드리기 시작한다. 그래서 Orca 를 깔았다. 저장소를 붙이고 worktree 를 세 개 만들어 Claude Code 와 Codex 를 서로 다른 폴더에 띄웠다. 파일은 정말 안 섞였다. diff 세 개가 나란히 쌓이고 마음에 드는 것만 골라 PR 로 올릴 수 있었다. 한쪽 에이전트에게 "작업 중인 변경 잠깐 치워두고 확인해봐"를 시켰더니 git stash 를 썼고, 그게 다른 폴더에서 그대로 보였다. 거기서 꺼내니 다른 브랜치의 작업 트리에 얹혔다. 충돌조차 나지 않았다. 이름에 IDE 가 붙었지만 편집기는 아니다 제작사는 Orca 를 ADE 라고 부른다. Agent Development Environment 의 약자로, 코딩 에이전트를 여러 개 띄워놓고 작업별로 챙기는 공간이라는 뜻이다. GitHub 저장소 설명 도 "병렬 에이전트 함대를 다루는 ADE" 라고 적혀 있다. Cursor 나 VS Code 에도 AI 기능이 있는데 굳이 하나를 더 깔아야 하냐는 질문이 먼저 나온다. 역할이 다르다. Cursor 에서는 편집기 안에서 AI 와 코드를 함께 쓴다. Orca 에서는 코드를 직접 쓰지 않고, 여러 에이전트의 진행 상황을 보고 결과를 비교해 어느 변경을 가져올지 고른다. 편집기 자리에 앉아 있는 게 아니라 감독 자리에 앉는 도구다. 별도 AI 모델을 새로 결제하는 방식도 아니다. 컴퓨터에 이미 깔려 있는 CLI 와 로그인 정보를 불러와 실행한다. 그래서 목록에 에이전트가 안 뜨면 앱을 다시 깔기 전에 CLI 설치와 로그인, PAT...

로블록스 기획서의 “작게”와 코드의 102스터드

이미지
지난 게임에서는 하네스를 마지막 날에 붙였다. 이번엔 코드보다 먼저 놨다. 하루에 12,903줄이 나왔고 테스트 354단언이 통과했는데, 맵은 어이없게 작았다. 저주대전 저장소를 열어보면 순서가 그대로 남아 있다. 첫 커밋이 2026-08-05, 마지막 커밋이 08-19. 그 사이 19개 커밋이 쌓였고 src/ 는 44파일 27,847줄이 됐다. .claude/agents/ 의 첫 파일이 생긴 시각은 08-19 12:34다. 14일치 코드를 다 쓰고 나서 에이전트를 만들었다는 뜻이다. 그 저장소에는 tests/ 디렉터리가 아예 없다. 검증이 없었던 건 아니다. 교차 참조 검사기를 23개까지 만들어 붙였고 규칙 문서는 MCP 서버로 잘라서 에이전트에 물렸다 . 다만 그게 전부 코드를 다 쓴 뒤에 따라온 것들이었다. 하네스를 붙이던 커밋 메시지에 스스로 진단이 적혀 있다. chore: 하네스 구성 — 정적 검증은 L3 인데 실기 검증만 L0(산문)이었다 교차 참조 검사 24종이 커밋을 물리적으로 막을 만큼 서 있는 동안, "스튜디오에서 실제로 봤는가"는 인계 문서의 산문 표에 47행까지 쌓여 있었다. 확인했다고 적을 자리가 없어서 매 세션이 47개를 다시 읽고도 무엇이 끝났는지 몰랐다. 코드를 다 쓴 다음에야 그 비대칭이 보였다. 같은 커밋의 마지막 줄은 이렇게 끝난다. "하네스 자체는 실제 작업으로 돌려본 적이 없다. 정적 검증까지다." 그래서 오늘은 순서를 바꿔봤다. 로블록스 게임 두 개를 같은 날 시작하면서 기획서와 하네스를 코드보다 먼저 놨다. 하루 만에 12,903줄이 나왔고 테스트 354단언이 통과했고 둘 다 실행됐다. 그래도 돌아가긴 하네, 싶었다. 그런데 열어보니 맵이 작았다. 354개 중에 그걸 물어본 단언은 하나도 없었다. 12시 24분에 기획서가 먼저 있었다 오늘 로블록스 게임 두 개를 동시에 시작했다. 「우리 학교가 이상하다」(1~4인 협동 관찰 공포, 전투 없음)와 「몬스터 군도...

유니티 넉 달과 로블록스 이틀, 무엇이 달랐을까?

이미지
이틀 만에 로블록스 게임을 하나 만들었다. Lua 43개 파일에 25,220줄, 문서 11개, 커밋 11개. 만들라고 시키기 전에 공부부터 시킨 이야기는 따로 적었다 . 그 글을 쓰고 나서 기분이 좋았다. 순서를 잘 잡았더니 이틀 만에 나왔다는 이야기였으니까. 며칠 뒤에 다른 저장소를 열어볼 일이 있었다. 유니티로 만들던 모바일 게임인데, 3월 말에 시작해서 7월 말이 마지막 커밋이다. 넉 달이다. 커밋은 219개. 같은 사람이 같은 도구로 작업했다. 한쪽은 이틀, 한쪽은 넉 달. 그 차이가 어디서 났는지 보려고 커밋 로그를 시간순으로 훑었다. 보고 나서 내가 이틀 만에 만들었다고 생각한 게 틀렸다는 걸 알았다. 월별로 세보니 이상했다 먼저 커밋을 월별로 세봤다. 2026년 3월에 2개, 4월에 163개, 5월에 40개, 6월과 7월에 각각 7개다. 합쳐서 219개다. 4월에 163개다. 전체의 74%가 한 달에 몰려 있다. 그리고 5월에 40개로 떨어지고 6월엔 7개가 된다. 처음엔 그냥 프로젝트에 시들해진 곡선이라고 생각했다. 대부분의 개인 프로젝트가 이렇게 생겼으니까. 그런데 커밋 종류를 세어보니 다른 게 보였다. feat 이 101개로 제일 많고 fix 가 51개다. chore 36개, docs 22개, refactor 4개, 기타 5개가 뒤를 잇는다. fix 가 51개다. 전체의 23%. 그리고 이 51개가 어디에 몰려 있는지가 문제였다. 4월 첫 주에 무슨 일이 있었나 4월 4일부터 7일까지 나흘간의 커밋을 그대로 옮긴다. 04-07 feat(assets): BoomBlitz 레퍼런스 기반 에셋 구조 전면 재설계 04-06 fix: StageSelectController long→int 캐스트 오류 + deprecated ScaleMode 수정 04-06 feat(ui): UI 스프라이트 에셋 29종 생성 + 전체 화면에 적용 04-06 feat(ui): 가챠/스테이지/영웅목록 화면 비주얼 대폭 개선 04-06 ...

내 하루 토큰 사용량의 분모는 얼마인가?

이미지
이틀 전에 게임 저장소에 문서 MCP 서버를 붙였다. 문서 14개를 통째로 읽히는 대신 질문에 맞는 섹션만 돌려주게 만든 것이고, 그 과정은 따로 적었다 . 그 글 끝에 나는 이렇게 썼다. get_rules 호출 기준 토큰이 13~20% 줄었다고. 그 문장을 쓸 때는 만족스러웠다. 측정을 했고 숫자가 나왔으니까. 며칠 지나고 나서 그 문장이 이상하게 걸렸다. 13~20%가 줄었다는 건 분자다. 분모는 무엇인가. 나는 하루에 토큰을 얼마나 쓰고 있나. 13%를 줄인 게 밥 한 숟갈인지 한 끼인지 나는 모르고 있었다. 모르는 채로 절감률만 적어둔 것이다. 분모를 세어보기로 했다 Claude Code는 대화 기록을 로컬에 남긴다. ~/.claude/projects/ 아래에 저장소별 디렉터리가 있고 그 안에 .jsonl 파일이 쌓인다. 각 줄이 메시지 하나고, 어시스턴트 메시지에는 usage 필드가 붙어 있다. 거기에 네 가지 숫자가 들어 있다. input_tokens 는 캐시에 없어서 새로 읽은 입력이고, output_tokens 는 모델이 생성한 출력이다. cache_creation_input_tokens 는 캐시에 새로 쓴 입력, cache_read_input_tokens 는 캐시에서 읽은 입력이다. 이 네 개를 저장소별로 더하는 스크립트를 40줄쯤 짰다. 48개 파일, 56MB였다. 결과를 처음 봤을 때 나는 자릿수를 잘못 읽은 줄 알았다. 6억 4,619만 로블록스 게임 저장소 한 곳이 153,811,746 토큰으로 23.8% 다. 블로그 저장소 두 곳이 252,075,809 로 39.0% 라 제일 크고, 개인 앱 프로젝트 한 곳이 133,050,923 으로 20.6% 다. 책 작업 세 곳이 76,789,730 으로 11.9%, 도구와 기타 두 곳이 18,243,049 로 2.8%, 업무 관련 저장소 네 곳이 12,220,298 로 1.9% 다. 열세 곳을 합치면 646,191,555 다. 6억 4,619만 토큰이다. 메시...

코딩 에이전트 CLI 4종 2026년 8월 판세

이미지
2024년부터 2025년까지, 터미널에서 돌리는 코딩 에이전트의 순서는 대체로 합의돼 있었다. 클로드 코드와 코덱스가 비등하게 앞에 있고, 그 뒤를 그록이, 마지막을 제미나이가 따라가는 형태였다. 이 순서는 꽤 오래 안정적이었다. 2026년 8월의 순서는 그렇지 않다. 넉 달 사이에 네 개 중 세 개가 자리를 바꿨고, 그중 하나는 제품 자체가 없어졌다. 개발자로서 이 넷을 한번 제대로 비교해보고 싶었다. 어느 쪽이 낫다는 인상은 다들 갖고 있는데 그 인상이 언제 무엇 때문에 생긴 건지는 잘 안 따진다. 그래서 넉 달치 벤더 공지와 포스트모템, 가격표, 종료 안내를 찾아서 날짜순으로 늘어놨다. 이 글은 그렇게 정리한 결과다. 그 넉 달에 무슨 일이 있었는지를 공개된 자료로만 다룬다. 벤더 포스트모템, 개발자 블로그 공지, 가격표, 벤치마크 숫자가 근거다. 출처의 신뢰도가 고르지 않아서, 1차 자료로 확인된 것과 2차 매체가 옮긴 것을 구분해 적었다. 판단은 마지막 절에만 있다. 먼저 짚어둘 게 있다. 코딩 에이전트 비교 글은 대개 벤치마크 표로 시작해서 벤치마크 표로 끝난다. 그런데 2026년 상반기에 순위를 실제로 흔든 건 벤치마크가 아니었다. 하나는 벤더가 조용히 바꾼 기본값이었고, 하나는 무료 티어 정리였고, 하나는 자본 거래였다. 셋 다 모델 성능표에는 안 찍힌다. 그래서 이 글은 점수 대신 날짜 를 축으로 놓는다. 이 글에서 내가 직접 돌려본 건 클로드 코드와 코덱스뿐이다. 그록과 제미나이 쪽은 벤더 공지와 포스트모템, 가격표, 종료 안내로만 확인했고 손으로 써보지 않았다. 그래서 성능 평가는 하지 않고 날짜와 공개된 수치만 늘어놓는다. 각 항목의 출처는 본문에 링크로 달았다. 넉 달 타임라인 1월에 Anthropic 이 서드파티 코딩 에이전트의 Claude 접속을 막았다. 구독 취소 경고가 이어졌다. 3월이 분기점이다. 3월 4일에 Claude Code 기본 reasoning effort 가 high 에서 medium 으로 조용히 ...

게임 레포 규칙 문서 250KB를 MCP 서버로 자르기

이미지
규칙은 다섯 줄에서 시작했다. 안내판이 빈 판으로 보인 사고가 나서 한 줄이 늘었다. 점프가 영구히 잠긴 사고에 또 한 줄, 이펙트가 자기 히트박스에 걸린 사고에 또 한 줄. 다 원인을 찾아서 적어뒀고 같은 사고는 두 번 안 났다. 그렇게 아들과 만드는 로블록스 게임 레포의 CLAUDE.md 가 10KB를 넘었다. 새 세션을 열면 에이전트가 그 10KB를 읽고 시작한다. 필요한 규칙은 그중 두 줄이다. 나머지 문서까지 합치면 250KB인데 그건 아예 안 읽는다. 안 읽은 쪽에 그날 필요한 줄이 있으면 사고가 다시 난다. 트렌딩에 올라온 것들이 같은 얘기를 하고 있었다 이 문제를 어떻게 할지 생각하기 전에, 그날 GitHub 트렌딩을 보고 있었다. 8월 6일 기준으로 하루에 스타를 많이 받은 레포들이 이런 것들이었다. obra/superpowers 는 방법론을 떼어냈다. 스킬을 배포 가능한 패키지로 만든 것이다. addyosmani/agent-skills 도 같은 것인데 70개 이상 에이전트를 타깃으로 잡았다. TencentCloud/TencentDB-Agent-Memory 는 기억을 떼어내서 개인 파일에 있던 걸 팀 공유 자산으로 올렸고, huangruiteng/loopx 는 루프 상태를 떼어내 목표와 게이트와 증거를 커널로 만들었다. 따로 보면 각각 다른 소식인데, 묶어 보면 전부 같은 일을 하고 있다. 작년까지 각자 CLAUDE.md 에 손으로 적던 것을 레이어로 뜯어내는 작업 이다. 방법론, 기억, 루프 상태. 여기에 7월 말에 나온 MCP 명세 개정이 붙는다. 상태를 서버가 들고 있지 않게 바뀌면서 클라이언트·서버 구현이 눈에 띄게 단순해졌다. 내 문제도 정확히 그 목록에 들어가는 종류였다. 규칙과 문서를 CLAUDE.md 한 파일에 쌓아 올리는 대신, 물어보면 답하는 층 으로 떼어내면 된다. 그리고 그걸 붙이는 규격이 MCP다. 다른 프로젝트에서 같은 문제를 그렇게 푼 걸 본 적이 있었다. 프로젝트 문서를 MCP 도구로 노출하...