IBM Bob, 방화벽 안으로 들어가다 — 그것이 바로 핵심이다

IBM이 자사의 에이전트형 소프트웨어 개발 플랫폼인 IBM Bob을 자체 호스팅(self-hosted) 형태로 제공하기 시작했다. 온프레미스, 프라이빗 클라우드, 소버린 클라우드, 에어갭(air-gapped) 배포가 모두 선택지에 올라 있다. 고객은 자체 모델 구성을 선택하고, 소스 코드와 애플리케이션 컨텍스트를 자사 네트워크 안에 유지하며, 데이터 상주 위치와 보안 정책에 대한 통제권을 그대로 보유한다.

언뜻 들으면 배포 방식에 붙는 각주처럼 보인다. 하지만 이는 누가 코딩 에이전트를 쓸 수 있는가에 관한 하나의 명제에 가깝다.

자체 호스팅이 메우는 격차

코딩 에이전트는 빠르게 진화해 왔다. 저장소를 읽고, 변경을 제안하고, 테스트를 실행하고, 풀 리퀘스트를 연다. 스타트업이라면 이를 클라우드 서비스에 연결하는 일은 화요일 오후에 끝낼 일이다. 하지만 방위산업체나 은행, 병원 시스템에서는 같은 시도가 첫 법률 검토 단계에서 좌초한다. 소스 코드는 건물 밖으로 나갈 수 없다. 코드베이스를 이해 가능하게 만드는 지저분한 조직 내부 지식, 즉 내부 컨텍스트도 마찬가지다. 에어갭 환경은 설계상 클라우드로 나가는 경로 자체가 없다.

그 결과 경제의 상당 부분이 유리벽 너머에서 에이전트 시대를 구경만 하고 있다. IBM은 바로 그 시장을 겨냥해 판매하고 있으며, 처음은 아니다. 이 범주는 현재 작다. 자체 호스팅 에이전트에는 모델 가중치와 하드웨어, 그리고 보통 클라우드 벤더가 제공하는 오케스트레이션 계층이 필요하기 때문이다. 이 배관 문제를 해결하는 기업은 API 우선(API-first) 연구소들이 닿을 수 없는 고객층을 확보하게 된다.

왜 생각보다 어려운가

에이전트는 단일한 무언가라기보다 루프로 이해하는 편이 쉽다. 계획하고, 행동하고, 관찰하고, 조정한다. 클라우드에서는 에이전트가 호출하는 도구들이 서비스이며, 장애 모드는 남의 문제다. 방화벽 안에서는 같은 저장소, 같은 티켓 트래커, 같은 빌드 시스템에 접근해야 하는데, 이제 네트워크는 분할되어 있고, 자격 증명은 일정에 따라 교체되며, 서비스 중 절반은 '에이전트'라는 단어가 아무 의미도 없던 시절에 마지막 업데이트가 이루어졌다.

IBM의 제안은 이미 이런 환경에 판매해 왔다는 사실에 기대고 있다. IBM의 고객들은 다른 누구도 건드리려 하지 않는 메인프레임과 레거시 시스템을 운영한다. 그곳에서 에이전트를 작동시키는 일은 화려하지도, 빠르지도 않으며, 바로 그런 종류의 작업이 해자를 만든다.

거버넌스 측면도 있고, 이것이 계속해서 화두로 떠오른다. 자체 호스팅 에이전트는 고객이 소유하는 로그를 생성한다. 규제 감사에서 어떤 모델이 실행되었고, 무엇을 읽었으며, 무엇을 변경했는지 정확히 보여줄 수 있다. 클라우드 환경에서는 그 증거가 벤더의 콘솔과 서비스 계약서에 흩어져 있다. 문제가 생겼을 때 '우리에게 로그가 있다'와 '우리가 로그를 요청했다'의 차이는 사건을 종결하는 것과 한 분기를 증거개시(디스커버리)에 허비하는 것의 차이다.

그 아래에 깔린 모델 문제

에이전트를 자체 호스팅한다는 것은 모델을 자체 호스팅한다는 뜻이거나, 최소한 자체 실리콘에 올릴 수 있는 모델을 선택한다는 뜻이다. IBM은 고객이 지원되는 구성을 선택할 수 있게 하는데, 실제로는 오픈 가중치 모델과 IBM 자체 모델의 조합을 의미한다. 여기서 오픈 가중치 옵션이 중요하다. 프라이빗 클러스터에서 돌아가는 70B급 모델은 최고의 호스팅 모델보다 느리고 성능도 떨어진다. 그 대신 네트워크가 끊겼을 때, 벤더가 가격을 올릴 때, 또는 벤더가 당신의 사용 사례가 한 번도 읽지 않은 정책을 위반한다고 판단할 때도 쓸 수 있다.

기업들은 데이터베이스로 이 트레이드오프를 10년째 해 왔고, 결과도 비슷하다. 통제권을 얻는 대신 성능 격차를 감수하고, 하드웨어가 좋아지면서 시간이 지나며 그 격차를 좁힌다.

방화벽 안에서는 경제성이 다르게 보인다

클라우드 코딩 에이전트는 토큰당 과금되므로, 비용은 에이전트가 읽고 쓰는 코드 양에 비례한다. 스타트업에게는 예측 가능한 비용 항목이다. 하나의 저장소에 수십 년의 이력이 담겨 있고 에이전트가 도움이 되기 전에 훨씬 많은 컨텍스트를 흡수해야 하는 대기업에서는 계량기가 뜨겁게 돌아간다.

자체 호스팅은 이 모델을 뒤집는다. 비용은 하드웨어와 운영이 되는데, 이는 조직이 이미 부담하고 있는 자본 지출이다. 데이터 센터를 가진 은행은 에이전트가 100만 줄을 더 읽는다고 더 내지 않는다. 추가 에이전트 작업의 한계 비용은 전기와 GPU 시간에 수렴하고, 그것들은 이미 매몰 비용이다. 이러한 비대칭성 때문에 클라우드 제품이 객관적으로 더 우수하더라도 자체 호스팅 제안이 먹히는 것이다.

다만 마케팅이 건너뛰는 컴플라이언스 비용이 있다. 자체 호스팅은 패치, 모니터링, 모델 업데이트의 부담을 고객에게 옮긴다. 클라우드 벤더는 수정 사항을 밀어 넣으면 끝이다. 온프레미스 배포는 업그레이드를 일정에 맞춰 계획하고, 내부 시스템에 대해 테스트하고, 변경 통제 위원회를 통과해야 한다. 이 도구는 더 통제 가능하고 더 많은 일을 요구하며, 그 트레이드오프가 엔터프라이즈 소프트웨어의 전부다.

이것을 가능하게 하는 인접 시장

에이전트 자체 호스팅은 방화벽 안에서 돌릴 만한 무언가가 있을 때만 작동하는데, 그 공급은 늘었다. 실제 코딩 작업을 할 수 있는 수준의 오픈 가중치 모델이 이제 흔하며, 여러 대륙의 연구소들이 허용적 라이선스로 공개한다. 빠져 있던 조각은 결코 모델이 아니었다. 통제된 네트워크 안에서 모델을 개발자가 위임할 수 있는 무언가로 바꿔 주는 하네스(harness)였다.

IBM이 파는 것이 바로 그 계층이다. 최고의 모델을 학습시키는 것이 목표가 아니다. 클라우드 호출이 선택지가 아닌 곳에서 기존 모델을 사용 가능하게 만드는 통합 지점이 되는 것이 목표다. 이 전략은 API 우선 연구소들의 정반대다. 그들은 역량을 바깥으로 밀어내고 누구나 연결하게 한다. IBM은 역량을 안으로 끌어들여 경계(perimeter)를 견뎌내게 만든다.

그 경계 안에 갇힌 구매자들에게 선택지는 2년간 불쾌했다. 멀리서 에이전트 물결을 바라보거나, 보안 규칙을 깨고 합류하거나. 자체 호스팅 옵션이 그 물결을 작게 만들지는 않는다. 다만 도달 가능하게 만들 뿐이며, 규제를 받는 조직에게는 그것이 곧 현실이 되는 것과 같다.

지켜볼 것

데모는 자체 호스팅 에이전트형 코딩에 대한 정직한 질문이 아니다. 정직한 질문은 회사를 떠난 사람들이 15년에 걸쳐 쌓은 기술 부채가 있는 코드베이스에서도 결과가 버티느냐다. 클라우드 에이전트도 그 부분에서 고전한다. 차이는 자체 호스팅 에이전트는 고객이 직접 나서지 않으면 벤더가 하룻밤 사이에 개선해 줄 수 없다는 점이다. 모든 개선은 고객 자체 팀이 벌어내야 한다.

그래서 도입은 느리고 끈적해지는데, 이는 IBM에 유리하다. IBM은 성공을 스프린트가 아니라 연 단위로 측정하고, 검사할 수 없는 더 나은 도구를 빌리는 것보다 살짝 떨어지는 도구를 소유하는 쪽을 택하는 구매자를 위해 만들고 있다. 2년 동안 벤치마크를 좇아온 코딩 에이전트 시장에서 이는 보수적인 베팅이다. 동시에 아직 제대로 서비스를 받지 못한 시장 부분에 대한 베팅이기도 하다.

이것이 나쁘게 전개되는 버전도 있다. 자체 호스팅 도구는 한 번 출시하고 나면 방치된다는 평판이 있다. 벤더가 지속적으로 개선할 유인이 없고, 고객이 요구할 협상력도 없기 때문이다. IBM Bob이 의미 있게 나아지지 않는 안정된 제품으로 정착한다면, 그것이 끌어들인 구매자들은 요청한 것을 정확히 얻되 기대한 것보다는 적게 얻는다. 반대로 고객이 통제하는 일정에 따라 자체 호스팅 에이전트가 개선되는 대안은 운영하기 더 어렵고 훨씬 더 가치 있다. IBM이 어느 쪽을 제공하는지가 앞으로 1년간 지켜볼 일이다.