랄프 위검 코딩: 루프는 쉽다. 프롬프트가 전부다.

최근 AI 개발 트위터를 조금이라도 본 적이 있다면, 이것을 보셨을 겁니다: 랄프 위검 코딩 접근법.

지속적인 실패에도 불구하고 계속 시도하는 심슨즈 캐릭터의 이름을 딴 이 기법은 놀랄 정도로 단순합니다. AI 코딩 에이전트를 루프로 실행하세요. 실패하도록 두세요. 다시 시도하도록 하세요. 성공하거나 한계에 도달할 때까지 계속하세요.

The Simpsons의 Ralph Wiggum

결과는 놀라웠습니다. 이 접근법을 개척한 Geoffrey Huntley는 API 비용 $297로 $50,000 계약을 성사시켰습니다. Claude Code를 만든 Boris Cherny는 30일 동안 259개의 PR을 올렸는데, 모든 줄이 AI가 작성한 것이었습니다. Anthropic은 공식 플러그인을 출시했습니다.

바이럴 포스트들은 루프에 초점을 맞춥니다. bash 스크립트에. 밤새 자동화에.

요점을 놓치고 있습니다.

루프는 사소한 것입니다

전체 기법은 다음과 같습니다:

while :; do cat PROMPT.md | claude ; done

끝입니다. 30초 안에 작성할 수 있습니다.

그렇다면 일부 개발자들은 혁신적인 결과를 얻는데 다른 개발자들은 에이전트가 제자리를 맴도는 것을 보며 API 크레딧을 태워버리는 이유는 무엇일까요?

답은 루프가 아닙니다. 무엇을 입력하느냐입니다.

프롬프트 품질이 진짜 열쇠입니다

공식 문서에서 직접 말하고 있습니다: “Ralph의 성공은 좋은 모델을 갖는 것이 아니라 좋은 프롬프트를 작성하는 데 달려 있습니다.”

대부분의 리뷰는 “구체적으로 작성하라”와 “완료 기준을 포함하라”에서 멈춥니다. 그건 기본입니다. 진정한 결과를 얻고 있는 개발자들은 다른 차원에서 작업하고 있습니다.

예를 들어보겠습니다:

실패할 프롬프트:

할 일 API를 만들고 잘 만들어줘.

작동하는 프롬프트:

/ralph-wiggum:ralph-loop "할 일 항목을 위한 REST API를 구현하세요.

요구사항:
- 할 일을 위한 CRUD 엔드포인트
- 모든 필드에 대한 입력 검증  
- 적절한 HTTP 상태 코드를 가진 에러 핸들링

성공 기준:
- 모든 엔드포인트가 올바르게 응답
- 80% 이상 커버리지로 테스트 통과  

15회 반복 후 완료되지 않으면:
- 차단 이슈 문서화
- 시도한 접근법 목록화

완료되면 <promise>COMPLETE</promise> 출력." --max-iterations 30

두 번째 프롬프트는 첫 번째가 하지 않는 세 가지를 합니다: 성공을 명확히 정의하고, 에이전트에게 자신의 작업을 검증하는 방법을 알려주며, 유용하게 실패하는 방법에 대한 지침을 포함합니다.

마지막 부분이 좋은 프롬프트와 뛰어난 프롬프트를 구분하는 것입니다.

프롬프트 품질 계층

여러 프로젝트에서 이러한 루프를 실행한 후, 저는 프롬프트 품질을 세 단계로 생각합니다:

1단계: 완료 기준. 에이전트가 언제 멈춰야 하는지 알고 있습니다. 대부분의 사람들이 여기까지 도달합니다.

2단계: 자기 검증. 에이전트가 자신의 작업을 확인할 수 있습니다. Boris Cherny는 이것을 “아마도 가장 중요한 것”이라고 합니다. Claude에게 결과를 검증할 방법을 주면 품질이 두 배가 됩니다.

3단계: 실패 복구. 프롬프트에 막혔을 때 무엇을 해야 하는지 포함되어 있습니다. 단순히 “다시 시도하라”가 아니라 진단 단계, 대안 접근법, 우아한 성능 저하를 말입니다. 여기가 진짜 레버리지가 있는 곳인데, 거의 아무도 이야기하지 않습니다.

대부분의 실패는 프롬프트가 성공 경로에서는 작동하지만 복구 전략이 없기 때문에 발생합니다. 에이전트가 막히고, 50회 반복을 돌며, 유용한 것을 전혀 생산하지 못합니다.

잘 설계된 프롬프트는 실패를 정보로 취급합니다. 두 시간을 잃는 대신, 두 시간을 잃더라도 보여줄 것이 있는 상태로 만듭니다.

직관에 반하는 진실

바이럴 포스트들이 언급하지 않는 것이 있습니다: 프롬프트에 더 많은 세부사항을 채워넣는 것은 종종 상황을 더 나쁘게 만듭니다.

연구에 따르면 최적의 컨텍스트 활용도는 40-60%입니다. 그 이상을 넘으면 모델 성능이 새로운 지침뿐만 아니라 모든 것에서 저하됩니다.

일관된 결과를 얻는 실무진들은 프롬프트를 간결하게 유지합니다. 모든 것을 미리 채워넣는 대신 Claude에게 정보를 찾는 방법을 알려줍니다. 큰 작업을 더 작은 루프로 나눕니다.

더 많은 세부사항은 더 많은 통제력처럼 느껴집니다. LLM에서는 더 많은 세부사항이 더 적은 능력이 되는 지점이 있습니다.

이것이 향하는 곳

제가 믿는 것은 이것입니다: 우리는 이러한 시스템과 작업하는 방법을 이해하는 것의 아주 초기 단계에 있습니다.

지금 대부분의 사람들은 병목이 모델 능력이라고 생각합니다. 그렇지 않습니다. 병목은 기계가 자율적으로 행동할 수 있을 만큼 충분히 명확하게 의도를 전달하는 우리의 능력입니다. 그것은 기술입니다. 그리고 모든 기술처럼, 일찍 개발하는 사람들이 엄청난 이점을 갖게 될 것입니다.

랄프 위검 기법은 그 미래를 엿보는 창입니다. 루프가 영리해서가 아니라, 프롬프트가 실제로 좋은지를 가차없이 드러내기 때문입니다. 실패한 반복마다 피드백입니다. 성공한 실행마다 기계가 실행할 수 있는 방식으로 생각하는 법을 배웠다는 증거입니다.

이것을 bash 스크립트 트릭으로 취급하는 개발자들은 더 큰 변화를 놓치고 있습니다. 이것을 인간-기계 협업을 위한 새로운 분야로 취급하는 사람들은 나머지 우리가 아직 상상할 수 없는 것들을 만들어낼 것입니다.

루프는 쉽습니다. 프롬프트가 전부입니다.

우리는 여러 프로젝트에서 개발을 가속화하기 위해 이러한 기법들을 사용하고 있습니다. 비슷한 과제를 다루고 계시다면, 연락주세요.