Rewrite the following source Markdown into a publishable Jekyll tech blog post for 초급~중급 개발자.

Output format requirements:

• Include YAML front matter with:
  • layout: post
  • title (no surrounding quotes)
  • date: YYYY-MM-DD HH:MM:SS +0900
  • categories: [, ] (exactly 2 items, both usable as `_posts` subdirectory path)
  • tags: 3 to 8 items
  • description: one-sentence summary (no surrounding quotes)
• Body must be valid Markdown with clear H2/H3 sections.
• Body must start with:
  • - Table of Contents
  • {:toc .large-only}
• Target body length (excluding front matter): at least around `` characters.
• `` is a quality floor, not a hard upper bound. If needed to preserve source details, write longer.

Required content structure:

• 시작: ## 요약 (2-4 bullets, 학습 포인트 중심)
• 본문 섹션 (H2/H3):
  • 배경/문제
  • 접근/해결 전략
  • 구현 포인트 (가능하면 코드/설정/명령어/파일 경로 예시)
  • 주의사항/트레이드오프 (보안, 성능, 유지보수 관점)
  • 마무리 (체크리스트 또는 핵심 정리)

Section density rules:

• ## 요약은 가능하면 3개 이상 bullet을 작성.
• 각 필수 섹션은 최소 1개 이상의 구체 문단을 작성.
• 주의사항/트레이드오프 섹션은 최소 2개 이상의 항목(문단 또는 bullet) 포함.
• source에 코드가 있으면 구현 포인트에 최소 1개의 fenced code block을 포함.

Content preservation rules (strict):

• Keep all major source points: 원인, 증상, 해결 절차, 예외 케이스, 트레이드오프, 결론.
• Do not drop unique examples, failure scenarios, or decision criteria that appear in source.
• Preserve concrete artifacts when present: error messages, commands, config keys, code snippets, file paths.
• If source has multiple meaningful sections/headings, ensure each is represented in output headings or paragraphs.
• Compression should remove duplication only; never remove technically meaningful points.

Fact and augmentation rules (strict):

• Source-grounded facts are mandatory baseline.
• You may add only stable, widely accepted technical fundamentals.
• Never add:
  • version-specific claims not in source
  • measured numbers/benchmarks not in source
  • organization-specific internals not in source
  • unverifiable security claims
• If uncertain, either omit or label explicitly as 가정.

De-identification rules (strict):

• Mask or generalize all sensitive/identifying data, including:
  • keys/tokens/passwords/secrets
  • project/service/company/person-specific names
  • internal URLs/domains/IPs/emails/account identifiers
• Replace with neutral placeholders, for example:
  • <REDACTED_TOKEN>, project-a, service-b, https://example.com
• Preserve technical intent while removing identifiable details.

Link and markdown hygiene:

• Remove local-only links (Obsidian links, local file paths) and broken/empty links.
• Keep valid web links (http/https) only.
• Keep code fences balanced.
• When removing a non-web link, preserve surrounding explanation text (or link label) so meaning is not lost.

Final constraints:

• Return raw Markdown only (no outer code fences like ```markdown).
• Prefer unquoted front matter values unless unavoidable.
• Do not include any explanation outside the final Markdown document.

Source: