- 마크다운을 사용하면 간결하고 기억하기 쉬운 구문으로 GitHub와 Reddit에서 일반 텍스트를 빠르게 서식 지정할 수 있습니다.
- GitHub Flavored Markdown은 표, 할 일 목록, 알림, 각주 및 섹션 간 고급 탐색 기능을 추가합니다.
- 레딧은 깃허브에서 사용하는 마크다운 변형인 스누마크를 사용하는데, 스누마크는 스포일러 기능이나 이미지 처리 방식 등 몇 가지 차이점이 있습니다.
- 제목, 목록, 인용문, 코드, 링크 및 이미지를 제어하면 두 플랫폼 모두에서 모든 콘텐츠의 가독성과 효율성이 크게 향상됩니다.

GitHub에서 자주 글을 쓰거나 Reddit에서 많은 시간을 보낸다면, 마크 다운을 익히는 것은 시간을 크게 절약하고 작업을 훨씬 수월하게 만들어주는 유용한 기술 중 하나입니다. 마크다운은 매우 가벼운 마크업 언어로, 메뉴나 버튼을 복잡하게 만들 필요 없이 몇 가지 기호만 적절한 위치에 배치하면 일반 텍스트를 빠르게 서식 지정할 수 있습니다.
GitHub에서는 저장소의 README.md 파일 , 이슈, 풀 리퀘스트, 토론, 심지어 프로필까지 모든 곳에서 마크다운을 찾아볼 수 있습니다. 반면 Reddit은 GitHub의 구문을 상당 부분 계승하면서도 고유한 기능과 제약 사항을 가진 Snoomark(Reddit 스타일 마크다운)라는 변형을 사용합니다. 이제 단계별로 다양한 예제를 통해 GitHub와 Reddit에서 마크다운을 빠르고 효과적으로 사용하는 방법을 살펴보겠습니다.
마크다운이란 무엇이며, 깃허브와 레딧에서 왜 그렇게 유용한가요?
마크다운은 일반 텍스트를 쉽게 읽고 쓸 수 있도록 설계된 경량 마크업 언어 이며 , HTML로의 변환 또한 간편합니다. 실제로 마크다운을 사용하면 일반 텍스트에 몇 가지 특수 문자를 추가하여 제목, 목록, 표, 인용문, 서식이 지정된 코드, 링크 또는 이미지를 만들 수 있습니다.
GitHub에서는 GitHub Flavored Markdown(GFM)이라는 구현체를 사용합니다. GFM은 기존 구문에 표, 할 일 목록, 고급 코드 강조 표시, 색상 지원, 알림 및 일부 허용된 HTML 태그를 추가합니다. 이 모든 기능은 .md 파일과 플랫폼의 댓글 필드에 자동으로 렌더링됩니다 .
레딧은 GFM을 기반으로 한 자체 편집기인 스누마크(Snoomark)를 사용합니다. 굵게, 기울임, 제목, 목록, 인용문, 인라인 또는 블록 코드, 링크 등 기본적인 기능은 GFM과 유사하지만, 몇 가지 중요한 차이점이 있습니다 . 예를 들어, 이미지 지원은 문맥에 따라 제한적이며, 스포일러와 같은 자체적인 요소들을 추가했습니다.
이 모든 것의 장점은 단 하나의 구문으로 GitHub와 Reddit 모두에서 보기 좋은 텍스트를 작성할 수 있다는 점입니다. 각 플랫폼의 작동 방식이 다른 몇 가지 세부 사항만 조정하면 되죠. 기본 규칙만 익히면 처음부터 다시 배울 필요 없이 두 플랫폼을 모두 쉽게 이용할 수 있습니다.
제목 및 내용 구조
GitHub와 Reddit 모두에서 가장 먼저 사용하게 될 기능 중 하나는 제목 입니다 . 제목은 텍스트를 섹션과 하위 섹션으로 구조화하는 데 도움이 됩니다.
마크다운에서 제목은 텍스트 앞에 해시 기호(#)를 1개에서 6개까지 붙여 만듭니다. 1개는 레벨 1 제목, 2개는 레벨 2 제목, 이런 식으로 레벨 6까지 있습니다. 예를 들어, GitHub의 README.md 파일에는 다음과 같은 내용이 있을 수 있습니다. # 메인 제목 , ## 섹션 , ### 하위 섹션 등.
GitHub는 파일에서 두 개 이상의 제목을 발견하면 파일 상단의 "개요" 아이콘에서 접근할 수 있는 목차를 자동으로 생성합니다 . 각 제목은 해당 섹션으로 바로 이동하는 링크로 표시되므로 긴 문서를 읽을 때 매우 유용합니다.
또한 각 제목은 제목 텍스트를 기반으로 하는 URL 스니펫으로 연결할 수 있는 내부 앵커가 됩니다. GitHub는 이 스니펫을 생성하기 위해 매우 구체적인 규칙을 적용합니다. 문자를 소문자로 변환하고, 공백을 하이픈으로 바꾸고, 구두점과 서식 문자(예: 이탤릭체)를 제거하고, 불필요한 공백을 없애고, 결과가 이전 제목과 일치하는 경우 고유성을 위해 숫자 접미사 (-1, -2 등)를 추가합니다.
이를 통해 ## 샘플 섹션 과 같은 코드를 삽입 한 다음 문서의 다른 위치에서 (#sample-section) 과 같은 링크를 사용하여 해당 섹션에 연결 하거나, 제목에 특수 문자가 포함된 섹션에도 연결할 수 있습니다. GitHub는 이러한 규칙에 따라 코드 조각을 생성하고 동일한 패턴으로 접근할 수 있도록 해주기 때문입니다.
강조, 강조 표시된 텍스트 및 인용문
마크다운은 굵게, 기울임, 취소선, 아래첨자, 위첨자, 밑줄 등 다양한 강조 표시를 사용할 수 있게 해줍니다 . GitHub에서 일반적으로 사용하는 스타일 표는 다음과 같지만, 여기서는 다른 방식으로 간략하게 설명했습니다.
텍스트를 굵게 표시하려면 별표 두 개(*) 또는 밑줄 두 개(_)로 텍스트를 감싸세요. 기울임꼴로 표시하려면 별표 하나(*) 또는 밑줄 하나(_)를 사용하세요. 취소선을 표시하려면 텍스트 양쪽에 물결표 두 개(~)를 붙이세요. 굵게와 기울임꼴을 중첩해서 사용할 수도 있고, 별표 세 개(*)를 사용하여 텍스트 전체에 굵게와 기울임꼴을 모두 적용할 수도 있습니다. 또한, 아래첨자와 위첨자를 나타내는 HTML 태그 `<b>` 와 밑줄을 나타내는 HTML 태그 `<i>` 를 사용할 수도 있습니다.
GitHub에서는 줄 시작 부분에 > 기호를 붙여 블록 인용문을 만들 수도 있습니다 . 인용된 텍스트는 왼쪽에 세로 막대가 회색으로 표시되어 눈에 잘 띕니다. 하나의 블록 인용문 안에 여러 줄을 넣을 수 있으며, > 기호를 더 추가하여 중첩 인용문도 만들 수 있습니다.
GitHub만의 고급 인용 형식 중 하나는 경고(alert) 또는 주의(admonition) 입니다 . 이는 일반적인 인용문 구문을 사용하지만, 첫 번째 줄에 경고 유형을 나타내는 특수 표시를 추가합니다. 예를 들어, 유용한 정보에는 `alert`, 유용한 팁에는 `helpful tips`, 핵심 데이터에는 `key data`, 긴급 경고에는 `urgent warnings`, 위험 또는 부정적인 결과에 대한 경고에는 `warnings of risks or negative consequences`를 지정할 수 있습니다. GitHub는 각 유형을 서로 다른 색상과 아이콘으로 표시하여 문서에서 중요한 정보를 강조하는 데 도움을 줍니다.
레딧에서도 같은 > 기호를 사용하여 간단한 인용을 지원하지만, 깃허브처럼 풍부한 핑 시스템은 없습니다. 그럼에도 불구하고, 상대방의 메시지 전체를 반복하지 않고 일부만 인용하여 답글을 달 수 있는 매우 유용한 방법입니다.
코드 강조 표시, 블록 및 색상
GitHub와 Reddit 모두 백틱(`)을 사용하여 텍스트 내 코드 조각을 강조 표시할 수 있습니다. 인라인 코드의 경우 단어나 명령어를 양쪽에 백틱 하나씩으로 묶으면 됩니다. 예를 들어 문장 내에서 ` git status`와 같은 명령어를 강조 표시하여 명령어임을 명확히 보여주는 데 유용합니다.
마크다운에서는 독립적인 코드 블록을 작성할 때 세 개의 백틱(```)을 사용합니다. 세 개의 백틱으로 한 줄을 만들고, 그 다음 코드를 여러 줄에 차례로 작성한 후, 다시 세 개의 백틱으로 마무리합니다. 깃허브에서는 첫 번째 백틱 바로 뒤에 언어를 지정하면 해당 언어에 특화된 색상과 서식을 사용한 구문 강조 표시가 적용됩니다.
GitHub는 백틱(`) 안의 색상 값을 강조 표시하는 특별한 기능도 제공합니다 . 백틱 사이에 16진수, RGB 또는 HSL 형식으로 색상을 입력하면 플랫폼에서 텍스트 옆에 작은 색상 표시기를 보여줍니다. 예를 들어, 밝은 모드의 배경색이 #ffffff이고 어두운 모드의 배경색이 #000000인 경우, 이 코드를 강조 표시하면 어떤 색상이 어떤 모드의 배경색인지 빠르게 확인할 수 있습니다.
코드와 표 표시와 관련하여 GitHub에서는 모든 주석 필드에 고정 폭 글꼴을 활성화할 수 있어 기술 문서 작업을 더 쉽게 할 수 있습니다. 브라우저나 Visual Studio Code 와 같은 편집기에서 코드 조각을 많이 편집하는 경우 이 옵션을 활성화하면 정렬과 가독성이 훨씬 일관성 있게 유지됩니다.
레딧은 백틱을 사용한 코드 블록도 지원하며, 인라인 코드와 블록 코드 모두 사용할 수 있지만, 레딧에서는 저장소 문서와 같은 긴 문서보다는 짧은 코드 조각이나 의사 코드에 더 많이 사용됩니다.
마크다운에서 링크를 만드는 것은 매우 간단합니다. 사용자에게 표시할 텍스트를 대괄호로 묶고 URL을 괄호로 묶으면 됩니다. 이 방법은 GitHub와 Reddit 모두에서 작동하며, GitHub에서는 키보드 단축키를 사용하여 더욱 편리하게 링크를 만들 수 있습니다 (예: 키 조합을 사용하여 선택한 텍스트를 빠르게 링크로 변환).
GitHub는 탐색과 관련된 몇 가지 추가 기능을 제공합니다. 첫째, 앞서 설명한 스니펫 생성 규칙을 사용하여 제목에 직접 링크할 수 있습니다 . 둘째, 저장소 내에서 상대 링크를 지원하는데, 이는 기술 문서 작성에 매우 중요합니다.
상대 링크는 현재 파일을 기준으로 계산되는 링크입니다. 예를 들어, README 파일이 프로젝트 루트에 있고 docs/CONTRIBUTING.md 파일에 링크하려면 docs/CONTRIBUTING.md와 같은 경로로 링크를 작성하면 됩니다. GitHub는 현재 브랜치에 관계없이 이 상대 링크를 올바르게 변환하여 브랜치 전환이나 저장소 복제 시 링크가 깨지지 않도록 합니다.
동일한 저장소 내의 파일 간 이동 시에는 항상 상대 경로를 사용하는 것이 좋습니다 . 절대 링크는 클론이나 포크된 저장소에서 작동하지 않을 수 있기 때문입니다. GitHub에서는 `./` 또는 `../`와 같은 표준 연산자와 프로젝트 루트를 기준으로 `/`로 시작하는 경로를 사용할 수 있습니다.
제목 외에 문서 내에 사용자 지정 앵커 포인트를 만들려면 `name` 속성을 가진 HTML 태그를 사용할 수 있습니다. 이렇게 하면 단락 중간이나 제목이 없는 텍스트 옆에 대상 지점을 배치하고 자동 생성된 제목과 동일한 구문을 사용하여 해당 지점에 링크할 수 있습니다.
GitHub의 이미지: 마크다운, HTML 및 상대 경로
GitHub에서 이미지는 일반적으로 링크와 동일한 구문을 사용하지만, 앞에 느낌표(!)를 붙여 삽입합니다. 대체 텍스트(alt)는 대괄호([]) 안에 지정하고, 이미지의 URL 또는 경로는 괄호([]) 안에 넣습니다. 이 대체 텍스트는 접근성 측면 에서 중요합니다 . 화면 낭독기가 읽는 내용이자 이미지가 로드되지 않을 경우 표시되는 내용이기 때문입니다.
이미지는 저장소 내의 파일이나 외부 URL에서 가져올 수 있습니다. GitHub는 다른 브랜치, 다른 저장소, 심지어 이슈 및 댓글에서 이미지를 업로드할 때 여러 상대 경로 패턴을 허용하며, 필요한 경우 ?raw=true 와 같은 접미사를 사용하여 파일을 직접 다운로드하도록 강제할 수 있습니다.
GitHub는 표준 Markdown 구문 외에도 HTML `<picture>` 요소를 지원합니다. 이 요소는 사용자의 테마 설정(밝은 테마 또는 어두운 테마)에 따라 변경되는 반응형 이미지를 로드하는 데 특히 유용합니다 . `prefers-color-scheme` 미디어 쿼리를 사용하면 각 모드에 대해 서로 다른 이미지 소스를 정의하고, 이 기능을 지원하지 않는 브라우저를 위한 기본 이미지를 지정할 수 있습니다.
일반적인 패턴은 내부에 포함하는 것을 포함합니다. 여러 요소 media 및 srcset 속성을 가지고 마지막으로 alt 속성과 일반 URL을 사용하면 다크 모드 사용자는 최적화된 이미지를 보고, 라이트 모드 사용자는 다른 이미지를 보게 되며, README 파일에 내용을 중복해서 작성할 필요가 없습니다.
GitHub는 마크다운 파일에서 HTML 주석을 지원하므로, 예를 들어 이미지 섹션을 업데이트하거나 나중에 새로운 예제를 추가하도록 독자에게 알리는 보이지 않는 알림을 추가할 수 있습니다.
표, 접이식 섹션 및 콘텐츠 분리
GitHub Flavored Markdown에서 가장 유용한 개선 사항 중 하나는 표 지원입니다 . 세로 막대를 사용하여 셀을 구분하고 대시(-)를 사용하여 헤더를 표시함으로써 데이터를 행과 열로 구성할 수 있습니다. 구분 기호에 콜론(:)을 사용하면 열을 오른쪽, 왼쪽 또는 가운데로 정렬할 수도 있습니다.
표는 프로그래밍 언어 목록, 사용 중인 프레임워크, 계획된 작업, 기능 비교 또는 행렬 구조가 필요한 기타 정보를 제시하는 데 매우 유용합니다. GitHub는 이러한 표를 깔끔하고 읽기 쉬운 스타일로 표시합니다.
긴 README 파일을 체계적으로 관리하려면 HTML 태그 `<details>`를 사용하여 접거나 펼칠 수 있는 섹션을 만들 수 있습니다. 이러한 섹션은 `<summary>` 태그 안에 요약을 표시하고 사용자가 필요에 따라 추가 콘텐츠를 펼치거나 접을 수 있도록 합니다 . 표나 보조 정보 블록은 사용자가 처음 봤을 때 부담감을 느끼지 않도록 `<details>` 태그 안에 넣는 것이 일반적입니다.
해당 섹션이 기본적으로 펼쳐진 상태로 표시되도록 하려면 open 속성을 추가하기만 하면 됩니다. 이 기법은 순위, 긴 목록 또는 처음 읽을 때는 필수적이지 않지만 접근하기 편리한 콘텐츠를 그룹화하는 데 매우 유용합니다.
정보를 정리하는 또 다른 간단한 도구는 가로선입니다. 세 개 이상의 점선을 그어 만드는 이 가로선은 섹션 사이를 구분하는 경계선 역할을 하여, 예를 들어 설명 섹션과 참고 자료 또는 추가 메모 섹션을 명확하게 구분할 수 있도록 해줍니다.
이러한 규칙은 문서 끝에 인용구를 삽입하는 것과 함께 사용하여 영감을 주는 문구, 알림 또는 핵심 메시지를 강조할 수 있습니다. 일반적인 예로는 프로필 README 파일의 끝에 구분선 뒤에 블록 인용구를 넣어 동기 부여 문구를 배치하는 것이 있습니다.
숨겨진 주석 및 서식 제어
GitHub에서는 `<!-- comment -->` 구문을 사용하여 Markdown 내에 HTML 주석을 삽입할 수 있습니다 . 이 주석 안에 입력한 내용은 렌더링된 콘텐츠에는 표시되지 않지만 소스 코드에는 나타나므로 내부 메모나 할 일 목록에 사용하기에 적합합니다.
예를 들어, 프로필 README 파일에 "나에 대한 정보" 섹션을 나중에 확장해야 한다거나, 더 이상 사용되지 않는 기술 표를 검토해야 한다는 등의 메모를 추가할 수 있지만, 프로필 방문자는 이 메모를 직접 볼 수 없습니다.
또 다른 유용한 기능은 일반적으로 마크다운으로 해석되는 문자를 이스케이프 처리하는 것 입니다 . 별표, 해시 기호 또는 기타 기호를 서식 없이 그대로 표시해야 하는 경우 각 기호 앞에 백슬래시를 붙이기만 하면 됩니다. 예를 들어, 이렇게 하면 목록 기호를 포함하는 표현식을 실제 목록으로 변환하지 않고도 작성할 수 있습니다.
GitHub에서 마크업 파일을 볼 때 상단의 버튼을 사용하여 렌더링된 보기와 소스 코드 보기 사이를 전환할 수 있습니다(또는 Brackets 와 같은 편집기에서 열 수도 있습니다). 마크다운 해석을 비활성화하면 특정 줄에 링크하는 것과 같은 일반적인 코드 보기 기능을 사용할 수 있는데 , 이는 README 파일이나 .md 파일의 특정 부분을 강조 표시하려는 경우에 매우 유용합니다.
마지막으로, GitHub는 댓글(이슈, PR 등)과 .md 파일에서 줄 바꿈을 다르게 처리한다는 점을 기억하세요. 댓글에서는 줄 바꿈이 그대로 적용되지만, Markdown 파일에서는 각 줄 끝에 공백 두 개, 백슬래시 또는 마침표를 추가해야 합니다. 같은 단락 내에서 이동을 강제로 적용합니다.
리스트, 중첩 리스트, 할 일 목록
목록은 GitHub와 Reddit 모두에서 Markdown에서 가장 많이 사용되는 요소 중 하나입니다. 각 목록 항목 앞에 하이픈(-), 별표(*), 또는 더하기 기호(+)를 붙이면 순서 없는 목록을 만들 수 있습니다 . 이러한 기호들은 모두 글머리 기호와 유사하게 표시됩니다.
정렬된 목록을 생성하려면 각 줄에 숫자와 마침표, 공백을 순서대로 입력하세요. 숫자의 순서가 완벽할 필요는 없지만(GitHub에서 자동으로 다시 계산해 줍니다), 소스 코드의 가독성을 높이기 위해 일관된 번호 매기기를 유지하는 것이 좋습니다.
중첩 목록은 아래 항목들을 들여쓰기하는 것만으로 간단하게 만들 수 있습니다. Sublime Text 와 같은 고정폭 글꼴 편집기에서는 부모 항목 텍스트의 첫 글자 아래에 중첩 목록 표시를 시각적으로 정렬하기만 하면 됩니다. GitHub 댓글 편집기처럼 글꼴이 고정폭이 아닌 경우에는 텍스트 앞에 있는 문자 수를 세어 그 수만큼 공백을 추가하여 들여쓰기를 해야 합니다.
공백 개수만 일정하게 유지한다면 여러 단계의 중첩 구조를 만들 수도 있습니다. 매우 복잡한 목록의 경우 이 시스템을 사용하려면 약간의 연습이 필요하지만, 익숙해지면 매우 빠르게 적용할 수 있습니다.
GitHub는 이슈, 풀 리퀘스트, 문서 관리 등에 매우 유용한 작업 목록 기능 도 제공합니다 . 이 목록은 하이픈(-)과 공백, 그리고 대괄호(공백 또는 'x' 포함) 한 쌍을 앞에 붙여 생성합니다. 대괄호 하나는 진행 중인 작업을, 다른 하나는 완료된 작업을 나타냅니다. 이러한 목록은 체크박스 형태로 표시되며, 인터페이스에서 선택하거나 선택 해제할 수 있습니다.
할 일 목록 항목의 텍스트가 괄호로 시작하는 경우, 구문 분석기에서 혼동을 피하기 위해 백슬래시(\)로 이스케이프해야 합니다. 이는 사소한 디테일이지만, "(선택 사항)" 또는 이와 유사한 표현으로 시작하는 설명을 작성할 때 중요합니다.
GitHub에서의 멘션, 참조 및 이모티콘
GitHub에서 Markdown으로 글을 쓰는 장점 중 하나는 플랫폼에서 사용자나 팀을 직접 멘션할 수 있다는 점입니다 . 간단히 @ 뒤에 사용자 이름이나 팀 이름을 입력하면 GitHub에서 해당 계정으로 알림을 보내 대화를 알릴 수 있습니다.
@ 기호를 입력하면 GitHub에서 해당 저장소 또는 스레드와 연결된 사용자 및 팀 목록을 표시하며, 입력하는 동안 목록을 필터링할 수 있습니다. 화살표 키를 사용하고 Enter 또는 Tab 키를 눌러 제안을 수락하세요. 팀의 경우 @조직/팀 이름 형식을 사용하면 모든 팀 구성원이 해당 스레드를 구독하게 됩니다.
멘션 기능 외에도 GitHub에서는 # 뒤에 숫자나 제목의 일부를 입력하기만 하면 이슈와 풀 리퀘스트를 쉽게 참조할 수 있습니다 . 그러면 추천 결과 목록이 표시되고, 멘션과 같은 방식으로 내용을 입력할 수 있습니다. 이 기능을 통해 관련 대화 간 이동 속도가 크게 향상됩니다.
저장소에 사용자 지정 자동 링크 참조가 구성되어 있는 경우 특정 외부 표기법(예: JIRA 또는 Zendesk 티켓 ID)도 자동으로 단축 링크로 변환될 수 있습니다. 이 설정에는 관리자 권한이 필요하지만, 활성화되면 최소한의 노력으로 시스템 간 데이터 공유가 가능해집니다.
마지막으로, GitHub는 코드를 통해 이모티콘을 지원합니다. 콜론(:)을 입력하고 이모티콘 이름을 입력한 다음 다시 콜론(:)을 입력하세요. 입력을 시작하면 추천 이모티콘 목록이 나타나는데, Tab 키나 Enter 키를 눌러 선택할 수 있습니다. 이모티콘을 댓글에 활용하면 좀 더 인간적인 느낌을 줄 수 있지만, 공식 문서에서 과도하게 사용하지 않도록 주의해야 합니다.
각주 및 고급 콘텐츠
GitHub는 대괄호 기반 구문과 캐럿 문자(^)를 식별자로 사용하는 각주 기능 도 지원합니다 . 참조를 표시하려는 위치에 `<footnote>`와 같은 태그를 삽입하고, 문서 끝부분에 동일한 태그 뒤에 콜론(:)과 각주 내용을 입력하여 각주 텍스트를 정의합니다.
각주는 여러 줄에 걸쳐 작성할 수 있으며, 각주 내에서 줄 바꿈을 강제하려면 마크다운 본문과 마찬가지로 줄 끝에 두 칸 띄어쓰기를 사용합니다. GitHub는 렌더링 시 텍스트 위에 위첨자를 표시하고 각주 목록을 끝에 표시하며, 참조와 각주 사이를 이동할 수 있는 백링크를 제공합니다.
GitHub에서 제공하는 또 다른 고급 기능은 앞서 언급한 알림 (NOTE, TIP, IMPORTANT, WARNING, CAUTION)입니다. 이러한 알림은 정말 필요한 경우에만 사용하고, 독자가 부담을 느끼지 않도록 너무 많이 연달아 사용하지 않는 것이 좋습니다. 또한 다른 복잡한 요소 안에 중첩될 수 없으므로 배치에 신중을 기해야 합니다.
마지막으로, GitHub에 렌더링된 마크다운의 일부를 HTML 주석으로 감싸서 일시적으로 숨기거나, 백슬래시를 사용한 특정 문자의 처리를 무시하도록 요청할 수 있습니다. 이는 특히 마크다운 구문 자체를 문서화 하고 해석 없이 예시를 그대로 보여줘야 할 때 유용합니다.
레딧의 마크다운: 스누마크 및 편집 모드
레딧은 거의 모든 주제를 자유롭게 토론할 수 있는 서브레딧 기반의 토론 플랫폼입니다. 레딧은 서식 편집기 두 가지를 제공하는데, 하나는 시각적인 효과를 강조하는 서식 있는 텍스트 편집기이고, 다른 하나는 마크다운 기반의 일반 텍스트 편집기입니다. 빠르게 작업하면서 결과물을 세밀하게 제어하고 싶다면 마크다운 편집기를 사용하는 것이 좋습니다.
기본적으로 레딧은 서식 있는 텍스트 편집기를 활성화하므로, 마크업 모드로 전환하려면 게시물이나 댓글의 텍스트 상자 안에 있는 '마크다운 모드' 옵션을 클릭해야 합니다 . 그러면 스누마크 구문을 직접 사용할 수 있습니다.
마크다운 편집기가 항상 로드되도록 하려면 사용자 설정으로 이동하여 피드 설정 섹션에서 "기본값 마크다운" 옵션을 활성화하세요 . 이렇게 하면 게시글이나 댓글을 작성할 때마다 마크다운 편집기가 자동으로 열리므로 수동으로 변경할 필요가 없습니다.
레딧은 제목, 굵게 및 기울임꼴, 목록, 인용문, 코드 블록, 링크 등 대부분의 기본 및 고급 마크다운 기능을 지원하며, 스포일러와 같은 자체적인 추가 기능도 제공합니다. 그러나 특히 이미지 처리 측면 에서 GitHub에 비해 상당한 단점이 있는데, 이는 맥락과 사용하는 편집기 종류에 따라 크게 달라지기 때문입니다.
레딧에서 지원하는 구문 및 스포일러
레딧에서 사용하는 스누마크(Snoomark) 변형은 깃허브(GitHub)와 공통점이 많기 때문에, 저장소 관리에 마크다운(Markdown)을 이미 능숙하게 사용한다면 레딧 환경에 그 지식을 적용하는 것은 매우 간단합니다. 제목을 사용하여 긴 게시글의 구조를 잡고, 번호 매기기나 글머리 기호 목록을 사용하고, 인용문을 사용하여 다른 사용자에게 답글을 달고, 코드 블록을 사용하여 명령어나 기술적인 코드를 표시할 수 있습니다.
주목할 만한 차이점 중 하나는 레딧에서 이미지를 처리하는 방식입니다 . 많은 경우 이미지는 마크다운 구문을 직접 사용하는 것이 아니라 그래픽 인터페이스를 통해 업로드되지만, 텍스트 콘텐츠를 처리하는 엔진은 여전히 스누마크(Snoomark)이므로 이미지 주변의 서식은 실제로 마크다운을 기반으로 합니다.
반면 레딧은 표준 사양에 포함되지 않은 스포일러와 같은 추가 기능을 제공합니다 . 스포일러를 사용하면 텍스트를 레이어 뒤에 숨길 수 있으며, 사용자는 클릭하여 내용을 드러낼 수 있습니다. 기술적으로 레딧은 스포일러를 처리할 때 HTML, CSS 클래스 및 플랫폼별 자바스크립트의 조합으로 변환합니다.
스포일러를 HTML로 표현하면 콘텐츠를 표시하거나 숨길 시점을 제어하는 핸들러가 포함됩니다. 이론적으로는 일반 HTML로도 비슷한 기능을 구현할 수 있지만, 레딧에서는 자체적인 내부 구현 방식에 따라 달라집니다. 사용자 입장에서 중요한 것은 글을 작성할 때 에디터에서 제공하는 특정 스포일러 구문만 사용하면 되고, 스누마크가 이를 적절한 구조로 변환해 준다는 점입니다.
요약하자면, Snoomark는 GitHub Flavored Markdown의 여러 기능을 계승하지만, 프로젝트 문서보다는 토론 커뮤니티의 요구 사항에 맞춰 설계되었습니다. 그럼에도 불구하고 핵심은 동일합니다. 일반 텍스트와 간단한 기호를 구조화되고 읽기 쉬운 콘텐츠로 변환하는 것입니다.
GitHub와 Reddit에서 마크다운 구문을 익히면 기술 문서 작성, 잘 설명된 이슈 제기, 풀 리퀘스트에 명확한 댓글 남기기, Reddit 토론 참여 등이 훨씬 효율적으로 이루어집니다. 제목, 강조, 목록, 인용문, 코드 블록, 링크, 이미지 등의 몇 가지 핵심 규칙과 표, 접을 수 있는 세부 정보, 알림, 각주, 스포일러와 같은 유용한 기능들을 활용하면 마우스 클릭 한 번 없이도 밋밋한 글에서 깔끔하고 읽기 쉬우며 전문적인 콘텐츠 로 전환할 수 있습니다.
