사용자가 제공한 데이터셋, 모델이 생성한 코드, 패키지 설치, 생성된 차트, 그리고 다운로드 가능한 출력물이 격리되고 관찰 가능한 환경에서 실행되어야 할 때, AI 데이터 분석가는 샌드박스 Python이 필요합니다. 실제 구현 흐름은 다음과 같습니다: 파일 업로드, 신뢰할 수 있는 코드로 스키마 검사, 모델에 계획 요청, 생성된 Python 검토, 제약된 샌드박스에서 실행, 출력 아티팩트 검증, 그리고 사용자에게 결과 표시.
AI 데이터 분석가 아키텍처: 업로드, 분석, 검토
제품 패턴은 표면적으로 간단합니다: 사용자가 CSV를 업로드하고 자연어 질문을 하면 유용한 테이블, 차트, 다운로드 가능한 파일을 기대합니다. 내부적으로 앱은 실제 부작용이 있는 소규모 에이전트 워크플로우를 실행합니다. 모델은 분석을 계획하고 Python 초안을 작성하며, 애플리케이션은 어떤 코드, 패키지, 파일, 네트워크 접근 및 출력이 허용되는지 결정합니다.
하나의 명확한 경로를 중심으로 첫 번째 버전을 구축하세요:
- 하나의 분석 작업에 대해 CSV 업로드를 수락합니다.
- 작업 범위의 샌드박스 작업 공간을 생성합니다.
- 모델에 Python을 요청하기 전에 소유된 스키마 검사 코드를 실행합니다.
- 모델에게 분석 계획을 요청한 다음, 파일 및 패키지 규칙을 따르는 스크립트를 요청합니다.
- 시간, 메모리, 디스크, 패키지 및 네트워크 제한을 두고 스크립트를 실행합니다.
- 알려진 출력 디렉토리에서 검증된 아티팩트만 수집합니다.
- 사용자에게 답변, 차트, 경고, 로그 및 다운로드용으로 선택된 파일을 보여줍니다.
이러한 분리는 책임을 명확히 합니다. 모델은 분석을 제안하고 설명합니다. 백엔드는 제품 정책과 오케스트레이션을 적용합니다. 샌드박스는 제한된 파일, 패키지, 시간, 메모리, 네트워크 접근 및 비밀로 코드를 실행합니다.
데이터 분석을 위한 Python 샌드박스 내부에서 실행되는 것은 무엇인가?
분석 작업 공간을 메인 애플리케이션 서버가 아닌 샌드박스 내부에 두십시오. 샌드박스는 하나의 분석 작업을 위해 좁은 입력 번들(업로드된 파일, 작은 매니페스트, 생성된 스크립트 및 승인된 런타임 구성)만 수신해야 합니다. 애플리케이션 백엔드는 인증, 결제, 사용자 신원, 장기 저장소 및 프로덕션 비밀을 해당 작업 공간 외부에 유지해야 합니다.
AI 데이터 분석가의 경우, 샌드박스는 일반적으로 다음 작업을 담당합니다:
| 샌드박스 작업 | 그곳에 속하는 이유 |
|---|---|
| 파일 스테이징 | 업로드된 CSV를 Python이 다루기 전에 스캔하여 격리된 작업 디렉토리로 복사할 수 있습니다. |
| 스키마 검사 | 앱은 전체 파일을 모델에 노출하지 않고 열 이름, 유형, null 비율, 행 수 및 샘플 값을 추론할 수 있습니다. |
| Python 실행 | 모델이 생성한 코드는 애플리케이션 서버와 떨어져 실행되며 시간 제한을 둘 수 있습니다. |
| 패키지 준비 | 승인된 종속성만 작업에 설치되거나 사용 가능하게 됩니다. |
| 차트 렌더링 | 플롯 이미지는 파일로 작성되어 다운로드 전에 검토됩니다. |
| 결과 패키징 | 최종 아티팩트는 알려진 출력 디렉토리에서 수집할 수 있습니다. |
| 정리 | 임시 파일, 생성된 코드 및 세션 상태는 삭제되거나 만료되도록 허용될 수 있습니다. |
모델의 프롬프트를 데이터보다 작게 유지하십시오. 스키마 요약, 정책이 허용하는 경우 몇 가지 대표 행, 열 설명, 사용자 의도 및 “모델을 훈련시키지 마십시오” 또는 "승인된 패키지만 사용하십시오"와 같은 제약 조건을 보내십시오. 원시 데이터셋은 제품이 노출을 늘릴 특별하고 검토된 이유가 없는 한 샌드박스 파일 시스템에 남아 있어야 합니다.
CSV 업로드 및 스키마 검사는 어떻게 작동해야 하는가?
모든 업로드를 신뢰할 수 없는 입력으로 취급하는 것부터 시작하십시오. 모델이 개입하기 전에 파일 유형, 크기, 인코딩, 구분 기호, 행 수, 열 수 및 의심스러운 수식을 검증하십시오. CSV는 나중에 열릴 때 스프레드시트 수식 실행을 트리거하는 값을 여전히 포함할 수 있으므로, 내보낸 파일도 대상 형식에 맞게 살균되어야 합니다.
실용적인 업로드 흐름은 다음과 같습니다:
- 사용자가 CSV를 앱에 업로드합니다.
- 백엔드는 작업 범위의 객체 키 또는 스테이징 경로 아래에 원본 파일을 저장합니다.
- 백엔드는 작업에 대한 샌드박스 세션을 생성합니다.
- 백엔드는 파일을 샌드박스 작업 디렉토리로 복사합니다.
- 작고 결정론적인 검사 스크립트가 파일을 읽고 스키마 요약을 생성합니다.
- 모델은 스키마 요약, 사용자 질문, 허용된 라이브러리 및 출력 요구 사항을 받습니다.
검사 단계는 모델이 생성한 코드가 아니라 소유한 결정론적 코드여야 합니다. 다음과 같은 간결한 JSON 요약을 생성할 수 있습니다:
{
"file": "sales.csv",
"rows": 84231,
"columns": [
{"name": "order_date", "type": "date", "null_rate": 0.01},
{"name": "region", "type": "string", "sample_values": ["NA", "EMEA", "APAC"]},
{"name": "revenue", "type": "number", "null_rate": 0.0}
],
"safe_sample_rows": 5
}
이 요약은 전체 데이터셋을 전달하지 않고 모델이 분석 초안을 작성할 수 있는 충분한 컨텍스트를 제공합니다. 민감한 워크로드의 경우 샘플 값을 줄이거나 제거하고, 열을 마스킹하거나, 사용자가 사용할 수 있는 열을 승인하도록 요구하십시오.
모델은 어떻게 Python을 안전하게 생성하고 실행하는가?
모델은 코드를 생성하기 전에 계획을 생성해야 합니다. 좋은 계획은 사용할 열, 실행하려는 변환, 생성할 것으로 예상되는 차트 및 쓸 출력 파일의 이름을 지정합니다. 이렇게 하면 애플리케이션에 정책 및 사용자 검토를 위한 체크포인트가 제공됩니다.
계획이 수락된 후, 좁은 계약을 따르는 Python을 요청하십시오:
input/디렉토리에서만 입력 파일을 읽습니다.output/디렉토리에만 아티팩트를 씁니다.- 승인된 패키지만 사용합니다.
- 작업 정책에서 명시적으로 허용하지 않는 한 네트워크 호출을 피합니다.
- 마지막에 구조화된 요약을 출력합니다.
- 필수 열이 누락된 경우 명확하게 실패합니다.
개념적 수준에서 오케스트레이션 루프는 다음과 같습니다:
job = create_analysis_job(user_id, uploaded_file)
sandbox = create_sandbox(job_id=job.id, timeout_seconds=300)
copy_file_to_sandbox(uploaded_file, sandbox_path="/work/input/data.csv")
schema = run_owned_schema_inspector(sandbox, "/work/input/data.csv")
plan = ask_model_for_analysis_plan(
user_question=job.question,
schema=schema,
allowed_packages=["pandas", "numpy", "matplotlib"],
output_contract={"directory": "/work/output", "formats": ["png", "csv", "json"]},
)
review_policy(plan)
script = ask_model_for_python(plan=plan, schema=schema)
review_static_code_policy(script)
result = run_python_in_sandbox(
sandbox=sandbox,
script=script,
working_dir="/work",
timeout_seconds=120,
memory_limit_mb=1024,
)
artifacts = collect_outputs(sandbox, "/work/output")
review_outputs(artifacts)
return_answer_to_user(result.summary, artifacts)
이는 제품 SDK 계약이 아닌 의사 코드입니다. 요점은 경계입니다: 생성된 코드가 검토되고, 타임아웃과 함께 실행되며, 알려진 디렉토리로 제한되고, 출력 수집 및 검토가 뒤따릅니다.
스크립트가 실패하면 오류 메시지와 작은 코드 발췌문을 모델로 다시 보내 수정하십시오. 무제한 로그를 보내지 마십시오. 오류 수정은 첫 번째 시도와 동일한 패키지, 파일, 네트워크 및 출력 정책을 유지해야 합니다.
AI 데이터 분석을 위한 제어된 Python 패키지 접근
패키지 접근은 많은 AI 데이터 분석가 데모가 위험해지는 부분입니다. 모델은 튜토리얼에서 보았기 때문에, 패키지 이름이 그럴듯해 보이기 때문에, 또는 사용자의 프롬프트가 제안했기 때문에 라이브러리를 요청할 수 있습니다. 앱은 이러한 제안을 제한 없는 패키지 설치로 바꾸어서는 안 됩니다.
데이터의 민감도에 맞는 정책을 사용하십시오:
| 패키지 정책 | 가장 적합한 경우 | 트레이드오프 |
|---|---|---|
| 사전 빌드된 이미지만 | 예측 가능한 분석 요구 사항이 있는 프로덕션 워크로드 | 가장 낮은 유연성, 가장 간단한 검토 표면 |
| 허용 목록 패키지 | 대부분의 CSV 분석 도우미 | pandas, 플로팅, 일반 통계 패키지에 대해 좋은 균형 |
| 버전 고정 설치 | 재현 가능한 분석 작업 | 패키지 유지 관리 및 취약점 검토 필요 |
| 캐시된 내부 미러 | 엔터프라이즈 또는 규제 데이터 워크플로우 | 더 많은 운영 작업, 공급망에 대한 더 나은 제어 |
| 사용자 승인 설치 | 신뢰할 수 있는 사용자를 위한 탐색 도구 | 더 유연하지만 더 느리고 명확한 경고 필요 |
첫 번째 프로덕션 버전의 경우 사전 빌드된 환경이나 짧은 허용 목록으로 시작하십시오. 대부분의 CSV 질문은 소규모 라이브러리 세트(pandas, numpy, matplotlib, seaborn, scipy, 때로는 scikit-learn)로 답변할 수 있습니다. 작업에 다른 패키지가 필요한 경우, 모델이 이유를 설명하게 한 다음 해당 요청을 인간 승인 또는 패키지 검토 워크플로우를 통해 전달하십시오.
패키지 이름, 버전, 소스 레지스트리, 설치 시간 및 패키지가 요청된 이유를 기록하십시오. 보안 팀이 종속성 스캐너 또는 프라이빗 레지스트리를 사용하는 경우, 에이전트가 이를 우회하도록 두지 말고 해당 프로세스와 통합하십시오.
차트 및 출력 파일 검증 방법
생성된 파일은 제품 경험의 일부이지만 신뢰 경계의 일부이기도 합니다. 차트가 잘못될 수 있습니다. CSV에 수식과 유사한 값이 포함될 수 있습니다. 노트북에 숨겨진 코드가 포함될 수 있습니다. ZIP에 예상치 못한 경로가 포함될 수 있습니다. 출력물을 단순히 다운로드할 파일이 아니라 검사할 아티팩트로 취급하십시오.
간단한 출력 계약을 정의하십시오:
{
"required_files": ["summary.json"],
"optional_files": ["chart-*.png", "filtered-data.csv"],
"blocked_extensions": [".exe", ".sh", ".bat", ".html"],
"max_total_size_mb": 25
}
완료된 각 작업에 대해 예상된 출력 디렉토리에서만 파일을 수집하십시오. MIME 유형, 확장자, 크기 및 경로를 검증하십시오. 이미지의 경우 미리보기용 썸네일을 생성하십시오. CSV 내보내기의 경우 파일이 Excel이나 Google Sheets에서 열릴 수 있으면 스프레드시트 수식을 이스케이프 처리하십시오. JSON 요약의 경우 UI에서 사용하기 전에 스키마에 대해 검증하십시오.
사용자가 결과를 다운로드하거나 공유하기 전에 검토 단계를 제공하십시오. 검토 화면에는 다음이 표시되어야 합니다:
- 원래 질문.
- 사용된 데이터셋 이름 및 스키마.
- 일반 언어로 된 분석 단계.
- 생성된 차트 및 테이블.
- 정책상 제외된 모든 열.
- 경고, 오류, 재시도 또는 패키지 요청.
모델은 서술적 설명을 작성할 수 있지만, 앱은 해당 설명을 샌드박스 실행의 파일 및 로그에 근거해야 합니다.
프로덕션 전 보안 체크포인트
AI 데이터 분석가는 보안 및 플랫폼 팀이 수행할 수 있는 작업에 대해 추론할 수 있는 경우에만 유용한 내부 도구입니다. 검토는 격리, 리소스 제한, 패키지 정책, 네트워크 동작, 비밀, 로그 및 삭제를 다루어야 합니다.
프로토타입을 넘어서기 전에 이 체크리스트를 사용하십시오:
| 체크포인트 | 답변해야 할 질문 |
|---|---|
| 격리 경계 | 한 사용자의 코드와 파일을 호스트 및 다른 사용자로부터 분리하는 것은 무엇입니까? |
| 파일 접근 | 생성된 코드가 작업 디렉토리만 읽을 수 있습니까, 아니면 더 넓은 스토리지를 볼 수 있습니까? |
| 리소스 제한 | CPU 시간, 메모리, 디스크, 프로세스 수 및 벽시계 시간을 제한하는 것은 무엇입니까? |
| 네트워크 정책 | 아웃바운드 네트워크 접근이 꺼져 있습니까, 허용 목록에 있습니까, 프록시됩니까, 아니면 완전히 열려 있습니까? |
| 패키지 정책 | 어떤 패키지를, 어디에서, 어떤 버전 제어로 설치할 수 있습니까? |
| 비밀 경계 | API 키, 데이터베이스 자격 증명 및 서비스 토큰이 명시적으로 범위가 지정되지 않는 한 샌드박스 외부에 유지됩니까? |
| 로그 | 명령, 패키지 설치, 오류, 파일 읽기/쓰기 및 출력 아티팩트가 기록됩니까? |
| 인간 검토 | 어떤 계획, 코드 조각, 패키지 요청 및 출력에 승인이 필요합니까? |
| 정리 | 샌드박스 상태, 업로드된 파일, 생성된 스크립트, 로그 및 출력이 언제 삭제됩니까? |
“코드가 탈출할 수 없다” 또는 "데이터가 유출될 수 없다"와 같은 절대적인 주장은 피하십시오. 실용적인 기준은 더 구체적입니다: 경계를 정의하고, 제어를 문서화하고, 실패 모드를 테스트하고, 예상치 못한 동작을 조사할 수 있는 충분한 감사 추적을 유지하십시오.
네트워크 및 패키지 정책의 경우, 패키지가 사전 빌드된 이미지나 제어된 미러에서 오지 않는 한 종속성 설치는 네트워크 이그레스의 한 형태임을 기억하십시오. 데이터셋이 민감한 경우 네트워크 접근은 기본적으로 차단되거나 엄격하게 허용 목록에 포함되어야 합니다. 분석가가 실시간 외부 데이터가 필요한 경우, 이를 자체 승인 및 로깅 경로가 있는 별도의 도구로 만드십시오.
실행 레이어로서의 Novita 에이전트 샌드박스 사용
Novita 에이전트 샌드박스는 AI 에이전트를 위한 격리된 상태 저장 실행 환경을 제공합니다. 현재 Novita 문서는 코드 실행, 종속성 설치, 파일 접근, 브라우저 사용 및 세션 간 실행 상태 유지를 지원하는 것으로 설명합니다. AI 데이터 분석가의 경우 이러한 기본 요소는 아키텍처의 실행 부분에 직접 매핑됩니다: 작업 공간 생성, 파일 이동, 분석 코드 실행, 아티팩트 수집, 그리고 세션 설계에 따라 상태 정리 또는 유지.
Novita 에이전트 샌드박스 SDK 및 CLI 문서는 Python 및 JavaScript/TypeScript에 대한 공식 SDK 지원을 나열하며, 이는 일반적인 애플리케이션 백엔드에 적합합니다. 샌드박스 파일 시스템 문서는 작업 범위의 작업 공간 내에서 CSV 파일과 생성된 아티팩트를 스테이징하는 데 유용한 고정 20GB 스토리지 공간이 있는 격리된 파일 시스템을 설명합니다.
구분을 명확히 유지하십시오:
- 이 기사의 구현 지침은 AI 데이터 분석가 앱을 위한 일반 아키텍처를 설명합니다.
- Novita 에이전트 샌드박스는 해당 워크플로우를 위한 샌드박스 실행 레이어를 제공할 수 있습니다.
- 애플리케이션은 여전히 사용자 인증, 데이터 보존 정책, 패키지 승인, 네트워크 정책, 출력 검토 및 게시/배포 결정을 소유합니다.
이러한 분리는 팀이 깔끔한 책임 모델로 구축하는 데 도움이 됩니다. 모델은 분석을 제안하고 설명합니다. 애플리케이션은 제품 정책을 적용합니다. 샌드박스는 코드, 파일, 패키지, 차트 및 로그를 메인 애플리케이션 서버에서 멀리서 처리할 수 있는 제어된 런타임을 제공합니다.
결론
가장 강력한 AI 데이터 분석가 설계는 "모델이 Python을 실행하게 하라"가 아닙니다. 이는 제어된 루프입니다: 데이터셋을 검사하고, 모델에 계획을 요청하고, 생성된 코드를 검토하고, 샌드박스에서 실행하고, 검증된 아티팩트를 수집하고, 사용자에게 발생한 일을 보여주고, 작업이 완료되면 상태를 정리합니다. 이 구조는 엔지니어링 및 보안 팀이 프로덕션 전에 평가할 구체적인 체크포인트를 제공하면서 사용자 경험을 빠르게 유지합니다.
이 패턴을 구축하는 팀의 경우 작게 시작하십시오: CSV 업로드, 스키마 검사, 짧은 패키지 허용 목록, 차트 출력, 엄격한 타임아웃 및 가시적인 검토 화면. 경계가 문서화되고 테스트된 후에만 더 넓은 패키지 접근, 네트워크 도구, 지속성 및 자동화를 추가하십시오.
FAQ
AI 데이터 분석가에게 샌드박스가 필요한 이유는 무엇인가요?
신뢰할 수 없는 파일, 모델이 생성한 Python, 패키지 요청, 차트 생성 및 다운로드 가능한 아티팩트가 결합된 워크플로우이기 때문에 샌드박스가 필요합니다. 해당 작업을 별도의 환경에서 실행하면 앱이 파일, 리소스, 패키지, 네트워크, 로깅 및 정리 제어를 적용할 수 있는 장소를 제공합니다.
모델이 전체 CSV를 볼 수 있어야 하나요?
일반적으로 아닙니다. 모델에 스키마 요약, 안전한 샘플, 열 설명 및 사용자 질문을 보내는 것으로 시작하십시오. 제품에 더 많은 데이터를 모델에 노출할 검토된 이유가 없는 한 원시 파일을 샌드박스에 보관하십시오.
패키지 설치는 허용할 수 있나요?
예, 하지만 제어되어야 합니다. 사전 빌드된 이미지, 허용 목록, 고정 버전, 프라이빗 미러 또는 승인 워크플로우를 사용하십시오. 모델이 생성한 코드가 검토 없이 공개 인터넷에서 임의의 패키지를 설치하도록 허용하지 마십시오.
앱이 사용자에게 반환해야 하는 파일은 무엇인가요?
알려진 출력 디렉토리에서 차트 이미지, 요약 JSON 및 살균된 CSV 내보내기와 같은 검증된 파일만 반환하십시오. 예상치 못한 확장자, 대용량 파일, 숨겨진 경로 및 출력 계약의 일부가 아닌 아티팩트를 차단하십시오.
이것이 컴플라이언스 보장인가요?
아닙니다. 샌드박스는 실행 아키텍처의 한 부분입니다. 컴플라이언스 및 보안 승인은 데이터, 위협 모델, 제어, 로깅, 보존, 검토 프로세스 및 배포 환경에 따라 달라집니다.
