도대체 루프가 뭔데?

게시일: 2026년 7월 4일 | 원문 작성일: 2026년 7월 4일 | 저자: Laurie Voss | 원문 보기

• • •

AI 엔지니어링 업계가 이번 달 새로 꽂힌 단어가 하나 있습니다. 그런데 이 단어, 뜻이 최소 네 가지입니다. 바로 루프(loop)입니다.

우리는 지금 하이프 사이클의 정점에 있습니다. 6월 7일, 🦄 Peter Steinberger는 이제 코딩 에이전트에게 프롬프트를 줄 게 아니라, 에이전트에게 프롬프트를 주는 루프를 설계해야 한다는 글을 올렸습니다. 같은 주에 Anthropic의 Boris Cherny는 무대에 올라, 자신은 더 이상 Claude에게 프롬프트를 주지 않는다며 이렇게 말했습니다.

Addy Osmani는 6월 7일 Loop Engineering이라는 에세이를 발표했고, swyx1는 6월 12일 Loopcraft: The Art of Stacking Loops를, LangChain은 6월 16일 The Art of Loop Engineering을 발표했습니다. 그러고 나서 AI Engineer World’s Fair가 열렸고, 이 단어가 메인 무대를 휩쓸었습니다. swyx는 Loopcraft를 주제로 키노트를 했고, 트랙 하나는 통째로 소프트웨어 팩토리만 다뤘으며, 연사들도 줄줄이 같은 단어를 꺼내 들었습니다. 그리고 7월 2일, 컨퍼런스는 루프를 둘러싼 하이프가 실전에서 통하는 수준을 앞질러 버린 게 아닌지 따지는 한 시간짜리 토론으로 막을 내렸습니다.

문제는 루프를 이야기하는 사람들이 같은 것을 논하고 있지 않다는 점입니다. 저는 그 한 단어 뒤에 숨어 있는 서로 다른 아키텍처를 최소 네 가지 세어 보았습니다. 그래서 이 글에서는 사람들이 이 단어로 저마다 무엇을 가리키는지 지도로 그려 보려 합니다.

1. 실행 루프: 에이전트 자신의 행동-관찰 사이클

”에이전트”라고 하면 대부분의 사람이 이 루프를 떠올립니다. 도구를 호출하고, 결과를 읽고, 다음 행동을 결정하고, 더 이상 호출할 도구가 없을 때까지 반복합니다. Addy가 내부 실행 루프 (inner execution loop)라고 부르는 것으로, 이제 에이전트가 대체로 혼자서 돌릴 수 있게 된 부분입니다. 여러분이 엔지니어링할 수 있는 루프 가운데서는 가장 안쪽에 있습니다(swyx의 스택에는 토큰 루프도 있지만, 토큰 루프는 아무도 설계하지 않습니다. 그건 그냥 모델의 일부니까요).

원문 보기

실행 루프는 하나의 태스크 안에서 단계들을 반복합니다. 이 루프는 환경에서 피드백이 오면 끝납니다. 테스트 출력이나 API 응답, 파일 내용이 그런 피드백입니다. 인간은 보통 루프가 도는 동안에는 자리에 없고, 계획을 승인하거나 결과를 검토하는 경계 지점에서만 나타납니다. 또 에이전트가 스스로 다 끝냈다고 판단하면, 실제로 끝냈든 아니든 이 루프는 끝나 버립니다. 이 문제를 풀려고 업계가 처음 찾아낸 방법은, 에이전트의 말을 곧이곧대로 믿지 않는 또 다른 루프로 이 루프를 감싸는 것이었습니다.

2. 태스크 루프: 스펙이 충족될 때까지 에이전트를 재시작하라

가장 먼저 이름을 얻은 루프는 Geoffrey Huntley의 랄프 루프 (Ralph Loop)2입니다. AI Engineer World’s Fair 메인 무대에서도 이 이름이 나왔는데, Keycard의 Allie Howe가 소프트웨어 팩토리 트랙을 소개하면서 그의 글 everything is a ralph loop를 인용했습니다. 랄프 루프는 같은 명세(스펙)를 주고 코딩 에이전트를 몇 번이고 다시 시작합니다. 반복할 때마다 완전히 새로운 컨텍스트 윈도를 할당하고, 루프 한 번에 정확히 하나의 태스크만 수행합니다. 낭비처럼 보이는 그 부분이 핵심입니다. 매번 전체 스펙을 다시 먹이면, 오래 도는 세션의 품질을 소리 없이 떨어뜨리는 컨텍스트 부패 (context rot)3와 컴팩션 이벤트를 막을 수 있기 때문입니다.

이 루프가 반복하는 대상은 하나의 산출물이고, 스펙을 지키고 테스트를 통과하면 루프가 끝납니다. 인간은 스펙을 쓰고 완료 여부를 판정합니다. Geoffrey의 설명에 따르면 인간이 할 일이 하나 더 있습니다. 뒤에서 다시 다루겠지만, 루프를 지켜보다가 실패 패턴을 찾아내고, 그 실패가 다시는 일어나지 않게 고치는 일입니다. 컨퍼런스 마지막 날 폐막 토론에서 그는 이 역할을 열차 기관사에 비유했습니다. 기차가 선로를 벗어나지 않게 지키는 것이 업무의 전부인 사람이죠. 그런데 스펙 하나에서 시야를 넓히면 훨씬 더 큰 루프가 보입니다. 코드베이스 전체를 돌리는 루프입니다.

3. 프로덕트 루프: 소프트웨어 팩토리

AI Engineer World’s Fair에서 가장 목소리가 컸던 버전이 이것입니다. Factory의 Tereza Tizkova는 소프트웨어 팩토리를 “루프 전체, 즉 자율적으로 소프트웨어를 개발하는 라이프사이클 전체”라고 정의했고, Warp의 Zach Lloyd는 Latent Space와의 인터뷰에서 그 라이프사이클이 무엇인지 구체적으로 짚었습니다. 트리아지, 명세, 구현, 리뷰, 검증, 배포, 그리고 모니터링입니다. Zach는 소프트웨어 엔지니어링이 팩토리 엔지니어링이 된다고 주장합니다. 여러분은 제품을 만드는 무언가를 만들게 된다는 것이죠. Warp는 이 방식을 스스로 먼저 써 보는 도그푸딩 (dogfooding)4을 하고 있습니다. 오픈소스로 공개한 자기네 저장소를 자사 팩토리 플랫폼인 Oz의 통제 아래 둔 것입니다. Zach가 설명하는 도입 경로는 저위험 저장소에서 출발해, 자동 PR 병합 비율을 20퍼센트에서 60퍼센트 쪽으로 단계적으로 끌어올리는 것입니다. Anthropic도 내부에서 같은 실험을 하고 있는 것으로 보입니다. 회사 측은 제품 팀 코드의 65퍼센트가 이제 Claude Tag의 사내 버전으로 만들어진다고 밝혔고, Mike Krieger는 World’s Fair에서 자기 팀의 사용 방식을 ‘위임형이며 능동적’이라고 표현했습니다. “이 버그를 고쳐라”가 아니라, 코드베이스의 이 부분을 책임지고 이 피드백 채널을 모니터링하며 태스크는 알아서 집어 들라는 식입니다.

태스크 루프와 실행 루프에는 정해진 종료 조건이 있습니다. 반면 프로덕트 루프는 코드베이스와 백로그를 대상으로 계속해서 반복하며, 종료 신호는 새로운 이슈, 프로덕션 로그, 사용자 피드백, 리뷰 결과처럼 전부 코드베이스 바깥에서 옵니다. 인간이 맡는 역할은 이제 설정하기 나름입니다. Zach의 구도에서는 라이프사이클 중 어디를 자동화하고 어느 지점에서 인간을 불러들일지 여러분이 고릅니다. 고위험 변경의 코드 리뷰를 계속 인간이 맡을지 같은 문제에서는 조직마다 답이 갈립니다. 팩토리는 제품을 개선합니다. 다음 루프는 팩토리 자체를 개선합니다.

4. 시스템 루프: 오토리서치

Introspection의 Roland Gavrilescu는 이것을 오토리서치 (autoresearch)라고 부르는데, Latent Space 인터뷰에서 그가 내놓은 정리가 가장 깔끔합니다. 내부 루프는 사용자 대면 작업을 하는 여러분의 주 시스템이고, 외부 루프는 그 주 시스템을 연구하고 유지보수합니다. 이 루프는 프롬프트, 하네스, 모델 선택, 그리고 평가(evals) 자체를 반복적으로 개선합니다. 그의 한 줄 요약은 이렇습니다. 루프가 곧 제품이다.

이 패턴에는 이제 규모의 양 극단에서 실제로 돌아가는 증거 사례가 있습니다. 최소 사례는 Andrej Karpathy가 2026년 3월에 만든 오토리서치입니다. 파이썬 약 630줄로 된 이 코드는 GPU 한 장으로 하룻밤 사이에 가설-수정-평가 실험을 50회 돌렸습니다. 실제로 출시된 사례는 6월 말에 발표된 Meta의 Brain2Qwerty v2입니다. 연구진은 에이전트들이 코드베이스를 거듭 고쳐 가며 더 나은 디코딩 아키텍처를 고안해 냈고, 그 결과 단어 오류율이 크게 낮아졌다고 보고했습니다. Meta가 덧붙인 단서가 시사적입니다. 최종 학습 설정은 여전히 사람이 직접 골랐다고 합니다. 간판격인 시스템 루프에서조차 마지막 체크포인트는 인간이 지키고 있습니다.

이 루프를 끝내는 신호들은 네 루프 가운데 가장 까다롭습니다. 평가, 심판(judges), 필터링된 제품 피드백이 여기에 해당하고, Roland의 설계에는 명시적인 ‘인간에게 물어보기’ 도구까지 들어갑니다. 에이전트는 이 도구로 사람에게 물어 가며, 신입 사원이 그러듯 암묵지를 쌓아 갑니다. 그리고 여기가 스택의 꼭대기입니다. 네 가지를 한데 놓고 보면 전체 시스템의 모양이 보이기 시작합니다.

• • •

네 가지 루프를 나란히 놓고 보면

원문 보기

에이전틱 맵리듀스는 어디에?

같은 주에 나온 유명한 패턴 하나를 저는 이 지도에서 일부러 뺐습니다. Cognition의 Devin Security Swarm은 범위가 제한된 에이전트들을 저장소 전체에 병렬로 퍼뜨린 뒤 그 결과를 취합합니다. Cognition은 이 형태를 에이전틱 맵리듀스 (Agentic MapReduce)5라고 부르는데, 이것도 루프라고들 합니다. 저는 이것이 루프가 아니라고 생각합니다. 분배하고, 모으고, 검증하는 흐름은 파이프라인입니다. 다음 사이클로 되먹임되는 것이 하나도 없으니까요. 피드백 없는 루프는 그냥 for 문일 뿐입니다. 팬아웃(fan-out)은 네 가지 루프 중 어디에든 배치할 수 있는 토폴로지이지, 그 자체로 하나의 루프는 아닙니다.

맨 위의 이름 없는 루프는 감독 루프다

swyx의 루프 다이어그램에서 가장 바깥쪽 고리, 즉 루프를 만드는 루프 위에 있는 고리에는 말 그대로 ”???? loop”라는 라벨이 붙어 있습니다. 그 고리가 하는 일로는 목표 설정, 자원 배분, 솎아내기(cull)가 적혀 있습니다. 종료 조건란에는 ‘없음’이라고 되어 있습니다.

저는 그 루프에 이름이 있다고 생각합니다. 제가 붙인 이름은 감독 루프(oversight loop)입니다. 목표를 정하고, 예산을 배분하고, 작업을 솎아 내는 곳이며, 인간이 머물러야 할 단 하나의 고리입니다.

주체성이야말로 감독 루프가 쥐고 있는 것입니다.

원문 보기

그리고 AIEWF에서 가장 첨예했던 의견 충돌들은, 뜯어 보면 전부 그 최상위 고리를 누가 돌리느냐를 둘러싼 논쟁이었습니다. Zach와 Roland는 다이얼을 올리자는 쪽입니다. 체크포인트를 의도적으로 고르고, 신뢰가 쌓이는 만큼 자율성을 단계적으로 높여 가자고 합니다. Roland의 인상적인 구분을 빌리면, 팩토리보다 오케스트라를 먼저 꾸려야 합니다. 여기서 오케스트라란 인간 지휘자를 두는 시스템입니다. 반대 진영은 다이얼에 더 돌릴 수 없는 한계가 있다고 말합니다. Notion의 Geoffrey Litt는 X에서 팩토리를 우울한 비전이라고 불렀고, 이후 에세이로 발표한 강연에서 이해를 위임하는 사람은 에이전트에게 대체된다고 주장했습니다. Paul Bakaus는 더없이 단호하게 잘라 말했습니다. “auto는 없습니다. 앞으로도 없을 겁니다.” 그는 품질뿐 아니라 주인 의식도 근거로 듭니다. 사람에게는 목적이 필요하고, 자기가 만드는 것에 한몫하고 싶어 한다는 이유에서입니다.

Latent Space의 컨퍼런스 리포트에도 실린 폐막 토론에서는 두 입장이 한 무대에 섰습니다. HumanLayer의 Dex Horthy는 자신이 루프 반대론자가 아니라는 점을 애써 강조하며, 쿠버네티스도 컨트롤 루프 위에 세워져 있지만 그것은 결정론적 루프라고 지적했습니다. 그는 열광이 엔지니어링을 앞질러 버렸다고 우려했고, 추상화 수준을 올리지 말고 오히려 한 단계 내려가라고 조언했습니다. Geoffrey는 반대편에 서서 루프는 필연이라고 말했습니다. 그리고 Mike는 가장 정직한 데이터 포인트를 내놓았습니다. Anthropic 내부에서조차 Tag를 운영하는 팀은 리뷰에서, 그리고 시스템이 무엇을 하고 있는지 사람이 머릿속에 그려 내는 능력에서 병목에 걸린다고 합니다. 인간이 자신을 위해 남겨 둔 체크포인트가 이제 제약이 되었습니다.

자율성은 네 가지 루프 각각에 별도로 존재하는 다이얼입니다. 사람이 촘촘히 감독하는 프로덕트 루프 안에서 완전 자율 실행 루프를 돌릴 수 있습니다. 목표 설정은 전적으로 인간이 하면서 시스템 루프는 에이전트에게 넘길 수도 있습니다. 흥미로운 엔지니어링 질문은 어느 진영이 이기느냐가 아니라, 각 다이얼을 올바르게 맞추려면 어떤 정보가 필요한지입니다.

위의 표는 그 빈칸을 제 나름대로 채워 본 것입니다. 맨 위의 루프를 포함해 모든 루프에는 이름 붙일 수 있는 종료 조건이 있고, 맨 위 루프의 종료 조건은 여러분 자신입니다. 하지만 신호에 이름을 붙이는 것과 그 신호를 실제로 연결해 넣는 것은 다른 일입니다. 신호가 없는 루프는 수렴하지 않습니다. 바깥의 무언가가 멈춰 세울 때까지 그냥 돌아갈 뿐입니다. 프로덕션 규모에서 여러분의 루프가 실제로 닫히고 있는지 알려면, 트랜스크립트를 이따금 뽑아 확인하는 대신 트레이스를 훑고 실패를 지속적으로 클러스터링해야 합니다. 딱 그 일을 하라고 만든 도구가 Arize AX입니다.

• • •

여러분은 어떤 루프를 만들고 있나요?

루프마다 이름이 붙었으니 이제 이 질문을 던져야 합니다. 다음 유행에 올라타는 일만큼 이 분야 사람들이 좋아하는 것도 없다 보니, 이번 달 ‘루프’라는 단어는 혼자서 너무 많은 의미를 떠맡고 있습니다. 하지만 네 루프의 밑바탕에는 사람들이 실제로 하고 있는 일이 깔려 있고, 그 일은 넷 다 똑같습니다. 사람들은 자신의 추상화 수준을 높이고, 인간의 판단을 스택 위쪽으로 밀어 올리고 있습니다. 그것이 루프의 진짜 교훈입니다. 우리는 스택을 타고 올라가는 방식으로 더 많은 일을 해냅니다. 그리고 이제 여러분에게는 지도가 있으니, 어디로 올라가야 할지도 알 수 있습니다.