프로젝트 07. 첫 번째 자동 루프 구축하기

관련 강의: L13. 왜 에이전트에게 프롬프트하는 것을 그만둬야 하는가

할 일

이것은 "하네스"에서 "루프"로 넘어가는 전환 프로젝트입니다. 여러분은 이미 적절한 환경, 지침, 피드백으로 에이전트를 설정하는 방법을 알고 있습니다 — 이제 그 설정을 스스로 돌아가는 루프로 바꿀 것입니다.

세 가지 점진적인 실험을 할 것입니다: 먼저 작업을 수동에서 /goal으로 바꾸고, 그 다음 모니터링 작업을 /loop 타이머로 바꾸고, 마지막으로 완전한 메이커-체커 루프를 구축하여 여러분이 루프 밖으로 나갔을 때 어떤 느낌인지 경험할 것입니다.

프로젝트 파일

리포지토리 경로: projects/project-07/

디렉토리	내용	하는 일
`starter/`	완전한 하네스(P06 최종 상태)가 있는 작은 지식 베이스 프로젝트로, AGENTS.md, feature_list.json, init.sh, session-handoff.md, clean-state-checklist.md가 포함되어 있습니다.	이 하네스를 자동으로 반복할 수 있는 하네스로 바꾸세요.
`solution/`	목표 루프, 타이머 루프, 메이커-체커 루프라는 세 가지 루프의 완전한 구현체와 루프 상태 파일, 검증 스크립트가 포함되어 있습니다.	루프 설계 패턴과 상태 관리의 참고 자료

사용할 도구

Claude Code 또는 Codex
Git
P06에서 가져온 완전한 하네스
터미널 멀티플렉서 (tmux 또는 screen, 오래 실행되는 루프 관찰용)
선택 사항: GitHub Actions 또는 cron (고급 이벤트 기반 / 예약 실험용)

단계

준비

P06를 마쳤던 같은 커밋에서 시작하세요.
세 개의 브랜치를 만드세요: p07-goal-loop, p07-timer-loop, p07-maker-checker.
하네스가 작동하는지 확인하세요: init.sh를 실행하고, 상태 파일, 기능 목록, 인계 문서가 모두 제자리에 있는지 확인하세요.
루프가 반복적으로 작업할 대상 작업을 하나 고르세요. 완료 기준이 명확한 중간 규모의 작업을 고르세요 — 예: "모든 모듈에 단위 테스트를 추가하여 80% 커버리지 달성" 또는 "모든 API 엔드포인트에 입력 유효성 검사 추가".

실험 1: 목표 루프 — 수동 실행에서 자동 실행으로

p07-goal-loop 브랜치로 전환하세요.

목표 설명 작성: 선택한 작업을 goal.md 파일로 만드세요. 다음을 포함합니다:
- 명확한 목표 ("무엇이 완료로 간주되는가")
- 검증 방법 ("어떻게 완료를 확인하는가" — 테스트 실행? 린트 실행? 커버리지 확인?)
- 중단 조건 ("언제 멈춰야 하는가" — 최대 턴? 시간 제한? 예산 제한?)
- 제약 조건 ("무엇을 건드리지 말아야 하는가" — 프로덕션 설정, 데이터베이스 스키마 등)
첫 수동 실행: 직접 에이전트에게 작업을 수동으로 주세요. 몇 턴이 걸렸는지, 몇 번 개입했는지, 결과 품질이 어땠는지 기록하세요. 이것이 여러분의 기준선입니다.
/goal로 실행: 같은 goal.md를 입력으로 사용하여 /goal 모드로 실행하세요. 에이전트는 목표가 달성되거나 중단 조건이 발동될 때까지 스스로 반복합니다.
결과 비교:
- 턴 수의 차이
- 개입 횟수의 차이
- 결과 품질의 차이 (같은 검증 기준 사용)
- 소요 시간의 차이
goal.md 반복하기: 결과가 좋지 않으면 목표 설명을 수정하고 다시 실행하세요. 결과에 만족하거나, 이 작업에서 목표 루프가 할 수 있는 한계를 확인할 때까지 계속하세요.

실험 2: 타이머 루프 — 모니터링을 심장 박동으로 바꾸기

p07-timer-loop 브랜치로 전환하세요.

모니터링 작업 고르기: 평소에 수동으로 하는 반복적인 확인을 찾으세요. 예를 들어:
- 매시간 테스트 스위트 실행하고 실패한 것 고치기
- 매일 아침 의존성 보안 업데이트 확인하기
- 매 커밋마다 코딩 스타일 위반 확인하기
- 주기적으로 TODO 주석을 스캔하여 오래된 것 확인하기
모니터링 프롬프트/스크립트 작성: 모니터링 단계를 명확하게 적으세요 — 무엇을 확인할지, 문제가 발견되면 무엇을 할지, 언제 인간을 호출할지.
/loop (또는 Codex 스레드 자동화)로 실행:
- 적절한 간격을 설정하세요 (10-30분 권장 — 너무 짧으면 짜증나고 너무 길면 효과를 못 봄)
- 최소 2시간 동안 실행하세요 (또는 다른 일을 하고 나중에 돌아오세요)
결과 기록:
- 몇 개의 문제를 발견했는가?
- 몇 개를 스스로 고쳤는가?
- 몇 개가 거짓 양성이었는가?
- 몇 개를 더 악화시켰는가?
- 결과를 후속 조치하는 데 얼마나 시간을 썼는가?
반성하기: 이 모니터링 작업을 자동화할 가치가 있는가? 절약한 시간과 후속 조치에 쓴 시간을 비교해보세요. 가치가 없다면, 잘못된 작업을 고른 것인가, 아니면 루프가 잘못 설계된 것인가?

실험 3: 메이커-체커 루프 — 루프에서 자신을 빼내기

p07-maker-checker 브랜치로 전환하세요.

이것은 세 실험 중 가장 중요합니다. 여러분이 거기 없어도 돌아가는 완전한 루프를 구축할 것입니다:

루프 구조 설계:
- 메이커 에이전트: 구현하고, 코드를 작성하고, 파일을 수정합니다
- 체커 에이전트: 검증하고, 테스트를 실행하고, 코드 리뷰를 하고, 통과 / 실패를 판단합니다
- 상태 파일 (loop-state.md): 현재 라운드, 한 일, 검증 결과, 다음 할 일을 기록합니다
- 중단 조건: N회 연속 통과, 또는 최대 라운드 도달
세 개의 프롬프트 작성:
- 메이커 지침 (무엇을 할지, 어떻게 할지, 무엇을 건드리지 말아야 할지)
- 체커 지침 (무엇을 검증할지, 어떻게 검증할지, 무엇을 통과로 간주할지, 어떻게 피드백을 줄지)
- 루프 제어 로직 (누가 먼저 하는지, 인계가 어떻게 작동하는지, 다음 라운드를 어떻게 시작하는지)
최소 5라운드 실행:
- 1라운드: 메이커 구현 → 체커 검증 → 실패 → 메이커에게 피드백
- 2라운드: 메이커가 피드백 기반으로 수정 → 체커 검증 → ...
- ...
- 연속 통과할 때까지, 또는 당신이 중단할 때까지
각 라운드의 상태 기록:
- 라운드 번호
- 메이커가 한 일
- 체커가 발견한 문제점
- 통과 / 실패
- 당신이 개입했는가? (했다면 왜?)
최종 회고:
- 몇 번 개입했는가? 왜?
- 개입하지 않았다면 무슨 일이 벌어졌을까?
- 체커가 놓친 문제가 있는가?
- 메이커가 계속 같은 실수를 저지르는가?
- 이 루프의 품질 상한선은 어디인가? 메이커 역량인가, 아니면 체커 역량인가?

결과 측정 방법

지표	실험 1 (목표)	실험 2 (타이머)	실험 3 (메이커-체커)
작업 완료율	목표에 도달했는가?	몇 개의 모니터링 사이클이 실행되었는가?	통과할 때까지 몇 라운드가 걸렸는가?
인간 개입	몇 번 개입했는가?	후속 조치에 얼마나 시간을 썼는가?	몇 번 개입했는가?
결과 품질	수동과 비교했을 때 어때?	거짓 양성률? 놓친 이슈?	체커가 당신이 못 찾았을 문제를 몇 개나 찾았는가?
절약 시간	얼마나 시간을 절약했는가?	자동화할 가치가 있는가?	루프를 설계하는 데 쓴 시간 대비 절약한 시간
신뢰성	중단 조건이 믿을만했는가?	통제 불능이 되었는가?	루프가 같은 곳에서 막힐 수 있는가?

제출할 것

goal.md (실험 1의 목표 설명, 최소 두 번의 반복)
실험 1 비교 노트: 수동 대 목표 루프
실험 2 모니터링 프롬프트 + 2시간 실행 로그
실험 3의 세 가지 프롬프트 (메이커 / 체커 / 루프 제어)
실험 3의 loop-state.md (최소 5라운드 기록)
최종 회고: 세 실험 모두에서 얻은 교훈, 루프 엔지니어링에 대한 여러분의 이해가 어떻게 바뀌었는지, 어떤 것들이 루프화할 좋은 후보이고 어떤 것들은 아닌지

프로젝트 07. 첫 번째 자동 루프 구축하기 ​

할 일 ​

프로젝트 파일 ​

사용할 도구 ​

단계 ​

준비 ​

실험 1: 목표 루프 — 수동 실행에서 자동 실행으로 ​

실험 2: 타이머 루프 — 모니터링을 심장 박동으로 바꾸기 ​

실험 3: 메이커-체커 루프 — 루프에서 자신을 빼내기 ​

결과 측정 방법 ​

제출할 것 ​

관련 강의 ​