99단계팀 표준을 만들고 새 기능을 따라가기
잘 되는 프롬프트·스킬·연결자를 팀 공용으로 모으고, 한 달에 한 번 공식 출처로 변화를 확인해 표준을 고친다.
걸리는 시간 · 읽기 약 10분 · 따라 하기 약 60분 · 난이도 ★★★ 심화
이 단계를 마치면
- 팀원들이 흩어져 쓰던 프롬프트와 스킬을 모아 표준을 고르고, 표준마다 주인·용도·쓰면 안 되는 경우·기준표를 붙일 수 있다.
- 한 달에 한 번 정해진 사람이 공식 출처로 변화를 확인하고, "영향 있음·시험해 볼 것·상관없음"으로 나눌 수 있다.
- 새 후보나 새 기능을 시험·채점·등급 지정을 거쳐 표준에 넣고, 쓰지 않는 표준은 내릴 수 있다.
팀에 주간 보고를 기막히게 뽑아내는 사람이 한 명 있다고 하자. 그 사람만 아는 프롬프트가 있고, 바로 옆 사람은 그런 게 있는지조차 모른다. 그 사람이 휴가를 떠나면 주간 보고의 품질도 함께 휴가를 간다. 게다가 그 프롬프트는 석 달 전 화면을 기준으로 만든 것이라, 그사이 생긴 기능을 쓰면 절반의 손으로 끝날 일일 수도 있다. 팀 표준은 잘 되는 방법을 한 사람의 손에서 꺼내 팀의 자산으로 옮기는 일이고, 월간 확인은 그 자산이 낡지 않게 하는 일이다. 둘은 한 쌍이다.
왜 표준이 필요한가
표준이 없는 팀에서는 같은 일의 결과물이 사람마다 다르다. 같은 고객에게 보내는 제안서인데 김 대리의 것과 박 대리의 것은 구성도, 말투도, 가격 표기도 다르다. 받는 쪽은 한 회사와 거래하면서 두 사람을 상대하는 기분이 든다. 더 큰 문제는 개선이 쌓이지 않는다는 점이다. 김 대리가 프롬프트의 약점을 찾아 고쳐도 그 개선은 김 대리의 파일 안에만 머문다. 표준이 있으면 한 사람의 개선이 팀 모두의 다음 결과물에 반영된다. 95단계의 개선 루프가 고치는 대상도 바로 이 표준이다.
| 모을 것 | 무엇인가 | 둘 곳 | 다시 볼 단계 |
|---|---|---|---|
| 공용 프롬프트 | 15단계에서 각자 만든 것 중 팀이 같이 쓸 만한 것 | 팀 프로젝트의 지침이나 공용 문서 | 5단계 · 같은 설명은 프로젝트에 한 번만 15단계 · 내 업무 프롬프트 다섯 개 |
| 공용 스킬 | 반복해서 쓰는 절차. 회사 양식과 용어집을 스킬 폴더에 함께 넣는다 | 조직 공유 | 47단계 · 참고 자료와 양식 넣기 50단계 · 팀에 스킬 나눠 주기 |
| 공용 연결자 목록 | 팀이 어떤 연결자를 어떤 권한으로 쓰는지 | 공용 문서. 98단계 등급표와 맞아야 한다 | 68단계 · 읽기 권한과 쓰기 권한 |
한두 문단으로 끝나고 매번 조금씩 고쳐 쓰는 것은 프롬프트로 둔다. 순서가 정해져 있고 양식이나 참고 자료가 따라붙는 것은 스킬로 만든다. 처음에는 프롬프트로 두었다가, 여러 사람이 같은 부분을 매번 고치기 시작하면 스킬로 옮긴다.
주인, 넣는 절차, 빼는 절차
표준마다 주인을 한 명 정한다. 주인은 불만을 듣고, 고치고, 고친 날짜와 내용을 기록한다. 주인이 없는 표준은 틀린 곳이 보여도 누구에게 말할지 몰라, 사람들이 조용히 자기 버전을 다시 만든다. 그렇게 표준은 흩어지기 전으로 돌아간다. 주인은 그 표준을 가장 많이 쓰는 사람이 맡는 게 좋다. 팀장이 모든 표준의 주인이 되면 병목이 생긴다.
표준에 넣을 때는 93단계의 기준표로 채점해 통과한 것만 넣는다. 에이전트로 돌아가는 스킬이라면 94단계의 평가 세트도 함께 붙인다. 이렇게 하면 "내 것이 더 좋다"는 다툼이 "기준표로 보면 이쪽이 낫다"는 대화로 바뀐다. 빼는 절차도 정해 둔다. 석 달 동안 아무도 쓰지 않은 표준, 주인이 떠났는데 새 주인이 없는 표준은 목록에서 내린다. 표준은 모두가 매주 쓰는 몇 개부터 적게 시작한다.
| 판단 | 표준에 넣는다 | 개인 것으로 둔다 |
|---|---|---|
| 쓰는 사람 | 팀의 여럿이 매주 쓴다 | 한 사람만 쓴다 |
| 결과물 | 밖으로 나가거나 다른 사람이 받는다 | 나만 본다 |
| 기준표 | 있고, 통과했다 | 없거나 아직 채점하지 않았다 |
| 주인 | 맡을 사람이 있다 | 맡을 사람이 없다 |
한 달에 한 번, 공식 출처로
표준을 만들어 두면 두 번째 일이 생긴다. 기능은 자주 바뀐다. 메뉴 이름이 달라지고, 없던 기능이 생기고, 어떤 기능은 다른 요금제로 옮겨 간다. 변화를 따라가지 않으면 두 가지 일이 생긴다. 하나는 몇 달 전부터 되는 일을 여전히 손으로 하는 것이다. 다른 하나는 더 조용하고, 그래서 더 위험하다. 쓰던 표준이 바뀌었는데 아무도 모르는 경우다. 스킬이 예전처럼 불리지 않거나, 연결자의 권한 범위가 달라졌거나, 자동화가 멈췄는데 알림조차 오지 않을 때가 있다.
그렇다고 모든 소식을 좇을 필요는 없다. 볼 것은 "우리가 하는 일이 더 쉬워지거나 위험해지는 변화"뿐이다. 루틴은 좁게 짠다.
| 요소 | 정할 것 | 예 |
|---|---|---|
| 누가 | 이번 달 담당 한 사람 | 운영팀 대리 |
| 언제 | 매달 같은 날 | 매달 첫째 주 화요일 |
| 어디서 | 공식 출처만. Anthropic의 공지와 도움말 문서 | 요약 글, 영상은 판단 근거로 쓰지 않는다 |
| 무엇을 적나 | 세 갈래로 나눈 표 하나 | 영향 있음 / 시험해 볼 것 / 상관없음 |
요약 글과 영상은 빠르지만 다른 나라에만 먼저 나온 기능, 일부 요금제에만 있는 기능, 발표만 되고 아직 쓸 수 없는 기능이 구분 없이 섞인다. Claude에게 웹 검색으로 정리를 맡길 때도 출처를 공식 문서로 한정하고, 담당자가 링크를 직접 눌러 확인한다(4단계).
| 갈래 | 할 일 |
|---|---|
| 영향 있음 | 해당 표준의 주인에게 알리고, 등급표(98단계)나 표준 목록을 고친다. 에이전트 작업이면 평가 세트를 다시 돌린다(94단계) |
| 시험해 볼 것 | 한 사람이 샘플 자료로 시험하고 기준표로 채점한 뒤, 등급표에서 위치를 정하고 도입한다 |
| 상관없음 | 짧게 기록만 하고 넘어간다 |
새 연결자라면 등급표에 열을 하나 더해야 하고, 새 기능이 밖으로 나가는 일을 할 수 있다면 사람이 확인하는 단계부터 정한다. 루틴 끝에는 "쓰던 것이 여전히 잘 도는가"도 본다. 공용 스킬을 샘플 하나로 돌리고, 자동화 실패 기록과 실패 알림을 받는 사람을 확인한다. 95단계의 월간 점검을 같은 날 하면 한 번에 끝난다.
칼럼에서 읽기 「AX를 잘하는 기업은 무엇이 다를까?」
“AI를 잘 쓰는 기업은 오늘의 업무에서 새 데이터와 경험을 얻는다. 그것을 지식으로 쌓고 프로세스를 고친다. 고친 프로세스에서 더 좋은 데이터가 나오고 AI는 그것을 다시 쓴다. 한 번의 개선이 다음 개선의 재료가 된다.”
“지식이 정리되지 않은 기업은 다르다. 새 AI가 나올 때마다 처음부터 다시 시작한다.”
「AX를 잘하는 기업은 무엇이 다를까?」의 이 대목이 팀 표준과 월간 확인을 함께 두는 이유다. 표준은 한 사람의 개선을 팀 모두의 다음 결과물로 넘겨 주고, 월간 확인은 새 기능이 나왔을 때 처음부터 다시 시작하지 않게 해 준다. 표준과 기준표, 평가 세트가 남아 있으면 새 기능 앞에서도 바뀐 부분만 시험하면 된다.
현장 장면
설계 엔지니어링 회사 운영팀의 서 대리는 팀 표준과 월간 확인을 함께 맡는다. 먼저 팀원 여섯 명에게 가장 자주 쓰는 프롬프트나 스킬을 하나씩 가져오게 한다. 모인 여덟 개를 아래 첫 번째 프롬프트로 정리하자 묶음 셋이 나온다. 설계 변경 요약, 회의록 정리, 협력사 회신 초안이다.
회의록 묶음에서 다툼이 난다. 한 사람은 자기 프롬프트가 더 읽기 쉽다고 하고, 다른 사람은 자기 것이 결정 사항을 더 잘 뽑는다고 맞선다. 서 대리는 기준표를 꺼낸다. "결정 사항마다 담당자와 기한이 있다(필수)", "회의에서 나오지 않은 결정이 없다(필수)", "한 페이지를 넘지 않는다(권장)". 같은 회의 녹취 다섯 건으로 채점하니, 읽기 쉽다던 쪽이 회의에서 나오지 않은 기한을 두 번 지어냈다. 결정 사항을 잘 뽑는 쪽을 표준으로 정하고, 읽기 쉬운 쪽의 요약 형식을 참고 예시로 붙인다. 주인은 그 프롬프트를 만든 사람이 맡는다. 협력사 회신 묶음은 쓰는 사람이 둘뿐이라 표준에 넣지 않는다.
한 달 뒤 첫 월간 확인. 첫 달 서 대리는 영상과 요약 글을 보고 새 기능 목록 열두 개를 올렸는데, 그중 하나는 회사 요금제에서 쓸 수 없었고 하나는 발표만 된 기능이었다. 둘째 달에는 웹 검색을 켠 Claude에게 출처를 공식 공지와 도움말 문서로 한정해 정리를 맡긴다. 링크가 달린 항목 일곱 개 가운데 하나는 링크를 열어 보니 그런 내용이 없어 지우고, 하나는 쓰지 않는 요금제 이야기라 "상관없음"으로 옮긴다.
스킬과 관련된 변화 하나는 "영향 있음"이다. 서 대리는 "설계 변경 요약" 스킬 주인에게 알리고, 주인은 평가 세트를 돌려 본다. 결과가 예전과 같아 "확인, 변경 없음"으로 기록한다. 프로젝트 관리 도구와 이어지는 새 연결자는 "시험해 볼 것"이다. 등급표에 해당 열이 없으니 보안 담당에게 먼저 묻고, "사내 일반까지, 읽기만"으로 정해진 뒤에야 샘플 프로젝트로 시험을 시작한다.
마지막 점검에서 주간 보고 취합 자동화가 지난달 두 번 실패한 것이 드러난다. 실패 알림을 받는 사람이 이미 퇴사한 직원이었다. 서 대리는 알림 받는 사람을 바꾸고, 운영 규칙 7번 항목에 반영해 달라고 요청한다.
따라 하기
- 팀원마다 가장 자주 쓰는 프롬프트나 스킬 하나씩을 가져오게 하고, 아래 첫 번째 프롬프트로 겹치는 것을 묶는다. 성공 기준: 남긴 후보가 다섯 개 이하다.
- 묶음 안에서 다툼이 있으면 같은 입력을 기준표로 채점해 결정한다. 성공 기준: 고른 이유가 "기준표의 ○번을 통과했다"는 문장이다.
- 남긴 것마다 주인, 용도, 쓰면 안 되는 경우, 기준표(에이전트 작업이면 평가 세트)를 붙여 한곳에 모은다. 팀이 쓰는 연결자와 권한도 같은 곳에 적는다. 성공 기준: 주인이 비어 있는 표준이 없고, 새 팀원이 링크 하나로 모든 표준에 닿으며, 연결자 권한이 98단계 등급표와 어긋나지 않는다.
- 월간 확인 담당과 날짜를 정하고, 두 번째 프롬프트로 첫 정리를 받는다. 웹 검색을 켠다. 성공 기준: 모든 항목에 출처 링크가 있고, 담당자가 링크를 눌러 확인한 항목만 남았다.
- 남은 항목을 세 갈래로 나누고, "영향 있음"은 해당 표준 주인에게, "시험해 볼 것"은 시험할 사람에게 넘긴다. 성공 기준: 앞의 두 갈래 항목마다 받는 사람의 이름이 있다.
- 쓰던 것이 여전히 잘 도는지 점검하고, 쓰이지 않거나 주인 없는 표준을 내린다. 성공 기준: 점검 결과가 "이상 없음" 또는 "고칠 것: ○○"으로 기록되어 있고, 다음 달 같은 날 일정이 팀 달력에 있다.
복사해 쓰는 프롬프트
팀원들이 가져온 프롬프트와 스킬을 팀 표준 후보로 정리해 줘.
[1: 작성자, 전문]
[2: 작성자, 전문]
[3: 작성자, 전문]
1. 용도가 겹치는 것끼리 묶어 줘.
2. 묶음마다 가장 나은 하나를 고르거나 장점을 합친 안을 제안하고, 고른 이유를 적어.
3. 각 안에 "용도", "쓰면 안 되는 경우", "좋은 결과 기준 세 가지(예·아니오로 답할 수 있게)"를 붙여 줘.
4. 스킬로 만들면 좋을 것에는 [스킬 후보]라고 표시하고 이유를 적어.
최종 선택은 팀이 한다. 너는 후보만 낸다.
지난 [기간] 동안 Claude 제품에 생긴 변화를 정리해 줘. 웹 검색으로 Anthropic의 공식 공지와 도움말 문서만 출처로 삼아.
항목마다: 무엇이 바뀌었나 / 출처 링크 / 쓸 수 있는 조건(요금제, 지역, 앱 종류. 출처에 적힌 것만) / 우리에게 해당하는지
우리 상황: [쓰는 기능과 요금제], 팀 표준 목록: [표준 이름들]
마지막에 세 갈래로 나눠 줘: 우리 표준에 영향 있음 / 시험해 볼 것 / 지금은 상관없음.
출처를 찾지 못한 내용은 넣지 마. 발표만 되고 아직 쓸 수 없는 기능은 따로 표시해 줘.
막히면 이렇게
| 증상 | 원인 | 처방 |
|---|---|---|
| "내 것이 더 좋다"는 다툼이 끝나지 않는다 | 판단할 기준이 없다 | 기준표를 먼저 정하고, 같은 입력으로 채점해 통과한 것을 고른다 |
| 표준이 틀렸는데 아무도 고치지 않는다 | 주인이 없다 | 가장 많이 쓰는 사람을 주인으로 정하고, 고친 날짜와 내용을 기록하게 한다 |
| 소개된 기능이 우리 화면에 없다 | 요약 글을 근거로 삼았고 요금제·지역 조건을 보지 않았다 | 공식 문서만 출처로 삼고, 쓸 수 있는 조건을 항목마다 적게 한다 |
| 스킬이나 자동화가 조용히 멈춰 있었다 | 새 기능만 보고 쓰던 것은 점검하지 않았다 | 루틴 끝에 "여전히 잘 도는가" 점검을 넣고, 실패 알림 받는 사람도 확인한다 |
스스로 점검
- ☐ 우리 팀 표준마다 주인과 기준표가 있고, 새 팀원에게 링크 하나로 보여 줄 수 있는가
- ☐ 이번 달 월간 확인 담당이 누구이고, 지난 확인의 "영향 있음" 항목이 누구에게 넘어갔는지 아는가
- ☐ 새 기능을 표준에 넣기 전에 거칠 세 가지(시험, 채점, 등급 지정)를 말할 수 있는가
점검 해설 보기
- 표준마다 주인, 용도, 쓰면 안 되는 경우, 기준표(에이전트 작업이면 평가 세트)가 붙어 있고, 새 팀원에게 링크 하나로 모두 보여 줄 수 있으면 통과다. 주인이 없는 표준이 있다면 「주인, 넣는 절차, 빼는 절차」를 보고 가장 많이 쓰는 사람을 주인으로 정하거나 목록에서 내린다.
- 이번 달 월간 확인 담당자의 이름과 날짜를 말할 수 있고, 지난 확인에서 "영향 있음"으로 나눈 항목마다 넘겨받은 표준 주인의 이름이 기록돼 있으면 된다. 기록이 없다면 「한 달에 한 번, 공식 출처로」의 루틴 표대로 누가, 언제, 어디서, 무엇을 적을지부터 정한다.
- 한 사람이 샘플 자료로 시험하고, 기준표로 채점하고, 98단계 등급표에서 위치를 정한다는 세 단계를 순서대로 말할 수 있으면 통과다. 요약 글이나 영상을 보고 바로 들이려 했다면 「현장 장면」의 서 대리 사례와 세 갈래 표를 다시 읽는다.
기억할 것
- 표준마다 주인이 한 명 있어야 한다. 넣을 때는 기준표로 판단하고, 쓰지 않는 것은 내린다.
- 새 소식은 공식 출처에서만 확인하고 링크를 직접 눌러 본다. 루틴은 좁게 짠다.
- 새것을 들이는 만큼, 쓰던 것이 여전히 잘 도는지도 살핀다.
더 알아보기 · 릴리스 노트 · Claude Code 변경 기록 · Anthropic 소식