해당 글은 코딩 에이전트(AI)를 활용하는 패러다임이 단순한 ‘프롬프트 입력(Prompting)’에서 ‘시스템 루프 설계(Loop Engineering)’로 진화에 대한 글에서 AI와 나눈 대화 속에서 인사이트 얻은 것을 작성 [LINK]
1. 루프 엔지니어링(Loop Engineering)의 정의
패러다임의 전환: 과거 2년 동안의 방식이 AI에게 좋은 프롬프트를 주고 매 턴 결과를 확인하는 ‘도구 조작’이었다면, 이제는 작업을 찾고, 배분하고, 검증하고, 기록하는 ‘작은 시스템(루프)을 구축하여 에이전트를 관리’하는 방식으로 변하고 있습니다.
핵심 개념: 사용자가 궁극적인 목적(
/goal)을 정의하면, 시스템이 그 조건이 참(True)이 될 때까지 재귀적으로 작동하며 스스로 유지되는 자동화 환경입니다.
2. 루프를 구동하는 5가지 핵심 구성 요소 (+ 1가지 저장소)
Claude Code와 Codex는 명칭만 다를 뿐, 이 5+1가지 메커니즘을 모두 내장하고 있습니다.
다.
| 구성 요소 | 역할 및 기능 | Claude Code의 구현 | Codex의 구현 |
| 1. 자동화 (Heartbeat) | 정해진 일정이나 훅(Hook)에 따라 스스로 실행되어 정보를 수집하고 문제를 해결하는 심장 박동 역할 | /loop, cron 작업, 훅(Hook), GitHub Actions 연동 | 자동화 탭, 실행 주기 설정, 트리아지 받은 편지함 |
| 2. 병렬 작업 트리 (Worktree) | 여러 에이전트가 동시에 작업할 때 파일이 충돌하거나 꼬이는 것을 방지하는 격리된 환경 | git worktree, --worktree 플래그, isolation: worktree | 자체 워크트리 지원 내장 (동시 접근 격리) |
| 3. 프로젝트 지식 (Skills) | 에이전트가 매 세션마다 컨텍스트를 잊지 않도록 프로젝트의 관례, 규칙, 의도를 문서화해 둔 스킬셋 | .claude/skills/ 폴더 내 지침 및 메타데이터 | .codex/agents/SKILL.md, 조건 일치 시 자동 호출 |
| 4. 플러그인 & 커넥터 (MCP) | 에이전트가 파일 시스템을 넘어 이슈 트래커, DB, Slack 등 외부 실제 도구와 상호작용하도록 연결 | MCP(Model Context Protocol) 기반 커넥터 지원 | MCP 기반 커넥터 지원 |
| 5. 하위 에이전트 (Sub-agents) | 코드를 작성하는 ‘제작자’와 이를 검증하는 ‘검토자’를 분리하여 상호 교차 검증하는 시스템 | .claude/agents/ 기반의 에이전트 팀 구성 | .codex/agents/ TOML 파일을 통한 역할/모델 분리 |
| + 메모리 (Disk Storage) | 모델은 세션이 끝나면 잊어버리므로, 완료된 작업과 남은 작업을 컨텍스트가 아닌 **디스크(마크다운, 리니어 보드 등)**에 저장 | 단일 대화 외부의 파일 또는 외부 상태 저장소 활용 | 단일 대화 외부의 파일 또는 외부 상태 저장소 활용 |
3. 루프 엔지니어링이란 무엇인가: 프롬프트 엔지니어링과의 패러다임 전환
AI와 협업하는 방식이 급격한 패러다임 전환을 맞이하고 있다. 지난 2년 동안 인공지능 코딩 에이전트를 활용하는 지배적인 방법은 고도화된 프롬프트 엔지니어링(Prompt Engineering)이었다.
사용자가 좋은 프롬프트를 작성하고, 충분한 코드 맥락(Context)을 제공하면, AI가 코드를 생성하고, 이를 다시 인간이 검토하여 다음 지시를 내리는 턴제(Turn-based) 방식이 주를 이루었다는 의미이다. 이 구조에서 에이전트는 단지 인간의 직접적인 조작을 기다리는 수동적인 도구에 머물렀다.
그러나 최근 피터 스타인버거(Peter Steinberger)와 앤트로픽(Anthropic)의 클로드 코드 책임을 맡고 있는 보리스 체르니(Boris Cherny)의 발언은 이러한 방식의 종말을 고하고 있다.
그들은 더 이상 에이전트에게 개별적인 프롬프트를 제공하지 않으며, 프롬프트를 제공하고 자율적으로 판단하여 작업을 완수하는 ‘시스템 루프(Loop)’를 설계하는 것이 엔지니어의 핵심 역할이라고 강조함.
루프 엔지니어링(Loop Engineering)은 사용자가 최종적인 목적과 검증 가능한 종료 조건만을 정의하면, AI 시스템이 목표를 달성할 때까지 자율적이고 재귀적으로 판단 및 수정을 반복하는 자율형 시스템을 설계하는 프로세스를 뜻한다.
이는 개발자가 매 턴마다 개입하던 수동 조작 방식에서 벗어나, 시스템 아키텍처 자체를 관리하는 방식으로의 진화를 의미함.
4. 에이전트 하네스 엔지니어링을 넘어선 자율형 시스템의 구축
루프 엔지니어링의 개념을 정확히 이해하기 위해서는 기존의 에이전트 하네스 엔지니어링(Agent Harness Engineering)과의 차이점을 명확히 해야 한다.
하네스 엔지니어링이 단일 에이전트가 안전하게 실행될 수 있는 격리된 환경(Sandbox), 파일 시스템 접근 권한, 실행 도구 등을 정적으로 구축해 주는 인프라적 접근이었다면, 루프 엔지니어링은 그 상위에 존재하는 동적 시스템 아키텍처라는 것이다.
하네스 모델이 일종의 ‘공장 기계와 거치대’를 만들어주는 작업이었다면,
루프 엔지니어링은 타이머와 크론(Cron) 작업에 의해 스스로 구동되고, 필요에 따라 스스로 하위 도우미(Sub-agents)를 생성하며, 실행이 끝난 후에도 자신의 상태를 유지하는 ‘자동화된 공장 라인 전체’를 설계하는 일이다.
1년 전까지만 해도 이러한 자율 반복 루프를 만들기 위해서는 수백 줄의 Bash 스크립트를 작성하고 지속적으로 유지보수해야 하는 기술적 부채가 존재했음. 하지만 현재는 Claude Code나 Codex와 같은 최신 도구들에 이러한 루프 제어 메커니즘이 제품 내부의 기본 기능으로 내장되기 시작하면서 대중화 단계에 접어들었다는 사실이다.
5. 코딩 에이전트와 협업하는 미래 지향적 엔지니어링 패러다임
이러한 변화는 단순한 도구의 업그레이드가 아니라 인간 엔지니어의 역할이 ‘코드 작성자’에서 ‘AI 오케스트레이터(Orchestrator)’로 이동함을 의미한다.
루프 엔지니어링 환경에서 엔지니어는 더 이상 개별 버그를 수정하기 위해 AI와 대화하지 않는다. 대신, 버그를 탐지하고, 격리된 브랜치를 생성하며, 코드를 수정하고, 테스트를 통과할 때까지 무한히 반복하는 전체 루프의 규칙과 파이프라인을 설계하게 된다는 점이다.
이것이 바로 미래의 코딩 패러다임이며, 개발자는 도구의 종속성에서 벗어나 어떤 도구를 사용하든 동일하게 자동작하는 보편적인 루프 아키텍처를 이해해야 한다.
다음 시리즈에서는 이 자율 루프를 구동하는 5가지 핵심 기계적 구성 요소와 외부 메모리 저장소에 대해 구체적인 사실을 기반으로 상세히 분석할 예정이다.