그래서 루프가 대체 뭔데?
TMT이번 달 AI 엔지니어링 업계에 새로 유행하는 단어가 하나 생겼는데, 그 뜻이 적어도 네 가지나 됩니다: 바로 루프(loop)입니다.
지금 우리는 하이프 사이클의 정점에 있습니다. 6월 7일 Peter Steinberger는 이제 코딩 에이전트에 직접 프롬프트를 넣을 게 아니라, 에이전트에 프롬프트를 넣어주는 루프를 설계해야 한다는 글을 올렸습니다. 같은 주에 Anthropic의 Boris Cherny는 무대에서 자신은 더 이상 Claude에 프롬프트를 쓰지 않는다며 이렇게 말했습니다: "저는 루프를 짜고, 일은 루프가 합니다." Addy Osmani는 6월 7일 Loop Engineering이라는 에세이를 냈고, swyx는 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의 스택에는 토큰 루프도 있지만, 토큰 루프는 누가 설계하는 게 아니라 그냥 모델의 일부입니다).
swyx의 Loopcraft 다이어그램
실행 루프는 하나의 작업 안에서 단계 단위로 반복합니다. 종료 신호는 환경 피드백입니다: 테스트 출력, API 응답, 파일 내용 같은 것들이죠. 사람은 보통 루프 중간에는 빠져 있다가 경계에서만 등장해 계획을 승인하거나 결과를 검토합니다. 또 이 루프는 실제로 끝났든 아니든 에이전트가 끝났다고 판단하는 순간에도 종료됩니다. 업계가 이 문제에 처음 내놓은 해법은, 에이전트의 말을 곧이곧대로 믿지 않는 또 하나의 루프로 이 루프를 감싸는 것이었습니다.
2. 작업 루프: 스펙이 충족될 때까지 에이전트를 재시작
이름이 붙은 첫 번째 루프로, Geoffrey Huntley의 Ralph 루프입니다. Keycard의 Allie Howe가 소프트웨어 팩토리 트랙을 소개하면서 그의 글 everything is a ralph loop를 인용해, AI Engineer World's Fair 메인 무대에서 직접 언급되기도 했습니다. Ralph 루프는 같은 스펙을 놓고 코딩 에이전트를 계속 재시작합니다. 반복할 때마다 완전히 새 컨텍스트 윈도를 할당하고, 루프 한 번에 정확히 하나의 작업만 수행합니다. 겉보기엔 낭비 같지만 그게 핵심입니다: 매번 스펙 전체를 다시 넣어주면, 장시간 세션을 슬그머니 망가뜨리는 컨텍스트 부패(context rot)와 컴팩션 이벤트를 막을 수 있습니다.
이 루프가 반복 대상으로 삼는 것은 산출물 하나입니다. 루프를 끝내는 것은 스펙 준수와 테스트 통과입니다. 사람은 스펙을 쓰고 완료 여부를 판정하는데, Geoffrey의 설명에 따르면 사람에게는 한 가지 일이 더 있습니다(뒤에서 다시 다루겠습니다): 루프를 지켜보다 실패 패턴을 찾아내고, 다시는 반복되지 않게 고치는 일입니다. 컨퍼런스 마지막 날 폐막 토론에서 그는 이 역할을 기관사에 비유했습니다. 기차가 선로를 벗어나지 않게 하는 것이 업의 전부인 사람 말이죠. 하지만 스펙 하나에서 시야를 넓히면 훨씬 큰 루프가 눈에 들어옵니다: 코드베이스 전체를 굴리는 루프입니다.
3. 제품 루프: 소프트웨어 팩토리
AI Engineer World's Fair에서 가장 목소리가 컸던 버전입니다. Factory의 Tereza Tížková는 소프트웨어 팩토리를 "루프 전체, 즉 자율성을 갖고 소프트웨어를 개발하는 라이프사이클 전체"라고 정의했고, Warp의 Zach Lloyd는 Latent Space 인터뷰에서 그 라이프사이클이 무엇인지 구체적으로 짚었습니다: 분류(triage), 스펙 작성, 구현, 리뷰, 검증, 출시, 모니터링. Zach의 주장은 소프트웨어 엔지니어링이 팩토리 엔지니어링이 되고, 앞으로는 제품이 아니라 제품을 만들어내는 것을 만들게 된다는 것입니다. Warp는 이걸 직접 자사에 적용해 보고 있습니다. 자사의 오픈소스 저장소를 자체 팩토리 플랫폼인 Oz의 관리 아래 두었고, Zach가 설명하는 도입 경로는 위험이 낮은 저장소부터 시작해 자동 PR 머지 비율을 20퍼센트에서 60퍼센트를 향해 단계적으로 끌어올리는 것입니다. Anthropic도 내부에서 같은 실험을 돌리고 있는 것으로 보입니다. 회사에 따르면 이제 제품팀 코드의 65퍼센트가 Claude Tag의 사내 버전으로 만들어지고 있고, Mike Krieger는 World's Fair에서 자기 팀의 사용 방식을 위임형이자 능동형이라고 설명했습니다: "이 버그 고쳐줘"가 아니라, 코드베이스의 이 부분을 책임지고, 이 피드백 채널을 모니터링하고, 할 일을 알아서 집어 가라는 식입니다.
작업 루프와 실행 루프에는 정의된 종료 조건이 있지만, 제품 루프는 코드베이스와 그 백로그를 놓고 끊임없이 반복하며, 종료 신호도 전부 코드베이스 바깥에서 옵니다: 새 이슈, 프로덕션 로그, 사용자 피드백, 리뷰 결과 같은 것들이죠. 사람의 역할은 설정 가능한 항목이 됩니다. Zach의 틀에서는 라이프사이클에서 자동화할 부분과 사람을 투입할 지점을 고르는 것이고, 위험이 큰 변경의 코드 리뷰를 계속 사람이 맡을지 같은 문제는 조직마다 답이 갈립니다. 팩토리는 제품을 개선합니다. 다음 루프는 팩토리 자체를 개선합니다.
4. 시스템 루프: 오토리서치
Introspection의 Roland Gavrilescu는 이것을 오토리서치(autoresearch)라고 부르는데, Latent Space 인터뷰에서 내놓은 그의 정리가 가장 깔끔합니다: 내부 루프는 사용자를 상대하는 일을 하는 주 시스템이고, 외부 루프는 그 주 시스템을 연구하고 유지보수합니다. 이 루프는 프롬프트, 하니스, 모델 선택, 그리고 평가(eval) 자체를 반복 개선합니다. 그의 한 줄 요약은 "루프가 곧 제품"이라는 것입니다.
이 패턴은 이제 규모의 양 극단에서 실제 사례로 증명되었습니다. 최소 사례는 2026년 3월 Andrej Karpathy의 오토리서치로, 대략 630줄짜리 Python이 GPU 한 장으로 하룻밤 사이 가설-수정-평가 실험을 50번 돌렸습니다. 실제 출시 사례는 6월 말 발표된 Meta의 Brain2Qwerty v2로, 연구진에 따르면 에이전트들이 코드베이스를 반복 수정하며 더 나은 디코딩 아키텍처를 고안해 냈고, 그 결과 단어 오류율이 크게 개선되었습니다. Meta가 달아둔 단서가 의미심장합니다: 최종 학습 설정은 여전히 사람이 골랐다는 것이죠. 대표급 시스템 루프조차 마지막 체크포인트에는 사람을 남겨둡니다.
이 루프를 끝내는 신호는 넷 중 가장 까다로운 조합입니다: 평가, 판정자(judge), 걸러낸 제품 피드백, 그리고 Roland의 설계에서는 명시적인 "사람에게 물어보기" 도구까지. 에이전트는 이 도구를 통해 신입 사원이 그러듯 암묵지를 쌓아갑니다. 여기가 스택의 꼭대기입니다. 네 루프를 한데 놓으면 시스템 전체의 모양이 보이기 시작합니다.
네 루프 나란히 보기
Agentic MapReduce는 어디에?
같은 주에 유명해진 패턴 하나가 이 지도에서 일부러 빠져 있습니다. Cognition의 Devin Security Swarm은 범위가 한정된 에이전트들을 저장소 전체에 병렬로 흩뿌린 뒤 결과를 취합하는데, Cognition은 이 형태를 Agentic MapReduce라고 부르고, 사람들은 이걸 루프라고 부르곤 합니다. 저는 이게 루프가 아니라고 봅니다. 내보내고, 모으고, 검증하는 것은 파이프라인입니다: 어떤 것도 다음 사이클로 되먹임되지 않으며, 피드백 없는 루프는 그냥 for 문일 뿐입니다. 팬아웃은 네 루프 어디에든 배치할 수 있는 토폴로지이지, 그 자체로 하나의 루프는 아닙니다.
꼭대기의 이름 없는 루프는 감독 루프다
swyx의 루프 다이어그램에서 가장 바깥 고리, 그러니까 루프를 만드는 루프보다 위에 있는 그 고리에는 말 그대로 "???? loop"라는 라벨이 붙어 있습니다. 이 루프의 동사는 목표 설정, 자원 배분, 솎아내기이고, 종료 조건은 "없음"으로 적혀 있습니다.
저는 그 루프에 이름이 있다고 생각합니다. 감독 루프(oversight loop)라고 부르려 합니다: 목표가 정해지고, 예산이 배분되고, 일이 솎아지는 곳이며, 사람이 상주해야 할 단 하나의 고리입니다. Addy는 AIEWF 무대에서 이렇게 말했습니다: "안쪽 루프는 능력(capability)이고, 바깥쪽 루프는 주도권(agency)이다." 감독 루프가 쥐고 있는 것이 바로 그 주도권입니다.
종료 조건까지 이름 붙인 루프 스택. 각 고리의 화살표가 그 루프가 끝나는 지점입니다.
그리고 AIEWF에서 가장 첨예했던 의견 충돌들은, 뜯어보면 전부 그 꼭대기 고리를 누가 돌리느냐에 대한 논쟁이었습니다. Zach와 Roland는 다이얼을 올리자는 쪽입니다: 체크포인트를 의도적으로 고르고, 신뢰가 쌓이는 만큼 자율성을 단계적으로 높이고, Roland의 인상적인 구분을 빌리자면 팩토리보다 오케스트라를 먼저 지으라는 것입니다. 여기서 오케스트라란 사람 지휘자를 남겨두는 시스템을 말합니다. 반대 진영은 그 다이얼에 멈춤 지점이 있다고 말합니다. Notion의 Geoffrey Litt는 X에서 팩토리를 우울한 비전이라 불렀고, 이후 에세이로 발표한 강연에서 이해까지 위임하는 사람은 결국 에이전트에게 대체된다고 주장했습니다. Paul Bakaus는 이보다 단호할 수 없게 잘라 말했습니다: "자동은 없고, 앞으로도 없을 것이다." 그의 논거는 품질만의 문제가 아니라 주인의식의 문제입니다. 사람에게는 목적이 필요하고, 자신이 만드는 것에서 맡을 역할을 원한다는 것이죠.
Latent Space의 컨퍼런스 취재에 실린 폐막 토론은 두 입장을 한 무대에 올렸습니다. HumanLayer의 Dex Horthy는 자신이 루프 반대론자가 아니라는 점을 애써 강조하며, Kubernetes도 컨트롤 루프 위에 지어졌지만 그것은 결정론적 루프라고 짚었습니다. 그가 걱정하는 것은 열기가 엔지니어링을 앞질러 버렸다는 점입니다. 그의 조언은 추상화 수준을 올리지 말고 오히려 한 단계 내려가라는 것이었습니다. Geoffrey는 반대편에 서서 루프는 피할 수 없는 흐름이라고 했습니다. 그리고 Mike는 가장 솔직한 데이터 포인트를 내놓았습니다: Anthropic 내부에서조차 Tag를 운영하는 팀이 리뷰에서, 그리고 시스템이 뭘 하고 있는지 사람이 개념적으로 따라잡는 능력에서 병목을 겪고 있다고 합니다. 사람이 스스로를 위해 남겨둔 체크포인트가 이제는 제약이 된 것입니다.
자율성은 네 루프 각각에 따로 달려 있는 다이얼입니다. 촘촘히 감독하는 제품 루프 안에서 완전 자율 실행 루프를 돌릴 수도 있고, 목표 설정은 전적으로 사람이 쥔 채 시스템 루프만 에이전트에 넘길 수도 있습니다. 흥미로운 엔지니어링 질문은 어느 진영이 이기느냐가 아니라, 각 다이얼을 올바르게 맞추려면 어떤 정보가 필요하냐는 것입니다.
위 표는 그 빈칸을 채워보려는 제 시도입니다. 꼭대기 루프를 포함해 모든 루프에는 이름 붙일 수 있는 종료 조건이 있고, 꼭대기 루프의 종료 조건은 바로 당신입니다. 하지만 신호에 이름을 붙이는 것과 실제로 연결해 넣는 것은 다릅니다. 신호가 빠진 루프는 수렴하지 않고, 외부에서 뭔가가 멈춰줄 때까지 그냥 돕니다. 프로덕션 규모에서 루프가 실제로 닫히고 있는지 알려면, 대화 기록을 띄엄띄엄 뽑아보는 대신 트레이스를 훑고 실패를 지속적으로 클러스터링해야 하는데, 그게 바로 Arize AX가 만들어진 이유입니다.
당신은 어떤 루프를 만들고 있나요?
이제 루프마다 이름이 생겼으니, 던져야 할 질문은 이것입니다. 이번 달 "루프"라는 단어는 과로 중입니다. 이 업계가 다음 유행에 올라타는 것만큼 좋아하는 일이 없으니까요. 하지만 네 루프 모두의 밑바탕에는 실제 실천이 있고, 그 실천은 넷 다 같습니다: 사람들은 자기 추상화 수준을 끌어올리고, 인간의 판단을 스택 위쪽으로 밀어 올리고 있습니다. 그것이 루프의 진짜 교훈입니다. 우리는 스택을 타고 올라갈수록 더 많은 일을 해내고, 이제 지도가 생겼으니 어디로 올라가야 할지도 알 수 있습니다.
공동 저자: @seldo
