Claude Code /loop, Hooks, Auto memory로 점검 자동화 루프 만들기

Technical Writer

2026년 3월 25일 · 약 13분

저는 앞선 글에서 Hooks로 Claude Code의 동작에 정책을 강제하는 방법과 Auto memory로 세션 간 맥락을 자동으로 이어가는 방법을 각각 다뤘습니다. 이번 글에서는 두 기능과 /loop를 연결해 자동화 루프를 구축하는 방법을 살펴보려 합니다. /loop는 정해진 간격으로 프롬프트를 반복 실행하는 기능입니다.

세 기능을 연결하면 주기적 점검, 정책 강제, 세션 간 학습을 하나의 루프로 구성할 수 있는데요. /loop이 주기적으로 점검을 트리거하면, Hooks가 점검 과정에서 발생하는 파일 수정·명령 실행·커밋에 정책을 강제하고요. Auto memory가 세션 중 발견한 설정 오류나 차단 이력과 같은 패턴을 기억해 다음 세션에도 해당 맥락을 제공하죠.

이 루프는 설정 파일 검증과 같은 주기적 확인이 필요한 작업에 적용할 수 있습니다. 예를 들어, 설정 파일을 주기적으로 검증하면서 debug 모드가 활성화된 상태의 커밋을 자동 차단하고, 다음 세션에서 이전에 발견한 문제를 기억해 정책을 적용하는 배포 후 점검 자동화 루프를 구축할 수 있습니다.

이 글에서는 Hooks, /loop, Auto memory를 조합한 점검 자동화 루프의 구조와 설계 방법, 유의 사항, 한계를 살펴보겠습니다.

점검 자동화 루프 구조

이 루프는 /loop이 점검을 트리거하고, Hooks가 그 과정에서 정책을 강제하며, Auto memory가 결과를 기억하는 흐름으로 동작합니다.

2026-03-25-claude-code-loop-0 | 인포그랩 GitLab

`/loop`: 주기적 트리거

Claude Code 세션에서 /loop + 프롬프트를 입력하면, Claude가 정해진 간격으로 프롬프트를 반복 실행합니다. 예를 들어, /loop 2m 설정 파일 상태를 확인해줘라고 입력하면, Claude가 2분마다 설정 파일 검증 스크립트를 실행하고 결과를 확인하죠. 이때 Claude는 파일을 읽고, 수정하고, 명령을 실행하는 등 여러 도구를 호출합니다.

Hooks: 도구 호출 시점 정책 강제

프로젝트의 .claude/settings.json에 설정한 Hooks가 Claude의 도구 호출에 개입합니다. PreToolUse Hook은 도구가 실행되기 직전에 동작해 위험한 명령이나 조건에 맞지 않는 커밋을 차단하죠. PostToolUse Hook은 도구 실행 직후에 동작해 파일 수정 도구가 실행될 때마다 검증 스크립트를 자동 실행합니다. /loop이 트리거한 점검 과정에서 Claude가 호출하는 모든 도구에 이러한 정책이 적용됩니다.

Auto memory: 세션 간 맥락 유지

Hooks가 정책을 강제하는 과정에서 Claude는 설정 오류나 차단 이력과 같은 맥락을 축적하는데요. Auto memory는 이 중 유용하다고 판단한 내용을 프로젝트별 MEMORY.md에 자동 기록합니다. 예를 들어, 특정 설정 필드가 누락되면 에러가 발생한다는 사실이나 debug 모드 관련 이슈가 반복된다는 패턴을 기록할 수 있죠. 다음 세션을 시작하면 이 기록이 자동으로 로딩돼 같은 맥락을 처음부터 설명할 필요 없이 이전 세션에서 축적한 맥락을 바탕으로 작업을 이어갈 수 있습니다.

설계 방법: 설정 파일 점검 루프 구축

지금부터 설정 파일 점검을 자동화하는 루프를 구축하겠습니다. 이 글에서는 실습 결과를 빠르게 확인하기 위해 /loop 간격을 2분으로 설정합니다. 실무에서는 작업 특성에 따라 10분 ~ 30분으로 조정하는 게 적절합니다.

1단계: `/loop`으로 주기적 점검 예약하기

이 단계에서는 설정 파일을 주기적으로 검증하는 점검 루프를 설정합니다.

Claude Code를 프로젝트 디렉터리에서 실행한 뒤 프롬프트를 입력합니다.
Claude가 2분 마다 validate-config.sh를 실행합니다.
실행 결과, 검증 스크립트가 설정 파일이 정상이면 “OK: config validation passed”, 문제가 있으면 경고나 에러를 출력합니다.

참고: 이 단계에서는 점검이 실행되지만 Claude가 문제를 해결하는 과정에서 위험한 명령을 실행하거나 검증되지 않은 설정을 커밋할 수 있습니다. 정책 강제가 없는 상태이기 때문입니다.

2단계: Hooks로 가드레일 추가하기

이 단계에서는 Hooks를 설정해 두 가지 정책을 강제합니다. 첫째, debug 모드가 활성화된 상태로 커밋하는 걸 차단합니다. 둘째, Claude가 파일을 수정할 때마다 설정 파일 검증을 자동 실행합니다.

.claude/settings.json에 다음 Hooks를 설정합니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "bash .claude/hooks/block-unsafe-commit.sh"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit|Update|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "bash scripts/validate-config.sh"
          }
        ]
      }
    ]
  }
}

PostToolUse Hook의 매처를 Write|Edit|Update|MultiEdit로 설정한 이유는 Claude Code의 파일 수정 도구에 Write, Edit, MultiEdit 등 여러 이름이 있고, 버전에 따라 다른 도구명이 사용될 수 있기 때문입니다. 매처가 이를 폭넓게 포함해야 파일 수정 시 검증이 누락되지 않습니다.

PreToolUse Hook이 실행하는 .claude/hooks/block-unsafe-commit.sh의 내용은 다음과 같습니다.

#!/bin/bash
COMMAND=$(cat | jq -r '.tool_input.command')

# git commit 또는 git push 명령인지 확인 (-C 등 옵션이 포함된 경우도 탐지)
if echo "$COMMAND" | grep -qE "git\b.*\b(commit|push)\b"; then
  # config/app.yaml에 debug: true가 남아있는지 확인
  if grep -q "debug: true" config/app.yaml 2>/dev/null; then
    jq -n '{
      hookSpecificOutput: {
        hookEventName: "PreToolUse",
        permissionDecision: "deny",
        permissionDecisionReason: "debug mode가 활성화된 상태에서는 커밋할 수 없습니다. config/app.yaml에서 debug: false로 변경한 뒤 다시 시도하세요."
      }
    }'
    exit 0
  fi
fi

exit 0

이 Hook은 Claude가 git commit이나 git push를 시도할 때, 설정 파일에 debug: true가 남아있으면 커밋 자체를 차단합니다. grep 패턴에 git\b.*\b(commit|push)\b를 사용한 이유는 Claude가 git commit을 단독으로 실행하지 않고 git -C /path commit처럼 옵션을 포함해 실행할 때가 있기 때문입니다. git과 commit 사이에 어떤 옵션이 들어와도 탐지할 수 있도록 .*로 연결했습니다.

팀의 정책에 따라 프로덕션 설정 파일의 권한 변경(chmod 777 등)이나 환경변수 파일(.env) 수정 같은 패턴도 같은 방식으로 추가할 수 있습니다.

PostToolUse Hook이 실행하는 scripts/validate-config.sh의 내용은 다음과 같습니다.

#!/bin/bash

CONFIG_FILE="config/app.yaml"

if [ ! -f "$CONFIG_FILE" ]; then
  echo "ERROR: $CONFIG_FILE not found" >&2
  exit 2
fi

ERROR=0

# debug 모드 확인
if grep -q "debug: true" "$CONFIG_FILE"; then
  echo "WARNING: debug mode is enabled in $CONFIG_FILE" >&2
  ERROR=1
fi

# port 필드 확인
if ! grep -q "port:" "$CONFIG_FILE"; then
  echo "ERROR: port field is missing in $CONFIG_FILE" >&2
  ERROR=1
fi

if [ $ERROR -eq 1 ]; then
  exit 2
fi

echo "OK: config validation passed"
exit 0

이 스크립트는 경고와 에러 메시지를 >&2로 stderr에 출력하고 exit 2로 종료합니다. Claude Code는 Hook의 exit code 2를 blocking error로 인식해 해당 메시지를 화면에 표시하고 Claude에게도 전달합니다. 정상일 때는 exit 0으로 종료하며, 이때 출력은 verbose 모드(Ctrl+O)에서만 확인할 수 있습니다.

동작 확인

Claude에게 “config/app.yaml에서 debug를 true로 바꿔줘”라고 요청합니다.
Claude가 파일을 수정하면, PostToolUse Hook이 자동으로 validate-config.sh를 실행합니다. 검증 스크립트가 문제를 발견하면 경고 메시지를 stderr로 출력하고 exit code 2로 종료하는데요. Claude Code는 이를 blocking error로 인식해 “WARNING - debug mode is enabled in config/app.yaml”를 화면에 표시하고 Claude에게도 전달합니다.
Claude에게 “변경 사항을 커밋해줘”라고 요청합니다.
PreToolUse Hook이 config/app.yaml에서 debug:true를 탐지하고 커밋을 차단합니다. Claude는 차단 사유를 확인한 뒤 debug: false로 수정하는 대안을 제안합니다.

참고: 이 단계에서는 /loop이 트리거한 점검뿐만 아니라 Claude의 모든 파일 수정과 명령 실행에 정책이 강제됩니다. 1단계에서 빠져 있던 가드레일이 추가된 상태입니다.

3단계: Auto memory로 세션 간 학습 연결하기

2단계까지 작업한 세션에서는 Claude가 설정 파일의 문제를 발견하고 수정한 이력이 쌓여 있습니다. 예를 들어, “debug: true가 문제였고, port 필드가 누락되면 에러가 난다”는 맥락이 대화에 남아있죠. Auto memory는 이 맥락 중 Claude가 유용하다고 판단한 내용을 자동으로 기록합니다.

세션 간 연속성 확인

현재 세션을 종료합니다.
같은 프로젝트 디렉터리에서 Claude Code를 다시 실행합니다.
Claude에게 “이 프로젝트의 설정 파일에서 주의할 점이 뭐야?”라고 물어봅니다.
Claude가 이전 세션에서 축적된 맥락을 바탕으로 답변하는지 확인합니다. Auto memory가 정상적으로 동작했다면, 이전 세션에서 발견한 문제를 언급할 수 있습니다.

Auto memory 상태 확인

현재 세션에서 /memory를 입력합니다.
Auto memory 활성화 상태와 저장된 메모리 파일 경로를 확인합니다.
~/.claude/projects/<project>/memory/MEMORY.md 파일이 생성됐는지 확인합니다. Auto memory가 기록할 내용이 있다고 판단했다면 설정 관련 패턴이 기록돼 있습니다. 세션이 짧으면 파일이 아직 생성되지 않았을 수 있는데 이는 Auto memory가 기록할 만큼 충분한 패턴이 축적되지 않았기 때문입니다.

참고: Auto memory는 Claude가 유용하다고 판단한 내용만 저장해 이전 세션의 모든 내용이 기록되는 건 아닙니다. 세션이 짧으면 MEMORY.md에 아무것도 기록되지 않을 수 있습니다. 이때 Claude가 이전 세션의 맥락을 언급해도 Auto memory가 아니라 프로젝트 파일이나 git 이력을 직접 읽어서 판단한 것일 수 있습니다. MEMORY.md에 실제로 어떤 내용이 저장됐는지 /memory 명령이나 파일을 직접 열어 확인해야 합니다.

새 세션에서 루프 재개

세 기능 중 Hooks 설정(settings.json)과 Auto memory(MEMORY.md)는 파일로 저장되므로 새 세션에서도 자동으로 유지됩니다. 그러나 /loop은 세션 범위에서만 동작해 새 세션을 시작할 때마다 다시 설정해야 합니다.

새 세션에서 /loop을 다시 설정합니다.
Hooks는 settings.json에 이미 설정돼 별도 작업 없이 동작합니다.
Auto memory가 이전 세션의 맥락을 불러온 상태에서 /loop이 트리거한 점검에 Hooks가 정책을 강제하는 전체 루프가 다시 동작합니다.

참고: 세션 시작 시 /loop 설정을 잊지 않으려면, 프로젝트의 CLAUDE.md에 “새 세션 시작 시 /loop 2m validate-config.sh를 실행해 설정 파일 상태를 확인해줘를 실행할 것”이라고 기록합니다. 그러면 세션 시작 시 Claude가 해당 지침을 참고할 수 있습니다. 다만, 자동 실행되는 건 아니라서 사용자가 직접 /loop을 다시 입력해야 합니다.

완성된 루프

/loop이 주기적으로 설정 파일 점검을 트리거합니다.
점검 과정에서 Claude가 파일을 수정하면 PostToolUse Hook이 자동으로 설정 파일 검증을 실행합니다.
Claude가 debug 모드가 활성화된 상태로 커밋을 시도하면, PreToolUse Hook이 차단합니다.
세션을 종료하고 다시 시작하면, Hooks 설정과 Auto memory는 자동으로 유지됩니다. /loop만 다시 설정하면 전체 루프가 재개됩니다.

유의 사항과 한계

점검 자동화 루프를 설계할 때 알아야 할 주의 사항과 이 루프의 구조적 한계는 다음과 같습니다.

설계 시 주의할 점

/loop 간격에 따른 토큰 소비 누적

/loop이 실행될 때마다 Claude가 프롬프트를 처리하면서 토큰이 소비됩니다. 예를 들어, 10분 간격으로 8시간 실행하면 48회 실행되는데요. 실행될 때마다 파일 읽기, 스크립트 실행, 결과 분석에 토큰이 사용되죠. API 과금 사용자라면 토큰 사용 비용이 누적될 수 있고, 구독 플랜 사용자라면 월간 토큰 사용량 한도를 예상보다 빨리 소진할 수 있습니다. 이 글의 실습에서는 결과를 신속히 확인하고자 2분 간격을 설정했지만 실무에서는 점검 대상의 변경 빈도에 맞춰 10 ~ 30분으로 조정하는 걸 권장합니다.
자동화 적정 범위 미고려 시 위험 작업 실행

이 글의 실습과 같이 설정 파일 검증, 조건에 맞지 않는 커밋 차단은 자동화하기에 적합합니다. 검증은 상태를 확인만 하고, 차단은 행동을 막을 뿐 시스템을 변경하지 않아 오작동해도 피해가 없기 때문이죠. 그러나 데이터베이스 마이그레이션이나 프로덕션 배포처럼 되돌리기 어려운 작업은 문제가 생기면 피해 범위가 커서 사람이 직접 판단하는 게 안전합니다.

구조적 한계

/loop 스케줄의 세션 종속

/loop으로 설정한 스케줄은 세션이 유지되는 동안만 동작합니다. 세션을 종료하면 해당 스케줄이 삭제되고, 새 세션을 시작해도 이전에 설정한 /loop 스케줄은 복원되지 않고요. 세션을 유지해도 /loop 스케줄은 생성 후 7일이 지나면 자동 만료됩니다. 세션 종료와 무관하게 주기적 점검 자동화가 필요하면 GitHub Actions의 schedule trigger나 별도 cron job으로 Claude Code를 비대화식으로 실행할 수 있습니다. 이때 Hooks는 설정 파일이 리포지터리에 포함돼 정상 동작하지만 Auto memory는 실행 환경에 따라 세션 기록을 저장하지 않을 수 있습니다.
Auto memory의 선택적 기록

Auto memory는 Claude가 유용하다고 판단한 맥락만 선택적으로 저장합니다. 예를 들어, Hook이 위험한 커밋을 차단한 이력이 있어도 Auto memory가 반드시 이를 기록한다는 보장은 없죠. 중요한 이력을 확실히 남기려면, Hook 스크립트 안에서 MEMORY.md에 직접 기록하는 방식으로 보완할 수 있습니다.

맺음말

지금까지 /loop, Hooks, Auto memory를 조합한 점검 자동화 루프의 구조와 설계 방법, 유의 사항, 한계를 살펴봤습니다. 이 글의 요점은 다음과 같은데요.

/loop이 주기적으로 점검을 트리거하고, Hooks가 그 과정에서 파일 수정·명령 실행·커밋에 정책을 강제하며, Auto memory가 발견한 패턴을 기억해 다음 세션에도 해당 맥락을 제공하는 자동화 루프를 구성할 수 있습니다.
설정 파일 점검 루프는 3단계로 구축합니다. 먼저 /loop으로 주기적 점검을 예약하고, Hooks로 위험한 커밋 차단과 파일 수정 시 자동 검증을 추가한 뒤, Auto memory로 세션 간 맥락을 이어갑니다. Hooks 설정과 Auto memory는 새 세션에서도 유지되지만, /loop은 매 세션 시작 시 다시 설정해야 합니다.
/loop 간격이 짧으면 토큰 소비가 누적돼 실무에서는 10 ~ 30분으로 조정하는 것을 권장합니다. 자동화 범위는 설정 파일 검증이나 커밋 차단과 같은 작업에 한정하고, 데이터베이스 마이그레이션이나 프로덕션 배포 같은 작업은 사람이 판단하는 게 안전합니다.
/loop 스케줄은 세션이 유지되는 동안만 동작하며 세션 종료 시 삭제되고, 생성 후 7일이 지나면 자동 만료됩니다. Auto memory는 Claude가 유용하다고 판단한 맥락만 선택적으로 저장해 중요한 이력을 확실히 남기려면 Hook 스크립트에서 MEMORY.md에 직접 기록하는 방식으로 보완할 수 있습니다.

참고 자료

“Automate workflows with hooks”, Anthropic, https://code.claude.com/docs/en/hooks-guide
“Hooks reference”, Anthropic, https://code.claude.com/docs/en/hooks
“Run prompts on a schedule”, Anthropic, https://code.claude.com/docs/en/scheduled-tasks
“How Claude remembers your project”, Anthropic, https://code.claude.com/docs/en/memory
“Extend Claude Code”, Anthropic, https://code.claude.com/docs/en/features-overview
“How Claude Code works”, Anthropic, https://code.claude.com/docs/en/how-claude-code-works
“Best Practices for Claude Code”, Anthropic, https://code.claude.com/docs/en/best-practices

우리 회사에 딱 맞는 DevSecOps 관행과 프레임워크를 찾고 계시나요? DevOps 전문가, 인포그랩과 상담하세요!

점검 자동화 루프 구조​

/loop: 주기적 트리거​

Hooks: 도구 호출 시점 정책 강제​

Auto memory: 세션 간 맥락 유지​

설계 방법: 설정 파일 점검 루프 구축​

1단계: /loop으로 주기적 점검 예약하기​

2단계: Hooks로 가드레일 추가하기​

3단계: Auto memory로 세션 간 학습 연결하기​

유의 사항과 한계​

설계 시 주의할 점​

구조적 한계​

맺음말​

참고 자료​