95단계스스로 나아지는 업무 시스템

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

이 단계를 마치면

• 사람이 고친 부분, 버려진 초안의 이유, 막힌 지점을 모아 개선의 재료로 쓸 수 있다.
• Claude에게 원인 분석과 개선안을 받아 94단계 평가 세트로 전후를 비교하고, 승인을 거쳐 반영할 수 있다.
• 변경 기록과 되돌리기, 바꾸지 못하는 항목을 갖춘 주간·월간 개선 루틴을 운영할 수 있다.

매주 월요일, Claude가 만든 초안을 받아 같은 곳을 고치고 있지는 않은가? 거래처 이름 뒤에 "귀하"를 붙이고, 날짜 형식을 바꾸고, 빠진 부가세 문구를 넣는다. 더 아까운 것은 그 수정이 아무 데도 남지 않는다는 점이다. 사람은 고치고 잊고, Claude는 다음 주에 같은 초안을 낸다. 이 단계에서는 그 수정들을 모아 시스템을 고치는 재료로 쓴다. 이 고리가 한 번 돌 때마다 업무 시스템이 조금씩 나아진다. 흔히 자율성장 시스템이라고 부르는 모습이다.

무엇이 자라는가

먼저 정직하게 말해 두자. 이 루프에서 Claude라는 모델 자체가 다시 학습하지는 않는다. 자라는 것은 Claude가 일할 때 읽는 파일과 지시다. 스킬의 절차와 참고 양식, CLAUDE.md의 규칙, 프로젝트 지침과 지식, 예약 작업이나 자동화 흐름의 지시문. 이것들이 나아지면 같은 Claude가 더 나은 결과를 낸다. 같은 신입 사원이라도 업무 매뉴얼이 좋아지면 일이 나아지는 것과 같다.

대화 내용을 기억해 다음에 반영하는 메모리 기능도 있다(6단계). 개인에게는 편하지만 팀의 업무 시스템을 고치는 일은 메모리에만 맡기지 않는다. 무엇이 언제 바뀌었는지 모두가 읽고 되돌리기 어렵기 때문이다. 팀의 개선은 누구나 열어 볼 수 있는 파일에 적고, 바꿀 때마다 기록을 남긴다.

"자율"이라는 말에도 선을 긋는다. 이 시스템이 스스로 하는 일은 기록을 모으고, 원인을 찾고, 개선안을 쓰는 데까지다. 반영은 언제나 사람이 승인한다.

개선 루프 여섯 단계

3단계의 개선안은 제안일 뿐이다. 아무리 그럴듯해도 4단계 평가 세트와 5단계 승인을 거치지 않으면 반영하지 않는다. 그럴듯한 개선이 다른 과제를 망가뜨리는 일은 94단계에서 이미 보았다.

무엇을 모으나

개선의 재료는 사람이 손댄 흔적이다.

96단계에서 만날 정 이사도 상담원이 초안을 버릴 때 이유 하나를 고르게 하고, 그렇게 모인 이유를 근거로 교환 정책 문서를 기준 자료에 넣는다. 같은 방식이다. 기록은 가볍게 만든다. 고친 사람이 30초 안에 적을 수 없으면 아무도 적지 않는다. 공용 폴더의 표 하나면 충분하고, 고객 이름이나 금액 같은 원문은 98단계 등급표에 맞게 가려서 적는다.

개선안은 이렇게 받는다

모인 기록을 Claude에게 주고 개선안을 받을 때 세 가지를 요구한다. 첫째, 원인별로 묶고 원인마다 건수를 세게 한다. 둘째, 고칠 곳을 파일과 문장으로 적게 한다. "더 공손하게" 같은 제안은 반영할 수 없다. "스킬 3단계 끝에 '거래처 이름 뒤에는 귀하를 붙인다'를 추가"처럼 어느 파일의 어디를 어떻게 바꿀지 전후를 나란히 보여 주게 한다. 셋째, 한 번에 한두 가지만 바꾼다. 다섯 가지를 한꺼번에 바꾸면 점수가 달라져도 무엇 때문인지 알 수 없다. 한 건뿐인 수정은 원인으로 올리지 말고 지켜본다. 한 번의 예외에 맞춰 규칙을 바꾸면 지침에 예외 조항만 쌓인다.

개선안마다 "고치지 말아야 할 이유"도 적게 하면 좋다. 사람마다 판단이 다른 부분이라면 규칙으로 만들지 않고 그대로 두는 편이 낫다.

루프가 바꾸지 못하는 것

루프가 잘 돌면 유혹이 생긴다. 점수만 좋으면 자동으로 반영하게 하고 싶어진다. 하지만 다음 항목은 어떤 경우에도 루프가 스스로 바꾸지 못하게 한다.

가장 확실한 방법은 권한으로 막는 것이다. 개선안을 쓰는 작업에는 수정 기록 읽기와 개선안 문서 쓰기만 허용한다. 스킬 폴더나 CLAUDE.md를 고칠 권한은 주지 않는다. 지시문에 "고치지 마"라고 적는 것보다 권한이 없어서 못 고치는 쪽이 더 믿을 만하다.

개선안이 확인 단계를 줄이자는 쪽으로 기울면 그 자체가 신호다. 확인을 없애면 막힌 지점이 줄어드는 건 사실이지만, 그 확인 단계는 멈추라고 둔 것이다. 이런 제안은 루프 안에서 결정하지 않고 운영 규칙의 주인에게 따로 올린다.

반영하고, 기록하고, 되돌릴 수 있게

반영 기준은 94단계와 같다. 합격 건수가 줄지 않을 것, 새 금지 행동 시도가 없을 것, 전에 합격하던 과제가 떨어졌다면 이유를 설명할 수 있을 것. 점수가 떨어지면 반영하지 않는다.

반영할 때는 이전 판 전체를 날짜를 붙인 이름으로 보관하고, 변경 기록에 날짜, 바꾼 곳, 근거가 된 수정 기록 건수, 평가 전후 결과, 승인한 사람을 적는다. Claude Code와 GitHub로 파일을 관리하는 팀이라면 커밋 기록으로 남기고 되돌려도 좋다(29단계). 반영 뒤 한두 주 사이 현장 수정이 오히려 늘었다면 이전 판으로 돌리고 원인을 다시 본다. 되돌리는 데 5분이 넘게 걸린다면 보관 방식부터 고친다.

주간·월간 루틴으로 돌리기

한 사람의 기억에 기대는 루프는 석 달을 못 간다. 날짜를 정해 둔다.

예약 작업은 초안 문서를 만드는 데서 멈춘다. 파일을 고치거나, 팀 채널에 게시하거나, 메일을 보내는 일은 사람이 한다. 월간 점검에서 평가 세트에 새 실패 유형을 더하는 일도 사람이 한다.

드리프트 신호

루프를 오래 돌리면 조금씩 엉뚱한 방향으로 흘러가기도 한다. 이를 드리프트라고 부른다. 다음 신호가 보이면 루프를 잠시 멈추고 사람이 전체를 다시 본다.

현장 장면

94단계의 문 팀장은 평가 세트를 만든 뒤 한 걸음 더 나간다. 공용 폴더에 수정 기록 표를 만든다. 날짜, 거래처(가상 코드), 고치기 전, 고친 뒤, 이유(형식·사실·말투·빠진 내용·기타 중 선택). 담당자 세 명에게 "고치면 30초만 들여 적어 달라"고 부탁한다.

이어서 Cowork 예약 작업을 하나 만든다. 매주 월요일 아침, 수정 기록 표에서 지난주 행을 읽어 개선안 초안 문서를 쓰는 작업이다. 이 작업에는 수정 기록 폴더 읽기와 개선안 폴더 쓰기만 허용하고, 스킬 폴더는 읽기만 가능하게 둔다.

첫 주 개선안에 원인 세 개가 묶여 나온다. "거래처명 뒤 호칭 누락" 일곱 건, "미수 90일 넘는 거래처에 독촉 문구가 약함" 세 건, "합계 열 위치를 잘못 읽음" 두 건. 개선안은 스킬에 호칭 규칙 한 문장, "합계는 열 위치 대신 '합계'라는 머리글로 찾는다" 한 문장을 넣자고 한다. 두 번째 원인에는 강한 독촉 문구를 제안하면서 "거래 관계에 따라 담당자 판단이 다를 수 있음"이라는 고치지 말아야 할 이유도 붙였다.

화요일, 문 팀장은 첫째와 셋째만 채택한다. 둘째는 담당자가 거래처 사정을 보고 판단할 일이라 규칙으로 만들지 않는다. 두 문장을 넣은 스킬 사본으로 평가 세트를 다시 돌리자 합격이 열넷에서 열여섯으로 늘고, 금지 행동 시도는 없다. 문 팀장은 승인하고, 이전 판을 날짜를 붙여 보관한 뒤 변경 기록에 적는다. "호칭 규칙, 합계 찾는 법 추가. 근거: 수정 기록 9건. 평가 14→16. 승인: 문○○."

셋째 주에는 이상한 제안이 섞여 나온다. "금액 차이가 없는 거래처는 담당자 확인 없이 바로 발송하면 대기 시간이 줄어든다." 문 팀장은 이 제안을 루프 안에서 다루지 않는다. 발송 전 확인은 운영 규칙이 정한 일이고, 루프가 건드릴 수 없다. 대신 예약 작업 지시문에 한 문장을 더한다. "발송·삭제·권한·확인 단계를 바꾸는 제안은 개선안에 넣지 말고 '루프 밖 검토 요청'으로 따로 적어."

두 달 뒤, 수정 기록 표의 주간 행 수는 스무 건 남짓에서 대여섯 건으로 줄었다. 문 팀장은 이 숫자와 센 방법을 함께 적어 분기 사용 보고의 "줄인 일"에 옮긴다.

따라 하기

1. 94단계에서 평가 세트를 만든 작업 하나를 고르고 수정 기록 양식을 만든다. 성공 기준: 열이 다섯 개 이하이고, 이유는 보기에서 고르며, 한 건을 30초 안에 적을 수 있다.
2. 루프가 바꾸지 못하는 항목을 적고, 개선안 작업의 권한을 좁힌다. 성공 기준: 목록이 루프 규칙 문서 맨 위에 있고, 개선안 작업은 기록 읽기와 개선안 문서 쓰기만 할 수 있다.
3. 한두 주 동안 기록을 모은 뒤 아래 프롬프트로 개선안 초안을 받는다. 성공 기준: 원인마다 건수와, 바꿀 파일·문장의 전후가 적혀 있다.
4. 채택할 개선 한두 가지를 사본에 반영하고 94단계 평가 세트로 전후를 비교한다. 성공 기준: 평가 기록 두 장이 있고 반영 기준 세 가지를 확인했다.
5. 통과했으면 승인하고 반영한다. 이전 판을 보관하고 변경 기록을 남긴다. 성공 기준: 이전 판으로 5분 안에 되돌릴 수 있고, 변경 기록에 승인한 사람의 이름이 있다.
6. 수집과 개선안 작성을 주간 예약 작업으로 만들고, 월간 점검을 99단계 월간 확인과 같은 날로 잡는다. 성공 기준: 예약 작업이 개선안 문서를 만드는 데서 멈추고, 월간 점검 항목에 드리프트 신호 확인과 평가 세트 추가가 들어 있다.

복사해 쓰는 프롬프트

너는 개선안만 쓴다. 파일을 직접 고치거나, 게시하거나, 보내지 마.

대상 작업: [예: 주간 미수금 안내 초안 작성]
고칠 수 있는 파일: [예: 스킬 "미수금 안내", 작업 지시문]
바꾸지 못하는 것: 금지 행동 목록, 사람 확인 단계, 권한과 연결자 범위, 데이터 등급 규칙, 평가 세트와 채점 기준
수정 기록: [지난주 수정 기록 표. 이름·금액은 가린 상태]

1. 수정 기록을 원인별로 묶고 원인마다 건수를 세어 줘. 한 건뿐인 원인은 "지켜볼 것"으로 따로 둬.
2. 두 건 이상인 원인마다 고칠 파일, 위치, 바꾸기 전 문장과 바꾼 뒤 문장을 나란히 적어 줘.
3. 제안마다 고치지 말아야 할 이유가 있으면 함께 적어 줘. 사람마다 판단이 다른 부분이면 그렇다고 써.
4. 바꾸지 못하는 것에 해당하는 제안은 개선안에 넣지 말고 맨 아래 "루프 밖 검토 요청"에 따로 적어.
5. 한 번에 반영할 개선은 두 가지 이내로 추천해 줘.
6. 맨 끝에 변경 기록 초안을 남겨 줘: 날짜 | 파일 | 바꿀 내용 | 근거 건수 | 평가 전→후 | 승인. 마지막 두 항목은 비워 둬.
최종 선택과 반영은 사람이 한다.

막히면 이렇게

실습 파일

공개 저장소에 올려 둔 가공 자료와 양식이다. 회사 자료 대신 먼저 이것으로 해 본다.

• 채워 쓰는 양식 개선루프_기록표.md · 수정 기록, 개선안, 전후 비교, 변경 기록, 주간·월간 루틴, 드리프트 신호

스스로 점검

• ☐ 우리 루프에서 개선안을 쓰는 작업이 스킬이나 지침을 직접 고칠 권한을 갖고 있지 않은가
• ☐ 반영 전에 평가 세트로 전후를 비교하고, 점수가 떨어지면 반영하지 않는다는 기준이 적혀 있는가
• ☐ 지난달 반영한 변경을 이전 판으로 되돌리는 방법을 말할 수 있는가

기억할 것

• 자라는 것은 Claude가 읽는 파일과 지시다. 개선안은 Claude가 쓰고, 반영은 사람이 승인한다.
• 금지 행동, 확인 단계, 권한, 평가 세트는 루프가 스스로 바꾸지 못한다. 권한 확대는 절대 자동으로 반영하지 않는다.
• 반영 전에는 평가 세트로 비교하고, 반영할 때는 이전 판과 변경 기록을 남긴다.