대부분의 “vs” 페이지는 비교가 아닙니다. 제품 소개 세 편을 이어 붙인 글입니다. 한 도구는 필자가 이미 쓰는 도구이고, 다른 도구는 스크린샷을 찍을 만큼만 엽니다. 과제는 중간에 바뀌고, 가격은 기억에서 가져옵니다. 댓글은 사실 일어나지 않은 비교를 두고 싸웁니다.

Claude Radar는 그래도 비교를 낼 것입니다. 도구 이름을 나란히 적지 않는 것은 일을 피하는 쪽에 가깝습니다. 정직한 쪽은 더 느립니다. 과제를 고정하고, 중단 조건을 고정하고, 운영자가 한 일을 적고, 증거처럼 보이지만 증거가 아닌 주장은 쓰지 않습니다.

이 글이 그 방법입니다. 다른 사람이 이 페이지만 보고 따라 할 수 있는 프로토콜입니다. 시간, 금액, 승률은 공개 픽스처와, 실행 날짜를 기록한 테스트가 있을 때까지 기다립니다.

도구 모음글의 문제

코딩 에이전트는 카메라가 아닙니다. 삼각대에 둘을 올려 같은 벽돌 벽을 찍을 수는 없습니다. 운영자가 루프 안에 있습니다. 프롬프트, 끼어드는 순간, 손대지 못하게 한 파일, “이 정도면 됐다”고 한 테스트. 그 루프가 안 보이면 비교는 성격 검사가 됩니다.

모음글은 범주도 섞습니다. 터미널 에이전트, 인라인 완성이 있는 편집기, 브라우저 앱 빌더는 모두 “할 일 앱을 쓴다”고 할 수 있습니다. 남는 저장소의 종류, 테스트의 종류, 다음 날 이어지는 일의 종류는 같지 않습니다. 서로 바꿔 끼울 수 있는 제품처럼 다루면 로고만 늘어놓은 표와 모호한 마무리 문단이 됩니다.

두 번째 운영자가 그 페이지만 보고 비교를 다시 돌릴 수 없다면, 그건 비교 제목을 단 일기입니다.

우리는 글을 더 적게 내고 싶습니다. 일기인 부분은 일기라고, 비교인 부분은 비교라고 적습니다. 이 프로토콜은 후자용입니다.

무엇을 비교하고, 무엇을 비교하지 않는가

이 매거진은 영어를 우선으로 하되 세계를 염두에 둡니다. 무게 중심은 Claude Code입니다. 이 매거진이 다루는 주제이기 때문입니다. Cursor, Codex, 바이브 코딩 도구는 독자가 실제로 오가기 때문에 같은 시야에 둡니다. 자동화 카탈로그, 템플릿 마켓, “워크플로 1,000개” 디렉터리는 나중에 옆줄로 올 수 있습니다. 이 매거진의 중심은 아닙니다.

비교가 이 사이트에 오려면 아래가 모두 참이어야 합니다.

  • 독자가 슬라이드가 아니라 작동하는 소프트웨어를 만들려 한다.
  • 각 도구를 같은 공개 픽스처에 겨눌 수 있다.
  • “더 빠르게 느껴졌다”가 아닌 완료 기준을 말할 수 있다.
  • 잘 된 런만이 아니라 놓친 것도 공개할 의지가 있다.

출처가 마케팅 페이지, 기억 속의 런칭 데모, 소셜 스레드뿐이면 여기 올 비교가 아닙니다. 공식 문서는 조회일과 함께 인용합니다. 벤치마크로 세탁하지 않습니다.

공유 픽스처

첫 편집 세트의 비교는 작은 공개 웹앱 하나에서 시작해야 합니다. 같은 저장소, 같은 실패 테스트, 같은 README. 픽스처의 요점은 실감을 과장하는 것이 아니라, 조건을 같게 두는 것입니다. Run A가 “머릿속 프로덕션 모노리스를 다시 짓기”이고 Run B가 “카운터 스캐폴드”이면, 우리는 서로 다른 일을 비교한 것입니다.

픽스처는 일부러 지루해야 합니다.

  • 한 번에 읽을 수 있을 만큼 작다.
  • 공개되어 독자가 클론할 수 있다.
  • 고객 비밀, 운영 로그, 사적 이름이 없다.
  • 런 시작 시점에 이미 알려진 이유로 실패하는 테스트가 있다.
  • 이 매거진의 코드베이스와 무관하다. 우리를 띄워 주는 정도로 채점하지 않기 위해서입니다.

첫 공개 픽스처는 쓰는 비교마다 커밋 해시와 함께 연결됩니다. 그 해시가 있기 전에는 비교는 결과가 아니라 방법에 머뭅니다.

프로토콜

따라 적을 수 있게 쓴 단계입니다. 발행된 비교가 한 단계를 건너뛰면, 어떤 단계인지와 이유를 말해야 합니다. 매끄러운 서사 안에 숨기지 않습니다.

  1. 도구를 기록한다. 도구 이름, 채널이나 빌드 식별자, 도구가 노출하는 모델 선택, 편집기나 CLI 버전, OS, 시작한 날짜를 적습니다. 버전을 안 보여 주면 그 사실을 적습니다. 어림하지 않습니다.
  2. 픽스처를 리셋한다. 합의한 커밋에서 시작합니다. 남은 node_modules 잔재, 숨긴 WIP, 비교의 주제가 아닌 스킬·규칙 파일은 없습니다. 시작 트리도 방법의 일부입니다.
  3. 같은 프롬프트 패킷을 건넨다. 런마다 패킷 하나. 기사나 옆 파일에 둡니다. “개인적으로도 말했다”는 없습니다. 제약이 필요하면 개입(4단계)이지, 비밀 서문이 아닙니다.
  4. 개입 횟수를 한도로 둔다. 패킷 이후 운영자 턴은 숫자로 정합니다. “그럴듯해질 때까지”가 아닙니다. 각 개입은 한 줄로: 무엇을 말했는지, 왜, 다른 런이 못 받을 정보를 흘렸는지.
  5. 같은 완료 기준에서 멈춘다. 첫 픽스처에서는 합의된 테스트가 통과하고, 앱이 로컬에서 서빙되고, 스크린샷을 예쁘게 하려고 기능을 몰래 넣지 않은 상태를 기대합니다. 한도 안에 못 가면 미완료이지, 시적인 “거의”가 아닙니다.
  6. 다른 로그를 보기 전에 자기 로그를 저장한다. Run A 노트는 Run B가 없는 것처럼 씁니다. 그다음 반대. 둘 다 저장한 뒤에야 한 표에 넣습니다. 훔쳐보는 것은 일기가 시험인 척하는 방법입니다.
  7. 한계를 표 옆에 공개한다. 재지 않은 것을 나열하지 못하는 비교 페이지는 아직 준비되지 않은 것입니다.

예시 프롬프트 패킷

아래 패킷은 어조와 범위의 표본입니다. 직접 런을 해보고 싶으면 복사하세요. 로컬 시도는 발행된 결과가 아닙니다.

쉬운 말로 된 과제: 작은 TypeScript 앱에 세션 노트 파서를 더해, 이미 모양을 적어 둔 테스트에 맞춰 원문 텍스트가 구조화된 노트가 되게 한다.

You are working in a small public web app at the tagged commit.

Add `src/notes/parseNote.ts` so the tests in
`src/notes/parseNote.test.ts` pass. Do not add features
the tests do not describe. Do not rewrite unrelated files.

Constraints:
- TypeScript, no new dependencies.
- Refuse sample data that looks like a real person.
- If a test is unclear, stop and ask one question.
  Do not invent a business rule.

Stop when `npm test` is green for that file, or when you
cannot proceed without a decision from me. Write a short
summary of files touched and any test you could not satisfy.

패킷이 가리키는 테스트는 픽스처에 이미 있어야 합니다. 도구가 자기 숙제를 채점하지 않게 하려는 것입니다.

무엇을 기록할 것인가

표는 이후 비교 페이지의 계약입니다. 빈칸은 “재지 않았다”이지 “괜찮다”가 아닙니다. 형용사로 채우지 않습니다.

기준 기록하는 것 추론하지 않는 것
완료 여부 개입 한도 안에서 합의된 테스트가 통과했는지. 그 도구가 “엔지니어링에 더 낫다”는 말.
작동까지 시간 측정하기로 했다면, 이름 있는 기계에서 시작부터 끝까지 잰 경과 시간. 팀 생산성, 피곤한 오후에도 같은 결과가 나온다는 말.
수정 품질 diff 크기, 손댄 파일, 여전히 통과하는 테스트, 무관한 재작성. 취향, 연차, “클린 아키텍처.”
운영자 노력 실제로 보낸 개입의 수와 문장. 운영자 일반의 숙련.
비용 도구가 노출하는 계량 사용량만, 날짜와 플랜 이름과 함께. 아니면 “미공개.” 당신의 월 청구서, 정가 순위.
실패 방식 어디서 멈췄는지, 무엇을 깨뜨렸는지, 어떻게 회복했는지 — 또는 못 했는지. 모델의 성격.
설정 마찰 설치, 로그인, 프로젝트 훅을 체크리스트로. 긴 설정이 항상 더 나쁘다는 말.

발행된 비교가 담을 것

후보 목록을 떠날 때 페이지에는 다음이 있어야 합니다.

  • 픽스처 해시와 프롬프트 패킷.
  • 1단계에서 기록한 도구 목록.
  • 양쪽 로그, 또는 놓친 것을 빼지 않은 공정한 요약.
  • 빈칸을 빈칸으로 둔 기준 표.
  • 플랜 이름이나 한도에 쓴 공식 문서 링크와 조회일.
  • 정정 칸. “아직 없음”이어도 됩니다.

나중에 제휴 링크나 스폰서를 넣으면 라벨을 붙이고 채점 표 밖에 둡니다. 상업 관계 뒤에 움직이는 순위는 새로고침이 아니라 정정입니다.

한계

이 프로토콜은 이미 편향되어 있습니다. 포장하기보다 이름을 붙이겠습니다.

  • 픽스처 하나가 산업이 아닙니다. 작은 TypeScript 앱의 파서는 네이티브 모바일, 데이터 노트북, 백만 줄 모노레포를 거의 말하지 않습니다.
  • 운영자는 변수입니다. 다른 사람은 더 빨리, 또는 전혀 끼어듭니다. 우리의 개입은 기록할 수 있어도 우리 자신을 뺄 수는 없습니다.
  • 도구는 움직입니다. 실행 날짜를 기록한 테스트는 그 날짜의 결과입니다. 옛 표를 현재 사건처럼 다시 입히지 않습니다.
  • 노출된 계량은 불완전합니다. 요금제에 사용량이 묶여 항목별 비용이 보이지 않으면 비용 칸을 지어낼 수 없습니다.
  • 아직 비교를 돌리지 않았습니다. 빈 표는 실행 날짜를 기록한 테스트가 있을 때까지 비어 있습니다.
  • 독립은 말뿐인 태도가 아니라 실제 작업 방식입니다. 이름에 Claude가 있다고 그 도구에 점수를 더 줄 권한은 없습니다. 특정 도구를 편드는 글로 읽히면, 그 비교는 방법에서 벗어난 것입니다.

출처 정책

출처 네 종류를 구별하고, 섞어 쓰지 않습니다.

  1. 공식 문서 — URL과 조회일과 함께 인용하거나 풀어 씁니다. 가격과 한도 숫자는 여기서 오거나, 나오지 않습니다.
  2. 우리의 픽스처와 로그 — 들여다볼 수 있을 만큼 공개. 고객 작업은 넣지 않습니다.
  3. 다른 저널리즘과 일차 글 — 세상에 대한 주장의 출처일 때 연결합니다. 건너뛴 런을 대체하지 않습니다.
  4. 마케팅 언어 — 업체가 한 말의 인용으로만. 측정이 아닙니다.

사적 채팅을 긁지 않고, 내부 런북을 붙이지 않으며, 소셜 스크린샷을 버전 번호로 쓰지 않습니다. 제휴나 스폰서가 있으면 그 링크가 있는 페이지에 이름을 올립니다.

정정 정책

발행된 비교가 틀리면 페이지는 공개적으로 바뀝니다.

  • 사실 오류(잘못된 버전, 플랜 이름, 테스트 오독)는 상단이나 정정 칸에 날짜와 함께 적고 본문을 고칩니다.
  • 새 런은 새 런입니다. 말하지 않고 옛 표를 덮어쓰지 않습니다.
  • 상업 계약, 업체 메일, 트래픽이 나쁜 밤 뒤에 순위를 조용히 바꾸지 않습니다.
  • 이 프로토콜로 문장을 지키지 못하면 창피가 아니라 그 문장을 지웁니다.

아직 비교를 발행하지 않았으므로 고칠 것이 없습니다. 정정 칸을 미리 두는 것은, 나중에 발행할 글도 같은 방식으로 고치기 위해서입니다.