같은 설명을 두 번 하지 않는 법 — AI에게 반복 업무를 넘기는 실전 순서

AI에게 일을 시키다 보면 이상한 지점에서 시간이 샙니다. 결과물을 고치는 시간이 아니라, 매번 같은 설명을 다시 하는 시간입니다. 주보 문안은 이런 톤으로, 보고서는 이 형식으로, 공지는 이 순서로. 지난주에도 했고 그 전 주에도 했던 말입니다.
이 반복은 AI가 기억을 못 해서 생기는 문제로 보이지만, 실제로는 설명을 어디에 둘 것인가의 문제입니다. 오늘은 그 자리를 만드는 순서를 정리합니다.
1. 후보를 고르는 기준은 하나입니다
무엇을 먼저 정리해야 할지 고민할 필요는 없습니다. 매주 같은 말을 하고 있다면 그것이 첫 후보입니다.
반대로, 매번 다르게 판단해야 하는 일은 후보가 아닙니다. 상황에 따라 답이 달라지는 일을 규칙으로 고정하면, 그 규칙이 판단을 대신하면서 이상한 결과가 나옵니다. 정리할 것은 판단이 아니라 형식입니다. 톤, 순서, 형식, 금지 표현. 이런 것들은 매번 같아야 정상입니다.
한 주간 자신이 AI에게 보낸 지시를 훑어보면 후보가 보입니다. 문장이 거의 같은 것끼리 묶으면 그게 목록입니다.
2. 지침 파일과 스킬은 다릅니다
여기서 두 가지 방식이 갈립니다.
지침 파일은 항상 앞에 붙이는 것입니다. “우리 조직의 문서는 이렇게 씁니다”를 다섯 줄 적어 두고 매번 함께 넣습니다. 짧고 늘 필요한 규칙에 맞습니다.
스킬은 필요할 때 불려 오는 것입니다. Anthropic은 이 방식을 Agent Skills라는 이름으로 정리했습니다(엔지니어링 문서, 2025년 10월 16일 게시). 새로 나온 기능이라서가 아니라, 지금 반복 설명으로 막히는 자리에 그대로 쓰이는 개념이라 가져옵니다. 해당 문서는 이렇게 정의합니다. “organized folders of instructions, scripts, and resources that agents can discover and load dynamically to perform better at specific tasks” — 에이전트가 스스로 찾아서 필요할 때 불러오는, 지시·스크립트·자료를 담은 폴더라고 설명합니다.
차이는 불려 오는 시점입니다. 같은 문서에서 이들은 이 구조를 **“progressive disclosure”**라 부르며, “it provides just enough information for Claude to know when each skill should be used without loading all of it into context” — 언제 써야 할지 알 만큼만 먼저 보여 주고, 전부를 미리 읽히지는 않는다고 적습니다.
이 구분이 실무에서 중요한 이유는 간단합니다. 항상 붙이는 규칙이 길어지면 정작 중요한 규칙이 묻힙니다. 자주 쓰지 않는 규칙은 항상 붙이는 대신 따로 두고, 필요할 때 꺼내 쓰는 편이 낫습니다.
여기서 한 가지 정확히 해 둘 것이 있습니다. 메모장 파일을 하나 만들어 두는 것만으로 스킬이 되지는 않습니다. 같은 문서에 따르면 스킬은 SKILL.md 파일을 가진 폴더 형태이고, 그 파일 첫머리에 **이름과 설명(무엇을 하는 스킬이고 언제 쓰는지)**이 적혀 있어야 합니다. 그 설명이 있어야 AI가 **“지금 이걸 꺼내 쓸 때”**를 스스로 판단할 수 있기 때문입니다. 설명이 없으면 폴더는 있지만 아무도 부르지 않는 규칙이 됩니다.
최소 형태는 이 정도입니다. 폴더 하나를 만들고 그 안에 SKILL.md를 둡니다. 파일 맨 위에 이름과 한 줄 설명(예: “주보 문안 규칙 — 주보·공지 문안을 작성하거나 검토할 때 사용”)을 적고, 그 아래에 규칙 다섯 줄을 씁니다. 그게 전부입니다. 형식이 거창해서가 아니라, 이름과 설명이 있어야 불려 나오기 때문에 이 두 가지는 빼지 않는 편이 좋습니다.

같은 모양의 그릇 여럿과 다른 모양 하나. 대체로 고정해도 되는 것은 형식 쪽이고, 판단은 남겨 두는 편이 낫다.
3. 처음 만들 세 가지
작은 조직이라면 다음 셋으로 시작하기를 권합니다. 셋 다 판단이 아니라 형식이고, 매주 반복되는 일입니다.
첫째, 문안 규칙. 우리 조직이 쓰는 말과 쓰지 않는 말을 적습니다. 호칭, 날짜 표기, 금지 표현. 다섯 줄이면 충분합니다. 길게 쓰면 지켜지지 않습니다.
둘째, 보고 형식. 무엇을 어떤 순서로 적을지 정합니다. 예를 들어 “무엇을 했다 / 무엇이 남았다 / 무엇을 못 했다” 세 줄 형식입니다. 형식이 정해지면 받는 사람이 읽는 속도가 달라집니다.
셋째, 확인 목록. 밖으로 나가기 전에 볼 것들입니다. 날짜가 맞는가, 이름이 맞는가, 링크가 열리는가. 이 목록은 실수가 날 때마다 한 줄씩 늘어납니다.
세 가지를 만들 때 순서도 중요합니다. 가장 자주 쓰는 것부터 만듭니다. 완성도가 아니라 사용 빈도가 기준입니다. 자주 쓰는 규칙은 며칠 안에 스스로 다듬어지지만, 어쩌다 쓰는 규칙은 만들어 두고도 낡은 채로 남습니다.
여기서 한 가지 실무 요령이 있습니다. 처음부터 완성하려 하지 말고, 한 번 쓰고 고칩니다. 실제로 써 보면 빠진 것이 보이고, 그때 고친 것이 진짜 규칙입니다. 머릿속에서 미리 완성한 규칙은 대개 현장과 맞지 않습니다.
4. 맥락은 많이 넣는 게 아니라 고르는 것입니다
이 이야기는 결국 무엇을 AI에게 보여 줄 것인가로 이어집니다.
Anthropic의 다른 엔지니어링 문서(2025년 9월 29일 게시)는 이 문제를 이렇게 정의합니다. “Context is a critical but finite resource for AI agents.” 맥락은 중요하지만 유한한 자원이라는 것입니다. 그래서 목표도 “많이 넣기”가 아니라, “the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome” — 원하는 결과가 나올 가능성을 가장 높이는 가장 작은 묶음을 고르는 일이라고 적습니다.
실무로 옮기면 이렇습니다. 지난 회의록 열 개를 통째로 붙이는 대신, 그중 결정된 세 줄만 골라 붙이는 방식이 있습니다. 어느 쪽이 항상 낫다고 말할 근거는 이 글에 없습니다 — 다만 무엇을 넣을지 고르는 일 자체가 작업의 일부라는 점은 위 문서가 말하는 바와 같습니다. 넣을 자료가 많다면, 그중 무엇이 이번 판단에 실제로 쓰이는지 먼저 정하는 편이 안전합니다.
이 원리는 앞의 두 방식과도 이어집니다. 항상 붙이는 지침이 길어질수록 그 안의 중요한 규칙은 다른 문장들 사이에 묻힙니다. 그래서 규칙을 늘리는 대신 자리를 나누는 것이 낫습니다. 늘 필요한 다섯 줄은 지침에, 특정 작업에서만 필요한 열 줄은 따로 두고 그때 꺼내는 식입니다.

선반은 넘치는데 책상 위에는 세 권뿐이다. 실제로 꺼내 쓰이지 않는 규칙은 자산보다 부담이 되기 쉽다.
5. 규칙은 낡습니다 — 만든 쪽이 먼저 말합니다
한 가지 더 붙일 것이 있습니다. 규칙을 만들어 두면 그것이 계속 맞을 것 같지만, 실제로는 도구가 좋아지면서 규칙이 먼저 낡습니다.
Anthropic이 2026년 4월에 낸 문서는 이 문제를 자기 사례로 적었습니다. “harnesses encode assumptions about what Claude can’t do on its own” — 규칙은 결국 “이 모델이 혼자서는 못 한다”는 가정을 담고 있고, 그래서 “those assumptions need to be frequently questioned because they can go stale as models improve” — 모델이 좋아지면 그 가정이 낡기 때문에 자주 다시 물어야 한다는 것입니다. 실제로 이전 모델에서 필요했던 보정 장치가 다음 모델에서는 불필요한 짐이 됐다고 적습니다.
우리 규칙도 같습니다. “이건 AI가 잘 못하니 이렇게 시켜라”로 만든 규칙은, 도구가 바뀌면 그 이유가 사라진 채 문장만 남습니다. 그래서 규칙에는 만든 날짜를 적어 두고, 반년쯤 지나면 **“이 규칙이 왜 생겼는지”**를 한 번 되짚는 편이 좋습니다.
6. 균형 — 많이 만들수록 좋아지지 않습니다
정직하게 붙일 절반이 있습니다.
규칙을 만들기 시작하면 재미가 붙어서 자꾸 늘리게 됩니다. 그런데 쓰이지 않는 규칙은 자산이 아니라 부담입니다. 관리해야 할 문서가 늘고, 서로 충돌하기 시작하면 어느 것이 맞는지 확인하는 데 시간이 더 듭니다.
기준을 하나 두면 좋습니다. 한 달 동안 한 번도 불려 나오지 않은 규칙은 지웁니다. 지워도 필요하면 다시 만들면 됩니다. 남겨 두는 비용이 다시 만드는 비용보다 큰 경우가 많습니다.
그리고 이 글에서 인용한 방식은 특정 도구에서 정리된 개념입니다. 도구마다 이름과 동작이 다르고, 우리 조직에 그대로 옮겨진다는 보장은 없습니다. 옮길 수 있는 것은 **“항상 붙이는 것과 필요할 때 꺼내는 것을 나눈다”**는 원리이고, 구현은 각자의 도구 안에서 확인해야 합니다.
7. 오늘 할 일 세 가지
- 지난 한 주 AI에게 보낸 지시를 훑어보고 문장이 거의 같은 것 세 개를 찾습니다.
- 그중 하나를 골라 다섯 줄 규칙으로 적습니다. 판단이 아니라 형식만 적습니다.
- 다음에 같은 일을 할 때 그 다섯 줄을 먼저 붙이고 시작합니다. 부족한 부분이 보이면 그때 한 줄 늘립니다.
마치며
반복 설명이 사라지면 시간이 남을 것 같지만, 실제로 달라지는 것은 일의 종류입니다. 같은 설명을 다시 하는 대신, 무엇을 규칙으로 남길지 고르는 일이 생깁니다.
이번 주에 같은 말을 세 번 이상 한 적이 있다면, 그 문장을 그대로 적어 두는 것에서 시작하면 됩니다. 그 다섯 줄이 첫 번째 규칙이 됩니다.
참고자료 (검증 출처)
-
Anthropic Engineering — Equipping agents for the real world with Agent Skills — 원문에서 직접 확인: Agent Skills의 정의(“organized folders of instructions, scripts, and resources that agents can discover and load dynamically”),
SKILL.md구조, progressive disclosure(언제 써야 할지 알 만큼만 먼저 보여 주고 전부를 컨텍스트에 올리지 않는다), 그리고 composable·scalable·portable이라는 설계 목표. -
Anthropic Engineering — Effective context engineering for AI agents — 원문에서 직접 확인: “Context is a critical but finite resource for AI agents” · 목표는 “the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome”.
-
Anthropic Engineering — Scaling Managed Agents: Decoupling the brain from the hands (Published Apr 08, 2026) — 원문에서 직접 확인: “harnesses encode assumptions about what Claude can’t do on its own” · “those assumptions need to be frequently questioned because they can go stale as models improve” · 이전 모델에서 필요했던 보정(컨텍스트 리셋)이 다음 모델에서는 불필요해졌다는 자사 사례.
불확실 항목 명시
- Agent Skills·컨텍스트 엔지니어링의 정의는 2025년 9~10월 문서를 따릅니다. 이 글은 이를 “최신 발표”로 제시하지 않고 개념 정의의 출처로만 쓰며, 2026년 4월 문서로 현행성을 확인했습니다(정의가 뒤집힌 것은 아니고, 규칙이 낡는다는 논의가 더해졌습니다).
- 인용한 개념은 Anthropic 제품 문서에서 정리된 것입니다. 다른 AI 도구에 같은 이름·같은 동작의 기능이 있다는 근거는 확인하지 못했습니다 — 옮길 수 있는 것은 원리이며 구현은 도구별로 확인해야 합니다.
- 본문의 “처음 만들 세 가지”와 “한 달 동안 불려 나오지 않으면 지운다”는 필자의 운영 기준이며, 인용한 문서가 제시한 수치나 권고가 아닙니다.
본 글은 공개된 1차 자료와 필자의 운영 경험을 기반으로 하며 정보 제공·교육 목적입니다.