런타임이 핵심 무대로 떠오르며 DeepSeek, 에이전트 하네스를 오픈소스로 공개

DeepSeek는 8월 13일 첫 공개 에이전트 하네스를 출시하며, Google News의 한 헤드라인을 폐쇄형 에이전트 플랫폼에 대한 직접적인 도전으로 바꿨다. 이번 공개가 중요한 이유는 DeepSeek가 더 이상 모델만 제공하지 않기 때문이다. 모델이 도구를 사용하고, 세션을 관리하며, 코드를 실행하고, 더 긴 작업을 완료할 수 있게 하는 소프트웨어 계층까지 개방한 것이다.

DeepSeek Harness라는 이 계층은 MIT 라이선스 기반의 개발자 프리뷰로 제공된다. DeepSeek는 모든 주요 구성 요소가 플러그인이라는 하나의 핵심 원칙으로 아키텍처를 설명한다. 개발자는 애플리케이션 전체를 다시 구축하지 않고도 모델, 도구, 스킬, 샌드박스, 파일시스템, 인터페이스, 오케스트레이션 로직을 교체할 수 있다.

이번 공개는 DeepSeek의 경쟁 구도를 바꾼다. 회사 평가에 따르면 V4 모델은 이미 추론 및 에이전트 벤치마크에서 OpenAI, Anthropic, Google의 시스템과 경쟁하고 있다. 하네스는 경쟁의 중심을 모델 품질에서 완전한 에이전트 스택에 대한 제어권으로 옮긴다.

이것이 Google News listing 뒤에 놓인 실제 충돌이다. 오픈 모델은 한때 유용한 에이전트가 되기 위해 서드파티 소프트웨어에 의존했다. 이제 DeepSeek는 모델 자체만큼이나 주변 런타임도 개방적이고 유연하게 만들고자 한다.

Google News가 포착한 DeepSeek의 모델 이후 행보

DeepSeek Harness는 회사의 에이전트 전략을 통합 약속에서 공개 소프트웨어 프로젝트로 전환한다.

공식 developer preview는 dsh로도 불리는 DeepSeek Harness를 오픈소스 에이전트 하네스로 설명한다. 에이전트 하네스는 도구, 상태, 실행, 권한, 사용자 상호작용을 관리하는 모델 주변의 운영 소프트웨어다.

DeepSeek는 장착, 교체, 재구성이 가능한 구성 요소를 지원하도록 설계된 플러그인 지향 프레임워크 Cordis 위에 이 프로젝트를 구축했다. 회사는 간결한 주장으로 이 설계를 요약한다. 모든 것이 플러그인이라는 것이다.

이 원칙은 모델 선택을 훨씬 넘어선다. 에이전트에는 다음 행동을 결정하는 루프, 행동을 수행하는 도구, 관련 상태를 보존하는 저장소가 필요하다. 또한 통제된 실행 환경, 인터페이스, 그리고 이 요소들을 조율하는 규칙도 필요하다.

DeepSeek는 이러한 기능을 플러그인 경계 뒤에 배치한다. 이 접근 방식은 개발자가 주변의 모든 종속성을 다시 작성하지 않고도 한 계층을 교체할 수 있게 한다. 한 팀은 도구, 인터페이스, 세션 형식을 유지하면서 모델 제공업체만 변경할 수 있다.

그 반대도 가능하다. 개발자는 모델은 유지한 채 샌드박스, 도구 카탈로그 또는 오케스트레이션 전략을 변경할 수 있다. 이러한 유연성은 DeepSeek Harness를 하나의 고정된 어시스턴트와 엄격히 통제된 워크플로에 기반한 애플리케이션과 구분한다.

이 프로젝트는 npm 명령을 통해 로컬 웹 인터페이스를 실행할 수 있다. DeepSeek에 따르면 이 인터페이스는 기본적으로 로컬 머신에서 작동한다. 개발자는 소스를 복제하고, 종속성을 설치한 뒤 직접 빌드할 수도 있다.

이러한 세부 사항은 이번 공개가 단순한 프롬프트 템플릿 모음 이상임을 보여준다. DeepSeek는 여러 패키지, 네이티브 구성 요소, 문서, 예제, 개발 도구를 갖춘 애플리케이션 런타임을 공개하고 있다.

MIT 라이선스 역시 중요하다. 비교적 제한적인 의무 아래 상업적 사용, 수정, 재배포를 허용한다. 스타트업은 DeepSeek가 호스팅 서비스로 모든 기능을 공개할 때까지 기다리지 않고 구현을 검토하고, 이를 맞춤화하며, 제품을 구축할 수 있다.

다만 이 프로젝트는 명시적으로 미완성 상태다. DeepSeek는 개발자 프리뷰에 호환성을 깨는 변경이 적용될 것이라고 경고한다. 현재의 인터페이스와 구성 패턴은 안정적인 약속이 아니므로, 이 경고는 모든 초기 평가에 반영돼야 한다.

시점상 하네스는 DeepSeek V4와도 연결된다. 회사는 4월 V4 프리뷰 모델을 출시하고, 이를 중심으로 에이전트 관련 주장을 확대했다. 하네스는 이러한 모델이 지속적인 작업을 수행하는 데 필요한 실행 계층을 제공한다.

따라서 Google News 헤드라인은 눈에 보이는 사건만 포착한다. 더 깊은 변화는 전략적이다. DeepSeek는 지능 자체와 그 지능을 실제 업무에 투입하는 장치를 모두 정의하려 하고 있다.

에이전트 하네스가 이제 경쟁 계층이 됐다

모델은 결정을 생성하지만, 그 결정이 신뢰할 수 있는 행동으로 이어지는지는 하네스가 좌우한다.

언어 모델은 터미널 명령을 제안하고, 파일을 식별하거나, API를 선택할 수 있다. 하지만 상태를 추적하고, 요청을 검증하며, 실패를 처리하고, 결과를 반환하는 소프트웨어 없이는 이러한 단계를 안전하게 실행할 수 없다.

이 주변 소프트웨어는 점점 더 에이전트의 실질적인 품질을 결정하고 있다. 동일한 모델을 사용하는 두 제품도 하네스가 컨텍스트, 도구, 오류를 다르게 관리하기 때문에 매우 다르게 작동할 수 있다.

여러 파일에 걸친 코딩 작업을 생각해 보자. 모델은 먼저 저장소를 정확히 파악해야 한다. 파일을 선택하고, 수정하고, 테스트를 실행하고, 실패를 해석하며, 추가 수정이 필요한지 결정해야 한다.

각 단계는 일관되게 유지되어야 하는 상태를 만든다. 도구 출력은 올바른 세션으로 돌아와야 한다. 시스템은 실패한 명령과 완료된 명령을 구분하고, 에이전트가 부분 출력을 성공으로 오인하지 못하게 해야 한다.

긴 작업은 부담을 더욱 키운다. 컨텍스트는 커지고, 이전 결정을 찾기는 어려워지며, 반복되는 도구 호출은 오류 기회를 늘린다. 더 나은 모델은 도움이 되지만, 이러한 시스템 문제를 없애지는 못한다.

최근 agent harness research는 코드를 추론, 행동, 환경 모델링, 검증을 위한 운영 기반으로 규정한다. 또한 메모리, 감독, 공유 상태, 평가와 관련된 미해결 문제도 지적한다.

DeepSeek의 플러그인 구조는 이 문제의 일부에 대응한다. 개발자가 서로 다른 도구, 저장소, 인터페이스, 제어 루프를 삽입할 수 있는 명시적 위치를 제공한다. 이 아키텍처는 에이전트를 하나의 분리 불가능한 제품이 아니라 교체 가능한 서비스의 조합으로 다룬다.

이 차이는 워크플로를 누가 통제하는지에 영향을 준다. 폐쇄형 에이전트 애플리케이션은 일반적으로 어떤 도구가 존재하는지, 세션을 어떻게 표현하는지, 어떤 모델이 각 요청을 받는지를 결정한다. 사용자는 제품을 구성할 수는 있어도 내부 경계를 통제하는 경우는 드물다.

오픈 하네스는 이러한 선택지를 더 많이 노출한다. 기업은 도구가 어떻게 제공되는지 검토하고, 실행 전 정책 검사를 배치하거나, 민감한 행동을 더 엄격한 샌드박스 안에 격리할 수 있다.

또한 모든 워크플로를 하나의 공급업체 인터페이스로 보내지 않고도 에이전트를 사내 시스템에 연결할 수 있다. 이는 규제 대상 업무, 내부 개발 환경, 특수 인프라를 보유한 조직에 중요하다.

이 아키텍처가 자동으로 이러한 배포를 안전하게 만드는 것은 아니다. 오픈 코드는 검토를 가능하게 하지만, 검토에는 여전히 시간과 전문성이 필요하다. 잘못 구성된 오픈 하네스는 폐쇄형 하네스와 동일한 운영상 위험을 초래할 수 있다.

그럼에도 검토 가능성은 구매자의 선택지를 바꾼다. 팀은 동작을 추적하고, 통제를 수정하며, 호스팅 서비스의 방향이 바뀌더라도 작동하는 구현을 유지할 수 있다.

이 때문에 하네스는 경쟁 계층이 됐다. 모델 제공업체들은 한때 독립 프레임워크가 오케스트레이션을 맡을 것이라 예상했다. 이제 DeepSeek는 이 관계를 전적으로 외부 프로젝트에 맡기려 하지 않는 것으로 보인다.

DeepSeek Harness가 폐쇄형 에이전트 플랫폼에 가하는 압력

DeepSeek는 최상의 에이전트 경험이 독점 런타임에 계속 묶여 있어야 한다는 생각에 도전하고 있다.

Anthropic, OpenAI 등 제공업체들은 모델을 선별된 도구 및 세밀하게 조정된 실행 시스템과 결합한 에이전트 제품을 구축했다. 이들의 강점은 사용자 요청부터 결과 행동까지의 전체 경로를 통제하는 데서 일부 나온다.

이러한 통제는 일관된 제품 동작을 뒷받침한다. 공급업체는 프롬프트, 도구 형식, 컨텍스트 관리, 안전 점검을 함께 최적화할 수 있다. 여러 독립 유지관리자와 조율하지 않고도 모든 계층을 업데이트할 수 있다.

같은 통합은 의존성도 만든다. 고객은 다른 모델로 깔끔하게 이전할 수 없는 독점 세션 형식, 도구 인터페이스 또는 워크플로 동작에 의존하게 될 수 있다. 모델 교체만으로는 이 문제를 해결할 수 없다.

DeepSeek Harness는 반대의 제안을 내놓는다. 모델은 더 넓은 런타임 안의 하나의 플러그인이 되며, 다른 구성 요소는 교체 가능하게 남는다. 원칙적으로 팀은 나머지 에이전트 환경을 버리지 않고 다른 모델을 시험할 수 있다.

이는 단순히 DeepSeek와 한 미국 연구소 간의 경쟁이 아니라, 경로 대 통제의 경쟁이다. 폐쇄형 플랫폼은 수직 통합을 통한 정교한 경험을 약속한다. 오픈 하네스는 노출된 경계를 통한 적응성을 약속한다.

DeepSeek의 모델 위상은 이러한 약속을 무명의 프레임워크 공급업체가 제시할 때보다 더 설득력 있게 만든다. V4 release details는 100만 토큰 컨텍스트 윈도와 전용 에이전트 최적화를 갖춘 두 모델을 설명한다.

DeepSeek에 따르면 V4-Pro는 총 1조6,000억 개의 파라미터를 보유하며 추론 시 490억 개가 활성화된다. V4-Flash는 총 2,840억 개, 활성 130억 개로 제시된다. 이는 여전히 회사가 보고한 사양 및 성능 주장이다.

회사는 두 모델 모두 자사 서비스를 통해 사고 모드와 비사고 모드를 지원한다고도 말한다. 이는 하네스 개발자에게 다른 모델 계열로 전환하지 않고도 여러 성능 프로필을 제공한다.

그러나 하네스 아키텍처는 DeepSeek V4보다 더 광범위하다. 모델을 플러그인으로 다루는 방식은 개발자가 여러 제공업체와 배포 환경에 걸쳐 실험할 수 있을 때만 전략적 의미를 갖는다.

이 가능성은 모델 기업에 두 방향의 압력을 가한다. 첫째, 고객이 전체 에이전트 환경을 채택할 것이라 가정하지 않고도 모델 성능으로 경쟁해야 한다. 둘째, 독점 하네스는 더 강한 의존성을 정당화할 만큼 충분한 가치를 제공해야 한다.

기존 오픈 에이전트 프레임워크도 압박을 받는다. DeepSeek가 진입하는 시장은 비어 있지 않다. 개발자들은 이미 여러 모델을 지원하는 오케스트레이션 라이브러리, 코딩 에이전트, 터미널 어시스턴트, 자동화 프레임워크를 사용하고 있다.

DeepSeek의 강점은 모델 엔지니어링과 하네스 엔지니어링의 직접적인 조율이다. 런타임을 모델별 동작에 맞추는 동시에, 그 조정을 검토할 수 있도록 공개할 수 있다.

약점은 중립성이다. 독립 프레임워크는 어떤 모델 공급업체도 로드맵을 통제하지 않는다고 주장할 수 있다. DeepSeek는 사용자가 경쟁 모델을 선택하거나 DeepSeek 전용 구성 요소를 교체할 때도 플러그인 약속이 유의미하다는 점을 입증해야 한다.

회사의 자체 공개 문구만으로는 이 질문에 답할 수 없다. 개발자들은 대체 플러그인이 동등한 지원, 문서화, 유지관리를 받는지 시험해야 한다.

DeepSeek가 성공한다면 경쟁 단위는 달라진다. 구매자는 모델, 하네스, 플러그인 모음, 배포 경로를 함께 평가하게 된다. 벤치마크 점수만으로는 최종 에이전트 경험을 덜 설명하게 될 것이다.

모든 것을 플러그인으로 만드는 것은 하나의 문제를 해결하고 또 다른 문제를 만든다

모듈성은 선택지를 늘리지만, 교체 가능한 모든 구성 요소는 새로운 호환성 및 보안 경계를 만든다.

플러그인 아키텍처는 에이전트 시스템의 적응을 더 쉽게 만들 수 있다. 그러나 여러 독립적으로 구성된 구성 요소에서 동작이 나타나기 때문에 시스템을 이해하기는 더 어려워질 수도 있다.

한 기업이 기본 파일시스템 플러그인을 공유 엔지니어링 디렉터리에 연결된 플러그인으로 교체한다고 가정해 보자. 새 플러그인은 경로 제한을 적용하고, 심볼릭 링크를 처리하며, 승인된 워크스페이스 밖에 대한 의도치 않은 접근을 막아야 한다.

샌드박스 플러그인도 비슷한 책임을 진다. 어떤 명령을 실행할 수 있는지, 어떤 네트워크 접근이 가능한지, 프로세스가 환경에서 자격 증명을 읽을 수 있는지를 결정해야 한다.

이는 겉모습만 다듬는 구현 세부 사항이 아니다. 이러한 요소는 작업을 제안하는 어시스턴트와 회사 시스템을 변경할 수 있는 에이전트를 가르는 차이를 결정한다.

도구 권한에도 구조적 강제가 필요하다. 모델에게 프로덕션 데이터를 수정하지 말라고 지시하는 프롬프트는, 프로덕션 쓰기 작업 자체를 제공하지 않는 도구 계층보다 약하다.

플러그인 경계는 팀이 이러한 제한을 명시적으로 만들도록 도울 수 있다. 읽기 전용 데이터베이스 플러그인은 변경 메서드를 아예 제외할 수 있다. 하지만 이 보장은 인접한 모든 구성 요소가 같은 경계를 준수하는지에 달려 있다.

서드파티 플러그인은 공급망 위험을 초래한다. 유용한 확장 기능이 세션 기록, 도구 출력, 소스 파일 또는 인증 토큰에도 접근할 수 있다. 팀에는 이러한 리소스의 민감도에 걸맞은 검토 프로세스가 필요하다.

버전 변경이 잦으면 문제가 더 커진다. DeepSeek는 프리뷰 기간에 호환성을 깨는 변경이 발생할 것이라고 경고한다. 오늘 작동하는 플러그인이 핵심 인터페이스 변경 뒤에는 실패할 수 있고, 더 나쁘게는 변경된 동작으로 계속 실행될 수도 있다.

GitHub에서 빠르게 성장하는 이 프로젝트는 강한 관심을 보여주지만, 인기가 곧 프로덕션 준비 상태를 뜻하지는 않는다. 스타와 포크는 신뢰성, 보안 또는 유지보수 품질보다 관심도를 더 직접적으로 측정한다.

가장 중요한 평가 공백은 전체 작업에 관한 부분이다. 모델 벤치마크는 답변을 채점하거나 패치가 테스트를 통과하는지 검증할 수 있다. 하지만 중단된 도구 실행, 손상된 상태 또는 모호한 권한에서 얼마나 잘 복구하는지는 상대적으로 덜 드러낸다.

에이전트는 벤치마크에서 성공하면서도 민감한 시스템에 지속적으로 접근하기에는 부적합할 수 있다. 기업에는 긴 세션 전반에서 감사 가능성, 실패 격리, 재현 가능성에 관한 증거가 필요하다.

같은 우려는 메모리에도 적용된다. 하네스가 광범위한 컨텍스트를 보존할 수는 있지만, 유지된 정보는 오래되거나 작업 간 데이터를 노출할 수 있다. 더 많은 메모리가 자동으로 더 나은 메모리를 의미하지는 않는다.

지식 도구에는 추적 가능한 출처, 통제된 보존 정책, 관련 없는 프로젝트를 분리할 방법이 필요하다. 이미 검색 가능한 지식 기반을 구축하는 팀은 이를 자율 실행 루프에 연결하기 전에 이러한 통제 수단을 평가해야 한다.

DeepSeek의 아키텍처는 이러한 통제 수단이 자리할 수 있는 지점을 만든다. 그렇다고 모든 기본 플러그인이나 커뮤니티 플러그인이 이를 올바르게 구현한다는 뜻은 아니다.

이것이 핵심적인 트레이드오프다. 개방형 조합은 개발자에게 에이전트 설계에 대한 더 큰 권한을 준다. 동시에 검증, 통합, 유지보수에 대한 더 큰 책임도 개발자에게 넘긴다.

이번 릴리스가 DeepSeek V4의 에이전트 주장을 새롭게 규정하는 방식

DeepSeek Harness는 V4의 에이전트 성능이 벤치마크 조건 밖에서도 유지되는지 시험할 수 있는 공개 환경을 제공한다.

DeepSeek는 향상된 추론, 지식, 에이전트 기능을 갖춘 모델 패밀리로 V4를 소개했다. 회사는 V4-Pro가 에이전트 코딩 벤치마크에서 오픈 모델 중 선도적인 결과를 냈다고 밝혔다.

독립 보도는 이러한 결과를 신중하게 다뤘다. V4 출시 보도는 분석가들이 경쟁 성능에 대한 최종 결론을 내리기 전에 독립 평가를 원했다고 전했다.

에이전트에서는 점수가 모델과 하네스를 모두 반영할 수 있기 때문에 이러한 신중함이 더욱 중요해진다. 도구 설명, 재시도 로직, 컨텍스트 형식화, 실행 정책은 결과에 실질적인 영향을 줄 수 있다.

고도로 조정된 내부 하네스를 통해 평가된 모델은 범용 프레임워크를 통해서는 다르게 작동할 수 있다. 마찬가지로 주변 런타임이 더 나은 상태 관리와 검증을 제공하면 보통 수준의 모델도 개선될 수 있다.

DeepSeek Harness를 공개함으로써 연구자들은 또 하나의 검토 대상을 얻었다. 회사가 선호하는 런타임 내부의 V4와 독립 시스템 내부의 V4를 비교할 수 있다. 다른 모델도 DeepSeek 런타임을 통해 시험할 수 있다.

이러한 비교는 자주 하나로 섞이는 세 가지 질문을 분리할 수 있다. 모델의 역량은 어느 정도인가? 하네스의 효과성은 어느 정도인가? 두 구성 요소는 한 쌍으로서 얼마나 잘 작동하는가?

그 답은 도입 결정에 중요하다. 에이전트 플랫폼을 선택하는 기업에는 보고된 점수가 가장 높은 모델 이상이 필요하다. 자사의 파일, 도구, 정책, 실패 상황에서 일관되게 작동하는 시스템이 필요하다.

현실적인 코딩 평가는 문서화가 불완전한 리포지토리, 불안정한 테스트, 네트워크에 접근할 수 없는 종속성을 포함할 수 있다. 에이전트는 같은 실패한 작업을 반복 시도하는 대신 이러한 조건을 인식해야 한다.

기업 워크플로는 다른 요구 사항도 만든다. 시스템은 이메일을 보내거나, 레코드를 변경하거나, 콘텐츠를 게시하기 전에 승인이 필요할 수 있다. 각 작업이 어떤 지침에서 비롯됐는지를 보여 주는 증거도 보존해야 한다.

DeepSeek Harness는 구성 요소가 공개되어 있으므로 이러한 요구 사항을 둘러싼 실험을 지원할 수 있다. 연구자는 호스팅 제품 업데이트를 기다리지 않고 루프를 수정하고, 도구를 제한하거나, 세션 저장소를 교체할 수 있다.

하지만 공개 코드가 재현 가능한 결과를 보장하지는 않는다. 평가자에게는 고정된 버전, 문서화된 구성, 고정된 도구 환경, 완전한 실행 추적이 여전히 필요하다.

또한 결과가 DeepSeek의 최소 구성, 더 풍부한 도구 모음 또는 맞춤형 플러그인 스택에서 나온 것인지 공개해야 한다. 그렇지 않으면 하네스는 또 다른 오해를 부르는 비교 속의 보이지 않는 변수가 된다.

가장 공정한 시험은 동일한 권한과 리소스 아래에서 시스템을 비교할 것이다. 무제한 셸 접근 권한을 가진 모델을 차이를 설명하지 않은 채 제한적인 에디터만 사용할 수 있는 모델과 순위 비교해서는 안 된다.

따라서 Google News 독자는 이번 릴리스를 승리 선언이 아니라 시험하라는 초대로 받아들여야 한다. DeepSeek는 에이전트 동작 뒤의 장치를 공개했지만, 이를 측정하는 일은 여전히 커뮤니티의 몫이다.

개발자와 기업 구매자가 다음으로 지켜봐야 할 것

다음 증거는 출시 당일의 관심이 아니라 호환성, 독립적인 작업 결과, 강제 가능한 통제 수단에서 나와야 한다.

첫 번째 신호는 플러그인 상호운용성이다. 개발자는 프리뷰가 발전하는 동안 독립적인 모델, 도구, 스토리지, 샌드박스 플러그인이 계속 기능하는지 지켜봐야 한다.

건전한 플러그인 시스템에는 확장 지점만으로는 부족하다. 안정적인 계약, 마이그레이션 안내, 버전 호환성, 배포 전에 호환성 파괴 동작을 드러내는 테스트가 필요하다.

DeepSeek가 서드파티 제공업체를 지원하면서 이러한 관행을 발전시킨다면, 개방형 런타임에 대한 주장은 더 강해질 것이다. 플러그인이 반복적으로 깨지거나 문서화되지 않은 내부 구현에 의존한다면, 이 아키텍처는 개방적으로 보이지만 신뢰성 있게 이식되지는 않을 것이다.

두 번째 신호는 독립 평가다. 연구자는 동일한 하네스 안에서 DeepSeek V4와 경쟁 모델을 시험한 뒤, 서로 다른 하네스에서도 비교를 반복해야 한다.

이러한 연구는 최종 작업 완료만 측정해서는 안 된다. 유용한 지표에는 도구 실패 후 복구, 불필요한 작업, 권한 위반, 컨텍스트 손실, 완료된 작업의 재현 가능성이 포함된다.

결과는 단순 작업과 장기 워크플로도 분리해야 한다. DeepSeek는 V4-Flash가 단순 에이전트 작업에서 V4-Pro와 비슷한 성능을 보인다고 밝혔다. 더 긴 과제는 이러한 관계가 유지되는지 더 잘 드러낼 것이다.

DeepSeek의 성능을 재현하는 독립적 결과는 모델과 런타임이 경쟁력 있는 에이전트 스택을 이룬다는 회사의 주장을 강화할 것이다. 하네스별로 큰 성능 변화가 나타난다면, 오케스트레이션이 여전히 결정적 변수임을 보여줄 것이다.

세 번째 신호는 보안 거버넌스다. 기업은 권한 통제, 감사 로그, 플러그인 출처, 격리 보장, 취약점에 대한 명확한 정책을 찾아야 한다.

신뢰할 수 있는 보안 모델은 각 플러그인이 무엇에 접근할 수 있는지와 그 권한이 어떻게 강제되는지를 설명해야 한다. 또한 관리자가 프롬프트 지침에 의존하지 않고 기능을 취소할 수 있는 방법을 보여줘야 한다.

구매자는 세션을 재생, 내보내기, 삭제하고 워크스페이스별로 분리할 수 있는지 물어봐야 한다. 도구가 잘못된 형식의 데이터를 반환하거나 작업 중간에 플러그인을 사용할 수 없게 될 때 어떤 일이 발생하는지도 시험해야 한다.

또한 핵심 확장 기능을 누가 유지보수하는지 살펴봐야 한다. 폭넓은 파일시스템 또는 네트워크 접근 권한을 가진 커뮤니티 플러그인은 권한이 있는 내부 서비스와 동일한 수준의 검토를 받아야 한다.

DeepSeek의 개발자 프리뷰 경고는 이 과정 전체에서 계속 분명히 보여야 한다. 이 프로젝트는 통제된 실험에는 적합하지만, 회사는 이를 안정적인 기업 플랫폼으로 제시하지 않았다.

개별 개발자에게 가장 유용한 첫 시험은 범위가 제한된 로컬 워크플로다. 하네스에 폐기 가능한 리포지토리, 제한된 자격 증명, 검증 가능한 결과가 있는 작업을 제공하라.

결과만이 아니라 의사결정을 관찰하라. 어떤 파일을 읽는지, 어떤 명령을 실행하는지, 실패에 어떻게 대응하는지, 다른 사람이 그 과정을 재구성할 수 있는지 확인하라.

조직의 경우, 결정은 워크플로 소유권에서 시작해야 한다. 어떤 구성 요소가 이식성을 유지해야 하는지, 어떤 데이터가 통제된 인프라를 벗어나서는 안 되는지, 어디에서 사람의 승인이 의무적인지 결정하라.

그다음 전체 시스템을 비교하라. 신뢰할 수 없는 하네스와 결합된 저비용 모델은 값비싼 감독 업무를 만들 수 있다. 정교한 폐쇄형 에이전트 역시 런타임이 일상 운영의 중심이 되면 마이그레이션 비용을 초래할 수 있다.

Google News 기사가 중요한 이유는 DeepSeek가 그 선택을 더 명확하게 드러냈기 때문이다. 회사는 에이전트 인프라가 검토 가능하고, 조합 가능하며, 하나의 관리형 서비스 밖에서도 이용 가능해야 한다고 주장한다.

이 주장은 개방형 구성 요소가 실제 운영 압박 속에서도 함께 작동할 때에만 성공할 것이다. 호환성 실패, 약한 권한 경계 또는 일관성 없는 평가는 그 근거를 약화시킬 것이다.

개발자는 이제 검토할 수 있는 구체적인 결과물을 갖게 됐다. 다음 단계는 모든 것이 플러그인이라는 구호를 받아들이는 일이 아니다. 작업이 어려워졌을 때 그 플러그인이 여전히 이해 가능한 에이전트를 만들어 내는지 시험하는 일이다.

실제 도구를 에이전트에 맡기기 전에, 현재 AI 워크플로에서 어떤 부분을 통제해야 할까? 모델, 메모리, 권한, 실행 환경 중 무엇일까?