한눈에 보는 핵심 인사이트 루프 엔지니어링(Loop Engineering)은 사람이 매번 프롬프트를 입력하는 대신, AI 에이전트가 일감을 찾고 실행하고 검증하고 기록하도록 그 반복 구조를 설계하는 방식입니다. 2026년 6월 구글 크롬 팀의 애디 오스마니(Addy Osmani)가 ‘Loop Engineering’이라는 글로 개념을 정리하면서, 프롬프트 엔지니어링에서 컨텍스트 엔지니어링, 하네스 엔지니어링으로 이어져 온 흐름의 다음 단계로 자리 잡았습니다. 잘 작동하는 루프는 자동화, 워크트리, 스킬, 커넥터, 서브에이전트의 다섯 가지 요소와 대화 밖에 남는 상태 기록으로 구성됩니다. 관건은 도구 선택이 아니라 운영 설계입니다. 목표를 검증 가능한 형태로 정의하고, 만드는 주체와 검증하는 주체를 분리하며, 진행 상황을 조직이 읽을 수 있는 형태로 남길 때 루프는 비로소 업무 성과로 이어집니다.

 

좋은 답변 한 번으로 끝나지 않는 실제 업무

 

지난 2년간 AI를 잘 쓰는 방법은 비교적 단순했습니다. 질문을 정교하게 다듬고 충분한 맥락을 넣어 주면 됐습니다. 사람이 입력하고, 돌아온 결과를 읽고, 다시 다음 지시를 입력하는 방식입니다. 이 구조에서 AI는 사람이 손에 쥐고 있는 도구였습니다.

문제는 실제 업무가 한 번의 좋은 답변으로 마무리되지 않는다는 데 있습니다. 현장의 일에는 문서에 적히지 않은 제약, 간헐적으로 실패하는 테스트, 오래된 관행, 불완전한 요구사항이 뒤섞여 있습니다. 그럴듯한 결과물을 한 번 만들어 내는 것만으로는 부족하고, 실행 결과라는 증거를 확인한 뒤 다음 단계를 고쳐 나가는 과정이 반드시 따라붙습니다. AI가 코드 작성뿐 아니라 도구 호출과 테스트, 문서 조사까지 직접 수행하게 되면서 중요한 것은 “좋은 답변을 한 번 받는 일”에서 “목표에 도달할 때까지 작업을 반복하고 개선하게 만드는 일”로 옮겨 갔습니다.

 

프롬프트에서 컨텍스트로, 하네스에서 루프로

 

 

AI를 다루는 방식은 층위를 하나씩 쌓아 올리며 진화해 왔습니다. 무엇을 질문할지 다듬는 프롬프트 엔지니어링, 판단에 필요한 정보를 어떻게 구성해 보여줄지 설계하는 컨텍스트 엔지니어링, 그리고 AI가 일할 수 있는 실행 환경 전체를 설계하는 하네스 엔지니어링까지가 지금까지의 흐름이었습니다.

루프 엔지니어링은 그 위에 한 층 더 올라섭니다. 하네스가 에이전트 하나를 위한 안전한 작업장을 만드는 일이라면, 루프는 그 작업장을 정해진 주기로 스스로 돌리고, 필요할 때 보조 인력을 부르고, 결과를 다시 자기 입력으로 삼게 만드는 일에 가깝습니다.

Anthropic에서 Claude Code를 총괄하는 보리스 체르니(Boris Cherny)는 더 이상 직접 프롬프트를 입력하지 않으며, 프롬프트를 넣고 다음 할 일을 정하는 루프를 돌리는 것이 자신의 일이 됐다고 말했습니다. 개발자 피터 슈타인베르거(Peter Steinberger) 역시 이제는 코딩 에이전트에게 프롬프트를 거는 대신, 에이전트에게 프롬프트를 거는 루프를 설계해야 한다고 정리했습니다. 두 발언을 개념으로 묶어낸 것이 오스마니의 글이며, 여기서 루프는 목적을 한 번 정의해 두면 AI가 완료될 때까지 스스로 반복하는 구조를 뜻합니다.

 

루프를 이루는 다섯 가지 요소와 하나의 기록

 

오스마니는 제대로 작동하는 루프가 다섯 가지 구성 요소와 하나의 기록으로 이루어진다고 정리합니다.

(1) 자동화(Automations)는 정해진 주기나 이벤트에 맞춰 스스로 실행되며 일감을 찾아 분류합니다. 한 번의 실행을 진짜 루프로 만들어 주는 심장에 해당합니다.

(2) 워크트리(Worktrees)는 여러 에이전트가 동시에 일할 때 각자의 작업 공간을 따로 떼어 줍니다. 같은 파일을 두 에이전트가 동시에 고치는 상황은 두 담당자가 상의 없이 같은 문서를 덮어쓰는 사고와 다르지 않습니다.

(3) 스킬(Skills)은 매번 새로 설명해야 했던 프로젝트 지식을 문서로 고정합니다. 규칙과 관행, 과거의 실패 경험까지 한 번 적어 두면 루프가 매 주기 처음부터 다시 추론하지 않고 지식을 축적해 나갑니다.

(4) 플러그인과 커넥터는 MCP를 기반으로 에이전트를 실제 업무 도구에 연결합니다. 이슈 트래커와 데이터베이스, 협업 도구에 닿는 순간 결과를 보고하는 데 그치지 않고 직접 처리하는 루프가 됩니다.

(5) 서브에이전트(Subagents)는 만드는 역할과 검증하는 역할을 분리합니다. 자신이 작성한 결과물을 스스로 채점하는 모델은 대체로 너그럽기 때문에, 다른 지시와 다른 모델을 쓰는 두 번째 에이전트가 검토를 맡을 때 오류가 훨씬 잘 걸러집니다.

마지막으로 상태(State)가 더해집니다. 마크다운 파일이든 이슈 보드든, 하나의 대화 바깥에 남아 무엇이 끝났고 무엇이 남았는지를 붙잡아 두는 기록입니다. 모델은 실행이 끝나면 맥락을 잊지만, 디스크에 남은 기록은 잊지 않습니다.

 

하루를 스스로 도는 루프, 그리고 종료 조건

 

 

이 요소들을 묶으면 작은 관제탑이 만들어집니다. 아침마다 자동화가 실행되어 지난밤의 빌드 실패와 열린 이슈, 최근 변경 이력을 읽고 결과를 상태 파일에 기록합니다. 처리할 가치가 있는 항목마다 격리된 작업 공간이 열리고, 한 서브에이전트가 수정안을 작성하면 다른 서브에이전트가 프로젝트 규칙과 기존 테스트를 기준으로 검토합니다. 커넥터가 코드 변경 요청(PR)을 등록하고 티켓을 갱신하며, 루프가 감당할 수 없는 건은 사람이 확인하도록 별도 인박스로 넘어갑니다. 다음 날 아침의 실행은 상태 파일을 읽고 오늘 멈춘 지점에서 이어집니다. 여기서 사람이 지시한 단계는 하나도 없습니다. 설계를 한 번 했을 뿐입니다.

이런 루프가 성립하려면 종료 조건을 검증 가능한 형태로 적어 두는 작업이 먼저입니다. Claude Code와 Codex는 모두 사용자가 정의한 조건이 실제로 충족될 때까지 작업을 이어 가는 목표 기반 실행 기능을 제공합니다. 특히 Claude Code는 매 턴이 끝날 때마다 별도의 모델이 완료 여부를 판정합니다. 결과물을 만든 쪽이 완료를 선언하지 않도록 판정 주체를 분리하는 것입니다. 종료 조건이 모호하면 루프는 끝나지 않고, 비용은 예측 범위를 벗어나며, 스스로 만든 성공에 만족한 채 잘못된 결과를 쌓아 올리게 됩니다.

 

루프가 대신해 주지 않는 세 가지

 

오스마니는 루프가 정교해질수록 오히려 더 날카로워지는 문제 세 가지를 짚습니다. 첫째는 검증입니다. 사람이 지켜보지 않는 사이 루프는 성과뿐만 아니라 실수도 함께 반복합니다. 검증자를 분리해도 완료는 여전히 주장이지 증명이 아닙니다. 둘째는 이해도입니다. 직접 작성하지 않은 결과물이 빠르게 쌓일수록, 실제 만들어진 것과 담당자가 파악하고 있는 것 사이의 간격이 벌어집니다. 셋째는 판단입니다. 루프가 알아서 돌아가기 시작하면 결과를 따져 보지 않고 나오는 대로 받아들이기 쉬워집니다. 같은 루프를 두 사람이 만들어도 결과는 정반대일 수 있습니다. 잘 아는 일을 더 빠르게 처리하는 데 쓰는 사람과, 그 일을 이해하지 않아도 되게 만드는 데 쓰는 사람의 차이입니다.

 

업무 안에 루프를 설계하는 AXgenticWire

 

 

루프 엔지니어링은 소프트웨어 개발 현장에서 먼저 자리를 잡았지만, 구조 자체는 특정 직무에 묶여 있지 않습니다. 트리거가 작업을 발견하고, 검증 가능한 목표가 완료를 정의하고, 실행과 검증이 분리되고, 진행 상황이 기록으로 남는 형태는 규제 모니터링, 계약 검토, 수요 예측, 리포트 작성 같은 업무에도 그대로 적용됩니다. 다만 조직의 루프는 개인의 루프와 달리 누가 무엇을 승인했고 어떤 근거로 완료 판정이 내려졌는지 추적할 수 있어야 합니다.

SK AX의 Agentic AI 브랜드 AXgenticWire는 이 운영 루프를 기업 업무 안으로 가져오는 데 초점을 맞추고 있습니다. AXgenticWire Core는 개발 지식이 없는 현업 구성원도 자신의 업무에 맞는 AI Agent를 직접 만들고 운영할 수 있는 환경을 제공합니다. 업무 목표를 설정하고, Agent를 실행하고, 결과의 품질을 평가하고, 피드백을 반영해 다시 개선하는 순환이 개인의 노하우가 아니라 조직이 함께 쓰는 체계로 자리 잡도록 설계하는 방식입니다. 루프를 잘 만드는 일이 곧 AI를 잘 쓰는 일이 된 지금, SK AX는 기업이 자기 업무에 맞는 루프를 갖추고 운영해 나갈 수 있도록 함께 설계합니다.

 

[FAQ]

 

Q1. 루프 엔지니어링이란 무엇인가요?

사람이 매번 프롬프트를 입력하는 대신, AI 에이전트가 일감을 찾고 실행하고 결과를 검증하고 기록한 뒤 다음 작업을 결정하도록 반복 구조 전체를 설계하는 방식입니다. 목적을 정의해 두면 AI가 완료될 때까지 스스로 반복한다는 점에서, 한 번의 질문과 한 번의 답변으로 끝나던 기존 활용 방식과 구분됩니다. 2026년 6월 애디 오스마니가 발표한 글을 통해 개념이 정리되며 널리 알려졌습니다.

 

Q2. 하네스 엔지니어링과 루프 엔지니어링은 어떻게 다른가요?

하네스 엔지니어링은 에이전트 하나가 안전하게 일할 수 있는 실행 환경을 설계하는 영역으로, 실행 범위 정의와 도구 호출 방식, 오류 처리, 안전 통제가 여기에 포함됩니다. 루프 엔지니어링은 그 환경을 정해진 주기로 스스로 돌아가게 만들고, 보조 에이전트를 호출하며, 결과를 다시 자기 입력으로 삼는 자율 제어 구조를 설계합니다. 하네스가 작업장이라면 루프는 그 작업장을 돌리는 운영 방식에 해당합니다.

 

Q3. 루프를 구성하는 요소에는 어떤 것들이 있나요?

주기적으로 실행되며 일감을 찾는 자동화, 병렬 작업이 충돌하지 않도록 분리하는 워크트리, 프로젝트 지식을 문서로 고정하는 스킬, 실제 업무 도구와 연결하는 플러그인·커넥터, 만드는 역할과 검증하는 역할을 나누는 서브에이전트의 다섯 가지가 기본 구성입니다. 여기에 대화 바깥에 남아 진행 상황을 붙잡아 두는 상태 기록이 더해져야 실행 간에 맥락이 이어집니다.

 

Q4. 루프를 도입할 때 가장 주의해야 할 점은 무엇인가요?

검증 가능한 종료 조건을 명확히 정의하는 일입니다. 조건이 모호하면 루프가 끝나지 않아 비용이 예측 범위를 벗어나고, 잘못된 결과를 완료로 판정한 채 계속 쌓아 올릴 위험이 있습니다. 결과물을 만든 에이전트와 완료를 판정하는 주체를 분리하고, 루프가 처리하지 못한 항목은 사람이 확인하도록 남겨 두는 구조가 함께 필요합니다.

 

---

 

AX 컨설팅부터 비즈니스 모델 발굴까지
Global Top 10 AX Service Company｜SK AX

#루프엔지니어링, #LoopEngineering, #AI에이전트, #에이전틱AI, #AgenticAI, #하네스엔지니어링, #컨텍스트엔지니어링, #프롬프트엔지니어링, #서브에이전트, #ClaudeCode, #MCP, #AI코딩에이전트, #업무자동화, #AXgenticWire, #SKAX