루프 엔지니어링: AI 에이전트를 직접 프롬프트하는 시대에서 루프를 설계하는 시대로
목차
개요
Addy Osmani는 자신의 X 글에서 코딩 에이전트와 협업하는 방식이 전환점을 맞이하고 있다고 설명한다. 지난 2년간의 접근 방식은 좋은 프롬프트와 충분한 컨텍스트를 에이전트에게 직접 전달하는 것이었다. 이제는 작업을 찾고, 배분하고, 검증하고, 결과를 기록한 뒤 다음 작업을 결정하는 작은 시스템을 만들어 그 시스템이 에이전트를 호출하게 하는 방향으로 바뀌고 있다. 이 개념이 바로 루프 엔지니어링(Loop Engineering)이다.
루프 엔지니어링이란
루프 엔지니어링은 에이전트에게 직접 프롬프트를 입력하는 사람을 대체하는 시스템을 설계하는 것이다. 여기서 루프는 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표로 이해할 수 있다. Anthropic Claude Code 책임자인 Brian Cherny는 “나는 더 이상 Claude에 직접 프롬프트하지 않는다. Claude에 프롬프트하고 무엇을 해야 할지 파악하는 루프를 돌린다. 내 역할은 루프를 작성하는 것이다”라고 밝혔다. 루프 엔지니어링은 하네스(harness)보다 한 단계 위에 위치하며, 타이머로 실행되고 보조 프로세스를 생성하며 스스로를 유지한다. Claude Code와 Codex는 이를 위한 다섯 가지 구성 요소를 모두 지원한다.
다섯 가지 구성 요소와 메모리
Automations
Automations는 스케줄에 따라 실행되며 자동으로 발견과 트리아지를 수행하는 구성 요소다. Codex 앱의 Automations 탭에서는 프로젝트, 프롬프트, 주기, 로컬 또는 백그라운드 워크트리를 선택할 수 있고 결과는 Triage 인박스로 전달된다. Claude Code에서는 /loop(주기 재실행), cron, hooks, GitHub Actions로 동일한 기능을 수행한다. /loop은 주기적으로 재실행하며, /goal은 조건이 충족될 때까지 계속 실행되고 매 턴 후 별도의 소형 모델이 완료 여부를 검증한다. 이 구조는 작성자와 채점자를 분리하는 원리를 따른다. Codex에도 동일한 /goal 기능이 있다.
Worktrees
Worktrees는 병렬로 실행되는 에이전트들 사이의 파일 충돌을 방지하는 구성 요소다. git worktree는 동일한 저장소 히스토리를 공유하는 별도의 작업 디렉터리와 브랜치를 제공한다. Claude Code는 --worktree 플래그와 서브에이전트 설정의 isolation: worktree 옵션을 지원한다.
Skills
Skills는 매 세션마다 프로젝트 컨텍스트를 반복해서 설명하지 않아도 되게 해주는 구성 요소다. SKILL.md 폴더 형식으로 관리되며, 선택적으로 스크립트, 레퍼런스, 에셋을 포함할 수 있다. 의도(intent)를 외부 파일에 명시해 두면 매 사이클마다 재유도할 필요가 없어진다.
Plugins / Connectors
Plugins와 Connectors는 MCP(Model Context Protocol) 기반으로 이슈 트래커, 데이터베이스, 스테이징 API, Slack 등 외부 시스템과 연결하는 구성 요소다. 플러그인은 커넥터와 스킬을 묶어 배포하는 단위로 사용된다.
Sub-agents
Sub-agents는 생성하는 역할과 검증하는 역할을 분리하는 구성 요소다. Codex에서는 .codex/agents/ 내 TOML 파일로, Claude Code에서는 .claude/agents/ 디렉터리로 정의된다. 일반적으로 탐색(exploration), 구현(implementation), 검증(verification) 역할로 나뉜다. /goal의 완료 판정 역시 같은 분리 원리를 따른다.
메모리
메모리는 단일 대화 범위 밖에 존재하는 마크다운 파일이나 Linear 보드를 통해 구현된다. 모델은 실행 사이에 상태를 잊기 때문에 기억은 반드시 디스크나 외부 저장소에 보관해야 한다.
실제 루프 예시
다음은 위 구성 요소들이 어떻게 하나의 루프를 이루는지 보여주는 예시다.
매일 아침 automation이 저장소에서 트리아지 스킬을 호출해 전날의 CI 실패, 이슈, 커밋 내역을 읽고 마크다운 파일 또는 Linear 보드에 기록한다. 가치 있는 발견이 있을 때마다 격리된 워크트리를 열고 첫 번째 서브에이전트가 초안을 작성한다. 두 번째 서브에이전트는 정의된 스킬과 테스트 기준에 따라 초안을 검토한다. 커넥터가 PR을 열고 관련 티켓을 갱신한다. 처리하지 못한 항목은 트리아지 인박스로 넘어간다. 상태 파일이 이 전체 흐름의 중심축 역할을 담당한다.
루프가 대신하지 못하는 것
Osmani는 루프 엔지니어링에 대한 기대와 함께 명확한 한계도 짚는다.
첫째, 검증은 여전히 사람의 몫이다. 무인 루프는 무인 상태로 실수도 저지른다.
둘째, 이해도는 방치하면 저하된다. 루프가 작업을 자동화할수록 사람이 도메인을 직접 이해하려는 노력이 줄어들 수 있다. 이를 comprehension debt(이해 부채)라 부를 수 있다.
셋째, 편안한 자세가 위험한 자세로 이어질 수 있다. 루프 설계가 판단을 가지고 이루어지면 생산성을 높이는 도구가 되지만, 사고를 회피하려는 목적으로 사용하면 오히려 문제를 가속시키는 수단이 된다.
결론
루프 엔지니어링은 AI 에이전트와 협업하는 방식의 다음 단계를 보여준다. Osmani는 직접 프롬프트하는 방식도 여전히 유효하며 균형이 핵심이라고 강조한다. 같은 루프를 사용하더라도, 깊이 이해한 영역을 더 빠르게 처리하는 데 활용하는 사람과 이해 자체를 회피하는 데 사용하는 사람의 결과는 정반대로 갈린다. 루프를 만들되, 단순히 버튼을 누르는 사람이 아니라 시스템을 설계하는 엔지니어로 남는 것이 핵심이다. 현재 이 방식은 아직 초기 단계이며, 토큰 비용과 품질 저하에 대한 주의도 여전히 필요하다.