메모리 컨트롤러 엔지니어를 위한 60분

Claude Code,
1주일 걸리던 일을
1시간 안에.

U-Boot 의 NAND 컨트롤러 드라이버 위에서, 가짜 데모 없이 직접 보여드립니다. 오늘 끝나면 — 내일 아침 첫 빌드 전에 — 자기 코드로 첫 실험을 돌릴 수 있습니다.

U-BootNAND / MTDDDR / PHYKconfig · MakefileDM · sandboxC / 비트필드

오늘 데모는 NAND 위주지만, DDR 컨트롤러·PHY 캘리브레이션·부트로더 코드도 같은 패턴으로 적용됩니다.

↓ 시작

오늘 60분 흐름

데모 24분 · 슬라이드 31분 · Q&A 5분
  1. 0~2
    오프닝
    오늘 60분에 가져갈 메시지 1줄
  2. 2~6
    §1 Claude Code 가 뭔가
    한 줄 정의 · 왜 지금이 변곡점인가
  3. 6~18
    §2 핵심 5 가지
    오늘 바로 쓸 3개 + 나중에 붙일 2개
  4. 18~42
    §3 임베디드 라이브 데모 4 종
    U-Boot NAND 컨트롤러 · 각 6분
  5. 42~48
    §4 그래서 우리가 얻는 것
    처리 속도보다 검토 품질과 밀도
  6. 48~55
    §5 시작하기
    오늘 30분 · 이번 주 7일
  7. 55~60
    Q & A
    라이브 우선 6문답
대상
메모리 컨트롤러·펌웨어·드라이버를 매일 만지는 엔지니어. AI 도구 경험 무관.
전제
본인 PC 에 git 으로 작업 중인 C 프로젝트가 1개 있다면 충분. 별도 준비물 없음.
결과물
오늘 30분이면 첫 명령. 이번 주 안에 코드리뷰·단위테스트 워크플로우에 붙일 수 있음.
§1

Claude Code란? + 지금 왜 봐야 하나

4분. 한 줄 정의 → 변곡점 3개 → 오늘 데모를 보는 관점.

한 줄 정의

Claude Code = 터미널에서 자율적으로 일하는 코드 동료

“자율적”이란, 한 번 시키면 스스로 파일을 읽고 / 빌드를 돌리고 / 로그를 보고 / 다음 행동을 결정한다는 뜻입니다. 보드 디버깅에서 “레지스터 보고, 가설 세우고, 다시 시도” 하는 루프를 코드 저장소 위에서 그대로 반복합니다.

오늘 중요한 것은 “모델이 똑똑해졌다”가 아닙니다. 코드를 읽고, 도구를 쓰고, 팀 규칙을 기억하는 형태로 바뀌었기 때문에 임베디드 코드베이스에서도 실전성이 생겼습니다.

왜 지금 실전 도구가 됐나

2024

대화형에서 작업형으로

한 번 답하는 챗봇에서 끝나지 않고, 도구를 호출해 읽고 → 시도하고 → 관찰하고 → 다시 시도 하는 작업 루프가 자리 잡았습니다.

2025

큰 저장소를 스스로 탐색

U-Boot 같은 저장소에서도 사람이 관련 파일을 먼저 고르지 않아도 됩니다.grep, 파일 읽기, 연관 추적을 Claude가 먼저 수행합니다.

2025~2026

팀 규칙을 함께 쓴다

`CLAUDE.md`, Skills, Hooks 로 팀 절차를 반복 가능하게 만들 수 있습니다. 개인 요령이 아니라 팀의 작업 방식으로 붙는다는 점이 변곡점입니다.

오늘 데모는 NAND, 그 다음은?

라이브 데모는 NAND/MTD 로 보여드리지만, 같은 패턴이 그대로 적용됩니다 — DDR 컨트롤러 캘리브레이션 코드(타이밍 파라미터 표 자동 정리), PHY 트레이닝 시퀀스(시퀀스 다이어그램·실패 패턴 분류), 부트로더 SPL 사이즈 분석(.map·bloat-o-meter 결과 해석). “레지스터 ↔ 데이터시트 ↔ 코드” 삼각관계가 있는 작업이면 거의 다 됩니다.

오늘 데모를 볼 때 체크할 것 3개

읽기 능력
대형 C 코드베이스를 의미 단위로 잘게 나누는지. 함수 책임, 비트필드, 레지스터 정의를 따라가는지.
실행 능력
단순 설명으로 끝나지 않고 make, 테스트, diff 검토까지 이어지는지.
검토 가능성
결과가 사람 리뷰를 더 쉽게 만드는지. 완성본보다 검토 시작점을 얼마나 끌어올리는지.
§2

핵심 기능 투어

12분. 오늘 바로 쓸 3개를 먼저, 나머지 2개는 확장 기능으로 본다.

한 줄 요약: Claude Code 는 (1) CLI 에이전틱 루프로 일하고, (2) CLAUDE.md 로 팀의 지식을 기억하고, (3) 도구로 코드·빌드·테스트를 직접 만지고, (4) MCP 로 외부 시스템과 연결되며, (5) Skills/Subagents/Hooks 로 팀 노하우를 코드처럼 굳힙니다.
오늘 바로 가져갈 것
CLI 루프, CLAUDE.md, 도구 사용. 여기까지 이해하면 오늘 데모 4종은 거의 다 설명됩니다.
나중에 붙일 것
MCP 와 Skills/Subagents/Hooks 는 팀 적용 단계의 증폭기입니다. 오늘은 “이런 확장축이 있다”까지만.
오늘 바로 · V2

CLI + 에이전틱 루프

사람이 한 번 시키면, Claude 가 사고 → 도구 호출 → 관찰 → 다음 행동을 스스로 반복합니다.

보드 디버깅에서 “레지스터 한 번 보고, 로그 한 번 보고, 가설 세우고, 다시 시도” 하는 그 루프와 똑같음. 차이는 코드 위에서 돌아간다는 것 뿐.

임베디드 맥락

터미널 기반 = SSH 접속한 빌드 서버·타겟 보드 호스트에서 그대로. GUI 도 IDE 도 강요 안 함.

: "ECC 4비트 에러 처리 로직을 찾아서, 타임아웃 코드와 같이 묶여 있는지 확인해줘" — 5번의 도구 호출로 끝.
Plan mode: Shift+Tab 으로 큰 작업 전 "계획 먼저 검토" 모드 진입. 빌드 깨뜨릴 수정 전에 사람이 한 번 확인.
오늘 바로 · V3

CLAUDE.md = 프로젝트의 기억

팀의 빌드 명령·코딩 규칙·하드웨어 제약을 적어두면 Claude 가 매 세션마다 그걸 알고 시작합니다.

신규 입사자에게 한 번 알려주듯이 한 번만. 매 PR 마다 “BCH-8 인지 확인했나?”를 다시 말할 필요 없음.

임베디드 맥락

ECC · OOB 사이즈 · IRQ 컨텍스트 · 비트필드 매크로 정책 — 사람이 자주 까먹는 항목이 그대로 컨텍스트.

한 줄 예: "ECC: BCH-8 고정. 변경 시 OOB 레이아웃까지 확인." → Claude 가 ECC 관련 변경엔 항상 OOB 도 같이 검사.
오늘 바로 · V4

도구 사용 (Read · Edit · Bash · Grep)

말만 하는 게 아니라 실제로 파일을 읽고, 고치고, 빌드를 돌립니다. ChatGPT 웹 채팅과의 결정적 차이.

Read = 파일 정독 / Grep = 심볼·문자열 검색 / Edit = 정확한 변경 / Bash = 빌드·테스트·git. 이 4 가지 조합으로 거의 모든 임베디드 작업이 됨.

임베디드 맥락

make · git · objdump · scripts/checkpatch.pl 까지 그대로 호출. 사내 빌드 스크립트를 따로 가르칠 필요 없음.

관찰: Bash 권한은 매 호출마다 물어봄. 위험 명령은 자동 차단(rm -rf, force push). 안전이 기본값.
2주차 이후 · V5

MCP — 외부 시스템과의 다리

GitHub · DB · Jira · 내부 시스템에 Claude 가 직접 접근. Model Context Protocol 이 표준 인터페이스.

사내에 이미 있는 도구를 Claude 와 잇는 표준 방법. 매번 별도 통합 코드를 짤 필요가 없습니다.

임베디드 맥락

JTAG 디버거·로직 애널라이저·내부 트레이스 서버를 MCP 로 노출하면, Claude 가 측정값을 직접 읽고 다음 시나리오를 결정. 사람이 콘솔에 GDB 명령 치는 시간을 그만큼 절약.

사내 시나리오: Jira MCP → 티켓 자동 링크. GitHub MCP → PR 본문·리뷰 자동 작성. 사내 빌드팜 MCP → cross-build 결과 회수.
Primitive 3종: Tools(호출 가능 함수) · Resources(읽기 전용 데이터) · Prompts(재사용 템플릿) — 영상 60~76s.
팀 적용 단계 · V6

Skills · Subagents · Hooks

Skill = 자주 하는 절차의 호출 가능한 형태(릴리즈 노트 작성·MISRA 점검).

Subagent = 큰 작업의 위임. 메인 컨텍스트를 더럽히지 않고 “이 디렉토리만 정리” 같은 분담.

Hook = 자동 트리거. 커밋 전 단위테스트, 빌드 후 정적 분석, 위험 명령 차단까지.

임베디드 맥락

Hook 으로 “git push 전 sandbox 빌드 + checkpatch” 강제. Subagent 로 “drivers/mtd/ 만 리팩토링” 분담. 팀 노하우가 코드가 됨.

조합: PR 생성 → Hook → security-review subagent + test-runner subagent 병렬 → 사람은 결과 표만 검토.

기능 도입 순서 — 한 번에 다 가져가지 말 것

시점기능언제 도입사람의 일
Day 1CLI 루프 + 도구설치 직후질문하고 빌드/테스트 결과 검토
Day 3CLAUDE.md같은 실수 2번 반복될 때5~10줄 작성·갱신
Week 2Skills같은 절차 3번 이상 반복팀 표준 절차를 Skill 로 고정
Month 1MCP외부 시스템(Jira·GitHub·빌드팜) 연계MCP 서버 1개 붙여 보기
Month 2Subagents · Hooks팀 워크플로우 표준화자동 게이트와 금기 정의

* 시점은 권장값. 팀 상황에 따라 늦춰도 무방. 단, 첫 줄(CLAUDE.md 1줄)은 오늘부터.

§2 보강 — MCP 심층

MCP — 사내 도구를 잇는 표준 인터페이스

MCP(Model Context Protocol) 는 Claude 같은 AI 클라이언트가 외부 시스템·내부 도구·측정장비를 다루는 표준 어댑터 규격입니다. 한 번 MCP 서버로 감싸면 — Claude Code · IDE 플러그인 · 자동화 봇이 가리지 않고 같은 인터페이스로 호출.

호출 흐름
사용자 promptClaudetools/listMCP servertools/call외부 시스템structured resultClaude 컨텍스트다음 행동

JSON-RPC 프로토콜. stdio · HTTP · SSE 전송 모두 지원. Claude 가 도구 카탈로그를 자동으로 발견하고 결과를 컨텍스트로 회수합니다.

MCP server 가 노출하는 3 가지

Tools · Resources · Prompts

Tools

호출 가능한 함수. 부수효과·외부 호출이 일어남.

  • github.get_pr(id)
  • jtag.read_reg(addr)
  • buildfarm.run('am335x')
Resources

읽기 전용 데이터. Claude 컨텍스트로 흘러들어옴.

  • repo://drivers/mtd/
  • schema://nand_metrics
  • doc://datasheet/EMIF
Prompts

재사용 템플릿. 팀 노하우를 한 줄 호출로.

  • /code-review @file
  • /post-mortem @incident
  • /release-notes @tag
등록은 한 줄 — 또는 .mcp.json

팀 공용 설정

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} 로 토큰은 환경변수에서.

메모리 컨트롤러 엔지니어가 가장 빨리 체감할 4 시나리오

JTAG 디버거 MCP
BeforeGDB 콘솔 열고 monitor mdw 0x40 0x44 ... 직접 친 뒤 결과를 따로 정리
After“ECC 카운터 1초 간격 10회 추세” 한 줄 → Claude 가 시계열 표·해석까지
사내 빌드팜 MCP
Beforessh build.internal && trigger.sh am335x → 한참 기다렸다 로그 다운로드
Afterbuildfarm.run('am335x') 호출 → cross-build 결과 PASS/FAIL 매트릭스 자동 회수
GitHub MCP
BeforePR 페이지 열어 코멘트 12개 손으로 옮겨 적기
Afterlist_comments(PR#482) → 코멘트 묶어 우선순위 3 으로 정리 + 직접 fix 패치
내부 측정장비 MCP
Before오실로스코프·로직 애널라이저 캡처 → 사진 찍어 슬랙 공유
AfterMCP 서버가 캡처 자동 회수 → Claude 가 신호 패턴 분류·trace 파일 첨부
MCP 의 함정 — 미리 알아두기
  • · MCP 서버에 권한이 있는 만큼 Claude 도 권한이 생김 — 최소권한 원칙 준수
  • · 서드파티 MCP 서버는 코드 검토 후 도입. 임의 npm 패키지를 그대로 신뢰 X
  • · Tool 호출은 매번 사용자 동의가 기본. /permissions 로 정책 조정
  • · 자체 MCP 서버는 @modelcontextprotocol/sdk 로 50 라인이면 시작
§3

임베디드 라이브 데모 — U-Boot 메모리 서브시스템

24분. 4종 데모 · 각 6분 · U-Boot 메모리 서브시스템

현장 운영 메모

각 데모는 90초 영상 + 4분 해설 + 30초 전환 기준입니다. 시간이 밀리면 A, C, E는 반드시 시연하고 H는 결과 화면만 요약해도 전체 메시지는 유지됩니다.

데모 A · V7-A · 6분

레거시 C 분석·리팩토링

Setup

U-Boot drivers/mtd/nand/raw/ 의 NAND 컨트롤러 드라이버 (600~800라인, 레거시).

Prompt
이 NAND 컨트롤러 드라이버의 함수별 책임을 정리하고, 명령 시퀀서·ECC·DMA 부분을 책임 단위로 분리할 수 있게 리팩토링을 제안해줘. 비트필드 매크로 가독성 개선 포함.
Claude 결과

함수 책임 마크다운 표 + Mermaid 다이어그램 + 매크로 → FIELD_PREP/FIELD_GET 변환 diff

영상에서 보실 것

사람이 똑같이 하려면 정독에만 30~60분. Claude는 5번의 도구 호출로 끝냄.

  • 0:05wc -l → 840 라인 — 사람이 한 번에 읽기 무리
  • 0:08Read · Grep 5번 호출 — 함수 13개 / 매크로 312곳 식별
  • 0:181) 함수 책임 표 9개 — IO / ECC / DMA / probe 4영역
  • 0:322) 3-way 책임 분리 제안 — io.c / ecc.c / probe.c
  • 0:453) 매크로 변환 diff — 0x0fff/>>4 → GENMASK + FIELD_GET
  • 1:025) race condition 식별 — 4bit ECC IRQ-context 위험
  • 1:15검증 명령 + 다음 단계 우선순위 4개

Claude 가 실제로 뱉은 결과물

영상이 짧아 캡처 못 한 산출물을 텍스트로 살림
1) 함수 책임 마크다운 표
9 개 함수 — IO / ECC / DMA / probe 4 영역으로 분류
함수영역라인책임
denali_cmd_ctrl()IO88~142command/address strobe 시퀀서
denali_read_buf()IO/DMA144~198data port FIFO 드레인
denali_write_buf()IO/DMA200~254data port FIFO 채우기
denali_irq_handler()IRQ256~320INT_STATUS 디스패치 (race risk!)
denali_ecc_correct()ECC322~3984bit/8bit Hamming · BCH 분기
denali_setup_dma()DMA400~462descriptor chain 구성
denali_probe()probe464~612clock·reset·layout 등록
nand_dt_init()probe614~698DT 노드 → controller config 매핑
denali_remove()probe700~736자원 해제 (irq/clk/dma)
2) 3-way 책임 분리 제안
io.c / ecc.c / probe.c — Mermaid 흐름도 그대로 렌더
3) 매크로 변환 diff
raw shift/mask → GENMASK + FIELD_GET (가독성·검증 용이성 ↑)
--- 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)
Claude 가 추가로 짚어준 위험 — race condition

denali_irq_handler() 안에서 INT_STATUS 클리어 전에 ECC 카운터를 읽음 — 4-bit correctable 이 IRQ 컨텍스트에서 sleeping 함수와 만나면 lost interrupt 가능. 우선순위 1로 수정 권장.

강사 강조
10년 된 코드를 30초에 의미 단위로 분리해 읽음. 코드리뷰 시작점이 0이 아니라 70%.
데모 C · V7-C · 6분

빌드 시스템 다루기

Setup

새 IP rev(가칭 V2) 지원을 위해 Kconfig 옵션·Makefile·defconfig 동시 수정.

Prompt
CONFIG_NAND_DENALI_V2 Kconfig 옵션 추가. 관련 Makefile, defconfig까지 일관되게. sandbox 빌드가 깨지지 않게.
Claude 결과

Kconfig·Makefile·defconfig 동시 diff + `make sandbox_defconfig && make` 실제 통과

영상에서 보실 것

Kconfig·Makefile·defconfig 3 파일 동시에. sandbox + am335x 두 보드에서 동시 검증.

  • 0:03ls 3 파일 — 수정해야 할 파일 목록 확인
  • 0:10Edit 3번 — Kconfig + Makefile + defconfig 동시 수정
  • 0:25git diff --stat — 3 파일 18 라인 추가 (의도와 일치)
  • 0:38Bash: make sandbox_defconfig && make — 빌드 PASS
  • 0:52대체 보드: am335x cross-compile 검증 — warning 0
  • 1:05size delta +4072 byte (V2 ECC table) / dependency 정상
  • 1:12검증 결과 요약 — 4개 게이트 모두 ✓

Claude 가 실제로 뱉은 결과물

영상이 짧아 캡처 못 한 산출물을 텍스트로 살림
1) 3 파일 동시 diff
Kconfig + Makefile + defconfig — 깜빡하기 쉬운 의존성을 한 번에
--- 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
2) sandbox + cross-compile 빌드 결과
두 보드(am335x · sandbox) 모두 통과 + size delta 회수
$ 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)
size delta
+4072 byte
V2 ECC table
warning
0
checkpatch 통과
depends on
NAND_DENALI
의존성 정상
강사 강조
여러 디렉토리에 흩어진 빌드 파일을 동시에·일관되게. 가장 자주 깜빡하는 부분.
데모 E · V7-E · 6분

단위 테스트 자동 생성

Setup

NAND 컨트롤러 핵심 함수에 단위테스트가 0개임을 강조.

Prompt
이 함수의 unit test를 sandbox에서 돌릴 수 있게 작성. 정상 + 경계 조건(타임아웃·잘못된 명령·ECC 비트 1~3개 에러). test/dm/ 패턴 따라서.
Claude 결과

test/dm/nand_<ctrl>.c 신규 + Mock 레지스터 + Kconfig·Makefile 등록 + ./test/py/test.py PASS

영상에서 보실 것

사람은 mock 만들기 귀찮아 미루던 일. Claude는 5 케이스 + coverage까지 한 번에.

  • 0:03grep test/dm/ → (no tests yet) — 시작점 확인
  • 0:10Write 3번 — test 파일 + Mock 컨트롤러 + Kconfig 등록
  • 0:30DM_TEST 5개 작성 — ready / ecc_pack / 4bit_timeout / 1bit / 3bit
  • 0:50Bash: ./test/py/test.py --bd=sandbox -k nand → 5 PASSED
  • 1:05coverage 매트릭스 — pack_ecc 100%, correct_data 47/55
  • 1:18효과: 보드 없이 host 검증 + 경계조건 4종 망라

Claude 가 실제로 뱉은 결과물

영상이 짧아 캡처 못 한 산출물을 텍스트로 살림
1) 신규 단위테스트 코드
test/dm/nand_denali.c — DM_TEST 5 케이스, 첫 두 개만 발췌
// 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 케이스 동일 패턴
2) sandbox 실행 출력 + coverage
./test/py/test.py --bd=sandbox -k nand
$ ./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 edge
추가 산출물

Claude 가 함께 만들어 준 것: Mock 컨트롤러(test/mock/denali_mock.c), Kconfig 등록(CONFIG_NAND_DENALI_TEST), Makefile 라인. 사람은 5 분 검토만.

강사 강조
Mock·픽스처가 귀찮아 미루던 단위테스트가 1분에 만들어지고 host에서 돌아감. 보드 없이 회귀 검증.
데모 H · V7-H · 6분

문서화 자동 생성

Setup

데모 A와 같은 드라이버. 문서가 0줄임 강조.

Prompt
이 드라이버의 컨트롤러 레지스터 맵을 마크다운 표로(오프셋·비트필드·의미). 'NAND read page' 명령 흐름을 Mermaid 시퀀스 다이어그램으로(CPU/컨트롤러/NAND chip).
Claude 결과

레지스터 맵 표 + Mermaid 시퀀스 다이어그램 + 메모리 트레이닝 흐름도

영상에서 보실 것

사람은 1~2일 걸려 안 하던 일. Claude는 표 + 다이어그램 + 매트릭스 + 성능표를 동시에.

  • 0:03find Documentation/ → 0 — 문서 부재 확인
  • 0:10Read · Grep 3번 — 레지스터 정의 + 데이터시트 참조 추출
  • 0:251) EMIF 레지스터 맵 표 — 오프셋·비트필드·의미
  • 0:402) NAND read page Mermaid 시퀀스 — CPU·DRV·EMIF·CHIP
  • 0:583) ECC 모드 Kconfig 매트릭스 — Hamming/BCH 분기
  • 1:085) probe-time 메모리 트레이닝 흐름도
  • 1:186) 성능 카운터 — read_page 98µs / bbt_scan 480ms

Claude 가 실제로 뱉은 결과물

영상이 짧아 캡처 못 한 산출물을 텍스트로 살림
1) EMIF 레지스터 맵 표
오프셋·비트필드·의미 — 데이터시트 vs 코드 갭 메우는 1차 자료
오프셋레지스터비트의미
0x000DEVICE_ID31:0controller revision (0x4 = V2)
0x010CHIP_RESET0self-clearing soft reset
0x040ECC_ERR_CNT_4BIT31:04-bit Hamming err 누적 카운터
0x044ECC_ERR_CNT_BCH31:0BCH 보정 카운터
0x080INT_STATUS31:0IRQ 디스패치 — bit별 의미는 표 §아래
0x100DMA_DESC_BASE31:0DMA descriptor chain head 물리주소
0x104DMA_BURST_LEN7:0AXI burst length (1/4/8/16)
0x200TIMING_CTRL_031:0tCS / tCH / tCLS / tCLH 인코딩
0x204TIMING_CTRL_131:0tWP / tWH / tRP / tREH 인코딩
0x300OOB_LAYOUT15:0OOB 64B 안의 ECC 영역 시작 오프셋
2) NAND read page Mermaid 시퀀스
CPU · 드라이버 · EMIF · NAND chip — 정상/보정/uncorrectable 분기까지
read_page
98 µs
평균 4KB 페이지
bbt_scan
480 ms
probe 1회
ECC 모드
Hamming · BCH
Kconfig 매트릭스
강사 강조
데이터시트와 코드 사이의 갭을 5분에 메움. 속도가 아니라 '안 하던 걸 하게 됨'.

시간 절감 요약

데모사람Claude Code절감
A 분석30~60분1분 + 검토 5분~85%
C 빌드30분5분~80%
E 단위테스트2~4시간5분 + 검토 10분~90%
H 문서화1~2일 (안 함이 다반사)10분0 → 1

* 이 표는 “대체로 얼마나 빨라지는가”를 보여주는 용도입니다. 메시지는 절감률보다도 검토 시작점이 올라간다는 데 있습니다.

§4

효과 — 생산성과 검토 품질이 어떻게 바뀌나

6분. 핵심은 인원 감축이 아니라 처리 속도와 검토 품질의 재배치입니다.

V8 · 90초

Before / After

V9 · 60초

시간 절감 차트

핵심 메시지

내 일이 사라지는 것이 아니라 내 일의 밀도가 올라갑니다. 반복 작업은 위임하고, 사람은 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분 × 51차 검토는 자동, 사람은 race·hardware 가정만 집중 — 50분
16:30단위테스트·문서화는 다음 주에…테스트 1개 + 레지스터 맵 문서 생성 — 20분

* 회의·디버그·문서·리뷰 슬롯이 재배치됨. 보드·디버거·로직 애널라이저와 만나는 시간은 오히려 늘어남.

팀 효과

회의 → 결정

“이거 어떻게 하지” 회의 시간이 짧아짐. 회의 들어가기 전에 옵션 3개와 trade-off 표가 준비됨. 회의는 결정만.

팀 효과

리뷰 → 깊은 리뷰

1차 검토(스타일·dead code·obvious bug)는 자동. 사람은 race·하드웨어 가정·확장성 같은 진짜 어려운 문제만.

팀 효과

문서 → 부산물

문서화가 별도 작업이 아니라 코드 변경의 부산물. 데이터시트와 코드의 갭이 사라지면 온보딩이 가벼워짐.

누가 가장 빨리 체감하는가

대상

시니어

혼자 읽던 코드를 둘이 읽는 효과. 본인 직관을 더 빨리 diff와 리뷰 코멘트로 바꿀 수 있습니다.
대상

주니어

작은 질문을 바로 던질 상대가 생깁니다. 막히는 시간을 줄이고 리뷰 전에 한 번 더 정리할 수 있습니다.
대상

리더

문서화와 온보딩이 별도 프로젝트가 아니라 코드 변경의 부산물로 붙습니다. 팀 표준화 속도가 빨라집니다.
안 변하는 것 — 솔직한 면
  • · 보드 위에서 마지막 검증은 여전히 사람. AI 가 대신 못 만짐.
  • · 데이터시트 의역·하드웨어 진실(설계자 의도) 은 사람만 압니다.
  • · “일정이 절반”이 아니라 “같은 시간에 더 많은 가치”라는 점을 조직에 정확히 설명해야 합니다.
  • · CLAUDE.md 가 부실하면 Claude 가 환각. 도구의 한계가 아니라 컨텍스트의 한계.
§5

시작하기 + 다음 7일

7분. 라이브에서는 첫 30분만 설명하고, 아래 체크리스트는 사후 참고 자료로 남깁니다.

V11 · 30초

설치 & 첫 명령

복붙용

첫 셸 세션 — 4 줄이면 끝

# 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.

템플릿

CLAUDE.md — 우리팀 사정에 맞춘 5분 작성

# 우리 프로젝트
이 프로젝트는 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 금지)
작성 원칙
  • · 빌드 명령은 무조건 1번 적기 — Claude가 환각으로 만들지 않게.
  • · 하지 말 것도 적기 — “직접 시프트/마스크 금지” 같은 금기.
  • · 리뷰 관점을 적기 — race·endianness·timeout.
  • · 길게 쓰지 말 것. 30~60줄이면 충분, 200줄 넘어가면 오히려 무시됨.
  • · 하위 디렉토리에도 별도 CLAUDE.md 가능 (스코프드).
좋은 한 줄 vs 나쁜 한 줄
ECC: BCH-8 고정. 변경 시 OOB 레이아웃까지 확인.
ECC 잘 처리해줘. ← Claude가 추측함
라이브에서 실제로 말할 3가지만
설치, CLAUDE.md, 첫 작업. 이 세 가지만 끝나면 청중은 내일 아침 바로 자기 저장소에서 첫 실험을 시작할 수 있습니다.

오늘 끝나고 바로 할 3단계

0~5 분

설치 + 로그인

npm i -g @anthropic-ai/claude-code claude login. 사내 프록시면 HTTPS_PROXY 만 export.

5~15 분

CLAUDE.md 5줄 + 1 작업

빌드 명령·하드웨어 제약 5줄만 적고, 가장 무서운 파일을 코드리뷰 시키기. 여기서 “여긴 틀렸어”라고 바로잡는 과정이 컨텍스트를 쌓는 첫 단계입니다.

15~30 분

단위테스트 1개 + 빌드

sandbox 빌드가 도는 폴더에서 test/dm/ 패턴으로 테스트 1개 생성 시키기. ./test/py/test.py 까지 PASS 보면 끝.

이번 주 7일 플랜

Day 1

내 저장소에서 첫 성공

가장 무서운 파일 1개 리뷰, 빌드 1회, 테스트 1회. 성공 경험을 먼저 만듭니다.
Day 3

반복되는 지식 적기

팀이 자주 하는 주의사항 5~10줄을 CLAUDE.md 에 정리합니다.
Day 7

팀 루프로 연결

리뷰 템플릿, 자주 쓰는 프롬프트, 테스트 명령 1개를 팀 공용 절차로 굳힙니다.
오늘 안 해보면 손해

체크리스트

  • npm install -g @anthropic-ai/claude-code
  • ☐ 프로젝트 루트에 CLAUDE.md 5줄 작성
  • ☐ 가장 무서운 파일을 Claude에 코드리뷰 시키기
  • ☐ 단위테스트 1개 작성 시키기 (sandbox)
  • /ide 로 VS Code 연결
  • .claude/commands/ 에 자주 쓰는 명령 1개 저장
자주 막히는 곳

트러블슈팅

  • · 응답이 엉뚱함 → CLAUDE.md 부재 or 오래된 내용. 최신화 5분.
  • · Bash 권한 거부/permissions 에서 정책 조정.
  • · 환각 빌드 명령 → CLAUDE.md 에 “빌드: …” 한 줄 박기.
  • · 토큰 한도/clear 로 컨텍스트 정리, 큰 작업은 나눠서.
  • · 대용량 로그 → 파이프 대신 파일로 저장 후 필요한 구간만 읽히기.
조직 차원

보안 / 데이터

  • · 엔터프라이즈 플랜: 학습 미사용 + 보존정책 통제.
  • · 비밀키·고객 데이터: .env, credentials* 자동 무시 — .gitignore 정비 우선.
  • · NDA 코드: 사내 프록시 + 감사 로그 활성화 후 사용.
  • · 금지 명령: rm -rf, git push --force 는 hook 으로 사전 차단.
  • · 자세한 정책은 보안팀 가이드 따르기.
더 깊이 들어가고 싶을 때
공식 문서

설치·CLI·MCP 레퍼런스. 변경이 빠르므로 분기마다 한 번씩.

사내 슬랙 채널

실패담·노하우 공유. 같은 함정에 두 번 빠지지 말 것. 신규 멤버는 핀 메시지부터.

vibe-project-lesson

자가학습 28모듈. CLAUDE.md → MCP → Subagent 순으로. 한 번에 몰아보지 말고 주 1모듈 페이스 권장.

Q&A

5분. Claude Code · AI 에이전트의 본질에 대한 10 문답. 라이브에서는 5~6 개만 다루고, 나머지는 사후 자료로.

비교

Copilot · Cursor 와 뭐가 다릅니까?

Copilot/Cursor 는 IDE 안의 자동완성·채팅이 중심. Claude Code 는 (1) 터미널에서 자율 루프로 일하고, (2) Read/Edit/Bash/Grep 4종 도구로 빌드·테스트·git 까지 직접 실행하고, (3) CLAUDE.md 로 팀의 규칙을 영구 기억합니다. “옆에서 코드 짜주는 도구” vs “위임할 수 있는 동료”의 차이.

기술

C 임베디드 코드를 정말 잘 이해합니까?

오늘 보신 U-Boot 데모가 답입니다. C/C++ · Kconfig · Makefile · linker script · 디바이스 트리 · RTOS 코드 모두 강함. 매크로·비트필드처럼 전통적 정적분석이 약한 영역에서도 의미적으로 추적합니다.

기술

메모리 제약·실시간성·코딩 표준도 반영합니까?

가능합니다. CLAUDE.md 나 Skill 에 “스택 사용 < 256B”, “IRQ 컨텍스트 sleep 금지”, “MISRA 예외 규칙” 같은 제약을 적어두면 출력이 그 범위 안으로 좁혀집니다. 제약을 안 적으면 일반적인 답이 옵니다 — 모든 건 컨텍스트에 달림.

특성

환각(hallucination) 으로 잘못된 레지스터 사양을 만들지 않나요?

위험은 있습니다. 그래서 두 단계: (1) CLAUDE.md 에 “데이터시트는 docs/ds/*.pdf 만 신뢰” 같은 출처 한정. (2) 변경 후 sandbox/DM 테스트로 즉시 회귀. 환각이 빌드를 깨면 Claude 가 스스로 알아채고 다시 시도합니다 — 자율 루프의 자가 교정.

특성

같은 작업을 두 번 시키면 결과가 똑같습니까?

완전히 같지는 않습니다. LLM 은 본질적으로 비결정적이고, 코드 변경처럼 경로가 여러 개인 작업은 매번 약간 다른 풀이를 냅니다. 그래서 평가 기준은 “같은 결과”가 아니라 “같은 검증 게이트(빌드·테스트·리뷰)를 통과하느냐”. 게이트가 정확하면 비결정성은 문제가 안 됩니다.

특성

컨텍스트가 너무 길어지면 어떻게 처리되나요?

세 가지 장치: (1) 자동 컴팩션 — 오래된 메시지를 요약해 토큰 절약. (2) `/clear` 명령으로 사람이 명시적 리셋. (3) Subagent — 큰 작업을 별도 컨텍스트로 위임해 메인을 깨끗하게. “디렉토리 전체 리팩토링” 같은 일은 Subagent 가 맞습니다.

활용

Plan mode 는 일반 모드와 언제 구분해서 씁니까?

큰 변경(여러 파일 수정·아키텍처 결정·머지 직전 작업) 전에 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 년의 워크플로우를 결정합니다.