Stats
Links
Categories
토스 스타일 한국어 기술 블로그 작성을 위한 Claude Code 스킬
npx claudepluginhub exceptanyone/ko-tech-blog-skill토스 기술블로그 스타일의 한국어 기술 블로그 글을 작성하는 스킬입니다.
토스 기술블로그 스타일의 한국어 기술 블로그 글을 작성하는 Claude Code 스킬
문제 해결 경험을 공감 → 문제 → 단계적 해결 → 결과 → 배움 구조로 작성합니다.
/plugin marketplace add ExceptAnyone/ko-tech-blog-skill
/plugin install ko-tech-blog
git clone https://github.com/ExceptAnyone/ko-tech-blog-skill.git
skills/ 디렉토리에 복사합니다:cp -r ko-tech-blog-skill ~/.claude/skills/ko-tech-blog
다음 키워드로 스킬을 실행할 수 있습니다:
블로그 글 써줘
기술 블로그 포스팅 작성
이 경험을 토스 스타일로 정리해줘
문제 해결 회고 글 작성
/blog
"Next.js 이미지 최적화 경험을 블로그 글로 써줘. 토스 스타일로."
"이 초안을 토스 스타일로 다듬어줘: [초안 내용]"
"프로젝트 완료했어. 배포 프로세스 개선한 경험을 블로그 글로 정리해줘."
스킬이 다음 질문을 통해 글감을 파악합니다:
선택한 템플릿 기반으로 초안 작성:
체크리스트와 구체적인 개선점 제시
/posts/ 디렉토리에 저장skills/ko-tech-blog/
├── SKILL.md # 메인 스킬 정의
├── README.md # 이 파일
├── references/
│ ├── toss-style-guide.md # 토스 스타일 핵심 규칙
│ ├── article-structure.md # 섹션별 작성 가이드
│ └── examples/
│ ├── good-intro.md # 좋은 서론 예시 5개
│ ├── good-problem.md # 좋은 문제 정의 예시 5개
│ └── good-conclusion.md # 좋은 결론 예시 5개
└── templates/
├── problem-solving-template.md # 문제 해결형 템플릿 (주력)
├── concept-explaining-template.md # 개념 설명형 템플릿
└── basic-template.md # 기본형 템플릿
❌ "Webpack의 SplitChunksPlugin을 사용하여..."
✅ "배포할 때마다 10분씩 기다리는 건 이제 그만"
❌ "Redis를 도입했습니다."
✅ "같은 데이터를 100만 번 조회하는 문제"
Phase 1: 가장 쉬운 방법 → 문제점 발견
Phase 2: 개선 → 새로운 문제
Phase 3: 최종 해결책 → 완성
✅ "배포 시간이 10분에서 30초로 줄었어요."
✅ "팀원들이 배포를 두려워하지 않게 된 거죠."
❌ "Debounce를 적용하여..."
✅ "타이핑을 멈춘 후 0.3초 뒤에 검색하도록 한 거죠."
가장 자주 사용하는 템플릿입니다.
구조:
# [숫자형/질문형/대비형 제목]
## 서론: 공감 유도
## 문제 정의
## 해결 과정
### Phase 1: 첫 번째 시도
### Phase 2: 개선
### Phase 3: 최종 해결책
## 결과
## 배운 점
## 참고 자료
언제 사용:
새로운 기술이나 개념을 소개할 때 사용합니다.
구조:
# [개념/기술명]: [부제목]
## 시작하며
## [기술명]이 뭐지?
## 왜 필요할까?
## 어떻게 동작할까?
## 언제 사용할까?
## 실전 예시
## 주요 개념과 용어
## 장점과 단점
## 시작하기
## 자주 묻는 질문
## 마무리하며
## 참고 자료
언제 사용:
간단한 경험 공유나 팁을 위한 템플릿입니다.
구조:
# [제목]
## 시작하며
## [핵심 내용 1]
## [핵심 내용 2]
## [핵심 내용 3]
## 팁과 주의사항
## 마무리하며
## 참고 자료
언제 사용:
숫자형:
질문형:
대비형:
"배포할 때마다 왜 이렇게 오래 걸릴까?"
개발자라면 누구나 한 번쯤 겪어봤을 거예요.
코드를 수정하고, 커밋하고, 푸시하고, 배포하는데...
커피 한 잔 마실 시간이 필요하죠.
우리 팀도 그랬어요. 배포 한 번 하는 데 10분이 걸렸거든요.
## 문제 정의
사용자가 상품 목록을 볼 때마다 **3초**씩 기다려야 했어요.
1초면 짧지만, 3초는 영원처럼 느껴지죠.
실제로 데이터를 분석해보니 구매 전환율이 **30%나 떨어져** 있었어요.
페이지 이탈률도 **50%**를 넘었고요.
매일 같은 상품 정보를 **100만 번** 이상 데이터베이스에서 조회하고 있었어요.
서버 비용도 매달 증가하는 추세였죠.
> 왜 같은 데이터를 매번 데이터베이스에서 조회해야 할까?
## 배운 점
이번 경험을 통해 배운 건 **"완벽한 해결책은 없다"**는 거예요.
Phase 1의 간단한 캐싱도, Phase 2의 Redis도, 모두 장단점이 있었죠.
중요한 건 **현재 문제에 가장 적합한 방법을 찾는 거**예요.
처음부터 완벽한 설계를 고민하느라 시간을 낭비하지 마세요.
작은 것부터 시도하고, 문제를 발견하고, 개선하는 게 더 빠른 길이에요.
> 기술은 수단이에요. 목적은 사용자에게 더 나은 경험을 주는 거죠.
아직 해결하지 못한 과제도 있어요. 캐시 워밍 전략, 분산 환경에서의 캐시 일관성...
하지만 우리는 계속 나아가고 있어요.
여러분은 어떤 방법을 사용하시나요?