DongHyeonkaandClaude Opus 5
25644cc4d9
.agents/skills의 technical-document-author, revising-korean-technical-prose, writing-natural-korean을 korean-technical-blog-skills-bundle-v1의 세 스킬로 교체한다. - writing-korean-technical-blogs: 문제·제약·선택·구현·결과·한계 구조화 - reducing-ai-like-korean-writing: 상투성·추상화·반복 제거 - editing-korean-grammar-and-expression: 맞춤법·띄어쓰기·호응 검수 상류를 수정하지 않고 복사했다. diff -r 0건, MANIFEST.sha256 검증 통과, 번들 validate_skill.py 3/3 PASS. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
57 lines
1.9 KiB
Markdown
57 lines
1.9 KiB
Markdown
# 기술 블로그 구조 패턴
|
|
|
|
목차를 고정 템플릿처럼 강제하지 않는다. 독자가 따라야 할 의사결정 순서를 기준으로 프로필을 선택한다.
|
|
|
|
## 공통 골격
|
|
|
|
1. 문제 또는 관찰값
|
|
2. 왜 지금 해결해야 했는지
|
|
3. 제약과 성공 기준
|
|
4. 검토한 대안과 선택 이유
|
|
5. 구현·실험 또는 운영 방식
|
|
6. 검증 방법과 결과
|
|
7. 비용·한계·실패 조건
|
|
8. 남은 과제와 적용 조건
|
|
|
|
자료가 없는 섹션은 만들지 않는다. 결과가 핵심이면 도입부에서 먼저 보여 주고 뒤에서 측정 방법을 설명한다.
|
|
|
|
## 도입
|
|
|
|
첫 15% 안에 다음 중 필요한 내용을 드러낸다.
|
|
|
|
- 어떤 시스템이나 작업을 다루는지
|
|
- 실제 문제 또는 관찰값
|
|
- 독자가 얻을 수 있는 정보
|
|
- 핵심 결과와 측정 범위
|
|
|
|
피해야 할 시작은 시대 일반론, 의례적 인사, `이번 글에서는 살펴보겠습니다`뿐인 문장이다.
|
|
|
|
## 제목
|
|
|
|
제목은 대상·문제·행동·선택·결과 중 하나 이상을 담는다.
|
|
|
|
```text
|
|
나쁨: Kubernetes 배포 자동화 소개
|
|
개선: Kubernetes 배포에서 승인·롤백·상태 확인을 자동화한 방법
|
|
```
|
|
|
|
숫자를 제목에 넣을 때는 본문이 같은 측정 기준을 뒷받침해야 한다.
|
|
|
|
## 본문
|
|
|
|
- 기술 선택은 장점 목록보다 제약과 대안 비교로 설명한다.
|
|
- 실험은 환경, 입력, 지표, 전후 조건을 분리한다.
|
|
- 여러 시도는 가설·조치·결과를 각각 묶는다.
|
|
- 보이지 않는 인프라 작업은 `왜 해야 했는가`부터 설명한다.
|
|
- 구현 세부는 독자가 재현하거나 판단하는 데 필요한 수준까지만 포함한다.
|
|
|
|
## 결론
|
|
|
|
결론은 본문을 다시 요약하는 대신 다음을 선택한다.
|
|
|
|
- 실제 결과와 측정 범위
|
|
- 선택이 유효한 조건
|
|
- 남은 비용과 위험
|
|
- 실패한 가설 또는 얻은 교훈
|
|
- 다음에 측정하거나 바꿀 항목
|