루프를 돌리는 여섯 개의 부품

"프롬프트를 대신할 시스템을 짜라." 커버스토리가 세운 이 정의는 손에 잡히지 않는 구호처럼 들린다. 하지만 애디 오스마니(Addy Osmani)가 2026년 6월 정식화한 루프 엔지니어링(loop engineering)은 추상론이 아니다. 그가 자신의 글에서 직접 열거한 대로, 그것은 오늘 당장 조립할 수 있는 여섯 개의 부품이고, 각 부품에는 이미 시장에 나와 있는 구체적인 구현 도구가 붙는다. 자동화·워크트리·스킬·플러그인/커넥터·서브에이전트, 그리고 여섯 번째로 강조되는 디스크 메모리다.

실무자에게 이 목록은 단순한 개념도가 아니라 조립 체크리스트다. 자율 루프를 짜겠다고 마음먹었다면 이 여섯 칸을 무엇으로 채울지가 곧 설계 그 자체이기 때문이다. 그래서 아래에서는 각 부품을 "무엇을 하는가"가 아니라 "이것이 빠지면 루프의 어디가 무너지는가"를 축으로 뜯어본다. 부품이 다 모여도 조립이 무너지는 세 지점 — 종료조건, 토큰 비용, 엔지니어의 안목 — 은 마지막에 따로 짚는다.

① 자동화(Automations) — 루프의 심장박동

첫 부품은 루프를 스스로 뛰게 만드는 방아쇠다. 스케줄(주기)이나 이벤트(빌드 실패, CI 신호, git 이벤트)를 트리거로 걸어, 사람이 버튼을 누르지 않아도 루프가 발동하도록 한다. 오스마니의 설명에 따르면 잘 짜인 자동화는 결과를 찾아낸 실행은 처리 대기함(Triage inbox)으로 보내고, 아무것도 못 찾은 실행은 스스로 아카이브한다.

이 부품이 없으면 루프는 시작 자체를 못 한다. 사람이 매번 "이제 돌아"라고 눌러줘야 한다면 그것은 결국 프롬프트 엔지니어링으로 되돌아간 것이다. 자동화는 정의의 '자율' 부분을 물리적으로 실현하는 심장박동이다. 무엇으로 구현하나 — Claude Code의 /loop(정해진 주기로 반복, 간격이 없으면 출력 속도에 맞춰 자체 조절), /goal(조건이 충족될 때까지), /schedule(루틴)이 대표적이고, 여기에 전통적인 cron과 GitHub Actions를 얹는다. Codex 쪽은 별도의 Automations 탭과 /goal을 제공한다.

② 워크트리(Worktree) — 충돌 없는 병렬 격리

여러 에이전트를 동시에 돌리려면 서로의 발을 밟지 않게 해야 한다. 워크트리는 각 에이전트에게 별도의 작업 디렉터리를 준다. 같은 저장소의 이력은 공유하되, 독립된 브랜치와 체크아웃을 갖는 방식이다. 오스마니의 표현을 빌리면 "한 에이전트의 편집이 다른 에이전트의 체크아웃을 말 그대로 건드릴 수 없는" 상태다.

이 부품이 없으면 병렬화가 곧 재앙이 된다. 두 에이전트가 같은 파일을 동시에 고치는 순간 루프는 충돌과 덮어쓰기의 진창에 빠진다. 무엇으로 구현하나 — git 표준 기능인 git worktree가 토대이고, Claude Code는 --worktree 플래그와 서브에이전트에 붙이는 isolation: worktree 설정으로 이를 감싼다. Codex는 스레드마다 "같은 이력을 공유하되 자기 폴더로 체크아웃된 저장소의 격리 사본"을 내장으로 만든다.

③ 스킬(Skill) — 매번 다시 설명하지 않기 위한 파일

루프는 매 실행마다 프로젝트의 맥락·규칙·빌드 절차를 다시 알아야 한다. 스킬은 이 지식을 파일에 한 번 적어두고 실행 때마다 참조하게 하는 부품이다. 오스마니는 재사용 폴더 안에 지시·스크립트·자산을 담은 SKILL.md를 두는 형식으로 설명하며, 이를 소홀히 할 때 쌓이는 '의도 부채(intent debt)'를 경고한다.

이 부품이 없으면 매 실행이 거대한 지시문의 재입력으로 시작된다. 반복될수록 지시는 흐려지고 루프는 프로젝트의 규칙을 잊는다. 무엇으로 구현하나 — Claude Code의 스킬은 폴더와 SKILL.md의 조합으로, 설명이 현재 작업과 맞으면 자동으로 로드된다. Codex도 같은 SKILL.md 포맷을 지원한다. 인접한 상시 지침 파일로 CLAUDE.md와 AGENTS.md가 있다. (일부 국내 정리 글은 스킬 폴더 안에 VISION·ARCHITECTURE·RULES.md 같은 하위 파일을 예로 들지만, 이는 정리자가 붙인 예시 수준으로 이해하면 된다.)

④ 플러그인·커넥터(Plugins & Connectors) — 말이 아니라 행동으로

에이전트가 말로만 끝내지 않고 실제로 무언가를 하게 하려면 외부 시스템과 이어져야 한다. 커넥터는 그 다리다. 오스마니의 말대로 커넥터는 에이전트가 "이슈 트래커를 읽고, 데이터베이스에 질의하고, 스테이징 API를 두드리고, 슬랙에 메시지를 남기게" 한다. 답변을 뱉는 대신 직접 PR을 열고 티켓을 잇는 것이다.

이 부품이 없으면 루프는 아무리 돌아도 세상에 흔적을 남기지 못한다. 검증과 배포로 이어지는 출구가 막힌 채 텍스트만 쌓인다. 무엇으로 구현하나 — 사실상 표준은 MCP(Model Context Protocol)다. MCP는 앤트로픽(Anthropic)이 2024년 11월 공개한 오픈 프로토콜로, GitHub·Slack·Git·구글 드라이브·Postgres 등의 공식 참조 서버를 제공한다. 슬랙 공식 MCP 서버는 2026년 2월 정식 출시(GA)된 것으로 알려졌다.

⑤ 서브에이전트(Sub-agent) — 자기 숙제를 자기가 채점하지 않도록

한 에이전트가 코드를 쓰고 그 코드를 스스로 평가하면 채점이 너무 후해진다. 오스마니의 문장이 핵심을 찌른다. "코드를 작성한 모델은 자기 숙제를 채점하기에는 지나치게 관대하다." 서브에이전트는 탐색·구현·검증 같은 역할별로 에이전트를 나눠 교차검증하게 하는 부품이다. 작성 에이전트와 별개의 검증 에이전트가 테스트·린트·명세에 대조해 채점한다.

이 부품이 없으면 루프는 자기 오류를 스스로 통과시키며 돈다. 무인 루프에서 이는 곧 잘못된 결과의 자동 승인이 된다. 무엇으로 구현하나 — 여기서 도구별 포맷이 갈리므로 정확히 구분해야 한다. Claude Code의 서브에이전트는 .claude/agents/ 아래의 마크다운 파일로, YAML 프론트매터(name·description·model·tools)와 시스템 프롬프트 본문으로 구성되며 독립된 컨텍스트 창에서 실행된다. Codex의 서브에이전트는 TOML 정의를 쓴다. (일부 2차 정리가 Claude Code까지 TOML로 적었으나 이는 오류다.)

⑥ 디스크 메모리(Memory) — 대화창이 꺼져도 남는 상태

여섯 번째 부품은 나머지 다섯과 결이 조금 다르다. 오스마니 자신도 이를 "기능 다섯에 더해진 여섯 번째"로 강조한다. 모델은 실행과 실행 사이에 모든 것을 잊기 때문에, 무엇을 시도했고 무엇이 남았는지를 대화 컨텍스트가 아니라 디스크에 적어둬야 한다. 그의 문장 그대로다. "모델은 실행 사이에 모든 것을 잊으므로, 메모리는 컨텍스트가 아니라 디스크에 있어야 한다."

이 부품이 없으면 세션이 끝나는 순간 루프는 기억상실에 걸린다. 다음 실행은 진행 상황을 모른 채 처음부터 다시 시작하고, 자율성의 연속성이 끊긴다. 무엇으로 구현하나 — 가장 단순하게는 진행·통과·미해결 상태를 적는 마크다운 파일이고, 팀 단위라면 MCP 커넥터로 연결한 Linear 보드 같은 티켓 시스템을 상태 저장소로 쓴다. 부품 ④(커넥터)와 ⑥(메모리)이 여기서 맞물린다.

이 조립을 무너뜨리는 세 가지 현실 장벽

여섯 부품을 다 갖췄다고 루프가 안전하게 도는 것은 아니다. 오스마니와 이를 실제로 운용해 본 실무자들이 공통으로 지목하는 붕괴 지점이 셋 있다.

첫째, 종료조건(Stop Rule)이 기계로 판별 가능해야 한다. "좋아 보이면 멈춰라" 같은 주관적 명령은 루프에 통하지 않는다. 오스마니의 원칙은 "모든 테스트 통과, 린트 오류 없음"처럼 기계가 참·거짓을 가릴 수 있는 조건을 먼저 정하라는 것이다. Claude Code의 /goal은 사람이 쓴 조건이 실제로 참이 될 때까지 돌고, 코드를 쓴 에이전트가 아니라 별도 모델이 완료를 검증한다. 실무에서는 세 가지 하드 스톱이 권장된다 — 반복 횟수 상한(통상 20회), 진척 정지 감지(같은 오류나 빈 diff가 N회 반복되면 중단), 그리고 예산 상한이다. 가드레일이 없으면 무한 루프와 예산 초과 청구가 뒤따른다.

둘째, 토큰 비용이 폭탄이 된다. 루프는 반복 구조인 데다 서브에이전트를 붙일수록 토큰을 더 태운다. 오스마니가 특히 강조한 항목이 바로 이것이다. "토큰 비용에는 반드시 주의해야 한다 — 토큰이 풍족하냐 부족하냐에 따라 사용 패턴이 크게 달라진다." 실무 관측치로 에이전트의 토큰 소비가 일반 채팅의 4배, 멀티에이전트는 최대 15배에 이른다는 보고가 있으나 이는 2차 인용치로 원측정 조건은 확인되지 않았다. 대응책의 원리는 두 가지다. 긴 컨텍스트를 싸게 처리하는 모델을 쓰고, 반복당 예산 상한을 거는 것. 저가·롱컨텍스트 모델의 한 예로 딥시크(DeepSeek) V4가 있다. 2026년 4월 24일 공식 출시된 이 모델은 1M(100만) 토큰 컨텍스트를 기본값으로 하고 최대 출력 384K 토큰을 지원하며, 백만 토큰당 출력 가격이 V4-Flash 0.28달러, V4-Pro 0.87달러(공식 가격 페이지 기준)로 매우 낮다. 다만 짚어둘 것 — "루프의 토큰 문제를 딥시크로 풀라"는 것은 오스마니의 처방이 아니다. 원문에는 특정 모델명이 없다. 딥시크 V4는 어디까지나 저가·롱컨텍스트라는 조건을 만족하는 실존 사례일 뿐이고, 성능 벤치마크 수치는 공식 확인분이 아니므로 여기서는 다루지 않는다.

셋째, 결국 엔지니어로 남아야 한다. 세 번째 장벽은 도구가 아니라 사람의 문제다. 오스마니의 경고는 단순하다. "무인으로 도는 루프는 무인으로 실수를 저지르는 루프이기도 하다." 그는 두 가지 잠식을 지목한다. 하나는 이해 부채 — 루프가 당신이 쓰지 않은 코드를 빠르게 내놓을수록, 실제 존재하는 것과 당신이 이해한 것 사이의 간극이 벌어진다. 다른 하나는 인지적 항복 — 루프가 알아서 돌면 의견을 갖기를 멈추고 결과를 그냥 받아들이고 싶어진다. 루프는 당신이 이해를 가속하는지 회피하는지 구분하지 못한다. 그 차이를 아는 것은 사람뿐이다. 그래서 그는 이렇게 맺는다. "루프를 지어라. 단, 그냥 실행 버튼을 누르는 사람이 아니라 계속 엔지니어로 남을 사람처럼 지어라."

여섯 부품은 오늘 조립할 수 있다. 도구도 다 나와 있다. 그러나 조립된 루프가 무엇을 만들어 내는지 끝까지 책임지는 자리 — 종료조건을 설계하고, 예산을 긋고, 결과를 검증하는 자리 — 는 여전히 사람의 몫으로 남는다. 그 자리를 비우지 않는 것이, 이 여섯 부품을 갖추는 것만큼이나 루프 엔지니어링의 일부다.