최근 며칠간, Claude Code를 사용하여 교육 콘텐츠를 자동 생성하는 Loop를 설계하면서 한 가지 결론에 도달했습니다.

지금까지 생성형 AI에서는

• Prompt Engineering (프롬프트 엔지니어링)
• Context Engineering (컨텍스트 엔지니어링)

이 중요하다고 말해왔습니다.

물론 지금도 중요합니다.

하지만, AI 에이전트를 몇 번이고 다시 만들면서 깨달은 것은,

정말로 어려운 것은 "AI에게 무엇을 지시할 것인가"가 아니라, "AI를 어떻게 계속 움직이게 할 것인가"였습니다.

저는 이것을 **Loop Engineering (루프 엔지니어링)**이라고 부르고 있습니다.

처음에는 저도

PDF
↓
교재 생성

만으로도 충분하다고 생각했습니다.

그 후,

PDF
↓
Lesson AI
...

라는 흐름으로 진화했습니다.

하지만 이래도 품질은 안정되지 않습니다.

다음에 생각한 것은

Lesson AI
↓
Judge AI
...

라는 구성입니다.

그런데 실제로 설계해 보니 새로운 문제가 보였습니다.

아직 개선할 수 있습니다
↓
개선했습니다
...

……

언제 끝나는 걸까요?

Loop는 내버려 두면 멈추지 않습니다.

여기서 처음으로 깨달은 것은,

Prompt (프롬프트)보다 중요한 것은

종료 조건 (Stop Condition)

이라는 것이었습니다.

예를 들어

• Retry (재시도)는 최대 5회까지
• 품질 점수 90점 이상이면 종료
• 개선율이 2% 미만이면 종료
• API 비용이 상한을 초과하면 종료

등입니다.

Loop Engineering이란,

"AI를 개선하는 메커니즘"이 아니라,

"개선을 어디서 멈출지를 설계하는 기술"

이기도 합니다.

여기에 또 하나의 벽이 있었습니다.

Judge AI 자신도 LLM입니다.

즉,

어제 90점이었던 답변이

오늘 85점이 될 수도 있습니다.

LLM에게만 품질 보증을 맡기는 것은 위험합니다.

그래서 현재는,

LLM에 의한 평가뿐만 아니라,

• JSON Schema Validation (JSON 스키마 검증)
• 필수 항목 체크
• Markdown 구조
• 글자 수
• 링크 끊김
• 파일 생성 확인

등,

결정론적인 체크 (Deterministic Check)

를 조합하는 구성을 생각하고 있습니다.

LLM Judge
│
▼
...

처음에는

Lesson
↓
Quiz
...

라는 Workflow (워크플로우)를 작성하고 있었습니다.

하지만 지금 생각하고 있는 Loop에서는,

State (상태)가 중심이 됩니다.

예를 들어

{
"lesson": 3,
"retry_count": 2,
...

이 State를 보고,

다음에

• Improve (개선)할 것인가
• Human Review (사람의 검토)로 보낼 것인가
• 강제 종료할 것인가

를 판단합니다.

Workflow는 "선"입니다.

Loop는 "상태 전이를 가진 그래프"입니다.

이 차이는 매우 크다고 느끼고 있습니다.

Claude Code 덕분에,

이 Loop를 놀라울 정도로 빠르게 시행착오를 겪으며 테스트할 수 있었습니다.

한편으로,

운영 환경을 생각하면,

Claude Code 자체가 Loop Runtime (루프 런타임)이 되는 것은 아닙니다.

장래에는,

• LangGraph
• Python을 이용한 독자적인 Runtime
• State Machine (상태 머신)

등으로 이행하게 될 것입니다.

Claude Code는,

Loop를 발명하기 위한 최고의 개발 환경이었습니다.

Loop를 몇 번 돌리는 정도라면 문제없습니다.

하지만 수백 번, 수천 번 돌리게 되면,

다른 문제가 발생합니다.

"지금 어디에서 멈춰 있는가"

를 알 수 없게 되는 것입니다.

그렇기 때문에,

앞으로는

• State의 시각화
• Retry 이력
• Token 소비
• Judge 점수의 추이
• 에러 이유

등을 감시하는

Observability (가관측성)

도 중요해질 것이라고 생각합니다.

처음에는

Prompt Engineering의 연장선상에 있다고 생각했습니다.

하지만 지금은 다릅니다.

Loop Engineering은,

Prompt를 쓰는 기술이 아닙니다.

State

Retry

Evaluation (평가)

Stop Condition (종료 조건)

Observability (가관측성)

Human in the Loop (인간 참여형 루프)

이것들을 설계하는,

소프트웨어 아키텍처 그 자체라고 생각합니다.

AI 에이전트가 당연해지는 앞으로는,

Prompt를 쓰는 능력보다,

Loop를 설계하는 능력이 더 중요해질지도 모릅니다.

현재 저는,

PDF를 업로드하면

• 교재
• 퀴즈
• 영상 대본
• 워크시트

까지 자동으로 생성하는 교육용 Loop Runtime을 시제품으로 제작하고 있습니다.

아직 시행착오를 겪는 단계이지만, 이 과정에서 얻은 지견을 앞으로도 Qiita를 통해 공유해 나가고자 합니다.

여러분은 AI 에이전트의 "종료 조건 (Termination Condition)"이나 "상태 관리 (State Management)"를 어떻게 설계하고 계신가요?