AI 업무 지식 관리, 반복 지적을 에이전트 기준으로 쓰고 갱신하기

AI 업무 지식 관리는 반복된 지적을 기준 한 건으로 쓰는 데서 시작합니다. 기준은 지켰는지 예·아니요로 판정할 수 있어야 하고, 한 범위에만 넣어 승인합니다. 승인 뒤에는 시험 실행으로 적용을 확인합니다. 이후 정기 점검으로 고치거나 대체 기록과 함께 폐기합니다.

목표는 기준을 많이 쌓는 것이 아닙니다. 짧고 서로 부딪히지 않는 기준만 남기는 것입니다.

업무 기준 문서에는 무엇을 넣고 무엇을 따로 두어야 하나요?

업무 기준 문서에는 매번 지킬 규칙만 넣고, 참고 자료와 작업 기록은 따로 둡니다. 세 가지는 갱신 주기와 책임자가 다르기 때문입니다.

Anthropic의 Claude Code 문서도 두 가지를 구분합니다. 사람이 쓰는 지시 파일에는 「지시와 규칙」을 담습니다. 에이전트가 스스로 적는 메모에는 「학습한 내용과 패턴」을 담습니다.

Microsoft Copilot Studio 문서는 지식 원천(knowledge source)이라는 층을 설명합니다. 공개 웹사이트나 업로드한 문서 같은 회사 자료를 에이전트 답변의 근거로 쓰는 기능입니다. 사내 문서 공유 서비스도 연결할 수 있습니다.

업무 기준은 승인을 거쳐 바뀝니다. 참고 자료는 원본이 바뀔 때 함께 바뀌고, 작업 기록은 일이 끝나면 정리합니다. 세 가지를 한 문서에 섞으면 어느 문장이 언제 낡았는지 가려내기 어렵습니다.

1~2단계: 어떤 지적을 기준으로 올리고, 한 건은 어떻게 적나요?

1단계. 반복된 지적만 후보로 모읍니다

Claude Code 문서는 지시 파일에 내용을 더할 때로 네 경우를 듭니다. 에이전트가 같은 실수를 두 번째로 할 때, 알았어야 할 내용을 검토에서 지적받을 때입니다. 지난번과 같은 정정을 다시 입력할 때, 새 팀원에게도 같은 설명이 필요할 때도 해당합니다.

Anthropic의 컨텍스트 엔지니어링 글은 최소한의 지시로 시작하라고 권합니다. 그다음 시험에서 발견한 실패에 맞춰 지시와 예시를 더하라고 합니다. 마케팅 업무에서는 위 네 경우를 후보 수집 기준으로 씁니다. 한 번뿐인 지적, 특정 고객 한 건의 사정, 담당자 연락처 같은 개인 정보는 후보에서 뺍니다.

완료 조건: 후보마다 원래 지적 문장과 발언자·날짜가 붙어 있습니다. 같은 지적이 몇 번 나왔는지도 표시되어 있습니다.

2단계. 한 건을 판정할 수 있는 문장으로 씁니다

Claude Code 문서는 지시가 구체적이고 간결할수록 에이전트가 더 일관되게 따른다고 설명합니다. 「코드를 잘 정리한다」 대신 「들여쓰기는 공백 2칸」처럼 검증할 수 있게 쓰라는 예를 듭니다. 컨텍스트 엔지니어링 글도 예외 규칙을 모두 나열하는 방식은 권하지 않습니다. 대신 기대하는 행동을 보여 주는 대표 예시를 고르라고 합니다.

한 건은 다음 여섯 칸으로 적습니다.

1. 제목: 지킬 행동을 한 문장으로 씁니다.
2. 적용 조건: 이 기준을 언제 쓰는지 적습니다.
3. 사실: 기준이 생긴 배경을 적습니다.
4. 조치: 에이전트가 할 일을 확인 가능한 동작으로 적습니다.
5. 원문: 지적한 사람의 발언이나 검수 기록을 그대로 붙입니다.
6. 범위와 기한: 적용 범위, 기준일, 재확인 예정일을 적습니다.

예를 들어 가상의 마케팅팀이 월간 보고서 기준을 만든다면 여섯 칸은 다음과 같습니다. 칸 이름과 작성 예를 그대로 옮겨 양식으로 쓸 수 있습니다.

「조치」 칸은 동사로 끝나는 행동이어야 합니다. 「품질에 유의한다」처럼 지켰는지 판단할 수 없는 문장은 다시 씁니다.

완료 조건: 다른 담당자가 이 한 건만 읽고 산출물이 기준을 지켰는지 예·아니요로 판정할 수 있습니다.

3단계: 기준의 적용 범위와 보관 위치는 어떻게 정하나요?

기준 한 건은 한 범위에만 둡니다. Claude Code 문서는 지시 파일을 조직·개인·프로젝트 같은 범위로 나눕니다. 여러 범위의 파일은 서로 덮어쓰지 않고 이어 붙여 읽힌다고 설명합니다.

문서는 두 지시가 충돌하면 에이전트가 어느 한쪽을 임의로 고를 수 있다고 덧붙입니다. 상위와 하위 범위에 반대 기준이 함께 있으면 어느 쪽이 적용될지 알 수 없다는 뜻입니다. 같은 문서는 파일 하나를 200줄 안쪽으로 유지하라고도 권합니다. 파일이 길수록 지시를 지키는 정도가 떨어진다는 이유입니다.

마케팅 업무에서는 범위를 회사 공통·역할별·고객별 세 가지로 나누어 운영합니다.

고객별 기준을 회사 공통에 올리면 다른 고객 작업에도 적용됩니다. 반대로 공통 기준을 고객 문서에 복사하면, 공통 기준이 바뀔 때 복사본만 옛 내용으로 남습니다. 다른 곳에서 필요하면 복사하지 않고 원래 위치를 가리키게 합니다.

완료 조건: 새 기준이 한 범위에만 들어갔습니다. 같은 범위와 상위 범위에 반대되는 기준이 없다는 것도 대조했습니다.

4단계: 승인한 기준이 실제로 적용되는지 어떻게 확인하나요?

승인 직후 기준이 걸리는 작업 하나를 시험 실행해 판정합니다. 지시 문서는 행동을 이끌 뿐 강제 장치가 아니기 때문입니다. Claude Code 문서도 지시 파일은 강제 설정이 아니라 맥락이라고 설명합니다. 반드시 막아야 하는 동작은 별도 설정으로 막으라고 안내합니다.

마케팅 업무로 옮기면 게시·발송·사이트 설정 변경은 에이전트 계정 권한으로 막습니다. 문체·표기·수치 출처 같은 기준은 지시 문서에 둡니다. Anthropic의 에이전트 구축 글은 격리된 시험 환경에서 충분히 시험하고 적절한 안전장치를 두라고 권합니다.

적용 확인은 다음 순서로 진행합니다.

1. 에이전트에게 지금 적용 중인 기준 목록을 말하게 해 새 기준이 들어 있는지 봅니다. 도구에 불러온 지시 파일 목록을 보여 주는 화면이 있으면 함께 확인합니다.
2. 기준이 걸리는 작업 하나를 고릅니다. 예) 지난달 보고서를 같은 원자료로 다시 작성하게 합니다.
3. 산출물을 2단계에서 정한 예·아니요 판정으로 검수합니다.
4. 기준을 어기면 아래 표로 원인을 찾습니다.

완료 조건: 시험 작업의 산출물이 새 기준 판정을 통과했습니다. 그 결과를 기준 한 건에 적용 확인일로 적었습니다.

5~6단계: 기준은 언제 고치고, 언제 폐기하나요?

정해진 주기에 점검해 낡거나 충돌하는 기준은 고쳐 쓰고, 쓸모가 끝난 기준은 대체 기록과 함께 폐기합니다. Claude Code 문서는 지시 파일을 주기적으로 검토해 오래되었거나 충돌하는 지시를 지우라고 안내합니다.

같은 문서는 이 검토를 에이전트에게 맡기는 점검 기능도 소개합니다. 결과는 수정안이 담긴 보고로 나옵니다. 사용자가 적용을 요청하기 전에는 파일이 바뀌지 않는다고 설명합니다. 점검은 에이전트에게 맡기고, 수정은 사람이 승인한 뒤 반영하는 구조입니다.

Anthropic의 메모리 도구 문서는 오래 열람되지 않은 메모리 파일을 주기적으로 지우라고 권합니다. 민감 정보는 저장하기 전에 걸러 내는 검증을 두라고도 합니다.

5단계. 정기 점검으로 고칩니다

점검 주기를 월 1회처럼 정하고 다음 항목을 확인합니다.

1. 재확인 예정일이 지난 기준이 있는지
2. 같은 행동에 서로 다른 지시를 하는 기준이 짝으로 있는지
3. 이미 없어진 도구·화면·담당자를 가리키는 기준이 있는지
4. 참고 자료 원본은 바뀌었는데 기준 문장에 옛 값이 남아 있는지
5. 일부 작업에만 필요한 절차가 공통 범위에 섞여 문서가 길어졌는지

4번 항목은 참고 자료 층과 이어집니다. Microsoft Copilot Studio 문서는 지식 원천의 정보가 시간에 따라 어떻게 바뀔지 늘 통제할 수는 없다고 설명합니다. 그래서 엄격한 검증 절차를 거치는 원천만 공식 원천으로 표시하도록 안내합니다. 이 방식을 따라 참고 자료도 검증 절차가 있는 원본만 공식으로 표시합니다. 그 원본이 바뀌면 그 값을 인용한 기준 문장도 함께 확인합니다.

점검이 쉬우려면 기준마다 날짜가 있어야 합니다. Claude Code 문서도 에이전트가 쓴 메모 파일에 기록 시각을 남긴다고 설명합니다. 그 시각으로 사람과 에이전트 모두 그 사실이 얼마나 최신인지 알 수 있다는 것입니다.

고칠 때는 기존 기준 아래에 새 문장을 덧붙이지 않고 원래 기준을 고쳐 씁니다. 판 번호를 올리고, 바뀐 이유와 원문 지적을 함께 남깁니다. 덧붙이기만 하면 옛 문장과 새 문장이 함께 남아 3단계에서 본 충돌이 생깁니다.

완료 조건: 다섯 점검 항목에 걸린 기준이 0건이거나, 걸린 건마다 수정·폐기 결정이 적혀 있습니다.

6단계. 폐기는 대체 기록과 함께 합니다

기준을 지울 때는 무엇이 그 자리를 대신하는지 함께 적습니다. 예를 들어 「표 머리줄은 진한 색」을 「표 머리줄은 밝은 회색」으로 바꾼다고 가정합니다. 이때 새 기준에 「이전 기준을 대체함」과 변경일을 씁니다.

대체 기록은 에이전트가 지난 대화나 옛 작업 기록에서 폐기된 기준을 다시 꺼내 쓸 가능성을 줄이는 실무 보완책입니다. 반드시 막아야 하는 동작이라면 4단계처럼 권한으로 막습니다.

고객 계약이 끝나거나 권한이 회수되면 그 고객 범위의 기준과 작업 기록을 함께 정리합니다. 옛 고객의 표기 규칙이 다른 고객 작업에 섞여 들어가는 일을 막기 위해서입니다.

완료 조건: 폐기한 기준이 에이전트가 읽는 위치에서 빠졌습니다. 대체 기준에는 이전 기준과 변경일이 적혀 있습니다.

정리

1. 최근 한 달 검수 기록에서 두 번 이상 나온 지적을 골라 후보 목록을 만듭니다.
2. 후보마다 제목·적용 조건·사실·조치·원문·범위와 기한의 여섯 칸 양식으로 한 건씩 씁니다.
3. 회사 공통·역할별·고객별 가운데 한 범위에만 넣고, 상위 범위와 충돌하는지 대조합니다.
4. 기준이 걸리는 작업 하나를 시험 실행해 예·아니요로 판정하고 적용 확인일을 적습니다.
5. 점검 주기를 정해 기한·충돌·옛 참조를 확인하고, 고친 기준에는 판 번호를, 폐기한 기준에는 대체 기록을 남깁니다.

참고 자료

• How Claude remembers your project (Anthropic Claude Code 문서, 확인일 2026-10-22)
• Memory tool (Anthropic Claude Platform 문서, 확인일 2026-10-22)
• Effective context engineering for AI agents (Anthropic Engineering, 확인일 2026-10-22)
• Building effective agents (Anthropic Engineering, 확인일 2026-10-22)
• Knowledge sources summary - Microsoft Copilot Studio (Microsoft Learn, 확인일 2026-10-22)