GUIDE 02 빌드캠프 가이드
루프 엔지니어링이란 무엇인가
짧은 답
루프 엔지니어링은 사람이 매번 다시 프롬프트하는 대신, 에이전트가 만든 결과를 평가하고 그 피드백을 다음 실행에 되먹이는 구조를 설계하는 일입니다. 사람은 루프를 시작하는 트리거가 되고, 이후 지시·검증·개선은 에이전트가 이어 갑니다. 핵심은 실행 기록(trace)을 남기고 판정(judge)해서 스스로 개선되게 만드는 것입니다.
프롬프트, 하네스, 그리고 루프
코딩 에이전트를 잘 쓰는 사람들의 관심은 "더 좋은 프롬프트"에서 "에이전트에게 다시 지시하고 평가하고 고치는 구조"로 옮겨 가고 있습니다. 세 단계를 나란히 놓으면 차이가 분명합니다.
| 단계 | 설계하는 것 | 사람의 역할 | 품질이 오르는 방식 |
|---|---|---|---|
| 프롬프트 엔지니어링 | 한 번의 지시문 | 매 턴마다 직접 지시 | 사람이 결과를 보고 다시 씀 |
| 하네스 엔지니어링 | 한 번의 실행을 위한 컨텍스트 · 도구 · 제약 | 실행을 준비하고 결과를 검수 | 사람이 붙어서 손으로 반복 |
| 루프 엔지니어링 | 생성 → 평가 → 개선이 이어지는 고리 | 루프를 시작하는 트리거, 필요한 지점의 게이트 | 평가 결과가 다음 실행에 자동으로 들어감 |
하네스의 한계는 분명합니다. one-shot 품질은 결국 사람이 계속 붙어 있어야 올라갑니다. 사람이 손으로 돌리던 그 고리를 에이전트에게 넘기는 것이 루프 엔지니어링입니다.
루프를 이루는 다섯 노드
이재규 강사는 루프를 다섯 개의 노드로 설명합니다. 이 다섯 가지가 계속 돌면 자기 개선이 일어납니다.
- run (실행): 에이전트가 작업을 합니다.
- trace (기록): 추론, 툴콜, 출력을 모두 남깁니다. 루프의 연료입니다. 측정해야 개선할 수 있습니다.
- judge (판정): 좋은 행동이었는지, 제대로 풀었는지 평가합니다. 답만 맞았는지가 아니라 어떻게 풀었는지를 봅니다.
- edit (수정): "툴콜 세 번을 한 번으로 줄일 수 있겠다"처럼 스킬이나 절차를 고칩니다.
- gate (게이트): 바뀐 것을 통과시킬지 정합니다. 사람이 검수하는 자리도 여기입니다.
judge: 결정론적 검증과 LLM 판정
루프마다 다른 것은 대부분 judge입니다. 검증 방식은 크게 두 갈래입니다.
- 결정론적 검증: 테스트 코드나 규칙처럼 통과 여부가 확정되는 게이트입니다. 기준이 명확하면 사람이 믿고 위임할 수 있습니다.
- LLM judge: 다른 모델이 기록을 읽고 판정합니다. 어디에나 쓸 수 있지만 남용하면 스킬이 비대해지고 비용이 커집니다.
검증 대상도 결과(outcome)만 볼지, 툴콜 같은 행동까지 볼지, 추론 과정까지 볼지로 나뉩니다. 실무에서는 테스트 코드, 절차를 담은 프롬프트, 다른 에이전트를 쓰는 LLM judge를 섞어서 검증 기준을 세웁니다.
Ouroboros로 보는 실제 흐름
Ouroboros는 이재규 강사가 만든 오픈소스 루프 도구로, 막연한 목표를 닫힌 루프로 바꾸는 명령을 제공합니다.
| 명령 | 하는 일 |
|---|---|
ooo interview | 질문을 주고받으며 모호도를 낮추고 완료 기준을 합의합니다. 모호도가 충분히 낮아져야 다음으로 넘어갑니다. |
ooo seed | 합의한 내용을 바꾸지 않을 스펙과 acceptance criteria로 고정합니다. |
ooo run | 작업을 분해해 병렬로 실행하고 결과를 한 곳으로 모읍니다. |
ooo evaluate | 기계적 검증, 의미 검증, 합의 검증의 3단계로 결과를 평가합니다. |
ooo evolve | 평가 결과를 다음 세대의 입력으로 넣어 개선합니다. 루프를 실제로 닫는 단계입니다. |
좋은 루프와 헛도는 루프
루프라고 다 좋은 것은 아닙니다. 메모리 없이 매일 같은 보고만 반복하는 에이전트는 도움보다 노이즈가 됩니다. 좋은 루프는 검증이 제자리에 있고, 그 결과로 스스로 개선되며, 언제 멈출지가 정해져 있습니다. 이 셋이 없으면 토큰만 쓰고 제자리를 도는 루프가 됩니다.
어디부터 해볼까
빌드캠프 5기에서는 쉬운 것부터 어려운 순서로 세 가지 산출물 루프를 실습했습니다.
- 보고서 루프: 병렬 검색과 요약 → 사실 오류·누락·근거 부족 평가 → 보강 후 재제출
- 발표자료 루프: 보고서를 메시지와 장표 구조로 압축 → 톤·구조 일관성 평가 → 청중별 버전
- 도구 제작 루프: 아이디어를 기능 목록과 완료 기준으로 → 만들고 써 보고 평가 → 새 아이디어에 같은 루프 재적용
자주 묻는 질문
루프 엔지니어링과 하네스 엔지니어링은 어떻게 다른가요?
하네스 엔지니어링은 한 번의 실행을 잘 되게 하는 컨텍스트·도구·제약을 설계합니다. 루프 엔지니어링은 그 실행 결과를 평가해 다음 실행에 되먹이는 고리 전체를 설계해서, 사람이 붙어 있지 않아도 품질이 오르게 만듭니다.
Ouroboros는 무엇인가요?
빌드캠프 5기 이재규 강사가 만든 오픈소스 루프 도구입니다. interview, seed, run, evaluate, evolve 명령으로 막연한 목표를 스펙으로 바꾸고, 실행과 평가와 개선을 한 사이클로 잇습니다.
LLM judge만으로 평가하면 안 되나요?
가능하지만 비용이 커지고 스킬이 비대해지기 쉽습니다. 테스트 코드나 규칙처럼 결정론적으로 확인할 수 있는 부분은 결정론적 게이트로 두고, 판단이 필요한 부분에만 LLM judge를 쓰는 것이 좋습니다.
개발자만 배울 수 있나요?
아니요. 빌드캠프 5기는 기획자·운영자, 콘텐츠·교육·연구 실무자까지 대상으로 보고서, 발표자료, 작은 도구를 루프로 만드는 실습을 진행했습니다. 터미널 환경과 AI 도구 계정 하나가 필요합니다.
지난 기수 · 2026.07 · 온라인 5강
빌드캠프 5기 — 모두를 위한 루프 엔지니어링
강사 이재규(ZEP 테크 리드, Ouroboros 제작자). 기수 소개와 커리큘럼을 그대로 볼 수 있습니다.