‘초안 생성’ 버튼 하나가 글쓰기 도구의 설계를 바꿨습니다

AI 요약

Meldr는 기술 글을 쓰는 과정에서 흩어진 조사 자료와 AI 대화, 메모를 한곳에 모으려는 터미널 기반 도구입니다. 흐름은 조사, 관점 설정, 편집 개요 작성, 개요 승인, 집필, 검토, 게시 순서입니다. 모든 단계의 자료는 Markdown 파일로 남고, 편집 개요 승인과 검토 제안 수락은 사람이 결정합니다.

기본값이 글쓰기 방식을 정합니다

저자는 편집 개요 승인 다음 단계에 있던 ‘초안 생성’ 버튼을 없앴습니다. 개요 승인이 곧 전체 글 생성을 뜻하면, 도구가 AI가 쓴 글을 권장하는 셈이기 때문입니다. 저자는 기술 글의 가치를 실제 버그와 예상 밖의 발견, 어려웠던 절충처럼 작성자만 제공할 수 있는 경험에서 찾습니다. 그런 맥락이 없는 모델은 그럴듯하지만 서로 비슷한 문장을 채워 넣기 쉽다고 설명합니다.

Meldr는 AI 집필 자체를 반대하지 않습니다. 다만 도구가 권장하는 기본 경로가 AI 완성본으로 이어지지 않도록 초안 생성 기능을 설정 뒤에 숨기는 대신 제거했습니다. 개요를 승인한 뒤에는 working.md를 열어 직접 씁니다.

제안과 원문을 분리합니다

프로젝트 파일은 brief.md에 방향·독자·논지·범위·개요를, working.md에 본문을 둡니다. editorial-notes.md에는 작성자에게 남긴 자리표시자와 확인할 일을 기록하고, revisions/에는 검토 제안과 섹션 제안, 주장 보고서를 보관합니다.

Meldr는 제목만 있는 파일을 검토하지 않습니다. 본문이 생기면 구조와 문체, 근거보다 단정적인 주장을 살펴보고 결과를 제안으로 돌려줍니다. 작성자는 제안을 수락하거나 수정하거나 무시할 수 있습니다. 특정 섹션에서 막혔을 때는 직접 쓰기, 요점 제안, 시작 도움, 건너뛰기 중 선택합니다. 모델은 요청받았을 때만 호출되며, 결과는 작성자가 승인하기 전까지 working.md를 바꾸지 않습니다.

오래된 제안과 확인되지 않은 주장을 막습니다

검토 뒤 본문을 고치면 기존 제안이 더는 현재 글에 맞지 않을 수 있습니다. Meldr는 제안을 만들 때 원문 기사에 SHA-256 다이제스트를 기록하고, 수락 시 현재 파일의 다이제스트와 비교합니다. 값이 다르면 제안을 오래된 것으로 처리해 적용을 거부합니다.

모델이 실제 사례를 모르면 지어낼 수 있으므로, 작성자만 채울 수 있는 부분은 [AUTHOR: ...] 형태로 남깁니다. 검증이 필요한 주장도 참이라고 판정하지 않고, 필요한 근거를 안내하는 별도 보고서로 관리합니다. 주장 보고서를 수정 제안과 분리해 불확실한 내용이 검증된 문장처럼 본문에 들어가는 일을 피합니다.

Meldr는 초안을 곧바로 만들어 주는 도구보다 느립니다. 대신 저자가 필요로 했던 조사, 구조화, 확인을 지원하고 글 자체는 작성자가 쓰도록 설계했습니다. 프로젝트 파일은 로컬에 두지만, 모델 도움을 요청하면 관련 맥락은 설정한 제공업체로 전송됩니다. 자동 게시 기능은 없습니다.

dev.to 반응

• @launchgatecheck — 주장 보고서를 수정 제안과 분리한 경계 설정이 유용합니다. 다이제스트 검사에서 한 가지 경우를 더 확인하고 싶습니다. 같은 working.md를 기준으로 검토한 제안 두 개는 처음에는 모두 유효하지만, 첫 번째를 수락하면 두 번째는 오래된 제안이 되어야 합니다. 이 경로를 테스트하나요? 수락 절차가 시작된 뒤 쓰기가 실패하는 경우도 넣어, 본문 일부만 남거나 제안이 잘못 수락 처리되지 않는지 확인하면 좋겠습니다. 편집과 수락 사이에 생기는 변경만 보는 게 아니라 수락 계약 전체를 시험하게 됩니다.
  • @mikachu — 유용한 예외 상황을 알려줘서 감사합니다. 첫 번째 제안을 수락하면 working.md가 바뀌므로 다이제스트 검사로 두 번째 제안을 오래된 것으로 처리해야 합니다. 하지만 아직 해당 테스트는 없어서 추가하겠습니다. 임시 파일에 쓴 뒤 working.md를 덮어쓰도록 이름을 바꾸고, 그 뒤에 제안을 수락 처리하겠습니다. 각 단계에서 실패하는 테스트를 추가해 일부만 반영되지 않는지 확인하겠습니다.
• @aikotanaka — 검증과 집필을 분리한 설계가 특히 마음에 듭니다. 주장 보고서를 문서 밖에 두는 점도 좋습니다. 모델이 검증되지 않은 주장을 본문에 넣으면, 나중에 편집하면서 모든 문장을 다시 사실 확인하게 되곤 합니다. 주장을 미해결 체크리스트로 다루면 실제 집필 문서가 더 깔끔하게 유지됩니다.

원문: dev.to / 번역·요약: Trawling