AI 에이전트가 읽기 좋은 회사 지식은 어떻게 만들어야 할까: SOP, 예외, 판단 기준, 금지사항 정리법

1. 개요: 문서 업로드는 지식 설계가 아닙니다

첫 AI 에이전트 업무를 고른 뒤 팀이 묻는 다음 질문은 보통 이겁니다. "에이전트가 무엇을 읽게 할까?" 쉬운 답은 위키, 드라이브 폴더, Notion 페이지, Slack 요약, 예전 회의록을 전부 넣는 것입니다. 하지만 이렇게 하면 에이전트가 단어는 찾는데 판단은 못 하는 상태가 자주 생깁니다.

OpenAI의 file search 문서는 문서를 파싱하고, chunk로 나누고, embedding을 만들고, keyword search와 semantic search를 함께 쓰고, 관련 결과를 다시 정렬해 답변에 쓰는 흐름을 설명합니다. Google과 Microsoft도 에이전트를 지정된 데이터 소스로 grounding하는 방식을 설명합니다. 이런 시스템은 검색을 가능하게 합니다. 하지만 회사 지식 자체가 명확하고 최신이고 권한에 맞고 판단 가능한 형태인지는 보장하지 않습니다.

운영자 입장에서의 실무 규칙은 단순합니다. 지식 소스를 에이전트에 연결하기 전에 그 업무를 읽을 수 있는 운영 카드로 바꾸세요. 이 카드는 workflow의 목적, 처리 절차, 중요한 예외, 사람에게 물어야 하는 기준, 절대 하면 안 되는 행동, 각 규칙의 출처를 보여줘야 합니다.

2. AI가 읽기 좋은 회사 지식의 다섯 요소

AI가 읽기 좋은 지식에는 다섯 요소가 있습니다. 첫째는 목적입니다. 이 workflow가 왜 있고 좋은 결과가 무엇인지입니다. 둘째는 절차입니다. 숙련된 직원이 평소에 밟는 단계입니다. 셋째는 예외입니다. 정상 규칙이 깨지는 경우입니다.

넷째는 판단 기준입니다. 여러 선택지 중 어디로 갈지 정하는 신호입니다. 다섯째는 금지사항입니다. 사용자가 요청해도, 데이터가 보여도, 모델이 자신 있어 보여도 에이전트가 하면 안 되는 행동입니다.

이게 중요한 이유는 에이전트가 단순히 답변만 하지 않기 때문입니다. 에이전트는 분류하고, 라우팅하고, 초안을 쓰고, 요약하고, 추천하고, 때로는 tool을 호출합니다. 지식이 "환불은 조심해서 처리"라고만 되어 있으면 에이전트는 운영 경계를 모릅니다. "이 조건에서는 환불 문구만 초안 작성, 이 금액 이상은 에스컬레이션, 승인이 없으면 환불 실행 금지"라고 쓰면 훨씬 안전한 범위 안에서 일할 수 있습니다.

• 목적: 비즈니스 결과와 품질 기준.
• 절차: 정상적인 단계별 처리 경로.
• 예외: 특이 고객, 정책 충돌, 누락 정보, 경계 사례.
• 판단 기준: 어떤 경로를 고를지 정하는 신호.
• 금지사항: 승인이나 에스컬레이션 없이 하면 안 되는 행동.

3. 쉬운 용어 정리: SOP, CLAUDE.md, RAG, grounding, citation, freshness

SOP는 standard operating procedure의 줄임말입니다. 쉽게 말하면 회사의 업무 레시피입니다. 좋은 SOP는 체크리스트만이 아닙니다. 목적, 예시, 예외, 승인 기준, 애매할 때의 처리법까지 함께 들어 있어야 합니다.

CLAUDE.md 같은 파일은 AI briefing입니다. 프로젝트의 안정적인 규칙을 AI에게 알려줍니다. 팀이 어떻게 일하는지, 어떤 명령이 중요한지, 어떤 스타일을 따라야 하는지, 어떤 위험을 피해야 하는지, 어떤 파일을 봐야 하는지 적는 문서입니다. 다만 이것은 맥락이지 강제 장치가 아닙니다. 권한, 승인, 로그, eval은 여전히 필요합니다.

RAG는 retrieval-augmented generation의 줄임말입니다. 비즈니스 언어로는 AI가 답하기 전에 회사 지식을 먼저 검색하는 방식입니다. grounding은 답변이 출처에 묶여 있다는 뜻입니다. citation은 사람이 확인할 수 있는 출처 링크나 문서 위치입니다. freshness는 그 출처가 아직 최신인지 보여주는 날짜나 책임자 정보입니다.

• SOP: 업무 레시피와 판단 기준표.
• CLAUDE.md: AI에게 주는 상시 업무 브리핑. 법적 통제 장치는 아닙니다.
• RAG: 회사 지식을 먼저 검색하고 답하는 방식.
• grounding: 일반 상식이 아니라 출처가 있는 답변.
• citation: 사람이 확인할 수 있는 답변의 근거.
• freshness: 그 규칙이 아직 유효한지 보여주는 날짜와 책임자.

4. 정상 절차보다 예외 케이스가 더 중요합니다

대부분의 팀은 happy path부터 문서화합니다. 이것도 필요하지만 AI 에이전트는 경계에서 흔들립니다. 특이한 고객, 누락된 필드, 정책 충돌, 오래된 계약, VIP 예외, 급하지만 수상한 요청, A처럼 보이지만 B로 처리해야 하는 경우가 문제입니다.

Anthropic의 context engineering 글은 에이전트에게 필요한 것은 전체 말뭉치를 통째로 넣는 것이 아니라 적절한 순간에 관련 맥락을 주는 것이라고 설명합니다. 회사 지식도 같습니다. 에이전트에게는 경계를 가르치는 예시와 반례가 필요합니다.

고객 답변 에이전트라면 "친절하게 답변"만 쓰지 마세요. 언제 사과하는지, 언제 추가 정보를 요청하는지, 언제 거절하는지, 언제 에스컬레이션하는지, 언제 약속을 피해야 하는지 예시로 넣어야 합니다. 좋은 예외 케이스 몇 개가 애매한 정책 20쪽보다 더 큰 안정성을 줍니다.

• 예시: 모든 정보가 있는 일반 환불 요청.
• 반례: 승인 한도를 넘는 환불 요청.
• 반례: 고객이 정책 예외를 요구하는 경우.
• 반례: 출처 문서와 최신 공지가 충돌하는 경우.
• 반례: 초안 작성에는 충분하지만 실행 권한은 없는 경우.

5. 좋은 문서 구조: 한 장짜리 workflow 카드, 예시, 출처 흐름

첫 도입에서는 거대한 지식 베이스를 만들지 않는 편이 좋습니다. 하나의 workflow card부터 시작하세요. 이 카드는 한 화면에 들어오고, 더 깊은 문서는 필요한 곳에만 링크하는 구조가 좋습니다. 그래야 에이전트와 검토자가 같은 기준을 봅니다.

좋은 workflow card에는 오너, 마지막 업데이트 날짜, 출처 링크, workflow 목적, 입력 필드, 정상 절차, 예시, 예외, 승인 기준, 금지사항, 출력 형식, 에스컬레이션 경로가 들어갑니다. 검토자는 이 카드를 보고 에이전트가 맞는 규칙을 사용했는지 판단할 수 있어야 합니다.

Microsoft Copilot Studio 문서는 지식 소스를 범위 지정하고 grounding할 수 있으며, 사용자 인증이 어떤 콘텐츠를 보여줄지에 영향을 줄 수 있다고 설명합니다. 작은 회사도 같은 원칙을 쓰면 됩니다. 모든 문서를 하나의 열린 버킷으로 넣지 말고, 민감하거나 오래됐거나 역할별로 다른 지식은 범위를 나눠야 합니다.

• 거대한 company brain 하나가 아니라 workflow별 카드 하나.
• 출처 없는 복사본이 아니라 원본 링크가 있는 규칙.
• 추상 규칙만이 아니라 예시와 반례.
• 별도 폴더에 숨은 승인 기준이 아니라 업무 카드 안의 승인/에스컬레이션 규칙.
• 이름 있는 업데이트 책임자와 마지막 검토 날짜.

6. 나쁜 문서 구조: 긴 회의록, 오래된 위키, 숨어 있는 암묵지

나쁜 AI 지식은 겉보기에는 풍부해 보입니다. 문서가 많고, 채널이 많고, 폴더가 많고, 예전 결정도 많습니다. 문제는 두 출처가 충돌할 때 어떤 규칙이 이기는지 아무도 모른다는 점입니다.

긴 회의록은 특히 위험합니다. 아이디어, 결정, 농담, 반대 의견, 폐기된 계획이 섞여 있기 때문입니다. 오래된 위키는 공식처럼 보이는데 틀렸기 때문에 더 위험합니다. 암묵지는 또 다른 실패를 만듭니다. 에이전트는 문서 기준으로 답하지만 실제 회사 규칙은 한 명의 시니어 머릿속에 있을 수 있습니다.

실제 AI agent workflow에 관한 Reddit 논의에서도 비슷한 문제가 반복됩니다. 맥락이 너무 적으면 hallucination이 생기고, 너무 많으면 핵심 신호가 묻히고, 색인이 최신이 아니면 RAG가 깨집니다. 이는 커뮤니티 신호로만 보되, 운영 교훈은 분명합니다. 지식 품질은 문서 수가 아니라 현재 유효한 규칙을 얼마나 빨리 찾을 수 있는지로 봐야 합니다.

• 나쁨: "모든 회의록을 읽고 판단해."
• 좋음: "승인된 환불 SOP를 먼저 쓰고, 회의록은 배경으로만 참고해."
• 나쁨: "모든 문서를 모든 에이전트가 볼 수 있어."
• 좋음: "이 workflow는 이 출처만 읽고, 사용한 출처를 반드시 표시해."
• 나쁨: "팀은 예외를 알고 있어."
• 좋음: "예외가 문서화되고, 날짜와 출처와 책임자가 붙어 있어."

7. 에이전트에 지식을 연결하기 전 체크리스트

지식 소스를 연결하기 전에 운영 질문에 답해야 합니다. 에이전트는 무엇을 읽을 수 있습니까? 문서가 충돌하면 무엇이 이깁니까? 어떤 정보는 검색되면 안 됩니까? SOP는 누가 업데이트합니까? 검토자는 빠진 지식이나 틀린 지식을 어떻게 표시합니까? 에이전트가 이 지식을 제대로 쓰는지 어떤 eval로 확인합니까?

OpenAI와 Anthropic의 자료는 instructions, tools, retrieval, context, evals, guardrails가 함께 작동하는 시스템 방향을 보여줍니다. 비전문 팀도 원리는 같습니다. 회사 지식은 폴더가 아니라 살아 있는 운영 레이어입니다.

• 읽기 경계: 이 workflow가 어떤 출처를 읽을 수 있습니까?
• 출처 우선순위: 두 문서가 충돌하면 무엇이 이깁니까?
• 개인정보/민감정보 경계: 어떤 데이터는 마스킹, 제외, 로컬 보관해야 합니까?
• 업데이트 책임자: 현실이 바뀌면 누가 규칙을 고칩니까?
• 출처 표시 규칙: 모든 답변이 근거를 보여줘야 합니까?
• eval 세트: 어떤 예시로 에이전트가 규칙을 제대로 썼는지 시험합니까?
• 피드백 루프: 검토자의 수정이 어떻게 더 나은 SOP로 돌아갑니까?

8. 결론: 진짜 준비물은 AI가 읽을 수 있는 운영 지식입니다

모델도 중요하고, 검색 시스템도 중요하고, tool stack도 중요합니다. 하지만 많은 회사의 첫 병목은 더 단순합니다. 회사 스스로가 일을 AI가 읽고 사람이 감사할 수 있는 형태로 써두지 않았다는 것입니다.

하나의 workflow부터 시작하세요. 목적, 절차, 예외, 판단 기준, 금지사항, 출처, 책임자, eval 케이스를 적으세요. 그 다음 에이전트를 연결하세요. 그래야 회사 지식은 문서 더미가 아니라 운영 자산이 됩니다.