00:00:00클로드 코드는 AI 개발을 위한 가장 강력한 도구 중 하나임에도 불구하고,
00:00:03왜 특정 작업에서는 제대로 작동하지 않을까요? 최근 앤스로픽이 출시한 기능들과
00:00:08우리가 구축해 온 워크플로우를 살펴보면, 불과 몇 주 전과는
00:00:12이 도구의 권장 사용 방식이 완전히 달라졌습니다. 저희 팀은 매일 클로드 코드를
00:00:16사용하고 있는데, 단순히 개발뿐만 아니라 연구, 프로덕션 파이프라인 관리,
00:00:21그리고 코드와 상관없는 업무 자동화에도 활용 중입니다. 그동안 저희가 알아낸 모든 노하우를 보여드리겠습니다.
00:00:26앤스로픽은 최근 클로드 코드에 'insights' 명령어를 추가했습니다. 이 기능은
00:00:31일정 기간 동안의 모든 과거 세션을 분석하여 보고서를 생성해 줍니다.
00:00:36이 보고서는 작업 스타일을 분석하고, 작업 패턴의 문제점을 꼬집으며, 잘한 점과
00:00:40그렇지 못한 점을 강조해 개선 방법을 알려줍니다. 저희가 가장 관심을 가졌던 부분은
00:00:45문제가 발생한 지점을 파악하는 것이었습니다. 그래야 더 발전할 수 있기 때문이죠. 보고서는
00:00:49마찰이 가장 컸던 영역을 짚어주고, 워크플로우 개선을 위한 기능들도 제안해 주었습니다.
00:00:54예를 들어, 에이전트 팀을 사용하던 중 메인 에이전트가 오랫동안 반복적으로
00:00:58작업 목록을 확인(polling)했던 세션이 있었습니다. 이로 인해 세션이 너무 길어졌고,
00:01:03결국 직접 종료해야만 했죠. 앞으로 이런 문제를 방지하기 위해 이 프롬프트를
00:01:07cloud.md에 복사해 두면, 멀티 에이전트를 사용할 때 클로드가
00:01:12무한 루프에 빠지지 않고 바로 행동하게 할 수 있습니다. 이런 팁들을 프로젝트에 적용해 두면 시간이 지날수록 클로드 코드 사용 경험이 개선됩니다.
00:01:17저희 팀은 클로드 코드를 다루는 데 많은 시간을 할애해 왔는데, 가장 중요한 단계는
00:01:22여전히 에이전트에게 얼마나 문맥(context)을 잘 제공하느냐에 달려 있습니다.
00:01:26세부 항목으로 나뉜 프로젝트 요구 사항이나, 사용 중인 프레임워크 및 라이브러리의
00:01:30문서 등이 여기에 해당합니다. 정확한 문맥만 주어지면 에이전트가 무엇을 해야 할지 알기 때문에
00:01:35오류는 거의 0에 가깝게 줄어듭니다. 저희는 프로젝트 문서를 직접 작성하기보다
00:01:39클로드를 활용해 작성하는 것을 선호합니다. 프로젝트 아이디어를 필요한 문서들로
00:01:44분해하는 데 필요한 모든 정보가 담긴 특정 프롬프트를 클로드에게 제공했습니다.
00:01:48앱의 특정 측면에 초점을 맞춘 네 개의 문서를 생성하도록 요청했는데, 가장 중요한 것은 PRD입니다.
00:01:53여기에는 프로젝트 요구 사항과 범위가 포함됩니다. 그다음은 architecture.md로,
00:01:57데이터 형식, 파일 구조, API 및 모든 아키텍처 세부 사항이 기록됩니다.
00:02:02그리고 decision.md에는 클로드가 프로젝트 제작 과정에서 내린 모든 결정 사항이 담겨
00:02:08나중에 참고할 수 있는 자료가 됩니다. 마지막으로 가장 중요한 feature.json은
00:02:12모든 기능을 특정 JSON 형식으로 포함합니다. 각 기능에 대한 세부 정보를 토큰 효율적인
00:02:17방식으로 담고 있으며, 기능 완성 기준과 구현 여부를 추적하기 위한
00:02:22'passes' 키를 포함하고 있습니다. 이제 큰 작업이 작은 섹션으로 나뉘었으므로,
00:02:27구현에 필요한 도구에 대한 문서를 'Context 7 MCP'를 통해 제공해야 합니다.
00:02:31여기에는 모든 라이브러리와 프레임워크의 문서가 들어 있으며 자주 업데이트됩니다.
00:02:36덕분에 에이전트는 최신 문서를 불러와 모델이 알고 있는 지식과
00:02:41실제 현재 업데이트 사이의 간극을 메울 수 있습니다. MCP 설정은 몇 단계면 충분합니다. 일단 설치되면
00:02:46Context 7의 도구를 사용해 라이브러리 정보를 직접 가져옵니다. 이를 통해
00:02:50최신 문서를 활용하고, 의존성 불일치로 인한 코드 오류를 방지하며 더 정확하게 구현할 수 있습니다.
00:02:55다음으로 '훅(Hooks)'은 활용도가 높지만 과소평가된 기능입니다. 클로드 코드의 훅은
00:03:00라이프사이클의 특정 지점에서 실행되는 쉘 명령어입니다. 세션 시작 시점,
00:03:05도구 사용 전후 등 특정 상황에 트리거되는 여러 유형이 있습니다. 하지만 가장 중요한 부분은
00:03:11특정 종료 코드(exit code)와 함께 설정하는 것입니다. 종료 코드는 클로드 코드에게 작업을
00:03:16진행할지, 차단할지, 아니면 무시할지를 알려줍니다. 종료 코드 0은 성공을 의미하고, 2는 차단 오류를 뜻합니다.
00:03:22따라서 클로드가 하지 말아야 할 일을 시도할 때 종료 코드 2를 만나면, 오류 메시지를 받고
00:03:27스스로를 수정하게 됩니다. 그 외의 종료 코드는 비차단(non-blocking) 방식으로 간주되어 상세 모드에 표시되며
00:03:32실행은 계속됩니다. 이 종료 코드 2는 에이전트의 행동을 제어할 수 있게 해주므로 매우 중요합니다.
00:03:37클로드 코드로 테스트 주도 개발(TDD)을 해보셨다면, 테스트를 통과하지 못할 때
00:03:41클로드가 테스트 코드 자체를 수정해버리는 경향이 있다는 걸 눈치채셨을 겁니다.
00:03:46이를 방지하기 위해 도구 사용 전(pre-tool use)에 트리거되는 커스텀 훅을 설정했습니다.
00:03:50이 훅은 테스트 스크립트가 수정되는 것을 방지합니다. 작업 경로가 테스트 디렉토리이거나 'test'라는 단어가 포함된 경우,
00:03:55테스트 폴더 수정은 허용되지 않는다는 오류 메시지를 표시하고 종료 코드 2를 반환합니다.
00:04:00이 훅을 적용한 뒤 클로드에게 테스트를 실행하라고 명령했을 때, 테스트가 실패하자
00:04:05클로드가 테스트 파일을 수정하려고 시도했습니다. 하지만 스크립트가 이를 차단했고 '수정 차단됨' 메시지가 나타났습니다.
00:04:10이로써 클로드가 건드리지 말아야 할 파일을 편집하는 것을 막았습니다. MCP를 사용해 보셨다면
00:04:15이들이 컨텍스트 창을 많이 차지한다는 것을 아실 겁니다. 대규모 프로젝트를 진행할수록
00:04:19연결되는 MCP의 수가 늘어나게 됩니다. 결국 모든 MCP 도구들이 컨텍스트 창에 상주하게 되어
00:04:25용량이 비대해지죠. 바로 이 문제를 해결하기 위해 클로드 코드는 실험적인 'MCP CLI 모드'를 제공합니다.
00:04:31저희는 'experimental MCP CLI' 플래그를 true로 설정했습니다. 설정하고 나니 컨텍스트에
00:04:36표시되던 모든 MCP들이 사라졌고, MCP 도구가 차지하던 컨텍스트 용량도 0이 되었습니다.
00:04:41질문은 도구들이 더 이상 메모리에 존재하지 않는데 어떻게 접근하느냐는 것이었습니다.
00:04:45모든 도구 스키마를 미리 로드하는 대신, 클로드 코드는 'MCP CLI info'와 'MCP CLI call'을 사용하여
00:04:52연결된 모든 MCP를 bash를 통해 실행합니다. 플래그가 설정된 상태에서 프롬프트를 입력하면,
00:04:56MCP 도구를 직접 호출하는 대신 CLI 도구를 통해 bash 명령어로 실행하게 됩니다.
00:05:03이 방식을 통해 필요한 도구만 온디맨드로 로드하여 컨텍스트 비대화를 방지할 수 있습니다.
00:05:08혹시 저희 콘텐츠가 마음에 드신다면 'Hype' 버튼을 눌러주세요. 더 좋은 영상을 만들고 더 많은 분께 다가가는 데 큰 힘이 됩니다.
00:05:13이전 영상들에서 저희는 에이전트의 모든 작업을 버전 관리 시스템인 git으로 추적해야 한다고 강조해 왔습니다.
00:05:18에이전트가 기능을 잘못 구현했을 때 되돌릴 수도 있기 때문이죠. 또한 git을 사용해
00:05:23장기 작업에 에이전트를 실행하는 방법도 다뤘으니 채널에서 확인해 보세요.
00:05:28저희는 병렬 에이전트를 사용하여 서로 다른 'worktree'에서 작업하게 함으로써,
00:05:32각 프로젝트 기능을 서로 간섭 없이 독립적으로 생성할 수 있도록 했습니다.
00:05:37에이전트들이 동일한 파일에서 작업하면 충돌이 발생하기 때문에, 나중에 결과를 병합하는 방식이 효율적입니다.
00:05:41브랜치는 충돌 가능성 때문에 권장하지 않습니다. 브랜치는 작업 디렉토리를 공유하지만
00:05:46worktree는 그렇지 않기 때문에 에이전트가 브랜치를 전환하며 작업하는 데 어려움을 겪기 때문입니다.
00:05:50그래서 구현해야 할 여러 기능 목록을 주면서, 각 에이전트가 별도의 worktree에서
00:05:55작업하도록 프롬프트를 작성했습니다. 각 worktree마다 별도의 에이전트가 할당되어,
00:05:59작업 설명이 일부 겹치더라도 서로 독립적으로 기능을 구현해 냈습니다.
00:06:03클로드가 별도의 브랜치에서 모든 기능을 올바르게 구현한 뒤, 결과를 병합하여
00:06:08단일 작업 디렉토리에 모든 기능이 모이도록 했습니다. 이제 'Strict Mode'는 오류 확인의 부담을
00:06:13에이전트에게 넘기는 데 필수적입니다. 사용하는 언어가 무엇이든 이 설정을 꼭 해야 하는데,
00:06:18사용자가 런타임에 버그를 마주하기 전에 빌드 단계에서 버그를 잡아주기 때문입니다.
00:06:22저희 주력 언어는 TypeScript이므로 프로젝트에서 항상 엄격 모드(strict mode)를 활성화합니다.
00:06:26이렇게 하면 null 값 및 암시적 타입 체크가 켜지고 엄격한 타이핑이 강제되어,
00:06:31전반적으로 런타임 오류가 줄어듭니다. 에이전트에게는 런타임 오류를 스스로 잡을 내장 기능이 없기 때문에
00:06:36이 설정이 매우 중요합니다. 엄격 모드는 런타임 실패 가능성을 최소화하고 컴파일러가
00:06:41대신 이슈를 처리하게 해줍니다. 에이전트는 터미널의 오류 로그를 보고 알려진 해결책을 적용할 수 있습니다.
00:06:46프로젝트를 스크립트로만 테스트하는 것 외에 추가로 고려해야 할 테스트 계층이 있습니다.
00:06:51앱이 구축된 후 테스트 과정을 안내하기 위해 사용자가 시스템과 상호작용하는 방식을
00:06:56기술한 '사용자 스토리'를 작성하는 것입니다. 저희는 구현을 시작하기 전에
00:07:00먼저 사용자 스토리를 정의하는데, 이것이 구현 과정에서 따라야 할 표준이 되기 때문입니다.
00:07:05프롬프트를 통해 클로드는 사용자가 시스템과 상호작용할 수 있는 모든 시나리오를 담은
00:07:10폴더 안에 여러 스토리를 작성했습니다. 각 스토리는 앱의 특정 측면, 우선순위,
00:07:15그리고 에이전트가 테스트할 때 기준으로 삼을 '수락 기준'을 포함합니다. 사용자 스토리는
00:07:21최선의 사례와 예외 사례를 포함한 모든 테스트 시나리오를 다뤘습니다. 이 스토리들은
00:07:26방금 구축한 시스템과 상호작용하는 법을 에이전트에게 알려줍니다. 적절한 지침만 있다면
00:07:31어떤 에이전트라도 동일한 원칙을 앱에 적용하여 사용자의 기대치를 더 잘 충족할 수 있습니다.
00:07:35문서화된 스토리를 바탕으로 클로드에게 하나씩 구현해 보라고 요청했으며,
00:07:40각 스토리의 최적 경로에서 시작해 모든 예외 사례를 처리하도록 지시했습니다.
00:07:45덕분에 구현 과정의 빈틈이 줄어들고 전반적인 사용자 만족도가 높아졌습니다. 이제
00:07:50지금까지 말씀드린 모든 팁은 'AI Labs Pro'에서 바로 사용 가능한 템플릿 형태로 제공됩니다.
00:07:55모르는 분들을 위해 설명하자면, 이곳은 최근 런칭한 커뮤니티로, 이번 영상뿐만 아니라
00:08:00이전 영상들에서 다룬 모든 명령어, 기술, 프롬프트 템플릿을 프로젝트에 바로 적용할 수 있습니다.
00:08:05저희 활동이 가치 있다고 느끼고 채널을 응원하고 싶으시다면 가장 좋은 방법입니다.
00:08:10링크는 설명란에 있습니다. 또한, 병렬화를 최대한 활용해야 합니다.
00:08:14이것이 에이전트가 워크플로우 속도를 높이고 서로 기다릴 필요가 없는 작업을 처리하는 방식이기 때문입니다.
00:08:20클로드는 작업이 병렬로 실행 가능한지 순차적으로 해야 하는지 자동으로 감지해
00:08:25스스로 결정하지만, 사용자가 직접 에이전트를 생성해 주는 것도 좋은 방법입니다.
00:08:29이전 영상에서 에이전트를 사용해 워크플로우를 빠르게 만드는 법을 다루기도 했지만,
00:08:34이러한 속도는 토큰 사용량 증가라는 비용을 수반합니다. 그럼에도 병렬화는 시도할 가치가 충분합니다.
00:08:39한번은 동일한 모델을 사용해 Opus 4.6 개선 사항의 영향에 대해 연구하고 있었는데,
00:08:43출처를 제공했음에도 불구하고 모델이 계속 사실을 왜곡해서 답변(hallucination)하더군요.
00:08:49계속 틀린 정보를 써서 반복적으로 수정해야만 했습니다. 결국 직접 고치느라
00:08:54연구를 진행하는 게 무의미하게 느껴질 정도였죠. 이런 일을 방지하기 위해 병렬 에이전트를 도입했습니다.
00:08:58KimiK 2.5와 클로드의 에이전트 스웜(agent swarm) 능력을 비교하는 연구 작업을 설정했습니다.
00:09:03하나는 연구를 수행하고, 다른 하나는 연구 에이전트의 내용을 팩트 체크하도록 두 에이전트를 사용했습니다.
00:09:09핵심 아이디어는 두 에이전트가 서로 소통하게 하여 결과의 정확성을 보장함으로써,
00:09:14우리가 직접 검증할 필요가 없게 만드는 것이었습니다. 이 구성에서는 한 에이전트가 작업을 수행하는 동안
00:09:19다른 에이전트가 이를 비판적으로 분석하는 '적대적 방식'으로 작동합니다. 연구 에이전트가 먼저 시작했고,
00:09:24팩트 체크 에이전트는 첫 번째 초안이 나올 때까지 대기했습니다. 초안이 나오자마자
00:09:28팩트 체크 에이전트가 검증을 시작했습니다. 연구 에이전트가 나열한 데이터에서 수많은 오류를
00:09:33즉시 찾아냈고, 저희가 일일이 잡아낼 필요가 없게 되었습니다. 두 에이전트는
00:09:38계속 소통하며 팩트 체크 과정을 촘촘하게 유지했습니다. 한 에이전트가 상대의
00:09:43잘못된 정보를 지적하는 데 전념한 것이죠. 이런 적대적 구성으로 실행할 수 있는 작업은 많습니다.
00:09:47연구뿐만 아니라 개발 업무에서도 한 에이전트가 기능을 구현하고 다른 에이전트가
00:09:52계획 대비 구현 내용을 검토하게 할 수 있습니다. 클로드 코드 제작자의 말에 따르면,
00:09:57에이전트는 자신의 작업을 스스로 검증할 수 있는 수단이 있을 때 더 잘 작동한다고 합니다.
00:10:02여기서 핵심은 에이전트에게 '눈'을 달아주는 것입니다. 즉, 구현된 기능이 올바른지,
00:10:07기대에 부응하는지 확인할 능력을 주는 것이죠. 이런 에이전트들은 터미널 기반이라
00:10:12특히 클라이언트 측에서 발생하는 런타임 이슈를 파악하지 못할 때가 많습니다. 그래서 저희는
00:10:17여러 가지 방법으로 에이전트의 작업을 검증합니다. 첫 번째는 '클로드 크롬 확장 프로그램'으로,
00:10:21DOM 캡처, 콘솔 로그 확인 등 브라우저 중심의 도구들을 제공합니다. 또 다른 도구는
00:10:26'Puppeteer MCP'입니다. 이 도구는 기존 세션과 분리된 별도의 브라우저에서 실행되므로
00:10:31유용합니다. 독립적으로 작동하여 현재 세션을 방해하지 않으므로 프라이버시 계층이 한 층 더 강화됩니다.
00:10:36하지만 저희가 선호하는 방식은 Vercel의 'agent browser'입니다. 이것은 MCP가 아니라
00:10:41에이전트에게 브라우저 테스트 능력을 부여하는 CLI 도구입니다. 내비게이션, 스크린샷 캡처 등의
00:10:46기능이 있습니다. 다른 도구들과 달리 단순히 스크린샷에만 의존해 탐색하지 않습니다.
00:10:51대신 각 요소가 고유 참조값을 갖는 '접근성 트리(accessibility tree)'를 사용합니다. 이를 통해 수천 개의 토큰이
00:10:56필요한 전체 DOM을 200~400토큰 정도로 압축하므로 훨씬 컨텍스트 효율적입니다.
00:11:01이것이 바로 클로드 크롬 확장 프로그램의 주요 문제였는데, 에이전트 브라우저가 이를 해결했습니다.
00:11:07기존 방식은 전체 DOM을 컨텍스트 창에 로드해 금방 용량을 소진해 버렸거든요. 저희는 또한
00:11:12cloud.md에 지침을 추가하여, 클로드가 MCP 기반 테스트 전에 에이전트 브라우저를 먼저
00:11:17사용하도록 설정했습니다. 즉, 에이전트 브라우저를 기본 검증 수단으로 쓰는 것이죠. 하지만 다른 관점도 있습니다.
00:11:23테스트는 항상 중요하지만, 테스트나 코드 리뷰 없이도 오류를 줄이는 방법이 있습니다.
00:11:28클로드에게 아직 일어나지 않은 일을 '예측'해 보라고 요청하는 것입니다. 구현 내용을 확인하고
00:11:33앱이 실패할 수 있는 영역을 찾아내라고 시키는 것이죠. 이는 우리가 아직 테스트를 통해
00:11:38발견하지 못했더라도, 클로드가 다른 앱에 존재했던 실패 사례들을 패턴 매칭하여
00:11:43잠재적인 문제를 예측하게 하기 때문에 가능합니다. 클로드가 이전과는 다른 각도에서
00:11:47코드를 바라보게 만드는 것이죠. 실제로 이렇게 요청했을 때, 다중 레이어 테스트 과정조차
00:11:52통과했던 치명적인 빈틈들을 찾아냈고, 실서비스에서 위험할 뻔했던 18개의 이슈를 발견했습니다.
00:11:57기존의 테스트 프로세스로는 잡지 못했던 것들이죠. 클로드가 프로젝트를 다른 관점에서
00:12:01보도록 밀어붙였을 때만 식별할 수 있었습니다. 이제 이번 영상의 끝에 다다랐네요.
00:12:06저희 채널을 응원하고 이런 영상을 계속 만드는 데 도움을 주고 싶으시다면,
00:12:10아래의 'Super Thanks' 버튼을 이용해 주세요. 언제나 시청해 주셔서 감사드리며,
00:12:15다음 영상에서 뵙겠습니다.