루프 엔지니어링(Loop Engineering)이란? 이제 AI에게 프롬프트하지 않습니다
프롬프트→컨텍스트→하네스에 이어 등장한 '루프 엔지니어링'. AI에게 매번 지시하는 대신, AI를 지시하는 시스템을 설계하는 새 작업 방식의 5가지 구성 요소와 주의점을 정리했습니다.
안녕하세요. Jay입니다!
AI 코딩 도구를 쓰다 보면 하루 종일 "이거 해줘", "다음은 저거" 하며 지시를 반복하게 되죠. 그런데 요즘 업계에서 이 방식 자체를 끝내자는 개념이 화제입니다. 바로 루프 엔지니어링(Loop Engineering) — 구글의 Addy Osmani가 정리한 글이 큰 반향을 얻었는데요, 오늘은 이 개념을 쉽게 풀어보겠습니다.
🔁 루프 엔지니어링이 뭔가요?
한 문장으로 하면 "에이전트에게 프롬프트하지 말고, 에이전트를 프롬프트하는 루프(시스템)를 설계하라"입니다. 앤트로픽에서 Claude Code를 이끄는 Boris Cherny는 이렇게 말합니다.
"이제 Claude에 프롬프트하지 않는다. Claude에 프롬프트하고 무엇을 할지 정하는 루프를 돌린다 — 내 일은 루프를 작성하는 것이다."
루프란 목적을 정의하면 AI가 완료될 때까지 반복하는 재귀적 목표예요. 지난 2년간 우리는 좋은 프롬프트(프롬프트 엔지니어링) → 충분한 맥락(컨텍스트 엔지니어링) → 좋은 실행 환경(하네스)으로 발전해 왔는데, 루프는 그 다음 단계입니다. 사람이 매 턴 개입하는 대신, 작업을 찾고 → 분배하고 → 검증하고 → 기록하고 → 다음을 결정하는 작은 시스템을 만들어 두는 거죠.
🧩 루프의 5가지 구성 요소 (+ 메모리)
Claude Code와 OpenAI Codex 모두 이미 다섯 가지를 제품 안에 갖추고 있습니다. 1년 전엔 직접 스크립트를 짜야 했던 것들이에요.
| 요소 | 역할 |
|---|---|
| ① Automations | 스케줄에 따라 스스로 실행·분류 (루프의 심장박동) — Claude Code는 /loop·훅·cron |
| ② Worktrees | 여러 에이전트가 병렬 작업해도 파일 충돌 방지 (git worktree 격리) |
| ③ Skills | 프로젝트 지식을 파일로 외부화 — 매 세션 처음부터 설명하는 비용 제거, 쓸수록 복리로 누적 |
| ④ Plugins·Connectors | MCP로 이슈 트래커·DB·Slack 등 실제 도구에 연결 — "PR 열고 CI 통과하면 채널에 알림"이 가능해짐 |
| ⑤ Sub-agents | 만드는 쪽과 검사하는 쪽 분리 — 코드를 쓴 모델은 자기 채점에 관대하므로 별도 검증자를 둠 |
여기에 여섯 번째로 메모리가 필요합니다. 모델은 실행 사이에 모든 걸 잊으니, 완료한 것과 다음 할 일을 대화가 아니라 디스크(마크다운 파일·보드)에 남겨야 해요. "에이전트는 잊어도 repo는 잊지 않는다"는 거죠.
이걸 합치면 이런 하루가 됩니다: 매일 아침 자동화가 어제의 CI 실패·이슈를 읽어 목록을 만들고 → 항목마다 격리된 작업 공간에서 서브에이전트가 수정 초안을 쓰고 → 두 번째 에이전트가 리뷰하고 → 커넥터가 PR을 열고 → 상태 파일이 진행 상황을 기록해 다음 날 이어갑니다. 이 단계들 중 어느 것도 사람이 프롬프트하지 않습니다. 한 번 설계했을 뿐이죠.
⚠️ 루프가 대신해 주지 않는 3가지
원문이 강조하는 경고가 오히려 백미입니다.
- 검증은 여전히 사람 몫 — 무인으로 도는 루프는 무인으로 실수하는 루프이기도 합니다. AI의 "끝났다"는 증명이 아니라 주장이에요.
- 이해는 방치하면 썩는다 — 직접 쓰지 않은 코드가 빨리 쌓일수록 "존재하는 것"과 "이해하는 것"의 간극이 커집니다 (comprehension debt).
- 편안한 자세가 위험한 자세 — 루프가 잘 돌수록 의견 갖기를 멈추고 결과를 그대로 받기 쉽습니다. 같은 루프도 판단을 갖고 쓰면 도구, 사고를 피하려 쓰면 독이에요.
그래서 결론은 "Build the loop, stay the engineer" — 루프를 만들되, 시작 버튼만 누르는 사람이 아니라 엔지니어로 남으라는 것.
💡 Jay의 경험
저도 비슷한 구조를 운영 중입니다. 개인 위키의 운영 규칙 문서가 Skills, 위키의 로그 파일이 상태 파일(메모리), 글 발행 후 검증 절차가 maker·checker 분리에 해당하더라고요. 실제로 해보니 루프의 품질은 모델이 아니라 규칙과 검증 장치를 얼마나 잘 적어뒀느냐가 결정합니다. 그리고 경고 그대로, 결과물을 안 읽고 넘긴 날엔 꼭 탈이 났습니다. 토큰 비용도 실감하는 부분이니 서브에이전트 검증은 "두 번째 의견이 값어치 있는 곳"에만 쓰는 걸 추천해요.
결론
AI 활용의 레버리지가 '좋은 지시'에서 '좋은 루프 설계'로 옮겨가고 있습니다. 단, 검증하고 이해하는 엔지니어의 자리는 루프가 대체하지 못합니다.
프롬프트 엔지니어링을 익히셨다면, 다음은 반복 작업 하나를 골라 작은 루프로 만들어 보세요. 다음에도 유익한 포스팅으로 찾아오겠습니다. 감사합니다!