2026 DeepSeek Harness는 E2B 샌드박스인가, 지속 환경인가?

개인 실험에서는 작업을 다시 만들 수 있는지가 첫 기준입니다. 저장소에서 다시 내려받을 수 있고, 설치 명령이 문서화되어 있으며, 실행 결과를 파일로 회수할 수 있다면 샌드박스가 잘 맞습니다. 짧은 스크립트, 데이터 형식 변환, 외부에서 받은 코드의 정적 확인, 일회성 테스트가 여기에 해당합니다.

반대로 다음 조건이 있으면 지속 실행 환경이 더 직접적입니다.

• 여러 차례의 대화와 디버깅이 같은 프로세스에 의존합니다.
• 로컬 의존성 설치에 시간이 걸리고 재설치가 불안정합니다.
• 사람이 자주 개입해 명령을 승인하거나 수정합니다.
• 데이터베이스, 빌드 캐시, 세션 파일을 다음 작업에서도 사용합니다.
• 특정 저장소와 작업 공간을 계속 유지해야 합니다.

여기서 중요한 구분이 있습니다. 샌드박스의 수명과 DeepSeek Harness 세션의 수명은 동일하지 않습니다. E2B는 일시 정지할 때 파일 시스템과 메모리, 실행 중인 프로세스 상태를 보존할 수 있습니다. 하지만 샌드박스를 완전히 종료하면 다시 연결할 수 없습니다. Harness의 대화 기록, 승인 이력, 작업 식별자를 별도 저장하지 않으면 실행 환경을 보존해도 세션 복구가 되지 않습니다.

응용 개발 팀은 “작업이 길다”보다 “무엇이 남아야 하는가”를 먼저 적어야 합니다. 다음 목록에서 하나라도 남겨야 한다면 임시 환경만으로 설계하지 않는 편이 좋습니다.

• 저장소 외부에 설치된 개인 패키지
• 데이터베이스의 임시 스키마
• 빌드 캐시와 대형 종속 파일
• Harness가 생성한 세션 파일
• 사람이 수정한 작업 공간
• 다음 실행에서 반드시 이어야 하는 백그라운드 프로세스

반대로 저장소, 초기화 스크립트, 테스트 입력, 결과 폴더가 모두 재현되면 샌드박스 수명 종료를 장애가 아니라 정리 과정으로 취급할 수 있습니다.

E2B는 샌드박스에 사용자 세션이나 작업 식별자를 메타데이터로 붙이는 방식을 제공합니다. 이 메타데이터는 샌드박스를 다시 찾는 데 유용하지만, 파일 산출물 자체를 장기 보관하는 저장소와는 다릅니다. (e2b.dev) 따라서 팀은 최소한 다음 세 가지를 분리해 기록해야 합니다.

1. task_id: Harness가 발행한 작업 식별자
2. sandbox_id: 실제 실행 공간 식별자
3. artifact_uri: 로그, 패치, 테스트 결과가 저장된 위치

이 세 값 중 하나라도 빠지면 “세션은 남았지만 결과 파일이 없다”거나 “파일은 남았지만 어느 실행에서 만들어졌는지 모른다”는 문제가 생깁니다.

E2B를 클라우드 맥으로 이해하면 안 됩니다. E2B 공식 문서는 샌드박스를 에이전트가 코드를 실행하는 격리된 리눅스 가상 머신으로 설명합니다. (e2b.dev) 그러므로 Xcode, iOS 서명, Safari 자동화, Keychain, macOS 전용 프레임워크가 작업의 성공 조건이면 실제 맥 실행면이 필요합니다.

권장 흐름은 다음과 같습니다.

• E2B: 외부 코드 압축 해제, 정적 분석, 의존성 목록 확인
• 지속 맥 환경: 저장소 체크아웃, Xcode 빌드, 서명, Safari 검증
• 제어면: 승인 기록, 로그 연결, 결과 판정, 산출물 보관

이 구조는 E2B가 macOS 기능을 대신한다는 뜻이 아닙니다. 위험한 전처리와 플랫폼 종속 실행을 분리한다는 뜻입니다. 실제 호환성은 반드시 각 팀의 Xcode 프로젝트, 서명 프로파일, 브라우저 자동화, Keychain 정책으로 검증해야 합니다.

맥에서 DeepSeek Harness를 운영할 때 필요한 기본 조건과 맥 미니 대여 가격 확인을 함께 점검하면 지속 환경의 책임 범위를 정하기 쉽습니다.

플랫폼 팀에는 단일 환경보다 이중 구성이 실용적입니다. 지속 환경은 Harness 설정과 상태를 보존합니다. E2B는 코드 실행만 맡고 작업이 끝나면 폐기하거나 일시 정지합니다.

다만 이중 구성은 자동으로 안전해지지 않습니다. 파일을 복사하는 인터페이스, 네트워크 허용 범위, 비밀값 주입 방식, 산출물 검증이 모두 별도 정책이어야 합니다.

주의: E2B의 격리는 실행 위치를 나누는 기능입니다. 프롬프트 인젝션이나 데이터 유출을 자동으로 막아 주는 보안 판정은 아닙니다. 외부 입력이 샌드박스 안에서 실행되더라도 네트워크와 비밀값 권한이 열려 있으면 피해 범위가 커질 수 있습니다.

E2B는 샌드박스별 네트워크 허용 여부와 출입 규칙을 설정할 수 있고, 수명 주기 이벤트를 웹훅으로 전달할 수 있습니다. (e2b.dev) 플랫폼에서는 이 기능을 다음처럼 사용해야 합니다.

• 생성 시 요청 출처와 작업 식별자를 검증합니다.
• 기본 네트워크는 차단하고 필요한 목적지만 허용합니다.
• 생산용 토큰 대신 단기 토큰이나 읽기 전용 자격 증명을 사용합니다.
• 샌드박스 종료·일시 정지·재개 이벤트를 감사 로그에 기록합니다.
• 결과 파일은 허용된 확장자와 경로만 회수합니다.
• 실패하면 지속 환경으로 자동 승격하지 말고 사람의 승인을 받습니다.

환경 변수는 편리하지만 비밀 저장소와 같지 않습니다. E2B 문서도 명령 실행 단위 환경 변수가 운영체제 안에서 비공개가 아니라고 설명합니다. (e2b.dev) 따라서 AI Agent가 읽을 수 있는 값과 실행 프로세스가 사용할 수 있는 값을 구분해야 합니다.

재현성 확인 목록

• [ ] 새 환경에서 저장소만으로 실행할 수 있습니다.
• [ ] 설치 명령과 버전 잠금 파일이 있습니다.
• [ ] 작업 결과를 지정된 폴더로 모읍니다.
• [ ] 세션 기록을 샌드박스 밖에 저장합니다.
• [ ] 샌드박스 종료 전에 로그와 패치를 회수합니다.
• [ ] Xcode와 Keychain이 필요한 단계는 맥으로 보냅니다.
• [ ] 외부 입력에 생산용 비밀값을 전달하지 않습니다.
• [ ] 실패한 작업을 누가 인계할지 정했습니다.

비용을 단순히 실행 시간으로만 계산하면 안 됩니다. 샌드박스 방식은 환경 생성, 파일 업로드, 패키지 재설치, 결과 회수, 실패 재시도가 추가됩니다. 지속 환경은 항상 켜진 시간, 저장 공간, 접근 통제, 관리자의 점검 시간이 들어갑니다.

E2B의 일시 정지는 상태를 보존하지만, 정지 중인 서비스는 외부에서 접근할 수 없고 재개 뒤 연결을 다시 맺어야 합니다. 또한 공식 문서는 메모리 1 GiB당 일시 정지에 약 4초, 재개에 약 1초가 걸릴 수 있다고 설명합니다. (e2b.dev) 이 수치는 긴 세션에서 재연결 설계를 별도로 해야 한다는 뜻입니다.

E2B에는 샌드박스 수명과 독립적으로 데이터를 보존하는 볼륨 기능이 있지만, 공식 문서상 현재 비공개 베타로 안내됩니다. (e2b.dev) 따라서 이를 모든 팀의 기본 전제로 삼기보다, 현재 제공되는 저장 방식과 접근 정책을 먼저 확인해야 합니다.

1. 작업을 세 부류로 나눕니다. 폐기 가능, 상태 의존, macOS 의존으로 표시합니다.
2. 재현성 파일을 확인합니다. 저장소, 잠금 파일, 초기화 스크립트, 테스트 입력을 준비합니다.
3. 권한 표를 만듭니다. 네트워크, 비밀값, 외부 쓰기, 저장소 접근을 각각 읽기·쓰기·차단으로 정합니다.
4. 작업 식별자를 먼저 발급합니다. 세션, 샌드박스, 산출물을 같은 식별자에 연결합니다.
5. 폐기 작업을 E2B에서 실행합니다. 종료·일시 정지·재개 이벤트와 결과 회수를 확인합니다.
6. 상태 의존 작업을 지속 환경에서 실행합니다. 사람이 개입한 뒤에도 세션과 작업 공간이 유지되는지 확인합니다.
7. macOS 단계만 맥으로 넘깁니다. Xcode 빌드, 서명, Safari, Keychain을 실제 환경에서 검증합니다.
8. 실패 인계 규칙을 시험합니다. 자동 재시도 대신 승인 대기, 로그 보존, 책임자 알림이 작동하는지 확인합니다.

이번 주에는 작은 검증 작업 하나를 E2B에서 실행하고, 같은 작업의 장기 디버깅 버전을 지속 맥 환경에서 실행해 보시기 바랍니다. 두 결과를 비교하면 재설치 시간, 세션 복구, 파일 회수 누락이 바로 드러납니다.

DeepSeek Harness에서 E2B 샌드박스는 장기 작업에도 적합합니까?

장기 작업 전체를 E2B에 맡기는 방식은 신중해야 합니다. E2B는 일시 정지와 재개로 파일 시스템과 메모리 상태를 보존할 수 있지만, 실행 제한과 네트워크 재연결을 별도로 관리해야 합니다. 장기 디버깅, 고정 저장소, 자주 이어지는 사람의 개입이 핵심이면 지속 환경이 더 단순합니다.

Xcode가 필요한 AI Agent 작업을 E2B에서 실행할 수 있습니까?

E2B는 원격 격리 리눅스 가상 머신이므로 Xcode나 iOS 서명처럼 macOS 전용 도구 체인을 그대로 대신할 수 없습니다. 코드 분석과 비신뢰 입력 전처리는 E2B에서 처리할 수 있지만, 실제 빌드와 서명, Safari 검증, Keychain 접근은 통제된 맥에서 따로 확인해야 합니다.

E2B 샌드박스가 만료되면 DeepSeek Harness 세션도 사라집니까?

두 상태는 같은 개념이 아닙니다. Harness 세션 기록이 외부 저장소나 제어면에 저장되어 있다면 샌드박스가 종료되어도 대화와 작업 식별자는 남을 수 있습니다. 반대로 실행 중인 프로세스와 임시 파일은 샌드박스의 종료 방식에 따라 사라집니다. 세션, 파일, 산출물을 각각 저장해야 합니다.

고위험 코드 실행과 장기 작업 공간을 어떻게 분리합니까?

지속 환경에는 Harness 설정, 승인 기록, 저장소 연결과 같은 제어 기능만 남기고, 신뢰하지 않는 코드와 외부 입력은 별도 E2B 샌드박스에서 실행합니다. 실행 결과는 작업 식별자와 함께 검증한 뒤 필요한 파일만 회수합니다. 생산용 비밀값과 외부 쓰기 권한은 기본으로 전달하지 않아야 합니다.

현재 환경이 개인 맥이나 일반 서버에 머물러 있다면 장기 작업에서 세 가지 문제가 반복됩니다. 작업이 중단될 때 세션과 프로세스를 직접 복구해야 합니다. 여러 사람이 같은 저장소와 인증 정보를 공유하기 쉽습니다. Xcode, Safari, Keychain 단계가 별도 장비로 흩어져 인계 책임도 모호해집니다.

반면 E2B만으로 모든 문제를 해결할 수는 없습니다. macOS 전용 도구를 실행할 수 없고, 장기 작업에서는 파일 회수와 재연결 로직이 필요합니다. 그래서 맥 도구 체인과 장기 상태가 실제 업무에 포함되어 있다면, 해당 단계는 통제된 지속 맥 환경에 남기는 편이 낫습니다. MESHLAUNCH의 한국용 맥 미니 대여 환경은 이런 지속 실행 단계를 별도로 검토할 때 참고할 수 있습니다.

최종 기준은 간단합니다. 폐기 가능한 작업은 E2B, 플랫폼 종속 작업은 지속 환경, 두 작업이 함께 있으면 이중 구성입니다. 이번 주에는 작업 목록에 상태 보존과 macOS 의존성 표시부터 붙이십시오. 그 두 칸이 채워지면 어떤 실행면을 선택할지와 누가 결과를 책임질지가 함께 정리됩니다.