JYP Garden Internal

프롬프트보다 중요한 것은 반복 가능한 에이전트 루프 설계

Properties1
tagslinkedin, jyp-labs, agentic-ai, loop-engineering, ai-work-os

11 min read

프롬프트보다 중요한 것은 반복 가능한 에이전트 루프 설계 — Sanguine Kim

Key Insight

AI 에이전트의 성과 병목은 프롬프트 자체보다 Discovery → Planning → Execution → Verification → Iteration이 닫히는 반복 구조와, 이를 지탱하는 운영 문서·검증 게이트 설계에 있다.

출처: LinkedIn / Sanguine Kim
타입: SNS 포스트
공유 맥락: 정영필 대표님 ingest 요청 / repost 여부 확인 필요
유효일: 2026-06-19
Raw: 2026-06-19-https-www-linkedin-com-posts-sanguinekim-aiagents-loopengineering-agenticai-shar

핵심 Takeaway

  • 에이전트가 일을 못하는 이유를 “프롬프트가 부족해서”로 해석하는 것이 흔한 착각이며, 일정 수준 이후 진짜 병목은 반복 구조 부재라고 주장한다.
  • Loop Engineering은 사람이 매번 지시하는 대신, 에이전트가 스스로 작업을 발견하고 계획·실행·검증·재시도하도록 루프를 설계하는 접근으로 설명된다.
  • Agent Loop의 핵심 5단계는 Discovery, Planning, Execution, Verification, Iteration이다.
  • 운영 문서로 AGENTS.md, customer.md, PRD.md, progress.md를 분리해 맥락·판단·진행상태를 누적해야 에이전트가 매번 새로 시작하지 않는다고 본다.
  • 좋은 루프의 구성 블록으로 Automations, Worktrees, Skills, MCP/Connectors, Sub-agents, Memory를 제시한다.
  • Agent output이 바로 ship으로 가면 위험하므로 Tests, Type Check, 보안 체크, Eval, 사람 승인이 포함된 Quality Gate가 반드시 필요하다고 강조한다.
  • 앞으로 중요한 역량은 “좋은 프롬프트 작성”보다 “에이전트가 반복 가능하게 일하고 실패를 학습하며 검증을 통과하도록 운영 설계하는 능력”이라는 관점이다.

상세 요약

1) 프롬프트 최적화보다 루프 설계가 병목이다

포스트는 프롬프트 품질이 중요하다는 점은 인정하면서도, 일정 수준을 넘으면 생산성 차이는 프롬프트 문구가 아니라 반복 구조 설계에서 난다고 본다. 즉, 한 번 잘 시키는 문제보다 다음번에도 같은 유형의 일을 스스로 더 잘 수행하도록 루프를 닫는 것이 핵심이라는 주장이다.

2) Agent Loop는 5단계 운영 구조다

Discovery에서 필요한 맥락과 파일을 찾고, Planning에서 작업과 성공 기준을 쪼개며, Execution에서 실제 산출을 만들고, Verification에서 테스트·타입체크·Eval·보안검사를 수행한 뒤, Iteration에서 실패 원인을 반영해 다시 고친다. 이 구조는 JYP Labs의 작은 closed loop 설계와 거의 같은 골격이다.

3) 루프는 프롬프트 안이 아니라 파일과 운영 구조 안에 있다

저자는 Rules만으로는 부족하고, 에이전트가 참조해야 할 문서를 역할별로 분리해야 한다고 본다. AGENTS.md는 운영 원칙과 가드레일, customer.md는 고객 문제, PRD.md는 목표·범위·성공 기준, progress.md는 현재 상태와 다음 액션을 담당한다.

4) 좋은 루프는 도구 블록과 검증 게이트를 함께 요구한다

Automations·Worktrees·Skills·MCP/Connectors·Sub-agents·Memory가 루프의 운영 블록이라면, Tests·Type Check·보안 체크·Eval·사람 승인은 루프가 오작동하거나 위험한 결과를 바로 배포하지 못하게 막는 Quality Gate다. 따라서 실행 구조와 검증 구조를 함께 설계해야 한다.

5) AI 리더십의 초점이 운영 설계 능력으로 이동한다

포스트의 결론은 생산성이 한 번의 멋진 답변이 아니라 잘 설계된 루프에서 나온다는 것이다. 이는 JYP Labs 관점에서 스킬·표준·승인 경계·증거 패키지까지 포함한 AI Work OS 설계 능력을 교육/컨설팅 자산으로 전환할 수 있음을 시사한다.

JYP Labs 운영체계 시사점

A. 입력 인터페이스

  • LinkedIn/Slack/YouTube에서 들어오는 AI/AX 신호를 단순 뉴스가 아니라 “운영 표준 보강 후보”로 수집하는 흐름이 유효하다.

B. 계획/작업 분해

  • JYP Labs Loop Engineering 표준의 기본 루프를 Discovery → Planning → Execution → Verification → Iteration 관점으로 더 간결하게 설명하는 외부 사례로 활용할 수 있다.
  • 작업 계약(prompt보다 contract)과 진행 상태 문서(progress.md)를 한 세트로 보는 설명은 JYP Labs project/log/standard 분리 원칙과 잘 맞는다.

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

  • Worktrees·Sub-agents·Skills를 별도 블록으로 보는 시각은 Hermes subagent, Codex 보조검토, OMW 문서화의 역할 분리를 정당화한다.
  • 에이전트 운영 문서(AGENTS.md)와 고객/제품/진행 문서를 분리하면 병렬 실행 시 컨텍스트 충돌을 줄일 수 있다.

D. 지식 저장소/재사용

  • 성공한 루프는 OMW source/concept/standard와 Hermes skill로 승격하고, 실패/진행 상황은 progress.md 또는 OMW log로 누적하는 패턴이 재확인된다.
  • 문서 하네스(AGENTS.md, customer.md, PRD.md, progress.md)를 JYP Labs 표준 템플릿으로 정리할 필요가 있다.

E. 검증/승인/리스크

  • Tests·Type Check·보안 체크·Eval·사람 승인을 Quality Gate로 명시한 점은 JYP Labs의 비가역 작업 승인 경계와 Evidence Package 기준을 외부 사례로 보강한다.
  • repost 여부와 공개 페이지 외 숨겨진 수정 이력은 raw fetch만으로 확정할 수 없어 확인 필요로 둔다.

후보 분류

스킬 후보

  • Skill name candidate: loop-engineering-workflow-design
  • Trigger phrase: “이 업무를 loop로 설계해”, “AGENTS/customer/PRD/progress 문서 구조까지 잡아줘”
  • Inputs: 업무 목표, 사용자/고객 맥락, 범위/비범위, 현재 진행 상태, 검증 기준, 승인 필요 여부
  • Steps: Discovery → Planning → Execution → Verification → Iteration + 문서 하네스 구성 → Evidence Package 정리 → 기록/스킬화
  • Verification: 산출물 경로·테스트 결과·확인 필요 항목·승인 경계가 명시됐는지 확인
  • Human approval boundary: 외부 발송·배포·삭제·권한 변경 전 승인 필수

강의 후보

  • Module title: 프롬프트보다 루프: AI 에이전트 운영 설계의 핵심
  • Audience: 기업 임원, PM, AX 리더, 개발 리더
  • Hook: “좋은 프롬프트보다 중요한 것은 에이전트가 반복 가능하게 일하도록 만드는 운영 구조다.”
  • 3 teaching points:
    1. 프롬프트 병목과 루프 병목의 차이
    2. AGENTS/customer/PRD/progress 문서 하네스의 역할 분담
    3. Quality Gate 없는 agent output이 왜 위험한가
  • Exercise/demo idea: 동일한 업무를 단일 프롬프트 방식과 문서 하네스+검증 게이트 방식으로 비교해 산출물 품질과 재현성 차이를 점검

자동화 후보

  • Trigger: LinkedIn/YouTube/메일에서 loop engineering, agent workflow, quality gate 관련 신호 수집
  • Input source: SNS 포스트 원문, OMW source note, 기존 표준/프로젝트 문서
  • Output artifact: source note, 관련 standard 보강, skill/lecture/automation 후보, 운영체계 반영 메모
  • Destination: OMW wiki/sources/, wiki/work/standards/, Hermes 브리핑
  • Approval boundary: 표준 개정·외부 공유·자동 게시 전 사람 승인
  • Failure mode: 공개 페이지 로그인 장벽, 문서 하네스 과설계, 검증 게이트 누락, agent output 직행 배포

연결되는 노트

확인 필요

  • LinkedIn 공개 페이지 기준 repost 여부와 원 게시 편집 전후 차이는 확인되지 않았다.
  • Bright Data 구조화 결과의 canonical URL은 activity 링크로 정규화됐고, 사용자가 전달한 원본은 share 링크였다.

그래프 뷰

백링크