프롬프트를 쓰는 것을 그만두자 ― '루프 엔지니어링 (Loop Engineering)'을 자신의 업무에 구현하기

2026년 6월, AI 에이전트 업계의 담론이 하룻밤 사이에 바뀌었다.

계기는 OpenClaw 개발자 Peter Steinberger의 X 포스트다.

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

(이제 코딩 에이전트에 프롬프트를 입력하지 마라. 에이전트에 프롬프트를 입력하는 "루프 (Loop)"를 설계하라)

이 게시물은 약 650만 view에 달했다. 다음 날에는 Google의 Addy Osmani가 "Loop Engineering"이라는 제목의 에세이를 공개하며, 이 실천에 이름과 "해부도"를 부여했다. 결정타는 Claude Code를 이끄는 Anthropic의 Boris Cherny의 한마디였다.

"I don't prompt Claude anymore. I have loops running that prompt Claude. My job is to write loops."

(이제 Claude에 프롬프트를 쓰지 않는다. Claude에 프롬프트를 입력하는 루프를 실행하고 있다. 나의 일은 루프를 쓰는 것이다)

여기서 많은 엔지니어가 "그럼 나도 자율 루프를 구축하는 도구를 도입하자"라고 생각한다. 그것이 첫 번째이자 가장 큰 실수다. 루프 엔지니어링 (Loop Engineering)의 본질은 도구가 아니다. 자신의 업무를 Input → 작업(skill) → Output이라는 함수로 분해하고, 그것을 계속해서 돌리는 설계 사상이다. 순서를 틀리면 아무것도 돌아가지 않는다.

최근 몇 년간의 AI 활용은 관심의 대상이 일관되게 외부로 이동해 왔다.

프롬프트 엔지니어링 (Prompt Engineering) (2022–2024): 모델에 전달할 "언어"의 최적화 -
컨텍스트 엔지니어링 (Context Engineering) (2025): 모델이 보는 "정보 전체"의 설계 -
하네스 엔지니어링 (Harness Engineering) (2026): 에이전트를 둘러싼 "환경·발판"의 구축 -
루프 엔지니어링 (Loop Engineering) (2026): 이것들을 구동하는 "반복 사이클" 그 자체의 설계

중요한 점은 각 계층이 이전 계층을 대체하는 것이 아니라 내포한다는 점이다. Anthropic은 실제로 자사에 머지(merge)되는 코드의 80% 이상을 Claude가 작성하고 있다고 밝혔다 (2026년 5월 시점). 이는 개별 프롬프트가 뛰어나기 때문이 아니라, 검증을 동반한 루프가 돌아가고 있기 때문이다. Anthropic 스스로도 "Building effective agents"에서 다음과 같이 정의하고 있다 ― "에이전트란 본질적으로, 환경으로부터의 피드백을 바탕으로 도구를 루프로 사용하는 LLM에 불과하다".

여기서 한 가지 정의를 내려두자. 루프란 단순한 반복이 아니다. Output을 평가하고, 그 결과가 다음 Input과 작업(skill)을 개선하는 "순환"이다. 이 "순환"을 주인공으로 세울 수 있느냐가 유행을 타는 사람과 뒤처지는 사람을 가른다.

Osmani는 루프 엔지니어링을 다음과 같이 단언한다.

"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."

(루프 엔지니어링이란, 프롬프트를 입력하는 "당신 자신"을 대체하는 것이다. 대신 그것을 수행하는 시스템을 설계하는 것이다)

"당신 자신을 대체한다"라고 해도, 자신이 평소에 무엇을 하고 있는지 언어화할 수 없다면 대체할 방법이 없다. 따라서 출발점은 도구의 도입이 아니라 업무의 언어화다. 모든 태스크를 다음 세 가지 상자에 강제로 집어넣는다.

Input: 무엇을 받아서 시작되는가 (이메일, 회의록, 로그, 티켓…) -
작업(skill): 그 Input에 대해 어떤 판단·변환을 가하는가 -
Output: 최종적으로 무엇을 내놓는가 (누가, 무엇을 보고, OK라고 말할 수 있는가) -

Karpathy가 말하는 Software 3.0 ― "프로그래밍이란 프롬프팅이다" ― 가 와닿는 지점이 바로 여기다. 업무를 세 가지 상자로 분해하는 순간, 그것은 "자연어로 작성된 함수"가 된다. 함수가 되면 재사용할 수 있고, 자동화할 수 있으며, 그리고 평가 루프에 태울 수 있다.

구체적인 사례를 보자. "회의 회의록에서 과제를 추출하여 담당자에게 할당한다"라는, 어느 직장에나 있는 업무를 분해해 보자.

Input: 회의록 텍스트 (포맷은 부정형) + 멤버 목록 및 담당 영역

• 작업(skill):

  • 발언에서 '미결 과제'만 추출하기
  • 각 과제를 담당 영역에 매칭하기
  • 기한에 대한 단서가 있다면 부여하기

Output: '과제·담당자·기한' 표. 누락이 없고 담당자가 적절하다면 OK

이를 최소 단위의 루프(loop)로 작성하면 골격은 다음과 같다.

state = init(회의록, 멤버 목록)
loop:
과제 = reason(state) # 추출·할당을 추론
...

'일일 보고서 작성'에서도 구조는 동일하다. Input = 그날의 커밋(commit)·채팅 로그, 작업 = 요약 및 정형화, Output = 정형화된 포맷의 일일 보고서. 상자 안의 내용물이 바뀔 뿐, 루프의 골격은 재사용할 수 있다. 이것이 바로 '모든 태스크에 적용 가능한 추상화'의 정체이다.

여기까지 들으면 "그저 업무 흐름(workflow) 정리 아닌가?"라고 생각할지도 모른다. 아니다. 결정적인 차이는 위 의사코드(pseudo-code)의 verify와 break ― 즉, 프로그래밍적인 검증(exit 조건)이 있다는 점이다.

종료 조건(exit condition)이 없는 루프는 어떻게 될까? 실제로 언급된 실패 사례가 있다. 한 개발자가 Claude에게 태스크를 구현하게 하고, 매번 "과잉 구현이다"라고 수동으로 피드백하며, 이를 13시간 동안 87회 반복했다는 이야기다. 이것은 자동화가 아니다. 검증을 인간이 계속 붙잡고 있었기에 루프가 계속 돌았을 뿐이다.

업무 매뉴얼은 '절차서'에 불과하다. 루프 엔지니어링(Loop Engineering)이 절차서와 다른 점은, '무엇을 완료로 간주할 것인가'를 코드로 정의하고, 이를 충족할 때까지 자율적으로 실행하게 한다는 점에 있다. Cherny의 "My job is to write loops"는 바로 이 종료 조건(exit condition)의 설계를 가리킨다.

단언컨대, 루프화에 적합한 업무와 적합하지 않은 업무가 있다. 이를 잘못 판단하면 노동력 낭비다.

적합한 업무

• 반복 빈도가 높음 (일주일에 여러 번 수행)
• Input·Output이 정형화에 가까움
• '완료' 기준을 언어화·검증할 수 있음

적합하지 않은 업무

• 일회성이라 다시 발생하지 않음
• 판단이 개인의 역량에 의존적이며, 정답을 언어화하기 어려움
• 실패 비용이 높고, 인간의 승인을 배제할 수 없음

적합하지 않은 업무에 억지로 루프를 구성하기보다, 적합한 업무를 하나 찾아 확실하게 돌리는 것이 비용 대비 효과(ROI) 측면에서 차원이 다르게 높다.

루프 엔지니어링의 유행에 올라타고 싶다면, 새로운 에이전트(agent) 도구를 설치하기 전에 종이와 펜을 들고 자신의 업무를 하나 꺼내어 Input / 작업(skill) / Output의 세 가지 상자에 넣어보길 권한다. 상자에 깔끔하게 담기고 Output의 합격 여부를 글로 쓸 수 있다면, 그것은 오늘부터 루프로 만들 수 있는 업무다. 담기지 않는다면 아직 언어화가 부족한 것이다.

"프롬프트를 쓰는 것을 그만두라"는 말의 진정한 의미는, 손을 움직이는 것을 멈추고 자신의 업무 구조를 작성하라는 뜻이다. 유행은 도구의 얼굴을 하고 찾아오지만, 승부는 언제나 그 전 단계인 업무 분석에서 결정된다.

• Peter Steinberger / Addy Osmani — Loop Engineering (addyosmani.com)
• Anthropic — Building effective agents
• Anthropic — Effective context engineering for AI agents
• Andrej Karpathy — Software 3.0 (YC/Sequoia 강연, 2025)
• Boris Cherny의 발언·80%의 출처 정리 — Loop engineering 해설 기사 (tosea.ai / explainx.ai)