클로드 코드를 사용할 때 대화가 길어지면 클로드가 멍청해지거나 실수를 반복하고, 코드를 수정하다가 다른 곳이 망가지는 문제의 원인은 컨텍스트 관리와 워크플로우에 있다. 이번 영상에서는 클로드 코드를 실전에서 200% 활용하는 방법을 제시한다. 컨텍스트 관리부터 프롬프트 패턴까지 바로 써먹을 수 있는 내용 위주로 다룬다.
클로드 코드 활용 시 컨텍스트 관리와 워크플로우가 중요하며, 이를 개선하면 효율성을 극대화할 수 있다.
영상 내용을 한눈에 정리한 치트 시트를 노션에 만들어 두었으며, 영상 설명란에 링크를 걸어두었다. 궁금한 점은 댓글로 문의 가능하다.
클로드의 답변 품질은 컨텍스트 관리에 따라 크게 달라진다. 세컨드 브레인을 구축하여 클로드와 작업하면서 배운 내용, 새로운 패턴, 해결책, 의사 결정 이유 등을 로컬 마크다운 파일에 저장한다.
세컨드 브레인을 통해 클로드에게 필요한 정보를 제공하고 효율적인 작업을 수행할 수 있다.
클로드 코드는 슬래시 메모리라는 기능으로 자동 메모리 시스템 관리를 최근에 릴리즈했다. 클로드가 작업하면서 자동으로 학습한 내용을 메모리.md 파일에 저장한다.
매 세션 시작 시 이 파일이 자동으로 로드되어 클로드가 이전 세션에서 학습한 내용을 바로 활용할 수 있다. /메모리 명령으로 확인하거나 편집할 수 있다.
슬래시 메모리 기능을 통해 클로드가 자동으로 학습한 내용을 활용하여 작업 효율성을 높일 수 있다.
팀원들과 공유해야 하는 컨텍스트는 cloud.md에 명시적으로 작성하는 것이 좋다. 개인 메모리는 메모리.md, 팀 공유 지식은 cloud.md로 나눠 쓰는 것을 추천한다.
API 스펙, DB 스키마, 코딩 컨벤션, 아키텍처 문서 등을 모두 cloud.md 하나에 몰아넣는 것은 좋지 않다. cloud.md는 매 세션마다 자동으로 로드되므로 토큰을 불필요하게 소비할 수 있다.
cloud.md에 API 엔드포인트 50개를 모두 포함cloud.md는 참조만 보여주고 상세 내용은 별도 파일로 분리cloud.md 맨 마지막에 참조 문서 목록을 파일 경로로 알려준다. 이 전략을 사용하면 레이지 로딩이 되어 클라우드는 필요할 때만 해당 파일을 읽을 수 있다.
cloud.md에는 규칙과 참조만 두고 상세 내용은 별도 파일로 분리하여 토큰 낭비를 막고 효율성을 높일 수 있다.
루트 cloud.md가 커지는 것이 걱정된다면 폴더별로 cloud.md를 따로 만들면 된다. 예를 들어 앱스/API 아래에 API 관련 cloud.md를 만들고, 웹 아래에는 웹 관련 cloud.md를 만드는 식이다. 이렇게 하면 해당 폴더의 파일을 작업할 때는 그 폴더의 cloud.md만 읽기 때문에 루트 cloud.md의 비대화를 막으면서 컨텍스트 오염도 방지할 수 있다.
폴더별로
cloud.md를 관리하여 컨텍스트 오염을 방지하고 필요한 정보만 빠르게 로드할 수 있다.
클로드가 컨텍스트 윈도우에 담을 수 있는 200K 토큰은 많아 보이지만 실제로 쓰다 보면 금방 찬다. 클로드코드에는 /clear나 /compact 명령어가 있지만, 코딩하다가 일일이 컨텍스트를 체크하고 콤팩트하는 것은 현실적이지 않다. 가장 실용적인 규칙은 한 세션에서는 한 피처, 한 작업만 하는 것이다.
한 세션에서는 한 가지 기능만 구현하여 컨텍스트 윈도우를 효율적으로 관리해야 한다.
작업을 세분화하는 습관이 중요하다. "결제 시스템 전체 만들어 줘"가 아니라 "스트라이프 웹훅 핸들러 구현해 줘"와 같이 단위를 쪼개야 한다. 이를 위해서는 먼저 플랜이 있어야 한다.
실전 워크플로우는 다음과 같다.
/clear 또는 새 세션을 연다./clear하고 다음 단계로 넘어간다.작업을 세분화하고 플랜을 세운 후, 각 단계를 별도의 세션에서 구현하여 효율성을 높일 수 있다.
신선한 컨텍스트가 부풀려진 컨텍스트보다 낫다. 이전 대화에 집착하지 말고 매 작업마다 깨끗한 세션으로 시작하는 것이 더 좋은 결과를 만들 수 있다.
MCP(Managed Cloud Provider)를 여러 개 연결하면 도구 설명만으로 토큰을 크게 소비한다. 현재 작업에 안 쓰는 MCP는 비활성화해야 한다. 노션이나 리니얼 같은 MCP는 도구 설명이 매우 커서 토큰을 많이 잡아먹으므로, 자주 쓰는 기능만 골라서 커스텀 MCP를 만들어 쓰는 것을 추천한다. 필요한 엔드포인트만 래핑하면 토큰 절약은 물론 응답 품질도 올라간다.
사용하지 않는 MCP는 비활성화하고, 필요한 기능만 담은 커스텀 MCP를 만들어 토큰 낭비를 줄여야 한다.
멀메이드 다이어그램을 이용하여 아키텍처를 컨텍스트에 효율적으로 정리할 수 있다. 시스템 구조를 말로 설명하지 않고 다이어그램으로 정리해두면 클라우드 MD가 훨씬 빠르게 이해하고 컨텍스트도 효율적으로 저장할 수 있다.
멀메이드 다이어그램을 활용하여 시스템 아키텍처를 시각적으로 표현하고 클라우드의 이해도를 높일 수 있다.
무거운 데이터 처리를 대화 안에서 시키다 보면 컨텍스트가 오염될 수 있다. 클로드에게 스크립트를 작성하게 하고 결과를 돌려줘서 클로드가 다음 작업을 할 수 있게 만드는 것이 좋다.
예를 들어 10만 행이 되는 CSV 파일을 파싱해야 하는 경우, 클로드에게 CSV 파싱 및 DB 마이그레이션 스크립트를 작성해 달라고 부탁하고, 스크립트를 돌려서 나온 아웃풋을 클로드가 받아서 다음 작업을 실행한다. 이렇게 하면 클로드는 큰 엑셀 파일을 읽을 필요 없이 스크립트가 처리한 데이터의 결과값만 받아서 작업을 진행할 수 있다.
무거운 데이터 처리 작업은 스크립트로 오프로드하여 컨텍스트 오염을 방지하고 효율성을 높일 수 있다.
큰 변경 작업을 시작할 때뿐만 아니라 어떤 작업을 시작할 때 반드시 플랜 모드로 시작하는 것을 추천한다.
플랜 모드를 통해 클로드의 작업 방향을 미리 검토하고 오류를 줄일 수 있다.
테스트 주도 개발(TDD) 방식으로 클로드 코드를 사용한다. 작은 변경을 한다면 바로 다음 변경으로 넘어가지 말고 꼭 테스트를 작성해서 테스트가 잘 돌아가는지 확인하고 커밋하는 것을 반복한다. 문제가 생겨도 마지막 커밋으로 돌아가면 되므로 디버깅이 훨씬 쉬워진다.
TDD 방식을 통해 코드의 안정성을 높이고 디버깅을 용이하게 할 수 있다.
클로드가 생각하는 과정을 무시하면 안 된다. 클로드가 가정을 세우는 순간들이 있는데, 그 가정이 틀릴 때가 있다. 그 순간에 바로 중단시키고 다시 시작하거나 가정을 수정해야 한다. 잘못된 가정 위에 쌓은 코드는 쓸모없다.
클로드의 플랜을 다른 AI(챗GPT, Gemini)에게 보여주고 분석을 요청할 수 있다. 다른 AI 모델은 다른 시선으로 바라보고 다른 문제를 정의하고 다른 솔루션을 제시할 수 있다. 이 피드백들을 통해 새로운 접근법을 찾을 수 있다.
여러 AI 모델의 검증을 통해 더 나은 해결책을 찾을 수 있다.
커스텀 스킬을 만들어 이 과정을 자동화할 수 있다. 예를 들어 "with multiple AI"라는 스킬을 만들면 한 AI 모델의 플랜을 다른 AI에게 전달해서 플랜을 취합하고 요약해주는 스킬을 만들 수 있다.
에러를 해석해서 설명하지 말고 에러 로그를 통째로 AI에게 던지는 것이 가장 좋다. 클로드는 스택 트레이스 분석에 능숙하므로 그대로 주는 것이 제일 잘한다.
투두 파일을 항상 프로젝트 시작부터 끝까지 하나의 파일에서 관리하는 것을 추천한다. AI는 오늘 할 일, 내일 할 일 등을 모르기 때문에 투두 파일을 계속 관리하면서 업데이트해주고 AI에게 공유해주면 AI도 작업 내용을 알 수 있다.
투두 파일을 통해 AI와 작업 내용을 공유하고 작업의 연속성을 유지할 수 있다.
WAT(Workflow, Agent, Tools)는 유튜버 네이트k크가 제안한 프로젝트 관리 방법론이다.
WAT 프레임워크를 통해 작업 흐름을 명확히 정의하고 AI 에이전트를 활용하여 효율적인 프로젝트 관리를 할 수 있다.
컨텍스트 관리와 워크플로우를 개선하면 클로드 코드를 단순한 코딩 도구가 아니라 동료 개발자처럼 활용할 수 있다.
다음 편에서는 고급 자동화 및 확장 심화편을 다룬다.