---
title: "사내 AI 에이전트 온보딩 가이드 만드는 법"
slug: "enterprise-ai-agent-onboarding-guide"
canonicalUrl: "https://moonshotnotes.com/posts/enterprise-ai-agent-onboarding-guide/"
sourceUrl: "https://moonshotnotes.com/posts/enterprise-ai-agent-onboarding-guide/"
markdownUrl: "https://moonshotnotes.com/agent/posts/enterprise-ai-agent-onboarding-guide.md"
language: "ko"
category: "Workflow"
updatedAt: "2026-05-14"
agentTokenEstimate: 3641
---

# 사내 AI 에이전트 온보딩 가이드 만드는 법

사내에서 AI 에이전트를 적극적으로 사용하도록 만들기 위한 AX 온보딩 가이드 설계 방법을 정리합니다. 사용 사례, 보안 기준, 권한 관리, 4주 온보딩 프로그램, 실전 템플릿까지 다룹니다.

## Agent metadata

- Source: https://moonshotnotes.com/posts/enterprise-ai-agent-onboarding-guide/
- Markdown: https://moonshotnotes.com/agent/posts/enterprise-ai-agent-onboarding-guide.md
- Language: ko
- Category: Workflow
- Tags: AI Agent, AX, AI Onboarding, AI Governance, Guardrails, Workflow
- Updated: 2026-05-14
- Estimated tokens: 3641

어느 날 사내에서 AI 에이전트 온보딩 가이드를 맡게 되었다고 해봅시다. 처음에는 간단해 보입니다. 승인된 도구 목록을 정리하고, 좋은 프롬프트 예시를 모으고, 보안 주의사항을 붙이면 될 것 같습니다.

그런데 실제로는 곧 다른 문제가 터집니다.

```text
이 자동화를 하려면 관리자 권한이 필요합니다.
API 키는 어디서 발급받나요?
고객 문의 원문을 넣어도 되나요?
운영 로그를 AI에게 읽혀도 되나요?
AI가 만든 코드를 바로 배포해도 되나요?
비용은 어느 팀 예산으로 처리하나요?
```

이 질문이 나오기 시작하면 온보딩은 더 이상 "사용법 교육"이 아닙니다. 조직이 AI에게 어떤 일을 맡기고, 어떤 데이터는 막고, 어떤 결과는 사람이 검증할지 정하는 운영 설계가 됩니다.

AI 에이전트 온보딩 가이드는 프롬프트 모음집으로 끝나면 안 됩니다. 핵심은 다음 질문에 답하는 것입니다.

```text
AI 에이전트에게 어떤 일을 맡길 수 있는가?
어떤 데이터는 넣으면 안 되는가?
어떤 실행은 승인 받아야 하는가?
AI 결과를 사람이 어떻게 검증할 것인가?
팀 업무 흐름을 어떻게 바꿀 것인가?
```

| 기준 | 내용 |
|---|---|
| 분석 기준일 | 2026-05-13 |
| 분석 범위 | 사내 AX 도입, AI 에이전트 온보딩, 보안/권한/비용 가드레일, 직군별 실무 적용 |
| 주요 참고자료 | OpenAI Agents SDK, OpenAI agent 구축 가이드, NIST AI RMF, Microsoft Work Trend Index, Google Cloud GenAI 보안 가이드, Atlassian AI Demo Playbook |
| 적용 대상 | AX 담당자, 개발팀 리더, 플랫폼/보안 담당자, 사내 AI 도입 프로그램 운영자 |

## 핵심 요약

- 사내 AI 에이전트 온보딩 가이드는 도구 사용법 문서가 아니라 **업무 전환 플레이북**이어야 합니다.
- AI 에이전트는 일반 챗봇보다 더 많은 도구와 권한을 다룰 수 있으므로, 권한/데이터/비용/검증 기준을 함께 설계해야 합니다.
- 도입 흐름은 `Harbor -> Spark -> Harness -> Route`로 나눌 수 있습니다. 먼저 공식 운영 경계를 만들고, 작은 성공 사례를 보여주고, 안전한 가드레일을 붙인 뒤, 계속 갱신되는 표준으로 운영합니다.
- 온보딩 문서는 `Quick Start Guide`, `Role-based Playbook`, `Governance & Safety Guide`의 3종 세트로 분리하는 편이 좋습니다.
- 운영 지표는 계정 수나 프롬프트 수보다 반복 업무 절감, 재사용 가능한 워크플로우, 승인된 자동화 비율, 품질 개선으로 봐야 합니다.

## AI 에이전트 온보딩은 왜 필요한가

처음 AI 도구를 도입하면 대부분 이렇게 시작합니다.

```text
ChatGPT 써보세요.
Claude 써보세요.
Copilot 써보세요.
Cursor 써보세요.
Claude Code 써보세요.
```

이 방식만으로는 조직 전체 사용률이 잘 올라가지 않습니다. 사람들은 도구 이름보다 자기 업무에서 어떻게 쓰는지 알고 싶어합니다.

개발자는 PR 리뷰와 테스트 코드 생성에 관심이 있습니다. QA는 테스트 케이스와 재현 절차에 관심이 있습니다. 기획자는 요구사항 정리와 정책 문서 초안에 관심이 있고, 운영/CS는 고객 문의 분류와 답변 초안에 관심이 있습니다.

| 기존 교육 방식 | 온보딩 플레이북 방식 |
|---|---|
| 도구 기능 설명 | 업무 흐름 변화 설명 |
| 프롬프트 예시 제공 | 직군별 사용 사례 제공 |
| 일회성 교육 | 반복 가능한 실습 프로그램 |
| 개인 역량에 의존 | 팀별 챔피언과 사례 공유 |
| 보안 기준 모호 | 허용/금지 데이터 기준 명확화 |
| 사용량 중심 | 업무 시간 절감과 품질 개선 중심 |

[Microsoft 2026 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization)는 AI와 에이전트가 실행을 맡을수록 사람이 일을 지휘하고 판단하는 역할이 커진다고 설명합니다. 이 글에서의 해석은 분명합니다. 사내 온보딩은 개인에게 "AI를 잘 써보라"고 말하는 문서가 아니라, 조직이 AI를 안전하고 반복 가능하게 흡수하기 위한 운영 문서가 되어야 합니다.

## AI 에이전트와 일반 챗봇의 차이

온보딩 초반에는 이 차이를 짧고 명확하게 설명해야 합니다.

일반 챗봇은 주로 질문에 답합니다. AI 에이전트는 목표를 받고, 필요한 정보를 찾고, 도구를 호출하고, 여러 단계를 거쳐 결과를 만듭니다.

[OpenAI Agents SDK 문서](https://openai.github.io/openai-agents-python/agents/)는 에이전트를 instructions, tools, handoffs, guardrails, structured outputs 같은 런타임 요소로 구성할 수 있는 LLM 실행 단위로 설명합니다. [OpenAI의 agent 구축 가이드](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)도 agent가 복잡한 의사결정, 유지하기 어려운 규칙, 비정형 데이터가 많은 워크플로우에 적합하다고 설명합니다.

| 구분 | 일반 챗봇 | AI 에이전트 |
|---|---|---|
| 기본 동작 | 질문에 답변 | 목표를 수행 |
| 입력 | 프롬프트 | 목표, 자료, 도구, 제약조건 |
| 실행 방식 | 단일 응답 중심 | 다단계 작업 중심 |
| 도구 사용 | 제한적 | API, 파일, 브라우저, 코드, 검색 등 |
| 위험 요소 | 부정확한 답변 | 잘못된 도구 실행, 권한 오남용, 비용 증가 |
| 필요한 관리 | 프롬프트 가이드 | 권한, 보안, 로그, 비용, 검증 기준 |

온보딩 가이드에는 다음 문장을 넣어야 합니다.

```text
AI 에이전트는 답변 도구가 아니라 실행 도구입니다.
따라서 실행 권한이 커질수록 검증 기준과 가드레일도 함께 커져야 합니다.
```

## AX 도입 방법론: Harbor, Spark, Harness, Route

사내 AX 도입은 교육 프로젝트가 아니라 조직 운영체계 전환 프로젝트입니다. 이 글에서는 네 단계로 나눕니다.

```mermaid
%% AX 도입은 공식 운영 경계, 첫 성공 사례, 안전한 가드레일, 지속 갱신 루프로 이어진다.
flowchart LR
  Harbor["Harbor<br/>공식 운영 경계"] --> Spark["Spark<br/>첫 성공 사례"]
  Spark --> Harness["Harness<br/>가드레일과 실행 표준"]
  Harness --> Route["Route<br/>지속 갱신되는 플레이북"]
  Route -.학습과 사례 반영.-> Spark
```

### Harbor: 경영진이 항구를 만든다

AI 사용이 개인의 몰래 쓰기 수준에 머물면 조직 전환은 일어나지 않습니다. 먼저 회사가 공식적으로 정해야 합니다.

| 결정 항목 | 질문 |
|---|---|
| 비용 | 어떤 AI 도구를 회사 비용으로 지원할 것인가 |
| 데이터 | 어떤 데이터에 AI를 붙일 수 있는가 |
| 권한 | 어떤 업무에서 도구 호출이나 자동화를 허용할 것인가 |
| 책임 | AX 운영 담당자는 누구인가 |
| 보안 | 민감정보, 고객정보, 소스코드 기준은 무엇인가 |
| 지표 | AI 사용의 성과를 무엇으로 볼 것인가 |

Harbor의 목적은 통제가 아닙니다. 개인이 눈치 보며 쓰는 상태를 공식 운영 경계 안으로 끌어오는 것입니다.

### Spark: 동경을 만든다

사람들이 AI를 쓰게 하려면 LLM 원리부터 설명할 필요는 없습니다. 더 강한 것은 옆 팀의 실제 사례입니다.

```text
옆 팀 사람이 AI로 매주 2시간 걸리던 일을 20분으로 줄였다.
```

[Atlassian AI Use Case Demo Playbook](https://www.atlassian.com/team-playbook/plays/ai-demos)은 AI 도입을 장려하는 방법 중 하나로 구체적인 사용 사례 데모를 제안합니다. 특히 실제 문제를 해결하는 라이브 데모는 동료가 "나도 저렇게 쓸 수 있겠다"고 느끼게 만듭니다.

온보딩 가이드에는 도구 설명보다 Before/After 사례가 많아야 합니다.

| Before | After |
|---|---|
| 회의록을 사람이 읽고 결정사항을 정리 | AI가 결정사항/담당자/마감일 초안을 만들고 사람이 검수 |
| PR diff를 리뷰어가 처음부터 훑음 | AI가 변경 요약/위험 포인트/테스트 후보를 먼저 정리 |
| 고객 문의를 운영자가 수동 분류 | AI가 유형/우선순위/답변 초안을 만들고 운영자가 확정 |
| 주간 보고를 각자 다른 형식으로 작성 | AI가 공통 템플릿으로 리스크/결정사항/다음 액션을 정리 |

### Harness: 자유를 가속하는 가드레일을 만든다

AI 사용이 잘 되기 시작하면 권한 요청이 늘어납니다. 이때 전부 막으면 확산이 죽고, 전부 열어주면 사고가 납니다.

그래서 필요한 것이 Harness입니다.

Harness는 AI 사용을 막는 통제가 아니라, 안전하게 더 많이 쓰게 만드는 가드레일입니다. [NIST AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)는 AI 리스크 관리를 Govern, Map, Measure, Manage 기능으로 나눕니다. 사내 AI 에이전트도 같은 관점으로 봐야 합니다.

| Harness 영역 | 필요한 장치 |
|---|---|
| 데이터 | 입력 금지/조건부 허용 데이터 표 |
| 권한 | 파일, 브라우저, API, DB, 배포 권한 레벨 |
| 비용 | 모델별 비용 기준, 반복 실행 제한, 팀별 한도 |
| 검증 | 사람이 확인해야 하는 항목, 테스트 기준 |
| 로그 | 누가 어떤 도구로 어떤 작업을 실행했는지 |
| 사고 대응 | 잘못된 입력/출력/도구 실행이 발생했을 때의 절차 |

### Route: 표준은 계속 갈아엎는다

AI 도구와 모델은 빠르게 바뀝니다. 오늘의 모범 사례가 다음 달에는 낡은 방식이 될 수 있습니다. 그래서 온보딩 가이드는 완성 문서가 아니라 살아있는 문서여야 합니다.

Route 단계의 핵심은 표준을 고정하는 것이 아니라, 성공 사례와 실패 사례가 계속 반영되는 루프를 만드는 것입니다.

```text
새 사용 사례 수집
-> 위험도 분류
-> 팀별 실습에 반영
-> 실패 사례와 가드레일 업데이트
-> 다음 온보딩 자료에 반영
```

## 온보딩 가이드는 3종 세트로 나눈다

한 문서에 모든 내용을 넣으면 아무도 끝까지 읽지 않습니다. 사내 온보딩 가이드는 세 문서로 나누는 편이 좋습니다.

| 문서 | 대상 | 목적 |
|---|---|---|
| Quick Start Guide | 전 직원 | 30분 안에 첫 성공 경험 만들기 |
| Role-based Playbook | 직군별 사용자 | 내 업무에 바로 적용할 사례 제공 |
| Governance & Safety Guide | 리더, AX 담당자, 보안 담당자 | 권한, 데이터, 비용, 감사 기준 정리 |

### Quick Start Guide

입문 문서의 성공 기준은 설명량이 아니라 첫 업무 결과물입니다.

```text
목표:
처음 쓰는 사람이 30분 안에
자기 업무 하나를 AI 에이전트로 처리해보게 만든다.
```

| 섹션 | 내용 |
|---|---|
| AI 에이전트란? | 챗봇과의 차이 |
| 사용 가능한 도구 | 사내 승인 도구 목록 |
| 계정 신청 | 접근 방법 |
| 첫 실습 | 회의록 요약, 문서 정리, 코드 설명 등 |
| 금지 데이터 | 넣으면 안 되는 정보 |
| 결과 검증 | 사람이 확인할 항목 |

### Role-based Playbook

Role-based Playbook은 직군별로 나눠야 합니다. 같은 AI 도구라도 직군마다 첫 성공 경험이 다릅니다.

| 직군 | 대표 사용 사례 |
|---|---|
| 개발 | 코드 설명, PR 요약, 테스트 케이스 생성, 리팩터링 초안 |
| QA | 테스트 시나리오, 엣지 케이스, 재현 절차 정리 |
| 기획 | 요구사항 정리, 사용자 스토리, 정책 문서 초안 |
| 디자인 | 사용자 가이드, 화면 문구, 접근성 체크 |
| 운영/CS | 고객 문의 분류, 답변 초안, 이슈 요약 |
| 데이터/분석 | 지표 정의, SQL 초안, 리포트 요약 |
| 리더 | 주간 리포트, 의사결정 리스크, 회의 요약 |

### Governance & Safety Guide

이 문서는 길게 만들 필요가 없습니다. 하지만 모호하면 안 됩니다.

| 항목 | 반드시 정리할 내용 |
|---|---|
| 데이터 등급 | 공개/내부/민감/고객/기밀 |
| 도구 권한 | 파일, 브라우저, 코드, API, DB 접근 |
| 비용 | 팀별 한도, 모델별 비용, 반복 실행 주의 |
| 로그 | 어떤 사용 기록을 남길 것인가 |
| 승인 | 어떤 요청은 별도 승인이 필요한가 |
| 사고 대응 | 잘못된 입력이나 출력 발생 시 절차 |

[OpenAI Enterprise Privacy](https://openai.com/enterprise-privacy/)는 기업용 제품과 API Platform에서 비즈니스 데이터의 소유와 통제, 모델 학습 사용 여부, 조직 내 접근 제어를 설명합니다. 다만 사내 가이드는 특정 벤더 정책만 믿으면 안 됩니다. 회사가 실제로 쓰는 도구별 데이터 처리 기준을 별도 표로 정리해야 합니다.

## 첫 성공 경험을 설계한다

온보딩에서 가장 중요한 것은 첫 성공 경험입니다. 처음부터 거창한 자동화를 시키면 실패합니다. 15~30분 안에 끝나는 작은 실습이 필요합니다.

| 대상 | 첫 실습 | 기대 효과 |
|---|---|---|
| 전 직원 | 긴 문서 요약 후 액션 아이템 추출 | 즉시 체감 |
| 개발자 | PR diff 요약과 리뷰 포인트 생성 | 코드 리뷰 시간 절감 |
| QA | 요구사항 기반 테스트 케이스 생성 | 누락 케이스 발견 |
| 기획자 | 회의록을 정책 문서 초안으로 변환 | 문서화 속도 향상 |
| 디자이너 | 화면 설명을 사용자 가이드로 변환 | 반복 문서 작업 감소 |
| CS | 고객 문의를 유형별로 분류 | 응대 품질 균일화 |
| 리더 | 주간 업무 내용을 리스크/결정사항으로 요약 | 의사결정 보조 |

여기서 중요한 것은 실습 주제가 "AI 기능 체험"이 아니라 "내 업무 하나 해결"이어야 한다는 점입니다.

| 나쁜 실습 | 좋은 실습 |
|---|---|
| AI에게 자기소개서를 써보게 하기 | 이번 주 회의록에서 결정사항, 담당자, 마감일을 표로 정리하게 하기 |
| AI에게 아무 글이나 요약하게 하기 | 실제 팀 문서에서 다음 액션과 누락된 의사결정을 추출하게 하기 |
| 프롬프트 엔지니어링 용어 설명 | 팀에서 매주 반복하는 업무를 하나 줄여보게 하기 |

## 사용 사례는 직군별 카드로 만든다

좋은 유스케이스 카드는 프롬프트보다 업무 흐름을 보여줍니다. 개발자를 위한 카드는 이렇게 만들 수 있습니다.

```text
# 유스케이스 카드: PR 변경사항 요약

## 대상
개발자, 테크리드

## 기존 방식
PR diff 확인 -> 변경 파일 읽기 -> 리뷰 포인트 작성 -> 테스트 필요 항목 정리

## AI 적용 방식
PR diff와 관련 이슈를 입력 -> 변경 요약 -> 위험 포인트 -> 테스트 추천 생성

## 입력 자료
- PR diff
- 관련 Jira/GitHub Issue
- 변경된 파일 일부
- 기존 테스트 코드

## 출력 형식
- 5줄 요약
- 주요 변경점
- 위험 포인트
- 테스트 필요 항목
- 리뷰 질문

## 주의사항
- 비밀키, 토큰, 고객정보가 diff에 포함되어 있지 않은지 확인
- AI 결과를 그대로 approve하지 않기
- 최종 merge 판단은 사람이 하기
```

QA 카드라면 입력과 검증 기준이 달라집니다.

```text
# 유스케이스 카드: 요구사항 기반 테스트 케이스 생성

## 대상
QA, 기획자, 개발자

## 기존 방식
요구사항 문서 읽기 -> 정상 흐름 정리 -> 예외 케이스 수동 도출

## AI 적용 방식
요구사항과 화면 정책을 입력 -> 정상/예외/경계값 테스트 초안 생성

## 출력 형식
- 테스트 목적
- 사전 조건
- 테스트 데이터
- 절차
- 기대 결과
- 우선순위

## 검증 기준
- 비즈니스 정책과 충돌하는 케이스가 없는가
- 보안/권한 관련 케이스가 빠지지 않았는가
- 사람이 실제로 실행 가능한 절차인가
```

## AI 에이전트 사용은 3단계로 분류한다

회의록 요약과 운영 DB 접근 자동화는 위험도가 완전히 다릅니다. AI 사용을 모두 같은 수준으로 관리하면 안 됩니다.

| 레벨 | 사용 유형 | 예시 | 승인 기준 |
|---|---|---|---|
| Level 1 | 개인 생산성 | 요약, 번역, 초안, 회의록, 코드 설명 | 즉시 허용 |
| Level 2 | 팀 업무 보조 | QA 시나리오, PR 요약, 리포트 자동화, 로그 분석 | 팀 리더 또는 담당자 검토 |
| Level 3 | 시스템 연동/자동 실행 | DB 조회, API 호출, 배포 스크립트, 고객정보 처리 | 보안/개발/AX 담당 검토 |

[Google Cloud의 생성형 AI 보안 가이드](https://cloud.google.com/docs/security/security-best-practices-genai)는 생성형 AI 워크로드를 인프라, 데이터 관리, 애플리케이션 통제 관점에서 다룹니다. [Google Cloud Production-Ready AI Learning Path](https://cloud.google.com/blog/topics/developers-practitioners/production-ready-ai-with-google-cloud-learning-path/)도 agent를 개발, 보안, 배포, 평가, production pattern으로 나누어 다룹니다.

사내 가이드도 같은 방식이어야 합니다. "AI를 쓰라"가 아니라 "어떤 레벨의 업무인지 먼저 분류하라"가 출발점입니다.

## 보안/데이터/권한 기준은 1페이지로 만든다

보안 문서가 너무 길면 아무도 읽지 않습니다. 온보딩 가이드에는 1페이지짜리 "넣어도 되는 것 / 넣으면 안 되는 것" 표가 있어야 합니다.

### 입력 금지 데이터

먼저 금지 데이터는 체크리스트로 바로 보여줘야 합니다.

```text
AI 에이전트에 입력하면 안 되는 것

[ ] 고객 개인정보
[ ] 주민등록번호, 계좌번호, 카드번호
[ ] 인증 토큰, API Key, Secret Key
[ ] 비공개 계약서 원문
[ ] 접근 권한이 없는 타 팀 문서
[ ] 운영 DB 원본 데이터
[ ] 보안 취약점 세부 정보
[ ] 외부 공개 금지 소스코드
```

### 조건부 허용 데이터

익명화와 마스킹 기준은 사용자가 바로 판단할 수 있게 적어야 합니다.

```text
조건부로 사용 가능한 것

[ ] 익명화된 로그
[ ] 마스킹된 고객 문의
[ ] 공개 가능한 코드 일부
[ ] 내부 정책 요약본
[ ] 테스트용 더미 데이터
[ ] 샘플 API 응답
```

### 권한 요청 기준

AI 에이전트가 도구를 호출하기 시작하면 권한 관리가 중요해집니다.

| 권한 유형 | 예시 | 기본 정책 |
|---|---|---|
| 파일 읽기 | 문서 요약, 코드 분석 | 제한적으로 허용 |
| 파일 수정 | 코드 변경, 문서 수정 | diff 확인 후 허용 |
| 브라우저 접근 | 웹 검색, 화면 캡처 | 공개 정보 중심 |
| API 호출 | 내부 시스템 조회 | 승인 필요 |
| DB 접근 | 운영 데이터 조회 | 기본 금지 |
| 배포 실행 | 스크립트 실행, CI/CD 호출 | 고위험 승인 필요 |

> **권한 기준 (danger)**
>
> AI 에이전트가 도구를 호출할 수 있다는 것은 실제 시스템에 영향을 줄 수 있다는 뜻입니다. 도구 권한은 사용자 권한보다 더 보수적으로 설계하는 편이 안전합니다.

## 4주 온보딩 프로그램으로 운영한다

문서만 배포하면 사용률은 잘 올라가지 않습니다. 온보딩은 문서가 아니라 프로그램으로 운영해야 합니다.

| 주차 | 목표 | 진행 내용 | 산출물 |
|---|---|---|---|
| 1주차 | 기본 사용 경험 | 계정 설정, 첫 실습, 금지 데이터 교육 | 개인 실습 결과 |
| 2주차 | 직군별 업무 적용 | 팀별 대표 업무 1개를 AI로 처리 | Before/After 사례 |
| 3주차 | 에이전트형 업무 확장 | 도구 사용, 문서/코드/로그 기반 작업 | 팀별 workflow template |
| 4주차 | 공유와 표준화 | 사례 발표, 실패 사례 정리, 가이드 업데이트 | 사내 플레이북 v1 |

이 방식의 장점은 분명합니다.

- 사람들이 실제로 써봅니다.
- 성공 사례가 생깁니다.
- 실패 사례도 문서에 반영됩니다.
- 가이드는 살아있는 문서가 됩니다.

## 실전 템플릿

온보딩 가이드의 마지막에는 바로 복사해서 쓸 수 있는 템플릿을 넣어야 합니다.

### AI 에이전트 요청 템플릿

```text
# AI 에이전트 요청 템플릿

## 1. 목표
무엇을 끝내야 하는가?

## 2. 배경
왜 이 작업이 필요한가?

## 3. 입력 자료
AI가 참고해야 할 문서, 로그, 코드, 이슈, 정책은 무엇인가?

## 4. 제약조건
하면 안 되는 것, 지켜야 할 규칙, 형식은 무엇인가?

## 5. 출력 형식
표, Markdown, JSON, 체크리스트, 코드, 이메일 초안 중 무엇으로 받을 것인가?

## 6. 검증 기준
사람이 무엇을 확인해야 완료로 볼 수 있는가?
```

요청 품질은 결과 품질을 크게 바꿉니다.

| 나쁜 요청 | 좋은 요청 |
|---|---|
| 이 코드 고쳐줘 | 아래 Node.js API 코드에서 인증 실패 시 500이 아니라 401을 반환하도록 수정안을 제안해줘. 기존 응답 스키마는 유지하고, 변경 파일 후보와 테스트 케이스를 함께 제안해줘. |
| 문서 정리해줘 | 아래 회의록에서 결정사항, 담당자, 마감일, 미확정 쟁점을 표로 정리해줘. 사실이 불확실한 항목은 "확인 필요"로 표시해줘. |
| 자동화해줘 | 현재 수작업 절차, 입력 데이터, 권한 필요 여부, 실패 시 되돌리는 방법을 먼저 정리한 뒤 자동화 가능 범위를 Level 1/2/3으로 분류해줘. |

### AX 자동화 요청서

Level 2 이상 업무에는 요청서를 받는 편이 좋습니다.

```text
# AX 자동화 요청서

## 1. 해결하려는 문제
- 현재 어떤 업무가 반복되는가?
- 한 번 처리하는 데 얼마나 걸리는가?
- 월 몇 회 발생하는가?

## 2. 현재 업무 흐름
Before:
1.
2.
3.

## 3. AI 적용 후 기대 흐름
After:
1.
2.
3.

## 4. 사용하는 데이터
- 공개 데이터:
- 내부 일반 데이터:
- 민감 데이터:
- 고객/개인정보:
- 소스코드/비밀키 포함 여부:

## 5. 필요한 권한
- 파일 접근:
- API 접근:
- DB 접근:
- 외부 서비스 연동:
- 관리자 권한 필요 여부:

## 6. 결과물
- 문서
- 코드
- 리포트
- 알림
- 웹서비스
- 자동 실행 스크립트

## 7. 위험도 분류
- Level 1: 개인 생산성
- Level 2: 팀 업무 자동화
- Level 3: 시스템/데이터 연동

## 8. 검증 기준
- 사람이 확인할 항목:
- 실패 시 되돌리는 방법:
- 로그 또는 증거:
```

### 개인 사용 전 체크리스트

```text
# AI 에이전트 사용 전 체크리스트

## 입력 데이터
[ ] 고객 개인정보가 포함되어 있지 않은가?
[ ] API Key, Secret, Token이 포함되어 있지 않은가?
[ ] 외부 공개가 불가능한 계약/정책/소스코드가 포함되어 있지 않은가?
[ ] 필요한 경우 익명화 또는 마스킹했는가?

## 작업 범위
[ ] AI에게 맡길 작업이 명확한가?
[ ] 사람이 최종 판단할 항목이 분리되어 있는가?
[ ] 결과물 형식을 지정했는가?
[ ] 실패했을 때 되돌릴 수 있는가?

## 검증
[ ] AI가 생성한 사실을 확인했는가?
[ ] AI가 생성한 코드를 테스트했는가?
[ ] 보안/권한 영향이 있는지 확인했는가?
[ ] 비용이 과도하게 발생하지 않는가?

## 공유
[ ] 이 사용 사례를 팀에서 재사용할 수 있는가?
[ ] 프롬프트가 아니라 업무 흐름으로 정리했는가?
[ ] 성공/실패 사례를 사내 채널에 남겼는가?
```

## 운영 지표는 사용량보다 업무 변화로 본다

AI 에이전트를 적극 사용하게 만들려면 지표도 잘 잡아야 합니다. 많은 조직이 처음에는 사용량을 봅니다.

```text
계정 발급 수
월간 프롬프트 수
AI 도구 접속자 수
```

하지만 이것만으로는 실제 효과를 알기 어렵습니다. 더 중요한 지표는 업무 흐름의 변화입니다.

| 나쁜 지표 | 좋은 지표 |
|---|---|
| AI 계정 발급 수 | 반복 업무 절감 시간 |
| 프롬프트 공유 수 | 재사용 가능한 워크플로우 수 |
| 교육 참석자 수 | 실제 적용 사례 수 |
| 월간 사용량 | 비용 대비 절감 효과 |
| 챗봇 호출 수 | 산출물 품질 개선률 |
| 자동화 개수 | 안전하게 승인된 Level 1/2 업무 비율 |

온보딩 가이드의 목표는 사용량을 늘리는 것이 아니라 아래 질문에 답하는 것이어야 합니다.

```text
이 팀은 AI 에이전트를 통해 어떤 업무 흐름을 바꿨는가?
그 변화는 안전한가?
반복 가능한가?
다른 팀도 가져다 쓸 수 있는가?
```

## 바로 시작하는 운영 순서

처음부터 거대한 AX 조직을 만들 필요는 없습니다. 시작은 작아도 됩니다.

```text
1. 각 팀에서 매주 반복하는 업무 3개를 수집한다.
2. 각 업무를 Level 1/2/3으로 분류한다.
3. Level 1 업무 하나로 30분 실습을 만든다.
4. Before/After 사례를 카드로 남긴다.
5. 금지 데이터와 권한 기준을 1페이지로 붙인다.
6. 4주 뒤 실제 사례와 실패 사례를 반영해 플레이북을 갱신한다.
```

AX는 AI를 많이 쓰게 하는 프로젝트가 아닙니다. 사람이 더 중요한 문제에 시간을 쓰도록, 반복 가능한 업무 흐름을 다시 설계하는 프로젝트입니다.

프롬프트 모음집이 아니라 업무 플레이북, 도구 소개가 아니라 첫 성공 경험, 무조건 허용이 아니라 위험도 기반 가드레일. 이 세 가지를 지키면 사내 AI 에이전트 온보딩은 교육 자료를 넘어 조직의 실행 방식을 바꾸는 운영 체계가 됩니다.

## 요약 카드

| 항목 | 내용 |
|---|---|
| 한 줄 요약 | AI 에이전트 온보딩은 사용법 교육이 아니라 업무 흐름 전환 플레이북이다. |
| 추천 대상 | AX 담당자, 사내 AI 도입 담당자, 개발팀 리더, 보안/플랫폼 담당자 |
| 가장 중요한 구조 | Quick Start Guide + Role-based Playbook + Governance & Safety Guide |
| 가장 큰 리스크 | 보안 기준 없이 권한/API/DB 접근을 열어주는 것 |
| 가장 중요한 장치 | 직군별 첫 성공 경험과 Before/After 사례 |
| 지금 바로 할 일 | 팀별 반복 업무 3개를 수집하고 유스케이스 카드로 정리하기 |

## 참고자료

- [OpenAI Agents SDK: Agents](https://openai.github.io/openai-agents-python/agents/)
- [OpenAI: A practical guide to building agents](https://openai.com/business/guides-and-resources/a-practical-guide-to-building-ai-agents/)
- [OpenAI Enterprise Privacy](https://openai.com/enterprise-privacy/)
- [Microsoft 2026 Work Trend Index](https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization)
- [NIST AI RMF Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/)
- [Atlassian AI Use Case Demo Playbook](https://www.atlassian.com/team-playbook/plays/ai-demos)
- [Google Cloud security best practices for generative AI workloads](https://cloud.google.com/docs/security/security-best-practices-genai)
- [Google Cloud Production-Ready AI Learning Path](https://cloud.google.com/blog/topics/developers-practitioners/production-ready-ai-with-google-cloud-learning-path/)