DREAMLABS · WORKER HOST

팀의 역할은 유지하고,
AI 실행력은 확장하세요.

반복 업무를 역할별 Worker에 맡기고, 팀은 검토와 결정에 집중하세요. 각 Worker는 허용된 지식과 도구로 인증된 사용자의 독립 요청 하나를 처리합니다.

AGENTOPS FOUNDATION Worker를 만드는 데서 끝나지 않고, 요청·실행·결과·변경의 운영 경계를 함께 관리하도록 설계합니다.

내 업무와 닮은 사례 보기 작동 방식 확인하기

요청은 독립적으로 · 결과는 검토 가능하게 · 결정은 사람에게

ROLE-BASED EXECUTIONHUMAN-GATED
PLProduct Lead독립 요청
PRODUCT WORKER허용된 맥락으로 처리

KnowledgeTools

REVIEWABLE RESULT범위 · 근거 · 확인 항목사람이 승인·수정·보류
HUMAN CONTROL 다음 단계가 필요하면 사람이 새로운 독립 요청을 만듭니다.
01역할별 Worker
02독립 요청 실행
03사람의 승인
04상태와 결과 추적

AGENTOPS FOUNDATION

Worker를 만들고, 실행하고, 확인하고,
안전하게 바꾸는 운영 기반

AgentOps는 AI Worker를 실제 업무에서 지속적으로 실행·관찰·통제·변경하는 운영 방식입니다. Worker Host는 역할별 구성과 독립 실행을 명확한 운영 경계로 연결합니다.

  1. 01CONFIGURE

    역할과 범위 구성

    담당 역할에 필요한 지식·도구·접근 범위를 분리해 구성합니다.

    ROLE · KNOWLEDGE · TOOLS
  2. 02RUN

    독립 요청 실행

    인증된 사용자의 독립 요청 하나를 지정된 Worker에서 처리합니다.

    AUTH · REQUEST · CONTROL
  3. 03OBSERVE

    상태와 결과 확인

    상태와 결과를 검토하고, 적용된 기록 정책 범위에서 History와 redacted audit을 확인합니다.

    STATUS · RESULT · HISTORY
  4. 04CHANGE

    검증된 단위로 변경

    Whole Worker Release를 변경 단위로 삼고, 환경별 검증과 rollback 경계를 구분합니다.

    RELEASE · VERIFY · ROLLBACK

사람 중심의 운영 루프 결과가 다음 업무나 배포를 자동으로 시작하지 않습니다. 사람 또는 승인된 정책이 다음 단계를 결정합니다.

SOURCE-ONLY · DEPLOYED · BLOCKED
기능·환경별 상태 구분

WORK SCENARIOS

내 업무와 닮은 장면부터
확인하세요.

기술 구조보다 먼저 누가 무엇을 요청하고, 어떤 결과를 검토하며, 사람이 어디에서 결정하는지 사례별로 보여드립니다.

판매·수익성 분석 가상 시나리오 포스터01
가상 적용 시나리오15초 사례 영상
판매·수익성 분석

흩어진 판매·매입 데이터를, 결정할 수 있는 숫자로

거래처별 판매량, 수익성 비율과 프로모션 전후 변화를 산식·근거와 함께 정리합니다.

15초 영상과 사례 보기
기관 문서업무 가상 시나리오 포스터02
가상 적용 시나리오15초 사례 영상
기관 문서업무

정해진 서식은 기준에 맞게, 서식이 없는 문서는 구조부터

보고서·접수 문서·회의자료를 초안, 누락 후보와 참고 근거로 정리합니다.

15초 영상과 사례 보기
기업 운영업무 가상 시나리오 포스터03
가상 적용 시나리오15초 사례 영상
기업 운영업무

흩어진 운영정보를 다음 행동이 보이는 결과로

회의·요청·실적자료를 핵심 요약, 실행 항목과 확인 필요사항으로 구조화합니다.

15초 영상과 사례 보기
작은 개발팀 가상 시나리오 포스터04
가상 적용 시나리오15초 사례 영상
작은 개발팀

제품·개발·QA 역할은 유지하고 AI 실행력은 확장

역할자가 각자의 Worker에 독립 요청하고 요구사항·영향 분석·테스트 결과를 검토합니다.

15초 영상과 사례 보기
HUMAN
CONTROL기획제작 준비공개피드백
05
가상 적용 시나리오기획→피드백 순환 사례 · 영상 추후 제작
유튜브 콘텐츠 운영

한 편의 반응을 다음 콘텐츠 기획의 근거로

기획·제작 준비·공개 후 피드백을 역할별 Worker가 정리하고, 사람이 반영할 내용을 선택해 다음 독립 요청으로 이어갑니다.

순환 구조와 사례 보기

WHY WORKER HOST

AI를 연결하는 것만으로는
충분하지 않습니다.

업무에 AI를 적용하려면 모델 연결을 넘어 요청, 역할, 지식, 권한과 결과를 확인할 수 있는 실행 기반이 필요합니다.

01

맥락이 매번
처음부터 시작됩니다

팀의 용어와 기준이 대화마다 반복되고 결과의 일관성을 유지하기 어렵습니다.

02

중요한 변경의
경계가 흐려집니다

단순 분석과 실제 변경, 사용자 확인이 필요한 지점을 구분하기 어렵습니다.

03

작업의 상태와
결과가 흩어집니다

무엇을 요청했고 어디까지 진행됐는지 팀이 함께 확인하기 어렵습니다.

HOW IT WORKS

요청부터 결과까지,
네 단계로 명확하게

01

요청

사용자가 원하는 결과와 작업 범위를 자연어로 전달합니다.

02

확인

Worker가 역할, 지식, 도구와 허용 범위를 확인합니다.

03

실행

정해진 범위에서 작업하고 필요하면 사용자 확인을 요청합니다.

04

결과

상태, 결과와 사람이 검토할 다음 항목을 제공합니다.

결과에서 새로운 업무가 자동으로 시작되지는 않습니다. 사람의 검토가 다음 요청을 만듭니다.

ROLE-BASED WORKERS

한 명의 만능 AI보다,
팀을 이해하는 역할별 Worker

각 역할에 필요한 업무 지식, 도구와 접근 범위를 구분하고 사람의 책임 구조에 맞춰 구성합니다.

ROLE OWNER

BO

Business Owner

“거래처별 판매량과 수익성 변화를 분석해 줘”

ROLE-BASED AI

Data Analysis Worker

KnowledgeApproved Tools

REVIEWABLE OUTPUT

비교표 · 산식 · 증감 · 확인 항목

사람의 결정영업 집중, 가격과 프로모션 방향을 결정합니다.

WHOLE SYSTEM CONCEPT

요청이 들어오고, Worker가 실행하고,
사람이 결정하는 전체 구조

독립 요청의 실행 흐름과 운영 변경의 책임을 분리해, 어디까지 AI가 처리하고 어디서 사람이 결정하는지 보여줍니다.

EXECUTION FLOW

독립 요청 하나의 실행 흐름

NO ORCHESTRATION Worker 간 자동 호출이나 자동 후속 요청이 없습니다.

  1. USER TOUCHPOINTS

    사람이 요청을 시작

    • Web Console
    • Chat · Mattermost
    • Remote Request API · Source-only
    • 예약된 독립 요청

    연결 범위와 상태는 적용 환경별로 확인합니다.

  2. ONE INDEPENDENT REQUEST

    지정된 Worker에 요청을 접수

    사람 또는 연결 설정이 정한 Worker에서 요청을 인증·정규화하고 권한과 처리 상태를 고정합니다.

    Data · Product · Engineering · QA · Release가상 역할 구성 예시 · 자동 배차 아님
  3. TARGET WORKER

    역할별 Worker가 독립 실행

    요청 해석 · 권한 확인 · 작업 상태 · 실행 제어를 지정된 Worker 안에서 처리합니다.

    이 요청에 지정된 Worker 1개
  4. REVIEWABLE RESULT

    결과를 사람이 검토·결정

    결과 · 근거 · 처리 상태를 확인하고 승인, 수정 또는 보류를 결정합니다.

    NO AUTO FOLLOW-UP 결과가 다음 요청을 자동으로 만들지 않습니다.
CONTEXT & CAPABILITIES

지정된 Worker가 허용 범위 안에서 사용하는 실행 자원

Worker별 격리 · 환경별 구성

  • WORKER CONTEXT승인된 지식 · 작업 기록현재 요청에 필요한 범위만 사용
  • WORKSPACE파일 · 프로젝트 · Skills권한과 작업 범위 안에서 연결
  • AI RUNTIME구성된 단일 실행 환경공급자와 기능은 환경별 선택
  • TOOLS & SYSTEMS승인된 도구 · MCP사내·외부 시스템은 허용된 접근만
CONTROLLED COLLABORATION

독립 실행은 유지하고, 역할 간 협업은 제한된 handoff로

NEW INDEPENDENT REQUESTS ONLY

각 Worker의 결과를 사람이 검토해 다른 역할 Worker의 새 요청에 포함하면 협업 흐름을 구성할 수 있습니다. Worker가 다른 Worker를 직접 호출하거나 결과가 자동으로 다음 업무를 시작하지는 않습니다.

ROLE WORKER A · 구성 예Product Worker의 결과

요구사항 범위 · 수용 기준 · 확인 항목

REVIEW & HANDOFF다음 역할로 전달할지 결정

검토된 결과 중 필요한 범위만 선택해 새로운 요청을 만듭니다.

기본 사람의 검토와 전달연동 옵션 승인된 외부 업무 시스템 Source-only · 환경별 검증
ROLE WORKER B · 구성 예Engineering·QA Worker 실행

새 요청 ID · 별도 권한 · 독립된 처리 상태

제한 범주 외부 업무 시스템은 Worker Host 밖에서 인증된 독립 요청만 조정합니다. Worker 간 직접 호출, 결과 기반 자동 후속 실행과 공유 워크플로 엔진은 포함하지 않습니다.

AGENTOPS OPERATIONS PLANE

Worker 운영과 변경을 담당하는 AgentOps 경계

MIXED STATUS · VERIFY BY ENVIRONMENT
  • REFERENCE · NOT A DISPATCHERWorker Registry

    역할·이미지·버전·상태를 별도 운영 경계에서 참조

    SOURCE-ONLY · RUNTIME UNVERIFIED
  • SOURCE · REVIEW · BUILD검증 기준 Worker Release

    소스, 검증 결과와 immutable 이미지의 기준을 관리

    SOURCE-ONLY
  • SITE-LOCAL UPDATEWorker Update Manager

    사용자 또는 승인 정책이 만든 요청만 해당 사이트에서 처리

    DEPLOYED · SPECIFIC ENV
  • CUSTOMER RUNTIMEPortainer · Docker 환경

    지정된 Worker를 독립 실행하고 운영 변경을 분리

    DEPLOYED · DIRECT-TEST
  • PER-WORKER BOUNDARY독립 데이터 · 인증 · 상태

    보존 여부는 Release와 환경별 검증 결과로 확인

    VERIFY BY RELEASE

이 개념도가 모든 구성의 배포를 뜻하지는 않습니다. Registry는 요청을 자동 배차하거나 Worker를 지휘하지 않으며, Manager가 구성된 환경에서는 해당 사이트의 Manager가 업데이트 실행을 담당합니다.

  • 01독립 요청한 요청은 한 실행 단위로 처리
  • 02승인된 맥락Worker별 지식과 작업 범위 유지
  • 03통제된 handoff검토 후 다른 역할에 새 요청
  • 04운영 변경 분리배포·업데이트 권한은 별도 경계
  • 05사람의 최종 결정결과 검토 후 다음 요청을 선택

상태 읽는 법 Source-only는 소스에만 존재하고, Deployed는 특정 환경의 배포 근거가 있으며, Blocked는 확인된 제한이 남아 있음을 뜻합니다. 실제 상태는 기능·환경·특정 Worker별로 구분합니다.

Product reference · 22f6e3ba456523dc59d851f02588e8e7ef6d6472 · 2026-08-20

RUNTIME KNOWLEDGE

팀의 지식을
매 요청의 맥락으로

제품 정보, 팀의 용어, 개발 원칙과 운영 절차를 승인된 지식으로 구성할 수 있습니다. 적용된 Worker는 현재 요청에 필요한 범위를 선택해 활용합니다.

Core 공통 필수 지식Auto 관련 지식 선택Pinned 지정 범위 고정Off 지식 미사용

검색과 미리보기만으로 지식이 변경되지는 않습니다.

CURRENT APPROVED KNOWLEDGErevision-bound
01제품과 서비스제품 설명 · 용어 · 정책
02개발과 검증개발 원칙 · 테스트 기준
03운영과 결정운영 절차 · 주요 결정
요청에 필요한 범위만 선택
K
TURN CONTEXTWorker 실행 전 맥락

사용한 지식의 provenance를 결과와 연결합니다.

HUMAN-LED BY DESIGN

빠른 실행과 사람의 통제를
함께 설계했습니다

01

독립 요청

Worker는 인증된 사용자가 보낸 요청 하나를 정해진 범위에서 처리합니다.

02

명시적인 승인

중요한 변경과 추가 권한이 필요한 순간에는 사람의 확인을 요청합니다.

03

역할별 접근 범위

지식, 도구와 작업 공간을 Worker의 역할과 책임에 맞게 구성합니다.

04

확인 가능한 결과

적용된 기록 정책에 따라 작업 상태와 결과를 검토할 수 있도록 구성합니다.

“

Worker는 다른 Worker를 자동으로 지휘하거나
결과를 보고 다음 업무를 임의로 생성하지 않습니다.

요청은 독립적으로 · 결정은 사람에게

ADOPTION PATH

작은 업무 하나에서 시작해
검증된 범위만 확장하세요

우리 팀의 첫 Worker 설계하기
  1. 01
    업무 선택

    반복되는 업무 하나를 고릅니다.

  2. 02
    역할 구성

    담당자와 역할별 Worker를 정합니다.

  3. 03
    범위 설정

    참고 지식, 도구와 승인 지점을 정의합니다.

  4. 04
    작게 검증

    분석·문서화 요청부터 품질을 확인합니다.

  5. 05
    단계적 확대

    검증된 업무와 역할만 확장합니다.

FAQ

자주 묻는 질문

Worker Host의 역할과 사람의 책임, 실제 적용 범위를 명확하게 확인하세요.

01일반 AI Chat과 무엇이 다른가요?

대화만 남기는 것이 아니라 역할별 지식과 도구, 요청 상태, 결과와 작업 기록을 하나의 실행 흐름으로 연결합니다.

02Worker Host는 AgentOps 플랫폼인가요?

Worker Host는 역할별 AI Worker의 요청·실행·결과·상태·업데이트를 확인하고 통제하기 위한 AgentOps 운영 기반을 제공합니다. 다만 Worker 간 자동 멀티에이전트 오케스트레이션이나 범용 fleet 운영 전체를 뜻하지는 않으며, Registry와 일부 연동 기능은 표시된 상태와 적용 환경별로 확인합니다.

03Worker마다 다른 역할을 설정할 수 있나요?

네. 담당 업무, 참고 지식, 사용할 도구와 접근 범위를 역할에 맞게 구분할 수 있습니다. 실제 제공 범위는 적용 환경별로 확인합니다.

04여러 Worker가 협업할 수 있나요?

역할 간 협업은 가능합니다. 다만 Worker끼리 직접 호출하거나 다음 업무를 자동 생성하지는 않습니다. 한 Worker의 결과를 사람이 검토해 다른 Worker에 새 독립 요청으로 전달할 수 있습니다. 승인된 외부 시스템을 통한 연계는 Source-only이므로 실제 제공 상태는 환경별로 확인합니다.

05Worker가 코드를 자동으로 배포하나요?

Worker는 분석과 작업을 지원하지만 공식 배포는 GitLab/CI와 승인된 운영 절차를 통해 별도로 진행합니다.

06팀의 지식이 자동으로 바뀌지는 않나요?

검색과 미리보기는 지식을 변경하지 않습니다. Runtime Knowledge 변경에는 명시적인 요청과 검증 절차가 필요합니다.

START WITH ONE WORKER

팀의 첫 번째 역할별 Worker를
설계해 보세요.

반복되는 업무, 필요한 지식과 사람의 승인 지점을 함께 정리하면 작은 범위에서 Worker Host 적용을 시작할 수 있습니다.

도입 상담 준비하기 상담 연결 채널은 정식 공개 시 제공됩니다.