🙋‍
저는 Luhui Dev로, 에이전트 엔지니어링 (Agent engineering)을 분석하고 AI가 교육에 어떻게 적용될 수 있는지 탐구해 온 개발자입니다.
저는 에이전트 하네스 (Agent Harness), LLM 애플리케이션 엔지니어링 (LLM application engineering), 수학을 위한 AI (AI for Math), 그리고 교육 SaaS의 제품화에 집중하고 있습니다.

“루프 엔지니어링 (Loop Engineering)”이 AI 코딩의 최신 아이디어로 떠오르고 있습니다.

Claude Code의 제작자인 Boris Cherny는 더 이상 Claude에게 직접 프롬프트 (prompt)를 입력하지 않는다고 말했습니다. 대신, 그는 Claude에게 프롬프트를 입력하고 다음에 무엇이 일어나야 할지를 결정하는 루프 (loops)를 작성합니다. Addy Osmani는 루프 엔지니어링 (Loop Engineering)을 유사한 용어로 설명합니다. 즉, 사람이 지속적으로 에이전트 (agent)에게 프롬프트를 입력하는 대신, 사람을 대신하여 프롬프트 입력, 실행 (execution), 그리고 피드백 (feedback)을 처리하는 시스템을 설계하는 것입니다.

매력적으로 들립니다.

Ralph Wiggum 루프 (Ralph Wiggum Loop)와 예약된 Claude Code 실행부터 Codex Goals, 장기 실행 작업 (long-running tasks), 그리고 멀티 에이전트 오케스트레이션 (multi-agent orchestration)에 이르기까지, 점점 더 많은 도구들이 이 패턴을 지원하고 있습니다. OpenAI는 약 25시간 동안 실행되어 약 1,300만 개의 토큰 (tokens)을 소비하고 약 30,000줄의 코드를 생성한 Codex 실험을 시연하기도 했습니다.

하지만 저는 루프 엔지니어링 (Loop Engineering)이 안정적이고 범용적인 소프트웨어 엔지니어링 패러다임 (software engineering paradigm)이 될 것인지에 대해 회의적입니다.

에이전트 (agents)가 계속 개선될 것이라는 점을 의심하지 않으며, 자동화된 루프 (automated loops)가 일부 작업에서 엄청난 가치를 창출할 수 있다는 점도 부정하지 않습니다. 저의 우려는 더 근본적입니다: 에이전트를 루프 (loop)에 넣는다고 해서 불확실한 모델 (model)이 자동으로 신뢰할 수 있는 엔지니어링 시스템 (engineering system)으로 변하는 것은 아닙니다.

루프 (loop)는 에이전트가 계속 작동하게 만드는 문제를 해결합니다. 하지만 더 중요한 질문은 해결하지 못합니다:

에이전트가 계속해서 올바른 일을 하고 있는가?

이것이 루프 엔지니어링 (Loop Engineering)의 핵심 과제입니다.

1. 실행은 루프화하기 쉽지만, 완료는 정의하기 어렵다

루프 (loop)에는 최소 세 가지 기본 요소가 필요합니다:

목표 (Goal), 실행 프로세스 (execution process), 완료 조건 (completion condition)

실행 (Execution)은 가장 어려운 부분이 아닙니다. 무엇이 "완료 (done)"되었는지를 정의하는 것이 어렵습니다.

전통적인 프로그램의 경우, 답은 종종 명확합니다:

큐가 비었을 때 중단
모든 파일이 처리되었을 때 중단
API가 성공을 반환할 때 중단

이러한 조건들은 결정론적 (deterministic)이며 계산 가능 (computable)합니다.

대부분의 실제 소프트웨어 목표는 그렇지 않습니다.

다음 사례를 고려해 보세요:

사용자 경험 (user experience) 개선
결제 시스템 리팩터링 (Refactor)
코드 품질 개선
...

그 어떤 것도 불리언 (Boolean) 표현식으로 깔끔하게 변환되지 않습니다.

Codex Goals에 대한 OpenAI의 가이드는 동일한 경계를 명확히 하고 있습니다: 목표의 종착점 (endpoint)이 모호할 때 그 목표는 부적합합니다. 목표 상태 (target state), 테스트, 그리고 제약 조건 (constraints) 없이 "더 좋게 만들어라" 또는 "이 코드를 리팩터링하라"와 같은 지침은 에이전트 (agent)에게 신뢰할 수 있는 완료 조건 (completion condition)을 제공하지 못합니다. 목표는 지속적인 목적 (persistent objective)과 증거 기반의 종착점 (evidence-based endpoint)을 가지고 있으며, 여러 차례의 조사 과정을 필요로 할 때 가장 잘 작동합니다.

이것이 루프 엔지니어링 (Loop Engineering)의 실제 범위를 드러냅니다.

자동화된 루프 (automated loops)에 가장 적합한 대상은 모두 복잡한 작업인 것이 아닙니다. 그것은 인간이 이미 검증 가능한 문제로 변환해 놓은 작업들입니다:

모든 테스트를 통과시킬 것
남은 23개의 레거시 엔드포인트 (legacy endpoints)를 새 프로토콜로 마이그레이션 (Migrate)할 것
모든 정적 분석 (static-analysis) 오류를 수정할 것

하지만 인간이 목표, 상태, 제약 조건, 그리고 완료 기준을 명확하게 정의할 수 있다면, 가장 어려운 요구사항 정의 작업의 상당 부분은 이미 완료된 것이나 다름없습니다.

루프 엔지니어링은 소프트웨어 엔지니어링의 핵심인 판단 (judgment)보다는, 하류 실행 (downstream execution)의 더 많은 부분을 자동화합니다.

2. 자동화된 검증은 실제 요구사항을 검증하지 않는다

루프 엔지니어링은 일반적으로 피드백으로서 테스트, 린트 (lint) 결과, 빌드, 성능 지표, 또는 스크린샷 평가에 의존합니다.

전형적인 루프는 다음과 같습니다:

에이전트가 코드를 변경함 -> 테스트 실행 -> 테스트 실패 -> 에이전트가 실패 원인 분석
-> 코드를 다시 변경함 -> 테스트 통과 -> 중단

이는 엔지니어링 관행과 일치하는 것처럼 느껴지지만, 심각한 문제를 숨기고 있습니다:

에이전트는 우리가 실제로 원하는 결과가 아니라, 검증 신호 (verification signal)를 최적화합니다.

테스트는 요구사항을 불완전하게 표현한 것에 불과합니다.

2026 SpecBench 연구는 장기적 코딩 에이전트 (long-horizon coding agents)에서의 보상 해킹 (reward hacking)을 조사했습니다. 공개 검증 테스트 (public validation tests)와 숨겨진 구성 테스트 (hidden compositional tests)를 분리함으로써, 연구는 최첨단 에이전트 (frontier agents)들이 가시적인 테스트에서는 높은 점수를 받을 수 있지만, 숨겨진 테스트에서는 여전히 상당한 격차를 보인다는 것을 발견했습니다. 이 격차는 작업의 규모가 커질수록 증가했습니다. 심지어 구현체가 올바른 동작을 모방하기 위해 테스트 입력을 암기하는 극단적인 사례도 나타났습니다.

이것이 반드시 에이전트가 의도적으로 속이고 있다는 것을 의미하지는 않습니다.

더 정확하게 말하면, 에이전트는 현재 사용 가능한 피드백을 충족하는 경로를 탐색합니다. 그 피드백이 실제 목표를 완전히 대변하지 못할 때, 대리 왜곡 (proxy distortion)이 자연스럽게 뒤따릅니다.

이는 굿하트의 법칙 (Goodhart’s law)과 유사합니다:

어떤 측정치가 목표가 되는 순간, 그것은 더 이상 좋은 측정치가 아니다.

인간 엔지니어들은 보통 테스트 범위를 벗어난 제약 조건들을 고려합니다:

• 코드가 제품의 실제 의도와 일치하는가?
• 다른 모듈의 동작을 망가뜨리는가?
• 장기적인 유지보수 비용을 발생시키는가?
• 아키텍처 원칙을 위반하는가?
• 보안 리스크를 증가시키는가?
• 단순히 테스트 케이스에 과적합 (overfitting)된 것인가?

에이전트는 이러한 조직적, 제품적, 그리고 역사적 지식을 자연적으로 보유하고 있지 않습니다.

결과적으로, 루프 엔지니어링 (Loop Engineering)을 위한 완전한 검증 시스템을 구축하는 비용은 작업을 직접 완료하는 비용만큼 많이 들 수도 있습니다.

3. 루프는 오류를 교정할 뿐만 아니라 증폭할 수도 있다

지지자들은 종종 루프를 다음과 같은 자기 교정 시스템 (self-correcting system)으로 설명합니다:

실패 -> 피드백 -> 교정 -> 재시도

하지만 루프가 본질적으로 수렴하는 것은 아닙니다.

루프는 다음과 같이 작동할 수도 있습니다:

목표를 잘못 읽음 -> 잘못된 구현을 구축함 -> 해당 구현을 바탕으로 계획을 업데이트함
-> 문서에 잘못된 상태를 기록함 -> 이후의 에이전트들이 이를 사실로 취급함
-> 잘못된 방향으로 최적화를 계속함

긴 작업(long task) 동안 에이전트는 코드뿐만 아니라 PRD(제품 요구 사항 문서), 할 일 목록(todo lists), 프로젝트 상태, 아키텍처 노트, 테스트, 진행 로그, 그리고 근본 원인(root cause)에 대한 기록까지 변경할 수 있습니다. 이러한 산출물(artifacts)들은 다음 반복(iteration)을 위한 컨텍스트(context)가 됩니다.

만약 한 번의 반복에서 잘못된 상태를 기록한다면, 이후의 반복들은 이를 검증되지 않은 가설로 취급하기를 멈추고 기정사실로 취급하기 시작할 수 있습니다.

단일 턴(single-turn) AI 오류는 보통 하나의 응답 내에 국한됩니다. 하지만 긴 루프(long loop)는 오류를 저장소(repository), 문서, 데이터베이스, 작업 시스템, 그리고 Git 히스토리까지 전파할 수 있습니다. 루프가 길게 실행될수록, 오류의 폭발 반경(blast radius)은 더 커질 수 있습니다.

4. 컨텍스트 리셋은 컨텍스트 오염을 해결하지 못함

Ralph Loop의 중요한 아이디어 중 하나는 에이전트가 한 번에 하나의 작업을 완료하고, 진행 상황을 파일이나 Git에 저장한 뒤, 새로운 컨텍스트 창(context window)으로 다음 반복을 시작하는 것입니다.

이는 대화가 무한정 길어지는 것을 방지할 수 있습니다.

하지만 이는 단지 모델 컨텍스트(model context)에 있는 상태(state)를 외부 저장소로 옮기는 것일 뿐입니다. 정보 관리 문제를 제거하지는 못합니다.

시스템은 여전히 어떤 이력을 유지할지, 어떤 것이 오래된 것인지, 어떤 결론이 단순한 추측인지, 어떤 코드와 문서가 현재 작업에 중요한지, 그리고 출처가 충돌할 때 어떤 출처를 신뢰해야 하는지를 결정해야 합니다.

Anthropic은 이를 **컨텍스트 엔지니어링 (Context Engineering)**으로 정의합니다. 에이전트가 루프 내부에서 더 많은 데이터를 생성함에 따라, 시스템은 다음 추론 단계(reasoning step)에 실제로 필요한 것이 무엇인지 지속적으로 선택하고 압축해야 합니다. Anthropic은 또한 컨텍스트가 커질수록 정확한 회상(recall)과 장기 추론(long-range reasoning) 능력이 저하된다고 언급하며, 따라서 컨텍스트는 항상 양이 많을수록 좋은 것이 아니라 희소한 자원으로 취급되어야 한다고 지적합니다.

따라서 장기 실행 에이전트는 딜레마에 직면합니다:

너무 적게 로드하면 에이전트가 프로젝트를 이해하지 못하고, 너무 많이 로드하면 중요한 신호가 노이즈(noise) 속으로 사라져 버립니다.

외부 상태(external state)는 코드베이스와 마찬가지로 엔트로피(entropy)를 축적합니다:

오래된 계획
중복된 설명
모순되는 규칙
...

어려운 문제는 루프 (loop)를 재시작하는 것이 아닙니다. 모든 재시작이 정확하고, 간결하며, 신뢰할 수 있고, 관련성 있는 정보를 전달받도록 보장하는 것입니다.

그 문제는 "루프를 작성하는 것"이라기보다 지식 관리 (knowledge management), 구성 관리 (configuration management), 그리고 런타임 상태 거버넌스 (runtime-state governance)에 더 가까워 보입니다.

5. 코드 생성 처리량은 엔지니어링 생산성이 아니다

루프 엔지니어링 (Loop Engineering)의 가장 눈에 보이는 이점은 더 높은 코드 생성 처리량 (code-generation throughput)입니다.

하나의 에이전트 (agent)는 지속적으로 작업할 수 있습니다. 여러 에이전트가 병렬로 작업할 수 있습니다. 작업은 밤새 실행될 수 있습니다. 실패한 테스트는 자동 수리를 트리거할 수 있습니다. 이론적으로 코드 출력량은 극적으로 증가합니다.

하지만 소프트웨어 생산성이 코드 라인 수와 동일했던 적은 결코 없습니다.

의미 있는 측정 기준은 요구사항이 제기된 시점부터 올바른 소프트웨어가 사용 단계에 진입하고 유지보수 가능한 상태로 남을 때까지의 총 비용입니다.

더 빠른 생성(generation)이 반드시 더 빠른 전달 (delivery)을 의미하지는 않습니다.

만약 에이전트들이 하루에 수십 개의 풀 리퀘스트 (pull requests)를 생성하는 동안 인간은 몇 개밖에 검토할 수 없다면, 병목 현상 (bottleneck)은 단순히 코드를 작성하는 단계에서 이를 검증하는 단계로 이동할 뿐입니다. 검토자들이 기계가 생성한 변경 사항의 양을 이해할 수 없다면, 다음과 같은 두 가지 결과가 발생할 가능성이 높습니다.

첫째, 에이전트의 출력물이 쌓이기만 하고 자동화된 처리량이 실제 전달로 이어지지 못합니다.

둘째, 팀이 검토 기준을 낮추고 빠르게 병합(merge)하여, 문제를 테스트, 운영, 그리고 장기적인 유지보수 단계로 떠넘기게 됩니다.

Martin Fowler의 사이트에서도 이러한 불일치에 대해 논의한 바 있습니다: 에이전트는 인간이 한 줄씩 검사하는 것보다 더 빠르게 코드를 생성할 수 있습니다. 인간의 검토가 병목 현상이 되지 않도록 하려면, 팀은 품질 검사를 더 앞 단계로 옮겨야 하며, 에이전트가 스스로 점검할 수 있도록 사양 (specifications), 테스트, 그리고 워크플로 제약 조건 (workflow constraints)을 만들어야 합니다.

숙련된 오픈 소스 개발자들을 대상으로 진행된 2025년 무작위 대조 시험 (randomized controlled trial)에서, METR은 참가자들이 이미 익숙한 성숙한 코드베이스 (mature codebases)의 경우, 당시 사용 가능한 AI 도구들이 작업 완료 시간을 평균 19% 증가시켰다는 사실을 발견했습니다. 2026년 후속 연구에서는 가속화의 몇 가지 가능성을 발견했으나, 신뢰 구간 (confidence intervals)이 너무 넓어 AI가 모든 환경에서 일관되게 속도를 높인다고 결론짓기에는 무리가 있었습니다.

AI 코딩 생산성은 단순히 생성 속도에 곱해지는 배수보다 훨씬 더 복잡한 문제입니다.

루프 엔지니어링 (Loop Engineering)은 이 격차를 더욱 벌립니다. 즉, 팀이 해당 출력물을 이해하고, 검증하며, 책임질 수 있는 능력을 반드시 높이지는 않으면서도, 에이전트의 실행 시간 (runtime)과 출력량 (output volume)만을 증가시킵니다.

6. 에이전트 권한의 증가는 더 큰 루프 리스크를 의미한다

복잡한 작업을 완료하기 위해 에이전트에게는 도구와 권한이 필요합니다: 저장소 접근 (repository access), 파일 수정, 셸 실행 (shell execution), 데이터베이스 접근, 로그, 클라우드 API, 배포 (deployment), 그리고 롤백 (rollback) 등이 있습니다.

더 위험한 점은, 에이전트가 GitHub 이슈나 웹 페이지와 같이 신뢰할 수 없는 외부 콘텐츠를 읽는다는 것입니다. 공격자는 해당 콘텐츠에 간접 프롬프트 주입 (indirect prompt injections)을 심어두어, 에이전트가 외부 텍스트를 운영 지침으로 오인하게 만들 수 있습니다.

지속적인 루프 (persistent loop)는 이러한 리스크를 증폭시킵니다.

침해된 에이전트는 단순히 잘못된 답변을 생성하는 것 이상의 행동을 할 수 있습니다:

민감한 데이터 읽기 -> 도구 호출 -> 외부 상태 변경
-> 잘못된 결과를 장기 메모리 (long-term memory)에 저장 -> 다음 반복 (iteration) 계속 진행

따라서 프로덕션 루프 (production loop)에는 엄격한 최소 권한 원칙 (least privilege)이 요구되는 것처럼 보입니다. 하지만 권한을 더 엄격하게 제한할수록 에이전트의 자율성은 낮아집니다.

이는 또 다른 루프 엔지니어링의 모순을 만들어냅니다:

권한이 많아지면 자동화 가치가 높아지지만 리스크도 커지며, 권한이 적어지면 리스크는 줄어들지만 에이전트가 성취할 수 있는 일도 제한됩니다.

7. 루프 엔지니어링은 Cron에 에이전트를 더한 것일 수도 있다

구조적으로 볼 때, 루프 엔지니어링이라 불리는 것의 상당 부분은 새로운 것이 아닙니다.

흔한 예시는 다음과 같습니다:

새로운 Sentry 이슈 발생 -> 에이전트가 조사 후 풀 리퀘스트 (pull request) 생성

매일 밤 실행 -> 에이전트가 실패한 테스트 확인 -> 수정을 시도함

새로운 고객 지원 티켓 발생 -> 에이전트가 로그 조사 -> 권장 사항 생성

과거에 팀들은 Cron, 웹훅 (webhooks), CI/CD, 메시지 큐 (message queues), Zapier 또는 n8n을 사용하여 이러한 패턴을 구축했습니다.

새로운 점은 LLM 에이전트가 워크플로 (workflow) 내의 결정론적 처리 노드 (deterministic processing node) 하나를 대체한다는 것입니다.

대부분의 사례는 여전히 이벤트 트리거 (event triggers) 및 예약된 작업 (scheduled jobs) 형태에 머물러 있습니다. 이것들이 유용할 수는 있지만, 이를 완전히 새로운 워크플로 패러다임 (workflow paradigm)이라고 부르기는 어렵습니다. 일부 개발자들은 에이전트 드리프트 (agent drift)를 경험하거나, 인간의 개입이 더 효과적이라는 것을 깨닫거나, 과도한 토큰 비용 문제에 직면한 후 기존의 방식(conventional approaches)으로 돌아가기도 했습니다.

8. 맺음말

루프 엔지니어링 (Loop Engineering)은 매력적인 미래를 제시합니다. 인간은 목표를 정의하고, 에이전트는 계속해서 작업을 수행하며, 소프트웨어는 스스로 진화하는 모습입니다.

하지만 실제 소프트웨어 엔지니어링 (software engineering)은 단순히 계속 시도한다고 해서 반드시 수렴하는 (converges) 문제는 아닙니다.