실례와 정리: 이 문서 묶음 자체가 루프로 만들어졌다

코스의 마지막 편입니다. 앞 일곱 편에서 정의, 자동화와의 차이, 적용 기준, 부품 여섯 가지, 도구 대응, 안쪽과 바깥쪽 루프를 봤습니다. 이 편은 개념을 한 번 더 설명하는 대신, 지금 읽고 계신 이 문서 묶음이 실제로 어떤 루프로 만들어졌는지를 보여 드립니다. 그다음 코스 전체의 요점을 여섯 줄로 정리합니다.

읽고 나면 자기 손에 있는 작업 하나를 골라 안쪽 루프와 바깥쪽 루프를 그릴 수 있고, 내일 무엇부터 시작할지 정할 수 있습니다.

핵심 요약

• 이 문서 묶음(13개 코스)은 브리프와 구조 스펙을 받은 작성 에이전트 13개가 병렬로 쓰고, 공식 문서 대조와 분량·문구 게이트를 거쳐 나왔습니다.
• 사이트 디자인은 Codex 채점 62라운드, 결제 코드는 교차 리뷰 4라운드, 운영은 launchd 잡과 워치독이 맡습니다.
• 교훈은 위키, 스킬, CLAUDE.md 세 층으로 굳어 다음 작업의 출발점이 됐습니다.
• 시작은 프롬프트 한 줄이 아니라 완료 조건 한 문장과 검증 방법 하나입니다.

실례: 이 문서 묶음 자체가 루프로 만들어졌다

좋은 실례가 바로 눈앞에 있다

루프 엔지니어링을 설명하려고 다른 회사의 사례를 빌릴 필요가 없었습니다. junglefutures.com의 학습 문서와 그 문서가 올라가는 사이트가 그 자체로 실례입니다. 사이트 디자인은 8월 25일부터 Codex 채점 루프로 95%까지 수렴시켰고, 문의 admin 화면과 결제 코드는 같은 루프의 변형으로 검증했으며, 이 문서 묶음은 그 뒤에 같은 방식으로 집필됐습니다.

안쪽 루프(이 문서 묶음을 완성시키는 반복)

문서 한 편이 나오는 안쪽 루프는 다섯 단계입니다.

1. 스펙 확인: 작성 에이전트는 content/docs/_BRIEF.md(정체성, 형식, 사실 검증 규칙)와 _spec/group-NN.json(제목, 난이도, 읽는 시간, 목표 글자 수, 소주제 목록)을 먼저 읽습니다. 소주제의 순서와 개수는 스펙을 따르고 문장은 전부 새로 씁니다.
2. 조사: 언급할 기능은 공식 문서를 WebFetch로 열어 확인합니다. /loop의 7일 만료, --worktree의 생성 위치, 서브에이전트 frontmatter 필드, 자동 메모리 경로, 프록시 환경 변수가 그렇게 확인됐고, codex exec 옵션은 설치된 0.145.0의 --help로, 우리 사례의 숫자(62라운드, 4라운드, 5분 워치독)는 볼트 문서와 실제 plist로 맞췄습니다.
3. 집필: 브리프의 골격(도입, 핵심 요약, 본문 h2, 정리, 자주 묻는 질문)대로 씁니다.
4. 검증: 분량이 목표의 ±20% 안인지, 발행 글에 작대기가 없는지, 확신 없는 수치가 들어가지 않았는지 검사합니다. 검사에 걸리면 3번으로 돌아갑니다.
5. 표시 확인: 사이트에 올린 뒤 모바일 390px와 360px 뷰포트에서 scrollWidth를 실측해 가로 스크롤이 0건인지 봅니다. 캡처를 눈으로 보고 판단하지 않는다는 것이 우리 규칙입니다.

검증 단계(4번)가 안쪽 루프의 정지 조건입니다. 이 글을 쓰는 동안에도 워치독의 재시도 규칙을 기억으로 적었다가 실제 스크립트를 열어 "bootstrap 최대 6회, 5초 간격"으로 고쳤습니다. 검증이 없었으면 추측이 그대로 발행됐을 것입니다.

바깥쪽 루프(세션을 가로질러 똑똑해지는 구조)

문서가 나온 뒤에 도는 바깥쪽 루프는 세 층입니다.

1. 위키: 채점 루프의 방법론 문서(8월 25일)와 적용 확장 문서(8월 26일)가 .omc/wiki/와 옵시디언 볼트에 있습니다. 라운드별 점수 표, 채점자 오판과 실측 반박, 기술 함정이 서사로 남습니다.
2. 스킬: 반복할 절차는 codex-score-loop(전역)와 deploy-mini(프로젝트) SKILL.md로 굳었습니다. 다음 세션은 "그 루프 돌려" 한마디로 같은 형식의 채점을 시작합니다.
3. 규칙: 한 줄로 줄어드는 것은 CLAUDE.md에 들어갔습니다. "결제 코드 수정 시 교차 리뷰 필수", "UI 변경 시 390/360px 실측", "같은 워크트리에 자동 세션과 일반 세션 동시 금지".

이 문서 묶음의 브리프 자체가 바깥쪽 루프의 산물입니다. 앞선 발행 작업에서 굳어진 규칙, 즉 "발행 글에 시각적 작대기 금지"와 "확인 필요라고 쓰지 말고 확인해서 쓰거나 빼라"가 그대로 브리프에 들어가 이번 집필의 검증 게이트가 됐습니다.

구성 요소와의 대응도 분명하다

개념을 설명하는 글이 그 개념의 실연이 되어 있다

이 코스는 "루프를 이렇게 짜라"고 말하는 글이 아니라 그렇게 짠 루프가 만든 글입니다. 발표 자료가 아니라 지금 돌아가는 시스템으로 가르치고, 정지 규칙은 증거(실행 화면, 로그, 점수 표)라는 우리 관점 그대로입니다. 8주차 교재의 강사 개발 루프(플랜모드, 미리 써 둔 프롬프트, 샘플 확인, 오토모드, 다른 모델 교차 체크, 반복)가 안쪽 루프이고, 수업 뒤 교재와 규칙서에 남는 것이 바깥쪽 루프입니다.

자, 정리해 보자

요점을 다시 짚는다

여섯 줄입니다.

1. 루프 엔지니어링은 다음 지시를 쓰는 역할을 사람에게서 떼어내 완료 조건, 검증 방법, 재실행 규칙이 적힌 파일에 넣는 일입니다.
2. 자동화와의 차이는 검증 내장, 목적 입력, 기록을 통한 개선 세 가지이며, 루프는 하네스 한 층 위의 관제실입니다.
3. 쓸지 말지는 "반복해서 일어나는가"와 "완료를 실행 결과로 확인할 수 있는가" 두 질문으로 가릅니다.
4. 부품은 자동화, 워크트리, 스킬, 커넥터, 서브에이전트 다섯이고 기억이 토대입니다. 빠진 부품은 이유를 답할 수 있어야 합니다.
5. 제작자와 판정자를 분리합니다. 다른 회사 모델이 가장 강한 분리이고, 도구를 막은 서브에이전트가 그다음입니다.
6. 안쪽 루프의 교훈을 바깥쪽 루프가 위키, 스킬, 규칙 세 층으로 굳힐 때만 "쓸수록 똑똑해진다"가 참이 됩니다.

당신의 일은 이제 프롬프트를 한 줄 더 쓰는 게 아니다

내일 아침 Claude Code를 열었을 때 할 일은 더 좋은 프롬프트를 고민하는 것이 아닙니다. 다음 순서입니다.

1. 지난주에 두 번 이상 한 작업을 하나 고릅니다.
2. 완료 조건을 실행 결과로 한 문장 씁니다. "도메인이 200을 돌려준다", "점수 95 이상, 3회 중앙값", "테스트 통과."
3. 그 조건을 확인하는 방법을 하나 만듭니다. 스크립트 한 개, 채점 프롬프트 한 개, 테스트 명령 한 줄.
4. 정지 조건 세 겹(완료 판정, 상한, 천장 판별)을 적습니다.
5. 처음 세 라운드는 사람이 결과를 봅니다. 채점자가 오판하면 실측으로 반박하고 그 사실을 적습니다.
6. 세 라운드가 안정되면 절차를 SKILL.md로, 한 줄 규칙을 CLAUDE.md로 옮깁니다.

이 여섯 단계를 한 작업에 적용하고 나면 두 번째 작업은 절반의 시간이 걸립니다. 그것이 우리가 홈 페이지 32라운드에서 결제 diff 4라운드로 온 길입니다.

정리

• 이 문서 묶음은 스펙 확인, 조사, 집필, 검증, 표시 확인의 안쪽 루프와 위키, 스킬, 규칙의 바깥쪽 루프로 만들어졌습니다.
• 여섯 부품 전부 이 작업에 대응물이 있으며, 작성자와 검토자의 분리가 품질을 지켰습니다.
• 코스의 요점은 여섯 줄이고, 시작은 반복되는 작업 하나와 완료 조건 한 문장입니다.
• 첫 루프가 안정되면 절차는 스킬로, 규칙은 CLAUDE.md로 옮깁니다.

자주 묻는 질문