루프 엔지니어링 마스터하기: 스스로 개선하는 AI 에이전트 구축

수동 프롬프트에서 엔지니어링된 루프로

대부분의 사람들은 여전히 AI 에이전트를 수동으로 조작합니다

하나의 작업을 입력하고

하나의 응답을 기다리고

결과를 직접 검토하고

실수를 직접 수정하고

다시 프롬프트를 보냅니다

인간이 여전히 루프를 돌리고 있는 겁니다

다음 단계는 다릅니다

에이전트에게 단계별로 프롬프트를 보내는 것을 멈춥니다

그 주변에 루프를 구축합니다

루프가 지침을 주고

출력을 확인하고

다음 행동을 선택하고

결과가 기준에 도달할 때까지 계속 실행합니다

이것이 루프 엔지니어링입니다

아이디어는 간단합니다

에이전트를 수동으로 프롬프트하는 데 시간을 쓰지 마세요

대신 에이전트를 대신해 프롬프트하는 시스템을 설계하세요

"더 이상 코딩 에이전트를 프롬프트해서는 안 됩니다. 에이전트를 프롬프트하는 루프를 설계해야 합니다."

Boris Cherny는 Anthropic에서 Claude Code를 이끌고 있습니다

그는 자신의 작업 흐름을 통해 동일한 변화를 설명했습니다:

"저는 더 이상 Claude에게 프롬프트를 보내지 않습니다. Claude를 프롬프트하고 무엇을 할지 결정하는 루프가 실행되고 있습니다. 제 역할은 루프를 작성하는 것입니다."

왜 대부분의 사람들은 여전히 실제 루프를 구축하지 않는가

루프는 토큰 비용을 확인하기 전까지는 엄청나게 좋아 보입니다

일반적인 에이전트 루프는 컨텍스트를 매우 빠르게 소모할 수 있습니다:

중간 규모의 코딩 루프는 50K-200K 토큰을 사용할 수 있습니다
오케스트레이터와 전문가로 구성된 플릿은 500K-2M 토큰을 사용할 수 있습니다
매일 실행되도록 예약된 루프는 매주 수백만 개의 토큰을 소모할 수 있습니다

모든 재시도에 토큰이 소모됩니다

모든 수정에 토큰이 소모됩니다

모든 검증 단계에 토큰이 소모됩니다

모든 하위 에이전트가 또 다른 비용을 추가합니다

이것이 사람들이 거의 논의하지 않는 숨겨진 한계입니다

루프 엔지니어링이 어려운 이유는 개념을 이해하기 어렵기 때문이 아닙니다

대부분의 사용자가 무제한 에이전트 실행을 감당할 수 없기 때문입니다

당연한 반응은:

"당신이 말하기는 쉽죠, 당신은 무제한 OpenAI 액세스 권한이 있잖아요"

그리고 그 비판은 타당합니다

이것이 바로 저렴한 모델과 큰 컨텍스트 윈도우가 중요한 이유입니다

매일 유용한 루프를 실행하려면 다음이 필요합니다:

저렴한 입력 토큰
저렴한 출력 토큰
큰 컨텍스트 윈도우
신뢰할 수 있는 도구 호출
구조화된 JSON 출력
높은 동시성
이전 단계를 기억할 수 있는 충분한 컨텍스트

이러한 것들이 없으면 루프는 비싼 실험에 머뭅니다

이러한 것들이 있으면 루프는 실제 작업을 실행할 수 있는 실용적인 시스템이 됩니다

기존 워크플로우 vs 새로운 워크플로우

지난 2년 동안 대부분의 사람들은 에이전트를 이렇게 사용했습니다:

프롬프트를 보냅니다

에이전트가 응답합니다

답변을 검토합니다

문제를 발견합니다

다시 프롬프트를 보냅니다

작동은 하지만 확장되지 않습니다

기존 워크플로우:

프롬프트를 작성합니다
에이전트가 출력을 생성합니다
출력을 검사합니다
약한 부분을 수정합니다
수동으로 프로세스를 반복합니다

새로운 워크플로우:

결과를 정의합니다
루프가 필요한 것을 발견합니다
루프가 계획을 수립합니다
에이전트가 작업을 실행합니다
검사자가 결과를 평가합니다
루프가 실패를 수정합니다
목표가 완료되면 시스템이 중지됩니다

프롬프트는 에이전트에게 하나의 지시를 내립니다

루프는 에이전트에게 전체 작업을 부여합니다

루프 엔지니어링이 실제로 의미하는 것

루프 엔지니어링은 AI 에이전트 주변에 반복 가능한 피드백 사이클을 구축하는 것을 의미합니다

목표는 간단합니다:

초기 시도에서 검증된 결과로 이동하는 것입니다

인간이 모든 단계를 제어하지 않고도 말이죠

기본 루프는 5단계로 구성됩니다:

발견
계획
실행
검증
반복

결과가 검사를 통과하면 배포합니다

결과가 실패하면 루프로 돌려보냅니다

이것이 전체 개념입니다

완벽한 프롬프트 하나를 작성하려는 것이 아닙니다

시스템을 만드는 것입니다

불완전한 출력을 요구 사항에 맞을 때까지 개선하는 시스템입니다

단일 에이전트 루프

루프는 일반적으로 두 가지 크기로 제공됩니다

더 작은 버전은 하나의 에이전트가 전체 사이클을 완료합니다

무슨 일이 일어나야 하는지 발견하고

작업을 계획하고

작업을 수행하고

결과를 검토하고

무언가 실패하면 다시 시도합니다

한 사람이 자신의 초안을 준비될 때까지 편집하는 것과 유사합니다

단일 에이전트 루프는 다음에 적합합니다:

집중된 작업
제한된 범위
명확한 목표
콘텐츠 초안
버그 수정
연구 요약

하나의 에이전트

하나의 피드백 사이클

지속적인 자기 개선

플릿 루프

플릿 루프는 더 큰 규모로 작동합니다

하나의 오케스트레이터가 주요 목표를 받습니다

목표를 더 작은 조각으로 나눕니다

그 조각들은 전문 에이전트에게 할당됩니다

각 전문가는 더 좁은 작업을 더 작은 하위 에이전트에 위임할 수도 있습니다

예시:

text

1목표: 생산성 앱 구축
2
3오케스트레이터가 미션을 소유합니다
4        ↓              ↓              ↓
5    연구             엔지니어링        QA
6    전문가           전문가            전문가
7        ↓              ↓              ↓
8 웹 리서처       코드 작성자       테스트 작성자
9                  + 디버거          + 버그 트래커

이것은 더 이상 하나의 에이전트가 혼자 작업하는 것이 아닙니다

작은 자율 팀이 프로젝트를 처음부터 끝까지 실행하는 것에 더 가깝습니다

개방형 루프 vs 폐쇄형 루프

이것이 가장 중요한 실용적 차이입니다

모든 루프가 동일하게 작동하는 것은 아닙니다

개방형 루프

개방형 루프는 탐색적입니다

광범위한 목표를 제공하고 에이전트가 자신의 경로를 발견하도록 허용합니다

에이전트는 당신이 지정하지 않은 유용한 것들을 발견할 수 있습니다

하지만 비용이 많이 들고 혼란스러울 수도 있습니다

개방형 루프는 다음을 할 수 있습니다:

너무 많은 방향을 탐색
많은 양의 토큰 낭비
빠른 속도로 저품질 작업 생성
실제 목표에서 벗어남
제어하기 어려워짐

개방형 루프는 흥미롭습니다

하지만 일반적으로 최고의 시작점은 아닙니다

폐쇄형 루프

폐쇄형 루프는 명확한 경계를 가지고 있습니다

인간이 먼저 경로를 정의합니다

루프는 여전히 독립적으로 작동하지만 명시적 규칙 내에 머뭅니다

폐쇄형 루프에는 다음이 포함됩니다:

명확한 목표
정의된 단계
각 단계 후 평가
중지 조건
시스템이 막히면 인간에게 인계

이것이 오늘날 가치를 창출하는 버전입니다

비용이 적게 듭니다

신뢰하기 쉽습니다

더 깔끔한 결과를 생성합니다

폐쇄형 루프로 시작하세요

검사가 충분히 강력해진 후에만 더 개방형으로 만드세요

효과적인 루프의 6가지 구성 요소

모든 루프는 개념적으로 동일한 5단계 사이클을 따릅니다

실제로는 6가지 구성 요소가 그 사이클을 유용하게 만듭니다

1 자동화

자동화는 루프의 심장입니다

수동으로 시작할 필요 없이 프로세스를 시작합니다

예시:

매일 아침 실행
PR이 열릴 때마다 실행
파일이 변경된 후 실행
새 티켓이 나타날 때 실행
모든 테스트가 통과할 때까지 계속

여전히 모든 작업을 직접 시작한다면 루프가 충분히 작동하지 않는 것입니다

2 워크트리

워크트리는 여러 에이전트가 동시에 코드를 편집할 때 중요해집니다

격리 없이는 에이전트가 충돌합니다

두 에이전트가 같은 파일을 변경할 수 있습니다

한 에이전트가 다른 에이전트의 작업을 덮어쓸 수 있습니다

워크트리는 각 에이전트에게 별도의 작업 공간과 브랜치를 제공합니다

이를 통해 여러 에이전트가 병렬로 작업할 수 있습니다

리포지토리를 엉망으로 만들지 않고도 말이죠

3 스킬

스킬은 프로젝트에 대한 재사용 가능한 지식을 저장합니다

매 실행마다 동일한 컨텍스트를 설명하는 것을 중단하세요

중요한 정보를 한 번 작성하세요

모든 미래의 루프가 그것을 재사용하도록 하세요

유용한 스킬 파일에는 다음이 포함될 수 있습니다:

제품 비전
아키텍처
프로젝트 규칙
빌드 지침
테스트 지침
에이전트가 절대 해서는 안 되는 작업

스킬이 없으면 모든 루프가 콜드 스타트에서 시작합니다

스킬이 있으면 모든 실행이 이전 작업에서 축적된 지식으로 시작합니다

4 플러그인 및 커넥터

로컬 파일만 읽을 수 있는 루프는 제한된 가치를 가집니다

커넥터는 실제 작업이 이루어지는 도구와 상호 작용할 수 있게 해줍니다

예시:

GitHub
Slack
Linear
Jira
Gmail
Google Drive
데이터베이스
스테이징 API

이것이 다음의 차이입니다:

"여기 가능한 수정 사항이 있습니다"

그리고:

"PR을 열고 티켓에 연결했습니다"

"그런 다음 CI를 모니터링하고 최종 업데이트를 게시했습니다"

5 하위 에이전트

제작자와 검사자가 항상 동일한 에이전트여서는 안 됩니다

코드를 작성한 에이전트는 검토할 때 너그러울 수 있습니다

기사를 초안 작성한 에이전트는 동일한 약한 부분을 두 번 간과할 수 있습니다

다음에 대해 별도의 에이전트를 사용하세요:

탐색
구현
검토
테스트
사실 확인
최종 요약

검토자가 독립적일 때 품질이 향상됩니다

창작자가 유일하게 작업을 확인하는 사람이 되어서는 안 됩니다

6 메모리

메모리는 루프가 여러 실행에 걸쳐 계속될 수 있게 해줍니다

모델은 잊어버립니다

리포지토리는 잊지 않습니다

노트는 잊지 않습니다

프로젝트 로그는 잊지 않습니다

메모리는 다음에 저장될 수 있습니다:

Markdown 파일
프로젝트 로그
Linear 티켓
GitHub 이슈
Obsidian 볼트
데이터베이스
Claude Projects

장기 실행 루프는 이미 시도한 것을 기억해야 합니다

무엇이 작동했는지

무엇이 실패했는지

그리고 여전히 완료해야 할 것이 무엇인지

지속적인 메모리 없이 루프는 매번 제로에서 시작합니다

루프의 실제 예시

이러한 워크플로우가 개념을 구체화합니다

코딩 루프

text

1VISION.md + ARCHITECTURE.md 읽기
2↓
3다음 변경 사항 계획
4↓
5코드 편집
6↓
7테스트 실행
8↓
9테스트 실패 시 → 오류 검사 → 수정 → 다시 테스트
10↓
11테스트 통과 시 → 변경 사항 요약
12↓
13중지

인간이 모든 단계를 주도할 필요는 없습니다

에이전트가 자신의 작업을 작성, 테스트, 수정 및 검증합니다

연구 루프

text

1연구 질문 정의
2↓
3관련 출처 찾기
4↓
5증거 요약
6↓
7출처에 대한 모든 주장 검증
8↓
9상충되는 정보 비교
10↓
11최종 종합 생성
12↓
13신뢰도 임계값에 도달하면 중지

이것은 하나의 빠른 요약을 요청하는 것보다 훨씬 강력한 결과를 생성합니다

콘텐츠 루프

text

1주제 + 대상 + 목표 정의
2↓
3첫 번째 초안 작성
4↓
5비평 에이전트에게 보내기
6↓
7비평을 사용하여 다시 작성
8↓
9성공 기준에 따라 점수 매기기
10↓
11통과 시 → 게시
12↓
13실패 시 → 다시 작성

루프는 하나의 아이디어를 반복 가능한 콘텐츠 시스템으로 전환합니다

영업 아웃리치 루프

text

1ICP 정의
2↓
3프로필에 맞는 리드 찾기
4↓
5각 리드에 회사 데이터로 보강
6↓
7기준에 따라 자격 평가
8↓
9메시지 개인화
10↓
11품질 검토 실행
12↓
13인간에게 보내거나 에스컬레이션

모든 예시는 동일한 뼈대를 사용합니다:

목표

행동

확인

수정

작업이 완료될 때까지 반복

프롬프트 엔지니어 vs 루프 엔지니어

이것이 2026년에 열리는 새로운 기술 격차입니다

프롬프트 엔지니어

프롬프트 엔지니어는 더 나은 지침에 집중합니다

문구를 개선합니다

더 강력한 단일 응답을 생성합니다

하지만 에이전트가 완료된 후에도 인간이 모든 것을 검토해야 합니다

인간은 여전히 피드백 루프로 남아 있습니다