33일차 회고｜AI Agent·MCP·Tool Calling·미니프로젝트 기획｜AI 오케스트레이션 개발자 국비지원

 

오늘은 AI Agent가 Tool을 어떻게 선택하고 실행하는지, 그리고 그 Tool을 MCP Server와 연결했을 때 전체 구조가 어떻게 달라지는지를 집중적으로 학습했다.
오전에는 MCP의 기본 동작과 Tool Calling을 직접 확인했고, 오후에는 배운 내용을 바탕으로 팀 미니프로젝트의 주제를 정하고 직접 Agent를 기획하는 시간까지 이어졌다.

특히 오늘은 단순히 코드를 작성하는 것보다 “어떤 AI Agent를 만들 것인가?”, “그 Agent에는 어떤 Tool이 필요한가?”를 설계하는 것이 더 중요하다는 점을 체감한 하루였다.

---

1. 오늘 배운 내용

오늘 가장 중요했던 개념은 AI Agent, Tool Calling, MCP Server, RAG였다.

AI Agent는 단순히 질문에 답하는 프로그램이 아니었다

기존에 LLM을 사용했을 때는 사용자가 질문하면 LLM이 답변을 생성하는 구조를 주로 생각했다.

하지만 Tool을 사용할 수 있게 되면 흐름이 달라진다.

사용자 질문 → 사용할 Tool 판단 → Tool에 전달할 arguments 결정 → Tool 실행 → 결과를 LLM에 전달 → 최종 답변

예를 들어 사용자가

“부산에서 10만 원 이하의 호텔을 찾아줘.”

라고 질문한다면 LLM이 단순히 호텔을 추천하는 것이 아니라,

• search_hotel Tool을 사용해야 한다고 판단하고
• city = 부산
• max_price = 100000

같은 arguments를 만들어 Tool을 호출하도록 지시할 수 있다.

Tool의 실행 결과를 다시 LLM에 전달하면 LLM이 그 결과를 바탕으로 최종 답변을 만들어준다.

결국 LLM이 무엇을 할지 판단하고, 실제 작업은 Tool이 수행하는 구조라는 점을 이해하게 됐다.

---

2. MCP Server가 필요한 이유

오늘 수업에서는 MCP가 있다고 해서 AI Agent 자체가 달라지는 것은 아니라는 점도 배웠다.

프로젝트 내부에 Tool을 직접 만들어 사용할 수도 있고, MCP Server에 Tool을 만들어 외부에서 사용할 수도 있다.

중요한 차이는 Tool을 어디에서 관리하고 공유할 것인가에 있다.

예를 들어 날씨처럼 여러 서비스에서 공통적으로 사용할 수 있는 Tool이라면 MCP Server로 분리해 여러 Agent가 사용할 수 있다.

반대로 특정 프로젝트에서만 사용하는 음식 검색 Tool이라면 굳이 MCP Server로 분리하지 않고 프로젝트 내부에 둘 수도 있다.

결국 Tool을 설계할 때는 단순히

“이 기능이 필요하다.”

에서 끝나는 것이 아니라,

“이 Tool은 특정 프로젝트에서만 사용할 것인가?”
“여러 Agent가 공통으로 사용할 것인가?”

까지 생각해야 한다는 것을 배웠다.

---

3. Tool Calling의 전체 흐름을 직접 확인했다

오늘 실습에서 가장 기억에 남았던 부분은 LLM이 Tool과 arguments를 직접 결정한다는 것이었다.

전체 흐름을 정리하면 다음과 같다.

사용자 질문
   ↓
사용 가능한 Tool List 전달
   ↓
LLM
   ↓
사용할 Tool 선택
   ↓
Tool arguments 생성
   ↓
MCP Server에서 Tool 실행
   ↓
Tool 실행 결과
   ↓
LLM에 결과 전달
   ↓
최종 답변

예를 들어

“부산의 현재 날씨를 알려줘.”

라고 질문하면 LLM이 Tool List를 확인한 후 날씨 Tool을 선택하고, 사용자의 질문에서 부산이라는 정보를 추출해서 arguments로 전달한다.

Tool 실행 결과가 다시 LLM으로 전달되고, LLM이 사람이 읽기 좋은 답변으로 만들어준다.

이 과정을 직접 확인하면서 LLM이 단순한 텍스트 생성기가 아니라 Tool을 선택하고 작업을 연결하는 역할까지 할 수 있다는 것을 조금 더 구체적으로 이해하게 됐다.

---

4. Parallel Tool Call도 학습했다

Tool이 여러 개 필요한 경우에는 Tool을 하나씩 순서대로 실행하는 방법도 있지만, 서로 의존하지 않는 Tool이라면 동시에 실행하는 방식을 사용할 수 있다.

예를 들어 세 개의 Tool이 각각 5분씩 걸린다고 가정하면,

순차 실행
Tool 1 → 5분
Tool 2 → 5분
Tool 3 → 5분
총 15분

반면 동시에 실행한다면,

Tool 1 ─┐
Tool 2 ─┼→ 약 5분
Tool 3 ─┘

처럼 처리 시간을 줄일 수 있다.

오늘은 이것을 Parallel Tool Call이라는 개념으로 배웠다.

아직 내가 직접 복잡한 비동기 구조를 구현한 단계는 아니지만, Agent가 여러 Tool을 사용할 때 무조건 반복문으로 하나씩 실행하는 것이 최선은 아니라는 것을 알게 됐다.

---

5. RAG와 일반 DB 검색의 차이

오후에는 Tool에서 데이터를 어떻게 가져올 것인지에 대한 이야기도 이어졌다.

일반적인 데이터베이스 검색은 특정 단어가 정확하게 일치해야 원하는 데이터를 찾기 쉬운 반면, 사용자의 질문은 항상 데이터에 저장된 표현과 똑같지는 않다.

예를 들어 데이터에

“강변에 위치한 호텔입니다.”

라고 저장되어 있는데 사용자가

“물이 보이는 호텔을 찾아줘.”

라고 질문할 수도 있다.

이런 경우 단순한 문자열 검색만으로는 원하는 결과를 찾기 어려울 수 있다.

그래서 RAG(Retrieval-Augmented Generation)와 벡터 검색을 이용해 문장의 의미적 유사도를 기준으로 데이터를 검색하는 방법을 배웠다.

오늘 수업에서는 호텔 정보를 예로 들었지만, 이런 검색 방식은 특정 분야에만 필요한 것이 아니라 사용자의 표현과 데이터의 표현이 다를 수 있는 다양한 AI 서비스에서 활용할 수 있다는 점이 인상적이었다.

반대로 사용자별 피부 타입이나 회원 정보처럼 데이터베이스에서 정확하게 관리되는 정보는 굳이 RAG를 사용할 필요가 없다는 점도 함께 배웠다.

즉,

모든 데이터를 RAG로 처리하는 것이 아니라 데이터의 성격에 따라 DB 검색과 RAG를 구분해야 한다.

는 것이 핵심이었다.

---

6. 오늘 가장 중요했던 것: Agent보다 Tool 설계

오늘 수업에서 가장 크게 느낀 부분은 코딩보다 기획과 설계의 중요성이 커지고 있다는 것이다.

AI Agent를 만든다고 해서 무작정 Agent부터 만드는 것이 아니라,

1. 어떤 문제를 해결할 것인지
2. 어떤 AI Agent가 필요한지
3. Agent가 어떤 Tool을 사용할지
4. 각 Tool에는 어떤 arguments가 필요한지
5. Tool은 MCP Server로 분리할 필요가 있는지
6. 데이터는 DB로 가져올지 RAG로 검색할지

를 먼저 결정해야 한다.

특히 Tool에는 명확한 설명(description)이 필요하다는 점도 중요했다.

LLM은 Tool의 설명과 사용자의 질문을 보고 어떤 Tool을 사용할지 판단하기 때문에, Tool의 역할과 arguments가 애매하면 LLM 역시 엉뚱한 선택을 할 가능성이 높다.

결국 좋은 Agent를 만들기 위해서는 단순히 코드를 많이 작성하는 것보다 LLM이 올바른 판단을 내릴 수 있도록 구조와 Tool을 설계하는 능력이 중요하다는 것을 알게 됐다.

---

7. 오후 미니프로젝트: AI 술집 키오스크

오늘 오후에는 배운 내용을 활용해 팀 미니프로젝트 주제를 정했다.

처음에는 여러 아이디어를 고민했지만 최종적으로 AI 술집 키오스크를 주제로 진행하기로 했다.

일반적인 키오스크는 메뉴를 보여주고 주문을 받는 역할에 집중한다.

하지만 AI Agent를 활용하면 사용자가 메뉴를 고르는 과정에서 질문을 하고 도움을 받을 수 있다.

예를 들어,

“오늘 매콤한 게 먹고 싶은데 뭐가 좋아?”

“이 음식이랑 잘 어울리는 술 추천해줘.”

처럼 자연어로 질문하고 Agent가 필요한 정보를 검색해서 추천할 수 있다.

현재 정한 Agent는 다음과 같다.

🍖 음식 추천 Agent

사용자의 상황과 취향을 바탕으로 적절한 음식을 검색하고 추천한다.

🍺 주류 추천 Agent

선택한 음식이나 사용자의 주류 취향을 바탕으로 어울리는 술을 추천한다.

🥟 사이드메뉴 추천 Agent

선택한 음식과 잘 어울리는 사이드메뉴를 검색하고 추천한다.

🚕 귀가도우미 Agent

술자리를 마친 사용자가 안전하게 귀가할 수 있도록 귀가와 관련된 정보를 제공한다.

나는 이 중에서 오늘 귀가도우미 Agent를 맡아 구현하기로 했다.

---

8. 귀가도우미 Agent를 어떻게 설계할 것인가

오늘은 완성된 서비스를 만드는 것이 아니라 미니프로젝트 수준에서 Agent 하나를 설계하고 구현하는 것이 목표다.

따라서 귀가도우미 Agent 역시 너무 크게 확장하지 않고 핵심 기능에 집중하기로 했다.

기본적인 흐름은 다음과 같이 생각할 수 있다.

사용자
 ↓
“서울대입구역으로 가려는데 어떻게 귀가하지?”
 ↓
AI Agent
 ↓
귀가 관련 Tool 선택
 ↓
목적지 등의 arguments 전달
 ↓
Tool 실행
 ↓
결과를 LLM에 전달
 ↓
귀가 방법 안내

오늘 배운 MCP 구조를 적용하면 귀가 관련 정보를 제공하는 Tool을 MCP Server에 등록하고, AI Agent가 사용자의 질문에 따라 해당 Tool을 선택하도록 만들 수 있다.

이번 미니프로젝트에서는 복잡한 교통 서비스까지 구현하기보다는 Agent → Tool 선택 → MCP 실행 → 결과 전달 → 최종 답변이라는 구조를 직접 경험하는 데 초점을 맞추는 것이 적절하다고 판단했다.

---

9. 오늘 새롭게 이해한 점

처음에는 AI Agent를 생각하면 LLM을 연결하고 프롬프트를 잘 작성하면 되는 것이라고 생각했다.

하지만 오늘 수업을 통해 생각이 조금 바뀌었다.

AI Agent에서 중요한 것은 LLM 자체만이 아니라,

LLM이 어떤 Tool을 사용할 수 있고, 그 Tool을 어떤 기준으로 선택하며, Tool이 어떤 데이터를 가져오고, 그 결과를 어떻게 다시 LLM에게 전달할 것인가

라는 전체 구조였다.

특히 MCP를 배우면서 Tool을 독립적인 서버로 분리하면 여러 Agent가 공통으로 사용할 수 있는 구조를 만들 수 있다는 것도 이해하게 됐다.

그리고 실제 프로젝트에서는 Agent를 만드는 것보다 어떤 Agent와 Tool이 필요한지 먼저 정의하는 기획 능력이 상당히 중요할 것 같다는 생각이 들었다.

---

10. 아직 부족한 부분

아직은 MCP와 AI Agent의 전체적인 흐름을 이해하는 단계다.

특히 다음 부분은 더 연습이 필요하다.

• MCP Server와 Client의 실제 연결 구조
• Tool arguments를 안정적으로 검증하는 방법
• 여러 Tool을 사용하는 Agent의 실행 흐름
• Parallel Tool Call과 비동기 처리
• 실제 DB와 MCP Server 연결
• RAG를 이용한 데이터 검색
• Agent가 여러 개일 때 각각의 역할을 어떻게 나눌지
• Tool description을 LLM이 잘 이해하도록 설계하는 방법

무엇보다 “이 기능을 만들 수 있느냐”보다 “이 기능을 어떤 Agent와 Tool로 나누는 것이 좋은가”를 판단하는 능력을 더 키워야 할 것 같다.

---

11. 오늘의 회고

33일차에는 AI Agent를 단순히 “LLM을 사용하는 프로그램”으로 생각했던 것에서 조금 더 나아갈 수 있었다.

사용자의 질문을 받고, 사용 가능한 Tool을 확인하고, LLM이 필요한 Tool과 arguments를 판단하고, MCP Server에서 실제 Tool을 실행한 뒤 결과를 다시 LLM에게 전달하는 전체 과정을 확인했다.

그리고 오후에는 직접 미니프로젝트 주제를 정하면서 배운 내용을 실제 서비스에 어떻게 적용할지 고민했다.

특히 AI 술집 키오스크의 귀가도우미 Agent를 맡으면서 단순히 기능 하나를 만드는 것보다 먼저

“이 Agent는 어떤 문제를 해결해야 하는가?”
“어떤 Tool이 필요한가?”
“그 Tool에는 어떤 정보가 필요한가?”

를 정의하는 것이 먼저라는 것을 알게 됐다.

앞으로 AI 오케스트레이션을 공부하면서는 코드를 작성하는 것뿐만 아니라 Agent와 Tool을 적절하게 분리하고 설계하는 능력을 함께 키워야겠다.

오늘은 AI Agent를 직접 만들어보는 것보다, AI Agent를 제대로 만들기 위해 무엇을 먼저 설계해야 하는지 이해한 날에 가까웠다.

---

해시태그

#AI오케스트레이션 #AIAgent #MCP #MCPServer #ToolCalling #RAG #LLM #AI에이전트 #Python #개발자국비지원