1) 런타임 환경 격리

목적

• 패키지가 실제로 배포된 뒤, 사용자 시스템에서 안전하고 일관되게 실행되도록 보장하는 것 -> 즉 PyPI에 올라간 s2n이 현업에서 충돌 없이 동작해야 하는 환경
• 최종 사용자에게 문제가 생기지 않게 배포본을 감싸서 보호하는 것.

특징

• 운영 환경(OS, 패키지 버전, 의존성)이 확정된 상태
• 보안/안정성/성능이 우선
• Docker 이미지, AWS Lambda Layer, venv/conda 환경, system-level deps 등이 포함됨
• 변경은 매우 보수적
• 개발 편의 기능 거의 없음

예시 (s2n 기준)

• pip install s2n한 유저의 익명 서버
• 우리가 배포하는 도커 이미지
• CI 실행 환경 (테스트 -> 빌드 -> 배포)

2) 개발 환경 격리

목적

• 개발자마자 다른 로컬 환경에서도 동일하게 빌드/테스트가 재현되게 하기 위해 -> 팀원 5명이 모두 같은 버전 조건에서 s2n 코드를 수정하기 위해 필요한 환경
• 개발자가 쓰는 작업 공간을 깔끔하게 만드는 것

특징

• 개발자 편의를 위한 도구 포함 (Pytest, black, …)
• 소스 코드 수정/테스트/디버깅 중심
• 업데이트 자주 가능

예시

• .venv/ 안에서 개발
• pdm install로 dev dependencies 설치
• plugin 디버깅, scan-engine 실험
• FastAPI 개발 서버 띄워서 테스트

정리

플러그인 실행 로직을 개발 환경에서 실행하지 않고, 격리된 도커 컨테이너 안에서 실행시키는 구조. 즉 CLI/코드가 플러그인 실행 -> 내부적으로 docker exec 혹은 컨테이너 호출을 통해 실행

(1) 개발 환경

개발자가 로컬에서 명령 호출하면 플러그인 실행은 도커 안에서

dev 환경 (내 로컬)
  ↓   CLI 호출
docker exec ... s2n-plugin-runner ...
  ↓
컨테이너 내부에서 플러그인 실행

___ENV__ = "dev"

• 로컬에서 명령 실행
• 내부적으로 dev용 도커 컨테이너 자동 실행
• 모든 플러그인은 컨테이너 내부

(2) 런타임 환경

유저가 pip install s2n 해도 플러그인은 결국 s2n이 내장한 도커 이미지 내에서 실행

사용자 서버 ( pip install s2n )
  ↓
s2n CLI
  ↓ 내부적으로
docker exec ... run plugin
  ↓
컨테이너에서 실행됨

__ENV__ = "prod"

• 사용자는 pip로 받은 s2n 실행
• s2n 내부에서 prod용 도커 이미지 실행
• 플러그인 실행은 항상 prod 컨테이너 안에서 처리