99단계팀 표준을 만들고 새 기능을 따라가기

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 60분 · 난이도 ★★★ 심화

이 단계를 마치면

• 팀원들이 흩어져 쓰던 프롬프트와 스킬을 모아 표준을 고르고, 표준마다 주인·용도·쓰면 안 되는 경우·기준표를 붙일 수 있습니다.
• 한 달에 한 번 정해진 사람이 공식 출처로 변화를 확인하고, "영향 있음·시험해 볼 것·상관없음"으로 나눌 수 있습니다.
• 새 후보나 새 기능을 시험·채점·등급 지정을 거쳐 표준에 넣고, 쓰지 않는 표준은 내릴 수 있습니다.

팀에 주간 보고를 기막히게 뽑아내는 사람이 한 명 있다고 합시다. 그 사람만 아는 프롬프트가 있고, 바로 옆 사람은 그런 게 있는지조차 모릅니다. 그 사람이 휴가를 떠나면 주간 보고의 품질도 함께 휴가를 갑니다. 게다가 그 프롬프트는 석 달 전 화면을 기준으로 만든 것이라, 그사이 생긴 기능을 쓰면 절반의 손으로 끝날 일일 수도 있습니다. 팀 표준은 잘 되는 방법을 한 사람의 손에서 꺼내 팀의 자산으로 옮기는 일이고, 월간 확인은 그 자산이 낡지 않게 하는 일입니다. 둘은 한 쌍입니다.

왜 표준이 필요한가

표준이 없는 팀에서는 같은 일의 결과물이 사람마다 다릅니다. 같은 고객에게 보내는 제안서인데 김 대리의 것과 박 대리의 것은 구성도, 말투도, 가격 표기도 다릅니다. 받는 쪽은 한 회사와 거래하면서 두 사람을 상대하는 기분이 듭니다. 더 큰 문제는 개선이 쌓이지 않는다는 점입니다. 김 대리가 프롬프트의 약점을 찾아 고쳐도 그 개선은 김 대리의 파일 안에만 머뭅니다. 표준이 있으면 한 사람의 개선이 팀 모두의 다음 결과물에 반영됩니다. 95단계의 개선 루프가 고치는 대상도 바로 이 표준입니다.

한두 문단으로 끝나고 매번 조금씩 고쳐 쓰는 것은 프롬프트로 둡니다. 순서가 정해져 있고 양식이나 참고 자료가 따라붙는 것은 스킬로 만듭니다. 처음에는 프롬프트로 두었다가, 여러 사람이 같은 부분을 매번 고치기 시작하면 스킬로 옮깁니다.

주인, 넣는 절차, 빼는 절차

표준마다 주인을 한 명 정합니다. 주인은 불만을 듣고, 고치고, 고친 날짜와 내용을 기록합니다. 주인이 없는 표준은 틀린 곳이 보여도 누구에게 말할지 몰라, 사람들이 조용히 자기 버전을 다시 만듭니다. 그렇게 표준은 흩어지기 전으로 돌아갑니다. 주인은 그 표준을 가장 많이 쓰는 사람이 맡는 게 좋습니다. 팀장이 모든 표준의 주인이 되면 병목이 생깁니다.

표준에 넣을 때는 93단계의 기준표로 채점해 통과한 것만 넣습니다. 에이전트로 돌아가는 스킬이라면 94단계의 평가 세트도 함께 붙입니다. 이렇게 하면 "내 것이 더 좋다"는 다툼이 "기준표로 보면 이쪽이 낫다"는 대화로 바뀝니다. 빼는 절차도 정해 둡니다. 석 달 동안 아무도 쓰지 않은 표준, 주인이 떠났는데 새 주인이 없는 표준은 목록에서 내립니다. 표준은 모두가 매주 쓰는 몇 개부터 적게 시작합니다.

한 달에 한 번, 공식 출처로

표준을 만들어 두면 두 번째 일이 생깁니다. 기능은 자주 바뀝니다. 메뉴 이름이 달라지고, 없던 기능이 생기고, 어떤 기능은 다른 요금제로 옮겨 갑니다. 변화를 따라가지 않으면 두 가지 일이 생깁니다. 하나는 몇 달 전부터 되는 일을 여전히 손으로 하는 것입니다. 다른 하나는 더 조용하고, 그래서 더 위험합니다. 쓰던 표준이 바뀌었는데 아무도 모르는 경우입니다. 스킬이 예전처럼 불리지 않거나, 연결자의 권한 범위가 달라졌거나, 자동화가 멈췄는데 알림조차 오지 않을 때가 있습니다.

그렇다고 모든 소식을 좇을 필요는 없습니다. 볼 것은 "우리가 하는 일이 더 쉬워지거나 위험해지는 변화"뿐입니다. 루틴은 좁게 짭니다.

요약 글과 영상은 빠르지만 다른 나라에만 먼저 나온 기능, 일부 요금제에만 있는 기능, 발표만 되고 아직 쓸 수 없는 기능이 구분 없이 섞입니다. Claude에게 웹 검색으로 정리를 맡길 때도 출처를 공식 문서로 한정하고, 담당자가 링크를 직접 눌러 확인합니다(4단계).

새 연결자라면 등급표에 열을 하나 더해야 하고, 새 기능이 밖으로 나가는 일을 할 수 있다면 사람이 확인하는 단계부터 정합니다. 루틴 끝에는 "쓰던 것이 여전히 잘 도는가"도 봅니다. 공용 스킬을 샘플 하나로 돌리고, 자동화 실패 기록과 실패 알림을 받는 사람을 확인합니다. 95단계의 월간 점검을 같은 날 하면 한 번에 끝납니다.

현장 장면

설계 엔지니어링 회사 운영팀의 서 대리는 팀 표준과 월간 확인을 함께 맡습니다. 먼저 팀원 여섯 명에게 가장 자주 쓰는 프롬프트나 스킬을 하나씩 가져오게 합니다. 모인 여덟 개를 아래 첫 번째 프롬프트로 정리하자 묶음 셋이 나옵니다. 설계 변경 요약, 회의록 정리, 협력사 회신 초안입니다.

회의록 묶음에서 다툼이 납니다. 한 사람은 자기 프롬프트가 더 읽기 쉽다고 하고, 다른 사람은 자기 것이 결정 사항을 더 잘 뽑는다고 맞섭니다. 서 대리는 기준표를 꺼냅니다. "결정 사항마다 담당자와 기한이 있다(필수)", "회의에서 나오지 않은 결정이 없다(필수)", "한 페이지를 넘지 않는다(권장)". 같은 회의 녹취 다섯 건으로 채점하니, 읽기 쉽다던 쪽이 회의에서 나오지 않은 기한을 두 번 지어냈습니다. 결정 사항을 잘 뽑는 쪽을 표준으로 정하고, 읽기 쉬운 쪽의 요약 형식을 참고 예시로 붙입니다. 주인은 그 프롬프트를 만든 사람이 맡습니다. 협력사 회신 묶음은 쓰는 사람이 둘뿐이라 표준에 넣지 않습니다.

한 달 뒤 첫 월간 확인. 첫 달 서 대리는 영상과 요약 글을 보고 새 기능 목록 열두 개를 올렸는데, 그중 하나는 회사 요금제에서 쓸 수 없었고 하나는 발표만 된 기능이었습니다. 둘째 달에는 웹 검색을 켠 Claude에게 출처를 공식 공지와 도움말 문서로 한정해 정리를 맡깁니다. 링크가 달린 항목 일곱 개 가운데 하나는 링크를 열어 보니 그런 내용이 없어 지우고, 하나는 쓰지 않는 요금제 이야기라 "상관없음"으로 옮깁니다.

스킬과 관련된 변화 하나는 "영향 있음"입니다. 서 대리는 "설계 변경 요약" 스킬 주인에게 알리고, 주인은 평가 세트를 돌려 봅니다. 결과가 예전과 같아 "확인, 변경 없음"으로 기록합니다. 프로젝트 관리 도구와 이어지는 새 연결자는 "시험해 볼 것"입니다. 등급표에 해당 열이 없으니 보안 담당에게 먼저 묻고, "사내 일반까지, 읽기만"으로 정해진 뒤에야 샘플 프로젝트로 시험을 시작합니다.

마지막 점검에서 주간 보고 취합 자동화가 지난달 두 번 실패한 것이 드러납니다. 실패 알림을 받는 사람이 이미 퇴사한 직원이었습니다. 서 대리는 알림 받는 사람을 바꾸고, 운영 규칙 7번 항목에 반영해 달라고 요청합니다.

따라 하기

1. 팀원마다 가장 자주 쓰는 프롬프트나 스킬 하나씩을 가져오게 하고, 아래 첫 번째 프롬프트로 겹치는 것을 묶습니다. 성공 기준: 남긴 후보가 다섯 개 이하입니다.
2. 묶음 안에서 다툼이 있으면 같은 입력을 기준표로 채점해 결정합니다. 성공 기준: 고른 이유가 "기준표의 ○번을 통과했다"는 문장입니다.
3. 남긴 것마다 주인, 용도, 쓰면 안 되는 경우, 기준표(에이전트 작업이면 평가 세트)를 붙여 한곳에 모읍니다. 팀이 쓰는 연결자와 권한도 같은 곳에 적습니다. 성공 기준: 주인이 비어 있는 표준이 없고, 새 팀원이 링크 하나로 모든 표준에 닿으며, 연결자 권한이 98단계 등급표와 어긋나지 않습니다.
4. 월간 확인 담당과 날짜를 정하고, 두 번째 프롬프트로 첫 정리를 받습니다. 웹 검색을 켭니다. 성공 기준: 모든 항목에 출처 링크가 있고, 담당자가 링크를 눌러 확인한 항목만 남았습니다.
5. 남은 항목을 세 갈래로 나누고, "영향 있음"은 해당 표준 주인에게, "시험해 볼 것"은 시험할 사람에게 넘깁니다. 성공 기준: 앞의 두 갈래 항목마다 받는 사람의 이름이 있습니다.
6. 쓰던 것이 여전히 잘 도는지 점검하고, 쓰이지 않거나 주인 없는 표준을 내립니다. 성공 기준: 점검 결과가 "이상 없음" 또는 "고칠 것: ○○"으로 기록되어 있고, 다음 달 같은 날 일정이 팀 달력에 있습니다.

복사해 쓰는 프롬프트

팀원들이 가져온 프롬프트와 스킬을 팀 표준 후보로 정리해 줘.

[1: 작성자, 전문]
[2: 작성자, 전문]
[3: 작성자, 전문]

1. 용도가 겹치는 것끼리 묶어 줘.
2. 묶음마다 가장 나은 하나를 고르거나 장점을 합친 안을 제안하고, 고른 이유를 적어.
3. 각 안에 "용도", "쓰면 안 되는 경우", "좋은 결과 기준 세 가지(예·아니오로 답할 수 있게)"를 붙여 줘.
4. 스킬로 만들면 좋을 것에는 [스킬 후보]라고 표시하고 이유를 적어.
최종 선택은 팀이 한다. 너는 후보만 낸다.

지난 [기간] 동안 Claude 제품에 생긴 변화를 정리해 줘. 웹 검색으로 Anthropic의 공식 공지와 도움말 문서만 출처로 삼아.

항목마다: 무엇이 바뀌었나 / 출처 링크 / 쓸 수 있는 조건(요금제, 지역, 앱 종류. 출처에 적힌 것만) / 우리에게 해당하는지
우리 상황: [쓰는 기능과 요금제], 팀 표준 목록: [표준 이름들]

마지막에 세 갈래로 나눠 줘: 우리 표준에 영향 있음 / 시험해 볼 것 / 지금은 상관없음.
출처를 찾지 못한 내용은 넣지 마. 발표만 되고 아직 쓸 수 없는 기능은 따로 표시해 줘.

막히면 이렇게

스스로 점검

• ☐ 우리 팀 표준마다 주인과 기준표가 있고, 새 팀원에게 링크 하나로 보여 줄 수 있습니까
• ☐ 이번 달 월간 확인 담당이 누구이고, 지난 확인의 "영향 있음" 항목이 누구에게 넘어갔는지 압니까
• ☐ 새 기능을 표준에 넣기 전에 거칠 세 가지(시험, 채점, 등급 지정)를 말할 수 있습니까

기억할 것

• 표준마다 주인이 한 명 있어야 합니다. 넣을 때는 기준표로 판단하고, 쓰지 않는 것은 내립니다.
• 새 소식은 공식 출처에서만 확인하고 링크를 직접 눌러 봅니다. 루틴은 좁게 짭니다.
• 새것을 들이는 만큼, 쓰던 것이 여전히 잘 도는지도 살핍니다.

더 알아보기 · 릴리스 노트 · Claude Code 변경 기록 · Anthropic 소식