마크다운 사용 가이드: MD 파일 열기부터 회의록·README 작성과 PDF 저장까지
마크다운을 처음 쓰는 사람을 위한 실무 가이드입니다. 제목·표·체크리스트·코드 문법, 회의록과 README 작성 순서, UTF-8 파일 열기, MD·HTML·PDF 차이와 저장 전 확인 방법을 설명합니다.
처음 사용할 때 가장 궁금한 네 가지
문법을 익히기 전에 파일을 여는 방법과 저장 형식부터 정하세요.
MD 파일은 무엇으로 여나요?
마크다운 편집기 또는 일반 텍스트 편집기로 엽니다.툴킷에서는 UTF-8 .md·.markdown 파일 한 개를 선택하거나 끌어다 놓을 수 있습니다.
파일 열기와 인코딩 확인왜 줄을 바꿨는데 붙어 보이나요?
일반 줄바꿈과 문단 구분은 다릅니다.문단 사이에는 빈 줄을 넣으세요. 줄 끝 공백에 의존하는 방식은 공유 과정에서 달라질 수 있습니다.
문단과 제목 작성법계속 수정할 문서는 무엇으로 저장하나요?
MD 원문을 보관하고 HTML·PDF를 사본으로 만드세요.HTML·PDF는 읽기와 공유에 유용하지만 원래 마크다운 구조를 다시 편집하는 목적과는 다릅니다.
저장 형식 선택하기입력한 내용이 자동 저장되나요?
툴킷은 문서 내용을 자동 저장하지 않습니다.탭을 닫거나 페이지를 이동하기 전에 MD 다운로드를 눌러 저장 여부를 확인하세요.
작업 내용을 잃지 않는 습관근거 확인 · CommonMark 0.31.2 — 제목·문단·목록·코드·링크 문법 ↗ · GitHub Flavored Markdown Spec — 표·작업 목록 등 확장 ↗
먼저 알아두세요
마크다운은 제목·목록·강조 같은 구조를 텍스트와 기호로 기록하는 방식입니다. MD 파일은 특정 프로그램에만 묶인 문서가 아니어서 일반 텍스트 편집기로 내용을 읽을 수 있고, 뷰어에서는 보기 좋은 문서로 확인할 수 있습니다. 이 가이드는 기호를 외우는 데서 끝내지 않고 회의록, README, 인수인계 문서를 실제로 정리하는 순서를 설명합니다. 툴킷에서는 파일을 열고 원문과 미리보기를 나란히 비교한 뒤 MD 또는 HTML로 저장할 수 있습니다. 나중에 다시 고칠 원문과 다른 사람에게 전달할 읽기용 사본을 구분하는 것이 첫 번째 원칙입니다.
2026년 10월 4일 기준 툴킷 편집기의 지원 범위를 설명합니다. CommonMark의 기본 구조와 GFM 확장 문법을 중심으로 하며, 모든 서비스의 마크다운 표시가 동일하다고 가정하지 않습니다. 아래 사람 이름·날짜·업무 상황은 문서 작성 방법을 설명하기 위한 가상 예시입니다.
01마크다운이 잘 맞는 문서부터 고르세요
마크다운을 처음 접하면 워드나 한글의 간단한 대체품으로 생각하기 쉽습니다. 그러나 먼저 문서의 목적을 나눠보면 선택이 편해집니다. 회의에서 정한 일을 공유하거나 소프트웨어 사용 순서를 설명하는 문서는 내용의 순서와 구조가 중요합니다. 이런 문서는 제목, 문단, 목록과 짧은 표만으로도 충분히 읽기 좋게 만들 수 있습니다. 반대로 제출 기관이 정확한 양식, 칸 크기, 서명 위치를 지정했다면 그 양식을 유지하는 편집 도구가 더 적합합니다.
팀 회의록을 예로 들어보겠습니다. 회의 날짜와 참석자, 결정 사항, 담당자와 기한이 핵심이라면 복잡한 꾸밈 없이 기록할 수 있습니다. 첫 줄에 회의 이름을 적고 그 아래에 배경, 결정 사항, 후속 작업을 나누면 됩니다. 글꼴을 바꾸는 데 시간을 쓰기보다 아직 결정되지 않은 항목과 확정된 항목을 분리하세요. 나중에 읽는 사람이 자신의 다음 행동을 찾을 수 있다면 목적에 맞는 문서입니다.
README는 폴더나 프로젝트의 입구에 놓는 안내문입니다. 개발 프로젝트뿐 아니라 행사 운영 자료, 공용 템플릿, 데이터 전달 폴더에도 쓸 수 있습니다. 파일이 무엇인지, 어디서부터 봐야 하는지, 언제 갱신되었는지를 적으면 전달받은 사람이 여러 파일을 무작정 열지 않아도 됩니다. 원본 자료는 별도로 두고 README에는 자료의 역할과 사용 순서를 설명하는 식으로 구성해보세요.
계산이 필요한 표, 복잡한 도형, 여러 사람이 동시에 수정해야 하는 장부까지 한 MD 파일에 넣으려 할 필요는 없습니다. 숫자를 계산하는 원본은 스프레드시트에 두고 마크다운에는 계산 목적과 확인 결과를 적을 수 있습니다. 온라인 공동 편집이나 변경 승인 절차가 필요하다면 그 기능이 있는 문서 관리 환경을 함께 선택하세요. 툴킷 편집기는 한 브라우저에서 문서를 읽고 고치는 도구이며 공동 편집 공간이나 파일 보관 서비스가 아닙니다.
02MD 파일 열기: 확장자, 인코딩, 크기 확인
이미 파일을 받았다면 먼저 확장자를 확인하세요. 툴킷의 파일 열기는 .md와 .markdown을 받습니다. 압축파일이나 워드 문서의 이름만 .md로 바꾼다고 마크다운이 되는 것은 아닙니다. 파일 형식을 변환해야 하는 경우에는 원래 프로그램에서 일반 텍스트를 내보낸 뒤 내용을 정리하세요. 파일 선택 창에 보이지 않는다면 실제 확장자가 무엇인지 운영체제의 파일 정보에서 살펴보는 것이 첫 단계입니다.
한글이 제대로 보이려면 글자를 저장한 인코딩과 읽는 방식이 맞아야 합니다. 툴킷은 UTF-8 파일을 읽으며 다른 인코딩을 추측해서 변환하지 않습니다. UTF-16이나 CP949로 저장한 파일에서 오류가 나면 원래 텍스트 편집기로 열어 인코딩을 UTF-8로 지정하고 사본을 저장하세요. 이미 깨진 글자를 그대로 다시 저장하면 원래 글자가 복원되는 것은 아닙니다. 정상으로 보이는 원본을 확보한 다음 변환해야 합니다.
파일 선택 대신 드래그해서 편집 영역에 놓을 수도 있습니다. 한 번에는 문서 한 개를 받으며 폴더와 연결된 이미지 파일을 함께 읽지는 않습니다. 이미 작성하던 내용이 있다면 교체 안내가 나타납니다. 현재 MD 저장을 누른 다음 실제 다운로드를 확인하고 새 내용을 열면 됩니다. 취소를 누르면 작성 중인 내용을 유지합니다. 파일을 열어 수정해도 기기에 있던 원본 파일이 즉시 바뀌지는 않습니다.
파일 용량과 글자 수는 다른 제한입니다. 한글은 UTF-8에서 여러 바이트를 사용하므로 같은 글자 수의 영문 문서와 용량이 다를 수 있습니다. 툴킷은 파일당 1MiB, 편집 내용 100,000자와 5,000줄을 제한으로 둡니다. 화면의 글자 수는 편집기의 문자열 길이 기준이라 일부 이모지는 여러 자리로 셀 수 있습니다. 소설 원고 전체나 큰 로그 파일보다는 주제별로 나눈 문서가 편집과 검토에 적합합니다. 빈 파일도 열 수 있으며 오른쪽 안내가 보이면 왼쪽에 내용을 입력하면 됩니다.
03좌우 화면으로 원문과 결과를 함께 확인하기
편집기를 처음 열면 짧은 예제 문서가 나옵니다. 왼쪽에는 기호를 포함한 원문이, 오른쪽에는 문서로 표시한 결과가 보입니다. 제목 앞의 #이나 강조할 말 양쪽의 **를 하나씩 바꾸며 차이를 확인하면 문법의 역할을 이해하기 쉽습니다. 예제는 설명용이며 개인 문서를 불러오기 전까지 사용자의 파일을 읽지 않습니다. 빈 페이지에서 시작하려면 새 문서를 선택하세요.
나란히 모드는 넓은 화면에서 작성과 확인을 함께 할 때 적합합니다. 긴 문장에 집중하고 싶을 때는 편집 모드, 문서 전체의 흐름을 읽을 때는 미리보기 모드를 선택하세요. 좁은 화면에서는 두 영역이 위아래로 배치됩니다. 휴대전화에서 원문과 결과를 번갈아 보고 싶다면 각 모드로 전환하는 편이 편합니다. 글자 크기는 16, 18, 20, 22px 중 고를 수 있으며 화면에서 읽는 크기를 조절합니다.
자동 줄바꿈은 편집 화면의 한 줄을 화면 폭에 맞춰 접어 보여주는 기능입니다. 이 옵션을 바꿔도 파일 원문에 새로운 줄바꿈 문자가 들어가지 않습니다. 긴 주소나 한 줄짜리 코드의 실제 구조를 살펴보려면 옵션을 끄고 가로로 이동해보세요. 미리보기의 긴 코드나 넓은 표도 해당 영역 안에서 가로로 이동할 수 있습니다. 줄이 화면에서 접힌 것과 원문에서 Enter를 누른 것은 서로 다릅니다.
문법 버튼은 선택한 글자에 기호를 추가하거나 현재 줄 앞에 목록 표시를 넣습니다. 굵게, 기울임과 링크는 먼저 원하는 부분을 선택하면 편합니다. 제목과 목록 버튼은 현재 줄 또는 선택한 여러 줄에 표시를 추가하므로 같은 버튼을 여러 번 누르면 기호가 반복될 수 있습니다. 결과가 의도와 다르면 실행 취소를 누르거나 원문을 고치세요. 전체화면은 브라우저가 지원할 때 사용할 수 있으며 Esc로 돌아올 수 있습니다. 전체화면을 나가도 내용은 유지되지만 페이지 자체를 닫기 전에는 따로 저장해야 합니다.
04제목과 문단: 읽는 순서를 먼저 설계하기
문법을 많이 쓰는 것보다 제목을 잘 나누는 것이 먼저입니다. 문서의 대표 제목을 맨 위에 하나 두고, 그 아래에는 배경, 준비 사항, 진행 방법, 확인 결과처럼 독자의 질문 순서대로 소제목을 놓아보세요. 예를 들어 안내문을 받는 사람이 가장 먼저 알고 싶은 내용이 신청 대상이라면 작성자의 내부 진행 경과보다 신청 대상을 앞에 두는 편이 자연스럽습니다. 제목만 훑어도 문서의 목적을 이해할 수 있는지 점검하세요.
기본 제목은 줄 맨 앞에 #과 공백을 둡니다. #은 큰 제목, ##은 그 아래 단계, ###은 더 작은 단계에 사용할 수 있습니다. 숫자가 클수록 중요한 제목이라는 뜻은 아니며 구조의 깊이가 달라집니다. 글자를 작게 만들기 위해 제목 단계를 건너뛰기보다 내용의 관계에 맞춰 순서를 정하세요. 툴킷의 제목 버튼은 두 번째 단계인 ##를 넣습니다. 첫 제목은 원문에서 #으로 바꾸면 됩니다.
문단을 나누려면 문단 사이에 빈 줄을 넣으세요. 일반 문장 중간에서 Enter를 한 번 누른 것은 미리보기에서 공백처럼 이어질 수 있습니다. 주소나 시처럼 반드시 한 줄씩 구분해야 하는 짧은 내용은 줄 끝 공백이나 줄바꿈 문법을 사용할 수 있지만, 보이지 않는 공백이 복사 과정에서 사라지는 문제를 고려해야 합니다. 일반 업무 문서라면 빈 줄로 문단을 나누거나 목록으로 재구성하는 편이 검토하기 쉽습니다.
강조는 독자가 놓치면 안 되는 짧은 구절에만 사용하는 것이 좋습니다. 문단 전체를 굵게 만들면 어느 부분이 핵심인지 다시 찾기 어렵습니다. 신청 마감일, 변경된 조건, 제출할 파일명처럼 구체적인 정보에 적용해보세요. 본문에서 별표 자체를 표시하고 싶은데 강조로 해석된다면 앞에 역슬래시를 붙여 기호를 문자로 나타낼 수 있습니다. 문법 기호가 섞인 내용을 설명할 때는 짧은 코드 표시를 사용하는 방법도 있습니다.
| 원문 예시 | 용도 | 확인할 점 |
|---|---|---|
| # 문서 제목 | 대표 제목 | # 뒤에 공백을 넣습니다. |
| ## 준비 사항 | 큰 항목 구분 | 같은 단계끼리 비슷한 범위를 다룹니다. |
| **마감일** | 중요한 말 강조 | 여닫는 별표 개수를 맞춥니다. |
| > 확인이 필요한 내용 | 인용 블록 | 인용의 출처와 맥락을 함께 설명합니다. |
| `report.md` | 파일명·짧은 코드 | 코드가 실행되는 것은 아닙니다. |
05목록과 체크리스트: 읽기 좋은 할 일 만들기
순서가 없는 항목은 하이픈과 공백으로 목록을 만들고, 순서가 중요한 절차는 숫자 목록으로 표현하세요. 회의 준비물은 순서 없는 목록으로 충분하지만 신청서 제출 절차는 첫 단계와 다음 단계가 구분되어야 합니다. 하나의 목록에 설명과 결정, 질문을 모두 넣으면 항목의 성격이 섞입니다. 처음에는 결정 사항과 확인할 사항을 별도 소제목으로 나누는 것만으로도 읽기가 훨씬 편해집니다.
체크리스트는 작업 상태를 표시하는 데 유용합니다. 원문에 - [ ]를 쓰면 미완료, - [x]를 쓰면 완료 표시가 됩니다. 툴킷 미리보기의 체크박스는 읽기 전용이므로 클릭해서 문서를 바꾸는 방식이 아닙니다. 왼쪽 원문에서 괄호 안의 공백을 x로 바꾸세요. 미리보기에 체크가 생겼다면 MD로 저장해야 그 상태가 파일에 남습니다. 화면에서 체크된 모습을 확인하는 것과 파일을 저장하는 것은 별개의 행동입니다.
좋은 할 일은 행동과 완료 조건이 함께 있습니다. ‘자료 확인’보다는 ‘지민: 견적서의 수량과 단가를 대조하고 확인 결과를 금요일까지 회신’처럼 적어보세요. 다만 한 줄이 너무 길어지면 담당자, 기한과 설명을 여러 항목으로 나누는 편이 좋습니다. 작업 목록을 작성할 때 모든 세부 내용을 한 번에 넣기보다 책임자가 바로 움직일 수 있는 최소 정보부터 정리하세요. 관련 자료의 위치는 별도 링크나 파일명으로 안내할 수 있습니다.
완료 체크가 있다고 해서 검토나 승인이 끝났다는 뜻은 아닐 수 있습니다. 초안 작성 완료와 최종 배포 완료는 서로 다른 상태입니다. 팀에서 쓰는 문서라면 무엇을 완료로 볼지 앞부분에 짧게 정해두세요. 예를 들어 ‘체크 표시는 담당자 작성 완료, 최종 검토는 아래 검토 결과에 기록’이라고 적으면 오해를 줄일 수 있습니다. 장기 프로젝트의 변경 이력과 업무 알림까지 필요하다면 MD 파일만으로 관리하기보다 별도 업무 관리 도구와 역할을 나누는 편이 좋습니다.
06표는 비교에 쓰고, 계산은 원본에서 확인하세요
표는 항목별 정보를 같은 기준으로 비교할 때 유용합니다. 담당자와 기한, 버전과 변경 내용, 파일명과 용도처럼 열의 의미가 일정하면 문장이 길게 이어지는 것보다 보기 쉽습니다. 마크다운 표는 세로 막대로 칸을 나누고 제목 행 다음에 구분 행을 둡니다. 툴킷의 표 버튼을 누르면 작은 예시가 들어가므로 항목과 내용을 바꿔보세요. 칸의 구분과 제목 행이 바르게 보이는지 오른쪽에서 확인할 수 있습니다.
마크다운 표를 엑셀처럼 생각하면 혼동하기 쉽습니다. 표 안에 100과 200을 적고 마지막 줄에 합계 300을 넣어도 자동 계산이 되는 것이 아닙니다. 숫자를 바꾸면 합계도 직접 수정해야 합니다. 업무 결과를 보고할 때는 스프레드시트의 계산 결과를 먼저 확인하고 그중 독자가 필요한 값만 표로 옮기세요. 합계, 집계 기준일과 단위를 함께 적어야 다른 사람이 숫자의 의미를 파악할 수 있습니다.
열이 많은 표를 한 화면에 모두 넣으려 하면 휴대전화에서 읽기 어려워집니다. 예를 들어 열 개 부서의 세부 실적을 그대로 붙이기보다 부서별 요약 표와 세부 자료를 나누어 전달해보세요. 설명이 긴 칸은 표 아래의 문단으로 빼는 방법도 있습니다. 미리보기에서 가로 스크롤이 생기면 고장이라고 판단하기 전에 열 개수와 각 칸의 문장 길이를 살펴보세요. 인쇄에서는 화면보다 폭이 좁아질 수 있으므로 별도로 미리 확인해야 합니다.
표의 숫자는 보기 좋은 정렬보다 기준을 분명히 하는 것이 우선입니다. 금액이 원인지 천 원인지, 수량이 건수인지 사람 수인지 제목 또는 캡션에 적으세요. 빈칸을 0으로 이해할 수 있는지도 설명해야 합니다. 금액을 모르는 상태와 금액이 실제로 0인 상태는 다릅니다. 예시 표를 복사했다면 가상 숫자가 실제 자료처럼 남아 있지 않은지 마지막에 점검하세요. 표 안에 세로 막대 문자 자체가 필요하면 이스케이프 문법을 사용하고 결과 칸 수가 의도한 대로인지 확인하세요.
07링크와 코드: 실행보다 설명에 집중하기
링크는 주소만 길게 붙이는 것보다 무엇을 여는지 설명하는 제목을 붙이는 편이 읽기 좋습니다. ‘여기’라는 말이 여러 번 반복되면 독자는 클릭하기 전에 목적지를 알기 어렵습니다. ‘행사 일정표’나 ‘설치 안내 원문’처럼 대상이 분명한 이름을 써보세요. 링크 버튼은 제목과 예시 주소를 넣으므로 실제 주소로 바꾸는 것을 잊지 마세요. 인터넷에서 복사한 주소에 개인용 토큰이나 비공개 식별 정보가 포함되어 있지는 않은지도 공유 전에 살펴보세요.
툴킷은 http, https, mailto 주소와 문서 내부 조각 링크를 제한적으로 처리합니다. 상대 경로는 연결할 프로젝트 폴더가 없어서 비활성화합니다. 예를 들어 ./images/photo.png가 원래 프로젝트에서는 올바른 경로여도 이 편집기는 그 폴더를 함께 읽지 않습니다. 공개 웹 주소라면 전체 주소를 쓸 수 있지만, 접근 권한이 필요한 페이지의 권한까지 이 도구가 바꾸지는 않습니다. 문서 내부 링크도 실제로 대응하는 식별자가 있어야 이동하며, 일반 제목에 자동 목차용 식별자를 붙여주는 기능은 제공하지 않습니다.
짧은 명령이나 파일명은 백틱 한 쌍으로 감싸고 여러 줄의 코드는 백틱 세 개로 블록을 만들 수 있습니다. 코드 블록은 설명을 위한 텍스트입니다. 버튼을 눌러 실행하거나 결과를 계산해주는 환경이 아닙니다. 툴킷에서는 코드의 언어 이름을 적을 수 있지만 언어별 색상 강조를 보장하지 않습니다. 독자가 복사해서 실행할 명령이라면 명령 자체뿐 아니라 실행 위치, 필요한 준비와 예상 결과를 함께 적어야 합니다.
예를 들어 설치 안내에 명령 한 줄만 적으면 사용자는 어느 폴더에서 실행하는지, 이미 설치한 사람도 다시 해야 하는지 판단하기 어렵습니다. ‘프로젝트 폴더에서 실행’처럼 문맥을 먼저 쓰고, 실행 후 확인할 화면이나 파일을 뒤에 적어보세요. 실제 계정의 비밀번호, API 키, 개인 주소를 예시 코드에 넣지 마세요. 자리표시자를 썼다면 무엇을 자신의 값으로 바꿔야 하는지 설명합니다. 설명용 자리표시자와 실행 가능한 명령을 구분하는 것이 사용 설명서의 품질을 높입니다.
08실전 예시: 회의 메모를 실행 가능한 회의록으로 바꾸기
가상의 월요일 회의를 생각해보겠습니다. 메모에는 ‘신규 안내문 필요, 금요일 확인, 고객 질문 많음, 지민 초안, 수현 검토’라는 말만 남아 있습니다. 회의에 참여한 사람은 기억할 수 있지만 이틀 뒤 처음 읽는 사람은 금요일에 무엇을 확인하는지 알기 어렵습니다. 마크다운으로 옮기기 전에 문서의 목적을 ‘신규 안내문 배포를 위해 결정한 일과 담당을 공유’로 한 문장으로 정해보세요. 그 문장이 문서에 넣을 정보와 뺄 정보를 고르는 기준이 됩니다.
먼저 날짜, 참석자와 논의 대상을 맨 위에 적습니다. 다음으로 배경과 결정 사항을 나눕니다. 배경에는 최근 같은 질문이 반복되어 안내문이 필요해졌다는 상황을, 결정 사항에는 어떤 고객을 대상으로 어느 채널에 배포할지를 적습니다. 아직 정하지 않은 배포 시간은 확정된 사실처럼 쓰지 않고 확인할 사항에 둡니다. 회의 중 나온 의견을 모두 결정 사항으로 옮기는 실수를 피하는 것이 핵심입니다.
후속 작업에는 담당자, 결과물과 기한을 함께 기록합니다. 지민은 목요일까지 안내문 초안 파일을 공유하고, 수현은 금요일 오전까지 실제 상담 내용과 표현이 맞는지 검토하는 식입니다. 담당자가 정해지지 않은 항목은 빈칸 대신 미정이라고 적고 누가 언제 담당을 정할지도 남겨보세요. 회의록 자체에 모든 자료를 복사하기보다 관련 자료의 파일명과 위치를 적으면 문서가 지나치게 길어지는 것을 줄일 수 있습니다.
미리보기에서 읽을 때는 참석하지 않은 동료의 입장이 되어보세요. 무엇을 해야 하는지, 언제까지인지, 어떤 상태가 완료인지 찾을 수 있는지 확인합니다. 회의록 끝에는 다음 확인 날짜와 아직 열린 질문을 남겨도 좋습니다. 마지막으로 MD 원문을 저장하고 검토자가 편하게 읽을 HTML이나 PDF 사본을 만듭니다. 배포한 뒤 중요한 결정이 바뀌었다면 기존 기록을 몰래 바꾸기보다 변경 날짜와 바뀐 이유를 덧붙여 경과를 남기는 편이 이해하기 쉽습니다.
| 항목 | 적을 내용 | 피할 표현 |
|---|---|---|
| 배경 | 같은 사용 문의가 반복되어 안내문을 보완함 | 아무 설명 없이 ‘문제 많음’ |
| 결정 | 신규 이용자를 위한 한 장 안내문을 만들기로 함 | 논의 중인 안을 확정처럼 기록 |
| 작업 | 지민: 목요일까지 초안 파일 공유 | 담당과 기한 없는 ‘준비하기’ |
| 확인 | 수현: 금요일 오전까지 내용 검토 | 무엇을 확인하는지 없는 ‘체크’ |
09실전 예시: 처음 받는 사람을 위한 README와 인수인계서
좋은 README는 작성자가 무엇을 했는지 나열하는 글보다 독자가 어디서 시작해야 하는지 알려주는 글에 가깝습니다. 처음 몇 문장에서 자료의 목적과 사용할 대상을 설명하세요. 예를 들어 ‘이 폴더는 월별 고객 문의를 분류한 요약 자료이며, 운영 회의에서 반복 질문을 확인할 때 사용합니다’라고 적으면 자료를 연 사람이 맥락을 알 수 있습니다. 데이터가 실제 개인정보를 포함한다면 이용 범위와 접근 권한에 관한 내부 규칙도 별도로 확인해야 합니다.
그다음 폴더 안의 파일이 각각 어떤 역할을 하는지 적습니다. 원본 자료, 정리한 자료와 보고용 결과를 구분하고, 자동 생성되는 파일인지 직접 수정하는 파일인지 알려주세요. 파일 이름에 final이나 최종이라는 표현이 여러 번 붙어 있다면 README에서 사용해야 할 파일과 기준일을 명시하는 것이 도움이 됩니다. 제목만 같은 사본들이 쌓이지 않도록 이름 규칙을 정하고 실제 파일과 설명이 서로 맞는지도 확인하세요.
실행 절차는 필요한 준비부터 확인 결과까지 이어지도록 작성합니다. 설치나 데이터 입력이 필요한 작업이라면 먼저 필요한 프로그램과 입력 파일을 설명하세요. 순서를 적은 다음 각 단계가 끝났을 때 어떤 결과가 나와야 하는지 한 줄씩 붙입니다. 중간 단계가 실패했을 때 확인할 경로를 적어두면 다음 담당자가 같은 문제를 반복해서 질문할 가능성을 줄일 수 있습니다. 다만 직접 확인하지 않은 해결책을 단정적으로 쓰기보다 어떤 조건에서 확인한 방법인지 남기는 편이 정확합니다.
인수인계서에는 정상 절차 외에 예외와 담당 범위를 담는 것이 좋습니다. 정기 작업은 언제 하는지, 누락이 생기면 누구에게 확인하는지, 어디까지 담당자가 직접 결정할 수 있는지를 분리하세요. 비밀번호를 문서에 적는 대신 조직에서 정한 자격 증명 관리 방법을 안내합니다. 연락처를 포함할 때는 공유 대상에 맞는 업무용 정보인지 확인하세요. 마지막 수정일을 쓰는 것만으로 내용이 최신이 되는 것은 아니므로 실제 절차를 한 번 따라가보고 필요한 부분을 고친 뒤 검토 날짜를 기록하는 것이 좋습니다.
10MD·HTML·PDF를 목적에 맞게 저장하기
계속 고칠 문서는 MD로 다운로드하세요. 제목 기호, 목록과 링크 주소를 포함한 원문이 남아 다른 편집기에서도 수정할 수 있습니다. 툴킷에서 파일을 열고 바꾼 내용은 원본 파일에 자동으로 덮어쓰지 않습니다. 다운로드한 파일이 새 결과입니다. 저장할 파일 이름을 문서 상단에서 바꿀 수 있으며 운영체제에서 파일 이름으로 쓰기 어려운 기호는 정리됩니다. 다운로드 폴더에 같은 이름이 있으면 브라우저가 번호를 붙일 수 있으니 최신 파일을 구분하세요.
HTML은 브라우저에서 읽을 수 있는 문서 사본입니다. 툴킷이 제공하는 HTML에는 본문을 읽기 위한 스타일이 함께 들어갑니다. 다른 사람에게 보내기 전에 직접 열어 제목, 표, 한글과 링크가 정상인지 확인해보세요. 이 편집기에서 제한하는 원시 HTML과 외부 이미지는 HTML 저장본에도 나타나지 않습니다. 원문에 이미지 문법이 남아 있다고 해서 이미지 파일이 HTML 안에 포함되는 것은 아닙니다. 화면과 저장본은 글꼴이나 창 너비에 따라 줄바꿈 위치가 달라질 수 있습니다.
PDF 저장·인쇄는 브라우저 인쇄 기능을 사용합니다. 인쇄 창에서 대상을 PDF로 저장으로 고른 다음 용지 크기, 여백과 배율을 확인하세요. 브라우저와 운영체제에 따라 버튼 이름과 선택 항목이 다를 수 있습니다. 머리글과 바닥글을 넣는 설정이 켜져 있으면 날짜나 문서 주소가 추가될 수 있으니 제출용 문서라면 인쇄 미리보기에서 확인합니다. 인쇄 창이 열리지 않으면 HTML 파일을 저장해 브라우저에서 연 뒤 인쇄 기능을 사용할 수 있습니다.
저장 형식은 우열보다 용도의 문제입니다. 원문 보관용 MD, 링크를 따라 읽는 HTML, 인쇄나 고정된 공유 사본으로 쓰는 PDF를 구분해보세요. PDF는 보는 기기에서 일정한 페이지 구성을 유지하기에 편리하지만 다시 마크다운으로 복원하려면 구조가 달라질 수 있습니다. 하나의 형식만 남겨야 한다고 생각하지 말고 중요한 문서는 MD와 배포 사본을 함께 보관하세요. 배포 후 오탈자가 발견되면 원문을 수정하고 새 사본을 만든 다음 버전과 기준일을 맞추는 순서로 처리하면 됩니다.
| 형식 | 잘 맞는 목적 | 저장 뒤 확인 |
|---|---|---|
| MD | 수정 가능한 원문과 변경 이력 보관 | 기호·문장·링크 주소가 남아 있는지 |
| HTML | 브라우저에서 읽는 문서 공유 | 표 너비·한글·외부 링크 |
| 페이지 단위 배포와 인쇄 | 잘린 표·페이지 나눔·머리글과 여백 |
11자동 저장 없이도 작업 내용을 잃지 않는 순서
툴킷은 문서 내용을 서버나 브라우저 저장 공간에 자동 보관하지 않습니다. 현재 탭에서 처리하는 방식이므로 새로고침, 페이지 이동이나 탭 종료로 작업이 사라질 수 있습니다. 편집한 내용이 있으면 브라우저가 종료 경고를 표시할 수 있지만 모든 이동이나 기기 종료를 막아주는 것은 아닙니다. 특히 휴대전화에서 다른 앱을 오래 쓰거나 브라우저가 탭을 정리하는 상황까지 경고로 보호할 수 있다고 가정하지 마세요.
작업을 시작할 때 파일 이름을 먼저 정하고 한 항목을 마칠 때마다 MD를 다운로드하는 습관을 권합니다. 예를 들어 meeting-2026-10-04.md처럼 주제와 날짜를 넣으면 다운로드 목록에서 찾기 쉽습니다. 내용이 크게 바뀌는 검토 단계에는 별도 버전을 보관하세요. 파일을 자주 저장하는 것과 사본을 끝없이 늘리는 것은 다르므로, 어느 폴더의 어느 파일이 현재 원문인지 스스로 정해두는 것이 중요합니다.
다운로드 버튼을 누른 뒤에는 브라우저의 다운로드 목록이나 저장 폴더를 확인하세요. 툴킷의 안내는 다운로드를 요청했다는 뜻이며 사용자의 기기에 파일이 저장되었는지 직접 확인하는 기능은 아닙니다. 저장 위치를 묻는 창을 취소했거나 브라우저 정책이 다운로드를 막을 수도 있습니다. 중요한 수정이라면 저장한 MD를 다시 열어 마지막 문장과 변경 항목을 확인한 뒤 원래 작업 탭을 닫으세요.
검토 전후를 비교할 필요가 있으면 수정 전 MD와 수정 후 MD를 각각 보관하고 텍스트 비교 도구에 원문을 넣어보세요. 화면의 모양이 비슷해도 링크 주소나 체크 상태가 달라졌을 수 있습니다. 비교할 때는 자동 줄바꿈처럼 화면에만 적용되는 설정과 실제 줄바꿈 문자를 구분하세요. 임시로 복사한 내용은 다른 것을 복사하면 사라질 수 있으므로 클립보드를 유일한 보관 장소로 쓰지 않는 편이 좋습니다.
12이미지·HTML 제한과 문서 처리 범위 이해하기
문서에 외부 이미지 주소가 있으면 일반적인 뷰어는 해당 서버에서 이미지를 가져올 수 있습니다. 툴킷은 파일을 여는 것만으로 그런 요청이 생기지 않도록 이미지 대신 설명을 표시합니다. 그림이 꼭 필요한 문서라면 이 제한을 이해하고 사용하세요. 원문과 MD 저장본에는 이미지 문법이 남아 있으므로 다른 편집기로 옮겼을 때는 그 편집기의 설정에 따라 이미지가 불러와질 수 있습니다. 이곳에서 보이지 않았다는 이유로 원문에서 주소가 삭제되었다고 생각하면 안 됩니다.
HTML 태그도 같은 맥락에서 지원 범위를 구분해야 합니다. 어떤 마크다운 서비스는 HTML을 함께 허용하지만 툴킷 미리보기는 원시 HTML을 표시하거나 실행하지 않습니다. 외부 스크립트, 삽입 프레임, 사용자 지정 스타일을 넣어도 웹페이지 제작 환경처럼 동작하지 않습니다. JavaScript가 포함된 MDX나 Mermaid 다이어그램, 별도의 수식 확장도 실행하지 않습니다. 이런 기능이 꼭 필요한 프로젝트는 해당 형식을 지원하는 전용 환경에서 최종 결과를 확인해야 합니다.
파일 내용과 파일 이름은 도구 이용 통계에 넣지 않습니다. 다만 사이트 방문이나 다운로드 버튼 사용 여부 같은 통계는 문서 내용과 별도로 측정될 수 있습니다. 브라우저 안에서 문서를 처리한다는 설명을 인터넷 연결이 전혀 없거나 사이트의 모든 요청이 사라진다는 뜻으로 받아들이지는 마세요. 앱을 불러오기 위한 요청과 방문 통계, 사용자가 직접 누른 외부 링크는 문서 파일을 서버에 제출하는 동작과 구분됩니다.
공유하기 전에는 본문에 불필요한 개인정보나 내부 경로가 남아 있는지 작성자가 직접 확인해야 합니다. 뷰어의 제한은 문서 내용 자체를 검열하거나 비밀을 자동으로 지워주는 기능이 아닙니다. 특히 MD는 일반 텍스트이므로 원문에 남은 주석이나 이미지 주소도 파일을 받은 사람이 읽을 수 있습니다. 공개용 문서가 필요하면 원본을 별도로 보관하고 배포용 사본에서 공개할 내용만 남기는 순서로 준비하세요.
13문서가 예상과 다를 때 확인할 순서
미리보기가 예상과 다르면 전체 문서를 지우기보다 문제 구간을 좁혀보세요. 제목이 일반 문장으로 보이면 # 앞뒤의 위치와 공백을, 굵게 표시가 이어지면 여닫는 별표 개수를 살펴봅니다. 코드 블록 뒤의 본문이 모두 코드처럼 보일 때는 닫는 백틱을 빠뜨렸는지 확인하세요. 문제 구간의 앞부분에서 문법이 시작되어 뒤 문장까지 영향을 주는 경우가 있으므로 이상한 줄 바로 앞도 함께 읽는 것이 좋습니다.
표가 한 줄의 문자처럼 보이면 제목 행 다음의 구분 행을 확인하세요. 줄마다 칸의 개수가 비슷한지, 문장 속 세로 막대가 뜻하지 않게 칸을 나누지는 않았는지도 살펴봅니다. 목록의 들여쓰기가 달라졌다면 복사한 내용에 탭과 여러 공백이 섞였을 수 있습니다. 불필요한 공백을 한꺼번에 지우면 필요한 들여쓰기까지 바뀔 수 있으니 원본 사본을 만든 뒤 짧은 구간부터 수정하세요.
다른 서비스에 붙여 넣었을 때 모양이 바뀌는 것은 반드시 이 편집기의 오류라는 뜻은 아닙니다. 서비스마다 지원하는 확장 문법, 글꼴, 표 너비와 줄바꿈 규칙이 다를 수 있습니다. 여기서 잘 보이는 체크리스트나 각주도 전달 대상 환경에서 다시 확인하세요. 제출할 곳이 정해져 있다면 그 환경에서 지원하는 최소 문법으로 작성하는 편이 예측하기 쉽습니다. 픽셀 단위의 같은 모양이 필요하면 PDF 사본을 함께 제공하는 방법을 고려할 수 있습니다.
마지막 검토에서는 문법뿐 아니라 내용의 유효성을 확인합니다. 날짜와 요일이 맞는지, 담당자가 실제로 정해졌는지, 링크 제목과 목적지가 맞는지, 예시 값이 남아 있지 않은지 읽어보세요. 코드 블록의 명령이나 문서의 주장까지 뷰어가 검증하는 것은 아닙니다. 문서가 보기 좋게 표시되는 단계와 정보가 정확한 단계는 따로 확인해야 합니다. 그런 다음 최신 MD를 저장하고 필요한 형식으로 사본을 만든 뒤 받는 사람의 환경에서 열어볼 수 있는지 점검하면 작업을 마칠 수 있습니다.
자주 묻는 질문
마크다운을 처음 쓰는데 개발 지식이 필요한가요?
회의록이나 체크리스트를 작성하는 데 개발 지식이 필요한 것은 아닙니다. 제목, 문단, 목록부터 시작해도 충분합니다. 툴킷 예제에서 문장을 바꾸고 미리보기에서 결과를 확인해보세요. 복잡한 문법을 모두 익히기보다 독자가 찾을 정보의 순서를 정하는 것이 먼저입니다.
워드 파일이나 PDF를 MD로 변환할 수 있나요?
이 편집기는 MD 원문을 열고 수정하는 도구이며 워드·PDF 자동 변환을 제공하지 않습니다. 필요한 글을 복사해 붙여 넣은 뒤 제목과 목록을 다시 정리할 수는 있습니다. PDF에서 복사한 문장에는 불필요한 줄바꿈이 섞일 수 있고, 표·이미지·페이지 서식이 그대로 유지되지는 않습니다.
GitHub README와 똑같이 보이나요?
GFM의 표·취소선·작업 목록 등은 지원하지만 GitHub 사이트 전체의 표시 기능을 재현하지는 않습니다. 상대 경로 이미지, 제목 링크, 저장소 전용 기능과 스타일은 달라질 수 있습니다. README를 배포할 예정이라면 최종적으로 해당 저장소의 미리보기에서 다시 확인하세요.
미리보기 글자 크기가 다운로드 파일에도 적용되나요?
글자 크기 설정은 편집 화면과 미리보기의 읽기 편의를 위한 옵션입니다. MD에는 글자 크기 정보가 들어가지 않고 HTML·인쇄에는 읽기용 기본 스타일이 적용됩니다. PDF의 크기와 여백은 인쇄 창의 용지·배율 설정에서 확인하세요.
원본 파일을 열고 수정하면 원본이 바뀌나요?
파일을 읽기만 하며 원본을 자동으로 덮어쓰지 않습니다. 수정한 내용을 MD로 다운로드해야 새 파일이 생깁니다. 저장이 끝난 뒤 그 파일을 다시 열어 수정 내용을 확인하세요. 같은 이름의 파일이 여러 개라면 생성 시각과 마지막 수정 문장을 보고 최신본을 구분하는 것이 좋습니다.
인터넷 없이도 사용할 수 있나요?
문서 변환은 브라우저 안에서 하지만 사이트를 처음 여는 데는 앱 파일을 불러와야 합니다. 오프라인 설치 앱으로 제공하거나 연결이 끊긴 상황의 모든 동작을 보장하는 도구는 아닙니다. 네트워크 상황이 불안정하다면 작업 중간에 MD를 다운로드해 기기에 보관하세요.
공식 출처와 확인 기준
본문을 수정했습니다. 아래 공식 기술 문서와 툴킷의 제공 기능을 기준으로 작성했습니다. 브라우저와 원본 파일에 따라 결과가 달라질 수 있으므로 실제 결과를 확인하고 사용하세요.
- CommonMark 0.31.2 — 제목·문단·목록·코드·링크 문법 (새 탭)
- GitHub Flavored Markdown Spec — 표·작업 목록 등 확장 (새 탭)
- MDN — TextDecoder와 문자 디코딩 (새 탭)
- react-markdown — 렌더링과 보안 안내 (새 탭)