당신의 피드 절반이 갑자기 같은 말을 하고 있습니다. 에이전트에게 프롬프트를 주는 것을 멈추고, 루프를 엔지니어링하세요.

Claude Code를 만든 Boris Cherny가 명확히 말했습니다: "저는 더 이상 Claude에게 프롬프트를 주지 않습니다. 제가 실행하는 루프가 있습니다. 제 일은 루프를 작성하는 것입니다."

세계에서 가장 인기 있는 코딩 에이전트 중 하나를 만든 사람이 프롬프트를 주지 않습니다. 그렇다면 그는 대신 무엇을 하고 있을까요?

이것이 바로 루프 엔지니어링의 핵심 아이디어입니다. 이제 왜 이것이 보기보다 어려운지 분석해 보겠습니다.

첫째, 루프 그 자체#

에이전트는 마법 상자가 아닙니다. 핵심은 단순한 루프입니다:

python

while True:
    response = model(context)
    if response.has_tool_calls():
        results = run_tools(response.tool_calls)
        context += results
    else:
        break

모델이 컨텍스트를 읽습니다. 도구 호출을 요청합니다. 당신이 도구를 실행하고 결과를 다시 피드합니다. 모델이 다시 읽고, 도구 요청을 멈출 때까지 반복합니다.

모델 → 도구 → 컨텍스트 → 반복.

여기 사람들을 놀라게 하는 부분이 있습니다. 이 루프는 이미 해결된 문제입니다. 모든 진지한 에이전트 프레임워크는 대략 이 여섯 줄에 도달합니다. 아무도 while 문으로 경쟁하지 않습니다.

그렇다면 루프가 사소하다면, 사람들은 실제로 무엇을 엔지니어링하고 있을까요?

작업이 모델 외부로 이동했습니다#

AI의 중심은 계속해서 모델 자체에서 멀어지고 있습니다.

프롬프트 엔지니어링. 당신이 보내는 단어들.
컨텍스트 엔지니어링. 모델이 보는 모든 것, 단순한 지시사항뿐만 아니라.
하네스 엔지니어링. 도구를 실행하고, 상태를 추적하며, 오류를 처리하는 모델 주변의 코드.
루프 엔지니어링. 전체를 목표로 이끄는 자율적인 사이클.

각 계층은 이전 계층을 감쌉니다. 프롬프트에 대한 관심을 멈춘 것이 아닙니다. 프롬프트가 훨씬 더 큰 시스템의 작은 조각일 뿐임을 깨달은 것입니다.

LangChain이 깔끔하게 설명합니다. 에이전트 = 모델 + 하네스. 당신이 모델이 아니라면, 당신은 하네스입니다.

그리고 여기 당신의 우선순위를 재정렬해야 할 발견이 있습니다. 이제 하네스가 모델보다 더 중요합니다. 팀들은 모델을 고정시키고, 주변 코드만 변경한 채 벤치마크 중간에서 상위 5위 안으로 뛰어올랐습니다. 같은 두뇌, 다른 루프.

루프 엔지니어링은 그 두뇌가 실행되는 모든 것을 구축하는 학문입니다. 실제로 문제가 되는 부분들을 보여드리겠습니다.

어려운 부분 1: 멈출 때를 아는 것#

이것은 아무도 경고하지 않는 문제입니다.

에이전트가 도구 요청을 멈추면, 그것은 턴을 종료한 것입니다. 이것은 작업을 완료한 것과 같지 않습니다.

코딩 에이전트를 상상해 보세요. 코드를 작성하고, 주변을 살짝 둘러보며, 진전이 있었음을 확인하고, 완료되었다고 선언합니다. 테스트는 여전히 실패합니다. 그럼에도 승리를 선언합니다.

터미널 메시지는 턴을 종료할 뿐, 작업을 종료하지 않습니다. 이 둘을 혼동하는 것은 루프가 잘못되는 가장 흔한 방법입니다.

좋은 루프는 올바른 이유로 멈춥니다. 따라서 여러 가지 제동 장치를 계층화합니다:

최대 반복 횟수. 고착된 에이전트가 영원히 실행되지 않도록 하는 하드 한도.
예산 및 시간 제한. 토큰, 비용, 시간에 대한 상한선.
진전 없음 감지. 동일한 인수로 동일한 호출을 반복한다면, 그것은 제자리걸음입니다.
실제 완료 확인. 작업이 완료되었음을 증명하는 자동화된 조건.

마지막 것이 가장 중요한 역할을 합니다. "완료"는 에이전트가 자신의 작업에 대해 기분이 좋다는 의미가 아니라, 테스트가 통과한다는 의미여야 합니다.

어려운 부분 2: 컨텍스트를 깨끗하게 유지하는 것#

긴 루프는 내부에서부터 썩습니다.

에이전트가 더 많은 턴을 거칠수록, 오래된 도구 출력, 막다른 길, 쓸모없는 추론과 같은 정크가 컨텍스트에 더 많이 쌓입니다. 그 더미가 커질수록 모델 성능은 떨어집니다. 이 현상을 컨텍스트 부패(context rot)라고 합니다.

루프는 이를 악순환시킵니다. 부패한 컨텍스트는 더 나쁜 결정을 내리고, 더 많은 노이즈를 추가하며, 컨텍스트를 더욱 부패시킵니다. 사람들은 이것을 둠 루프(doom loop)라고 부르며, 당신도 느껴본 적이 있을 것입니다. 에이전트가 오래 실행될수록 더 멍청해집니다.

컨텍스트를 버킷이 아닌 예산으로 취급함으로써 이에 맞서 싸웁니다:

압축(Compaction). 대화가 길어지면 요약한 후 요약본에서 계속 진행합니다.
오프로딩(Offloading). 거대한 출력을 파일로 밀어내고 필요한 조각만 유지합니다.
하위 에이전트(Sub-agents). 지저분한 하위 작업을 별도의 에이전트에 넘기고 깨끗한 결과만 반환받습니다.

본능은 만일을 대비해 모든 것을 유지하는 것입니다. 기술은 무엇을 버려야 하는지 아는 것입니다.

어려운 부분 3: 에이전트가 실제로 사용할 수 있는 도구#

루프는 그 안에 있는 도구만큼만 좋습니다.

수백 개의 도구를 쌓아두면 에이전트는 어떤 것을 사용해야 할지 파악하지 못합니다. 집중되고 중복되지 않는 작은 도구 세트가 승리합니다. Anthropic의 경험 법칙은 명확합니다. 인간 엔지니어가 어떤 도구가 적합한지 확실히 말할 수 없다면, 에이전트는 기회가 없습니다.

사람들이 예상보다 더 중요하게 여겨야 할 두 가지가 있습니다:

쓰기 작업을 반복해도 안전하게 만드세요. 루프는 재시도하며, 재시도된 "고객 생성" 호출이 두 번째 고객을 만들면 중복 레코드와 이중 청구로 일어나게 됩니다. 상태를 변경하는 모든 것은 두 번 호출해도 안전해야 합니다.
에이전트를 위한 오류 메시지를 작성하세요, 인간을 위한 것이 아닙니다. 좋은 오류는 에이전트에게 다음에 무엇을 해야 하는지 알려줍니다. 도구를 출시하기 전에, LLM이 그 오류를 읽었을 때 다음 단계를 알 수 있을지 물어보세요.

루프에서 오류는 막다른 길이 아닙니다. 그것은 다음 지시사항입니다.

어려운 부분 4: "아니오"라고 말할 수 있는 무언가#

자율 루프에는 조용한 실패 모드가 있습니다. 혼자 남겨진 에이전트는 자신에게 동의하는 경향이 있습니다.

전체 논쟁에서 가장 날카로운 의견이 이것을 정확히 짚었습니다. 루프를 설계하는 것이 작업의 절반이고, 나머지 절반은 루프 안에 "아니오"라고 말할 수 있는 무언가, 즉 테스트, 타입 검사, 또는 실제 오류를 넣는 것입니다.

비판자가 없는 루프는 자신의 작업에 고개를 끄덕이는 에이전트에 불과합니다.

해결책은 제작자와 검사자를 분리하는 것입니다. 한 모델이 작업을 수행합니다. 다른 검사, 종종 별도의 모델이나 하드 테스트가 그것을 평가합니다. 작업자는 자신의 숙제를 스스로 채점하지 않습니다.

실제 변화#

이제 Cherny의 인용문이 이해가 됩니다.

프롬프팅은 당신이 에이전트를 한 단계씩 조종하는 것입니다. 루프 엔지니어링은 당신이 그것을 조종하는 시스템을 구축하고, 물러서는 것입니다.

당신의 역할은 지시를 내리는 것에서 세 가지를 설계하는 것으로 바뀝니다:

목표. 에이전트가 스스로 확인할 수 있는 성공 기준으로 작성됩니다.
루프. 적절한 제동 장치가 있어 잘 멈춥니다.
검증자. "완료"가 주장되는 것이 아니라 증명됩니다.

Andrej Karpathy가 이 마인드셋을 잘 포착했습니다. 모델에게 무엇을 해야 하는지 말하지 말고, 성공 기준을 주고 지켜보라는 것입니다. 그는 스크립트를 수정하고, 테스트하고, 작동하는 것을 유지하고, 그렇지 않은 것을 폐기하는 연구 루프를 밤새 실행하며, 자신은 루프에 전혀 개입하지 않습니다. 한 번 설정하고 실행 버튼을 누릅니다.

이것이 전환입니다. 당신은 손이 되는 것을 멈추고 기계를 설계하는 사람이 됩니다.

어디서부터 시작할까#

첫날부터 밤새 실행되는 자율 에이전트가 필요하지 않습니다. 단계적으로 구축하세요:

기본 루프로 시작하고, 즉시 최대 반복 횟수, 타임아웃, 비용 상한선을 추가하세요.
"완료"를 시작하기 전에 자동화된 검사로 정의하고, 나중에 느낌으로 정의하지 마세요.
컨텍스트를 보호하세요. 긴 실행을 압축하고, 큰 출력을 오프로드하며, 지저분한 하위 작업을 격리하세요.
도구를 감사하세요. 적게 유지하고 집중시키며, 쓰기 작업을 반복해도 안전하게 만들고, 에이전트가 조치를 취할 수 있도록 오류를 다시 작성하세요.
루프에 비판자를 넣으세요. "아니오"라고 말하는 것을 신뢰할 수 있을 때만 완전히 손을 떼세요.

요점#

루프 엔지니어링은 설치하는 프레임워크나 도구가 아닙니다. 그것은 당신의 노력을 어디에 집중할지에 대한 변화입니다.

모델은 상품화되고 있습니다. 그 주변의 루프가 이제 실제 엔지니어링이 살아있는 곳입니다.

최고의 빌더들은 "에이전트에게 무엇을 말해야 할까?"라고 묻는 것을 멈췄습니다. 그들은 "나 없이 이것을 해낼 시스템은 무엇일까?"라고 묻기 시작했습니다.

그 질문에 잘 답한다면, 당신도 프롬프트를 멈추게 될 것입니다.

루프 엔지니어링의 핵심 요점을 요약한 이미지입니다.

읽어주셔서 감사합니다!

건배 :) Akshay.

Agent Cookbook

루프 엔지니어링 완벽 설명