[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_8월 3주차 회고

 

8월 3주차에는 27일차부터 29일차까지 수업을 진행했다.

이번 주에는 본격적으로 LLM을 실제 서비스에 연결하는 방법과 AI Agent의 구조를 공부했다.

지난주까지 Docker, PostgreSQL, Redis, pgvector, Ollama 등을 이용해 AI 서비스를 만들기 위한 개발 환경과 기반 기술을 준비했다면, 이번 주부터는 그 환경 위에서 실제 LLM과 Agent가 어떤 방식으로 동작하는지 살펴보기 시작했다.

27일차에는 LLM과 Agent의 차이, Routing과 Orchestration을 배우고 이미지 분석과 TTS를 연결하는 멀티모달 AI 실습까지 진행했다.

28일차에는 Prompt Engineering과 Structured Output을 중심으로 공부하면서 LLM에게 단순히 질문을 보내는 것이 아니라 어떤 역할을 부여하고, 어떤 형식으로 결과를 받아야 하는지를 학습했다. 이후 Kakao Local API와 Kakao Map을 연결한 부산 여행 가이드 프로젝트를 분석하면서 AI가 생성한 결과를 실제 API와 결합하는 구조도 확인했다.

29일차에는 기존 여행 프로젝트를 Agent와 Tool 구조로 리팩터링했다. 기존 Service를 전부 새롭게 만드는 것이 아니라 Agent → Tool → 기존 Service 형태로 연결하면서 Agent와 Tool, Service의 역할을 직접 구분해봤다. 마지막에는 여행 일정 Agent까지 추가하고 GitHub와 Render를 이용해 실제 배포 환경까지 구성했다.

특히 이번 주에는 AI가 무엇을 답하는가보다 AI의 결과를 어떻게 실제 서비스에 연결할 것인가가 더 중요하다는 점을 많이 느꼈다.

---

주요 학습 내용

1. LLM에서 Agent로 넘어가기

이번 주 가장 먼저 이해하려고 했던 부분은 LLM과 Agent의 차이였다.

처음에는 LLM에게 질문하고 답을 받는 것과 Agent가 크게 다르지 않아 보였다.

하지만 수업을 들으면서 둘의 역할이 조금씩 구분되기 시작했다.

LLM은 주어진 입력을 바탕으로 답변을 생성한다면,

Agent는

사용자 요청
↓
의도 판단
↓
필요한 기능 선택
↓
Tool 사용
↓
결과 확인
↓
최종 답변

처럼 여러 과정을 거쳐 작업을 수행할 수 있다.

예를 들어 사용자가

해운대에서 부모님과 갈 만한 조용한 식당 추천해줘.

라고 입력했다고 하자.

단순 LLM이라면 학습된 지식을 바탕으로 식당을 추천할 수 있다.

하지만 Agent는

사용자가 원하는 것이 무엇인지 판단
→ 해운대라는 지역 확인
→ 식당이라는 카테고리 확인
→ 실제 검색이 필요한지 판단
→ 장소 검색 Tool 선택
→ 외부 API 호출
→ 검색 결과 확인
→ 최종 추천

과 같은 작업을 수행할 수 있다.

그래서 이번 주부터는 단순히

LLM = AI

라고 생각하기보다

LLM은 Agent가 사용하는 핵심 능력 중 하나

라고 이해하는 것이 중요하겠다는 생각이 들었다.

---

2. Routing과 Orchestration 이해하기

여러 Agent를 사용하려면 먼저 사용자의 요청을 적절한 Agent에게 전달해야 한다.

이때 사용하는 개념이 Routing이다.

예를 들어

내일 비 와?

라는 질문은 날씨 Agent로 보내고,

호텔 예약을 취소하고 싶어.

라는 질문은 정책이나 예약 Agent로 보내는 식이다.

가장 단순하게는 특정 키워드를 찾는 방법이 있다.

날씨 / 비 / 우산 → Weather

하지만

내일 하늘에서 물이 떨어질까?

처럼 표현하면 '날씨'라는 단어가 없어도 실제로는 날씨에 대한 질문이다.

그래서 LLM을 이용해 사용자의 의도를 분류하는 방법도 사용할 수 있다.

다만 정확도를 높일 수 있는 대신 LLM을 한 번 더 호출해야 하기 때문에 비용과 속도도 함께 고려해야 한다.

여기서 한 단계 더 나아가 여러 Agent가 서로 다른 작업을 수행하도록 만드는 것이 Orchestration이다.

예를 들어 여행 계획을 하나 만든다고 하면

날씨 확인
→ 관광지 검색
→ 숙소 검색
→ 교통 검색
→ 결과 통합

처럼 여러 작업이 필요하다.

Orchestrator가 각 작업을 적절한 Agent에게 분배하고 마지막에 결과를 하나로 합치는 구조다.

이번 주부터 수업 제목에 들어가는 멀티 에이전트 AI 오케스트레이션이라는 말이 조금씩 구체적으로 이해되기 시작했다.

---

3. Prompt Engineering과 Structured Output

28일차에는 Prompt Engineering을 본격적으로 공부했다.

지금까지는 LLM에게 질문을 전달하면 그에 맞는 답변을 받는 정도로 생각했지만, 실제 서비스에서는 질문을 어떻게 전달할 것인지 자체가 중요한 개발 요소라는 것을 알게 됐다.

예를 들어 사용자가

부산으로 3박 4일 여행 가려고 해.

라고 입력했다고 하자.

그대로 LLM에게 전달할 수도 있지만 실제 서비스에서는

Role
Instruction
Context
Output Format

등을 명확하게 지정하는 것이 좋다.

예를 들어

당신은 한국 여행 전문가입니다.

처럼 역할을 부여하고,

부산 3박 4일 여행 계획을 작성하세요.

처럼 해야 할 일을 지정하고,

사용자는 대중교통을 이용하는 가족 여행객입니다.

처럼 상황을 전달할 수 있다.

그리고 최종 결과의 형식까지 지정하면 프로그램에서 사용하기 훨씬 쉬워진다.

이때 배운 개념이 Structured Output이었다.

예전에는 LLM이 긴 문장을 반환하면 사람이 내용을 다시 해석해야 했다.

하지만

{
  "place_name": "광안리",
  "category": "관광지",
  "address": "...",
  "latitude": 35.1531,
  "longitude": 129.1186
}

처럼 필요한 데이터를 일정한 구조로 받을 수 있다면 Backend나 Frontend에서 바로 사용할 수 있다.

이번 주를 통해 LLM에게 답변을 잘 시키는 것과 프로그램에서 사용할 수 있는 결과를 받는 것은 다른 문제라는 점을 알게 됐다.

---

4. LLM과 외부 API를 연결하기

이번 주에는 Structured Output이 실제 서비스에서 어떻게 사용되는지도 확인했다.

부산 여행 가이드 프로젝트에서는 사용자가

광안리에서 회 맛집 찾아줘.

라고 질문하면 LLM이 모든 답을 직접 만들어주는 것이 아니라,

사용자 질문
→ LLM이 의도와 검색 조건 구조화
→ Kakao Local API 검색
→ 실제 장소 데이터 반환
→ 지도와 카드로 표시

하는 형태로 구성되어 있었다.

이 부분이 특히 인상적이었다.

LLM에게

부산 맛집 추천해줘.

라고만 하면 존재하지 않는 가게나 잘못된 주소를 만들어낼 가능성이 있다.

반면 실제 장소 데이터는 Kakao Local API에서 가져오고 LLM은 사용자의 자연어를 이해해서 검색 조건을 만들어주는 역할을 담당하게 하면 훨씬 안정적인 서비스를 만들 수 있다.

결국

AI에게 모든 것을 맡기는 것이 아니라 AI가 잘하는 일과 API가 잘하는 일을 나누는 것

이 중요하다는 것을 알게 됐다.

---

5. 이미지 분석과 TTS 연결

27일차에는 이미지 분석과 TTS도 직접 연결해봤다.

전체 흐름은

이미지 입력
↓
LLM 이미지 분석
↓
Structured Output
↓
필요한 문장 선택
↓
TTS
↓
MP3 생성

형태였다.

수업에서는 여행 사진을 분석하는 예제를 활용했지만, 나는 이것을 응용해서 축구선수 유니폼 이미지 분석 프로그램으로 바꿔봤다.

유니폼 뒤쪽에 있는 선수 이름과 등번호를 읽고,

class FootballPlayerAnalysis(BaseModel):
    player_name_text: str | None = None
    jersey_number: str | None = None
    uniform_description: str | None = None
    team_guess: str | None = None
    spoken_summary: str | None = None

처럼 구조화된 결과를 만들었다.

그리고

맨체스터 시티의 45번 선수 KHUSANOV로 보입니다.

처럼 생성된 spoken_summary를 다시 TTS에 전달해 음성 파일까지 만들었다.

이미지 분석과 Structured Output, TTS가 각각 따로 존재하는 기능이 아니라 하나의 Workflow로 연결될 수 있다는 점을 직접 경험할 수 있었다.

---

6. Agent와 Tool의 역할을 나누기

29일차에는 기존 부산 여행 프로젝트를 Agent와 Tool 구조로 리팩터링했다.

여기서 가장 중요했던 부분은 모든 기능을 Agent로 만들면 안 된다는 것이었다.

예를 들어 사용자가 화면에서

지역 = 해운대
카테고리 = 카페
키워드 = 오션뷰

를 직접 선택했다면 굳이 Agent가 판단할 필요가 없다.

그냥

사용자 선택
→ 검색 함수
→ 결과

로 처리하면 된다.

반면

해운대에서 부모님이랑 갈 조용한 카페 추천해줘.

처럼 자연어를 해석해야 한다면 Agent가 필요하다.

자연어 질문
→ Agent
→ 의도 분석
→ Tool 선택
→ 실제 장소 검색
→ 결과 반환

형태가 된다.

결국 이번 주에는

판단이 필요한가?

라는 질문이 Agent를 사용할지 결정하는 중요한 기준이라는 것을 배웠다.

---

7. Agent → Tool → Service 구조

기존 프로젝트에서는 ChatService가 여러 기능을 직접 조정하고 있었다.

그래서 이것을

ChatService
↓
BusanPlaceRecommendationAgent
↓
SearchPlacesTool
↓
PlaceSearchService
↓
Kakao Local API

형태로 분리했다.

여기서

Agent
= 무엇을 해야 할지 판단

Tool
= Agent가 사용할 수 있는 기능

Service
= 실제 비즈니스 로직 수행

이라고 이해했다.

특히 좋았던 점은 기존 코드를 전부 다시 만들지 않았다는 것이다.

이미 Kakao API를 호출하고 검색 조건을 처리하는 Service가 있다면 그것을 그대로 활용하고 Tool이 중간에서 연결해주는 방식이다.

이렇게 하면 기존 코드의 재사용성을 유지하면서 Agent 구조를 추가할 수 있다.

이번 실습을 통해 단순히 코드를 많이 작성하는 것보다 역할을 어떻게 나누는지가 중요하다는 것을 조금 더 체감했다.

---

실습 및 문제 해결

이번 주에는 AI 기능 자체보다 실제 개발 환경에서 발생하는 문제를 해결하는 과정에서도 많이 배웠다.

1. localhost와 배포 환경의 차이

로컬에서는

http://127.0.0.1:8000

으로 Backend에 접근할 수 있었다.

하지만 Streamlit을 외부에 배포하면 127.0.0.1은 내 컴퓨터의 Backend가 아니라 배포된 서버 자신의 localhost를 의미하게 된다.

그래서 실제 Backend가 Render에 있다면 Frontend에서는 Render 주소를 사용해야 했다.

이번 문제를 통해 개발 환경과 배포 환경의 주소를 분리하고 환경변수를 이용해 관리하는 것이 중요하다는 것을 알게 됐다.

---

2. Render Build 오류

배포 과정에서는 Build Command의 작은 오타 때문에 배포가 실패하는 문제도 있었다.

예를 들어

python -m pip install -r requirements.txt"

처럼 불필요한 따옴표 하나가 들어가 있어 Build가 실패했다.

코드에 문제가 있는 줄 알고 확인했지만 실제 원인은 배포 설정이었다.

그래서 배포 문제가 발생하면

Build Command
Start Command
requirements.txt
Python 버전
환경변수
GitHub Commit

등을 함께 확인해야 한다는 것을 배웠다.

---

3. 외부 API와 SDK 문제

Agent 구조로 리팩터링한 뒤에는 Kakao API의 403 오류, JavaScript SDK 도메인 설정 문제, Gemini SDK 버전 문제 등도 경험했다.

이전에는 오류가 발생하면 코드부터 수정하려는 경우가 많았는데 이번 주에는

코드 문제인가?
↓
환경변수 문제인가?
↓
SDK 버전 문제인가?
↓
외부 API 설정 문제인가?
↓
배포 환경 문제인가?

순서대로 원인을 좁혀가는 습관이 필요하다는 것을 느꼈다.

---

이번 주에 가장 많이 배운 것

이번 주를 한 문장으로 정리하면

LLM을 호출하는 것과 AI 서비스를 만드는 것은 전혀 다른 문제다.

라고 할 수 있을 것 같다.

처음에는

사용자 질문
↓
LLM
↓
답변

정도만 생각했다.

하지만 이번 주에는

사용자 입력
↓
Prompt
↓
Routing
↓
Agent
↓
Tool
↓
외부 API / DB
↓
결과 검증
↓
Structured Output
↓
Frontend

처럼 훨씬 많은 과정이 필요하다는 것을 알게 됐다.

그리고 AI가 모든 것을 처리하게 하는 것이 아니라

LLM이 잘하는 것
= 자연어 이해, 판단, 생성

API가 잘하는 것
= 실제 데이터 검색

DB가 잘하는 것
= 데이터 저장

Frontend가 잘하는 것
= 사용자에게 결과 표시

처럼 각각의 역할을 나누는 것이 중요했다.

결국 AI 서비스를 만드는 개발자는 단순히 프롬프트를 작성하는 사람이 아니라 각 기술을 어떻게 연결할지 설계하는 사람에 가까운 것 같다.

---

KPT 회고

Keep

이번 주에도 기능을 만들고 끝내지 않고 실제 동작 과정과 오류까지 확인하는 방식을 계속 유지하고 싶다.

특히 LLM이 만들어준 결과를 그대로 사용하는 것이 아니라 Structured Output과 Validation, 실제 API 데이터를 통해 한 번 더 확인하는 습관을 계속 가져가려고 한다.

또 기존 Service를 그대로 활용하면서 Agent와 Tool을 추가했던 것처럼, 무조건 코드를 새로 작성하기보다 현재 프로젝트의 구조를 먼저 이해한 뒤 필요한 부분만 개선하는 방식도 계속 연습하고 싶다.

---

Problem

이번 주에는 Agent, Tool, Routing, Orchestration, Structured Output처럼 비슷하게 느껴지는 개념이 한꺼번에 등장해서 처음에는 서로의 차이가 헷갈렸다.

또 LLM 자체를 사용하는 것보다 Prompt, JSON 구조, API 연동, 환경변수, 배포 설정까지 함께 고려해야 해서 프로젝트 전체 구조를 이해하는 것이 생각보다 어려웠다.

특히 AI 코딩 도구를 이용하면 코드는 빠르게 만들어지지만 내가 그 코드를 왜 그렇게 작성했는지 이해하지 못하면 조금만 구조가 달라져도 직접 수정하기 어렵다는 점을 다시 느꼈다.

---

Try

앞으로는 AI에게 바로 코드를 만들어달라고 하기보다 먼저

현재 프로젝트 분석
↓
구조 이해
↓
구현 계획 작성
↓
PLAN.md 정리
↓
사람이 계획 검토
↓
구현
↓
변경된 코드 다시 공부

순서로 작업하는 습관을 만들려고 한다.

특히 Agent를 추가할 때도

어떤 요청을 받을 것인가?
↓
Agent가 필요한가?
↓
어떤 Agent가 담당하는가?
↓
어떤 Tool이 필요한가?
↓
기존 Service를 재사용할 수 있는가?

를 먼저 생각해보려고 한다.

---

다음 주 계획

다음 주부터는 이번 주에 배운 Agent와 Tool 구조를 바탕으로 여러 Agent가 협업하는 멀티 에이전트 시스템을 더 본격적으로 공부하게 될 것 같다.

특히 Routing과 Orchestration, RAG, Memory, LangGraph 등의 개념이 실제 Agent 구조에서 어떻게 연결되는지 다시 정리해보고 싶다.

또 지금까지는 수업에서 제공된 프로젝트를 중심으로 따라가는 경우가 많았기 때문에, 배운 구조를 내가 직접 작은 서비스로 다시 만들어보면서 Agent를 어디에 사용해야 하고 어디에는 사용하지 않아야 하는지 감각을 익히는 것도 목표로 잡고 있다.

---

8월 3주차는 지금까지 배웠던 개발 환경 위에 드디어 LLM과 Agent를 실제 서비스 구조로 연결하기 시작한 한 주였다.

지난주까지는

"AI 서비스를 만들기 위한 환경을 어떻게 구성할까?"

를 고민했다면,

이번 주부터는

"이 환경에서 AI가 실제로 어떤 역할을 하고, 다른 기능들과 어떻게 연결될까?"

를 고민하기 시작한 느낌이다.

특히 이번 주를 지나면서 LLM → Agent → Tool → API → Frontend로 이어지는 구조가 조금씩 보이기 시작했다.

아직 각각의 개념이 완전히 익숙한 것은 아니지만, 단순히 AI에게 질문해서 답변을 받는 수준에서 벗어나 AI가 실제로 일을 수행하는 서비스를 어떻게 설계하는지를 조금씩 배우고 있다는 점에서 의미가 있었던 한 주였다.