2026년 6월부터 루프 엔지니어링(Loop Engineering)이라는 용어를 부쩍 자주 보게 되었습니다. 발단은 OpenClaw의 제작자 Peter Steinberger의 게시물로, "이제 코딩 에이전트에게 프롬프트를 작성하지 마라. 에이전트가 프롬프트를 작성하는 루프(Loop)를 설계하라"라는 취지의 내용이었습니다. Claude Code를 이끄는 Boris Cherny도 "이제 Claude에게 직접 지시를 내리지 않는다. 루프가 Claude에게 프롬프트를 하고 있다"라고 말했으며, 바로 다음 날 Google의 Addy Osmani가 개념을 정리하여 Loop Engineering이라고 명명했다고 합니다.

개념을 설명하는 기사는 이미 많이 나와 있습니다. 하지만 읽기만 해서는 솔직히 감이 오지 않았습니다. "그게 cron으로 정기 실행하는 것과 무엇이 다른가?"라는 의문이 끝까지 사라지지 않았기 때문입니다.

그래서 제 업무 태스크로 직접 하나 구축해 보았습니다. 이 기사는 그 과정에서 '단순한 정기 실행'과 '루프'의 차이가 어디에 있는지 알게 되기까지의 기록입니다. 실제로 만든 파일 일체(샘플)도 함께 올립니다.

본문에서 사용할 용어를 먼저 정리해 두겠습니다. 알고 계신 분은 건너뛰셔도 됩니다.

용어	의미
cron (크론)	Linux나 Mac에 예전부터 있는 정시 실행 메커니즘. "매일 아침 9시에 이 명령어를 실행하라"와 같은 예약이 가능하다. crontab이라는 설정 파일에 작성한다
...

저는 직업훈련학교에서 신입 사원 연수를 지켜보고 있습니다. 신입 멤버들에게는 매일 Slack 전용 채널에 진척 상황을 게시하도록 하고 있는데, 전원을 매일 아침 육안으로 확인하는 것이 은근히 번거로웠습니다. 누가 언제 게시했는지, 멈춰 있는 사람은 없는지. 확인 자체는 5분이면 끝나지만, 잊어버리는 날도 있고 확인하는 사람의 기분에 따라 기준이 흔들리기도 합니다.

루프 엔지니어링의 해설 기사에서도 로그 순회 점검은 루프에 적합한 태스크의 첫 번째 사례로 꼽혔습니다. 판정 기준을 수치화할 수 있고(48시간 동안 게시가 없으면 확인 필요), 증거도 남길 수 있으며(Slack의 permalink), 실수해도 아무것도 망가뜨리지 않습니다. 연습용으로는 딱 좋습니다.

참고로, 이후 샘플에 등장하는 성명은 모두 가명(다나카 타로 등)으로 대체했습니다.

첫 번째 버전은 다음과 같았습니다.

• SKILL.md에 절차를 작성한다 (채널을 찾는다, 24시간 분량을 읽는다, 사람별로 최종 게시물을 추출한다, 48시간이 넘으면 확인 필요)
• claude -p로 해당 스킬을 비대화형(non-interactive)으로 실행하는 셸 스크립트를 작성한다
• crontab에 등록하여 매일 아침 9시 30분에 돌린다

crontab의 내용은 한 줄입니다.

30 9 * * 1-5 /home/kazu/shinsotsu-tracker/scripts/run_daily.sh

의미는 "평일(1-5=월~금) 9시 30분에 이 스크립트를 실행하라"입니다. 이로써 매일 아침 진척 상황 목록이 자동으로 로그에 쌓이게 되었습니다.

작동은 합니다. 하지만 만든 본인이 가장 위화감을 느꼈습니다. 이거, AI를 호출하고 있을 뿐인 정기 배치(Batch) 아닌가?

이 의문은 사실 핵심을 찌르고 있었던 것 같습니다. X(구 Twitter)에서도 "그냥 모자를 쓴 cron job일 뿐이잖아"라는 냉소적인 목소리가 있었다고 합니다. 그래서 해설 기사를 다시 읽고 깨달은 것은, cron과 루프를 나누는 것은 기동 방법이 아니라는 점이었습니다.

첫 번째 버전의 무엇이 문제였을까요. 매일 아침의 실행이 전날의 결과를 전혀 참조하지 않았다는 점입니다.

매일 제로 베이스에서 전원을 다시 조사합니다. 어제 "이 사람은 게시물을 찾을 수 없음"이라고 판정한 사람을 오늘도 다시 7일 전까지 거슬러 올라가 찾습니다. 어제 통지했던 확인 필요 대상자에게 오늘도 똑같은 통지를 보냅니다. 실행할 때마다 결과를 버리고 있기 때문에 원(Circle)이 연결되지 않았습니다. 정기 실행이라는 직선을 매일 나열하고 있을 뿐이었습니다.

해결 방법은 간단합니다. state.json이라는 상태 파일을 하나 만들었습니다. 실물(가명 버전)은 다음과 같습니다.

{
"last_run": "2026-07-04",
"members": {
...

status는 3가지입니다. ok(최근 게시물 있음), escalated(확인 필요로 통지 완료), unresolved(게시물 자체를 찾지 못해 원인 미정). lessons에는 실행하며 배운 주의 사항이 쌓여갑니다.

이 파일을 실행 전에 읽습니다. 상태에 따라 동작을 바꿉니다. 실행 후에 다시 씁니다.

• unresolved인 사람은 매번 7일 전까지 거슬러 올라가는 낭비를 없애고 그대로 유지
• escalated된 사람에게는 재통지하지 않음 (매일 똑같은 알람이 오면 인간은 무시하게 됨)
• ok인 사람은 최근 24시간만 확인

이것을 도입한 순간, 동작이 바뀌었습니다. 불필요한 탐색이 사라지고, 알림의 노이즈도 사라졌습니다. 어제의 결과가 오늘의 움직임을 바꿉니다. 이 순환이 이루어져야 비로소 루프(Loop)라고 부를 수 있다는 것을 체감으로 이해할 수 있었던 순간입니다. 모델은 매번 잊어버리지만, 파일은 잊지 않더군요.

참고로 cron 자체가 악당은 아닙니다. 해설 기사에서도 Automations(자동 실행)는 정당한 부품으로 위치 지어지고 있습니다. 심장 박동은 매일 아침 cron이 칩니다. 하지만 기억과 판단은 루프 측이 가집니다. 이 역할 분담이 정답이었습니다.

기억을 순환시켜 만족할 뻔했습니다만, 해설 기사 3편(Zenn, Qiita, DevelopersIO)과 자신의 구현을 대조해 보니 공통적으로 결여된 것이 2가지 발견되었습니다.

작업한 에이전트가 "전부 확인했습니다"라고 말한다. 그것을 믿어도 되는가. 안 되는 모양입니다. 어느 기사에서든 작업자의 완료 보고는 자기 신고(Self-report)일 뿐 증명이 아니라고 주의를 주고 있었습니다. 실제로 DevelopersIO의 기사에서는, 리뷰 역할을 하는 에이전트가 "테스트의 기대값을 조작하여 통과한 것처럼 만들었다"는 부정행위를 검출한 사례가 소개되어 있었는데, 이는 조금 무서웠습니다.

그래서 2단 구성으로 만들었습니다. Slack을 읽고 요약하는 Maker(작업자)와는 별개로, 검증 전용인 Checker(검증자)를 별도의 모델(Haiku. 빠르고 저렴한 모델)로 실행합니다. 스크립트의 해당 부분 발췌본은 다음과 같습니다.

# ── Checker (검증자 · 별도 모델 · 읽기 전용) ──
checker_out=$(claude -p "당신은 이 성과물을 작성하지 않은 독립적인 검증자입니다.
의심을 품고 접근하십시오. 다음 관점으로만 검증하고, 첫 줄에 PASS 또는
...

서두의 "당신은 이 성과물을 작성하지 않은"이라는 문장은, 자신의 작업에 관대해지는 확증 편향(Confirmation Bias)을 언어로 상쇄하기 위한 정석이라고 합니다. 관점 4가 저희 태스크에서의 채점표 조작 검출에 해당합니다. 확인이 필요했던 사람을 증거 없이 마음대로 ok로 되돌리지 않았는지 확인하는 것입니다.

Checker가 FAIL을 내보내면 지적 사항을 Maker에게 돌려주어 재실행합니다. 2번 실패하면 state.json을 업데이트하지 않고 인간에게 넘깁니다. 망가진 상태를 기억에 남기지 않기 위해서입니다.

또 하나는 비용과 횟수의 천장입니다. Uber가 직원의 AI 도구 이용에 월 1500달러 상한을 두었는데, 연간 예산을 4개월 만에 다 써버렸다는 보도가 있었다고 하니 웃어넘길 일이 아닙니다. 스크립트 서두에 루프를 작성하기보다 먼저 정지 조건(Stop Condition)을 작성했습니다.

# ── 정지 조건 (먼저 작성) ─────────────────
MAX_ATTEMPTS=2 # Checker FAIL 시 재시도 상한
MAX_TURNS=15 # 1회의 claude -p 턴 상한
...

그리고 사소한 이야기입니다만, claude -p (헤드리스 실행)는 2026년 6월부터 구독과는 별도의 종량제(Metered billing)로 전환됩니다. 정기 실행에 올릴 계획이라면 이 과금 체계를 미리 확인해 두는 것이 좋습니다.

지금까지의 구성물을 Addy Osmani 스타일의 6개 모듈과 설계 단계 5단계에 대응시키면 다음과 같습니다. 직접 만든 것이 어떤 부품에 해당하는지는 이 표를 만들고 나서야 정리할 수 있었습니다.

모듈	역할	이번 구현
Automations (자동 실행)	정해진 시각이나 이벤트로 자동 실행됨	crontab (평일 9:30)
...
단계	내용	이번 구현
---	---	---
1. 목표 계약	목표와 수락 기준, 금지 사항을 먼저 결정	48시간 규칙, permalink 필수, 본인 연락 금지
...

만드는 순서도 이 표와 같았습니다. 갑자기 자동 실행부터 만들면 불안정한 것을 매일 돌리는 것에 불과하게 됩니다. 수동으로 한 번 돌아가는 것(단계 2)을 만들고, 지식을 고정하고(Skills), 증거와 정지 조건을 갖춘 뒤, 마지막에 cron을 연결합니다. 이 순서가 재작업이 가장 적었습니다.

지금 제가 이 루프에 대해 할 일은 세 가지뿐입니다. 확인 필요 기준을 결정하는 것(48시간). 알림이 왔을 때 본인에게 말을 걸지 말지 판단하는 것. 미결 상태가 2주간 지속되면 시스템 자체를 재검토하는 것.

매일 아침 Slack을 열어 육안으로 확인하는 업무는 사라졌습니다. 대신 판정 기준과 예외 처리를 설계하는 업무가 남았습니다. Osmani의 마지막 문장에, 실행 버튼만 누르는 사람이 아니라 엔지니어로 남고자 하는 사람으로서 루프를 만들라는 취지의 내용이 있는데, 이는 정말 맞는 말이라고 생각합니다. 루프에 맡기는 순간 내용물을 이해하려는 노력을 그만둔다면, 오류 또한 고속으로 양산될 뿐이기 때문입니다.

또한, 이 루프는 보고만 수행합니다. 본인에게 재촉하는 것을 자동화하는 것도 기술적으로는 가능하지만, 그렇게 하지 않았습니다. 해설 기사의 용어로 말하자면 L1(보고만 수행) 단계입니다. 감시받고 있다는 느낌을 신입 사원에게 줄 것인가는 기술의 문제가 아니라 운영의 문제이며, 그 부분은 아직 제 안에서 결론이 나지 않았습니다. 자율도를 높이는 것은 L1의 보고를 신뢰할 수 있다고 확인한 이후에 해도 충분하다고 생각합니다.

• cron으로 매일 아침 AI를 실행하는 것만으로는 정기 실행(Scheduled execution)일 뿐 루프가 아니다. 이전의 결과가 이번의 움직임을 변화시키는 기억의 순환(state.json)이 포함되어야 비로소 루프가 된다.
• 작업 역할의 완료 보고는 자기 신고 방식이다. 별도 모델의 검증 역할(Maker-Checker)과 변조 탐지 관점을 도입한다.
• 정지 조건과 예산은 루프를 작성하기 전에 결정한다. 재시도 상한, 턴(Turn) 상한, 일일 예산.
• 첫 번째 태스크는 판정을 수치화할 수 있고, 실수하더라도 망가지지 않는 읽기 전용(Read-only)인 것을 선택한다.

구성 요소는 SKILL.md(절차 및 금지 사항), state.json(기억), 셸 스크립트(Maker → Checker → 상태 업데이트 제어)의 단 3개 파일뿐입니다. 화려함은 없지만, 이 작은 규모로도 루프의 형태는 한 차례 모두 배울 수 있었습니다. 다음에는 사내 주간 보고 시스템의 미제출 체크에 동일한 형태를 이식할 예정입니다.

• 이제 프롬프트를 작성하지 마라. 「Loop Engineering」이라는 새로운 패러다임의 정체 (Zenn / acrosstudioblog)

• 입문부터 실전 「루프 엔지니어링」 (Qiita / Syoitu)

• Loop Engineering을 Claude를 사용하여 실천해 보았다. (DevelopersIO / Classmethod)