DEVOCEAN

오늘의 트렌드

최근 AI 생태계는 단순히 거대 언어 모델(LLM)의 성능을 자랑하는 단계를 넘어섰습니다. 실무 현장에서는 "AI 시스템을 어떻게 안전하게 제어하고 통제할 것인가"라는 거버넌스 과제와 "텍스트로 담지 못하는 복잡한 문서 구조를 어떻게 정확히 검색할 것인가"라는 기술적 한계에 직접적으로 부딪히고 있습니다.

현대 기업 환경에서 AI 에이전트 도입이 보편화됨에 따라 API 키 발급, 비용 실시간 차단, 접근 권한 관리 및 검색 품질의 수치화가 최우선 과제로 떠올랐습니다. 다른 한편으로는 단순 텍스트 임베딩만으로는 파악하기 힘든 표, 그래프, 배너 등의 시각적 맥락을 해석하기 위해 비전-언어 모델(VLM, Vision-Language Model: 텍스트와 이미지를 동시에 이해하고 처리하는 AI 모델)을 검색 엔진에 결합하려는 시도가 본격화되고 있습니다.

오늘 포스트에서는 엔터프라이즈 환경에서 필수적으로 구축해야 하는 LLM 게이트웨이 운영 실무, VLM을 활용한 시각적 문서 검색 기술, 검색 품질을 객관적으로 측정하는 모니터링 체계, 그리고 CLI 에이전트와 브라우저 환경을 결합하는 개발 생산성 도구의 흐름을 심층적으로 다룹니다.

Amazon Bedrock 및 LiteLLM 기반의 사내 LLM 게이트웨이 구축

기업 내에서 AI 코딩 도구나 에이전트 도입을 검토할 때 가장 먼저 부딪히는 걸림돌은 보안과 비용 관리입니다. 전사 차원의 하향식 기획만 기다리다 보면 현업 팀의 개발 속도가 지연되기 쉽습니다. 이러한 문제를 해결하기 위해 최근에는 실제 AI 사용량이 높은 엔지니어링 조직이 주도하여 API 키 관리, 비용 모니터링, 접근 제어를 통합 처리하는 게이트웨이 아키텍처를 선제적으로 구축하는 사례가 주목받고 있습니다.

대표적으로 F&F의 AI Engineering 팀은 Amazon Bedrock 인프라 상단에 LiteLLM 게이트웨이(다양한 LLM API를 단일 인터페이스로 관리하는 프록시 서버)를 레이어로 배치하는 구성을 선보였습니다. F&F의 LiteLLM 게이트웨이 운영 사례에 따르면, 이들은 단순히 API를 중계하는 것을 넘어 키 발급부터 모델 승인, 사용자 및 팀별 할당량(Quota) 확인, 상한선 초과 시 자동 차단, 사용량 감사까지를 단일 운영 수명주기로 통합했습니다.

이러한 게이트웨이 중심 구조는 보안 사고 예방 측면에서도 핵심적인 역할을 합니다. 개별 개발자나 부서가 각자의 API 키를 임의로 발급받아 사용할 경우, 키 유출 위험이나 예산 오버런(Overrun)을 감지하기 어렵습니다. 게이트웨이를 중앙에 배치하면 사용자의 모든 요청이 단일 엔드포인트를 통과하게 되므로, 실시간 토큰 사용량 계산 및 비용 제약 조건에 따른 원천 차단 정책을 유연하게 적용할 수 있습니다.

또한 게이트웨이 아키텍처는 백엔드 모델의 유연성을 제공합니다. 내부 프록시 서버가 Anthropic Claude, OpenAI, Amazon Titan 등 여러 모델의 규격을 통일된 API 형식으로 변환해 주므로, 애플리케이션 코드를 전혀 수정하지 않고도 클라우드 제공자나 모델 버전을 자유롭게 교체할 수 있습니다.

# LiteLLM 게이트웨이 구성 예시 (config.yaml)
model_list:
  - model_name: claude-3-5-sonnet
    litellm_params:
      model: bedrock/anthropic.claude-3-5-sonnet-20240620-v1:0
      aws_region_name: us-east-1

router_settings:
  routing_strategy: usage-based-routing-v2
  redis_host: redis.internal.net
  redis_port: 6379

general_settings:
  master_key: sk-master-gate-key
  database_url: postgresql://admin:password@db.internal.net:5432/litellm
  max_user_budget: 100.0 # 사용자당 기본 예산 제한 ($)

위 설정 예시처럼 Centralized Router와 Redis/PostgreSQL을 결합하여 가동하면, 실시간으로 각 사용자의 쿼리 요청을 검증하고 지정된 예산을 초과하는 즉시 API 호출을 원천 차단하는 정교한 거버넌스를 구현할 수 있습니다.

VLM을 활용한 시각적 문서 검색: ColPali와 ColQwen의 도입

전통적인 RAG(Retrieval-Augmented Generation: 외부 문서를 검색해 LLM 답변의 정확도를 높이는 기술) 시스템은 문서의 PDF나 HTML 내 텍스트를 추출(Text Extraction)하여 벡터 DB에 저장하는 방식을 사용해 왔습니다. 그러나 표, 카탈로그, 배너, 복잡한 레이아웃이 포함된 문서의 경우, 텍스트만 떼어내어 임베딩하면 본래 포함되어 있던 시각적 맥락과 위치 정보가 모두 손실되는 결정적인 문제가 발생합니다.

이러한 한계를 극복하기 위해 제안된 것이 VLM 기반의 시각적 문서 검색 체계입니다. ColPali와 ColQwen 기반 시각적 문서 검색 연구에 따르면, 문서를 텍스트로 전환하지 않고 페이지 이미지 자체를 VLM 인코더에 통과시켜 비주얼 임베딩을 생성하는 레이트 인터랙션 다중 벡터(Late Interaction Multi-Vector) 방식이 폭넓게 쓰이고 있습니다.

ColPali와 ColQwen 모델은 입력된 사용자 질의(Text Query)와 문서 이미지 페이지의 세부 패치(Visual Patch)들을 매핑하여 단어와 이미지 구역 간의 세밀한 상호작용 점수를 계산합니다. 이 방식은 문단 배치가 복잡하거나 인포그래픽 형태의 데이터, T월드 이벤트 배너처럼 텍스트 비중이 낮고 이미지가 핵심인 자료에서도 고도화된 검색 정확도를 보여줍니다.

하지만 실제 인프라 도입 과정에서는 성능과 자원 간의 트레이드오프가 존재합니다. 이미지 전체를 고해상도로 처리할 경우 VLM의 렌더링 비용과 토큰 소비량이 급증하며, 유사한 디자인의 페이지가 많을 때 검색 결과의 중복성이 심화될 수 있습니다. 이를 해결하기 위해 이미지 청킹(Visual Chunking) 및 관련 패치를 그룹화하는 추가적인 가공 전략이 고도화되는 추세입니다.

# ColPali / ColQwen 다중 벡터 레이트 인터랙션 유사도 계산 개념 코드
import torch
import torch.nn.functional as F

def compute_late_interaction_score(query_embeddings, image_patch_embeddings):
    """
    query_embeddings: [num_query_tokens, dim]
    image_patch_embeddings: [num_patches, dim]
    """
    # 1. 정규화 (Cosine Similarity 준비)
    q_norm = F.normalize(query_embeddings, p=2, dim=-1)
    img_norm = F.normalize(image_patch_embeddings, p=2, dim=-1)
    
    # 2. 질의 토큰과 이미지 패치 간의 전치 행렬 곱 (Similarity Matrix)
    # Result shape: [num_query_tokens, num_patches]
    sim_matrix = torch.matmul(q_norm, img_norm.T)
    
    # 3. MaxSim 연산: 각 질의 토큰별로 가장 유사도가 높은 이미지 패치 점수 추출
    max_sim_per_query_token, _ = torch.max(sim_matrix, dim=-1)
    
    # 4. 모든 질의 토큰의 최대 유사도 합산
    final_score = torch.sum(max_sim_per_query_token)
    return final_score.item()

# 예시 데이터 적용
query_emb = torch.randn(5, 128)      # 5개 토큰으로 이루어진 질의
image_patches = torch.randn(64, 128)  # 8x8 패치로 분할된 문서 이미지

score = compute_late_interaction_score(query_emb, image_patches)
print(f"Document Similarity Score: {score:.4f}")

이와 같이 텍스트 변환 과정 없이 원본 문서 이미지 고유의 레이아웃 구조를 보존한 채 벡터 유사도를 산출함으로써, 복잡한 대기업 서식이나 기술 도면, 시각 자료 위주의 문서를 검색할 때 비약적인 품질 향상을 달성할 수 있습니다.

AI Agent의 검색 품질 정량화: OpenSearch 정밀 평가

RAG 에이전트를 개발할 때 흔히 범하는 실수는 검색 엔진의 성능을 개발자의 직관이나 소수의 샘플 쿼리 테스트에만 의존해 판단하는 것입니다. OpenSearch 검색 품질 평가 가이드에 설명되어 있듯, 정량적 지표 없이 프롬프트나 파라미터를 수정하는 것은 기준점 없이 시스템을 조작하는 것과 같습니다.

AI 에이전트의 오답률을 낮추기 위해서는 에이전트 생성부(Generation) 이전 단계인 검색부(Retrieval)의 품질을 독립된 평가지표로 측정해야 합니다. 검색 결과에 불필요한 정보가 섞여 들어오거나(Low Precision), 필요한 문서가 검색 범위 내에 들어오지 못하는 경우(Low Recall) 아무리 뛰어난 성능의 LLM을 배치하더라도 정답을 생성할 수 없기 때문입니다.

검색 엔진 성능 평가는 주로 MRR(Mean Reciprocal Rank), NDCG(Normalized Discounted Cumulative Gain), Precision@K, Recall@K 지표를 통해 이루어집니다. OpenSearch 환경에서는 사전에 정의된 평가 데이터셋(Evaluation Dataset)을 구성하고, Automated Test Pipeline을 가동하여 검색 알고리즘 변경 시 지표 변동성을 시각적으로 모니터링할 수 있습니다.

• Precision@K — 주요 역할: 상위 K개 검색 결과 중 관련 문서의 비율 측정 / 활용 시점: 사용자에게 소수의 검색 결과만 노출할 때
• Recall@K — 주요 역할: 전체 정답 문서 중 상위 K개 내에 포함된 비율 측정 / 활용 시점: AI 에이전트에게 전달할 컨텍스트 후보를 확보할 때
• MRR (Mean Reciprocal Rank) — 주요 역할: 최초로 관련 문서가 등장하는 순위의 역수 평균 / 활용 시점: 첫 번째 검색 결과의 정밀도가 최우선인 검색창
• NDCG — 주요 역할: 검색 결과의 순위까지 고려한 관련도 누적 점수 / 활용 시점: 검색 결과의 상위 노출 순서가 매우 중요한 RAG 파이프라인

이러한 지표를 지속적으로 수집함으로써, 텍스트 하이브리드 검색(BM25 + Dense Vector)의 가중치 조절, 키워드 부스팅 정책, 그리고 엠베딩 모델 마이그레이션 효과를 숫자로 증명하고 시스템을 안정적으로 개선할 수 있습니다.

브라우저 기반 CLI 에이전트 오케스트레이션과 개발 도구의 확장

최근 에이전트 개발 생태계에서는 개발자가 로컬 터미널 환경을 벗어나 어디서나 터미널 에이전트를 통제할 수 있는 브라우저 연동 기술이 빠른 속도로 전개되고 있습니다. 터미널 기반 명령어 인터페이스는 강력하지만, 모바일 기기나 외부 브라우저 환경에서는 접근성이 크게 떨어진다는 한계가 있었습니다.

Oh My Portal(OMP) 프로젝트 사례는 터미널 환경에서 가동되는 Anthropic Claude Code, OpenAI Codex CLI, Gemini CLI, OpenCode 등 다양한 CLI 에이전트를 웹 브라우저에서 제어할 수 있도록 연결해 줍니다. OMP Portal Tunnel 스킬 모듈을 사용하면 터미널 세션을 암호화된 웹 터널로 외부에 안전하게 노출하고, 독자적인 URL을 생성하여 외부 브라우저에서 CLI 응답을 실시간으로 확인하고 제어할 수 있습니다.

이와 함께 대규모 코드베이스를 시각화하여 에이전트와 상호작용하도록 돕는 도구들도 등장하고 있습니다. VS Code 확장 모듈 시냅스(Synapse)는 거대한 모노레포(Monorepo) 프로젝트의 모듈 연관 관계를 캔버스(Canvas) 형태의 노드 그래프로 시각화해 줍니다. 단순 텍스트 검색을 넘어 코드 구조를 시각적으로 분석하면서 에이전트에게 변경 범위를 지정해 주는 방식입니다.

동시에 개별 개발자의 웹 보안 도구 활용법도 한층 고도화되고 있습니다. uBlock Origin 하드 모드 설정에 명시된 바와 같이, 서드파티 스크립트, 미디어, 프레임 및 불필요하게 삽입되는 AI 클라이언트 트래픽을 기본 차단(Default Deny)하도록 웹 환경을 구성하고, 동작에 필수적인 항목만 허용하는 동적 필터링을 도입하는 등 개인 개발 환경의 무결성을 지키기 위한 시도도 이어지고 있습니다.

실무에서 바로 써보기: LiteLLM과 Bedrock을 활용한 엔드포인트 연동

사내 AI 에이전트 구축 및 거버넌스 확보를 위해 LiteLLM 게이트웨이를 Docker 환경에서 손쉽게 가동하고 Amazon Bedrock 모델에 연동하는 구체적인 실무 설정 예시입니다.

아래 설정 및 Docker Compose 코드는 로컬 또는 사내 서버에 바로 적용할 수 있는 형태입니다.

# docker-compose.yml
version: '3.8'

services:
  litellm-gateway:
    image: ghcr.io/berriai/litellm:main-v1.40.0
    container_name: litellm-gateway
    ports:
      - "4000:4000"
    environment:
      - AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
      - AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
      - AWS_REGION_NAME=us-east-1
      - LITELLM_MASTER_KEY=sk-internal-master-key-2026
    volumes:
      - ./config.yaml:/app/config.yaml
    command:
      - "--config"
      - "/app/config.yaml"
      - "--port"
      - "4000"
    restart: always

# gateway_client_example.py
import os
from openai import OpenAI

# LiteLLM 게이트웨이 엔드포인트를 OpenAI 표준 SDK로 호출
client = OpenAI(
    api_key="sk-internal-master-key-2026", # 게이트웨이 마스터 또는 유저 키
    base_url="http://localhost:4000"       # 사내 게이트웨이 주소
)

response = client.chat.completions.create(
    model="claude-3-5-sonnet", # 게이트웨이에 등록된 Alias
    messages=[
        {"role": "system", "content": "당신은 사내 지식 기반 어시스턴트입니다."},
        {"role": "user", "content": "사내 LLM 게이트웨이 도입의 주요 장점을 요약해주세요."}
    ],
    temperature=0.2,
    max_tokens=500
)

print(f"Response:\n{response.choices[0].message.content}")
print(f"\nUsed Tokens: {response.usage.total_tokens}")

이와 같은 방식을 사용하면 백엔드 AI 모델 인프라가 Amazon Bedrock이든 Azure OpenAI이든 관계없이, 개별 클라이언트 애플리케이션에서는 표준화된 OpenAI API 규격을 그대로 유지하면서 중앙에서 인증, 인가, 할당량 모니터링을 전적으로 통제할 수 있습니다.

앞으로의 전망

앞으로의 엔터프라이즈 AI 기술 환경은 "모델 자체의 거대화"보다는 "엔터프라이즈 운영 거버넌스"와 "멀티모달 입력 처리의 정교화"라는 두 축을 중심으로 재편될 것입니다.

첫째, LLM 게이트웨이 및 사내 AI 프록시 레이어는 단순한 선택이 아닌 표준 인프라(Standard Infrastructure)로 자리잡을 것입니다. FinOps(비용 최적화) 및 보안 컴플라이언스 준수를 위해 모든 AI 요청이 중앙 통제 레이어를 거치게 되며, 실시간 토큰 가시성 확보와 자산 정책 결합이 필수화될 것입니다.

둘째, RAG 및 문서 검색 분야에서는 텍스트 임베딩 중심에서 VLM 기반 시각적 임베딩으로 전환되는 흐름이 가속화될 것입니다. ColPali나 ColQwen과 같은 시각적 검색 기술이 표준화됨에 따라, 그동안 파싱하기 힘들었던 무수한 비구조화 PDF 문서들이 정밀한 검색 대상으로 편입될 것으로 기대됩니다.

셋째, 개발 도구 측면에서는 CLI 환경의 막강한 제어 기능과 웹 브라우저의 시각적 인터페이스가 융합된 하이브리드 에이전트 환경이 활성화될 것입니다. 개발자는 단일 IDE에 국한되지 않고 브라우저, 터미널, 시각화 캔버스를 자유롭게 넘나들며 멀티 에이전트를 모니터링하고 가동하게 될 것입니다.

실무 적용 체크리스트

사내 AI 인프라 고도화 및 검색 시스템 개편을 준비 중인 팀을 위한 실무 점검 항목입니다.

• [ ] LLM 게이트웨이 도입 여부: 사용자 및 팀별 API 키 발급 체계가 마련되어 있는가?
• [ ] 실시간 비용 및 할당량 차단: 예산 오버런 방지를 위한 실시간 토큰 카운팅 및 자동 차단 로직이 구현되어 있는가?
• [ ] 문서 파싱 한계 점검: 현재 RAG 시스템이 이미지, 표, 복잡한 인포그래픽 문서를 정상적으로 처리하고 있는가?
• [ ] VLM 검색 검토: 이미지 레이아웃 정보 손실이 큰 문서를 위해 ColPali/ColQwen 기반 시각적 임베딩 도입을 고려했는가?
• [ ] 검색 품질 정량 지표 측정: Precision@K, Recall@K, NDCG 등 정량적 지표를 기반으로 검색엔진을 자동 평가하고 있는가?
• [ ] CLI 및 에이전트 보안 통제: 외부 터널링 및 CLI 도구 연동 시 세션 암호화와 접근 권한 인가 절차가 올바르게 구성되었는가?