저는 프로덕션급 AI 시스템이 어떻게 설계되고, 구축되며, 확장되고, 유지되는지 이해하는 여정을 시작하고 있습니다.

제 목표는 단순히 LLM API를 애플리케이션에 통합하는 것이 아닙니다. 저는 신뢰할 수 있는 AI 제품 뒤에 숨겨진 엔지니어링 결정들을 이해하고 싶습니다.

근본적인 질문부터 시작하겠습니다:

AI 시스템을 구축하려면 실제로 무엇이 필요한가?

1. LLM API 호출은 완전한 AI 시스템이 아니다

LLM API를 호출하면 응답을 생성할 수 있지만, 프로덕션 애플리케이션에는 훨씬 더 많은 것이 필요합니다:

• 인증(Authentication) 및 권한 부여(Authorization)
• 데이터 검색 및 컨텍스트 관리
• 속도 제한(Rate limiting) 및 비용 제어
• 시간 초과(Timeouts), 재시도(Retries), 오류 처리
• 평가(Evaluation) 및 출력 검증(Output validation)
• 모니터링, 보안, 확장성(Scalability)

LLM은 더 큰 소프트웨어 아키텍처의 한 구성 요소일 뿐입니다.

2. 우리의 첫 번째 설계 문제

10만 개의 내부 문서를 가진 회사용 AI 지식 비서 구축을 상상해 보세요.

직원들은 다음과 같은 질문을 할 수 있어야 합니다:

"당사의 기업 환불 정책은 무엇인가요?"

시스템은 관련 문서를 검색하고, 해당 문서에 근거하여 답변을 생성하며, 출처(citation)를 제공해야 합니다. 또한 직원들이 접근 권한이 없는 정보는 볼 수 없도록 보장해야 합니다.

3. 높은 수준의 아키텍처

우리의 초기 설계에는 다음과 같은 구성 요소가 포함됩니다:

클라이언트 → Go API 백엔드 → 검색 서비스(Retrieval Service) → AI 오케스트레이션(AI Orchestration) → LLM 제공업체(LLM Provider)

지원 인프라에는 다음이 포함됩니다:

• PostgreSQL: 사용자, 문서 메타데이터, 권한 및 애플리케이션 기록.
• 벡터 검색(Vector search): 의미적으로 관련된 문서 청크 검색.
• 객체 스토리지(Object storage): 원본 업로드 문서.
• 메시지 큐(Message queue): 비동기 문서 처리.
• 백그라운드 워커(Background workers): 텍스트 추출, 청킹(chunking) 및 임베딩 생성.
• Redis: 선택적 캐싱 및 속도 제한 작업 부하.

4. RAG는 어디에 속할까요?

검색 증강 생성(Retrieval-Augmented Generation, RAG)은 애플리케이션이 관련 외부 정보를 검색하여 이를 LLM에게 컨텍스트로 제공할 수 있게 합니다.

일반적인 워크플로우는 다음과 같습니다:

1. 사용자가 질문을 제출합니다.
2. 백엔드가 사용자를 인증합니다.
3. 검색 계층(retrieval layer)이 관련 있고 승인된 문서 청크를 검색합니다.
4. 오케스트레이션 계층(orchestration layer)이 질문과 검색된 컨텍스트를 포함하는 프롬프트를 구성합니다.
5. LLM이 답변을 생성합니다.
6. 백엔드가 응답을 검증하고 출처 참조와 함께 반환합니다.

RAG는 근거성(grounding)을 향상시킬 수 있지만, 정확성을 보장하지는 않습니다. 검색 성능이 떨어지거나, 문서가 오래되었거나, 오해의 소지가 있는 자료를 사용하면 여전히 부정확한 답변이 나올 수 있습니다.

5. 고려할 만한 프로덕션 과제들

작동하는 프로토타입은 시작에 불과합니다.

지연 시간(Latency): 검색과 생성을 대화형 사용에 충분히 빠르게 유지하려면 어떻게 해야 할까요?

비용(Cost): 토큰 소비를 제어하고 불필요한 모델 호출을 피하려면 어떻게 해야 할까요?

보안(Security): 컨텍스트가 모델에 도달하기 전에 문서 수준의 권한을 강제하려면 어떻게 해야 할까요?

신뢰성(Reliability): 모델 제공업체가 시간 초과되거나 사용할 수 없게 되면 어떻게 될까요?

품질(Quality): 몇 가지 수동 테스트에 의존하는 대신, 검색 관련성과 답변 정확도를 어떻게 측정할 수 있을까요?

이러한 질문들은 AI 통합을 시스템 설계로 만듭니다.

6. 다음에 탐구할 내용

제가 각 구성 요소를 조사하고, 실용적인 예제를 구현하며, 학습하는 대로 아키텍처적 트레이드오프를 문서화할 것입니다.

다음 주제는 RAG입니다: 문서 수집(ingestion), 청킹(chunking), 임베딩(embeddings), 검색이 어떻게 함께 작동하는지—그리고 단순히 LLM을 데이터베이스에 연결하는 것만으로는 충분하지 않은 이유에 대해 다룰 것입니다.

이것은 실용적인 백엔드 엔지니어링에 초점을 맞춘 핸즈온 AI 시스템 설계 시리즈의 시작입니다.

다른 개발자들에게 질문: AI 지식 비서(knowledge assistant)를 설계할 때, 검색 정확도, 응답 지연 시간, 비용 중 무엇을 우선순위에 두시겠습니까? 그 이유는 무엇인가요?

ai #systemdesign #backend #golang #programming