00:00:00클로드 코드는 작년 5월 22일, 클로드 3.5 출시와 함께 정식 버전이 공개되었습니다.
00:00:06하지만 그전에도 리서치 프리뷰 버전이 있었기에, 저는 이 도구를
00:00:11이제 1년 넘게 사용해 오고 있습니다. 실제로 계산을 한번 해봤는데요.
00:00:15클로드에 프롬프트를 입력하고, 코드를 검토하고, 모니터링한 시간을 모두 합치면 2,000시간이
00:00:21넘더라고요. 그래서 여러분께 가르쳐 드릴 게 꽤 많습니다. 이번 영상에서 바로 그 이야기를 하려고 해요.
00:00:27지금부터 제가 실전에서 검증한 모든 전략을 공유해 드리겠습니다. 여러분을
00:00:31초보 클로드 코드 사용자에서 파워 유저로 만들어 줄 전략들이죠. 이 모든 내용을 묶어서
00:00:37저는 'WISC 프레임워크'라고 부릅니다. 이건 진짜 실전 전략입니다. 저는 단순히
00:00:43최근 몇 달 사이에 클로드 코드 열풍에 올라탄 흔한 AI 콘텐츠 제작자가 아닙니다.
00:00:48말씀드렸듯이 저는 1년 넘게 매일 이 도구를 사용해 왔습니다. 따라서 이 전략들은
00:00:54어떤 코드베이스에서도, 심지어 거대한 규모나 여러 개의 코드베이스가 섞인 프로젝트에서도 통합니다.
00:01:00엔터프라이즈 수준에서 적용되는 것도 직접 확인했으니, 여러분이 무엇을 작업하든 도움이 될 겁니다.
00:01:05또한 다른 AI 코딩 어시스턴트에도 적용 가능합니다. 현재로서는 클로드 코드가 가장 뛰어나서 여기에 집중하는 것뿐이죠.
00:01:10여러분이 클로드 코드에 대한 기본적인 이해는 갖추고 있다는 전제하에, 이제 다음 단계로
00:01:15넘어가 보려고 합니다. 만약 AI 코딩 시스템 구축의 기초가 궁금하시다면,
00:01:21여기에 링크해 둔 영상을 참고해 주세요. 오늘 다룰 전략들은
00:01:25복잡하고 지저분해지기 쉬운 실제 코드베이스에서 작업할 때 필요한 '컨텍스트 관리'에
00:01:32초점이 맞춰져 있습니다. 왜냐하면 '컨텍스트 부패(Context Rot)'가 현재 AI 코딩 어시스턴트의 가장 큰 문제이기 때문입니다.
00:01:38클로드 코드의 제한이 100만 토큰으로 늘어났다고 해도 상관없습니다. 우리는 여전히
00:01:43컨텍스트를 가장 소중한 자원으로 여기고, AI 코딩 어시스턴트와 함께 매우 신중하게 설계해야 합니다.
00:01:49W, I, S, C로 구성된 이 프레임워크의 모든 전략은 바로 그 점에 집중하고 있으며,
00:01:56여러분의 프로젝트에 즉시 적용할 수 있는 내용들입니다.
00:02:00이제 하나씩 아주 쉽게 설명해 드릴게요. 그런데 이런 의문이
00:02:05드실 수도 있습니다. "콜, 왜 그렇게 컨텍스트 관리에 집착하나요?"
00:02:11클로드 코드를 2,000시간이나 썼는데 고작 이거냐고요? 제 대답은 "네, 맞습니다"입니다.
00:02:17매우 구체적인 주제처럼 들리겠지만, 지금은 컨텍스트 부패를 어떻게 피할지에 집중해야 할 때입니다.
00:02:23코딩 에이전트가 코드베이스에서 실수하는 원인의 80% 정도는 여러분이
00:02:28컨텍스트 관리를 제대로 하지 못했기 때문이라고 단언할 수 있습니다. 그래서 먼저 컨텍스트 부패 문제를 짚어보고,
00:02:33바로 WISC 프레임워크의 각 부분을 실무적으로 파헤쳐 보겠습니다. 컨텍스트 부패를
00:02:38먼저 설명하는 이유는 그 중요성을 확실히 체감하시기 위해서입니다. WISC 프레임워크를 적용하는 순간,
00:02:45지저분한 코드베이스에서도 AI 코딩의 신뢰도가 비약적으로 상승하는 것을 보게 되실 겁니다.
00:02:50규모가 크고 복잡한 코드베이스일수록 컨텍스트 부패가 치명적인 문제가 되기 때문에
00:02:56이를 계속 강조하는 것입니다. 그동안 업계에서는 컨텍스트 부패에 대한
00:03:02많은 연구가 있었는데요, 그중 제가 가장 좋아하고 실용적인 것은 크로마(Chroma)의
00:03:07기술 보고서입니다. 입력 토큰의 증가가 LLM의 성능에 어떤 영향을 미치는지 다루고 있죠. 핵심은
00:03:13LLM의 컨텍스트 창에 특정 양의 토큰을 넣을 수 있다고 해서, 반드시 다 넣어야 한다는 뜻은 아니라는 겁니다.
00:03:18이는 100만 토큰 제한을 가진 최신 클로드 코드에도 똑같이 적용됩니다.
00:03:24대규모 언어 모델도 사람처럼 너무 많은 정보가 들어오면 압도당하기 때문이죠. 이를
00:03:30소위 '건초더미에서 바늘 찾기' 문제라고 부릅니다. 아주 구체적인 정보나,
00:03:35코딩 에이전트가 읽어야 할 특정 파일이 있을 때, 모델은 단기 기억을 활용해
00:03:41그 정보를 잘 기억해 냅니다. 하지만 컨텍스트 창이 꽉 차지 않았을 때만 가능한 일이죠.
00:03:47엄청난 양의 컨텍스트가 로드되기 시작하면, 이른바 '방해 요소(Distractors)'가
00:03:52발생합니다. 즉, 모델이 찾아야 하는 정보와 비슷하거나 근접해 보이지만,
00:03:58정확히는 틀린 정보들이 섞이는 것이죠. 대규모 코드베이스로 AI 코딩을 할 때 이런 일이 빈번합니다.
00:04:04코드베이스 전반에 걸쳐 동일한 패턴을 따르고 있고,
00:04:09서로 다른 부분들이 유사하게 구현되어 있는 경우가 많기 때문입니다. 그러면 모델은
00:04:14엉뚱한 정보를 끌어와 놓고는 자신의 수정이나 구현이 맞다고 확신하게 됩니다. 아마
00:04:19자주 겪어보셨을 거예요. 이 '건초더미에서 바늘 찾기' 문제가 AI 코딩에서
00:04:24수시로 발생합니다. 이것이 바로 컨텍스트 부패의 개념입니다. 컨텍스트 창이 커질수록,
00:04:30모델은 코딩 에이전트와의 현재 대화 단계에서 정확히 필요한 정보를 뽑아내는 데 어려움을 겪습니다.
00:04:36자, 다시 도표로 돌아가서 더 구체적으로 말씀드릴게요. 우리가 이 모든 전략을 통해 해결하려는
00:04:42질문은 이겁니다. "어떻게 하면 코딩 에이전트에게 필요한 모든 정보를 주면서도
00:04:48컨텍스트 창을 최대한 가볍게 유지할 것인가?" 이것이 바로 우리가 하려는
00:04:53컨텍스트 엔지니어링입니다. 이제 모든 전략을 하나씩 살펴보겠습니다.
00:04:57복잡한 코드베이스를 활용해 실제 예시를 보여드릴 거고요, 예시에 사용된
00:05:02모든 명령어나 규칙, 문서들은 설명란에 링크된 폴더에 담아두었습니다.
00:05:06개념적인 부분뿐만 아니라, 이 예시 명령어들을 활용해 전략을 직접 써보실 수 있습니다.
00:05:12여기 있는 .claude 폴더 안에 들어있죠. 자, 그럼 개별 전략으로 들어가 볼까요?
00:05:17W는 Write(기록), I는 Isolate(격리), S는 Select(선택), C는 Compress(압축)를 뜻합니다.
00:05:24먼저 W, 즉 에이전트의 기억을 외부로 '기록'하는 것부터 시작하겠습니다.
00:05:30가능한 한 주요 결정 사항과 작업 내용을 캡처해 두어야,
00:05:34다음 세션에서 에이전트를 훨씬 빠르게 동기화할 수 있고,
00:05:40요구 사항을 이해시키는 데 드는 초기 토큰 비용을 줄일 수 있습니다. 그 첫 번째 전략은
00:05:46Git 로그를 장기 기억 저장소로 활용하는 것입니다. 저는 이 방법을 정말 좋아합니다.
00:05:52코딩 에이전트를 위해 지나치게 복잡한 기억 관리 프레임워크를 만들려는 분들이 많지만,
00:05:56사실 우리는 이미 버전 관리를 위해 Git과 GitHub을 사용하고 있잖아요. 그러니
00:06:01이미 사용 중인 도구를 활용해 에이전트에게 장기 기억을 제공하면 됩니다. 어떻게 하는지
00:06:07직접 보여드릴게요. 모든 예시에서 사용할 코드베이스는
00:06:12새로운 '아콘(Archon)'입니다. 지난 몇 달 동안 제가 뒤에서 정말 열심히 작업한 프로젝트죠.
00:06:18이건 장기 실행 AI 코딩 워크플로우를 생성, 관리, 실행할 수 있는 여러분의 AI 커맨드 센터입니다.
00:06:23심지어 워크플로우 빌더도 작업 중인데, AI 코딩계의 N8N 같은 존재가 될 거예요. 워크플로우를 시작하고,
00:06:28미션 컨트롤에서 로그를 모니터링할 수도 있습니다. 지난 실행 기록을 보며
00:06:33무슨 일이 있었는지 정확히 확인할 수도 있죠. 지금 보시는 건 코드베이스의 모든
00:06:39풀 리퀘스트를 검증하기 위한 아주 긴 워크플로우입니다. 이 화면만 보셔도
00:06:44아시겠지만, 아콘은 앞으로 공개될 기능도 많고 상당히 복잡한 구조로 되어 있습니다.
00:06:47그래서 제가 설명해 드릴 모든 전략을 보여드리기엔 최적의 예시죠.
00:06:51매우 까다로운 코드베이스니까요.
00:06:57Git을 장기 기억으로 활용하는 예시를 보여드리자면, 여기 최근의
00:07:03모든 커밋 메시지를 가져오는 간단한 명령어가 있습니다. 여기서 주목할 점은
00:07:09커밋 메시지를 생성하는 매우 표준화된 방식이 있다는 것입니다. 머지 기록뿐만 아니라
00:07:13기능 구현과 수정 사항들도 모두 포함되죠. 제가 이렇게 형식을 표준화한 이유는
00:07:19커밋 메시지만 보고도 코딩 에이전트에게 최근에 무엇을 작업했는지 알려줄 수 있기 때문입니다.
00:07:24대부분의 경우 그 기록이 다음 작업의 가이드가 되거든요. 제가 형식을
00:07:29표준화할 수 있었던 비결은 바로 커밋 명령어를 사용하기 때문입니다. Git 커밋 자체는 쉽지만,
00:07:36메시지를 표준화하고 코딩 에이전트의 도움을 받으려면
00:07:40특정 명령어를 두는 게 매우 강력합니다. 여기 코딩 에이전트와 단일 컨텍스트 창에서
00:07:46작업을 마친 상태가 있습니다. 이제 커밋을 할 준비가 다 되었죠.
00:07:51여기서 그냥 `/commit`만 입력하면 됩니다. 그러면 제가 작업 내용을 기록하는
00:07:55표준화된 방식대로 명령어가 실행됩니다. 또한 제 규칙이나 명령어를 개선한 내용도 반영되죠.
00:08:01즉, '우리가 무엇을 만들었는지'와 'AI 레이어를 어떻게 개선했는지'를 모두 담은 2부 구성의 명령어입니다.
00:08:06이제 커밋이 생성될 텐데, 결과가 어떤지 보여드릴게요.
00:08:10자, 커밋 메시지를 보면 CLI에 대한 테스트 개선 사항이 적혀 있습니다.
00:08:14아주 깔끔한 접두사와 함께 상세 내용이 담겨 있죠. 또한 코딩 에이전트가
00:08:19자신의 규칙과 명령어가 어떻게 진화하는지 알 수 있도록, 예를 들어 'plan' 명령어를 개선할
00:08:23기회가 있을 때마다 그 내용을 커밋 메시지에 포함합니다.
00:08:29당연히 이 커밋 명령어는 제가 저장소에 공유해 드린 리소스에 포함되어 있습니다.
00:08:33이걸 시작점으로 사용하시되, 여러분의 스타일에 맞게
00:08:37커밋 메시지 형식을 커스텀해 보시길 권장합니다. 핵심은 메시지를 표준화하고
00:08:41상세하게 기록하여 장기 기억으로 활용하는 것입니다. 자, 두 번째 '기록' 전략은
00:08:47코드를 작성할 때마다 항상 '새로운 컨텍스트 창'에서 시작하는 것입니다. 어떤 작업을 하든
00:08:53제 워크플로우는 항상 이렇습니다. 먼저 에이전트와 한 번의 대화를 통해 계획을 세웁니다. 구조화된 계획이 담긴
00:08:57마크다운 파일을 하나 만들고, 구현 단계로 넘어가서 새 세션을 열 때 그 파일만
00:09:03유일한 컨텍스트로 보냅니다. 따라서 이 명세서에는 에이전트가 코드를 쓰고
00:09:08검증하는 데 필요한 모든 컨텍스트가 들어있어야 합니다. 예를 들어, 이 대화에서
00:09:14저는 오직 계획만 세우고 있습니다. 먼저 시작을 위해 'prime' 명령어를 실행하는데, 이건 이따 설명할게요.
00:09:18컨텍스트를 로드한 뒤 이 명령어로 계획을 세웁니다. 이것 역시 여러분께
00:09:24제공해 드리는 리소스 중 하나입니다. 이 명령어는 기본적으로 코딩 에이전트에게
00:09:28단일 마크다운 문서에 담아야 할 정확한 구조를 알려줍니다. 우리의 단기 기억을
00:09:33하나의 문서로 옮기는 것이죠. 그리고 여기서 세션을 종료합니다. 이제 완전히 새로운 컨텍스트 창으로
00:09:38가서 구현을 시작합니다. 여기 제 'execute' 명령어가 있는데요,
00:09:42여기서 구조화된 계획 파일의 경로를 지정합니다. 다른 컨텍스트는 필요 없습니다. 이 파일 안에
00:09:48필요한 모든 게 있어야 하니까요. 이 방식은 코딩 에이전트가 현재 작업에 극도로 집중하게
00:09:53만들어 주기 때문에 매우 중요합니다. 계획을 세운 곳에서 그대로 구현까지 하게 되면
00:09:57조사 자료 같은 것들이 섞여서 컨텍스트 창이 지저분해지기 쉽거든요. 에이전트의 기억을 외부로 기록하는
00:10:03마지막 W 전략은 진행 상황 파일과 결정 로그입니다. 좀 더 정교한
00:10:08AI 코딩 프레임워크를 보면 `handoff.md`나 `todo.md` 같은 파일을 통해
00:10:13하위 에이전트끼리, 혹은 에이전트 세션끼리 소통하는 것을 자주 보셨을 겁니다.
00:10:17컨텍스트가 부족해질 때, 방금 완료된 작업의 요약본을 만드는 것이 좋습니다. 그러면
00:10:22긴 대화로 인해 에이전트가 환각을 일으키며 발생하는 컨텍스트 부패를 끊어내고
00:10:27새로운 세션으로 갈 수 있죠. 물론 대화가 길어지는 걸 피하는 게 가장 좋지만,
00:10:33어쩔 수 없이 길어질 때가 있습니다. 예를 들어, 아콘에서 제가 자주 하는 작업 중 하나는
00:10:38Vercel 에이전트 브라우저 CLI를 써서 브라우저 내 엔드투엔드(E2E) 테스트를 수행하는 것입니다.
00:10:44다양한 사용자 여정을 거치고 예외 케이스를 테스트해야 해서
00:10:49컨텍스트를 아주 많이 잡아먹습니다. 하단을 보시면 컨텍스트를 확인했을 때 벌써 20만 토큰을 썼죠.
00:10:56100만 한도가 있어도 순식간에 차버립니다. 컨텍스트 창에 수십만 개의
00:11:01토큰이 쌓이기 시작하면 에이전트의 성능이 저하되기 시작합니다. 이때
00:11:05`/handoff`를 실행하면 됩니다. 이 명령어는 요약본을 생성하여 다음 세션으로 넘겨줌으로써
00:11:11에이전트가 작업을 이어가게 해줍니다. 이제 다음 에이전트는 창 안에 수십만 개의
00:11:16불필요한 도구 호출 기록 같은 걸 쌓아두지 않아도 됩니다. 이 'handoff' 명령어는 기본적으로
00:11:21이 문서에 무엇을 담아야 할지 과정을 안내하여 다음 에이전트에게 필요한 정보를 전달합니다.
00:11:25자, 이렇게 W 전략들을 살펴봤습니다. 각각의 전략은 주요 결정 사항을 기록하여
00:11:31미래의 에이전트 세션이 빠르게 상황을 파악하게 한다는 점에서 매우 중요합니다.
00:11:36제가 좀 빨리 설명하고 있는데, 이 중 더 자세히
00:11:40알고 싶은 전략이 있다면 댓글로 알려주세요. 각각 주제 하나로 영상을 만들 수도 있으니까요.
00:11:45이제 I, 즉 하위 에이전트를 활용한 '격리(Isolate)'로 넘어가 보겠습니다. 저는 모든 리서치 작업에
00:11:52하위 에이전트를 사용하며, 거의 매 세션마다 활용하고 있습니다. 여기서 중요한 점은
00:11:56메인 컨텍스트를 깨끗하게 유지하는 것입니다. 하위 에이전트를 써서 코드베이스나
00:12:03웹 전체에서 수만, 수십만 토큰 분량의 리서치를 수행하게 한 다음, 딱 필요한 요약본만
00:12:10메인 클로드 코드 컨텍스트 창에 넘겨주는 것이죠. 수만 토큰의 리서치 내용을 직접 로드하는 대신,
00:12:16이제는 500토큰 정도만 쓰면 됩니다. 핵심 정보는 그대로 가져오면서요.
00:12:21앤스로픽의 연구에 따르면, 메인 에이전트가 모든 걸 처리하게 하는 대신 하위 에이전트를 사용해
00:12:28사전에 컨텍스트를 로드하면 성능이 90.2%나 향상된다고 합니다.
00:12:33자, 간단한 예시를 보여드릴게요. 대화의 시작 단계나 아까 말씀드린
00:12:38구조화된 계획을 짜기 전, 즉 기획 단계에서 하위 에이전트를 아주 적극적으로 활용합니다.
00:12:43보세요. 저는 아콘에 워크플로우 빌더를 구축하고 싶습니다.
00:12:50그래서 하위 에이전트 두 개를 띄우려고 합니다. 하나는 코드베이스를 광범위하게 조사해서
00:12:55워크플로우 빌더를 어떻게 구축할지, 아콘에 어떤 의미가 있을지 파악하게 하고, 다른 하나는
00:13:01기술 스택의 베스트 프랙티스에 대해 웹 리서치를 하게 할 겁니다. 예를 들어 리액트를 쓴다면
00:13:06어떤 라이브러리가 좋을지, 그리고 일반적인 워크플로우 빌더는 어떻게 구축하는지 조사하게 하는 거죠.
00:13:12음성 인식 도구를 써서 프롬프트를 보내겠습니다. 자, 됐습니다.
00:13:16이러면 격리 효과뿐만 아니라 속도 면에서도 이득입니다. 하위 에이전트들이 병렬로 실행되어
00:13:21요약본을 가져오면, 메인 에이전트가 그걸 종합해서 최종 보고를 해주니까요.
00:13:26보시는 것처럼 하위 에이전트 두 개가 뒤에서 동시에 돌아가고 있습니다. 각각의
00:13:31로그를 확인할 수도 있고요. 작업이 모두 끝나면 최종 보고서와 함께 돌아올 겁니다.
00:13:36자, 하위 에이전트 작업이 끝났습니다. 메인 컨텍스트 창에서 수십만 개의 토큰을 쓰는 대신,
00:13:41하위 에이전트들이 그만큼의 조사를 수행했음에도 불구하고,
00:13:46우리는 고작 44,000토큰, 즉 창의 4%만 사용했습니다. 이것이 하위 에이전트의 힘입니다.
00:13:53실제 구현 단계에서는 작업 맥락을 다 알아야 하므로 권장하지 않지만,
00:13:57리서치 단계에서는 매우 강력합니다. 격리와 하위 에이전트는 기획 단계에서
00:14:04정말 중요하죠. 하위 에이전트를 활용하는 또 다른 방법은 '정찰(Scout) 패턴'입니다.
00:14:09메인 컨텍스트를 커밋하기 전에 정찰병을 먼저 보내는 것이죠. 코드베이스나
00:14:14문서의 특정 부분이 메인 클로드 코드 세션에 로드할 만큼
00:14:21관련이 있는지 하위 에이전트에게 미리 탐색하게 하는 겁니다. 에이전트가 미리 결정을 내리는 거죠.
00:14:25이건 더 큰 기획을 위해 가져와야 한다거나, 관련 없으니 건너뛰어도 된다는 식으로요.
00:14:30예를 들어, 아콘에는 코드베이스의 특정 부분을 깊게 다루는 마크다운 문서들이 몇 개 있는데,”항상 규칙에 넣어두기엔 너무 무겁습니다. 하지만 가끔
00:14:36로드하고 싶을 때가 있죠. 컨플루언스나 구글 드라이브 같은 곳에
00:14:41컨텍스트를 저장해 두었다고 생각하시면 됩니다. 자, 다시 메인 대화로 돌아가서
00:14:45이렇게 말할 수 있습니다. "하위 에이전트를 띄워서 .claude/docs 폴더를 전부 조사해 줘."
00:14:48"기획을 위해 메인 컨텍스트에 로드해야 할 중요한 문서가 있을까?"
00:14:54이렇게 보내면 에이전트가 판단해서 필요한 것만 로드합니다. 여기 보시면
00:14:59'explore' 하위 에이전트가 실행되었죠. 모든 문서를 찾아서 그중 하나를 로드하라고 권장하네요.
00:15:04그러면 제가 "그래, 로드해 줘"라고 답합니다. 이건 지금 세우는 계획에 정말 중요하니까요.
00:15:09단순 리서치뿐만 아니라, 메인 컨텍스트 창에 꼭 필요한 문서 조각이 있다고 생각될 때
00:15:13이 정찰 패턴을 사용하면 됩니다.
00:15:18이것으로 격리(Isolate)에 대한 설명을 마칩니다. 리서치와 기획 단계에서
00:15:23하위 에이전트를 적극적으로 활용하는 걸 잊지 마세요. 이제 S, '선택(Select)'으로 넘어갑니다.
00:15:28컨텍스트는 '혹시나' 해서가 아니라 '지금 당장' 필요할 때 로드하세요.
00:15:34이게 무슨 뜻이냐면, 어떤 정보가 코딩 에이전트에게 지금 당장 중요하다는 확신이 100% 없다면
00:15:40굳이 로드할 필요가 없다는 겁니다. 이를 돕기 위해 우리는 계층화된 접근 방식을 취합니다.
00:15:46먼저 '전역 규칙(Global Rules)'부터 시작합니다. 에이전트가 항상 인지하고 있어야 하는
00:15:51제약 사항과 컨벤션들이죠. 이 파일은 꽤 간결해야 합니다.
00:15:57저는 보통 500에서 700줄 정도를 유지합니다. 더 적어야 한다고 주장하는 분들도 많지만,
00:16:02아키텍처, 실행 명령어, 테스트 및 로깅 전략 같은 것들이 포함됩니다.
00:16:08이건 아콘의 예시인데, 에이전트가 항상 알고 있어야 하는 필수 정보들입니다.
00:16:12그다음은 레이어 2인 '온디맨드(On-demand) 컨텍스트'입니다.
00:16:18코드베이스의 특정 부분에만 적용되는 규칙들이죠. 가령 우리가 항상 프론트엔드를 작업하는 건 아니지만,
00:16:23프론트엔드 작업을 할 때 필요한 전역 규칙이나, API 엔드포인트를 구축할 때의
00:16:28전역 규칙 같은 것들입니다. 특정 작업 유형에 맞춰서
00:16:33전역 규칙 위에 추가로 얹어주는 것이죠. 항상 프론트엔드 작업만 하는 건 아니니까요.
00:16:38예를 하나 보여드리자면, 아까 'explorer' 하위 에이전트가 가져온 워크플로우 YAML 참조 문서가 있습니다.
00:16:43워크플로우 관련 작업을 할 때는 이게 중요하지만, 평소 아콘을 작업할 때는
00:16:48이 파일이 굳이 전역 규칙에 있을 필요가 없습니다. 코드베이스의 아주 특정 부분이니까요.
00:16:52그래서 이건 온디맨드 컨텍스트로 분류합니다.
00:16:57세 번째 레이어는 '기술(Skills)'입니다. 클로드 코드 등에서 현재 매우 인기 있는 방식이죠.
00:17:05에이전트가 해당 기술이 실제로 필요하다고 판단할 때만
00:17:10그 기술의 지침과 기능을 탐색하는 단계들을 둡니다.
00:17:15먼저 설명(Description)부터 시작하는데, 이건 전역 규칙과 함께 로드되는 아주 적은 양의 토큰입니다.
00:17:20에이전트가 이 기술을 쓰기로 결정하면, 그때 비로소 전체 `skill.md`를 로드합니다.
00:17:25이 파일은 더 깊은 내용이 필요할 경우 다른 스크립트나 참조 문서를 가리킬 수도 있습니다.
00:17:29예를 들어, 저에게는 '에이전트 브라우저' 기술이 있습니다.
00:17:35아까 보여드린 E2E 테스트를 위해 브라우저 자동화에 사용하는 기술이죠. 저는 매일 이 기능을 씁니다.
00:17:40E2E 테스트를 할 때만 이 지침 세트를 로드해서
00:17:46에이전트가 브라우저 사용법을 이해하게 합니다. 마지막 네 번째 레이어는 'Prime' 명령어입니다.
00:17:52지금까지 다룬 것들은 가끔 업데이트되는 정적인 문서들이지만,
00:17:57때로는 에이전트가 현재 활성화된 코드베이스를 직접 탐색해야 할 때가 있습니다.
00:18:02정보가 완전히 최신 상태인지 확인해야 하고, 이를 위해 기꺼이 초기 토큰을 써서 하위 에이전트를 돌릴 용의가 있을 때죠.
00:18:07그게 바로 'prime' 명령어가 하는 일입니다. 기획 단계 시작 시점에 코드베이스를 탐색해서
00:18:11다음에 무엇을 만들지 결정하기 전에 코드를 이해하게 만드는 것이죠.
00:18:16제 'commands' 폴더를 보시면 여러 종류의 prime 명령어가 있는데,
00:18:22만들려는 기능에 따라 에이전트가 이해해야 할 코드베이스의 범위가 다르기 때문입니다.
00:18:27지금 보고 계신 게 일반적인 'prime' 명령어입니다. 아콘 코드베이스를
00:18:32높은 수준에서 파악하라고 지시하죠. Git 로그를 포함해서 단계별로 무엇을 읽어야 할지
00:18:36지정해 두었습니다. Git 로그는 장기 기억 활용을 위해 중요하니까요.
00:18:41또한 아콘의 워크플로우 엔진을 작업할 때를 위한
00:18:47'prime workflows'라는 전문화된 명령어도 있습니다. 비슷하지만 더 특정 영역에 집중된 명령어죠.
00:18:53대화 시작 시점에 이 명령어를 실행해서 에이전트가 필요한 정보를 빠르게 로드하게 합니다.
00:18:58에이전트가 코드를 이해했는지 확인한 뒤, 아까 보여드린 기획 단계로 들어갑니다.
00:19:03정리하자면, 전역 규칙은 항상 로드됩니다. 온디맨드 컨텍스트는 별도 문서화된
00:19:09특정 부분을 작업할 때 로드합니다. 기술(Skills)은 다른 능력이 필요할 때,
00:19:13가령 "이제 E2E 테스트를 할 거니까 브라우저 기술을 로드하자" 이럴 때 씁니다.
00:19:18그리고 Prime 명령어는 보통 대화 맨 처음에 실행해서 기획을 위한 무대를 세팅하죠.
00:19:22이것으로 '선택(Select)'에 대한 설명을 마칩니다. 이제 '압축(Compress)'으로 넘어갈 텐데,
00:19:28가장 빨리 끝날 섹션입니다. 기록, 격리, 선택 전략을 잘 지켰다면
00:19:34압축할 일이 거의 없어야 하거든요. 다른 전략들을 통해 컨텍스트를 가볍게 유지하고 있다면
00:19:39압축은 피하는 것이 상책입니다. 최대한 안 하는 게 좋으니까요.
00:19:46하지만 꼭 압축해야만 한다면 두 가지 전략이 있습니다.
00:19:52바로 '핸드오프(Handoff)'와 '포커스 압축(Focus Compaction)'입니다. 클로드 코드로 돌아가서 보시죠.
00:19:56핸드오프는 이미 설명해 드렸죠. '기록' 전략 중 하나이기도 합니다.
00:20:02지금까지의 모든 작업을 요약해서 다른 에이전트나, 메모리 압축 후의 본인에게 넘겨주는 방식입니다.
00:20:06그다음은 클로드 코드의 내장 기능인 `/compact` 명령어입니다.
00:20:12대화를 요약한 뒤 이전 기록을 지우고, 요약본을 컨텍스트 창 맨 위에 배치합니다.
00:20:18핸드오프는 정보를 기억하는 우리만의 워크플로우를 정의할 수 있어 매우 강력합니다.
00:20:23하지만 `/compact` 역시 유용한데, 특히 선택적으로 요약 지침을 줄 수 있기 때문입니다.
00:20:28어쩔 수 없이 압축해야 할 때 저는 매번 이 기능을 씁니다. 예를 들어
00:20:34"방금 테스트한 예외 케이스들에 집중해서 요약해 줘"라고 하는 거죠.
00:20:41그러면 요약본을 만들 때 단기 기억 중 그 부분에 더 주의를 기울이게 됩니다.
00:20:48오타가 좀 났지만 괜찮습니다. 알아서 압축을 실행할 거예요.
00:20:53핸드오프와 `/compact` 중 하나를 선택해서 쓸 수도 있고,
00:20:58둘 다 써야 할 때도 있습니다. 특히 압축을 두 번 이상 해야 할 정도라면
00:21:03대화가 너무 비대해진 것이니 핸드오프를 써서 아예 새 세션을 시작하는 게 낫습니다.
00:21:09하지만 한 번 정도라면 `/compact`로도 충분할 때가 많죠. 다만 압축 후에는
00:21:14에이전트에게 무엇을 기억하고 있는지 다시 물어보곤 합니다.
00:21:19제대로 이해하고 있는지 확인하기 위해서죠. "지금까지 내용을 어떻게 기억하고 있니?" 같은 식으로요.
00:21:24물론 이건 이상적인 상황은 아닙니다. 압축은 가능한 한 피하세요.
00:21:30최고의 압축 전략은 압축이 필요 없게 만드는 것입니다. 자, 이것이 바로 'WISC 프레임워크'입니다.
00:21:36내용이 많았는데 도움이 되셨길 바랍니다. 더 깊게 파고들고 싶은
00:21:41특정 전략이 있다면 꼭 알려주세요. 어느 전략이든 영상 하나로 만들 수 있으니까요.
00:21:46이 WISC 프레임워크가 여러분의 클로드 코드 활용 능력을, 혹은 다른 어떤
00:21:52AI 코딩 어시스턴트 활용 능력을 한 단계 높여주길 바랍니다.
00:21:59영상이 도움이 되셨고 앞으로 AI 코딩이나 이런 실전 프레임워크에 대한
00:22:04콘텐츠를 더 보고 싶으시다면 좋아요와 구독 부탁드립니다. 그럼
00:22:09다음 영상에서 뵙겠습니다. 아! 가시기 전에 정말 놓치면 안 될 마지막 소식이 하나 더 있어요.
00:22:144월 2일 제 유튜브 채널에서 라이브로 '무료 AI 트랜스포메이션 워크숍'을 개최합니다.
00:22:20CTOX의 설립자인 리오 와인스타인(Lior Weinstein)과 함께하는 아주 큰 행사입니다. 리오는
00:22:27조직 전체를 AI 중심으로 재편하는 법을 가르쳐 줄 거고, 저는 신뢰할 수 있고 반복 가능한
00:22:32코딩 에이전트 시스템을 구축하는 저만의 AI 코딩 방법론을 전수해 드릴 예정입니다.
00:22:38설명란에 해당 페이지 링크를 걸어둘게요. 제 유튜브 채널에서 라이브로 진행되니
00:22:42이 버튼을 눌러 알림 설정을 해두세요. 그때 뵙겠습니다!