클로드 코드에 버그 수정을 맡겨 놓고 퇴근하려는데 노트북을 덮으면 작업이 멈춥니다. 🤔 작업 세 개를 동시에 돌리고 싶어도 로컬에서는 git worktree를 여러 개 만들어 가며 브랜치가 섞이지 않게 챙겨야 하고요. 에이전트가 일하는 동안 내 컴퓨터가 계속 켜져 있어야 한다는 게 은근히 발목을 잡습니다. Anthropic이 2025년 10월 20일에 리서치 프리뷰로 내놓은 Claude Code on the web은 에이전트를 아예 클라우드로 옮겨서 이 문제를 풉니다. 클로드 코드가 내 컴퓨터가 아니라 Anthropic이 관리하는
요즘 Cursor나 Claude Code, Codex와 같은 AI 도구로 소프트웨어 개발을 많이 하시죠? 그런데 AI 코딩 에이전트에게 작업을 시키다 보면 프로젝트에 대한 전반적인 지식이 부족하여 엉뚱하게 작업을 진행할 때가 있습니다. 예를 들어, 테스트 파일을 엉뚱한 위치에 생성하거나, 프로젝트의 코딩 컨벤션을 무시하거나, 마음대로 이미 쓰고 있는 라이브러리랑 비슷한 기능을 하는 다른 라이브러리를 설치해버리는 식이죠. 이럴 때는 AI 에이전트에게 좀 더 구체적으로 작업 방향을 알려줄 수 있지만, 새로운 대화 세션을 시작할 때마다
클로드 코드에 프로젝트 규칙을 알려주는 가장 기본적인 방법은 CLAUDE.md입니다. 그런데 프로젝트가 커지면 이 파일 하나가 점점 비대해지죠. 프론트엔드 규칙, 백엔드 규칙, 테스트 컨벤션, 보안 요구사항... 온갖 내용이 한 파일에 뒤섞이면 읽기도 어렵고, 매 세션 전부 로드되니 컨텍스트도 부담스러워집니다. .claude/rules/ 디렉토리는 이 문제를 푸는 방법입니다. 규칙을 주제별로 여러 파일에 나눠 담고, 필요한 순간에만 로드되도록 만들 수 있어요. 이 글에서는 .claude/rules/를 어떻게 구성하는지, 그리고 CL
AI 코딩 에이전트를 쓰다 보면 "이 웹 페이지 좀 열어서 확인해줘"라고 말하고 싶을 때가 종종 있지 않나요? 배포한 사이트에 버그가 있는 것 같을 때, 특정 폼이 제대로 동작하는지 테스트하고 싶을 때, 혹은 경쟁사 사이트의 UI를 참고하고 싶을 때... 하지만 대부분의 AI 에이전트는 터미널 안에서만 동작하기 때문에 브라우저를 직접 다룰 수가 없습니다. 이 문제를 해결하는 것이 바로 Playwright MCP입니다. Microsoft에서 만든 이 MCP(Model Context Protocol) 서버를 AI 에이전트에 연결하면 브
클로드 코드로 작업하다 보면 새 세션을 시작할 때마다 AI가 프로젝트에 대해 아무것도 모른다는 걸 느끼게 됩니다. "테스트는 bun run test로 돌려", "커밋 메시지는 영어로 써줘", "이 프로젝트는 Prettier를 쓰고 있어"... 매번 같은 말을 반복하는 건 꽤 피곤한 일이죠. CLAUDE.md는 이 문제를 해결하는 가장 직접적인 방법입니다. 프로젝트의 빌드 명령어, 코딩 스타일, 아키텍처 결정 같은 규칙을 마크다운으로 적어두면 Claude가 매 세션 시작 시 읽어들이거든요. Git에 커밋하면 팀 전체가 공유할 수 있고
클로드 코드로 작업하다가 "아, 이 방향이 아닌데…"라고 느낀 적 있으신가요? 리팩토링을 요청했더니 파일 10개를 고쳐놓았는데 원래 구조가 나았다거나, 라이브러리를 교체하라고 했다가 오히려 빌드가 깨진다거나. 이런 상황에서 할 수 있는 선택지가 그리 많지 않았습니다. git stash로 코드를 되돌린다 해도 Claude의 대화 컨텍스트에는 잘못된 지시가 그대로 남아 있으니까요. 새 세션을 열면 코드는 원래대로 돌아가겠지만 그동안 쌓아온 맥락이 통째로 날아갑니다. 수동으로 "방금 한 거 취소하고 다시 해줘"라고 설명하자니 토큰만 낭비
클로드 코드에게 "인증 시스템을 추가해줘"라고 요청하면 어떻게 될까요? Claude는 곧바로 파일을 수정하기 시작합니다. DB 스키마를 만들고 미들웨어를 작성하고 라우트를 추가하죠. 그런데 작업이 절반쯤 진행된 시점에 "아, JWT 대신 세션 기반으로 가고 싶었는데…"라는 생각이 든다면? 이미 수정된 파일들을 되돌려야 하는 번거로운 상황이 벌어집니다. 😅 이런 문제를 피하려면 코딩에 들어가기 전에 먼저 설계를 검토하는 단계가 필요합니다. 실제 개발에서도 PR을 올리기 전에 설계 문서를 작성하거나 팀원과 접근 방식을 논의하잖아요.
클로드 코드를 쓰다 보면 "이 파일을 수정해도 될까요?", "이 명령어를 실행해도 될까요?" 하는 승인 팝업이 끊임없이 뜹니다. 한두 번이면 괜찮지만 리팩토링처럼 파일을 수십 개씩 고치는 작업에서는 클릭 노동이 되죠. 반대로 CI/CD 파이프라인에서는 묻더라도 답할 사람이 없습니다. 😅 이처럼 상황마다 필요한 자율성이 다릅니다. 탐색만 할 때는 코드를 건드리지 못하게 막고 싶고, 빌드를 돌릴 때는 편하게 허용하고 싶죠. 클로드 코드의 권한 모드가 이 스펙트럼을 조절해 줍니다. 권한 설정이 "무엇을 허용/차단할까"를 정한다면, 권한
클로드 코드를 쓰다 보면 가장 자주 마주치는 것이 "이 명령어를 실행해도 될까요?"라는 권한 요청 팝업입니다. 처음에는 안전장치로 느껴지지만 매번 답하다 보면 꽤 성가시죠. 이 글에서는 클로드 코드의 권한 시스템을 속속들이 파헤쳐서 안전하면서도 흐름이 끊기지 않는 환경을 만드는 방법을 알아보겠습니다. 권한 시스템의 기본 구조 클로드 코드는 도구 종류에 따라 세 단계의 기본 권한 정책을 적용합니다. | 도구 유형 | 예시 | 승인 필요 | "다시 묻지 않기" 범위 | | ----------- | ---------------------
클로드 코드를 쓰다 보면 파일을 읽거나 코드를 수정하는 것은 사실 Claude가 직접 하는 게 아니라 **도구(Tool)**를 호출해서 처리한다는 걸 알게 됩니다. 코딩 에이전트의 작동 원리에서 다뤘듯이, 언어 모델 자체는 텍스트를 생성하는 것밖에 못 하고 실제 작업은 도구가 대신하는 거죠. 그런데 이 도구 이름을 알아야 하는 이유가 있습니다. 권한 설정에서 Bash(npm run *), Read(./.env) 같은 규칙을 쓸 때 도구 이름이 필요하고, Hooks에서 PreToolUse 매처를 작성할 때도, 서브 에이전트에 허용할
클로드 코드를 설치하고 기본 사용법을 익혔다면 이제 나에게 맞는 환경을 만들어볼 차례입니다. 클로드 코드는 settings.json이라는 설정 파일을 통해 권한 관리부터 모델 선택, 환경 변수, 샌드박스, 커밋 메시지 스타일까지 폭넓게 제어할 수 있는데요. 이 글에서는 설정 체계를 처음 접하는 분도 쉽게 따라올 수 있도록 하나씩 뜯어보겠습니다. 설정 파일의 계층 구조 클로드 코드의 설정은 한 군데 모여 있지 않고 여러 레벨로 나뉘어 있습니다. 각 레벨마다 역할이 다르기 때문에 상황에 맞는 위치에 설정을 놓아야 해요. | 우선순위 |
작은 서비스를 하나 만들었는데, 막상 배포하려고 하면 손이 멈출 때가 있습니다. 서버는 어디에 띄우지? 데이터베이스는 누가 만들지? 환경 변수는 어디에 넣지? 로그는 어떻게 보지? Dockerfile까지 써야 하나? 이런 질문들이 한꺼번에 밀려오죠. 요즘은 여기에 질문이 하나 더 붙습니다. AI 코딩 에이전트가 이 배포 환경을 얼마나 잘 이해할 수 있을까? 사람 혼자 터미널에서 손으로 맞추는 시대라면 대시보드 몇 번 클릭해도 괜찮았습니다. 하지만 Claude Code, Codex, Cursor 같은 코딩 에이전트와 함께 일하려면 배
클로드 코드로 웹 개발을 하다 보면 개발 서버를 띄워놓은 상태에서 코드를 수정해야 하는 상황이 자주 생깁니다. 프론트엔드 서버와 백엔드 서버를 동시에 돌리면서 코드를 고쳐야 할 때도 있고요. 일반 터미널에서는 탭이나 tmux로 해결하지만, 클로드 코드 안에서는 어떻게 할까요? 🤔 백그라운드 프로세스 기능을 쓰면 됩니다. 오래 걸리는 명령어를 뒤로 보내놓고 대화를 이어가다가 필요할 때 다시 확인하거나 종료할 수 있거든요. 한번 익혀두면 개발 서버 띄우기, 빌드 감시, 테스트 실행 같은 작업이 훨씬 수월해집니다. 백그라운드로 보내는
클로드 코드는 기본적으로 파일 읽기와 쓰기, Bash 명령어 실행, 코드 탐색처럼 소프트웨어 개발에 필요한 핵심 도구를 갖추고 있습니다. 하지만 실제 개발 작업을 하다 보면 클로드 코드에 내장된 기본 도구만으로는 부족할 때가 있습니다. 이럴 때 MCP(Model Context Protocol) 서버를 연결하면 클로드 코드의 능력을 크게 확장할 수 있습니다. MCP 서버를 한번 설정해두면 "GitHub 이슈 42번 내용 알려줘", "users 테이블 스키마 보여줘" 같은 자연어 요청만으로 외부 시스템을 다룰 수 있게 되거든요. 이 글
클로드 코드를 처음 쓸 때 /help를 입력해보면 70개가 넘는 슬래시 커맨드가 쏟아져 나옵니다. "이걸 언제 다 외우지?"라는 생각이 들 수 있는데요. 사실 매일 쓰는 명령어는 그중 일부에 불과합니다. 나머지는 특정 상황에서만 꺼내 쓰는 도구에 가깝죠. 이 글에서는 실무에서 자주 쓰는 명령어를 카테고리별로 정리해봤습니다. 각 명령어가 어떤 상황에서 유용한지, 관련 기능을 더 깊이 다룬 글은 어디 있는지까지 함께 안내합니다. 가장 먼저 알아둘 명령어는 **/help**입니다. 전체 명령어 목록을 보여주기 때문에, 나머지 명령어가 기
우리는 지난 몇 년간 소프트웨어 개발 방식에 혁명적인 변화를 가져온 AI 도구들을 경험했습니다. 초기에는 ChatGPT가 생성해주는 코드를 IDE로 복붙하다가, 깃허브 Copilot이나 Cursor와 같은 도구들이 코딩을 도와주는 시대를 지나 이제 새로운 패러다임이 등장하고 있습니다. 바로 Anthropic이 선보인 CLI(명령줄 인터페이스) 기반의 AI 코딩 도구, 클로드 코드입니다. 단순한 코드 완성이 아닌, 작업 위임의 시대 클로드 코드는 단순히 코드를 완성해주거나 코드를 생성하는 도구를 넘어섭니다. 이 도구의 핵심에는 사용자
요즘 개발자 커뮤니티에서 코딩 에이전트 이야기가 정말 많이 나옵니다. Claude Code, Cursor, Windsurf, Copilot 등등 하루가 멀다 하고 새로운 도구가 등장하고 있죠. 그런데 이 도구들이 내부적으로 어떻게 돌아가는지 아는 사람은 의외로 많지 않습니다. 코딩 에이전트는 단순히 코드를 생성하는 것을 넘어서 파일을 읽고 명령어를 실행하고 테스트까지 돌리는 꽤 복잡한 시스템인데요. 그 중심에는 **도구 사용(Tool Use)**이라는 메커니즘이 있습니다. 이 글에서는 코딩 에이전트가 어떻게 작동하는지 그 원리를 하
코드를 작성하다 보면 AI의 도움이 필요한 순간이 자주 찾아옵니다. 복잡한 알고리즘을 짜야 할 때라든가 에러 메시지가 도통 이해가 안 될 때 말이죠. 이럴 때 에디터를 떠나서 ChatGPT나 클로드 코드를 따로 실행하면 작업 흐름이 끊기기 쉬운데요. Zed 에디터는 AI 기능을 에디터 깊숙이 통합해서 이런 컨텍스트 전환을 줄여줍니다. 에이전트 패널에서 AI와 대화하면서 코드를 수정하거나 인라인 어시스턴트로 선택한 코드를 즉석에서 바꾸는 것도 됩니다. 편집 예측은 다음에 칠 코드를 알아서 제안해주고요. 거기에 클로드 코드까지 에디터
터미널에서 코딩 에이전트를 쓰는 분이라면 클로드 코드를 먼저 떠올리실 텐데요. OpenAI도 비슷한 도구를 내놓았습니다. 바로 Codex CLI입니다. Codex CLI는 2025년 4월 16일 공개된 OpenAI의 코딩 에이전트로, 우리 컴퓨터에서 직접 실행되면서 코드를 읽고 고치고 명령을 실행합니다. 소스 코드가 Apache 2.0 라이선스로 공개되어 있고, ChatGPT 구독이 있으면 추가 비용 없이 쓸 수 있다는 점이 눈에 띄어요. 이번 글에서는 Codex CLI를 설치해서 쓰는 방법과 함께, 이 도구의 가장 큰 특징인 샌드
혹시 git worktree라는 Git 명령어를 아시나요? 사실 이 명령어는 Git 2.5(2015년)에 도입된 꽤 오래된 기능인데요. 그동안 잘 알려지지 않았다가 최근 Claude Code, Cursor 같은 AI 코딩 에이전트들이 적극적으로 활용하면서 다시 주목받고 있습니다. 여러 작업을 병렬로 처리하면서 변경사항을 안전하게 격리하기 위해서인데요. 이처럼 git worktree는 사람뿐 아니라 AI에게도 빠질 수 없는 도구가 되어가고 있습니다. 이번 글에서는 git worktree의 기본 개념과 실전 활용법에 대해 알아보겠습니다