실례와 정리 — 이 가이드 자체가 루프로 만들어졌다

앞 글 안쪽 루프와 바깥쪽 루프에서 루프가 쓸수록 똑똑해지는 이중 구조를 봤다. 이 글은 코스의 마지막으로, 그 구조가 실제로 돌아간 실례 — 다름 아닌 이 가이드 자체 — 를 구성 요소와 대응시켜 보고, 여기까지의 요점을 한 번 더 정리한다.

실례 ── 이 가이드 자체가 루프로 만들어졌다

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

여기까지 개념을 설명했는데, 사실 좋은 실례가 바로 눈앞에 있다. 지금 읽고 있는 이 가이드 자체가 루프 엔지니어링으로 만들어졌다.

이 가이드의 바탕이 된 글은 loop-engineering이라는 프로젝트 안의 '기술 기사 루프'(기동 커맨드는 start-tech-article-loop)로 생성됐다. 그 구조는 여기까지 설명해 온 안쪽 루프·바깥쪽 루프·구성 요소와 거의 그대로 대응한다.

안쪽 루프(이 가이드를 완성시키는 반복)

1. 발견(탐색) → 어떤 관점·구성으로 써야 할지 뽑아낸다
2. 조사 → 인용·귀속·날짜 같은 사실을 1차 정보로 뒷받침한다
3. 편집 → 메모와 조사 결과를 바탕으로 본문을 쓴다
4. 검증 → 편집과 독립된 담당이 적대적으로 리뷰한다
5. 표시 확인 → HTML로 만들어 PC·모바일에서의 가독성을 점검한다

이걸 완료의 정의(독자가 무엇을 설명할 수 있게 되는가, 분량, 인용의 정확성 등)를 만족할 때까지 반복한다. 그대로 발견 → 실행 → 검증 → 기억 → 재실행이다.

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

• 회차별 진행 상황은 runs/ 디렉터리의 파일에 적어 남긴다(중단·재개의 기점이 된다)
• 보존 가치가 있는 교훈은 lessons.md로 통합한다. 각 교훈은 범용성으로 랭킹을 매기고, 중복을 걸러낸 뒤 덧붙인다. 안쪽 루프와 바깥쪽 루프에서 구현 예로 든 절차가 여기서 실제로 돌아간다

실제로 이 바깥쪽 루프는 과거에 효과를 봤다. 예를 들어 "에이전트는 잊지만, 리포지터리는 잊지 않는다"는 인용을 어느 회차의 생성 담당이 '모델은 잊는다'라고 잘못 썼다. 그 오류가 검증에서 잡혔고, 교훈으로 lessons.md에 '인용은 원문과 축어로 대조하라', '주어는 에이전트다'라고 적혀 남았다. 그래서 이 가이드의 기억 글은 처음부터 올바른 주어로 쓰였다. 이건 바깥쪽 루프가 안쪽 루프를 끌어올린 살아 있는 사례다.

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

• 서브에이전트(생성과 검증의 분리): 본문을 쓰는 담당(generator에 해당하는 역할)과 그걸 검증하는 담당(verifier에 해당하는 역할)은 반드시 따로 둔다. 쓴 본인이 스스로 합격을 내는 일은 없다. 이건 앞서 말한 일반적인 패턴 이름으로 하면 Generator–Verifier(생성과 검증의 분리)에 해당한다. 참고로 이 프로젝트에서는 검증 쪽이 한발 더 들어가 '망가져 있다는 전제로 반증을 시도하는' 운용을 하고, 이걸 프로젝트 고유의 호칭으로 '적대적 검증'이라 부른다. 일반 용어와 프로젝트 고유 호칭은 구분해서 이해하면 좋겠다. Claude Code에서 이런 역할 분리를 실제로 어떻게 두는지는 서브에이전트를 참고하면 된다.
• 기억: 진행 상황은 runs/, 교훈과 제외 사항은 lessons.md, 횡단적인 학습은 프로젝트 안의 .claude/memory/ — 이렇게 용도별로 디스크상의 자리가 나뉘어 있다.
• 워크트리·스킬·커넥터: 각 담당은 독립된 작업 영역을 갖고(워크트리), 편집·조사·리뷰 같은 전문 지식을 스킬로 안고, 필요한 도구에 커넥터를 통해 접속한다.

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

오스마니가 든 '5개 + 기억' 구성 요소와 이 프로젝트를 만든 방식은 거의 들어맞는다. 그리고 마무리에 어울리는 중첩이 여기 있다. 루프 엔지니어링을 해설하는 이 글은 루프 엔지니어링 자체로 만들어졌다. 개념을 설명하는 글이 그 개념의 실연이 되어 있다.

자, 정리해 보자

요점을 다시 짚는다

긴 길이었으니 요점을 한 번 더 정리해 둔다.

• 정의: 루프 엔지니어링이란 에이전트에게 지시를 주는 역할을 자신에게서 떼어내고 그 일을 하는 시스템 — 단발 프롬프트를 그만두고 발견 → 실행 → 검증 → 기억 → 재실행을 자동으로 돌리는 루프 — 을 설계하는 것. 사람은 개별 지시가 아니라 그 구조를 설계한다.
• 평가 관점: 사람이 손대는 자리가 개별 출력에서 루프(프로세스) 자체로 옮겨간다. 완료 조건과 검증 역할의 설계가 사람의 주된 일이 된다.
• 하네스와의 관계: 루프 엔지니어링은 '하네스의 한 층 위'에 위치한다. 하네스가 1회 실행분의 장치를 정하고, 루프가 그걸 몇 번이고 돌려 자기 개선시킨다.
• 활용 장면: 일간 트리아지나 CI 실패 요약 같은 반복 태스크에 잘 듣는다. 단발·일회성 작업에는 루프 구축 비용이 과해지기 쉽다.
• 구성 요소: 자동화·워크트리·스킬·플러그인/커넥터·서브에이전트, 그리고 토대가 되는 기억(디스크로). 에이전트는 잊지만, 리포지터리는 잊지 않는다.
• 안쪽/바깥쪽 루프: 안쪽이 태스크를 완료시키고, 바깥쪽이 교훈을 다음번의 출발점으로 바꾼다. 둘이 맞물리면 시스템은 쓸수록 똑똑해진다.

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

그리고 이 가이드의 출발점에 놓았던 보리스 체르니와 피터 슈타인베르거의 말로 돌아가 보자. 둘이 각자 다른 자리에서 같은 방향을 가리킨 건 우연이 아니다. AI 에이전트가 스스로 굴러갈 수 있게 된 지금, 사람의 부가가치는 '더 나은 한 줄의 프롬프트'에서 '더 나은 루프의 설계'로 옮겨 가고 있다.

당신의 일은 이제 프롬프트를 한 줄 더 쓰는 게 아니다. 계속 도는 루프를 쓰는 것이다.

우선 작은 안쪽 루프를 한 바퀴 돌려 보고 배운 것 한 줄을 남기는 데서 시작해 보자. 그게 당신의 첫 바깥쪽 루프가 된다.

코스의 처음으로: 루프 엔지니어링이란