기업용 AI의 성패는 어떤 모델을 고르느냐만으로 결정되지 않는다. 같은 모델을 써도 사내 시스템과 연결하고 작업을 통제하는 방식에 따라 실제 성과는 달라진다.
잘 고른 모델보다 잘 짠 시스템
Coinbase Forge, Shopify River, Ramp Inspect는 자체 AI 모델이 아니다. 모델은 외부에서 가져오고 사내 정보와 도구를 연결해 권한과 작업 순서를 관리하고 결과를 검증하는 시스템은 직접 만들었다. 경쟁력의 중심은 모델에서 ‘모델이 일하는 방식’, 즉 에이전트 하네스로 옮겨갔다.
Stripe, Coinbase, Ramp 역시 독립적으로 비슷한 구조의 시스템을 만들었다. LangChain은 이를 바탕으로 2026년 3월 Open SWE를 공개했다. 공통 요소는 격리된 샌드박스(외부 시스템과 분리해 코드를 실행하는 환경), 선별된 도구, 서브에이전트(큰 작업을 나눠 맡는 하위 에이전트), Slack, Linear, GitHub 연동이다. 도구를 많이 주는 것이 관건일까. 아니다. 모델에 필요한 정보와 권한만 주는 것이 관건이다.
Shopify도 River 아래에 공통 플랫폼 Aquifer를 뒀다. 세션 기록, 모델 호출, 샌드박스, 권한, 모니터링을 한곳에서 관리한다. 세션은 프로세스나 실행 환경이 바뀌어도 유지되는 작업 상태를 뜻한다. 새 에이전트도 플랫폼을 다시 만들 필요 없이 프롬프트와 스킬, 실행 정책만 추가하면 된다. 모델과 실행 환경은 분리하고 세션은 계속 보존하는 구조다.
성과는 모델보다 운영에서 나왔다
Shopify에서는 30일 동안 7,000명 이상이 River를 썼고 River가 참여한 머지 PR(코드 변경을 검토, 병합해 달라는 요청)은 3,536건이었다. 전사 PR 여덟 건 중 한 건꼴이다. 세션 중앙값은 19분, 도구 호출은 50회였다.
두 달 사이 머지율은 36%에서 77%로 뛰었다. 모델 성능 덕분일까. 아니었다. 사용자들이 실패 원인과 해결법을 사내 스킬에 계속 남긴 결과였다. River를 공개 Slack 채널에서만 쓰게 한 것도 같은 이유다. 한 사람의 해결법이 기록으로 남아 다음 작업에 쓰인다. 모델은 빌려도 개선의 자산은 회사에 남는다.
Coinbase Forge 역시 머지 PR의 5%를 처리하며 PR 순환 시간을 약 150시간에서 15시간으로 줄였다. 한편 Ramp는 코드 생성보다 검증에 집중했다. 실제 서비스와 비슷한 샌드박스에서 결과를 실행하고 스크린샷과 라이브 프리뷰로 확인했다. 강제 도입 없이도 Inspect가 만든 PR은 전체의 절반을 넘었다.
비용과 감사도 하네스가 좌우한다
Coinbase는 토큰 사용량이 늘었는데도 비용을 줄였다. 작업 난이도에 따라 모델을 나누고 반복되는 프롬프트는 캐시(입력을 저장해 두었다가 다시 쓰는 기능)로 처리하며 장애나 품질 저하 때 다른 모델로 돌린 덕분이다. Anthropic 기준 캐시 읽기 비용은 일반 입력 토큰의 10%다.
그런데 상용 도구에만 의존하면 이런 정책도 공급자의 기본값을 따라야 한다. 하네스를 소유하면 가격과 품질에 맞춰 모델과 캐시 기준을 바꿀 수 있다. 모든 것을 직접 만들 필요는 없다. Ramp도 인프라와 모델 API는 구매하고 사내 업무를 잇는 작업 흐름과 검증 과정만 운영한다.
하네스는 비용만이 아니라 감사 체계이기도 하다. 에이전트마다 권한을 나누고 모든 실행을 기록해야 사고가 났을 때 책임 소재를 가릴 수 있다. 직원 계정을 에이전트와 함께 쓰면 사람과 자동화 중 누가 행동했는지 알기 어렵다. 규제와 별개로 고유 신원, 권한 범위, 실행 기록은 나중에 급히 덧붙일 수 있을까. 어렵다.
무엇을 사고, 무엇을 직접 지을 것인가
모델과 대화형 IDE는 사서 쓰는 편이 현실적이다. 회사가 직접 가져갈 부분은 세션, 샌드박스, 게이트웨이(모델 호출과 내부 도구 접근을 중계, 통제하는 관문), 검증과 평가 체계다. 판단 기준은 회사 규모보다 ‘검증에 사내 시스템을 얼마나 연결해야 하는가’다.
에이전트가 오류 추적 도구와 피처 플래그(기능을 배포와 별개로 켜고 끄는 설정), 모노레포(여러 프로젝트의 코드를 하나의 저장소에서 관리하는 방식) 빌드, 프리뷰 환경까지 확인해야 한다면 범용 제품만으로는 부족하다. 반대로 검증이 npm test 한 줄로 끝난다면 별도 플랫폼의 이점은 작다. IDE 안의 대화형 작업은 상용 도구로 충분하지만 Slack의 버그 제보부터 코드 수정, PR, 모바일 빌드, 결과 보고까지 이어지는 비동기 흐름에는 사내 배선이 필요하다.
다만 하네스는 한번 만들고 끝나는 제품이 아니어서 전담 운영 인력이 필요하다. 초기에는 학습과 검증, 배포 절차를 다시 맞추느라 생산성이 떨어질 수도 있다. 효과도 작업에 따라 다르다. 단순한 신규 작업은 생산성이 35~40% 늘었지만 복잡한 레거시 작업은 개선 폭이 10% 이하였다. 기반 없이 코드만 빨리 늘리면 어떻게 되는가. 리뷰와 배포가 새 병목이 된다.
그래서 플랫폼 팀은 세션과 감사 로그, 격리 환경, 권한, 도구, 모델 선택과 캐시 정책을 관리해야 한다. 실패 경험을 사내 스킬로 되돌리는 일도 중요하다.
모델과 가격은 계속 바뀐다. 하지만 축적한 스킬과 실행 기록, 작업별 모델 선택 정책은 회사에 남는다. 기업이 직접 짓는 것은 모델이 아니라 모델이 안전하고 효율적으로 일하는 환경이다.
그래서 모델의 성능 격차는 시간이 지나며 좁아질 수 있지만 조직마다 다른 업무 절차와 검증 기준은 쉽게 표준화되지 않는다. 외부 기술이 빠르게 바뀔수록 내부 운영 방식은 더 오래 경쟁력의 차이를 만든다.