루프 엔지니어링이란? LLM 에이전트의 반복 루프 설계 원리와 실무

루프 엔지니어링(loop engineering)은 대규모 언어 모델(LLM)을 한 차례 호출하고 끝내는 대신, 모델의 출력을 다시 입력으로 되먹여 관찰·추론·행동을 반복하는 순환 구조를 설계하는 기술입니다. 쉽게 말해 '한 번에 정답을 내놓아라'가 아니라 '해 보고, 결과를 보고, 고쳐서 다시 해라'라는 흐름을 코드로 짜는 일입니다. 여기서 LLM은 ChatGPT나 Claude처럼 방대한 글을 읽고 배워 사람 말로 답하는 AI 모델을 가리킵니다.

한눈에 보기

• 루프 엔지니어링은 AI에게 한 번에 답을 받는 대신 '해 보고, 결과를 보고, 고치는' 반복을 설계하는 일입니다.
• 반복이 쓸모 있으려면 매 바퀴의 실제 결과를 AI에게 다시 보여 주고, 언제 멈출지 미리 정해 두어야 합니다.
• 반복할수록 비용은 바퀴 수보다 빠르게 늘고 AI의 자기 평가는 믿기 어려우므로, 멈춤 조건과 바깥 검증이 핵심입니다.

한 번의 대답에서 여러 번의 시도로

이런 상황을 떠올려 보세요. 거래처에 보낼 분기 실적 보고서 초안을 ChatGPT에게 맡겼습니다. 첫 답은 그럴듯하지만 숫자 하나가 엑셀 원본과 다르고, 팀장이 싫어하는 과장된 표현이 섞여 있고, 요청한 분량보다 두 배 깁니다. 결국 사람이 틀린 곳을 짚어 "이 숫자 다시 확인해", "좀 더 짧게"라고 몇 번을 되돌려 보낸 끝에야 쓸 만한 글이 나옵니다. 이 '되돌려 보내고 다시 받는' 과정을 사람이 매번 손으로 하지 않고, 정해진 규칙에 따라 자동으로 돌아가게 짜는 것이 루프 엔지니어링입니다.

프롬프트 엔지니어링이 '무엇을 어떻게 물어볼까'에 초점을 둔다면, 루프 엔지니어링은 '모델을 몇 번, 어떤 조건으로, 무엇을 참조하며 다시 돌릴까'를 다룹니다. 질문의 문장을 다듬는 데서 한 걸음 더 나아가, 모델을 둘러싼 실행 흐름 자체를 설계하는 한 층 위의 일입니다.

이 개념은 최근 LLM 에이전트(agent)와 자율 워크플로가 떠오르면서 점점 중요해졌습니다. 에이전트는 사람이 단계마다 지시하지 않아도 AI가 스스로 다음 할 일을 정하고 도구를 써 가며 일을 끝까지 진행하는 프로그램이고, 워크플로는 'A를 하고 나면 B, 그다음 C'처럼 순서를 미리 정해 둔 작업 흐름입니다. 코드 자동 수정, 웹 검색을 곁들인 조사, 여러 단계로 나뉜 데이터 처리처럼 한 번의 응답으로는 도저히 끝나지 않는 작업이 늘었기 때문입니다. 이런 작업을 안정적으로 굴리려면 루프를 잘 설계하는 능력이 꼭 필요합니다.

새 이름, 오래된 생각

먼저 짚어 둘 점이 있습니다. '루프 엔지니어링'은 아직 표준으로 굳은 전문 용어가 아닙니다. 2026년 들어 업계 블로그와 일부 논문에서 쓰이기 시작한 새 이름에 가깝습니다. 예를 들어 LangChain은 2026년 6월 블로그 글 The Art of Loop Engineering에서 에이전트 주변에 여러 겹의 반복 고리를 쌓는 일을 이 이름으로 불렀습니다. 이 해설을 처음 쓴 뒤인 2026년 8월 21일에는 arXiv에 조사 논문 Graph Engineering in the Era of LLM Agents가 올라왔는데, 이 논문은 프롬프트 엔지니어링, 컨텍스트 엔지니어링, 하네스 엔지니어링 다음 단계로 루프 엔지니어링을 꼽았습니다. 다만 쓰는 사람마다 가리키는 범위가 조금씩 달라서, 이 글에서는 '모델 호출을 되풀이하는 흐름을 설계하는 일' 정도의 넓은 뜻으로 씁니다.

이름과 달리 그 안에 담긴 생각은 몇 해 전부터 연구로 다져져 왔습니다. 2022년 ReAct는 모델이 생각과 행동을 번갈아 하며 외부 결과를 읽게 했고, 2023년 Self-Refine은 모델이 자기 답에 의견을 달고 그 의견대로 고쳐 쓰기를 되풀이하게 했습니다. 같은 해 Reflexion은 실패한 시도를 말로 돌아보고 그 반성을 기억에 남겨 다음 시도에 쓰게 했습니다. Anthropic이 2024년 12월 19일 공개한 Building effective agents는 한 모델이 답을 만들고 다른 모델이 평가와 피드백을 돌려주는 '평가자와 개선자(evaluator-optimizer)' 흐름, 그리고 환경의 결과를 보며 도는 에이전트 루프를 정리했습니다. 이 글이 설명하는 내용은 이 흐름들을 한데 묶어 부르는 이름이라고 보면 됩니다.

왜 단발성 프롬프트로는 부족한가

LLM은 다음에 올 토큰(token, AI가 글을 읽고 쓰는 조각 단위로, 보통 단어 하나보다 조금 작은 단위)을 확률 분포에서 하나씩 골라 문장을 이어 붙이는 모델입니다. 이 방식은 짧고 명확한 질문에는 강하지만, 여러 단계의 판단과 외부 정보가 필요한 작업에서는 한계를 드러냅니다. 모델이 중간에 계산을 틀리거나, 최신 정보를 모르거나, 실제 파일 시스템을 건드릴 수 없는 상황에서 한 번의 출력만으로 완결된 결과를 기대하기는 어렵습니다.

예를 들어 '이 저장소의 버그를 고쳐라'라는 요청을 생각해 봅시다. 모델은 코드를 읽고, 원인을 추론하고, 수정안을 만들고, 테스트를 돌려 결과를 확인하고, 실패하면 다시 고쳐야 합니다. 여기서 테스트는 프로그램이 제대로 동작하는지 자동으로 확인해 '통과'나 '실패'를 알려 주는 검사 프로그램입니다. 이 과정을 단 한 번의 응답 안에 밀어 넣으면 모델은 실제 실행 결과를 볼 수 없어 헛다리를 짚기 쉽습니다. 눈을 가린 채 한 번에 정답을 외치라는 요구나 다름없습니다.

루프를 도입하면 상황이 달라집니다. 모델이 수정안을 내면 그 코드를 실제로 실행해 테스트 결과를 얻고, 그 결과를 다시 모델에게 보여 줍니다. 모델은 실패 로그를 근거로 다음 시도를 다듬습니다. 이렇게 '행동 → 관찰 → 재추론'을 반복하면, 단발성 호출로는 닿지 못하던 정확도에 조금씩 다가갑니다. 사람이 시행착오로 문제를 풀듯, 모델에게도 다시 시도할 기회를 주는 것입니다.

사무실에서 보는 루프: 보고서 초안 고쳐 쓰기

개발 현장이 아니어도 루프는 똑같이 돕니다. 앞에서 든 분기 실적 보고서를 예로 한 바퀴씩 따라가 보겠습니다.

첫 바퀴에서 AI는 엑셀 실적표와 작성 지침(두 쪽 이내, 과장 표현 금지, 전년 대비 증감을 꼭 적을 것)을 받아 초안을 씁니다. 여기까지는 평소 ChatGPT를 쓰는 방식과 같습니다.

다음은 검토입니다. 검토는 두 갈래로 나눌 수 있습니다. 하나는 규칙으로 기계적으로 따질 수 있는 부분입니다. 초안에 적힌 매출 숫자가 엑셀 원본과 같은지, 분량이 두 쪽을 넘지 않는지, '획기적', '압도적' 같은 금지 단어가 들어 있는지는 AI에게 묻지 않아도 간단한 프로그램이 정확히 가려냅니다. 다른 하나는 판단이 필요한 부분입니다. 논리 흐름이 자연스러운지, 거래처가 읽기에 어조가 적당한지는 검토 역할을 맡은 별도의 AI에게 체크리스트를 주고 항목별로 의견을 달게 합니다.

검토 결과는 그대로 다음 바퀴의 재료가 됩니다. 숫자가 틀린 곳, 금지 단어, 어긋난 결론 같은 지적이 붙은 채로 AI가 고쳐 씁니다. 그리고 다시 검토합니다. 두 바퀴 만에 끝난 경우를 표로 적으면 다음과 같습니다.

언제 멈출까요. 표의 둘째 바퀴처럼 규칙 검사를 모두 통과하고 검토 AI의 지적이 더 나오지 않으면 끝냅니다. 세 바퀴를 돌았는데도 숫자가 계속 어긋나면 원본 자료 자체에 문제가 있을 가능성이 크므로, 더 돌리지 않고 담당자에게 넘깁니다. 이렇게 '쓰기 → 검토 → 고쳐 쓰기 → 멈출지 판단'을 되풀이하는 것이 루프이고, 무엇을 검토하고 언제 멈출지 미리 정하는 일이 루프 엔지니어링입니다.

엑셀 수식 오류를 찾는 일도 같은 틀로 돌릴 수 있습니다. AI가 의심 가는 수식을 고르고, 프로그램이 그 수식을 실제로 계산해 결과를 돌려주고, AI가 결과를 보고 다음에 볼 칸을 정합니다. 수식을 눈으로만 읽고 추측하는 것보다, 실제 계산 결과를 보며 좁혀 가는 쪽이 훨씬 정확합니다.

사고-행동-관찰의 순환 고리

루프의 뼈대는 대개 세 박자로 돌아갑니다. 첫째, 모델이 현재 상황을 놓고 무엇을 할지 판단합니다(사고, reasoning). 둘째, 그 판단에 따라 실제 도구를 호출하거나 명령을 실행합니다(행동, action). 도구 호출은 AI가 직접 할 수 없는 일, 예컨대 검색, 계산, 파일 열기, 메일 조회를 바깥 프로그램에 부탁하고 그 결과를 받아 오는 것을 말합니다. 셋째, 실행이 낳은 결과를 다시 모델에게 되돌려 줍니다(관찰, observation). 이 세 단계가 목표를 이룰 때까지, 혹은 정해진 한도에 이를 때까지 반복됩니다.

이 구조를 잘 보여 주는 대표 기법이 ReAct입니다. ReAct는 추론(Reasoning)과 행동(Acting)을 번갈아 엮는 방식으로, 모델이 '생각'을 텍스트로 적고 그에 따라 도구를 부른 뒤 '관찰'을 다시 읽어 다음 생각으로 이어 갑니다. 사고 사슬(chain-of-thought)은 AI가 답만 내지 않고 풀이 과정을 한 단계씩 글로 적게 하는 방법인데, ReAct는 이처럼 추론 과정을 겉으로 드러내되 거기에 외부 세계와 주고받을 손발을 달아 준 방식이라고 볼 수 있습니다.

핵심은 되먹임(feedback)입니다. 이전 단계의 실제 결과가 다음 단계의 입력에 스며들어야 루프가 의미를 갖습니다. 결과를 보지 않고 무작정 같은 프롬프트를 반복하면 그것은 루프가 아니라 낭비입니다. 루프 엔지니어링의 큰 몫은 '무엇을 관찰로 되돌려 줄 것인가'를 정하는 일에 달려 있습니다. 실행 로그, 오류 메시지, 검색 결과, 도구의 반환값 가운데 무엇을 얼마나 넣어야 모델이 제대로 방향을 잡는지가 관건입니다. 보고서 예에서라면 "틀렸다"라고만 알려 주는 것보다 "어느 표의 어느 숫자가 원본과 얼마나 다르다"까지 알려 줄 때 다음 초안이 훨씬 빨리 좋아집니다.

루프를 멈추게 하는 조건들

잘 짜인 루프에는 반드시 종료 조건이 있습니다. 목표 달성 신호, 최대 반복 횟수, 시간 제한, 비용 상한이 대표적입니다. 종료 조건이 허술하면 모델은 만족스러운 답을 이미 냈는데도 계속 돌거나, 반대로 영영 끝나지 않는 무한 루프에 빠집니다. 자율 에이전트가 비용을 크게 불리는 사고는 흔히 종료 설계의 실패에서 옵니다. Anthropic의 에이전트 설계 글도 작업이 끝나면 멈추는 것이 기본이지만, 최대 반복 횟수 같은 멈춤 조건을 함께 두어 통제권을 잃지 않는 것이 흔한 방식이라고 적었습니다.

목표 달성을 어떻게 판정하느냐도 중요합니다. 코드 수정이라면 '테스트가 모두 통과했는가'라는 명확한 기준이 있습니다. 반면 글쓰기나 조사처럼 정답이 흐릿한 작업은 별도의 검증자(verifier)를 두거나, 모델 스스로 '완료' 신호를 내도록 유도합니다. 검증자는 결과물이 기준을 채웠는지 따로 확인하는 역할로, 규칙 검사 프로그램일 수도 있고 평가만 맡은 다른 AI일 수도 있습니다. 다만 모델의 자기 판단만 믿으면 과신하기 쉬우므로, 되도록 바깥에서 검증할 수 있는 신호를 종료 조건으로 삼는 편이 안전합니다.

최대 반복 횟수는 안전판입니다. 예컨대 열 번을 넘겨도 테스트가 통과하지 않으면 루프를 끊고 사람에게 넘깁니다. 이 한도를 너무 낮게 잡으면 풀 수 있는 문제도 중도에 포기하고, 너무 높게 잡으면 실패하는 문제에 자원을 쏟아붓습니다. 작업 성격에 맞춰 이 상한을 조절하는 일은 실무에서 되풀이해 손보게 되는 대목입니다. 재시도할 때 답이 얼마나 달라질지를 정하는 온도(temperature) 설정도 결과에 영향을 주는데, 단계마다 어떻게 잡는지는 글 끝 심화 절과 프롬프트 엔지니어링 글에 정리해 두었습니다.

컨텍스트 창을 어떻게 관리할 것인가

루프가 여러 번 돌면 매 반복의 사고와 관찰이 맥락(context)에 쌓입니다. 그런데 LLM이 한 번에 처리할 수 있는 토큰 수, 즉 컨텍스트 창(context window)에는 한계가 있습니다. 컨텍스트 창은 AI가 한 번에 펼쳐 놓고 볼 수 있는 책상 크기라고 생각하면 쉽습니다. 관찰을 무한정 붙이다 보면 창을 넘어서고, 넘지 않더라도 오래된 정보가 최신 판단을 흐립니다. 그래서 무엇을 남기고 무엇을 버릴지 정하는 맥락 관리가 루프 설계의 큰 축이 됩니다.

흔한 전략은 요약과 압축입니다. 지난 단계들의 상세 로그를 짧은 요약으로 갈아 끼우면 창을 아끼면서도 흐름을 유지할 수 있습니다. 회의를 열 번 했다고 열 번치 녹취록을 다 들고 다니지 않고, 회의록 요약 한 장만 챙기는 것과 같습니다. 또는 검색 증강 생성(RAG, Retrieval-Augmented Generation) 방식으로 필요한 정보만 그때그때 외부 저장소에서 끌어와 붙이기도 합니다. RAG는 AI가 답하기 전에 관련 문서를 먼저 찾아 읽게 하는 방법입니다. 모든 이력을 통째로 지고 다니는 대신, 지금 판단에 필요한 조각만 임베딩(embedding) 기반 검색으로 가져오는 것입니다. 임베딩은 글의 뜻을 숫자 목록으로 바꿔 둔 것으로, 단어가 달라도 뜻이 비슷한 글끼리 찾아낼 수 있게 해 줍니다.

장기 기억을 별도 저장소에 두는 방식도 있습니다. 루프가 만들어 낸 중간 결과나 결정을 외부 메모리에 적어 두고, 필요할 때 참조합니다. 이렇게 하면 짧은 컨텍스트 창의 제약 안에서도 긴 작업을 이어 갈 수 있습니다. 루프 엔지니어링과 메모리 설계, RAG는 실무에서 서로 뗄 수 없이 얽혀 있습니다.

흔한 오해와 실전에서 걸리는 함정

가장 흔한 오해는 '루프를 많이 돌리면 알아서 좋아진다'는 믿음입니다. 되먹임이 부실하면 반복은 오히려 오류를 키웁니다. 모델이 잘못된 관찰을 근거로 잘못된 판단을 내리고, 그것이 다시 맥락에 쌓여 다음 판단을 더 망칩니다. 이런 오류 누적을 막으려면 관찰의 품질을 관리하고, 필요하면 중간에 상태를 초기화하는 장치가 있어야 합니다.

두 번째 함정은 비용과 지연입니다. 루프 한 바퀴마다 LLM을 호출하므로 반복이 늘수록 비용과 응답 시간이 쌓이는데, 쌓이는 속도가 바퀴 수에 그대로 비례하지 않습니다. 바퀴마다 앞선 대화와 관찰을 모두 다시 읽혀야 하므로, 뒤로 갈수록 한 바퀴에 읽히는 분량 자체가 커지기 때문입니다. 단순한 계산으로 보면, 처음 문제 설명이 2,000토큰이고 한 바퀴마다 1,000토큰씩 기록이 늘어난다고 할 때 열 바퀴 동안 모델이 읽는 양은 모두 6만 5,000토큰으로, 한 번 부를 때(2,000토큰)의 서른 배가 넘습니다. 그래서 열 바퀴 도는 에이전트는 단발 호출보다 열 배가 아니라 그보다 훨씬 비싸질 수 있습니다. 앞부분이 같은 입력을 할인해 주는 프롬프트 캐싱 같은 장치로 부담을 줄일 수는 있지만, 종료 조건과 최대 반복 한도를 촘촘히 잡지 않으면 성능은 조금 오르는데 비용만 크게 불어나는 상황이 벌어집니다. Anthropic도 에이전트 방식은 더 나은 결과를 얻는 대가로 시간과 비용을 더 쓰는 선택이므로, 그 맞바꿈이 맞는 작업인지 먼저 따져 보라고 권합니다.

세 번째는 모델의 자기 평가를 지나치게 믿는 것입니다. 모델에게 '다 됐느냐'라고 물으면 실제로 안 됐어도 됐다고 답하는 과신이 자주 나타납니다. 종료 판정과 검증은 되도록 모델 바깥의 객관적 신호에 맡겨야 합니다. 테스트 통과 여부, 규칙 기반 검사, 별도 검증 모델 같은 외부 근거가 자기 보고보다 훨씬 믿을 만합니다. 보고서 예에서 숫자 대조를 AI의 판단이 아니라 프로그램에 맡긴 것도 같은 이유입니다.

더 깊이 파고들기 위한 길잡이

루프 엔지니어링을 제대로 익히려면 먼저 프롬프트 엔지니어링의 기본기를 다져야 합니다. 제로샷(zero-shot)과 퓨샷(few-shot) 프롬프팅, 사고 사슬, ReAct 같은 기법은 루프의 각 단계를 채우는 재료입니다. 제로샷은 예시 없이 지시만 주는 방식이고, 퓨샷은 원하는 답의 예시를 몇 개 먼저 보여 주는 방식입니다. 특히 ReAct는 추론과 행동을 엮는 방식이라 루프 구조를 이해하는 출발점으로 알맞고, 고쳐 쓰기 루프에 관심이 있다면 Self-Refine과 Reflexion 논문을 다음으로 읽으면 좋습니다.

그다음은 에이전트 아키텍처와 도구 사용(tool use, function calling)입니다. 모델이 외부 함수를 호출하고 그 결과를 받아 다음 판단에 쓰는 흐름을 이해하면, 루프 안에서 '행동'이 어떻게 실제 세계와 맞닿는지 감이 잡힙니다. 여기에 RAG와 임베딩 기반 메모리를 더하면 긴 작업을 다루는 큰 그림이 완성됩니다.

마지막으로 평가와 관측 가능성(observability)을 함께 공부하길 권합니다. 관측 가능성은 프로그램이 돌아가는 동안 무슨 일이 일어났는지 기록을 남겨 나중에 들여다볼 수 있게 하는 것을 말합니다. 루프가 어디서 헛도는지, 어느 단계에서 비용이 새는지, 어떤 관찰이 판단을 망치는지를 추적하지 못하면 개선할 수 없습니다. 각 반복의 사고와 행동을 로그로 남기고 분석하는 습관이 결국 좋은 루프 엔지니어와 그렇지 못한 엔지니어를 가릅니다.

실전에 적용하려면

루프를 실제 제품 품질로 안정화하려면 종료 조건 설계, 실패 복구, 컨텍스트 관리를 함께 다뤄야 합니다. 젠아이랩스(GenAI Labs)의 MCP Agent 솔루션이 이 루프를 기업 업무에 맞게 구축해 드립니다.

개발자를 위한 심화

이 부분은 직접 구현하는 개발자를 위한 내용입니다.

코드로 보는 최소 루프 골격

간단한 코드 수정 에이전트의 루프를 의사코드로 그려 보면 구조가 또렷해집니다. 의사코드는 실제로 실행되는 코드가 아니라, 흐름만 알아보기 쉽게 프로그램 모양으로 적은 설명입니다.

아래는 핵심 흐름만 남긴 골격으로, '판단 → 도구 실행 → 종료 검사 → 결과 되먹임'을 최대 MAX_STEPS번 반복하는 파이썬 모양의 의사코드입니다.

context = 초기_문제_설명
for step in range(MAX_STEPS):
    plan = llm(context, temperature=0.7)   # 사고: 무엇을 할지 판단
    action = parse_action(plan)            # 행동 파싱
    result = run_tool(action)              # 도구 실행(테스트, 검색 등)
    if is_done(result):                    # 종료 조건 검사
        break
    context += f"\n[판단]\n{plan}\n[관찰]\n{result}"   # 판단과 관찰을 맥락에 되먹임

여기서 눈여겨볼 점이 셋입니다. 첫째, 모델이 내린 판단(plan)과 run_tool의 결과가 함께 context에 붙어 다음 llm 호출의 입력이 됩니다. 모델은 자기가 무엇을 하려 했고 그 결과가 어땠는지를 나란히 보고 다음 판단을 내립니다. 이 되먹임이 루프의 핵심입니다. 둘째, is_done이 반복마다 종료를 판정하고, MAX_STEPS가 무한 루프를 막습니다. 셋째, 매번 맥락이 길어지므로 어느 시점부터는 오래된 관찰을 요약하거나 잘라내는 관리가 필요합니다. 셋째 점이 곧 앞에서 말한 비용 문제의 원인이기도 합니다. context가 커질수록 매 llm 호출의 입력 토큰이 늘어, 전체 입력량은 반복 횟수에 비례하는 것보다 빠르게 커집니다.

실제 프레임워크에서는 이 골격 위에 도구 정의, 오류 처리, 재시도 정책, 로그 저장이 얹힙니다. 그러나 아무리 복잡해져도 근본 구조는 이 '사고-행동-관찰-종료 검사'의 반복에서 벗어나지 않습니다. 루프 엔지니어링을 배운다는 것은 이 뼈대를 자기 문제에 맞게 살찌우는 법을 익히는 일입니다.

샘플링 파라미터를 단계별로 나누기

실무에서는 '탐색 단계는 온도를 높여 여러 후보를 뽑고, 검증 단계는 온도를 낮춰 안정적으로 판정한다'는 식으로 단계마다 파라미터를 달리 줍니다. 온도가 0에 가까우면 관찰이 그대로인 한 몇 번을 돌려도 거의 같은 출력이 나와 재시도의 의미가 줄어듭니다. 한 응답의 최대 길이를 정하는 max_tokens도 루프에서는 비용 상한과 바로 이어지므로, 검증 단계처럼 짧은 판정만 필요한 호출에는 작게 잡습니다. 각 파라미터의 자세한 뜻은 프롬프트 엔지니어링 글을 참고하세요.