이 글은 루프 엔지니어링 코스의 첫 편입니다. "루프 엔지니어링"이라는 말이 무엇을 가리키는지, 왜 지금 이 주제가 중요해졌는지, 그리고 이 코스를 끝까지 읽으면 무엇을 할 수 있게 되는지를 다룹니다. 우리가 실제로 돌리고 있는 루프, 예를 들어 사이트 디자인을 Codex 채점으로 95%까지 수렴시킨 62라운드짜리 루프와 맥미니에서 24시간 도는 launchd 잡을 기준으로 설명합니다.
다음 편에서는 이것이 "그냥 자동화"와 무엇이 다른지, 프롬프트에서 컨텍스트, 하네스를 거쳐 루프로 이어지는 흐름 속에서 루프가 어느 층에 있는지를 봅니다.
핵심 요약
- 루프 엔지니어링은 "에이전트에게 지시하는 역할"을 사람에게서 떼어내 시스템에 맡기는 일입니다.
- 한 바퀴는 발견, 실행, 검증, 기억, 재실행으로 돌고, 검증에서 통과하지 못하면 다시 실행으로 돌아갑니다.
- 사람의 일은 끝의 모양(완료 조건)과 옳음을 확인하는 방법(검증 방법)을 정하는 것입니다.
- 평가 대상이 "이번 답"에서 "답을 계속 만들어 내는 구조"로 옮겨갑니다.
- 우리 실무에서는 Codex 채점 루프, 결제 코드 교차 리뷰, 무인 서버 launchd 잡이 이 개념의 실물입니다.
시작하기 전에: 루프 엔지니어링이 대체 무슨 이야기인가
AI 도구들이 같은 방향을 가리키기 시작했다
2026년 현재 Claude Code에는 사람이 개입하지 않고 반복을 돌리기 위한 부품이 이미 들어 있습니다. 세션 안에서 프롬프트를 일정 간격으로 다시 실행하는 /loop, 작업이 끝났다고 말하려는 순간을 가로채 "테스트가 통과할 때까지 멈추지 말라"고 되돌리는 Stop 훅, 자기 컨텍스트에서 따로 일하고 요약만 돌려주는 서브에이전트, 세션이 끝나도 남는 CLAUDE.md와 자동 메모리가 그것입니다. Codex 쪽도 codex exec로 비대화형 실행을 지원하고 AGENTS.md로 프로젝트 지침을 받습니다. 도구마다 이름은 다르지만 방향은 하나입니다. 사람이 한 번 시키고 결과를 눈으로 보는 방식에서, 시스템이 스스로 돌면서 검증까지 하는 방식으로 무게중심이 옮겨가고 있습니다.
우리 교육에서도 이 흐름은 이미 커리큘럼 안에 있습니다. 초급 8주의 5주차가 "좋은 요청과 검증 게이트", 7주차가 "내 컴퓨터를 꺼도 도는 무인 잡", 8주차가 강사의 개발 루프 시연입니다. 루프 엔지니어링은 이 세 주차를 한 개념으로 묶은 이름이라고 생각하셔도 됩니다.
이 코스를 다 읽으면 알게 되는 것
여덟 편을 읽고 나면 다음을 스스로 판단하고 설계할 수 있게 되는 것이 목표입니다.
- 어떤 작업에 루프를 짜야 하고 어떤 작업은 그냥 한 번 시키면 되는지 가르는 기준
- 루프를 이루는 부품 다섯 가지(자동화, 워크트리, 스킬, 커넥터, 서브에이전트)와 토대인 기억의 역할
- Claude Code와 Codex에서 각 부품이 무엇에 해당하는지
- 안쪽 루프와 바깥쪽 루프를 구분해 "쓸수록 똑똑해지는" 구조를 만드는 법
- 우리가 실제로 돌린 루프의 라운드 기록을 읽고 자기 작업에 옮기는 법
루프 엔지니어링이란 무엇인가: 지시하는 사람을 시스템으로 갈아 끼우는 것
한마디로 하면 "지시하는 역할"을 떼어내는 것
Claude Code를 처음 쓰는 분들의 하루는 이렇습니다. 요청을 쓰고, 결과를 보고, 마음에 안 드는 곳을 다시 요청하고, 또 본다. 이 반복에서 사람은 두 가지 일을 동시에 하고 있습니다. 하나는 "무엇이 완성인가"를 판단하는 일이고, 다른 하나는 그 판단에 따라 "다음 지시"를 쓰는 일입니다. 루프 엔지니어링은 이 둘 중 뒤의 것, 즉 다음 지시를 쓰는 역할을 사람에게서 떼어내는 일입니다.
사이트 디자인 벤치마크 작업이 좋은 예입니다. 처음 며칠은 화면을 캡처해서 눈으로 보고 "여백이 넓다", "헤더가 다르다"를 직접 적어 넘겼습니다. 라운드가 열 번을 넘어가자 사람이 판정하는 편차가 오히려 더 컸습니다. 그래서 판정을 Codex에 넘기고 사람은 규칙만 정했습니다. "구조 유사도를 0에서 100으로 점수 내고, 수정 지시는 다섯 개 이하로, 문구와 이미지 내용은 채점에서 빼라." 그 뒤로 사람은 지시를 쓰지 않았습니다. 62라운드가 돌아가는 동안 사람이 한 일은 점수 표를 읽고, 채점자가 오판한 자리를 실측으로 반박하고, 마감 시점을 결정한 것뿐입니다.
지시하는 사람을 지시하는 시스템으로 갈아 끼운다
"떼어낸 역할"은 어디로 가느냐. 시스템으로 갑니다. 여기서 시스템은 거창한 것이 아닙니다. 다음 세 가지가 파일로 적혀 있으면 시스템입니다.
- 완료 조건: 목표 점수 95, 또는 "빌드 통과 + 모바일 390px에서 가로 스크롤 0건"처럼 숫자나 실행 결과로 확인 가능한 문장
- 검증 방법: 누가 어떤 입력을 보고 어떤 형식으로 판정하는가(캡처 스크립트, 채점 프롬프트, 테스트 명령)
- 재실행 규칙: 판정이 "수정 필요"면 무엇을 반영하고 무엇은 무시하는가(3회 일치 규칙, 최고점 롤백)
우리는 이 세 가지를 codex-score-loop라는 스킬 파일 하나에 적어 두었습니다. 다음 작업에서는 "그 루프 돌려" 한마디면 같은 판정 기준으로 돌아갑니다. 지시하는 사람이 필요 없어진 것이 아니라, 지시가 파일 안으로 들어간 것입니다.
한 바퀴의 모양: 발견, 실행, 검증, 기억, 재실행
루프 한 바퀴를 우리 사례에 대응시키면 이렇습니다.
| 단계 | 하는 일 | 디자인 벤치마크에서 | 무인 서버에서 |
|---|---|---|---|
| 발견 | 지금 무엇이 문제인지 찾는다 | 원본 HTML/CSS를 curl로 받아 섹션 순서와 컨테이너 폭을 숫자로 실측 | launchd 잡이 정해진 시각에 수집 대상(트랜스크립트, 커밋)을 모은다 |
| 실행 | 수정하거나 만든다 | 실측값을 프로토타입에 이식 | 요약을 만들어 노션 DB와 볼트에 쓴다 |
| 검증 | 완료 조건에 대조한다 | Playwright 캡처 후 codex exec로 채점, 점수와 수정 지시 회수 |
헬스체크(도메인 200 응답), 실패 시 로그의 첫 Error: 줄 확인 |
| 기억 | 다음 바퀴가 쓸 것을 남긴다 | 라운드별 점수 파일 r1.md, r2.md …, 채점자 오판 기록 |
로그 파일, 실패 알림 |
| 재실행 | 통과가 아니면 실행으로 돌아간다 | 수정 지시 반영 후 다시 캡처 | 워치독이 5분마다 상태를 보고 죽은 프로세스를 다시 띄운다 |
"검증에서 멈추지 않으면 루프가 아니다"라는 점만 기억하시면 됩니다. 검증 없이 실행만 반복하는 것은 루프가 아니라 스팸입니다. 우리 채점 루프에서 "통과" 판정이 나오기 전까지 사람은 어떤 라운드도 끝났다고 부르지 않았습니다.
사람의 일은 끝의 모양과 옳음을 확인하는 방법을 정하는 것
그러면 사람은 놀아도 되느냐. 아닙니다. 사람의 일이 앞쪽으로 이동합니다. 루프가 돌기 전에 두 가지를 정해야 합니다.
첫째, 끝의 모양입니다. "예쁘게"는 끝의 모양이 아닙니다. "홈 페이지 구조 유사도 95 이상, 3회 채점 중앙값 기준"이 끝의 모양입니다. 우리 교재 7주차의 무인화 완료 기준도 같은 형식입니다. "내 노트북을 끄고 다음 날 아침, 결과물이 나와 있는가."
둘째, 옳음을 확인하는 방법입니다. 이것이 더 어렵습니다. 디자인 루프에서 우리는 세 번 방법을 바꿨습니다. 처음엔 풀페이지 한 장으로 채점했는데 90 부근에서 정체됐습니다. 섹션별 쌍 비교로 바꾸자 다시 올랐습니다. 그다음 고정 네비게이션이 원본 캡처에만 겹쳐서 채점자가 없는 컴포넌트를 요구하는 오판이 나왔고, 캡처 스크립트에서 position: static을 주입해 공정하게 만들었습니다. 검증 방법을 고치는 것이 사람의 핵심 일이었습니다.
사람이 평가하는 자리가 바뀐다
평가 대상이 답에서 구조로 옮겨간다
지금까지 우리는 "이번 답이 좋은가"를 봤습니다. 루프를 짜고 나면 "이 구조가 좋은 답을 계속 만들어 내는가"를 보게 됩니다. 두 질문은 다릅니다.
결제 코드 교차 리뷰가 그 차이를 보여줍니다. SQLite에서 Supabase로 결제 계층을 옮기면서 Claude가 만든 diff를 Codex에 넘겨 4라운드를 돌렸습니다. 프롬프트에는 불변 규칙 다섯 개를 번호로 적었습니다. 금액은 서버가 정한다, 환불 규정이 없는 과정은 주문을 거부한다, 신청과 주문의 위변조를 막는다, 승인 시 금액을 대조한다, 중복 결제를 차단한다. 그리고 "각 규칙이 유지되는지, 트랜잭션을 빼면서 생긴 구멍, 경쟁 조건, 에러 노출"을 항목별로 묻게 했습니다. 3라운드에서 동시 주문과 비원자적 승인이라는 경쟁 조건이 나왔고 RPC와 유니크 인덱스로 막았습니다.
여기서 평가할 것은 "그 diff가 좋았는가"가 아닙니다. "불변 규칙을 번호로 적고 라운드마다 지난 지시 반영 여부를 O/X로 받는 이 구조가, 다음 결제 수정에서도 경쟁 조건을 잡아낼 것인가"입니다. 그래서 프롬프트 뼈대를 스킬에 넣었고, 프로젝트 규칙에 "결제 코드 수정 시 교차 리뷰 필수"를 적었습니다.
솔직히 밝히자면 여기는 이 코스의 해석이다
"루프 엔지니어링"은 공식 용어가 아닙니다. Claude Code 문서에도 Codex 문서에도 이 이름의 기능은 없습니다. 각 도구가 제공하는 것은 /loop, Stop 훅, 서브에이전트, 워크트리, 스킬, 메모리 같은 부품이고, 그것을 "지시하는 사람을 시스템으로 갈아 끼운다"는 한 문장으로 묶은 것은 이 코스의 해석입니다. 여러 사람이 비슷한 뜻으로 이 말을 쓰기 시작했지만, 정의가 합의된 단계는 아닙니다.
그래서 이 코스는 정의보다 사례에 무게를 둡니다. 우리가 62라운드를 돌리며 배운 규칙, 4라운드에서 경쟁 조건을 찾은 프롬프트, 맥미니에서 매일 00시 30분에 도는 보고 잡의 구조는 해석이 아니라 기록입니다. 개념이 바뀌어도 기록은 남습니다. 모델이 바뀌어도 "검증을 내장한 반복"이라는 원리는 남습니다. 우리가 "모델 종속 금지, 원리 중심"을 고집하는 이유입니다.
정리
- 루프 엔지니어링은 다음 지시를 쓰는 역할을 사람에게서 떼어내 파일(완료 조건, 검증 방법, 재실행 규칙)에 넣는 일입니다.
- 한 바퀴는 발견, 실행, 검증, 기억, 재실행이며 검증이 빠지면 루프가 아닙니다.
- 사람의 일은 앞으로 이동합니다. 끝의 모양을 숫자로 정하고, 옳음을 확인하는 방법을 고치는 것이 핵심입니다.
- 평가 대상은 "이번 답"에서 "답을 계속 만드는 구조"로 옮겨갑니다.
- 이름은 이 코스의 해석이지만, 라운드 기록과 프롬프트 뼈대는 실측입니다.
자주 묻는 질문
루프 엔지니어링이란 한마디로 무엇인가요?
에이전트에게 매번 다음 지시를 쓰던 사람의 역할을 시스템에 넘기는 일입니다. 시스템은 완료 조건, 검증 방법, 재실행 규칙이 적힌 파일과 그것을 실행하는 스케줄러나 훅으로 이루어집니다. 사람은 조건을 정하고 결과 기록을 읽습니다.
루프 엔지니어링이라는 말은 누가 만들었나요?
특정 한 사람이 정의한 공식 용어가 아닙니다. Claude Code와 Codex의 공식 문서에는 이 이름의 기능이 없고, 하네스와 에이전트 워크플로우를 다루는 여러 글에서 비슷한 뜻으로 쓰이기 시작한 표현입니다. 이 코스에서는 우리 실무 사례를 기준으로 정의해서 씁니다.
루프 한 바퀴는 어떤 단계로 이루어지나요?
발견(무엇이 문제인지 실측), 실행(수정 또는 생성), 검증(완료 조건과 대조), 기억(다음 바퀴가 쓸 기록), 재실행(통과가 아니면 실행으로 복귀)입니다. 디자인 루프에서는 실측, 이식, 캡처와 채점, 라운드 파일 기록, 재캡처가 이에 해당합니다.
루프 엔지니어링에서 사람은 무엇을 하나요?
루프가 돌기 전에 끝의 모양을 숫자나 실행 결과로 정하고, 옳음을 확인하는 방법(캡처 스크립트, 채점 프롬프트, 테스트)을 설계합니다. 루프가 도는 동안에는 기록을 읽고 채점자의 오판을 실측으로 반박하며, 천장에 닿았을 때 마감을 결정합니다.