Part 2 정리

AI에게 일을 맡기는 구조

What vs How, 그리고 자율 루프

Part 1의 수동 체크리스트를 코드로 바꾸면서 Part 2가 시작되었습니다. 핵심은 "어떻게 하라"에서 "무엇이 되어야 한다"로 옮겨가는 것입니다.

• What vs How: How는 단계를 하나하나 지시합니다. What은 목적지만 알려줍니다. AI가 막혔을 때 스스로 다른 방법을 시도할 수 있으려면 What이어야 합니다.
• 테스트 기반 검증: 수동 체크리스트를 테스트 코드로 변환하면, AI가 코드 변경 후에도 기존 기능이 정상인지 자동으로 확인합니다. bun run test 한 번이 브라우저 수동 클릭을 대체합니다.
• 성공 기준: "잘 동작해야 한다"가 아니라 "이 입력이면 이 출력"입니다. 구체적 입출력이 있어야 AI가 스스로 검증할 수 있습니다.
• 자율 루프: 테스트가 있으면 AI가 시도 -> 확인 -> 수정을 스스로 반복합니다. 코드는 실행하면 맞다/틀리다가 즉시 나오는 매체이기 때문에 가능합니다.

계획과 작업의 연결

성공 기준은 테스트 코드뿐 아니라 계획에도 씁니다. 계획은 context overflow와 auto-compact를 거쳐도 살아 있어야 합니다.

• 성공 기준과 Red Green Refactor: 요구사항 + 성공 기준 + 범위 제한으로 계획을 세우고, 성공 기준 목록에서 하나씩 테스트로 검증하며 구현합니다. Plan -> 실행 -> 발견 -> 다시 Plan 사이클로 기능을 정교하게 다듬습니다.
• Task 시스템: 작업 목록을 ~/.claude/tasks/에 JSON으로 저장합니다. auto-compact가 대화를 요약해도 파일의 진행 상황은 그대로 남습니다. blockedBy/blocks로 의존성을 설정하면 독립 작업을 병렬로 실행할 수 있습니다.

지침을 필요한 조건에 맞게 나누기

작업 지침은 필요한 조건에 따라 저장 위치를 나눴습니다. 모든 내용을 CLAUDE.md에 쌓지 않고 지금 세션, 파일과 작업에 필요한 지침만 읽게 합니다.

• CLAUDE.md: 기술 스택, 검사 명령처럼 모든 세션에서 필요한 프로젝트 공통 기준을 둡니다.
• Rules: .claude/rules/에 파일별 규칙을 분리하고 paths로 필요한 경로에서만 적용합니다.
• Skills: 커밋·코드 리뷰·배포처럼 특정 작업에서 반복하는 절차를 둡니다. 이름과 설명 → 본문 → 보조 파일 순서로 필요한 만큼 읽습니다.
• Skill 만들기와 설치: SKILL.md의 description으로 자동 호출 범위를 정합니다. 직접 만든 Skill은 Skill Creator로 개선하고, 범용 Skill은 공식 Plugin이나 skills.sh에서 가져옵니다.
• Skill 개선하기: 수정한 Skill이 실제로 나아졌는지 감으로 판단하지 않습니다. Skill Creator의 Eval로 "수정 전 vs 수정 후" 를 같은 시나리오에 돌려 통과율·토큰·시간을 나란히 비교하면, 개선을 수치로 확인할 수 있습니다. (참고 자료에서 자세히 보기)

Claude의 범위를 확장하는 외부 도구

Rules와 Skills는 Claude가 따를 규칙과 절차를 제공합니다. 하지만 외부 시스템에 접근할 경로까지 만들지는 않습니다. CLI와 MCP는 Claude가 사용할 수 있는 도구를 늘립니다.

• CLI: 개발자가 이미 쓰던 터미널 도구를 Claude에게 그대로 빌려줍니다. gh·aws·kubectl 같은 유명 CLI는 Claude가 이미 학습해서 바로 호출합니다. 결과를 파이프로 가공하고, 실행한 명령어를 개발자가 터미널에서 직접 재현할 수 있습니다.
• MCP: MCP를 하나 붙일 때마다 Claude의 Tool 상자가 커집니다. CLI가 주류인 지금도 MCP가 더 유리한 상황은 세 가지입니다. 실행 중인 내 앱 세션에 접근할 때 (Claude in Chrome·Playwright MCP), 공식 CLI가 없는 SaaS에 붙을 때 (Figma·Notion·Linear), .mcp.json 을 팀과 공유할 때입니다. Claude Code (Host + Client) 가 서버 프로세스를 띄워 stdio로 통신합니다
• Custom MCP: 공개 서버가 없는 사내 API나 자체 데이터베이스는 MCP 서버로 감싸 Tool로 만듭니다. Tool의 이름·설명·입력 스키마로 인터페이스를 정하고, 프로젝트 .mcp.json에 실행 명령을 공유합니다.
• Capability vs Procedure: CLI·MCP는 "Claude가 무엇에 닿을 수 있는가" 를 결정하는 Capability Layer, Skill은 "그 도구를 어떤 순서·기준·형식으로 쓸지" 를 정의하는 Procedure Layer입니다. 결합하면 코드 리뷰 (gh CLI + code-review Skill)·UI 버그 리포트 (Claude in Chrome + ui-bug-report Skill) 같은 반복 워크플로우가 매번 같은 형식으로 나옵니다.

실행을 제어하는 도구

CLAUDE.md 지침은 AI가 읽고 판단하는 권고이므로 건너뛸 수 있습니다. Hooks와 Custom Agent가 이 한계를 보완합니다. Hook으로 권고를 강제하고, 대량 탐색은 Custom Agent로 별도 컨텍스트에 격리합니다.

• Hooks: CLAUDE.md 지침이 AI가 건너뛸 수 있는 권고라면, Hook은 Claude Code 런타임이 매번 강제로 실행하는 스크립트입니다. Event (언제) · Matcher (어떤 조건) · Handler (무엇을) 세 요소로 구성되고, 세 가지 타이밍 중에서 고릅니다. 실행 전 수정·차단 (PreToolUse), 실행 후 단일 파일 검증 (PostToolUse), 작업 완료 시 통합 검증 (Stop)
• Custom Agent: .claude/agents/ 에 정의한 전문 Subagent입니다. 핵심은 역할 분담이 아니라 컨텍스트 오염 방지입니다. 대량 탐색·테스트 로그 분석처럼 입력은 방대하지만 결론은 짧은 작업을 별도 컨텍스트에서 처리하고, 메인에는 요약만 돌아와 본 대화의 Context Window를 지킵니다.

이어서 배울 내용

Part 2에서 개별 도구를 모두 배웠습니다. Part 3에서는 먼저 Claude Code Desktop으로 작업 화면을 넓히고, 이 도구를 AI 협업 워크플로우로 연결해 배포까지 완성한 뒤 병렬 작업으로 확장합니다.