동적 데이터 시스템을 위한 자연어 질의 (Natural Language Query) 아키텍처 선택하기

복잡하고 진화하는 데이터 카탈로그를 위한 자연어 질의 (Natural Language Query, NLQ) 인터페이스를 구축할 때, 아키텍처의 선택은 솔루션의 성패를 결정지을 수 있습니다. 이 포스트에서는 동적 스키마 (Dynamic Schemas), 빈번한 변경, 그리고 복잡한 질의 요구사항을 가진 시스템에 NLQ를 구현할 때 직면하는 아키텍처 결정 사항들을 탐구합니다.

도전 과제: 동적 데이터 시스템
우리의 데이터 아키텍처는 몇 가지 독특한 과제를 제시했습니다:

• 원자성 (Atomicity): 리소스 유형별로 조직된 데이터와 많은 유형별 특정 필드들
• 동적 진화 (Dynamic Evolution): 급격한 스키마 변경 (1년 만에 50개에서 140개 테이블로 증가)
• 복잡한 질의 (Complex Queries): 태그, 날짜 비교 및 고급 연산자 지원 (단순 등호뿐만 아니라 >, < 등)
• 높은 특수성 (High Specificity): 도메인 특화 질의 구문 요구사항

핵심 질문: 재학습이나 수동 업데이트 없이 이러한 지속적인 변화에 적응하는 NLQ 시스템을 어떻게 구축할 것인가?

솔루션 1: 미세 조정된 정적 모델 (Fine-Tuned Static Models)
전통적인 접근 방식은 다음과 같습니다:

• 베이스 모델 (Base Model): 일반적인 질의 구문에 대해 학습된 파운데이션 모델 (Foundation Model)
• 미세 조정 레이어 (Fine-Tuning Layer): 과거 데이터를 기반으로 한 제품 특화 학습
• 배포 (Deployment): 정적 모델을 통한 예측 제공

장점:

• 검증된 결과가 있는 잘 알려진 접근 방식
• 기존 인프라 활용 가능
• 대규모 운영 시 잠재적으로 낮은 쿼리당 비용

한계점:

• 비동적 (Not Dynamic): 모든 스키마 변경 시 재학습이 필요함
• 팀 의존성 (Team Dependency): ML 전문 지식과 인프라가 필요함
• 학습 비용 (Training Cost): 데이터와 컴퓨팅에 대한 상당한 초기 투자 필요
• 지연 시간 (Lag Time): 스키마 변경과 모델 업데이트 사이의 지연 발생

빈번한 스키마 진화가 발생하는 우리의 사용 사례의 경우, 이 접근 방식은 지속적인 유지보수 부담과 잠재적인 데이터 노후화 문제를 야기할 것입니다.

해결책 2: Model Context Protocol (MCP)
대안적인 접근 방식은 Model Context Protocol (MCP)을 사용하여 범용 LLM (Large Language Model)에 동적인 컨텍스트 (Context)를 제공하는 것입니다:

사용자 질의 (User Query) → MCP 도구 (Tools)를 사용하는 LLM → 질의 구문 (Query Syntax) → 실행 (Execution)

↓
[동적 스키마 (Dynamic Schema)]
[사용 가능한 필드 (Available Fields)]
[질의 예시 (Query Examples)]

MCP가 제공하는 것:

• 실시간 스키마 정보
• 사용 가능한 필드 및 타입 (Types)
• 유효한 질의 패턴
• 도메인 특화 제약 조건 (Domain-specific constraints)

장점:

• 완전한 동적 방식 (Fully Dynamic): 스키마 변경에 즉각적으로 적응함
• 팀 소유권 (Team Ownership): ML 팀에 대한 의존성이 없음
• 학습 감소 (Reduced Training): 모델 학습이나 재학습이 필요하지 않음
• 투명성 (Transparency): 도구 사용을 통해 설명 가능성 (Explainability)을 제공함

한계:

• 질의당 비용 (Per-Query Cost): 질의당 컴퓨팅 비용이 더 높음
• 지연 시간 (Latency): 여러 번의 LLM 호출이 필요할 수 있음
• 외부 의존성 (External Dependency): 외부 LLM 제공업체에 의존함

해결책 3: 하이브리드 접근 방식 (Hybrid Approach)
두 방식의 장점을 결합할 수는 없을까요?
아이디어: 동적 컨텍스트를 위해 MCP를 사용하는, 미세 조정된 (Fine-tuned) 작은 베이스 모델을 사용합니다.

현재의 현실:
대부분의 경량 모델 (예: Llama 8B 변형 모델들)은 MCP에 필요한 복잡한 도구 사용이나 추론 (Reasoning)을 지원하지 않습니다. 이들은 직접적인 번역 작업에 맞춰 학습되었습니다.
도구 사용 능력을 갖춘 더 큰 모델을 구축하는 것은:

• 훨씬 더 복잡함
• 자원 집약적임
• 대부분의 팀에게 단기적인 옵션이 아님

기타 고려 사항
직접적인 SQL 생성 (Direct SQL Generation)
중간 질의 구문을 건너뛰고 SQL을 직접 생성하면 안 될까요?

• 복잡성 (Complexity): 구문론적으로는 맞지만 의미론적으로 틀린 (Semantically wrong) 질의를 생성하기 쉬움
• 비즈니스 로직 (Business Logic): 기존 질의 레이어에 중요한 도메인 지식이 인코딩되어 있음
• 유지보수 (Maintenance): 여러 곳에 로직을 중복해서 작성해야 함
• 낮은 비용 (Low Cost): 실행 레이어가 이미 효율적이라면, 왜 이를 우회해야 하는가?

Agent SDK vs 커스텀 구현 (Custom Implementation)
최신 에이전트 프레임워크 (OpenAI Agents SDK, LangChain 등)는 더 높은 수준의 추상화 (Abstractions)를 제공합니다. 왜 커스텀으로 구축하나요?

언어 제약 사항 (Language Constraints): SDK가 귀하의 스택에서 사용 가능하지 않을 수 있습니다 (예: Go가 필요한 상황에서 Python SDK만 제공되는 경우).

성능 (Performance): SDK는 다음과 같은 비용을 추가합니다:

• API 호출을 위한 네트워크 오버헤드 (Network overhead)
• 직렬화/역직렬화 (Serialization/deserialization) 비용
• 잠재적인 서비스 간 지연 시간 (Service-to-service latency)

중복 (Duplication): 외부 서비스를 사용하는 것은 로직과 데이터 접근을 중복하는 것을 의미합니다.

제어 (Control): 커스텀 구현은 다음을 제공합니다:

• 세밀한 최적화 (Fine-grained optimization)
• 데이터에 대한 직접 접근
• 단일 서비스 경계 (Single service boundary)

고성능, 저지연 (Low-latency) 요구 사항의 경우, 귀하의 서비스에 직접 통합된 커스텀 구현이 더 선호될 수 있습니다.

의사결정 프레임워크 (Decision Framework)
NLQ 아키텍처를 선택할 때 다음을 고려하십시오:

스키마 안정성 (Schema Stability)

• 빈번한 변경 발생 → 동적 접근 방식 (MCP) 선호
• 안정적인 스키마 → 파인튜닝 (Fine-tuning)이 실행 가능함

팀 역량 (Team Capabilities)

• ML 전문 지식 보유 → 파인튜닝 가능
• 엔지니어링 중심 → MCP가 유지보수하기 더 쉬움

비용 프로필 (Cost Profile)

• 높은 질의량 (High query volume) → 파인튜닝된 모델이 더 경제적일 수 있음
• 낮은 질의량 → 질의당 MCP 비용이 수용 가능함

지연 시간 요구 사항 (Latency Requirements)

• 1초 미만 요구 사항 → 캐시된 모델 (Cached models)이 필요할 수 있음
• 수 초 단위 허용 → MCP가 잘 작동함

소유 모델 (Ownership Model)

• 중앙 집중식 ML 팀 → 공유 인프라를 통한 파인튜닝
• 제품 팀 소유 → 직접 제어가 가능한 MCP

우리의 결정: MCP
우리는 다음과 같은 이유로 MCP 접근 방식을 선택했습니다:

동적 우선 (Dynamic First): 우리의 스키마는 재학습 오버헤드가 상당할 정도로 빈번하게 변경됩니다.
독립성 (Independence): 종속성 없이 빠르게 움직이기를 원했습니다.
투명성 (Transparency): 도구 사용은 명확한 감사 추적 (Audit trails)을 제공합니다.
비용 수용 가능 (Cost Acceptable): 질의량이 인프라 학습을 정당화할 만큼 높지 않습니다.
경험 가치 (Experience Value): 나중에 접근 방식을 변경하더라도, 질의 데이터셋 및 테스트에 대한 작업은 그대로 전이될 것입니다.

결론
NLQ 시스템을 위한 보편적인 "최선"의 아키텍처는 존재하지 않습니다.

올바른 선택은 귀하의 구체적인 제약 조건에 따라 달라집니다:

• 스키마 안정성 (Schema stability)
• 팀 구조 및 전문성 (Team structure and expertise)
• 질의량 및 지연 시간 요구사항 (Query volume and latency requirements)
• 비용 고려사항 (Cost considerations)
• 소유권 및 유지보수 선호도 (Ownership and maintenance preferences)

스키마가 진화하는 동적 시스템 (Dynamic systems)의 경우, MCP 기반 접근 방식은 유연성, 유지보수성, 그리고 시장 출시 속도 (Time-to-market) 사이에서 매력적인 균형을 제공합니다. 안정적이고 대량의 질의가 발생하는 시나리오의 경우, 미세 조정된 모델 (Fine-tuned models)에 대한 초기 투자가 이득을 가져다줄 수 있습니다. 핵심은 모든 상황에 적용되는 만능 방식 (One-size-fits-all approach)을 따르는 것이 아니라, 귀하의 구체적인 요구사항에 아키텍처를 맞추는 것입니다.