에이전트가 옆 자리에 앉는다: 로컬 우선 LaTeX 워크스페이스 Lattice

왜 읽어야 하나

코딩 에이전트를 개발 환경에 붙이는 방법을 고민하는 플랫폼 엔지니어, 그리고 논문 작업에 에이전트를 쓰고 싶은 연구자를 대상으로 씁니다. 핵심 결론부터 말합니다. 에이전트를 “앱 안에 심는” 패턴은 Lattice가 보여준 것처럼 세 요소로 수렴합니다. 에이전트 런타임을 사용자 소유의 CLI로 두고, 모든 수정을 diff로 받아들이게 하고, 외부 지식은 MCP로 붙입니다. 이 패턴은 앱 하나가 혼자 하는 일로 끝나지 않습니다. 다키클라우드의 Paxis가 플랫폼 레벨에서 체계화하는 바로 그 작업이, 데스크톱 앱이라는 작은 규모에서 먼저 모습을 드러냈다는 점이 이 글의 이유입니다.

쉽게 말하면

글을 쓰는 책상을 한 방에 들여놓고, 연구 조교를 옆 자리에 앉힌다고 상상해 보세요. 조교는 손님이 가져온 도구(내 에이전트 CLI)를 씁니다. 조교가 원고를 고치면 즉시 정본이 바뀌지 않고, 종이에 붙여 놓는 고침 목록(diff)이 됩니다. 내가 한 장씩 고개를 끄덕이고(accept) 나서 비로소 원고에 반영됩니다. 안 되면 쓰레기통으로(undo·restore). 책상 위에는 내가 쓰는 문방구(TeX Live)만 두고, 조교는 문방구를 사러 가지 않습니다. 이 글에서 Lattice를 늘 이 책상 비유로 설명합니다.

개요

Lattice는 macOS용 로컬 우선 LaTeX 워크스페이스입니다. 한 창 안에 소스 편집기, 컴파일된 PDF, 인용할 논문 라이브러리, Overleaf 공동 저자 패널, 그리고 AI 에이전트 패널이 들어 있습니다. 프로젝트를 디스크 위의 일반 폴더로 두기 때문에 오프라인에서도 열리고, 다른 편집기로도 열리고, Git 관할 안에 남습니다. Overleaf는 저장소가 아니라 동기화 대상입니다.

만든 사람은 Tsinghua University IIIS 소속 학부생 @leoliuym입니다. 11월 6일(UTC), 소개 트윗과 함께 프로젝트를 알렸고, 그 뒤 릴리스가 계속 나오고 있습니다. 이 글의 기준 시점인 11월 9일(UTC) 아침에만 v0.16.1 릴리스와 새로운 push가 들어 왔습니다. 에이전트를 개발 도구에 붙이는 물결이 코딩 환경에서 논문 환경으로 넘어가는 시점에 나온, 그 첫 형태 중 하나로 읽을 수 있습니다.

README가 스스로를 “local-first, agent-first LaTeX writing app for macOS”라고 소개하는 점이 중요합니다. 에이전트 기능이 부가 기능이 아니라, 앱의 설계 전제 자체라는 뜻입니다. 앱은 자기 모델과 구독을 하나도 갖지 않습니다. 사용자가 Mac에 이미 로그인한 Claude Code나 Codex 같은 에이전트 CLI를 “데려온다(bring your own agent)”는 식으로 실행합니다. 즉 Lattice는 에이전트의 실행 환경이 아니라, 에이전트와 사람 사이에 두는 승인 테이블입니다.

이 도구는 무엇인가

기술적으로 Lattice는 Tauri 기반의 네이티브 데스크톱 앱입니다. 레포지토리의 주 언어는 TypeScript이고, 라이선스는 Apache-2.0입니다. 편집은 Tiptap과 CodeMirror, PDF 표시는 PDF.js, 도킹 패널 레이아웃은 Trellis, 슬라이드는 React 덱 오픈소스 Open Slide를 씁니다. 에이전트 패널 뒤의 런타임은 Synara이며, T3 Tools Inc.가 참여한 프로젝트입니다.

작업대 구조는 아래 그림과 같습니다. 핵심은 에이전트 패널이 프로젝트 폴더를 직접 고치지 않는다는 점입니다. 에이전트 CLI가 파일을 고치면, Lattice는 그 변경을 diff로 받아서 내 승인을 기다립니다.

flowchart TB
    P[프로젝트 폴더<br/>.tex 소스 + PDF + 메모 + 슬라이드]
    subgraph L["Lattice 데스크톱 셸 (Tauri)"]
        E[소스 편집기<br/>CodeMirror + TeX 진단]
        V[PDF 뷰어<br/>PDF.js + SyncTeX 양방향 점프]
        R[논문 라이브러리<br/>arXiv · DOI · BibTeX · Zotero]
        O[Overleaf 동기 패널<br/>라이브 프레전스 + 댓글 + 변경 추적]
        A[에이전트 패널<br/>diff 검토 + 승인/거절]
    end
    C["에이전트 CLI<br/>Claude Code · Codex · Cursor 등 (사용자 계정)"]
    M[MCP 서버<br/>Zotero · Heptabase]
    T[내 TeX Live<br/>원클릭 빌드 + arXiv 수출 ZIP]
    P --> E
    E --> V
    P --> R
    O -.공동 저자 편집 라이브 유입.-> P
    A --> C
    C -.MCP 커넥터.-> M
    E --> T
    A -.수정 제안은 diff로만.-> P

주요 기능은 세 축으로 묶입니다. 첫 번째는 작성입니다. 소스와 PDF를 나란히 두고 SyncTeX로 양쪽을 점프하고, 내 TeX Live로 원클릭 빌드합니다. NeurIPS, ICML, ICLR, ACL, CVPR, AAAI 템플릿과 학위 논문 클래스 두 개에서 시작할 수 있고, arXiv 수출은 스스로 빌드되는 한 개 ZIP으로 나갑니다. 인용 키에 마우스를 올리면 해당 참고 문헌이 표시되고, 여섯 가지 하이라이터가 아직 손이 필요한 곳을 표시합니다.

두 번째는 검토입니다. 지문을 선택해서 교정하거나 문장을 다듬으면, 에이전트가 수정과 함께 그 이유를 붙입니다. 소스든 PDF든 주석을 달아 두고 라운드로 검토를 돌리면, 에이전트가 각 주석에 대해 수정을 제안하고 내가 해당 자리에서 승인하거나 거절합니다. 그 주석은 내 선택에 따라 컴파일된 PDF의 표준 PDF 주석으로 수출되어, Preview나 Acrobat, Zotero에서 동료와 공유합니다.

세 번째는 공동 작업입니다. Overleaf 양방향 동기에서 라이브 프레전스, 채팅, 댓글, 변경 추적이 열립니다. 공동 저자는 Overleaf에 머물러도 되고, 그 사람의 편집은 타이핑되는 즉시 내 작업대로 들어옵니다. 변경 추적 모드는 Overleaf 요금제 없이 내가 한 편집을 소스와 PDF 양쪽에 표시하고, 하나씩 또는 일괄 승인·거절하게 합니다. 어떤 두 버전이든 비교해서 latexdiff로 표시된 PDF를 내보냅니다.

네 번째 축은 형식 다양성입니다. 같은 프로젝트 안에 마크다운 메모(블록 편집), tldraw 화이트보드, 인터랙티브 HTML 페이지, 수식기가 있는 스프레드시트가 함께 살아 있습니다. 슬라이드는 Open Slide가 움직이는 React 덱입니다. 편집과 주석, 에이전트 수정, 그리고 Lattice 안에서의 발표까지 이 덱 위에서 합니다. 프로젝트 폴더가 이 모든 것의 공통 저장소라는 점이 구조의 핵심입니다. 에이전트가 다뤄야 할 대상을 .tex 한 곳으로 좁혀 두지 않고, 메모와 화이트보드와 슬라이드까지 같은 책상 위에 두는 것입니다.

설치 및 통합

공식 빌드는 서명되고 Apple이 노타라이즈했으며, 자체 업데이트가 되는 .dmg 형태입니다. Apple 실리콘 Mac과 인텔 Mac 둘 다, macOS 14 이상에서 동작합니다.

# 1. 최신 릴리스에서 .dmg 다운로드 (Apple 실리콘)
#    github.com/leo1oel/lattice/releases/latest
#    Lattice_0.16.1_aarch64.dmg 를 Applications 에 드래그

# 2. TeX 가 없는 Mac: BasicTeX 설치를 제안받는 것 자체가 시작 체크리스트의 첫 단계
#    (MacTeX 또는 TeX Live 를 이미 두고 있으면 그것을 그대로 쓴다)

# 3. (실험) Linux: x86_64 AppImage (Ubuntu 22.04 이상, Fedora 45 계열)
chmod +x Lattice_*.AppImage
./Lattice_*.AppImage

프로젝트를 열거나, 템플릿에서 시작하거나, Overleaf 프로젝트에 연결하는 세 갈래로 진입합니다. 프로젝트 메뉴의 안내 튜토리얼은 샘플 논문을 여섯 단계 체크리스트로 이끕니다. PDF를 빌드하는 것부터, 에이전트가 한 단락을 고치게 하는 것까지. Linux 실험 빌드에서는 내장 에이전트 패널이 아직 제공되지 않는다는 점이 명시되어 있습니다.

프로젝트가 Git 리포지토리라면 Git 패널이 열립니다. 변경 사항과 풀 리퀘스트를 Lattice 안에서 보고, 책상의 서랍을 버전 관리하는 셈입니다.

실제 검증 (이 머신에서의 재현 기록)

저희는 이 글을 쓰던 홈 머신에서 Lattice를 .dmg 설치하고, BasicTeX를 도입하고, 실제로 빌드하는 재현을 시도했습니다. 재현 시도 중 실패: 비인터랙티브 세션에서 제삼자 데스크톱 앱 설치와 수십 기가바이트의 TeX 패키지 도입은 승인 대상이라, 이 실행에서는 하지 않았습니다. 대신 공개 산출물 기준으로 확인을 대체했습니다. 확인한 내용과 시점은 아래 표에 둡니다.

확인 항목	내용	확인 시점 (UTC)
최신 릴리스	v0.16.1, aarch64·x64 dmg와 .app.tar.gz(자동 업데이트용), amd64 AppImage	2026-11-09 04:44
레포지토리 활동	마지막 push 2026-11-09 10:20, 스타 375개 (GitHub API 실측)	2026-11-09
라이선스·언어	Apache-2.0, TypeScript (GitHub API 실측)	2026-11-09
공식 사이트	“Lattice, a local LaTeX workspace for your research”, 데모·릴리스·개발 문서 링크 확인	2026-11-09

릴리스 번호가 0.16.1인 점을 짚어 둡니다. 소수점 둘째 자리까지 16회를 지나고 패치까지 나온, 활발한 개발 단계의 프로젝트입니다. 동시에 0.x입니다. 공개 API나 저장소 포맷의 안정성을 전제로 내부 워크플로에 심기에는 아직 젊은 편입니다.

ThakiCloud 제품 적용 시사점

Lattice는 Paxis가 답하고 있는 질문의 작은 규모의 실물 사례입니다. “에이전트를 생산 라인에 붙일 때, 사람과 에이전트 사이에 어떤 테이블을 두는가.” Lattice의 테이블은 세 가지입니다.

첫째, 런타임의 소유권은 사용자 몫입니다. Lattice는 모델을 갖지 않고, 사용자가 로그인한 CLI를 씁니다. Paxis의 관점에서는 이것이 “에이전트 런타임 중립”입니다. 어떤 에이전트 엔진이 와도, 플랫폼은 승인 테이블과 감사 기록을 제공합니다. 앱 하나가 CLI를 고르는 것처럼, Paxis도 특정 모델이나 프론트엔드에 묶이지 않고 에이전트 실행 위에 제어 평면을 둡니다.

둘째, 모든 에이전트 수정은 diff로 들어오고, 승인 단위입니다. “에이전트가 파일 시스템에 직접 쓸 수 있다”는 전제는 Lattice에서 한 단계만 지나면 사라집니다. 에이전트는 제안하고, 사람이 받아들이고, 거절하면 원상이 됩니다. Paxis가 일급 리소스로 다루는 정책 게이트와 감사 로그의 데스크톱 버전이 이것입니다. 에이전트 작업 자동화의 실행 경제는 결국 “승인 한 번의 비용”으로 결정됩니다. 테이블이 좋은 만큼, 사람이 더 자주 고개를 끄덕이고(accept), 에이전트가 더 멀리 갈 수 있습니다.

셋째, 외부 지식은 MCP로 붙습니다. Zotero나 Heptabase 같은 메모·참고 문헌 도구가 에이전트 CLI의 MCP 서버로 들어옵니다. Lattice는 그 도구를 다시 구현하지 않습니다. Paxis의 MCP 커넥터가 OAuth 자동 재연결까지 다루는 것과 같은 논리입니다. 지식을 갖고 있는 도구는 제자리에 두고, 에이전트가 그 자리에 가서 쓰는 식입니다.

반대로 Lattice가 보여주지 못하는 부분도 시사합니다. 승인은 사람 한 명이, 한 책상 앞에서 합니다. Paxis가 플랫폼 레벨에서 풀어야 하는 것은 이 승인 테이블을 팀과 조직 단위로, 그리고 비동기로 확장하는 일입니다.

한계 및 반론

한계는 여섯 개로 압축합니다. 첫째, 에이전트 패널은 macOS 전용입니다. Linux 실험 빌드에는 아직 없습니다. 둘째, 사용자는 에이전트 CLI의 구독과 토큰 비용을 스스로의 몫으로 둡니다. 앱이 공짜라도, 조교의 임금(추론 비용)은 내가 냅니다. 셋째, 책상 하나, 사람 한 명의 도구입니다. 승인 테이블이 비동기·다수인 구조가 아니어서, 팀 규모의 논문 공동 작업에서는 Overleaf가 여전히 중심입니다. 넷째, 0.x 단계의 단일 주력 개발자 프로젝트입니다. Apache-2.0이라 코드는 계속 살지만, 앱 운영의 지속성은 레포지토리 활동만으로 판단할 일입니다. 다섯째, TeX Live 의존이라는 본질적 무게를 덜어내지 못합니다. LaTeX가 선택이 아니라 전제인 영역(학위 논문, 학회 투고) 밖에서는 책상의 필요성이 약해집니다. 여섯째, “agent-first”는 포지셔닝입니다. 에이전트가 실제 투고 논문을 얼마나 많이 고쳐 냈는지에 대한 공개 기록은 아직 없으므로, 이 글의 기술 분석은 README와 릴리스 산출물 기준으로 한정합니다.

반론도 한 번 세워 봅니다. “터미널에서 Claude Code를 돌리면서 기존 LaTeX 편집기를 쓰는 것”과 무엇이 다른가, 라는 물음입니다. Lattice의 답은 세 가지입니다. diff 승인 테이블을 편집 화면 안에 두고, SyncTeX·latexdiff·PDF 주석 수출 같은 검토 도구를 에이전트 수정에 그대로 적용하며, 논문 라이브러리와 Overleaf 댓글을 같은 창에 모은다는 것입니다. 이 답이 성립하려면, 사용자 자신이 리뷰 중심의 글쓰기를 해야 합니다. 에이전트에게 시키기만 하는 사용자에게는 책상의 이점이 줄어듭니다.

정리

Lattice는 에이전트를 앱에 넣는 것이 아니라, 사람과 에이전트 사이에 테이블을 놓는 패턴의 현재형입니다. 런타임은 사용자 소유, 수정은 diff, 지식은 MCP. 이 세 요소를 데스크톱 규모에서 검증해 본 사례가, Paxis가 플랫폼 규모에서 체계화하는 작업의 모양을 미리 보여 줍니다. 논문 워크플로가 주 업무라면 오늘 설치해서 체크리스트를 끝까지 돌려 볼 만하고, 에이전트 앱 설계를 한다면 “승인 테이블을 어디에 두는가”를 먼저 묻는 것부터 시작해 보십시오. 에이전트가 옆 자리에 앉았을 때, 책상의 품질이 생산의 품질이 됩니다.

---

출처

• Lattice 공식 사이트: https://leo1oel.github.io/lattice
• GitHub 레포지토리: https://github.com/leo1oel/lattice (Apache-2.0, README 기준)
• 최신 릴리스: https://github.com/leo1oel/lattice/releases (v0.16.1, 2026-11-09)
• 소개 트윗 (leoliuym, 2026-11-06): https://x.com/leoliuym/status/2118774820293034437

참고: 이 글은 홈 머신에서 작성되었으며, 앱 설치 재현은 비인터랙티브 세션 제약으로 공개 산출물 검증으로 대체했습니다.