2P by GN⁺ | ★ favorite | 댓글 1개
  • Lathe는 LLM이 대신 생각하게 하기보다 가르치도록 쓰는 실험으로, 프롬프트에서 실습형 기술 튜토리얼을 생성하고 사용자가 로컬 UI에서 직접 손으로 따라가며 학습하게 함
  • 단일 파트 또는 여러 파트의 튜토리얼 생성을 지원하며, 질문하기, 튜토리얼 검증, 새 파트 확장, 검색 태그 추가를 위한 LLM skills를 제공함
  • Claude Code, Cursor, Codex의 대화형 LLM 세션에서 튜토리얼을 생성할 수 있고, Go로 만든 lathe CLI가 튜토리얼 저장, 관리, 렌더링, 영속 상태를 담당함
  • CLI 자체는 LLM을 호출하지 않으며, 웹 버튼과 lathe verify·lathe extend 명령은 LLM 세션에 붙여 넣을 skill command를 제공하는 방식임
  • 로컬 웹 UI는 lathe serve로 실행하며 기본 포트는 4242; 튜토리얼 목록에서 제목, 주제, 태그, 저장소, 도구 버전 검색과 최신순·오래된순·제목순 정렬, 상태·유형·태그·버전 필터를 지원함
  • 읽기 UI는 오른쪽 사이드바의 목차 탐색, 본문 중간의 사이드 노트, 튜토리얼 끝의 독자용 연습 문제를 제공함
  • 모든 튜토리얼은 사용한 출처, 모델, 튜토리얼 문체를 이끈 프롬프트를 기록하며, 출처 기록은 metadata.jsonsources 필드와 UI의 출처 패널로 확인 가능함
  • 튜토리얼은 전역 경로 ~/.lathe/tutorials/에 슬러그별 디렉터리로 저장되며, metadata.jsonpart-01.md 같은 파트 파일 또는 index.md로 구성됨
  • 설치는 단일 독립 실행 바이너리 lathe$PATH에 두는 방식이며, macOS용 Homebrew cask, curl | sh 설치 스크립트, Go 1.25+ 기반 go install, 소스 빌드를 지원함
  • skills는 바이너리에 번들되어 있으며 lathe skills install로 Claude Code, Cursor, Codex용 위치에 설치 가능함
  • 튜토리얼 문체는 voice로 제어되며 기본 plainspokencompanion이 함께 제공되고, /lathe-voice로 사용자 정의 voice를 만들 수 있음
  • voice는 문체만 바꾸며 정확성, 조사, 인용, 검증, 구조는 바꾸지 않음; 사용자 정의 voice는 실존 인물 사칭, 자격 조작, LLM 저작 부인을 거부하도록 설정됨
  • 검증은 선택 사항이며 대화형 LLM 세션에서 /lathe-verify <slug>로 실행됨; 새 mktemp -d 스크래치 디렉터리에 파일을 만들고 명령과 ## Checkpoint 블록을 실행한 뒤 결과를 기록함
  • 검증 상태는 unverified, verifying, verified, failed, skipped, extending 중 하나이며, 필요한 도구가 없으면 실패가 아니라 skipped로 기록됨
  • 검증은 일반 LLM 권한 모델 아래에서 실행되어 도구 호출을 보고 승인할 수 있으며, 스크래치 디렉터리는 빌드 산출물을 저장소 밖에 두기 위한 관례일 뿐 보안 경계가 아님
  • Lathe는 LLM이므로 LLM이 실패하는 방식으로 실패할 수 있으며, 튜토리얼 생성에는 접근 가능한 가장 큰 “thinking” 모델 사용을 권장함
  • 현재 자체 테스트 사용 사례는 macOS의 Claude Code이며, 그 밖의 구성은 동작할 수 있지만 검증되지 않았다고 명시함
  • 개인 학습을 위한 개인 사용 외의 콘텐츠 작성 용도로 의도되지 않음

댓글과 토론

Hacker News 의견들
  • 관심 주제에 대해 LLM이 소크라테스식 문답으로 계속 퀴즈를 내게 하는 비슷한 방식도 좋음
    더 깊은 단계의 질문을 계속 던져서 스스로 답에 도달하게 만들고, 그 과정에서 문제를 진지하게 생각하게 되어 이해·학습·기억에 도움이 됨
    그래서 어떤 코딩 에이전트나 유사 도구에서도 쓸 수 있는 Socratic-quiz 스킬을 만들었음: https://pchalasani.github.io/claude-code-tools/plugins-detai...
    예를 들어 당뇨/인슐린, 도파민과 동기, Claude 구현처럼 직관에 어긋나는 내용을 더 잘 이해하는 데 써봤고, 이른바 인지 부채를 줄이는 데도 도움이 됨
    강한 LLM은 이런 퀴즈에 의외로 능숙하고, 일종의 마음 이론 비슷한 모습을 보임

    • 이 경우 문맥 길이 저하는 어떻게 다루는지 궁금함
      더 어려운 질문은 문맥이 거의 찼을 때쯤에야 나오게 될 텐데
    • 힘의 원천이 LLM이라면, LLM 없이 당신은 무엇인가?
    • 실제 자료로 공부하는 것을 보완하는 용도라면 유용할 수 있음
      당뇨/인슐린, 도파민과 동기 같은 복잡한 주제를 “이해했다”고 가볍게 말했지만, 완전히 이해하려면 상당한 공부가 필요함
      호기심 기반 학습으로 보는 건 괜찮지만, 실제로 중요하거나 진지한 내용을 배우는 방식으로는 잘 모르겠음
      자료를 찾아보고 안내된 수업을 따라가는 전통적인 방식이 이 방법보다 더 정돈되어 있고 빠름
  • 예전부터 늘 있던 정확한 범위의 사람들이 계속 있을 것 같음
    어떤 사람은 호기심이 많아서 자신이 하는 일을 이해하고 싶어 하거나 이해해야 하고, 어떤 사람은 그렇지 않아서 그냥 실행만 원함
    그 욕구 자체가 전문가를 만드는 근본적인 성격 특성
    LLM은 이런 호기심 많은 사람들에게 꿈같은 도구이고, 오히려 더 가속시켜 줄 것임
    실제 “손실”은 별로 없고, 신경 쓰지 않는 사람들이 일을 더 쉽게 하게 될 뿐임
    그들에게도 좋고 호기심 많은 사람들에게도 좋으니, 전체적으로 이득임

    • 둘 다인 것 같고, 대상이 무엇인지와 동시에 뭘 하고 있는지에 따라 달라짐
      어떤 때는 오랫동안 깊게 파고드는 게 재미있고 흥미로움
      반대로 어떤 것이 왜 안 되는지에는 별로 호기심이 없고, 그냥 작동하게 만들어서 원래 하려던 일로 넘어가고 싶을 때도 있음
      결국 LLM은 두 경우 모두 유용하다고 느낌
    • 어떤 사람은 환경과 상관없이 계속 호기심을 가질 수 있겠지만, 어떤 사람은 삶의 경험에 따라 호기심을 키우거나 잃는 쪽으로 흔들릴 수 있음
      항상 곁에 있는 “지금 답만 줘” 버튼은 그들을 무관심한 쪽으로 끌어당기는 강한 힘이 될 수 있음
  • 꽤 신선한 아이디어라고 생각함
    LLM의 큰 장점은 훌륭한 학습 도구라는 데 있음
    많은 사람이 뭔가를 생성하는 데 쓰고 싶어 하지만, 거기서 얻을 수 있는 지식은 과소평가되는 듯함
    지금껏 가질 수 있는 최고의 튜터일 수도 있음
    덧붙여, 프로젝트로 돈을 벌려는지 아닌지 공개해야 하는 분위기는 별로임
    돈 버는 일이 악마화되거나 눈총받아서는 안 됨

  • 최근 업무에서 이 일반적인 패턴을 많이 쓰고 있음
    결정적인 작업은 커스텀 CLI 앱으로 만들고, 에이전트 하네스에는 스킬을 붙인 뒤, 에이전트 안에서 그 스킬을 실행하게 해서 CLI와 에이전트식 추론으로 산출물을 만들게 하는 방식임
    예를 들어 “지난 한 달 동안 이 팀들의 백로그 활동에 대한 임원용 요약을 만들어줘”라고 하면 5~10분 안에 몇 쪽짜리 문서를 읽을 수 있고, 분석한 티켓 인용도 붙어 있음
    사람들을 귀찮게 하거나 또 다른 일을 부탁할 필요 없이, 백로그만 평소처럼 최신이고 상세하게 유지하면 됨
    반복 작업에서 일관된 결과를 내기 어려운 순수 에이전트 사용과, 사소한 일마다 완전한 앱을 만들거나 사야 하는 상황 사이에서 아주 유용한 지점을 차지함

    • 이 접근은 잘 작동하고 동의함
      다만 계속 반대로 뒤집고 싶다는 생각이 듦
      원하게 되는 구조는 대부분의 워크플로 지식과 결정을 실제 코드로 담은 전통적인 CLI 프로그램인데, 특정 워크플로 단계에서만 “아주 조금” 코딩 에이전트를 호출하는 형태임
      어떻게 구현할지 잘 모르겠음
      이런 라이브러리가 이미 있는지, 있다면 어떻게 동작할지도 궁금함
      제대로 하려면 CLI 소프트웨어가 잘 알려진 로컬 IPC 소켓을 통해 상호작용할 수 있는 백그라운드 서비스가 있어야 할 것 같음
      예를 들어 docker 데몬과 비슷한 방식임
      하지만 그런 IPC 기능을 노출하는 코딩 에이전트 소프트웨어나 프레임워크는 알지 못함
    • 동의함
      이 패턴은 Simon Willison의 어떤 작업, 아마 Rodney와 Showboat에서 처음 본 것 같음
      특정 워크플로에서는 Skills + CLI 조합이 LLM의 유연성과 CLI의 일관성 사이에서 좋은 균형을 줌
    • 결정적인 작업의 예를 몇 가지 들 수 있는지 궁금함
      예시에서는 결정적인 작업이 “이 팀의 백로그를 가져오기”이고, LLM 부분은 “각 백로그를 처리하기”와 “요약을 합치기”였는지?
  • 바로 이 목적에 맞게 인기 있는 /grill-me 스킬을 업데이트했음
    어제 pandas에서 극도로 큰 데이터셋을 로드하려고 할 때 정확히 무슨 일이 벌어지는지, 마지막 세부사항까지 아주 통찰력 있는 압박 질문 세션을 했음

    • 그 버전을 어디 공개해 둔 곳이 있음?
  • 멋진 방식임
    얼마 전 친구에게 프로그래밍은 코드를 손으로 직접 타이핑하면서 배운다고 말했음
    그래서 관심사와 필요에 맞춘 최소한의 교육용 예제를 LLM으로 생성해 보라고 제안함
    Zed Shaw식 프로그래밍 학습법, 즉 음악이나 미술의 습작처럼 코드 예제를 손으로 그대로 타이핑하는 방식을 시도해 봤음
    한동안 배우고 있었지만 고전하던 프로그래밍 언어에 시험해 봤는데, 몇 시간 타이핑만으로 유창성이 크게 올라감
    몇 시간 동안 타이핑하면서 몇 주 동안 공부할 때보다 더 많은 코드를 썼다는 걸 깨달음
    아직 언어를 모르면 코드를 만들어내는 일이 매우 느리고 오류가 많지만, 올바른 코드를 타이핑하는 일은 상대적으로 단순함
    그래서 접근을 “그냥 맹목적으로 타이핑하기”로 바꾸자, 적어도 읽기와 근육 기억 측면에서는 몇 시간 만에 이전 몇 주보다 더 많은 연습을 하게 됨
    물론 이해도 중요하지만, 내 경험상 그것은 별도의 축이고 대체로 기억과 유창성 뒤에 따라옴
    어떤 것을 이론적으로 이해하는 것과 실제로 사용할 수 있는 것은 매우 다름
    여기 깔린 일반 원리는 Stephen Krashen의 언어 습득 입력 가설임: https://en.wikipedia.org/wiki/Input_hypothesis
    아이는 말을 그냥 듣고, 입력에 노출되면서 언어를 배운다는 내용이고, 성인도 같은 방식으로 배울 수 있다고 봄
    지금은 없어졌을지도 모르는 훌륭한 웹사이트 All Japanese All The Time에서도 이 얘기를 접했음
    저자는 일본어를 많이 듣는 방식으로 스스로 가설을 시험했고 1년 만에 유창성을 얻었다고 함
    https://web.archive.org/web/20080705194055/http://www.alljap...

  • 아주 멋진 아이디어이고, 이 혼란스러운 시기에 LLM을 제정신으로 쓰는 방식처럼 느껴짐
    새 프로젝트를 시작할 때 모든 게 마찰로 느껴지는 상황에서 분위기를 여는 좋은 방법이 될 수 있음

    • 실제로 내 주요 사용 사례가 바로 그쪽임
      새 프로젝트에 들어가는 장벽을 낮추고, 익숙해진 뒤에는 스스로 더 깊게 가져갈 수 있는 기반을 마련해 줌
  • 흥미로운 영역을 다루고 있다고 생각함
    시스템 설계 면접 준비에서도 비슷한 걸 생각했음
    Twitter 설계와 WhatsApp 설계에 대한 블로그 글 시리즈 몇 개로 실험해 봤음: https://prepcommons.com/
    그래도 초기 요청을 그냥 처리하는 것보다 훨씬 더 많은 노력이 들었음
    AI는 모두가 평균적인 결과를 만들게 해주지만, 좋은 결과를 만들려면 여전히 취향과 안목이 필요함
    아마 강의에도 똑같이 적용될 것 같음

  • 멋진 프로젝트라서 써볼 생각임
    새 주제를 공부할 때 가진 자료를 전부 LLM “프로젝트”에 넣고, 실제 콘텐츠에 근거해서 가르쳐 달라고 해서 속도를 높이는 방식을 꽤 좋아함
    동시에 모든 것이 원하는 방식으로 딱 정리되어 주어지면, 원자료를 직접 보고 어렵게 파악해 가며 쌓는 이해가 약해질까 걱정됨
    그래서 이 방식처럼 여전히 LLM이 유발하는 지적 게으름을 어느 정도 달래면서도, 실제로 직접 해보는 데 더 초점을 두는 접근은 내 취향에 잘 맞음

  • 더 궁금한 건 직접 만든 바이브 코딩 도구를 실제로 써본 경험임
    소개만으로는 실제로 사용하고 좋아하는지 잘 모르겠음
    사용하고 가끔 반박도 한다고 했는데, 그것 자체가 하나의 학습 전략일 수도 있음
    또 “다른 모델로 튜토리얼이 컴파일되는지 테스트한다”는 건 기능이라고 부르기 애매함
    물론 한 번의 요청으로 완전무결한 튜토리얼을 기대하지는 않음
    손으로 작성한 프롬프트 대신 이걸 왜 써야 하는지도 잘 모르겠고, ChatGPT Study 모드가 왜 실패했는지도 궁금함
    흥미로워 보였기 때문임

    • 꽤 많이 써봤고 아주 마음에 듦
      물론 직접 프롬프트를 만들어도 됨
      내가 보는 가치는 재사용 가능한 스킬/프롬프트가 튜토리얼을 구성해 Claude가 그냥 복사해 붙일 코드를 주는 대신, 내가 새 개념을 생각하고 배우게 도와준다는 데 있음
      그리고 로컬 UI 덕분에 Claude의 마크다운 출력을 스크롤하는 것보다 튜토리얼을 따라가기가 훨씬 편함
      튜토리얼 시리즈가 지속적으로 남아 있어서 나중에 관심 있는 주제나 튜토리얼의 확장을 /lathe-extend로 쉽게 이어갈 수 있음
      다만 개인적으로 도움이 된 도구일 뿐, 모두에게 그럴 필요는 없음
      ChatGPT Study는 써본 적이 없어서 더 살펴보겠음. 알려줘서 고마움