스크립트
00:00:00Claude Code, Codex를 비롯해 여러분이 사용하는 거의 모든 에이전트에는 치명적인 문제가 하나 있으며, 실제 의사결정이 필요한 순간 바로 이에 부딪히게 됩니다.
00:00:08이 모델들은 문제를 깊이 고민할 수는 있지만, 결코 새로운 아이디어를 제시하지는 못합니다.
00:00:12어떤 모델을 사용하든 마찬가지입니다. 창의성이 필요한 순간에는 모두 한계에 부딪히죠.
00:00:17그래서 이들에게 아이디어를 요청하면 안전하고 뻔한 답변만 돌아오고, 결국 스스로 찾아냈어야 할 관점들을 계속해서 직접 제시해 줘야 합니다.
00:00:24새로운 관점을 직접 쥐어주기 전까지는 전혀 창의적으로 생각하지 못하는 것이죠.
00:00:28하지만 기이하게도, 이에 대한 해결책은 바로 주의력이 한곳에 머물지 못하고 산만하게 퍼지는 'ADHD'에 있습니다.
00:00:35알고 보면 ADHD는 AI 에이전트에게 강력한 슈퍼파워가 되며, 이것이 바로 우리가 에이전트에 부여하려는 기능입니다.
00:00:41요즘 정확히 이 역할을 해주는 툴이 트렌드로 떠오르고 있습니다.
00:00:44처음 오신 분들을 위해 소개하자면, 저희는 소프트웨어 기업이며 이 채널은 저희가 직접 워크플로우를 최적화한 것처럼 여러분의 프로세스를 AI로 최적화하는 방법을 공유하는 AI Labs입니다.
00:00:54이번 영상에서는 에이전트에게 ADHD 성향을 부여하는 것이 실제로 어떻게 도움이 되는지 살펴보겠습니다.
00:00:59툴을 살펴보기 전에, 우선 왜 이 툴이 필요한지부터 이해하셔야 합니다.
00:01:03Claude Code, Codex 또는 다른 에이전트를 사용해 보셨다면, 이들이 대형 작업들을 작은 단위로 잘게 나누는 데 뛰어남을 알고 계실 겁니다.
00:01:10메인 세션 용량을 채우지 않도록 작업 조각들을 하위 에이전트에 넘겨 각각의 컨텍스트 윈도우에서 처리하게 하죠.
00:01:16따로 요청하지 않아도 알아서 진행합니다.
00:01:18할 일을 만들고 작업들을 효율적으로 위임해 병렬로 작업을 수행하죠.
00:01:22하지만 이러한 작업 분할은 단지 단순 '실행' 단계에서만 일어납니다.
00:01:26아이디어를 도출할 때는 전혀 분할이 이뤄지지 않으며, 에이전트와 다양한 관점의 브레인스토밍을 시도해 본 분이라면 이 답답함을 이미 경험하셨을 겁니다.
00:01:34여러 변형안을 요구해도 말만 다르게 다듬었을 뿐, 결국 근본적으로는 똑같은 아이디어만 되돌아옵니다.
00:01:40따라서 완전히 새로운 방향을 발굴하는 것은 에이전트가 가장 못하는 영역이기에, 아이디어 도출을 맡기는 것이 가장 어렵습니다.
00:01:47이는 근본적으로 이 모델들이 학습된 방식 때문입니다.
00:01:50에이전트는 학습 데이터에서 가장 자주 나타난 패턴을 선택하는데, 같은 답변이 반복되는 것을 보며 그것이 정답이라고 학습했기 때문입니다.
00:01:59그렇다고 답변이 틀린 것은 아니고 보통 무난한 결과물이 나오지만, 고려조차 하지 않는 다른 각도들이 존재해 브레인스토밍의 취지 자체가 무색해집니다.
00:02:08안전한 패턴을 고수하는 것도 문제지만, 각 아이디어를 독립적으로 평가하지 못한다는 점도 큰 문제입니다.
00:02:13모든 가능성이 동일한 컨텍스트 윈도우 내에서 처리되다 보니, 아이디어들이 서로 섞이고 컨텍스트는 노이즈로 차게 됩니다.
00:02:20생각이 발전하기는커녕 악화되어 무엇 하나 명확히 평가하지 못하고, 결국 표현만 바꾼 동일한 아이디어만 내놓게 되는 것이죠.
00:02:28최근 공개된 'ADHD 스킬'은 며칠 만에 수많은 GitHub 스타를 받으며 주목을 받았습니다.
00:02:33실제 ADHD처럼 생각들이 사방으로 흩어지듯, 사고를 한 줄로 이어가는 대신 사방으로 분산시키기 때문에 아주 적절한 이름입니다.
00:02:42따라서 아이디어 도출이나 다양한 방향성이 존재하는 과제를 '생각의 나무(Tree of Thought)' 구조를 통해 여러 에이전트에 분산시킵니다.
00:02:49생각의 나무는 나뭇가지가 뻗어나가듯, 여러 하위 에이전트 가지들이 서로 다른 아이디어를 독립적으로 탐구하는 구조입니다.
00:02:58그리고 마지막에 각 가지가 하나의 가능성으로 정리되면, 그 모든 아이디어를 다시 모아 하나의 최종 답변으로 병합합니다.
00:03:06즉, 독자적인 컨텍스트 윈도우에서 사고하는 여러 에이전트를 구동하여, 각 에이전트에 동일한 문제에 대한 서로 다른 프레임을 부여합니다.
00:03:12이들은 완전히 격리되어 컨텍스트를 공유하지 않으며, 서로 무슨 작업을 하는지 전혀 알지 못합니다.
00:03:17그러나 여기서의 격리는 단순한 작업 분할이 아니라, 아이디어들이 서로 영향을 주지 않도록 독립성을 유지하기 위함입니다.
00:03:24독립성을 유지하는 핵심은 '프레임'인데, 이는 문제를 바라보는 서로 다른 관점의 렌즈라고 볼 수 있습니다.
00:03:29내부에 프레임 라이브러리가 있어 에이전트가 나아갈 수 있는 방향들을 담고 있으며, 각 에이전트는 작업할 프레임을 선택합니다.
00:03:37이 프레임 프롬프트는 시스템 프롬프트 및 문제 자체와 함께 제공됩니다.
00:03:41그러고 나면 크리틱(비평) 에이전트가 수집된 결과를 점수화하는데, 어떤 아이디어를 남길지 결정해야 하기 때문입니다.
00:03:48크리틱은 모든 아이디어를 세 가지 기준으로 평가합니다.
00:03:50첫째는 아이디어가 얼마나 참신하고 창의적인지를 나타내는 '참신성(Novelty)'.
00:03:54둘째는 실제로 구현이 가능한지를 평가하는 '실현 가능성(Viability)'.
00:03:57그리고 셋째는 해결하려는 문제에 얼마나 잘 부합하는지 보는 '적합성(Fit)'입니다.
00:04:01이 채점은 '회의적인 시니어 엔지니어' 역할을 수행하도록 지정된 별도의 평가 에이전트에서 진행됩니다.
00:04:07즉, 검토하는 모든 아이디어에 대해 엄격하게 비판하는 것이 이 에이전트의 역할입니다.
00:04:10그리고 이 점수에 기반하여 아이디어를 채택할지 버릴지를 결정합니다.
00:04:15마지막으로 스킬은 가장 우수한 아이디어들을 선정하고, 각 안안을 채택했을 때 발생할 수 있는 '함정 리스트'를 검토합니다.
00:04:23그런 다음 직관적이지 않고 참신하다고 판단된 아이디어에 우선순위를 부여합니다.
00:04:26이 스킬이 유용하게 쓰이는 실제 사례들을 보여드리기에 앞서, 채널 구독과 좋아요를 눌러주시면 감사하겠습니다.
00:04:33이 작은 관심과 응원이 저희에게는 정말 큰 힘이 됩니다.
00:04:36내부 동작 원리는 여기까지 살펴보고,
00:04:38이제 직접 설치해 보겠습니다.
00:04:40해당 프로젝트의 GitHub 저장소에서 설치 명령어를 확인하실 수 있습니다.
00:04:43명령어를 복사하여 작업 중인 프로젝트의 터미널을 열고 실행합니다.
00:04:47어떤 AI 코딩 에이전트에 설치할지 묻는 메시지가 뜨며, 45개 이상의 에이전트를 지원합니다.
00:04:53사용 중인 에이전트를 선택하기만 하면 됩니다.
00:04:55그 후, 현재 프로젝트 내에서만 사용할지(프로젝트 범주) 또는 어떤 프로젝트에 있든 관계없이 어디서나 사용할지 선택하라는 요청이 나옵니다.
00:05:03특정 프로젝트에서만 필요하다면 Project Scope를 선택하시면 됩니다.
00:05:06설치가 완료되면 `.agents`라는 폴더 안에 스킬이 배치됩니다.
00:05:10Codex 등 대다수 에이전트는 이 폴더를 설정을 저장하는 용도로 쓰지만, Claude Code는 기본적으로 `.claude` 폴더만 인식합니다.
00:05:18따라서 Claude Code를 사용 중이라면 해당 폴더명을 `.claude`로 변경해야 정상적으로 인식됩니다.
00:05:22폴더를 열어보면 설치된 스킬을 확인하실 수 있습니다.
00:05:25외부 참조 파일이나 의존성 없이, 단 하나의 `skill.md` 파일이 모든 프로세스를 자체적으로 처리합니다.
00:05:31이 지침 파일은 에이전트가 초기 3개의 답변을 넘어 더 깊이 사고하도록 강하게 유도합니다.
00:05:36파일 내용에는 처음 떠올린 3가지 아이디어가 학습 데이터에서 가장 흔히 발견되는 답변이자,
00:05:41숙련된 에이전트라면 누구나 즉시 도출할 수 있는 뻔한 결과물이라고 명시되어 있습니다.
00:05:44숙련된 에이전트가 발휘할 수 있는 진가와 흥미로운 아이디어는 그 3가지를 넘어선 이후에야 비로소 나오기 시작합니다.
00:05:50하지만 이렇게 수많은 에이전트를 구동하면 토큰 소모가 극심하므로,
00:05:52이 스킬을 실제로 실행할지 여부를 결정하는 사 전 검증(pre-check) 단계가 존재합니다.
00:05:56슬래시(/) 명령어나 직접 요청으로 스킬을 호출하면 즉시 동작합니다.
00:06:01만약 프롬프트에서 스킬을 직접 명시하지 않았는데
00:06:04에이전트가 자율적으로 스킬을 호출하겠다고 판단한 경우,
00:06:07사전 검증 단계의 3가지 질문을 통해 주어진 문제를 검증합니다.
00:06:11첫 번째 질문은 문제가 개방형(open-ended)인지 여부입니다.
00:06:14즉, 전문가 관점에서 여러 유효한 해법이 존재하는 문제인지,
00:06:19아니면 명확한 단 하나의 정답만 존재하는지 판단합니다.
00:06:20정답이 하나뿐인 문제라면
00:06:22다각도로 생각하는 것은 무의미하며 토큰만 낭비하게 되므로,
00:06:26이 단계에서 실행을 중단합니다.
00:06:27두 번째 기준은 사안의 중요도(stakes)가 실제로 높은지 여부로,
00:06:29뻔한 답을 택했다가 오답으로 판명되었을 때 상당한 손실이 발생하는지 평가합니다.
00:06:34세 번째 기준은 요청의 형태입니다.
00:06:36'빠르게' 혹은 '표준적인'과 같은 단어를 사용하셨다면
00:06:38직관적이고 간단한 답변을 원하시는 것이 분명하므로,
00:06:40스킬을 실행하지 않고 여기서 동작을 멈춥니다.
00:06:43이 사전 검증 단계 외에도,
00:06:44전체 루프 단계와 함께 각 에이전트에 전달될 방향성이 되는 프레임 테이블이 정의되어 있습니다.
00:06:50또한 에이전트가 명시적으로 회피해야 할 금지 패턴 목록도 명시되어 있습니다.
00:06:54실제 활용 사례를 살펴보기 전에, 스폰서 소식을 전해드립니다.
00:06:59바로 Top View입니다.
00:06:59AI 영상을 제작해 보셨다면 그 번거로움을 이미 아실 겁니다.
00:07:02모델마다 서로 다른 플랫폼에 흩어져 있어 클립을 하나씩 따로 생성해야 했죠.
00:07:05Top View가 이를 해결해 줍니다.
00:07:06코딩 에이전트 내부에서 동작하는 세계 최초의 올인원 AI 비디오 스킬입니다.
00:07:11Claude Code, Cursor, Codex 등에서 사용할 수 있죠.
00:07:13최상위 모델들을 한곳으로 통합했습니다.
00:07:16VEO, Kling, Seaweed, Wan 2.1 등을 모두 지원합니다.
00:07:19플랫폼을 전환하거나 여러 구독을 관리할 필요가 없습니다.
00:07:22저희가 직접 테스트해 봤습니다.
00:07:23에이전트에 단 하나의 명령을 내렸죠.
00:07:25“이 제품 이미지로 15초짜리 틱톡 광고 변형안 10개를 생성해 줘.”
00:07:29몇 초 만에 게시 가능한 광고 10개가 완성되었습니다.
00:07:32이것이 진정한 패러다임의 전환입니다.
00:07:34Top View는 에이전트를 비디오 생산 공장으로 만들어 줍니다.
00:07:36원하는 바를 한 번만 설명하면 한 세션 내에서 다양한 모델, 스타일, 화면비의 영상 수십 개를 일괄 생성합니다.
00:07:44작업에 적합한 최선의 모델도 자동으로 선택해 줍니다.
00:07:47에이전트를 이탈할 필요 없이, 텍스트 한 줄로 완성된 비디오들을 얻을 수 있습니다.
00:07:51영상 설명란의 링크를 통해 Top View 스킬을 체험해 보세요.
00:07:54설정 설명은 여기까지입니다.
00:07:54이제 이 스킬이 실제로 유용하게 활용되는 분야를 알아보겠습니다.
00:07:57탁월한 효과를 발휘하는 대표적인 분야는 에이전트가 테스트를 먼저 작성하도록 하는 테스트 주도 개발(TDD)입니다.
00:08:03이후 작성된 모든 테스트를 통과할 때까지 앱을 단계적으로 구축해 나가죠.
00:08:07이전 영상에서도 언급했듯, 코드 작성 전에 테스트를 먼저 정의하는 것은 매우 중요한데,
00:08:12모든 요구사항이 코드로 엄격히 명시되어 있으면, 시스템을 손상시키는 변경 사항이 테스트에서 즉시 감지되기 때문입니다.
00:08:18에이전트는 이 요구사항들을 준수할 수밖에 없게 되죠.
00:08:20그리고 테스트 작성은 에이전트들이 가장 건성으로 처리하는 영역이기에 이 스킬을 적용하기에 안성맞춤입니다.
00:08:26앞서 말했듯, 뻔한 답변에만 의존하여 지극히 일반적인 케이스에 대해서만 테스트를 작성하고 필요한 예외 케이스들을 놓치기 일쑤입니다.
00:08:33사용자가 앱을 이용하며 거칠 수 있는 다양한 예외 경로들을 제대로 검증하지 못하는 것이죠.
00:08:37테스트 작성법에 대한 상세한 프롬프트를 주거나, 테스트 작성만 전담하는 전문 에이전트를 구축할 수도 있습니다.
00:08:45그럼에도 불구하고 여전히 똑같은 패턴으로 되돌아가곤 합니다.
00:08:47스킬을 실행하기 전, 에이전트는 무엇을 만들지 미리 파악하고 있어야 합니다.
00:08:51이를 위해 개발할 내용, 즉 앱의 기능과 해결하려는 문제, 달성 목적 및 타깃 고객을 정리한 PRD(제품 요구사항 정의서) 문서를 작성해야 합니다.
00:09:03이와 함께 기술 스펙 문서를 제공하여 기술적 세부사항을 확정해 두면, 사용할 툴을 매번 반복해서 지시할 필요가 없어집니다.
00:09:11이 두 문서를 `CLAUDE.md` 파일 내에 링크해 두면 초기 단계부터 컨텍스트를 파악하게 됩니다.
00:09:16그런 다음 슬래시 명령어로 스킬을 호출하고 구축할 앱을 설명하는 프롬프트와 함께 TDD 방식으로 테스트 케이스를 작성하도록 요청합니다.
00:09:25명시적으로 스킬을 호출했기 때문에 사전 검증을 건너뛰고 즉시 5개의 에이전트를 구동합니다.
00:09:30각 에이전트는 문제에 가장 적합한 프레임을 활용해 각자의 사고 방향으로 나아가며, 서로 다른 테스트 작성 접근법을 도출해 냅니다.
00:09:38이후 앞서 살펴본 기준에 따라 각 안을 평가하여 상위 3개를 선정하고 이를 더욱 심도 있게 탐구합니다.
00:09:44모든 에이전트의 작업이 완료되면, 각 테스트 방향에 대한 점수와 상세한 보고서를 받게 됩니다.
00:09:50점수는 약어로 표기되는데, N9는 참신성 9점, V8은 실현 가능성 8점, F10은 적합성 만점을 의미합니다.
00:10:00각 아이디어에는 구체적인 구현 개요, 리스크 요소, 그리고 시작을 위한 첫 단계가 함께 제공됩니다.
00:10:07도출된 아이디어들은 일반적인 테스트 집합과는 차원이 다릅니다.
00:10:11보통 에이전트가 작성하는 테스트는 앱이 정상 동작하는지만 단순 확인합니다.
00:10:15반면 이 스킬이 제시한 안들은 훨씬 더 많은 엣지 케이스를 추적하고 성능 문제까지 포착해 냅니다.
00:10:21결과적으로 심도 있게 탐구된 3개의 가지로 분할되어 앱의 각기 다른 실행 경로를 검증하는 훨씬 견고한 테스트 수트를 갖추게 됩니다.
00:10:30다만 명심해야 할 점은 이 스킬이 테스트 전략을 '기획'할 뿐, 코드를 직접 작성하진 않는다는 것입니다.
00:10:34제공받는 것은 전략이므로, 채택할 방향을 지정해 주면 에이전트가 해당 방향의 구현을 진행합니다.
00:10:40단 하나의 방향만 선택할 수도 있고, 3가지 방향을 모두 구현하도록 지시할 수도 있습니다.
00:10:44성능이 핵심인 시스템이라면 3가지 모두 구현하는 것이 좋지만, 에이전트가 순차적으로 처리해야 하므로 시간이 다소 걸립니다.
00:10:52하지만 작업이 끝나면 일반적인 방식보다 테스트의 디테일이 훨씬 뛰어남을 명확히 확인하실 수 있습니다.
00:10:57단 하나의 테스트 코드를 작성하기도 전에 전체적인 테스트 전략을 구체적으로 수립했기 때문입니다.
00:11:02따라서 구현 전에 이를 활용하면 대부분의 영역을 사전에 커버하여 추후 앱이 손상될 가능성을 크게 줄여줍니다.
00:11:09여기까지가 빌드 전 활용법입니다.
00:11:11또 다른 활용법은 서비스 배포 바로 직전 단계에 적용하는 것입니다.
00:11:14출시를 앞둔 앱에 이 스킬을 실행하여 사용자 경험(UX)을 평가하도록 요청합니다.
00:11:18그러면 사이트를 탐색하거나 제품을 사용할 때 사용자에게 혼란을 줄 수 있는 요소들을 감지해 내며,
00:11:23이탈(Churn)을 유발할 수 있는 요인, 즉 유저가 서비스를 사용하다가 중단하게 만드는 요인들을 찾아냅니다.
00:11:29실제 유저가 유입되는 라이브 단계에서는 이탈이 빈번히 발생하며, 유료 서비스일수록 더욱 그렇습니다.
00:11:34처음에는 마음에 들어 하다가도 하나의 기능이 예상과 다르게 동작하면 바로 이탈하고
00:11:38환불을 요구하게 됩니다.
00:11:40그리고 많은 경우, 앱을 구축하는 과정에서 간과된 사소한 부분이
00:11:44라이브 버전에 포함되어 향후 큰 문제를 일으키곤 합니다.
00:11:48저희 커뮤니티 웹사이트에서 신규 기능을 출시하는 과정에 이 스킬을 직접 적용해 보았습니다.
00:11:53이미 많은 회원들이 이용 중이므로, 기존 유저의 경험을 저해하는 버그를 배포하지 않으려면
00:11:57새로운 모든 요소를 철저히 점검해야 했습니다.
00:12:01슬래시 명령어로 스킬을 호출해 해당 기능을 전달하고,
00:12:05이탈이 발생할 여지나 부정적 경험을 줄 수 있는 지점을 분석하도록 요청했습니다.
00:12:09스킬은 애플리케이션을 전체적으로 분석하여 컨텍스트를 수집한 뒤,
00:12:12동일한 방식으로 에이전트를 실행하여 약 30개의 다양한 아이디어를 도출해 냈습니다.
00:12:17그중 상위 3개를 선별하여 더 깊이 있게 분석했죠.
00:12:20분석이 끝난 후 참신성, 실현 가능성, 적합성 점수가 포함된 모든 분석 결과가 제공되었습니다.
00:12:25그리고 전혀 감지하지 못했던 결함들을 포착해 냈습니다.
00:12:28PRD에는 명시되었으나 실제로는 구현되지 않은 기능처럼,
00:12:32약속과 일치하지 않는 상태로 배포될 뻔했던 요소와 기타 여러 문제를 찾아냈습니다.
00:12:35기타 다양한 개선사항들도 함께 발견되었죠.
00:12:37발견된 모든 항목에 대해 해결책을 제시하고 수반되는 함정과 리스크를 정리해 주었습니다.
00:12:42작동 방식은 앞서 살펴본 테스트 때와 동일합니다.
00:12:44스킬이 스스로 수정하지 않으므로, 반영하고자 하는 항목을 에이전트에 전달하면
00:12:48에이전트가 알아서 구현해 냅니다.
00:12:50따라서 배포 이후가 아닌 배포 전에 모든 문제에 대응할 수 있게 되며,
00:12:53실제 서비스 공개 시점에 애플리케이션을 훨씬 완성도 높은 상태로 만들 수 있습니다.
00:12:57영상에서 소개해 드리는 모든 스킬, 워크플로우 및 리소스는
00:13:01저희 커뮤니티인 AI Labs Pro에서 이용하실 수 있습니다.
00:13:04저희 콘텐츠가 유용하셨고 채널을 후원하고 싶으시다면,
00:13:07이것이 가장 좋은 방법입니다.
00:13:09링크는 영상 설명란에 있습니다.
00:13:10오늘 준비한 영상은 여기까지입니다.
00:13:12채널을 응원하고 이런 영상을 계속 제작할 수 있도록 힘을 보태주고 싶으시다면,
00:13:16하단의 Super Thanks 버튼을 이용해 주시기 바랍니다.
00:13:18언제나 시청해 주셔서 감사드리며, 다음 영상에서 인사드리겠습니다.