이 소식을 처음 봤을 때 든 생각은 하나였다. 앤드류 응이라서 뜬 건가? GitHub 별이 공개 일주일 만에 몇 배로 뛰었다는데, 유명세 덕인지 정말 뭔가 다른 게 있는지가 먼저 궁금했다. 미리 답하자면 둘 다 조금씩 맞다. 그런데 그 “다른 것”이 생각보다 근본을 건드린다.
주인공은 OpenWorker다. Andrew Ng(앤드류 응)과 Rohit Prasad가 2026년 7월 23일 MIT 라이선스로 공개한 오픈소스 AI 데스크톱 에이전트다. 요즘 코딩 에이전트 위에 업무용 유틸 앱이 쏟아지는 흐름 한가운데 있는데, 접근이 좀 남다르다.
30초 요약
– OpenWorker는 내 컴퓨터에서 돌아가며 대화가 아니라 완성된 결과물(문서·Slack 답신·정리된 캘린더)을 내놓는 오픈소스 AI 코워커다.
– 핵심은 모델과 ‘하네스’를 떼어놓은 설계다. GPT·Claude·로컬 모델 30종을 골라 붙이고(BYOK), 데이터는 기계 밖으로 안 나가고, 제품값은 0원이다.
– 자유를 얻은 대신 성능이 고른 모델에 좌우되고, 셋업·보안 책임은 사용자 몫이라는 대가가 따른다.
OpenWorker는 뭘 하는 도구인가
OpenWorker는 사용자 컴퓨터에서 실행되면서 완성된 산출물을 손에 쥐여주는 AI 코워커다. 대화창에 그럴듯한 답을 띄우는 대신, 잘 다듬은 문서나 실제 수치가 담긴 Slack 답신, 정리된 받은편지함 같은 결과물을 직접 만들어 건넨다. 공식 사이트가 내건 문구도 “답이 아니라 결과물을 요청하라(Ask for an outcome, not just an answer)”다 (openworker.com).
작동 방식은 단순하다. 요청을 여러 단계로 쪼갠 뒤 로컬 파일과 연결된 앱을 넘나들며 일을 처리하고, 이메일 전송이나 명령 실행처럼 되돌리기 어려운 동작을 하기 전에 사람에게 확인을 받는다. Slack·GitHub·Jira·Notion·Gmail·Google Calendar를 비롯해 25종이 넘는 커넥터가 붙고, 터미널과 로컬 파일에도 직접 손을 댄다 (GitHub). 겉은 Tauri 데스크톱 앱, 속은 로컬에서 도는 Python 서버다. 코드가 약 3만 2천 줄에 이르러 잠깐 만든 장난감은 아니라는 게 MarkTechPost의 분석이다.
(Andrew Ng이 MIT 라이선스로 공개한 로컬 우선 데스크톱 AI 코워커 OpenWorker, 출처: MarkTechPost)
왜 공개 일주일 만에 이렇게 시끄러운가
화제의 이유는 한 가지가 아니라 여러 겹으로 겹쳐 있다. 가장 눈에 띄는 건 확산 속도다. GitHub 별이 공개 직후 1,700개 남짓에서 약 7,600개까지 뛰었다(집계 시점과 소스에 따라 수치 편차가 있어 대략의 규모로 보면 된다).
여기에 만든 사람의 무게가 더해진다. Andrew Ng은 DeepLearning.AI와 Coursera 강의로 전 세계 개발자에게 AI를 가르쳐 온 인물이고, OpenWorker는 그의 팀이 이미 별 1만 5천을 넘긴 LLM 라이브러리 aisuite 위에 얹혀 있다. 신뢰가 쌓인 이름이 붙으면 초기 확산 곡선이 확 가팔라진다.
마지막 한 겹이 요즘 업계가 부쩍 자주 꺼내는 단어, ‘하네스(harness)’다. OpenWorker가 흥미로운 지점이 바로 여기라서 절을 나눠 보겠다.
하네스가 대체 뭔가
하네스는 모델을 감싸서 실제로 일을 시키는 껍데기 계층을 말한다. 비유하자면 모델은 엔진이고 하네스는 그 엔진을 얹은 차체다. 아무리 힘 좋은 엔진도 차체와 바퀴, 운전대가 없으면 도로를 못 달린다. GPT나 Claude 같은 모델도 마찬가지여서, 요청을 단계로 쪼개 반복 실행하는 루프, 외부 도구를 연결하는 배선, 위험한 동작 앞의 승인 장치, 대화 맥락을 관리하는 살림을 누군가 대신 해줘야 비로소 일을 끝낸다. 그 살림꾼이 하네스다.
요즘 AI 도구를 두고 “결국 모델 싸움이냐, 하네스 싸움이냐”를 묻는 이유가 여기 있다. 이 프레이밍이 낯설다면 하네스 엔지니어링을 따로 정리한 글을 먼저 보면 감이 잡힌다. OpenWorker는 이 하네스를 통째로 열어젖힌 제품이다.
폐쇄형 코워커와 뭐가 다른가
OpenWorker의 결정적 차이는 모델과 하네스를 떼어놓았다는 데 있다. Claude Cowork나 ChatGPT Work 같은 폐쇄형 코워커는 하네스와 모델이 한 몸으로 묶여 있다. 그래서 그 회사 모델, 그 회사 클라우드, 그 회사 과금 구조에 자연스럽게 종속된다. OpenWorker는 이 묶음을 풀어 세 가지를 한꺼번에 사용자 손으로 넘긴다. 모델은 GPT·Claude·Gemini부터 DeepSeek·Qwen, 로컬 실행용 Ollama까지 30종을 작업별로 갈아 끼운다(BYOK, 사용자가 자기 모델 키를 직접 붙이는 방식). 데이터는 대화와 토큰, 키가 모두 기계에 남아 OpenWorker 서버로 실려 나가지 않는다. 비용은 MIT 오픈소스라 제품값이 0원이고 쓰는 모델의 토큰값만 낸다 (The AI Agent Index).
안전장치도 이 자유 위에서 설계됐다. 모든 도구 호출은 read(읽기)·write_local(로컬 쓰기)·exec(코드 실행)·external(외부 호출) 네 단계 위험 등급으로 나뉘고, 등급마다 승인 규칙이 다르다. 특히 shell 명령은 자동 실행 모드에서도 매번 사람 확인을 받도록 설계돼 있다. 그래서 이 제품이 던지는 진짜 질문은 성능이 아니다. “AI 에이전트는 구독 SaaS로 사서 쓴다”는 지금까지의 전제 자체를 흔든다는 점이다.
그럼 단점은 없나
자유를 얻은 만큼 넘어오는 부담도 정직하게 봐야 한다. 먼저 성능이다. 모델을 마음대로 고르는 대신 에이전트의 실력이 그 모델의 도구 사용·계획 능력에 그대로 묶인다. 힘 약한 로컬 모델을 붙이면 복잡한 작업에서 루프가 겉돌다 끝나기 쉽다.
운영과 보안 쪽도 만만치 않다. BYOK 키와 Ollama를 직접 설정해야 하는 진입 장벽이 있고, 벤더 SLA나 컴플라이언스 인증이 없으니 장애와 보안 사고의 책임이 고스란히 사용자에게 온다. 더 근본적인 건 프롬프트 인젝션 위험이다. OpenWorker는 로컬 파일 같은 민감 데이터를 읽고, 웹이나 수신 메시지 같은 외부 콘텐츠에 노출되며, 외부 도구를 호출한다. 보안 연구자 Simon Willison이 ‘치명적 삼박자(lethal trifecta)’라 부른 세 조건이 모두 성립하는 구조라, 승인 게이트가 마지막 방어선이지만 사용자가 무심코 승인 버튼을 누르면 뚫린다. 산출물 품질을 잴 표준 벤치마크가 아직 없다는 점, Windows 빌드가 미서명이라 실행 시 경고가 뜨는 점도 초기 제품의 흔적이다.
그리고 처음의 궁금증으로 돌아가 보면, 냉정한 시선도 필요하다. 로컬에서 돌고 오픈소스이며 모델을 안 가리는 조합은 사실 이번이 처음이 아니다. Open Interpreter나 Goose 같은 프로젝트가 먼저 있었지만 크게 뜨지는 못했다. 그렇게 보면 이번에 결정적으로 달랐던 한 가지는 Andrew Ng라는 이름이 붙었다는 사실일 수 있다. 설계가 남다른 것도 맞고, 브랜드가 불을 댕긴 것도 맞다.
정리 — 누가 써보면 좋을까
OpenWorker가 잘 맞는 사람은 대략 그려진다. 민감한 데이터가 기계 밖으로 나가면 곤란한 사람, 특정 모델이나 벤더에 묶이는 게 싫은 사람, 그리고 여러 도구를 오가며 반복되는 사무 작업이 많은 실무자다. 다만 셋업의 번거로움과 보안 책임을 스스로 질 각오가 서 있어야 한다. 규제가 빡빡한 데이터를 다루거나 벤더 보증이 꼭 필요한 환경이라면 아직은 조심스럽게 접근하는 편이 낫다.
브랜드가 초기 주목을 만든 건 분명하다. 그런데 주목이 걷힌 뒤에 남는 건 모델과 하네스를 분리한 설계 그 자체다. 폐쇄형 구독 코워커가 당연하게 여기던 종속 구조에 “굳이 그럴 필요가 있느냐”는 질문을 던졌고, 이 질문은 OpenWorker의 별 개수와 상관없이 계속 유효할 물음이다. 로컬 오픈소스 에이전트가 ‘가능하다’는 건 이미 증명됐다. 다음 라운드는 ‘믿고 맡길 수 있느냐’가 될 것이다.
함께 읽으면 좋은 글
