퇴사자 인수인계 스킬 만들기

왜 이 스킬이 필요한가

이 사건의 핵심 문제는 개인의 데이터를 무단으로 AI에 학습시킨 것이다. 하지만 "퇴사자의 업무 지식을 보존한다"는 목표 자체는 모든 조직의 과제다. 올바른 방법은 개인 데이터를 복제하는 게 아니라, 업무 프로세스와 노하우를 구조화된 문서(SKILL.md)로 정리하는 것이다.

이런 경험, 있지 않나요?

퇴사자가 남기고 간 빈자리의 크기는 퇴사 후에야 드러난다

인수인계 스킬 구축 5단계

퇴사 예정자가 재직 중에 업무 지식을 SKILL.md로 정리하는 과정

개발 직군 인수인계 예제

HR뿐 아니라 개발자, 디자이너, PM 등 모든 직군에 적용 가능하다

# 백엔드 개발자 인수인계 스킬 세트
.claude/skills/
├── deploy-production/
│   └── SKILL.md              # /deploy-production — 프로덕션 배포 절차
├── db-migration-guide/
│   └── SKILL.md              # /db-migration-guide — DB 마이그레이션 가이드
├── incident-response/
│   └── SKILL.md              # /incident-response — 장애 대응 매뉴얼
├── api-design-review/
│   └── SKILL.md              # /api-design-review — API 설계 리뷰 기준
└── legacy-payment/
    ├── SKILL.md              # /legacy-payment — 레거시 결제 시스템 가이드
    └── reference.md          # 시스템 구조 상세 문서

# .claude/skills/legacy-payment/SKILL.md
---
name: legacy-payment
description: 레거시 결제 시스템의 구조와 주의사항. 결제 관련 코드를 수정할 때 참조.
user-invocable: false
---

# 레거시 결제 시스템 가이드

이 스킬은 Claude가 결제 관련 코드를 수정할 때 자동으로 참조한다.
user-invocable: false이므로 / 메뉴에는 표시되지 않는다.

## 핵심 주의사항
- 결제 로직은 src/payment/ 디렉토리에 집중
- PG사 연동은 src/payment/pg/ — 3개 PG사를 추상화한 어댑터 패턴
- 절대 금지: payment_core.py의 calculate_amount()는 수정하지 않는다
  (세금 계산 로직이 세무사 검증을 거침, 함부로 바꾸면 세금 신고에 영향)
- 환불 로직은 비동기 처리. 동기로 바꾸면 타임아웃 발생

## 아키텍처
상세 구조는 [reference.md](reference.md) 참조

## 이 코드를 수정해야 할 때
1. 반드시 staging 환경에서 먼저 테스트
2. 테스트 결제 후 PG사 관리자 페이지에서 정상 처리 확인
3. 금액 관련 변경은 PR 리뷰어를 2명 이상 지정

실전 예제: 새벽 3시 장애 대응

퇴사한 시니어 개발자만 알던 장애 대응 노하우를 스킬로 남긴 사례

# .claude/skills/incident-response/SKILL.md
---
name: incident-response
description: 프로덕션 장애 발생 시 대응 절차. 서비스 다운, 500 에러 급증, DB 커넥션 풀 고갈 등의 상황에서 사용.
disable-model-invocation: true
---

# 장애 대응 매뉴얼

## 1단계: 상황 파악 (5분 이내)
- Grafana 대시보드 확인: https://grafana.internal/d/main
- 핵심 지표: 요청 성공률, p99 레이턴시, DB 커넥션 수
- Slack #incident 채널에 장애 선언: "@here [장애] {증상} 확인 중"

## 2단계: 원인 분류

### 500 에러 급증 → 대부분 배포 직후 발생
1. 최근 배포 이력 확인: kubectl rollout history deployment/api
2. 즉시 롤백: kubectl rollout undo deployment/api
3. 롤백 후 3분 대기, 에러율 정상화 확인

### DB 커넥션 풀 고갈 → 슬로우 쿼리가 원인
1. 현재 활성 커넥션 확인: SELECT count(*) FROM pg_stat_activity;
2. 5초 이상 실행 중인 쿼리 식별:
   SELECT pid, now() - pg_stat_activity.query_start AS duration, query
   FROM pg_stat_activity WHERE state = 'active'
   ORDER BY duration DESC LIMIT 10;
3. 주의: 바로 kill 하지 않는다. 결제/정산 쿼리일 수 있음
4. 쿼리 내용 확인 후 안전한 것만 종료: SELECT pg_cancel_backend({pid});

### 외부 API 타임아웃 → PG사 장애 가능성
1. PG사 상태 페이지 확인:
   - A사: https://status.pg-a.co.kr
   - B사: https://status.pg-b.co.kr
2. 특정 PG사 장애면 fallback PG로 전환:
   kubectl set env deployment/api PG_PRIMARY=pg-b
3. 절대 금지: 두 PG사를 동시에 활성화하면 이중 결제 발생

## 3단계: 복구 후
1. #incident 채널에 복구 선언 + 원인 요약
2. 24시간 이내 포스트모템 작성 (docs/postmortem/ 에 저장)
3. 재발 방지 이슈 생성

## 연락처 (장애 등급별)
- P1 (서비스 전체 다운): CTO + 인프라 팀 전원
- P2 (일부 기능 장애): 해당 팀 리드 + 온콜 담당
- P3 (성능 저하): 온콜 담당자
- 온콜 스케줄: https://opsgenie.internal/schedules

실전 예제: 고객 문의 대응 가이드

CS 팀 경력 5년차가 퇴사하면서 남긴 스킬 — 신입이 바로 쓸 수 있도록

# .claude/skills/cs-response/SKILL.md
---
name: cs-response
description: 고객 문의에 대한 응대 가이드. 문의 유형별 답변 템플릿, 에스컬레이션 기준, 톤앤매너 규칙 포함.
argument-hint: [문의 유형: 환불/배송/결제오류/계정/기타]
---

# 고객 문의 응대 가이드

$ARGUMENTS 유형의 문의에 대한 응대 초안을 작성한다.

## 응대 원칙
1. 3분 이내 초기 응답 — "확인 중" 이라도 보낸다
2. 감정 먼저, 해결 다음 — "불편을 드려 죄송합니다" 선행
3. 원인과 해결을 함께 — "~ 때문에 발생했고, ~ 처리하겠습니다"

## 문의 유형별 대응

### 환불 요청
- 결제 후 7일 이내: 전액 환불 가능 (관리자 페이지에서 처리)
- 7~30일: 팀장 승인 필요 → Slack #cs-approval 에 요청
- 30일 초과: 원칙적 불가, 특이사항 있으면 팀장에게 에스컬레이션
- 주의: 환불 승인 전에 "환불해드리겠습니다"라고 먼저 말하지 않는다

### 결제 오류
- PG사 오류인 경우: "일시적인 결제 시스템 지연" 안내 → 30분 후 재시도 권유
- 이중 결제: 즉시 관리자 페이지에서 확인 → 중복분 환불 처리 → 팀장 보고
- 카드사 한도 초과: 고객에게 카드사 직접 문의 안내 (우리가 해결 불가)

### VIP 고객 (월 결제 100만원 이상)
- 일반 가이드와 동일하지만 응대 속도 1분 이내 목표
- 환불/보상 재량권이 넓음 (팀장 승인 없이 10만원까지 가능)
- 담당 AM이 있으면 반드시 참조 (Slack DM으로 상황 공유)

## 절대 하지 말 것
- 내부 시스템 URL이나 관리자 페이지 주소를 고객에게 노출
- "다른 고객도 같은 문제를 겪고 있다"고 말하기 (불안 유발)
- 개발팀 탓으로 돌리기 ("개발팀 실수로 인해..." 금지)
- 해결 가능 여부 불확실한 상태에서 약속하기

관련 자료