marimo vs Jupyter vs Streamlit
"marimo를 쓰면 Jupyter를 버려야 하나?", "Streamlit 대신 marimo로 앱을 만들어야 하나?" 이 질문에 답하는 챕터입니다. 도구마다 강점이 다르고, 선택 기준은 작업의 성격에 따라 달라집니다.
4축 비교표
| 항목 | Jupyter | marimo | Streamlit |
|---|---|---|---|
| 실행 모델 | REPL 순차 실행 | DAG 반응형 실행 | 스크립트 재실행(top-down) |
| Hidden state | 발생 가능 | 없음 | 없음 |
| 파일 형식 | JSON (.ipynb) | 순수 Python (.py) | Python (.py) |
| Git diff | 출력 포함 노이즈 | 코드만, 깔끔함 | 코드만, 깔끔함 |
| 재현성 | 실행 순서에 의존 | 결정론적 실행 | 결정론적 실행 |
| 인터랙티브 위젯 | ipywidgets (별도 설치) | 내장 mo.ui | 내장 st.* |
| SQL 지원 | 없음 (별도 라이브러리) | 내장 DuckDB SQL 셀 | 없음 (별도 라이브러리) |
| 앱 배포 | 별도 변환 필요 | marimo run | streamlit run |
| WASM 내보내기 | 없음 | 지원 | 없음 |
| 편집기 | JupyterLab / VS Code | 브라우저 내장 에디터 | 코드 에디터 |
| 학습 곡선 | 낮음 | 중간 (반응형 개념 이해 필요) | 낮음 |
| 주요 용도 | 탐색·분석·교육 | 분석 + 앱 통합 | 앱·대시보드 |
선택 가이드
marimo가 유리한 상황
- 팀원과 노트북을 git으로 공유하고 코드 리뷰를 받아야 할 때
- Jupyter 노트북의 hidden state 문제로 재현이 안 되는 경험을 반복했을 때
- 분석 코드를 그대로 인터랙티브 앱으로 배포하고 싶을 때 (marimo run)
- SQL과 Python을 같은 노트북에서 자연스럽게 혼합하고 싶을 때
- 서버 없이 브라우저에서 실행되는 노트북을 배포해야 할 때 (WASM)
- CI/CD 파이프라인에서 노트북을 스크립트처럼 실행해야 할 때
Jupyter를 유지하는 게 나은 상황
- ipywidgets 기반 기존 자산이 방대하고 전환 비용이 클 때
- 팀 전체가 JupyterHub 환경에서 작업하고 있을 때
- 교육·강의 환경에서 학생들이 이미 Jupyter에 익숙할 때
- GPU 클러스터 접속, 원격 커널 연결 등 Jupyter 생태계 인프라를 활용해야 할 때
Streamlit이 나은 상황
- Python 코드를 웹 앱으로 빠르게 공유하는 것이 주목적일 때
- 분석보다 UI·앱 구성에 집중해야 하고 노트북 워크플로우가 불필요할 때
- Streamlit Community Cloud에 원클릭 배포를 원할 때
- 팀이 Streamlit에 이미 익숙하고 대규모 마이그레이션 비용이 클 때
함께 쓰는 시나리오
세 도구를 동시에 쓰는 것도 현실적인 선택입니다.
- 탐색적 분석(EDA)에는 marimo가 적합합니다 (반응형 노트북, git 친화).
- 빠른 프로토타입 공유에는 Streamlit이 적합합니다 (낮은 학습 곡선, 원클릭 배포).
- 교육·강의 자료에는 Jupyter가 적합합니다 (생태계와 학생 익숙도).
핵심 차이 한 줄 요약
Jupyter는 탐색 도구, Streamlit은 앱 프레임워크, marimo는 그 사이의 교차점입니다. 분석 코드와 앱을 하나의 파일로 관리하면서 git 협업까지 원한다면 marimo가 가장 직접적인 선택지입니다.