작업자와 도구의 분리

AI가 들어간 제품은 점점 많아지고 있습니다. 문서 도구는 문서를 요약하고, 모니터링 도구는 이상 징후를 설명하고, 협업 도구는 대화를 정리합니다. 그런데 사용자가 실제로 하려는 일은 여러 제품에 걸쳐 있습니다. 각각의 AI가 답을 주더라도, 그 답을 연결하고 다음 행동을 결정하는 일은 여전히 누군가 맡아야 합니다.

범용 에이전트는 이 일을 맡는 새로운 범용 작업자(에이전트) 입니다. 이 연재에서 '작업자'는 사람이 아니라 이 범용 에이전트를 가리키며, 사람은 사람이라고 부릅니다. 목표를 이해하고 여러 도구를 사용하면서 맥락을 유지하고 일을 이어갑니다. 고객은 이미 제품 바깥에서 자신의 작업자를 사용하고 있을 수 있습니다. 그 작업자는 다른 도구와 Skill을 익히며 수행 범위를 넓힙니다. 전문 소프트웨어도 자신의 기능과 사용 지식을 이 작업자에게 전달하는 방향으로 바뀌고 있습니다. 이 글에서는 그 변화를 ‘작업자와 도구의 분리’라는 관점에서 살펴봅니다. 이 글은 전문 소프트웨어와 범용 에이전트의 관계를 다루는 4편 연재의 첫 번째 글이며, 다음 글에서는 이 작업자를 조직 안에서 어떻게 운용할 것인지를 이어서 다룹니다.

업무는 제품의 경계를 넘습니다

제가 이 변화에 주목하게 된 계기 중 하나는 「Claude Blue - 실리콘밸리 전체가 우울하다」라는 글이었습니다. 제 눈길을 끈 것은 터미널에서 Claude Code와 Codex를 통해 여러 일을 이어가는 모습이었습니다. 단순한 명령 입력창이 다양한 소프트웨어를 함께 사용하는 작업 공간으로 바뀌고 있었습니다.

단순한 터미널 화면 뒤에서 에이전트는 파일을 읽고, 코드를 실행하고, 자료를 찾아 비교하고, 다른 시스템을 조회한 뒤 결과물을 만듭니다. 사용자는 같은 작업자에게 목표를 설명하고 일을 이어갑니다. 하나의 작업 주체가 여러 도구를 연결해 사용할 수 있게 된 것입니다.

운영 이상을 조사하는 상황을 생각해보겠습니다. 응답 시간이 급증했다는 알림을 받으면 지표를 확인하고, 같은 시간대의 로그를 검색하고, 배포 이력과 설정 변경을 대조해야 합니다. 과거 장애 기록이나 담당자의 대화가 단서가 될 수도 있습니다. 조사 결과는 다른 사람이 확인할 수 있는 보고서로 남겨야 합니다.

ClickHouse 같은 분석 데이터베이스와 SigNoz, Elastic 같은 관측·검색 도구는 MCP를 통해 에이전트가 데이터를 조회하고 기능을 사용하도록 지원합니다. 서비스 신뢰성을 다루는 SRE(Site Reliability Engineering) 업무에서는 이 접점들을 공통 작업 흐름으로 연결할 수 있습니다. 예를 들어 Slack에 P99 응답 시간의 이상 징후가 전달되면, Claude Code를 중심으로 구성한 작업 흐름이 지표와 로그를 조사하고 보고서를 작성해 담당자에게 검토를 요청하도록 설계할 수 있습니다.

Anthropic의 Ship your first managed agent 워크숍은 지표와 로그, 변경 이력을 조사해 데이터베이스 연결 풀 고갈을 원인으로 제시하고 대응 방안을 권고하는 시연을 보여줍니다. Managed Agents의 설계 설명과 워크숍 예제 코드에서도 이 흐름을 확인할 수 있습니다. 같은 조사 목표 아래 여러 도구에서 근거를 모으고 가설을 비교하는 작업입니다.

제품의 기능을 내장 에이전트만 사용할 수 있고 외부 작업자가 접근할 접점이 없다면, 이런 조사는 제품의 경계에서 끊기기 쉽습니다. 조사 목적은 하나인데 제품마다 다시 설명해야 하고, 한 대화창에서 얻은 결과를 다음 대화창으로 옮겨야 합니다.

각 제품이 자신의 기능과 결과를 외부 작업자에게 제공하면, 작업자는 여러 제품을 거치면서 전체 조사를 이어갈 수 있습니다. 제품은 전문 기능을 책임지고, 작업자는 어떤 기능을 언제 사용할지 판단하며 업무의 흐름을 이끕니다.

여러 도구를 사용하는 작업자

에이전트는 생각하는 머리와 실행하는 손을 함께 갖고 있습니다. 작업환경을 돌아다니면서 파일을 읽고, 명령을 실행하고, 여러 도구를 사용할 수 있습니다. 판단하는 능력과 도구를 다루는 수단을 함께 갖춘 작업자에 가깝습니다. 그래서 전문 소프트웨어와 에이전트의 관계를 설명할 때에는 작업자와 도구라는 비유가 적합합니다.

이때 도구는 자신의 전문 기능과 데이터, 상태를 제공합니다. 데이터베이스는 쿼리를 실행하고, 브라우저는 페이지를 열고 조작하며, 설계 도구는 문서와 객체를 편집합니다. 작업자는 주어진 목표를 위해 어떤 도구를 어떤 순서로 사용할지 판단하고 결과를 연결합니다.

범용 작업자는 특정 제품에 묶이지 않고 여러 도구의 사용법을 익혀 목표를 수행합니다. 도구는 그 작업자가 이용할 접점을 제공하면서 자신의 전문 기능과 내부 판단을 책임집니다. 제품 내부에도 AI와 전문 에이전트를 둘 수 있으며, 그 역할에 대해서는 뒤에서 살펴보겠습니다.

이 관계는 프론트엔드와 백엔드의 분리를 떠올리게 합니다. 서로 맡은 책임과 변화하는 이유가 다른 부분 사이에 경계를 만들고, 그 경계를 통해 결합하는 것입니다. 이 원칙은 헥사고날 아키텍처를 낳은 사고방식과도 맞닿아 있습니다. 핵심 업무 로직을 특정 화면이나 외부 기술에 묶지 않고, 사람과 다른 프로그램이 같은 기능을 각자의 접점으로 이용하도록 만드는 것입니다. 하나의 화면과 하나의 설치 패키지 안에서도 이런 분리는 가능합니다. 이 글에서 ‘외부 에이전트’는 제품의 고유 기능과 구분되는 실행 주체를 가리키며, 물리적으로 어느 서버에 배치되는지는 별도로 정할 수 있습니다.

범용 작업자의 실행 기반인 에이전트 런타임

모델이 답을 생성하는 것과 작업자가 일을 이어가는 것 사이에는 실행 구조가 필요합니다. 모델의 출력을 행동으로 연결하고, 도구의 결과를 받아 다음 행동을 정하며, 작업의 맥락과 상태를 유지해야 합니다. 이 글에서는 그 기반을 에이전트 런타임이라고 부르겠습니다. 실행 루프를 구성하는 하네스와 그 주변 기능을 포함하되, 제품마다 제공 범위와 배치 방식은 다를 수 있습니다.

Claude Code와 Codex는 파일을 읽고 쓰고, 코드를 작성하거나 실행하고, 여러 도구의 결과를 연결하는 범용 작업자입니다. 이런 능력은 개발뿐 아니라 데이터 분석과 문서 작성, 운영 조사에도 쓰입니다. OpenCode, pi, Deep Agents, Eve 등 다른 런타임도 여러 업무를 수행할 공통 실행 기반을 제공합니다.

코딩 능력이 범용적인 손이 되는 이유도 여기에 있습니다. 코드는 기존 API와 라이브러리를 호출하고, 데이터를 변환하고, 여러 단계를 조합할 수 있는 공통 수단입니다. 업무마다 새로운 전용 실행 엔진을 만들어야 했던 부분을, 이미 갖춰진 작업자에게 도구와 지식을 제공하는 방식으로 풀 수 있습니다.

이런 실행 기반은 서비스와 개발 도구로도 제공됩니다. Claude Managed Agents와 OpenAI의 에이전트 개발 도구는 모델의 응답을 여러 단계의 작업으로 연결합니다. 에이전트에 Skill, 훅과 플러그인, 도구, CI 같은 실행·검증 환경을 연결해 업무를 구성할 수 있습니다.

Anthropic은 Managed Agents의 설계를 설명하면서 에이전트의 추론과 실행을 이끄는 ‘머리’와, 도구가 실행되는 환경인 ‘손’을 분리합니다. 그 구분은 런타임을 구현하고 운영하는 아키텍처에 관한 것입니다. 제가 말하는 작업자와 도구의 구분은 업무 수행 주체와 전문 소프트웨어의 설계 경계에 관한 것입니다. 두 구분은 서로 다른 층위에서 함께 성립합니다.

OpenClaw와 Hermes는 비서 역할을, Cowork는 업무용 작업환경을 강조합니다. 사용자 경험과 운영 방식은 다르지만, 목표와 맥락을 유지하고 도구를 사용하며 일을 이어가는 실행 구조를 갖춘다는 점에서 에이전트 런타임의 관점으로 이해할 수 있습니다.

Cursor의 Lauren Tan 인터뷰는 Cursor 내부에서 봇이 자신의 실행환경과 반복 업무를 가지고 일하고, 사람이 그 결과를 검토하는 방식을 보여줍니다. 지속적인 업무를 맡는 작업자에게는 실행할 장소와 도구, 작업을 이어갈 구조가 필요합니다.

JVM이 자바 프로그램을, Python 인터프리터가 파이썬 스크립트를, Node.js나 브라우저가 자바스크립트를 실행하는 것처럼 에이전트 런타임도 그 위에 기능을 제공할 공통 기반이 됩니다. 다만 전통적인 언어 런타임과는 차이가 있습니다. 에이전트는 목표와 지침을 해석하며 실행 경로의 일부를 구성하고, 그 과정에서 작성하거나 호출하는 코드는 다시 기존 언어 런타임에서 실행될 수 있습니다.

자연어 지침도 애플리케이션을 구성합니다

실행 기반이 달라지면 그 위에 기능을 배포하는 방식도 달라집니다. 에이전트 런타임은 이미 추론과 도구 사용, 작업 진행에 필요한 공통 능력을 제공합니다. 패키지는 그 능력을 특정 업무에 쓰기 위한 목표와 절차, 제약과 판단 기준을 담을 수 있습니다.

에이전트와 Skill의 관계를 다룬 발표와 관련 짧은 영상도 범용 에이전트에 업무 지식과 도구를 결합하는 접근을 설명합니다. 여러 업무에서 공통 실행 능력을 재사용하고, 각 업무의 차이를 Skill과 도구, 규칙으로 전달하는 방식입니다.

저는 Skill이나 플러그인이 새로운 애플리케이션 패키징 방식이라고 봅니다. 방대한 코드나 바이너리를 직접 포함하지 않아도 됩니다. 자연어 지침들의 조합만으로 사용자와 에이전트가 함께 수행할 수 있는 일이 늘어난다면, 그 패키지는 새로운 작업 능력을 제공하는 것입니다.

예를 들어 보고서 검토 패키지는 사실과 가설을 구분하고, 수치의 출처를 확인하고, 누락된 근거를 찾고, 정해진 형식으로 검토 의견을 작성하도록 지시할 수 있습니다. 패키지 자체에는 자연어 지침만 들어 있더라도 에이전트의 파일 읽기와 검색, 문서 작성 능력을 이용해 하나의 기능을 제공합니다. 여기에 검증 스크립트와 참고 자료를 더할 수도 있습니다.

자연어는 실제 동작을 규정하는 코드의 역할 일부를 맡습니다. 지침의 해석과 실행은 모델과 런타임의 능력에 영향을 받으므로, 실행 결과를 확인하고 개선하는 과정도 필요합니다. 지침을 묶어 배포하고 반복해서 적용하는 일까지 소프트웨어를 구성하는 방식에 포함된 것입니다.

패키지가 얇아 보이는 것은 공통 실행 능력을 런타임이 제공하기 때문입니다. 그 안에 담긴 업무 지식이나 판단 기준까지 가볍다는 뜻은 아닙니다. MedSci Skills는 문헌 검색, 인용과 보고 지침 확인, 통계와 출판용 결과물 작성에 필요한 전문 지식을 기존 에이전트에서 사용하도록 제공하는 사례입니다. 이런 패키지는 연구자의 검토와 책임을 전제로 전문 작업을 지원합니다.

Hugging Face Skills도 모델 학습과 평가, 데이터셋 처리에 필요한 지침과 도구 사용법을 Claude Code, Codex, Gemini CLI, Cursor 같은 기존 작업자에게 제공합니다. 사용자는 익숙한 에이전트에 패키지를 더해 새로운 전문 업무를 맡길 수 있습니다. 전문 기능을 배포하는 단위가 별도의 실행 프로그램에서, 공통 런타임이 해석하고 수행할 지식과 절차의 묶음으로 넓어진 사례입니다.

이 관점에서 기능은 패키지, 런타임, 사용할 수 있는 도구의 결합으로 만들어집니다. 그래서 같은 패키지도 실행환경과 연결된 도구에 따라 수행 가능한 범위가 달라집니다. 에이전트 런타임이 새로운 소프트웨어의 실행 기반이라는 말에는 이 관계까지 포함됩니다.

개별 런타임도 이런 확장을 자신의 플랫폼 안으로 받아들이고 있습니다. Claude Code의 Mods는 플러그인에 담긴 JavaScript나 TypeScript 모듈로 세션의 이벤트와 도구 호출에 개입하고, 새로운 기능과 화면을 더할 수 있게 합니다. DeepSeek Harness는 ‘Everything is a Plugin’이라는 원칙을 내세워 하네스를 플러그인의 조합으로 구성합니다. 자연어로 업무 절차를 전달하는 Skill에서 실행 동작 자체를 확장하는 코드까지, 공통 런타임 위에 기능을 얹는 범위가 넓어지는 것입니다.

런타임 바깥에서도 작업을 다루는 환경이 등장하고 있습니다. Herdr, Orca, Paseo는 기존 에이전트를 운용하는 서로 다른 선택지입니다. Traycer와 Raven도 각자의 방식으로 실행 주체를 연결하고 작업을 조율합니다. 등장 배경에는 특정 런타임의 대화창을 넘어 작업의 배치와 진행, 결과를 다루려는 공통 요구가 있습니다.

개별 런타임은 기능을 받아들이는 플랫폼으로 발전하고, 외부의 Agent OS나 오케스트레이터는 여러 런타임을 공통 작업 단위로 다룹니다. 런타임마다 도구와 권한, 상태 관리 방식이 다르므로 같은 패키지의 실행 조건과 호환성도 확인해야 합니다. 이런 차이를 상위에서 다루는 방향은 쿠버네티스가 여러 노드의 자원과 워크로드를 공통 방식으로 다루는 것과 닮았습니다. 에이전트가 개별 전문 도구와 구분해 배치하고 관리할 단위가 된 것입니다.

소프트웨어가 에이전트를 받아들이는 여러 방식

범용 작업자는 제품 밖에서도 발전하며 다른 도구의 사용법을 익힙니다. 전문 소프트웨어는 자신의 기능과 사용 지식을 그 작업자에게 전달할 수 있어야 합니다. 지침 패키지뿐 아니라 화면과 데이터, 고유 기능을 가진 애플리케이션에도 같은 설계 과제가 생깁니다. 고객의 에이전트가 제품을 발견하고 사용할 경로를 마련하는 일입니다.

이처럼 에이전트의 사용을 고려해 설계한 제품을 ‘에이전트 친화적 소프트웨어’라고 부르겠습니다. 작업자가 일할 자리를 마련한다는 철학을 공유하면서도, 제품의 출발점과 지향점에는 세 가지 방향이 있습니다.

첫 번째는 처음부터 에이전트를 주요 작업자로 가정하는 도구입니다. pen.dev와 ego-lite를 이 관점에서 볼 수 있습니다. pen.dev의 문서는 앱 안의 통합 에이전트를 사용하는 방식과 외부 MCP 클라이언트를 연결하는 방식을 함께 설명합니다. 독립적인 디자인 문서와 편집 기능을 유지하면서 작업자를 연결하며, 공개된 연동 예제에서 그 접점을 구현하는 방법을 살펴볼 수 있습니다.

ego-lite의 공개 구현은 사람과 에이전트가 각자의 작업 공간에서 브라우저를 사용하도록 설계되어 있습니다. 에이전트는 Skill을 읽고 브라우저가 제공하는 JavaScript 도구를 사용해 페이지를 살펴보고 조작합니다. 앱과 Skill, 실행 인터페이스가 함께 하나의 사용 경험을 만듭니다. 독립적인 앱을 에이전트의 도구로 제공하면서, 사람이 같은 환경에서 계속 일할 수 있도록 설계한 사례입니다.

두 번째는 기존 전문 도구를 에이전트도 잘 사용하도록 확장하는 방향입니다. ClickHouse는 스키마 설계와 쿼리 최적화, 데이터 입력에 관한 지식을 공식 Agent Skills로 제공합니다. Arize 역시 외부 코딩 에이전트가 추적과 평가 등의 기능을 사용하도록 Skill과 MCP 접점을 제공합니다. 기능에 접근할 수 있게 하면서 그 기능을 잘 사용하는 지식도 전달하는 것입니다. QGIS MCP와 같은 시도 역시 기존 전문 소프트웨어를 에이전트의 도구로 연결한다는 관점에서 함께 볼 수 있습니다.

세 번째는 사람이 이미 일하고 있는 공간에 에이전트도 참여하게 만드는 방향입니다. Slack, Notion, Jira와 같은 협업 제품은 문서와 대화, 업무 상태가 축적되는 공간입니다. 여기에 에이전트가 참여하면 사람과 에이전트가 같은 업무 맥락을 이용하고 결과를 주고받을 수 있습니다. Slack이 제공하는 MCP와 Skills Plugin은 이런 접점의 구체적인 예입니다. 다만 패키지를 설치하는 경로와 런타임에 따라 연결 가능한 기능은 달라질 수 있습니다.

이 구분은 제품의 출발점과 지향점을 설명합니다. 에이전트 중심으로 만든 도구에도 사람이 직접 조작하는 화면이 있고, 기존 협업 플랫폼이 에이전트 실행 기능을 제공할 수도 있습니다. 한 제품이 여러 방향을 함께 택할 수 있습니다.

이들 제품이 작업자에게 기능을 전달하는 방식도 다양합니다. Skill은 마크다운 지침 하나일 수도 있고, 작은 스크립트를 포함하거나 npm 패키지를 호출할 수도 있습니다. 독립 애플리케이션의 사용법과 접근 방법을 전달하는 입구가 될 수도 있습니다. Skill·플러그인과 연동형 애플리케이션은 기능이 구현되고 전달되는 방식에 따라 하나의 사용 흐름 안에서 이어집니다.

HKUDS의 CLI-Anything도 기존 소프트웨어를 에이전트가 사용할 수 있는 명령행 접점으로 연결하려는 시도입니다. 에이전트가 이미 가진 실행 능력에 전문 도구를 연결한다는 방향을 보여줍니다.

WebMCP는 웹페이지의 기능을 설명과 입력 형식을 갖춘 도구로 공개하는 접점입니다. 브라우저와 연결된 에이전트가 이를 호출해 웹서비스를 사용할 수 있습니다. 2026년 10월 현재 W3C 커뮤니티 그룹 초안으로 논의되고 있으며 Chrome과 Edge에서 시험 적용 중입니다.

개발자는 기존 JavaScript 함수를 도구로 등록하거나 HTML 폼에 이름과 설명을 붙여 공개할 수 있습니다. 실제 동작은 사이트의 코드가 수행하고, 결과는 사람이 보고 있는 화면과 애플리케이션 상태에 반영됩니다. 일반 MCP 연동과 비교하면, WebMCP는 열려 있는 웹페이지에서 사람과 에이전트가 맥락을 공유하며 협업하는 데 초점을 둡니다.

OpenAI WebMCP Challenge의 수상작인 JupyterLite WebMCP는 기존 전문 도구에 이 접점을 추가한 사례입니다. 브라우저의 Jupyter 노트북을 읽고 수정하고 실행하는 기능을 에이전트용 도구로 제공합니다. 에이전트는 사람이 편집 중인 노트북과 데이터를 올려둔 동일한 실행 커널을 사용합니다. 출품자는 내장 LLM이나 별도의 채팅창 없이 Jupyter의 프런트엔드 확장으로 구현했다고 설명합니다.

연구 도구의 기능과 상태는 Jupyter에 남고, 사용자의 에이전트가 이를 활용합니다. 기존 화면과 업무 로직을 유지하면서 새로운 작업자에게 사용 경로를 제공한 것입니다. 이 경로를 통해 전문 소프트웨어는 더 큰 업무 흐름에 참여할 수 있습니다.

에이전트 입장에서 사용하기 좋은 도구

연결할 접점을 만드는 것에 더해, 그 접점을 에이전트가 잘 사용할 수 있도록 설계해야 합니다. 에이전트가 기능을 발견하고, 적절한 입력을 만들고, 결과를 이해하고, 실패했을 때 다음 행동을 정할 수 있어야 합니다.

JupyterLite WebMCP에서는 사용자가 선택한 텍스트를 에이전트가 읽고, 변경 결과를 해당 셀에서 확인할 수 있습니다. 사람이 먼저 내용을 수정했다면 오래된 상태를 기준으로 덮어쓰지 않도록 검사합니다. 셀 수정의 제안 모드에서는 변경 전후를 검토한 뒤 수락하거나 거절할 수 있습니다. 접점의 사용성에는 현재 상태를 정확히 읽고, 다른 참여자의 작업을 존중하며, 결과를 확인 가능하게 만드는 일까지 포함됩니다.

로그 조회에서도 반환하는 정보의 형식과 범위가 중요합니다. 수십만 줄을 그대로 돌려주면 작업자는 필요한 정보를 찾느라 많은 맥락과 연산을 소비합니다. 시간 범위와 조건으로 검색하고 관련 로그와 주변 문맥을 함께 반환하면 조사하기 쉬워집니다. 입력이 잘못됐을 때 수정할 수 있는 설명을 제공하면 다음 시도도 이어갈 수 있습니다.

Anthropic의 도구 설계 글은 이런 차이를 다룹니다. 에이전트가 수행할 업무에 맞는 기능 단위를 정하고, 관련성 높은 정보를 반환하고, 설명과 오류 메시지를 실제 사용에 맞게 다듬어야 한다는 것입니다. 도구 호출이 성공하는지와 에이전트가 그 도구로 업무를 완수하는지는 함께 확인해야 할 대상입니다.

Glean CLI는 이를 구체적으로 보여줍니다. 명령의 스키마를 조회하고, 요청을 보내기 전에 내용을 확인하고, 구조화된 결과를 다른 처리 단계에 전달할 수 있습니다. 함께 배포하는 Skill은 에이전트에게 CLI의 사용법을 알려줍니다. 검색 기능과 Glean Assistant, 내부 에이전트 실행을 같은 명령행 접점에서 사용할 수 있습니다.

이것이 작업자의 특성을 고려한 설계입니다. 에이전트는 코드를 작성해 여러 호출을 조합할 수 있지만, 작업 맥락은 제한되어 있고 모호한 설명을 잘못 해석할 수도 있습니다. 전문 기능과 함께 그 기능을 올바르게 사용하는 지식과 접점을 제공해야 작업자의 능력을 효과적으로 활용할 수 있습니다. 사람이 조작법을 배우는 데 들이던 노력의 일부를, 작업자가 읽고 활용할 수 있는 형태로 제품과 함께 제공하는 것입니다.

도구 내부의 AI와 전문 작업자

제품의 전문 기능과 업무 지식은 고객이 선택한 작업자도 사용할 수 있어야 합니다. 제품 내부의 AI 역시 이 경계를 유지하면서 맡은 책임에 맞게 설계할 수 있습니다. 정해진 기능을 수행하는 구성요소, 제품을 사용하는 기본 작업자, 위임받은 전문 업무를 처리하는 작업자로 나누어 설명하겠습니다.

첫째는 실행 순서와 분기를 명시적으로 정한 워크플로우에서 모델을 호출하는 방식입니다. 분류와 추출, 변환처럼 범위가 정해진 기능은 코드가 실행을 제어하고 필요한 단계에서 모델을 사용할 수 있습니다. 이런 구조에서는 정확도와 지연, 비용을 해당 기능에 맞춰 조정하고 검증합니다. 모델 출력의 품질은 별도로 확인해야 하지만, 매번 작업 전체를 자율적으로 계획할 필요는 줄어듭니다.

Jina Reader처럼 콘텐츠를 다른 작업자가 읽고 활용하기 좋은 형태로 반환하는 서비스도 이 관점에서 이해할 수 있습니다. 사용자나 에이전트에게 중요한 것은 입력을 주었을 때 어떤 유용한 결과를 얻는가입니다. 내부에 어떤 AI가 사용되는지는 그 기능의 정확도와 효율을 위해 선택할 구현 문제입니다.

둘째는 제품을 사용하는 기본 작업자를 함께 제공하는 방식입니다. 내장 에이전트는 화면에 편리하게 통합하고 첫 업무를 돕는 경량 컨시어지로 구성할 수 있습니다. 목표와 맥락 유지, 도구 사용 같은 공통 실행 능력과 제품 고유의 기능·업무 지식을 구분하면, 고객이 선택한 외부 에이전트도 같은 도구를 사용할 수 있습니다. 앞에서 본 pen.dev처럼 통합된 사용 경험과 외부 작업자의 접근 경로를 함께 제공하는 방식입니다.

셋째는 제품 내부의 전문 에이전트가 외부 작업자로부터 업무를 위임받는 방식입니다. 외부 작업자는 API나 CLI, MCP 등을 통해 목표와 조건을 전달하고, 내부 작업자는 한정된 도구와 권한 안에서 실행 방법을 정해 결과를 반환합니다. 이때 내부 에이전트의 자율성과 실행 구조는 맡은 전문 업무의 범위에 맞춰 설계할 수 있습니다.

연결 방식은 주고받는 대상에 맞춰 선택합니다. A2A는 에이전트 사이의 상호작용과 작업 협업을 다루고, Agent Client Protocol인 ACP는 편집기 같은 클라이언트와 코딩 에이전트를 연결합니다. 직접 조작할 도구를 제공하면서 일부 전문 업무를 내부 작업자에게 위임하도록 설계할 수도 있습니다.

Notion Custom Agents는 담당 업무와 접근 범위를 가진 내부 직원형 작업자의 사례로 볼 수 있습니다. 이런 작업자가 제품 안에서 일한다는 사실과, 외부 작업자가 그 작업자를 호출하거나 대체할 수 있다는 사실은 각각 확인해야 합니다.

Glean에서는 외부 작업자의 도구와 제품 내부의 작업자를 함께 볼 수 있습니다. 사용자는 Glean Assistant에 질문하고, 외부 에이전트는 MCP와 앞에서 본 CLI로 기업 지식에 접근하거나 Glean 에이전트를 조회하고 실행할 수 있습니다. 내부 검색 구성요소인 Waldo는 정해진 검색 도구로 근거를 모은 뒤 프런티어 모델에 제어와 맥락을 넘깁니다. 지연을 줄이기 위해 처음 실행되는 단계이며, 외부 모델이 매번 호출하는 하위 에이전트 구조와도 다릅니다. Glean 에이전트의 외부 실행 경로가 Waldo 자체의 직접 호출을 뜻하지는 않습니다.

범용 작업자는 다양한 목표와 도구를 다루는 능력, 자율성과 맥락의 지속을 중시합니다. 도구 내부의 전문 구성요소는 한정된 기능의 정확도와 지연, 비용과 자원 효율에 맞춰 설계할 수 있습니다. 작업자와 도구라는 이름은 특정 회사나 제품에 고정되지 않습니다. 목표를 받아 일을 수행하는 관계에서는 작업자이고, 다른 작업자가 기능을 이용하거나 일을 위임하는 관계에서는 도구 또는 위임 대상입니다. 이 관계에 맞춰 책임과 인터페이스를 명확히 해야 합니다.

전문 소프트웨어의 가치는 어디에 남는가

작업자가 범용화될수록 전문 소프트웨어가 무엇을 제공하는지도 더 분명해집니다. 데이터와 상태, 전문 계산, 도메인 규칙과 검증 방법은 도구에 축적됩니다. 작업자는 그 자산을 사용해 목표를 수행합니다. 도구의 사용법을 패키지로 전달할 수 있게 되면 전문 지식이 활용되는 경로도 넓어집니다.

Claude Science는 범용적인 실행 능력과 분야별 자산을 결합한 사례입니다. 공개 설명에는 범용 조정 에이전트, 과학 분야의 Skill과 커넥터, 연구 도구와 계산환경이 함께 등장합니다. 결과물에는 코드와 환경, 작업 이력을 연결해 검토와 재현을 돕습니다. 이런 내부 역할 분리와 외부 에이전트 런타임을 자유롭게 연결하는 개방성은 각각의 설계 조건입니다.

Synopsys가 설명하는 Lane 3는 지능형 실행 기반과 전문 도구를 분업하는 방향입니다. OpenAI가 모델·연산·서비스 계층을 맡고 Synopsys의 도구와 전문 자산을 결합합니다. 공식 협력 발표는 EDA 도구 사용에 특화한 모델을 개발하고 고객의 에이전트 하네스와 상호운용하도록 설계할 계획도 설명합니다.

전문 소프트웨어의 핵심 자산은 도구와 데이터, 업무 절차에 축적되어야 합니다. 특정 분야에 맞춘 모델과 에이전트의 개선도 이 구조 안에서 가능합니다. 도구를 잘 쓰는 모델과 전문 도구가 각각 발전하면서 결합할 수 있도록 경계를 만드는 것이 중요합니다.

ML Intern은 Hugging Face의 논문과 데이터셋, 연산 자원을 활용해 ML 연구와 코드 작성·실행을 수행하던 에이전트입니다. 전문 업무 로직을 자체 에이전트의 실행 루프와 맥락 관리에 결합해 제공했습니다. 저는 이 강결합이 분명한 설계 실수라고 봅니다.

기존 작업자가 사용할 수 있는 도구와 업무 절차로 제공할 전문성을, 별도 작업자의 채택과 묶어버렸기 때문입니다. 사용자는 전문 기능을 쓰기 위해 별도의 에이전트 환경을 받아들여야 하고, 공급자는 전문 기능뿐 아니라 범용 런타임의 역할까지 유지해야 합니다. 이미 Claude Code나 Codex로 일하는 사용자에게 필요한 것은 자신의 작업자가 연구 도구와 실행환경을 능숙하게 활용하는 능력입니다. ML Intern은 그 능력을 제공하면서 작업자까지 다시 선택하도록 요구했습니다.

ML Intern의 저장소는 2026년 9월 29일 보관 처리됐고, 종료 안내는 기존 웹 앱과 CLI의 운영 종료와 함께 후속 이용 경로로 HuggingChat을 제시합니다. 저는 이 종료에서도 전문 기능의 제공을 특정 실행 제품의 존속과 묶은 설계의 취약성이 드러났다고 봅니다.

반면 같은 생태계의 전문성을 기존 작업자에게 전달하는 Hugging Face Skills는 계속 제공되고 있습니다. 2026년 10월 4일 기준 공식 저장소는 약 1만 1천 개의 GitHub 스타를 확보했고, 공식 CLI의 권장 설치 경로에도 에이전트용 Skill의 배포가 통합되어 있습니다. ML 연구를 돕는 전문성에 대한 수요와 별도의 연구 에이전트 런타임에 대한 수요는 같지 않습니다. 전문 소프트웨어는 이 차이를 제품 설계에 반영해야 합니다.

Feynman의 skills-only 배포 역시 자체 터미널 앱이나 런타임 없이 연구 스킬을 기존 에이전트에 연결하는 경로를 제공합니다. 전문 에이전트를 표방하는 제품이라도 전문 기능을 독립적으로 전달할 수 있습니다. 도메인 지식과 업무 로직을 자산으로 만들고, 고객이 선택한 작업자가 그 자산을 사용하도록 제공하는 것이 중요합니다.

공급자에게는 자신의 전문 기능을 어떤 작업자들이 사용할 수 있게 할지, 그 작업자가 능숙하게 일하도록 무엇을 제공할지가 제품 설계의 일부가 됩니다. 독립 앱, Skill, 플러그인, MCP, CLI와 WebMCP는 이 선택을 구현하는 여러 형태입니다.

작업자와 도구가 각각 발전할 수 있도록

범용 에이전트가 사용할 수 있도록 제품을 설계하면 세 가지 이점을 기대할 수 있습니다.

첫째, 사용자가 제품별 조작법을 익히는 부담을 줄일 수 있습니다. 제품의 기능과 제약, 오류에 대응하는 방법을 에이전트가 읽고 사용할 형태로 제공하면, 사용자는 원하는 일을 설명하고 결과를 검토하는 데 집중할 수 있습니다.

둘째, 여러 도구를 가로지르는 업무를 같은 작업자에게 맡길 수 있습니다. 전문 모니터링 제품과 Elastic, 셸, Slack을 사용하는 작업자는 지표와 로그, 변경 이력과 대화를 연결해 조사합니다. 제품마다 분리된 대화창에서 결과를 복사해 옮겨야 한다면 사용자는 에이전트 사이의 우편배달원이 됩니다. 공통 접점을 제공하면 작업자가 맥락을 유지하며 전체 조사를 이어갈 수 있습니다. 실제 연동에서는 데이터 형식과 권한, 업무 의미를 맞춰야 하지만, 각 제품이 다른 모든 제품과의 조사 절차를 개별적으로 구현할 부담은 줄어듭니다.

셋째, 작업자와 도구가 각각 발전한 결과를 함께 활용할 수 있습니다. 에이전트의 배치와 운용을 제품의 전문 기능과 구분하면, 고객은 자신의 업무에 맞는 작업자와 자원을 선택하고 제품의 기능을 계속 사용할 수 있습니다. 공급자는 전문 기능과 사용 지식에 역량을 집중하면서 범용 런타임의 개선을 활용할 수 있습니다.

공급자는 범용 에이전트가 사용할 도구를 만들고, 고객이 그 작업자를 운용할 환경을 갖추도록 도울 수 있습니다. 환경이 없는 고객에게는 같은 제품 접점을 사용하는 내장 에이전트를 함께 제공합니다. 고객의 실행환경이 달라져도 전문 기능과 업무 지식을 계속 활용할 수 있도록 설계하는 것입니다.

사람에게 화면과 사용법을 제공해왔듯, 에이전트에게도 기능과 사용 지식, 실행 결과를 제공해야 합니다. 자연어 지침과 실행 패키지, 독립 애플리케이션은 그 결합을 전달하는 여러 형태입니다. 제품의 전문성이 고객이 선택한 작업자에게 계속 전달되고, 더 큰 업무 흐름에 참여할 수 있어야 합니다.

그러면 다음 질문은 조직으로 이어집니다. 여러 도구를 사용하는 이 작업자를 조직의 맥락과 권한 안에서 어디에 두고 어떻게 운용할 것인가. 다음 글에서는 분리망을 포함한 모든 조직이 범용 에이전트의 실행 기반을 갖추어야 한다는 주장을 다루겠습니다.