Plan Mode와 Auto Mode

앞 장에서 우리는 컨텍스트를 어떻게 깨끗하게 유지할지 배웠다. 이제는 그다음 질문으로 넘어갈 차례다. 언제 생각만 할 것인가, 언제 손을 맡길 것인가. 솔로 빌더에게 이 구분은 단순한 취향 문제가 아니다. 여기서 일정이 빨라지기도 하고, 반대로 며칠치 복구 작업이 생기기도 한다.

한 문장으로 요약하면 이 장의 핵심은 이것이다. 속도는 Auto가 주지만, 방향은 Plan이 지킨다.

Plan Mode는 서두르는 AI에게 "잠깐, 먼저 설계도부터 보자"라고 말하는 기능이다. Auto Mode는 반대로 "이제 계획은 섰으니, 자잘한 승인 팝업 없이 쭉 달려보자"에 가깝다. 둘은 경쟁 관계가 아니라 역할 분담 관계다. 설계와 실행을 분리할수록, 혼자 일하는 사람의 판단력은 오히려 더 강해진다.

Plan Mode로 먼저 설계하고 실행하기

복잡한 작업일수록 사람은 손부터 움직이고 싶어진다. "일단 고치다 보면 보이겠지"라는 마음이 들기 때문이다. 그런데 AI 에이전트와 일할 때 이 습관은 꽤 비싸다. 에이전트는 망설임이 적어서, 방향이 애매해도 일단 코드를 쓰기 시작한다. 문제는 속도가 빠른 만큼, 잘못된 방향으로도 빠르다는 점이다.

Plan Mode는 이 조급함을 강제로 끊어 준다. 이 모드에서는 Claude가 코드를 읽고, 영향 범위를 분석하고, 단계별 계획을 제시할 수는 있지만 파일을 수정하거나 명령을 실행할 수는 없다.¹ 말하자면 공사장에 들어가기 전에 현장을 둘러보고 도면을 그리는 시간이다.

복잡한 리팩터링, 인증 구조 변경, 데이터베이스 스키마 변경, 여러 파일에 걸친 기능 추가처럼 되돌리기 비용이 큰 작업은 거의 항상 Plan부터 시작하는 편이 낫다.¹ 반대로 수정 내용을 한 문장으로 정확히 설명할 수 있는 작업, 예를 들어 오타 수정이나 변수명 하나 바꾸기 같은 일은 굳이 Plan으로 들어갈 필요가 없다.

실전에서는 이런 식으로 쓰면 좋다.

1. 먼저 Plan Mode로 들어가 현재 구조를 읽게 한다.

2. 목표, 제약, 수정하면 안 되는 것까지 명확히 말한다.

3. 수정 대상 파일, 단계별 순서, 위험 요소, 검증 방법을 포함한 계획을 받는다.

4. 계획을 고친 뒤에만 실행 모드로 전환한다.

5. 구현은 승인된 계획의 순서대로 진행하게 한다.

예를 들어 당신이 혼자 만드는 SaaS에 "팀 초대와 권한 관리"를 붙인다고 해 보자. 겉으로는 초대 메일 하나 보내는 기능처럼 보여도 실제로는 사용자 모델, 조직 테이블, 권한 체크 미들웨어, 요금제 제한, UI 상태, 감사 로그까지 엮인다. 이런 작업을 일반 모드에서 바로 시작하면 AI는 대개 눈앞의 화면부터 고치기 쉽다. 하지만 Plan Mode에서는 먼저 "어떤 데이터가 추가되는가", "기존 단일 사용자 흐름과 충돌하지 않는가", "롤백은 가능한가"를 먼저 묻게 된다. 이 차이가 품질 차이다.

좋은 계획은 장황하지 않지만 빠진 것도 없다. 목표가 분명하고, 영향을 받는 범위가 드러나며, 중간 체크포인트가 있고, 실패했을 때 되돌아오는 길까지 적혀 있어야 한다. 솔로 빌더에게 특히 중요한 것은 롤백 전략이다. 팀에서는 누군가 대신 브레이크를 잡아주지만, 혼자 일할 때는 계획서 안에 브레이크가 들어 있어야 한다.

또 하나 기억할 점이 있다. Plan Mode는 느리게 만드는 기능이 아니라, 헛수고를 줄이는 기능이다. 처음 10분을 설계에 쓰면 나중 2시간을 아낄 수 있다. 혼자 만드는 사람에게는 이 2시간이 그냥 시간이 아니라, 출시일과 사기의 차이일 때가 많다.

Auto Mode의 위험 프로파일

Plan이 "생각 먼저"라면, Auto는 "이제 승인 피로를 줄이자"에 가깝다. Claude Code는 원래 파일 수정이나 셸 실행 때 권한과 규칙을 확인하도록 설계되어 있다. 그런데 긴 구현 세션에서는 사람이 어느 순간 개발자가 아니라 승인 버튼 담당자가 되어 버릴 수 있다. Auto Mode는 이 마찰을 줄이기 위해 나온 방식이다.²

중요한 점은 Auto가 단순한 무제한 허용이 아니라는 것이다. 공식 문서 기준으로 Auto Mode는 백그라운드 안전 검사로 도구 호출이 요청과 얼마나 맞는지 확인하면서 자동 승인 범위를 넓힌다. 현재는 연구 프리뷰 성격이 강하고, 권한 규칙과 함께 동작한다.² 즉, "눈 감고 맡기는 모드"라기보다 작은 승인들을 자동화하는 모드에 가깝다.

예를 들어 긴 리팩터링 세션에서 작업 디렉터리 안의 일반적인 수정이나 흔한 파일 작업은 더 자연스럽게 흘러가게 하고, 위험한 명령이나 범위 밖 동작은 여전히 막거나 묻게 된다. 이 점이 중요하다. Auto는 사람을 없애는 기능이 아니라, 사람의 개입 시점을 더 비싼 결정에 집중시키는 기능이다.

여기서 중요한 것은 "Auto를 켤까 말까"보다, 어떤 위험 프로파일로 Auto를 운영할까다. 혼자 일할수록 모드를 감으로 고르지 말고 기준으로 골라야 한다.

이 표의 핵심은 단순하다. 기준은 "얼마나 빨리 끝내고 싶은가"가 아니라, 망했을 때 얼마나 크게 망하는가다.

로그인 페이지 문구를 바꾸다 실수하면 웃고 고치면 된다. 하지만 결제 웹훅이나 사용자 권한 체계를 잘못 건드리면 매출, 신뢰, 잠이 함께 날아간다. 그때는 Auto보다 Plan이 먼저 운전대를 잡아야 한다.

YOLO 모드를 안전하게 쓰는 법

실무에서 사람들이 흔히 "YOLO 모드"라고 부르는 것은 대개 bypassPermissions처럼 권한 확인을 사실상 건너뛰는 사용 방식이다.² 이름부터 분위기가 심상치 않다. 빠른 것은 맞다. 대신 사고가 나면 아주 빠르게 커진다.

이 모드는 로컬 노트북에서 아무 생각 없이 켜는 기능이 아니다. 특히 브라우저 쿠키, 클라우드 자격 증명, 프로덕션 .env, SSH 키가 그대로 있는 개발 환경이라면 더 그렇다. 솔직히 말해, 이런 환경에서 YOLO는 용기가 아니라 무방비다.

그래도 정말 써야 할 때가 있다. 수십 개 파일을 한꺼번에 기계적으로 정리해야 하거나, 격리된 환경에서 장시간 자율 실행을 실험하고 싶을 때다. 그럴 때는 최소한 아래 원칙은 지켜야 한다.

• 버려도 되는 환경에서만 실행한다. 일회용 컨테이너, 별도 VM, 혹은 격리된 세션이 기본이다.

• 운영 자격 증명은 빼고 시작한다. 프로덕션 API 키, 클라우드 관리자 권한, 개인 SSH 키를 넣은 채로 돌리지 않는다.

• 메인 브랜치와 분리한다. 전용 브랜치에서만 작업하고, 보호 브랜치 규칙과 PR 리뷰 단계를 남겨 둔다.

• 되돌릴 수 있게 해 둔다. DB 백업, 스냅샷, 롤백 스크립트 없는 YOLO는 그냥 점프다.

• 배포 전에는 반드시 사람 검토를 넣는다. diff, 테스트, 보안 체크는 마지막에 직접 확인한다.

여기서 중요한 포인트는 하나다. YOLO는 실행 속도를 높여 주지만, 판단 책임까지 대신 가져가 주지는 않는다. 혼자 만드는 사람일수록 이 책임의 최종 소유자는 언제나 본인이다.

차라리 더 현실적인 전략은 이렇다. 설계는 Plan에서 하고, 구현은 Auto나 acceptEdits에서 돌리고, 정말 무제한 자율 실행이 필요할 때만 격리된 환경에서 YOLO를 쓴다. 그러면 속도는 많이 얻고, 파국 확률은 꽤 줄일 수 있다.

권한 시스템과 샌드박싱 이해하기

이제 가장 자주 헷갈리는 개념을 정리해 보자. 권한 시스템과 샌드박싱은 비슷해 보이지만 하는 일이 다르다.

권한 시스템은 "이 도구를 써도 되는가"를 결정한다. 샌드박싱은 "그 도구가 실행되더라도 어디까지 닿을 수 있는가"를 제한한다.²³

권한 쪽부터 보자. Claude Code는 allow, ask, deny 규칙으로 도구 사용을 관리하고, 규칙은 deny → ask → allow 순서로 평가된다.² 즉, 금지 규칙이 가장 강하다. 또한 모드마다 승인 방식도 다르다. default는 표준 모드, acceptEdits는 작업 디렉터리 안의 파일 수정과 흔한 파일 작업을 더 쉽게 통과시키는 모드, plan은 읽기 전용, auto는 백그라운드 안전 검사가 붙는 모드, dontAsk는 미리 허용된 것만 돌리고 나머지는 거부하는 모드다. bypassPermissions는 말 그대로 거의 모든 브레이크를 제거한다.²

이 구조를 이해하면 모드 선택이 쉬워진다. 모드는 성격이 아니라 권한 정책의 묶음이다. 지금 내가 원하는 것이 "신중한 탐색"인지, "빠른 구현"인지, "잠긴 자동화"인지에 따라 고르면 된다.

샌드박싱은 그다음 방어선이다. 공식 문서와 엔지니어링 설명에 따르면 Claude Code의 샌드박싱은 운영체제 수준에서 파일시스템과 네트워크를 격리한다. Bash 도구와 그 하위 프로세스가 정해진 디렉터리와 허용된 네트워크 경계 안에서만 움직이게 만드는 식이다.³ macOS에서는 Seatbelt, Linux에서는 bubblewrap 같은 OS 수준 기술을 사용한다는 설명도 공개되어 있다.³

비유하면 권한 시스템이 건물 1층의 안내 데스크라면, 샌드박스는 각 층마다 달린 잠금문이다. 안내 데스크에서 실수로 통과시켰더라도, 잠금문이 있으면 더 안쪽까지는 못 들어간다.

이게 왜 중요할까. AI 에이전트의 대표 위험 중 하나가 프롬프트 인젝션이기 때문이다. README, 스크립트, 웹 문서, 명령 출력 어딘가에 악의적인 지시가 숨어 있을 수 있다. 이때 권한만 믿으면 사람은 승인 피로에 지고, 에이전트는 속을 수 있다. 하지만 샌드박스가 파일시스템과 네트워크를 함께 막고 있으면, 설령 유도에 걸려도 시스템 파일을 고치거나 외부로 정보를 빼내기가 훨씬 어려워진다.³

Anthropic은 내부 사용에서 샌드박싱이 권한 프롬프트를 크게 줄이면서도 더 안전한 자율 실행을 가능하게 했다고 설명한다.³ 이 말이 뜻하는 바는 단순하다. 안전과 자율성은 꼭 반대말이 아니다. 경계를 잘 그으면 둘을 같이 얻을 수 있다.

따라서 솔로 빌더의 실전 원칙은 이렇게 정리된다. Auto를 쓰고 싶다면 샌드박스를 먼저 생각하라. YOLO를 쓰고 싶다면 샌드박스는 선택이 아니라 전제다.

솔로 빌더의 추천 운영 패턴

이 장의 내용을 실제 작업 흐름으로 바꾸면 의외로 단순하다.

아침에 큰 작업을 시작할 때는 먼저 Plan Mode로 들어가 범위, 영향 파일, 리스크, 테스트 방법을 정리한다. 점심 전까지 계획이 흔들리면 아직 실행할 때가 아니다. 반대로 계획이 단단해졌다면, 작업 성격에 맞게 acceptEdits나 Auto로 넘긴다. 이때 인증, 결제, 배포는 보수적으로 가고, 리팩터링이나 테스트 보강은 더 공격적으로 가도 된다. 그리고 자율 실행 시간이 길어질수록 브랜치 분리, 샌드박스, 롤백 수단을 먼저 확보한다.

가장 추천하는 패턴은 이것이다.

1. 복잡한 작업은 무조건 Plan에서 시작한다.

2. 계획이 승인되면 Balanced 프로파일로 Auto를 검토한다.

3. Auto를 켤 때는 작업 디렉터리, 허용 범위, 브랜치를 먼저 점검한다.

4. 배포 전 단계에서는 다시 사람 검토를 넣는다.

5. 무제한 자율 실행은 격리된 환경에서만 쓴다.

결국 Plan Mode와 Auto Mode는 상반된 철학이 아니다. 하나는 방향 감각을 지켜 주고, 다른 하나는 손목의 피로를 줄여 준다. 솔로 빌더가 둘을 함께 쓸 수 있게 되면, AI는 더 이상 "코드 좀 대신 써주는 봇"이 아니다. 설계할 때는 냉정한 아키텍트가 되고, 실행할 때는 지치지 않는 조수가 된다.

혼자 만드는 사람에게 필요한 것은 무작정 빠른 AI가 아니다. 잘 생각한 뒤, 안전하게 빨라지는 시스템이다. 그 시작점이 바로 Plan과 Auto의 분리다.

참고

¹Plan Mode

²Configure permissions

³Making Claude Code more secure and autonomous with sandboxing