Loop Engineering

3줄 요약

1. Addy Osmani가 2026년 6월 7일 자기 블로그에 올린 글로, Peter Steinberger와 Anthropic의 Claude Code 책임자 Boris Cherny가 던진 한 문장 — “이제 에이전트에게 프롬프트하지 말고, 에이전트를 프롬프트하는 루프를 설계하라” — 에서 출발해 ‘루프 엔지니어링’이 무엇인지를 풀어낸다.
2. 루프는 다섯 조각(자동화·워크트리·스킬·플러그인과 커넥터·서브에이전트)과 한 개의 기억(디스크에 남는 상태 파일)으로 이루어지며, Codex 앱과 Claude Code 양쪽에 이 조각들이 이미 제품 안에 들어와 있어 더 이상 직접 bash 더미를 짜서 유지할 필요가 없다.
3. 다만 루프가 좋아질수록 오히려 더 날카로워지는 세 문제 — 검증·이해의 부패·인지적 항복 — 는 여전히 사람의 몫이며, 같은 루프라도 그것을 쓰는 사람에 따라 정반대의 결과가 난다.

루프 엔지니어링이란 무엇인가

저자는 루프 엔지니어링을 이렇게 정의한다. 에이전트를 프롬프트하는 사람의 자리에서 자기 자신을 치워 내고, 그 일을 대신할 시스템을 설계하는 것. 여기서 루프란 목적을 정의해 두면 AI가 완료될 때까지 반복하는 재귀적 목표를 가리킨다.

지난 2년 동안 코딩 에이전트에게서 무언가를 얻어 내는 방식은 한결같았다. 좋은 프롬프트를 쓰고 충분한 맥락을 넘긴다. 한 번 입력하고, 돌아온 것을 읽고, 다음을 입력한다. 에이전트는 도구였고 나는 그 도구를 처음부터 끝까지 손에 쥐고 있었다. 저자는 그 시대가 끝나가고 있다고 본다.

이제는 작은 시스템을 만든다. 일을 찾아내고, 나눠 주고, 검사하고, 끝난 것을 적어 두고, 다음에 할 일을 정하는 시스템. 그리고 그 시스템이 나 대신 에이전트를 찔러 깨운다. 저자는 이것을 자신이 앞서 쓴 두 개념과 연결한다. 하나의 에이전트가 그 안에서 도는 환경을 만드는 에이전트 하네스 엔지니어링, 그리고 소프트웨어를 만들어 내는 시스템인 팩토리 모델이다. 루프 엔지니어링은 하네스보다 한 층 위에 앉는다. 하네스이되 타이머 위에서 돌고, 작은 조력자들을 띄우고, 스스로에게 먹이를 준다.

저자가 놀란 지점은 이것이 더 이상 도구 싸움이 아니라는 사실이다. 1년 전이라면 루프를 원할 때 bash 더미를 쌓아 직접 영원히 유지해야 했고 그것은 온전히 내 것이자 나만의 것이었다. 그런데 이제 그 조각들이 제품 안에 그대로 실려 나온다. Steinberger가 꼽은 목록은 Codex 앱에, 그리고 거의 똑같이 Claude Code에 들어맞는다. 모양이 같다는 걸 알아채고 나면 어느 도구냐를 두고 다투는 일을 멈추게 된다. 어느 쪽에 앉아 있든 여전히 작동하는 루프를 설계하면 그만이다.

다섯 조각과 한 개의 기억

루프에는 다섯 가지가 필요하고, 그다음에 무언가를 기억해 둘 한 곳이 필요하다.

1. 자동화(Automations) — 일정에 맞춰 저절로 발동해 발견과 분류(triage)를 스스로 한다.
2. 워크트리(Worktrees) — 병렬로 일하는 두 에이전트가 서로 밟지 않도록 격리한다.
3. 스킬(Skills) — 에이전트가 그냥 추측해 버릴 프로젝트 지식을 적어 둔다.
4. 플러그인과 커넥터(Plugins and connectors) — 에이전트를 내가 이미 쓰는 도구들에 꽂는다.
5. 서브에이전트(Sub-agents) — 하나가 아이디어를 내면 다른 하나가 그것을 검사한다.

그리고 여섯 번째, 기억이다. 마크다운 파일이든 Linear 보드든, 하나의 대화 바깥에 살면서 무엇이 끝났고 다음이 무엇인지를 쥐고 있는 무언가. 너무 단순해 중요해 보이지 않지만, 오래 도는 모든 에이전트가 기대는 바로 그 장치다. 모델은 실행과 실행 사이에 모든 것을 잊으므로, 기억은 컨텍스트가 아니라 디스크 위에 있어야 한다. 에이전트는 잊지만, 리포지토리는 잊지 않는다.

저자는 두 제품 모두 다섯 조각을 이제 전부 갖췄다며 다음 대응표를 제시한다.

이름은 여기저기 조금씩 다르지만 능력은 같은 것이다.

자동화 — 이것이 심장 박동이다

자동화는 루프를 한 번 돌리고 마는 단발 실행이 아니라 실제 루프로 만들어 주는 장치다. Codex 앱에서는 Automations 탭에서 프로젝트, 실행할 프롬프트, 빈도, 그리고 내 로컬 체크아웃에서 돌릴지 백그라운드 워크트리에서 돌릴지를 고른다. 무언가를 찾아낸 실행은 Triage 인박스로 가고, 아무것도 못 찾은 실행은 알아서 보관된다. OpenAI는 내부에서 일일 이슈 분류, CI 실패 요약, 커밋 브리핑 작성, 지난주에 누가 넣은 버그 사냥 같은 지루한 일에 이를 쓴다. 자동화는 스킬을 호출할 수 있어, 일정 안에 거대한 지시문 벽을 붙여 넣는 대신 $skill-name만 쏘면 된다.

Claude Code는 스케줄링과 훅으로 같은 곳에 도달한다. /loop로 프롬프트나 명령을 일정 간격으로 돌리고, cron 태스크를 잡고, 에이전트 생애주기의 특정 시점에 훅으로 셸 명령을 쏘고, 노트북을 닫은 뒤에도 계속 돌리고 싶으면 GitHub Actions로 통째 밀어 넣는다.

세션 안에서 알아 둘 만한 두 번째 프리미티브가 있는데, 이 글이 말하려는 바에 가장 가깝다. /loop는 주기마다 다시 돈다. /goal은 내가 적어 둔 조건이 실제로 참이 될 때까지 계속 가고, 매 턴 뒤에 별도의 작은 모델이 끝났는지를 검사한다. 코드를 쓴 에이전트가 채점하는 에이전트가 아니다. “test/auth의 모든 테스트가 통과하고 lint가 깨끗하다” 같은 걸 주고 자리를 떠나면 된다. Codex에도 같은 /goal이 있고, 검증 가능한 정지 조건이 성립할 때까지 턴을 넘겨 가며 일하며 일시정지·재개·초기화를 지원한다.

워크트리 — 병렬이 혼돈으로 바뀌지 않도록

에이전트를 둘 이상 돌리는 순간 파일이 충돌하기 시작하고, 그것이 곧 실패가 된다. 두 에이전트가 같은 파일을 쓰는 것은, 서로 말도 맞추지 않은 두 엔지니어가 같은 라인에 커밋하는 것과 똑같은 골칫거리다. git 워크트리가 이를 푼다. 같은 리포 히스토리를 공유하면서 각자의 브랜치 위에 놓인 별도의 작업 디렉토리이므로, 한 에이전트의 편집이 다른 쪽 체크아웃을 건드릴 수가 없다.

Codex는 워크트리 지원을 내장해 여러 스레드가 한 리포를 동시에 두드려도 부딪히지 않게 한다. Claude Code는 git worktree, 세션을 자기 체크아웃에서 여는 --worktree 플래그, 그리고 서브에이전트에 붙이는 isolation: worktree 설정으로 같은 격리를 준다. 저자는 한 가지를 분명히 한다. 워크트리는 기계적 충돌을 없애 주지만, 여전히 천장은 나다. 몇 개를 실제로 돌릴 수 있느냐를 정하는 것은 도구가 아니라 내 리뷰 대역폭이다.

스킬 — 매번 프로젝트를 설명하지 않도록

스킬은 매 세션 같은 프로젝트 맥락을 금붕어처럼 다시 설명하는 일을 멈추는 방법이다. 두 도구 모두 같은 형식을 쓴다. 지시와 메타데이터를 담은 SKILL.md가 든 폴더, 그리고 선택적인 스크립트·참조·에셋. Codex는 $나 /skills로 부르거나, 작업이 스킬 설명과 맞으면 저절로 실행한다. 그래서 영리한 설명보다 빡빡하고 지루한 설명이 더 낫다.

스킬은 의도(intent)가 거듭 비용으로 청구되는 일을 멈추는 자리이기도 하다. 에이전트는 매 세션 차갑게 시작하고 의도에 난 구멍을 자신만만한 추측으로 채운다. 스킬은 그 의도를 바깥에 적어 둔 것이다. 관행, 빌드 단계, “그 한 번의 사고 때문에 우리는 이렇게 하지 않는다” 같은 것을 한 번 적어 두면 에이전트가 매 실행마다 읽는다. 스킬이 없으면 루프는 매 주기 프로젝트 전체를 0에서 다시 유도하고, 스킬이 있으면 그것이 복리로 쌓인다.

한 가지 구분. 스킬은 저작 형식이고 플러그인은 그것을 배포하는 방법이다. 여러 리포에 스킬을 공유하거나 몇 개를 묶고 싶을 때 플러그인으로 패키징한다. Codex에서도, Claude Code에서도 참이다.

플러그인과 커넥터 — 루프가 진짜 도구를 만진다

파일시스템만 볼 수 있는 루프는 작은 루프다. MCP 위에 세워진 커넥터는 에이전트가 이슈 트래커를 읽고, 데이터베이스를 질의하고, 스테이징 API를 치고, Slack에 메시지를 떨어뜨리게 해 준다. Codex와 Claude Code 모두 MCP를 말하므로 한쪽을 위해 쓴 커넥터가 다른 쪽에서도 대개 그대로 작동한다. 플러그인은 커넥터와 스킬을 함께 묶어, 동료가 내 설정을 처음부터 재구성하는 대신 한 번에 설치하게 한다.

이것이 “여기 고침이 있다"고 말하는 에이전트와, PR을 열고 Linear 티켓을 연결하고 CI가 초록이 되면 채널에 알림을 띄우는 루프의 차이다. 커넥터는 루프가 그저 무엇을 할 수 있을지 말하는 대신 실제 내 환경 안에서 행동하게 하는 이유다.

서브에이전트 — 만드는 자와 검사하는 자를 떼어 놓는다

루프에서 가장 쓸모 있는 구조적 장치는, 단연코, 쓰는 자와 검사하는 자를 가르는 것이다. 코드를 쓴 모델은 자기 숙제를 너무 후하게 채점한다. 다른 지시를 받은, 때로는 다른 모델인 두 번째 에이전트가 첫 번째가 스스로를 설득해 넘긴 것을 잡아낸다.

Codex는 요청할 때만 서브에이전트를 띄워 동시에 돌리고 결과를 하나의 답으로 접어 넣는다. .codex/agents/의 TOML 파일로 이름·설명·지시, 그리고 선택적 모델과 추론 강도를 정의하므로, 보안 리뷰어는 높은 강도의 강한 모델로 두고 탐색기는 빠른 읽기 전용으로 둘 수 있다. Claude Code는 .claude/agents/의 서브에이전트와 일을 주고받는 에이전트 팀으로 같은 일을 한다. 흔한 분담은 하나가 탐색하고, 하나가 구현하고, 하나가 스펙에 비추어 검증하는 것이다.

루프 안에서 이것이 특히 중요한 이유는, 루프가 내가 지켜보지 않는 동안 돌기 때문이다. 내가 실제로 신뢰하는 검증기가 있어야만 자리를 떠날 수 있다. 서브에이전트는 각자 자기 모델과 도구 작업을 하므로 토큰을 더 태운다. 그러니 두 번째 의견에 값을 치를 만한 곳에 써야 한다. 저자는 이것이 Claude Code의 /goal이 내부에서 하는 일이라고 덧붙인다. 작업을 한 모델이 아니라 신선한 모델이 루프가 끝났는지를 정한다 — 만드는 자와 검사하는 자의 분리를 정지 조건 자체에 적용한 것이다.

하나의 루프는 어떤 모습인가

조각을 붙이면 하나의 스레드가 작은 관제판이 된다. 저자가 자주 쓴다는 한 가지 모양은 이렇다.

매일 아침 자동화가 리포 위에서 돈다. 그 프롬프트는 분류 스킬을 불러 어제의 CI 실패, 열린 이슈, 최근 커밋을 읽고 발견한 것을 마크다운 파일이나 Linear 보드에 적는다. 할 가치가 있는 발견마다 스레드가 격리된 워크트리를 열어 서브에이전트를 보내 고침 초안을 작성하게 하고, 두 번째 서브에이전트가 그 초안을 프로젝트 스킬과 기존 테스트에 비추어 리뷰한다.

커넥터가 루프로 하여금 PR을 열고 티켓을 갱신하게 한다. 루프가 처리하지 못하는 것은 내 Triage 인박스로 떨어진다. 상태 파일이 전체의 척추다. 무엇을 시도했고, 무엇이 통과했고, 무엇이 아직 열려 있는지를 기억하므로, 내일 아침 실행이 오늘 멈춘 곳에서 이어 간다.

저자는 강조한다. 여기서 내가 실제로 한 일을 보라. 나는 그것을 한 번 설계했다. 그 단계들 중 어느 것도 프롬프트하지 않았다. 그것이 Steinberger의 요점을 현실로 옮긴 것이고, Codex에서든 Claude Code에서든 조각이 같으므로 같은 루프다.

루프가 여전히 대신해 주지 않는 것

루프는 일을 바꿀 뿐 나를 일에서 지우지는 않는다. 그리고 세 가지 문제는 루프가 좋아질수록 오히려 더 날카로워진다.

검증은 여전히 내 몫이다. 지켜보지 않는 채 도는 루프는 지켜보지 않는 채 실수를 저지르는 루프이기도 하다. 검증기 서브에이전트를 만드는 자에게서 떼어 놓는 이유 자체가 루프의 “끝났다"를 의미 있게 만들기 위함인데, 그래도 “끝났다"는 증명이 아니라 주장이다. 저자가 거듭하는 한 줄 — 내 일은 작동을 내가 확인한 코드를 내보내는 것이다.

내 이해는 방치하면 부패한다. 루프가 내가 쓰지 않은 코드를 빠르게 내보낼수록, 존재하는 것과 내가 실제로 파악한 것 사이의 간극이 커진다. 이것이 이해 부채(comprehension debt)이고, 매끄러운 루프는 루프가 만든 것을 내가 읽지 않는 한 그 부채를 더 빨리 불린다.

편안한 자세가 위험한 자세다. 루프가 스스로 돌면 의견을 갖기를 멈추고 돌려주는 것을 그냥 받아들이고 싶어진다. 저자는 그것을 인지적 항복(cognitive surrender)이라 부른다. 루프를 설계하는 일은 판단을 가지고 할 때는 치료약이고, 생각을 피하려고 할 때는 촉진제다. 같은 행동, 정반대의 결과.

가장 눈여겨본 대목

내가 가장 곱씹은 것은 마지막의 한 문장이다. “두 사람이 똑같은 루프를 만들어도 완전히 정반대의 결과를 얻을 수 있다.” 한 사람은 깊이 이해한 일을 더 빨리 해내려고 루프를 쓰고, 다른 사람은 그 일을 아예 이해하지 않으려고 루프를 쓴다. 루프는 그 차이를 모른다 — 아는 것은 나다.

저자는 이것이 루프 설계를 프롬프트 엔지니어링보다 쉽게가 아니라 더 어렵게 만드는 지점이라고 본다. Cherny의 요점은 일이 쉬워졌다는 게 아니라 레버리지 지점이 옮겨갔다는 것이다. 그래서 글의 맺음말은 한 문장으로 압축된다 — “루프를 만들어라. 다만 그냥 시작 버튼을 누르는 사람이 아니라, 끝까지 엔지니어로 남을 작정인 사람처럼 만들어라.”

다만 저자 자신도 회의적인 태도를 숨기지 않는다. 아직 초기이고, 토큰 비용에 반드시 조심해야 하며, 직접 에이전트에게 프롬프트하는 것도 여전히 효과적이라고 분명히 밝힌다. 결국 균형을 찾는 일이라는 것이다.

출처

Addy Osmani, “Loop Engineering”, 2026년 6월 7일. 원문: https://addyosmani.com/blog/loop-engineering/

원문에는 본문 도식이 없고 글 말미의 저자 사진 한 장만 실려 있어, 그 사진을 커버로 삼고 본문은 텍스트 중심으로 옮겼다.