Lathe, LLM에게 코딩을 맡기는 대신 새 도메인을 배우게 해주는 튜토리얼 도구

LLM을 ‘대신 코딩하는 존재’가 아니라 ‘튜터’로 쓰자는 실험

• Lathe는 LLM으로 실습형 기술 튜토리얼을 만들고, 사용자가 직접 따라가며 배우게 하는 도구임

  • 작성자는 “LLM이 생각을 대신하게 하지 말고, 나를 가르치게 하자”는 문제의식에서 출발했다고 설명함
  • 단일 파트 튜토리얼도 되고, 여러 파트로 이어지는 시리즈도 만들 수 있음
  • 예시 프롬프트는 /lathe build a 3D Slicer in Erlang처럼 원하는 주제를 바로 던지는 방식

• 핵심은 자동 완성이 아니라 손으로 하는 학습임

  • Lathe가 튜토리얼을 만들면 사용자는 로컬 UI에서 직접 읽고 코드를 입력하며 진행함
  • 작성자는 PSP 홈브루, Lua, C++, Crafting Interpreters, build-your-own-x 같은 손맛 있는 튜토리얼에서 배운 경험을 계속 언급함
  • 요즘 LLM은 제품을 빨리 ship하는 데는 좋지만, 직접 부딪히며 이해하는 순간을 빼앗는다는 문제의식이 깔려 있음

구조는 Go CLI + LLM 스킬 + 로컬 웹 UI

• Lathe는 Go로 만든 단일 바이너리 CLI로 배포됨

  • macOS는 Homebrew cask로 설치 가능함
  • Linux는 설치 스크립트나 go install github.com/devenjarvis/lathe@latest를 쓰는 방식
  • 기본 웹 서버 포트는 4242이고, lathe serve로 브라우저를 열어 튜토리얼을 읽음

• 튜토리얼 생성과 보조 작업은 LLM 세션 안에서 스킬로 실행됨

  • Claude Code, Cursor, Codex를 지원한다고 되어 있음
  • Codex는 Claude Code와 같은 SKILL.md 형식을 그대로 사용한다고 설명함
  • Cursor 쪽은 slash command 형태로 설치되고, 런타임 세부 동작은 약간 다를 수 있음

• CLI는 LLM을 직접 호출하지 않고, 오래 남아야 하는 상태를 관리함

  • 튜토리얼 파일은 ~/.lathe/tutorials/ 아래에 slug별 디렉터리로 저장됨
  • metadata.json, part-01.md, part-02.md 같은 구조로 쌓임
  • 상태값은 unverified, verifying, verified, failed, skipped, extending 같은 식으로 관리됨

sequenceDiagram
    participant 사용자
    participant LLM세션
    participant Lathe스킬
    participant LatheCLI
    participant 로컬UI
    사용자->>LLM세션: 만들고 싶은 튜토리얼 요청
    LLM세션->>Lathe스킬: /lathe 명령 실행
    Lathe스킬->>LatheCLI: 튜토리얼과 출처 저장
    사용자->>로컬UI: lathe serve로 읽기 시작
    로컬UI->>사용자: 질문·검증·확장 명령 제공
    사용자->>LLM세션: /lathe-ask 또는 /lathe-verify 실행

그냥 Claude에게 물어보는 것과 뭐가 다르냐면

• Lathe는 튜토리얼 라이브러리 관리에 신경을 꽤 많이 씀

  • 목록 화면에서 제목, 주제, 태그, 저장소, 도구 버전으로 검색 가능함
  • 최신순, 오래된순, 제목순 정렬이 있고, 상태·타입·태그·버전 필터도 있음
  • 전부 클라이언트 사이드라 오프라인에서도 빠르게 동작하는 쪽을 노림

• 튜토리얼마다 생성 맥락을 기록함

  • 어떤 모델이 썼는지, 어떤 voice를 썼는지, 어떤 출처를 참고했는지 남김
  • sources 필드는 튜토리얼 레벨의 research trail 역할을 함
  • 읽기 화면에는 “Researched against N sources” 패널로 출처 목록을 펼쳐볼 수 있음

• voice 시스템도 들어가 있음

  • 기본 voice는 plainspoken이고, 정확하고 솔직한 톤을 목표로 함
  • companion은 조금 더 따뜻하고 재치 있는 1인칭 친구 같은 톤을 시도함
  • 커스텀 voice도 만들 수 있지만, 실존 인물 사칭이나 허위 경력 꾸미기는 막도록 설계했다고 함

검증은 자동 실행이 아니라 사용자 LLM 세션 안에서 이뤄짐

• Lathe의 verification은 옵트인임

  • 튜토리얼을 저장하면 기본 상태는 unverified
  • 사용자가 lathe verify <slug>나 웹 UI의 Verify 버튼을 누르면, 실제로는 /lathe-verify <slug> 명령을 LLM 세션에 붙여넣는 흐름

• 검증 스킬은 튜토리얼 단계를 실제로 따라가며 확인함

  • 새 mktemp -d 임시 디렉터리를 만들고, 그 안에서 파일 생성과 명령 실행을 진행함
  • 각 ## Checkpoint 블록을 실행해 컴파일·실행 여부를 확인함
  • 결과는 lathe verify-result로 기록되고, 실패하면 실패한 파트·단계·에러 출력이 남음

• 격리는 완전한 보안 경계가 아니라 작업물 오염을 줄이는 장치에 가까움

  • 작성자는 임시 디렉터리 방식을 soft isolation이라고 표현함
  • LLM 도구 호출은 사용자의 평소 permission model 아래에서 보이고 승인되는 구조임
  • 필요한 툴체인이 없으면 검증 결과는 skipped로 남음

아직은 개인 도구에 가까운, 하지만 방향은 꽤 흥미로운 프로젝트

• 작성자는 Lathe가 “vibecoded”됐다고 솔직히 밝힘

  • 범위와 리스크가 낮은 개인 학습 도구라서 가능한 접근이었다는 설명
  • 현재 주된 테스트 환경은 macOS에서 Claude Code를 쓰는 본인 사용 사례임
  • 다른 환경에서도 동작해야 하지만 충분히 검증되지는 않았고, 이슈 리포트를 원한다고 함

• 추천 모델도 꽤 현실적으로 말함

  • 튜토리얼 생성은 단순 반복 코딩보다 조사, 설계, 설명이 중요하다고 봄
  • 그래서 Opus나 GPT-5 Codex 같은 큰 thinking 모델을 권장함
  • 튜토리얼 생성은 일반적인 바이브코딩보다 토큰을 덜 먹는 편이라고도 언급함

• 한국 개발자에게도 꽤 실용적인 아이디어임

  • 한국어 자료가 부족한 신생 기술, 임베디드, 3D 프린팅, 특정 언어 생태계 같은 영역에서 특히 쓸 만함
  • 다만 사람이 쓴 좋은 자료가 있다면 그걸 먼저 보는 게 낫다는 전제를 깔고 써야 함
  • Lathe가 좋은 건 정답을 대신 주는 게 아니라, 질문하고 의심하면서 직접 따라갈 판을 만들어준다는 점임

기술 맥락

• Lathe가 Go CLI를 따로 둔 이유는 LLM 세션이 오래 남는 상태 관리에 약하기 때문이에요. 튜토리얼 파일, 메타데이터, 검증 결과, 출처 목록처럼 나중에 다시 봐야 하는 정보는 로컬 바이너리가 책임지는 편이 훨씬 안정적이거든요.

• LLM 호출을 CLI 안에 숨기지 않고 Claude Code, Cursor, Codex 같은 인터랙티브 세션에 맡긴 것도 의도적인 선택이에요. 사용자가 도구 호출을 보고 승인하는 기존 권한 모델을 그대로 쓰면, 튜토리얼 검증 중 실행되는 명령을 더 투명하게 다룰 수 있어요.

• 검증을 mktemp -d 임시 디렉터리에서 하는 건 학습 중인 저장소를 더럽히지 않기 위한 장치예요. 다만 원문에서도 말하듯 이건 보안 샌드박스가 아니라 작업 공간 분리 수준이라, 실행 명령 자체는 여전히 사용자가 확인해야 해요.

• 출처와 모델, voice를 메타데이터에 남기는 건 LLM 튜토리얼의 가장 큰 약점인 신뢰 문제를 줄이려는 선택이에요. 생성물이 틀릴 수 있다는 전제를 숨기지 않고, 사용자가 어디를 근거로 썼는지 확인하게 만드는 쪽에 가깝죠.