MCPlato의 Loop Engineering: 프롬프트에서 Artifact를 남기는 워크플로로

먼저 답하자면: Loop Engineering은 더 긴 프롬프트를 쓰는 일이 아닙니다. 입력을 관찰하고, 상태를 유지하고, 체크포인트에서 멈추고, 실패에서 복구하고, 사람의 승인을 요청하고, 검토 가능한 Artifact를 남길 수 있는 작업 루프를 설계하는 일입니다. MCPlato에서 그 루프는 Wand, Skill, Scheduled Task, channel workflow 또는 Sprite가 조정하는 여러 세션의 집합이 될 수 있습니다.

MCPlato의 Loop Engineering 표지 일러스트

그림 1: Loop Engineering은 일회성 AI 요청을 지속 가능한 Artifacts를 만드는 작업 사이클로 바꿉니다.

Prompt Engineering은 어떻게 요청해야 하는가? 를 묻습니다. Loop Engineering은 Artifact가 완성될 때까지 AI가 어떻게 안전하게 계속 작업해야 하는가? 를 묻습니다.

이 차이는 중요합니다. 실제 업무는 한 번의 응답으로 끝나는 경우가 드물기 때문입니다. 유지보수자는 테스트 증거가 포함된 수정이 필요하고, 제품 리드는 출처와 타임스탬프가 있는 브리핑이 필요하며, 운영팀은 감사 추적이 포함된 보고서 패키지가 필요하고, 사업 책임자는 외부 작업이나 파괴적 작업 전에 승인이 필요합니다.

따라서 올바른 설계 단위는 루프입니다.

MCPlato 루프 설계 방법

좋은 루프에는 세 가지 속성이 있습니다.

1. 관찰 가능: 사용자가 출처, 상태, 작업, 결과를 볼 수 있습니다.
2. 복구 가능: 작업이 처음부터 다시 시작되거나 반복되는 대신 체크포인트에서 재개될 수 있습니다.
3. Artifact 중심: 루프는 보고서, diff, 스프레드시트, 패키지, 의사결정 로그, 브리핑, 초안, 검토 기록처럼 검토 가능한 무언가로 끝납니다.

MCPlato는 이 모델에 자연스럽게 대응합니다.

• Wand: 반복 가능한 작업을 위한 패키지형 워크플로로, 단계, 안내, Artifact 지향의 가시적 런타임을 포함합니다.
• Artifact: 루프가 유용한 작업을 수행했다는 사실을 증명하는 지속 가능한 출력물입니다.
• Sprite: 작업을 여러 세션으로 나누고 결과를 다시 모을 수 있는 조정자입니다.
• Skill 및 Distill Skill: 루프가 스스로를 입증한 뒤 다시 호출할 수 있는 재사용 가능한 노하우입니다.
• ClawMode: 시간, 채널, 백그라운드 컨텍스트를 넘어 작업을 계속하게 하는 방식입니다.
• Scheduled Tasks 및 Channels: 반복 루프를 위한 트리거와 전달 경로입니다.
• 권한 및 체크포인트: 유용한 자율성을 통제된 상태로 유지하는 경계입니다.

실용적인 MCPlato 루프는 보통 아홉 단계를 따릅니다.

이 글의 나머지는 공개 토론과 문서에서 발견되는 네 가지 실제 사용자 수요 시나리오에 이 방법을 적용합니다.

시나리오 1: GitHub issue -> 수정 PR -> 증거 기반 QA 보고서

오픈소스 유지보수자들은 이미 GitHub issues를 맡아 제한된 수정을 시도할 수 있는 agents를 실험하고 있습니다. OpenHands는 저장소 issues를 위한 GitHub resolver를 설명하고, 그 QA 문서는 단순히 코드를 생성하는 것보다 변경 사항 검증에 초점을 둡니다.¹² 유지보수자에게는 패치, 테스트, 그리고 그 변경이 검토하기에 충분히 안전하다는 증거가 필요합니다.

관련 위험은 실제 개발자 피드백에서도 나타납니다. Continue의 한 GitHub issue는 어떤 agent가 깔끔하게 멈추지 않고 같은 코드에서 반복적으로 루프를 돌았다고 보고합니다.³ 이것이 Loop Engineering이 다루어야 할 실패 모드입니다. 중지 조건 없는 통제되지 않은 반복입니다.

GitHub issue에서 QA 증거로 이어지는 루프

그림 2: 제한된 엔지니어링 루프는 issue가 수정되었다는 주장만이 아니라 diff, 검증 로그, QA 증거 Artifact를 만들어야 합니다.

루프 설계

MCPlato에서 루프는 모델 출력이 아니라 Artifact에서 시작해야 합니다.

1. Issue 접수: issue, 연결된 파일, 재현 메모, 저장소 제약을 수집합니다.
2. 계획 체크포인트: 편집하기 전에 사용자 또는 유지보수자에게 의도한 범위를 승인받습니다.
3. 패치 단계: 범위가 지정된 작업 영역 안에서 가장 작은 합리적 변경을 수행합니다.
4. 검증 단계: 합의된 검사를 실행하고, 실패를 기록하며, 승인된 범위 안에서만 재시도합니다.
5. 증거 Artifact: 변경된 파일, 테스트 로그, 관련된 경우 스크린샷, 남은 위험을 포함하는 QA 보고서를 만듭니다.
6. 검토 게이트: PR 또는 MR 설명 초안을 준비하되, 작업이 병합되었거나 수락되었다고 표현하지 않습니다.
7. Distill: 패턴이 작동하면 이를 재사용 가능한 저장소 QA Skill 또는 팀용 Wand로 바꿉니다.

MCPlato 구현 패턴

여기서는 Sprite가 조정하는 구성이 유용합니다. 한 세션은 issue를 읽고 계획을 작성하고, 다른 세션은 저장소를 검사하며, 또 다른 세션은 검증하고, 마지막 세션은 QA 증거 Artifact를 조립할 수 있습니다. Wand는 이러한 단계를 패키지화하여 팀이 issue마다 루프를 새로 만들지 않도록 할 수 있습니다.

중요한 가드레일은 중지 조건입니다. 검증 예산이 소진되었거나, 같은 실패가 반복되었거나, 변경이 승인된 범위를 초과할 때 루프는 멈춰야 합니다. Artifact는 불확실성을 숨기지 말고 정확히 무슨 일이 있었는지 말해야 합니다.

Artifact: diff 요약, 테스트 로그, QA 증거 보고서, PR/MR 설명 초안, 위험 목록.

시나리오 2: 전체 결과를 전달하는 예약된 리서치 브리핑

반복적인 리서치는 "prompt once"가 너무 약한 또 다른 영역입니다. 예약된 AI 작업을 논의하는 사용자들은 완료 알림만이 아니라 전체 결과를 이메일로 보내달라고 요청했습니다.⁴ Zapier의 ChatGPT scheduled tasks 개요는 ChatGPT에게 미래 시점이나 반복 주기에 프롬프트를 실행하게 하는 패턴을 설명합니다.⁵ 실제 격차는 전달 품질입니다. 유용한 예약 루프는 링크, 타임스탬프, 델타, 실행 항목을 포함한 브리핑을 만들어야 합니다.

예약 브리핑 전달 루프

그림 3: 예약 루프는 출처를 수집하고, 중복을 제거하고, 종합하고, 인용을 확인하며, 전체 브리핑 Artifact를 올바른 채널로 전달해야 합니다.

루프 설계

MCPlato 브리핑 루프는 다음과 같을 수 있습니다.

1. 예약 트리거: 매일, 매주 또는 정기 회의 전에 실행합니다.
2. 출처 수집: 저장된 URL, RSS와 유사한 피드, 문서 페이지, 워크스페이스 자료처럼 승인된 출처를 수집합니다.
3. 관련성 및 중복 제거: 반복된 공지와 신호가 낮은 항목을 제거합니다.
4. 종합: 안정적인 형식으로 브리핑을 작성합니다.
5. 인용 확인: 모든 구체적 주장이 출처 URL로 되돌아갈 수 있는지 확인합니다.
6. Artifact 출력: 날짜가 있는 브리핑을 만들고 출처 목록과 실행 항목 표를 포함합니다.
7. Channel 전달: 전체 Artifact 또는 Artifact 링크가 있는 간결한 요약을 보냅니다.
8. 후속 조치: 사용자가 더 깊은 분석을 요청하거나, 다음 작업을 할당하거나, 브리핑 루프를 distill할 수 있게 합니다.

MCPlato 구현 패턴

여기에서 Scheduled Tasks, ClawMode, 채널이 함께 작동합니다. Scheduled Task가 루프를 트리거하고, MCPlato가 승인된 컨텍스트를 수집해 Artifact를 만들고 워크스페이스 또는 채널로 전달합니다. 브리핑이 중요도가 높을 때 Sprite는 출처 수집, 종합, 인용 검토를 맡는 별도 workers를 조정할 수 있습니다.

브리핑 루프는 실제로 접근하지 않은 출처를 읽은 것처럼 가장해서는 안 됩니다. 정보를 사용할 수 없을 때 Artifact에는 "찾을 수 없음" 또는 "확인되지 않음"이 포함되어야 합니다. 이런 정직한 상태가 세련되지만 검증 불가능한 문단보다 더 유용합니다.

Artifact: 일간 또는 주간 브리핑, 출처 목록, 실행 항목 표, 이전 실행 대비 델타, 인용 메모.

시나리오 3: 브라우저 로그인, 매개변수 입력, 보고서 다운로드, 로컬 정리

많은 비즈니스 워크플로는 여전히 깔끔한 API가 아니라 웹 페이지 뒤에 있습니다. Stack Overflow의 한 질문은 웹 페이지에 로그인하고 보고서를 다운로드하는 일을 자동화하는 방법을 묻습니다.⁶ Python.org 토론에서 한 사용자는 약 50개 고객에 대해 각각 34개의 보고서를 다운로드하며, 매주 수작업으로 34시간이 걸린다고 설명합니다.⁷ 이것은 실제 운영상의 고통입니다. 반복적이고, 브라우저에 묶여 있으며, 실수하기 쉽습니다.

브라우저 보고서 다운로드 루프

그림 4: 브라우저 자동화는 사람의 로그인 경계를 반복적인 매개변수, 다운로드, 검증, 정리 단계와 분리해야 합니다.

루프 설계

안전한 브라우저 보고서 루프는 접근 경계를 명확히 해야 합니다.

1. 요구사항 접수: 고객 이름, 보고서 유형, 날짜 범위, 예상 파일을 나열합니다.
2. 접근 경계: 로그인, MFA, CAPTCHA처럼 사용자가 수동으로 해야 할 일을 결정합니다.
3. 발견 및 API 확인: 브라우저 자동화를 사용하기 전에 문서화된 내보내기 또는 API가 있는지 확인합니다.
4. 브라우저 자동화: 매개변수를 입력하고, 다운로드를 시작하고, 각 단계를 기록합니다.
5. 검증: 파일 이름, 타임스탬프, 예상 개수, 명백히 빈 파일을 확인합니다.
6. 변환: 폴더를 정규화하고, 적절할 때 형식을 변환하며, 요약을 만듭니다.
7. 예외 보고서: 누락된 다운로드, 실패한 고객, 변경된 페이지를 나열합니다.
8. 예약 반복: 반복 가능한 부분만 주기에 따라 실행하고, 자격 증명이나 페이지 구조가 바뀌면 사람의 체크포인트를 둡니다.

MCPlato 구현 패턴

MCPlato를 "어떤 웹사이트든 처리할 수 있다"고 설명해서는 안 됩니다. 웹사이트는 서로 다르고, 로그인은 바뀌며, 정책은 중요하고, 일부 흐름은 의도적으로 자동화에 저항합니다. 더 나은 설명은 다음과 같습니다. MCPlato는 허용되고 반복 가능한 부분을 중심으로 통제된 루프를 설계하도록 도울 수 있습니다.

사용자는 로그인 체크포인트를 처리할 수 있습니다. 그러면 AI 루프는 승인된 브라우저 세션 안에서 작동하며, 보고서를 다운로드하고, 로컬 파일을 정리하고, 예외 Artifact를 만들 수 있습니다. 웹사이트가 바뀌면 루프는 추측하지 말고 멈춘 뒤 불일치를 보고해야 합니다.

이런 종류의 루프는 몇 차례 성공적으로 실행한 뒤 Wand로 distill할 가치가 있는 경우가 많습니다. Wand는 취약한 기록이 아니라 명확한 단계와 출력 폴더를 갖춘 팀의 반복 가능한 "월간 보고서 패키지" 프로세스가 됩니다.

Artifact: 다운로드된 보고서 패키지, 성공/실패 목록, 정규화된 폴더 구조, 요약 스프레드시트, 예외 보고서.

시나리오 4: 위험한 도구 호출에 대한 사람의 승인

Loop Engineering은 더 많이 하는 것만을 의미하지 않습니다. 언제 멈춰야 하는지를 아는 것도 포함합니다. 한 LangGraph issue는 사용자가 실행 전에 작업을 승인, 거부, 수정할 수 있는 approval-node 패턴을 요청합니다.⁸ LangChain의 human-in-the-loop 문서는 도구 호출 주변에서 검토를 위해 멈추는 방식을 설명합니다.⁹

위험 예시는 익숙합니다. 파일 쓰기, SQL 실행, 데이터 삭제, 콘텐츠 게시, 이메일 전송입니다. 이는 단순한 "agent steps"가 아닙니다. 비즈니스 행동입니다.

사람 승인 게이트 루프

그림 5: 좋은 루프는 위험한 작업 전에 멈추고, 결정을 기록하며, 실행 후 증거를 남깁니다.

루프 설계

위험한 작업 루프는 다음과 같아야 합니다.

1. 위험 분류: 다음 작업이 읽기 전용인지, 되돌릴 수 있는지, 외부에 노출되는지, 파괴적인지, 금전 관련인지 판단합니다.
2. 작업 초안: 파일 변경, SQL 문, 이메일, 게시물, 명령을 실행하지 않고 준비합니다.
3. 승인 체크포인트: 의도한 작업, 이유, 예상 효과, 롤백 계획을 사용자에게 보여줍니다.
4. 사용자 결정: 승인, 편집, 거부 또는 추가 컨텍스트 요청을 합니다.
5. 실행: 승인된 작업만 실행합니다.
6. 증거 Artifact: 결정, 전후 diff, 실행 결과, 남은 위험을 기록합니다.

MCPlato 구현 패턴

MCPlato의 루프 어휘는 이를 간단하게 만듭니다. Wand는 초안 작성과 실행을 분리할 수 있습니다. 권한은 승인 전에는 더 좁게, 확인 후에만 더 넓게 설정할 수 있습니다. Sprite는 사용자에게 보여주기 전에 다른 세션이 제안된 작업을 검토하도록 요청할 수 있습니다. ClawMode와 채널은 승인 요청을 사용자가 작업 중인 곳으로 전달할 수 있습니다.

루프는 위험한 기본값을 정상화해서는 안 됩니다. 데이터 삭제, 외부 메시지 전송, 청구 변경, 콘텐츠 게시에는, 사용자가 해당 작업을 위한 신뢰되고 제한된 워크플로를 명시적으로 설계하지 않은 한 게이트가 필요합니다.

Artifact: 승인 기록, 변경 계획, 전후 diff, 메시지 또는 이메일 초안, 실행 증거, 위험 목록.

성공한 루프를 재사용 가능한 MCPlato 역량으로 바꾸는 방법

루프가 한 번 성공했다고 해서 곧바로 모든 것을 자동화해서는 안 됩니다. 먼저 물어보세요.

1. Artifact가 유용했는가? 출력이 사용자의 의사결정이나 작업 완료를 돕지 못했다면 루프는 아직 준비되지 않았습니다.
2. 체크포인트가 올바른 위치에 있었는가? 체크포인트가 너무 많으면 루프가 성가시고, 너무 적으면 안전하지 않습니다.
3. 다른 사용자가 숨은 컨텍스트 없이 실행할 수 있는가? 답이 아니오라면 필요한 입력과 가정을 문서화하세요.

그다음 적절한 MCPlato 패키징 경로를 선택합니다.

MCPlato main branch의 최신 방향은 채팅에서 패키지화되고 관찰 가능한 작업으로의 전환을 강화합니다. Wands는 워크플로를 명시적으로 만듭니다. Artifact 지향 런타임 보기는 결과를 계속 보이게 합니다. Wand 작성과 반복 안내는 성공한 루프를 재사용 가능한 역량으로 바꾸기 쉽게 합니다. Skills와 Distill Skill은 방법의 반복 가능한 부분을 보존합니다.

원칙은 단순합니다. 답만 저장하지 말고, 그 답을 만든 작업 루프를 저장하세요.

위험과 가드레일

Loop Engineering은 강력하지만 예측 가능한 방식으로 실패할 수 있습니다.

• 폭주하는 반복: 예산, 반복 실패 감지, 명시적 종료 상태를 추가하세요.
• 가짜 완료: 로그, 출처 또는 전후 증거가 포함된 Artifact를 요구하세요.
• 권한 확장: 단계별로 권한을 할당하세요.
• 숨은 컨텍스트: 가정을 Artifact에 기록하세요.
• 과도한 자동화: 위험한 단계에는 승인 체크포인트를 추가하세요.
• 취약한 브라우저 흐름: 조용한 추측 대신 검증과 예외 보고서를 사용하세요.
• 인용 드리프트: 출처 타임스탬프와 인용 검토를 요구하세요.

좋은 루프는 자율성이 가장 많은 루프가 아닙니다. 좋은 루프는 Artifact를 완성하면서 그 작업을 신뢰할 만큼 충분히 보이게 하는 루프입니다.

FAQ

Loop Engineering이란 무엇인가요?

Loop Engineering은 AI 작업을 단일 응답이 아니라 상태가 있는 프로세스로 설계하는 실천입니다. 루프는 목표, 입력, 단계, 권한, 체크포인트, 복구 경로, 최종 Artifact를 정의합니다.

Prompt Engineering과 어떻게 다른가요?

Prompt Engineering은 지시를 개선합니다. Loop Engineering은 지시를 둘러싼 작업 시스템을 개선합니다. 더 나은 프롬프트는 더 나은 첫 답변을 만들 수 있습니다. 더 나은 루프는 계속하고, 검증하고, 멈추고, 복구하고, 전달할 수 있습니다.

MCPlato는 어디에 적합한가요?

MCPlato는 작업이 세션, 파일, 브라우저 컨텍스트, 일정, 채널, 지속 가능한 출력에 걸쳐 있을 때 유용합니다. Wand, Artifact, Sprite, Skill, ClawMode, Scheduled Tasks, 채널, 권한, 체크포인트라는 루프 어휘는 유용한 일회성 작업을 반복 가능한 역량으로 바꾸는 데 도움을 줍니다.

모든 AI 작업이 루프가 되어야 하나요?

아니요. 단순한 질문은 단순한 질문으로 남아도 됩니다. 작업이 장시간 실행되거나, 반복되거나, 위험하거나, 증거가 많이 필요하거나, Artifact 중심일 때 Loop Engineering을 사용하세요.

Loop Engineering은 정확성을 보장하나요?

아니요. 관찰 가능성, 복구, 검토를 개선합니다. 루프는 여전히 나쁜 출처를 사용하거나, 잘못된 가정을 하거나, 변경된 도구에서 실패할 수 있습니다. 그래서 인용, 체크포인트, 예외 보고서가 중요합니다.

참고 문헌

Footnotes

1. OpenHands: GitHub의 오픈소스 coding agents가 issues를 수정합니다 ↩

2. OpenHands 문서: QA changes ↩

3. Continue issue #8062 ↩

4. OpenAI Community: 알림만이 아니라 전체 ChatGPT task 결과를 이메일로 보내기 ↩

5. Zapier: ChatGPT scheduled tasks 사용 방법 ↩

6. Stack Overflow: 웹페이지 로그인을 자동화하고 보고서를 다운로드할 방법이 있나요? ↩

7. Python.org 토론: Selenium을 사용해 웹사이트에서 보고서를 자동으로 다운로드하기 ↩

8. LangGraph issue #8026: ApprovalNode ↩

9. LangChain 문서: Human-in-the-loop ↩