대화형에서 작업형으로
한 번 답하는 챗봇에서 끝나지 않고, 도구를 호출해 읽고 → 시도하고 → 관찰하고 → 다시 시도 하는 작업 루프가 자리 잡았습니다.
U-Boot 의 NAND 컨트롤러 드라이버 위에서, 가짜 데모 없이 직접 보여드립니다. 오늘 끝나면 — 내일 아침 첫 빌드 전에 — 자기 코드로 첫 실험을 돌릴 수 있습니다.
오늘 데모는 NAND 위주지만, DDR 컨트롤러·PHY 캘리브레이션·부트로더 코드도 같은 패턴으로 적용됩니다.
4분. 한 줄 정의 → 변곡점 3개 → 오늘 데모를 보는 관점.
Claude Code = 터미널에서 자율적으로 일하는 코드 동료
“자율적”이란, 한 번 시키면 스스로 파일을 읽고 / 빌드를 돌리고 / 로그를 보고 / 다음 행동을 결정한다는 뜻입니다. 보드 디버깅에서 “레지스터 보고, 가설 세우고, 다시 시도” 하는 루프를 코드 저장소 위에서 그대로 반복합니다.
오늘 중요한 것은 “모델이 똑똑해졌다”가 아닙니다. 코드를 읽고, 도구를 쓰고, 팀 규칙을 기억하는 형태로 바뀌었기 때문에 임베디드 코드베이스에서도 실전성이 생겼습니다.
한 번 답하는 챗봇에서 끝나지 않고, 도구를 호출해 읽고 → 시도하고 → 관찰하고 → 다시 시도 하는 작업 루프가 자리 잡았습니다.
U-Boot 같은 저장소에서도 사람이 관련 파일을 먼저 고르지 않아도 됩니다.grep, 파일 읽기, 연관 추적을 Claude가 먼저 수행합니다.
`CLAUDE.md`, Skills, Hooks 로 팀 절차를 반복 가능하게 만들 수 있습니다. 개인 요령이 아니라 팀의 작업 방식으로 붙는다는 점이 변곡점입니다.
라이브 데모는 NAND/MTD 로 보여드리지만, 같은 패턴이 그대로 적용됩니다 — DDR 컨트롤러 캘리브레이션 코드(타이밍 파라미터 표 자동 정리), PHY 트레이닝 시퀀스(시퀀스 다이어그램·실패 패턴 분류), 부트로더 SPL 사이즈 분석(.map·bloat-o-meter 결과 해석). “레지스터 ↔ 데이터시트 ↔ 코드” 삼각관계가 있는 작업이면 거의 다 됩니다.
make, 테스트, diff 검토까지 이어지는지.12분. 오늘 바로 쓸 3개를 먼저, 나머지 2개는 확장 기능으로 본다.
CLAUDE.md, 도구 사용. 여기까지 이해하면 오늘 데모 4종은 거의 다 설명됩니다.사람이 한 번 시키면, Claude 가 사고 → 도구 호출 → 관찰 → 다음 행동을 스스로 반복합니다.
보드 디버깅에서 “레지스터 한 번 보고, 로그 한 번 보고, 가설 세우고, 다시 시도” 하는 그 루프와 똑같음. 차이는 코드 위에서 돌아간다는 것 뿐.
터미널 기반 = SSH 접속한 빌드 서버·타겟 보드 호스트에서 그대로. GUI 도 IDE 도 강요 안 함.
팀의 빌드 명령·코딩 규칙·하드웨어 제약을 적어두면 Claude 가 매 세션마다 그걸 알고 시작합니다.
신규 입사자에게 한 번 알려주듯이 한 번만. 매 PR 마다 “BCH-8 인지 확인했나?”를 다시 말할 필요 없음.
ECC · OOB 사이즈 · IRQ 컨텍스트 · 비트필드 매크로 정책 — 사람이 자주 까먹는 항목이 그대로 컨텍스트.
말만 하는 게 아니라 실제로 파일을 읽고, 고치고, 빌드를 돌립니다. ChatGPT 웹 채팅과의 결정적 차이.
Read = 파일 정독 / Grep = 심볼·문자열 검색 / Edit = 정확한 변경 / Bash = 빌드·테스트·git. 이 4 가지 조합으로 거의 모든 임베디드 작업이 됨.
make · git · objdump · scripts/checkpatch.pl 까지 그대로 호출. 사내 빌드 스크립트를 따로 가르칠 필요 없음.
GitHub · DB · Jira · 내부 시스템에 Claude 가 직접 접근. Model Context Protocol 이 표준 인터페이스.
사내에 이미 있는 도구를 Claude 와 잇는 표준 방법. 매번 별도 통합 코드를 짤 필요가 없습니다.
JTAG 디버거·로직 애널라이저·내부 트레이스 서버를 MCP 로 노출하면, Claude 가 측정값을 직접 읽고 다음 시나리오를 결정. 사람이 콘솔에 GDB 명령 치는 시간을 그만큼 절약.
Skill = 자주 하는 절차의 호출 가능한 형태(릴리즈 노트 작성·MISRA 점검).
Subagent = 큰 작업의 위임. 메인 컨텍스트를 더럽히지 않고 “이 디렉토리만 정리” 같은 분담.
Hook = 자동 트리거. 커밋 전 단위테스트, 빌드 후 정적 분석, 위험 명령 차단까지.
Hook 으로 “git push 전 sandbox 빌드 + checkpatch” 강제. Subagent 로 “drivers/mtd/ 만 리팩토링” 분담. 팀 노하우가 코드가 됨.
| 시점 | 기능 | 언제 도입 | 사람의 일 |
|---|---|---|---|
| Day 1 | CLI 루프 + 도구 | 설치 직후 | 질문하고 빌드/테스트 결과 검토 |
| Day 3 | CLAUDE.md | 같은 실수 2번 반복될 때 | 5~10줄 작성·갱신 |
| Week 2 | Skills | 같은 절차 3번 이상 반복 | 팀 표준 절차를 Skill 로 고정 |
| Month 1 | MCP | 외부 시스템(Jira·GitHub·빌드팜) 연계 | MCP 서버 1개 붙여 보기 |
| Month 2 | Subagents · Hooks | 팀 워크플로우 표준화 | 자동 게이트와 금기 정의 |
* 시점은 권장값. 팀 상황에 따라 늦춰도 무방. 단, 첫 줄(CLAUDE.md 1줄)은 오늘부터.
MCP(Model Context Protocol) 는 Claude 같은 AI 클라이언트가 외부 시스템·내부 도구·측정장비를 다루는 표준 어댑터 규격입니다. 한 번 MCP 서버로 감싸면 — Claude Code · IDE 플러그인 · 자동화 봇이 가리지 않고 같은 인터페이스로 호출.
JSON-RPC 프로토콜. stdio · HTTP · SSE 전송 모두 지원. Claude 가 도구 카탈로그를 자동으로 발견하고 결과를 컨텍스트로 회수합니다.
호출 가능한 함수. 부수효과·외부 호출이 일어남.
읽기 전용 데이터. Claude 컨텍스트로 흘러들어옴.
재사용 템플릿. 팀 노하우를 한 줄 호출로.
CLI 한 줄: claude mcp add github -- npx -y @modelcontextprotocol/server-github
여러 서버를 git 으로 공유하려면 프로젝트 루트의 .mcp.json:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
},
"jtag": {
"command": "/opt/jtag-mcp/server",
"env": { "JTAG_PORT": "ttyUSB0" }
},
"buildfarm": {
"url": "https://build.internal/mcp"
}
}
}팀원이 저장소 clone 만 하면 같은 도구. $${VAR} 로 토큰은 환경변수에서.
/permissions 로 정책 조정@modelcontextprotocol/sdk 로 50 라인이면 시작24분. 4종 데모 · 각 6분 · U-Boot 메모리 서브시스템
각 데모는 90초 영상 + 4분 해설 + 30초 전환 기준입니다. 시간이 밀리면 A, C, E는 반드시 시연하고 H는 결과 화면만 요약해도 전체 메시지는 유지됩니다.
U-Boot drivers/mtd/nand/raw/ 의 NAND 컨트롤러 드라이버 (600~800라인, 레거시).
이 NAND 컨트롤러 드라이버의 함수별 책임을 정리하고, 명령 시퀀서·ECC·DMA 부분을 책임 단위로 분리할 수 있게 리팩토링을 제안해줘. 비트필드 매크로 가독성 개선 포함.함수 책임 마크다운 표 + Mermaid 다이어그램 + 매크로 → FIELD_PREP/FIELD_GET 변환 diff
사람이 똑같이 하려면 정독에만 30~60분. Claude는 5번의 도구 호출로 끝냄.
| 함수 | 영역 | 라인 | 책임 |
|---|---|---|---|
| denali_cmd_ctrl() | IO | 88~142 | command/address strobe 시퀀서 |
| denali_read_buf() | IO/DMA | 144~198 | data port FIFO 드레인 |
| denali_write_buf() | IO/DMA | 200~254 | data port FIFO 채우기 |
| denali_irq_handler() | IRQ | 256~320 | INT_STATUS 디스패치 (race risk!) |
| denali_ecc_correct() | ECC | 322~398 | 4bit/8bit Hamming · BCH 분기 |
| denali_setup_dma() | DMA | 400~462 | descriptor chain 구성 |
| denali_probe() | probe | 464~612 | clock·reset·layout 등록 |
| nand_dt_init() | probe | 614~698 | DT 노드 → controller config 매핑 |
| denali_remove() | probe | 700~736 | 자원 해제 (irq/clk/dma) |
--- a/drivers/mtd/nand/raw/denali.c
+++ b/drivers/mtd/nand/raw/denali.c
@@ -271,15 +271,11 @@ static void denali_irq_handler(struct denali_nand_info *denali)
- u32 ecc_status = (irq_status >> 4) & 0x0fff;
- u32 sect = (irq_status >> 16) & 0xff;
- bool corr_err = (irq_status & 0x80000000) ? true : false;
+ u32 ecc_status = FIELD_GET(IRQ_ECC_STATUS_MASK, irq_status);
+ u32 sect = FIELD_GET(IRQ_SECT_MASK, irq_status);
+ bool corr_err = FIELD_GET(IRQ_CORR_ERR, irq_status);
@@ -22,6 +22,12 @@
+#define IRQ_ECC_STATUS_MASK GENMASK(15, 4)
+#define IRQ_SECT_MASK GENMASK(23, 16)
+#define IRQ_CORR_ERR BIT(31)denali_irq_handler() 안에서 INT_STATUS 클리어 전에 ECC 카운터를 읽음 — 4-bit correctable 이 IRQ 컨텍스트에서 sleeping 함수와 만나면 lost interrupt 가능. 우선순위 1로 수정 권장.
새 IP rev(가칭 V2) 지원을 위해 Kconfig 옵션·Makefile·defconfig 동시 수정.
CONFIG_NAND_DENALI_V2 Kconfig 옵션 추가. 관련 Makefile, defconfig까지 일관되게. sandbox 빌드가 깨지지 않게.Kconfig·Makefile·defconfig 동시 diff + `make sandbox_defconfig && make` 실제 통과
Kconfig·Makefile·defconfig 3 파일 동시에. sandbox + am335x 두 보드에서 동시 검증.
--- a/drivers/mtd/nand/raw/Makefile
+++ b/drivers/mtd/nand/raw/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_NAND_DENALI) += denali.o
obj-$(CONFIG_NAND_DENALI_DT) += denali_dt.o
+obj-$(CONFIG_NAND_DENALI_V2) += denali_v2.o
--- a/drivers/mtd/nand/raw/Kconfig
+++ b/drivers/mtd/nand/raw/Kconfig
@@ -67,6 +67,14 @@ config NAND_DENALI_DT
depends on NAND_DENALI
help
+config NAND_DENALI_V2
+ bool "Support Denali NAND V2 (rev >= 2.4)"
+ depends on NAND_DENALI
+ default n
+ help
+ Enables register layout and ECC table for Denali V2
+ (sandbox + am335x verified).
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -212,3 +212,4 @@ CONFIG_NAND_DENALI=y
CONFIG_NAND_DENALI_DT=y
+CONFIG_NAND_DENALI_V2=y$ make sandbox_defconfig && make -j$(nproc)
HOSTCC scripts/basic/fixdep
...
CC drivers/mtd/nand/raw/denali_v2.o
AR drivers/mtd/nand/raw/built-in.a
LD u-boot
Image Name: U-Boot 2026.04
Created: Wed Apr 29 16:55:21 2026
Image Type: sandbox
Data Size: 8482456 Bytes = 8.09 MiB
size delta vs HEAD~1: +4072 bytes (V2 ECC table)
warnings: 0
result: PASS
$ make CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig && make -j$(nproc)
...
LD u-boot
warnings: 0
result: PASS (cross-compile)NAND 컨트롤러 핵심 함수에 단위테스트가 0개임을 강조.
이 함수의 unit test를 sandbox에서 돌릴 수 있게 작성. 정상 + 경계 조건(타임아웃·잘못된 명령·ECC 비트 1~3개 에러). test/dm/ 패턴 따라서.test/dm/nand_<ctrl>.c 신규 + Mock 레지스터 + Kconfig·Makefile 등록 + ./test/py/test.py PASS
사람은 mock 만들기 귀찮아 미루던 일. Claude는 5 케이스 + coverage까지 한 번에.
// test/dm/nand_denali.c — Claude 가 신규 작성
#include <dm.h>
#include <dm/test.h>
#include <test/ut.h>
static int dm_test_denali_ready(struct unit_test_state *uts)
{
struct mtd_info *mtd = mock_denali_setup(uts, 0);
ut_assertok(mock_denali_wait_ready(mtd, 1));
ut_asserteq(mock_denali_irq_count(mtd), 1);
return 0;
}
DM_TEST(dm_test_denali_ready, UTF_DM | UTF_SCAN_FDT);
static int dm_test_denali_4bit_timeout(struct unit_test_state *uts)
{
struct mtd_info *mtd = mock_denali_setup(uts, 0);
mock_denali_inject_ecc_err(mtd, /*nbits=*/4);
mock_denali_set_timeout(mtd, 50); /* tight bound */
ut_assertne(mtd_read(mtd, 0, 4096, NULL, buf), 0);
ut_asserteq(mock_denali_irq_count(mtd), 1);
return 0;
}
DM_TEST(dm_test_denali_4bit_timeout, UTF_DM | UTF_SCAN_FDT);
// ... ecc_pack / 1bit / 3bit 케이스 동일 패턴$ ./test/py/test.py --bd=sandbox -k nand
============================= test session starts ==============================
collected 7 items / 5 selected
dm_test_denali_ready PASS (3 ms)
dm_test_denali_ecc_pack PASS (8 ms)
dm_test_denali_4bit_timeout PASS (52 ms)
dm_test_denali_1bit_correct PASS (4 ms)
dm_test_denali_3bit_correct PASS (5 ms)
============================== 5 passed in 0.18s ==============================
coverage:
pack_ecc() 100% (32/32 lines)
correct_data() 85% (47/55 lines) ← 미커버: rare BCH path
irq dispatch() 78% (32/41 lines) ← 미커버: timeout edgeClaude 가 함께 만들어 준 것: Mock 컨트롤러(test/mock/denali_mock.c), Kconfig 등록(CONFIG_NAND_DENALI_TEST), Makefile 라인. 사람은 5 분 검토만.
데모 A와 같은 드라이버. 문서가 0줄임 강조.
이 드라이버의 컨트롤러 레지스터 맵을 마크다운 표로(오프셋·비트필드·의미). 'NAND read page' 명령 흐름을 Mermaid 시퀀스 다이어그램으로(CPU/컨트롤러/NAND chip).레지스터 맵 표 + Mermaid 시퀀스 다이어그램 + 메모리 트레이닝 흐름도
사람은 1~2일 걸려 안 하던 일. Claude는 표 + 다이어그램 + 매트릭스 + 성능표를 동시에.
| 오프셋 | 레지스터 | 비트 | 의미 |
|---|---|---|---|
| 0x000 | DEVICE_ID | 31:0 | controller revision (0x4 = V2) |
| 0x010 | CHIP_RESET | 0 | self-clearing soft reset |
| 0x040 | ECC_ERR_CNT_4BIT | 31:0 | 4-bit Hamming err 누적 카운터 |
| 0x044 | ECC_ERR_CNT_BCH | 31:0 | BCH 보정 카운터 |
| 0x080 | INT_STATUS | 31:0 | IRQ 디스패치 — bit별 의미는 표 §아래 |
| 0x100 | DMA_DESC_BASE | 31:0 | DMA descriptor chain head 물리주소 |
| 0x104 | DMA_BURST_LEN | 7:0 | AXI burst length (1/4/8/16) |
| 0x200 | TIMING_CTRL_0 | 31:0 | tCS / tCH / tCLS / tCLH 인코딩 |
| 0x204 | TIMING_CTRL_1 | 31:0 | tWP / tWH / tRP / tREH 인코딩 |
| 0x300 | OOB_LAYOUT | 15:0 | OOB 64B 안의 ECC 영역 시작 오프셋 |
| 데모 | 사람 | Claude Code | 절감 |
|---|---|---|---|
| A 분석 | 30~60분 | 1분 + 검토 5분 | ~85% |
| C 빌드 | 30분 | 5분 | ~80% |
| E 단위테스트 | 2~4시간 | 5분 + 검토 10분 | ~90% |
| H 문서화 | 1~2일 (안 함이 다반사) | 10분 | 0 → 1 |
* 이 표는 “대체로 얼마나 빨라지는가”를 보여주는 용도입니다. 메시지는 절감률보다도 검토 시작점이 올라간다는 데 있습니다.
6분. 핵심은 인원 감축이 아니라 처리 속도와 검토 품질의 재배치입니다.
내 일이 사라지는 것이 아니라 내 일의 밀도가 올라갑니다. 반복 작업은 위임하고, 사람은 race condition · 하드웨어 진실 · 아키텍처 결정 · 요구사항 협상 같은 어려운 판단에 시간을 씁니다.
| 시각 | Before — 지금 | After — Claude Code 도입 후 |
|---|---|---|
| 09:00 | 어제 빌드 깨진 거 원인 추적 — 3시간 | Claude 가 git bisect + Kconfig 변경 추적 → 로그 받기 — 20분 |
| 11:00 | 신규 IP rev 지원 패치 — Kconfig·Makefile·defconfig 수동 수정 | “V2 추가” 한 번으로 3 파일 동시 수정 + sandbox 검증 |
| 14:00 | 이번 주 PR 코드리뷰 5건 — 정독 30분 × 5 | 1차 검토는 자동, 사람은 race·hardware 가정만 집중 — 50분 |
| 16:30 | 단위테스트·문서화는 다음 주에… | 테스트 1개 + 레지스터 맵 문서 생성 — 20분 |
* 회의·디버그·문서·리뷰 슬롯이 재배치됨. 보드·디버거·로직 애널라이저와 만나는 시간은 오히려 늘어남.
“이거 어떻게 하지” 회의 시간이 짧아짐. 회의 들어가기 전에 옵션 3개와 trade-off 표가 준비됨. 회의는 결정만.
1차 검토(스타일·dead code·obvious bug)는 자동. 사람은 race·하드웨어 가정·확장성 같은 진짜 어려운 문제만.
문서화가 별도 작업이 아니라 코드 변경의 부산물. 데이터시트와 코드의 갭이 사라지면 온보딩이 가벼워짐.
7분. 라이브에서는 첫 30분만 설명하고, 아래 체크리스트는 사후 참고 자료로 남깁니다.
# 1. 설치 (npm 글로벌)
npm install -g @anthropic-ai/claude-code
# 2. 인증
claude login
# 3. 프로젝트 루트로 이동 후 시작
cd ~/work/u-boot
claude
# 4. 첫 명령 — 프로젝트 파악시키기
> CLAUDE.md 를 읽고, 이 저장소 구조를 3문단으로 요약해줘.인증은 1회. 이후 같은 셸이면 토큰이 캐시됨. 프록시 환경은 HTTPS_PROXY 만 export.
# 우리 프로젝트
이 프로젝트는 NAND 컨트롤러 펌웨어다.
## 빌드/실행
- 빌드: `make sandbox_defconfig && make -j$(nproc)`
- 단위테스트: `./test/py/test.py --bd=sandbox`
- 크로스 빌드: `make CROSS_COMPILE=arm-linux-gnueabihf- am335x_evm_defconfig`
## 관습
- 새 컨트롤러 드라이버는 drivers/mtd/nand/raw/ 에.
- 비트필드는 FIELD_PREP/FIELD_GET 사용 (직접 시프트/마스크 금지).
- 신규 코드는 SPDX-License-Identifier 헤더 필수.
## 하드웨어 제약
- ECC: BCH-8, OOB 64바이트 (변경 불가)
- 페이지 크기: 4KB
- 컨트롤러 클럭: 100MHz, AHB 버스
- DMA 정렬: 16바이트
## 리뷰어가 항상 보는 것
- race condition (IRQ context vs sleeping function)
- endianness (cpu_to_le32 누락)
- 타임아웃 처리 (busy loop 금지)CLAUDE.md 가능 (스코프드).ECC: BCH-8 고정. 변경 시 OOB 레이아웃까지 확인.ECC 잘 처리해줘. ← Claude가 추측함CLAUDE.md, 첫 작업. 이 세 가지만 끝나면 청중은 내일 아침 바로 자기 저장소에서 첫 실험을 시작할 수 있습니다.npm i -g @anthropic-ai/claude-code 후 claude login. 사내 프록시면 HTTPS_PROXY 만 export.
빌드 명령·하드웨어 제약 5줄만 적고, 가장 무서운 파일을 코드리뷰 시키기. 여기서 “여긴 틀렸어”라고 바로잡는 과정이 컨텍스트를 쌓는 첫 단계입니다.
sandbox 빌드가 도는 폴더에서 test/dm/ 패턴으로 테스트 1개 생성 시키기. ./test/py/test.py 까지 PASS 보면 끝.
CLAUDE.md 에 정리합니다.npm install -g @anthropic-ai/claude-code/ide 로 VS Code 연결.claude/commands/ 에 자주 쓰는 명령 1개 저장/permissions 에서 정책 조정./clear 로 컨텍스트 정리, 큰 작업은 나눠서..env, credentials* 자동 무시 — .gitignore 정비 우선.rm -rf, git push --force 는 hook 으로 사전 차단.설치·CLI·MCP 레퍼런스. 변경이 빠르므로 분기마다 한 번씩.
실패담·노하우 공유. 같은 함정에 두 번 빠지지 말 것. 신규 멤버는 핀 메시지부터.
자가학습 28모듈. CLAUDE.md → MCP → Subagent 순으로. 한 번에 몰아보지 말고 주 1모듈 페이스 권장.
5분. Claude Code · AI 에이전트의 본질에 대한 10 문답. 라이브에서는 5~6 개만 다루고, 나머지는 사후 자료로.
Copilot/Cursor 는 IDE 안의 자동완성·채팅이 중심. Claude Code 는 (1) 터미널에서 자율 루프로 일하고, (2) Read/Edit/Bash/Grep 4종 도구로 빌드·테스트·git 까지 직접 실행하고, (3) CLAUDE.md 로 팀의 규칙을 영구 기억합니다. “옆에서 코드 짜주는 도구” vs “위임할 수 있는 동료”의 차이.
오늘 보신 U-Boot 데모가 답입니다. C/C++ · Kconfig · Makefile · linker script · 디바이스 트리 · RTOS 코드 모두 강함. 매크로·비트필드처럼 전통적 정적분석이 약한 영역에서도 의미적으로 추적합니다.
가능합니다. CLAUDE.md 나 Skill 에 “스택 사용 < 256B”, “IRQ 컨텍스트 sleep 금지”, “MISRA 예외 규칙” 같은 제약을 적어두면 출력이 그 범위 안으로 좁혀집니다. 제약을 안 적으면 일반적인 답이 옵니다 — 모든 건 컨텍스트에 달림.
위험은 있습니다. 그래서 두 단계: (1) CLAUDE.md 에 “데이터시트는 docs/ds/*.pdf 만 신뢰” 같은 출처 한정. (2) 변경 후 sandbox/DM 테스트로 즉시 회귀. 환각이 빌드를 깨면 Claude 가 스스로 알아채고 다시 시도합니다 — 자율 루프의 자가 교정.
완전히 같지는 않습니다. LLM 은 본질적으로 비결정적이고, 코드 변경처럼 경로가 여러 개인 작업은 매번 약간 다른 풀이를 냅니다. 그래서 평가 기준은 “같은 결과”가 아니라 “같은 검증 게이트(빌드·테스트·리뷰)를 통과하느냐”. 게이트가 정확하면 비결정성은 문제가 안 됩니다.
세 가지 장치: (1) 자동 컴팩션 — 오래된 메시지를 요약해 토큰 절약. (2) `/clear` 명령으로 사람이 명시적 리셋. (3) Subagent — 큰 작업을 별도 컨텍스트로 위임해 메인을 깨끗하게. “디렉토리 전체 리팩토링” 같은 일은 Subagent 가 맞습니다.
큰 변경(여러 파일 수정·아키텍처 결정·머지 직전 작업) 전에 Shift+Tab 으로 Plan mode 진입. Claude 가 “이렇게 할 계획”만 제시하고 실제 변경은 안 함 — 사람이 검토 후 승인. 일상적 1~2파일 수정은 일반 모드가 빠릅니다.
AI 가 80% 를 만들고, 사람이 보드 위에서 마무리. 일의 분담이 바뀌는 것이지 사람이 빠지는 게 아닙니다. sandbox · DM 테스트 · QEMU 같은 호스트 검증 루프를 만들면 회귀의 80% 를 보드 없이 잡을 수 있습니다.
초반엔 벌어집니다. 잘 쓰는 사람의 요령은 대부분 “좋은 CLAUDE.md · 좋은 프롬프트 · 자주 쓰는 Skill”. 그래서 개인 노트로 두지 말고 공용 자산으로 굳혀야 합니다 — 격차가 개인 숙련도가 아니라 팀 자산이 됩니다.
(1) 설치·로그인 5분. (2) CLAUDE.md 5줄 작성. (3) “가장 무서운 파일을 코드리뷰” 1번 시켜보기. 이 3단계까지가 30분. §5 페이지에 그대로 적혀 있습니다.
“1주일 걸리던 일을 1시간에” 는 마케팅 카피가 아니라 오늘 보여드린 데모 4 종의 실측입니다. 오늘 끝나면 — 내일 아침 첫 빌드 전에 — 자기 코드로 첫 실험을 돌려 보세요. 그 첫 30 분이 다음 1 년의 워크플로우를 결정합니다.