도대체 루프가 뭔데?

게시일: 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회 돌렸습니다. 출시된 사례는 Meta의 Brain2Qwerty v2로, 6월 말에 발표되었는데, 연구진의 보고에 따르면 에이전트들이 코드베이스를 반복적으로 수정해 더 나은 디코딩 아키텍처를 발명했고, 단어 오류율에서 상당한 개선을 이뤄냈습니다. Meta가 덧붙인 단서가 시사적입니다. 최종 학습 설정은 여전히 사람이 직접 골랐다는 것입니다. 최고 수준의 시스템 루프조차 마지막 체크포인트에는 인간을 남겨 둡니다.

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

• • •

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

원문 보기

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

같은 주에 나온 유명한 패턴 하나가 이 지도에서 의도적으로 빠져 있습니다. Cognition의 Devin Security Swarm은 범위가 제한된 에이전트들을 저장소 전체에 병렬로 퍼뜨린 뒤 그 결과를 취합하는데, 그들은 이 형태를 에이전틱 맵리듀스 (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가 만들어진 이유입니다.

• • •

당신은 어떤 루프를 만들고 있나요?

이제 루프들에 이름이 붙었으니, 바로 그것이 던져야 할 질문입니다. 이번 달 ‘루프’라는 단어는 혼자서 너무 많은 의미를 떠맡고 있습니다. 이 분야는 다음 유행에 올라타는 것을 무엇보다 사랑하니까요. 하지만 네 가지 루프 모두의 밑바탕에는 실제 실천이 있고, 그 실천은 넷 모두에서 동일합니다. 사람들은 자신의 추상화 수준을 끌어올리고, 인간의 판단을 스택 위쪽으로 밀어 올리고 있습니다. 그것이 루프의 진짜 교훈입니다. 우리는 스택을 타고 올라감으로써 더 많은 일을 해냅니다. 그리고 이제 지도가 생겼으니, 어디로 올라가야 할지도 알게 되었습니다.