coredot.today
루프를 쌓는 기술: LangChain이 그린 '4중 루프'와 스스로 진화하는 에이전트
블로그로 돌아가기
루프 엔지니어링loopcraftLangChain에이전트검증 루프이벤트 드리븐힐 클라이밍ReActReflexionLangSmith하네스AI 에이전트

루프를 쌓는 기술: LangChain이 그린 '4중 루프'와 스스로 진화하는 에이전트

LangChain의 글 한 편이 개발자 타임라인을 뒤흔들었다. '에이전트를 프롬프트하지 말고, 루프를 쌓아라(loopcraft).' 핵심은 네 개의 루프를 겹겹이 포개는 것 — 일하는 에이전트 루프, 채점하는 검증 루프, 스스로 깨어나는 이벤트 루프, 그리고 자기 자신을 고쳐 쓰는 힐 클라이밍 루프. ReAct(2022)와 Reflexion(2023)이라는 두 논문에서 뿌리를 찾고, LangChain의 '문서 봇' 사례로 네 루프가 하나로 포개지는 순간을 눈으로 확인한다. swyx의 'Salty Lesson'부터 2026년의 복리 효과까지, 용어가 생소해도 그림과 사례로 끝까지 쉽게.

코어닷투데이2026-07-0437

한 문장에서 시작하는 이야기

2026년 6월, LangChain의 시드니 렁클(Sydney Runkle)이 쓴 글 한 편이 개발자들 사이에서 화제가 됐다. 제목은 《The Art of Loop Engineering》(루프 엔지니어링의 기술). 핵심 주장은 놀랍도록 단순하다.

"에이전트가 강력해지는 건 모델이 똑똑해서가 아니다. 그 모델을 감싼 루프(loop)를 얼마나 잘 쌓았느냐로 결정된다."

루프를 쌓는 기술 — 네 개의 루프가 겹겹이 포개진 에이전트

이 문장이 낯설게 들린다면, 먼저 이렇게 바꿔 읽어보자. 우리는 지난 몇 년간 AI에게 더 좋은 질문(프롬프트) 을 던지는 법을 배웠고, 그다음엔 더 좋은 정보(컨텍스트) 를 떠먹이는 법을 배웠다. 그런데 2026년 현재, 가장 앞선 팀들은 질문도 정보도 아닌 "에이전트가 돌아가는 고리 그 자체" 를 설계하는 데 몰두하고 있다. 그 고리를 겹겹이 포개는 기술 — LangChain은 이것을 루프 엔지니어링, 그 뿌리를 만든 swyx(숀 왕)는 loopcraft(루프크래프트) 라고 부른다.

📌 이 글의 위치. 코어닷투데이는 앞서 《루프 엔지니어링 — 더 이상 에이전트에게 프롬프트하지 마라》에서 Addy Osmani의 관점으로 '루프를 이루는 다섯 가지 빌딩블록'을 다뤘다. 이번 글은 같은 주제를 LangChain이 정리한 '네 개의 루프' 프레임으로 다시 조명한다. 두 글은 겹치지 않고 이어진다 — 이쪽은 루프를 어떻게 겹쳐 쌓는가의 지도다.

이 글은 세 가지를 약속한다. 첫째, 왜 이 개념이 나왔는지를 역사와 논문에서부터 따라간다. 둘째, 네 개의 루프가 각각 무엇이고 어떻게 포개지는지를 그림과 사례로 푼다. 셋째, 2026년 지금 이 기술이 왜 중요한지 — 비용과 위험까지 솔직하게 짚는다. 용어가 생소해도 괜찮다. 하나씩, 천천히.

제1장: 왜 지금인가 — 프롬프트에서 하네스, 그리고 루프까지
제2장: loopcraft — '루프를 쌓는다'는 발상
제3장: 네 개의 루프 — 에이전트 · 검증 · 이벤트 · 힐 클라이밍
제4장: 아키텍처의 뿌리 — ReAct와 Reflexion 논문
제5장: 사례 — LangChain '문서 봇'에서 네 루프가 포개지다
제6장: 2026년 — 복리, 사람, 그리고 잘못된 채점표의 위험

제1장: 왜 지금인가 — 프롬프트에서 하네스, 그리고 루프까지

루프 엔지니어링이 왜 갑자기 튀어나왔는지 이해하려면, AI를 다루는 방식이 지난 4년간 어떻게 진화했는지를 봐야 한다. 업계는 이것을 세 개의 시대(three eras) 로 나눈다.

시대무엇을 다뤘나한 줄 요약
프롬프트 엔지니어링
2022–2024
역할 지정 · 예시 제공 · 말투 제약. "질문을 어떻게 던질까"모델에게 무엇을 할지 말한다
컨텍스트 엔지니어링
2025
맥락 창을 관련 문서·대화 이력·도구 정의·RAG 결과로 채우기모델에게 알아야 할 것을 준다
하네스 엔지니어링
2026
에이전트의 작업 흐름·제약·피드백 루프·툴체인·수명주기를 통째로 설계에이전트가 안정적으로 일을 해내는 환경을 만든다

프롬프트는 표현을 다듬고, 컨텍스트는 정보를 큐레이션한다. 하지만 완벽한 프롬프트도, 완벽한 정보도 "이 일을 끝까지, 실수 없이, 반복해서 해내는 능력" 은 보장하지 못한다. 그 마지막 조각을 채우는 것이 하네스(harness) — 에이전트를 감싸는 '작업 환경 전체'다. (하네스 개념 자체가 궁금하다면 《오토하네스 — LLM 코드 하네스》를 참고.)

그리고 루프 엔지니어링은 이 하네스 시대의 '운영 규율(operational discipline)' 이다. 하네스가 정적인 '환경'이라면, 루프는 그 환경 안에서 끊임없이 도는 동적인 고리다. LangChain의 표현을 빌리면:

"에이전트는 결국 모델이 도구를 부르며 작업이 끝날 때까지 도는 루프다. 이건 첫 번째 루프일 뿐이고, 가장 근본적인 루프일 뿐이다. 이 주위에 루프를 더 쌓으면 에이전트는 극적으로 더 믿음직하고, 더 확장 가능하고, 스스로 개선되는 존재가 된다."

핵심 단어는 "쌓는다(stack)" 이다. 루프는 하나가 아니다. 여러 개를 겹겹이 포갤 수 있다. 그것이 이 글의 주제다.


제2장: loopcraft — '루프를 쌓는다'는 발상

이 '쌓기'라는 발상의 원조는 AI 엔지니어 커뮤니티의 대부격인 swyx(숀 왕) 다. 그는 2026년 6월 AI Engineer World's Fair의 오프닝 강연 《Loopcraft: The Art of Stacking Loops(루프크래프트: 루프를 쌓는 기술)》 에서 지난 4년의 흐름을 이렇게 압축했다 — "채팅에서, 도구로, 목표로(from chat, to tools, to goals)." 그리고 지금의 초점은 자동화 — 크론잡과 루프 라고 못박았다.

swyx의 주장에서 가장 회자된 대목은 이른바 'Salty Lesson(짭짤한 교훈)' 이다. 이 이름은 강화학습의 대가 리처드 서튼의 유명한 'Bitter Lesson(쓰라린 교훈)'"인간의 지식을 억지로 집어넣는 것보다, 계산량으로 확장되는 일반적 방법이 결국 이긴다" — 를 에이전트 버전으로 비튼 것이다.

🧗
Bitter Lesson (모델의 교훈)
모델을 잘 만들려면 — 인간의 규칙을 손으로 넣지 말고, 계산량으로 확장되는 학습 방법에 맡겨라.
🔁
Salty Lesson (에이전트의 교훈)
에이전트를 잘 굴리려면 — 문제를 당신 손으로 고치지 말고, 더 많은 에이전트와 함께 확장되는 시스템(목표·오케스트레이션)에 맡겨라.
📈
그래서 loopcraft
"다음 세기의 게임 전체는, 루프를 얼마나 효과적으로 쌓을 수 있느냐에 달렸다." — swyx

swyx는 여기에 실전 감각을 하나 덧붙였다. 각 국면의 초기에는 언제 아래 루프로 내려갈지(go DOWN) 를 아는 것이 중요하다는 것 — 뭔가 어긋났을 때는 더 근본적인 안쪽 루프로 내려가 신뢰성을 확보하고, 시스템이 안정되면 바깥 루프로 올라가 능력을 키운다. 즉 루프 쌓기는 위로만 올라가는 게 아니라, 안팎을 오르내리는 기술이다.

LangChain의 시드니 렁클은 바로 이 loopcraft를 이어받아, 실무자가 곧장 쓸 수 있는 네 개의 층으로 정리했다. 이제 그 네 층을 하나씩 오르자.


제3장: 네 개의 루프

LangChain의 프레임은 러시아 인형(마트료시카)을 닮았다. 가장 안쪽에 '일하는 루프'가 있고, 그것을 '채점하는 루프'가 감싸고, 다시 '스스로 깨어나는 루프'가 감싸고, 마지막으로 '자기 자신을 고쳐 쓰는 루프'가 전체를 감싼다.

4중 루프 스택 — 안에서 밖으로
① 에이전트 루프 일을 한다 모델이 도구를 부르며 작업이 끝날 때까지 반복. 실제 작업을 실행하는 심장.
② 검증 루프 채점을 한다 채점기가 결과를 기준표(rubric)에 맞춰 평가하고, 미달이면 피드백과 함께 되돌려보낸다.
③ 이벤트 루프 스스로 깨어난다 문서가 도착하거나·일정이 되거나·웹훅이 오면 에이전트가 자동으로 실행된다.
④ 힐 클라이밍 루프 자기를 고쳐 쓴다 운영 기록(trace)을 분석 에이전트가 읽고, 반복되는 문제를 찾아 하네스 자체를 다시 쓴다.

이 순서에는 의미가 있다. ①→②는 이미 널리 자리 잡은 관행이고, 진짜 판을 바꾸는 곳은 ③과 ④ — 에이전트를 당신의 생태계 안에 심고, 그것이 당신의 기준에 맞춰 스스로 계속 나아지게 만드는 층이다. 하나씩 보자.

① 에이전트 루프 — 일을 하는 심장

가장 안쪽. "모델이 도구를 부르며, 작업이 끝날 때까지 도는 것." LangChain에서는 create_agent라는 한 줄짜리 기본 원시(primitive)가 이 고리를 만들어준다. 예를 들어 문서를 관리하는 에이전트라면, 요청을 받고 → 무엇을 바꿀지 계획하고 → 저장소를 복제하고 → 파일을 읽고 → 문서를 쓰고 → 풀 리퀘스트(PR)를 여는 식으로 도구를 차례로 부른다.

생각 → 행동 → 관찰: 에이전트 루프의 기본 박동

이 단순한 고리가 에이전트를 '체인(chain)'과 근본적으로 다르게 만든다. 체인은 정해진 순서를 따라가는 파이프라인이지만, 에이전트 루프에서는 매 바퀴마다 LLM이 '다음에 뭘 할지' 스스로 결정한다. 모델이 단순한 텍스트 변환기가 아니라 매 순간의 의사결정자가 되는 것 — 이 박동의 정확한 뿌리는 2022년의 ReAct 논문이고, 제4장에서 해부한다.

② 검증 루프 — 채점하는 감독관

에이전트 루프는 일을 해내지만, 첫 시도에 늘 올바르거나 일관된 결과를 내지는 않는다. 그래서 두 번째 루프가 등장한다. 결과를 채점기(grader) 로 감싸는 것이다.

생성
에이전트가 초안 결과를 만든다 (문서·코드·PR 등)
채점
채점기가 기준표(rubric)에 맞춰 점수를 매긴다 — 결정론적 테스트이거나, '판사 역할 LLM(LLM-as-a-judge)'
되돌림
기준 미달이면 무엇이 왜 부족한지 피드백과 함께 다시 에이전트에게 → 재시도

문서 봇의 경우 검증 루프는 이런 걸 자동으로 확인한다 — 링크가 실제로 연결되는가, CI가 통과하는가, 변경 범위(diff)가 요청한 선을 넘지 않는가. 사람이 일일이 눈으로 볼 필요 없이 기계가 먼저 거른다.

여기엔 대가가 있다. 검증 루프는 한 번 돌 때마다 지연과 비용을 더한다. 그래서 속도보다 품질이 중요한 작업일 때 값을 한다. 그리고 이 루프의 철학적 뿌리 — "코드를 쓴 모델이 자기 코드를 채점하게 두지 마라" — 는 2023년 Reflexion 논문에서 왔다. 이 역시 제4장에서 본다.

③ 이벤트 루프 — 스스로 깨어나는 상시 근무자

여기서부터 판이 바뀐다. 앞의 두 루프까지는 사람이 "실행"을 눌러야 돌아간다. 세 번째 루프는 그 방아쇠를 사람에게서 떼어낸다.

이벤트가 에이전트를 깨운다 — 알람 · 새 문서 · 웹훅

"이벤트가 발생하면 — 새 문서가 도착하고, 일정이 되고, 웹훅이 도착하면 — 에이전트가 실행된다."

이 전환의 의미를 LangChain은 이렇게 표현한다. 이벤트 루프는 "당신이 콕콕 찔러대던 도구(a tool you poke at)""더 큰 시스템 안에서 상시 돌아가는 부품(a component running continuously)" 으로 바꾼다. 크론 스케줄, 웹훅, 메시지 도착 — LangSmith Deployment와 Fleet 같은 인프라가 이 방아쇠들을 관리한다. 문서 봇의 경우, Slack 채널에 메시지가 올라오는 것이 곧 방아쇠다.

이벤트 루프에 대한 코어닷투데이의 별도 심층 해설은 《휴먼 인 더 루프》에서도 이어진다 — 상시 근무 에이전트일수록 사람이 개입하는 지점을 어디에 둘지가 더 중요해지기 때문이다.

④ 힐 클라이밍 루프 — 자기 자신을 고쳐 쓰는 루프

가장 바깥, 그리고 가장 혁신적인 층. 앞의 세 루프가 일을 개선했다면, 네 번째 루프는 개선하는 행위 자체를 자동화한다.

힐 클라이밍 — 매 사이클 지표를 읽고 한 계단씩 스스로 나아진다

'힐 클라이밍(hill climbing, 언덕 오르기)'은 최적화 이론에서 온 말이다. 현재 위치에서 조금씩 더 높은 쪽으로 발을 옮겨 정상에 다가가는 방법. 여기서 '언덕'은 에이전트의 성능이고, '한 걸음'은 하네스의 작은 수정이다.

작동 방식은 이렇다. 프로덕션에서 쌓인 실행 기록(trace)분석 에이전트가 읽는다. 그리고 반복되는 문제를 찾아내 — 프롬프트를 손보거나, 도구를 바꾸거나 — 하네스 자체를 다시 쓴다. LangChain은 이 메커니즘을 LangSmith Engine으로 구현했다. 이 층의 진짜 무서운 점은 되돌아오는 화살표의 방향이다.

"되돌아오는 화살표는 그저 맨 위로 되돌아가는 게 아니다. 그것은 안으로 손을 뻗어 에이전트 루프를 직접 고친다. 바깥 루프가 한 바퀴 돌 때마다, 안쪽 루프들이 더 효과적으로 변한다."

즉 ④가 한 번 돌면 ①②③이 더 좋아진다. 그리고 더 좋아진 ①②③은 더 나은 기록을 남기고, 그 기록이 다시 ④를 돌린다. 이것이 '복리(compounding)' 다 — 시스템이 정체되지 않고 시간이 갈수록 스스로 나아진다. Reflexion(제4장)이 한 작업 안에서 보여준 '말로 복기하는 자기개선'을, 힐 클라이밍 루프는 시스템 전체 수준으로 끌어올린 셈이다.


제4장: 아키텍처의 뿌리 — ReAct와 Reflexion

네 개의 루프는 하늘에서 떨어지지 않았다. ①과 ②의 골격은 각각 2022년과 2023년의 두 논문에 이미 다 들어 있었다. 용어가 생소하겠지만, 그림과 함께 천천히 보면 어렵지 않다.

4-1. ReAct(2022) — 에이전트 루프의 조상

ReAct"Reasoning + acting", 즉 추론과 행동을 하나로 엮은 것이다. 야오(Yao) 등이 2022년 발표했다(arXiv:2210.03629). 이전까지 LLM 활용은 두 갈래로 갈려 있었는데, ReAct 논문의 그 유명한 Figure 1 은 같은 질문을 네 방식으로 푸는 모습을 나란히 보여준다.

방식하는 일한계
(a) Standard그냥 답을 뱉음근거도 도구도 없음
(b) CoT — 추론만머릿속 단계별 생각(Chain-of-Thought)최신 정보가 없어 그럴듯한 거짓(환각)을 지어냄
(c) Act-only — 행동만위키피디아 검색 같은 도구 호출도구 결과를 제대로 해석·추론하지 못함
(d) ReAct — 추론+행동생각하고 → 도구 쓰고 → 결과 보고 → 다시 생각두 세계의 장점을 모두 가짐

핵심은 (d)다. ReAct는 생각(Thought) → 행동(Action) → 관찰(Observation) 을 한 단위로 묶어 반복한다.

Thought · 생각
"이 인물의 출생지를 알아야겠다. 위키를 검색하자."
Action · 행동
Search["인물 이름"] — 실제 위키피디아 API를 호출
Observation · 관찰
"검색 결과: …출생지는 X…" — 도구가 돌려준 사실

이 고리가 다시 "그럼 X를 한 번 더 찾아보자"는 다음 생각으로 이어진다. 그래서 ReAct는 환각을 줄이고(매 단계 실제 도구로 사실을 확인하니까), 사람이 따라 읽기 쉬운(생각이 글로 남으니까) 풀이를 만든다. 결과도 인상적이었다 — 상호작용형 의사결정 벤치마크 ALFWorld에서 기존 모방·강화학습 방법을 절대치 34%p 앞섰고, 예시를 한두 개만 주고도 그랬다.

LangChain의 ①에이전트 루프는 바로 이 생각-행동-관찰 고리의 직계 후손이다. ReAct가 한 작업 안의 작은 루프라면, 루프 엔지니어링은 그 위에 세 개를 더 쌓은 큰 루프다.

4-2. Reflexion(2023) — 검증 루프의 조상

ReAct가 "도구를 쓰며 생각하기"였다면, Reflexion(신Shinn 등, 2023, NeurIPS)은 한 발 더 간다. "이번에 왜 틀렸지?"를 스스로 말로 적어 다음 시도에 반영하는 루프다. 놀라운 점은 모델의 가중치를 전혀 바꾸지 않는다는 것 — 오직 언어로 된 피드백만으로 성능을 끌어올린다. 그래서 '언어적 강화학습(verbal reinforcement learning)' 이라 부른다.

Reflexion의 아키텍처는 세 개의 역할로 나뉜다. 이 분업이 오늘날 검증 루프와 '서브에이전트 분리'의 조상이다.

Actor · 행동가
실제 행동과 답을 생성하는 LLM. 내부적으로 CoT·ReAct를 쓴다 (정책 역할)
Evaluator · 평가자
생성된 궤적(trajectory)을 받아 성공/실패의 보상 점수를 매긴다
Self-Reflection · 성찰가
실패를 "무엇이·왜 잘못됐고 다음엔 어떻게"라는 로 변환
↓ 성찰 메모를 일화 기억(episodic memory)에 저장 → 다음 시도의 입력으로 ↓

돌아가는 방식은 하나의 고리다 — 과업 정의 → 궤적 생성 → 평가 → 성찰 → 다음 궤적 생성. 짧은 기억(현재 궤적)과 긴 기억(누적된 성찰)을 함께 굴리며, 파인튜닝 없이 시행마다 나아진다. 이 세 역할이 만든 핵심 원칙이 바로 검증 루프의 심장이다.

답을 쓴 모델이 자기 답을 채점하게 두지 마라. 코드를 작성한 모델은 자기 숙제에 너무 후한 점수를 준다. Reflexion은 평가를 분리해 이 편향을 깼다.

성과도 확실했다. ALFWorld에서 134개 과제 중 130개를 완수해 ReAct 단독을 크게 앞섰고, 코드 생성 벤치마크 HumanEval에서 약 91% 로 당시 최고 수준에 올랐다.

ReAct — ALFWorld 성공률 향상
+34%p
Reflexion — ALFWorld (130/134 과제)
97%
Reflexion — HumanEval 코딩 정확도
91%

▲ 두 논문의 대표 수치. ReAct는 '향상 폭(%p)', 나머지 둘은 '달성률(%)' 기준이라 절대 비교는 아님

두 논문이 루프 엔지니어링에 남긴 유산

  • ReAct → 생각-행동-관찰 고리 = ①에이전트 루프의 기본 박동
  • Reflexion → 메이커·체커 분리 + 외부 기억 = ②검증 루프와 ④힐 클라이밍의 씨앗

여기서 한 가지가 또렷해진다. Reflexion의 '일화 기억'은 오늘날 에이전트 메모리의 직접 조상이다. 기억이 어떻게 루프를 시간 너머로 이어주는지는 《AI는 어떻게 기억하는가》에서 깊게 다뤘다.


제5장: 사례 — '문서 봇'에서 네 루프가 포개지다

이론은 충분하다. 이제 네 개의 루프가 하나의 살아 있는 시스템으로 포개지는 순간을 보자. LangChain이 든 대표 사례는 자사의 문서 관리 에이전트('docs agent') 다. 개발자가 코드를 바꾸면 문서도 따라 바뀌어야 하는데, 그 지겨운 일을 봇이 대신한다.

문서 봇: Slack 요청 → 봇이 문서 작성·자가 검증 → PR 생성

③ 이벤트 루프
Slack의 #docs-plz 채널에 "이 기능 문서 좀"이라는 메시지가 올라온다. 이 메시지 도착이 곧 방아쇠 — 사람이 봇을 켜지 않아도 봇이 스스로 깨어난다.
① 에이전트 루프
봇이 저장소를 복제하고, 관련 파일을 읽고, 무엇을 바꿀지 계획하고, 문서를 고쳐 쓴 뒤 PR을 연다. 도구를 부르며 작업이 끝날 때까지 도는 심장.
② 검증 루프
자동 채점기가 확인한다 — 링크가 다 연결되는가, CI가 통과하는가, 변경 범위가 요청한 선을 넘지 않는가. 미달이면 피드백과 함께 ①로 되돌린다.
④ 힐 클라이밍 루프
쌓인 실행 기록을 분석 에이전트가 읽고, "이 봇이 자꾸 특정 유형 링크를 깨뜨린다"를 발견하면 봇의 프롬프트·도구를 스스로 손본다. 다음부터 ①②가 더 잘 돈다.

여기서 중요한 통찰 하나. 자동 채점기가 링크가 연결되는지는 확인할 수 있지만, '이 문서의 어조·프레이밍이 틀렸다'는 건 여전히 사람이 알아챈다. LangChain이 강조하는 대목이다.

"자동 채점기는 링크가 연결되는지 확인할 수 있다. 하지만 프레이밍이 잘못됐다는 걸 알아채는 건 사람의 몫이다."

그래서 네 루프 모두에 사람이 개입하는 체크포인트(human-in-the-loop) 가 자연스럽게 존재한다. 특히 돈이나 데이터베이스를 건드리는 되돌릴 수 없는 작업 앞에서는 반드시. loopcraft는 사람을 없애는 기술이 아니라, 사람이 '실행'이 아니라 '조종(steer)'에 집중하도록 자리를 옮기는 기술이다.


제6장: 2026년 — 복리, 사람, 그리고 잘못된 채점표의 위험

왜 지금 이것이 중요한가 — 복리 효과

2026년, 앞선 팀들이 loopcraft에 몰두하는 이유는 하나로 요약된다. 복리(compounding). 프롬프트나 컨텍스트를 아무리 잘 다듬어도 그것은 한 번의 개선이다. 하지만 힐 클라이밍 루프를 심으면, 시스템은 프로덕션 데이터를 먹으며 시간이 갈수록 스스로 나아진다. 정체(plateau)하지 않고 복리로 쌓인다.

마이크로소프트 CEO 사티아 나델라의 말을 빌려, LangChain은 이렇게 정리한다.

"학습 루프를 일찍 구축한 회사는 — 복제하기 어려운 우위를 쌓게 된다."

이것이 loopcraft가 단순한 개발 기법을 넘어 경영 전략이 되는 지점이다. 경쟁사가 더 좋은 모델을 사 오는 사이, 당신의 시스템은 당신의 데이터로만 만들어지는 개선의 언덕을 스스로 오른다.

하지만 — 잘못된 채점표라는 함정

루프를 쌓는 데는 대가와 위험이 따른다. LangChain과 해설자들이 입을 모아 경고하는 지점을 솔직하게 짚는다.

얻는 것치르는 것 / 위험
층마다 신뢰성·자율성·자기개선이 올라간다층마다 지연(latency)과 비용이 붙는다
상시 백그라운드 운영상당한 인프라 투자가 필요하다
복리로 쌓이는 개선기준표(rubric)가 잘못되면 — 시스템은 신나게 엉뚱한 목표로 최적화된다

마지막 줄이 핵심이다. 힐 클라이밍 루프는 '언덕을 오르는' 기술인데, 당신이 잘못된 언덕을 가리키면 시스템은 그 잘못된 정상까지 아주 효율적으로 올라가 버린다. 채점표가 '링크가 깨지지 않는 것'만 본다면, 봇은 어조가 엉망이어도 링크만 멀쩡한 문서를 양산하도록 진화한다. 자동화가 강력할수록, 무엇을 채점하는가가 무엇보다 중요해진다.

비용 폭주·보안(자율 루프 + 외부 연결의 '치명적 삼각편대')·주니어 파이프라인의 소멸 같은 더 어두운 논쟁은 코어닷투데이의 후속편 《루프 엔지니어링의 위험과 논쟁》에서 따로 깊게 다뤘다.

정리 — 루프를 쌓는다는 것

🧩
과거: 에이전트를 프롬프트했다
사람이 매번 지시하고, 결과를 검토하고, 다음 일을 시켰다. 사람이 곧 루프였다.
🔁
현재: 루프를 쌓는다
일하는 루프를 검증 루프가 감싸고, 이벤트 루프가 깨우고, 힐 클라이밍 루프가 전체를 스스로 고쳐 쓴다.
📈
그래서: 사람은 조종석으로
사람의 일은 '실행'에서 '조종'으로 옮겨간다 — 어느 언덕을 오를지 가리키고, 되돌릴 수 없는 순간에 손을 얹는 것.

swyx의 말로 이 글을 닫는다. "다음 세기의 게임 전체는, 루프를 얼마나 효과적으로 쌓을 수 있느냐에 달렸다." 2026년, 그 게임은 이미 시작됐다. 그리고 다행히도, 그 규칙은 프롬프트 한 줄보다 배우기에 훨씬 흥미롭다 — 왜냐하면 그것은 한 번의 답이 아니라 스스로 나아지는 시스템을 짓는 일이기 때문이다.


함께 읽으면 좋은 코어닷투데이 시리즈

참고 자료