LLMOps 살펴보기, 2일차

LLMOps 살펴보기는 "LLMOps: Managing Large Language Models in Production" 라는 서적을 읽고 관련 내용을 풀어쓴 시리즈이다.

---

LLM-Based Applications

API를 통해 모델을 직접 사용하는 것과 웹 애플리케이션(예: chatgpt.com)에서 사용하는 것 사이에는 응답 차이가 생긴다. 예를 들어, ChatGPT 웹에서 질문하면 API에서 같은 질문을 했을 때와는 다른 답을 받을 수 있다. ChatGPT 웹은 이전 대화 데이터를 활용하고, 사용자 프롬프트에 추가 지침을 덧붙인다. 예를 들어, 현재 ChatGPT 웹은 보통 답변 끝에 “더 알아보고 싶으신가요?” 같은 문장을 붙여 대화를 이어가도록 유도한다. 반면 API로 모델을 직접 호출하면 이런 문구는 포함되지 않는다. 

 

회사가 AI 애플리케이션을 만들기 위해 반드시 자체 모델을 개발·훈련할 필요는 없다. 기존 모델(Gemini, Claude, GPT-4o 등)을 라이선스 받아 애플리케이션에 통합할 수 있다. 실제로 2023년 이후, GitHub에 올라오는 수많은 저장소들이 OpenAI API 사용 코드를 가져다 쓰고 있으며, 이는 많은 개발자들이 OpenAI 클라우드 서비스를 활용해 자신들의 애플리케이션에 AI 기능을 추가하고 있음을 보여준다. 

 

과거에는 자동화와 머신러닝이 도와주던 많은 애플리케이션 작업들이 이제는 AI 모델을 통해 실행되고 있다. 직접 자동화를 구현하는 것과, 파운데이션 모델(Foundation Model)을 사용하는 것의 차이는 미묘하지만, LLMOps 관점에서는 매우 중요하다. 머신러닝과 파운데이션 모델이 등장하기 전에는, 어떤 작업을 자동화하려면 모든 가능한 입력과 그에 대응하는 출력을 직접 프로그래밍해야 했다. 지난 10여 년 동안, 이 많은 자동화 코드는 머신러닝 모델을 학습시키는 방식으로 대체될 수 있었다. 새로운 입력이 주어지면, ML 모델은 그 입력이 명시적으로 프로그래밍되거나 이전에 본 적이 없어도 적절한 출력을 생성할 수 있었다. 다음은 서드파티 파운데이션 모델을 활용한 대표적인 소비자 지향 애플리케이션 사례들이다.

• Be My Eyes 
  - OpenAI가 지원하는 앱으로, 시각장애인이나 저시력자가 세상을 더 잘 탐색할 수 있도록 도와준다. 휴대폰 카메라를 사물에 비추면 풍부한 음성 설명을 들을 수 있다. 
• Duolingo
  - 외국어 학습 앱 Duolingo는 LLM을 이용해 더 빠르고 다양한 학습 콘텐츠를 만든다.
• Microsoft Copilot
  - Office, Windows, Bing 등 다양한 MS 제품에 탑재된 AI 스택 

지금은 *프로그래밍 -> 머신러닝 모델 -> 파운데이션 모델로 진화하면서, 기존 자동화 코드보다 훨씬 강력하고 다양한 AI 기반 애플리케이션이 탄생했다고 볼 수 있다. 

 

Agentic Workflows

Agentic Workflow를 구현하기에는 단일 프롬프트만으로는 한계가 있고, 메모리, 계획, 도구 활용, 능동적 실행이 필요하다. 이때 LLM은 단순 언어 모델에서 에이전트 시스템으로 진화한다. 에이전트의 기본 구조는 관찰 -> 결정 -> 실행의 반복이라 할 수 있으며, 여기서 실행은 지시 읽기, 상태 확인, 리소스 가져오기, 도구 호출, 태스크 분할 등 다양하다. 즉, 모델은 더 이상 수동적 응답기가 아니라, 코드를 실행하며, 단계별 작업을 관리하고, 상황에 맞게 적응하는 주체가 된다.

 

주요 에이전트 유형으로는 다음과 같은 것들이 있다. 

Agent 1. 싱글 스텝 에이전트

단순히 입력 -> 출력 후 종료하는 에이전트로, 메모리가 없고 실패 대응이 불가해 복잡한 태스크에는 취약하다. 

 

ex) SQL 쿼리 생성, 트윗 변환, 직접 질문 응답.

 

Agent 2. Chain-of-though 에이전트 

한 번의 프롬프트 안에서 단계별 추론을 수행하는 에이전트로, 다단계 문제 해결 성능이 뛰어나다. 다만 컨텍스트 윈도우에 제약이 있고, 여전히 단일 호출 내에서만 작동한다.

 

Agent 3. Plan-and-Act 에이전트

먼저 계획을 세우고, 그 뒤 단계별 실행하는 에이전트로, 중간 상태 기록, 오류 지점 확인, 재시도·자기 교정이 가능하다.

 

예: 블로그 글쓰기 → 개요 작성 → 각 섹션 작성 → 일관성 체크 

 

Agent 4. Reflective / Self-improving 에이전트

실행 후 결과를 자기 평가/반성하는 에이전트로, 출력 점수를 매기는 것이 가능하고, 기준과 비교할 수 있다. 다른 모델에 검증 요청 또한 가능하며, 러닝이 아닌 런타임 레벨 자기 개선에 비용이 많이 들지만 강력하다. 

 

Agent 5. Recursive decomposition 에이전트

재귀적으로 태스크를 분해하는 에이전트로, 큰 목표 → 작은 서브태스크 → 해결 가능한 수준까지 쪼개어 과제를 수행한다. 제약 사항이 없으면 무한 루프에 빠질 위험이 있다. 

 

예: AutoGPT, BabyAGI

 

Agent 6. Multi-agent collaboration

여러 에이전트가 역할을 분담한다. 

 

예: 하나는 글쓰기, 하나는 편집, 하나는 데이터 수집, 하나는 분석. 병렬 처리 가능, 도메인별 전문성 발휘. 필요: 명확한 인터페이스, 메시지 공유·큐 기반 협업

 

멀티 에이전트 시스템의 경우, 단일 거대 에이전트 대신 작고 특화된 에이전트들의 협업 아키텍처가 효과적이다. 각 에이전트는 반독립적으로, 도구, 메모리, 목표를 보유하고 있으며 서로 메시지를 주고받고, 작업을 위임하여 협력할 수 있다. 다만 에이전트 수가 많아질수록 조율 부담이 급증하며, 각 에이전트들의 역할 정의, 통신 경계, 오류 처리를 잘 설계하는 것이 중요하다고 할 수 있다. 

 

MCP, Model Context Protocol

요즘 AI 애플리케이션을 보면 예전과는 완전히 다른 분위기가 느껴진다. 과거에는 “챗봇”이나 “요약기”처럼 한정된 역할을 하는 도구들이 주를 이뤘지만, 이제는 캘린더를 불러오고, 데이터베이스에서 쿼리를 날리고, GitHub 저장소까지 들여다볼 수 있는 AI들이 등장했다. 이러한 변화는 MCP(Model Context Protocol)라는 새로운 표준 덕분에 가능해졌다. 

 

초창기 언어 모델을 기반으로 한 앱들은 대부분 모놀리식(Monolithic) 구조로, 모델이 DB와 연결되려면 전용 커넥터 코드를 작성해야 했고, 모델이 스프레드시트랑 연결되려면 또다른 커넥터를 작성해야 했다. Slack, 캘린더, 코드 저장소 등 새로 연결할 때마다 새 코드를 작성하는 방식이었으며, 모델과 툴이 많아질수록 통합은 거미줄처럼 얽히고, 관리 불가능해졌다. 

 

2024년 말, Anthropic이 제안한 MCP는 이런 혼란 속에서 등장했다. 아이디어는 다음과 같이 단순하다. “모델이 모든 툴을 이해할 필요도, 툴이 모델의 언어를 배울 필요도 없다. 그냥 각자 역할만 나눠서 공통 언어로 대화하면 된다."  

 

MCP가 정의하는 외부 시스템의 구성 요소는 세 가지 (Tools, Resource, Prompts)가 있다. 툴은 행동, 리소스는 데이터, 프롬프트는 가이드라인이라 볼 수 있고, 이 세 가지가 합쳐져 모델이 안정적이고 똑똑하게 움직일 수 있게 된다. MCP는 클라이언트-서버 구조로 구현되며, 다음과 같이 동작한다. 

1. Handshake 

클라이언트와 서버가 버전·기능 정보를 교환하는 것으로, “나 이런 기능 있어!” 하고 서버가 알려준다.

 

2. Discovery (탐색)

클라이언트가 서버에 툴·리소스·프롬프트 목록을 요청하면, 서버는 구조화된 메타데이터를 반환하고, 모델은 이를 맥락(Context)에 반영한다.

 

3. Interaction (상호작용)

모델이 필요할 때 툴을 호출하거나, 리소스를 조회하거나, 프롬프트를 적용한다. 요청은 JSON 같은 구조화된 형식으로 전달되고, 서버는 실행 결과를 반환한다. 호스트 애플리케이션은 이 결과를 다시 모델의 맥락에 주입해 다음 추론에 활용한다.

* 위 모든 동작들은 실시간·비동기적으로 진행됨

 

MCP의 핵심 가치는, 이제 모델이 모든 지식을 머릿속에 다 담아둘 필요가 없다는 것이라고 할 수 있다. 대신, 모델은 필요할 때 찾고, 묻고, 올바른 도구를 호출할 수 있는 능력을 갖게 된다. MCP 개념이 자리 잡으면서, LangChain, DSPy, Gorilla 같은 새로운 프레임워크와 툴들이 등장하기 시작했다. 이들은 MCP를 직접 표방하지 않더라도 아키텍처를 모듈화하고, 역할을 분리하며, 언어 모델을 거대한 블랙박스가 아닌 유연한 도구로 활용하는 것을 핵심 논리로 삼고 있다. 

 

MCP가 자리 잡으면, 언어 모델과의 상호작용은 단순한 프롬프트-응답 수준을 넘어서게 될 것이다. 조건부 실행, 함수 조합(Composable Functions), 툴 호출, 메모리 관리 등이 가능해지고, 언어 모델은 더 이상 질문-답변기가 아닌 백엔드 시스템의 일부로 작동하게 된다. 앞으로는 맥락(Context Window)이 계속 확장되고, vLLM(virtualized LLM) 같은 기술 덕분에 *세션 간 상태가 유지될 것이다. 이제 사용자는 단순히 “프롬프트를 입력”하는 게 아니라, 메모리·작업 스택·로그·툴 호출 능력을 갖춘 LLM-네이티브 환경과 상호작용하게 된다. 뿐만 아니라, 우리가 웹을 쓸 때 HTTP를 의식하지 않듯이 MCP는 뒤에서 조용히 돌아가며 다중 에이전트 시스템, 복잡한 워크플로우, 개방형 지능 인프라 의 뼈대를 담당하게 될 것이다.

 

* 기본 LLM은 stateless (대화 기록을 매번 프롬프트로 다시 줘야 함). vLLM은 긴 컨텍스트 관리 + 효율적인 캐시 재사용 덕분에, 이전 세션의 맥락을 효율적으로 이어서 가져갈 수 있고 개발자가 이를 활용해 세션 간 “연속성”을 구현할 수 있음.