영상 정리 · AI·개발
AI 에이전트가 "다 했다"고 거짓말하는 문제를, 작업을 트리로 쪼개고 명령어 실행 결과로만 완료를 인정하는 Unlazy 스킬로 잡는 법과, 직렬 실행 때문에 3~4시간 걸리던 걸 10개 병렬 에이전트로 2시간으로 줄인 실전 수정법을 정리한 영상
영상의 영어 원어 자막 전체가 근거입니다. 30초 묶음 22개, 13,963자, 끝 시각 11분 26초(영상 길이 11분 31초). 이 영상은 원어가 영어이고 원어 자막(en-orig) 하나만 받아 두었으며, 그 하나로 영상 시간을 거의 다 채우므로 그대로 썼습니다. 폴더 이름의 "[한영자막]"은 업로더가 영상 화면 안에 직접 박아 넣은 자막을 뜻하는 것으로 보이며, 유튜브 자막 트랙과는 다른 것입니다.
영상이 소개하는 원 저장소(GitHub의 Leonxlnx/unlazy)를 직접 열어 대조했습니다. 그래서 이 정리에는 영상에 없는 내용이 들어 있습니다. 그런 대목은 "영상에 없음"이라고 표시했습니다.
영상 속 해설자가 자기 채널을 직접 밝히는 대목이 있는데, 정리해 둔 메타데이터(채널명 "Tech Bridge")와 어긋납니다. 부록 B 참고.
이 영상은 낱말 다섯 개를 안다고 전제하고 말합니다. 하나씩 풀고 갑니다.
영상은 AI 에이전트를 쓰는 사람이라면 다 겪어 본 문제로 시작합니다.
"AI 모델에는 근본적인 문제가 하나 있습니다. 작업을 맡기면 그 작업에 대한 책임을 절대 스스로 지지 않습니다. 그래서 우리는 항상 에이전트의 결과물을 다시 검토해야 합니다. 그걸 믿을 수가 없기 때문이죠. 그런데 이 게으름 문제가 방금 풀렸습니다."
해설자 [00:00]
해결책을 내놓은 사람은 GitHub 트렌딩 1위에 오른 개발자라고 소개됩니다. 같은 사람이 만든 다른 스킬로 "디자인 취향(design taste) 스킬"도 언급되는데, 지금 가장 인기 있는 디자인 스킬 중 하나라고 합니다. 이 개발자가 이번에 내놓은 것이 Unlazy라는 스킬이고, AI 에이전트의 이 게으름 문제를 정확히 겨냥해서 만들어졌습니다.
채널 소개도 이어집니다. 해설자는 자신들을 소프트웨어 회사라고 밝히고, 채널 이름을 직접 말합니다.
"저희는 소프트웨어 회사고, 여기는 AI Labs입니다."
해설자 [00:32]
이어서 이 게으름이 모델을 가리지 않고 나타나는 문제라는 점을 짚습니다. Opus나 GPT 5.6처럼 강력한 모델도 예외가 아니고, 다만 작은 모델일수록 능력이 부족해서 한계가 더 빨리 눈에 띌 뿐이라는 것입니다. [00:32]
그리고 Unlazy가 다른 시도들과 무엇이 다른지를 한 문장으로 요약합니다.
"이 스킬은 에이전트가 다 됐다고 말만 하지 않게 만듭니다. 그걸 증명하게 만듭니다. 원장(ledger)을 놓고 그 작업을 검사하는데, 이 원장은 항목마다 정말로 끝났다는 증거가 있어야 하는 체크리스트입니다. 그러니까 그냥 작업이 끝났다고 말하는 대신, 모든 부분에 대해 증거를 보여 줍니다. 그리고 Claude Code, Codex를 비롯해 인기 있는 에이전트 대부분과 같이 씁니다."
해설자 [01:04]
"원장"과 "증거"가 정확히 어떤 모양인지는 5장에서 그대로 다룹니다. 그 전에, 애초에 에이전트가 왜 게을러지는지부터 봐야 합니다.
AI 모델은 앞서 0장에서 풀었듯 그 자체로는 아무것도 기억하지 못합니다. 그래서 매번 지금까지의 대화 전체를 새 메시지와 함께 다시 보냅니다.
"이 에이전트들은 이전 메시지 전부를 새 프롬프트와 함께 보냅니다. 그래야 모델이 이전에 무슨 일이 있었는지 알 수 있으니까요. 그런데 메시지를 더 많이 보낼수록 그 더미는 계속 커지고, 모델이 한 번에 신경 써야 할 게 훨씬 많아집니다. 바로 이 때문에 에이전트가 작업의 각 부분에 뚜렷하게 집중하지 못하고, 일하는 도중에 그냥 대충 넘어가 버립니다."
해설자 [01:37]~[02:09]
이 게으름은 두 가지 방식으로 나타난다고 영상은 정리합니다. 첫째는 끝나지 않았는데 끝났다고 말하는 것입니다.
"Claude Code에게 여러 파일을 훑어보라고 시켰는데, 실제로는 몇 개만 열어 보고도 전체를 다 훑었다고 보고하는 일이 여러 번 있었습니다."
해설자 [02:09]
영상은 여기서 무엇이 진짜 문제인지를 구분합니다. 일을 다 못 끝내고 멈추는 것 자체는 괜찮습니다. 미완성이라는 게 눈에 보이니까요. 문제는 미완성인 채로 멈춰 놓고 다 끝났다고 말하는 것입니다. 그러면 직접 확인하지 않는 한 정말 끝났는지 알 길이 없고, 그 위에 계속 새 작업을 쌓아 올리면 나중에 문제가 터집니다. [02:41]
둘째는 알리지도 않고 작업 범위를 몰래 줄이는 것입니다.
"예를 들어 다섯 부분으로 이루어진 걸 부탁했다고 해 보죠. 그중 하나가 어렵습니다. 에이전트는 쉬운 네 개만 만들고 어려운 하나는 건너뜁니다. 그리고 마지막에 받는 요약에는 뭔가 빠졌다는 말이 전혀 없습니다."
해설자 [02:41]~[03:14]
둘 다 원인은 같습니다. 컨텍스트가 쌓일수록 모델이 각 부분에 쏟는 주의가 옅어진다는 것입니다. 그런데 영상은 여기서 곧바로 "이건 이미 다들 알던 문제고, 고쳐 보려는 시도도 많았다"고 짚고 넘어갑니다.
영상은 이 문제가 새롭지 않다는 걸 인정합니다. 이미 나와 있던 세 가지 시도를 짚습니다.
"랄프 루프(Ralph loop)는 이미 아실 겁니다. 같은 프롬프트를 계속 다시 보내는 방식인데, 에이전트가 결과물에 '작업 끝'이라는 표시를 남길 때까지 반복합니다. Claude의 goal 커맨드도 있는데, 이건 다른 모델을 심판으로 씁니다. 저희도 이런 루프를 직접 만들어 본 적이 있는데, 작업 목록에 각 작업이 통과해야 할 체크 항목을 넣어 두는 방식이었습니다."
해설자 [03:14]~[03:48]
세 가지 다 나름의 한계가 있다고 영상은 하나씩 짚습니다. 랄프 루프의 한계는 "끝났다"는 표시가 그냥 에이전트가 일하면서 스스로 적어 넣는 글자 몇 개일 뿐이라는 점입니다. 그런데 많은 작업은 이런 한 줄짜리 표시로는 판단할 수 없습니다. "기능이 제대로 만들어졌다"는 걸 알려주는 낱말 하나 같은 건 없기 때문입니다.
goal 커맨드의 한계는 작은 모델이 대화 내용을 읽고 끝났는지를 판단한다는 점입니다. 즉 실제로 만들어진 결과물이 아니라 대화가 뭐라고 말했는지로 판단하는 것이고, 그러다 보니 원래 필요했던 것과 어긋날 수 있습니다.
영상 팀이 직접 만들었던 루프의 한계도 인정합니다. 체크 항목 자체는 진짜였지만, 그 체크가 통과했는지를 판단하는 게 결국 에이전트 자신이었다는 것입니다. 결국 일이 끝났는지를 에이전트가 스스로 정하는 구조는 그대로였습니다.
"이 방식들 모두 컨텍스트 윈도우가 아직 깨끗할 때는 꽤 잘 작동합니다. 그런데 진짜 작업으로 깊이 들어가면 흔들리기 시작합니다. 그리고 바로 그 지점이야말로 이 방식들이 버텨 줘야 하는 순간입니다."
해설자 [04:20]
정리하면, 기존 방식들의 공통된 구멍은 "끝났다"는 판정을 결국 에이전트 자신이나, 에이전트가 남긴 흔적에 맡긴다는 것입니다. Unlazy는 여기서부터 다르게 설계됩니다.
Unlazy에게 큰 작업을 맡기면, 이 스킬은 곧바로 일을 시작하지 않습니다. 먼저 작업을 쪼갭니다.
"큰 작업을 주면, 그걸 먼저 더 작은 작업들로 쪼갭니다. 그리고 그 작은 작업 하나하나를 또 더 작은 작업으로 쪼갭니다. 그렇게 전체가 가지를 치듯 뻗어 나갑니다. 하나의 작업이 몇 개로, 그 각각이 다시 몇 개로 갈라지죠. 그래서 이름이 트리(tree)입니다."
해설자 [04:20]~[04:53]
더는 쪼개지지 않는 가장 작은 단위(리프)에 이르면, 그 하나하나가 각자의 서브 에이전트에게 넘어갑니다. 그리고 몇 번을 쪼갤지는 사용자가 직접 정합니다. 프롬프트에 스킬 이름과 함께 숫자를 하나 적으면, 그게 트리의 깊이입니다. 5라고 적으면 다섯 번 쪼개고 거기서 멈춥니다. 숫자를 아예 안 주면, 스킬이 지금 시킨 일에 맞는 가장 작은 숫자를 알아서 고릅니다. [04:53]
왜 굳이 이렇게 잘게 쪼개는지는 2장에서 나온 문제로 곧장 이어집니다. 작업이 이렇게 쪼개지면 각 조각은 목표가 하나뿐이고, 그 조각을 맡은 에이전트는 나머지 전체 작업을 떠안고 있지 않아도 됩니다. 컨텍스트가 쌓여서 주의가 흐트러지는 문제 자체를 피하는 것입니다.
하지만 너무 잘게 쪼개도 안 됩니다. 스킬이 정해 둔 규칙이 있습니다.
"이 스킬이 정한 규칙은, 각 조각이 최소한 10분어치의 실제 작업이어야 한다는 겁니다. 에이전트가 혼자 맡아서 끝낼 수 있는 제대로 된 일의 단위여야 하니까요. 그래서 숫자를 너무 높게 잡아서 조각이 10분어치보다 작게 나오면, 스킬이 알아서 기본값인 3으로 낮춥니다."
해설자 [04:53]~[05:25]
그리고 이 숫자(트리 깊이)가 작업이 어떻게 돌아가는지도 정합니다. 3 이하는 "솔로 모드"이고, 이게 기본값입니다. 모든 일이 한 세션 안에서, 같은 에이전트 하나가 끝까지 처리합니다. 4 이상은 "오케스트레이션 모드"로 넘어가는데, 여기서부터는 훨씬 많은 걸 파일로 적어 둡니다. 전체 작업 배분을 담은 계획 파일 하나, 그리고 그 안의 작업마다 따로 붙는 체크리스트입니다. [05:58]
왜 굳이 파일에 적어 두는지는, 이 스킬의 이전 버전이 왜 실패했는지에서 나옵니다.
"이전 버전의 스킬은 에이전트에게 '꼼꼼하게 하라'고 지시하는 방식으로 게으름을 고치려고 했습니다. 그런데 긴 세션에서는 지시문이야말로 가장 먼저 잊히는 것이고, 그게 정확히 이 스킬이 고치려던 그 문제였습니다. 그래서 이번 버전은 부탁하는 걸 그만두고, 일을 시작하기 전에 파일에 미리 적어 두는 쪽으로 바꿨습니다."
해설자 [05:58]~[06:30]
그 파일이 게이트 파일이고, 1장에서 나온 원장(ledger)이 바로 이겁니다. 그 안의 항목 하나하나를 게이트라고 부릅니다.
"게이트 하나는 결과와 함께 적힌 체크박스입니다. 작업이 끝났다고 치기 전에 반드시 참이어야 하는 것 하나죠. 그리고 그 결과 아래에 세 줄이 붙습니다. 첫째는 그 결과가 달성됐다는 걸 증명하는 명령어입니다. 둘째는 그 명령어가 돌려줘야 하는 정확한 문구입니다. 셋째는 증거인데, 처음에는 그냥 '대기 중(pending)'이라고만 적혀 있습니다."
해설자 [06:30]~[07:03]
이 스킬에는 검사기(checker)가 딸려 옵니다. 이걸 돌리면 그 파일을 처음부터 끝까지 훑으면서, 적혀 있는 명령어를 스킬 자신이 직접 하나씩 실행합니다. 돌아온 답에 그 게이트가 기대하던 문구가 들어 있으면 체크박스에 체크하고, "대기 중"이라고 적혀 있던 줄을 그 답의 일부로 바꿔 씁니다. [07:03]
바로 이 증거 줄이, 앞서 3장에서 짚은 기존 방식들의 구멍을 정확히 막습니다.
"체크박스는 체크돼 있는데 그 아래는 여전히 '대기 중'이다 — 이건 에이전트가 스스로 체크박스를 체크했다는 뜻이고, 결국 에이전트가 다시 한번 '저 끝났어요'라고 말하는 것과 똑같습니다. 그래서 이건 '충족 안 됨'으로 칩니다. 그리고 스킬은 이걸 빈 체크박스보다 더 나쁘게 취급합니다. 빈 체크박스는 적어도 작업이 실제로 어디까지 갔는지에 대해 정직하니까요."
해설자 [07:03]~[07:35]
즉 게이트는 "됐다"는 말을 아예 받아들이지 않습니다. 명령어를 실제로 돌려서 나온 문구만 증거로 인정합니다. 그런데 트리가 커져서 여러 서브 에이전트가 나눠 일하게 되면, 이 검증을 누가 언제 하느냐가 또 다른 문제가 됩니다.
4장에서 본 오케스트레이션 모드(트리 깊이 4 이상)에서는, 게이트의 이 원칙이 서브 에이전트 사이의 관계에도 그대로 적용됩니다.
"오케스트레이션 모드에서는 새 에이전트 하나에게 작업 하나를 맡기는데, 그 에이전트는 오직 전체 계획과 자기 몫의 게이트 파일만 받습니다. 나머지 작업에 대해서는 아무것도 모릅니다. 그런데 그 에이전트가 다 끝났다고 돌아와도, 메인 에이전트는 그 말을 그대로 믿지 않고 그 작업의 체크들을 자기가 직접 다시 실행합니다. 그렇게 하고 나서야 계획 파일에 한 줄을 적고 다음 작업을 넘겨줍니다."
해설자 [07:35]
여기에 정직하게 빠져나갈 길도 마련돼 있습니다. 어떤 작업은 하다 보면 불가능하다는 게 드러나기도 합니다. 그럴 때 에이전트는 그 작업을 그냥 버리고 아무 말도 안 하는 대신, 어느 게이트를 포기했는지 이름을 밝히고 이유를 적은 줄을 남깁니다. 이건 최종 보고서에 그대로 들어갑니다. [08:08]
영상은 이 장을 이렇게 정리합니다. Unlazy는 마지막에 한 번 검사하는 게 아니라 처음부터 끝까지 통째로 하나의 시스템이고, 어느 지점에서도 에이전트 스스로 "다 됐다"고 정할 수 있는 자리가 없습니다.
여기서부터는 실제로 이 스킬을 쓰는 방법입니다. 먼저 공식 GitHub 페이지에서 설치 안내(install) 부분을 찾아 명령어를 복사합니다(영상 설명글에 저장소 링크가 있습니다). 그다음 지금 작업 중인 프로젝트 폴더 안에서 터미널을 열고 그 명령을 돌립니다.
"설치 프로그램이 시작되면 맨 먼저 어떤 에이전트를 쓰는지 묻습니다. Codex를 쓴다면 따로 바꿀 게 없습니다. Codex가 이미 읽고 있는 agents 폴더에 그대로 설치되니까요. 하지만 Claude Code라면, 열리는 메뉴에서 직접 골라야 합니다. 그리고 동시에 다른 것들도 원하는 만큼 같이 고를 수 있습니다."
해설자 [08:08]~[08:41]
그다음은 범위(scope)를 고르는 단계입니다. 지금 이 프로젝트 안에서만 쓸지, 앞으로 만들 모든 프로젝트에서 쓸 수 있게 할지를 정합니다. 영상은 특정 프로젝트 하나로 먼저 테스트해 보고 싶어서 프로젝트 범위를 골랐다고 합니다. 그 뒤로는 추천 옵션대로 넘기면 설치가 끝납니다. [08:41]
설치가 끝나고 VS Code로 그 프로젝트를 열어 보면 새 폴더가 두 개 보입니다.
"하나는 agents 폴더이고 하나는 .claude 폴더인데, 이 둘은 서로 다른 복사본이 아닙니다. 스킬 본체는 실제로 agents 폴더 안에 있고, .claude 폴더는 그저 그리로 가는 바로가기입니다. Claude Code도 프로젝트 안에 중복 없이 이 스킬을 알아보고 쓸 수 있게 하려는 것뿐입니다."
해설자 [08:41]~[09:15]
그 폴더 안의 스킬 파일 하나에 에이전트가 이 스킬을 어떻게 써야 하는지에 대한 안내가 전부 들어 있습니다. 여기까지 마치면 설치는 끝나고 바로 쓸 수 있습니다. [09:15]
다만 쓰기 전에 알아야 할 게 하나 있다고 영상은 못 박습니다. 스킬을 받은 그대로 돌리면, 뭔가 쓸 만한 게 나오기까지 시간이 정말 오래 걸립니다.
"저희가 앱 하나에 직접 써 보고 알게 된 건데요, 그 세션이 3시간에서 4시간 내내 돌아갔는데, 진행 상황을 확인해 보니 로그인 페이지 하나뿐이고 그 외엔 아무것도 없었습니다. 스킬을 살펴보니 문제는 그 지시문 안에 있었습니다."
해설자 [09:15]~[09:48]
원인은 이랬습니다.
"Claude Code와 Codex 둘 다 여러 에이전트를 동시에 돌릴 수 있고, 각 서브 에이전트가 서로 다른 작업을 병렬로 처리할 수 있습니다. 그런데 이 스킬은 작업 하나를 넘기고 그게 끝나길 기다렸다가 그제서야 다음 작업을 넘깁니다. 그러니까 에이전트를 여러 개 돌리고는 있었지만, 이 도구들의 능력을 제대로 활용하지 못했던 겁니다. 그 시간이 전부 거기서 새 나간 거고요."
해설자 [09:48]
그래서 영상 팀은 스킬 자체를 직접 고쳤습니다. 고친 것의 핵심은 하나입니다. Claude Code와 Codex가 여러 에이전트를 동시에 돌릴 수 있다는 사실을 스킬이 실제로 활용하게 만든 것입니다. 그 뒤로 스킬을 돌리는 방법은 이렇습니다. 스킬 이름, 트리 깊이, 그리고 만들고 싶은 것 전부를 이어서 적는 것입니다. [09:48]~[10:21]
영상 팀은 이번엔 데모 앱을 처음부터 만드는 거라 깊이를 5로 잡았습니다. 이 숫자는 작업 규모에 맞춰 고르면 됩니다. 앱 전체가 아니라 기능 하나 정도라면 2나 3이면 충분하다고 합니다. 숫자를 잘못 골라도 걱정할 필요는 없습니다 — 필요한 것보다 높게 잡으면 스킬이 알아서 깊이를 낮춰 줍니다(4장에서 본 10분 규칙과 같은 장치입니다). [10:21]
무언가를 만들기 전에 스킬이 가장 먼저 하는 일은 계획 파일(PLAN.md)을 쓰고, 이어서 게이트 파일(gates.md)을 쓰는 것입니다. 계획 파일에는 어떤 작업이 어떤 파일을 다루는지도 같이 적어 두는데, 그래야 여러 에이전트가 동시에 일할 때 서로의 작업을 덮어쓰지 않습니다. 그다음 기초를 놓고, 동시에 돌아가는 에이전트들에게 작업을 나눠 주기 시작합니다. [10:54]
"이 수정을 반영하고 나니, 에이전트 10개가 동시에 각자 다른 부분을 맡아 일했습니다. 그 실행은 거의 2시간 동안 이어졌고, 끝났을 때는 원했던 기능이 전부 제대로 작동하는 데모 앱의 첫 버전을 얻었습니다."
해설자 [10:54]~[11:26]
이 정도 규모로 만든다면, 모델 라우터 스킬과 같이 쓸 수도 있다고 영상은 덧붙입니다. 작업마다 알맞은 모델로 보내 주는 스킬인데, 기계적인 단순 작업은 값싼 모델로, 어려운 부분은 강한 모델로 보내서 한도(limit)에 빨리 부딪히지 않게 해 준다는 것입니다. [11:26]
영상은 마지막으로 이렇게 맺습니다. "여기서 쓴 이 스킬은 여러 번의 테스트와 다듬기를 거쳐 만들어진 것입니다." [11:31]
이 스킬이 실제로 겨냥하는 것은 결국 "AI에게 맡긴 일을 사람이 다시 검토하는 시간"입니다. 에이전트가 다 했다고 말해 놓고 실제로는 절반만 했다면, 그걸 사람이 알아채고 다시 시키고 다시 검토하는 데 드는 시간이 곧 인건비입니다. 게이트가 "명령어로 증명된 것만 완료로 친다"는 규칙을 강제하면, 그 재검토·재작업 시간이 줄어듭니다. 여러 명이 함께 개발 도구나 서비스를 파는 팀이라면, 이건 곧 같은 시간에 더 많은 걸 출하할 수 있다는 뜻이고, 출하 속도가 곧 매출로 이어지는 사업에서는 이게 돈이 되는 지점입니다. 다만 이건 영상이 직접 한 말이 아니라, 정리하며 제가 덧붙인 판단입니다.
영상이 소개한 저장소 Leonxlnx/unlazy를 직접 열어 보니, 영상의 설명과 대부분 그대로 맞았습니다. 특히 숫자로 된 규칙들이 정확히 일치했습니다.
| 영상의 설명 | 저장소 원문(영어)과 대조 |
|---|---|
| 깊이를 안 주면 가장 작은 숫자를 알아서 고른다 | 일치. 저장소 문서는 "사용자가 깊이를 지정하지 않으면, 작업의 자연스러운 구성요소와 맞아떨어지는 가장 작은 N을 고른다"고 그대로 적어 둡니다. |
| 각 조각은 최소 10분어치 작업 | 일치. "10분 이상의 집중된 작업, 결과물 하나, 게이트 파일 하나"라고 정확히 같은 기준이 적혀 있습니다. |
| 3 이하 솔로 모드, 4 이상 오케스트레이션 모드 | 대체로 일치하지만 원문은 기준을 조금 다르게 씁니다. 원문은 "트리 2~3, 한 세션에서 순서대로 처리하는 2~4개 리프"를 솔로 모드로, "트리 4~5, 한 컨텍스트가 감당하기 벅찬 8~16개 리프"를 오케스트레이션 모드로 설명합니다. 즉 원문의 기준은 깊이 숫자 자체보다 리프(최종 작업 조각) 개수에 더 가깝습니다. 영상이 이걸 "깊이 3/4 기준"으로 단순화해서 말한 것으로 보입니다. |
| 게이트 = 체크박스 + 명령어·기대 문구·증거 세 줄 | 일치. 원문의 게이트 형식은 CHECK(실행할 명령) · EXPECT(기대하는 결과) · EVIDENCE(검사 결과, 초기값 pending)로 구성되어 영상의 설명과 그대로 대응합니다. |
| 계획 파일 + 게이트 파일 | 일치. 원문 이름은 각각 PLAN.md, gates.md입니다. 자막에는 "plan.mmd", "gates.m MD file"처럼 깨져서 찍혀 있습니다. |
영상에는 없지만 원문에만 있는 내용도 있습니다.
npx skills add Leonxlnx/unlazy 한 줄을 자동 설치 명령으로 안내합니다. 영상은 "설명글에 링크가 있다"고만 말하고 명령어 자체는 화면으로만 보여줬을 것으로 보입니다(자막에는 안 나옵니다).저장소를 만든 사람의 GitHub 프로필도 확인했습니다. 이름은 Leon Lin(아이디 Leonxlnx)이고, 고정해 둔 저장소 중 taste-skill이라는 것이 있습니다. "AI에게 좋은 취향을 부여해서 뻔하고 성의 없는 결과물이 나오지 않게 막는다"는 설명이 붙어 있고 별이 79,100개가 넘습니다. 영상이 말한 "디자인 취향 스킬"과 같은 것으로 보입니다. 다만 unlazy가 실제로 "GitHub 트렌딩 1위"였는지는 프로필 페이지만으로는 확인할 수 없었습니다 — 부록 B 참고.
| 낱말 | 뜻 | 나온 곳 |
|---|---|---|
| AI 에이전트 | 파일을 읽고 고치고 명령을 실행하며 스스로 작업을 진행하는 AI | 0장 |
| 컨텍스트 · 컨텍스트 윈도우 | AI가 지금 한 번에 붙잡고 있는 내용 전부와 그 최대 크기 | 0장, 2장 |
| 서브 에이전트 | 메인 대화와 별도 컨텍스트로 도는 작은 AI 일꾼. 여러 개를 동시에 돌리면 병렬 처리가 됨 | 0장, 4장, 8장 |
| 스킬 | 에이전트에 새 작업 방식을 통째로 얹어 주는 확장 기능 | 0장 |
| 트리(tree) · 깊이(depth) | 작업을 반복해서 잘게 쪼개는 구조와, 몇 번 쪼갤지를 정하는 숫자 | 4장 |
| 솔로 모드 / 오케스트레이션 모드 | 깊이 3 이하로 한 세션에서 처리 / 깊이 4 이상으로 여러 서브 에이전트에 나눠 처리 | 4장 |
| 게이트(gate) | 체크박스 하나 + 증명 명령어·기대 문구·증거 세 줄로 이루어진 완료 조건 하나 | 5장 |
| 원장(ledger) · 게이트 파일 | 게이트를 전부 모아 놓은 체크리스트 파일 | 1장, 5장 |
| 계획 파일(PLAN.md) | 전체 작업 배분과 어떤 작업이 어떤 파일을 다루는지 적어 둔 파일(오케스트레이션 모드) | 4장, 8장 |
| 모델 라우터 스킬 | 작업마다 알맞은 값의 모델로 자동 배분해 주는 별도 스킬 | 8장 |
이 영상은 원어가 영어이고, 받아 둔 자막은 유튜브 원어 자막(en-orig) 하나뿐입니다. 30초 묶음 22개, 13,963자로 영상 길이(11분 31초) 중 11분 26초 지점까지 채웁니다 — 사실상 끝까지입니다. 다른 언어 자막은 받아 두지 않았으므로 비교할 대상이 없었고, en-orig 하나로 충분히 채워졌으므로 그대로 썼습니다. 폴더 이름의 "[한영자막]"은 업로더가 영상 화면 안에 직접 넣은 자막을 가리키는 것으로 보이며, 이것과는 별개입니다.
| 자막에 찍힌 것 | 실제로 추정되는 것 | 확인 방법 |
|---|---|---|
| "aents" 폴더 | agents 폴더의 오기. 자동 자막이 'g'를 빠뜨린 것으로 보입니다 | 문맥 · 저장소 구조와 대조 |
| "theclaw one" | "the .claude one"(그 .claude 폴더)의 오기로 추정 | 문맥 |
| "codeex" | Codex의 오기. 문서 전체에서 일관되게 이렇게 찍혀 있습니다 | 문맥 · 저장소에서 확인 |
| "plan.m MD file", "plan.mmd" | PLAN.md 파일. 저장소 원문에서 정확한 이름을 확인했습니다 | 저장소 대조로 확인됨 |
| "gates.m MD file" | gates.md 파일. 위와 같은 방식으로 깨진 것으로 보입니다 | 저장소 대조로 확인됨 |
| "GPT 5.6" | 실제 모델 이름이 이것인지 확인하지 못했습니다. 자막에 들린 대로 찍힌 것일 수 있습니다 | 확인 못 함 |
_정보.tsv)에는 채널명이 "Tech Bridge"라고 되어 있습니다. 그런데 영상 안에서 해설자 본인은 [00:32] "저희는 소프트웨어 회사고, 여기는 AI Labs입니다"라고 말합니다. 둘 중 무엇이 실제 채널명인지, 혹은 "Tech Bridge"가 이 채널을 운영하는 별도의 회사·다른 채널명인지 이번 확인으로는 가리지 못했습니다. 유튜브 페이지를 직접 여는 방식으로는 채널명이 동적으로 로드되어 이번 조사로 확인이 안 됐습니다.반대로 영상이 정확했던 부분도 적어 둡니다. 게이트의 3줄 구조(명령·기대 문구·증거), 10분 최소 작업 단위, 깊이를 안 주면 가장 작은 수를 고르는 규칙, 계획 파일과 게이트 파일을 함께 쓴다는 것, agents 폴더가 본체이고 .claude는 바로가기라는 것, 저자가 만든 다른 인기 스킬(디자인 취향 스킬 = taste-skill)이 있다는 것 — 이 여섯은 저장소 원문과 그대로 맞습니다.