AI Agent란? > AI Agent

최고관리자

25-07-29 22:56 0개 346회

AI Agent란?

# AI Agent 완벽 가이드 > **작성 기준:** 2026년 8월 29일 > **대상:** AI Agent의 개념부터 실제 설계·개발·운영까지 이해하려는 사용자와 개발자 > **핵심 주제:** AI Agent의 정의, 구조, 동작 원리, Skill·MCP·하네스·루프·그래프와의 관계, 멀티에이전트, 평가와 보안 *** ## 1\. AI Agent란? \*\*AI Agent(인공지능 에이전트)\*\*는 사용자가 정한 목표를 달성하기 위해 현재 상황을 파악하고, 다음 행동을 판단하고, 필요한 도구를 사용하며, 결과를 확인해 작업을 이어가는 AI 기반 시스템입니다. OpenAI 공식 문서는 Agent를 **계획하고, 도구를 호출하고, 전문 에이전트와 협업하며, 여러 단계의 작업을 완료할 만큼 상태를 유지하는 애플리케이션**으로 설명합니다. 쉽게 말하면 다음과 같습니다. > **일반 AI가 질문에 답하는 두뇌라면, AI Agent는 목표를 받고 실제 업무를 수행하는 AI 직원에 가깝습니다.** 예를 들어 일반 챗봇에게 “이 영상을 요약하는 방법을 알려줘”라고 하면 절차를 설명합니다. 영상 요약 Agent는 다음 행동을 직접 수행할 수 있습니다. 1. 영상 정보 확인 2. 전체 자막 확보 3. 자막을 구간별로 분석 4. 광고와 본문 분리 5. 상세 요약 작성 6. Markdown 문법 검사 7. 파일 저장 8. 오류가 생기면 다른 방법을 시도하거나 사람에게 요청 Agent의 핵심은 단순히 글을 생성하는 것이 아니라 **목표를 향해 여러 행동을 선택하고 실행한다는 점**입니다. *** ## 2\. LLM과 AI Agent의 차이 LLM은 Agent의 두뇌 역할을 할 수 있지만, LLM 하나만으로 완전한 Agent가 되는 것은 아닙니다. | 구분 | LLM | AI Agent | | --- | --- | -------- | | **주요 역할** | 입력을 이해하고 텍스트·코드 등을 생성 | 목표 달성을 위해 판단하고 행동 | | **입력 단위** | 프롬프트 | 목표, 환경 정보, 상태, 도구 결과 | | **외부 행동** | 기본적으로 없음 | 도구를 이용해 파일·API·서비스 조작 가능 | | **작업 길이** | 주로 한 번의 응답 | 여러 단계와 여러 번의 도구 호출 | | **상태 관리** | 현재 컨텍스트 중심 | 세션·파일·DB 등에 진행 상태 유지 | | **검증** | 스스로 답변을 평가할 수 있으나 한계 존재 | 테스트·규칙·다른 Agent·사람으로 검증 가능 | | **종료 판단** | 응답 생성 후 종료 | 목표·중단 조건·승인 상태에 따라 종료 | 정리하면 다음과 같습니다. > **AI Agent = LLM + 지시 + 도구 + 상태 + 실행 루프 + 검증·안전장치** *** ## 3\. 챗봇과 AI Agent의 차이 | 항목 | 일반 챗봇 | AI Agent | | --- | ----- | -------- | | **사용자 관계** | 질문에 답변 | 사용자를 대신해 업무 수행 | | **행동 방식** | 수동적·응답 중심 | 목표 중심·행동 중심 | | **다음 단계** | 사용자가 다시 지시 | Agent가 상황을 보고 결정 가능 | | **도구 사용** | 없거나 제한적 | 검색, 코드, 파일, API, 브라우저 등 사용 | | **반복 작업** | 사용자가 대화를 이어감 | 결과가 부족하면 스스로 재시도 가능 | | **완료 조건** | 답변을 생성하면 완료 | 검증 가능한 목표를 달성해야 완료 | | **예외 처리** | 오류를 설명 | 재시도·대체 경로·사람 이관 수행 | 다만 최근의 고급 챗봇도 검색, 파일 작업과 도구 사용을 지원하므로 제품의 겉모습만으로 챗봇과 Agent를 구분하기는 어렵습니다. 중요한 것은 **시스템이 목표를 위해 여러 행동을 선택하고 상태를 유지하는가**입니다. *** ## 4\. 자동화 Workflow와 Agent의 차이 전통적인 자동화 Workflow는 사람이 미리 정한 순서대로 실행됩니다. ``` 메일 수신 → 첨부파일 저장 → 데이터 추출 → 보고서 생성 ``` Agent는 실행 도중 상황에 따라 다음 행동을 판단할 수 있습니다. ``` 메일 수신 → 첨부파일 종류 확인 → PDF면 OCR, CSV면 데이터 분석 → 정보가 부족하면 발신자에게 질문 초안 작성 → 위험한 요청이면 사람에게 전달 → 정상 데이터면 보고서 생성 ``` | 구분 | 고정 Workflow | AI Agent | | --- | ----------- | -------- | | **경로** | 사전에 고정 | 상황에 따라 동적으로 선택 | | **예외 처리** | 미리 코딩해야 함 | 맥락을 해석해 대안 선택 가능 | | **예측 가능성** | 높음 | 상대적으로 낮음 | | **유연성** | 낮음 | 높음 | | **감사·검증** | 비교적 쉬움 | 별도의 로그와 평가 필요 | 실무에서는 모든 것을 Agent에게 맡기기보다 **고정할 수 있는 단계는 일반 Workflow로 만들고, 의미 판단이 필요한 부분에만 Agent를 배치하는 혼합 구조**가 효과적입니다. *** ## 5\. AI Agent의 핵심 구성요소 | 구성요소 | 역할 | | ---- | --- | | **Goal·Instructions** | Agent가 달성할 목표와 따라야 할 규칙 | | **Model** | 언어 이해, 추론, 계획과 의사결정을 담당하는 두뇌 | | **Tools** | 검색, 코드 실행, 파일 처리, API 호출 등 실제 행동 수단 | | **Context** | 현재 판단에 필요한 문서·대화·환경 정보 | | **State·Memory** | 현재 진행 상황과 과거의 유용한 정보 유지 | | **Agent Loop** | 판단→행동→관찰→수정의 반복 구조 | | **Guardrails** | 허용·금지 행동, 입력·출력과 도구 사용 검사 | | **Approvals** | 위험한 행동 전에 사람의 확인을 받는 단계 | | **Observability** | 모델 호출·도구 사용·오류·비용을 추적하는 로그 | | **Evals** | Agent가 실제 목표를 얼마나 잘 달성하는지 평가 | *** ## 6\. AI Agent의 기본 동작 원리 Agent는 일반적으로 다음 루프를 반복합니다. ``` flowchart TD A["목표와 현재 상태 확인"] --> B["다음 행동 판단"] B --> C["도구·Skill·다른 Agent 사용"] C --> D["결과 관찰"] D --> E["상태와 계획 갱신"] E --> F{"완료 조건 충족?"} F -->|아니요| B F -->|예| G["결과 제출·종료"] E --> H{"승인·이관 필요?"} H -->|예| I["사람에게 질문·승인 대기"] I --> E ``` ### 1\. 목표 확인 사용자가 원하는 결과, 제한 조건과 완료 기준을 이해합니다. ### 2\. 계획 또는 다음 행동 선택 복잡한 업무는 하위 작업으로 나누고, 간단한 업무는 바로 다음 행동을 결정합니다. ### 3\. 도구 사용 필요한 정보를 검색하고, 파일을 읽고, 코드를 실행하거나 외부 서비스에 요청합니다. ### 4\. 결과 관찰 도구가 반환한 데이터, 테스트 결과와 오류를 확인합니다. ### 5\. 계획과 상태 수정 성공한 항목, 실패 원인, 남은 작업과 다음 행동을 갱신합니다. ### 6\. 완료·재시도·이관 판단 * 완료 조건 충족 → 결과 제출 * 수정 가능 → 재시도 * 외부 장애 → 대기 또는 대체 경로 * 정보 부족·위험 행동 → 사람에게 질문 또는 승인 요청 *** ## 7\. Agent의 목표와 Instructions Agent는 자율적으로 행동하더라도 인간이 정한 목표와 경계 안에서 움직여야 합니다. 좋은 Instructions에는 다음 내용이 포함됩니다. * Agent의 역할 * 달성해야 할 목표 * 사용할 수 있는 자료와 도구 * 반드시 지켜야 할 규칙 * 완료 조건 * 실패와 재시도 조건 * 사람에게 이관할 조건 * 해서는 안 되는 행동 ### 모호한 지시 ``` 고객을 잘 도와줘. ``` ### 개선된 지시 ``` 배송 문의를 해결하는 고객지원 Agent입니다. 주문번호를 확인하고 배송 시스템에서 상태를 조회합니다. 배송 지연이면 공식 정책에 따라 안내 초안을 작성합니다. 환불, 주소 변경, 보상 확정은 사용자의 승인 없이 실행하지 않습니다. 정보가 일치하지 않으면 임의로 추측하지 말고 담당자에게 이관합니다. ``` *** ## 8\. Tools: Agent가 실제 행동하는 방법 모델은 생각하고 문장을 만드는 데 강하지만, 최신 정보를 확인하거나 외부 시스템을 변경하려면 도구가 필요합니다. ### 정보 획득 도구 * 웹 검색 * 파일 검색 * 사내 문서 검색 * 데이터베이스 조회 * RAG 검색 ### 실행 도구 * 함수 호출 * 셸 명령 실행 * 코드 인터프리터 * 브라우저·컴퓨터 사용 * 이미지 생성 * 문서·스프레드시트 생성 ### 외부 서비스 도구 * Gmail * Slack * GitHub * Notion * Google Calendar * 기타 MCP 서버와 API 도구가 많다고 좋은 Agent가 되는 것은 아닙니다. 도구가 늘어날수록 잘못된 선택, 권한 오용과 보안 위험도 커집니다. Agent의 업무에 필요한 최소한의 도구만 제공하는 것이 좋습니다. *** ## 9\. Function Calling과 MCP ### Function Calling 애플리케이션 개발자가 정의한 함수를 모델이 선택해 호출하는 방식입니다. 예를 들면 다음과 같습니다. * `get\_order\_status(order\_id)` * `search\_documents(query)` * `create\_report(data)` ### MCP(Model Context Protocol) Agent가 외부 데이터·도구·서비스와 연결될 수 있도록 표준화한 방식입니다. 여러 Agent와 제품에서 같은 외부 기능을 재사용하기에 유리합니다. ### 차이 | 구분 | Function Calling | MCP | | --- | ---------------- | --- | | **정의 위치** | 현재 애플리케이션 코드 | 독립 MCP 서버·커넥터 | | **재사용 범위** | 해당 앱 중심 | 여러 Agent·호스트에서 재사용 가능 | | **용도** | 내부 비즈니스 함수 호출 | 외부 시스템과 표준 방식으로 연결 | Agent 관점에서는 둘 다 ‘사용할 수 있는 도구’이며, 어떤 방식으로 구현됐는지는 하네스와 애플리케이션이 관리합니다. *** ## 10\. Context\, State와 Memory의 차이 세 용어는 비슷해 보이지만 역할이 다릅니다. | 개념 | 의미 | 예시 | | --- | --- | --- | | **Context** | 현재 판단 시 모델에게 제공되는 정보 | 현재 대화, 관련 문서, 도구 결과 | | **State** | 현재 실행이 어디까지 진행됐는지 나타내는 구조화된 정보 | 완료 작업, 재시도 횟수, 다음 노드 | | **Memory** | 이후 작업에서도 재사용할 장기 정보 | 사용자 선호, 반복되는 결정, 과거 해결책 | ### 상태 예시 ``` task_id: report-2026-08-29 status: reviewing completed_steps: - collect_sources - create_draft retry_count: 1 next_step: verify_numbers human_approval: pending ``` Agent가 긴 작업을 안정적으로 수행하려면 대화 내용만 믿지 말고 중요한 진행 상황을 파일이나 데이터베이스의 명시적인 상태로 저장해야 합니다. *** ## 11\. AI Skill과 AI Agent의 관계 앞서 정리한 AI Skill과 Agent는 다음 관계로 이해할 수 있습니다. > **Agent는 일을 수행하는 주체이고, Skill은 Agent가 특정 업무를 수행할 때 참고하는 매뉴얼입니다.** | 구분 | AI Agent | AI Skill | | --- | -------- | -------- | | **역할** | 목표를 받고 판단·행동 | 특정 업무의 표준 절차 제공 | | **실행 가능성** | 도구를 사용해 작업 수행 | 단독 실행 주체가 아니라 Agent가 적용 | | **상태 관리** | 작업 진행 상태 유지 | 일반적으로 절차와 자료를 제공 | | **선택** | 목표에 따라 다음 행동 결정 | 요청과 Description이 맞을 때 로드 | ### 예시: 영상 요약 * **Agent:** 자막 도구를 사용하고 오류를 처리하며 파일을 저장하는 실행 주체 * **YouTube Summary Skill:** 영상 요약 순서, 출력 형식, 광고 분리와 검증 기준 * **도구:** 영상 메타데이터·자막 확인, 파일 작성 * **상태:** 자막 확보 여부, 작성 완료 섹션, 저장 결과 *** ## 12\. Agent·Skill·MCP·하네스·루프·그래프의 관계 지금까지 정리한 개념은 회사에 비유하면 쉽게 연결됩니다. | AI 개념 | 회사 비유 | 역할 | | ----- | ----- | --- | | **Agent** | 직원 | 목표를 받고 실제로 업무 수행 | | **Model** | 직원의 두뇌 | 이해·추론·판단 | | **Skill** | 업무 매뉴얼 | 반복 업무의 표준 절차 | | **MCP·Tool** | 사내 시스템과 업무 도구 | 자료 조회와 실제 행동 | | **Memory** | 경험과 개인 메모 | 이전 선호와 해결 방법 기억 | | **State** | 업무 진행표·인수인계 노트 | 현재 작업 위치와 결과 기록 | | **Harness** | 사무실·규정·권한·검사 시스템 | Agent가 일하는 전체 환경 | | **Loop** | 확인→작업→검토→수정 순환 | 한 작업을 반복하는 실행 구조 | | **Graph** | 업무 프로세스도·조직 협업도 | 분기·병렬·승인을 포함한 전체 흐름 | ``` flowchart TD A["사용자의 목표"] --> B["AI Agent"] B --> C["Skill·Instructions"] B --> D["Model"] B --> E["Tools·MCP"] B --> F["State·Memory"] C --> G["Agent Loop"] D --> G E --> G F --> G G --> H["Harness·Guardrails"] H --> I["Workflow·Graph 안에서 실행"] ``` *** ## 13\. 하네스가 중요한 이유 같은 모델을 사용해도 Agent의 성능과 안전성은 하네스에 따라 크게 달라질 수 있습니다. 하네스에는 다음이 포함됩니다. * Instructions와 프로젝트 규칙 * 제공되는 도구와 권한 * 컨텍스트 선택 방식 * 상태와 메모리 저장 * 실행 환경과 샌드박스 * 테스트와 출력 검증 * 승인 단계 * 시간·비용·재시도 제한 * 로그와 추적 좋은 모델을 선택하는 것만큼 **모델이 어떤 환경에서 무엇을 보고 어떤 도구를 사용할 수 있는지 설계하는 것**이 중요합니다. *** ## 14\. Agent Loop와 종료 조건 Agent는 목표를 달성할 때까지 다음 행동을 반복할 수 있습니다. 그러나 반복 횟수와 완료 조건이 없으면 비용이 계속 증가하거나 같은 오류를 반복할 수 있습니다. ### 좋은 종료 조건 예시 * 자동 테스트 전체 통과 * 보고서 필수 항목 모두 작성 * 수치의 원본 출처 연결 완료 * 검증 Agent의 승인 * 사람이 최종 승인 ### 안전 제한 * 최대 도구 호출 횟수 * 최대 재시도 횟수 * 전체 실행 시간 * 토큰·API 비용 상한 * 같은 오류가 반복되면 중단 * 진전이 없으면 사람에게 이관 > Agent의 자율성은 무제한 실행이 아니라, **명확한 목표와 경계 안에서 다음 행동을 스스로 선택하는 능력**입니다. *** ## 15\. 단일 Agent와 Multi\-Agent ### 단일 Agent 한 Agent가 여러 도구를 사용해 전체 업무를 수행합니다. #### 장점 * 구조가 단순함 * 컨텍스트와 상태 관리가 쉬움 * 디버깅과 비용 추적이 비교적 쉬움 #### 단점 * 역할이 많아지면 Instructions가 복잡해짐 * 서로 다른 전문 업무가 한 컨텍스트에서 충돌할 수 있음 ### Multi-Agent 여러 전문 Agent가 역할을 나누어 협업합니다. 예시는 다음과 같습니다. * 조사 Agent * 분석 Agent * 작성 Agent * 검증 Agent * 배포 Agent #### 장점 * 전문 역할별 Instructions와 도구 구성 가능 * 독립적인 컨텍스트 사용 * 일부 작업 병렬화 가능 * 생성자와 검증자 분리 가능 #### 단점 * Agent 간 전달 과정에서 정보 손실 가능 * 비용과 실행 시간이 증가할 수 있음 * 오류 원인과 책임 추적이 복잡해짐 * 잘못된 결과가 다음 Agent로 전파될 수 있음 처음에는 단일 Agent로 시작하고, 역할·권한·컨텍스트를 실제로 분리해야 할 이유가 생겼을 때 Multi-Agent로 확장하는 것이 좋습니다. *** ## 16\. Multi\-Agent 협업 방식 OpenAI Agents SDK는 대표적으로 두 가지 협업 패턴을 제공합니다. ### Agent as Tool 메인 Agent가 다른 전문 Agent를 도구처럼 호출합니다. 메인 Agent가 최종 응답과 업무 소유권을 유지합니다. ``` 관리 Agent ├── 조사 Agent 호출 ├── 데이터 분석 Agent 호출 └── 결과를 종합해 최종 답변 ``` 적합한 상황은 다음과 같습니다. * 여러 전문가의 결과를 한 Agent가 종합해야 할 때 * 사용자와 대화하는 담당자를 유지해야 할 때 * 보조 Agent가 결과만 반환하면 될 때 ### Handoff 현재 Agent가 다른 전문 Agent에게 대화와 작업 소유권을 넘깁니다. ``` 접수 Agent → 환불 전문 Agent → 사람 승인 → 처리 완료 ``` 적합한 상황은 다음과 같습니다. * 전문 Agent가 사용자와 직접 대화해야 할 때 * 분야별로 권한과 정책이 뚜렷하게 다를 때 * 다음 Agent가 이후 작업을 끝까지 책임져야 할 때 *** ## 17\. Orchestrator Agent 여러 Agent를 사용하는 시스템에는 작업을 분배하고 결과를 종합하는 Orchestrator가 필요할 수 있습니다. ### 주요 역할 * 요청의 유형 분류 * 적합한 전문 Agent 선택 * 병렬·순차 실행 결정 * Agent 사이에 필요한 상태 전달 * 결과 충돌 해결 * 실패 시 재시도·대체 Agent 선택 * 최종 결과 종합 Orchestrator 자체도 잘못된 Agent를 선택할 수 있으므로 라우팅 정확도와 실패 처리에 대한 평가가 필요합니다. *** ## 18\. Agent와 RAG의 관계 RAG(Retrieval-Augmented Generation)는 관련 문서를 검색해 모델에 제공하는 기술입니다. RAG 자체가 반드시 Agent인 것은 아닙니다. ### 일반 RAG ``` 질문 → 관련 문서 검색 → 문서와 질문을 모델에 전달 → 답변 ``` ### Agentic RAG ``` 질문 분석 → 검색 필요 여부 판단 → 검색어 생성 → 여러 출처 검색 → 결과가 부족하면 검색어 수정 → 출처 충돌 검사 → 답변 작성 ``` Agent는 RAG를 하나의 도구로 사용하며, 검색할지 여부와 몇 번 검색할지, 어떤 출처를 선택할지 동적으로 판단할 수 있습니다. *** ## 19\. AI Agent의 자율성 수준 Agent는 모두 같은 정도로 자율적인 것이 아닙니다. | 수준 | 특징 | 예시 | | --- | --- | --- | | **Level 0: 답변형** | 행동 없이 답변만 생성 | 일반 챗봇 | | **Level 1: 도구 보조형** | 사용자가 요청한 도구를 실행 | 파일 변환, 검색 | | **Level 2: 감독형 Agent** | 여러 단계를 수행하되 중요한 행동 전 승인 | 보고서 작성, PR 초안 | | **Level 3: 제한된 자율 Agent** | 정해진 범위에서 스스로 반복·수정 | 테스트 통과까지 코드 수정 | | **Level 4: 장기 실행 Agent** | 일정·이벤트에 따라 장시간 작업 | 모니터링, 정기 조사, 운영 자동화 | 실제 서비스에서는 위험도가 높을수록 자율성을 낮추고 승인과 검증을 강화해야 합니다. *** ## 20\. 대표적인 AI Agent 유형 ### 연구 Agent 여러 자료를 검색·비교하고 출처가 포함된 보고서를 작성합니다. ### 코딩 Agent 저장소를 이해하고 코드 수정, 테스트, 디버깅과 PR 준비를 수행합니다. ### 고객지원 Agent 문의 내용을 분류하고 고객 정보와 정책을 확인해 답변하거나 담당자에게 이관합니다. ### 데이터 분석 Agent 데이터를 불러오고 정제·분석·시각화한 뒤 인사이트를 설명합니다. ### 브라우저 Agent 웹사이트를 탐색하고 양식을 작성하며 상태를 확인합니다. ### 개인 비서 Agent 메일·일정·문서를 확인하고 업무를 정리하거나 사용자 승인 후 행동합니다. ### 생산·품질 관리 Agent 설비·품질·재고 데이터를 분석하고 이상 징후, 병목과 개선 후보를 찾습니다. *** ## 21\. 상민님께 적용할 수 있는 Agent 예시 ### 21.1 AI 기술 콘텐츠 정리 Agent #### 목표 AI 관련 영상과 이미지를 블로그용 Markdown 자료로 축적합니다. #### 구성 * 영상 자막·웹 검색 도구 * YouTube Summary Skill * 출처 검증 절차 * Markdown 작성·검사 도구 * 파일 저장 기능 #### 실행 흐름 1. 영상 메타데이터와 자막 확인 2. 핵심 개념 분류 3. 공식 자료로 중요한 내용 확인 4. 초보자 친화적인 설명 작성 5. 참고 URL과 체크리스트 추가 6. Markdown 검증 후 저장 ### 21.2 Vue 프로젝트 QA Agent #### 목표 Vue 애플리케이션의 기능과 시각 품질을 함께 검사합니다. #### 도구 * 저장소와 파일 읽기 * 테스트·린트·빌드 * 브라우저와 화면 캡처 * 접근성 검사 #### 완료 조건 * 테스트·빌드 성공 * 콘솔 오류 없음 * 주요 화면 반응형 확인 * 색상·간격·오버플로 문제 보고 ### 21.3 취업 경험 카드 Agent #### 목표 경력 사례를 지원 직무에 맞는 경험 카드와 면접 답변으로 변환합니다. #### 흐름 1. 지원 직무와 질문 분석 2. 관련 경험 검색 3. 상황·문제·행동·성과 구조화 4. 근거 없는 수치 제거 5. 자기소개서와 면접용 버전 생성 6. 글자 수와 중복 경험 검사 *** ## 22\. AI Agent 설계 순서 ### 1단계: 문제와 성공 기준 정의 * 사용자가 해결하려는 문제는 무엇인가? * Agent가 만든 결과를 어떻게 검사할 것인가? * 현재 자동화보다 Agent가 필요한 이유는 무엇인가? ### 2단계: Agent가 필요한 구간 찾기 고정된 코드로 처리할 수 있는 부분과 의미 판단이 필요한 부분을 구분합니다. ### 3단계: 최소 도구 선택 업무에 꼭 필요한 도구만 제공합니다. 읽기와 쓰기 권한도 분리합니다. ### 4단계: 단일 Agent로 시작 Instructions와 도구를 단순하게 유지하고 실제 평가 데이터를 만듭니다. ### 5단계: 상태와 종료 조건 설계 진행 상태, 재시도, 비용, 사람 승인과 완료 기준을 명시합니다. ### 6단계: Guardrails와 승인 추가 위험한 입력·출력·도구 호출을 검사하고 영향력 있는 행동은 사람의 승인을 받습니다. ### 7단계: 관찰 가능성 확보 모델 호출, 도구 호출, 오류, 시간, 비용과 결과를 추적합니다. ### 8단계: 평가 후 확장 단일 Agent의 한계가 측정된 후에만 전문 Agent와 복잡한 그래프로 확장합니다. *** ## 23\. Agent를 만들 때 가장 중요한 완료 조건 완료 조건은 주관적인 문장이 아니라 프로그램 또는 사람이 확인할 수 있어야 합니다. | 모호한 목표 | 검증 가능한 목표 | | ------ | --------- | | 좋은 보고서 작성 | 필수 항목 8개와 모든 수치 출처 포함 | | 버그를 완벽하게 수정 | 재현 테스트와 전체 테스트 통과 | | 고객을 만족시킴 | 정책 준수 답변 생성 및 승인 완료 | | 디자인을 예쁘게 개선 | 지정된 디자인 토큰 준수와 화면 QA 통과 | Agent는 완료 기준이 없으면 불필요한 반복을 하거나 너무 일찍 작업을 끝낼 수 있습니다. *** ## 24\. Guardrails와 Human\-in\-the\-loop ### Guardrails Agent의 입력, 출력 또는 도구 사용을 검사하는 안전장치입니다. #### 입력 Guardrail * 허용되지 않은 요청 차단 * 개인정보·민감정보 감지 * 프롬프트 인젝션 위험 검사 #### 출력 Guardrail * 필수 형식 검사 * 정책 위반 내용 확인 * 개인정보와 비밀정보 제거 * 근거 없는 수치·주장 검사 #### Tool Guardrail * 허용된 인자와 대상만 실행 * 파일 삭제·외부 발송 전 승인 * 운영 시스템 접근 제한 ### Human-in-the-loop Agent가 다음 작업을 수행하기 전에는 사람의 승인이 필요할 수 있습니다. * 금융 거래 * 이메일·메시지 대량 발송 * 계약·환불·보상 확정 * 운영 배포 * 고객 데이터 변경 * 파일 삭제 * 법률·의료·인사상 중요한 결정 *** ## 25\. 주요 보안 위험 ### Prompt Injection 검색한 웹페이지나 문서에 “기존 지시를 무시하라”는 악성 문구가 포함될 수 있습니다. ### 과도한 도구 권한 읽기만 필요한 Agent가 수정·삭제 권한까지 가지면 작은 판단 오류가 큰 피해로 이어질 수 있습니다. ### 데이터 유출 API 키, 개인정보와 사내 문서가 외부 도구 호출이나 로그에 포함될 수 있습니다. ### 잘못된 도구 호출 Agent가 대상, 금액, 수신자와 파일 경로를 잘못 판단할 수 있습니다. ### 무한 루프와 비용 폭증 종료 조건이 없으면 같은 작업과 도구 호출을 반복할 수 있습니다. ### Multi-Agent 오류 전파 한 Agent의 잘못된 결과를 다른 Agent가 사실로 받아들이면서 오류가 확대될 수 있습니다. ### 대응 원칙 * 최소 권한 * 입력·출력과 도구 인자 검증 * 샌드박스 사용 * 비밀정보 분리 * 시간·횟수·비용 제한 * 중요한 행동의 사람 승인 * 실행 로그와 추적 * 신뢰하지 않는 외부 콘텐츠와 시스템 지시 분리 *** ## 26\. Agent 평가\(Evals\) Agent는 같은 입력에도 다른 경로와 도구를 선택할 수 있으므로 최종 답변만 평가해서는 부족합니다. ### 결과 평가 * 목표를 실제로 달성했는가? * 사실과 수치가 정확한가? * 필수 출력 형식을 지켰는가? ### 과정 평가 * 적절한 도구를 선택했는가? * 불필요한 도구 호출이 없었는가? * 위험 행동 전에 승인을 요청했는가? * 실패 후 올바른 경로로 복구했는가? ### 운영 평가 * 평균 실행 시간 * 토큰과 API 비용 * 성공까지 필요한 재시도 횟수 * 사람에게 이관되는 비율 * 오류 발생률 ### 안전 평가 * 프롬프트 인젝션에 저항하는가? * 권한 밖의 행동을 거절하는가? * 민감정보를 노출하지 않는가? * 악의적인 도구 인자를 차단하는가? *** ## 27\. 관찰 가능성\(Observability\) Agent 운영에서는 최종 결과뿐 아니라 어떤 판단과 행동을 거쳤는지 확인할 수 있어야 합니다. 기록해야 할 항목은 다음과 같습니다. * 실행 ID와 사용자 요청 * 사용한 모델 * 도구 호출과 입력·결과 * Agent 간 Handoff * Guardrail 통과·차단 결과 * 사람 승인 요청과 결정 * 오류와 재시도 * 시간·토큰·비용 * 최종 결과와 평가 점수 OpenAI Agents SDK의 Tracing은 모델 호출, 도구 호출, Agent 전환과 Guardrail 등을 구조화해 추적하는 데 사용할 수 있습니다. *** ## 28\. Agent 개발 실패 패턴 ### 목표가 모호하다 성공 기준이 없으므로 Agent가 불필요한 행동을 하거나 임의로 완료를 선언합니다. ### 처음부터 Multi-Agent로 만든다 한 Agent로 충분한 업무를 여러 Agent로 나누면 비용과 디버깅 복잡성만 증가할 수 있습니다. ### 도구를 너무 많이 제공한다 선택 오류와 보안 위험이 늘어납니다. ### 모든 판단을 LLM에 맡긴다 테스트·형식·수치 계산처럼 코드로 검증할 수 있는 부분까지 자연어 판단에 맡깁니다. ### 상태를 대화에만 저장한다 컨텍스트가 길어지거나 세션이 종료되면 진행 상황을 잃습니다. ### Agent의 자기 검토만 믿는다 자신이 만든 결과에 관대할 수 있으므로 결정론적 검사, 별도 검증 Agent 또는 사람이 필요합니다. ### 정상 상황만 테스트한다 외부 API 장애, 권한 부족, 잘못된 입력과 프롬프트 인젝션 상황에서 실패합니다. *** ## 29\. Responses API와 Agents SDK의 차이 OpenAI 공식 문서에서는 직접 루프를 관리할지 SDK가 관리하게 할지에 따라 선택할 수 있다고 설명합니다. | 구분 | Responses API | Agents SDK | | --- | ------------- | ---------- | | **핵심 단위** | 모델 응답 | Agent 실행 | | **루프 관리** | 애플리케이션이 직접 구현 | SDK Runner가 관리 | | **분기·라우팅** | 직접 설계 | 반복 도구 호출과 Handoff 지원 | | **Multi-Agent** | 직접 구현 | Agents-as-tools와 Handoff 제공 | | **상태** | 응답 연결·대화 등을 직접 관리 | 세션과 재개 가능한 실행 상태 지원 | | **Guardrails** | 애플리케이션에서 구성 | 입력·출력·도구 Guardrail과 승인 흐름 지원 | | **추적** | 응답 객체와 API 로그 | 모델·도구·Agent·Handoff 통합 Trace | ### Responses API가 적합한 경우 * 루프와 도구 라우팅을 직접 제어하고 싶습니다. * 기존 애플리케이션 구조에 세밀하게 통합해야 합니다. * Agent 추상화보다 커스텀 모델 기능이 중심입니다. ### Agents SDK가 적합한 경우 * SDK가 Agent Loop와 반복 도구 호출을 관리하기를 원합니다. * 여러 전문 Agent와 Handoff가 필요합니다. * Guardrail, 세션, Trace와 승인 재개 흐름을 활용하고 싶습니다. *** ## 30\. AI Agent 개발 학습 순서 상민님이 AI 개발자 방향으로 공부한다면 다음 순서가 효율적입니다. ### 1단계: LLM과 프롬프트 * System·User Instructions * Structured Output * 컨텍스트 윈도우 * 환각과 불확실성 ### 2단계: Tool Calling * Function Calling * API 연동 * 도구 결과 검증 * 오류와 재시도 ### 3단계: RAG * 문서 분할과 임베딩 * 벡터 검색 * 검색 품질 평가 * 출처 포함 답변 ### 4단계: 단일 Agent * Agent Loop * 상태 관리 * 완료·중단 조건 * Guardrails ### 5단계: Skills와 하네스 * 반복 절차 모듈화 * 프로젝트 규칙 * MCP 연결 * 샌드박스와 승인 ### 6단계: Multi-Agent와 그래프 * Agent as Tool * Handoff * Orchestrator * 병렬 처리와 체크포인트 ### 7단계: Evals와 운영 * Trace 분석 * 데이터셋 기반 평가 * 비용·속도 최적화 * 보안과 권한 관리 *** ## 31\. AI Agent 설계 체크리스트 ### 목표 * 사용자의 문제와 Agent의 목표가 한 문장으로 정의되는가? * 성공 여부를 객관적으로 검사할 수 있는가? * 일반 Workflow보다 Agent가 필요한 이유가 있는가? ### 모델과 Instructions * Agent의 역할과 금지사항이 명확한가? * 작업 난이도에 맞는 모델을 선택했는가? * 불확실할 때 추측하지 않고 질문하도록 했는가? ### 도구 * 필요한 최소 도구만 제공했는가? * 읽기·쓰기·삭제 권한이 분리되어 있는가? * 도구 입력값과 결과를 검증하는가? * 외부 API 장애와 호출 제한을 처리하는가? ### 상태와 루프 * 현재 진행 상황을 구조화된 상태로 기록하는가? * 완료 조건과 최대 재시도 횟수가 있는가? * 중단 후 재개할 수 있는가? * 같은 행동이 중복 실행돼도 안전한가? ### 안전 * Prompt Injection을 고려했는가? * 비밀정보가 모델·도구·로그에 노출되지 않는가? * 영향력 있는 행동 전에 사람 승인이 있는가? * 시간·토큰·비용 제한이 있는가? ### 평가와 운영 * 대표 정상·오류·공격 사례로 테스트했는가? * 모델·도구·Agent 전환을 추적할 수 있는가? * 품질·비용·지연시간 지표를 측정하는가? * 실패한 실행을 재현하고 개선할 수 있는가? *** ## 32\. 핵심 정리 AI Agent는 단순히 대화를 잘하는 AI가 아니라 **목표를 달성하기 위해 정보를 관찰하고, 다음 행동을 판단하고, 도구를 실행하고, 결과를 확인하며, 상태를 갱신하는 애플리케이션**입니다. 핵심 내용을 여섯 문장으로 정리하면 다음과 같습니다. 1. **LLM은 Agent의 두뇌이며, Agent는 지시·도구·상태·실행 루프를 포함한 전체 시스템입니다.** 2. **Skill은 Agent가 특정 업무를 수행하는 매뉴얼이고, MCP는 외부 시스템을 사용하는 통로입니다.** 3. **하네스는 Agent의 규칙·권한·환경·검증을 구성하고, 루프와 그래프는 작업의 실행 흐름을 구성합니다.** 4. **고정할 수 있는 절차는 일반 코드로 만들고, 의미 판단이 필요한 구간에 AI를 배치하는 것이 좋습니다.** 5. **Multi-Agent는 역할 분리가 실제로 필요할 때 도입하며, 처음에는 단일 Agent로 시작하는 편이 안정적입니다.** 6. **완료 조건, 최소 권한, 사람 승인, 실행 로그와 평가가 없는 Agent는 실제 업무에 안전하게 사용하기 어렵습니다.** 결국 좋은 AI Agent를 만드는 일은 모델에게 더 많은 자율성을 주는 것이 아니라, **무엇을 자율적으로 판단하게 하고 무엇을 시스템과 사람이 통제할지 정확하게 설계하는 것**입니다. *** ## 공식 참고자료 * OpenAI Docs — Agents SDK: [https://developers.openai.com/api/docs/guides/agents](https://developers.openai.com/api/docs/guides/agents) * OpenAI Docs — Building agents: [https://developers.openai.com/tracks/building-agents](https://developers.openai.com/tracks/building-agents) * OpenAI Docs — Agent definitions: [https://developers.openai.com/api/docs/guides/agents/define-agents](https://developers.openai.com/api/docs/guides/agents/define-agents) * OpenAI Docs — Running agents: [https://developers.openai.com/api/docs/guides/agents/running-agents](https://developers.openai.com/api/docs/guides/agents/running-agents) * OpenAI Docs — Orchestration and handoffs: [https://developers.openai.com/api/docs/guides/agents/orchestration](https://developers.openai.com/api/docs/guides/agents/orchestration) * OpenAI Docs — Tools: [https://developers.openai.com/api/docs/guides/tools](https://developers.openai.com/api/docs/guides/tools) * OpenAI Docs — Safety in building agents: [https://developers.openai.com/api/docs/guides/agent-builder-safety](https://developers.openai.com/api/docs/guides/agent-builder-safety) * OpenAI Docs — Agent evaluation: [https://developers.openai.com/api/docs/guides/agents/evaluate](https://developers.openai.com/api/docs/guides/agents/evaluate) ## 작성 기준 * OpenAI 공식 문서의 Agent 정의, 도구, 상태, 오케스트레이션, Guardrail과 평가 구조를 기준으로 작성했습니다. * 학습 단계, 자율성 수준과 실무 예시는 이해를 돕기 위해 재구성한 설명입니다. * API와 SDK의 세부 인터페이스는 업데이트될 수 있으므로 실제 구현 시 최신 공식 문서를 확인해야 합니다.

콘텐츠를 불러오는 중..