Hacker News 의견들

• 글이 잘 쓰였음. 하지만 내가 Markdown을 좋아하는 가장 큰 이유는 그게 근본적으로 텍스트 기반이라는 점임
  포맷이나 벤더 종속이 없고 git 저장소에 넣기에도 완벽함. OneNote 같은 포맷이 2035년에 여전히 열릴지 걱정할 필요가 없음
  또 LLM들이 기본적으로 Markdown을 이해한다는 점도 좋음. 서버 코드에서 API 문서를 만들어 달라고 하면, 텍스트 기반 요약을 원한다는 걸 바로 알아들음

  • Markdown은 원래 사람들이 텍스트 파일에서 쓰던 관습을 공식화한 것임. 나도 평소에 텍스트로 문서를 쓰다가, 나중에 보니 이미 Markdown 문법을 쓰고 있었음. 그래서 확장자를 .md로 바꾸고 약간 수정하면 보기 좋게 변함
  • 물론 AsciiDoc이나 reStructuredText 같은 더 나은 포맷도 있음. 하지만 결국 Markdown을 써야 하는 곳이 많아서 그냥 충분히 괜찮은 선택으로 남음
  • Markdown은 본질적으로 그럭저럭 보기 좋은 텍스트임. 표를 지원하지 않는 이유도 여기에 있음. 아무리 문법을 잘 만들어도 순수 텍스트로 표를 예쁘게 표현하기는 어려움
  • 나도 같은 이유로 텍스트를 선호하게 됨. 지금 The UNIX Programming Environment (1984) 를 읽고 있는데, 이 책 덕분에 텍스트 기반 형식의 영속성을 다시 느끼고 있음
  • 그래서 Obsidian을 좋아함. 마치 Markdown을 위한 운영체제 같음

• 예전에 Google Docs에 Markdown 지원 기능을 20% 프로젝트로 추가했음. Markdown 역사에 이름이 언급돼서 영광스러움

  • 그 기능 덕분에 Google Docs가 훨씬 즐거워졌음. 특히 alt+/ 단축키와 함께 쓰면 정말 편함
  • 빠르게 문서를 만들어 공유할 때 큰 도움이 됨
  • 거의 매일 쓰고 있음. 고마움!

• HTML을 직접 쓰는 게 어렵다기보다, Markdown의 매력은 원본 텍스트 자체가 읽기 쉬움이라는 점임
  그리고 Markdown의 ‘모양’을 커스터마이징할 수 있는 내 편집기 Kraa를 소개함

  • 예전에 Kraa를 봤는데, 다시 써보니 단어 줄바꿈이 어색하고, #을 숨겨서 헤더 스타일을 바꾸기 어렵고, 비표준 체크박스 문법([])을 써서 불편했음. UI는 멋지지만 Markdown 편집기로는 부족함
  • 제품이 좋아 보이지만 자체 호스팅 불가라 보안이 불명확함. 개인 노트라면 괜찮지만 업무용으로는 불안함. 수익화 계획이 있는지도 궁금함
  • <br>이 필요한 경우도 있음. 예를 들어 멀티라인 표 셀 같은 곳에서는 고정폭 폰트와 함께 써야 함
  • 자바스크립트를 끄면 빈 화면만 보임. 이건 좀 아쉬움

• Markdown을 정말 좋아함. 그런데 아직도 대부분의 브라우저에서 .md 파일을 바로 열 수 없다는 게 놀라움. 브라우저가 자동으로 HTML로 변환해 보여주면 좋겠음

  • 나는 Markdeep을 사용함. 문서 끝에 코드 스니펫을 추가하고 .md.html로 저장하면 브라우저에서 바로 렌더링됨. Google Drive에 저장해두고 모든 노트 앱을 대체함
  • 이 기능을 구현하려면 Markdown의 표준화가 필요함. CommonMark가 있긴 하지만 여전히 복잡하고 모호함
  • 단순히 Markdown을 보기 좋게 렌더링할 리더 앱이 거의 없다는 게 이상함. 왜 이렇게 단순한 게 없는지 모르겠음
  • 브라우저에서 “HTML로 보기” 같은 버튼으로 렌더링할 수 있게 하면 좋을 텐데, 왜 거부됐는지 궁금함
  • 또한 Markdown을 안전한 HTML로 바꾸는 기본 JS API가 없다는 것도 아쉬움

• 글에서 Jeff Atwood(스택오버플로 창립자)가 Gruber에게 Markdown 표준화를 제안했던 이야기가 빠져 있음
  Gruber는 결국 거절했지만, 자신이 하고 싶은 일을 고수한 점은 영감을 주는 사례라고 생각함

  • 실제로는 Atwood가 먼저 “Standard Markdown” 문서를 공개했고, Gruber가 이를 승인하지 않음. 이후 프로젝트 이름이 CommonMark로 바뀜. 결과적으로 단순함을 유지할 수 있었음
  • 하지만 표준 부재로 인해 여러 번 호환성 문제를 겪었음

• “모든 문맥에 맞는 맛을 가졌다”는 표현이 웃김. Markdown이 통일되지 않아 bold나 bold, italics가 헷갈림
  그래도 CommonMark가 더 널리 쓰였으면 좋겠음

  • 다른 포맷처럼 /italics/, _underline_ 같은 직관적인 표기가 더 낫다고 생각함
  • 실제로는 굵게나 기울임의 구분이 중요하지 않음. 강조만 전달되면 충분함
  • 예전엔 이런 변형이 싫었지만, 이제는 “실용적 포용성(Practical Postelism)” 으로 받아들임. 완벽한 표준보다 현실적인 다양성이 시스템 성공에 도움이 됨
  • Slack의 단일 별표 굵게 표기는 Markdown이 아님. 너무 불편해서 그냥 단축키를 외워버림

• CommonMark와 Pandoc의 제작자가 만든 새로운 포맷 Djot(djot.net)이 있음. 더 합리적이고 파싱이 쉬움

  • 하지만 한국어 사용자 입장에서는 “djot” 발음이 비속어처럼 들림
  • 사양이 명확하지 않아 새로운 구현을 만들기 어려움
  • 그래도 더 엄격하고 깔끔한 Markdown 같아서 시도해볼 예정임
  • 나는 Djot을 내 프로젝트(Moor 클라이언트)에 사용 중임. 안전하고 익숙하며 파싱이 쉬움

• Markdown의 장점은 명확함
  텍스트 기반, git 친화적, LLM 친화적, 검색 가능성이 뛰어남
  하지만 복잡한 레이아웃이나 정밀한 타이포그래피, 바이너리 임베딩은 불가능함. 다른 제약이 있는지 궁금함

  • 다단계 리스트가 깊어지면 코드 블록처럼 렌더링되는 문제가 있음. 이건 Markdown의 큰 단점임
  • CommonMark는 HTML의 상위 집합처럼 동작함. 하지만 구현마다 미묘한 차이가 많음
  • Markdown은 간단한 메모에는 좋지만, 구조화된 문서에는 부적합함. 의미론적 마크업이 없기 때문임
  • 수식, 소문자 대문자 구분, 문서 구획 등 학술적 표현이 부족함
  • 확장 문법에서는 HTML/CSS나 base64 이미지를 넣을 수 있지만, 그건 이미 Markdown의 정신에서 벗어남

• Markdown이 성공한 이유는 시기적 타이밍 덕분임
  AsciiDoc, org-mode 등은 더 구조적이지만 대중성이 부족했음.
  GitHub가 Markdown을 선택하면서 오픈소스 커뮤니티 전체가 자연스럽게 따라왔음.
  VHS와 Betamax의 경쟁처럼, 더 나은 기술이 아니라 먼저 자리 잡은 포맷이 승리한 셈임

• “까칠하지만 따뜻한 사람, 지금쯤 Kubrick 영화를 보며 말도 안 되는 팀을 응원하고 있을 것 같다”는 묘사가 인상적이었음