OpenWorker: Andrew Ng의 오픈소스 AI 에이전트

AI 시스템이 그저 프롬프트에 답하는 것을 넘어 실제로 일을 끝내기를 바란다면, OpenWorker의 핵심을 한 줄로 요약하면 이렇습니다: 작업을 계획하고, 도구를 사용하며, 고위험 행동 전에는 승인을 위해 멈춘다.

저라면 이렇게 정리하겠습니다. OpenWorker는 데스크톱 앱과 로컬 Python 서버를 통해 실행되는 오픈소스 로컬 우선 에이전트 프레임워크로, 클라우드와 로컬 모델에 걸쳐 작업을 라우팅하고, 4단계 권한 레벨로 파일 접근, 명령 실행, 외부 메시지 전송을 제어합니다. 데이터에 대한 더 강한 통제, 여러 모델에 걸친 낮은 설정 부담, 그리고 위험한 일이 벌어지기 전 명확한 사람의 확인을 원하는 팀에 적합합니다.

간단히 요약하면 다음과 같습니다:

• 하는 일: 목표를 여러 단계로 이루어진 워크플로로 전환
• 실행 방식: Tauri 2 데스크톱 앱 + React 18 UI + 로컬 FastAPI/Uvicorn 서버
• 모델 접근: aisuite를 통한 클라우드 제공업체 및 로컬 모델, 그리고 로컬 사용을 위한 Ollama
• 안전 모델: read, write_local, exec, external
• 사람의 검토: 모든 exec 및 external 단계는 승인을 기다림
• 연동 도구: 파일, 캘린더, Slack 및 기타 팀 시스템
• 모델 엔드포인트 옵션: OpenAI 호환 단일 API를 통한 APIMart
• 가장 적합한 작업: 보고서, 리서치, 콘텐츠 패키지, 지원 업무, 미디어 파이프라인
• 프로덕션 요구사항: 트레이싱, 평가, 프롬프트 버전 관리, 지출 추적, 아웃박스 검토 플로

몇 가지 사실이 눈에 띕니다. OpenWorker는 4가지 액션 유형을 사용하고, 사람이 승인하기 전까지 exec 및 external 액션의 100%를 차단하며, 워크플로 로직을 바꾸지 않고도 GPT-5, Claude Sonnet 4.6, Gemini 3 Pro Preview 같은 모델을 오갈 수 있습니다.

우리 팀에 맞는지 판단해야 한다면, 저는 먼저 한 가지를 봅니다: 명확한 단계가 있는 반복 가능한 업무가 있고, 위험한 행동에 대해 사람의 승인이 필요한가? 그렇다면 OpenWorker는 합리적인 선택입니다.

Andrew Ng: State of AI Agents | LangChain Interrupt

OpenWorker의 작동 방식: 아키텍처, 모델, 권한

OpenWorker의 안정성은 세 가지 계층에서 나옵니다: 로컬 실행, 모델 라우팅, 승인 게이트.

데스크톱 앱과 로컬 에이전트 서버

OpenWorker는 React 18 UI를 갖춘 Tauri 2 데스크톱 애플리케이션으로 실행되며, FastAPI와 Uvicorn을 사용하는 로컬 Python 3.10+ 서버와 짝을 이룹니다. 쉽게 말해, 데스크톱에서 보이는 앱이 사용자의 컴퓨터에서 실행되는 로컬 서버와 나란히 동작합니다.

이 구성은 에이전트를 데이터와 사용자 모두에 가깝게 유지합니다. 또한 서버가 기본적으로 localhost에서 수신 대기하므로, 통제 관점에서도 상황을 더 단단하게 유지하는 데 도움이 됩니다.

클라우드와 로컬 LLM에 걸친 모델 라우팅

OpenWorker는 aisuite를 사용해 클라우드 모델 제공업체와 Ollama 같은 로컬 런타임 사이에서 요청을 라우팅합니다. 이를 통해 모든 것을 하나의 경로로 보내는 대신, 각 작업을 어디로 보낼지 팀이 결정할 여지가 생깁니다.

예를 들어 팀은 비공개 작업은 로컬에 두고, 위험도가 낮은 업무는 다른 곳으로 라우팅할 수 있습니다. 데이터가 민감하다면 Ollama를 통해 로컬 모델로 작업을 보낼 수 있습니다.

작업 계획, 유형화된 액션, 승인 게이트

OpenWorker에 목표를 주면, 그 목표를 개별 단계로 쪼개고 실행 전에 각 액션에 권한 유형을 할당합니다. 따라서 하나의 커다란 블랙박스 대신, 확인하고 검토할 수 있는 일련의 단계를 얻게 됩니다.

네 가지 권한 유형은 위험 수준에 직접 대응합니다:

승인 게이트는 사람이 승인할 때까지 모든 exec 및 external 액션을 차단합니다. 바로 이 통제 모델이 다음 계층의 연동을 실용적으로 만듭니다.

도구, 연동, 그리고 APIMart 기반 모델 접근

파일, 캘린더, Slack, 팀 시스템에 걸친 작업

OpenWorker는 내장 도구, 호스팅 연동, 커넥터를 통해 로컬 파일, 캘린더, Slack 및 기타 팀 시스템에 연결됩니다.^[4] 덕분에 일회성 작업뿐 아니라 서로 연결된 업무를 자동화하는 데도 유용합니다.

실제로는 이런 모습입니다. 운영팀이 OpenWorker에게 주간 성과 보고서를 준비해 팀과 공유해 달라고 요청합니다. 에이전트는 로컬 분석 내보내기 파일을 읽고, 공유 폴더에 잘 다듬어진 문서를 작성하며, 핵심 지표를 담은 Slack 요약본 초안을 만든 뒤, 팀 외부로 무언가를 보내기 전에 멈추고 승인을 요청합니다.^[4] OpenWorker는 조율을 담당합니다. 무엇을 내보낼지는 여전히 사람이 결정합니다.

콘텐츠 및 마케팅 팀은 콘텐츠 패키지에 동일한 구성을 사용할 수 있습니다. OpenWorker는 로컬 파일에서 원본 리서치를 가져오고, 브리프나 블로그 문서 초안을 작성하며, 팀 캘린더에 검토 마감일을 표시할 수 있습니다. 누군가 승인하기 전까지는 외부 시스템을 전혀 건드리지 않습니다.^[4]

통합 모델 엔드포인트로 APIMart 사용하기

도구가 연결되고 나면, 다음 단계는 모델 접근입니다. OpenWorker는 단일 OpenAI 호환 base URL을 통해 APIMart를 통합 모델 엔드포인트로 사용할 수 있습니다.^[2][3]

설정은 꽤 간단합니다:

• APIMart API 키 생성
• 채팅, 컴플리션, 미디어 요청에 대해 표준 OpenAI 호환 JSON 페이로드 전송

OpenWorker의 관점에서 APIMart는 하나의 안정적인 제공업체처럼 보입니다. 하지만 그 단일 엔드포인트 뒤에서, 팀은 에이전트 워크플로를 전혀 바꾸지 않고도 GPT-5, Claude Sonnet 4.6, Gemini 3 Pro Preview 같은 모델을 오갈 수 있습니다. 즉, 하나의 라우팅 계층으로 팀이 사용하는 여러 모델에 걸친 유지 관리 부담이 줄어듭니다.

콘텐츠 및 미디어 팀을 위한 멀티모달 워크플로

이와 같은 라우팅 구성은 텍스트를 넘어선 멀티모달 작업도 지원합니다. APIMart를 사용하면 OpenWorker는 하나의 엔드포인트를 통해 리서치에서 스크립트, 영상 생성까지 이어갈 수 있습니다.^[1]

매주 영상 콘텐츠를 제작하는 팀이라면, OpenWorker가 리서치, 스크립팅, 에셋 생성, 검토 준비까지 전체 파이프라인을 조율하는 동안 APIMart가 백그라운드에서 모델 선택을 처리합니다. 워크플로는 그대로 유지됩니다. 바뀌는 것은 모델뿐입니다.

프로덕션에서 OpenWorker를 안정적으로 운영하기

프로덕션 사용에는 모델, 작업, 팀에 걸친 트레이싱, 통제, 비용 가시성이 필요합니다. 이미 갖춰진 권한과 모델 라우팅 위에 세워진 이 섹션은, 그러한 기반이 실제로 작동하도록 만드는 운영 계층을 다룹니다. 다음 단계는 그 구성을 프로덕션에서 관찰하고, 감사하고, 통제할 수 있는 무언가로 바꾸는 것입니다.

트레이싱, 평가, 프롬프트 버전 관리

프로덕션 안정성은 모든 실행의 모든 단계에 대한 가시성에서 시작됩니다.

모든 에이전트 실행은 전체 실행 상태를 로깅해야 합니다: 대화 상태, 도구 입력과 출력, 사용된 모델, 토큰 수, 단계별 지연 시간. 이것이 없으면 디버깅은 추측 게임이 됩니다. 이것이 있으면 워크플로가 어디서 실패했는지 정확히 파악하고, 나머지를 건드리지 않고 그 부분만 고칠 수 있습니다.

프롬프트 버전 관리도 그만큼 중요합니다. 팀이 출력 품질을 높이려고 시스템 프롬프트를 업데이트하면, 이미 잘 작동하던 무언가를 망가뜨릴 가능성이 항상 존재합니다. 골든 테스트(예상 출력이 있는 검증된 소규모 입력 세트)를 모든 프롬프트 변경에 대해 실행하면, 프로덕션에 도달하기 전에 회귀를 잡아내는 데 도움이 됩니다. 골든 테스트는 배포 전에 프롬프트 회귀를 잡아냅니다.

민감한 행동을 위한 위험 통제와 사람의 감독

에이전트가 공유 시스템에 영향을 줄 수 있을 때, 실행에는 검토 가능한 인계 절차가 필요합니다.

민감한 행동에는 아웃박스 패턴을 사용하세요: 에이전트가 실행 전에 의도한 행동을 검토용으로 기록하는 방식입니다.^[5] 이는 공유 시스템에 적합하며, 여기서는 피해가 발생한 뒤가 아니라 실행 전에 사람의 검토가 이루어져야 합니다.

이는 앞서 설정한 exec 및 external 권한 유형과 직접 연결됩니다. 아웃박스 패턴이 이러한 고위험 행동의 최종 인계를 관장합니다. 더 복잡한 멀티 에이전트 구성에서는 inbox/, outbox/, workspace/ 디렉터리를 중심으로 짜인 폴더 구조가 데이터 경계를 깔끔하게 유지하고 인계를 예측 가능하게 만듭니다.^[5] 각 에이전트는 어디서 읽고 어디에 쓸지 알고 있어, 파이프라인을 감사하기가 더 쉬워집니다.

APIMart 라우팅을 통한 비용 및 모델 관리

워크플로가 돌아가기 시작하면, 비용 통제는 운영상의 필수 요건이 됩니다.

APIMart를 중앙 엔드포인트로 두면, 팀은 지출을 추적하고, 가격 상한을 설정하며, 지연 시간을 한곳에서 모니터링할 수 있습니다. 이미 멀티 모델 워크플로를 운영 중이라면, 중앙 집중식 라우팅은 각 제공업체별 키, SDK, 대시보드를 관리하는 부담을 줄여줍니다.

직접 키를 사용하면 비용 급증은 종종 청구 주기가 끝날 무렵에야 발견됩니다. APIMart 라우팅을 사용하면, 워크플로가 값비싼 문제로 번지기 전에 팀이 가격 상한과 라우팅 규칙을 설정할 수 있습니다.

실용적인 사용 사례와 결론

리서치, 콘텐츠 운영, 미디어 워크플로

워크플로 통제가 갖춰지고 나면, OpenWorker는 반복적이고 대량인 업무에서 특히 빛을 발하는 경향이 있습니다. 작업이 동일한 단계를 반복해서 따를 때 가장 잘 작동합니다.

그래서 마케팅, 리서치, 미디어 워크플로에 그렇게 잘 맞습니다. 팀은 프로세스의 여러 부분을 조율하고 최종 결과물을 브랜드 기준에 비추어 확인함으로써 콘텐츠 조립을 자동화할 수 있습니다. 하나의 파이프라인에서 팀은 하나의 엔드포인트를 통해 카피를 작성하고, 이미지를 생성하며, 짧은 영상을 만들 수 있습니다.

이런 구성은 리서치에서 텍스트, 이미지, 영상 생성으로 넘어가는 과정을 훨씬 매끄럽게 만듭니다. 도구들을 손으로 이어 붙이는 대신, 팀은 전체 흐름을 한곳에서 실행할 수 있습니다.

지원, 운영, 내부 업무 자동화

같은 아이디어가 내부 지원과 운영에도 이어집니다. OpenWorker는 단순한 답변 전송 이상을 할 수 있습니다. 주문 상태 확인, 비밀번호 재설정, 청구 요청 같은 일상적인 작업에 대해 답하고, 검증하고, 조치를 취할 수 있습니다.

팀 입장에서 이것이 중요한 이유는, 많은 내부 업무가 어렵지 않기 때문입니다. 그저 반복적일 뿐입니다. OpenWorker는 민감한 행동을 승인 게이트 뒤에 두면서도 그런 업무를 진척시키는 데 도움을 줍니다.

결론: 오늘 팀이 만들 수 있는 것

종합하면, 이러한 워크플로들은 지금 OpenWorker가 어디서 가장 강력한지 보여줍니다. 오픈소스 설계는 팀에게 커스터마이징, 데이터, 비용에 대한 직접적인 통제권을 줍니다. 이 구성은 로컬 우선 실행과, 일을 시작만 하는 것이 아니라 끝내는 실용적인 자동화를 중심으로 세워져 있습니다.

시작하는 현명한 방법은 단순합니다: 대량의 반복 워크플로 하나로 시작해 가치를 입증한 뒤 확장하는 것입니다.

FAQ

OpenWorker는 누구에게 가장 적합한가요?

OpenWorker는 AI를 데모에서 신뢰할 수 있는 프로덕션 준비 자동화로 옮기고자 하는 교차 기능 팀, 개발자, 사업 부서에 가장 적합합니다.

리서치, 콘텐츠 운영, 고객 지원, 비즈니스 프로세스 자동화 전반에서 여러 단계로 이루어진 워크플로를 확장하려는 팀에게 잘 맞으며, 특히 커스터마이징, 연동, 비용을 스스로 통제하고 싶을 때 그렇습니다.

OpenWorker는 민감한 데이터를 로컬에 유지할 수 있나요?

네. 오픈소스 에이전트 프레임워크는 흔히 로컬 배포를 지원하므로, 개발자는 민감한 데이터를 자신의 시스템 안에 두면서 에이전트를 구축하고 테스트할 수 있습니다.

로컬 배포 모델과 파일 기반 통신 프로토콜을 사용하면, 팀은 엄격한 데이터 경계를 유지하고 운영을 내부에 둘 수 있습니다.

팀은 어떤 작업을 먼저 자동화해야 하나요?

대량의 규칙 기반 워크플로부터 시작하세요. 가장 좋은 초기 대상은 반복적이고, 측정하기 쉬우며, 이미 CRM, ERP, 헬프데스크 같은 시스템과 연결된 작업입니다.

좋은 첫 사용 사례로는 고객 지원 분류와 인보이스 처리가 있습니다. 왜 이것들부터일까요? 큰 프로세스 개편 없이도 수작업을 빠르게 줄이고 서비스 비용을 낮출 수 있기 때문입니다.

거기서부터 팀은 문서 처리, 데이터 추출, 콘텐츠 생성으로 뻗어 나갈 수 있습니다.