스크립트
00:00:00요즘 다들 에이전트 루프에 대해 많이 이야기하니 아마 한 번쯤 들어보셨을 겁니다.
00:00:05AI 기업들이 단순히 제품 사용료를 더 받으려고
00:00:09토큰을 많이 소모하는 루프를 만든다고 생각하실 수도 있겠네요. 하지만 그건
00:00:13작업에 맞지 않는 루프를 잘못 사용했을 때만 발생하는 일입니다. 저희는 소프트웨어 기업으로서
00:00:18AI 코딩 작업에 루프를 활용하며 실험을 거듭해 왔습니다. 그 과정에서
00:00:23다양한 루프 유형을 분류하고 각각 어떤 사용 사례에 적합한지 파악했습니다. 그래서 저희가
00:00:28설정해 본 루프들 중 실제로 유용했던 것들을 공유하려 합니다. 또한 각 루프를 어떻게
00:00:33설정하고 워크플로우에 어떤 영향을 주는지도 보여드리겠습니다. 루프 유형을 살펴보기 전에
00:00:38처음이신 분들을 위해 루프 엔지니어링이 무엇인지 간략히 짚고 넘어가겠습니다.
00:00:43깊게 다루지는 않겠지만, 자세한 내용이 궁금하시다면 저희 채널의 이전 영상을 확인해 주세요.
00:00:48루프 엔지니어링의 핵심은 사람이 에이전트를 구동하는 프롬프트를 일일이 작성하는 대신,
00:00:53루프 자체를 작성하는 시스템을 만드는 것입니다. 시간 들여서 길고 세심한
00:00:58구조화된 프롬프트를 작성하는 대신, 에이전트가 스스로 모든 것을 처리하게 하는 거죠.
00:01:02에이전트는 진행하며 배우고, 부딪히는 문제로부터 성장하며
00:01:07다음에 무엇을 해야 할지 스스로 판단합니다. 그것이 진정한 에이전트 루프입니다. 지난
00:01:12영상에서 루프를 결과에 따라 결정적 루프와
00:01:18비결정적 루프 두 가지로 나눴습니다. 결정적 루프는 결과물을 미리 알 수 있어서,
00:01:22에이전트가 스스로 결과를 확인하고 목표에 도달할 때까지 작업하는 형태입니다.
00:01:27비결정적 루프는 결과를 알 수 없어서 에이전트가 스스로 결과물을 확인할 수 없으므로
00:01:32다른 방식을 사용해야 합니다. 하지만 이건 아주 넓은 분류였고,
00:01:36설정 방식도 매우 다양합니다. 그에 따라 할 수 있는 일도 달라지죠.
00:01:41가장 먼저 다룰 유형은 아마 많이들 써보셨을 겁니다.
00:01:46모든 루프의 기본이 되는 구성 요소이며, 가장 명확한 예시는 'goal' 명령입니다.
00:01:51우리는 이를 스테이트리스(stateless) 루프라고 부릅니다. 루프가 어떠한 상태를 유지하거나
00:01:56작업하며 스스로 개선되지 않기 때문입니다. 일어난 일로부터 배우고 더 나아지는 과정이 없죠.
00:02:01바로 그 점이 이 루프를 가장 단순하게 만듭니다. 이 유형 중 아마 보셨을 만한 것은
00:02:05ralph 루프입니다. 메모리를 유지하지 않기 때문에 스테이트리스죠. 그저 같은 작업을
00:02:10반복하다가 작업이 완료된 것을 확인하면 멈출 뿐입니다. 'goal' 명령에 대해
00:02:15이미 아시겠지만, 이것이 스테이트리스 루프의 가장 좋은 예입니다. 사용하려면
00:02:19'goal' 명령 뒤에 구축하고 싶은 내용을 적으면 됩니다. Claude가 목표를 설정하고 작업을
00:02:25시작합니다. 메인 에이전트가 작업이 완료되었다고 판단할 때마다 더 작은 모델을 사용해
00:02:30결과물을 확인합니다. Claude Code에서는 이 작은 모델이 Haiku입니다. 에이전트가
00:02:35프롬프트 요구사항에 맞춰 작업했는지 검토하고, 작업이 부족하다면
00:02:38에이전트에게 다시 프롬프트를 보내 마무리를 시킵니다. 하지만 이 루프에는 문제가 있습니다. 에이전트가
00:02:43작업 완료 여부를 전적으로 모델에게 의존하는데, 결과에 대한 측정 기준이 없다는 점입니다.
00:02:48그래서 하드코딩된 구체적인 방식으로 확인할 수 있는 기능에 가장 적합합니다.
00:02:53그 방법 중 하나가 테스트입니다. 지난 영상에서 다뤘듯이, 기능을 만들기 전에
00:02:58테스트를 먼저 작성합니다. 그러면 Claude가 기능 구현을 잘못 변경할 경우,
00:03:03테스트에서 오류가 발생해 Claude에게 구현이 잘못되었다고 알려줍니다. 모든 기능에
00:03:08테스트를 준비하면 에이전트에게 실제 자율성을 부여할 수 있습니다. 다른 기능을 깨뜨리거나
00:03:12원치 않는 방향으로 빌드할 걱정 없이 맡길 수 있죠. 테스트를 작성한 후에는
00:03:17Claude Code에게 모든 테스트를 통과하는 것을 목표로 빌드하라고 지시할 수 있습니다. 에이전트는 계속
00:03:22코드를 작성하고 테스트를 실행해 스스로 확인하며 모든 테스트가 통과될 때까지 반복합니다.
00:03:27모두 통과하면 기능이 올바르게 빌드된 것이며 Claude는 목표를 완료로 표시할 것입니다. 에이전트가
00:03:33스스로 작동하게 하려면, Claude.md 파일에 한 줄을 추가해야 합니다. 그 줄은 에이전트에게
00:03:38앱의 모든 정상 작동 버전을 저장하라고 지시합니다. 그렇게 하면 나중에 앱이 깨지더라도,
00:03:43기억에 의존해 변경 사항을 되돌리려 애쓰지 않고 마지막 정상 버전을 즉시 불러올 수 있습니다.
00:03:47다음 유형으로 넘어가기 전에, 스폰서인 Minimax의 소식을 전해드립니다.
00:03:53Minimax에서 방금 출시한 M3는 코딩, 100만 토큰 컨텍스트, 네이티브 멀티모달리티라는 세 가지 분야에서
00:03:59최고 수준에 도달한 최초의 오픈 웨이트 모델입니다. 저희는 M3 API를 Claude Code에 바로 연동하여
00:04:06한 가지 목표를 주었습니다. '현재 판매 중인 최고의 전기차를 조사해서
00:04:11실시간 비교 대시보드를 구축하라'는 것이었죠. M3는 스스로 해냈습니다. 웹을 브라우징해서 실시간
00:04:17사양과 가격을 가져왔고, 대시보드를 처음부터 구축했습니다. 다양한 EV 브랜드를 검색하고
00:04:22최신 모델을 탐색하면 모든 것이 실시간으로 업데이트됩니다. 자율 브라우징에서 Opus 4.7을 능가하며,
00:04:28100만 토큰 컨텍스트 덕분에 전체 코드베이스를 한 창에 담을 수 있었습니다. 하지만 에이전트 실행은
00:04:34많은 토큰을 소비하는데, 이때 Minimax 토큰 요금제가 해결책이 됩니다. 고정 비용의 토큰 플랜을 선택하거나,
00:04:40유연하게 사용할 수 있는 종량제를 선택하세요. 텍스트, 이미지, 음성, 음악이 동일한 토큰 풀을 공유하며
00:04:46높은 할당량을 제공합니다. 플랜은 월 20달러부터 시작하니 설명란의 첫 번째 링크를 클릭해
00:04:5112% 독점 할인을 받으세요. 방금 살펴본 스테이트리스 루프는 상태를 유지하지 않습니다.
00:04:58과정 중에 스스로 개선되는 것 없이 지침에 따라 스스로 모든 것을 처리합니다. 다음 유형은 정반대로 작동하며,
00:05:03우리는 이를 '러닝(learning) 루프'라고 부릅니다. 러닝 루프는 다르게 작동합니다. 단순히
00:05:08작업을 끝내고 멈추는 스테이트리스 루프나 goal 명령과 달리, 반복적으로 사용하는 기술이나
00:05:13워크플로우를 개선하는 데 집중합니다. 방법은 간단합니다. 기술을 실행하고,
00:05:18수행 방식을 관찰한 다음 배운 점을 바탕으로 개선하며, 모든 교훈을 완벽하게 기록합니다.
00:05:23그래서 기술을 다시 실행할 때 에이전트는 과거의 문제를 알고 있으므로
00:05:28똑같은 문제를 반복하지 않습니다. 이 루프는 많은 곳에 적용할 수 있습니다. 예를 들어,
00:05:33저희 커뮤니티 웹사이트 구축 시 반복되는 워크플로우를 처리하기 위해 여러 기술을 만들었습니다.
00:05:38하지만 기술을 빌드하면 그것이 제대로 작동하는지 어떻게 알 수 있느냐는 당연한 의문이 생깁니다.
00:05:43그에 대한 답으로 우리는 완전한 러닝 루프를 설정했습니다. 루프를 트리거하는
00:05:48'skill loop' 명령을 만든 것이죠. 이 명령에는 기술 개선 에이전트를 호출하고,
00:05:53개선할 점이 없을 때까지 계속 호출하라는 지침이 포함되어 있습니다.
00:05:58이 기술 개선 에이전트는 기술의 품질을 평가하고, 여러 영역에 걸쳐 테스트하며
00:06:03문제를 살피며 기술을 향상시키는 에이전트입니다. 사용법은 간단합니다.
00:06:08명령을 실행하고 개선하고 싶은 기술을 전달하면 작업이 시작됩니다. 이 루프는
00:06:14여러 라운드로 실행됩니다. 각 라운드마다 테스트 세트를 실행하고 변경 사항을 적용한 뒤 확인합니다.
00:06:19그런 다음 전달받은 프롬프트만으로 작업하는 별도의 Claude 세션을 시작하여,
00:06:24권한을 묻지 않고 백그라운드에서 실행하며 결과를 보고합니다. 내부적으로는
00:06:29해당 기술을 사용했을 때와 안 했을 때 두 가지 방식으로 구현을 실행하여,
00:06:34기술의 실제 영향을 측정합니다. 그 비교를 통해 개선이 필요한 부분을 정확히 파악하고
00:06:40직접 변경 사항을 적용합니다. 하지만 가장 중요한 부분은 생성되는 'learning.md' 파일입니다.
00:06:46이 파일은 에이전트가 무엇이 효과적이고 무엇이 그렇지 않은지 알 수 있는 방법을 제공하며 기술 내부에 존재합니다.
00:06:51에이전트가 배운 모든 것을 구조화된 형식으로 문서화하는 개선 저널과 같습니다.
00:06:56시도한 것과 결과를 기술 사용 전후로 나누어 기록하고, 여러 라운드에 걸쳐
00:07:00배운 교훈을 나열합니다. 그렇게 기술이 최상의 버전으로 정교화될 때까지 라운드를
00:07:05반복합니다. 어떤 워크플로우든 같은 설정으로 개선할 수 있습니다.
00:07:09지난 영상에서는 루프를 구축하는 법을 보여드렸는데, 두 에이전트 중 하나는 구현을,
00:07:14다른 하나는 검토하고 구현 에이전트가 적용할 수정 사항을 보고하는 방식이었습니다.
00:07:20여기에는 문제가 하나 있는데, 단일 검토 에이전트가 모든 측면을 혼자 다룬다는 것입니다.
00:07:25검토는 결코 한 가지 측면만이 아닙니다. 항상 다양한 관점에서
00:07:30나오기 때문에 에이전트 하나가 혼자 감당하기에는 너무 많은 영역입니다.
00:07:35여러 에이전트가 여러 차원에 걸쳐 검토하면 단일 에이전트가 놓칠 수 있는 맹점을
00:07:40보완할 수 있으므로 검토가 훨씬 더 완전해집니다.
00:07:46이는 안드레이 카르파티가 공개한 LLM Council과 유사한 개념으로,
00:07:51여러 모델의 추론을 사용하여 주제에 대해 서로 논의하고 올바른 답변에 도달하는 에이전트 위원회입니다.
00:07:56멀티 에이전트 루프를 만들려면 여러 에이전트가 필요합니다. 그래서
00:08:00예를 들어, 저희가 설정한 루프에는 4개의 에이전트가 있습니다. 첫 번째는
00:08:05웹 검색 같은 도구를 사용하여 실제 출처를 바탕으로 사실 여부를 확인합니다.
00:08:10두 번째는 도메인 검사기 에이전트로, 검토 대상이 우리가 하려는 작업과
00:08:15실제로 관련이 있는지 확인합니다. 세 번째는 안전 비평 에이전트로 민감한 콘텐츠,
00:08:20보안 위험, 정책 위반 등 향후 문제가 될 수 있는 요소를 살핍니다.
00:08:25마지막은 스타일 비평으로, 콘텐츠가 명확하고 잘 작성되었으며 의도한 스타일에 맞는지 확인합니다.
00:08:30코딩이든 아니든 모든 작업에 이 에이전트들을 사용할 수 있습니다.
00:08:35이 네 가지를 하나로 묶는 것은 우리가 만든 'orchestrate' 명령입니다. 이 명령에는
00:08:40네 에이전트를 어떻게 관리하고 조정하며 각각의 피드백을 어떻게 처리해야 하는지에 대한
00:08:46상세 지침이 포함되어 있습니다. 루프를 시작하려면 'orchestrate' 명령을 실행하고 원하는
00:08:51내용을 검토하라고 지시하면 프로세스를 위해 모든 에이전트가 가동됩니다.
00:08:56이 명령은 여러 라운드로 실행되며 매 라운드마다 모든 에이전트를 가동합니다.
00:09:01메인 에이전트가 1라운드에서 보고된 수정 사항을 적용한 뒤 다음 라운드를 위해 다시 모든 에이전트를
00:09:06가동합니다. 최종 패스가 끝나면 훨씬 개선된 앱을 얻게 됩니다.
00:09:12에이전트가 직접 통신하게 하려면, 이전 영상에서 다룬 에이전트 팀 워크플로우를 사용할 수 있습니다.
00:09:17하지만 우리는 오케스트레이터를 선택했습니다. 워크플로우를 제대로 조정하려면 에이전트 한 명이 이전 라운드의
00:09:22컨텍스트를 유지해야 하기 때문입니다. 우리가 자주 사용하는 또 다른 유형은
00:09:27'검증 루프'입니다. 이 루프도 멀티 에이전트를 사용하는데, 한 명은 구현을 하고
00:09:33다른 한 명은 구현을 평가하며 구현자의 목표는 특정 지표에 대해 가능한 가장 높은 점수를 받는 것입니다.
00:09:38이를 설정하기 위해 전체 루프를 조정하고 검토 워크플로우를 스스로 실행하는 명령을 만들었습니다.
00:09:43이미 아시겠지만, Cursor에는 'thermonuclear review' 기능이 있습니다. 코드가 얼마나 깨끗하고
00:09:48건강한지 확인하여 나중에 빌드하기 쉽게 해주는 강력한 검토 기술입니다.
00:09:54모든 코드를 감사하고 타협 없는 표준에 따라 심층적인 검토 결과를 반환하므로,
00:09:59최고 품질의 검토를 보장받을 수 있습니다. 이를 위해 동적 워크플로우를 실행합니다.
00:10:04검토는 많은 범주를 포괄해야 하므로 동적 워크플로우가 이를 다루기에 가장 좋습니다.
00:10:09여러 하위 에이전트가 각자 다른 측면을 동시에 맡아 작업을 처리하기 때문입니다.
00:10:15앞서 언급했듯이 이 루프의 플레이어로 두 에이전트를 만들었습니다. 첫 번째는
00:10:20PRD를 읽고 필요한 기능을 구현하는 '구현자'입니다. 두 번째는
00:10:25'thermonuclear 코드 검토자'이며, 오직 검토 점수를 반환하는 역할만 합니다. 편집 기능은 없습니다.
00:10:30이것을 트리거하려면 'review loop' 명령을 실행합니다.
00:10:35먼저 앱의 목적을 이해하고 1라운드에 대한 thermonuclear 검토를 시작합니다.
00:10:40첫 번째 검토에서 앱 실행 자체를 막는 치명적인 문제를 포함하여 발견된 문제를 기록합니다.
00:10:45JSON 파일에 결과를 기록하고 구현자 에이전트를 실행해 수정합니다.
00:10:51루프는 계속 진행되지만 한 가지는 유의하세요. 워낙 많은 차원을 검토하기 때문에,
00:10:56상당히 오랜 시간이 걸리고 많은 토큰을 소비합니다. 동적 워크플로우가
00:11:01전체 하위 에이전트 세트에 걸쳐 작업을 분산하기 때문입니다. 따라서 앱을 대규모로 빌드한 후
00:11:06철저히 검토하고 싶을 때 사용하는 것이 좋습니다. 또는 동적 워크플로우 없이
00:11:12일반적인 검토자 에이전트를 사용하여 구축할 수도 있습니다. 시간과 토큰 소모가 훨씬 적죠.
00:11:17영상이 즐거우셨다면 채널을 구독하고 'hype' 버튼을 눌러주세요.
00:11:22작은 지원이 저희에게는 큰 힘이 됩니다. 지금까지 보여드린 모든 루프 중
00:11:28루프 자체를 개선하는 별도의 단계가 있는 루프는 없었습니다. 하지만 그게 루프의 진정한 핵심이죠.
00:11:33바로 여기서 '워크플로우 개선 루프'가 등장합니다. 이 루프는 단순히 작업을
00:11:38반복하는 것을 넘어 프로세스 자체를 살펴보고 워크플로우 개선을 제안합니다.
00:11:43앞서 다룬 러닝 루프도 그렇게 하는 것 같지만 분명한 차이가 있습니다.
00:11:48러닝 루프는 기술, 즉 프로세스 내부의 한 부분만을 개선합니다.
00:11:53반면 이 루프는 설정한 전체 프로세스, 즉 루프 자체를 개선합니다. 엔트리 포인트는
00:11:58각 실행 중에 일어나는 모든 것의 오케스트레이터 역할을 하는 'iterate' 명령입니다.
00:12:03세 명의 에이전트가 있습니다. 첫 번째는 빌더 에이전트로 구현을 담당하고 각 실행마다
00:12:08앱의 요구사항 중 하나를 전달합니다. 두 번째는 채점자로 앱의 품질 가이드라인 역할을 하는
00:12:13기준에 따라 구현을 확인하고 100점 만점으로 점수를 매깁니다. 그리고
00:12:19세 번째는 프로세스 최적화 에이전트로, 실제로 자기 개선을 담당합니다.
00:12:24보통 루프는 계획, 구현, 검증, 반복 과정을 거치지만,
00:12:29이 에이전트는 루프 반복을 검토하고 더 나은 방법을 제안하는 추가 단계를 더합니다.
00:12:35사용하려면 'iterate all' 명령을 실행하면 됩니다. 'all'은 단일 워크플로우 내에서 앱 전체를 구현한다는 의미입니다.
00:12:40루프는 빌더 에이전트를 가동하며 시작합니다.
00:12:44그런 다음 채점자가 기준에 따라 구현된 내용을 평가하고 매 라운드마다 점수를 JSON 파일에 기록합니다.
00:12:49이후 프로세스 최적화 에이전트가 작동하여 대화 내용을 살펴보고 워크플로우를 개선할 점이 있는지 파악합니다.
00:12:55앱이 고품질로 빌드되고 올바른 단계가 따르고 있는지 확인하죠.
00:13:00따라서 이 워크플로우가 끝나면 단순한 빌드 앱을 넘어,
00:13:04테스트되고 정교화되어 모든 단계가 검증된 워크플로우를 얻게 됩니다.
00:13:10영상은 여기까지입니다. 채널을 지원하고 이런 영상을 계속 제작하도록 돕고 싶다면
00:13:15아래 슈퍼 땡스(super thanks) 버튼을 통해 지원하실 수 있습니다.
00:13:20늘 시청해 주셔서 감사합니다. 다음 영상에서 뵙겠습니다.