AI 에이전트란?

AI 에이전트는 추론하고, 툴을 호출하고, 결과를 관찰하는 과정을 반복하며 목표를 추구하는 LLM 기반 시스템입니다. 단순한 LLM 호출은 답하고 멈춥니다. 에이전트는 그 호출을 제어 루프로 감싸고, 여기에 툴(호출할 수 있는 함수), 메모리(단계를 넘나드는 상태), 그리고 행동의 순서를 스스로 고를 수 있을 만큼의 자율성을 더합니다. 백엔드 개발자에게 가장 중요한 변화는 에이전트에 관해 가장 평범하면서도 가장 덜 언급되는 사실에 있습니다. 에이전트의 “툴”은 여러분의 백엔드 엔드포인트입니다. 에이전트가 “툴을 사용한다”는 것은 여러분이 작성한 API를 호출한다는 뜻이며, 따라서 안전이 실제로 자리하는 곳은 프롬프트가 아니라 백엔드입니다.

핵심 요약

AI 에이전트 추론 루프(ReAct)의 동작 방식

목표: "마지막 주문을 환불하고 확인 이메일을 보내 주십시오"

  ┌───────────────────────────────────────────────────┐
  │ 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 — 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 — 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.

// 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.

// 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<Map<String, Any>>("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 에이전트의 네 가지 핵심 구성 요소

정석적인 분해는 모델 + 계획 + 메모리 + 툴 사용이지만, 운영 관점의 버전은 더 단순합니다. 모델이 추론하고, 툴이 행동하며(툴은 백엔드 함수입니다), 메모리가 상태를 보관합니다. 단기 메모리는 컨텍스트 윈도우에, 장기 메모리는 데이터베이스나 벡터 저장소에 있습니다. 그리고 오케스트레이션 루프가 이들을 하나로 묶습니다. 이 루프는 추론과 행동을 교차시키는 ReAct 패턴에 기반합니다.

에이전트 vs. 챗봇 vs. LLM 호출 vs. 워크플로

가장 중요하지만 거의 어떤 용어집도 짚지 않는 구분이 있습니다. 워크플로는 사전 정의된 코드 경로를 통한 오케스트레이션이고, 에이전트는 모델이 스스로 경로를 정하게 합니다. Anthropic의 가이드는 그 결과에 대해 직설적입니다. 에이전트가 필요해 보이는 작업 대부분은 결정적 워크플로로 더 잘 처리되며, 자율성은 경로를 정말로 스크립트로 짤 수 없을 때에만 추가해야 합니다.

신뢰성: 단계마다 곱해지는 오류

벤더 페이지들이 피하는 솔직한 섹션입니다. 에이전트는 단계별로는 인상적이지만 체인 전체로는 취약합니다. 성공 확률은 곱해지기 때문입니다. 각 단계가 확률 p로 성공한다면, n단계 작업은 대략 pⁿ의 확률로 성공합니다.

단계별 성공률      10단계     20단계
     95%            ~60%        ~36%
     90%            ~35%        ~12%
     85%            ~20%         ~4%

인상적인 한 단계를 해내는 데모가 스무 단계를 해내는 시스템은 아닙니다.
실제 환경에서 다단계·다중 시스템 에이전트의 성공률은 흔히 20–40%입니다.

이 계산이 프로덕션의 플레이북을 결정합니다. 체인을 짧게 유지하고, 결과를 그대로 믿지 말고 단계 사이마다 결과를 검증하며, 되돌릴 수 없는 행동(발송, 삭제, 결제, 게시)은 사람의 승인을 거치게 하고, 단계 수와 비용 한도로 루프에 상한을 두어 혼란에 빠진 에이전트가 큰 비용을 치르기 전에 저렴하게 실패하도록 해야 합니다. 신뢰성은 모델이 좋아지기를 기다리는 속성이 아니라, 아키텍처로 부과하는 것입니다.

보안 표면

행동할 수 있는 에이전트는 속아서 행동할 수도 있으며, 이 때문에 에이전트는 진정으로 새로운 공격 표면이 됩니다. 프롬프트 인젝션(prompt injection)은 모델 입력에 담긴 지시를 실제 행동으로 바꿉니다. 위험한 변종은 간접 인젝션입니다. 에이전트가 읽는 오염된 웹 페이지, 이메일, 지원 티켓에 지시가 담겨 있으면, 에이전트는 그 지시를 여러분의 자격 증명으로 실행합니다. 혼동된 대리인(confused deputy)은 그 피해의 형태입니다. 넓은 권한을 가진 에이전트가 조작되어 공격자를 대신해 그 권한을 오용하는 것입니다. 완화책은 새로운 행위자를 겨냥한 오래된 보안 규율입니다. 최소 권한의 사용자 범위 자격 증명(작업을 요청한 사용자가 이미 가진 것 이상을 에이전트에 주지 않음), 기본 거부 원칙의 좁은 범위 툴, 샌드박싱, 그리고 되돌릴 수 없는 모든 작업에 대한 사람의 승인 단계입니다. 가장 중요한 관점은 이것입니다. 보안 경계는 프롬프트가 아니라 백엔드입니다. 프롬프트에는 인젝션이 가능하지만, 서버 측 권한 검사는 말로 설득해 강제를 멈추게 할 수 없습니다.

에이전트가 오용할 수 없는 툴 설계

툴이 곧 백엔드이므로, 툴 설계는 백엔드 보안을 한층 더 엄격하게 적용하는 일입니다. 각 툴은 가능하면 멱등하게 만들고(재시도된 환불이 이중 환불이 되어서는 안 됩니다), 좁은 범위로 두며(원시 데이터베이스 접근이 아니라 명확한 행동 하나), 권한을 적용하고(사용자의 신원으로 실행되며 그 사용자의 ACL이 적용됨), 스키마를 명확히 해야 합니다. 모델이 툴을 호출할지, 어떻게 호출할지를 결정하기 위해 읽는 설명은 프롬프트만큼 공들일 가치가 있습니다. 모호한 툴 설명은 모델이 언젠가 찾아낼 버그이기 때문입니다. 테이블이 아니라 행동을 노출해야 합니다. 자체 검사를 갖춘 refund_order(id)를 노출하고, run_sql(query)는 절대 노출하지 않습니다.

일반적인 사용 사례

• 고객 운영 – 에이전트가 권한이 적용된 툴로 고객 지원 요청을 처음부터 끝까지 해결하며, 환불과 취소에는 사람의 승인을 거칩니다.
• 코딩 어시스턴트 – 저장소를 읽고, 툴을 실행하고, 리뷰를 거칠 변경을 향해 반복합니다.
• 조사와 종합 – 경로를 미리 알 수 없는 다단계 검색과 요약입니다.
• 판단이 필요한 데이터 워크플로 – 단계 사이에 추론이 필요한 작업으로, 고정된 파이프라인만으로는 부족합니다.
• 일정 관리와 조율 – 여러 시스템에 걸친 목표를, 각각 범위가 제한된 툴로 처리합니다.

에이전트를 만들어야 할까? 결정 매트릭스

한계와 트레이드오프

• 자율성은 신뢰성을 내주고 능력을 얻습니다. 에이전트가 열린 목표를 다룰 수 있게 하는 자유는 오류를 누적시키는 바로 그 자유입니다. 의도적으로 범위를 제한해야 합니다.
• 루프에는 돈과 시간이 듭니다. 반복할 때마다 모델 호출이 늘어나므로, 에이전트는 설계상 단일 호출보다 느리고 비쌉니다. 둘 다 상한을 두고 모니터링해야 합니다.
• 비결정성은 테스트를 어렵게 합니다. 워크플로는 단위 테스트를 하지만, 에이전트는 많은 실행에 걸쳐 통계적으로 평가해야 합니다. 같은 입력도 다른 경로를 탈 수 있기 때문입니다.
• 영향 범위는 여러분의 자격 증명입니다. 에이전트의 안전성은 툴에 부여한 권한을 얼마나 좁게 제한했는지에 달려 있습니다. 지나치게 넓은 접근 권한은 언제 터질지 모르는 장애입니다.
• 인상적이라고 신뢰할 수 있는 것은 아닙니다. 인상적인 데모는 운 좋은 체인 하나일 뿐이고, 프로덕션은 가드레일, 승인 게이트, 짧은 경로를 갖추는 지루한 작업입니다.

Back4app에서의 AI 에이전트

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. “툴은 백엔드 함수”라는 명제가 곧 통합의 전부입니다. 에이전트의 툴은 Cloud Code 함수이고, 호출한 사용자의 세션으로 실행되므로 플랫폼의 ACL과 클래스 수준 권한이 에이전트가 시도하는 모든 읽기와 쓰기를 통제합니다. 코드 탭에서 보듯이, 탈취되거나 프롬프트 인젝션을 당한 에이전트도 사용자 본인의 권한을 넘어설 수 없습니다. 혼동된 대리인의 영향 범위는 모델의 올바른 행동이 아니라 접근 제어로 제한되기 때문입니다. 나머지는 자연스럽게 따라옵니다. 원시 데이터가 아니라 범위가 제한된 행동(refundOrder)을 노출하고, 모델 키는 서버 측에 보관하며, 여러 에이전트가 툴 표면을 공유한다면 MCP로 표준화하고, 백엔드가 거절할 수 있게 해야 합니다. 에이전트는 제안하고 백엔드는 결정합니다. 자율 시스템의 안전이 자리해야 할 곳이 바로 거기입니다.