🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

관리형 딥 에이전트는 모델과 비즈니스 로직에 대한 개발자의 통제권을 유지하면서, 장기 실행·상태 보존·샌드박스·평가·채널·배포에 필요한 운영 인프라를 랭스미스가 맡는 코드 중심의 관리형 런타임이다.

📌 핵심 요약

• 관리형 딥 에이전트가 공개 베타로 제공되며, 개발자는 파이썬이나 타입스크립트로 에이전트를 작성하고 로컬에서 시험한 뒤 명령 하나로 랭스미스 관리형 런타임에 배포할 수 있다.
• 기반이 되는 딥 에이전트는 도구 호출, 작업 파일, 장기 문맥, 하위 에이전트 위임, 분야별 기술, 사람의 승인 절차를 묶은 오픈 소스이자 모델 비종속적인 에이전트 하네스다.
• 관리형 런타임은 내구성 있는 실행, 스트리밍, 스레드 상태 보존, 메모리, 격리된 샌드박스, 평가, 외부 채널, 사용자 식별, 일정 실행과 추적 등 공통 운영 기능을 제공한다.
• 에이전트는 저장소 안의 코드 중심 프로젝트로 구성되며, 배포 과정에서 프로젝트 컴파일, 컨텍스트 허브 동기화, 빌드 업로드, 호스팅된 랭스미스 배포 생성이 자동으로 처리된다.
• 현재 공개 베타는 미국 리전의 랭스미스 클라우드와 명령줄 인터페이스를 중심으로 제공되며, 사용자 정의 경로·고유 인증 로직·영속성 계층 직접 제어가 필요하면 랭스미스 배포를 직접 사용하는 방안이 제시된다.

🧩 주요 포인트

1. 오픈 소스 하네스와 관리형 운영을 분리해 모델·프롬프트·도구·미들웨어·업무 규칙은 사용자가 소유하고, 반복적인 실행·배포 인프라의 부담은 서비스가 맡도록 했다.
2. 에이전트를 짧고 무상태인 요청이 아니라 중단·재개·재시도·승인·파일 작업이 필요한 장기 상태형 프로세스로 다루며, 이에 맞는 내구성과 관찰 가능성을 기본 기능으로 제공한다.
3. 빠른 관리형 배포에는 적합하지만 모든 확장 요구를 대신하지는 않으며, 높은 수준의 사용자 정의가 필요할 때는 직접 랭스미스 배포를 사용하거나 오픈 소스 하네스를 자체 인프라에서 운영할 수 있다.

🧠 상세 정리

1. 공개 베타와 개발·배포 흐름

관리형 딥 에이전트는 2026년 8월 7일 공개 베타로 발표됐으며, 프로토타입에서 운영 규모로 전환할 때 기반 인프라를 직접 관리하지 않도록 설계됐다. 개발자는 파이썬 또는 타입스크립트로 딥 에이전트를 작성하고, 프로젝트를 초기화한 뒤 의존성을 설치해 로컬 랭스미스 스튜디오에서 실행할 수 있다. 명령줄 도구는 프로젝트 생성, 로컬 개발, 배포 단계를 각각 명확한 명령으로 제공하며, 배포 명령 한 번으로 관리형 런타임에 올리는 흐름을 지원한다. 이 과정에서도 개발자는 사용할 모델, 지침, 도구, 미들웨어, 하위 에이전트 등 에이전트의 핵심 구성을 직접 결정하고, 랭스미스는 영속성·메모리 마운트·기술 로딩·샌드박스 수명 주기·배포 같은 실행 영역을 담당한다.

2. 오픈 소스 딥 에이전트 하네스의 역할

딥 에이전트는 유용한 에이전트에서 반복적으로 나타나는 공통 패턴을 재사용 가능한 하네스로 묶은 오픈 소스 기반이다. 에이전트는 도구를 호출하고 작업 파일을 보관해야 하며, 실행이 길어질수록 증가하는 문맥을 관리하고 일부 작업을 하위 에이전트에 위임할 필요가 있다. 또한 특정 분야의 기술을 불러오거나 민감한 행동 전에 사람의 승인을 기다리는 절차도 요구될 수 있는데, 이 기능들을 매번 낮은 수준의 프레임워크 위에서 다시 구현하지 않도록 한 것이 하네스의 목적이다. 딥 에이전트는 특정 모델에 종속되지 않으므로 조직이 모델·지침·도구·업무 로직을 가져와 통제할 수 있고, 원한다면 오픈 소스 하네스를 선택한 인프라에서 직접 운영할 수도 있다.

3. 관리형 런타임과 코드 중심 프로젝트 구조

관리형 딥 에이전트는 하네스로 에이전트를 만드는 문제보다 그 에이전트를 실제 운영 환경에서 안정적으로 실행하는 문제에 초점을 맞춘다. 서비스는 일시 중단과 재개가 가능한 내구성 있는 실행, 진행 상황 스트리밍, 장애와 재시작을 견디는 상태 보존, 격리된 샌드박스, 평가, 외부 채널, 장기 메모리, 사용자 식별 같은 공통 운영 기능을 제공한다. 프로젝트는 저장소 안의 코드 중심 디렉터리로 유지되며, 에이전트 코드와 의존성 파일뿐 아니라 지침, 식별 규칙, 메모리 정의, 사용자 정의 도구, 채널, 미들웨어, 일정, 연결기, 기술, 샌드박스 설정, 평가 항목을 구조적으로 배치할 수 있다. 배포 명령을 실행하면 프로젝트가 컴파일되고 배포 소유 컨텍스트가 랭스미스 컨텍스트 허브에 동기화되며, 빌드 업로드와 호스팅된 배포 생성까지 이어진다.

4. 장기 상태형 에이전트를 위한 배포 기반

일반적인 운영 인프라는 요청이 짧게 끝나고 서버에 상태를 남기지 않는다는 가정을 두지만, 에이전트는 몇 분에서 몇 시간 또는 며칠 동안 실행될 수 있어 이 가정에 맞지 않는다. 에이전트는 사람의 승인을 기다리며 멈추거나 사용자 답변 이후 재개하고, 작업 과정을 스트리밍하며, 인프라가 재시작되어도 기존 상태를 잃지 않아야 할 수 있다. 따라서 내구성 있는 스레드, 영속 메모리, 취소와 재시도 정책, 모델 호출·도구 호출·파일·오류·런타임 상태를 연결하는 추적 기능이 운영 품질에 직접 영향을 준다. 관리형 딥 에이전트는 기존 랭스미스 배포 에이전트 서버를 기반으로 이러한 패턴을 딥 에이전트용의 더 명확한 런타임으로 묶으며, 직접 구축할 경우 수개월 이상 걸릴 수 있는 지속 실행·승인·인증·일정·상태 관리의 반복 부담을 줄이는 데 목적을 둔다.

5. 파일·코드 작업을 위한 격리형 샌드박스

파일을 조사하고 결과물을 작성하거나 시험을 실행하고 의존성을 설치하는 에이전트에는 통제된 실행 환경이 필요하다. 딥 에이전트는 이러한 작업을 위한 샌드박스 백엔드를 지원하며, 관리형 딥 에이전트에서는 랭스미스 샌드박스를 우선 지원 대상으로 제공한다. 기본 구성에서는 각각의 내구성 있는 스레드가 자체 샌드박스를 받아 사용자 대화나 작업별로 작업 공간을 분리하므로, 코딩 에이전트처럼 파일 상태가 중요한 사례에 적합하다. 반대로 여러 스레드가 하나의 환경을 공유해야 한다면 범위를 에이전트 단위로 설정할 수 있으며, 서비스가 샌드박스의 프로비저닝·수명 주기·정리를 관리한다. 샌드박스 안에서 발생한 활동도 랭스미스에 추적되기 때문에 실행 성공이나 실패 시 어떤 작업이 수행됐는지 조사할 수 있다.

6. 하버 기반 행동·상태 평가

이 글은 에이전트 평가가 최종 답변과 기대 답변을 비교하는 데 그쳐서는 안 되며, 답변에 도달하는 동안 어떤 행동을 했는지도 확인해야 한다고 설명한다. 올바른 도구를 호출했는지, 정확한 파일을 수정했는지, 필요한 산출물을 만들었는지, 마지막 작업 공간 상태가 과제와 일치하는지 같은 상태 기반 검사가 코드·파일 작업 에이전트에는 특히 중요하다. 관리형 딥 에이전트는 하버 과제를 초기화하고 컴파일하는 명령을 제공해, 저장소에 보관되는 평가 과제와 컴파일된 에이전트 산출물·실행 어댑터·예제 작업 설정을 포함한 인계 패키지를 생성한다. 하버 자체는 로컬 도커나 사용자가 구성한 별도 환경에서 직접 실행하므로 평가의 이동 가능성이 유지된다. 배포 후에는 모든 실행이 랭스미스에 추적되며, 운영 중 발견된 실패를 이후 평가 사례로 전환해 개발과 운영 사이의 피드백 순환을 만들 수 있다.

7. 업무 채널 연결과 장기 메모리

채널 기능은 에이전트를 사용자가 실제로 협업하는 도구에 노출하는 진입점으로 사용된다. 프로젝트의 채널 디렉터리에 정의 파일을 추가하면 런타임이 공급자 이벤트 엔드포인트를 마운트하고 서명을 검증하며, 사용자 식별 정보를 붙여 에이전트를 호출한 뒤 원래 대화로 응답할 수 있다. 슬랙에서는 앱 언급과 직접 메시지를 받아 자동 응답하도록 구성할 수 있어 별도의 통합 서비스를 새로 만들지 않고도 지원·운영·코드 검토 에이전트를 팀의 기존 대화 공간에 연결할 수 있다. 메모리는 단일 대화의 스레드 상태를 넘어 여러 대화에 걸쳐 선호와 문맥을 유지하는 기능으로, 배포마다 에이전트 범위의 메모리가 기본 제공되고 런타임에서는 메모리 파일 경로를 통해 읽고 쓴다. 재배포 시 프로젝트의 지침과 기술은 컨텍스트 허브에 동기화되지만 런타임에서 생성된 메모리는 보존되므로, 하네스 동작을 갱신하면서 기존에 축적된 문맥을 지우지 않을 수 있다.

8. 다중 사용자 식별과 접근 경계

관리형 딥 에이전트는 현재 기본적인 사용자 식별 모델을 제공하며, 향후 더 고도화된 인증과 자격 증명 흐름을 추가할 계획이라고 밝힌다. 현 단계에서는 고정된 자격 증명으로 에이전트를 실행할 수 있고, 프로젝트에 오픈아이디 연결 공급자를 정의하면 해당 공급자가 제공한 최종 사용자 식별자에 따라 스레드를 분리할 수 있다. 이에 따라 하나의 배포를 여러 사용자가 공유하더라도 각 사용자의 스레드가 서로 격리되며, 같은 식별 체계가 사용자별 메모리 범위와 향후 자격 증명 패턴의 기반이 된다. 중요한 점은 에이전트가 실행을 시작한 사용자를 프롬프트 문구나 위조 가능한 요청 필드로 추정하지 않고 신뢰할 수 있는 식별 정보로 확인하도록 했다는 것이다. 다만 글은 현재 모델을 기본 수준으로 규정하고 있으므로, 복잡한 사용자 정의 인증 로직이 필요한 경우에는 관리형 구성보다 랭스미스 배포를 직접 사용하는 선택지를 제시한다.

9. 도입 사례, 선택 기준과 공개 베타 범위

소개된 사용자 증언에서는 관리형 딥 에이전트가 특정 모델이나 연구 조직에 종속되지 않는 통합형 에이전트 인프라로 평가됐으며, 아이디어에서 운영 환경까지 걸리는 시간을 몇 주가 아닌 몇 시간으로 줄였다는 사례가 제시됐다. 한 사례에서는 교사 역할의 에이전트가 매일 전체 에이전트 실행을 검토하고 관찰 데이터와 실시간 평가를 바탕으로 개선을 이끄는 방식도 언급됐지만, 이는 해당 사용자의 경험을 인용한 내용이다. 제품은 오픈 소스 하네스를 기반으로 모델·프롬프트·도구·미들웨어·업무 로직을 통제하면서도 스레드, 메모리, 샌드박스, 채널, 일정, 평가, 추적을 빠르게 확보하려는 팀에 적합하다고 정리된다. 반면 사용자 정의 경로, 그래프와 함께 실행할 애플리케이션 코드, 고유 인증 로직, 영속성 계층에 대한 직접 제어가 필요하면 랭스미스 배포를 직접 사용해야 하며, 완전한 자체 운영을 원하면 오픈 소스 딥 에이전트를 선택한 인프라에서 실행할 수 있다. 현재 공개 베타는 미국 리전의 랭스미스 클라우드로 제한되고 명령줄 인터페이스를 우선 제공하며, 추가 리전과 배포 방식은 이후 제공될 예정이다.

🧾 핵심 주장 / 시사점

• 제품의 핵심 경계는 에이전트의 고유 행동과 공통 운영 기반을 분리하는 데 있다. 모델·지침·도구·업무 규칙은 사용자가 통제하고, 상태 보존·실행·배포·샌드박스 수명 주기는 관리형 런타임이 담당한다.
• 장기 실행 에이전트의 품질은 최종 출력뿐 아니라 중단과 재개, 재시도, 승인 대기, 파일 상태, 사용자 경계가 보존되는지에 좌우되므로 일반적인 무상태 요청 인프라와 다른 운영 원리가 필요하다.
• 하버 평가와 랭스미스 추적을 결합한 흐름은 에이전트가 무엇을 답했는지뿐 아니라 어떤 도구와 파일을 다뤘고 최종 환경을 어떻게 바꿨는지를 검증 대상으로 삼는다.

✅ 액션 아이템

• 공개 베타 관리형 딥 에이전트에서 파이썬이나 타입스크립트로 로컬 시험 후 명령 하나로 랭스미스 관리형 런타임 배포 경로를 점검한다.
• 오픈 소스 하네스와 관리형 운영 분리 기준으로 모델·프롬프트·도구·미들웨어·업무 규칙 소유 범위를 정의한다.
• 사용자 정의 경로·고유 인증 로직·영속성 계층 직접 제어 필요 시 랭스미스 배포 직접 사용과 오픈 소스 하네스 자체 인프라 운영을 비교한다.

❓ 열린 질문

• 장기 상태형 프로세스의 중단·재개·재시도·승인·파일 작업에서 관리형 런타임의 내구성과 관찰 가능성은 어느 수준인가?
• 미국 리전 랭스미스 클라우드와 명령줄 인터페이스 중심 공개 베타가 현재 배포 제약을 어떻게 만드는가?
• 격리된 샌드박스·평가·외부 채널·일정 실행이 필요한 업무에서 빠른 관리형 배포가 확장 요구를 대신하지 못하는 지점은 어디인가?