#6 SOP 유지·개선 루틴 설계lecture_script
코스: claude-sop-onboarding · 에이전트: producer
HOOK (45초)
SOP 열심히 만들었는데, 팀원 한 명 바뀌자마자 절반이 틀린 내용이 됐던 경험 있으시죠?
그 순간 SOP는 '문서'가 아니라 '민폐'가 됩니다.
오늘은 그 문제를 구조로 해결합니다.
Claude를 이용해 SOP를 언제, 누가, 어떻게 업데이트할지 반복 가능한 루틴으로 만들어 드릴게요.
한 번만 설계해 두면, 앞으로 SOP는 저절로 살아 움직입니다.
PROMISE (30초)
이 차시가 끝나면, 팀원 교체나 업무 변경이 생겼을 때 Claude와 함께 SOP를 10분 안에 업데이트하는 재현 가능한 순서를 직접 문서화할 수 있습니다.
CORE (8–10분)
중요 개념 1 — SOP 버전 관리 원칙: '신호등 트리거'
설명
SOP는 만들고 끝이 아닙니다.
업데이트가 필요한 순간을 미리 정의해야 합니다.
이걸 '트리거 조건'이라고 부릅니다.
메모리 페그는 신호등 3색입니다.
- 🔴 빨강: 즉시 업데이트 — 팀원 교체, 툴 변경, 법규·정책 변경
- 🟡 노랑: 30일 내 검토 — 반복 질문 3회 이상, 온보딩 완료 후 피드백
- 🟢 초록: 분기 정기 검토 — 큰 변화 없어도 3개월마다 한 번
예시
신규 입사자가 Notion 대신 Linear를 쓰게 됐다면, 빨간 신호등입니다.
그날 바로 SOP 업데이트 트리거를 당겨야 합니다.
반례
"그냥 분기마다 한꺼번에 고치면 되지 않나요?"
대부분의 경우, 이 방식은 실패합니다.
분기가 끝날 때쯤엔 뭐가 바뀌었는지 아무도 기억 못 합니다.
트리거는 반드시 사건과 연결되어야 합니다.
정리
SOP 버전 관리의 중요한은 '주기'가 아니라 '트리거'입니다.
변경 이력에는 날짜, 변경 사유, 담당자 세 가지를 항상 기록하세요.
중요 개념 2 — Claude에게 기존 SOP 비교·수정 요청하는 프롬프트 패턴: '비포-애프터 샌드위치'
설명
Claude에게 SOP 수정을 맡길 때, 가장 흔한 실수는 "이거 좀 업데이트해줘"라고만 하는 겁니다.
Claude는 맥락이 없으면 추측합니다.
제 경험상, 이 세 겹 구조가 가장 잘 작동합니다.
메모리 페그는 샌드위치 3단입니다.
- 첫 번째 빵: 기존 SOP 전문 붙여넣기
- 속 재료: 변경된 조건 또는 새로운 정보 명시
- 두 번째 빵: 원하는 출력 형식 지정
예시
실제 프롬프트 예시를 보여드리겠습니다.
"아래는 현재 온보딩 SOP입니다. [기존 SOP 전문] 변경 사항: 슬랙 대신 Teams를 사용하게 됐고, 승인 담당자가 김팀장에서 이팀장으로 바뀌었습니다. 위 변경 사항을 반영해 SOP를 수정해 주세요. 변경된 부분은 굵게 표시하고, 변경 이유를 각 항목 하단에 한 줄로 추가해 주세요."
이 구조로 요청하면 Claude는 기존 내용을 유지하면서 수정 부분만 정확히 짚어줍니다.
반례
"변경 사항만 알려주면 Claude가 알아서 하지 않나요?"
기존 SOP를 붙여넣지 않으면, Claude는 새로운 문서를 새로 씁니다.
회원님이 원하는 건 '교체'가 아니라 '수정'입니다.
정리
비포-애프터 샌드위치 구조를 쓰면 Claude는 수정 전후를 비교 가능한 형태로 돌려줍니다.
팀원에게 검토 요청하기도 훨씬 쉬워집니다.
중요 개념 3 — 팀원 피드백을 SOP 개선에 반영하는 루틴: '3R 루프'
설명
SOP는 만드는 사람이 아니라 쓰는 사람이 개선합니다.
팀원 피드백을 SOP에 녹이는 루틴이 없으면, 피드백은 채팅창에서 사라집니다.
메모리 페그는 3R 루프입니다.
- Receive: 피드백 수집 — 온보딩 완료 후 설문 또는 슬랙 전용 채널
- Refine: Claude로 수정 — 피드백을 프롬프트에 넣고 SOP 개선안 생성
- Release: 버전 업 배포 — 팀 공유 문서에 변경 이력과 함께 업로드
예시
신입 팀원이 "3단계 승인 절차가 너무 복잡해요"라는 피드백을 남겼습니다.
이걸 Claude에게 이렇게 전달합니다.
"온보딩 SOP 3단계 승인 절차에 대해 팀원이 '복잡하다'는 피드백을 줬습니다. 절차를 단순화하되 필수 승인 기준은 유지하는 방향으로 해당 섹션을 다시 써주세요."
Claude가 개선안을 주면, 팀장 검토 후 바로 배포합니다.
반례
"피드백을 모아서 한꺼번에 반영하면 안 되나요?"
모아두면 컨텍스트가 섞입니다.
피드백은 받은 즉시 트리거를 판단하고, 빨간 신호등이면 즉시 3R 루프를 돌리세요.
정리
3R 루프는 피드백이 SOP 안으로 들어오는 공식 통로입니다.
이 루틴이 있으면 팀원은 피드백을 줄 이유가 생기고, SOP는 계속 살아있게 됩니다.
EXERCISE (3–4분)
영상을 지금 일시정지하세요.
아래 4단계를 따라 '온보딩 SOP 유지관리 플레이북' 1페이지를 직접 만들어 보겠습니다.
준비물: Notion, Google Docs, 또는 종이 한 장
Step 1 — 트리거 조건 정의 (1분)
표를 하나 만드세요.
3행짜리면 충분합니다.
| 트리거 색상 | 조건 | 대응 기한 |
|---|---|---|
| 🔴 빨강 | (회원님의 팀에 맞는 즉시 변경 조건 2가지 적기) | 즉시 |
| 🟡 노랑 | (30일 내 검토 조건 2가지 적기) | 30일 내 |
| 🟢 초록 | 정기 검토 | 분기 1회 |
Step 2 — 담당자와 주기 지정 (1분)
다음 세 항목을 한 줄씩 적으세요.
- SOP 수정 담당자: (이름 또는 역할)
- 검토 승인자: (이름 또는 역할)
- 배포 채널: (예: Notion 팀 페이지 / 슬랙 #공지 채널)
Step 3 — Claude 수정 요청 프롬프트 템플릿 작성 (1분)
빈칸을 채워서 나만의 프롬프트 템플릿을 완성하세요.
"아래는 현재 [업무명] SOP입니다. [기존 SOP] 변경 사항: [변경 내용] 변경된 부분은 굵게 표시하고, 변경 이유를 각 항목 하단에 한 줄로 추가해 주세요."
이 템플릿을 플레이북 문서 안에 그대로 붙여넣으세요.
Step 4 — 3R 루프 피드백 채널 지정 (30초)
팀원 피드백을 받을 채널 하나만 정하세요.
슬랙 채널, 구글 폼, 노션 댓글 중 지금 팀에서 쓰는 것 하나면 됩니다.
플레이북 맨 아래에 "피드백 채널: [채널명]" 한 줄을 추가하면 완성입니다.
CTA (30초)
다음 차시에서는 이 코스 전체를 마무리합니다.
Claude로 만든 SOP 자동 처리을 팀에 실제로 도입할 때 생기는 저항과 그 해결법을 다룰 예정입니다.
오늘 만든 유지관리 플레이북, 댓글에 인증해 주세요.
어떤 트리거 조건을 정했는지 한 줄만 남겨줘도 됩니다.
다른 분들에게 실질적인 도움이 됩니다.
예상 분량: 15분