Claude Code 업데이트 심화 정리: Memory, Skills(번들 스킬), Remote Control, Ralph Loop 실전 운영

이번 글은 아래 5개 공식 링크를 기준으로 Claude Code의 핵심 업데이트를 “기능 소개"가 아니라 “운영 설계” 관점에서 다시 정리한 문서입니다.
특히 Memory, Skills, Remote Control, Ralph Loop를 각각 이해한 뒤, 마지막에 하나의 루프로 합치는 방법까지 다룹니다.
문서 확인 시점은 2026-03-02 입니다.

Sources

• https://code.claude.com/docs/ko/memory
• https://code.claude.com/docs/en/skills#bundled-skills
• https://code.claude.com/docs/en/remote-control
• https://claude.com/plugins/ralph-loop
• https://github.com/anthropics/claude-code/blob/main/plugins/ralph-wiggum/README.md

1) Memory: “지침"과 “학습"을 분리하는 계층 설계

Memory 문서의 핵심은 메모리를 한 종류로 보지 않는 것입니다.
Claude Code는 크게 아래 두 축을 함께 사용합니다.

• 지침형 메모리: CLAUDE.md 계열 (사용자/팀/조직이 규칙을 명시)
• 자동 메모리: Claude가 세션 중 학습한 내용을 저장하는 ~/.claude/projects/<project>/memory/ 계열

flowchart TD
  A["Memory 입력"] --> B["지침형 메모리
CLAUDE.md 계열"]
  A --> C["자동 메모리
MEMORY.md + 토픽 파일"]
  B --> D["세션 시작 시 로드"]
  C --> E["MEMORY.md 앞 200줄 로드"]
  E --> F["상세 토픽 파일은 필요 시 로드"]
  D --> G["작업 중 행동 규칙 형성"]
  F --> G

  classDef input fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
  classDef memory fill:#fff3e0,stroke:#ef6c00,color:#e65100
  classDef output fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
  class A input
  class B,C,D,E,F memory
  class G output

메모리 위치와 우선순위 핵심

문서 기준으로 메모리 레이어는 조직/프로젝트/사용자/로컬/자동 메모리로 분리됩니다.
실무에서 중요한 포인트는 아래입니다.

• 더 구체적인 지침이 더 넓은 지침보다 우선합니다.
• cwd 기준 상위 디렉토리의 CLAUDE.md를 재귀적으로 읽습니다.
• 하위 디렉토리의 CLAUDE.md는 시작 시 전부 로드하지 않고, 해당 하위 트리 파일을 읽을 때 지연 로드됩니다.

자동 메모리의 실제 동작

• 엔트리 파일: MEMORY.md (세션 시작 시 앞 200줄만 자동 로드)
• 상세 파일: debugging.md, api-conventions.md 같은 토픽 파일 (필요 시 읽기)
• 저장 위치: ~/.claude/projects/<project>/memory/
• git worktree는 별도 메모리 디렉토리를 가집니다.

제어 스위치

• /memory 명령으로 메모리 파일을 직접 열고 편집 가능
• autoMemoryEnabled 설정으로 사용자/프로젝트 단위 on/off
• CLAUDE_CODE_DISABLE_AUTO_MEMORY 환경 변수가 /memory 토글 및 settings보다 우선

# ~/.claude/settings.json
{ "autoMemoryEnabled": false }

# .claude/settings.json
{ "autoMemoryEnabled": false }

export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1

구조화 팁

Memory 문서에서 실전적으로 특히 중요한 부분은 아래 3개입니다.

1. .claude/rules/*.md로 규칙을 모듈화하고, 필요하면 YAML paths로 경로별 규칙을 건다.
2. @path/to/import로 규칙 파일을 분리하되, 임포트 깊이(최대 5 hops)를 의식한다.
3. 대형 리포는 “공통 규칙(상위) + 모듈 규칙(하위) + 자동 메모리(프로젝트 학습)” 3층 구조로 운영한다.

2) Skills: 프롬프트 자산을 “실행 가능한 단위"로 관리

Skills 문서의 핵심은 “명령어 확장"이 아니라 “Claude의 실행 정책 확장"입니다.
스킬은 SKILL.md와 frontmatter로 정의되고, 필요 시 자동 호출되거나 /skill-name으로 직접 호출됩니다.

flowchart LR
  A["사용자 요청"] --> B{"스킬 자동 호출 조건 충족?"}
  B -->|Yes| C["Skill description 기반 자동 로드"]
  B -->|No| D["직접 호출
/skill-name"]
  C --> E["SKILL.md 본문 실행"]
  D --> E
  E --> F["도구 실행 / 파일 읽기 / 서브에이전트"]

  classDef input fill:#e8eaf6,stroke:#3949ab,color:#1a237e
  classDef decision fill:#fff8e1,stroke:#ff8f00,color:#e65100
  classDef action fill:#e0f2f1,stroke:#00695c,color:#004d40
  class A input
  class B decision
  class C,D,E,F action

번들 스킬(Bundled skills)

문서에 명시된 기본 번들 스킬은 아래입니다.

• /simplify: 최근 변경 파일을 병렬 리뷰하고 개선 적용
• /batch <instruction>: 대규모 변경을 5~30개 단위로 분해, 승인 후 병렬 에이전트/워크트리 기반 실행
• /debug [description]: 현재 세션 디버그 로그 기반 문제 분석

추가로 Anthropic SDK import 시 자동 활성화되는 개발자 플랫폼 번들 스킬이 있다고 문서에 명시돼 있습니다.

스킬 저장 위치와 충돌 우선순위

• Enterprise
• Personal: ~/.claude/skills/<skill-name>/SKILL.md
• Project: .claude/skills/<skill-name>/SKILL.md
• Plugin: <plugin>/skills/<skill-name>/SKILL.md

우선순위는 enterprise > personal > project 입니다.
플러그인 스킬은 plugin-name:skill-name 네임스페이스를 사용해 충돌을 피합니다.

운영에 바로 쓰는 frontmatter 핵심

• disable-model-invocation: true: 모델 자동 호출 금지 (수동 실행 전용)
• user-invocable: false: / 메뉴에서 숨김, 모델 자동 호출 전용
• allowed-tools: 스킬 활성 시 무승인 사용 가능한 도구 범위
• context: fork + agent: 분리된 subagent에서 실행

flowchart TD
  A["Skill frontmatter"] --> B["disable-model-invocation"]
  A --> C["user-invocable"]
  A --> D["allowed-tools"]
  A --> E["context: fork + agent"]
  B --> F["수동 트리거 통제"]
  C --> G["UI 노출 통제"]
  D --> H["도구 권한 통제"]
  E --> I["격리 실행 통제"]

  classDef core fill:#f3e5f5,stroke:#6a1b9a,color:#4a148c
  classDef out fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
  class A,B,C,D,E core
  class F,G,H,I out

고급 패턴 2가지

1. !\command`구문으로 스킬 실행 전 동적 데이터 주입<br>예:gh pr diff` 결과를 프롬프트에 선반영
2. 스킬 설명 문자열 예산 관리
   문서 기준으로 스킬 설명은 컨텍스트 예산(동적 2%, fallback 16,000 chars) 내에서 로드

3) Remote Control: 로컬 실행을 유지한 채 멀티디바이스로 이어붙이기

Remote Control 문서 핵심은 “웹에서 조작"이 아니라 “로컬 세션을 원격에서 이어서 제어"입니다.
즉 실행 위치는 계속 내 머신이고, 브라우저/모바일은 그 세션의 창 역할을 합니다.

flowchart LR
  A["로컬 Claude Code 세션"] --> B["Outbound HTTPS only"]
  B --> C["Anthropic API 중계"]
  C --> D["claude.ai/code"]
  C --> E["Claude 모바일 앱"]
  D --> F["동일 세션 동기화"]
  E --> F

  classDef local fill:#e3f2fd,stroke:#1565c0,color:#0d47a1
  classDef net fill:#fff3e0,stroke:#ef6c00,color:#e65100
  classDef client fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
  class A local
  class B,C net
  class D,E,F client

시작 방법

• 새 원격 세션: claude remote-control
• 기존 세션 이어붙이기: /remote-control 또는 /rc
• URL/QR/세션 목록으로 다른 디바이스에서 접속

claude remote-control 에서만 아래 플래그 사용 가능:

• --verbose
• --sandbox / --no-sandbox

문서 기준 요구사항과 현재 상태

문서 상단에는 “research preview, Max/Pro” 표기가 있고, Requirements 섹션에는 “현재 Max 필요, Pro 곧 지원"이라고 명시되어 있습니다.
즉 같은 페이지 안에서도 안내 문구가 섹션별로 다를 수 있으므로, 실제 사용 전 계정 플랜에서 즉시 확인이 필요합니다.

추가 요구사항:

• /login 인증 필요
• 프로젝트 디렉토리에서 한 번 실행해 workspace trust 승인 필요
• API key 방식은 Remote Control에서 지원되지 않음

보안/네트워크 관점 핵심

• 인바운드 포트를 열지 않음
• 로컬 프로세스가 아웃바운드 HTTPS로 등록/폴링
• 트래픽은 TLS 위에서 전송
• 용도별 단기 credential 사용

제한사항

• Claude Code 인스턴스당 원격 세션 1개
• 터미널/프로세스 종료 시 세션 종료
• 약 10분 이상 네트워크 단절 시 timeout 후 프로세스 종료

4) Ralph Loop: Stop Hook 기반 반복 개선 루프

Ralph Loop 플러그인 페이지와 ralph-wiggum README가 공통으로 강조하는 포인트는 동일합니다.
한 번 실행한 프롬프트를 세션 내부에서 반복 재투입해, 실패를 다음 반복의 입력으로 쓰는 구조입니다.

flowchart TD
  A["/ralph-loop 실행"] --> B["Claude 작업 수행"]
  B --> C["종료 시도"]
  C --> D["Stop Hook가 종료 차단"]
  D --> E["동일 프롬프트 재주입"]
  E --> B
  B --> F{"완료 문자열 일치?"}
  F -->|Yes| G["루프 종료"]
  F -->|No| H{"max-iterations 도달?"}
  H -->|No| C
  H -->|Yes| I["안전 종료"]

  classDef run fill:#ede7f6,stroke:#5e35b1,color:#311b92
  classDef gate fill:#fff8e1,stroke:#ff8f00,color:#e65100
  classDef endNode fill:#e8f5e9,stroke:#2e7d32,color:#1b5e20
  class A,B,C,D,E run
  class F,H gate
  class G,I endNode

명령과 제약

• 시작: /ralph-loop "<prompt>" --max-iterations <n> --completion-promise "<text>"
• 중단: /cancel-ralph
• --completion-promise는 정확 문자열 매칭
• 다중 종료 조건을 completion-promise 하나로 표현하기 어렵기 때문에 --max-iterations를 항상 안전장치로 두는 것을 README가 권장

어떤 작업에 적합한가

적합:

• 성공 조건이 명확한 작업
• 테스트/린트 등 자동 검증 가능한 반복 개선 작업
• 그린필드 구현처럼 일정 시간 무인 반복이 가능한 작업

부적합:

• 인간 판단/디자인 결정이 핵심인 작업
• 성공 조건이 불명확한 작업
• 프로덕션 장애처럼 즉시 정밀 판단이 필요한 디버깅

플러그인 페이지 메타

• Anthropic verified 표기
• 작성 주체: Anthropic
• 설치 수 표기(확인 시점 2026-03-02 기준): 83,061 installs

5) 4개 기능을 한 루프로 묶는 실전 운영 패턴

실무에서는 아래 순서가 가장 안정적입니다.

1. Memory로 규칙/학습 축적 구조를 먼저 고정
2. Skills로 반복 작업 절차를 명령화
3. Ralph Loop로 자동 반복 개선 구동
4. Remote Control로 이동 중 관찰/개입

flowchart LR
  A["Memory 설계"] --> B["Skills 표준화"]
  B --> C["Ralph 반복 실행"]
  C --> D["Remote Control 관찰/개입"]
  D --> E["결과를 Memory/Skills에 환류"]
  E --> B

  classDef stage fill:#e0f7fa,stroke:#00838f,color:#006064
  class A,B,C,D,E stage

이 루프의 장점은 “한 번 잘한 작업"을 “다음에도 재현 가능한 작업"으로 바꾼다는 점입니다.
결국 핵심은 기능 사용법 자체보다, 실패와 개선 흔적을 구조화해 다음 실행에 자동 반영하는 운영 체계입니다.

Evidence Notes