Transcript
00:00:00요즘 새로운 용어가 유행하고 있는데, 이미 들어보셨을지도 모르겠네요.
00:00:04바로 '루프 엔지니어링'이라는 건데요. 다른 과장된 용어들처럼 다들 대단한 신기술인 것처럼 말하지만
00:00:09사실 그렇지 않습니다. 하지만 Hermes처럼 항상 실행되는 에이전트와 결합하면 이야기가 달라집니다.
00:00:13대부분 이걸 설정하려는 사람들은 루프를 구현하는 데는 성공하지만 정작 중요한 핵심을
00:00:17놓치고 있습니다. 두 가지 루프 유형이 있다는 건 이미 아실 텐데, 그중 하나에만 들어가는
00:00:22특수한 설정이 있는데 아무도 그걸 하지 않거든요. 이걸 알게 되면 에이전트 구축 방식에 대한
00:00:27생각이 완전히 바뀔 겁니다. 이번 영상이 끝날 때쯤이면 그게 정확히 뭔지 이해하고,
00:00:31여러분이 직접 개입할 필요 없이 Hermes와 Claude Code에서 바로 돌아가게 될 겁니다. 루프 엔지니어링의
00:00:36핵심 아이디어는 간단합니다. 에이전트를 구동하는 프롬프트를 작성하는 사람이 되는 것을 멈추고,
00:00:41대신 에이전트가 스스로 움직이게 두는 것입니다. 하지만 왜 이것이 패러다임의 전환인지 이해하려면
00:00:46이전과 비교해 봐야 합니다. 예전에는 프롬프트 엔지니어링이 중요했습니다. 코딩 에이전트를
00:00:51올바르게 구동하기 위해 적절한 일련의 지시사항을 작성하는 데 온 집중을 쏟았죠. 하지만 루프 엔지니어링은
00:00:56그걸 뒤집어버립니다. 직접 프롬프트를 작성하는 대신 프롬프트 엔지니어링을 알아서 수행하고
00:01:01에이전트를 스스로 구동하는 시스템을 설계하는 것이죠. 즉, 지시사항을 만드는 것에서
00:01:05스스로 작동하는 시스템을 설계하는 쪽으로 초점이 이동합니다. 이 모든 것은 OpenClaw의 개발자가
00:01:10더 이상 코딩 에이전트에 프롬프트를 줄 필요가 없으며, 대신 에이전트에게 프롬프트를 자동으로
00:01:15보내주는 루프를 설계하는 데 집중해야 한다고 말하면서 시작되었습니다. 그뿐만이 아닙니다. Claude Code의 개발자인
00:01:20Boris도 Anthropic 연례 개발자 컨퍼런스에서 같은 주장을 했습니다. 그는 이제 Claude에게
00:01:25직접 프롬프트를 주지 않는다고 합니다. 대신 Claude에게 자동으로 프롬프트를 보내고
00:01:30Claude 스스로 무엇을 해야 할지 파악하게 만드는 루프를 돌리고 있죠. 그렇다면 시작하려면 어떻게 해야 할까요? 핵심은
00:01:34에이전트에게 일일이 프롬프트를 줄 필요가 없는 시스템을 얼마나 잘 구축하느냐에 달려 있습니다.
00:01:39필요한 것을 정의하면 에이전트가 나머지를 다 처리하는 것, 그것이 바로 AI 기반 개발이
00:01:45향하고 있는 지점입니다. 실제로 만드는 방법을 알아보기 전에 루프가 무엇인지 명확히 할 필요가 있습니다. 루프란
00:01:50기본적으로 최종 목표를 정의하면 에이전트가 스스로 목표를 달성하기 위한 단계를 파악하는 프로세스입니다.
00:01:56에이전트는 진행 과정에서 스스로 수정하고 문제가 발생하면 우회하며 설정한 목표에 도달합니다.
00:02:01몇 달 전만 해도 모델들이 긴 작업을 수행할 능력이 없었기에 이것은 불가능했습니다. 만약 앱을
00:02:06만들어야 했다면, 여러분이 프롬프트를 입력하고, 에이전트의 작동을 모니터링하고, 직접 결과를 확인하고,
00:02:11오류를 찾아 다시 프롬프트를 입력해 수정해야 했습니다. 여러분 자신이 바로 '루프'였던 거죠. 에러를 체크하고
00:02:16단계마다 수정하는 과정을 맡은 게 바로 여러분이었습니다. 여전히 대부분의 사람들은 이렇게 개발하고 있고,
00:02:20그 과정을 루프 엔지니어링이 대신해 줄 것입니다. 새로운 개념처럼 들릴지 모르지만
00:02:25루프는 사실 이미 오랫동안 존재해 왔습니다. 크론잡(Cron jobs)이
00:02:30이미 보셨을 법한 좋은 예시입니다. 매번 트리거하지 않아도 정해진 시간에 반복적으로
00:02:35자동 실행되도록 예약된 작업일 뿐이니까요. 진짜 차이점은 크론잡은 정해진 시간에만 실행된다는 점이죠.
00:02:39루프를 도입하면 더 이상 프롬프트를 작성하는 것에 매달릴 필요가 없습니다.
00:02:44에이전트의 작업 성능은 최종 목표를 얼마나 잘 정의하느냐에 달려 있게 됩니다. 어떤 분들에게는
00:02:49이 과정이 강화학습과 비슷하게 들릴 겁니다. 혹시 강화학습을 잘 모르시는 분들을 위해 설명하자면,
00:02:54강화학습은 모델에게 정답을 알려주지 않고 훈련하는 방법입니다. 대신 모델이
00:02:59잘했을 때와 못했을 때만 알려주면, 점점 스스로 개선하는 방법을 찾아내는 것이죠.
00:03:04모델은 여러 가지를 시도하며 올바른 경로를 찾습니다. 옳은 방향으로 갈 때는 긍정적인 신호를 받고,
00:03:09아닐 때는 부정적인 신호를 받는 식입니다. 여기에서도 똑같은 원리가 적용되는데 모델 자체가
00:03:14훈련되는 것이 아니라, 에이전트가 완료하려는 작업에 집중하고,
00:03:19마치 모델이 훈련 중에 개선되는 것과 같은 방식으로 작업을 반복하는 것입니다. 만약 실패하면 에이전트에게
00:03:23적용된 루프가 작업을 완료 처리하지 않습니다. 다시 시도하고, 계속해서 목표를 달성할 때까지
00:03:28스스로 수정하며 나아가는 것이죠. 자, 모든 것이 자동화된다면 여러분이 할 일은 대체 무엇인지 궁금하실 수도 있습니다.
00:03:33하지만 여러분의 역할은 줄어드는 것이 아니라 훨씬 더 중요해집니다.
00:03:38최종 목표를 정의하는 것은 바로 여러분의 도메인 지식과 경험이기 때문이며,
00:03:43그 결과물이 여러분이 만들고 출시하는 모든 것에 드러나게 됩니다. 자율형 루프에 대한 추진력이 가속화되고
00:03:48지금 나오는 모든 새로운 기능에서 나타나는 이유가 바로 이것입니다. Fable 5가 가장
00:03:54대표적인 예입니다. Anthropic은 AI 개발 속도를 늦춰야 한다고 주장했음에도 이 모델을 내놓았는데,
00:03:59모델들의 성능이 따라잡기 힘들 정도로 빠르게 향상되고 있기 때문입니다. 그리고 한동안 출시했다가
00:04:03결국 내렸죠. 이 모델은 길고 복잡한 작업을 위해 만들어졌는데,
00:04:08작업이 길고 복잡할수록 더 잘 작동합니다. 모델이 과거에 작동하던 방식과는 완전히 반대죠.
00:04:13이러한 변화는 Opus 4.5부터 본격적으로 시작되었습니다. 모델이 등장한 이후 장기 실행 작업은
00:04:19극적으로 향상되었습니다. 더 이상 에이전트에게 꼼꼼하게 설계된 가이드라인을 제공할 필요가 없어진 거죠.
00:04:23구조화된 설정으로 단계를 안내하는 방식 대신,
00:04:28이제 모델들이 단계별 안내 없이 스스로 작업할 수 있는 능력이 충분해졌기 때문에 프로젝트를
00:04:33장기적인 관점에서 구동할 수 있도록 준비하는 데 초점이 맞춰졌습니다. 하지만 루프만 중요한 것은 아닙니다.
00:04:38에이전트가 개입 없이 스스로 오래 작업할 수 있도록 프로젝트를 구조화해야 합니다.
00:04:43그래서 많은 사람이 이런 유형의 설정을 위한 시스템을 만들고 오픈소스로 공개하고 있습니다.
00:04:48RALF 루프가 그중 하나였습니다. 최종 목표를 설정하고 에이전트가 그 목표에서 벗어나지 않도록 함으로써 작동했습니다.
00:04:53후크(hooks)를 통해 작동했는데, 특정 상황이 발생할 때 자동으로 실행되는 스크립트라고 보시면 됩니다.
00:04:57즉, 이 스크립트는 에이전트가 조건을 충족하지 않은 상태에서 작업 완료 처리를 하지 못하도록 엄격히 제한합니다.
00:05:03하지만 후크는 너무 경직되어 있어서, Claude는 더 유연한 자체 목표 명령어(goal command)를 도입했습니다.
00:05:09하드 코딩된 체크 방식 대신, 다른 모델이 작업 완료 여부를 결정하도록 하는 방식이죠.
00:05:14저희가 다뤘던 Goal Buddy 2는 여기에서 더 나아가, 에이전트가 로컬 파일에서 진행 상황을 추적하고
00:05:19작업 시작 전에 '완료'란 무엇인지 정확히 정의하게 해서 항상 목표를 잊지 않도록 했습니다.
00:05:24Hermes 에이전트와 OpenClaw 모두 같은 철학을 바탕으로 만들어졌습니다.
00:05:29이들은 여러분을 완전히 배제하고 에이전트가 모든 것을 스스로 처리하도록 합니다.
00:05:35자, 이런 루프를 구축하고 싶다면 간단한 5단계 시스템이 있습니다. 루프에는 두 가지 유형이 있기 때문에
00:05:40단계가 약간 다르게 작동할 수 있지만, 나중에 두 가지 유형 모두 다뤄보겠습니다.
00:05:45지금은 Claude Code에서 시작해 보고, 나중에 영상 후반부에서 Hermes 에이전트로 동일한 작업을
00:05:49하는 방법을 살펴보겠습니다. 첫 번째 단계는 프로젝트의 상태를 확인하는 것입니다. 그 상태를 바탕으로,
00:05:54모델이 다음 행동을 결정합니다. 그리고 그 결정에 따라 행동하는 것이죠. 여기가 실제 작업이
00:05:59일어나는 곳입니다. 에이전트는 도구를 호출하고, 파일에 쓰고, 명령어를 실행하여 작업을 완료합니다. 일단
00:06:04완료되면, 에이전트는 피드백을 수집하여 무슨 일이 일어났는지 확인하고,
00:06:09이를 토대로 작업이 완료되었는지 여부를 결정합니다. 여기가 바로 프롬프트 엔지니어링과 루프 엔지니어링의 차이가
00:06:14극명하게 드러나는 지점입니다. 프롬프트 엔지니어링에서는 여러분이 '결정' 단계만 제어하지만, 루프 엔지니어링은
00:06:19이 5단계를 모두 처리합니다. 잘 작동하는 루프를 구축하려면 몇 가지 요소를 제대로 갖춰야 하며,
00:06:24각 요소는 해결해야 할 특정 문제 때문에 존재합니다. 첫 번째는 문맥 관리(Context Management)입니다.
00:06:29에이전트가 어떤 시점에 무엇을 알고 있는지를 결정하는 것이 매 턴마다 입력되는 내용이기 때문에,
00:06:34대화 문맥만 의존해서는 안 됩니다. 100만 토큰이나 되는 거대한 문맥 창을 가진 모델이라 해도,
00:06:39기본적으로 에이전트가 메모리에 한 번에 담을 수 있는 양은 한정되어 있기 때문입니다. 대화가 길어지면,
00:06:44시스템 프롬프트와 지시사항들이 최근 도구 출력값들에 파묻히게 됩니다. 에이전트의
00:06:50주의력은 자연스럽게 가장 최근의 정보로 쏠리기 때문에 중요한 내용은 잊혀집니다. 그래서
00:06:55문맥 관리가 매우 중요한 것입니다. 그다음 제대로 해야 할 것은 피드백의 품질입니다. 피드백은
00:07:00에이전트에게 성과를 알려주는 시스템 전체에서 가장 중요한 신호 중 하나입니다.
00:07:05테스트 결과나 UI의 스크린샷 등 다양한 형태를 가질 수 있고, 그 형태가 무엇이든,
00:07:11에이전트는 그것을 읽고 다음 행동을 결정합니다. 검증 게이트(Verification Gates)는 피드백을
00:07:16명확한 결과로 바꿔주는 역할을 합니다. 작업이 실제로 완료되었는지 알려주는 검문소죠.
00:07:21또한 루프를 언제 멈춰야 할지 알려주는 규칙인 종료 조건(Termination Condition)이 필요합니다.
00:07:26이것을 명확히 설정하지 않으면 에이전트가 너무 일찍 종료하거나 실질적인 진전 없이
00:07:31계속 루프를 돌게 됩니다. 가장 자주 간과되는 것은 오류 처리입니다.
00:07:36도구 호출이 실패했을 때 모델이 어떻게 해야 할지 명시해야 시스템이 문제를 깔끔하게 해결하며,
00:07:41더 큰 문제를 야기하는 고장 난 상태로 방치되지 않게 합니다. 마지막으로, 턴 전반에 걸쳐 상태를 관리해야 합니다.
00:07:46대화가 길어짐에 따라 작업의 진척 상황을 추적해야 합니다. 문맥 창은
00:07:51영원히 모든 것을 기억할 수 없기에, 외부 파일을 활용해 에이전트를 위한 정보를 추적하고
00:07:57흐름을 잃지 않고 작업을 계속할 수 있게 해야 합니다. 다만 한 가지 유의할 점은, 직접 경로를 정하는 대신
00:08:01모델에 그 작업을 넘기기 때문에 루프는 토큰 비용이 많이 들 수 있다는 것입니다.
00:08:06그러니 어떤 작업을 루프에 맡길지 신중해야 합니다. 루프가 더 많은 토큰으로
00:08:11작업할수록 일반적으로 더 복잡한 작업을 잘 처리합니다. 계속하기 전에,
00:08:15이번 영상의 스폰서인 Scrimba를 소개해 드립니다. 대부분의 파이썬 강의는 슬라이드를 읽어주는 지루한 방식이죠. Scrimba는 다릅니다.
00:08:21영상 플레이어 자체가 코드 에디터라서 언제든 멈추고 강사의 코드를 직접 수정해 보며
00:08:26무슨 일이 일어나는지 확인할 수 있습니다. 탭 전환이나 복사 붙여넣기 없이, 처음부터 바로 실습 코딩을 할 수 있죠.
00:08:31새로 나온 파이썬 학습 과정이 눈길을 끄는 이유는, 무작위 예제 대신 실제로
00:08:37무언가를 만들기 때문입니다. 첫날부터 바로 작동하는 비용 분담 앱인 'PayUp'을 만드는 과정을 따라가며
00:08:42각 개념을 즉시 적용해 볼 수 있습니다. 파이썬 지식이 전혀 없는 완전 초보도 가능하며,
00:08:47변수, 문자열, 사용자 입력, 산술 연산자, 타입 변환,
00:08:53데이터 정제, 숫자 서식 지정까지, 앱 기능을 구현하며 배우게 됩니다. 과정을 마치면
00:08:57직접 만든 프로젝트가 여러분이 파이썬을 실제로 안다는 것을 증명해 줍니다. 이번 강의는
00:09:02앞으로 몇 주간 공개될 시리즈 중 첫 번째 부분이며, 현재는 완전히 무료로
00:09:07학습할 수 있습니다. 무료 강의로 지금 바로 시작해 보세요. 저희 채널 이용자들은 프로 플랜을
00:09:1220% 추가 할인받으실 수 있습니다. 고정 댓글의 링크를 클릭하거나 QR 코드를 스캔해서 지금 바로 빌드해 보세요.
00:09:18앞서 말씀드렸듯이 루프에는 두 가지 유형이 있습니다. 첫 번째는 확정적 루프(deterministic loop)입니다. 사용은
00:09:23테스트 통과, 코드 성공적인 컴파일 등 '완료'라는 명확한 정의가 있는 작업에 사용합니다.
00:09:28이런 루프는 최종 목표가 분명하기 때문에 진행하기가 상당히 쉽습니다.
00:09:33모델이 작업을 완료 처리하기 전에 무엇을 해야 할지 정확히 알고 있거든요. Hermes는 항상 실행되고 있기 때문에
00:09:38이 루프를 구현하기에 정말 좋은 에이전트입니다. 저희는 이전에 여러 워크플로우를 만들었고,
00:09:43지난 영상에서 Hermes가 얼마나 많은 저희 작업을 스스로 처리하는지 보여드린 적이 있죠.
00:09:49확정적 루프의 핵심은 최종 목표에 대한 명확한 정의이고, 여러분이 호스팅한 앱의 경우
00:09:54그 정의가 바로 테스트 케이스입니다. 따라서 여러분은 Hermes 에이전트를 테스트 케이스가 있는
00:09:59어떤 앱에나 연결해서 모니터링하게 할 수 있습니다. 만약 변경 사항이나 커밋이 프로덕션 환경을
00:10:04고장 냈다면, Hermes에 자동화를 설정해 이를 잡아낼 수 있습니다. 이 방식이 여기서 가장 잘 작동하는 이유는
00:10:09워크플로우를 기반으로 스킬을 자동으로 생성하고 진화시키는 '자기 진화형 스킬(self-evolving skills)' 기능이 있기 때문입니다.
00:10:14앱의 상태를 계속 확인해 주죠. 그런 모니터링 자동화를 설정한 후에는,
00:10:18Claude Code를 비대화형 모드로 실행하도록 요청할 수 있습니다. 즉, 여러분이 직접 조종할 필요 없이 스스로 실행하며,
00:10:23모든 테스트 케이스가 통과할 때까지 루프 안에서 문제를 해결하게 만드는 것이죠. 거기서부터 에이전트는
00:10:28자동화 워크플로우를 설정하고, 서브 에이전트 기반 개발 스킬과
00:10:34GitHub PR 워크플로우 스킬처럼 GitHub에서 앱을 관리하는 법을 알려주는 스킬들을 로드합니다. 먼저
00:10:39프로덕션을 고장 낸 문제들을 식별한 다음, Claude Code를 비대화형 모드로 실행하여
00:10:44테스트를 통과시키고 모든 테스트가 통과되면 변경 사항을 커밋합니다. 모든 테스트를 실행하고
00:10:50프로덕션 실패의 원인을 해결한 후에는, GitHub CLI를 사용하여 변경 사항을 커밋합니다.
00:10:55성공적인 배포를 위한 모든 체크 항목이 완료되었음을 확인했기 때문에 앱은 오류 없이 실행되게 됩니다.
00:11:00이런 분석이 마음에 드신다면 구독하고, 알림 설정을 켜고, 하이프(hype) 버튼도 눌러주세요.
00:11:05이 채널에서는 다양한 비즈니스 프로세스를 AI로 최적화하는 새로운 방법을 배울 수 있는 콘텐츠를 게시합니다.
00:11:10구독, 알림 설정, 하이프 버튼 등 여러분의 성원은 저희가 더 많은 콘텐츠를 제작하여
00:11:15더 많은 사람들에게 다가갈 수 있게 해줍니다. 저희에게 정말 큰 힘이 됩니다.
00:11:21두 번째 유형은 비확정적 루프(non-deterministic loop)입니다. 확정적 루프처럼 작업 완료 여부를
00:11:26확인할 명확한 규칙을 세울 수 없는 작업들이죠. 그렇기 때문에,
00:11:31결과를 검증할 깔끔한 방법이 없습니다. 인간인 우리가 직접 보고
00:11:36판단해야 하는 UI 구축이나 판단이 필요한 기능 구현 같은 것들 말이죠.
00:11:41비확정적 루프 작업 시에는 워크플로우가 다릅니다. AI를 UI에 적용해 보셨다면,
00:11:46항상 똑같은 패턴으로 회귀하는 경향이 있다는 것을 이미 아실 겁니다. 그래서
00:11:51AI가 만든 조잡한 결과물, 즉 'AI 슬롭(AI slop)'을 방지하는 지시사항과 그 특징들을 정리한
00:11:57'AI 슬롭 탐지기(AI Slop Detector)'라는 스킬을 만들었습니다. Hermes를 다시 사용하는 이유는
00:12:02자기 진화형 스킬 때문입니다. 이 스킬을 실행한 후에도 UI에서 AI 슬롭이 발견되면, 스킬이 스스로 업데이트되어
00:12:07피드백을 직접 반영할 수 있는데, 바로 그 이유 때문에 Hermes에서 이 워크플로우를 설정한 것입니다. Hermes에게
00:12:13이 스킬을 사용해 UI에 그런 패턴이 있는지 확인하라고 했습니다. 패턴이 발견되면 수정하고,
00:12:18Claude Code를 비대화형 모드로 실행하여 스킬을 돌리고, 문제가 없을 때까지 계속 수정하도록 하는 거죠.
00:12:23Hermes를 사용해서 얻는 또 다른 이점은 작업을 만드는 모델과 리뷰하는 모델이 다르다는 점입니다.
00:12:28코드 리뷰에 가장 뛰어난 것으로 알려진 GPT 모델들을 사용했고, Claude 모델이 '빌더' 역할을,
00:12:33다른 에이전트가 '검증자' 역할을 했습니다. 이것이 서로의 작업을 체크하는 대립형 루프(adversarial loop)를 완성합니다.
00:12:38이 루프가 실행되자, 요즘 Opus 모델들이 내놓는 일반적인 결과물보다 훨씬 나은 UI가 만들어졌습니다.
00:12:43만약 에이전트 루프가 끝난 뒤에도 UI에서 AI 슬롭의 흔적을 발견한다면,
00:12:49그냥 언급만 하세요. 에이전트가 알아서 스킬을 업데이트해 주고,
00:12:54이미 갖춰진 검증 기능을 더 강화해 줄 겁니다. 저희는 이 스킬을 저희와 Hermes가 함께 식별한
00:12:59다양한 AI 슬롭 패턴을 걸러내도록 강화했습니다. 이 스킬을 사용하고 싶으시다면 저희 커뮤니티인
00:13:04AI Labs Pro에서 구하실 수 있습니다. 링크는 설명란에 있습니다. 영상이 끝났습니다.
00:13:09채널을 지원하고 이런 영상을 계속 만드는 데 도움을 주고 싶으시다면 아래의
00:13:14슈퍼 땡스(Super Thanks) 버튼을 눌러주세요. 시청해 주셔서 감사드리고, 다음 영상에서 뵙겠습니다.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video