AI 스터디 W2 — Extend Claude Code • Eunseo Choi

읽으면서 궁금한 것 - 1. subagents와 agent teams의 차이점

📍궁금한 이유

작업을 할 때 PR 기능에 대해서는 subagents로 FE/BE/Test를 실행하게 시키고 있는데
Subagent랑 Agent teams랑 차이가 뭐지? 📍**가장 큰 차이 = 소통 구조 (둘 다 작업을 병렬화하지만 아키텍처가 다르다)*
Subagent : 메인 세션 안에서 실행되는 격리된 워커 ➡️ 결과를 메인 에이전트에게만 보고함
Agent teams : 서로 독립적인 별도의 Claude Code 세션들 ➡️ 팀원끼리 (독리된 Claude Code 세션들끼리) 서로 직접 메세지를 주고 받음 ==⭐️ 그러면 워커와 Claude Code 세션은 무엇인지? (Subagent도 자체 세션을 갖지 않나? 라는 생각으로 시작된 용어 정리)== agent teams가 좀 더 토큰이 많이 드는 이유

세션이 여러 개 만들어지면서 부담하는 게 많아진다. 세션 (회색 상자)은 자기 혼자서 하나의 완결된 Claude Code 인스턴스이기 때문에, 세션마다 독립적으로
- Antropic이 모델마다 만들어둔 (자기만의) 시스템 프롬프트
- CLAUDE.md 로딩
- git status 등 세션 시작 시 로드되는 컨텍스트
- 도구 스키마, 대화 이력 이러한 것들이 로드되어서 부담하게 됨 -> 토큰 비용이 늘어남…!
대화의 비용이 다름
- Subagent는 각자의 테스크 수행 후, 요약된 내용을 메인세션에게 리포트를 하는 형태
- Agent teams의 경우에는 작업중에 팀원끼리 계속 주고받는 메세지가 있는데 (P2P) 이것 역시 토큰이다보니.. 통신량 자체가 누적이 됨 ==⭐️ 그렇다면 질문.. 기획 스펙을 만들고 > FE/BE 개발 픽스 문서를 만들고 > subagents를 시키면, FE <-> BE간에 소통할만한 일이 안 생길테니 그럼 되는거 아닌가?==

agent teams가 나온 이유는 “이상적으로 그게 항상 가능한 게 아니니까..!”
구현하는 중에 발견되는 것들도 분명히 있음. 예를 들어..
- BE를 짜다보니 스펙에 없던 제약이 발견되면 (ex. 이 필드는 nullable이어야 함), FE에게 바로 알려야 함
- QA가 테스트를 하다가 엣지 케이스를 발견하면 -> BE 로직을 다시 확인해야 함
- FE 요구사항이 실제 구현 중 모호한 부분이 드러나게 됨
subagent의 구조에서는.. (메인에게 return을 던지면 바로 소멸되는 형태인가봄)
- 예를 들면 정보를 찾고, 아티팩트로 정리해줘 - 형태에서는 subagent가 나을수도..

QA (subagent) → "이거 이상한데?" → 메인에게 보고 → 소멸
메인이 이해 → BE (새 subagent 재소환, 이전 기억 없음) → 작업 → 보고 → 소멸
메인이 다시 이해 → FE에게 전달...

📍 내가 하고 있었던 방법

기획서를 작성한다 -> 코드를 탐색하는 서브에이전트 두 개를 보내서 (FE / BE & DATA 확인) 코드 탐색 -> 조사 결과를 토대로 메인 세션에서 개발 문서 작성 -> 하나의 기능을 작업별로 나눔 -> 작업별로 서브에이전트 실행 (BE-DATA, BE-GEN, BE-API, FE-CORE, FE-FLOW) -> 메인세션에서 확인 -> TEST e2e 서브에이전트 실행 -> TEST 결과를 메인 세션에서 받아옴 -> 수정 에이전트 호출 -> 결과를 메인 세션에게 전달 -> 커밋 & 푸시

읽으면서 궁금한 점 - 2. CLAUDE.md와 MEMORY.md의 차이

[!질문] Claude가 규칙이나 명령을 두 번 잘못 수행하면 CLAUDE.md 문서에 추가한다는데, MEMORY.md랑 차이가 뭔지?

CLAUDE.md에 작성한다 = Claude가 반복되는 실수를 하는 것을 보고 사람이 CLAUDE.md파일에 룰을 적상한다.
MEMORY.md에 작성된다 = Claude가 반복되는 실수를 하게 되면, 본인이 직접 작성한다.

알게된 것 : rule이라는 존재..! (이전에는 몰랐음)

⭐️ rule과 skill 의 차이

rule - 트리거가 파일 경로라서 Claude가 src/api/order.ts를 읽으면 -> path : src/api/** rule이 자동으로 로드가 됨 (기계적인 매칭)
- 이 내용은 이 디렉토리를 건드릴 때만 유효하다 - 라는 조건을 걸 수 있게 만든 게 rule
skill - 트리거가 작업 의도 (task) -> 커맨드를 통해 직접 타이핑하거나 Claude가 스스로 “지금 하는 일이 배포와 관련된 일이네” 라고 판단이 되면 자동 로드를 하게 됨

⭐️ 궁금한 점 : rule을 지정한 것 vs 하위 폴더에 CLAUDE.md를 넣어두는 것 nested_claude_md_vs_rules

rule은 hook 처럼 기계마냥 업로드하는 형태인 것 같고, 중첩 CLAUDE.md는 원래 동작하던대로 로드되는 형태인 듯

읽으면서 궁금한 점 - 커맨드는 왜 이 문서에 없지?

/deploy라는 command 자체가 액션 스킬의 한 예시로, 그리고 스킬의 호출 방식으로 흡수되어서 설명되고 있음
추측
Match features to your goal 항목을 보면 - CLAUDE.md, Skill, Subagent, Agent teams, Code Intelligence, MCP, Hook, Artifact - 전부 컨텍스트에 무엇을 언재 로드하느냐를 기준으로 분류가 된 것이고, command 는 스킬을 “언제 트리거하냐”의 문제일 뿐…
세션을 시작하게 되면 context window에 기본적으로 로드되는 항목은
- CLAUDE.md - 전체 내용 로드 (managed, user, project 레벨 전부)
- Skills - 이름 + description 만 로드, 내용 전체는 실제 호출될 때
- MCP 서버 - 툴 이름만 로드, 전체 스키마는 사용 시점에 로드

스터디 후기

금요일 저녁 일정으로 토툐일 새벽 5시에 일어나서 스터디 준비를 했는데 .. 일찍 일어나서 하루가 긴 건 좋은데 약간 피곤한 듯
2주차 발표자님께서 준비해주신 슬라이드에는 “이 docs를 읽고 무엇을 우리가 한 번 업무 환경에 대해서 고민해볼 수 있을까?”를 생각해볼 수 있는 자료였던 것 같다. 이번 docs는 내가 궁금하거나 헷갈리는 방향으로 정리해보았는데,
업무 방식을 고민해보기 - 나의 방식으로 다른 회사에 가서 협업을 한다고 했을 때, 좋은 방식일까? 를 고민해봐야 할 것 같다. 혼자 개발을 하면서 나쁜 습관이 안 들게끔 다른 사람들은 어떻게 현업에서 개발하고 계신지를 많이 접해야 할 것 같다.

장점이자 단점인 것 같은데, 생각보다 현업에서 git worktrees를 이용해서 병렬로 작업을 많이 안하고 계신가? 라는 생각이 들었던 것 같다. 작은 작업 단위에서 워크트리 열어서 사용하고, PR이 너무 큰 경우, 작업 흐름에 맞춰서 PR을 작게 나눌 것