Loop engineering은 에이전트를 프롬프트하는 시스템을 설계하는 것 — Jeongmin Lee

Key Insight

AI 코딩/업무 에이전트의 생산성은 단일 프롬프트가 아니라 태스크 발견 → 분배 → 실행 → 검증 → 다음 태스크 결정이 자동 순환하는 loop 설계 역량에서 나온다.

출처: LinkedIn / Jeongmin Lee 타입: SNS 포스트 공유 맥락: 정영필 대표님 ingest 요청 / repost 여부 확인 필요 유효일: 2026-06-09 Raw: 2026-06-09-https-www-linkedin-com-feed-update-urn-li-activity-7469915687986098177

핵심 Takeaway

  • Boris Cherny(Claude Code)와 Peter Steinberger(OpenClaw)의 발언을 인용하며, 앞으로의 핵심은 “에이전트에게 직접 프롬프트하기”보다 “에이전트를 프롬프트하는 루프를 설계하기”라고 설명한다.
  • Loop engineering은 사람이 반복 프롬프트를 넣는 병목을 줄이고, 태스크 발견·분배·실행·검증·다음 결정이 자동으로 도는 구조를 만드는 접근이다.
  • Addy Osmani의 5개 building block으로 Automation, worktree, skill, connector, subagent가 언급된다.
  • RLM(Recursive Language Model)은 전체 컨텍스트를 한 번에 넣는 방식이 아니라, REPL의 context 변수에서 필요한 부분만 읽고 출력도 scaffold 단계에서 잘라 컨텍스트 낭비를 줄이는 구조로 설명된다.
  • Subagent 결과가 상위 context 전체로 붙는 것이 아니라 REPL 내 Python 변수처럼 돌아오면, 상위 에이전트는 검증 후 최종 반환만 하면 되므로 토큰 재생성과 출력 길이 병목이 줄어든다.
  • Claude Code dynamic workflow는 JavaScript로 subagent를 생성·조율하고, 각 subagent가 독립 context에서 작업한 뒤 결과만 상위로 올리는 구조로 소개된다.
  • 활용 패턴은 fan-out-and-synthesize, adversarial verification, tournament 등이며, 개발뿐 아니라 리서치 검증·서포트 티켓 분류 같은 비개발 업무에도 적용 가능하다.

상세 요약

1) 프롬프트 작성에서 루프 설계로 이동

포스트의 중심 문장은 “나는 더 이상 Claude에 프롬프트를 치지 않는다. 내 일은 loop를 짜는 것이다”이다. 단일 프롬프트 품질보다 작업이 반복·분기·검증되는 구조가 더 중요해졌다는 문제의식이다.

2) RLM은 컨텍스트 운영 방식의 대안

RLM은 필요한 부분만 읽고 불필요한 print/output이 context window를 채우지 않도록 하여, 장시간·다단계 작업에서 목표 이탈과 컨텍스트 오염을 줄이는 방식으로 설명된다.

3) Subagent는 “본문 전체”가 아니라 “검증 가능한 결과 변수”를 반환해야 한다

상위 에이전트가 하위 에이전트의 전체 reasoning/context를 떠안는 구조는 토큰 비용과 품질 저하를 만든다. 결과를 변수처럼 받고 검증만 하는 구조가 loop engineering의 핵심 설계 포인트다.

4) Dynamic workflow는 loop engineering의 구현 방향

Claude Code dynamic workflow는 subagent의 독립 context, 상위 조율, 결과 합성이라는 패턴을 통해 agentic laziness, self-preferential bias, goal drift를 구조적으로 줄이려는 방향으로 해석된다.

5) 비용은 아직 부담이지만 기본값이 될 가능성

현재 dynamic workflow는 토큰을 많이 쓰며, 일반 작업에 verifier를 과도하게 붙일 필요는 없다. 다만 모델 비용 하락과 KV cache hit 개선이 진행되면 loop 기반 작업이 기본값이 될 가능성이 높다.

JYP Labs 운영체계 시사점

A. 입력 인터페이스

  • Slack/LinkedIn/YouTube/메일에서 들어온 AI/AX 신호를 단순 요약하지 않고 “loop 후보”로 분류해야 한다.

B. 계획/작업 분해

  • 단일 요청 처리보다 task discovery → worker assignment → execution → verification → next decision 템플릿을 표준 작업 분해법으로 삼을 수 있다.

C. 병렬 실행/에이전트 운영

  • Codex/Claude Code/Hermes subagent를 fan-out-and-synthesize, adversarial verification, tournament 패턴으로 선택적으로 운영한다.
  • 모든 작업에 다중 verifier를 붙이지 않고, 위험도·비용·재사용성 기준으로 verifier 수를 결정한다.

D. 지식 저장소/재사용

  • 성공한 loop는 OMW source/concept/project와 Hermes skill로 승격한다.
  • subagent 결과는 장문 context 덤프가 아니라 요약 변수/검증 항목/산출물 경로 중심으로 저장한다.

E. 검증/승인/리스크

  • 외부 발송·삭제·결제·게시 같은 비가역 작업은 loop 자동화 안에서도 인간 승인 경계를 유지한다.
  • LinkedIn 공개 fetch 기준으로 포스트의 ❼ 항목은 본문에서 확인되지 않아 확인 필요로 둔다.

후보 분류

스킬 후보

  • Skill name candidate: loop-engineering-workflow-design
  • Trigger phrase: “이 업무 loop로 설계해”, “subagent workflow로 쪼개줘”
  • Inputs: 목표, 작업 범위, 위험도, 산출물 형식, 검증 기준, 승인 필요 여부
  • Steps: 태스크 발견 → 병렬/순차 분배 → 실행자 선택 → 검증자 배치 → 결과 합성 → 다음 태스크 결정 → 기록/스킬화
  • Verification: 각 subagent 산출물의 파일/URL/테스트/근거를 상위 에이전트가 재확인
  • Human approval boundary: 외부 전송·삭제·배포·결제·권한 변경 전 승인 필수

강의 후보

  • Module title: 프롬프트 엔지니어링 다음 단계: Loop Engineering
  • Audience: 기업 임원, PM, 개발 리더, AX 담당자
  • Hook: “AI에게 똑똑한 질문을 하는 시대에서, AI가 계속 일하게 만드는 루프를 설계하는 시대로 넘어간다.”
  • 3 teaching points:
    1. 단일 프롬프트의 한계와 반복 루프의 필요성
    2. subagent·검증자·worktree·skill의 역할 분리
    3. 자동화 루프에서 인간 승인과 검증 경계를 설계하는 법
  • Exercise/demo idea: 같은 요구사항을 단일 프롬프트 방식과 fan-out-and-synthesize 방식으로 처리해 결과 품질·비용·검증 부담 비교

자동화 후보

  • Trigger: Slack/OMW에 “loop로 설계” 요청 또는 고위험/다단계 작업 감지
  • Input source: Slack 요청, OMW source note, GitHub issue/PR, Gmail/Tasks
  • Output artifact: loop 설계안, worker 태스크 목록, verifier 체크리스트, 최종 브리핑
  • Destination: OMW wiki/work/projects/ 또는 Hermes thread 답변
  • Approval boundary: 실행 계획 승인 후 쓰기/배포 단계 진행
  • Failure mode: 과도한 subagent 수로 비용 증가, verifier 간 충돌, 결과 합성 누락, 공개 페이지 fetch 누락

연결되는 노트

확인 필요

  • 공개 fetch 본문에는 ❶~❻만 확인되며, 포스트가 “7가지”라고 언급한 ❼ 항목은 로그인/페이지 제한으로 누락되었을 가능성이 있다.
  • 정영필 대표님 repost 여부는 LinkedIn 공개 페이지 raw만으로는 확인되지 않았다.