모두가 Loop Engineering에 대해 이야기하고 있습니다. 듣자하니, 이제 더 이상 프로그래밍을 할 필요가 없다고 합니다.

요약(TL;DR): Loop Engineering은 2026년 가장 뜨거운 AI 워크플로우 (workflow) 패턴입니다. 하지만 그 뒤에는 추악한 비밀이 숨겨져 있습니다.

모든 것을 시작하게 만든 트윗

2026년 6월, Addy Osmani와 PostHog 팀은 동일한 아이디어에 대한 자신들의 견해를 발표했습니다.

AI 에이전트 (agent)에게 수동으로 프롬프트 (prompt)를 입력하는 대신, 당신을 대신해 에이전트에게 프롬프트를 입력하는 시스템을 구축하는 것입니다.

이 메타프롬프트 (metaprompt) 아이디어는 이제 멋진 이름을 갖게 되었습니다. 바로 Loop Engineering입니다.

Loop engineering은 에이전트에게 프롬프트를 입력하는 사람으로서의 당신 자신을 대체하는 것입니다. 대신 그 일을 수행하는 시스템을 설계하는 것이죠.

Addy Osmani

PostHog는 이를 프로덕션 (production) 환경에서 실행했습니다. 결과는 다음과 같습니다: 11%의 성능 향상, 그리고 쿼리 엔진 (query engine)에서 3년 된 결함이 사람의 개입 없이 해결되었습니다.

인터넷은 다시 한번 열광했습니다. 그럴 만한 이유가 있었습니다.

하지만 이 용어 뒤에는 추악한 비밀이 숨겨져 있습니다.

루프 (Loop)란 실제로 무엇인가

기능적인 루프는 네 가지 부분으로 구성됩니다:

• 목표 (Goal): 에이전트를 위한 명확하게 범위가 지정된 대상
• 컨텍스트 (Context): 각 사이클 (cycle)에 입력되는 도구 (tools), 데이터 (data), 오류 (errors), 그리고 메모리 (memory)
• 평가 (Evaluation): 루프를 계속할지 아니면 중단할지를 결정하는 메커니즘 (일명 종료 조건, exit criteria)
• 에이전트 (Agent): 단순한 /goal 명령부터 완전한 멀티 에이전트 하네스 (multi-agent harness)에 이르는 실행자

평가 (evaluation) 구성 요소가 핵심입니다. 이것이 없다면 당신은 루프를 가진 것이 아닙니다. 당신은 무한히 폭주하는 프로세스를 가진 것입니다. 당신의 토큰 (token) 청구서를 행운을 빌며 지켜보세요!

또한 하네스 (harness)가 필요합니다. 이는 에이전트를 포함하고, 당신의 규칙을 강제하며, 루프가 작동할 수 있는 안전한 경계를 제공하는 스캐폴딩 (scaffolding)입니다.

가능한 가장 작은 명세 (Spec)부터 시작하라

여기서 Loop Engineering이 흥미로워지며, 대부분의 사람들이 실수하는 지점이 나타납니다.

루프가 단 한 번 실행되기 전에 가능한 모든 케이스를 다루는 거대한 명세 (spec)를 작성한다면, 당신은 Loop Engineering을 하고 있는 것이 아닙니다. 당신은 단계만 더 추가된 폭포수 (waterfall) 모델을 하고 있는 것입니다.

시스템 전체가 아니라, 당신이 검증하고 싶은 것, 즉 하나의 동작 (behavior)에 대해 생각하십시오.

Loop Engineering을 사용하여 2026 FIFA 월드컵 조별 예선 순위 시뮬레이터를 만들어 보겠습니다.

E조에는 독일, 코트디부아르, 에콰도르, 그리고 퀴라소(Curaçao)가 있습니다. 총 3라운드의 경기가 치러집니다. 상위 2개 팀이 진출하며, 승점이 가장 높은 3위 팀들도 진출권을 얻습니다.

가장 작은 규모의 스펙(Spec)은 무엇일까요?

경기에 승리한 팀은 3점을 얻는다.

그게 전부입니다. 조 전체를 다루는 것도, 토너먼트 대진표를 다루는 것도 아닙니다. 단 하나의 경기에 관한 단 하나의 규칙입니다.

이것이 스펙 주도(Spec-Driven) 방식입니다. 구현(Implementation) 전에 의도(Intent)를 정의하되, 범위를 매우 정밀하게(Surgical) 유지하는 것입니다.

루프 반복 1: 실패하는 스펙 작성하기

첫 번째 루프 사이클입니다. 구현체가 존재하기 전에 평가 조건(Evaluation condition)을 정의합니다.

def test_win_gives_three_points():
germany = Team("Germany 🇩🇪")
curacao = Team("Curaçao 🇨🇼")
...

이를 실행합니다. 실패합니다. Team이 존재하지 않습니다. Match가 존재하지 않습니다. GroupStandings가 존재하지 않습니다.

(독일은 2026년 6월 14일에 퀴라소를 7-1로 이겼습니다. 스펙은 실제 사실과 일치합니다.)

루프 조건은 빨간색 🔴입니다.

이것이 루프에 필요한 신호입니다. 평가는 다음과 같이 말합니다: 아직 완료되지 않았습니다. /goal을 달성할 때까지 계속 실행하십시오.

루프 반복 2: 평가 통과시키기

이제 에이전트(Agent)에게 루프를 종료시키기 위한 최소한의 구현(Implementation)을 제공합니다.

class Team:
def __init__(self, name):
self.name = name
...

스펙을 실행합니다. 초록색 🟢. 루프가 종료됩니다.

모든 규칙을 모델링했기 때문이 아닙니다. 루프가 확인하고 있던 단 하나의 조건을 충족했기 때문입니다.

루프 반복 3: 스펙 확장, 다시 빨간색 🔴

새로운 목표와 함께 루프가 재시작됩니다.

def test_draw_gives_one_point_each():
ecuador = Team("Ecuador 🇪🇨")
curacao = Team("Curaçao 🇨🇼")
...

빨간색 🔴. record 메서드가 무승부를 처리하지 못합니다.

(에콰도르는 6월 20일에 퀴라소와 0-0로 비겼습니다. 이번에도 스펙은 실제 사실과 일치합니다.)

평가가 실패합니다. 루프가 계속됩니다. 무승부 케이스를 추가합니다. 초록색 🟢. 루프가 종료됩니다.

루프 확장: 조별 예선 완료

사이클이 반복될 때마다 스펙은 확장됩니다:

• Iteration 4: 세 라운드 전체에서 여러 매치가 포인트를 올바르게 누적함
• Iteration 5: 동일한 포인트를 가진 팀들은 골 득실차 (Goal Difference)로 순위를 결정함
• Iteration 6: 골 득실차가 같을 경우 다득점 (Goals Scored)으로 결정함
• Iteration 7: 상위 2개 팀이 토너먼트 (Knockout stage) 단계로 진출함

각 반복 (Iteration)은 동일한 패턴을 따릅니다: 평가 조건을 먼저 작성하고, 실행하고 (실패함), 통과하기 위한 최소한의 구현을 수행하고, 다시 실행하고 (초록색 🟢), 다음 사이클로 넘어갑니다.

7번의 반복 후, E조 최종 순위:

Group E - Final Standings
1. Germany 6 pts GD: +6 GF: 10
2. Ivory Coast 6 pts GD: +2 GF: 4
...

루프 확장: 토너먼트 대진표 (Knockout Brackets)

동일한 루프 규율이 대진표 생성에도 적용됩니다.

def test_group_winner_faces_different_group_runner_up():
bracket = KnockoutBracket(completed_group_results)
round_of_32 = bracket.round_of_32()
...

먼저 빨간색 🔴. 그다음 초록색 🟢. 그다음 다음 스펙 (Spec).

루프는 시작하기 전에는 전체 대진표를 알지 못합니다. 한 번에 하나의 평가를 통해 대진표를 발견해 나갑니다.

루프를 안전하게 유지하는 것: 하네스 (The Harness)

다음과 같은 구조가 없다면 이 중 어느 것도 작동하지 않습니다:

• 매 사이클마다 평가를 실행함
• 조건이 통과되면 에이전트 (Agent)를 중단함
• 현재 스펙이 초록색 🟢이 될 때까지 에이전트가 다음 스펙으로 넘어가는 것을 방지함
• 사이클 사이에 상태 (State)를 저장하여 다음 스펙이 이미 무엇이 통과되었는지 알 수 있게 함
• 평가를 통과하게 만드는 최소한의 솔루션만을 강제하며, 그 이상은 허용하지 않음
• 스펙이 초록색 🟢이 되는 순간 루프가 멈추기 때문에 오버엔지니어링 (Over-engineering)이 구조적으로 불가능함

이것이 바로 하네스 (Harness)입니다. 하네스는 Loop Engineering을 while True 루프에서 Claude를 실행하며 운에 맡기는 것과 구분 짓는 요소입니다.

Codex와 Claude Code는 이제 /goal, /loop, isolation: worktree, 그리고 별도의 검증을 위한 서브 에이전트 (Sub-agents)와 같은 내장된 루프 인프라를 제공합니다.

하네스는 더 이상 처음부터 직접 구축해야 하는 것이 아닙니다.

검증을 수행하는 에이전트는 구현자가 무엇을 했는지에 대한 기억이 없는 깨끗한 서브 에이전트에서 실행됩니다.

그것은 *심판의 날 (Judgment Day)*의 순간을 찾는 독립적인 검사관입니다.

그것은 작업이 수행되는 과정을 본 적이 없기 때문에 자신의 작업을 스스로 채점할 수 없습니다.

이는 개발자에게 자신의 풀 리퀘스트 (Pull Request)를 직접 리뷰해달라고 요청하지 않는 것과 같은 이유입니다.

모두의 이목을 집중시킨 수치들

왜 이것이 5년 전이 아닌 지금 주목받고 있을까요?

그 이유는 평가 (Evaluation) 단계(루프가 계속 진행할지 여부를 결정하는 부분)에 사람이 필요했기 때문입니다. 이제는 그렇지 않습니다.

• Opus 4.8은 12시간의 작업이 필요한 작업의 50%를 완료하며, 이는 1년 전 전작보다 6배 빠른 속도입니다.
• Stripe는 팀이 수동으로 작업했을 때 두 달이 걸렸을 전체 코드베이스를 단 하루 만에 마이그레이션했습니다.
• PostHog의 자동 조사 루프 (Autoresearcher loop)는 감독 없이도 11%의 성능 향상을 달성하고 3년 된 결함을 수정했습니다.

모델이 더 약했을 때는 루프가 평가 출력값을 해석하기 위해 당신을 필요로 했습니다. 이제는 평가 자체가 테스트 스위트 (Test suite)가 될 수 있으며, 에이전트가 이를 직접 읽습니다.

추악한 비밀

당신은 지금까지 테스트 주도 개발 (Test-Driven Development, TDD)에 대해 읽어왔습니다.

*명세 (Spec)*는 테스트입니다.

*평가 (Evaluation)*는 테스트 러너 (Test runner)입니다.

*루프 (Loop)*는 레드 🔴-그린 🟢-리팩터 (Refactor) 🔵 사이클입니다.

*목표 (Goal)*는 실패하는 어설션 (Assertion)입니다.

평가를 통과할 때 루프가 종료된다는 것은 테스트가 그린 🟢 상태임을 의미합니다.

Kent Beck은 이를 2003년에 설명했습니다.

Ward Cunningham은 그 이전부터 이를 수행하고 있었습니다.

다음번에 어떤 *목표 (Goal)*를 다룰지 선택하기 위한 구조화된 가이드인 ZOMBIES 프레임워크도 존재합니다: Zero, One, Many, Boundary, Interface, Exceptional, Simple. 이것이 당신의 루프 반복 순서입니다.

변한 것은 기술이 아닙니다. 변한 것은 루프를 실행하는 주체입니다.

2003년에는 인간 개발자가 테스트를 작성하고, 실행하고, 레드 🔴 출력을 읽고, 최소한의 코드를 작성하고, 다시 실행하여 그린 🟢을 확인한 뒤 다음 테스트로 넘어갔습니다.

그것이 루프였습니다.

2026년에는 기능적 개발자 (Functional developer)가 명세를 작성하면, 에이전트가 사이클을 실행하고, 레드 🔴 출력을 읽고, 최소한의 코드를 작성하고, 사이클을 다시 실행하여 그린 🟢을 확인한 뒤 다음 명세를 시작합니다. 그것 역시 여전히 루프입니다.

빨간색 🔴-초록색 🟢-리팩터링 🔵 어휘는 2026년이 되기에는 충분히 기억에 남지 않았습니다. 그래서 업계는 이름을 바꿨습니다.

평가(Evaluation)는 여전히 테스트입니다. 사이클은 여전히 TDD(Test-Driven Development)입니다. 규율은 정확히 동일합니다.

루프를 구축하십시오. 하지만 단순히 '시작(go)' 버튼을 누르는 사람이 아니라, 엔지니어로 계속 남고자 하는 사람처럼 구축하십시오.

Addy Osmani

Kent Beck도 똑같은 말을 했습니다. 그는 단지 그것을 다른 이름으로 불렀을 뿐입니다.

몇 가지 추가 팁:

• 첫 번째 반복(iteration)을 시작하기 전에, 읽기 전용(read-only) 모드로 계획하십시오: 어떤 명세(spec)를 어떤 순서로 작성할지 결정합니다. 아직 코드는 작성하지 마십시오.
• 에이전트(Agent)가 결함의 재현 단계나 누락된 기능에 대해 항상 실패하는 테스트를 작성하도록 강제하고, 작업을 완료로 표시하기 전에 반드시 기준 확인(criterion check)을 수행하도록 강제하십시오.
• 전체 과정을 지켜보십시오. 당신의 명시적인 승인 없이는 프로덕션(production)에 배포하지 마십시오.
• 당신은 모든 솔루션 코드를 이해해야 합니다. 루프는 빠르게 돌아갑니다. 루프가 당신의 이해 속도보다 앞서 나가게 두지 마십시오. 수동적인 자동화는 이해 부채(comprehension debt)를 생성합니다.
• 테스트가 통과할 때마다 자동으로 커밋하도록 하네스(harness)를 구성하십시오. 이것이 TCR (Test && Commit || Revert)입니다: 초록색 🟢이면 커밋하고, 빨간색 🔴이면 되돌리기(revert)를 합니다. 통과하는 각 사이클은 깨끗한 체크포인트를 남깁니다. 루프는 결코 유효하지 않은 상태로 표류하지 않습니다.
• 사이클당 하나의 명세는 기능당 하나의 작은 풀 리퀘스트(pull request)를 의미합니다. 리뷰어는 소설이 아니라 차이점(diff)을 읽습니다.
• TDD에는 두 단계가 아니라 세 단계가 있습니다. 빨간색 🔴, 초록색 🟢, 리팩터링 🔵. 루프는 처음 두 단계를 자동으로 처리합니다. 세 번째 단계에는 여전히 당신이 필요합니다. 결합도(coupling)와 응집도(cohesion) 지표를 갖춘 하네스는 방금 초록색 🟢이 된 코드가 그대로 유지할 가치가 있는지 알려줍니다. 통과하는 사이클 이후 결합도가 높거나 응집도가 낮다면, 다음 명세로 넘어가기 전에 리팩터링해야 한다는 신호입니다.

레거시 시스템에서의 루프 엔지니어링 (Loop Engineering on Legacy Systems)

루프 엔지니어링은 신규 코드(greenfield code)나 화려한 MVP만을 위한 것이 아닙니다. 이는 테스트가 전혀 없는 시스템을 안전하게 현대화하는 방법이기도 합니다.

비결은 동일합니다: 명세를 먼저 작성하십시오.

레거시 시스템에서 그 명세는 시스템이 이미 가지고 있는 동작을 기술합니다.

당신은 새로운 규칙을 발명하는 것이 아닙니다. 루프 (loop)가 기존 규칙을 깨뜨릴 수 없도록 기존의 규칙들을 고정 (pinning)하는 것입니다.

프로덕션 레거시 시스템 (production legacy systems)에서는 하네스 (harnesses)가 훨씬 더 중요합니다.

그러면 루프는 한 사이클마다 테스트되지 않은 영역을 줄여 나갑니다.

통과된 (green 🟢) 명세 (spec) 하나하나가 에이전트 (agent)가 다음 반복 (iteration)에서 실수로 파괴할 수 없는 동작임을 의미합니다.

레거시 시스템에 TDD (테스트 주도 개발)를 적용하는 방식은 사람이 사이클을 돌리든 에이전트가 돌리든 동일합니다. 규율 (discipline)은 같습니다. 변하는 것은 속도뿐입니다.

무엇을 기다리고 있습니까? 하네스 (harnesses)를 구축하십시오. 루프 (loops)를 시작하십시오.