핵심 정리

이 책 전체를 읽어온 독자라면, 이제 marimo가 어떤 도구인지 몸으로 알고 있습니다. 설명으로 알기 전에 직접 만들어봤기 때문입니다. 이 챕터는 그 경험을 개념으로 정리하는 자리입니다.

marimo를 한 문장으로

marimo는 셀 간 변수 의존성을 DAG로 추적해 자동 재실행하고, 표준 Python 파일로 저장해 git 친화성과 재현성을 보장하는 반응형 노트북 환경입니다.

이 한 문장 안에 세 가지 가치가 들어 있습니다. PART 00 Ch01에서 처음 소개했던 그 세 가지입니다.

첫째, 반응형 실행. 셀 하나를 바꾸면 그 셀이 정의하는 변수에 의존하는 모든 셀이 자동으로 재실행됩니다. 위젯을 조작하는 순간 의존 셀이 따라옵니다. 사람이 직접 "지금 이 셀 실행" 버튼을 누를 필요가 없습니다.

둘째, 순수 .py 저장. Jupyter가 출력 데이터와 실행 카운터를 포함한 JSON으로 저장하는 것과 달리, marimo는 코드만 담긴 표준 Python 파일로 저장합니다. git diff가 깔끔하고, PR 리뷰가 명확하고, python notebook.py로 스크립트처럼 직접 실행할 수 있습니다.

셋째, 재현성. 변수 단일 정의 원칙과 DAG 기반 실행은 실행 순서에 의존하지 않습니다. 어떤 환경에서, 어떤 순서로 실행해도 동일한 입력에 동일한 출력을 얻습니다. Jupyter에서 "커널을 재시작하고 처음부터 다시 실행해야 제대로 된 결과가 나온다"는 경험이 marimo에서는 구조적으로 불필요합니다.

핵심 개념 요약

반응형 DAG 실행

모든 셀은 DAG(방향성 비순환 그래프)의 노드입니다. 셀이 정의하는 변수와 참조하는 변수가 엣지를 구성합니다. 어떤 셀이 재실행되면, 그 셀의 출력 변수에 의존하는 하위 셀 전체가 자동으로 재실행됩니다.

이 구조 덕분에 Jupyter에서 발생하던 hidden state 문제가 원천 차단됩니다. 셀을 삭제하면 그 셀이 만든 변수가 메모리에서 즉시 제거됩니다. 실행 카운터가 없고, 셀을 어떤 순서로 실행해도 결과가 일관됩니다.

변수 단일 정의(MB002)와 순환 금지(MB003)

marimo의 전역 네임스페이스에서 변수 하나는 반드시 하나의 셀에서만 정의해야 합니다. 같은 변수 이름을 두 셀에서 정의하면 MB002(multiple-definitions) 에러가 발생합니다. 셀 A가 셀 B의 출력을 참조하고, 셀 B가 다시 셀 A의 출력을 참조하면 MB003(순환 의존성) 에러가 발생합니다. DAG는 순환이 없어야 합니다.

이 두 규칙이 marimo 반응형 실행의 수학적 기반입니다. marimo check notebook.py로 파일을 에디터 없이 정적 검사할 수 있습니다.

순수 .py 저장과 git 친화성

marimo 노트북 파일은 Python 함수 모음입니다.

import marimo__generated_with = "0.23.10"app = marimo.App()@app.celldef _():    x = 10    return (x,)@app.celldef _(x):    result = x * 2    return (result,)

각 셀이 @app.cell 데코레이터를 붙인 함수입니다. 함수 매개변수가 입력 의존성이고, return 문이 출력 변수 목록입니다. 셀 출력(숫자, 그래프, 테이블)은 파일에 포함되지 않습니다. git diff는 코드 변경만 보여줍니다.

mo.ui 위젯과 반응형 연결

mo.ui.slider, mo.ui.dropdown, mo.ui.text 같은 위젯은 DAG의 노드입니다. 위젯을 전역 변수로 정의하고, 다른 셀에서 .value로 현재 값을 읽습니다. 위젯 값이 바뀌면 .value를 참조하는 모든 셀이 자동으로 재실행됩니다. 콜백을 작성할 필요가 없습니다.

mo.ui.table과 mo.ui.dataframe은 데이터프레임을 시각화하면서 동시에 선택 상태를 .value로 노출합니다. 테이블에서 행을 선택하면 그 선택이 변수로서 하위 셀에 흘러갑니다.

DuckDB SQL 셀과 데이터프레임

mo.sql()로 실행하는 SQL 셀은 내부적으로 DuckDB를 사용합니다. Python에서 정의한 Pandas나 Polars 데이터프레임을 SQL 쿼리에서 테이블 이름으로 직접 참조할 수 있습니다. SQL 셀의 결과는 Python 데이터프레임으로 받아 다음 셀에서 사용합니다. 위젯 값을 f-string으로 SQL에 삽입하면 위젯 조작 즉시 쿼리가 재실행됩니다.

캐싱

반응형 실행에서는 셀이 자주 재실행됩니다. 계산 비용이 큰 함수에는 캐싱 데코레이터를 씁니다.

• @mo.cache: 동일 입력에 대한 함수 결과를 메모리에 보관합니다.
• @mo.lru_cache: LRU 방식으로 최근 N개 결과만 유지합니다.
• @mo.persistent_cache: 결과를 디스크에 저장해 커널 재시작 후에도 재사용합니다.

마이그레이션

Jupyter .ipynb 파일은 marimo convert notebook.ipynb -o notebook.py 명령으로 변환합니다. 변환 후 MB002 등 정적 에러를 marimo check로 확인하고 수정합니다. ipywidgets의 interact, observe 패턴은 mo.ui 방식으로 재작성해야 합니다.

배포 — 앱 모드와 WASM

marimo run notebook.py는 앱 모드로 실행합니다. 편집 기능이 없고, 각 사용자 세션은 독립된 Python 프로세스를 할당받습니다. --host 0.0.0.0 --port 8080 옵션으로 외부 접근을 허용하고, Dockerfile로 컨테이너로 묶을 수 있습니다.

marimo export html-wasm은 Pyodide를 사용해 브라우저 안에서 Python을 실행하는 HTML을 생성합니다. 서버 없이 GitHub Pages 같은 정적 호스팅에 올릴 수 있습니다. 단, PyPI 패키지 중 C 확장을 포함하는 것은 WASM에서 동작하지 않습니다. marimo 에디터의 MW003(incompatible-package) 린트 규칙이 알려진 비호환 패키지를 import 분석으로 사전에 감지합니다.

운영과 보안

marimo run은 기본적으로 인증이 없습니다. 인터넷에 공개할 때는 리버스 프록시에서 인증을 처리해야 합니다. --token 옵션으로 단순 토큰 인증을 붙일 수 있습니다. 반응형 실행의 셀 재실행 체인은 변수 패널과 셀 함수 시그니처로 추적하고, marimo check로 정적 문제를 사전에 잡습니다.

PART별 한 줄 정리

정리

• marimo의 핵심은 DAG 기반 반응형 실행, 변수 단일 정의 원칙, 순수 .py 저장, 이 세 가지입니다.
• MB002(중복 정의)와 MB003(순환 의존성)을 이해하면 marimo의 실행 모델 전체가 설명됩니다.
• mo.ui 위젯은 위젯도 DAG 노드라는 원리의 자연스러운 연장이며, mo.sql()은 Python과 SQL을 반응형으로 연결합니다.
• 배포는 서버 모드와 WASM 모드 두 경로가 있고, 각각 적합한 상황이 다릅니다.
• marimo check는 에디터 없이도 정적 검사를 실행하며, CI에 통합할 수 있습니다.