2장. Claude 작업 구조를 이해하는 기본 개념

2.1 용어를 잘못 이해하면 전체가 꼬인다

Claude 관련 글이 어렵게 느껴지는 이유는 단어 수가 아니다. 서로 다른 층위가 한꺼번에 섞여서다. 먼저 큰 갈래부터 잡는다.

다섯 가지 핵심 용어

이름을 외우기 전에 지금 필요한 것이 대화인지, 배경 자료를 오래 들고 가는 작업인지, 초안 위임인지, 구현과 검증인지부터 묻는 편이 낫다.

네 가지 핵심 틀

1장에서는 하네스를 "Claude가 일하는 작업장"으로 잡았다. 여기서 경계를 더 정확히 고정한다.

작업면은 "어디서 시작하느냐", 하네스는 "어떤 작업장에서 움직이느냐", 운영층은 "그걸 계속 굴릴 수 있느냐", 시스템은 "이 모두를 묶은 전체"다.

사무실 비유로 바꾸면 선명해진다. 작업면은 책상, 하네스는 서랍과 결재선과 체크리스트, 운영층은 관리실, 시스템은 사무실 전체다.

2.2 가장 중요한 분류: 지식, 도구, 패키지, 통제

Claude 생태계는 네 축으로 나누면 선명해진다.

작업장 비유로 보면 간단하다. 지식은 매뉴얼 선반, 도구는 책상 위 장비, 패키지는 온보딩 상자, 통제는 잠금장치와 결재선이다.

같은 요청을 레이어로 나누면

Claude Code 설정 scope

공식 settings 문서(2026년 3월 23일 기준)는 우선순위를 이렇게 설명한다.

조직이 위에서 잠근 규칙은 개인이나 저장소 설정으로 덮지 못한다. 이 한 줄만 알아도 "왜 내 설정이 안 먹지?" 같은 혼란이 줄어든다.

토큰을 초반부터 이해해야 하는 이유

토큰은 모델이 읽고 쓰는 글 조각의 계산 단위다. 사용자가 한 줄을 입력해도 실제로는 그 한 줄만 보내지지 않는다. 현재 질문, 직전 대화, 읽은 파일, CLAUDE.md, 규칙, 도구 결과, 방금 만든 출력까지 한꺼번에 문맥 창으로 들어간다.

2.3 왜 Claude 활용에서 "파일"이 기본 단위가 되는가

처음 접하면 흔히 이렇게 생각한다.

짧은 작업은 그렇다. 하지만 Claude Code와 Cowork가 강해지는 지점은 대화를 오래 이어 가는 능력이 아니다. 작업 상태를 파일로 남기고 다시 읽는 구조에 있다.

마크다운 파일은 형식 문법이 아니라 사람과 Claude가 함께 보는 공유 메모에 가깝다.

왜 하필 .md 파일인가

.md만 가능한 건 아니다. 다만 사람이 읽기 쉽고, Claude가 읽기 쉽고, 버전 관리가 쉽다. PDF, DOCX, PPTX, XLSX도 충분히 쓸 수 있다. 규칙, 템플릿, 브리프, 운영 메모, 계획, handoff처럼 자주 바뀌고 자주 읽는 운영 파일에 .md가 가장 잘 맞는다.

2.4 왜 "폴더"가 파일만큼 중요한가

파일이 기억의 단위라면 폴더는 역할의 단위다. 가장 흔한 실수는 모든 자료를 한 폴더에 몰아넣고 Claude에게 정리를 맡기는 일이다.

2.5 왜 템플릿을 따로 둬야 하는가

템플릿은 예쁜 형식을 재사용하려고 두는 게 아니다. 산출물 품질의 기준을 따로 관리하기 위해서다.

예를 들어 weekly-brief-template.md가 있으면 매번 "상단 요약, 중간 경쟁사 변화, 하단 액션"을 설명할 필요가 없다. Claude는 구조를 템플릿에서 읽고 이번 주 데이터만 새로 채운다.

템플릿과 예시는 어떻게 다른가

파일명 규칙은 왜 필요한가

생성형 작업은 수정본이 빠르게 늘어난다. 이름이 제각각이면 최신본을 찾기 어렵다.

좋은 파일명은 적어도 세 가지를 담는다. 프로젝트, 산출물 종류, 버전이다. 형식이 YYYY-MM-DD_topic_type.md든 client_project_v2.md든 팀이 정한 규칙이면 충분하다. 중요한 건 가장 좋은 형식이 아니라 일관성이다.

2.6 초보자가 가장 먼저 알아야 할 파일 8종

초보자에게 필요한 파일은 생각보다 적다.

초보자용 시작 세트 구조

my-workspace/
├── ABOUT-ME/
│   ├── about-me.md
│   ├── working-rules.md
│   └── brand-voice.md
├── PROJECTS/
│   └── current-project/
│       ├── brief.md
│       └── glossary.md
├── TEMPLATES/
│   └── output-template.md
└── OUTPUTS/

"무엇을 읽어야 하는지"와 "무엇을 만들어야 하는지"가 분명해진다. 초보자는 새 파일을 많이 만들기보다 같은 구조를 반복해 쓰는 편이 빠르게 익숙해진다.

2.7 Skill, Plugin, MCP의 차이

초보자가 가장 많이 헷갈리는 조합이다. 차이만 고정한다.

실무 조합 순서는 보통 이렇다.

한 줄로 줄이면 Skill은 하는 법, MCP는 닿는 길, Plugin은 묶어서 배포하는 상자다.

예를 들어 주간 보고서를 만든다면 Skill은 조사와 작성 순서를 정하고, MCP나 Connector는 Notion·Drive·웹 검색에 닿게 하고, Plugin은 이 구성을 팀에 설치한다.

초보자를 위한 한 줄 판단법

"좋아 보이는 플러그인"부터 고르기보다 문제 유형을 먼저 나누면 덜 헤맨다.

2.8 Connector와 MCP는 같은가

둘은 닮았지만 같은 말은 아니다. 둘 다 외부 도구에 연결하지만 사용자 경험의 층이 다르다.

실무에서는 이렇게 나눈다.

Connector 내부 구분 (2026년 3월 공식 도움말 기준)

2.9 Hook이 왜 중요한가

Hook은 초보자에게 조금 늦게 익숙해지지만 생산성을 빠르게 끌어올리는 장치다. 중요한 규칙을 모델의 기억에만 맡기지 않고 시스템 수준에서 자동으로 건다.

2026년 3월 기준 Claude Code 공식 hooks 문서는 hooks를 단순 shell command로만 설명하지 않는다. command hook뿐 아니라 prompt-based hook, agent-based hook, HTTP hook까지 다룬다.

가장 작은 hook 예시 (PreToolUse)

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": ".claude/hooks/block-rm.sh"
          }
        ]
      }
    ]
  }
}

위험한 Bash 명령을 실행하기 전에 차단하는 가장 단순한 패턴이다. 핵심은 완벽한 자동화가 아니다. 사람이 자주 놓치는 금지선을 시스템 쪽으로 끌어내리는 것이다. 최신 문서에는 HTTP hook allowlist나 managed-only hook 같은 조직 운영용 옵션도 있다.

2.10 Agent, Subagent, Agent Team은 무엇이 다른가

세 단어 모두 "여러 AI가 같이 일한다"는 인상만 남기기 쉬워 뭉뚱그려진다. 실제 구조는 다르다.

agentic vs agent

Subagent와 Agent Team

왜 지금 에이전트가 나왔나

단순하게 정리하면 머리가 좋아지고, 더 오래 생각할 수 있게 되고, 손이 생겼기 때문이다.

에이전트는 "더 똑똑한 챗봇"이 아니다. 생각하는 시간과 손이 붙은 LLM이 실제 업무 흐름을 만나면서 나온 형태다.

LLM OS라는 말

운영체제 커널을 모델로 바꾼다는 뜻으로 이해하면 과하다. 안드레이 카파시(Andrej Karpathy)가 말해 온 두 가지 비유를 푼 표현에 가깝다. 하나는 GPT를 자연어 프로그램을 실행하는 범용 컴퓨터로 본 관점, 다른 하나는 LLM을 초기 운영체제에 비유한 관점이다.

핵심은 모델 하나가 모든 것을 안다는 뜻이 아니다. 모델 주변에 파일, 규칙, 기억, 도구, 승인선이 새로운 작업 운영층처럼 붙는다는 데 있다.

실무적으로는 네 층을 같이 떠올리면 감이 온다.

Software 3.0이라는 말도 같은 맥락이다. 전통 코드와 모델 가중치만이 아니라 자연어 자체가 작업 지시와 조합의 인터페이스가 되고 있다.

2.11 Remote Control, Channels, Scheduled Tasks의 차이

셋 다 "책상 앞에 없어도 Claude가 움직인다"는 인상을 준다. 하지만 출발 버튼을 누르는 주체가 다르다.

Scheduled Tasks는 제품면마다 구현이 다르다

Claude Code on the web은 다른 상자다

2.12 Context Engineering이 Prompt Engineering보다 더 중요해진 이유

과거의 LLM 활용은 "프롬프트를 어떻게 쓰느냐"가 중심이었다. 지금은 "Claude가 읽게 될 전체 시스템 상태를 어떻게 배치하느냐" 가 더 중요하다.

Context Engineering이 다루는 것은 이런 것들이다. 추상 이론이 아니라 파일, 규칙, 도구 상태를 어떻게 배치하느냐의 문제다.

같은 버그 수정도 세 층으로 나누면

2.13 Harness Engineering이란 무엇인가

Harness에는 시스템 프롬프트와 프로젝트 규칙, 도구 목록과 MCP 서버 정의, Hook과 권한 정책, 세션 재개와 압축, handoff 정책, 테스트와 검증, 로그와 알림, worktree와 tmux, 원격 제어와 채널 연결이 들어간다. 프롬프트를 더 영리하게 쓰는 기술이 아니라 모델이 일하는 작업장을 설계하는 기술이다.

초보자는 아래만 챙겨도 하네스를 만들기 시작한 셈이다.

1. CLAUDE.md에 기본 규칙 적기

   프로젝트 계약을 텍스트로 고정한다

2. settings.json에 허용/차단 적기

   도구 권한 경계를 만든다

3. plan.md로 큰 작업 쪼개기

   탐색과 실행을 분리한다

4. hook으로 자동화

   테스트나 포맷을 자동으로 건다

5. handoff.md로 종료 상태 남기기

   다음 세션이 이어받을 단서

하네스는 거창한 프레임워크가 아니다. Claude가 매번 같은 작업장에서 움직이게 만드는 최소 장치 모음이다.

2.14 Plan Mode, AskUserQuestion, Approval의 역할

아래 세 표현은 2026년 3월 23일 기준 Anthropic 전체의 단일 공식 브랜드 명칭이 아니라, agentic workflow를 설명할 때 쓰는 실무형 약칭에 가깝다.

언제 쓰는가

2.15 "OpenClaw처럼 쓴다"는 말의 의미

사용자가 말하는 "OpenClaw처럼"은 특정 제품의 모든 기능을 복제한다는 뜻이 아니다. 여러 세션과 역할을 병렬로 운용하고, 장기 실행과 상태 지속을 중시하며, 채널·원격 제어·예약·메모리·외부 도구 연결을 함께 묶는 운영 성향을 뜻한다. "계속 켜져 있고 이어받을 수 있는 작업 시스템"이라는 목표에 가깝다.

OpenClaw 공식 문서는 이를 self-hosted gateway로 설명한다. Gateway 하나가 세션, 라우팅, 채널 연결의 기준점이 되고, WhatsApp·Telegram·Discord·iMessage 같은 메시징 채널과 cron jobs, heartbeat, remote access, browser control, workspace/local/bundled skills, multi-agent routing을 같은 운영면에서 다룬다. 메시징 앱, 스케줄러, 세션 관리자, 로컬 도구, 에이전트 라우터가 묶인 개인용 에이전트 운영면이다.

"OpenClaw처럼"이 원하는 다섯 가지

Claude에서 유사한 조합

Claude Code 위에 CLAUDE.md, hooks, subagents나 agent teams를 얹고, MCP와 plugins, skills를 연결하고, Remote Control·Channels·Scheduled Tasks·Claude Code on the web을 상황별로 나눠 쓰고, Cowork와 persistent thread, connector와 plugin 조합을 함께 쓰는 그림이다.

중요한 차이

"OpenClaw처럼"은 특정 브랜드 기능보다 "항상 켜져 있고 스스로 이어가는 작업 시스템"이라는 운영 목표에 가깝다. Claude 쪽에서는 그 목표를 더 잘게 쪼갠 제품 표면을 조합해 구현한다.

2.16 초보자가 가장 자주 하는 오해 12가지

초보자 오해는 결국 한 방향으로 모인다. "모델만 더 좋은 걸로 바꾸면 워크플로까지 좋아질 것" 이라는 기대다.

공식 도움말 기준으로 Cowork 기록은 Audit Logs, Compliance API, Data Exports에 잡히지 않으며 regulated workload(규제 대상 업무)에 쓰지 말아야 한다. 원격 이어받기는 데스크톱 작업을 계속 조향하는 기능으로 이해하는 편이 맞다. 초반에는 "더 똑똑한 모델만 찾으면 된다"는 기대를 내려놓는 편이 낫다.

2.17 이 장의 실전 요약

이 장을 한꺼번에 다 기억할 필요는 없다. 네 가지만 남기면 이후 장들이 훨씬 쉬워진다.

2.18 장 끝 참고 출처

공식

• Claude Help Center: What are Skills?
• Claude Code Docs: plugins, skills, channels, scheduled tasks, agent teams
• Claude Help Center release notes

커뮤니티

• 공개 커뮤니티 자료 중 .claude/, hooks, skills, memory, multi-session 운영 글