01핵심 개요
| 항목 | 내용 |
|---|---|
| 형식 | 채널에서 반응이 컸던 세 편(케이브맨 모드로 토큰 87% 절감, RAG를 몇 달 붙잡다 접은 이야기, 매일 쓰는 도구 6개)을 하나로 이어붙인 종합 정리 영상 |
| 화자 | 메이커 에반 — 클로드 코드를 약 10개월간 하루 12시간씩 사용해 온 실사용자, 코드를 손으로 직접 쓰지 않고 AI 도구 운용에 집중 |
| 핵심 문제의식 | 똑같은 리액트 질문에 어떤 사람은 1,214토큰, 어떤 사람은 294토큰만 써서 답을 얻는 차이(비용 4배 이상)는 모델·요금제·버전 차이가 아니라 "무엇을 넣고 무엇을 뺐는가"라는 컨텍스트 구성 방식의 차이에서 발생한다는 문제의식 |
| 핵심 내용 | (1) 컨텍스트 윈도우는 3년간 250배 커졌지만 다 채우면 오히려 성능이 떨어짐(중간 손실 30%+), (2) 출력을 짧게 강제하는 "케이브맨 모드"로 출력 토큰 65~87% 절감 + 정확도 최대 26점 상승, (3) RAG(청크 분할 검색)를 몇 달 시도하다 결국 포기하고 클로드 코드처럼 "필요할 때 검색해서 읽는" 방식으로 전환, (4) 서브에이전트는 "완전히 빈 책상"에서 시작하므로 역할별 상시 에이전트 조직이 아니라 진짜 독립적인 작업에만 한정 사용, (5) 매뉴얼을 50줄 단위로 쪼개 목차+챕터 구조로 만들어 자원 사용량 40~60% 절감, (6) 효과를 느낌이 아니라 컨텍스트 사용량·절약량·세션 생존시간·재설명 횟수 4개 숫자로 측정 |
02핵심 기능/내용 구조
- 컨텍스트 윈도우 확장의 함정: 컨텍스트 윈도우(AI가 한 번에 처리하는 정보량)는 지난 3년간 약 250배 넓어졌지만, 스탠포드 연구에 따르면 긴 내용을 한 번에 넣으면 첫 부분과 마지막 부분은 잘 기억해도 중간 부분은 흘려보내며 해당 구간에서 성능이 30% 이상 하락한다("Lost in the Middle" 현상). 화자 본인도 매뉴얼을 100줄까지 늘렸다가 오히려 헛다리를 짚는 빈도가 늘었고, 이를 목차 1개+상세 챕터 파일 여러 개로 나눠 재구성하자 자원 사용량이 40~60% 줄었다.
- 비용이 새는 3곳: (a) 출력 쪽 — 질문 하나에 "자서전 한 권" 분량 답이 나와 필요한 한 줄을 찾기 어렵고 반복 질문마다 같은 낭비가 재발, (b) 입력 쪽 — 문서를 통째로 밀어넣는 방식은 필요한 부분만 잘라 쓰는 방식보다 최대 82배 더 비쌀 수 있음(연구 인용), (c) 보이지 않는 비용 — 컨텍스트가 지저분해지면 세션이 조기에 죽어 새 대화를 열고 맥락을 처음부터 재설명해야 하는 시간 손실.
- 케이브맨(Caveman) 모드 — 출력 압축: "클로드 코드한테 원시인처럼 말해라"는 한 줄 지시를 시스템에 심어두는 서드파티 도구. 안내문은 "군더더기 빼라 / 짧게 말해라 / 대신 기술 용어는 정확히 써라" 단 3줄이다. 클로드 API 벤치마크(리액트 리렌더 설명, 인증 미들웨어 수정, 도커 빌드 등 개발자 질문 10개)에서 기본 응답 평균 1,214토큰이 케이브맨 모드 적용 시 294토큰으로 줄어(질문당 920토큰, 평균 65%~최대 87% 절감) 감소했으며, 비교 대상이 이미 "짧게 답하라"고 지시해둔 모드였다는 점에서 신뢰도가 높다고 평가. 인용된 논문에 따르면 짧게 답하도록 지시하면 정확도가 오히려 오르며(일부 벤치마크에서 최대 26점 상승), 이는 모델이 길게 말할수록 자기 답변에 스스로 흔들리는 현상을 짧은 지시가 억제하기 때문으로 해석된다. 압축 강도는 라이트/기본/울트라 단계로 조절 가능하며, 부가 기능으로 커밋 메시지 50자 이내 축약(무엇보다 왜 위주), 코드 리뷰 한 줄 요약, 그리고 가장 실속 있다고 꼽은 기능인 매뉴얼 파일 자체를 평균 46% 압축 재작성(세션마다 반복 로드되므로 누적 절감 효과)이 있다.
- RAG를 접고 검색형 로딩으로 전환: RAG(문서를 청크로 쪼개 벡터화 후 질문과 유사한 조각을 검색해 제공)를 몇 달간 시도했으나 청크 분할 시점에서 문맥이 소실돼(예: "마케팅 비용이 전 분기 대비 15% 증가"라는 조각만으로는 어느 회사, 몇 분기인지 알 수 없음) 반복적으로 실패했다. 반면 클로드 코드는 RAG 없이 사람이 낯선 문서를 처음 볼 때처럼 검색으로 필요한 부분만 찾아 읽는 방식(예: 만 줄짜리 파일도 처음 10줄만 읽고 구조 파악 후 필요시 추가로 읽음)을 쓰는데, 이를 라이다(정밀하지만 무겁고 부품 하나에 전체가 흔들림) 대 카메라(단순하지만 데이터가 쌓일수록 좋아짐) 비유로 설명한다. 제대로 된 RAG 구축에는 의미 기반 검색+키워드 검색 병행, 결과 재검토·필터링, 문서 간 관계를 미리 그려두는 그래프 RAG(구축 비용 크고 문서 변경 시 관계도 재작성 필요)까지 필요해 유지 인력이 없다면 신중해야 한다고 조언. 대안으로 (1) 문서가 적으면 자르지 않고 통째로 투입(비용은 높지만 맥락 보존), (2) 청크를 자르기 전에 전체 문서에서의 위치를 설명하는 태그를 붙이는 방식(앤트로픽 발표 기법, 검색 실패율 67% 감소), (3) 단락별 요약본만 검색 인덱스로 저장하고 실제 응답 시엔 원문 단락을 통째로 제공하는 방식(화자가 가장 효과를 본 방법)을 제시한다.
- 서브에이전트 — "책상 분리" 원칙: 클로드 코드의 서브에이전트(subagent)는 호출 시 완전히 빈 새 책상에서 시작하며 메인 대화의 서류(맥락)를 전혀 물려받지 않는다. 화자는 CEO/디자인/테스팅 에이전트처럼 역할별 상시 조직을 구성하는 방식을 "최악"이라 평가하는데, 테스팅 에이전트가 메인이 무엇을 만졌고 어디서 깨졌는지 모른 채 검사만 하는 상태가 되기 때문이다. 원칙은 "진짜로 독립적인 일"(문서 조사, 예제 수집, 후보 비교 등 결과만 받으면 끝나는 작업)에만 서브에이전트를 쓰고, 지시는 평소보다 길게(무엇을·왜·범위를 매번 명시) 작성하는 것이다. 이렇게 분리하면 보통 30분에 망가지던 메인 대화가 2시간까지 유지되며, 화자의 실제 운용은 계획 수립 → 서브에이전트에 작업 분배 → 별도 서브에이전트가 결과를 "지시 이행 여부"와 "코드 품질" 2단계로 검토 → 가능하면 다른 회사 모델(예: 코덱스)을 교차 검토에 투입(같은 모델끼리는 자기 실수를 잘 못 잡음) → 워크트리로 작업 공간을 물리적으로 분리(보통 3개 동시 운용)하는 순서다.
- 오늘 저녁에 바꿀 수 있는 5가지 실천: (1) 클로드 데스크탑 앱 초기 설정으로 매뉴얼(CLAUDE.md) 자동 생성 — 무엇을 만드는지·어떤 도구를 쓰는지·결과를 어떻게 검증할지(체크리스트) 3요소 필수 포함, (2) 매뉴얼을 50줄 안팎에서 잘라 챕터별 파일로 분리하고 절대 룰 섹션은 맨 위에 배치, 같은 실수 2회 반복 시 매뉴얼을 그 자리에서 즉시 수정, (3) 키워드·의도·작업 위치·파일 내용 4가지 조건으로 관련 매뉴얼을 자동 호출하는 전/후 훅(hook) 설치, (4) 큰 작업 시작 시 계획서·맥락노트·할일 체크리스트 3개 문서를 먼저 생성해 대화가 끊겨도 복귀 좌표를 남기고, 계획 승인 즉시 문서로 저장 후 새 대화를 열어 이어가기, (5) 작업 완료 시 요약이 걸리기 전에 먼저 대화를 비우고 필요한 노트만 불러오기.
- 모델 혼합 전략: "오퍼스 플랜" 모드로 계획은 오퍼스가, 코드 작성은 소네트가 담당하도록 역할을 분리해 비싼 모델은 판단에만, 저렴한 모델은 반복 작업에 투입한다. 회사 업무는 비싼 모델, 사이드 프로젝트는 저렴한 모델로 구분하며, 완성된 결과물을 코덱스로 재검토하는 데는 토큰을 아끼지 않는데 여기서 잡히는 실수 하나가 아낀 토큰보다 가치 있다고 판단하기 때문이다.
- 효과 측정 4지표: 느낌이 아니라 숫자로 확인해야 한다며 (1) 현재 컨텍스트 사용량(화면 하단 플러그인으로 상시 표시), (2) 케이브맨 모드 등으로 절약된 토큰량·환산 비용(누적 표시), (3) 새 대화 시작부터 답변이 흐려지기 시작하기까지의 생존 시간(목표: 약 2시간), (4) 같은 설명을 반복한 횟수(3회 초과 시 그날 세팅에 결함이 있다는 신호)를 매일 기록할 것을 제안. 전체 세팅 구축에 이틀이 걸렸지만 이후 생산성이 10배 이상 늘었다고 언급하며, 시간이 부족하면 매뉴얼 쪼개기(40~60% 절감) 하나만 먼저 적용해도 된다고 조언한다.
03기술적 맥락
이 영상이 다루는 핵심은 컨텍스트 엔지니어링이 모델 성능·요금제보다 실질적인 비용·품질 결정 요인이라는 점이다. 스탠포드의 "Lost in the Middle" 유형 연구(중간 구간 성능 30%+ 하락)와 청크 분할 시 문맥 손실 문제는 컨텍스트 윈도우 확장이 곧바로 활용 가능한 용량 확장을 의미하지 않음을 보여주며, 이는 클로드 코드의 서브에이전트가 메모리를 공유하지 않고 완전히 새로 시작하는 설계, RAG의 청크-검색 구조가 갖는 근본적 한계(문맥 없는 조각 검색)와 궤를 같이한다. 케이브맨 모드가 출력 길이를 줄이면서 정확도까지 올린다는 결과(최대 26점 상승)는 LLM의 장문 출력이 자기 일관성을 해치는 방향으로 작용할 수 있음을 시사하며, 이는 프롬프트 엔지니어링에서 "간결성이 곧 정확성"이라는 반직관적 원칙을 뒷받침한다. 앤트로픽이 발표한 청크 앞에 위치 설명을 붙이는 기법(검색 실패율 67% 감소)과 화자가 직접 고안한 "요약본 검색 + 원문 응답" 이원화 방식은 순수 RAG와 순수 컨텍스트 전체 투입 사이의 실용적 중간 지점을 모색하는 최신 실무 패턴을 보여준다.
04전략적 의미
첫째, 모델·요금제 업그레이드보다 컨텍스트 구성 방식(무엇을 넣고 빼는가)이 비용·품질 양쪽에서 더 큰 레버리지를 갖는다는 점은, AI 도구 비용 최적화의 우선순위를 "더 좋은 모델 찾기"에서 "컨텍스트 위생 관리"로 재조정해야 함을 시사한다. 둘째, RAG가 만능 해법이 아니라는 실사용 경험(몇 달간의 시행착오 끝 포기)은 RAG 도입을 검토하는 조직에게 문서량·유지 인력·검증 가능한 대안(검색형 로딩, 위치 태그, 요약-원문 이원화)을 먼저 저울질하라는 신호를 준다. 셋째, 서브에이전트를 "역할별 상시 조직"이 아니라 "독립 작업 전용 일회성 파견"으로 써야 한다는 원칙은, 멀티에이전트 시스템 설계에서 흔히 범하는 "회사 조직도 모사" 오류(빈 컨텍스트 문제 무시)를 정면으로 지적하며 향후 에이전트 오케스트레이션 설계 시 컨텍스트 상속 여부를 최우선 설계 변수로 삼아야 함을 시사한다. 넷째, 서로 다른 모델(클로드-코덱스)을 교차 검토에 투입하는 관행은 동종 모델 간 자기 확증 편향을 줄이는 실무적 해법으로, 향후 멀티모델 워크플로우 설계의 표준 패턴으로 확산될 가능성이 있다.
05핵심 워크플로우 또는 비교표
| 항목 | 기존 방식(문제) | 개선 방식 | 효과(수치) |
|---|---|---|---|
| 출력 길이 | 질문마다 자서전급 장문 응답 | 케이브맨 모드(군더더기 제거·기술용어 정확 유지 지시) | 평균 1,214→294토큰(65~87% 절감), 정확도 최대 26점 상승 |
| 매뉴얼 구조 | 한 파일에 룰 전부 몰아넣기(100줄+) | 목차 1개 + 챕터별 파일 분리, 50줄 안팎 유지 | 자원 사용량 40~60% 절감 |
| 문서 활용 | RAG(청크 분할 벡터 검색) | 검색형 로딩(필요 부분만 그때그때 읽기) 또는 위치 태그·요약-원문 이원화 | RAG 대비 문맥 손실 방지, 위치 태그 시 검색 실패율 67% 감소(앤트로픽) |
| 대량 문서 투입 | 문서 통째로 프롬프트에 삽입 | 필요한 조각만 검색해 투입 | 통째 투입이 최대 82배 더 비쌈(청크 검색 대비) |
| 멀티 작업 | 역할별 상시 에이전트 조직(CEO/디자인/테스팅 등) | 독립 작업에만 한정된 일회성 서브에이전트 + 긴 지시문 | 대화 생존시간 30분 → 최대 2시간 |
| 결과 검증 | 동일 모델이 자기 결과 재검토 | 타사 모델(코덱스 등) 교차 검토 | 동일 모델이 놓친 오류를 다수 발견 |
06활용 시나리오
- 클로드 코드/Copilot 등 AI 코딩 도구 헤비유저: 매뉴얼(CLAUDE.md류)을 50줄 단위 챕터로 쪼개고 절대 룰 섹션을 최상단에 배치하는 구조로 재작성해 자원 사용량을 즉시 40~60% 절감하고, 케이브맨류 출력 압축 지시를 시스템 프롬프트에 추가해 토큰 비용을 줄이는 데 바로 적용할 수 있다.
- 사내 문서 기반 챗봇/RAG 시스템 구축 담당자: RAG 도입 전 문서량과 유지 인력을 먼저 점검하고, 문서가 적으면 통째 투입, 많으면 청크에 위치 설명 태그를 붙이거나 요약본 검색+원문 응답 이원화 구조를 우선 검토해 청크 분할로 인한 문맥 손실 문제를 사전에 회피하는 데 참고할 수 있다.
- 멀티에이전트 오케스트레이션 설계자: 역할별 상시 에이전트 조직을 만들기 전에 각 서브에이전트가 메인 컨텍스트를 상속받지 못한다는 제약을 먼저 검증하고, 진짜 독립적인 작업(조사·비교·수집)에만 서브에이전트를 배정하며 지시문을 충분히 길게 작성하는 설계 원칙을 적용할 수 있다.
- AI 도구 비용 관리 담당자/팀 리드: 컨텍스트 사용량·절약 토큰량·대화 생존시간·재설명 횟수 4개 지표를 팀 차원에서 매일 트래킹하는 대시보드를 구축해, 느낌이 아닌 숫자로 컨텍스트 관리 개선 효과를 검증하고 우선순위를 정하는 데 활용할 수 있다.
07현황 및 전망
화자는 컨텍스트 관리 세팅 전체를 구축하는 데 이틀이 걸렸지만 이후 생산성이 10배 이상 향상됐다고 밝히며, 특히 매뉴얼을 챕터별로 쪼개는 작업(40~60% 절감)이 투입 대비 가장 효율이 높았다고 평가한다. 케이브맨 모드처럼 출력을 압축하는 서드파티 도구, 앤트로픽이 공식 발표한 청크 위치 태그 기법 등 커뮤니티·기업 양쪽에서 컨텍스트 효율화 도구가 계속 등장하고 있어, RAG 중심의 기존 접근에서 "검색형 로딩"과 "요약-원문 이원화" 같은 하이브리드 방식으로 실무 트렌드가 이동하는 초기 단계로 보인다. 화자는 도구를 한꺼번에 다 설치하지 말고 하나씩 늘려갈 것과, 별점 조작이 흔해졌으니 도구 선택 시 별점만 믿지 말 것을 권고하며, 컨텍스트 관리 원칙("신선하게, 압축돼 있게, 관련 있게")이 특정 도구가 아니라 모든 LLM 사용에 보편적으로 적용된다는 점을 강조하며 영상을 마무리한다.
08용어 사전
| 용어 | 한줄설명 | 비유 |
|---|---|---|
| 컨텍스트 윈도우(Context window) | AI가 한 번에 처리할 수 있는 정보의 최대 양 | 작업 책상의 넓이 |
| Lost in the Middle(중간 손실 현상) | 긴 입력의 처음과 끝은 잘 기억하지만 중간 부분 정보를 놓치는 현상 | 두꺼운 계약서를 한 번에 훑으면 가운데 페이지만 기억 안 나는 것 |
| 케이브맨(Caveman) 모드 | AI에게 군더더기 없이 짧고 정확한 기술 용어로만 답하게 강제하는 서드파티 설정 도구 | 원시인처럼 필요한 말만 하도록 시키는 것 |
| RAG(검색증강생성) | 문서를 청크로 쪼개 벡터화한 뒤 질문과 유사한 조각을 검색해 답변에 활용하는 기법 | 책 한 페이지만 찢어서 건네주는 방식(맥락 없이) |
| 그래프 RAG | 문서 간 인용·참조 관계를 미리 그래프로 그려두고 검색에 활용하는 고급 RAG 방식 | 문서들 사이의 관계도를 미리 그려둔 지도 |
| 서브에이전트(Subagent) | 메인 대화와 완전히 분리된 새 컨텍스트에서 독립적으로 작업을 수행하는 클로드 코드의 분신 기능 | 완전히 빈 책상에서 새로 시작하는 대리 직원 |
| 워크트리(Worktree) | 하나의 코드 저장소에서 여러 작업 공간을 물리적으로 분리해 동시에 작업할 수 있게 하는 Git 기능 | 같은 사무실을 여러 개의 분리된 방으로 나누는 것 |
| 오퍼스 플랜(Opus Plan) 모드 | 계획 수립은 고성능 모델(오퍼스), 실제 코드 작성은 경량 모델(소네트)로 역할을 나누는 운용 방식 | 비싼 컨설턴트는 전략만, 실무자는 실행만 담당하는 분업 |