Loop Spec 템플릿 2026 – AI 에이전트 루프 시작 전 채울 10칸

Posted on by

Loop Spec은 AI 에이전트 루프를 시작하기 전에 목적, 트리거, 상태 파일, 검증, 중단 조건을 한 장에 적는 작업 명세다. 2026년 6월 기준으로 Codex, Claude Code 같은 코딩 에이전트가 자동화·워크트리·스킬·서브에이전트까지 품기 시작하면서, 이제 필요한 것은 멋진 한 줄 지시문보다 반복 작업이 사고 없이 굴러가게 만드는 작은 명세서다.

AI 자동화 얘기 들으면 다들 한 번쯤 이런 상상을 한다. “이제 에이전트한테 맡기고 나는 커피 마시면 되나?” 좋다. 꿈은 크게 가져야 한다. 그런데 자동화에 종료 조건이 없으면 커피 마시는 동안 에이전트가 회사 프린터처럼 계속 무언가를 뽑아낸다. 문제는 종이가 아니라 토큰이 나간다는 점이다.

오늘 정리한 루프 엔지니어링 노트에서 내가 제일 크게 본 포인트도 그거였다. 루프는 “AI가 알아서 하게 만들기”가 아니라 “AI가 어디까지 알아서 하고, 무엇을 증거로 남기고, 어디서 사람에게 넘길지 정하기”에 가깝다. 2026년 6월 10일에 쓴 선행 글이 루프 엔지니어링의 개념편이라면, 이 글은 자동화 전에 실제로 채우는 Loop Spec 작성편이다.

먼저 답하면

루프 엔지니어링을 시작할 때는 프롬프트부터 쓰지 말고, 아래 10칸짜리 스펙부터 채우는 게 안전하다.

항목 적어야 할 질문
목적 이 루프가 끝나면 무엇이 달라져야 하나
트리거 언제, 어떤 조건에서 시작하나
입력 어떤 파일, 이슈, URL, 로그를 읽나
도구 어떤 명령, 앱, 커넥터, 스킬을 쓸 수 있나
상태 파일 결과와 실패를 어디에 남기나
성공 조건 무엇이 참이면 완료인가
실패 조건 무엇이 반복되면 멈추나
검증 방법 누가, 무엇으로 결과를 확인하나
승인 지점 어떤 행동은 사람 허락이 필요한가
비용 한도 몇 번, 얼마나 자주, 어떤 모델로 돌리나

이 표를 못 채우면 아직 루프를 만들 때가 아니다. 그 상태에서 자동화부터 걸면, 에이전트가 일을 하는 게 아니라 안개 속에서 러닝머신을 타는 꼴이 된다. 열심히는 움직이는데 어디 갔는지는 모른다.

루프 스펙은 왜 프롬프트보다 먼저인가

프롬프트는 “이번 한 번”의 지시문이다. 물론 중요하다. 프롬프트가 흐리면 결과도 흐려지고, 결과가 흐린데 반복까지 붙이면 흐린 결과가 대량생산된다. 여기서부터 살짝 공장 냄새가 난다.

루프 스펙은 “다음에도 같은 방식으로 굴러갈 작업 계약서”다. 작업자가 AI든 사람이든, 반복 업무에는 계약서가 필요하다. 언제 시작하는지, 어디까지 해도 되는지, 실패하면 누구를 부르는지, 결과는 어디에 남기는지가 없으면 운영이 아니라 분위기다.

Addy Osmani는 루프 엔지니어링을 사람이 직접 에이전트에게 프롬프트하는 역할을 시스템으로 대체하는 흐름으로 설명한다. LangChain은 이를 더 구조적으로 나눠 agent loop, verification loop, event-driven loop, hill-climbing loop처럼 여러 겹의 반복 구조로 본다. MindStudio도 좋은 루프에는 명확한 목표, 종료 조건, 도구 접근, 컨텍스트 관리, 실패 탈출구가 필요하다고 본다. 표현은 조금씩 다르지만 공통점은 같다. 좋은 AI 작업은 한 번 답하고 끝나는 게 아니라, 실행과 검증이 묶인 반복 시스템이 된다는 것이다.

예시로 보면 더 쉽다

내 Obsidian 볼트에 붙일 수 있는 작은 루프를 하나 잡아보자. “새로 들어온 YouTube 요약 노트가 기존 루프 엔지니어링 클러스터와 중복인지 판단한다”는 작업이다. 이건 사람이 매번 하기도 귀찮고, 기준만 있으면 AI가 꽤 잘 도와줄 수 있다.

스펙으로 쓰면 이렇게 된다.

## Loop Spec

- 목적: 새 Inbox 노트를 기존 루프 엔지니어링 클러스터와 연결할지 판단한다.
- 트리거: `00.Inbox`에 YouTube 또는 Threads 요약 노트가 생겼을 때.
- 입력: 새 노트 1개, 기존 AI Agent 리소스 노트, `03.Resources/wiki/ai-tools.md`.
- 사용할 도구: rg 검색, semantic query, frontmatter read.
- 상태 파일: `00.Inbox/⚡ TRIAGE_QUEUE.md` 또는 원본 노트의 병합 상태 섹션.
- 성공 조건: `신규 / 보강 / 중복 / 보류` 중 하나로 분류하고 근거 링크를 남긴다.
- 실패 조건: 관련 노트가 2개 미만이거나 출처가 자막 발췌뿐이면 review 상태를 유지한다.
- 검증 방법: 기존 발행 글과 resource note 중복 여부를 확인한다.
- 사람 승인 필요 지점: 위키 반영, 블로그 handoff 생성, 공개 발행.
- 비용/반복 한도: 관련 노트 5개 이하 읽기, 검색 1회, 판단 불가면 중단.

이 정도만 써도 루프가 훨씬 덜 위험해진다. AI에게 “정리해줘”라고만 말하면 새 글감이 계속 생길 수 있다. 반대로 위 스펙은 중복이면 중복이라고 멈추게 한다. 자동화에서 이 차이가 꽤 크다. 특히 블로그 운영에서는 중복 글감이 쌓이면 나중에 내가 내 글끼리 검색 결과에서 싸움을 붙이는 이상한 경기장이 열린다.

Loop Spec 항목을 Codex 부품에 대응해보면

OpenAI Codex 문서 기준으로 보면, Loop Spec의 각 칸은 Codex 부품과 꽤 자연스럽게 맞물린다. 중요한 건 기능 이름을 외우는 게 아니라, 스펙의 빈칸을 어떤 부품으로 채울지 정하는 것이다.

Loop Spec 항목 Codex 쪽 대응 부품 실무 의미
트리거 Automations / Thread automations 언제 다시 실행할지 정한다
격리 Worktrees 내 로컬 작업과 백그라운드 작업을 분리한다
재사용 규칙 Agent Skills 반복 지시와 프로젝트 지식을 SKILL.md로 묶는다
도구 연결 MCP / connectors GitHub, Slack, 문서, 브라우저 같은 외부 도구에 닿게 한다
검증 Subagents / reviewer thread 만드는 역할과 확인하는 역할을 분리한다
중단 조건 Automation prompt / rules / 사람 승인 무인 반복이 계속 달리지 않게 멈춤 기준을 둔다

예를 들어 Automations는 반복 작업을 백그라운드에서 실행하고, 발견한 결과를 Triage에 남기거나 보고할 게 없으면 아카이브하는 역할을 한다. 문서에서도 예약 전에는 일반 thread에서 먼저 프롬프트를 테스트해 결과 diff가 검토 가능한지 확인하라고 안내한다. 그러니까 Automations는 루프의 엔진이지, 스펙 검토를 대신해주는 보험은 아니다.

Worktrees는 격리 칸에 들어간다. 여러 에이전트가 같은 저장소를 만질 때 로컬 작업과 자동화 작업이 섞이면 바로 피곤해진다. Skills는 반복 지식을 포장하고, Subagents는 maker와 checker를 나눌 때 쓴다. MCP와 커넥터는 루프가 외부 세상에 손을 뻗게 하지만, 그 순간 권한과 승인 지점도 같이 적어야 한다.

좋은 루프는 만드는 쪽과 확인하는 쪽이 다르다

루프 엔지니어링에서 제일 위험한 착각은 “AI가 다시 확인했으니 괜찮겠지”다. 같은 역할, 같은 문맥, 같은 목표로 만든 결과를 다시 보면 관대해지기 쉽다. 사람도 자기가 쓴 글 오탈자 못 보고 지나간다. AI라고 갑자기 무한한 편집장 모드가 되는 건 아니다.

그래서 루프 스펙에는 검증 방법을 따로 적어야 한다. 코드라면 테스트와 린트가 있어야 하고, 문서라면 출처 대조와 링크 검사가 있어야 하고, 블로그라면 채널 적합도와 중복 여부를 봐야 한다. 중요한 작업일수록 maker와 checker를 분리하는 게 좋다.

예를 들어 글쓰기 루프라면 writer가 초안을 쓰고 reviewer가 AI 냄새, 출처, 분량, 채널 적합도를 본다. 개발 루프라면 worker가 수정하고 reviewer가 diff, 테스트, 보안 위험을 본다. 돈, 고객 데이터, 외부 메시지가 걸리면 마지막 승인자는 사람이어야 한다.

실수 TOP 5

첫 번째 실수는 목표를 너무 크게 쓰는 것이다. “프로젝트를 개선해줘”는 루프 목표가 아니다. “깨진 링크를 찾아 reports/broken-links.md에 남기고, 수정 가능한 내부 링크만 패치한다” 정도는 되어야 한다. 루프는 시를 쓰는 자리가 아니라 작업지시서를 쓰는 자리다.

두 번째 실수는 종료 조건을 안 쓰는 것이다. “될 때까지 반복”은 듣기엔 시원하지만 운영에서는 위험하다. 최대 반복 횟수, 같은 오류 반복 시 중단, 검증 실패 시 보류 같은 문장을 넣어야 한다. 루프는 근성이 아니라 브레이크가 실력이다.

세 번째 실수는 상태 파일을 안 남기는 것이다. AI는 다음 실행에서 이전 대화를 완벽히 기억하지 못할 수 있다. 그래서 결과, 실패 원인, 다음 행동은 외부 파일이나 이슈에 남겨야 한다. 상태 파일이 없으면 루프가 아니라 매번 새로 온 인턴에게 처음부터 설명하는 아침 조회가 된다.

네 번째 실수는 권한을 넓게 주는 것이다. 읽기, 초안 작성, 테스트 실행까지는 괜찮은 루프가 많다. 하지만 삭제, 배포, 결제, 외부 발송은 별도 승인 게이트를 둬야 한다. 자동화는 편하려고 만드는 건데, 새벽에 사고 치면 편함이 순식간에 기상 알람으로 변한다.

다섯 번째 실수는 비용을 나중에 보는 것이다. 서브에이전트, 긴 컨텍스트, 잦은 스케줄을 같이 붙이면 비용이 빠르게 커진다. Business Insider도 최근 루프 논의에서 비용과 토큰 사용을 주요 우려로 다뤘다. 루프 스펙에 모델 등급, 실행 주기, 최대 반복 횟수를 같이 적어야 하는 이유다.

언제 루프로 만들면 좋나

루프가 잘 맞는 작업은 반복되고, 입력 형식이 비슷하고, 검증 기준이 있는 일이다. CI 실패 요약, PR 리뷰 초안, 문서 링크 점검, 인박스 분류, 블로그 글감 중복 확인, LLM Wiki lint 같은 작업이 여기에 들어간다.

반대로 질문 자체가 흐릿하거나 실패 비용이 큰 작업은 루프보다 체크리스트부터 만드는 편이 낫다. “우리 회사 AI 전략을 알아서 세워줘”는 아직 루프 목표로 너무 크다. 먼저 “최근 30일 AI 도입 후보 10개를 표로 정리하고, 권한·비용·검증 기준이 없는 후보를 보류로 표시한다”처럼 줄여야 한다.

초보자에게 추천하는 첫 루프는 읽기 중심이다. 파일을 읽고, 요약하고, 분류하고, 사람이 볼 수 있는 표를 남기는 작업부터 시작한다. 파일을 쓰거나 외부 서비스를 조작하는 루프는 그다음이다. 처음부터 배포 자동화로 가면 배움보다 혈압이 먼저 오른다.

루프 스펙 템플릿

복사해서 쓰기 좋게 다시 적어두면 이렇다.

## Loop Spec

- 목적:
- 트리거:
- 입력:
- 사용할 도구:
- 상태 파일:
- 성공 조건:
- 실패/중단 조건:
- 검증 방법:
- 사람 승인 필요 지점:
- 비용/반복 한도:
- 결과 보고 형식:

여기서 가장 중요한 칸은 성공 조건, 실패/중단 조건, 상태 파일이다. 이 세 칸이 비어 있으면 아직 자동화하지 말자. 프롬프트를 더 잘 쓰는 문제가 아니라 운영 설계가 덜 된 상태다.

누가 지금 써야 하나

AI 코딩 에이전트를 매일 쓰고, 비슷한 지시를 계속 반복하고, 결과 검토에 시간이 많이 드는 사람이라면 루프 스펙을 써볼 만하다. 특히 개인 개발자, 블로그 운영자, 사내 자동화 담당자, 문서와 코드가 섞인 프로젝트를 굴리는 사람에게 잘 맞는다.

반대로 아직 한두 번 테스트해본 도구를 바로 루프로 만들 필요는 없다. 먼저 수동으로 3번 해보고, 입력과 출력이 반복되는지 확인하는 게 좋다. 세 번 해도 매번 기준이 바뀌면 아직 루프가 아니라 탐색 단계다.

내 기준에서 루프 엔지니어링의 핵심은 “AI를 더 믿자”가 아니다. “AI가 한 일을 내가 더 빨리 확인할 수 있게 만들자”에 가깝다. 자동화의 목적은 사람을 없애는 게 아니라, 사람이 봐야 할 지점을 더 선명하게 만드는 쪽이어야 한다.

FAQ

루프 엔지니어링은 프롬프트 엔지니어링을 대체하나?

완전히 대체하지 않는다. 프롬프트는 여전히 루프 안에서 한 번의 실행 품질을 결정한다. 다만 반복 업무에서는 프롬프트만 잘 쓰는 것보다 트리거, 상태 저장, 검증, 중단 조건을 함께 설계하는 쪽이 더 중요해진다.

Loop Spec은 꼭 문서로 남겨야 하나?

반복 실행할 작업이라면 남기는 편이 좋다. 특히 자동화가 일정에 따라 돌거나 여러 에이전트를 부르면, 스펙이 없을 때 나중에 “이거 왜 이렇게 했지?”가 바로 온다. 그 순간부터 디버깅이 아니라 추리물이 된다.

Codex Automations를 쓰면 바로 루프 엔지니어링인가?

도구만 쓴다고 자동으로 좋은 루프가 되지는 않는다. Automations는 반복 실행을 도와주는 부품이고, 좋은 루프가 되려면 목표, 상태 파일, 검증, 비용 한도, 승인 지점이 같이 있어야 한다.

서브에이전트는 언제 붙이면 좋나?

작업을 나누면 실제로 품질이 좋아질 때 붙이면 된다. 예를 들어 한 에이전트가 코드를 수정하고, 다른 에이전트가 보안·테스트·범위 이탈을 보는 식이다. 단순 요약 작업에 서브에이전트를 많이 붙이면 비용만 커질 수 있다.

루프가 실패했을 때 가장 먼저 봐야 할 것은?

프롬프트보다 중단 조건과 상태 파일을 먼저 본다. 실패가 기록되지 않았거나, 같은 오류를 계속 반복했거나, 성공 조건이 애매했다면 루프 설계 문제일 가능성이 크다.

처음 만들기 좋은 루프 예시는?

읽기 중심 루프가 좋다. 00.Inbox 노트 중복 분류, PR 설명 초안, 테스트 실패 요약, 문서 링크 점검처럼 실패해도 피해가 작고 사람이 결과를 빨리 확인할 수 있는 작업부터 시작하면 된다.

참고 자료

함께 보면 좋은 글