JYP Labs Loop Engineering 표준안 v0.1

핵심 메시지: AI 경쟁력은 “한 번 잘 묻는 프롬프트”가 아니라 태스크 발견 → 분배 → 실행 → 검증 → 다음 결정이 반복되는 업무 루프를 설계하고 운영하는 능력에서 나온다.

0. 운영 표준 체계 내 역할

항목	내용
계층	L3 루프 설계 표준
상위 기준	jyp-labs-operating-system-v0.1, sophie-reliable-workflow-operating-standard-v0.1, jyp-labs-operating-standards-map-v0.1
책임	Discovery→Decompose→Dispatch→Execute→Verify→Synthesize→Decide→Skillize 반복 개선 루프 설계 기준
연결되는 하위 산출물	omw-top3-evaluation-checklist-v0.2, ai-tool-validation-loop-v0.1, vibe-coding-mvp-sop-v0.1
충돌 시 원칙	루프 단계·검증 레벨은 본 문서를 우선하고, 도메인별 세부 판정은 해당 L4 SOP를 따른다.

1. 목적

이 문서는 JYP Labs가 AI/AX 컨설팅, 강의 제작, 내부 자동화, OMW/Hermes 운영에서 공통으로 사용할 Loop Engineering 표준이다.

목적은 세 가지다.

1. 반복 업무를 AI 에이전트가 안전하게 수행할 수 있는 루프 구조로 바꾼다.
2. 사람의 역할을 “매번 실행자”에서 “기준·승인·검증을 설계하는 운영자”로 전환한다.
3. 성공한 루프를 OMW 문서, Hermes skill, 강의 모듈, 고객사 SOP로 재사용한다.

2. 정의

JYP Labs에서 Loop Engineering은 다음 구조를 설계·운영하는 일이다.

신호/요청 감지
→ 태스크 발견
→ 작업 분해
→ 실행자 배정
→ 실행
→ 검증
→ 결과 합성
→ 다음 결정
→ 기록/스킬화
→ 재실행

단일 프롬프트는 “한 번의 요청”을 해결한다. Loop Engineering은 “같은 종류의 업무가 다음번에 더 잘 처리되도록” 업무 체계를 개선한다.

2.1 작은 Closed Loop — AI 위임의 원자 단위

JYP Labs에서 작은 Closed Loop은 다음 여섯 요소가 닫혀야 완료된 것으로 본다.

문제 발견 → 요구 파악 → 작은 변경 → 테스트 → 검토 → 기록

루프가 작을수록 실패 비용은 낮아지고, 검증은 빨라지고, 여러 세션·subagent로 병렬화하기 쉬워진다. 반대로 아래 신호가 있으면 루프를 더 쪼갠다.

• 요청·제약·의도가 불명확한데 실행 범위가 넓다.
• “됐습니다” 외에 확인 가능한 증거가 없다.
• 수정 가능 범위와 금지 범위가 없다.
• 실패가 로그·문서·스킬에 남지 않는다.

3. 기본 원칙

3.1 측정 없는 진화는 금지한다

루프는 반드시 현재 상태를 재고, 변경 후 같은 기준으로 다시 재야 한다.

• 개선 전 기준 점수 또는 체크리스트를 만든다.
• 변경은 한 번에 하나씩 적용한다.
• 변경 전후를 같은 시험지로 비교한다.
• 좋아진 변경만 살리고, 나빠진 변경은 폐기한다.

3.2 한 번에 하나만 바꾼다

여러 조건을 동시에 바꾸면 무엇이 성능을 올렸는지 알 수 없다.

• 프롬프트 한 문장
• 체크리스트 한 항목
• 입력 데이터 한 종류
• verifier 한 단계
• 출력 형식 한 필드

위와 같이 변경 단위를 작게 유지한다.

3.3 사람은 루프 안이 아니라 루프 위에 선다

사람은 반복 실행자가 아니라 루프의 기준·승인·검증 책임자다.

사람이 소유해야 하는 것:

1. “좋은 결과”의 기준
2. 고정 시험지 또는 평가 체크리스트
3. 비가역 작업의 승인 경계
4. 최종 QA/E2E 판단
5. 실패 로그의 해석과 다음 실험 결정

AI가 맡을 수 있는 것:

1. 초안 생성
2. 후보 수집
3. 반복 실행
4. 결과 비교
5. 변경 제안
6. 로그 정리

2026-06-19 LinkedIn 보강

Sanguine Kim의 LinkedIn 포스트는 사람이 루프 위에서 관리해야 할 제어 문서를 AGENTS.md, customer.md, PRD.md, progress.md로 분리하고, 실행 결과가 바로 ship으로 가지 않도록 Quality Gate를 두어야 한다는 점을 재강조한다. 이는 JYP Labs의 문서 하네스·승인 경계·Evidence Package 표준을 보강하는 외부 사례다.

3.4 Subagent는 장문이 아니라 검증 가능한 결과 변수를 반환한다

하위 에이전트의 전체 reasoning/context를 상위로 덤프하면 비용과 오염이 커진다. 상위 루프에는 다음만 올린다.

• 산출물 경로 또는 URL
• 테스트/검증 결과
• 핵심 요약
• 확인 필요 항목
• 실패 사유
• 다음 액션 후보

3.5 실패 로그를 남긴다

실패는 버리지 않고 “다시 시도하지 말아야 할 경로”로 기록한다.

실패 로그 최소 필드:

failed_at: YYYY-MM-DD
loop_name: <loop>
change_attempted: <무엇을 바꿨는가>
expected_gain: <기대 효과>
actual_result: <측정 결과>
reason: <실패 원인 또는 확인 필요>
decision: discard | retry_later | needs_human_review

4. 표준 루프 구조

4.1 Discovery — 태스크 발견

목표: 루프에 넣을 업무 신호를 찾는다.

입력 예시:

• Slack 요청
• OMW 수집 문서
• Gmail 메일
• Google Calendar 일정
• GitHub issue/PR
• 회의록
• YouTube/LinkedIn/뉴스 자료

판단 기준:

• 반복되는가?
• 입력과 출력이 예측 가능한가?
• 검증할 수 있는가?
• 사람 승인 경계가 필요한가?
• 실행 결과가 다음 실행을 개선할 수 있는가?

4.1.1 작업 계약 — Prompt보다 Contract

Loop를 실행하기 전 최소 작업 계약을 둔다. 좋은 요청은 “알아서 개선해줘”가 아니라 “이 범위에서 이 증거를 남기고 닫아줘”이다.

계약 항목	의미
Goal	해결할 문제와 기대 결과
Context	문서, 코드, 이슈, 이전 실패
Boundaries	수정 가능 범위와 금지 범위
Validation	통과해야 할 테스트와 평가 기준(Rubric)
Stop	완료, 반려, 에스컬레이션 조건

4.2 Decompose — 작업 분해

목표: 하나의 요청을 실행 가능한 태스크로 쪼갠다.

표준 분해 형식:

goal: <최종 목표>
inputs:
  - <자료/파일/URL>
outputs:
  - <산출물>
constraints:
  - <범위/기한/금지사항>
risks:
  - <비용/권한/보안/품질 위험>
tasks:
  - id: T1
    owner: human | sophie | subagent | external_tool
    action: <작업>
    verification: <검증 방법>
    approval_required: true | false

4.3 Dispatch — 실행자 배정

목표: 작업 성격에 맞는 실행 방식을 고른다.

작업 유형	기본 실행자	조건
단순 조회/계산	Sophie + tool	결과가 즉시 검증 가능
코드 작성/리팩토링	Codex/Claude Code + Sophie 재검토	git 상태 확인, 테스트 필수
자료 조사/요약	Sophie 또는 subagent	출처 보존, 확인 필요 표시
다중 후보 비교	subagent fan-out	독립 비교 후 상위 합성
고위험 실행	사람 승인 후 진행	발송·삭제·결제·게시·권한 변경

4.4 Execute — 실행

목표: 정해진 산출물을 만든다.

실행 원칙:

• 파일을 쓰면 경로를 남긴다.
• 명령을 실행하면 실제 출력으로 검증한다.
• 외부 발송/삭제/게시/결제는 승인 없이 하지 않는다.
• 실패하면 우회 또는 중단 사유를 기록한다.

4.5 Verify — 검증

목표: 결과가 기준을 만족하는지 확인한다.

검증 레벨:

레벨	사용 조건	예시
L0 형식 검증	모든 루프	파일 존재, frontmatter, JSON/YAML 파싱
L1 근거 검증	요약/분류/브리핑	원문 경로, 인용, 확인 필요 표시
L2 실행 검증	코드/자동화	테스트, dry-run, 로그 확인
L3 반대 검증	고위험/고가치	adversarial review, 다른 agent 검토
L4 E2E 검증	제품/고객 전달	실제 사용자 흐름, 브라우저/수동 QA

Evidence Package — 완료의 최소 증거

완료 보고는 주장(assertion)이 아니라 검토 가능한 증거 패키지여야 한다.

필드	질문	예시
Diff	무엇을 왜 바꿨나?	수정 파일, 문서 섹션, 생성 산출물
Test	어떤 검증을 통과했나?	read-back, lint, test, dry-run, API 상태
Risk	무엇이 아직 위험한가?	확인 필요, 미검증 외부 주장, 비용·권한 위험
Memory	다음 루프에 무엇을 남기나?	실패 로그, skill/standard 보강, 장기 기억 후보

4.6 Synthesize — 결과 합성

목표: 여러 실행 결과를 사람에게 결정 가능한 형태로 줄인다.

출력 형식:

## 요약 3줄
- ...
 
## 실행 결과
- 산출물:
- 검증 결과:
- 실패/확인 필요:
 
## 다음 결정
1. 승인하고 적용
2. 보류하고 추가 검토
3. 폐기하고 실패 로그 등록

4.7 Decide — 다음 결정

목표: 루프를 멈출지, 반복할지, 스킬화할지 결정한다.

결정 옵션:

• apply: 변경을 적용한다.
• iterate: 다음 실험을 설계한다.
• skillize: Hermes/OMW skill로 승격한다.
• document: OMW standard/project/source에 기록한다.
• discard: 실패 로그로 남기고 폐기한다.
• escalate: 사람 승인 또는 외부 전문가 검토로 넘긴다.

4.8 Memory/Skillize — 기록과 재사용

목표: 다음 실행이 더 좋아지도록 남긴다.

기록 위치:

내용	저장 위치
원문 자료	wiki/sources/ 또는 raw/
기준/표준	wiki/work/standards/
실행 계획	wiki/work/projects/
반복 절차	Hermes skill
임시 실행 로그	cron/output 또는 project log
장기 사용자 선호	Mem0/Hermes user memory
환경·도구·프로젝트 운영 fact	Mem0/Hermes memory

세부 memory 저장/비저장 기준은 jyp-labs-memory-operating-standard-v0.1와 sophie-memory-candidate-checklist-v0.1를 따른다.

5. JYP Labs 표준 루프 템플릿

아래 템플릿은 새 업무를 loop로 설계할 때 사용한다.

# <Loop Name>
 
## 1. 목적
- 이 루프가 해결할 반복 업무:
- 성공 기준:
 
## 2. 입력
- 필수 입력:
- 선택 입력:
- 권한/도구:
 
## 3. 출력
- 기본 산출물:
- 보고 형식:
- 저장 위치:
 
## 4. 루프 단계
1. 발견:
2. 분해:
3. 실행자 배정:
4. 실행:
5. 검증:
6. 합성:
7. 다음 결정:
8. 기록/스킬화:
 
## 5. 평가 체크리스트
- [ ] 출처/근거가 명확하다.
- [ ] 사실과 추정이 구분되어 있다.
- [ ] 산출물이 지정된 형식에 맞다.
- [ ] 검증 로그가 있다.
- [ ] 실패/확인 필요 항목이 드러나 있다.
- [ ] 사람 승인 경계가 지켜졌다.
 
## 6. 변경 실험 로그
| 날짜 | 변경 1개 | 기대 효과 | 결과 | 결정 |
|---|---|---|---|---|
 
## 7. 인간 승인 경계
- 자동 가능:
- 승인 필요:
- 금지:

6. 우선 적용 루프

P0. OMW 수집 문서 → 실행 후보 TOP 3 루프

목표: 매일 수집되는 AI/AX 문서를 단순 요약이 아니라 JYP Labs 실행 후보로 전환한다.

OMW 수집 문서 탐지
→ raw/processed 중복 제거
→ 스킬/강의/자동화/loop 후보 분류
→ 우선순위 산정
→ TOP 3 추천
→ 대표님 승인/선택
→ 표준안·스킬·강의 모듈로 승격

검증 기준:

• 오늘 날짜 기준 문서만 포함했는가?
• migration/reindex/system noise를 제외했는가?
• 원문 경로가 보존됐는가?
• TOP3 선정 이유가 명확한가?
• 실행 후보가 실제 산출물로 이어지는가?

2026-06-14 최근 수집 문서 반영 — human-in-the-loop 우선 기준

최근 3일 수집 문서 중 Loop/Agentic Engineering 관련 상위 후보 2건을 반영한다.

• yt-Y9F1qktnpyQ-루프-한-달에-18억-태우는-사람들의-워크플로우를-당신이-따라하면-안-되는-이유.-하지만-쓰는곳이-있다.
• yt-QI1FNnUfiZg-클로드-만든-개발자는-이제-프롬프트를-안씁니다-Fable-5로-Loop-Engineering

운영 반영 원칙:

1. Human-in-the-loop 기본값: 기획서의 빈칸이 많거나 디자인·아키텍처·권한·비용 판단이 필요한 업무는 사람이 단계별 승인한다.
2. Agentic loop 제한 허용: 입력, 성공 기준, 테스트, 실패 중단 조건, 비용 상한이 문서화된 read-only 또는 샌드박스 업무에 한해 허용한다.
3. 비용·토큰 상한 선지정: 장시간 루프는 실행 전 최대 반복 수, 예산, 중단 조건을 적는다.
4. 검증자 독립성 유지: 실행 agent와 검증 agent 또는 사람 QA를 분리한다.
5. 승인 경계 유지: 외부 발송·삭제·게시·결제·권한 변경은 loop 안에서 자동 실행하지 않는다.

P0. Loop Engineering 표준안 작성 루프

목표: loop 관련 수집 자료를 내부 표준으로 전환한다.

Loop 관련 소스 3건 이상 확인
→ 공통 원칙 추출
→ JYP Labs 운영 단계로 재구성
→ 표준 템플릿 작성
→ OMW 저장
→ lint/search 검증
→ 다음 실행 과제 도출

P1. 바이브코딩: 데모에서 제품으로 루프

목표: 아이디어→plan.md→agent build→품질 게이트→배포/운영 흐름을 강의 모듈로 만든다.

검증 기준:

• 데모와 제품의 차이를 품질·보안·운영 관점에서 설명하는가?
• agentic engineering과 vibe coding의 차이를 구분하는가?
• 학습자가 바로 쓸 수 있는 체크리스트가 있는가?

P1. Gmail/Calendar/Drive 개인 인텔리전스 브리핑 루프

목표: Sophie/Hermes 개인 비서 브리핑을 Google Workspace 기반 개인 업무 OS로 고도화한다.

검증 기준:

• 메일/일정/드라이브/태스크 입력 경계가 명확한가?
• 민감 정보가 마스킹되는가?
• 일정 생성/메일 발송은 승인 후에만 진행되는가?

7. 강의/컨설팅 메시지

핵심 한 문장

AI를 잘 쓰는 사람은 프롬프트를 잘 쓰지만, AI로 조직을 바꾸는 사람은 루프를 설계한다.

3단계 설명

1. Prompt Engineering: AI에게 한 번 잘 말하는 기술
2. Context/Harness Engineering: AI가 일할 자료·도구·검사 장치를 주는 기술
3. Loop Engineering: 그 장치들이 매번 측정·개선·검증되게 만드는 운영 기술

임원/고객사 대상 질문

• 우리 회사에서 매일 반복되지만 품질 편차가 큰 업무는 무엇인가?
• 그 업무의 “좋은 결과” 기준은 문서화되어 있는가?
• AI가 만든 결과를 누가, 어떤 기준으로 검증하는가?
• 실패한 자동화 시도는 다음 루프에서 재사용되는가, 그냥 사라지는가?
• 비가역 작업의 인간 승인 경계는 명확한가?

8. 운영 체크리스트

새 루프를 운영하기 전 아래를 확인한다.

• 반복되는 업무인가?
• 입력과 출력이 정의됐는가?
• 성공 기준을 5~7개 체크리스트로 만들 수 있는가?
• 변경 전 기준 점수를 측정했는가?
• 한 번에 하나만 바꾸도록 설계됐는가?
• verifier 또는 human QA가 필요한 지점을 정했는가?
• 실패 로그 위치가 정해졌는가?
• 자동 실행과 사람 승인 경계가 분리됐는가?
• 성공 시 OMW 문서/Hermes skill/강의 모듈로 승격할 경로가 있는가?

9. 리스크와 방지책

리스크	설명	방지책
기준 오염	AI가 자기에게 유리하게 평가 기준을 바꿈	평가 체크리스트는 사람이 소유
목표 이탈	긴 루프에서 원래 목표를 잃음	각 반복마다 goal/constraints 재확인
토큰/비용 증가	subagent/verifier 남발	위험도·가치 기준으로 검증 레벨 선택
자동화 과신	실제 사용자 QA 없이 적용	L4 E2E는 사람 또는 브라우저 검증 유지
실패 반복	이전 실패를 기록하지 않아 재시도	실패 로그 필수화
비가역 사고	발송·삭제·게시를 자동 실행	승인 경계 명시, default stop

10. 적용 상태 / 변경 이력

날짜	반영 내용	근거
2026-06-11	OMW 수집 문서 → 실행 후보 TOP 3 루프 평가 기준을 v0.2로 정량화	omw-top3-evaluation-checklist-v0.2
2026-06-11	loop-engineering-workflow-design Hermes skill 후보를 Sophie profile skill로 생성하고 로드 검증	Sophie skill productivity/loop-engineering-workflow-design
2026-06-11	프롬프트 엔지니어링 다음 단계: Loop Engineering 5장 강의 초안과 PPTX 작성	loop-engineering-5-slide-draft, wiki/teaching/slides/loop-engineering-5-slide-draft.pptx
2026-06-14	최근 3일 수집 문서 5건을 P0/P1 실행으로 전환하고 TOP3 운영 로그에 기록	omw-top3-execution-metrics-log

11. v0.2 개정 후보

1. 실제 크론 브리핑 결과를 1주일 단위로 모아 TOP3 추천 정확도를 점검한다.
2. 운영 로그에서 반복 실패·승인 대기·검증 누락 사례를 추출해 평가 항목을 수치화한다.
3. 강의/컨설팅 적용 사례가 누적되면 Loop Engineering 예시 섹션을 보강한다.

12. 확인 필요

• LinkedIn 소스 일부는 공개 fetch 범위에 제한이 있어 원문 전체와 차이가 있을 수 있다.
• YouTube transcript는 자동 수집 텍스트이므로 세부 용어 오인식 가능성이 있다.
• 본 문서는 v0.1 초안이며, 실제 운영 로그를 반영해 v0.2에서 평가 항목을 수치화해야 한다.