토비의 스프링 - 클로드 코드를 이용해 스프링 앱 개발하기 - 라이브

000_개인 감상 정리.md

개인 감상과 정리

• 클로드 코드를 이용해 스프링 앱 개발하기-Live 1 - 토비의 스프링
• 클로드 코드를 이용해 스프링 앱 개발하기-Live 2 - 토비의 스프링
• 클로드 코드를 이용해 스프링 앱 개발하기-Live 3 - 토비의 스프링

개인 감상

LLM 설명이나 사용법은 알고 있던 내용이 많았음.

근데 자잘하지만 유용한 기능 사용법이나, 개발을 하면서 행동을 조정하는 걸 실제로 보는 게 도움이 많이 됨. (경험 기반의 판단과 교정 과정을 관찰하는 것)

토비가 생각하는 AI 개발 실력 키우는 법

• 주기적으로(본인은 한 달, 또는 새 모델 나올 때) 모든 설정(~/.claude)을 리셋하여, AI의 성능·기본 기능 개선에 따라 불필요해진 설정/스킬을 제거하고 재구축하기.
• 공식 문서를 읽고, 적극적으로 사용해보기. 시행착오를 통해 개선하기. 토비는 Claude Code Docs를 특히 강조 — "베스트 프랙티스를 포함해서 온갖 기능에 대한 굉장히 좋은 팁들이 들어 있다. 머릿속에 다 들어 있어야 한다."
• AI를 시키되, 결과를 보고, 안 하는 것(예: 테스트를 안 만듦)과 잘못하는 것(예: 도메인 테스트에 JPA 넣음)을 정의해서 CLAUDE.md에 규칙으로 남기기 — 매번 사람이 명령하지 않아도 지키도록 최적화.
• AI가 어떤 식으로 동작하는지 분석하기. Plan 모드로 AI가 어떤 접근법(버전, 구조 등)을 사용하려 하는지 먼저 확인하고 교정.
• AI가 만든 코드를 반드시 리뷰한다. 사람이 평가하고 AI의 행동을 교정해야 더 나은 품질이 나오고, 사람도 성장할 수 있다. 안 그러면 "AI는 점점 똑똑해져서 일을 잘하지만 여러분이 바보가 됩니다. 그러면 일을 잘 못 시켜요, 점점."
• AI가 작업하는 동안 멍하니 기다리지 말고 다른 활동을 한다 — 병렬 개발, 학습, 다른 세션 작업 등.

AI 에이전트 코딩의 동작 원리

(Andrej Karpathy의 Deep Dive into LLMs like ChatGPT 후반부 내용과 겹치는 부분이 많다고 느낌.)

• AI 에이전트의 구조: 기본 AI(채봇, 멀티모달) + Tools를 조합하여 파일 읽기/쓰기, 셸 실행, 웹 검색 등의 기능을 수행. AI 자체는 지시만 하고, 실제 실행은 Claude Code(하네스)가 담당.
• 에이전틱 루프: 컨텍스트 수집 → AI에게 전송 → AI가 도구 사용 지시 → Claude Code가 실행 → 결과를 AI에게 반환 → 추가 작업 필요 여부 판단 → 반복 또는 종료.
• Tools: LLM이 사용 가능한 도구. 기본 내장(Bash, Read, Write, Edit, Glob, Grep, WebSearch, WebFetch, AskUserQuestion, Plan 등)과 확장(스킬, 서브 에이전트, 에이전트 팀, MCP, 플러그인 등)으로 나뉨.
• 컨텍스트 관리가 중요하다: 매 요청마다 시스템 프롬프트 + 대화 히스토리 + 도구 목록 + 최신 프롬프트가 AI에게 전송된다. 불필요한 정보가 쌓이면 AI 효율이 떨어진다. 이후 나오는 서브 에이전트, 에이전트 팀 등의 기술도 결국 필요한 컨텍스트만 유지하기 위한 방법.
• CLAUDE.md: 프로젝트 또는 유저 레벨에서 AI가 매 세션마다 읽는 문서. 코딩 규칙, 테스트 정책, 참고 문서 경로 등을 기록. AI가 이미 잘하는 것은 빼고 교정이 필요한 것만 유지해야 한다 — 길어지면 오히려 성능 저하.
• 스킬(Skill): 반복되는 프롬프트를 재사용 가능하게 패키징한 것. 본질은 프롬프트 + (선택적) 코드. 3번 이상 반복되면 스킬로 만든다. MCP보다 컨텍스트 소비가 적어 선호.
• 서브 에이전트(Sub-Agent): 별도 세션에서 실행되어 메인 컨텍스트에 대화 내용이 추가되지 않음. 요약된 결과만 반환. 코드 분석, 품질 평가, 리뷰 등 보조 작업에 적합.
• 에이전트 팀(Agent Team): 여러 에이전트를 묶어서 에이전트 간 커뮤니케이션이 가능한 구조. 예: TDD 팀 — Red(실패 테스트 작성), Green(최소 코드로 통과), Refactor(정리) + Team Lead(태스크 분할·할당). tmux로 병렬 시각화 가능. 현재 실험적 기능(CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAM 환경변수 필요).
• 플러그인(Plugin): 스킬, 에이전트, 훅, 커맨드 등 여러 확장 요소를 패키징한 것. 공식 마켓플레이스(anthropics/claude-code-plugins)에서 검증된 것만 선별 설치 권장. 보안 주의 — 플러그인은 로컬 실행 권한을 가지므로 악의적 코드가 포함될 수 있다.

용어

• PRD (Product Requirements Document): "무엇을 만들 것인가"를 정의하는 기능 스펙 문서. 유저 스토리, 기능 목록, UI 방향 등.
• SDD (Spec-Driven Development): PRD를 받아서 "어떻게 구현할 것인가"를 구체화하는 방식. 스펙 → 구현 계획(Phase 분할) → 태스크 리스트 → 단계별 개발 순서로 진행.
• 하네스(Harness): AI 모델을 감싸고 도구·컨텍스트·권한 관리 등을 제공하는 실행 환경. Claude Code 자체가 하네스.
• 에이전틱 루프(Agentic Loop): 컨텍스트 수집 → AI 판단 → 도구 실행 → 결과 확인을 반복하는 에이전트의 작업 사이클.

문서 관리

• Plan 모드의 계획은 세션이 끝나면 사라지므로, 프로젝트 루트에 마크다운 파일로 명시적으로 저장한다.
• 실제 사용된 파일: spec.md(기능 스펙), plan.md(구현 계획), tasks.md(체크박스 태스크), CLAUDE.md(코딩 규칙).
• CLAUDE.md에 이 문서 경로들을 참고 문서로 기록해두면 다음 세션에서도 AI가 참조 가능. "다음에 프롬프트 쓸 때 tasks.md를 참고해서 뭐를 하세요, 이런 거 할 필요가 없는 거죠."
• 장기 프로젝트에서는 docs/ 폴더에 날짜나 시리얼 번호를 붙여 스펙 문서를 누적 관리.

워크플로우 예시

1회차: 맨땅에서 Spring Boot 프로젝트 만들기

기술 스택: Spring Boot 4.x / Java 25 / Gradle Kotlin DSL / JPA + H2 / Next.js (프론트) / Ghostty + IntelliJ

1. 환경 리셋 (~/.claude 삭제) → 빈 폴더에서 시작
2. Plan 모드로 AI의 기본 판단 확인 → Boot 3.5 + Java 17~21로 하려는 걸 발견 → 취소
3. "스프링 이니셜라이저를 이용해서 Boot 4 최신 + Java 25 프로젝트 생성해줘" → Initializr API 경유가 핵심 (AI가 직접 Gradle 파일 만들면 버전 호환이 꼬임)
4. gradle build로 환경 검증 → IntelliJ에서 구조 확인
5. PRD 작성 (Apple Reminders 클론) → SDD로 변환 (Phase 분할) → Task 리스트 67개 생성
6. 단일 엔티티(ReminderList)로 전 레이어 한 사이클 — 이게 핵심 전략. AI 가능한 테스크 단위로 쪼갬.
   (영상은 거기서도 레이어별로 쪼개는데, 왜?: AI가 초반 참고할 기존 없으면 원하는 결과가 나오지 않아서 조정을 위함.)
   • 도메인 엔티티 → 단위 테스트 (JPA 의존 금지로 교정)
   • 서비스 (인터페이스 분리, ports.input 패키지, Default 접두사) → 통합 테스트 (Mock 아닌 @SpringBootTest로 교정)
   • 컨트롤러 + OpenAPI 스펙 → MockMvc 테스트
   • 각 단계에서 발견한 교정사항을 CLAUDE.md에 기록
7. 컨벤션 확립 후 나머지 엔티티 + 프론트엔드(Next.js) 일괄 개발
8. 라이브 데모 → 버그 수정 → 코드 리뷰 → 이슈 기반 개선

2회차: 도구 확장 (스킬 → 서브 에이전트 → 에이전트 팀)

1. 에이전틱 루프 동작 원리 설명 (AI는 채봇, Claude Code가 도구 실행)
2. "가지고 있는 도구가 뭔지 알려줘" → 기본 내장 도구 파악 (Bash, Read, Write, Glob, Grep, WebSearch 등)
3. 공식 플러그인 마켓플레이스 설치 → 최소한만 선별 (Ralph Loop, Skill Creator, Exploratory Output Style, Plugin Dev)
4. 스킬 제작: Spring Initializr 스킬 — AskUserQuestion 도구로 버전/디펜던시 선택 UI 구현. 이후 /spring-initializer로 재사용.
5. 서브 에이전트 제작: 코드 품질 감사 에이전트 — 별도 세션에서 실행되어 메인 컨텍스트 오염 없음. 가독성/아키텍처/테스트/보안 분야별 점수(A~F) 리포트.
6. 에이전트 팀 구성: TDD(Red/Green/Refactor + Lead) — tmux로 병렬 시각화. 문자열 계산기 예제로 데모. (Refactor가 매 사이클이 아닌 마지막에만 실행되는 문제 발견 → 프롬프트 교정 필요)
7. 실전 조합: 품질 감사 → 이슈 추출 → TDD 팀으로 수정 (실패 테스트 먼저 → 수정 → 리팩터)
8. 멀티 모델 협업: Codex에게 리뷰 위임 → Claude와 토론 → 합의된 개선만 적용

토비의 사용 팁

컨텍스트·워크플로우

• 컨텍스트 관리를 항상 신경 쓰기. 한 번에 큰 작업을 하지 않기. 파일(spec.md, plan.md, tasks.md)을 사용해서 중간 결과, 계획, 상태 등을 저장.
• 반복되는 작업은 스킬, 에이전트 등의 기능을 사용하여 최적화.
• Plan 모드로 AI의 기본 판단을 먼저 확인하고 교정. (토큰 낭비 방지 + 방향 확인)
• 초반에는 큰 작업보다 레이어(도메인 → 서비스 → 컨트롤러) 단위로 주의 깊게 보면서 AI를 교정.
• 어느 정도 초반 코드와 규칙이 쌓였으면(AI가 코드를 보고 따라 할 수 있을 만큼) 큰 작업을 시키기.

코드 품질

• 코드 작성 시 테스트 작성과 실행을 필수로 하도록 교정하기. (기본적으로 테스트를 만들어도 실행을 안 하거나, 아예 안 만들려는 경향이 있음)
• AI가 의도한 도구가 아닌 다른 방법을 쓰려 할 때(예: Initializr 대신 직접 Gradle 작성) 적절하게 중단하고 교정.

도구 이해

• Claude의 동작을 보면 매번 특정 도구를 사용하는 걸 볼 수 있다. (예: Bash, Read, Read 등)
• 도구의 동작 방식을 이해하면 시간을 아낄 수 있다. 각 도구가 어떤 특성을 가지는지 알면, 명시적으로 지정하거나 조합하여 훨씬 효율적으로 작업 가능.
  • 예: Explorer 에이전트는 코드 분석에 특화되어 있는데, AI가 알아서 안 쓰고 Glob/Grep만 쓸 때가 있다.
  • 예: 서브 에이전트는 병렬로 여러 개를 동시 실행 가능.
  • 예: AskUserQuestion 도구를 스킬에 넣으면 텍스트 입력 대신 탭 선택 UI를 만들어줌.

"가지고 있는 도구가 뭔지 알려줘"를 첫 번째로 실행하여 현재 사용 가능한 도구를 파악하는 것이 출발점.

편의 기능

• /permissions로 안전한 명령(./gradlew, ls, find 등)을 사전 허용. 설정이 쌓이면 위험한 작업 외에는 거의 확인 없이 동작.
• /ide로 IntelliJ/VS Code와 연동하여 코드 변경 승인을 IDE의 diff 뷰에서 처리.
• claude -w 워크스페이스이름으로 Git Worktree 자동 생성. 병렬 브랜치 작업에 유용. Ctrl+C로 빠져나가면 워크트리 설정 자동 정리.
• 상태 표시줄(/status-bar)에 컨텍스트 사용량(%), Git 브랜치, 모델명 등 표시. 컨텍스트가 차면 clear context 또는 compact 시점 판단에 활용.
• 느낌표(!) 접두사로 AI를 거치지 않고 셸 명령 직접 실행 가능. 예: !idea .

플러그인

• /plugins로 플러그인 확인/설치/활성화. 한 번에 많이 설치하지 말고 필요한 기능을 조금씩 추가. 컨텍스트 관리를 위해 필요한 것만 활성화.
• 공식 마켓플레이스: github.com/anthropics/claude-code-plugins
• 추천 목록:
  • Exploratory Output Style — 대화 중 인사이트 팁 표시 (무조건 켜놓을 것)
  • Skill Creator — 스킬 제작 지원
  • Ralph Loop — 실무 워크플로우
  • Plugin Dev — 플러그인 개발용
• LSP, Figma 등 고급 플러그인은 처음부터 필요 없음. 나중에 필요할 때 추가.

005_토비의 Claude Code 활용법 정리.md

토비의 Claude Code 활용법 정리

AI 에이전트 코딩의 동작 원리

• Claude(AI 모델)는 지금도 채봇이다. 파일을 만들거나 명령을 실행하는 능력이 없다. 텍스트를 받아서 텍스트를 돌려줄 뿐.
• Claude Code(하네스)가 도구(Tool)를 가지고 있다. 사용자가 프롬프트를 입력하면 Claude Code가 "내가 이런 도구들을 가지고 있어"라는 정보와 함께 AI에게 전송한다.
• AI는 "이 도구를 써서 이 작업을 해라"라고 지시만 한다. 실제 실행은 Claude Code가 사용자의 로컬 환경에서 수행하고, 그 결과를 다시 AI에게 보내서 다음 지시를 받는다.
• 이 컨텍스트 수집 → AI 지시 → 도구 실행 → 결과 반환 → 반복 사이클을 "에이전틱 루프"라고 부른다. AI가 "작업이 완료됐다"고 판단하면 루프가 끝난다.
• Claude Code 화면에서 동그란 아이콘과 함께 표시되는 각 항목(Bash, Read, Explorer 등)이 AI가 지시하고 Claude Code가 실행한 도구 호출 하나하나다. 이걸 읽을 수 있으면 AI가 지금 뭘 하고 있는지 파악할 수 있다.

기본 내장 도구

"내가 가지고 있는 도구가 뭔지 알려줘"라고 물어보면 현재 상태의 도구 목록을 볼 수 있다:

도구	기능
Bash	셸 명령 실행 (어떤 커맨드라인 명령이든)
Read	파일 읽기
Write	파일 쓰기/덮어쓰기
Edit	파일 내 문자열 치환
Glob	패턴 기반 파일 검색
Grep	파일 내용 텍스트 검색
WebSearch / WebFetch	웹 검색·페이지 내용 가져오기
Skill	스킬 실행
Agent	서브 에이전트 실행
Plan	Plan 모드 진입·관리
Task	태스크 리스트 관리
Browser	Chrome 확장 통한 브라우저 제어
AskUserQuestion	사용자에게 탭 형태 선택지 제시
Git	Git 작업

명시적으로 어떤 도구를 쓰라고 지시하면 더 나은 결과가 나오는 경우가 많다. 예: "Explorer 에이전트를 사용해서 분석해줘"라고 하면 Glob/Grep만 쓰는 것보다 훨씬 깊이 있는 분석을 한다.

컨텍스트 구조

프롬프트를 보낼 때마다 AI에게 실제로 전송되는 전체 내용:

시스템 프롬프트 (Claude Code 팀이 세팅한 고정 규칙)
  +
대화 히스토리 (이전 모든 사용자↔AI 메시지 쌍, 세션 내 누적)
  +
도구 목록 (기본 도구 + 플러그인 + MCP + 스킬 + 에이전트)
  +
최신 프롬프트 (방금 입력한 내용)

• 대화 히스토리가 길어지면 AI 효율이 떨어진다. 현재 작업과 무관한 과거 대화가 쌓이면 AI가 혼란스러워한다.
• 도구 목록도 MCP를 많이 설치하면 비대해진다. 스킬은 상대적으로 가볍다.
• 컨텍스트 사용량은 상태 표시줄로 확인 가능. 많이 차면 clear context(초기화) 또는 compact(요약 압축).

---

AI 개발 실력 키우는 법

• 주기적으로 모든 설정을 리셋한다.

  • 토비는 한 달 주기 또는 새 모델 출시 시 ~/.claude를 통째로 삭제하고 재구축한다.
  • 모델이 좋아지면 기존 스킬·설정이 불필요하거나 오히려 방해가 되기 때문.
  • 이전에 확신 있던 것만 다시 넣으면서 "여전히 유효한가"를 점검.

• 공식 문서를 읽고, 적극적으로 사용해본다.

  • Claude Code 공식 Docs에 베스트 프랙티스, 기능 설명, 팁이 들어있다. 한국어 번역도 제공.
  • 마크다운으로 다운받아 AI에게 통째로 넣고 질문하는 것도 유효.
  • 시행착오를 통해 개선하기.

• AI에게 시키되, 결과를 보고, 안 하는 것 / 해야 하는 것을 정의한다.

  • 그걸 CLAUDE.md나 스킬에 반영해서 다음부터 사람이 매번 명령하지 않아도 AI가 자동으로 따르도록 최적화.
  • 한 사이클 돌려서 AI의 기본 습관을 파악 → 원하는 스타일로 교정 → 가이드에 기록 → 이후에는 그 스타일대로 알아서 하게 만듦.

• AI가 어떤 식으로 동작하는지 분석한다.

  • Plan 모드로 AI가 어떤 접근법을 쓰려는지 먼저 확인.
  • 화면에 뜨는 도구 호출 아이콘을 읽으면서 AI의 의사결정 과정을 파악.
  • 도구를 직접 지정해서 시키면 더 나은 결과가 나오는 경우가 많다.

• AI가 만든 코드를 반드시 리뷰한다.

  • 코드 품질 에이전트 + 멀티 모델 토론(Claude + Codex)으로 품질을 끌어올린다.
  • "AI는 점점 똑똑해지지만 여러분이 바보가 된다. 그러면 일을 점점 잘 못 시킨다."
  • AI가 작업하는 동안 놀지 않는다. 병렬 세션 활용, 다른 기능 개발, 또는 Claude Code 학습.

---

AI 활용 원리 & 방법

AI는 메모리가 없다

세션이 끝나면 대화 내용이 사라진다. 오토 메모리가 어느 정도 기억해주긴 하지만 신뢰할 수 없다. 따라서 파일로 명시적으로 남겨야 컨텍스트가 사라져도 작업을 이어갈 수 있다:

파일	용도	특성
CLAUDE.md	AI가 항상 지켜야 할 코딩 관례·규칙	매 요청 시 자동 로딩됨 (컨텍스트 앞에 붙음)
plan.md	구현 계획 (Phase 분할, 기술 결정)	세션 간 유지, "참고해서 진행해줘"로 연결
tasks.md	체크박스 태스크 리스트	AI가 진행 상황 추적하며 체크
spec.md / prd.md	기능 스펙 / PRD	기획 문서
openapi.yml	API 스펙	프론트엔드 개발 시 "이 스펙 참고해서 만들어줘"
docs/fix-001.md 등	리뷰 이슈, 수정 이력	번호 매겨서 누적 관리

핵심: Plan 모드의 결과는 세션이 끝나면 사라진다. 중요한 계획은 반드시 plan.md로 저장해야 한다.

Plan 모드를 먼저 거친다

Shift+Tab으로 Plan 모드를 켜면 AI가 코드를 생성하지 않고 계획만 보여준다:

• AI가 어떤 버전·방식을 쓰려는지 파악 (예: Claude는 기본적으로 Spring Boot 3.5 + Java 17~21을 제안 — 원하는 4.x와 달랐음)
• 계획을 반복적으로 다듬을 수 있음 ("이건 빼고, 이건 바꾸고, 이건 좀 더 생각해봐")
• 잘하는 사람은 1시간 반 중 1시간을 플랜에, 30분을 실제 코드 생성에 쓴다

한 방에 다 시키지 않는다

AI는 기본적으로 작업 범위를 크게 잡으려 한다. 이를 제어하는 방법:

1. 단일 단위로 한 사이클을 먼저 돌린다. 예: 엔티티 하나로 도메인→리포지토리→서비스→컨트롤러 전 레이어를 만들어봄 → AI의 기본 습관 파악 → 교정 사항을 CLAUDE.md에 기록.
2. 이후에는 나머지를 일괄로 시켜도 된다. 컨벤션이 확립되었으므로.
3. TDD 사이클을 활용하면 AI가 작은 단위로 작업하도록 자연스럽게 강제할 수 있다.

작업 지시의 구체성 수준

상황	접근
빠른 프로토타입, 일회성	"만들어줘" → 즉시 개발
일반 작업	Plan 모드로 확인 → 승인 후 실행
체계적 프로젝트	PRD 작성 → 리뷰 후 개발
장기 프로젝트, 팀 협업	SDD 스타일: 스펙 → 구현 계획 → 태스크 리스트 → 단계적 개발

검증을 AI에게 시킨다

코드를 만들고 끝내면 안 된다. AI에게 검증까지 포함시켜야 한다:

• "테스트도 만들고 실행해줘"
• "Gradle 빌드 돌려서 문제 없는지 확인해줘"
• "curl로 API 테스트해줘"
• Acceptance Criteria를 Phase별로 정해두면 AI가 그 조건을 만족할 때까지 자체 수정함.

---

CLAUDE.md — AI가 항상 지켜야 할 규칙 저장소

프로젝트 루트에 위치. 모든 AI 요청 시 자동으로 컨텍스트 앞에 붙어 전송된다.

넣어야 하는 것

• AI가 틀리거나 빠뜨리는 것에 대한 교정 규칙
  • 예: "기능 구현 시 테스트도 같이 만들고 실행할 것"
  • 예: "도메인 단위 테스트에 JPA 의존 금지"
  • 예: "서비스 테스트는 @SpringBootTest 통합 테스트로 (Mock 금지)"
• 프로젝트 고유의 아키텍처 결정
  • 예: "서비스 인터페이스는 ports.input 패키지, 구현 클래스는 Default 접두사"
• 스타일 규칙
  • 예: "커밋 메시지는 한글로"
  • 예: "테스트 @DisplayName은 한글로"
• 참고 문서 경로
  • 예: tasks.md, plan.md 위치

넣지 말아야 하는 것

• AI가 시키지 않아도 이미 잘하는 것 (예: 엔티티에 @Entity 붙이기, 생성자 주입, @Transactional 사용)
• 이미 코드에 반영 완료되어 반복될 일 없는 지시사항
• 너무 장황한 내용 → 양이 많으면 AI가 일부를 무시해버린다

관리 원칙

• 개발하다가 "이 부분은 앞으로 AI가 계속 기억했으면 좋겠다"는 게 나오면 즉시 CLAUDE.md 업데이트 후 다음 진행.
• 주기적으로 정리하여 불필요한 항목 제거. 모델이 발전하면 기존에 교정이 필요했던 것을 이제는 알아서 할 수도 있다.
• Claude Code 개발팀도 이 원칙을 항상 강조한다.

유저 레벨 vs 프로젝트 레벨

위치	범위	예시
~/.claude/CLAUDE.md	모든 프로젝트에 적용	언어 설정, 전역 스타일 규칙
프로젝트/.claude/CLAUDE.md 또는 프로젝트/CLAUDE.md	해당 프로젝트만	아키텍처 결정, 도메인 규칙

프로젝트 레벨은 Git에 커밋하여 팀원과 공유 가능.

---

스킬(Skill) — 반복 작업을 재사용 가능하게 패키징

정의

반복되는 프롬프트를 저장해서 슬래시 명령이나 자연어로 실행할 수 있게 만든 것. 본질은 프롬프트 + (선택적) 코드. 함수를 만들어 재사용하는 것과 같은 개념.

만드는 기준: 3번 이상 반복되는 작업이면 스킬로 만든다.

특징

• 메인 세션에서 실행된다 (대화 히스토리에 과정이 추가됨).
• 도구 목록에서 차지하는 공간이 MCP보다 가볍다 (컨텍스트 소비 적음).
• 파일 기반이라 직접 수정이 쉽다.
• 유저 레벨에 설치하면 어떤 프로젝트에서든 사용 가능.
• AI가 프롬프트 내용을 보고 관련 스킬을 자동 매칭하여 실행하기도 한다.

만드는 법 (예시 — Spring Initializr 스킬)

Skill Creator 플러그인 사용:

/skill-creator 스프링부트 프로젝트를 생성하는 스킬을 만들어줘.

- 스프링 이니셜라이저를 이용해서 진행
- 스프링부트 버전: AskUserQuestion 도구로 선택 UI
- 자바 버전: 선택 가능하게
- Gradle Kotlin DSL 고정 (물어보지 않음)
- 아티팩트: 현재 폴더명 디폴트, 수정할지 확인
- 패키지: toby.ai.{아티팩트} 디폴트, 수정할지 확인
- 디펜던시: Initializr에서 목록 가져와 그룹별 다중 선택

사용법

• /spring-initializer (슬래시 명령)
• 또는 "스프링 프로젝트 만들어줘" → AI가 스킬 자동 매칭

한 번에 완성할 필요 없다. 만들고 계속 고치면 된다. 기존 스킬을 Skill Creator에게 "이렇게 바꿔줘"라고 하면 수정해준다.

다른 활용 예

• PRD 생성 스킬 (옵션들을 물어보고 체계적으로 만들어줌)
• TDD 팀 구성 스킬 (에이전트 팀을 만들고 실행하는 과정을 자동화)
• Codex 위임 스킬 (다른 AI 모델에게 작업을 보내고 결과를 받아옴)

---

서브 에이전트(Sub-Agent) — 컨텍스트 오염 없는 독립 작업

정의

스킬과 비슷하게 반복 작업을 패키징하지만, 별도 세션에서 실행되어 메인 컨텍스트에 대화 내용이 추가되지 않는다. 요약된 결과만 반환.

스킬과의 핵심 차이

	스킬	서브 에이전트
실행 세션	메인 (히스토리에 추가됨)	별도 (메인 컨텍스트 오염 없음)
결과 전달	전체 과정이 히스토리에 남음	요약된 결과만
적합한 용도	개발 흐름의 일부	분석, 리뷰, 감사 등 보조 작업
병렬 실행	불가	가능 (백그라운드)

어떤 작업을 에이전트로 만들어야 하나

메인 개발 흐름과 직접 관련 없고, 수행 과정이 이후 컨텍스트에 남을 필요가 없는 작업.

• 코드 품질 분석·평가
• 보안 취약점 스캔
• 코드 리뷰
• 프로젝트 구조 분석

만드는 법 (예시 — 코드 품질 감사)

/agent → 새로운 에이전트 만들기 → 유저 레벨

코드를 분석해서 코드 품질을 평가하고 리포트 생성.
가독성, 아키텍처, 테스트, 보안 등 여러 분야로 분석.
각각 A~F 등급.

실행: "코드 품질을 분석해줘" → AI가 도구 목록에서 해당 에이전트를 자동 매칭하여 백그라운드 실행. 메인 세션에서 다른 작업 계속 가능.

결과 예시: 종합 81점(B), N+1 쿼리 지적, 아키텍처 위반 탐지, 개선 권고 등.

---

에이전트 팀(Agent Team) — 에이전트 간 협업

정의

여러 서브 에이전트가 팀으로 구성되어 서로 커뮤니케이션하며 협업. 일반 서브 에이전트는 메인↔에이전트 단방향이지만, 에이전트 팀은 에이전트 간 직접 통신이 가능.

활성화 (실험적 기능)

// ~/.claude/settings.json
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAM": "1" } }

주의: ENABLE이 아닌 EXPERIMENTAL이 올바른 키. AI에게 설정을 시키면 잘못 넣는 경우가 있었다 (직접 확인 필요).

예시 — TDD 팀

/create-team TDD를 에이전트 팀으로 구성해줘.

- Red: 실패하는 테스트 작성 → 실행해서 실패 확인 (빌드 실패가 아닌 테스트 실패)
- Green: 테스트를 성공시키기 위한 최소한의 코드만 작성
- Refactor: 리팩터링
- Team Lead: 요구사항 → 태스크 분할 → 각 에이전트에 순차 할당

tmux로 화면을 분할하면 각 에이전트가 독립 터미널 창에서 동시에 작업하는 것을 시각적으로 확인 가능.

주의사항

• 라이브에서 Refactor가 매 사이클이 아닌 마지막에 한 번만 실행되는 문제 발생 → 프롬프트를 다듬거나 스킬로 고정하여 "매 태스크 끝날 때마다 Refactor 수행"을 명시해야 함.
• 한번 잘 만들면 스킬로 저장해서 이후 재사용.

---

실전 워크플로우 — 전체 개발 흐름 요약

Phase 0: 환경 준비

1. ~/.claude 리셋 (주기적)
2. 공식 플러그인 최소 설치 (아래 "플러그인 설치 원칙" 참조)
3. 터미널 세팅, 상태 표시줄 구성

Phase 1: 프로젝트 생성

1. 빈 폴더 생성
2. Plan 모드로 AI의 기본 판단 확인 → 교정
3. Spring Initializr 경유하여 프로젝트 생성 (스킬로 만들어두면 이후 반복 없음)
4. 빌드로 환경 검증
5. IDE에서 의존성·패키지 구조 확인
6. Git 초기화 + 원격 리포지토리 생성

Phase 2: 기획 문서 작성

1. PRD(기능 스펙) 생성 → 리뷰 후 보완
2. SDD 변환: Phase를 나누어 가장 단순한 것부터 시작하도록
3. Task 리스트 생성: tasks.md에 체크박스 형태로

Phase 3: 코딩 컨벤션 확립

단일 단위로 전 레이어 한 사이클 → AI의 기본 습관 파악 → 교정 → CLAUDE.md 기록. 이 과정에서 AI가 잘하는 것은 CLAUDE.md에 넣지 않는다.

Phase 4: 본격 개발

1. tasks.md 기반으로 일괄 개발 ("이 항목들 개발하고 완료되면 체크해줘")
2. 호환 문제는 AI가 웹 검색으로 자체 해결 (한 번 해결하면 반복하지 않음)
3. 프론트엔드까지 포함한 일괄 진행
4. 라이브 앱 데모 → 버그 발견 시 자연어로 설명하면 AI가 원인 분석·수정

Phase 5: 품질 향상 사이클

코드 품질 감사 에이전트 실행 (서브 에이전트, 백그라운드)
  ↓
리포트에서 이슈 추출 → GitHub Issue 또는 로컬 태스크로 등록
  ↓
이슈 하나씩 TDD 팀으로 수정
  · Red: 문제를 재현하는 실패 테스트 작성
  · Green: 수정 코드 작성
  · Refactor: 정리
  ↓
멀티 모델 토론 (선택)
  · Codex에게 리뷰 위임 → Claude에게 "동의하냐? 반박해봐"
  · 합의된 개선 사항만 적용
  ↓
커밋

---

플러그인 설치 원칙

• 절대 금지: 한꺼번에 수십~수백 개 설치. "에이전트 150개 + 스킬 1500개 설치"류는 컨텍스트를 지저분하게 만들고 성능을 떨어뜨린다.
• 공식 마켓플레이스 (github.com/anthropics/claude-code-plugins)에서 선별 설치.
• 최소 권장 목록:

플러그인	용도
Ralph Loop	실무 워크플로우
Skill Creator	스킬 제작
Exploratory Output Style	인사이트 팁 표시 — 무조건 켜놓을 것
Plugin Dev	플러그인 개발용

• 나머지(LSP, Figma 등)는 필요할 때만.
• 보안 주의: 플러그인은 Claude Code의 로컬 실행 권한을 가진다. 악의적 프롬프트가 심어진 플러그인은 컴퓨터 정보를 빼낼 수 있다. 검증된 것만 사용하거나 직접 만들 것.
• Context7(최신 문서 MCP)은 WebSearch/WebFetch 기능 추가 이후 불필요. 웹 검색이 더 빠르고 정확하며, Context7은 컨텍스트를 많이 잡아먹는다.

---

멀티 모델 협업 (Claude + Codex)

• Claude Code: 일상 개발 메인. 프로젝트 초반부터 끝까지 담당.
• Codex: 알고리즘·로직 분석, 코드 리뷰에 강점. 맨땅에서 시작하면 초반이 힘들다 (3~5배 더 잔소리 필요).
• 스킬로 Codex 호출을 패키징할 수 있다: "Codex를 호출해서 요청한 작업을 수행하고 결과를 돌려받는 스킬을 만들어줘" → "Codex Delegator" 스킬.
• 활용 흐름: Claude에서 개발 → Codex에게 리뷰 위임 → Claude에게 "Codex 의견에 동의하냐, 반박해봐" → 두 모델 토론 → 합의된 것만 적용.

---

기타 실전 팁

권한 관리 (Permissions)

• 안전한 명령(./gradlew, ls, find 등)은 Permissions에 Allow List로 사전 등록 → 매번 승인 불필요.
• 유저 레벨 settings.json에 넣으면 모든 프로젝트에 적용.
• 격리된 환경(Docker)에서는 전체 허용 모드(--dangerously-skip-permissions)도 가능.

Git Worktree 병렬 개발

claude -w review로 워크트리 자동 생성. 별도 브랜치에서 독립 작업 후 Ctrl+C로 빠져나가면 설정 자동 정리. 동시에 여러 기능을 병렬로 개발하거나, 한쪽에서 리뷰하면서 다른 쪽에서 개발 진행.

IDE 연동 (IntelliJ SLADE)

Claude Code와 연결하면 코드 변경 승인을 IDE의 diff 뷰에서 수락/거부 가능. Accept Edits를 끄면(Shift+Tab) 파일 수정마다 확인 거침 → 학습·검증에 유용.

상태 표시줄

/status-bar 유저, 상대 폴더, 모델, Git 브랜치, 컨텍스트 사용량, 시간
상대 경로가 길면 중간 폴더 한 글자 축약

특히 **컨텍스트 사용량(%)**이 보이는 것이 중요 — clear/compact 시점 판단.

알림(Notification) 훅

Claude Code가 작업 완료 또는 응답 대기 시 알림을 보내도록 Stop/Notification 훅 설정. 여러 세션 동시 운용 시 필수. 밥 먹으러 가서도 폰의 Claude 앱(리모트 컨트롤)으로 상태 확인·명령 가능.

프론트엔드 디자인 수정

디자인이 마음에 안 들면: Google Stitch 등으로 시안 생성 → 캡처 → "이 디자인 스타일로 바꿔줘". 반응형 웹도 "모바일에서도 잘 보이도록" 한마디면 처리.

010_Toby - 클로드 코드를 이용해 스프링 앱 개발하기 - Live 1.md

1회차 — Claude Code로 Spring Boot 개발하기: 맨땅에서 시작

원본: https://www.youtube.com/live/gdg4DBcakIg?si=-5n5Qq_EDlk5Lbw_ 발표자: 토비 (이일민)

개요

Claude Code를 이용한 바이브 코딩(입코딩, 말로 하는 코딩)으로 Spring 애플리케이션을 개발하는 과정을 처음부터 보여주는 라이브. 모든 설정을 리셋한 맨땅 상태에서 시작하여, Apple Reminders 앱의 웹 버전 클론을 만든다.

기술 스택

구분	기술	비고
백엔드	Spring Boot 4.0.x (Spring Framework 7.x)	AI 학습 범위 밖이라 에러 빈발
언어	Java 25	Boot 4 + Gradle 9 조합에 필요
빌드	Gradle (Kotlin DSL)	Groovy DSL 대신 선택
ORM	Spring Data JPA
DB	H2 (인메모리)	개발 단계
프론트엔드	Next.js 최신 버전	AI에게 완전 위임 (바이브 코딩)
AI 도구	Claude Code (Opus 4.6)	$200 MAX 플랜
보조 AI	OpenAI Codex	코드 리뷰, 로직 분석 보조
IDE	IntelliJ IDEA 2025.3.3	코드 리뷰·변경 확인용
터미널	Ghostty	네이티브 빌드, 화면 분할, Claude Code 팀도 사용
형상관리	Git + GitHub (gh CLI)

전체 흐름

환경 리셋 (/.claude 삭제)
  ↓
프로젝트 폴더 생성 (toby-reminder)
  ↓
Plan 모드로 AI의 기본 판단 확인
  ↓
Spring Initializr 경유하여 프로젝트 생성
  ↓
Gradle 빌드로 환경 검증
  ↓
Git 초기화 + GitHub 리포지토리 생성
  ↓
PRD(기능 스펙) 작성
  ↓
SDD(구현 계획) 변환 → Phase 분할
  ↓
Task 리스트 생성 (67개 체크박스)
  ↓
단일 엔티티(ReminderList)로 전 레이어 한 사이클
  · 도메인 엔티티 → 단위 테스트
  · 리포지토리
  · 서비스 (인터페이스 분리) → 통합 테스트
  · 컨트롤러 + OpenAPI 스펙 → MockMvc 테스트
  ↓
코딩 컨벤션을 CLAUDE.md에 기록
  ↓
나머지 엔티티(Reminder 등) 일괄 개발
  ↓
프론트엔드(Next.js) 셋업 + Phase 2~5 일괄 개발
  ↓
라이브 앱 데모 + 버그 수정
  ↓
코드 리뷰 요청 → 이슈 기반 개선

1단계: 환경 리셋과 초기 세팅

리셋 철학

토비는 ~/.claude 아래 축적된 모든 설정·플러그인을 한 달 주기(또는 새 모델 출시 시)로 전부 삭제하고 재구축한다.

• 이전에 확신 있던 설정만 다시 넣으면서 "여전히 유효한가 / 더 나은 방법이 있는가"를 점검.
• 모델이 업데이트되면 기존 프롬프트나 스킬이 무용지물이 되거나 오히려 방해가 되는 경우가 빈번하기 때문.
• 불필요한 것이 쌓이면 컨텍스트가 비대해져서 AI 성능이 떨어진다.

"플러그인도 없고, 설정도 없고, 진짜 맨땅인 상태입니다."

터미널 환경

Ghostty 터미널을 사용한다. 화면을 좌우 분할하여 한쪽에서 Claude Code를 실행하고, 다른 쪽에서 별도 작업(다른 프로젝트, 문서 확인 등)을 동시에 진행한다.

Ghostty 커스텀 포인트: 한글 폰트 변경, 패인 구분선 강조 색상, 기타 세부 설정. Claude Code 개발팀 자체도 Ghostty를 사용한다고 언급.

2단계: Spring Boot 프로젝트 생성

AI가 기본으로 만드는 버전 확인 (Plan 모드)

먼저 Plan 모드를 켜고 "Spring Boot, JPA, H2를 사용하는 프로젝트를 구성해줘"라고 요청한다. 코드를 생성하지 않고 계획만 보여달라는 것.

결과: Claude는 Spring Boot 3.5 + Java 17~21 조합을 기본으로 제안했다. 이것이 현재 AI의 학습 데이터 기준선이다. 원하는 4.x와 다르므로 이 계획은 취소한다.

"얘가 과연 기본적으로 현재 버전의 클로드는 뭘 어떻게 사용할 것인가를 먼저 확인하는 거예요."

Spring Initializr 경유 (핵심)

AI에게 "스프링 프로젝트 만들어줘"라고만 하면 자체적으로 Gradle 파일을 직접 작성하려고 시도한다. 이렇게 하면 Boot 4에서 필요한 Gradle 9 래퍼 버전, Java 25 호환성 등이 꼬여서 결국 3.x로 다운그레이드하는 등 엉망이 된다.

해결책: "스프링 이니셜라이저를 이용해서"라는 문구를 반드시 넣는다.

실제 프롬프트:

스프링부트 4의 최신 버전, JPA, H2, Lombok을 사용하는 프로젝트를
스프링 이니셜라이저를 이용해서 생성해줘.
Gradle Kotlin DSL을 사용하고,
패키지: toby.reminder, 프로젝트명: toby-reminder, 자바 25

이렇게 하면 Claude Code가 start.spring.io API를 curl로 호출하여 정식 프로젝트를 다운받는다.

• Claude가 start.spring.io에 접근 → 4.0.3이 최신임을 확인.
• Initializr API를 호출하여 프로젝트 ZIP 다운로드 → 압축 해제.
• Spring 팀이 세팅해놓은 최적의 구성을 그대로 받아오므로 Gradle 버전, Java 호환성 등이 자동으로 맞춰진다.

"스프링 이니셜라이저를 이용해서 만들면 되니까. 거기서 최선의 스프링 개발자들이 세팅해놓은 최선의 걸 가지고 만들잖아요."

빌드 검증

프로젝트 생성 직후 ./gradlew build를 실행하여 환경 정합성을 확인한다. 8080 포트 충돌 등 사소한 문제는 AI가 알아서 프로세스를 찾아 죽이고 재시작한다.

"기본 Gradle을 풀로 한번 돌려봅니다. 요거 잘 돼야 모든 설정이나 환경이 잘 맞는지 확인하는 거죠."

IntelliJ에서 확인

!idea . 명령으로 IntelliJ를 열어 AI가 만들어놓은 코드를 직접 눈으로 확인한다.

• 패키지 구조가 요청대로 되었는지
• Boot 4.x + Spring 7.x 의존성이 잡혔는지
• Starter들이 세분화된 부분이 제대로 반영됐는지

"인텔리J에 가지고 얘가 만들어놓은 게 내가 지시한 대로 잘 만들어졌는지 확인하는 거죠."

Context7(컨텍스트세븐) 불필요론

예전에는 최신 기술 문서를 정리해서 MCP로 접근하는 Context7을 많이 썼지만, 토비는 Claude Code의 WebSearch/WebFetch 기능이 추가된 이후로 쓰지 않는다. 웹 검색이 더 빠르고 정확하며, Context7은 컨텍스트를 많이 잡아먹는다.

3단계: 개발 워크플로우 결정

선택지 비교

방식	설명	적합한 상황
프롬프트 → 즉시 개발	바로 "만들어줘"	빠른 프로토타입, 일회성
Plan 모드 경유	계획 확인 → 승인 후 실행	대부분의 일반 작업
PRD 먼저 생성	기능 스펙 문서 작성·리뷰 후 개발	체계적 프로젝트
SDD 스타일	스펙 → 구현 계획 → 태스크 리스트 → 단계적 개발	장기 프로젝트, 팀 협업

Plan 모드의 단점: 세션이 끝나면 사라진다. 명시적으로 문서를 남겨두는 것이 낫다.

토비의 선택: SDD 스타일

1. PRD 작성 — Apple Reminders 앱의 웹 버전이라는 주제로 기능 스펙을 먼저 생성.
2. SDD 변환 — PRD를 구현 계획(Implementation Plan)으로 변환. Phase를 나눈다.
3. Task 리스트 생성 — 각 Phase를 세부 태스크로 분할. 체크박스 형태로 만들어달라고 명시.

"체크 가능하도록 해달라는 말 빼놓지 않아요. 나중에 체크를 안 하고 넘어가기도 해서."

4단계: PRD 작성

프롬프트

애플 리마인더 앱의 웹 버전을 만들려고 한다.
백엔드: Spring Boot + JPA + H2, REST API 서비스로 개발
프론트엔드: Next.js 최신 버전
PRD로 정리해줘.

AI가 초안을 만들면 리뷰한다:

• UI는 Apple Reminders 앱과 최대한 유사하게 → 추가 지시
• 기능이 너무 단순하게 나왔으면 보완 요청

SDD로 변환

PRD가 백엔드를 한 방에 다 만드는 구조로 나왔으므로, 여러 단계(Phase)로 나누어 가장 단순한 것부터 시작하도록 변환을 요청한다.

이 PRD를 SDD 스타일로 변환해줘.
여러 Phase로 나누어서 가장 단순한 것부터 시작하고,
프론트까지 띄워서 보면서 기능을 추가하는 방식으로.

결과:

• Phase 1: 기본 엔티티 + 리포지토리 + API + 초기 데이터 + 검증 (백엔드만)
• Phase 2: Next.js 프론트엔드 기본 구성
• Phase 3: 리마인더 CRUD UI
• Phase 4: 상세 필드 추가
• Phase 5: 스마트 목록

Task 리스트 생성

plan.md를 기반으로 tasks.md에 체크 가능한 태스크 리스트를 만들어줘.

67개의 체크박스 항목이 생성된다. 이후 개발 진행 시 AI가 이 리스트를 참조하며 체크해간다.

5단계: 단일 엔티티로 전 레이어 한 사이클

전략

전체 Task를 한꺼번에 돌리지 않고, ReminderList 엔티티 하나만 골라서 도메인 → 리포지토리 → 서비스 → 컨트롤러 전 레이어를 만든다. 이 과정에서 AI의 기본 코딩 습관을 파악하고, 원하는 스타일로 교정한 뒤 **코딩 컨벤션 가이드(CLAUDE.md)**를 작성한다.

"처음에 딱 세팅을 하고 싶다면 이 단계를 거치는 게 좋습니다."

5-1. 도메인 엔티티

프롬프트: ReminderList 도메인 엔티티를 만들어줘

AI가 만든 결과:

• Lombok으로 JPA 엔티티 생성 (@Entity, @Getter, @Builder)
• Long 타입 ID, 이름, 색상, Boolean 필드 등

교정 사항:

• 패키지 이름: entity → **domain**으로 변경 요청

5-2. 도메인 단위 테스트

프롬프트: ReminderList에 대한 단위 테스트를 만들어줘. 생성자, 업데이트, 날짜 정보 자동 등록 검증.

발견된 문제:

• AI가 @PrePersist 같은 JPA 콜백을 단위 테스트에서 직접 호출하려 함 → 도메인 단위 테스트에 JPA 의존 금지
• JPA 콜백으로 날짜를 세팅하는 대신, 생성자에서 직접 날짜를 설정하는 방식으로 변경 요청

"도메인 테스트하고 있는데 막 JPA 집어넣고 이러면 말도 안 되죠."

교정 프롬프트:

도메인 엔티티의 단위 테스트에서는 JPA(@PrePersist 등)를 사용하지 않도록 해줘.
순수 자바 코드의 로직만 검증하도록.
JPA 기능 검증은 리포지토리 테스트에서.

5-3. CLAUDE.md 첫 작성

여기까지의 교정 사항을 영구적으로 기록한다.

프롬프트: 지금까지 개발하면서 나온 코딩 관례를 CLAUDE.md 파일에 저장해줘.

AI가 만든 초안에서 불필요한 것을 제거한다:

넣는 것 (AI가 틀렸거나 교정이 필요한 것)	빼는 것 (AI가 이미 잘하는 것)
기능 구현 시 테스트도 같이 만들고 실행할 것	엔티티에 @Entity 붙이기
도메인 단위 테스트에 JPA 의존 금지	패키지명 (이미 변경 완료)
테스트 @DisplayName 한글 작성	Lombok 사용법 (기본적으로 잘함)
참고 문서 경로 (tasks.md, plan.md)	기본적인 Spring 관례 전반

"AI가 시키지 않아도 알아서 잘하는 거는 넣지 않아요. 너무 양이 많으면 이 중에서 어떤 것들은 무시해버리거든요."

5-4. 서비스 레이어

프롬프트: ReminderList 서비스를 만들어줘.

AI가 만든 결과 확인:

• 생성자 주입 사용 ✓
• @Transactional(readOnly = true) 기본, 변경 있는 것만 @Transactional ✓
• 기본 목록(default list) 삭제 방지 로직 포함 ✓

교정 사항 1 — 인터페이스 분리:

ReminderListService를 인터페이스로 분리하고 구현 클래스가 이를 구현하도록 해줘.
인터페이스는 ports.input 패키지에 배치.
구현 클래스의 네이밍은 앞에 Default를 붙이는 방식으로 (Impl 접미사 아님).

교정 사항 2 — 서비스 테스트 방식:

AI의 기본 습관: Mock 테스트(Mockito로 리포지토리를 목킹) 토비의 요구: @SpringBootTest 통합 테스트 (H2 메모리 DB + @Transactional 롤백)

앞으로 서비스 테스트는 @SpringBootTest를 사용한 통합 테스트로 만들어줘.
Mock을 사용하지 않고 실제 리포지토리와 H2 DB를 사용.

이유: Mock 테스트는 리포지토리가 복잡해지면 테스트가 지저분해지고, DB까지 실제로 갔다오지 않기 때문에 그 부분의 문제가 남기 쉽다. H2 + @Transactional이면 롤백되므로 충분히 빠르다.

5-5. 컨트롤러 & API

프롬프트에 추가한 조건:

API를 OpenAPI 스펙을 따라서 만들고,
만들어진 API 스펙을 openapi.yml 파일에 저장해줘.

이유: openapi.yml 파일이 있으면 나중에 프론트엔드 개발할 때 "이 스펙을 참고해서 만들어줘"라고 하면 AI가 정확하게 따른다.

AI의 결과:

• 생성자 주입, 응답 상태 코드 지정 잘함.
• 테스트는 MockMvc로 작성 (컨트롤러 테스트는 이것이 적절).

5-6. CLAUDE.md 업데이트

서비스 레이어에서 발견된 추가 규칙을 CLAUDE.md에 반영:

서비스 인터페이스: ports.input 패키지
구현 클래스: Default 접두사 (DefaultXxxService)
서비스 테스트: @SpringBootTest 통합 테스트 (Mock 사용 금지)

5-7. 커밋 규칙

커밋 메시지는 한글로 작성해줘.

이것도 CLAUDE.md에 기록. 매번 프롬프트에 넣을 필요 없도록.

6단계: 나머지 엔티티 일괄 개발

한 사이클을 통해 코딩 컨벤션이 확립되었으므로, 이제 나머지 엔티티(Reminder, 알림 등)를 Task 리스트 기반으로 일괄 개발시킨다.

tasks.md의 Phase 1 나머지 항목을 개발하고, 완료되면 체크해줘.
테스트도 만들고, 모든 테스트가 통과하는지 검증해.

AI가 Task 리스트를 참조하며 하나씩 체크해가면서 개발을 진행한다.

Spring Boot 4.x에서 발생하는 문제들 (Jackson 3.x 패키지 변경, 테스트 모듈명 변경 등)을 AI가 웹 검색으로 찾아서 자체 해결한다. 한 번 해결하면 이후에는 같은 문제를 반복하지 않는다.

"처음 할 때 이런 부분을 한 단계로 거쳐서 진행하지 않으면, Boot 4를 썼기 때문에 굉장히 많은 부분에서 에러가 나면서 진행이 오래 걸려요."

7단계: 프론트엔드(Next.js) 개발

Phase 2~5를 프론트엔드까지 포함하여 일괄 진행 요청:

Phase 2부터 5까지 한번에 개발해줘.
프론트엔드는 frontend 폴더에 생성.
완료되면 서버를 띄워서 검증해.

AI가 Next.js 프로젝트를 생성하고, 백엔드 API와 연동하는 프론트엔드를 만든다. Apple Reminders의 룩앤필을 최대한 재현하도록 요청했으므로, 폰트·색상·레이아웃 등을 근사하게 구성한다.

디자인 수정 방법

디자인이 마음에 안 들면:

1. Google Stitch 등으로 원하는 디자인 시안을 생성
2. 캡처하여 Claude Code에 전달
3. "이 디자인 스타일로 바꿔줘" → 잘 바꿔줌

반응형 웹: "모바일에서도 잘 보이도록 리스판시브 웹으로 만들어줘" → 잘 처리.

8단계: 라이브 데모 & 버그 수정

서버를 띄우고 브라우저에서 확인:

• 리마인더 리스트 생성 시 항목이 두 번씩 등록되는 버그 발견
• "리마인더 리스트나 리마인더 등록할 때 두 개씩 들어가는 문제를 고쳐줘" → 원인 분석(React useEffect 중복 실행 또는 더블 클릭 미차단) 후 수정

"보통 이런 문제는 뭐 이펙트가 두 번 생기는 거고, 혹은 더블 클릭을 차단 안 시켜가지고 그런 거라... 우리가 알고 요청해도 되지만 그냥 하면 얘가 원인이 뭔지 생각하고 고쳐주더라고요."

9단계: 코드 리뷰

프롬프트: 코드 리뷰 해줘.

AI가 백엔드·프론트엔드를 분리하여 각각 리뷰 결과를 제공:

• 주요 이슈: DTO 검증 없음, Priority 값 실패 예외 처리, N+1 쿼리
• 워닝 수준: 기타 개선 사항
• 모범 사례: 잘한 부분도 인정

리뷰 결과를 이슈 목록(tasks)으로 변환하고, 각 이슈를 TDD 방식으로 수정하는 것을 권장.

"N+1 쿼리를 TDD로 개발하면 얘가 N+1 쿼리를 검증하는 테스트를 만들어주는데 기가 막힙니다."

10단계: Git Worktree 병렬 개발

메인 작업 중 별도 브랜치 작업이 필요할 때:

claude -w review

• Claude Code가 자동으로 .claude/worktrees/review/ 디렉토리 생성
• 별도 Git 브랜치에서 독립 작업 가능
• Ctrl+C로 빠져나가면 워크트리 관련 설정 자동 정리
• 브랜치는 수동 삭제 또는 머지

11단계: 상태 표시줄 (Status Line) 설정

Claude Code에는 하단 상태 표시줄을 커스텀하는 기본 기능이 있다.

/status-bar 유저, 상대 폴더, 모델, Git 브랜치, 컨텍스트 사용량, 시간을 넣어줘.
상대 경로가 길면 중간 폴더를 한 글자로 축약해줘.

결과: 하단에 컬러 상태 표시줄이 생성된다. 특히 **컨텍스트 사용량(%)**이 보이는 것이 중요 — 컨텍스트가 차면 성능이 떨어지므로 clear/compact 시점을 판단할 수 있다.

"돌아가는 중에 컨텍스트 아 얼마 남았지? 이거 좀 클리어하고 갈까, 콤팩트 할까, 이런 걸 생각해야 되는데 이게 계속 나오게 하면 좋습니다."

핵심 포인트 요약

1. Spring Initializr 경유 필수 — AI가 직접 프로젝트 구조를 만들게 하면 꼬인다.
2. Plan 모드로 먼저 확인 — AI가 어떤 버전·방식을 쓰려는지 파악 후 교정.
3. 단일 엔티티로 한 사이클 — 전 레이어를 돌리며 코딩 컨벤션 확립.
4. CLAUDE.md는 간결하게 — AI가 이미 잘하는 것은 빼고, 교정이 필요한 것만 유지.
5. Spring Boot 4.x는 AI 학습 범위 밖 — 첫 사이클에서 한 번 잡아주면 이후에는 학습.
6. Task 리스트 + 체크박스 — AI가 진행 상황을 추적하며 빠뜨리지 않도록.
7. 프론트엔드는 AI에게 완전 위임 — 백엔드 개발자도 Next.js로 충분히 그럴듯한 UI를 뽑을 수 있다.
8. 코드 리뷰 → 이슈 → TDD 수정 — 품질을 끌어올리는 사이클.

020_Toby - 클로드 코드를 이용해 스프링 앱 개발하기 - Live 2.md

2회차 — Claude Code 동작 원리 이해와 도구 확장

원본: https://www.youtube.com/live/ECK6jZWixtk?si=zorjjplWRVpwvye3 발표자: 토비 (이일민)

개요

1회차에서 맨땅부터 Spring Boot 프로젝트를 만드는 과정을 보여줬다면, 2회차는 Claude Code가 내부적으로 어떻게 동작하는지 이해하고, 그 위에 스킬·에이전트·에이전트 팀 등 확장 도구를 직접 만들어 사용하는 방법을 다룬다.

기술 스택 (1회차와 동일 + 추가)

구분	기술	비고
AI 도구	Claude Code (Opus 4.6)	$200 MAX 플랜
보조 AI	OpenAI Codex	코드 리뷰, 로직 분석 보조
터미널	Ghostty + tmux	에이전트 팀 시각화에 tmux 사용
IDE	IntelliJ IDEA	코드 변경 승인·리뷰용
플러그인	anthropics/claude-code-plugins (공식)	검증된 것만 선별 설치
프로젝트	1회차의 toby-reminder (Spring Boot 4.x)	계속 이어서 사용

전체 흐름

AI 에이전트 동작 원리 설명
· 에이전틱 루프 (컨텍스트 → 액션 → 검증 → 반복)
· Claude(AI) vs Claude Code(하네스) 역할 구분
· 도구(Tool)의 개념과 역할
↓
기본 내장 도구 확인
· "가지고 있는 도구가 뭔지 알려줘"
· Bash, Read, Write, Edit, Glob, Grep, Skill, Agent, Web 등
↓
컨텍스트 구조 이해
· 시스템 프롬프트 + 대화 히스토리 + 도구 목록 + 최신 프롬프트
· 컨텍스트가 커지면 AI 효율 저하
↓
공식 플러그인 마켓플레이스 설치
· 최소한의 플러그인만 선별
↓
스킬(Skill) 제작 — Spring Initializr 스킬
· Skill Creator 플러그인 사용
· AskUserQuestion 도구로 대화형 선택 UI 구현
↓
서브 에이전트 제작 — 코드 품질 감사 에이전트
· 별도 세션에서 실행, 메인 컨텍스트 오염 없음
↓
에이전트 팀 구성 — TDD Red/Green/Refactor
· tmux로 병렬 시각화
· 팀 리드가 태스크 분할 → 에이전트 간 협업
↓
실전 워크플로우 조합
· 코드 품질 감사 → 이슈 추출 → TDD 팀으로 수정
↓
멀티 모델 협업 (Claude + Codex)
· 스킬로 Codex 호출 패키징
· 두 모델 간 코드 리뷰 토론
↓
권한 관리(Permissions) & IDE 연동 팁

1단계: AI 에이전트 동작 원리

핵심 개념 — "Claude는 지금도 채봇이다"

Claude Code 공식 문서의 "작동 방식" 섹션을 기반으로 설명.

에이전틱 루프:

① 컨텍스트 수집 → ② AI에게 전송 → ③ AI가 도구 사용 지시
→ ④ Claude Code가 도구 실행 → ⑤ 결과를 AI에게 반환
→ ⑥ AI가 "더 할 게 있나" 판단 → 있으면 ③으로 / 없으면 응답 출력

두 가지 필수 구성 요소:

1. 추론 모델 (Claude) — 텍스트를 받아서 텍스트를 돌려주는 채봇. 파일을 만들거나 명령을 실행하는 능력은 없다.
2. 도구 (Tools) — Claude Code가 보유한 것들. AI가 직접 사용하는 게 아니라, "이 도구를 사용해서 이 작업을 해라"라고 지시하면 Claude Code가 대신 실행한다.

"AI한테 '야 너 내 컴퓨터에 와가지고 프로젝트 만들어줘' 하면 '나는 사용자의 컴퓨터에 접근할 수 없습니다'라고 끝나겠죠. 당연히 못하죠. 그래서 도구가 필요한 거예요."

실제 동작 예시

현재 프로젝트를 분석해줘라고 입력하면:

1. Claude Code가 도구 목록 + 프롬프트를 AI에게 전송
2. AI: "Bash 도구로 ls 명령을 실행해라" → Claude Code가 실행 → 결과 반환
3. AI: "Read 도구로 build.gradle.kts를 읽어라" → Claude Code가 실행 → 결과 반환
4. AI: "Explorer 에이전트를 띄워서 코드를 분석해라" → Claude Code가 실행
5. 분석 완료 → AI가 최종 응답 출력

화면에서 동그란 아이콘과 함께 표시되는 각 항목(Bash, Read, Explorer 등)이 AI가 지시하고 Claude Code가 실행한 도구 호출이다.

"여기 앞에 동그라미 붙어가지고 돌아가는 거 볼 때마다, 아 클로드 코드의 이런 도구를 지금 AI가 사용하라고 해서 실행하고 있구나, 라고 이해하시면 됩니다."

2단계: 기본 내장 도구 확인

도구 목록 조회

내가 가지고 있는 도구가 어떤 건지 알려줘.
에이전트도 알려줘.

(플러그인 미설치 상태에서의 기본 도구 목록)

도구	기능
Bash	셸 명령 실행 — 어떤 커맨드라인 명령이든 가능
Read	파일 읽기
Write	새 파일 쓰기 / 덮어쓰기
Edit (str_replace)	파일 내 문자열 치환
Glob	패턴 기반 파일 검색
Grep	파일 내용(텍스트) 검색
Skill	스킬 로딩·실행
Agent	서브 에이전트 실행
ToolSearch	도구 검색 (플러그인 등에서 적절한 도구 탐색)
WebSearch	웹 검색
WebFetch	웹 페이지 내용 가져오기
Task	태스크 리스트 관리
Plan	Plan 모드 진입·관리
Browser	Chrome 확장 통한 브라우저 제어 (웹 테스트, UI 검증 등)
AskUserQuestion	사용자에게 탭 형태 선택지 제시
Notebook	Python 노트북 편집
Git	Git 작업

• 커넥터 연동 시 Gmail, Google Calendar 등 추가.

도구를 아는 것이 중요한 이유

명시적으로 어떤 도구를 쓰라고 지시하면 훨씬 나은 결과가 나오는 경우가 많다.

예시: 코드 분석 시 AI가 Glob/Grep만 쓰고 대충 넘어갈 때 → "Explorer 에이전트를 사용해서 분석해줘"라고 명시하면 훨씬 깊이 있는 분석을 한다. Explorer는 병렬로 여러 개 띄울 수도 있다.

에이전트 사용법 문의

Explorer 에이전트는 어떻게 사용하면 좋은지 알려줘.

Claude Code 자신이 가장 잘 알고 있으므로 사용법, 파라미터, 활용 방법 등을 상세히 답변해준다.

"클로드 코드를 잘 쓰는 법은 클로드 코드한테 물어보면 됩니다."

3단계: 컨텍스트 구조 이해

프롬프트 전송 시 AI에게 가는 전체 내용

┌─────────────────────────────────────────┐
│ 시스템 프롬프트                            │  ← Claude Code 팀이 세팅한 고정 규칙
│   (윤리 규칙, 코딩 에이전트 역할 정의 등)    │
├─────────────────────────────────────────┤
│ 대화 히스토리                              │  ← 이전 모든 사용자↔AI 메시지 쌍
│   (사용자: "엔티티 만들어줘"                │     세션 내 누적
│    AI: "ReminderList를 만들었습니다..."     │
│    사용자: "테스트도 만들어줘"               │
│    AI: "단위 테스트를 작성했습니다..."       │
│    ...)                                   │
├─────────────────────────────────────────┤
│ 도구 목록                                  │  ← 기본 도구 + 플러그인 + MCP
│   (Bash, Read, Write, ..., 스킬 목록,     │     매 요청마다 전송됨
│    에이전트 목록, ...)                      │
├─────────────────────────────────────────┤
│ 최신 프롬프트                              │  ← 방금 입력한 내용
│   ("서비스 테스트를 통합 테스트로 바꿔줘")   │
└─────────────────────────────────────────┘

컨텍스트 관리의 중요성

• 대화 히스토리가 길어지면 AI 효율이 떨어진다. 현재 작업과 무관한 과거 대화가 쌓여 있으면 AI가 혼란스러워한다.
• 도구 목록도 MCP를 많이 설치하면 비대해진다. 스킬은 상대적으로 가볍다.
• 컨텍스트 사용량은 상태 표시줄에서 확인 가능. 많이 차면 clear context(대화 히스토리 초기화) 또는 compact(AI가 요약하여 압축) 사용.

"컨텍스트에 의미 없는, 지금 작업과 직접 관련 없는 것들이 계속 남아 있으면 AI가 일을 잘 못 해요."

4단계: 공식 플러그인 마켓플레이스 설치

설치 원칙

절대 금지: 한꺼번에 수십~수백 개 플러그인 설치. "에이전트 150개 + 스킬 1500개를 설치해드립니다" 같은 것은 컨텍스트를 지저분하게 만들고 성능을 떨어뜨린다.

"인텔리제이에다가 플러그인 뭐 오픈소스로 존재하는 거 한 300개쯤 깔면 갑자기 스프링 개발하는 게 좋아지나요? 그거 아닌 거 여러분 다 아시잖아요. 마찬가지거든요."

마켓플레이스 추가

/plugins → Add Marketplace → URL 입력:
https://github.com/anthropics/claude-code-plugins

Anthropic이 관리하는 공식 플러그인 저장소. 내부(Internal) 플러그인 + 검증된 외부(External) 플러그인을 포함.

최소 권장 설치 목록

플러그인	용도	설치 우선도
Ralph Loop	실무 워크플로우 (매일 사용)	필수
Skill Creator	스킬 제작 지원	필수
Exploratory Output Style	대화 중 인사이트 팁 표시	필수 (무조건 켜놓을 것)
Plugin Dev	플러그인 개발용	권장

나머지(LSP, Figma 등)는 필요할 때만 추가. 처음부터 설치하면 혼란만 가중된다.

보안 주의

플러그인은 로컬에서 실행되는 Claude Code의 권한을 가진다. 악의적인 프롬프트가 심어진 플러그인은 컴퓨터의 중요 정보를 빼내어 외부 전송할 수 있다. 충분히 검증된 플러그인만 사용하거나 직접 만들어 쓰는 것이 안전.

5단계: 스킬(Skill) 제작 — Spring Initializr 스킬

스킬이란?

반복되는 프롬프트를 재사용 가능한 형태로 패키징한 것. 본질은 프롬프트 + (선택적) 코드. 함수를 만들어 재사용하는 것과 같은 개념.

"스킬이 뭐 엄청 대단한 거 같다고 생각하시는데 그냥 진짜 아무것도 아닙니다. 여러분이 프롬프트 재사용하게 만들어준 겁니다."

만드는 기준: 3번 이상 반복되는 작업이면 스킬로 만든다.

스킬 vs MCP 비교

	스킬	MCP
컨텍스트 소비	가벼움 (도구 목록 정보가 간결)	무거움 (도구 목록이 장황)
실행 위치	메인 세션 (대화 히스토리에 추가됨)	외부 서버
관리	파일 기반, 직접 수정 용이	서버 설정 필요

→ 가능하면 스킬을 선호한다.

제작 과정

Skill Creator 플러그인을 사용하여 프롬프트 기반으로 스킬을 생성한다.

/skill-creator 스프링부트 프로젝트를 생성하는 스킬을 만들어줘.

- 스프링 이니셜라이저를 이용해서 진행해줘
- 스프링부트 버전: 사용 가능한 것을 보여주고 선택 (AskUserQuestion 도구 사용)
- 자바 버전: 선택 가능하게
- Gradle Kotlin DSL 고정 (물어보지 않음)
- 아티팩트: 현재 폴더명을 디폴트, 수정할지 확인
- 패키지: toby.ai.{아티팩트} 디폴트, 수정할지 확인
- 디펜던시: Initializr에서 목록 가져와 그룹별로 다중 선택

AskUserQuestion 도구: 탭 형태의 선택지 UI를 만들어주는 Claude Code 내장 도구. 인텔리제이의 Spring 프로젝트 생성 다이얼로그와 유사한 경험을 터미널에서 제공.

설치 및 사용

생성된 스킬을 유저 레벨로 설치 → 어떤 프로젝트에서든 사용 가능.

사용 방법:

• /spring-initializer (슬래시 명령)
• 또는 "스프링 프로젝트 만들어줘"라고 프롬프트 → AI가 스킬 자동 매칭

실행 흐름:

1. Boot 버전 선택 (탭 UI)
2. Java 버전 선택 (탭 UI)
3. 아티팩트명 확인/수정
4. 패키지명 확인/수정
5. 디펜던시 그룹 선택 → 그룹 내 항목 다중 선택
6. Initializr API 호출 → 프로젝트 생성

"스킬도 한 번에 100% 완성할 필요는 없습니다. 만들고 계속 고쳐도 돼요."

6단계: 서브 에이전트 제작 — 코드 품질 감사

서브 에이전트란?

스킬과 비슷하게 반복 작업을 패키징하지만, 별도 세션에서 실행되어 메인 컨텍스트에 대화 내용이 추가되지 않는다. 요약된 결과만 반환.

스킬과의 핵심 차이:

	스킬	서브 에이전트
실행 세션	메인 세션 (대화 히스토리에 추가)	별도 세션 (메인 컨텍스트 오염 없음)
결과 전달	전체 과정이 히스토리에 남음	요약된 결과만 반환
적합한 용도	개발 흐름의 일부	분석, 리뷰 등 보조 작업
병렬 실행	불가	가능 (백그라운드)

"코드를 분석하고 하는 작업들은 지금 개발 중에 중간에 실행을 한다면, 이후 컨텍스트에 그 흘러갔던 내용들이 남아 있을 필요가 없어요. 결과만 받아오면 됩니다."

제작 과정

/agent → 새로운 에이전트 만들기 → 유저 레벨 → Claude로 만들기

코드를 분석해서 코드 품질을 평가하고 리포트를 생성하는 에이전트.
가독성, 아키텍처, 테스트, 보안 등 여러 분야로 분석하고
각각 점수를 A~F 등급으로 매겨줘.

생성된 에이전트 이름: code-quality-auditor

실행 및 결과

1회차에서 만든 toby-reminder 프로젝트에 대해 실행:

코드 품질을 분석해줘.

AI가 도구 목록에서 code-quality-auditor 에이전트를 발견하고 자동 실행. 백그라운드에서 독립적으로 동작하며, 메인 세션에서 다른 작업을 계속할 수 있다.

결과 예시:

• 종합 점수: 81점 (B)
• 코드 규칙 준수: 양호
• 가독성: 약간 부족
• 아키텍처: 양호
• 성능: C (N+1 쿼리 지적)
• 크리티컬 이슈: 컨트롤러에서 리포지토리 직접 주입 (아키텍처 위반), N+1 쿼리, DTO 생성 수준 공유 문제
• 모범 사례: 잘한 부분도 인정

7단계: 에이전트 팀 — TDD Red/Green/Refactor

에이전트 팀이란?

여러 서브 에이전트가 팀으로 구성되어 서로 커뮤니케이션하며 협업하는 구조. 일반 서브 에이전트는 메인 세션에서 호출·응답 방식이지만, 에이전트 팀은 에이전트 간 직접 통신이 가능하다.

활성화 (실험적 기능)

설정 파일에 환경변수 추가가 필요하다:

// ~/.claude/settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAM": "1"
}
}

주의: ENABLE이 아닌 EXPERIMENTAL이 올바른 키. AI에게 설정을 시키면 잘못 넣는 경우가 있다.

TDD 팀 구성

/create-team TDD를 에이전트 팀으로 구성해줘.

- Red: 실패하는 테스트 작성 → 반드시 테스트를 실행해서 실패하는지 확인
(빌드 실패가 아닌, 테스트 실행 후 실패여야 함)
- Green: 실패하는 테스트를 성공시키기 위한 최소한의 코드만 작성
- Refactor: 작성된 코드를 리팩터링
- Team Lead: 주어진 개발 요구사항을 받아서 태스크를 먼저 분할하고,
각 에이전트에 순차 할당

tmux 연동 시각화

에이전트 팀이 실행되면 tmux를 이용하여 화면을 분할하고, 각 에이전트(Red, Green, Refactor, Lead)에 독립적인 터미널 창을 할당한다. 각 창에서 에이전트가 동시에 작업하는 것을 시각적으로 확인할 수 있다.

Ghostty에서 tmux를 사용하려면 몇 가지 추가 설정이 필요하다 (검색하면 나옴).

실행 예시 — 문자열 계산기

문자열 계산기를 만들어줘.
빈 문자열이면 0, 쉼표로 구분된 숫자를 합산.

실행 흐름:

1. Team Lead가 태스크 분할:

• 빈 문자열 → 0 반환
• 숫자 하나 → 그 숫자 반환
• 쉼표 구분 → 합산

2. Red 에이전트에게 첫 번째 태스크 전달 → 실패하는 테스트 작성 → 테스트 실행하여 실패 확인
3. Green 에이전트에게 전달 → 최소한의 코드로 테스트 통과
4. Refactor 에이전트에게 전달 → 코드 정리
5. 다음 태스크로 반복

발견된 문제

이번 실행에서 Refactor 에이전트가 매 태스크마다 실행되지 않고 마지막에 한 번만 실행됐다. TDD에서 리팩터는 매 사이클마다 해야 하는데 AI가 잘못 구성한 것.

→ 해결: 프롬프트를 다듬거나 스킬로 고정하여 "매 태스크가 끝날 때마다 Refactor를 수행하라"고 명시.

IDE 연동

IntelliJ의 SLADE 기능으로 Claude Code와 연결하면, 코드 변경 승인을 터미널이 아닌 IntelliJ 내에서 할 수 있다. TDD 진행 중 에이전트가 만드는 코드를 IDE의 diff 뷰로 확인하며 수락/거부 가능.

Accept Edits를 끄면(시프트 탭으로 토글), 파일 수정마다 사용자 확인을 거치므로 학습·검증 목적에 유용하다.

8단계: 실전 워크플로우 조합

코드 품질 감사 → 이슈 → TDD 수정

코드 품질 감사 에이전트 실행
↓
리포트에서 이슈 추출
↓
이슈 목록을 로컬 태스크 또는 GitHub Issue로 등록
↓
이슈 하나씩 TDD 팀으로 수정
· 문제를 재현하는 실패 테스트 작성 (Red)
· 수정 코드 작성 (Green)
· 리팩터 (Refactor)
↓
커밋 (이슈마다 또는 일괄)

"수정 작업을 할 때는 바로 하지 않고 TDD를 꼭 만들어서 하라고 합니다. 문제가 있다는 실패하는 테스트를 꼭 만들고 나서 수정하라고 합니다."

N+1 쿼리 사례: AI가 N+1 쿼리를 검증하는 실패 테스트를 만들어주는데, 쿼리 카운트를 체크하는 방식 등으로 정교하게 구성한다.

9단계: 멀티 모델 협업

Codex 연동 스킬

스킬로 다른 모델 호출을 패키징할 수 있다:

Codex를 호출해서 요청한 작업을 수행하고 결과를 돌려받는 스킬을 만들어줘.

→ "Codex Delegator" 스킬 생성

사용 시나리오

1. Claude Code에서 개발 (메인)
2. 코드 리뷰가 필요할 때 → Codex에게 위임: "이 코드 리뷰해줘"
3. Codex 결과 수신 → Claude Code에게: "Codex가 이렇게 말했는데 동의하냐? 반박해봐"
4. 두 모델이 토론 → 합의된 개선 사항만 적용

"클로드: 일상 개발 메인. 코덱스: 알고리즘·로직 분석, 코드 리뷰에 강점."

Codex의 특성: 어려운 알고리즘이나 로직 분석에 강하지만, 맨땅에서 프로젝트를 시작하면 초반이 힘들다 (3~5배 더 잔소리 필요). 따라서 항상 Claude Code로 시작하고 Codex는 보조·협력 역할.

10단계: 권한 관리 (Permissions)

문제

에이전트 팀이 돌아가는 동안 ./gradlew test 같은 외부 명령 실행마다 사용자 승인을 요구하면 작업이 끊긴다.

해결 — Allow List

안전하다고 판단되는 명령을 Permissions에 사전 등록:

/permissions에서 확인:
- ./gradlew → 항상 허용
- ls, find → 항상 허용
- start.spring.io 접근 → 항상 허용

유저 레벨 settings.json에 등록하면 모든 프로젝트에 적용.

또는 Docker 컨테이너 위에서 전체 허용 모드(--dangerously-skip-permissions)로 실행하는 방법도 있음. 프로덕션 DB 접근 등이 없는 격리된 환경에서만 사용.

알림(Notification) 훅

Claude Code가 작업 완료 또는 사용자 응답 대기 시 알림을 보내도록 Stop/Notification 훅을 설정할 수 있다. 여러 세션을 동시에 돌릴 때 어느 창에서 대기 중인지 빠르게 파악 가능.

핵심 포인트 요약

1. Claude는 채봇이고 Claude Code가 도구를 실행한다. 이 구조를 이해해야 도구를 효과적으로 활용할 수 있다.

2. 기본 도구 목록을 파악하라. "가지고 있는 도구가 뭔지 알려줘"를 첫 번째로 실행. 명시적으로 도구를 지정하면 AI가 더 잘한다.

3. 컨텍스트를 깨끗하게 유지하라. 대화 히스토리가 길어지면 성능 저하. 보조 작업은 서브 에이전트로 분리.

4. 플러그인은 최소한으로. 공식 검증된 것부터 하나씩. 대량 설치는 성능 저하의 직접적 원인.

5. 3번 반복되면 스킬로 만들어라. 스킬은 가볍고 관리가 쉽다. MCP보다 컨텍스트 소비가 적다.

6. 분석·리뷰 등 보조 작업은 서브 에이전트로. 메인 컨텍스트를 오염시키지 않고 결과만 받는다.

7. 에이전트 팀으로 TDD를 자동화하라. 특히 초기 컨벤션 확립과 이슈 수정에 효과적.

8. 멀티 모델 토론으로 코드 품질을 올려라. Claude + Codex 조합이 현재 실전에서 가장 효과적.

9. 모델 업데이트마다 도구 세트를 재평가하라. 새 모델이 기본으로 해결하는 영역이 넓어지면 기존 스킬이 불필요해질 수 있다.

10. Claude Code 공식 문서를 철저히 읽어라. 베스트 프랙티스·기능 설명·팁이 담겨 있다. 한국어 번역도 제공. 마크다운으로 다운받아 통째로 AI에게 넣고 질문하는 것도 유효.

"클로드 코드를 잘 쓰고 싶으시면 공식 문서 안에 어마어마한 내용이 들어 있어요. 이거 읽고 공부하세요."

030_Toby - 클로드 코드를 이용해 스프링 앱 개발하기 - Live 3.md

3회차 — AI 개발 워크플로우와 실전 도구 활용

원본: (3회차 라이브 — 토비의 Claude Code로 Spring Boot 개발하기) 발표자: 토비 (이일민)

---

개요

1회차는 맨땅에서 프로젝트 생성, 2회차는 에이전트 동작 원리와 도구 확장을 다뤘다면, 3회차는 실전 워크플로우에 집중한다. 새 프로젝트를 처음부터 설계하는 과정을 Superpowers 플러그인의 브레인스토밍 기능으로 시연하며, 멀티 모델 협업(Codex/Gemini 병렬 리뷰), 보안 설정, 대화 기록 저장 등 실무 팁을 다룬다.

---

기술 스택

구분	기술	비고
백엔드	Spring Boot 4.x (Spring Framework 7.x)
언어	Java 25
빌드	Gradle (Kotlin DSL)
ORM	Spring Data JPA
DB	PostgreSQL (운영) / H2 (테스트)	이전 회차의 H2 전용에서 변경
프론트엔드	Thymeleaf (서버 사이드 렌더링)	이전 회차의 Next.js와 다른 선택
인증	소셜 로그인 (OAuth2)
AI 도구	Claude Code (Opus 4.6)	$200 MAX 플랜
보조 AI	OpenAI Codex (Plus), Google Gemini	설계 리뷰용 병렬 호출
터미널	CMUX (Ghostty에서 전환)	AI 코딩 특화 터미널
IDE	IntelliJ IDEA
개발 대상	URL 단축기 + 분석(Analytics) 서비스	SaaS로 공개 목표

---

전체 흐름

CMUX 터미널 소개 (Ghostty에서 전환)
  · 워크스페이스, 페인 분할, 내장 브라우저, 완료 알림
  ↓
Firecrawl 플러그인으로 새 기술 학습 (CMUX 사용법)
  · 학습 내용을 스킬 또는 오토 메모리로 저장
  ↓
플러그인 마켓플레이스 소개
  · 오피셜 플러그인 (필수)
  · Superpowers, Ralph (워크플로우)
  · 토비 플러그인 (자작)
  ↓
핵심 워크플로우 설명: 탐색 → 계획 → 구현 → 커밋
  · Claude Code 공식 Best Practices 기반
  · 세 가지 계획 도구 비교: Plan 모드 / Superpowers / Ralph
  ↓
프로젝트 선정: URL 단축기 서비스
  · AI에게 아이디어 제안 받기
  · Firecrawl로 기존 서비스 리서치 (Bitly, TinyURL 등)
  ↓
Superpowers 브레인스토밍 9단계 실행
  · 명확화 질문 (목적, 규모, 기술 스택, 기능 범위)
  · 아키텍처 다이어그램 (비주얼 컴패니언)
  · Spring 7 신기능 활용 제안
  · API 설계 및 데이터 모델
  · 스펙 문서 작성 + 셀프 리뷰
  ↓
멀티 모델 리뷰: Codex + Gemini 병렬 호출
  · CMUX 페인에 각각 띄워서 시각적 확인
  · Codex가 Claude의 기술적 오류를 지적
  · 컨센서스 분석 (3모델 의견 일치/불일치 정리)
  ↓
구현 계획 작성 → TDD 방식으로 코드 구현 시작
  ↓
보안 설정 (Permissions: Allow / Deny / Hook)
  ↓
대화 기록 저장 (Save Conversation 스킬)

---

1. CMUX 터미널 — Ghostty에서 전환

토비가 메인 터미널을 Ghostty에서 CMUX로 변경했다. 2주 사용 후 완전히 정착.

CMUX의 장점

워크스페이스: 좌측 패널에 워크스페이스 목록이 표시되고, 각 워크스페이스에 이름을 부여할 수 있다. 동시에 여러 프로젝트를 작업하거나, 한 프로젝트 내에서 메인 개발 / 실험 / 학습 등을 워크스페이스로 구분하여 관리.

페인 분할: 상하/좌우 자유롭게 분할. 한쪽에서 Claude Code 실행, 다른 쪽에서 별도 작업(다른 세션, 문서 확인 등) 가능.

내장 브라우저: 터미널 내부에서 브라우저 탭을 열 수 있다. 크롬과 화면 전환 없이 개발 결과를 바로 확인하거나, AI가 브라우저를 통해 웹 테스트를 수행하도록 연결 가능.

완료 알림: AI 작업이 끝나거나 사용자 응답을 기다릴 때 워크스페이스 탭에 알림 표시(숫자 뱃지 + 파란색 테두리). 동시에 5개 이상 세션을 열고 작업할 때 어느 쪽이 대기 중인지 즉시 파악 가능.

실행 상태 표시: 각 페인에 "Running" / 체크마크 / "응답 대기" 등 상태가 실시간으로 표시.

"보통 한 다섯 개 정도 항상 열고 쓰는 것 같은데, 어디서 지금 나를 기다리고 있구나, 이걸 계속 클릭해서 다음 작업 진행해, 이건 이렇게 진행해, 답변하고... 진짜 바쁩니다."

CMUX에 AI 연결하기

Claude Code는 기본적으로 CMUX를 모른다. Firecrawl 플러그인(오피셜 플러그인에 포함)으로 CMUX 공식 사이트를 학습시키면, 이후 CMUX의 페인 생성, 메시지 전송 등 기능을 활용할 수 있게 된다.

학습 후 세션이 끝나면 까먹으므로, 스킬로 만들어 저장하거나 오토 메모리에 넣어둔다. 오토 메모리는 같은 프로젝트 폴더 내에서는 세션이 바뀌어도 유지되지만, 다른 프로젝트/장비로 이동하면 사라지므로 스킬이 더 확실하다.

"한번 이렇게 시키고 나면 그다음부터는 CMUX를 통해서 어떤 기능을 사용해, 이렇게 하면 굉장히 잘해요."

---

2. 스킬(Skill)의 두 가지 용도

용도 1: 반복 작업 자동화

이전 회차에서 설명한 것과 동일. 반복되는 프롬프트를 패키징하여 간단한 명령으로 실행.

용도 2: 레퍼런스 (AI가 모르는 지식 보충)

AI가 학습하지 않은 것(최신 기술, 새 버전)이나 알 수 없는 것(사내 코딩 관례, 현재 팀의 집중 영역, 프로젝트 고유 규칙)을 스킬에 담아두면, 필요할 때 자동으로 로딩되어 컨텍스트에 포함된다.

예시 — Spring Boot 4 스킬:

• Boot 3과 달라진 점 정리
• 자주 사용하는 새 기능 (API 버전 관리, @Retryable, RestClient 등)
• 마이그레이션 가이드 참조 포인트

이 스킬이 있으면 "스프링 7에 새로 추가된 기능을 이용해서 만들어줘"라고만 해도 AI가 스킬을 자동 로딩하여 정확한 정보를 참고한다.

"자기가 많이 쓰는 기술에 대한 이런 레퍼런스 스킬을 만들어두세요. 범용적인 공개 스킬도 좋지만, 여러분만의 스킬이 더 중요합니다."

스킬 유지보수

• 스킬은 한번 만들고 끝이 아니다. 부족한 부분은 계속 개선 요청.
• 모델 업데이트 시 재평가 필수. 새 모델이 기본으로 잘하게 된 것은 스킬에서 제거. 오히려 성능을 떨어뜨릴 수 있다.
• Skill Creator의 이밸루에이션 기능: 스킬 사용 vs 미사용, 스킬 수정 전 vs 후의 결과를 비교 평가할 수 있다. Claude Code 팀도 이 방법으로 스킬을 검증한다고 공개.

---

3. 플러그인 구성

필수 마켓플레이스

Claude 플러그인 오피셜 (anthropics/claude-code-plugins) — 100개 이상의 검증된 플러그인. 오토 업데이트 권장.

토비가 사용하는 주요 플러그인

플러그인	용도	비고
Superpowers	워크플로우 (브레인스토밍, 구현 계획, 비주얼 컴패니언)	GitHub 스타 4만+, 가장 많이 사용
Ralph (Ralph Skills)	PRD 생성, 워크플로우 (Superpowers보다 가볍고 빠름)	오피셜 플러그인에도 포함
Firecrawl	웹사이트 종합 크롤링·학습	기술 학습, 리서치에 유용
Exploratory Output Style	대화 중 인사이트 팁 표시	무조건 켜놓을 것
Skill Creator	스킬 제작·평가
Toby Plugins (자작)	코드 품질 측정, 퍼미션 관리, 대화 저장, 멀티 모델 호출 등	GitHub에 공개

주의

• Oh My Claude Code / Oh My Open Code: 워크플로우 자동화에 특화된 프로젝트. 토비는 아직 관망 중 — "이거는 아무것도 모른 채로 깔면 뭔가 잘 되는 느낌으로 만들어진 거라. 본격적으로 스킬을 이용해서 워크플로우를 만들 단계가 되면 참고용으로 살펴볼 것."
• 최소한의 플러그인만 설치하는 원칙은 여전히 유효.

---

4. 핵심 워크플로우: 탐색 → 계획 → 구현 → 커밋

Claude Code 공식 문서의 "모범 사례(Best Practices)"에 나오는 권장 작업 흐름. 토비는 이를 기반으로 자신의 워크플로우를 구축.

4단계

단계	내용
1. 탐색	현재 프로젝트 상태를 AI에게 분석시킴. 기존 코드, 구조, 설계 문서 등을 파악.
2. 계획	무엇을 어떻게 만들지 계획 수립. 충분한 대화와 리뷰를 거쳐 구체화.
3. 구현	계획에 따라 코드 생성. TDD, 서브 에이전트 등 활용.
4. 커밋	한 사이클의 결과를 커밋. 롤백 포인트 확보.

"계획에 여러분이 많은 비중을 두고 투자를 해야 그다음에 구현이 되게 잘됩니다."

이 사이클은 모든 규모에 적용

• MVP 초기 개발: 리서치 → 브레인스토밍 → 계획 → 최소 기능 구현 → 커밋
• 기능 추가: 탐색(현재 코드 파악) → 계획 → 구현 → 커밋
• 버그 수정: 탐색(에러 분석) → 계획(수정 방안 + 검증 테스트) → 구현 → 커밋
• UI 개선: 탐색 → 브레인스토밍(디자인 방향) → 계획 → 구현 → 커밋

"버그 수정도 이 흐름을 타는 게 좋습니다. 이런 에러가 났는데 이거 무슨 문제야? → 고치려면 어떤 식으로 할까? → 수정 확인 테스트 만들고 → 구현."

컨텍스트와 사이클 범위 관리

• 한 사이클의 범위를 너무 크게 잡지 않는다. AI가 한 번에 많이 만들 수 있지만, 결과 품질이 떨어진다.
• 컨텍스트는 200K~300K 수준에서 끊고 clear context 또는 새 세션 시작.
• 세션을 끝내기 전에 AI가 지금까지 뭘 작업했고 다음에 뭘 해야 하는지 이해할 수 있을 만큼 문서를 만들어둔다.

"적어도 한두 사이클 이내로 돌아가는 게 좋아요. 하루 종일 한 번도 클리어 안 하고 쓰면 점점 AI가 비효율적이 돼요."

---

5. 세 가지 계획 도구 비교

도구	속도	깊이	적합한 상황
Plan 모드 (내장)	빠름	가벼움	간단한 수정, 잘 아는 작업, 빠른 확인
Superpowers	느림 (30분~1시간)	깊음 (9단계, 셀프 리뷰, 비주얼 컴패니언)	새 프로젝트, 주요 기능 추가, 복잡한 설계
Ralph	중간	중간 (질문 1회, 빠른 PRD)	이전에 해본 적 있는 작업, Superpowers가 과한 경우

"3분이면 끝날 것 같은데 Superpowers 쓰면 30분 걸릴 수도 있거든요. 정말 간단한 건 Plan 모드, 좀 큰 건 Superpowers, 그 중간은 Ralph."

---

6. Superpowers 브레인스토밍 9단계 실습

프로젝트: URL 단축기 + Analytics 서비스

AI에게 "스프링 부트 4로 뭔가 재밌는 걸 만들어보고 싶어"라고 요청 → AI가 여러 아이디어 제안 → URL Shortener + Analytics 선택.

리서치 단계

브레인스토밍 시작 전에 먼저 리서치:

인기 URL 단축 서비스들 (Bitly, TinyURL, Rebrandly 등)을 분석해서
기능, 장단점, 가격 정책을 비교해줘.

Firecrawl 플러그인이 여러 웹사이트를 동시에 크롤링하여 비교 분석 결과를 제공.

브레인스토밍 시작

/brainstorm URL 단축 + 분석 기능 포함 서비스 개발. 스프링부트 사용.

9단계 진행:

1. 프로젝트 컨텍스트 탐색 — 기존 코드, 이전 리서치 결과 확인
2. 명확화 질문 — AI가 구체적인 질문을 던짐:
   • 목적: 학습용 vs 실제 서비스 vs 포트폴리오 vs 오픈소스?
   • 규모: 개인용 vs 팀/회사용 vs SaaS 공개?
   • 분석 기능 범위: 기본 클릭 통계 vs 고급 분석?
   • 인증: 소셜 로그인? API 키?
   • 프론트엔드 포함 여부?
   • 빌드 도구?
   • QR 코드 생성 필요?
3. 접근법 제안 — 여러 아키텍처 옵션을 제시하고 추천:
   • A: 모놀리스 + Thymeleaf (단순)
   • B: 모놀리스 + Redis/Kafka 연동 (고성능)
   • C: 모놀리스 + 비동기 이벤트 분석 (추천 — 단순하면서도 성능 보장)
4. 아키텍처 다이어그램 — 비주얼 컴패니언으로 브라우저에 시각화
5. Spring 7 신기능 활용 제안 — API 버전 관리, @Retryable, RestClient 등
6. 데이터 모델 설계 — User, Link, ClickEvent 3개 엔티티. Base62 인코딩, 랜덤 생성, 충돌 처리 전략
7. API 설계 — RESTful 엔드포인트 정의
8. 스펙 문서 작성 + 셀프 리뷰 — AI가 스스로 리뷰하여 누락·불일치 수정
9. 구현 계획 수립 — Phase 분할, 태스크 리스트, 샘플 코드 포함

"똑똑한 동료 내지는 컨설턴트 한 명 앞에 앉혀두고 '이런 거 개발하고 싶은데' 하면 질문을 막 하면서 설계를 해주는 딱 그 느낌."

---

7. 멀티 모델 협업: Codex + Gemini 병렬 리뷰

구조

토비가 만든 "Toby Team" 스킬을 사용. CMUX의 페인 분할 기능을 활용하여 Codex와 Gemini를 각각 독립 페인에 띄우고, 메시지를 전송하여 작업을 의뢰한다.

[메인 페인: Claude Code]  [우측 상단 페인: Codex]  [우측 하단 페인: Gemini]

실행 흐름

1. Claude Code에서 스펙 문서 완성
2. "Toby Team" 스킬 실행 → Codex, Gemini 페인 자동 생성
3. 스펙 파일을 Codex/Gemini에게 전달 + "리뷰해줘" 요청
4. 각 모델이 리뷰하는 동안 Claude Code에서 다른 작업 가능
5. 결과 파일 생성을 백그라운드 프로세스가 감시
6. 리뷰 결과 도착 → Claude Code가 요약하여 표시

Codex 리뷰 결과 (실제 사례)

Codex가 Claude의 설계에서 발견한 문제:

• Spring 7 기능 오해: @RateLimiter는 Rate Limiting이 아닌 Concurrency 제어용. 실제 Rate Limiting은 Redis + Token Bucket 등이 필요.
• 데이터 모델 누락: Soft Delete인데 deletedAt 필드가 없음.
• JWT 정책 분리 필요: API용 토큰과 웹 세션용 토큰의 발급/검증이 분리되어야 함.
• Base62 해시 계산 오류: 문서에 나온 숫자가 실제 계산과 맞지 않음.

"자기 스스로 리뷰했을 때 못 찾았던 걸 코덱스가 찾아줍니다. 코덱스가 코드 리뷰는 제일 날카로워요."

컨센서스 분석

세 모델(Claude, Codex, Gemini)의 의견을 비교:

• 셋 다 동의하는 것 → 즉시 반영
• 둘만 동의하는 것 → Claude Code가 판단
• 셋 다 다른 의견 → Claude Code에게 "정직하게 양심적으로 판단해서 결정하고 진행해봐"

동의하지만 지금 단계에서 불필요한 것 → GitHub Issue로 등록하여 나중에 처리.

---

8. 보안 설정 (Permissions)

Allow 규칙

안전한 명령을 사전 허용하여 매번 확인 불필요하게 만든다.

/permissions → Allow 탭 → Add
예: Bash(gradle*), Bash(git commit*), Bash(ls*), ...

토비의 "Merge Permissions" 스킬: 현재 세션에서 수락한 Allow 항목들을 자동으로 유저 레벨 settings.json에 병합. 다음 프로젝트에서도 다시 수락할 필요 없음.

Deny 규칙

위험한 접근을 원천 차단:

대상	Deny 규칙	이유
~/.ssh/*	Read, Edit 차단	SSH 키 유출 방지
~/.aws/credentials	Read, Edit 차단	AWS 과금 폭탄 방지
.env 파일	Read, Edit 차단 (운영 환경 정보 포함 시)	DB 접속 정보 등 유출 방지
rm -rf	Bash 차단	파일 시스템 파괴 방지
curl (외부 전송)	Bash 차단 (상황에 따라)	정보 외부 유출 방지

"AI가 실수하기보다는 악의적인 프롬프트가 잘못되거나 여러분이 큰 실수를 했을 경우에, 절대로 AI조차도 알면 안 되는 것에 접근하는 것을 차단해야 합니다."

Hook으로 이중 차단

Allow/Deny는 프롬프트 수준의 제한이므로 AI 모델이 가끔 무시할 수 있다. Hook은 코드로 동작하므로 결정적(deterministic)이다.

토비의 "Block Dangerous" 훅: 도구 실행 전에 명령을 검사하여 위험한 패턴(rm -rf, SSH 키 접근 등)이 감지되면 실행을 차단.

"얼라우와 디나이가 무시될 때도 있다고 합니다. 충격이죠. 프롬프트는 제한이지 명령이 아니라서 AI 모델이 가끔 무시합니다. 그래서 훅이 더 필요합니다."

---

9. 대화 기록 저장 (Save Conversation)

문제의식

AI가 100% 코드를 만들어주는 시대에, 코드만 커밋하고 PR을 올리면:

• 리뷰어가 "왜 이렇게 개발했는지" 알 수 없음
• 개발자 본인도 "AI가 만들어준 거라 잘 모르겠고요, AI한테 다시 물어볼게요" 상황 발생
• 동일 프롬프트를 다시 실행해도 AI는 비결정적이므로 같은 결과가 나오지 않음

"자기가 이해도 못 하는 코드를 만들어서 올려놓고 PR 리뷰를 해달라고 요청하는, 이게 좋은 걸까?"

해결: Save Conversation 스킬

커밋 전 자동으로 실행되도록 훅에 연결. 커밋에 포함되는 내용:

• 사용자가 보낸 프롬프트 요약
• AI의 응답 요약
• 사용된 도구/스킬 목록
• 변경된 파일 목록

이를 통해 코드 리뷰 시 "이 개발자가 AI와 어떤 대화를 나누고, AI가 어떤 판단을 해서, 어떤 파일이 변경되었는지"를 추적할 수 있다.

관련 오픈소스 프로젝트: Entire — 더 상세한 대화 기록을 웹으로 시각화하는 도구.

---

10. AI 코딩 철학

"개발은 AI가 해주는 게 아닙니다. 개발은 사람이 하는 거예요."

• 코드 타이핑을 AI가 100% 해도, 설계·리뷰·판단은 사람의 몫.
• Claude Code 팀 자체도 작년 4~5월에는 "80% AI + 20% 사람 코딩"이었지만, 현재는 "100% Claude Code로 만든다"고 발표. 단, 스킬과 하네스를 충분히 잘 만들고, 사람이 꼼꼼하게 리뷰하는 전제 하에.
• 간단한 유틸이나 크롬 익스텐션은 코드를 자세히 안 봐도 됨. 하지만 중요한 비즈니스 코드는 코드 레벨 리뷰가 필요하거나, AI가 신뢰할 수 있는 결과를 낼 만큼 하네스를 잘 구축해야 함.

하네스(Harness)의 최종 정의

• Claude Code 자체가 Claude 모델의 하네스.
• 그 위에 사용자가 스킬·에이전트·훅·퍼미션 등을 추가하면, 그것이 "나만의 하네스를 확장하는 것."
• 스킬 ≠ 하네스. 스킬은 하네스의 구성 요소 중 하나. 스킬들이 모여서 하네스를 이룬다.

"스프링 프레임워크 위에서 개발하듯이, 여러분만의 프레임워크를 클로드 코드 위에 만드는 거예요. 그 안에 클래스도 만들고 설정 파일도 만들듯이, 스킬도 만들고 훅도 만들고."

---

핵심 포인트 요약

1. 워크플로우가 핵심이다. 탐색 → 계획 → 구현 → 커밋 사이클을 모든 규모의 작업에 적용. 계획 단계에 가장 많은 시간을 투자.

2. 세 가지 계획 도구를 상황에 맞게 사용. Plan 모드(가벼운 것), Ralph(중간), Superpowers(깊은 설계).

3. 브레인스토밍부터 시작하라. 새 프로젝트든 기능 추가든 리팩터링이든, Superpowers 브레인스토밍으로 시작하면 체계적인 스펙과 구현 계획이 나온다.

4. 멀티 모델 리뷰는 가치가 있다. Claude가 놓치는 기술적 오류를 Codex가 찾아내고, 세 모델의 컨센서스 분석으로 균형 잡힌 판단이 가능.

5. 보안은 Allow/Deny + Hook 이중 구조. Deny만으로는 AI가 무시할 수 있으므로, Hook으로 코드 수준에서 차단.

6. 대화 기록을 커밋에 포함하라. AI 시대의 코드 리뷰는 코드만이 아니라, "어떤 대화로 이 코드가 나왔는지"도 보아야 한다.

7. 초반 세팅에 가장 많이 투자하라. 코딩 스타일, 아키텍처 규칙, 테스트 정책 등을 CLAUDE.md와 구현 계획에서 꼼꼼하게 잡으면, 이후 AI의 일관성과 품질이 크게 올라간다.

8. 하네스는 계속 유지보수해야 한다. 모델 업데이트마다 스킬을 재평가하고, 불필요한 것은 제거. "하네스 깎는 노인"이라는 표현이 있을 만큼 지속적인 작업.