Loop Engineering for Beginners — AI 에이전트가 스스로 일하게 만드는 법
📺 원본 영상: Loop engineering for beginners 🎙️ 채널: How I AI 📅 정리 일자: 2026-06-18 ⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(데모 화면, 코드, UI 스크린샷 등)는 포함되지 않을 수 있습니다.
개요
AI 에이전트를 사용하는 방식은 크게 두 가지로 나뉜다. 사람이 직접 프롬프트를 입력하는 방식, 그리고 에이전트가 스스로 프롬프트를 생성하여 작업을 수행하는 방식이다. 이 영상은 후자, 즉 루프(Loop) 기반 자동화 에이전트의 개념을 처음 접하는 사람들을 위해 설계되었다. 강연자는 루프가 무엇인지를 비기술적인 언어로 풀어내고, Claude Code와 Codex라는 두 플랫폼에서 실제로 루프를 구현하는 과정을 시연하며, 마지막으로 루프를 무분별하게 사용할 때 발생하는 함정까지 짚어준다.
왜 지금 루프가 주목받는가
강연자에 따르면, 이 흐름의 촉발점은 OpenClaw(강연자가 활동하는 AI 커뮤니티/뉴스레터 플랫폼으로 보임)의 Pete가 올린 한 장의 트윗이었다. 그는 “여전히 프롬프트를 직접 입력하고 있다면 구시대 인물”이라고 선언하며, 에이전트가 스스로를 프롬프트하는 루프 설계로 넘어가야 한다고 주장했다. 이 트윗은 폭발적인 반응을 낳았고, 루프에 관한 콘텐츠가 쏟아졌지만, 강연자는 “그 어느 것도 루프를 제대로 설명하지 못했다”고 평가한다. 이 영상은 그 공백을 채우기 위해 제작되었다.
그러나 강연자는 처음부터 균형 잡힌 시각을 제시한다. 루프가 유용하긴 하지만, 자신도 여전히 직접 프롬프트를 입력하는 방식을 쓴다고 밝힌다. “루프를 극단적으로 추구하지 않아도 AI로 많은 것을 해낼 수 있다”는 전제 아래, 루프가 실질적으로 가치 있는 상황을 가려내는 데 집중하는 것이 이 강연의 실용적 태도다.
루프란 무엇인가 — 핵심 개념 정리
루프를 이해하려면, 먼저 AI 에이전트를 프롬프트하는 방식이 하나가 아니라는 점을 받아들여야 한다. 강연자는 프롬프트 방식을 크게 구분한다. 가장 보편적인 것은 메시지(Message) 방식으로, 사람이 채팅창에 프롬프트를 입력하고 응답을 기다린 뒤 다시 입력하는 턴(Turn) 기반 방식이다. 이는 여전히 유효하지만, 루프와는 본질적으로 다르다.
루프는 간단히 말해 에이전트를 자동으로 프롬프트하는 것이다. 사람의 손가락이 키보드를 두드릴 필요 없이, 미리 정의된 조건이나 일정에 따라 에이전트가 스스로 작업을 시작하고 수행한다. 강연자는 이 개념을 “정말 기본적으로 설명하겠다”고 약속하며, 루프를 다음과 같이 정의한다.
“루프는 에이전트를 일정에 따라, 혹은 반복적인 방식으로 자율적으로 실행시키는 수단이다. 작업이 완료되거나, 시간이 다 될 때까지 지속된다.”
루프의 네 가지 유형
강연자는 루프를 구현하는 형태를 구체적으로 네 가지로 나눠 설명한다. 이 분류는 AI 이전부터 자동화 분야에서 쓰이던 개념이기도 하다.
첫 번째는 **하트비트(Heartbeat)**다. “매 5분마다”, “매 30분마다”처럼 일정한 주기로 작업을 실행하는 방식이다. 예를 들어 “매 5분마다 새 JIRA 티켓이 있는지 확인하고, 있다면 코딩 에이전트를 실행해 트리아지(triage)하고 수정하라”는 식의 자동화가 여기 해당한다.
두 번째는 **크론(Cron)**이다. 하트비트가 주기 기반이라면, 크론은 “매일 오전 9시”, “매주 일요일 밤”처럼 특정 시점에 실행된다. 일정이 더 명시적이고 고정적인 것이 특징이다.
세 번째는 **훅(Hook)**이다. 특정 이벤트가 발생했을 때 에이전트를 실행하는 방식으로, 내부 라이프사이클 이벤트(예: 특정 도구 호출, 세션 시작)나 외부 웹훅(예: “이메일을 수신할 때마다 에이전트를 실행하라”)이 트리거로 작동한다.
네 번째는 **목표(Goal)**다. 강연자는 이것을 가장 새로운 유형으로 소개한다. 목표 기반 루프는 단순히 시간이나 이벤트에 반응하는 것이 아니라, 결과(Outcome)를 정의하고 그 결과가 측정·검증될 때까지 에이전트를 계속 실행한다. 에이전트가 막히거나, 정의된 성공 기준을 충족할 때 루프가 종료된다. 강연자에 따르면, 목표 루프는 Claude Code와 Codex 양쪽 모두에서 핵심 기능(First-class citizen)으로 구현되어 있다.
05:32 - 목표(Goal) 루프의 정의 설명 — 결과가 측정·검증될 때까지 에이전트를 실행하는 새로운 루프 유형 소개
효과적인 루프를 구성하는 다섯 가지 요소
강연자는 Adi Osmani가 작성한 루프 엔지니어링 관련 아티클을 인용하며, 좋은 루프를 만들기 위해 필요한 요소들을 정리한다.
💡 [영상 참조] 강연자는 이 시점에서 해당 아티클의 내용이 담긴 화면을 보여주며 설명합니다. 📺 원본 영상에서 확인하세요.
자동화(Automation) 그 자체가 첫 번째 요소다. 어떤 트리거에 의해 무슨 작업을 수행할지 명확히 정의된 자동화 명세가 필요하다. Claude Code에서는 이것을 ‘루틴(Routines)‘이라 부르고, Codex에서는 ‘자동화(Automations)’ 탭에서 설정한다.
**워크트리(Work Trees)**는 에이전트의 작업을 다른 에이전트의 작업과 격리하는 메커니즘이다. 여러 루프가 동시에 실행될 때 서로의 코드베이스를 침범하지 않도록 샌드박스 환경을 제공한다. 강연자는 이를 Git 기초 개념으로 설명하며, 루프 환경에서는 필수적인 요소라고 강조한다.
**스킬(Skills)**은 에이전트가 반복적으로 수행하는 작업의 방식을 정의해 둔 재사용 가능한 루틴이다. 강연자는 이에 관한 별도 에피소드가 있다고 언급한다.
**플러그인과 커넥터(Plugins & Connectors)**는 에이전트가 외부 도구와 연결되는 방식이다. GitHub, Google Docs, Google Calendar, Slack 등의 커넥터와, 그 도구들을 어떻게 사용할지 지시하는 플러그인이 포함된다.
**서브 에이전트(Sub-agents)**는 메인 스레드에서 파생되어 특정 작업, 특히 검증 작업을 전담하는 하위 에이전트다. Claude Code와 Codex 모두 이를 지원한다.
마지막으로 **상태 추적(State Tracking)**이 있다. 강연자는 이를 “할 일 목록”에 비유한다. Markdown 파일로 저장하거나 Linear 같은 태스크 트래커를 사용할 수 있으며, 루프가 어디까지 왔는지를 추적하는 데 쓰인다.
이 모든 요소를 조합하면, 자율적으로 시작되고 도구를 활용하며 서브 에이전트를 파견하고 스스로 작업을 마무리하는 완전한 루프 생태계가 구성된다.
07:36 - 워크트리, 스킬, 플러그인, 서브 에이전트, 상태 추적 등 루프 구성 요소 설명 구간
루프 설계의 사고방식 — “직원을 온보딩하라”
강연자는 루프 설계를 바라보는 강력한 프레임을 제시한다. 루프를 설계하는 것은 곧 직원을 온보딩하는 것과 같다는 것이다. 당신은 에이전트라는 직원에게 역할과 반복적으로 수행해야 할 업무를 부여하는 관리자다.
예를 들어 “매주 금요일에 내 캘린더를 검토해서 취소된 미팅, 더 효율적으로 쓸 수 있었던 시간, 후속 조치가 필요한 항목을 정리하고 Slack 메시지를 보내줘”라고 지시한다면, 그것은 곧 비서 에이전트를 위한 루프다. “매 시간마다 GitHub 이슈를 확인하고, 처리할 것이 있으면 트리아지하고 코드를 작성해 코드 리뷰에 올려줘”라면 소프트웨어 엔지니어 에이전트 루프가 된다.
나아가, “PR을 받을 때마다 정의된 코드 표준을 충족하고 모든 린트와 검사가 통과될 때까지 반복해서 작업하라”는 지시는 목표(Goal) 루프의 전형적인 사례다. 강연자는 이 프레임 덕분에 “루프를 설계한다는 것이 복잡한 워크플로 다이어그램이 아니라, 그냥 사람에게 직무를 부여하는 것”임을 직관적으로 이해할 수 있다고 말한다.
실습 1 — Claude Code에서 Daily PR 에이징 리뷰 루틴 만들기
강연자는 먼저 가볍고 비기술적인 예시로 Claude.ai 웹 인터페이스의 ‘아침 브리핑(Morning Briefing)’ 기능을 언급한다. 정기적으로 실행되고, 스스로 무엇을 해야 할지 프롬프트하고, 완료하는 이 기능 자체가 이미 루프라는 것이다. Claude Code에서는 이것을 ‘루틴(Routines)‘이라고 부르며, 루프 입문자에게 가장 접근하기 쉬운 출발점이 된다.
그런 다음 강연자는 실질적인 엔지니어링 팀 문제를 해결하기 위한 루틴을 Claude Code에서 직접 생성한다. 배경은 이렇다. 에이전트를 활용해 PR을 대거 생성하다 보니, 오래된 PR을 방치하는 일이 잦아졌고 약 40개가 쌓여 있다. 특히 신경 써야 할 것은 아무도 돌보지 않아 오래 방치된 PR들이다.
강연자가 설정한 루틴의 핵심 지시 내용은 다음과 같다. ChatPRD(강연자가 운영하는 것으로 보이는 애플리케이션)의 오픈 PR을 확인하고, 12시간 이상 열려 있는 것을 대상으로 머지 준비 상태를 검토한다. 직접 처리 가능한 PR은 서브 스레드를 생성해 모든 머지 체크가 초록불이 될 때까지 바비싯(babysit)한다. 그렇지 않은 경우 Slack의 프로덕트 채널에 팀에게 메시지를 보내 조치를 촉구한다. 실행 시각은 매일 오전 10시 15분으로 설정했다.
13:43 - Claude Code에서 Daily PR 에이징 리뷰 루틴 생성 화면 — 12시간 이상 경과 PR 검토 및 서브 에이전트 파견 설정
이 루틴의 설계에서 주목할 점은 두 가지 성공 기준이 병렬로 설정되어 있다는 것이다. 하나는 에이전트가 직접 PR을 바비싯하여 머지 가능 상태로 만드는 것이고, 다른 하나는 그것이 불가능할 경우 팀에게 알리는 것이다. 또한 강연자가 명시적으로 “처리 가능한 PR이 있으면 서브 스레드를 생성하라”고 지시함으로써, 메인 루프가 서브 에이전트를 파견하는 구조를 자연스럽게 구현했다. 루프가 루프를 만드는 구조의 첫 번째 사례다.
실습 2 — Codex에서 메타 루프 만들기 (서브 에이전트 + 목표 루프 조합)
두 번째 실습은 한층 복잡하고 흥미롭다. Codex의 자동화 탭에는 사전 제작된 템플릿이 있는데, 강연자는 “최근 PR 및 리뷰를 바탕으로 심화할 스킬을 제안하라(From recent PRs and reviews, suggest next skills to deepen)“는 템플릿을 선택한다.
19:53 - Codex 자동화 탭의 템플릿 목록 화면 — 사전 정의된 루프 아이디어들 나열
강연자가 이 템플릿에 추가한 구체적인 지시는 다음과 같다. 에이전트 또는 개발자가 작업 결과를 자동으로 검증할 수 있는 도구(특히 커맨드라인 도구나 MCP)가 개발된 경우, 그에 대한 스킬이 반드시 존재해야 한다. 그리고 새로운 스킬을 발견하면, 별도의 서브 스레드를 생성하고 해당 스킬을 레포 베이스 브랜치에서 검증하되, 목표(Goal) 루프를 사용해 실제로 품질 높은 결과를 내는지 확인하라.
이 자동화를 실행하자 에이전트는 곧바로 실행에 들어가 레포의 최근 코드를 분석했다. 그 결과 “Chat Smoke CLI 스킬”이 강력한 자동화 후보로 식별되었다. 이 도구는 강연자가 UI 없이 커맨드라인에서 앱을 테스트하기 위해 직접 제작한 것이었다. 메인 에이전트는 즉시 서브 에이전트 두 개를 파견했는데, 하나(Gauss)는 Chat Smoke CLI 스킬 검증을 담당하고, 다른 하나(Galileo)는 GitHub 코멘트 처리 스킬 검증을 맡았다. 두 서브 에이전트 모두 목표(Goal) 루프를 기반으로 동작하며, 검증이 완료될 때까지 자율적으로 반복 작업을 수행한다.
23:46 - Codex 메타 루프 실행 후 서브 에이전트(Gauss, Galileo) 파견 화면 — 각각 다른 스킬 검증 목표 루프를 실행 중
강연자는 이 구조를 “메타 루프”라고 부른다. 매주 금요일 실행되는 스케줄 루프가 메인 에이전트를 시작시키고, 그 에이전트가 서브 에이전트를 파견하며, 각 서브 에이전트는 목표 기반 루프로 동작한다. 스케줄, 서브 에이전트, 목표 루프가 세 겹으로 중첩된 이 구조는 강연자 스스로도 이번 에피소드 중에 아이디어를 떠올렸다고 밝혔다.
루프 사용 시 주의해야 할 두 가지 경고
강연자는 루프의 효용성을 강조하면서도, 마무리 무렵에 현실적인 경고를 두 가지 제시한다.
25:47 - 루프 사용 경고 구간 — 토큰 비용 문제 및 목표 기반 프롬프트의 정밀도 요건 설명
비용 문제 — 루프는 토큰을 태운다
루프, 특히 목표 기반 루프는 성공 기준을 충족할 때까지 계속 실행된다. 이는 곧 AI 토큰이 지속적으로 소모됨을 의미한다. 검증 기준을 너무 느슨하게 설정하거나, 프롬프트를 허술하게 작성하면 에이전트가 불필요하게 많은 반복을 수행하며 비용이 눈덩이처럼 불어난다. 강연자는 “루프는 돈을 쓰기 매우 좋은 방법”이라고 솔직하게 경고하며, 어디에 루프를 적용할지 신중히 선택하고 비용과 효율성 양면에서 모니터링해야 한다고 강조한다.
프롬프트 정밀도 — 루프 프롬프트는 별도의 기술이다
강연자는 이 에피소드에서 자신이 작성한 루프 프롬프트들이 사실 그다지 잘 쓰여진 것이 아니라고 인정한다. 일반적인 대화형 프롬프트와 달리, 목표 기반 루프의 프롬프트는 평가 기준(Evaluation Criteria)과 성공 기준(Success Criteria)을 매우 정밀하게 명시해야 한다. 이 두 가지가 불명확하면 에이전트는 방향을 잃고 토큰만 낭비하게 된다. 강연자는 OpenAI가 Codex용 목표 작성 가이드를 제공하고 있으며, 자신은 종종 Codex에게 목표 자체를 스스로 작성하게 한다고 덧붙인다. 루프 기반 프롬프팅, 특히 목표 기반 프롬프팅은 일반 대화보다 훨씬 높은 정밀도를 요구하는 독자적인 기술 분야다.
마무리 — 루프를 쓸 때와 쓰지 않을 때
강연자의 핵심 메시지는 루프를 위한 루프를 만들지 말라는 것이다. “매일 또는 매 시간 정해진 작업이 반복적으로 수행될 수 있다”는 확신이 들 때, 그때가 루프를 도입할 적기다. 아침 브리핑, Gmail 인박스 정리, PR 검토, 스킬 검증, 연구 에이전트 파견 등 반복성과 자율성이 공존하는 영역이라면 루프는 강력한 도구가 된다.
그러나 자신이 직접 모니터링하고 싶은 작업, 결과 기준이 명확하지 않은 작업, 혹은 비용 대비 효율이 불분명한 작업이라면 여전히 직접 프롬프트하는 방식이 낫다. 루프는 인간과 에이전트 사이의 역할 분담을 재정의하는 도구이지, 모든 AI 작업을 대체하는 만능 해결책이 아니다.
강연자는 마지막으로 이렇게 정리한다. “루프는 당신의 작은 에이전트 직원에게 일정에 따른 업무를 부여하거나, 완료 가능한 목표를 주고 혼자 해내게 하는 방법이다. 그리고 그 일이 끝날 때까지 내버려 두는 것, 그것이 루프다.”
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Loop engineering for beginners |
| 채널 | How I AI |
| 리포트 작성 | 2026-06-18 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.