루프 엔지니어링 이란? — 프롬프트를 짜는 게 아니라 시스템을 짜는 시대(프롬프트 엔지니어링은 끝났다? 다음은 '루프 엔지니어링'이다)
-
728x90
안녕하세요! 갓대희입니다.
요즘 코딩 에이전트(스스로 코드를 읽고 고치는 AI 일꾼)를 다루는 방식이 조금씩 달라지고 있다. 핵심은 한 문장으로 줄일 수 있다. "AI한테 매번 시키지 말고, AI를 시키는 시스템을 짜라." 요즘 이 흐름을 루프 엔지니어링(loop engineering) 이라 부른다.
여기서 정말 달라지는 건 내 자리다. 매 줄 직접 지시하던 '실행자'에서, 루프를 설계하고 결과를 검토하는 '감독관'으로 옮겨간다. 그래서 이건 단순히 신규 기능이나 명령어 몇 개를 외우는 차원이 아니다. 내가 무슨 일을 하는 사람인지... 관점 자체가 바뀌는 이야기다.
여기서 루프(loop) 란, 쉽게 말해 목적만 정해두면 AI가 끝날 때까지 스스로 같은 일을 반복하는 작업 묶음이다. 빨래 건조기를 떠올리면 쉽다. 우리는 매 분마다 "더 돌려, 그만 돌려"라고 말하지 않는다. "이만큼 마르면 멈춰"라는 조건만 걸어두면 알아서 돈다. 루프 엔지니어링은 바로 그 건조기를 설계하는 일이다.
이 글에서는 Addy Osmani의 글 Loop Engineering을 기준으로 정리한다. 루프를 이루는 부품이 무엇인지, Claude Code와 Codex에서는 각각 어떻게 부르는지, 그리고 마지막에 꼭 짚어야 할 냉정한 현실까지 차례로 살펴보려 한다.
이 글의 핵심 5가지
흐름이 '프롬프트 쓰기'에서 '루프 설계'로 옮겨가고 있다 — Peter Steinberger, Boris Cherny가 같은 말을 한다.
루프를 만드는 핵심 부품은 5개 + 기억장치 1개다.
1년 전엔 직접 스크립트로 짜야 했지만, 지금은 Claude Code·Codex 둘 다 기본으로 갖췄다 — 이름만 다르고 기능은 같다.
에이전트(agent): 스스로 도구를 쓰고 판단해 일하는 AI. 단순 챗봇보다 한 단계 위, '일꾼'에 가깝다.
루프(loop): 목적만 주면 완료될 때까지 스스로 반복하는 작업 묶음.
오토메이션(automation): 정해진 시각·주기에 사람 없이 자동으로 시작되는 것.
워크트리(worktree): 한 저장소 안에서 AI마다 따로 떼어주는 독립 작업 폴더.
스킬(skill): 프로젝트 설명을 미리 적어둔 파일. AI가 작업마다 다시 읽는 '인수인계 노트'.
플러그인·커넥터(plugin·connector): AI를 외부 도구(이슈 트래커·Slack 등)에 연결하고, 그 묶음을 한 번에 설치하게 포장한 것.
서브에이전트(sub-agent): 본 작업과 별개로 띄우는 보조 AI. 보통 '검사역'으로 쓴다.
1. "프롬프트를 쓴다"에서 "루프를 짠다"로
지금까지 우리가 AI를 쓰던 방식은 대체로 프롬프트, 즉 대화형이었다. 한 줄 한 줄 시키고(프롬프트), AI가 답하고, 결과를 읽고, 다시 사람이 프롬프트를 입력하여 일을 이어 간다. 매 턴마다 사람이 직접 지시하는, 운전대를 손에서 놓지 않는 구조였다.
루프 엔지니어링은 이 운전대를 시스템에게 넘긴다. Addy Osmani의 표현을 그대로 옮기면 이렇다.
"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
(루프 엔지니어링이란, 에이전트에게 프롬프트를 쓰는 그 사람 자리에서 당신을 빼내는 것이다. 대신 그 일을 해줄 시스템을 당신이 설계한다.) — Addy Osmani
말로만 도는 유행도 아니다. 개발자 Peter Steinberger는 이렇게 못 박았다.
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."
(이제 코딩 에이전트에 프롬프트를 쓰지 마라. 에이전트에게 프롬프트를 던지는 루프를 설계하라.) — Peter Steinberger
Anthropic에서 Claude Code를 총괄하는 Boris Cherny도 같은 결의 말을 했다.
"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."
(나는 더 이상 Claude에 프롬프트를 쓰지 않는다. Claude에게 무엇을 할지 시키는 루프를 돌리고 있고, 내 일은 그 루프를 짜는 것이다.) — Boris Cherny
원문이 인용한 두 사람의 말은 같은 방향을 가리킨다. 지렛대의 받침점이 프롬프트 한 줄에서 루프 한 벌로 옮겨갔다는 뜻이다.
2. 루프를 이루는 다섯 부품과 기억장치 하나
그럼 루프는 무엇으로 만들까.
핵심 부품은 다섯 가지, 여기에 기억장치 하나가 더 붙는다.
1년 전만 해도 이걸 별도의 MCP를 사용하거나, 직접 셸 스크립트(터미널 명령을 묶어 자동 실행하는 작은 프로그램)로 짜고 계속 관리해야 했지만, 지금은 Claude Code와 Codex 두 제품 모두에 기본으로 들어가 있다.
하나씩 자세히 살펴보자.
부품 ① 오토메이션 — 알아서 '시작' 버튼을 누른다
비유: 매일 아침 7시에 알아서 켜지는 커피머신. 버튼을 누르지 않아도 정해진 시각에 돈다.
기능: 오토메이션(automation) 은 정해진 주기에 사람 개입 없이 발견과 분류를 실행한다. 여기서 '분류'는 영어로 트리아지(triage) 라고 부른다. 응급실에서 환자의 급한 순서를 가리듯, 할 일을 추리고 우선순위를 매기는 것을 뜻한다.
두 제품에서는: Claude Code는 /loop(주기 반복), /goal(조건 만족까지), 그리고 cron(시각 예약기)·hooks(특정 사건에 자동 실행되는 갈고리)·GitHub Actions로 돈다. Codex는 'Automations' 탭에서 프로젝트·프롬프트·주기·실행 환경을 지정하고, 처리 못 한 일이 모이는 'Triage inbox'와 /goal을 제공한다.
부품 ② 워크트리 — AI마다 책상을 따로 준다
비유: 개발자 둘이 상의 없이 같은 문서를 동시에 덮어쓰면 서로의 작업이 날아간다. 그래서 각자 책상에 사본을 한 부씩 깔아준다.
기능: 워크트리(worktree) 는 같은 커밋 이력(코드 변경 기록)을 공유하는 하나의 저장소 안에서, AI마다 별도 브랜치(작업 갈래)의 독립 폴더를 내어준다. 한 AI의 수정이 다른 AI의 폴더에 닿지 않게 분리해 충돌을 막는다. 다만 충돌을 막아준다고 무한정 늘릴 수는 없다 — 결과를 검토하는 사람은 결국 당신이고, 검토 여력이 동시 실행 대수를 정한다.
이름은: Claude Code 쪽이 git worktree, --worktree 플래그(실행 옵션), 그리고 서브에이전트에 isolation: worktree를 걸어 작업 후 자동 정리되는 폴더를 준다. Codex 쪽은 스레드(작업 대화 한 줄기)마다 워크트리를 내장으로 띄운다. 실제로 Codex 앱의 깃 통합 메뉴에는 '브랜치 접두사·워크트리' 설정이 그대로 들어 있다. (참고: 갓대희 Codex Mac App 가이드 실측)
부품 ③ 스킬 — 매번 처음부터 설명하지 않게 적어둔다
비유: 새 직원이 올 때마다 회사 규칙을 입으로 다시 설명하면 지친다. 대신 인수인계 노트를 한 장 써두면 그걸 읽고 시작한다.
기능: AI는 세션(작업 한 판)이 바뀌면 맥락이 백지로 돌아간다. 그러면 비어 있는 정보를 자신 있게 추측으로 메워버리는 일이 생긴다. 스킬(skill) 은 프로젝트 지식을 SKILL.md라는 파일에 적어두고, AI가 매 작업마다 다시 읽고 시작하게 한다. 처음부터 설명하는 수고를 줄여준다.
부르는 법: Claude Code와 Codex 둘 다 SKILL.md 같은 형식을 쓴다. Codex에서는 $이름으로 부르거나 문맥에 맞으면 알아서 불러온다.
부품 ④ 플러그인·커넥터 — 손발을 달아준다
비유: 아무리 똑똑해도 손발이 없으면 보고서를 직접 제출하진 못한다. 플러그인은 그 손발이다.
기능: 커넥터(connector) 는 에이전트를 외부 도구(GitHub·이슈 트래커, 데이터베이스(DB), 각종 API, 협업 메신저 Slack 등)에 연결한다. 보통 MCP(Model Context Protocol, AI와 외부 도구를 잇는 표준 연결 규격)를 통한다. 그래서 "고치세요"라고 말만 하고 끝나지 않는다 — 직접 PR(Pull Request, 코드를 이렇게 바꾸자는 변경 제안)을 열고, 이슈 티켓을 연결하고, CI(작성한 코드를 자동으로 빌드·검사하는 단계)가 통과하면 채널에 알림까지 보낸다. 플러그인(plugin) 은 이 커넥터와 스킬을 한 묶음으로 포장한 것이다. 동료가 한 번에 같은 환경을 설치할 수 있게 해준다. 스킬이 '작성하는 형식'이라면, 플러그인은 그걸 '배포하는 방식'이다.
제품 표기: Claude Code는 MCP 서버 + 플러그인, Codex도 MCP + 플러그인으로 배포한다. 다만 Codex의 플러그인은 OpenAI가 큐레이트한 GUI 확장이고, MCP는 표준 프로토콜 서버, Skills는 재사용 지침 묶음으로 셋의 역할이 갈린다 — 자주 헷갈리는 지점이라 구분해두면 좋다. (참고: 갓대희 Codex Mac App 가이드 실측)
부품 ⑤ 서브에이전트 — '짓는 AI'와 '검사하는 AI'를 나눈다
비유: 자기가 쓴 글은 자기 눈엔 다 잘 써 보인다. 그래서 교정은 다른 사람에게 맡긴다.
기능: 코드를 짠 모델은 자기 결과를 후하게 평가하는 경향이 있다. 그래서 서브에이전트(sub-agent) — 다른 지시문, 때로는 다른 모델을 쓰는 두 번째 에이전트 — 가 첫 번째가 놓친 문제를 잡아낸다. '만드는 AI'와 '검사하는 AI'를 일부러 나누는 것이다. 역할마다 모델과 추론 강도를 달리 둘 수도 있다 — 보안 검토용은 강한 모델에 깊은 추론(high effort)으로, 빠른 탐색용은 가벼운 읽기 전용 모델로 굴리는 식이다.
설정 위치: Claude Code는 .claude/agents/에 설정 파일을 두고 에이전트 팀이나 작업용 서브에이전트를 띄운다. Codex는 .codex/agents/에 같은 방식으로 두고, 요청할 때만 서브에이전트를 띄워 동시에 돌린 뒤 결과를 하나로 합친다.
+ 기억장치: 상태 파일 — 어제 멈춘 곳에서 잇는다
비유: 게임의 '세이브 파일'. 전원을 꺼도 다시 켜면 죽은 자리부터 다시 시작한다.
기능: 부품 5개가 손발이라면, 상태 파일(state file) 은 기억이다. 대화 컨텍스트(그 세션이 기억하는 범위) 바깥에 오래 남는 마크다운 파일이나 이슈 관리 보드(예: Linear)에, 뭘 시도했고·뭐가 통과했고·뭐가 남았는지를 적어둔다. 그래서 다음 날 아침 작업이 멈춘 지점부터 이어진다. Addy Osmani의 한마디가 핵심을 찌른다 — "The agent forgets, the repo doesn't(에이전트는 잊어도, 저장소는 잊지 않는다)."
저장처: Claude Code는 마크다운(AGENTS.md·진행 파일) 또는 MCP로 연결한 Linear, Codex는 마크다운 또는 커넥터로 연결한 Linear를 쓴다.
3. 실제로 돌아가는 루프 한 바퀴
부품을 다 모으면 어떤 그림이 될까.
한 바퀴, 즉 하나의 루프는 발견 → 분류 → 수정 → 검증 네 동작으로 압축할 수 있다
(원문이 공식 4단계로 못 박은 건 아니고, 흐름을 정리한 것이다). Addy Osmani가 든 예시를 따라가 보자.
그래서 루프는 실제로 뭐에 쓰나
흐름이 추상적으로 느껴진다면, 실제 사용처를 보면 된다.
OpenAI는 사내에서 루프를 지루하지만 끝없이 반복되는 일에 돌린다 — 매일 이슈 분류, CI 실패 요약, 커밋 브리핑 작성, 지난주 누군가 심어둔 버그 사냥. 사람이 매번 시키기엔 아깝지만, 안 하면 조용히 쌓이는 일들이다.
거창한 자동화부터 떠올릴 필요가 없다 — 손이 자꾸 가는 잡일 하나가 첫 루프로 가장 좋다.
오토메이션이 매일 아침 저장소에서 한 번 돈다.
깨어난 루프가 트리아지 스킬을 불러, 어제의 CI 실패·열린 이슈·최근 커밋을 읽고 그 결과를 마크다운 파일(또는 Linear 보드)에 적는다.
처리할 만한 작업마다 격리된 워크트리를 연다. 그 안에서 한 서브에이전트가 수정안을 쓰고, 두 번째 서브에이전트가 프로젝트 스킬과 기존 테스트를 기준으로 그 수정안을 검토한다.
커넥터가 PR을 열고 티켓을 갱신한다.
무언가 발견한 실행은 사람의 수신함(triage inbox)으로 올라오고, 아무것도 못 찾은 실행은 스스로 아카이브된다 — 책상에 올라오는 건 정말 봐야 할 것만 남는다.
상태 파일이 이 전체의 중심이다 — 뭘 했고 뭐가 남았는지 기억해, 다음 날 멈춘 지점부터 잇는다.
이 모든 걸 사람은 단 한 번 설계했을 뿐, 어느 단계도 직접 프롬프트하지 않았다.
Addy Osmani의 말 그대로다 — "You designed it one time. You did not prompt any of those steps." (당신은 이걸 한 번 설계했다. 그 단계들 중 어느 것도 직접 시키지 않았다.)
한 가지 실용 팁도 있다. Codex의 Fast 모드는 속도가 빠른 대신 크레딧(사용 한도)을 2~2.5배 빨리 쓴다.
보통 모드는 추론 시간을 더 둬서 멀티파일 리팩터나 복잡한 에이전트 작업에 오히려 더 안정적인 경향이 있다.
루프를 돌릴 땐 속도보다 안정성이 결국 비용을 좌우한다. 그래서 보통 모드를 권한다.
5. 나의 하네스 살펴보기
Addy의 부품
내 하네스의 실제 구현
① 오토메이션
형제 파이프라인이 Codex heartbeat(주기적으로 깨우는 자동 신호) + cron 프롬프트로 토픽을 스스로 발굴하고 예약 실행한다. 'AI 트렌드 자동 토픽' 런이 쌓여 있다.
② 워크트리
거의 쓰지 않는다(정직한 약점). 블로그는 코드가 아니라 콘텐츠라, 각 런이 runs/<run-id>/ 디렉토리로 이미 분리된다. git worktree는 과하다고 판단해 도입하지 않았다.
③ 스킬
파이프라인 지식을 여러 SKILL.md로 코드화했다(주간 블로그 파이프라인 등).
④ 플러그인·커넥터
Codex·이슈 트래커·NotebookLM 등을 MCP 커넥터로 붙였다.
⑤ 서브에이전트
가장 강한 부품. Planner→Researcher→Writer↔Evaluator↔Critic를 별도 서브에이전트로 분리한다. "만드는 AI와 평가하는 AI를 반드시 다른 에이전트로 분리"하는 것이 설계의 핵심이다.
⑥ 상태·기억
수정 금지 산출물 체인(spec.json→evidence.json→draft.md→qa_report.json→final.html). 모델은 런 사이에 잊으므로 기억을 디스크에 둔다.
⑤ 서브에이전트의 한 바퀴를 그림으로 옮기면 이렇다. 만드는 AI(Writer)와 검사하는 AI(Evaluator·Critic)가 같은 글을 두고 역할을 나눠 맡는다.
[토픽/URL]
└─ Planner → spec.json (무엇을 쓸지 정한다)
└─ Researcher → evidence.json (출처·인용을 모은다)
└─ Writer → draft.md ← 만드는 AI
└─ Evaluator → qa_report.json ← 검사하는 AI (별도 서브에이전트)
└─ Publisher → final.html (발행용 HTML로 변환)
└─ Critic → ship 판정 ← 또 다른 검사 AI
↑________________________________|
통과 못 하면 Writer로 되돌려 다시 한 바퀴
왜 만드는 AI와 검사하는 AI를 갈라놨나
같은 글을 Claude가 스스로 채점하면 9.04, Codex가 독립으로 채점하면 7.43이 나온 적이 있다 — 1.6점이 벌어졌다. 자기가 만든 글을 자기가 후하게 본다는 뜻이다. 그래서 평가자를 만드는 AI와 분리하고, 같은 계열 모델이 채점하면 'self-bias 경고' 플래그를 강제로 단다. 이 수치는 내 한 번의 하네스 런에서 관찰한 값이다 — 공개 벤치마크가 아니며, 재현을 보장하지도 않는 한 사례의 기록이다.
6. 냉정하게 — 루프는 사람을 일에서 빼주지 않는다
루프는 일의 형태를 바꿀 뿐, 사람을 일에서 빼주지 않는다.
오히려 루프가 좋아질수록 사람이 붙잡아야 할 부분이 더 선명해진다.
Addy Osmani는 세 가지를 못 박았다.
검증은 여전히 사람 몫이다. 루프는 사람이 안 볼 때 실수한다. "Your job is to ship code you confirmed works." (당신의 일은 작동을 직접 확인한 코드를 내보내는 것이다.) 검토 없이 루프에 다 맡기면 제품 품질이 무너지고 악순환에 빠진다고, 저자 본인도 인정한다.
이해도는 노력하지 않으면 떨어진다. 코드가 빨리 나올수록, 읽지 않으면 내가 어떤 코드를 들고 있는지 모르게 된다. 루프의 산출물을 읽는 일은 선택이 아니다.
가장 큰 위험은 '인지적 항복'이다. 똑같은 루프를 두 사람이 만들어도 정반대 결과가 나온다 — 한 명은 깊이 아는 일을 더 빨리 하려고 쓰고, 다른 한 명은 그 일을 이해하지 않으려고 쓴다. 여기서 '인지적 항복(cognitive surrender)'이란, 생각하기를 기계에 넘겨버리는 것을 말한다. Addy Osmani가 그 차이를 한 문장으로 못 박는다. "The loop doesn't know the difference. You do." (루프는 그 차이를 모른다. 당신은 안다.)
가장 위험한 신호 — 인지적 항복
루프가 매끄러울수록 '생각하기'를 기계에 넘기고 싶어진다. 그 순간 루프는 숙련을 빠르게 만드는 도구가 아니라 이해를 피하는 핑계가 된다. 똑같은 루프인데 결과가 갈리는 건, 도구가 아니라 쓰는 사람 때문이다.
앞 장에서 본 자기 채점과 독립 채점의 괴리가 바로 이 경고의 증거다. 검사하는 AI를 따로 두지 않았다면, 후한 자기 점수만 믿고 부족한 글을 내보냈을 것이다. 검증을 빼면 품질이 조용히 무너진다는 말은 추상이 아니라 한 번 측정된 사실이다.
그러면서 저자는 균형추를 단다. 코드를 직접 검토하지 않거나 수정을 전적으로 루프에 맡겼다면 제 제품의 품질은 나빠졌을 것이라고 솔직히 인정한다. 그리고 덧붙인다 — 루프는 짜되, 에이전트에게 직접 프롬프트를 던지는 방식도 여전히 효과적이라고. 루프냐 직접이냐의 양자택일이 아니라 "결국 올바른 균형을 찾는 일(It's all about finding the right balance)" 이라는 것이다.
"Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go."
(루프를 만들어라. 단, '시작' 버튼만 누르는 사람이 아니라 끝까지 엔지니어로 남을 작정인 사람처럼 만들어라.) — Addy Osmani
이게 루프 설계가 프롬프트 작성보다 더 어려운 이유다. 일이 쉬워진 게 아니라, 지렛대의 받침점이 옮겨갔을 뿐이다. 글 처음에 말한 '실행자에서 감독관으로'의 자리바꿈은 일을 덜어준다는 약속이 아니다. 더 무거운 자리로 옮겨 앉으라는 요구에 가깝다. 감독관은 버튼만 누르는 사람이 아니라, 무엇이 통과했고 무엇이 틀렸는지 끝까지 책임지는 사람이다.
7. 자주 묻는 질문
Q. 루프 엔지니어링은 결국 cron 자동화 아닌가?
자동화는 루프의 부품 하나(오토메이션)일 뿐이다. 루프는 발견→분류→수정→검증을 여러 부품으로 엮은 작업 묶음이고, 자동화는 그중 '시작 버튼'에 해당한다. 나머지 다섯(워크트리·스킬·커넥터·서브에이전트·상태)이 빠지면 그냥 예약 실행이지 루프가 아니다.
Q. 초보도 오늘 시작할 수 있나?
부품 전부를 한 번에 깔 필요는 없다. 스킬(SKILL.md) 한 장과 진행 파일(progress.md) 하나부터 시작한다. 이 둘만 있어도 다음 세션에서 다시 설명할 일이 줄고, 작업이 멈춘 지점부터 이어진다.
Q. Claude Code와 Codex 중 뭘 골라야 하나?
부품은 둘 다 갖췄다. 갈리는 건 이름과 설정 위치뿐이다. 이미 쓰는 환경을 그대로 쓰되, '루프를 짠다'는 사고방식만 옮기면 된다. 두 제품을 굳이 갈아탈 이유는 부품이 아니라 팀의 기존 워크플로우에서 찾는 편이 낫다.
Q. 루프를 돌리면 코드 리뷰를 안 해도 되나?
반대다. 산출물이 빨리·많이 나올수록 검토는 더 중요해진다. 앞에서 봤듯 자기 채점과 독립 채점은 크게 벌어질 수 있다. 검증을 빼면 그 괴리가 그대로 발행물에 실린다.
마무리 — 오늘 당장 할 수 있는 것
루프 엔지니어링은 거창한 인프라에서 시작하지 않는다. 부품 6개를 내 작업에 하나씩 끼워보는 일에서 시작한다. 부품 전부를 갖추지 않아도 된다 — 내 하네스도 워크트리는 안 쓰고, 무인 발행은 일부러 닫지 않았다.
단계별 도입 플레이북
오늘 — 부품 ③ 스킬부터: 자주 하는 작업 하나를 골라 SKILL.md(인수인계 노트)로 적는다. 다음 세션부터 설명이 줄어든다.
이번 주 — 부품 ⑤ 서브에이전트: 코드를 짠 AI에게 검토까지 맡기지 말고, 별도 검사 AI를 한 번 띄운다. 자기 글에 후한 편향이 바로 보인다.
꾸준히 — 기억장치 상태 파일: 진행 파일 하나(progress.md)에 '한 일/남은 일'을 적게 하면, 내일 아침 작업이 훨씬 매끄럽다.
잊지 말아야 할 한 가지 — 검토하는 사람은 여전히 당신이다. 루프는 '시작' 버튼을 대신 눌러줄 뿐, 책임까지 가져가진 않는다. 이 글을 출발점 삼아, 가장 작은 부품 하나부터 내 작업에 끼워보길 권한다.
