[AI 에이전트] 6주차 실습 - KBO 직관 플래너 Agent 설계하기

2026. 8. 4.원문 보기

#AI Agent

KBO 직관 초심자를 위해 경기·날씨·좌석·교통·티켓 정보를 상황별로 조합하는 Agent를 기획하고, ReAct와 Plan-and-Execute 패턴 및 Tool 명세를 설계했습니다.

5주차까지는 RAG 파이프라인을 구축하고, 검색 및 생성 결과를 Ragas 메트릭으로 평가하는 과정을 진행했습니다.

이번 6주차부터는 정해진 문서를 검색해 답변하는 RAG를 넘어, LLM이 사용자의 요청과 현재 상황을 분석하고 다음 행동을 스스로 선택하는 AI Agent를 설계했습니다.

이번 과제의 핵심은 바로 구현을 시작하는 것이 아니었습니다.

이 문제에 정말 Agent가 필요한가?
→ 어떤 Tool을 사용할 것인가?
→ 요청에 따라 실행 경로가 어떻게 달라지는가?
→ Tool 호출에 실패하면 어떻게 대응하는가?
→ Agent는 언제 실행을 종료하는가?

이 질문들을 코드보다 먼저 문서로 정의하는 것이 이번 실습의 목표였습니다.

저는 KBO 야구장 직관이 처음이거나 익숙하지 않은 구장으로 원정 직관을 가는 사용자를 위해, 경기 일정부터 날씨, 좌석, 이동 동선, 티켓팅, 관전 포인트까지 조합해서 안내하는 KBO 직관 플래너 Agent를 설계했습니다.

과제 안내
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/TASK.md

6주차 참고 자료
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/README.md

제출한 설계 문서
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/DChanhong/design.md

1. 실습 목표

이번 실습의 목표는 만들고 싶은 AI Agent 하나를 정하고, 구현에 필요한 요구사항과 동작 방식을 설계 문서로 정의하는 것입니다.

과제에서는 다음 두 조건을 만족하는 문제를 Agent 후보로 제시했습니다.

사용자 요청에 따라 실행 경로가 달라져야 한다.
Tool을 두 개 이상 사용하며, 상황에 따라 서로 다른 조합으로 호출해야 한다.

특정 PDF에서 답변을 찾거나 텍스트를 JSON으로 변환하는 것처럼 실행 경로가 고정된 작업은 Agent보다 RAG나 일반 Workflow가 더 적합합니다.

반면 야구 직관 계획은 다음 조건에 따라 필요한 정보와 Tool 호출 순서가 달라집니다.

응원하는 팀
경기 날짜와 시간
경기장
출발지
날씨
구장이 돔인지 야외인지
낮 경기인지 야간 경기인지
사용자가 좌석, 교통, 맛집 중 무엇을 원하는지
홈 팬인지 원정 팬인지

따라서 하나의 고정 함수나 정해진 Workflow보다, 상황을 관찰하고 다음 행동을 선택하는 Agent가 적합하다고 판단했습니다.

2. 기획한 Agent

이번에 기획한 Agent의 목적은 야구 직관 초심자가 경기장에 가기 전 필요한 정보를 하나씩 직접 찾지 않아도 되도록, 여러 정보를 상황에 맞게 조합해 개인화된 직관 계획을 제공하는 것입니다.

해결하려는 문제

야구 직관을 처음 가는 사용자는 경기 일정과 티켓만 확인해서는 충분하지 않습니다.

직관 계획을 세우려면 다음 정보를 함께 고려해야 합니다.

경기 일정과 대진
경기 시간
선발 투수와 주요 선수
당일 날씨
구장 구조
햇빛이 드는 좌석
응원석과 시야 좋은 좌석
출발지에서 구장까지의 이동 수단
경기 종료 후 막차
티켓 예매 일정
경기장 주변 맛집
초보자가 알아야 할 야구 규칙

이러한 정보는 서로 독립적이지 않습니다.

예를 들어 같은 잠실 야구장이라도 오후 2시 경기와 오후 6시 30분 경기는 추천 좌석이 달라질 수 있습니다.

비가 오더라도 고척돔 경기는 정상적으로 관람할 수 있지만, 야외 구장은 경기 취소 가능성을 확인해야 합니다.

원정 팬이라면 단순히 좌석을 추천하는 데서 끝나는 것이 아니라, 경기 종료 시간과 기차 또는 버스 막차를 함께 고려해야 합니다.

타깃 사용자

주요 타깃 사용자는 다음과 같습니다.

KBO 직관이 처음이거나,
익숙하지 않은 구장으로 원정 직관을 계획하는 야구 팬

3. 왜 Agent여야 하는가

이 기능을 고정된 Workflow로 구현하면 다음과 같은 순서가 모든 요청에 동일하게 적용됩니다.

경기 조회
→ 날씨 조회
→ 좌석 추천
→ 교통 조회
→ 맛집 추천

하지만 모든 요청에 이 과정이 필요한 것은 아닙니다.

사용자가 “잠실 야구 보고 갈 만한 데 있나?”라고 물었다면 경기장 주변 장소와 경기 종료 후 이동 경로가 중요합니다.

반면 “다음 주 토요일 잠실 롯데전의 그늘진 자리 추천해줘”라고 요청했다면 경기 시간, 날씨, 태양 방향, 좌석 구조를 우선 확인해야 합니다.

다음과 같이 요청에 따라 실행 경로가 달라집니다.

좌석 추천 요청
→ 경기 일정 확인
→ 경기 시간 확인
→ 날씨 확인
→ 구장별 그늘 좌석 검색
→ 준비물 안내

원정 동선 요청
→ 경기 일정 확인
→ 출발지 확인
→ 이동 수단별 경로 검색
→ 경기 종료 예상 시간 확인
→ 막차 및 복귀 경로 구성

티켓팅 요청
→ 경기 대진 확인
→ 예매처 확인
→ 예매 오픈 일정 확인
→ 경기 인기도 분석
→ 난이도별 티켓팅 팁 제공

실행에 필요한 Tool과 순서가 요청마다 달라지므로 Agent가 적합한 문제라고 판단했습니다.

4. Agent 실행 예시

폭염이 예보된 낮 경기를 예로 들 수 있습니다.

초기 관찰

Agent가 날씨와 경기 시간을 확인합니다.

기상 정보
→ 최고 기온 33℃ 이상

경기 시간
→ 오후 2시 낮 경기

실행 경로 변경

일반적인 명당이나 응원석을 추천하는 대신, 더위를 피하는 것을 최우선 조건으로 변경합니다.

기존 계획
→ 시야와 응원 열기 중심 좌석 추천

변경된 계획
→ 폭염 대응 좌석 추천
→ 그늘 좌석 확인
→ 준비물 안내
→ 가까운 음료·빙수 매장 안내

Tool 호출

날씨 조회
→ 현재 기온과 자외선 확인

구장 환경 조회
→ 경기 시간대의 그늘 좌석 검색

준비물 추천
→ 선글라스, 선크림, 쿨링 패치 안내

먹거리 조회
→ 추천 좌석에서 가까운 음료 매장 검색

최종 결과

Agent는 다음 조건을 조합해 최종 답변을 생성합니다.

날씨
+
경기 시간
+
구장 구조
+
좌석 위치
+
경기 정보
=
개인화된 직관 가이드

5. 사용자 시나리오

Persona

항목	내용
이름	김롯데
거주지	부산
역할	주말을 이용해 서울 원정 직관을 계획하는 롯데 자이언츠 팬
목적	익숙하지 않은 잠실 야구장에서 적절한 좌석과 이동 동선을 안내받는 것
주요 관심사	그늘 좌석, 교통, 경기 전후 즐길 거리

대표 요청 1

다음 주 토요일 잠실 롯데전 가려고 하는데,
괜찮은 자리랑 근처 놀 데 추천해줘.

이 요청은 하나의 Tool만으로 처리하기 어렵습니다.

경기 시간과 구장 정보를 확인한 뒤 날씨를 조회해야 하며, 낮 경기라면 그늘 좌석을 찾아야 합니다.

여기에 경기 전후 방문할 장소와 사용자의 이동 동선까지 함께 구성해야 합니다.

대표 요청 2

잠실 야구 보고 갈 만한 데 있나?

이 요청에서는 경기 종료 시간과 사용자가 원정 팬이라는 조건을 함께 고려해야 합니다.

단순히 잠실 주변 장소를 나열하는 것이 아니라, 부산으로 돌아가는 교통수단과 막차 시간을 고려하여 방문 가능한 장소만 추천해야 합니다.

6. 기능 요구사항

기능은 Must-have와 Nice-to-have로 구분했습니다.

Must-have

1) 경기와 날씨 기반 좌석 추천

입력:

응원 팀
경기 날짜

출력:

경기 대진
경기 장소와 시간
당일 날씨
시간대별 좌석 추천
우천 및 폭염 대응 정보
필요한 준비물

낮 경기에서는 햇빛을 피할 수 있는 구역을 우선 추천합니다.

저녁 경기에서는 시야가 좋거나 응원 열기가 높은 구역을 추천할 수 있습니다.

비가 올 때는 구장이 돔인지 야외인지 확인하여 직관 진행 가능성을 판단합니다.

2) 원정 팬 맞춤 동선 설계

입력:

사용자의 출발지
목적 경기장
경기 시간

출력:

기차, 버스, 자차 등 이동 수단 비교
이동 수단별 예상 시간과 비용
추천 출발 시간
경기 종료 후 복귀 경로
막차 정보
경기 전후 방문 장소

3) 티켓 예매 일정과 가이드

입력:

경기 일정
응원 팀
경기장

출력:

예매 오픈 일시
선예매 일정
공식 예매처
경기별 예매 난이도
티켓팅 팁

단순한 예매 링크뿐만 아니라 대진, 주말 경기 여부, 인기 팀 여부 등을 분석하여 티켓팅 난이도를 안내합니다.

4) 관전 포인트와 응원 가이드

입력:

경기 라인업
선수 데이터

출력:

양 팀 선발 투수 기록
최근 경기 성적
주목해야 할 핵심 선수
주요 선수 응원가
초보자를 위한 응원 방법

Nice-to-have

5) 취향과 날씨 기반 먹거리 추천

입력:

사용자 음식 취향
경기장
날씨

출력:

구장 안팎의 먹거리
사용자 취향에 맞는 메뉴
날씨에 적합한 메뉴
폭염이나 우천 시 건강 관련 안내

6) 초보자용 야구 규칙 큐레이션

입력:

사용자의 질문
현재 경기 상황

출력:

기초 야구 규칙
현재 경기와 관련된 규칙
초보자가 이해하기 쉬운 비유
필요에 따른 심화 설명

7. Agent 패턴 선택

이번 설계에서는 하나의 패턴을 모든 기능에 적용하지 않고 기능별 특성에 따라 Plan-and-Execute와 ReAct를 혼합했습니다.

기능	적용 패턴	선택 이유
경기·날씨 기반 좌석 추천	Plan-and-Execute	경기, 날씨, 구장 정보를 순서대로 조회한 뒤 결과를 조합
원정 팬 동선 설계	ReAct	실시간 교통과 막차 등 조회 결과에 따라 다음 행동이 변경
티켓 예매 가이드	ReAct	대진과 인기도에 따라 예매 난이도와 추가 검색이 달라짐
관전 포인트 분석	Plan-and-Execute	선수 데이터를 단계적으로 수집한 뒤 종합 분석
날씨·취향 기반 먹거리	ReAct	날씨와 사용자 취향에 따라 검색 조건을 반복 조정
야구 규칙 설명	Plan-and-Execute	질문 수준을 판단한 뒤 설명 범위와 단계를 계획

8. Plan-and-Execute 패턴

Plan-and-Execute는 먼저 전체 작업 계획을 세운 뒤 각 단계를 순서대로 실행하는 방식입니다.

경기와 날씨 기반 좌석 추천은 필요한 정보가 비교적 명확합니다.

1. 경기 일정 조회
2. 경기 시간 확인
3. 날씨 조회
4. 구장 구조 확인
5. 조건에 맞는 좌석 검색
6. 결과 조합

각 단계의 순서는 정형화되어 있지만 조회 결과에 따라 최종 추천 내용이 달라집니다.

관전 포인트 분석도 비슷합니다.

1. 선발 라인업 조회
2. 양 팀 선발 투수 기록 조회
3. 주요 타자의 최근 성적 조회
4. 기록 비교
5. 핵심 선수 선정
6. 응원 정보 연결

9. ReAct 패턴

ReAct는 다음 루프를 반복하며 문제를 해결합니다.

Thought
→ Action
→ Observation
→ Thought
→ Action
→ Observation
→ Final Response

원정 팬의 이동 동선을 설계할 때는 검색 결과에 따라 다음 행동이 변경됩니다.

Thought
→ 부산에서 잠실까지 이동 수단 확인 필요

Action
→ 기차, 버스, 자차 경로 검색

Observation
→ 기차가 가장 빠르지만 경기 종료 후 막차 시간이 촉박함

Thought
→ 경기 종료 예상 시간과 막차를 비교해야 함

Action
→ 경기 종료 예상 시간과 서울역 이동 시간 조회

Observation
→ 연장전 발생 시 막차 탑승이 어려울 수 있음

Thought
→ 숙박 또는 심야 버스 대안 필요

Action
→ 심야 교통 및 숙박 위치 검색

Final Response
→ 기본 경로와 비상 대안을 함께 제시

이처럼 중간 관찰 결과에 따라 다음 Tool이 달라지는 기능에는 ReAct가 적합합니다.

10. 입력과 출력 명세

입력 스키마

기본 입력은 자연어입니다.

다음 주 토요일 잠실 롯데전 가려는데,
괜찮은 자리 추천해줘.

Agent는 자연어에서 다음 정보를 추출합니다.

날짜
구장 또는 지역
응원 팀
상대 팀
사용자의 주요 목적
출발지
좌석 취향
음식 취향

필수 정보가 누락되면 임의로 결정하지 않고 사용자에게 추가 질문을 합니다.

출력 스키마

최종 결과는 자연어 안내와 구조화된 Metadata를 함께 반환합니다.

{
  "answer": "폭염이 예상되는 낮 경기이므로 3루 상단의 그늘 좌석을 추천합니다.",
  "metadata": {
    "game_time": "14:00",
    "stadium": "잠실야구장",
    "weather": "폭염",
    "recommended_zone": "3루 상단 그늘 구역"
  }
}

자연어 답변은 사용자가 이해하기 쉬운 가이드를 제공하고, Metadata는 이후 화면 구성이나 다른 서비스와의 연동에 사용할 수 있습니다.

11. 정상 실행 흐름

다음 요청을 기준으로 정상 흐름을 설계했습니다.

다음 주 토요일 잠실 롯데전 가려는데,
괜찮은 자리 추천해줘.

Step 1

Thought
→ 날짜, 잠실, 롯데전 키워드를 추출한다.
→ 구체적인 경기 일정과 상대 팀을 먼저 확인해야 한다.

Step 2

Action
→ game_data_provider 호출

Step 3

Observation
→ 14시 경기
→ 잠실야구장
→ 두산 대 롯데

Step 4

Thought
→ 오후 2시 낮 경기이므로 날씨와 자외선이 좌석 선택의 핵심 조건이다.

Step 5

Action
→ stadium_env_expert를 통해 날씨와 좌석 정보 조회

Step 6

Observation
→ 최고 기온 33℃
→ 맑음
→ 자외선 지수 매우 높음
→ 3루 상단과 일부 뒷열에 그늘 형성

Step 7

Final Response
→ 폭염 정보를 안내
→ 그늘 좌석 추천
→ 선글라스, 선크림, 수분 준비 안내

12. 예외 흐름

Agent는 Tool 실패나 정보 부족 상황에서도 실행을 바로 중단하지 않도록 설계했습니다.

Tool 호출 실패

외부 API 호출에 실패하면 내부 정적 데이터나 과거 통계값을 사용합니다.

실시간 날씨 조회 실패
→ 일반적인 계절 기온과 구장 특성 제공
→ 실시간 정보가 아님을 사용자에게 고지

검색 결과 없음

데이터가 없다고 단정하는 대신 가장 가까운 시점이나 대안을 제시합니다.

해당 날짜 경기 없음
→ 인접 날짜의 동일 팀 경기 검색
→ 사용자가 날짜를 다시 선택할 수 있도록 안내

입력 정보 부족

사용자 요청에서 날짜, 구장, 팀 등의 필수 조건이 빠진 경우 추가 정보를 요청합니다.

사용자:
괜찮은 자리 추천해줘.

Agent:
어느 구장과 경기 날짜를 기준으로 추천할까요?

권한 또는 인증 실패

인증이 필요한 API에 접근할 수 없는 경우 권한 오류를 명확히 안내하고, 사용 가능한 공개 데이터로 대체할 수 있는지 판단합니다.

13. 종료 조건

Agent의 무한 반복과 과도한 Tool 호출을 막기 위해 종료 조건을 정의했습니다.

최대 Step 수

단일 질문당 Tool 호출 최대 5회

최대 횟수를 초과하면 현재까지 수집한 정보로 최종 답변을 생성하고, 일부 정보가 불완전할 수 있음을 안내합니다.

정상 종료

다음 중 하나를 만족하면 종료합니다.

LLM이 Final Response를 생성한 경우
Plan-and-Execute의 모든 단계가 성공한 경우
사용자 요청에 필요한 필수 정보가 모두 수집된 경우

반복 탐지

다음 조건에서는 반복으로 판단합니다.

동일한 Tool을 동일한 인자로 2회 연속 호출
최근 3개 Thought가 의미적으로 동일
새로운 정보 없이 동일한 검색을 반복

반복이 감지되면 강제로 종료하고 정보 부족을 사용자에게 안내합니다.

치명적 실패

핵심 Tool인 game_data_provider가 두 번의 재시도 후에도 실패하면 실시간 계획 생성을 중단합니다.

대신 정적 데이터를 기반으로 일반적인 구장 가이드를 제공합니다.

14. Tool 설계

이번 Agent는 총 네 개의 Tool을 사용합니다.

game_data_provider
stadium_env_expert
logistics_planner
baseball_knowledge_base

Tool의 수를 과도하게 늘리지 않고, 서로 관련된 기능을 하나의 Tool로 묶어 Agent의 선택 부담을 줄였습니다.

15. Tool 1: game_data_provider

목적

특정 날짜의 경기 일정, 대진, 구장, 선발 투수 및 라인업 정보를 조회합니다.

입력

{
  "date": "YYYYMMDD",
  "team_name": "string"
}

team_name은 선택값입니다.

출력

{
  "game_info": {
    "home": "LG 트윈스",
    "away": "롯데 자이언츠",
    "stadium": "잠실야구장",
    "time": "14:00"
  },
  "pitchers": {
    "home": "선발 투수 이름",
    "away": "선발 투수 이름"
  },
  "is_dome": false
}

실패 응답

{
  "error": "NOT_FOUND",
  "detail": "해당 날짜에 경기가 없거나 정보를 불러올 수 없습니다."
}

사용 조건

경기 일정 확인
대진 조회
구장 확인
선발 투수와 라인업 조회
돔구장 여부 확인

16. Tool 2: stadium_env_expert

목적

구장별 좌석 특징, 기상 상황, 구장 내외 먹거리 정보를 조회합니다.

입력

{
  "stadium_name": "잠실야구장",
  "date": "2026-05-15",
  "weather_needed": true,
  "food_preference": "시원한 음식"
}

출력

{
  "weather": {
    "temp": 33,
    "condition": "맑음"
  },
  "seat_recommendations": [
    {
      "zone": "3루 상단",
      "reason": "오후 시간대 그늘 형성"
    }
  ],
  "food_list": [
    "시원한 음료",
    "빙수"
  ],
  "tips": "자외선이 강하므로 선크림과 선글라스를 준비하세요."
}

실패 응답

{
  "error": "DATA_INCOMPLETE",
  "detail": "구장 정보 또는 날씨 데이터를 가져오는 데 실패했습니다."
}

사용 조건

좌석 추천
날씨 기반 준비물 안내
구장 먹거리 추천
그늘 구역 확인
돔구장 여부와 우천 대응

17. Tool 3: logistics_planner

목적

사용자의 출발지에서 경기장까지 이동하는 경로와 경기 종료 후 동선을 설계합니다.

입력

{
  "origin": "부산",
  "destination_stadium": "잠실야구장",
  "game_result": null,
  "day_of_week": "토요일"
}

출력

{
  "transport": [
    {
      "type": "KTX",
      "estimated_time": "약 3시간",
      "price": "예상 요금"
    },
    {
      "type": "고속버스",
      "estimated_time": "약 4시간 30분",
      "price": "예상 요금"
    }
  ],
  "recommended_departure": "오전 8시 이전",
  "last_conveyance": "23:50",
  "after_party_spots": [
    {
      "name": "신천시장",
      "distance": "도보 12분"
    }
  ]
}

실패 응답

{
  "error": "ROUTE_NOT_FOUND",
  "detail": "이동 경로를 계산할 수 없거나 인근 장소 정보가 없습니다."
}

사용 조건

원정 팬 동선 설계
막차 확인
이동 수단 비교
경기 후 장소 추천
복귀 시나리오 설계

18. Tool 4: baseball_knowledge_base

목적

티켓 예매 일정과 팁, 야구 규칙을 검색하거나 조회합니다.

입력

{
  "query_type": "ticketing",
  "target_team": "롯데 자이언츠",
  "context": "잠실 주말 원정 경기"
}

query_type은 다음 두 종류를 사용합니다.

ticketing
rule

출력

{
  "info_summary": "경기 예매는 경기일 기준 일주일 전에 시작됩니다.",
  "links": [
    "공식 예매처 링크"
  ],
  "pro_tips": "주말 인기 경기는 예매 시작 전에 결제 수단을 등록하는 것이 좋습니다."
}

실패 응답

{
  "error": "SEARCH_FAILED",
  "detail": "해당 규칙이나 예매 정보를 찾을 수 없습니다."
}

사용 조건

예매 일정 안내
예매처 안내
티켓팅 난이도 분석
야구 규칙 설명
초보자 관전 가이드

19. 데이터 출처

경기 데이터

경기 일정과 결과는 KBO 공식 사이트를 기반으로 수집합니다.

KBO 공식 일정 및 결과
네이버 스포츠 야구 라인업
구장별 정적 Metadata JSON

정적 데이터에는 다음 정보가 포함됩니다.

구장명
홈 팀
돔구장 여부
수용 인원
위도와 경도

날씨 및 구장 정보

기상청 단기예보 API
구장별 좌석 정보
야구 커뮤니티 좌석 후기
구장 주변 맛집 데이터

날씨는 실시간 또는 시간 단위로 갱신하고, 좌석 및 맛집 정보는 시즌별로 갱신합니다.

교통 정보

ODsay 대중교통 API
카카오 장소 검색 API

출발지와 구장 사이의 대중교통 경로, 예상 이동 시간, 막차, 인근 장소 정보를 조회합니다.

티켓 및 규칙 정보

티켓링크
인터파크 티켓
구단별 예매 공지
야구 규칙 정적 데이터

실제 API를 사용할 수 없는 경우에도 동일한 출력 스키마를 가진 Mock 데이터를 사용하도록 설계했습니다.

20. 성공 판정 기준

Agent가 잘 동작하는지 판단하기 위한 기준을 다음과 같이 정의했습니다.

1) 필수 데이터 포함

최종 응답에 다음 정보가 누락되지 않아야 합니다.

경기 시간
경기장
날씨
추천 결과
추천 이유

구조화된 JSON을 반환하는 경우 정의한 스키마를 따라야 합니다.

2) Tool 호출 순서

요청 해결에 필요한 Tool이 타당한 순서로 호출되어야 합니다.

예를 들어 날씨 기반 좌석 추천에서는 경기장을 확인하기 전에 좌석 Tool을 호출하면 안 됩니다.

game_data_provider
→ stadium_env_expert
→ 최종 좌석 추천

3) 예외 대응

Tool 호출에 실패했을 때 다음 중 하나를 수행해야 합니다.

재시도
정적 데이터로 대체
다른 Tool 사용
추가 정보 요청
불완전한 정보임을 고지

4) 실행 효율성

단일 요청은 최대 5회의 Tool 호출 안에 종료되어야 합니다.

5) 반복 방지

동일한 Tool과 인자를 반복 호출하지 않아야 합니다.

이 기준은 이후 Agent 평가에서 Final Response뿐 아니라 Step과 Trajectory를 평가하는 기준으로 사용할 수 있습니다.

21. 현재 설계의 한계

단일 Agent가 경기, 날씨, 교통, 좌석, 티켓, 맛집, 야구 규칙을 모두 처리하면 컨텍스트가 지나치게 커질 수 있습니다.

너무 많은 역할
→ Tool 선택 복잡도 증가
→ Prompt와 Context 증가
→ 응답 시간 증가
→ 잘못된 Tool 선택 가능성 증가

또한 각 데이터는 갱신 주기와 신뢰도가 다릅니다.

경기 일정은 실시간에 가까운 갱신 필요
날씨는 시간 단위 갱신 필요
교통은 요청 시점에 따라 변경
구장 정보는 비교적 정적
티켓 일정은 구단과 예매처마다 다름
커뮤니티 좌석 정보는 주관적일 수 있음

따라서 모든 데이터를 하나의 Agent가 동일한 방식으로 처리하기에는 한계가 있습니다.

22. Multi-Agent 확장

향후에는 Orchestrator와 Worker 구조로 분리할 수 있습니다.

역할	Agent 후보	담당 업무
Orchestrator	경기 운영 본부	사용자 요청 분석, Worker 선택, 결과 취합
Worker 1	경기 데이터 분석관	일정, 라인업, 선수 기록 분석
Worker 2	로컬 가이드	날씨, 좌석, 구장 맛집 안내
Worker 3	교통·물류 팀장	이동 경로, 막차, 뒤풀이 동선 설계
Worker 4	야구 백과사전	티켓팅 정보와 야구 규칙 설명

Orchestrator는 모든 Worker를 고정된 순서로 호출하지 않습니다.

사용자 요청을 분석한 후 필요한 Worker만 선택합니다.

좌석 요청
→ 경기 데이터 분석관
→ 로컬 가이드

교통 요청
→ 경기 데이터 분석관
→ 교통·물류 팀장

규칙 질문
→ 야구 백과사전만 호출

전체 원정 플랜
→ 필요한 Worker들을 병렬 또는 순차 호출
→ Orchestrator가 결과 취합

요청에 따라 Worker의 종류와 호출 순서가 달라지면 고정 Workflow보다 Multi-Agent에 가까운 구조가 됩니다.

23. Memory가 필요한 시나리오

장기적으로는 사용자의 취향과 이전 직관 기록을 기억하는 Memory가 필요합니다.

저장할 수 있는 정보의 예시는 다음과 같습니다.

응원 팀
선호 구장
선호 좌석
응원석 또는 조용한 좌석 선호
음식 취향
출발지
주로 이용하는 교통수단
이전에 방문한 경기장
햇빛이나 더위에 민감한지 여부
가족, 친구, 연인 등 동행 형태

예를 들어 사용자가 이전에 “응원석보다 시야 좋은 좌석을 좋아한다”고 말했다면 다음 요청에서는 응원석보다 중앙 또는 상단 시야석을 우선 추천할 수 있습니다.

이전 대화
→ 응원 열기보다 시야를 선호

새 요청
→ 잠실 좌석 추천

Memory 반영
→ 응원석보다 시야 중심 좌석 우선 추천

24. 실습을 통해 확인한 점

이번 과제를 진행하면서 Agent를 만드는 일은 단순히 LLM에 여러 Tool을 연결하는 것이 아니라는 점을 확인했습니다.

먼저 문제 자체가 Agent에 적합한지 판단해야 했습니다.

실행 순서가 항상 같다면 일반 Workflow가 더 단순하고 안정적입니다.

Agent는 다음 조건이 있을 때 의미가 있습니다.

요청마다 필요한 Tool이 다름
+
중간 결과에 따라 다음 행동이 달라짐
+
실행을 언제 종료할지 판단해야 함

Tool의 설명도 중요했습니다.

Tool 이름만 정의하는 것이 아니라 LLM이 다음 정보를 보고 사용 여부를 판단할 수 있어야 합니다.

Tool의 목적
입력값
반환값
언제 사용하는지
실패하면 무엇을 반환하는지

종료 조건과 반복 탐지 역시 구현 전에 정의해야 했습니다.

Agent에게 명확한 제한을 주지 않으면 동일한 검색을 반복하거나 불필요하게 많은 Tool을 호출할 수 있습니다.

25. 개선해 보고 싶은 부분

Tool 책임 분리

현재 stadium_env_expert는 날씨, 좌석, 맛집을 모두 담당합니다.

구현 과정에서 책임이 너무 넓다고 판단되면 다음과 같이 분리할 수 있습니다.

weather_provider
stadium_seat_provider
stadium_food_provider

다만 Tool이 너무 많아지면 Agent가 적절한 Tool을 선택하기 어려워질 수 있으므로 실제 평가 결과를 보고 결정해야 합니다.

데이터 신뢰도 표시

커뮤니티 기반 좌석 정보와 공식 경기 일정은 신뢰도가 다릅니다.

최종 응답에 출처와 갱신 시점을 함께 표시하는 방식이 필요합니다.

{
  "source": "KBO 공식 일정",
  "updated_at": "2026-05-15T17:35:00Z",
  "confidence": "high"
}

Human-in-the-loop

티켓 구매나 교통편 예약처럼 실제 결제나 예약이 발생하는 기능으로 확장한다면 Agent가 바로 실행해서는 안 됩니다.

검색
→ 후보 추천
→ 사용자 확인
→ 결제 또는 예약 실행

파괴적이거나 비용이 발생하는 동작은 반드시 사용자 확인 단계를 거쳐야 합니다.

평가 데이터셋 구성

다음 주 구현 및 평가 단계에서는 요청 유형별 평가 데이터셋을 만들 수 있습니다.

정상적인 좌석 추천
우천 취소 가능성이 있는 경기
돔구장 경기
출발지가 누락된 요청
막차가 없는 원정 경기
경기 일정이 존재하지 않는 날짜
날씨 API 실패
동일 Tool 반복 호출 가능성이 있는 요청

Final Response뿐 아니라 Tool 호출 순서와 전체 Trajectory도 평가해야 합니다.

26. 느낀 점

기존 RAG 실습에서는 사용자의 질문을 받고 관련 문서를 검색한 뒤 답변을 생성하는 흐름이 비교적 고정되어 있었습니다.

이번 Agent 설계에서는 같은 야구 직관 요청이라도 사용자의 목적과 상황에 따라 필요한 정보가 달라졌습니다.

좌석을 묻는 요청은 날씨와 구장 구조가 중요하고, 원정 동선을 묻는 요청은 교통과 막차가 중요합니다.

티켓팅을 묻는 요청에서는 경기 인기도와 공식 예매 일정이 중요합니다.

이 차이를 설계하면서 Agent와 Workflow의 구분을 조금 더 구체적으로 이해할 수 있었습니다.

또한 Agent에서 중요한 것은 Tool의 개수가 아니라, 필요한 순간에 적절한 Tool을 선택하고 제한된 Step 안에 실행을 끝내는 것이라는 점도 알게 되었습니다.

처음에는 경기, 날씨, 좌석, 교통, 티켓, 맛집을 모두 하나의 Agent로 처리하도록 설계했지만 기능이 늘어날수록 단일 Agent의 역할이 너무 커질 가능성이 보였습니다.

향후 실제 구현 과정에서는 단일 Agent로 먼저 MVP를 만든 뒤, Tool 선택 오류와 컨텍스트 증가 문제가 확인되면 Orchestrator와 Worker 구조로 분리하는 방향이 적합해 보입니다.

27. 핵심 정리

KBO 직관 초심자와 원정 팬을 위한 직관 플래너 Agent를 설계했습니다.
경기, 날씨, 구장, 좌석, 교통, 티켓, 선수 정보를 상황별로 조합하도록 구성했습니다.
요청마다 필요한 Tool과 실행 순서가 달라지므로 고정 Workflow보다 Agent가 적합하다고 판단했습니다.
경기와 날씨 기반 좌석 추천에는 Plan-and-Execute 패턴을 적용했습니다.
교통과 티켓팅처럼 중간 결과에 따라 다음 행동이 달라지는 기능에는 ReAct 패턴을 적용했습니다.
game_data_provider, stadium_env_expert, logistics_planner, baseball_knowledge_base 네 개의 Tool을 설계했습니다.
각 Tool에 입력, 출력, 실패 응답, 사용 조건을 정의했습니다.
자연어 응답과 JSON Metadata를 함께 반환하도록 출력 스키마를 설계했습니다.
Tool 호출은 단일 요청당 최대 5회로 제한했습니다.
동일 Tool과 인자의 반복 호출을 감지하는 종료 조건을 정의했습니다.
외부 API 실패 시 정적 데이터나 과거 통계로 대체하도록 예외 흐름을 설계했습니다.
단일 Agent의 역할이 커지는 문제를 해결하기 위해 향후 Orchestrator와 Worker 기반 Multi-Agent 구조를 고려했습니다.
장기적으로 사용자의 응원 팀, 좌석, 음식, 교통 취향을 저장하는 Memory가 필요합니다.
다음 단계에서는 Final Response뿐 아니라 Tool 호출 Step과 전체 Trajectory를 평가해야 합니다.

참고 자료

과제 안내
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/TASK.md
6주차 참고 자료
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/README.md
제출한 Agent 설계 문서
https://github.com/DChanHong/aiagent-repo/blob/week-6/DChanhong/week-6/DChanhong/design.md