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

Output format requirements:

• Include YAML front matter with:
  • layout: post
  • title (YAML-safe scalar; if it contains : then wrap with double 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 (if it contains : then wrap with double quotes)
• Body must be valid Markdown with clear H2/H3 sections.
• Body must start with:
  • - Table of Contents
  • {:toc .large-only}
• Hard minimum: body length must be at least 2400 characters.
• Target length: aim for around characters (±10%).
• Hard maximum: body length must not exceed 9800 characters.
• Length policy: prioritize depth within the target band; do not pad with repetitive paraphrases.

Required content structure:

• Core sections must be present (heading text can vary by context, but keep validator keywords):
  • ## 요약 (2-4 bullets, 독자가 바로 얻는 결과 중심)
  • ## 배경/문제 (실무 맥락, 제약, 실패 신호)
  • ## 접근/해결 전략 (선택 이유와 의사결정 기준)
  • ## 구현 포인트 (핵심 코드/설정/명령어/파일 경로)
  • ## 검증 (Before/After, 성공 판정 기준, 회귀 체크)
  • ## 대안 비교/트레이드오프 또는 ## 주의사항/트레이드오프 (최소 2개 대안과 선택 기준)
  • ## 마무리 (체크리스트 + 적용 제외 케이스)
• Do not force identical heading names every time. Keep the required intent, but adapt phrasing to the source.
• If the source contains meaningful diagrams, screenshots, or charts, keep them in the output near the relevant explanation. Do not delete source images just to shorten the draft.

Section density rules:

• 각 핵심 섹션은 가능한 한 구체 문단 중심으로 작성.
• 요약 섹션은 bullet 중심으로 작성하되, 나머지 주요 H2 섹션은 설명 문단을 우선 확보.
• 요약을 제외한 각 주요 H2 섹션은 최소 2개 이상의 설명 문단을 확보하고, 가능하면 “개념/원리”와 “실무 적용/판단”을 분리해서 쓸 것.
• 증상 재현, 접근/해결 전략(또는 구현 포인트), 검증 섹션에는 각각 최소 1개의 fenced code block 또는 command block을 포함.
• 모든 코드 예시는 fenced code block으로 작성하고, 언어 식별자(java`,javascript, ```bash` 등)를 반드시 지정.
• 여러 statement를 한 줄에 압축하지 말고, 들여쓰기/줄바꿈을 유지한 multi-line 형태로 작성.
• 긴 코드 예시를 본문 문장(plain text)으로 붙여 넣지 말 것. 긴 예시는 코드 블록으로만 제시.
• 코드 블록은 핵심 발췌 위주로 유지(긴 코드를 통째로 붙이지 말고 핵심 구간만 제시).
• 코드/표가 과도하게 길어져 설명 본문이 약해지지 않도록, 왜/언제/주의점 설명 문단을 충분히 확보.
• 대안 비교 섹션이 있으면 표를 우선 고려하되, 소스 특성상 표가 부자연스러우면 bullet 비교로 대체 가능.
• 각 주요 섹션은 최소 1개의 evidence anchor(에러 메시지, 설정 키, 명령어, 코드 조각, 파일 경로, 로그 문구)를 포함.
• source가 짧더라도 분량을 억지 요약하지 말고, 아래 확장 요소를 문서 근거와 연결해 전문 블로그 수준으로 보강:
  • 핵심 개념의 내부 동작 원리
  • 실무에서 자주 겪는 실패 시나리오와 재현 조건
  • 대안 접근 2개 이상과 선택 기준
  • 운영 체크리스트/디버깅 체크리스트
• 원문이 메모/요약/체크리스트 형태라면, 그대로 재진술하지 말고 아래 순서로 독자 관점의 설명으로 재구성:
  • 이 항목이 왜 문제였는지
  • 어떤 신호로 문제를 인지하는지
  • 왜 이 접근을 선택했는지
  • 적용 시 어디서 깨질 수 있는지
  • 검증 시 무엇을 확인해야 하는지
• 원문 bullet 하나를 output bullet 하나로 1:1 매핑하지 말 것. 각 핵심 bullet은 설명 문단, 예시, 검증 기준으로 확장해서 녹여 쓸 것.
• 원문이 특정 코드/설정/로그를 짧게 언급하면, output에서는 “맥락 -> 해석 -> 적용 포인트 -> 주의점”까지 풀어서 설명할 것.
• 위 확장 요소는 반드시 원문의 핵심 포인트와 연결해서 작성하고, 같은 의미의 반복 문장으로 분량을 채우지 말 것.

Persona and tone execution rules:

• Write like an engineer’s field note: concise, concrete, and accountable.
• Prefer “문제 -> 판단 -> 적용 -> 검증” 흐름을 문단 단위로 보여줄 것.
• Use first-person phrasing sparingly only if source implies direct experience; never invent personal anecdotes.
• Avoid repetitive opener patterns (e.g., every paragraph starting with “먼저”, “또한”, “그리고”).
• Avoid generic closing lines; end sections with practical criteria or next action.

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.
• Evidence-first writing: each major section should contain at least one source-grounded anchor (e.g., 에러 메시지, 설정 키, 명령어, 코드 조각, 파일 경로, 로그 문구).
• Treat the source as evidence and outline material, not as the final article shape. The output should read like a finished technical post, not a cleaned-up meeting memo.

Fact and augmentation rules (strict):

• Source-grounded facts are mandatory baseline.
• You may add only stable, widely accepted technical fundamentals.
• Add relevant adjacent knowledge when useful (architecture rationale, debugging heuristics, operational safeguards), but tie it back to source context and keep it non-speculative.
• When adding adjacent knowledge, prefer explanation that increases reader comprehension:
  • define the moving part
  • explain why it behaves that way
  • clarify when the same fix does not apply
  • state the practical decision rule the reader can reuse
• 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.
• Exclude internal bookkeeping sections from output even if present in source:
  • 관련 파일, 파일 목록
  • 변경 이력, 커밋 이력, commit hash lists
• If needed for understanding, summarize only the technical implication in prose without table-style inventories.

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).
• Keep front matter YAML-parseable; quote scalar values when needed.
• Do not include any explanation outside the final Markdown document.
• Before finalizing, check whether a reader who has not seen the source can still understand the problem, the reasoning, and the verification steps. If not, expand the missing explanation instead of shortening.

Source: