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 Agent Sandbox 사용하기
Novita Agent Sandbox는 AI 에이전트를 위한 격리되고 상태 저장된 실행 환경을 제공합니다. 현재 Novita 문서는 코드 실행, 종속성 설치, 파일 접근, 브라우저 사용 및 세션 간 실행 상태 유지를 지원하는 것으로 설명합니다. AI 데이터 분석가의 경우, 이러한 기본 요소는 아키텍처의 실행 부분에 직접 매핑됩니다: 작업 워크스페이스 생성, 파일 이동, 분석 코드 실행, 아티팩트 수집 및 세션 설계에 따라 상태 정리 또는 유지.
Novita Agent Sandbox SDK 및 CLI 문서는 일반적인 애플리케이션 백엔드에 적합한 Python 및 JavaScript/TypeScript에 대한 공식 SDK 지원을 나열합니다. 샌드박스 파일 시스템 문서는 작업 범위 워크스페이스 내에서 CSV 파일 및 생성된 아티팩트를 스테이징하는 데 유용한 샌드박스용 20GB 고정 스토리지 공간이 있는 격리된 파일 시스템을 설명합니다.
구분을 명확히 유지하세요:
- 이 문서의 구현 지침은 AI 데이터 분석가 앱을 위한 일반적인 아키텍처를 설명합니다.
- Novita Agent Sandbox는 이러한 워크플로우를 위한 샌드박스 실행 계층을 제공할 수 있습니다.
- 귀하의 애플리케이션은 여전히 사용자 인증, 데이터 보존 정책, 패키지 승인, 네트워크 정책, 출력 검토 및 게시/배포 결정을 담당합니다.
이러한 분리는 팀이 명확한 책임 모델로 구축하는 데 도움이 됩니다. 모델은 분석을 제안하고 설명합니다. 애플리케이션은 제품 정책을 시행합니다. 샌드박스는 코드, 파일, 패키지, 차트 및 로그를 메인 애플리케이션 서버와 분리하여 처리할 수 있는 제어된 런타임을 제공합니다.
결론
가장 강력한 AI 데이터 분석가 설계는 "모델이 Python을 실행하게 하는 것"이 아닙니다. 이는 제어된 루프입니다: 데이터셋 검사, 모델에 계획 요청, 생성된 코드 검토, 샌드박스에서 실행, 검증된 아티팩트 수집, 사용자에게 결과 표시, 작업 완료 시 상태 정리. 이 구조는 사용자 경험을 빠르게 유지하면서 엔지니어링 및 보안 팀이 프로덕션 전에 평가할 구체적인 체크포인트를 제공합니다.
이 패턴을 구축하는 팀의 경우, 작게 시작하세요: CSV 업로드, 스키마 검사, 짧은 패키지 허용 목록, 차트 출력, 엄격한 시간 제한 및 눈에 보이는 검토 화면. 경계가 문서화되고 테스트된 후에만 더 넓은 패키지 접근, 네트워크 도구, 지속성 및 자동화를 추가하세요.
FAQ
AI 데이터 분석가가 샌드박스가 필요한 이유는 무엇인가요?
워크플로우가 신뢰할 수 없는 파일, 모델 생성 Python, 패키지 요청, 차트 생성 및 다운로드 가능한 아티팩트를 결합하기 때문에 샌드박스가 필요합니다. 해당 작업을 별도의 환경에서 실행하면 파일, 리소스, 패키지, 네트워크, 로깅 및 정리 제어를 적용할 수 있는 장소를 앱에 제공합니다.
모델이 전체 CSV를 볼 수 있어야 하나요?
일반적으로 아니요. 먼저 모델에 스키마 요약, 안전한 샘플, 열 설명 및 사용자의 질문을 보내세요. 제품에 모델에 더 많은 데이터를 노출해야 하는 검토된 이유가 없는 한, 원시 파일을 샌드박스에 유지하세요.
패키지 설치를 허용할 수 있나요?
예, 하지만 제어되어야 합니다. 사전 빌드 이미지, 허용 목록, 고정 버전, 프라이빗 미러 또는 승인 워크플로우를 사용하세요. 모델 생성 코드가 검토 없이 공개 인터넷에서 임의의 패키지를 설치하도록 두지 마세요.
앱이 사용자에게 반환해야 하는 파일은 무엇인가요?
차트 이미지, 요약 JSON 및 정리된 CSV 내보내기와 같이 알려진 출력 디렉토리에서 검증된 파일만 반환하세요. 예상치 못한 확장자, 대용량 파일, 숨겨진 경로 및 출력 계약의 일부가 아닌 아티팩트를 차단하세요.
이것이 규정 준수를 보장하나요?
아니요. 샌드박스는 실행 아키텍처의 한 부분입니다. 규정 준수 및 보안 승인은 데이터, 위협 모델, 통제, 로깅, 보존, 검토 프로세스 및 배포 환경에 따라 달라집니다.
