LLM 시스템 설계 패턴 심화: 모듈화와 상태 관리 원칙

대규모 언어 모델(LLM)을 활용하는 방식이 단순한 API 호출을 넘어섰습니다. 기업의 실제 업무 환경에 적용할 때는 모델 자체의 성능 외에 시스템 아키텍처 설계가 핵심이 됩니다. 복잡한 사용자 요구사항을 처리하는 서비스는 단일 모델 호출만으로는 구현할 수 없습니다. 따라서 LLM을 중심으로 여러 기능을 유기적으로 연결하고 관리하는 시스템 설계가 필수적입니다.

실제 서비스에서 LLM을 활용하려면 시스템을 독립적인 모듈로 분리하는 설계 패턴을 이해해야 합니다. 각 모듈은 특정 기능을 전담하고, 이들이 상호작용하며 전체 작업을 수행합니다. 또한, 대화가 진행되는 동안 시스템이 앞뒤 맥락을 잃지 않도록 모듈 간의 상태를 일관성 있게 관리하는 원리가 필요합니다. 이 상태 관리 원칙을 이해하는 것이 안정적인 에이전트 시스템 구축의 기반이 됩니다.

이 글은 LLM 시스템을 안정적으로 구축하기 위한 심화 설계 패턴을 다룹니다. 에이전트의 기본 구조를 파악하고, 컴포저블 패턴을 활용한 모듈화 방법을 학습합니다. 또한, 외부 도구를 사용하는 설계 방식과 대화 상태를 관리하는 원리를 깊이 있게 다룹니다. 마지막으로, 외부 지식을 활용하는 RAG 원리까지 체계적으로 정리합니다.

에이전트 시스템의 기본 구조

에이전트 시스템은 복잡한 목표를 달성하기 위해 여러 단계를 거치는 시스템입니다. 단순한 단일 요청 처리와 달리, 에이전트는 목표를 세분화하고, 계획을 수립하며, 필요한 작업을 순차적으로 수행합니다. 이러한 과정은 에이전트가 독립적으로 작동하는 시스템부터 정해진 작업 흐름(workflow)을 따르는 구현까지 폭넓게 정의됩니다.

에이전트의 작동 원리는 핵심적인 반복 구조를 가집니다. 에이전트는 목표를 설정하면, 현재 상태를 파악하고, 다음에 취해야 할 행동을 결정합니다. 이 과정에서 필요한 외부 기능이나 정보를 호출하여 결과를 받아 다음 행동 계획에 반영합니다. 이러한 순환적인 과정이 성공적인 에이전트 구현의 기본 구조가 됩니다.

성공적인 에이전트 개발은 복잡한 전용 프레임워크에 의존하기보다, 단순하고 조합 가능한 패턴(composable patterns)을 활용하는 것이 일반적입니다. 개발자는 LLM의 추론 능력과 외부 도구(tool)의 실행 능력을 결합하여 시스템을 구축합니다. 이 도구 사용은 모델이 정의된 함수나 API를 호출하고, 그 결과를 다시 입력으로 받아 다음 추론에 사용하는 방식으로 작동합니다.

이러한 구조를 이해하는 것은 시스템 설계의 출발점입니다. 에이전트의 목표가 자율적인 탐색에 가깝다면, 계획 수립과 자기 수정 메커니즘을 강조해야 합니다. 반면, 특정 비즈니스 프로세스를 자동화하는 것이 목표라면, 명확하게 정의된 작업 흐름을 따르도록 설계하는 것이 효과적입니다.

에이전트의 성능을 높이려면, 모델에게 단순히 답변을 생성하도록 요청하는 것 이상의 지침을 제공해야 합니다. 예를 들어, "응답하기 전에 도구를 사용해 조사하라"와 같은 명시적인 지침은 모델의 도구 사용 빈도를 높여줍니다. 따라서 에이전트 시스템을 설계할 때는 LLM 시스템 설계 패턴과 같은 구조적 접근 방식을 염두에 두는 것이 중요합니다.

모듈화와 컴포저블 패턴

시스템을 독립적인 모듈(module)로 분리하면 각 기능의 책임 영역이 명확해집니다. 이 방식은 시스템 전체의 복잡도를 낮추고, 특정 기능의 변경이 다른 부분에 미치는 영향을 최소화합니다. 모듈화는 시스템의 안정성을 높이는 기본 원칙입니다.

컴포저블 패턴(composable pattern)은 이러한 모듈들을 조합하여 기능을 구현하는 설계 방식입니다. 이 패턴을 사용하면 단순하고 조합 가능한 방식으로 시스템을 구축할 수 있습니다. 각 모듈은 특정한 작업을 전담하고, 그 결과를 다음 모듈의 입력으로 전달하는 방식으로 순차적으로 작동합니다. 이처럼 단계별로 결과를 주고받는 구조가 에이전트의 실행 흐름을 만듭니다.

이러한 모듈 기반의 설계는 시스템의 확장성을 극대화합니다. 새로운 기능을 추가할 때 기존 코드를 대폭 수정할 필요가 없습니다. 대신, 새로운 기능을 담당하는 모듈만 추가하거나 기존 모듈을 교체하면 됩니다. 이는 개발 속도를 높이고 유지보수 비용을 줄이는 효과를 가져옵니다.

모듈 간의 경계를 명확히 하는 것은 시스템의 신뢰도를 높이는 핵심 요소입니다. 예를 들어, 사용자 입력 처리 모듈과 외부 도구 호출 모듈을 분리하면, 어느 단계에서 오류가 발생했는지 정확히 진단할 수 있습니다. 이러한 설계 원칙을 이해하는 것은 LLM 시스템 설계 패턴 학습에 도움이 됩니다.

도구 사용(Tool Use) 설계

도구 사용(Tool Use)은 대규모 언어 모델(LLM)이 자체적인 지식만으로 답변하는 것을 넘어, 외부 시스템이나 애플리케이션의 기능(API)을 호출하여 실제 작업을 수행하게 하는 기능입니다. 이를 통해 LLM은 계산, 데이터 조회, 외부 서비스 연동 등 현실 세계의 복잡한 작업을 처리할 수 있게 됩니다. 도구 사용을 설계할 때는 모델이 어떤 도구를 언제, 어떤 인자(argument)와 함께 호출해야 하는지 명확히 정의하는 것이 핵심입니다.

도구 사용은 단일 단계로 완료되지 않고, 전 과정을 거치는 왕복(round trip) 구조로 작동합니다. 사용자가 질문을 하면, LLM은 먼저 주어진 도구 목록과 설명을 검토하여 필요한 도구 호출을 결정합니다. 이 호출 정보가 시스템에 전달되면, 실제 코드가 실행되어 결과를 반환합니다. 이 반환된 결과(tool result)를 다시 LLM에게 입력으로 제공하며, LLM은 이 정보를 바탕으로 최종 사용자 응답을 생성합니다. 이 순환 구조가 바로 에이전트 시스템의 핵심 작동 원리입니다.

도구 호출을 설계할 때 반드시 정의해야 하는 요소들이 있습니다. 도구의 이름, 사용 목적을 설명하는 상세한 설명(description), 그리고 입력 인자들의 구조와 타입을 정의하는 스키마(schema)가 필수적입니다. 이 스키마는 모델이 어떤 데이터를 기대해야 하는지 판단하는 기준이 됩니다.

요소	설명	역할
도구 이름	함수 또는 API의 고유 식별자입니다.	모델이 호출할 기능을 지정합니다.
설명	도구의 기능과 사용 시점을 상세히 설명합니다.	모델이 사용 여부를 판단하는 근거가 됩니다.
스키마	필요한 입력 인자(파라미터)의 구조와 타입을 정의합니다.	모델이 호출에 필요한 정확한 데이터를 생성하도록 유도합니다.

도구 사용을 통해 발생하는 비용은 입력 토큰과 출력 토큰을 기준으로 책정됩니다. 이 비용에는 도구의 이름, 설명, 스키마가 포함된 요청 토큰과, 도구 실행 결과가 포함된 응답 토큰이 모두 포함됩니다. 따라서 도구의 설명과 스키마를 간결하게 작성하는 것이 비용 효율성 측면에서 유리합니다. 도구 사용의 정확한 설계 원리와 구현 방법은 AI 개발자를 위한 구조화 출력과 함수 호출 설계 가이드를 참고하시면 도움이 됩니다.

대화 상태 관리 원리

LLM과의 상호작용은 단순한 단일 프롬프트가 아니라, 메시지(Messages) 목록이라는 구조화된 형태로 이루어집니다. 이 메시지 목록은 시스템이 모델에게 전달하는 모든 입력의 기록입니다. 모델은 이 구조를 통해 대화의 흐름을 파악하고 다음 응답을 생성합니다.

대화의 연속성을 유지하는 것이 상태 관리의 핵심입니다. 모델이 이전 대화 내용을 알지 못하면, 사용자가 방금 한 이야기가 무엇인지 이해하지 못합니다. 따라서 대화의 흐름을 유지하려면, 현재의 질문과 함께 이전의 주고받은 메시지들을 입력으로 포함해야 합니다. 이 입력 메시지들을 모두 전달하는 것이 바로 '컨텍스트(Context)'를 제공하는 방식입니다. 컨텍스트를 충분히 제공해야 일관성 있는 답변을 얻을 수 있습니다.

메시지 구조는 텍스트 외에도 다양한 형태의 콘텐츠를 지원합니다. 단순히 사람이 작성한 텍스트만 포함되는 것이 아닙니다. 사용자가 업로드한 이미지나, 시스템이 실행한 코드의 결과물 등 여러 종류의 콘텐츠가 메시지 객체 안에 포함될 수 있습니다. 예를 들어, 코드가 실행된 결과는 별도의 코드 실행 결과 블록(Code Execution Result Block) 형태로 메시지에 기록됩니다.

이러한 메시지 구조를 이해하는 것은 LLM 시스템을 설계하는 기본 원칙입니다. 메시지 목록을 정확하게 관리하는 것이 곧 대화의 상태를 관리하는 것입니다. 개발자는 대화가 진행됨에 따라 메시지 목록을 누적하고, 필요에 따라 이 목록을 잘라내어(Truncation) 모델에 전달하는 방식을 적용합니다. 메시지 목록을 효율적으로 관리하는 것이 장기적인 대화 시스템을 구현하는 핵심 기술입니다.

지식 검색 증강 생성(RAG) 원리

지식 검색 증강 생성(Retrieval-Augmented Generation, RAG)은 대규모 언어 모델(LLM)의 답변 생성 능력을 외부 지식 저장소와 결합하는 방식입니다. LLM이 학습한 내부 지식(parametric memory)에만 의존하는 것이 아니라, 필요할 때 외부의 비구조화된 지식(non-parametric memory)을 검색하여 이를 참고 자료로 활용합니다. 이 구조는 모델이 답변을 생성할 때 근거 자료를 제시하도록 유도하여 사실적 정확도를 높입니다.

RAG의 기본 원리는 사용자의 질문(Query)이 들어오면, 먼저 외부 지식 베이스에서 관련 문서를 검색하는 검색(Retrieval) 단계를 거칩니다. 검색된 문서는 단순히 참고 목록으로만 존재하는 것이 아닙니다. 이 정보는 사용자의 질문과 함께 모델의 입력 컨텍스트(Context)에 추가되어 모델에게 전달됩니다. 즉, 모델은 질문과 함께 "이 자료를 바탕으로 답변을 생성해 주세요"라는 지시를 받는 것과 같습니다.

이러한 과정을 통해 LLM은 환각(Hallucination) 현상을 줄이고, 최신 정보나 기업 내부의 전문 지식 등 학습 데이터에 포함되지 않은 지식을 바탕으로 답변을 구성할 수 있습니다. 따라서 RAG는 모델의 지식 범위를 확장하고 답변의 신뢰성을 확보하는 핵심적인 시스템 설계 패턴입니다.

RAG 파이프라인을 설계할 때는 검색 과정의 품질이 전체 성능을 좌우합니다. 검색된 문서가 질문과 관련성이 높아야 모델이 정확한 답변을 생성할 수 있기 때문입니다. 따라서 단순히 검색 엔진을 사용하는 것을 넘어, 질문의 의도를 파악하고 최적의 청크(Chunk) 단위로 지식을 분할하며, 검색 결과를 정제하는 과정이 필요합니다.

RAG의 작동 원리를 이해하는 것은 단순한 프롬프트 엔지니어링을 넘어선 시스템 설계의 영역입니다. 모델의 출력만으로는 부족한 지식적 깊이를 외부 시스템을 통해 보강하는 것이 핵심입니다. 이 원리를 효과적으로 구현하려면 RAG 파이프라인 설계와 같은 전문적인 접근 방식이 필요하며, 검색된 정보가 답변의 근거로 명확히 제시되도록 구조화하는 것이 중요합니다.

흔한 오해

"복잡한 전문 라이브러리를 사용해야 에이전트를 만들 수 있다." 성공적인 에이전트 구현은 복잡한 프레임워크나 전문 라이브러리보다는 단순하고 조합 가능한 패턴을 사용하는 것이 일반적입니다. 실제 구현 사례들을 보면 복잡한 구조보다 간단한 패턴 조합이 효과적임을 알 수 있습니다.

"에이전트는 복잡하고 전문적인 프레임워크를 사용해야만 안정적으로 작동합니다." 에이전트가 안정적으로 작동하기 위해 반드시 복잡한 프레임워크가 필요하지 않습니다. 오히려 복잡한 구조보다 단순하고 조합 가능한 패턴을 활용하는 것이 성공적인 구현에 더 도움이 됩니다. 이는 실제 개발 사례를 통해 확인된 원칙입니다.

"도구 사용은 모델이 외부 API를 호출하는 것만으로 모든 과정이 끝납니다." 도구 사용은 모델의 요청과 외부 실행 결과가 오가는 왕복(round trip) 구조로 작동합니다. 모델이 도구를 호출한 후, 외부에서 실행된 결과를 다시 모델에 전달하여 최종 응답을 생성합니다. 이 과정 전체가 도구 사용의 핵심입니다.