라벨이 하네스인 게시물 표시

Buzz 워크플로우는 액션이 일곱 개인데 셋은 로그만 남기고 성공한다

이미지
리뷰 영상 네 편을 봤습니다. 네 편 다 설치부터 시연까지 보여주고, 네 편 다 된다고 말합니다. 그런데도 코드를 열었습니다. 굳이 연 이유는 네 편의 순서가 전부 똑같았기 때문입니다. "된다"를 보여주고 나서 "그런데 이건 아직"을 덧붙이는데, 그 "이건 아직"이 네 편 모두 같은 기능에 걸려 있었습니다. 한 편이 걸리면 그 사람 환경 문제입니다. 네 편이 같은 자리에서 걸리면 화면 문제가 아니라 그 아래 문제입니다. 리뷰 영상은 되는 걸 보여주려고 만듭니다. 안 되면 다시 찍거나 그 대목을 잘라냅니다. 그 편향을 뚫고 네 편에 다 남아 있다면, 다시 찍어도 안 되고 잘라내면 흐름이 끊기는 자리라는 뜻입니다. crates/buzz-workflow/src/executor.rs 532번째 줄에 이렇게 적혀 있었습니다. /// For MVP, most actions log their intent and return a success output. /// Real event emission is wired in WF-07/08 (relay integration). 대부분의 액션이 무엇을 하려 했는지를 로그로 남기고 성공 출력을 반환한다 고, 코드가 자기 입으로 적어놓았습니다. 한 줄로 설명이 안 되는 물건입니다 Buzz 는 Block 이 공개한 오픈소스입니다. Apache 2.0 이라 가져다 고쳐 써도 됩니다. 그런데 이게 뭘 하는 물건인지가 한 줄로 안 잡힙니다. 채팅앱이라고 하기엔 git 저장소를 품고 있고, 개발 도구라고 하기엔 채널과 DM 이 있습니다. 공식 설명은 사람과 에이전트가 같이 일하는 작업 공간이라고 되어 있습니다. 구조는 세 덩어리로 보면 정리가 됩니다. relay 와 agent 와 community 입니다. relay 는 Rust 로 짠 서버인데, 메시지든 반응이든 git 이벤트든 전부 여기 하나의 로그로 쌓입니다. 사람도 에이전트도 각자 키를 가지고, 남기는 흔적마...

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인 협동 관찰 공포, 전투 없음)와 「몬스터 군도...

코딩 에이전트 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 도구로 노출하...