앞 두 편에서 루프가 무엇이고 자동화·하네스와 어떻게 다른지를 봤습니다. 이 편은 실무에서 가장 먼저 부딪히는 두 질문에 답합니다. "이 작업에 루프를 짜야 하나?"와 "짠다면 무엇으로 짜나?"입니다. 앞 질문의 기준은 하나뿐이고, 뒤 질문의 답은 부품 다섯 개와 토대 하나입니다.
다음 두 편에서 부품을 셋씩 나눠 자세히 다루므로, 여기서는 전체 지도를 그리는 데 집중합니다.
핵심 요약
- 판단 기준은 "그 작업이 반복해서 일어나는가" 하나입니다.
- 일간 보고, 배포 후 검증, 목표 점수까지의 검수, 프로세스 감시에는 루프가 잘 듣습니다.
- 한 번 하고 끝나는 작업에 루프를 짜면 루프를 만드는 시간이 작업 시간보다 깁니다.
- 부품은 자동화(기동), 워크트리(분리), 스킬(지식), 커넥터(검증력), 서브에이전트(분담) 다섯이고, 기억이 토대입니다.
언제 써야 하나: 맞고 안 맞고를 가려내자
판단 기준은 "그거 반복해서 일어나는 작업이냐?"
루프를 짜는 데는 비용이 듭니다. 완료 조건을 숫자로 적고, 검증 스크립트를 만들고, 채점 프롬프트를 다듬고, 기록 형식을 정해야 합니다. 디자인 벤치마크 루프는 캡처 스크립트와 채점 프롬프트가 자리 잡는 데만 열 라운드 가까이 걸렸습니다. 이 비용을 회수하려면 같은 구조가 여러 번 돌아야 합니다. 그래서 기준은 하나입니다. 이 작업이 다시 일어나는가.
"다시"에는 두 종류가 있습니다. 시간 축의 반복(매일, 매주, 배포 때마다)과 수렴 축의 반복(목표에 닿을 때까지 같은 검사를 여러 번). 둘 중 하나라도 해당하면 루프 후보입니다.
루프가 힘을 발휘하는 장면
우리가 실제로 돌려 본 것 중 효과가 분명했던 장면입니다.
- 일간 보고: 매일 00시 30분, 그날의 트랜스크립트와 커밋을 모아 요약하고 노션 「작업 일지」와 볼트에 씁니다. 사람이 하면 매번 30분, 대개는 잊어버립니다.
- 배포 후 검증:
deploy-mini가 빌드와 재시작 뒤 로컬 포트와 도메인의 200 응답을 확인하고, 실패하면 로그의 첫 에러 줄을 보고합니다. - 목표 점수까지의 검수: 캡처, 채점, 수정을 목표 95까지 반복합니다. 홈 페이지는 68에서 95까지 32라운드였습니다.
- 프로세스 감시: 워치독이 5분마다 원격 데스크톱 프로세스를 보고, 내려가 있으면 다시 띄웁니다. 실제로 언로드 사고가 난 뒤 만든 것입니다.
- 결제 같은 고위험 코드의 교차 리뷰: 수정할 때마다 같은 불변 규칙 목록으로 검사합니다.
공통점은 "완료 조건을 실행 결과로 확인할 수 있다"는 것입니다. 200 응답, 점수, 프로세스 생존, 규칙 O/X. 확인할 수 없는 작업은 루프로 만들 수 없습니다.
단발 작업에는 과하기 쉽다
회의록 한 건을 정리하거나, 파일 이름을 한 번 바꾸거나, 처음 보는 코드베이스의 구조를 묻는 일에 루프를 짜면 배보다 배꼽이 큽니다. 이런 일은 좋은 요청 한 번(범위, 목적, 제약, 검증)으로 끝내는 것이 맞습니다. 판단이 애매하면 이렇게 물어보십시오. "이 검증 스크립트를 다음 달에도 쓸까?" 아니오면 루프가 아닙니다.
예외는 실패 비용이 큰 작업(결제, 운영 DB, 고객에게 나가는 문서)입니다. 결제 코드 교차 리뷰는 4라운드로 끝났지만, 3라운드에서 찾은 경쟁 조건은 운영에서 터졌다면 환불과 신뢰 문제로 돌아왔을 것입니다.
톤에는 주의하자
루프라는 말이 근사해서 모든 것을 루프로 부르면 팀 안에서 말이 흐려집니다. 우리는 검증 없이 정해진 시각에 도는 것은 "잡", 검증과 재실행이 있는 것은 "루프", 한 번 시키고 사람이 보는 것은 "요청"으로 구분해 부릅니다. 세 단어를 섞지 않으면 "이거 루프 돌릴까?"에 답이 빨라집니다.
구성 요소는 "5개 더하기 기억"
추상적인 아이디어를 구체적인 부품으로 떨어뜨린다
"검증을 내장한 반복"을 실제로 만들려면 무엇이 필요한지 부품 단위로 내려 보면 다음 여섯 가지입니다. 앞의 다섯은 루프를 돌리는 부품이고, 마지막 하나는 그 부품들이 딛고 선 바닥입니다.
| 번호 | 부품 | 역할 | 우리 실물 |
|---|---|---|---|
| 1 | 자동화 | 루프의 기동 장치. 언제 시작하고 언제 멈추는가 | launchd 잡, /loop, Stop 훅, 워치독 |
| 2 | 워크트리 | 병행 작업이 서로의 파일을 밟지 않게 분리 | claude --worktree, 서브에이전트 isolation: worktree, 문서 13묶음 병렬 집필 |
| 3 | 스킬 | 에이전트가 모르면 추측으로 메울 프로젝트 지식 | codex-score-loop, deploy-mini |
| 4 | 커넥터 | 현실의 도구에 닿아 결과를 실물로 검증하는 힘 | Playwright 캡처, Supabase, codex exec, MCP |
| 5 | 서브에이전트 | 생성과 검증을 다른 주체에 나눠 자기 승인을 막음 | 제작자 Claude와 채점자 Codex, 리뷰어 에이전트 |
| 토대 | 기억 | 세션이 끝나도 남는 디스크 위의 기록 | CLAUDE.md, 자동 메모리, 스킬 파일, 볼트 위키, 라운드 파일 |
여섯 가지가 전부 있어야 루프인 것은 아닙니다. 일간 보고 잡은 자동화와 기억만으로 돕니다. 다만 "왜 이 부품이 빠져 있는가"를 답할 수 있어야 합니다. 부품이 빠진 자리에서 사고가 납니다. 워크트리 없이 두 세션을 같은 폴더에서 돌리다 HEAD가 꼬인 사고를 겪은 뒤 "같은 워크트리에 자동 모드 세션과 일반 세션 동시 금지"가 규칙이 됐습니다. 다음 두 편에서 부품을 셋씩 다룹니다.
정리
- 루프를 쓸지는 "반복해서 일어나는가" 하나로 가릅니다. 시간 축 반복과 수렴 축 반복 둘 다 해당합니다.
- 완료 조건을 실행 결과로 확인할 수 없는 작업은 루프로 만들 수 없습니다.
- 단발 작업은 좋은 요청 한 번으로 끝냅니다. 실패 비용이 큰 단발 작업만 짧은 수렴 루프를 붙입니다.
- 부품은 자동화, 워크트리, 스킬, 커넥터, 서브에이전트 다섯이고 기억이 토대입니다.
- 빠진 부품이 있어도 되지만 왜 빠졌는지 답할 수 있어야 합니다.
자주 묻는 질문
루프 엔지니어링은 어떤 작업에 써야 하나요?
같은 구조로 다시 일어나는 작업입니다. 매일 도는 보고, 배포할 때마다 하는 검증, 목표 점수까지 반복하는 검수, 프로세스 감시가 대표적입니다. 공통 조건은 완료 여부를 200 응답, 점수, 프로세스 생존 같은 실행 결과로 확인할 수 있다는 것입니다.
한 번만 하는 작업에도 루프를 짜야 하나요?
원칙적으로 아닙니다. 검증 스크립트와 채점 프롬프트를 만드는 비용이 작업 자체보다 큽니다. 예외는 실패 비용이 큰 작업입니다. 결제 코드처럼 한 번의 수정이라도 운영에서 터지면 되돌리기 어려운 경우에는 서너 라운드의 짧은 교차 리뷰 루프가 남는 장사입니다.
루프를 쓸지 말지 빠르게 판단하는 요령이 있나요?
두 질문을 던집니다. "이 검증 스크립트를 다음 달에도 쓸까?"와 "완료를 실행 결과로 확인할 수 있을까?" 둘 다 예면 루프, 둘 중 하나라도 아니오면 요청 한 번 또는 단순 잡입니다. 잡, 루프, 요청 세 단어를 섞지 않는 것도 판단을 빠르게 합니다.
루프의 구성 요소 5개와 기억은 각각 무슨 역할인가요?
자동화는 언제 시작하고 멈출지를 정하는 기동 장치, 워크트리는 병행 작업의 파일 분리, 스킬은 추측으로 메워질 프로젝트 지식의 기록, 커넥터는 결과를 실물로 확인하는 검증력, 서브에이전트는 생성과 검증의 분담입니다. 기억은 세션이 끝나도 남아 다음 바퀴의 출발점이 되는 디스크 위의 기록으로, 다섯 부품이 딛고 선 토대입니다.