How I Plan, Build, and Run Loops with Claude Code in 40 Minutes | Thariq Shihipar

URL: https://youtu.be/aVO6E181cNU 날짜: 2026-07-19 채널: Peter Yang

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

Anthropic 클로드 코드(Claude Code) 팀의 Thariq Shihipar가 ==모델이 똑똑해질수록 사람은 더 적은 제약과 예시를 주고, 대신 "무엇을 모르는지 알아가는" 반복적 탐색으로서의 계획(planning)과, 에이전트가 스스로 오래 일하게 만드는 loop·goal·workflow 세 가지 도구를 어떻게 조합하는지==를 실제 비디오 편집 워크플로우 데모로 보여준다.

• /goal은 에이전트가 스스로 종료 조건을 상기하며 조기 중단을 막는 도구이고, workflow는 서브에이전트를 병렬로 띄워 작업과 검증을 분리하는 가장 강력한 형태다
• 계획(planning)은 한 번에 다 쓰고 실행에 넘기는 문서가 아니라, "내가 모르는 것을 알아가는" 반복적 탐색 과정이며 학습·목업·기술 조사 등 다양한 형태를 띤다
• 모델이 똑똑해지면서 Anthropic은 클로드 코드 시스템 프롬프트를 80% 줄였는데, 이는 예시와 제약이 많을수록 오히려 모델을 부자연스럽게 구속하기 때문이다

호스트 Peter Yang은 자신의 팟캐스트 영상 편집 사례를 통해 Thariq이 실시간으로 whisper 전사 → Remotion 오버레이 자막 생성을 원샷 프롬프트로 시연하는 과정, 그리고 Claude 팀 내부에서 loop·goal·workflow·Slack 기반 "cloud tag"(클로드 태그 기능)를 실제로 어떻게 쓰는지를 심층 인터뷰한다.

---

1. Loop, Goal, Workflow — 에이전트를 오래 일하게 만드는 세 도구

1.1. 개념 정의와 용도 구분

1. Loop라는 상위 개념
   1. 정의: Loop는 에이전트가 피드백을 받으며 오케스트레이션된 방식으로 오래 작업하게 만드는 다양한 방법을 통칭하는 넓은 용어다
   2. 세 가지 실현 형태: /loop, /goal, workflow가 이 개념을 구현하는 세 가지 구체적 도구다
2. /goal의 역할 — 종료 조건의 상기
   1. 조기 중단 방지: /goal은 에이전트가 스스로에게 "종료 조건이 무엇인지"를 계속 상기시켜, 조건이 충족되기 전까지는 멈추지 않게 만든다
   2. 적합한 상황: 복잡한 작업이라 반드시 끝까지 완수돼야 하고, 사용자가 이미 문제 공간을 충분히 이해하고 탐색을 마친 뒤 "그냥 실행해, 막히면 알아서 채워 넣어"라고 지시하고 싶을 때 적합하다

1.2. Workflow — 가장 강력한 형태

1. 비결정적 작업을 결정적 작업으로 쪼개기
   1. 서브에이전트의 병렬화와 검증 분리: workflow는 서브에이전트를 여러 개 띄워 작업을 병렬로 수행하게 하는 동시에 그 결과를 검증하는 역할까지 분리할 수 있어, 비기술적(non-technical) 작업에서 특히 강력하다
   2. 비결정적 작업의 결정화: 무엇이 "좋은 결과"인지 애매한(squishy) 작업일수록 워크플로우로 루브릭을 만들고 검증 에이전트를 두어 판단을 구조화할 수 있다
2. 선택 기준 — 결정적 신호가 있는가
   1. 레이턴시처럼 결정적 신호가 있을 때는 /goal: 예를 들어 Figma MCP로 디자인 스펙을 검증할 수 있다면 "렌더링된 결과가 Figma와 일치하는지 확인해"라는 /goal이 스크린샷 대조보다 훨씬 쉽다
   2. 애매한 기준일 때는 workflow: 스크린샷 비교처럼 판단 기준이 애매한 경우엔 루브릭과 검증 에이전트를 갖춘 workflow가 더 적합하다

---

2. 실시간 데모 — 원샷 프롬프트로 만든 비디오 편집 워크플로우

2.1. 팟캐스트 영상에 자동 자막·오버레이 만들기

1. 한 번의 프롬프트로 완성된 결과물
   1. 프롬프트 내용: "이 레포는 Peter Yang 팟캐스트용이다. 샘플 영상이 있다. Whisper로 전사하고, Remotion으로 각 단어가 하이라이트되는 자막과 오버레이를 만드는 UI를 만들어라. 영상이 완전히 렌더링될 때까지 멈추지 마라(/goal)"는 단 한 번의 프롬프트였다
   2. 즉각적 결과물: 이 한 번의 프롬프트만으로 전사, 캡션 생성, 오버레이 삽입, 페이드아웃까지 전부 자동으로 완성됐다
2. 아직 남은 개선 여지
   1. 손가락 위치 인식의 한계: 발표자가 손으로 가리키는 위치를 정확히 인식하지 못하는 문제가 있었고, 이를 개선하려면 손가락이나 얼굴을 트래킹해 더 풍부한 메타데이터를 에이전트에게 줘야 한다는 방향을 제시했다

2.2. 팟캐스트 프로덕션 스킬과 워크플로우 실전 사례

1. Peter Yang의 자체 스킬 시연
   1. 인터뷰 transcript → 썸네일/클립 자동 생성: 저자(Peter)는 인터뷰 트랜스크립트를 붙여넣으면 클릭베이트성 유튜브 썸네일과 클립 아이디어를 만들어주는 자체 스킬을 시연했으며, 이는 ffmpeg 등을 활용해 실제 캡션이 달린 영상 클립까지 생성한다
2. 워크플로우로 전환할 지점
   1. 여러 개의 짧은 클립을 만들 때: 예를 들어 5~10개의 숏폼 클립을 만들 때, 메인 에이전트가 클립으로 만들 구간 5곳을 정하고 워크플로우가 각각에 서브에이전트를 하나씩 배정해 루브릭에 따라 검증하게 하는 방식이 이상적이다
   2. 컴퓨트 낭비 방지: 여러 클립을 동시에 하나의 세션에서 처리하면 클로드가 개별 클립에 쓰는 노력을 줄이는 경향이 있으므로, 클립마다 별도 서브에이전트를 배정하면 각 클립에 최대한의 컴퓨트를 투입하게 된다

---

3. 계획(Planning)은 스펙 작성이 아니라 "모르는 것을 알아가는" 과정

3.1. 반복적 탐색으로서의 플래닝

1. 한 번에 끝나는 스펙이 아니다
   1. 탐색·조사·발견의 과정: 계획은 한 번 작성하고 그대로 구현에 넘기는 것이 아니라, 탐색하고 조사하며 자신이 무엇을 모르는지, 무엇을 원하는지 알아가는 반복적 과정이며 그 끝에서 자연스럽게 단순화된다
   2. "unknowns를 없애는 것": 어떤 작업이든 항상 "어떻게 작동하는지" 또는 "무엇을 원하는지"에 대해 모르는 것이 많으며, 이것을 알아가는 과정이 곧 플래닝이다
2. HTML 아티팩트를 활용한 디자인 탐색
   1. 레퍼런스 제공 → 탐색안 생성: Peter Yang의 블로그를 레퍼런스로 주고 "여러 오버레이/캡션 디자인 변형을 탐색할 수 있는 HTML 아티팩트를 만들어라"고 요청하는 방식으로, 디자이너가 아닌 사람도 "보면 안다"는 방식의 탐색이 가능해진다
   2. 기술 조사도 플래닝의 일부: Whisper 전사가 어떻게 작동하는지, 어떤 엣지 케이스가 있는지(예: 침묵 구간이 "시청해주셔서 감사합니다"로 잘못 인식되거나, 한 단어가 두 조각으로 쪼개지거나, 화자 인식이 안 되는 문제)를 먼저 조사해두면 나중에 복잡한 워크플로우를 구축한 뒤 문제를 발견하는 것을 미리 방지할 수 있다

3.2. 스펙과 구현은 분리된 한 번의 전달이 아니라 왕복 과정

1. 구현 중 발견되는 예상 밖의 사실들
   1. 구현 노트 남기기: 인간의 요청 → 에이전트의 기술적 탐색 → 목업/설명 자료로 unknown을 좁힘 → 다시 에이전트에게 전달 → 구현 시작이라는 흐름에서, 구현 과정 중 예상치 못한 것을 발견하면 "구현 노트"를 남기게 해서 필요하면 스펙을 다시 쓸 수 있게 한다
   2. 저렴한 프로토타이핑의 원칙: 지금은 프로토타입(HTML)으로 개념을 먼저 검증하고, 그것이 확정되면 더 비용이 큰 구현(React 등 실제 코드 변경과 재렌더링이 필요한)으로 넘어가는 최소 단계 접근이 유효하다

---

4. Workflow vs Skill — 언제 무엇을 쓰는가

4.1. Workflow가 필요한 이유 두 가지

1. 컨텍스트 청결성(context cleanliness)
   1. 서브에이전트로 컨텍스트 분리: workflow는 서브에이전트를 띄워 컨텍스트를 깨끗하게 유지할 수 있게 해준다
2. 자기참조 편향(self-referential bias) 방지
   1. 자신의 결과물에 관대해지는 문제: 모델은 자신이 만든 결과물을 검증할 때 더 관대해지는 경향("self-referential bias")이 있으므로, 작업하는 클로드와 검증하는 클로드를 별도로 분리해야 한다
   2. 컴퓨트 투입량 증가: 별도로 분리하면 세 개의 클로드(코디네이터·작업자·검증자)가 각기 다른 컨텍스트로 더 많은 컴퓨트를 투입하게 되어, 조기 종료 가능성이 줄고 더 깊이 생각하게 된다

4.2. Workflow 생성 방법

1. 간단한 지시로 생성 가능
   1. 자연어 요청으로 충분: "여기서 클립 10개를 만들어줘, 워크플로우를 써서. 이게 좋은 클립인지 판단하는 루브릭이야"라고 말하면 워크플로우가 생성되며, 이는 하나의 JS 파일로 저장되고 스킬로 패키징해 재사용할 수 있다

---

5. Claude in Slack("cloud tag") — 팀의 실제 협업 패턴

5.1. 언제 Slack, 언제 터미널/데스크톱을 쓰는가

1. 병렬 작업은 Slack, 집중 작업은 터미널
   1. 멀티클라우딩(multi-clouding): 여러 작업이 동시에 진행될 때, 특히 다른 사람과 협업해야 할 때(예: PR을 봐줄 리뷰어를 같은 슬랙 채널에 태그하는 경우)는 Slack에서, 초기 탐색·PR 스펙 작성 등도 Slack에서 진행한다
   2. 한 가지에 집중할 때는 로컬 클로드 코드: 하나에 집중해서 왔다갔다 반복 작업할 때는 로컬 클로드 코드 세션에서 진행하며, 저자는 이제 활성 클로드 코드 세션은 보통 하나이고 나머지는 다수의 Slack 클로드 태그 세션으로 운영한다는 패턴을 공유한다
2. 개인 채널과 팀 채널 모두 활용
   1. 개인 작업 채널 + 팀/프로젝트 채널: 개인적으로 대부분의 작업을 하는 개인 슬랙 채널과, 피드백·프로젝트별 엔지니어링 채널 같은 팀 채널을 모두 활용한다

5.2. 에이전트를 동료처럼 대하는 관점의 장단점

1. 동료 비유의 유용성과 한계
   1. 채널·에이전트마다 별도 메모리: Slack에서는 채널/에이전트마다 별도의 메모리를 갖는 방식을 택했으며, 이는 여러 선택지 중 하나(예: 여러 클로드를 각기 다른 Slack 아이덴티티로 태그하는 방식도 가능) 중 하나다
   2. 동료와는 다르다는 인정: 지속성과 정체성을 가진 에이전트로 생각하는 것이 도움은 되지만, 실제 동료와는 다르며 그 진화 방향은 모델의 발전에 따라 열어두고 있다는 입장이다

---

6. 시스템 프롬프트를 80% 줄인 이유 — 모델이 똑똑해질수록 덜 지시하라

6.1. 제약과 예시가 오히려 성능을 해칠 수 있다

1. 80% 시스템 프롬프트 감축
   1. 모델이 똑똑해질수록 필요 없어지는 지시: 모델이 똑똑해지면서 방향 제시, 제약, 예시가 덜 필요해졌고, 그 결과 클로드 코드의 시스템 프롬프트를 80% 줄였다
   2. 예시가 오히려 구속이 된다: "배치 도구를 쓸 때 이런 5가지 예시가 있다"는 식의 지시가 오히려 모델을 그 예시 형태로만 국한시키는 부작용을 낳으며, 예시를 제거하면 더 자유로운 형태로 문제를 풀 수 있게 된다
2. "절대 하지 마라"보다 이유를 설명하라
   1. 제약보다 근거 제시가 효과적: "절대 하지 마라"는 지시는 대부분 "대부분의 경우 하지 마라"는 의미인데, 하지 말아야 할 이유를 설명하는 것이 단순 금지 지시보다 더 효과적이다

6.2. 컨텍스트를 다듬는 실천 원칙

1. CLAUDE.md와 스킬을 짧게
   1. 길이를 줄여라: CLAUDE.md는 대체로 너무 길고, 스킬도 너무 긴 경우가 많으므로 계속 줄여나가야 한다는 것이 저자의 조언이다
   2. MCP는 상황에 따라 다르다: MCP는 컨텍스트를 많이 차지할 수 있지만, 도구 검색(tool search) 같은 기능으로 이를 개선하려는 팀의 노력이 있다는 점도 언급한다
2. 제약보다 원칙을 제시하라 (트위터 포스트 예시)
   1. 경직된 규칙 대신 맥락과 선호를 제공: "280자 이내로 써라, 이건 하지 마라"는 경직된 규칙 대신, "나는 이런 사람이고 이런 원칙을 따른다"는 컨텍스트를 주고, "트위터 스레드보다는 한 개의 트윗을 선호한다"처럼 유연한 선호를 제시하는 것이 더 나은 결과를 만든다

---

7. 사람이 더 기술적이 되는 법과 생산성 팁

7.1. "기술적이 된다"는 것의 재정의

1. 문법이 아니라 트레이드오프를 아는 것
   1. Unknown unknowns를 아는 것이 목표: 타입스크립트 문법을 아는 것은 별로 도움이 안 되지만, 다양한 백엔드 서비스의 트레이드오프나 영상 인코딩 라이브러리 간 차이, 로컬 vs 원격 전사 라이브러리의 차이를 아는 것은 실질적으로 도움이 된다
   2. 배움은 재미보다 노력이어야 한다: Karpathy의 말을 인용해 "교육은 재미보다 노동처럼 느껴져야 한다"며, 클로드에게 밀어붙여 브레인스토밍과 학습을 시킬 수 있지만 실제로 그렇게 하려면 스스로를 밀어붙여야 한다고 강조한다
2. HTML 리포트를 읽는 습관
   1. 결과물을 읽지 않는 것이 흔한 실수: 대부분의 사람들은 클로드가 만든 상세한 HTML 리포트나 계획서를 제대로 읽지 않고 넘어가는데, 저자는 이를 반드시 읽고 이해하는 습관이 실력 향상의 핵심이라고 지적한다

7.2. 멀티태스킹과 게으른 프롬프트에 대한 경계

1. 한 번에 하나의 프로젝트에 집중하기
   1. 멀티클라우딩의 함정: 여러 스레드를 동시에 돌리는 것이 오히려 대면 회의를 연달아 하는 것보다 피곤할 수 있으며, 저자는 "가장 집중하는 프로젝트 하나"를 정해두는 방식을 추천한다
   2. 게으른 프롬프트의 대가: "그냥 해줘"라는 게으른 프롬프트는 당장은 편하지만 결국 더 오래 걸리고 비용도 더 들게 된다
2. 정리(organization)는 사람을 위한 것
   1. 품질보다 결과물이 중요한 경우: 비디오 출력물처럼 코드 품질보다 결과물이 중요한 작업에서는, 정리정돈이 에이전트보다 오히려 사람 자신이 워크스페이스에 대해 편안함을 느끼기 위한 것이며 simplify 같은 도구로 언제든 정리를 요청할 수 있다

---

주요 발언 모음

"As the models have gotten smarter, they need less direction, fewer constraints, and fewer examples." "I think planning is more of this iterative process of like exploring, investigating, finding out what you don't know, what you want." "The prompt box can definitely just be a lazy button... but usually you end up paying for that." "We call it self-referential bias — when a model prefers its own outputs, it's going to be more lenient at verifying it." "Education should feel like work more than fun." (Karpathy 인용) "If you have a really capable employee, you're not going to micromanage them."

핵심 데이터 & 수치

• 시스템 프롬프트 감축: Anthropic이 클로드 코드 시스템 프롬프트를 80% 줄임 — 모델이 똑똑해질수록 예시·제약이 덜 필요해졌기 때문
• 데모 시간: 영상 편집 원샷 프롬프트 시연에 약 10분 소요 (사전 녹화 영상 준비 포함)
• 도구 세 가지: /loop, /goal, workflow — 각각 다른 상황(탐색형, 종료조건 강제형, 병렬·검증형)에 대응

결론 및 시사점

1. /goal은 명확한 종료 조건이 있는 복잡한 작업에, workflow는 판단 기준이 애매하고 병렬 검증이 필요한 작업에 적합하다는 것을 구분해서 써야 한다.
2. 좋은 계획(planning)은 한 번에 완성하는 문서가 아니라, 자신이 무엇을 모르는지 알아가는 반복적 탐색이며 HTML 아티팩트나 기술 조사 같은 다양한 형태를 취할 수 있다.
3. 구현은 스펙에서 한 번에 넘어가는 것이 아니라, 구현 중 발견한 사실을 담은 "구현 노트"를 남기며 스펙과 계속 왕복하는 과정이어야 한다.
4. Workflow는 서브에이전트로 컨텍스트를 깨끗하게 유지하고, 자기참조 편향(자기 결과물에 관대해지는 경향)을 막기 위해 작업자와 검증자를 분리하는 데 핵심 가치가 있다.
5. 모델이 똑똑해질수록 시스템 프롬프트·CLAUDE.md·스킬을 오히려 짧게 줄이고, 경직된 제약보다 원칙과 맥락을 제공하는 방향으로 프롬프트 설계를 바꿔야 한다.
6. 기술적으로 성장한다는 것은 문법을 아는 것이 아니라 시스템의 트레이드오프와 "모르는 것을 모른다는 사실"을 줄여나가는 것이며, 이는 재미가 아니라 의도적인 노력을 요구한다.
7. 멀티태스킹(멀티클라우딩)의 함정을 피하려면 가장 집중할 프로젝트 하나를 정하고, "그냥 해줘"라는 게으른 프롬프트가 결국 더 큰 비용으로 돌아온다는 것을 기억해야 한다.