Claude Architect · 강의

코드 생성 및 개발자 생산성

CLAUDE.md, 계획 모드, 기본 제공 도구 및 조사를 다룹니다

코드 생성 및 개발자 생산성은(는) CoddyKit의 무료 Claude Architect 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 Claude Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

Scenario 4: Developer Productivity

This lesson maps to Scenario 4 — Developer Productivity, one of the eight exam scenarios. The architect's job here is to make Claude Code an effective teammate inside a real repository: investigating unfamiliar code, planning changes safely, and persisting team conventions.

Three pillars carry most of the exam weight in this scenario:

CLAUDE.md — durable, shared project memory.
Plan mode — explore and propose before editing.
Built-in tools + incremental investigation — Glob, Grep, Read, Write, Edit, Bash used in a disciplined loop.

Get these decisions right and you'll handle most D3 (Config & Workflows) questions.

The CLAUDE.md Hierarchy

CLAUDE.md is persistent context loaded automatically into every session. There are three scopes, and choosing the right one is a frequent exam decision:

User-level ~/.claude/CLAUDE.md — personal preferences. NOT shared via VCS, so new teammates never see it.
Project-level ./CLAUDE.md or .claude/CLAUDE.md — committed to the repo and shared with the whole team.
Directory-level — scoped to a subtree, loaded when working in that folder.

Rule of thumb: anything every contributor must follow belongs in the project-level file. Putting team conventions only in your user-level file is a classic trap answer.

# Project memory — committed to VCS, shared with the team
# ./CLAUDE.md

## Build
- `yarn build` then run `dist/main.js`

## Conventions
- Use absolute imports from `src/`
- All API errors return structured `{ code, message }`
- Never commit secrets; read from env vars

Modularizing CLAUDE.md with @imports

A monolithic CLAUDE.md grows unwieldy and burns context tokens on every turn. Two mechanisms keep it lean:

@path imports — pull in modular files, e.g. @./standards/coding-style.md, so shared standards live in their own versioned files.
.claude/rules/ files — each carries YAML frontmatter with a paths glob, and loads only when you edit matching files. This saves context versus stuffing everything into one always-loaded CLAUDE.md.

Use rules for narrowly-scoped guidance (e.g. test conventions) that is irrelevant most of the time.

---
# .claude/rules/testing.md
paths:
  - "**/*.test.ts"
  - "**/*.spec.ts"
---

# Loaded ONLY when editing test files
- Use the existing `makeTestClient()` helper
- One assertion concern per `it(...)` block
- Never mock the database; use the in-memory fixture

Editing Memory: /memory and /compact

Two slash commands manage long-lived context:

/memory edits CLAUDE.md directly and persists across sessions — use it to capture a hard-won convention so it's enforced next time.
/compact compresses the current conversation to free context window. Beware: progressive summarization makes numbers, percentages, and dates vague. If exact values matter, keep them verbatim outside the summary rather than relying on /compact.

The exam likes to contrast durable memory (CLAUDE.md) with transient compression (/compact) — they solve different problems.

# Persist a convention into CLAUDE.md (survives future sessions)
/memory

# Compress the running conversation to reclaim context window
/compact

Plan Mode: Explore Before You Edit

Plan mode lets Claude explore the codebase and propose an approach that you approve before any edits land. Reach for it when:

The change is large or touches many files.
There are multiple viable approaches to weigh.
An architectural decision is involved.
You want safe exploration of unfamiliar code first.

For a single-file fix or a clear stack trace, skip plan mode and go straight to direct execution — planning overhead there is wasted. Matching mode to task size is the core decision this scenario tests.

Isolating Discovery with the Explore Subagent

Investigation produces a lot of verbose output — file dumps, search hits, traces — that can crowd the main context window. The Explore subagent isolates that discovery work, returning a distilled summary instead of raw noise.

This is the same principle as a Skill with context: fork: run the messy, token-heavy part in an isolated context so the main session stays focused. Pair plan mode with an explore step for big, unfamiliar changes.

---
# .claude/skills/audit-deps.md
name: audit-deps
description: Scan the repo for outdated/vulnerable dependencies
context: fork          # isolate verbose scan output
allowed-tools: [Bash, Grep, Read]
argument-hint: "[package-name]"
---

Run the dependency audit and report only actionable findings.

The Built-in Tool Set

Claude Code ships a focused set of built-in tools. Knowing what each is FOR is exam-critical:

Glob — find files by pattern, e.g. **/*.test.tsx.
Grep — search file contents.
Read — load a file into context.
Write — create a file.
Edit — a precise, unique-match change.
Bash — run shell commands.

Glob finds files by name/pattern; Grep finds files by what's inside them. Mixing those two up is a common distractor.

# Glob: locate files by pattern
**/*.service.ts

# Grep: search contents across the repo
grep -rn "process_refund" src/

# Bash: run the test suite
yarn test --runInBand

Edit vs Read+Write

Edit performs a precise change by matching a unique string in the file. If the target string is not unique, the edit fails — that's a safety feature, not a bug.

The correct fallback is to Read the file, then Write the full corrected version (or expand the match with more surrounding context to make it unique). Don't force ambiguous edits; that risks changing the wrong occurrence.

Edit is for surgical, unambiguous changes; Read+Write is for broader or ambiguous rewrites.

# Pseudocode of the decision
# 1) Try a unique-match Edit
#    old_string must appear EXACTLY once in the file
# 2) If the match is not unique -> Edit fails
# 3) Fallback: Read the whole file, then Write the corrected version
#    (or add more surrounding lines to old_string to disambiguate)

Incremental Investigation

The exam rewards a disciplined investigation loop rather than dumping the whole repo into context. The canonical pattern:

Grep the entry points (where does this feature start?).
Read the relevant files you found.
Grep for usages of the symbols you discovered.
Read the consumers to understand impact.

This narrows scope step by step and avoids the lost-in-the-middle problem of over-stuffed context. Trim verbose tool output to the relevant fields as you go.

# 1) Find the entry point
grep -rn "router.post('/refund'" src/

# 2) Read the handler file (Read tool)
# 3) Grep usages of the function it calls
grep -rn "processRefund(" src/

# 4) Read each consumer to assess blast radius

Extending Reach with MCP

Built-in tools cover the local filesystem and shell. To reach external systems — a GitHub repo, a database, an issue tracker — connect an MCP server.

Server primitives: Tools (actions), Resources (read-only data like schemas/catalogs), Prompts (templates).
Scope: project .mcp.json (shared in VCS) vs user ~/.claude.json (personal).
Secrets go through env vars like ${GITHUB_TOKEN} — never commit tokens.
Prefer a maintained community MCP server over building a custom one for standard integrations.

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
    }
  }
}

Commands and Skills

Reusable workflows live in two places. .claude/commands/ is the legacy form; .claude/skills/ is the current one. Both follow the same scoping rule:

Project scope (in the repo) — shared with the team via VCS.
User scope (~/.claude/) — personal, not shared.

Skill frontmatter gives you real control: context: fork to isolate verbose output, allowed-tools to restrict capability (least privilege), and argument-hint to document inputs. Package a recurring investigation as a project-scoped skill so the whole team runs it consistently.

---
# .claude/skills/triage-bug.md  (project scope -> shared via VCS)
name: triage-bug
description: Reproduce a bug, locate root cause via incremental investigation
context: fork
allowed-tools: [Grep, Read, Bash]
argument-hint: "<issue-id or stack trace>"
---

Grep entry points, Read suspects, Grep usages, then summarize root cause.

Quick Check: Choosing Your Approach

A scenario question on configuring Claude Code for a developer-productivity workflow.

Recap: Developer Productivity Essentials

Key takeaways for Scenario 4:

CLAUDE.md scope: project-level (VCS-shared) for team rules; user-level is personal and unshared; directory-level for subtrees.
Keep it lean: @path imports modularize, and .claude/rules/ with a paths glob load only when relevant.
/memory persists conventions; /compact compresses but blurs numbers and dates.
Plan mode for large, multi-approach, or architectural changes; direct execution for single-file fixes and clear stack traces. The Explore subagent isolates noisy discovery.
Built-in tools: Glob (find by pattern), Grep (search contents), Read, Write, Edit (unique-match; fall back to Read+Write), Bash. Investigate incrementally: Grep entry points -> Read -> Grep usages -> Read consumers.
MCP extends reach to external systems; prefer community servers, scope via .mcp.json, secrets through env vars.

Match the tool and mode to the task, and let durable config do the remembering.

자주 묻는 질문

“코드 생성 및 개발자 생산성” 강의는 무료인가요?

네 — “코드 생성 및 개발자 생산성” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 Claude Architect 강의 전체를 잠금 해제할 수 있습니다. Claude Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“코드 생성 및 개발자 생산성”에서 뭘 배우나요?

CLAUDE.md, 계획 모드, 기본 제공 도구 및 조사를 다룹니다 브라우저에서 직접 실행하는 실습 코드로 Claude Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

Claude Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 Claude Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.

“코드 생성 및 개발자 생산성” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 Claude Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 Claude Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← Claude Architect(으)로 돌아가기