오늘은 본격적으로 LLM과 Agent의 차이, 여러 Agent를 연결하는 Routing과 Orchestration, 그리고 이미지와 음성을 이용하는 멀티모달 AI 서비스를 공부했다.
지난 시간까지는 Docker에서 PostgreSQL, Redis, Ollama 등의 로컬 환경을 준비했다면 오늘부터는 이 환경을 이용해 실제 AI Agent가 어떻게 움직이는지 살펴보기 시작했다.
특히 단순히
사용자 질문 → LLM → 답변
으로 끝나는 것이 아니라,
사용자 질문 → 의도 분류 → Agent 선택 → Tool·데이터 활용 → 결과 생성
처럼 여러 단계가 연결되는 구조를 배웠다.
오후에는 이미지 분석과 TTS를 연결하는 실습도 진행했다. 수업 내용을 응용해서 나는 축구선수의 유니폼 사진을 분석해 이름, 등번호, 유니폼 정보를 추출하고 그 결과를 음성파일로 만드는 프로그램도 만들어봤다.
1교시 | Docker 로컬 환경 복습과 Agent 시스템 전체 구조
첫 시간에는 지난 시간에 구축했던 Docker 환경을 다시 확인했다.
현재 Docker에서는 주로 다음 서비스를 사용한다.
PostgreSQL → 데이터 저장
Redis → 빠른 임시 데이터 처리
Ollama → 로컬 LLM 실행
여기서 다시 기억해야 할 부분은 Ollama 자체가 LLM은 아니라는 것이다.
Ollama → LLM을 실행하는 플랫폼
Llama → Ollama에서 실행하는 실제 LLM
이라고 구분하면 된다.
앞으로는 GPT와 Gemini 같은 Cloud LLM뿐 아니라 Ollama에서 실행하는 Llama 같은 Local LLM도 함께 사용한다.
앞으로의 AI 서비스 구조
이전에는 주로
Frontend → Backend → DB
정도의 구조를 만들었다.
하지만 이번 단계부터는 뒤쪽에 Agent Server가 추가된다.
Frontend
↓
Backend
↓
Agent Server
↓
LLM / PostgreSQL / Redis / Tool
Agent 기능을 Backend 하나에 모두 넣으면 서버가 너무 많은 일을 처리해야 하기 때문에 별도의 Agent Server로 분리하는 구조도 사용한다.
이번 단계에서는 코드를 얼마나 많이 작성했는지보다 여러 서버와 Agent를 어떻게 구성하고 연결했는지가 더 중요해질 것 같다.
2교시 | Chapter 5 전체 흐름과 RAG·Memory 이해
Chapter 5에서는 단순한 LLM 호출을 넘어 여러 AI 기능을 연결한다.
앞으로 공부할 내용은 다음과 같다.
Prompt Engineering
Structured Output
Tool
RAG
Memory
LangGraph
Human-in-the-loop
Multi Agent
Structured Output
예전에는 LLM에게 질문하면 긴 문장이 그대로 돌아왔다.
하지만 실제 프로그램에서는 필요한 데이터만 일정한 형식으로 받는 것이 편하다.
예를 들어 맛집 정보를 받는다면
가게 이름
주소
평점
메뉴
처럼 정해진 형태로 받을 수 있다.
이처럼 LLM의 답변 형식을 미리 정하는 것을 Structured Output이라고 한다.
RAG와 Memory 차이
두 개념도 다시 구분했다.
RAG → 필요한 지식을 검색
Memory → 과거 대화를 기억
RAG는 많은 문서 중 질문과 비슷한 자료를 찾아오는 역할을 한다.
예를 들어 회사 내부의 수많은 부품 자료가 있다면 사용자가 특정 부품을 질문했을 때 관련 문서를 찾아 LLM에게 전달할 수 있다.
반면 Memory는
예전에 내가 무슨 말을 했는가?
를 기억하기 위한 기능이다.
앞으로 RAG에서는 PostgreSQL의 pgvector를 사용하고, Memory에는 Redis나 PostgreSQL 같은 저장소를 활용하게 된다.
3교시 | Routing으로 사용자 질문 분류하기
AI Agent 서비스를 만들 때 가장 먼저 해야 할 일은 사용자가 무엇을 원하는지 알아내는 것이다.
예를 들어 질문이 다음처럼 들어올 수 있다.
"내일 비가 올까요?"
→ 날씨
"호텔 예약을 취소하고 싶어요."
→ 취소·정책
"제주도 여행 일정을 만들어줘."
→ 여행 계획
이처럼 질문을 먼저 분류해서 알맞은 Agent나 Workflow로 보내는 것을 Routing이라고 한다.
키워드 방식
가장 단순한 방법은 특정 단어를 찾는 것이다.
날씨 / 비 / 우산 → Weather
취소 / 환불 → Policy
장점은 빠르고 비용이 거의 들지 않는다는 것이다.
하지만
"내일 하늘에서 물이 떨어질까요?"
처럼 표현하면 "날씨"라는 단어가 없어도 실제로는 날씨 질문이다.
그래서 키워드만으로 모든 질문을 정확하게 분류하기는 어렵다.
LLM에게 분류시키기
다른 방법은 LLM에게 직접 질문하는 것이다.
이 질문이 날씨, 여행, 정책 중 무엇인지 분류해줘.
이렇게 하면 자연스러운 문장을 더 잘 이해할 수 있다.
하지만 LLM을 한 번 더 호출해야 해서 시간과 API 비용이 증가한다.
따라서 실제 서비스에서는 정확도뿐 아니라 속도와 비용도 함께 고려해야 한다.
4교시 | Agent·Routing·Orchestration 쉽게 이해하기
오늘 가장 중요했던 부분 중 하나였다.
Agent
Agent는 단순히 LLM 하나만 의미하지 않는다.
LLM
+ Tool
+ Memory
+ Retriever
+ Context
처럼 여러 기능을 이용해서 일을 처리하는 존재라고 생각하면 된다.
쉽게 표현하면 AI 직원 한 명이다.
Routing
Routing은 AI 직원에게 일을 보내기 전에
이건 누구에게 맡길 일이지?
를 판단하는 과정이다.
Orchestration
Orchestration은 여러 AI 직원에게 일을 나누는 팀장 역할과 비슷하다.
예를 들어
다음 주 경주에서 축구를 하고 싶은데 여행 계획을 만들어줘.
라는 요청이 들어왔다고 생각해보자.
필요한 작업은 여러 개다.
날씨 확인
축구장 검색
숙소 검색
교통 검색
Orchestrator가 이 작업들을 각각의 Agent에게 나누어주고 마지막에 결과를 합친다.
이제 과정 이름인 멀티 AI 에이전트 오케스트레이션이 무엇을 의미하는지 조금씩 이해되기 시작했다.
5교시 | GPT·Gemini·Llama 비교와 이미지·음성 처리
FastAPI Backend를 실행하고 실제로 여러 LLM을 호출해봤다.
현재 비교한 모델은
OpenAI GPT
Gemini
Ollama + Llama
였다.
같은 질문을 보내도 모델마다 결과와 속도가 달랐다.
특히 Ollama에서 실행한 로컬 Llama는 내 컴퓨터 자원을 사용하기 때문에 응답이 상당히 느렸다.
Local LLM의 장점은 외부 API를 사용하지 않는다는 것이지만, 실제 서비스에서는 컴퓨터 성능도 중요하다는 것을 알 수 있었다.
System Prompt
LLM에게 질문하기 전에 역할을 지정할 수도 있다.
예를 들어
너는 여행 전문가야.
라고 설정하면 여행 관련 답변을 중심으로 하게 된다.
또
너는 국제 마케팅 전문가야.
처럼 역할을 정할 수도 있다.
즉 System Prompt는 AI에게 어떤 역할로 행동할지 알려주는 설명서라고 이해했다.
이미지 분석과 Structured Output
이번에는 이미지를 LLM에게 직접 전달해 분석했다.
여행 사진을 넣으면 단순한 설명만 받는 것이 아니라
summary
visible_text
travel_tips
safety_notes
location_info
처럼 원하는 형식으로 결과를 받을 수 있었다.
이 부분에서 Structured Output의 장점을 확실하게 이해할 수 있었다.
일반적인 긴 문장을 받는 것보다 프로그램이 사용하기 좋은 데이터 구조로 결과를 받으면 이후 Backend나 Frontend에서 활용하기 훨씬 편하다.
TTS | 글자를 음성으로 바꾸기
TTS는 Text To Speech의 약자다.
텍스트 → 음성
으로 바꾸는 기능이다.
예를 들어
서울역에서 출발하기 전에 승차권 시간과 플랫폼을 확인하세요.
라는 문장을 OpenAI TTS 모델에 보내면 MP3 음성파일을 만들 수 있다.
목소리 종류뿐 아니라
한국어로 또렷하고 안내 방송처럼 말하세요.
처럼 말하는 방식도 지정할 수 있었다.
반대로
음성 → 텍스트
로 바꾸는 Speech To Text도 있기 때문에
사용자가 말함
↓
텍스트 변환
↓
LLM 처리
↓
다시 TTS
구조를 만들면 음성 AI 서비스도 만들 수 있다.
6교시 | 이미지 분석 + TTS 직접 연결하기
오후에는 앞에서 따로 공부했던 이미지 분석과 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예를 들어 결과가
{
"player_name_text": "KHUSANOV",
"jersey_number": "45",
"uniform_description": "하늘색 유니폼을 착용하고 있습니다.",
"team_guess": "맨체스터 시티",
"spoken_summary": "맨체스터 시티의 45번 선수 KHUSANOV로 보입니다."
}처럼 나오도록 구성했다.
여기서 중요한 것은 얼굴을 보고 선수를 알아맞히는 것이 아니라 유니폼에 실제로 적힌 글자와 등번호를 읽고, 유니폼 특징을 분석하도록 만든 것이다.
그다음 spoken_summary를 TTS의 입력값으로 전달한다.
input=analysis.spoken_summary그러면 최종적으로
맨체스터 시티의 45번 선수 KHUSANOV로 보입니다.
라는 내용을 음성으로 읽는 MP3가 만들어진다.
오늘 배운
이미지 분석 + Structured Output + TTS
세 가지를 한 프로그램 안에서 직접 연결해본 실습이었다.
7교시 | 도메인에 특화된 AI 서비스를 만들기
이미지 분석 기능은 여행 사진에만 사용할 필요가 없다.
예를 들어
음식 사진 → 음식과 칼로리 분석
문제 사진 → 문제 풀이
관광지 사진 → 여행 정보
축구선수 사진 → 유니폼 정보
처럼 사용할 수 있다.
하지만 하나의 AI가 모든 분야를 완벽하게 처리하도록 만드는 것은 어렵다.
그래서 실제 AI 서비스에서는 도메인을 좁히는 것이 중요하다.
예를 들어 축구 서비스라면 축구에 필요한 정보만 정확하게 분석하도록 만드는 것이 훨씬 현실적이다.
LLM 결과를 다음 작업에 사용하기
LLM의 결과를 화면에 출력하고 끝낼 필요도 없다.
예를 들어 사진에서
경주
라는 위치를 찾았다면
경주
↓
위도·경도 검색
↓
지도 표시
처럼 다음 기능으로 연결할 수 있다.
즉 LLM의 결과가 다음 Agent나 Tool의 입력값이 되는 것이다.
이런 연결이 결국 Workflow와 Agent 시스템을 만드는 기본이라고 이해했다.
카메라와 마이크도 AI의 입력이 될 수 있다
브라우저에서는 이미지 파일뿐 아니라 카메라와 마이크도 사용할 수 있다.
카메라
카메라 촬영
↓
사진 프레임
↓
Backend 전송
↓
이미지 분석
처럼 만들 수 있다.
실시간 영상도 영상 전체를 계속 보내는 것이 아니라 일정 시간마다 프레임을 잘라 분석하는 방법을 사용할 수 있다.
마이크
사용자 음성
↓
Backend 전송
↓
Speech To Text
↓
LLM
↓
TTS
방식으로 만들 수 있다.
이렇게 생각해보니 AI Agent 서비스를 IoT나 키오스크 같은 형태로도 확장할 수 있을 것 같다.
8교시 | Codex로 바로 코딩하지 말고 PLAN.md부터 만들기
마지막 시간에는 Codex를 이용한 바이브 코딩 방법을 배웠다.
가장 강조된 내용은
바로 코드를 만들어달라고 하지 말자.
였다.
먼저 해야 할 기능을 자세하게 설명하고
프로젝트 분석
↓
단계별 개발 계획
↓
PLAN.md 작성
↓
사람이 검토
↓
한 단계씩 구현
순서로 진행하는 것이 좋다.
수정할 파일도 정확하게 지정하기
팀 프로젝트에서
이 기능 만들어줘.
라고만 하면 Codex가 공통 파일이나 다른 팀원이 작업한 파일까지 수정할 수 있다.
그래서
어떤 파일을 수정할지
어떤 API를 만들지
Frontend와 Backend를 어떻게 연결할지
기존 코드는 무엇을 참고할지
를 미리 PLAN.md에 작성하는 것이 중요하다.
Git도 함께 사용하기
Codex가 코드를 수정하다가 프로젝트가 이상해질 수도 있다.
그래서 AI에게 큰 작업을 맡기기 전에는
Commit
↓
AI 작업 Branch 생성
↓
Codex 작업
방식으로 진행하는 것이 안전하다.
문제가 생기면 이전 Commit으로 돌아갈 수 있기 때문이다.
결국 바이브 코딩도 AI에게 모든 것을 맡기는 것이 아니라 사람이 계획하고 AI에게 정확하게 일을 나눠주는 과정이라는 생각이 들었다.
오늘의 회고
오늘부터 정말 AI Agent를 만드는 과정에 들어왔다는 느낌이 들었다.
이전까지는
질문 → LLM → 답변
정도의 구조를 많이 만들었다면 이제는
사용자 입력
↓
Routing
↓
Agent / Workflow
↓
Tool / RAG / Memory
↓
LLM
↓
결과 평가
↓
최종 응답
처럼 훨씬 많은 단계가 생겼다.
처음에는 Agent, Workflow, Routing, Orchestration이라는 단어들이 모두 비슷하게 느껴졌는데 오늘 수업을 들으면서 조금씩 구분되기 시작했다.
내가 이해한 방식으로 가장 간단하게 정리하면
LLM → 답을 만드는 AI
Agent → 도구와 데이터를 이용해 일을 하는 AI 직원
Routing → 어떤 AI 직원에게 보낼지 정하기
Workflow → 미리 정한 순서대로 작업하기
Orchestration → 여러 AI 직원의 일을 관리하기
정도다.
또 오늘 직접 만든 축구선수 이미지 분석 프로그램도 기억에 남는다.
단순히 사진을 분석하는 것으로 끝나는 것이 아니라
축구선수 이미지
→ Structured Output
→ 선수 정보 추출
→ 설명 문장 생성
→ TTS
→ MP3
까지 연결하면서 하나의 AI 기능의 결과가 다음 AI 기능의 입력이 되는 과정을 직접 경험했다.
앞으로 프로젝트에서도 무조건 기능을 많이 넣으려고 하기보다는 어떤 도메인의 어떤 문제를 해결할 것인지 먼저 정하고, 필요한 Agent만 연결하는 방식으로 생각해봐야겠다.
그리고 Codex를 사용할 때도 바로
만들어줘.
라고 하는 습관보다는
분석 → PLAN.md → 검토 → 구현 → 테스트
순서로 사용하는 습관을 들여야겠다.
AI가 코드를 빠르게 만들어주는 것은 편하지만, 결국 어떤 구조로 만들 것인지 판단하고 여러 Agent를 어떻게 연결할 것인지는 내가 이해하고 있어야 한다.
오늘은 그동안 배운 Backend, LLM, Docker 환경 위에 본격적으로 Agent와 Orchestration이라는 새로운 층을 올리기 시작한 날이었다.
#AI오케스트레이션 #AI에이전트 #멀티에이전트 #LLM #LangGraph #OpenAIAPI #Ollama #이미지분석 #TTS #엔코아AI캠퍼스
댓글