# \#markdown **URL:** https://discuss.pytorch.kr/tag/markdown/4233.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [OpenProse: Markdown 기반의 계약으로 지속적인 AI 작업을 정의하는, AI Agent의 동작을 위한 언어](https://discuss.pytorch.kr/t/openprose-markdown-ai-ai-agent/12010)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 29, 2026, 10:30오전 UTC](https://discuss.pytorch.kr/t/openprose-markdown-ai-ai-agent/12010 "2026-09-29T10:30:36Z")
OpenProse 소개 에이전트에게 여러 단계의 작업을 지시할 때는 보통 실행 순서와 종료 조건을 프롬프트에 적습니다. 그러나 한 번 끝나는 작업이 아니라, 입력이 바뀔 때마다 같은 목표 상태를 유지해야 하는 작업이라면 매번 전체 순서를 다시 설명해야 합니다. OpenProse는 이런 지속적인 AI 작업을 Markdown 계약(\*.prose.md)으로 정의하는 언어입니다. 작성자는 작업 순서보다 유지해야 할 상태와 그 상태를 확인할 조건을 먼저 적습니다. OpenProse는 이를 선언형 접근으로 소개하며, 순서나 반복을 직접 통제해야 할 때는 선택적으로 ProseScript 계획을 사용합니다. 계약은 일반 파일이므로 저장소에서 버전을 관리할 수 있고, 이를 실행하는 에이전트 환경은 파일 읽기와 쓰기, 도구 호출, 세션 생성 기능을 갖춰야 합니다. 프로젝트의 현재 문서는 책임(kind: responsibility)을 지속적인 목표를 표현하는 기본 계약으로 설명합니다. Maintains에 유지할 상태와 사후 조건을, Requires에 상위 입력을, Continuity에 다시 실행될 계기를 적습니다. 문서에는 최근 계약 문법을 바꾼 내용도 명시되어 있으므로, 예전 Ensures나 service 예제를 그대로 가져와 시작하지 않는 편이 좋습니다. README에 따르면 v0.14 이하에서 쓰던 계약 소스는 prose upgrade --dry-run으로 이관 계획을 먼저 확인한 뒤 prose upgrade로 옮길 수 있지만, 이전 실행 기록(ledger)과 상태 데이터는 이관 도구 없이 버리고 깨끗한 상태 디렉터리에서 다시 실행해야 합니다. OpenProse와 순서 중심 에이전트 작업 비교 순서 중심 작업은 작성자가 실행 단계를 직접 나열합니다. OpenProse의 기본 단위인 responsibility는 어떤 상태를 유지할지 선언하고, 필요한 입력과 갱신 계기를 계약에 적습니다. 여러 계약을 연결할 때는 Requires와 Maintains의 항목을 맞춰… --- ## [anydoc: 오피스 문서를 LLM이 읽을 Markdown으로 5밀리초 안에 바꾸는 Rust 라이브러리](https://discuss.pytorch.kr/t/anydoc-llm-markdown-5-rust/11552)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [8월 9, 2026, 4:30오전 UTC](https://discuss.pytorch.kr/t/anydoc-llm-markdown-5-rust/11552 "2026-08-09T04:30:36Z")
anydoc 소개 문서를 입력으로 받는 AI 파이프라인은 대체로 같은 자리에서 막힙니다. 사용자가 올리는 파일은 .docx, .pptx, .xlsx, .pdf, .epub처럼 제각각인데, 언어 모델에 넣으려면 결국 하나의 텍스트 표현으로 정리해야 합니다. 그래서 형식마다 다른 파서를 붙이게 되고, 표 하나가 docx에서는 멀쩡히 나오는데 rtf에서는 깨지는 식의 불일치가 쌓입니다. 표 이스케이핑 버그를 고쳐도 그 수정이 다른 형식에는 적용되지 않아 같은 작업을 형식 개수만큼 반복하게 되고, 변환기 자체가 무거우면 문서 한 건에 1초 넘게 걸려 수집 단계 전체가 느려집니다. anydoc은 파서는 형식별로 두되 그 뒤를 하나로 합치는 방식으로 이 문제에 접근합니다. 각 형식 파서는 공통 문서 모델(Document)을 만들어 내고, 그 모델 하나만 GitHub Flavored Markdown 직렬화기를 통과합니다. 이스케이핑, 표, 제목 앵커, 각주가 어떤 형식에서 들어왔든 동일하게 처리되는 이유이며, 저자들은 이 구조 덕분에 "docx의 표 이스케이핑 수정이 곧바로 rtf, odt를 비롯한 나머지 전부의 수정이 된다" 고 설명합니다. 구현은 순수 Rust이고 머신러닝 모델이나 외부 서비스를 호출하지 않아, 문서 한 건 변환 시간 중앙값이 5밀리초 아래입니다. 만든 곳은 웹 크롤링 API로 알려진 Firecrawl이며, 이 라이브러리는 자사 서비스인 Firecrawl Parse를 구동하는 엔진이기도 합니다. 배포 형태는 Rust 크레이트, Node.js 패키지, Python 휠, 그리고 브라우저용 WebAssembly 빌드까지 네 가지이고, 별도 설치 없이 쓰는 CLI와 코딩 에이전트용 Agent Skill도 함께 제공됩니다. 현재 최신 릴리즈는 v0.1.6입니다. anydoc과 기존 문서 변환 도구의 차이 문서를 마크다운으로 바꾸는 도구는 이미 여럿 있습니다. LibreOffice를 헤드리스로 돌리는 방식은 지원 형식이 넓은 대신 프로세스 기동 비용이 … --- ## [pdf-inspector: OCR 없이 PDF를 분류하고 마크다운으로 추출하는 Rust 라이브러리 (feat. firecrawl)](https://discuss.pytorch.kr/t/pdf-inspector-ocr-pdf-rust-feat-firecrawl/11255)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [7월 14, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/pdf-inspector-ocr-pdf-rust-feat-firecrawl/11255 "2026-07-14T23:30:18Z")
pdf-inspector 소개 문서를 다루는 파이프라인에서 PDF는 가장 까다로운 입력 중 하나입니다. 어떤 PDF는 이미 본문 텍스트가 그대로 들어 있는 반면, 어떤 PDF는 종이를 스캔한 이미지 덩어리라 광학 문자 인식(OCR)을 거쳐야 글자를 얻을 수 있습니다. 둘을 구분하지 않고 모든 PDF를 OCR 서비스로 보내면, 이미 텍스트가 있는 문서에까지 불필요한 비용과 수 초 단위의 지연이 붙습니다. pdf-inspector는 이 구분을 앞단에서 빠르게 처리하는 라이브러리입니다. OCR이나 머신러닝 모델 없이 순수 Rust로 PDF의 콘텐츠 스트림을 샘플링해 문서가 텍스트 기반인지 스캔본인지 밀리초 단위로 판별하고, 텍스트 기반이면 위치 정보를 유지한 채 본문을 추출해 마크다운으로 변환합니다. 웹 크롤링·데이터 수집 도구를 만드는 Firecrawl 이 자사 파이프라인을 위해 만들었으며, 텍스트 기반 PDF를 200ms 안에 로컬에서 처리해 "OCR이 필요 없는 약 54%의 PDF" 에 대한 외부 OCR 호출을 건너뛰는 것을 목표로 합니다. 핵심 기능은 크게 세 가지입니다. PDF 타입 분류, 위치 인식 텍스트 추출, 그리고 제목·목록·표·코드 블록을 인식하는 마크다운 변환입니다. Rust 라이브러리 본체와 함께 Python 및 Node.js 바인딩, 그리고 명령줄 도구를 제공하며, PDF 파싱을 위한 lopdf 하나 외에는 외부 의존성이 없습니다. pdf-inspector의 문서 처리 파이프라인 pdf-inspector는 문서를 한 번만 파싱한 뒤 그 결과를 분류 단계와 추출 단계가 공유하는 구조로 설계되어 있습니다. load\_document\_from\_path 또는 load\_document\_from\_mem 로 문서를 한 차례 로드하고, 이후 감지(detector)와 추출(extractor)이 같은 파싱 결과를 재사용하므로 중복 I/O가 발생하지 않습니다. 추출 단계는 여러 하위 모듈로 나뉩니다. 폰트 정보(폭·인코딩)를 읽고, 콘텐츠 스트림… --- ## [Cabinet: 마크다운 파일로 동작하는, AI-우선(AI-first) 지식 베이스 프로젝트](https://discuss.pytorch.kr/t/cabinet-ai-ai-first/10753)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [6월 24, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/cabinet-ai-ai-first/10753 "2026-06-24T09:30:33Z")
Cabinet 소개 Cabinet은 모든 데이터를 디스크의 마크다운 파일로 저장하는 AI 우선(AI-first) 지식 베이스이자 스타트업 OS입니다. 데이터베이스 없이 평범한 파일로만 동작하고, 자체 호스팅을 전제로 하므로 데이터가 사용자의 컴퓨터를 벗어나지 않습니다. Apple에서 엔지니어링 매니저를 지낸 Hila Shmuel이 오픈소스 커뮤니티와 함께 공개적으로 개발하고 있습니다. 이 프로젝트는 새 AI 세션을 시작할 때마다 이전의 맥락과 결정, 조사한 내용이 사라지는 문제에서 출발합니다. 흩어진 문서와 기억이 없는 AI 세션, 도구 사이를 오가는 수동 복사·붙여넣기를 하나의 지식 베이스로 모으고, 그 위에서 기억을 유지하는 AI 에이전트와 예약 작업이 돌아가도록 하는 것이 Cabinet의 목표입니다. Cabinet은 몇 가지 원칙 위에 설계됐습니다. 데이터는 로컬에 두어 사용자가 통제하고(Yours), 저장할 때마다 자동으로 커밋해 변경 이력을 남기며(Git everything), 특정 제공자에 묶이지 않도록 Claude, Codex, OpenCode, 로컬 모델 등을 함께 쓸 수 있게 합니다(BYOAI). 본 게시물에서는 Cabinet의 동작 방식과 주요 기능, 설치 방법을 정리합니다. Cabinet의 동작 방식 Cabinet에서 하나의 캐비닛(cabinet)은 마크다운 파일들이 담긴 폴더일 뿐이며, 원하는 위치에 둘 수 있습니다. 첫 실행 시 앱이 ~/.cabinet/app/v{version}/에 내려받아지고 그곳에 의존성이 설치되므로, 지식이 담긴 폴더 자체는 가볍게 유지됩니다. 모든 저장이 자동으로 커밋되기 때문에 변경 내역을 확인하고, 잘못된 부분을 되돌리고, 지식이 어떻게 쌓여 왔는지 감사할 수 있습니다. 아래는 Cabinet이 실제로 동작하는 모습을 담은 공식 데모입니다. 저자는 Cabinet의 지향점을 두고 "기업용 워크플로우 소프트웨어처럼 느껴진다면 잘못된 것이고, 팀이 일하는 모습을 지켜보는 것처럼 느껴진다면 제대로 된… --- ## [lat.md(Agent Lattice): AI 코딩 에이전트와 사람을 위한 마크다운 기반 코드베이스 지식 그래프](https://discuss.pytorch.kr/t/lat-md-agent-lattice-ai/10095)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [5월 10, 2026, 3:30오전 UTC](https://discuss.pytorch.kr/t/lat-md-agent-lattice-ai/10095 "2026-05-10T03:30:57Z")
lat.md 소개 코드베이스가 일정 규모를 넘어가면 단일한 AGENTS.md나 README.md로 모든 설계 결정과 도메인 맥락을 담아 두기 어려워집니다. 핵심 의사결정은 길어지는 문서 깊숙이 묻히고, 비즈니스 로직이 문서화되지 않은 채 구현체에만 남으며, AI 코딩 에이전트는 결국 찾을 수 없는 맥락을 환각(Hallucination)으로 채우게 됩니다. lat.md(Agent Lattice)는 이 문제를 정면으로 다루는 오픈소스 도구로, 프로젝트 루트의 lat.md/ 디렉토리에 모이는 마크다운 파일들의 집합을 코드베이스 전용 지식 그래프(Knowledge Graph)로 다룹니다. 핵심 아이디어는 단순합니다. 마크다운 섹션끼리는 위키 링크(\[\[wiki links\]\])로 연결하고, 마크다운에서 코드 심볼로는 \[\[src/auth.ts#validateToken\]\] 같은 링크로 들어가며, 코드에서는 // @lat: \[\[section-id\]\] 주석으로 다시 그래프로 돌아오게 합니다. 이렇게 양방향으로 묶인 그래프 위에서 lat check 같은 명령이 참조 무결성(Referential Integrity)을 강제하기 때문에, 시간이 지나도 문서와 코드가 손쉽게 어긋나지 않도록 유지할 수 있습니다. 이 접근의 1차적인 수혜자는 AI 에이전트입니다. 에이전트는 코드 전체를 grep으로 훑는 대신, 그래프에서 설계 결정·제약·도메인 맥락을 빠르고 일관되게 검색해 사용할 수 있습니다. 사람의 측면에서도 풀 리퀘스트(Pull Request) 리뷰를 코드보다 먼저 lat.md/의 의미적 변경부터 살펴봄으로써 "무엇이, 왜 바뀌었는가" 를 빠르게 파악할 수 있고, 세션 종료와 함께 휘발되던 프롬프트의 추론 맥락도 그래프에 누적되어 다음 세션에서 그대로 재사용됩니다. lat.md의 동작 원리와 디렉토리 구조 lat init 명령으로 프로젝트 루트에 lat.md/ 디렉토리를 만들면, 아키텍처·인증·테스트 명세 같은 문서를 자유롭게 작성할 수 있습니다. 섹션 간 링크는 \[\[fil… --- ## [Markdown for Agents: Cloudflare가 공개한, AI 에이전트를 위한 새로운 콘텐츠 요청/응답 방식](https://discuss.pytorch.kr/t/markdown-for-agents-cloudflare-ai/8989)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [2월 14, 2026, 9:30오전 UTC](https://discuss.pytorch.kr/t/markdown-for-agents-cloudflare-ai/8989 "2026-02-14T09:30:07Z")
Markdown for Agents 소개 Cloudflare가 웹 콘텐츠를 AI 에이전트와 크롤러가 더 효율적으로 소비할 수 있도록 돕는 새로운 기능인 Markdown for Agents를 발표했습니다. 오늘날 웹 트래픽의 상당 부분은 사람이 아닌 AI 에이전트와 크롤러에서 발생하고 있습니다. 하지만 기존 웹은 사람을 위해 설계된 HTML, CSS, JavaScript로 구성되어 있어, AI가 정보를 추출하기에는 불필요한 태그와 스크립트가 많아 비효율적이었습니다. Markdown for Agents는 이러한 문제를 해결하기 위해, 요청 시 실시간으로 웹페이지의 HTML을 Markdown으로 변환하여 제공하는 기능입니다. 이 기술의 핵심은 콘텐츠 협상(Content Negotiation)입니다. AI 에이전트가 웹페이지를 요청할 때 Accept: text/markdown 헤더를 포함하면, Cloudflare 네트워크가 이를 감지하여 원본 서버의 HTML을 가져온 뒤 자동으로 Markdown으로 변환하여 응답합니다. 이를 통해 AI 모델은 복잡한 HTML 파싱 과정 없이 순수한 텍스트와 구조화된 데이터만을 즉시 소비할 수 있게 됩니다. Markdown for Agents 기능은 AI 모델의 추론 비용과 속도에 직접적인 영향을 미치는 '토큰(Token)' 사용량을 획기적으로 줄여줍니다. 예를 들어, HTML로 구성된 일반적인 블로그 포스트는 약 16,000 토큰을 소모하지만, 이를 Markdown으로 변환하면 약 3,000 토큰으로 줄어들어 약 80%의 절감 효과를 볼 수 있습니다. 이는 AI 에이전트의 컨텍스트 윈도우(Context Window)를 효율적으로 사용하고, 더 정확한 검색 증강 생성(RAG) 결과를 얻는 데 기여합니다. AI Agent의 HTML vs. Markdown 방식 비교 기존의 웹 접근 방식과 Markdown for Agents를 사용했을 때의 차이점은 다음과 같습니다. 기존 방식(HTML) 은 AI 에이전트가 웹페이지를 스크… --- ## [mdflow: Markdown 형태로 프롬프트를 작성한 뒤, CLI 명령어처럼 실행할 수 있도록 하는 프로젝트](https://discuss.pytorch.kr/t/mdflow-markdown-cli/8414)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 13, 2025, 6:30오전 UTC](https://discuss.pytorch.kr/t/mdflow-markdown-cli/8414 "2025-12-13T06:30:25Z")
mdflow 소개 mdflow는 개발자가 작성한 마크다운(Markdown) 파일을 '실행 가능한 AI 에이전트'로 변환해주는 CLI(Command Line Interface) 도구입니다. Script Kit의 제작자로 유명한 John Lindquist가 개발한 이 프로젝트는 "당신의 마크다운 파일이 이제 실행 가능한 AI 에이전트가 됩니다(Your markdown files are now executable AI agents)"라는 핵심 아이디어를 바탕으로 합니다. 기존의 AI 상호작용이 주로 웹 기반의 채팅 인터페이스에서 이루어졌다면, mdflow는 이를 코드 중심의 워크플로우로 가져옵니다. 개발자는 마크다운 파일에 프롬프트를 작성하고, 파일 확장자나 이름을 통해 실행할 AI 모델(Claude, Gemini, OpenAI Codex 등)을 지정할 수 있습니다. 이는 프롬프트를 코드로 관리하고, 버전을 제어하며, 기존의 유닉스(Unix) 파이프라인과 결합하여 자동화된 작업을 수행할 수 있게 해줍니다. mdflow 도구는 반복적인 AI 작업을 스크립트화하거나, 복잡한 프롬프트 엔지니어링을 파일 단위로 구조화하여 관리하고 싶은 개발자들에게 특히 유용합니다. 또한, 로컬 파일을 읽어 AI에게 전달하거나, AI의 출력을 다른 명령어의 입력으로 연결하는 등 터미널 환경에서의 유연한 AI 활용을 지원합니다. Web UI 기반의 ChatGPT 및 Claude 등의 서비스가 대화형(Conversation) 중심이라면, mdflow는 스크립트 실행(Execution) 중심입니다. 즉, 사용자가 실행하는 프롬프트 내용이 파일로 저장되므로 재사용과 수정이 용이합니다. 또한, Web UI 기반 서비스에서는 웹 브라우저에 파일 업로드나 텍스트 복사/붙여넣기 등을 의존해야 하지만, mdflow는 표준 입출력(stdin/stdout)을 지원합니다. 즉, cat file.txt | mdflow task.md와 같이 리눅스 명령어와 결합하여 데이터를 유연하게 처리할 수 있습니다. … --- ## [GitBook Downloader, GitBook 문서를 LLM에 지식으로 전달하기 위한 다운로더 (feat. Markdown)](https://discuss.pytorch.kr/t/gitbook-downloader-gitbook-llm-feat-markdown/5757)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [12월 29, 2024, 4:38오전 UTC](https://discuss.pytorch.kr/t/gitbook-downloader-gitbook-llm-feat-markdown/5757 "2024-12-29T04:38:57Z")
GitBook Downloader 소개 Gitbook Documentation Downloader는 Gitbook 문서를 Markdown 형식으로 변환하여 LLM에 적합하게 만드는 애플리케이션입니다. 이를 통해 다음과 같은 작업이 가능합니다: 기술 문서를 다운로드하여 사용자 정의 LLM 훈련에 활용 AI 챗봇(예: ChatGPT, Claude)의 컨텍스트 창에 문서를 입력 Markdown 형식으로 구조화된 데이터 생성 Gitbook 기반의 문서 구조를 유지하면서 HTML을 LLM 친화적인 Markdown으로 변환하며, 내부 링크 및 탐색 기능도 지원하여 효율적으로 활용할 수 있습니다. GitBook Downloader 주요 기능 Gitbook 문서 스크래핑: Gitbook 사이트의 내용을 추출. Markdown 변환: LLM이 처리하기 쉬운 Markdown 형식으로 변환. 브라우저 미리보기: 변환된 내용을 브라우저에서 확인 가능. Markdown 파일 다운로드: 변환된 내용을 하나의 Markdown 파일로 다운로드 가능. 문서 구조 보존: 내부 링크 및 탐색 기능을 유지. :github: GitBook Downloader GitHub 저징소 https://github.com/Amal-David/gitbook-downloader 이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다. :hugs: :pytorch:파이토치 한국 사용자 모임:south\_korea:이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일:love\_letter:로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.) :wrapped\_gift: 아래:down\_right\_arrow:쪽에 좋아요:…