들어가며: 클라우드에만 의존하는 AI, 산업 현장에선 한계가 있다

시만텍의 2024년 보고서에 따르면, Fortune 500대 기업은 계획에 없던 다운타임으로 인해 연간 약 1조 4천억 달러의 손실을 보고 있다고 합니다. 문제는 이 다운타임의 상당 부분이 문제를 빠르게 감지하고 해결할 수 있는 기술 부족으로 인해 더 악화된다는 점입니다. 생성형 AI가 해결책으로 떠오르고 있지만, 정작 산업 현장에 적용하려면 큰 벽에 부딪힙니다. 바로 클라우드 연결이 불안정하거나 아예 불가능한 환경이라는 점입니다.

대부분의 AI 서비스는 클라우드 API 호출을 전제로 합니다. 하지만 원유 시추선, 원격 농업 시설, 혹은 공장 내부와 같은 곳에서 인터넷 연결을 보장하기란 쉽지 않죠. 이 글에서는 AWS 서비스를 활용해 오프라인 환경에서도 완벽하게 동작하는 생성형 AI 아키텍처를 설계하는 방법을 단계별로 살펴보겠습니다. 핵심은 AI 추론을 엣지 디바이스로 옮기고, 클라우드는 모델을 커스터마이징하고 지속적으로 개선하는 '공장(factory)' 역할에 집중하는 것입니다.

Industrial server rack with edge AI GPU cards for local inference Coding Session Visual

본론 1: 아키텍처 설계의 핵심 결정 - 모델 커스터마이징 전략

이 아키텍처에서 가장 중요한 첫걸음은 도메인에 특화된 작은 언어 모델(SLM) 을 만드는 것입니다. 엣지 디바이스의 제한된 GPU 메모리(보통 16GB 이상) 안에서 동작해야 하므로, 모델의 크기와 성능 사이의 균형이 필수적입니다. AWS 블로그 아키텍처에서는 다음과 같은 전략들을 제시합니다.

(1) 파인튜닝 (Fine-tuning, FT)

사전 훈련된 모델을 특수 작업에 맞게 가볍게 적응시키는 과정입니다. 예를 들어, 정비 티켓의 Q&A 쌍을 이용해 특정 장비에 대한 문제 해결 질문에 답하도록 모델을 학습시킬 수 있습니다. FT는 출력의 형식과 스타일을 가르치는 데 탁월하지만, 모델이 원래 알지 못하던 새로운 도메인 지식을 주입하는 데는 한계가 있습니다.

(2) 지속 사전 훈련 (Continued Pre-training, CPT)

도메인 특화 비정형 데이터(기술 매뉴얼, 수리 로그 등)로 모델을 추가 훈련시켜 새로운 지식을 파라미터에 내장하는 방식입니다. FT보다 훨씬 많은 컴퓨팅 리소스와 데이터가 필요하지만, 장비 관련 전문 용어와 진단 절차를 모델에 깊이 있게 학습시킬 수 있습니다.

(3) 하이브리드 접근법 (FT + RAG) - 이 글의 핵심

RAG(Retrieval-Augmented Generation) 는 추론 시점에 관련 문서를 검색하여 모델 응답의 정확도를 높이고 출처를 명시해 환각(hallucination)을 줄이는 기술입니다. 이 아키텍처에서는 임베딩 모델과 벡터 DB를 CPU/SSD에서 실행하여 GPU 메모리 사용량을 0으로 만들고, 전체 16GB를 LLM에 전적으로 할당합니다.

# 예시: ChromaDB를 사용한 엣지 RAG 파이프라인 설정
from chromadb import PersistentClient
from sentence_transformers import SentenceTransformer

# 1. 임베딩 모델 (CPU에서 동작)
embedding_model = SentenceTransformer('sentence-transformers/all-MiniLM-L6-v2')

# 2. 벡터 DB 클라이언트 (로컬 디스크에 저장)
client = PersistentClient(path="/edge/data/rag_db")
collection = client.get_or_create_collection(
    name="equipment_manuals",
    metadata={"hnsw:space": "cosine"}
)

# 3. 문서 추가 (512 토큰, 50 토큰 오버랩으로 청킹)
def add_document(text: str, doc_id: str):
    chunks = [text[i:i+512] for i in range(0, len(text), 462)]  # 512-50=462
    embeddings = embedding_model.encode(chunks).tolist()
    collection.add(
        embeddings=embeddings,
        documents=chunks,
        ids=[f"{doc_id}_{i}" for i in range(len(chunks))]
    )

# 4. 검색 쿼리
query = "라인 정지 시 안전 절차는?"
results = collection.query(
    query_embeddings=embedding_model.encode([query]).tolist(),
    n_results=3
)
print(results['documents'])

이 하이브리드 접근법은 모델을 컴팩트하게 유지하면서도 최신 정보를 제공할 수 있다는 장점 덕분에, 이 AWS 레퍼런스 아키텍처의 메인 전략으로 선택되었습니다.

IoT sensors and devices connected to edge gateway for industrial monitoring Software Concept Art

본론 2: 오프라인 AI 아키텍처의 실제 구현과 보안 고려사항

이 아키텍처는 크게 세 개의 레이어로 구성됩니다: 클라우드 측 준비(13단계), 배포 오케스트레이션(4단계), 엣지 측 추론(59단계). 각 레이어는 AWS의 특정 서비스와 통합됩니다.

(1) 클라우드: 데이터 준비 및 모델 커스터마이징

  • Amazon S3: 기술 매뉴얼, SOP 문서의 원본 저장소.
  • Amazon Bedrock (Nova Pro): 원본 문서를 파인튜닝용 질문-답변-맥락 쌍으로 자동 변환. 수동 큐레이션 대신 대형 FM을 사용해 비용을 절감하고 확장성을 확보.
  • Amazon SageMaker AI Pipelines: QLoRA 방식으로 gpt-oss-20b (MoE, 21B 총 파라미터) 모델을 파인튜닝하고, 버전 관리된 모델 아티팩트를 S3에 저장.

(2) 배포: AWS IoT Greengrass

훈련된 모델을 양자화(GGUF 형식)하여 엣지 디바이스로 전달하는 역할을 합니다. Greengrass는 모델 패키징, 버전 관리, 수명 주기 관리를 담당하며, 디바이스의 지속적인 연결성을 요구하지 않습니다.

(3) 엣지: 로컬 추론 및 오케스트레이션

  • 하드웨어: NVIDIA Jetson Xavier와 같은 GPU 디바이스 (최소 16GB VRAM).
  • 추론 런타임: Ollama가 양자화된 SLM을 서빙.
  • 오케스트레이션: Strands Agents가 쿼리 처리 워크플로우를 조정. RAG 지식 베이스 조회, 장비 원격 측정 데이터 수집 등 다양한 도구를 라우팅.
  • UI: 로컬에서 실행되는 Flask 기반 운영자 포털.

보안: 엣지에서의 보안은 '물리적 접근'부터 고려해야

클라우드와 달리 엣지에서는 보안 주체가 완전히 바뀝니다. 인프라 보안을 AWS에 위임할 수 없으므로, 다음과 같은 자체 보안 제어가 필수입니다.

  • 인증: SAML/OIDC 연동 또는 상호 TLS 인증서 기반 인증. 역할 기반 접근 제어(RBAC)로 운영자/관리자/정비사 권한 분리.
  • 암호화: 전체 디스크 암호화(LUKS/BitLocker)를 통한 모델 아티팩트 및 벡터 DB 보호.
  • 네트워크 분리: 운영자 포털(네트워크 존), 추론 런타임(제한 구역), 클라우드 동기화 채널(격리된 아웃바운드 전용 인터페이스)을 분리.

실전 성능: 파인튜닝 효과는?

AWS 블로그에서 공개한 테스트 결과를 보면, 파인튜닝된 gpt-oss-20b 모델은 기본 모델 대비 모든 LLM 평가자(Claude 4.5, Nova Pro)에서 평균 점수가 10~15% 이상 향상되었습니다. 특히 Claude 4.5 Haiku 평가 기준으로는 85%의 높은 점수를 기록했습니다. 이는 소량의 파인튜닝 데이터로도 도메인 특화 작업에서 상당한 성능 개선을 이끌어낼 수 있음을 증명합니다.

Data flow diagram from edge devices to cloud for AI model retraining Developer Related Image

결론: 오프라인 AI, 이렇게 시작해보세요

이 레퍼런스 아키텍처는 제조업을 넘어 간헐적 연결, 엄격한 지연 시간, 데이터 지역성 제약을 가진 모든 산업(해양 에너지, 원격 농업, 운송, 국방)에 적용 가능한 패턴입니다.

핵심 테이크어웨이:

  1. 모델은 '작게' 유지하고, 지식은 RAG로 보강하세요. (FT + RAG 하이브리드 전략)
  2. 클라우드는 '공장', 엣지는 '서비스' 입니다. SageMaker AI Pipelines와 같은 FMOps 파이프라인으로 모델을 지속적으로 개선하고, Greengrass로 배포하세요.
  3. 보안은 처음부터 설계에 포함하세요. 물리적 접근부터 네트워크 분리까지 엣지 환경에 맞는 보안 전략을 세워야 합니다.

이 기술의 한계 및 주의사항

  • 하드웨어 제약: SLM이라고 해도 16GB VRAM은 최소 조건입니다. 모델 선택과 GPU 메모리 사용 전략(모델 복제 vs 텐서 병렬화)을 신중히 결정해야 합니다.
  • RAG 데이터 관리: 오프라인 환경에서는 벡터 DB의 최신성을 유지하기 어렵습니다. 주기적인 동기화 전략과 데이터 버전 관리가 필수적입니다.
  • 완전한 자동화의 함정: 파인튜닝 데이터 생성에 사용되는 LLM의 출력 품질을 항상 검증해야 합니다. 특히 산업 안전과 관련된 도메인에서는 사람의 검토가 반드시 필요합니다.

다음 단계 학습 방향

  • AWS의 FMOps 파이프라인을 직접 구축해보고, gpt-oss-20b 모델을 자체 데이터로 파인튜닝해보세요.
  • AWS IoT Greengrass의 모델 배포 및 업데이트 메커니즘을 심층 학습하세요.
  • RAG 성능 최적화를 위해 다양한 임베딩 모델과 청킹 전략을 비교 실험해보세요.
  • 온프레미스 환경에서의 대규모 언어 모델 서빙을 위해 vLLM이나 TensorRT-LLM과 같은 프레임워크를 공부해보세요.

함께 보면 좋은 글

근거자료: AWS Architecture Blog - Architecting offline-first generative AI applications for edge deployments

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.