프롬프트 엔지니어링(Prompt Engineering)은 죽었다, 루프 엔지니어링(Loop Engineering)이 그 바통을 이어받다

프롬프트 엔지니어링 (Prompt Engineering)은 죽었고, 루프 엔지니어링 (Loop Engineering)이 그 바통을 이어받았습니다.

@karpathy의 방식이 가장 생생하게 느껴집니다. 밤에 연구 루프를 설정해두면, 자동으로 스크립트를 수정하고 테스트를 실행하며, 맞는 것은 남기고 틀린 것은 버린 뒤 잠자리에 듭니다. 아침에 일어나면 결과만 바로 확인하면 되죠. 전 과정에서 거의 개입하지 않습니다.

이것이 바로 현재 업계에서 이야기하는 루프 엔지니어링 (Loop Engineering)입니다. AI를 한 단계씩 지휘하는 것에서, 스스로 완주할 수 있는 시스템을 설계하는 것으로 변모하는 것입니다.

네 가지 핵심 기둥이 있으며, 각각은 실제 운영 환경에서 겪은 뼈아픈 경험을 통해 얻은 것입니다.

1️⃣ 언제 멈춰야 할지 아는 것: AI가 스스로 완료했다고 말하는 것을 믿지 마세요. 코드가 실행되지 않거나 논리에 허점이 있는 경우가 허다합니다. 강제 종료 조건과 독립적인 검증 단계를 추가해야 합니다. 수많은 프로젝트가 데모 단계에서 실제 적용 단계로 넘어가지 못하고 이 단계에서 실패합니다.

2️⃣ 컨텍스트 (Context)를 깨끗하게 유지하는 것: 루프가 오래 돌아가면 오래된 오류, 막다른 길, 불필요한 사고가 쌓이게 되어 의사결정 품질이 급격히 떨어집니다. 컨텍스트를 한정된 예산처럼 관리해야 합니다. 정기적으로 압축하고, 서브 에이전트 (Sub-Agent)를 사용하여 하위 작업을 격리해야 합니다.

3️⃣ 실제로 사용 가능한 도구를 제공하는 것: 단순히 숫자를 채우기 위해 100개의 도구를 쌓아두는 것이 아니라, 중복 없이 적고 정교해야 합니다. 안전하게 재시도할 수 있어야 하며, 오류 메시지를 이해할 수 있어야 합니다. 이것이 운영 환경에서 가장 사고가 나기 쉬운 부분입니다.

4️⃣ '아니오'라고 말할 수 있는 메커니즘을 갖추는 것: 에이전트 (Agent)는 자신의 결점을 찾아내지 못하며, 스스로 숙제를 고칠 때는 항상 만점을 줍니다. 반드시 실행하는 역할과 검사하는 역할을 분리해야 합니다. 즉, Maker-Checker 패턴을 도입해야 하며, Claude Code 팀은 이미 이를 사용하고 있습니다.

@bcherny는 가장 직설적으로 말했습니다. "나는 더 이상 Claude에게 프롬프트를 입력하지 않는다. 나는 루프 (Loops)를 작성하고, 그것들이 돌아가게 만든다."

모델은 점차 표준 부품처럼 변하고 있습니다.
동일한 모델이라도 더 나은 루프 설계가 결합되면, 성능을 중간 수준에서 최상급으로 끌어올릴 수 있습니다.
진정한 엔지니어링 가치는 이미 단일 대화에서 장기 자율 시스템 (Long-term Autonomous Systems)의 설계로 이동했습니다.

에이전트 (Agent)를 만드는 분들은 스스로를 점검해 보시기 바랍니다. 당신이 언제 프롬프트를 쓰는 사람에서 시스템을 설계하는 사람으로 변했는지, 그리고 언제 다음 단계의 문턱에 도달했는지를 말입니다.