LLM을 직접 API로 호출하는 것만 보면 생각보다 단순하다.
간단한 챗봇이라면 이 정도로도 충분하다.
그런데 실제 애플리케이션으로 만들기 시작하면 이야기가 달라진다.
대화 기록을 관리해야 하고, 외부 문서를 검색해야 하고, 여러 도구를 호출해야 하고, 모델의 응답을 특정 형식으로 받아야 할 수도 있다.
이런 흐름이 복잡해지면 각 단계를 직접 연결하고 관리하는 코드가 점점 많아진다.
AI Framework와 Orchestration은 이런 문제를 다루기 위한 개념이다.
AI Framework는 왜 필요한가
LLM API를 직접 호출하는 코드는 어렵지 않다.
개념적으로는 다음과 같다.
response = client.chat(
model="...",
messages=[
{"role": "user", "content": "게임 개발에 대해 설명해줘"}
]
)
문제는 애플리케이션이 복잡해지면서 주변 코드가 많아진다는 것이다.
예를 들어 RAG를 붙인다면,
Tool Calling까지 추가하면,
처럼 흐름이 길어진다.
AI Framework는 이런 작업에서 자주 사용되는 기능을 일정한 방식으로 구성할 수 있도록 도와준다.
다만 Framework가 LLM 자체를 대신하는 것은 아니다.
LLM은 여전히 외부 모델이고, Framework는 그 모델과 데이터, 도구, 애플리케이션 로직을 연결하는 역할을 한다.
Framework와 Library는 어떻게 다른가
둘을 엄격하게 구분하기는 어렵다.
일반적으로 Library는 개발자가 필요한 기능을 호출해서 사용하는 형태에 가깝다.
내 코드-> Library 호출-> 결과 사용
Framework는 애플리케이션의 전체적인 구조나 실행 흐름을 어느 정도 제공한다.
Framework-> 정해진 구조-> 내가 작성한 로직
AI 분야에서도 마찬가지다.
다만 요즘 AI Framework라는 이름으로 제공되는 도구들은 단순한 하나의 기능부터 Agent 실행 구조까지 범위가 상당히 넓다.
그래서 이름보다 어떤 문제를 해결해주는 도구인지를 보는 편이 낫다.
Orchestration은 무엇인가
Orchestration은 여러 작업과 시스템의 실행 순서를 조정하는 것을 의미한다.
AI 애플리케이션에서는 특히 LLM, 검색 시스템, 데이터베이스, 외부 API, Tool 등을 연결하는 작업을 말할 때 자주 사용된다.
예를 들어 사용자가
내일 서울 날씨를 확인하고 일정에 맞춰 알려줘.
라고 했다고 하자.
이 요청 하나를 처리하기 위해 여러 작업이 필요할 수 있다.
이 각각의 작업을 어떤 순서로 실행하고, 이전 단계의 결과를 다음 단계에 어떻게 전달할지를 관리하는 것이 Orchestration이다.
그래서 AI 시스템을 단순하게 보면 다음과 같이 생각할 수 있다.
LLM-> 생각하고 생성하는 모델
Tools-> 외부 기능
Data-> 참고할 정보
Orchestration-> 이들을 연결하고 실행하는 구조
Chain은 작업을 순서대로 연결하는 방식이다
가장 단순한 Orchestration은 순차적인 작업이다.
예를 들어 사용자의 질문을 먼저 요약하고, 요약된 내용을 다시 다른 Prompt에 넣을 수도 있다.
각 단계의 출력이 다음 단계의 입력이 된다.
이런 구조를 흔히 Chain이라고 부른다.
코드로 표현하면 대략 이런 형태다.
question = "긴 질문..."
summary = summarize(question)
answer = generate_answer(summary)
복잡한 작업도 결국 작은 단계로 나누면 이런 형태로 표현할 수 있다.
AI Framework가 관리하는 것들
AI Framework에서 자주 다루는 기능은 크게 몇 가지로 나눌 수 있다.
Prompt 관리
LLM에 전달할 Prompt를 코드와 분리해서 관리할 수 있다.
사용자 입력-> Prompt Template-> LLM-> 응답
사용자 입력이나 검색 결과 같은 동적인 데이터를 Prompt에 삽입하는 것도 쉽게 구성할 수 있다.
Model 연결
서로 다른 LLM을 비슷한 인터페이스로 사용할 수 있도록 추상화하기도 한다.
Application-> Framework-> Model A
또는
Application-> Framework-> Model B
모델을 교체해야 할 때 애플리케이션 코드의 변경 범위를 줄이는 데 도움이 된다.
Retrieval
Vector DB나 검색 시스템과 연결해서 RAG 구조를 만들 수 있다.
질문 -> Retriever -> 관련 문서 -> Prompt -> LLM
Tool Calling
LLM이 외부 기능을 사용하도록 연결할 수도 있다.
LLM -> Tool 선택 -> Tool 실행 -> 결과 -> LLM
Memory
대화형 애플리케이션에서는 이전 대화 내용을 관리해야 한다.
사용자 -> 질문 -> 이전 대화 + 현재 질문 -> LLM
다만 Memory라는 이름이 붙었다고 해서 모델 자체가 대화를 영구적으로 기억하는 것은 아니다.
대부분 애플리케이션이 이전 대화 내용을 저장하고 필요할 때 모델의 입력에 포함시키는 구조다.
Tool Calling이 들어가면 구조가 달라진다
LLM은 기본적으로 텍스트를 생성하는 모델이다.
현재 주가를 조회하거나 데이터베이스에서 유저 정보를 가져오는 것처럼 외부 시스템을 직접 실행할 수는 없다.
그래서 애플리케이션이 Tool을 제공한다.
예를 들어 날씨를 조회하는 Tool이 있다고 하자.
get_weather(city)
사용자가 날씨를 물어보면 LLM이 직접 날씨를 만들어내는 것이 아니라 Tool을 사용하도록 요청할 수 있다.
여기서 중요한 것은 Tool을 실제로 실행하는 주체가 별도로 존재한다는 점이다.
LLM은 어떤 Tool을 어떤 인자로 호출할지 결정하는 역할을 하고, 애플리케이션이 실제 함수를 실행한다.
Agent는 무엇인가
여기서 Agent라는 개념이 나온다.
일반적인 Chain은 개발자가 실행 순서를 미리 정해놓는다.
A-> B-> C-> D
Agent는 상황에 따라 다음에 어떤 작업을 할지 모델이 결정하도록 만들 수 있다.
예를 들어,
처럼 실행 과정이 동적으로 바뀔 수 있다.
Agent의 기본적인 아이디어는 LLM에게 여러 Tool과 작업 환경을 제공하고, 현재 상황에서 어떤 행동을 취할지 결정하게 만드는 것이다.
다만 Agent가 항상 좋은 선택은 아니다.
실행 흐름이 예측 가능하다면 굳이 Agent를 사용할 필요가 없다.
Chain과 Agent의 차이
둘을 단순하게 비교하면 이렇다.
Chain-> 개발자가 실행 흐름을 결정
Agent-> LLM이 다음 행동을 결정
예를 들어 사용자가 문서를 검색하고 답변을 받는 시스템이라면 정해진 RAG Pipeline으로 충분할 수 있다.
반면 질문에 따라 검색도 하고 계산도 하고 API도 호출해야 한다면 Agent 구조가 더 적합할 수 있다.
문제는 자유도가 높아질수록 제어하기 어려워진다는 것이다.
실행 횟수가 예상보다 많아질 수도 있고, 잘못된 Tool을 선택할 수도 있으며, 비용과 응답 시간이 증가할 수도 있다.
그래서 무조건 Agent를 사용하는 것보다 필요한 만큼만 자율성을 주는 것이 실용적이다.
Graph 구조를 사용하는 경우도 있다
작업이 복잡해지면 단순한 Chain으로 표현하기 어려워진다.
예를 들어,
입력 -> 분석 -> 검색 -> 결과 평가
까지 진행한 뒤 검색 결과가 충분하면 답변하고, 부족하면 다시 검색하도록 만들 수 있다.
이런 분기와 반복이 많아지면 작업을 Graph 형태로 표현할 수 있다.
각 작업을 Node로 만들고 Node 사이의 이동 조건을 Edge로 표현하는 방식이다.
Node A-> Node B-> Node C
필요하면
Node C-> Node B
처럼 다시 이전 단계로 돌아갈 수도 있다.
이런 구조는 Agent Workflow처럼 상태와 분기가 많은 시스템을 관리할 때 유용하다.
Framework가 모든 것을 해결해주는 것은 아니다
AI Framework를 사용하면 코드가 짧아지고 편해질 수 있다.
하지만 추상화가 많아질수록 내부 동작을 이해하기 어려워지는 문제도 있다.
예를 들어 Framework에서
result = chain.invoke(question)
한 줄로 실행되는 작업이 실제로는 내부에서
을 수행할 수도 있다.
Framework를 처음 사용할 때는 이런 추상화가 편하다.
하지만 문제가 발생하면 내부에서 실제로 어떤 일이 일어나는지 알아야 한다.
검색 결과가 이상한 것인지, Prompt가 잘못된 것인지, 모델이 잘못 답한 것인지 확인하려면 결국 각 단계를 분리해서 볼 수 있어야 한다.
그래서 AI Framework를 사용할 때도 추상화된 API만 외우는 것은 위험하다.
대표적인 AI Framework
AI 애플리케이션을 만들 때 많이 접하게 되는 도구들이 있다.
대표적으로 LangChain, LlamaIndex, 그리고 Workflow나 Agent 실행 구조에 초점을 맞춘 여러 프레임워크가 있다.
각 도구의 성격은 조금씩 다르다.
LangChain은 LLM, Prompt, Tool, Retrieval 등을 조합해서 애플리케이션을 구성하는 데 초점을 둔다.
LlamaIndex는 외부 데이터를 LLM 애플리케이션과 연결하는 부분, 특히 데이터 ingestion과 retrieval 쪽에서 많이 사용된다.
중요한 것은 특정 Framework의 API를 외우는 것보다 어떤 추상화를 제공하는지 이해하는 것이다.
예를 들어 다음 개념은 특정 라이브러리를 사용하지 않아도 알아두는 편이 좋다.
Prompt
Model
Embedding
Retriever
Tool
Parser
Chain
Agent
Workflow
State
Framework가 바뀌어도 이런 개념 자체는 계속 등장한다.
직접 구현하는 것과 Framework를 사용하는 것
작은 프로젝트라면 Framework를 사용하지 않고 직접 구현하는 것도 충분히 가능하다.
예를 들어 간단한 RAG라면,
정도는 직접 코드로 작성할 수 있다.
오히려 이 방법이 내부 동작을 이해하는 데 도움이 될 수도 있다.
반대로 Tool이 많고 여러 모델과 데이터 소스를 연결해야 하거나, 실행 상태와 분기까지 관리해야 한다면 Framework가 제공하는 추상화가 유용해진다.
결국 선택 기준은 “Framework를 써야 하는가?”가 아니다.
직접 구현했을 때 발생하는 반복 작업과 복잡성을 Framework가 줄여주는가?
이것을 보면 된다.
AI Application의 구조를 보면 역할이 분리된다
지금까지 나온 내용을 하나로 묶어보면 대략 이런 구조가 된다.
실제로는 구현 방식에 따라 구조가 달라진다.
그래도 각각의 역할을 구분해서 생각하면 좋다.
LLM-> 언어를 이해하고 생성하는 모델
Embedding-> 데이터를 벡터 표현으로 변환
Vector DB-> 벡터 기반 검색
Tool-> 외부 기능 실행
Framework-> 이런 구성 요소를 연결하기 위한 추상화
Orchestration-> 전체 실행 흐름과 상태를 관리
이렇게 보면 AI 애플리케이션이 단순히 “LLM API 하나 호출하는 프로그램”이 아니라는 것도 알 수 있다.
Framework보다 먼저 이해해야 하는 것
AI Framework는 계속 바뀐다.
새로운 모델이 나오고 새로운 SDK가 나오고, 기존 Framework의 API도 계속 변경된다.
그래서 특정 라이브러리의 사용법을 외우는 것만으로는 오래 가져가기 어렵다.
반대로 다음과 같은 구조를 이해하고 있으면 새로운 도구를 접해도 적응하기 쉽다.
Framework는 이 구조를 구현하기 편하게 만들어주는 도구일 뿐이다.
어떤 Framework를 사용하느냐보다 내가 만들고 있는 AI 시스템에서 어떤 단계가 필요하고, 각 단계의 책임이 무엇인지 분리하는 것이 먼저다.
정리
AI Framework와 Orchestration을 공부하면서 처음에는 Framework의 기능이 너무 많아 보일 수 있다.
하지만 기본적인 구조는 생각보다 단순하다.
LLM-> 생성
Retriever-> 검색
Tool-> 외부 기능 실행
Framework-> 구성 요소 연결
Orchestration-> 실행 순서와 상태 관리
단순한 애플리케이션이라면 LLM API를 직접 호출하는 것만으로 충분할 수 있다.
하지만 RAG, Tool Calling, 여러 단계의 Workflow, Agent 같은 기능이 추가되면 각 요소를 연결하고 실행 상태를 관리하는 코드가 복잡해진다.
이때 Framework와 Orchestration이 의미를 갖는다.
AI Framework를 공부할 때는 특정 라이브러리의 문법부터 외우는 것보다,
각 단계가 왜 존재하는지를 먼저 이해하는 편이 좋다고 생각한다.
그러면 Framework가 바뀌어도 구조 자체는 그대로 가져갈 수 있다.
결국 Framework는 AI를 더 똑똑하게 만드는 기술이라기보다 여러 AI 기능을 하나의 애플리케이션으로 묶고 관리하기 위한 개발 도구에 가깝다.