지난 글에서는 AI Agent가 챗봇과 무엇이 다른지 살펴봤습니다. 챗봇이 주로 대화와 정보 제공에 집중한다면, AI Agent는 주어진 목표를 달성하기 위해 생각하고, 판단하고, 행동하는 시스템이라고 정리했습니다.
이번 글에서는 그다음 질문으로 들어가 보겠습니다. AI Agent는 실제로 어떻게 일할까요? 단순히 “똑똑한 AI가 알아서 한다”라고 말하면 너무 막연합니다. Agent가 목표를 처리하는 내부 흐름을 이해하려면 Thought, Action, Observation이라는 세 단어를 먼저 잡아야 합니다.
이번 글의 핵심 질문
AI Agent는 목표를 받았을 때 어떤 순서로 생각하고, 어떤 도구를 사용하며, 실행 결과를 어떻게 다시 판단에 반영할까요?
목차
1. Agent는 어떻게 일하는가?
AI Agent는 목표를 받으면 바로 최종 답변을 내놓는 것이 아닙니다. 먼저 목표를 이해하고, 필요한 단계를 계획하고, 사용할 도구를 고르고, 실행 결과를 확인한 뒤, 다음 행동을 다시 결정합니다.
이 흐름을 가장 단순하게 표현하면 다음과 같습니다.
AI Agent 기본 작동 흐름
사용자 목표 입력
→ Thought: 무엇을 해야 할지 계획
→ Action: 필요한 도구를 사용해 실행
→ Observation: 실행 결과 확인
→ 다시 Thought: 다음 단계 판단
→ 목표가 완료될 때까지 반복
→ 최종 결과 전달예를 들어 사용자가 “이 고객의 환불 가능 여부를 확인하고, 가능하면 환불 요청까지 처리해줘”라고 말했다고 해보겠습니다. Agent는 이 요청을 단순 질문으로 보지 않습니다. 하나의 목표로 보고, 여러 단계를 나누어 처리합니다.
| 단계 | Agent가 하는 일 | 환불 처리 예시 |
|---|---|---|
| Thought | 목표를 이해하고 필요한 단계를 계획 | 주문 조회와 환불 정책 확인이 필요하다고 판단 |
| Action | 도구나 시스템을 사용해 실제 작업 수행 | 주문 DB 조회, 환불 API 호출 |
| Observation | 실행 결과를 확인하고 다음 판단에 반영 | 배송 완료일과 결제 상태 확인 |
Agent는 한 번 답하고 끝나는 구조가 아닙니다. 계획하고, 실행하고, 결과를 보고, 다시 계획하는 반복 구조로 목표에 가까워집니다.
2. Thought 단계
Thought는 Agent가 목표를 이해하고 다음 행동을 계획하는 단계입니다. 한국어로는 “생각” 또는 “계획”에 가깝습니다.
여기서 중요한 점은 Thought가 단순한 답변 생성이 아니라는 것입니다. Agent는 사용자의 요청을 보고 “이 목표를 달성하려면 어떤 정보가 필요하지?”, “어떤 도구를 써야 하지?”, “먼저 무엇부터 확인해야 하지?”를 판단합니다.
사용자 목표:
이 고객의 환불 가능 여부를 확인하고, 가능하면 환불 요청을 처리해줘.
Thought 단계에서 Agent가 해야 할 판단:
1. 고객을 식별해야 한다.
2. 주문 내역을 조회해야 한다.
3. 배송 상태를 확인해야 한다.
4. 환불 정책을 확인해야 한다.
5. 조건이 맞으면 환불 API를 호출해야 한다.
6. 금액이 크면 사람 승인을 받아야 한다.이 단계가 약하면 Agent는 도구를 아무렇게나 호출하거나, 필요한 정보를 빠뜨리거나, 아직 실행하면 안 되는 작업을 먼저 수행할 수 있습니다.
Planning, Routing, Reflection
Thought 단계와 함께 자주 나오는 개념이 Planning, Routing, Reflection입니다.
| 개념 | 의미 | 예시 |
|---|---|---|
| Planning | 목표를 여러 단계로 나누는 과정 | 주문 조회 → 정책 확인 → 환불 판단 → 처리 |
| Routing | 어떤 도구나 경로로 보낼지 결정하는 과정 | 배송 문의는 배송 API, 결제 문의는 결제 API 사용 |
| Reflection | 실행 결과를 보고 계획이 맞았는지 다시 점검하는 과정 | 주문 조회 실패 후 고객에게 주문번호를 다시 요청 |
실제 서비스에서는 Agent의 내부 Thought를 사용자에게 그대로 보여주지 않는 것이 일반적입니다. 대신 사용자에게는 판단 근거, 실행 결과, 다음에 필요한 정보만 안전하게 보여주는 방식이 좋습니다.
3. Action 단계
Action은 Agent가 실제로 행동하는 단계입니다. 여기서 행동은 꼭 물리적인 행동을 뜻하지 않습니다. API를 호출하거나, 데이터베이스를 조회하거나, 이메일 초안을 만들거나, 캘린더 일정을 생성하는 것도 모두 Action입니다.
LLM만 있는 AI는 말은 잘하지만 실제 시스템을 움직일 수 없습니다. 하지만 Agent는 Tool을 통해 외부 시스템과 연결되기 때문에 실제 업무를 처리할 수 있습니다.
Action 예시
- 고객 DB에서 고객 정보 조회
- 주문 시스템에서 주문 상태 확인
- 결제 API로 환불 가능 여부 확인
- 이메일 시스템으로 안내 메일 작성
- 캘린더 API로 회의 일정 등록
- 검색 도구로 최신 정보 조회Action 단계가 들어가면 AI의 역할이 크게 달라집니다. 단순히 “환불 규정은 이렇습니다”라고 말하는 수준을 넘어, “환불 가능 여부를 확인했고, 승인 요청까지 생성했습니다”처럼 실제 업무 결과를 만들 수 있습니다.
Action이 위험해지는 순간
Action은 Agent의 가장 강력한 부분이지만, 동시에 가장 위험한 부분이기도 합니다. 잘못된 도구를 호출하거나, 잘못된 인자를 넣거나, 권한이 과도하게 부여되어 있으면 실제 피해로 이어질 수 있습니다.
| 위험 상황 | 문제 | 대응 방법 |
|---|---|---|
| 잘못된 Tool 선택 | 배송 조회가 필요한데 환불 API를 호출 | Tool 설명과 사용 조건을 명확히 작성 |
| 잘못된 인자 입력 | 다른 고객의 주문번호로 조회 | 입력 검증과 사용자 확인 단계 추가 |
| 과도한 권한 | Agent가 삭제, 결제, 발송까지 자동 실행 | 권한 최소화와 승인 단계 적용 |
| 반복 호출 | 같은 API를 계속 호출해 비용과 오류 증가 | 최대 반복 횟수와 중단 조건 설정 |
4. Observation 단계
Observation은 Agent가 실행 결과를 확인하는 단계입니다. Action이 “무언가를 했다”라면, Observation은 “그 결과가 어땠는지 확인한다”에 가깝습니다.
Agent가 도구를 호출했을 때 항상 원하는 결과가 나오는 것은 아닙니다. 주문 조회가 실패할 수도 있고, API가 오류를 반환할 수도 있고, 고객 정보가 부족할 수도 있습니다. 이 결과를 보고 다음 행동을 바꾸는 것이 Observation의 역할입니다.
Observation 예시
Action:
주문 시스템에서 주문번호 A1234를 조회한다.
Observation:
주문번호 A1234는 존재하지만, 배송 상태는 아직 "배송 중"이다.
수령일이 없으므로 7일 이내 환불 조건을 바로 판단할 수 없다.
다음 Thought:
고객에게 상품 수령 여부를 확인하거나,
배송 지연 기준에 따른 환불 정책을 조회해야 한다.이처럼 Agent는 실행 결과를 보고 다음 계획을 수정합니다. 그래서 Agent는 단순 자동화보다 유연하게 움직일 수 있습니다.
Observation은 Agent가 현실을 확인하는 과정입니다. 도구를 호출한 결과를 보고, 목표에 가까워졌는지 아니면 다른 행동이 필요한지 판단합니다.
무한 반복을 막는 방법
Agent가 Thought, Action, Observation을 반복할 수 있다는 것은 장점이지만, 잘못 설계하면 같은 행동을 계속 반복할 수도 있습니다. 이를 막기 위해서는 중단 조건이 필요합니다.
- 최대 반복 횟수를 정한다.
- 같은 Tool을 같은 인자로 반복 호출하지 않게 한다.
- 필수 정보가 부족하면 사용자에게 질문하게 한다.
- 중요한 실행 전에는 사람 승인을 요구한다.
- 오류가 일정 횟수 이상 반복되면 상담원이나 관리자에게 넘긴다.
Agent loop는 강력하지만, 무한 반복되면 비용 증가와 시스템 부하로 이어질 수 있습니다. 반드시 최대 반복 횟수, 실패 처리, 사람 개입 조건을 함께 설계해야 합니다.
5. Tool이란?
Tool은 Agent가 외부 세계와 상호작용하기 위해 사용하는 모든 수단입니다. 쉽게 말하면 Agent의 손과 발입니다.
LLM만 있으면 AI는 주로 말만 할 수 있습니다. 하지만 Tool이 연결되면 정보를 조회하고, 계산하고, 메일을 보내고, 예약을 생성하고, 데이터베이스를 수정할 수 있습니다.
| Tool 종류 | 역할 | 예시 |
|---|---|---|
| Search Tool | 외부 정보나 문서를 검색 | 웹 검색, 사내 문서 검색, RAG 검색 |
| Database Tool | 데이터베이스에서 정보를 조회 | 고객 정보 조회, 주문 내역 조회 |
| API Tool | 외부 시스템 기능 호출 | 결제 취소, 배송 조회, 예약 생성 |
| Email Tool | 메일 작성 또는 발송 | 환불 안내 메일, 회의록 공유 |
| Calendar Tool | 일정 확인과 등록 | 회의 시간 확인, 일정 초대 발송 |
| Code Tool | 계산이나 데이터 분석 수행 | CSV 분석, 그래프 생성, 통계 계산 |
Tool schema 설계
Tool schema는 Tool을 Agent에게 설명하는 명세서입니다. “이 도구는 무슨 일을 하는지”, “어떤 입력값을 받아야 하는지”, “언제 사용해야 하는지”를 정의합니다.
Tool schema 예시
도구 이름:
get_order_status
설명:
주문번호를 입력받아 주문 상태, 배송 상태, 결제 상태를 조회한다.
입력값:
- order_id: 주문번호
반환값:
- order_status
- delivery_status
- payment_status
사용 시점:
고객이 주문 상태, 배송 상태, 환불 가능 여부를 물어볼 때 사용한다.Tool 설명이 모호하면 Agent가 잘못된 도구를 고를 가능성이 커집니다. 그래서 Tool schema는 개발자용 문서가 아니라, Agent가 올바르게 행동하도록 돕는 행동 지침이라고 볼 수 있습니다.
6. Function Calling
Function Calling은 LLM이 필요한 함수를 직접 선택하고, 그 함수에 넣을 인자를 구조화해서 생성하는 방식입니다. 쉽게 말하면 “AI가 지금 어떤 함수를 불러야 하는지 판단하고, 함수 호출에 필요한 값을 채워주는 기능”입니다.
예를 들어 고객이 “내 주문이 어디쯤 왔는지 알려줘”라고 물었다고 해보겠습니다. Agent는 이 질문에 답하려면 주문 상태 조회 함수가 필요하다고 판단할 수 있습니다.
사용자 질문:
내 주문 A1234가 어디쯤 왔는지 알려줘.
Agent의 Function Calling 판단:
get_order_status 함수를 호출해야 한다.
함수 호출 인자:
{
"order_id": "A1234"
}여기서 LLM이 실제로 배송 시스템을 직접 조작하는 것은 아닙니다. LLM은 “이 함수를 호출해야 한다”는 구조화된 요청을 만들고, 애플리케이션 코드가 실제 함수를 실행합니다. 실행 결과가 다시 Agent에게 전달되면, Agent는 그 결과를 해석해 사용자에게 답합니다.
Function Calling의 전체 흐름
Function Calling 흐름
1. 개발자가 사용할 수 있는 함수 목록을 Agent에게 제공한다.
2. 사용자가 자연어로 요청한다.
3. Agent가 필요한 함수를 선택한다.
4. Agent가 함수 호출에 필요한 인자를 생성한다.
5. 애플리케이션 코드가 실제 함수를 실행한다.
6. 함수 실행 결과가 Agent에게 돌아온다.
7. Agent가 결과를 바탕으로 최종 답변을 작성한다.| 구분 | 역할 | 예시 |
|---|---|---|
| LLM | 함수 선택과 인자 생성 | get_order_status 선택 |
| 애플리케이션 코드 | 실제 함수 실행 | 주문 DB 조회 |
| 외부 시스템 | 데이터 제공 또는 작업 수행 | 배송 상태 반환 |
| Agent | 결과 해석과 다음 행동 결정 | 배송 지연이면 환불 정책 확인 |
Function Calling은 Agent가 외부 시스템을 안전하게 사용하기 위한 연결 방식입니다. LLM이 직접 시스템을 마음대로 조작하는 것이 아니라, 정해진 함수와 입력 구조 안에서 행동하게 만듭니다.
7. Prompt와 Agent 행동 규칙
Prompt는 Agent에게 “너는 누구고, 무엇을 해야 하며, 어떤 규칙을 따라야 하는지” 알려주는 핵심 지시문입니다.
일반 챗봇의 Prompt가 말투나 답변 형식을 정하는 데 집중한다면, Agent의 Prompt는 훨씬 더 중요합니다. Agent는 실제 도구를 사용하고 시스템을 움직일 수 있기 때문에 행동 규칙이 명확해야 합니다.
Agent Prompt 예시
너는 고객센터 환불 처리 Agent이다.
목표:
고객의 환불 요청을 확인하고, 정책에 따라 가능한 조치를 안내한다.
규칙:
1. 주문 정보를 확인하기 전에는 환불 가능 여부를 확정하지 않는다.
2. 결제 취소나 환불 실행은 10만 원 이하만 자동 처리한다.
3. 10만 원을 초과하는 환불은 관리자 승인을 요청한다.
4. 개인정보는 마스킹해서 출력한다.
5. 문서나 시스템에서 확인되지 않은 내용은 추측하지 않는다.
6. 도구 호출에 실패하면 같은 요청을 2회 이상 반복하지 않고 상담원에게 넘긴다.이런 규칙이 있어야 Agent가 예측 가능한 방식으로 행동합니다. 특히 금전, 개인정보, 외부 발송, 데이터 삭제처럼 위험도가 높은 작업은 Prompt와 시스템 권한을 함께 설계해야 합니다.
Agent Prompt에 들어가야 할 것
| 구성 요소 | 설명 | 예시 |
|---|---|---|
| 역할 | Agent가 어떤 존재인지 정의 | 고객센터 환불 처리 Agent |
| 목표 | Agent가 달성해야 할 최종 목적 | 환불 가능 여부 확인과 처리 안내 |
| 도구 사용 규칙 | 어떤 상황에서 어떤 Tool을 사용할지 정의 | 주문 조회는 get_order_status 사용 |
| 제한 사항 | 자동 처리하면 안 되는 조건 | 고액 환불은 사람 승인 필요 |
| 출력 형식 | 사용자에게 결과를 보여주는 방식 | 결론, 근거, 다음 단계로 구분 |
8. Memory: 단기 기억과 장기 기억
Memory는 Agent가 이전 대화와 작업 내용을 기억하는 능력입니다. Memory가 없으면 Agent는 매번 처음 만나는 사람처럼 행동합니다. 반대로 Memory가 있으면 이전 맥락을 바탕으로 더 자연스럽고 연속적인 업무를 처리할 수 있습니다.
Memory는 크게 Short-term Memory와 Long-term Memory로 나눠볼 수 있습니다.
| 구분 | 의미 | 예시 |
|---|---|---|
| Short-term Memory | 현재 대화나 현재 작업 안에서 유지되는 기억 | 방금 사용자가 말한 주문번호, 현재 문의 내용 |
| Long-term Memory | 대화가 끝난 뒤에도 저장해 두는 장기 정보 | 사용자 선호, 반복 업무 방식, 자주 쓰는 보고서 형식 |
Memory가 필요한 이유
Memory가 있으면 Agent는 같은 정보를 반복해서 묻지 않아도 됩니다. 예를 들어 사용자가 첫 메시지에서 주문번호를 말했고, 두 번째 메시지에서 “그럼 환불은 가능해?”라고 물었다면, Agent는 앞에서 말한 주문번호를 기억하고 이어서 처리할 수 있습니다.
Memory가 없는 경우
사용자:
주문번호 A1234 배송 상태 확인해줘.
Agent:
배송 중입니다.
사용자:
그럼 환불 가능해?
Agent:
어떤 주문에 대한 환불을 말씀하시나요?
Memory가 있는 경우
사용자:
주문번호 A1234 배송 상태 확인해줘.
Agent:
배송 중입니다.
사용자:
그럼 환불 가능해?
Agent:
방금 확인한 주문번호 A1234 기준으로 환불 가능 여부를 확인해보겠습니다.Memory에 저장하면 안 되는 정보
Memory는 편리하지만, 아무 정보나 저장하면 위험합니다. 특히 개인정보나 민감정보를 장기 기억에 저장하는 것은 매우 조심해야 합니다.
| 저장 주의 정보 | 이유 | 대응 방법 |
|---|---|---|
| 주민번호, 계좌번호 | 민감한 식별 정보 | 저장하지 않거나 마스킹 처리 |
| 건강, 금융 정보 | 오용 시 피해가 큰 정보 | 필요 최소한만 임시 처리 |
| 비밀번호, API Key | 유출 시 계정 탈취 위험 | 절대 Memory에 저장하지 않음 |
| 일시적인 정보 | 나중에 의미가 없거나 오히려 혼란을 줄 수 있음 | Short-term Memory에서만 사용 |
Memory는 Agent를 똑똑하게 만들지만, 잘못 설계하면 개인정보 저장소가 될 수 있습니다. 무엇을 기억할지보다 무엇을 기억하지 않을지를 먼저 정해야 합니다.
9. 예시: 환불 처리 Agent
이제 지금까지 본 개념을 하나의 예시로 연결해 보겠습니다. 고객이 환불을 요청하는 상황입니다.
사용자 요청:
지난주에 주문한 상품이 아직 도착하지 않았어요.
배송 상태를 확인하고, 너무 늦으면 환불도 가능한지 봐주세요.이 요청을 챗봇이 받았다면 배송 지연 안내나 환불 규정을 설명하는 데 그칠 수 있습니다. 하지만 Agent는 실제 업무 흐름으로 나누어 처리할 수 있습니다.
| 순서 | Agent 내부 흐름 | 실제 처리 |
|---|---|---|
| 1 | Thought | 배송 상태와 환불 정책을 확인해야 한다고 계획 |
| 2 | Action | 고객 DB에서 최근 주문 목록 조회 |
| 3 | Observation | 최근 주문 1건이 아직 배송 중임을 확인 |
| 4 | Thought | 배송 지연 기준과 환불 가능 조건을 확인해야 한다고 판단 |
| 5 | Action | 환불 정책 문서 검색 Tool 호출 |
| 6 | Observation | 배송 예정일 초과 시 환불 요청 가능 조건 확인 |
| 7 | Action | 환불 요청 초안 생성 또는 승인 요청 |
| 8 | Final Answer | 고객에게 배송 상태, 환불 가능성, 다음 절차 안내 |
사용자에게 보여줄 최종 답변 예시
확인 결과, 최근 주문하신 상품은 현재 배송 중이며 예정일을 초과한 상태입니다.
환불 정책에 따르면 배송 예정일을 초과한 경우 환불 요청이 가능합니다.
다만 실제 환불 실행 전에는 결제 금액과 주문 상태를 한 번 더 확인해야 합니다.
다음 단계:
- 환불 요청을 진행하려면 승인 버튼을 눌러주세요.
- 고액 환불이거나 예외 주문인 경우 상담원 확인이 필요할 수 있습니다.이 예시에서 중요한 것은 Agent가 모든 것을 무조건 자동으로 처리하지 않는다는 점입니다. 위험도가 낮은 조회는 자동으로 수행할 수 있지만, 환불 실행처럼 실제 영향이 있는 작업은 승인 단계를 넣는 것이 안전합니다.
좋은 Agent는 무조건 많이 자동화하는 Agent가 아닙니다. 자동화할 일과 사람에게 넘겨야 할 일을 구분하는 Agent가 실무에서 더 안전합니다.
10. Agent 평가 기준
Agent를 만들었다면 “답변이 자연스러운가?”만 보면 안 됩니다. Agent는 실제 도구를 사용하고 업무를 처리하기 때문에 평가 기준도 더 넓어져야 합니다.
| 평가 기준 | 확인 질문 | 예시 |
|---|---|---|
| 목표 달성률 | 사용자의 목표를 실제로 완료했는가? | 환불 가능 여부 확인 완료 |
| Tool 선택 정확도 | 상황에 맞는 도구를 골랐는가? | 배송 문의에 배송 조회 API 사용 |
| 인자 정확도 | 도구 호출에 필요한 값을 정확히 넣었는가? | 올바른 주문번호로 조회 |
| 안전성 | 위험 작업에서 승인 절차를 거쳤는가? | 고액 환불은 관리자 승인 요청 |
| 반복 제어 | 무한 반복 없이 적절히 중단했는가? | API 오류 2회 후 상담원 연결 |
| 사용자 경험 | 사용자가 현재 진행 상황을 이해할 수 있는가? | 조회 중, 확인 완료, 승인 필요 상태 표시 |
Agent 평가는 답변 품질뿐 아니라 행동 품질까지 봐야 합니다. 어떤 도구를 골랐는지, 어떤 값을 넣었는지, 실패했을 때 어떻게 처리했는지, 위험한 실행을 막았는지가 모두 중요합니다.
11. 정리
AI Agent는 목표를 받으면 Thought, Action, Observation을 반복하며 목표에 가까워집니다. Thought는 목표를 이해하고 계획하는 단계, Action은 도구를 사용해 실제 행동하는 단계, Observation은 행동 결과를 확인하고 다음 판단에 반영하는 단계입니다.
여기에 Tool, Function Calling, Prompt, Memory가 더해지면서 Agent는 단순한 대화형 AI를 넘어 실제 업무를 처리할 수 있게 됩니다. Tool은 Agent의 손과 발이고, Function Calling은 Tool을 구조적으로 호출하는 방식이며, Prompt는 행동 규칙을 정하고, Memory는 이전 맥락을 유지하게 해줍니다.
Agent의 핵심은 반복적 판단과 도구 사용입니다.
목표를 이해하고, 필요한 도구를 사용하고, 결과를 확인한 뒤, 다시 다음 행동을 결정하는 구조가 Agent를 Agent답게 만듭니다.
12. 전체 흐름 한 번에 정리
- Agent는 목표를 받으면 바로 답하지 않고 필요한 단계를 계획한다.
- Thought 단계에서는 목표를 이해하고 어떤 정보와 도구가 필요한지 판단한다.
- Action 단계에서는 API, DB, 이메일, 검색 같은 Tool을 사용해 실제 작업을 수행한다.
- Observation 단계에서는 실행 결과를 확인하고 다음 판단에 반영한다.
- Tool은 Agent가 외부 세계와 상호작용하는 수단이다.
- Function Calling은 Agent가 필요한 함수를 선택하고 입력값을 구조화해 호출하는 방식이다.
- Prompt는 Agent의 역할, 목표, 제한 사항, 행동 규칙을 정한다.
- Memory는 이전 대화와 작업 맥락을 기억하게 해준다.
- Short-term Memory는 현재 대화 안의 맥락을 유지하고, Long-term Memory는 장기적으로 필요한 정보를 저장한다.
- Agent loop는 강력하지만 무한 반복을 막기 위한 중단 조건이 필요하다.
- 실무 Agent는 목표 달성률, Tool 선택 정확도, 안전성, 반복 제어 기준으로 평가해야 한다.
13. 핵심 키워드 정리
| 키워드 | 의미 |
|---|---|
| Thought | 목표를 이해하고 필요한 단계와 도구를 계획하는 과정 |
| Action | Tool이나 시스템을 사용해 실제 작업을 수행하는 과정 |
| Observation | 실행 결과를 확인하고 다음 판단에 반영하는 과정 |
| Tool | Agent가 외부 시스템과 상호작용하기 위해 사용하는 수단 |
| Function Calling | LLM이 필요한 함수를 선택하고 입력값을 구조화해 호출하는 방식 |
| API | Agent가 외부 서비스 기능을 사용하기 위한 연결 통로 |
| Database | 고객 정보, 주문 내역, 업무 데이터를 조회하는 저장소 |
| Email Tool | Agent가 이메일 초안 작성이나 발송을 수행하는 도구 |
| Prompt | Agent의 역할, 목표, 행동 규칙을 정의하는 지시문 |
| Memory | Agent가 이전 대화와 작업 맥락을 기억하는 기능 |
| Short-term Memory | 현재 대화나 현재 작업 안에서 유지되는 임시 기억 |
| Long-term Memory | 대화가 끝난 뒤에도 저장해 두는 장기 정보 |
다음 글 예고
다음 글에서는 Azure AI Foundry를 사용해 Agent를 실제로 설계하고 구축하는 흐름을 살펴보겠습니다. 목표 정의, Tool 연결, Agent 생성, 테스트, 보안 설정까지 Azure AI Foundry 기반 Agent 구현 과정을 실습 중심으로 정리해 보겠습니다.
'Azure OpenAI Engineering > Agent' 카테고리의 다른 글
| [ Azure OpenAI #17 ] Azure AI Foundry로 Agent 만들기: 설계, 구축, 테스트, 보안 (0) | 2026.06.18 |
|---|---|
| [ Azure OpenAI #15 ] AI Agent란 무엇인가? 챗봇, 어시스턴트, Agent의 차이 (0) | 2026.06.18 |