매번 새로 시작하는 대화의 비용

AI를 업무에 써 본 사람이라면 누구나 겪는 장면이 있다. 지난주에 공들여 만든 보고서 초안을 떠올려 보자. 그때 AI에게 "이런 톤으로, 이 순서대로, 이 항목은 빼고"라고 몇 번이나 고쳐 말한 끝에 겨우 마음에 드는 결과를 얻었다. 그런데 이번 주에 같은 종류의 보고서를 만들려고 새 창을 열면, 지난주의 그 대화는 온데간데없다. 처음부터 다시 설명해야 한다. 옆자리 동료도 똑같은 작업을 하면서, 또 자기만의 방식으로 처음부터 설명하고 있다.

AI는 충분히 좋은 결과물을 내놓지만, 그 답을 만들어 낸 방법과 프롬프트 요령은 개인의 채팅 기록 속에 흩어져 사라진다. 그래서 조직은 똑같은 시행착오를 사람 수만큼 반복하게 된다.
남는 결과물, 사라지는 방법

문제는 결과물의 품질이 아니다. AI는 충분히 좋은 답을 내놓는다. 진짜 문제는 따로 있다. 그 좋은 답을 만들어 낸 '방법'이 어디에도 남지 않는다는 것이다. 개인이 쌓은 프롬프트 요령은 채팅 기록 속에 흩어져 사라진다. 조직 차원에서는 똑같은 시행착오를 사람 수만큼 반복한다. 일 잘하는 사람의 노하우가 옆 사람에게 전해지지 않는 구조 — 사실 이건 AI가 등장하기 훨씬 전부터 있던 오래된 문제와 똑 닮았다.

'무엇을'이 아니라 '어떻게'를 저장한다

CLAUDE.md가 프로젝트 전체에 두루 적용되는 규칙·메모리, 즉 '헌법'이라면, 클로드 스킬(SKILL.md)은 특정 작업을 위한 플레이북, 즉 '경기 전술'이다. AI 업무 표준화가 진짜 힘을 발휘하는 곳은 대개 반복되는 개별 작업의 플레이북 쪽이다.
CLAUDE.md는 헌법, 스킬은 전술

그래서 요즘 주목받는 접근이 바로 AI 업무 표준화다. 발상은 의외로 단순하다. 반복되는 작업의 절차를 사람이 매번 말로 되풀이하는 대신, 한 번 문서로 정의해 두는 것이다. 그러면 AI가 그 정의를 불러와 언제나 같은 방식으로 작업을 처리한다.

앤스로픽이 2025년 10월 공개한 클로드 스킬(Claude Skills)이 이 발상을 눈에 보이게 구현한 사례다. 앤스로픽은 스킬을 "에이전트가 특정 작업을 더 잘 해내도록 필요할 때 불러오는, 지침·스크립트·자료를 담은 폴더"로 설명한다. 비개발자를 겨냥한 한 실무 가이드는 같은 구조를 더 짧게 요약한다. "반복적인 AI 작업이나 특정 업무 절차를 SKILL.md로 정의해 일관된 방식으로 작업을 수행하도록 만드는 구조"라는 것이다. 회의록을 정리하는 방식, 계약서를 검토할 때 훑어야 할 체크리스트, 마케팅 카피의 톤 규칙 — 이런 것들을 그때그때 프롬프트로 풀어내는 대신, 하나의 파일에 절차로 박아 두는 셈이다.

여기서 흔히들 헷갈리는 대목을 하나 짚고 가자. 프로젝트 전체에 두루 적용되는 규칙과, 특정 작업 하나를 위한 절차는 서로 다른 것이다. 예를 들어 클로드 코드가 세션마다 먼저 읽어 들이는 CLAUDE.md가 앞의 것, 즉 프로젝트 전반의 규칙·메모리에 해당한다. 두 파일을 나란히 놓고 비교한 한 기술 글은 그 차이를 이렇게 정리한다. "CLAUDE.md가 프로젝트 전체 규칙이라면, 스킬은 특정 작업을 위한 플레이북"이라고. 말하자면 앞의 것이 '우리 조직은 늘 이렇게 한다'는 헌법이라면, 뒤의 것은 '이 작업은 이 순서로 처리한다'는 경기 전술에 가깝다. AI 업무 표준화가 진짜 힘을 발휘하는 곳은 대개 뒤쪽, 즉 반복되는 개별 작업의 플레이북이다.

표준화가 실제로 바꾸는 세 가지

작업 절차를 한 번 정의해 두고 계속 재사용한다 — 언뜻 보면 그저 편해지자는 이야기 같다. 하지만 조직의 눈으로 보면, 성격이 전혀 다른 세 가지 변화가 일어난다.

AI 업무 표준화는 성격이 다른 세 가지를 바꾼다. 노하우가 개인에게서 조직의 공동 자산으로 옮겨 가고, 사람마다 달랐던 결과물의 편차가 줄어들며, 정의 파일 한 줄만 고치면 조직 전체의 일하는 방식이 한 번에 바뀐다.
표준화가 바꾸는 세 가지

첫째, 노하우가 개인에게서 조직으로 옮겨 간다. 일 잘하는 담당자의 프롬프트 요령이 그 사람의 채팅 기록 속에만 갇혀 있지 않고, 팀 누구나 불러다 쓸 수 있는 공동 자산이 된다. 신입이 입사 첫날, 선임이 오래 쌓은 요령을 그대로 물려받는 셈이다.

둘째, 결과물의 편차가 줄어든다. 같은 작업을 열 사람이 하면 열 가지 결과가 나오던 것이, 정의된 절차를 함께 쓰면 품질의 바닥이 올라간다. 표준화의 본질은 '최고를 만드는 것'이 아니라, 누가 하더라도 일정 수준 이상을 보장하는 것이다.

셋째, 개선의 단위가 바뀐다. 절차가 문서로 남아 있으면, 그 문서 하나만 고쳐도 조직 전체의 일하는 방식이 한 번에 바뀐다. 검토 기준이 달라졌을 때 백 명에게 일일이 다시 공지할 것 없이, 정의 파일의 한 줄만 수정하면 된다.

도구가 아니라 규율의 문제

SKILL.md 같은 형식은 표준화를 가능하게 할 뿐 저절로 이뤄지게 하지는 않는다. 계속 돌보는 정의 파일은 매주 시간을 아끼는 공동 자산이 되지만, 방치된 파일은 모두가 믿지만 실제로는 틀린 '가장 위험한 자산', 곧 부채가 된다. 그래서 AI 업무 표준화는 도구가 아니라 조직의 규율 문제다.
도구가 아니라 규율의 문제

다만 냉정하게 봐야 할 지점이 있다. SKILL.md 같은 형식은 표준화를 '가능하게' 해 줄 뿐, '저절로 이뤄지게' 해 주지는 않는다. 문서가 살아 있으려면 누군가 계속 돌봐야 한다. 절차는 바뀌었는데 정의 파일이 그대로 방치되면, 그 문서는 가장 위험한 종류의 자산으로 변한다. 모두가 믿고 따르지만 실제로는 틀린 지침이 되기 때문이다. 실제로 클로드 코드 문서조차 규칙 파일이 지나치게 길거나 방치되면 '가이드'가 아니라 '부채'가 된다고 경고한다.

그래서 AI 업무 표준화는 도구를 들이는 문제라기보다, 조직의 규율에 가까운 문제다. 어떤 작업을 표준화 대상으로 삼을지, 정의 파일의 주인은 누구인지, 언제 갱신할지 — 이런 운영 원칙이 없으면 아무리 잘 만든 스킬도 반년 뒤엔 아무도 손대지 않는 유물이 되고 만다. 반대로 이 규율이 자리 잡은 조직에서는, 매번 처음부터 다시 시키던 AI 작업이 조금씩 쌓여 가는 공동의 자산으로 바뀐다.

정리하며

"매번 처음부터 다시 시키던 AI 작업을, 한 번 정의해 두고 함께 재사용할 수 있을까?" 이 질문에 대한 답은, 기술적으로는 이미 '그렇다'이다. 스킬 같은 구조가 그 방법을 마련해 준다. 이제 남은 것은 하나다. 조직이 그 방법을 규율로 만들어 낼 의지가 있는가.

작게 시작하기를 권한다. 팀에서 가장 자주 반복되는 AI 작업 하나를 골라, 그 절차를 문서 한 장에 정의해 보는 것이다. 그렇게 정의한 절차가 처음 재사용되는 순간, 표준화는 추상적인 구호가 아니라 매주 아껴지는 시간으로 비로소 손에 잡히기 시작한다.

출처 · 참고

참고 문헌

이미지 출처