--- term: 'AI 에이전트' seoTitle: 'AI 에이전트란? 루프, 툴, 신뢰성, 보안' headline: 'AI 에이전트란?' slug: ai-agent category: ai-modern-stack shortDefinition: 'AI 에이전트는 추론하고, 툴을 호출하고, 결과를 관찰하는 과정을 반복하며 목표를 추구하는 LLM 기반 시스템입니다.' relatedTerms: - llm-api - model-context-protocol-mcp - cloud-code-serverless-functions - access-control-lists-acl contrastsWith: - llm-api aboutTerms: - 'The Agent Loop (ReAct)' - 'Tools & Function Calling' - 'Agent Memory' faq: - question: 'AI 에이전트를 쉽게 설명하면 무엇입니까?' answer: '언어 모델을 사용해 여러 단계로 이루어진 목표를 스스로 파악하고 수행하는 소프트웨어 시스템입니다. 단순히 대화하는 데 그치지 않고 계획을 세우고, 툴을 사용하고, 행동합니다. 챗봇과의 차이는 자율성입니다. 에이전트는 단계의 순서를 스스로 정하고 툴을 통해 외부 세계에 작용합니다.' - question: 'AI 에이전트와 챗봇의 차이는 무엇입니까?' answer: '챗봇은 응답합니다. 메시지에 답하고 멈춥니다. 에이전트는 행동합니다. 목표에 대해 추론하고, 어떤 툴을 쓸지 결정해 호출하고, 결과를 관찰하며, 작업이 끝날 때까지 계속합니다. 챗봇은 주문 환불에 대해 이야기하고, 에이전트는 실제로 환불합니다.' - question: '에이전트 루프는 어떻게 동작합니까?' answer: '목표를 받고, 다음 단계를 추론하고, 툴을 호출하고, 결과를 관찰하고, 다시 추론합니다. 이 과정을 작업이 끝나거나 단계 수 또는 비용 한도에 도달할 때까지 반복합니다. 이 추론-행동-관찰 주기가 ReAct 패턴이며, 에이전트를 대화형이 아닌 에이전트형으로 만드는 핵심입니다.' - question: '툴과 함수 호출이란 무엇입니까?' answer: '툴은 에이전트가 호출할 수 있는 외부 함수로, API 호출, 데이터베이스 쿼리, 코드 실행 등이 해당합니다. 함수 호출은 그 메커니즘입니다. 모델이 툴 이름과 인수를 담은 구조화된 JSON 호출을 출력하면, 애플리케이션 코드가 이를 실행하고 결과를 모델에 돌려줍니다. 모델은 툴을 직접 실행하지 않으며, 요청할 뿐입니다.' - question: '에이전트 메모리란 무엇입니까?' answer: '두 종류가 있습니다. 단기 메모리는 컨텍스트 윈도우에 들어가는 내용, 즉 최근 단계와 작업 상태입니다. 장기 메모리는 데이터베이스나 벡터 저장소에 영속화되어 세션을 넘어 검색되는 지식입니다. 루프에는 둘 다 필요합니다. 지금 추론하기 위한 윈도우와 나중에 기억하기 위한 저장소입니다.' - question: 'AI 에이전트는 신뢰할 수 있고 프로덕션에 쓸 준비가 되어 있습니까?' answer: '개별 단계는 대체로 신뢰할 만하지만 긴 체인은 그렇지 않습니다. 각 단계의 성공률이 95%라면 10단계는 약 60%, 20단계는 약 36%만 성공합니다. 오류가 누적되기 때문입니다. 프로덕션 에이전트는 체인을 짧게 유지하고, 결과를 검증하며, 되돌릴 수 없는 행동은 사람의 승인을 거치게 하고, 툴이 할 수 있는 일을 제한합니다.' - question: 'AI 에이전트를 사용하지 말아야 할 때는 언제입니까?' answer: '작업이 결정적이고 잘 정의되어 있다면 단순한 워크플로나 일반 코드가 더 저렴하고, 빠르고, 신뢰할 수 있습니다. 에이전트는 경로를 미리 스크립트로 짤 수 없을 때에만 그 복잡성만큼의 가치를 냅니다. 자율성은 기본값으로 넣지 말고, 결과를 분명히 개선한다는 것이 입증될 때 추가해야 합니다.' - question: 'MCP는 AI 에이전트와 어떤 관계입니까?' answer: 'Model Context Protocol은 에이전트가 툴과 데이터를 발견하고 호출하는 방식에 관한 개방형 표준으로, 일회성 연동을 공통 인터페이스로 대체합니다. MCP는 에이전트와 툴 사이의 연결 계층이며, 툴 자체는 여전히 실제 작업을 수행하는 백엔드 함수입니다.' codeLanguages: [javascript, dart, swift, kotlin] externalAuthorities: - name: 'ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., 2022)' url: 'https://arxiv.org/abs/2210.03629' - name: 'Building Effective Agents — Anthropic' url: 'https://www.anthropic.com/engineering/building-effective-agents' - name: 'LLM-Powered Autonomous Agents — Lilian Weng' url: 'https://lilianweng.github.io/posts/2023-06-23-agent/' - name: 'Confused Deputy Attacks on Autonomous AI Agents — Cloud Security Alliance' url: 'https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-agent-confused-deputy-prompt-injection/' - name: 'AI agent — Wikipedia' url: 'https://en.wikipedia.org/wiki/AI_agent' cta: title: '백엔드가 에이전트의 가드레일입니다' text: 'Back4app에서 에이전트의 툴은 사용자 세션으로 실행되는 Cloud Code 함수입니다. 에이전트가 무엇에 접근할 수 있는지는 ACL이 결정하므로, 탈취된 에이전트도 사용자 본인의 권한을 넘어설 수 없습니다.' linkText: '무료로 시작하기' linkUrl: 'https://www.back4app.com/signup' author: 'Back4app Engineering' publishedDate: '2026-10-31' translationKey: ai-agent --- **AI 에이전트는 추론하고, 툴을 호출하고, 결과를 관찰하는 과정을 반복하며 목표를 추구하는 LLM 기반 시스템입니다.** 단순한 [LLM 호출](/glossary/ko/llm-api/)은 답하고 멈춥니다. 에이전트는 그 호출을 제어 루프로 감싸고, 여기에 **툴**(호출할 수 있는 함수), **메모리**(단계를 넘나드는 상태), 그리고 행동의 순서를 스스로 고를 수 있을 만큼의 **자율성**을 더합니다. 백엔드 개발자에게 가장 중요한 변화는 에이전트에 관해 가장 평범하면서도 가장 덜 언급되는 사실에 있습니다. **에이전트의 "툴"은 여러분의 백엔드 엔드포인트입니다.** 에이전트가 "툴을 사용한다"는 것은 여러분이 작성한 API를 호출한다는 뜻이며, 따라서 안전이 실제로 자리하는 곳은 프롬프트가 아니라 백엔드입니다. ## 핵심 요약 | 질문 | 답변 | | --- | --- | | 루프 | 추론 → 행동(툴 호출) → 관찰 → 완료될 때까지 반복(ReAct) | | 네 가지 구성 요소 | 모델(추론) · 툴(행동) · 메모리(상태) · 오케스트레이션(루프) | | vs. 챗봇 | 챗봇은 작업에 대해 *이야기하고*, 에이전트는 작업을 *실행함* | | 냉정한 진실 | 신뢰성은 단계마다 곱해져 *떨어짐*. 단계당 95%면 10단계에서 약 60% | | 안전 경계 | 툴이 할 수 있는 일은 모델의 선의가 아니라 백엔드가 강제함 | ## AI 에이전트 추론 루프(ReAct)의 동작 방식 ```text 목표: "마지막 주문을 환불하고 확인 이메일을 보내 주십시오" ┌───────────────────────────────────────────────────┐ │ 1 REASON 모델: "사용자의 마지막 주문 확인 필요" │ │ 2 ACT 툴 호출: find_orders(user, last=1) │ │ 3 OBSERVE 결과: 주문 #1187, $42, 배송 완료 │ │ 4 REASON "환불 대상, 환불 진행" │ │ 5 ACT 툴 호출: refund_order(1187) │◄─ 모든 ACT가 │ 6 OBSERVE 결과: 환불 완료 │ 여러분의 백엔드를 호출 │ 7 REASON "이제 사용자에게 이메일 발송" │ │ 8 ACT 툴 호출: send_email(...) │ │ 9 REASON "완료" → 최종 답변 │ └───────────────────────────────────────────────────┘ 모델은 툴을 직접 실행하지 않습니다. 툴을 요청(이름 + 인수)할 뿐이며, 코드가 이를 실행하고 그 결과를 다음 추론 단계에 다시 넘깁니다. ``` 그 루프 속 툴을 백엔드에서 구현한 모습입니다. 범위가 제한되고, 권한이 적용되며, 사용자 권한으로 실행됩니다: **JavaScript:** ```javascript // JavaScript — Cloud Code (cloud/main.js) // An agent's "tool" is a backend function — scoped, permissioned, auditable Parse.Cloud.define('refundOrder', async (req) => { // Runs under the CALLING USER's session — ACLs gate everything. // A hijacked agent can't exceed what this user may already do. const asUser = { sessionToken: req.user.getSessionToken() }; const order = await new Parse.Query('Order').get(req.params.orderId, asUser); // ACLs apply via the session token: not your order → this throws, agent or not if (order.get('amount') > 100) throw 'Refunds over $100 need human approval'; order.set('status', 'refunded'); await order.save(null, asUser); return { refunded: order.id }; // the tool result the model reasons over next }); // The backend, not the prompt, is the security boundary. ``` **Flutter:** ```dart // Flutter / Dart — Back4app Flutter SDK // The agent loop runs server-side; the tools it may call are YOUR functions final result = await ParseCloudFunction('runAgent') .execute(parameters: {'goal': 'Refund my last order and email me'}); print(result.result); // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Swift:** ```swift // iOS / Swift — Back4app Swift SDK // The agent loop runs server-side; the tools it may call are YOUR functions let result: [String: Any] = try await Cloud.run( name: "runAgent", parameters: ["goal": "Refund my last order and email me"]) print(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` **Kotlin:** ```kotlin // Android / Kotlin — Back4app Android SDK // The agent loop runs server-side; the tools it may call are YOUR functions val params = mapOf("goal" to "Refund my last order and email me") val result = ParseCloud.callFunction>("runAgent", params) println(result) // The agent reasoned, chose the refundOrder tool, and called it — // but the ACLs on Order decided whether it was ALLOWED to succeed. ``` ## AI 에이전트의 네 가지 핵심 구성 요소 ```mermaid flowchart LR accTitle: AI 에이전트의 네 가지 구성 요소 accDescr: AI 에이전트는 추론을 위한 언어 모델, 행동을 수행하기 위해 호출하는 툴, 상태를 담는 단기 및 장기 메모리, 그리고 목표에 도달할 때까지 추론, 행동, 관찰을 순환하는 오케스트레이션 루프를 결합합니다. 툴은 백엔드 함수와 API입니다. M["모델
(추론 핵심)"] --> O["오케스트레이션 루프
추론 → 행동 → 관찰"] T["툴
(여러분의 API / 함수)"] --> O MEM["메모리
단기(윈도우)
장기(데이터베이스)"] --> O O -->|"툴 호출"| BE[("여러분의 백엔드
+ 데이터")] BE -->|"결과"| O ``` [정석적인 분해](https://lilianweng.github.io/posts/2023-06-23-agent/)는 모델 + 계획 + 메모리 + 툴 사용이지만, 운영 관점의 버전은 더 단순합니다. **모델**이 추론하고, **툴**이 행동하며(툴은 백엔드 함수입니다), **메모리**가 상태를 보관합니다. 단기 메모리는 [컨텍스트 윈도우](/glossary/ko/llm-api/)에, 장기 메모리는 [데이터베이스나 벡터 저장소](/glossary/ko/vector-database-embeddings/)에 있습니다. 그리고 **오케스트레이션 루프**가 이들을 하나로 묶습니다. 이 루프는 추론과 행동을 교차시키는 [ReAct 패턴](https://arxiv.org/abs/2210.03629)에 기반합니다. ## 에이전트 vs. 챗봇 vs. LLM 호출 vs. 워크플로 | | 단순 LLM 호출 | 챗봇 | 워크플로 | AI 에이전트 | | --- | --- | --- | --- | --- | | 하는 일 | 한 번 답함 | 대화함 | 고정된 단계를 실행 | 단계를 스스로 선택 | | 제어 흐름 | 없음 | 턴 주고받기 | **사전 정의된 코드 경로** | **모델이 지시** | | 행동 수행 | 아니요 | 아니요 | 예, 스크립트대로 | 예, 런타임에 결정 | | 예측 가능성 | 호출 단위 | 어느 정도 | **결정적** | **확률적** | | 적합한 용도 | Q&A, 추출 | 고객 지원 채팅 | 정해진 프로세스 | 열린 목표 | 가장 중요하지만 거의 어떤 용어집도 짚지 않는 구분이 있습니다. **워크플로는 사전 정의된 코드 경로를 통한 [오케스트레이션](/glossary/ko/api-orchestration/)이고, 에이전트는 모델이 스스로 경로를 정하게 합니다.** [Anthropic의 가이드](https://www.anthropic.com/engineering/building-effective-agents)는 그 결과에 대해 직설적입니다. 에이전트가 필요해 *보이는* 작업 대부분은 결정적 워크플로로 더 잘 처리되며, 자율성은 경로를 정말로 스크립트로 짤 수 없을 때에만 추가해야 합니다. ## 신뢰성: 단계마다 곱해지는 오류 벤더 페이지들이 피하는 솔직한 섹션입니다. 에이전트는 단계별로는 인상적이지만 체인 전체로는 취약합니다. **성공 확률은 곱해지기** 때문입니다. 각 단계가 확률 *p*로 성공한다면, *n*단계 작업은 대략 *pⁿ*의 확률로 성공합니다. ```text 단계별 성공률 10단계 20단계 95% ~60% ~36% 90% ~35% ~12% 85% ~20% ~4% 인상적인 한 단계를 해내는 데모가 스무 단계를 해내는 시스템은 아닙니다. 실제 환경에서 다단계·다중 시스템 에이전트의 성공률은 흔히 20–40%입니다. ``` 이 계산이 프로덕션의 플레이북을 결정합니다. **체인을 짧게 유지하고**, 결과를 그대로 믿지 말고 단계 사이마다 **결과를 검증하며**, **되돌릴 수 없는 행동**(발송, 삭제, 결제, 게시)은 사람의 승인을 거치게 하고, 단계 수와 비용 한도로 **루프에 상한을 두어** 혼란에 빠진 에이전트가 큰 비용을 치르기 전에 저렴하게 실패하도록 해야 합니다. 신뢰성은 모델이 좋아지기를 기다리는 속성이 아니라, 아키텍처로 부과하는 것입니다. ## 보안 표면 *행동할* 수 있는 에이전트는 *속아서 행동할* 수도 있으며, 이 때문에 에이전트는 진정으로 새로운 공격 표면이 됩니다. **프롬프트 인젝션**(prompt injection)은 모델 입력에 담긴 지시를 실제 행동으로 바꿉니다. 위험한 변종은 *간접* 인젝션입니다. 에이전트가 읽는 오염된 웹 페이지, 이메일, 지원 티켓에 지시가 담겨 있으면, 에이전트는 그 지시를 여러분의 자격 증명으로 실행합니다. **혼동된 대리인**(confused deputy)은 그 피해의 형태입니다. 넓은 권한을 가진 에이전트가 조작되어 공격자를 대신해 그 권한을 오용하는 것입니다. 완화책은 새로운 행위자를 겨냥한 오래된 보안 규율입니다. **최소 권한의 사용자 범위 자격 증명**(작업을 요청한 사용자가 이미 가진 것 이상을 에이전트에 주지 않음), **기본 거부 원칙의 좁은 범위 툴**, 샌드박싱, 그리고 되돌릴 수 없는 모든 작업에 대한 사람의 승인 단계입니다. 가장 중요한 관점은 이것입니다. **보안 경계는 프롬프트가 아니라 백엔드입니다.** 프롬프트에는 인젝션이 가능하지만, 서버 측 [권한 검사](/glossary/ko/access-control-lists-acl/)는 말로 설득해 강제를 멈추게 할 수 없습니다. ## 에이전트가 오용할 수 없는 툴 설계 툴이 곧 백엔드이므로, 툴 설계는 백엔드 보안을 한층 더 엄격하게 적용하는 일입니다. 각 툴은 가능하면 **멱등**하게 만들고(재시도된 환불이 이중 환불이 되어서는 안 됩니다), **좁은 범위**로 두며(원시 데이터베이스 접근이 아니라 명확한 행동 하나), **권한을 적용**하고(사용자의 신원으로 실행되며 그 사용자의 [ACL](/glossary/ko/access-control-lists-acl/)이 적용됨), **스키마를 명확히** 해야 합니다. 모델이 툴을 *호출할지*, *어떻게* 호출할지를 결정하기 위해 읽는 설명은 프롬프트만큼 공들일 가치가 있습니다. 모호한 툴 설명은 모델이 언젠가 찾아낼 버그이기 때문입니다. 테이블이 아니라 *행동*을 노출해야 합니다. 자체 검사를 갖춘 `refund_order(id)`를 노출하고, `run_sql(query)`는 절대 노출하지 않습니다. ## 일반적인 사용 사례 - **고객 운영** – 에이전트가 권한이 적용된 툴로 고객 지원 요청을 처음부터 끝까지 해결하며, 환불과 취소에는 사람의 승인을 거칩니다. - **코딩 어시스턴트** – 저장소를 읽고, 툴을 실행하고, 리뷰를 거칠 변경을 향해 반복합니다. - **조사와 종합** – 경로를 미리 알 수 없는 다단계 검색과 요약입니다. - **판단이 필요한 데이터 워크플로** – 단계 사이에 추론이 필요한 작업으로, 고정된 [파이프라인](/glossary/ko/api-orchestration/)만으로는 부족합니다. - **일정 관리와 조율** – 여러 시스템에 걸친 목표를, 각각 범위가 제한된 툴로 처리합니다. ## 에이전트를 만들어야 할까? 결정 매트릭스 | 상황 | 선택 | | --- | --- | | 단계를 미리 알 수 있는 경우 | [워크플로](/glossary/ko/api-orchestration/). 결정적이고 테스트 가능 | | 단일 질문이나 추출 | 단순한 [LLM 호출](/glossary/ko/llm-api/) | | 열린 목표, 런타임에 결정되는 경로 | 에이전트. 에이전트가 가장 빛나는 영역 | | 루프 안에 되돌릴 수 없는 행동이 있는 경우 | *사람의 승인 게이트를 갖춘* 에이전트 | | 여러 에이전트/모델이 재사용하는 툴이 많은 경우 | [MCP](/glossary/ko/model-context-protocol-mcp/)로 표준화 | | 신뢰성이 안전에 직결되는 경우 | 짧은 체인과 검증, 아니면 자동화하지 않음 | ## 한계와 트레이드오프 - **자율성은 신뢰성을 내주고 능력을 얻습니다.** 에이전트가 열린 목표를 다룰 수 있게 하는 자유는 오류를 누적시키는 바로 그 자유입니다. 의도적으로 범위를 제한해야 합니다. - **루프에는 돈과 시간이 듭니다.** 반복할 때마다 모델 호출이 늘어나므로, 에이전트는 설계상 단일 호출보다 느리고 비쌉니다. 둘 다 상한을 두고 모니터링해야 합니다. - **비결정성은 테스트를 어렵게 합니다.** 워크플로는 단위 테스트를 하지만, 에이전트는 많은 실행에 걸쳐 통계적으로 *평가*해야 합니다. 같은 입력도 다른 경로를 탈 수 있기 때문입니다. - **영향 범위는 여러분의 자격 증명입니다.** 에이전트의 안전성은 툴에 부여한 권한을 얼마나 좁게 제한했는지에 달려 있습니다. 지나치게 넓은 접근 권한은 언제 터질지 모르는 장애입니다. - **인상적이라고 신뢰할 수 있는 것은 아닙니다.** 인상적인 데모는 운 좋은 체인 하나일 뿐이고, 프로덕션은 가드레일, 승인 게이트, 짧은 경로를 갖추는 지루한 작업입니다. ## Back4app에서의 AI 에이전트 Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. "툴은 백엔드 함수"라는 명제가 곧 통합의 전부입니다. 에이전트의 툴은 [Cloud Code 함수](/glossary/ko/cloud-code-serverless-functions/)이고, 호출한 사용자의 세션으로 실행되므로 플랫폼의 [ACL과 클래스 수준 권한](/glossary/ko/access-control-lists-acl/)이 에이전트가 시도하는 모든 읽기와 쓰기를 통제합니다. 코드 탭에서 보듯이, 탈취되거나 프롬프트 인젝션을 당한 에이전트도 *사용자 본인의 권한을 넘어설 수 없습니다*. 혼동된 대리인의 영향 범위는 모델의 올바른 행동이 아니라 접근 제어로 제한되기 때문입니다. 나머지는 자연스럽게 따라옵니다. 원시 데이터가 아니라 범위가 제한된 행동(`refundOrder`)을 노출하고, [모델 키는 서버 측](/glossary/ko/api-key-security/)에 보관하며, 여러 에이전트가 툴 표면을 공유한다면 [MCP](/glossary/ko/model-context-protocol-mcp/)로 표준화하고, 백엔드가 거절할 수 있게 해야 합니다. 에이전트는 제안하고 백엔드는 결정합니다. 자율 시스템의 안전이 자리해야 할 곳이 바로 거기입니다.