스크립트
00:00:00AI 모델에는 근본적인 문제가 있습니다. 작업을 부여할 때마다 에이전트는 결코 그 작업에 대해
00:00:04주도적으로 책임을 지지 않습니다. 바로 이 때문에 우리는 항상 에이전트의 출력을 검토해야 합니다.
00:00:09전적으로 신뢰할 수 없기 때문이죠. 하지만 이 나태함 문제가 드디어 해결되었습니다. GitHub 1위 트렌딩 작가가
00:00:15여기에 대한 해결책을 내놓았습니다. 이분은 현재 가장 인기 있는 디자인 스킬 중 하나인
00:00:20디자인 테이스트 스킬을 만든 사람이기도 합니다. 그는 AI 에이전트의 바로 이 문제를 해결하는
00:00:25Unlazy라는 새로운 스킬을 만들었습니다. Unlazy 뒤에 숨은 워크플로는 정말 창의적입니다.
00:00:31하지만 직접 실행해 보니 속도가 너무 느리다는 치명적인 문제가 있었고, 저희는 그 문제까지
00:00:36해결할 방법을 찾아냈습니다. 새로 오신 분들이라면 환영합니다. 저희는 소프트웨어 회사이자 AI
00:00:41Labs입니다. 이번 영상에서는 Unlazy가 무엇인지, 실제로 어떻게 작동하는지, 어떤 문제를 가지고 있으며
00:00:46어떻게 수정했는지 다뤄보겠습니다. 자, 나태함은 기본적으로 어떤 모델을 사용하든 상관없이 나타나는 문제입니다.
00:00:51Opus나 GPT 5.6 같은 가장 강력한 모델에서도 마찬가지입니다. 다만 더 작은 모델에서는 기능이 훨씬 적고
00:00:57한계가 훨씬 빠르게 드러나기 때문에 눈에 더 잘 띌 뿐입니다. Unlazy는 정확히 이 문제를 해결하기 위해
00:01:02만들어졌습니다. 이 스킬은 내장된 메커니즘을 통해 에이전트가 요령을 피우지 못하게 강제하고
00:01:08정말로 필요한 결과물을 전달하도록 만듭니다. 이 방식의 핵심 아이디어는 에이전트가 끝났다고
00:01:13말하게 하는 게 아니라 증명하게 만드는 것입니다. 작업이 실제로 완료되었다는 증명이 반드시 포함되어야 하는
00:01:18체크리스트인 원장(ledger)을 기준으로 작업을 검사합니다. 따라서 작업이 완료되었다고 말로만 하는 대신
00:01:23모든 부분에 대한 증거를 보여줍니다. 그리고 이 기능은 Claude Code, Codex 등 인기 있는 모든
00:01:28에이전트와 함께 작동합니다. 하지만 이 스킬이 중요한 이유를 이해하려면,
00:01:34이것이 없을 때 어떤 일이 벌어지는지, 그리고 이를 추가함으로써 어떻게 문제가 해결되는지 알아야 합니다. 본격적으로
00:01:39들어가기 전에 채널 구독과 좋아요 버튼을 눌러주시면 정말 감사하겠습니다. 이 작은
00:01:44지원 행동이 저희에게는 큰 힘이 됩니다. 자, 이 스킬을 실제로 살펴보기 전에 먼저
00:01:48에이전트가 애초에 왜 나태해지는지 이해해야 합니다. 새로운 컨텍스트 윈도우 상태에서는
00:01:54이런 문제가 전혀 느껴지지 않을 수 있습니다. 아직 들어 있는 내용이 거의 없기 때문에 모델이 부여된 작업에
00:01:59훨씬 더 잘 집중할 수 있기 때문입니다. 하지만 컨텍스트가 채워질수록 이 현상은 더 두드러집니다. 이러한 모델들은
00:02:04내장된 메모리가 전혀 없기 때문에 이전 메시지에서 어떤 일이 일어났는지 실제로 알지 못합니다. 그렇다면
00:02:09이전 상황을 어떻게 알 수 있을까요? 이 에이전트들은 새 프롬프트와 함께 이전의 모든 메시지를 함께 보내므로 모델이
00:02:14이미 일어난 일을 알 수 있습니다. 하지만 메시지를 주고받을수록 그 더미는 계속 커지고, 모델이 한 번에
00:02:20신경 써야 할 부분이 훨씬 많아집니다. 바로 이 때문에 에이전트가 작업의 각 부분에 명확하게 집중하지 못하고
00:02:26작업을 진행하면서 대충대충 처리하게 되는 것입니다. 이러한 나태함은 두 가지
00:02:31다른 방식으로 나타납니다. 첫 번째는 작업이 끝나지 않았는데도 끝났다고 말하는 경우입니다. Claude Code에
00:02:37여러 파일을 처리해 달라고 요청했을 때, 실제로 모든 파일을 확인하지 않고 일부만 연 다음
00:02:42전부 다 처리했다고 보고하는 경우가 종종 있습니다. 그리고 바로 이 부분이 비용을 낭비하게 만듭니다. 미완료된
00:02:47작업을 남겨둔 채 일찍 멈추는 모델은 용인할 수 있지만, 일찍 멈추고는 모든 걸 끝냈다고 말할 때
00:02:52문제가 발생합니다. 직접 검증해 보기 전까지는 실제로 완료되었는지 알 수 없습니다. 따라서 직접 확인하지 않고
00:02:57그 미완료된 작업 위에 계속 쌓아 나가면, 결국 장기적으로 문제가 발생하게 됩니다.
00:03:02두 번째는 아무말도 없이 작업 범위를 축소해 버리는 것입니다. 예를 들어 5가지 부분이 있는
00:03:06요청을 했는데 그중 하나가 어려운 경우, 쉬운 4가지만 만들고 어려운 부분은
00:03:12건너뜁니다. 그리고 마지막에 받는 요약에서는 빠진 내용이 무엇인지 절대 언급하지 않습니다. 이 문제가 새로운
00:03:16문제가 아니라고 생각하실 수도 있고, 그 생각이 맞습니다. 이러한 문제는 이러한 에이전트들에게
00:03:21항상 존재해 왔고, 사람들은 오랫동안 이에 대한 해결책을 만들어 왔으니까요. 아마 여러분도
00:03:26Ralph 루프에 대해 이미 알고 계실 겁니다. 그 방식은 출력 결과의 지표에 작업이 완료되었다고 나올 때까지
00:03:33에이전트에게 동일한 프롬프트를 계속해서 보냅니다. 또한 다른 모델을 심사위원으로 사용하는 Claude의 goal 명령어
00:03:39도 있습니다. 우리 역시 모든 작업이 통과해야 하는 체크리스트를 유지하는 이러한 루프를 직접 만들어 보기도 했습니다. 하지만 이 모든 것에는
00:03:44한계가 있습니다. Ralph의 경우, 그 결승선은 에이전트가 작업 중에 작성하는 약간의 텍스트일 뿐이지만, 많은 작업들은
00:03:50결승선 하나로 판단할 수 없습니다. 기능이 제대로 구축되었는지 알려주는 단 하나의 단어 같은 것은 없으니까요.
00:03:56그리고 goal 명령어는 대화를 읽고 작업이 완료되었는지 여부를 결정하는 더 작은 모델을 사용합니다.
00:04:02따라서 실제 작업 자체가 아니라 대화 내용에 따라 판단하므로, 정말로 필요한 것에서 벗어날 수 있습니다.
00:04:07그리고 우리 자신의 루프의 경우 검증은 실제적이었지만, 그것들을 채점한 것은 에이전트 자신이었기 때문에
00:04:12완료 여부를 결정하는 것도 여전히 에이전트였습니다. 이러한 방법들은 컨텍스트 윈도우가 쾌적할 때는
00:04:17모두 정말 잘 작동할 수 있습니다. 하지만 실제 작업에 깊게 몰두하게 되면 흔들리기 시작합니다.
00:04:22그리고 정확히 그 지점이 바로 그것들이 버텨주어야 하는 순간입니다. 하지만 이러한 문제를 해결하는 전체 워크플로를
00:04:26보여드리기 전에, 스폰서의 메시지를 들어보겠습니다. Data for SEO입니다. SEO 툴이나 마케팅
00:04:33대시보드를 바이브 코딩해 보셨다면, 그것이 뒷받침하는 데이터만큼만 훌륭하다는 것을 아실 겁니다. 그리고 실제 SEO 데이터는 보통
00:04:39제품을 출시하기도 전에 비싼 월간 구독료를 의미합니다. Data for SEO는 그 문제를 해결합니다. 세계 최고의 SEO 데이터
00:04:45제공업체 중 하나로, 키워드와 백링크부터 경쟁사 리포트와 AI 검색 가시성까지 모든 것을 다루는 10개 이상의 API를 제공합니다.
00:04:51대시보드에는 API 플레이그라운드가 있습니다. 키워드를 입력하고
00:04:56요청 한 번을 보냈더니 몇 초 만에 검색량과 상위 랭킹 페이지가 눈앞에 나타났습니다.
00:05:02그런 다음 앱에 플러그인할 코드를 건네주었고, 우리의 대시보드는 1분도 안 되어 실시간 순위를 가져오기 시작했습니다.
00:05:06설치는 5분이 채 걸리지 않았습니다. 가격 책정이 진정한 장점입니다. 구독료가 없고
00:05:11요청당 종량제로 비용을 지불하므로 성장에 따라 비용이 조절됩니다. 봇이 아닌 실제 인간의 연중무휴 지원도 제공됩니다.
00:05:17보통은 1달러 체험판으로 시작하지만, 저희 링크를 사용하시면 5달러어치 무료 크레딧이 추가됩니다.
00:05:23링크를 통해 빌드해 보세요. 링크는 고정 댓글에 있습니다. 자, 이를 설정하는 방법을 보여드리기 전에
00:05:27내부적으로 실제로 무슨 일이 일어나고 있는지, 그리고 그것이 어떻게 문제를 해결하는지 살펴보겠습니다. 이 스킬에 큰
00:05:33작업을 부여하면 바로 작업을 시작하지 않습니다. 먼저 그 작업을 더 작은 작업들로 쪼갠 다음, 각 작업을
00:05:38가져와서 다시 더 작은 작업들로 쪼갭니다. 그래서 전체적인 구조가 가지치기처럼 뻗어 나가며, 하나의 작업이
00:05:44여러 개로 바뀌고 그 각각이 다시 몇 개씩으로 바뀝니다. 그래서 이것을 트리라고 부릅니다. 분할이 멈추면
00:05:49끝에 있는 모든 작은 작업들은 각각 독립된 서브 에이전트에게 넘겨집니다. 그리고 그 과정이 얼마나
00:05:54반복될지 제어하는 것은 바로 여러분입니다. 따라서 프롬프트를 작성할 때 이 스킬을 사용하고 싶다고 말하고
00:05:58그와 함께 숫자를 부여합니다. 그 숫자가 트리의 깊이입니다. 예를 들어 5라고 말하면
00:06:03작업이 총 5번에 걸쳐 분해되며 더 이상 분해되지 않습니다. 숫자를 전혀 입력하지 않으면
00:06:09요청하신 내용에 맞는 가장 작은 값을 선택합니다. 이 모든 작업을 수행하는 이유는 앞서 언급한
00:06:14주의력 문제와 직결됩니다. 작업이 이런 식으로 쪼개지면 각 작업은 하나의 명확한 목표를 가지며,
00:06:19그 작업을 수행하는 에이전트는 나머지 업무를 짊어지고 다니지 않게 됩니다. 하지만 이러한
00:06:24작업이 너무 작아져서도 안 됩니다. 이 스킬이 제시하는 규칙은 각 작업이 최소 10분 분량의
00:06:29실제 작업 가치가 있어야 한다는 것입니다. 에이전트가 스스로 집어 들고 완료할 수 있는
00:06:34적절한 업무 조각이어야 하기 때문입니다. 따라서 숫자를 너무 높게 설정하여 작업 결과물이 10분 분량의
00:06:39작업보다 작아지면, 스킬은 분할된 작업을 기본값인 3으로 낮춥니다. 그리고 그 숫자에 따라
00:06:45작업 실행 방식이 결정됩니다. 3 이하인 경우 스킬에서 솔로 모드라고 부르며, 이것이 기본값입니다.
00:06:51모든 것이 하나의 세션 내에 유지되며 동일한 에이전트가 전체 작업을 처리합니다. 하지만 4 이상이면
00:06:56오케스트레이션 모드로 전환되며, 이때는 기록되는 내용이 훨씬 더 많아집니다. 전체 분할 내용을 담는
00:07:02계획 파일과 그 안에 있는 모든 단일 작업에 대한 별도의 체크리스트를 작성합니다. 그리고 파일을
00:07:06통해 기록을 남기는 이유는 이전 버전의 이 스킬이 실패했던 방식에서 기인합니다. 이전 버전은
00:07:11에이전트에게 철저해지라고 지시함으로써 나태함을 고치려 했습니다. 하지만 지시사항이라는 것은 긴 세션 속에서
00:07:16가장 먼저 유실되는 것이며, 그것이야말로 해결하려던 바로 그 문제였습니다. 그래서 이번 버전에서는
00:07:21요청하는 것을 멈추고 어떤 작업이 시작되기도 전에 파일에 기록하기 시작했습니다. 그 파일이 게이트
00:07:26파일이며, 앞에서 언급했던 원장입니다. 그리고 그 파일의 모든 항목을 게이트라고 부릅니다. 따라서
00:07:32각 게이트는 옆에 결과가 적혀 있는 체크박스인데, 작업이 완료된 것으로 간주되기 위해 반드시 참이어야 하는
00:07:37한 가지 조건입니다. 그리고 그 결과 아래에는 세 줄이 있습니다. 첫 번째는
00:07:42그 결과가 달성되었음을 증명하는 명령어입니다. 두 번째는 그 명령어가 반환해야 하는 정확한 단어들이며,
00:07:47세 번째는 증거로, 처음에는 단순히 대기 중(pending)이라고 시작됩니다. 그런 다음 스킬에
00:07:52체커가 내장되어 있어서 이를 실행하면 해당 파일을 따라 내려가며 이러한 명령어들을 전부
00:07:57직접 실행합니다. 돌아온 답변에 게이트가 예상하던 단어가 포함되어 있다면 박스에 체크하고
00:08:02그 대기 중 줄을 판정을 내리게 만든 답변의 일부로 대체합니다. 그리고 그 증거 줄이 바로
00:08:07앞서 나열한 모든 해결책들의 구멍을 메워주는 요소입니다. 대기 중이라는 글자가 여전히 아래에 남아 있는 체크된 박스는
00:08:12에이전트가 그 박스에 직접 체크했다는 뜻이며, 이는 에이전트가 다 끝냈다고 다시 말하는 것뿐입니다. 따라서
00:08:17미충족으로 간주되며, 스킬은 이를 빈 박스보다 더 나쁜 것으로 취급합니다. 빈 박스는 적어도 작업이
00:08:23실제로 어디까지 진행되었는지에 대해 정직하기 때문입니다. 그리고 그 동일한 규칙이 더 큰 규모의 실행도 정직하게 유지해 줍니다.
00:08:28오케스트레이션 모드에서는 하나의 작업을 새로운 에이전트에게 넘기는데, 이 에이전트는 계획과 해당 작업의
00:08:33게이트 파일만 받게 되며 나머지 작업에 대해서는 알지 못합니다. 하지만 그 에이전트가 끝났다고 돌아왔을 때,
00:08:38메인 에이전트는 그 말을 그대로 믿지 않고 해당 작업의 검증을 직접 다시 실행합니다. 그리고 오직 그럴 때만
00:08:43계획 파일에 한 줄을 작성하고 다음 작업을 내어줍니다. 그리고 정직한 탈출구도 존재합니다.
00:08:48때로는 작업이 불가능한 경우도 생기기 때문입니다. 그래서 에이전트가 작업을 그냥 포기하고
00:08:53아무 말도 안 하는 대신, 해당 게이트를 포기한다는 내용과 이유를 이름과 함께 리포트에 남기며
00:08:58이는 최종 결과물에 그대로 반영됩니다. 즉, unlazy는 단순히 마지막의 단일 검사라기보다는
00:09:03전체 시스템에 가깝습니다. 그리고 이 과정 그 어디에서도 에이전트가 임의로 작업 완료 여부를
00:09:08결정할 수 없습니다. 이제 실제로 이 스킬을 사용하려면
00:09:13먼저 설치를 진행해야 합니다. 공식 GitHub 페이지로 이동해 설치 섹션에서 명령어 복사하면 됩니다.
00:09:17링크는 아래 더보기란에서 확인하실 수 있습니다. 그후 작업 중인 프로젝트의 터미널을 열고 실행합니다.
00:09:22실행을 완료하면 설치 프로그램이 시작되며, 가장 먼저 어떤 에이전트를 사용 중인지 묻습니다. Codex를 사용 중이라면
00:09:27Codex가 이미 읽어들이는 .agents 폴더에 설치되므로 따로 설정할 필요가 없습니다.
00:09:33하지만 Claude Code를 사용하는 경우 열리는 메뉴에서 선택하면 되며, 필요에 따라 다른 항목도 동시에 여러 개 선택할 수 있습니다.
00:09:38그런 다음 범위를 선택하라고 나오는데, 기본적으로 이 스킬을 현재 작업 중인 프로젝트 내에서만
00:09:43동작하게 할 것인지, 아니면 앞으로 만드는 모든 프로젝트에서 사용할 수 있게 할 것인지를 결정하는 것입니다.
00:09:47우선 특정 프로젝트 하나에 먼저 테스트해보고 싶었기 때문에 프로젝트 범위로 설정했습니다.
00:09:52그 후 추천 옵션을 선택하면 설치가 완료됩니다.
00:09:57이제 VS Code에서 해당 프로젝트를 열어보면 .agents와 .clawed라는 두 개의 새로운 폴더가 생성된 것을 볼 수 있습니다.
00:10:02이들이 각각 별개의 복사본인 것은 아닙니다. 스킬 자체는 실제로 .agents 폴더 안에 위치하며,
00:10:08.clawed 폴더는 단축키 같은 역할이라 Claude나 Codex가
00:10:12동일 프로젝트 내에서 중복 없이 이를 인식하고 사용할 수 있게 해줍니다. 이제 해당 폴더 안에서
00:10:17스킬 파일은 에이전트가 이 기능을 어떻게 활용해야 하는지에 대한 모든 지침을 담고 있습니다.
00:10:23이 작업까지 끝나면 스킬 설치가 완료되어 바로 사용할 준비가 된 것입니다. 하지만 시작하기 전에
00:10:28반드시 알아두어야 할 점이 하나 있습니다. 이 스킬을 수정 없이 그대로 실행하면 의미 있는 결과물을
00:10:33만들어내는 데 정말 오랜 시간이 걸립니다. 앱을 대상으로 테스트를 진행하면서 이 사실을 알게 되었습니다. 세션이
00:10:37약 3~4시간 동안 연속으로 실행되었는데도, 진행 상황을 확인해보니 로그인 페이지만 달랑 만들어져 있고
00:10:42아무것도 없었습니다. 스킬의 내부 동작을 살펴보니 원인은 바로 그 지침에 있었습니다.
00:10:47Claude Code와 Codex 모두 여러 에이전트를 동시에 실행할 수 있고 각 서브 에이전트가 서로 다른 작업에 대해
00:10:52병렬로 작업할 수 있습니다. 하지만 이 스킬은 하나의 작업만 던져주고 완료될 때까지 기다린 뒤에야
00:10:57다음 작업을 넘겨주는 방식을 취하고 있었습니다. 따라서 에이전트를 실행하고는 있었지만
00:11:02에이전트들의 잠재력을 최대한 활용하지 못하고 있었고, 그 수많은 시간이 전부 거기에 낭비되었던 것입니다. 그래서 프로젝트를 다시 열어
00:11:06스킬 자체를 수정했습니다. 직접 수정하고 싶으시다면 여기서 영상을 잠시 멈추고 저희가 사용한 프롬프트를 복사해 가셔도 좋습니다.
00:11:11직접 수정하고 싶으시다면 이 프롬프트를 복사해 사용해 보세요. 이 스킬이 하는 일은
00:11:16이 도구들이 여러 에이전트를 동시에 실행할 수 있다는 점을 실제로 활용하도록 만드는 것입니다. 실행하려면 스킬 이름과 트리 깊이를
00:11:21입력한 뒤, 만들고 싶은 내용을 모두 작성하면 됩니다. 저희는 이 데모 앱을 처음부터 만들었기 때문에
00:11:255를 선택했습니다. 하지만 이 숫자는 작업의 규모에 따라 선택하시면 됩니다. 전체 앱이 아니라
00:11:30특정 기능 하나만 작업하고 싶다면 2나 3으로도 충분합니다. 그리고 잘못된 옵션을
00:11:35선택할까 걱정하지 않으셔도 됩니다. 필요한 것보다 높게 설정하면 자동으로
00:11:40깊이를 낮춰주기 때문입니다. 무언가를 구축하기 전에 가장 먼저 하는 일은 plan.md
00:11:45파일과 gates.md 파일을 작성하는 것입니다. plan.md에서는 어떤 작업이 어떤 파일과 연동되는지도 명시하여
00:11:51두 에이전트가 동시에 작업할 때 서로의 코드를 덮어쓰지 않도록 합니다. 그런 다음
00:11:56기반을 다지고 동시에 실행 중인 에이전트들에게 작업을 나누어주기 시작합니다. 그렇게
00:12:01수정 사항을 적용한 후 10개의 에이전트가 동시에 각기 다른 부분을 작업했습니다. 그 실행은 거의 2시간 동안
00:12:06진행되었습니다. 마침내 모든 기능이 원하는 대로 정확히 작동하는 데모 앱의 첫 번째 버전을 얻게 되었습니다.
00:12:11이런 규모로 개발을 진행하신다면, 여기에 모델 라우터 스킬을
00:12:16함께 사용할 수도 있습니다. 이는 각 작업을 그에 가장 알맞은 모델로 보내주는 역할을 합니다. 따라서
00:12:21단순한 기계적 작업은 더 저렴한 모델에 맡기고 어려운 부분은 성능 좋은 모델에 맡겨
00:12:26사용량 한도에 빨리 도달하지 않도록 하는 것입니다. 자, 여기서 우리가 사용한 이 스킬은 여러 차례의 테스트와
00:12:31수정을 거쳐 만들어졌습니다. 이 스킬이 필요하시다면 저희 커뮤니티인 AI Labs Pro에서 얻으실 수 있습니다.
00:12:36저희 활동에서 유익함을 얻으셨고 채널을 지원하고 싶으시다면 이것이 바로 그 방법입니다.
00:12:40링크는 설명란에 있습니다. 이것으로 이번 영상도 마무리되겠습니다. 채널을 지원하고
00:12:44이와 같은 영상을 계속 만들 수 있도록 돕고 싶으시다면 아래의 슈퍼 땡스 버튼을 통해
00:12:49시청해 주셔서 감사합니다.
커뮤니티 글
아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!
이 영상에 대해 글쓰기