You are revising an existing draft into a fuller, publishable Jekyll tech blog post for 초급~중급 개발자.

Goal:

• Improve depth and completeness while staying strictly source-grounded.
• Keep facts accurate; do not invent versions, metrics, incidents, or organization-specific details.
• If uncertain, mark as 가정 or omit.

Input:

• Source Markdown: ``
• Current Draft Markdown: ``
• 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: expand for depth, but never inflate with repetitive restatement.

Requirements:

• Preserve valid YAML front matter and Markdown structure.
• Keep front matter YAML-parseable; quote title/description when they contain :.
• Keep body start:
  • - Table of Contents
  • {:toc .large-only}
• Ensure required sections remain clear:
  • 요약
  • 배경/문제
  • 접근/해결 전략
  • 구현 포인트
  • 주의사항/트레이드오프
  • 마무리
• Expand weak/short sections with concrete implementation detail, decision rationale, and trade-offs.
• If source is short, proactively add grounded expansions:
  • 핵심 개념의 동작 원리/배경
  • 실무 장애 패턴과 예방책
  • 대체 설계 옵션과 선택 기준
  • 운영 체크리스트와 검증 절차
• Treat the source and current draft as raw material, not as the final article shape. Rewrite thin sections so a reader can understand the topic without seeing the original memo.
• Apply augmentation quality gates; if missing, revise to satisfy practical coverage:
  • 최소 1개의 실패 재현 시나리오 존재
  • 최소 1개의 성공 검증 시나리오 존재
  • 최소 2개 이상의 대안 비교와 선택 기준 존재
  • 운영 적용 팁(모니터링/롤백/보안/성능) 존재
• Keep human-like author voice during augmentation:
  • Preserve or improve the original narrative flow instead of turning sections into uniform templates.
  • Keep concrete decision context (why this option was chosen) and practical boundary conditions.
  • Use first-person phrasing only when source supports direct experience; do not invent anecdotes.
  • Reduce repeated connective phrases and repetitive list-only writing.
• Ensure each major section includes at least one source-grounded anchor (에러 메시지, 설정 키, 명령어, 코드 조각, 파일 경로, 로그 문구 등).
• 요약을 제외한 주요 H2 섹션은 최소 2개 이상의 설명 문단을 우선 확보하되, 소스 밀도가 낮으면 억지 반복으로 채우지 말 것.
• Bullet-only sections should usually be rewritten into prose + examples + verification criteria rather than kept as short lists.
• Preserve all major source points: 원인, 증상, 해결 절차, 예외 케이스, 트레이드오프, 결론.
• Do not remove unique examples, failure scenarios, or concrete artifacts from source.
• Preserve concrete artifacts when present: error messages, commands, config keys, code snippets, file paths.
• Compression should remove duplication only; do not drop technically meaningful content.
• If source contains code, include at least one fenced code block in 구현 포인트.
• 코드 예시는 fenced code block + 언어 식별자를 사용하고, 코드 라인을 한 줄로 압축하지 말 것.
• 본문 문장에 긴 코드 문자열을 섞어 쓰지 말고, 코드 표현은 코드 블록으로만 제공.
• 코드 블록은 핵심 발췌로 제한하고, 긴 원문 코드를 그대로 붙여 길이를 채우지 말 것.
• 코드/표 분량이 늘어날수록 동일 섹션의 설명 문단(판단 이유, 적용 조건, 실패 경계)을 함께 확장할 것.
• Remove or mask sensitive/identifying data.
• Remove local-only links and broken links, but preserve link labels/explanatory text.
• Remove internal bookkeeping sections/tables if present:
  • 관련 파일, 파일 목록
  • 변경 이력, 커밋 이력, commit hash lists
• Keep only externally useful technical reasoning; convert internal tracking details into brief generalized prose when necessary.
• Added expansions must remain factual and low-variance; if uncertainty exists, mark as 가정.
• Avoid filler: do not repeat the same claim with different wording just to increase length.
• Each section should end with actionable guidance: when to use this approach and when to avoid it.
• For each thin source point, try to add: failure signal, causal explanation, application boundary, and a reusable decision rule.

Output constraints:

• Return raw Markdown only.
• Do not output explanations outside the final Markdown document.