문제점: LLM API를 호출하는 것은 쉽다. 하지만 책임감 있게 운영하는 것은 더 어렵다.

프롬프트(Prompt)를 LLM API로 직접 전송하는 애플리케이션을 구축하는 것은 놀라울 정도로 간단합니다.

사용자가 요청을 제출하면, 애플리케이션이 이를 모델로 전달하고 응답이 반환됩니다.

프로토타입이나 개인 프로젝트의 경우, 그러한 아키텍처(Architecture)로도 충분한 경우가 많습니다.

하지만 애플리케이션이 성장함에 따라 추가적인 고민들이 나타나기 시작합니다.

일반적인 과제들은 다음과 같습니다:

• 개인 식별 정보(PII, Personally Identifiable Information)의 우발적 노출 방지
• 프롬프트 인젝션(Prompt Injection) 시도가 모델에 도달하기 전에 탐지
• 시간에 따른 API 비용 이해
• 지연 시간(Latency) 및 요청량 측정
• 문제 해결 및 운영 가시성(Operational Visibility)을 위한 감사 추적(Audit Trails) 생성

이러한 책임들은 언어 모델(Language Model) 자체와는 크게 무관합니다.

애플리케이션 전반에 이러한 기능들을 내장하는 대신, 저는 다른 아키텍처적 접근 방식을 탐구해보고 싶었습니다:

만약 모든 LLM 요청이 모델과 통신하기 전에 보안, 검증 및 관찰성(Observability)을 담당하는 전용 게이트웨이를 통과한다면 어떨까?

이 질문에 답하기 위해, 저는 클라이언트 애플리케이션과 OpenAI API 사이에 위치하는 **LLM 게이트웨이 프록시(LLM Gateway Proxy)**를 구축했습니다.

이 게이트웨이는 세 가지 주요 책임을 수행합니다:

• 보안 (Security)
• 컴플라이언스 (Compliance)
• 운영 모니터링 (Operational monitoring)

왜 게이트웨이를 도입하는가?

한 가지 설계 옵션은 검증 로직을 애플리케이션 내부에 직접 배치하는 것이었습니다.

대신, 저는 이러한 책임들을 전용 미들웨어(Middleware) 계층으로 격리하는 방식을 선택했습니다.

이는 여러 가지 장점을 제공합니다.

보안 로직이 한 곳에 존재합니다.

모니터링이 모든 요청에 대해 일관되게 이루어집니다.

향후 애플리케이션들은 코드를 중복 생성하지 않고도 동일한 게이트웨이를 재사용할 수 있습니다.

이는 인증(Authentication), 로깅(Logging), 속도 제한(Rate Limiting)과 같은 횡단 관심사(Cross-cutting concerns)가 여러 서비스에 흩어져 있는 대신 중앙 집중화되는 일반적인 아키텍처 패턴을 반영합니다.

상위 수준 아키텍처 (High-Level Architecture)

                 User Request
                      │
                      ▼
...

단순한 프록시(Proxy) 역할을 하기보다, 게이트웨이는 모든 상호작용을 검증하고 모니터링하는 책임을 지는 제어 지점(Control Point)이 됩니다.

Layer 1: PII Sanitization (개인정보 식별 정보 정화)

게이트웨이의 첫 번째 책임은 민감한 정보가 로컬 애플리케이션을 떠나기 전에 이를 식별하는 것입니다.

정규 표현식(Regular Expressions)을 사용하여 게이트웨이는 다음과 같은 일반적인 개인정보 식별 정보(PII, Personally Identifiable Information) 형태를 검색합니다:

• 이메일 주소 (Email addresses)
• 전화번호 (Telephone numbers)

탐지될 경우, 해당 값들은 다음과 같은 플레이스홀더 토큰(Placeholder tokens)으로 교체됩니다:

[EMAIL]

및

[PHONE_NUMBER]

그 후 원문 대신 정화된(Sanitized) 요청이 전달됩니다.

이 구현은 패턴 매칭(Pattern matching)을 사용하지만, 중요한 아키텍처 원칙을 보여줍니다:

민감한 정보는 요청 라이프사이클(Request lifecycle) 내에서 가능한 한 조기에 처리되어야 합니다.

향후 버전에서는 더 광범위한 PII 탐지를 위해 개체명 인식 (NER, Named Entity Recognition) 모델을 사용하여 이 레이어를 확장할 수 있습니다.

Layer 2: Prompt Injection Detection (프롬프트 인젝션 탐지)

다음 단계는 들어오는 프롬프트가 알려진 프롬프트 인젝션 (Prompt injection) 패턴을 가지고 있는지 평가합니다.

초기 구현은 가벼운 휴리스틱 (Heuristic) 접근 방식을 사용합니다.

def check_input_guardrail(text: str) -> bool:
    malicious_tokens = [
        "ignore previous instructions",
...

의심스러운 콘텐츠가 탐지되면, 게이트웨이는 요청을 언어 모델로 전달하는 대신 즉시 로컬 거부(Local refusal)를 반환합니다.

이 설계는 두 가지 이점을 제공합니다.

첫째, 불필요한 API 호출을 방지합니다.

둘째, 시스템 동작을 조작하려는 요청을 처리할 위험을 줄입니다.

이 접근 방식은 완전성(Completeness)보다 단순함(Simplicity)을 의도적으로 우선시한다는 점을 주목할 필요가 있습니다.

휴리스틱 탐지는 비용이 저렴하고 이해하기 쉽지만, 모든 적대적 프롬프트(Adversarial prompt)를 탐지할 수는 없습니다.

더 정교한 접근 방식으로는 임베딩 (Embeddings), 분류기 (Classifiers) 또는 전용 가드레일 모델을 결합하는 방법이 있습니다.

Layer 3: 관찰성 (Observability) 및 비용 추적 (Cost Tracking)

요청이 검증을 성공적으로 통과하면 OpenAI API로 전달됩니다.

게이트웨이는 실행 중에 다음과 같은 여러 운영 지표 (Operational metrics)를 측정합니다:

• 요청 지연 시간 (Request latency)
• 프롬프트 토큰 (Prompt tokens)
• 완료 토큰 (Completion tokens)
• 총 토큰 사용량 (Total token usage)
• 예상 API 비용 (Estimated API cost)

그 후 각 요청은 CSV 원장 (CSV ledger)에 기록됩니다.

CSV 파일은 가벼운 영속성 메커니즘 (Persistence mechanism)이지만, 개발 단계에서 사용 트렌드를 분석하기에 충분한 과거 데이터를 제공합니다.

여기서 얻을 수 있는 더 넓은 교훈은 관찰성 (Observability)을 사후 고려 사항으로 취급해서는 안 된다는 것입니다.

AI 시스템이 시간이 지남에 따라 어떻게 동작하는지 이해하는 것은 응답을 생성하는 것만큼이나 중요합니다.

대시보드 구축하기 (Building the Dashboard)

지표를 수집하는 것도 유용합니다.

하지만 이를 시각화하는 것은 훨씬 더 유용합니다.

기록된 데이터를 탐색하기 위해, 저는 두 가지 주요 목적을 수행하는 Streamlit 대시보드를 구축했습니다.

대화형 플레이그라운드 (Interactive Playground)

개발자는 다양한 프롬프트를 실험하고 게이트웨이가 어떻게 반응하는지 즉시 관찰할 수 있습니다.

이를 통해 다음 사항을 더 쉽게 검증할 수 있습니다:

• 개인정보 (PII)가 적절히 비식별화 (Redacted) 되었는지.
• 주입 (Injection) 시도가 거부되었는지.
• 안전한 요청이 정상적으로 계속되는지.

운영 지표 (Operational Metrics)

대시보드는 또한 다음과 같은 항목을 표시하여 실행 이력을 요약합니다:

• 총 요청 수 (Total requests)
• 예상 API 비용 (Estimated API cost)
• 평균 지연 시간 (Average latency)
• 과거 요청 로그 (Historical request logs)

이러한 지표를 즉각적으로 가시화할 수 있으면 시스템이 시간이 지남에 따라 어떻게 동작하는지 이해하기가 더 쉬워집니다.

엔지니어링 트레이드오프 (Engineering Trade-offs)

모든 아키텍처 결정에는 트레이드오프 (Trade-offs)가 따릅니다.

게이트웨이를 도입하면 모든 요청이 추가적인 검증 레이어를 통과해야 하므로 처리 시간이 약간 증가합니다.

하지만 이러한 오버헤드 (Overhead)는 일관성, 가시성 및 보안을 향상시킵니다.

마찬가지로, 휴리스틱 프롬프트 탐지 (Heuristic prompt detection)는 의도적으로 가볍게 설계되었습니다.

이는 낮은 지연 시간과 간단한 구현을 제공하지만, 더 미묘한 공격은 탐지할 수 없습니다.

마찬가지로, 실행 로그(execution logs)를 CSV 파일로 저장하는 방식은 개발과 검사를 단순화하지만, 실제 운영 환경(production deployment)에서는 데이터베이스나 중앙 집중형 로깅 플랫폼(centralized logging platform)을 사용할 가능성이 높습니다.

이러한 트레이드오프(trade-offs)를 인식하는 것은 프로젝트 전반에 걸친 설계 결정(design decisions)을 형성하는 데 도움이 되었습니다.

Docker 및 재현성 (Reproducibility)

환경 전반에 걸쳐 일관된 실행을 보장하기 위해, 애플리케이션은 Docker를 사용하여 컨테이너화(containerized)되었습니다.

컨테이너화는 다음과 같은 몇 가지 실질적인 이점을 제공합니다.

• 일관된 Python 환경
• 재현 가능한 의존성 관리 (dependency management)
• 단순화된 온보딩 (onboarding)
• 용이한 CI 통합
• 호스트 시스템 차이로부터의 격리

Docker는 보안 문제를 직접적으로 해결하기보다는, 게이트웨이가 실행되는 위치와 관계없이 일관되게 동작하도록 보장하는 데 도움을 줍니다.

지속적 통합 (Continuous Integration)

저장소에는 새로운 코드가 푸시(push)될 때마다 자동화된 품질 검사를 수행하는 GitHub Actions 워크플로(workflow)도 포함되어 있습니다.

현재 파이프라인(pipeline)은 다음 사항을 검증합니다:

• 의존성 설치 (Dependency installation)
• 정적 분석 (Static analysis)
• flake8을 이용한 린팅 (Linting)

단순한 과정이지만, 이는 중요한 엔지니어링 원칙을 강화합니다:

자동화는 배포 후가 아니라, 배포 전에 소프트웨어 품질을 검증해야 합니다.

직면했던 도전 과제들 (Challenges I Encountered)

게이트웨이를 구축하는 것은 단순히 API를 통합하는 것 이상의 작업이었습니다.

더 흥미로운 엔지니어링 도전 과제들은 다음과 같았습니다:

• 검증(validation)이 어디에서 이루어져야 하는지 결정하는 것
• 중복 로깅(duplicate logging) 방지
• 토큰 비용(token costs)을 정확하게 추정하는 것
• 가벼운 상태를 유지하는 가드레일(guardrails) 설계
• 미들웨어(middleware)의 책임과 프레젠테이션 로직(presentation logic)의 분리

이러한 결정들은 개별 API 호출보다 아키텍처(architecture)에 훨씬 더 큰 영향을 미쳤습니다.

배운 점들 (Lessons Learned)

이 프로젝트는 AI 엔지니어링에 관한 몇 가지 아이디어를 강화해 주었습니다.

보안은 계층화되어야 한다 (Security Should Be Layered)

언어 모델(language models)이 스스로 모든 보안 정책을 강제할 것이라고 기대해서는 안 됩니다.

애플리케이션 수준의 검증(application-level validation)은 추가적인 방어 계층을 제공합니다.

관찰성(Observability)은 필수적이다

지연 시간(latency), 비용, 그리고 요청 이력(request history)에 대한 가시성(visibility)이 없다면, AI 시스템을 최적화하는 것은 상당 부분 추측에 의존하는 일이 됩니다.

미들웨어(Middleware)는 재사용을 촉진한다

게이트웨이(gateway) 내부에서 검증(validation)과 모니터링(monitoring)을 격리함으로써, 여러 클라이언트 애플리케이션이 구현을 중복하지 않고도 동일한 보안 정책의 혜택을 누릴 수 있습니다.

향후 개선 사항

다음으로 탐구하고 싶은 몇 가지 방향이 있습니다.

• 임베딩(embeddings)을 사용한 시맨틱 가드레일(Semantic guardrails)
• 더 풍부한 PII(개인정보) 탐지를 위한 개체명 인식(Named Entity Recognition)
• Redis 기반의 응답 캐싱(response caching)
• 영구적인 실행 이력을 위한 PostgreSQL
• OpenTelemetry 트레이싱(tracing)
• Prometheus 및 Grafana 메트릭(metrics)
• 인증(Authentication) 및 API 키
• 속도 제한(Rate limiting)
• FastAPI 배포
• Kubernetes 오케스트레이션(orchestration)

이러한 기능들이 추가되면 게이트웨이는 LLM 상호작용을 관리하기 위한 더욱 포괄적인 플랫폼으로 확장될 것입니다.

마치며

이 프로젝트를 구축하면서 AI 애플리케이션을 넘어 확장되는 하나의 아이디어를 재확인했습니다.

신뢰할 수 있는 시스템은 유능한 모델과 절제된 소프트웨어 엔지니어링(software engineering)을 결합함으로써 구축됩니다.

보안(Security), 관찰성(observability), 검증(validation), 그리고 비용 인식(cost awareness)은 선택적인 추가 사항이 아닙니다. 이는 AI 시스템이 실제 환경에서 어떻게 동작하는지를 결정짓는 아키텍처적 관심사(architectural concerns)입니다.

언어 모델(language model)을 애플리케이션의 중심으로 취급하는 대신, 이 프로젝트는 언어 모델을 신뢰성, 투명성, 그리고 운영 제어(operational control)를 향상시키기 위해 설계된 더 큰 시스템 내의 하나의 구성 요소로 취급합니다.

소스 코드

전체 소스 코드, Docker 설정, GitHub Actions 워크플로(workflow), 그리고 문서는 GitHub에서 확인할 수 있습니다.

GitHub 저장소: https://github.com/ernest-emmanuel-utibe/llm-guardrail-dashboard.git

만약 여러분이 AI 인프라, LLM 게이트웨이, 또는 관찰성 도구를 구축하고 있다면, 여러분은 유사한 과제에 어떻게 접근했는지, 혹은 이 아키텍처에 어떤 개선을 가할 것인지에 대해 의견을 듣고 싶습니다.