Claude Code가 똑똑해질수록 사람은 세세한 지시에서 벗어날 수 있다. 중요한 일은 에이전트가 오래 움직일 목표와 환경을 만들고, 결과가 좋은지 판단할 기준을 세우는 것이다. Anthropic의 Thariq Shihipar는 /loop, 목표, 스킬, 워크플로를 조합해 이 일을 한다. 그가 바라는 것은 단순히 더 많은 일을 처리하는 것이 아니다. 덜 일하면서 더 나은 결과를 만드는 것이다.
긴 작업은 지시보다 목표에서 시작한다
에이전트에게 한 번 프롬프트를 보내는 방식은 금방 끝난다. 반면 긴 작업에는 스스로 다음 행동을 고를 수 있는 목표가 필요하다. 작업을 작은 지시로 쪼개서 사람이 계속 밀어주는 대신, 완료 상태와 판단 기준을 알려줘야 한다. 에이전트는 그 목표를 향해 계획하고, 만들고, 확인하는 일을 이어간다.
Thariq가 소개한 도구들은 모두 에이전트가 오래 일하게 하는 데 초점을 둔다. /loop는 같은 종류의 점검이나 개선을 일정한 간격으로 다시 실행한다. 목표는 여러 차례의 작업을 하나의 완료 조건에 묶는다. 워크플로는 작업을 나누고 여러 에이전트가 각자 만들거나 검토하게 한다. 셋은 모양이 다르지만 한 가지 문제를 푼다. 사람이 매번 다음 프롬프트를 보내지 않아도 에이전트가 계속 유용한 일을 하게 만든다.
영상 편집 시연은 이 차이를 보여준다. 한 번의 요청만으로도 Claude Code는 자막을 만들고, 화면 위에 작은 그래픽을 얹고, 마지막에 검은 화면으로 전환하는 작업을 차례로 처리했다. 사람은 영상 도구의 모든 명령을 직접 입력하지 않았다. 원하는 결과와 확인할 대상을 알려주고, Claude가 필요한 도구를 골라 쓰게 했다.
프롬프트가 길다고 좋은 장기 작업이 되는 것은 아니다. 에이전트가 다음 행동을 판단할 수 있도록 목표와 피드백 고리를 갖춰야 한다. 실행 도중에 무엇을 살펴보고 어떻게 고칠지도 목표의 일부가 된다.
에이전트가 실패했을 때도 곧바로 지시를 늘릴 필요는 없다. 먼저 작업 환경에 필요한 정보와 도구가 있는지 본다. 결과를 관찰할 수 있는 화면이나 보고서를 만들고, 에이전트가 그 결과를 읽게 하면 스스로 다음 수정을 찾을 수 있다. 사람의 역할은 모든 단계를 정하는 데서 좋은 환경을 만드는 쪽으로 옮겨간다.
스킬은 지식을 담고 작업 공간은 자산을 쌓는다
스킬은 되풀이할 방법을 담는 데 알맞다. 예를 들어 Peter Yang은 영상을 받아 게시물 문안을 만들거나, 영상에서 짧은 클립 후보를 찾고 실제 클립과 자막을 만드는 스킬을 쓴다. 여러 스킬을 이어서 원본을 준비하고, 클립을 만들고, 썸네일까지 만드는 식으로 사용할 수 있다.
하지만 모든 것을 하나의 스킬에 넣는 것이 답은 아니다. 작업이 커지면 스크립트, 참고 자료, 중간 산출물, 결과물이 계속 쌓인다. 이때는 오래 유지하는 저장소를 작업 공간으로 삼는 편이 낫다. 영상 편집이라면 자막 처리, 화면 전환, 오버레이 생성 같은 스크립트가 계속 자산으로 남는다. 다음 작업에서 에이전트는 처음부터 같은 문제를 다시 풀지 않는다.
Thariq는 스킬과 작업 공간의 경계를 이렇게 본다. 스킬은 작업 방법을 설명할 수 있고, 필요하다면 작업 공간을 만드는 방법까지 담을 수 있다. 반면 실제로 쌓이는 도구와 결과물은 지속적인 저장소에서 관리한다. 에이전트가 오래 일할수록 지시문보다 재사용할 수 있는 스크립트와 자료가 더 큰 도움이 된다.
Peter의 영상 스킬은 클립을 자동으로 만들고 자막도 입혔지만 완벽하지 않았다. 그는 B-roll, 화면 오버레이, 로고 같은 자료를 상황에 맞게 가져오는 기능을 원했다. 이런 요구는 한 번의 프롬프트보다 영상 편집용 작업 공간에 더 잘 맞는다. 에이전트가 필요한 도구를 추가하고, 결과를 보면서 스크립트를 다듬고, 다음 영상에서도 그대로 쓸 수 있기 때문이다.
이미지 생성도 같은 방식으로 다룰 수 있다. 얼굴 표정을 크게 바꾸면 사람이 어색해질 수 있지만, 원래 얼굴을 유지한 채 배경이나 글자를 바꾸는 일은 상대적으로 잘 된다. Claude는 Gemini나 OpenAI의 이미지 생성 API를 직접 호출할 수 있다. 생성한 얼굴과 배경을 다시 살펴보고 조금씩 고치게 하면 한 번에 결과를 받는 방식보다 나아질 수 있다. Claude의 강점은 모든 미디어를 직접 만드는 데만 있지 않다. 다른 도구를 골라 쓰고 결과를 보며 다음 행동을 정하는 데 있다.
워크플로는 병렬 처리와 독립 검증을 함께 설계한다
짧은 영상 여러 개를 만들 때는 워크플로가 힘을 발휘한다. 먼저 중심 에이전트가 긴 영상에서 클립으로 만들 다섯 구간을 고른다. 워크플로는 각 구간을 별도 에이전트에게 맡긴다. 각 에이전트는 좋은 클립의 기준을 담은 평가표를 받아 자기 결과를 확인한다. 이렇게 하면 여러 후보를 한 문맥에서 한꺼번에 만들 때보다 각 클립을 충분히 검토하고 다듬을 수 있다.
워크플로는 JavaScript 파일로 만들 수 있다. Claude Code에 "열 개의 클립을 만들고 이 평가표로 확인하는 워크플로를 써라"라고 요청해 초안을 만들 수 있다. 완성한 파일을 스킬에 넣으면 다음에도 같은 흐름을 다시 쓸 수 있다. 스킬이 작업 지식과 호출 방법을 담고, 워크플로가 에이전트의 역할과 실행 순서를 맡는 셈이다.
병렬 실행만이 워크플로의 장점은 아니다. 결과를 만든 에이전트와 검토하는 에이전트를 나누는 일이 더 중요할 수 있다. 모델은 자신이 만든 결과를 평가할 때 너그러워지는 경향이 있다. Thariq는 이를 자기 참조 편향이라고 설명한다. 만든 사람이 자기 작업을 검토하면 평가표를 느슨하게 적용하거나 일찍 멈출 수 있다.
그래서 중심 에이전트는 작업을 조정하고, 생성 에이전트는 결과를 만들고, 검증 에이전트는 별도의 문맥에서 평가표를 적용한다. 검증 에이전트가 문제를 찾으면 생성 에이전트가 다시 고친다. 각 에이전트는 서로 다른 문맥에서 일하므로 한 에이전트의 가정과 실수를 그대로 물려받을 가능성이 줄어든다.
워크플로의 핵심은 에이전트 수가 아니다. 생성과 검증을 나누고, 각 결과를 충분히 검토하고 다듬는 구조다. 정답을 기계적으로 판별할 수 없는 영상, 글, 디자인 같은 작업일수록 평가표와 독립 검증이 중요하다.
에이전트가 병렬로 일해도 사람은 한 프로젝트에 집중한다
여러 에이전트를 동시에 돌리면 생산성이 무조건 높아지지는 않는다. 다섯 가지 작업이 계속 사람에게 질문을 보내면 연속 회의보다 더 지칠 수 있다. 각 작업의 상태를 기억하고 문맥을 바꾸는 비용이 생기기 때문이다. 에이전트의 병렬 처리량과 사람의 집중력은 별개의 자원이다.
Thariq는 한 번에 한 프로젝트를 중심에 둔다. 빌드나 병합처럼 기다려야 하는 일은 다른 에이전트에게 맡길 수 있다. 탐색 작업도 뒤에서 돌릴 수 있다. 그래도 자신이 깊게 생각할 대상은 하나로 정한다. 여러 작업을 대충 오가면 프롬프트도 게을러지고, 결국 잘못된 결과를 고치느라 시간을 잃는다.
사람마다 적절한 병렬 작업 수는 다르다. 중요한 기준은 몇 개를 켰는지가 아니라 사람이 어느 작업의 품질을 책임지고 있는지 분명한지다. 나머지 작업을 맡은 에이전트는 완료 조건과 확인 방법을 갖춘 채 스스로 진행해야 한다. 에이전트가 사람을 계속 호출한다면 아직 충분한 목표나 도구를 받지 못했을 수 있다.
코드 품질을 어디까지 관리할지도 결과물의 용도에 따라 달라진다. 영상 파일만 필요하고 편집 스크립트를 다시 쓰지 않는다면 내부 코드가 얼마나 잘 정리되어 있는지는 덜 중요할 수 있다. 에이전트는 다소 거친 코드로도 결과를 만들어낼 수 있다. 반대로 오래 운영할 저장소라면 정리 비용을 미룰 수 없다. simplify 같은 기능을 쓰거나 에이전트에게 코드와 폴더를 정리하도록 맡길 수 있다.
다만 폴더 정리는 때로 에이전트보다 사람을 위한 일이다. 사람이 작업 공간을 이해하고 안심하려면 일정한 구조가 필요하다. 출력만 평가하는 작업과 장기 유지할 시스템을 구분하면 어디에 품질 기준을 엄격하게 적용할지 정하기 쉽다.
에이전트는 여러 일을 동시에 할 수 있지만 사람까지 그렇게 일할 필요는 없다. 사람은 가장 중요한 프로젝트 하나에 집중하고, 나머지는 목표와 검증 절차를 갖춘 에이전트에게 넘기는 편이 낫다.
더 똑똑한 모델에는 짧은 지침과 깊은 학습이 필요하다
Anthropic은 Claude Code의 시스템 프롬프트를 80% 줄였다. 모델이 좋아질수록 지시, 제약, 예시가 덜 필요해졌기 때문이다. 예전에는 한 도구를 설명하면서 다섯 가지 사용 예와 여러 금지 조건을 붙여야 했다. 이제 그런 예가 오히려 모델이 특정 방식만 따르게 할 수 있다.
절대 금지 문구도 주의해야 한다. 사람이 "절대 하지 마라"라고 쓸 때 실제 뜻은 "대부분의 경우 피하라"인 때가 많다. 규칙만 주면 예외가 필요한 상황에서도 모델이 움직이지 못한다. 하지 말아야 할 이유를 설명하면 모델이 상황에 맞게 판단할 여지가 생긴다. 물론 280자 제한처럼 반드시 지켜야 하는 조건은 그대로 명확하게 써야 한다.
예를 들어 한 개의 게시물을 원한다면 "한 게시물을 우선하되, 두 개로 나눌 때 훨씬 좋아지면 스레드로 만들어도 된다"라고 말할 수 있다. 목표와 선호를 함께 주면 모델은 조건을 지키면서 더 나은 결과를 찾는다. 작성자의 배경과 글쓰기 원칙을 알려주는 것도 구체적인 금지 목록보다 도움이 될 수 있다.
이 관점에서 긴 CLAUDE.md와 스킬은 계속 줄여볼 대상이다. 도구 설명이 문맥을 많이 차지하면 모델이 실제 문제를 검토하는 데 쓸 수 있는 문맥이 줄어든다. MCP도 도구 수와 설명에 따라 문맥을 차지하지만, 도구 검색 같은 기능이 이 부담을 줄인다. 모델이 좋아질수록 좋은 지침은 모든 행동을 미리 정하지 않는다. 목적, 이유, 반드시 지킬 조건만 남긴다.
지침을 줄이는 일은 사람이 기술을 몰라도 된다는 뜻이 아니다. 에이전트가 코드를 대신 써주면 문법을 외우는 가치는 줄 수 있다. 그래도 시스템의 제약과 선택지는 알아야 한다. 서로 다른 백엔드 서비스가 각각 어떤 장단점이 있는지, 영상 처리 라이브러리가 어떻게 다른지, 로컬과 원격 전사 방식이 비용·속도·품질에 어떤 영향을 주는지를 알아야 더 좋은 방향을 고를 수 있다.
배움의 목표는 자신이 무엇을 모르는지 발견하는 데 있다. 지금 시스템이 어떻게 작동하는지, 무엇까지 가능한지, 다른 방식을 쓰면 얼마나 좋아질 수 있는지를 묻는다. Claude에게 이 질문을 던지고 설명이나 HTML 보고서를 만들게 할 수 있다. 하지만 보고서를 실제로 읽고 이해하려는 노력은 사람이 해야 한다.
배움은 결과만 받는 것보다 힘들다. 영상 클립이 나오기만 기다리면 아무것도 배우지 않아도 된다. 최고 수준의 클립을 만들려면 영상 제작과 편집, 기술 도구의 원리를 함께 익혀야 한다. 에이전트가 빨리 만들어준 결과를 출발점으로 삼되, 사람이 그 작동 방식을 파고들어야 다음 목표와 평가 기준도 좋아진다.
결국 에이전트와 일하는 능력은 더 많은 프롬프트를 보내는 기술이 아니다. 목표를 세우고, 재사용할 작업 공간을 만들고, 생성과 검증을 나누고, 사람이 배워야 할 지점을 고르는 기술이다. 그래야 에이전트가 단순히 더 빨리 일하는 데서 멈추지 않고 사람과 함께 더 나은 결과를 만든다.
https://youtu.be/aVO6E181cNU?si=HDxZrFXsrwEMag0k
Deep Dive
2026-07-20
스킬은 행동을, 작업 공간은 축적된 성과를 재사용한다
스킬은 작업 순서, 판단 기준, 도구 사용법처럼 되풀이할 방법을 담는다. 작업 공간은 작업 이력뿐 아니라 검증된 스크립트, 자료, 중간 결과와 현재 상태를 축적한다. 스킬이 "어떻게 일할 것인가"를 알려준다면 작업 공간은 "지금까지 무엇을 만들어 두었는가"를 알려준다.
그러나 기존 결과물이 다음 작업에 자동으로 도움이 되는 것은 아니다. 에이전트가 결과물을 찾고, 읽고, 믿을 수 있어야 한다. 따라서 작업 공간을 관리한다는 것은 모든 파일을 보존하는 일이 아니다. 다시 쓸 자산과 판단 기록은 기준으로 승격하고, 일회성 결과는 분리하며, 실패한 임시 파일과 오래된 설정은 폐기하는 일이다. 작업 공간은 결과물을 쌓는 곳이 아니라 검증된 결과물을 다음 작업의 입력으로 바꾸는 곳이다.
코드 정리는 미래의 기본 선택을 관리한다
코드는 실행되는 결과물이면서 다음 코드를 만드는 개발자와 에이전트가 참고하는 지침이다. AI는 기존 코드에서 비슷한 구현을 찾아 새 코드를 만든다. 임시 구현과 중복된 방식이 남아 있으면 AI는 그것을 정상적인 예시로 받아들이고 반복한다. 그러면 과거의 임시 선택이 우리가 원하지 않는 방향으로 확대된다.
따라서 코드 정리는 과거 코드를 보기 좋게 만드는 일이 아니다. 다음 구현이 따라야 할 기준을 분명하게 만드는 일이다. 중복 로직을 하나의 기준 구현으로 합치고, 쓰지 않는 코드를 제거하고, 올바른 사용법을 테스트로 고정해야 한다. 코드가 다음 구현을 잘못 이끌기 시작할 때 정리하면 기술 부채가 복제되는 것을 막을 수 있다.
짧은 지침은 깊은 이해의 결과다
모델이 똑똑해질수록 사용자는 모든 행동을 미리 지시할 필요가 줄어든다. 많은 예시와 절대 규칙은 모델의 선택지를 좁히고, 실제 문제를 검토하는 데 쓸 문맥을 차지할 수 있다. 좋은 지침은 목표, 맥락, 반드시 지킬 조건, 품질 기준과 자율 범위를 분명하게 남긴다.
그렇다고 사람이 덜 배워도 되는 것은 아니다. AI가 구현 방법을 고를 수 있어도 사람은 무엇이 옳은지, 어떤 위험을 허용할지, 결과가 충분히 좋은지 판단해야 한다. 깊이 이해한 사람만 반드시 제한할 부분과 AI에게 맡길 부분을 나눌 수 있다. 짧은 지침은 대충 쓴 지침이 아니라 중요하지 않은 지시를 덜어낸 결과다.
Key Insight
에이전트와 오래 일하려면 스킬로 행동을 재사용하고 작업 공간에서 검증된 성과를 다음 입력으로 승격해야 한다. 사람은 코드와 작업 공간을 정리해 잘못된 과거가 반복되지 않게 하고, 깊이 이해한 뒤 모델에 짧고 정확한 목표와 기준을 줘야 한다.