매일 Claude Code 를 사용하는데도 왜 당신의 워크플로우는 변하지 않았을까
"분명 /init 을 실행한 기억은 있는데, 마지막으로 업데이트한 게 언제인지는 기억이 안 나요."
이 얘기가 당신에게도 해당되나요? Claude Code 를 설치하고, 처음 며칠은 설정하느라 바빴고, 매일 같이 대화를 나누고 있습니다. 하지만 석 달 전과 비교해도 작업의 구조는 거의 변하지 않았습니다.
이것은 사용법의 문제가 아니라, 위치 선정의 문제입니다.
Claude Code 를 계속해서 "말을 걸면 대답해주는 도구" 로만 사용한다면, 매일 아침 같은 지시를 입력하고, 비슷한 응답을 받아서 작업에 복사해 넣는 일을 반복하게 됩니다. 효율성은 높아졌을지 몰라도, 작업이 진행되는 방식 자체는 근본적으로 바뀌지 않습니다.
변화는 Claude Code 를 "설계의 대상" 으로 바라보기 시작할 때 일어납니다. 어떤 맥락(Context)에서 누가 무엇을 알고 있는가? 어떤 작업이 누구에게 위임되는가? 사람이 없어도 움직이는 것은 무엇인가? 이것을 설계라고 생각하기 시작하면, Claude Code 는 완전히 다른 방식으로 작동하기 시작합니다.
@sairahul1 님이 공개한 27 가지 기능 (https://x.com/sairahul1/status/2070428662080618607) 은 이러한 설계 관점에서 사용해야 할 기능들을 체계적으로 정리한 것입니다. Swarm 은 이 기능들을 에이전트 설계의 렌즈를 통해 해석하고, 실제 비즈니스 현장에 적용할 수 있는 형식으로 정리했습니다.
27 개라면 많아 보일 수 있지만, 핵심 원칙은 단 세 가지입니다. 이 구조에 대해서는 다음 장부터 순서대로 설명하겠습니다.
27 가지 기능을 연결하는 세 가지 원칙
27 가지 기능을 살펴보면, 이것저것 흩어져 있는 것처럼 보일 수 있습니다. 단축키, 파일 설정, 음성 입력, 테스트 실행 등이 있습니다. 하지만 그 내용을 분석해보면, 세 가지 질문에 답하는 그룹으로 정리할 수 있습니다.
원칙 1: 맥락 설계 (Context Design) (기능 1–5)
Claude 가 "누구의 프로젝트인지, 어떤 목적인지, 현재 어느 정도 이해하고 있는지" 를 알 수 있는 상태를 만드는 것입니다. 이것이 무너지면 매번 모든 것을 처음부터 설명해야 합니다.
원칙 2: 위임 설계 (Delegation Design) (기능 6–14)
작업과 권한을 구조적으로 Claude 에게 넘기는 것입니다. "버그를 고쳐줘" 라고 말하는 대신, "무엇이 고장 났고, 제약 조건은 무엇인지" 를 정리해서 넘기면, 한 번에 해결될 확률이 달라집니다.
원칙 3: 자율성 설계 (Autonomy Design) (기능 15–27)
Claude 가 사람의 지시 없이도 계속 움직일 수 있는 메커니즘을 설계하는 것입니다.
이 세 단계는 또한 사용해야 할 순서이기도 합니다. 맥락이 설정되지 않으면 위임이 엉성해집니다. 위임이 설계되지 않으면 자율성은 통제 불능이 됩니다.
여기서 주의해야 할 점은 "내가 매일 아침 Claude 에게 지시하는" 구조를 어떻게 바꿀 것인가입니다. 매일 아침 같은 작업을 채팅에 던지고 있다면, 여전히 사람이 주체입니다. 설계가 Claude 를 움직이는 구조로 전환되면, 당신이 아침에 하는 일도 달라집니다.
먼저, 맥락 설계의 다섯 가지 기능을 살펴보겠습니다.
맥락 설계의 기본
맥락 설계의 목표는 Claude 에게 "이 프로젝트의 맥락" 을 제공하는 것입니다. 맥락이 없으면 모든 대화는 백지 상태에서 시작됩니다.
가장 먼저 실행해야 할 것은 `/init` 입니다.
처음 프로젝트를 열었을 때, 이것을 먼저 실행하세요. Claude 가 코드베이스 구조, 의존성, 빌드 명령어를 스캔하여 자동으로 CLAUDE.md 를 생성합니다. 이 파일은 프로젝트의 "설계도" 가 됩니다.
많은 사람들이 여기서 멈춥니다. /init 을 실행한 기억은 있지만, 마지막으로 업데이트한 때는 모릅니다. 생성된 그대로 방치하면, 프로젝트가 변경됨에 따라 CLAUDE.md 의 내용은 현실과 동떨어지게 됩니다. 매주 업데이트한다는 전제로 운영하면, Claude 는 항상 최신 맥락 안에서 움직일 수 있습니다.
다음으로, `/statusline` 을 설정해두면 유용합니다.
화면 하단에 상태 표시줄이 나타납니다. 현재 실행 중인 것과 어떤 프로세스가 활성화되어 있는지 시각적으로 파악할 수 있습니다. Vim 이나 Neovim 의 커스텀 상태 표시줄과도 연동할 수 있어, 기존 편집기 환경에 맞춰 설정할 수 있습니다.
세 번째는 음성 입력입니다.
Mac 에서 ⌃⌘Space 를 사용하거나 iOS 및 Android 의 기본 음성 입력을 사용하여 말로써 복잡한 요구사항을 전달할 수 있습니다. "이 컴포넌트를 이런 이유로 이렇게 움직이게 하고 싶은데, 기존 스타일은 변경하지 마" 와 같은 긴 지시를 입력하지 않고 전달할 수 있습니다. 생각나는 대로 전달할 수 있으므로, 입력하면서 정리하는 시간을 절약할 수 있습니다.
`/context` 를 사용하여 맥락의 상태를 확인하세요.
현재 대화에 무엇이 들어있는지, 맥락 창(Context Window) 사용량을 실시간으로 확인할 수 있습니다. 긴 세션에서는 처음에 설정한 설계도의 내용이 희미해지기 쉽습니다. 이 명령어를 사용하면 그것을 모니터링할 수 있습니다.
그리고 이를 위한 리셋 작업은 `/compact` 와 `/clear` 입니다.
/compact 는 전체 맥락을 요약본으로 압축합니다. /clear 는 완전히 리셋하는 것입니다. 긴 세션을 계속하면 Claude 의 답변이 모호해질 수 있습니다. 이것은 맥락이 막혔다는 신호입니다. 주기적으로 /compact 를 사용하면 출력 품질을 유지할 수 있습니다.
이전: 긴 세션 후반부에 "아까 논의한 설계 정책을 따라" 라고 말해도 Claude 가 엉뚱한 답변을 내놓습니다.
이후: 계속하기 전에 /compact 로 압축하면 정책에 정확한 출력을 유지할 수 있습니다.
다섯 가지 기능은 한 가지 일을 합니다: Claude 가 "알고 있는" 상태를 설계로 유지하는 것입니다. 이것이 다음 단계인 위임 설계의 기초가 됩니다.
문제를 전달하는 기술
맥락이 설정되면, 다음 단계는 문제를 어떻게 전달할 것인가입니다. "버그를 고쳐줘" 라고 말하는 것과 구조화된 방식으로 전달하는 것에 따라 응답의 정확도가 완전히 달라집니다.
첫 번째, 계획 모드(Plan Mode, `Shift+Tab`)를 사용하세요.
주요 변경 전에, 이 모드는 실행 대신 "계획만" 을 출력합니다. Claude 가 무엇을 어떤 순서로 변경하려고 하는지 미리 확인할 수 있습니다.
오류가 발생한 후에 고치는 대신, 계획 단계에서 "그건 잘못됐어" 라고 지적할 수 있습니다. 이 한 단계를 설계에 포함시키는 것만으로 예상치 못한 변경의 빈도가 크게 달라집니다. 계속 사용하다 보면, 나중에 "왜 이 파일이 덮어쓰여졌지?" 라고 확인하는 수고가 줄어든다는 것을 깨닫게 됩니다.
두 번째는 문제, 제약 조건, 맥락의 구조화입니다.
"버그를 고쳐줘" 라고만 말하면, Claude 는 스스로 추정을 채워 넣으려고 합니다. 그 추정이 틀리면 해결책도 틀리게 됩니다.
공식적으로 권장되는 형식은 첫 줄에 "무엇이 고장 났는지" 를 쓰고, 두 번째 줄부터 "시도해 본 것, 제약 조건, 예상 출력 형식" 을 작성하는 것입니다. 이 형식으로 전달하는 것만으로도 한 번에 해결되는 비율이 달라집니다. 문제를 전달하는 방식 자체가 하나의 기술이 되는 것입니다.
세 번째는 `AskUserQuestion` 입니다.
이 기능은 Claude 가 모호한 요구사항을 만났을 때, 진행하기 전에 명확히 하기 위해 질문을 하는 기능입니다. 모호한 요구사항으로 구현을 진행하다가 발생하는 재작업은 이 기능을 사용하지 않을 때 자주 발생합니다. 구현 전에 확인하는 비용을 먼저 지불하는 설계입니다.
네 번째는 자체 검증 단계입니다.
작업이 끝날 때 "테스트를 실행하고 빌드가 통과하는지 확인한 후에 종료해" 라고 지시합니다. 이것을 매번 수동으로 추가하는 대신 CLAUDE.md 에 작성해두면 모든 작업이 끝날 때 자동으로 실행됩니다. 변경 후에 Claude 가 작동하지 않는 상태에서 멈추는 대신, 검증을 포함한 루프가 하나의 작업으로 완료됩니다.
계획 모드로 능동적인 조치를 취하고, 자체 검증으로 반응적인 단계를 자동화합니다. 이 두 가지가 설계에 통합되는 순간, 개발 흐름의 구조가 바뀝니다.
다음 장에서는 지속적인 작업을 Claude 에게 위임하는 설계에 대해 알아보겠습니다.
위임 설계하기
지금까지 Claude 와 소통하는 방법과 기억을 유지하는 방법에 대해 정리했습니다. 다음은 "누가 주체가 되는가" 를 바꾸는 것에 관한 내용입니다.
10. 하위 에이전트 (Subagents)
긴 작업 중에 사람이 절차를 관리하면 필연적으로 막히게 됩니다. "다음에 이것을 하고, 끝나면 저것을 해" 라고 계속 말하는 것은 Claude 가 아니라 사람이 조정을 담당하고 있는 것입니다.
TodoWrite 나 Task 도구를 사용하여 Claude 는 작업을 하위 작업으로 분해하고 병렬로 실행합니다. 공식 용어로는 "동시 하위 에이전트 실행(concurrent subagent execution)" 이라고 하며, 여러 개의 자식 Claude 가 동시에 움직이는 구조입니다. 서로 다른 Claude 가 리서치, 구현, 테스트를 동시에 실행합니다. 사람이 절차를 쥐고 있을 필요가 없습니다.
11. 커스텀 스킬 (Custom Skills, 워크플로우 템플릿 파일)
.claude/commands/ 디렉토리에 Markdown 파일을 배치하면 /명령어-이름 으로 명령어 세트를 호출할 수 있습니다. Swarm 의 맥락에서는 "SKILL.md (워크플로우 템플릿 파일)" 이라고 생각하는 것이 더 쉽습니다.
이전: "경쟁사 조사를 부탁합니다. 순서는 1, 2, 3..." 을 매번 작성해야 했습니다.
이후: /competitive-research 라고 한 줄만 입력하면 됩니다.
똑같은 지시를 반복해서 작성하는 시간이 사라집니다. 팀과 공유하면 누구나 동일한 품질의 출력을 얻을 수 있는 템플릿이 됩니다.
12. 모델 선택 (Model Selection)
Alt+P 를 눌러 세션 내에서 모델을 전환할 수 있습니다. 현실적인 3단계 사용법은 다음과 같습니다: 설계 및 개념 단계에는 고추론(high-reasoning) 모델, 간단한 구현에는 경량 모델, 디버깅에는 중간급 모델을 사용합니다.
모델의 성능을 작업의 무게에 맞추면 비용 효율성과 응답 속도를 동시에 개선할 수 있습니다.
13. 자동 CLAUDE.md 업데이트
Claude 에게 "이번 프로젝트에서 배운 내용을 CLAUDE.md 에 추가해줘" 라고 지시하면, Claude 가 스스로 CLAUDE.md 를 업데이트합니다. 설계도가 스스로 성장하는 구조입니다.
이 명령어를 일주일에 한 번 추가하면, CLAUDE.md 는 "살아있는 문서" 가 됩니다. 사람이 회고를 작성하지 않아도 Claude 가 학습한 내용을 축적합니다.
14. 외부 파일 연결
@{파일_경로} 를 사용하여 파일, URL 또는 이슈(Issue)를 맥락으로 전달할 수 있습니다. "작업 전에 이 파일을 읽어" 라는 지시를 한 줄로 완료하는 메커니즘입니다.
이전: 파일 내용을 복사해서 프롬프트에 붙여넣어야 했습니다.
이후: "@src/config.yaml 을 참고하여 설정을 확인해" 라고만 쓰면 됩니다.
위임을 설계한다는 것은 주체를 Claude 에게 넘기는 시스템을 만드는 것입니다. 절차, 템플릿, 참조, 기억이 모두 갖춰지면, 사람은 "무엇을 만들 것인가" 만 생각하면 됩니다.
하지만 위임이 늘어날수록 "Claude 가 의도와 다른 방향으로 움직이는" 위험도 함께 증가합니다. 다음 장에서는 그 이탈(Drift)을 조기에 차단하는 방법을 알아보겠습니다.
이탈을 조기에 차단하기
Claude 에 대한 위임이 늘어나면 한 가지 문제가 더 자주 발생합니다: 의도했던 방향과 완전히 다른 쪽으로 가고 있다는 것을 깨닫는 것입니다. 우리는 이것을 이탈(Drift)이라고 부릅니다.
이탈은 나중에 고치는 것이 아니라, 사전에 설계 단계에서 조치를 취함으로써 예방할 수 있습니다.
15. 즉시 중단 (Immediate Stop)
출력이 명백히 잘못된 방향으로 가고 있다고 느껴지면, Escape 키를 눌러 즉시 중단할 수 있습니다. "다 끝나면 고치지 뭐" 는 실수입니다. 생성이 더 진행될수록 수정 비용은 증가합니다. 중간에 멈추고 프롬프트를 수정하는 것이 시간과 토큰을 모두 절약합니다.
무언가 잘못됐다는 직감이 들면, 망설이지 말고 중단하세요. 이 판단의 속도는 정확도에 직접적인 영향을 미칩니다.
16. 첫 번째 출력을 증거로 요청하기
작업을 시작하기 전에 "첫 번째 출력만 먼저 보여줘, 계속할지는 그걸 보고 결정할게" 라고 말하는 것이 능동적인 설계입니다.
10 분 동안 엉뚱한 방향으로 가게 놔두는 대신, 첫 번째 출력을 확인한 후에 실행하도록 하는 것입니다. 이것은 이탈을 미연에 방지하는 발상입니다. 장시간 작업이나 방향성이 모호한 상태에서 시작하는 작업에 필수적입니다.
"나머지는 네게 맡길게" 라고 말하기 전에 "시작 부분을 먼저 확인하게 해줘" 를 끼워 넣으세요. 단 한 단계이지만, 이 능동적인 움직임이 결과를 바꿉니다.
17. 알림 훅 (Notification Hooks)
긴 작업이 끝나길 기다리며 화면을 응시하는 것은 시간 낭비입니다. ~/.claude/hooks/ 에 스크립트를 배치하면 작업이 완료되었을 때 데스크톱 알림을 받을 수 있습니다.
한 번만 설정해 두세요. 그러면 다른 작업을 하고 있어도 Claude 가 끝났을 때 알려줍니다. 기다리는 행위 자체를 없애는 설계입니다.
18. 스크린샷 전달하기
UI 버그를 말로 설명하는 것은 놀라울 정도로 어렵습니다. "왼쪽 상단에 빨간색 오류가 뜨고 버튼을 누를 수 없어" 라고 말로 설명하는 대신 스크린샷을 전달하는 것이 더 빠릅니다.
Claude 는 이미지를 받고 오류 내용, 원인, 수정 제안을 그대로 반환합니다. "이 화면을 봐" 라고 말하는 것만으로 완료됩니다.
지금까지 소개한 18 가지 기능은 모두 한 사람이 운영하는 것을 전제로 합니다. 다음 장에서는 "팀으로 사용하는" 구조, 즉 여러 Claude 가 병렬로 실행되고 통합되는 구조로 들어갑니다.
병렬 운영 및 통합
Claude Code 를 채팅 도구로 사용하는 한, 하나의 작업이 끝날 때까지 다음 작업을 시작할 수 없습니다. 하지만 설계를 변경하면 여러 Claude 가 동시에 움직이는 구조를 만들 수 있습니다.
Chrome DevTools 통합부터 시작하세요. 브라우저 오류 로그와 네트워크 로그를 Claude Code 에 직접 전달할 수 있으므로, "콘솔에 빨간색 오류가 있는데 무슨 일인지 모르겠어" 와 같은 상황을 말로 설명할 필요가 없습니다. 공식 문서에는 이 기능을 위한 전용 페이지가 있으며, 디버깅의 관문으로 자리 잡고 있습니다.
세션 관리도 달라집니다. claude --continue 로 최신 세션을 그대로 재개하거나, claude --resume 으로 세션 목록에서 선택할 수 있습니다. 더 나아가 /rename 으로 세션에 이름을 지정하면 Git 브랜치와 같은 느낌으로 여러 작업을 병렬로 관리할 수 있습니다. "Auth", "Payment", "Dashboard" 라는 이름의 세션을 사용하면 맥락 전환 비용이 거의 제로가 됩니다.
그리고 병렬 운영의 핵심은 git worktrees 와의 조합입니다. claude --worktree feature-auth 를 입력하면 브랜치가 워크트리(Worktree)에 의해 완전히 분리된 세션이 시작됩니다. Auth, Payment, Dashboard 를 각각 별도의 워크트리에서 실행하면, 세 개의 Claude 가 병렬로 개발을 진행합니다. 각각 독립된 작업 공간에 있으므로 충돌이 발생하지 않습니다. 일주일 분량의 개발을 하루 만에 끝낼 수 있는 구조가 설계로서 여기에 확립됩니다.
MCP 에 대한 생각도 정리할 필요가 있습니다. MCP 서버가 항상 최적의 해결책은 아닙니다. 공식 문서에는 "CLI 도구가 외부 서비스와 상호작용하는 가장 맥락 효율적인 방법" 이라고 명시되어 있으며, gh 나 aws 와 같은 CLI 도구는 맥락 효율성이 높고 Rate Limit 에 걸릴 가능성이 적다고 합니다. gh 명령어만으로도 Claude Code 는 GitHub Issue 를 자율적으로 생성, 업데이트, 종료할 수 있습니다. MCP 를 추가하기 전에 CLI 도구로 해결할 수 있는지 먼저 확인하는 판단 축을 가지면 설계를 단순하게 유지할 수 있습니다.
병렬 설계가 가능해지면, 사람은 더 이상 작업 순서를 관리할 필요가 없습니다. 여러 개의 주체를 Claude 에게 동시에 전달하는 설계로 전환되기 때문입니다. 다음으로, 이렇게 설계된 병렬 처리를 책상에서 떨어져 있어도 계속 움직이는 시스템으로 발전시켜 보겠습니다.
자율 운영
병렬 설계 다음에 오는 질문은 "그동안 내가 어디에 있어야 하지?" 입니다. 자율 운영이 설계되면, 사람이 없어도 작업이 진행되는 상태가 만들어집니다.
/loop 는 세션 내에서 자동 폴링을 실행하는 기능입니다. 공식 설명은 "세션이 열려 있는 동안 빠른 폴링" 이며, 세션이 열려 있는 동안 지정된 작업을 반복합니다. --resume 또는 --continue 를 사용하면 만료되지 않은 세션을 재개할 수 있으며, 원문의 경험 보고에 따르면 최대 3 일간 무인 운영한 사례가 보고되었습니다. 그 기간을 공식 소스에서 직접 확인한 것은 아니지만, 장시간 자율 운영을 위한 진입점 역할을 확실히 합니다.
2026 년 1 분기에 추가된 원격 제어(Remote Control)는 로컬에서 실행 중인 Claude Code 세션을 스마트폰이나 PC 브라우저에서 조작하는 기능입니다. 코드는 로컬에 남아 있고, 메시지만 암호화된 채널을 통해 교환됩니다. 2026 년 2 월에 리서치 프리뷰로 출시되었습니다. 외출 중에 스마트폰에서 "테스트 통과했는지 확인해줘" 라고 보내기만 하면 로컬의 Claude Code 가 계속 움직이는 시나리오가 성립됩니다.
데이터베이스에 대한 자연어 쿼리도 설계에 통합할 수 있습니다. MCP 를 통해 SQLite, PostgreSQL 또는 MySQL 에 연결하면 SQL 을 작성하지 않고도 "지난주에 등록한 사용자를 알려줘" 와 같은 자연어로 데이터를 검색할 수 있습니다. 공식 가이드에서는 claude mcp add 를 실행하여 데이터베이스와 같은 외부 도구를 연결하고, 데이터 확인 루틴을 Claude 에게 위임할 것을 제안합니다.
사고 깊이를 제어하는 네 가지 기능도 있습니다. ultrathink 는 프롬프트에 해당 키워드를 포함시키기만 하면 최대 31,999 토큰의 확장 사고(Extended Thinking)를 실행합니다. 계층 구조가 있습니다: think 는 4,000 토큰, megathink 는 10,000 토큰, ultrathink 는 31,999 토큰입니다. 올바른 사용법은 복잡한 아키텍처 결정, 보안 구현, 성능 최적화, 대규모 리팩토링과 같은 진짜 어려운 10% 의 문제에만 사용하는 것입니다. 모든 질문에 사용하면 비용만 무의미하게 증가합니다.
/effort ultracode 는 전체 세션에 대해 xhigh 추론 및 동적 워크플로우를 활성화하는 설정입니다. ultrathink 가 한 턴의 키워드라면, ultracode 는 세션 전체에 걸쳐 활성화됩니다. 전체 코드베이스 감사, 수백 개의 파일 마이그레이션 또는 고위험 작업과 같은 "세션 전체의 무거운 작업" 에 적합합니다. 하지만 토큰 비용이 크게 증가하므로, 상황을 식별하는 것이 효과를 좌우합니다.
채팅에 입력하여 움직이게 하던 Claude Code 는 이벤트를 감지하고 자율적으로 움직이는 시스템의 관문에 도달했습니다. 사람이 움직이는 대신, 설계가 Claude 를 움직입니다. 다음으로, 이러한 모든 기능을 통해 생산성의 차이가 본질적으로 어디서 발생하는지 확인해 보겠습니다.
같은 Claude Code 로도 결과가 다른 이유
빠르게 개발하는 사람들이 특별한 능력을 가지고 있는 것은 아닙니다. 그들은 단지 더 체계적으로 설계하고 있을 뿐입니다.
예를 들어, /init 을 실행하는 상황을 생각해 보세요. 같은 명령어를 입력하더라도, 몇 달 후의 출력 품질은 매주 업데이트되는 CLAUDE.md 와 설정 이후 방치된 CLAUDE.md 사이에 완전히 차이가 납니다. Claude 가 읽는 맥락의 최신성과 정확성이 출력 품질에 직접적인 영향을 미치기 때문입니다.
주방에 비유하자면, 요리의 수준은 어떤 재료를 사용하는지보다 부엌 자체가 어떻게 정리되어 있는지에 의해 더 크게 결정됩니다. Claude 의 모델 성능은 모든 사용자에게 동등하게 제공됩니다. 차이는 맥락이 어떻게 정리되었는지, 지시가 어떻게 체계화되었는지, 자율 운영이 어떻게 설계되었는지 이 세 가지 지점의 정확성에 있습니다.
"어떤 모델을 사용할까" 를 논의하기 전에, 현재 CLAUDE.md 가 마지막으로 업데이트된 때를 확인해 보세요. 그것이 현재 설계의 상태를 말해줄 것입니다.
그렇다면 실제로 어디서부터 시작해야 할까요? 다음 장에서는 단계별 도입 순서를 정리해 보겠습니다.
어디서부터 시작할까: 단계별 도입 가이드
27 개를 모두 한 번에 기억하려고 할 필요는 없습니다.
첫 주에는 다음 네 가지만으로 시작하세요.
/init으로 프로젝트 맵을 만듭니다./compact로 주기적으로 맥락을 압축합니다.- 계획 모드(Plan Mode,
Shift+Tab)로 탐색과 실행을 분리합니다. - 자체 검증 단계(테스트, 빌드)를 Claude 에게 전달합니다.
이 네 가지만으로도 세션의 품질은 근본적으로 달라집니다. Claude 가 "무엇을 해야 하는지" 정확히 파악한 상태에서 움직이기 시작하므로, 재작업의 양이 눈에 띄게 줄어듭니다.
두 번째 주부터는 이 기반 위에 위임 설계를 추가합니다. 커스텀 스킬(Custom Skills)로 지시를 재사용 가능한 형식으로 요약하고, 모델 선택(Alt+P)으로 처리의 무게와 속도를 조절하며, CLAUDE.md 를 매주 업데이트하는 습관을 만듭니다. 이것은 지시를 "매번 작성하는 것" 에서 "축적되는 것" 으로 바꾸는 단계입니다.
한 달 후에는 하위 에이전트(Subagents), git worktrees, 병렬 세션으로 진행합니다. 여러 기능을 동시에 개발하면서 설계와 확인에 집중할 수 있는 시스템을 갖추게 됩니다.
ultrathink 와 ultracode 는 이 흐름 속에서 "진짜 어려운 문제" 를 만났을 때 처음 사용하는 도구입니다. 모든 문제에 꺼내는 도구가 아닙니다.
이러한 단계를 거치면 "각 기능이 왜 필요한지" 를 경험을 통해 이해하게 될 것입니다. 첫 주에는 네 가지 항목부터 시작해 보세요.
설계의 대상으로 삼는 순간 모든 것이 바뀐다
Claude Code 를 설계의 대상으로 삼기 시작하는 순간, 세션의 품질은 근본적으로 바뀝니다.
이 글에서 소개한 내용을 저장해 두고 다시 볼 수 있는 형태로 요약합니다.
/init+/compact+ 계획 모드 + 자체 검증, 이 네 가지가 가장 기본적인 기본 설계입니다.- 커스텀 스킬(Custom Skills)로 지시의 재사용을 체계화하고,
CLAUDE.md를 매주 업데이트되는 "살아있는 설계도" 로 성장시키세요. - 하위 에이전트(Subagents)를 사용하기 시작하면 생산성이 덧셈에서 곱셈으로 바뀝니다.
- 이탈을 조기에 감지하고 즉시 중단하는 것이 철칙입니다. 항상 첫 번째 출력에서 증거를 요청하세요.
git worktrees+ 병렬 세션으로 여러 기능을 동시에 개발할 수 있습니다./loop로 자율 운영을 설정하고, 원격 제어(Remote Control)로 스마트폰에서 확인하거나 지시하세요.ultrathink는 "진짜 어려운 10%" 를 위한 전용 도구입니다. 모든 문제를 위한 것이 아닙니다.
이 글에서 언급된 기능 중 하나라도 시도해 본다면, Claude Code 와의 관계는 점차 변화하기 시작할 것입니다.
AI 에이전트에 관심이 있으신가요?
Swarm (@swarm_japan) 은 에이전트에 필요한 필수 설계 철학과 비즈니스 사용 사례를 공유합니다.
저희를 팔로우하여 AI 에이전트 시대에 필요한 비즈니스 지식을 습득하세요 👇
★ 최신 AI 에이전트 정보를 독특한 관점으로 설명합니다
★ 에이전트의 비즈니스 사용 사례를 소개합니다
★ 독자적인 노하우를 공개합니다
관심이 있으시다면, 꼭 팔로우하고 확인해 보세요! 👀
