전부 loop였다: loop engineering과 harness engineering이 실제로 대체하는 것

2026-06-10

최종 업데이트 2026-06-10

당신이 2년 동안 이름도 붙이지 않은 채 돌려온 loop가 있다. 에이전트가 한 덩어리를 작업한다. 돌아온 걸 읽는다. 괜찮은지, 다음에 뭘 할지 판단한다. 다음 지시를 친다. 에이전트가 또 다음을 진행한다. 이 「결과 보기 · 판단하기 · 다시 prompt하기」의 반복이 하나의 loop이고, 그걸 돌리는 사람은 당신이다.

이 loop가 보이는 순간, 2026년 여기저기서 들리는 두 단어는 더 이상 서로 경쟁하는 유행어가 아니다.harness engineering과 loop engineering은 서로 다른 loop를 상대한다. 하나는 에이전트 자신의 loop를 더 오래 굴리고, 다른 하나는 당신의 loop를 노린다.

세 개의 loop, 겹겹이 포개진

위로 갈수록 loop다. 세 개가 쌓여 있고, 바깥이 안쪽을 감싼다.

가장 안쪽은 ReAct loop. 한 번의 실행 안에서 에이전트는 추론하고, 도구를 부르고, 결과를 보고, 다시 추론한다. 이건 에이전트 자신의 loop로, 하나의 작업을 스스로 한 바퀴씩 돈다.
그 바깥이 harness. 당신이 돌리는 loop가 아니라, 「안쪽 loop가 막히기 전에 얼마나 멀리 갈 수 있는지」를 정하는 장치다. 도구, 상태, 컨텍스트 관리, hooks, 복구.
더 바깥이 당신. 실행이 끝나거나 막히면 일은 사람에게 돌아온다. 결과를 보고, 다음 목표를 정하고, 또 한 바퀴를 시작한다. 이것이 아무도 이름 붙이지 않은 loop다.

이 그림을 기억해 두자. 질문은 하나, 각 단어가 어느 loop를 바꾸려 하는가이기 때문이다.

겹겹이 포개진 세 개의 loop

ReAct → harness → loop engineering, 그리고 사람은 어디로

안쪽 loop · 에이전트 자신harness · 한 번을 더 멀리loop engineering · 바깥 loop

안쪽 loop는 에이전트 자신의 것. harness는 한 번의 실행이 어디까지 가는지를 정한다. loop engineering이 자동화하는 건 한때 당신이던 바깥 loop이고, 매 턴의 검사는 별도의 검증자에게 넘긴다.

harness engineering은 안쪽을 노린다

맨 모델은 에이전트가 아니다. 비계로 감싸야 비로소 에이전트가 된다. 그 비계가 harness다. Viv Trivedy의 한마디가 그 모양을 잘 잡아낸다. Agent = Model + Harness. 모델이 아니라면, 당신이 harness다.그러니 harness engineering이란 그 비계를 제대로 된 산출물로 취급해 다듬는 일이다. 에이전트가 실수할 때마다 환경을 바꿔 그 실수가 다시는 안 나게 하고, 거기서 더 조여 간다.

쉽게 말해 harness는 「모델 빼고」 전부다.

시스템 prompt와 규칙집(AGENTS.md나 CLAUDE.md 같은). 매 턴 끼워 넣는다.
도구, skills, connectors, 그리고 「언제 무엇을 쓸지」 모델에게 알려 주는 설명.
컨텍스트 전략. 압축, 큰 도구 출력 덜어내기, 필요할 때만 지시 꺼내 보이기. 모두 context rot(길어질수록 흐려지는 문제)에 맞서기 위한 것이다.
샌드박스. 코드를 안전하게 돌리고, 에이전트가 스스로 결과를 검증할 수 있는 곳.
hooks. 규칙을 확정적으로 강제한다. 파괴적 명령을 막고, 편집 뒤 테스트를 돌리고, push 전 승인을 요구한다.
관측성. 로그, 트레이스, token 비용과 지연.

아주 근본적인 현상이 반복해서 나타난다. 같은 모델이라도 더 나은 harness에 얹으면 성능이 확 달라진다. harness만 바꿔 코딩 에이전트를 벤치마크 중위권에서 상위 5위로 끌어올린 팀도 있다. 모델은 애초에 유일한 변수가 아니었다.

그게 무엇을 사 주는지 보자. 좋은 harness는 한 번의 실행을 더 멀리 보낸다. 단계가 늘고, 일관성이 늘고, 고꾸라짐이 줄고, 그제야 제어를 사람에게 돌려준다. 늘어나는 건 「한 호흡에 얼마나 멀리, 얼마나 안정적으로 미느냐」다. Anthropic 엔지니어링 팀의 표현이 날카롭다. harness의 모든 부품은 「모델이 혼자 못 하는 것」에 대한 가정을 품고 있다. 그래서 모델이 좋아져도 비계는 사라지지 않는다. 새 천장이 있는 곳으로 옮겨 갈 뿐이다.

다만 harness engineering이 못 하는 게 있다. 가장 바깥 loop에서 당신을 빼내는 일이다. harness가 아무리 좋아도 한 번의 실행은 언젠가 끝나고, 누군가는 결과를 보고 「좋아, 다음은 이걸」이라고 말해야 한다. 지난 2년간 그 누군가는 줄곧 사람이었다.

loop engineering은 바깥을 노린다

loop engineering은 Addy Osmani가 퍼뜨렸고 Peter Steinberger와 Claude Code의 Boris Cherny도 같은 얘길 하는 말이다. 그것이 자동화하는 건 바로, 당신이 손으로 돌려온 그 loop다. 한 덩어리마다 보고 prompt하는 걸 그만두고, 목표를 한 번만 정한 뒤 에이전트를 정말 달성할 때까지 굴리는 시스템을 짠다.

게다가 「다음 prompt를 자동으로 쳐 준다」가 전부가 아니다. 당신의 loop는 「다음 단계를 정하는」 것뿐 아니라 조용히 또 하나, 「할 일이 있다는 걸 알아채는」 일도 했다. 그래서 진짜 바깥 loop는 발견과 분류까지 떠안는다. 정기적이거나 이벤트 기반인 트리거가 할 일을 길어 올리고, loop가 스스로 나눠 주고, 감당 못 하는 것만 당신에게 돌아온다. 스케줄러, 디스패처, 매 턴의 운전자, 이 세 역할을 한꺼번에 내려놓게 된다.

작동하는 loop를 뜯어보면 부품 다섯에 기억 하나가 나온다.

자동화. 정기적이거나 이벤트 기반으로 일을 길어 올리는 트리거. 심장 박동이다.
격리. worktree나 각자 독립된 컨텍스트. 병렬로 도는 에이전트가 서로 밟지 않도록.
skills. 프로젝트 지식을 한 번 적어 둔다. loop가 매 사이클마다 당신의 규칙을 처음부터 다시 끌어내지 않도록.
connectors. 일이 실제로 건드리는 도구와 데이터에 대한 접근.
서브에이전트. 「만드는 쪽」과 「검사하는 쪽」의 분리. 중요해서 아래 따로 한 절을 뒀다.
디스크에 남는 기억. 실행을 넘나들며 살아남는 파일이나 보드. 모델은 실행과 실행 사이에 전부 잊기 때문이다.

이젠 탁상공론이 아니다. Claude Code엔 /loop와 /goal이 있고, OpenAI Codex엔 Automations와 자체 /goal 명령이 있다. 이 원시 기능들이 이제 당신이 매일 쓰는 도구 안에 들어 있다. 이 단어가 떠오른 것도 절반은 그 때문이다.

진짜 바뀌는 건 여기다. 중심이 「이 하나의 prompt가 얼마나 좋은가」에서 「당신 대신 prompt를 쓰고 결과를 판단하는 시스템이 얼마나 좋은가」로 옮겨 간다. 잘 설계된 바깥 loop는 유능한 엔지니어를 증폭한다. 잘못된 설계는 나쁜 판단을 같은 속도로 증폭한다. 지켜보는 눈은 더 적다.

함정: 사람 loop는 검사도 하고 있었다

순진한 버전의 loop engineering은 여기서 무너진다. 사람을 그냥 빼고 시스템이 목표를 향해 스스로 prompt를 돌리게 하면, 지운 건 「다음은 이걸」이라고 말하는 사람만이 아니다. 「잠깐, 직전 단계가 틀렸어」라고 말하는 사람까지 지운 것이다. 바깥 loop는 늘 모자 하나 아래 두 가지 일을 담고 있었다. 다음 단계를 정하기, 그리고 직전 단계를 검증하기.

그래서 제대로 작동하는 loop는 검증을 제 안으로 들여와야 한다. 정석은 「만드는 쪽」과 「검사하는 쪽」을 분리하는 것(maker-checker)이다. 별도의 검증 에이전트가 중간 결과를 채점하고 목표 도달 여부를 판단한다. 작업한 에이전트는 절대 쓰지 않는다. 모델은 자기 결과를 매번 후하게 매기기 때문이다. 이 검증자가 있어야 「loop가 끝났다고 말한다」에 의미가 생긴다. 이건 진지한 에이전트 평가를 떠받치는 원리와 같다. 생성과 판단을 분리하라. 안 그러면 당신이 믿는 건 자신만만한 어림짐작일 뿐이다.

검증자가 있어도 사람은 검사 자리에서 완전히 떠나지 않는다. 매 턴의 loop에서 빠져 두 자리로 올라갈 뿐이다.

착수 전, 먼저 loop를 설계한다. 목표, 검증자가 비춰 볼 「완료의 정의」, 실행 주기, 되돌릴 수 없는 작업에 거는 승인 게이트. 「어떻게 되면 완료인가」를 글로 적어 두는 게 이탈을 가장 잘 막는다.
실행 후엔 중요한 것만 본다. 매 턴이 아니라, 영향이 크고 되돌리기 힘든 결과만. 「완료」는 loop의 일방적 주장이고, 그걸 받아들일지는 여전히 당신 몫이다.

그러니 솔직한 한마디는 「사람은 최종 상태만 보면 된다」가 아니다. 이쪽에 가깝다. loop engineering은 당신을 매 턴 운전에서 빼내, loop 설계와 중요한 산출물 리뷰로 끌어올린다. 그리고 당신이 하나하나 손으로 하던 검사는 검증 에이전트가 이어받는다.

휴대폰에선 어떻게 보이나: Memex

이 틀이 우리에게 단순한 단어가 아닌 이유는 이렇다. 두 단어가 뜨기 한참 전부터, Memex는 이미 바깥 loop의 한 형태를 기기 위에서 돌려 왔다. 로컬 우선, 백엔드 없는 앱으로, 기록을 구조화된 카드로 정리하고 지식을 뽑아내고 통찰을 떠올리는 멀티 에이전트가 전부 휴대폰에서 돈다. 여기서 harness가 dart_agent_core, 완전한 ReAct loop에 더해 도구 실행, FileStateStorage로 디스크에 남기는 세션, 컨텍스트 압축, 복구를 구현한 우리의 오픈소스 Dart 프레임워크다. 재미있는 건 제약 쪽이다. 서버도 없고, shell도 없고, CI도 없다. 바깥 loop는 앱이 종료돼도 기기가 재시작돼도 살아남아야 한다. 그래서 「상태를 디스크에 남기기」와 「이벤트로 구동하기」가 여기선 장식이 아니라 대들보가 된다. (자세한 건 Memex 뒤의 엔지니어링에서.)

그 바깥 loop는 채팅이 아니라 이벤트로 돈다. 카드를 확인한 뒤 다음을 지시하는 게 아니라, 기록 이벤트가 글로벌 이벤트 버스를 거쳐 그걸 구독한 에이전트에게 곧장 넘어간다. 트리거, 작업 디렉터리, 스킬 세트는 전부 디스크의 CustomAgentConfig에 적혀 있다. Super Agent가 전문 worker(Card, PKM, Insight, Comment, Memory)를 묶고,delegate_task로 일을 나눠 주며, 저마다 격리된 상태에서 돈다. 사람이 다음 prompt를 치지 않는다.

그리고 「완료의 정의」도 코드에 적혀 있다. 곧이곧대로 믿지 않는다. Card Agent가 끝나면 Memex는 CardRunCompletionEvidence를 돌린다. 디스크에 카드가 있는지, fact_id가 맞는지, 상태가 completed인지, 제목과 UI 설정이 있는지, 실행 기록에 성공한 save_timeline_card 호출이 있는지. 전부 만족해야 비로소 완료다. 빠진 게 있으면 부족한 요건을 콕 집어 되돌려 다시 돌리고, 재시도 상한까지 반복한다. 여기에 파괴적 작업 전에 멈추는 AgentController hooks와 반복 호출을 잡아내는 루프 감지기를 더하면, 이게 바로 이 글에서 말한 검증자와 완료 조건이 휴대폰 한 대에서 실제로 도는 모습이다.

진짜 흥미로운 건 그 제약이다. loop engineering 글들은 대개 서버와 shell과 CI 러너를 전제한다. Memex엔 그 어느 것도 없다. 바깥 loop는 앱이 시스템에 종료되든, 기기가 재시작되든, 네트워크가 끊기든 살아남아야 한다. 그래서 「상태를 디스크에 남기기」와 「이벤트로 구동하기」가 여기선 장식이 아니라, 바깥 loop를 휴대폰에서 성립시키는 유일한 방법이 된다.

위험은 사라지지 않는다, 한 층 위로 옮겨 갈 뿐

「사람 loop」에 숨어 있던 골칫거리는 자동화한다고 사라지지 않는다. 자리만 바꿀 뿐이고, 몇 개는 오히려 더 날카로워진다.

검증은 여전히 가장 어렵다. 당신은 그걸 자기 눈에서 검증 에이전트와 중요한 결과의 리뷰로 옮겼을 뿐이다. 검증자가 부실하면 loop는 옛 사람 loop보다 더 빠르고 더 당당하게 틀린 결과를 내놓는다.
「이해의 빚」이 쌓인다. loop가 당신이 손대지 않은 변경을 빠르게 낼수록, 「실제로 존재하는 것」과 「당신이 정말 이해하는 것」 사이의 간극은 벌어진다.
비용은 작업이 아니라 loop에 비례한다. 매 턴 검증자를 돌리고 서브에이전트를 여럿 거느린 정기 loop는, 건진 게 없어도 token을 태운다. 우선 느리게 돌리고, 청구서를 보고, 정말 남기고 싶은 결과가 나온 뒤에 주기를 올려라.

그래서 결론은 「사람 loop를 자동화하고 손 떼라」가 아니다. 일의 형태가 바뀌었다는 것이다. harness engineering은 한 번의 실행을 믿을 만하게 만든다. loop engineering은 믿을 만한 실행을, 당신이 운전하지 않아도 계속 반복하게 만든다. 수지가 맞느냐는 두 가지로 갈린다. 당신이 하나하나 손으로 하던 검증이 그대로 loop 안에 다시 지어졌는가. 그리고 당신이 여전히 그걸 설계한 엔지니어인가, 아니면 그냥 「시작」을 누르는 사람인가.

FAQ: loop, harness, 그리고 무엇이 대체되는가

agentic 코딩에서 말하는 「사람이라는 loop」란?

이름을 붙이지 않은 채 매일 돌리는 loop다. 에이전트가 한 덩어리를 끝내면 당신이 확인하고, 다음 목표를 정하고, 다시 prompt를 친다. 지난 2년간 코딩 에이전트를 쓴다는 건 기본적으로 이 사람 주도의 바깥 loop였다. loop engineering은 그것을 자동화한다. 목표는 한 번만 정하고, 나머지는 시스템이 에이전트를 굴린다. 다음 단계를 매번 당신이 치는 게 아니라.

harness engineering과 loop engineering은 무엇을 나눠 맡나?

노리는 loop가 다르다. harness engineering은 안쪽 loop를 다룬다. 도구·상태·컨텍스트 정책·hooks·복구로, 한 번의 실행이 당신에게 제어를 돌려주기 전까지 더 멀리, 더 일관되게 가게 한다. loop engineering은 바깥 loop를 다룬다. 결과를 확인하고 다음에 뭘 prompt할지 정하는 당신을 대체한다. harness는 한 번의 추진을 늘리고, loop는 추진과 추진 사이에서 당신을 빼낸다.

loop engineering이 사람을 대체하면 검사는 누가 하나?

아무도 안 하는 게 아니다. 바로 거기에 함정이 있다. 사람 loop는 「다음 단계를 정하는」 일만 한 게 아니라 늘 「직전 단계를 검증하는」 일도 했다. 그래서 제대로 작동하는 loop는 검증을 안으로 들여와야 한다. 별도의 검증 에이전트가 중간 결과를 채점하고 목표 도달 여부를 판단한다. 작업한 에이전트는 절대 쓰지 않는다. 모델은 자기 결과를 늘 후하게 매기기 때문이다. 사람은 검증에서 완전히 빠지지 않고, 영향이 크고 되돌릴 수 없는 결과의 리뷰와 「완료의 정의」 설계로 옮겨 간다.

그럼 loop engineering 체계에서 사람은 결국 뭘 하나?

두 가지, 둘 다 위쪽으로 옮겨 간다. 실행 전에는 loop를 설계한다. 재귀적 목표, 완료 조건, 검증자, 실행 주기, 되돌릴 수 없는 작업의 승인 게이트. 실행 후에는 중요하고 되돌리기 힘든 결과만 리뷰한다. 매 턴이 아니라. 중심도 옮겨 간다. 「당신의 prompt가 얼마나 좋은가」에서 「당신 대신 prompt하고 결과를 판단하는 시스템이 얼마나 좋은가」로.

Memex는 이 패턴을 쓰나?

쓴다. 휴대폰 크기로 줄여서. Memex의 커스텀 에이전트는 이벤트 기반이다. 기록 이벤트가 글로벌 이벤트 버스와 로컬 태스크 실행기를 거쳐 에이전트를 깨우고, 사람이 다음 prompt를 치지 않는다. 바깥 loop가 자동화된 것이다. 검증은 controller hooks(파괴적 작업 전에 멈춰 확인할 수 있다)와 루프 감지기에 박혀 있다. 상태는 디스크에 남아서 앱이 종료돼도 loop는 살아남는다. 사람은 중요한 게이트에만 선다.