m0lz.01: 나에게 말이 되는가?

나에게 말이 되나요? 이것이 m0lz.01에서 제가 원했던 기준입니다. 저는 또 다른 콘텐츠 캘린더, 또 다른 노트 앱, 또는 실제 작업이 터미널, 초안, 브라우저 탭, 그리고 미완성 체크리스트에 흩어져 있는 상태로 두고 게시할 수 있다고 주장하는 또 다른 에이전트는 필요하지 않습니다. 저는 아이디어를 받아 연구로 전환하고, 포스트를 작성하며, 주장을 검토하고, 제 사이트에 게시하고, 위험한 부분이 마법인 척하는 것 없이 배포 작업을 준비할 수 있는 단일 로컬 시스템을 원했습니다. m0lz.01이 바로 그 시스템입니다. 이것은 동일한 SQLite 상태와 파일 아티팩트 위에 Codex 및 Claude 작성 표면(authoring surfaces)을 갖는 독립형 블로그 CLI입니다. CLI가 기계적인 작업을 담당합니다. Codex와 Claude는 계획하고, 쓰고, 검토하며, 이를 운영하는 데 도움을 줍니다. 중요한 부분은 이것이 글을 쓸 수 있다는 것이 아닙니다. 중요한 부분은 이 시스템이 제가 검사할 수 있는 워크플로우를 남긴다는 것입니다.

Shape 파이프라인은 여섯 가지 작업 단계로 구성되어 있습니다: ideas, research, benchmark, draft, evaluate, 그리고 publish입니다. published는 성공적인 터미널 상태입니다. unpublished는 정규 URL(canonical URL)이 영구적이기 때문에 슬러그를 예약하는 롤백 상태입니다. 허브는 이 사이트입니다. 모든 포스트는 https://m0lz.dev/writing/<slug> 에 게시됩니다. 크로스포스트는 그들의 정규 URL을 이곳으로 되돌립니다. 프로젝트 리포지토리와 연구 페이지는 진실의 경쟁적인 출처가 아니라, 허브를 둘러싼 바퀴살입니다.

CLI는 상태를 .blog-agent/state.db에 저장하고 그 옆에 단계별 아티팩트(phase artifacts)를 작성합니다: 리서치 노트, 벤치마크 결과, MDX 초안, 평가 보고서, 생성된 리서치 페이지, 소셜 붙여넣기 파일, 게시 영수증. 듣기에 지루하게 들릴 수 있지만, 그럴 만도 합니다. 지속 가능한 가치는 에이전트의 개성이 아닙니다. 그것은 채팅 창을 넘어서 생존하는 상태입니다. Codex 우선, Claude만 아니다 이 이야기의 첫 번째 버전은 /blog Claude 표면에 과도하게 의존했습니다. 왜냐하면 그것이 최초로 다듬어진 대화형 경로였기 때문입니다. 하지만 그것이 더 이상 전체 그림은 아닙니다. 진실은 더 간단합니다: m0lz.01은 로컬 CLI가 우선입니다. Codex는 이제 제가 시스템을 작업하고 운영하는 일급 방식(first-class way)입니다. 이 리포지토리에는 .codex/commands/* 아래에 Codex 명령어 래퍼와 .agents/skills/source-command-* 아래로 마이그레이션된 소스-명령어 스킬이 있습니다. Claude Code는 여전히 패키징된 .claude-plugin/ /blog 스킬을 가지고 있으며, 이 플러그인은 npm tarball에 포함됩니다. 이들은 동일한 CLI 경계 위의 두 클라이언트입니다. 어느 쪽도 데이터베이스가 될 수 없고, 게시 시스템이 될 수도 없습니다. 그들은 작업을 제안하고, 파일을 검사하며, 텍스트를 초안 작성하고, 확인을 실행하며, 상태 변경을 blog로 넘깁니다. 이 구분이 중요합니다. 만약 제가 Codex에서 글을 쓰고 있다면, 코드 변경에 사용하는 것과 동일한 계획 및 평가 규율(evaluation discipline)을 실행할 수 있습니다. 만약 제가 Claude Code에 있다면, 패키징된 /blog 흐름을 사용할 수 있습니다. 콘텐츠 파이프라인은 다음 승인된 단계를 생성하는 데 어떤 어시스턴트가 도움을 주었는지 신경 쓰지 않습니다.

하나의 프롬프트가 아무런 판단을 의미하지는 않습니다. 쾌적한 데모는 다음과 같습니다. 출시 게시물을 요청하면 발행된 게시물을 얻습니다. 실제 워크플로우는 더 엄격합니다. 작성 계층(authoring layer)이 계획을 제안합니다. CLI는 이 계획이 등록된 리프 명령어(leaf commands)로 구성되었는지 검증합니다. 운영자(operator)가 이를 승인합니다. blog agent apply가 승인된 단계를 실행하고 영수증을 작성합니다. 프로젝트 출시의 경우, 작업은 대략 다음과 같습니다: blog research init m0lz-01-launch --topic "m0lz.01 launch" blog research finalize m0lz-01-launch blog benchmark skip m0lz-01-launch blog draft init m0lz-01-launch blog draft complete m0lz-01-launch blog evaluate init m0lz-01-launch blog evaluate structural-autocheck m0lz-01-launch blog evaluate record m0lz-01-launch structural structural.json blog evaluate record m0lz-01-launch adversarial adversarial.json blog evaluate record m0lz-01-launch methodology methodology.json blog evaluate synthesize m0lz-01-launch blog evaluate complete m0lz-01-launch blog publish start m0lz-01-launch 계획 경로는 이러한 명령어들을 해시 게이트(hash gate)로 감쌉니다. 승인은 표준 계획 페이로드(canonical plan payload)의 SHA256 해시를 기록합니다. 만약 계획이 승인 후에 변경되면, 검증하고 HASH_MISMATCH와 함께 거부합니다. 이 게이트는 유용하지만 샌드박스(sandbox)는 아닙니다. 작성 표면(authoring surface)은 여전히 blog 명령어를 실행하도록 요청할 수 있습니다. 터미널에 있는 인간은 여전히 계획 시스템을 우회할 수 있습니다. 모델은 협조적입니다: 협조적인 작성자, 협조적인 어시스턴트, 그리고 승인된 경로에서 실수로 벗어나기 어렵게 만드는 CLI가 존재합니다.

평가는 시스템이 가치를 창출하는 곳입니다. 저는 초안을 신뢰하지 않습니다. 저는 압박을 신뢰합니다. m0lz.01은 세 명의 심사위원 패널을 운영합니다: 구조적 검토(Structural review)는 콘텐츠 형태, MDX 계약(contract), 출처 및 게시 준비 상태를 확인합니다. 적대적 검토(Adversarial review)는 Codex GPT-5.5 high를 사용하여 논제에 반박합니다. 방법론적 검토(Methodology review)는 Codex GPT-5.5 xhigh를 사용하여 벤치마크 유효성, 재현성 및 증거 주장을 확인합니다. 종합 단계(synthesis step)에서는 발견된 내용을 합의(consensus), 다수(majority), 단일 심사위원 이슈로 그룹화합니다. 합의 및 다수 이슈는 차단됩니다(block). Autocheck 발견 사항도 차단됩니다(block). 단일 심사위원 이슈는 자문적일 수 있지만, 저는 이 게시물을 테스트하는 동안 여러 알고리즘 패스를 거부했는데, 이는 심각한 발견 사항들이 단일 심사위원 자문으로 나타났기 때문입니다. 그것이 유용한 신호였습니다. 시스템은 단순히 녹색 체크 표시를 생성하지 않았습니다. 제가 그 결과를 거부할 수 있을 만큼 약점을 눈에 보이게 만들었습니다.

자동으로 배포되는 것(What Ships Automatically) 게시 파이프라인은 체크포인트가 설정되어 있습니다. 만약 5단계에서 실패하면, 다음 블로그 게시물 시작 <slug>은 5단계부터 재개됩니다. 각 단계는 아이덴티티(idempotent)하도록 설계되었습니다. 이 파이프라인은 다음을 수행할 수 있습니다: 허브 레포지토리의 표준 MDX 생성 또는 업데이트, 연구 동반 페이지 생성, 사이트 풀 리퀘스트 게이트 일시 중지, published: false로 Dev.to 초안 작성, 표준 URL을 Dev.to 초안에 첨부, 붙여넣기 준비가 된 Medium, Substack, LinkedIn 및 Hacker News 텍스트 준비, 프로젝트 레포지토리가 존재할 때 동반 레포지토리 링크 업데이트. 현재 제가 자동화하기를 원하는 유일한 API 크로스 포스팅 경로는 Dev.to입니다.

Medium, Substack, LinkedIn 및 Hacker News는 수동 검토 단계가 여전히 유용하고 API를 게시 경로에 바인딩할 가치가 아직 없기 때문에 붙여넣기 준비된 출력 상태로 유지됩니다. 아직 바인딩하지 않은 것: plan hash는 .blogrc.yaml을 바인딩하지 않습니다. 워크스페이스 설정이 승인과 적용 사이에 변경되면, plan hash가 이를 감지하지 못합니다. plan은 장소를 운영자 측면의 완화책으로 표시하지만, config-hash 바인딩은 여전히 향후 작업입니다. SQLite 데이터베이스는 로컬 상태이며 보호된 상태가 아닙니다. 워크스페이스가 중요하다면 업그레이드 전에 백업하세요. 잠금(lock)은 슬러그 범위(slug-scoped)이며 협력적입니다. 동일한 슬러그에 대한 두 개의 적용이 동시에 실행되는 것을 방지합니다. .blog-agent/ 내부의 임의 파일 시스템 편집으로부터는 보호하지 못합니다. 이러한 제한 사항들이 시스템을 쓸모없게 만들지는 않습니다. 그것들은 경계를 정의할 뿐입니다. m0lz.01은 범용 보안 에이전트 런타임(general-purpose secure agent runtime)이 아닙니다. 이는 영수증, 단계 게이트(phase gates), 그리고 제가 어시스턴트가 작성한 것을 가장 먼저 배포하는 것을 막을 만큼 충분한 마찰력이 있는 로컬 게시 워크플로우입니다. 설치: CLI를 전역으로 설치하고 바이너리가 올바르게 해결되는지 확인합니다: npm install -g m0lz-01 blog --help 프로젝트 레포지토리 외부의 전용 워크스페이스를 생성합니다: mkdir -p ~/blog cd ~/blog blog init .blogrc.yaml을 허브 사이트 레포, 기본 URL, 콘텐츠 디렉터리, 작성자 핸들 및 선택적 프로젝트 맵으로 편집합니다. 그런 다음 Dev.to 게시가 활성화된 경우 .env 파일을 수정하여 DEVTO_API_KEY를 추가합니다.

로컬 커맨드 래퍼 워크플로우를 원할 때는 m0lz.01 리포의 Codex를 사용하세요: .codex/commands/prime.md .codex/commands/plan-feature.md <주제> .codex/commands/execute.md <계획 파일> .codex/commands/evaluate.md <계획 파일> /blog 스킬을 원할 때는 패키징된 Claude Code 플러그인을 사용하세요: claude --plugin-dir " $( npm root -g ) /m0lz-01/.claude-plugin" 그런 다음 실제 질문으로 시작합니다: /blog 새로운 프로젝트를 시작하려면 소스는 github.com/jmolz/m0lz.01에 있습니다. 이 리포는 CLI, 패키징된 Claude 플러그인, Codex 커맨드 래퍼, 그리고 게시 경로의 정직함을 유지하는 회귀 테스트(regression tests)를 포함합니다.