Tithon의 구성 요소와 기술 제원

이번에 공개된 Tithon은 VS Code 확장 프로그램과 백그라운드 데몬(daemon)으로 구성된 REPL 노트북 도구다. 기존 Jupyter 노트북의 `.ipynb` 형식이 아닌 순수 파이썬 파일인 `.py`를 셀 단위로 실행하는 구조를 취한다. 실행 엔진으로는 표준 `ipykernel`을 그대로 사용하므로, 기존 파이썬 환경과 설치된 라이브러리를 별도의 수정 없이 그대로 활용할 수 있다.

데이터 저장소로는 SQLite 데이터베이스를 채택했다. 커널에서 발생하는 모든 셀 출력과 실행 상태는 실시간으로 이 데이터베이스에 기록된다. 이는 클라이언트와 서버의 연결이 끊어지더라도 실행 결과가 휘발되지 않고 물리적 저장소에 남도록 하기 위한 설계다. 설치를 위해서는 Python 3.11 이상의 버전과 Unix 계열 호스트 환경이 필수적이며, Windows 환경에서는 WSL(Windows Subsystem for Linux) 사용이 권장된다.

설치 및 환경 구성은 다음 명령어를 통해 수행한다.

pip install tithon
code --install-extension rnoro.tithon

상태 복구 메커니즘과 생명주기 분리

기존 Jupyter 환경에서 발생하는 출력 손실의 핵심 원인은 WebSocket 기반의 실시간 전달 방식에 있다. 커널은 계속 작동하더라도 클라이언트와 서버 사이의 WebSocket 연결이 끊기면, 그 사이에 발생한 출력값은 전달될 경로를 잃고 사라진다. 재연결 시에도 과거의 출력 기록을 복원하는 메커니즘이 부족해 사용자는 실행 결과 전체를 잃게 된다.

Tithon은 이를 해결하기 위해 'VS Code - 데몬 - 파이썬 커널'로 이어지는 3단계 생명주기 분리 구조를 도입했다. 우선 VS Code 확장 프로그램이 종료되거나 재시작되어도 백그라운드 데몬이 독립적으로 실행되며 작업을 유지한다. 더 나아가 파이썬 커널 역시 데몬과 별도의 프로세스로 실행된다. 만약 데몬이 재시작되더라도 커널 프로세스가 살아 있다면, 보존된 재접속 정보를 통해 기존의 변수, 모델, import 상태를 그대로 유지한 채 다시 연결할 수 있다.

이러한 구조적 차이는 기존의 대안들과 비교했을 때 명확한 차별점을 가진다. `tmux`를 이용한 Jupyter 서버 실행은 프로세스 유지에는 기여하지만, WebSocket 재연결 시의 출력 복원 문제를 해결하지 못한다. `jupyter-server-documents` 같은 확장 기능은 서버 측 실행을 통해 복원을 시도하지만, `tqdm.notebook`과 같은 HTML 기반 IPython 위젯 렌더링 오류나 반복적인 출력 갱신 표시 실패라는 제약이 있다. Tithon은 모든 출력을 SQLite에 저장하고 재접속 시 이를 다시 불러오는 방식으로 이 문제를 우회한다.

개발 환경의 변화와 도입 판단 기준

파일 포맷을 `.ipynb`에서 `.py`로 변경한 점은 협업과 자동화 관점에서 변화를 가져온다. JSON 메타데이터가 포함되지 않은 순수 파이썬 코드로 저장되기 때문에 `git diff`를 통한 변경 사항 확인이 명확해진다. 또한, 코딩 에이전트(AI)가 파일을 읽을 때 불필요한 JSON 구조를 해석할 필요 없이 코드 자체에만 집중할 수 있어 AI 친화적인 작업 환경을 제공한다.

활용 사례로는 네트워크 연결이 불안정한 원격 서버 환경에서의 딥러닝 모델 학습이나, 수 시간 이상 소요되는 데이터 분석 실험이 대표적이다. 클라이언트의 일시적인 튕김이나 네트워크 단절이 발생해도 SQLite에 저장된 실행 기록을 통해 작업 지점을 즉시 복구할 수 있기 때문이다.

불안정한 네트워크 환경에서 장시간 실행되는 실험을 수행하며, `.ipynb` 파일의 무거운 메타데이터로 인해 Git 관리의 어려움을 겪는 개발자는 Jupyter 대신 Tithon의 데몬 기반 구조를 도입해 출력 복구 안정성을 확보하는 것이 적절하다.