모든 프로덕션 시스템은 코드가 아닌 다이어그램에서 시작됩니다.

이 프로젝트를 시작했을 때, 저는 대부분의 시간을 LLM (Large Language Model)을 선택하고 설정하는 데 보낼 것이라고 생각했습니다.

하지만 대신, 저는 다른 무언가에 대해 고민하며 며칠을 보냈습니다.

⚠️ 처음 오셨나요? 이것은 시리즈의 파트 1입니다. 제가 왜 이 플랫폼을 구축했는지에 대한 배경 이야기, 제가 저지른 실수들, 그리고 저의 첫 번째 프로덕션 RAG (Retrieval-Augmented Generation) 시스템으로부터 얻은 교훈이 궁금하시다면, 먼저 파트 0을 읽어보세요:

Building an Enterprise GenAI Platform on OCI – Lessons from My First Production RAG System

그 다음 아키텍처에 대한 심층 분석을 위해 여기로 돌아오시면 됩니다.

아키텍처.

모델에 대한 생각을 멈추고 시스템에 대해 생각하기 시작한 순간, 모든 것이 바뀌었습니다. 프로덕션 GenAI 애플리케이션에는 LLM 그 이상의 것이 필요합니다. 신뢰할 수 있는 데이터 파이프라인 (Data Pipelines), 효율적인 검색 (Retrieval), 확장 가능한 인프라 (Scalable Infrastructure), 그리고 보안이 적용된 배포 (Secure Deployment)가 필요합니다. 그래서 코드를 작성하기 전에 스스로에게 물었습니다: 내가 정확히 무엇을 만들고 있는가? 챗봇인가, RAG 애플리케이션인가, 아니면 엔터프라이즈 GenAI 플랫폼인가?

챗봇 그 이상을 생각하기

대부분의 RAG 튜토리얼은 대략 동일한 흐름을 따릅니다.

문서 (Documents) -> 임베딩 (Embeddings) -> 벡터 데이터베이스 (Vector Database) -> LLM -> 답변 (Answer)

학습용으로는 그러한 **아키텍처 (Architecture)**가 충분히 잘 작동합니다. 하지만 _프로덕션 (Production)_은 단순히 문서를 검색하고 LLM을 호출하는 것에 그치지 않습니다. 데이터를 지속적으로 수집하고, 신뢰성 있게 확장하며, 시간이 지남에 따라 진화할 수 있는 시스템을 구축하는 것에 관한 것입니다. 그때 저는 제가 챗봇을 설계하고 있는 것이 아니라, 플랫폼을 설계하고 있다는 것을 깨달았습니다.

아키텍처

Figure 1 – High-level architecture of the Enterprise GenAI Platform on OCI.

아키텍처는 자연스럽게 두 개의 독립적인 파이프라인으로 분리되었습니다.

1. 오프라인 파이프라인 (Offline Pipeline)

이 파이프라인은 사용자가 쿼리를 보내기 전에 지식을 준비합니다.

이 파이프라인의 책임은 가공되지 않은 정보(raw information)를 LLM이 효율적으로 검색할 수 있는 형태로 변환하는 것입니다.

흐름은 다음과 같습니다:

외부 소스 (External Sources) -> OCI Compute -> Object Storage -> 정제 및 청킹 (Cleaning & Chunking) -> 임베딩 생성 (Embedding Generation) -> FAISS 인덱스 (FAISS Index) -> 아티팩트 (Artifacts)

이러한 작업들은 연산 집약적(compute intensive)이지만, 모든 요청마다 실행될 필요는 없습니다.

이들을 분리해 둠으로써 지식 베이스(knowledge base)를 추론 서비스(inference service)와 독립적으로 발전시킬 수 있습니다.

2. 온라인 파이프라인 (Online Pipeline)

데이터가 준비되면, 온라인 파이프라인이 역할을 이어받습니다.

사용자 (User) -> Oracle APEX -> FastAPI -> 쿼리 임베딩 (Query Embedding) -> FAISS 검색 (FAISS Retrieval) -> 프롬프트 구성 (Prompt Construction) -> LLM -> 스트리밍 응답 (Streaming Response)

오프라인 파이프라인과 달리, 여기서는 매 밀리초(millisecond)가 중요합니다.

목표는 단순히 답변을 생성하는 것이 아닙니다.

목표는 올바른 답변을 빠르게 생성하는 것입니다.

이 점이 모든 구성 요소의 설계 방식을 변화시킵니다.

왜 플랫폼을 분리하는가?

제가 스스로에게 계속 던졌던 질문은 다음과 같습니다:

왜 모든 것을 단일 애플리케이션 안에 넣지 않는가?

그 이유는 서로 다른 워크로드(workload)가 서로 다른 요구사항을 갖기 때문입니다.

수집(ingestion) 파이프라인은 배치(batch) 단위로 수천 개의 문서를 처리할 수 있습니다.

추론 서비스(inference service)는 수 초 내에 응답해야 합니다.

하나의 애플리케이션 내에서 두 문제를 모두 해결하려고 하면 확장(scaling)이 더 어려워지고 배포(deployment)의 위험이 커집니다.

플랫폼을 독립적인 서비스로 분리한다는 것은 각 계층이 다른 계층에 영향을 주지 않고 발전할 수 있음을 의미합니다.

책임 중심의 설계

프레임워크에 대한 생각을 멈추고 책임(responsibilities)에 대해 생각하기 시작하자, 아키텍처는 거의 스스로 설계되었습니다. 모든 구성 요소는 데이터 수집, 데이터 처리, 지식 검색, 응답 생성, 또는 애플리케이션 제공 중 하나의 작업만을 수행했습니다. 그렇게 플랫폼은 자연스럽게 6개의 계층으로 진화했습니다.

이 계층들 중 어느 것도 특정 기술에 종속되지 않았다는 점에 주목하십시오. 이는 의도된 설계입니다. 훌륭한 아키텍처 (Architecture)는 이를 구현하는 데 사용된 도구보다 더 오래 지속되어야 합니다. FastAPI는 다른 프레임워크로 대체될 수 있고, FAISS는 관리형 벡터 데이터베이스 (Managed Vector Database)로, TinyLlama는 다른 거대언어모델 (LLM)로 교체될 수 있습니다. 기술은 진화할 수 있지만, 각 계층의 책임은 동일하게 유지됩니다.

아키텍처 원칙 (Architecture Principles)

플랫폼을 설계하면서 저는 몇 가지 핵심 원칙으로 계속 되돌아갔습니다.

• 모듈형 (Modular) – 모든 계층은 단일 책임을 가져야 합니다.
• 클라우드 네이티브 (Cloud-native) – 적절한 곳에 관리형 서비스 (Managed Services)를 사용합니다.
• 확장 가능성 (Scalable) – 수집 (Ingestion)과 추론 (Inference)을 독립적으로 확장합니다.
• 관측 가능성 (Observable) – 상태 확인 (Health), 메트릭 (Metrics), 로깅 (Logging)을 내장합니다.
• 보안 (Secure) – 서비스 간 최소 권한 접근 (Least-privilege access)을 적용합니다.
• 비용 인식 (Cost aware) – 불필요한 인프라 없이 학습을 최적화합니다.

이러한 원칙들은 이후의 모든 결정에 영향을 미쳤습니다.

왜 OCI인가?

이 프로젝트의 목표 중 하나는 Oracle Cloud Infrastructure (OCI)를 사용하여 프로덕션 지향적인 GenAI 플랫폼을 어디까지 구축할 수 있는지 탐구하는 것이었습니다.

OCI는 프로젝트의 이 단계에서 제가 필요로 하는 모든 것을 제공했습니다:

• 데이터 수집을 위한 컴퓨트 (Compute)
• 데이터 레이크 (Data Lake)를 위한 오브젝트 스토리지 (Object Storage)
• 실험을 위한 데이터 사이언스 (Data Science)
• 배포를 위한 컨테이너 레지스트리 (Container Registry)
• 보안 액세스를 위한 IAM
• 엔터프라이즈 애플리케이션 계층을 위한 Oracle APEX

모든 서비스를 한꺼번에 도입하기보다는, 이 시리즈를 통해 프로젝트가 진화함에 따라 각 서비스가 자연스럽게 등장할 것입니다.

초기에 배운 교훈 하나

저는 가장 어려운 부분이 적절한 LLM을 선택하고 프롬프트 (Prompt)를 정교화하는 것이라고 생각하며 이 프로젝트를 시작했습니다. 하지만 실제로는 데이터가 시스템을 통해 어떻게 이동하는지 설계하는 데 훨씬 더 많은 시간을 소비하고 있는 저 자신을 발견했습니다. 그때 저는 훌륭한 GenAI 애플리케이션은 모델에 의해 정의되는 것이 아니라, 아키텍처에 의해 정의된다는 것을 깨달았습니다.

다음 단계는?

이제 청사진이 완성되었으니, 구축을 시작할 차례입니다.

파트 2에서는 플랫폼의 첫 번째 단계를 구현할 것입니다:

• OCI Compute를 이용한 데이터 수집
• Object Storage로의 직접적인 데이터 스트리밍 (Streaming)
• 데이터 레이크 (Data Lake) 설계
• 다운스트림 프로세싱 (Downstream processing)을 위한 수천 개의 문서 준비

훌륭한 검색 시스템 (Retrieval system)을 구축하기에 앞서, 먼저 훌륭한 데이터가 필요하기 때문입니다.