- 단일 AI 어시스턴트와 동기적 루프로 협업하던 방식에서, 여러 에이전트가 각자의 컨텍스트 윈도우와 파일 범위를 가지고 비동기적으로 동작하는 오케스트레이터 모델로의 전환이 2026년 현재 진행 중
- 서브에이전트(Subagents), 에이전트 팀(Agent Teams), 계층적 위임 등 3가지 핵심 패턴이 멀티 에이전트 코딩의 기본 구조를 이루며, 각각 병렬성·전문화·격리·복합 학습이라는 효과를 제공
-
공유 태스크 리스트와 피어 투 피어 메시징이 에이전트 팀의 핵심 조율 메커니즘으로, 의존성 자동 해제와 병목 방지를 가능하게 함
- 2026년 기준 도구 생태계는 인프로세스 서브에이전트(Tier 1), 로컬 오케스트레이터(Tier 2), 클라우드 비동기 에이전트(Tier 3)의 세 계층으로 구분되며, 대부분의 개발자는 세 계층 모두를 용도에 맞게 혼합 사용
- 병목은 코드 생성이 아닌 검증(Verification) 으로 이동했으며, 플랜 승인·훅(Hooks)·AGENTS.md를 통한 품질 게이트와 인간 리뷰가 멀티 에이전트 체계의 신뢰성을 결정하는 핵심 요소
현재의 전환: 지휘자에서 오케스트레이터로
- 6개월 전까지 대부분의 개발자는 단일 AI 어시스턴트와 동기적으로 작업했으며, 단일 컨텍스트 윈도우가 작업의 상한선이었음
- 현재 가장 생산적인 개발자들은 각자의 컨텍스트 윈도우와 파일 범위, 책임 영역을 가진 여러 에이전트를 비동기적으로 조율하는 방식으로 전환됨
-
컨덕터(Conductor) 모델: 단일 에이전트를 실시간 동기 방식으로 안내; Claude Code CLI, Cursor 에디터 내 에이전트 모드가 대표 도구
-
오케스트레이터(Orchestrator) 모델: 각자의 컨텍스트 윈도우를 가진 여러 에이전트를 비동기 조율; Agent Teams, Conductor, Codex, Copilot Coding Agent가 대표 도구
- 오케스트레이터로서는 명확한 스펙 작성, 작업 분해, 결과물 검증이라는 새로운 역량이 필요함
AI 지원 코딩의 8단계
-
[오케스트레이션]
-
L8 — 나만의 오케스트레이터 구축: 에이전트 생성·라우팅·관리를 직접 코드로 작성하는 코디네이션 레이어를 스스로 구현
-
L7 — 에이전트 10개 이상, 수동 관리: "이런, 엉망이 됐다." 잘못된 컨텍스트가 잘못된 에이전트에게 전달되며 "Claude Code가 Claude Code를 실행하면 어떨까?"라는 질문이 시작됨
-
L6 — 에이전트 멀티플렉싱: 기다리기 지루해서 에이전트를 하나씩 더 실행, 여러 스트림 사이를 오가다 멈출 수 없는 상태
-
[에이전트 우선]
-
L5 — 에이전트 우선, IDE는 나중: 에이전트 대화가 주작업 공간, IDE는 코드 확인용
-
L4 — diff가 사라지고 대화가 주도: 매번 diff를 검토하지 않고, 에이전트 행동을 관찰하며 방향 제시에 집중
-
[IDE 시대]
-
L3 — YOLO 모드: 에이전트가 IDE에서 자유롭게 실행, 신뢰 상승
-
L2 — IDE 내 에이전트, 권한 수동 승인: 모든 파일 변경을 직접 허가, 완전 수동 제어
-
L1 — AI 없음: 전통적인 개발 워크플로우
- Steve Yegge가 정리한 AI 도구 활용 8단계 프레임워크 기준으로, 대부분의 개발자는 레벨 3~4에 머물러 있음
- 오케스트레이션 계층은 레벨 6부터 시작하며, 레벨 5까지 올라온 역량과는 근본적으로 다른 스킬셋을 요구
- 이 내용은 레벨 5~8을 다룸
단일 에이전트의 한계
-
컨텍스트 과부하: 단일 에이전트는 보유 가능한 정보량이 제한되며, 대규모 코드베이스는 단일 컨텍스트 윈도우를 압도함
-
전문화 부재: 데이터 레이어, API, UI, 테스트를 모두 처리하는 에이전트는 제너럴리스트에 불과하며, 데이터 레이어만 전담하는 에이전트가 훨씬 우수한 DB 코드 작성
-
조율 부재: 헬퍼 에이전트를 추가해도 서로 소통·태스크 공유·의존성 해결이 불가능하며, 조율 프리미티브 없이 에이전트를 늘릴수록 관리 난이도가 높아짐
- 서브에이전트는 처음 두 문제를, 에이전트 팀은 세 가지 문제 모두를 해결
멀티 에이전트의 이유
-
병렬성 (3배 처리량): 프론트엔드·백엔드·테스트 에이전트가 동시에 작업
-
전문화 (집중된 컨텍스트): 각 에이전트는 자신이 담당하는 파일만 인식;
db.js만 아는 에이전트가 전체 코드베이스를 다루는 에이전트보다 더 나은 DB 코드 작성
-
격리 (안전한 실행): Git 워크트리가 각 에이전트에게 독립적인 작업 디렉터리 제공, 병합 충돌 없음
-
복합 학습:
AGENTS.md 파일이 세션 간 패턴과 주의사항을 축적하여 매 세션이 다음 세션을 개선
- 집중된 에이전트 3개가 3배 오래 작업하는 제너럴리스트 에이전트 1개보다 일관되게 높은 성과
패턴 1: 서브에이전트 — 집중된 위임
- Task 도구를 사용해 부모 오케스트레이터에서 전문화된 자식 에이전트를 생성; 가장 단순한 멀티 에이전트 패턴으로 먼저 시도해볼 것
- 구체적 예시: Claude Code에 "Express와 SQLite로 북마크 매니저 Link Shelf를 구축하라"는 프롬프트를 주면, 부모 오케스트레이터가 세 서브에이전트 브리프로 분해
-
데이터 레이어 서브에이전트:
db.js 구축 후 DATA.md 보고서 작성
-
비즈니스 로직 서브에이전트:
validation.js 구축 후 LOGIC.md 보고서 작성
-
API 라우트 서브에이전트:
DATA.md와 LOGIC.md를 읽은 후 server.js 구축
- 처음 두 서브에이전트는 독립적으로 병렬 실행, 세 번째는 두 보고서 완료 후 시작; 부모가 의존성 그래프를 수동 관리
- 서브에이전트의 한계: 부모가 의존성 그래프를 수동 관리해야 하며, 에이전트 간 피어 메시징·공유 태스크 리스트 없음; 파일 범위 관리가 느슨하면 충돌 발생 가능
- 총 약 22만 토큰으로 비용 중립적 수준
-
계층적 서브에이전트 (팀의 팀)
- 오케스트레이터가 6개 서브에이전트를 직접 생성하는 대신, 피처 리드 2명을 생성하고 각 피처 리드가 자체적으로 전문가 2~3명을 생성하는 구조
- 부모 오케스트레이터는 두 에이전트만 관리하여 컨텍스트를 깔끔하게 유지; 피처 리드 A는 "검색 기능 구축"이라는 브리프를 받아 자체적으로 분해
- 실제 엔지니어링 조직의 운영 방식과 동일한 원리: VP가 개별 엔지니어에게 직접 태스크를 배정하지 않고 테크 리드를 통해 전달
패턴 2: 에이전트 팀 — 진정한 병렬 실행
- Claude Code의 실험적 기능으로,
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 명령으로 활성화
-
아키텍처 3계층:
- 팀 리드(Team Lead): 작업 분해, 태스크 리스트 생성, 결과 종합
-
공유 태스크 리스트: 상태(pending, in_progress, completed, blocked)·의존성 추적·파일 잠금
-
팀원(Teammates): 각자 독립적인 Claude Code 인스턴스, 자체 컨텍스트 윈도우 보유, tmux 분할 패널에서 실행
- 팀원은 공유 리스트에서 태스크를 자율 선택하며, 피어 투 피어 메시징으로 직접 소통(리드를 거치지 않음)
- 한 팀원이 태스크 완료 후 완료 표시를 하면, 이에 의존하던 블로킹된 태스크가 자동으로 잠금 해제
-
Ctrl+T로 태스크 리스트의 시각적 오버레이 토글 가능
-
에이전트 팀 핵심 메커니즘
-
공유 태스크 리스트: 백엔드 팀원이 검색 API를 완료로 표시하면, 블로킹된 테스트 작성 태스크가 자동으로 pending 상태로 전환; 파일 잠금으로 동시 편집 방지
-
피어 메시징: 백엔드 에이전트가 프론트엔드 에이전트에게 API 계약을 직접 전달 — "GET /search?q= returns [{id,title,url}]"; 리드가 조율 병목이 되는 것을 방지
- 팀원이 유휴 상태가 되면 리드에게 자동 알림
-
에이전트 팀 핵심 권장 사항
-
3~5명의 팀원이 최적점; 토큰 비용은 팀 규모에 비례해 선형 증가
-
플랜 승인: 팀원이 구현 전 플랜을 작성하면 리드가 검토·승인 또는 거부; 코드가 존재하기 전에 아키텍처 문제를 발견하는 것이 훨씬 저렴함
- 집중된 팀원 3명이 산만한 팀원 5명보다 일관되게 우수한 성과
-
에이전트 팀 신뢰성 팁
-
루프 가드레일 + 반성 단계: 모든 팀원에게
MAX_ITERATIONS=8 상한선 설정; 각 재시도 전 "무엇이 실패했나? 어떤 구체적 변경이 수정을 가져올까? 같은 접근 방식을 반복하고 있나?"라는 반성 프롬프트 강제 → 교착 에이전트 발생 대폭 감소
-
전담 @reviewer 팀원: Claude Opus 4.6(읽기 전용)을 reviewer로 지정, lint·테스트·보안 스캔 도구만 사용, 매 TaskCompleted 이벤트에 자동 트리거; 빌더 3~4명당 reviewer 1명 비율; 리드는 항상 검토 완료된 코드만 수신
패턴 3: 규모에서의 오케스트레이션
- 5개, 10개, 20개 이상의 에이전트를 여러 레포와 피처에 걸쳐 관리할 때는 전용 오케스트레이션 도구가 필요
-
Tier 1 — 인프로세스 서브에이전트·팀: Claude Code 서브에이전트·에이전트 팀; 단일 터미널 세션, 추가 도구 불필요; 여기서 시작
-
Tier 2 — 로컬 오케스트레이터: 독립된 워크트리에서 여러 에이전트 실행, 대시보드·diff 리뷰·병합 제어 유지; 알려진 코드베이스에서 3~10개 에이전트에 최적; Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents
-
Tier 3 — 클라우드 비동기 에이전트: 태스크 배정 후 노트북을 닫고 PR을 기다리는 방식; 클라우드 VM에서 실행; Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI
- 2026년 대부분의 개발자는 세 계층 모두 사용: Tier 1(인터랙티브 작업), Tier 2(병렬 스프린트), Tier 3(야간 백로그 처리)
도구 스포트라이트
-
Conductor by Melty Labs
- Mac에서 멀티 에이전트 오케스트레이션을 시작하는 가장 빠른 방법; 각각 독립된 git 워크트리에서 여러 Claude Code·Codex 에이전트를 병렬 실행
- 시각적 대시보드와 diff 우선 리뷰 UI 제공; API 비용만 부담(무료); macOS 전용(Apple Silicon·Intel)
- 동일 레포에서 3~8개 피처를 병렬 작업하며 시각적 감독이 필요한 경우에 최적
-
Claude Code Web
-
claude.ai/code에서 접근; 완전 브라우저 기반, 터미널 불필요; GitHub 레포 연결 후 태스크 설명 입력 → Anthropic 관리 클라우드 VM에서 실행
- 중간 스티어링, 자동 PR 생성, iOS 앱 접근 지원
-
팀(터미널)은 에이전트와 함께 작업하는 방식, 웹(브라우저)은 위임하고 자리를 비우는 방식
-
GitHub Copilot Coding Agent
- IDE의 Copilot 에이전트 모드(동기·인터랙티브)와 구별; GitHub의 Copilot Coding Agent는 완전 비동기
- 모든 GitHub 이슈를
@copilot에 배정하거나 Agents 패널에서 시작 → GitHub Actions 환경에서 드래프트 PR 생성
- 태그 전에 자체 리뷰 루프 실행; Claude Code·Codex 등 서드파티 에이전트도 동일 패널에서 접근 가능; Slack, Jira, Linear, Azure Boards에서 트리거 가능
-
Jules by Google
- Google의 비동기 클라우드 코딩 에이전트, Gemini 기반; GitHub 레포 연결 → 태스크 설명 → Jules가 플랜 생성 → 승인 후 클라우드 VM에서 실행 → 전체 추론 과정과 터미널 로그가 포함된 PR 반환
- 오디오 체인지로그, 중간 태스크 중단, GitHub 이슈를 직접 파이핑하는 Jules Tools CLI 제공
- 레포의
AGENTS.md를 추가 설정 없이 자동으로 읽음
-
OpenAI Codex Web
- 각 태스크가 GitHub 레포가 사전 로드된 독립된 샌드박스 컨테이너에서 실행
- Web, CLI(오픈소스), macOS 앱, IDE 익스텐션, GitHub 통합을 ChatGPT 계정으로 연결하는 서피스 에코시스템 보유
-
검증 가능한 증거(Verifiable Evidence) 기능: 모든 태스크에 대해 터미널 로그와 테스트 출력의 인용을 반환하여 실행 내역 감사 가능
-
Cursor Cloud Agents + Glass
- 웹, 데스크톱 앱, Slack, Linear, GitHub, API, PWA(cursor.com/agents 설치)에서 에이전트 시작 가능
-
Glass: Cursor의 새 인터페이스로, 에이전트 관리를 기본 화면으로, 기존 에디터는 필요 시 접근하는 보조 도구로 전환
- 전체 생태계 전반에서 컨트롤 플레인이 주요 경험이 되고 에디터가 그 아래 하나의 악기가 되는 패턴을 반영
-
Vibe Kanban
- "둠스크롤링 갭"(에이전트 작업 중 2~5분의 공백) 해결; 태스크 카드 생성 후 "In Progress"로 드래그하면 각자의 워크트리·브랜치 생성
- 보드 내에서 diff 리뷰 및 실행 중 에이전트에 피드백 전송 가능; Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI 등 지원; 크로스 플랫폼(Mac, Windows, Linux), 무료, BYOK
규모 확장을 위한 팁
-
멀티 모델 라우팅
- 모든 태스크에 가장 비싼 모델이 필요하지 않음;
MODEL_ROUTING.md 파일을 생성하여 역할별 라우팅:
- 플랜·아키텍처 → 저렴한 Gemini/Claude/OpenAI 모델
- 구현 → Sonnet, Opus 또는 Codex
- 리뷰 → 전용 보안 모델
-
워크트리 라이프사이클 스크립트
- 세 가지 셸 앨리어스로 반복 작업 자동화:
-
agent-spin <feature>: 워크트리 + 브랜치 생성 + 에이전트 시작
-
agent-merge <feature>: 리베이스 + 리뷰 + PR 생성
-
agent-clean: 완료된 워크트리 제거
- 약 12줄의 bash; Conductor가 이를 시각적으로 처리
-
인간이 작성한 AGENTS.md만 허용
- ETH Zurich Gloaguen et al.의 연구에서 LLM이 생성한 AGENTS.md 파일은 이점이 없으며 평균 ~3% 성공률 저하, 추론 비용 20% 이상 증가를 유발함을 확인
-
개발자가 작성한 컨텍스트 파일은 ~4% 성능 향상 제공
- 에이전트가
AGENTS.md에 직접 쓰는 것을 절대 허용하지 말 것; 리드가 모든 줄을 승인해야 함
- 명확한 섹션으로 간결하게 유지: STYLE, GOTCHAS, ARCH_DECISIONS, TEST_STRATEGY
품질 게이트: 신뢰하되 검증하라
-
세 가지 품질 게이트
-
플랜 승인: 팀원이 코딩 시작 전 플랜 작성 → 리드가 검토·승인 또는 거부 → 구현; 나쁜 플랜을 수정하는 비용이 나쁜 코드를 수정하는 비용보다 훨씬 저렴
-
훅(Hooks): 라이프사이클 이벤트의 자동화된 체크;
TeammateIdle 훅은 에이전트가 작업을 중단하기 전 모든 테스트 통과 여부 확인; TaskCompleted 훅은 완료 표시 전 lint·테스트 실행; 훅이 실패하면 에이전트는 통과할 때까지 계속 작업
-
AGENTS.md를 통한 복합 학습: 발견된 패턴·주의사항·스타일 선호를 포착; 모든 에이전트가 세션 시작 시 읽고 매 세션마다 추가됨
-
병목은 검증으로 이동
- 에이전트가 인상적인 출력을 놀라운 속도로 생성할 수 있음; 그 출력이 정확한지 확신하는 것이 어려운 부분
- 변경 전 통과하는 테스트가 변경으로 인한 회귀를 잡아낼 것을 보장하지 않음
- 에이전트는 기술적으로 유효하지만 중요한 케이스를 놓치는 테스트를 작성할 수 있음
-
컨텍스트 윈도우 한계로 인해 대규모 코드베이스에서 작업하는 에이전트는 현재 뷰 밖의 중요한 제약을 놓칠 수 있음
- 단일 개발자에게는 성가신 엣지 케이스인 불안정한 환경이, 40개 에이전트가 동시에 같은 불안정한 테스트를 마주칠 때는 시스템적 블로커가 됨
- 검증 인프라가 생성 역량을 따라잡을 때까지 인간 리뷰는 선택적 부가 비용이 아닌 안전 시스템
Ralph Loop와 자기 개선 에이전트
-
Ralph Loop 패턴
- Geoffrey Huntley와 Ryan Carson이 대중화; "잠자는 동안 배송"의 배후 패턴; Carson의 독립 도구
ralph(snarktank/ralph)가 핵심 루프를 구현하며, Antfarm 프로젝트는 OpenClaw 위에 멀티 에이전트 오케스트레이션을 추가
-
5단계 사이클: Pick(tasks.json에서 다음 태스크 선택) → Implement(변경 수행) → Validate(테스트·타입·lint 실행) → Commit(체크 통과 시 커밋 및 태스크 상태 업데이트) → Reset(에이전트 컨텍스트 초기화 후 다음 태스크로)
- 핵심 인사이트: 각 반복마다 리셋함으로써 혼동 누적 방지; 작고 범위가 명확한 태스크는 하나의 거대한 프롬프트보다 환각이 적고 더 깔끔한 코드 생성
-
안전 장치: 자동 재시도를 위해 오류를 피드백으로 전달하되, 3회 이상 교착 상태 시 종료 및 재배정; 항상 피처 브랜치에서 작업; 반복·시간·토큰 상한선 설정; 에이전트가 PR 생성 → 병합 전 인간 리뷰
- 컨텍스트 리셋 간 4가지 메모리 채널 유지: git 커밋 히스토리, 진행 로그, 태스크 상태 파일(tasks.json), 장기 의미 기억으로서의 AGENTS.md
-
에이전트를 시간이 지날수록 더 스마트하게
-
REFLECTION.md를 통한 자기 반성: 매 태스크 후 "무엇이 놀라웠나, AGENTS.md에 추가할 패턴 하나, 프롬프트 개선 하나"를 작성하도록 강제; 리드가 검토하고 승인된 학습 내용을 병합
-
토큰 예산과 종료 기준: 에이전트별 상한선 설정(예: 프론트엔드 18만 토큰, 백엔드 28만 토큰); 예산의 85%에서 자동 일시정지 및 리드 알림; 동일 오류에서 3회 이상 교착 시 종료하고 새 에이전트에 재배정
-
Beads / 영구 메모리: Gastown의 "beads" 패턴 — 전체 출처를 가진 모든 결정과 결과의 불변·git 기반 기록; 에이전트가 태스크 그래프와 SQL 주소 가능한 데이터 플레인을 통해 과거 beads 조회; 단순 벡터 기반 RAG가 아닌 구조화된 쿼리 가능한 제도적 기억
이 모든 것을 작동시키는 규율
-
인간의 병목은 버그가 아니라 피처였음
- 인간 속도로 코드를 작성할 때는 일찍 고통을 느낌; 테스트 실패, 코드 리뷰 지적, 중복 발견 — 고통이 즉각적이어서 진행하면서 수정
- 오케스트레이션된 에이전트 군단에서는 자연스러운 병목이 없음; 작은 실수(코드 냄새, 중복, 불필요한 추상화)가 따라잡을 수 없는 속도로 복합 증폭됨
- 루프에서 빠져나온 상태이므로 아키텍처가 새 기능을 허용하지 않게 될 때까지 고통을 느끼지 못함
-
모든 품질 게이트(플랜 승인, 훅, 토큰 예산, 인간 리뷰) 가 존재하는 이유: 없으면 에이전트 코딩으로 스스로를 막다른 골목에 몰아넣게 됨
-
태스크를 위임하되 판단은 보유할 것
-
에이전트에게 맡겨야 하는 것: 명확한 합격/불합격 기준이 있는 범위가 명확한 태스크, 보일러플레이트, 마이그레이션, 테스트 스캐폴딩, 직접 시도할 시간이 없는 접근법 탐색
-
직접 보유해야 하는 것: 아키텍처와 API 설계(에이전트는 훈련 데이터에서 많은 나쁜 아키텍처를 학습해 엔터프라이즈 패턴을 스타트업에 그대로 적용할 수 있음), 만들지 않을 것을 결정하는 일(No라고 말하는 것은 에이전트에게 없는 기능), 전체 시스템 컨텍스트로 에이전트 출력 리뷰
-
자신의 시스템에 대한 이해를 잃으면 수정·확장·오작동 감지 능력을 잃음
-
스펙이 레버리지
- 50개 에이전트를 병렬로 오케스트레이션할 때, 모호한 사고는 단순히 속도를 늦추는 것이 아니라 수십 개의 병렬 실행 전체에 증폭됨
- 평범한 출력과 탁월한 출력의 차이는 거의 전적으로 스펙의 품질에 달려 있음
- 모호한 스펙은 전체 플릿에 오류를 증폭; 명확한 아키텍처·통합 경계·엣지 케이스·불변 조건이 있는 정밀한 스펙은 전체에 걸쳐 정밀한 구현으로 증폭
- 코드를 타이핑하는 기계적 작업은 자동화되는 중; 시스템을 이해하는 인지적 작업은 자율적 작업자 전체 플릿에 걸쳐 증폭됨
팩토리 모델
- 더 이상 단순히 코드를 작성하는 것이 아닌, 소프트웨어를 만드는 팩토리를 구축하는 단계
-
6단계 생산 라인: Plan(수용 기준이 있는 스펙 작성) → Spawn(팀 생성 및 에이전트 배정) → Monitor(5~10분마다 진행 상황 확인·블로커 해결, 호버링 금지) → Verify(테스트 실행·코드 리뷰; 검증이 병목) → Integrate(브랜치 병합·충돌 해결) → Retro(새 패턴으로 AGENTS.md 업데이트; 복합 학습)
-
실용적 팁:
- WIP 한도 설정: 의미 있게 리뷰할 수 있는 것보다 많은 에이전트 실행 금지; 3~5개가 최적점
- 종료 기준 정의: 동일 오류에서 3회 이상 교착 시 중단 및 재배정
- 비동기 체크인: 5~10분마다 진행 상황 확인; 에이전트가 자율적으로 작업하게 할 것
- 파일 하나에 오너 하나: 두 에이전트가 동일 파일을 편집하지 않도록; 충돌은 속도를 죽임
오늘 시작할 5가지 패턴
-
서브에이전트로 분해: Task 도구로 특정 브리프와 파일 소유권이 있는 집중된 자식 에이전트 생성; 설정 불필요; 오늘 시작
-
에이전트 팀으로 병렬성:
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 활성화; 리드 + 팀원 3명 생성; 공유 태스크 리스트로 조율
-
Git 워크트리로 격리: 각 에이전트에 자체 워크트리 제공; 병합 충돌 없음; Conductor가 자동 처리
-
신뢰를 위한 품질 게이트: 위험한 변경에 플랜 승인 요구; 태스크 완료 시 테스트를 실행하는 훅 추가; 검증 없이 에이전트 출력 신뢰 금지
-
AGENTS.md로 복합 학습: 패턴·주의사항·스타일 선호 문서화; 매 세션이 읽고 업데이트; 지식이 복합 증폭됨