에이전트 시대, 전문 소프트웨어 공급자가 고를 수 있는 범위

전문 소프트웨어에 에이전트 기능을 붙이는 일은 화면에 대화창을 하나 더 다는 결정처럼 보입니다. 사용자의 질문을 받고, 제품이 가진 데이터로 답을 만들어 보여주면 됩니다. 그런데 같은 화면을 만드는 방법이 하나가 아니고, 어느 쪽을 고르느냐에 따라 일 년 뒤에 공급자 손에 남는 것이 달라집니다. 저는 이 선택이 기능의 완성도보다 공급자가 앞으로 팔 수 있는 범위를 더 크게 가른다고 봅니다.

이 글은 연재의 4편입니다. 1편에서는 여러 도구를 사용하는 범용 작업자(에이전트) 와 전문 도구의 분리를 다루었고, 2편에서는 그 작업자가 일할 에이전트 런타임을 조직 안에 두는 문제를, 3편에서는 현장에서 얻은 경험이 제품으로 돌아오는 과정을 다루었습니다. 이 연재에서 '작업자'는 사람이 아니라 이 범용 에이전트를 가리키며, 사람은 사람이라고 부릅니다. 4편은 같은 관점을 전문 소프트웨어 공급자의 사업 선택에 적용합니다.

제가 보기에 가장 중요한 첫걸음은 범용 작업자가 제품의 전문 기능을 사용할 수 있는 접점을 만드는 것입니다. 고객에게 에이전트 런타임이 준비되어 있지 않다면 축소판 에이전트를 함께 공급하는 길이 있습니다. 다만 그 경우에도 제품의 전문 기능과 업무 자산은 다른 호환 작업자가 똑같이 쓸 수 있도록 설계해야 한다고 생각합니다. 이 글에서는 제품과 함께 공급하는 축소판 에이전트를 1편에서 쓴 이름대로 내장 에이전트라고 부릅니다.

이 선택은 제품 개발에서 사업으로 이어집니다. 범용 작업자가 전문 제품을 쓰려면 고객 조직 안에 그 작업자가 일할 자리가 먼저 있어야 하기 때문입니다. 이미 환경을 갖춘 고객에게는 제품을 연결하면 되고, 더 넓은 업무를 맡길 런타임이 필요한 고객에게는 범용 에이전트 인프라의 컨설팅과 구축이 따라붙습니다. 내장 에이전트를 공급하는 일과 조직 차원의 인프라를 구축하는 일은 서로 다른 공급 범위이고, 어느 쪽을 택할지는 고객의 준비 상태와 필요에 달려 있습니다.

고객사 구성원들은 외부망에서 이미 Claude Code 같은 작업자를 쓰고 있습니다. 그 작업 방식을 내부의 코드와 운영 데이터에도 적용하려는 수요는 앞으로 커질 것이라고 봅니다. 그런데 내부망에서는 모델과 런타임, 도구 연결과 실행 권한이 갖춰지지 않아 그 흐름이 끊깁니다. 이 간극을 메우고, 고객이 익숙한 업무 흐름 안에서 전문 제품을 쓰게 만드는 것이 제품 쪽 과제와 인프라 쪽 과제의 공통 출발점입니다.

보고서 한 장을 만드는 두 가지 내부 구조

사용자가 "오늘 오전부터 서비스가 느려진 이유를 조사해달라"고 입력하는 장면을 떠올려봅시다. 에이전트는 모니터링 지표와 로그, 최근 변경 이력을 훑고, 알아낸 사실과 원인 가설을 정리합니다. 화면에 남는 것은 사용자의 요청과 에이전트가 쓴 보고서 한 장입니다. 그런데 이 한 장을 만드는 내부 구조는 둘로 갈립니다.

첫 번째는 조사 순서와 분석 규칙, 도구를 호출하는 방법을 제품 전용 에이전트의 코드 안에 함께 구현하는 것입니다. 두 번째는 제품의 전문 기능을 호출 가능한 도구로 내놓고, 사용법과 조사 절차를 별도의 업무 자산으로 묶은 뒤, 에이전트가 그것을 읽고 쓰게 하는 것입니다. 사용자가 받는 보고서는 두 경우 모두 같습니다.

차이는 두 번째 요구가 들어왔을 때 드러납니다. 고객이 이미 쓰는 작업자에서 이 제품을 부르고 싶어 하거나, 런타임을 교체하거나, 같은 조사 기능을 다른 업무에 붙이려 할 때 무엇을 다시 만들어야 하는지가 달라집니다. 전문 기능과 업무 자산이 특정 에이전트 안에 묶여 있으면 이를 꺼내거나 다시 구현해야 합니다. 처음부터 경계를 그어두면 기능과 자산은 그대로 두고 연결만 바꾸면 됩니다.

전용 에이전트도 외부 시스템을 호출하도록 만들 수 있습니다. 그러니 쟁점은 외부 도구를 부를 수 있느냐가 아닙니다. 그 연결과 업무 자산이 어느 구현에 속하느냐입니다. 전문 모니터링 제품을 잘 쓰는 능력을 특정 에이전트만의 내부 구현으로 남길지, 여러 작업자가 꺼내 쓸 수 있는 제품 자산으로 만들지가 갈림길입니다.

이 경계는 나중에 그을수록 비쌉니다. 첫 기능을 만드는 시점에는 두 구조의 공수 차이가 크지 않습니다. 하지만 두 번째 런타임과 세 번째 업무가 생긴 뒤에는 이미 작성된 실행 루프에서 업무 자산을 분리해내는 작업이 먼저 붙고, 그동안 쌓인 동작을 그대로 재현했는지 검산하는 일도 따라옵니다. 지금 경계를 정해두면 첫 기능에 들인 투자를 다음 런타임과 다음 업무에서도 그대로 씁니다.

호출할 수 있다는 것과 쓸 수 있다는 것은 다릅니다

접점은 에이전트가 제품의 기능을 찾아 이해하고 부른 뒤, 그 결과를 다음 작업에 쓰는 자리입니다. 1편에서 쓴 말을 그대로 씁니다. 기능을 부를 수 있다는 것과 그 기능을 적절히 쓸 수 있다는 것은 다른 문제이고, 둘 다 갖춰져야 접점이 제 역할을 합니다.

지정한 시간 구간의 지표를 조회하는 기능을 도구로 내놓는다고 해봅시다. 에이전트는 대상과 시간 범위를 어떻게 지정하는지, 돌아온 값의 단위와 의미가 무엇인지, 데이터가 없는 경우와 조회가 실패한 경우를 어떻게 가르는지 알아야 합니다. 분석 결과라면 어떤 조건에서 나온 값인지, 근거가 무엇인지까지 함께 볼 수 있어야 합니다. 다른 작업자가 같은 기능을 불러도 이 의미가 흔들리지 않게 만드는 일이 접점의 몫입니다.

여기에 업무 자산이 붙습니다. 어떤 질문에 어떤 기능을 쓰는지, 조사할 때 무엇부터 보는지, 결과를 어떻게 읽어야 하는지를 문서와 Skill, 필요하면 스크립트로 묶은 것입니다. 기능과 업무 자산을 함께 내놓으면 에이전트가 매번 시행착오로 사용법을 더듬는 일이 줄어듭니다.

이런 접점은 고객이 이미 가진 업무 흐름 안으로 제품이 들어가는 통로가 됩니다. 운영 담당자가 하는 조사는 모니터링 제품 하나에서 끝나지 않습니다. 로그 시스템과 변경 이력, 사내 문서를 함께 봐야 한다면, 조직의 작업자가 그 일을 이어가면서 필요한 순간에 전문 모니터링 제품의 기능을 부를 수 있어야 합니다.

공급자 쪽에도 이득이 있습니다. 제품의 전문 기능이 내장 에이전트의 화면과 고객의 다른 작업환경 양쪽에서 쓰일 경로가 생깁니다. 더 나은 모델이나 런타임으로 갈아탈 때에도 분석 기능과 업무 자산은 그대로 따라갑니다. 물론 실제로 지원할 환경은 연결 방식과 권한, 모델과 런타임의 능력을 하나씩 짚어 정해야 합니다.

그래서 첫 개발 과제는 대표 업무에서 에이전트에게 넘길 기능을 고르고, 그 기능과 업무 자산을 일관된 형태로 내놓는 일이 됩니다. API나 MCP 같은 연결 방식의 선택은 이를 구현하는 수단입니다. 제품 관점에서 확인할 것은 그 접점으로 실제 업무가 얼마나 잘 수행되는지입니다.

내장 에이전트와 외부 작업자가 같은 문을 쓴다면

고객에게 아직 범용 에이전트 환경이 없는 경우가 많습니다. 그래도 제품의 에이전트 기능을 쓰게 하려면 내장 에이전트를 함께 공급하는 길이 있습니다. 내장 에이전트는 범용 실행 능력을 첫 업무에 필요한 범위로 줄여 구성하되, 제품의 전문 기능과 업무 자산은 외부 작업자와 똑같은 접점을 통해 씁니다.

내장 에이전트에 기본으로 들어가는 것은 공통 실행 능력입니다. 사용자의 목표와 맥락을 유지하고, 제공된 지침을 읽고, 도구를 부르고, 결과를 받아 다음 작업으로 잇습니다. 배포와 운영 구성도 첫 업무에 필요한 만큼으로 줄입니다. 제품 화면에서는 사용법을 안내하고 첫 조사를 돕는 전용 도우미로 붙일 수 있습니다.

전문 지식은 제품 기능과 업무 자산 쪽에 둡니다. 지표 계산과 데이터 처리, 전문 분석은 제품이 맡고, 그 기능을 쓰는 방법과 조사 절차는 문서와 Skill, 스크립트로 냅니다. 내장 에이전트의 실행 엔진에는 제품 비즈니스 로직을 따로 심지 않습니다. 내장 에이전트와 고객의 범용 작업자가 같은 기능, 같은 자산을 봅니다.

정해진 순서와 조건으로 도는 업무 기능은 제품 안에 구현하고, 제품이 분석 과정에서 모델을 직접 호출하게 할 수도 있습니다. 에이전트는 이 기능들을 도구로 쓰면서 전체 작업의 목표와 맥락을 쥡니다. 제품 내부의 구현과 제품을 쓰는 실행 주체의 책임이 이렇게 나뉩니다.

이 경계를 지키면 고객은 내장 에이전트로 시작했다가 조직의 런타임이 준비되었을 때 같은 제품 기능과 업무 자산을 그대로 연결하면 됩니다. 공급자가 내장 에이전트용 분석 로직과 외부 작업자용 분석 로직을 따로 유지할 이유도 줄어듭니다. 런타임이 바뀌면 연결과 품질은 다시 점검해야 하지만, 전문 기능 전체를 새로 만드는 일은 피합니다.

반대로 내장 에이전트에 조사 절차와 해석 규칙까지 넣어버리면, 그 에이전트는 제품의 유일한 입구가 됩니다. 고객이 자기 작업자로 같은 일을 하려는 순간 공급자는 같은 지식을 두 번째로 구현하게 되고, 그다음부터는 두 구현의 결과가 어긋나지 않는지까지 관리해야 합니다.

조사를 이어받는 쪽에서 본 변화

운영 이상을 조사하는 사람은 여러 화면을 오가며 같은 서비스와 시간대를 맞추고, 자료를 모으고, 다음에 무엇을 볼지 정합니다. 조사를 다른 팀에 넘길 때는 지금까지 본 것을 처음부터 다시 설명합니다. 에이전트가 덜어줄 수 있는 쪽은 이 반복되는 준비와 실행입니다.

공급자가 고객의 시스템을 살핀 뒤 구성할 수 있는 조사 흐름은 이렇습니다. 작업자가 허용된 범위의 지표와 로그, 변경 이력을 모으고, 전문 모니터링 제품의 기능을 실행한 뒤 다른 도구에서 얻은 정보와 묶어 정리합니다. 결과에는 관측한 사실과 원인 가설, 더 봐야 할 것을 나누어 적고 근거를 답니다. 고객이 실제로 접근할 수 있는 자료와 도구를 바탕으로 이 흐름을 짜고 검증해야 합니다.

흐름이 제대로 돌면 사람이 자료를 옮기고 조건을 맞추는 시간이 줄어듭니다. 담당자는 중요한 주장과 남은 불확실성을 보는 데 시간을 쓰고, 다음 담당자는 실행 기록을 읽고 진행된 지점에서 이어받습니다. 도구마다 사용법을 따로 익혀야 했던 부담도 일부 덜어집니다.

이미 조직의 작업자를 운용하는 고객이라면 그 흐름 안에서 제품을 씁니다. 준비가 안 된 고객은 내장 에이전트로 시작합니다. 어느 쪽에서 출발하든 제품의 전문 기능과 업무 자산을 계속 쓰게 만드는 것이 고객 쪽에서 본 연속성입니다.

이상 조사에 마련한 도구 연결과 서비스별 정보는 정기 보고나 배포 후 점검에도 쓰입니다. 다만 그대로 옮겨지지는 않습니다. 적용할 업무와 권한을 짚고 절차를 손봐야 합니다. 그래도 유효한 연결과 지식은 다음 작업의 출발점이 됩니다. 고객에게 남는 것은 실제로 돌아가는 런타임과 도구 연결, 고쳐 쓸 수 있는 업무 절차, 나중에 되짚어볼 수 있는 작업 기록입니다.

조회와 분석, 조치안 작성, 실제 운영 변경은 각각 어디까지 맡길지 정해야 합니다. 조사와 보고서 작성으로 시작한다면 완료 조건도 그 범위에 맞춥니다. 보고서를 받은 사람이 어떤 근거로 무엇을 판단하게 되었는지가 기준입니다. 변경안 작성이나 운영 반영까지 넓히는 것은 그 기준을 통과한 다음 문제입니다.

고객의 준비 상태가 공급 범위를 가릅니다

제품을 쓸 작업자의 경계를 정하고 나면, 그 작업자를 어디에서 어떻게 운용할지가 다음 문제로 넘어옵니다. 제품 설계가 인프라 사업과 이어지는 지점이 여기입니다.

고객이 어떤 작업환경을 가지고 있고 업무를 어디까지 넓히려 하느냐에 따라 공급 범위가 셋으로 갈립니다. 세 경우 모두 제품의 전문 기능과 업무 자산은 같고, 달라지는 것은 런타임과 연결 범위입니다.

이 셋은 고정된 등급이 아닙니다. 내장 에이전트로 시작한 고객이 나중에 조직의 런타임을 마련하기도 하고, 이미 환경을 가진 고객이 연동과 운영 기능만 보완하기도 합니다. 전문 기능과 업무 자산을 공통으로 두면 고객이 어느 칸으로 옮겨가도 같은 자산이 따라갑니다.

2편에서 본 런타임 구성을 사업으로 옮기려면 고객에게 무엇을 남길지부터 정해야 합니다. 출발점은 맡길 업무와 완료 조건, 접근할 시스템과 허용되는 실행 범위를 함께 적어두는 일입니다. 런타임 선정 기준도 2편에서 정리했습니다. 공급 관점에서 추가로 정할 것은 직접 개발할 범위입니다. 조직의 작업 공간과 인증을 잇거나, 업무를 전달하고 상태를 관리하는 기능처럼 고객 환경에서만 필요한 부분에 집중하는 편이 낫습니다. 자체 런타임이나 포크는 장기 유지보수 부담을 따져 택할 일입니다. 제품의 전문 로직은 제품에, 사용법과 절차는 업무 자산에 두면 어느 런타임을 골라도 같은 투자를 씁니다.

이 사업에서 공급자가 중심을 잡아야 할 부분은 고객의 업무를 이해하고 전체 구성을 설계하며, 전문 제품과 다른 도구를 연결해 실제 수행 결과를 검증하는 일입니다. 공통 운용 계층에는 2편에서 살펴본 ToolHive, LiteLLM, Arize Phoenix 같은 구성요소를, 추론 기반에는 vLLM과 llm-d 등을 후보로 놓을 수 있습니다. 어느 도구를 넣었는지보다 중요한 것은 그것들을 엮은 환경에서 고객이 맡기려는 일이 실제로 수행되는지 설명하고 보여줄 수 있는가입니다.

인수인계에는 운영 매뉴얼과 교육, 검증된 업무 절차와 평가 사례가 들어갑니다. 어떤 구성과 버전에서 통과했는지, 장애를 누가 접수하고 어느 계층의 문제로 분류할지, 모델과 런타임과 도구를 바꿀 때 누가 무엇을 다시 볼지도 적어 남깁니다. 구축이 끝난 뒤에도 연결한 시스템과 업무 절차는 계속 바뀝니다. 연결 수정과 업무 자산 갱신, 변경 후 품질 점검, 실패 원인 조사가 운영·개선 서비스의 범위입니다. 실제로 어디까지 맡고 어떤 계약으로 제공할지는 고객의 필요와 지원 부담을 보고 정합니다.

제품을 적용하다가 런타임의 필요가 드러나기도 하고, 런타임을 구축하다가 전문 도구를 쓰는 업무가 구체화되기도 합니다. 두 사업이 이어지는 이유가 여기 있습니다. 다만 제품 연결만 필요한 고객과 인프라까지 필요한 고객을 섞어서 보면 공급 범위도 사업 기회도 과대평가하게 됩니다.

첫 업무의 완료 기준을 누가 쓰는가

이 구조가 실제로 돌아가는지는 첫 업무 하나에서 드러납니다. 첫 업무를 고를 때 중요한 것은 난이도가 아니라 완료 기준을 글로 쓸 수 있느냐입니다. 운영 이상 조사라면 대상과 시간대를 정해 자료를 보고, 근거와 더 봐야 할 것을 담은 보고서를 내는 범위가 그런 업무입니다. 전문 모니터링 제품이 맡을 기능과 다른 시스템의 역할, 사람이 판단할 지점을 이 범위 안에서 갈라둡니다.

완료 기준은 공급자가 혼자 써두면 소용이 없습니다. 고객과 같은 문장을 보고 같은 판정을 내릴 수 있어야 합니다. 첫 조사라면 조회 대상과 시간 범위가 맞는지, 보고서의 사실 판단을 원본 자료까지 따라가 짚을 수 있는지, 데이터가 없거나 호출이 실패한 부분을 감추지 않고 드러내는지가 그런 항목입니다. 실제 장애 원인을 확정하는 일까지 맡길지는 따로 정합니다.

Anthropic의 AI 기반 코드 현대화 지침은 목표 상태와 검증 조건·테스트, 실제 반영 절차를 먼저 정하고 작은 범위에서 전체 과정을 돌려본 뒤 넓히라고 설명합니다. 사람이 결과를 검토하고 업무에 받아들이는 과정까지 실행 설계에 넣는 접근입니다. 공급에 옮기면 고객에게 남길 것에 돌아가는 환경과 업무용 Skill, 절차만이 아니라 합의한 완료 기준과 그 기준을 통과했다는 근거가 함께 들어갑니다.

기준을 글로 남겨두면 나중에 비교가 됩니다. 조사 절차를 고치거나 모델과 런타임을 바꿨을 때 무엇이 달라졌는지 같은 자로 잴 수 있습니다. 이런 검증과 인수 체계를 고객의 실제 업무에 맞춰 만들 수 있는지가 공급자의 컨설팅·구축 역량입니다.

첫 업무를 돌릴 때는 고객에게 준비된 런타임이 있으면 거기서 먼저 쓰게 합니다. 없으면 내장 에이전트로 시작합니다. 한쪽이 돌아간 뒤 다른 호환 작업자에서도 같은 자산을 써보면, 업무의 의미가 특정 런타임 내부 구현에 갇혀 있는지 드러납니다. 재사용 범위를 말로 주장하지 않고 실행으로 가려내는 방법입니다.

고객 쪽 이득은 같은 완료 조건에 닿는 전체 시간, 사람이 직접 들인 시간, 결과의 품질을 함께 놓고 봐야 보입니다. 보고서가 빨리 나왔더라도 담당자가 원본을 전부 다시 조사한다면 부담은 줄지 않은 것입니다. 검토와 재작업, 연결 실패 처리, 모델과 인프라와 유지보수 비용까지 넣어야 실제 업무가 나아졌는지 셈이 맞습니다.

공급자 쪽은 다른 자로 재야 합니다. 다른 런타임에 붙일 때 전문 기능을 다시 구현하는지, 새 고객에게 갈 때 기존 연결과 업무 자산을 얼마나 그대로 들고 가는지, 현장별 수정과 지원 부담이 어느 방향으로 움직이는지가 그 자입니다. 인프라 구축과 운영 지원에 실제 수요가 있는지, 그 범위를 계속 감당할 수 있는지도 같은 시기에 드러납니다.

현장에서 돌아오는 것과 돌아오지 않는 것

3편은 현장 적용과 축적의 관계를 씨앗과 발아로 설명했습니다. 무엇을 현장 설정으로 남기고 무엇을 공통 제품에 반영할지의 기준도 거기서 정리했습니다. 4편에서 더할 것은 그 기준이 사업 자산을 가르는 자리에서 어떻게 쓰이는가입니다.

고객에게 제공할 설정과 업무 절차, 실행 기록은 공급자가 일반화할 구현·검증 사례와 구분해야 합니다. 고객의 원본 데이터나 내부 지식이 자동으로 공급자의 재사용 자산이 되지는 않습니다. 공유와 활용이 허용된 범위에서만 기술과 수행 경험을 정리해 공통 제품으로 옮길 수 있고, 그 범위를 긋는 일 자체가 계약과 현장 관계의 문제이기도 합니다.

3편에서 1인칭으로 다룬 메모리 사용률 0 사례도 이 관점에서 다시 읽힙니다. 필드를 잘못 고르면 매핑은 성공하고 결과 행도 생기지만 값은 계속 0입니다. 남길 가치가 있는 것은 고친 코드가 아니라 그 실패를 다시 만들어내는 조건과, 다음 구현에서 무엇을 검산해야 하는지입니다.

반복되는 도구 연결과 데이터 변환은 공통 어댑터로 묶고, 효과가 있던 조사 절차는 업무 자산으로 정리하며, 실제 실패는 재현 사례로 남깁니다. 그러면 다음 현장에서 같은 문제를 처음부터 조사하고 구현하는 부담이 실제로 줄었는지 따져볼 수 있습니다.

현장 적용과 공통 제품 개발은 한쪽이 끝나고 다른 쪽이 시작되는 관계가 아닙니다. 고객의 문제를 푸는 기간 안에 그 해법이 특정 프로젝트에만 남지 않도록 정리하는 작업이 함께 들어갑니다. 담당자의 경험, 연결 코드, 업무 자산과 검증 사례 가운데 다음 사업에서 쓸 수 있는 것을 제품팀과 함께 골라내는 과정이 있어야 합니다.

양쪽에 남는 것은 서로 다릅니다

지금까지의 선택은 고객과 공급자 양쪽에 결과를 남기는데, 남는 것의 성격이 다릅니다. 고객에게는 쓸 수 있는 환경이 남고, 공급자에게는 다음 고객에게 들고 갈 자산이 남습니다. 같은 설계에서 나오지만 성립하는 조건은 따로 봐야 합니다.

제품 측면에서는 전문 제품이 고객의 업무에 참여할 경로가 넓어집니다. 자체 화면과 내장 에이전트뿐 아니라 고객이 고른 작업환경에서도 전문 기능을 부를 수 있다면 제품이 쓰이는 자리가 늘어납니다. 분석 기능과 업무 자산을 한 벌로 유지하므로 런타임이 추가될 때 기존 투자를 그대로 씁니다.

대신 비교 대상이 늘어납니다. 접점을 열어두면 같은 작업자가 다른 전문 도구도 부를 수 있기 때문입니다. 공급자에게 필요한 경쟁력은 전문 모니터링 제품의 기능이 실제 조사에 얼마나 쓸모 있는지, 결과를 얼마나 잘 읽고 따져볼 수 있는지, 고객 환경에 얼마나 안정적으로 붙는지에서 나옵니다. 접점은 기회를 열 뿐이고, 실제 사용과 구매로 이어지는지는 이 쓸모가 가릅니다.

사업 측면에서는 제품을 고객 업무에 붙이는 데 필요한 환경을 함께 공급하게 됩니다. 고객에 따라 제품 연결, 내장 에이전트 제공, 조직 인프라 구축, 운영 지원으로 범위가 달라집니다. 공급자가 직접 맡을 설계·연결·검증의 범위, 각 범위의 고객 수요, 수행 비용, 지속적인 지원 부담까지 함께 따져야 사업 가치를 판단할 수 있습니다.

축적 측면에서는 한 현장에서 찾은 해결 방법이 다음 제품과 사업을 바꿉니다. 다만 이 축적은 저절로 일어나지 않습니다. 공통 접점을 유지하고 여러 런타임에서 동작을 점검하는 데에는 개발과 운영 비용이 들고, 현장 경험을 제품으로 되돌리는 일에도 따로 시간이 듭니다. 그 투자가 반복 구현과 지원 부담을 얼마나 덜어내고 제품이 쓰이는 자리를 얼마나 넓혔는지는 제품 경쟁력, 새 수주 범위, 수행 비용이라는 세 결과로 각각 나타납니다. 셋 가운데 하나만 좋아졌다면 나머지 둘의 조건이 아직 성립하지 않은 것입니다.

이 선택이 흔들리는 자리

경계를 나누는 쪽이 언제나 이득은 아닙니다. 몇 가지 조건이 깨지면 묶어두는 쪽이 더 쌉니다. 저는 이 글의 주장을 받아들이기 전에 이 세 가지를 먼저 봐야 한다고 생각합니다.

첫째, 접점을 열어도 그 접점을 쓸 작업자가 고객 조직에 없는 경우입니다. 내장 에이전트가 사실상 유일한 사용자라면 공통 접점을 유지하는 비용은 당장의 수익과 연결되지 않습니다. 이때 경계를 나눈 이득은 전부 미래에 있고, 그 미래를 얼마나 가깝게 보느냐가 판단을 가릅니다. 외부망에서 작업자를 쓰는 사람들이 같은 방식을 내부망에서도 요구하기까지 얼마나 걸리는지가 여기서 실제 변수입니다.

둘째, 전문 기능과 조사 절차를 떼어놓기 어려운 경우입니다. 분석의 의미가 호출 순서 안에 들어 있어 도구 단위로 쪼개면 결과가 달라지는 기능이 있습니다. 이런 기능은 하나의 도구로 묶어 제품 안에서 순서를 지키게 하고, 에이전트에게는 그 묶음을 부르게 하는 편이 낫습니다. 경계를 나눈다는 말이 기능을 잘게 쪼갠다는 뜻은 아닙니다. 나누는 선은 기능의 크기가 아니라 '이 지식이 바뀔 때 누가 고쳐야 하는가'를 따라 그어야 합니다.

셋째, 제품의 차별화를 에이전트 경험 자체에 두려는 경우입니다. 접점을 열면 같은 작업자가 경쟁 제품도 부릅니다. 데이터와 전문 계산이 아니라 대화 경험이 차별화의 전부라면, 접점을 여는 선택은 그 차별화를 스스로 지우는 일이 됩니다. 다만 1편에서 본 ML Intern의 종료는 반대 방향에서 같은 자리를 비춥니다. 전문성을 전용 런타임과 묶어 공급하면 런타임이 멈출 때 전문성도 함께 멈춥니다. 대화 경험으로 지키는 차별화는 그 런타임이 계속 경쟁력을 유지한다는 전제 위에만 서 있습니다.

세 조건을 다 놓고 봐도, 저는 기본값은 경계를 나누는 쪽이라고 봅니다. 전문 소프트웨어가 가진 것은 데이터와 전문 계산, 도메인 규칙과 검증 방법이고 이것들은 작업자가 바뀌어도 값이 떨어지지 않습니다. 반면 실행 루프와 맥락 관리는 범용 런타임 쪽이 훨씬 빠르게 좋아지는 영역입니다. 자기 자산이 아닌 것을 붙들고 있으면 그 개선을 받아올 통로가 막힙니다.

고객은 자신의 도구와 업무를 엮어 일을 맡길 환경을 얻고, 공급자는 그 환경에서 불려 나갈 전문 제품과 구축·운영 역량, 다음 현장으로 들고 갈 수행 경험을 얻습니다. 어느 쪽도 첫 기능 하나로 완성되지 않습니다. 다만 첫 기능을 어떤 구조로 만드느냐가 그 뒤에 쌓을 수 있는 것의 상한을 정합니다. 전문 소프트웨어의 가치가 도구와 데이터, 업무 절차에 남는다면, 지금 만드는 에이전트 기능도 그 자리에 남겨야 합니다.