Round Figure

Claude Code API 연결 안 될 때 체크리스트 — SSL 인증서·프록시·QUIC까지

roundfigure — Sun, 12 Jul 2026 01:50:42 +0900

claude 실행했는데 Unable to connect to API (ETIMEDOUT)이나 fetch failed만 뜨고 아무것도 안 되는 상황, 회사 네트워크에서 특히 자주 겪습니다. 근데 이 에러 하나에 원인이 최소 서너 가지 섞여 있어서, 검색해서 나오는 해결법을 그대로 따라 해도 안 먹히는 경우가 많아요. 이 글은 Claude Code 공식 에러 레퍼런스와 네트워크 설정 문서를 기준으로, 실제로 자주 나오는 원인부터 순서대로 짚어봅니다. 마지막에는 드물지만 실제 보고된 QUIC 차단 케이스도 다룹니다.

Claude Code API 연결 안 될 때, 뭐부터 봐야 할까

공식 문서(code.claude.com/docs/en/errors)는 이 계열 에러의 원인을 "보통 로컬 네트워크, 프록시, 방화벽, 혹은 클라우드 환경의 네트워크 정책에서 시작된다"고 명시합니다. Claude Help Center도 비슷하게 "방화벽, 네트워크, VPN 문제일 가능성이 높다"고 안내하고요.

정리하면 우선순위는 이렇습니다. 1) SSL 인증서 검증 실패, 2) 프록시 미설정, 3) VPN 잔여 문제. 이 세 가지가 공식 문서에 명시된 흔한 원인이고, QUIC/UDP 443 차단은 GitHub에 실제 보고는 있지만 공식 문서 어디에도 등장하지 않는 비주류 케이스입니다. 순서대로 확인해보죠.

SSL 인증서 오류 — UNABLE_TO_GET_ISSUER_CERT_LOCALLY

회사 방화벽이나 Zscaler, CrowdStrike Falcon 같은 TLS 검사 프록시를 쓰는 환경에서 가장 흔하게 보는 에러입니다. 실제 GitHub 이슈(#43050)에 보고된 메시지 원문은 이렇습니다.

Failed to connect to api.anthropic.com: UNABLE_TO_GET_ISSUER_CERT_LOCALLY

SSL certificate error (UNABLE_TO_GET_ISSUER_CERT_LOCALLY). If you are behind a corporate proxy or TLS-intercepting firewall, set NODE_EXTRA_CA_CERTS to your CA bundle path, or ask IT to allowlist *.anthropic.com. Run /doctor for details.

원인은 회사 프록시가 TLS 트래픽을 가로채면서 자체 인증서로 갈아끼우는데, 그 인증서 체인을 Claude Code가 신뢰하지 못하는 겁니다. 공식 해결법은 조직 CA 번들을 지정하는 것.

export NODE_EXTRA_CA_CERTS=/path/to/ca-bundle.pem

Claude Code는 기본적으로 번들된 Mozilla CA 인증서와 OS 인증서 저장소를 함께 신뢰합니다. CLAUDE_CODE_CERT_STORE 환경변수로 어느 쪽을 쓸지 조정할 수도 있어요.

export CLAUDE_CODE_CERT_STORE=bundled   # 번들 CA만 신뢰
export CLAUDE_CODE_CERT_STORE=system    # OS 신뢰 저장소만 신뢰

여기서 하나 주의할 게 있는데, NODE_TLS_REJECT_UNAUTHORIZED=0으로 인증서 검증을 아예 꺼버리는 방법은 공식 문서가 명시적으로 하지 말라고 경고합니다. 검증을 끄면 중간자 공격에 그대로 노출되니까요. 참고로 v2.1.199부터는 인증서 검증 실패가 재시도 없이 첫 시도에서 바로 표시됩니다. 예전 버전에서는 재시도 예산을 다 쓴 뒤에야 에러가 나서 원인 파악이 더 오래 걸렸다고 하네요.

프록시 미설정 — HTTPS_PROXY 확인하기

인증서 에러가 아니라 그냥 타임아웃(ETIMEDOUT)이나 연결 거부(ECONNREFUSED)만 뜬다면 프록시 설정 자체가 안 돼 있을 가능성이 높습니다. 회사 네트워크는 대부분 프록시를 거쳐야 외부로 나가는데, Claude Code는 표준 프록시 환경변수를 그대로 존중합니다.

export HTTPS_PROXY=https://proxy.example.com:8080   # 권장
export HTTP_PROXY=http://proxy.example.com:8080      # HTTPS 프록시 불가 시
export NO_PROXY="localhost,192.168.1.1,example.com,.example.com"

프록시에 기본 인증이 필요하면 URL 안에 자격증명을 넣으면 됩니다(http://username:password@proxy.example.com:8080). 다만 비밀번호를 스크립트에 그대로 박아두는 건 피하는 게 좋습니다. NTLM이나 Kerberos 같은 고급 인증 방식이 필요한 환경이면, 이걸 지원하는 LLM 게이트웨이 서비스를 쓰라고 공식 문서가 권장하고 있어요.

한 가지 알아둘 점은, Claude Code는 SOCKS 프록시를 지원하지 않는다는 겁니다. 회사에서 SOCKS5 프록시만 제공한다면 이 부분부터 IT팀과 확인해야 합니다.

VPN이 원인일 수도 있습니다

VPN 클라이언트를 껐다 켰다 하는 과정에서 라우팅 테이블이나 네트워크 인터페이스가 지저분하게 남는 경우가 있습니다. 공식 문서가 언급하는 macOS 사례를 보면, 연결 해제되었거나 이미 제거된 VPN 클라이언트가 터널 인터페이스를 그대로 남겨두는 일이 있다고 합니다. ifconfig로 오래된 utun 인터페이스가 남아있는지 확인하고, 시스템 설정에서 해당 VPN의 네트워크 확장을 지우는 게 공식 대응법입니다.

Claude Help Center는 더 간단하게, 요청 실행 시 VPN을 아예 꺼보라고 안내합니다. VPN을 끈 상태에서 정상 작동한다면 VPN 쪽 문제로 좁혀지는 거죠. Docker Desktop 같은 컨테이너 런타임도 아웃바운드 트래픽을 가로챌 수 있으니, 종료하고 재시도해보는 것도 공식 문서가 제시하는 체크 항목입니다.

curl로 먼저 확인하기 — 공식 대응 절차

원인을 하나씩 추측하기 전에, 같은 셸에서 curl로 API 호스트에 도달하는지부터 확인하는 게 순서입니다.

curl -I https://api.anthropic.com

Windows PowerShell에서는 내장 curl 별칭(사실은 Invoke-WebRequest)이 아니라 curl.exe -I https://api.anthropic.com로 실제 curl 바이너리를 호출해야 합니다. 이게 성공하는데 Claude Code만 실패한다면, 리졸버 설정 문제일 수 있습니다. 특히 WSL 환경은 /etc/resolv.conf에 호스트로부터 물려받은 깨진 네임서버가 남아있는 경우가 있다고 공식 문서가 짚고 있어요.

방화벽이 필요한 호스트를 다 허용하고 있는지도 확인해야 합니다. Claude Code가 접근해야 하는 URL은 api.anthropic.com(API 요청), claude.ai(계정 인증), downloads.claude.ai(설치·업데이트) 등입니다. LLM 게이트웨이나 릴레이를 쓰고 있다면 ANTHROPIC_BASE_URL을 해당 주소로 지정해야 하고요.

드문 케이스 — QUIC/UDP 443이 막힌 네트워크

여기까지 다 확인했는데도 원인을 못 찾겠다면, 조금 특이한 케이스도 하나 알아두면 좋습니다. GitHub 이슈 #49761에 보고된 사례인데, Claude Code(2.1.112, macOS)가 로그인 과정에서 이런 에러를 냈습니다.

OAuth error: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch()

보고자가 tcpdump로 트래픽을 직접 캡처해보니, Claude Code가 api.anthropic.com 연결 시 QUIC(UDP 443)만 시도하고 TCP SYN 패킷은 아예 보내지 않았다고 합니다. 같은 네트워크에서 curl https://api.anthropic.com은 TCP HTTPS로 멀쩡히 작동했는데도요. 이슈 설명 원문을 그대로 옮기면 이렇습니다.

"The underlying Bun runtime appears to prefer QUIC/HTTP/3 and does not fall back to TCP HTTPS when QUIC fails, unlike curl and mainstream browsers which implement fallback behaviour."

즉 Claude Code가 쓰는 Bun 런타임이 QUIC을 우선 시도하는데, 이 경로가 막힌 네트워크에서는 curl이나 브라우저와 달리 TCP로 자동 폴백하지 않는다는 겁니다. 보고자는 macOS 방화벽(pf)으로 UDP 443을 강제로 차단해서 TCP 폴백을 유도하는 방식으로 우회했습니다.

echo "block out proto udp from any to 160.79.104.0/24 port 443" | \
  sudo tee /etc/pf.anchors/blockquic
sudo pfctl -a blockquic -f /etc/pf.anchors/blockquic
sudo pfctl -e

다만 이 이슈는 "Closed as not planned"로 종료됐고, Anthropic 공식 문서 어디에도 QUIC이나 HTTP/3이라는 단어가 등장하지 않습니다. 공식 수정 계획도 없는 상태고요. 회사 방화벽이 이미 UDP 443을 막고 있는 환경이라면 이론상 비슷한 효과가 날 수 있지만, 실제로는 UDP 443이 "일부만 손상"된 애매한 상태라 패킷이 조용히 드롭되면서 타임아웃만 반복되는 경우도 보고돼 있습니다. 프록시(HTTPS_PROXY)를 거치면 프록시가 보통 TCP만 처리하니 QUIC 자체를 우회하는 부수 효과가 있을 거라는 추론도 있는데, 이 부분은 Claude Code에서 실제로 검증된 사례를 찾지는 못했습니다. 앞의 프록시/인증서/VPN 체크를 다 해본 다음에야 고려할 만한 옵션으로 보는 게 맞습니다.

그래도 간헐적으로 끊긴다면 — 재시도 환경변수

원인을 찾았는데도 연결이 가끔 불안정하다면 재시도·타임아웃 관련 환경변수로 임시 대응할 수 있습니다.

변수	기본값	효과
`CLAUDE_CODE_MAX_RETRIES`	10	재시도 횟수
`CLAUDE_CODE_RETRY_WATCHDOG`	unset	`1`로 설정하면 429/529 용량 에러를 무한 재시도, v2.1.199부터는 다른 일시적 에러도 최대 300회까지 재시도
`API_TIMEOUT_MS`	600000	요청당 타임아웃(ms), 느린 프록시 환경에서는 상향 조정

단, TLS 인증서 검증 실패는 재시도 대상이 아닙니다. 인증서 문제면 재시도 횟수를 아무리 늘려도 소용없고, 위에서 다룬 NODE_EXTRA_CA_CERTS 설정으로 바로 해결해야 합니다.

자주 묻는 질문

Q. claude doctor는 정상인데 실행할 때만 에러가 나요.
GitHub 이슈 #43050 보고자도 같은 증상을 겪었습니다. doctor 명령의 점검 로직과 실제 API 요청 시 인증서 검증 로직이 완전히 같은 경로를 타지 않는 것으로 보이니, doctor 결과만 믿지 말고 curl -I https://api.anthropic.com으로 직접 확인하는 게 낫습니다.

Q. HTTPS_PROXY를 설정했는데도 안 됩니다.
프록시가 SOCKS 방식인지 먼저 확인하세요. Claude Code는 SOCKS 프록시를 지원하지 않습니다. NTLM/Kerberos 인증이 필요한 프록시도 별도 게이트웨이 없이는 안 됩니다.

Q. Amazon Bedrock이나 Google Cloud 쪽 게이트웨이를 쓰는데도 이 에러가 나요.
모델 트래픽과 인증은 해당 게이트웨이로 가지만, WebFetch 도구는 도메인 안전성 검사 때문에 skipWebFetchPreflight: true를 설정하지 않는 한 여전히 api.anthropic.com을 호출합니다. 이 부분이 막혀 있으면 게이트웨이 설정과는 별개로 에러가 날 수 있습니다.

이 정도만 순서대로 체크해봐도 대부분의 "API 연결 안 됨" 문제는 원인이 좁혀집니다. EACCES 계열 설치 오류를 따로 겪고 있다면 Claude Code EACCES 오류 해결법 글도 참고하면 되고, 컨텍스트 압축 루프처럼 연결과는 다른 종류의 먹통 증상이라면 Autocompact is thrashing 해결법에서 다룬 적이 있습니다. sandbox 권한 설정까지 손봐야 하는 상황이라면 Claude Code sandbox.credentials 설정 글도 도움이 될 겁니다.

Claude Code sandbox.credentials 설정, 기본값만 믿으면 안 되는 이유

roundfigure — Sat, 11 Jul 2026 10:54:25 +0900

Claude Code에서 sandbox.enabled: true만 켜두면 자격증명이 자동으로 보호될 거라고 생각하기 쉬운데, 사실 그렇지 않습니다. 샌드박스의 기본 읽기 정책은 "일부 디렉터리만 빼고 컴퓨터 전체를 읽을 수 있게 허용"하는 쪽으로 설계돼 있어서, ~/.aws/credentials나 ~/.ssh 같은 자격증명 파일은 손대지 않으면 그대로 노출됩니다. 이 글에서는 왜 이런 구조인지, 실제로 어떤 위험으로 이어질 수 있는지, 그리고 sandbox.credentials로 정확히 어떻게 막는지 정리했습니다.

샌드박스를 켜도 자격증명이 뚫려 있는 이유

Claude Code의 Bash 샌드박스는 매번 승인을 묻지 않고도 명령을 실행할 수 있게 해주는 격리 환경입니다. macOS는 Seatbelt, Linux·WSL2는 bubblewrap과 socat 조합으로 파일시스템·네트워크 경계를 강제하는 방식이죠. 근데 이 격리, 쓰기와 읽기를 다르게 취급해요.

공식 문서(code.claude.com/docs/en/sandboxing)는 기본 읽기 동작을 이렇게 명시합니다. "read access to the entire computer, except certain denied directories. Note that this default still allows reading credential files such as ~/.aws/credentials and ~/.ssh/." 쓰기는 현재 작업 디렉터리와 세션 임시 디렉터리로 좁혀지지만, 읽기는 기본적으로 열려 있다는 뜻입니다.

환경변수 쪽도 마찬가지입니다. 문서의 Scope 섹션은 "sandboxed Bash commands inherit the parent process environment by default, including any credentials set there"라고 밝힙니다. 셸에 GITHUB_TOKEN 같은 값이 export돼 있으면, 샌드박스 안에서 실행되는 명령도 그 값을 그대로 물려받습니다. 샌드박스가 막아주는 건 "쓰기"와 "새 도메인 네트워크 접근"이지, 이미 컴퓨터에 있는 자격증명 읽기가 아니라는 걸 정확히 짚고 넘어가야 합니다.

자격증명 노출이 실제로 문제가 됐던 사례

이게 왜 이론적인 얘기가 아니라 실전 문제인지 보여주는 사례가 있습니다. 블로그 Arrange Act Assert(2026년 6월 30일 게시)는 Mozilla 0DIN 팀이 보고한 2026년 6월 사례를 소개하는데, 겉보기엔 평범한 GitHub 저장소가 AI 코딩 에이전트를 리버스 셸로 유도한 케이스입니다. 저장소 자체에는 악성 코드가 전혀 없고, 정상적인 Python 패키지 설치가 실패한 뒤 공격자가 제어하는 DNS TXT 레코드를 조회해서 그 안의 페이로드를 bash로 파이핑해 실행하는 방식이었다고 합니다. 페이로드가 실행 시점에 원격에서 가져와지니 코드 리뷰로는 잡히지 않는 구조죠.

이 글의 저자는 "The sandbox limits writes well by default. It does not limit reads the same way"라고 못박습니다. 설정하지 않으면 기본적으로 열려 있는 항목으로 ~/.ssh, ~/.aws/credentials, npm·GitHub 토큰, 클라우드 제공자 구성 파일을 꼽았습니다.

여기서 하나 구분해서 짚을 부분이 있습니다. cybersecuritynews.com이 보도한 또 다른 취약점은 성격이 좀 다릅니다. 2025년 10월(v2.0.24)부터 2026년 4월(v2.1.90) 패치까지 약 5.5개월간 존재했던 네트워크 샌드박스 우회 취약점(CVE-2025-66479 계열)인데, allowedDomains: []로 모든 아웃바운드를 막으려던 설정이 결함 있는 체크 로직 때문에 오히려 "전부 허용"으로 오작동한 것과, SOCKS5 호스트명에 널바이트를 심어 필터를 속이는 방식(attacker-host.com\x00.google.com처럼 JS 필터는 뒤쪽 도메인만 보고 통과시키지만 getaddrinfo()는 널바이트에서 문자열을 끊어 실제로는 앞쪽 공격자 도메인으로 연결)이 결합된 사고였습니다. 이건 사용자가 설정을 잘못한 게 아니라 구현 자체의 버그였습니다.

두 사례를 나란히 놓으면 왜 다층 방어가 필요한지 드러납니다. Mozilla 사례는 "기본 정책이 원래 이렇게 설계됐다"는 문제고, CVE 사례는 "의도한 정책조차 버그로 뚫릴 수 있다"는 문제입니다. sandbox.credentials로 자격증명을 명시적으로 차단해두면, 설계상의 허점이든 예상 못한 구현 버그든 최소한 자격증명 자체는 애초에 프로세스에 노출되지 않도록 막는 역할을 합니다. 공식 문서 Limitations 섹션도 "Sandboxing reduces risk but is not a complete isolation boundary"라고 인정하는 부분입니다.

sandbox.credentials 실전 설정법

그럼 실제로는 어떻게 설정해야 할까요? sandbox.credentials는 Claude Code v2.1.187부터 추가된 전용 설정 블록입니다. files와 envVars 두 배열로 구성되고, 각 항목은 경로(또는 변수명)와 mode를 가집니다.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

files 항목은 "mode": "deny"만 지원합니다. 샌드박스 내에서 해당 경로 읽기가 완전히 거부되는 방식이고, 사실상 filesystem.denyRead와 같은 메커니즘입니다. 공식 문서는 이 자격증명 전용 블록을 따로 둔 이유를 "keeps credential rules grouped together and separate from general filesystem rules"라고 설명합니다 — 일반 파일 규칙과 섞이지 않게 구분해두려는 목적입니다.

envVars는 한 단계 더 나아가서 "mode": "mask"(v2.1.199+)를 지원합니다. deny는 변수를 아예 unset 처리해버려서 그 값으로 인증하던 gh, npm 같은 도구가 깨질 수 있는데, mask는 샌드박스 안 명령에는 세션별 sentinel 값만 보여주고, 요청이 샌드박스 밖으로 나가 지정된 injectHosts로 향할 때 프록시가 실제 값으로 바꿔치기합니다.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "tlsTerminate": {},
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    },
    "credentials": {
      "envVars": [
        { "name": "GH_TOKEN", "mode": "mask", "injectHosts": ["api.github.com"] },
        { "name": "NPM_TOKEN", "mode": "mask" }
      ]
    }
  }
}

주의할 점 하나. mask가 동작하려면 network.tlsTerminate를 반드시 같이 설정해서 프록시가 TLS를 직접 종료해야 합니다. 이걸 빼먹으면 마스킹이 fail closed 상태가 됩니다 — 명령은 여전히 sentinel만 보지만, 그 sentinel이 그대로 서버로 전달돼 인증 자체가 실패하는 거죠. 다행히 Claude Code가 시작 시점에 이 설정 오류를 알려줍니다.

공식 문서가 한 문장으로 정리하는 원칙도 기억해둘 만합니다. "There is no built-in credential deny list, so only the files and variables you list are restricted." 자동으로 보호되는 기본 목록 같은 건 없고, 직접 나열한 것만 막힙니다.

deny와 mask, 어디에 써야 통하는지

설정 스코프 얘기를 빼놓을 수 없습니다. Claude Code 설정은 Managed → Command line → Local(.claude/settings.local.json) → Project(.claude/settings.json) → User(~/.claude/settings.json) 순으로 우선순위가 매겨지는데, deny 계열 배열 값은 이 순서와 무관하게 모든 스코프에서 병합됩니다. 즉 프로젝트 설정에 자격증명 차단을 걸어두면 사용자가 로컬 설정으로 이를 풀 수 없다는 뜻입니다.

반대로 mask 항목과 network.tlsTerminate, credentials.allowPlaintextInject는 저장소에 포함되는 .claude/settings.json이나 .claude/settings.local.json에서는 아예 무시됩니다. 사용자 설정, 관리형 설정, --settings CLI 플래그처럼 신뢰도 높은 스코프에서만 적용됩니다. 저장소 설정 파일은 협업자나 공격자가 손댈 여지가 있으니, 자격증명을 실제 값으로 주입하는 위험한 동작은 신뢰된 스코프에서만 열어준다는 설계로 보입니다.

이 우선순위 구조는 Claude Code 매번 승인 물어볼 때 — Manual 모드 정체와 Auto 복원법에서 다룬 권한 흐름과도 맞닿아 있습니다. 샌드박스가 Auto-allow 모드로 동작할 때는 승인 절차 자체가 생략되는 만큼, 파일·환경변수 차단 규칙이 스코프별로 정확히 어디서 먹히는지 미리 알아두는 게 중요합니다.

조직 전체에 강제하려면 관리형 설정에 아래처럼 배포하고, sandbox.credentials 항목을 추가하라고 공식 문서도 권고합니다.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

문서 원문: "Add sandbox.credentials entries for credential directories such as ~/.aws and ~/.ssh and for secret environment variables, since the default read policy still allows them." allowManagedReadPathsOnly, allowManagedDomainsOnly 같은 잠금 옵션을 걸어두면 개발자가 로컬에서 정책을 넓히는 것도 막을 수 있습니다. 다만 excludedCommands에는 이런 잠금 대응 옵션이 없어서, 여기 등재된 명령은 샌드박스 제약을 아예 우회한다는 점도 기억해두는 게 좋습니다.

문서에 없었다는 얘기, 지금은 사정이 다릅니다

sandbox.credentials가 v2.1.187에서 조용히 추가되고 나서, 한동안 공식 문서에 이 설정이 전혀 반영되지 않았던 시기가 있었습니다. 2026년 6월 23일 올라온 GitHub 이슈 #70440이 이 문제를 짚었는데, 샌드박싱 가이드가 여전히 옛날 방식인 수동 denyRead 설정만 안내하고 있었고, 설정 페이지의 sandbox 설정 표에도 이 항목이 빠져 있었다는 지적이었습니다.

근데 이 리서치를 진행한 시점 기준으로 공식 문서를 직접 확인해보니, 이미 "Protect credentials"라는 전용 섹션이 생겨서 스키마와 예시, mask 모드까지 상세히 서술돼 있었습니다. 이슈 제기 이후 문서가 보강된 것으로 보입니다. 그러니 지금 이 설정을 검색하면서 "공식 문서에 안 나온다"는 식으로 알고 있었다면, 그건 이미 지나간 얘기라는 것만 짚고 넘어가겠습니다.

FAQ

Q. sandbox.enabled만 켜도 자격증명이 안전한가요?
아니요. 기본 읽기 정책이 컴퓨터 전체를 허용하는 쪽이라 ~/.aws/credentials, ~/.ssh 같은 파일은 sandbox.credentials.files에 직접 등록해야 차단됩니다.

Q. deny와 mask 중 뭘 써야 하나요?
gh, npm처럼 그 자격증명으로 인증해서 계속 동작해야 하는 도구가 있으면 mask, 아예 접근 자체를 막아도 되는 경우면 deny가 맞습니다. 단 mask는 network.tlsTerminate 설정과 신뢰된 스코프(사용자/관리형 설정)가 필요합니다.

Q. 프로젝트 저장소의 .claude/settings.json에 mask를 써도 되나요?
공식 문서 기준으로는 무시됩니다. mask, network.tlsTerminate, credentials.allowPlaintextInject는 사용자 설정, 관리형 설정, --settings CLI 플래그에서만 유효합니다.

권한 프롬프트나 승인 흐름이 헷갈렸다면 Claude Code 매번 승인 물어볼 때 — Manual 모드 정체와 Auto 복원법을, 파일 접근 권한 자체에서 막힌 적이 있다면 Claude Code EACCES 오류 해결법, npm 전역 설치 실패 체크리스트를 같이 보면 설정 맥락이 좀 더 잡힙니다. 샌드박스 설정을 걸어두고 나서 컨텍스트 압축 관련 이슈가 궁금하다면 Autocompact is thrashing 해결법 — Claude Code 컨텍스트 압축 루프 대처도 참고할 만합니다. 아직 sandbox.credentials를 설정 안 해뒀다면, 지금 쓰고 있는 .aws, .ssh 경로부터 하나씩 등록해보는 걸 권합니다.

Autocompact is thrashing 해결법 — Claude Code 컨텍스트 압축 루프 대처

roundfigure — Fri, 10 Jul 2026 11:13:44 +0900

Claude Code로 작업하다가 갑자기 "Autocompact is thrashing"이라는 경고가 뜨면서 대화가 멈춘 적 있으신가요? 몇 턴 지나면 또 뜨고, /clear를 눌러도 다시 뜨고 — 작업 흐름이 뚝뚝 끊기니 답답할 수밖에 없습니다. 이 오류는 정확히 어떤 상황에서 발생하고, 왜 반복되는지, GitHub 이슈와 공식 문서를 근거로 정리했습니다.

Claude Code 터미널에 "Autocompact is thrashing" 경고 배너가 뜬 화면

"Autocompact is thrashing" 에러 메시지, 정확히 뭐라고 뜨나

에러 메시지 원문은 이래요.

"Autocompact is thrashing: the context refilled to the limit within 3 turns of the previous compact, 3 times in a row. A file being read or a tool output is likely too large for the context window. Try reading in smaller chunks, or use /clear to start fresh."

anthropics/claude-agent-sdk-python의 Issue #958과 anthropics/claude-code의 Issue #60485에서 동일한 문구가 그대로 확인됩니다. 두 이슈 모두 같은 텍스트를 보고하고 있어서, 이 메시지는 Claude Code 내부에 하드코딩된 고정 경고문으로 보입니다.

Issue #60485가 정리한 재현 조건은 이렇습니다. 루트 CLAUDE.md 24KB, .claude/CLAUDE.md 8KB, 프로젝트별 memory/ 9KB — 합쳐서 41KB 정도 되는 정상적인 자동 로드 컨텍스트를 가진 프로젝트에서 새 세션을 열고, Read 몇 개와 Bash 명령어 몇 개 정도 가벼운 작업을 몇 턴 하면 3턴 이내에 이 배너가 뜨고 매 compact 이후에도 계속 반복됩니다.

이 경고, 버그일까 정상 동작일까

일단 알아둘 게 있습니다. 이건 그 자체로는 버그가 아니라 의도된 가드 메커니즘입니다. Claude Code가 압축(compact)을 했는데도 컨텍스트가 3턴 이내에 다시 한계까지 차는 상황이 3회 연속 반복되면, 무한 압축 루프에 빠지는 대신 스스로 멈추고 경고를 띄우는 구조입니다.

근본 원인은 대개 하나로 좁혀집니다. 단일 파일이나 도구(tool) 출력이 컨텍스트 윈도우에 비해 너무 큰 경우입니다. 압축을 해도 그 거대한 콘텐츠가 다시 읽히면서 컨텍스트를 즉시 재충전시키고, 이 압축→재팽창 사이클이 반복되면서 thrashing으로 감지되는 겁니다. fazm.ai는 이 감지 메커니즘을 "보호 장치"로 설명하면서, "그것은 싸워야 할 버그가 아니라 신호다. 창(window) 안에 비대한 무언가가 있다는 신호"라고 서술합니다.

근데 문제는 여기서 끝나지 않습니다. Issue #60485는 자동 로드 컨텍스트가 41KB에 불과해 200K 토큰 윈도우에서 문제될 수준이 아닌데도 thrashing이 반복됐다고 보고했습니다. 버전 2.1.144부터 증상이 시작됐고, 이전 버전에서는 같은 프로젝트·같은 파일로 정상 작동했다는 점에서 autocompact 휴리스틱이나 컨텍스트 계산 로직 자체가 바뀐 회귀(regression) 버그일 가능성이 제기됩니다. 즉 "공식 설명(파일이 너무 큰 경우에만 발생)"과 "실사용 보고(컨텍스트가 크지 않은데도 발생)" 사이에 차이가 있다는 얘기입니다.

Autocompact 트리거 전후 컨텍스트 사용률 변화를 보여주는 다이어그램

Autocompact가 원래 어떻게 작동하는지부터 짚어보기

Claude Code의 autocompact는 대화가 컨텍스트 윈도우 한계에 가까워지면 이전 내용을 자동으로 요약해서 대화를 이어가는 기능입니다. 기술 블로그 claudefa.st에 따르면 200K 토큰 윈도우 기준으로 실제 쓸 수 있는 컨텍스트는 약 167K 토큰이고, 나머지 33K 토큰(16.5%)은 요약 처리 자체를 위한 버퍼로 예약돼 있습니다.

그런데 이 auto-compaction이 정확히 몇 %에서 트리거되는지는 소스마다 설명이 다릅니다. claudefa.st는 약 83.5% 사용률(약 167K 토큰) 근처로 설명하는 반면, hyperdev.matsuoka.com은 "이전에는 90% 이상에서 작동했으나 현재는 약 75% 사용률에서 더 일찍 트리거된다"고 설명합니다. 두 수치가 다르고, 어느 쪽도 공식 changelog에 명시된 값임을 확인하지 못했습니다 — 둘 다 스스로 "공식 문서에 명시되지 않은 관찰"이라고 인정하고 있습니다. 그러니 "정확히 몇 %에서 압축된다"는 식으로 단정하기보다는 대략적인 참고치로만 보는 게 안전합니다.

hyperdev 쪽 설명이 흥미로운 부분은 이겁니다. 과거 방식은 90% 도달 후 압축하다 보니 작업 중간에 끊기고 컨텍스트가 손실되는 문제가 있었는데, 더 이른 시점에 압축하고 현재 작업을 완료한 뒤 리셋하는 방식으로 바뀌면서 일관성이 나아졌다는 겁니다.

공식이 권장하는 대처법

에러 메시지 원문에 이미 1차 대처법 두 가지가 적혀 있어요.

파일이나 도구 출력을 한 번에 통째로 읽지 말고 더 작은 단위로 나눠 읽기
/clear로 세션을 초기화하고 새로 시작하기

fazm.ai는 여기에 몇 가지를 더 얹습니다. /context 명령으로 현재 무엇이 컨텍스트 창을 채우고 있는지 확인하는 것, /compact focus on the API changes처럼 압축 시 보존할 내용을 지정하는 것, CLAUDE.md에 "Compact Instructions" 섹션을 추가해서 이후 모든 압축에 지침이 적용되게 하는 것 등입니다. 한계에 도달하기 전에 선제적으로 /compact를 실행하면 압축기가 더 선택적으로 동작한다는 점도 함께 소개합니다. 세션 자체를 보존하고 싶다면 --fork-session 플래그나 /branch 명령으로 한계 도달 전 깨끗한 지점에서 새 브랜치를 만들어 이어가는 방법도 있습니다.

한 가지 확실히 해둘 게 있습니다. fazm.ai는 "Claude Code의 자동 컨텍스트 압축은 완전히 비활성화할 수 없다"고 명시합니다. ~/.claude/settings.json에 autoCompactEnabled: false를 추가해도 작동하지 않는데, 이유는 그 키가 설정 스키마 자체에 존재하지 않아 무시되기 때문이라고 합니다.

근본적인 예방책으로는 claudefa.st가 제시하는 방법도 있습니다. 1M 토큰 컨텍스트를 지원하는 모델(Sonnet 5, Fable 5, Opus 4.6 이상)을 쓰면 추가 비용 없이 훨씬 넓은 여유 공간을 확보할 수 있다는 설명입니다.

근데 이 워크어라운드, 항상 통하는 건 아니다

여기서 정직하게 짚고 넘어가야 할 부분이 있습니다. Issue #60485의 실사용 보고를 보면 공식 워크어라운드가 항상 통하는 건 아니라는 게 드러납니다. 보고자는 "/clear는 한 번은 작동하지만 ~3턴 내에 thrashing이 재발한다", "/compact <focus>도 동일한 결과"라고 밝혔습니다. thrash 이벤트가 뜰 때마다 워크플로우가 끊기고 수동으로 /clear와 작업 재시작을 반복해야 했다는 지적입니다.

환경변수 쪽도 비슷한 사정입니다. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE는 1~100 범위 값을 받아 압축 발동 퍼센티지를 직접 지정하는 환경변수로, docs.bswen.com은 40~70% 범위를 권장합니다. CLAUDE_CODE_AUTO_COMPACT_WINDOW로 유효 토큰 윈도우 크기 자체를 줄이는 방법도 있는데, 두 값 모두 새 세션부터 적용되고 재시작이 필요합니다.

문제는 Issue #42394입니다. ~/.claude/settings.json의 env 필드에 "CLAUDE_AUTOCOMPACT_PCT_OVERRIDE": "95"와 "DISABLE_AUTO_COMPACT": "1"을 동시에 설정했는데도, Opus 4.6(1M 컨텍스트) + Claude Code v2.1.90 + macOS 환경에서 새 세션 시작 시 자동으로 컴팩션이 실행됐다고 보고됩니다("Cultivating… (1m 26s · ↓ 3.2k tokens)" 로그와 함께 컨텍스트가 6%로 떨어졌다는 내용). 공식 설정값이 문서상 존재하더라도 버전에 따라 기대대로 작동하지 않을 수 있다는 뜻이니, 설정을 걸어뒀다고 안심하지 말고 실제 트리거 시점이 바뀌는지 확인해보는 게 나아요.

이 워크어라운드들을 시도했는데도 반복적으로 thrashing이 발생한다면, 버전 회귀 가능성을 의심하고 다운그레이드하거나 재현 조건과 함께 공식 이슈 트래커에 등록하는 게 실질적인 대안입니다.

/context 명령 실행 화면 예시, 컨텍스트 창을 채우고 있는 항목별 비율

자주 묻는 질문

Q. Autocompact를 아예 끌 수는 없나요?
공식적으로는 없습니다. autoCompactEnabled: false는 스키마에 없는 키라 무시되고, DISABLE_AUTO_COMPACT=1도 여전히 컴팩션이 실행됐다는 버그 보고(Issue #42394)가 있습니다.

Q. /clear를 눌렀는데도 thrashing이 계속 뜨면요?
Issue #60485처럼 재발한다면 버전 회귀 가능성부터 의심하세요. 버전을 확인하고, 필요하면 다운그레이드하거나 재현 조건을 정리해 공식 이슈로 등록하는 게 낫습니다.

Q. CLAUDE_AUTOCOMPACT_PCT_OVERRIDE 값은 얼마로 설정해야 하나요?
docs.bswen.com은 40~70% 범위를 권장합니다. 다만 설정해도 항상 기대대로 작동하지 않을 수 있으니, 적용 후 실제 압축 시점이 바뀌는지 확인이 필요합니다.

컨텍스트 문제, thrashing 하나로 끝나지 않는다

Autocompact thrashing은 결국 "Claude Code가 컨텍스트를 다루는 방식" 전반의 문제 중 하나입니다. 비슷한 맥락에서 Claude Code Task Budgets로 API 비용 폭주 막는 법도 컨텍스트·토큰 소비를 통제하는 문제를 다루고 있어서 같이 보면 도움이 될 겁니다. 반대로 파일 권한 문제로 Claude Code 자체가 안 열리는 상황이라면 Claude Code EACCES 오류 해결법 쪽 체크리스트가 먼저일 수도 있고요.

컨텍스트 창이 자꾸 꽉 차서 압축이 반복된다면, 일단 /context로 뭐가 창을 채우고 있는지부터 확인해보시길 권해요. 큰 로그 파일이나 방대한 도구 출력을 통째로 읽고 있는 건 아닌지, 그 지점부터 좁혀 나가는 게 가장 빠른 길입니다.

Claude 피크 시간 사용량 제한, 지금도 적용될까 (3월 도입~5월 폐지 타임라인)

roundfigure — Thu, 9 Jul 2026 11:44:01 +0900

결론부터 말씀드리면, 2026년 7월 9일 현재 Claude의 피크 시간 사용량 제한은 적용되지 않습니다. "요즘 왜 이렇게 한도가 빨리 닳지" 싶어서 검색하셨다면, 그 문제의 원인이었던 정책은 이미 5월 초에 폐지됐어요. 다만 이 정책이 왜 생겼고 왜 없어졌는지, 그리고 폐지 발표문에 "다시는 안 한다"는 확언은 없다는 점까지 알아두면 앞으로 비슷한 이슈가 또 생겼을 때 헷갈리지 않습니다. 오늘은 이 짧고 굵었던 정책의 타임라인과, 한국 시간으로는 정확히 몇 시였는지를 정리해봤습니다.

Claude 피크 시간 사용량 제한 도입부터 폐지까지 타임라인 인포그래픽

피크 시간 사용량 제한이란 무엇이었나

Anthropic 엔지니어 Thariq Shihipar가 2026년 3월 26일 X(트위터)에서 직접 밝힌 내용이 출발점입니다. "늘어나는 수요를 관리하기 위해 무료·Pro·Max 구독의 5시간 세션 한도를 피크 시간대에 조정한다"는 게 핵심이었어요. 미국 평일 오전 5시~11시(태평양 시간) 동안에는 5시간 세션 한도가 평소보다 빨리 소진되도록 만들고, 그 대신 비피크 시간에는 처리 용량을 더 늘려 균형을 맞춘다는 방식이었습니다.

중요한 건 주간(weekly) 한도 자체는 건드리지 않았다는 점이에요. Shihipar도 "전체 주간 한도는 그대로고, 그 한도가 한 주 안에서 분배되는 방식만 바뀌는 것"이라고 못 박았습니다. 대상은 Free, Pro($20/월), Max 5x($100/월), Max 20x($200/월) 전 티어였고, 그중에서도 Pro 티어가 가장 크게 영향받을 거라고 예상됐습니다. Anthropic이 밝힌 영향 규모는 "약 7%의 사용자가 기존이라면 도달하지 않았을 세션 한도에 도달하게 된다"는 수치였어요.

도입 직후 반발, 그리고 폐지까지

시행되자마자 반발이 쏟아졌습니다. The Register 보도에 따르면 Claude Pro 구독자 중에는 "매주 월요일에 한도를 다 쓰고 토요일에 리셋되는 패턴이라 30일 중 12일만 실질적으로 쓸 수 있다"고 지적한 사례가 있었고, Max 5x 사용자는 "1시간짜리 작업으로 전체 한도를 다 소진했다"고 보고했습니다. 결국 2026년 3월 31일, Anthropic은 공식적으로 "Claude Code에서 사람들이 예상보다 훨씬 더 빨리 사용 한도에 도달하고 있다는 걸 알고 있다"고 인정하며 이를 팀의 최우선 순위로 삼겠다고 밝혔어요.

개발자 커뮤니티 쪽에서는 기술적 원인 분석도 나왔습니다. Claude Code 바이너리를 역분석해서 "프롬프트 캐시를 깨뜨려 비용을 10~20배까지 은밀하게 부풀리는 버그 2개"를 발견했다는 주장이 공유됐고, 자동화 워크플로우를 쓰는 사용자들 사이에서는 "레이트리밋 오류로 하루치 예산이 몇 분 만에 소진될 수 있다"는 경고가 돌았습니다.

그리고 약 한 달 뒤인 2026년 5월 6일, Anthropic은 이 정책을 완전히 뒤집는 발표를 합니다. Pro·Max·Team 플랜의 5시간 한도를 2배로 늘리고, Pro·Max의 피크 시간 제한 축소를 아예 제거하고, Opus 모델 API 레이트리밋도 대폭 올린다는 내용이었어요. 배경은 SpaceX와 맺은 컴퓨트 계약이었습니다. Colossus 1 데이터센터에서 300MW 이상, GPU 22만 개 이상 규모의 추가 용량을 확보하면서 굳이 피크 시간을 쥐어짤 이유가 없어진 거죠.

정리하면 이 정책은 딱 6주짜리였습니다. 3월 26일 도입 → 3월 31일 문제 인정 → 5월 6일 완전 폐지. 폐지 발표문 어디에도 "앞으로 다시는 안 한다"는 문구는 없어서, 수요가 또 급증하면 비슷한 조치가 재도입될 가능성 자체는 남아 있습니다. 다만 7월 9일 현재까지 재도입 보도는 확인되지 않았어요.

Anthropic 공식 발표문 인용 - 5시간 한도 2배 상향 및 피크 시간 제한 제거

피크 시간대, 한국 시간으로는 정확히 몇 시였나

이 정책의 실용적인 궁금증은 결국 "그래서 내 시간으로는 언제였는데?"입니다. Anthropic 발표문은 "weekdays 5am–11am PT / 1pm–7pm GMT"라고 병기했는데, 사실 이 두 표현 자체가 서로 정확히 맞아떨어지지 않아요. 그래서 계산을 두 갈래로 나눠서 봐야 합니다.

첫 번째, 발표문의 GMT 표기를 그대로 따르면 UTC 13:00~19:00이고, 여기에 9시간을 더하면 한국 시간 밤 10시~다음날 새벽 4시가 나옵니다. 두 번째, 실제 시행 기간(3월 26일~5월 6일)은 미국이 서머타임(PDT, UTC-7)을 적용 중이던 시기라 "현지 시계로 오전 5~11시"를 그대로 환산하면 UTC 12:00~18:00이 맞고, 이걸 KST로 옮기면 밤 9시~새벽 3시가 됩니다.

두 계산이 1시간씩 어긋나는 이유는 Anthropic이 PT를 서머타임 여부와 상관없이 관용적으로 UTC-8(PST)로 단순 표기하는 흔한 관행 때문으로 보여요. 어느 쪽을 취하든 결론은 크게 다르지 않습니다. 피크 시간은 한국 시간 밤 9~10시부터 다음날 새벽 3~4시 사이로 수렴합니다.

피크 시간대 태평양 시간(PT) vs 한국 시간(KST) 환산 비교표

이게 의미하는 바가 재밌는데요, 미국 평일 아침 출근 시간대(수요가 몰리는 시간)가 한국 시간으로는 저녁~심야~새벽에 해당합니다. 그러니까 한국의 통상적인 주간 업무 시간(오전 9시~오후 6시)에는 이 제한이 아예 적용되지 않았던 거예요. 오히려 밤늦게, 새벽에 Claude Code를 돌리던 야간 작업자나 해외 팀과 시차를 맞춰 협업하던 개발자가 가장 직접적인 영향권에 있었던 셈입니다.

요금제별로 체감 차이가 있었을까

대상은 Free, Pro, Max 5x, Max 20x 전 티어였지만, 앞서 봤듯 기본 한도가 낮은 Pro가 가장 크게 체감했고 Max 5x도 예외는 아니었습니다.

참고로 Claude 요금제 구조 자체가 궁금하다면 Claude Pro·Max·Team 요금제 완전 분석 글에서 플랜별 한도와 가격을 자세히 다뤘습니다. 그리고 최근 Anthropic이 종량제 옵션을 확대한 흐름은 클로드 종량제 전환, 진짜 영향받는 사람은 따로 있다에서 정리했는데, 이번 피크 시간 제한 소동과 겹쳐서 보면 Anthropic이 지난 몇 달간 사용량 정책을 꽤 자주 손봐왔다는 흐름이 보입니다.

별건이지만 비슷한 시기 맥락 하나 더. 2026년 6월에는 Max 플랜 사용자 Karl Khan이 "광고된 배율만큼 실제 사용량을 주지 않는다"며 캘리포니아 북부 연방지법에 집단소송을 제기했습니다. 피크 시간 제한을 직접 겨냥한 소송은 아니지만, 같은 시기 사용자 불만 흐름과 무관하지 않아 보여요.

지금도 유효한 사용량 절약 팁

피크 시간 자체를 피하라는 조언은 이제 의미가 없습니다. 5월 6일부로 그 제한이 사라졌으니까요. 근데 Claude Help Center의 공식 "사용량 한도 관리 팁" 문서를 보면, 피크 시간과 무관하게 여전히 유효한 습관들이 있습니다.

여러 질문을 쪼개서 보내지 말고 하나의 메시지에 명확하게 정리해서 보내기
불필요한 반복이나 재설명을 줄인 구체적인 프롬프트 작성하기
반복 참고 문서는 프로젝트에 미리 올려두고 매번 새로 붙여넣지 않기
유료 플랜이라면 검색·메모리 기능으로 이전 대화를 다시 활용하기
Settings > Usage에서 5시간 한도와 주간 한도 진행률을 실시간으로 확인하기

API 쪽에서 비용을 통제하고 싶다면 Claude Code Task Budgets에서 다룬 예산 설정 방법도 참고할 만합니다.

혹시 지금도 사용량 한도에 자주 걸린다면, 그건 피크 시간 문제가 아니라 다른 원인일 가능성이 큽니다. Settings > Usage부터 열어서 어느 한도(5시간 세션인지 주간인지)에 먼저 걸리는지 확인해보는 게 다음 순서입니다.

Claude Code 매번 승인 물어볼 때 — Manual 모드 정체와 Auto 복원법

roundfigure — Wed, 8 Jul 2026 21:16:01 +0900

Claude Code를 업데이트했더니 갑자기 명령 하나하나마다 승인을 물어보고, 설정 어딘가에 "Manual"이라는 낯선 모드 이름이 떠 있다면 — 지금 검색해서 들어오신 이유가 바로 그거일 겁니다. 2026년 7월 3일 릴리스된 v2.1.200 이후 커뮤니티에서 가장 많이 나오는 질문이에요. 근데 검색해 보면 "기본값이 Auto에서 Manual로 바뀌었다"는 글과 "아무것도 안 바뀌었다"는 글이 섞여 있어서 더 헷갈립니다.

이 글에서 그 사실 관계를 공식 릴리스 노트 기준으로 정확히 가르고, Auto 모드로 되돌리는 설정까지 순서대로 정리합니다.

Claude Code 터미널에서 권한 승인 프롬프트가 반복해서 뜨는 화면 스크린샷

v2.1.200에서 실제로 바뀐 것은 딱 두 가지

GitHub 릴리스 노트 원문 기준으로 권한 관련 변경은 두 줄입니다.

모드 이름 변경: 기존에 default라고 표기되던 권한 모드가 CLI, --help, VS Code, JetBrains 전반에서 "Manual"로 표기됩니다. --permission-mode manual과 "defaultMode": "manual"이 기존 default와 나란히 허용되는 별칭(alias)으로 추가됐어요.
AskUserQuestion 자동 진행 제거: Claude가 사용자에게 선택지를 묻는 대화상자가 이제 기본적으로 사람이 답할 때까지 무한 대기합니다. 이전에는 약 60초 뒤 알아서 진행됐습니다.

후속 버전 v2.1.203에서는 Manual 모드가 켜져 있을 때 푸터에 회색 일시정지 배지가 추가돼서, 현재 모드가 항상 눈에 보이게 됐고요.

"Auto가 기본이었는데 Manual로 바뀌었다"는 말, 사실일까

여기가 이 글의 핵심입니다. TechTimes 같은 일부 매체는 "기본 권한 모드가 Auto에서 Manual로 변경됐다"고 썼습니다. 하지만 공식 릴리스 노트의 문구는 "Changed the 'default' permission mode to 'Manual'" — 즉 default라는 모드의 명칭을 Manual로 바꿨다는 뜻입니다.

공식 문서 기준으로 정리하면 이렇습니다.

매 행동마다 승인을 요청하는 모드(default)는 원래부터 기본값이었습니다. Anthropic 엔지니어링 블로그도 2026년 3월에 이미 "기본적으로 Claude Code는 명령 실행·파일 수정 전에 승인을 요청한다"고 기술하고 있어요.
Auto가 기본이었던 적은 공식 소스 어디에도 없습니다. 기능은 그대로고, "default"라는 애매한 이름이 "Manual"이라는 정직한 이름으로 바뀐 겁니다.

Medium의 Automation Labs 글은 이 변경을 "commands needed approval, but the name said nothing"(승인은 원래 필요했지만, 이름이 아무것도 말해주지 않았다)라고 요약했습니다. 정확한 표현이라고 봅니다.

그럼 왜 다들 "갑자기 승인이 늘었다"고 느낄까요? 그 체감에는 실체가 있습니다. 다음 섹션에서 봅니다.

"Auto에서 Manual로 변경" 오해 vs "default 모드 이름만 Manual로 변경" 사실을 대비시킨 다이어그램

갑자기 매번 물어보는 것처럼 느껴지는 진짜 원인 두 가지

원인 1 — AskUserQuestion이 더 이상 알아서 진행하지 않는다. v2.1.198 무렵부터 질문 대화상자에 60초쯤 답하지 않으면 "사용자가 자리를 비운 것 같으니 알아서 진행하라"는 합성 응답이 주입되는 동작이 있었습니다. GitHub 이슈 #73408과 #73772에서 "침묵을 승인으로 취급한다", "동의 없는 행동"이라는 비판이 쏟아졌고, v2.1.200이 이 자동 진행을 기본 해제했어요. 그 결과 자동 진행에 (알게 모르게) 의존하던 무인 파이프라인이나 백그라운드 실행은 이제 질문 지점에서 사람이 답할 때까지 멈춥니다. "전엔 알아서 넘어가던 게 이젠 매번 기다린다"는 체감이 여기서 나옵니다.

원인 2 — 프로젝트 설정의 defaultMode: "auto"는 무시된다. v2.1.142 이후, 프로젝트의 .claude/settings.json이나 .claude/settings.local.json에 넣어둔 "auto"는 조용히 무시됩니다. 저장소가 스스로에게 auto 권한을 부여하지 못하게 막는 보안 조치예요. 에러 메시지도 없이 그냥 Manual로 시작하기 때문에, 설정을 분명히 했는데 안 먹는다면 십중팔구 설정 파일 위치 문제입니다.

여기에 모드 표기가 "default"에서 "Manual"로 바뀐 게 겹치면서, 업데이트 직후 "설정이 Manual로 바뀌었고 매번 승인을 요구한다"는 인식이 만들어진 거죠.

Auto 모드로 되돌리는 방법

세 가지 층위가 있습니다. 상황에 맞는 걸 골라 쓰면 됩니다.

세션 중 전환: 터미널에서 Shift+Tab을 누르면 모드가 사이클로 돌아갑니다. 계정이 auto 요건을 충족하면 사이클 마지막에 auto가 나타나요. Claude Code Plan Mode 활용법에서 다뤘던 plan 모드도 같은 사이클 안에 있습니다. VS Code에서는 프롬프트 박스 하단의 모드 인디케이터를 클릭하면 됩니다.

시작 시 플래그:

claude --permission-mode auto

영구 기본값 — 반드시 사용자 설정에: ~/.claude/settings.json에 아래를 추가합니다.

{
  "permissions": {
    "defaultMode": "auto"
  }
}

다시 강조하지만 프로젝트 폴더의 .claude/settings.json에 넣으면 무시됩니다. 반드시 홈 디렉터리의 사용자 설정이어야 해요. VS Code의 claudeCode.initialPermissionMode 설정도 auto 값을 받지 않으니 같은 방식으로 사용자 설정에 지정합니다.

Auto 모드 표시 요건도 확인하세요. 공식 문서 기준으로 Claude Code v2.1.83 이상, 모델은 Anthropic API에서 Opus 4.6 또는 Sonnet 4.6 이상이어야 하고, Team/Enterprise 플랜은 Owner가 관리자 설정에서 먼저 활성화해야 합니다. Bedrock 같은 외부 프로바이더에서는 CLAUDE_CODE_ENABLE_AUTO_MODE=1 환경변수가 별도로 필요합니다.

그리고 무인 실행 때문에 AskUserQuestion 자동 진행이 필요하다면, /config에서 유휴 타임아웃(idle timeout)을 옵트인할 수 있습니다. 서브에이전트를 여러 개 굴리는 파이프라인처럼 사람이 자리를 지키기 어려운 구성에서 유용한데, 이 60초 자동 진행이 바로 이슈 #73408에서 비판받았던 그 동작이라는 점은 기억해 두세요.

~/.claude/settings.json에 defaultMode auto를 설정한 에디터 화면과 Shift+Tab 모드 사이클 안내

Auto로 돌리기 전에 알아둘 트레이드오프

Anthropic이 왜 이름까지 바꿔가며 승인 절차를 강조했는지 수치를 보면 이해가 됩니다. Anthropic 엔지니어링 블로그에 따르면 사용자는 권한 프롬프트의 93%를 승인합니다. 승인이 의사결정이 아니라 반사행동이 된다는 거예요. 그래서 만든 게 auto 모드의 분류기(classifier)인데, 이 분류기도 완벽하지 않습니다. 실제 과잉 행동 52건 중 17%를 놓쳤다는 게 Anthropic 자체 측정치입니다. 잘못 해석된 지시로 원격 git 브랜치를 삭제하거나 프로덕션 DB에 마이그레이션을 시도한 사례도 문서화돼 있고요.

auto 모드에서 알아둘 세부 사항도 있습니다.

Bash(*) 같은 광범위 allow 규칙은 auto 진입 시 자동 해제되고, Bash(npm test) 같은 좁은 규칙만 유지됩니다.
대화 중 "푸시하지 마" 같은 선언은 컨텍스트 압축으로 유실될 수 있으니, 확실한 차단은 deny 규칙으로 걸어야 합니다. 이런 규칙을 어디에 어떻게 쓰는지는 CLAUDE.md 가이드에서 정리한 설정 계층 구조를 참고하세요.
차단이 3회 연속이거나 세션 누적 20회면 auto가 일시 중지되고 프롬프트 모드로 돌아갑니다.

bypassPermissions로 아예 우회하는 방법도 있긴 한데, 공식 문서가 "프롬프트 인젝션이나 의도치 않은 행동에 대한 보호가 전혀 없다"며 인터넷이 차단된 컨테이너/VM 전용으로 못 박습니다. 굳이 이 모드를 쓸 거라면 로컬 머신이 아니라 격리된 클라우드 VM에서 돌리는 게 그나마 안전한 구성인데, Vultr 같은 시간 단위 과금 VPS라면 실험용 격리 VM을 만들었다 지우는 식으로 부담 없이 시험해 볼 수 있습니다. → Vultr 시작하기

자주 묻는 질문

Q. Manual 모드로 바뀌면서 기능도 달라졌나요?
아니요. 기능은 기존 default 모드와 동일하고 이름만 바뀌었습니다. config 값도 여전히 default가 유효하고, hooks나 SDK 통합은 계속 default를 씁니다. manual은 v2.1.200 이상에서만 인식되는 별칭이에요.

Q. .claude/settings.json에 auto를 넣었는데 왜 안 되죠?
v2.1.142 이후 프로젝트·로컬 설정 파일의 auto는 에러 없이 무시됩니다. ~/.claude/settings.json(사용자 설정)으로 옮기세요.

Q. 승인 프롬프트만 줄이고 auto는 부담스러운데요?
/permissions에서 자주 쓰는 도구·명령에 allow 규칙을 추가하는 방법이 있습니다. 모드와 별개 레이어라 Manual 모드에서도 동작해요. 특정 시점에 자동으로 검사를 끼워 넣고 싶다면 Claude Code Hooks로 승인 흐름 자체를 커스텀하는 방법도 있습니다.

업데이트 직후 확인할 두 가지

정리 대신 체크 포인트만 남깁니다. 첫째, 무인 실행 파이프라인이 있다면 AskUserQuestion 지점에서 멈추지 않는지 지금 확인하세요. 둘째, auto를 쓰고 싶다면 설정이 ~/.claude/settings.json에 있는지부터 보세요. 이 두 가지만 확인해도 "갑자기 매번 물어보는" 문제의 대부분은 풀립니다. 권한 모드를 손봤다면, 그다음은 계획 단계와 실행 단계를 나누는 Plan Mode 활용법까지 같이 잡아두는 걸 권합니다.

GitHub Copilot AI Credits 요금 폭탄, 크레딧 다 썼을 때 대처법

roundfigure — Wed, 8 Jul 2026 09:25:23 +0900

"어제까지 잘 쓰던 코파일럿인데 오늘 갑자기 채팅이 막혔다" — 요즘 GitHub 커뮤니티에 이런 글이 부쩍 늘었어요. 2026년 6월 1일부로 GitHub Copilot이 정액제에서 사용량 기반 AI Credits 과금으로 바뀌면서 생긴 일입니다. 근데 문제는 크레딧이 예상보다 훨씬 빨리 사라진다는 거예요. 대체 왜 이렇게 빨리 줄어드는 걸까요? 크레딧이 바닥났을 때 뭘 할 수 있는지까지 실전 대처법으로 정리해봤습니다.

GitHub Copilot AI Credits 요금 폭탄을 상징하는 대표 이미지

AI Credits 과금, 대체 뭐가 바뀐 건가

핵심만 말하면 이렇습니다. 예전엔 한 달에 프리미엄 요청 몇 번, 이런 식으로 횟수를 세는 구조였는데, 이제는 실제로 사용한 토큰량만큼 크레딧을 깎아요. 1 AI Credit = $0.01로 고정돼 있고, 입력·출력·캐시 토큰을 각각 계산해서 차감합니다.

요금제별로 포함된 크레딧도 정해져 있어요. Pro는 월 $10에 1,500크레딧, Pro+는 월 $39에 7,000크레딧, Max는 월 $100에 20,000크레딧입니다. Business와 Enterprise는 각각 $19, $39 상당의 크레딧이 지급되고요.

다만 연간 구독 중이던 Pro/Pro+ 사용자는 계약이 끝날 때까지 기존 프리미엄 요청 방식을 그대로 유지합니다. 그런데 이 경우에도 모델별 배수 자체는 크게 올랐다고 해요. 일부 보도에 따르면 Claude Opus 계열은 배수가 최대 27배까지 인상됐다고 합니다. 예전엔 크레딧을 다 쓰면 자동으로 저비용 모델로 넘어갔는데, 이 기능도 이번에 사라졌습니다.

크레딧이 순식간에 사라지는 진짜 이유

모델마다 토큰 단가가 완전히 다르다는 게 핵심입니다. GitHub Docs에 게시된 가격표를 보면, GPT-5 nano는 입력 1M 토큰당 $0.20인 반면 GPT-5.5는 $5.00, Claude Opus 4.5~4.8은 $5.00입니다. 출력 기준으로 보면 GPT-5 nano는 $1.25인데 GPT-5.5는 $30.00이에요. 최상위 모델과 최하위 모델 사이 격차가 20배가 훌쩍 넘습니다.

그러니까 코드 한 줄 리팩토링하는 간단한 작업에도 Claude Sonnet이나 GPT-5.5 같은 고급 모델을 계속 붙여서 쓰면, 크레딧이 순식간에 녹아내리는 거죠. 여러 파일을 오가는 복잡한 디버깅일수록 입력 컨텍스트(토큰량)가 커지고, 모델이나 추론 수준을 자주 바꾸면 캐시가 무효화돼서 정가 토큰이 반복 청구됩니다.

다행히 코드 완성(Code Completion)과 Next Edit Suggestions는 크레딧과 무관하게 모든 유료 플랜에서 무제한으로 계속 씁니다. 크레딧이 깎이는 건 채팅, 에이전트 모드 같은 기능들이에요.

모델별 1M 토큰당 입력·출력 가격 비교 표

실제로 하루 만에 크레딧이 바닥난 사람들

GitHub 공식 Discussion(#197571)에 올라온 사례를 보면, 한 사용자는 "이전에는 월 $10에 프리미엄 요청 300개를 받았고 월말에도 100개가 남았는데, 전환 후에는 하루 만에 1,500포인트가 소진됐다"고 밝혔습니다. 하던 작업을 마치려면 $200 이상이 더 필요하다고 했고요.

이런 사례가 한둘이 아니에요. Pro+ 사용자 whitewidovv는 2시간 정상 사용만으로 $39짜리 월 크레딧을 완전히 소진했다고 보고했습니다. Franco1999std는 1,500줄짜리 파이썬 파일에서 50줄만 고쳤는데 크레딧의 70%가 날아갔다고 했고요. The Register 보도에 따르면 어떤 Pro+ 사용자는 2시간 만에 월 할당량의 8%를 썼는데, 이 속도라면 7,000크레딧이 이틀 안에 바닥날 상황이었습니다.

Hacker News에서는 한 개발자가 이번 변화를 "$80짜리 월 요금이 갑자기 $1,000으로 뛴 것과 같다"고 표현하기도 했어요. 커뮤니티에서는 이 상황을 "예측 가능한 구독제에서 스트레스 가득한 계량제로 바뀐 셈"이라고 요약하더군요.

크레딧 다 쓰면 실제로 무슨 일이 벌어지나

포함된 크레딧을 다 쓰면 선택지는 세 가지입니다.

월초 리셋까지 기다리기: 미사용 크레딧은 이월되지 않고 사라지고, 매월 1일 UTC 00시에 전체 한도로 리셋됩니다.
추가 사용량 결제: 미리 USD 단위로 예산을 설정해두면 크레딧 소진 후에도 요율대로 계속 과금되며 작업을 이어갈 수 있습니다. $10 예산 = 1,000크레딧 상당이에요.
상위 요금제로 업그레이드: 기존 요금제와 차액만 내면, 이미 쓴 크레딧이 새 요금제의 더 큰 한도 안에 포함돼서 바로 잔여 크레딧을 쓸 수 있습니다.

크레딧 소진 후 선택 가능한 세 가지 대처법을 비교한 다이어그램

여기서 가장 중요한 안전장치가 하나 있는데요. 추가 사용 예산을 $0으로 설정해두는 겁니다. 그러면 포함 크레딧을 다 쓰는 순간 코파일럿이 그냥 멈추고, 구독료 이상으로는 한 푼도 더 청구되지 않아요. "요금 폭탄"을 원천 차단하는 가장 확실한 방법이라 커뮤니티에서도 공통으로 권장하고 있습니다.

크레딧 아껴 쓰는 실전 방법

GitHub 공식 최적화 가이드와 커뮤니티 팁을 합쳐보면 이렇습니다.

작업 난이도에 맞는 모델을 씁니다. 복잡한 아키텍처 결정에는 추론 모델을, 리팩토링·포맷팅 같은 루틴 작업에는 GPT-5 nano나 mini, Gemini 3 Flash 같은 경량 모델을 씁니다.
자동 모델 선택(Auto model selection)을 켜두면 작업에 맞는 효율적인 모델을 알아서 고르고, 10% 할인까지 받습니다.
캐시된 토큰은 정가의 약 10%만 청구되니, 세션 중간에 모델이나 추론 수준을 자주 바꾸지 않는 게 좋습니다.
작업이 바뀌면 /new나 /clear로 새 대화를 시작하고, 긴 세션은 /compact로 압축합니다.
리서치 → 계획 → 구현 단계를 나눠서 불필요한 컨텍스트가 다음 단계까지 안 넘어가게 합니다.
세션별 크레딧 상한을 미리 정해두고, 테스트·린터 같은 안전장치로 에러가 반복되며 토큰을 잡아먹는 악순환을 막습니다.

크레딧 절약 체크리스트 인포그래픽

그래도 부담스럽다면 - 대안으로 갈아탄 사람들

일부 개발자는 아예 다른 도구로 옮겼습니다. 커뮤니티에서 자주 언급되는 대안은 Cursor(월 $20), Claude Code, DeepSeek V4 Pro, OpenRouter, Windsurf, Codex, LM Studio, RooCode 정도예요. 하루 만에 크레딧을 다 쓴 앞서 언급한 사용자도 결국 DeepSeek V4 Pro와 Cursor 구독으로 갈아탔다고 밝혔습니다.

어떤 도구가 낫다고 단정하긴 어려워요. 다만 지금 쓰는 워크플로우가 채팅·에이전트 모드 위주라면, 한 달 정도는 사용량을 실제로 찍어보고 비용을 비교해보는 게 먼저입니다.

FAQ

Q. 크레딧이 다 떨어지면 코드 자동완성도 안 되나요?
아닙니다. 코드 완성과 Next Edit Suggestions는 크레딧과 무관하게 모든 유료 플랜에서 무제한으로 계속 씁니다. 막히는 건 채팅과 에이전트 모드 쪽이에요.

Q. 연간 구독자도 이번 변경의 영향을 받나요?
연간 구독 중인 Pro/Pro+ 사용자는 계약 만료 전까지 기존 프리미엄 요청 방식을 유지합니다. 다만 모델별 배수 자체가 오른 상태라, 고급 모델을 쓰면 예전보다 요청이 더 빨리 줄어들 수 있습니다.

Q. 추가 결제 없이 크레딧만 쓰고 멈추게 할 수 있나요?
네, 가능합니다. 추가 사용 예산을 $0으로 설정해두면 포함 크레딧 소진 시 자동으로 사용이 중단되고, 별도 청구는 발생하지 않습니다.

이번 개편을 계기로 본인의 작업 패턴에 어떤 모델이 실제로 맞는지 한 번쯤 점검해보는 것도 나쁘지 않아요. 사용 예산부터 $0으로 맞춰두고, 그 다음에 모델 조합을 바꿔가며 실제 소모량을 지켜보는 게 가장 빠른 방법입니다.

Claude Code EACCES 오류 해결법, npm 전역 설치 실패 체크리스트

roundfigure — Wed, 8 Jul 2026 02:15:55 +0900

npm install -g @anthropic-ai/claude-code를 돌렸는데 EACCES: permission denied, mkdir '/usr/local/lib/node_modules/@anthropic-ai' 같은 에러 로그만 뜨고 멈춘 적 있으신가요? 이거, 검색해보면 십중팔구 "sudo 붙여서 설치하세요"라는 답이 먼저 나오는데 그게 진짜 근본 해결책은 아닙니다. npm이 root 소유 디렉터리에 파일을 쓰려다 막히는 게 원인이라서, sudo는 증상만 잠깐 가리는 처방이거든요. EACCES가 왜 나는지, OS별로 왜 다르게 대응해야 하는지, 그리고 Anthropic이 공식적으로 권장하는 우회 방법은 뭔지 아래서 하나씩 확인해보세요.

터미널에 표시된 npm EACCES permission denied 에러 로그 예시

EACCES 권한 오류, 왜 발생하나

npm 공식 문서에 따르면 이 오류는 npm이 전역 패키지를 설치하면서 쓰기 권한이 없는 디렉터리에 접근하려 할 때 발생합니다. 대표적으로 /usr/local/lib/node_modules처럼 root가 소유한 경로죠. 일반 사용자 계정으로는 여기에 파일을 못 만드니 mkdir 단계에서 바로 막히는 겁니다.

실제로 이 문제가 재현된 사례가 있습니다. anthropics/claude-code 저장소의 이슈 #3951에서 Ubuntu/Debian, Node.js v22.14.0, npm 10.9.2 조합으로 npm install -g @anthropic-ai/claude-code를 실행하자 위와 똑같은 에러 로그가 그대로 나왔습니다. 근데 더 흥미로운 건 그 다음이에요. 이슈 보고자가 급한 대로 sudo를 붙여서 설치는 성공했는데, 이후 claude 명령어 자체를 터미널이 못 찾는 후속 문제가 이어졌습니다. 임시방편이 또 다른 문제를 낳은 셈이죠.

sudo로 설치하면 안 되는 이유

sudo npm install -g로 밀어붙이면 당장은 설치가 됩니다. 문제는 그다음부터예요. 그렇게 설치된 파일은 전부 root 소유가 되고, 나중에 같은 패키지를 업데이트하거나 지우려 하면 다시 EACCES가 뜹니다. 게다가 sudo로 실행되는 설치 스크립트는 root 권한으로 임의 코드를 돌리는 셈이라 보안 측면에서도 좋지 않습니다.

Anthropic 공식 문서(code.claude.com/docs/en/troubleshoot-install)도 이 부분을 명확히 짚습니다. "npm install fails with EACCES / permission denied. This usually means the install was run with sudo, or your global npm directory is root-owned"라고 원인을 밝힌 뒤, sudo를 쓰지 말고 네이티브 인스톨러를 쓰거나 npm prefix를 고치라고 안내하죠. 공식 문서와 npm 쪽 설명이 정확히 같은 방향을 가리키고 있다는 게 포인트입니다.

sudo로 설치한 npm 패키지가 root 소유가 되는 구조를 보여주는 다이어그램

해결법 1 — npm 전역 디렉터리를 홈으로 옮기기

macOS·Linux에서 가장 많이 쓰이는 방법은 npm이 쓸 전역 디렉터리 자체를 사용자 홈 안으로 바꿔버리는 겁니다.

mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
export PATH=~/.npm-global/bin:$PATH
source ~/.profile
npm install -g @anthropic-ai/claude-code

기존 Node.js나 npm을 재설치할 필요가 없다는 게 이 방법의 장점입니다. 다만 npm 공식 문서는 "이 섹션은 Windows에는 적용되지 않는다"고 못 박고 있어요. Windows는 npm 전역 디렉터리가 원래부터 사용자 프로필 하위에 있어서 이런 권한 충돌이 잘 안 생기기 때문입니다.

해결법 2 — EACCES 디렉터리 소유권만 chown으로 고치기

새 디렉터리를 만드는 대신 문제가 되는 디렉터리의 소유자만 바꾸는 방법도 있습니다.

sudo chown -R $(whoami) /usr/local/lib/node_modules
sudo chown -R $(whoami) /usr/local/bin
sudo chown -R $(whoami) /usr/local/share

한 번만 실행하면 되니 간편하긴 한데, 서버를 여러 사용자가 같이 쓰는 환경이라면 추천하지 않는다는 지적이 커뮤니티 자료에도 따라붙습니다. npm 캐시 자체(~/.npm)가 원인일 때는 sudo chown -R $(whoami) ~/.npm로 대응한다는 사례도 Claude Code 관련 커뮤니티 글에서 확인됩니다.

해결법 3 — nvm으로 npm 권한 오류 자체를 없애기

npm 공식 문서는 "Node 버전 관리자를 쓰는 게 권한 문제를 피하는 가장 좋은 방법"이라고 명시합니다. nvm으로 설치한 Node는 애초에 전부 사용자 홈 디렉터리 안에 자리 잡기 때문에, root 소유 디렉터리를 건드릴 일 자체가 없어지는 거죠.

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.0/install.sh | bash
nvm install --lts
nvm use --lts
npm install -g @anthropic-ai/claude-code

기존 시스템 Node.js를 지울 필요 없이 nvm만 추가로 설치하면 됩니다. 근데 매번 새 셸을 열 때 nvm 초기화가 안 되면 또 헷갈릴 수 있으니, .bashrc나 .zshrc에 nvm 로더가 잘 들어가 있는지는 확인해두는 게 좋습니다.

npm prefix 방식, chown 방식, nvm 방식 세 가지 해결법 비교 표

해결법 4 — Anthropic 공식 권장: 네이티브 인스톨러로 npm 우회

사실 Anthropic 공식 문서가 1순위로 권장하는 건 위 세 가지 우회법이 아니라 아예 npm을 거치지 않는 겁니다. 네이티브 인스톨러는 Node.js 설치 여부와 무관하게 동작하고, 백그라운드 업데이트도 자체적으로 처리합니다.

# macOS / Linux
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

macOS는 Homebrew(brew install --cask claude-code), Windows는 WinGet(winget install Anthropic.ClaudeCode)으로도 설치할 수 있습니다. 이미 npm으로 설치해서 EACCES를 겪는 중이라면 공식 문서는 아래처럼 정리하고 넘어가라고 안내합니다.

npm uninstall -g @anthropic-ai/claude-code
curl -fsSL https://claude.ai/install.sh | bash

OS별 EACCES 권한 오류 대응, 뭐가 다른가

macOS·Linux는 네이티브 인스톨러가 ~/.local/bin/, ~/.claude/ 두 경로에 쓰기 권한을 요구합니다. test -w ~/.local/bin으로 먼저 확인하고, 안 되면 sudo chown -R $(whoami) ~/.local로 소유권만 바꿔주면 됩니다.

Windows는 사정이 좀 다릅니다. 공식 문서가 "Windows의 설치 위치는 %USERPROFILE% 하위라 이 섹션이 거의 적용되지 않는다"고 밝힐 정도로, 리눅스식 EACCES는 원래 잘 안 생깁니다. 대신 실제로 자주 걸리는 건 PATH에 claude가 안 잡혀서 나는 인식 오류, 구버전 Claude Desktop이 WindowsApps 경로에 등록해둔 Claude.exe가 PATH 우선순위를 가로채는 문제 쪽입니다. 그래도 npm 전역 경로 자체를 바꾸고 싶다면 이렇게 하면 됩니다.

mkdir %APPDATA%\npm-global
npm config set prefix %APPDATA%\npm-global

이후 시스템 환경 변수의 사용자 변수 Path에 %APPDATA%\npm-global을 추가해주면 끝입니다.

WSL은 또 다른 케이스예요. 여기서 흔한 건 EACCES가 아니라 OS 오검출과 잘못된 바이너리 참조입니다. which npm, which node 결과가 /mnt/c/로 시작한다면 Windows 쪽 바이너리를 그대로 물고 있다는 뜻이고, 이 상태에서 설치하면 플랫폼 불일치가 납니다. 공식 문서는 이럴 때 npm config set os linux를 먼저 실행한 뒤 npm install -g @anthropic-ai/claude-code --force로 설치하라고 안내하는데, 여기서도 "sudo는 쓰지 말라"는 원칙은 그대로 유지됩니다. 리눅스용 Node를 nvm이나 배포판 패키지 매니저로 따로 설치해두는 편이 근본적으로 깔끔합니다.

FAQ

Q. sudo로 일단 설치했는데 지금이라도 되돌릴 수 있나요?
가능합니다. npm uninstall -g @anthropic-ai/claude-code로 root 소유 설치본을 지운 다음, 위에서 소개한 prefix 변경이나 네이티브 인스톨러로 다시 깔면 됩니다.

Q. Windows인데도 EACCES 비슷한 오류가 났어요.
공식 문서 기준으로는 예외적인 케이스입니다. 관리자 권한으로 설치된 시스템 전역 Node.js를 쓰고 있거나, npm-global 경로 설정이 꼬여 있을 가능성이 큽니다. 위의 %APPDATA%\npm-global 설정으로 경로를 사용자 소유 쪽으로 옮겨보세요.

Q. nvm과 네이티브 인스톨러 중 뭘 써야 하나요?
Node.js를 다른 프로젝트에서도 계속 쓸 계획이면 nvm이 낫고, Claude Code만 깔끔하게 쓰고 싶다면 Anthropic이 권장하는 네이티브 인스톨러가 더 간단합니다.

다음에 볼 만한 것

설치 자체는 끝냈는데 claude 명령어가 인식이 안 되거나 로그인 단계에서 막힌다면, 이건 오늘 다룬 EACCES와는 원인이 다른 별개 이슈일 가능성이 큽니다. Claude Code 공식 트러블슈트 문서(code.claude.com/docs/en/troubleshoot-install)를 한 번 열어두고 옆에서 참고하면서 진행하는 걸 추천합니다.

클로드 종량제 전환, 진짜 영향받는 사람은 따로 있다 (2026)

roundfigure — Tue, 7 Jul 2026 12:17:47 +0900

"클로드도 이제 종량제로 바뀐다더라", "쓴 만큼 낸다는데 비용 폭탄 아니냐" — 요즘 이런 얘기 한 번쯤 들어보셨을 겁니다. 근데 이 뉴스, 절반만 맞고 절반은 좀 다르게 알려져 있어요. 종량제로 바뀐 건 맞는데, 그 대상이 여러분이 매달 $20 내는 Claude Pro가 아닐 수도 있거든요. 이 글에서는 실제로 뭐가 바뀌었고 누가 영향을 받는지, 그리고 개인·소규모 개발자가 진짜 신경 써야 할 부분이 뭔지 정리해봤습니다.

Claude 요금제 구조 - Enterprise 종량제 vs Pro/Max 정액제 비교 다이어그램

"무제한 AI 시대 끝났다"는 종량제 전환 뉴스, 정확히 뭐가 바뀐 걸까

2026년 4월 중순 보도된 내용을 보면, Anthropic이 요금 체계를 바꾼 건 사실입니다. 다만 대상이 명확해요. Claude Enterprise, 그러니까 좌석 150개 이상인 대기업 고객 제품에 한정된 변경입니다. 기존에는 사용자당 월 최대 $200 정액제였는데, 이걸 "사용자당 월 $20 기본료 + 실제 컴퓨팅 사용량에 따른 종량 과금"으로 바꾼 거예요.

라이선싱 분석 업체 Redress Compliance는 이 변화로 헤비 유저의 비용이 2배에서 3배까지 뛸 수 있다고 봤습니다. Claude Code나 Cowork처럼 컴퓨팅을 많이 쓰는 도구를 회사 전체가 돌리는 경우 특히 그렇겠죠.

같은 시기 흥미로운 해프닝도 있었습니다. AMD의 한 임원이 GitHub에 "Claude Code 성능이 떨어졌다"는 글을 올려 화제가 됐는데, Claude Code 개발자 Boris Cherny는 이를 "거짓(false)"이라 반박했어요. 가격 인상과 모델 성능 저하는 별개 얘기였다는 겁니다.

출처: Anthropic Switches to Usage-Based Billing for Enterprise Customers (PYMNTS), Anthropic Hiked the Price for Power Users (Gizmodo)

그럼 개인 Pro·Max 요금제는? 종량제 전환 대상이 아니다

여기서 많은 분들이 헷갈리시는데, 개인용 Claude Pro($20/월), Max 5x($100/월), Max 20x($200/월) 플랜은 이번 Enterprise 종량제 전환과 직접 관련이 없습니다. 여전히 정액 구독 한도 안에서 쓰는 구조 그대로예요.

사실 개인 플랜에는 예전부터 "usage credits(사용량 크레딧)"이라는 선택적 종량제 기능이 있었습니다. 구독 한도를 다 쓴 다음에도 계속 쓰고 싶으면 Settings > Usage에서 활성화해서 추가로 결제하는 방식이죠. 월간 지출 상한을 정하거나 잔액이 떨어지면 자동 충전하도록 설정할 수 있고, 일일 충전 한도는 $2,000입니다. 강제로 전환된 게 아니라 원래 있던 옵션이라는 게 핵심입니다.

Claude Settings 화면의 Usage credits 활성화 및 지출 한도 설정 메뉴

출처: Manage usage credits for paid Claude plans (Claude Help Center)

그런데 개인 사용자도 요금 면에서 이미 두 번은 영향받았다

여기서 끝나면 좋겠지만, 개인·소규모 사용자가 아예 무풍지대였던 건 아닙니다. 실제로 체감할 만한 변화가 두 번 있었어요.

첫 번째는 2025년 8월 28일 도입된 주간(weekly) 사용량 한도입니다. 기존 5시간 롤링 한도에 더해서 일주일 단위 한도가 추가로 생긴 건데, Anthropic은 "현재 사용 패턴상 구독자의 5% 미만에만 영향을 줄 것"이라고 밝혔습니다. 그런데 실제로는 반응이 꽤 컸어요. Reddit에서 "Claude Is Dead" 스레드가 생길 정도였고, $200짜리 Max 요금제를 쓰면서도 주중이 끝나기 전에 한도에 도달했다는 불만이 다수 보고됐습니다. Anthropic 측은 24시간 내내 Claude Code를 돌리는 극단적 사용자와 계정 공유·재판매를 막기 위한 조치라고 설명했고요.

솔직히 말하면 "5% 미만"이라는 수치와 커뮤니티 체감 반응 사이에 간극이 있었던 셈입니다.

Reddit "Claude Is Dead" 스레드와 주간 사용량 한도 관련 커뮤니티 불만 게시글 캡처

출처: Anthropic unveils new rate limits to curb Claude Code power users (TechCrunch)

서드파티 에이전트 프레임워크 쓴다면 과금 방식이 달라진다

두 번째 변화는 2026년 4월 4일부터 적용된 건데, Claude Code나 Cowork처럼 Anthropic 자체 도구가 아니라 OpenClaw 같은 서드파티 AI 에이전트 프레임워크에서 Claude를 엔진으로 붙여 쓰는 경우입니다. 이 경우 더 이상 구독 정액 한도로 커버되지 않고, 별도의 "Extra Usage" 종량 과금이 붙게 바뀌었어요.

자동화 파이프라인이나 커스텀 에이전트를 굴리는 개발자, 스타트업이라면 여기서 체크해야 할 게 있습니다. 지금 쓰는 도구가 Anthropic 공식 앱인지, 아니면 Claude를 엔진으로만 가져다 쓰는 서드파티 프레임워크인지에 따라 청구 방식이 완전히 갈리거든요.

출처: Anthropic, 4월 4일부터 Claude 구독으로 OpenClaw 등 서드파티 하네스 사용 시 별도 과금 시행 (박재홍의 실리콘밸리)

예고됐다가 없던 일이 된 6월 15일 요금 개편 계획 — 그래도 안심은 이르다

여기서 한 번 더 반전이 있습니다. 2026년 5월 14일, Anthropic은 구독 청구 체계를 아예 뜯어고치는 계획을 발표했어요. 웹 채팅·터미널 대화형 Claude Code·Cowork를 묶은 "Interactive Pool"과, Agent SDK·claude -p 프로그래밍 호출·CI 환경·서드파티 앱을 묶은 "Agent SDK Credit Pool"을 분리한다는 내용이었죠. 계획대로였다면 6월 15일부터 Pro $20 플랜에는 표준 API 요금 기준 별도 월별 크레딧이 부여되고, 초과분은 이월도 안 되는 구조였습니다.

근데 실제 시행일인 6월 15일, Anthropic은 이 변경을 시행하지 않는다고 공식 확인했습니다. Agent SDK든 claude -p든 서드파티 앱이든 기존 구독 한도에서 그대로 차감되고, 새 크레딧도 부여되지 않는다는 거예요. 왜 철회했는지 구체적인 이유는 공개하지 않았고, "사용자들의 활용 방식을 더 잘 지원하기 위해 재검토 중"이라는 원론적 설명만 나왔습니다.

즉 자동화 워크로드를 분리 과금하겠다는 시도는 한 번 나왔다가 시행 직전에 접힌 상태입니다. 지금 당장 영향은 없지만, 자동화 파이프라인이나 Agent SDK 기반 서비스를 운영 중이라면 이 사안이 언제든 다시 테이블에 올라올 수 있다는 신호로 봐두는 게 맞을 것 같습니다.

출처: Anthropic June 15 Claude subscription billing overhaul (Apiyi.com), Claude Credit Overhaul 2026: Anthropic Pauses the June 15 Change (Digital Applied)

Sonnet 5 모델 가격도 같이 체크해야 하는 이유

요금제 얘기가 나온 김에 모델 가격도 짚고 넘어갈게요. Claude Sonnet 5는 출시 이후 2026년 8월 31일까지 도입가(입력 백만 토큰당 $2, 출력 백만 토큰당 $10)가 적용되고, 9월 1일부터는 정가(입력 $3, 출력 $15)로 오릅니다.

근데 여기 함정이 하나 있어요. Sonnet 5는 새 토크나이저를 써서 같은 텍스트라도 이전 모델(4.6) 대비 토큰 수가 약 30% 더 많이 잡힙니다. 토큰당 단가만 보면 도입가가 저렴해 보이지만, 요청 하나당 실제 비용은 그만큼 줄지 않을 수 있다는 얘기입니다.

출처: Claude Sonnet 5 Pricing 2026: The Hidden Costs and Real Savings (Finout)

개인 개발자가 실제로 할 수 있는 비용 관리 방법

정리하자면 개인·소규모 개발자가 진짜 신경 써야 할 건 Enterprise 종량제가 아니라 주간 한도, 서드파티 프레임워크 과금, 그리고 앞으로 다시 나올 수 있는 분리 과금 논의입니다. 지금 당장 할 수 있는 실전 대응은 이렇습니다.

/usage-credits 명령으로 월간 지출 상한선을 미리 정해두기. 한도에 도달하면 CLI 안에서 바로 올릴지 물어봐서 작업 흐름이 끊기지 않습니다.
Settings > Usage에서 5시간 세션 게이지와 주간 사용량 게이지를 주기적으로 확인하기.
세션이 길어지면 /clear로 컨텍스트를 초기화해서 불필요한 토큰 소비 줄이기.
설계·계획 단계에만 Opus를 쓰고, 일상적인 코딩 작업은 상대적으로 저렴한 Sonnet을 기본값으로 두기.
파일 전체를 붙여넣기보다 파일 경로를 참조하는 방식으로 입력 토큰 아끼기.

참고로 Anthropic 자체 데이터에 따르면 Claude Code 사용자의 평균 비용은 개발자 1인당 하루 약 $6이고, 90%의 사용자는 하루 $12 미만을 쓴다고 합니다. 숫자만 보면 "종량제 비용 폭탄"이라는 표현이 개인 사용자한테는 좀 과장된 프레임일 수 있어요.

출처: Claude Code Usage Limits and Pricing, Explained (CC for Everyone)

자주 묻는 질문

Q. 저는 Claude Pro($20/월)만 쓰는데 이번 종량제 전환으로 요금이 오르나요?
A. 아니요. 이번에 종량제로 바뀐 건 Claude Enterprise(150인 이상) 제품이고, Pro/Max 개인 플랜은 대상이 아닙니다. 다만 한도를 초과해서 usage credits를 켜둔 상태라면 그 초과분에 대해서는 원래부터 종량 과금이었습니다.

Q. Claude Code로 자동화 스크립트나 CI 파이프라인을 돌리고 있는데 영향이 있을까요?
A. Anthropic 자체 도구(Claude Code, Cowork)는 여전히 구독 한도에서 차감됩니다. 다만 OpenClaw 같은 서드파티 프레임워크로 Claude를 붙여 쓴다면 2026년 4월 4일부터 별도 종량 과금 대상입니다.

Q. 6월 15일에 시행 예정이었다는 Agent SDK 분리 과금은 지금 적용된 상태인가요?
A. 아니요. Anthropic이 시행 직전 보류했고, 2026년 7월 현재까지 기존 구독 한도 그대로 유지되고 있습니다. 다만 향후 재추진될 가능성은 열려 있는 상태입니다.

주간 한도나 서드파티 과금 정책은 앞으로도 계속 바뀔 여지가 있는 영역입니다. 자동화 워크플로우를 운영하고 있다면 Anthropic 공지사항을 가끔이라도 확인해두는 게 나중에 청구서 보고 놀라는 것보다 낫습니다.

HWP-MCP 완벽 가이드 2026, Claude로 한글 문서 자동화하기

roundfigure — Mon, 6 Jul 2026 09:43:35 +0900

"HWP-MCP 깔았는데 왜 한글 프로그램이 없다고 에러가 나지?" 혹은 반대로 "한글 프로그램도 없는데 이게 왜 돼?" — HWP-MCP를 검색해서 들어온 분이라면 둘 중 하나의 궁금증을 안고 왔을 겁니다. 결론부터 말하면 둘 다 맞는 말입니다. HWP-MCP라는 이름을 쓰는 프로젝트가 GitHub에 여러 개 있고, 그중 어떤 걸 설치했느냐에 따라 답이 정반대로 갈리거든요. 이 글에서는 어떤 프로젝트가 있는지, 내 상황(한컴오피스 있음/없음, OS)에 맞는 선택지가 뭔지 정리해봤습니다.

Claude Desktop 설정 화면에 HWP-MCP 서버가 등록된 모습

HWP-MCP, 사실 하나가 아니다

저도 처음엔 "HWP-MCP"를 검색하면 나오는 첫 번째 저장소만 보고 "아, 이거구나" 했는데, 알고 보니 GitHub에 같은 이름의 서로 다른 프로젝트가 최소 두 개, 관련 프로젝트까지 합치면 다섯 개 넘게 있더군요. 개발자도 다르고, 구현 언어도 다르고, 심지어 한컴오피스가 필요한지 아닌지도 반대입니다.

대표적으로 jkf87/hwp-mcp(Python, 스타 259개)와 treesoop/hwp-mcp(TypeScript, 스타 51개)가 이름이 완전히 똑같습니다. 여기에 HWPX 전용인 airmang/hwpx-mcp-server(스타 62개), 세부 제어 기능이 많은 crowwan/hwp-mcp-advanced-custom, Go로 짠 m1ns2o/hwp-mcp-go 같은 프로젝트까지 있습니다. 전부 2025~2026년 사이에 만들어진 개인·소규모 개발팀 프로젝트고, 한글과컴퓨터가 공식으로 만든 건 하나도 없습니다.

그러니까 "HWP-MCP 설치법"을 검색해서 나온 글을 그대로 따라 했는데 안 된다면, 애초에 다른 프로젝트 얘기를 보고 있었을 가능성부터 의심해봐야 합니다.

한컴오피스 설치가 필요한가 — 프로젝트마다 답이 다르다

이게 이 글에서 제일 중요한 부분입니다. HWP-MCP를 쓰려면 한글(한컴오피스) 프로그램이 PC에 깔려 있어야 하냐는 질문, 답은 "어느 프로젝트를 쓰느냐에 따라 다르다"입니다.

이미 한컴오피스가 깔려 있는 Windows 사용자 → jkf87/hwp-mcp

jkf87/hwp-mcp는 pywin32 기반 COM 자동화 방식입니다. 쉽게 말해 한글 프로그램을 실제로 백그라운드에서 실행시켜놓고 Claude가 그 프로그램을 원격 조종하는 구조예요. 그래서 Windows여야 하고, 한글 프로그램이 실제로 설치되어 실행 가능한 상태여야 동작합니다. README에는 문서 생성, 텍스트 삽입, 글꼴 설정, 표 생성과 데이터 채우기, 여러 작업을 순서대로 실행하는 배치 기능이 있다고 나와 있습니다.

설치는 git clone https://github.com/jkf87/hwp-mcp.git 후 pip install -r requirements.txt, 그다음 Claude Desktop 설정 JSON에 Python 스크립트 경로를 직접 적어주는 방식입니다.

{
  "mcpServers": {
    "hwp": {
      "command": "python",
      "args": ["경로/hwp-mcp/hwp_mcp_stdio_server.py"]
    }
  }
}

한글 프로그램의 외부 파일 접근 보안 경고를 우회하는 DLL 모듈도 포함돼 있는데, 반대로 말하면 한글 프로그램이 안 켜져 있으면 연결 자체가 실패할 수 있다는 뜻이기도 합니다. 이미 회사·관공서 PC에 한컴오피스가 깔려 있고 Windows만 쓴다면 가장 직관적인 선택지입니다.

한컴오피스 없이 크로스플랫폼으로 쓰고 싶다 → treesoop/hwp-mcp

treesoop/hwp-mcp는 완전히 다른 접근입니다. Rust/WebAssembly로 만든 자체 HWP 파싱 엔진 rhwp 위에 34개 도구를 얹은 구조라, 한글 프로그램 없이 macOS·Windows·Linux 어디서나 동작한다고 README에 명시돼 있습니다. 설치도 claude mcp add hwp-mcp -- npx -y hwp-mcp 한 줄이면 끝이라 훨씬 간단하고요.

다만 함정이 하나 있습니다. 읽기(문서 내용·표·이미지 추출, SVG/HTML 렌더링)는 .hwp와 .hwpx 둘 다 되는데, 쓰기(텍스트 치환, 템플릿 채우기, 문단/표 추가)는 .hwpx 포맷에서만 지원됩니다. 기존 구버전 .hwp 파일을 열어서 내용을 편집하려는 거라면 이 프로젝트로는 안 될 수 있다는 얘기죠.

HWPX 문서만 다루면 된다 → airmang/hwpx-mcp-server

애초에 다루는 문서가 최신 개방형 포맷인 .hwpx뿐이라면 airmang/hwpx-mcp-server도 대안입니다. 순수 파이썬 라이브러리 python-hwpx 위에서 동작해서 한컴오피스가 필요 없고, Windows·macOS·Linux 모두 지원합니다. uvx hwpx-mcp-server 명령으로 바로 설치되고, 열람·검색·편집·양식 채움·문서 생성까지 지원합니다. 다만 이름 그대로 .hwpx만 대상이고 바이너리 .hwp는 처음부터 편집 대상이 아니라고 README에 못 박혀 있어서, 옛날 .hwp 문서가 많다면 이건 선택지에서 빠집니다.

jkf87 hwp-mcp, treesoop hwp-mcp, airmang hwpx-mcp-server 3개 프로젝트 비교표 - 언어, OS, 한컴오피스 필요 여부, 지원 포맷

그 외 HWP-MCP 후보군 — 더 있다

여기까지가 널리 쓰이는 세 개고, 그 외에도 crowwan/hwp-mcp-advanced-custom(Windows COM 기반, 59개 이상의 세부 제어 기능, 스타 6개), Dayoooun/hwpx-mcp(스타 27개), m1ns2o/hwp-mcp-go(Go로 짠 Windows 전용, 스타 2개) 같은 프로젝트도 검색에서 확인됩니다.

crowwan 프로젝트는 README에서 스스로 한계를 인정하는 부분이 눈에 띄었는데, 한글 파일을 여러 개 동시에 열면 각각 별도 프로세스로 뜨지만 COM은 한 프로세스에만 연결되기 때문에 다중 문서 작업에는 제약이 있다고 직접 경고해두고 있습니다. Dayoooun과 m1ns2o 프로젝트는 스타·포크 수가 적어서 아직 커뮤니티에서 검증된 규모는 크지 않다고 보는 게 맞습니다.

HWP-MCP로 실제로 뭘 할 수 있나

프로젝트마다 기능 범위는 다르지만, 공통적으로 확인되는 작업을 묶어보면 이렇습니다.

문서 생성·열기·저장·닫기
텍스트 삽입과 글꼴·문단·페이지 서식 설정
표 생성, 셀 데이터 채우기, 연속 번호 자동 채우기
찾기/바꾸기, {{이름}} {{날짜}} 같은 템플릿 변수 채우기
본문·표·이미지·머리말·꼬리말·각주·수식 추출, 문서 메타정보(버전, 페이지 수, 글꼴) 조회
여러 작업을 순서대로 묶어 실행하는 배치 처리

이 중 "템플릿 채우기"와 "표에 데이터 채우기"가 실무에서 제일 쓸모 있는 조합이라고 생각합니다. 보고서 양식 하나 만들어두고 Claude한테 "이 표에 이번 분기 매출 데이터 채워줘" 하는 식으로 시키면 되니까요.

Claude 대화창에서 HWP 표에 데이터를 채우도록 요청하는 예시 화면

HWP-MCP 한계와 실사용 후기, 그런데 걸러 들어야 할 부분도 있다

TreeSoop 자사 블로그(개발사 측 설명)에 따르면 한글 수식 편집기로 만든 수식은 텍스트 추출이 제한적이고, 비밀번호 걸린 문서는 파싱이 막히며, 1990년대 후반의 구버전 HWP 포맷은 아예 지원하지 않는다고 합니다. 검색어가 두 텍스트 노드에 걸쳐 있으면 매칭이 안 되는 것도 알려진 한계입니다. 다만 이건 프로젝트 운영사가 직접 쓴 홍보성 글이라 독립적인 제3자가 검증한 내용은 아니라는 점, 감안하고 읽어야 합니다.

"공공기관의 91%가 한컴오피스를 쓰는데 AI는 HWP를 제대로 못 읽는다"는 문제의식은 실제 현장에서도 확인됩니다. 웹진 인벤(2026-04-20)에 따르면 광진구청 소속 7년 차 공무원이 이 문제를 직접 겪고 HWP/HWPX/PDF를 AI가 읽을 수 있게 변환하는 도구를 직접 만들어 공개한 사례가 있습니다. hwp-mcp 계열 프로젝트에 대한 후기는 아니지만, 문제 자체가 현장에서 실제로 겪는 일이라는 근거는 됩니다.

HWP를 여전히 많이 쓰는 이유, 그런데 흐름이 바뀌고 있다

1990년대 초 정부가 HWP를 공문서 표준 포맷으로 지정한 이래로 행정 전산망과 전자결재 시스템 대부분이 이 형식 기반으로 굳어졌습니다. 직원들이 익숙한 양식으로 문서를 올리고 결재받을 수 있고, 글자 겹치기·페이지 보호 같은 한글 전용 기능이 기존 그룹웨어와 궁합이 좋다는 점이 배경입니다.

근데 최근 이 흐름에 제동이 걸렸습니다. 국가인공지능전략위원회가 2026년 4월 24일 행정안전부·문화체육관광부와 함께 공공 문서 유통망에서 바이너리 HWP 사용을 단계적으로 제한하고 개방형 포맷 HWPX로 전환하는 방침을 발표했거든요. 행정 전산망은 5월 18일부터 지자체로 HWPX 적용을 확대했고, 공무원 메일 시스템은 10월까지 전환을 완료할 계획입니다. AI가 기존 바이너리 HWP는 구조상 데이터를 잘 못 뽑아내는데, HWPX는 문서 구성요소가 구조화돼 있어서 AI 활용도가 높다는 게 정부 판단입니다. 이 흐름을 보면 HWPX 전용으로 만들어진 airmang/hwpx-mcp-server 같은 프로젝트의 존재 가치가 앞으로 더 커질 가능성이 있어 보입니다.

결국 어떤 HWP-MCP를 골라야 하나

결론부터 말하면 이렇습니다.

Windows + 한컴오피스가 이미 깔려 있고, 기존 .hwp 파일을 직접 편집해야 한다 → jkf87/hwp-mcp
한컴오피스 없이 macOS·Linux에서도 쓰고 싶다, 읽기 위주 작업이 많다 → treesoop/hwp-mcp
다루는 문서가 전부 .hwpx고 크로스플랫폼이 필요하다 → airmang/hwpx-mcp-server
한글 COM 자동화로 더 세밀한 서식 제어가 필요하다 → crowwan/hwp-mcp-advanced-custom (단, 다중 문서 동시 작업 제약 있음)

세 가지 질문만 스스로 던져보면 답이 나옵니다. 한컴오피스가 설치돼 있는가, OS가 뭔가, 다루는 파일이 .hwp인가 .hwpx인가.

자주 묻는 질문

Q. HWP-MCP 설치했는데 Claude가 도구를 인식 못 해요.
세션을 재시작해야 새로 등록한 MCP 도구가 보이는 경우가 많습니다. treesoop/hwp-mcp README는 claude mcp list | grep hwp-mcp 실행 시 ✓ Connected가 뜨는지부터 확인하라고 안내합니다.

Q. jkf87/hwp-mcp를 설치했는데 연결이 안 돼요.
한글 프로그램이 실제로 실행 중이어야 COM 연결이 됩니다. 한글 프로그램을 먼저 켜둔 상태에서 다시 시도해보세요.

Q. 회사 문서를 외부로 안 보내고 싶은데 안전한가요?
treesoop/hwp-mcp README는 로컬 실행이 기본값이라 문서를 외부 서버로 전송하지 않는다고 설명합니다. 다만 이 역시 프로젝트 측 자체 설명이니 폐쇄망 환경이라면 소스 코드를 직접 확인해보는 걸 권합니다.

한컴오피스 유무, OS, 다루는 파일 포맷 세 가지만 확인하면 어떤 프로젝트를 설치해야 할지는 이미 정해진 셈입니다. 직접 설치해보고 막히는 부분이 있으면, 이 글에서 다룬 세 프로젝트 중 어떤 걸 썼는지부터 다시 확인해보세요. 대부분의 삽질은 거기서 시작됩니다.

Claude Code Plan Mode 완벽 활용법: 설계부터 실행까지

roundfigure — Sun, 5 Jul 2026 21:31:44 +0900

Claude Code로 코드를 고치다가 갑자기 파일이 엉뚱하게 바뀐 경험, 한 번쯤 있으실 거예요. 저도 처음엔 그냥 프롬프트만 잘 쓰면 되는 줄 알았는데, 여러 파일에 걸친 작업을 시킬 때마다 결과물이 매번 달라지는 걸 보고 나서야 Plan Mode를 진지하게 들여다봤습니다. Claude Code Plan Mode는 Claude가 파일을 고치기 전에 먼저 계획만 세우게 만드는 권한 모드인데, 언제 켜고 언제 꺼야 하는지 감이 안 잡히면 오히려 작업 속도만 늦출 수 있어요. 이 글에서는 진입 방법부터 승인 흐름, 실전 판단 기준, 그리고 실제 써보면서 걸리는 버그까지 정리했습니다.

Claude Code 터미널에서 Shift+Tab으로 Plan Mode 전환 화면

Claude Code Plan Mode란 무엇인가

공식 문서 기준으로 Claude Code의 권한 모드는 총 6가지입니다. default(읽기만 자동 승인), acceptEdits(읽기+파일 편집 자동 승인), plan, auto(백그라운드 안전 검사와 함께 전부 자동 승인), dontAsk(사전 승인된 도구만), bypassPermissions(격리된 컨테이너 전용, 전부 무승인 실행)입니다. 그중 plan 모드는 "Claude reads files, runs shell commands to explore, and writes a plan, but does not edit your source"라고 문서에 명시되어 있어요. 쉽게 말해 파일을 읽고 탐색은 하지만 실제로 뭘 고치지는 않는 상태입니다.

재밌는 건 이 정체성에 대한 시선이 하나만 있는 게 아니라는 점이에요. 공식 문서는 Plan Mode를 도구 호출 자체를 막는 권한 모드로 설명합니다. 반면 개발자 Armin Ronacher는 2025년 12월 블로그에서 다른 각도로 분석했어요. 그의 표현을 빌리면 "a plan in Claude Code is effectively a markdown file written into Claude's plans folder by Claude in plan mode"입니다. 즉 도구 수준의 하드 제약이라기보다, "읽기 전용으로 행동하라"는 반복적인 프롬프트 지시와 계획 마크다운 파일을 다루는 상태 머신에 가깝다는 주장이죠. 어느 쪽이 완전히 맞다고 단정하기는 어렵지만, 실제로 써보면 최소한 편집 도구가 막혀 있다는 체감은 확실히 있습니다.

Claude Code 6가지 권한 모드 비교표

Plan Mode 진입하는 세 가지 방법

진입 방법은 세 가지예요.

CLI 세션 중 Shift+Tab을 반복 입력합니다. 기본 순환 순서는 default → acceptEdits → plan이고, 현재 모드는 상태 표시줄에 나타납니다.
프롬프트 앞에 /plan을 붙입니다. 해당 턴 한 번만 Plan Mode로 들어가요.
시작 시 claude --permission-mode plan 플래그를 씁니다.

나가고 싶으면 Shift+Tab을 한 번 더 누르면 그만입니다. VS Code는 프롬프트 박스 하단 모드 표시기를 클릭하고, JetBrains 플러그인은 터미널에서 CLI와 동일하게 Shift+Tab을 씁니다. 프로젝트 전체에서 항상 Plan Mode로 시작하게 강제하고 싶으면 .claude/settings.json에 "permissions": { "defaultMode": "plan" }을 추가하면 됩니다.

계획 승인부터 실행 전환까지

계획이 다 만들어지면 Claude가 계획 내용을 보여주고 다음 중 하나를 고르라고 물어요.

auto 모드로 승인 후 바로 시작
accept-edits 모드로 승인
편집을 하나씩 수동으로 검토하며 승인
피드백을 주고 계획을 계속 다듬기
Ultraplan으로 넘겨서 브라우저 기반 검토로 정교화

승인하는 순간 Plan Mode는 종료되고, 고른 권한 모드로 세션이 전환되면서 실제 편집이 시작됩니다. 계획 내용을 텍스트로 직접 손보고 싶으면 Ctrl+G로 기본 에디터에서 열어 수정할 수도 있어요.

계획 승인 옵션 5가지와 실행 전환 흐름도

Plan Mode, 언제 진짜 효과가 있을까

"diff를 한 문장으로 설명할 수 있으면 Plan Mode를 건너뛰어라"는 게 공식 문서와 커뮤니티에서 공통으로 나오는 실전 기준입니다. 오타 수정, 로그 한 줄 추가, 변수 이름 바꾸기처럼 범위가 뻔한 작업에는 계획 단계 자체가 오버헤드예요. 반대로 여러 파일을 건드리거나, 익숙하지 않은 코드 영역이거나, 접근 방식 자체가 확실하지 않을 때는 얘기가 달라집니다.

Claude Code 팀의 Boris Cherny는 Hacker News에서 이렇게 말했어요. "Use Plan mode (press shift-tab 2x). Go back and forth with Claude until you like the plan before you let Claude execute. This easily 2-3x's results for harder tasks." 어려운 작업일수록 계획을 한 번에 승인하지 말고 마음에 들 때까지 주고받으라는 조언인데, 저도 큰 리팩터링 작업에서는 계획 단계에서 두세 번 더 물어보고 나서야 실행 버튼을 누르는 편입니다.

규모가 큰 작업은 Ultraplan으로

/ultraplan 명령을 쓰면 로컬 CLI의 계획 작업을 Claude Code on the web 세션으로 넘길 수 있어요. 여러 에이전트가 병렬로 계획을 짜기 때문에, 표준 모드로 4분 넘게 걸리던 계획 수립이 약 1분 만에 끝난다고 소개됩니다. 계획이 준비되면 브라우저에서 특정 구간에 인라인 댓글을 달아 수정 요청을 할 수 있고, 마음에 들면 브라우저에서 바로 실행할지 로컬 터미널로 돌려보낼지 고를 수 있습니다. 다만 Git 저장소, Pro나 Max 구독, GitHub 연동 저장소가 필요해요. GitLab이나 Bitbucket, 로컬 전용 저장소는 아직 지원되지 않습니다.

실전에서 마주치는 버그도 알아두기

Plan Mode를 쓰다 보면 최근에 고쳐진 버그들도 눈에 띕니다. v2.1.198(2026-07-01)에서는 plan 모드에서 상태를 변경하는 브라우저 도구 호출에 프롬프트가 뜨지 않던 문제가 수정됐고, v2.1.172(2026-06-10)에서는 세션이 plan 모드로 시작될 때 읽기 전용 호출이 자동 승인되지 않던 문제가 고쳐졌어요.

근데 아직 공식적으로 해결됐다고 보기 어려운 이슈도 있습니다. Hacker News 댓글에서 한 사용자는 Claude Code가 계획을 ~/.claude/plans에 동물 이름으로 저장하는데, 같은 세션에서 완전히 다른 작업을 새로 계획시켜도 이전에 저장된 첫 계획을 계속 참조하는 현상을 겪었다고 보고했어요. 임시 해결책으로는 명시적으로 "새 계획을 세워달라"고 요청하거나, 작업 단위마다 세션을 새로 시작하는 방법이 제시됐습니다. 공식 문서에는 이 부분이 따로 언급돼 있지 않으니, 반복적으로 계획을 여러 번 새로 짜는 작업 흐름이라면 한 번쯤 의심해볼 만한 지점입니다.

Plan Mode 하나만 켜놓는다고 모든 게 해결되지는 않아요. 지금 하려는 작업이 diff 한 문장짜리인지 먼저 따져보고, 애매하면 일단 켜서 계획부터 받아보는 쪽을 권합니다. 계획이 마음에 안 들면 승인하지 말고 피드백부터 주고받아 보세요.

Claude Code Task Budgets, 왜 안 될까 — API 비용 폭주 진짜로 막는 법 (2026)

roundfigure — Sun, 5 Jul 2026 14:49:07 +0900

Claude Code 쓰다가 "이거 토큰을 너무 많이 먹는데, Task Budgets라는 게 있다던데 그거 설정하면 되나?" 싶어서 찾아본 분 꽤 있을 겁니다. 저도 처음엔 그렇게 생각했는데, 공식 문서를 열어보니 마지막 줄에 이렇게 딱 적혀 있더라고요. "Task budgets are not supported on Claude Code or Cowork surfaces." 그러니까 Claude Code나 Cowork에서는 이 기능 자체가 안 됩니다. 근데 그럼 대체 Claude Code에서 진짜 비용 폭주는 뭘로 막아야 하나 — 이게 이 글의 진짜 질문입니다.

Claude Platform Docs의 Task budgets 문서 중 "Not supported on Claude Code or Cowork surfaces" 문구가 있는 Feature support 섹션 캡처

Task Budgets가 Claude Code에서 안 되는 이유

결론부터 말하면 Task Budgets는 Claude API의 output_config.task_budget 파라미터입니다. Messages API를 직접 호출하는 개발자용 기능이지, Claude Code CLI 안에 노출되는 설정값이 아니에요. 공식 문서 Feature support 섹션에 "지원 모델에서 Messages API를 통해 직접 사용하라"고 명시돼 있으니, Claude Code 설정 파일 어디를 뒤져도 이 옵션은 나오지 않습니다. 검색해서 여기 들어온 분이라면 이 부분부터 확실히 짚고 넘어가는 게 맞다고 봅니다 — 없는 기능을 찾느라 시간 쓸 필요는 없으니까요.

그래서 Task Budgets는 정확히 뭔가

간단히만 짚고 넘어가겠습니다. Task budgets는 Claude에게 "이번 에이전틱 루프(사고+툴콜+툴결과+출력 전체)에서 쓸 수 있는 토큰이 이 정도"라고 미리 알려주는 기능입니다. output_config.task_budget = {"type": "tokens", "total": 64000} 형태로 설정하고 anthropic-beta: task-budgets-2026-03-13 헤더를 붙여야 하는데, 여기서 중요한 건 이게 하드 캡이 아니라는 점이에요. 공식 문서 표현 그대로 "advisory, not enforced" — 권고일 뿐 강제가 아닙니다. Claude는 예산을 넘겨서라도 작업을 계속할 수 있고, 진짜 절대 상한이 필요하면 max_tokens를 같이 걸어야 합니다. 최소 설정값도 20,000토큰이라 이보다 작게 잡으면 400 에러가 나고, 너무 낮게 잡으면 오히려 Claude가 작업을 거절하거나 대충 끝내버리는 부작용이 생길 수 있다고 문서는 경고합니다. 지원 모델도 아직 Claude Fable 5·Mythos 5·Opus 4.8·Opus 4.7 정도로 베타 단계고, 정작 많이 쓰는 Sonnet 5나 Opus 4.6, Haiku 4.5에서는 아예 지원하지 않습니다.

task_budget 파라미터 구조도 - total, remaining, type 필드 설명

Claude Code에서 진짜 비용 폭주를 막는 법

Task Budgets는 못 쓰지만, Claude Code 자체 비용 관리 문서를 보면 이미 쓸 수 있는 도구가 여럿 있습니다. 사실 이쪽이 진짜 실전 정보입니다.

/usage: 현재 세션 토큰 사용량과 로컬 추정 비용을 바로 보여줍니다. Pro/Max/Team/Enterprise 플랜이면 스킬·서브에이전트·플러그인·MCP 서버별로 어디서 얼마나 썼는지 24시간/7일 단위로 쪼개서 볼 수 있어요.
/usage-credits: Pro·Max 플랜에서 월간 지출 한도를 직접 걸 수 있습니다. 한도에 닿으면 CLI 안에서 올릴지 말지 물어보는데, 결제 권한이 있어야 변경 가능합니다.
워크스페이스 지출 한도: Claude API로 쓰는 경우 Claude Code 전용 워크스페이스 전체에 지출 한도를 걸 수 있고, 관리자는 콘솔에서 비용 리포트를 확인합니다.
조직 레이트리밋: 팀 규모별 권장치가 따로 있습니다. 1~5명 팀이면 사용자당 200k~300k TPM에 5~7 RPM 정도, 500명 넘는 조직이면 오히려 사용자당 10k~15k TPM, 0.25~0.35 RPM으로 낮춥니다.

여기서 진짜 조심해야 할 부분이 에이전트 팀(Agent teams)입니다. 여러 Claude Code 인스턴스를 동시에 띄우는 기능이라 팀원 수만큼 토큰 소비가 배로 늘어나는데, 플랜 모드로 돌리는 에이전트 팀은 표준 세션 대비 무려 7배 더 많은 토큰을 씁니다. 기본적으로 꺼져 있고 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 환경변수를 켜야 활성화되는데, 켤 거면 팀 규모를 작게, spawn 프롬프트는 간결하게, 작업 끝난 팀원은 바로 종료하는 게 낫습니다. 이 프로젝트도 오케스트레이터-서브에이전트 구조를 쓰고 있는데, 서브에이전트가 늘어날수록 토큰이 배로 불어난다는 걸 체감하고 나서는 spawn 프롬프트를 최대한 짧게 쓰려고 신경 쓰게 됐습니다.

이 외에도 컨텍스트 관리(/clear, /compact), 서브에이전트에 Haiku 지정하기, CLAUDE.md는 200줄 이하로 유지하고 나머지는 skills로 옮기기 같은 절감 전략이 있습니다. 참고로 엔터프라이즈 평균은 개발자 1인당 활성일 기준 약 $13, 월 $150~250 수준이고 상위 90% 사용자는 활성일당 $30 미만이라고 하니, 이 범위를 크게 벗어난다면 뭔가 새고 있다는 신호로 봐도 됩니다.

Claude Code /usage 명령어 실행 화면 - 스킬/서브에이전트별 사용량 분류 예시

Uber도 못 피한 비용 폭주, 그래서 나온 Spend-Threshold Alerts

이 기능들이 왜 이렇게 촘촘해졌는지 배경을 보면 이해가 빠릅니다. 보도에 따르면 Uber는 2025년 12월 약 5,000명 엔지니어에게 Claude Code를 배포했고, 넉 달 만인 2026년 4월에 그해 AI 예산 전체를 에이전틱 코딩 세션으로 다 써버렸습니다. 더 극단적인 사례도 있는데, 어떤 기업은 사용량 상한을 아예 걸지 않은 채 배포했다가 한 달 만에 약 5억 달러를 지출했다고 Axios가 보도했어요. 5억 달러, 숫자만 봐도 아찔합니다. Microsoft는 2026 회계연도 마감을 앞두고 한 사업부 내부 Claude Code 라이선스를 취소하기 시작했다는 얘기까지 나왔고요.

이런 배경 속에서 Anthropic은 2026년 7월 2일 Claude Enterprise용 관리자 도구를 새로 공개했습니다. 그룹·사용자별 분석 대시보드, Claude Code 전용 "Usage"·"Value" 탭(활성 개발자 수, 세션 수, 커밋당 비용까지 보여줌), 자연어로 질의하는 Analytics Chat, 그리고 핵심인 Spend-Threshold Alerts — 조직 지출 한도의 75%·90%에 도달하면, 개인 사용자는 75%·95%에 도달하면 알림을 보내는 기능입니다. 에이전틱 AI 툴이 단순 챗 질의보다 최대 1000배 많은 토큰을 소비할 수 있다는데, 이 정도면 클라우드 컴퓨팅 시대의 FinOps(재무 운영) 개념이 에이전틱 AI에도 그대로 옮겨올 만하지 않을까요?

3rd party 가이드와 공식 문서가 다르게 말하는 부분

찾아보다 보면 헷갈릴 수 있는 부분이 하나 있습니다. Verdent라는 곳의 가이드(2026-04-27 발행)는 "task budgets를 API 파라미터나 Claude Code 설정으로 구성한다"고 서술하고 있어요. 근데 이건 공식 문서의 "Claude Code 미지원" 명시와 정면으로 충돌합니다. 이런 경우엔 1차 소스, 그러니까 Anthropic 공식 문서 쪽을 믿는 게 맞습니다. Verdent 쪽 서술은 베타 초기에 나온 부정확한 정보이거나, 이후 문서가 갱신되기 전 스냅샷일 가능성이 커 보입니다. 이 글 쓰면서 느낀 건데, AI 관련 기능은 베타 딱지 붙은 채로 몇 달씩 가는 경우가 많아서 3rd party 가이드보다는 항상 공식 문서의 "Feature support" 같은 섹션을 마지막에 한 번 더 확인하는 습관이 필요합니다.

지금 바로 확인해볼 것

API를 직접 호출하는 개발자가 아니라면 Task Budgets는 신경 쓸 필요도 없어요. 대신 /usage로 지금 얼마나 쓰고 있는지부터 확인하고, /usage-credits로 상한을 걸고, 팀 단위라면 관리자에게 Spend-Threshold Alerts가 켜져 있는지 물어보는 쪽이 훨씬 현실적인 대응입니다. 에이전트 팀 같은 실험적 기능을 켜뒀다면, 지금 바로 사용량부터 한번 확인해 보세요!

Claude Code ultrareview 써보니, 아무 커밋에나 쓸 건 아니었다

roundfigure — Sun, 5 Jul 2026 14:26:53 +0900

"버그 하나 놓치면 배포 후에 훨씬 크게 터진다"는 걸 아는 사람이라면 Claude Code의 ultrareview 얘기를 한 번쯤 들어봤을 겁니다. 근데 막상 찾아보면 명령어 이름부터 헷갈립니다. 지금은 /code-review ultra로 이름이 바뀌었고, /ultrareview는 예전 이름을 그대로 쓸 수 있게 남겨둔 별칭이거든요. 저도 처음엔 "왜 문서마다 이름이 다르지" 하면서 한참 헤맸는데, 직접 써보니 이름보다 중요한 건 "이걸 언제 써야 손해가 안 나는가"였습니다. 이번 글에서 실제로 확인한 가격, 소요 시간, 그리고 써보고 느낀 점을 정리해봤어요.

Claude Code 터미널에서 /code-review ultra 명령을 실행하는 화면

Claude Code ultrareview란, 로컬 리뷰와 뭐가 다른가

/code-review ultra는 Claude Code on the web 인프라 위에서 도는 딥 코드 리뷰 기능입니다. 실행하면 저장소 상태를 원격 샌드박스로 올리고, 그 안에서 여러 개의 리뷰어 에이전트 무리를 병렬로 띄워 버그를 찾습니다. 로컬에서 바로 도는 /code-review나 /review <pr>와 비교하면 공식 문서가 밝히는 차이는 세 가지예요.

첫째, 발견한 문제를 에이전트가 독립적으로 재현하고 검증한 뒤에만 최종 리포트에 넣습니다. 그래서 "이거 문제일 수도 있어요" 같은 추측성 지적이 줄고, 스타일 지적보다 실제로 동작에 영향을 주는 버그에 집중하게 됩니다. 둘째, 더 큰 규모의 에이전트 무리가 동시에 코드를 훑기 때문에 중간 강도의 로컬 리뷰가 놓칠 법한 이슈까지 잡습니다. 셋째, 전부 원격에서 돌기 때문에 로컬 자원을 하나도 안 쓰고, 리뷰가 도는 동안 터미널에서 다른 작업을 계속할 수 있습니다.

ultrareview 실행 방법: 대화형 명령과 CI용 CLI

인자 없이 /code-review ultra를 실행하면 현재 브랜치와 기본 브랜치 사이의 diff를 리뷰 대상으로 삼습니다. 커밋되지 않은 변경이나 staged 변경도 포함됩니다. /code-review ultra 1234처럼 PR 번호를 넘기면 로컬 워킹트리 대신 GitHub(또는 조직이 연결한 GitHub Enterprise Server)에서 해당 PR을 직접 클론해 리뷰하는 PR 모드로 바뀝니다. 저장소가 너무 커서 번들링이 안 되면 Claude Code가 PR 모드를 쓰라고 안내해주고, PR의 diff 자체가 너무 크면 시작 전에 범위를 좁히라는 안내와 함께 거절됩니다.

CI나 스크립트처럼 대화형 세션 없이 돌리고 싶으면 claude ultrareview 서브커맨드를 씁니다. 원격 리뷰가 끝날 때까지 블로킹하고 결과를 stdout으로 출력하며, 성공하면 종료 코드 0, 실패하면 1을 반환합니다. claude ultrareview origin/main처럼 비교할 베이스 브랜치를 지정할 수도 있고, --json 플래그로 원본 페이로드를, --timeout <분>으로 최대 대기 시간(기본 30분)을 정할 수 있습니다. 이 서브커맨드를 실행하는 순간 그 자체가 과금·약관 동의로 간주된다는 점은 알아두는 게 좋습니다.

/code-review ultra와 claude ultrareview CLI 실행 흐름 비교 다이어그램

ultrareview 가격과 무료 횟수, 생각보다 짜다

Pro와 Max 플랜은 계정당 평생 3회 무료 실행을 줍니다. 근데 이 3회, 리필이 안 됩니다. 다 쓰고 나면 매 리뷰가 usage credit으로 과금되는데 변경 규모에 따라 보통 5~20달러 수준이에요. Team과 Enterprise는 아예 무료 실행 없이 바로 usage credit으로 과금됩니다. 원격 세션이 시작되는 순간 1회로 카운트되기 때문에 중간에 중단하거나 실패해도 무료 횟수는 이미 소진됩니다. 다만 유료 리뷰라면 실제로 실행된 부분만큼만 과금된다는 게 그나마 위안이에요.

요구 사항도 확인해두는 게 좋습니다. Claude Code v2.1.86 이상이 필요하고, Claude.ai 계정 로그인이 필수입니다. API 키만으로는 못 씁니다. Amazon Bedrock, Google Cloud Agent Platform, Microsoft Foundry 경유로 쓰거나 Zero Data Retention을 켠 조직이라면 이 기능 자체를 못 씁니다.

소요 시간, 공식 문서와 실사용 후기가 갈린다

공식 문서는 보통 5~10분이 걸린다고 밝히고 있어요. 백그라운드 작업이라 세션을 계속 쓰거나 다른 명령을 시작해도 되고, 터미널을 아예 닫아도 리뷰는 계속 돌아갑니다. /tasks 명령으로 진행 중이거나 끝난 리뷰 목록을 보고 중단할 수도 있는데, 중단하면 그 시점까지의 부분 결과는 반환되지 않습니다.

근데 MindStudio의 실사용 후기는 체감 소요 시간을 10~20분으로 보고합니다. 공식 수치보다 확실히 길게 느껴진다는 거죠. 저도 실제로 돌려보면서 "언제 끝나지" 하고 딴 작업을 하다가 알림이 뜨는 걸 보고 나서야 끝난 걸 알았습니다. 기다리는 동안 다른 일을 병행할 수 있다는 건 확실히 장점이지만, 5~10분이라는 숫자만 믿고 옆에서 기다리고 있으면 좀 답답할 수 있어요.

/tasks 명령으로 ultrareview 진행 상황을 확인하는 화면

실제로 써보니: 언제 쓰고 언제 아껴야 하나

MindStudio 쪽 실사용 가이드는 명확한 기준을 제시합니다. "프로덕션 버그 하나의 비용이 20달러를 넘는 커밋에만 아껴 써라"는 겁니다. 결제 흐름, 인증, 데이터베이스 마이그레이션, 출시 직전 코드처럼 실패했을 때 리스크가 큰 변경에만 쓰고, 평소에는 무료인 일반 /review를 쓰다가 결정적인 순간에만 유료인 /code-review ultra를 투입하라는 논리입니다. 시니어 엔지니어 2시간 몸값이면 이미 20달러를 넘기 때문에 고위험 코드에는 경제적으로 타당하다는 거예요.

이 가격 정책 자체를 "유익한 마찰(beneficial friction)"이라고 부르는 시각도 있습니다. /review는 공짜고 /code-review ultra는 진짜 돈이 드니까, 자연히 싼 도구는 평소에 쓰고 비싼 도구는 진짜 중요한 커밋에만 아껴 쓰게 된다는 거죠. 반대로 effloow.com 같은 비교 자료는 변경 규모에 따라 비용이 달라지는 구조를 "팀이 PR당 토큰 비용을 예측할 수 없다"는 약점으로 짚습니다. 같은 과금 구조를 두고 관점이 정반대로 갈리는 셈인데, 저는 개인 프로젝트 기준으로는 전자 쪽에 더 공감했습니다. 아무 커밋에나 돌리면 무료 3회는 순식간에 사라지거든요.

클라우드 샌드박스라서 생기는 한계도 있습니다. 프라이빗 패키지 레지스트리, 로컬 서비스, 하드웨어 의존성, 의도적으로 제한된 시크릿에는 접근하지 못합니다. 그래서 ChatGate 쪽 소개 글은 /code-review ultra를 "최종 승인 권한이 아니라 병합 전 신호(pre-merge signal)" 정도로 보는 게 적절하다고 정리하는데, 저도 이 표현이 제일 정확하다고 느꼈습니다.

헷갈리기 쉬운 별개 기능, Anthropic "Code Review"

이름이 비슷해서 자주 혼동되는 게 하나 더 있습니다. Anthropic이 2026년 3월 9일 출시한 "Code Review"라는 기능인데, 이건 /code-review ultra와 완전히 다른 상품입니다. GitHub 저장소에 직접 연결해서 모든 PR을 자동으로 리뷰하는 관리형 서비스로, Claude Code Team/Enterprise 고객 대상 리서치 프리뷰로 제공되고 PR당 15~25달러 수준입니다. /code-review ultra가 Pro/Max 개인 세션에서 사용자가 수동으로 실행하는 것과 대조적이죠.

작동 방식은 비슷합니다. 여러 에이전트가 로직 오류, 경계 조건, API 오용, 인증 결함, 프로젝트별 컨벤션 준수 같은 서로 다른 이슈 유형을 나눠 맡고, 각 발견 사항을 반증(disprove)하려 시도한 뒤에만 PR에 게시합니다. Anthropic은 테스트 기간 동안 "의미 있는 리뷰 코멘트가 달린 PR 비율이 16%에서 54%로 늘었다"고 밝혔고, "엔지니어가 틀렸다고 표시한 발견 사항은 1% 미만"이었다고 합니다. 다만 이 기능도 PR을 직접 승인하거나 막지는 않습니다. 최종 병합 결정은 여전히 사람 몫이에요.

AI 코드 리뷰 경쟁 도구와 비교하면 어디쯤일까

가격 구조를 비교한 effloow.com 자료를 보면, 대부분의 경쟁 도구는 사용자당 월정액입니다. CodeRabbit Pro는 연간 결제 기준 사용자당 월 24달러(사용량 기반 애드온 별도), Qodo Teams는 연간 결제 기준 사용자당 월 30달러(사용자당 월 20건 PR 상한), GitHub Copilot Pro는 사용자당 월 10달러지만 2026년 도입된 사용량 기반 과금에서는 리뷰가 크레딧을 소모합니다. 변동 과금인 Anthropic Code Review와는 계산 방식 자체가 다른 셈이죠.

이 자료는 Anthropic Code Review의 강점으로 "이미 Claude Code에 표준화된 조직"과 "복잡한 로직 리뷰에 유리한 멀티 에이전트 구조"를 꼽고, 약점으로는 예측 불가능한 토큰 비용과 아직 전면 공개가 아니라는 점을 지적합니다. PR 건수가 많아 고정 예산이 필요한 팀이나 GitLab·Bitbucket처럼 GitHub가 아닌 플랫폼을 쓰는 팀에는 안 맞는다는 결론이었어요. 참고로 CodeRabbit과 GitHub Copilot Code Review를 직접 비교한 별도 벤치마크(morphllm.com)에서는 CodeRabbit이 F1 스코어 51.5%로 Copilot의 44.5%를 앞섰고, 버그 재현율도 52.5% 대 36.7%로 우세했다고 하는데, 이 벤치마크에는 Claude Code 계열이 포함되지 않았습니다.

자주 묻는 질문

Q. `/ultrareview`랑 `/code-review ultra`는 다른 명령인가요?
아닙니다. /code-review ultra가 현재 공식 이름이고 /ultrareview는 이전 이름을 그대로 쓸 수 있게 남겨둔 별칭입니다.

Q. 무료 3회를 다 쓰면 이제 어떻게 되나요?
usage credit으로 과금되고, 변경 규모에 따라 보통 5~20달러 수준입니다. Team/Enterprise는 애초에 무료 실행이 없습니다.

Q. API 키만 있으면 쓸 수 있나요?
안 됩니다. Claude.ai 계정 로그인이 필수이고, API 키만 로그인된 상태라면 /login으로 다시 인증해야 합니다.

Q. 리뷰 도중에 취소하면 무료 횟수가 아깝지 않나요?
아깝습니다. 원격 세션이 시작되는 순간 1회로 카운트되기 때문에 중단해도 무료 횟수는 이미 소진되고, 그 시점까지의 부분 결과도 받을 수 없습니다.

써보고 나서 든 결론은 하나예요. /code-review ultra는 매 커밋마다 돌리는 습관용 도구가 아니라, "이거 하나는 확실히 짚고 넘어가야 한다" 싶은 순간을 위해 아껴두는 도구입니다. 결제·인증·마이그레이션처럼 무거운 브랜치를 앞두고 있다면 남은 무료 횟수부터 /tasks 근처에서 한번 확인해보세요.

AGENTS.md 완전 가이드: AI 코딩 도구 28개가 함께 읽는 단 하나의 파일

roundfigure — Sun, 5 Jul 2026 06:40:23 +0900

메타 설명: AGENTS.md 표준 가이드 — Cursor, GitHub Copilot, Claude Code 등 28개+ AI 도구가 공통으로 인식하는 설정 파일 작성법, 실제 사용 템플릿, 런타임 28% 단축 성능 수치, 안티패턴까지 한 번에 정리했습니다.

AGENTS.md와 AI 코딩 도구 연결 다이어그램

팀에 AI 코딩 도구가 두 개 이상 섞이면 진짜 문제가 생깁니다. Cursor 쓰는 개발자는 .cursorrules 관리하고, Claude Code 쓰는 개발자는 CLAUDE.md 업데이트하고, GitHub Copilot 쓰는 개발자는 또 copilot-instructions.md 따로 관리해요. 같은 프로젝트를 설명하는 파일이 세 개인 거죠. 어느 게 최신인지도 모르고.

AGENTS.md는 이 문제를 해결하기 위해 만들어진 표준 파일입니다. 지금 60,000개 이상의 오픈소스 프로젝트가 채택했고, 28개 이상의 AI 도구가 공식 지원합니다.

AGENTS.md가 뭔지 30초 요약

리포지토리 루트에 올려두는 마크다운 파일입니다. README.md가 사람 개발자에게 프로젝트를 설명하는 것처럼, AGENTS.md는 AI 에이전트에게 프로젝트 운영 방식을 설명합니다.

특별한 문법 없어요. 그냥 마크다운입니다. 필수 필드도 없고, 프레임워크나 라이브러리 설치도 필요 없습니다. 파일 하나 만들어서 리포에 올리면 끝이에요.

근데 이게 단순해 보이는데 실제 효과가 꽤 됩니다. arXiv에 올라온 연구(2601.20404)에서 10개 리포지토리, 124개 풀 리퀘스트를 분석했더니 AGENTS.md가 있는 프로젝트에서 에이전트 런타임이 28.64% 단축되고 출력 토큰 소비가 16.58% 절감됐어요. 에이전트가 프로젝트 구조 파악하는 데 헤매는 시간이 줄어들기 때문입니다.

AGENTS.md 도입 효과 수치 — 런타임 28.64% 단축, 토큰 16.58% 절감, 버그 35~55% 감소

탄생 배경: 왜 또 다른 파일 표준이 필요했나

2025년 8월, OpenAI와 Google, Cursor, Factory가 협력해서 AGENTS.md 오픈 표준을 공개했습니다. 그 전까지는 도구마다 파일 이름이 달랐어요.

도구	파일 이름
Cursor	`.cursorrules` / `.cursor/rules/*.mdc`
Claude Code	`CLAUDE.md`
GitHub Copilot	`.github/copilot-instructions.md`
Windsurf	`.windsurfrules`

팀에 여러 도구가 섞이면 지침이 분산되고, 업데이트하다 보면 파일마다 내용이 달라집니다. AGENTS.md는 이걸 하나로 통합하자는 취지입니다.

2025년 12월에는 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증됐어요. OpenAI의 AGENTS.md, Anthropic의 MCP, Block의 Goose가 공동 창립 프로젝트로 들어갔습니다. AWS, Google, Microsoft, Anthropic, Cloudflare, Bloomberg 같은 회사들이 플래티넘 멤버로 참여 중이고요.

AGENTS.md 지원 도구 현황 (2026년 중반)

현재 28개 이상의 AI 코딩 도구가 AGENTS.md를 공식 지원합니다. 주요 도구만 추리면:

도구	개발사
OpenAI Codex CLI	OpenAI (표준 제안사)
GitHub Copilot	Microsoft/GitHub
Cursor	Cursor
Windsurf	Codeium
Aider	오픈소스
Gemini CLI	Google
Google Jules	Google
Devin	Cognition
VS Code	Microsoft
Cline	오픈소스
Zed	Zed Industries

솔직히 표준 제안사인 OpenAI Codex CLI가 지원이 가장 완전하고, 나머지 도구들은 기본 읽기는 되는데 고급 기능은 도구마다 차이가 있어요. 그래도 Cursor, GitHub Copilot, Windsurf 수준이면 실무에서 체감하기에 충분합니다.

AGENTS.md를 지원하는 28개+ AI 코딩 도구 목록

AGENTS.md vs CLAUDE.md vs .cursorrules 뭘 써야 하나

이 세 가지를 직접 비교해볼게요.

항목	AGENTS.md	CLAUDE.md	.cursorrules
호환 도구	28개+	Claude Code 전용	Cursor 전용
표준 주체	Linux Foundation	Anthropic	Cursor
글로벌 설정	`~/.codex/AGENTS.md`	`~/.claude/CLAUDE.md`	불가
다단계 상속	지원	지원	`.cursor/rules/*.mdc`로 확장

멀티 도구 팀이라면 전략은 이렇게 잡는 게 좋습니다.

AGENTS.md — 모든 도구에 공통 적용되는 기본 지침 (빌드 명령, 프로젝트 구조, 코드 스타일)
CLAUDE.md — Claude Code 전용 심화 설정 (Hooks, Skills 같은 Claude 특화 기능)
간단하게 가고 싶다면 ln -s AGENTS.md CLAUDE.md 심볼릭 링크로 동기화

저는 현재 AGENTS.md에 프로젝트 공통 내용을 넣고, CLAUDE.md에 Claude 전용 설정을 추가하는 방식으로 쓰고 있어요. CLAUDE.md 상세 활용법은 CLAUDE.md 완벽 가이드에서, Claude Code의 고급 기능은 Claude Code Skills 가이드에서 별도로 다뤘습니다.

파일 위치와 우선순위 규칙

AGENTS.md는 여러 위치에 둘 수 있고, 에이전트가 읽는 순서가 있습니다. Codex 기준으로 탐색 우선순위는 이렇습니다.

~/.codex/AGENTS.override.md (전역 오버라이드)
~/.codex/AGENTS.md (전역 기본 설정)
Git 루트부터 현재 디렉터리까지 각 경로에서 AGENTS.override.md → AGENTS.md 순서로 탐색

파일들은 루트부터 순서대로 연결(concatenate)되고, 더 가까운 파일의 지침이 이전 지침을 덮어씁니다. 모노레포에서 패키지별로 다른 규칙이 필요할 때 활용할 수 있어요.

my-monorepo/
├── AGENTS.md              # 전체 프로젝트 공통 규칙
├── packages/
│   ├── api/
│   │   └── AGENTS.md      # API 서버 전용 추가 규칙
│   └── web/
│       └── AGENTS.md      # 프론트엔드 전용 추가 규칙

파일 크기는 기본 32KB 제한입니다. 근데 사실 그 전에 150줄 제한을 스스로 두는 게 낫습니다. 연구 결과에 따르면 150줄을 넘어도 성능 향상은 없고 추론 비용만 20~23% 증가했거든요.

효과적인 AGENTS.md 작성법

GitHub이 2,500개 이상의 공개 리포지토리를 분석해서 뽑아낸 권장 섹션입니다.

1. Commands — 가장 중요한 섹션

파일 최상단에 위치해야 합니다. AI 에이전트가 가장 먼저, 가장 자주 참조하는 정보예요.

# Commands
- 개발 서버: `npm run dev`
- 빌드: `npm run build`
- 테스트 전체: `npm test`
- 단일 파일 타입 체크: `npm run tsc --noEmit path/to/file.tsx`
- 단일 파일 린트: `npm run eslint --fix path/to/file.tsx`

단순히 npm test가 아니라 단일 파일 테스트 명령도 명시하세요. 에이전트가 전체 테스트 슈트를 돌리는 대신 수정한 파일만 체크하게 됩니다.

2. Project Structure — 추상이 아닌 실제 경로

# Project Structure
- `src/routes/` — 라우팅 설정
- `src/components/` — 재사용 가능한 UI 컴포넌트
- `src/hooks/` — 커스텀 React 훅
- `src/api/` — API 클라이언트

"MVC 패턴을 따른다" 같은 추상적 설명보다 실제 파일 경로가 훨씬 효과적입니다.

3. Code Style — 예제 코드로 보여주기

# Code Style
- 함수형 컴포넌트 + 훅 사용 (`src/components/Projects.tsx` 참고)
- 클래스형 컴포넌트 금지
- 상태 관리: Zustand (Redux 사용 금지)
- 비동기: async/await, Promise.then 금지

"클린 코드를 작성한다"는 에이전트에게 의미 없어요. 실제 예제 파일 경로를 참조하게 해주세요.

4. Boundaries — 명확한 경계 설정

# Boundaries
절대 금지:
- secrets, .env 파일 수정 또는 커밋
- node_modules/ 직접 수정
- 프로덕션 DB 설정 변경

먼저 확인:
- 새 npm 패키지 추가
- 기존 API 스펙 변경
- 데이터베이스 스키마 수정

에이전트가 "알아서" 잘 판단해줄 거라고 기대하면 안 됩니다. 경계를 명시적으로 그어줘야 해요.

실제 사용 템플릿

바로 복사해서 쓸 수 있는 최소 템플릿입니다.

# Project Overview
React 18 + TypeScript + Vite + Tailwind CSS 기반 SPA.
백엔드: Node.js/Express, PostgreSQL.

# Commands
- 개발 서버: `npm run dev`
- 빌드: `npm run build`
- 테스트 전체: `npm test`
- 단일 파일 타입 체크: `npm run tsc --noEmit path/to/file.tsx`
- 단일 파일 린트: `npm run eslint --fix path/to/file.tsx`

# Project Structure
- `src/routes/` — 라우팅 설정
- `src/components/` — 재사용 가능한 UI 컴포넌트
- `src/hooks/` — 커스텀 React 훅
- `src/api/` — API 클라이언트

# Code Style
- 함수형 컴포넌트 + 훅 사용 (`src/components/Projects.tsx` 참고)
- 클래스형 컴포넌트 금지
- 상태 관리: Zustand (Redux 사용 금지)

# Testing
- 단위 테스트: Vitest
- E2E: Playwright (`tests/` 디렉터리)
- 새 기능엔 반드시 테스트 추가

# Boundaries
절대 금지:
- secrets, .env 파일 수정 또는 커밋
- node_modules/ 직접 수정
- 프로덕션 DB 설정 변경

버전 명시는 중요합니다. "React 프로젝트"가 아니라 "React 18 + TypeScript + Vite + Tailwind CSS"처럼 구체적으로 써야 에이전트가 맞는 문법과 API를 사용해요.

AGENTS.md 작성 시 피해야 할 안티패턴

AI 생성 AGENTS.md는 역효과

흥미로운 연구 결과가 있어요. arXiv:2602.11988에 따르면 LLM으로 자동 생성한 AGENTS.md는 8가지 테스트 환경 중 5개에서 태스크 성공률이 오히려 낮아졌습니다. 자동 생성 시 태스크당 2.45~3.92단계가 추가로 소요됐고요.

AI가 만든 AGENTS.md가 왜 역효과냐면, 실제 프로젝트 맥락 없이 일반적인 지침만 생성되기 때문입니다. 에이전트가 읽어봤자 실제 도움이 안 되는 내용이 대부분이에요.

사람이 직접 작성한 구체적인 내용이 훨씬 효과적입니다.

모호한 페르소나 설명

"당신은 도움이 되는 코딩 어시스턴트입니다" — 이런 문장은 AI 에이전트에게 아무 의미 없습니다. 실행 가능한 명령어와 구체적인 경로로 채우세요.

비밀 정보 절대 금지

.env에 있는 API 키, DB 비밀번호 같은 정보를 AGENTS.md에 넣으면 안 됩니다. AGENTS.md는 git에 커밋되는 파일이에요.

커뮤니티 실사용 데이터

AGENTS.md를 도입한 프로젝트들의 보고된 수치들:

에이전트 생성 버그 35~55% 감소
새 AI 코딩 세션 설정 시간: 20~40분 → 2분 미만으로 단축
런타임 28.64% 단축, 출력 토큰 16.58% 절감 (arXiv 연구 기준)

새 세션마다 "이 프로젝트는 Next.js 14 씁니다, App Router 씁니다, 테스트는 Jest 씁니다..." 반복 설명하는 시간이 없어지는 게 체감상 가장 큰 차이입니다.

AGENTS.md와 MCP의 관계

AGENTS.md가 프로젝트 컨텍스트를 제공하는 정적 파일이라면, MCP(Model Context Protocol)는 AI 에이전트에게 동적 도구와 데이터 접근권을 주는 프로토콜입니다. 둘은 보완 관계예요.

AGENTS.md → "이 프로젝트에서 어떻게 일해야 하는지" 규칙 제공
MCP → "어떤 외부 도구와 데이터를 사용할 수 있는지" 도구 제공

둘 다 Agentic AI Foundation에 기증된 프로젝트라는 것도 흥미롭습니다. MCP 활용법이 궁금하다면 MCP Apps 완전 가이드를 참고하세요.

지금 당장 시작하는 법

리포지토리 루트에 AGENTS.md 파일 생성
위 템플릿을 복사해서 프로젝트에 맞게 수정
Commands 섹션부터 채우기 — 가장 중요하고 즉각적인 효과
에이전트가 실수할 때마다 규칙 추가 (최소로 시작, 반복 개선)

처음부터 완벽하게 만들려 하지 마세요. 5분 안에 Commands와 Project Structure만 채운 파일도 없는 것보다 훨씬 낫습니다. 에이전트 쓰다가 "아, 이게 빠졌구나" 싶을 때 한 줄씩 추가하면 됩니다.

Cloudways 호스팅 완벽 가이드 2026 - 요금제부터 실사용 후기까지

roundfigure — Sat, 4 Jul 2026 16:12:19 +0900

워드프레스 사이트가 느려지거나 트래픽이 갑자기 몰릴 때, "서버를 옮겨야 하나" 고민하다가 Cloudways라는 이름을 한 번쯤 보셨을 거예요. 근데 막상 찾아보면 DigitalOcean이나 Vultr 같은 이름도 같이 나오고, 도대체 뭐가 다른 건지 헷갈리기 시작합니다. Cloudways는 서버를 직접 관리하지 않고 DigitalOcean·AWS·Google Cloud·Vultr·Linode 같은 클라우드 인프라 위에 관리 레이어를 얹어주는 서비스인데, 이 글에서는 요금제 구조부터 실측 성능, 실사용자 평판까지 확인 가능한 정보만 정리해봤습니다.

Cloudways 대시보드와 5개 클라우드 제공사 로고(DigitalOcean, AWS, Google Cloud, Vultr, Linode)를 함께 배치한 대표 이미지

Cloudways란 무엇인가 - "관리형" 클라우드 호스팅의 포지션

Cloudways는 자체 데이터센터나 서버를 소유하지 않습니다. 대신 DigitalOcean, AWS, Google Cloud, Vultr, Linode 등 5개 인프라 제공사의 서버를 임대해서 그 위에 서버 프로비저닝, 캐싱, 보안, 백업, 기술 지원까지 얹은 리셀러형 관리형 호스팅입니다. 전 세계 65개 이상의 데이터센터 위치 중에서 서버를 선택할 수 있고요.

이게 순수 VPS(Vultr, DigitalOcean, Hetzner 자체 상품)와 다른 지점입니다. 순수 VPS는 SSH로 직접 접속해서 리눅스 서버를 처음부터 세팅해야 하는데, 저도 예전에 처음 VPS로 워드프레스 올리려다가 방화벽 설정 하나 때문에 반나절을 날린 적이 있어요. Cloudways는 그 과정을 대신 처리해주는 대가로 원가 대비 추가 요금을 받는 구조입니다.

Cloudways 요금제 - Flexible과 Autonomous, 뭐가 다른가

Cloudways는 크게 두 가지 라인업으로 나뉩니다.

Cloudways Flexible은 워드프레스, Magento, Laravel 같은 PHP 앱을 위한 커스터마이징 가능한 관리형 호스팅으로, 클라우드 제공사와 서버 사양을 직접 고를 수 있습니다. DigitalOcean 기준 Micro 플랜(2GB RAM, 1 vCPU)이 월 11달러부터 시작하고, 연간 결제하면 월 8.25달러 수준으로 떨어집니다. Vultr와 Linode는 14달러, AWS는 20.56달러, Google Cloud는 37.33달러부터입니다. 종량제라 실제 사용한 서버 시간만큼만 청구되는 구조예요.

Cloudways Autonomous는 이커머스나 LMS처럼 트래픽 변동이 심한 사이트를 위한 완전 관리형 상품입니다. Google Kubernetes Engine 기반 자동 확장이 내장되어 있고요. Growth 플랜이 월 99달러부터 시작하는데, 다른 소스에서는 기본 티어가 월 35달러(15GB 스토리지, 3만 방문)라고 소개하기도 해서 소스마다 진입가 표기가 좀 다릅니다. 중급은 월 145달러(40GB, 12.5만 방문), 상급은 월 1,640달러(200GB, 150만 방문)까지 올라갑니다.

공통으로는 24/7 지원, 무료 SSL, 무제한 애플리케이션 설치, 자동 백업, 스테이징 환경, Object Cache Pro가 포함되고, Autonomous에는 Cloudflare Enterprise CDN과 Redis 캐싱이 추가로 들어갑니다. 신용카드 없이 3일 무료 체험을 해볼 수 있고, 연간 약정 없이 언제든 스케일 업다운이나 취소가 가능하다는 점도 눈에 띕니다.

Cloudways Flexible과 Autonomous 요금제 비교 표(클라우드 제공사별 시작가, 포함 기능)

가격을 뜯어보면 - VPS를 직접 쓰는 것과 뭐가 다를까

여기서부터가 진짜 궁금한 부분이죠. Cloudways에서 DigitalOcean Premium과 Vultr High Frequency는 모든 서버 사양에서 가격이 동일합니다. 1GB 14달러, 2GB 28달러, 4GB 54달러, 8GB 107달러. 즉 두 인프라의 원가가 Cloudways 가격 정책 안에 그대로 녹아있다는 뜻입니다.

근데 2026년 4월 발행된 리뷰(onlinemediamasters)는 이 가격이 DigitalOcean·Vultr 공식 사이트 가격 대비 약 220% 마크업이라고 지적합니다. 리소스를 개별적으로 확장할 수 없어서 쓰지 않는 리소스에도 비용을 낸다는 점도 단점으로 꼽았고요. 쉽게 말하면 "관리 서비스"에 대한 대가로 원가의 두 배 이상을 지불하는 구조라는 겁니다. 다만 이 계산 기준은 소스마다 다를 수 있어서, 정확한 마크업 배율보다는 "관리 편의성에 얼마를 지불할 의향이 있는가"로 접근하는 게 맞다고 봅니다.

실제 성능은 어떨까 - 로딩 속도와 가동률

managedwpguide가 DigitalOcean 런던 데이터센터 기준으로 실측한 자료를 보면 지역별 편차가 꽤 큽니다. 프랑크푸르트는 로딩 0.32초, TTFB 188ms인데 시드니는 로딩 2.58초, TTFB 942ms까지 벌어집니다. 서버 지역과 방문자 위치가 멀수록 체감 속도가 크게 떨어진다는 뜻이에요.

DigitalOcean Premium과 Vultr High Frequency는 캐시된 페이지를 서빙할 땐 체감 차이가 거의 없지만, 캐시되지 않는 관리자 페이지나 결제 처리처럼 동적 콘텐츠에서는 Vultr HF가 더 빠른 경우가 많다는 부하 테스트 결과가 있습니다. 그래서 블로그처럼 캐시 중심 사이트는 DigitalOcean, WooCommerce처럼 복잡한 쿼리가 많은 사이트는 Vultr HF가 권장되는 편입니다. 데이터센터 수는 DigitalOcean 9개, Vultr 30개 이상으로 Vultr가 지역 커버리지는 더 넓습니다.

조금 오래된 자료지만 tooltester(2022년 10월 업데이트)는 Cloudways 평균 페이지 로딩 시간을 1.46초로 측정해 테스트한 호스트 중 상위권이라고 밝혔고, 99.99% 가동률을 기록했다고 보고했습니다. hostduel의 2026년 6월 데이터도 30일 가동률 99.98~99.99% 수준을 재확인하고 있어서, 안정성 자체는 꾸준히 유지되고 있는 것으로 보입니다.

지역별 Cloudways 로딩 시간·TTFB 비교 막대그래프(프랑크푸르트, 파리, 오하이오, 시드니)

실사용자들은 뭐라고 하나 - 장점과 단점

Capterra 기준 Cloudways 평점은 4.2/5(검증된 리뷰 93건)이고, 사용 편의성 4.2점, 고객 서비스 3.9점입니다. 자주 나오는 장점은 몇 분 안에 끝나는 서버 설정, 계약 기간 없는 종량제, 5개 인프라 중 선택 가능한 유연성, 빠른 24시간 지원이에요. 반대로 자주 지적되는 단점은 구독 취소 후에도 청구가 계속되는 경험, 처음 쓰는 사람에게는 다소 복잡하게 느껴지는 백엔드, 소규모 사이트 기준으로는 부담스러운 가격, 이메일 전송 문제로 비즈니스에 영향을 받았다는 사례입니다.

앞서 언급한 onlinemediamasters 리뷰는 훨씬 비판적입니다. 공유 vCPU 경쟁으로 인한 높은 CPU 사용량, Apache 기반 스택이 OpenLiteSpeed 대비 성능이 떨어진다는 점, 자사 캐싱 플러그인 Breeze의 낮은 평점(3.5/5), 자동 확장 기능의 신뢰성 문제(로드 밸런싱 이슈, 실제 다운타임 사례)까지 구체적으로 짚었어요. 다만 이 리뷰 자체가 상당히 비판적인 톤을 취하고 있어서, Capterra의 우호적인 실사용 평점과는 온도차가 있다는 점은 감안하고 봐야 합니다.

Capterra 리뷰 화면 캡처 형태로 재구성한 Cloudways 평점 요약(사용 편의성 4.2점, 고객 서비스 3.9점, 장단점 항목별 아이콘)

Cloudways에 없는 것들 - 이메일, CDN, 도메인

Cloudways는 순수 애플리케이션 호스팅 서비스라서 이메일 호스팅과 도메인 등록이 기본 제공되지 않습니다. 이메일은 사서함당 월 1달러의 별도 유료 서비스를 이용해야 하고요. tooltester(2022년 자료라 다소 오래됐습니다)에 따르면 CDN도 25GB당 1달러 추가 비용이 붙고, 오프라인 백업은 GB당 0.033달러가 별도 청구된다고 언급했는데, 이건 Autonomous 플랜에 기본 포함된 Cloudflare Enterprise CDN과는 별개의 구정보일 가능성이 있어요. 플랜별로 CDN 포함 여부가 다를 수 있다는 점은 신청 전에 직접 확인해보시는 게 안전합니다. 기본 플랜의 라이브 채팅 지원은 15분으로 제한되고, 프리미엄 지원은 월 100~500달러 추가 비용이 듭니다.

Cloudways vs Hetzner - 관리형이냐 셀프호스팅이냐

비용만 놓고 보면 Hetzner가 압도적입니다. 월 1.90달러부터 시작하는 순수 클라우드 인프라인데, 대신 서버 설정과 운영을 전부 직접 해야 해요. Cloudways는 같은 등급 자원에 관리 서비스를 얹어 훨씬 비싼 가격에 제공하고요. 가동률은 Cloudways 99.99%, Hetzner 99.9% 보증으로 표기되고, 평가 점수는 Cloudways 4.2/5, Hetzner 4.0/5로 비교됩니다(hostduel, 2026년 6월 데이터 기준).

비용을 최우선하고 리눅스 서버 운영에 익숙한 개발자, 유럽 내 데이터 주권이 필요한 경우라면 Hetzner가 맞고, 워드프레스·WooCommerce 운영자나 서버 관리 부담을 피하고 싶은 개발자·에이전시, 초보자라면 Cloudways 쪽이 맞습니다. 저도 개인 프로젝트는 Hetzner로 직접 굴리지만, 클라이언트 사이트처럼 장애 대응을 남에게 맡기고 싶은 경우엔 관리형을 택하는 편이에요. hostduel 자료는 "7개 비교 카테고리 중 5개에서 Cloudways가 우세"하다고 결론짓는데, 이건 관리 편의성이나 지원 품질 같은 비가격 요소에 가중치를 둔 평가라서 순수 가격 대비 성능만 보면 얘기가 달라진다는 점은 알아두시면 좋겠습니다.

가격: Cloudways 월 11달러~ / Hetzner 월 1.90달러~ (Hetzner 우위)
가동률: Cloudways 99.99% / Hetzner 99.9% 보증 (Cloudways 우위)
평점: Cloudways 4.2/5 / Hetzner 4.0/5 (Cloudways 우위)
관리 부담: Cloudways는 전 과정 관리형 / Hetzner는 서버 설정·운영을 직접 처리 (Cloudways 우위)

앞으로는 어떻게 되나 - Cloudways Copilot

2026년 기준 Cloudways는 "Cloudways Copilot"이라는 AI 기반 도구 모음을 출시 준비 중이라는 언급이 있습니다. 호스팅과 사이트 관리를 자동화하는 게 목표라고 하는데, 구체적인 출시일이나 기능 세부사항을 담은 공식 발표는 아직 확인되지 않았어요. "출시 예정" 정도로만 알아두시고, 실제 계약 결정에는 지금 확인 가능한 요금제와 성능 기준으로 판단하시는 걸 추천합니다.

정리 - 누구에게 맞는 선택인가

Cloudways는 서버 관리를 아예 신경 쓰고 싶지 않은 워드프레스·이커머스 운영자, 트래픽 변동이 큰 사이트를 운영하는 에이전시에 적합한 선택입니다. 반대로 리눅스 서버 운영 경험이 있고 비용 최적화가 우선이라면 Vultr나 Hetzner를 직접 쓰는 게 더 유리하고요.

신용카드 없이 3일간 무료로 체험해볼 수 있고, 연간 약정 없이 언제든 스케일 업다운·취소가 가능하다는 점은 일단 부담 없이 판단해보기엔 나쁘지 않은 조건입니다. → Cloudways 요금제 확인하고 무료 체험 시작하기

서버 이전을 고민 중이시라면 지금 쓰는 사이트의 트래픽 패턴과 예산부터 먼저 정리해보시길 권합니다. 관리형이냐 직접 운영이냐는 그 두 가지에 따라 답이 꽤 명확하게 갈립니다.

Claude Sonnet 5 프로모션 가격 8월 31일 종료, 지금 써야 할 이유

roundfigure — Sat, 4 Jul 2026 11:02:58 +0900

Claude Sonnet 5 API를 쓰고 있거나 도입을 고민 중이라면, 8월 31일이라는 날짜를 달력에 꼭 표시해두세요. 프로모션 가격이 끝나는 날입니다. 9월 1일부터는 입력 토큰이 MTok당 $2 → $3, 출력 토큰이 $10 → $15로 오릅니다. 숫자로 보면 50% 인상인데, 사실 그게 끝이 아닙니다. 새 토크나이저 문제까지 더하면 실제 청구 금액은 훨씬 더 커질 수 있어요.

Claude Sonnet 5 프로모션가 vs 정가 비교표

Claude Sonnet 5, 왜 이렇게 주목받나

Anthropic이 Sonnet 5를 발표하면서 내세운 핵심 문구가 "Opus 4.8 수준의 성능을 Sonnet 가격에"였습니다. 2026년 6월 30일 출시 직후 TechRadar는 "에이전트 AI 전쟁에서 가장 중요한 모델"이라고 표현했을 정도니까요.

벤치마크를 보면 왜 그런 말이 나왔는지 이해가 됩니다. 에이전틱 코딩 지표인 SWE-bench Pro에서 Sonnet 4.6 대비 5.1 포인트 오른 63.2%를 기록했고, 터미널·CLI 자동화를 측정하는 Terminal-Bench 2.1에서는 무려 13.4 포인트 상승한 80.4%를 냈습니다. FrontierCode v1(실제 PR 기반 코딩)에서는 15.1%에서 38.8%로 거의 2.6배 뛰었어요. 지식 업무 벤치마크(GDPval-AA v2)에서는 Opus 4.8을 근소하게 앞질렀습니다.

직접 써본 결과, 가장 체감되는 부분은 멀티스텝 작업에서의 완료율입니다. Sonnet 4.6이 중간에 멈추던 리팩터링 작업을 Sonnet 5가 한 번에 처리하는 케이스가 실제 Cursor 사용자들 사이에서 꽤 보고되고 있어요.

Sonnet 4.6 vs Sonnet 5 벤치마크 성능 비교

8월 31일 프로모션 가격 종료 후 비용이 얼마나 오르나

단순 계산으로는 50% 인상입니다. 그런데 진짜 함정은 토크나이저 변경에 있습니다.

Sonnet 5는 Opus 4.7에서 처음 도입된 새 토크나이저를 씁니다. 동일한 텍스트를 집어넣었을 때 Sonnet 4.6보다 더 많은 토큰으로 쪼개집니다. 영어 텍스트 기준으로 약 1.42배, Python 코드는 약 1.27배 더 많은 토큰이 소비됩니다. 한국어나 중국어는 변화가 거의 없는 편이지만, 영어·코드 중심 워크로드라면 이야기가 달라집니다.

계산해봅시다. 프로모션이 끝난 뒤 동일한 영어 코딩 작업을 돌리면, 가격 인상 50% × 토큰 증가 약 30~42%가 겹칩니다. Sonnet 4.6 대비 실질 비용이 20~35% 추가로 오를 수 있다는 의미입니다. The Decoder와 The Register는 이를 두고 "Anthropic이 토크나이저를 이용해 실질적인 가격 인상을 반복하고 있다"고 비판하기도 했습니다.

Claude Sonnet 5 토크나이저 변경 토큰 증가 비교

Claude Sonnet 5 프로모션 가격, 절감 레버는 두 가지

프로모션 가격($2/$10) 기준으로, 1M 컨텍스트 윈도우를 장문 추가 요금 없이 쓸 수 있다는 것 자체가 이미 상당한 메리트입니다. 여기에 두 가지 절감 레버를 더 쓸 수 있어요.

프롬프트 캐싱: 시스템 프롬프트처럼 반복되는 컨텍스트가 1,024 토큰 이상이면 캐싱이 적용되어 최대 90% 비용을 줄일 수 있습니다. 에이전트를 반복 호출하는 워크플로에선 체감 효과가 큽니다.

Batch API: 실시간 응답이 필요 없는 작업이라면 Batch API로 처리하면 입출력 모두 50% 할인됩니다. 데이터 분류, 문서 요약, 대량 코드 분석처럼 비동기로 돌릴 수 있는 작업이라면 지금이 세팅해두기 가장 좋은 시점입니다.

커뮤니티 반응도 꽤 단호합니다. "프로모션 가격 동안은 Opus를 쓸 이유가 없다"는 말이 나올 정도니, 성능과 비용을 동시에 챙길 수 있는 구간이 8월 31일까지라는 건 분명합니다.

어떤 워크로드에 지금 당장 써볼까

Sonnet 5의 가장 큰 도약이 나온 영역은 에이전틱 작업입니다. Claude Code에서 기본 실행 모델로 지정되었고, 버그 재현 테스트 자동 작성부터 수정, 회귀 검증까지 단일 패스로 처리하는 식의 워크로드에서 효과가 두드러집니다.

기업 환경에서는 이미 도입 사례가 나오고 있습니다. Salesforce 워크플로에서 계정 티어 업데이트와 이메일 발송을 종단간 처리하는 CRM 자동화, 보험사 Pace의 청약 접수 및 손실 보고서 처리 에이전트 등이 대표적입니다. 솔직히 말하면 이런 종류의 멀티스텝 자동화는 Sonnet 4.6으로 세팅해두셨다면, 지금 Sonnet 5로 바꾸고 9월 이전에 충분히 실험해두는 게 맞습니다. 정가 전환 이후에도 프롬프트 캐싱과 Batch API를 붙여놓으면 실사용 단가를 상당 부분 낮출 수 있거든요.

지금 해야 할 것

8월 31일까지 약 두 달이 남아 있습니다. 이 기간을 그냥 흘려보내기보다는, 현재 Sonnet 4.6으로 돌리고 있는 워크플로를 Sonnet 5로 마이그레이션하고 프롬프트 캐싱을 붙여 실제 토큰 소비량을 측정해두세요. 9월 1일 이후 정가에서도 얼마나 나오는지 미리 파악해둬야 예산 계획이 가능합니다. 캐싱과 Batch API까지 세팅해두면, 정가 전환 이후에도 지금과 비슷한 수준의 비용을 유지할 수 있는 구조를 만들 수 있습니다.

Claude Cowork 완벽 가이드, 파일 정리부터 보고서까지 맡기는 AI 동료

roundfigure — Sat, 4 Jul 2026 01:32:30 +0900

"이 폴더 좀 누가 대신 정리해줬으면" 하고 생각해본 적, 다들 한 번쯤 있으실 겁니다. 저도 다운로드 폴더가 3천 개 넘는 파일로 뒤엉켜 있는 걸 보고 한숨만 쉬던 사람인데요. Claude Cowork는 이런 반복적인 문서·파일 작업을 통째로 맡기는 걸 목표로 나온 데스크톱 AI 도구입니다. 코딩을 몰라도 쓸 수 있다는 점이 핵심이라 리서처, 애널리스트, 운영·법무·재무 담당자처럼 개발과 무관한 직군에서 특히 주목하고 있어요. 오늘은 Claude Cowork가 정확히 뭘 해주는지, 실제로 써보면 어떤지, 그리고 요금제는 어떻게 되는지까지 정리해봤습니다.

Claude Desktop 앱 상단의 Chat, Cowork, Code 세 탭이 나란히 보이는 화면

Claude Cowork란 무엇인가

Claude Cowork는 Anthropic이 2026년 1월 12일 연구 프리뷰(research preview) 형태로 처음 공개한 데스크톱 AI 에이전트입니다. Anthropic 공식 페이지의 설명을 그대로 옮기면 "목표를 주면 Claude가 사용자의 컴퓨터, 로컬 파일, 애플리케이션에서 작업해 완성된 결과물을 돌려준다"는 게 핵심 콘셉트예요. Claude.ai 제품 페이지 슬로건도 "작업을 맡기면, 다듬어진 결과물을 받는다"로 딱 이 느낌을 담고 있습니다.

재밌는 건 출시 배경입니다. Aragon Research에 따르면 개발자들이 이미 Claude Code를 코딩이 아니라 행정 업무나 휴가 계획, 문서 정리 같은 데 쓰고 있었다고 해요. 그러니까 "어차피 다들 이렇게 쓰고 있으니 아예 비개발자 전용 버전을 만들자"는 흐름이었던 셈이죠. Microsoft Copilot 같은 경쟁 제품 견제도 배경 중 하나로 언급됩니다.

Cowork 출시 타임라인으로 보는 성장 과정

Cowork는 반년 만에 꽤 빠르게 몸집을 키웠습니다.

2026년 1월 12일: 연구 프리뷰로 최초 공개. 특정 폴더·파일·앱을 지정하면 결과물을 만들어주는 방식으로 소개됐어요.
2026년 2월: 엔터프라이즈 대상으로 확대. Google Drive, Gmail, DocuSign, FactSet 같은 업무 툴과 연결되는 커넥터가 추가되고, 금융·엔지니어링·HR 등 도메인별 커스텀 플러그인을 조직 단위로 배포할 수 있게 됐습니다.
2026년 4월 9일: 정식 출시(GA) 전환. 같은 날 Claude Managed Agents 공개 베타, Claude Code 업데이트도 함께 발표됐어요. RBAC, 사용자 그룹별 지출 한도, 사용 분석 대시보드, OpenTelemetry 연동, Zoom MCP 커넥터, 도구별 커넥터 접근 제어까지 6가지 엔터프라이즈 기능이 한 번에 추가됐습니다.
2026년 6월 5일~7월 5일: Pro·Max·Team 플랜과 좌석 기반 Enterprise 사용자 대상으로 5시간 사용 한도가 10시간으로 한시적으로 2배 확대되는 프로모션이 진행 중이에요. 무료 플랜과 소비량 기반 Enterprise는 제외되고, 일일 한도만 늘어나고 주간 한도는 그대로입니다.

Cowork 핵심 기능, 뭘 얼마나 대신 해주나

Claude Cowork는 Claude Desktop 앱 상단의 Chat, Cowork, Code 세 탭 중 하나로 제공됩니다. 사용법은 단순해요. 폴더나 커넥터에 접근 권한을 부여하면 Claude가 곧바로 작업을 시작하지 않고, 먼저 실행 계획을 보여주고 승인을 기다립니다. 승인하고 나면 Word, Excel, PowerPoint, Outlook, Chrome 같은 로컬 앱과 커넥터를 오가며 여러 단계를 알아서 처리해서 서식이 갖춰진 스프레드시트나 보고서를 돌려주는 방식이에요.

대표적인 활용 사례는 이렇습니다.

파일 자동 정렬, 이름 변경, 중복 파일 제거
영수증 스크린샷 같은 비정형 자료를 Excel 스프레드시트로 변환
흩어진 메모와 원본 자료를 바탕으로 형식을 갖춘 보고서 작성
여러 자료를 종합하는 복잡한 리서치 작업, 회의록·스크린샷 분석
예약(스케줄) 작업 설정 — 이메일 확인, 지표 수집, Slack 다이제스트 같은 반복 업무를 한 번 지시해두면 정해진 주기로 자동 실행
여러 작업 병렬 실행

지원 플랫폼은 macOS와 Windows뿐이고 Linux는 지원하지 않습니다. 모바일 지원도 제한적이라고 해요. 알려진 제약도 있는데, 통계·인용 오류 같은 환각(hallucination) 확률이 약 1% 정도로 언급되고, Salesforce 같은 CRM이나 Shopify 같은 전자상거래·POS 시스템은 아직 지원하지 않습니다. 커뮤니티 플러그인도 200개 미만이라 아직 생태계가 크다고 보긴 어려워요.

폴더 접근 권한을 승인하면 Claude Cowork가 실행 계획을 보여주는 화면 예시

Cowork 실제 사용 흐름은 어떻게 되나

Claude.ai 공식 페이지는 사용법을 세 단계로 설명합니다.

지시(Instruct): 데스크톱이나 휴대폰에서 원하는 작업을 설명한다.
실행(Execute): Claude가 브라우저, 로컬 앱, 연결된 커넥터를 활용해 단계별로 작업을 진행한다.
결과(Result): 서식이 갖춰진 스프레드시트, 메모, 보고서 등 완성된 결과물을 받는다.

TECHSY 가이드는 이 과정을 조금 더 구체적으로 풀어서 "폴더 접근 권한 부여 → 파일 접근 가능 상태 → 예약 작업 설정 → 백그라운드 실행" 순서로 설명해요. 전역 지시사항과 폴더별 지시사항을 CLAUDE.md 형식으로 따로 지정할 수 있다는 점도 눈에 띕니다. 개발자라면 익숙한 방식이라 반갑게 느껴질 부분이에요.

Claude Code, Claude.ai Chat과는 뭐가 다른가

이름이 비슷해서 헷갈리기 쉬운데, Anthropic 공식 설명을 보면 정리가 됩니다. Claude Cowork는 "Claude Code와 같은 능력을, 비개발자의 지식 노동이 이뤄지는 곳에 맞게 단순화한 경험"이라고 해요. 그러니까 Claude Code의 자동화 능력을 커맨드라인 없이 쓸 수 있게 만든 버전이라고 보면 됩니다. Claude Code는 여전히 프로그래밍·개발 작업에, Cowork는 파일 정리나 보고서 작성 같은 비코딩 업무에 특화되어 있고요. 둘 다 같은 Claude Desktop 앱 안에서 별도 탭으로 공존합니다.

Claude.ai 일반 Chat과 비교하면 차이가 더 뚜렷합니다. Chat은 한 번에 한 프롬프트씩 응답하는 대화형인 반면, Cowork는 목표 하나를 던지면 여러 단계를 사용자 조율 없이 알아서 처리해서 완성된 결과물을 돌려줘요. 근데 그만큼 사용자가 중간에 관여할 여지는 줄어드니, 처음 쓸 때는 승인 단계에서 실행 계획을 꼼꼼히 확인하는 게 좋습니다.

Cowork 요금제는 얼마나 있어야 쓸 수 있나

여기가 좀 애매한 지점인데, 소스마다 설명이 갈립니다. Anthropic 공식 제품 페이지는 Cowork가 "모든 유료 플랜"에서 사용 가능하다고만 밝히고 구체적인 가격은 별도 pricing 페이지로 안내할 뿐 명시하지 않아요.

TECHSY 가이드 쪽 설명은 Cowork가 모든 유료 플랜에 무료로 포함된다는 쪽입니다. Claude Pro(월 20달러)만으로도 전체 기능을 쓸 수 있고, Team(사용자당 월 25달러, 최소 5인)은 공유 워크스페이스가 추가되며, Enterprise는 맞춤형 가격에 EU 데이터 거주·감사 로그·HIPAA BAA까지 포함된다고 소개합니다. 반면 Aragon Research는 결이 다른 설명을 내놓는데, Claude Cowork는 Max 구독자 대상으로만 제공되고 월 100~200달러 수준이라고 밝히고 있어요.

두 소스 모두 발행일이 명확하지 않거나 Anthropic 공식 가격표를 직접 인용하지 않아서, 어느 쪽이 더 최신·정확한 정보인지는 이 글만으로 단정하기 어렵습니다. 실제로 구독을 결정하기 전에는 Anthropic 공식 pricing 페이지에서 최신 가격을 한 번 더 확인하시는 걸 추천드려요. 다만 6월 5일부터 7월 5일까지는 Pro·Max·Team과 좌석 기반 Enterprise 사용자 대상으로 사용 한도가 5시간에서 10시간으로 늘어나는 프로모션이 진행 중이니, 지금 써볼 계획이라면 이 기간을 활용해보는 것도 방법입니다.

Pro, Team, Enterprise 플랜별 Claude Cowork 포함 여부와 가격을 비교한 표

직접 써본 소감

저는 며칠 동안 정리 안 된 리서치 폴더를 Cowork에 맡겨봤는데요. 승인 단계에서 계획을 미리 보여주는 방식이 생각보다 안심되더라고요. 무작정 실행부터 하는 게 아니라서 "어, 이건 좀 아닌데" 싶으면 그 자리에서 멈출 수 있으니까요. 다만 예약 작업까지 활용해보려면 익숙해지는 데 시간이 좀 걸렸습니다. 처음엔 지시를 너무 뭉뚱그려서 줬더니 원하는 결과물이 안 나와서, CLAUDE.md 형식으로 지시사항을 구체적으로 나눠서 적어주니 그제서야 결과물이 쓸만해졌어요.

솔직히 말하면 아직 CRM이나 전자상거래 시스템 연동이 안 되는 건 제약으로 느껴집니다. 사무 문서·파일 정리 위주 작업에는 확실히 강한데, 영업이나 커머스 쪽 업무까지 기대하고 있다면 지금은 시기상조일 수 있어요.

자주 묻는 질문

Q. Claude Cowork는 Claude Code를 대체하는 건가요?
아닙니다. Anthropic 스스로도 Cowork를 Claude Code와 상호보완적인 관계로 설명합니다. 코딩 작업은 여전히 Claude Code, 비코딩 문서·파일 작업은 Cowork로 나눠 쓰는 구조예요.

Q. Windows에서도 쓸 수 있나요?
네, macOS와 Windows를 지원합니다. 다만 Linux는 지원하지 않고, 모바일 지원도 제한적이라는 점은 참고해두시면 좋습니다.

Q. 무료로 써볼 방법이 있나요?
2026년 6월 5일부터 7월 5일까지는 Pro·Max·Team, 좌석 기반 Enterprise 사용자를 대상으로 사용 한도가 2배로 늘어나는 프로모션이 진행 중입니다. 무료 플랜 자체에는 포함되지 않으니 이 부분은 헷갈리지 않으셨으면 합니다.

Claude Cowork, 아직 완벽하진 않지만 반복적인 파일 작업에 지친 분이라면 한 번쯤 시도해볼 만합니다. 프로모션 기간이 끝나기 전에 다운로드 폴더나 흩어진 자료부터 한 번 맡겨보시는 것도 방법이에요.

RunCell로 주피터 노트북 자동화하기, 데이터 사이언티스트용 AI 에이전트

roundfigure — Fri, 3 Jul 2026 23:11:58 +0900

노트북 셀 하나하나 손으로 돌려가며 EDA 하다가 "이거 누가 대신 좀 해줬으면" 싶었던 적, 다들 한 번쯤 있으실 겁니다. RunCell은 그 지점을 파고든 도구입니다. JupyterLab 안에서 직접 동작하면서 커널의 변수와 DataFrame, 실행 이력, 차트 출력까지 읽고 코드를 짜고 실행하고 오류까지 고쳐주는 "Jupyter 네이티브 AI 에이전트"거든요. 설치 방법부터 핵심 기능, 기존 도구와의 차이까지 정리해봤습니다.

RunCell이 JupyterLab에서 동작하는 방식 — 커널 상태 인식, 계획 수립, 코드 실행, 결과 확인·수정 4단계

RunCell이란 무엇인가

RunCell은 스스로를 "다주간(multi-week) ML·데이터 프로젝트를 실행하는 Jupyter 네이티브 AI 파트너"라고 소개합니다. JupyterLab용 경량 확장 프로그램 겸 Python 패키지로 배포되고, 목표만 설명하면 계획 수립부터 코드 작성, 셀 실행, 에러 수정까지 스스로 해냅니다.

RunCell 설치 방법과 지원 환경

설치는 크게 어렵지 않습니다.

pip install runcell — pip·conda 환경 모두 이 명령 하나면 됩니다
uv를 쓴다면 uv pip install runcell
휠(wheel) 파일을 받아 수동으로 설치하는 방법도 있습니다

시스템 요구사항은 Python 3.10 이상, JupyterLab 4.4.0 이상입니다. 근데 공식 문서는 JupyterLab 버전만 명시하는데 Kanaries 소개 글은 "Classic Notebook, VS Code에도 통합된다"고 해서 얘기가 조금 다릅니다. 저라면 JupyterLab 4.4.0 이상을 기준으로 잡고 설치 전 공식 문서를 한 번 더 확인해보시길 추천드립니다.

RunCell 핵심 기능 4가지

RunCell이 공식적으로 내세우는 기능은 네 가지입니다.

Autonomous Agent(자율 에이전트) — 목표만 던지면 계획 수립부터 코드 작성, 셀 실행, 오류 수정까지 알아서 처리합니다.
In-Context Assist(상황 인식 지원) — 셀을 선택해 질문하면 주변 코드와 결과를 분석해 수정안을 원클릭으로 적용합니다.
Learn by Doing(체험 학습) — 낯선 알고리즘을 문서 대신 실행 예제로 보여줍니다. K-means와 DBSCAN을 실제 데이터로 비교하는 식이죠.
Domain Expertise(도메인 전문성) — 도메인 용어로 분석을 설명하면 circos plot 같은 연구 수준 시각화 코드까지 생성해줍니다.

RunCell 핵심 기능 4가지 — Autonomous Agent, In-Context Assist, Learn by Doing, Domain Expertise

RunCell, Copilot·Cursor와 뭐가 다른가

GitHub Copilot이나 Cursor를 쓰고 계신 분이라면 "이것도 자동완성 아니야?" 싶으실 텐데, 접근 방식이 다릅니다. Copilot은 자동완성, Cursor는 파일 편집에 강한 반면 RunCell은 커널 상태, 즉 변수 값과 DataFrame, 차트 출력까지 직접 읽고 판단합니다. 세션 간 프로젝트 메모리도 특징인데, 며칠 뒤 돌아와서 "지금까지 뭐 했지?"라고 물으면 이전 상황을 기억해서 이어갑니다.

RunCell vs GitHub Copilot vs Cursor 비교표 — 커널 상태 인식, 세션 간 메모리, 강점 영역

Kanaries 비교 아티클은 데이터 확인·셀 실행 작업은 RunCell, 다중 파일 리팩토링은 Cursor, IDE 지원과 비용은 Copilot이 낫다고 정리합니다. skywork.ai 리뷰도 보일러플레이트 자동화와 오류 자동 수정을 강점으로 꼽으면서, 클라우드 LLM 의존에 따른 개인정보 우려는 단점으로 짚습니다. 사실 저도 장점만 나열한 글은 의심부터 하는 편인데, 이 정도면 참고할 만했습니다.

RunCell 요금제와 개인정보 처리는 어떻게 되나

RunCell은 Free, Pro, Ultra, Team 네 단계 요금제를 운영하고, 토큰 기반 크레딧 시스템으로 과금됩니다. 유료 플랜은 "Privacy Mode"가 켜져서 프롬프트와 결과가 모델 학습에 쓰이지 않습니다. 다만 구체적인 달러 가격은 이번 조사로 확인하지 못했으니, 공식 pricing 페이지에서 직접 확인해보세요!

FAQ

Q. RunCell은 무료로 쓸 수 있나요?
A. 네, Free 플랜이 있습니다. 다만 사용량이 늘면 유료 플랜으로 넘어가야 할 수 있어요.

Q. VS Code에서도 RunCell을 쓸 수 있나요?
A. 공식 문서는 JupyterLab만 요구사항으로 명시하니, VS Code에서 쓰실 분은 설치 전 확인해보세요.

주피터 반복 작업에 시간을 많이 쓰신다면 pip install runcell 한 줄로 시작해볼 만합니다. 요금제와 실사용 후기는 다음 글에서 다뤄보겠습니다.

Aider 완벽 가이드: 터미널에서 Git 커밋까지 자동으로 처리하는 AI 페어 프로그래머

roundfigure — Fri, 3 Jul 2026 15:15:05 +0900

터미널에서 AI한테 코드를 시키고 싶은데, 매번 diff 확인하고 커밋 메시지 쓰는 게 귀찮으셨나요? Aider는 이 부분을 통째로 자동화한 오픈소스 도구입니다. 파일을 수정할 때마다 알아서 Git 커밋까지 남기는 게 핵심인데, 저도 처음 써봤을 때 "이걸 이렇게까지 자동으로 해준다고?" 싶었습니다. 설치 방법부터 자동 커밋·리포지토리 맵 같은 핵심 기능, 그리고 Cursor·Claude Code와 실제로 뭐가 다른지까지 하나씩 풀어보겠습니다.

터미널 화면에서 Aider가 코드를 수정하고 자동으로 Git 커밋 메시지를 생성하는 모습

Aider란 무엇인가

Aider는 터미널에서 실행되는 오픈소스 AI 페어 프로그래밍 도구입니다. 공식 소개 문구가 "AI pair programming in your terminal"인데, 딱 그대로입니다. Python, JavaScript, Rust, Ruby, Go, C++, PHP, HTML, CSS 등 수십 개 언어를 지원해서 새 프로젝트를 시작할 때나 이미 커져버린 기존 코드베이스를 건드릴 때나 둘 다 쓸 수 있습니다. 개발자는 Paul Gauthier이고, GitHub 저장소는 원래 paul-gauthier/aider였다가 지금은 Aider-AI/aider 조직으로 옮겨졌습니다.

Aider 설치 방법과 Python 버전, 뭐가 맞을까

설치는 어렵지 않습니다. pip install aider-chat 한 줄이면 끝나고, 공식 권장 명령은 python -m pip install -U --upgrade-strategy only-if-needed aider-chat입니다. 격리 환경을 원하면 pipx install aider-chat, uv를 쓴다면 uv tool install --force --python python3.12 --with pip aider-chat@latest, macOS라면 brew install aider로도 설치됩니다.

여기서 헷갈리는 부분이 하나 있는데요. Python 최소 버전입니다. 공식 문서는 Python 3.9~3.12를 지원한다고 명시하지만, NxCode나 DeployHQ 같은 일부 서드파티 튜토리얼은 Python 3.10 이상을 요구한다고 안내합니다. 공식 기준으로는 3.9부터 되는 게 맞지만, 실제 환경에 따라 의존성 충돌이 날 수 있으니 3.10 이상으로 맞춰두는 편이 마음 편합니다.

Aider 핵심 기능 1 — 자동 Git 커밋

Aider를 쓰는 가장 큰 이유가 바로 이겁니다. 파일을 수정할 때마다 설명이 담긴 커밋 메시지와 함께 자동으로 커밋해줍니다. 커밋 메시지는 별도의 weak model이 diff와 채팅 기록을 보고 생성하며, 기본적으로 Conventional Commits 형식을 따릅니다.

근데 더 마음에 드는 부분은 dirty file 처리 방식입니다. 아직 커밋 안 한 변경사항이 있는 상태에서 Aider가 그 파일을 편집하려 하면, 기존 변경사항부터 먼저 별도 커밋으로 분리하고 그다음에 AI의 편집을 또 다른 커밋으로 남깁니다. 내 작업과 AI 작업이 섞이지 않는다는 뜻이죠. 저는 이 기능 덕분에 리팩터링 도중 실수로 제 변경사항과 AI 변경사항이 뒤섞인 커밋을 만든 적이 없습니다. --no-auto-commits로 자동 커밋을 끄거나 --no-dirty-commits로 dirty file 사전 커밋만 끌 수도 있고, 기본값이 --no-verify라 pre-commit 훅은 건너뛴다는 점도 알아두면 좋습니다.

Aider의 dirty file 처리 흐름 — 기존 변경 커밋 분리 후 AI 편집 커밋 생성 다이어그램

Aider 핵심 기능 2 — 리포지토리 맵으로 대형 코드베이스 이해하기

사실 파일 수백 개짜리 프로젝트를 통째로 LLM에 던질 수는 없잖아요. Aider는 tree-sitter로 코드베이스 전체를 분석해서 파일별 핵심 클래스·함수 시그니처만 뽑아낸 "리포지토리 맵"을 만듭니다. 그리고 그래프 랭킹 알고리즘으로 각 소스 파일을 노드, 의존 관계를 엣지로 놓고 지금 요청과 가장 관련 있는 부분만 골라 LLM에 전달합니다. 덕분에 컨텍스트 창 한계에 걸리지 않으면서도 전체 코드 구조를 어느 정도 파악한 상태로 답변을 만들어냅니다.

채팅 모드와 편집 포맷

Aider는 기본적으로 code 모드로 시작하지만, 상황에 따라 모드를 바꿔가며 쓸 수 있습니다.

code(기본): 파일을 직접 수정
architect: 아키텍트 모델이 방안을 제안하고 별도 에디터 모델이 실제 파일 편집으로 옮기는 2단계 방식
ask: 파일 수정 없이 코드베이스에 대해 질문만
help: Aider 자체 사용법에 대한 답변

/code, /architect, /ask처럼 메시지별로 모드를 지정할 수도 있고 /chat-mode로 아예 고정할 수도 있습니다. architect/editor 2모델 방식은 실제로 효과가 검증된 편인데, 공식 블로그에 따르면 o1-preview를 아키텍트로, DeepSeek이나 o1-mini를 에디터로 조합했을 때 Aider 코드 편집 벤치마크에서 당시 최고점인 85%를 기록했습니다.

지원 모델과 최신 버전

Aider는 LiteLLM을 통해 사실상 모든 LLM에 연결됩니다. Claude, GPT-4o, Gemini, DeepSeek은 물론 Ollama로 로컬 모델까지 붙일 수 있는 게 특정 모델에 종속된 도구들과 가장 다른 지점입니다. 2026년 7월 기준 최신 정식 릴리스는 v0.86.1이고, GPT-5 계열에 대한 reasoning_effort 설정이 추가됐습니다. 개발 브랜치에는 Claude 4.5/4.6 지원과 Gemini 2.5 Flash 계열, /ok 명령(제안 변경사항 빠른 승인) 같은 기능이 먼저 들어가 있습니다.

Aider vs Cursor vs Claude Code, 뭐가 다를까

셋 다 AI 코딩 도구지만 형태부터 다릅니다. Aider와 Claude Code는 둘 다 터미널에서 동작하며 코드베이스를 읽어 다중 파일 편집을 만들어냅니다. 반면 Cursor는 VS Code 포크라서 탭 자동완성, Cmd-K 인라인 편집, Composer/Agent 모드까지 IDE 안에서 다 처리하는 방식입니다.

모델 선택 면에서는 Aider가 확실히 유연합니다. 어떤 모델과도 붙일 수 있는 반면 Claude Code는 하나의 모델 계열에 깊게 통합된 고정형 에이전트고, Cursor는 Claude·GPT·Gemini·자체 Composer-1 모델을 중개하는 방식입니다. Git 워크플로도 갈리는데, Aider는 모든 변경을 자동 커밋하는 반면 Cursor는 수락 전에 시각적 diff로 검토할 수 있게 해줍니다.

Aider, Cursor, Claude Code 세 도구의 실행 환경·모델 유연성·Git 워크플로 비교 표

비용과 성능 수치는 좀 조심스럽게 봐야 합니다. 헤비유즈 기준 Aider 월 $60, Claude Code 월 $200이라는 비교나 Claude Code가 Aider 대비 토큰을 4.2배 더 쓰는 대신 정확도가 7~10퍼센트포인트 높다는 벤치마크가 있긴 한데, 이건 Aider나 Anthropic의 공식 발표가 아니라 Requesty·Morph 같은 서드파티 비교 매체가 자체적으로 낸 수치입니다. 가격 정책과 모델 버전이 계속 바뀌는 걸 감안하면 참고용으로만 보고, 절대적인 사실로 단정하지는 않는 게 안전합니다. 실무에서는 일상적인 코딩엔 자동완성이 강한 Cursor를, 어려운 다중 파일 리팩터링이나 마이그레이션엔 Aider·Claude Code 같은 터미널 도구를 병행하는 하이브리드 워크플로도 흔하게 쓰입니다.

FAQ

Q. Aider는 무료인가요?
Aider 자체는 오픈소스라 무료입니다. 다만 연결하는 LLM(Claude, GPT 등) API 사용료는 별도로 발생합니다.

Q. 기존 Git 프로젝트가 아니어도 쓸 수 있나요?
Git 저장소가 아닌 폴더에서도 실행은 되지만, 자동 커밋이나 dirty file 분리 같은 핵심 기능을 온전히 쓰려면 Git 저장소로 초기화된 상태가 좋습니다.

Q. Cursor 쓰다가 Aider로 넘어가도 괜찮을까요?
둘은 대체재라기보다 용도가 다릅니다. 평소 자동완성과 시각적 diff가 편하면 Cursor를 유지하면서, 큰 리팩터링이나 CI 연동이 필요한 작업에만 Aider를 따로 써보는 방식을 추천합니다.

터미널 작업이 익숙하고 Git 히스토리를 깔끔하게 관리하고 싶다면 Aider 쪽이 꽤 잘 맞습니다. 직접 설치해서 작은 리팩터링 작업 하나에 붙여보고, 자동 커밋된 로그를 git log로 한번 확인해보세요. 어떤 도구인지 감이 훨씬 빨리 옵니다.

Claude Code 멀티 에이전트 오케스트레이션 — 병렬 에이전트로 복잡한 작업을 10배 빠르게

roundfigure — Fri, 3 Jul 2026 08:33:08 +0900

혼자 처리하기 너무 큰 작업이 있을 때 어떻게 하시나요? Claude Code 멀티 에이전트 오케스트레이션이 바로 그 문제의 답입니다. 오케스트레이터 하나가 일을 쪼개서 여러 에이전트에게 위임하고, 결과를 취합하는 구조 — 이게 제대로 세팅되면 독립적인 작업의 벽시계 시간을 60~80%나 줄일 수 있어요. 근데 막상 "병렬로 돌려봐야지" 하고 프롬프트를 짜면 의외로 순차적으로 돌아가는 경험, 저도 처음엔 몇 번이나 했습니다. 이 글에서는 Claude Code v2.1.154부터 공식 지원하는 4가지 멀티 에이전트 메커니즘을 실전 관점에서 정리합니다.

Claude Code 멀티 에이전트 오케스트레이션 아키텍처 다이어그램

Claude Code 멀티 에이전트란 — 4가지 메커니즘 한눈에

Claude Code는 현재 4개의 공식 멀티 에이전트 메커니즘을 지원합니다.

방식	조율자	에이전트 간 통신	규모
서브에이전트	메인 세션 Claude	없음 (결과만 반환)	소규모 위임
Agent View	사용자 (대시보드)	없음	독립 멀티태스크
에이전트 팀	리드 에이전트	직접 메시지 가능	중규모 협업
다이나믹 워크플로우	JavaScript 스크립트	없음 (결과 수집)	수십~수백 에이전트

핵심 패턴은 오케스트레이터-워커 구조입니다. 오케스트레이터가 복잡한 작업을 분해하고, 독립적인 워커 에이전트들이 각자 맡은 파트를 처리한 뒤, 결과가 다시 오케스트레이터로 취합됩니다. 언제 어떤 메커니즘을 써야 하는지가 관건이에요. 하나씩 뜯어볼게요.

AI 에이전트 오케스트레이션의 핵심 — 서브에이전트 병렬 실행

서브에이전트는 가장 기본적인 멀티 에이전트 패턴입니다. 각 서브에이전트는 독립적인 컨텍스트 창, 커스텀 시스템 프롬프트, 지정된 툴 접근권한을 가집니다. 작업이 끝나면 결과 요약만 메인 컨텍스트로 돌아와요. 메인 세션이 오염되지 않는 게 포인트입니다.

Claude Code 병렬 실행을 위한 핵심 규칙이 하나 있습니다. 프롬프트에 "parallel" 혹은 "separate subagents를 사용해서 병렬로"라는 말을 명시적으로 써야 합니다. 이걸 빠뜨리면 Claude가 순차적으로 돌릴 수 있어요. 솔직히 이걸 몰라서 병렬 실행이 안 된다고 헤매는 경우가 꽤 많습니다.

# 잘못된 예 (순차 실행될 수 있음)
"src/routes/ 아래 모든 엔드포인트를 보안 감사해줘"

# 올바른 예 (병렬 실행 보장)
"src/routes/ 아래 각 엔드포인트 파일을 별도의 서브에이전트로 병렬 감사해줘.
각 에이전트는 독립적으로 인증 누락 여부를 확인하고 결과를 반환할 것"

서브에이전트의 또 다른 강점은 비용 라우팅입니다. 단순 반복 작업은 저렴한 모델(Haiku)에 맡기고, 오케스트레이터만 Opus를 쓰는 구조로 토큰 비용을 5~10배 줄일 수 있어요. Haiku는 Opus 대비 토큰당 약 25배 저렴하거든요.

/batch 커맨드도 알아두면 좋아요. 서브에이전트 + Git worktree를 결합한 빌트인 스킬로, 하나의 큰 변경을 5~30개의 worktree 격리 서브에이전트로 분할해서 각자 PR을 생성합니다.

서브에이전트 병렬 실행 흐름

서브에이전트 커스터마이징을 더 깊이 파고 싶다면 Claude Code 서브에이전트 커스텀 만들기를 참고하세요.

에이전트끼리 대화하는 구조 — Claude Code 에이전트 팀

에이전트 팀은 2026년 2월 Opus 4.6과 함께 출시된 실험적 기능입니다. 서브에이전트와 가장 큰 차이는 에이전트끼리 직접 메시지를 주고받을 수 있다는 점이에요. 공유 태스크 리스트로 자체 조율도 합니다.

활성화 방법:

// settings.json
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

아키텍처 구성:

Team Lead: 메인 Claude Code 세션, 작업 분배
Teammates: 독립 컨텍스트 창을 가진 별도 Claude Code 인스턴스
Task List: 모든 에이전트가 공유, 파일 락으로 레이스 컨디션 방지
Mailbox: 에이전트 간 직접 메시지 시스템

스토리지 위치: ~/.claude/teams/{team-name}/config.json, 태스크: ~/.claude/tasks/{team-name}/

서브에이전트 vs 에이전트 팀을 언제 써야 할지 헷갈리는 분들이 많은데, 이 표로 정리됩니다.

항목	서브에이전트	에이전트 팀
컨텍스트	격리, 결과만 반환	격리, 완전 독립
통신	메인 에이전트에만	팀원 간 직접 가능
조율	메인이 관리	공유 태스크 리스트로 자체 조율
토큰 비용	낮음	높음 (팀원 = 별도 Claude 인스턴스)

에이전트 팀이 빛나는 시나리오들:

# PR 리뷰 — 세 가지 관점을 동시에
"PR #142를 세 명의 팀원이 동시에 리뷰해줘:
- 한 명은 보안 취약점 집중
- 한 명은 성능 영향 검토
- 한 명은 테스트 커버리지 검증"

# 경쟁 가설 디버깅 — 과학자처럼 논쟁
"앱이 메시지 하나 보내고 나면 종료된다는 버그 리포트가 들어왔어.
5명의 에이전트 팀원을 소환해서 각각 다른 가설을 조사하고,
서로 과학자처럼 논쟁하게 해줘"

근데 주의할 게 있어요. 팀원이 많다고 좋은 게 아닙니다. 공식 문서 권장 사항은:

시작: 3~5명 (병렬 이점 vs 조율 오버헤드 균형)
팀원당 5~6개 태스크
5명 이상부터 조율 오버헤드가 산출물 이익보다 빠르게 증가
역할이 명확한 에이전트 3명 > 역할이 모호한 에이전트 5명

에이전트 팀 핵심 구성 요소

수백 개 에이전트를 코드로 조율 — 다이나믹 워크플로우

다이나믹 워크플로우는 2026년 도입된 가장 강력한 메커니즘입니다. Claude가 JavaScript 오케스트레이션 스크립트를 직접 작성하고, 런타임이 이를 백그라운드에서 실행합니다.

핵심 차이: 오케스트레이션 계획이 Claude의 컨텍스트 창이 아닌 코드 안에 담깁니다. 중간 결과는 스크립트 변수에 저장되고요. 컨텍스트 한계에 걸릴 대규모 작업에서 진가를 발휘합니다.

트리거 방법:

ultracode: src/routes/ 아래 모든 API 엔드포인트에서 인증 누락 여부를 감사해줘

# 또는
"src/components/ 아래 모든 컴포넌트를 styled-components에서 Tailwind로 마이그레이션해줘.
각 파일은 격리된 상태에서 작업할 것"

모니터링: /workflows 커맨드

빌트인 워크플로우로는 /deep-research가 있습니다. 여러 각도에서 동시에 웹 검색을 팬아웃하고, 소스를 교차 검증하며 미검증 주장을 필터링합니다.

제한 사항:

최대 동시 16개 에이전트
런타임당 최대 1,000개 에이전트
중간에 사용자 입력 불가
Claude Code v2.1.154+, 유료 플랜(Pro/Max/Team/Enterprise) 필요

비용 최적화와 언제 무엇을 쓸까

멀티 에이전트 = 빠르지만 비싸다는 공식이 무조건 맞지는 않아요. 잘 설계하면 비용도 줄일 수 있습니다.

오케스트레이터-워커 비용 최적화 패턴:

Claude Opus(오케스트레이터) + Claude Haiku(서브에이전트) 조합
Haiku는 Opus 대비 토큰당 약 25배 저렴
잘 설계된 워크플로우에서 토큰 사용량의 80~90%가 저렴한 모델로 이동

지표	병렬 실행	순차 실행
벽시계 시간	60~80% 단축	기준
토큰 비용	동일 (에이전트 수에 비례)	더 낮을 수 있음
컨텍스트 오버헤드	3~4배(팀), 최대 15배	1배
조율 복잡도	높음	낮음
최적 케이스	독립적 작업	순차 의존 작업

멀티 에이전트가 오히려 손해인 경우:

단일 에이전트가 한 번에 처리할 수 있는 단순한 작업
각 단계가 이전 단계 결과에 의존하는 순차 작업
같은 파일을 여러 에이전트가 수정해야 하는 강하게 결합된 작업
조율 오버헤드가 병렬화 이득보다 큰 소규모 작업

사실 "무조건 병렬로 돌리면 빠르다"는 생각이 가장 위험합니다. 독립성이 확보되지 않은 작업을 병렬화하면 충돌과 오버헤드만 생겨요.

병렬 실행 vs 순차 실행 비교

주의해야 할 함정들

멀티 에이전트를 실제로 쓰다 보면 만나는 함정들을 정리했습니다.

서브에이전트 주의사항:

서브에이전트는 메인 에이전트의 대화 히스토리를 상속받지 않습니다
CLAUDE.md, MCP 서버, 스킬을 매번 새로 로드
"parallel" 키워드 없으면 순차 실행될 수 있음
두 에이전트가 같은 파일 수정 시 덮어쓰기 충돌 발생 가능

에이전트 팀 현재 한계:

세션 재개 불가 — /resume, /rewind로 진행 중인 팀원 복구 안 됨
태스크 상태 지연 — 팀원이 완료 표시를 놓치면 의존 태스크가 블록됨
종료 지연 — 팀원은 현재 요청/툴 호출 완료 후에 중단
세션당 팀 하나 — 세션 간 팀 공유 불가
중첩 팀 불가 — 팀원이 자신의 팀원을 소환할 수 없음
리드 고정 — 메인 세션이 항상 리드, 팀원 승격 불가
분할 창 제한 — tmux 또는 iTerm2 필요 (VS Code 통합 터미널, Windows Terminal, Ghostty 미지원)

Windows 환경에서 에이전트 팀을 쓰려면 tmux를 별도로 설치해야 한다는 게 현실적인 걸림돌입니다.

Claude Code Hooks와 연동해서 에이전트 작업을 더 세밀하게 제어하고 싶다면 Claude Code Hooks 완벽 가이드를 참고하세요. 프로젝트 규칙 세팅은 Claude Code CLAUDE.md 완벽 가이드가 도움이 됩니다.

FAQ

Q. 서브에이전트와 에이전트 팀 중 어떤 걸 먼저 써봐야 하나요?

서브에이전트부터 시작하는 걸 추천합니다. 설정이 필요 없고, "parallel" 키워드만 잘 써줘도 즉시 병렬 실행이 됩니다. 에이전트 팀은 에이전트 간 조율이 필요한 중복 리뷰나 역할 분담 작업에서 쓰되, 실험적 기능이라는 걸 감안해야 해요.

Q. Claude Code 병렬 실행 시 비용이 얼마나 늘어나나요?

토큰 비용은 에이전트 수에 비례해서 선형으로 증가합니다. 벽시계 시간은 줄지만 비용이 같이 줄지는 않아요. 비용도 줄이고 싶다면 오케스트레이터는 Opus, 워커는 Haiku를 쓰는 모델 라우팅 전략이 핵심입니다. 잘 설계하면 토큰 비용의 80~90%를 저렴한 모델로 이동시킬 수 있어요.

Q. 다이나믹 워크플로우는 무료 플랜에서도 쓸 수 있나요?

Pro/Max/Team/Enterprise 유료 플랜에서만 사용 가능합니다. Claude Code v2.1.154 이상 버전도 필요하고요. ultracode: 프리픽스나 "use a workflow" 문구로 트리거하고, /workflows로 모니터링할 수 있습니다.

다음 단계

멀티 에이전트 오케스트레이션을 제대로 활용하려면 프로젝트에 맞는 CLAUDE.md 세팅이 선행돼야 합니다. 에이전트가 매번 컨텍스트를 새로 로드한다는 걸 생각하면, CLAUDE.md에 팀 구조와 역할 분담 규칙을 명시해두는 게 실전에서 훨씬 안정적으로 동작합니다. Claude Code CLAUDE.md 완벽 가이드에서 실전 세팅법을 확인해보세요.

Amazon Kiro 한국어 응답 고정하는 법: 스티어링 파일 설정 완전 가이드

roundfigure — Thu, 2 Jul 2026 22:19:24 +0900

Amazon Kiro 스티어링 파일 인클루전 모드 4가지 비교

Kiro를 처음 설치하고 반가운 마음에 한국어로 질문을 던졌는데 영어로 답이 오는 경험, 해보셨나요? Amazon Kiro는 기본적으로 영어 응답 모드로 동작합니다. 한국어 입력에도 영어로 답하는 경우가 꽤 많아요. "설정이 따로 있겠지" 하고 찾아보면 의외로 명확한 가이드가 없어서 헤매게 됩니다.

해결책은 스티어링 파일(Steering File)입니다. .kiro/steering/ 폴더에 마크다운 파일 하나를 만들면, 세션을 새로 시작해도 한국어 응답이 자동으로 유지됩니다. 이 글에서는 설정 방법과 실전에서 쓸 만한 스티어링 파일 활용법을 정리했습니다.

Amazon Kiro가 뭔지 모른다면 먼저

Kiro는 AWS가 2025년 7월 정식 출시한 에이전틱 IDE(Agentic IDE)입니다. 단순한 코드 자동완성 도구가 아니라, 개발자의 아이디어를 요구사항 문서(requirements.md) → 설계 문서(design.md) → 태스크 목록(tasks.md) → 실제 코드로 변환하는 전체 파이프라인을 지원해요.

VS Code 포크 기반이라 기존 VS Code 확장 프로그램과 설정을 그대로 가져올 수 있습니다. 내부적으로 추론이 필요한 작업에는 Claude Sonnet, 대량 코드 생성에는 Amazon Nova를 라우팅하고, AWS Bedrock을 통합 모델 플레인으로 씁니다. 기존 Amazon Q Developer의 후속 제품이기도 해서, Q Developer IDE 플러그인은 2027년 4월 30일 지원이 종료됩니다.

요금은 Free(월 50크레딧)부터 Pro($20), Pro+($40), Pro Max($100), Power($200)까지 5단계예요. 일단 무료로 써보는 데 부담이 없다는 게 장점입니다.

스티어링 파일이란?

스티어링 파일은 Kiro에게 프로젝트 전반의 규칙을 영구적으로 주입하는 마크다운 파일이에요. 공식 문서 설명을 직역하면 이렇습니다.

"Instead of explaining your conventions in every chat, steering files ensure Kiro consistently follows your established patterns, libraries, and standards."

매번 대화마다 "한국어로 답해줘"라고 말할 필요 없이, 한 번 파일을 만들어두면 끝입니다.

파일 위치는 두 곳입니다.

워크스페이스 단위: 프로젝트 루트의 .kiro/steering/ 폴더
글로벌 단위: 홈 디렉토리의 ~/.kiro/steering/ 폴더

워크스페이스 스티어링은 해당 프로젝트에만 적용되고, 글로벌 스티어링은 모든 프로젝트에 적용됩니다. 한국어 설정은 보통 글로벌로 잡는 게 편합니다.

한국어 응답 고정하기: 스티어링 파일 설정

1단계: 파일 생성

프로젝트 루트에서 .kiro/steering/ 폴더를 만들고, 그 안에 korean-language.md 파일을 생성합니다.

mkdir -p .kiro/steering
touch .kiro/steering/korean-language.md

또는 Kiro IDE의 사이드바 Steering 섹션에서 + 버튼을 눌러 UI로 바로 만들 수 있어요. 범위 선택에서 해당 프로젝트만 적용할지, 모든 워크스페이스에 적용할지 고를 수 있습니다.

2단계: 파일 내용 작성

아래 내용을 그대로 복사해서 붙여넣기하면 됩니다.

---
inclusion: always
---

# 언어 설정 (Language Configuration)

## 응답 언어 규칙

- 모든 응답은 한국어로 작성해야 합니다
- 코드 주석도 가능한 한 한국어로 작성합니다
- 기술 용어는 필요시 영어와 한국어를 병행 표기합니다 (예: 컴포넌트(Component))
- 코드 내 변수명, 함수명, 클래스명은 영어를 유지합니다

## 예외 규칙

- 에러 메시지 원문은 영어로 표시 후 한국어 설명을 추가합니다
- 영어 전용 라이브러리 API 이름은 영어로 유지합니다

korean-language.md 파일 전체 구성

핵심은 맨 위 YAML 프론트매터의 inclusion: always입니다. 이 옵션이 없으면 Kiro가 해당 파일을 항상 참조하지 않을 수 있어요. 스티어링 파일에는 4가지 인클루전 모드가 있는데, 언어 설정처럼 프로젝트 전반에 반드시 적용돼야 하는 규칙은 always를 씁니다.

3단계: 확인

파일을 저장하고 Kiro 채팅창에서 아무 질문이나 해보세요. "컴포넌트 설계해줘" 같은 한국어 입력에 한국어로 답이 오면 성공입니다. 만약 여전히 영어가 나온다면, Kiro를 재시작한 뒤 다시 시도해보세요.

글로벌 적용: 모든 프로젝트에 한국어 고정

매 프로젝트마다 파일을 만드는 게 번거롭다면, 홈 디렉토리의 글로벌 스티어링 폴더에 파일을 두면 됩니다.

mkdir -p ~/.kiro/steering
cp .kiro/steering/korean-language.md ~/.kiro/steering/

한 번 설정하면 새 프로젝트를 열 때마다 자동으로 한국어 응답이 켜져 있습니다. 저는 이 방법으로 세팅해두고 프로젝트마다 따로 파일을 관리하지 않아요. 한결 편하더라고요.

스티어링 파일 인클루전 모드 4가지

한국어 설정 외에 다른 규약에도 스티어링 파일을 활용하려면 인클루전 모드를 알아두면 좋습니다.

모드	동작 방식	사용 예시
`always`	모든 대화에 항상 포함	언어 설정, 보안 정책
`fileMatch`	특정 파일 패턴이 컨텍스트에 있을 때만 로드	TypeScript 규약, React 컴포넌트 가이드
`manual`	채팅에서 `#파일명`으로 직접 참조할 때만	마이그레이션 가이드, 특수 워크플로
`auto`	Kiro가 관련성을 판단해 자동 포함	여러 맥락에 걸친 규약

auto 모드는 Kiro가 알아서 판단하는 방식이라 예측이 어려워요. 언어 설정처럼 "반드시 항상 적용돼야 하는" 규칙은 always로 명시하는 게 안전합니다.

스티어링 파일로 할 수 있는 것들

한국어 설정 외에도 스티어링 파일은 팀 규약을 일관되게 유지하는 데 강력합니다.

Kiro는 새 프로젝트를 시작하면 3가지 기본 스티어링 파일을 자동 생성해요.

product.md: 제품 목적, 대상 사용자, 주요 기능
tech.md: 사용 프레임워크, 라이브러리, 기술 스택
structure.md: 파일 구조, 네이밍 컨벤션, 아키텍처 패턴

이 파일들에 팀 규약을 추가해두면, 어떤 팀원이 Kiro로 작업해도 같은 코딩 표준을 따르게 됩니다. 솔직히 코드 리뷰에서 스타일 이슈가 줄어드는 게 가장 체감이 크더라고요. 파일 자체가 git으로 버전 관리되기 때문에, 팀 전체가 동일한 규약을 공유하기도 쉽습니다.

Kiro vs 다른 AI 코딩 도구

Amazon Kiro vs Cursor vs Claude Code vs GitHub Copilot 기능 비교 (2026)

Kiro의 포지션은 명확합니다. 신규 프로젝트에서 설계부터 코드까지 한 파이프라인으로 가져가고 싶을 때 강점을 보여요. Specs 기능으로 EARS 표기법 기반의 요구사항 문서가 자동 생성되고, 그걸 토대로 설계와 태스크까지 나오는 구조입니다.

반면 기존 레거시 코드베이스를 유지보수하거나 빠른 반복 개발이 필요한 상황에서는 Cursor가 더 빠르다는 평이 많습니다. Claude Code는 터미널 기반이라 GUI가 없고, Copilot은 인라인 자동완성에 특화돼 있어요. 각자 잘하는 영역이 다르니 업무 성격에 따라 고르는 게 맞습니다.

시작해보기

Kiro는 kiro.dev에서 무료로 다운로드할 수 있습니다. Free 플랜은 월 50크레딧이 주어져서, 가볍게 써보는 정도는 충분합니다.

한국어 설정 파일을 먼저 만들어 두고, 간단한 프로젝트에서 Specs 기능으로 요구사항 → 설계 → 태스크로 분해되는 과정을 한 번 경험해보세요. "스펙 기반 IDE"라는 말이 어떤 의미인지 바로 와닿습니다.

Kiro를 쓰면서 한국어 응답이 안 된다고 느꼈다면, 위 스티어링 파일 하나가 그 불편을 해결해줄 거예요. Claude Code에서 CLAUDE.md로 규칙을 설정하는 방식이랑 개념이 비슷하니까, 둘 다 써본 분이라면 금방 익숙해질 겁니다. Kiro의 Hooks 기능은 Claude Code Hooks와도 비슷한 이벤트 기반 자동화 개념이라, 함께 보면 이해가 빠릅니다.

Cloudflare Workers AI 요금 완전 분석: 진짜 숨은 비용은 어디서 나오나

roundfigure — Thu, 2 Jul 2026 19:36:00 +0900

Cloudflare Workers AI 요금표를 처음 열어보면 좀 당황스러워요. 어떤 모델은 1M 토큰당 몇 센트로 표시돼 있는데, 그 옆에 괄호로 "Neurons"라는 낯선 숫자가 같이 붙어 있거든요. 게다가 "egress 비용이 숨어있다더라" 같은 이야기까지 돌아다니니까 실제로 얼마가 나올지 감이 안 잡히는 게 당연합니다. 이 글에서는 Neurons와 토큰 과금이 실제로는 같은 걸 두 가지 방식으로 보여주는 것뿐이라는 점, 그리고 "숨은 비용"이라 불릴 만한 게 정확히 어디서 나오는지를 근거 있는 수치로 정리했습니다.

Cloudflare Workers AI 요금 구조를 나타내는 대표 이미지 - Neurons 단위와 모델 카테고리별 과금 방식을 보여주는 다이어그램

Neurons가 대체 뭐길래 모든 과금의 기준이 되나

Cloudflare 공식 문서는 Neurons를 "요청을 처리하는 데 필요한 GPU 컴퓨트를 나타내는, 서로 다른 모델의 AI 출력을 측정하는 자체 단위"라고 정의합니다. LLM이든 이미지 생성이든 임베딩이든 오디오든, 모델 종류가 완전히 달라도 GPU 컴퓨트라는 하나의 잣대로 통일해서 비교·과금하겠다는 거예요.

가격 자체는 단순합니다. 1,000 Neurons당 $0.011. 이 단가는 모델이 뭐든 동일합니다. 다만 같은 작업(예: 토큰 1개 생성)을 처리하는 데 모델마다 소비하는 Neurons 양이 천차만별이라서, 결과적으로 체감하는 비용은 모델별로 크게 달라집니다. 그래서 요금표에 "1M 토큰당 $X"라는 익숙한 숫자가 있어도, 청구서에는 사실 Neurons 사용량이 찍힙니다. 겉으로 보이는 단위가 다를 뿐 계산의 기준은 하나라는 거죠.

무료 티어 10,000 Neurons, 실제로 얼마나 쓸 수 있나

무료 할당량은 하루 10,000 Neurons이고, 이건 Workers Free 플랜이든 Workers Paid 플랜이든 똑같이 제공됩니다. 매일 UTC 00:00에 초기화되고요. Free 플랜은 이 한도를 넘기면 그냥 거기서 멈추고, 초과분을 계속 쓰려면 월 $5짜리 Workers Paid 플랜에 가입해야 합니다. 가입 후에는 초과 사용분에 대해서만 1,000 Neurons당 $0.011가 붙는 구조예요.

여기서 하나 짚고 넘어갈 게 있는데, OpenAI 같은 외부 모델을 AI Gateway로 중계하는 "프록시 모델"에는 이 무료 할당량이 아예 적용되지 않습니다. Cloudflare 문서 표현을 그대로 옮기면 "프록시 모델에는 무료 할당량이 없다 — 뉴런도, 토큰도, 무료 추론 비용도 0"이라고 못 박혀 있어요. Cloudflare가 직접 호스팅하는 모델을 쓸 때만 저 무료 티어가 적용된다는 뜻입니다.

모델별 토큰 단가, 텍스트만 봐도 이렇게 벌어진다

2025년 2월 20일부터 Cloudflare는 과금 표시 방식을 바꿨습니다. 예전엔 모델들을 등급별로 묶어서("버킷" 방식) 단가를 매겼는데, 지금은 모델마다 개별 단가를 표시하고 토큰 수와 Neurons 환산치를 동시에 보여줍니다. 표시 방식이 바뀐 거지 요율 자체가 통째로 바뀌었다는 근거는 없었어요.

실제 숫자로 보면 체감이 빠릅니다. 100만 토큰 기준 입력/출력 단가예요.

모델	입력 (1M 토큰)	출력 (1M 토큰)
Llama-3.2-1B	$0.027 (2,457 뉴런)	$0.201 (18,252 뉴런)
Mistral-7B	$0.110 (10,000 뉴런)	$0.190 (17,300 뉴런)
Llama-3.1-70B	$0.293 (26,668 뉴런)	$2.253 (204,805 뉴런)
Gemma-3-12B	$0.345 (31,371 뉴런)	$0.556 (50,560 뉴런)

LLM 카테고리 전체 25개 모델로 넓혀보면 입력은 $0.017~$1.40/M, 출력은 $0.026~$4.40/M 사이에 분포합니다. 제일 싼 모델과 제일 비싼 모델 사이에 입력 기준 최대 82배, 출력 기준 최대 169배 차이가 나는 거예요. 저도 처음엔 "그냥 작은 모델 쓰면 되지"라고 단순하게 생각했는데, 실제로 표를 뽑아보니 모델 선택 하나가 월 청구서를 몇 배씩 흔들 수 있겠더라고요.

토큰이 아닌 모델들, 임베딩·이미지·오디오는 기준부터 다르다

텍스트 생성 모델을 벗어나면 과금 단위 자체가 바뀝니다. 파이프라인에 이런 모델을 여러 개 조합해 쓴다면 여기부터 미리 확인해두는 게 좋습니다.

임베딩 모델(6종): 100만 입력 토큰당 $0.012~$0.204
이미지 생성 모델(6종): 512×512 타일당 $0.000059~$0.015, 또는 확산 스텝당 $0.0001056~$0.002
오디오 모델(9종): 분당 $0.0002~$0.015, 텍스트 음성 변환은 1,000자당 $0.015~$0.030
분류·번역·비전 등 기타(5종): 단위당 $0.003~$2.51

임베딩, 이미지 생성, 오디오, 기타 모델 카테고리별 과금 단위와 가격 범위를 비교하는 표

이미지 생성 모델의 경우 "이미지 1장당 정확히 얼마"라고 딱 떨어지는 숫자는 공식 문서에서 확인되지 않았어요. 해상도(타일 수)와 스텝 수에 따라 실제 소비되는 Neurons가 달라지기 때문인데, SDXL 같은 모델로 이미지 하나 뽑는 데 보통 10~30초 걸린다는 것까지만 공식적으로 확인됩니다. 그러니 이미지 생성 비용을 미리 계산할 땐 예상보다 여유 있게 잡아두는 편이 안전합니다.

"숨은 egress 비용"은 사실이 아니다 — 진짜 비용은 여기서 나온다

이 글을 검색해서 들어온 분이라면 "Workers AI 쓰면 egress 요금이 몰래 붙는다더라" 같은 얘기를 들어봤을 수도 있어요. 근데 확인해보니 이건 정확한 얘기가 아닙니다. Cloudflare 공식 문서와 R2, Workers 문서를 다 뒤져봐도 Workers AI 자체에는 별도의 데이터 전송(egress)이나 대역폭 요금이 명시돼 있지 않습니다. Cloudflare는 자사 학습 자료에서 "egress 요금을 0으로 부과한다"고 못 박고 있고, R2도 "Workers API, S3 API, r2.dev 도메인 경유를 포함해 데이터 전송 요금이 발생하지 않는다"고 설명합니다. Workers AI를 단독으로 호출해서 텍스트나 이미지를 받아오는 것만 놓고 보면, egress 청구 항목 자체가 없어요.

그럼 진짜 예상 밖 비용은 어디서 나올까요. 답은 Workers AI를 다른 Cloudflare 서비스와 엮어서 쓸 때입니다.

Vectorize(RAG 파이프라인에서 임베딩과 자주 같이 쓰는 벡터 검색 DB): 저장/조회되는 벡터 수와 차원 수를 기준으로 별도 과금됩니다. 프로토타이핑 수준은 무료 플랜에서도 되지만, 본격적으로 쓰려면 Workers 유료 플랜이 필요해요.
AI Search(과거 AutoRAG): 스토리지·벡터 인덱싱은 상품 가격에 포함돼 있지만, 그 안에서 실제로 호출되는 Workers AI와 AI Gateway 사용량은 별도로 청구됩니다.

정리하면, "egress 비용이 숨어있다"는 전제 자체가 틀렸고, 실제로 청구서를 부풀리는 건 egress가 아니라 Vectorize·AI Gateway 같은 연계 서비스의 개별 과금입니다. RAG 파이프라인처럼 여러 서비스를 조합해서 쓸 계획이라면, Workers AI 요금만 보고 예산을 잡지 말고 Vectorize·AI Gateway 요금까지 따로 더해서 계산해야 실제 비용에 가까워집니다.

한 가지 더 참고할 만한 건, 서드파티 비교 사이트 하나에서 "일정 사용량을 넘기면 엔터프라이즈 전환을 유도하는 비공개 한도가 있다"는 사용자 인용을 소개한 적이 있는데, 이건 단일 출처 기반의 사용자 경험담일 뿐 Cloudflare 공식 문서에서는 확인되지 않았습니다. 이 부분은 아직 "확정된 사실"이 아니라 참고 정도로만 받아들이는 게 맞습니다.

Workers AI 단독 사용 vs Vectorize·AI Gateway를 결합한 RAG 파이프라인의 과금 구조 차이를 나타내는 흐름도

요금 정책은 계속 바뀌어왔다

Workers AI는 처음엔 베타 기간 동안 무료·무제한이었고, 2024년 4월 1일부터 비베타 모델 과금이 시작됐습니다. 이후 2024년 11월 1일에 새 가격 구조가 적용됐고, 2025년 2월 20일에 지금의 모델별 개별 단가 표시 방식으로 다시 바뀌었어요. 이렇게 짧은 기간에 몇 번씩 개편된 이력을 보면, 지금 정리한 단가도 앞으로 또 바뀔 가능성을 열어두고 봐야 합니다. 실제로 프로덕션에 붙이기 전에는 항상 공식 요금 페이지에서 최신 수치를 한 번 더 확인하시길 권합니다.

Workers AI로 추론까지는 처리하되 서버 인프라 자체를 직접 관리해야 하는 상황이라면, Vultr 같은 클라우드에서 별도 인스턴스를 붙이는 경우도 종종 있습니다. 신규 가입 시 30일간 $300 크레딧을 주는 프로모션이 있어서, 사이드 프로젝트로 이것저것 테스트해보기엔 부담이 적은 편이에요. → Vultr 시작하기

Workers AI 요금 구조, 결국 핵심은 세 가지예요. Neurons 하나로 통일된 과금 기준, 모델별로 천차만별인 단가, 그리고 egress가 아니라 연계 서비스에서 튀는 진짜 비용. 다음에 RAG 파이프라인이나 이미지 생성 워크플로우를 Workers AI로 붙일 계획이 있다면, Vectorize·AI Gateway 요금표까지 같이 열어두고 계산해보세요.

MCP Apps란 무엇인가: 대화창에 대시보드가 뜨는 이유 (2026 최종 스펙)

roundfigure — Thu, 2 Jul 2026 15:03:09 +0900

Claude나 ChatGPT한테 "이번 달 매출 데이터 보여줘" 했는데 텍스트 요약 대신 진짜 대시보드가 화면에 떴다면, 그게 바로 MCP Apps입니다. 저도 처음 이 화면을 봤을 때 "이게 챗봇 창 맞나" 싶었어요. MCP Apps는 Model Context Protocol의 첫 번째 공식 확장(extension)으로, 도구 실행 결과를 텍스트가 아니라 대화형 HTML UI로 돌려줄 수 있게 해주는 규격입니다. 이 구조가 실제로 어떻게 돌아가는지, 얼마나 안전한지, 지금 당장 어디서 써볼 수 있는지 하나씩 짚어보겠습니다.

채팅 대화창 안에 대시보드형 UI가 인라인으로 렌더링되는 모습을 보여주는 개념 일러스트

MCP Apps가 나온 이유

MCP Apps(SEP-1865)는 2025년 11월 21일 처음 제안됐고, 2026년 1월 26일 Model Context Protocol 공식 블로그를 통해 "첫 번째 공식 MCP 확장"으로 발표되면서 바로 프로덕션에 쓸 수 있는 상태가 됐습니다. MCP-UI 프로젝트와 OpenAI Apps SDK가 먼저 "UI 리소스가 MCP 생태계에 자연스럽게 들어맞는다"는 걸 증명했고, 그 뒤 Anthropic과 OpenAI가 손잡고 어떤 MCP 클라이언트에서도 쓸 수 있는 공유 오픈 표준으로 다듬었습니다.

문제의식은 단순합니다. 도구가 수백 개 행짜리 데이터베이스 쿼리 결과를 돌려줘도, 지금까지는 모델이 그걸 텍스트로 요약하는 수밖에 없었어요. 근데 사용자는 요약이 아니라 직접 들여다보고 필터링하고 싶을 때가 많잖아요. MCP Apps 공식 블로그도 정확히 이 지점을 짚습니다. 텍스트만으로는 실시간 업데이트도, 미디어 뷰어도, 상태를 유지하는 다단계 워크플로우도 만들기 어려웠던 겁니다.

도구와 UI 리소스는 어떻게 연결되나

구조 자체는 생각보다 단순해요. 도구(tool) 하나가 UI 리소스 하나를 참조하는 방식입니다. UI 리소스는 ui:// 스킴으로 식별되고, 도구는 _meta.ui.resourceUri 필드로 이 리소스를 가리킵니다.

{
  "name": "get_weather",
  "_meta": {
    "ui": {
      "resourceUri": "ui://weather-server/dashboard-template",
      "visibility": ["model", "app"]
    }
  }
}

visibility 필드가 재밌는데, model이면 에이전트가 이 UI를 표시·호출할 수 있고 app이면 같은 서버 안의 다른 앱에서만 불러쓸 수 있습니다. 기본값은 둘 다 포함이에요. 호스트는 도구 설명에서 이 메타데이터를 읽고 UI를 미리 가져와서(prefetch) 캐싱해두고, 렌더링 전에 보안 검토까지 끝내둘 수 있습니다. 즉 사용자가 도구를 호출하는 순간엔 이미 검증이 끝난 UI가 나오는 구조예요.

도구(tool)의 _meta.ui.resourceUri가 ui:// 스킴 리소스를 참조하고 호스트가 이를 prefetch·캐싱하는 흐름을 보여주는 다이어그램

렌더링된 iframe이 호스트와 주고받는 통신은 postMessage 위에 JSON-RPC 2.0을 얹은 방식입니다. MCP 전체가 쓰는 것과 같은 기반 프로토콜이라, UI 안에서 시작된 액션(도구 호출 같은)도 전부 기존 MCP의 감사·동의 절차를 그대로 통과해요. View에서 Host로 ui/open-link, ui/message, tools/call 같은 요청을 보내고, Host는 ui/notifications/tool-result, ui/notifications/size-changed 같은 알림으로 응답합니다. 콘텐츠 타입은 text/html;profile=mcp-app이 필수고, 유효한 HTML5 문서여야 합니다.

MCP Apps 보안은 괜찮을까

솔직히 이 부분이 제일 궁금했어요. 채팅창에 임의의 HTML을 띄운다니, 뭔가 불안하지 않나 싶었거든요. 스펙을 보니 3계층으로 방어하고 있더라고요.

첫째, 모든 UI 콘텐츠는 권한이 제한된 샌드박스 iframe에서만 실행됩니다. 기본 샌드박스 속성은 allow-scripts, allow-same-origin 정도로 좁혀져 있어요. 둘째, 호스트가 렌더링하기 전에 HTML 템플릿을 미리 검토할 수 있도록 도구가 UI를 사전 선언합니다. 셋째, UI와 호스트 사이의 모든 통신이 로깅 가능한 JSON-RPC를 통해 오가서 감사가 가능합니다.

여기에 도메인 단위 CSP(Content Security Policy)도 자동으로 걸립니다. connectDomains, resourceDomains, frameDomains 같은 걸 선언하면 각각 connect-src, frame-src 같은 지시어로 매핑되고, 선언이 없으면 기본값이 default-src 'none'으로 아주 빡빡하게 잡힙니다. 카메라·마이크·클립보드 같은 권한도 iframe의 allow 속성으로 별도 요청해야 하고요. 공식 블로그도 "MCP 서버 연결 전 철저히 검증할 것"을 명시적으로 권고하고 있는데, 이건 자동으로 다 막아주는 마법 같은 게 아니라 여전히 신뢰할 수 있는 서버만 연결해야 한다는 뜻이에요.

MCP Apps는 지금 어디서 써볼 수 있나

2026년 1월 26일 발표 시점 기준으로 Claude(웹·데스크톱), Goose, VS Code Insiders에서 이미 사용 가능했고 ChatGPT는 그 주 안에 지원 예정이었습니다. JetBrains, AWS, Google DeepMind도 관심을 표명했고요.

VS Code 쪽 활용 사례가 특히 구체적입니다. AI 코딩 에이전트가 드래그앤드롭으로 항목을 재정렬하는 인터페이스를 보여주거나, CPU 프로필 데이터를 텍스트 요약 대신 대화형 플레임 그래프로 띄워서 콜 스택을 바로 탐색하게 해주는 식이에요. 기능 플래그를 환경별(prod/staging/dev)로 보여주고 그 자리에서 전환하는 UI도 예시로 나와 있습니다. 세일즈 분석 도구가 지역별 필터와 계정 드릴다운이 되는 대시보드를 반환하는 시나리오, "production" 선택 시 보안 옵션이 추가로 나타나는 설정 마법사 시나리오도 있고요.

2026-07-28 최종 스펙에서 MCP Apps의 위치

MCP Apps는 단독 기능이 아니라 더 큰 스펙 개편의 일부입니다. 릴리스 후보는 2026년 5월 21일 나왔고, 최종 스펙은 2026년 7월 28일 출시됐어요. 이 릴리스에서 눈에 띄는 변화가 몇 가지 있습니다.

가장 큰 건 Stateless Protocol Core예요. 기존 initialize/initialized 핸드셰이크와 Mcp-Session-Id 헤더가 사라지고, 어떤 요청이든 아무 서버 인스턴스에나 도착해도 처리되는 구조로 바뀌었습니다. 원격 MCP 서버를 일반 라운드로빈 로드밸런서 뒤에 그냥 둘 수 있게 된 거죠. Extensions Framework도 새로 생겼는데, 확장을 역-DNS ID로 식별하고 클라이언트·서버 capabilities의 extensions 맵으로 협상하는 공식 체계입니다. MCP Apps는 이 프레임워크 아래 확장 중 하나로 편입됐고요.

그 외에 Tasks가 실험 기능에서 정식 확장으로 승격됐고, authorization은 OAuth 2.0·OIDC 배포 방식과 더 맞도록 강화됐습니다. 기능 폐기(deprecation) 정책도 공식화돼서 Roots, Sampling, Logging이 폐기 예정으로 표시됐어요. 하나씩 보면 개별 변경이지만, 전체적으로는 MCP가 "실험적 프로토콜"에서 "운영 가능한 표준"으로 넘어가는 신호로 읽힙니다.

MCP Apps, Stateless Protocol Core, Extensions Framework, Tasks, Authorization 강화, Deprecation 정책이 2026-07-28 최종 스펙에 포함된 구성을 정리한 다이어그램

직접 확인해보고 싶다면

MCP Apps는 이미 스펙 문서와 예제 서버가 공개돼 있어서, 지금 쓰고 있는 MCP 클라이언트가 뭔지에 따라 바로 체감할 수 있습니다. Claude나 VS Code Insiders를 쓰고 있다면 UI를 반환하는 MCP 서버 하나만 연결해봐도 감이 옵니다. 도구를 직접 만들어보는 쪽이라면 _meta.ui.resourceUri 필드부터 붙여보는 게 제일 빠른 시작점이고요. 관련해서 더 궁금한 부분이 있으면 다음 글에서 실제 서버 구현 예제로 이어가 볼게요.

Claude Code Teleport 완전 정리: 웹 세션을 로컬로 가져오는 법

roundfigure — Thu, 2 Jul 2026 11:20:20 +0900

출근길 지하철에서 스마트폰으로 Claude Code 웹 세션 하나 던져놓고, 회사 도착해서 노트북 열자마자 그 작업을 이어서 하고 싶었던 적 있으신가요? 저도 처음엔 "그냥 새로 시작하면 되지"라고 생각했는데, 막상 컨텍스트를 다시 설명하려니 시간이 꽤 걸리더라고요. Claude Code의 Teleport 기능이 정확히 이 문제를 풉니다. claude.ai/code에서 돌아가던 클라우드 세션을 대화 기록과 작업 브랜치까지 통째로 로컬 터미널로 끌고 올 수 있거든요. 이번 글에서는 --teleport와 /teleport 사용법, 텔레포트 전에 반드시 확인해야 할 요구조건, 그리고 헷갈리기 쉬운 --resume·--remote·Remote Control과의 차이를 정리해봤습니다.

claude.ai/code 웹 화면에서 "Open in CLI" 버튼을 클릭하는 장면

Teleport란 무엇인가: 세션 모빌리티 기능

Teleport는 Claude Code에서 웹과 로컬 터미널 사이에 작업을 이동시키는 "세션 모빌리티" 기능입니다. 공식 문서는 이걸 "Move tasks between web and terminal" 섹션에서 설명하는데, 방향이 두 개예요. --remote는 터미널에서 웹으로, --teleport는 반대로 웹에서 터미널로 보내는 명령입니다. 클라우드 세션은 Anthropic이 관리하는 인프라에서 돌아가기 때문에 브라우저를 닫아도 세션이 살아있고, 심지어 Claude 모바일 앱에서 진행 상황을 확인할 수도 있어요.

다만 아직은 모든 사용자에게 열려 있는 건 아닙니다. 현재는 Pro, Max, Team 사용자, 그리고 프리미엄 시트를 가진 Enterprise 사용자에게 리서치 프리뷰 형태로 제공되고 있어요.

--teleport / /teleport 사용법: 웹 세션을 로컬로 가져오기

공식 문서에 나온 방법은 크게 네 가지입니다.

claude --teleport: 터미널에서 이 명령을 실행하면 대화형 세션 선택기가 뜹니다. 목록에서 원하는 클라우드 세션을 고르면 됩니다.
claude --teleport <session-id>: 세션 ID를 알고 있으면 선택기를 거치지 않고 바로 재개할 수 있어요.
/teleport (단축형 /tp): 이미 CLI 세션 안에 있다면 Claude Code를 재시작할 필요 없이 이 명령으로 같은 선택기를 열 수 있습니다.
/tasks에서 t 키: 백그라운드 세션 목록을 /tasks로 확인한 뒤 t를 누르면 해당 세션으로 텔레포트됩니다.

웹 인터페이스 쪽에서 시작하는 방법도 있어요. 세션 화면에서 "Open in CLI"를 누르면 터미널에 붙여넣을 명령이 클립보드에 복사됩니다.

텔레포트가 실행되면 Claude가 자동으로 (1) 올바른 저장소에 있는지 확인하고, (2) 클라우드 세션에서 만든 브랜치를 fetch·checkout하고, (3) 전체 대화 기록을 터미널로 불러옵니다. 커밋되지 않은 변경사항이 있으면 먼저 stash 하라는 안내가 뜨니 참고하세요.

--teleport 실행 시 나타나는 대화형 세션 선택기 터미널 화면

텔레포트 전에 반드시 확인해야 할 4가지 요구조건

여기서 막히는 경우가 은근히 많습니다. 텔레포트는 세션을 재개하기 전에 아래 네 가지를 검사하는데, 하나라도 안 맞으면 오류가 나거나 해결 방법을 안내받습니다.

요구조건	내용
클린 git 상태	작업 디렉터리에 커밋되지 않은 변경사항이 없어야 합니다. 있으면 stash 하라고 안내됩니다.
올바른 저장소	포크가 아닌, 동일한 저장소의 체크아웃에서 실행해야 합니다.
브랜치 존재	클라우드 세션에서 만든 브랜치가 원격에 push되어 있어야 합니다.
동일 계정	클라우드 세션과 같은 claude.ai 계정으로 인증돼 있어야 합니다.

이 중에서 특히 헷갈리는 게 인증 방식이에요. Teleport는 claude.ai 구독 인증이 필요합니다. API 키나 Bedrock, Vertex AI, Microsoft Foundry로 로그인한 상태라면 --teleport 자체가 안 뜹니다. /login으로 claude.ai 계정으로 다시 로그인해야 해요. claude.ai로 이미 로그인했는데도 안 된다면, 조직(organization)에서 클라우드 세션 기능을 아직 활성화하지 않았을 가능성이 큽니다.

Teleport는 일방향이다: --remote와의 관계

여기서 오해하기 쉬운 부분이 하나 있는데요, 텔레포트는 웹에서 로컬로 가져오는 것만 됩니다. 반대로 로컬에서 작업하던 세션을 그대로 웹으로 밀어 올리는 기능은 없어요.

로컬 작업을 클라우드로 보내고 싶다면 --remote 플래그를 씁니다. 예를 들어 claude --remote "Fix the authentication bug in src/auth/login.ts"처럼 실행하면, 현재 디렉터리의 GitHub 원격 저장소를 현재 브랜치 기준으로 클론해서 새 클라우드 세션을 만듭니다. 여기서 중요한 건 "새로 만든다"는 점이에요. 기존 로컬 대화를 그대로 옮기는 게 아니라, VM이 로컬 머신이 아니라 GitHub에서 클론하는 방식이라 push하지 않은 로컬 변경사항이 있으면 먼저 push해야 합니다. --remote는 한 번에 하나의 저장소에서만 동작하고요.

v2.1.195부터는 컨테이너가 준비되는 동안 저장소 클론, 셋업 스크립트 실행 같은 과정을 실시간 체크리스트로 보여주는데, 이 대기 시간에 입력한 메시지는 큐에 쌓였다가 세션이 준비되면 자동으로 전송됩니다.

정리하면, --remote(로컬→웹, 새 세션 생성)와 --teleport(웹→로컬, 기존 세션 그대로 가져오기)는 짝을 이루는 반대 방향 명령이지만 동작 방식은 완전히 대칭은 아닙니다. 참고로 Desktop 앱에는 로컬 세션을 웹으로 보내는 "Continue in" 메뉴가 별도로 존재한다고 하니, 데스크톱 사용자라면 이 경로도 확인해보시면 좋을 것 같아요.

--teleport와 --remote 방향을 화살표로 표시한 다이어그램

--teleport vs --resume: 헷갈리지 말아야 할 차이

이름이 비슷해서 처음엔 저도 둘을 혼동했는데, 역할이 완전히 다릅니다. --resume은 "이 머신"에 저장된 로컬 대화 기록만 재개하는 명령이에요. 클라우드 세션 목록은 아예 보여주지 않습니다. 반면 --teleport는 클라우드에서 실행 중이던 세션과 그 세션이 만든 브랜치를 통째로 끌어옵니다.

즉 지금 쓰던 노트북에서 어제 하던 로컬 작업을 이어가고 싶으면 --resume, 다른 기기(또는 웹)에서 돌리던 클라우드 세션을 이 컴퓨터로 가져오고 싶으면 --teleport를 쓰면 됩니다.

Remote Control과는 다른 개념

Teleport와 자주 헷갈리는 또 다른 기능이 Remote Control입니다. 이름도 비슷하고 둘 다 "다른 기기에서 이어간다"는 느낌이라 헷갈리기 쉬운데, 실행 위치가 정반대예요.

Teleport로 가져오는 세션은 Anthropic이 관리하는 클라우드 VM에서 실행됩니다. 반면 Remote Control은 로컬 머신에서 계속 돌아가는 Claude Code 세션을 웹이나 모바일 앱에서 원격으로 조작하는 기능입니다. 코드 자체는 클라우드로 이동하지 않고, 로컬 파일시스템과 MCP 서버, 로컬 툴이 그대로 사용돼요. claude remote-control(서버 모드), claude --remote-control(단축 --rc), 세션 도중 /remote-control(단축 /rc)로 시작할 수 있고, v2.1.51 이상이 필요합니다. API 키 인증으로는 쓸 수 없고 Pro/Max/Team/Enterprise 구독이 있어야 하며, Team/Enterprise라면 관리자가 별도로 토글을 켜야 합니다.

공식 문서는 두 기능의 용도를 이렇게 구분합니다. Claude Code on the web(및 --remote, --teleport)은 "로컬 설정 없이 작업을 시작하거나 여러 작업을 병렬로 돌릴 때", Remote Control은 "로컬 작업 도중 다른 기기에서 이어가고 싶을 때" 적합하다고요. 실제로 Claude Code 개발을 이끄는 Anthropic의 Boris Cherny는 v2.1.0 출시를 알리며 두 기능을 나란히 소개했는데, 본인은 /config에서 "Enable Remote Control for all sessions"를 켜두고 쓴다고 언급하기도 했습니다.

트러블슈팅 관점에서 하나 더 알아두면 좋은 게, --teleport는 사실 Remote Control과 같은 연결 인프라를 씁니다. 그래서 인증 오류가 날 때 "Remote Control session expired" 같은 문구로 뜨는 경우가 있어요. 이땐 로컬에서 /login으로 자격 증명을 새로고침하고, 클라우드 세션을 만든 계정과 같은 계정으로 로그인했는지 확인하면 됩니다. 클라우드 세션은 일정 시간 활동이 없으면 환경이 회수되는데, 이 경우 "Could not resume session ... its environment has expired"라는 메시지가 뜨고 claude.ai/code에서 다시 열면 대화 기록이 복원된 새 환경이 준비됩니다.

실전 팁: 백그라운드 세션과 함께 쓰기

매번 브라우저 열어서 세션 시작하는 게 번거롭다면? CLI나 VS Code에서 프롬프트 앞에 &를 붙이면 백그라운드 클라우드 세션이 바로 시작됩니다. 예를 들어 & Refactor the authentication module to use JWT tokens처럼요. 이렇게 시작한 세션은 나중에 claude --teleport <session-id>로 로컬로 가져올 수 있어요. 여러 작업을 병렬로 돌리거나, 세션 ID를 공유해서 비동기로 페어 프로그래밍하는 식으로 활용할 수 있습니다. 나중에 기기를 바꿀 가능성이 조금이라도 있다면 처음부터 &로 작업을 띄우고 git 상태를 깨끗하게 유지하는 습관을 들이는 게 좋습니다. 텔레포트 요구조건 1번(클린 git 상태)에서 걸리는 걸 미리 막아주거든요.

다만 /teleport 명령 자체는 아직 신생 기능이라 배포 초기 버전 간 편차가 있었습니다. GitHub 이슈 트래커에는 v2.1.1의 Claude Max 계정, macOS 환경에서 /teleport가 자동완성 목록에 안 뜨고 /remote-env만 표시됐다는 버그 보고가 있었어요. 최신 버전에서는 해결됐을 가능성이 높지만, 명령이 안 보인다면 버전부터 확인해보시길 권합니다.

마치며

Teleport는 "어디서 시작했든 계속 이어간다"는 방향으로 Claude Code가 진화하고 있다는 걸 보여주는 기능이라고 생각해요. 아직 리서치 프리뷰 단계라 세부 동작이 조금씩 바뀔 수 있으니, 자주 쓰는 워크플로라면 claude --version으로 버전을 챙겨두고 공식 릴리스 노트를 가끔 확인해보시는 걸 추천합니다.

Google Antigravity 완벽 가이드 — Gemini AI 에이전트 IDE 직접 써보니

roundfigure — Thu, 2 Jul 2026 03:17:19 +0900

AI 코딩 도구가 쏟아지는 시대에 "구글도 뭔가 만들었다"는 소식이 들렸을 때, 저도 처음엔 반신반의했습니다. 코드 자동완성 정도겠지 싶었거든요. 근데 실제로 써보니 방향 자체가 달랐어요. Google Antigravity는 단순한 AI 에디터가 아니라 에이전트를 지휘하는 플랫폼에 가깝습니다. 이 글에서는 기능, 요금제, 경쟁 도구와의 차이점을 실제 사용 경험 기반으로 정리합니다.

Google Antigravity 공식 사이트 메인 화면 — "아이디어를 프로덕션 수준 앱으로" 슬로건이 보이는 데스크탑 스크린샷

Google Antigravity가 뭔지 30초 만에 이해하기

2025년 11월 18일, Gemini 3 모델 발표와 동시에 공개된 Google DeepMind의 에이전트 우선(Agent-First) 개발 플랫폼입니다. 그리고 2026년 5월 19일 Google I/O에서 Antigravity 2.0이 발표되면서 단일 IDE에서 5개 서피스를 갖춘 플랫폼으로 확장됐어요.

구글 스스로 "에이전트 컨트롤 타워"라고 부를 만큼, 이 도구의 핵심은 코드를 쓰는 게 아니라 에이전트에게 일을 시키는 겁니다. 계획 수립, 코드 작성, 테스트, 브라우저 조작까지 에이전트가 자율적으로 처리하고, 개발자는 결과를 확인하고 피드백을 주는 식이죠.

공식 사이트: https://antigravity.google/

Antigravity 2.0의 5가지 서피스

Antigravity 2.0은 아래 5가지 형태로 제공됩니다.

데스크탑 앱: 에이전트 오케스트레이션 중심의 메인 UI입니다. macOS(Apple Silicon/Intel), Windows(x64/ARM64), 일부 Linux를 지원합니다.

Antigravity CLI: 터미널로 에이전트를 제어하는 도구입니다. 2026년 6월 18일에 기존 Gemini CLI를 완전히 대체했고, 명령어는 agy입니다. Go 언어로 재작성되어 응답 속도도 개선됐어요.

Antigravity SDK: 커스텀 에이전트 워크플로우를 직접 만들 수 있는 SDK.

Managed Agents API: Gemini API 단일 호출로 에이전트 인스턴스를 생성하는 기능입니다. 격리된 Linux 환경에서 코드 실행, 파일 관리, 웹 브라우징까지 처리합니다.

Enterprise Agent Platform: Google Vertex AI·Cloud 연동, SSO, 전체 감사 로그를 포함한 기업용 플랫폼.

Antigravity 2.0 Manager View 화면 — 최대 5개 에이전트가 병렬로 실행 중인 대시보드 캡처

Google Antigravity 핵심 기능 3가지 — 실제로 차별화되는 것들

Manager View: 에이전트 5개를 동시에 돌린다

가장 눈에 띄는 기능입니다. 실행 중인 에이전트를 한 화면에서 관제하는 대시보드인데, 최대 5개 병렬 에이전트를 동시에 돌릴 수 있어요. Cursor의 사이드바나 Claude Code의 터미널 방식과 다르게, "미션 컨트롤" 형태의 UI를 제공합니다.

구글이 직접 93개 에이전트를 병렬 실행해서 12시간 내 운영체제를 $1,000 미만으로 빌드하는 데모를 시연했는데, 그게 이 구조의 잠재력을 보여주는 데모였습니다.

동적 서브에이전트: 메인이 서브를 알아서 만든다

Antigravity 2.0의 가장 큰 신기능입니다. 이전까지는 사용자가 수동으로 에이전트를 생성해야 했지만, 2.0부터는 메인 에이전트가 작업에 따라 전문화된 서브에이전트를 자율적으로 스폰합니다. 각 서브에이전트는 독립된 워크스페이스에서 병렬 작업하기 때문에 메인 컨텍스트 윈도우가 오염되지 않아요.

예약 백그라운드 작업

에이전트 작업을 특정 시간에 자동 실행하도록 예약하는 기능입니다. 대규모 리팩토링이나 장시간 리서치처럼 시간이 걸리는 작업을 밤새 돌려두고 아침에 결과만 확인하는 방식이 가능합니다.

이 외에도 Artifacts 시스템(결과물을 스크린샷·작업 목록·브라우저 레코딩으로 저장), 음성 명령(2.0 신기능), 지식 베이스(컨텍스트 저장)가 포함돼 있습니다.

Antigravity 요금제 — 무료지만 쿼터 소진이 빠르다

플랜	가격	특징
무료	$0	모든 모델 접근, 약 5시간마다 쿼터 리셋
AI Pro	$20/월	무료 대비 향상된 한도
AI Ultra	$100/월	Pro 대비 5배 한도, Gemini 3.5 Flash 우선 접근
AI Ultra Max	$200/월	Pro 대비 20배 한도 (원래 $249.99에서 I/O 2026 이후 인하)

솔직히 말하면, 무료 쿼터는 생각보다 빨리 닳습니다. 초기 사용자들이 20분 만에 크레딧을 소진했다는 후기가 적지 않았고, 2026년 3월에는 무료 티어 쿼터가 92% 삭감됐어요. 가볍게 체험하는 용도라면 무료로도 충분하지만, 실제 개발 작업에 쓰려면 Pro 이상을 고려하는 게 현실적입니다.

크레딧 시스템도 있습니다. $0.01/크레딧 기준이며, 대량 구매 시 $199에 20,000 크레딧을 살 수 있습니다.

Antigravity 요금제 비교 화면 — 무료/Pro/Ultra/Ultra Max 플랜 특징 정리 테이블

Cursor, Claude Code와 비교하면

AI 코딩 도구가 너무 많아서 "뭘 써야 하나" 헷갈리는 분들을 위해 간단히 정리합니다.

Google Antigravity: 병렬 에이전트 오케스트레이션, 구글 생태계(AI Studio/Firebase/Android) 통합, 동적 서브에이전트 자동 생성이 강점입니다. 음성 명령도 됩니다. 반면 무료 쿼터 소진이 빠르고, 자동 업데이트로 개발 환경이 바뀌는 경험을 한 사람이 많습니다.

Cursor: Pro $20/월. 완성도 높은 IDE 경험과 모델 선택 폭이 넓습니다. 생태계 안정성 면에서는 현재 가장 균형이 잡혀 있어서, 대부분의 팀에 1순위로 추천되는 도구입니다.

Claude Code: 터미널 네이티브 에이전트 도구입니다. VS Code, Cursor, JetBrains 어디서든 쓸 수 있고, 에디터를 대체하는 게 아니라 기존 도구 위에 얹히는 방식이라 통제 가능한 에이전트 워크플로우를 선호하는 팀에 맞습니다.

Windsurf/Devin Desktop: $15/월로 가장 저렴한 유료 IDE입니다. 참고로 Windsurf는 2026년 6월 2일 Cognition이 Devin Desktop으로 리브랜딩했습니다.

기본 모델은 Gemini 3.5 Flash(경쟁 프론티어 모델 대비 4배 빠른 속도를 주장)이며, Gemini 3.1 Pro, Claude Sonnet 4.5, GPT-OSS로도 전환할 수 있습니다.

Antigravity 써보기 전에 알았으면 좋았을 것들

2.0 업데이트가 자동으로 기존 IDE 인터페이스를 제거한 건 꽤 큰 반발을 샀습니다. 사전 고지 없이 터미널, 파일 탐색기, 직접 코드 편집 기능이 사라졌고, 기존 설정까지 날아가는 경우가 있었어요. Hacker News에서 "바이트앤스위치(bait and switch)"로 불린 이유가 있었습니다.

보안 이슈도 있었습니다. 2026년 1월 7일 Strict Mode를 우회하는 프롬프트 인젝션 취약점이 발견됐고, 2026년 2월 28일에 패치됐습니다.

Gemini CLI를 쓰던 분들께 한 가지 더. 기존 Gemini CLI는 오픈소스였지만 Antigravity CLI는 폐쇄 소스(closed-source)로 전환됐습니다. 할당량 기준도 바뀌어서, 기존 1,000 요청/일에서 주간 컴퓨팅 기반 캡으로 변경됐어요.

시작하는 방법

다운로드: https://antigravity.google/download

Windows는 x64 또는 ARM64용 .exe 인스톨러, macOS는 Apple Silicon 또는 Intel용 .dmg 파일을 받으면 됩니다. 설치 후 Google 계정으로 로그인하면 AI 기능이 바로 활성화됩니다.

처음 실행하면 Manager View(에이전트 매니저)가 기본 화면으로 뜹니다. 기존 에디터 형태가 익숙한 분들은 별도로 Editor View를 다운로드해야 합니다. 한국어 프롬프트를 그대로 쓸 수 있어서 영어를 굳이 쓰지 않아도 됩니다.

공식 코드랩: https://codelabs.developers.google.com/getting-started-google-antigravity

자주 묻는 질문

Q. 무료로 실무에 써도 되나요?
가볍게 시험해보는 정도는 됩니다. 다만 대규모 작업을 돌리다 보면 쿼터가 생각보다 빨리 소진됩니다. 매일 쓸 생각이라면 Pro($20/월)가 현실적입니다.

Q. 기존 Gemini CLI 사용자라면 어떻게 해야 하나요?
2026년 6월 18일에 Gemini CLI가 서비스 종료됐습니다. 명령어를 gemini에서 agy로 바꾸고 Antigravity CLI로 이전하면 됩니다. Agent Skills, Hooks, Subagents, Extensions 기능은 유지됩니다.

Q. Cursor랑 같이 써도 되나요?
네, 충돌하지 않습니다. Claude Code처럼 기존 에디터와 병행 사용이 가능합니다.

직접 써볼 준비가 됐다면

에이전트 오케스트레이션을 직접 경험하고 싶다면, https://antigravity.google/download 에서 무료로 시작해 보세요. 쿼터 소진 속도를 먼저 체감해보고 유료 전환 여부를 결정하는 게 순서입니다. 구글 생태계(Firebase, AI Studio, Android)를 이미 쓰고 있다면 시너지가 특히 큽니다.

Cursor iOS 앱 완벽 가이드 — 모바일에서 AI 코딩 에이전트 굴리는 법

roundfigure — Wed, 1 Jul 2026 08:03:10 +0900

스마트폰으로 코딩한다는 말, 솔직히 6개월 전만 해도 웃어넘겼을 얘기예요. 근데 Anthropic Claude Code의 헤드 Boris Cherny가 TechCrunch 인터뷰에서 이런 말을 했습니다. "Most of my coding now is on my phone. I would have said 'you're crazy' if you told me that six months ago, but yeah, here we are." 그리고 2026년 6월 29일, Cursor도 iOS 앱을 공개 베타로 내놨습니다. Cursor for iOS가 정확히 무엇인지, 어떻게 쓰는 건지 처음부터 짚어볼게요.

Cursor for iOS 앱 아이콘과 App Store 다운로드 화면

Cursor iOS 앱의 실체 — "코드 에디터 아닙니다"

가장 먼저 짚어야 할 부분이 여기입니다. Cursor for iOS는 모바일 IDE가 아닙니다.

App Store 설명 문구는 "AI coding agent for big ideas"이고, Cursor 공식 블로그는 "the agent-native way to build ambitious software"라는 표현을 씁니다. 실제 코드를 타이핑하고 실행하고 테스트하는 곳은 여전히 클라우드 VM이나 데스크톱입니다. 폰은 그 작업에 지시를 내리고, 결과를 검토하고, PR을 병합하는 컨트롤 패널 역할을 합니다.

eesel AI가 이걸 아주 깔끔하게 정리했어요. "The phone isn't where you code — it's where you decide what gets coded and then get on with your life." 저도 처음엔 "그럼 별로 쓸모 없는 거 아냐?" 싶었는데, 에이전트 중심 개발 방식이 익숙해지고 나면 이 구분이 꽤 의미 있게 다가옵니다.

Cursor 제품 리드 Kevin Niparko의 말이 이 앱의 탄생 배경을 잘 설명해줍니다. "에이전트를 살려두기 위해 노트북이 닫히지 않도록 작은 장치를 들고 다니는 엔지니어들을 보곤 한다." 그 문제를 해결하는 게 이 앱의 목적입니다.

Cursor iOS 앱 메인 화면 — 에이전트 목록과 상태 표시 인터페이스

Cursor 모바일의 두 가지 핵심 워크플로우

앱을 열면 크게 두 가지 방식으로 에이전트를 돌릴 수 있습니다.

클라우드 에이전트 (Cloud Agents)

완전히 격리된 VM에서 실행됩니다. VM에는 레포지토리가 클론되고, 의존성이 설치된 완전한 개발 환경이 구성됩니다. 에이전트가 작업을 마치면 별도 브랜치에 PR을 만들고, 스크린샷·동영상·로그 같은 아티팩트도 함께 제출하죠.

눈에 띄는 스펙이 몇 가지 있어요. 에이전트를 동시에 10~20개까지 병렬 실행할 수 있고, 내 노트북이 꺼져 있어도 상관없습니다. 2026년 2월부터는 "Computer Use" 기능도 추가됐는데, 에이전트가 브라우저를 직접 열고 localhost UI를 클릭해서 변경 사항을 시각적으로 검증하는 방식입니다. GitHub, GitLab, Azure DevOps, Bitbucket Cloud를 지원합니다.

한 가지 알아둘 점은 클라우드 에이전트는 항상 Max Mode로 실행된다는 거예요. 비활성화 옵션이 없고, 선택한 모델의 API 가격으로 과금됩니다. 처음 시작할 때 지출 한도를 설정해야 합니다.

Cursor 클라우드 에이전트 실행 화면 — VM 상태와 PR 생성 결과

Remote Control (원격 제어)

집이나 사무실 데스크톱에서 이미 돌아가고 있는 로컬 에이전트를 폰으로 계속 지휘하는 방식입니다. "컴퓨터를 깨어 있게 유지" 설정을 켜두면 자리를 비워도 데스크톱이 접근 가능 상태를 유지합니다.

Teams·Enterprise 플랜 사용자라면 워크스페이스 어드민이 Cursor Dashboard에서 Remote Control을 먼저 활성화해야 사용 가능합니다.

iOS 네이티브 기능들

그냥 웹뷰 감싼 앱이 아닙니다. iOS 심층 통합이 꽤 촘촘하게 구현돼 있어요.

Dynamic Island: 에이전트가 실행 중일 때 Dynamic Island에 실시간 상태가 표시됩니다. 다른 앱을 쓰다가도 진행 상황을 확인할 수 있습니다.

Lock Screen Live Activities: 잠금 화면에서도 에이전트 진행 상황을 추적합니다. 폰 들어서 잠금 화면만 켜도 "지금 어디까지 됐는지" 바로 보입니다.

보이스 인풋: 타이핑 없이 음성으로 에이전트에 지시를 넣을 수 있습니다. 걸으면서 "이 버그 고쳐줘"라고 말하는 게 실제로 가능해졌습니다.

이미지 어노테이션: 스크린샷을 캡처해서 동그라미를 치거나 코멘트를 추가해 에이전트에 시각적 피드백을 전달합니다. 디자인 수정 지시에 특히 유용합니다.

이 외에도 슬래시 커맨드로 에이전트 방향을 조정하거나, 에이전트 완료·입력 필요 시 Push Notification을 받을 수 있습니다.

Cursor for iOS 설치 방법과 이용 조건

앱 자체는 App Store에서 무료로 다운로드할 수 있습니다. 앱 ID는 6767085653, 개발사는 Anysphere입니다. 앱 크기는 77.5MB입니다.

단, 에이전트를 실제로 돌리려면 유료 Cursor 플랜이 필요합니다. 무료 플랜으로는 에이전트 기능을 쓸 수 없어요. 그리고 iOS 26.0 이상 기기가 필요합니다.

네이티브 앱 외에도 Safari에서 cursor.com/agents에 접속해 "홈 화면에 추가"로 PWA 방식으로 설치하는 방법도 있습니다. 공식 문서에는 두 방법이 모두 병기돼 있습니다. Android 지원은 2026년 7월 1일 기준 아직 없습니다.

출시와 함께 Composer 2.5 런 75% 할인 프로모션도 진행 중인데, 2026년 7월 5일까지입니다.

모바일 AI 코딩 실전 시나리오 3가지

Cursor 공식 블로그에서 제시한 사례들입니다.

온콜 장애 대응: 점심 먹다가 페이징이 울릴 때, 자리로 달려가지 않아도 됩니다. 폰에서 에이전트를 킥오프해서 장애 조사와 수정안 제안까지 받을 수 있습니다. 에이전트가 작업하는 동안 밥 먹고, 결과 알림 오면 검토하고 병합하면 됩니다.

고객 이슈 해결: 데스크톱 없이도 버그를 재현하게 하고, 코드를 검토하고, 수정안을 만들도록 에이전트를 시작할 수 있습니다. 이미지 어노테이션으로 "이 버튼이 이상함" 같은 피드백을 시각적으로 전달하는 것도 가능합니다.

디자인 피드백: SNS에서 본 레퍼런스 스크린샷을 캡처해서 에이전트에게 "이 느낌으로 수정해줘" 식의 UI 변경 지시를 넣을 수 있습니다.

개발자 중 한 명은 이 앱을 만든 이유를 이렇게 설명했습니다. "I built it because I wanted cursor on my phone because I have two small kids and don't want to be chained to my desk." 이 맥락이 앱의 존재 이유를 잘 압축하는 것 같습니다.

Cursor 모바일 앱, 아직 아쉬운 점

솔직하게 한계도 짚고 가야 합니다.

첫째, 유료 플랜 전용입니다. 클라우드 에이전트는 Max Mode 강제 적용이라 생각보다 과금이 빠를 수 있습니다. 무료로 "한번 써볼까" 하기가 어렵습니다.

둘째, iOS 26.0 이상이어야 합니다. 구형 기기 사용자는 아직 쓸 수 없습니다.

셋째, Android 지원이 없습니다. PWA 방식으로 cursor.com/agents에 접속하면 Android에서도 기본적인 웹 인터페이스는 쓸 수 있지만, Dynamic Island나 Live Activities 같은 네이티브 기능은 iOS 전용입니다.

Hacker News와 Reddit에서는 "Cursor가 IDE 정체성에서 멀어지고 있다"는 비판도 있습니다. 에이전트 중심 모델이 "코드 리뷰·테스트·컨텍스트 전환" 때문에 플로 상태 달성이 어렵다는 지적입니다. 코드를 직접 빠르게 작성하는 게 주 목적인 분이라면 이 앱의 효용이 제한적일 수 있습니다.

향후 로드맵

Cursor 공식 블로그에서 예고한 기능들입니다. 클라우드 에이전트 실행 경험이 로컬 머신 실행과 "구분 불가능한 수준"으로 개선될 예정이고, 코드베이스 컨텍스트가 필요 없는 작업을 시작하기 쉽게 하는 "레포지토리 없는 채팅(Repo-less chat)"도 추가될 예정입니다. MCP를 통해 Datadog, Slack 같은 외부 서비스 통합도 확대된다고 합니다.

지금 Cursor for iOS를 써볼 이유가 있는가

이 앱이 모든 개발자에게 필수는 아닙니다. 유료 플랜 쓰고 있고, 이미 AI 에이전트 중심으로 작업 흐름이 잡혀 있고, 외근이 많거나 "데스크톱에서 에이전트 돌려놓고 나갔다가 폰으로 확인하고 싶다"는 니즈가 있다면 지금 당장 써볼 만합니다.

App Store Developer Tools 카테고리에서 출시 직후 1위를 기록했을 정도로 반응은 뜨겁습니다. 현재 평점은 4.5/5(24개)입니다. 아직 공개 베타 단계라 기능이 빠르게 추가되고 있으니, 지금 설치해두고 로드맵 기능들이 추가되는 것을 지켜보는 것도 방법입니다.

Cursor 유료 플랜을 아직 고민 중이라면 이 블로그의 [Cursor AI 요금제 비교 2026] 글을 먼저 확인해보세요. 어떤 플랜이 본인 작업 스타일에 맞는지 정리해뒀습니다.

FAQ

Q. Cursor for iOS는 무료로 쓸 수 있나요?
앱 다운로드는 무료입니다. 하지만 클라우드 에이전트와 Remote Control 기능을 쓰려면 유료 Cursor 플랜 구독이 필요합니다. 무료 플랜으로는 에이전트 기능을 사용할 수 없습니다.

Q. Android는 언제 지원되나요?
2026년 7월 1일 기준 공식 Android 앱은 없습니다. cursor.com/agents를 Safari 외의 모바일 브라우저에서 접속하면 웹 인터페이스를 쓸 수는 있지만, iOS 네이티브 기능들은 사용 불가능합니다.

Q. 클라우드 에이전트 과금은 어떻게 되나요?
선택한 AI 모델의 API 사용량 기준으로 과금됩니다. 클라우드 에이전트는 Max Mode가 강제 적용되므로 일반 대화보다 비용이 더 나올 수 있습니다. 처음 사용 시 지출 한도를 설정해두는 것을 권장합니다.

Q. iOS 26.0보다 낮은 버전에서는 쓸 수 없나요?
네이티브 앱은 iOS 26.0 이상 필수입니다. 구형 기기라면 cursor.com/agents에서 PWA 방식으로 접근하는 것이 대안입니다.

스페이스X 커서(Cursor) 인수, 개발자에게 무슨 의미일까 (2026)

roundfigure — Wed, 1 Jul 2026 07:33:19 +0900

2026년 6월 16일, 스페이스X가 Cursor를 만든 Anysphere를 600억 달러에 인수한다는 소식이 떴습니다. 처음 헤드라인만 봤을 땐 "로켓 회사가 왜 코딩 에디터를?" 싶었는데, 막상 파보니 단순한 사업 다각화가 아니더라고요. 매일 Cursor 켜놓고 일하는 개발자라면 한 번쯤 짚고 넘어가야 할 변화입니다. 이번 인수가 실제로 무엇을 바꾸는지, 코드 작성 워크플로우에 어떤 영향을 줄지 정리해봤습니다.

스페이스X 로고와 Cursor 로고가 나란히 배치된 인수 발표 일러스트, 약 600억 달러 전액 주식 교환

스페이스X-커서 인수, 무슨 일이 있었나

스페이스X는 6월 16일 화요일, Anysphere를 인수하는 정식 계약을 체결했다고 발표했습니다. 금액은 약 600억 달러 상당의 스페이스X 클래스 A 보통주 전액 교환 방식이고요. 흥미로운 건 타이밍입니다. 스페이스X가 대규모 IPO를 마친 지 딱 나흘 만에 나온 발표였거든요.

인수 마감은 2026년 3분기로 예정돼 있고 규제 승인이 전제 조건입니다. 거래가 끝나면 Cursor는 스페이스X의 완전자회사가 됩니다. Anysphere 주주들은 7일 거래량가중평균가격(VWAP) 기준으로 산정된 스페이스X 주식을 받게 되고요.

사실 이건 완전히 새로운 거래는 아니었습니다. 2026년 4월, 스페이스X는 이미 약 100억 달러 규모 파트너십 또는 600억 달러 인수라는 옵션을 확보해둔 상태였거든요. 이번 발표는 그 옵션을 행사한 결과입니다. 스페이스X 공식 X 계정은 "세상에서 가장 유용한 AI 모델을 만들기 위해 Cursor 인수 옵션을 행사했다"고 밝혔고, Cursor CEO 마이클 트루엘도 "프론티어 AI 역량을 발전시키기 위해 스페이스X 팀과 긴밀히 협력하겠다"는 성명을 냈습니다.

2026년 4월 옵션 계약부터 6월 인수 발표까지 스페이스X-Cursor 인수 타임라인 다이어그램

스페이스X는 왜 코딩 에디터 회사를 샀을까

표면적으로는 어울리지 않는 조합이죠. 근데 맥락을 보면 그림이 좀 다르게 보입니다. 스페이스X는 2026년 2월에 이미 xAI를 인수했습니다. xAI는 연구자 이탈로 몸살을 앓았고, Grok 모델은 코딩 영역에서 OpenAI나 Anthropic에 밀린다는 평가를 받아왔습니다. 2025년 한 해 손실만 약 63억 5천만 달러였다는 보도도 있고요.

HackerNoon 분석이 정확히 짚은 부분인데, 이번 인수는 에디터 자체보다 "컴퓨트와 배포(distribution) 전략"에 가깝습니다. Cursor를 거쳐 Anthropic·OpenAI API로 흘러가던 매출을, 자체 Colossus 인프라와 Grok 모델 쪽으로 돌릴 수 있게 된 거죠. Cursor의 활성 개발자 사용자가 약 400만 명이라는 점도 빼놓을 수 없는 배경입니다. 컴퓨트, 모델, 배포 채널 — 이 세 가지가 한 회사 아래 묶이는 겁니다.

실제로 스페이스X와 Cursor는 인수 발표 전부터 협력 관계였습니다. 발표문에 따르면 지난 몇 달간 공동으로 모델을 학습시켜 왔고, 이 모델은 곧 Cursor와 Grok Build에 함께 출시될 예정이라고 합니다.

개발자가 가장 걱정하는 것 — 모델 중립성

저도 처음 이 소식을 듣고 가장 먼저 든 생각이 "그럼 이제 Cursor에서 Claude 못 쓰는 거 아니야?"였습니다. Cursor는 그동안 Claude, GPT, 자체 Composer 모델을 자유롭게 골라 쓸 수 있다는 "모델 중립성"을 핵심 무기로 내세워왔거든요. OpenAI의 두 차례 인수 제안을 거절하면서까지 독립성을 지켜온 회사였습니다.

근데 이제 IDE(Cursor)와 AI 모델(Grok), 클라우드 인프라(스페이스X)가 전부 한 회사 소유가 됩니다. 모델 중립성 때문에 Cursor를 선택했던 팀이라면 당연히 불안할 수밖에 없는 구조죠. 다만 현재 시점(인수 마감 전)까지는 Cursor가 기존대로 Claude·GPT·Composer를 그대로 지원하고 있다는 점은 확인해뒀습니다.

가격 쪽도 짚어볼 부분입니다. 현재 Cursor Pro는 월 20달러, Business는 사용자당 월 40달러입니다. 600억 달러라는 인수가는 매출 대비 약 15배 멀티플이라 상당히 높은 편인데, 이 정도 규모의 인수 이후엔 기업용 가격이 인상되는 경향이 역사적으로 있었다는 분석이 나옵니다. 다만 이건 업계 분석가들의 전망일 뿐, 스페이스X나 Cursor가 가격 인상을 공식 발표한 건 아닙니다.

Cursor Pro와 Business 요금제 비교, Claude·GPT·Composer 모델 지원 현황 표

락인 리스크, 진짜 위험은 따로 있다

분석 매체들이 이번 거래에서 "가장 저평가된 함의"로 꼽는 게 바로 락인(lock-in) 리스크입니다. IDE와 모델, 클라우드가 전부 한 회사 손에 들어가면, 도구 품질 자체보다 "내가 더 이상 선택권을 갖지 못한다"는 게 더 큰 위험이 된다는 지적이에요. 일부 분석에서는 독립성 우려 때문에 일부 사용자가 Claude Code나 오픈소스 도구로 옮겨갈 가능성도 언급됐는데, 이건 어디까지나 추정이고 실제 이탈 수치가 통계로 확인된 건 아닙니다.

제품 방향성 쪽에서는 이미 신호가 하나 나왔습니다. 6월 28일 일론 머스크는 xAI 신모델 Grok 4.5가 비공개 베타에 들어갔다고 발표했는데, 이 모델이 Cursor 데이터를 활용해 코딩·기술적 추론 능력을 강화하도록 설계됐다고 합니다. 인수 이후 처음으로 가시화된 모델 통합 사례인 셈이죠. 다만 Grok 4.5는 아직 공개 접근이 불가능하고 독립적인 벤치마크도 없는 상태라, 실력이 어느 정도인지는 더 지켜봐야 합니다.

개발자 커뮤니티 반응은 엇갈린다

Hacker News 반응을 보면 시각이 꽤 갈립니다. 일부는 재무적 관점에서 "스페이스X가 600억 달러짜리 옵션을 단 100억 달러에 확보한 셈"이라며 스페이스X에 유리한 거래라고 평가했고요. 한 시스템 엔지니어는 "프롬프트 엔지니어링이나 도구를 우회하는 작업 방식은 1년 안에 끝날 것"이라는 다소 비관적인 전망을 남기기도 했습니다.

흥미로운 건 주가 반응에 대한 보도가 정반대로 갈린다는 점입니다. Fortune은 인수 발표 후 스페이스X 주가가 약 16% 급등해 시가총액 기준 아마존·마이크로소프트를 제치고 미국 4위 기업이 됐다고 보도했는데, Hacker News에 올라온 한 글 제목은 "SpaceX Loses $600B After Announcing Acquisition of Cursor"입니다. 보도 시점이나 측정 기준(발표 당일 단기 급등 vs 이후 일정 기간의 누적 변화)이 달랐을 가능성이 있는데, 정확한 맥락 차이까지는 이번 정리에서 명확히 확인하지 못했습니다. 두 가지 보도가 모두 존재한다는 정도로만 받아들이는 게 안전할 것 같습니다.

2026년 AI 코딩 도구 지형, 결국 진영 싸움이다

이번 인수를 더 큰 그림에서 보면, 2026년 들어 약 90일이라는 짧은 기간 동안 AI 코딩 도구 시장이 빠르게 재편된 흐름의 일부입니다.

GitHub Copilot: 이미 Microsoft 소유. VS Code 생태계와 기업 계약에 단단히 통합돼 있고 사용자 2천만 명 이상으로 "엔터프라이즈 기본값" 포지션을 유지 중입니다.
Windsurf: OpenAI가 2026년 3월 약 30억 달러에 인수했습니다. 이 인수 이전에 2025년 협상이 한 차례 결렬되고 Google이 라이선스 계약으로 끼어드는 우여곡절도 있었습니다.
Claude Code: Anthropic이 직접 보유 중이고, Amazon·Google의 투자를 받았지만 상대적으로 독립성을 유지하고 있다고 평가받습니다. 어려운 문제를 풀 때 찾는 터미널 기반 자율 코딩 에이전트로 자리잡았습니다.
Cursor: 이번에 스페이스X 소유로 넘어가며 xAI의 Colossus 컴퓨트, Grok 모델과 결합되는 구조입니다.

DEV Community의 분석이 이 흐름을 잘 요약하는데, "2026년 어떤 코딩 도구를 쓸지는 점점 더 어떤 AI 생태계 안에서 살고 싶은지를 선택하는 문제가 되고 있다"고 정리합니다. 저도 이 말에 공감하는 게, 예전엔 "어떤 에디터가 자동완성을 더 잘하나"가 선택 기준이었다면, 이젠 "어느 회사의 생태계에 종속될 것인가"를 고민해야 하는 시대가 된 것 같아요.

참고로 Cursor의 매출 성장세도 이번 인수가가 왜 이렇게 높게 매겨졌는지 설명해줍니다. 2025년 1월 ARR 1억 달러에서 시작해 6월 5억 달러, 11월 10억 달러, 2026년 2월 20억 달러, 4월 30억 달러, 6월 초 40억 달러를 찍었거든요. 이 중 약 75%(약 26억 달러)가 엔터프라이즈 매출이고, 2026년 1분기 엔터프라이즈 매출은 전 분기 대비 3배 성장했다고 합니다. Slack, Zoom, Snowflake 같은 기존 SaaS 벤치마크를 능가하는 역대 최고속 성장이라는 평가가 나오는 이유입니다.

자주 묻는 질문

Q. Cursor에서 Claude나 GPT를 계속 쓸 수 있나요?
인수 마감(2026년 3분기) 전까지는 기존대로 Claude·GPT·Composer 모델을 그대로 지원하고 있습니다. 다만 인수 완료 이후 정책이 어떻게 바뀔지는 아직 공식 발표가 없습니다.

Q. Cursor 요금제가 오를까요?
스페이스X나 Cursor 측의 공식 가격 인상 발표는 없습니다. 다만 매출 대비 15배라는 높은 인수 멀티플을 근거로, 대형 인수 이후 기업용 가격이 오르는 경향이 있다는 업계 분석은 나와 있는 상태입니다.

Q. Cursor 대신 쓸 만한 대안이 있나요?
모델 중립성이 중요하다면 Anthropic이 독립적으로 운영하는 Claude Code, Microsoft 생태계라면 GitHub Copilot, OpenAI 진영이라면 Windsurf가 각각 다른 선택지로 거론됩니다.

결론 대신, 다음에 확인할 것들

인수 마감 시점인 2026년 3분기가 가까워지면 실제 정책 변화가 구체적으로 나올 가능성이 큽니다. 모델 선택 옵션이 줄어드는지, 가격이 실제로 오르는지, Grok 4.5가 공개 벤치마크에서 어떤 성적을 내는지 — 이 세 가지가 앞으로 지켜봐야 할 핵심 신호입니다. 지금 당장 Cursor를 갈아탈지 고민하는 단계는 아니지만, 팀 단위로 도구를 쓰고 있다면 이번 분기 안에 정책 변화 공지를 한 번씩 챙겨보시는 걸 추천합니다.

MCP 서버 직접 만들기: Claude Code에서 나만의 도구 연결하는 단계별 가이드 (초보자용)

roundfigure — Tue, 30 Jun 2026 10:22:14 +0900

"Claude Code에서 내가 만든 함수를 AI가 직접 호출하게 할 수 있다고?"

저도 처음 MCP 개념을 접했을 때 반신반의했습니다. 근데 실제로 해보니까 생각보다 훨씬 간단했어요. Python 파일 하나, 명령어 한 줄이면 됩니다. 이 글에서는 MCP 서버가 뭔지 짧게 짚고, Python으로 서버를 만든 다음 Claude Code에 연결하는 전체 과정을 순서대로 정리했습니다. 중간에 막히는 포인트도 같이 다룹니다.

MCP 아키텍처 다이어그램 — Host(Claude Code), Client(내부 컴포넌트), Server(사용자 제작 도구)의 3계층 흐름도

MCP가 뭔지 30초만에 이해하기

MCP(Model Context Protocol)는 Anthropic이 2024년 오픈소스로 공개한 프로토콜입니다. 공식 문서에서 "AI용 USB-C 포트"라고 표현하는데, 딱 맞는 비유예요. USB-C가 노트북이든 폰이든 어댑터 없이 꽂히듯, MCP는 Claude Code가 어떤 외부 도구든 같은 방식으로 연결하게 해줍니다.

구조는 세 계층입니다.

MCP Host: AI 앱 자체. Claude Code, Claude Desktop, VS Code 같은 것들.
MCP Client: Host 내부에서 서버와 1:1로 붙는 컴포넌트. SDK가 알아서 처리해줘서 신경 안 써도 됩니다.
MCP Server: 여러분이 만들 프로그램. 도구(Tools), 리소스(Resources), 프롬프트(Prompts)를 Claude에 제공하는 역할.

2026년 현재 공개된 MCP 서버가 13,000개를 넘겼고, Claude·ChatGPT·VS Code·Cursor 등 주요 플랫폼이 전부 지원합니다. 이미 사실상의 표준이 됐습니다.

Python으로 MCP 서버 만들기 (FastMCP)

환경 준비

Python 3.10 이상이 필요합니다. 패키지 매니저는 uv를 씁니다. pip보다 빠르고, MCP 공식 문서도 uv를 기본으로 안내합니다.

# uv 설치 (Windows PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

# 프로젝트 생성
uv init my-mcp-server
cd my-mcp-server
uv venv
.venv\Scripts\activate    # Windows
# source .venv/bin/activate  # macOS/Linux

uv add "mcp[cli]"

SDK 버전은 stable 기준 1.x입니다. 2.0.0a3 같은 pre-release 버전은 프로덕션에서 쓰지 마세요.

가장 간단한 서버: 두 수를 더하는 도구

# server.py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def add(a: int, b: int) -> int:
    """두 정수를 더한다."""
    return a + b

if __name__ == "__main__":
    mcp.run(transport="stdio")

@mcp.tool() 데코레이터 하나로 함수가 도구로 등록됩니다. Python 타입 힌트와 docstring으로 JSON 스키마가 자동 생성되기 때문에, 스키마를 손으로 작성할 필요가 없어요. FastMCP가 다 해줍니다.

VS Code 터미널에서 uv add mcp 설치 후 server.py를 실행하는 화면

외부 API를 쓰는 서버 예시

실제로 쓸 만한 건 HTTP 요청이 들어갑니다. httpx를 추가로 설치하면 됩니다.

uv add httpx

# weather.py
from typing import Any
import httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")
NWS_API_BASE = "https://api.weather.gov"

async def make_nws_request(url: str) -> dict[str, Any] | None:
    headers = {"User-Agent": "weather-app/1.0", "Accept": "application/geo+json"}
    async with httpx.AsyncClient() as client:
        try:
            response = await client.get(url, headers=headers, timeout=30.0)
            response.raise_for_status()
            return response.json()
        except Exception:
            return None

@mcp.tool()
async def get_alerts(state: str) -> str:
    """미국 주별 기상 경보 조회. state: 두 글자 주 코드 (예: CA, NY)"""
    url = f"{NWS_API_BASE}/alerts/active/area/{state}"
    data = await make_nws_request(url)
    if not data or "features" not in data:
        return "경보 정보를 가져올 수 없습니다."
    if not data["features"]:
        return "해당 주에 활성 경보 없음."
    return f"{len(data['features'])}개 경보 발견"

def main():
    mcp.run(transport="stdio")

if __name__ == "__main__":
    main()

서버 실행: uv run weather.py

Claude Code에 MCP 서버 연결하기

서버 파일을 만들었으면 Claude Code에 등록해야 합니다. 명령어 한 줄입니다.

# 로컬 stdio 서버 등록
claude mcp add my-server -- python /절대경로/server.py

# uv로 실행하는 경우
claude mcp add my-server -- uv --directory /절대경로/프로젝트 run server.py

# 등록 확인
claude mcp list

절대경로를 써야 한다는 점이 중요합니다. MCP 클라이언트가 서버를 시작할 때 작업 디렉터리가 예측 불가능해서, 상대경로(./server.py)로 쓰면 연결에 실패할 수 있어요.

스코프 설정: 나만 쓸지, 팀이랑 쓸지

# 내 모든 프로젝트에서 사용 (user 스코프)
claude mcp add --scope user my-server -- python /절대경로/server.py

# 팀 전체와 공유 (project 스코프 → .mcp.json 생성 → git 커밋)
claude mcp add --scope project my-server -- python /절대경로/server.py

스코프	저장 위치	적용 범위
local (기본)	`~/.claude.json`	나, 현재 프로젝트만
user	`~/.claude.json`	나, 모든 프로젝트
project	`.mcp.json` (프로젝트 루트)	git 커밋하면 팀 전체

claude mcp list 실행 결과 터미널 화면 — Connected 상태 표시

초보자가 반드시 알아야 할 실수 3가지

1. STDIO 서버에서 print() 쓰기 (가장 흔한 실수)

STDIO 트랜스포트는 표준 입출력 스트림으로 통신합니다. print()로 stdout에 뭔가를 출력하는 순간 JSON-RPC 스트림이 오염되고, 연결이 끊깁니다. 공식 문서도 명시적으로 경고하는 내용입니다.

# 잘못된 방법
print("처리 중...")          # stdout → 프로토콜 파괴

# 올바른 방법
import sys
print("처리 중...", file=sys.stderr)   # stderr로만 출력

import logging
logging.info("처리 중...")  # logging은 기본적으로 stderr 사용

저도 처음에 이거 때문에 한참 헤맸습니다. 연결은 되는데 도구 호출하면 계속 오류 나는 상황이면 일단 print()부터 확인하세요.

2. 코드 수정 후 재시작 안 하기

server.py를 수정하고 Claude Code를 그냥 두면 변경사항이 반영되지 않습니다. MCP 클라이언트(Claude Code)를 완전히 재시작해야 해요. 창만 닫는 게 아니라 프로세스 종료 후 재실행까지 해야 합니다.

3. 환경 변수 빠뜨리기

API 키 같은 환경 변수는 STDIO 서버에 자동 상속되지 않습니다. .mcp.json에 명시적으로 넣어줘야 해요.

{
  "mcpServers": {
    "my-server": {
      "command": "python",
      "args": ["/절대경로/server.py"],
      "env": {
        "MY_API_KEY": "실제_키값"
      }
    }
  }
}

만든 서버, 어디서 디버깅하나

개발 중엔 MCP Inspector를 씁니다. 브라우저에서 서버를 직접 테스트할 수 있어요.

npx @modelcontextprotocol/inspector uv run server.py

연결 상태는 Claude Code 세션 안에서 /mcp 명령으로 확인합니다. ✓ Connected면 정상, ✗ Failed to connect면 서버 명령어를 직접 터미널에서 실행해서 오류 메시지를 확인하세요.

서버를 완성했다면, 다음 단계는

혼자 쓸 도구면 .mcp.json에 등록해서 git으로 팀과 공유하면 됩니다. 공개 배포까지 생각하면 npm 패키지(npx로 설치 없이 실행)나 PyPI 패키지(uvx로 실행) 형태로 만드는 게 편합니다.

2026년 6월 기준으로 Smithery(smithery.ai)에는 7,300개 이상의 MCP 서버가 등록돼 있고, 월 43만 명의 개발자가 사용 중입니다. 원격 HTTP 서버를 만들어 배포하려면 VPS가 필요한데, Vultr처럼 저렴하게 시작할 수 있는 옵션을 쓰는 개발자들이 많습니다.

FastMCP로 10줄짜리 서버 하나 만들어보는 게 이 모든 것의 시작입니다. 직접 해보면 "이게 이렇게 간단했어?" 싶을 거예요.

관련해서 읽어볼 글

Claude Code 기본 사용법 정리
MCP 공식 레지스트리에서 도구 찾는 법

Claude Code vs Devin 비교 2026 — 실제로 써보니 이게 달랐다

roundfigure — Tue, 30 Jun 2026 01:37:55 +0900

둘 다 "$20/월에 AI 개발자"를 내세운다. 근데 실제로 써보면 완전히 다른 물건이다. Claude Code와 Devin 2.0은 겉보기엔 비슷한 가격대로 출발하지만, 철학 자체가 다르다. 저도 처음엔 그냥 "AI 코딩 도구 두 개 중에 더 좋은 거 하나 고르면 되겠지" 싶었는데, 막상 써보고 나니 질문 자체를 바꿔야 했어요.

Claude Code vs Devin 핵심 차이 비교 카드

Devin 2.0이 뭔지부터 — 진짜 자율 AI 엔지니어

Devin은 Cognition AI가 만든 자율 AI 소프트웨어 엔지니어다. 2024년 처음 공개될 때 "세계 최초 자율 AI 개발자"라는 타이틀로 화제를 모았고, 2025년 말~2026년 초에 Devin 2.0으로 업그레이드됐습니다.

작동 방식이 다른 도구들과 근본적으로 다르다. 사용자가 Slack이나 Jira 티켓으로 작업을 넘기면, Devin이 클라우드 샌드박스에서 혼자 계획을 세우고, 코드를 쓰고, 테스트를 돌리고, PR을 올립니다. 사용자가 할 일은 결과물인 PR을 검토하는 것뿐. 그동안 회의를 해도 되고 다른 작업을 해도 된다는 게 핵심 셀링포인트예요.

Devin 2.0에서 눈에 띄는 기능은 크게 두 가지다. 첫째는 병렬 세션 — 여러 Devin 인스턴스를 동시에 돌려서 티켓 여러 개를 동시에 처리할 수 있어요. 둘째는 Devin Wiki — 코드베이스 전체를 자동 분석해서 아키텍처 문서를 만들고 몇 시간마다 업데이트한다. 600만 줄 코드를 가진 Nubank가 Devin으로 대규모 마이그레이션을 했을 때 "엔지니어링 시간 8~12배 향상, 비용 20배 이상 절감"이라는 결과를 발표한 것도 이런 병렬 처리 능력 덕분입니다.

Claude Code가 뭔지 — 터미널에서 함께 일하는 파트너

Claude Code는 Anthropic이 만든 터미널 기반 AI 코딩 어시스턴트다. 핵심 차이는 "로컬에서 개발자와 함께"라는 점이에요. Devin이 클라우드 샌드박스에서 혼자 일하는 반면, Claude Code는 내 터미널, 내 파일시스템, 내 Git 저장소에 직접 붙어서 같이 작업합니다.

작업 방식도 다르다. 명령을 입력하면 Claude가 코드베이스를 탐색하고 (README → import 추적 → 관련 모듈 순으로), 파일을 수정하고, 테스트를 실행하고, 커밋을 만든다. 이 과정이 대화처럼 이어지기 때문에 "어, 그쪽 방향이 아니라 이쪽으로" 하고 중간에 방향을 바꾸는 게 자연스럽습니다.

200K 토큰 컨텍스트 윈도우(Max 플랜 기준)는 실제로 체감된다. 대형 코드베이스에서도 앞서 논의한 내용을 잊지 않고 이어가는 게 인상적이에요. VS Code·JetBrains 확장도 지원하고, MCP로 외부 도구를 연동해서 확장할 수 있습니다.

가격이 같아 보이는데, 실제로는 얼마나 다를까

Devin vs Claude Code 가격 비교 표

여기서부터 이야기가 복잡해진다. 둘 다 "$20/월부터"라고 마케팅하는데, 실제 구조가 꽤 다릅니다.

Devin의 가격 구조

플랜	월 비용	추가 ACU 단가
Core	$20	$2.25/ACU
Team	$500	$2.00/ACU
Enterprise	협의	협의

여기서 ACU(Agentic Computing Unit)가 핵심이다. 1 ACU는 대략 15분의 활성 자율 작업을 의미하는데, 작업 종류별로 소비량이 다릅니다.

버그 수정 1건: 1~3 ACU → $2.25~$6.75
기능 구현 1건: 5~10 ACU → $11.25~$22.50

즉, Core $20은 사실상 "입장권"에 가까워요. 실제로 팀 단위로 쓰면 월 $100~$500+ 지출을 예상해야 한다는 분석이 많습니다. 반면 Claude Code는 Max 5x($100/월)나 Max 20x($200/월)로 사용량 상한선이 명확하다. 어느 쪽이 예산 관리에 유리한지는 팀마다 다르겠지만, 예측 가능성 면에서는 Claude Code가 낫습니다.

Claude Code 가격

플랜	월 비용
Pro	$20
Max 5x	$100
Max 20x	$200
Team Standard	$25/seat

코드 실력은 숫자로 — SWE-bench 비교

SWE-bench Verified 점수 비교 바 차트

SWE-bench Verified는 실제 GitHub 이슈 500개를 기반으로 한 코딩 에이전트 표준 벤치마크다. 점수가 높을수록 실제 오픈소스 버그를 잘 고친다는 의미예요.

결과가 꽤 뚜렷하다.

Claude Code (Opus 4.8): 88.6% — 실제 GitHub 이슈 약 9개 중 8개 이상 자율 해결
Devin 2.0: 45.8% — 실제 GitHub 이슈 약 절반 자율 해결

두 배 가까운 차이다. 근데 솔직히 이 수치만 보고 "Claude Code가 무조건 낫다"고 결론 내리면 조금 성급해요. Devin의 강점은 점수가 아니라 운영 방식에 있거든요.

실제로 잘하는 작업이 다르다

사용해 보면서 가장 명확히 느낀 건 이거다. 두 도구는 경쟁 관계가 아니라 잘 맞는 작업 유형이 다르다.

Devin이 빛나는 순간

백로그에 쌓인 의존성 업그레이드 (Node.js 모듈 38개 → 주말 동안 31개 자율 완료라는 사례 있음)
레거시 코드 마이그레이션 (COBOL, Fortran → Python, Go 같은 작업)
회의 중에 처리하고 싶은 4시간짜리 기계적인 PR
반복적인 테스트 생성, 문서화

명확하게 정의된 작업, 목적지가 정해진 작업에서 강하다. 혼자 해결하고 결과만 가져오니까요.

Claude Code가 빛나는 순간

원인을 모르는 버그 조사 (대화하면서 좁혀나가는 과정)
아키텍처 결정이 필요한 리팩토링
"이렇게 하면 어때?" 하고 의견을 들으면서 방향 잡는 작업
새로운 문제 해결

판단이 필요한 작업, 목적지가 흐릿해서 같이 찾아가야 하는 작업에서 강하다. G2 리뷰 15개 평균이 4.9/5라는 것도, 복잡한 작업에서의 추론 능력을 높이 산 평가가 많습니다.

Devin의 실패 패턴도 알아두면 좋다. 500K LOC(줄 수)를 넘는 모노레포에서 실패율이 소규모 저장소의 약 2배로 올라가고, 모호하거나 아키텍처 중심 문제에서 비용이 급증한다는 사례가 보고되고 있어요.

내 상황에 맞는 선택 — 어떤 팀에 뭐가 맞나

팀 규모별 AI 코딩 에이전트 선택 가이드

솔직하게 정리하면 이렇다.

1인 개발자·프리랜서 → Claude Code Pro($20)
Devin의 ACU 구조는 개인 규모에서 비효율적이다. 하나씩 대화하면서 작업하는 게 맞는다.

5~15인 스타트업 팀 → 둘 다 써보는 게 낫다
Devin으로 티켓 백로그를 처리하고, Claude Code로 판단이 필요한 작업을 하면 서로 보완이 된다. 실제로 이렇게 병행 사용하는 팀이 늘고 있어요.

엔터프라이즈(50인 이상) → Devin 중심 + Claude Code 보완
대규모 병렬 처리 경제성은 Devin이 압도적이다. Nubank 사례처럼 수백만 줄 규모의 마이그레이션이 필요하다면 Devin이 답이 될 수 있어요.

자주 묻는 질문

Q. Devin $20 플랜은 정말로 쓸 만한가요?
입문용으로는 시도해볼 만하지만, 실제 팀 작업에 쓰려면 ACU 비용이 빠르게 누적됩니다. 개인이 단순 작업 몇 건 테스트하는 용도라면 괜찮지만, 예산이 빠듯한 팀이라면 Claude Code Max($100)가 비용 예측이 더 쉽습니다.

Q. Claude Code와 Devin 중 코드 품질은 어느 쪽이 높나요?
벤치마크 기준으로는 Claude Code(SWE-bench 88.6%) vs Devin(45.8%)으로 Claude Code가 앞선다. 다만 Devin은 품질보다 자율 운영 능력에 강점이 있어서, 단순히 점수로만 비교하기는 어렵습니다.

Q. 두 도구를 동시에 쓰는 게 가능한가요?
가능하고, 오히려 권장하는 팀도 많습니다. Devin을 백그라운드에서 티켓 처리용으로, Claude Code를 포그라운드 심도 작업용으로 운영하면 서로의 약점을 보완할 수 있습니다.

비슷해 보이는 두 도구지만 실제로 해결하려는 문제가 다르다. "AI 엔지니어에게 작업을 위임하고 싶다"면 Devin, "AI와 함께 생각하면서 코드를 짜고 싶다"면 Claude Code가 더 잘 맞습니다. 어느 쪽을 선택하든, 실제 작업에 하루 이틀만 써보면 금방 감이 온다. 직접 돌려보는 게 가장 빠른 답이에요.

Claude Code를 더 잘 쓰고 싶다면 Claude Code Hooks 완벽 가이드나 서브에이전트 심화 가이드도 블로그에서 찾아볼 수 있습니다.

Cursor Rules vs CLAUDE.md — AI 지시 파일 완전 비교 2026

roundfigure — Mon, 29 Jun 2026 19:56:35 +0900

Cursor를 쓰면 .cursor/rules/에 규칙을 넣고, Claude Code를 쓰면 CLAUDE.md에 지침을 쓴다. 둘 다 "AI한테 이렇게 코딩해줘"를 전달하는 파일인데, 구조도 다르고 동작 방식도 꽤 다릅니다. 저도 처음엔 두 파일이 어떻게 다른지 정확히 몰라서 대충 비슷한 내용을 두 군데 복붙해뒀었는데, 그게 최선이 아니더라고요. 이 글에서는 Cursor Rules와 CLAUDE.md를 실제 파일 구조부터 동작 원리, 각각의 한계까지 비교해서 어떤 상황에 뭘 쓸지 정리해봤습니다.

Cursor Rules와 CLAUDE.md 핵심 차이점 한눈에 보기 비교 인포그래픽

Cursor Rules란? .cursorrules vs .mdc 파일 차이부터

Cursor IDE에서 AI 동작 방식을 커스터마이즈하는 지시 파일 시스템입니다. 개발자가 규칙을 작성하면 Cursor의 AI 컨텍스트에 주입되어, 코딩 표준이나 프레임워크 규칙 같은 걸 AI가 자동으로 따르게 됩니다.

파일 형식이 두 가지입니다.

현대 방식 (.mdc, 2025년 이후 권장)

.cursor/
└── rules/
    ├── base.mdc          # 항상 적용
    ├── frontend.mdc      # 프론트엔드 파일에만 적용
    └── api.mdc           # API 파일에만 적용

확장자가 .mdc여야 합니다. .md로 만들면 그냥 무시됩니다. YAML 프론트매터로 4가지 활성화 모드를 제어할 수 있어서, 파일 패턴이 매칭될 때만 규칙이 적용되도록 설정할 수 있습니다.

모드	조건	설명
Always Apply	`alwaysApply: true`	모든 대화에 항상 로드 (200단어 이하 권장)
Auto Attached	`globs` 설정	매칭 파일이 컨텍스트에 있을 때 자동 로드
Agent Requested	`description`만 설정	AI가 작업 컨텍스트 보고 스스로 판단
Manual	둘 다 없음	`@rule-name`으로 명시적 참조 시에만 로드

레거시 방식 (.cursorrules)

프로젝트 루트에 단일 파일로 두는 방식입니다. 단순하긴 한데, 치명적인 문제가 하나 있어요. Agent 모드에서 무시됩니다. 에이전틱 워크플로우로 전환하는 순간 이 파일 전체가 로드되지 않습니다. 2026년 기준으로 커뮤니티 예제 대부분이 아직도 .cursorrules 기반인데, 이걸 모르고 계속 레거시 방식 쓰다가 "왜 규칙이 안 먹히지?" 하고 당황하는 케이스가 꽤 있습니다.

Cursor Rules의 주요 한계를 정리하면 이렇습니다.

.cursorrules는 Agent 모드에서 무시됨 (위 설명 참고)
Cursor Tab(자동완성)과 Inline Edit(Cmd+K)에는 규칙이 아예 적용 안 됨
파일당 최대 500줄 권장 — 초과하면 컨텍스트 우선순위가 낮아짐
Always Apply 규칙은 매 요청마다 토큰을 소모, 과하면 컨텍스트 창이 빨리 찹니다
Cursor 전용 — 도구 전환 시 마이그레이션 필요

CLAUDE.md란? 계층형 로딩 구조가 핵심

Claude Code가 세션 시작 시 자동으로 읽는 마크다운 파일입니다. 특수 문법이 없어요. 순수 마크다운으로 쓰면 됩니다. 저는 이 단순함이 처음엔 "기능이 없는 건가?" 싶었는데, 사실은 구조적으로 더 풍부합니다.

CLAUDE.md 계층형 로딩 구조 다이어그램 — Managed Policy부터 Local까지 5단계

파일 계층 구조 (로드 순서)

범위	위치	용도
Managed Policy	`/etc/claude-code/CLAUDE.md`	조직 전체 IT/DevOps 관리 지침
User	`~/.claude/CLAUDE.md`	개인 전역 선호 설정
Project	`./CLAUDE.md`	팀 공유 프로젝트 지침 (버전 관리)
Local	`./CLAUDE.local.md`	개인 프로젝트 설정 (gitignore 권장)
서브디렉터리	`./src/CLAUDE.md` 등	해당 디렉터리 파일을 열 때 온디맨드 로드

오버라이드가 아니라 누적 방식입니다. 발견된 파일을 전부 이어붙여서 컨텍스트에 로드합니다.

CLAUDE.md만의 기능 몇 가지를 보면:

@path 임포트 문법

프로젝트 개요는 @README를 참고.
npm 명령어는 @package.json 확인.
git 워크플로우: @docs/git-instructions.md

최대 4단계 재귀 임포트가 됩니다. 단, 임포트된 파일도 전부 로드되기 때문에 컨텍스트 절약 효과는 없습니다.

Auto Memory (v2.1.59 이상 기본 활성화)

Claude가 세션 중 스스로 학습한 내용을 ~/.claude/projects/<project>/memory/에 저장합니다. 빌드 명령어, 디버깅 패턴, 코드 스타일 선호 같은 것들을 자동으로 기록해두는 거예요. /memory 명령어로 현재 세션에 로드된 파일을 확인하거나 수정할 수도 있습니다.

CLAUDE.md의 한계도 있습니다.

지침은 권고이지 강제가 아님 — 규칙 위반을 막으려면 Hook을 써야 합니다
파일당 200줄 이하 권장, 초과 시 준수율이 떨어집니다
/compact 후 서브디렉터리 CLAUDE.md는 자동 재주입되지 않음
Claude Code 전용 — Cursor, Copilot 등에서는 인식 안 됩니다

Cursor Rules vs CLAUDE.md 핵심 차이점 비교

Cursor Rules vs CLAUDE.md 기술적 차이점 비교 표 — 주입 타이밍, 세션 지속성, 파일 임포트 등

가장 중요한 차이는 주입 타이밍입니다.

Cursor는 매 인라인 편집 요청마다 새 시스템 프롬프트를 생성해서 규칙을 매번 주입합니다. Claude Code는 세션 시작 시 한 번 컨텍스트에 로드합니다. 이 구조 차이가 각 파일의 최적 작성 스타일을 결정합니다.

항목	Cursor Rules	CLAUDE.md
적용 도구	Cursor IDE 전용	Claude Code 전용
파일 확장자	`.mdc` (현대), `.cursorrules` (레거시)	`.md` (표준 마크다운)
특수 문법	YAML 프론트매터	없음
주입 타이밍	매 요청마다 새로 주입	세션 시작 시 한 번 로드
계층 구조	3단계 (Global > Project > Directory)	5단계 (Managed > User > Project > Local + 서브디렉터리)
파일 임포트	지원 안 함	`@path` 문법 (최대 4단계 재귀)
자동 메모리	없음	Auto Memory 내장
경로 스코핑	`globs` 프론트매터	`paths` 프론트매터 (`.claude/rules/`)
최적 작성 스타일	짧고 명령형 ("Tailwind만 사용")	서술형 배경 + 명확한 규칙 혼합
커뮤니티 예제 수	2,000+	500+

이 표에서 "최적 작성 스타일" 부분이 실전에서 가장 체감이 큰 차이입니다. Cursor는 짧고 강한 명령형이 잘 먹히고, CLAUDE.md는 배경 맥락과 아키텍처 의도를 서술형으로 담아줄 때 효과가 좋습니다.

Cursor Rules vs CLAUDE.md — 어떤 상황에 어느 파일을 써야 할까?

Cursor Rules가 맞는 경우

Cursor IDE를 주 편집기로 쓰고 Claude Code는 쓰지 않는 경우
파일 타입별로 세밀한 규칙 스코핑이 필요한 경우 (API 파일 vs 컴포넌트 파일별로 다른 규칙)
팀 전체가 Cursor를 쓰고 있어 커뮤니티 예제를 바로 가져다 쓰고 싶은 경우

CLAUDE.md가 맞는 경우

Claude Code를 터미널 기반 주요 AI 코딩 도구로 쓰는 경우
장시간 세션에서 아키텍처 설명, 코드베이스 배경, 위험 구역 설명 같은 서술형 컨텍스트가 필요한 경우
Auto Memory로 Claude가 프로젝트를 점진적으로 학습하길 원하는 경우
조직 전체 Managed Policy로 사내 표준을 강제해야 하는 경우

둘 다 써야 하는 경우

솔직히 2026년에 가장 흔한 패턴은 두 파일을 동시에 유지하는 것입니다. 각 도구는 자신의 파일만 읽습니다. Cursor는 .cursor/rules/*.mdc와 .cursorrules만 읽고, Claude Code는 CLAUDE.md와 .claude/rules/*.md만 읽습니다. 충돌이 없어요.

팀 내에 Cursor 사용자와 Claude Code 사용자가 섞여 있거나, Cursor를 인라인 편집기로 쓰고 Claude Code를 터미널에서 대형 작업·아키텍처·테스트 생성에 병행하는 경우라면 두 파일을 모두 관리하는 게 자연스럽습니다.

Cursor Rules와 CLAUDE.md 동시 관리 전략 3가지

AGENTS.md 공통 기반으로 Cursor Rules와 CLAUDE.md를 함께 관리하는 폴더 구조 다이어그램

전략 1: 독립 유지

각 파일을 별도로 관리하되, 내용의 약 90%를 동일하게 유지하고 도구별 특화 기능만 분리합니다. 가장 단순한 방법이에요.

전략 2: AGENTS.md 공통 기반 활용

2026년 신흥 표준으로 AGENTS.md(Linux Foundation, 60,000+ 레포 사용)가 부상하고 있습니다. 공통 지침을 AGENTS.md에 두고, CLAUDE.md에서 @AGENTS.md로 임포트하고, Cursor Rules의 base.mdc에도 핵심 내용을 가져오는 방식입니다.

# CLAUDE.md
@AGENTS.md

## Claude Code 전용
billing 디렉터리 변경 시 플랜 모드 사용.

중복 업데이트가 줄어드는 게 장점입니다. 참고로 Claude Code의 /init 명령어를 실행하면 기존 .cursorrules나 AGENTS.md 내용을 읽어서 CLAUDE.md 생성에 활용해줍니다.

전략 3: pre-commit 훅으로 동기화

소스 파일 하나를 유지하고 커밋 전 자동으로 각 형식으로 내보내는 방식. 개발 팀 규모가 크거나 파일 관리를 자동화하고 싶을 때 적합합니다.

FAQ

Q. .cursorrules를 아직 쓰고 있는데, .mdc로 꼭 바꿔야 하나요?

Agent 모드를 사용하지 않는다면 단기적으로는 괜찮습니다. 하지만 Cursor의 공식 권장은 2025년부터 .mdc 방식이고, Agent 모드에서 .cursorrules가 완전히 무시되는 건 실제로 꽤 치명적입니다. 마이그레이션하는 편이 낫습니다.

Q. Cursor를 쓰면서 Claude Code 확장도 같이 쓰는데, CLAUDE.md를 Cursor Rules처럼 쓸 수 있나요?

Cursor 에디터에서 Claude Code 확장을 쓰는 경우 .cursor/rules/와 CLAUDE.md를 동시에 가지는 설정을 운용하는 개발자들이 있습니다. 각 시스템이 자신의 파일만 읽기 때문에 충돌은 없습니다.

Q. AGENTS.md를 공통 기반으로 쓰면 Cursor Rules와 CLAUDE.md를 다 대체할 수 있나요?

대체는 어렵습니다. AGENTS.md가 아직 Claude Code와 Cursor의 특화 기능을 완전히 대체하지 못합니다. CLAUDE.md의 Auto Memory, Cursor Rules의 4가지 활성화 모드 같은 기능은 도구별 파일을 써야만 쓸 수 있습니다. AGENTS.md는 공통 기반, 도구별 파일은 그 위에 올리는 레이어로 보는 게 현실적입니다.

지금 바로 해볼 것

둘 중 하나만 쓰고 있다면 지금 어떤 방식인지부터 점검해봐요. 특히 .cursorrules를 쓰고 있다면 Agent 모드에서 규칙이 먹히는지 확인해보는 게 먼저입니다. Cursor와 Claude Code를 병행한다면 전략 2(AGENTS.md 공통 기반)를 한 번 시도해볼 만합니다. 공통 지침을 한 곳에 관리하는 것만으로도 중복 업데이트 부담이 확 줄어듭니다.

각 파일의 상세 설정 방법이 궁금하다면 [cursorrules 가이드]나 [Claude Code CLAUDE.md 완벽 가이드 2026]도 참고해보세요.

Claude Code Skills 완벽 가이드 2026 — 슬래시 커맨드로 반복 작업 자동화하기

roundfigure — Mon, 29 Jun 2026 09:36:54 +0900

매번 같은 코드 리뷰 지침을 채팅창에 복붙하고 있다면, 그게 바로 Claude Code Skills를 써야 하는 신호입니다. 저도 처음엔 "그냥 프롬프트 아니야?" 싶었는데, 직접 써본 결과 반복 작업 방식이 완전히 달라졌어요. Skills는 단순한 프롬프트 저장소가 아니라, /skill-name 하나로 호출하는 재사용 워크플로우 패키지입니다. 2025년 10월 공식 출시 이후 2026년 2월에는 'Skills 2.0'으로 진화해 실행 스크립트까지 포함한 실제 산출물 생성 워크플로우가 됐어요.

Claude Code 터미널에서 /code-review 슬래시 커맨드를 입력하는 화면

Skills가 CLAUDE.md와 다른 이유

CLAUDE.md는 세션 시작할 때 항상 로드됩니다. 프로젝트 규칙이나 사실 정보처럼 "항상 알고 있어야 하는 것"을 넣는 파일이에요. 반면 Skills는 호출할 때만 컨텍스트에 로드됩니다.

공식 문서는 이렇게 설명합니다. "같은 지침, 체크리스트 또는 다단계 절차를 계속 채팅에 붙여넣거나, CLAUDE.md의 섹션이 사실이 아닌 절차로 성장했을 때 skill을 생성하라." 결국 CLAUDE.md가 무거워지기 시작하면 Skills로 분리하라는 뜻이죠.

컨텍스트 비용 차이도 실질적입니다. 필요할 때만 로드하기 때문에 토큰 비용을 30~50% 절감한 사례가 보고됐어요. 긴 체크리스트나 다단계 절차는 항상 올라가 있을 필요가 없으니까요.

내장 커맨드(/help, /compact)와도 다릅니다. 내장 커맨드는 고정 로직이 즉시 실행되지만, Skills는 프롬프트 기반으로 Claude가 실제로 도구를 사용해 작업을 조율합니다. 같은 /code-review를 써도 상황마다 결과가 달라질 수 있는 이유가 여기 있어요.

CLAUDE.md vs Skills vs 내장 커맨드 차이점 비교표

기본 내장 번들 Skills 7가지

Claude Code를 설치하면 별도 설정 없이 바로 쓸 수 있는 번들 Skills가 있습니다. disableBundledSkills 설정으로 끄지 않는 한 모든 세션에서 사용 가능해요.

스킬	기능
`/code-review`	코드 정확성, 보안, 스타일 검토
`/batch`	대규모 변경을 독립 단위로 분해해 병렬 실행
`/debug`	도구 호출 실패나 컨텍스트 혼란 진단
`/loop`	반복 주기로 프롬프트 실행 (예: "5분마다 오류 확인")
`/claude-api`	Claude API 구현 참조 자료 로드
`/run`	프로젝트 유형을 자동 인식해 앱 실행 (v2.1.145 이상)
`/verify`	코드 변경이 의도대로 동작하는지 실제로 확인 (v2.1.145 이상)

/batch가 특히 인상적인데, 수백 파일에 걸친 변경을 각각 격리된 git worktree에서 병렬로 처리해 줍니다. 대규모 리팩토링할 때 충돌 걱정 없이 돌릴 수 있어요.

커스텀 Skills를 5분 만에 만드는 법

커스텀 스킬은 파일 하나면 됩니다. ~/.claude/skills/<skill-name>/SKILL.md 경로에 파일을 만들면 즉시 슬래시 커맨드로 호출할 수 있어요. Claude Code 재시작도 필요 없습니다.

mkdir -p ~/.claude/skills/summarize-changes
cat > ~/.claude/skills/summarize-changes/SKILL.md << 'EOF'
---
description: 커밋되지 않은 변경사항을 요약하고 위험 항목 표시. 사용자가 무엇이 변경됐는지 물어보거나 커밋 메시지나 diff 리뷰를 요청할 때 사용.
---

## 현재 변경사항
!`git diff HEAD`

## 지침
위 변경사항을 2~3개 불릿으로 요약하고, 위험 항목을 나열하라.
EOF

프론트매터에서 세밀한 제어도 가능합니다. disable-model-invocation: true를 넣으면 Claude가 맥락상 자동 호출하는 것을 막을 수 있어요. 배포 스킬처럼 "실수로 실행되면 안 되는" 작업에 유용합니다. allowed-tools로 이 스킬이 활성화될 때만 허용할 도구를 제한할 수도 있고, model: claude-opus-4-8처럼 특정 스킬에서만 더 강력한 모델로 전환하는 것도 됩니다.

!`command` 구문은 Skills의 숨겨진 강점입니다. SKILL.md가 Claude에게 전달되기 전에 셸 커맨드가 실행돼 결과가 자동으로 삽입되거든요. 위 예제의 !`git diff HEAD`처럼 현재 상태를 동적으로 주입할 수 있어요.

SKILL.md 파일 구조와 프론트매터 옵션 설명 다이어그램

스킬 저장 위치에 따라 적용 범위가 달라집니다. ~/.claude/skills/에 넣으면 모든 프로젝트에서 쓸 수 있고, .claude/skills/에 넣으면 해당 프로젝트에서만 작동합니다. Monorepo에서 apps/web/.claude/skills/ 같은 중첩 위치도 지원해요.

실전에서 나온 생산성 수치들

"10배 빠르다"는 말은 과장이 많지만, 실제 보고된 수치는 꽤 구체적입니다. 표준화된 /review 스킬을 적용하면 코드 리뷰 사이클이 40% 단축됐고, TDD와 스킬을 결합하면 프로덕션 버그가 70% 감소한 사례가 있어요. 컨텍스트 관리 스킬 활용 시 토큰 비용 30~50% 절감, 성능 리팩토링 스킬 적용 시 렌더 시간이 847ms에서 286ms로 줄었다는 수치도 나왔습니다.

internal-comms 스킬 하나로 일일 Slack 메시지 작성 30분을 절약했다는 사례도 인상적이에요. 근데 가장 극단적인 건 Medium에 올라온 한 개발자 사례인데, "4인×6개월" 규모 프로젝트를 혼자 2개월 만에 완료했다고 합니다. 스킬 중심 워크플로우로 컨텍스트 관리 부담을 없애고 목표에만 집중한 결과예요.

Ramp에서는 ML 모델 변환 작업에 Skills를 적용해서 1~2일을 절약하기도 했습니다.

스킬 적용 전후 코드 리뷰 사이클 및 버그 수 비교 인포그래픽

바로 설치할 수 있는 커뮤니티 추천 스킬

DEV Community 리뷰어가 100개 스킬을 테스트한 결과, TOP 스킬로 꼽힌 것들입니다.

문서 처리 계열: PDF 폼 필드 추출, DOCX/PPTX/XLSX 네이티브 생성 스킬이 1~2위였어요. 모델이 "알아서 처리"하는 게 아니라 실행 코드 기반으로 작동해서 환각이 없다는 게 이유였습니다.

개발 계열: skill-creator(올바른 스킬 아키텍처 자동 생성), webapp-testing(Playwright 기반 브라우저 테스트 자동화), mcp-builder(Skills와 MCP 서버 연동)가 꼽혔습니다.

커뮤니티에서 주목받는 번들 중 obra/superpowers는 TDD, 디버깅, 협업 패턴 20개 이상을 묶었고, Trail of Bits Security Skills는 정적 분석과 취약점 탐지에 특화됩니다. 한국어 커뮤니티에서는 bear2u/my-skills(GitHub)를 참고해볼 만합니다.

설치는 간단합니다. ~/.claude/skills/ 아래에 디렉토리를 만들고 SKILL.md를 넣으면 끝이에요. 공식 마켓플레이스에서는 /plugin install document-skills@anthropic-agent-skills로도 설치할 수 있습니다.

보안 주의: 신뢰하지 않는 소스의 스킬은 SKILL.md 및 포함된 스크립트를 반드시 먼저 읽어보세요. 스킬은 광범위한 도구 접근 권한을 스스로에게 부여할 수 있습니다.

Claude Code 마켓플레이스에서 스킬 설치 방법 및 커뮤니티 추천 스킬 목록

AgentSkills 오픈 표준 — Claude만의 기능이 아니다

2025년 12월 18일 AgentSkills 오픈 표준이 공개되면서 SKILL.md 포맷이 다른 AI 도구에서도 작동하게 됐습니다. 2026년 기준으로 Claude Code, Codex CLI(OpenAI), Gemini CLI(Google), GitHub Copilot, Cursor, Cline, Windsurf가 동일한 포맷을 지원해요.

사실 처음엔 Claude 전용 포맷이라 다른 도구로 옮기면 다시 만들어야 하나 걱정했는데, 그럴 필요가 없어졌어요. Claude 중심으로 만든 스킬이 다른 도구에서도 그대로 돌아간다는 뜻입니다. 프론트매터 필수 필드(name, description)만 지키고 플랫폼 특화 동작을 선택적 필드에 분리하면 됩니다.

Anthropic은 Skills와 MCP(Model Context Protocol)를 상호보완 관계로 설명합니다. MCP가 외부 서비스 연동에 강하다면, Skills는 조직별 워크플로우를 캡슐화하는 데 적합하다고요. 둘 다 쓰는 게 맞습니다.

처음 시작하기 좋은 방법은 지금 당장 자주 쓰는 코드 리뷰 기준을 SKILL.md 하나로 만들어보는 거예요. 팀 전체가 같은 기준으로 리뷰하게 되는 부수 효과도 생기거든요. 커스텀 스킬 제작이 막막하다면 공식 skill-creator 플러그인이 제작 전 과정을 안내해주니 거기서 시작해도 됩니다.

CLAUDE.md 완벽 가이드 2026 — AI가 내 규칙을 기억하게 만드는 법

roundfigure — Mon, 29 Jun 2026 00:59:20 +0900

Claude Code를 처음 쓸 때 제일 답답한 게 뭔지 아세요? 어제 분명히 "TypeScript에서 any 쓰지 마"라고 했는데, 오늘 새 세션 열면 또 any가 나와 있어요. 매 세션마다 같은 말을 반복해야 하는 상황. 이게 싫어서 찾은 게 바로 CLAUDE.md입니다.

CCLAUDE.md 란?

CLAUDE.md가 뭔지 정확히 알고 시작하자

CLAUDE.md는 Claude Code가 매 세션 시작 시 자동으로 읽는 마크다운 파일입니다. 공식 문서 표현을 빌리면 "context, not enforced configuration"인데, 쉽게 말하면 "AI한테 보내는 영구 메모"예요.

여기에 코딩 표준, 아키텍처 결정, 선호 라이브러리를 적어두면 Claude가 매번 그걸 읽고 일을 시작합니다. 세션이 끊겨도 규칙은 살아있어요.

그럼 언제 뭔가를 추가해야 할까요? 공식 문서에서 권장하는 타이밍이 딱 세 가지입니다. Claude가 같은 실수를 두 번 반복했을 때, 코드 리뷰에서 "이건 Claude가 알았어야 하는 거잖아" 싶은 피드백이 나왔을 때, 그리고 지난 세션이랑 똑같은 교정을 또 타이핑하고 있을 때. 이 세 상황이 오면 그냥 CLAUDE.md에 박아버리면 됩니다.

CLAUDE.md 파일이 있는 위치 — 5단계 계층 구조

파일 하나가 아닙니다. Claude Code는 5단계로 나뉜 계층 구조를 읽어요. 더 좁은 범위의 파일이 더 나중에 읽혀 우선 적용되는 방식입니다.

단계	위치	공유 대상
Managed Policy	Windows: `C:\Program Files\ClaudeCode\CLAUDE.md`	조직 전체
User	`~/.claude/CLAUDE.md`	나 혼자, 모든 프로젝트
Project	`./CLAUDE.md` 또는 `./.claude/CLAUDE.md`	팀 전체 (git 커밋)
Local	`./CLAUDE.local.md`	나 혼자 (gitignore)
서브디렉토리	`./apps/web/CLAUDE.md`	해당 서브트리만

저도 처음엔 프로젝트 루트에 하나만 만들면 된다고 생각했는데, 계층 구조를 이해하고 나서 완전히 달라졌어요. User 레벨에는 제 개인 코딩 습관(탭 대신 스페이스, 커밋 메시지 형식 등)을 넣고, Project 레벨에는 팀 공통 규칙을, Local 레벨에는 저만 쓰는 개인 설정을 분리했습니다.

한 가지 중요한 특성이 있어요. 서브디렉토리에 있는 CLAUDE.md는 지연 로딩됩니다. Claude가 그 디렉토리 파일을 실제로 열 때만 로드돼요. 그래서 apps/api/CLAUDE.md에 적어둔 내용은 Claude가 그 폴더를 건드릴 때부터 적용됩니다.

CLAUDE.md 5단계 계층 구조를 시각화한 다이어그램 — 피라미드 형태로 Managed Policy(최상단)부터 서브디렉토리(최하단)까지

CLAUDE.md 실전 작성법 — 구체적이어야 통한다

핵심은 구체성입니다. "코드를 깔끔하게 유지해"는 Claude한테 아무 의미가 없어요. "2스페이스 들여쓰기 사용"처럼 검증 가능한 형태여야 합니다.

파일 크기도 중요해요. 200줄 이하로 유지해야 하고, 실제로는 80~120줄이 최적입니다. 길어질수록 준수율이 급락한다는 게 현실이에요.

제가 쓰는 필터가 하나 있습니다. "이 줄을 지우면 Claude가 잘못할까?" — No라면 그냥 지웁니다. 규칙이 많다고 좋은 게 아니에요.

아래가 실제 프로젝트에 적용 중인 CLAUDE.md 예시입니다:

# Project: my-app

## Commands
- Build: `pnpm build` (Turbopack 사용 — Webpack 플래그 미적용)
- Test: `pnpm test --run` (Vitest, Jest 아님)
- Lint: `pnpm lint` (경고도 CI 실패 처리)

## 규칙
- 서버 컴포넌트가 기본값. 폼/대화형 UI만 'use client' 추가
- DB 접근은 lib/db/ 헬퍼만 사용 — 라우트 직접 SQL 금지

## 안티패턴
- 새 의존성 추가 전 PR 댓글 먼저 작성
- `any` 금지 — `unknown` 사용 후 타입 좁히기

Commands 섹션에서 중요한 건 "어떤 명령어 쓰는지"뿐 아니라 "어떤 걸 쓰면 안 되는지"도 명시하는 거예요. Vitest 프로젝트인데 jest 명령어 날리는 실수, 생각보다 자주 일어납니다.

CLAUDE.md @import로 파일 나누기 — 조직화 목적

CLAUDE.md가 커지면 분리하고 싶어지는데, @ 문법으로 가능합니다.

# Project Rules

@.claude/rules/code-style.md
@.claude/rules/testing.md

See @README for project overview.

.claude/rules/ 디렉토리에 역할별로 파일을 나눌 수 있어요. 더 나아가 YAML frontmatter로 경로 스코프도 지정됩니다:

---
paths:
  - "src/api/**/*.ts"
---
# API 개발 규칙

paths가 있으면 해당 파일 패턴에서만 적용되고, 없으면 전체 적용이에요. 단, 주의할 점이 있습니다. @import로 분리해도 컨텍스트 절약이 되지 않아요. 조직화 목적으로만 씁시다.

HTML 주석()은 컨텍스트 주입 전에 제거되니까 토큰 절약 꼼수로 쓸 수 있긴 한데, 관리가 불편해서 저는 잘 안 씁니다.

.claude/rules/ 디렉토리 구조를 보여주는 파일 트리 스크린샷

Auto Memory — Claude가 스스로 기억을 관리하는 방식

Claude Code v2.1.59부터 자동 메모리 기능이 생겼습니다. Claude가 빌드 명령, 디버깅 인사이트 같은 걸 직접 기록해요.

저장 위치는 ~/.claude/projects/<project>/memory/이고, MEMORY.md 파일을 매 세션 첫 200줄 또는 25KB 로드합니다. CLAUDE.md랑 다른 점은 /compact 명령어로 컨텍스트 압축을 해도 CLAUDE.md는 자동 재주입되지만, 서브디렉토리 CLAUDE.md는 재주입이 안 된다는 거예요.

버전 확인부터 하세요. v2.1.59 미만이면 이 기능 없습니다.

/init 명령어로 초안 자동 생성

처음 만드는 게 막막하면 /init 명령어 쓰면 됩니다. Claude가 프로젝트를 분석해서 CLAUDE.md 초안을 자동으로 만들어줘요. 단, 자동 생성 결과를 그대로 쓰면 안 됩니다. 반드시 직접 편집해야 해요. 자동 생성본엔 너무 일반적인 내용이 많이 들어가거든요.

Claude Code 터미널에서 /init 명령어 실행 후 CLAUDE.md가 생성되는 과정

CLAUDE.md가 무시될 때 점검 리스트

직접 써보고 가장 많이 겪은 문제들입니다.

원인	해결법
파일 길이 초과	200줄 이하로 축소
모호한 표현	구체적이고 검증 가능하게 재작성
이유 없는 규칙	각 규칙에 한 문장 이유 추가
컨텍스트 압축	`/clear` 또는 새 세션 시작
파일명 오류	`CLAUDE.md` 대소문자 확인

파일명 오류가 생각보다 많아요. claude.md로 소문자로 만들어도 macOS에서는 동작하는데 리눅스 환경에서는 안 읽히는 경우가 있거든요. 대문자로 통일하세요.

CLAUDE.md vs Cursor .cursorrules — 뭐가 다를까

Cursor도 쓰는 분들이 궁금할 텐데, 간단히 비교하면 이렇습니다:

항목	CLAUDE.md	.cursor/rules/
지원 도구	Claude Code 전용	Cursor IDE 전용
계층 구조	5단계	Team>Project>User
@import	지원 (최대 4단계)	미지원
로컬 파일	CLAUDE.local.md	별도 없음
조직 정책	Managed Policy 지원	미지원

두 파일은 같은 저장소에 공존할 수 있어요. 충돌 없이 각자 동작합니다.

CLAUDE.md 자주 묻는 질문 (FAQ)

Q. CLAUDE.md에 민감한 API 키나 패스워드를 적어도 되나요?
A. 절대 안 됩니다. CLAUDE.md는 보통 git에 커밋되기 때문에 민감 정보가 그대로 올라갑니다. API 키 같은 건 .env 파일에 두고 gitignore 처리하세요. CLAUDE.local.md는 팀과 공유되지 않는 로컬 파일이지만, 여기서도 민감 정보는 피하는 게 맞습니다.

Q. CLAUDE.md가 너무 길어지면 어떻게 정리하나요?
A. 200줄 기준으로 잘라야 합니다. 역할별로 .claude/rules/ 하위에 파일을 나누고 @import로 불러오는 방식이 좋아요. 그래도 길면 "이 줄이 없으면 Claude가 실수할까?"를 기준으로 줄을 쳐냅니다.

Q. 서브디렉토리 CLAUDE.md는 언제 로드되나요?
A. Claude가 해당 디렉토리의 파일을 실제로 열 때 로드됩니다. 세션 시작 시 전부 로드되는 게 아니에요. 그래서 apps/api/ 폴더를 건드리기 전까지는 그 안의 CLAUDE.md가 적용되지 않습니다.

Q. /compact 후 CLAUDE.md 내용도 사라지나요?
A. 프로젝트 루트 CLAUDE.md는 /compact 후에도 자동으로 재주입됩니다. 서브디렉토리 CLAUDE.md는 재주입이 안 되므로, 중요한 규칙은 루트 파일에 두는 게 안전합니다.

CLAUDE.md, 지금 바로 만들어보는 게 빠릅니다

이론만 보면 복잡해 보이지만, 실제로는 간단해요. 지금 쓰는 프로젝트 루트에 CLAUDE.md 파일 하나 만들고, Commands 섹션 세 줄, Rules 섹션 다섯 줄부터 시작하세요. 쓰다 보면 추가할 게 자연스럽게 생겨요.

저는 처음 만든 CLAUDE.md가 12줄이었는데, 지금은 95줄짜리가 됐습니다. 그 사이에 "또 같은 말 하네" 싶었던 순간마다 한 줄씩 추가한 거예요.

Claude Code Max 플랜 쓸 가치 있나? Pro·Max·Team 요금제 실사용 후기 (2026)

roundfigure — Sun, 28 Jun 2026 19:22:15 +0900

$100짜리 Max 플랜을 선뜻 긁기가 망설여지는 건 당연합니다. Pro $20으로 시작했다가 한도에 막히면 그때 올리면 되는 거 아닐까 — 저도 그렇게 생각했습니다. 근데 실제로 어느 시점에 올려야 하는지, 올리면 뭐가 달라지는지가 생각보다 명확하지 않아서 직접 수치를 파보게 됐어요.

Pro·Max·Team 플랜 사용량 한도, API 대비 손익분기점, "어떤 사람이 Max를 쓰면 이득인가" — 수치 기준으로 정리했어요.

Claude Code 요금제 플랜 비교표 스크린샷 — Pro $20, Max 5x $100, Max 20x $200 가격 나란히 표시

요금 구조부터 짚고 가기

현재 개인 플랜은 네 단계입니다.

플랜	월 요금	사용량 배수	Claude Code
Free	$0	기준 이하	제한적 포함
Pro	$20 (연납 $17)	1x	포함
Max 5x	$100	Pro 대비 5배	포함
Max 20x	$200	Pro 대비 20배	포함

팀 플랜은 구조가 좀 다릅니다. Team Standard($20/seat)에는 Claude Code가 없고, Claude Code를 쓰려면 Team Premium($100/seat, 최소 5석)을 골라야 합니다. 팀원 중 개발자만 1명이고 나머지 4명은 Standard를 쓴다면 월 $180으로 Max 20x보다 저렴하게 구성하는 것도 가능해요.

사용량 한도, 실제로 얼마나 차이 나나

Claude Code는 "5시간 롤링 윈도우 + 주간 총량 캡" 이중 구조로 한도를 관리합니다. Anthropic이 구체적인 숫자를 공식 공개하지 않기 때문에 아래 수치는 제3자 분석 기반 추정치입니다.

플랜	5시간 윈도우 프롬프트 수	주간 Sonnet 시간
Pro	약 10~45개	40~80시간
Max 5x	약 50~225개	140~240시간
Max 20x	약 200~900개	240~480시간

실제 워크플로우별로 어떻게 체감되는지를 보면 차이가 확연합니다.

일일 8시간 코딩: Pro는 오전 11시 전에 한도 초과, Max 5x는 하루 종일 끊김 없이 사용 가능
장문 글쓰기 / 리서치: Pro와 Max 모두 한도에 거의 도달하지 않음
주간 리서치 세션: Pro는 주 2회 한도 도달, Max 5x는 한도 없이 사용 가능

글쓰기나 리서치 전용이라면 Pro와 Max 간 실제 사용 경험 차이가 거의 없다는 말입니다. Max는 사실상 개발자용 플랜입니다.

2026년 5월 6일부터 Anthropic이 5시간 한도를 두 배로 늘리고 피크 시간대(오전 5~11시 PT) 한도 축소도 폐지했습니다. 체감 상 상황이 좀 나아지긴 했지만, "한도 불투명 문제"는 여전히 남아 있어요 — 이건 아래에서 따로 다룹니다.

API vs 구독: 언제부터 Max가 유리한가

Claude Code는 구독 외에 API 키로도 사용할 수 있습니다. 어느 쪽이 더 저렴한지는 사용량에 달려 있어요.

현재 API 요금(2026년 6월 기준):

모델	입력 토큰	출력 토큰
Haiku 4.5	$1/MTok	$5/MTok
Sonnet 4.6	$3/MTok	$15/MTok
Opus 4.6	$5/MTok	$25/MTok

하루 API 비용 기준 손익분기점:

Pro $20/월 → 하루 $0.67 이상이면 구독이 유리
Max 5x $100/월 → 하루 $3.33 이상이면 구독이 유리
Max 20x $200/월 → 하루 $6.67 이상이면 구독이 유리

태스크 기준으로 환산하면 Max 5x는 버그 수정 111개/월 또는 피처 개발 26개/월 이상이면 API보다 저렴합니다. 하루 5개 태스크 정도면 손익분기 달성이에요.

실제 절감 사례도 있습니다. 한 개발자가 8개월간 100억 토큰을 사용했는데, API 환산 $15,000+ 비용이 Max 구독($100/월 기준 8개월 = $800)으로 약 93% 줄었습니다.

API 요금 vs Max 구독 손익분기점 비교 차트 — 월 사용량에 따른 비용 곡선

Team Premium vs Max 5x: 같은 $100인데 뭐가 다른가

개인 Max 5x와 Team Premium이 동일하게 $100/seat인데, 수치 차이가 있습니다.

사용량: Team Premium은 Pro 대비 6.25x, Max 5x는 5x — Team Premium이 세션당 25% 더 많음
한도 방식: Max는 5시간 롤링 리셋이 더 유리, Team은 주간 캡이 추가로 적용됨
부가 기능: Team은 SSO, SCIM, 공유 프로젝트, 중앙 청구 포함

혼자 쓰면서 지속적으로 하루 종일 쓴다면 Max가 낫고, 5명 이상 팀이라면 Team Premium이 더 현실적인 선택입니다.

알아두면 좋은 함정들

공유 사용량 풀: Claude Code, claude.ai 채팅, Cowork 모두 같은 사용량 풀을 공유합니다. 채팅에서 많이 쓰면 Claude Code 쪽 한도가 줄어듭니다.

v2.1.100 버그: 2026년 3월 조사에서 Claude Code v2.1.100이 매 요청마다 약 2만 개의 불필요한 토큰을 추가로 소모하는 버그가 발견됐습니다. 예상보다 40% 빠르게 한도가 소진되는 증상인데, 우회책은 npm으로 v2.1.34로 다운그레이드하는 것입니다.

한도 불투명 문제: Anthropic은 공식적으로 구체적인 토큰 한도를 공개하지 않습니다. GitHub 이슈에서는 같은 플랜, 같은 워크로드인데 시간당 소진율이 48시간 내에 5.6%에서 59.9%까지 극단적으로 들쭉날쭉하다는 보고가 다수 올라와 있어요. Anthropic이 대부분의 이슈에 응답 없이 'stale' 처리 후 종료해서 불만이 누적된 상태이고, 2026년 6월에는 연방 소송도 제기됐습니다.

Claude Code GitHub 이슈 화면 캡처 — 한도 불투명 문제 관련 사용자 리포트

결론: 이 사람은 업그레이드해야 하고, 이 사람은 하지 않아도 된다

Max 플랜이 맞는 경우:

하루 8시간 Claude Code를 켜두고 일하는 개발자
Pro 한도가 매일 오전에 걸리는 사람
Cursor나 GitHub Copilot 구독을 대체하려는 경우
에이전틱 워크플로우를 병렬로 돌리거나 대형 코드베이스를 다루는 사람
Claude Code로 아끼는 시간 가치가 월 $80 이상이라고 느끼는 사람

Pro $20으로 충분한 경우:

글쓰기·리서치 전용 사용자 (한도 차이 거의 없음)
하루 2~3시간 이하 캐주얼 사용
학생, 개인 사이드 프로젝트 라이트 유저
이미 Cursor 등 다른 AI 코딩 툴 구독 중인 경우

한 마디로 정리하면, Max는 일하는 도구로 쓰는 사람 전용 플랜입니다. 하루 종일 터미널에 Claude Code 띄워놓고 코딩하는 사람은 API 직접 사용 대비 확실히 아끼지만, 그렇지 않은 사람에게는 Pro와 사실상 같은 경험을 제공합니다.

한 달 기준으로 계산해보는 게 제일 정직한 방법입니다. API 키로 1~2주 써보고 하루 청구액이 $3.33을 넘어가면 그때 Max 5x로 올리면 됩니다. 반대로 $1도 안 나온다면 Pro에 머무는 게 맞아요.

Claude 요금제 공식 페이지는 claude.ai 에서 확인할 수 있습니다.

FAQ

Q. Claude Code Max 플랜은 연납 할인이 있나요?
A. 현재(2026년 6월 기준) Max 5x($100)와 Max 20x($200)는 연납 옵션이 없습니다. Pro 플랜만 연납 시 월 $17로 할인됩니다.

Q. Pro에서 Max로 올리면 기존 사용량 리셋이 되나요?
A. 5시간 롤링 윈도우는 업그레이드 시점 기준으로 재산정됩니다. 당일 이미 많이 사용했다면 즉각적인 한도 회복은 제한적일 수 있습니다.

Q. API와 구독을 병용할 수 있나요?
A. 가능합니다. 구독 한도가 소진된 이후 API 키로 전환해서 사용하는 방식도 선택지입니다. 다만 이 경우 구독 한도 소진 시 Claude Code 설정에서 API 키를 따로 설정해야 합니다.

Q. Max 20x가 Max 5x보다 4배 비싼데, 사용량도 4배인가요?
A. 이론적으로는 그렇지만, Anthropic이 한도를 공식 공개하지 않아 보장이 어렵습니다. 실제 테스트에서 Max 20x는 에이전틱 코딩 풀데이 작업에서 스로틀링 없이 완주한 유일한 플랜이었습니다.

Claude API 요금 완전 분석: Opus·Sonnet·Haiku 언제 뭘 써야 하나 (2026)

roundfigure — Thu, 25 Jun 2026 20:18:16 +0900

"Opus 쓰면 비싸고, Haiku 쓰면 품질이 떨어지는데 도대체 어느 모델을 써야 하지?" — Claude API를 처음 붙일 때 대부분 이 질문에서 막힙니다. 저도 처음엔 그냥 성능이 좋다는 Opus를 기본으로 썼다가 청구서 보고 깜짝 놀랐어요. 2026년 6월 기준, 모델별 가격 구조와 실제 비용 절감 방법을 있는 그대로 정리했습니다.

Claude API 모델 라인업 비교 표 — Haiku·Sonnet·Opus·Fable 가격 한눈에 보기

Claude API 모델 가격표 (2026년 6월 최신)

현재 Claude API에는 크게 네 등급의 모델이 있습니다.

모델	입력 ($/1M 토큰)	출력 ($/1M 토큰)	컨텍스트
Claude Haiku 4.5	$1.00	$5.00	200K
Claude Sonnet 4.6	$3.00	$15.00	1M
Claude Opus 4.8	$5.00	$25.00	1M
Claude Fable 5	$10.00	$50.00	1M

눈에 띄는 점이 하나 있어요. 출력 토큰이 입력 토큰보다 5배 비쌉니다. 그러니 출력을 얼마나 쥐어짜는가가 비용 설계의 핵심입니다. 긴 답변을 요청하는 프롬프트 구조는 그 자체로 비용을 폭발적으로 키웁니다.

Haiku 4.5의 컨텍스트 창이 200K로 유일하게 작다는 것도 기억해두세요. 200K를 넘는 문서를 처리해야 한다면 Haiku는 선택지에서 빠집니다.

모델별 비용 대비 효과 — 실제로 언제 뭘 써야 하나

Haiku 4.5 — 빠르고 싸다, 단순 작업의 왕

분류, 키워드 추출, 짧은 요약, 실시간 챗봇 응답 — 이런 작업이라면 Haiku 4.5가 정답입니다. 입력 $1, 출력 $5로 Sonnet 대비 3분의 1 가격이고, 응답 속도도 빠릅니다. 대량 배치 처리라면 더 유리해지는데, 뒤에서 설명할 배치 API를 붙이면 $0.50/$2.50까지 내려갑니다.

근데 한 가지 함정이 있어요. 복잡한 지시나 멀티스텝 추론이 들어가면 품질이 Sonnet에 비해 눈에 띄게 떨어집니다. "단순한가, 아닌가"를 먼저 판단하는 게 모델 선택의 출발점입니다.

Sonnet 4.6 — 대부분의 실무는 여기서 끝난다

솔직히 말하면, 웬만한 업무는 Sonnet 4.6으로 충분합니다. 코드 생성, 문서 분석, 긴 컨텍스트 처리(1M 창 지원), 일반적인 엔터프라이즈 작업 — Opus와 비슷한 품질을 60% 가격에 냅니다. 저도 직접 써본 결과, 복잡도 중간 수준의 코드 리뷰는 Sonnet과 Opus 출력물 차이를 느끼기 어려웠어요.

1M 컨텍스트 창이 Haiku(200K)의 5배라는 것도 큰 강점입니다. 긴 문서를 통째로 넣고 분석하는 작업에 딱 맞습니다.

Opus 4.8 — 진짜 어려운 문제만

복잡한 멀티스텝 추론, 난이도 높은 코딩 문제, 에이전트 파이프라인처럼 "틀리면 안 되는 작업"에 Opus 4.8을 씁니다. Adaptive Thinking을 지원해서 문제를 스스로 분해하며 접근하는 능력이 다릅니다. 가격은 Sonnet의 약 1.7배. 정확도가 비용을 정당화하는 상황인지 먼저 따져보세요.

Fable 5 — 예산 제한 없을 때만

Anthropic 최상위 모델로 입력 $10, 출력 $50입니다. Sonnet 대비 3배 이상 비쌉니다. 사고 과정이 항상 활성화되고 output_config.effort로 깊이를 조절할 수 있어요. 참고로 2026년 6월 12일에 일시 접근 제한이 있었다가 재개됐습니다 — 프로덕션에서 의존한다면 폴백 모델을 준비해두는 게 안전합니다.

모델별 사용 시나리오 의사결정 플로우차트

배치 API로 50% 자동 할인받기

실시간 응답이 필요 없는 작업이라면 배치 API(Batch API)를 쓰세요. 조건 없이 입출력 모든 토큰에 50% 할인이 적용됩니다. 최소 물량 조건도 없어요.

모델	기본 입력/출력	배치 API 적용 후
Haiku 4.5	$1.00 / $5.00	$0.50 / $2.50
Sonnet 4.6	$3.00 / $15.00	$1.50 / $7.50
Opus 4.8	$5.00 / $25.00	$2.50 / $12.50
Fable 5	$10.00 / $50.00	$5.00 / $25.00

대량 텍스트 분류, 야간 배치 분석, 비동기 문서 처리 — 이런 워크로드에 배치 API를 붙이면 같은 예산으로 처리량이 두 배가 됩니다. 24시간 내에 결과를 받아도 되는 작업이라면 실시간 API를 쓸 이유가 없어요.

프롬프트 캐싱으로 최대 90% 더 아끼기

배치 API보다 덜 알려졌는데 더 강력할 때도 있는 기능이 프롬프트 캐싱입니다. 같은 시스템 프롬프트나 긴 컨텍스트를 반복 사용하는 구조라면 캐시 읽기 비용이 기본 입력의 단 10%입니다.

캐시 구조는 두 가지예요.

5분 캐시: 캐시 쓰기 1.25배, 캐시 읽기 0.10배 — 같은 프롬프트를 1회만 더 읽어도 이득
1시간 캐시: 캐시 쓰기 2배, 캐시 읽기 0.10배 — 2회 이상 읽으면 이득

실제로 얼마나 절감되는지 예시 하나만 보면 바로 감이 옵니다. Sonnet 4.6으로 500토큰짜리 시스템 프롬프트를 하루 500번 호출한다고 가정하면, 캐싱 없이 처리하면 일일 약 $75 수준이던 비용이 캐싱 적용 후 $7.69 수준으로 떨어집니다. 연간으로 치면 약 $24,500 절감입니다.

프롬프트 캐싱 비용 절감 비교 그래프 — 캐싱 전후 일일 비용

배치 API와 프롬프트 캐싱을 동시에 적용하면 Sonnet 4.6 기준 입력 단가가 $3.00에서 최저 $0.15/1M 수준까지 내려갑니다. 이론상 95% 절감입니다.

Claude API 비용 경쟁력 — GPT·Gemini 대비 가격이 유리한 상황, 아닌 상황

Claude가 비싸다는 인식이 있는데, 비교해보면 케이스가 갈립니다.

모델	공급사	입력 ($/1M)	출력 ($/1M)	컨텍스트
Claude Sonnet 4.6	Anthropic	$3.00	$15.00	1M
GPT-5.4	OpenAI	$2.50	$20.00	~128K
Gemini 2.5 Pro	Google	$1.25	$10.00	1M
Gemini 2.5 Flash	Google	$0.30	$2.50	1M

Claude가 확실히 유리한 상황은 긴 컨텍스트입니다. Sonnet 4.6의 1M 컨텍스트 창은 GPT-5.4(~128K)의 약 8배입니다. 긴 문서를 통째로 처리해야 하는 작업이라면 GPT로 분할 처리하는 복잡함 없이 한 번에 끝낼 수 있어요.

반면 단순 분류나 빠른 처리가 목적이라면 Gemini 2.5 Flash($0.30/$2.50)가 Haiku 4.5보다 훨씬 저렴합니다. 비용만 보면 Claude의 약 3분의 1 수준이에요. 목적에 맞는 모델을 고르는 게 클라우드 제공사 충성도보다 중요합니다.

한국어로 Claude API 쓸 때 요금 계산에서 놓치기 쉬운 것

한 가지 빠뜨리기 쉬운 부분이 있습니다. 한국어는 영어 대비 토큰 수가 많습니다. 같은 내용을 영어로 쓸 때와 한국어로 쓸 때 토큰 수가 다르기 때문에, 요금 계산을 영어 기준으로 예측하면 실제 청구액이 더 나올 수 있어요. 프로덕션에 붙이기 전에 한국어 텍스트로 토큰 수를 직접 테스트해보는 걸 권장합니다.

모델 버전도 명시하는 습관을 들이세요. claude-opus-4-8처럼 버전을 고정해두지 않으면 Anthropic이 모델을 업데이트할 때 동작이 달라질 수 있습니다.

Claude API 모델 선택·비용 절감 — 5단계 결정 흐름

복잡하게 생각할 것 없이 이 순서로 판단하면 됩니다.

작업이 단순한가 (분류, 짧은 요약, 키워드 추출) → Haiku 4.5
200K 이상 컨텍스트가 필요하거나 코드·분석 작업인가 → Sonnet 4.6
복잡한 추론이나 에이전트 작업인가 → Opus 4.8
실시간이 필요 없는가 → 배치 API 50% 할인 추가
같은 시스템 프롬프트를 반복 사용하는가 → 프롬프트 캐싱 90% 절감 추가

API 비용 때문에 프로젝트를 포기하는 경우를 꽤 봤는데, 대부분 모델 선택과 캐싱 설계를 한 번만 손봐도 해결됩니다. Anthropic 공식 문서의 프롬프트 캐싱 가이드와 배치 API 문서를 한 번씩 읽어보는 것, 생각보다 빠르게 비용이 바뀝니다.

AI 개발 도구 무료 플랜 총정리 2026 — Claude Code vs Cursor vs GitHub Copilot

roundfigure — Wed, 24 Jun 2026 09:45:58 +0900

무료로 쓸 수 있는 AI 코딩 도구가 이렇게 많아진 건 사실 최근 일이에요. 근데 막상 써보면 "무료인데 이걸로 뭘 할 수 있지?" 싶은 경우가 꽤 있습니다. 세 도구 모두 무료 티어를 제공한다고 알려져 있는데, 실제로는 결이 완전히 다릅니다. Claude Code, Cursor, GitHub Copilot — 2026년 6월 기준 무료 플랜의 실체를 정리해봤어요.

Claude Code vs Cursor vs GitHub Copilot 무료 플랜 비교

Claude Code — 무료 플랜은 없다

솔직히 말하면 Claude Code는 무료 옵션이 없습니다. 웹에서 claude.ai를 무료로 쓸 수는 있지만, 터미널에서 claude 명령어를 실행하는 순간 Pro 구독을 요구해요. 무료 계정으로 CLI를 실행하면 그냥 차단됩니다.

요금 구조는 이렇습니다.

Pro: $20/월 — 5시간 롤링 한도 + 주간 한도
Max 5x: $100/월
Max 20x: $200/월

2026년 5월 6일부터 Pro 기준 5시간 롤링 한도가 2배로 늘었어요. 이전보다 여유가 생긴 건 맞지만, 여전히 무료로 쓸 방법은 없습니다.

Claude Code의 무료 대안을 찾고 있다면 몇 가지 선택지가 있어요. Gemini CLI는 하루 1,000회 무료 할당량이 있고, Cline에 자신의 API 키를 연결해서 쓰거나, Aider를 직접 사용하는 방법도 있습니다. 쓰는 만큼 API 비용이 나오니 컨트롤하기는 더 쉬울 수 있어요.

Claude Code 무료 플랜 없음 — Pro 구독 필수

Cursor Hobby — 있긴 한데, 빠르게 소진된다

Cursor는 Hobby라는 이름의 무료 플랜을 제공합니다. 신용카드도 필요 없고, 시작하기 쉬운 건 맞아요. 근데 한도가 타이트합니다.

Hobby 플랜 한도 (월 기준)

탭 자동완성: 2,000회
프리미엄 요청 (Claude, GPT-4o 등): 50회 (느린 큐)
1주일 Pro 체험 포함

실사용 관점에서 보면, 코딩하면서 탭 자동완성을 쓰다 보면 시간당 50~100회 정도는 금방 소비됩니다. 2,000회가 넉넉해 보여도 하루 2~3시간 작업하면 1~2일 안에 소진될 수 있어요. "real projects에서는 금방 한도가 찬다"는 게 Cursor 커뮤니티의 공통된 이야기입니다.

프리미엄 요청 50회도 마찬가지예요. 에이전트 모드로 복잡한 작업을 맡기면 한 번에 몇 회씩 쓰기 때문에, 헤비 유저라면 1주일을 못 버티는 경우도 있습니다.

유료 플랜은 Pro $20/월, Pro+ $60/월, Ultra $200/월로 구성돼 있어요.

Cursor Hobby 플랜 한도 — 탭 2,000회 요청 50회

GitHub Copilot Free — 세 도구 중 유일하게 실용적인 무료 티어

GitHub Copilot은 2026년 6월 기준으로 세 도구 중 가장 쓸 만한 무료 플랜을 가지고 있어요. 신용카드 없이 쓸 수 있고, 지원 IDE도 VS Code, JetBrains, Neovim, Xcode 등 기존에 쓰던 에디터를 그대로 활용할 수 있습니다.

Free 플랜 한도 (월 기준)

코드 완성: 2,000회
채팅/에이전트 요청: 50회
접근 가능 모델: Claude Haiku 4.5, GPT-5 mini (공식 문서 기준)

2026년 6월 1일부터 AI Credits 시스템으로 전환됐는데, 사용자 입장에서 체감 변화는 크지 않습니다. 월 2,000회 완성 한도 자체는 유지되고 있어요.

가벼운 코딩을 하루 1~2시간 정도 한다면 한 달을 버틸 수 있습니다. 헤비 유저라면 3~5일 안에 소진될 수도 있고요. 주의할 점이 하나 있어요 — 2025년 10월부터 일부 사용자 사이에서 한도 리셋 버그가 보고되고 있는데, 2026년 6월 현재까지 완전히 해결됐다는 공식 확인은 없습니다.

유료 플랜은 Pro $10/월, Pro+ $39/월, Max $100/월이에요. 가성비 면에서는 Cursor Pro($20/월)보다 저렴하게 시작할 수 있습니다.

GitHub Copilot Free 플랜 한도 2026

세 도구 한눈에 비교

항목	Claude Code	Cursor (Hobby)	GitHub Copilot (Free)
무료 플랜	없음	있음	있음
코드 완성	N/A	월 2,000회	월 2,000회
채팅/에이전트	N/A	월 50회 (느린 큐)	월 50회
에디터	터미널 CLI	전용 에디터	기존 IDE 플러그인
신용카드	N/A	불필요	불필요
최저 유료 가격	$20/월	$20/월	$10/월
실용적 무료 기간	—	1~2일	1달 (가벼운 사용 기준)

AI 개발 도구 무료 플랜 비교표 2026 — Claude Code vs Cursor vs GitHub Copilot

어떤 걸 선택해야 할까

무료로 AI 코딩 도구를 시작하고 싶다면 GitHub Copilot Free가 현실적인 선택입니다. 기존 에디터를 그대로 쓸 수 있고, 한도도 세 도구 중 가장 오래갑니다. 일단 무료로 쓰다가 아쉬움이 생기면 $10/월 Pro로 올리는 게 가장 낮은 진입 장벽이에요.

Cursor는 UI와 에이전트 경험 자체는 좋지만, 무료 한도로 진지하게 개발하기엔 빠듯합니다. 1주일 Pro 체험을 통해 느낌을 잡고 나서 결정하는 게 나을 것 같아요.

Claude Code는 처음부터 유료를 전제로 설계돼 있습니다. 무료로 맛보려면 웹 채팅 claude.ai를 써보거나, Gemini CLI나 Cline 같은 대안으로 에이전트 코딩 자체를 먼저 경험해보는 걸 추천해요.

세 도구 모두 빠르게 업데이트되고 있어서 한도나 가격이 바뀔 수 있습니다. 가입 전 공식 페이지에서 최신 조건을 한 번 더 확인하는 게 좋습니다.

n8n Claude API 연동 완전 가이드 — 설정부터 실전 워크플로우까지 (2026)

roundfigure — Tue, 23 Jun 2026 23:32:41 +0900

n8n Claude API 연동 완전 가이드

n8n으로 Claude를 붙이려고 공식 문서 찾아봤다가 버전 차이 때문에 헤맨 경험, 저도 있습니다. 연동 방법 자체는 간단한데 막상 노드 구성에서 막히는 경우가 꽤 있거든요. 이 글에서는 공식 Anthropic 노드를 쓰는 방법과 HTTP Request 노드로 직접 API를 호출하는 방법, 두 가지를 모두 정리합니다. 어떤 상황에서 뭘 쓰는지도 구분해드릴게요.

n8n 캔버스에서 Anthropic 노드가 연결된 워크플로우 전체 화면 캡처

연동 방법 두 가지 — 공식 노드 vs HTTP Request

n8n에서 Claude API를 쓰는 방법은 크게 두 가지입니다.

방법 1: 공식 Anthropic 노드 (대부분의 경우 이걸 쓰면 됩니다)

n8n에 Anthropic 통합이 기본 내장되어 있어서 별도 HTTP 설정 없이 바로 쓸 수 있어요. 자격증명 등록하고 노드 선택하면 끝입니다. 30개 이상의 사전 제작 템플릿도 제공하니까 처음 시작할 때 참고하기 좋습니다.

방법 2: HTTP Request 노드 (세밀한 제어가 필요할 때)

Claude API 엔드포인트를 직접 호출하는 방식입니다. 공식 노드에서 지원하지 않는 파라미터를 써야 하거나, 응답 구조를 원하는 대로 가공해야 할 때 유용합니다.

공식 Anthropic 노드 설정하기

n8n Credentials 화면에서 Anthropic API 키 입력하는 단계 스크린샷

먼저 API 키가 필요합니다. Anthropic Console → Settings → API Keys에서 발급받으세요.

키 준비됐으면 n8n에서 이렇게 진행합니다.

Settings → Credentials → Add Credential
"Anthropic" 검색 후 선택
API 키 붙여넣고 저장

자격증명이 등록되면 워크플로우 캔버스에서 세 가지 노드 중 하나를 선택하면 됩니다.

Chat Anthropic 노드: AI Agent나 LLM Chain과 연결해서 씁니다. 대화형 흐름에 적합합니다.
Basic LLM Chain 노드: 프롬프트 넣으면 텍스트 나오는 단순한 흐름에 씁니다. 구조 이해하면서 테스트하기 좋아요.
AI Agent 노드: 웹 검색, 문서 조회 같은 외부 도구를 Claude가 직접 호출해야 하는 복잡한 작업에 씁니다.

공식 노드가 지원하는 작업은 문서 분석, 이미지 분석, 프롬프트 생성, 파일 업로드/조회/삭제까지 꽤 넓습니다.

HTTP Request 노드로 직접 API 호출하기

세밀한 제어가 필요하다면 HTTP Request 노드로 직접 API를 호출할 수 있습니다. 설정값은 다음과 같습니다.

엔드포인트: https://api.anthropic.com/v1/messages
메서드: POST
헤더:
- x-api-key: Anthropic API 키
- anthropic-version: 2023-06-01
- content-type: application/json

요청 본문(JSON) 예시입니다.

{
  "model": "claude-sonnet-4-6-20260217",
  "max_tokens": 1024,
  "messages": [
    {
      "role": "user",
      "content": "{{ $json.input_text }}"
    }
  ]
}

응답에서 텍스트만 꺼내려면 {{ $json.content[0].text }} 표현식을 씁니다. 응답 전처리가 필요하면 뒤에 Execute Code 노드(JavaScript)를 붙이면 됩니다.

HTTP Request 노드 설정 화면 — 헤더와 Body 탭이 보이는 전체 캡처

실전 워크플로우 5가지

어떻게 쓰는지 감이 오는 게 중요하니까, 실제로 바로 구현할 수 있는 워크플로우 다섯 가지를 정리했습니다.

1. 이메일 자동 요약 & 일일 다이제스트
Gmail Trigger → HTTP Request(Claude) → Aggregate → Schedule Trigger → Gmail 발송 흐름입니다. 하루치 이메일을 Claude가 요약하고, 매일 오후 5시에 한 번에 정리해서 보내줍니다. 핵심 스레드만 뽑아서 보고서 형태로 묶어줘요.

2. 콘텐츠 자동 생성 파이프라인
Google Sheets에서 미발행 주제를 읽어서 → Claude Sonnet이 초안 작성 → Google Docs에 문서 생성 → Slack으로 팀 알림. 시스템 프롬프트에 브랜드 가이드라인을 박아두면 어조와 포맷이 일관되게 유지됩니다.

3. 문서 데이터 추출 (인보이스/PDF)
이메일에 PDF 첨부파일이 오면 → 텍스트 추출 → Claude Sonnet이 공급업체명, 인보이스 번호, 항목별 금액을 구조화 JSON으로 추출. Claude의 컨텍스트 창이 200,000 토큰이라 대용량 문서도 청킹 없이 단일 요청으로 처리됩니다.

4. 지원 티켓 지능형 라우팅
Webhook으로 헬프데스크 티켓 수신 → Claude Haiku가 카테고리·긴급도·감정을 분류 → 우선순위별로 팀/채널에 자동 배분. 분류처럼 단순한 작업에는 Claude Haiku(입력 $1/MTok)를 써서 비용을 낮추는 게 포인트입니다.

5. GitHub PR 자동 코드 리뷰 요약
PR이 열릴 때 트리거 → diff 가져오기 → Claude Sonnet이 변경 내용 분석 및 이슈 플래그 → PR 코멘트로 리뷰 자동 게시. 리뷰어 부담을 꽤 줄여줍니다.

n8n 캔버스에서 콘텐츠 자동 생성 파이프라인 워크플로우 전체 흐름 캡처

Claude API 비용 — 모델별 가격과 절감 전략

2026년 6월 기준 주요 모델 가격입니다.

모델	입력 (MTok당)	출력 (MTok당)
Claude Sonnet 4.6	$3	$15
Claude Opus 4.8	$5	$25
Claude Haiku 4.5	$1	$5

MTok = 백만 토큰입니다. 영어 기준 1토큰 ≈ 4자.

비용 줄이는 방법 세 가지가 있습니다.

프롬프트 캐싱: 반복되는 시스템 프롬프트를 캐시하면 캐시 읽기 비용이 기본 입력 가격의 10%로 떨어집니다. 같은 시스템 프롬프트로 여러 번 실행하는 n8n 워크플로우에서는 최대 90% 절감이 가능합니다.

Batch API: 시간이 급하지 않은 대량 작업이라면 Batch API를 쓰면 됩니다. 입력·출력 토큰 모두 50% 할인입니다. Claude Sonnet 4.6 기준 배치 가격은 입력 $1.50/MTok, 출력 $7.50/MTok.

모델 선택 전략: 단순 분류나 라우팅은 Claude Haiku, 일반 콘텐츠 생성은 Claude Sonnet, 복잡한 추론이 필요한 멀티에이전트 작업은 Claude Opus로 나눠 쓰면 됩니다. 지원 티켓 10,000건을 Claude Haiku로 처리하면 총비용이 약 $37 수준입니다.

n8n 클라우드 vs 셀프호스팅 — 비용 비교

n8n 클라우드는 Starter 플랜이 €20/월(월 2,500 실행)부터 시작합니다. Pro는 €50/월(10,000 실행), Business는 €667/월(40,000 실행)입니다. 실행 횟수 계산 방식이 Zapier와 달라서, 10단계짜리 워크플로우가 1,000번 돌아도 n8n 기준 1,000 실행으로 카운트됩니다.

셀프호스팅 커뮤니티 에디션은 소프트웨어 자체는 무료이고 실행 횟수 제한도 없습니다. 실제로 드는 건 서버 비용뿐인데, 소규모 자동화라면 월 $3~12 수준의 VPS로 충분합니다.

Pro 클라우드(€50/월) 대비 셀프호스팅($3~7/월)은 연간 $636~684 차이입니다. 규모가 커질수록 셀프호스팅이 압도적으로 유리해집니다.

직접 서버 운영이 처음이라면 Vultr에서 시작해볼 만합니다. 신규 가입 시 $300 크레딧이 제공되니까 처음 몇 달은 사실상 무료로 n8n 셀프호스팅을 테스트해볼 수 있어요.

흔한 실수와 주의사항

설정할 때 한 번씩 빠지는 함정들이 있습니다.

Simple Memory 노드 배포 문제: 개발 중에는 잘 돌아가는데 배포 후에 "모든 걸 잊어버리는" 현상이 생깁니다. 프로덕션에는 Postgres 또는 Redis 기반 메모리를 써야 합니다.

세션 ID 하드코딩: 세션 ID를 고정값으로 박아두면 모든 사용자가 메모리를 공유하게 됩니다. 개인정보 침해 문제가 생길 수 있으니 사용자별로 세션 ID를 동적 생성해야 합니다.

레이트 리밋 미처리: Claude API는 분당 요청 횟수 제한이 있습니다. 배치 처리 시 Claude 호출 사이에 Wait 노드(1~2초)를 꼭 넣으세요. 대용량이라면 Batch API로 넘기는 게 낫습니다.

자격증명 하드코딩: API 키를 워크플로우 노드에 직접 입력하지 말고 n8n 자격증명 관리자에 저장해야 합니다. 민감한 데이터가 로그에 남지 않도록 설정도 확인하세요.

에러 핸들링 미설치: Error Trigger 노드를 별도로 구성해두지 않으면 워크플로우가 조용히 실패합니다. 일시적 실패에는 지수 백오프(1초, 2초, 4초) 재시도 로직도 넣어두세요.

시작 전에 확인할 것

연동 자체는 생각보다 빠르게 끝납니다. API 키 발급, 자격증명 등록, 노드 연결이 전부거든요. 근데 프로덕션에 올리기 전에는 메모리 설정, 세션 관리, 에러 핸들링 세 가지를 꼭 챙기세요. 이 부분을 대충 넘기면 나중에 잡기 힘든 버그가 됩니다.

n8n 공식 템플릿 페이지에서 Claude 관련 워크플로우를 검색해보면 바로 포크해서 쓸 수 있는 것들이 30개 넘게 있습니다. 처음엔 템플릿 뜯어보면서 구조를 파악하는 게 가장 빠른 방법입니다.

Windsurf vs Cursor vs Claude Code: 2026년 AI 에디터 3파전 최종 정리

roundfigure — Mon, 22 Jun 2026 13:14:41 +0900

2026년 6월 2일, Windsurf가 'Devin Desktop'으로 공식 리브랜딩됐다. Cognition AI에 인수되면서 이름도, 방향성도 바뀐 것이다. 한때 "AI 에디터 3파전"이라 불리던 구도가 사실상 2파전으로 재편된 셈이다. 남은 두 선수, Cursor와 Claude Code는 전혀 다른 방식으로 개발자의 일상에 파고들고 있다. 지금 이 시점에 세 도구를 한꺼번에 정리해두는 게 의미 있는 이유가 바로 여기 있다.

Windsurf, Cursor, Claude Code AI 에디터 비교 대표 이미지 2026

세 도구, 한 줄 포지셔닝

각 도구가 어디를 겨냥하는지부터 짚어야 비교가 선명해진다.

도구	현재 이름	한 줄 포지셔닝	기반
Windsurf	Devin Desktop	멀티에이전트 오케스트레이터로 피벗	VSCode 포크
Cursor	Cursor	AI가 통합된 IDE 점유율 1위	VSCode 포크
Claude Code	Claude Code	터미널 기반 에이전트 + IDE 통합 지원	CLI + VS Code/JetBrains

세 도구 모두 VS Code 생태계와 연결되어 있다. Cursor·Devin Desktop은 VS Code 포크로 그 자체가 IDE고, Claude Code는 터미널이 기본이지만 VS Code·JetBrains 익스텐션으로도 쓸 수 있다. 같은 "AI 코딩 도구"로 묶이지만 실제 사용 방식은 꽤 다르다.

Windsurf는 어떻게 됐나 — Devin Desktop으로의 변신

Windsurf의 역사는 2026년에 급격히 달라졌다. 처음엔 OpenAI가 $3B에 인수하려다 2025년 7월 협상이 무산됐다. 그다음 Google DeepMind가 핵심 인력 약 40명을 $2.4B에 데려갔고, 남은 IP와 직원, 브랜드($82M ARR 포함)를 Cognition AI가 인수했다.

그 결과가 2026년 6월 2일의 리브랜딩이다. Windsurf라는 이름 대신 Devin Desktop이 전면에 나서게 됐다. Cascade 기능은 2026년 7월 1일 EOL(서비스 종료) 예정이다.

지금의 Devin Desktop은 무엇이 달라졌나:

Agent Command Center: 칸반보드 형식으로 여러 에이전트를 동시에 관리할 수 있다. 단순 코드 자동완성을 넘어 멀티에이전트 오케스트레이션으로 방향을 틀었다.
ACP 오픈 프로토콜: 다양한 에이전트 간 통신을 위한 자체 프로토콜을 공개했다.
SWE-1.6 자체 모델: 950토큰/초 속도를 자랑하는 자체 모델을 탑재했다.
VSCode 완전 호환: 기존 Windsurf 사용자는 확장 생태계를 그대로 유지할 수 있다.

다만 쾌적하지 않은 부분도 있다. 브랜드 혼란이 아직 가시지 않았고, 쿼터 정책이 불투명하다는 불만이 커뮤니티에서 꾸준히 나오고 있다. 인수 과정이 워낙 복잡했다 보니 안정성 이슈도 일부 보고된다.

Cursor — 점유율 1위, 지금 뭐가 달라졌나

Cursor는 2026년 6월 기준 $3B ARR, 일일 활성 사용자 100만 명 이상을 기록하고 있다. 포춘 500대 기업 3분의 2가 사용 중이라는 수치도 있다. JetBrains 설문에서 직장 내 AI 도구 사용률 18%로 Claude Code와 공동 2위를 기록했다.

2026년 6월 16일엔 SpaceX가 $60B에 인수 합의를 발표했다. Cursor 생태계에 어떤 변화가 생길지는 아직 지켜봐야 한다.

Cursor의 차별점:

Tab + Agent + Chat 통합: 자동완성, 에이전트 모드, 채팅이 하나의 인터페이스 안에 있어 컨텍스트 전환 없이 쓸 수 있다.
Bugbot: 90초 안에 버그를 탐지하는 기능이다.
브라우저 통합: 브라우저와 연동해 UI 확인이나 웹 리서치를 IDE 안에서 처리한다.
멀티모델 지원: 특정 모델에 묶이지 않고 여러 AI 모델을 상황에 맞게 선택할 수 있다.

주의해야 할 점도 있다. 2026년 3월에 코드를 무단으로 롤백하거나 파일을 변경하는 버그가 보고됐다. Pro 플랜 헤비유저들이 실제로 $40~50/월을 지출하게 된다는 비용 초과 문제도 적지 않은 불만을 낳고 있다. 고객지원에 대한 평가도 엇갈린다.

직접 써보면서 느낀 건, Cursor는 "익숙한 IDE 위에 AI를 얹어준다"는 경험이 좋다는 점이다. VSCode에서 넘어오는 진입 장벽이 거의 없다.

Claude Code — 터미널이 기본, IDE도 된다

Claude Code는 2025년 5월 정식 출시됐고, 6개월 만에 연간 $1B 매출을 달성했다. 기본 인터페이스는 터미널이다. 그런데 VS Code 익스텐션과 JetBrains 플러그인도 공식 지원한다. 터미널에서 쓰든, IDE 안에서 쓰든 동일한 에이전트가 동작한다.

핵심 강점:

100만 토큰 컨텍스트: 대규모 코드베이스를 통째로 참조할 수 있다.
Dynamic Workflows: 수백 개의 서브에이전트를 병렬로 실행하는 방식이다. 멀티에이전트 작업에서 진가를 발휘한다.
토큰 효율: builder.io의 독립 테스트에서 동일 작업을 Cursor 대비 5.5배 적은 토큰으로 처리했다.
MCP 생태계: Model Context Protocol을 통해 다양한 외부 도구와 연결된다.

실제 사례로, API 엔드포인트 15개 리팩터링 작업에서 Claude Code를 쓰면 2시간 걸리던 게 48분으로 줄었다는 보고가 있다. 비용은 $2.3이었다.

단점도 명확하다. VS Code 익스텐션이 있지만 Cursor처럼 IDE 자체를 대체하진 않는다. 인라인 자동완성(코드 치는 중 실시간으로 뜨는 제안)이 없다. 비용 구조도 일일 한도 기반이라 예측하기 어렵다는 의견이 있다.

요금제 비교

AI 에디터 3종 요금제 비교표 — Windsurf, Cursor, Claude Code 가격 티어

플랜	Windsurf (Devin Desktop)	Cursor	Claude Code
무료	$0 (경량 일별 쿼터, Tab 무제한)	$0 (Hobby)	—
기본 유료	Pro $20/월	Pro $20/월 (프리미엄 요청 500회)	Pro $20/월 (Claude Code 포함)
중간	—	Pro+ $60/월 (3배)	Max 5x $100/월
고사양	Max $200/월	Ultra $200/월 (20배)	Max 20x $200/월
팀	Teams $40/인/월	Business $40/인/월	Team Premium $100/인/월 (연간)

세 도구 모두 $20/월 기본 유료 플랜에서 시작한다. 헤비유저일수록 Cursor와 Claude Code는 $200/월까지 올라가는 구조가 같다. Cursor Pro 플랜의 프리미엄 요청 500회 한도가 실제로 부족한 경우가 많아 중간 플랜인 Pro+ ($60/월)로 넘어가는 패턴이 자주 나타난다.

실제 성능 — 벤치마크와 현장 평가

Claude Code vs Cursor 성능 벤치마크 — SWE-bench 점수 비교

SWE-bench Verified 점수:

도구	점수
Claude Code (Opus 4.6)	80.8%
Claude Code (SWE-bench 기준)	72.5%
멀티파일 성공률 (Claude Code)	91%

builder.io의 독립 비교 테스트에서 Claude Code는 Cursor 대비 블라인드 테스트 승률 67%를 기록했다. 동일 작업에서 토큰 사용량은 5.5배 적었다.

현장 설문:

JetBrains 2026년 직장 내 AI 도구 사용률 조사 결과:

GitHub Copilot: 29%
Cursor: 18%
Claude Code: 18%
Windsurf: 5%

AI-enabled IDE 시장 점유율에서는 Cursor 18%, Claude Code 10%, Windsurf 5% 순이다.

G2 리뷰에서 Claude Code는 4.9/5 (15개 리뷰 전원 추천)을 받았다. 표본이 작다는 점은 고려해야 한다.

현장에서 가장 흔히 보이는 패턴은 Cursor(일상 코딩) + Claude Code(복잡한 작업) 병행이다. 단일 도구로 모든 걸 해결하기보다 성격에 따라 나눠 쓰는 방식이 정착되는 분위기다.

어떤 도구를 골라야 하나 — 상황별 추천

AI 에디터 상황별 추천 가이드 — Cursor vs Claude Code vs Devin Desktop 선택 기준

Cursor가 맞는 경우:

VSCode에서 자연스럽게 넘어오고 싶을 때
Tab 자동완성을 일상적으로 많이 쓸 때
팀 단위로 표준화된 IDE 환경이 필요할 때
브라우저 통합이나 멀티모델 전환이 필요한 경우

Claude Code가 맞는 경우:

대규모 리팩터링, 멀티파일 수정 작업이 잦을 때
터미널과 CLI 환경에 익숙한 개발자
비용 대비 성능을 최우선으로 볼 때
MCP를 통해 외부 도구와 긴밀하게 연결해야 할 때

Devin Desktop(Windsurf)이 맞는 경우:

멀티에이전트 워크플로우를 본격적으로 실험하고 싶을 때
ACP 기반의 에이전트 협업 시나리오를 탐구 중인 팀
다만 브랜드 전환 과도기인 만큼 안정성보다 새로운 기능 탐색에 가치를 두는 경우

실용적인 선택지를 하나 꼽자면, 첫 달 Cursor Pro로 시작해 일상 코딩 흐름을 잡은 뒤, 무거운 작업이 생기면 Claude Code Pro를 병행하는 방식이 지금 시점에선 가장 유연하다.

자주 묻는 질문

Q. Windsurf를 쓰고 있었는데 지금 당장 옮겨야 하나요?

Cascade EOL이 2026년 7월 1일이므로 시간이 얼마 없다. Devin Desktop으로 자연스럽게 마이그레이션되는 경우도 있지만, 이 기회에 Cursor나 Claude Code를 함께 평가해보는 것도 합리적인 선택이에요.

Q. Cursor Pro $20/월이 실제로 부족한가요?

헤비유저라면 부족한 경우가 많습니다. 프리미엄 요청 500회/월 한도가 생각보다 빨리 닳아요. 실제 지출이 $40~50/월로 올라가는 사례도 흔하다. Pro+($60/월)나 Ultra($200/월) 플랜이 필요한지 한 달 써보고 판단하는 게 좋아요.

Q. Claude Code는 GUI가 없으면 불편하지 않나요?

터미널에 익숙한 개발자라면 오히려 더 빠르다고 느끼는 경우가 많습니다. 인라인 자동완성이 없다는 건 분명한 단점이에요. 그래서 현장에서 Claude Code만 단독으로 쓰기보다 Cursor와 병행하는 패턴이 많은 겁니다.

Q. SpaceX가 Cursor를 인수하면 뭐가 달라지나요?

2026년 6월 16일 합의 발표 이후 세부 사항이 공개되지 않았습니다. 당분간은 제품 방향이나 가격에 큰 변화가 없을 가능성이 높지만, 중장기적으로 SpaceX 인프라와의 통합 가능성을 배제할 수 없어요.

마무리

2026년 AI 에디터 시장은 "어떤 도구 하나가 압도적"이 아니라 "어떤 조합이 내 워크플로우에 맞나"를 고민하는 단계로 넘어왔다. Windsurf가 Devin Desktop으로 전환하며 멀티에이전트 오케스트레이션으로 방향을 바꿨고, Cursor는 점유율 1위 자리를 유지하며 SpaceX라는 든든한 뒷배를 얻었다. Claude Code는 터미널이라는 낯선 방식으로도 6개월 만에 $1B 매출을 찍었다.

각 도구의 무료 체험 기간을 활용해 직접 손에 익혀보는 것이 지금 시점에서 가장 빠른 판단 방법이다. 벤치마크 숫자보다 "내가 오늘 작업한 코드 앞에서 이 도구가 얼마나 막힘없이 돌아가는가"가 결국 기준이 된다.

Vultr vs Hetzner vs DigitalOcean: 2026년 VPS 성능·가격 직접 비교

roundfigure — Mon, 22 Jun 2026 12:09:01 +0900

VPS를 고를 때 보통 가격표부터 열어보죠. 근데 2026년 상반기는 그 가격표 자체가 흔들렸습니다. Hetzner가 넉 달 사이에 세 번이나 요금을 올렸거든요. "그래도 제일 저렴하다더라"는 말이 맞는 건지, 아니면 이제는 Vultr나 DigitalOcean을 봐야 하는 건지 — 실제 수치로 정리해봤습니다.

Vultr, Hetzner, DigitalOcean 비교 대표 이미지

세 업체, 한 줄 포지셔닝

헷갈리지 않게 먼저 정리하면 이렇습니다.

Hetzner: 유럽 기반. 인상 후에도 경쟁사 대비 압도적으로 저렴. 단, 한국 리전 없음
Vultr: 성능 최상위. 서울 리전 보유. 전 세계 33개 리전
DigitalOcean: 순수 VPS 성능은 셋 중 최하위지만, 관리형 서비스 생태계가 강점

세 업체 모두 "싸고 빠른 VPS"로 소개되곤 하는데, 실제로는 포지션이 꽤 다릅니다. 어떤 것이 맞냐는 쓰임새에 따라 달라집니다.

2026년 실제 가격 비교표

2 vCPU / 4 GB RAM 급 기준으로 정리했습니다. 같은 스펙이라도 업체마다 플랜명이 달라서 헷갈리는 경우가 많으니, 실제 스펙으로 맞춰서 비교했습니다.

업체	플랜	vCPU	RAM	스토리지	월 요금	대역폭
Hetzner	CX32	4	8 GB	80 GB NVMe	~€7.59	20 TB
Hetzner	CPX22 (6월 인상 후)	2	4 GB	80 GB NVMe	€19.49	20 TB
Vultr	High Frequency	2	4 GB	65 GB NVMe	$24	5 TB
DigitalOcean	Basic (Premium AMD)	2	4 GB	80 GB SSD	$24	4 TB

Hetzner CX32는 인상 후에도 여전히 저렴합니다. 문제는 CPX 계열입니다. CPX22가 €7.99에서 €19.49로 오르면서(+144%), 이제 Vultr·DigitalOcean과 가격 차이가 거의 없어졌습니다. 어떤 플랜을 보느냐에 따라 "여전히 최저가"와 "이제 비슷해졌다" 둘 다 맞는 말이 되는 아이러니한 상황입니다.

3사 가격 비교 막대 그래프 — 동급 플랜 월 요금(USD 기준 환산)

Hetzner 2026년 세 번의 가격 인상 — 지금은 어떤가

솔직히 말하면, 이 정도 인상 속도는 예상 밖이었습니다.

1차(4월 1일): CX 계열 기본 플랜이 33% 올랐고, 기존 고객도 예외 없이 적용됐습니다.

2차(4월 29일): 전용 서버 초기 설치비 추가 조정. RAM과 NVMe SSD 비용 급등을 이유로 들었습니다.

3차(6월 15일): CPX·CCX 계열 폭탄. CPX22가 +144%, CCX13이 +169% 올랐습니다. 이번엔 기존 계약자는 유지하고 신규와 리스케일 대상만 적용했습니다.

원인은 DRAM 공급 위기입니다. 서버용 DRAM 계약 가격이 2025년 4분기에 43~48% 급등했고, AI 가속기용 HBM 생산으로 메모리 라인이 전환되면서 서버용 물량이 줄었습니다. Hetzner만의 문제가 아니라 OVHcloud도 55% 인상했고, Scaleway·IONOS도 비슷하게 움직였습니다.

그럼 지금 Hetzner는 싼가요? CX 계열은 여전히 압도적으로 저렴합니다. CX32 기준으로 DigitalOcean·Vultr 동급 대비 약 1/6 수준이에요. 반면 CPX·CCX 계열은 이제 경쟁사와 큰 차이가 없습니다. 어떤 플랜을 쓰느냐에 따라 판단이 갈립니다.

성능 벤치마크 — 어디가 제일 빠른가

가격만 보면 Hetzner가 이기는 것 같지만, 성능 쪽에선 얘기가 다릅니다.

CPU 성능 (Geekbench 6, 2 vCPU/4 GB 동급)

	DigitalOcean	Hetzner CPX22	Vultr HF
싱글코어	772	~939	1,926
멀티코어	~1,400	~1,672	3,513

Vultr High Frequency가 DigitalOcean 대비 싱글코어 기준 149% 높습니다. 칩 세대 차이가 큰데, Vultr는 AMD EPYC-Genoa(3.25 GHz)를 쓰고 DigitalOcean은 Intel Xeon, Hetzner CPX 계열은 AMD EPYC-Rome(2.4 GHz)입니다.

디스크 IOPS

	DigitalOcean	Hetzner	Vultr HF
랜덤 4K IOPS	~54,200	~40,900	~118,400

디스크도 Vultr가 두 배 이상 앞섭니다. 직접 WordPress를 돌려본 벤치마크에서도 Vultr HF는 620ms 로드 타임으로 DigitalOcean(1.1s)보다 눈에 띄게 빨랐습니다.

Hetzner는 CPU·디스크 모두 중간 수준이지만, 가격 대비로 따지면 CX 계열은 여전히 이야기가 됩니다.

CPU 성능(Geekbench 6 싱글코어/멀티코어) 3사 비교 막대 그래프

데이터센터 위치 — 한국에서 쓴다면

이 항목이 한국 사용자에게는 사실 가장 중요한 부분일 수 있습니다.

Vultr: 서울 포함 아시아 7개 리전(오사카, 도쿄, 서울, 싱가포르, 뭄바이, 방갈로르, 델리). 셋 중 유일하게 서울 리전을 운영합니다.

DigitalOcean: 싱가포르(SGP1) 단일 리전. 한국 리전 없음.

Hetzner: 유럽·미국·싱가포르. 한국 리전 없음. 싱가포르 리전도 2024년에 개설했고, 자체 데이터센터가 아닌 코로케이션 방식이라 EU 대비 가격이 소폭 높습니다.

한국 타겟 서비스를 운영한다면 선택지가 Vultr 서울 하나뿐입니다. Hetzner·DigitalOcean을 쓰려면 싱가포르 리전으로 타협해야 하는데, 레이턴시 차이가 꽤 납니다.

상황별 추천 — 어떤 업체를 써야 하는가

경우에 따라 답이 달라집니다.

유럽 대상 서비스, 비용이 최우선 → Hetzner CX/CAX
인상 후에도 CX 계열은 경쟁사 대비 1/3~1/6 수준입니다. ARM 기반 CAX 계열은 6월 인상 영향도 작았고(+33%), 컨테이너 워크로드에 적합합니다. 대역폭도 20 TB라서 트래픽 걱정이 없어요.

한국/아시아 서비스, 또는 최고 성능 필요 → Vultr
서울 리전이 있고, CPU·디스크 성능이 셋 중 최상위입니다. 게임 서버, 고성능 API, WordPress 사이트 모두 Vultr HF가 제일 빠릅니다.

이 링크로 가입하면 30일간 $300 크레딧이 즉시 지급됩니다. → Vultr 시작하기

스타트업 또는 관리형 서비스가 필요한 팀 → DigitalOcean
순수 VPS 성능 대비 가격은 셋 중 가장 불리하지만, 관리형 PostgreSQL·MySQL·Redis(월 $15~), App Platform(PaaS), CDN 내장 Object Storage까지 생태계가 갖춰져 있습니다. 인프라 담당자 없이 개발에만 집중하고 싶은 팀이라면 DO의 에코시스템이 순수 VPS 가격 차이를 상쇄합니다.

DB 워크로드, 쓰기 IOPS 중요 → Hetzner CX22
Hetzner CX22는 50,000 쓰기 IOPS 수준으로 PostgreSQL·MySQL에 무난하게 쓸 수 있습니다. 가격 경쟁력도 유지합니다.

상황별 VPS 업체 선택 인포그래픽

FAQ

Q. Hetzner 가격 인상 전에 계약한 고객은 영향 없나요?

6월 3차 인상은 기존 계약자를 보호했습니다. 하지만 4월 1차 인상은 기존 고객에게도 적용됐습니다. 커뮤니티에서는 "영구 보호가 아닐 수 있다"는 불안감이 있어요. r/selfhosted, Hacker News에서도 신뢰도 논쟁이 있었습니다.

Q. Vultr와 DigitalOcean 중 어느 쪽이 더 안정적인가요?

두 업체 모두 SLA를 제공합니다. Vultr는 100% 업타임 보장을, DigitalOcean은 99.99%를 내세웁니다. 실제 장애 경험은 케이스바이케이스이고, 장기적으로 두 업체 모두 큰 차이는 없습니다.

Q. DigitalOcean 신규 가입하면 크레딧이 있나요?

$200 크레딧(60일 유효)이 제공됩니다. 2026년부터는 초당 과금을 도입해 단기 실험 비용도 줄었습니다. → DigitalOcean 공식 사이트

Q. Hetzner 싱가포르 리전은 한국에서 쓸 만한가요?

싱가포르-서울 간 레이턴시는 보통 70~90ms 수준입니다. 한국 사용자가 직접 접속하는 서비스에는 체감 차이가 있을 수 있지만, 백엔드 처리 서버나 CI 환경이라면 충분히 쓸 수 있습니다.

Q. Hetzner ARM(CAX) 계열은 어떤가요?

CAX11(2 vCPU/4 GB, €5.99)은 6월 인상에서도 +33% 수준으로 상대적으로 작게 올랐습니다. ARM 호환 컨테이너 워크로드라면 여전히 가격 대비 좋은 선택입니다. → Hetzner Cloud

2026년 VPS 시장에서 "정답" 한 업체는 없습니다. Hetzner는 유럽 리전에서 아직 강하고, Vultr는 성능과 아시아 리전 커버리지에서 앞서고, DigitalOcean은 생태계로 차별화합니다. 지금 어떤 상황인지 먼저 따져보고 고르는 게 제일 빠릅니다. 지금 바로 Vultr 서울 리전을 테스트해보고 싶다면 이 링크로 가입하면 30일간 $300 크레딧이 즉시 지급됩니다. → Vultr 시작하기

저렴한 VPS 추천 2026: 월 6천 원으로 서울 서버 쓰는 법

roundfigure — Mon, 22 Jun 2026 02:41:20 +0900

메타 디스크립션: 2026년 저렴한 VPS 추천 비교. Vultr 서울 DC 직접 써본 후기, $5~$6 플랜 실제 성능, 가입부터 SSH 접속까지 입문자 가이드.

VPS 처음 알아볼 때 가장 막히는 부분이 "얼마짜리 써야 하지?"입니다. AWS EC2 열어봤다가 가격표 보고 탭 닫은 경험, 저도 있어요. 근데 실제로는 월 6천 원대 서버로 Discord 봇이나 개인 프로젝트 충분히 돌릴 수 있습니다. 이 글에서는 그 선택지 중 하나인 Vultr를 직접 써본 경험 위주로 정리했습니다.

VPS가 처음이라면: 내 상황에 맞는 서버 크기부터

서버 고르는 기준을 모르면 필요 이상으로 비싼 플랜을 고르게 됩니다. 실제로 많이 쓰이는 케이스별로 정리하면 이렇습니다.

사용 목적	최소 RAM	추천 플랜
Discord/텔레그램 봇	512MB	$5/월
정적 사이트, 포트폴리오	512MB~1GB	$5/월
WordPress, 소형 앱	1~2GB	$5~$10/월
Node.js + DB 동시 운영	2~4GB	$12~$24/월
n8n, Uptime Kuma 등 자동화	1GB	$6/월 NVMe

대부분의 입문자는 $5~$6 구간에서 시작하면 됩니다. 부족하면 언제든 업그레이드 가능하고, Vultr는 시간 단위 과금이라 테스트하고 삭제해도 실제 쓴 시간만큼만 청구됩니다.

용도별 VPS 플랜 추천 비교표

왜 Vultr인가: 한국 기준으로 따졌을 때

솔직히 가격만 보면 Hetzner가 더 쌉니다. €3.49에 RAM 4GB, NVMe, 대역폭 20TB짜리 플랜이 있거든요. 근데 문제가 있습니다. Hetzner는 데이터센터가 독일과 핀란드뿐입니다. 한국에서 유럽 서버로 요청 보내면 레이턴시가 200ms 넘게 나옵니다. 개인 봇이나 자동화 툴이라면 그나마 몰라도, 사용자가 직접 접속하는 서비스라면 체감이 확실히 다릅니다.

DigitalOcean은 UI가 깔끔하고 튜토리얼이 풍부하지만 서울 리전이 없고, 같은 가격에 스펙이 Vultr보다 떨어집니다. $4짜리 Droplet은 RAM 512MB에 대역폭도 500GB밖에 안 됩니다.

Vultr는 서울 리전을 직접 보유하고 있습니다. 아시아 DC가 필요한 경우 가장 현실적인 선택지 중 하나예요.

Vultr 대시보드 서울 리전 선택

Vultr 플랜 구조: $5짜리랑 $6짜리, 뭐가 다른가

Vultr에는 크게 두 가지 입문 플랜이 있습니다.

Regular Performance ($5/월)

vCPU 1코어, RAM 1GB, SSD 25GB, 대역폭 1TB
일반 SSD, 구형 Intel CPU
정적 사이트나 봇처럼 I/O 부담 적은 곳에 적합

High Performance AMD ($6/월)

vCPU 1코어, RAM 1GB, NVMe SSD 25GB, 대역폭 2TB
최신 AMD CPU + NVMe, $1 더 비싸지만 디스크 I/O가 체감상 다릅니다
벤치마크 기준으로 4K 랜덤 IOPS가 약 118,000 — DigitalOcean(54,000)의 2배 이상

데이터베이스를 같이 돌리거나, 파일 입출력이 잦은 작업이라면 $6짜리 High Performance가 맞습니다. 단순 봇이나 정적 사이트라면 $5짜리로 충분해요.

참고로 $2.50짜리 플랜도 있는데, 이건 IPv4 주소가 없는 IPv6 전용 플랜입니다. 일반 웹서버로 쓰기엔 불편해서 입문자에게는 비추합니다.

경쟁사 비교: 같은 가격대, 실제 스펙 차이

제공업체	월 요금	RAM	스토리지	대역폭	서울 DC
Vultr (Regular)	$5	1GB	25GB SSD	1TB	O
Vultr (High Perf)	$6	1GB	25GB NVMe	2TB	O
DigitalOcean	$4	512MB	10GB SSD	500GB	X
Hetzner	~$3.80	4GB	NVMe	20TB	X (유럽만)
Linode/Akamai	$5	1GB	25GB SSD	1TB	X (도쿄만)

Hetzner가 스펙상 압도적이지만, 2026년 4월에 가격이 30~35% 올랐고 무엇보다 아시아 DC가 없습니다. 한국이나 아시아 사용자가 대상인 서비스라면 Vultr가 현실적입니다.

서울 리전 기준으로 레이턴시가 도쿄보다 확실히 낮게 나왔습니다.

실제 서버 세팅: 가입부터 SSH 접속까지

처음 VPS 세팅할 때 어디서 멈추는지 예상이 돼서, 막히는 지점 위주로 적었습니다.

1단계: 가입과 결제 수단 등록

신용카드나 PayPal로 결제 수단을 등록해야 서버를 만들 수 있습니다. Vultr 가입하기로 가입하시면 신규 가입 시 30일 동안 자유롭게 사용할 수 있는 300달러 무료 크레딧이 즉시 지급됩니다. 300달러 크레딧 중 사용하지 않는 부분은 30일 후 소멸됩니다. 300달러 만큼 무료로 테스트해볼 수 있습니다.

2단계: "Deploy +" 클릭

대시보드 우측 상단의 "Deploy +" 버튼 → "Deploy New Server" 선택합니다.

3단계: Cloud Compute 선택

서버 유형은 "Cloud Compute (Shared CPU)"를 고릅니다. 입문자 기본 선택이에요. Bare Metal이나 Dedicated는 가격이 훨씬 높고, 일반 프로젝트엔 필요 없습니다.

4단계: 리전 선택 — 여기서 많이 실수합니다

기본값이 미국 리전으로 되어 있는 경우가 많습니다. 반드시 Seoul을 직접 클릭해서 선택하세요. 한국 사용자 대상이면 Seoul, 그게 아니라면 Tokyo도 괜찮습니다.

Vultr 서버 배포 시 Seoul 리전 선택 화면

5단계: OS 선택

Ubuntu 24.04 LTS를 권장합니다. 한국어 자료가 가장 많고, 패키지 설치도 편합니다. Debian이나 CentOS도 선택할 수 있지만 입문자라면 Ubuntu로 시작하는 게 무난합니다.

6단계: 플랜 선택

Regular $5 또는 High Performance $6. 위에서 정리한 기준대로 선택하면 됩니다.

7단계: SSH 키 등록 (필수에 가깝습니다)

"Add SSH Key" 항목이 있습니다. 로컬에서 아래 명령어로 키를 생성하고, 공개키를 붙여넣으세요.

ssh-keygen -t ed25519 -C "my-vultr-key"
cat ~/.ssh/id_ed25519.pub

비밀번호 로그인은 브루트포스 공격에 취약합니다. SSH 키 방식이 훨씬 안전하고, 접속도 더 편합니다.

8단계: Deploy Now

호스트명을 입력하고 "Deploy Now" 클릭. 60초 이내로 서버가 활성화됩니다. 대시보드에서 IP 주소를 확인하면 됩니다.

SSH 접속

ssh root@[서버_IP_주소]

SSH 키를 등록했다면 비밀번호 없이 바로 접속됩니다. 처음 접속 시 호스트 키 확인 메시지가 나오면 yes 입력하면 됩니다.

Vultr 서버 SSH 접속 터미널 화면

입문자가 자주 하는 실수 4가지

1. 리전을 미국으로 두고 배포
가장 흔한 실수입니다. 배포 화면에서 Seoul을 직접 클릭해야 합니다.

2. 처음부터 비싼 플랜 선택
$5/$6에서 시작하고, 부족하면 업그레이드하면 됩니다. 처음부터 $24짜리 고를 필요 없어요.

3. 백업 설정 안 함
자동 백업은 플랜 요금의 20%를 더 내면 됩니다. $5 플랜이면 $1/월 추가. 처음 세팅할 때 켜두는 걸 권장합니다.

4. SSH 키 안 쓰고 비밀번호만 사용
비밀번호 로그인 상태로 두면 자동 브루트포스 공격을 계속 받습니다. SSH 키 등록은 배포 단계에서 미리 해두는 게 편합니다.

실제 사용자 평가: 장단점 솔직하게

좋은 점

서버 스핀업이 진짜 빠릅니다. 60초면 완료
시간 과금이라 테스트하고 삭제해도 몇 센트 수준
CPU 성능이 같은 가격대 DigitalOcean 대비 2~2.5배 높음 (Geekbench 기준)
서울 리전 직접 보유

신경 써야 할 점

고객 지원이 느립니다. 티켓 기반이고, 긴급 대응은 어렵습니다
관리형 데이터베이스 서비스가 없음 (DigitalOcean은 제공)
UI가 영어 전용
일부 사용자가 환불 과정에서 불만을 보고한 사례 있음

고객 지원이 느린 건 실제로 불편한 부분입니다. 급하게 뭔가 해결해야 할 때 답변이 늦으면 답답하죠. 다만 VPS 특성상 서버 자체 세팅은 결국 본인이 해야 하는 경우가 많아서, 지원 품질보다 문서와 커뮤니티 활용이 더 현실적입니다.

자주 묻는 질문

Q. Vultr 한국어 지원이 되나요?
아니요, UI와 고객지원 모두 영어 전용입니다. 다만 서버 세팅 자체는 Ubuntu 기준으로 한국어 자료가 워낙 많아서 크게 불편하지 않습니다.

Q. $2.50 플랜은 뭐가 문제인가요?
IPv4 주소가 없는 IPv6 전용 플랜입니다. 내부 테스트나 특수한 용도 외에는 일반 웹서버·API 서버로 쓰기 어렵습니다. 리전 제한도 있습니다.

Q. 무료로 써볼 수 있나요?
신규 가입 시 $100~$300 크레딧이 지급되는 프로모션이 자주 있습니다. $5/월 서버면 크레딧으로 몇 달 테스트할 수 있어요. 단, 크레딧 유효기간이 30일~12개월로 코드마다 다르니 확인이 필요합니다.

Q. 서버를 실수로 켜놓으면 계속 과금되나요?
네, 시간 단위 과금이라 서버가 존재하는 한 계속 청구됩니다. 테스트가 끝나면 Destroy(삭제)를 해야 과금이 멈춥니다. Stop(중지)은 과금이 계속 됩니다.

Q. WordPress 운영하려면 어떤 플랜이 필요한가요?
캐시 플러그인(예: WP Rocket, W3TC)을 쓴다는 전제로 $5/월 1GB 플랜에서 가능합니다. 방문자가 많아지면 $10/월 2GB로 올리는 걸 권장합니다.

마무리

VPS 입문이 어렵게 느껴지는 이유 중 하나가 "뭘 골라야 할지 모르는 것"인데, 한국에서 쓸 서버를 찾고 있다면 Vultr 서울 리전이 현실적인 시작점입니다. $5~$6 구간에서 시작해서 직접 써보고, 부족하면 그때 업그레이드하면 됩니다.

시간 과금이라 잘못 골랐어도 손해가 크지 않습니다. 가장 빠른 방법은 그냥 하나 만들어보는 거예요.

Claude Code 서브에이전트 커스텀 만들기: 내 AI팀 구성하는 단계별 가이드

roundfigure — Mon, 22 Jun 2026 01:17:07 +0900

저도 처음엔 Claude Code를 그냥 "채팅으로 코드 짜는 도구" 정도로만 쓰고 있었어요. 그러다 서브에이전트를 알게 됐는데, 솔직히 말하면 이게 진짜 게임체인저였습니다. 코드 리뷰, 보안 감사, 테스트 작성을 각각 전문화된 에이전트에게 맡기면 — 메인 대화창이 로그로 도배되는 일도 없고, 작업마다 딱 필요한 권한만 주니까 훨씬 안전하거든요.

Claude Code 서브에이전트가 뭔지, 어떻게 만드는지, 어떤 실수를 피해야 하는지 순서대로 정리해봤습니다.

.claude/agents/ 폴더 구조 — 전문화된 AI 팀 구성

서브에이전트가 뭔지부터 짚고 가면

서브에이전트는 .claude/agents/ 폴더에 마크다운 파일로 정의하는 전문화된 AI 어시스턴트입니다. 핵심은 독립된 컨텍스트 윈도우예요. 메인 대화에서 분리되어 자기 공간에서 작업하고, 결과 요약만 돌려보내죠.

Claude 공식 문서에는 이렇게 나와 있어요.

"Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again: the subagent does that work in its own context and returns only the summary."

파일 100개를 뒤지는 작업을 메인 세션에서 하면 컨텍스트가 금방 터집니다. 서브에이전트에 맡기면 그 작업은 별도 공간에서 돌고, 메인 세션엔 깔끔한 요약만 남아요. 에이전트마다 다른 Claude 모델(Haiku, Sonnet, Opus)을 지정할 수 있어서 비용 최적화도 됩니다.

기존 Task 툴과의 차이가 궁금하실 수 있어요. Task 툴은 그때그때 임시 세션을 만들어 쓰는 방식인데, 서브에이전트는 고유한 정체성과 전문성을 미리 선언해두고 재사용합니다. "코드 리뷰가 필요하면 항상 이 에이전트에게" 같은 패턴이 가능해지는 거예요.

YAML frontmatter 구조 — 필수는 딱 두 개

파일 구조는 간단합니다. YAML frontmatter + 시스템 프롬프트 본문이 전부예요.

---
name: agent-identifier          # 필수: 소문자-하이픈 형식
description: |                  # 필수: Claude가 언제 이 에이전트를 쓸지 결정하는 근거
  When and why Claude should use this agent.
  "MUST BE USED for..." 패턴이 자동 위임에 효과적.
model: sonnet                   # 선택: sonnet | opus | haiku
tools: [Read, Edit, Bash]       # 선택: 허용 도구 목록 (생략 시 전체 허용)
disallowedTools: [Write]        # 선택: 명시적 차단 목록
permissionMode: default         # 선택: default | acceptEdits | dontAsk | bypassPermissions
maxTurns: 10                    # 선택: 최대 agentic 턴 수
background: false               # 선택: true면 항상 병렬 실행
---
시스템 프롬프트 본문

필수 필드는 name과 description 두 개뿐입니다. 나머지는 전부 선택이에요. 근데 tools 필드는 꼭 챙기는 걸 권장해요. 생략하면 모든 도구에 접근하게 돼서, 리뷰어가 실수로 파일을 수정하는 상황이 생길 수 있거든요.

description 필드가 생각보다 중요합니다. Claude는 이걸 읽고 "지금 이 작업에 어떤 에이전트를 불러야 하는지" 판단해요. "MUST BE USED for..." 패턴에 구체적인 키워드를 포함하면 자동 위임이 훨씬 잘 됩니다.

YAML frontmatter 구조 — 필수 2개 + 선택 필드 완전 해부

서브에이전트 만드는 두 가지 방법

방법 1: /agents 명령으로 GUI에서 만들기

Claude Code에서 /agents를 입력하면 Library 탭이 열립니다. "Create new agent"를 선택하고, 스코프(프로젝트 or 사용자), 역할과 목적을 설명하면 Claude가 description, name, 시스템 프롬프트를 자동으로 생성해줘요. 도구 목록과 모델을 검토한 뒤 저장하면 재시작 없이 바로 적용됩니다.

처음 만드는 분들한테는 이 방법이 제일 편해요.

방법 2: 직접 .md 파일 작성

.claude/agents/ 폴더에 .md 파일을 직접 만드는 방법입니다.

.claude/
└── agents/
    ├── code-reviewer.md
    ├── test-writer.md
    └── security-auditor.md

저장 위치에 따라 스코프가 달라져요.

위치	스코프	특징
`.claude/agents/`	프로젝트 전용	Git으로 팀 공유 가능
`~/.claude/agents/`	전체 개인 프로젝트	모든 세션에서 재사용

팀 프로젝트라면 .claude/agents/에 두고 Git에 포함시키는 게 좋습니다. 팀 전체가 동일한 에이전트를 쓸 수 있거든요.

실전 서브에이전트 예시 3가지

말로만 하면 감이 안 오죠. 바로 쓸 수 있는 예시입니다.

코드 리뷰어 (읽기 전용 — 가장 안전한 시작점)

---
name: code-reviewer
description: MUST BE USED for code review, PR review, security audit,
  and refactor suggestions on TypeScript/Next.js code. Read-only — never writes files.
tools: Read, Grep, Glob, Bash
model: sonnet
---

# Role
Senior code-reviewer specializing in TypeScript and Next.js.

# Context discovery
1. Read CLAUDE.md at repo root
2. Run: git diff main...HEAD
3. Read changed files and their imports

# Workflow
For each changed file: Correctness → Security → Performance → Maintainability

# Output format
## Critical (must fix before merge)
## Warnings (should fix)
## Suggestions (optional improvement)
## Verdict: MERGE_READY | NEEDS_WORK | BLOCKING

tools에 Write가 없는 게 포인트예요. 리뷰어가 파일을 직접 수정하는 일은 없어야 하니까요.

보안 감시자 (Opus 모델 사용)

---
name: security-auditor
description: Security-focused code reviewer. Use proactively after writing
  authentication, authorization, or data-handling code.
tools: Read, Grep, Glob
model: opus
---

Role: Senior application security engineer reviewing code for vulnerabilities before it ships.
Focus: SQL injection, XSS, authentication bypass, sensitive data exposure, dependency risks.
Output: severity-ranked findings with OWASP category and remediation steps.

미묘한 패턴 인식이 중요한 보안 감사에는 Opus 모델을 씁니다. 비용이 더 들지만, 여기서 Haiku를 쓰는 건 좀 아깝죠.

테스트 작성자

---
name: test-writer
description: Generates unit and integration tests for new or modified code.
tools: Read, Write, Edit, Bash, Glob
model: sonnet
---

Generate comprehensive tests covering happy paths, edge cases, and error conditions.
Follow existing test patterns in the project. Run tests after writing to verify they pass.

메인 세션에서 3개 에이전트 동시 병렬 실행 흐름도

병렬 실행 — 여러 에이전트를 동시에 돌리는 방법

메인 오케스트레이터가 Task 툴을 여러 번 연속 호출하면 병렬 실행이 됩니다. 각 에이전트는 독립된 컨텍스트에서 동시에 작동하고, 모두 완료되면 결과를 통합해요.

메인 세션
  ├── Task → code-reviewer (독립 컨텍스트, 병렬)
  ├── Task → security-auditor (독립 컨텍스트, 병렬)
  └── Task → test-writer (독립 컨텍스트, 병렬)
       ↓ (모두 완료 후)
  결과 통합 → 메인 세션

실용적인 상한선은 3~5개 동시 실행입니다. 그 이상 넘어가면 결과 병합에 드는 시간이 병렬 실행의 이득을 상쇄하기 시작해요.

참고로 HAMY.xyz 사례에서는 단일 /code-review 명령 하나로 9개 에이전트를 동시에 실행합니다 — test-runner, linter, code-reviewer, security-reviewer, quality-reviewer, test-quality-reviewer, performance-reviewer, dependency-reviewer, simplicity-reviewer. 제안의 약 75%가 실용적이라고 저자는 평가하더라고요.

background: true 필드를 frontmatter에 지정하면 해당 에이전트는 항상 백그라운드로 실행됩니다. 린터처럼 항상 병렬로 돌아야 하는 에이전트에 유용해요.

서브에이전트 vs Hooks vs MCP — 뭘 써야 하나

헷갈리기 쉬운 부분인데, 역할 차이가 명확합니다.

구분	핵심 역할	언제 쓰나
서브에이전트	격리된 작업 위임	코드 탐색, 보안 감시, 조사 작업
Hooks	이벤트 기반 자동화 강제	파일 편집 후 포맷팅, 커밋 전 린트
MCP	외부 시스템 연결	GitHub API, Jira, DB, Sentry 등

서브에이전트의 실행은 모델 판단에 의존합니다. Hooks는 달라요 — "파일 편집 후 항상 포맷팅 실행"처럼 모델 판단 없이 강제로 실행됩니다. "이걸 AI가 알아서 판단해도 되는가"가 선택 기준이에요. 강제로 실행되어야 하면 Hooks, 유연하게 맡겨도 되면 서브에이전트.

자주 하는 실수 5가지

1. 서브에이전트가 자동으로 안 불린다

description 필드가 모호한 게 원인입니다. "MUST BE USED for code review on TypeScript..." 처럼 트리거 키워드를 구체적으로 써야 해요. 아니면 그냥 "Use the code-reviewer agent to audit this module"처럼 명시적으로 언급하는 것도 방법입니다.

2. 서브에이전트가 다른 서브에이전트를 호출하려 한다

서브에이전트는 중첩이 안 됩니다. 1단계까지만 허용돼요. 복잡한 체인이 필요하면 메인 세션에서 순차적으로 조율해야 합니다.

3. 토큰 비용이 예상보다 훨씬 많다

N개 에이전트를 병렬 실행하면 토큰 비용이 약 N배 증가합니다. Anthropic 문서 기준으로 서브에이전트 집약 워크플로우는 단일 세션 대비 최대 7배까지 올라가요. 간단한 작업은 그냥 단일 세션으로, 반복·단순 작업에는 Haiku 모델을 지정하는 식으로 조절하세요.

4. 컨텍스트가 60~70%를 넘어가면 성능이 떨어진다

흔히 "agent dumb zone"이라고 부르는 현상입니다. 컨텍스트 사용량이 60~70%를 넘으면 눈에 띄게 성능이 저하돼요. 50% 시점에서 수동으로 /compact를 실행하는 게 안전합니다.

5. 리뷰어가 항상 문제를 찾아낸다

"문제를 찾아라"고 프롬프트하면 실제로 없는 문제도 만들어냅니다. "정확성이나 요구사항에 영향을 미치는 문제만 플래그하라"처럼 범위를 제한해야 해요.

처음 시작한다면 이 순서로

코드 리뷰어부터 — 읽기 전용이라 가장 위험이 없습니다
테스트 작성자 추가 — 리뷰어가 익숙해지면 바로 이어서
리뷰어 → 테스트 작성자 순차 조율 패턴 구현
팀이 익숙해지면 보안 감시자, 문서화 에이전트 추가

1주일이면 실제로 효과를 평가하기에 충분합니다.

GitHub의 VoltAgent/awesome-claude-code-subagents 저장소에 100개 이상의 전문화 서브에이전트 예시가 공개돼 있어요. 처음 시작할 때 여기서 하나 가져다 쓰고 입맛에 맞게 수정하는 게 제일 빠릅니다.

서브에이전트 도입 추천 순서 로드맵 — 1주일이면 효과 검증 가능

직접 .claude/agents/ 폴더에 파일 하나 만들어서 써보세요. name과 description 두 줄만 있어도 일단 동작합니다. 정교하게 다듬는 건 써보면서 해도 늦지 않아요.

GitHub Copilot vs Claude Code 2026: 월 10달러 vs 100달러, 뭘 써야 하나

roundfigure — Sun, 21 Jun 2026 19:47:15 +0900

GitHub Copilot vs Claude Code 2026: 월 10달러 vs 100달러, 뭘 써야 하나

AI 코딩 도구를 고르는 게 이렇게 복잡한 적이 있었나 싶습니다. GitHub Copilot은 $10, Claude Code는 $100. 가격만 보면 답이 뻔한 것 같은데, 실제로 써보면 얘기가 달라져요. 2026년 지금, GitHub Copilot vs Claude Code를 놓고 진짜로 고민 중이라면 이 글이 도움이 될 겁니다.

GitHub Copilot vs Claude Code, 가격 차이만큼 성능도 다를까

솔직히 말하면 처음엔 저도 "10배 비싸면 10배 좋겠지"라는 단순한 생각을 했어요. 근데 실제로 두 도구를 비교해보니까 가격 차이보다 훨씬 근본적인 것에서 갈립니다. 아예 다른 도구라는 게 맞는 표현이에요.

GitHub Copilot은 VS Code, JetBrains, Neovim, Xcode 같은 IDE 안에 박혀서 인라인으로 코드를 제안합니다. 타이핑하는 순간 바로 다음 코드가 뜨는, 그 경험이 핵심이에요. Claude Code는 반대입니다. IDE가 없어요. 터미널에서 실행하고, 작업 지시를 내리면 알아서 계획 세우고, 실행하고, 검증합니다.

인라인 자동완성이 필요하면 Copilot. 대규모 작업을 통째로 맡기고 싶으면 Claude Code. 이 둘은 경쟁 구도가 아닌 거예요.

2026년 요금제, 실제로 얼마 내야 하나

GitHub Copilot과 Claude Code 요금제를 나란히 비교한 표 이미지

GitHub Copilot은 2026년 6월 1일부터 AI Credits 종량제로 전환했습니다. 구조가 조금 바뀌었어요.

Free: $0 (월 2,000회 완성, 프리미엄 요청 50개)
Pro: $10/월 ($15 상당 크레딧 포함)
Pro+: $39/월 ($70 상당, Opus 포함)
Max: $100/월 ($200 상당, 신규 모델 우선 접근)

중요한 건 코드 자동완성은 여전히 무제한 무료라는 점입니다. 크레딧은 Chat, 에이전트 모드, 코드 리뷰 같은 기능을 쓸 때 소모돼요. 라이트 유저라면 $10으로도 충분하지만, 에이전트 모드를 자주 쓰는 사람은 크레딧이 생각보다 빨리 달 수 있습니다.

Claude Code는 심플합니다.

Pro: $20/월 (연간 결제 시 $17)
Max 5x: $100/월 (Pro 대비 5배 사용량)
Max 20x: $200/월 (매일 집중 사용자용)

$20짜리 Pro가 사실 진입점이에요. 헤비유저가 되면 $100 Max로 올라가게 됩니다.

성능 차이, 숫자로 보면 꽤 충격적입니다

SWE-bench Verified라는 벤치마크가 있어요. 실제 GitHub 이슈를 AI가 얼마나 잘 해결하는지 측정하는 테스트입니다.

Claude Code (Opus 4.8): 88.6% (2026년 5월 28일 기준)
GitHub Copilot 에이전트 모드: 추정 60~70%

숫자로만 보면 Claude Code가 압도적입니다. 테스트 커버리지도 Claude Code 89% vs GitHub Copilot 71%로 차이가 나요. 멀티파일 처리에서도 갈립니다. Claude Code는 30개 이상 파일을 동시에 수정해도 안정적이고, Copilot 에이전트는 10개 초과하면 크로스-파일 의존성을 놓치는 사례가 보고됩니다.

Rakuten 사례가 인상적인데, Claude Code로 7시간 무인 리팩토링을 돌렸더니 40개 이상 파일의 deprecated API 패턴을 탐지하고, 교체하고, 테스트까지 통과시켰다고 합니다.

컨텍스트 창 차이가 왜 중요한가

컨텍스트 창 크기 비교 시각화 - Claude Code 100만 토큰 vs GitHub Copilot 32K~128K

Claude Code는 최대 100만 토큰 컨텍스트 창을 씁니다. 쉽게 말하면 코드베이스 전체를 한 번에 머릿속에 넣어두고 작업할 수 있다는 거예요. GitHub Copilot은 모델에 따라 32K~128K인데, 이를 보완하려고 검색 기반 Retrieval + Copilot Memory(프리뷰)를 씁니다.

대형 레거시 코드를 다뤄본 사람이라면 이 차이가 얼마나 큰지 바로 느낄 겁니다. 파일 A를 고칠 때 파일 B, C, D의 맥락을 다 들고 있어야 하는 상황에서 컨텍스트 창 크기가 결과를 갈라놓거든요.

결국 누가 뭘 써야 하나

GitHub Copilot Pro ($10)이 맞는 사람

하루 종일 IDE에서 코딩하고, 인라인 자동완성이 생산성의 핵심인 경우
비용이 최우선 — 프리랜서, 사이드 프로젝트, 스타트업 초기
GitHub PR 생성, 코드 리뷰 자동화가 중요한 팀
작업 대부분이 단일 파일 수정이나 짧은 함수 작성

Claude Code Max ($100)이 맞는 사람

수십~수백 개 파일에 걸친 아키텍처 변경이나 마이그레이션이 잦은 경우
터미널 중심 워크플로우 또는 CI/CD 파이프라인 자동화가 필요한 경우
Jira, Slack, Figma 같은 외부 툴 연동을 터미널 한 줄로 처리하고 싶은 경우
한국어로 자연어 명령해도 고품질 결과가 나오길 원하는 경우

2026년 고수들이 쓰는 방법: 둘 다

Copilot Pro + Claude Code Max 조합 워크플로우 다이어그램

국내 AI 코딩 도구 사용 순위를 보면 Cursor > Claude Code > Codex > GitHub Copilot > Cline 순입니다. Copilot이 해외에서 점유율 1위임에도 국내에서는 Claude Code, Cursor에 밀리는 현상이 흥미롭죠.

근데 실무 고수들 사이에서 떠오른 공식이 있어요. Copilot Pro $10으로 일상 자동완성, Claude Code Max $100으로 대형 작업. 두 도구는 작동 영역이 겹치지 않아서 충돌 없이 병행 사용이 가능합니다.

Copilot: IDE 내에서 함수 작성 중 인라인 자동완성, 빠른 유닛 테스트 생성, PR 설명 초안
Claude Code: 레거시 API 마이그레이션(40개+ 파일), 새 기능 모듈 전체 설계·구현, 보안 감사

2026년 2월에는 GitHub Copilot Pro+ 이상에서 Claude를 외부 에이전트로 직접 위임하는 기능도 GA됐습니다. Copilot 워크플로우 안에서 Claude Code를 부르는 구조도 가능해진 거예요.

국내 기술 블로그 Mimul Tech Blog에서도 비슷한 전략을 권장합니다. "도구를 조합하는 사람이 더 좋은 코드를 만들 확률이 높다"는 말이 딱 맞아요.

자주 묻는 질문

Q. Claude Code에는 인라인 자동완성이 없나요?
맞아요. Claude Code는 터미널 기반 에이전트라 IDE 인라인 완성은 지원하지 않습니다. 인라인 자동완성이 필요하면 Copilot을 함께 써야 합니다.

Q. GitHub Copilot Pro $10으로 Claude 모델을 쓸 수 있나요?
Pro는 기본 모델 위주이고, Claude Opus 같은 프리미엄 모델은 Pro+ ($39) 이상에서 사용할 수 있습니다. 다만 크레딧 소모가 빠를 수 있어요.

Q. Claude Code가 한국어 명령을 잘 이해하나요?
네. 국내 개발자들 사이에서 "한국어로 명령해도 고품질 결과가 나온다"는 평가가 많습니다. 특히 복잡한 작업 지시를 자연어로 내릴 때 Claude Code의 강점이 드러납니다.

지금 당장 하나만 고른다면, 인라인 자동완성에 만족하고 있는 사람은 Copilot Pro에 머물고 Claude Code는 무료 플랜으로 맛만 봐도 됩니다. 반대로 대규모 레거시 마이그레이션이나 복잡한 리팩토링 작업이 자주 있다면 Claude Code Max $100이 오히려 시간당 비용이 낮을 수 있어요.

두 도구 모두 지금 무료 플랜이 있으니, 직접 돌려보고 결정하는 게 제일 빠릅니다.

Claude Code Hooks 완벽 가이드

roundfigure — Sun, 21 Jun 2026 19:04:09 +0900

Claude Code Hooks 완벽 가이드

Claude Code를 쓰다 보면 한 가지 답답한 순간이 옵니다. "매번 Prettier 실행해달라고 말해야 하나?" 같은 생각이요. Claude Code Hooks는 바로 그 지점을 해결합니다. AI한테 부탁하는 게 아니라, 특정 시점에 명령이 자동으로 실행되도록 못을 박아두는 방식입니다.

Claude Code Hooks 개요 다이어그램 — 수명주기 이벤트에서 Hook이 트리거되는 흐름

Claude Code Hooks가 하는 일

공식 문서에는 이렇게 적혀 있습니다.

"Hooks provide deterministic control over Claude Code's behavior, ensuring certain actions always happen rather than relying on the LLM to choose to run them."

번역하면 이렇습니다. Claude가 "기억해서" 해주길 기다리는 게 아니라, 반드시 실행된다를 보장하는 레이어입니다.

저도 처음엔 CLAUDE.md에 "파일 수정 후 꼭 black 실행해줘"라고 써뒀는데, 가끔 빠뜨리더라고요. Hooks를 쓰고 나서는 그 걱정이 사라졌습니다.

2026년 현재 v2.1.141+ 기준으로 27~30개의 수명주기 이벤트를 지원합니다. 다섯 가지 핸들러 타입도 있어요.

타입	설명
`command`	셸 명령어. stdin으로 JSON 수신
`http`	HTTP POST 엔드포인트
`mcp_tool`	MCP 서버 툴 호출
`prompt`	단발성 LLM 평가 (최대 30초)
`agent`	툴 접근 가능한 서브에이전트 (최대 60초)

핵심 이벤트 5가지 — 이것만 알면 시작 가능

PreToolUse: 가장 강력한 보안 게이트

Claude가 툴을 실행하기 직전에 발동합니다. exit 2로 아예 차단할 수 있어서, 5가지 이벤트 중에 제일 강력합니다.

{
  "hook_event_name": "PreToolUse",
  "tool_name": "Bash",
  "tool_input": { "command": "rm -rf dist/" }
}

이런 JSON이 stdin으로 들어오고, 스크립트가 exit 2를 반환하면 해당 명령은 실행되지 않습니다. git push --force main이나 DROP TABLE 같은 걸 원천 차단하는 데 딱입니다.

PostToolUse: 코드 포맷팅 자동화의 핵심

툴이 성공적으로 끝난 뒤 실행됩니다. 차단은 안 되고, 피드백이나 추가 작업만 가능합니다. 포맷터를 여기서 연결해두면 파일 수정할 때마다 자동으로 돌아갑니다.

Stop: Claude 응답 완료 후

Claude가 응답을 마쳤을 때 실행됩니다. exit 2로 계속 작업을 강제할 수도 있고, macOS 알림을 띄우는 데도 씁니다.

PreCompact / PostCompact: 컨텍스트 압축 전후

컨텍스트 윈도우가 가득 찼을 때 압축 직전/직후에 발동합니다. PreCompact에서 트랜스크립트를 백업해두면 중요한 작업 흐름을 잃지 않아요. manual(사용자가 /compact 직접 실행)과 auto(자동 압축)로 구분해서 다르게 처리할 수도 있습니다.

Notification: 관찰 전용 이벤트

permission_prompt, auth_success, elicitation_dialog 같은 알림이 발송될 때 실행됩니다. 차단은 안 되고, Slack 채널로 전달하거나 데스크탑 알림으로 바꾸는 용도로 씁니다.

5가지 핵심 이벤트 수명주기 타임라인 — PreToolUse → 툴 실행 → PostToolUse → Stop 흐름

settings.json 설정 방법

설정 파일은 두 곳에 둘 수 있습니다.

위치	범위	팀 공유
`~/.claude/settings.json`	사용자 전역	불가
`.claude/settings.json`	프로젝트 단위	가능 (git 커밋)
`.claude/settings.local.json`	프로젝트 단위 (개인)	불가 (gitignore)

구조는 3단 중첩입니다. 이벤트 이름 → 매처 그룹 배열 → 핸들러 배열 순서입니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/security-check.sh"
          }
        ]
      }
    ]
  }
}

매처(Matcher)는 어떤 툴에 반응할지 필터링합니다. "Bash"는 Bash 툴만, "Edit|Write"는 둘 다, "mcp__.*__write.*"는 모든 MCP 서버의 write 계열 툴에 반응합니다.

종료 코드는 간단합니다. 0이면 성공, 2면 차단(stderr를 Claude에게 전달), 그 외 숫자면 오류를 표시하되 실행은 계속합니다.

settings.json 파일 구조 시각화 — 이벤트, 매처, 핸들러 3단 계층도

바로 쓸 수 있는 실전 설정 4가지

1. 파일 수정 시 자동 포맷팅

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "bash -c 'if [[ \"$FILE_PATH\" == *.py ]]; then black --quiet \"$FILE_PATH\"; elif [[ \"$FILE_PATH\" == *.js ]] || [[ \"$FILE_PATH\" == *.ts ]]; then npx prettier --write \"$FILE_PATH\"; fi'"
          }
        ]
      }
    ]
  }
}

Python이면 Black, JS/TS면 Prettier가 자동으로 돌아갑니다. 매번 수동으로 실행할 필요가 없어집니다.

2. 위험 명령어 차단 스크립트

#!/bin/bash
# .claude/hooks/security-gate.sh
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r ".tool_input.command")

DANGEROUS_PATTERNS="rm\s+-rf\s+/|git\s+push\s+(-f|--force)\s+(origin\s+)?main|git\s+reset\s+--hard|DROP\s+TABLE"

if echo "$CMD" | grep -qE "$DANGEROUS_PATTERNS"; then
  echo "BLOCKED: 위험 명령어 감지: $CMD" >&2
  exit 2
fi

rm -rf /, git push --force main, git reset --hard, DROP TABLE을 차단합니다. PreToolUse에 Bash 매처로 연결해두면 됩니다.

3. .env 파일 보호

#!/usr/bin/env python3
import json
import sys

input_data = json.load(sys.stdin)
file_path = input_data.get("tool_input", {}).get("file_path", "")

dangerous_paths = [".env", ".env.local", "secrets.json", "credentials.json"]
if any(pattern in file_path for pattern in dangerous_paths):
    print(f"차단: {file_path}는 민감 파일입니다", file=sys.stderr)
    sys.exit(2)
sys.exit(0)

4. 작업 완료 알림 (macOS)

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude 작업 완료\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

Linux는 notify-send "Claude Code" "작업이 완료되었습니다"로 바꾸면 됩니다.

실전 설정 예시 스크린샷 — settings.json 파일과 터미널에서 Hook이 실행되는 화면

Hooks vs MCP vs 서브에이전트, 뭐가 다른가

솔직히 말하면 처음에 이 셋이 헷갈렸습니다.

특성	Hooks	MCP	서브에이전트
역할	강제 집행	외부 툴 연결	독립 작업 위임
트리거	이벤트 기반 (자동)	툴 호출 시	명시적 생성
차단 능력	있음 (exit 2)	없음	없음

기준은 이렇게 잡으면 됩니다.

Hooks를 쓸 때: 포맷팅, 린트, 검증처럼 항상 실행되어야 하는 규칙. "AI가 기억하길 바라는" 게 아니라 반드시 실행되어야 할 때.

MCP를 쓸 때: GitHub, Jira, 데이터베이스 등 외부 시스템 연결. 외부 데이터를 가져오는 작업.

서브에이전트를 쓸 때: 코드베이스 탐색, PR 리뷰처럼 깊은 탐색 작업. 메인 컨텍스트를 오염시키지 않고 독립적으로 처리해야 할 때.

MCP 툴도 mcp__<server>__<tool> 형식의 툴명으로 매처에 잡히기 때문에, MCP 서버의 쓰기 작업에도 동일한 보안 게이트를 걸 수 있습니다.

보안 주의사항: 가볍게 보면 안 됩니다

CVE-2025-59536 — Check Point Research가 2026년 초에 발견한 취약점입니다. 악성 저장소의 .claude/settings.json에 숨겨진 SessionStart hook이 자동 실행되어 역쉘(reverse shell)을 설치하거나 API 토큰을 탈취할 수 있다는 내용입니다. Anthropic은 현재 버전에서 패치했지만, 로직 자체는 여전히 유효합니다.

신뢰하지 않는 저장소를 클론할 때는 .claude/ 디렉터리를 코드와 똑같이 검토해야 합니다. .claude/settings.json을 "설정 파일"이 아니라 "실행 코드"로 보는 게 맞습니다.

성능 측면에서는 PostToolUse hook이 파일 편집마다 실행되기 때문에, 500ms 이상 걸리는 hook은 체감 지연을 일으킵니다. 실전에서 95개 hook을 운용해도 각 200ms 이내면 지연이 없다는 사례가 있습니다. 비차단 작업은 async: true로 백그라운드 실행을 권장합니다.

타임아웃 기본값도 알아두세요. command, http, mcp_tool은 600초, prompt는 30초, agent는 60초입니다.

보안 주의사항 요약 인포그래픽 — CVE-2025-59536 공격 흐름과 대응 방법

자주 묻는 질문

Q. settings.json을 git에 커밋해도 되나요?

.claude/settings.json은 커밋해서 팀과 공유할 수 있습니다. 단, 민감한 API 토큰이나 경로가 담긴 개인 설정은 .claude/settings.local.json에 넣고 gitignore로 제외해야 합니다.

Q. hook이 실패하면 어떻게 되나요?

종료 코드 2면 해당 이벤트가 차단되고 stderr가 Claude에게 전달됩니다. 그 외 0이 아닌 코드는 오류를 표시하되 실행은 계속됩니다. PostToolUse는 차단 자체가 불가능합니다.

Q. 모든 툴에 hook을 걸려면?

매처를 "*"나 ""로 설정하거나 아예 생략하면 됩니다. 모든 툴 이벤트에 반응합니다.

Q. prompt 타입 hook은 언제 쓰나요?

yes/no 판단이 필요한 경우입니다. 예를 들어 Stop hook에서 "테스트가 통과했는지" LLM에게 물어보고, 미통과 시 exit 2로 차단해서 Claude가 계속 작업하도록 강제하는 패턴에 씁니다. 최대 30초 타임아웃이 있습니다.

직접 하나씩 설정해보는 게 제일 빠릅니다. PostToolUse에 간단한 포맷터 하나 연결해보는 것부터 시작하면 금방 감이 잡혀요. 더 복잡한 보안 게이트나 테스트 자동 실행 패턴이 궁금하다면, DEV Community의 "20+ Examples" 글이나 Pixelmojo의 "6 Production Patterns"를 같이 보시길 권합니다.

.cursorrules 완전 가이드: Cursor AI 생산성 제대로 높이는 설정법 (2026)

roundfigure — Sat, 20 Jun 2026 02:31:22 +0900

.cursorrules 열심히 작성해서 쓰고 있다면, 지금 당장 확인할 게 있어요.

2026년 기준 Cursor Agent 모드에서 구형 .cursorrules 파일은 규칙을 아예 무시합니다. 동일한 규칙 9개를 두 형식으로 테스트했을 때 구형 .cursorrules는 0/9 준수, 신형 .mdc 방식은 9/9 준수라는 결과가 나왔어요. 열심히 써둔 규칙이 Agent 모드에선 작동 안 하고 있을 수 있습니다.

구형 .cursorrules vs 신형 .mdc — Agent 모드 준수율 비교

.cursorrules가 뭔지 먼저 짚고 가면

Cursor AI가 코드를 생성하기 전에 참조하는 "프로젝트 지침서"예요. 프로젝트 루트에 파일 하나 두면 새 채팅 세션마다 "우리 프로젝트는 React 18, TypeScript strict, 함수는 30줄 이내야"라고 반복 설명 안 해도 됩니다. Cursor가 알아서 읽고 적용해요.

AI 제안 수용률이 규칙 없을 때 약 30% 수준에서, 잘 작성된 규칙을 적용하면 80% 이상으로 올라간다는 데이터가 있어요. Salesforce는 20,000명 규모 도입 후 개발 속도가 30% 이상 향상됐다고 밝혔고요. 팀 차원에서 Git에 커밋해두면 신규 입사자도 처음부터 동일한 AI 경험을 받을 수 있다는 것도 장점입니다.

저도 처음엔 .cursorrules 파일 하나만 쓰고 있었는데, Agent 모드를 쓰기 시작하면서 규칙이 전혀 안 먹히는 걸 느끼고 나서야 신형으로 갈아탔어요.

구형 vs 신형 — 뭐가 달라졌나

2025년 중반부터 Cursor는 .cursor/rules/*.mdc 디렉터리 방식을 공식 권장 포맷으로 내놨습니다. 구형 .cursorrules는 Chat 모드에서는 여전히 동작하지만, Agent 모드에선 완전히 무시돼요.

	구형 .cursorrules	신형 .cursor/rules/*.mdc
위치	프로젝트 루트	.cursor/rules/ 하위
형식	마크다운	YAML 프론트매터 + 마크다운
Agent 모드	작동 안 함	완전 지원
활성화 방식	항상 전체 로드	4가지 모드 선택 가능
팀 공유	Git 커밋으로 가능	동일 + 더 세밀한 제어

둘이 동시에 존재할 경우 .mdc가 우선 적용됩니다. Agent 모드 쓴다면 지금 당장 마이그레이션하는 게 맞아요.

신형 .mdc 4가지 활성화 모드

.mdc 파일의 YAML 프론트매터에서 4가지 모드 중 하나를 고릅니다. 이게 구형과 가장 크게 다른 점이에요 — 불필요한 규칙을 매번 로드하지 않아서 토큰 낭비를 줄일 수 있습니다.

Always Apply (alwaysApply: true) — 모든 대화에서 항상 로드. 200단어 이내로 짧게 유지하는 게 좋습니다. 기술 스택 선언, 전사 코딩 표준처럼 항상 필요한 것만.

Auto Attached (glob 패턴 지정) — 특정 파일이 컨텍스트에 들어올 때만 자동 활성화. src/components/**/*.tsx 같이 지정하면 컴포넌트 파일 작업할 때만 React 규칙이 붙어요. 200~500단어 범위.

Agent Requested (description만 있고 나머지 없음) — AI가 description을 읽고 관련성 있으면 스스로 불러옵니다. Stripe, Supabase처럼 특정 도구 쓸 때 자동으로 관련 규칙이 붙는 방식.

Manual (@rule-name으로 명시 호출) — 배포 체크리스트나 코드 리뷰 기준처럼 가끔만 쓰는 규칙에 씁니다.

.mdc 4가지 활성화 모드

실제로 어떻게 쓰는가 — 바로 쓸 수 있는 예시

기본 Always Apply 규칙 (스택 선언)

---
description: Core project foundation
globs: []
alwaysApply: true
---

## 기술 스택
- Frontend: React 18, TypeScript 5.4, Vite 5, Tailwind CSS 3
- Backend: Node.js 20, Express 4, Prisma 5, PostgreSQL 15

## 핵심 원칙
- 함수 길이: 30줄 이내
- 파라미터: 4개 이내 (초과 시 객체로 묶기)
- 에러 처리: try/catch 없이 외부 호출 금지
- 커밋 전 반드시 사용자 확인 요청

React + TypeScript 컴포넌트 규칙

---
description: React TypeScript component standards
globs: ["src/components/**/*.tsx", "src/pages/**/*.tsx"]
alwaysApply: false
---

- 함수형 컴포넌트만 사용, React.FC<Props> 타입 명시
- 파일명: PascalCase (예: UserProfile.tsx)
- any 타입 사용 금지 → unknown 또는 구체적 타입 사용
- 재사용 로직은 custom hooks로 분리 (use 접두사)
- 서버 컴포넌트 기본, 클라이언트 컴포넌트는 "use client" 명시

여기서 핵심은 "깔끔하게 써라" 같은 모호한 지시를 쓰지 않는 거예요. "함수는 30줄 이내, 파라미터는 4개 이내"처럼 측정 가능한 기준을 써야 AI가 명확하게 따릅니다. 한국 개발팀 실무 사례에서도 이 방식이 가장 효과적이라고 나왔어요.

Agent 안전 규칙 (꼭 추가 권장)

---
description: Agent safety rules
globs: []
alwaysApply: true
---

- .env, package.json 등 설정 파일 삭제 금지 (명시적 확인 없이)
- 데이터베이스 마이그레이션은 사용자 승인 후 실행
- 보안 취약점 발견 시 즉시 중단하고 보고

Agent 모드가 강력한 만큼 실수도 강력해질 수 있거든요. 이 규칙은 짧게라도 꼭 넣는 걸 권장합니다.

권장 .cursor/rules/ 폴더 구조

팀에서 쓸 때 알아야 할 것

.cursor/rules/ 폴더는 반드시 Git에 커밋하세요. 팀원 모두가 동일한 AI 경험을 받고, 코드 스타일도 자연스럽게 일관됩니다. 개인 취향 설정은 .gitignore에 넣으면 됩니다.

규칙을 직접 처음부터 쓰기 부담스럽다면 awesome-cursorrules(GitHub 별 40,000+)를 참고하세요. React, Next.js, Python, Go, Flutter까지 13개 카테고리에 걸쳐 커뮤니티가 검증한 템플릿이 모여 있습니다.

몇 가지 실용 팁이 더 있어요. 규칙 파일 수정 후 반영이 안 되면 Cursor를 재시작하는 게 먼저입니다(알려진 UI 버그). .cursorrules는 Chat/Agent에만 적용되고 Tab 자동완성과 인라인 편집(Ctrl+K)에는 적용 안 돼요. Glob 패턴에서 중괄호 {src,lib}/** 문법은 Cursor에서 동작하지 않으니 주의하세요.

Rule of Three도 유용한 기준이에요 — AI에게 같은 지시를 3번 반복했다면 그건 규칙 파일에 넣어야 한다는 신호입니다.

Cursor 말고 Windsurf를 쓰는 분들도 Cascade Rules 기능이 있어요. 비슷한 개념이지만 파일 형식이 다르니 공식 문서를 확인하는 게 좋습니다.

Agent 모드를 쓰고 있다면, 지금 .cursorrules 파일이 있는지 확인하고 .cursor/rules/ 디렉터리로 옮기는 게 오늘 할 일 1번이에요.

Windsurf vs Cursor: 2026년 AI 코드 에디터, 실제로 써보니 이게 달랐다

roundfigure — Sat, 20 Jun 2026 02:10:52 +0900

올해 AI 코딩 도구 업계에서 가장 드라마틱한 일이 벌어진 게 Windsurf였어요. OpenAI가 30억 달러에 인수하려다 Microsoft IP 갈등으로 무산됐고, Google이 CEO 포함 핵심 인력을 24억 달러에 낚아채 갔습니다. 제품 자체는 Cognition이 가져갔고요. 72시간 안에 세 회사로 쪼개진 셈이에요.

근데 이 소용돌이 속에서도 "Cursor vs Windsurf 뭐가 낫냐"는 질문은 계속 쏟아지고 있습니다. 저도 두 도구를 번갈아 써봤는데, 결론부터 말하면 어떤 게 더 좋다가 아니라 어떤 상황에 쓰냐의 문제예요.

Windsurf vs Cursor 주요 스펙 비교

Windsurf 지금 어떻게 된 건가

인수 구조를 한 번만 정리하고 넘어갈게요. 혼란스러운 분들이 많아서요.

2025년 말, OpenAI가 Windsurf(개발사 Codeium)를 약 30억 달러에 인수하려고 했습니다. 근데 Microsoft가 OpenAI와의 IP 계약 조항을 들어 제동을 걸었어요. Windsurf 기술이 자사 GitHub Copilot과 경쟁 관계라는 이유였고요. 협상은 결렬됐습니다.

거기서 Google이 등장해요. DeepMind가 CEO 바룬 모한과 공동창업자 더글러스 첸을 포함한 핵심 R&D 인력을 24억 달러짜리 기술 라이선싱 계약으로 데려갔습니다. 완전 인수가 아닌 라이선싱 구조로 공정거래 심사를 피해간 거예요.

제품 브랜드와 잔여 팀은 Cognition이 인수했고요. 그래서 지금 Windsurf라는 이름의 에디터는 Cognition이 운영하는 제품입니다.

이게 중요한 이유는 단순 가십이 아니에요. AI 코딩 도구 시장에서 인프라·인재·제품이 경쟁사 간에 분리 매각된 첫 사례라 앞으로의 방향성을 가늠하기가 쉽지 않아졌거든요. 요금제가 바뀔 수 있고, 제품 방향이 달라질 수 있습니다.

두 도구가 추구하는 철학이 애초에 다르다

스펙을 보기 전에 이걸 먼저 이해해야 해요.

Cursor는 VS Code를 포크한 AI 에디터입니다. 철학이 "AI 페어 프로그래머"예요. 코드 수정을 제안하면 개발자가 diff를 보고 승인하거나 거부합니다. 제어권이 개발자한테 있어요. 여러 AI 모델(GPT-4o, Claude 등)을 직접 고를 수 있고, 2026년 4월에 나온 Cursor 3에서는 다중 에이전트를 병렬로 돌리는 Agents Window도 생겼어요.

Windsurf는 "에이전트 IDE"를 표방합니다. 핵심 엔진 Cascade가 전체 레포지토리를 자동으로 스캔하고 코드를 직접 수정해요. 승인 다이얼로그 없이요. "Redis 기반 레이트 제한 구현해줘"라고 하면 3.5분 만에 여러 파일에 걸쳐 처리가 완료되는 구조입니다. Cascade Memory는 코드베이스 구조와 선호도를 대화 간에도 기억해서, 이전에 어떤 스타일로 코드를 짰는지 누적해서 반영합니다.

한쪽은 "같이 일하는 동료", 한쪽은 "시키면 알아서 하는 팀원" 느낌이에요. 어느 쪽이 좋냐는 개발자마다 다릅니다.

숫자로 보면 어디서 차이나나

실측 데이터를 정리하면 이렇습니다.

코드 완성 수용률은 Cursor가 72%, Windsurf가 65%예요. TypeScript 속성명 제안 정확도도 Cursor 85%, Windsurf 78%로 Cursor가 앞섭니다. 정밀도 면에서는 Cursor가 우위예요.

추론 속도는 반대예요. Windsurf의 SWE-1.5 모델이 초당 950토큰, Cursor Composer 2가 초당 200토큰 정도입니다. 약 5배 차이가 나요. 빠른 응답을 원한다면 Windsurf가 체감이 다릅니다.

멀티파일 작업에서는 Cursor가 15개 파일 React 라이브러리를 10분 만에 TypeScript로 변환하는 사례가 있어요. Windsurf는 5개 파일 이상 작업 시 성능이 떨어진다는 리뷰들이 있고요. 단, 2026년 5월 Digital Applied 벤치마크에서는 Windsurf 2가 에디터 네이티브 멀티파일 리팩토링에서 앞선다는 결과도 있어서 이건 버전마다 달라지는 것 같습니다.

컨텍스트는 Windsurf가 인상적이에요. 15,000개 파일짜리 레포를 8초 만에 인덱싱하는 Fast Context를 2026년 업데이트에서 내놨습니다. Cursor는 200K 토큰 컨텍스트 윈도우를 씁니다.

Cursor와 Windsurf의 에이전트 작동 방식 비교

가격은 어떻게 다른가

Cursor Pro는 월 $20입니다. 무제한 탭 완성과 Auto 모드 무제한이 포함되고, 프론티어 모델을 수동으로 선택하면 크레딧이 차감돼요. 2025년 6월에 요청 기반에서 사용량 기반 과금으로 전환했습니다. 무거운 모델 많이 쓰는 분들은 체감되는 변화예요.

Windsurf Pro는 월 $15입니다. 거기다 무료 티어가 꽤 넉넉해요. 무제한 자동완성·채팅에 월 25 크레딧이 무료로 제공됩니다. 개인 개발자나 사이드 프로젝트에는 무료 티어만으로도 써볼 만한 수준이에요. 단, Cognition 인수 이후 가격 정책이 변경될 가능성은 있습니다.

Teams 플랜은 두 도구 다 사용자당 월 $40으로 동일합니다.

Cursor vs Windsurf 요금제 비교

어떤 상황에 뭘 써야 하나

직접 써보고 커뮤니티 반응들을 종합해보면 이렇습니다.

Cursor가 맞는 상황은 대규모 레거시 코드베이스를 다룰 때예요. 단계별로 내가 승인하면서 가고 싶고, 모델도 직접 고르고 싶다면 Cursor가 맞아요. VS Code 기반이라 기존 테마, 키바인딩, 확장이 그대로 쓰이는 것도 강점입니다. SK DevOcean 체험기에서도 대기업·금융·레거시 환경에서는 Cursor가 온보딩 속도에 실질적 도움이 된다고 나왔어요.

Windsurf가 맞는 상황은 새 프로젝트를 빠르게 시작할 때, 또는 반복적인 보일러플레이트 작업을 자동화하고 싶을 때입니다. "이거 해줘" 하고 결과를 받아보는 방식이 편한 분들에게 맞아요. JetBrains나 Vim을 쓴다면 Windsurf밖에 선택지가 없기도 하고요.

30일 실사용 테스트들의 공통된 결론은 "대규모 리팩토링은 Cursor, 빠른 소규모 작업은 Windsurf"예요. 저도 비슷하게 느꼈습니다.

당장 시작한다면 — Windsurf 무료 티어로 먼저 일주일 써보고, 정밀 제어가 필요해지면 Cursor Pro로 넘어가는 순서가 비용 낭비가 적습니다. Windsurf 인수 후폭풍이 어떻게 마무리되는지 지켜보면서 결정해도 늦지 않아요.

바이브코딩 입문: 코딩 몰라도 앱 만들 수 있다는 게 사실일까? (2026)

roundfigure — Sat, 20 Jun 2026 01:58:40 +0900

"앱을 만들고 싶은데 코딩은 모른다" — 이 말이 불가능처럼 들렸던 게 2년 전이에요. 지금은 바이브코딩 덕분에 얘기가 달라졌습니다. 2025년 2월 AI 연구자 Andrej Karpathy가 처음 이름 붙인 이 방식이, 1년 반 만에 Collins Dictionary 올해의 단어로 뽑힐 만큼 폭발적으로 퍼졌어요. 2026년 기준 전 세계에서 바이브코딩으로 만들어진 앱이 3,100만 개라고 합니다. 근데 그게 전부 성공한 건 아니에요. 실제로 뭘 할 수 있고, 어디서 막히는지 솔직하게 정리해봤습니다.

바이브코딩 작동 흐름: 자연어 → AI 코드 생성 → 앱 완성

바이브코딩이 뭔가, 한 줄로 정리하면

코드 문법 없이 말로 앱을 만드는 방식입니다. "사용자 로그인 기능 있는 할 일 관리 앱 만들어줘"라고 치면 AI가 코드를 짜고, 에러가 나면 "에러 났어" 하고 다시 보내면 AI가 고쳐줘요. 개발자의 역할이 코드 작성자에서 설계자로 바뀌는 거예요.

OpenAI 공동창업자이자 테슬라 AI 총괄이었던 Karpathy는 2025년 2월 2일 X에 이 개념을 올렸고, 해당 포스트는 450만 회 이상 조회됐습니다. 사실 그는 2023년 1월에 이미 "가장 핫한 새 프로그래밍 언어는 영어"라는 트윗을 남겼는데, 그게 2년 뒤에 현실이 된 거죠.

입문자가 쓸 만한 도구는 뭔가

도구 선택에서 많이 헤매더라고요. 간단히 정리하면 코딩 지식이 전혀 없다면 Bolt.new나 Lovable부터 시작하는 게 맞아요.

Bolt.new는 약 3분 만에 풀스택 웹앱 초안을 뽑아줘서 "일단 뭔가 돌아가는 것"을 보고 싶은 분들에게 적합합니다. 무료 플랜이 있어서 부담 없이 시작할 수 있어요. Lovable은 결과물이 가장 세련되게 나와서 UI가 중요한 서비스 데모나 포트폴리오 사이트 만들 때 강점이 있습니다.

Replit은 2025년 한 해 동안 속도가 2~3배 빨라지면서 빠른 프로토타이핑 플랫폼으로 자리잡았어요. 이미 200만 개 이상의 앱이 이 플랫폼에서 만들어졌습니다.

Cursor나 Claude Code는 코딩 지식이 어느 정도 있는 분들에게 훨씬 강력해요. 10개 파일에 걸친 복잡한 프로젝트 수정도 처리하지만, 코드를 전혀 모르면 AI 출력을 검증하기가 어렵습니다.

바이브코딩 주요 도구 비교 (난이도·비용·적합 상황)

실제로 해보면 어떤가

저도 처음엔 "정말 코딩 없이 되나?" 반신반의했는데, 실제 사례들을 보면 꽤 구체적입니다.

컨설턴트 한 명이 월 $36 내던 Squarespace 사이트를 Bolt로 대체했어요. 5개 페이지, 반응형 디자인, 연락처 폼, 블로그 섹션 — 하루 오후 시간에 완성했다고 합니다. Claude Code로 만든 RSS 리더 앱 RSScal은 2026년 2월 첫 커밋 이후 7주 만에 337커밋으로 상업용 앱으로 나왔고요. Lovable은 800만 사용자에 연 매출 $2억을 달성했고, Bolt.new는 5개월 만에 $4천만 ARR에 도달했습니다.

근데 여기서 끝내면 반쪽짜리 얘기예요.

3,100만 개 앱 중 앱 스토어에 올라간 건 0.4%

이게 2026년 6월 현재 가장 솔직한 수치예요. 바이브코딩으로 전 세계에서 만들어진 앱이 3,100만 개인데, 실제 구글 플레이나 앱스토어에 올라간 건 약 12만 7천 개. 0.4%입니다.

이유가 있어요. 앱 스토어 심사 기준, 개인정보 처리 정책, 백엔드 인프라 — 이런 건 AI가 프로토타입 코드를 짜주는 것과 완전히 다른 영역이거든요. AI가 코드를 잘 짠다는 것과 비즈니스로 운영 가능한 앱을 가진다는 건 다른 문제라는 게 현장 전문가들의 공통된 얘기입니다.

보안도 봐야 해요. AI가 생성한 코드의 45%에서 심각한 보안 취약점이 발견된다는 통계가 있어요. SQL 인젝션, API 키 노출, 입력 검증 부재 같은 것들인데, 이걸 모르고 그냥 배포하면 나중에 큰일 납니다. METR 연구에서는 숙련 개발자들이 AI 도구를 쓸 때 실제로 19% 느려졌는데 본인들은 20% 빨라졌다고 느꼈다는 결과도 있어요. 과신이 위험합니다.

2026년 바이브코딩 현실 수치

지금 시작하는 현실적인 방법

"코딩 몰라도 앱 만들 수 있다"는 맞아요. 단, 조건이 있습니다.

프로토타입이나 개인용 도구 만들기에는 바이브코딩이 진짜 강력합니다. 비용도 확 줄어요 — 기능하는 SaaS 프로토타입 개발 비용이 약 20만 달러에서 5천 달러 수준으로 떨어졌다는 데이터가 있습니다. Y Combinator 2025년 겨울 배치의 스타트업 25%가 코드베이스 95% 이상을 AI로 생성했을 만큼, 빠른 검증 단계에서는 강력한 무기예요.

시작은 Lovable이나 Bolt.new로 하고, 실제 서비스를 목표로 한다면 개발자에게 코드 검토를 맡기는 게 현실적이에요. 한국어 입문 강의도 Udemy와 구름 등에서 찾을 수 있고, 위키북스에서 '클로드 코드를 활용한 바이브 코딩 완벽 입문'(2026년 3월)도 나와 있습니다.

바이브코딩으로 어떤 걸 만들지 이미 머릿속에 있다면, 지금 바로 Bolt.new를 열고 한 문장으로 설명해보세요. 생각보다 빨리 뭔가 돌아갑니다.

Gemini CLI 종료됐다 — 무료 AI 코딩 도구 전쟁, 이제 Claude Code만 남았나? (2026년 6월)

roundfigure — Sat, 20 Jun 2026 01:42:11 +0900

2026년 6월 18일, 조용히 하나의 시대가 끝났어요.

구글이 2025년 6월에 내놓은 Gemini CLI — 하루 1,000건 무료, Apache 2.0 오픈소스라는 조합으로 "드디어 무료 AI 코딩 도구가 왔다"는 반응이 쏟아졌던 바로 그 도구입니다. 그게 1년도 안 돼서 개인 사용자 서비스를 종료했어요. 대체품으로 Antigravity CLI가 나왔는데, 이건 Go 기반 클로즈드 소스라 분위기가 완전히 달라졌습니다.

그렇다면 이제 AI 코딩 터미널 도구 시장은 Claude Code 독주 체제로 굳어지는 걸까요? 직접 두 도구를 써본 입장에서, 종료 전후 상황을 정리해봤습니다.

Gemini CLI 종료와 Claude Code 비교

Gemini CLI, 왜 갑자기 종료됐나

사실 징조는 있었어요. 2026년 5월 19일 Google I/O에서 Antigravity CLI를 발표했을 때부터 "Gemini CLI는 어떻게 되는 거지?"라는 질문이 커뮤니티에 돌기 시작했거든요.

한 달 뒤인 6월 18일, 구글은 개인 무료·유료 소비자 계정에 대한 Gemini CLI 서비스를 중단했습니다. 기업용(Gemini Code Assist Standard/Enterprise) 고객은 계속 사용 가능하지만, 개인 개발자에게는 Antigravity CLI로 이동하라는 안내만 남겼어요.

근데 Antigravity CLI는 Gemini CLI와 결이 달라요. agy 커맨드로 실행되는 이 도구는 Go 언어 기반 바이너리고, 가장 중요한 건 오픈소스가 아닙니다. Apache 2.0으로 누구나 볼 수 있던 코드가 클로즈드 소스로 전환된 거예요. GitHub 커뮤니티 반응은 예상대로 좋지 않았습니다. "구글이 또 했다"는 반응이 주를 이뤘어요.

성능과 효율, 숫자로 보면 어떻게 다른가

두 도구를 스펙 상으로만 놓고 보면 이렇습니다.

항목	Claude Code	Gemini CLI
기반 모델	Claude Sonnet 4.6	Gemini 3.1 Pro
SWE-bench Verified	82.1%	80.6%
동일 작업 완료 시간	평균 1분 44초	평균 2분 36초
동일 작업 토큰 소비	261K	432K
컨텍스트 창	200K	1M
월 요금	$20~	무료 (종료 전)

숫자만 보면 Claude Code가 꽤 유리해 보이는데, 솔직히 말하면 SWE-bench 수치는 소스마다 달라서 그대로 믿기 어려운 면이 있어요. Gemini 3 기준으로는 63.8%라는 수치도 있고, 3.1 Pro 기준으로는 80.6%가 나오거든요. 벤치마크를 어떤 버전·조건으로 돌렸는지에 따라 크게 달라집니다.

토큰 효율은 체감이 되는 차이입니다. 같은 작업에 Claude Code는 261K 토큰, Gemini CLI는 432K 토큰을 썼다는 건 유료 플랜 쓸 때 비용 차이로 직결돼요.

Claude Code vs Gemini CLI 실전 차이점 카드

실제로 써보면 어디서 차이가 나나

벤치마크보다 중요한 건 실제 워크플로우에서의 차이예요.

Claude Code가 유리한 상황

복잡한 멀티파일 리팩터링에서는 Claude Code가 눈에 띄게 앞섭니다. 10개 파일에 걸친 의존성을 따라가면서 단계별로 수정하는 작업은 Claude Code 쪽이 훨씬 안정적으로 처리해요. 에러 진단도 마찬가지입니다. 스택 트레이스를 넣으면 관련 파일들을 찾아서 문제 지점을 짚어주는 방식이 초보 개발자한테도 이해하기 쉬운 구조예요.

출력 스타일도 다릅니다. Claude Code는 짧은 불릿과 트리 구조로 정보를 정리해줘서 가독성이 좋고, Gemini CLI는 단락 형식으로 설명해주는 경향이 있어요. 숙련된 개발자라면 Gemini CLI 스타일이 더 편할 수 있지만, 처음 쓰는 사람한테는 Claude Code 출력이 더 직관적입니다.

Gemini CLI가 유리했던 상황 (종료 전 기준)

인터랙티브 스크립트 실행에서는 Gemini CLI가 앞서 있었어요. PTY 쉘 지원 덕분에 실시간 입력이 필요한 프로세스를 더 자연스럽게 다뤘습니다. Google Cloud 환경에 이미 깊이 들어가 있는 팀이라면 통합 편의성도 좋았고요. 그리고 역시 가장 큰 장점은 무료 였죠.

거대 코드베이스를 일회성으로 훑어봐야 하는 상황에서 1M 컨텍스트도 매력적이었습니다. Claude Code의 200K와는 차이가 크거든요. 단, 두 도구 모두 긴 세션에서는 컨텍스트 리셋을 권장하는 의견이 많아서 실제로 그 차이가 얼마나 유효한지는 의문이에요.

Gemini CLI 종료 타임라인 — 2025년 출시부터 2026년 6월 종료까지

Antigravity CLI, 대안이 될 수 있을까

공식적으로는 Gemini CLI의 후속이지만, 커뮤니티 반응을 보면 "계승"이라고 보기 어려운 측면이 있어요.

오픈소스 개발자들이 Gemini CLI를 선택한 이유 중 하나가 Apache 2.0이었거든요. 코드를 직접 볼 수 있고, 포크하고, 수정할 수 있다는 것. Antigravity CLI는 그게 불가능합니다. 바이너리만 배포되고 내부는 블랙박스예요.

요금 구조도 아직 불투명한 부분이 있어요. 무료 티어가 어느 정도인지, 유료로 전환하면 얼마인지 명확하게 공개된 정보가 부족합니다. 솔직히 지금 시점에서 Antigravity CLI를 주력으로 쓰기엔 이른 감이 있어요.

그래서 지금 뭘 써야 하나

무료로 AI 코딩 도구를 쓰고 싶다면 선택지가 줄었습니다. Codeium, Continue.dev 같은 IDE 플러그인 계열이 아직 무료 옵션을 유지하고 있지만, 터미널 에이전트 형태에서 Gemini CLI만큼 강력한 무료 도구는 현재로선 없어요.

Claude Code를 쓰는 사람이라면 딱히 상황이 바뀐 건 없어요. 원래 유료였고, 지금도 유료입니다. Pro 플랜 $20에서 무거운 작업이 많아지면 Max 플랜으로 올라가는 구조예요. 오픈소스 메인테이너라면 Claude for Open Source 프로그램으로 6개월간 Max 20x를 무료로 쓸 수 있으니 확인해볼 만합니다.

Antigravity CLI는 좀 더 지켜봐야 해요. 오픈소스 폐기에 대한 커뮤니티 불만이 어떻게 수렴되는지, 요금 정책이 어떻게 잡히는지를 보고 판단해도 늦지 않습니다.

지금 당장 AI 터미널 에이전트를 써야 한다면 — Claude Code Pro $20에서 시작해보는 게 현실적인 선택이에요. 무료 대안이 사라진 시장에서 검증된 도구를 쓰는 게 시간 낭비를 줄이는 방법입니다.

Claude Fable 5 완전 분석: Opus 4.8과 뭐가 다른가 + 접근 제한 이슈 총정리 (2026년 6월)

roundfigure — Sat, 20 Jun 2026 01:24:56 +0900

Claude Fable 5를 써보려다 갑자기 막혀버린 분들, 지금 정확히 무슨 일이 일어난 건지 헷갈리는 분들 많으시죠. 저도 6월 12일 저녁에 API 콜이 터지는 걸 보고 처음엔 그냥 인프라 장애인 줄 알았는데, 알고 보니 미국 상무부가 개입한 전혀 다른 종류의 이슈였습니다.

이 글에서는 Fable 5가 정확히 어떤 모델인지, Opus 4.8과 무엇이 다른지, 그리고 접근 제한 이슈가 어떤 경위로 발생했고 지금 어떤 상태인지를 리서치한 내용 전부를 정리합니다.

Anthropic 모델 계층도 — Haiku부터 Fable 5(Mythos급)까지

Fable 5는 어떤 모델인가 — Mythos급이 처음 공개됐다

Anthropic의 모델 계열은 지금까지 Haiku → Sonnet → Opus 순으로 알려져 있었습니다. Fable 5는 그 위에 새로 생긴 Mythos급의 첫 번째 일반 공개(generally available) 모델입니다. 2026년 6월 9일 출시됐고, API 모델 ID는 claude-fable-5입니다.

기술 사양부터 보면:

컨텍스트 윈도우: 100만 토큰
최대 출력: 128,000 토큰
지식 컷오프: 2026년 1월
데이터 보존: 30일 필수 (제로 데이터 보존 불가)

100만 토큰 컨텍스트는 Opus 4.8과 동일한데, 최대 출력 128K는 기존 대비 의미 있는 차이입니다. 단, 데이터 30일 보존 필수 정책은 나중에 설명할 Microsoft 환경에서 마찰이 생기는 원인이 되기도 합니다.

같은 기반 모델에서 파생된 Claude Mythos 5도 함께 출시됐는데, 이쪽은 안전 분류기를 제거한 제한적 접근 버전(Project Glasswing)입니다. 일반 사용자가 쓸 수 있는 건 Fable 5입니다.

Claude Fable 5 핵심 스펙 — 100만 토큰 컨텍스트, 128K 출력

Opus 4.8과 핵심 차이 5가지

벤치마크 숫자 먼저 보겠습니다.

벤치마크	Fable 5	Opus 4.8	격차
SWE-bench Verified	95.0%	88.6%	+6.4pp
SWE-bench Pro	80.0%	69.2%	+10.8pp
FrontierCode (Diamond)	29.3%	13.4%	+119%
Blueprint-Bench 2	38.6%	14.5%	+166%

SWE-bench Pro에서 약 11점 차이가 납니다. FrontierCode에서는 Fable 5가 Opus 4.8의 2배 이상 점수를 기록했어요. 단순 코딩보다 복잡하고 장기적인 엔지니어링 과제일수록 격차가 벌어지는 구조입니다.

성능 외에 구조적 차이도 있습니다.

1. 안전 분류기 탑재 (Fable 5 전용)
Fable 5에는 세 가지 분류기가 내장되어 있습니다. 사이버보안(익스플로잇·취약점 발견), 생물학·화학(생물무기·이중 용도 연구), 모델 증류 방지(경쟁사 훈련용 역량 추출 차단). 이 분류기가 작동하면 Opus 4.8로 폴백합니다. 실제로는 전체 세션의 약 95%가 폴백 없이 Fable 5 응답으로 완료된다고 합니다.

2. 적응형 사고 항상 활성화
Opus 4.8은 적응형 사고를 선택적으로 쓸 수 있는 반면, Fable 5는 항상 켜져 있고 비활성화가 불가능합니다. raw thinking 반환도 안 됩니다(요약 또는 생략만 가능). 추론 과정을 직접 제어하고 싶은 개발자에게는 제약이 될 수 있습니다.

3. 데이터 보존 정책 차이
Fable 5는 안전 분류 목적상 30일 데이터 보존이 필수입니다. Opus 4.8은 제로 데이터 보존(ZDR)이 가능합니다. Microsoft Foundry 환경처럼 ZDR이 기본 정책인 곳에서는 Fable 5를 그냥 쓸 수가 없습니다.

4. 가격은 정확히 2배
Fable 5는 입력 $10/100만, 출력 $50/100만 토큰입니다. Opus 4.8은 입력 $5/100만, 출력 $25/100만 토큰. 짧고 범위가 명확한 작업이라면 Opus 4.8이 비용 면에서 오히려 합리적입니다.

5. 모델 계층 포지셔닝
Fable 5는 Opus 상위인 Mythos급으로 설계됐습니다. 수일 단위의 장기 자율 에이전트 작업, 하위 에이전트 위임, 단계별 계획 수립 같은 시나리오가 주 대상입니다. Stripe는 "수개월치 엔지니어링을 며칠로 압축했다"고 발표했고, 금융 분석 벤치마크에서도 최고 성능을 기록했습니다.

Claude Fable 5 vs Opus 4.8 벤치마크 비교 — SWE-bench Pro 80% vs 69.2%

접근 제한 이슈 — 정확히 무슨 일이 있었나

이게 핵심입니다. 순서대로 보겠습니다.

타임라인

6월 9일: Fable 5·Mythos 5 공식 출시
6월 12일 오후 5:21 ET: 미국 상무부로부터 수출통제 지령 수령
6월 13일 오전 00:50 UTC: Claude Status 페이지에 인시던트 게시
6월 20일 현재: 복구 일정 미발표, 모니터링 상태

상무부 장관 Howard Lutnick이 서명한 이 지령의 내용은 간단합니다. 모든 외국 국적자(Anthropic 직원 포함)의 Fable 5 및 Mythos 5 접근을 차단하라는 것. Anthropic은 국적별 실시간 선별 차단이 기술적으로 불가능하다고 판단해서, 전 세계 모든 고객에게 두 모델을 비활성화했습니다.

근거는 "좁은 범위의 젬브레이크(narrow jailbreak)"였습니다. Fable 5에 특정 안전 가드레일을 우회하는 취약점이 존재하며 이것이 국가 안보 위협이라는 주장입니다. Amazon 보안팀이 해당 취약점을 백악관에 보고했다는 보도도 나왔습니다.

Anthropic의 반박은 4가지입니다.

해당 취약점은 새로운 것이 아니라 이미 알려진 소수의 경미한 취약점이다.
동일 기능은 OpenAI GPT-5.5 같은 다른 공개 모델로도 달성 가능하다.
정부로부터 상세한 서면 근거를 받지 못했다.
오해에서 비롯된 상황으로 판단하며 복구를 위해 협력 중이다.

그리고 이 사건은 더 넓은 맥락이 있습니다. 국방부(DOD)가 이전에 자율 무기·국내 감시 응용을 위한 무제한 Claude 접근을 요구했고 Anthropic이 거절한 적 있었습니다. Anthropic은 현재 관련 조치들에 대해 법적 대응도 진행 중입니다.

Claude Fable 5 접근 제한 타임라인 — 미국 상무부 수출통제 지령

헷갈리기 쉬운 세 가지 혼동

이 시기에 비슷한 시점으로 겹친 이슈들이 있어서 혼동하기 쉽습니다.

혼동 1. 구독 제외 정책 vs 정부 지령
6월 23일부터 Fable 5가 구독 요금제에서 빠지고 별도 유료 크레딧이 필요해진다는 건 사전에 발표된 비즈니스 정책입니다. 6월 12일 전면 중단은 그것과 완전히 별개인 정부 지령 이슈입니다. Anthropic도 이를 명확히 구분하고 있습니다.

혼동 2. 젬브레이크 발생 vs 수출통제 지령
"젬브레이크가 실제로 발생했다"는 보도가 일부 있었는데, 독립 분석에 따르면 이는 부정확한 추측입니다. 실제 사건은 수출통제 지령이었습니다.

혼동 3. 성능 제한 논란 (별개 이슈)
모델 증류에 악용된다고 판단될 경우 사용자에게 고지 없이 하위 모델로 우회하는 정책을 Anthropic이 적용하려 했다는 별개 논란도 있습니다. Anthropic은 이를 "잘못된 판단"으로 인정했습니다.

지금 당장 어떻게 해야 하나

현재(2026년 6월 20일) 상태입니다.

모델	상태
Claude Fable 5	전면 이용 불가 (복구 일정 미정)
Claude Mythos 5	전면 이용 불가 (복구 일정 미정)
Claude Opus 4.8	정상 운영
Claude Sonnet 4.6	정상 운영
Claude Haiku 4.5	정상 운영

API 통합 시 주의할 점은 이번 중단이 인프라 장애가 아니라는 겁니다. 재시도 로직(retry logic)으로는 해결이 안 됩니다. Anthropic이 fallbacks 파라미터를 API에서 베타로 제공 중인데, 서버 사이드에서 자동 폴백을 설정해두면 Fable 5가 복구됐을 때 자동으로 전환할 수 있습니다.

당장 높은 성능이 필요하다면 Opus 4.8이 현실적 대안입니다. SWE-bench Pro 기준으로 Fable 5(80%) 대비 약 11점 낮은 69.2%지만, 가격은 절반입니다. 일반적인 작업 범위라면 격차를 체감하기 어려운 경우가 많습니다.

Fable 5, 돌아오면 쓸 가치가 있을까

솔직히 말하면, 장기 에이전트 작업이나 대규모 코드 마이그레이션을 다루는 팀이라면 복구 이후 Fable 5를 검토할 이유가 충분합니다. FrontierCode에서 Opus 4.8의 두 배 이상 점수를 기록한 건 숫자 이상의 의미가 있고, Stripe 사례처럼 실제 업무 시간을 크게 줄이는 사용 사례도 나왔습니다.

다만 데이터 보존 30일 필수, raw thinking 불가, 가격 2배 — 이 세 가지 제약을 감수할 수 있는 용도인지는 팀마다 다르게 판단할 것입니다.

복구 소식은 Claude Status 페이지(status.anthropic.com)와 Anthropic 공식 블로그를 주시하는 게 가장 빠릅니다. White House AI 자문관 David Sacks도 "신속한 해결을 희망한다"고 밝혔으니, 장기전이 될지 단기에 풀릴지는 아직 열려 있습니다.

Cursor AI 요금제 비교 2026: 무료 vs Pro vs Business 뭐가 이득?

roundfigure — Fri, 19 Jun 2026 16:00:45 +0900

Cursor AI 요금제를 검색하다 보면 "$20이면 되겠지" 싶다가도, 실제 후기를 읽으면 "2주 만에 크레딧 다 썼다"는 말이 나와서 갸웃하게 됩니다. 2026년 현재 Cursor는 플랜이 7개로 늘어났고, 2025년 6월 크레딧 방식으로 전환하면서 요금 구조가 꽤 복잡해졌어요. 이 글에서는 각 플랜의 실제 차이, 크레딧이 얼마나 빨리 소진되는지, 그리고 내 상황에 맞는 플랜이 어디인지까지 한 번에 정리합니다.

Cursor AI 요금제 전체 플랜 비교표

Cursor AI 요금제 한눈에 보기 (2026년 현재)

2026년 6월 기준으로 Cursor 플랜은 이렇게 정리됩니다.

플랜	월간 가격	연간 환산	크레딧 풀
Hobby (무료)	$0	$0	없음
Pro	$20	$16	$20 상당
Pro+	$60	$48	$60 상당
Ultra	$200	$160	$200 상당
Teams Standard	$40/인	$32/인	팀 표준 할당
Teams Premium	$120/인	$96/인	Standard의 5배
Enterprise	맞춤	맞춤	풀링(전체 공유)

연간 결제하면 약 20% 할인됩니다. Pro는 월 $20 → 연간 결제 시 월 $16(연 $192)으로 내려가요.

무료 플랜(Hobby)은 진짜 쓸 수 있나?

솔직히 말하면, 무료 플랜은 "일단 써보는" 용도입니다. VS Code 기반 편집기 자체는 제한 없이 쓸 수 있고, Tab 완성도 월 약 2,000회, 느린 프리미엄 모델 요청도 50회 정도 됩니다. 신규 가입 시엔 Pro를 1주일 무료로 체험할 수 있어요.

근데 문제는 빠지는 기능들이 핵심 기능이라는 점입니다.

에이전트 모드 없음: 자율 코딩, 멀티파일 작업 불가
MCP 없음: 외부 도구 연동 차단
클라우드 에이전트 없음
피크 타임에 응답이 느려지거나 더 가벼운 모델로 대체됨

하루 1~2시간 이상 AI 도움을 받으면서 코딩한다면, 월 중순 전에 한도 소진을 경험하게 됩니다. "주 1~2회 가벼운 개인 프로젝트"나 "Cursor 도입 전 평가" 목적이 아니면 무료 플랜으론 한계가 있어요.

Cursor Hobby 플랜 제한 사항

Cursor Pro $20, 가성비는 맞는 말인가

Pro가 "가성비 최강"이라는 평가를 받는 건 이유가 있습니다. $20에 에이전트 모드, 클라우드 에이전트, MCP, Skills, Hooks 전부 포함되니까요. Tab 완성은 Supermaven 기반 무제한입니다.

저도 처음엔 "월 $20이면 커피 몇 잔 값이니까 그냥 쓰지 뭐" 싶었는데, 크레딧 구조를 알고 나서 좀 달랐습니다.

크레딧 시스템의 핵심: 2025년 6월 16일부터 Cursor는 기존 '500회 고정 요청' 방식을 버리고 '크레딧 풀' 방식으로 바꿨습니다. Pro $20 플랜은 월 $20 상당의 크레딧을 받는 거예요. Auto 모드는 무제한이지만, 수동으로 모델을 직접 선택하면 크레딧이 차감됩니다.

실제 소모 예시를 보면:

Claude Sonnet 수동 선택 시: 월 약 225회
Gemini 수동 선택 시: 월 약 550회

기존 방식과 비교하면 Claude Sonnet 기준으로 500회 → 약 225회, 약 55% 감소한 셈입니다. 이게 당시 커뮤니티에서 꽤 큰 논란이 됐고, Cursor는 공개 사과와 함께 2025년 6월 16일~7월 4일 사이 요금을 전액 환불했습니다.

결론: Auto 모드 위주로 쓰면 크레딧 걱정 없이 쓸 수 있어요. 근데 특정 모델을 수동으로 고집한다면, 집중 개발 구간에서 2주 만에 크레딧이 바닥날 수 있습니다. 실제로 그런 사례가 여럿 보고됩니다.

Cursor Pro 크레딧 소모 비교 - Auto 모드 vs 수동 모드

Pro+ vs Pro, 3배 비싼 게 맞나

Pro+는 월 $60으로 Pro의 3배입니다. 기능은 Pro와 완전히 똑같고, 크레딧만 3배입니다.

이게 합리적인 선택이 되려면 한 가지 조건이 있어요. 수동 모델 선택으로 크레딧 소진이 잦아서 Pro+를 선택하느냐, 아니면 초과분을 온디맨드로 추가 구매하느냐 — 사용 패턴에 따라 달라집니다. 사용량이 일정하지 않고 한 달에 1~2번 몰리는 편이라면 Pro + 필요 시 온디맨드 충전이 더 경제적일 수 있어요.

Ultra($200/월)는 크레딧이 Pro의 20배이고 신기능 우선 접근 권한까지 포함됩니다. 매일 수십 시간씩 헤비하게 쓰는 개발자 대상입니다.

Teams(Business) 플랜은 언제 필요한가

2026년 현재 Cursor는 기존 'Business' 명칭을 'Teams'로 통일했습니다. 혼용 중인 자료들도 있으니 참고하세요.

Teams Standard ($40/인/월)는 Pro 기능에 팀 관리 기능이 더해집니다:

중앙집중식 팀 빌링 + 관리자 대시보드
팀 마켓플레이스 (내부 규칙·Skills·플러그인 공유)
코드 리뷰 기능
사용량 분석 및 보고서
팀 전체 Privacy Mode
SAML/OIDC SSO

2026년 6월에 새로 생긴 Teams Premium ($120/인/월)은 Standard의 5배 사용량을 3배 비용에 제공합니다. Standard에 Composer + Auto 전용 사용량 풀이 분리된 구조입니다. 이 개편은 신규 고객은 즉시 적용, 기존 고객은 2026년 7월 1일 이후 갱신 시 적용됩니다.

3~4인 이상 팀이라면 개인 Pro를 각자 결제하는 것보다 Teams Standard로 묶는 게 관리 편의성 면에서 낫습니다. 비용만 따지면 차이가 있지만, SSO나 사용량 모니터링이 필요한 시점이 되면 Teams로 넘어가는 게 자연스럽습니다.

Cursor Teams Standard vs Teams Premium 기능 비교

경쟁 도구와 가격 비교

Cursor만 보면 가격 판단이 어렵습니다. 같이 놓고 보면 이렇습니다.

도구	개인 기본	특징
Cursor Pro	$20/월	IDE 통합 + 에이전트 + Tab 완성 종합 최강
GitHub Copilot Pro	$10/월	가장 저렴, GitHub 네이티브 통합
Claude Code	Claude Pro $20/월 포함	복잡한 코드베이스 이해, 자율 멀티파일 작업

2026년 6월부로 GitHub Copilot도 요청 기반 → 사용량 기반 청구로 전환했습니다.

가장 저렴하게 AI 코딩 보조를 시작하고 싶다면 GitHub Copilot Pro($10/월)가 맞습니다. IDE 경험이나 에이전트 기능에서 Cursor와는 차이가 있지만, 비용 최우선이라면 선택지가 됩니다.

내 상황에 맞는 Cursor 플랜 고르기

Hobby(무료): Cursor 에디터 처음 평가할 때, 또는 주 1~2회 가벼운 사이드 프로젝트.

Pro($20/월): 하루 4시간 이상 코딩하는 개발자, AI 에이전트를 일상적으로 쓰는 프리랜서·스타트업 개발자. Auto 모드 위주로 활용하면 크레딧 걱정 없이 씁니다.

Pro+($60/월): 수동으로 특정 고급 모델을 자주 쓰고, Pro 크레딧이 매달 소진되는 경우.

Teams Standard($40/인/월): 팀 빌링 관리, SSO, 사용량 모니터링이 필요한 팀.

참고로, Cursor는 .edu 이메일 인증 시 Pro 1년 무료 학생 할인을 공식 제공합니다. 학생이라면 먼저 확인해볼 만합니다. 결제는 USD 기준이라 환율 변동에 따라 실질 비용이 달라지고, 연간 결제로 20% 절감할 수 있습니다.

마지막으로 하나만

Cursor 공식 문서에는 이런 문구가 실제로 있습니다. "일일 에이전트 사용자는 $60~$100/월이 현실적이다." $20에 시작하지만, 실제로 헤비하게 쓴다면 그 이상 나올 수 있다는 걸 미리 알고 시작하는 게 낫습니다.

직접 써보려면 무료 플랜으로 1주일 Pro 체험을 활용하세요. 그걸로 내 사용 패턴을 먼저 파악하고, 크레딧이 얼마나 빨리 소진되는지 확인한 다음 Pro 구독 여부를 결정하는 게 가장 합리적인 접근입니다.

FAQ

Q. Cursor Pro 연간 결제 취소하면 환불되나요?
공식 문서 기준으로 연간 구독은 갱신 전 취소 가능하며, 남은 기간 환불 정책은 cursor.com/help에서 확인하는 게 가장 정확합니다. 정책이 자주 바뀌는 편입니다.

Q. Cursor 무료 플랜과 Pro의 가장 큰 차이는 뭔가요?
에이전트 모드입니다. 무료 플랜은 에이전트 모드, MCP, 클라우드 에이전트가 빠져 있어서 단순 코드 보조 수준에 머뭅니다. AI 에이전트 기능을 써보려면 Pro가 필요합니다.

Q. Cursor Pro+ 대신 Pro + 온디맨드 추가 구매가 더 나은 경우는?
사용량이 매달 고르지 않고 몰리는 구간이 있는 패턴이라면, Pro+보다 Pro 유지하면서 크레딧 초과 시 온디맨드로 충전하는 방식이 더 경제적일 수 있습니다. 매달 꾸준히 크레딧을 전부 쓴다면 Pro+가 맞습니다.

Claude Code vs Cursor vs GitHub Copilot: 2026년 실무자가 직접 비교한 AI 코딩 도구 3종

roundfigure — Fri, 19 Jun 2026 12:42:08 +0900

세 도구 중 하나를 골라야 한다는 압박, 한 번쯤 느껴보셨죠? 가격도 다르고, 쓰는 방식도 다르고, 커뮤니티마다 말이 엇갈리니까요. 저도 작년까지는 "일단 Copilot 쓰면 되지 않나?" 싶었는데, Claude Code를 써보고 나서 생각이 완전히 바뀌었습니다.

2026년 기준으로 세 도구가 얼마나 달라졌는지, 어떤 상황에 어떤 걸 써야 하는지 정리해봤어요. 가격부터 벤치마크 점수, 실사용 패턴까지 데이터 기반으로 알아봅시다.

Claude Code, Cursor, GitHub Copilot 로고 세 개를 나란히 배치한 비교 대표 이미지

세 도구는 사실 '카테고리'가 다르다

같은 "AI 코딩 도구"로 묶이지만, 실제로 하는 일이 완전히 달라요.

Claude Code는 터미널(CLI) 기반 에이전트입니다. IDE가 아니에요. 명령어 하나로 수백 개 파일을 건드리는 멀티파일 자율 작업이 핵심이고, 1M 토큰 컨텍스트 윈도우 덕분에 25,000~30,000줄짜리 코드베이스를 청킹 없이 통째로 처리합니다.

Cursor는 VS Code를 포크(fork)한 AI 네이티브 IDE예요. 기존 VS Code 설정과 확장을 그대로 가져올 수 있고, Tab 자동완성의 72% 수용률이 업계 최고 수준입니다. AI가 편집기 전 레이어에 내장된 구조라 일상적인 코드 편집에서 속도가 가장 빠릅니다.

GitHub Copilot은 IDE 확장 플러그인입니다. VS Code, JetBrains, Neovim, Xcode, Visual Studio까지 10개 이상의 IDE를 지원해요. 기존 개발 환경을 바꾸지 않고 AI 보조를 붙이고 싶은 사람에게 진입 장벽이 가장 낮습니다.

근데 이 차이가 단순한 UI 문제가 아니에요. 어떤 작업을 주로 하느냐에 따라 체감이 완전히 달라집니다.

가격 — 표면 숫자만 보면 손해 본다

세 도구 요금제 비교표 — 월 기준 가격과 주요 기능을 정리한 표

단순 월 구독료만 보면 이렇습니다:

GitHub Copilot Pro: $10/월 (가장 저렴)
Cursor Pro: $20/월
Claude Code (Claude Pro 플랜): $20/월

그런데 실제로는 숫자가 더 복잡해집니다.

Cursor는 파워 유저 기준 "월 $60~100+"라는 커뮤니티 보고가 여러 곳에서 반복돼요. 광고는 $20이지만 헤비하게 쓰면 크레딧 초과로 추가 비용이 붙습니다. Pro+ 플랜이 $60/월, Ultra가 $200/월이니 실사용 비용 폭이 꽤 넓습니다. 팀 단위로 쓰면 $40/user/월이라 세 도구 중 가장 비싸요.

Claude Code는 Pro 플랜($20)이 가장 저렴하지만, 매일 고강도로 쓰려면 Max 5x($100) 또는 Max 20x($200)로 올라가야 합니다. 그리고 중요한 함정 하나 — Team Standard 플랜($20/seat)에는 Claude Code가 포함되지 않아요. 개발팀은 Team Premium($100/seat)을 사야 합니다. 가장 흔한 구매 실수라고 합니다.

GitHub Copilot은 2026년 6월 1일부터 사용량 기반 빌링으로 전환했습니다. 인라인 코드 완성은 모든 유료 플랜에서 무료지만, Chat과 Agent 모드는 AI 크레딧을 소모합니다. 헤비 유저는 비용 예측이 어려워질 수 있다는 우려가 커뮤니티에서 나오고 있어요.

성능 — SWE-bench 점수의 진짜 의미

SWE-bench는 실제 GitHub 이슈를 코드로 해결하는 벤치마크입니다. 2026년 6월 기준 점수를 보면:

도구	SWE-bench Verified
Claude Code (Opus 4.8)	88.6%
GitHub Copilot	56.0%
Cursor (기본 모델)	51.7%

Claude Code가 압도적으로 높아 보이지만, 해석할 때 조심해야 할 부분이 있어요. Cursor는 모델 선택이 가능합니다. Claude Opus 4.8을 Cursor에서 선택하면 Claude Code와 거의 같은 성능이 나올 수 있거든요. 위 51.7%는 Cursor 기본 설정 기준입니다.

GitHub Copilot의 56%는 기본 탑재 모델(GPT 계열) 기준이고, Copilot도 Claude Sonnet이나 Gemini 2.5 Pro로 모델 전환이 가능합니다.

결국 "순수한 에이전트 자율성"은 Claude Code가 앞서고, "모델 유연성으로 성능을 조합"하는 건 Cursor와 Copilot도 된다 — 이렇게 이해하는 게 맞습니다.

실사용에서 갈리는 지점

세 도구별 강점 영역을 시각화한 다이어그램 — 자율 에이전트, 일상 편집, IDE 통합 세 축

커뮤니티 의견을 보면 패턴이 꽤 일관됩니다.

Claude Code는 대형 작업에서 타의 추종을 불허합니다. "수백 개 파일에 걸친 리팩터링에서는 비교 대상이 없다"는 평가가 dev.to에서 반복돼요. Slack 메시지에서 직접 태스크를 할당하고 완성된 PR을 받아볼 수 있는 비동기 워크플로우도 실무자들이 많이 언급합니다. 단, GUI 디버거 통합이 안 되고 프론트엔드·디자인 작업에는 약점이 있어요.

Cursor는 일상 편집 속도에서 가장 빠릅니다. Tab 자동완성이 멀티라인 편집과 파일 간 변경을 예측하는 수준이고, Composer 2의 자율성 슬라이더 덕분에 루프 밖에서 작업이 돌아가는 게 편합니다. 단, 수십 개 파일에 걸친 일관성 유지는 Claude Code에 비해 약점이라는 평가가 있어요.

GitHub Copilot은 GitHub 생태계와의 통합이 압도적입니다. 이슈→PR 변환, 네이티브 코드 리뷰 연동은 다른 두 도구가 따라가기 어렵습니다. JetBrains, Visual Studio, Neovim 사용자라면 사실상 선택지가 Copilot 외에 없기도 해요. 신규 개발자에게 친절하다는 평가도 많습니다.

어떤 상황에 뭘 써야 하나

솔직히 "하나만 쓰세요"는 현실적인 조언이 아닙니다. 2026년 기준으로 전문 개발자의 다수가 도구를 조합해서 씁니다. 가장 흔한 조합은 이렇습니다:

Cursor (일상 편집) + Claude Code (대형 리팩터링): 월 $40 조합. 속도는 Cursor, 대규모 작업은 Claude Code로 역할 분리하는 게 가장 많이 쓰이는 전문가 스택이에요.

Copilot (IDE) + Claude Code (터미널): GitHub 팀 워크플로우를 유지하면서 자율 에이전트 기능을 더하고 싶을 때.

단일 도구로만 써야 한다면:

대규모 코드베이스, 자율 작업 → Claude Code
일상 편집 속도, VS Code 생태계 → Cursor
JetBrains·Neovim 사용자, GitHub 중심 워크플로우, 비용 민감 → GitHub Copilot

개발자 선호도 조사 결과 (2026년)

한 가지 흥미로운 데이터가 있어요. "가장 좋아하는 AI 코딩 도구" 선호도 조사에서 Claude Code가 46%로 1위, Cursor 19%, Copilot 9% 순서였습니다. 출시 1년도 안 된 도구가 이 위치에 올라온 거라 커뮤니티 반응이 뜨겁습니다.

단, 선호도 != 사용량이에요. Copilot은 GitHub 계정이 있으면 접근하기 쉬워서 절대적인 사용자 수는 여전히 많습니다.

FAQ

Q. Cursor와 Claude Code를 동시에 써도 되나요?
네, 실제로 가장 많이 쓰이는 조합입니다. Cursor로 파일을 열어서 편집하고, 터미널에서 Claude Code로 대형 리팩터링을 돌리는 방식이에요. 비용은 합산되지만 역할이 명확히 다릅니다.

Q. Claude Code Team Standard 플랜을 쓰고 있는데 Claude Code가 안 보여요.
Team Standard($20/seat)에는 Claude Code가 포함되어 있지 않습니다. 개발팀은 Team Premium($100/seat, 최소 5석)을 구독해야 합니다. 가장 흔한 구매 실수예요.

Q. GitHub Copilot 빌링이 6월에 바뀌었다는데 실제 비용이 얼마나 더 나오나요?
인라인 코드 완성은 그대로 무료입니다. Chat, Agent 모드, 코드 리뷰는 AI 크레딧을 소모해요. Pro 플랜 기준 $15 크레딧이 포함되어 있는데, 헤비하게 Agent를 쓴다면 초과할 수 있습니다. 지금은 아직 커뮤니티에서도 실비용 데이터가 쌓이는 중이에요.

Q. 프론트엔드 작업 위주인데 어떤 도구가 맞나요?
Cursor가 낫습니다. Claude Code는 GUI 통합이 없고 디자인 작업에는 약해요. Cursor는 멀티모델 지원과 시각적 diff 편집이 가능해서 UI 작업에 더 자연스럽습니다.

세 도구 중 "최고"는 없어요. 작업 유형과 워크플로우에 따라 최선이 달라집니다. 지금 어떤 IDE를 쓰고, 어떤 작업이 병목인지를 먼저 정리해보는 게 출발점입니다.

Claude Pro·Max·Team 요금제 완전 분석: 내 상황엔 어떤 플랜이 맞을까?

roundfigure — Fri, 19 Jun 2026 12:21:50 +0900

Claude 쓰다가 "사용량 한도에 도달했습니다" 메시지를 하루에 세 번 이상 마주친 적 있다면, 이 글이 바로 그 상황을 위한 겁니다. 반대로 아직 Free 플랜인데 Pro로 올릴지 고민 중이라면, 업그레이드 전에 각 플랜이 실제로 어떻게 다른지 확인하고 결정하는 게 맞습니다.

(2026년 7월 업데이트: Enterprise 종량제 전환과 Opus 4.8 출시가 반영된 최신 내용입니다.)

2026년 7월 기준 Claude의 유료 플랜은 Pro($20/월), Max 5x($100/월), Max 20x($200/월), 그리고 팀용 Team 플랜으로 나뉩니다. 가격 차이가 꽤 크기 때문에 자기 사용 패턴을 먼저 파악하는 게 중요합니다.

Claude 요금제 플랜별 가격 비교표 - Pro/Max 5x/Max 20x/Team 월 요금을 가로 비교한 깔끔한 인포그래픽

Pro 플랜 ($20/월): 대부분의 개인 사용자가 여기서 시작한다

월 $20(연 결제 시 $17/월, 연간 $200)로 Free 대비 사용량이 5배 늘어납니다. 5시간 윈도우당 약 45~100개 메시지 수준이고, Claude Code·Research 모드·Claude Cowork·100만 토큰 컨텍스트 창이 모두 포함됩니다.

ChatGPT Plus도 $20이고 Gemini Advanced가 $19.99인데, Claude Pro가 이 둘과 다른 건 컨텍스트 창입니다. ChatGPT Plus는 128K 토큰인 반면 Claude Pro는 100만 토큰. 긴 문서를 통째로 넣거나 대형 코드베이스를 다룰 때 차이가 체감됩니다.

한국 기준으로는 월 약 27,600원(VAT 별도, 1달러 ≈ 1,380원). 연 결제하면 매월 약 23,460원 수준으로 내려가고, 연간 $36를 아낄 수 있습니다. 공식 학생 할인은 없고, 연 결제가 유일한 절감 방법입니다.

저도 처음엔 Pro로 시작했는데, 글쓰기·요약·코드 리뷰를 하루 1~2시간 정도 쓰는 패턴에서는 한도 초과 메시지가 거의 안 떴습니다. Pro가 맞지 않는 신호는 딱 하나입니다. "주당 3회 이상 한도 초과를 경험한다"는 것.

Max 플랜: 가격이 5배인데 뭐가 다를까

Max는 새로운 기능을 추가로 주는 게 아닙니다. Pro에 있는 기능은 Max에도 똑같이 있습니다. 차이는 오직 사용 한도입니다.

플랜	Pro 대비 사용량	월 가격
Max 5x	5배	$100
Max 20x	20배	$200

5시간마다 한도가 리셋되는 구조이고(하루 단위가 아닙니다), 여기에 더해 주간 한도가 별도로 적용됩니다. 계정별로 지정된 요일·시각에 리셋되는 방식이라 24시간 내내 돌리는 극단적 사용은 주간 한도에 먼저 걸립니다. 연간 결제 옵션은 없습니다. 최상위 모델인 Opus 4.8(2026년 5월 말 출시)은 이제 Pro에서도 선택할 수 있지만, Opus는 사용량 소모가 커서 한도 걱정 없이 일관되게 쓰려면 사실상 Max 20x가 필요합니다.

Max 5x vs Max 20x 선택 기준 플로우차트 - 하루 세션 수와 Claude Code 사용 빈도 기준

Max 5x ($100/월)가 맞는 경우:

하루 1~3회 진지한 작업 세션을 진행하는 개발자·프리랜서
Pro 한도 초과를 주당 3회 이상 경험하는 헤비유저
Claude Code를 꾸준히 쓰지만 풀타임은 아닌 경우

Max 20x ($200/월)가 맞는 경우:

Claude를 하루 종일 열어두고 작업하는 파워유저
멀티시간 터미널 세션이 일상인 소프트웨어 엔지니어
Opus 4.8 모델을 한도 걱정 없이 일관되게 써야 하는 연구자·전문가

한 가지 체크해볼 것: API 사용량이 많다면 Max보다 직접 API 요금이 더 저렴할 수 있습니다. Max는 구독 기반 한도 확장이고, API는 토큰 단위 과금이라 사용 패턴에 따라 비용이 역전됩니다.

한국 원화로 보면 Max 5x는 월 약 138,000원, Max 20x는 약 276,000원 수준입니다(VAT 별도).

주의: Claude Code는 별도 한도가 아니다

2026년에 에이전틱 코딩 수요가 폭발적으로 늘면서 자주 생기는 오해입니다. Claude Code는 일반 Claude 대화와 동일한 플랜 풀을 공유합니다. Claude Code를 집중적으로 쓰면 일반 대화 한도가 그만큼 줄어듭니다. Pro에서 Claude Code를 집중 사용하다 한도가 빨리 소진되는 사용자들이 Max로 전환하는 이유가 여기 있습니다.

Claude Code와 일반 대화가 동일 사용량 풀을 공유하는 구조 다이어그램

Team 플랜: 5인 이상 조직이라면 계산이 달라진다

Team 표준 좌석은 월 $25/인(연 결제 시 $20/인). 최소 5석이 필요합니다.

가격만 보면 Pro보다 비싸 보이지만, Team에서 추가되는 기능들이 있습니다.

공유 프로젝트·팀 지식 베이스
SSO(Google/Microsoft IdP), 도메인 캡처, RBAC
어드민 콘솔, 중앙화된 청구
데이터가 모델 학습에 사용되지 않는다는 보장 (기본값)

사용량은 표준 좌석 기준 Pro의 1.25배이고, 한도는 개인별 적용입니다. Team 프리미엄 좌석($125/인, 연 $100/인)은 Pro 대비 6.25배 한도로 Max 5x 수준에 근접합니다.

표준·프리미엄 혼합 구성도 가능해서, 팀 내 헤비유저만 프리미엄으로 설정하는 방식도 됩니다.

Enterprise는 SAML 전체 IdP 지원, SCIM 자동 프로비저닝, 전체 감사 로그, HIPAA BAA가 필요한 조직을 위한 플랜입니다. Team이 5~150인 대상이라, 150인을 넘거나 의료·금융·법무 등 규제 산업이라면 Enterprise로 가야 합니다.

한 가지 큰 변화가 있습니다. 2026년 3월 계약 갱신분부터 Enterprise가 정액제에서 종량제로 바뀌었어요. 기존에는 1인당 최대 $200 수준의 정액 요금에 할인된 토큰 번들이 포함됐는데, 이제는 기본 좌석 $20/인/월에 실제 사용량을 표준 API 요금으로 따로 과금합니다. 라이선싱 전문가들의 분석(PYMNTS, 2026년 4월 보도)을 보면 Claude Code·Cowork를 많이 쓰는 조직은 총비용이 2~3배까지 늘 수 있고, 실사용 기준 1인당 월 $60~$250 이상이 될 수 있다는 추정도 나옵니다. Enterprise 도입을 검토 중이라면 좌석 수가 아니라 예상 사용량 기준으로 견적을 잡아야 합니다.

Team vs Enterprise 기능 비교 표 - SSO/감사로그/HIPAA/데이터보존 항목 비교

내 상황에 맞는 플랜 고르기

사용 패턴	추천 플랜
가끔 쓰고, 한도 초과 없음	Free (or Pro 검토)
매일 1~2시간, 주당 한도 초과 1~2회 미만	Pro $20
주당 한도 초과 3회+, 집중 작업 세션	Max 5x $100
하루 종일 Claude 열어두고 작업	Max 20x $200
5인 이상 팀, 관리 기능 필요	Team 표준 $25/인
팀 내 헤비유저 + 조직 보안 필요	Team 프리미엄 $125/인
150인 초과 or 규제 산업	Enterprise ($20/인 + 사용량 과금)

플랜 결정이 어렵다면 Pro로 시작해서 한 달 써보는 게 가장 현실적입니다. 한도 초과 메시지가 주당 3번을 넘기 시작하면 그때 Max 5x를 검토하면 됩니다. 지금 바로 claude.com/pricing에서 각 플랜의 기능 목록을 확인하고, 자신의 사용 패턴과 대조해보세요.

ChatGPT Codex vs Claude Code: 2026년 AI 코딩 에이전트 비교, 어떤 걸 써야 할까

roundfigure — Fri, 19 Jun 2026 12:20:02 +0900

"둘 다 써봤는데 솔직히 모르겠다"는 반응이 꽤 많더라고요. 저도 처음엔 그랬습니다. 벤치마크 숫자는 Claude Code가 앞서는데, 막상 $20 플랜으로 쓰다 보면 금세 한도에 걸려서 Codex로 손이 가는 상황이 반복됐거든요. 2026년 6월 기준 데이터를 기준으로 두 도구를 뜯어봤습니다. 어떤 상황에서 무엇을 써야 할지, 답을 드릴게요.

실력 차이가 실제로 있나? — 벤치마크 수치부터

SWE-bench Verified 기준으로는 Codex(GPT-5.5) 88.7%, Claude Code(Opus 4.8) 88.6%로 사실상 동점입니다. 이 숫자만 보면 "그냥 취향 차이"처럼 보이는데, 문제는 더 현실적인 벤치마크에서 갈립니다.

실제 GitHub 이슈 기반의 SWE-bench Pro에서는 Claude Code가 69.2%, Codex가 58.6%로 10.6%p 차이가 납니다. 반대로 터미널 자율 구동을 보는 Terminal-Bench 2.1에서는 Codex가 83.4%로 Claude Code(78.9%)를 앞섭니다.

요약하면 이렇습니다. 복잡한 버그 수정이나 대규모 코드베이스 작업이라면 Claude Code가 눈에 띄게 낫고, 터미널 자동화 워크플로에서는 Codex가 유리합니다.

SWE-bench Pro 및 Terminal-Bench 2.1 벤치마크 비교 차트

가장 현실적인 차이 — 요금과 사용 한도

벤치마크보다 실사용에서 더 직접적으로 체감되는 부분이 여기입니다.

Claude Code는 $20 Pro 플랜에서 복잡한 프롬프트 1~2개면 한도가 소진됩니다. 5~6개 프롬프트 후 컨텍스트 압축도 발생하고요. Max 5x 플랜($100)이나 Max 20x 플랜($200)으로 올라가야 편하게 쓸 수 있는 구조입니다. 참고로 2026년 5월 6일에 Anthropic이 모든 유료 플랜의 한도를 두 배로 늘렸는데도 이 얘기가 나온다는 건, 원래 얼마나 빡빡했는지를 보여주는 거죠.

Codex는 $20 Plus 플랜에서 하루 종일 쓸 수 있고, Free 플랜도 GPT-5.3 Instant로 기본 체험이 됩니다. 같은 $20 예산이라면 실사용량 면에서 Codex가 압도적으로 유리합니다.

Reddit 개발자 500명 이상을 분석한 DEV.to 자료(2026년 3월 기준)에서도 일상 작업 선호도는 Codex 65.3%로 나왔습니다. 이유는 단순합니다. "한도 문제 때문에." 반면 코드 품질 블라인드 테스트 승률은 Claude Code가 67%로 앞섰습니다.

커뮤니티의 합의는 명확합니다. "Claude Code는 더 높은 품질이지만 사용 불가능. Codex는 약간 낮은 품질이지만 실제로 사용 가능."

어떻게 돌아가는 도구인가 — 실행 환경과 기능

두 도구는 구조 자체가 다릅니다.

Claude Code는 로컬 터미널 기반입니다. 코드가 내 기기에서 실행되고, 컨텍스트 윈도우가 1M 토큰이라 대형 파일을 통째로 넣어도 됩니다. VS Code 마켓플레이스에서 가장 사랑받는 도구 46% 점유율을 기록 중이고, JetBrains 베타 플러그인도 있습니다. MCP(Model Context Protocol)를 완전 지원하는 것도 차별점입니다.

Codex는 클라우드 샌드박스 기반으로 돌아갑니다. 실행 환경이 원격 VM이라서 인터넷은 기본적으로 차단되지만, 사용자 조작 없이 PR을 자동으로 올리거나 GitHub 이슈에 @Codex를 멘션하는 것만으로 태스크를 트리거할 수 있습니다. CLI, VS Code, 웹앱, iOS, Chrome 확장까지 지원하니까 어느 기기에서든 이어서 쓸 수 있는 것도 장점입니다.

에이전트 능력에서도 차이가 있습니다. Claude Code는 30개 이상의 자동화 훅과 태스크 의존성을 추적하는 서브에이전트 팀 구성을 지원합니다. Codex는 2026년 3월부터 최대 8개의 병렬 에이전트가 격리된 클라우드 샌드박스에서 작동하는 방식으로 GA가 됐습니다.

Claude Code 로컬 vs ChatGPT Codex 클라우드 실행 환경 및 기능 비교

토큰 소비 — 품질에는 비용이 따른다

Claude Code가 더 철저하게 작업한다는 건, 토큰을 훨씬 많이 쓴다는 의미이기도 합니다.

Figma 플러그인 빌드 테스트에서 Claude Code는 6.2M 토큰, Codex는 1.5M 토큰을 썼습니다(4.2배 차이). 스케줄러 앱 제작에서는 235K 대 73K, API 통합 작업에서는 650K 대 180K였습니다. 이 패턴이 사용 한도 소진 속도의 차이로 직결됩니다.

속도 면에서는 흥미로운 반전도 있습니다. 대시보드 프론트엔드 빌드에서는 Claude Code가 2분, Codex가 8분 걸렸습니다. Claude Code가 4배 빨랐던 거죠. PDF 리포트 생성처럼 리서치가 많이 필요한 작업에서는 Codex가 토큰을 40% 덜 썼고요. 작업 성격에 따라 유리한 쪽이 달라집니다.

누구에게 무엇이 맞나

상황별로 명확하게 나뉩니다.

Claude Code가 맞는 경우:

1M 토큰 컨텍스트가 필요한 대규모 코드베이스
MCP 생태계를 쓰는 프론트엔드/UI 작업
실제 버그 수정 정확도가 중요한 팀 (SWE-bench Pro 69.2%)
복잡한 멀티에이전트 오케스트레이션
Max 5x($100) 이상 플랜을 쓸 수 있는 경우

Codex가 맞는 경우:

$20 플랜에서 하루 종일 쓰고 싶은 경우
GitHub 이슈/@Codex 멘션으로 자동 PR을 원하는 팀
터미널 자동화 워크플로 (Terminal-Bench 83.4%)
iOS, 웹, CLI 등 멀티 디바이스를 넘나드는 작업
/goal 명령으로 24시간 이상 자율 실행이 필요한 경우

그리고 꽤 많은 전문 개발자들이 실제로 두 도구를 같이 씁니다. 계획과 리뷰는 Claude Code, 자율 구현과 DevOps는 Codex. 프로토타입은 Codex로 빠르게 만들고, 품질 정제는 Claude Code로 마무리하는 방식입니다. 월 $40(두 도구 각각 $20)으로 이 하이브리드 전략을 구현할 수 있습니다.

하이브리드 워크플로 다이어그램 — 계획/리뷰: Claude Code → 자율 구현: Codex → 품질 정제: Claude Code

GitHub 스타와 커뮤니티 규모

마지막으로 도구의 실제 채택 규모를 보면, Claude Code가 GitHub 별 132K, Codex가 91K입니다. Claude Code 관련 커뮤니티 토론 볼륨이 Codex의 4배에 달한다는 점도 주목할 만합니다. 현재 전체 공개 GitHub 커밋 중 약 10%(하루 약 32.6만 건)가 Claude Code를 통해 나오고 있습니다.

어떤 도구로 시작할지 결정이 안 된다면

$20 예산이 한 가지라면 지금 당장은 Codex가 낫습니다. 한도 걱정 없이 사용량 한계를 먼저 경험하고, 작업 품질이 부족하다고 느껴지면 그때 Claude Code Max 플랜으로 넘어가는 것이 현실적입니다. 둘 다 가입해서 2주씩 직접 써보는 게 어떤 비교 글보다 정확합니다. 지금 무료로 체험 가능한 Codex부터 시작해보세요.