00:00:00Ralph Wiggum이 엄청나게 뜨고 있습니다. 작년에 관련 영상을 올린 이후로
00:00:04트위터에서는 온통 이 이야기뿐이죠. Matt Pocock은 수많은 영상을 만들었고,
00:00:09Ryan Carson은 아주 인기 있는 기사를 썼으며, Razmike는 Ralphie Bash 스크립트로
00:00:13이를 더욱 발전시켰습니다. 하지만 다들 잘못하고 있는 걸까요? 제작자는 이미
00:00:19일부 구현 방식이 잘못되었다고 언급했습니다.
00:00:21그렇다면 올바른 방법은 무엇일까요? 그리고 왜 Ralph가 현재 AI로 소프트웨어를 개발하는 가장 좋은 방법일까요?
00:00:26구독 버튼을 누르고 자세히 알아보겠습니다.
00:00:30Ralph 루프는 Jeff Huntley가 만들었으며 작년 6월에 처음 소개되었습니다.
00:00:35이것은 본질적으로 AI 에이전트에게 똑같은 프롬프트를 반복해서 전달하는 bash 루프입니다.
00:00:40하지만 여러 면에서 천재적입니다. AI 에이전트가 가장 적은 컨텍스트를 가질 때
00:00:46가장 똑똑하게 작동한다는 점을 이용하기 때문이죠. 이걸 한번 보시죠.
00:00:51이것이 에이전트의 전체 컨텍스트 창이라고 가정해 봅시다. 0에서 30% 정도까지가
00:00:57에이전트가 최고의 성능을 발휘하는 일명 '스마트 존'입니다. 약 30%에서
00:01:0160%까지는 여전히 성능이 훌륭합니다. 하지만 60%가 넘어가는 시점, 즉 70, 80, 90%부터는
00:01:08성능이 저하되기 시작합니다. 여기를 '덤(Dumb) 존'이라고 부르겠습니다. 물론 이 수치는
00:01:12절대적인 것은 아니며 모델마다 다를 수 있습니다. 어떤 모델은 스마트 존이 40~50%일 수도 있지만,
00:01:16보통 컨텍스트 창의 80%를 넘어가면 지능 저하 현상이 나타나기 시작합니다.
00:01:21Claude Sonnet이나 Opus의 경우, 일반적인 컨텍스트 창은 20만 토큰입니다.
00:01:28처음 6만 토큰까지는 스마트 존이라고 할 수 있죠. 다음 6만 토큰도 괜찮긴 하지만
00:01:33처음 6만 토큰만큼은 아닙니다. 그리고 마지막 8만 토큰에서는 성능이 제대로 나오지 않는 듯합니다.
00:01:38이것은 제 개인적인 경험일 뿐이며, 여러분은 다를 수도 있습니다. 이런 현상이 발생하는 이유는
00:01:43모델 자체가 '자기 회귀(Autoregressive)' 방식이기 때문입니다. 즉, 다음 토큰을 예측하기 위해
00:01:47이전 토큰들을 살펴봐야 한다는 뜻이죠. 토큰이 너무 많으면 다음에 수행할 작업에
00:01:52관련된 중요한 부분을 찾아내기 위해 수많은 데이터를 훑어야 합니다.
00:01:56이제 처음 30% 구간에 집중해 봅시다. 첫 프롬프트를 작성하기도 전에
00:02:01컨텍스트 창에 자동으로 추가되는 것들이 있습니다. 먼저 시스템 프롬프트가 있고,
00:02:06그다음은 시스템 도구입니다. 일반적인 Claude 모델에서는 각각 컨텍스트의 8.3%와 1.4%를 차지합니다.
00:02:12스마트 존 30% 중 거의 10%를 이미 쓰는 셈이죠. 여기에 '스킬'이나
00:02:16커스텀 MCP 도구, 그리고 agent.md 파일까지 있다면 그만큼 더 추가됩니다.
00:02:21당연히 이 파일들이 커질수록, 특히 agent.md 파일이 클수록 더 많은 토큰을
00:02:25잡아먹게 됩니다. 여러분의 프롬프트를 넣기도 전에 말이죠. 따라서
00:02:30일반적으로 이 섹션을 최대한 작게 유지하는 것이 좋습니다. 도구나 스킬,
00:02:35agent.md 파일 내용을 줄여서 모델이 가장 최적의 컨텍스트 상태에서 작동하게 해야 합니다.
00:02:406만 토큰이 어느 정도인지 감을 잡기 위해 예를 들자면, 영화 '스타워즈: 새로운 희망'의
00:02:44전체 대본이 GPT-5 기준으로 약 54,000 토큰 정도 됩니다. 대략 그 정도 분량인 거죠.
00:02:51이제 압축(Compaction)이 이 과정에 도움이 되지 않을까 궁금하실 텐데요, 그 부분은
00:02:56잠시 후에 다루겠습니다. 이제 Ralph가 구체적으로 어떻게 도움이 되는지 알아보죠.
00:03:00Ralph의 장점은 컨텍스트 창 하나당 하나의 목표에만 집중한다는 것입니다.
00:03:0520만 토큰의 컨텍스트 창 전체를 하나의 목표나 작업에 전념하게 할 수 있습니다.
00:03:10방법은 이렇습니다. 먼저 plan.md 파일을 검토하라는 프롬프트를 작성합니다.
00:03:15이 파일에는 프론트엔드 생성, 백엔드 생성, 데이터베이스 작업 등 수행해야 할 작업들이
00:03:19담겨 있습니다. 아주 개괄적인 예시일 뿐이지만, 실제 Ralph를 사용할 때는
00:03:23훨씬 더 세분화하고 구체적으로 작성하게 됩니다. 어쨌든 이 프롬프트는
00:03:28에이전트에게 가장 중요한 작업을 골라 변경 사항을 적용하라고 지시합니다. 변경 후에는
00:03:33테스트를 수행하고, 변경 사항을 커밋하고 푸시까지 하도록 합니다.
00:03:38그 작업이 끝나고 테스트를 통과하면 plan.md 파일에 완료 표시를 하고
00:03:42이 과정을 반복합니다. 에이전트는 모든 작업이 완료될 때까지 계속해서
00:03:46수행해야 할 가장 중요한 작업을 찾아낼 것입니다. 사실 방금 한 말은 취소하겠습니다.
00:03:52모든 작업이 완료된 후에도 Ralph 루프를 계속 돌릴 수 있기 때문이죠.
00:03:57그렇게 하면 에이전트가 수정할 부분을 더 찾아내거나 plan.md에는 없던
00:04:02새로운 기능을 제안할 수도 있습니다. 만약 루프가 의도와 다르게 흘러간다면,
00:04:08Ralph의 장점인 '언제든 중단 가능'을 활용해 프롬프트 파일을 수정하고 다시 실행하면 됩니다.
00:04:12이 모든 과정이 단 하나의 bash while 루프로 실행되기 때문에 Ralph는 매우 심플합니다.
00:04:16여기서 prompt.md 파일을 읽어 에이전트에게 출력하고 Claude를 소위 'YOLO 모드'로 실행합니다.
00:04:22물론 실제 플래그가 YOLO인 건 아니고 '권한 확인 건너뛰기' 옵션인데,
00:04:26공간을 줄이려고 그렇게 불렀습니다.
00:04:31Ralph가 특별한 점은 모델의 통제권 밖에 있다는 점입니다. 모델 스스로
00:04:36Ralph를 멈출 수 없으며, 루프는 계속 돌아갑니다. 덕분에 새로운 작업이나
00:04:41새 프롬프트가 실행될 때마다 컨텍스트는 에이전트를 처음 열었을 때와 같은
00:04:46깨끗한 상태를 유지합니다. 압축된 것도 없고 추가된 것도 없죠.
00:04:50따라서 각 작업은 최대한의 컨텍스트를 확보하며 가장 스마트하고 최적화된
00:04:55컨텍스트 창 상태에서 모델을 사용하게 됩니다. 기본적으로 압축이란 에이전트가
00:05:01지금까지 작성된 모든 토큰을 살펴보고 다음 프롬프트에 가장 중요하다고 판단되는
00:05:05핵심만 골라내는 과정입니다. 하지만 무엇이 '진짜' 중요한지는 에이전트가 완벽히 알 수 없죠.
00:05:11따라서 압축 과정에서 중요한 정보가 유실되어 프로젝트가 예상대로 작동하지 않을 수 있습니다.
00:05:16어쨌든 제작자가 만든 이 표준적인 Ralph 루프 구현 방식을 보면
00:05:21다른 구현 방식들이 왜 차이가 나는지 알 수 있습니다. Anthropic의 구현 방식을 보죠.
00:05:27슬래시 명령어를 사용해 Claude 코드 내부에서 Ralph를 실행하며, 최대 반복 횟수와
00:05:33완료 보장(completion promise) 기능이 있습니다. 하지만 이 방식의 문제점은
00:05:38다음 작업으로 넘어갈 때 정보를 압축한다는 점입니다. 한 작업을 마치고
00:05:43프롬프트를 재실행할 때 컨텍스트 창을 완전히 초기화하는 대신 이전 내용을 압축하므로
00:05:48중요한 정보를 잃을 수 있습니다. 또한 최대 반복 횟수나 완료 보장 기능이
00:05:54오히려 방해가 될 수도 있습니다. 가끔은 Ralph를 계속 돌아가게 두는 게 좋을 때도 있거든요.
00:05:59생각지도 못했던 흥미로운 해결책을 찾아내기도 하니까요. 그리고 사람이 개입해(Human-on-the-loop)
00:06:04관찰하다 보면 특정 모델의 좋거나 나쁜 패턴을 발견해 프롬프트를 개선할 수도 있습니다.
00:06:08Ryan Carson의 접근 방식을 보면 이것도 표준 방식과는 약간 다릅니다.
00:06:14루프가 돌 때마다 agent.md 파일을 수정하거나 내용을 추가할 가능성이 있기 때문이죠.
00:06:19시스템 프롬프트나 사용자의 설정에 따라 다르겠지만, 제 경험상 기본적으로
00:06:24모델들은 말이 많은 편입니다. 반복할 때마다 agent.md 파일에 내용이 추가되고,
00:06:29이 파일이 매번 사용자 프롬프트 시작 부분에 포함된다면 결국 컨텍스트 창에
00:06:33토큰이 쌓이게 됩니다. 모델을 '덤 존'으로 몰아넣어 성능 저하를 유발할 수 있죠.
00:06:39그럼에도 불구하고 사람들이 기본 Ralph 루프 bash 스크립트를 토대로 자신만의 스크립트를
00:06:44만든다는 것은 이 방식이 그만큼 단순하고 이해하기 쉽다는 증거입니다.
00:06:48비록 표준적인 방식은 존재하지만, 개발자나 팀, 회사가 각자의 사례에 맞춰
00:06:53변형해 사용하는 것은 좋다고 생각합니다. 예를 들어 Raz Mike의 Ralphie 스크립트처럼
00:06:57Ralph를 병렬로 실행하거나, 에이전트 브라우저 도구를 활용해
00:07:03브라우저 테스트를 수행하는 방식은 정말 훌륭합니다. Matt Pocock의 버전도 인상적인데요,
00:07:08할 일을 GitHub 이슈로 등록하면 Ralph 루프가 가장 중요한 이슈를 골라
00:07:13작업하고 완료 표시를 한 뒤 다음 이슈로 넘어가는 방식인데, 아주 영리한 아이디어라고 봅니다.
00:07:18Ralph의 파워와 단순함 덕분에 이 방식은 아주 오랫동안 살아남을 것입니다.
00:07:23앞으로도 많은 변형과 개선이 이루어질 거고요. Jeffrey가 Loom and Weaver 프로젝트를 통해
00:07:28소프트웨어를 자율적이고 정확하게 만들려는 방향성도 아주 마음에 듭니다. 하지만
00:07:32Ralph들이 자율적으로 소프트웨어를 만들다 보면 에러를 찾아내고
00:07:37수정할 방법이 필요해집니다. 이때 Better Stack이 큰 도움이 됩니다.
00:07:42로그를 수집하고 에러를 걸러낼 뿐만 아니라 프론트엔드의 에러 트래킹도 처리하기 때문이죠.
00:07:47이 MCP 서버를 사용하면 에이전트에게 로그 전체를 읽게 하는 대신 프론트엔드나
00:07:52백엔드의 특정 에러만 골라내도록 요청할 수 있어 컨텍스트 창을 줄일 수 있습니다.
00:07:56Better Flux를 한번 확인해 보시고 의견을 댓글로 남겨주세요.
00:08:01and filter out errors from them, but it can also handle error tracking on the front end.
00:08:06So with this MCP server, you can ask an agent to specifically pick out errors from the front
00:08:11end or back end instead of reading through the whole log, which in turn reduces the context
00:08:16window.
00:08:17So go and check out Better Flux, and let me know what you think in the comments.