마크다운의 불편한 진실, 이제 그만!
마크다운(Markdown)은 단순한 텍스트 포맷팅을 넘어선 복잡한 요구사항을 처리하기에 설계가 부적절함을 지적함
인라인 HTML 삽입과 같은 기능은 마크다운의 단순성을 해치고 보안 취약점(Cross-site Scripting)을 야기한다고 비판함
마크다운의 모호한 문법과 파싱 규칙은 예측 불가능한 렌더링 결과를 초래하며, 이는 개발 생산성 저하로 이어진다고 주장함
대안으로 더 나은 빌트인 기능과 명확한 문법을 갖춘 언어의 필요성을 강조하며, 마크다운의 한계를 명확히 함
마크다운의 근본적인 설계 결함: 단순함을 넘어서
발표자는 마크다운이 단순한 텍스트 포맷팅(Plain text formatting)을 위해 설계되었으나, 현대 개발 환경에서 요구되는 복잡한 구조와 기능(Complex requirements)을 처리하기에는 근본적인 한계가 있다고 지적함. 특히, 인라인 HTML 삽입(Inline HTML insertion)은 마크다운의 단순성을 훼손하고, 크로스 사이트 스크립팅(XSS)과 같은 보안 취약점을 유발하는 주요 원인으로 꼽힘. 이는 마크다운이 본래 의도했던 보안성(Security)과 단순성(Simplicity)을 저해하는 요소로 작용한다고 설명함.
모호한 문법과 예측 불가능한 렌더링의 문제
영상에서는 마크다운의 문법적 모호성(Syntactic ambiguity)이 예측 불가능한 렌더링 결과(Unpredictable rendering results)를 초래한다고 비판함. 예를 들어, 볼드(Bold) 표기법만 해도 여러 방식으로 구현 가능하며, 이는 파서(Parser)마다 다른 결과를 만들어내 개발자들의 혼란을 가중시킴. 이러한 일관성 부족(Lack of consistency)은 마크다운을 신뢰할 수 없는(Unreliable) 도구로 만들며, 코드 리뷰 및 협업 과정에서 불필요한 마찰을 일으킨다고 주장함.
마크다운의 한계: 빌드 시스템 부재와 확장성의 어려움
발표자는 마크다운이 빌드 시스템(Build system)을 갖추지 못했기 때문에, 코드 컴파일, 테스트 자동화, 의존성 관리 등 현대적인 개발 워크플로우에 통합되기 어렵다고 지적함. 또한, 인라인 HTML, CSS, JavaScript 등을 삽입하는 방식은 마크다운의 확장성(Extensibility)을 제한하고, 코드 스니펫(Code snippets)이나 수식(Formulas)과 같은 복잡한 콘텐츠를 표현하는 데에도 한계를 보인다고 설명함. 이는 마크다운이 단순한 문서 작성 도구 이상으로 발전하기 어려운 이유를 보여줌.
마크다운의 대안: 명확한 문법과 풍부한 기능을 갖춘 언어
영상에서는 마크다운의 문제점을 해결하기 위해 더 명확한 문법(Clearer syntax)과 풍부한 기능(Richer features)을 제공하는 대안을 제시함. 예를 들어, reStructuredText나 AsciiDoc과 같은 언어는 더 나은 구조화(Better structuring), 참조 관리(Reference management), 확장성(Extensibility)을 제공한다고 언급됨. 또한, 노션(Notion)과 같이 마크다운 문법을 차용하면서도 내부적으로는 더 강력한 기능을 제공하는 도구의 사례를 통해, 마크다운 자체의 한계를 우회하는 방안도 제시함.
마크다운의 '프로그래밍 언어'로서의 부적절성
발표자는 마크다운이 튜링 완전성(Turing completeness)을 갖추지 못했기 때문에 엄밀히 말해 프로그래밍 언어(Programming language)로 분류될 수 없다고 주장함. 마크다운은 주로 텍스트 렌더링(Text rendering)에 초점을 맞추며, 로직 구현(Logic implementation)이나 복잡한 데이터 처리(Complex data processing)에는 부적합하다고 설명함. 이는 마크다운을 프로그래밍 언어의 범주에 넣고 비교하는 것 자체가 잘못되었음을 시사하며, 마크다운의 본질적인 용도에 대한 재고를 촉구함.