커서·클로드코드·코덱스 중 딱 하나만 골라야 한다면요?

작업 폭이 넓고 빠짐없이·깊이가 중요하다면 클로드코드가 안전한 기본값입니다. IDE에서 diff를 보며 가고 싶으면 커서, 맨바닥에서 빠르게 찍어내는 일이 많으면 코덱스가 더 맞을 수 있습니다. 무료로 자기 작업에 셋을 시켜보고 정하길 권합니다.

AI 코딩 도구, 초보는 뭐부터 시작하나요?

IDE가 익숙하면 커서, 터미널이 편하면 클로드코드부터입니다. 코덱스는 던져두고 결과를 받는 방식에 익숙해진 뒤 붙이는 게 자연스럽습니다.

세 도구 비교의 공통 결론은 무엇인가요?

어떤 도구든 빠르게 만들어줄수록 사람의 검수가 실력이 됩니다. 디버깅·스캐폴딩·리팩토링·테스트·코드리뷰 다섯 작업 모두에서 같은 결론에 도달했습니다 — AI는 검수를 대신하는 게 아니라 검수를 잘하게 돕는 도구입니다.

Devin 성공률을 높이는 가장 큰 요인은 무엇인가요?

작업 설명(명세)의 품질입니다. 재현 절차·기대 결과·관련 파일·검증 방법을 구체적으로 줄수록 성공하고, 모호한 지시는 러빗홀로 갑니다. 초반 계획을 확인해 방향을 잡아주는 것도 중요합니다.

커버리지 100%면 테스트가 충분한 건가요?

아닙니다. 커버리지는 모든 줄이 실행됐다만 뜻하고 모든 경우가 검증됐다가 아닙니다. 커버리지 100%에 가까운 테스트가 음수·null 같은 엣지케이스 버그를 하나도 못 잡는 경우가 흔합니다.

AI 코딩 도구를 세 개 다 결제해야 하나요?

아니요. 하나로 시작해 부족할 때 하나를 더합니다. 무료·체험으로 자기 코드에 같은 리팩토링을 시켜보고 정하는 것이 가장 정확합니다.

DevPilot

Devin에 큰 작업을 맡길 때, PR은 어디서 나눠야 할까?

DevPilot — Thu, 1 Oct 2026 08:06:43 +0900

Devin에 API와 화면 수정을 함께 맡기면서 “PR은 백엔드와 프론트엔드로 나눠줘”라고 요청할 수 있습니다. 그런데 폴더가 다르다는 이유만으로 나누면, 먼저 배포된 쪽이 기존 화면을 깨뜨릴 수 있어요. 나눌 때 확인할 것은 각 PR이 끝난 시점의 동작입니다.

PR마다 이 질문을 붙여보세요. “이 변경만 먼저 들어가도 지금 사용 중인 버전이 동작하는가?” 안 된다면 선행 변경과 적용 순서를 명시하거나, 호환되는 중간 단계를 먼저 만들어야 합니다.

2026-10-01 작성. 아래 코드는 API 응답과 화면의 읽기 동작을 단순화한 설명용 예제입니다. 실제 Devin의 작업 결과나 운영 장애를 재현한 후기가 아닙니다.

이름 하나를 바꿔도 서버와 화면의 순서가 생깁니다

사용자 정보의 name을 displayName으로 바꾼다고 가정해보겠습니다. 여기서는 필드 이름만 바뀌며, 값의 의미는 같습니다. 기존 화면은 응답에서 user.name을 읽고 있어요.

// 기존 응답
{ name: "Mina" }

// 이름을 바로 바꾼 응답
{ displayName: "Mina" }

서버 PR을 먼저 배포하면 기존 화면이 찾는 name이 사라집니다. 순서를 바꿔 새 화면을 먼저 배포해도, 이전 서버에는 displayName이 없어요. 새 서버와 새 화면을 함께 확인할 때만 보면 놓치기 쉬운 조합입니다.

Google의 API 설계 지침인 AIP-180도 필드 이름 변경을 기존 항목의 삭제와 새 항목의 추가로 봅니다. 같은 메이저 버전에서 기존 항목을 제거하지 말라는 원칙을 제시해요. “이름만 바꿨다”는 설명으로 호환성 검토를 생략할 수 없는 이유입니다. AIP-180의 삭제·이름 변경 지침

먼저 두 이름이 함께 있는 상태를 만듭니다

이 예제라면 첫 PR에서 응답에 displayName을 추가하고 name은 유지하겠습니다. 다음 PR에서 화면을 전환하고, 기존 필드의 제거 여부는 별도로 판단합니다. 둘 다 반환하는 동안에는 같은 원본 값에서 만들어 값이 어긋나지 않게 합니다.

PR 1: 기존 화면을 유지하면서 응답을 확장합니다

응답을 { name: "Mina", displayName: "Mina" }로 만듭니다. 이 PR의 완료 조건은 기존 화면이 그대로 이름을 읽고, 새 필드에서도 같은 값을 읽을 수 있는 것입니다. 필드를 추가하는 일이라도 엄격한 응답 검증을 하는 클라이언트가 있다면 그 검증도 확인해야 합니다.

PR 2: 화면을 전환하고 이전 서버에 대한 동작을 정합니다

화면이 displayName을 우선 사용하도록 바꿉니다. 서버가 이전 버전으로 돌아갈 가능성까지 지원하려면, 이 예제에서는 displayName ?? name으로 읽는 방법을 택할 수 있어요. 새 필드가 없거나 null이면 기존 필드를 읽습니다.

기존 필드 제거는 지원 정책을 확인한 뒤 결정합니다

구버전 앱이나 오래 열린 웹 화면, 외부 연동이 name을 계속 읽을 수 있습니다. 이들이 남아 있다면 필드를 유지해야 합니다. 공개 API의 호환성 약속이 있다면 새 버전 제공이나 정해진 폐기 절차가 필요할 수 있고요. 화면 PR을 합쳤다는 사실만으로 삭제 조건이 충족되지는 않습니다.

PR은 코드를 검토하고 합치는 단위이고, 배포는 사용자가 받을 버전을 바꾸는 작업입니다. PR을 나눴다고 배포 순서가 자동으로 정해지지는 않습니다. 각 PR 설명에 선행 변경과 적용 조건도 적어두세요.

9가지 조합을 실행해 보면 빠진 조건이 보입니다

응답 세 가지와 읽기 함수 세 가지를 조합했습니다. original은 기존 응답, expanded는 두 필드가 있는 응답, contracted는 기존 필드를 제거한 응답입니다. old는 기존 필드만, new는 새 필드만, fallback은 새 필드를 우선하되 기존 필드도 읽습니다.

아래 코드를 compatibility.mjs로 저장하고 Node.js에서 실행할 수 있습니다. HTTP 서버나 화면을 띄우지 않고 읽은 값이 예상 이름과 같은지만 확인합니다. 이름이 없는 두 조합도 의도한 비교 대상이라, 예상 결과와 일치하면 프로그램은 정상 종료합니다.

// Explanatory in-memory API/client combinations, not a Devin session.
import assert from 'node:assert/strict';

const responses = {
  original: { name: 'Mina' },
  expanded: { name: 'Mina', displayName: 'Mina' },
  contracted: { displayName: 'Mina' },
};

const readers = {
  old: (user) => user.name,
  new: (user) => user.displayName,
  fallback: (user) => user.displayName ?? user.name,
};

const expected = {
  original: { old: true, new: false, fallback: true },
  expanded: { old: true, new: true, fallback: true },
  contracted: { old: false, new: true, fallback: true },
};

for (const [api, payload] of Object.entries(responses)) {
  for (const [client, read] of Object.entries(readers)) {
    const value = read(payload);
    const compatible = value === 'Mina';
    assert.equal(compatible, expected[api][client]);
    console.log(`${api} / ${client}: ${compatible ? 'OK' : 'MISSING'} (${String(value)})`);
  }
}

node compatibility.mjs

Node.js v22.12.0에서 확인한 출력입니다. MISSING은 이 예제에서 기대한 이름을 읽지 못했다는 표시이지, Devin이나 HTTP의 오류 코드가 아닙니다.

original / old: OK (Mina)
original / new: MISSING (undefined)
original / fallback: OK (Mina)
expanded / old: OK (Mina)
expanded / new: OK (Mina)
expanded / fallback: OK (Mina)
contracted / old: MISSING (undefined)
contracted / new: OK (Mina)
contracted / fallback: OK (Mina)

기존 화면은 확장된 응답에서는 이름을 읽지만, 기존 필드를 제거한 응답에서는 undefined를 얻었습니다. 새 필드만 읽는 화면 역시 기존 서버의 응답에서는 값을 얻지 못했어요. 두 필드를 지원하는 함수는 이 예제의 세 응답에서 모두 이름을 읽었습니다.

“문제 생기면 서버만 되돌리자”도 확인이 필요합니다

새 화면이 displayName만 읽는데 서버를 이전 응답으로 되돌리면 어떨까요? 위 출력의 original / new 조합이 됩니다. 앞으로 적용하는 순서뿐 아니라, 되돌렸을 때 만나는 조합도 작업 범위에 넣어야 합니다.

그렇다고 모든 필드에 ??를 붙이면 해결되는 것은 아닙니다. 이번에는 이름만 바뀌었고 두 필드의 의미가 같다는 전제가 있어요. null이 “이름을 숨김”이라는 의도적인 값이라면 기존 이름을 다시 보여주는 동작은 잘못일 수 있습니다. 빈 문자열도 ??의 대체 조건에 포함되지 않습니다.

예제에서는 실제 API 응답 검증, 데이터 저장, 브라우저 캐시, 앱 업데이트 상태까지 확인하지 않았습니다. 실서비스에서는 지원할 버전 조합과 값의 의미를 먼저 정하고, 그 조건에 맞는 검증을 붙여야 합니다.

Devin에는 구현 전에 나눌 경계부터 요청합니다

Devin 공식 가이드도 큰 작업을 집중된 작업으로 나누고, 시작과 끝 및 성공 조건을 명확히 정하라고 권합니다. 독립적인 작업을 병렬로 진행하는 것과, 앞 작업의 결과가 필요한 작업을 동시에 맡기는 것은 구분해야 해요. 작업 범위를 정하는 공식 가이드

저라면 “백엔드 PR과 프론트엔드 PR로 나눠줘” 대신 아래 요청으로 시작하겠습니다. 구현할 파일 목록을 받기 전에, 사용하는 쪽과 배포 중에 생길 조합부터 확인하는 요청입니다.

사용자 정보의 name을 displayName으로 전환하려고 한다.
우선 수정하지 말고 작업을 나눌 계획을 작성해줘.

1. 응답을 만드는 곳과 읽는 곳을 찾아 경로를 적어줘.
   이 저장소에서 확인할 수 없는 외부 사용자는 미확인으로 남겨줘.
2. 기존 버전과 새 버전이 섞이는 동안 필요한 중간 상태를 제안해줘.
3. 각 PR에 다음 내용을 적어줘.
   - 바꾸는 동작과 이번 PR에서 유지할 동작
   - 선행 PR 및 배포 순서
   - 따로 배포 가능한지와 그 조건
   - 검증할 버전 조합, 실행 방법, 완료 조건
   - 되돌릴 경우 지원할 조합과 제한
4. 기존 필드의 제거는 별도 항목으로 두고,
   구버전 사용 여부와 호환성 정책을 확인하기 전에는 진행하지 마.

계획을 검토한 뒤 응답 확장 단계부터 구현을 요청하겠다.

이 요청은 구현 범위와 성공 조건, 참고할 코드를 구체적으로 전달하라는 공식 지침을 예제에 맞게 풀어 쓴 것입니다. 실제 파일 경로와 API 동작은 저장소 조사 결과로 채워야 합니다. 지시문 작성 공식 가이드

모든 작업을 세 PR로 만들 필요는 없습니다. 함께 배포되는 작은 변경은 한 PR이 더 명확할 수도 있고, 서로 기대는 PR로 검토 순서만 나눌 수도 있어요. 다만 의존성이 있는 PR을 독립적으로 배포 가능한 것으로 표시하면 안 됩니다.

자주 묻는 질문

PR은 파일 수나 변경 줄 수로 나누면 되나요?

크기는 검토 부담을 가늠하는 데 도움이 되지만, 경계를 정하는 유일한 기준은 아닙니다. 각 변경의 완료 조건과 선행 작업, 중간 버전의 호환성을 함께 봐야 합니다.

새 화면이 배포되면 기존 API 필드는 바로 지워도 되나요?

구버전 앱, 오래 열린 웹 화면, 외부 연동이 기존 필드를 사용하는지 확인해야 합니다. 지원 정책과 제거 조건이 충족되기 전에는 유지하고, 공개 API라면 버전 및 폐기 정책도 따라야 합니다.

다음 PR 없이도 설명할 수 있는 완료 조건을 적습니다

첫 PR의 완료 조건은 “새 필드를 추가했다”에서 끝내지 않겠습니다. “기존 화면이 계속 이름을 읽고, 새 필드에서도 같은 값을 읽는다”까지 적어두겠습니다. 그러면 다음 작업이 늦어져도 현재 상태를 검토할 기준이 남습니다.

완성된 PR을 어떻게 확인할지는 Devin이 만든 PR, 테스트 통과만 보고 합쳐도 될까?에서 이어집니다. Devin의 기본 작업 방식은 Devin 소개 글에, 작업 도중 같은 오류가 반복될 때의 확인 순서는 반복 오류 진단 글에 정리했습니다.

공식 자료 확인: 2026-10-01. 로컬 실습: Node.js v22.12.0에서 응답 객체 3개와 읽기 함수 3개의 조합 확인. 실제 Devin 실행, HTTP 통신, 화면 렌더링, 운영 배포 및 시간·비용 변화는 측정하지 않았습니다. 도식은 설명용 생성 이미지입니다.

Devin에 같은 설명을 반복한다면? AGENTS.md에 남길 것과 빼야 할 것

DevPilot — Mon, 28 Sep 2026 21:45:06 +0900

“검색에 실패한 걸 결과가 없는 것으로 처리하면 안 돼.” 이런 설명을 작업마다 다시 적고 있다면, 다음 요청에도 필요한 기준인지부터 보세요. 프로젝트에서 계속 지킬 동작이라면 AGENTS.md에 남길 후보입니다. 이번 버그를 재현하는 입력이나 임시 우회 방법은 따로 두고요.

옮길 것은 대화 전체가 아니라, 다음 작업에도 유효한 기준입니다. 짧은 프로젝트 규칙은 AGENTS.md에, 이번 작업의 입력과 완료 조건은 요청문에, 반복하는 긴 절차는 Skills나 별도 문서에 두는 구성을 권합니다.

2026-09-28 공식 문서 확인 기준입니다. 아래 파일은 글을 위해 만든 설명용 예제이며, 실제 Devin 세션에서 규칙 적용률을 측정한 사용 후기는 아닙니다.

“다음에도 같은 답인가?”로 남길 문장을 고릅니다

지난 글에서는 같은 오류가 반복될 때 실행 환경과 요구사항, 수정 가설을 확인했습니다. 오류를 해결한 뒤에는 질문이 하나 더 남습니다. 다른 기능을 고칠 때도 이 설명을 다시 해야 할까요?

예를 들어 “검색 실패 시 오류 안내와 재시도 버튼을 표시한다”는 합의된 제품 동작입니다. 반면 “오늘 확인한 이 검색어로 오류를 재현해 달라”는 이번 작업의 조건이에요. 둘을 같은 문서에 계속 쌓으면, 나중에는 예전 작업의 입력까지 상시 규칙처럼 남습니다.

AGENTS.md: “검색 실패를 성공한 빈 결과로 바꾸지 않는다.” 프로젝트에서 합의했고 앞으로도 유지할 기준입니다.
이번 요청: 재현 입력, 현재 오류 로그, 이번에 바꿀 범위와 완료 조건을 적습니다.
Skills 또는 별도 문서: 서버 준비부터 화면 확인, 결과 보고까지 여러 작업에서 반복할 절차를 적습니다.

이 구분이 기능상 엄격한 경계는 아닙니다. AGENTS.md에도 테스트 명령을 적을 수 있어요. 다만 짧은 규칙 한 줄을 읽는 데 지난 장애의 로그 수십 줄까지 따라오게 할 필요는 없습니다.

“잘 고쳐줘”를 확인 가능한 문장으로 바꿉니다

저라면 “버그 없이 수정할 것”부터 지우겠습니다. 틀린 말은 아니지만, 결과를 검토할 때 무엇을 확인해야 할지 알려주지 않거든요. PR 검토 글의 검색 화면 예제처럼 구체적인 조건을 붙이면 문장의 쓰임이 달라집니다.

바꾸기 전: 검색 화면을 안정적으로 만들고 테스트를 잘 해줘.
바꾼 뒤: 검색 실패를 성공한 빈 결과로 바꾸지 않는다. 검색 상태를 바꾼 작업은 로딩, 실패, 성공한 빈 결과, 성공한 결과를 각각 확인한다.

“실패와 빈 결과를 구분한다”는 동작 기준이고, “네 상태를 각각 확인한다”는 검토 기준입니다. 둘을 같이 적으면 수정 결과를 볼 때도 같은 질문을 사용할 수 있어요. 문장은 짧아도 확인할 대상은 구체적입니다.

다만 이 동작이 모든 서비스의 정답은 아닙니다. 실패해도 이전 검색 결과를 유지하는 제품이라면 그 정책에 맞춰 써야 합니다. 합의하지 않은 제품 결정을 규칙 파일에 먼저 넣지는 마세요.

처음에는 이 정도 파일로도 시작할 수 있습니다

Devin 공식 문서는 프로젝트 루트 등에 AGENTS.md를 두면 코딩을 시작하기 전에 파일을 찾는다고 설명합니다. 아래는 검색 화면에 적용할 규칙만 담은 예제입니다. 실제 프로젝트에 맞춰 수정한 뒤, Devin이 작업할 저장소와 브랜치에서 읽을 수 있도록 반영하세요. 공식 AGENTS.md 안내

# 검색 화면 프로젝트 규칙

이 파일은 설명용 예제다. 실제 프로젝트의 합의된 동작에 맞게 고쳐 사용한다.
적용 대상: 검색 요청과 검색 결과 화면을 변경하는 작업.

## 유지할 동작
- 검색 실패를 성공한 빈 결과로 바꾸지 않는다.
- 요청 성공이 확인되고 결과가 0개일 때만 빈 결과 안내를 표시한다.
- 검색 실패 시 오류 안내와 재시도 버튼을 표시한다.

## 확인할 조건
- 검색 상태를 바꾼 작업은 로딩, 실패, 성공한 빈 결과, 성공한 결과를 각각 확인한다.
- 기존 설정과 CI에서 실제 검증 명령과 실행 위치를 확인한다. 없는 명령을 추정하지 않는다.
- 확인하지 못한 조건은 통과로 보고하지 않고, 막힌 이유를 적는다.

## 작업 결과에 남길 것
- 바꾼 동작과 파일, 실행한 명령과 결과, 아직 확인하지 못한 조건을 구분해 적는다.

예제에는 npm test 같은 명령을 임의로 넣지 않았습니다. 프로젝트에서 실제로 쓰는 명령과 실행 폴더를 확인했다면 그 자리에 구체적으로 적으세요. 이미 AGENTS.md가 있다면 새 파일로 덮어쓰지 말고, 관련 항목에 필요한 기준만 합치는 편이 좋겠습니다.

지난 오류의 임시 조치도 그대로 가져오지 않습니다. 예를 들어 실습을 통과하려고 사용한 통화 값 KRW는 모든 보고서가 지켜야 할 기본값이 아니에요. 상시 규칙으로 남기려면 “통화 설정이 없을 때 임의 기본값을 넣어도 되는가”부터 제품 담당자와 정해야 합니다.

Devin은 파일의 앞 16KiB를 자동으로 포함합니다

파일이 길어지면 이 부분을 확인해야 합니다. 공식 문서에 따르면 Devin은 각 AGENTS.md의 앞 16KiB, 즉 16,384바이트까지 컨텍스트에 자동으로 포함합니다. 그 뒤 내용은 필요하면 전체 파일을 추가로 읽을 수 있지만, 자동 포함 범위에는 들어가지 않습니다. 자동 포함 범위와 긴 문서 구성

여기서 기준은 줄 수가 아니라 바이트입니다. 같은 줄 수라도 한글과 영문, 코드가 섞인 정도에 따라 파일 크기가 달라져요. macOS·Linux에서는 파일이 있는 폴더에서 아래 명령으로 확인할 수 있습니다.

wc -c AGENTS.md

이 글의 예제 파일은 UTF-8, LF 줄바꿈으로 저장했을 때 964바이트였습니다. 바이트와 글자 수의 차이도 별도로 확인했습니다. 한글 “가”만 6,000번 반복한 문자열은 UTF-8에서 18,000바이트였어요.

text = "가" * 6000
print(len(text), len(text.encode("utf-8")))
# 실행 출력: 6000 18000

이 확인은 파일 크기 계산입니다. Devin이 실제 세션에서 어디까지 읽었는지 시험한 결과는 아니에요. 16KiB를 목표 분량으로 채울 이유도 없습니다. 계속 필요한 기준을 앞에 두고, 긴 로그나 상황별 절차는 별도 문서로 빼면 됩니다.

Knowledge에 저장하라는 예전 안내는 다시 확인하세요

공식 문서를 확인하다 눈에 띈 변경도 있습니다. 2026년 9월 28일 기준 Knowledge 안내에는 폐기 예정이며, 기존 내용은 Plugins의 Skills로 자동 이전 중이라는 공지가 있습니다. 이전은 순차적으로 진행되고, 새 지침은 Skills로 작성하라고 안내합니다. 모든 계정에서 이미 이전이 끝났다는 뜻은 아닙니다. Knowledge 전환 공지

저장소에 직접 만드는 Skill은 .agents/skills/<skill-name>/SKILL.md 경로가 권장됩니다. 이름과 설명으로 어떤 절차인지 알리고, 호출할 때 본문을 읽는 방식입니다. Knowledge에서 이전된 내용은 Devin이 관리하는 Plugins에 저장되므로, 저장소에 같은 파일을 다시 만들 필요는 없습니다. Skills 안내 · 이전 FAQ

규칙이 몇 줄이라면 AGENTS.md부터 정리하겠습니다. “어떤 서버를 띄우고, 어떤 화면을 확인하고, 무엇을 보고할지”가 긴 순서로 반복될 때는 Skills로 옮길지 살펴보세요.

파일을 만들었으면, 다음 작업에서 읽은 내용을 확인합니다

파일 저장만으로 작업 결과까지 보장되지는 않습니다. 다음 작업을 시작할 때 아래처럼 요청해, 의도한 규칙과 실제 작업 위치가 맞는지 확인할 수 있습니다. 특히 다른 브랜치를 보고 있거나 경로가 바뀌었다면 문서부터 바로잡아야 합니다.

수정 전에 이번 작업에 적용할 규칙을 먼저 정리해줘.
- 현재 저장소와 브랜치, 읽은 규칙 파일의 경로
- 이번 변경과 관련 있는 규칙 및 적용 대상
- 실제 검증 명령과 실행 위치, 그 명령을 확인한 설정 파일

문서끼리 충돌하거나 없는 경로를 가리키면 그 부분을 먼저 알려줘.
이번 작업의 입력과 완료 조건은 이 요청에 별도로 적겠다.

규칙을 정확히 요약했다고 실제 구현까지 맞다는 증거가 되지는 않습니다. 작업이 끝나면 “실패와 빈 결과를 각각 확인했는가”를 결과와 함께 봐야 해요. 같은 문장을 계속 덧붙이기보다는, 지켜지지 않은 이유가 파일 위치인지, 문장의 모호함인지, 검증 누락인지 좁혀보는 편이 낫겠습니다.

자주 묻는 질문

AGENTS.md에 대화 내용을 전부 붙여도 되나요?

다음 작업에도 유효한 기준만 추리는 편이 좋습니다. 이번 작업의 입력과 임시 조치는 요청문에, 반복하는 긴 절차는 Skills나 별도 문서에 남기세요.

16KiB를 넘으면 Devin이 나머지를 읽지 못하나요?

읽을 수 있습니다. 공식 문서는 각 파일의 앞 16KiB까지 자동으로 포함하고, 그 뒤 내용은 필요할 때 전체 파일을 추가로 읽을 수 있다고 설명합니다.

오늘은 반복해서 설명한 기준 하나만 남겨보세요

“이 작업이 끝나도 이 문장이 필요한가?”를 먼저 묻고, 필요하다면 적용 대상과 확인 조건을 붙여 적습니다. 저는 규칙의 개수보다 다음 수정 결과를 보고 지켰는지 판단할 수 있는가를 기준으로 삼겠습니다. 오래된 임시 조치가 섞여 있다면 새 규칙을 더하기 전에 지우거나 고칠 항목부터 살펴보세요.

Devin 자체의 작업 방식이 궁금하다면 Devin 소개와 한계를, 이미 같은 오류가 반복되고 있다면 다시 시키기 전에 확인할 것을 이어서 볼 수 있습니다.

공식 자료 확인: 2026-09-28. 설명용 파일의 바이트 수와 Python 문자열 인코딩 결과를 로컬에서 확인했습니다. 실제 Devin 세션의 규칙 적용, 작업 시간·비용 변화는 측정하지 않았습니다. 그림은 설명용 생성 도식입니다.

Devin이 같은 오류를 반복할 때, 다시 시키기 전에 확인할 것

DevPilot — Fri, 25 Sep 2026 22:37:01 +0900

Devin이 같은 오류를 다시 보고했을 때, 바로 “다시 고쳐줘”라고 보내기 전에 볼 것이 있습니다. 이번 시도에서 달라진 조건이 무엇인지입니다. 코드만 달라졌는지, 실행 환경도 달라졌는지, 아니면 같은 명령을 다시 돌렸는지부터 구분해야 해요.

다시 시키기 전 확인할 것: 실패한 명령과 오류를 남기고, 실행 환경·요구사항·수정 방향 중 어디를 더 확인할지 정합니다. 다음 시도에는 가설과 확인 방법을 하나씩 붙입니다. 아래 실습에서는 설정이 빠진 실행이 세 번 모두 실패했고, 설정을 전달한 뒤 같은 소스로 정상 종료했습니다.

2026-09-25 작성. Node.js v22.12.0에서 실행한 설명용 예제와 공식 문서를 바탕으로 정리했습니다. 세 번의 재실행은 직접 구성한 실습이며, 실제 Devin이 반복 실패한 사용 후기가 아닙니다. 도식도 실제 제품 화면이 아닙니다.

“또 실패”를 명령·위치·오류로 풀어 적습니다

화면에 같은 문구가 보여도 원인은 달라질 수 있습니다. 반대로 코드가 여러 번 바뀌었어도, 설정을 읽는 첫 단계에서 멈췄다면 고친 코드까지 실행되지 않았을 수 있어요.

우선 진행 중인 수정을 잠시 멈추고 아래 정보를 요청하겠습니다. 에러 메시지뿐 아니라 어디서 무엇을 실행했는지가 있어야 이전 시도와 비교할 수 있습니다.

지금은 추가 수정하지 말고 실패 지점을 정리해줘.
- 실행한 명령과 작업 폴더, 런타임 버전
- 실패를 설명하는 오류 부분과 종료 코드
- 직전 시도에서 바꾼 파일 또는 실행 조건
- 그 변경 뒤 새로 확인한 사실
사실과 원인 추정을 구분해줘. 비밀 값은 제외해줘.

예를 들어 “테스트 실패”와 “테스트 실행 도구를 찾지 못함”은 다음 행동이 다릅니다. 실행 자체가 안 됐다면 기능 구현을 다시 고치기 전에 설치·실행 경로부터 확인해야 합니다.

막힌 지점에 따라 다음 요청도 달라집니다

실행 환경에서 막혔다면, 먼저 실행 가능한 상태를 만듭니다

필요한 설정, 패키지, 실행 파일, 저장소 접근이 있는지 봅니다. “파일 없음”이라는 문구도 파일이 실제로 없는 것인지, 다른 폴더에서 실행한 것인지부터 확인해야 해요. 문구 하나로 설치 문제라고 단정하지 않습니다.

다음 요청: 기능 코드는 잠시 두고, 이 명령이 시작되는 데 필요한 조건을 확인해줘. 현재 작업 폴더와 런타임, 누락된 설정 이름을 정리하고 최소 실행부터 확인해줘. 비밀 값은 출력하지 마.

원하는 결과가 갈린다면, 사람이 기준을 정해야 합니다

“검색 오류를 없애줘”는 오류 안내를 없애라는 뜻으로도 읽힙니다. 검색 실패 시 재시도 안내를 보여줄 것인지, 이전 결과를 남길 것인지부터 정해야 해요. 실행이 성공해도 이 기준이 없으면 수정이 오갈 수 있습니다.

다음 요청: 검색 실패는 빈 결과로 처리하지 않아. 실패하면 오류 안내와 재시도 버튼을 보여주고, 성공했는데 결과가 0개일 때만 빈 결과 안내를 표시해줘. 이 둘을 구분해 검증해줘.

입력과 기준이 분명한데 실패한다면, 가설을 하나씩 확인합니다

같은 테스트에서 실패한다고 해서 시도마다 아무 진전이 없었던 것은 아닙니다. 한 원인을 배제한 것도 정보예요. 다만 “이번에는 다른 방식으로 수정”만 반복한다면, 어떤 가설을 확인했는지 알기 어렵습니다.

다음 요청: 가장 가능성 높은 원인 하나와 그 근거를 적어줘. 어떤 확인 결과가 나오면 그 가설을 배제할 수 있는지도 정하고, 그 확인부터 진행해줘. 관련 없는 리팩토링은 보류해줘.

이 세 가지는 완전히 분리된 원인 목록은 아닙니다. 환경이 정상인 것을 확인한 뒤에야 구현 결함이 드러날 수도 있어요. 지금 다음으로 확인할 지점을 고르기 위한 구분입니다.

작은 실습: 세 번 실행해도 빠진 설정은 생기지 않습니다

이번 예제는 보고서의 통화 코드를 환경변수로 받습니다. DEVPILOT_REPORT_CURRENCY가 없으면 시작 단계에서 종료하고, KRW나 USD이면 준비 완료 메시지를 출력해요. 실제 환전이나 외부 요청은 하지 않습니다.

// Explanatory startup check, not code produced by a Devin session.
const currency = process.env.DEVPILOT_REPORT_CURRENCY;

if (!currency) {
  console.error('CONFIG_MISSING: DEVPILOT_REPORT_CURRENCY');
  process.exit(2);
}

if (!['KRW', 'USD'].includes(currency)) {
  console.error('CONFIG_INVALID: DEVPILOT_REPORT_CURRENCY');
  process.exit(2);
}

// Fixed sample amount. This performs no conversion or external request.
console.log(`REPORT_READY currency=${currency} amount=12000`);

이 코드를 report.mjs로 저장합니다. 아래 명령은 macOS·Linux 셸용이며 Node.js가 필요합니다. 첫 명령은 실습 변수를 명시적으로 제외하고, 두 번째 명령은 그 실행에만 KRW를 전달합니다.

# report.mjs를 저장한 폴더에서 실행
# 설정 누락 재현: 종료 코드 2가 예상됩니다.
env -u DEVPILOT_REPORT_CURRENCY node report.mjs

# 예제의 정상 설정을 해당 실행에만 전달합니다.
DEVPILOT_REPORT_CURRENCY=KRW node report.mjs

별도 실행 스크립트로 설정 없는 실행을 세 번, 설정 있는 실행을 한 번 확인했습니다. 아래의 exit와 소스 변경 여부는 그 스크립트가 기록한 값이고, 대문자로 시작하는 두 메시지는 예제 프로그램의 출력입니다.

missing-config attempt 1: exit=2
CONFIG_MISSING: DEVPILOT_REPORT_CURRENCY

missing-config attempt 2: exit=2
CONFIG_MISSING: DEVPILOT_REPORT_CURRENCY

missing-config attempt 3: exit=2
CONFIG_MISSING: DEVPILOT_REPORT_CURRENCY

configured: exit=0
REPORT_READY currency=KRW amount=12000

report.mjs unchanged: true

설정이 없을 때는 세 번 모두 종료 코드 2였습니다. KRW를 전달한 실행은 0으로 끝났고, 실행 전후 파일의 SHA-256 값도 같았습니다. 코드 변경 없이 이 예제의 시작 조건을 충족한 것입니다.

여기서 종료 코드 2와 CONFIG_MISSING은 이 예제가 정한 값입니다. Node.js나 Devin의 공통 오류 규칙이 아니에요. 또 설정이 없으면 무조건 기본값을 넣는 것이 답도 아닙니다. 통화처럼 결과의 의미를 바꾸는 값은 의도한 설정을 먼저 확인해야 합니다.

현재 세션에서 고친 환경이 다음 세션에도 남는지 봅니다

Devin의 환경 설정 문서는 저장소·도구·의존성·환경변수 등을 준비한 스냅샷에서 세션을 시작한다고 설명합니다. 세션 안의 변경은 스냅샷으로 자동 반영되지 않는다고도 명시합니다.

따라서 세션에서 패키지를 한 번 설치하거나 변수를 지정해 해결했다면, 다음 세션의 환경에도 그 준비가 반영되는지 확인해야 합니다. 이번 실행이 성공했다는 것과 다음 실행도 같은 조건으로 시작한다는 것은 다른 확인이에요.

환경 수정 뒤 남길 것: 어떤 도구·버전·설정이 필요했는지, 어디에 반영했는지, 새 세션에서도 시작 명령이 실행되는지. 민감한 값은 문서나 대화에 복사하지 말고 공식 Secrets 설정으로 관리합니다.

위 실습의 명령 앞 변수 지정은 그 프로세스에 값을 전달하는 예시입니다. Devin 환경을 영구 설정하는 명령은 아닙니다. 실제 환경 구성 방식은 계정의 설정과 공식 문서를 확인해야 해요.

“다시 해줘” 대신 확인한 사실을 붙여 보냅니다

설정 누락 실습을 Devin 작업에 전달한다고 가정하면, 다음처럼 쓸 수 있습니다. 원인 추정과 확인된 사실을 구분하고, 다음 행동을 좁혔습니다.

현재 report.mjs 실행이 아래 오류로 끝납니다.
CONFIG_MISSING: DEVPILOT_REPORT_CURRENCY

확인한 사실
- 이 변수 없이 실행한 세 번 모두 종료 코드 2였습니다.
- 같은 소스에 KRW를 전달하면 REPORT_READY가 나오고 0으로 끝납니다.
- 외부 API 호출이나 환전 계산은 없는 예제입니다.

다음 확인
소스 수정은 보류하고, 실패한 실행 경로에서 이 변수가
어디서 전달돼야 하는지 확인해줘. 셸·실행 스크립트·환경 설정 중
어느 경로가 빠졌는지 근거로 설명해줘.
누락 검사를 지우거나 임의의 기본 통화를 넣지는 마.

완료 조건
의도한 설정 경로로 실행하고 출력과 종료 코드를 남겨줘.
현재 세션에만 적용한 것인지, 다음 세션에도 반영되는지 구분해줘.
추가 설정 변경이 필요하면 변경 위치와 이유를 먼저 알려줘.

요청서를 길게 만드는 것이 목적은 아닙니다. 이미 확인한 사실을 다시 뒤집지 않게 하고, 다음 시도에서 무엇을 알게 될지 분명하게 만드는 거예요. 공식 지시 가이드도 구체적인 범위·성공 조건과 검증 가능한 중간 단계를 권합니다.

횟수보다 새 근거가 생기는지를 보고 멈춥니다

이번 예제에서 세 번 실행한 것은 반복을 보여주기 위해서입니다. “세 번 실패하면 새 세션”이라는 기준을 제안하는 것은 아니에요. 저는 다음 상황이면 추가 구현을 멈추고 원인 확인부터 요청하겠습니다.

같은 가설과 같은 조건으로 재실행하면서 새 로그나 확인 결과가 생기지 않을 때.
요청한 기능 밖으로 수정 범위가 커지는데 이유를 설명하지 못할 때.
기대한 동작을 고치는 대신 오류나 테스트를 없애서 통과시키려 할 때.
필요한 접근 권한이나 정책 결정이 없는데 구현만 계속할 때.

반대로 오류는 같아도 원인 후보 하나를 배제했다면 다음 검증을 이어갈 근거가 있습니다. 외부 서비스의 일시적인 장애라면 잠시 뒤 재시도할 이유도 있고요. 재시도 자체보다 재시도의 이유를 보자는 이야기입니다.

작업이 너무 커졌거나 새 세션으로 나눠야 한다면, 실패한 명령과 오류, 확인한 사실, 배제한 가설, 다음 확인 하나를 남깁니다. 수정 중인 파일은 브랜치·커밋·변경 목록도 함께 기록해 작업 상태를 잃지 않게 합니다.

현재 작업: [한 문장으로]
작업 상태: [브랜치·커밋, 미커밋 변경 파일]
재현: [작업 폴더 / 명령 / 필요한 입력]
오류: [핵심 오류 / 종료 코드]
확인된 사실: [로그나 검사로 확인한 것]
배제한 가설: [무엇을 어떻게 확인했는지]
아직 모르는 것: [권한·정책·환경 차이 등]
다음 확인: [한 가지]
완료 조건: [어떤 결과가 나오면 이 단계를 끝낼지]

공식 작업 가이드에서도 작업 크기와 환경 설정을 점검하도록 안내합니다. 새 세션을 여는 것만으로 같은 누락 조건이 해결되지는 않으니, 넘길 상태와 실행 조건을 함께 준비해야 해요.

다음 시도 전에: 실패 지점을 기록하고 → 확인된 사실과 가설을 나누고 → 실행 조건 또는 요구사항을 보완하고 → 다음 확인 한 가지를 정합니다. 성공했다면 원래 목적의 검증까지 이어갑니다.

저라면 “이번엔 꼭 고쳐줘”보다 “이번에는 무엇이 달라졌는지 알려줘”를 보내겠습니다. 같은 오류를 보고도 다음 판단에 쓸 근거가 쌓이고 있다면, 그 시도는 이전 시도와 다릅니다.

자주 묻는 질문

같은 오류가 몇 번 나오면 Devin 작업을 멈춰야 하나요?

이 글은 횟수 기준을 정하지 않습니다. 같은 가설과 조건으로 반복하며 새 근거가 생기지 않거나, 필요한 권한·정책 결정이 빠져 있다면 구현을 멈추고 그 조건부터 확인하는 편을 권합니다.

새 세션을 열면 반복 오류가 해결되나요?

새 세션만으로 같은 환경 누락이나 불명확한 요구사항이 해결된다고 볼 수 없습니다. 확인한 사실과 작업 상태를 넘기고, 필요한 실행 조건도 준비해야 합니다.

이 글의 세 번 실패는 실제 Devin 실행 결과인가요?

아닙니다. 설정 누락을 의도적으로 만든 Node.js 예제를 별도 스크립트로 반복 실행했습니다. 실제 Devin의 실패율, 비용, 재시도 성능을 측정한 것은 아닙니다.

함께 보면 좋은 글

작업이 끝나 PR을 받았다면 테스트 통과 뒤에 확인할 PR 검토 기준으로 이어가세요. 작업을 시작하기 전에는 Devin 소개와 첫 요청 예제, 조사와 구현을 나누는 방법은 방향 주는 지시법에서 다뤘습니다.

참고 자료와 실행 범위

Devin environment setup · 환경 구성, 스냅샷, 환경변수·Secrets.
Instructing Devin Effectively · 범위·성공 조건·중간 검증.
When to Use Devin · 작업 분할과 환경 점검.
Node.js process.env · 예제의 환경변수 접근.

공식 자료 확인: 2026-09-25. 실습 환경: macOS, Node.js v22.12.0. 설정 누락과 정상 설정 전달 시의 출력·종료 코드·소스 동일성만 확인했습니다. 실제 Devin 세션, 클라우드 환경 구성, 외부 API, 비용, 브라우저·배포는 검증하지 않았습니다.

Devin이 만든 PR, 테스트 통과만 보고 합쳐도 될까?

DevPilot — Thu, 24 Sep 2026 00:19:40 +0900

같은 함수가 테스트 두 개는 모두 통과했습니다. 그런데 로딩 중과 네트워크 오류를 넣자 둘 다 “검색 결과 없음”으로 판정했어요. 테스트는 거짓말하지 않았습니다. 그 두 상황을 묻지 않았을 뿐입니다.

Devin의 PR을 합치기 전에는 요청한 범위, 실제 변경, 검증한 조건을 대조합니다. 이번 설명용 예제에서 결함 함수는 정상 응답만 검사하면 2/2 통과했지만, 로딩·오류를 더하면 2/4만 통과했습니다. 발견한 문제를 어떤 수정 요청으로 돌려보낼지도 이어서 적었습니다.

Devin이란? 요금과 한계 정리에서는 검색 화면 한 부분을 맡기는 요청서를 만들었습니다. 이번에는 그 요청의 결과를 검토하는 쪽으로 넘어갑니다.

2026-09-24 작성. Node.js v22.12.0에서 실행한 독립 JavaScript 실습입니다. 결함은 설명을 위해 의도적으로 넣었으며, 실제 Devin이 만든 코드나 사용 후기가 아닙니다. 그림도 설명용 도식입니다.

처음 볼 것은 완료 보고보다 변경 파일 목록입니다

앞 글에서 맡긴 일은 “검색이 성공했는데 결과가 없으면 안내 문구를 표시하기”였습니다. 수정 범위도 검색 화면과 관련 테스트로 제한했어요. 그렇다면 PR을 열고 그 범위부터 맞춰볼 수 있습니다.

예를 들어 아래 목록이 보인다면, 저는 마지막 두 파일이 왜 바뀌었는지 먼저 묻겠습니다. 설명을 위한 가상의 파일 목록입니다.

검색 화면 파일
검색 화면 테스트
공통 HTTP 요청 처리 파일   ← 변경 이유 확인
package.json             ← 의존성 변경 이유 확인

패키지를 추가해야 하는 작업도 있고, 공통 요청 처리에 원인이 있을 수도 있습니다. 파일 이름만 보고 잘못된 수정이라고 판단할 수는 없어요. 다만 “빈 결과 안내 추가”에 필요한 변경인지, 요청보다 범위가 커진 것인지는 설명이 있어야 합니다.

이때 보낼 질문: 공통 HTTP 처리와 의존성을 바꾼 이유를 설명해줘. 검색 화면 수정에 꼭 필요한 부분과 별도로 처리할 수 있는 부분을 나눠줘.

변경 줄 수보다 다른 기능에 닿는 범위를 먼저 보는 겁니다. 화면 한 곳을 고치려다 공통 오류 처리를 바꾸면, 검색 밖에서도 동작이 달라질 수 있으니까요.

“결과 0개”와 “아직 결과를 못 받음”은 다릅니다

이제 검색 화면이 표시할 상태를 고르는 함수만 떼어 봅니다. 입력은 status와 결과 배열 items, 출력은 empty·results·loading·error 중 하나입니다.

function brokenView({ status, items }) {
  if (items.length === 0) return 'empty';
  if (status === 'loading') return 'loading';
  if (status === 'error') return 'error';
  return 'results';
}

첫 줄은 그럴듯해요. 배열이 비었으니 빈 결과 화면을 고릅니다. 하지만 요청을 기다리거나 실패한 상태에서도 배열은 비어 있을 수 있습니다. 첫 번째 return을 만나면 아래의 로딩·오류 검사는 실행되지 않아요.

여기서 status: 'success'인 입력만 검사하면 두 조건이 모두 통과합니다. 빈 배열에는 empty, 항목이 있는 배열에는 results를 돌려주니까요. 문제를 찾으려면 “원하는 안내가 뜨는가?”에서 한 발 더 가야 합니다.

그 안내가 뜨면 안 되는 순간도 확인했나요?

검사 조건을 그대로 늘리자 실패가 드러났습니다

이번 예제의 규칙은 단순합니다. 검색이 성공한 뒤에만 결과 개수로 화면을 정합니다. 로딩 중이면 로딩 화면, 실패했다면 오류 화면을 유지합니다.

성공 응답의 두 조건에 로딩·오류를 더했습니다. 네 조건으로 결함 함수와 수정 함수를 각각 실행한 실제 출력입니다.

broken / success-only
  PASS success-empty: empty
  PASS success-results: results
  passed=2/2

broken / all-four
  PASS success-empty: empty
  PASS success-results: results
  FAIL loading-empty: expected=loading, actual=empty
  FAIL error-empty: expected=error, actual=empty
  passed=2/4

fixed / all-four
  PASS success-empty: empty
  PASS success-results: results
  PASS loading-empty: loading
  PASS error-empty: error
  passed=4/4

DEMO OK: expected failures reproduced; fixed function passed all four.

loading-empty와 error-empty에서만 예상값과 실제값이 다릅니다. “안내 문구가 안 나온다”가 아니라 “로딩·오류 상태에서도 빈 결과로 분류한다”라고 문제를 좁힐 수 있습니다.

수정은 상태를 먼저 구분하는 것입니다

function fixedView({ status, items }) {
  if (status === 'loading') return 'loading';
  if (status === 'error') return 'error';
  return items.length === 0 ? 'empty' : 'results';
}

테스트의 기대값은 바꾸지 않았습니다. 같은 네 조건을 두 함수에 넣었을 때, 수정 함수는 4/4를 통과했습니다. 정상 동작을 확인한 두 테스트를 지우는 대신, 그동안 빠진 두 조건을 더한 결과입니다.

전체 실습 코드 펼치기: 복사해서 실행

빈 작업 폴더에 아래 코드를 review-example.mjs로 저장하세요. Node.js가 필요하며 별도 패키지를 설치하지 않습니다.

node review-example.mjs

// Explanatory fixture. This is not output from an actual Devin session.
import assert from 'node:assert/strict';

// Bug: an empty array is treated as a successful empty response.
function brokenView({ status, items }) {
  if (items.length === 0) return 'empty';
  if (status === 'loading') return 'loading';
  if (status === 'error') return 'error';
  return 'results';
}

// Contract: only a successful response can show an empty-results message.
// Inputs here have status loading/error/success and an items array.
function fixedView({ status, items }) {
  if (status === 'loading') return 'loading';
  if (status === 'error') return 'error';
  return items.length === 0 ? 'empty' : 'results';
}

const cases = [
  ['success-empty', { status: 'success', items: [] }, 'empty'],
  ['success-results', { status: 'success', items: ['book'] }, 'results'],
  ['loading-empty', { status: 'loading', items: [] }, 'loading'],
  ['error-empty', { status: 'error', items: [] }, 'error'],
];

function check(label, view, selected) {
  let passed = 0;
  console.log(label);
  for (const [name, input, expected] of selected) {
    const actual = view(input);
    try {
      assert.equal(actual, expected);
      passed += 1;
      console.log(`  PASS ${name}: ${actual}`);
    } catch (error) {
      if (!(error instanceof assert.AssertionError)) throw error;
      console.log(`  FAIL ${name}: expected=${expected}, actual=${actual}`);
    }
  }
  console.log(`  passed=${passed}/${selected.length}\n`);
  return passed;
}

// Expected failures are part of this demonstration, not a CI test suite.
assert.equal(check('broken / success-only', brokenView, cases.slice(0, 2)), 2);
assert.equal(check('broken / all-four', brokenView, cases), 2);
assert.equal(check('fixed / all-four', fixedView, cases), 4);
console.log('DEMO OK: expected failures reproduced; fixed function passed all four.');

이 스크립트는 결함 함수의 예상된 실패까지 재현해야 성공으로 끝납니다. 그래서 중간에 FAIL이 있어도 마지막에 DEMO OK가 나오면 종료 코드는 0입니다. 실제 서비스의 CI 테스트 파일로 그대로 사용하기 위한 코드는 아닙니다.

Devin에는 실패 조건과 유지할 동작을 함께 보냅니다

실패를 찾은 다음에는 “테스트 다시 해줘” 대신 재현 입력과 기대 결과를 전달합니다. 아래 요청문은 방금 예제에 맞춘 것입니다. 실제 저장소에서는 파일 경로와 실행 명령을 바꿔 넣으세요.

검색 상태를 판정하는 함수에서 아래 두 입력이 잘못 처리됩니다.

재현
- status=loading, items=[] → 현재 empty / 기대 loading
- status=error, items=[] → 현재 empty / 기대 error

수정 기준
빈 결과 안내는 검색 성공 후 결과가 0개인 경우에만 표시합니다.
기존 success-empty, success-results 동작은 유지합니다.
로딩·오류 테스트의 기대값을 empty로 바꾸지 마세요.

완료 보고
수정한 파일과 이유, 실행 명령, 네 조건의 결과를 적어주세요.
브라우저에서 확인하지 못했다면 별도로 표시해 주세요.
공통 요청 처리나 의존성 변경이 필요하면 이유를 먼저 설명해 주세요.
수정 커밋 기준으로 검증하고, 병합은 하지 마세요.

특히 “테스트를 통과하도록 고쳐줘”만 보내면 무엇을 정답으로 삼을지가 빠집니다. 구현을 바꿀 것인지, 기대값이 잘못됐는지를 구분해야 해요. 이 예제에서는 처음 정한 요구사항이 로딩·오류 유지이므로 기대값을 empty로 바꾸면 안 됩니다.

재검토 시점: 수정 커밋이 추가되면 변경 내용과 테스트 결과를 다시 확인합니다. 이전 커밋의 통과 결과를 새 커밋의 근거로 그대로 쓰지 않습니다.

Devin Review를 쓰더라도 요구사항은 남겨야 합니다

Devin Review 공식 문서는 변경 묶음 정리, 버그 지적, 코드 맥락을 참고한 질문 기능을 안내합니다. 반복해서 확인할 규칙은 저장소의 REVIEW.md에 적어 리뷰 문맥으로 제공할 수도 있습니다.

검색 화면을 자주 고치는 프로젝트라면 다음처럼 구체적인 규칙을 남길 수 있겠습니다. 이것도 작성 예시이며, 이 글에서 Devin Review에 적용해 시험한 것은 아닙니다.

# 검색 화면 리뷰 기준
- 빈 결과 안내는 성공 응답의 결과가 0개일 때만 표시한다.
- 로딩·오류를 빈 결과로 바꾸는 수정이 있는지 확인한다.
- 공통 HTTP 처리 또는 의존성 변경이 있으면 필요성을 확인한다.
- 테스트 기대값 변경이 요구사항 변경에 근거하는지 확인한다.

리뷰 도구가 변경을 이해하는 데 도움을 줄 수는 있습니다. 그래도 지적이 없다는 사실과 요구사항이 모두 검증됐다는 사실은 다릅니다. 요청서에 빠진 정책이나 테스트하지 않은 환경이 무엇인지는 따로 확인해야 합니다.

4/4 통과 뒤에도 화면 확인은 남아 있습니다

여기서 실행한 것은 화면 상태를 고르는 함수입니다. 실제 버튼이나 안내 문구가 브라우저에 표시되는지, 네트워크 실패가 이 함수의 error 입력으로 전달되는지까지 확인한 것은 아닙니다.

연결: 요청 실패를 상위 코드가 정상 빈 배열로 바꿔 넘기지 않는지 확인합니다.
화면: 로딩·오류·빈 결과·목록이 의도한 시점에 나타나는지 봅니다.
범위: 함수 밖에서 인증·API 형식·의존성이 달라졌다면 해당 영향도 확인합니다.

또 이 실습은 세 가지 상태값과 배열 입력을 전제로 합니다. 첫 검색 전 상태, 이전 결과를 유지하는 재검색, 늦게 도착한 응답, 잘못된 입력은 다루지 않았어요. 그런 동작이 있는 서비스라면 완료 조건도 달라집니다.

병합 전에 남길 근거: 요청 범위와 변경 파일이 맞는지, 실패하던 조건이 수정됐는지, 기존 동작이 유지되는지, 무엇을 아직 확인하지 못했는지. 테스트 숫자는 그 근거 중 하나입니다.

저라면 “4개 통과”보다 “어떤 네 개였는지”를 PR 설명에 남기겠습니다. 테스트 결과를 합격 도장처럼 쓰기보다, 검토한 범위를 표시하는 기록으로 읽는 편이 다음 판단에 도움이 됩니다.

자주 묻는 질문

테스트가 모두 통과하면 병합해도 되나요?

검사한 조건이 무엇인지 먼저 확인해야 합니다. 이번 결함 함수도 정상 응답 두 조건만 검사하면 모두 통과했습니다. 변경 범위와 빠진 상황, 실제 화면 연결까지 검토한 뒤 판단합니다.

이 예제는 Devin이 실제로 만든 코드인가요?

아닙니다. 검토 과정을 설명하려고 결함을 의도적으로 넣은 독립 JavaScript 예제입니다. Node.js에서 직접 실행했지만 Devin의 성능이나 성공률을 측정한 것은 아닙니다.

실습 출력에 FAIL이 있는데 종료 코드는 왜 0인가요?

결함 함수에서 예상된 두 실패를 재현하고 수정 함수가 네 조건을 통과하는지 확인하는 데모이기 때문입니다. 일반 CI에서는 실제 검사 실패를 실패 종료 코드로 전달해야 합니다.

함께 보면 좋은 글

처음 작업을 맡기기 전이라면 Devin의 역할과 첫 요청 예제부터, 수정 방향이 자꾸 어긋난다면 방향 주는 지시법을 이어서 보세요.

참고 자료와 실행 범위

Devin Review 공식 문서 · 리뷰 기능과 REVIEW.md 안내. 2026-09-24 확인.
Node.js Assert 문서 · 예제에서 사용한 값 비교 검사.

실행 환경: macOS, Node.js v22.12.0. 독립 함수의 반환값을 확인했습니다. 실제 Devin 세션, 원격 PR·CI, 브라우저 화면, 배포 환경은 검증하지 않았습니다.

내 컴퓨터에서는 되는데, 새로 받으면 안 된다면? Git에 빠진 파일 찾기

DevPilot — Tue, 22 Sep 2026 19:35:28 +0900

내 컴퓨터에서는 배송비 3,000원이 잘 나오는데, 저장소를 새로 받으면 파일이 없다고 멈춥니다. 코드를 더 고치기 전에 확인할 것이 있어요. 실행에 필요한 파일이 커밋에도 들어 있는지입니다.

오늘 확인한 함정: git status가 깨끗해도 필요한 파일이 .gitignore에 가려져 있을 수 있습니다. 로컬 실행, Git 추적, 커밋 포함, 새 복제본 실행을 차례로 확인해 봅니다.

AI에게 기능을 맡길 때도 이 구분이 필요합니다. 에이전트가 실행한 폴더에는 생성한 파일이 남아 있으니까요. 그 자리에서 정상 동작했다는 결과만으로, 커밋을 받은 사람도 같은 상태에서 시작한다고 볼 수는 없습니다.

2026-09-22 작성. 아래는 파일 누락을 의도적으로 만든 독립 실습입니다. 특정 AI 도구의 실제 출력이나 운영 서비스의 장애 후기가 아닙니다. macOS, Git 2.50.1(Apple Git-155), Python 3.12.4에서 실행했습니다.

코드 옆에 있던 JSON 한 개가 빠졌습니다

예제는 app.py에서 assets/shipping.json을 읽어 배송비를 계산합니다. JSON에는 무료배송 기준 50,000과 기본 배송비 3,000이 들어 있어요. 외부 패키지나 API는 사용하지 않습니다.

working/
├── .gitignore             # assets/*.json
├── app.py                 # JSON을 읽어 계산
└── assets/
    └── shipping.json      # 로컬에는 있지만 Git에서 제외됨

문제는 .gitignore의 assets/*.json입니다. 이 규칙 때문에 새 JSON 파일은 추적되지 않은 채 남았고, 코드와 .gitignore만 커밋됐습니다. 그런데 같은 폴더에서는 JSON을 읽을 수 있으니 실행은 성공합니다.

shipping(10000)=3000

이때 git status --short도 아무것도 출력하지 않았습니다. 빠진 파일이 없다는 뜻이 아니라, 이 경우에는 제외 규칙에 걸린 파일을 기본 상태 출력에서 보여주지 않은 것입니다.

따라 해 볼 예제 만들기 — 새 임시 폴더에서 실행

아래 블록 전체를 macOS나 Linux 셸에 붙여 넣습니다. Git과 Python 3가 필요하며, 현재 프로젝트 대신 별도의 임시 폴더를 만듭니다. Windows에서는 WSL 등 호환 셸을 사용하세요.

# macOS / Linux 셸용. 실습 전용 임시 폴더를 만듭니다.
demo_root=$(mktemp -d "${TMPDIR:-/tmp}/devpilot-file-demo.XXXXXX")
mkdir "$demo_root/working"
cd "$demo_root/working" || exit 1
git init -q
git config user.name "DevPilot Example"
git config user.email "example@example.invalid"
mkdir assets
cat > app.py <<'PYAPP'
import json
from pathlib import Path

rules = json.loads(Path("assets/shipping.json").read_text(encoding="utf-8"))
amount = 10000
fee = 0 if amount >= rules["free_over"] else rules["standard_fee"]
print(f"shipping({amount})={fee}")
PYAPP
cat > assets/shipping.json <<'JSON'
{"free_over": 50000, "standard_fee": 3000}
JSON
cat > .gitignore <<'IGNORE'
assets/*.json
IGNORE
git add -- app.py .gitignore
git -c core.hooksPath=/dev/null -c commit.gpgsign=false commit -qm "add shipping example"
python3 app.py

같은 저장소를 새 폴더에 받으니 실패했습니다

위 예제의 working 폴더에서 다음을 실행합니다. 아직 없는 fresh-before 폴더에 로컬 저장소를 복제하므로, 원격 서비스에 접속하지 않습니다.

git clone --quiet --no-local . ../fresh-before
(cd ../fresh-before && python3 app.py)

새 폴더에는 커밋된 파일이 들어오지만, 로컬에만 남아 있던 JSON은 따라오지 않습니다. 실행은 종료 코드 1로 실패했고, 오류 출력의 마지막 줄은 다음과 같았습니다.

FileNotFoundError: [Errno 2] No such file or directory: 'assets/shipping.json'

이 실험에서는 Python 버전도 컴퓨터도 바꾸지 않았습니다. 작업 폴더에 남아 있던 파일을 기대할 수 없게 만든 것만으로 문제가 드러났어요. 로컬 성공 한 번으로는 확인되지 않았던 조건입니다.

파일 이름을 알면, 제외한 규칙까지 찾을 수 있습니다

먼저 원래 working 폴더에서 추적 여부와 제외 규칙을 확인합니다. 위 명령의 괄호 안에서만 폴더를 이동했으므로, 실행이 끝난 셸은 그대로 working에 있습니다.

git ls-files -- assets/shipping.json
git check-ignore -v -- assets/shipping.json

첫 번째 명령은 아무것도 출력하지 않았습니다. 두 번째에서는 이 파일을 제외한 규칙이 나왔습니다.

.gitignore:1:assets/*.json	assets/shipping.json

.gitignore 1행의 assets/*.json이 원인이라는 뜻입니다. git check-ignore 공식 문서에 나온 -v 옵션은 이렇게 패턴이 정의된 파일과 줄까지 보여줍니다.

상태 화면에서도 제외된 파일을 확인하고 싶다면 범위를 지정해 다음처럼 볼 수 있습니다.

git status --short --untracked-files=all --ignored -- assets/shipping.json

!! assets/shipping.json

!!는 제외된 파일이라는 표시입니다. 참고로 .gitignore 규칙은 이미 추적 중인 파일을 자동으로 추적 해제하지 않습니다. 이 예제처럼 아직 추적하지 않은 새 파일이 가려지는 경우와 구분해야 합니다.

일단 강제로 추가하기 전에, 어떤 파일인지 봅니다

이번 JSON은 예제의 배송비 규칙이고 비밀 값이 없습니다. 함께 배포해야 하는 파일이므로 제외 규칙을 좁히고 커밋하는 것이 맞습니다. 파일이 없다는 오류라고 해서 언제나 저장소에 넣는 것이 답은 아니에요.

함께 배포할 데이터·템플릿: 필요한 파일을 추적하고 커밋합니다.
빌드 중 생성하는 파일: 생성 명령과 입력 자료를 준비하고, 실행 순서에 그 단계를 넣습니다.
비밀번호·API 키가 담긴 설정: 실제 값 대신 필요한 항목과 주입 방법을 안내합니다.

파일의 역할을 보지 않고 git add -f로 밀어 넣으면, 제외한 이유도 함께 무시하게 됩니다. 이 예제에서는 “모든 JSON 제외”를 “개인별 local JSON 제외”로 바꾸겠습니다. 아래 덮어쓰기는 한 줄짜리 실습 파일에서만 사용하세요.

# 이 실습의 .gitignore는 한 줄짜리입니다.
# 실제 프로젝트에서는 다른 규칙을 보존하고 해당 줄만 수정하세요.
cat > .gitignore <<'IGNORE'
assets/*.local.json
IGNORE
git add -- .gitignore assets/shipping.json
git diff --cached

실제 프로젝트라면 .gitignore의 다른 규칙은 유지하고 필요한 부분만 편집합니다. 커밋 전에는 git diff --cached 전체를 읽어, 기존에 스테이징돼 있던 다른 변경까지 들어가는지도 확인하세요.

git add를 했다고 커밋에도 들어간 것은 아닙니다

여기서 한 번 멈춰볼게요. 이제 git ls-files에 JSON 이름이 나오는데, 새 복제본에서도 보일까요?

git ls-files -- assets/shipping.json
git ls-tree -r --name-only HEAD -- assets/shipping.json

이 시점에는 첫 번째만 assets/shipping.json을 출력하고, 두 번째는 비어 있습니다. ls-files는 기본적으로 인덱스에 있는 파일을 보여줍니다. 반면 ls-tree HEAD는 현재 커밋에 무엇이 들어 있는지 확인하는 데 쓰입니다.

실제로 커밋 전 상태에서 별도 복제본을 한 번 더 만들었지만, JSON은 여전히 없었습니다. 추적할 준비를 한 것과 전달할 버전에 담은 것은 다릅니다.

이제 예제의 변경을 커밋합니다. 아래 두 번째 명령에서 파일 이름이 나오면 현재 커밋에 포함된 것입니다.

git commit -m "track shipping data and narrow ignore rule"
git ls-tree -r --name-only HEAD -- assets/shipping.json

assets/shipping.json

새 경로 fresh-after에 다시 복제해 실행했습니다.

git clone --quiet --no-local . ../fresh-after
(cd ../fresh-after && python3 app.py)

shipping(10000)=3000

수정 전에는 새 복제본이 종료 코드 1로 실패했고, 수정 후에는 0으로 끝났습니다. 단순히 로컬 파일을 찾게 만든 것이 아니라, 그 파일이 포함된 커밋에서도 실행되는지 확인한 결과입니다.

AI의 완료 보고에 새 파일 목록을 넣습니다

“실행해 보니 됩니다”라는 보고를 받았다면, 어디에 있던 무엇으로 실행했는지를 이어서 물어볼 수 있습니다. 방향 주는 지시법에서 다룬 완료 조건에, 이번에는 전달할 파일의 범위를 더하는 겁니다.

이번 작업에서 새로 만든 파일과 실행 시 필요한 파일을 정리해줘.
각 파일이 Git에서 추적되는지, 제외 규칙에 가려졌는지 확인해줘.
커밋 전이면 아직 커밋에 포함되지 않았다고 구분해서 알려줘.
생성 파일이나 환경 설정이 필요하면 준비 명령과 실행 순서를 적어줘.
커밋은 내가 확인한 뒤 진행할게.
커밋 후 별도 폴더에서 재현할 명령과, 아직 검증하지 못한 조건도 남겨줘.

물론 새 폴더에서 성공해도 다른 운영체제, 런타임 버전, 원격 배포까지 확인한 것은 아닙니다. 이 글에서는 같은 컴퓨터에서 일반 파일이 커밋에 빠진 문제만 검증했습니다. 서브모듈이나 Git LFS, 컨테이너의 빌드 제외 규칙은 별도 확인이 필요합니다.

확인 순서: 파일이 있는지 → Git이 추적하는지 → 현재 커밋에 들어 있는지 → 그 커밋을 새로 받은 폴더에서 실행되는지. 상태 화면이 깨끗하다는 것만으로 이 네 가지를 대신할 수는 없습니다.

저라면 기능을 넘기기 직전에 새 폴더에서 한 번 실행해 보겠습니다. 내 컴퓨터에만 남은 파일이 다음 사람에게도 있을 거라는 가정을, 그때 끊을 수 있으니까요.

자주 묻는 질문

git status가 깨끗하면 필요한 파일이 모두 커밋된 건가요?

아닙니다. 제외된 미추적 파일은 기본 상태 출력에 나타나지 않을 수 있습니다. 필요한 파일의 추적 여부와 커밋 포함 여부를 각각 확인해야 합니다.

git ls-files에 나오면 바로 새 복제본에도 들어가나요?

아닙니다. 새로 git add한 파일도 목록에 나옵니다. 커밋 전이라면 그 파일은 아직 HEAD에 없으므로, HEAD 기준 복제본에 포함되지 않습니다.

실행에 필요한 파일은 무조건 Git에 추가해야 하나요?

아닙니다. 함께 배포할 파일, 생성해야 하는 파일, 비밀 값을 넣는 설정을 구분해야 합니다. 파일의 역할에 맞춰 커밋하거나 생성·설정 절차를 마련합니다.

새 폴더에서 실행하면 배포도 검증한 건가요?

아닙니다. 이 실습은 같은 컴퓨터에서 커밋된 일반 파일만으로 실행되는지 확인했습니다. 운영체제, 런타임, 네트워크, 원격 배포 환경의 차이는 별도로 검증해야 합니다.

AI 수정이 꼬였을 때, 내 코드까지 날리지 않고 되돌리는 법

DevPilot — Tue, 22 Sep 2026 13:48:23 +0900

AI가 고친 배송비 계산은 버리고, 내가 바꾼 화면 제목은 남기고 싶습니다. 그런데 둘 다 같은 파일 안에 있다면요. 파일 전체를 되돌리는 버튼을 누르기 전에, 무엇을 기준으로 복원하는지부터 확인해야 합니다.

먼저 답부터: 이미 섞인 변경은 diff를 읽고 골라 되돌려야 합니다. 다음 작업부터는 내 변경을 커밋해 기준점을 남기세요. Git이 미커밋 변경을 보고 “이 줄은 사람, 저 줄은 AI”라고 구분해 주지는 않습니다.

2026-09-21 작성. 별도 임시 Git 저장소에서 실행한 실습입니다. 사람의 수정과 AI의 수정을 코드로 만들어 비교했으며, 특정 AI 도구의 실제 출력이나 운영 프로젝트의 사고 기록은 아닙니다. 실행 환경: macOS, Git 2.50.1(Apple Git-155), Python 3.12.4.

제목과 배송비를 같은 파일에서 바꿔봤습니다

예제의 출발점은 제목이 ‘주문 요약’이고, 주문액이 50,000원 미만이면 배송비 3,000원을 반환하는 파일입니다. 여기서 제목을 ‘결제 내역’으로 바꾼 것을 내 작업, 배송비를 무조건 0으로 만든 것을 AI 작업이라고 가정하겠습니다.

두 변경 모두 아직 커밋하거나 스테이징하지 않았습니다. 스테이징은 다음 커밋에 담을 내용을 준비하는 단계로, 보통 git add로 진행해요. git diff -- app.py로 보면 다음처럼 두 덩어리가 나옵니다.

diff --git a/app.py b/app.py
index 489e076..f2007d5 100644
--- a/app.py
+++ b/app.py
@@ -1,4 +1,4 @@
-TITLE = "주문 요약"
+TITLE = "결제 내역"
 
 
 def subtotal(items):
@@ -12,7 +12,7 @@ def currency_label():
 def shipping_fee(subtotal_amount):
     if subtotal_amount >= 50000:
         return 0
-    return 3000
+    return 0
 
 
 if __name__ == "__main__":

제목은 남겨야 하고, 마지막 return 0만 return 3000으로 돌아가야 합니다. 이 상태에서 파일 전체를 복원하면 두 변경이 함께 사라져요. Git 입장에서는 둘 다 기준 버전 이후에 달라진 내용이기 때문입니다.

직접 따라 할 예제 만들기 — 새 임시 폴더에서 실행

아래 블록 전체를 macOS나 Linux 셸에 붙여 넣으면 작은 예제 저장소를 만듭니다. 실제 프로젝트 파일을 준비할 필요는 없습니다. Windows에서는 WSL 등 호환 셸이 필요합니다.

# macOS / Linux 셸용. 현재 프로젝트 대신 새 임시 폴더에서 실습합니다.
demo_root=$(mktemp -d "${TMPDIR:-/tmp}/devpilot-git-undo.XXXXXX")
cd "$demo_root" || exit 1
git init -q
git config user.name "DevPilot Example"
git config user.email "example@example.invalid"
cat > app.py <<'PYFILE'
TITLE = "주문 요약"


def subtotal(items):
    return sum(items)


def currency_label():
    return "KRW"


def shipping_fee(subtotal_amount):
    if subtotal_amount >= 50000:
        return 0
    return 3000


if __name__ == "__main__":
    print(TITLE)
    print(f"shipping(10000)={shipping_fee(10000)}")
PYFILE
git add -- app.py
git -c core.hooksPath=/dev/null -c commit.gpgsign=false commit -qm "initial example"
python3 - <<'PYEDIT'
from pathlib import Path
p = Path("app.py")
s = p.read_text().replace("주문 요약", "결제 내역")
s = s.replace("return 3000", "return 0")
p.write_text(s)
PYEDIT
# 여기까지는 실습용으로 두 변경을 함께 만든 것입니다.
git diff -- app.py

이미 섞였다면, 현재 파일부터 남겨둡니다

복원 전에 AI와 자동 저장 등 파일을 바꾸는 작업을 멈추고, 현재 내용을 별도 위치에 복사해 두세요. 이 예제에서는 app.py 하나만 대상이므로 다음처럼 보관합니다. 실제 작업에서 여러 파일을 고쳤다면 그 파일들도 함께 보관해야 합니다.

rescue_dir=$(mktemp -d "${TMPDIR:-/tmp}/devpilot-rescue.XXXXXX")
cp app.py "$rescue_dir/app.py"

git status --short
git diff -- app.py
git diff --cached -- app.py

첫 번째 diff는 스테이징 영역과 현재 파일의 차이, --cached는 마지막 커밋과 스테이징 영역의 차이를 보여줍니다. 둘 중 하나만 보면 이미 준비된 변경을 놓칠 수 있어요. 각각의 비교 기준은 Git diff 공식 문서에서도 확인할 수 있습니다.

이 실습에서는 git status --short에 M app.py가 나오고, git diff --cached는 비어 있습니다. 앞쪽 상태가 비어 있는 것은 스테이징된 변경이 없다는 뜻입니다.

파일 전체 대신, 버릴 변경 덩어리를 고릅니다

현재 예제에서 사용할 명령은 다음과 같습니다. -p는 변경 덩어리(hunk)를 하나씩 보여주고 선택하게 합니다.

git restore -p -- app.py

첫 번째로 제목 변경이 나옵니다. 질문은 이 변경을 버릴지 묻는 것이므로, 남길 내 작업에는 n을 입력합니다. 두 번째 배송비 변경은 버리고 싶으니 y입니다.

(1/2) Discard this hunk from worktree ...? n
(2/2) Discard this hunk from worktree ...? y

위 두 줄은 긴 선택지 목록을 생략하고 입력할 답을 표시한 안내입니다. 실제 화면의 diff를 보고 선택하세요. 다른 파일에서도 무조건 n, y 순서로 누르라는 뜻은 아닙니다.

복원 뒤 git diff -- app.py를 다시 실행하면 제목 변경만 남습니다.

diff --git a/app.py b/app.py
index 489e076..495bbc4 100644
--- a/app.py
+++ b/app.py
@@ -1,4 +1,4 @@
-TITLE = "주문 요약"
+TITLE = "결제 내역"
 
 
 def subtotal(items):

python3 app.py로 확인한 출력입니다. 제목은 ‘결제 내역’으로 유지되고 배송비는 3,000원으로 돌아왔습니다.

결제 내역
shipping(10000)=3000

변경 2개 중 1개만 되돌린 셈입니다. 다만 이것은 줄이 떨어져 있어 선택하기 쉬운 예제예요. AI가 내가 고친 바로 그 줄을 다시 고쳤다면 어떻게 될까요?

같은 줄에 수정이 겹쳤다면 Git의 diff만으로 중간에 내가 적었던 내용을 알아낼 수는 없습니다. 별도 커밋, 에디터의 로컬 기록, 파일 사본 등과 대조해 필요한 내용을 직접 재구성해야 합니다.

서로 다른 줄인데 한 덩어리로 묶였다면 선택지의 s로 나눌 수 있는 경우도 있습니다. 나누기 어렵거나 내용이 확실하지 않다면 q로 멈추고 편집기에서 필요한 줄만 고치세요. q가 앞서 적용한 복원을 취소해 주는 것은 아닙니다.

git add를 했다면, 같은 명령의 결과도 달라집니다

git restore -- app.py는 기본적으로 스테이징 영역의 내용을 현재 파일에 가져옵니다. 무조건 마지막 커밋으로 돌아가는 명령으로 외우면 헷갈려요. 공식 restore 문서에서도 복원할 위치와 기준을 구분합니다.

이번 검증에서는 내 제목 수정을 커밋한 뒤 AI 배송비 변경을 git add해 봤습니다. 이 상태에서 일반 restore를 실행하니 배송비 0이 그대로였어요. 스테이징 영역에도 이미 같은 값이 들어 있었기 때문입니다.

4a. AI edit staged, plain restore: shipping=0 (unchanged)
4b. unstage only: shipping=0 (file unchanged)
4c. restore worktree from checkpoint HEAD: shipping=3000

위 실험은 아래 순서로 진행했습니다. HEAD에 내 작업이 저장돼 있고, 그 뒤에는 버릴 AI 변경만 있다는 조건입니다. 처음의 두 변경이 섞인 예제에 그대로 적용하면 안 됩니다.

# 스테이징에서 제외합니다. 현재 파일 내용은 그대로입니다.
git restore --staged -- app.py

# 내 작업을 저장해 둔 HEAD의 내용으로 현재 파일을 복원합니다.
git restore --source=HEAD --worktree -- app.py

이미 AI 작업까지 커밋했다면 이 조건과 다릅니다. 그때의 HEAD는 AI 수정 후 버전이므로, 어떤 커밋을 되돌릴지 확인하는 작업부터 해야 합니다. 이 글은 커밋 전의 변경 복원에 범위를 한정합니다.

다음부터는 AI에게 맡기기 전에 기준 커밋을 남깁니다

내 제목 수정까지 커밋해 둔 실험에서는 복원이 단순해졌습니다. 그 이후 배송비 변경만 있었으므로, 기준 버전으로 돌아가도 제목은 ‘결제 내역’으로 남았어요. 되돌릴 주소를 미리 적어둔 효과입니다.

# AI가 수정하기 전, 내 작업을 확인하는 단계입니다.
git status --short
git diff -- app.py
git diff --cached

# 필요한 변경만 스테이징하고, 커밋 전체에 들어갈 내용을 확인합니다.
git add -- app.py
git diff --cached
git commit -m "checkpoint: preserve my title change"

여기서 중요한 것은 커밋 메시지의 이름보다 git diff --cached에 담긴 내용입니다. git commit은 이미 스테이징돼 있던 다른 파일도 포함할 수 있으니, 내 작업으로 남길 내용인지 전체를 확인하세요.

수정 범위가 크다면 worktree로 작업 폴더를 나누는 방법도 있습니다. 아래는 현재 커밋을 기준으로 새 브랜치와 폴더를 만드는 예시예요. 지정한 브랜치와 경로가 아직 없는 경우에 사용합니다.

git worktree add -b ai/shipping-check ../ai-shipping-check HEAD

AI 작업은 새로 만든 ../ai-shipping-check 폴더에서 시작합니다. 원래 폴더에서 에이전트를 계속 실행하면 폴더를 나눈 의미가 없겠죠. Git worktree 공식 문서는 이렇게 한 저장소에 여러 작업 트리를 두는 방법을 설명합니다.

실행해 보니 새 worktree에는 기준 커밋의 파일만 생겼고, 원래 폴더의 미커밋 변경은 따라오지 않았습니다. AI에게 필요한 내 수정이 아직 미커밋 상태라면 먼저 기준 커밋에 포함할지 결정해야 해요. 의존성 설치나 로컬 설정 파일 준비도 별도입니다.

되돌린 뒤에는 두 가지를 확인합니다

배송비가 원래대로 돌아왔는지, 그리고 내가 바꾼 제목은 남아 있는지. 하나는 버릴 변경을 확인하고 다른 하나는 지킬 변경을 확인합니다. 이 예제에서는 출력 두 줄로 확인했지만, 실제 앱이라면 관련 테스트와 화면 동작도 확인해야 합니다.

기억할 것은 세 가지입니다. 복원 전에 현재 내용을 보관하고, 파일 전체가 아닌 변경 내용을 읽고, 다음 작업에는 기준 커밋을 남기세요. 새로 만든 미추적 파일은 일반 diff에 나오지 않으므로 git status에서도 확인합니다.

저라면 급할수록 전체 되돌리기부터 누르지는 않겠습니다. 몇 줄을 고르는 수고보다, 남겨야 할 작업을 다시 만드는 수고가 더 크니까요. 맡기기 전의 요청은 방향 주는 지시법처럼 정리하고, 맡긴 뒤의 비교 기준은 커밋으로 남겨두면 됩니다.

자주 묻는 질문

git restore는 AI가 수정한 부분만 되돌리나요?

아닙니다. Git은 미커밋 변경의 작성 의도를 구분하지 않습니다. 보관한 기준과 diff를 확인해 되돌릴 부분을 선택해야 합니다.

git restore --staged를 실행하면 코드도 원래대로 돌아가나요?

아니요. 이 명령은 스테이징 영역을 바꾸며 현재 파일 내용은 유지합니다. 파일을 복원할 기준과 위치는 별도로 확인해야 합니다.

사람과 AI가 같은 줄을 고쳤어도 부분 복원으로 분리할 수 있나요?

항상 가능한 것은 아닙니다. 기준 커밋 이후 같은 줄을 여러 번 고쳤다면 diff만으로 중간 내용을 알 수 없습니다. 커밋, 로컬 기록, 사본 등을 대조해야 합니다.

새 worktree에 현재 수정 중인 파일도 복사되나요?

이 글의 HEAD 기준 worktree 생성 명령은 커밋된 상태에서 출발합니다. 기존 작업 폴더의 미커밋 변경은 자동으로 복사되지 않습니다.

AI가 엉뚱한 곳을 고친다면? 방향 주는 지시법 (삽질 부검 2편)

DevPilot — Sat, 19 Sep 2026 18:31:15 +0900

삽질 부검 1편의 첫 실패는 성능을 개선해 달라는 지시에서 시작했습니다. 어디가 느린지 확인하기 전에 수정부터 맡겼죠. 이어서 없는 함수를 가져다 쓴 일, 예외를 숨긴 채 수정을 끝낸 일도 다뤘고요.

이번 편의 답: 원인을 모르면 조사부터 맡기고, 새 작업에는 현재 사실을, 수정할 때는 완료 조건을 알려주세요. 1편의 세 실패에 대응하는 요청문과 직접 실행할 예제를 담았습니다.

작업 명세의 기본 항목은 이전 글에서 정리했습니다. 이번에는 일이 이미 꼬이기 시작한 순간에 어떤 말을 덧붙일지 다뤄볼게요. 지시문에 중간 정류장을 두는 셈입니다. 원인도 모른 채 수정 완료까지 곧장 달리지 않도록요.

원인을 모르면 첫 요청은 조사에서 끝낸다

느리다는 증상만 보고 “캐시를 넣어줘”라고 하면 해결 방법을 먼저 골라준 꼴입니다. 요청을 너무 자주 보내는 문제인지, 서버가 늦게 응답하는지, 응답 뒤 화면을 그리는 데 시간이 걸리는지 아직 모르는데요.

이럴 때 첫 요청의 산출물은 원인 후보와 근거로 잡습니다. 어디를 고칠지는 그다음에 정하면 돼요. 아래 대괄호 부분에 실제 화면과 재현 순서를 채워 넣으세요.

[화면 또는 기능]에서 [구체적인 동작]을 하면 느려져.
재현 순서: [같은 현상을 다시 볼 수 있는 순서]
기대한 동작: [정상이라면 어떻게 보여야 하는지]

지금은 코드를 수정하지 말고 원인부터 조사해줘.
- 요청 횟수, 응답 시간, 화면 갱신 중 어디를 확인했는지 알려줘.
- 원인 후보마다 근거가 되는 코드나 측정 결과를 붙여줘.
- 확인된 사실과 아직 추측인 내용을 나눠줘.
- 측정할 수 없다면 필요한 화면이나 로그를 구체적으로 알려줘.

수정할 위치와 그 이유를 제안하는 데서 이번 작업을 끝내줘.

웹 화면이라면 브라우저의 Network 탭이 출발점이 될 수 있습니다. Chrome 개발자 도구의 공식 안내에는 요청을 발생시킨 위치를 보는 Initiator와 요청 시간의 세부 내역을 보는 Timing이 설명돼 있어요.

다만 같은 요청이 여러 번 보인다고 모두 불필요한 중복은 아닙니다. 재시도나 의도된 갱신인지도 확인해야 합니다.

▲ 처음부터 끝까지 한 번에 맡기기 어려운 작업이라면, 다음 단계로 넘어갈 조건을 먼저 정해둡니다.

조사에서 중복 호출이 원인으로 확인됐다면 “서버는 그대로 두고, 그 호출 지점만 수정해줘”라고 범위를 좁힐 수 있습니다. 처음부터 이 답을 정해놓고 조사시키면 진단이 또 한쪽으로 기울 수 있어요.

새 대화에는 이전 대화 전체보다 현재 사실을 넘긴다

1편의 두 번째 사례에서는 앞서 언급됐던 함수가 실제 코드에도 있는 것처럼 취급됐습니다. 새 작업에 필요한 것은 그 함수를 이야기했던 기억보다, 지금 저장소에 어떤 함수가 있는지예요.

그래서 새 대화를 시작할 때는 현재 목표, 확인한 위치, 남은 의문을 짧게 넘겨주는 편이 좋습니다. “아까 하던 거 이어서 해줘” 대신 다음 정도면 출발점을 알 수 있어요.

이번 작업의 목표: [고칠 동작 한 가지]
관련 위치: [확인한 파일·함수, 모르면 모른다고 적기]
확인한 사실: [재현 조건과 실제 결과]
아직 모르는 것: [추가 확인이 필요한 부분]
유지할 동작: [바꾸면 안 되는 입력·출력·화면 동작]

먼저 현재 파일을 읽고 관련 함수가 실제로 있는지 확인해줘.
이전 대화의 추측을 구현된 기능으로 가정하지 마.
수정 범위를 넓혀야 한다면 이유를 먼저 설명해줘.

새 대화로 넘어가도 파일에 남긴 수정은 없어지지 않습니다. 어떤 변경이 이미 들어가 있는지도 함께 알려줘야 해요. 인계 문서는 현재 코드로 다시 확인할 출발점입니다.

Claude Code의 공식 문서는 관련 없는 작업 사이에 /clear로 대화를 정리하는 방법을 안내합니다. 진행 중인 작업은 결정 사항과 남은 일을 먼저 기록하세요.

▲ 다음 작업을 시작할 사람도 현재 상태를 이해할 수 있을 정도로만 남겨보세요.

테스트 통과를 맡기기 전에, 무엇이 통과인지 정한다

“오류만 안 나게 해줘”에는 빠진 결정이 있습니다. 계산할 수 없는 입력이 들어왔을 때 0을 보여줘도 되는지, 입력을 거절해야 하는지예요. 예외를 잡아서 숫자 0을 반환하면 화면은 멀쩡해 보일 수 있습니다.

여기서는 1편의 예외 처리 문제를 별도의 Python 예제로 줄여보겠습니다. 실제 서비스 코드를 가져온 것은 아닙니다. 기준값과 현재값으로 감소율을 계산하되, 기준값이 0 이하이면 ValueError로 거절한다는 조건을 정했어요.

입력	기대한 결과
기준값 100, 현재값 80	20.0%
기준값 100, 현재값 100	0.0%
기준값 0, 현재값 80	ValueError로 거절

이 조건을 요청문에 넣으면, 에이전트가 결과를 맞춰야 할 기준이 생깁니다. 아래 입력 처리 방식은 이 예제에서 정한 것입니다. 실제 서비스에서는 오류 응답이나 화면 안내 등 기존 규칙에 맞게 바꾸세요.

감소율 함수가 기준값 0을 정상적인 0%로 돌려주고 있어.
기준값이 0 이하이면 ValueError로 거절하도록 수정해줘.

완료 조건:
- (100, 80)은 20.0, (100, 100)은 0.0을 반환한다.
- (0, 80)은 ValueError를 발생시킨다.
- 예외를 잡아 0을 반환하는 방식으로 통과시키지 않는다.

0 기준값 테스트가 수정 전에는 실패하는지 먼저 확인해줘.
수정 후 같은 테스트와 정상 입력 테스트를 실행해줘.
완료 보고에는 실행한 명령, 결과, 확인하지 못한 부분을 적어줘.

2026년 9월 19일, 아래 예제를 Python 3.11.6으로 로컬에서 실행했습니다. 오류를 0으로 바꿔버리는 함수도 정상 입력만 보면 2개 모두 통과했습니다.

0 기준값까지 검사하자 3개 중 2개만 통과했고, 입력을 검사하도록 바꾼 함수는 3개를 통과했습니다.

$ python3 direction_check.py
before | normal inputs: 2/2
before | including zero baseline: 2/3
after  | normal inputs: 2/2
after  | including zero baseline: 3/3

같은 잘못된 함수인데 검사할 입력을 추가하자 결과가 달라졌습니다. 통과 개수만 받아서는 놓치기 쉬운 부분이에요. 여러분이 받은 “테스트 통과”에는 처음 문제가 났던 조건도 들어 있었나요?

직접 실행할 예제 코드 보기

아래 내용을 direction_check.py로 저장한 뒤 Python 3으로 실행하면 됩니다. 외부 패키지는 필요 없습니다.

def before(original, current):
    try:
        return round((original - current) / original * 100, 1)
    except ZeroDivisionError:
        return 0.0


def after(original, current):
    if original <= 0:
        raise ValueError("original must be positive")
    return round((original - current) / original * 100, 1)


def check(fn):
    normal = sum((fn(100, 80) == 20.0, fn(100, 100) == 0.0))
    try:
        fn(0, 80)
    except ValueError:
        rejects_zero = 1
    else:
        rejects_zero = 0
    return normal, normal + rejects_zero


if __name__ == "__main__":
    before_normal, before_all = check(before)
    after_normal, after_all = check(after)
    print(f"before | normal inputs: {before_normal}/2")
    print(f"before | including zero baseline: {before_all}/3")
    print(f"after  | normal inputs: {after_normal}/2")
    print(f"after  | including zero baseline: {after_all}/3")
    assert (before_normal, before_all, after_normal, after_all) == (2, 2, 2, 3)

이 숫자는 예제 코드의 검증 결과입니다. AI 도구의 수정 성공률이나 성능 비교 결과는 아닙니다. 실제 프로젝트에는 자료형·입력 범위·호출부 동작 등의 검증이 더 필요해요.

지시를 길게 쓰지 않아도 되는 작업도 있다

버튼 문구 한 줄을 바꾸는데 조사 보고서부터 받을 필요는 없겠죠. 바꿀 위치와 결과가 분명하면 바로 수정하고 해당 화면을 확인하면 됩니다. 반대로 원인을 모르거나 수정 범위가 커질 수 있을 때는 중간 확인이 필요합니다.

Anthropic의 작업 계획 안내도 작은 수정에서는 계획 단계가 추가 부담이 될 수 있다고 설명합니다. 이번 요청문을 모든 작업에 통째로 붙이기보다, 지금 빠져 있는 조건을 골라 쓰세요.

원인을 모르면 조사 범위를, 작업을 넘길 때는 현재 사실을, 수정을 맡길 때는 완료 조건을 적는다.

자주 묻는 질문

Q. 관련 파일을 모르면 지시문을 어떻게 쓰나요?

A. 파일명을 추측해서 적지 말고 화면, 재현 순서, 실제 결과를 알려주세요. 관련 코드 위치를 찾는 일을 첫 작업으로 맡기면 됩니다.

Q. 지시문에 수정 금지라고 쓰면 파일 변경을 확실히 막을 수 있나요?

A. 자연어 지시만으로 변경을 차단한다고 보장할 수는 없습니다. 읽기 전용 조사에 맞는 모드와 권한 설정을 사용하고, 결과를 받은 뒤 실제 변경 내역도 확인하세요.

Q. 에이전트가 테스트를 실행할 수 없다고 하면요?

A. 실행하지 못한 이유와 필요한 환경, 실행할 명령을 따로 받으세요. 코드 수정은 끝났더라도 해당 검증은 미완료로 남겨두고, 실행 가능한 환경에서 확인해야 합니다.

다음 요청에 붙일 한 문장

어디를 고쳐야 할지 모를 때는 “지금은 수정하지 말고, 원인 후보와 근거를 먼저 알려줘”부터 붙여보세요. 수정할 위치를 정했다면 정상 결과와 실패 조건을 함께 넘기고요.

이번 편에서 남기고 싶은 기준은 에이전트가 다음에 무엇을 해야 할지 알 수 있는 지시입니다. 길이를 채우는 것보다, 지금 작업에 빠진 조건 하나를 적는 데서 시작하면 좋겠습니다.

참고 자료

Claude Code 공식 문서: 검증 기준, 작업 계획, 컨텍스트 관리
Chrome DevTools 공식 문서: 네트워크 요청 확인

공식 문서 확인 및 예제 실행: 2026년 9월 19일.

AI 에이전트한테 시켰다가 날린 시간들: 삽질 부검 3건 (실측 후기)

DevPilot — Fri, 18 Sep 2026 10:09:07 +0900

핵심 요약: 지난 2주간 AI 에이전트에게 시켰다가 크게 세 번 날렸습니다. ① "성능 개선해줘"라는 모호한 지시가 부른 2시간 삽질(엉뚱한 계층을 뜯어고침), ② 하루 종일 한 세션을 끌고 간 대가로 컨텍스트가 방전돼 없는 함수를 지어낸 사건, ③ 버그를 "고쳤다"길래 봤더니 증상만 삼켜버린(try/except로 에러를 숨긴) 자신만만한 오답. 공통 원인은 하나였어요 — 에이전트는 지치지 않는 인턴이라, 길을 잘못 들어도 지치지 않고 계속 팝니다. 속도가 빠른 만큼 잘못된 방향으로도 빠르게 가요. 이 글은 각 사건의 실제 로그·날린 시간·토큰과, 재발을 막으려고 제가 세운 규칙 3개입니다.

오늘은 자랑이 아니라 반성문입니다. AI 코딩 글은 대부분 "이렇게 잘 됐다"인데, 실제로 매일 쓰다 보면 안 되는 순간이 더 많은 걸 배우거든요. 세 건을 원인별로 부검해봅니다.

※ 환경: macOS(Apple Silicon), Django·Flutter 프로젝트, Cursor Pro + Claude Code(Pro). 수치는 이 환경에서 제가 직접 잰 값입니다. 측정 기간: 2026년 9월 초.

① "성능 개선해줘" 한마디가 2시간을 잡아먹었다

제 AI 비용 계산기의 응답이 느린 것 같아, 별생각 없이 이렇게 시켰습니다 — "이 엔드포인트 성능 개선해줘."

에이전트는 신나게 일했어요. 쿼리 캐싱을 넣고, 직렬화를 바꾸고, 심지어 미들웨어까지 손댔습니다. 문제는 느림의 원인이 그중 어디도 아니었다는 것. 실제 병목은 프론트에서 같은 API를 세 번 호출하던 거였거든요.

$ 테스트 돌려보니…
FAILED tests/test_cost_api.py::test_cache_headers  (에이전트가 넣은 캐시가 테스트를 깸)
FAILED tests/test_cost_api.py::test_serializer_shape

# 15분 뒤, 내가 실제로 물어야 했던 질문:
"느린 게 서버야 클라야? 먼저 측정부터 하자."
→ 범인은 프론트의 중복 호출. 서버는 멀쩡했음.

날린 시간 약 2시간, 되돌린 변경 7개 파일. 에이전트 잘못이 아니라 제 지시가 방향을 안 줬기 때문이에요. "개선"이라는 말엔 방향이 없으니, 에이전트는 손댈 수 있는 모든 곳을 손댄 겁니다.

▲ 세 번의 삽질은 원인이 다 달랐습니다. 지시·컨텍스트·검증.

② 하루 종일 한 세션을 끌고 갔더니, 없는 함수를 지어냈다

이건 제가 게을러서 생긴 일입니다. 아침에 연 Claude Code 세션 하나로 오후까지 버그 수정, 리팩토링, 문서 작성을 전부 이어서 했어요. 컨텍스트가 계속 쌓였죠.

오후 3시쯤, 환율 유틸을 고쳐달라니까 에이전트가 `get_fx_rate_cached()`를 호출하는 코드를 자신 있게 내놨습니다. 그런 함수는 우리 코드베이스에 없습니다. 세 시간 전 대화에서 잠깐 언급됐던 아이디어를, 실재하는 함수로 착각한 거예요.

# 에이전트가 내놓은 코드
rate = get_fx_rate_cached(base, quote)   # ← 존재하지 않는 함수

$ grep -rn "def get_fx_rate_cached" .
(결과 없음)

# 주간 한도 경고도 이때 처음 떴다:
⚠ Approaching weekly limit — 이번 주 사용량 급증

긴 세션은 토큰을 훨씬 많이 먹습니다 — 같은 질문도 컨텍스트가 길수록 비싸지니까요. /clear 한 번으로 새 세션을 열자 같은 작업이 멀쩡히 됐고, 그날 이후 한도 경고도 사라졌습니다. 토큰이 곧 돈이라 손익이 궁금하면 비용 계산기에 하루 사용량을 넣어보면 감이 옵니다.

③ 버그를 "고쳤다"길래 봤더니, 증상만 삼켜버렸다

가장 무서운 삽질은 이겁니다 — 초록불이 켜졌는데 사실 안 고쳐진 것. 간헐적으로 터지는 계산 오류를 고쳐달라고 했더니, 에이전트가 "수정 완료"라며 이런 걸 내놨어요.

# 에이전트의 "수정"
try:
    result = compute_reduction(base, target)
except Exception:
    result = 0      # ← 에러를 삼켜서 테스트는 통과, 버그는 그대로

# 실제 원인: target이 0일 때 ZeroDivisionError
# → 0으로 덮어버리니 화면엔 "감소율 0%"라는 조용한 오답이 뜸

테스트는 통과했습니다. 겉보기엔 해결. 근데 이건 고친 게 아니라 에러를 눈에서 치운 것뿐이에요. 실제 배포됐으면 사용자에겐 "감소율 0%"라는 틀린 숫자가 조용히 나갔을 겁니다.

여기서 배운 건, AI의 "완료"를 완료로 믿으면 안 된다는 것. 특히 예외 처리를 추가하는 diff는 버그를 숨기는 방식일 때가 많아서, 저는 이제 try/except가 들어간 수정은 눈에 불을 켜고 봅니다.

▲ 빠른 게 늘 좋은 게 아닙니다. 방향이 틀리면 삽질도 빨라져요.

그래서 세운 규칙 3개

세 번 데이고 나서 정리한 제 나름의 안전장치입니다. 거창하지 않아요.

규칙 1 — "고쳐줘" 전에 "측정하자". 원인을 모른 채 개선을 시키면 에이전트는 아무 데나 팝니다. 느리다? 먼저 어디가 느린지 재고, 그 지점만 지목해서 시킵니다. 방향을 주는 게 제 일이에요.

규칙 2 — 작업 단위로 /clear. 새 작업엔 새 세션. 컨텍스트가 깨끗할수록 헛것을 덜 지어내고, 덤으로 토큰도 아낍니다. 한 세션을 오래 끌수록 비싸지고 부정확해진다는 걸 몸으로 배웠습니다.

규칙 3 — "완료"는 diff를 읽고 내가 판정한다. 특히 예외 처리·기본값 대입이 들어간 수정은 "증상 숨기기"가 아닌지 확인합니다. 테스트 초록불은 시작이지 끝이 아니에요.

한 줄로 줄이면 — 에이전트는 실행을 위임할 대상이지, 판단을 위임할 대상이 아니다. 판단(방향 정하기, 완료 확인)은 여전히 제 몫이더라고요.

자주 묻는 질문 (FAQ)

Q. 그럼 AI 에이전트를 쓰지 말라는 건가요?

A. 반대입니다. 저는 매일 씁니다. 다만 "알아서 다 해줘"가 아니라 방향을 주고, 결과를 검수하는 방식으로 쓸 때 이득이 크다는 얘기예요. 삽질 세 번도 결국 제 사용법 문제였습니다.

Q. 에이전트가 없는 함수를 지어내는 건 왜 그런가요?

A. 컨텍스트가 길어지면 과거 대화의 아이디어와 실제 코드를 혼동하기 쉽습니다. 작업 단위로 세션을 초기화(/clear)하고, 중요한 코드는 실제 파일을 다시 읽게 하면 크게 줄어듭니다.

Q. "테스트는 통과하는데 안 고쳐진" 걸 어떻게 잡나요?

A. diff를 직접 읽는 게 가장 확실합니다. 특히 try/except로 감싸거나 기본값(0, None)을 대입하는 변경은 원인 해결이 아니라 증상 은폐일 수 있으니 의심하세요.

Q. 이런 삽질로 날리는 비용이 아까운데요?

A. 그래서 측정이 먼저입니다. 방향 없는 지시가 가장 비싼 실수예요. 토큰·구독 비용 손익이 궁금하면 사용량 기준으로 계산해보면 "무엇을 아껴야 하는지"가 보입니다.

3줄 정리

모호한 지시는 엉뚱한 삽질을, 긴 세션은 헛것을, 맹신은 조용한 오답을 부릅니다. 셋 다 도구가 아니라 제 사용법 문제였어요. 측정 먼저 · 작업마다 /clear · diff는 내가 판정 — 이 세 개면 대부분 막힙니다.

다음 편에선 "그럼 방향을 어떻게 주느냐" — 모호하지 않은 작업 지시를 쓰는 법을 실제 예시로 다뤄볼게요. 여러분은 에이전트한테 크게 데인 적, 어떤 종류였나요?

Cursor Auto 과금이 바뀌었다 (8/24): 내 청구서가 실제로 어떻게 달라졌나

DevPilot — Fri, 18 Sep 2026 08:01:49 +0900

핵심 요약: 8월 24일부로 Cursor가 Auto 모드의 정액요율($1.25/$6)을 없앴습니다. 이제 Auto는 "그때그때 라우팅된 모델의 정가"로 과금돼요 — Cursor 공식 안내도 "대부분의 요청은 요율이 올라간다"고 못 박았습니다. 대신 자사 모델(Composer 2.5·Grok) 포함량은 늘려줬고요. 실제로 제 사용량 그래프는 8/24 이후 같은 작업인데 더 빨리 닳기 시작했는데, 원인은 프론티어 모델(Claude·GPT)을 물린 Auto 요청이었습니다. 결론부터: 가격표(월 $20)는 그대로, 바뀐 건 "Auto 한 번의 원가"예요. 대응은 셋 — ① 일상은 Composer 2.5로 라우팅되게 두기 ② 프론티어는 난제에만 명시 지정 ③ 지출 한도 재점검. Enterprise 정액 유예도 9/7로 끝났습니다.

지난 2주간 대시보드를 들여다보며 정리한, "그래서 내 청구서엔 뭐가 달라졌나"의 기록입니다. 순서는 이렇게 갑니다: 뭐가 바뀌었나 → 두 개의 사용량 풀 → 내 그래프에 생긴 변화 → 지금 쓰는 법.

※ 기준 시점: 2026년 9월 중순. 개인 플랜 가격(Free·Pro $20·Pro+ $60·Ultra $200)은 변동 없습니다. 바뀐 건 가격표가 아니라 Auto 요청 하나가 포함 사용량을 갉아먹는 속도예요.

뭐가 바뀌었나: 정액이 사라졌다

예전 Auto는 고정 요율이었습니다 — 어떤 모델로 라우팅되든 입력 $1.25 / 출력 $6(100만 토큰당)으로 계산됐죠. 그래서 "Auto로 돌리면 예측 가능하고 싸다"가 공식이었어요.

8월 24일부로 그 고정 숫자가 사라졌습니다. 이제 Auto가 Composer 2.5로 보내면 Composer 값, Claude로 보내면 Claude 값 — 라우팅된 모델의 정가 그대로 차감됩니다. Cursor가 안내 메일에 쓴 표현이 솔직해요: "대부분의 요청은 이로 인해 요율이 더 높아집니다."

▲ 같은 "Auto"인데 과금 방식이 바뀌었습니다. 정액 한 칸 → 모델마다 다른 칸.

체감으로 옮기면 이렇습니다. Composer 2.5로 라우팅되면 오히려 예전 정액보다 쌀 수도 있어요($0.50/$2.50). 근데 Claude Fable 5 같은 상위 모델로 가면 $10/$50 — 같은 요청이 8배까지 비싸질 수 있습니다.

핵심은 "두 개의 풀"을 구분하는 것

이번 개편을 이해하는 열쇠는 포함 사용량이 두 갈래로 나뉜다는 점입니다. SpaceX 인수(8/14) 뒤 Cursor 자사 모델이 된 것들과, 남의 집 모델을 구분한 거예요.

풀	들어가는 모델	과금 성격
Cursor Models	Composer 2.5, Grok 4.6, Grok 4.5	포함량 넉넉 (자사 모델, 보조금)
Other Models	Claude·GPT·Gemini 등 프론티어	각 모델 API 정가로 차감

즉 Auto가 Cursor Models로 보내면 오래 가고, Other Models로 보내면 빨리 닳습니다. 예전엔 어디로 가든 같은 값이라 신경 쓸 필요가 없었는데, 지금은 "내 Auto가 주로 어디로 라우팅되나"가 곧 청구서예요.

▲ 사용량이 두 통으로 나뉩니다. 자사 통은 넉넉, 남의 집 통은 정가.

내 그래프에 실제로 생긴 변화

솔직히 처음엔 몰랐습니다. 8/24 다음 주에 대시보드를 열었다가 "어? 아직 월 중순인데 벌써 이만큼?" 하고 놀란 게 시작이었어요.

Usage 상세 내역을 열어보니 범인이 명확했습니다. 제가 습관적으로 어려운 작업엔 모델을 Claude로 고정해두고 Auto처럼 쓰고 있었는데, 예전엔 그게 정액이라 티가 안 났던 거죠. 8/24 이후로는 그 요청 하나하나가 Other Models 풀을 정가로 깎고 있었습니다.

그래서 실험을 해봤어요. 이틀은 평소대로, 이틀은 모델 지정을 풀고 Auto(Composer 2.5 위주)로만. 결과는 예상보다 컸습니다 — 후자 이틀의 포함량 소모가 절반 아래였어요. 물론 난제에선 Composer가 Claude만큼 안 풀릴 때가 있어서, 이건 "전부 Auto로 바꿔라"가 아니라 "기본을 뭘로 두느냐"의 문제입니다.

여기서 반전인데, 이게 꼭 나쁜 소식만은 아니었습니다. Composer 2.5로 처리되는 일상 작업(자잘한 수정, 리팩토링, 테스트 생성)은 정액 시절보다 오히려 싸졌거든요. 손해 본 건 "아무 데나 상위 모델 물려 쓰던" 제 게으른 습관이었지, 요금제 자체가 아니었어요.

그래서 지금은 이렇게 씁니다

① 기본은 Auto, 손 떼기. 모델 드롭다운을 Auto로 두면 Cursor Models로 라우팅되는 비중이 높아져 포함량이 오래 갑니다. 일상 작업에서 굳이 Claude를 지목하지 않아요.

② 프론티어는 "진짜 어려울 때만" 명시. 복잡한 설계·긴 맥락이 필요한 난제에서만 Claude/GPT를 직접 지정합니다. 그때 드는 값은 기꺼이 낼 값이고, 나머지 90%까지 그 요율을 낼 이유는 없더라고요.

③ 지출 한도 다시 확인. 과금 성격이 바뀌었으니 예전에 걸어둔 지출 한도(spend limit)가 지금 패턴에 맞는지 재점검했습니다. 종량제로 넘어가는 지점이 달라졌으니까요. 구독이냐 종량이냐 손익분기가 헷갈리면 AI 구독 vs API 계산기에 하루 요청 수를 넣어보면 감이 잡힙니다.

한 가지 더 — 이번 변경으로 "Auto가 어떤 모델을 골랐는지"가 청구에 직결되니, 저는 Usage 상세를 주 1회는 확인하는 습관을 들였습니다. 예전엔 볼 이유가 없던 화면인데 말이죠.

누가 손해, 누가 이득인가

정리하면 이렇게 갈립니다. 이득: Auto를 기본값으로 쓰며 자사 모델 비중이 높던 사람 — 포함량이 늘고 Composer 요율이 싸져 되레 여유가 생깁니다. 손해: 상위 모델을 상시 지정해 "정액이니까"라며 막 쓰던 사람 — 저처럼요. 그리고 Enterprise는 유일하게 정액을 유지했지만 그 유예도 9월 7일로 끝났습니다.

자주 묻는 질문 (FAQ)

Q. Cursor Pro 월 요금이 오른 건가요?

A. 아닙니다. 개인 플랜 가격(Pro $20 등)은 그대로입니다. 바뀐 건 Auto 요청 하나가 포함 사용량을 소모하는 방식 — 정액에서 "라우팅된 모델 정가"로 바뀐 것뿐입니다.

Q. 그럼 Auto를 쓰면 무조건 비싸지나요?

A. 아니요. Composer 2.5로 라우팅되면 예전 정액($1.25/$6)보다 오히려 쌉니다($0.50/$2.50). 비싸지는 건 Claude·GPT 같은 프론티어 모델로 라우팅될 때입니다. 그래서 "기본 Auto + 난제만 프론티어 지정"이 유리해졌습니다.

Q. 포함 사용량이 두 개로 나뉘었다는 게 무슨 뜻인가요?

A. Cursor Models(Composer·Grok, 자사 모델·넉넉)와 Other Models(Claude·GPT·Gemini, API 정가) 두 풀로 나뉩니다. 대시보드에서 어느 쪽을 얼마나 썼는지 따로 보이니, 소모가 빠르면 Other Models 쪽을 먼저 확인하세요.

Q. 이 요금 구조가 또 바뀔 수 있나요?

A. 가능성 높습니다. Cursor는 최근 1년 새 과금 구조를 여러 번 손봤습니다. 결제·플랜 변경 전에는 공식 요금 페이지를 꼭 확인하세요.

3줄 정리

가격표는 그대로, Auto 한 번의 원가가 바뀌었습니다. 기본은 Auto로 두고(Composer 라우팅) 프론티어는 난제에만 지정하면 포함량이 배로 오래 가요. 대시보드 Usage를 주 1회 보는 습관 하나로 "월 중순 방전"을 피할 수 있습니다.

저는 이번에 게으른 습관 하나 고친 셈이라, 결과적으론 청구서가 더 깔끔해졌습니다. 다음엔 8/24 이후 실제 라우팅 로그를 캡처해 "Auto가 어떤 모델을 얼마나 고르나"를 숫자로 뜯어볼 생각이에요. 여러분은 지금 모델 드롭다운이 Auto인가요, 특정 모델 고정인가요?

참고 자료

Cursor 공식 요금 페이지
Cursor 공식 문서 - 사용량 기반 과금

커서 vs 클로드코드 vs 코덱스: 작업별로 뭘 써야 하나 총정리 (디버깅·만들기·리팩토링·테스트·리뷰, 2026)

DevPilot — Wed, 16 Sep 2026 16:18:06 +0900

핵심 요약: "셋 중 뭐가 최고냐"는 틀린 질문입니다. 제가 같은 작업을 커서·클로드코드·코덱스에 똑같이 시켜본 실측 5편(디버깅·만들기·리팩토링·테스트·코드리뷰)의 결론은 하나로 모입니다 — 승자는 없고, 작업마다 잘하는 놈이 다르다. 요약하면: 맨바닥·빠른 초안·재현 쉬운 버그 = 코덱스(자율 실행 속도), 기존 코드에 얹기·앵커 주고 손보기 = 커서(IDE·@멘션), 원인 모를 버그·광범위 리팩토링·보안·심층 리뷰 = 클로드코드(맥락·깊이). 그래서 실전은 "하나 고르기"가 아니라 작업별로 나눠 쓰는 스택이고, 무엇을 쓰든 마지막 공통 결론은 같습니다 — 빨라질수록 검수가 실력.

이 글에서 다루는 내용: 왜 "하나의 승자"가 없는지, 작업별 결정 매트릭스, 5개 실측의 한 줄 결론, 내 실제 조합, 비용 관점.

왜 "최고의 도구"가 없나

세 도구는 애초에 노리는 자리가 다릅니다. 코덱스는 자리를 비워도 끝까지 미는 자율 실행, 커서는 내가 옆에서 같이 하는 IDE 통합, 클로드코드는 코드베이스 맥락을 깊이 읽는 추론. 그래서 "합쳐서 하나가 이긴다"가 아니라, 최근 업계 분석대로 오케스트레이션·실행·리뷰 계층으로 나뉘는 "조합형 스택"으로 가고 있어요. 제가 다섯 가지 실제 작업을 셋에 똑같이 시켜본 것도 이걸 확인한 과정이었습니다.

▲ "뭐가 최고냐"가 아니라 "이 작업엔 뭐가 맞냐"로 보면 답이 명확해집니다.

작업별 결정 매트릭스

작업	1순위	보조	한 줄 이유
버그 수정(디버깅)	클로드코드	코덱스(재현 쉬우면)	원인을 거슬러 추적하는 깊이
새 기능 스캐폴딩	코덱스 / 커서	클로드코드	맨바닥=코덱스 속도, 기존에 얹기=커서 앵커
레거시 리팩토링	클로드코드	커서(범위 좁으면)	흩어진 호출부 전수 추적
테스트 생성	클로드코드	코덱스(양)	커버리지 숫자보다 엣지케이스
코드 리뷰	Bugbot(상시) + 클로드코드(심층)	코덱스(빠른 스캔)	1차 자동 필터 + 중요 PR 심층

5개 실측, 한 줄씩

① 디버깅 — 같은 간헐 버그에 셋을 물렸더니 코덱스는 증상만 덮고, 커서는 위치를 알려주면 고쳤고, 클로드코드만 원인(stale closure)까지 갔습니다(디버깅 편). ② 스캐폴딩 — 새 기능을 만들 때 코덱스는 빨랐지만 컨벤션을 겉돌았고, 커서는 앵커를 주면 결이 맞았고, 클로드코드는 힌트 없이 구조를 읽어 맞췄습니다(스캐폴딩 편). ③ 리팩토링 — 광범위 수정에서 코덱스는 호출부 2곳을 놓쳤고, 커서는 대형 스팬 후반에 놓쳤고, 클로드코드가 전수 추적으로 다 잡았습니다(리팩토링 편). ④ 테스트 — 코덱스는 커버리지 100%인데 심어둔 버그를 0개 잡았고, 클로드코드만 엣지케이스로 버그를 드러냈습니다(테스트 편). ⑤ 코드 리뷰 — Bugbot은 상시 1차 필터, 코덱스는 표면적, 클로드코드는 보안까지 짚었습니다(코드리뷰 편).

▲ 하나로 합쳐지지 않고 계층으로 나뉜다 — 그게 2026년 AI 코딩 스택의 현재 모습입니다.

내 실제 조합

이 다섯 번의 실측이 제 워크플로를 이렇게 정리해줬습니다. 새 기능·초안은 맨바닥이면 코덱스, 기존 코드에 얹으면 커서에 앵커. 버그·리팩토링·테스트처럼 "빠짐없이·깊이"가 중요한 건 클로드코드. 코드 리뷰는 Bugbot을 모든 PR에 상시로 깔고, 결제·보안·마이그레이션 PR만 클로드코드로 심층. 한 도구에 충성하는 대신 작업이 손에 들어올 때 "이건 누구 자리지?"를 먼저 묻는 습관이 생겼어요.

비용 관점: 다 결제할 필요는 없다

셋을 다 구독할 필요는 없습니다. 대부분은 하나(주력) + 무료/체험 하나로 시작해, 병목이 반복되는 작업이 생기면 그때 하나를 더합니다. 시작가는 셋 다 월 $20 근처지만 에이전트를 매일 헤비하게 돌리면 실제 예산은 훨씬 커지니(Claude Code 요금·Cursor 요금), 무료로 자기 작업에 같은 걸 시켜보고 정하는 게 가장 정확합니다. 구독 vs API 손익은 비용 계산기에 하루 요청 수를 넣으면 바로 나옵니다.

자주 묻는 질문 (FAQ)

Q. 딱 하나만 골라야 한다면요?

A. 작업 폭이 넓고 "빠짐없이·깊이"가 중요하다면 클로드코드가 안전한 기본값입니다. 다만 IDE에서 눈으로 diff를 보며 가고 싶으면 커서, 맨바닥에서 빠르게 찍어내는 일이 많으면 코덱스가 더 맞을 수 있어요. 하나만 고르기 전에 무료로 자기 작업에 셋을 시켜보길 권합니다.

Q. 초보인데 뭐부터 시작하나요?

A. IDE가 익숙하면 커서(눈으로 확인하며 배우기 좋음), 터미널이 편하면 클로드코드부터. 코덱스는 "던져두고 결과 받기"에 익숙해진 뒤에 붙이는 게 자연스럽습니다.

Q. 결국 공통 결론은 뭔가요?

A. 어떤 도구든 빠르게 만들어줄수록, "이게 맞는지" 확인하는 사람의 검수가 실력이 됩니다. 다섯 작업 모두에서 같은 결론에 도달했습니다 — AI는 검수를 대신하는 게 아니라 검수를 잘하게 돕는 도구입니다.

한눈에 보는 요약

승자는 없고 작업별 적임자가 있습니다 — 맨바닥·빠른 초안은 코덱스, 기존에 얹기는 커서, 원인 모를 버그·광범위 리팩토링·테스트·심층 리뷰는 클로드코드. 실전은 하나 고르기가 아니라 작업별로 나눠 쓰는 조합형 스택이고, 무엇을 쓰든 마지막은 사람 검수입니다.

함께 보면 좋은 글 (실측 5편)

① 디버깅: 같은 버그에 다 시켜봤다
② 스캐폴딩: 같은 기능에 다 만들게 시켰다
③ 리팩토링: 같은 광범위 수정에 다 시켰다
④ 테스트: 같은 함수에 테스트 짜게 시켰다
⑤ 코드 리뷰: 같은 PR에 리뷰시켰다

참고 자료

Cursor 공식 사이트
Claude Code 공식 문서
OpenAI Codex 소개

같은 PR, 커서 Bugbot·클로드코드·코덱스에 리뷰시켰다: 뭘 잡고 뭘 놓치나 (2026)

DevPilot — Tue, 15 Sep 2026 07:57:13 +0900

핵심 요약: 리뷰 시리즈 다섯 번째 — 이번엔 "코드 리뷰를 시켜보기"입니다. 제 서비스(AI 비용 계산기)의 실제 PR 하나(환율 유틸 리팩토링, 일부러 버그·보안 이슈 심음)를 커서 Bugbot(PR 자동 리뷰)·클로드코드(로컬 심층 리뷰)·코덱스(클라우드 PR 리뷰)에 똑같이 리뷰시켰어요. 결과: Bugbot은 PR에 붙어 명백한 버그·스타일을 빠르게 코멘트했지만 깊은 로직·보안은 얕았고(+오탐 약간), 코덱스는 빠르게 훑되 표면적, 클로드코드만 코드베이스 맥락을 읽어 숨은 보안 이슈(입력 검증 누락)와 엣지케이스까지 짚었습니다. 한 줄 결론: 상시 1차 필터는 Bugbot, 중요 PR 심층 리뷰는 클로드코드, 빠른 스캔은 코덱스 — 그리고 셋 다 사람 리뷰를 대체하는 게 아니라 앞단에 까는 것입니다.

이 글에서 다루는 내용: 어떤 PR이었나, 공정 비교 규칙, 세 도구의 리뷰 결과, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 PR이었나

대상은 통화 환산 유틸을 공용 함수로 통합한 PR이었습니다(지난 리팩토링 편에서 다룬 그 작업의 실제 PR). 리뷰 도구의 검출력을 보려고 세 가지 결함을 일부러 심었어요 — ① 음수 입력 검증 누락(환불 케이스에서 오작동), ② 사용자 입력을 그대로 쓰는 보안 이슈(검증 없이 파싱), ③ 반올림 경계의 미묘한 로직 버그. 관전 포인트는 "이 셋을 각각 잡느냐, 아니면 스타일 지적만 하고 넘어가느냐"였습니다.

▲ 같은 PR, 세 갈래 리뷰. 상시 1차 필터냐, 빠른 스캔이냐, 맥락을 읽는 심층이냐.

공정하게 비교하려고 정한 규칙

① 같은 PR — 셋 다 같은 diff. ② 같은 요청 — "이 PR을 리뷰해줘"만, 심어둔 결함 힌트는 안 줌. ③ 같은 잣대 — 심어둔 세 결함을 몇 개 잡는가, 오탐(잘못된 지적)이 얼마나 나오는가, 리뷰가 실행 가능한(actionable) 코멘트인가, 그리고 비용·워크플로. 사람이 이미 아는 결함으로 채점하니 "리뷰가 진짜인지 스타일 훈수인지"가 바로 드러납니다.

① 커서 Bugbot: PR에 붙는 빠른 1차 필터

Bugbot의 강점은 워크플로였습니다 — PR을 올리면 자동으로 GitHub에 리뷰 코멘트가 달려서, 내가 부르지 않아도 1차 점검이 됩니다. 명백한 버그(반올림 경계)와 스타일 이슈를 빠르게 짚었어요. 다만 보안 이슈(입력 검증 누락)는 놓쳤고, 오탐도 한 건 있었습니다("이 변수 안 쓰임" — 실제론 쓰임). 리뷰당 과금($1~1.5, PR 클수록 비쌈)이라 모든 PR에 자동으로 돌리면 티끌이 쌓이므로, 일정 규모 이상 PR에만 트리거하는 규칙이 필요합니다.

② 코덱스: 빠르지만 표면적

코덱스도 PR 리뷰를 지원하는데, 가장 빨랐지만 가장 얕았습니다. 심어둔 셋 중 반올림 버그 하나만 잡고, 음수 검증·보안은 넘어갔어요. 코멘트도 "이 부분을 확인하세요" 수준의 일반론이 많아 바로 고칠 수 있는(actionable) 지적은 적었습니다. 여러 PR을 빠르게 훑어 "큰 문제 없나" 보는 용도엔 맞지만, 리뷰를 이걸로 끝내면 위험합니다.

// 세 도구가 잡은 결함 (심어둔 3개 중)
// Bugbot:   반올림 버그 O / 음수검증 X / 보안 X  (+오탐 1)
// Codex:    반올림 버그 O / 음수검증 X / 보안 X
// ClaudeCode: 반올림 O / 음수검증 O / 보안 O

③ 클로드코드: 맥락을 읽어 보안까지 짚었다

클로드코드에는 로컬에서 "이 변경을 리뷰해줘"라고 시켰는데, 코드베이스 맥락을 읽어 세 결함을 모두 짚었습니다. 특히 입력 검증 누락을 "보안 이슈"로 분류하고 "이 값이 사용자 입력에서 온다면 검증이 필요하다"며 근거까지 달았어요 — 지난 보안 스캔 후기에서 본 깊이가 리뷰에서도 나온 셈입니다. 대가는 역시 느리고 토큰을 많이 쓰며, PR에 자동으로 붙지 않아 내가 직접 불러야 한다는 점. "상시 자동"이 아니라 "중요 PR에 부르는 심층 리뷰어"에 가깝습니다.

▲ AI 리뷰는 사람을 대체하는 게 아니라 앞단에 까는 계층입니다.

항목별 비교

항목	커서 Bugbot	코덱스(Codex)	클로드코드
워크플로	PR에 자동 코멘트	클라우드 PR 리뷰	로컬, 직접 호출
심어둔 결함 검출	1/3 (+오탐)	1/3	3/3
보안 이슈	놓침	놓침	짚음(근거까지)
코멘트 실행가능성	중간	낮음(일반론)	높음
속도·비용	빠름·PR당 과금	가장 빠름	느림·토큰↑
포지션	상시 1차 필터	빠른 스캔	심층 리뷰어

상황별 추천

모든 PR에 상시 1차 점검을 깔고 싶을 때: Bugbot이 워크플로상 최적입니다 — 자동으로 붙으니까(단, 트리거 규칙으로 비용 관리). 중요하거나 위험한 PR을 깊게 보고 싶을 때: 클로드코드에 직접 리뷰를 시키세요 — 보안·엣지케이스까지 잡습니다. 여러 PR을 빠르게 훑어 큰 문제만 거르고 싶을 때: 코덱스가 빠릅니다(단, 이걸로 리뷰를 끝내지 말 것). 저는 Bugbot을 상시 1차 필터로 깔고, 결제·보안·마이그레이션 관련 PR만 클로드코드로 심층 리뷰하는 2단 구성을 씁니다. AI 코드 리뷰 도구 전반 비교는 이 글에 따로 있습니다.

정작 제일 크게 배운 것

세 도구 중 무엇도 사람 리뷰를 대체하지 못했습니다 — 가장 깊었던 클로드코드조차 "이건 의도된 동작인가?"라는 맥락 판단은 못 했으니까요. AI 코드 리뷰의 진짜 값은 사람이 봐야 할 것을 줄여주는 1차 필터에 있습니다. 명백한 것들을 AI가 걸러주면, 사람은 "이 설계가 맞나" 같은 고차원 판단에 집중할 수 있죠. 리뷰 5편을 오면서 계속 같은 결론에 도달했는데, 코드 리뷰 편에서 그게 가장 선명해졌어요 — AI는 검수를 대신하는 게 아니라, 검수를 잘하게 도와주는 도구입니다.

자주 묻는 질문 (FAQ)

Q. AI 코드 리뷰가 사람 리뷰를 대체하나요?

A. 아니요. 명백한 버그·스타일·일부 보안 이슈를 앞단에서 걸러주는 1차 필터입니다. "이게 의도된 동작인가", "이 설계가 맞나" 같은 맥락 판단은 여전히 사람 몫이라, AI 리뷰 위에 사람 리뷰를 얹는 계층 구성이 맞습니다.

Q. 코드 리뷰엔 어떤 도구가 제일 낫나요?

A. 용도에 따라 다릅니다. 모든 PR 상시 1차 점검은 Bugbot(자동), 중요·위험 PR 심층 리뷰는 클로드코드(보안·엣지케이스), 빠른 스캔은 코덱스입니다. Bugbot 1차 + 중요 PR만 클로드코드 심층의 2단이 효율적이었습니다.

Q. Bugbot을 모든 PR에 돌리면 비용이 괜찮나요?

A. 리뷰당 과금이라 PR이 많으면 쌓입니다. 일정 규모(예: 50줄) 이상 PR에만 트리거하는 규칙을 걸면 지출을 절반 가까이 줄일 수 있습니다.

Q. AI 리뷰 코멘트를 그대로 반영해도 되나요?

A. 오탐이 섞입니다(이번에도 "안 쓰이는 변수" 오탐이 있었습니다). 코멘트를 참고로 받아들이되 실제 코드로 확인하고 반영하세요. 반복되는 오탐은 규칙·설정에 피드백하면 노이즈가 줄어듭니다.

한눈에 보는 요약

같은 PR을 세 도구에 리뷰시켰더니 — Bugbot은 PR에 자동으로 붙는 빠른 1차 필터(깊이는 얕고 오탐 약간), 코덱스는 가장 빠르지만 표면적, 클로드코드는 맥락을 읽어 보안·엣지케이스까지 유일하게 짚음. 상시 1차는 Bugbot, 심층은 클로드코드, 빠른 스캔은 코덱스. 그리고 셋 다 사람 리뷰의 대체가 아니라 앞단 필터입니다.

참고 자료

Claude Code 공식 문서
Cursor 공식 사이트 (Bugbot)
OpenAI Codex 소개

Devin에 실제 작업 4개 시켜본 한 달 실전기: ACU 비용, PR 품질, 삽질까지 (2026)

DevPilot — Sun, 13 Sep 2026 17:34:46 +0900

핵심 요약: "AI 개발자" Devin을 한 달 결제해 제 서비스(AI 비용 계산기)와 블로그 코드에 실제 작업 4개를 시켜봤습니다. 결론부터 — 잘 정의된 반복 작업·버그 수정에서는 진짜 "외주 준 느낌"이 나지만(그동안 딴 일을 할 수 있음), 모호한 작업에선 러빗홀에 빠져 ACU만 태우고 실패했습니다. 가장 인상적이었던 건 병렬 실행(여러 작업 동시에)과 PR을 알아서 올려주는 fire-and-forget, 가장 아팠던 건 ACU 비용(같은 작업이 Cursor·Claude Code로는 몇 분의 1)과 "마지막 30%"(핵심은 되는데 엣지·UI가 미완). 한 줄 정리: Devin은 사람 대체가 아니라 "잘 정의된 티켓을 던지는 비동기 주니어"이고, 그 전제에서만 값을 합니다.

이 글에서 다루는 내용: 결제·셋업, 작업 4개의 타임라인과 ACU 실측, PR 품질과 삽질, 기능별 소감, 한 달 뒤 내 결론.

※ ACU(Agent Compute Unit)는 Devin의 작업량 단위입니다. 요금·ACU 단가는 자주 바뀌니 정확한 최신 요금은 Devin 요금 정리와 공식 페이지를 확인하세요 — 이 글은 "작업당 ACU가 얼마나 드는지"의 체감에 초점을 둡니다.

결제와 셋업: 15분

결제 후 GitHub 조직과 슬랙을 연결하면 끝입니다. 컨트롤은 두 가지 — 웹 앱과 슬랙 봇인데, 저는 슬랙을 썼어요(웹은 알림이 약해서 컨펌 대기 중인 걸 놓치기 쉽습니다). Devin이 중간에 확인이 필요하면 슬랙으로 물어보고, 답하기 전까진 기다립니다 — 그래서 알림을 놓치면 작업이 그대로 멈춰 있습니다. 셋업 자체는 매끄러웠고, "메신저로 동료에게 일 시키는" 감각이 바로 잡혔습니다.

작업 4개, 타임라인과 ACU 실측

제 실제 백로그에서 성격이 다른 네 가지를 골라 던졌습니다.

작업	성격	ACU	결과
계산기 5개 페이지에 SEO 메타태그 일괄 추가	반복·잘 정의	낮음	⭕ 깔끔 (병렬로 한 번에)
환율 표시가 가끔 갱신 안 되는 버그 수정	잘 정의된 버그	보통	⭕ 원인 찾고 테스트까지 클린 PR
계산 결과 공유 링크 기능 추가	새 기능	높음	△ 핵심은 되나 "마지막 30%" 미완
"낡은 코드 좀 정리해줘"(범위 모호)	모호·아키텍처	매우 높음	❌ 러빗홀 → 태우고 실패

▲ 같은 도구, 작업 성격에 따라 결과와 비용이 극과 극. 잘 정의될수록 싸고 성공, 모호할수록 비싸고 실패.

빛난 자리: 반복 잡일과 잘 정의된 버그

SEO 메타태그 일괄 추가는 Devin의 강점이 그대로 나온 작업입니다 — 다섯 페이지를 병렬로 처리하고 PR을 올려줬는데, 그동안 저는 다른 글을 쓰고 있었어요. Cursor·Claude Code로도 되지만 "에디터를 붙잡고 기다리는" 시간이 있는데, Devin은 샌드박스에서 알아서 돌고 끝나면 알려주는 비동기라 그 시간이 통째로 제 것이 됩니다. 환율 갱신 버그도 sweet spot이었어요 — 재현 조건이 명확하니 원인(비동기 갱신 누락)을 찾아 고치고 테스트까지 붙인 클린 PR을 올렸습니다. 이 두 작업만 보면 "월 구독값 하네" 싶었습니다.

아팠던 자리: "마지막 30%"와 러빗홀

공유 링크 기능에서 그 유명한 "마지막 30%"를 만났습니다 — 링크 생성·복원의 핵심 로직은 잘 짰는데, 만료 처리·에러 UI·기존 컴포넌트와의 통합이 비어 있었어요. 두 번 피드백을 주고서야 마무리됐는데, 그 왕복에 ACU가 계속 붙었습니다. 더 아팠던 건 "낡은 코드 정리" — 범위를 모호하게 던졌더니 Devin이 러빗홀에 빠졌습니다. 한 곳을 고치다 예상 못 한 에러를 만나자 점점 복잡한 "수정"을 쌓으며 상황을 악화시켰고, 결국 ACU만 크게 태우고 결과물은 오히려 처음보다 나빴어요. 이건 도구 탓이 아니라 제가 명세를 안 준 탓이 컸습니다.

기능별 소감

병렬 실행이 진짜 차별점입니다 — 여러 작업을 동시에 던지고 각각 PR로 받는 경험은 단일 에디터 도구엔 없죠. 웹 VS Code로 Devin이 삽질한 걸 직접 고칠 수 있는데, 고친 뒤 "뭘 바꿨는지" 채팅으로 알려줘야 하는 번거로움이 있습니다. Knowledge(작업 중 배운 관례를 저장)는 반복 사용 시 강력한데, 저처럼 짧게 써볼 거면 우리 프로젝트 규칙 파일에 정리해두는 편이 낫습니다. 타임라인으로 과거 실행 과정을 되짚어볼 수 있어, 어디서 삽질했는지 복기하고 다음 지시를 다듬기 좋았습니다.

비용 감각: 정직하게

ACU 과금은 불투명하고, 헤비하게 쓰면 빠르게 쌓입니다. 잘 정의된 작업 몇 개는 저렴했지만, 러빗홀에 빠진 모호한 작업 하나가 나머지를 합친 것보다 더 태웠어요. 같은 작업을 Cursor·Claude Code로 하면 몇 분의 1이라, "백로그에 잘 정의된 티켓이 꾸준히 쌓이는 팀"이 아니면 개인에겐 비쌉니다. 결국 손익은 사용량이 정합니다 — 상세 기준은 요금 글과 비용 계산기에서.

▲ 기대치를 여기에 맞추면 실망이 없습니다 — 던져두고 잊을 수 있는 잘 정의된 일에만.

한 달 뒤 내 결론

Devin은 "사람 대체"가 아니라 새로운 종류의 팀원입니다 — 정확히는 잘 정의된 티켓을 던지면 비동기로 처리하는 주니어. 그 전제(명확한 수용 기준 + 코드리뷰)를 지키면 반복 작업·버그·테스트·마이그레이션에서 시간을 벌어주고, 그 전제를 어기면(모호한 지시) 돈만 태웁니다. 저는 개인 프로젝트 규모라 상시 구독은 접었지만, "이번 주에 잘 정의된 잡일이 열 개 쌓였다" 싶은 시점이 오면 다시 붙일 겁니다. 무엇을 잘하고 못하는지, 어떻게 지시해야 성공률이 오르는지는 잘하는 일 vs 못하는 일과 지시문 템플릿에 따로 정리해뒀습니다.

자주 묻는 질문 (FAQ)

Q. Devin, 개인 개발자가 결제할 만한가요?

A. 잘 정의된 잡일·버그·테스트가 꾸준히 쌓이는 사람이라면 병렬·비동기 처리로 값을 합니다. 하지만 작업이 드물거나 모호·복잡한 일이 많으면 ACU 비용 대비 효율이 나빠, Claude Code 같은 저가 대안이 낫습니다.

Q. 성공률을 높이는 가장 큰 요인은요?

A. 작업 설명(명세)의 품질입니다. 재현 절차·기대 결과·관련 파일·검증 방법을 구체적으로 줄수록 성공하고, "낡은 코드 정리해줘" 같은 모호한 지시는 러빗홀로 갑니다. 초반 몇 분의 계획을 확인해 방향을 잡아주는 것도 중요합니다.

Q. Devin이 만든 PR을 그냥 머지해도 되나요?

A. 안 됩니다. 주니어 PR처럼 다뤄야 합니다 — 보안, 엣지케이스, 컨벤션, "마지막 30%"(만료·에러·통합 누락)를 반드시 검수하세요. Devin은 보안 취약점을 놓치는 경우가 있습니다.

Q. Cursor·Claude Code가 있는데 Devin이 필요한가요?

A. 성격이 다릅니다. 커서·클로드코드는 내가 옆에서 같이 하는 도구, Devin은 자리를 비워도 알아서 끝내는 비동기·병렬 도구입니다. "던져두고 잊기"가 필요한 잘 정의된 작업이 많을 때 Devin이 갈립니다. 1:1 비교는 Devin vs Cursor에 있습니다.

한눈에 보는 요약

한 달 실사용 결론 — Devin은 잘 정의된 반복·버그·테스트를 병렬·비동기로 처리할 때 "외주 준 느낌"으로 값을 하지만, 모호한 작업엔 러빗홀로 ACU만 태웁니다. "마지막 30%"와 비용은 감안해야 하고, 무엇을 쓰든 PR 검수는 필수. 사람 대체가 아니라 "잘 정의된 티켓을 던지는 비동기 주니어"로 보면 기대치가 맞습니다.

참고 자료

Devin 공식 사이트
Devin 공식 문서

같은 함수, 커서·클로드코드·코덱스에 테스트 짜게 시켰다: 커버리지 vs 엣지케이스 (2026)

DevPilot — Sat, 12 Sep 2026 22:11:10 +0900

핵심 요약: 리뷰 시리즈 네 번째 — 이번엔 "테스트 짜게 시키기"입니다. 제 서비스(AI 비용 계산기)의 비용 환산·합계 함수 하나에 단위 테스트를 커서(Cursor)·클로드코드(Claude Code)·코덱스(Codex)에 동일 투입했어요. 결과가 테스트의 본질을 그대로 드러냈습니다 — 코덱스는 테스트를 제일 많이·빠르게 뽑아 커버리지 숫자는 최고였지만 대부분 해피패스라 진짜 버그는 못 잡았고, 커서는 기존 테스트 파일을 앵커로 주자 우리 스타일 그대로 확장했으며, 클로드코드만 코드를 읽고 경계값·예외 경로 같은 엣지케이스를 스스로 짚어 실제로 숨은 버그(음수 입력·null 환율)를 드러냈습니다. 한 줄 결론: 커버리지 숫자는 코덱스, 스타일 일관성은 커서, 버그 잡는 엣지케이스는 클로드코드 — 그리고 커버리지 %는 품질이 아닙니다.

이 글에서 다루는 내용: 어떤 테스트 과제였나, 공정 비교 규칙, 세 도구의 실제 결과, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 과제였나

대상은 USD 비용을 받아 환율을 적용하고 KRW 합계를 내는 함수였습니다. 겉보기엔 단순하지만 숨은 함정이 많은 종류예요 — 0원, 음수(환불 케이스), 아주 큰 값, null 환율(조회 실패), 반올림 경계. 과제는 "이 함수의 단위 테스트를 작성해줘"만 주는 것. 관전 포인트는 명확했습니다 — 커버리지 숫자를 채우느냐, 아니면 실제로 깨질 수 있는 지점을 짚느냐.

▲ 같은 함수, 세 갈래 테스트. 숫자를 채우느냐, 스타일을 맞추느냐, 깨질 곳을 찾느냐.

공정하게 비교하려고 정한 규칙

① 같은 시작점 — 셋 다 같은 함수, 같은 커밋. ② 같은 프롬프트 — "이 함수의 단위 테스트를 작성해줘"만, 엣지케이스 힌트는 안 줌. ③ 같은 잣대 — 생성된 테스트의 커버리지 %, 그리고 더 중요하게 내가 알고 있던 버그(음수·null 환율)를 잡아내는가, 테스트가 우리 기존 스타일(pytest fixture·given-when-then)을 따르는가. 커버리지는 도구로 측정하고, "버그를 잡느냐"는 일부러 함수에 심어둔 결함으로 검증했습니다.

① 코덱스(Codex): 커버리지는 최고, 버그는 못 잡음

코덱스는 테스트를 가장 많이·빠르게 뽑았습니다. 라인 커버리지가 100%에 근접했고 실행도 다 통과했어요. 문제는 내용이었습니다 — 대부분 해피패스(정상 값 넣고 정상 결과 확인)와 자명한 검증이라, 제가 심어둔 음수 입력·null 환율 버그를 하나도 못 잡았습니다. 커버리지 숫자는 "모든 줄이 실행됐다"만 말할 뿐, "모든 경우가 검증됐다"가 아니니까요.

// 코덱스가 뽑은 전형적 테스트 (해피패스 위주)
test("converts USD to KRW", () => {
  expect(convert(10, 1300)).toBe(13000);
}); // 음수·null·경계값은 없음

맨바닥에서 "일단 테스트 골격을 빠르게 깔고 싶을 때"는 이 속도가 강점입니다. 하지만 테스트의 목적이 버그를 잡는 것이라면, 높은 커버리지 숫자가 오히려 "테스트가 충분하다"는 착각을 줘서 위험할 수 있어요.

② 커서(Cursor): 앵커를 주면 우리 스타일 그대로

커서는 기존 테스트 파일을 @멘션 앵커로 넘기자 진가를 냈습니다 — "@test_pricing.py 이 스타일 그대로 convert 함수 테스트를 작성해줘"라고 하니, 기존 fixture를 재사용하고 given-when-then 주석 구조까지 맞춰서 나왔어요. 인라인 diff로 확인이 편했고요. 다만 앵커(참고 테스트)가 없으면 코덱스처럼 해피패스 위주가 됐습니다 — "좋은 예시 테스트 하나"가 있느냐가 결과를 갈랐습니다.

// 커서: 앵커(@test_pricing.py) 스타일을 그대로 복제
def test_convert_negative_refund(rate_fixture):
    # given-when-then, 기존 fixture 재사용 (앵커 스타일)
    assert convert(-10, rate_fixture) == -13000

테스트가 아예 없는 프로젝트라면 첫 테스트 하나를 공들여 만들고 그걸 앵커로 확장하는 방식이 좋습니다. 관례를 Rules에 넣어두면 앵커 없이도 스타일이 유지되고요.

③ 클로드코드(Claude Code): 엣지케이스를 스스로 짚었다

클로드코드에는 앵커 없이 함수만 줬는데, 코드를 읽고 "여기서 깨질 수 있다"를 추론했습니다 — 음수 입력, null 환율, 0, 아주 큰 값, 반올림 경계를 각각 테스트로 만들었고, 그중 음수와 null 환율 테스트가 실제로 실패하며 제가 심어둔 버그를 드러냈어요. 커버리지 숫자는 코덱스보다 오히려 낮게 나온 케이스도 있었지만, 버그를 잡은 건 이쪽뿐이었습니다. 지난 디버깅 편의 "코드를 깊이 읽는" 강점이 테스트에서도 그대로 나온 셈입니다.

▲ 커버리지 100%가 "테스트 충분"이 아닙니다. 모든 줄이 실행돼도 엣지케이스가 없으면 버그는 통과합니다.

대가는 역시 토큰과 속도였습니다 — 코드를 읽고 위험 지점을 추론하느라 코덱스보다 느리고 소모가 컸어요. 하지만 "테스트를 왜 짜는가"가 버그를 잡기 위해서라면, 그 값을 하는 유일한 결과물이었습니다.

항목별 비교

항목	코덱스(Codex)	커서(Cursor)	클로드코드(Claude Code)
속도·양	가장 빠름·많음	빠름	느림(추론)
커버리지 숫자	최고(100% 근접)	앵커 따라 높음	보통
엣지케이스	거의 없음(해피패스)	앵커에 있으면 반영	스스로 짚음
심어둔 버그 검출	0건	앵커에 유사 케이스 있으면	음수·null 검출
스타일 일관성	제네릭	앵커로 정확	양호(코드 관례 추론)
이대로 신뢰?	❌ (숫자만 높음)	⭕ (좋은 앵커 필요)	⭕ (검수 후)

상황별 추천

테스트 골격을 빠르게 깔고 싶을 때(양이 우선): 코덱스가 빠릅니다 — 단, 엣지케이스는 사람이 따로 추가한다는 전제로. 기존 테스트 스타일을 지키며 확장할 때: 커서에 좋은 예시 테스트를 앵커로 주면 가장 일관됩니다. 버그를 잡는 게 목적일 때(엣지케이스가 핵심): 클로드코드의 추론이 값을 합니다. 저는 요즘 코덱스로 골격을 빠르게 깔고 → 클로드코드에 "엣지케이스만 보강해줘"로 넘기는 2단 구성을 씁니다 — 속도와 깊이를 둘 다 가져가는 방법이에요. 커버리지 %보다 무엇이 중요한지는 이 글에 단일 도구 관점으로 따로 정리해뒀습니다.

정작 제일 크게 배운 것

세 도구를 가른 건 "테스트를 얼마나 짜느냐"가 아니라 "무엇을 검증하느냐"였습니다. 코덱스의 100% 커버리지가 버그를 하나도 못 잡은 게 이 시리즈에서 가장 인상적인 장면이었어요 — 커버리지 %는 안심을 주지만 안전을 주지 않습니다. AI가 테스트를 순식간에 뽑아줄수록, "이 테스트가 실제로 깨질 곳을 건드리는가"를 사람이 확인하는 눈이 더 중요해집니다. 리뷰 4편(디버깅·스캐폴딩·리팩토링·테스트)이 결국 같은 자리에 도착했네요 — 빨라질수록 검수가 실력입니다.

자주 묻는 질문 (FAQ)

Q. 테스트 생성엔 어떤 도구가 제일 낫나요?

A. 목적에 따라 다릅니다. 커버리지 숫자·양이면 코덱스, 기존 스타일 유지면 커서(앵커 필요), 버그를 잡는 엣지케이스면 클로드코드입니다. 실전에선 코덱스로 골격을 깔고 클로드코드로 엣지케이스를 보강하는 2단 구성이 효율적이었습니다.

Q. 커버리지 100%면 테스트가 충분한 거 아닌가요?

A. 아닙니다. 커버리지는 "모든 줄이 실행됐다"만 뜻하고 "모든 경우가 검증됐다"가 아닙니다. 이번에도 커버리지 100%에 가까운 테스트가 음수·null 같은 엣지케이스 버그를 하나도 못 잡았습니다.

Q. AI가 만든 테스트를 그냥 믿어도 되나요?

A. 특히 테스트는 안 됩니다. 얕은 테스트는 "테스트가 있다"는 착각만 주고 버그는 통과시킵니다. 최소한 알고 있는 실패 케이스(경계값·예외)를 AI 테스트가 잡는지 확인하고 채택하세요.

Q. 테스트가 아예 없는 프로젝트는 어디서 시작하나요?

A. 첫 테스트 파일 하나를 fixture·네이밍·given-when-then까지 공들여 만들고, 그걸 앵커로 커서에 확장시키는 방식이 좋습니다. 그 뒤 엣지케이스는 클로드코드로 보강하세요.

한눈에 보는 요약

같은 함수에 테스트를 세 도구에 시켰더니 — 코덱스는 커버리지 최고지만 버그 0건, 커서는 앵커를 주면 스타일 그대로, 클로드코드는 엣지케이스를 스스로 짚어 유일하게 버그를 잡았습니다. 양은 코덱스, 스타일은 커서, 버그 검출은 클로드코드. 그리고 커버리지 %는 품질이 아니라는 것 — 실전에선 코덱스로 깔고 클로드코드로 보강하는 2단이 답이었습니다.

참고 자료

Claude Code 공식 문서
OpenAI Codex 소개
Cursor 공식 사이트

같은 리팩토링, 커서·클로드코드·코덱스에 다 시켰다: 광범위 수정 실전 비교 (2026)

DevPilot — Thu, 10 Sep 2026 20:27:35 +0900

핵심 요약: 버그 수정·새 기능 편에 이어, 리뷰 3부작의 마지막 — "리팩토링 시키기"입니다. 제 서비스(AI 비용 계산기)에서 여러 컴포넌트에 흩어진 통화 환산(USD→KRW) 로직을 공용 유틸 하나로 통합하는 과제를 커서·클로드코드·코덱스에 동일 투입했어요. 리팩토링의 생명은 "흩어진 호출부를 하나도 빠뜨리지 않고 다 바꾸느냐"인데 — 클로드코드가 긴 컨텍스트로 전 호출부를 추적해 가장 안전했고, 커서는 파일을 @멘션 앵커로 짚어주면 정확했지만 파일 수가 많아지자 후반에 몇 개를 놓쳤으며, 코덱스는 제일 빨랐지만 흩어진 호출부 두 곳을 빠뜨려 그대로 머지했으면 환산이 어긋날 뻔했습니다. 한 줄 결론: 광범위 리팩토링은 클로드코드, 범위가 좁으면 커서(앵커), 빠른 시도는 코덱스+철저한 검수.

이 글에서 다루는 내용: 어떤 리팩토링이었나, 공정 비교 규칙, 세 도구의 실제 결과, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 리팩토링이었나

제 계산기에는 통화 환산 로직이 컴포넌트마다 복붙돼 있었습니다 — 결과 카드, 비교 표, 요약 배너 등 여러 곳에서 각자 USD에 환율을 곱하고 있었죠(전형적인 레거시 냄새). 과제는 이걸 공용 유틸 함수 하나로 뽑아내고 모든 호출부를 그 함수로 교체하는 것이었습니다. 어려운 지점은 로직 자체가 아니라 범위였어요 — 흩어진 호출부가 십수 군데라, "하나라도 빠뜨리면 그 화면만 옛날 환율로 남는" 리팩토링이었습니다.

▲ 같은 리팩토링, 세 갈래. 리팩토링의 승부는 지능보다 "흩어진 호출부를 다 잡느냐"에서 났습니다.

공정하게 비교하려고 정한 규칙

세 가지를 고정했습니다. ① 같은 시작점 — 셋 다 같은 커밋에서 출발. ② 같은 프롬프트 — "여러 곳에 복붙된 USD→KRW 환산 로직을 공용 유틸 하나로 뽑고, 모든 호출부를 교체해줘"만 주고 힌트는 안 줌. ③ 같은 잣대 — 흩어진 호출부를 몇 개나 빠뜨리는가, 빌드·테스트가 통과하는가, 사람이 손볼 게 얼마나 남는가, "이대로 머지해도 되나". 검증은 리팩토링 전후로 모든 화면의 환산 결과가 동일한지 스냅샷 테스트로 확인했습니다.

① 코덱스(Codex): 제일 빨랐지만 두 곳을 놓쳤다

코덱스는 공용 유틸을 만들고 대부분의 호출부를 빠르게 갈아치웠습니다. 자율 실행으로 쭉 밀어붙이는 힘은 여전히 좋았어요. 문제는 덜 뚜렷한 호출부 두 곳(조건부 렌더 안쪽, 그리고 유틸이 아니라 인라인으로 계산하던 배너)을 못 찾고 남겨뒀다는 겁니다. 스냅샷 테스트를 돌리니 그 두 화면만 값이 어긋났어요 — 테스트가 없었다면 배포 후에야 발견했을 종류의 누락입니다.

// 코덱스가 놓친 호출부 (인라인 계산이 그대로 남음)
const krw = usd * rate; // ← convertUSD(usd)로 안 바뀜

맨바닥 작업이나 호출부가 몇 개 안 되는 리팩토링이면 이 속도가 그대로 강점입니다. 하지만 광범위하게 흩어진 리팩토링에서는 "빠르게 대부분"이 오히려 위험해요 — 남은 소수를 사람이 다 찾아야 하는데, 그게 리팩토링에서 제일 품이 드는 일이니까요.

② 커서(Cursor): 앵커는 정확, 대형 스팬에선 후반에 놓침

커서는 관련 파일들을 @멘션으로 앵커로 넘기면 정확하게 교체했습니다. 인라인 diff로 파일별 확인이 편했고요. 그런데 파일이 20개를 넘어가자 세션 후반에 앞쪽 맥락을 놓치는 현상이 나왔어요 — 초반 파일은 공용 유틸로 잘 바꿨는데, 뒤쪽 몇 개는 새 유틸을 안 쓰고 비슷한 걸 또 만들려 했습니다. 컨텍스트 창의 한계로 알려진 그 지점이더군요.

그래서 커서로 대형 리팩토링을 할 땐 "한 번에 다"가 아니라 폴더/도메인 단위로 쪼개서 앵커를 주는 게 답이었습니다. 범위를 좁게 끊으면 정확도가 확 올라가요. 관례를 Rules에 박아두면 "새 유틸 대신 기존 걸 쓰라"는 지시를 매번 반복하지 않아도 됩니다.

③ 클로드코드(Claude Code): 전 호출부를 추적해 가장 안전했다

클로드코드에는 앵커 없이 과제만 던졌는데, 먼저 코드베이스에서 환산 패턴을 전수 검색해 호출부 목록을 뽑고("총 14곳을 찾았다"), 계획을 보여준 뒤 공용 유틸을 만들어 하나씩 교체하며 각 지점을 보고했습니다. 코덱스가 놓친 인라인 배너와 조건부 렌더 안쪽까지 다 잡았고, 마지막에 테스트를 돌려 전 화면 값이 동일함을 확인했어요. 광범위 리팩토링에서 필요한 "빠짐없이"가 셋 중 가장 강했습니다 — 지난 디버깅 편의 "긴 맥락을 끝까지"가 여기서도 이어집니다.

▲ 리팩토링은 '범위'가 도구를 정합니다. 넓게 흩어질수록 전수 추적이 강한 쪽으로.

대가는 역시 토큰입니다 — 전수 검색과 추적에 파일을 많이 읽어 소모가 컸어요(긴 세션은 비용이 붙습니다). 하지만 "하나라도 빠지면 그 화면만 틀리는" 리팩토링에서는 그 비용이 버그를 미리 막는 값으로 정당화됐습니다.

항목별 비교

항목	코덱스(Codex)	커서(Cursor)	클로드코드(Claude Code)
속도	가장 빠름	빠름	전수 검색이라 느림
호출부 누락	2곳 누락	대형 스팬서 후반 누락	누락 없음
범위 대응	좁은 범위에 적합	쪼개서 앵커 주면 정확	광범위에 강함
사람 개입	누락분 직접 탐색	범위 분할·앵커 지정	거의 없이 진행
비용·체감	빠름·자율성↑	IDE diff 리뷰	토큰 많이 씀·터미널
이대로 머지?	❌ (누락 있음)	⭕ (범위 쪼개면)	⭕ (검수 후)

상황별 추천

호출부가 넓게 흩어진 광범위 리팩토링: 클로드코드의 전수 추적이 값을 합니다 — "빠짐없이"가 생명인 작업에 가장 안전합니다. 범위가 좁거나 특정 폴더로 한정되는 리팩토링: 커서에 그 파일들을 앵커로 주면 가장 쾌적합니다(넓으면 도메인 단위로 쪼개세요). 빠르게 초안 리팩토링을 뽑고 싶을 때: 코덱스가 빠르되, 흩어진 호출부 누락을 잡을 테스트가 반드시 함께 있어야 합니다. 저는 광범위 정리는 클로드코드에 맡기고, 좁은 범위는 커서 앵커로 처리하는 식으로 나눠 씁니다. 단일 도구 관점의 Cursor 레거시 경험은 이 글에 따로 정리해뒀습니다.

정작 제일 크게 배운 것

리팩토링에서 도구를 가른 건 "코드를 얼마나 잘 바꾸느냐"가 아니라 "바꿔야 할 곳을 다 찾느냐"였습니다. 그리고 그걸 보증해준 건 도구가 아니라 내가 미리 짜둔 스냅샷 테스트였어요 — 테스트가 없었다면 코덱스의 누락 두 곳은 조용히 배포됐을 겁니다. 결국 AI가 광범위 수정을 빠르게 해줄수록, "바뀐 결과가 예전과 같은지 자동으로 확인하는 안전망"이 리팩토링의 진짜 핵심이라는 걸 이 작업이 다시 확인시켜 줬습니다. 이걸로 리뷰 3부작(고치기·만들기·리팩토링)에서 매번 같은 결론에 도달했네요 — 빨라질수록 검수가 실력이다.

자주 묻는 질문 (FAQ)

Q. 광범위 리팩토링엔 어떤 도구가 제일 낫나요?

A. 호출부가 넓게 흩어졌다면 클로드코드의 전수 추적이 가장 안전합니다. 범위가 좁거나 특정 폴더로 한정되면 커서에 앵커를 주는 게 더 쾌적하고, 코덱스는 빠르되 누락을 잡을 테스트가 전제입니다.

Q. AI가 한 리팩토링을 그냥 믿고 머지해도 되나요?

A. 특히 안 됩니다. 이번에도 한 도구가 흩어진 호출부 두 곳을 놓쳐, 그대로 합쳤다면 그 화면만 옛 로직으로 남을 뻔했습니다. 리팩토링 전후 결과가 동일한지 확인하는 테스트를 반드시 돌리고 머지하세요.

Q. 커서가 대형 리팩토링에서 뒤로 갈수록 놓치는데요?

A. 컨텍스트 창 한계 때문입니다. 한 번에 전체를 시키지 말고 폴더·도메인 단위로 쪼개 앵커를 주면 정확도가 크게 올라갑니다.

Q. 세 개를 다 결제해야 하나요?

A. 아니요. 하나로 시작해 부족할 때 하나를 더합니다. 무료·체험으로 자기 코드에 같은 리팩토링을 시켜보고 정하는 게 가장 정확합니다.

한눈에 보는 요약

같은 광범위 리팩토링을 세 도구에 시켰더니 — 코덱스는 빨랐지만 흩어진 호출부 두 곳을 놓쳤고, 커서는 앵커를 주면 정확했지만 파일이 많아지자 후반에 놓쳤고, 클로드코드는 전수 추적으로 다 잡았습니다. 넓게 흩어지면 클로드코드, 좁으면 커서(앵커), 빠른 시도는 코덱스+테스트. 그리고 무엇을 쓰든 "결과가 예전과 같은지" 검증하는 안전망이 리팩토링의 핵심입니다.

참고 자료

Claude Code 공식 문서
OpenAI Codex 소개
Cursor 공식 사이트

같은 기능, 커서·클로드코드·코덱스에 다 만들게 시켰다: 스캐폴딩 실전 비교 (2026)

DevPilot — Thu, 10 Sep 2026 01:07:01 +0900

핵심 요약: 지난번 버그 수정 편에 이어, 이번엔 "새 기능 만들기"를 세 도구에 똑같이 시켜봤습니다. 제 서비스(AI 비용 계산기)에 새 계산기 페이지 하나를 통째로 스캐폴딩하는 과제를 커서(Cursor)·클로드코드(Claude Code)·코덱스(Codex)에 동일 투입했어요. 결과: 코덱스는 빈 캔버스에서 파일·의존성·기본 테스트까지 제일 빨리 뽑았지만 우리 프로젝트의 기존 컨벤션을 겉돌았고, 커서는 기존 계산기 파일을 @멘션으로 앵커 주자 스타일이 딱 맞게 나왔으며, 클로드코드는 힌트 없이도 계획을 먼저 보여주고 기존 구조를 스스로 파악해 맞췄습니다. 한 줄 결론: 맨바닥 신규는 코덱스, 기존 프로젝트에 얹기는 커서(앵커)나 클로드코드. 그리고 셋 다 컨벤션 검수는 사람 몫이었습니다.

이 글에서 다루는 내용: 어떤 스캐폴딩 과제였나, 공정 비교 규칙, 세 도구의 실제 결과물, 항목별 비교표, 상황별 추천, 배운 것.

먼저, 어떤 과제였나

제 계산기 사이트에는 이미 "AI 비용 계산기"가 있고, 여기에 변형 페이지 하나(이미지 생성 비용 계산기)를 새로 추가하는 게 과제였습니다. 손이 가는 파일이 여럿이라 스캐폴딩 비교에 딱 맞아요 — 새 라우트, 입력 폼 컴포넌트, 모델별 단가 데이터 모듈, 결과 카드, 내비게이션 링크까지. 기존 계산기가 이미 그 다섯 조각을 갖고 있으니, "얼마나 우리 패턴에 맞게 새 걸 얹느냐"가 진짜 관전 포인트였습니다.

▲ 같은 "새 기능 만들기", 세 갈래 접근. 빠르게 찍어내느냐, 기존 걸 참조해 맞추느냐, 스스로 구조를 읽어 맞추느냐.

공정하게 비교하려고 정한 규칙

세 가지를 고정했습니다. ① 같은 시작점 — 셋 다 같은 커밋에서 출발. ② 같은 프롬프트 — "기존 AI 비용 계산기와 같은 구조로, 이미지 생성 비용 계산기 페이지를 새로 추가해줘. 라우트·폼·단가 데이터·결과 카드·내비 링크까지"만 주고, 추가 힌트는 안 줌. ③ 같은 잣대 — 얼마나 빨리 도는가, 기존 컨벤션(파일 위치·네이밍·스타일)을 얼마나 따르는가, 사람이 손볼 게 얼마나 남는가, "이대로 머지해도 되나". 벤치마크 점수는 참고만 하고 판단은 제 실제 코드베이스에서 어떻게 굴렀는지로 했습니다.

① 코덱스(Codex): 빈 캔버스에서 제일 빠르다

코덱스의 강점이 스캐폴딩에서 그대로 나왔습니다 — 다섯 조각을 한 번에 만들고, 필요한 의존성을 설치하고, 기본 렌더 테스트까지 붙여 돌아왔어요. 사람이 중간에 끼어들 일이 거의 없이 끝까지 밀어붙이는 자율성은 확실히 편했습니다. 문제는 "우리 프로젝트답지 않다"였어요 — 단가 데이터를 기존 모듈에 합치는 대신 새 형식으로 따로 만들었고, 결과 카드도 기존 컴포넌트를 재사용하지 않고 비슷한 걸 새로 그렸습니다.

// 코덱스: 기존 pricing.ts를 두고 새 파일을 만듦
// image-pricing.ts  (기존 pricing.ts와 형식이 미묘하게 다름)
export const IMAGE_PRICES = { "model-a": 0.04, ... };

맨바닥에서 새 프로젝트를 찍는 상황이라면 이 속도가 그대로 강점입니다. 하지만 이미 패턴이 있는 코드베이스에 얹을 때는, 빨리 나온 결과물을 우리 컨벤션에 맞추는 뒷작업이 생겨 시간 이득이 절반쯤 상쇄됐습니다.

② 커서(Cursor): 앵커를 주면 결이 딱 맞는다

커서는 IDE 안에서 기존 계산기 파일들을 @멘션으로 앵커로 넘길 수 있는 게 결정적이었습니다. "@ai-cost/ 이 폴더 구조와 같은 방식으로 image 버전을 만들어줘"라고 하니, 기존 pricing 모듈에 항목을 추가하고 결과 카드도 같은 컴포넌트를 재사용해서, 스타일이 처음부터 맞게 나왔어요. 멀티파일 수정은 Composer/Agent(그 정리)로 묶여 인라인 diff로 리뷰가 편했고요.

// 커서: 앵커(@pricing.ts) 덕에 기존 모듈에 얹음
// pricing.ts 에 항목 추가 (형식 그대로)
export const PRICES = { ...text, image: { "model-a": 0.04 } };

정리하면 커서는 "참고할 기존 코드를 내가 짚어줄 수 있을 때" 가장 강했습니다. 반대로 앵커 없이 던지면 코덱스처럼 새 파일을 만드는 경향이 있어, 앵커를 주는 한 줄이 결과 품질을 갈랐습니다. 관례를 아예 규칙으로 박아두면(Rules) 앵커 없이도 편차가 줄어듭니다.

③ 클로드코드(Claude Code): 힌트 없이 구조를 읽어 맞춘다

클로드코드에는 앵커 없이 과제 문장만 던졌는데, 먼저 계획을 보여주고("기존 pricing 모듈을 확장하고, CalculatorCard를 재사용하겠다") 나서 여러 파일을 훑어 우리 구조를 스스로 파악한 뒤 그에 맞춰 만들었습니다. 새 파일을 남발하지 않고 기존 걸 확장하는 판단이 셋 중 가장 정확했어요. 터미널에서 테스트까지 돌려 마무리했고요 — 지난 디버깅 편에서 본 "맥락을 끝까지 붙잡는" 강점이 스캐폴딩에서도 나왔습니다.

▲ 신규냐 기존이냐 — 이 한 갈래가 스캐폴딩 도구 선택의 대부분을 결정합니다.

대가는 역시 토큰이었습니다. 구조를 파악하느라 파일을 많이 읽어 소모가 컸고(긴 세션은 비용이 붙습니다), 터미널 전용이라 시각적 diff가 익숙한 분은 초반이 낯설 수 있어요. 그래도 "기존 프로젝트에 자연스럽게 얹기"에서는 앵커를 안 줘도 되는 유일한 도구였습니다.

항목별 비교

항목	코덱스(Codex)	커서(Cursor)	클로드코드(Claude Code)
속도(맨바닥)	가장 빠름	빠름	계획 먼저라 약간 느림
기존 컨벤션 준수	약함(새 파일 남발)	앵커 주면 정확	자력 파악, 정확
기존 코드 재사용	덜 함	앵커로 재사용	스스로 재사용 판단
사람 개입	컨벤션 정리 필요	앵커 한 번 지정	거의 없이 진행
비용·체감	빠름·자율성↑	IDE 손맛·diff 리뷰	토큰 많이 씀·터미널
이대로 머지?	△ (컨벤션 손질 후)	⭕ (검수 후)	⭕ (검수 후)

상황별 추천

맨바닥에서 새 프로젝트·프로토타입을 찍을 때: 코덱스가 빠릅니다 — 참고할 기존 패턴이 없으니 "새 파일 남발"이 단점이 아니라 그냥 속도가 됩니다. 이미 패턴이 있는 코드베이스에 기능을 얹을 때: 커서(앵커 지정)나 클로드코드(자력 파악)가 뒷작업을 줄여줍니다. IDE에서 diff를 눈으로 확인하며 가고 싶으면 커서, 앵커 지정도 귀찮고 알아서 맞춰주길 원하면 클로드코드. 저는 요즘 기존 서비스 작업은 커서에 앵커를 주고 가다가, 구조가 복잡해 앵커를 특정하기 애매하면 클로드코드에 통째로 넘기는 식으로 씁니다.

정작 제일 크게 배운 것

스캐폴딩은 셋 다 "만들기" 자체는 잘합니다 — 갈리는 건 "우리 프로젝트답게" 만드느냐였어요. 그리고 그건 도구의 지능보다 내가 맥락(앵커·규칙·기존 구조)을 얼마나 쥐여주느냐에 달려 있었습니다. 코덱스가 겉돈 것도 도구가 나빠서가 아니라 맥락을 안 줬기 때문이고, 규칙 파일 하나만 있었어도 결과가 달랐을 겁니다. 결국 빨리 만들어주는 시대일수록 "무엇을 우리 관례로 정해 두느냐"가 결과를 가른다는 걸, 이 작은 페이지 하나가 다시 확인시켜 줬습니다.

자주 묻는 질문 (FAQ)

Q. 새 기능 스캐폴딩엔 어떤 도구가 제일 낫나요?

A. 맨바닥 신규는 코덱스의 속도, 기존 프로젝트에 얹기는 커서(앵커 지정)나 클로드코드(자력 파악)가 낫습니다. "우리 코드에 자연스럽게 붙느냐"가 기준이면 클로드코드를 기본으로 두되, 참고 파일을 짚어줄 수 있으면 커서가 가장 쾌적합니다.

Q. AI가 만든 새 기능을 그냥 믿고 머지해도 되나요?

A. 권하지 않습니다. 이번에도 한 도구는 기존 모듈을 두고 새 파일을 만들어, 그대로 합쳤다면 단가 데이터가 두 곳으로 갈라질 뻔했습니다. 최소한 "기존 걸 재사용했는지, 컨벤션에 맞는지"를 확인하고 머지하세요.

Q. 결과를 우리 스타일에 맞추는 제일 쉬운 방법은요?

A. 참고할 기존 파일을 앵커로 주거나(커서 @멘션), 관례를 규칙 파일(Cursor Rules·CLAUDE.md)에 박아두는 것입니다. 맥락을 미리 쥐여줄수록 뒷작업이 줄어듭니다.

Q. 셋을 다 결제해야 하나요?

A. 아니요. 하나로 시작해 부족할 때 하나를 더합니다. 무료·체험으로 자기 프로젝트에 같은 스캐폴딩을 시켜보고 정하는 게 가장 정확합니다.

한눈에 보는 요약

같은 새 기능을 세 도구에 만들게 했더니 — 코덱스는 빈 캔버스에서 제일 빨랐지만 컨벤션을 겉돌았고, 커서는 앵커를 주면 결이 맞았고, 클로드코드는 힌트 없이 구조를 읽어 맞췄습니다. 맨바닥은 코덱스, 기존에 얹기는 커서·클로드코드. 그리고 무엇을 쓰든 "우리 관례로 만들었는지" 검수는 사람 몫입니다.

참고 자료

Claude Code 공식 문서
OpenAI Codex 소개
Cursor 공식 사이트

같은 버그, 커서·클로드코드·코덱스에 다 시켜봤다: 디버깅 실전 비교 (2026)

DevPilot — Tue, 8 Sep 2026 22:23:08 +0900

핵심 요약: 제 서비스(AI 비용 계산기)에 실제로 있던 간헐적 버그 하나를 커서(Cursor)·클로드코드(Claude Code)·코덱스(Codex)에 똑같은 문장으로 던져봤습니다. 결과가 셋 다 달랐어요 — 코덱스는 증상 재현 테스트를 제일 빨리 짰지만 근본 원인은 못 짚고 표시 로직에 방어코드만 붙였고, 커서는 제가 "이 파일이 의심된다"고 짚어주자 인라인으로 정확히 고쳤고(안 짚어주면 헤맴), 클로드코드만 힌트 없이 여러 파일을 훑어 진짜 원인(비동기 핸들러의 stale closure)까지 거슬러 올라갔습니다. 한 줄 결론: 원인이 뻔한 버그는 코덱스, 원인 모를 버그는 클로드코드, 위치를 아는 상태에서 손보긴 커서. 그리고 셋 다 사람 검수 없이 그대로 머지했으면 위험했습니다.

이 글에서 다루는 내용: 어떤 버그였나, 공정 비교를 위한 규칙, 세 도구의 실제 반응, 항목별 비교표, 상황별 추천, 그리고 제가 배운 것.

먼저, 어떤 버그였나

제가 운영하는 AI 비용 계산기에 모델을 빠르게 연속으로 바꾸면 합계가 가끔 "직전 모델" 가격으로 표시되는 버그가 있었습니다. 천천히 바꾸면 멀쩡하고, 급하게 클릭할 때만 재현되는 전형적인 간헐적(비결정적) 버그였죠. 증상이 보이는 곳은 화면의 합계 표시였지만, 실제 원인은 거기서 한참 떨어진 비동기 가격 조회 핸들러에 있었습니다 — 단가를 받아온 뒤 합계를 세팅할 때, 최신 선택이 아니라 요청을 건 시점의 모델을 클로저로 붙잡고 있었던 겁니다(이른바 stale closure).

▲ "증상이 보이는 곳 ≠ 원인이 있는 곳" — 디버깅 도구를 가르는 건 이 거리를 얼마나 거슬러 올라가느냐입니다.

공정하게 비교하려고 정한 규칙

후기가 후기다우려면 조건이 같아야 해서, 세 가지를 고정했습니다. ① 같은 시작점 — 셋 다 버그가 있는 동일 커밋에서 출발. ② 같은 프롬프트 — "모델을 빠르게 바꾸면 합계가 가끔 직전 모델 가격으로 나온다. 원인을 찾아 고쳐줘"만 주고, 원인 힌트는 안 줌. ③ 같은 잣대 — 원인 추적 깊이, 헛발질, 사람이 끼어들어야 했던 횟수, 그리고 "이대로 머지해도 되나"를 봤습니다. 벤치마크 점수(SWE-bench·Terminal-bench 같은 것)는 참고만 하고, 판단은 제 코드에서 실제로 어떻게 굴었는지로 했어요.

① 코덱스(Codex): 제일 빨랐지만, 증상만 덮었다

코덱스는 혼자 끝까지 밀어붙이는 힘이 확실했습니다. 재현이 어렵다고 멈추지 않고, 스스로 연속 클릭을 흉내 내는 테스트를 짜서 버그를 결정적으로 만든 뒤 달려들더군요. 문제는 결론이었습니다 — 합계 표시 부분에 "값이 이상하면 다시 계산" 같은 방어코드를 넣어 증상은 줄였지만, 정작 stale closure는 손대지 않았어요.

// 코덱스가 넣은 방향 (증상 완화)
if (total !== recompute(selectedModel, tokens)) {
  total = recompute(selectedModel, tokens); // 표시 직전 재계산으로 덮기
}

빠르고, 테스트까지 붙여주는 건 좋았습니다. 하지만 이건 "왜 틀렸나"가 아니라 "틀리면 고쳐 보이게" 한 거라, 다른 화면에서 같은 원인이 또 터질 여지가 남습니다. 원인이 분명한 버그였다면 코덱스의 속도가 그대로 강점이 됐을 텐데, 이번처럼 원인이 숨은 케이스에선 자율성이 오히려 엉뚱한 방향으로 빨리 가는 위험으로 작동했습니다.

② 커서(Cursor): 위치를 짚어주면 가장 깔끔했다

커서는 처음엔 코덱스와 비슷하게 합계 표시 컴포넌트 주변만 맴돌았습니다. 그런데 제가 IDE에서 의심 가는 비동기 핸들러 파일을 열고 "이 근처가 수상하다"고 한마디 보태자, 곧바로 stale closure를 정확히 지목하고 함수형 업데이트로 바꾸는 diff를 인라인으로 보여줬어요. 받아들일지 말지 줄 단위로 고를 수 있어서 검수와 수정이 한 화면에서 끝나는 손맛이 좋았습니다.

// 커서가 제안한 수정 (원인 교정)
const price = await fetchPrice(model);
setTotal(() => compute(model, tokensRef.current)); // 클로저 대신 최신 값 참조

정리하면 커서는 "내가 어디를 볼지 아는" 상태에서 가장 강했습니다. 에디터 왕복이 익숙한 사람에겐 제일 편한 흐름이고요. 반대로 원인 위치를 모르는 채로 던지면 표시 로직 근처를 벗어나지 못했다는 점은 코덱스와 크게 다르지 않았습니다. 커서 자체를 처음 잡는 분은 CLI·기본 사용 정리부터 보면 감이 빠릅니다.

③ 클로드코드(Claude Code): 유일하게 원인까지 거슬러 갔다

클로드코드에는 힌트 없이 증상 문장만 던졌는데, 여러 파일을 순서대로 훑으며 상태가 어디서 세팅되는지 추적하더니 표시 컴포넌트를 지나 비동기 핸들러까지 거슬러 올라가 "여기서 오래된 model 값을 캡처한다"고 원인을 콕 집었습니다. 수정도 함수형 업데이트 + 오래된 요청 취소(경쟁 상태 방지)로 하고, 재현 테스트까지 붙여 마무리했어요. 제가 이전에 남긴 보안 실전 후기에서 느낀 "긴 맥락을 끝까지 붙잡는" 강점이 디버깅에서도 그대로 나왔습니다.

▲ 같은 버그, 세 갈래 접근. 증상을 덮느냐, 위치를 알려주면 고치느냐, 원인까지 거슬러 가느냐.

대신 대가가 있었습니다. 여러 파일을 훑는 만큼 토큰을 많이 썼고(긴 세션은 비용이 붙습니다), 터미널 전용이라 시각적 diff에 익숙한 분은 초반 진입이 낯설 수 있어요. 그래도 "원인을 모르겠는 버그"에서만큼은 셋 중 유일하게 제 손을 덜어준 도구였습니다.

항목별 비교

항목	코덱스(Codex)	커서(Cursor)	클로드코드(Claude Code)
첫 접근	증상 재현 테스트 자동 작성	표시 로직 주변 탐색	파일 훑으며 상태 흐름 추적
원인 추적 깊이	얕음 (증상에 머묾)	힌트 주면 정확	깊음 (원인까지)
수정 성격	방어코드(증상 완화)	원인 교정(인라인 diff)	원인 교정 + 경쟁상태 방지
사람 개입	방향 교정 필요	위치 한 번 짚어주면 됨	거의 없이 진행
비용·체감	빠름, 자율성 높음	왕복 편함, IDE 손맛	토큰 많이 씀, 터미널
이대로 머지?	❌ (원인 남음)	⭕ (검수 후)	⭕ (검수 후)

상황별 추천

원인이 분명한 버그(같은 입력에 항상 같은 오류, 스택 트레이스가 원인을 가리킴): 코덱스가 빠릅니다 — 테스트 짜고 고치는 루프가 짧아요. 원인을 모르겠는 버그(간헐적, 여러 파일에 걸침): 클로드코드의 추적 깊이가 값을 합니다. 이미 의심 위치를 아는 상태에서 손보는 일: 커서의 인라인 수정이 제일 쾌적합니다. 실제로 저는 요즘 커서를 열어두고, 원인이 안 잡히면 클로드코드에 넘기는 식으로 둘을 같이 씁니다 — 많은 개발자가 "에디터엔 커서, 터미널엔 클로드코드"를 동시에 켜두는 이유가 이겁니다.

정작 제일 크게 배운 것

세 도구 다 그대로 머지했으면 안 됐다는 점입니다. 코덱스 버전은 증상을 덮어 버그를 더 찾기 어렵게 만들 뻔했고, 커서·클로드코드의 수정도 제가 테스트를 돌려 확인한 뒤에야 안심이 됐어요. AI가 코드를 빨리 짜줄수록 "누가 언제 검수하느냐"가 실제 품질을 가른다는, 흔하지만 자꾸 잊는 교훈을 이 작은 버그가 다시 확인시켜 줬습니다. 비슷한 결의 실패·수습 기록은 UX 버그 수정 후기에도 남겨뒀습니다.

자주 묻는 질문 (FAQ)

Q. 결국 디버깅엔 어떤 도구가 제일 낫나요?

A. 버그 성격에 따라 갈립니다. 원인이 분명하면 코덱스, 원인을 모르겠으면 클로드코드, 위치를 아는 상태에서 손보면 커서가 편했습니다. 하나만 고르라면 "원인 추적"이 디버깅의 본질이라 클로드코드를 기본으로 두되, 재현 쉬운 버그는 코덱스로 빠르게 처리하는 조합을 권합니다.

Q. AI가 고친 버그 수정을 그냥 믿고 머지해도 되나요?

A. 권하지 않습니다. 이번 사례에서 한 도구는 원인이 아니라 증상만 덮었고, 그대로 합쳤다면 다른 화면에서 같은 버그가 다시 터졌을 겁니다. 최소한 재현 테스트를 돌려 원인이 사라졌는지 확인한 뒤 머지하세요.

Q. 세 개를 다 결제해야 하나요?

A. 아니요. 대부분은 하나로 시작해 부족할 때 한 개를 더합니다. 요금 구조와 무료 범위는 도구마다 다르니(예: 클로드코드 정리) 무료·체험으로 자기 버그에 직접 시켜보고 정하는 게 가장 정확합니다.

Q. 간헐적(비결정적) 버그는 AI가 원래 약하지 않나요?

A. 맞습니다. 셋 다 재현이 어려운 상태에선 헤맸고, 그래서 "재현을 결정적으로 만드는 테스트"를 먼저 짜는 도구(코덱스)가 초반에 유리했습니다. 다만 재현 이후 원인까지 가는 건 별개의 능력이라, 거기서 클로드코드가 앞섰습니다.

한눈에 보는 요약

같은 간헐적 버그에 세 도구를 똑같이 물렸더니 — 코덱스는 빠르게 증상만 덮고, 커서는 위치를 알려주면 깔끔히 고치고, 클로드코드는 힌트 없이 원인까지 거슬러 갔습니다. 원인이 뻔하면 코덱스, 모르겠으면 클로드코드, 위치를 알면 커서. 그리고 무엇을 쓰든 사람 검수 없이 머지는 금물입니다.

참고 자료

Claude Code 공식 문서
OpenAI Codex 소개
Cursor 공식 사이트

Copilot 구독료는 그대로인데 9월 청구서가 늘었다? — 포함 크레딧 최대 44% 삭감 정리

DevPilot — Mon, 7 Sep 2026 20:43:41 +0900

핵심 요약: GitHub Copilot이 9월 1일부터 포함 크레딧(included credits)을 대폭 줄였습니다 — Business는 $30→$19(−37%), Enterprise는 $70→$39(−44%). 6~8월 3개월 프로모션이 끝나며 표준값으로 내려온 건데, 구독료(Business $19·Enterprise $39)는 그대로예요. 즉 같은 돈을 내는데 "공짜로 쓸 수 있는 양"만 줄었습니다. 안심 포인트 하나 — 자동완성(인라인·Next Edit)은 크레딧과 무관하게 계속 무제한이라, 자동완성만 쓰는 팀은 영향이 없을 수 있어요. 크레딧을 먹는 건 챗·에이전트·프리미엄 모델입니다. 그리고 개인 Pro($10)·Pro+($39)는 이번 변화 대상이 아니에요. 문제는 에이전트를 많이 쓰는 팀 — 아무도 설정을 안 바꿔도 9월 청구서가 8월보다 커질 수 있습니다. 이 글은 뭐가 바뀌었고, 청구서 전에 뭘 확인해야 하는지 정리합니다.

※ 이 글은 2026년 9월 7일 기준이며, 수치는 GitHub 공식 발표와 이를 검증한 자료를 따랐습니다(하단 링크). 초과 과금 처리 방식은 조직 설정에 따라 다르니 본문의 "확인할 것"을 참고하세요.

지난주 Copilot 모델 6종 폐기를 다뤘는데, 같은 9월 1일에 요금 쪽에서도 조용한 변화가 하나 더 있었습니다. 모델이 사라진 건 눈에 띄지만, 이건 청구서를 받아야 알게 되는 종류라 더 주의가 필요해요.

무슨 일이 있었나: 프로모션이 끝났다

GitHub은 6월 1일부로 Copilot 과금을 "프리미엄 요청" 단위에서 사용량 기반 AI 크레딧으로 바꿨습니다. 그러면서 조직(Business·Enterprise)에 6~8월 석 달간 넉넉한 포함 크레딧을 얹어줬어요. 그 프로모션이 8월 31일에 끝났고, 9월 1일부터 표준값으로 내려온 겁니다.

▲ 구독료 칸은 그대로, "포함" 칸만 내려갔습니다. 그게 이번 변화의 전부이자 핵심.

플랜	구독료/시트	6~8월 포함	9월부터	변화
Business	$19/월	$30 크레딧	$19 크레딧	−37%
Enterprise	$39/월	$70 크레딧	$39 크레딧	−44%
Pro	$10/월	$10	$10	변화 없음
Pro+	$39/월	$39	$39	변화 없음

정리하면 — 구독료는 안 올랐고, 포함된 사용량만 줄었습니다. 개인 Pro·Pro+는 애초에 프로모션 대상이 아니라 이날 바뀐 게 없어요. 영향을 받는 건 조직 플랜(Business·Enterprise)입니다.

먼저 안심할 것: 자동완성은 무제한 그대로

패닉을 멈추는 지점이 여기예요. 코드 자동완성(인라인 제안·Next Edit Suggestions)은 크레딧으로 과금되지 않고, 유료 플랜에서 계속 무제한입니다. 크레딧을 소모하는 건 챗, 에이전트, 프리미엄 모델 같은 "토큰을 많이 쓰는 상호작용"이에요.

그래서 팀이 Copilot을 주로 자동완성으로만 쓴다면, 이번 변화로 드는 추가 비용이 0일 수 있습니다. 반대로 에이전트 모드·프리미엄 모델에 기대는 팀이라면, "정액 청구서"가 "변동 청구서"로 바뀌는 갈림길이에요. 이 차이가 이번 사안의 전부이고, 답은 오직 우리 팀의 사용 데이터에만 있습니다.

청구서 전에 확인할 것 세 가지

▲ 순서대로 셋만. "설정 확인"이 청구서 사고를 막는 핵심입니다.

① 8월 사용량을 읽으세요. 조직의 Copilot 청구 화면에서 시트별 8월 크레딧 소모를 확인합니다. 그 숫자는 $30(Business)·$70(Enterprise) 한도에 맞춰 잰 값이에요. 이걸 $19·$39와 비교하세요 — 어떤 시트가 8월에 $24를 썼다면, 프로모션 안에선 여유였지만 9월엔 표준 한도를 넘습니다.

② 지출 정책(spend policy)을 확인하세요. GitHub은 조직이 "추가 사용을 표준 요율로 허용할지, 지출을 상한으로 막을지 선택할 수 있다"고 안내합니다. 이 관리자 설정이 한도 도달 시 초과 청구가 날지, 에이전트 기능이 멈출지를 가릅니다. 둘 중 뭐가 맞다는 게 아니라, 모르고 맞으면 둘 다 나쁩니다 — 의도적으로 정하고 팀에 알리세요.

참고로 이 초과 과금이 "기본적으로 켜져 있다(opt-out)"고 쓴 글이 많은데, GitHub 공식 페이지에서 그 표현은 확인되지 않습니다. 그래서 이 글도 단정하지 않아요 — 남의 설명(제 것 포함)을 믿지 말고 본인 조직의 관리자 설정을 직접 확인하는 게 정답입니다.

③ 그다음에 플랜을 재검토하세요. 상당수 시트가 매월 표준 한도를 넘길 것 같으면, 비교 기준은 스티커 가격이 아니라 초과분까지 포함한 시트당 실비용입니다. Copilot이 여전히 쌀 수도, 아닐 수도 있어요 — 감이 아니라 계산으로 정하세요. 작업 성격에 맞춰 모델·도구를 나누는 접근이 여기서도 유효합니다(에이전트 작업이 소수 인원에 몰린다면, 전원 상향보다 그들만 강한 도구를 붙이는 편이 쌀 수 있어요).

이 흐름의 의미

지난주부터 Copilot 쪽 축소가 둘 연속입니다 — 9/1 모델 폐기, 그리고 이 크레딧 삭감. 요금표의 숫자는 안 바뀌었지만 "같은 돈에 포함되는 양"이 줄었죠. 이건 지난 주말 글(매주 바뀌는 시대의 생존법)에서 말한 그대로예요 — 공급자는 가격표를 안 건드리고도 조건을 바꿀 수 있습니다. 그러니 "구독료가 그대로니 괜찮겠지"가 아니라, 포함량·초과 정책 같은 세부를 주기적으로 들여다보는 습관이 결국 지갑을 지킵니다.

자주 묻는 질문 (FAQ)

Q. 구독료가 오른 건가요?

A. 아니요. Business $19·Enterprise $39의 구독료는 그대로입니다. 바뀐 것은 그 안에 "포함된" 크레딧(사용량)으로, Business $30→$19, Enterprise $70→$39로 줄었습니다.

Q. 저는 개인 Pro인데 영향이 있나요?

A. 없습니다. 개인 Pro($10)와 Pro+($39)는 이번 프로모션 대상이 아니었고 9월 1일에 바뀐 것이 없습니다. 이번 변화는 조직 플랜(Business·Enterprise)에 해당합니다.

Q. 그럼 자동완성도 크레딧을 쓰나요?

A. 아니요. 인라인 자동완성과 Next Edit Suggestions는 크레딧으로 과금되지 않고 유료 플랜에서 무제한입니다. 크레딧은 챗·에이전트·프리미엄 모델 같은 토큰 소모형 상호작용에 쓰입니다.

Q. 한도를 넘기면 자동으로 초과 청구되나요?

A. 조직의 지출 정책 설정에 달렸습니다. 추가 사용을 허용하면 초과 청구가, 상한으로 막으면 기능이 멈춥니다. 초과가 기본으로 켜져 있는지는 출처마다 설명이 엇갈리므로, 본인 조직의 관리자 설정을 직접 확인하는 것이 안전합니다.

정리하면

9/1 Copilot 포함 크레딧 = Business −37%($30→$19), Enterprise −44%($70→$39), 구독료·개인 Pro/Pro+는 불변. 자동완성은 무제한 유지, 챗·에이전트·프리미엄만 크레딧 소모. 할 일은 셋 — 8월 사용량 읽고, 지출 정책 확인하고, 넘칠 것 같으면 실비용으로 플랜 재검토. 저는 이번에도 같은 걸 느꼈어요 — 요금 뉴스에서 제일 위험한 건 "가격 인상"이 아니라, 가격은 그대로인데 조용히 줄어든 포함량입니다. 청구서를 받기 전에 설정부터 열어보세요.

참고 자료

Copilot 사용량 기반 과금 전환 (GitHub Blog)
크레딧·사용량 공식 문서 (GitHub Docs)

Cursor CLI 명령어·실전 예제 총정리: 설치부터 CI 자동화 스크립트까지 (2026)

DevPilot — Sun, 6 Sep 2026 17:50:23 +0900

핵심 요약: Cursor CLI는 터미널에서 agent 한 단어로 Cursor 에이전트를 쓰는 도구입니다. 이 글은 명령어·플래그 레퍼런스와 복붙용 실전 예제를 한곳에 모은 쿡북이에요("이게 뭔가"는 개요 글에서 다뤘습니다). 외울 건 많지 않습니다 — 대화형은 agent, 스크립트·CI는 agent -p(프린트 모드), 파일을 실제로 고치려면 --force, 모드는 --mode=plan/ask, 이전 대화는 agent resume. 여기에 헤드리스 모드로 배치 리팩터링·자동 코드 리뷰·이미지 분석을 돌리는 실제 스크립트 예제를 붙였습니다. 명령어는 모두 공식 문서 기준으로 확인했고(하단 링크), 바로 복사해 쓸 수 있게 정리했어요.

※ 이 글은 2026년 9월 6일 기준 공식 문서(cursor.com/docs/cli)를 확인해 정리한 실전 가이드입니다. 플래그는 버전에 따라 바뀔 수 있으니 자동화에 넣기 전 agent --help로 한 번 확인하세요.

개요 글에서 "Cursor CLI가 뭐고 왜 쓰나"를 다뤘으니, 여기서는 곧장 손에 익는 것부터 갑니다 — 설치하고, 명령어를 훑고, 실제 스크립트로 돌리는 순서로요.

설치: 명령어 한 줄

운영체제별로 한 줄이면 끝납니다. 설치되는 실행 파일 이름은 이제 agent예요(예전 이름 cursor-agent도 별칭으로 아직 동작합니다).

# macOS · Linux · WSL
curl https://cursor.com/install -fsS | bash

# Windows (PowerShell)
irm 'https://cursor.com/install?win32=true' | iex

# 설치 후 대화형 세션 시작
agent

명령어 한눈에 (치트시트)

▲ 이 카드 한 장이면 대부분 커버됩니다. 아래는 상황별 설명.

목적	명령어
대화형 세션 시작	`agent`
초기 프롬프트와 함께 시작	`agent "인증 모듈을 JWT로 리팩터"`
계획 모드(코딩 전 설계)	`agent --mode=plan` 또는 `/plan`, `Shift+Tab`
읽기 전용 탐색(수정 안 함)	`agent --mode=ask` 또는 `/ask`
비대화형(스크립트·CI)	`agent -p "질문"`
파일을 실제로 수정	`agent -p --force "..."`
모델 지정	`agent -p "..." --model "gpt-5"`
출력 형식	`--output-format text\|json\|stream-json`
이전 대화 목록·재개	`agent ls` · `agent resume` · `agent --continue`
클라우드로 위임	메시지 앞에 `&` — `& 테스트까지 추가해줘`
샌드박스 토글	`/sandbox` 또는 `--sandbox enabled\|disabled`

대화형 기본: 모드 세 가지

그냥 agent를 치면 대화형 세션이 열립니다. 목표를 말하면 변경안을 제안하고, 명령 실행은 승인받아 진행해요. 에디터와 같은 모드·같은 Rules·같은 MCP 설정을 공유하는 게 핵심입니다 — 그래서 에디터에서 쓰던 감각 그대로 터미널에서 쓸 수 있어요.

모드는 셋입니다. Agent(기본)는 모든 도구를 써서 실제 작업을 하고, Plan은 코딩 전에 접근 방식을 설계하며 필요하면 되묻고, Ask는 읽기 전용이라 코드를 건드리지 않고 탐색만 합니다. "일단 구조부터 파악하고 싶다"면 Ask, "큰 변경 전에 계획부터"면 Plan으로 시작하는 습관이 사고를 줄여줍니다.

세션 관리: 맥락 이어가기

긴 작업은 세션을 이어가는 게 편합니다. 이전 대화를 다시 불러와 맥락을 유지할 수 있어요.

# 이전 대화 목록에서 골라 재개
agent ls

# 가장 최근 대화 재개
agent resume

# 직전 세션 이어서
agent --continue

# 특정 대화 ID로 재개
agent --resume="chat-id-here"

헤드리스·CI: `-p`가 핵심

▲ "사람이 볼 거냐, 스크립트가 돌 거냐"로 갈리고, 파일을 실제로 고칠 때만 --force.

자동화의 출발점은 프린트 모드(-p 또는 --print)입니다. 결과만 stdout으로 깔끔히 뱉어서 다른 도구로 파이프하기 좋아요. 중요한 안전장치 하나 — 기본은 변경을 "제안만" 하고 파일을 안 고칩니다. 실제로 수정하게 하려면 --force(또는 --yolo)를 붙여야 해요. CI에서는 인증을 위해 CURSOR_API_KEY 환경변수를 먼저 설정합니다.

# 질문만 — 파일 안 고침(기본)
agent -p "이 코드베이스는 무슨 일을 하나?"

# 실제로 파일 수정 — --force 필요
agent -p --force "src의 코드를 최신 ES6+ 문법으로 리팩터"

# 스크립트용: API 키 설정 후 실행
export CURSOR_API_KEY=your_api_key_here
agent -p "이 변경의 보안 이슈를 리뷰해줘" --output-format text

실전 예제 모음 (복붙용)

여기가 이 글의 본론입니다. 자주 쓰는 패턴 넷을 실제 스크립트로 정리했어요.

① 배치 리팩터링 — 파일마다 순회
여러 파일에 같은 작업을 돌릴 때. --force가 있어야 실제로 반영됩니다.

# src의 모든 .js에 JSDoc 주석 추가
find src/ -name "*.js" | while read file; do
  agent -p --force "이 파일에 JSDoc 주석을 꼼꼼히 추가: $file"
done

② 자동 코드 리뷰 — 성공/실패 처리까지
CI 파이프라인에 넣기 좋은 형태. 종료 코드로 성공 여부를 판정합니다.

#!/bin/bash
# code-review.sh — 최근 변경 자동 리뷰
agent -p --force --output-format text \
  "최근 변경을 리뷰하고 코드 품질·잠재 버그·보안·베스트프랙티스 관점의
   구체적 개선안을 review.txt에 정리해줘"

if [ $? -eq 0 ]; then
  echo "✅ 코드 리뷰 완료"
else
  echo "❌ 리뷰 실패"; exit 1
fi

③ JSON 출력 → jq로 파싱
구조화된 결과가 필요할 때. 다른 도구와 연결하기 좋습니다.

# 결과를 JSON으로 받아 특정 필드만 추출
agent -p --output-format json "이 프로젝트 구조를 요약해줘" | jq -r '.result'

④ 이미지·목업 분석
프롬프트에 파일 경로를 적으면 에이전트가 알아서 읽습니다 — 스크린샷·디자인 목업도요.

# 스크린샷 분석
agent -p "이 이미지를 분석해서 무엇이 보이는지 설명: ./screenshot.png"

# 코드와 디자인 목업을 함께 주고 개선안 요청
agent -p "src/app.ts의 코드와 designs/home.png 목업을 보고,
          디자인에 맞게 개선안을 제안해줘"

클라우드로 넘기기: `&` 한 글자

오래 걸리는 작업은 자리를 비워도 계속 돌게 클라우드 에이전트로 넘길 수 있어요. 대화 중 메시지 앞에 &만 붙이면 됩니다. 넘긴 작업은 웹·모바일(cursor.com/agents)에서 이어봅니다 — 노트북을 닫아도 진행되는 구조예요.

# 대화 도중 이 작업을 클라우드로 위임
& 인증 모듈을 리팩터하고 테스트도 꼼꼼히 추가해줘

안전장치: `--force`는 신중히

편의만큼 주의도 필요합니다. --force는 확인 없이 파일을 바꿉니다 — 커밋되지 않은 작업이 있는 저장소에서 헤드리스로 돌리면 되돌리기 번거로워요. 습관 둘을 권합니다: 깨끗한 브랜치에서 돌리고, 명령 실행 격리가 필요하면 --sandbox enabled로 샌드박스를 켜세요(네트워크 접근까지 제어, 설정은 세션 간 유지). 참고로 sudo가 필요한 명령은 마스킹된 프롬프트로 비밀번호를 받고 모델에는 전달되지 않습니다.

자주 묻는 질문 (FAQ)

Q. 명령어가 `agent`인가요 `cursor-agent`인가요?

A. 현재 설치되는 실행 파일은 agent입니다. 예전 이름 cursor-agent도 별칭으로 아직 동작하지만, 새 스크립트는 agent로 쓰는 것이 좋습니다.

Q. `-p`로 돌렸는데 파일이 안 바뀌어요.

A. 정상입니다. 프린트 모드는 기본적으로 변경을 제안만 하고 적용하지 않습니다. 실제로 파일을 수정하려면 --force(또는 --yolo)를 함께 붙이세요.

Q. CI에서 인증은 어떻게 하나요?

A. CURSOR_API_KEY 환경변수에 API 키를 넣고 실행하면 됩니다. 키는 저장소에 하드코딩하지 말고 CI의 시크릿(secret)으로 주입하세요.

Q. Claude Code와 뭐가 다른가요?

A. 둘 다 터미널 에이전트지만, Cursor CLI는 Cursor 구독으로 쓰고 에디터와 설정을 공유한다는 점이 다릅니다. 이미 Cursor Pro라면 추가 비용 없이 쓸 수 있습니다. 자세한 위치 관계는 개요 글에 정리했습니다.

정리하면

Cursor CLI는 agent로 시작해서, 스크립트엔 -p, 실제 수정엔 --force, 모드는 --mode, 이어가기는 resume — 이 다섯 개가 뼈대입니다. 나머지는 위 예제를 상황에 맞게 변주하면 돼요. 저는 이걸 정리하면서 다시 느꼈는데, CLI의 진짜 값은 "터미널에서도 된다"가 아니라 "스크립트·CI에 에이전트를 끼워 넣을 수 있다"는 데 있습니다. 반복 작업 하나를 -p --force 스크립트로 옮겨보는 것부터 시작해보세요.

참고 자료

Cursor CLI 공식 문서 (Overview)
Headless / CI 공식 문서

이번 주 진짜 주인공은 제일 싼 모델? — Gemini 3.8 Flash 정리

DevPilot — Sun, 6 Sep 2026 17:05:41 +0900

핵심 요약: 이번 주 프런티어 모델이 셋 나왔습니다 — Fable 5.1($10/$50), GPT-6 Astra($10/$50, Sol의 2.5배), 그리고 9월 2일 Google Gemini 3.8 Flash. 그런데 정작 주목할 건 제일 조용히 나온 세 번째일지도 몰라요. 가격이 입력 100만 토큰 $0.75, 출력 $3.75 — 플래그십들의 약 13분의 1인데, 구글은 "역대 최고 추론·코딩 모델"이라며 DeepSWE 같은 코딩 벤치에서 더 큰 모델들을 제치고 Opus 5도 일부 항목에서 이겼다고 합니다. 그럼 다 이걸 쓰면 될까요? 함정이 셋 있습니다 — ① Flash(경량) 티어라 아주 어려운 장기 작업은 여전히 약하고, ② "더 열심히 일하는" 설계라 토큰을 더 써서 싼 단가가 상쇄될 수 있고, ③ 이 가격은 도입가라 2027년 1월 1일에 2배가 됩니다. 이 글은 그 가성비의 실체와 조건을 정리합니다.

※ 이 글은 2026년 9월 6일 기준이며, 수치는 Google 공식 발표(블로그)를 따랐습니다(하단 링크). 벤치 수치는 3.7 Flash 대비 공표값입니다.

지난주 "모델이 매주 바뀐다"는 글에서 작업별 라우팅을 이야기했는데, 오늘 그 논지에 딱 맞는 사례가 나왔어요. 값싸고 빠른 "일꾼 모델"이 어디까지 왔는지 보여주는 케이스거든요.

뭐가 나왔나: 6주 만에 세 번째 Flash

Google이 9월 2일 Gemini 3.8 Flash와 보안 특화 3.8 Flash Cyber를 공개했습니다. 3.7 Flash가 나온 지 3주 만이자 6주 만에 세 번째 Flash예요. 구글의 표현은 "역대 최고의 추론·코딩 모델을 3.7과 같은 속도·저비용으로"입니다. 여기서 핵심 단어는 "같은 저비용"이에요.

가격이 이야기의 절반이다

▲ 같은 100만 입력 토큰에 $0.75 대 $10. 자릿수가 다릅니다.

Gemini 3.8 Flash는 입력 100만 토큰 $0.75, 출력 $3.75입니다. 이번 주 함께 나온 Fable 5.1·GPT-6 Astra가 입력 $10이었으니, 입력 기준 약 13분의 1 가격이에요. 이 정도 차이면 "성능이 조금 낮아도 열 배 싸면 이득"인 작업이 수두룩합니다. 대량 반복 작업·자동화·1차 필터링 같은 곳에서요.

구글이 강조한 것도 그 지점입니다 — 장기 소프트웨어 엔지니어링 벤치(DeepSWE)에서 훨씬 큰 프런티어 모델들을 "비용의 일부만으로" 앞선다고요. 즉 자랑 포인트가 "최고 점수"가 아니라 "점수 대비 가격"입니다.

코딩은 진짜 붙는다

가성비만 있는 게 아니라 절대 성능도 올랐습니다. 3.7 Flash 대비 코딩·에이전트 지표가 뚜렷하게 뛰었어요 — 장기 SE(DeepSWE v1.1)와 터미널 기반 에이전트 코딩(Terminal-Bench) 계열에서 전작을 앞서고, 구글이 공표한 벤치 일부에선 Claude Opus 5까지 제쳤습니다. 금융(Vals)·법률(Harvey) 에이전트 벤치처럼 전문 도메인에서도 전작·타 프런티어를 넘었다고 하고요.

정리하면 — "싸구려 경량 모델"이 아니라 "경량 가격표를 단 진짜 일꾼"에 가깝습니다. 그래서 더더욱, 아래 함정을 같이 봐야 해요.

싼 데는 조건이 있다: 함정 셋

▲ "열 배 싸다"에 바로 올인하기 전에 이 셋을 확인하세요.

① 여전히 Flash 티어입니다. 쉬운·중간 난도에선 프런티어에 근접하지만, 가장 어려운 장기 에이전트 과제(Terminal-Bench 4.0 계열)에선 절대 점수 자체가 낮습니다. "대부분의 일"엔 충분해도 "제일 어려운 소수"엔 아직 상위 모델이 필요해요.

② "더 열심히 일한다" = 토큰을 더 쓴다. 구글도 명시했어요 — 3.8 Flash는 복잡한 작업에서 추론 단계를 더 밟고 도구를 반복 호출하며, 특히 높은 effort에서 토큰을 더 씁니다. 어제 Fable 5.1에서 본 것과 똑같은 구조죠. 단가가 싸도 토큰을 많이 쓰면 총액은 오를 수 있으니, 효율이 우선이면 effort를 낮추거나 3.7 Flash를 유지하라고 구글이 직접 권합니다.

③ 이 가격은 도입가입니다. $0.75/$3.75는 2026년 12월 31일까지예요. 2027년 1월 1일부터 $1.50/$7.50로 정확히 2배가 됩니다. 그래도 플래그십보단 훨씬 싸지만, "13분의 1"이라는 매력은 넉 달짜리라는 걸 알고 예산을 잡으세요.

덤: 3.8 Flash Cyber

같이 나온 보안 변종도 인상적입니다. 3.8 Flash Cyber는 신뢰된 방어자에게만(Fairwind 프로그램) 열리는데, 취약점 탐지·자동 패치에 특화됐어요. 구글 Chrome 보안팀이 "훨씬 큰 상용 모델보다 2.6배 많은 정확한 패치를 만들었다"고 했고, 자사 클라우드 취약점 연구팀은 보통 몇 달 걸리는 critical 취약점을 2시간 안에 찾았다고 합니다. 지난주 보안 스캐너 시리즈(그 글)의 흐름에서 흥미로운 대목이에요 — 방어 쪽 자동화가 빠르게 싸지고 있습니다.

그래서 어떻게 쓰나

어제 글의 결론과 정확히 이어집니다 — 작업별로 모델을 나누세요. 대량·반복·1차 처리·비용이 중요한 자동화는 Gemini 3.8 Flash 같은 저가 일꾼으로, 사람이 마주 앉는 최고난도 설계·디버깅은 상위 모델로. "제일 싼 것 하나로 다"도, "제일 센 것 하나로 다"도 아니고, 작업 성격에 맞춰 배치하는 거예요. 이번 주 세 모델이 준 진짜 교훈은 "누가 최고냐"가 아니라 "내 작업 지도에 이 셋을 어떻게 배치하냐"입니다.

자주 묻는 질문 (FAQ)

Q. Gemini 3.8 Flash가 Opus 5보다 나은가요?

A. 일부 벤치에서는 앞섭니다(구글 공표 기준). 다만 Flash는 경량 티어라 가장 어려운 장기 에이전트 과제에서는 절대 성능이 낮습니다. "대부분의 작업에 충분하고 훨씬 싸다"가 정확한 표현이며, 최고난도 소수 작업엔 상위 모델이 여전히 유리합니다.

Q. 가격이 정말 그렇게 싼가요?

A. 입력 100만 토큰 $0.75, 출력 $3.75로 이번 주 플래그십(입력 $10)의 약 13분의 1입니다. 단 이는 도입가이며 2027년 1월 1일부터 $1.50/$7.50로 두 배가 됩니다.

Q. 싼 단가면 총비용도 항상 싼가요?

A. 아닙니다. 3.8 Flash는 복잡한 작업에서 추론 단계를 더 밟고 토큰을 더 쓰는 설계라, 높은 effort에서는 총액이 오를 수 있습니다. 효율이 중요하면 effort를 낮추거나 3.7 Flash를 유지하는 편이 낫다고 구글도 권합니다.

Q. 어디서 쓸 수 있나요?

A. Gemini API(Google AI Studio), Antigravity, Android Studio, Gemini Enterprise에서 개발용으로 쓸 수 있고, 일반 사용자는 Google AI Pro·Ultra 구독의 Gemini 앱 등에서 이용할 수 있습니다.

정리하면

Gemini 3.8 Flash = $0.75/$3.75(플래그십의 1/13)에 코딩 벤치는 프런티어에 근접, 일부 항목은 Opus 5도 제침. 단 Flash 티어 한계·토큰 증가·2027년 1월 2배 인상이라는 조건이 붙습니다. 이번 주 비싼 신모델 둘이 헤드라인을 가져갔지만, 저는 "점수 대비 가격"으로 보면 이 조용한 세 번째가 제일 실용적이라고 봐요. 결국 좋은 선택은 최고 모델을 고르는 게 아니라, 작업마다 적정 모델을 고르는 것입니다.

참고 자료

Gemini 3.8 Flash·Cyber 공식 발표 (Google)
Gemini API 개발자 문서 (Google)

모델이 매주 바뀌는 시대의 생존법 — 워크플로를 특정 모델에 묶지 마라

DevPilot — Sun, 6 Sep 2026 00:22:12 +0900

핵심 요약: 이번 한 주만 돌아봐도 AI 코딩 도구의 바닥이 다섯 번 흔들렸습니다 — Claude Code 한도 전환(9/14), Copilot 모델 6종 폐기, OpenAI의 Cursor 공급 중단, Fable 5.1·GPT-6 Astra 출시까지요. 공통점이 보이시나요? 내가 쓰던 모델·한도·가격이 내 의사와 무관하게 바뀐다는 겁니다. 그래서 오늘은 뉴스가 아니라 원칙을 씁니다 — 무엇이 바뀌든 흔들리지 않는 워크플로를 만드는 다섯 가지. 핵심은 하나예요: "최고 모델 하나에 올인"이 아니라 "무엇이 바뀌어도 갈아탈 수 있게" 짜는 것. 매주 바뀌는 건 못 막아도, 매주 휘둘리는 건 막을 수 있습니다.

※ 이 글은 특정 발표의 정리가 아니라, 이번 주 다섯 사건에서 뽑은 실전 원칙 모음입니다. 각 사건의 상세는 위 링크에.

솔직히 이번 주 글을 쓰면서 좀 지쳤어요. 월요일에 한도 이야기를 쓰고, 화요일에 모델이 사라졌고, 수요일엔 공급이 끊겼고, 목·금엔 새 모델이 둘 나왔죠. 그런데 이 피로가 힌트였습니다 — 도구가 문제가 아니라, 도구에 나를 너무 단단히 묶어둔 게 문제더라고요.

먼저: 이번 주에 뭐가 흔들렸나

▲ 닷새 동안 다섯 번. 축은 다르지만 메시지는 하나입니다.

한도가 바뀌었고(부스트→영구 전환), 모델이 폐기됐고(Copilot 6종), 공급이 끊겼고(OpenAI→Cursor), 새 모델이 나왔지만 "역대 최고"라는 수식과 독립 벤치가 어긋났죠(Fable 5.1·GPT-6 Astra). 내가 통제할 수 있는 건 하나도 없었습니다. 통제 못 하는 걸 붙들고 있으면 매번 휘둘려요. 그래서 통제할 수 있는 것 — 내 워크플로의 구조 — 에 손을 대는 겁니다.

원칙 ①: 작업에 모델을 맞춘다 ("최고 하나"의 함정)

이번 주 두 신모델이 준 교훈이 정확히 이겁니다 — "세계 최고"라는 모델이 내 모든 작업에 최적은 아니에요. GPT-6 Astra는 지능 지수가 전작과 동률인데 값은 2.5배였고, Fable 5.1은 effort를 높이면 오히려 비쌌죠. 정답은 "제일 센 모델 하나로 다 돌리기"가 아니라 작업별로 급을 나누는 것입니다.

사람이 마주 앉는 어려운 설계·디버깅은 상위 모델, 커밋 메시지·요약·반복 수정은 하위 모델로. 이 라우팅 기준을 한 번 정해두면, 새 모델이 나와도 "이건 어느 칸에 넣지?"만 판단하면 됩니다. 모델이 바뀌어도 칸(작업 분류)은 그대로니까요.

원칙 ②: 모델 핀을 느슨하게 (자동화에 모델명을 박지 마라)

Copilot 폐기와 Cursor 공급 중단이 준 실전 교훈입니다. 자동화·CI·에이전트 스크립트에 특정 모델 ID를 하드코딩해두면, 그 모델이 폐기되는 날 파이프라인이 멈춥니다. Copilot은 6종을 한꺼번에 내렸고, Cursor의 자동화·CLI는 BYOK로도 못 살렸죠.

그래서 프로덕션 자동화는 모델명을 변수 하나로 빼두고, "이 작업엔 이 급의 모델"이라는 추상 레벨로 지정하세요. 폐기 공지가 떠도 변수 한 줄만 바꾸면 끝나게요. 모델명을 코드 곳곳에 흩뿌려두면, 그 개수만큼 이사 비용이 붙습니다.

원칙 ③: 이식성을 싸게 유지한다 (BYOK의 한계를 미리 알기)

▲ 다섯 원칙을 한 장으로. 새 소식이 뜰 때마다 이 목록으로 점검하면 됩니다.

Cursor 공급 중단 때 많은 분이 "내 API 키 넣으면 되지"라고 했지만, BYOK는 로컬 Chat·Agent만 커버하고 Tab·자동라우팅·백그라운드 에이전트·CLI는 못 살렸습니다. 우회로가 있다는 것과, 그 우회로가 내 사용 방식을 커버한다는 건 다른 얘기예요.

그래서 평소에 "내가 쓰는 기능 중 어느 게 어느 공급자에 묶여 있나"를 대략이라도 알아두세요. 한 도구에만 깊게 의존하지 말고, 같은 작업을 다른 도구로도 해본 경험을 조금씩 쌓아두면 — 공급이 끊기는 날 이사가 이벤트가 아니라 설정 변경이 됩니다.

원칙 ④: 모델을 갈아타기 전에 effort와 캐시부터

이번 주 가격 뉴스 셋(부스트 축소, Fable 5.1, GPT-6 Astra)의 공통 결론입니다. 비용 문제의 첫 해법은 "더 싼 모델로 갈아타기"가 아니라 "지금 모델을 덜 쓰기"예요. effort를 낮추고(그 가이드), 캐시를 재사용하고, 컨텍스트를 짧게 유지하는 것만으로 체감이 크게 달라집니다.

Fable 5.1의 절감도 캐시에서 나왔고, 부스트 대응도 effort 하향이 먼저였죠. 모델 단가표를 비교하기 전에 내 사용 패턴부터 보세요 — 어느 쪽이 싼지는 비용 계산기에 하루 요청 수를 넣으면 숫자로 갈립니다. 대개 문제는 모델이 아니라 습관입니다.

원칙 ⑤: 폐기·시한을 캘린더로 추적한다

마지막은 지루하지만 제일 효과적입니다. 모델 폐기·한도 전환·공급 중단엔 대부분 날짜가 붙어 있어요 — Copilot 9/1·9/10, 부스트 9/14, Cursor 11/12. 이 날짜들을 캘린더에 "재확인" 항목으로 넣어두면, 어느 날 갑자기 당하는 대신 미리 준비합니다.

특히 "제안된" 날짜(협상 중이라 바뀔 수 있는 것)는 단일 알림이 아니라 주간 점검으로 두세요. 날짜가 앞당겨지는 경우도 있으니까요. 이 습관 하나가 "갑자기 안 돼요"를 "아, 그거 다음 주죠"로 바꿉니다.

자주 묻는 질문 (FAQ)

Q. 그냥 제일 좋은 모델 하나만 쓰면 안 되나요?

A. 가능하지만 두 가지 위험이 있습니다. 첫째, "제일 좋은"은 자주 바뀌고 값이 비쌉니다(이번 주 GPT-6 Astra는 전작과 지능 동률에 2.5배 가격). 둘째, 그 모델이 폐기·공급 중단되면 대안이 없습니다. 작업별 라우팅은 성능·비용·리스크를 동시에 관리합니다.

Q. 소규모 개인 개발자에게도 필요한가요?

A. 오히려 더 유용합니다. 대응할 팀이 없을수록 "이사 비용"을 미리 낮춰두는 게 중요합니다. 자동화에 모델명을 변수로 빼고, effort를 습관화하고, 폐기 날짜를 메모하는 정도면 개인도 충분히 실천할 수 있습니다.

Q. 도구를 여러 개 쓰면 오히려 비효율 아닌가요?

A. 항상 여러 개를 쓰라는 게 아니라, "한 개에만 깊게 갇히지 말라"는 뜻입니다. 주력 도구는 하나여도, 같은 작업을 다른 도구로도 할 수 있다는 감각만 유지하면 공급이 끊길 때 전환 비용이 급감합니다.

정리하면

매주 바뀌는 건 못 막습니다 — 한도도, 모델도, 공급도, 가격도. 하지만 매주 휘둘리는 건 막을 수 있어요. 작업에 모델을 맞추고(①), 자동화에 모델명을 박지 말고(②), 이식성을 싸게 유지하고(③), 갈아타기 전에 effort·캐시부터 보고(④), 날짜를 캘린더로 추적하는 것(⑤). 저는 이번 주 다섯 번 흔들리고 나서야 이걸 정리했는데, 결국 좋은 워크플로란 "최신을 좇는 것"이 아니라 "무엇이 바뀌어도 덜 아픈 구조"더군요. 다음 주에 또 뭔가 나와도, 이 다섯 칸에 넣어보면 됩니다.

GPT-6 Astra 나왔다 — "역대 최고"라는데, 독립 벤치는 왜 GPT-5.6 Sol과 동률일까

DevPilot — Fri, 4 Sep 2026 18:55:12 +0900

핵심 요약: 9월 3일, OpenAI가 GPT-6 Astra를 공개했습니다 — "세계에서 가장 지능적인 모델", "역대 최고의 소프트웨어 엔지니어링 모델", 심지어 "AGI 시대"라는 표현까지 붙였어요. 공식 벤치는 화려합니다(FrontierMath 티어4 ~98%, ARC-AGI-3 포화, ExploitBench 100%). 그런데 — 어제 Fable 5.1 글(그 글)과 똑같은 패턴이 나옵니다. 독립 평가(Artificial Analysis)에선 종합 지능 지수가 61로 기존 GPT-5.6 Sol과 동률이고, 코딩 지수도 67 대 65로 겨우 2점 차예요. 게다가 가격은 Sol의 약 2.5배($10/$50, Fast 모드 $20/$100)입니다. 그럼 뭐가 좋아진 걸까요? 진짜 개선은 벤치 점수가 아니라 컴퓨터 사용·속도·장시간 작업·Codex의 컨텍스트 보존 쪽이에요. 이 글은 마케팅과 실측을 분리해, "내 작업에 이게 의미 있나"를 기준으로 정리합니다.

※ 이 글은 2026년 9월 4일 기준이며, 수치는 OpenAI 공식 발표와 독립 벤치(Artificial Analysis 등)를 함께 인용했습니다(하단 링크).

공교롭게 이번 주는 프런티어 모델이 이틀 연속 나왔습니다 — 목요일 Anthropic Fable 5.1, 금요일 OpenAI GPT-6 Astra. 그리고 둘 다 "역대 최고"를 외쳤는데, 둘 다 독립 벤치에서 보면 이야기가 좀 달라져요. 오늘은 그 두 번째입니다.

OpenAI가 내세운 것

OpenAI의 표현은 대담합니다. GPT-6 Astra를 "세계에서 가장 지능적이고 정렬된 모델"이라 부르고, 컴퓨터 사용·브라우징·소프트웨어 엔지니어링·사이버보안·과학·전문 업무에서 최신 기록이라고 했어요. 벤치도 포화 수준을 내세웠습니다 — FrontierMath 티어4에서 약 98%, ARC-AGI-3 사실상 포화, ExploitBench 100%. 코딩에선 DeepSWE 계열 74.1% 같은 숫자를 들었고요.

흥미로운 건 이 모델의 정체입니다. 지난주 OpenAI가 Cursor 공급을 끊겠다고 했을 때 근거로 든 "곧 나올 모델 Astra의 책임성"이 바로 이겁니다. 그때 예고편이 이번 주에 본편으로 나온 셈이에요.

그런데 독립 벤치는 다르게 말한다

▲ 공식 발표(왼쪽)와 독립 지수(오른쪽)의 온도차. 같은 모델을 두고 그림이 다릅니다.

제3자 평가기관 Artificial Analysis의 종합 지능 지수에서 GPT-6 Astra는 61점 — 기존 GPT-5.6 Sol과 정확히 같습니다. 코딩 특화 지수에서도 67 대 65로 2점 차에 그쳤고요. "AGI 시대"라는 수사와, 독립 지표가 보여주는 "전작과 사실상 동급"의 간극이 이 발표의 핵심 논점입니다.

물론 벤치 포화(98%, 100% 같은 숫자)는 진짜입니다 — 다만 포화된 벤치는 변별력이 없어요. 모두가 만점에 근접하면 그 시험으론 우열을 못 가리죠. 그래서 종합 지능·코딩 지수 같은 "아직 여유가 있는" 지표가 더 정직한 비교가 되는데, 거기서 Astra는 도약이 아니라 소폭 개선입니다.

가격: Sol의 약 2.5배

지갑 이야기는 더 냉정합니다. GPT-6 Astra의 API 가격은 입력 100만 토큰 $10, 출력 $50(표준), 빠른 응답인 Fast 모드는 $20/$100입니다. 캐시 입력은 $1.00이고요. 이건 GPT-5.6 Sol의 약 2.5배 가격이에요. 지능 지수는 동률인데 값은 2.5배 — 순수 "지능 대비 가격"만 보면 오히려 나빠진 셈입니다.

어느 쪽이 내게 합리적인지는 결국 작업 성격과 사용량에 달려요. 지능 점수가 같다면 대부분의 일상 작업엔 더 싼 모델이 맞고, Astra는 뒤에서 볼 "다른 축"이 필요한 작업에서만 값을 합니다. 감이 아니라 숫자로 보려면 AI 구독 vs API 비용 계산기에 하루 요청 수를 넣어보세요.

그럼 진짜 개선은 어디에

▲ 점수판 말고 이 세 축이 Astra의 실제 값입니다.

Astra의 진짜 가치는 "지능 점수"가 아니라 일을 굴리는 능력에 있습니다. 컴퓨터 사용 벤치(OSWorld 2.0)에서 72.6%를 작업당 40분에 냈는데, 이는 GPT-5.6 Sol의 65.7%·75분보다 더 정확하면서 거의 두 배 빠른 겁니다. 즉 화면을 직접 조작해 다단계 업무(문서·스프레드시트·슬라이드 제작 등)를 끝까지 끌고 가는 힘이 붙었어요.

Codex 쪽 변화도 실무적입니다. 긴 세션에서 컨텍스트 창이 차면 기존엔 압축(compaction)으로 요약하며 "왜 그 수정이 실패했는지" 같은 디테일을 잃곤 했는데, Astra는 컨텍스트 창을 넘나들며 메모를 유지하고 이전 창을 검색할 수 있게 됐습니다. 큰 리팩터링·복잡한 디버깅처럼 오래 끄는 작업에서 체감이 클 대목이에요(현재 실험 기능, 곧 Astra 기본값 전환 예정).

접근성: 천천히 열린다

바로 다 쓸 수 있는 건 아닙니다. OpenAI는 Astra가 자사 대비 프레임워크의 사이버보안 "Critical" 임계치에 도달했다고 밝혔고, 그래서 느리게 롤아웃합니다 — 사이버 프로그램 소속 일부 조직부터 시작해, 며칠에 걸쳐 ChatGPT Plus·Pro·Business·Enterprise와 OpenAI API·AWS로 확대돼요. 기존 구독 사용량에 포함되고 추가분은 크레딧 구매 방식이며, Pro·Business·Enterprise는 GPT-6 Astra Pro도 받습니다. 단 Enterprise는 기본 비활성이라 관리자가 켜야 합니다.

그래서 써야 하나

정리하면 이렇습니다. ① "지능 점수"만 보면 굳이 2.5배 주고 갈아탈 이유는 약합니다 — 일상 코딩·질의는 기존 모델이 가성비에서 앞서요. ② 반대로 컴퓨터를 직접 조작하는 자동화, 아주 긴 에이전트 세션, Codex의 대형 리팩터링이 일상이라면 Astra의 속도·컨텍스트 보존이 실제 값을 합니다. ③ 결국 작업별로 모델을 고르는 원칙이 정답이에요 — "최고 모델 하나로 다"가 아니라 "이 작업엔 이 축이 필요한가"로요. 마케팅 문구가 아니라 그 질문이 비용을 지킵니다.

자주 묻는 질문 (FAQ)

Q. GPT-6 Astra가 정말 "역대 최고"인가요?

A. 공식 벤치 일부는 포화 수준이지만, 독립 평가(Artificial Analysis)의 종합 지능 지수에서는 61로 기존 GPT-5.6 Sol과 동률이고 코딩 지수도 2점 차입니다. "지능"만 보면 도약이 아니라 소폭 개선에 가깝고, 실제 강점은 컴퓨터 사용·속도·장시간 작업에 있습니다.

Q. 가격이 얼마인가요?

A. 표준 모드가 입력 100만 토큰 $10, 출력 $50이고 Fast 모드는 $20/$100입니다. 이는 GPT-5.6 Sol의 약 2.5배 수준입니다. 지능 지수가 동률인 점을 감안하면 지능 대비 가격은 오히려 불리합니다.

Q. Codex에서 뭐가 달라지나요?

A. 긴 세션에서 컨텍스트가 찰 때 압축으로 요약하는 대신, 컨텍스트 창을 넘나들며 메모를 유지하고 이전 창을 검색할 수 있게 됩니다. 대형 리팩터링이나 복잡한 디버깅에서 세부 정보 손실이 줄어듭니다. 현재 실험 기능이며 곧 Astra 기본값이 됩니다.

Q. 지금 바로 쓸 수 있나요?

A. 사이버보안 임계치 도달로 천천히 배포됩니다. 일부 조직부터 시작해 며칠에 걸쳐 ChatGPT 유료 플랜과 OpenAI API·AWS로 확대되며, Enterprise는 관리자가 활성화해야 합니다.

정리하면

GPT-6 Astra = 공식 "역대 최고·AGI 시대", 독립 지능 지수는 GPT-5.6 Sol과 동률(코딩 +2), 가격은 2.5배. 진짜 개선은 점수가 아니라 컴퓨터 사용·속도·장시간 작업·Codex 컨텍스트 보존. 저는 이번 주 두 번 같은 걸 배웠어요 — 모델 발표의 형용사와 독립 벤치의 숫자는 자주 어긋나고, 내 지갑을 지키는 건 형용사가 아니라 "내 작업 축에 실제로 맞나"라는 질문이라는 것. 화려한 데모에 설레되, 갈아타기 전엔 독립 지표와 내 작업 유형부터 맞춰보세요.

참고 자료

GPT-6 Astra 공식 발표 (OpenAI)
GPT-6 Astra 독립 벤치·지능 지수 (Artificial Analysis)

Claude Fable 5.1 나왔다 — 코딩 벤치는 대폭 상승, 근데 '싸졌다'는 진짜일까

DevPilot — Thu, 3 Sep 2026 17:51:36 +0900

핵심 요약: 9월 1일, Anthropic이 Claude Fable 5.1과 Mythos 5.1을 내놨습니다 — "세계 최고 코딩·지식 모델"이라는 표현과 함께요. 둘은 같은 모델에 안전장치 수위만 다른 쌍(Fable은 일반 공개, Mythos는 사이버보안·생명과학 특수 프로그램 한정)입니다. 코딩 벤치는 확실히 뛰었어요 — 에이전트 코딩(Terminal-Bench 4.0)에서 Fable 5.1이 55.8%로 전작 42.0%를 크게 앞섭니다. 가격은 입력 $10·출력 $50로 그대로지만, 캐시 읽기를 $1→$0.25로 75% 내려 전형적 작업은 약 25%, 에이전트 작업은 최대 45% 싸진다고 하고요. 그런데 — 여기가 이 글의 포인트인데, "싸졌다"는 조건부입니다. 출력 토큰을 더 쓰는 특성이라 effort를 높이면 오히려 전작보다 비싸질 수 있고, 무엇보다 Opus 5가 절반 가격($5/$25)에 성능은 3점밖에 안 낮아요. 이 글은 벤치·가격·그 함정을 실사용 관점에서 정리합니다.

※ 이 글은 2026년 9월 3일 기준이며, 수치는 Anthropic 공식 발표와 벤치 원자료(Artificial Analysis 등)를 따랐습니다(하단 링크).

여름 내내 Anthropic 모델 소식이 잦았죠 — 7월 말 Opus 5(그 정리)가 "Fable 5보다 싸면서 대부분 벤치에서 비슷하거나 낫다"는 평가를 받았고, 그 가격 압박 속에서 Fable이 5.1로 답을 내놓은 셈입니다. 결론부터 말하면 — 좋아졌는데, "그래서 이걸 써야 하나"는 생각보다 안 단순해요.

뭐가 나왔나: Fable 5.1과 Mythos 5.1

둘은 같은 베이스 모델이고 안전장치(가드레일) 수위만 다릅니다. Fable 5.1은 모든 플랫폼(API·AWS·GCP·Azure)에서 바로 쓸 수 있고, API 모델명은 claude-fable-5-1이에요. Mythos 5.1은 미국 기관 대상의 사이버 방어·생명과학 검증 프로그램에 한정 공개됩니다. 일반 개발자에게 실질적으로 의미 있는 건 Fable 5.1 쪽이에요.

참고로 이 둘은 워터마크가 내장된 첫 Claude 모델이기도 합니다 — 출력 텍스트에 표식을 넣고, 규제기관·언론·연구자가 검증할 수 있는 탐지 API를 프리뷰로 열었어요. 창작·과제 용도로 쓰는 분은 알아둘 만합니다.

코딩 벤치: 확실히 뛰었다

▲ 전작(Fable 5) 대비 상승폭이 큽니다. 특히 에이전트·과학 계열에서.

숫자로 보죠. 에이전트 코딩 지표인 Terminal-Bench 4.0에서 Fable 5.1은 55.8%(Mythos는 60.9%)로 전작 42.0%, GPT-5.6 Sol 37.3%를 앞섭니다. 과학 계열 에이전트(Terminal-Bench-Science 0.1)에선 52.6%로 전작 24.7%의 두 배 이상이고요. Cursor 실사용에 가까운 CursorBench 3.2.0은 73.4%로 전작 70.5%·Opus 5 70.0%보다 위입니다. 종합 지능 지표(Artificial Analysis Intelligence Index)에서도 Fable 5.1이 66점으로 Opus 5(63)·GPT-5.6 Sol(61)을 제치고 1위예요.

덤으로 반가운 변화 하나 — Anthropic 연구자가 밝히길 글쓰기 스타일이 개선됐답니다. 이전 모델이 채팅에서 불릿·볼드를 남발하던 걸 줄이고 더 자연스럽게, 스타일 지시도 더 잘 따른다고요. 저처럼 초안을 자주 뽑는 사람에겐 체감 큰 부분이에요.

가격: "$10/$50 그대로, 근데 캐시는 75% 인하"

이제 지갑 이야기. API 가격은 입력 100만 토큰 $10, 출력 $50로 전작과 동일합니다. 대신 캐시 읽기를 $1에서 $0.25로 75% 내렸어요. Anthropic은 이 덕에 전형적 작업은 약 25%, 툴 호출이 많은 긴 에이전트 작업은 최대 45%까지 싸진다고 설명합니다.

▲ "싸졌다"는 조건부입니다. effort와 작업 성격에 따라 방향이 갈려요.

그런데 여기서 반전이 있습니다. 사전 테스트에 참여한 Artificial Analysis가 절감 주장에 이의를 달았어요 — Fable 5.1은 출력 토큰을 전작의 약 1.7배 쓰는 경향이라, 최고 effort에선 작업당 비용이 오히려 전작보다 20% 비싸진다는 겁니다. 캐시 읽기에서 아낀 걸 늘어난 출력이 도로 까먹는 구조예요. 다행히 Anthropic도 "낮음·중간 effort에선 전작 성능을 더 싸게 낸다"고 하니, effort 다이얼(그 가이드)을 낮게 두는 사용이 실제 절감의 조건입니다.

진짜 비교 상대는 Opus 5

그리고 이 대목을 빼면 안 됩니다 — Opus 5는 입력 $5·출력 $50의 절반인 $25로, Fable 5.1의 딱 절반 가격입니다. 종합 지능 지표에선 66 대 63으로 단 3점 차이고요. 즉 "최고 성능"이 필요한 소수 작업이 아니라면, 대부분의 실무는 Opus 5가 가성비에서 앞섭니다. Fable 5는 높은 가격 탓에 기업 도입이 저조했는데, 5.1이 그 구도를 뒤집었다고 보긴 이릅니다.

어느 쪽이 내게 싼지는 결국 작업량과 캐시 활용도에 달려요 — AI 구독 vs API 비용 계산기에 하루 요청 수를 넣어 보면 감이 아니라 숫자로 갈립니다.

보안 쪽 변화: 오탐 감소 + 취약점 식별

지난주 보안 스캐너 후기(그 글)와 이어지는 대목이 있어요. 5.1은 사이버·생물·의료 질문의 과민한 오탐(false positive)을 크게 줄였습니다 — 사이버 60%, 생물 85% 감소. 그리고 Fable 5.1이 처음으로 소프트웨어 취약점을 "식별"할 수 있게 됐어요(단, 익스플로잇 생성은 여전히 Opus 계열로 라우팅). 방어적 보안 작업의 문턱이 낮아진 셈입니다.

운영 쪽 변화도 하나 — 증류(distillation) 공격을 막으려고, 새 API 계정은 다중 턴 대화에서 사고 과정(thinking) 기록을 유지한 채 이전 컨텍스트를 편집하는 걸 막았습니다. 대부분의 사용자에겐 영향 없지만, 프롬프트 파이프라인을 정교하게 짜는 분은 알아둘 변화예요.

그래서 지금 써야 하나

정리하면 이렇습니다. ① Claude Code나 API에서 고난도 에이전트 코딩을 돌린다면 5.1의 벤치 상승이 체감될 수 있어요 — 단 effort는 낮게 시작. ② "무조건 최신·최고"가 아니라 비용까지 본다면 Opus 5가 여전히 합리적 기본값입니다(절반 가격, 3점 차). ③ 캐시를 많이 재사용하는 워크플로(같은 코드베이스 반복 질의 등)라면 캐시 인하 효과가 커서 5.1이 유리하고요. 한 줄로: "모델을 바꾸기 전에 effort와 캐시 활용부터 보라"가 이번 출시의 실용 결론입니다.

자주 묻는 질문 (FAQ)

Q. Fable 5.1과 Mythos 5.1은 뭐가 다른가요?

A. 같은 베이스 모델이고 안전장치 수위만 다릅니다. Fable 5.1은 모든 플랫폼에서 일반 공개되고, Mythos 5.1은 미국 기관 대상 사이버 방어·생명과학 검증 프로그램에 한정 제공됩니다. 일반 개발자가 쓰는 건 Fable 5.1입니다.

Q. 정말 전작보다 싸진 건가요?

A. 조건부입니다. 캐시 읽기가 75% 저렴해져 낮음·중간 effort에서는 전작 성능을 더 싸게 냅니다. 다만 출력 토큰을 더 쓰는 특성이라, 최고 effort에서는 작업당 비용이 오히려 전작보다 비싸질 수 있습니다.

Q. Opus 5 대신 Fable 5.1을 써야 하나요?

A. 대부분은 아닙니다. Opus 5는 Fable 5.1의 절반 가격($5/$25)이며 종합 지능 지표에서 3점밖에 낮지 않습니다. 최고 성능이 꼭 필요한 소수 작업이 아니라면 Opus 5가 가성비에서 앞섭니다.

Q. 어떻게 쓰나요?

A. API에서 모델명 claude-fable-5-1로 호출하며 AWS·GCP·Azure에서도 제공됩니다. Claude Code에서도 선택할 수 있습니다.

정리하면

Fable 5.1·Mythos 5.1 = 코딩 벤치 대폭 상승(에이전트·과학 계열 특히), 가격 $10/$50 유지+캐시 75%↓. 다만 "싸졌다"는 effort·캐시 활용에 달린 조건부이고, 절반 가격의 Opus 5가 3점 차로 붙어 있어 실무 기본값은 여전히 Opus 5 쪽입니다. 저는 이번 발표에서 벤치 숫자보다 "출력 토큰을 더 써서 절감이 상쇄된다"는 반론이 더 유익했어요 — AI 비용은 단가표가 아니라 내 사용 패턴에서 정해진다는 걸 또 확인합니다. effort부터 만져보고 판단하세요.

참고 자료

Claude Fable 5.1·Mythos 5.1 공식 발표 (Anthropic)
Fable 5.1 벤치·지능 지표 (Artificial Analysis)

Cursor에서 GPT 모델이 사라진다? — OpenAI 공급 중단(11/12 예정)의 실제 영향

DevPilot — Wed, 2 Sep 2026 16:52:20 +0900

핵심 요약: 8월 28일, OpenAI가 "Cursor에 자사 모델 공급을 중단하겠다"고 발표했습니다 — 제안 시한은 11월 12일(아직 "제안"이고 확정 아님). 방아쇠는 SpaceX의 Cursor 인수(8/14 완료)로 발동된 계약상 지배권 변경(change-of-control) 조항이에요. 겁부터 먹을 필요는 없습니다 — 실제 영향은 Cursor의 11개 모델 중 3개(GPT-5.6 Luna·Sol·Terra)뿐이고, Cursor CEO는 "OpenAI 모델은 트래픽의 약 5%"라고 밝혔어요. Claude·Grok·Gemini·Composer는 무관하고, Anthropic은 오히려 "Claude 공급 유지 + 컴퓨트 증량"으로 응수했습니다. 다만 함정 하나 — "내 OpenAI 키를 넣으면(BYOK) 되잖아"는 절반만 맞습니다. BYOK는 로컬 Chat·Agent만 커버하고 Tab·Auto·Cloud/Background Agent·CLI는 못 살려요. 이 글은 뭐가 바뀌고 뭐가 안 바뀌는지, Cursor 쓰는 사람 기준으로 정리합니다.

※ 이 글은 2026년 9월 2일 기준이며, 수치·시한은 OpenAI 공식 발표와 Help Center를 따랐습니다(하단 링크). "11/12"는 확정이 아니라 제안 시한입니다.

지난달 SpaceX가 Cursor를 인수했다는 글을 쓰면서, "인수는 시작일 뿐이고 진짜 이야기는 그 다음"이라고 적었는데 — 그 다음이 생각보다 빨리 왔습니다. 인수 2주 만에 OpenAI가 손을 뗀다고 나섰거든요.

무슨 일이 있었나

8월 28일(금) 늦은 밤, OpenAI가 자사 사이트에 "SpaceX의 Cursor 인수에 대한 우리의 결정"이라는 글을 올렸습니다. 요지는 넷이에요 — ① Cursor에 모델을 공급하던 계약을 정리(wind down)하겠다, ② 제안 시한은 11월 12일, ③ "계약이 허용하는 최대한의 유예"를 준다, ④ 그동안 미래 모델은 Cursor에 주지 않는다.

중요한 단어는 "제안(proposed)"입니다. OpenAI의 Help Center는 한 발 더 나가 "Cursor가 더 일찍 접근을 종료할 수도 있고, 공식 종료일은 양사 간 확정되는 대로 공유하겠다"고 적었어요. 즉 11/12는 확정 날짜가 아닙니다 — 더 빨라질 수도, 협상으로 바뀔 수도 있어요.

왜 갑자기: 지배권 변경 조항

이유는 계약 구조에 있습니다. OpenAI와 Cursor의 맞춤 계약엔 "상대의 지배권이 바뀌면 일정 기간 안에 해지할 수 있는" 조항이 있었고, 8월 14일 SpaceX의 Anysphere(Cursor 모회사) 인수가 완료되며 그 창이 열렸습니다. 8/28 발표는 OpenAI가 그 창으로 걸어 들어간 거예요.

명분은 신뢰 문제입니다. OpenAI는 "머스크 계열사들이 계약을 위반해온 경험상, SpaceX가 우리 기술을 약관 내에서 쓸 거라 확신할 수 없다"고 못박았어요. 흥미로운 건 Cursor 제품 자체엔 "4년간 함께한 팀에 큰 존경을 표한다"며 우호적이라는 점 — 문제 삼는 건 제품이 아니라 새 모회사입니다.

실제 영향: 11개 중 3개, 트래픽 5%

▲ 겁먹을 규모는 아닙니다. 빨간 3개만 흔들리고, 나머지 8개는 그대로예요.

Cursor의 모델 문서 기준, 현재 셀렉터엔 11개 모델이 있습니다. 이번에 흔들리는 건 그중 OpenAI의 3개 — GPT-5.6 Luna·Sol·Terra뿐이에요. Grok 4.6·4.5, Composer 2.5, Claude(Fable 5·Opus 5·Sonnet 5), Gemini(3.1 Pro·3.7 Flash)는 전부 무관합니다. Cursor CEO 마이클 트루얼도 8/30에 "OpenAI 모델은 Cursor 트래픽의 약 5%이고, OpenAI와 해결을 논의 중"이라고 밝혔고요.

그리고 반대편 소식 — Anthropic 공동창업자 톰 브라운이 같은 날 "Cursor는 Sonnet 3.5 때부터의 신뢰하는 파트너다. Claude 모델을 위한 컴퓨트를 계속 늘리겠다"고 응수했습니다. 한쪽이 발을 빼자 다른 쪽이 들어온 셈이라, Claude를 주로 쓰는 Cursor 사용자에겐 오히려 안정 신호예요.

함정: "내 API 키 넣으면 되잖아"는 절반만 맞다

여기가 이 글에서 제일 중요한 부분입니다. OpenAI는 발표와 함께 "그래도 쓰고 싶으면 BYOK(내 키 사용)·Codex 확장·AI 게이트웨이 3가지 길이 있다"고 안내했어요. 그런데 BYOK가 커버하는 범위가 좁습니다.

▲ 내 키로 살아나는 건 로컬 Chat·Agent 둘뿐. 아래 회색은 공식 우회로가 없습니다.

OpenAI Help Center의 문구 그대로 — 내 API 키는 로컬 Chat·Agent 요청에만 적용됩니다. Tab·자동완성, Auto 모델 라우팅, Cloud·Background Agent, Automations, Cursor CLI, Cursor API/SDK엔 적용되지 않아요. AI 게이트웨이(Bedrock·Azure)도 같은 한계고요. 특히 Cursor의 Auto 라우터가 커버 밖이라, Auto가 그동안 조용히 GPT 모델을 골라주고 있었다면 내가 아무것도 안 해도 동작이 달라질 수 있습니다.

영수증 함정도 둘 있어요. ChatGPT 구독은 API 사용을 포함하지 않습니다 — BYOK를 쓰려면 결제 설정된 별도 OpenAI API 계정이 필요해요. 그리고 Cursor Teams·Enterprise는 BYOK 요청에도 100만 토큰당 $0.25의 Cursor 요율이 붙습니다. 여기에 하나 더 — 자체 키를 쓰면 Cursor의 Zero Data Retention 보장이 그 트래픽엔 적용되지 않아요. 보안 때문에 Cursor를 골랐다면 이건 짚고 넘어가야 합니다.

2025년 Windsurf와 뭐가 다른가

비슷한 기억이 있죠 — 2025년 6월 Anthropic이 Windsurf의 Claude 직접 접근을 제한한 사건. 그때와 이번은 메커니즘이 다릅니다. Windsurf 건은 "컴퓨트 배분"을 이유로 든 5일 미만의 급작스러운 제한이었고, 이번 건은 계약 조항을 명시적으로 발동한 약 76일의 유예 + 공식 우회로 안내가 딸려 있어요. 같은 저류(코딩 도구의 모델 공급은 결국 인프라 제공자가 당길 수 있는 레버)지만, 대비할 시간은 이번이 훨씬 깁니다.

그래서 Cursor 사용자가 지금 할 일

세 가지면 충분합니다. ① 내가 Cursor에서 OpenAI 모델을 어느 기능에서 쓰는지 확인 — 가끔 로컬 Chat에서 GPT를 고르는 정도면 BYOK로 오후 한나절이면 되고, Automations·Background Agent·CLI에 GPT 모델 ID를 박아뒀다면 공식 우회로가 없으니 대체 모델로 다시 지정해야 합니다. ② 어차피 대부분은 Claude·Grok으로 충분하니, 작업별 모델 라우팅 기준대로 GPT 의존 작업만 골라 옮기세요. ③ 11/12는 "제안"일 뿐이니 확정일을 캘린더에 재확인 항목으로 — 더 빨라질 수도 있습니다. 결론은, 특정 벤더 모델에 워크플로를 못박지 않는 습관이 이번에도 정답이에요.

자주 묻는 질문 (FAQ)

Q. 11월 12일에 Cursor에서 GPT가 무조건 사라지나요?

A. 확정이 아닙니다. OpenAI는 "제안된(proposed)" 날짜라고 반복했고, Help Center는 "더 빨라질 수 있으며 공식 종료일은 양사가 확정하는 대로 공유한다"고 밝혔습니다. 협상이 진행 중이라 앞당겨질 수도, 조정될 수도 있습니다.

Q. Claude나 Grok을 쓰는데 영향이 있나요?

A. 없습니다. 이번 발표는 OpenAI 모델(GPT-5.6 Luna·Sol·Terra)에만 해당합니다. Claude·Grok·Gemini·Composer는 그대로이고, Anthropic은 Claude 공급 유지와 컴퓨트 증량을 공언했습니다.

Q. 내 OpenAI API 키를 넣으면 계속 쓸 수 있나요?

A. 부분적으로만 가능합니다. BYOK는 로컬 Chat·Agent에만 적용되고 Tab·Auto 라우팅·Cloud/Background Agent·Automations·CLI·API/SDK엔 적용되지 않습니다. 또 ChatGPT 구독과 별개로 결제 설정된 OpenAI API 계정이 필요합니다.

Q. 지금 당장 뭘 해야 하나요?

A. Cursor에서 OpenAI 모델을 쓰는 기능을 먼저 파악하세요. 자동화·백그라운드 에이전트·CLI에 GPT 모델 ID가 고정돼 있으면 공식 우회로가 없으므로 대체 모델로 재지정이 필요하고, 로컬 Chat 위주면 대응이 가볍습니다.

정리하면

OpenAI가 8/28 Cursor 공급 중단을 발표(11/12 제안), 방아쇠는 SpaceX 인수의 지배권 변경 조항. 실제 영향은 11개 중 3개(GPT-5.6)·트래픽 5%, Claude·Grok은 무관하고 Anthropic은 컴퓨트 증량으로 응수. BYOK는 로컬 Chat·Agent만 커버하는 절반짜리 패치. 저는 이 사건을 보며 다시 확인했어요 — AI 코딩 도구에서 "어떤 모델을 쓰느냐"만큼 "그 모델을 누가, 어떤 계약으로 공급하느냐"가 리스크더군요. 도구를 고를 때 모델 이식성을 싸게 유지해두는 습관이, 이런 날 결국 나를 구합니다.

참고 자료

OpenAI 공식 발표 (8/28)
OpenAI Help Center — Cursor에서 OpenAI 모델 사용
Cursor 모델·요금 공식 문서

어제 Copilot에서 모델이 사라졌다면 — 9/1 폐기 6종과 갈아타기 정리

DevPilot — Wed, 2 Sep 2026 01:52:35 +0900

핵심 요약: 어제(9월 1일) GitHub Copilot에서 모델 6종이 전 기능에서 폐기됐습니다 — 챗·인라인 편집·ask/agent 모드·코드 완성 전부요. 그래서 오늘 아침 "쓰던 모델이 갑자기 안 보인다"는 글이 커뮤니티에 쏟아지고 있어요. 사라진 건 Gemini 3.1 Pro, Claude Opus 4.5·4.6, Claude Sonnet 4.5·4.6, Raptor Mini. 각각 대체 모델이 지정돼 있으니 당황할 필요는 없습니다(Sonnet 계열은 Sonnet 5, Opus 계열은 Opus 4.7/4.8/5). 딱 한 가지 예외 — 연간 개인 구독자는 Sonnet 4.6이 유지됩니다. 그리고 "폐기 목록에 없는데도 내 모델이 안 보이는" 경우가 있는데, 그건 폐기가 아니라 관리자 정책이나 플랜 제한 문제예요. 이 글은 폐기 목록·대체 매핑·"왜 안 보이지" 3가지 원인·9/10 추가 폐기까지, 오늘 필요한 것만 정리합니다.

※ 이 글은 2026년 9월 2일 기준이며, 폐기 목록·날짜는 GitHub 공식 체인지로그를 따랐습니다(하단 링크).

지난달 9월 캘린더 글에서 "9/1 Copilot 모델 폐기"를 예고편으로 다뤘는데, 어제 실제로 실행됐습니다. 예고와 실제가 만나는 날은 늘 검색이 몰려요 — "어? 내 모델 어디 갔지?" 하고요.

무슨 일이 있었나: 6종 폐기

GitHub은 9월 1일부로 아래 모델들을 Copilot 전 기능(챗·인라인 편집·ask/agent·코드 완성)에서 내렸습니다. 표부터 보시죠 — 왼쪽이 사라진 모델, 오른쪽이 공식 지정 대체입니다.

▲ 사라진 모델 → 갈아탈 모델. 대부분 "같은 계열의 최신판"으로 자연스럽게 이어집니다.

폐기된 모델 (9/1)	공식 대체 모델
Gemini 3.1 Pro	Gemini 3.6 Flash
Claude Opus 4.5	Claude Opus 4.7 · 4.8 · 5
Claude Opus 4.6	Claude Opus 4.7 · 4.8 · 5
Claude Sonnet 4.5	Claude Sonnet 5
Claude Sonnet 4.6	Claude Sonnet 5 (연간 개인 구독자는 유지)
Raptor Mini	MAI-Code-1-Flash

좋은 소식은, 폐기된 모델을 손수 지울 필요가 없다는 겁니다 — GitHub이 알아서 목록에서 내려요. 여러분이 할 일은 "쓰던 모델의 후속을 골라 다시 지정"하는 것뿐입니다. Sonnet 4.6을 쓰던 사람은 Sonnet 5로, Opus 4.6을 쓰던 사람은 Opus 4.8이나 5로 옮기면 됩니다.

딱 하나의 예외: 연간 개인 구독자

표에 별표 하나 붙여둔 이유입니다. 개인(individual) 연간 플랜 구독자는 Sonnet 계열이 하나쯤 남아 있도록 Claude Sonnet 4.6이 그대로 유지됩니다. 이 경우엔 폐기 대상이 아니에요. 그래서 "나는 아직 Sonnet 4.6이 보이는데?" 하는 분과 "사라졌는데?" 하는 분이 갈리는 겁니다 — 플랜 차이지 버그가 아닙니다.

"폐기 목록에 없는데 내 모델이 안 보여요"

여기가 오늘 진짜 혼란 지점입니다. 커뮤니티엔 폐기 6종 말고도 "Opus 4.8이 안 보인다", "모델 절반이 사라졌다" 같은 글이 섞여 올라와요. 그런데 이건 폐기가 아니라 다른 원인일 때가 많습니다. 세 가지로 나눠 보면 정리됩니다.

▲ "안 보인다"의 원인은 셋 중 하나입니다. 먼저 어느 경우인지부터.

① 진짜 폐기된 모델이라면 위 표대로 후속으로 갈아타면 끝. ② 조직(Enterprise) 계정이라면, 대체 모델이 관리자 정책에서 아직 활성화되지 않은 경우가 흔합니다. 관리자가 Copilot 설정의 모델 정책에서 해당 모델을 켜줘야 셀렉터에 나타나요. 본인이 관리자라면 개인 Copilot 설정에서 그 모델 정책이 켜져 있는지 먼저 확인하세요. ③ 무료 Student 플랜이라면, 프리미엄 모델(상위 Claude·GPT 등)의 수동 선택 자체가 제한됩니다. 서비스를 무료로 유지하기 위한 조치라, 프리미엄 모델을 직접 고르려면 Pro 이상이 필요해요.

정리하면 — 안 보이는 모델이 위 6종이면 "갈아타기", 그 외인데 조직 계정이면 "관리자 정책 확인", 학생 무료 플랜이면 "플랜 제한"입니다. 재설치나 VS Code 업데이트로 임시 복구됐다는 얘기도 도는데, 원인이 폐기·정책·플랜이면 재설치로는 안 돌아옵니다.

9/10에 하나 더: MAI-Code-1-Flash

달력에 하나 더 적어두세요. 9월 10일엔 방금 대체 모델로 올라온 MAI-Code-1-Flash가 다시 폐기되고 MAI-Code-1.1-Flash로 넘어갑니다. 즉 Raptor Mini를 쓰던 분은 9/1에 MAI-Code-1-Flash로, 다시 9/10에 1.1로 두 번 이사하는 셈이에요. 자주 바뀌는 경량 모델 라인이라, 여기에 워크플로를 고정해뒀다면 버전 태그를 느슨하게 잡아두는 게 편합니다.

그래서 오늘 할 일

세 줄로 줄이면 이렇습니다. ① 쓰던 모델이 표의 6종이면 후속 모델로 다시 지정(대부분 Sonnet 5 / Opus 4.8·5). ② 조직 계정에서 원하는 모델이 안 보이면 관리자에게 모델 정책 활성화 요청. ③ 9/10 MAI-Code 이사 예약. 모델을 고를 때 "어떤 작업에 어떤 급을 쓸지" 기준이 헷갈린다면 작업별 모델 라우팅 기준이 그대로 도움이 됩니다 — 폐기든 아니든, 결국 "이 작업에 이 모델이 맞나"는 같은 질문이니까요.

자주 묻는 질문 (FAQ)

Q. 폐기된 모델을 계속 쓸 방법이 있나요?

A. 없습니다. 폐기된 모델은 Copilot 전 기능에서 선택지에서 내려가며, 재설치·재로그인으로 되살릴 수 없습니다. 지정된 대체 모델로 옮기는 것이 유일한 방법입니다.

Q. 어제까지 쓰던 Sonnet 4.6이 아직 보이는데 왜죠?

A. 개인 연간 플랜 구독자에게는 Sonnet 4.6이 유지되기 때문입니다. Sonnet 계열을 하나는 남겨두는 예외라, 폐기 대상이 아닙니다. 월간·조직 플랜에서는 사라졌을 수 있습니다.

Q. 폐기 목록에 없는 모델이 안 보이면요?

A. 폐기가 아니라 정책·플랜 문제일 가능성이 큽니다. 조직 계정은 관리자가 Copilot 설정의 모델 정책에서 활성화해야 하고, 무료 Student 플랜은 프리미엄 모델의 수동 선택이 제한됩니다.

Q. 대체 모델을 자동으로 골라주나요?

A. 자동 삭제는 되지만 자동 지정은 아닙니다. 사라진 모델의 후속을 본인이 모델 셀렉터에서 골라야 합니다. Enterprise는 관리자 정책에서 대체 모델이 켜져 있어야 셀렉터에 노출됩니다.

정리하면

9/1 Copilot 폐기 = Gemini 3.1 Pro·Opus 4.5·4.6·Sonnet 4.5·4.6·Raptor Mini 6종, 각각 최신 계열로 대체(연간 개인은 Sonnet 4.6 유지). "안 보인다"의 원인은 폐기·관리자 정책·플랜 제한 셋 중 하나. 9/10엔 MAI-Code-1-Flash가 1.1로. 저는 이런 폐기 공지를 볼 때마다 느끼는데, AI 모델은 이제 "설치하고 잊는" 도구가 아니라 분기마다 이사하는 도구네요. 셀렉터를 가끔 열어 "지금 뭐가 최신인지" 확인하는 습관이 결국 제일 쌉니다.

참고 자료

9/1 모델 폐기 6종 (GitHub Changelog)
9/10 MAI-Code-1-Flash 폐기 (GitHub Changelog)
Copilot 지원 모델 공식 문서

Claude Code 한도 '영구 25% 인상'의 함정 — 9/14부터 지금보다 17% 줄어든다

DevPilot — Mon, 31 Aug 2026 17:20:52 +0900

핵심 요약: Anthropic이 공식 계정으로 공지했습니다 — Claude Code 주간 한도를 9월 14일부터 "영구 25% 인상"한다고요(Pro·Max·Team·시트형 Enterprise 대상). "인상"이라는 단어만 보면 좋은 소식 같은데, 함정이 있습니다. 지금은 +50% 부스트가 걸려 있어서 기준선의 150% 를 쓰고 있거든요. 9/14부터 그게 125%로 바뀝니다. 즉 원래보다는 늘었지만, 오늘 쓰던 양보다는 약 17% 줄어드는 겁니다. 부스트는 9월 13일까지 그대로 유지되고, 그 다음 날 전환돼요. 5시간 세션 한도는 이번 변화와 무관하게 그대로입니다. 이 글은 그 산수를 정확히 풀고, D-13인 지금 뭘 해두면 전환 충격이 없는지 — /usage 측정부터 effort·라우팅·세션 정리까지 — 실전 순서로 정리합니다.

※ 이 글은 2026년 9월 1일 기준입니다. 수치·날짜는 Anthropic 공식 발표(Claude Developers 계정)를 따랐고, 본문 하단에 원문을 링크했습니다.

지난 몇 달간 이 부스트 얘기를 여러 번 썼습니다. "8/19 종료" 예고가 나왔다가 8/31로 연장됐고(그 대비 글), 그래서 어제까지도 "9월엔 어떻게 되나"가 열린 질문이었어요. 이제 답이 나왔습니다 — 그런데 그 답의 모양이 좀 얄궂습니다.

공지 내용부터: "영구 25% 인상"

Anthropic은 이렇게 밝혔습니다 — 9월 14일부터 Claude Code의 표준 주간 한도를 영구적으로 25% 올린다, 그때까지는 현재의 50% 인상이 유지된다. 대상은 Pro·Max·Team, 그리고 시트 기반 Enterprise예요. 문장만 보면 "한도를 올려준다"니 반가운 소식처럼 들립니다.

▲ 세 개의 막대만 보면 함정이 한눈에 보입니다. "원래보다 +25%"와 "지금보다 −17%"는 둘 다 사실이에요.

근데 문제는 기준점입니다. "영구 인상"의 기준은 부스트가 없던 원래 한도(100)예요. 지금 우리는 그 위에 +50% 부스트가 얹힌 150을 쓰고 있고요. 9/14부터는 100의 125%, 즉 125가 됩니다. 원래(100)와 비교하면 인상이 맞지만, 오늘(150)과 비교하면 감소인 거죠.

산수: 왜 "17% 감소"인가

숫자로 정확히 짚겠습니다. 기준선을 100이라 두면 —

원래 주간 한도      : 100  (부스트 없던 값)
지금(~9/13)         : 150  (원래 + 50% 부스트)
9/14부터(영구)      : 125  (원래 + 25% 인상)

지금 대비 변화 : 125 / 150 = 0.833...  →  약 -17%

"25% 올린다"와 "17% 줄어든다"가 동시에 참인 이유가 여기 있습니다. 기준을 100에 두면 인상, 150에 두면 감소예요. 헤비 유저 입장에서 체감하는 건 후자입니다 — 매주 부스트 한도를 꽉 채워 쓰던 사람은 9/14부터 같은 작업량에서 벽을 더 일찍 만나게 되니까요.

물론 매일 가볍게 쓰는 분은 이 17%가 안 느껴질 수 있습니다. 125도 원래보다 넉넉하거든요. 그래서 "나에게 이게 문제인가"는 감이 아니라 측정으로 답해야 합니다 — 이건 아래에서.

타임라인: 언제 뭐가 바뀌나

▲ 5월에 시작한 부스트의 마지막 여정입니다. 9/13이 +50%로 쓰는 마지막 날.

정리하면 이렇습니다. ~9월 13일: 지금과 동일한 +50% 부스트 유지. 9월 14일: 영구 +25%로 전환. 즉 당장 이번 주에 뭐가 줄어드는 건 아니에요. 2주 남았습니다. 이 2주가 "허둥대며 맞을지, 준비하고 맞을지"를 가르는 시간이고요.

하나 안심되는 점 — 5시간 세션 한도는 이번 변화와 무관합니다. 5월에 영구 적용된 5시간 단위 2배·피크 스로틀 제거는 그대로예요. 이번에 손대는 건 오직 "일주일 총량"입니다. 5시간 윈도우의 체감은 9/14 전후로 동일합니다.

지금(D-13) 할 일 ①: 내 소모부터 재세요

가장 먼저, /usage로 이번 주 주간 소모율을 확인하세요. 타이밍이 중요합니다 — 부스트가 살아 있는 지금 "150 중 몇 %를 쓰는지" 재두면, 9/14 이후(125) 내 위치가 바로 계산되거든요.

기준은 이렇게 잡으면 됩니다. 지금 주간 소모가 80% 이하(150 기준)면 9/14 이후에도 125 안에 들어오니 대응이 거의 필요 없습니다. 83%를 넘나든다면 딱 전환선이라, 아래 절약 습관을 미리 들여두는 게 좋아요. 매주 한도 경고를 보는 분이라면 지금이 플랜·API 전환을 저울질할 시점입니다.

여러분은 지금 /usage에 몇 %로 찍히나요? 그 숫자 하나면 아래 대응의 수위가 정해집니다. 저는 이 글 쓰면서 재봤더니 부스트 한도의 절반쯤이라, 솔직히 저는 무대응 그룹이었어요. 근데 그걸 "재보고 안" 것과 "그러겠지 하고 넘긴" 것은 다르죠.

지금 할 일 ②~④: 습관 세 가지

▲ 위에서 아래로 순서대로. 플랜 업그레이드는 맨 마지막 카드입니다.

② effort 낮추기. Opus 5의 effort 다이얼(사용 가이드)이 정확히 이럴 때 쓰는 도구예요. 커밋 메시지·요약·뻔한 수정을 medium 이하로 내리면 소모가 눈에 띄게 줍니다. 2주 동안 습관으로 굳혀두면 전환일이 와도 티가 안 나요.

③ 모델 라우팅. 사람이 마주 앉는 어려운 작업은 상위 모델, 기계적 반복은 Sonnet 5로 내리는 기준(그 정리) 그대로입니다. 습관적으로 전부 최상위 모델로 돌리고 있었다면 여기서 새는 양이 제일 큽니다.

④ 클라우드 세션 정리. 웹·모바일에 걸어두고 잊은 세션도 같은 주간 주머니를 씁니다. "병렬로 여러 개 걸어두는 게 습관"이 된 분이라면 방치 세션부터 점검하세요. 이 셋은 전환이 없더라도 그냥 이득인 습관이라, 준비가 헛수고가 될 일은 없습니다.

그래도 매주 막힌다면: 플랜 vs API

습관을 다 들였는데도 매주 벽을 만난다면, 그때가 구조를 바꿀 시점입니다. 순서는 effort·라우팅으로 2주 → 그래도 반복이면 플랜 검토예요. 습관 개선 없이 플랜만 올리면 같은 문제를 더 비싸게 만나거든요.

검토할 땐 "Max로 올릴까"만이 아니라 "구독 대신 API 종량으로 돌릴까"도 같이 저울에 올리세요. 어느 쪽이 싼지는 하루 요청 수에 따라 갈립니다 — AI 구독 vs API 비용 계산기에 넣으면 손익분기가 바로 나옵니다. 참고로 Sonnet 5 API는 $2/$10이 영구화돼서(9월 인상은 취소됐죠) 종량 쪽 계산이 이전보다 유리해졌어요.

자주 묻는 질문 (FAQ)

Q. 결국 한도가 늘어난 건가요, 줄어든 건가요?

A. 둘 다 사실입니다. 부스트가 없던 원래 한도(100)와 비교하면 25% 인상이고, 지금 쓰고 있는 부스트 한도(150)와 비교하면 약 17% 감소입니다. 매주 부스트 한도를 꽉 채워 쓰던 헤비 유저는 감소로 체감합니다.

Q. 언제부터 바뀌나요?

A. 9월 13일까지는 현재의 +50% 부스트가 그대로 유지되고, 9월 14일부터 영구 +25%로 전환됩니다. 이번 주에 당장 줄어드는 건 아닙니다.

Q. 5시간 세션 한도도 줄어드나요?

A. 아니요. 이번 변화는 주간 총량에만 적용됩니다. 5시간 단위 한도(5월 영구 적용분)는 그대로라, 세션 안에서의 체감은 전후가 동일합니다.

Q. 제 플랜도 대상인가요?

A. Pro·Max·Team, 그리고 시트 기반 Enterprise가 대상입니다. 실제 소진 속도는 대화 길이·모델·도구 사용·effort에 따라 달라지므로, 고정된 "프롬프트 몇 개"로 환산되지는 않습니다.

오늘의 결론

9/14부터 Claude Code 주간 한도 = 원래 대비 +25%(영구), 그러나 지금 대비 약 −17%. 부스트는 9/13까지 그대로, 5시간 한도는 불변. 남은 2주에 할 일: /usage로 내 위치 측정 → effort 하향 → 모델 라우팅 → 세션 정리, 그래도 막히면 플랜·API 검토. 저는 "인상"이라는 단어에 안심하고 넘길 뻔했는데, 기준점을 바꿔 보니 이야기가 달라지더군요. 숫자를 읽을 땐 늘 "무엇과 비교한 건가"를 먼저 봐야 한다는 걸 이번에도 배웁니다.

참고 자료

Claude 공식 요금
Claude 공식 지원 센터 (한도 안내)

AI로 도구 하나 만들었더니 — 코딩보다 '데이터 찾기'가 더 오래 걸렸다 (제작기)

DevPilot — Sun, 30 Aug 2026 17:28:47 +0900

핵심 요약: 주말에 작은 웹 도구를 하나 만들었습니다 — 태어난 해를 넣으면 "한국에서 나이순 몇 번째인지, 동갑은 몇 명인지" 알려주는 계산기예요(내 나이 순위). Claude Code로 만들었는데, 의외였던 건 시간 배분이었어요 — 코딩은 금방이었고, "믿을 만한 공공데이터를 찾고 검증하는 데" 훨씬 오래 걸렸습니다. AI 시대의 개발이 어디로 옮겨가는지 딱 보여주는 경험이었어요: 만드는 건 쉬워졌고, "무엇을·어떤 근거로 만들 것인가"의 비중이 커졌습니다. 이 글은 그 제작 과정과, 데이터를 다루며 내린 정직한 결정 몇 가지를 정리한 기록입니다.

※ 이 글은 2026년 8월 31일 기준의 실제 제작 기록입니다. 도구는 배포 완료 상태입니다.

요즘 "AI로 앱 만들었다"는 글이 많죠. 대부분 "이 프롬프트로 5분 만에!"인데, 저는 반대 얘기를 하려고 합니다 — 코딩이 빨라질수록, 코딩 아닌 부분이 병목이 됩니다. 이번 도구가 딱 그랬어요.

뭘 만들었나: "나 몇 번째로 나이 많지?"

아이디어는 단순했습니다. 다들 자기 나이를 실제보다 젊게 짐작하잖아요 — "서른이면 아직 젊지"라고요. 그런데 한국인 중위 연령이 47세라, 서른은 이미 아래에서 4분의 1 지점입니다. 이 반전을 숫자로 보여주는 도구예요. 태어난 해만 넣으면 나보다 나이 많은 사람 수, 동갑 수, 상위 몇 %가 나옵니다.

▲ 실제 도구 화면입니다. 브라우저 안에서만 계산되고 입력값은 저장·전송되지 않아요.

코딩은 금방이었다

Claude Code로 만들었는데, 계산 로직 자체는 간단합니다 — 연령별 인구 배열을 놓고 누적합으로 순위를 내는 거예요. UI(입력창, 결과 문구, 복사 버튼)도 금방 나왔고요. 솔직히 "코드"만 보면 반나절도 안 걸릴 물건입니다.

AI 코딩 도구를 쓰면 이 부분이 정말 빨라져요. 로직 짜고, 엣지케이스(생일 안 지난 경우) 처리하고, 반응형 붙이는 건 지시만 명확하면 순식간입니다. 그래서 시간을 잡아먹은 건 여기가 아니었어요.

진짜 오래 걸린 것: 믿을 만한 데이터 찾기

도구의 핵심은 "어떤 인구 데이터를 쓰느냐"입니다. 숫자가 틀리면 도구 전체가 거짓말이 되니까요. 여기서 시간이 갔습니다.

▲ 체감 시간 배분입니다. 만드는 것보다 "무엇으로 만들지"에 훨씬 오래.

확인해야 할 것들이 많았어요 — 어떤 기관의 통계가 1세 단위로 제공되나(대부분 5세 구간이라 순위 계산이 부정확해짐), 언제 기준인가, 갱신 주기는, 그리고 등록구분(내국인/외국인/재외국민)을 어떻게 잡을 것인가. 최종적으로 행정안전부 주민등록 인구통계의 1세 단위 자료(전국, 등록구분 전체, 2026년 7월)를 골랐습니다.

그리고 마지막에 검증을 하나 했어요 — 101개 연령값(0세~100세 이상)의 합이 공표된 총인구와 일치하는지. 맞았습니다(51,088,284명). 이걸 확인 안 하면 어딘가 값이 새도 모르거든요. 이 검증에 AI를 쓰는 게 딱 좋았어요 — 지루한 합산·대조를 시키기에.

정직한 결정들: 안 쓴 것들의 이유

도구를 만들다 보면 "더 극적인 표현"의 유혹이 있습니다. 저는 몇 개를 일부러 안 썼어요.

▲ 세 가지를 일부러 뺐습니다. 자극적이지만 사실을 왜곡하는 표현들이라서요.

① "그 해 태어난 사람 중 몇 명이 살아있나"를 안 씀. 훨씬 자극적이지만 부정확합니다. 출생아 수와 현재 그 나이 인구의 차이엔 사망만이 아니라 이민·귀화·국적상실·재외국민 변동이 다 섞여 있어서, 생존율처럼 말하면 거짓이 돼요. 1970년 이전 출생 통계는 신뢰도도 낮고요.

② 동갑은 "무리의 한가운데"로 계산. 같은 나이끼리는 누가 먼저인지 알 수 없으니, 정확한 등수 대신 대략적 위치로 표시했습니다. 있는 척하지 않는 게 맞다고 봤어요.

③ 외국인은 빠진다고 명시. 주민등록 기준이라 국내 거주 외국인은 빠지고, 해외 재외국민은 포함됩니다. 그래서 "한국에 사는 사람"이 아니라 "주민등록된 한국인"의 순위라고 도구에 적어뒀어요.

이런 건 코드가 아니라 판단입니다. AI가 코드는 빨리 짜주지만, "이 표현이 사실을 왜곡하나?"는 사람이 결정할 몫이에요. 지난주 XSS 후기(그 글)에서 얻은 교훈과 정확히 같은 자리예요 — AI는 코드 안, 사람은 코드 밖.

이번 제작에서 배운 것

정리하면 — AI 코딩 시대의 개발은 무게중심이 옮겨갑니다. "어떻게 짜지?"는 도구가 대부분 답해주고, "무엇을, 어떤 근거로, 어디까지 정직하게 만들 것인가"가 사람의 일로 남아요. 이번 도구도 코드 줄 수로는 얼마 안 되지만, 그 뒤에 데이터 출처 검증과 표현의 정직성에 대한 결정이 깔려 있습니다.

바이브 코딩(그 개념)이 "말로 만든다"는 뜻이라면, 그 말의 품질이 결과의 품질입니다. 그리고 그 품질은 대개 코드 밖에서 정해져요.

자주 묻는 질문 (FAQ)

Q. AI로 만들면 개발이 정말 빨라지나요?

A. 코딩 자체는 확실히 빨라집니다. 다만 데이터 확보·검증, 설계 결정, 정확성 판단 같은 "코드 아닌 일"의 비중이 상대적으로 커집니다. 전체 시간이 줄긴 하지만, 줄어드는 곳은 주로 타이핑 쪽입니다.

Q. 공공데이터는 어디서 찾나요?

A. 이번엔 행정안전부 주민등록 인구통계를 썼습니다. 통계 도구를 만들 때는 "1세 단위인가, 기준 시점이 명확한가, 갱신되는가, 합계가 맞는가"를 확인하는 게 중요합니다.

Q. AI가 데이터 검증도 해주나요?

A. 지루한 합산·대조 같은 기계적 검증은 잘 시킬 수 있습니다. 다만 "이 데이터를 이렇게 해석해도 되는가"는 사람이 판단해야 합니다. 이번에 생존율 표현을 뺀 것도 그런 판단이었습니다.

정리하면

AI로 도구 하나 = 코딩은 반나절, 데이터 확보·검증·표현 결정이 그보다 오래. Claude Code가 짠 계산 로직 뒤에는 "어떤 통계를, 어떻게 정직하게 쓸 것인가"라는 사람의 결정이 깔려 있습니다. 만드는 게 쉬워질수록 "무엇을 만들 것인가"가 중요해진다 — 이번 주말의 작은 결론입니다. 궁금하면 직접 넣어보세요, 생각보다 순위가 높을 겁니다.

Devin 지시문 템플릿 7종 — 복붙해서 빈칸만 채우면 되는 프롬프트 모음 (2026)

DevPilot — Sun, 30 Aug 2026 17:12:16 +0900

핵심 요약: 어제 글(Devin 잘하는 일 vs 못하는 일)에서 "성공은 지시문 품질이 8할"이라고 했는데, 그 지시문을 복붙해서 빈칸만 채우면 되는 형태로 만들었습니다. Devin이 방황하지 않으려면 지시에 네 가지가 있어야 해요 — ① 무엇을(맥락·재현) ② 어떻게 되어야(기대 결과) ③ 어디를(위치 힌트) ④ 어떻게 확인(검증 방법). 이 네 칸을 작업 유형별로 미리 짜뒀습니다: 버그픽스·테스트 작성·마이그레이션·기능 추가·리팩토링·문서화·CI 설정 7종. 각 템플릿에 "이건 꼭 넣으세요"와 "이건 빼세요"까지 달았어요. 그대로 긁어서 대괄호만 바꾸면 됩니다.

※ 이 템플릿들은 Devin 외에 Claude Code·Cursor의 에이전트 모드에도 그대로 응용됩니다. 자율 에이전트에게 일을 맡기는 공통 문법이라서요.

어제 Devin이 작업 종류를 심하게 탄다고 썼는데, 사실 같은 작업도 지시문에 따라 성공률이 갈립니다. "로그인 고쳐줘"는 실패하고 아래 템플릿을 채운 지시는 12분에 끝나요. 이 글은 그 지시문을 통째로 드립니다.

먼저: 모든 템플릿의 뼈대 (4요소)

유형이 뭐든 자율 에이전트 지시는 이 골격을 따릅니다. 하나라도 비면 그 자리에서 Devin이 추측하고, 추측은 곧 방황(=ACU 낭비)입니다.

▲ 이 네 칸이 채워졌는지만 보면 됩니다. 빈 칸이 곧 실패 지점이에요.

[작업 유형]: (한 줄 요약)
맥락: (배경·현재 상황·관련 파일)
기대: (끝났을 때 어떤 상태여야 하는가)
위치: (건드릴 파일·모듈 힌트 — 알면)
검증: (어떻게 확인하나 — 명령어·테스트)
범위: (이 밖으로는 나가지 말 것)

① 버그픽스 (성공률 78%)

버그: [증상 한 줄]
재현: 1) [단계] 2) [단계] 3) [단계]
기대: [정상이라면 이렇게 동작해야 함]
실제: [지금 이렇게 잘못 동작함]
위치: 아마 [파일/모듈] — 확실하지 않으면 이 줄 삭제
검증: [테스트 명령어 또는 확인 방법]
범위: 이 버그만. 리팩토링·기타 개선은 하지 말 것

꼭: 재현 단계를 번호로. 빼세요: "겸사겸사 이것도" 류의 곁다리 — 토끼굴의 시작입니다.

② 테스트 작성 (성공률 82% — 최고 강점)

대상: [파일/클래스/함수]에 대한 유닛 테스트 작성
커버: 해피패스 + 에러 케이스 + 엣지케이스
      (예: 빈 입력, 경계값, 만료/무효 상태)
목표: 커버리지 [80]% 이상
관례: 기존 테스트는 [경로]에 있음 — 같은 스타일·목킹 패턴 따를 것
검증: [테스트 실행 명령어]로 통과 확인
범위: 테스트만. 대상 코드는 수정하지 말 것

꼭: "기존 테스트 스타일 따르라" — 관례 미스가 Devin의 흔한 약점이라 미리 못박기. 빼세요: "완벽하게" 같은 모호어. 커버리지 숫자로 대체.

③ 마이그레이션 (성공률 70%)

작업: [A]에서 [B]로 마이그레이션
      (예: axios → fetch, moment → date-fns, JS → TS)
범위: [디렉터리/파일 목록] — 여기만
규칙: [유지해야 할 동작·시그니처]
      (예: 함수 반환 형태는 그대로, 공개 API 변경 금지)
검증: [빌드/테스트 명령어] 통과 + 기존 테스트 깨지지 않기
분할: 파일이 많으면 [N]개씩 나눠서, 매 배치 후 멈추고 보고

꼭: "분할" 지시 — 20개 파일 넘으면 재시도가 잦아지니 배치로. 빼세요: "관련된 것도 알아서" — 범위를 흐리면 방황합니다.

④ 기능 추가 (성공률 65%, 명세 또렷할 때만)

기능: [무엇을 추가]
동작: 사용자가 [행동]하면 [결과]가 되어야 함
수용 기준(체크리스트):
  - [ ] [구체 조건 1]
  - [ ] [구체 조건 2]
  - [ ] [엣지케이스 처리]
연결: [영향받는 컴포넌트/파일] 전부 반영할 것
      (예: 다크모드면 사이드바·모달·코드블록까지)
검증: [테스트 또는 수동 확인 절차]
범위: 이 기능만. "마지막 30%"(엣지·마감)까지 포함

꼭: "연결" 항목 — Devin의 "마지막 30% 문제"(누락 컴포넌트)를 지시로 방어. 빼세요: "사용성 개선" 같은 추상 목표. 수용 기준 체크박스로.

⑤ 리팩토링 (성공률 45% — 감독 필수)

대상: [파일/클래스]
목표: [구체적 개선 — "깔끔하게" 금지]
      (예: 500줄 함수를 3개 이하 책임으로 분리)
불변: 외부 동작·공개 시그니처·테스트 결과는 그대로
방법: [원하는 구조가 있으면 명시 — 예: "전략 패턴 말고 단순 함수로"]
검증: 리팩토링 전후 [테스트] 동일 통과
먼저: 계획부터 보여주고, 승인 후 실행할 것

꼭: "먼저 계획" — 리팩토링은 Devin이 과설계로 빠지기 쉬워 계획 검토가 필수. 빼세요: "베스트 프랙티스대로" — 맥락 없는 패턴 적용의 원인.

⑥ 문서화 (성공률 85% — 가장 안전)

대상: [코드베이스/모듈/API]
산출물: [README / API 문서 / 코드 주석 / CHANGELOG]
포함: [설치·사용 예시·파라미터·반환값·에러]
독자: [초보자 / 팀 내부 / 외부 개발자]
형식: [마크다운 / JSDoc / 기존 문서 스타일 따르기]
검증: 예시 코드가 실제로 동작하는지 확인할 것

꼭: "독자" 지정 — 같은 내용도 대상에 따라 깊이가 달라집니다. 빼세요: 특별히 없음. 저위험 작업이라 부담 적어요.

⑦ 환경·CI 설정 (성공률 55%)

작업: [CI 파이프라인 / 개발환경 / Docker 설정]
플랫폼: [GitHub Actions / GitLab CI / 기타]
단계: [린트 → 테스트 → 빌드 → (배포)]
조건: [트리거 — 예: PR 시, main 푸시 시]
비밀: [시크릿은 이름만, 값은 내가 넣음 — 하드코딩 금지]
검증: 워크플로가 통과하는 더미 커밋으로 확인
범위: 설정만. 애플리케이션 코드 변경 금지

꼭: "시크릿 하드코딩 금지" — 보안 무지가 Devin의 약점이라 명시. 빼세요: 배포 자동화를 처음부터 통째로 — 단계별로 나눠 검증.

공통 마무리 문구 (모든 지시 끝에 붙이면 좋은 것)

- 막히거나 확신이 안 서면 진행하지 말고 질문할 것
- 이 지시 범위 밖의 변경은 하지 말 것
- 끝나면 무엇을 바꿨는지 요약해줘

▲ 왼쪽처럼 던지면 실패하고, 오른쪽처럼 채우면 성공합니다. 차이는 5분의 타이핑이에요.

이 세 줄이 토끼굴 방지·범위 이탈 방지·리뷰 편의를 한 번에 잡습니다. 특히 첫 줄("막히면 질문") 하나가 ACU를 가장 많이 아껴줘요 — Devin이 혼자 헤매는 대신 손을 들게 만드니까요.

자주 묻는 질문 (FAQ)

Q. 이 템플릿을 그대로 복붙하면 되나요?

A. 네, 대괄호 부분만 여러분 상황으로 바꾸면 됩니다. 다만 "위치"나 "검증"처럼 모르는 칸이 있으면 비워도 되고, 그럴수록 Devin의 성공률과 속도가 조금씩 떨어진다고 보면 됩니다.

Q. Claude Code나 Cursor에도 쓸 수 있나요?

A. 그대로 응용됩니다. 4요소(맥락·기대·위치·검증)는 자율 에이전트에게 일을 맡기는 공통 문법이라, 도구가 달라도 원리는 같습니다.

Q. 지시를 자세히 쓰는 게 오히려 시간 낭비 아닌가요?

A. 반대입니다. 지시에 5분 더 쓰면 방황·재시도·잘못된 결과물 검토에 드는 30분을 아낍니다. 특히 ACU 종량 과금에서는 이 5분이 직접적인 비용 절감이에요.

정리하면

Devin 지시문 = 맥락·기대·위치·검증 4요소 + 범위 제한 + "막히면 질문". 유형별 템플릿 7종을 복붙용으로 드렸으니, 대괄호만 채워 쓰세요. 어제 글이 "무엇을 시킬까"였다면 오늘은 "어떻게 시킬까"입니다 — 이 둘을 합치면 Devin의 값어치가 확실히 올라가요. 다음엔 실제로 이 템플릿으로 작업을 돌린 기록을 가져오겠습니다.

Devin으로 뭘 시킬 수 있나 — 잘하는 일 vs 못하는 일, 실측 성공률로 정리 (2026)

DevPilot — Sun, 30 Aug 2026 01:48:33 +0900

핵심 요약: "Devin으로 뭘 할 수 있나"에 정면으로 답합니다. Devin은 만능 개발자가 아니라 "작업 종류를 심하게 타는" 자율 에이전트예요. 실측 데이터로 보면 명확합니다 — 잘하는 것: 테스트 작성(성공률 82%)·문서화(85%)·명확한 버그픽스(78%)·코드 마이그레이션(70%)·보일러플레이트. 못하는 것: 새 아키텍처 설계(15%)·모호한 기능(25%)·의미 있는 리팩토링(45%)·복잡한 디버깅. 한 줄로 요약하면 — "명세가 또렷하고 반복적인 잡무"엔 강하고, "판단과 설계가 필요한 일"엔 약합니다. 그래서 Devin을 잘 쓰는 핵심은 도구가 아니라 일을 어떻게 쪼개서 시키느냐예요. 아래에 작업별 성공률 표, 실전 사례, "ACU 아끼는 지시문 쓰는 법"까지 정리했습니다.

※ 이 글은 2026년 8월 30일 기준이며, 인용한 성공률은 여러 실사용 리뷰의 테스트 결과입니다(환경에 따라 달라질 수 있음). 원출처는 글 끝에.

Devin 관련 글을 여러 편 썼는데(Devin이란?, ACU 요금) 정작 제일 많이 검색되는 질문엔 답을 안 했더라고요 — "그래서 이걸로 뭘 시키지?" 오늘은 그 얘깁니다.

결론부터: 작업 종류가 전부다

Devin의 성능은 "얼마나 똑똑한가"보다 "어떤 종류의 일인가"에 훨씬 크게 좌우됩니다. 같은 도구인데 작업에 따라 성공률이 15%에서 85%까지 벌어져요. 실사용 테스트를 종합한 표입니다.

작업 유형	성공률	평균 소요	개입 횟수
문서화 (README·API 문서)	85%	10분	0~1
테스트 작성	82%	20분	0~1
버그픽스 (재현 명확)	78%	15분	0~1
코드 마이그레이션	70%	25분	1
기능 추가 (명세 또렷)	65%	30분	1~2
CI/CD 설정	55%	35분	2~3
리팩토링	45%	40분	2~3
버그픽스 (모호)	35%	45분	2~4
기능 추가 (모호)	25%	60분+	3~5
새 아키텍처 설계	15%	90분+	5+

▲ 위쪽 초록이 맡겨도 되는 일, 아래쪽 빨강이 사람이 해야 하는 일입니다. 경계선이 뚜렷해요.

잘하는 일: 명세가 또렷하고 반복적인 것

테스트 작성이 Devin의 최고 강점입니다(82%). 공개 메서드를 전부 훑어 해피패스·에러·엣지케이스(만료 토큰, 잘못된 자격증명)까지 24개 테스트로 커버율 86%를 달성한 사례가 있어요. 테스트는 패턴이 정해져 있어서 Devin의 성격에 잘 맞습니다.

명확한 버그픽스도 스윗스팟이에요. "페이지 넘길 때 중복 결과가 나온다, API 계층 문제"라는 지시에 — 누락된 OFFSET + 커서 페이지네이션 오류를 찾아 SQL 수정, 엣지케이스 테스트 추가, 깔끔한 PR까지 12분에 마쳤습니다. 개입 0회. 재현이 명확하고 위치가 특정되고 범위가 좁으면 사람보다 빠릅니다.

그 외 마이그레이션(라이브러리 교체·API 버전 업), 보일러플레이트(CRUD 엔드포인트, DB 모델), 문서화가 모두 강점 구간입니다. 공통점은 하나 — "창의적 판단"이 아니라 "패턴 반복"이라는 것.

못하는 일: 판단과 설계가 필요한 것

반대쪽은 명확한 약점입니다. 1,800줄 OrderProcessor 클래스를 SRP로 리팩토링하라는 테스트에서 Devin은 메서드를 새 파일로 옮기긴 했는데 — 관심사 분리가 피상적이었고, 불필요한 간접 계층만 늘려 오히려 더 나쁜 구조가 됐어요. 작성한 테스트도 실제 동작을 검증 못 하는 껍데기 목이었고요. Devin은 "이 패턴이 이 맥락에 맞는가"를 판단하지 못합니다.

▲ 특히 이 세 함정을 기억하세요. 비용과 직결됩니다.

기억할 함정 셋 — ① 토끼굴 문제: 예상 못 한 에러를 만나면 물러서서 접근을 재고하는 대신, 점점 복잡한 "수정"을 쌓아 상황을 악화시킵니다(ACU 낭비의 주범). ② 마지막 30% 문제: 기능의 핵심 70%는 만들지만 엣지케이스·에러처리·UI 마감·통합은 미완인 채 끝나는 경우가 잦아요. ③ 보안 무지: SQL 인젝션·XSS를 인지 못 하고 그냥 만들 수 있습니다 — 지난주 제 사이트에서 XSS 3건이 나온 것도(그 후기) 같은 맥락이죠. Devin PR은 주니어 PR처럼 반드시 리뷰해야 합니다.

그래서 잘 쓰는 법: 지시문이 8할이다

Devin 성공의 가장 큰 변수는 도구 성능이 아니라 지시문의 품질입니다. 같은 버그도 이렇게 갈려요.

나쁜 지시: "로그인 페이지 고쳐줘"

좋은 지시:
버그: 올바른 이메일/비번인데도 "Invalid credentials" 표시
재현: 1) /login 접속 2) test@example.com / TestPass123 입력 3) 제출
기대: /dashboard로 이동
실제: "Invalid credentials" 에러
위치: 아마 api/auth/login.ts
검증: "npm test -- --grep auth"로 확인

여기에 ACU까지 아끼려면 실전 요령 넷 — ① 관련 파일을 콕 집어주기(맥락이 많을수록 방황이 줄어듦), ② 초반에 점검(계획과 첫 몇 분을 보고 방향이 틀렸으면 바로 잡기 — 완성 후 갈아엎는 것보다 훨씬 쌈), ③ 비슷한 작업은 묶어서("이 10개 엔드포인트에 에러처리 추가"처럼 — 세션 내에서 패턴을 학습함), ④ 범위 상한 걸기("이 범위 밖이면 멈추고 물어봐"). ACU 절약 원리는 ACU 가이드에 더 있습니다.

정리: 언제 쓰고, 언제 안 쓰나

쓰기 좋은 때 — 명확한 티켓 백로그가 쌓였을 때, 테스트·마이그레이션·보일러플레이트 위주일 때, 병렬로 잡무를 돌리고 싶을 때, 코드 리뷰 프로세스가 탄탄할 때. 피할 때 — 요구사항이 모호할 때, 아키텍처·시스템 설계가 필요할 때, 도메인 전문지식(금융 규제·의료 데이터)이 필요할 때, 코드베이스가 관례가 많고 특이할 때, 보안이 치명적인데 리뷰 여력이 없을 때.

한 줄로 — Devin은 "잠 안 자는 유능한 주니어"입니다. 시니어를 대체하는 게 아니라, 중요하지만 지적으로 어렵지 않은 일을 떠맡아 팀을 증강하는 도구예요. 이 기대치만 맞추면 값어치를 합니다.

자주 묻는 질문 (FAQ)

Q. Devin에게 처음 뭘 시켜보면 좋나요?

A. 성공률이 높고 위험이 낮은 것부터 — 기존 코드의 테스트 작성, README·API 문서 생성, 재현이 명확한 버그픽스입니다. 이 세 가지로 감을 잡은 뒤 점점 범위를 넓히는 게 실패를 줄이는 순서예요.

Q. 복잡한 기능도 시킬 수 있나요?

A. 통째로는 권하지 않습니다. 대신 큰 기능을 명세가 또렷한 작은 조각(엔드포인트 하나, 컴포넌트 하나)으로 쪼개면 성공률이 올라갑니다. "마지막 30%"는 사람이 마무리한다고 처음부터 계획하세요.

Q. Devin 결과물을 바로 배포해도 되나요?

A. 안 됩니다. 보안 취약점·엣지케이스·프로젝트 관례를 놓칠 수 있어 반드시 사람 리뷰 후 머지하세요. 주니어 개발자의 PR을 다루듯 검토하는 것이 원칙입니다.

정리하면

Devin은 작업을 심하게 타는 도구 = 잘하는 것(테스트·문서·명확한 버그픽스·마이그레이션)과 못하는 것(아키텍처·모호한 요구·복잡한 디버깅)이 성공률로 뚜렷이 갈립니다. 잘 쓰는 핵심은 또렷한 지시문 + 작은 범위 + 사람 리뷰. 저는 Devin을 "만능 개발자"로 기대했다가 실망하는 분을 여럿 봤는데, "유능한 주니어"로 기대를 맞추면 이야기가 달라져요. 다음엔 실제 지시문 템플릿 모음으로 이어가겠습니다.

참고 자료

Devin 실사용 테스트·한계 리뷰 (Idlen)
Devin이 실제로 내놓는 것 (DeepFounder)

스캐너가 못 잡은 그 버그, 사람이 이렇게 고쳤다 — "+124% 절감"의 정체 (실전 후기 2)

DevPilot — Sat, 29 Aug 2026 21:51:28 +0900

핵심 요약: 어제 글(XSS 3건 후기)에서 예고한 그 버그를 고쳤습니다. 이미지 압축 도구에서 19KB 파일이 43KB로 커졌는데 화면엔 "+124% 절감"이라고 뜨던 문제요. 원인을 파보니 계산 자체는 멀쩡했고 — 결과가 원본보다 클 때(음수%)의 표시 처리가 부호만 뒤집고 "증가/절감" 라벨을 안 붙이던 것이 진짜 문제였습니다. 게다가 세 도구(압축·변환·리사이즈)의 표시 로직이 제각각이었어요 — 변환 도구만 "커짐"을 제대로 표시하고 있었죠. 그래서 표시 라벨을 공용 헬퍼 하나로 통일했습니다("N% 절감"·"N% 증가"·"변화 없음"). 보안 스캐너는 이걸 못 잡습니다. 취약점이 아니니까요. 오늘은 "사람이 코드 밖에서 잡은 결함을, 어떻게 코드 안으로 들어가 고치는가"의 기록입니다.

※ 이 글은 2026년 8월 29일의 실제 수정 기록입니다. 관련 배포는 완료됐습니다.

이 글은 어제 글의 나머지 절반입니다. 어제는 보안 스캐너(Claude Security)가 내 코드의 XSS 3건을 잡아낸 이야기였고, 오늘은 그 스캐너가 관심조차 없던 버그를 사람이 어떻게 처리했는지예요.

다시 보는 증상: 커졌는데 "절감"

발단은 어제의 재현 과정이었습니다. 패치를 검증하려고 평범한 이미지(PNG를 JPEG로)를 하나 압축했는데, 결과가 원본보다 커졌어요 — 그런데 화면엔 "+124% 절감"이 떴습니다.

▲ 어제의 그 화면. 43KB로 늘었는데 "+124%"라는 숫자만 있고, 늘었다는 말이 없습니다.

PNG를 JPEG로 바꾸면 커지는 건 사실 정상입니다 — 색이 단순한 그래픽·스크린샷 계열은 JPEG가 오히려 손해예요(그래서 저희 도구 설명에도 "이미 압축된 사진은 오히려 늘 수 있다"고 적혀 있고요). 즉 동작은 맞았고, 그 사실을 전달하는 화면이 틀린 겁니다.

진단: 부호는 뒤집는데, 말은 안 바꾼다

코드를 열어보니 계산 함수는 이랬습니다. 원본보다 커지면 음수를 반환하도록 정확히 설계돼 있었어요.

// 감소율(%) 계산. 늘어난 경우 음수
reductionPct(before, after) → Math.round((before - after) / before * 100)
// 19KB → 43KB 면: (19-43)/19 ≈ -126%

문제는 이 음수를 화면에 뿌리는 쪽이었습니다. 대략 이런 코드였어요 — pct > 0 ? '-'+pct : '+'+절댓값. 즉 커졌을 때(음수) +126%로 부호만 바꿔 보여주고, "증가"인지 "절감"인지 단어를 안 붙였습니다. 숫자만 덩그러니. 사용자 눈엔 "+124%"가 좋은 건지 나쁜 건지 알 길이 없죠.

▲ 버그의 위치. 계산이 아니라 "번역"에서 났습니다. 숫자를 사람 말로 옮기는 그 한 칸에서요.

진짜 원인: 세 도구가 제각각이었다

더 파보니 이게 단순 오타가 아니라 구조 문제였어요. 같은 계산 함수를 쓰는 세 도구의 표시 코드가 전부 조금씩 달랐습니다.

이미지 변환 — 상태줄은 "N% 커짐"을 제대로 표시하고 있었음(잘된 사례!). 근데 표 셀은 라벨 없음.
이미지 압축 — 표 셀도 상태줄도 "증가" 처리 없음. 상태줄은 커지면 아예 "변화 없음"으로 잘못 표기.
이미지 리사이즈 — 애초에 이 계산을 안 씀(크기 비교가 무의미하니 정상).

같은 개념을 세 군데서 따로 구현하다 보니 각자 다른 실수를 한 겁니다. 어제 XSS도 정확히 같은 병이었어요 — 안전한 도구 두 개, 위험한 도구 세 개가 한 저장소에 공존했죠. 결함은 코드가 아니라 일관성의 부재에서 나옵니다.

수정: 한 곳에서 결정하게 한다

그래서 개별 파일을 손보는 대신, 표시 규칙을 공용 함수 하나로 뽑았습니다. 퍼센트를 넣으면 "무슨 말과 무슨 색으로 보여줄지"를 한 곳에서 결정하게요.

sizeDeltaLabel(pct):
  pct > 0 → { "N% 절감", 초록 }
  pct < 0 → { "N% 증가", 빨강 }   // ← 예전엔 여기가 비어 있었다
  0       → { "변화 없음", 회색 }

그리고 압축·변환 도구의 표 셀과 상태줄이 전부 이 함수를 부르도록 바꿨습니다. 3개 파일, 16줄 추가·5줄 삭제. 이제 어디서 표시하든 "커지면 빨간 글씨로 '증가'"가 한 번만 정의되고 모두가 따릅니다. 다음에 이미지 도구를 하나 더 만들어도 같은 실수를 반복할 수 없어요.

▲ 수정 후. 같은 상황에서 이제 "증가"라고, 그것도 경고색으로 알려줍니다. 정직한 화면이 됐어요.

스캐너와 사람의 경계선, 다시

이 버그를 두 도구가 어떻게 대하는지 나란히 보면 재밌습니다. 보안 스캐너는 이걸 못 봅니다 — 데이터가 새는 것도, 코드가 깨지는 것도 아니니 스캐너의 정의상 "결함"이 아니에요. 린터·타입 체커도 못 잡습니다 — 문법은 완벽하고 타입도 맞으니까요. 테스트도 (있었더라도) 못 잡았을 겁니다 — "커지면 뭐라고 표시해야 하는가"는 애초에 아무도 명세하지 않은 요구사항이라, 그걸 검사하는 테스트가 존재할 리 없죠.

이 버그를 잡을 수 있는 건 화면을 실제로 보고 "어? 이 숫자 이상한데"라고 느끼는 사람뿐이었습니다. 코드 안에는 이상 신호가 없었어요. 이상은 화면과 상식 사이에 있었습니다.

지지난주부터 이어온 이야기(코드 리뷰 글)의 결론이 여기서 완성됩니다 — AI는 코드 안을 보고, 사람은 코드 밖을 본다. 어제는 코드 안(XSS)을 기계가 잡았고, 오늘은 코드 밖(말이 안 되는 표시)을 사람이 잡았어요. 좋은 개발 워크플로는 둘 중 하나를 고르는 게 아니라, 둘을 각자의 자리에 놓는 겁니다.

자주 묻는 질문 (FAQ)

Q. 이런 버그는 왜 자동 도구로 못 잡나요?

A. 보안 스캐너·린터·타입 체커는 "코드가 규칙을 어겼는가"를 봅니다. 그런데 이건 코드가 규칙을 다 지켰는데도 결과가 사용자에게 말이 안 되는 경우예요. "커진 걸 절감이라 부르면 안 된다"는 건 코드 규칙이 아니라 상식이라, 사람이 화면을 봐야 드러납니다.

Q. 왜 개별 파일을 고치지 않고 공용 함수로 뺐나요?

A. 버그의 근본 원인이 "같은 로직의 중복 구현"이었기 때문입니다. 세 곳을 각각 고치면 당장은 되지만 다음에 또 갈라집니다. 한 곳에서 결정하게 하면 재발이 구조적으로 막힙니다. 어제 XSS도 같은 교훈이었어요.

Q. AI 코딩 도구는 이 수정에 안 썼나요?

A. 진단과 수정 방향은 사람이 정했고, 반복적인 코드 변경 적용에는 도구를 활용했습니다. 이 블로그의 원칙 그대로 — 판단은 사람, 실행은 도구입니다(워크플로 글).

정리하면

"+124% 절감" 버그 = 계산은 정상(음수 반환), 표시가 부호만 바꾸고 라벨을 안 붙인 것 + 세 도구의 로직이 제각각. 공용 헬퍼 하나로 통일해 "증가/절감/변화 없음"을 한 곳에서 결정하게 수정·배포했습니다. 자동 도구는 못 잡고 사람만 잡는 결함이 있다는 것 — 이게 이틀에 걸친 실험의 결론입니다. 다음엔 또 다른 실전 기록으로 찾아올게요.

Claude Security로 내 서비스를 스캔했더니 — 진짜 XSS 3건이 나왔다 (실전 후기)

DevPilot — Thu, 27 Aug 2026 13:59:39 +0900

핵심 요약: 어제 소개한 Claude Security 플러그인을 말로만 두기 아까워서, 제가 운영하는 실서비스에 직접 돌렸습니다. 결과가 예상보다 셌어요 — 이미지 도구 세 곳에서 진짜 XSS 3건이 나왔거든요(파일명을 이스케이프 없이 innerHTML에 넣던 DOM 기반 XSS). 게다가 오탐 0건, 전부 검증 패널 만장일치. 실측도 남겼습니다: 87개 파일 스캔에 9분 26초, 토큰 약 120만, 주간 한도 24% 소모, 세션 비용 $8.76. 스캐너가 만든 패치를 검증하고 배포까지 마쳤고 — 그 과정에서 스캐너는 못 잡는 버그를 사람인 제가 하나 더 발견했습니다. 그게 오히려 이 글의 진짜 포인트예요. 캡처와 함께 전 과정을 공개합니다.

※ 이 글은 2026년 8월 28일의 실제 실행 기록입니다. 발견된 취약점은 모두 수정·배포를 마친 뒤에 공개합니다.

도구 소개 글을 쓰고 나면 늘 찜찜합니다 — "그래서 실제로 쓸 만한가?"에 답을 안 했으니까요. 그래서 이번엔 순서를 바꿨습니다. 어제 글을 쓰자마자, 제가 운영하는 유틸 사이트 저장소에 바로 스캔을 걸었어요.

스캔: 명령 하나, 확인 한 번

절차는 어제 정리한 그대로였습니다. /claude-security → Scan codebase → 범위 선택. 87개 파일짜리 소형 저장소라 "전체 스캔, medium 강도, 저렴함"으로 떴고, 확인을 누르니 에이전트 팀이 움직이기 시작했어요.

▲ 범위 선택 화면. 파일 수와 상대 비용까지 알려줘서 판단이 쉬웠습니다.

인벤토리 → 위협 모델 → 컴포넌트별 조사 → 넓은 스윕 → 세 관점 검증 패널. 진행 상황이 실시간으로 뜨고, 창만 열어두면 자리를 비워도 됐습니다. 9분 26초 뒤에 끝났어요.

결과: MEDIUM XSS 3건, 오탐 0

보고서를 열자 같은 패턴 3건이 나란히 있었습니다 — 이미지 압축·변환·리사이즈 도구. 전부 DOM 기반 XSS였어요. 사용자가 고른 파일의 이름(File.name)을 이스케이프 없이 결과 테이블의 innerHTML에 그대로 넣던 코드였습니다.

▲ 세 건 모두 MEDIUM·HIGH 신뢰도, 검증 패널 만장일치. 오탐이 없어서 보고서가 짧고 읽혔습니다.

공격 시나리오도 구체적으로 적혀 있었습니다 — 파일명이 x"><img src=x onerror=alert(document.domain)>.jpg인 이미지를 사용자가 그 도구에 넣으면, 결과 테이블이 그려질 때 사이트 원본에서 임의 JS가 실행됩니다. 인상 깊었던 건 스캐너가 같은 저장소의 다른 도구 두 개(PDF 병합, JPG→PDF)는 이미 안전하게 처리하고 있다는 것까지 짚어준 점이에요 — "고치는 방법은 저기 이미 있는 그 패턴"이라고요.

재현: 진짜였다

보고서를 믿기 전에 직접 확인했습니다. 로컬 개발 서버를 띄우고, 문제의 파일명을 붙인 이미지를 압축 도구에 넣었더니 —

▲ 팝업이 떴습니다. 보고서가 맞았어요. 이 순간이 좀 서늘했습니다 — 이게 배포돼 있었으니까.

실제로 위험한 시나리오는 아니라고 스스로를 위로할 수도 있었습니다("누가 파일명을 저렇게 지어서 올려?"). 그런데 공유 링크·자동화·타인이 만든 파일을 다루는 순간 이야기가 달라지죠. 낮은 확률이라도 임의 JS 실행은 임의 JS 실행입니다.

패치: 만들어주되, 적용은 내가

"Suggest patches"를 골랐더니 항목마다 패치 생성 에이전트와 검증 에이전트가 따로 돌았습니다. 생성 에이전트가 스크래치 사본에서 수정을 만들고, 다른 에이전트가 그 diff를 독립적으로 리뷰하는 구조예요.

▲ 작성자와 리뷰어가 다른 에이전트. 지난주 글(코드 리뷰 이야기)에서 말한 원칙이 그대로 구현돼 있었습니다.

수정 자체는 한 줄짜리였습니다 — 파일명 셀을 innerHTML 대신 textContent로 채우고, 사용자가 조작할 수 없는 숫자 값(크기·비율)만 따로 삽입. 검증 노트가 정직했던 게 마음에 들었어요: "이 저장소엔 테스트 스위트가 없어서, 동작 불변은 실행 테스트가 아니라 코드 리뷰와 빌드 성공 기반"이라고 한계를 명시했습니다. AI 도구가 자기 검증의 빈틈을 스스로 적어두는 건 흔치 않죠.

적용은 제 몫이었습니다. 브랜치 만들고 git apply로 패치 3개 적용 → 빌드 통과(39페이지) → 아까 그 파일로 재확인.

▲ 같은 파일, 이번엔 팝업이 없습니다. 파일명이 잘리지 않고 통째로 "글자"로 표시됐어요 — textContent가 먹었다는 뜻입니다.

머지하고 배포까지 마쳤습니다. XSS 3건, 처리 완료.

비용: 스캔 한 번에 얼마나 쓰나

제일 궁금하실 숫자죠. /usage로 확인한 이번 작업의 실측입니다.

▲ 스캔 + 패치 한 사이클의 실측. 소형 저장소인데도 적지 않게 씁니다.

정리하면 — 파일 87개 / 소요 9분 26초 / 토큰 약 120만 / 세션 비용 $8.76 / 주간 한도의 24% 소모(마침 +50% 부스트가 8/31까지 살아있는 기간이라 체감이 덜했습니다). 멀티에이전트가 병렬로 도니 소형 저장소도 이 정도예요. "매일 CI에서 자동으로"보다는 "의미 있는 변경 때 수동으로"가 맞는 비용 감각입니다. 대형 저장소는 영역별로 쪼개 돌리라는 공식 권장이 이해됐어요.

진짜 결론: 스캐너가 못 잡은 걸 내가 잡았다

여기서부터가 이 글을 쓰는 이유입니다. 패치를 검증하려고 로컬에서 정상 이미지(PNG를 JPEG로)를 하나 압축해봤는데 — 결과가 19KB → 43KB로 커졌는데 화면엔 "+124% 절감"이라고 떴습니다. 줄어든 게 아니라 늘었는데 "절감"이라뇨.

이건 취약점이 아니라 표시 로직 버그입니다. PNG를 JPEG로 재인코딩하면 커지는 건 흔한 일이라(플랫한 그래픽·스크린샷 계열) 로직 자체는 정상 동작한 거고, 결과가 원본보다 클 때의 라벨·부호 처리가 틀린 거예요. 그런데 — Claude Security는 이걸 못 잡습니다. 보안 취약점이 아니니까요. 스캐너의 관심 밖입니다.

지난주에 "AI는 코드 안을 보고, 사람은 코드 밖을 본다"고 썼는데(그 글), 오늘 그걸 제 손으로 겪었습니다. XSS 3건은 기계가 코드 안에서 정확히 찾아냈고, "+124%가 이상하다"는 화면을 눈으로 보고 위화감을 느낀 사람이 잡았어요. 둘은 다른 종류의 결함이고, 다른 종류의 관찰자가 필요합니다.

그래서 이 UX 버그는 다음 글에서 고칩니다 — "스캐너가 못 잡은 걸 사람이 어떻게 잡고 고치는가"로요. 오늘은 여기까지가 정직한 기록입니다.

자주 묻는 질문 (FAQ)

Q. 실서비스에 돌려도 안전한가요?

A. 스캔은 로컬 세션에서 코드를 읽기만 하고, 결과 폴더 외에는 저장소를 건드리지 않습니다. 패치도 스크래치 사본에서 만들어 자동 적용되지 않고요. 다만 발견된 취약점 상세는 고치기 전까지 공개하지 마세요 — 공격 힌트가 됩니다. 이 글도 배포 완료 후에 씁니다.

Q. 스캔 결과 폴더를 커밋해도 되나요?

A. 기본적으로 폴더에 자체 .gitignore가 들어 있어 커밋에서 제외됩니다. 취약점 상세가 담기므로 그대로 두는 게 안전하고, 감사 목적으로 남기려면 접근 권한을 통제하는 곳에 따로 보관하세요.

Q. 오탐이 정말 0건이었나요?

A. 이번 87파일 스캔에서는 그랬습니다. 독립 검증 에이전트가 확인한 항목만 보고서에 올리는 구조라 오탐이 걸러지는데, 스캔은 비결정적이라 다른 저장소·다른 실행에서는 결과가 달라질 수 있습니다.

정리하면

실서비스 스캔 결과 = XSS 3건 발견·수정·배포 완료, 9분 26초, 주간 한도 24%. 도구는 기대 이상이었고, 특히 "이미 안전한 형제 코드를 근거로 제시"하는 점이 좋았습니다. 하지만 오늘 제가 가장 크게 배운 건 도구의 성능이 아니라 한계예요 — 스캐너가 XSS를 잡는 동안, +124%라는 이상한 숫자는 사람이 봐야 보였습니다. 좋은 스캐너를 붙이는 것과 사람이 화면을 계속 보는 것은 대체 관계가 아니라 보완 관계입니다. 다음 글에서 그 나머지 절반을 이어가겠습니다.

참고 자료

Claude Security 플러그인 공식 문서

Claude Code에 보안 스캐너가 들어왔다: /claude-security 플러그인 사용법 (2026)

DevPilot — Wed, 26 Aug 2026 19:18:58 +0900

핵심 요약: Claude Code에서 명령 하나로 저장소 취약점 스캔이 됩니다 — 공식 Claude Security 플러그인(베타)이에요. /plugin install claude-security@claude-plugins-official로 설치하면 /claude-security 명령이 생기고, 에이전트 팀이 아키텍처 파악 → 위협 모델링 → 취약점 사냥 → 독립 에이전트의 검증까지 거쳐 보고서를 만듭니다. 전체 저장소뿐 아니라 브랜치 diff·PR·커밋 단위 스캔도 되고, 발견 항목은 패치 파일로 만들어주되 자동 적용은 절대 안 합니다 — git apply는 항상 사람 몫. 요구사항은 유료 플랜 + v2.1.154 이상 + python3, 스캔은 내 플랜 사용량을 소모합니다. 결론 먼저: 기존 정적 분석을 대체하는 게 아니라, "사람 보안 리서처처럼 추론하는" 딥스캔 계층이 하나 얹힌 겁니다.

※ 이 글은 2026년 8월 27일 기준이며 공식 문서를 기반으로 합니다. 베타 기능이라 절차가 바뀔 수 있어요.

지난주 코드 리뷰 글(그 이야기)에서 "AI 리뷰는 판사가 아니라 센서"라고 썼는데, 마침 그 센서 계층의 공식 도구를 발견했습니다. 7월 말 베타로 나왔는데 SpaceX·플러그인 뉴스에 묻혀 놓칠 뻔했어요.

뭘 하는 물건인가: 에이전트 팀이 보안 리서처처럼

핵심은 단일 패스가 아니라 멀티에이전트 구조입니다. 스캔을 시작하면 에이전트들이 역할을 나눠 — 저장소 아키텍처를 매핑하고, 위협 모델을 세우고, 취약점을 사냥하고, 마지막으로 발견 항목마다 독립 검증 에이전트가 다시 확인한 것만 보고서에 올립니다. 오탐을 걸러 "짧고 읽을 가치 있는 보고서"를 만드는 설계예요.

기존 정적 분석 도구와의 차이가 여기 있습니다 — 규칙 매칭이 아니라 코드의 맥락을 추론합니다. 공식 문서 표현대로 "사람 보안 리서처가 하듯" 접근하는 것이고, 그래서 대체가 아니라 병행이 맞습니다.

▲ 이 플러그인은 5계층 중 "필요할 때 부르는 딥스캔" 자리입니다. /security-review(1패스)와는 깊이가 달라요.

설치와 요구사항 (5분)

세션 안에서 두 줄이면 끝납니다 — /plugin install claude-security@claude-plugins-official 설치 후 /reload-plugins. 마켓플레이스가 없다고 나오면 /plugin marketplace add anthropics/claude-plugins-official을 먼저.

요구사항 셋만 확인하세요: 유료 플랜 + Claude Code v2.1.154 이상(Pro는 /config에서 Dynamic workflows 켜기), python3 3.9.6 이상(표준 라이브러리만 써서 별도 설치 없음), 그리고 diff 스캔·패치용 git. 참고로 스캔은 로컬 세션에서 돌고 내 플랜 사용량을 소모합니다 — 토큰을 꽤 쓰는 작업이라 시작 전에 확인 단계가 한 번 있습니다.

▲ 실제 메뉴입니다. 전체 스캔 / 변경분 스캔 / 패치 제안 셋뿐이라 헤맬 게 없어요. (직접 캡처)

쓰는 법: 스캔 → 보고서 → 패치 제안 → 직접 적용

/claude-security를 치면 세 가지 작업 메뉴가 뜹니다. 전체 스캔은 저장소를 읽고 "전체 vs 집중 영역"을 파일 수·상대 비용과 함께 제안해요(대형 저장소는 인증 코드, API 계층처럼 영역별로 나눠 도는 걸 권장). 변경분 스캔은 브랜치 diff·열린 PR·특정 커밋 단위 — "머지 전에 이 브랜치만 봐줘"가 됩니다. 자연어로 "scan commit abc1234"처럼 불러도 되고요.

결과는 저장소 안 CLAUDE-SECURITY-(타임스탬프)/ 폴더에 남습니다 — 보고서(md), 기계용(jsonl), 그리고 어느 커밋을 어떤 강도로 스캔했는지 기록하는 리비전 스탬프까지. 폴더에 자체 .gitignore가 들어 있어 실수로 커밋될 일도 없게 해뒀어요. 디테일에 공을 들인 티가 납니다.

▲ 마지막 화살표만 사람이 당깁니다. 패치 자동 적용은 설계상 없습니다.

패치: 만들어는 주되, 적용은 안 한다

이 플러그인에서 제일 마음에 드는 설계입니다. "Suggest patches"를 고르면 선택한 발견 항목마다 패치 파일(F1.patch)을 만드는데 — 패치는 스크래치 복사본에서 작성되고, 작성자와 다른 독립 에이전트가 리뷰합니다(테스트가 있으면 돌려보고, 새 취약점을 만들지 않는지 diff를 따로 읽음). 그 검증을 통과 못 하면 패치 대신 "왜 못 만들었는지" 메모가 옵니다.

그리고 적용은 무조건 사람이 — git apply로 패치당 PR 하나씩. 지난주 글의 위험 기반 리뷰 원칙(보안·인증은 사람이 직접)과 정확히 같은 철학이라, 도구 설계가 이 방향으로 수렴하는 게 보입니다. 시크릿·계정 위임 원칙(보안 체크리스트)과 묶어 쓰면 좋아요.

알아둘 것 셋

① 스캔은 비결정적 — 같은 코드를 두 번 스캔하면 다른 항목이 나올 수 있습니다. 일회성 통과 의식이 아니라 주기적으로 도는 습관이 맞아요. ② Fable 5에서 차단 메시지가 뜰 수 있음 — 사이버보안 안전장치가 일부 작업을 막고 Opus로 자동 강등하는데, 공식 문서가 "정상 동작"이라고 명시합니다. ③ Enterprise엔 관리형 버전 — 저장소를 상시 모니터링하는 Claude Security 제품이 따로 있고, 8/21부터 그쪽 스캔은 보안 특화 모델(Mythos 5)로 돕니다. 플러그인은 GitLab·비트버킷·폐쇄망처럼 관리형이 못 닿는 곳까지 커버하는 게 차별점이에요.

자주 묻는 질문 (FAQ)

Q. 무료 플랜에서도 쓸 수 있나요?

A. 아니요, 유료 플랜 전용입니다(Claude Code 자체가 유료 기능이기도 하고요). Pro에서는 /config에서 Dynamic workflows를 켜야 합니다.

Q. 스캔 비용은 따로 내나요?

A. 별도 과금은 없고 내 플랜의 사용량 한도를 소모합니다. 전체 스캔은 토큰을 많이 쓰는 작업이라, 대형 저장소는 영역별로 나눠 돌리는 것이 권장됩니다.

Q. 기존 SAST·의존성 스캐너를 대체하나요?

A. 아니요, 병행이 공식 권장입니다. 이 플러그인은 맥락 추론형 딥스캔이고, 규칙 기반 정적 분석·공급망 검사·CI 정책은 기존 도구의 영역입니다.

정리하면

Claude Security 플러그인 = 터미널 안 멀티에이전트 취약점 스캐너(설치 2줄, 전체/diff/커밋 스캔, 독립 검증된 보고서, 패치는 제안만·적용은 사람). 유료 플랜 사용량으로 돌고, 기존 스캐너의 대체가 아니라 추론 계층 추가입니다. 저는 이번 주에 블로그 파이프라인 저장소에 한번 돌려볼 생각인데, 결과가 흥미로우면 후기로 이어가겠습니다.

참고 자료

Claude Security 플러그인 공식 문서
베타 출시 보도 (MarkTechPost)

Devin Desktop 8월 업데이트 총정리: 조용히 '팀 도구'가 되고 있다 (2026)

DevPilot — Tue, 25 Aug 2026 17:36:57 +0900

핵심 요약: 8월 한 달간 Devin Desktop에 릴리스가 넷(8/1 v3.6.27, 8/10 v3.7.16, 8/13 v3.7.25, 8/21 v3.8.20) 쌓였습니다. 개별 항목은 잘아 보이는데 묶어 보면 방향이 선명해요 — ① 비용 가시화(세션마다 ACU 크기 표시, 자동 연장 과금 알림이 대화에 인라인으로) ② 팀 기능(민감정보 자동 제거된 대화 공유 링크, 플러그인 계정 동기화, 계층형 권한 규칙) ③ 안전장치(심링크 통한 파일 쓰기 차단, 신뢰 안 된 워크스페이스 경고) ④ 플랜 모드 강화(마크다운 플랜 파일 + 명시적 Implement 버튼 — Claude Code Plan 모드의 대응물). 요금·플랜 변화는 없습니다. 한 줄 정리: 혼자 쓰는 에이전트에서 팀이 관리하며 쓰는 에이전트로 체질을 바꾸는 중입니다.

※ 이 글은 2026년 8월 26일 기준이며 공식 체인지로그의 8월 릴리스 4건을 기반으로 합니다.

Devin은 이 블로그에서 검색 유입이 가장 꾸준한 주제인데, 정작 8월 소식은 SpaceX·플러그인 뉴스에 밀려 못 다뤘습니다. 몰아서 보니 흩어진 업데이트가 한 방향을 가리키고 있더라고요.

흐름 ①: 돈이 보이기 시작했다

Devin의 고질적 불만은 "ACU가 어디서 얼마나 나가는지 모르겠다"였습니다(ACU 구조는 완전 이해 글 참고). 8월 업데이트가 정확히 여기를 손봤어요 — 클라우드 세션 목록에 세션별 ACU 크기 칩이 붙고, 세션이 자동 연장될 때의 과금 알림이 대화 안에 인라인으로 표시됩니다. Enterprise는 한도에 닿으면 추가 사용 요청 링크까지.

"요금이 싸졌다"가 아니라 "청구서가 예측 가능해졌다"는 변화인데, 종량제 도구에선 후자가 체감상 더 큽니다. 미터기가 보여야 아낄 수 있으니까요.

▲ 릴리스 4건을 겹쳐 보면 이 네 갈래입니다. 방향은 하나 — 팀 도구화.

흐름 ②: 팀 기능 — 공유·동기화·권한

이번 달 가장 큰 신기능은 Devin Local 대화 공유입니다(8/10). 완료된 턴 아래에서 Share Conversation을 누르면 트랜스크립트가 업로드되고 팀 링크가 복사되는데, 디테일이 좋아요 — 시스템 프롬프트·도구 정의는 빠지고, 시크릿은 자동 마스킹되고, 경로는 정규화됩니다. "이거 어떻게 시켰어?"를 링크 하나로 답하는 기능이죠.

플러그인도 계정 단위로 바뀌었습니다 — Customizations에서 설치하면 기본이 개인 계정 소속이라 Devin Cloud와 다른 기기에서도 따라옵니다(기기 한정 설치는 옵션). 그리고 권한 규칙이 계층형으로 정리됐어요: 기업·모드·사용자·프로젝트·서브에이전트 레벨의 규칙이 예측 가능하게 합성되고, 명시적 deny가 항상 이깁니다. 어디서 거부됐는지 레이어까지 알려주고요. 조직 관리자가 원하던 바로 그 구조입니다.

흐름 ③: 안전장치 — 수수하지만 중요한 것들

8/1 릴리스에 눈에 띄는 보안 수정이 있습니다 — Devin Local의 편집 도구들이 심링크를 통한 쓰기를 거부하게 됐어요. 승인된 편집이 심링크를 타고 엉뚱한 파일로 우회되는 경로를 막은 겁니다. 8/21에는 신뢰되지 않은 워크스페이스를 열면 사이드바·컴포저가 경고하고 명시적 신뢰 확인을 받도록 바뀌었고요.

에이전트에게 파일 쓰기 권한을 주는 시대에 이런 항목은 체인지로그의 "Fixed" 한 줄로 지나치기 아까운 변화입니다. 위임이 커질수록 안전장치의 가치도 커지니까요.

흐름 ④: 플랜 모드 — "계획 검토 후 실행" 이 표준이 되는 중

Devin Local의 플랜 모드가 전체 마크다운 플랜 파일 + 명시적 Implement 버튼 구조로 강화됐습니다(8/21). 계획을 파일로 따로 검토하고, 버튼을 눌러야 실행이 시작되는 방식 — Claude Code의 Plan 모드, Cursor의 Plan과 같은 계열이에요. 지난주 코드 리뷰 글(그 이야기)에서 말한 "사람의 체크포인트를 코드 생성 이전으로 옮기기"가 도구 전반의 표준 UI가 되어가는 증거로 읽힙니다.

그 외 자잘한 것들 — 서브에이전트 개별 중지(턴 전체 취소 없이), Agent Command Center 창 분리·다중 에이전트 창(8/21), Windows에서 Desktop 업데이트 시 devin CLI도 함께 갱신되는 shim, 수천 세션 사용자용 사이드바 성능 개선(8/13). Windsurf 시절부터 쓰던 분들이 체감할 개선이 많습니다.

자주 묻는 질문 (FAQ)

Q. 요금이나 플랜도 바뀌었나요?

A. 아니요, 8월 업데이트는 전부 기능·안정성 개선이고 ACU 단가($2.25/15분)와 플랜 구성은 그대로입니다. 바뀐 건 사용량이 보이는 방식입니다.

Q. 대화 공유하면 시크릿이나 코드도 노출되나요?

A. 공유 트랜스크립트는 시스템 프롬프트·도구 정의가 제거되고 시크릿이 자동 마스킹된 정제본입니다. 다만 대화 본문에 직접 붙여넣은 민감 정보는 스스로 확인하는 게 안전합니다.

Q. Windsurf 이름으로 쓰던 것과 같은 앱인가요?

A. 네, 6월에 Windsurf가 Devin Desktop으로 리브랜딩된 그 앱입니다. 전환 배경과 차이는 별도 글에 정리돼 있습니다.

정리하면

8월의 Devin = 비용 가시화 + 팀 공유·권한 + 안전장치 + 플랜 모드. 신기능 한 방 대신 "조직이 믿고 배포할 수 있는 상태"를 만드는 업데이트들입니다. 개인 사용자 기준 오늘 써볼 것 하나만 꼽으면 대화 공유 — 팀에 데빈 쓰는 법을 전파할 때 이만한 도구가 없어요. Cursor와의 비교 관점은 /25 비교 글도 오늘 함께 갱신했습니다.

참고 자료

Devin Desktop 공식 체인지로그

Grok 4.6 정리: 가장 싼 프론티어 모델 — Cursor·Copilot 사용자에게 뭐가 달라지나 (2026)

DevPilot — Mon, 24 Aug 2026 22:48:47 +0900

핵심 요약: 8월 12일 xAI(SpaceXAI)가 Grok 4.6을 냈습니다. 숫자만 보면 포지션이 선명해요 — Artificial Analysis 지능 지수 61점으로 GPT-5.6 Sol과 동률(Claude Fable 5보다 1점 아래)인데, 가격은 $2/$6(1M 토큰)으로 프론티어급 중 최저가입니다. 컨텍스트 500K, 에이전트 코딩 벤치(DeepSWE)는 4.5의 54에서 65.9로 점프. 대신 약점도 명확합니다 — 터미널 작업 계열이 상대적으로 약하고, 싼 단가가 곧 싼 작업당 비용은 아니에요. 도구 사용자 관점 요약: Cursor에선 모델 목록에서 바로 선택 가능(같은 SpaceX 지붕이라 기본값 향방이 관전 포인트), Copilot엔 8/14 카탈로그 추가(9월 폐기 모델의 대체 후보), API 직접 사용자에겐 "가격 대비 지능" 1순위 후보입니다.

※ 이 글은 2026년 8월 25일 기준입니다. 모델 가격·제공 범위는 자주 바뀌니 사용 전 공식 문서를 확인하세요.

지난주 내내 SpaceX-Cursor 이야기(인수, Grok Bot)를 썼는데, 그 사이 정작 모델 쪽 뉴스를 밀어뒀습니다. 인수 이틀 전에 나온 Grok 4.6 — 출시 당일 머스크가 "4.7은 3~4주 뒤"라는 트윗까지 올려서 화제가 됐던 그 모델입니다.

포지션: 1점 차이를 3분의 1 가격에

이번 릴리스의 본질은 순위가 아니라 가격 대비 지능입니다. Artificial Analysis 지능 지수에서 61점 — GPT-5.6 Sol과 동점이고 Fable 5(62)보다 딱 1점 아래인데, 단가는 GPT-5.6 Sol($5/$30)의 절반 이하, Fable 5($10/$50)의 5분의 1 수준이에요.

▲ 세로가 지능, 가로가 가격입니다. 왼쪽 위 구석을 파고든 게 이번 전략이에요.

세부를 보면 성격이 갈립니다. 에이전트 코딩(DeepSWE)이 4.5의 54에서 65.9로 크게 뛴 반면, 터미널 작업 계열은 상대적으로 약합니다. 지식 노동·법률 추론 쪽 점수가 강해서 — "코딩 1위"라기보다 "제일 싸게 프론티어급을 쓰는 선택지"로 읽는 게 정확합니다. 컨텍스트는 500K, 급할 때 쓰는 Fast 변형은 2배 가격입니다.

단가와 청구서는 다르다 (늘 하는 이야기지만)

$2/$6이라는 숫자에 바로 갈아타기 전에, 이 블로그에서 반복하는 원칙 하나만 — 싼 단가 ≠ 싼 작업당 비용입니다. 에이전트 작업은 모델마다 소비 토큰량이 수십 배 갈리고, 답을 길게 내는 모델은 단가 우위를 토큰량으로 반납하기도 해요(그 산수는 손익분기 글에서 다뤘습니다). 대표 작업 하나를 실제로 돌려 총액을 재보고 결정하는 게 정확합니다.

도구별로 보면: 내 자리에서 뭐가 달라지나

▲ 같은 모델인데 자리마다 의미가 다릅니다.

Cursor 사용자 — 모델 목록에서 바로 선택할 수 있고, Router를 쓴다면 배정 대상에도 들어옵니다. 관전 포인트는 따로 있어요: 이제 같은 SpaceX 지붕 아래라서(8/14 인수 완료), Grok 계열이 기본값·추천 위치로 기우는지가 앞으로 몇 달의 체크 항목입니다. 모델 선택권 자체는 그대로입니다.

Copilot 사용자 — 8월 14일 카탈로그에 추가됐습니다. 시점이 절묘한데, 9월 1일 구모델 폐기(Sonnet 3.7·Opus 4·Gemini 2.0 Flash)로 이동해야 하는 사람들에겐 대체 후보가 하나 늘어난 셈이에요(Cursor vs Copilot 비교도 오늘 이 내용으로 갱신했습니다).

API 직접 사용자 — 가격 대비 지능으로는 현재 1순위 후보. 다만 위의 작업당 비용 원칙대로 내 워크로드에서 실측 먼저. 그리고 4.7이 몇 주 뒤로 예고된 상태라, 대규모 마이그레이션이라면 한 템포 기다리는 것도 합리적입니다.

자주 묻는 질문 (FAQ)

Q. Grok 4.6과 Grok Bot은 뭐가 다른가요?

A. 4.6은 모델(API·도구에서 선택하는 두뇌)이고, Grok Bot은 그 모델 계열을 쓰는 상시형 에이전트 제품입니다. 4.6은 $2/$6 종량으로 누구나 쓸 수 있지만, Grok Bot은 SuperGrok Heavy·Cursor Ultra 등 프리미엄 구독 번들로만 접근됩니다.

Q. 코딩용으로 Claude나 GPT에서 갈아탈 만한가요?

A. 에이전트 코딩 벤치는 크게 올랐지만 터미널 작업 계열은 상대적으로 약합니다. 벤치마크보다 내 대표 작업 하나를 실제로 돌려 완주율과 총비용을 비교해보고 결정하는 것을 권합니다.

Q. Grok 4.7이 곧 나온다는데 기다려야 하나요?

A. 출시 당일 3~4주 뒤 4.7이 예고됐습니다. 가볍게 써보는 건 지금도 무방하지만, 파이프라인 전체를 옮기는 결정이라면 4.7 확인 후가 안전합니다.

3줄 요약

Grok 4.6(8/12) = 프론티어급 지능(AA 61, Fable 5 -1점)을 최저 단가($2/$6, 500K 컨텍스트)에. 강점은 에이전트 코딩·지식 노동, 약점은 터미널 계열 — "가장 똑똑한"이 아니라 "가장 싼 프론티어"가 정확한 포지션. Cursor에선 기본값 향방을, Copilot에선 9월 대체 후보로, API에선 실측 후 판단을. 4.7이 예고돼 있어 이 글도 곧 후속이 붙을 겁니다.

참고 자료

Grok 4.6 API 가격 (OpenRouter)
Grok 4.6 in GitHub Copilot (GitHub Changelog)
Grok 4.6 벤치마크 분석 (Apidog)

코드가 읽는 속도를 추월했다 — 그래서 나는 뭘 읽기로 했나 (2026)

DevPilot — Sat, 22 Aug 2026 19:01:12 +0900

이 글은 요약 글이 아니라 고민 글입니다. AI가 코드를 쓰는 속도가 사람이 읽는 속도를 넘어선 지금, "모든 코드를 사람이 읽고 머지한다"는 원칙이 실제 데이터에서 어떻게 무너지고 있는지(리뷰 시간 +441.5%, 리뷰 없는 머지 +31.3%), AI 리뷰어를 붙이면 해결되는지(채택률 16.6% vs 56.5% — 아니요), 그러면 사람은 뭘 읽어야 하는지를 정리했습니다. 결론 먼저: 모든 줄을 같은 강도로 읽는 관행이 끝나는 것이지, 읽기와 책임이 끝나는 게 아닙니다. 그리고 마지막엔 이 블로그가 같은 문제를 어떻게 처리하는지 — 어제 실제로 있었던 일까지 포함해서 — 적었습니다.

※ 이 글은 2026년 8월 23일 기준이며, 인용한 연구들은 대부분 관찰 데이터입니다(인과 입증 아님). 원출처는 글 끝에 모아뒀습니다.

얼마 전 커뮤니티에서 이런 댓글을 봤습니다 — "코드리뷰를 굉장히 좋아하는 편이었는데, 에이전트가 쏟아내는 방대한 코드를 리뷰하는 데에 지쳐갑니다." 저장해뒀어요. 남 얘기가 아니라서요.

숫자부터: 격차는 이미 데이터에 있다

Faros AI가 4,000개 팀, 22,000명 개발자의 2년치 텔레메트리를 분석했습니다. AI 도입도가 낮은 팀에서 높은 팀으로 갈수록 — 중앙값 리뷰 소요 시간 +441.5%, 리뷰 없이 머지된 PR +31.3%.

주목할 건 해석입니다. 누구도 "리뷰를 생략하자"고 결정하지 않았어요. 리뷰어가 물량을 못 따라가면서 읽히지 않은 코드가 머지되는 게 그냥 일상이 된 것입니다. 생산량 쪽 숫자도 비슷한 무늬인데 — GitClear 데이터에서 AI를 매일 쓰는 개발자는 원시 산출량이 약 4배였지만, 1년 전 자신과 비교한 생산성 향상은 약 12%였습니다. 늘어난 코드의 검토 비용을 어딘가에서 사람이 떠안고 있다는 뜻이죠. (둘 다 관찰 데이터라 선택 편향 여지는 있습니다 — 그래도 방향은 제 체감과 정확히 일치해요.)

▲ 문제의 본체입니다. 병목은 원래부터 타이핑이 아니라 이해와 검증이었어요.

AI 리뷰어를 붙이면 되지 않나

올해 그 실험의 데이터가 나왔습니다. 300개 오픈소스 프로젝트의 PR 5만 4천 개, 인라인 리뷰 대화 27만 8천 개를 분석한 연구에서 — 이미 전체 리뷰의 절반 이상(55.7%)을 AI가 시작하고 있었어요. 그런데 결과가 흥미롭습니다.

AI 리뷰어 제안의 채택률은 16.6%, 인간 리뷰어는 56.5%. AI가 시작한 리뷰의 85% 이상은 첫 코멘트 뒤 아무 응답 없이 끝났고요. 차이의 원인도 데이터에 보입니다 — AI 코멘트의 95% 이상은 코드 안의 결함·개선에 집중한 반면, 인간은 구현 의도를 묻고, 테스트 방식을 확인하고, 저장소의 관례와 과거 결정을 대화로 가져왔습니다. AI는 코드 안을 보고, 사람은 코드 밖을 봅니다.

207개 프로젝트 102만 개 PR을 시대별로 나눈 다른 연구는 경고를 하나 보탭니다 — 모든 PR에 같은 모델을 일괄로 붙인 프로젝트는 속도 개선도 없었고 리뷰 안티패턴이 오히려 늘었어요. 같은 리뷰어(모델) 조합이 반복되는 비율이 60%로, 사람만일 때(16%)보다 훨씬 높았고요. 리뷰어 수는 늘어난 것 같지만 관점은 하나로 고정되는 겁니다. 그래서 제 결론은 이래요: AI 리뷰는 판사가 아니라 센서입니다. 어디를 사람이 봐야 하는지 알려주는 넓은 탐지망이요.

그러면 사람은 뭘 읽나: 틀렸을 때의 비용으로 정한다

"모든 코드를 두 사람이 읽는다"를 지킬 수 없다면, 다음 원칙은 이것밖에 없다고 봅니다 — 작성자가 사람인지 AI인지가 아니라, 이 변경이 틀렸을 때 무슨 일이 생기는지로 리뷰 강도를 정한다.

▲ 모든 줄에 같은 관심을 쓰는 게 아니라, 위험한 곳에 사람의 주의를 몰아주는 구조입니다.

일회성 스크립트·낮은 위험 변경은 자동 테스트 + AI 센서로 충분합니다. 오래 유지할 핵심 로직은 사람이 설계와 유지보수성까지 읽고요 — 리뷰어가 이해 못 한 코드는 미래의 유지보수자도 이해 못 하니까, 여기서 읽기의 목적은 무결성 증명이 아니라 "다른 사람이 이어받을 수 있는가"의 확인입니다. 그리고 인증·결제·권한·데이터 삭제·인프라는 시스템 소유자가 직접. 타협 없이요.

남는 질문은 "그래서 사람이 최종적으로 소유하는 게 뭔가"인데, 저는 네 단어로 정리하게 됐습니다 — 의도(맞는 문제를 푸는가), 맥락(코드 밖의 제약과 과거 결정), 증거(실제로 돌아간다는 확인), 책임(문제가 생기면 설명하고 되돌릴 수 있는가). 이 넷은 자동화가 안 됩니다. 장애가 나면 모델이 온콜을 받아주지 않아요.

고백: 이 블로그도 같은 구조로 돌아갑니다

여기서부터는 제 이야기입니다. 이 블로그는 AI 초안 + 사람 검증으로 운영된다고 편집 방침에 밝혀뒀는데(워크플로 공개 글), 코드 리뷰의 문제와 정확히 같은 문제를 매일 만납니다. 글이 만들어지는 속도가 제가 전부 정독하는 속도보다 빠르거든요.

그래서 구조가 위의 사다리와 같아졌습니다. 반복 가능한 검사는 자동화 — 매 글마다 스크립트가 FAQ 구조, 깨진 내부 링크, 금지 패턴을 검사합니다(코드의 린트·테스트에 해당). 위험한 곳은 원출처 재확인 — 가격·날짜·정책처럼 틀리면 독자에게 실해가 가는 팩트는 공식 발표를 직접 다시 봅니다. 그리고 게시 버튼과 책임은 사람이요.

이 구조가 밥값을 한 게 바로 어제입니다. 9월 요금 캘린더(그 글)를 쓰려고 원출처를 확인하다가, 저희가 여러 글에서 "9월 인상 예정"이라 적어둔 Sonnet 5 가격이 열흘 전에 이미 취소된 걸 발견했어요. 그날 글 8개를 고쳤습니다. 자동 검사는 이걸 못 잡습니다 — 링크는 멀쩡하고 문법도 맞으니까요. "이 날짜가 아직 유효한가"는 맥락의 문제라, 사람 몫이더라고요.

자주 묻는 질문 (FAQ)

Q. AI 코드 리뷰 도구는 쓸 필요가 없다는 건가요?

A. 반대입니다. 결함 후보를 넓게 탐지하는 1차 센서로는 유용합니다. 다만 승인·판단까지 맡기면 리뷰 관점이 하나로 고정되는 부작용이 데이터로 확인됐으니, 사람의 주의를 배치하는 도구로 쓰는 게 맞습니다. 도구 비교는 별도 글에 있습니다.

Q. 리뷰 없이 머지하는 게 늘어난 건 결국 나쁜 일 아닌가요?

A. 모든 변경에 같은 리뷰를 강제하던 관행이 물량 앞에서 무너진 결과에 가깝습니다. 위험이 낮은 변경을 가볍게 통과시키는 건 설계일 수 있지만, 위험한 변경까지 읽히지 않고 나가는 건 사고입니다. 구분하는 기준이 이 글의 요지입니다.

Q. 인용된 수치는 어디까지 믿을 수 있나요?

A. 대부분 관찰 연구라 인과관계 입증은 아니며, 표본 편향 가능성도 각 연구가 명시하고 있습니다. 이 글은 수치를 "정확한 예측"이 아니라 "방향의 증거"로 씁니다.

오늘의 결론

사라지는 건 코드 리뷰가 아니라 "모든 변경을 같은 사람이 같은 방식으로 읽던 관행"입니다. 자동화할 것(반복 검사), 센서에 맡길 것(넓은 탐지), 사람이 소유할 것(의도·맥락·증거·책임)을 나누는 일이 지금의 리뷰 설계고 — 이건 코드만의 이야기가 아니라는 걸, 블로그를 운영하며 매일 확인하고 있습니다. 여러분의 팀은 이 사다리의 어디쯤에 있나요?

참고 자료

Faros AI — 4,000개 팀 텔레메트리 분석
From Human-Centric to Agentic Code Review (arXiv, 102만 PR)
Addy Osmani — Agentic Code Review
GeekNews — 관련 글 큐레이션 (논의 출발점)

9월 AI 요금 캘린더: 오르는 것, 취소된 것, 지켜볼 것 (2026)

DevPilot — Fri, 21 Aug 2026 08:59:12 +0900

핵심 요약: 원래 이 글은 "9월 인상 캘린더"로 기획했는데, 조사하다 보니 제일 큰 항목이 사라져 있었습니다 — Sonnet 5 API의 9월 1일 인상($2/$10 → $3/$15)이 취소됐거든요(8/11 공식 발표, 도입가 영구화). 그래서 남은 9월 일정은 이렇게 정리됩니다. 확정: 9/1 Copilot에서 Claude Sonnet 3.7(일반·Thinking)·Opus 4·Gemini 2.0 Flash 제공 종료, 9/10 MAI-Code-1-Flash 종료 — 요금 인상은 아니지만 구모델 고정 워크플로엔 강제 이사입니다. 유동: Claude Code 주간 +50% 부스트가 8/31까지 연장된 상태("영구화 희망"이라는 단서 포함). 흐름: 여름 내내 OpenAI 인하 → Anthropic 인상 취소로 이어진 가격 경쟁 — 다만 "영구"라는 말의 유통기한도 함께 알아둘 필요가 있습니다.

※ 이 글은 2026년 8월 22일 기준입니다. 요금·일정은 바뀔 수 있으니 결제·이전 전 각 공식 공지를 확인하세요.

※ 2026년 9월 1일 갱신: 아래 "유동" 항목의 결론이 나왔습니다 — Claude Code 주간 부스트는 9/13까지 +50% 그대로 유지되고, 9/14부터 영구 +25%로 전환됩니다(공식 발표). 기준선(부스트 이전) 대비로는 인상이지만, 지금 쓰던 +50% 대비로는 약 17% 감소예요. 5시간 세션 한도는 무관하게 그대로입니다. 상세 산수와 대응은 전용 글에 정리했습니다.

지난달 8월 마감 캘린더가 유입이 꾸준했어서 9월판을 준비했는데, 쓰기 전에 팩트 체크부터 하길 잘했습니다. 달력에 적어뒀던 날짜 하나가 조용히 지워져 있었어요.

취소된 것: Sonnet 5 인상 (이 달의 가장 좋은 소식)

8월 11일, Anthropic이 공식 계정으로 발표했습니다 — "Sonnet 5의 도입가($2/$10, 1M 토큰)를 영구화한다." 원래 8/31까지의 프로모션이었고 9/1부터 $3/$15가 예고돼 있었는데, 그 인상이 통째로 사라진 겁니다.

▲ 발표 원문입니다. 출처: Claude 공식 X (2026-08-11)

API로 자동화·CI를 돌리는 분들에겐 실질적인 절감입니다 — 9월 예산을 $3/$15 기준으로 잡아뒀다면 그 차액(50%)이 그대로 돌아온 셈이니까요. 구독(Pro·Max) 사용자는 원래 무관합니다. 구독 vs API 종량 중 어느 쪽이 싼지는 사용량에 따라 갈리는데, AI 구독 vs API 비용 계산기에 하루 요청 수를 넣으면 $2/$10 기준 손익분기가 바로 나옵니다.

확정된 것: Copilot 구모델 종료 (9/1·9/10)

요금표는 안 바뀌지만 달력에 적어야 할 확정 일정은 Copilot 쪽입니다. 9월 1일에 Claude Sonnet 3.7(일반·Thinking), Claude Opus 4, Gemini 2.0 Flash가 Copilot 전 기능(챗·인라인 편집·에이전트·자동완성)에서 내려가고, 9월 10일엔 MAI-Code-1-Flash가 종료됩니다.

▲ 달력에 남은 것과 지워진 것. 지워진 쪽이 제일 큰 항목이었습니다.

인상은 아니지만 강제 이사입니다 — 리뷰 기준이나 자동화를 특정 구모델에 고정해둔 조직은 9월 전에 대체 모델로 옮겨야 하고, Enterprise는 관리자가 대체 모델을 활성화해줘야 합니다. 코드 리뷰 파이프라인에 걸린 영향은 리뷰 도구 비교 글에 정리해뒀습니다.

유동적인 것: Claude Code 부스트 (8/31 시한)

주간 한도 +50% 부스트는 8/19 종료 예정이었다가 다섯 번째 연장으로 8/31까지 살아 있습니다. 이번 공지엔 "영구화를 희망한다"는 문구가 붙었는데, "수요에 따라 유동적"이라는 단서도 함께예요. 즉 9/1에 어떻게 될지는 아직 모릅니다 — 대비 체크리스트는 부스트 대비 글 그대로 유효합니다.

큰 그림: 여름의 가격 전쟁, 그리고 "영구"의 유통기한

이번 취소를 단독 사건으로 보면 반쪽입니다. 7월에 OpenAI가 GPT-5.6 Luna·Terra 단가를 내렸고, 중국 오픈 모델들이 바닥 가격을 유지했고, 그 압박 속에서 Anthropic이 인상을 접었어요. 올여름 API 단가의 방향은 분명히 아래쪽입니다.

다만 발표에 대한 커뮤니티 반응이 흥미로운데 — 축하보다 산수가 많았습니다. "단가가 같아도 Sonnet 5는 토큰을 많이 써서 작업당 비용은 여전히 비싸다"는 반론이 대표적이에요(참고: explainx 분석). 그리고 "영구"라는 말 자체의 유통기한도 있습니다 — DeepSeek는 5월에 "영구 할인"을 발표했다가 8월 초에 인상을 예고했죠. AI 단가에서 영구란 "서빙 경제학이 허락하는 동안"이라는 뜻에 가깝습니다.

▲ 방향은 인하 쪽. 다만 "영구"는 계약이 아니라 선언입니다.

그래서 9월 전에 할 일

정리하면 셋입니다. ① Copilot 사용자 — 구모델 고정 설정이 있는지 확인하고 9/1 전에 이동(조직은 관리자 설정 포함). ② API 예산 담당 — Sonnet 5를 $3/$15로 잡아뒀다면 $2/$10으로 환원, 다만 분기마다 재확인. ③ Claude Code 헤비 유저 — 8/31 부스트 시한 전후 공지 확인, /usage 측정 습관 유지. 나머지는, 솔직히 없습니다. 9월은 이사(모델 폐기)의 달이지 인상의 달이 아니게 됐어요.

자주 묻는 질문 (FAQ)

Q. Sonnet 5 가격이 나중에 오를 수도 있나요?

A. 공식 표현은 "영구(permanent)"지만, AI 단가는 시장 상황에 따라 바뀌어 온 전례가 있습니다. 계약이 아니라 정책 선언이므로 장기 예산은 분기 단위 재확인을 권합니다.

Q. Copilot 모델 종료는 요금에 영향이 있나요?

A. 요금표는 그대로입니다. 다만 특정 구모델에 맞춰둔 워크플로는 대체 모델로 옮겨야 하고, Enterprise는 관리자 설정에서 대체 모델 활성화가 필요합니다.

Q. Claude Code 부스트는 9월에도 유지되나요?

A. 미정입니다. 현재 시한은 8/31이고 공식은 영구화 희망을 밝혔지만 확정은 아닙니다. 공지가 나오는 대로 이 글과 부스트 대비 글을 갱신하겠습니다.

정리하면

9월 캘린더 = 취소 1(Sonnet 5 인상), 확정 2(Copilot 모델 종료 9/1·9/10), 유동 1(CC 부스트 8/31 시한). 인상의 달이 이사의 달로 바뀐 게 이번 달 조사의 결론입니다. 저는 캘린더 글을 쓸 때마다 느끼는데, 날짜보다 "그 날짜가 아직 유효한가"를 확인하는 게 일의 절반이네요. 부스트 결과가 나오면 이어서 다루겠습니다.

참고 자료

Sonnet 5 도입가 영구화 발표 (Claude 공식 X, 8/11)
Copilot 9/1 모델 폐기 (GitHub Changelog)
MAI-Code-1-Flash 9/10 폐기 (GitHub Changelog)

Claude Code 세션끼리 대화를 시작했다 — 크로스 세션 메시징 & 셀프호스팅 러너 (2026)

DevPilot — Thu, 20 Aug 2026 15:56:19 +0900

핵심 요약: 8월 7일 Claude Code v2.1.224에 기능 둘이 실렸습니다. 하나는 크로스 세션 메시징 — 새 도구 ListAgents(내 컴퓨터의 다른 활성 세션 찾기)와 SendMessage(그 세션에 메시지 보내기)로, 떠 있는 세션들이 서로 대화합니다. 대형 리팩토링을 맡은 긴 세션이 하위 작업 세션들과 직접 조율하는 그림이 공식 기능이 된 거예요. 설계가 인상적인데 — 같은 기기 안의 메시지는 로컬에만 머물고 Anthropic 서버로 가지 않으며, 전달되는 건 텍스트뿐입니다(대화 이력·파일·권한은 안 넘어감). 다른 하나는 셀프호스팅 러너 — claude self-hosted-runner 명령 하나로 내 서버·컨테이너를 클라우드 세션의 실행 컴퓨터로 만드는 기능(Team·Enterprise 전용, 기본 비활성). 개인에겐 전자가, 회사엔 후자가 이번 업데이트의 핵심입니다.

※ 이 글은 2026년 8월 21일 기준(v2.1.224~225)입니다. Claude Code는 거의 매주 바뀌니 공식 What's New를 함께 확인하세요.

지난주 /30 허브 갱신에서 "8월 신기능 3종"으로 한 줄씩만 적고 지나갔는데, 써볼수록 한 줄로 끝낼 물건이 아니었습니다. 특히 세션끼리 말을 건다는 것 — 이건 작업 방식이 바뀌는 종류의 기능이에요.

크로스 세션 메시징: 멀티 에이전트가 공식 기능이 됐다

지금까지 터미널 여러 개에 Claude Code를 띄워 병렬로 쓰는 사람들은 조율을 사람이 했습니다. A 세션 결과를 복사해서 B 세션에 붙여넣는 식이죠. 서브에이전트(그 정리)는 한 세션 안의 위임이었고요.

v2.1.224부터는 독립된 세션들끼리 직접 조율합니다. ListAgents로 같은 컴퓨터의 활성 세션을 찾고, SendMessage로 메시지를 보내요. 리팩토링 총괄 세션이 "auth 모듈 끝났으면 알려줘"라고 테스트 세션에 묻는 그림이 도구 호출 한 번이 됩니다.

▲ 화살표가 늘었지만 넘어가는 건 텍스트뿐입니다. 파일도 권한도 안 넘어가요.

경계선도 명확합니다. 같은 기기 안 메시지는 로컬에서만 오가고 서버를 거치지 않습니다. 다른 기기와는 Remote Control(맥 터미널을 iOS·안드로이드 앱과 잇는 그 기능, 웹·폰 활용 글 참고) 경유로만 — 224에서는 응답만 가능했는데 바로 다음 버전(225)에서 먼저 말 걸기도 열렸어요. 그리고 어떤 경우든 전달되는 건 텍스트뿐, 대화 이력·파일·권한은 넘어가지 않습니다.

▲ 출처: Claude Code 공식 What's New 문서

셀프호스팅 러너: 클라우드 세션을 내 서버에서

두 번째 기능은 방향이 반대입니다. 클라우드 세션은 원래 Anthropic 인프라에서 돌았는데, 이제 claude self-hosted-runner 명령으로 내 머신·컨테이너를 실행 계층으로 쓸 수 있어요. Team·Enterprise 플랜 전용이고 기본은 꺼져 있습니다.

누구를 위한 기능인지는 분명합니다 — 코드가 외부 인프라에서 실행되는 것 자체가 막혀 있던 조직이요. 내부망 자원 접근이 필요한 파이프라인, 컴플라이언스 요건이 있는 팀에게 "클라우드 세션의 편의 + 실행은 우리 인프라"라는 조합이 열린 겁니다. 흥미로운 건 시장 전체가 같은 방향이라는 것 — 지난주 Cursor의 builds(그 정리)도 결국 "에이전트가 도는 환경"의 경쟁이었죠. 모델 경쟁의 다음 라운드는 인프라인 모양입니다.

▲ 세션을 시키는 곳과 실행되는 곳이 분리됩니다. 팀·엔터프라이즈 전용, 기본 꺼짐.

커뮤니티 반응: "드디어" 와 "텍스트만이라 아쉽다"

반응은 대체로 환영입니다. tmux나 파일 감시 스크립트로 세션 간 신호를 직접 만들어 쓰던 사람들이 "해킹이 공식 기능이 됐다"고 반겼고, 메시지가 로컬에 머문다는 설계는 보안 관점에서도 호평이에요(참고: MacRumors).

아쉬움도 구체적입니다 — 텍스트만 오가니 컨텍스트 공유가 안 되고(긴 결과물은 결국 파일로 주고받아야), 기기 간 통신이 Remote Control 경유로 제한적이라는 지적(참고: XenoSpectrum의 한계 분석). 저는 이 제한이 단점이라기보다 안전장치에 가깝다고 보는데, 권한까지 넘어가는 순간 위험의 종류가 달라지니까요.

어떻게 써볼까

개인 기준 현실적인 첫 활용은 "긴 작업 + 감시자" 2세션 구성입니다. 한 세션에 큰 작업을 맡기고, 다른 세션에 "저 세션이 끝나거나 막히면 내게 요약해줘"를 시키는 것. 저처럼 블로그 파이프라인을 돌리는 경우라면 글 쓰는 세션과 검증 세션의 분리도 자연스럽고요.

주의점은 하나 — 세션이 늘면 사용량도 세션 수만큼 나갑니다. 부스트가 8/31까지 연장되긴 했지만(그 소식), 병렬 구성은 주간 한도를 빠르게 소모하는 패턴이라 /usage 확인 습관과 세트로 가세요.

자주 묻는 질문 (FAQ)

Q. 세션 간 메시지가 Anthropic 서버로 전송되나요?

A. 같은 기기 안에서는 아닙니다 — 로컬에서만 오갑니다. 다른 기기와 통신할 때만 Remote Control 경로를 거칩니다.

Q. 파일이나 대화 내용도 다른 세션에 넘어가나요?

A. 아니요, 전달되는 건 텍스트 메시지뿐입니다. 대화 이력·파일·권한은 세션 간에 공유되지 않습니다.

Q. 셀프호스팅 러너는 개인 플랜에서도 쓸 수 있나요?

A. 현재 Team·Enterprise 플랜 전용이며 기본 비활성 상태입니다. Pro·Max 개인 플랜에서는 클라우드 세션이 기존대로 Anthropic 인프라에서 실행됩니다.

3줄 요약

v2.1.224(8/7) = 크로스 세션 메시징(ListAgents·SendMessage, 같은 기기 로컬 유지, 텍스트만) + 셀프호스팅 러너(Team·Ent, 내 인프라에서 클라우드 세션 실행). 개인은 "긴 작업 + 감시자" 2세션부터, 팀은 컴플라이언스 요건이 있다면 러너 검토. 병렬 세션은 사용량도 병렬로 나간다는 것만 기억하세요.

참고 자료

Claude Code What's New — Week 32 (공식 문서)
MacRumors 보도
XenoSpectrum — 구조와 한계 분석

Cursor에서 Gmail·드라이브·캘린더 쓰기 — Workspace 플러그인 설치와 주의점 (2026)

DevPilot — Wed, 19 Aug 2026 18:04:08 +0900

핵심 요약: 8월 3일부터 Cursor 에이전트가 Gmail·구글 드라이브·캘린더에 직접 접근할 수 있습니다 — 공식 플러그인 3종이 나왔거든요. 메일 검색·작성·전송, 드라이브 파일 검색·생성, 일정 조회·등록까지 에디터 안에서 처리됩니다. 설치는 Cursor의 Customize 페이지나 Marketplace에서 클릭 몇 번이면 끝. 쓸모는 분명합니다 — 버그 리포트 메일을 이슈로 정리하고, 스펙 문서를 드라이브에서 바로 끌어오는 식으로 탭 전환 자체가 사라져요. 다만 커뮤니티의 질문도 정당합니다: 메일 전송 같은 행동에 확인 절차가 어떻게 걸리는지, 권한 범위가 얼마나 넓은지. 그래서 이 글의 결론은 "설치하되, 읽기 시나리오부터"입니다.

※ 이 글은 2026년 8월 20일 기준입니다. 플러그인 기능·권한 정책은 바뀔 수 있으니 사용 전 공식 체인지로그를 한 번 더 확인하세요.

어제 플러그인 표준 이야기(Agent Plugins 정리)를 쓰면서 "그래서 플러그인으로 뭘 하는데?"라는 질문이 남았는데, 오늘이 그 답입니다. 8월 초에 나온 것 중 가장 실용적인 플러그인 — 구글 워크스페이스 3종이에요.

뭐가 되나: 읽기만이 아니라 쓰기까지

공식 발표의 첫 문장이 범위를 정확히 말해줍니다 — "Cursor가 이제 여러분의 Google Workspace 전반에서 읽고, 쓰고, 행동할 수 있다." 조회 전용이 아니라는 게 포인트예요.

▲ 3종 모두 "읽기"와 "쓰기"가 다 됩니다. 편리함과 주의점이 같은 곳에서 나와요.

구체적으로 — Gmail은 메일 검색·읽기·초안·전송·라벨·스레드 관리, 드라이브는 파일·폴더 검색, 열기·다운로드, 생성·정리, 캘린더는 일정 조회, 이벤트 생성·수정, 빈 시간 찾기까지. 설치는 Cursor 안의 Customize 페이지 또는 Cursor Marketplace에서 플러그인을 고르고 구글 계정을 연결하면 끝입니다.

▲ 실제 설치 화면입니다. 출처: Cursor 앱 Customize 페이지 (직접 캡처)

코딩 도구에 왜 메일이 필요한가

처음엔 저도 갸웃했습니다. 그런데 하루 이틀 생각해보니, 개발 작업의 컨텍스트가 원래 에디터 밖에 흩어져 있다는 게 문제였어요. 버그 제보는 메일로 오고, 스펙 문서는 드라이브에 있고, 리뷰 일정은 캘린더에 있죠.

그래서 실전 시나리오는 이런 겁니다 — "어제 온 버그 리포트 메일 찾아서 재현 조건을 정리해줘", "이 API 설계, 드라이브의 스펙 문서와 다른 부분 짚어줘", "다음 주에 코드 리뷰 1시간 잡을 수 있는 시간 찾아줘". 각각이 원래는 탭 전환 + 검색 + 복사·붙여넣기였던 일이에요.

어제 글의 프레임으로 보면, 이건 Cursor Marketplace가 "개발 도구 확장"을 넘어 업무 컨텍스트 전체로 넓어지는 신호이기도 합니다. MCP로 직접 연결을 짜던 일(MCP 개념)이 공식 플러그인 설치 한 번으로 내려온 거죠.

커뮤니티 반응: 환영과 질문이 반반

출시 후 반응을 찾아보면 두 갈래가 선명합니다. 환영하는 쪽의 논거는 컨텍스트 스위칭 제거 — 개발자가 하루 12~15회의 큰 흐름 끊김을 겪고 회복에 평균 23분이 든다는 연구를 들어, 메일·드라이브 왕복이 사라지는 것 자체가 집중 시간의 회수라는 겁니다.

반면 보안 쪽 질문도 구체적이에요 — 각 플러그인이 요구하는 OAuth 권한 범위가 문서화되지 않았고, 메일 전송·일정 삭제 같은 행동에 사용자 확인이 필수인지 에이전트가 자율 실행하는지가 불명확하며, 세션에 끌어온 메일 내용의 보존 정책, 멀티 계정 처리도 공식 스레드에서 답을 기다리는 중입니다(참고: nextdev 분석, 공식 발표 스레드).

둘 다 맞는 말이라는 게 제 생각입니다. 쓸모와 위험이 같은 기능("쓰기 가능")에서 나오니까요.

그래서 어떻게 쓰나: 읽기부터, 계정은 가려서

▲ 위임은 계단식으로. Comet 때도 Grok Bot 때도 같은 결론이었습니다.

제 권장 순서는 셋입니다. 1단계 — 읽기 시나리오만. 메일·문서 검색과 요약은 위험 없이 효용의 대부분을 줍니다. 2단계 — 초안까지. 메일 초안은 시키되 전송 버튼은 내가 누르기. 3단계 — 쓰기 위임. 몇 주 써보고 에이전트의 판단을 신뢰하게 됐을 때, 그것도 라벨 정리처럼 되돌릴 수 있는 것부터.

하나 더 — 연결 계정 선택이 사실상 가장 큰 보안 설정입니다. 개인 메인 계정보다 업무용·프로젝트용 계정부터 연결하세요. "내 계정으로 로그인하는 에이전트"의 위임 원칙은 Grok Bot 글(그 정리)에서 다룬 그대로입니다.

자주 묻는 질문 (FAQ)

Q. 추가 요금이 있나요?

A. 플러그인 자체는 무료입니다. Cursor 구독만 있으면 Customize 페이지나 Marketplace에서 설치할 수 있고, 에이전트 사용량은 평소처럼 소모됩니다.

Q. 에이전트가 내 허락 없이 메일을 보낼 수 있나요?

A. 전송·삭제 같은 행동의 확인 절차가 공식 문서에 아직 명확히 정리되지 않았습니다. 그래서 이 글은 전송은 직접 누르는 2단계 운용을 권합니다. 정책이 문서화되면 이 글을 갱신하겠습니다.

Q. MCP로 직접 연결하는 것과 뭐가 다른가요?

A. 하는 일은 비슷하지만 설치·인증·관리가 공식 플러그인으로 정리된 형태입니다. 직접 MCP 서버를 붙이던 구성보다 진입 장벽이 훨씬 낮고, 유지보수를 Cursor가 맡습니다.

정리하면

Workspace 플러그인 3종(8/3) = Gmail·드라이브·캘린더를 에디터 안에서 읽고 쓰기. 설치는 쉽고 쓸모는 분명하지만, 권한 문서화가 따라오는 중이라 읽기 시나리오부터 계단식으로. 저는 드라이브 검색부터 붙여봤는데, 스펙 문서 왕복이 사라진 것만으로도 남는 장사였습니다. 권한 정책이 문서화되면 이어서 다룰게요.

참고 자료

Google Workspace Plugins (Cursor 공식 체인지로그)
Cursor Marketplace
Cursor 공식 발표 (X)

AI 플러그인 표준 전쟁, 싱겁게 끝났다 — Agent Plugins 1.0 정리 (2026)

DevPilot — Tue, 18 Aug 2026 12:44:55 +0900

핵심 요약: 8월 6일, Agent Plugins 1.0이 공개됐습니다 — 에이전트용 스킬과 MCP 서버를 하나의 설치 가능한 플러그인으로 묶는 오픈 표준이에요. 놀라운 건 명단입니다: AWS·Anysphere(Cursor)·Microsoft·OpenAI·Vercel이 공동 발표했고, 같은 날 Google이 코어 메인테이너로 합류했어요. 지원 클라이언트도 ChatGPT, Codex, Cursor, GitHub Copilot, Kiro, VS Code — 경쟁사들이 한 포맷에 서명한 겁니다. 구조는 단순합니다: plugin.json 매니페스트 + skills/ 폴더 + mcp.json, 벤더 전용 기능은 네임스페이스 폴더로 격리(다른 클라이언트는 무시). 8월 12일부터 Copilot 쪽은 VS Code·CLI·SDK·앱 전 플랜에서 정식 지원(GA)이고, Cursor도 자체 포맷과 병행 지원합니다. 개발자 입장에서는 "클라이언트마다 따로 패키징"하던 중복이 사라지는 변화예요.

원래 이 글의 가제는 "플러그인 표준 전쟁"이었습니다. Cursor Marketplace와 Copilot 플러그인이 각자 생태계를 굳히는 그림을 예상했거든요. 자료를 모아 보니 결론이 반대였습니다 — 전쟁이 아니라 통일이었어요.

무슨 일: 경쟁사들이 한 포맷에 서명했다

8월 6일 발표된 Agent Plugins 1.0은 특정 회사 소유가 아닌 독립 거버넌스의 오픈 표준입니다. 공동 발표사가 AWS, Anysphere(Cursor 개발사), Microsoft, OpenAI, Vercel — 그리고 같은 날 Google이 코어 메인테이너로 들어왔습니다.

작년의 MCP가 "에이전트와 도구를 잇는 규격"(개념 정리)이었다면, 이번엔 그 위 계층입니다. 스킬(작업 지침 패키지)과 MCP 서버 설정을 배포 가능한 하나의 꾸러미로 묶는 포장 규격이에요. MCP 사양이 7월에 확정된 것(그 정리)과 이어지는 흐름입니다 — 규격이 안정되니 그걸 담는 상자도 표준화되는 순서죠.

▲ 만드는 쪽과 쓰는 쪽 명단입니다. 서로 경쟁하는 회사들이 한 줄에 서 있는 게 이 발표의 핵심이에요.

구조: 폴더 하나, 매니페스트 하나

플러그인의 실체는 폴더입니다. 필수는 plugin.json 매니페스트 하나이고, 스킬은 skills/ 폴더에, MCP 서버 선언은 mcp.json에 들어갑니다. 호환 클라이언트는 같은 패키지에서 자기가 지원하는 부분만 읽어가요.

재치 있는 부분은 벤더 전용 기능의 처리입니다. 표준이 커버하지 않는 것들 — 예컨대 Copilot의 커스텀 에이전트·훅 — 은 com.github.copilot/ 같은 네임스페이스 폴더에 넣고, 다른 클라이언트는 그 폴더를 무시합니다. 하나의 패키지가 이식성과 벤더 기능을 다 갖는 구조예요.

▲ 폴더 구조가 곧 스펙입니다. 기존 플러그인을 옮기는 것도 대부분 매니페스트 작업이에요.

지금 당장 뭐가 되나

Copilot 쪽은 8월 12일부터 정식 지원입니다 — VS Code, Copilot CLI, Copilot SDK, Copilot 앱, 전 플랜. Awesome Copilot 마켓플레이스가 기본 탑재돼서 거기서 표준 플러그인을 바로 설치할 수 있어요. 기존 Copilot 플러그인은 마이그레이션 없이 계속 동작합니다.

Cursor 쪽은 자체 플러그인 포맷과 병행 지원입니다. Customize 페이지나 Cursor Marketplace에서 설치·관리하고요. 개발자라면 이제 배포 런북 스킬 + 그 도구의 MCP 서버를 한 패키지로 묶어 "한 번 만들고 ChatGPT·Codex·Cursor·Copilot에 다 배포"가 됩니다 — 지금까지는 클라이언트마다 매니페스트와 폴더 구조를 따로 유지했어요.

팀 관리자용 장치도 처음부터 들어 있습니다. Copilot Business·Enterprise는 기존 managed-settings.json으로 플러그인 자동 설치·차단(enabledPlugins), 마켓플레이스 허용 목록(strictKnownMarketplaces)을 걸 수 있고, 플러그인이 MCP 서버를 실어 나르는 만큼 MCP 허용 목록과 짝지어 쓰는 게 권장이에요.

관전 포인트: 명단에 없는 이름

발표를 여러 번 읽으면서 눈에 걸린 건 있는 이름이 아니라 없는 이름이었습니다 — 메인테이너에도, 출시 시점 지원 클라이언트에도 Anthropic(Claude Code)이 없어요. Claude Code는 자체 플러그인·마켓플레이스 체계를 갖고 있는데, 이 표준에 합류할지는 현재로선 발표된 바 없습니다.

표준의 힘은 결국 참여 폭이 정합니다. 지금 명단만으로도 충분히 무겁지만, 에이전트 코딩의 큰 축 하나가 바깥에 있는 동안은 "사실상 통일"이라고 부르긴 이르죠. 이 부분은 움직임이 나오면 갱신하겠습니다.

자주 묻는 질문 (FAQ)

Q. 기존에 쓰던 플러그인은 어떻게 되나요?

A. 그대로 동작합니다. Copilot은 표준을 따르지 않는 기존 플러그인도 계속 지원한다고 명시했고, Cursor도 자체 포맷과 병행 지원입니다. 마이그레이션은 선택이에요.

Q. MCP와는 뭐가 다른가요?

A. 계층이 다릅니다. MCP는 에이전트와 외부 도구를 연결하는 통신 규격이고, Agent Plugins는 스킬과 MCP 서버 설정을 묶어 배포하는 포장 규격입니다. 플러그인 안에 mcp.json이 들어가는 관계예요.

Q. 플러그인을 만들려면 뭐부터 보면 되나요?

A. plugin.json에 $schema를 추가하고 skills/와 mcp.json 구조를 맞추는 게 시작입니다. 공식 스펙 문서와 예제 플러그인·마이그레이션 가이드가 공개돼 있습니다(아래 참고 자료).

오늘의 결론

Agent Plugins 1.0 = 스킬+MCP 서버를 한 꾸러미로 묶는 오픈 표준(8/6 공개, Copilot은 8/12 전면 GA, Cursor 병행 지원). 개발자는 한 번 만들어 여러 에이전트에 배포, 사용자는 마켓플레이스에서 설치, 기업은 기존 관리 설정 그대로. 남은 변수는 참여 폭 — 특히 명단 밖의 Claude Code가 어느 쪽으로 움직이는지입니다.

참고 자료

Agent Plugins 1.0 in VS Code, Copilot CLI, and the Copilot app (GitHub Changelog)
Agent Plugins 1.0 공식 스펙
Cursor Plugins 문서

Cursor 클라우드 에이전트가 3배 빨라졌다 — 어제부터 자동 적용된 'builds'의 정체 (2026)

DevPilot — Mon, 17 Aug 2026 19:44:25 +0900

핵심 요약: 8월 13일 Cursor가 builds를 공개했습니다 — 클라우드 에이전트의 개발 환경을 백그라운드에서 미리 만들어두는 기능이에요. 지금까지는 에이전트를 시킬 때마다 머신 부팅→저장소 클론→의존성 설치를 그 자리에서 했는데(큰 저장소면 몇 분), 이제는 완성된 환경을 포크해서 바로 시작합니다. 결과: 시작 최대 3배 빨라짐, Cursor 내부 기준 부팅 10배·첫 토큰 3배. 추가 요금 없고, 8월 17일부터 전 환경에 기본 적용이라 대부분은 아무것도 안 해도 됩니다. 다만 환경 설정을 직접 만져둔 팀이라면 확인할 게 셋 있어요(install 커맨드 범위, 시크릿 종류, start 커맨드 용도) — 아래에서 정리합니다.

월요일 아침에 클라우드 에이전트를 하나 돌렸는데, 평소보다 빨리 첫 응답이 왔습니다. 착각인가 했더니 아니었어요 — 어제(17일)부터 builds가 전 환경 기본값이 됐거든요. 지난주 발표를 이제야 제대로 정리합니다.

뭐가 문제였나: 매번 "그 자리에서" 차리던 밥상

클라우드 에이전트(개념 정리)의 고질적인 대기 시간은 모델이 아니라 환경이었습니다. 작업을 맡길 때마다 VM을 부팅하고, 저장소를 클론하고, install 스크립트를 처음부터 끝까지 돌렸어요.

작은 프로젝트면 참을 만한데, 모노레포급이면 에이전트가 일을 시작하기도 전에 몇 분이 갑니다. "맡기고 잊기"가 장점인 기능에서 시작이 느리다는 건 꽤 아픈 부분이었죠.

builds의 원리: 미리 지어두고, 포크한다

builds는 그 준비 과정을 백그라운드로 옮긴 것입니다. Cursor가 기본 1시간마다 내 개발 환경의 완성본(클론·의존성·install 완료 상태)을 미리 만들어두고, 에이전트는 그 위에서 바로 출발해요.

디테일이 하나 더 있는데 — 디스크에서 복원하는 게 아니라 살아 있는 머신을 포크합니다. 따뜻하게 데워둔 복사본에서 시작하니 세션이 거의 즉시 열려요. 파일시스템 스냅샷 기반이라 추가 요금도 없습니다.

▲ 위가 지금까지, 아래가 builds입니다. 밥상을 매번 차리느냐, 차려둔 밥상에 앉느냐 차이예요.

속도만이 아니라 "안 깨지는" 것도 포인트

제가 더 좋다고 느낀 건 사실 이쪽입니다. 의존성 업데이트나 잘못된 커밋으로 install이 깨지면, 그 빌드는 활성화되지 않고 알림만 옵니다. 에이전트들은 마지막으로 성공한 빌드에서 계속 일해요.

환경이 깨져서 에이전트 전체가 멈추는 상황이 구조적으로 사라지는 겁니다. 대시보드에 Builds 탭이 생겨서 빌드별 로그·커밋 SHA·어느 에이전트가 어느 빌드를 썼는지도 추적되고, 에이전트가 Cursor Cloud MCP로 빌드를 직접 조회·관리할 수도 있어요.

내가 할 일: 대부분은 없음, 팀은 셋만 확인

8월 17일부터 신규·기존 환경 모두 기본 적용이라, 개인 사용자는 체감만 하면 됩니다. 환경 설정을 직접 만져둔 팀이라면 스냅샷 방식 특성상 세 가지를 확인하세요.

▲ 셋 다 "빌드 시점에 도는 것 vs 세션 시점에 도는 것"의 구분 문제입니다.

정리하면 — ① install 커맨드에 미리 준비 가능한 건 다 몰아넣기(의존성 설치 등, 여기 있는 것만 빌드에 미리 반영됨) ② 프라이빗 레지스트리 인증은 팀·환경 시크릿으로(개인 시크릿은 빌드에 포함되지 않고 에이전트 시작 때 주입) ③ start 커맨드는 여전히 세션 시작 시 실행되니 Docker 컨테이너처럼 갓 띄워야 하는 것만 남기기. CI에서 CLI로 에이전트를 돌리는 팀(CLI 글)이나 Automations 사용자(그 정리)일수록 효과가 큽니다 — 자동 실행은 시작 지연이 그대로 누적되던 영역이니까요.

자주 묻는 질문 (FAQ)

Q. builds는 유료 기능인가요?

A. 아니요, 추가 비용 없이 제공됩니다. 8월 17일부터 신규·기존 환경 모두 기본 적용됐습니다.

Q. 빌드가 실패하면 에이전트가 멈추나요?

A. 멈추지 않습니다. 실패한 빌드는 활성화되지 않고, 에이전트는 마지막 성공 빌드에서 계속 실행됩니다. 실패 알림을 받고 백그라운드에서 고치면 됩니다.

Q. 빌드는 얼마나 자주 갱신되나요?

A. 기본 1시간마다 새 빌드를 만듭니다. 빌드가 기본 브랜치에서 너무 뒤처지지 않도록 git 상태 임계값도 설정할 수 있습니다.

3줄 요약

builds = 클라우드 에이전트 환경을 백그라운드에서 미리 완성해두는 기능(8/13 공개, 8/17 전 환경 기본 적용, 무료). 시작 최대 3배·부팅 10배 빨라지고, 환경이 깨져도 마지막 성공 빌드로 계속 돈다. 개인은 할 일 없음 — 팀만 install·시크릿·start 커맨드 세 가지 확인.

참고 자료

Cloud agents start 3x faster with builds (Cursor 공식 블로그)

Grok Bot이란? 내가 자는 동안 일하는 '상시형' AI 동료의 실체 (2026)

DevPilot — Sun, 16 Aug 2026 15:53:25 +0900

핵심 요약: 8월 11일 베타로 나온 Grok Bot은 지금까지의 AI 에이전트와 작동 단위가 다릅니다 — 세션(일 시키고 끝나면 종료)이 아니라 상시 가동이에요. 봇마다 전용 클라우드 컴퓨터를 받고, 내 계정으로 내 앱들에 로그인해서, 내가 노트북을 덮고 잔 뒤에도 계속 일합니다. 사람은 판단이 필요할 때만 호출되고, 봇은 대화를 기억하며 내 방식을 학습해요. 말 그대로 "동료" 콘셉트입니다. 접근은 셋뿐 — SuperGrok Heavy(월 ~$300), Cursor Ultra($200), Cursor Teams Premium(시트당 $120) 구독자 대상 베타(7일 체험 있음). 흥미로운 물건이지만 제 결론은 신중 쪽입니다: "내 계정으로 로그인하는 상시 에이전트"는 편리함의 단위가 아니라 위임의 단위가 바뀌는 일이라서요. 아래에서 뭐가 다르고, 누가 써볼 만하고, 뭘 조심해야 하는지 정리합니다.

어제 SpaceX 인수 글(그 정리)에서 "Grok Bot이 사흘 먼저 들어왔다"고 지나가듯 썼는데, 그게 뭔지 묻는 분들이 있었습니다. 오늘은 그 물건 자체를 봅니다.

세션형과 상시형: 작동 단위가 다르다

지금까지 우리가 쓰던 에이전트는 전부 세션형입니다. Claude Code도, Devin도, Cursor의 클라우드 에이전트도 — 작업을 주면 시작하고, 끝나면 꺼져요.

Grok Bot은 안 꺼집니다. 자기 클라우드 컴퓨터에서 상주하며, 맡은 역할(메일 분류, 이슈 정리, 모니터링 같은)을 계속 수행하다가, 사람의 결정이 필요한 순간에만 말을 겁니다. 대화를 기억하고 선호를 학습한다는 점까지 합치면 — "일 시키는 도구"보다 "채용한 직원"에 가까운 설계예요.

▲ 왼쪽이 지금까지의 에이전트, 오른쪽이 Grok Bot입니다. 차이는 성능이 아니라 존재 방식이에요.

핵심이자 논쟁점: "내 계정으로" 로그인한다

이 제품의 가장 대담한 설계가 이겁니다 — 봇이 나로서(as you) 내 도구들에 로그인합니다. 별도 API 연동이 아니라, 사람이 쓰는 그 화면을 그대로 조작해요.

편리함의 이유이자 불안함의 이유죠. API가 없는 서비스까지 전부 다룰 수 있게 되는 대신, 봇에게 넘어가는 건 계정 그 자체입니다. Comet 브라우저 때(그 글) "계정 위임은 단계적으로"라고 썼는데, Grok Bot은 그 위임을 상시로, 잠든 시간까지 확장하는 물건입니다. 시크릿·계정 보안의 기본기(그 체크리스트)가 어느 때보다 전제 조건이 돼요.

누가 쓸 수 있나: 게이트가 셋뿐

▲ 단독 구독 상품이 아니라는 게 포인트. 프리미엄 생태계의 "번들"입니다.

Grok Bot만 따로 살 수는 없습니다. SuperGrok Heavy(월 ~$300) / Cursor Ultra($200) / Cursor Teams Premium(시트당 $120) — 이 셋 중 하나를 이미 내고 있어야 베타 접근이 열려요(7일 무료 체험 제공). 맥·윈도우·리눅스·iOS에서 쓸 수 있고 안드로이드는 예고 상태입니다.

이 게이팅이 어제 글에서 말한 "Ultra 값어치 재계산"의 실체입니다 — Ultra가 "사용량 최대 플랜"에서 "Grok Bot 입장권이 딸린 플랜"으로 성격이 하나 늘었어요. 인수 마무리 사흘 전에 이 번들이 나온 건 우연이 아니겠죠.

그래서 써볼 만한가

솔직한 답: 대부분의 개인 개발자는 아직입니다. 이유는 간단해요 — 이미 Ultra급을 내는 사람이 아니라면 입장료가 월 $200부터고, 상시형의 가치는 "위임할 반복 업무가 상시로 존재하는 사람"에게만 성립합니다. 하루 한두 번 코딩 시키는 패턴이면 세션형(지금 쓰는 그것)이 정확한 도구예요.

반대로 써볼 만한 경우 — 이미 Ultra·Teams Premium을 내고 있고(추가 비용 0), 메일 분류·이슈 트리아지·모니터링처럼 "끊기지 않는 잡무"가 실제로 있는 경우. 그렇다면 7일 체험으로 잡무 하나만 맡겨보세요. 단, 시작은 민감하지 않은 계정부터 — 이건 타협 없이요.

자주 묻는 질문 (FAQ)

Q. Grok Bot만 따로 구독할 수는 없나요?

A. 현재 베타 기준으로는 없습니다. SuperGrok Heavy, Cursor Ultra, Cursor Teams Premium 중 하나의 구독에 딸려오는 구조입니다.

Q. Claude Code나 Devin과 뭐가 다른가요?

A. 그쪽은 작업 단위로 켜졌다 꺼지는 세션형이고, Grok Bot은 클라우드에 상주하는 상시형입니다. 코딩 작업 위임이 목적이면 세션형이 여전히 정확한 도구이고, 끊기지 않는 잡무의 상시 처리가 목적일 때 Grok Bot의 설계가 맞습니다.

Q. 봇이 내 계정으로 로그인하는 게 안전한가요?

A. 허가·호출 구조가 있다 해도 위임 범위가 넓은 건 사실입니다. 체험한다면 민감하지 않은 계정부터, 결제·업무 핵심 계정은 신뢰가 쌓인 뒤에 — Comet 때와 같은 원칙을 권합니다.

오늘의 결론

Grok Bot = 상시형 AI 동료(전용 클라우드 컴퓨터, 내 계정으로 로그인, 잘 때도 가동). 입장은 $120~300 프리미엄 구독 3종뿐, 7일 체험 있음. 세션형과는 용도가 다른 물건이라 대부분은 아직이고 — 이미 Ultra를 내는 분만 잡무 하나로 체험해보세요. 저는 이 "상시 위임"이라는 방향 자체가 하반기의 큰 이야기가 될 거라고 보고, 후속 소식이 나오면 이어서 다루겠습니다.

참고 자료

Introducing Grok Bot (SpaceXAI 공식)
VentureBeat 보도

Cursor, 이제 SpaceX 소속 — 개발자에게 실제로 뭐가 바뀌나 (2026)

DevPilot — Sat, 15 Aug 2026 16:37:13 +0900

핵심 요약: 8월 14일, SpaceX가 Cursor의 모회사 Anysphere 인수를 마쳤습니다 — 600억 달러, 전액 주식 교환, Cursor는 신설 SpaceXAI 사업부의 완전 자회사가 됐어요. 그래서 내일부터 뭐가 달라지냐면: 당장은 아무것도 안 달라집니다. 요금제 그대로, 프라이버시 모드 그대로, 에디터도 그대로예요. 대신 지켜볼 변수가 셋 있습니다 — ① Grok 계열 모델의 편입 가속(이미 8/11에 Ultra 플랜에 Grok Bot이 들어왔죠) ② Colossus 슈퍼컴퓨터 접근 — 자체 모델 Composer의 성능 곡선이 바뀔 수 있는 대목 ③ 소유주가 바뀐 회사의 정책은 결국 바뀐다는 올해의 교훈. 결론: 갈아탈 이유는 없고, 다만 워크플로를 도구 중립으로 유지하는 평소 원칙이 이럴 때를 위한 겁니다.

금요일 밤에 뉴스가 떴고, 주말 내내 커뮤니티가 시끄러웠습니다. "커서 구독 해지해야 하나요?"라는 질문까지 봤어요. 결론부터 말하면 그럴 일은 아닌데, 왜 그런지 순서대로 보시죠.

무슨 일이 있었나: 6월 발표, 8월 종결

시간순으로 정리하면 이렇습니다. 6월 말에 인수 합의가 발표됐고, 규제 절차를 거쳐 8월 14일에 거래가 마감됐습니다. 규모는 600억 달러 — 현금이 아니라 전액 주식 교환입니다. Cursor 주주들이 SpaceX 주식(나스닥 SPCX)을 받는 구조예요.

Cursor는 이제 SpaceXAI라는 새 사업부 아래의 완전 자회사입니다. 흡수합병이 아니라 자회사 유지라는 게 포인트 — 팀과 제품은 그대로 굴러갑니다.

▲ 6월에 발표됐던 그 딜이 맞습니다 — 두 달 만에 종결됐어요.

당장 바뀌는 것: 사실상 없음

구독자 입장에서 확인한 것들 — 요금제 무변동(Free·Pro $20·Pro+ $60·Ultra $200 그대로), 프라이버시 모드 유지, 에디터·기능 변화 없음. 인수 종결 당일에도 평소처럼 업데이트가 나왔습니다.

저도 그날 아침에 평소처럼 Cursor를 열었는데, 달라진 건 뉴스 알림뿐이었어요. 소유권 이전이라는 게 원래 그렇습니다 — 서류는 요란하고 제품은 조용하죠.

지켜볼 변수 셋

① Grok 편입 가속. 사실 신호는 인수 종결 전부터 있었습니다 — 8월 11일에 Ultra 플랜에 Grok Bot(상시 대기 에이전트, 원래 별도 구독 필요)이 번들로 들어왔어요(요금 글에 반영해뒀습니다). 같은 지붕 아래가 됐으니 이 흐름은 빨라질 겁니다. 모델 선택지가 늘어나는 건 이득인데, 기본값이 어디로 기우는지는 지켜봐야죠.

② Colossus 컴퓨트. 발표에서 눈여겨볼 실익은 이겁니다 — Cursor가 SpaceX의 슈퍼컴퓨터 인프라에 접근하게 됐다는 것. 자체 모델 Composer를 키우는 회사에게 컴퓨트는 곧 성능입니다. Composer가 프론티어급으로 치고 올라오면 "Auto 모드만 써도 충분한" 날이 앞당겨질 수 있어요.

③ 정책 변화의 전례. 그런데 의외로 제일 무거운 변수는 기술이 아니라 역사입니다. 올해 상반기에만 소유·방향이 바뀐 도구들이 어떻게 됐는지 우리는 봤잖아요 — Windsurf, Atlas. 인수 직후엔 다들 "아무것도 안 바뀐다"고 말합니다. 그리고 반년쯤 지나 요금표가 바뀌죠. 단정이 아니라 확률의 문제고, 그래서 다음 섹션이 필요합니다.

▲ 요약하면 이 세 칸입니다. 오른쪽 칸만 가끔 들여다보면 됩니다.

그래서 뭘 하면 되나

솔직히, 대부분은 아무것도 안 해도 됩니다. 해지도, 이사도, 백업 소동도 불필요해요.

딱 두 부류만 체크리스트가 있습니다. 회사 코드로 쓰는 조직 — 소유권이 바뀌면 보안·컴플라이언스 재검토가 관례입니다. 프라이버시 모드 정책 문서가 갱신되는지 한 번 확인하세요. 도구 의존이 깊은 개인 — 설정과 규칙을 도구 중립 파일로 빼두는 습관(이탈 전략 글)이 정확히 이런 날을 위한 보험입니다. 저는 인수 뉴스를 보고 AGENTS.md를 오랜만에 열어 정리했습니다. 5분 걸렸어요.

자주 묻는 질문 (FAQ)

Q. 커서 요금이 오르나요?

A. 인수 시점 기준 변동 없습니다. 개인 Free·Pro·Pro+·Ultra 전부 그대로이며, 변동이 생기면 이 글과 요금 글을 갱신하겠습니다.

Q. 내 코드가 SpaceX로 넘어가는 건가요?

A. 프라이버시 모드 등 기존 데이터 정책은 유지된 상태입니다. 다만 소유권 변경 후 정책 문서 개정은 흔한 수순이니, 민감한 코드를 다루는 조직이라면 개정 공지를 구독해두는 것을 권합니다.

Q. Grok 모델을 강제로 쓰게 되나요?

A. 아니요, 모델 선택권은 그대로입니다. 현재로선 Ultra 플랜에 Grok Bot이 추가 혜택으로 들어온 정도이고, 기본값 변화가 생기면 그때 다룰 일입니다.

3줄 요약

8/14 SpaceX가 Cursor 인수 완료($60B 전액 주식, SpaceXAI 자회사). 당장 바뀌는 건 없음 — 요금·프라이버시·제품 그대로. 지켜볼 건 Grok 편입·Colossus 컴퓨트·정책 변화 전례, 그리고 내가 할 일은 도구 중립 습관 하나면 충분합니다.

참고 자료

SpaceX completes $60B acquisition of Cursor (Seeking Alpha)
Cursor 공식 사이트

갤럭시 AI 끄는 법: 전부 끄기 전에, 목적부터 정하세요 (2026)

DevPilot — Sat, 15 Aug 2026 08:48:50 +0900

핵심 요약: 갤럭시에는 "AI 전부 끄기" 버튼이 없습니다 — 대신 목적별로 다른 스위치가 있어요. ① 개인정보가 걱정이면: 끄는 것보다 설정 → Galaxy AI → "기기 내 데이터 처리만" 토글이 정답에 가깝습니다(AI는 쓰되 데이터가 서버로 안 나감) + 퍼스널 데이터 인텔리전스 끄기(분석 데이터 삭제됨). ② 자꾸 튀어나와서 거슬리면: 기능별 토글로 — 홈 버튼 길게 눌러 뜨는 서클 투 서치, 키보드의 채팅 어시스트, 통화 요약 등 각각 끌 수 있습니다. ③ 아예 안 쓰고 싶으면: Gemini 앱 비활성화(설정 → 애플리케이션)까지. 배터리 걱정은 참고로 과장된 편입니다 — 온디바이스 AI는 부를 때만 돌아서, 끈다고 대기 배터리가 눈에 띄게 늘진 않아요. 메뉴 이름은 원UI 버전에 따라 조금 다를 수 있으니 설정 검색창을 활용하세요.

갤럭시 AI 유료화 팩트체크(그 글)를 쓰고 나서 "그런데 이거 끄는 법은요?"라는 검색이 따라온다는 걸 알았습니다. 끄려는 이유가 사람마다 달라서, 이유별로 정리하는 게 맞겠더라고요.

먼저: 왜 끄려고 하세요?

끄기 전에 30초만 — 목적이 뭔지에 따라 눌러야 할 스위치가 다릅니다. 개인정보형("내 데이터가 어디로 가는지 모르겠다"), 거슬림형("의도 안 했는데 자꾸 뜬다"), 완전 차단형("그냥 다 꺼줘"). 아래 순서대로 보시고 자기 유형 섹션만 따라 하시면 됩니다.

① 개인정보형: 끄지 말고 "기기 안에 가두세요"

의외의 답부터 — 프라이버시가 걱정이라면 기능을 끄는 것보다 나은 스위치가 있습니다. 설정 → Galaxy AI → "기기 내 데이터 처리만"을 켜면, 클라우드로 나가야 하는 AI 처리를 막고 폰의 NPU에서 처리 가능한 기능만 동작합니다. 통역·요약 같은 핵심 기능 상당수는 온디바이스로 돌아서 체감 손실이 생각보다 작고, "기능은 쓰되 데이터는 안 보낸다"는 절충이 성립해요. 여기에 더해 같은 메뉴의 퍼스널 데이터 인텔리전스(개인 데이터 분석)를 끄면 폰이 내 사용 패턴을 분석해둔 데이터도 삭제됩니다. 이 두 개가 개인정보형의 핵심 스위치입니다.

② 거슬림형: 튀어나오는 것들만 골라 끄기

실수로 자꾸 발동되는 것들의 개별 스위치입니다(메뉴 위치는 원UI 버전별로 다를 수 있어 설정 검색어를 병기합니다):

서클 투 서치(홈 버튼·바 길게 누르면 뜨는 검색) — 설정에서 "서클 투 서치" 검색 → 끄기. 내비게이션 방식에 따라 디스플레이 → 내비게이션 바 안에 있습니다. 사이드 버튼의 AI 호출(길게 누르면 어시스턴트) — 설정 → 유용한 기능 → 사이드 버튼에서 "전원 끄기 메뉴"로 변경. 키보드 채팅 어시스트(문자 쓸 때 뜨는 AI 제안) — 설정 → 일반(삼성 키보드) → AI 관련 토글 끄기. 통화 요약·통역 — 전화 앱 → 설정 → 통화 어시스트에서 개별 끄기. 갤러리 포토 어시스트 — 갤러리 설정에서 끄기. 전부 끌 필요 없이, 나를 귀찮게 한 그 기능만 끄면 됩니다.

③ 완전 차단형: 그래도 다 끄고 싶다면

순서대로 — ①의 "기기 내 데이터 처리만" 켜기 → ②의 기능별 토글 전부 끄기 → 마지막으로 설정 → 애플리케이션 → Gemini → 사용 안 함(기본 어시스턴트가 Gemini로 잡혀 있다면 어시스턴트 앱 설정에서 '없음'으로 먼저 변경). 이렇게 하면 일상 사용에서 AI가 등장할 일은 사실상 없어집니다. 다만 알아둘 것 — 시스템에 통합된 일부 요소(검색 제안 등)까지 뿌리째 제거하는 공식 방법은 없고, 그건 갤럭시만이 아니라 요즘 폰 전반의 조건입니다(아이폰도 같은 사정 — 폰 AI 비교 참고).

배터리 얘기: 솔직한 기대치

"AI 끄면 배터리가 확 좋아진다"는 기대는 조정이 필요합니다. 갤럭시 AI의 온디바이스 기능은 부를 때만 NPU를 돌리는 구조라 대기 전력에 주는 영향이 크지 않아요. 배터리가 급격히 닳는다면 범인은 대개 다른 곳(화면, 5G, 백그라운드 앱)입니다. AI를 꺼서 얻는 실익은 배터리보다 오작동 스트레스 감소와 데이터 통제감 쪽이라고 보는 게 정직합니다.

끄기 전에 하나만: 남겨둘 가치가 있는 것

전부 끄기 전에 한 번만 생각해볼 기능 둘 — 실시간 통역(전화·대면 모두, 여행·외국어 통화에서 진가)과 서클 투 서치(거슬림형 1위지만, 익숙해지면 "이게 뭐지?"를 해결하는 가장 빠른 길이기도). 저는 서클 투 서치를 껐다가 2주 만에 다시 켠 쪽입니다. 끄는 건 언제든 되니까, "한 달 안 쓰면 끄기" 정도의 유예를 권합니다.

자주 묻는 질문 (FAQ)

Q. 갤럭시 AI를 한 번에 전부 끄는 버튼은 없나요?

A. 없습니다. 설정 → Galaxy AI에서 데이터 처리 방식을 통제하고, 기능별 토글을 개별로 꺼야 합니다. 이 글의 유형별 순서를 따라 하면 5분 안에 끝납니다.

Q. "기기 내 데이터 처리만"을 켜면 뭐가 안 되나요?

A. 클라우드 처리가 필요한 일부 기능(고급 생성 기능 등)이 제한되거나 품질이 낮아질 수 있습니다. 통역·요약 등 상당수는 온디바이스로 동작해 체감 차이가 작은 편입니다.

Q. 껐다가 다시 켜면 원래대로 돌아오나요?

A. 네, 기능 토글은 언제든 되돌릴 수 있습니다. 단 퍼스널 데이터 인텔리전스를 끄며 삭제된 분석 데이터는 다시 쌓이는 데 시간이 걸립니다.

한눈에 보는 요약

개인정보 걱정 = "기기 내 데이터 처리만" + 퍼스널 데이터 인텔리전스 끄기. 거슬림 = 그 기능만 개별 토글. 완전 차단 = 위 두 단계 + Gemini 앱 비활성화. 배터리 효과는 기대보다 작고, 통역과 서클 투 서치는 끄기 전에 한 달만 유예를.

참고 자료

갤럭시 AI 공식 페이지 (삼성전자)
삼성 멤버스 커뮤니티 (설정 관련 공식 답변)

AI로 블로그 운영하는 실제 워크플로 공개: 프롬프트가 아니라 루프입니다

DevPilot — Fri, 14 Aug 2026 13:03:49 +0900

핵심 요약: 요즘 SNS에 "이 프롬프트 7개면 블로그로 돈 번다"는 글이 자주 돕니다. 저도 AI로 블로그를 운영하지만, 두 달 해보고(그리고 애드센스에 두 번 떨어져 보고) 내린 결론은 반대입니다 — 핵심은 좋은 프롬프트가 아니라 좋은 루프입니다. 프롬프트는 AI에게 "그럴듯한 추측"을 시키지만, 루프는 실측 데이터가 다음 행동을 정하게 만들거든요. 이 글에서 제가 매일 돌리는 5단계를 실데이터 사례와 함께 전부 공개합니다: ① 주제는 묻지 않고 본다(서치콘솔) ② 조사는 해외까지 ③ 초안은 AI, 검증은 사람 ④ 그림은 직접 그린다 ⑤ 발행 후가 진짜 시작(링크·제목·재색인 루프). 특별한 도구도, 비밀 프롬프트도 없습니다 — 순서와 데이터가 전부입니다.

먼저 밝혀둡니다: 이 블로그의 글은 AI 도구로 초안을 만들고 제가 검증·편집합니다(작성 원칙에 공개돼 있어요). 그래서 이 글은 "AI 쓰지 마세요"가 아니라, "AI를 쓰되 어디에 사람과 데이터를 배치해야 하는가"에 대한 실전 기록입니다.

왜 프롬프트가 아니라 루프인가

"수익 나는 주제를 추천해줘"라고 AI에게 물으면 답이 나옵니다 — 그럴듯하고, 누구에게나 같은 답이요. 문제는 그 답이 추측이라는 겁니다. AI는 내 블로그에 지금 어떤 검색이 꽂히는지 모르니까요. 제가 한 달간 하루 대여섯 편씩 쏟아내다 배운 것(그 전말)이 이거였습니다: 생산은 AI가 도와줘도, 방향은 데이터가 정해야 한다. 그래서 아래 5단계는 전부 "무엇을 근거로 결정하는가"를 중심으로 설계돼 있습니다.

① 주제는 AI에게 묻지 않고, 데이터에서 본다

매일 아침 서치콘솔 실적을 봅니다. 보는 건 두 가지 — "노출은 있는데 클릭이 없는 쿼리"(내 글이 약하거나 없는 자리)와 "대응 글이 아예 없는 쿼리"(신규 글감). 실례: 어느 날 "잰스파크"라는 오타형 검색이 노출 545회에 클릭 1회로 잡혀 있었어요. AI에게 백 번 물어도 안 나올 주제죠. 표기 병기와 FAQ 대응으로 그 노출을 받아냈습니다. 또 "genspark cursor" 조합 검색 65회를 발견하고 보니 대응 글이 이미 있는데 제목이 영문이라 못 받고 있더군요 — 신규가 아니라 제목 수정이 답인 경우였고, 이것도 데이터만이 알려줍니다.

② 조사는 공식 문서 + 해외 소스까지

초안을 시키기 전에 재료를 모읍니다 — 공식 문서·공식 블로그(가격·기능의 유일한 근거), 그리고 해외 리뷰·포럼(실사용자의 패턴과 불만). 이 두 번째가 글의 고유값을 만듭니다. 실례: Orca라는 도구를 다룰 때 해외 사용자들 사이에 "같은 작업을 에이전트 셋에 동시에 시키고 diff를 비교해 체리픽한다"는 운용 패턴이 정착돼 있다는 걸 발견했는데, 이건 공식 문서에 없는 내용이에요. 요약만 하는 글과 관찰이 든 글의 차이가 여기서 갈립니다.

③ 초안은 AI, 사실 확인과 목소리는 사람

재료가 모이면 초안은 AI가 빠르게 만듭니다 — 여기까지는 프롬프트 팩과 같아 보이죠. 차이는 그다음입니다: 가격·날짜·기능 주장은 전부 공식 소스와 대조하고(참고 자료로 링크), 결론과 평가는 제 것으로 다시 씁니다. 한 달 전엔 이 검증을 느슨하게 했고, 그 결과가 "같은 골격의 글 180편"이었습니다. 지금은 문체도 글마다 바꿉니다 — 독자는 몰라도 되지만, 같은 틀의 반복은 사이트 전체의 신뢰를 갉아먹는다는 걸 심사로 배웠으니까요.

④ 그림은 직접 그린다

글마다 다이어그램 한 장 이상을 직접 만듭니다(코드로 그려서 블로그 톤 유지). 남의 이미지 복사는 저작권 문제이기 전에 고유성 문제예요 — 내가 그린 도식은 다른 어디에도 없는 콘텐츠입니다. 손익분기 그래프, 진단 플로우차트, 제품군 지도 같은 것들이 체류 시간과 공유를 눈에 띄게 바꿨습니다. 도구는 뭐든 됩니다 — 포인트는 "글의 논리를 한 장으로 압축한 그림"이라는 것.

⑤ 발행 후가 진짜 시작: 개선 루프

발행은 루프의 끝이 아니라 중간입니다. 주기적으로 세 가지를 돌립니다 — 내부 링크 감사(유입은 있는데 아무도 링크 안 거는 "고아 글" 찾기 — 링크를 놓아준 글이 다음 주 유입 2배가 된 사례가 있습니다), 제목 CTR 실험(노출 수백에 클릭 0인 글은 제목이 범인 — 환불 기한 숫자를 제목 앞으로 옮기는 식), 재색인 요청(제목을 고쳐도 재색인 전엔 효과 0이라는 걸 모르면 실험 자체가 무의미). 이 단계가 있어서 ①의 데이터가 다시 쌓이고, 루프가 돕니다.

이 워크플로의 비용

구독은 둘입니다 — 에디터형 하나, 에이전트형 하나로 월 $40. 블로그 운영만이라면 더 줄일 수도 있는데, 구독이 나은지 API 종량이 나은지는 결국 하루에 얼마나 시키느냐에 갈립니다 — 애매하면 AI 구독 vs API 비용 계산기에 사용량을 넣어보세요. 하루 몇 번부터 구독이 이득인지 바로 나옵니다. 그 외 비용은 $0 — 서치콘솔도, 그림 그리는 것도, 이 루프의 어디에도 유료 "비밀 도구"는 없습니다.

따라 한다면: 순서만 지키세요

이 루프의 요지는 도구가 아니라 순서입니다 — 데이터 → 조사 → 생산 → 고유화 → 개선. 프롬프트 팩의 문제는 내용이 아니라 순서예요: 생산에서 시작해 생산으로 끝나니까, 사이트는 커지는데 가치는 안 쌓입니다. 저는 그 방식으로 한 달을 달려봤고, 심사가 그걸 뭐라고 부르는지도 확인했습니다("가치가 별로 없는 콘텐츠"). 지금 방식이 느려 보여도, 발행량을 5분의 1로 줄이고 방문자가 그대로였다는 게 제 데이터가 준 답입니다.

자주 묻는 질문 (FAQ)

Q. 서치콘솔에 데이터가 쌓이기 전(블로그 초기)에는 뭘 근거로 하나요?

A. 초기엔 어쩔 수 없이 가설로 시작합니다. 다만 한 주제 클러스터를 정해 좁고 깊게 쓰면 데이터가 빨리 쌓이고, 노출이 잡히기 시작하는 4~6주 차부터 이 루프로 전환하면 됩니다.

Q. AI로 쓴 글이라고 검색에서 불이익이 있나요?

A. 구글의 공식 입장은 "작성 방식이 아니라 품질"입니다. 제 경험상 문제는 AI 사용 자체가 아니라 AI로 가능해진 속도와 균질함이었습니다 — 그걸 통제하는 게 이 루프의 목적입니다.

Q. 하루에 시간이 얼마나 드나요?

A. 신규 1편 + 개선 작업 기준으로 저는 오전 한나절입니다. 조사와 검증에 절반, 초안 다듬기와 그림에 절반 정도의 감각입니다.

한눈에 보는 요약

프롬프트가 아니라 루프 — 데이터(서치콘솔)로 방향을 정하고, 해외까지 조사하고, AI 초안을 사람이 검증하고, 그림으로 고유화하고, 발행 후 링크·제목·재색인을 돌립니다. 비밀 도구 없음, 순서가 전부입니다.

참고 자료

유용하고 신뢰할 수 있는 콘텐츠 제작 가이드 (구글 공식)
Google Search Console (공식)

AI 구독 vs API 종량, 뭐가 더 싼가: 손익분기 정하는 법 (2026)

DevPilot — Thu, 13 Aug 2026 10:04:38 +0900

핵심 요약: 같은 모델을 쓰는 두 가지 지불 방식 — 구독(월 정액 + 한도)과 API 종량(토큰당 과금) 중 뭐가 싼지는 결국 하루 요청 수와 요청당 토큰이 정합니다. 감을 잡을 기준점 하나: 가벼운 대화형 요청(입력 2천·출력 1천 토큰 안팎) 기준으로 Sonnet 5급 모델은 대략 하루 30~50회 언저리에서 구독($20)과 종량이 교차합니다. 그보다 적게 쓰면 종량이, 많이 쓰면 구독이 이득이죠. 단, 함정이 둘 있습니다 — ① 에이전트 작업은 요청당 토큰이 수십 배라 손익분기가 "하루 몇 회" 수준으로 뚝 떨어지고 ② 예고됐던 9월 Sonnet 5 API 인상은 취소돼(8/11 발표) $2/$10 기준으로 계산하면 됩니다. 아래에서 그래프와 함께 내 위치를 찾는 법을 정리합니다.

이번 주에 이 질문을 받을 일이 많았습니다 — Claude Code 부스트 종료(D-7 정리)를 앞두고 "구독을 올릴까, 차라리 API로 갈까"를 고민하는 분들이 늘어서요. 급하게 결정하기 전에, 이 계산의 구조부터 보시죠.

두 방식의 구조: 정액 뷔페 vs 계량 판매

구독은 뷔페입니다 — 월 $20(Pro급)을 내면 한도 안에서 먹는 만큼 이득이고, 한도가 천장이죠. API 종량은 계량 판매 — 입력·출력 토큰 단가(예: Sonnet 5 기준 백만 토큰당 입력 $3/출력 $15, 9월 표준가)에 쓴 만큼 냅니다. 천장이 없는 대신 바닥도 없어서, 안 쓴 달은 $0이에요. 그래서 원리는 단순합니다: 꾸준히 많이 = 구독, 가끔 몰아서 = 종량. 문제는 "많이"의 경계가 어디냐는 것.

손익분기: 그래프로 보기

가로축이 하루 요청 수, 세로축이 월 비용입니다. 구독은 수평선($20), 종량은 우상향 직선이고, 두 선이 만나는 점이 손익분기입니다. 관건은 종량선의 기울기 = 요청당 토큰인데, 여기서 패턴이 갈립니다 — 가벼운 대화형(질문·요약, 요청당 3천 토큰 안팎)이면 기울기가 완만해서 교차점이 하루 수십 회 지점에 오지만, 에이전트 작업(코드베이스 탐색·수정, 요청당 수만~수십만 토큰)은 기울기가 가팔라서 하루 몇 회만 돌려도 구독이 이깁니다. Claude Code를 매일 쓰는 사람에게 구독이 정답인 이유가 이 기울기예요.

계산에 넣어야 할 변수 세 가지

① 캐시 적중률 — API는 반복되는 컨텍스트(시스템 프롬프트, 문서)에 캐시 할인이 적용돼, 같은 작업을 반복하는 자동화라면 실효 단가가 크게 내려갑니다. ② 가격 변동 리스크 — 예고됐던 Sonnet 5의 9월 인상($3/$15)은 취소됐습니다(8/11 발표, $2/$10 영구화). 다만 "영구"도 시장 상황 따라 바뀌는 게 AI 단가라, 경계선에 있는 사람은 분기마다 재계산을 권합니다. ③ 내 시간 — 종량은 "얼마 나올까"를 신경 쓰는 비용이 있습니다. 계산이 뻔하게 구독 쪽이면, 미터기 신경 안 쓰는 값까지 구독에 포함된 셈으로 치세요.

내 위치 찾기: 패턴별 결론

매일 코딩에 에이전트를 쓴다 → 구독. 계산할 것도 없이 기울기가 답입니다. 부족하면 상향 검토(Pro vs Max). 한 달에 며칠, 프로젝트 있을 때만 몰아 쓴다 → 종량이 유력. 안 쓰는 주에 $0인 게 큽니다. 가벼운 질문 위주로 매일 조금씩 → 경계 지대라 계산이 필요합니다. 하루 요청 수와 평균 토큰이 사람마다 달라서 여기부터는 일반론이 무의미한데, AI 구독 vs API 비용 계산기에 자기 사용량을 넣어보면 하루 몇 번부터 구독이 이득인지 손익분기가 바로 나옵니다 — 캐시 적중률과 원화 환산(해외결제 수수료 포함)까지 반영되고, 단가를 직접 수정할 수 있어 9월 이후 가격으로도 비교됩니다. 자동화·CI 파이프라인 → 무조건 종량(구독은 개인 사용 약관 영역이기도 하고, 캐시·배치 최적화 여지도 종량 쪽에 있습니다).

흔한 실수 두 가지

"API가 항상 싸다"는 착각 — 에이전트 시대엔 반대인 경우가 많습니다. Claude Code 헤비 유저의 월 토큰량을 API 단가로 환산하면 구독료의 몇 배가 나오는 게 보통이에요. 구독의 한도는 제약이자 할인입니다. "구독했으니 API는 필요 없다"는 착각 — 자동화는 구독 사용량과 별도 주머니(API)로 돌리는 게 맞고, 그 비용은 따로 계산해야 합니다. 이 구분은 해지 시리즈에서 반복해 나온 그 원칙 — 소비자 구독과 API 계정은 별개 — 와 같은 이야기입니다.

자주 묻는 질문 (FAQ)

Q. 손익분기 "하루 30~50회"는 어떤 가정인가요?

A. 요청당 입력 2천·출력 1천 토큰 안팎의 가벼운 대화형 사용, Sonnet 5급 단가, 월 $20 구독 기준의 대략치입니다. 에이전트 작업은 요청당 토큰이 수십 배라 이 숫자가 크게 내려갑니다 — 자기 패턴으로 직접 계산하는 것이 정확합니다.

Q. 구독과 API를 같이 쓰는 게 이상한가요?

A. 아니요, 오히려 표준 구성입니다 — 대화·에이전트 작업은 구독으로, 자동화·스크립트는 API로. 용도가 다른 두 지갑입니다.

Q. 9월 가격 인상 전에 뭘 해두면 좋나요?

A. 8월 사용량 기준으로 9월 단가를 넣어 재계산해보세요. 종량으로 서비스·자동화를 돌리는 쪽이라면 캐시 적중률을 올리는 최적화가 인상분을 상쇄할 수 있는 시점입니다.

한눈에 보는 요약

구독 = 정액 뷔페, 종량 = 계량 판매. 가벼운 사용은 하루 수십 회 언저리, 에이전트 작업은 하루 몇 회에서 구독이 이깁니다. 변수는 캐시·9월 인상·내 신경 비용 — 경계 지대면 계산기로 숫자를 내고, 매일 에이전트파는 그냥 구독입니다.

참고 자료

Claude 공식 요금 (구독·API)
OpenAI API 요금 (공식)

Claude Code 주간 한도 부스트 8/19 종료: 뭐가 줄고, 이번 주에 뭘 해야 하나

DevPilot — Wed, 12 Aug 2026 14:58:56 +0900

핵심 요약: 5월부터 이어진 Claude Code 주간 한도 +50% 부스트가 8월 19일(수)에 끝납니다 — Pro·Max·Team·시트형 Enterprise 전부 해당. 사라지는 건 부스트뿐입니다: 5월에 영구 적용된 개선(5시간 한도 2배, 피크 시간 스로틀 제거)은 그대로예요. 체감 산수를 먼저 — 부스트 기준으로 주간 한도를 꽉 채워 쓰고 있었다면, 19일부터 실질 한도가 3분의 1 줄어드는 셈입니다. 알아둘 것 하나: 이 부스트는 이미 네 번 연장된 전력이 있어서 또 연장될 가능성도 있습니다. 하지만 "연장되겠지"를 전제로 워크플로를 잡는 건 도박이죠. 이번 주에 할 일 넷 — ① /usage로 내 주간 소모 측정(부스트가 살아있는 이번 주가 측정 적기) ② effort 낮추기 습관 장착 ③ 작업별 모델 라우팅 점검 ④ 클라우드 세션 방치 습관 정리. 넷 다 아래에서 구체적으로.

※ 2026년 8월 18일 갱신: 예상대로였습니다 — 다섯 번째 연장이 공지됐습니다. 부스트는 8월 31일까지 유지되고, Anthropic은 "영구화를 희망하지만 수요에 따라 유동적"이라고 밝혔어요. 아래의 준비 4종은 연장과 무관하게 유효합니다(본문의 "어느 쪽이든 준비하는 쪽이 이깁니다" 그대로). 그리고 월말 마감이 하나 줄었습니다 — 예고됐던 Sonnet 5 API 인상(9/1)이 취소돼(8/11 발표, $2/$10 영구화) 남은 마감은 부스트뿐이에요.

※ 2026년 9월 1일 갱신: 부스트의 최종 향방이 확정됐습니다 — 9/13까지 +50%가 그대로 유지되고, 9/14부터 영구 +25%로 전환됩니다(공식 발표). 즉 "종료"가 아니라 "전환"이에요. 다만 기준선(부스트 이전) 대비로는 인상이지만 지금 쓰던 +50% 대비로는 약 17% 감소라, 헤비 유저는 줄어든 것으로 체감합니다. 아래 준비 4종은 전환 뒤에도 그대로 유효하고요. 상세 산수와 대응은 전용 글에 정리했습니다.

이 글은 D-7 시점(8/12)에 씁니다 — 종료 후에 허둥대는 것보다, 부스트가 살아 있는 일주일 동안 준비하는 쪽이 여러모로 유리해서요.

정확히 뭐가 끝나나 (그리고 뭐가 남나)

혼동 포인트부터 정리합니다. 올해 Claude 한도 관련 변화는 세 겹이었어요 — ① 5월 6일의 영구 개선: 5시간 단위 한도 2배 + 피크 시간 스로틀 제거. 이건 프로모션이 아니라 기본값 변경이라 계속 유지됩니다. ② 주간 한도 +50% 부스트: 이번에 끝나는 그것. ③ Fable 5 관련 정책: 7월의 요금 분기(그 정리)로, 부스트와는 완전히 별개입니다. 즉 19일 이후에도 5시간 윈도우의 체감은 그대로이고, 줄어드는 건 "일주일 총량"입니다. 매일 가볍게 쓰는 사람은 변화를 못 느낄 수 있고, 주 후반에 한도 경고를 보던 헤비 유저는 확실히 느낍니다.

이번 주에 할 일 ①: 내 소모를 측정하세요 (지금이 적기인 이유)

/usage로 이번 주 주간 소모율을 확인해두세요. 포인트는 타이밍입니다 — 부스트가 살아 있는 지금 "주간 한도의 몇 %를 쓰는지" 재두면, 19일 이후의 내 위치가 계산됩니다. 지금 60% 이하로 쓰고 있다면 부스트가 빠져도 한도 안이니 무대응으로 충분하고, 70%를 넘나든다면 19일부터는 한도에 닿는다는 뜻이라 아래 절약 수단이 필요합니다. 90%+ 라면 플랜 검토(Pro vs Max)까지 시야에 둬야 하고요 — 그 검토엔 "구독 상향 vs API 종량 전환"의 비교도 포함하세요. 어느 쪽이 싼지는 사용량에 따라 갈리는데, AI 구독 vs API 비용 계산기에 하루 요청 수를 넣으면 손익분기가 바로 나옵니다. 감이 아니라 이 숫자 하나로 대응 수위가 정해집니다.

이번 주에 할 일 ②~④: 절약 수단 세 가지

② effort 낮추기 — 마침 Opus 5의 effort 다이얼(사용 가이드)이 정확히 이 상황을 위한 도구입니다. 커밋 메시지·요약·뻔한 수정을 medium 이하로 내리는 것만으로 소모가 눈에 띄게 줍니다 — 부스트 종료를 앞두고 이번 주에 습관을 들여두세요. ③ 모델 라우팅 — 사람이 마주 앉는 작업은 Opus 5, 기계적 반복 작업은 Sonnet 5로(그 기준). ④ 클라우드 세션 습관 — 웹·모바일에서 걸어두고 잊은 세션도 같은 주머니를 소모합니다(그 구조). "병렬로 걸어두는 게 습관"이 된 분이라면 세션 수부터 점검을. 참고로 이 세 가지는 부스트가 연장되더라도 그냥 이득인 습관들이라, 준비가 헛수고가 될 일은 없습니다.

연장 가능성에 대하여

솔직한 전망도 적어둡니다 — 이 부스트는 네 번 연장된 전력이 있습니다. 다섯 번째 연장이 나와도 놀랍지 않아요. 다만 운영 관점에서 "연장 베팅"은 나쁜 계획입니다: 연장되면 준비가 여유가 되고, 안 되면 준비가 생존이 되니까, 어느 쪽이든 준비하는 쪽이 이깁니다. 연장 여부는 19일 전후 공식 공지로 확인되는 대로 이 글에 갱신을 달겠습니다. 8월의 다른 일정은 8월 캘린더에서(Sonnet 5 프로모션 종료는 이후 취소돼 $2/$10이 영구화됐습니다).

자주 묻는 질문 (FAQ)

Q. 부스트 종료로 5시간 한도도 줄어드나요?

A. 아니요, 5시간 단위 한도는 5월에 영구 적용된 개선이라 그대로입니다. 줄어드는 것은 주간 총량뿐입니다.

Q. 저는 Pro인데 체감이 클까요?

A. 사용 패턴에 달렸습니다. 이번 주 /usage에서 주간 소모가 60% 이하면 체감이 거의 없고, 70% 이상이면 주 후반 한도 관리가 필요해집니다.

Q. 한도가 부족해지면 Max로 올려야 하나요?

A. 순서가 있습니다 — effort 조절과 모델 라우팅으로 2주 버텨보고, 그래도 매주 막히면 그때가 플랜 검토 시점입니다. 습관 개선 없이 플랜만 올리면 같은 문제를 더 비싸게 만납니다.

한눈에 보는 요약

8/19 종료되는 건 주간 +50% 부스트뿐(5시간 2배·스로틀 제거는 영구). 헤비 유저 기준 실질 총량 1/3 감소. 이번 주 할 일: /usage 측정 → effort 하향 → 모델 라우팅 → 세션 정리. 네 번 연장된 전력이 있지만, 연장 베팅 말고 준비를.

참고 자료

Claude 공식 지원 센터 (한도 안내)
Claude 공식 요금

한 달에 190편 쓰고 애드센스에 두 번 떨어졌다: 블로그 37일의 기록

DevPilot — Tue, 11 Aug 2026 19:12:15 +0900

7월 5일에 이 블로그의 첫 글을 올렸다. 오늘이 8월 11일이니 37일째다. 그 사이에 올라간 글이 193편. 계산하면 하루 평균 다섯 편이 넘는다. 이 문장을 쓰면서도 좀 아득한데, 사실이 그렇다.

그리고 그 37일 동안 구글 애드센스에 두 번 떨어졌다. 사유는 두 번 다 같았다 — "가치가 별로 없는 콘텐츠." 이 글은 그 기록이다. 뭘 했고, 왜 그게 문제였고, 지금은 뭘 바꿨는지. 블로그 운영기가 대개 성공담이라 이런 글이 오히려 드물 것 같아서, 실패 쪽을 데이터째 공개하기로 했다.

질주: 27일 동안 181편

시작은 실험이었다. AI 검색 시대에 맞는 글 구조(질문형 제목, 답부터 주는 요약)를 잡고, AI 도구로 초안을 만들고 내가 검증·편집하는 체제를 세팅하니 — 글이 빨리 나왔다. 너무 빨리 나왔다. 검색 데이터를 보면 다음 주제가 보였고, 주제가 보이면 쓰지 않을 이유가 없었고, 그렇게 하루 4편이 기본이 되고 많은 날은 열 편을 넘겼다. 7월 마지막 주가 정점이었다. 위 그래프의 가파른 구간이 그 시기다.

변명하자면 지표가 나쁘지 않았다. 방문자는 늘고 있었고, 검색 노출도 붙기 시작했다. "많이 쓰면 많이 걸리겠지"라는 산수가 작동하는 것처럼 보였다.

거절 두 번: 같은 사유, 다른 교훈

1차 거절 때는 색인 문제라고 해석했다. 심사 시점에 색인된 글이 95편 중 36편뿐이었으니, "구글이 아직 내 글을 못 봤구나"라고. 색인을 요청하고, 글을 더 쓰고, 재신청했다. 8월 1일에 같은 문장이 돌아왔다.

두 번째는 데이터를 다르게 읽을 수밖에 없었다. 색인은 늘었는데 결과가 같다면, 문제는 양이 아니라는 뜻이다. 냉정하게 내 블로그를 심사관의 눈으로 다시 보니 이런 사이트였다 — 개설 한 달에 글 180편, 거의 전부가 같은 골격(요약 박스 → 표 → FAQ → 요약), 실사용 스크린샷은 드물고, 운영자가 누군지 알 수 있는 페이지는 없음. 글 하나하나는 공들였다고 생각했지만, 사이트 전체의 인상은 "자동 생산 라인"에 가까웠다. 인정하는 데 하루쯤 걸렸다.

바꾼 것들: 8월 1일 이후

그날 저녁에 운영 방식을 갈아엎었다. 바꾼 것들:

하루 1편. 위 그래프에서 8월 1일 이후 기울기가 눕는 게 그 결정이다. 덜 쓰는 대신 한 편마다 해외 자료 조사를 넣고, 다이어그램을 직접 그려 넣기 시작했다. 신뢰 페이지 4종. 운영자 소개, 콘텐츠 작성·검증 원칙, 문의, 개인정보처리방침 — 특히 작성 원칙에는 AI 초안을 활용하되 사실 확인과 편집은 사람이 한다는 것까지 적었다. 숨길 게 아니라 밝힐 일이라고 판단했다. 기존 글 수술. 새 글보다 있는 글에 시간을 쓰기 시작했다 — 내부 링크가 없던 고아 글 17편에 길을 놓고, 노출은 되는데 클릭이 없는 글들의 제목을 고쳤다. 이 작업의 효과는 빨랐다: 어떤 글은 링크를 놓아준 다음 주에 유입이 두 배가 됐다.

바꾸고 나서: 아직 작지만, 방향이 다르다

현재 숫자를 그대로 적는다 — 누적 방문 895명, 누적 조회 1,791회, 구독자 26명, 하루 방문 60~80명 수준, 유입의 43%가 검색. 자랑할 크기가 아니라는 걸 안다. 다만 곡선의 성질이 달라졌다 — 글을 쏟아내서 만든 스파이크가 아니라, 검색이 매일 데려오는 완만한 우상향이다. 재밌는 건, 발행량을 5분의 1로 줄였는데 방문자는 줄지 않았다는 것. 한 달 전의 나에게 이 문장을 보여주고 싶다.

애드센스는 8월 말에서 9월 초 사이에 세 번째 신청을 넣을 생각이다. 색인 비율과 일일 검색 유입이 기준선을 넘으면. 떨어지면 그 기록도 쓰겠다 — 이 글의 존재 이유가 그거니까.

같은 길에 있는 분들에게

블로그를 AI와 함께 운영하는 사람이 이제 드물지 않을 거다. 37일 치 수업료로 배운 걸 세 줄로 남기면: 속도는 전략이 아니라 유혹이다 — 쓸 수 있다고 다 쓰면 사이트 전체가 값을 잃는다. 글의 가치는 검증 가능한 고유함에서 나온다 — 내 데이터, 내 스크린샷, 내 실패가 어떤 요약보다 강하다. 그리고 정직이 최적화다 — 작성 방식을 밝히고, 실패를 기록하는 것이 돌아서 보니 가장 나은 SEO였다. 이 블로그가 어떻게 쓰이는지 궁금하면 작성 원칙에 있고, 다음 기록은 세 번째 심사 결과와 함께 돌아오겠다.

챗GPT 무료로 어디까지? 8월부터 텍스트 무제한 — 그래도 Plus가 필요한 경우 (2026)

DevPilot — Sun, 9 Aug 2026 11:07:32 +0900

핵심 요약: 이번 주에 판이 바뀌었습니다 — 8월 6일부터 챗GPT 무료 플랜의 텍스트 대화가 무제한이 됐습니다. "5시간에 10개" 시절이 끝나고, 기본 모델도 GPT-5.6 계열(Luna)로 올라왔어요. 단, 무제한은 텍스트에 한정입니다 — 파일 업로드·이미지 생성·음성은 별도 한도가 남아 있고, Deep Research·에이전트 모드·상위 추론 모델(GPT-5.6 Sol)은 여전히 유료 전용입니다. 그리고 이 관대함의 대가도 알아두세요: 무료·Go 티어에는 광고가 붙는 방향으로 가고 있습니다(지역별 순차). 그래서 결론은 — "물어보고 답 받는" 용도면 이제 무료로 정말 충분하고, Plus($20)는 ① 깊은 조사(Deep Research) ② 에이전트 작업 ③ 상위 추론 모델 ④ 광고 없는 환경, 이 넷 중 하나가 매일 필요할 때 내는 돈입니다.

※ 2026년 8월 27일 갱신: Plus 쪽 조건이 하나 바뀌었습니다 — 7월에 풀렸던 5시간 한도가 8월 25일부로 Plus에 복귀했습니다(Codex·ChatGPT Work 대상, 주간 한도와 병행되는 이중 구조). 무료 텍스트 무제한은 그대로이고, Pro($100/$200)는 5시간 한도 없이 유지됩니다. 에이전트 작업을 몰아 쓰는 Plus 사용자라면 체감될 변화입니다.

무료 시리즈의 마지막 조각입니다 — 젠스파크, 제미나이, 퍼플렉시티, 노트북LM을 거쳐 드디어 챗GPT. 마침 사흘 전에 정책이 크게 바뀌어서, 오래된 정보(10개 제한 시절)로 판단하지 않도록 최신 기준으로 정리합니다.

8월 6일에 뭐가 바뀌었나

변경 전의 무료는 "체험판"이었습니다 — 대략 5시간에 10개 남짓한 메시지, 한도에 닿으면 몇 시간 대기. 8월 6일부터는 텍스트 대화에 한해 횟수 제한이 사라졌고, 무료 기본 모델이 GPT-5.6 계열(Luna)로 올라왔습니다. 일상 질문·글쓰기·요약·가벼운 코딩 질문 수준에서는 이제 유료와의 차이를 체감하기 어렵습니다. 배경에는 광고 모델 전환이 있습니다 — 무료·저가(Go) 티어에 광고를 붙여 수익화하는 방향이라, "무제한 + 광고"와 "유료 + 무광고"의 구도로 재편되는 중입니다(광고 적용은 지역·사용자별 순차라 아직 안 보일 수 있어요).

무료에 남아 있는 한도

무제한은 텍스트만입니다. 파일 업로드(PDF 분석 등), 이미지 생성, 음성 대화는 각자의 일일 한도가 유지되고, 혼잡 시간에는 무료 사용자의 우선순위가 밀릴 수 있습니다. 그리고 기능 벽이 셋 있습니다 — Deep Research(웹을 뒤져 보고서를 만드는 심층 조사), 에이전트 모드(브라우저 조작·다단계 작업 — Atlas가 흡수된 그 기능), 상위 추론 모델(GPT-5.6 Sol의 중·고강도 추론)은 유료 플랜의 영역입니다. 요컨대 "대화는 공짜, 노동은 유료"가 새 구도입니다.

그럼 Plus($20)는 언제 필요한가

이제 Plus의 값어치는 "더 많은 메시지"가 아니라 기능입니다. 결제 신호 넷: ① Deep Research를 주 몇 회 이상 — 리서치가 업무인 사람(이 용도만이면 퍼플렉시티와 비교해보세요 — 그 정리). ② 에이전트 작업 — 예약·폼 작성 같은 웹 심부름을 시키는 워크플로. ③ 상위 추론 — 복잡한 분석·코딩에서 Sol급 추론이 필요한 경우(개발자라면 이 돈으로 Claude Pro나 Cursor Pro와 저울질하는 게 맞고, 그 비교는 블로그의 단골 주제죠). ④ 광고 없는 환경 + 파일·이미지 한도 — 매일 파일을 던지는 사용 패턴. 넷 다 "가끔"이면 무료로 버티고, 하나라도 "매일"이면 $20이 정당화됩니다. 개발 용도로 API와 저울질 중이라면 감으로 정하지 마세요 — AI 구독 vs API 비용 계산기에 하루 요청 수를 넣으면 GPT-5.6 계열 모델별로 구독과 종량 중 어느 쪽이 싼지 원화로 나옵니다. 참고로 중간 티어(Go)도 있지만 핵심 기능 벽(Deep Research 등)은 Plus부터 열리는 구조라, 애매하면 무료 아니면 Plus 둘 중 하나로 단순화하는 걸 권합니다.

갈아탈까 고민 중이라면

이번 변경으로 "무료 챗봇" 선택지가 넓어졌습니다 — 챗GPT(텍스트 무제한), 제미나이(무료 정리 — Pro 모델 접근 가능, 컴퓨팅 한도제), 퍼플렉시티(검색 특화). 거칠게 정리하면: 범용 대화·글쓰기는 챗GPT 무료가 가장 후해졌고, 검색·출처가 중요하면 퍼플렉시티, 구글 생태계(폰·문서) 통합이면 제미나이입니다. 유료를 하나만 유지한다면 "내가 매일 시키는 노동이 뭔지"로 고르세요 — 조사면 퍼플렉시티 Pro, 범용+에이전트면 챗GPT Plus, 코딩이면 Claude/Cursor 계열. 해지·환불이 궁금해지면 챗GPT 해지 정리에 절차가 있습니다.

자주 묻는 질문 (FAQ)

Q. 무료 무제한이면 Plus 해지해도 되지 않나요?

A. 텍스트 대화만 쓰고 있었다면 합리적인 선택입니다. 다만 Deep Research·에이전트·파일 분석을 쓰고 있었다면 그 기능들이 만료와 함께 사라지니, 지난 한 달 사용 내역을 보고 결정하세요.

Q. 무료에도 광고가 나온다는 게 사실인가요?

A. 무료·저가 티어에 광고를 도입하는 방향이 공식화됐고 지역·사용자별로 순차 적용 중입니다. 아직 안 보인다면 순서가 오지 않은 것일 수 있습니다.

Q. 무료의 GPT-5.6 Luna와 Plus의 모델은 얼마나 다른가요?

A. 일상 질문에서는 차이가 크지 않습니다. 차이가 벌어지는 건 복잡한 다단계 추론·분석 작업으로, 그 영역이 필요한지가 곧 Plus 판단 기준입니다.

한눈에 보는 요약

8/6부터 챗GPT 무료 = 텍스트 무제한(GPT-5.6 Luna, 광고 순차 도입). 남은 벽은 파일·이미지·음성 한도와 Deep Research·에이전트·상위 추론. "대화는 공짜, 노동은 유료" — 매일 시키는 노동이 있을 때만 $20을 내세요.

참고 자료

ChatGPT 요금 (OpenAI 공식)
OpenAI 헬프센터

노트북LM 사용법: 자료 넣으면 요약·질문·팟캐스트까지, 무료로 어디까지? (2026)

DevPilot — Sat, 8 Aug 2026 10:26:22 +0900

핵심 요약: 노트북LM(NotebookLM — 올여름부터 Gemini Notebook이라는 새 이름으로 바뀌는 중, 같은 제품입니다)은 "내가 올린 자료만 갖고" 답하는 구글의 자료 분석 도구입니다. PDF·문서·웹페이지·유튜브 링크를 넣으면 그 범위 안에서 요약하고, 질문에 출처 표시와 함께 답하고, 자료를 두 진행자가 대화하는 팟캐스트(오디오 오버뷰)로도 만들어줍니다 — 한국어 오디오 지원됩니다. 무료가 후합니다: 노트북 100개, 노트북당 자료 50개(개당 최대 50만 단어/200MB), 하루 채팅 50회·오디오 3개. 일반 챗봇과의 결정적 차이는 "아는 척"이 없다는 것 — 자료에 없으면 없다고 하고, 모든 답에 근거 위치를 답니다. 시험공부·보고서·계약서 검토처럼 "이 자료들에 대해서만 정확하게"가 필요한 일의 기본 도구입니다.

제미나이 글들(무료 한도, 나노 바나나)을 읽고 "그럼 자료 요약은 뭘로?"라고 물으신 분들이 있어서 — 그 답이 이 글입니다.

일반 챗봇과 뭐가 다른가

챗GPT나 제미나이에게 PDF를 던져도 요약은 됩니다. 노트북LM의 차이는 범위와 근거입니다 — ① 답변의 재료를 내가 올린 자료로 한정합니다(웹 지식으로 아는 척하지 않음) ② 모든 답변 문장에 어느 자료 몇 번째 부분인지 출처 번호가 붙어 클릭하면 원문으로 이동합니다 ③ 자료가 여러 개여도 교차 분석합니다("계약서 A와 B의 위약금 조항 차이는?"). 환각이 두려운 작업 — 시험 자료 정리, 회사 문서 검토, 논문 리뷰 — 에서 이 구조가 주는 안심이 이 도구의 본질입니다.

시작하기: 3분이면 됩니다

notebooklm.google.com 접속(구글 계정이면 끝, 카드 등록 없음) → 새 노트북 만들기 → 소스 추가: PDF, 구글 문서/슬라이드, 웹 URL, 유튜브 링크, 붙여넣은 텍스트, 음성 파일까지 됩니다. 자료가 올라가면 왼쪽에 소스 목록, 가운데 채팅, 오른쪽에 스튜디오(오디오·학습 도구)가 뜹니다. 첫 사용이라면 이 순서를 권해요: ① 자동 생성된 브리핑 문서로 전체 구조 파악 → ② 궁금한 것 채팅으로 질문(출처 번호 클릭해보기) → ③ 오디오 오버뷰 생성해서 산책하며 듣기.

오디오 오버뷰: 이 도구가 유명해진 이유

자료를 넣고 버튼 하나를 누르면, 진행자 두 명이 그 내용으로 수다 떠는 10~20분짜리 팟캐스트가 만들어집니다. 한국어를 포함한 다국어를 지원하고, 특정 주제에 집중하라고 지시할 수도, 중간에 끼어들어 질문할 수도 있습니다(인터랙티브 모드). 실용적인 용도: 출퇴근길에 들을 자료 예습, 긴 보고서를 팀에 공유하기 전 "듣는 요약본", 공부한 내용 복습. 무료는 하루 3개 생성이라, 아껴 쓰는 요령은 자료를 노트북 하나에 모아 한 번에 만드는 것입니다. 영상 형태(비디오 오버뷰)도 하루 3개까지 됩니다.

무료 한도 정리 — 그리고 언제 유료인가

무료: 노트북 100개 / 노트북당 소스 50개 / 소스당 50만 단어·200MB / 하루 채팅 50회·오디오 3개·비디오 3개. 체감으로는 — 학생의 학기 공부, 직장인의 프로젝트 자료 관리 수준에서 한도에 걸릴 일이 거의 없습니다. 유료(구글 AI 구독에 포함되는 상위 버전)는 소스·채팅 한도가 크게 늘고(최상위 기준 노트북당 소스 수백 개) 팀 공유 기능이 붙는데, "자료 50개로 부족한 리서치"를 하는 사람만 해당됩니다. 제미나이 유료를 이미 구독 중이라면(그 정리) 상위 버전이 포함돼 있는지 확인해보시고, 아니라면 무료로 충분히 시작하세요.

이름이 바뀌는 중입니다: Gemini Notebook

7월부터 구글이 이 제품을 Gemini Notebook으로 리브랜딩하는 중입니다 — 제미나이 제품군으로 이름을 통일하는 흐름이고, 기능·무료 정책은 그대로입니다. 당분간 두 이름이 섞여 보일 텐데(앱·문서마다 반영 속도가 달라서), "노트북LM = 제미나이 노트북"으로 기억하시면 됩니다. 이 글도 이름 전환이 완전히 정리되면 갱신하겠습니다.

자주 묻는 질문 (FAQ)

Q. 올린 자료가 AI 학습에 쓰이나요?

A. 구글은 노트북LM에 올린 개인 자료를 모델 학습에 사용하지 않는다고 안내합니다. 다만 회사 기밀 문서라면 조직의 보안 정책을 먼저 확인하는 것이 순서입니다.

Q. 한국어 자료도 잘 되나요?

A. 네, 한국어 문서 분석·질문·답변 모두 자연스럽고 오디오 오버뷰도 한국어로 생성됩니다. 다만 스캔본 PDF(이미지)는 텍스트 인식 품질에 따라 결과가 갈립니다.

Q. 챗GPT 프로젝트나 클로드 프로젝트와 뭐가 다른가요?

A. 방향이 다릅니다 — 그쪽은 "대화에 자료를 곁들이는" 구조고, 노트북LM은 "자료가 주인공이고 대화는 조회 수단"입니다. 자료 기반 정확성과 출처 추적이 중요하면 노트북LM이 우위입니다.

한눈에 보는 요약

내 자료만 갖고, 출처 달아서 답하는 도구 — 무료로 노트북 100개·자료 50개씩·하루 채팅 50회·팟캐스트 3개. 시험공부와 문서 검토의 기본기로 쓰고, 이름이 Gemini Notebook으로 바뀌는 중이라는 것만 알아두세요.

참고 자료

NotebookLM 공식
NotebookLM 공식 고객센터

제미나이 구독 해지·환불 방법: 해지 버튼은 제미나이에 없습니다 (2026)

DevPilot — Fri, 7 Aug 2026 14:37:19 +0900

핵심 요약: 제미나이 유료 구독(Google AI Pro 등)을 끊으려고 제미나이 설정을 뒤지고 계셨다면, 거기엔 없습니다 — 이 구독의 본체는 Google One이라서 해지도 one.google.com의 멤버십 관리에서 합니다(폰 앱스토어로 결제했다면 각 스토어의 구독 관리에서). 해지해도 결제 주기 끝까지 혜택이 유지되는 건 다른 구독과 같지만, 구글만의 함정이 하나 있습니다: 스토리지. AI Pro에는 2TB가 묶여 있어서, 만료되면 15GB로 내려가고 그보다 많이 쓰고 있으면 구글 포토 백업·업로드가 막힙니다. 환불은 원칙적으로 불가지만, 해지 화면에 "즉시 종료 + 남은 기간 부분 환불" 옵션이 표시되는 국가/지역이 있으니(한국 포함 여부는 화면에서 확인) 해지 전에 그 옵션부터 보세요.

해지·환불 시리즈의 일곱 번째 도구입니다. 제미나이는 절차 자체는 쉬운데 "어디서 하는지"와 "해지하면 뭘 잃는지"에서 헛걸음이 많은 케이스라, 그 둘에 집중합니다.

해지 위치: 제미나이가 아니라 Google One

혼동의 근원부터 — 제미나이 유료 요금제(AI Plus/Pro/Ultra)는 제미나이라는 서비스의 구독이 아니라 Google One 멤버십의 한 종류입니다. 그래서 해지는: ① one.google.com 접속 → ② 좌측(또는 설정)의 멤버십 관리 → ③ 멤버십 취소 → 확인. 제미나이 앱의 설정에는 구독 관리로 가는 링크만 있고 해지 버튼은 없습니다. 폰에서 결제한 경우는 예외 — 아이폰은 설정 → 내 이름 → 구독, 안드로이드는 Play 스토어 → 결제 및 구독에서 해지해야 합니다. "해지 버튼이 안 보인다"의 십중팔구는 결제 경로가 다른 케이스라는 것, 이 시리즈의 단골 결론이 여기도 적용됩니다.

해지하면 잃는 것: AI보다 스토리지가 문제

결제 주기가 끝나는 날 두 가지가 사라집니다. ① AI 혜택: 한도 4배, 100만 토큰 컨텍스트, Veo 영상 생성 등(무료와의 차이 정리) — 무료 플랜으로 내려가는 것이니 예상 범위죠. 진짜 주의할 건 ② 스토리지입니다. AI Pro에 묶인 2TB가 기본 15GB로 다운그레이드되는데, 이미 15GB 넘게 쓰고 있다면 — 구글 포토의 새 사진 백업이 중단되고, 드라이브 업로드와 Gmail 수발신까지 영향을 받을 수 있습니다. 기존 파일이 당장 지워지진 않지만, 초과 상태가 장기간(구글 안내 기준 2년) 지속되면 콘텐츠 삭제 대상이 될 수 있다는 정책도 있어요. 그러니 순서는 이렇게: 해지 전에 스토리지 사용량부터 확인(one.google.com에 바로 표시됩니다) → 15GB 초과분이 있으면 정리 계획(사진 정리, 다른 클라우드 이동)을 세우고 → 그다음 해지.

환불: 원칙 불가, 그러나 화면을 확인할 것

구글 공식 정책은 "구입한 스토리지 요금제는 환불되지 않는다"입니다 — 해지 후 기간 끝까지 쓰는 구조가 기본이죠. 다만 공식 문서에 "일부 국가/지역에서는 구독을 즉시 종료하고 부분 환불을 받을 수 있다"는 예외가 명시돼 있고, 해당되는 경우 해지 과정에서 그 선택지가 화면에 표시됩니다. 그러니 해지 버튼을 눌렀을 때 "즉시 종료·부분 환불" 옵션이 뜨는지 확인하고, 뜬다면 남은 기간과 금액을 비교해 선택하세요(기간을 거의 다 썼다면 그냥 만료까지 쓰는 게 이득입니다). 앱스토어 결제분은 늘 그렇듯 애플(reportaproblem.apple.com)·구글 플레이의 자체 환불 절차를 따릅니다.

해지 전 체크리스트

① 스토리지 사용량 확인 — 15GB 초과면 정리 먼저(이게 이 글의 핵심 당부입니다) ② 결제 경로 확인 — 웹(Google One)인지 스토어인지 ③ 가족 공유 여부 — Google One은 가족과 공유되는 멤버십이라, 내 해지가 가족의 스토리지·AI 혜택에도 영향을 줍니다 ④ 환불 옵션 확인 — 해지 화면의 부분 환불 표시 여부 ⑤ 대안 검토 — "AI는 필요 없는데 스토리지는 필요"라면 해지가 아니라 스토리지 전용 요금제로 다운그레이드가 답일 수 있습니다(멤버십 취소 대신 요금제 변경). 다른 도구들의 해지 절차는 6개 도구 총정리 허브에 모아뒀습니다.

자주 묻는 질문 (FAQ)

Q. 해지하면 제미나이를 아예 못 쓰나요?

A. 아니요, 무료 플랜으로 전환됩니다. 기본 검색·대화·이미지 생성은 계속 되고, 한도와 컨텍스트가 무료 기준으로 줄어들 뿐입니다.

Q. 해지하면 구글 포토 사진이 지워지나요?

A. 당장 지워지지 않습니다. 다만 15GB를 초과한 상태면 새 백업이 중단되고, 초과 상태가 장기간 지속되면 정책상 삭제 대상이 될 수 있으니 초과분은 정리해두는 것이 안전합니다.

Q. 학생 무료 12개월로 쓰고 있는데 이것도 해지해야 하나요?

A. 무료 기간 종료 후 자동으로 유료 전환되는 조건이었다면, 결제를 원치 않을 경우 만료 전에 같은 방법(Google One 멤버십 관리)으로 취소해두는 것이 안전합니다.

한눈에 보는 요약

해지는 제미나이가 아니라 one.google.com 멤버십 관리에서(스토어 결제는 스토어에서). 기간 끝까지 유지 후 무료 전환 — 단 스토리지 15GB 함정부터 점검하고, 해지 화면의 부분 환불 옵션 표시 여부를 확인하세요. "스토리지만 필요"면 해지 대신 요금제 변경이 답입니다.

참고 자료

Google One 멤버십 취소하기 (구글 공식 고객센터)
구매, 취소 및 환불 정책 (구글 공식)

Claude Opus 5 effort 설정 가이드: 언제 올리고, 언제 내리나 (2026)

DevPilot — Thu, 6 Aug 2026 08:03:09 +0900

핵심 요약: Opus 5의 effort는 "얼마나 깊게 생각할지"를 정하는 5단계 다이얼입니다 — low / medium / high(기본값) / xhigh / max. 지난 세대까지 "비용을 아끼려면 모델을 내리는" 방식이었다면, 이제는 같은 모델의 노력 수준을 조절하는 쪽이 먼저입니다. 쓰는 법은 간단합니다: Claude Code에서 /effort 명령(또는 /effort low처럼 직접 지정, /effort auto로 초기화), API에서는 output_config.effort 파라미터. 운용 공식을 먼저 드리면 — 기본 high로 두고, 일상 잡무는 low·medium으로 내려 토큰을 아끼고, 까다로운 디버깅·설계는 xhigh로, max는 "토큰이 얼마가 들든 맞아야 하는" 예외에만. 함정 하나: thinking을 끈 상태에서 xhigh·max를 쓰면 400 에러가 납니다 — 고심 모드는 생각을 끌 수 없게 설계돼 있어요.

Opus 5 출시 정리(그 글)에서 "effort가 이번 세대의 조작법"이라고 했는데, 정작 어떻게 조작하는지는 다루지 않았죠. 오늘은 그 다이얼을 실제로 돌려봅니다.

effort가 실제로 하는 일

effort는 모델이 응답에 얼마나 많은 추론 토큰을 쓸지를 정합니다. 올리면 더 오래 생각하고 더 정확해지는 대신 느려지고 비싸지며, 내리면 빠르고 싸지는 대신 마지막 몇 %의 정확도를 양보합니다. 중요한 건 이 트레이드오프의 기울기입니다 — 공식 벤치마크 기준 Opus 5는 가장 낮은 effort에서도 경쟁 모델 이상의 과제 통과율을 냈고, 반대로 max에서는 Fable 5 최고점의 0.5% 이내까지 붙습니다. 낮춰도 크게 안 무너지고 올리면 확실히 오르는, 다이얼 값을 하는 다이얼이라는 뜻입니다. 실사용 조직들의 보고도 같은 방향이에요 — 법률 AI 회사 Harvey는 낮은 추론 수준에서 토큰을 26% 덜 쓰면서 비슷한 품질을 유지했다고 밝혔습니다.

조작법: Claude Code와 API

Claude Code: 세션에서 /effort를 치면 화살표로 고르는 슬라이더가 뜨고, /effort low처럼 바로 지정할 수도 있습니다. /effort auto는 기본값 복귀. 세션마다 매번 바꾸기 귀찮으면 CLAUDE_CODE_EFFORT_LEVEL 환경변수나 설정 파일의 effortLevel로 고정할 수 있는데, max는 세션 한정이라 설정 저장이 안 됩니다 — "상시 max"라는 위험한 습관을 도구가 막아둔 셈이죠. API: 요청에 output_config={"effort": "medium"} 형태로 지정합니다. 기본값은 양쪽 다 high.

단계별 운용: 제가 일주일 돌려본 결과

low·medium — 생각보다 넓은 영역: 커밋 메시지, 코드 요약, 문서 초안, 명세가 뻔한 소규모 수정. 이런 일에 high를 쓰는 건 근처 편의점을 고속열차 타고 가는 격입니다. 체감 응답 속도가 확 빨라져서, 저는 "읽고 바로 판단할 수 있는 작업"은 전부 medium으로 내렸습니다. high(기본) — 대부분의 코딩: 그대로 두면 됩니다. xhigh — 막힌 문제: 재현이 까다로운 버그, 여러 파일이 얽힌 리팩터링 계획, "high로 두 번 실패한 작업"의 세 번째 시도. 두 번 실패에 세 번째도 같은 설정으로 던지는 것보다 xhigh 한 번이 토큰이 덜 들 때가 많았습니다. max — 예외 카드: 아키텍처 결정 검토처럼 "틀리면 비용이 훨씬 큰" 문제 전용. 상시 사용은 한도(특히 8월 19일 주간 부스트 종료 이후) 관점에서 권하지 않습니다.

함정과 팁

① thinking과의 관계: thinking을 끈 요청에 xhigh·max를 조합하면 400 에러가 반환됩니다. 고심 단계는 사고 과정 자체가 필요하니 당연한 설계인데, API 자동화에서 종종 밟는 지뢰입니다 — 비용 통제는 thinking을 끄는 대신 effort를 내리는 쪽이 공식 권장입니다. ② "내릴까"가 "바꿀까"를 대체: 지난주까지 Sonnet으로 내리던 상황의 상당수가 이제 "effort를 내리는" 걸로 해결됩니다 — 모델 전환 기준은 Opus 5 vs Sonnet 5에 갱신해뒀습니다. ③ 흐름의 일부: "설정으로 지능을 조절한다"는 발상은 Cursor의 Router(우선순위 기반 모델 라우팅 — 그 정리)와 같은 방향입니다. 도구들이 "뭘 쓸까"라는 질문을 흡수하는 중이고, effort는 그 Claude식 답안입니다.

자주 묻는 질문 (FAQ)

Q. effort를 내리면 사용량(한도)도 덜 소모되나요?

A. 네, 추론 토큰이 줄어드는 만큼 소모가 줄어듭니다. 구독 한도가 아쉬울 때 모델을 바꾸지 않고 쓸 수 있는 첫 번째 절약 수단입니다. API로 쓰고 있다면 절약분이 그대로 청구액 감소인데, 토큰 사용량별 금액 차이는 AI 구독 vs API 비용 계산기에서 모델별로 확인할 수 있습니다.

Q. 기본값을 low로 바꿔놓는 건 어떤가요?

A. 권하지 않습니다. low는 "이 작업엔 깊은 추론이 필요 없다"고 판단했을 때 명시적으로 내리는 용도이고, 기본값은 high(또는 조직 표준)로 두는 것이 재작업 비용까지 계산하면 쌉니다.

Q. 웹 챗(claude.ai)에서도 effort를 조절할 수 있나요?

A. 제공 위치와 명칭은 플랫폼별로 순차 반영 중입니다. 이 글의 조작법은 Claude Code와 API 기준이며, 다른 환경은 설정 메뉴에서 노력 수준 관련 옵션을 확인하세요.

한눈에 보는 요약

effort = 5단계 추론 다이얼(기본 high). 잡무는 medium 이하로 내려 토큰 절약, 막힌 문제는 xhigh, max는 세션 한정 예외 카드. Claude Code는 /effort, API는 output_config.effort — 그리고 thinking 끄고 xhigh 이상은 400 에러라는 것만 기억하세요.

참고 자료

Effort 공식 문서 (Claude Platform Docs)
Opus 5 발표 (Anthropic 공식)