### AI Agent의 메커니즘에 대해서 자세히 알아보자. (Tool Calling / Function Calling / Memory) #### 1) 일반 챗봇과 Agent의 근본적 차이 일반 챗봇은 "질문 → LLM → 답변"으로 끝입니다. LLM이 아는 것만 답합니다. Agent는 LLM이 **스스로 판단해서 외부 도구를 호출하고, 그 결과를 다시 보고 다음 행동을 결정**합니다. 즉 LLM이 "생각하는 엔진"이 되고, 실제 작업은 도구가 수행합니다. ``` [일반 챗봇] 질문 → LLM → 답변 [Agent] 질문 → LLM(판단) → 도구 호출 → 결과 확인 → LLM(재판단) → ... → 최종 답변 ↑______________________________________| (필요하면 이 루프를 반복) ``` 이 반복 구조가 핵심입니다. 챗봇은 1턴이고, Agent는 목표 달성까지 여러 턴을 스스로 돕니다. #### 2) Function Calling — Agent를 가능하게 하는 기본 메커니즘 LLM 자체는 코드를 실행하거나 DB를 조회할 수 없습니다. 대신 "이 도구를 이런 인자로 호출해줘"라는 **구조화된 요청(JSON)만 만들어냅니다.** 실제 실행은 개발자가 작성한 코드가 합니다. python ``` from openai import OpenAI import json client = OpenAI() # 1. LLM에게 사용 가능한 도구 목록을 알려줌 tools = [ { "type": "function", "function": { "name": "get_weather", "description": "특정 도시의 현재 날씨를 조회한다", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "도시 이름"} }, "required": ["city"] } } } ] response = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": "수원 날씨 어때?"}], tools=tools ) # 2. LLM은 코드를 실행하지 않고, "이렇게 호출해줘"라는 요청만 반환 tool_call = response.choices[0].message.tool_calls[0] print(tool_call.function.name) # "get_weather" print(tool_call.function.arguments) # '{"city": "수원"}' # 3. 실제 실행은 우리 코드가 담당 def get_weather(city): return f"{city}은 맑음, 24도" # 실제로는 날씨 API 호출 args = json.loads(tool_call.function.arguments) result = get_weather(**args) # 4. 실행 결과를 다시 LLM에게 돌려줘서 최종 답변 생성 messages = [ {"role": "user", "content": "수원 날씨 어때?"}, response.choices[0].message, {"role": "tool", "tool_call_id": tool_call.id, "content": result} ] final = client.chat.completions.create(model="gpt-4o-mini", messages=messages) print(final.choices[0].message.content) # "수원은 현재 맑고 24도입니다." ``` **여기서 오해하기 쉬운 부분**: LLM은 `get_weather`라는 함수를 직접 실행하지 않습니다. "이 함수를 이 인자로 불러야 한다"는 판단만 하고, 실행·API 호출·결과 반환은 전부 개발자 코드가 담당합니다. 이 왕복 구조를 이해하고 있는지 면접에서 종종 확인합니다. #### 3) Tool — Agent가 쓸 수 있는 실제 능력 Tool은 Agent가 호출할 수 있는 외부 기능 전체를 말합니다. | Tool 종류 | 예시 | | ------- | --- | | 검색 | 웹 검색, RAG 문서 검색 | | 계산 | 계산기, 코드 실행(Python sandbox) | | 데이터 | DB 조회, API 호출 | | 액션 | 이메일 발송, 파일 생성, 캘린더 등록 | RAG도 사실 Agent 입장에서는 **하나의 Tool**입니다. "Vector DB 검색"이라는 도구를 LLM이 필요할 때 호출하는 구조로 보면 RAG와 Agent가 자연스럽게 연결됩니다. #### 4) ReAct 패턴 — Agent가 "생각하고 행동하는" 방식 Agent의 대표적인 동작 방식이 ReAct(Reasoning + Acting)입니다. LLM이 생각(Thought) → 행동(Action) → 관찰(Observation)을 반복합니다. ``` 질문: "수원의 현재 기온이 서울보다 높은지 알려줘" Thought: 수원과 서울 날씨를 각각 조회해야 한다 Action: get_weather("수원") Observation: 24도 Thought: 이제 서울 날씨도 필요하다 Action: get_weather("서울") Observation: 21도 Thought: 24 > 21이므로 수원이 더 높다 Final Answer: 네, 수원이 서울보다 3도 더 높습니다 ``` 한 번의 LLM 호출로 끝나지 않고, 도구 결과를 보면서 다음 행동을 스스로 결정하는 게 핵심입니다. #### 5) Memory — Agent가 맥락을 유지하는 방법 Memory는 크게 두 종류로 나눠 이해하면 명확합니다. **단기 기억 (Short-term / Conversation Memory)** 현재 대화 세션 안에서 주고받은 메시지들. 그냥 `messages` 리스트에 계속 쌓아서 매 요청마다 같이 보내는 방식입니다. python ``` messages = [ {"role": "user", "content": "내 이름은 이상민이야"}, {"role": "assistant", "content": "안녕하세요 이상민님"}, {"role": "user", "content": "내 이름이 뭐라고 했지?"} # 앞 대화를 참고해서 답변 ] ``` **장기 기억 (Long-term Memory)** 세션이 끝나도 유지되어야 하는 정보(사용자 선호, 과거 결정사항 등). 이건 대화가 길어지면 전부 프롬프트에 넣을 수 없기 때문에, **Vector DB에 저장해뒀다가 필요할 때만 검색해서 꺼내옵니다.** 여기서 Vector DB가 RAG뿐 아니라 Agent의 기억 저장소로도 쓰인다는 걸 알 수 있습니다. ``` 사용자와의 대화 기록 ↓ 중요한 내용만 요약 ↓ Embedding Vector DB에 저장 ↓ (다음 대화에서) 관련 기억만 검색해서 프롬프트에 삽입 ``` #### 6) LangGraph — 여러 단계를 그래프로 관리 Agent가 복잡해지면 "다음에 뭘 할지"를 코드로 일일이 분기 처리하기 어려워집니다. LangGraph는 Agent의 흐름을 **노드(작업)와 엣지(흐름)로 이루어진 그래프**로 표현해서, 조건 분기·반복·병렬 실행을 관리하기 쉽게 해줍니다. ``` [사용자 입력] ↓ [분류 노드] → 질문 종류 판단 ↓ ┌──┴──┐ [RAG 노드] [계산 노드] ↓ ↓ └────┬────┘ [응답 생성 노드] ↓ [최종 답변] ``` 단순 반복(ReAct)보다 규모가 큰 Agent 시스템(여러 전문 Agent가 협업하는 Multi-agent 구조 등)을 만들 때 주로 씁니다. <br> *** <br> #### 면접 예상 질문 대비 (섹션 5 30번 문항 보강) **Q. Function Calling과 Tool Calling은 같은 건가요?** 거의 같은 개념입니다. Function Calling은 OpenAI가 처음 부른 용어이고, 여러 도구를 다루는 일반적 맥락에서는 Tool Calling / Tool Use라는 표현을 더 많이 씁니다. **Q. Agent가 잘못된 도구를 호출하면 어떻게 하나요?** 도구 설명(description)을 명확하게 작성하는 게 1차 방어선입니다. 그래도 실패하면 도구 실행 결과에 에러를 명시적으로 포함해서 LLM이 스스로 재시도하거나 다른 도구를 선택하도록 유도합니다. **Q. Multi-agent는 왜 필요한가요?** 하나의 Agent가 모든 역할(검색, 코딩, 검토)을 다 하면 프롬프트가 복잡해지고 성능이 떨어집니다. 역할별로 전문 Agent를 나누고(예: 검색 담당, 코드 작성 담당, 검토 담당) 서로 결과를 주고받게 하면 각 Agent가 좁은 범위에 집중해서 정확도가 올라갑니다. **Q. MCP(Model Context Protocol)가 뭔가요?** Agent가 외부 도구·데이터 소스에 연결할 때 매번 다른 방식으로 통합하지 않도록, Anthropic이 제안한 **표준화된 연결 프로토콜**입니다. 도구 제공자가 MCP 서버를 만들어두면 어떤 Agent든 동일한 방식으로 연결해 쓸 수 있습니다.