모든 조직은 에이전트 실행환경을 가져야 한다

“모든 조직은 Claude Code를 가져야 한다.”

여기서 Claude Code는 목표를 받아 여러 도구를 사용하며 일을 이어가는 범용 에이전트 런타임을 뜻합니다. 저는 인터넷 서비스를 자유롭게 쓰는 조직이든 분리망을 가진 조직이든, 결국 이런 런타임을 업무환경의 기본 구성요소로 갖추게 될 것이라고 생각합니다. 사람이 에이전트에게 일을 맡기고, 에이전트는 그 사람의 작업환경에서 여러 도구를 사용하는 방식입니다.

이 글은 연재의 2편입니다. 1편에서는 에이전트를 여러 도구를 사용하는 범용 작업자(에이전트)로 바라보았습니다. 소프트웨어는 이 작업자가 자신의 기능과 데이터를 이용할 수 있도록 접점을 마련하고, Skill과 플러그인은 작업자가 수행할 수 있는 일을 확장합니다. 이 변화는 분리망 안에서도 이어질 것입니다. 기업용 소프트웨어 역시 고객이 범용 에이전트를 운용한다는 전제에서 설계해야 합니다.

저는 범용 에이전트를 이용한 업무 자동화와 조직화가 보편적인 작업 방식이 될 것이라고 생각합니다. 고객 조직의 구성원들도 이미 외부망에서 Claude Code 같은 도구를 사용하며 그 가능성을 경험하고 있으리라고 보고 있습니다. 그들이 내부 업무에서도 기대할 것은 익숙해진 작업 방식을 실제 코드와 데이터, 사내 시스템에 적용하는 능력입니다.

그 작업 방식의 중심에는 사용자의 로컬 PC에서 작동하는 에이전트가 있을 것이라고 봅니다. 사람이 이미 일하고 있는 폴더와 개발환경, 문서와 도구 가까이에서 에이전트가 함께 일할 수 있기 때문입니다. 일상 업무에서는 이 편의성과 작업환경과의 짧은 거리가 큰 우위를 가집니다.

분리망에서도 기본 구조는 같습니다. 내부 업무용 PC에 범용 에이전트 런타임이 있고, 그 작업자가 조직의 모델과 도구를 사용하며 일을 수행하는 것입니다. 망과 인증, 모델 공급과 실행 권한의 차이는 이 구조를 어떻게 구현할지에서 다룰 문제입니다. 외부에서 이미 경험한 작업 방식을 내부에서도 가능하게 만드는 것이 도입의 출발점입니다.

여러 도구를 사용하며 일을 이어가는 공통 기반

조직의 업무는 미리 정한 절차만으로 채워져 있지 않습니다. 어제까지 없던 문제가 생기고, 새로운 자료를 기존 자료와 대조해야 하며, 서로 다른 시스템의 결과를 연결해야 합니다. 반복되는 부분은 자동화할 수 있지만, 달라진 상황을 해석하고 다음 행동을 정하는 일은 계속 남습니다.

예를 들어 운영 담당자가 “이번 주에 처리 시간이 길어진 이유를 조사해달라”고 요청했다고 해보겠습니다. 데이터베이스에서 지표를 조회하고, 배포 이력을 살피고, 로그와 설정을 비교해야 합니다. 필요하면 짧은 스크립트를 만들어 데이터를 가공하고, 가설을 검증한 뒤 근거와 함께 보고서를 작성합니다. 기존 시스템의 기능을 쓰면서도, 그 기능을 어떤 순서로 조합할지는 조사 과정에서 달라집니다.

이런 일을 수행하는 기반이 Claude Code와 같은 범용 에이전트 실행환경입니다. 목표를 받아 맥락을 유지하고, 파일을 읽고 쓰고, 코드를 작성하거나 실행하고, 여러 도구의 결과를 연결합니다. 코딩 능력은 새로운 프로그램을 만드는 데 그치지 않고, 이미 존재하는 소프트웨어를 다루는 범용적인 손이 됩니다.

모델에 질문할 수 있는 사내 채팅창도 유용합니다. 여기에 실제 업무를 맡기려면 실행 구조가 더 필요합니다. 작업할 공간, 사용할 도구, 중간 결과를 남길 곳, 실패했을 때 다시 시도하거나 사람에게 넘기는 방식이 갖춰져야 합니다. 답변이 끝나는 시점과 일이 끝나는 시점은 다르기 때문입니다.

계산과 분류, 정해진 승인 절차처럼 기존 프로그램과 명시적인 워크플로우가 잘 처리하는 일은 계속 그 방식에 맡길 수 있습니다. 범용 실행 기반은 상황에 따라 여러 기능을 조합해야 하는 일을 담당하고, 필요할 때 그 프로그램과 워크플로우를 도구로 사용합니다.

이 기반을 갖추면 새로운 업무를 만날 때마다 실행 엔진부터 다시 만들 필요가 줄어듭니다. 같은 작업자에게 새로운 도구와 업무 지식을 제공하고, 수행 범위와 완료 조건을 정할 수 있습니다. 조직에 범용 에이전트가 필요하다는 주장의 중심은 이 재사용 가능성에 있습니다.

에이전트의 주된 자리는 사용자의 PC입니다

저는 일상 업무를 수행하는 에이전트의 주된 실행 장소가 사용자의 로컬 PC가 될 것이라고 봅니다. 그곳에는 이미 작업 중인 파일과 코드 저장소, 설치된 프로그램과 개발환경이 있습니다. 사람은 그 환경에서 일을 시작하고, 중간 결과를 확인하고, 직접 수정합니다. 에이전트도 같은 환경에서 허용된 범위의 파일과 도구를 다룰 수 있다면 사람과 작업을 주고받는 거리가 짧아집니다.

이 편의성은 단순히 실행 속도의 문제가 아닙니다. 자료를 별도의 작업 공간에 옮기고, 두 환경의 상태를 맞추고, 결과를 다시 가져오는 과정이 줄어듭니다. 사용자는 지금 보고 있는 코드와 문서에 대해 일을 맡기고, 에이전트가 만든 파일이나 변경 사항을 평소 도구로 확인할 수 있습니다. 일상적으로 수많은 작은 작업을 맡길수록 이 차이는 커집니다.

분리망 조직에서도 이 장점은 그대로입니다. 내부 업무용 PC에 코드와 문서가 있고, 그 PC에서 사내 시스템을 사용하고 있다면 에이전트 역시 그 작업환경 가까이에 두는 것이 자연스럽습니다. 에이전트가 사용할 수 있는 파일과 명령, 시스템 접근 범위는 조직의 정책과 사용자의 업무 권한에 맞게 정해야 합니다.

로컬 PC에서 에이전트를 실행한다는 것은 모델 추론까지 그 PC에서 처리한다는 뜻은 아닙니다. 런타임은 사용자의 PC에서 맥락을 관리하고 도구를 실행하면서, 모델 호출은 조직이 제공하는 내부 추론 서버나 허용된 서비스로 보낼 수 있습니다. 로컬의 작업 편의성과 조직 차원의 모델 공급을 결합하는 구조입니다.

서버나 클라우드의 실행환경은 야간 작업, 예약된 반복 업무, 장시간 실행과 팀 공용 자동화에 활용할 수 있습니다. 이런 실행환경을 함께 갖추더라도 사람이 수시로 일을 맡기고 개입하는 일상 업무에서는 자신의 PC에 있는 에이전트가 중심이 될 것이라고 봅니다. 공통 운용 기반은 그 작업자가 조직의 자원을 잘 활용하도록 뒷받침해야 합니다.

개인의 사용 경험이 조직의 작업 방식으로 이어집니다

이 변화의 단서는 이미 여러 조직에서 나타납니다. Anthropic이 공개한 내부 연구는 2025년 8월 엔지니어와 연구자 132명을 설문하고, 53명을 심층 인터뷰했으며, 내부 Claude Code 사용 기록을 분석했습니다. 보안팀은 익숙하지 않은 코드를 분석하고, 연구자는 데이터 시각화용 화면을 만드는 등 같은 실행 기반이 서로 다른 전문 업무를 보조하는 모습을 보여줍니다.

이 연구는 AI를 만드는 회사 내부의 사용 경험을 다루며, 생산성 수치에는 자기보고가 포함되어 있습니다. 제가 주목하는 것은 사람이 결과를 확인하고 수정하면서도 자신의 전문 영역을 넘어 더 넓은 범위의 일을 수행하게 되었다는 점입니다.

Elena Verna가 설명한 Lovable의 업무 방식에서도 공유된 맥락이 중요합니다. 회사의 지식 기반을 통해 어떤 일이 있었는지뿐 아니라 왜 그렇게 결정했는지를 찾아볼 수 있고, 마케팅과 분석, 코드베이스를 다루는 여러 에이전트가 일상 업무에 참여합니다. 저는 여기서 개인이 가진 능력을 조직이 함께 쓰려면 실행 도구와 함께 업무 맥락을 제공해야 한다는 점을 봅니다.

1편에서 살펴본 Cursor 내부의 봇 활용과 Anthropic의 운영 조사 시연도 사람의 요청을 받은 에이전트가 여러 도구를 사용하며 일을 이어가는 모습입니다. 조직과 적용 범위는 다르지만, 저는 이런 작업 방식이 AI를 먼저 도입한 조직을 넘어 일반적인 업무환경으로 확산될 것이라고 생각합니다.

조직마다 도입 속도와 방식은 다를 것입니다. 어떤 조직은 개인 작업부터 시작하고, 어떤 조직은 팀이 함께 사용하는 반복 업무부터 시작할 수 있습니다. 활용이 늘어나면 각자의 PC에서 쌓인 유용한 설정과 Skill, 도구 사용법을 조직의 공통 자산으로 관리하고 배포할 필요가 생깁니다. 개인의 작업환경 가까이에서 실행하면서 조직의 지식과 운영 기준을 함께 사용하는 방향입니다.

같은 작업 방식을 내부망에서 구현합니다

분리망 조직에서도 내부 업무용 PC에 범용 에이전트 런타임을 배치하고, 그 PC에서 다루는 코드와 문서, 접근이 허용된 사내 시스템을 연결할 수 있습니다. 사용자는 평소 작업하던 환경에서 목표를 설명하고, 에이전트는 자료를 읽고 도구를 사용하며 결과를 만듭니다. 내부망 구축의 과제는 이 익숙한 흐름을 끝까지 이어주는 데 있습니다.

구현할 때는 사용자가 조작하는 화면, 에이전트 런타임, 모델 추론의 위치를 구분해야 합니다. 기본 구성에서는 화면과 런타임이 사용자의 PC에 있고, 모델은 내부 추론 서버나 조직이 허용한 서비스에서 실행됩니다. 어떤 도구는 PC에서 실행되고, 다른 도구는 사내 시스템의 API를 통해 호출됩니다. 이 경로를 따라 어떤 데이터가 이동하는지 확인해야 실제 망 경계에 맞게 구성할 수 있습니다.

팀 공용 자동화나 장시간 작업에는 내부 서버와 프라이빗 클라우드의 실행환경을 더할 수 있습니다. 사용자의 PC는 대화와 수시 작업을 맡고, 지속적인 실행이 필요한 업무는 공용 작업 공간에서 수행하도록 역할을 나누는 것입니다. 공통으로 관리할 대상이 늘어나더라도 일상적인 작업의 중심을 사용자 가까이에 둘 수 있습니다.

조직의 조건에 따라 허용된 외부 추론 서비스를 이용할 수도 있고, 모델 가중치와 서빙 시스템까지 내부에 배치해야 할 수도 있습니다. 후자의 경우에는 런타임만 설치해서 끝나지 않습니다. 모델과 실행 패키지, 도구의 의존성을 내부에서 확보하고, 업데이트와 운영도 그 경계 안에서 이어갈 수 있어야 합니다. ‘자체 호스팅이 가능하다’는 설명 역시 어디까지 자체 호스팅하는지 확인해야 의미가 있습니다.

Anthropic의 한국 사업 발표는 삼성전자 구성원들이 Claude Code와 Cowork 등을 활용하고 있다고 설명합니다. 보안 요구가 높은 기업에서도 범용 에이전트를 업무에 사용하는 사례가 나타나고 있습니다.

kt cloud는 2026년 9월 1일 열린 KCD x Ceph x OpenInfra Day Korea 2026에서 ToolHive를 활용한 MCP 운영 경험을 발표했습니다. 발표 소개는 구축 과정의 경험과 시행착오를 다루며, 조직이 MCP를 함께 쓰기 위한 신원, 권한, 자격증명과 운영을 주요 과제로 제시합니다.

이 사례들은 기업도 범용 에이전트를 사용하고, 도구를 함께 쓰기 위한 운영 기반을 마련하고 있다는 점을 보여줍니다. 저는 분리망 조직도 같은 방향으로 갈 것이라고 봅니다. 다만 위 사례가 특정 분리망 구성을 검증한 것은 아니므로, 실제 구축에서는 모델 추론과 도구 실행의 위치, 데이터가 오가는 경로를 확인해야 합니다.

같은 작업 구조를 갖추더라도 모델과 연산 자원의 차이에 따라 수행 능력은 달라질 수 있습니다. 내부 자원이 제한된다면 맡길 수 있는 업무의 범위와 결과의 품질을 실제로 확인해야 합니다. 적절한 도구와 맥락을 제공하고 결과를 검증하면서 활용 범위를 정할 수 있습니다. 공통 실행 기반을 갖춰두면 이후 모델과 인프라가 개선될 때, 이미 연결한 업무와 도구에도 그 개선을 적용할 수 있습니다.

제품은 조직의 에이전트가 사용한다는 전제로 설계합니다

고객이 결국 범용 에이전트를 쓰게 된다는 전망은 지금 무엇을 납품할지에 영향을 줍니다. 분리망 고객에게 아직 그런 환경이 없더라도, 제품은 고객의 작업자가 사용할 전문 도구로 설계해야 합니다. 현재의 도입 공백을 이유로 제품마다 독립된 작업자와 업무 맥락을 만드는 방향을 기본값으로 삼아서는 안 됩니다. 필요한 경우 제품과 함께 범용 실행 기반을 마련할 수 있습니다.

실행환경이 있는 조직이라면 사용자는 자신의 PC에서 쓰는 에이전트에 제품을 연결할 수 있어야 합니다. 사용할 기능과 입력 형식, 필요한 권한, 결과의 의미를 제공하고, 제품을 잘 쓰는 절차는 Skill이나 플러그인으로 전달합니다. 에이전트가 기능을 발견하는 것부터 결과를 확인하는 것까지 제품의 사용 경험에 포함됩니다.

실행환경이 없는 조직이라면 첫 제품을 도입할 때 업무용 PC에 호환되는 런타임을 배포하고, 필요한 모델과 도구 연결을 함께 마련할 수 있습니다. 이때 함께 제공한 에이전트가 다른 도구도 사용할 수 있고, 제품도 이후 다른 에이전트와 결합할 수 있어야 합니다. 첫 도입이 다음 제품을 연결하는 출발점이 되는 것입니다.

제품 내부의 AI와 전문 에이전트도 이 구조 안에 남습니다. 검색 계획을 최적화하거나 특정 분석을 수행하는 전문 구성요소는 제품 안에서 동작할 수 있습니다. 조직의 작업자는 그 기능을 호출하거나 업무를 위임합니다. 1편에서 설명한 작업자와 도구의 구분을, 고객 조직의 배치와 운영 조건에 적용하는 셈입니다.

Synopsys가 Investor Day에서 제시한 Lane 2는 고객이 자신의 모델과 에이전트로 Synopsys의 도구를 이용하고, 필요하면 Synopsys의 에이전트도 함께 사용하는 공급 방향입니다. 저는 여기에서 고객이 가진 작업 기반을 제품의 설계와 사업 모델 안에 받아들이는 선택을 봅니다. 공급자는 전문 도구와 필요한 실행 자산을 제공하고, 구체적인 연동 범위와 호환성은 고객 환경에 맞춰 확인할 수 있습니다.

따라서 제품의 납품 단위도 전문 기능과 그 사용법, 연결 방식, 검증 수단을 함께 포함하게 됩니다. 실행환경과 제품을 함께 공급하더라도 각각의 책임과 교체 가능한 경계를 유지하는 것이 중요합니다.

로컬 런타임을 조직의 운용환경으로 연결합니다

한 사람이 자신의 컴퓨터에서 에이전트를 실행할 때는 어느 폴더에서 일하는지, 어떤 계정으로 접속해 있는지, 무엇을 바꿔도 되는지와 같은 조건을 직접 조정할 수 있습니다. 여러 사람이 각자의 PC에서 작업자를 운용하면 이 조건들을 조직의 기준으로 다룰 필요가 생깁니다. 로컬에서 실행되는 런타임에 공통 도구와 정책, 업무 자산을 전달하고, 그 실행을 확인할 수 있어야 합니다.

조직의 운용환경은 사용자의 요청을 목적과 완료 조건이 분명한 작업으로 구체화하고, 조직의 맥락과 권한 안에서 실행하도록 지원해야 합니다. 티켓이나 작업 명세에 범위와 조건을 남기고, 여러 도구를 거친 결과와 검증 근거를 모아 일을 마칠 수 있어야 합니다. 이런 공통 기준은 각 PC의 에이전트와 서버에서 실행되는 작업자에 함께 적용할 수 있습니다.

개별 도구는 자신의 데이터와 기능에 대한 권한을 검사하고 요청의 유효성을 확인합니다. 공통 운용환경은 여러 제품에 걸친 작업의 범위와 진행을 관리합니다. 두 계층이 각자의 경계를 지키면서 요청자의 신원과 허용 범위를 일관되게 전달해야 합니다.

이 글에서 Agent OS나 메타 하네스는 서로 다른 런타임 위에서도 조직이 업무를 같은 기준으로 맡기고 확인하도록 만드는 상위 운용 계층을 가리킵니다. 개별 런타임이 판단과 도구 호출을 이어간다면, 조직의 운용환경은 그 작업이 누구의 요청으로 시작됐고 어떤 조건에서 끝나야 하는지를 함께 관리합니다. 각 PC와 공용 서버에 배치된 작업자들을 이 계층에서 연결하고 운용할 수 있습니다.

이 요구는 에이전트를 쓰는 업무가 늘어날수록 구체화됩니다. 요청을 어느 작업자에게 맡길지, 여러 작업을 어떻게 나누고 결과를 합칠지, 기다리거나 중단된 일을 어디에서 이어갈지를 다루어야 합니다. 특정 런타임에서 시작하더라도 업무의 목적과 상태, 완료 근거를 그 구현과 구분해 관리할 필요가 생깁니다. 런타임을 추상화하고 작업을 오케스트레이션하는 일은 조직의 업무를 지속적으로 운영하기 위한 과제가 됩니다.

1편에서 살펴본 외부 작업환경들의 등장은 이런 수요의 한 단면입니다. 개별 런타임이 플러그인과 확장 기능을 늘려가더라도, 조직은 여러 런타임에 공통 기준을 적용하고 도구와 업무 자산을 함께 사용해야 합니다. 조직의 운용환경은 런타임의 기능을 활용하면서도, 특정 제품의 지원 범위와 출시 일정에 모든 업무를 의존하지 않도록 경계를 마련합니다.

사용자의 PC에서 에이전트를 실행하면서도 인증, 승인된 모델과 도구, Skill 배포, 실행 기록과 비용 관리는 공통 기반으로 제공할 수 있습니다. 접근 권한은 각 도구와 시스템에서도 실제로 검사해야 합니다. 조직이 공유할 기준과 서비스를 정하고, 개인의 수시 작업과 팀의 지속적인 작업에 맞춰 실행 위치를 나누는 구성입니다.

팀 공용 자동화와 격리된 장시간 실행을 구성할 때 참고할 시도도 나타나고 있습니다. 핵심 개념과 사양을 개발 중인 Google의 AX는 작업과 작업 공간, 모델을 선언하고 격리된 실행을 배치하는 방향을 제시합니다. OpenHands는 에이전트 실행과 작업 공간을 다루는 서버, 브라우저 클라이언트, 자동화와 샌드박스 등을 구분합니다. 이런 실행환경은 개인 PC에서 수행하는 업무와 함께 조직의 운용 범위에 들어올 수 있습니다.

신뢰된 환경에서 시험하기 위한 엔지니어링 프리뷰인 OpenAI의 Symphony는 이슈를 작업으로 받아 격리된 실행을 시작하고, CI 상태와 리뷰 결과 등 근거를 모아 사람이 검토하는 흐름을 제시합니다. Salix의 공식 설명에서는 에이전트의 지속적인 실행과 컴퓨터가 필요한 작업을 구분하고, 외부 런타임을 이용하는 방식도 다룹니다. 각 프로젝트의 범위와 성숙도는 다르지만, 작업자를 하나의 터미널 세션보다 넓은 단위로 운용하려는 시도를 보여줍니다.

쿠버네티스와의 비유는 작업의 조건을 특정 실행 장소와 분리해 표현한다는 점에서 유용합니다. 애플리케이션에 필요한 자원과 실행 조건을 표현해 배치하는 것처럼, 에이전트의 작업도 사용할 런타임과 권한, 완료 조건을 명시해 상위에서 다룰 수 있습니다. 실제 실행은 업무 성격에 맞춰 사용자의 PC나 공용 실행환경에 배치합니다. 모델이나 런타임을 바꿨을 때 작업 능력과 권한 처리, 상태 유지가 같아지는 것은 아니므로, 공통 계약과 실제 호환성을 함께 확인해야 합니다.

조직의 맥락과 완료 근거가 실행 능력을 만듭니다

운용환경에 모델과 도구를 연결해두어도 에이전트가 우리 조직의 일을 바로 잘하는 것은 아닙니다. 어떤 자료를 우선해야 하는지, 같은 용어가 어느 업무에서 어떤 뜻인지, 요청자가 말하는 완료가 무엇인지를 알아야 합니다. 사람은 동료와 대화하고 과거 결정을 기억하면서 이 맥락을 얻습니다. 에이전트에게도 이를 전달할 경로가 필요합니다.

Cursor의 Lauren Tan이 설명한 feature map은 그 간극을 잘 보여줍니다. 에이전트가 앱을 실행하고 화면을 조작할 수 있어도, 사용자가 말하는 기능이 어디에 있고 어떻게 접근하는지 모르면 시간을 낭비합니다. 기능과 화면의 관계, 접근 경로를 알려주는 자료를 제공해야 모호한 사용자 제보를 실제 확인 작업으로 연결하기 쉬워집니다.

그 지식을 한 사람의 대화에만 남겨두기보다, 반복해서 사용할 수 있는 업무 자산으로 관리할 수 있습니다. 데이터 조회 절차, 장애 조사 순서, 보고서 검토 기준, 제품별 사용법을 Skill과 문서, 스크립트로 묶는 것입니다. 누가 관리하며 어떤 버전이 검증되었는지도 함께 알 수 있어야 합니다.

Agent Registry는 MCP 서버와 에이전트, Skill과 프롬프트를 조직이 발견하고 배포할 수 있는 카탈로그로 다룹니다. Skillport는 Skill을 CLI와 MCP를 통해 여러 에이전트에 제공하는 방향을 취합니다. Tessl과 TrueFoundry의 Skills Registry도 재사용할 지침과 패키지를 관리하는 사례입니다. 지식을 한 번 작성하는 데서 그치지 않고, 필요한 작업자에게 전달하고 변경을 관리하는 일이 운용환경의 일부가 됩니다.

작업 자체의 상태도 대화와 별도로 남아야 합니다. 누군가 검토를 요청했는데 아직 답을 받지 못했는지, 추가 자료가 도착해 다시 시작할 수 있는지, 실제로 완료되었는지는 채팅 메시지의 생성 여부만으로 판단하기 어렵습니다.

WorldLoops는 다른 에이전트가 읽어온 신호를 바탕으로 아직 해결되지 않은 일을 추적하고, 제안과 승인, 상태 전이와 기록을 다루는 사례입니다. 공개 저장소의 구현은 외부 시스템에 직접 쓰는 동작과 로컬 상태 전이를 구분합니다. Ouroboros는 요청을 명세로 구체화하고 실행과 평가를 기록하며, 여러 에이전트 런타임에 공통 작업 흐름을 연결합니다. 두 사례에서 주목할 점은 업무 상태와 수행 조건을 지속적으로 관리해 대화 세션이 바뀌어도 일을 이어가도록 한다는 것입니다.

완료 근거를 만드는 도구도 중요합니다. 토스 프론트엔드 개발자들의 검증 사례에서는 테스트를 위한 API, 실제 기기를 다루는 디바이스 팜, 로그와 실패 장면을 확인하는 리플레이가 함께 등장합니다. 에이전트가 검증할 수 있도록 주변 환경을 마련하는 작업이 필요한 것입니다. 좋은 검증 지침을 쓰는 것과 실제로 검증 가능한 환경을 갖추는 것은 함께 가야 합니다.

권한에도 같은 원칙이 적용됩니다. “허용된 데이터만 읽어라”는 자연어 지침과, 그 범위를 시스템에서 실제로 제한하는 것은 다른 역할입니다. 조직의 작업자는 요청자의 권한과 업무상 허용 범위 안에서 도구를 사용해야 하고, 결과를 남길 때도 그 결과를 볼 수 있는 사람의 범위가 이어져야 합니다.

그리고 이 기반을 관리할 사람이 필요합니다. Lovable이 말하는 ‘agent parent’는 에이전트 결과의 품질을 책임지고 지식을 갱신하며 잘못된 답변을 교정하는 사람입니다. 조직이 에이전트를 운용한다는 말에는 누군가 이 책임을 맡는다는 뜻도 포함됩니다. 실행 횟수가 늘어날수록 어떤 업무 자산과 환경을 고쳐야 하는지 판단하는 역할이 중요해집니다.

내부 실행 기반을 제공하는 일도 전문성이 됩니다

조직은 보유한 역량에 따라 실행환경을 직접 구축하거나 외부의 도움을 받아 도입하고 관리할 수 있습니다. 고객이 외부망에서 경험한 작업 방식을 내부 업무용 PC에서도 사용할 수 있도록 만드는 일이 출발점입니다. 여기에 모델 공급과 도구 연결, 공통 운영을 갖추어 실제 업무까지 이어주는 일이 전문적인 사업이 될 수 있습니다.

필요한 구성을 나누면 사용자 PC의 런타임, 조직의 공통 운용 계층, 모델 추론 기반, 이를 뒷받침할 자원이 있습니다. 일상 업무는 PC 가까이에서 수행하고, 모델과 도구, 정책과 기록은 공통 기반을 통해 제공할 수 있습니다. 장시간 작업이나 팀 공용 자동화를 위한 실행환경은 필요한 범위에서 더합니다.

Claude Code와 유사한 작업 방식을 제공하는 오픈소스 런타임을 고객의 업무용 PC와 내부 모델, 사내 도구에 연결해 검증하고, 배포 패키지와 운영 매뉴얼을 함께 공급하는 일이 하나의 사업이 될 수 있습니다.

기본 방향은 성숙한 오픈소스 런타임을 선정하고, 필요한 부분에 공급자 자체의 하네스와 연동 계층을 더하는 것입니다. 런타임 자체를 만드는 선택도 가능하지만, 지속적인 기능 개선과 결함 수정, 모델·도구 호환성 유지에 드는 부담을 함께 판단해야 합니다. 기존 프로젝트의 확장 기능과 인터페이스를 활용하면 업스트림의 개선을 받아들이면서 현장에 필요한 기능을 보완할 수 있습니다. 포크를 유지해야 한다면 원본과의 차이를 계속 관리할 비용까지 선택에 포함해야 합니다.

선정 기준은 실제 사용자의 작업환경에서 확인해야 합니다. 업무용 PC의 운영체제와 개발환경, 파일과 도구를 다룰 수 있는지, 내부 모델에서 도구 호출이 안정적인지, 장시간 작업과 실패를 어떻게 처리하는지 살펴야 합니다. 작업 공간과 실행 권한을 분리할 수 있는지, 외부 연결 없이 필요한 패키지를 배포하고 갱신할 수 있는지도 중요합니다. 프로젝트의 유지보수 상태와 확장 방식, 라이선스와 운영 지원 조건도 함께 보아야 합니다.

구현을 참고할 수 있는 프로젝트도 다양합니다. Gajae-Code는 코딩 에이전트 하네스의 사례이고, Open Cowork와 OpenDots는 사용자가 에이전트와 만나는 작업환경을 구성하는 방식을 보여줍니다. OpenHarness는 모델과 도구, Skill을 연결하는 하네스 구현을 살펴볼 수 있는 사례입니다. 각 프로젝트를 분리망에 적용하려면 모델 연결과 외부 서비스·인증 의존성, 배포와 업데이트 조건, 필요한 운영 기능을 실제 환경에서 검증해야 합니다.

실행 능력은 모델과 런타임의 조합으로 확인해야 합니다. FineEnvs의 multi-harness RL 실험은 여러 실제 에이전트 하네스를 공통 환경에 연결해 모델의 동작을 평가하고 가중치를 학습하는 접근을 보여줍니다. 같은 모델도 하네스에 따라 수행 결과가 달라질 수 있습니다. 저는 여러 런타임을 공통 실험 환경에서 다룰 수 있게 한 구조가 학습과 평가에서도 중요하다는 점에 주목합니다.

이 실험을 내부망 도입에 적용하면, 후보 모델의 점수만으로는 작업 능력을 판단할 수 없다는 결론에 이릅니다. 사용할 런타임과 도구를 연결한 상태에서 고객의 대표 업무를 수행해보고, 완료 품질과 실패 방식, 비용을 비교해야 합니다. 서로 다른 실행환경을 같은 업무와 기준으로 확인할 수 있도록 만드는 일이 먼저이며, 모델을 추가로 학습할지는 그 평가에서 드러난 필요에 따라 판단할 수 있습니다.

여러 사람이 각자의 PC에서 여러 도구를 사용하는 환경에서는 공통 운용 계층이 필요합니다. 누가 어떤 모델과 도구를 사용할 수 있는지, 승인된 Skill을 어디에서 가져오는지, 작업의 진행과 실패를 어디에서 확인하는지를 조직의 인증·권한 체계와 연결해야 합니다. 모델 게이트웨이와 도구 관리, 실행 관측은 각각 다른 대상을 다루므로 그 책임을 구분해 설계해야 합니다.

예를 들어 ToolHive는 MCP 서버를 배포·관리하고 도구 접근을 통제하는 데 활용할 수 있습니다. LiteLLM은 여러 모델에 대한 접근과 라우팅, 사용량과 비용 관리를 구성하는 출발점이 될 수 있습니다. 앞에서 살펴본 레지스트리는 조직이 사용할 도구와 Skill을 발견하고 배포하는 일을 맡습니다. 기능이 겹치는 부분은 이미 가진 시스템과 운영 부담을 고려해 조합하면 됩니다.

Uber의 MCP Gateway는 조직 규모에서 이런 공통 기반이 필요한 이유를 보여줍니다. 팀마다 개별 연동을 만들면서 도구의 발견과 운영, 재사용이 어려워지자, 기존 서비스 API와 MCP 서버를 함께 다루는 게이트웨이를 구축했습니다. 레지스트리는 도구의 정의와 소유 주체, 활성화 상태를 관리하고, 프록시는 호출을 실제 서비스로 전달합니다. 발견한 도구도 소유 팀이 검토하고 활성화하는 절차를 거칩니다.

ToolHive와 Uber의 사례를 내부망 구축에 연결해보면, 도구를 호출할 수 있는 접점에 더해 누가 제공하고 누가 사용할 수 있으며 어떻게 변경을 관리하는지까지 조직의 기준으로 다루어야 한다는 점이 드러납니다. 전문 모니터링 제품은 자신의 기능과 사용법, 권한과 결과의 의미를 명확히 제공하고, 공통 운용환경은 여러 제품의 접점을 발견하고 연결하는 일을 맡을 수 있습니다.

Arize Phoenix 같은 관측·평가 도구는 모델 호출과 도구 사용의 트레이스를 살펴보고, 변경 전후의 결과를 같은 사례로 비교하는 데 활용할 수 있습니다. 이를 업무의 완료 기록과 연결하면 문제가 모델의 판단, 도구의 응답, 권한, 업무 절차 중 어디에서 생겼는지 조사할 근거를 확보할 수 있습니다. 로그를 모으는 것에서 나아가 실제 업무의 품질을 확인하는 체계가 필요합니다.

로컬에서 일하는 여러 에이전트가 공통 추론 서버를 사용한다면, 그 서버가 감당할 업무량을 정해야 합니다. 어느 규모의 작업자가 어떤 일을 동시에 수행할 때 GPU가 얼마나 필요하고, 어떤 모델을 어느 정도로 양자화해 어떤 서빙 엔진에 올릴지 판단할 수 있어야 합니다. 공용 작업 실행에 필요한 자원도 별도로 산정해야 합니다. 이렇게 실제 부하를 구분해야 하드웨어나 클라우드 견적의 근거가 생깁니다.

용량을 산정할 때도 동시 접속자 수만으로는 부족합니다. 에이전트 한 번의 작업은 여러 차례의 추론과 도구 실행, 사람의 응답을 기다리는 시간으로 이루어질 수 있습니다. 긴 문서를 읽는 일과 짧은 판단을 반복하는 일, 코드를 실행하는 일은 자원을 사용하는 방식이 다릅니다. 어떤 작업이 얼마나 자주 시작되고, 얼마나 오래 지속되며, 무엇을 기다리는지부터 알아야 합니다.

추론 엔지니어링은 사용할 모델을 고르는 일에서 시작해, 실제 업무의 병목에 맞춰 실행 구성을 조정하는 일로 이어집니다. Qwen, Gemma, Solar 같은 모델을 검토할 때에도 목표 품질을 충족하는지와 함께 응답 지연, 메모리 사용량, 동시 처리 능력을 확인해야 합니다.

최적화 후보에는 MTP, DSpark, KV 캐시 오프로딩 등이 있습니다. 업무별로 대형 모델과 소형 모델을 나누어 쓰거나, 임베딩 모델과 Jev·Laya 같은 판단 모델의 활용 가능성을 검토할 수도 있습니다. 각 후보를 어느 단계에 적용할지 정하고, 품질과 자원 사용에 미치는 영향을 측정하는 일이 공급자의 전문성이 됩니다.

이런 최적화 후보의 효과는 모델과 서빙 엔진, 하드웨어, 실제 업무에 따라 달라집니다. 양자화를 통해 더 많은 작업을 동시에 처리할 수 있더라도, 도구 사용이나 긴 맥락 처리에서 품질이 떨어져 재시도가 늘면 전체 업무에서는 이득이 작아질 수 있습니다. 모델의 크기와 응답 속도뿐 아니라 과업의 성공 여부, 수정에 드는 노력, 대기시간과 총비용을 함께 봐야 합니다.

vLLM은 모델의 추론과 서빙을 담당하는 엔진의 예입니다. llm-d는 여러 모델 서버를 운용하면서 부하와 KV 캐시 등을 고려해 요청을 배치하는 구성을 다룹니다. 모델을 실행하는 엔진과 여러 실행 인스턴스를 운용하는 계층은 역할이 다르며, 필요한 규모와 병목에 맞춰 구성해야 합니다.

또한 여러 모델 중 어떤 모델을 사용할지 정하는 것과, 선택한 모델을 실행하는 서버들 중 어디로 요청을 보낼지 정하는 것은 다른 판단입니다. 어떤 업무를 어떤 에이전트에게 맡길지는 다시 그 위의 문제입니다. 에이전트 운용과 모델 선택, 추론 요청의 배치를 구분하면서 연결해야 성능과 비용의 원인을 찾을 수 있습니다.

이 검증 결과를 장비와 클라우드의 사양으로 옮기는 일도 필요합니다. GPU의 메모리와 수량뿐 아니라 서버 간 통신, 모델과 데이터를 읽는 스토리지, 필요한 가용성과 확장 여유를 함께 살펴야 합니다. 고객이 가진 자원을 활용할지, 장비를 추가할지, 허용되는 클라우드를 사용할지 비교하고 도입비와 지속적인 운영비를 포함한 견적을 제시할 수 있어야 합니다. 사용자 PC에 배포할 런타임과 하네스에 내부 모델 서빙용 GPU 클러스터 어플라이언스를 결합하는 공급 구성도 이 과정에서 구체화할 수 있습니다.

Agentic AI Platform 엔지니어링 플레이북은 설계·아키텍처, 모델 서빙, 운영·거버넌스를 나누어 살펴볼 수 있는 참고 자료입니다. 구체적인 구성을 선택할 때는 고객의 망과 인증 체계, 보유 자원, 실제 업무 조건에 맞게 각 층위를 다시 연결해야 합니다.

공급자가 제공할 수 있는 가치는 이러한 선택을 고객이 사용할 업무에 맞게 검증하고, 운영 가능한 구성으로 묶는 데 있습니다. 어떤 일을 맡길 수 있는지, 어떤 조건에서 사람에게 넘기는지, 모델이나 런타임을 바꿀 때 무엇을 다시 확인해야 하는지를 설명할 수 있어야 합니다. 매뉴얼과 교육, 관측과 장애 대응까지 이어질 때 실행환경을 갖췄다고 말할 수 있습니다.

업무용 PC에서 시작해 조직의 기반으로 넓힙니다

출발점은 팀 하나의 업무용 PC에 범용 런타임을 배치하고, 실제로 맡길 업무에 필요한 모델과 도구를 연결하는 것입니다. 사용자가 평소 작업하던 파일과 시스템을 대상으로 일을 맡기고 결과를 확인할 수 있어야 합니다. 그 작은 범위에서도 작업의 목적과 권한, 산출물과 확인 방법은 분명해야 합니다. 이후 여러 사람이 반복해서 쓰는 Skill과 도구 연결, 모델 접근과 실행 기록을 공통 기반으로 관리하면 됩니다.

처음에는 하나의 런타임으로 실제 업무를 수행할 수 있습니다. 활용이 늘면 여러 PC의 런타임과 팀 공용 작업자를 함께 운용하려는 요구도 커질 것입니다. 그동안 쌓은 업무 지식과 도구 연결, 작업 기록과 검증 기준을 다른 실행환경에서도 활용할 수 있도록 경계를 만들어야 합니다. 사용자의 작업환경 가까이에서 얻는 편의성을 유지하면서 조직 전체의 운용 능력을 더하는 방향입니다.

저는 분리망 조직도 결국 바깥 세상과 같은 기본 구조로 일하게 될 것이라고 생각합니다. 사용자의 PC에는 범용 에이전트 런타임이 있고, 조직은 그 작업자가 사용할 모델과 도구, 지식과 운영 기반을 제공합니다. 망과 자원에 따라 구현은 달라지지만, 여러 도구를 사용하는 작업자에게 업무를 맡긴다는 방향은 같습니다. 기업용 소프트웨어는 그 환경에서 쓰인다는 전제로 설계되어야 하며, 실행 기반이 없는 고객에게는 그 기반을 함께 마련할 수 있어야 합니다.

이 전제가 갖춰지면 제품을 개발하고 고객 현장에 적용하는 방식에도 새로운 질문이 생깁니다. 외부의 강력한 에이전트와 현장 내부의 에이전트가 서로 다른 조건에서 일할 때, 공급자는 무엇을 미리 만들고 현장에는 어떤 조정 가능성을 남겨야 할까요. 다음 글에서는 이 사업 수행 방식의 변화와 제품 자체의 현장 적응을 구분하면서, ‘씨앗과 발아’의 관점으로 살펴보겠습니다.