OpenAI API를 활용한 응용 프로그램 설계 및 구현

1. LLM 애플리케이션 아키텍처의 이해

단순 챗봇을 넘어 시스템으로서의 LLM을 이해하는 단계
AI 응용 서비스 개발의 기초이자 가장 중요한 ‘설계 철학’을 다루는 단계

전통적인 프로그래밍이 Input + Logic = Output 이었다면, LLM 애플리케이션은 이를 넘어선 3단계 진화를 거치는 중
- 단순 Prompting 🡲 RAG(Retrieval-Augmented Generation) 🡲 Agentic Workflow
단계별 설명
- 1단계: 단순 Prompting (Zero/Few-shot)
  - 사용자의 입력을 모델에 그대로 전달하고 결과를 받음
  - 한계: 최신 정보 부재, 환각(Hallucination) 현상
- 2단계: RAG (Retrieval-Augmented Generation)
  - 외부 지식 베이스(DB, 문서)에서 관련 정보를 검색하여 프롬프트에 포함시킴
  - 핵심: “모델을 재학습시키지 않고도 최신/내부 데이터를 활용하는 법”
- 3단계: Agentic Workflow
  - LLM이 스스로 도구(Tool)를 사용하고, 결과를 검토하며, 필요시 루프를 돌며 작업을 완수
  - 핵심: 단순 응답기가 아닌 ‘판단과 실행의 주체’로 활용

모든 서비스에 최상위 모델을 쓰는 것은 비효율적 🡲 목적에 맞는 ‘모델 믹스’가 필요함
- 스마트팩토리 데이터 분석처럼 정밀한 로직이 필요한 경우 o1 계열
- 일반적인 사용자 인터페이스에는 4o 계열을 섞어 쓰는 Router 아키텍처를 설계

모델 시리즈	주요 특징	권장 용도
GPT-4o (Omni)	속도, 지능, 비용의 최적 밸런스, 멀티모달 지원	범용 서비스, 복잡한 추론, 실시간 대화
GPT-4o-mini	극도의 가성비와 빠른 속도	단순 분류, 요약, 임베딩 전처리, 대량 데이터 처리
o1-preview / o1-mini	강화된 추론(Reasoning) 능력. '생각하는 시간'을 가짐	복잡한 코딩 문제, 수학적 증명, 논리적 아키텍처 설계

LLM의 자원은 유한하며, 이는 곧 비용 및 성능과 직결됨
Context Window:
- 모델이 한 번에 기억할 수 있는 정보량(예: 128k tokens)
- 너무 많은 정보를 넣으면 모델이 중간 내용을 놓치는 ‘Lost in the Middle’ 현상이 발생
Tokenization:
- 텍스트가 숫자로 변환되는 단위
- 한국어는 영어보다 토큰 소모가 컸으나, 최신 모델(tiktoken)에서는 효율이 대폭 개선
비용 최적화:
- Prompt Compression: 불필요한 수식어 제거
- Caching: 동일한 시스템 프롬프트나 반복되는 컨텍스트에 대해 비용을 할인받는 기능 활용

엔터프라이즈 급 서비스를 위해 반드시 고려해야 할 ‘Back-end’ 관점의 기술
API Key 보안:
- .env 파일 활용 및 시스템 환경 변수 격리
- Client-side(JS)에서 직접 호출 금지 (반드시 서버를 거치는 Proxy 구조)
Rate Limit (기능 제한) 대응:
- OpenAI는 계정 등급에 따라 분당 요청수(RPM)와 토큰수(TPM)를 제한
- Exponential Backoff: 요청 실패 시 재시도 간격을 지수적으로 늘리는 알고리즘 구현 필수
Moderation API:
- 사용자의 입력이나 모델의 출력이 유해한지 실시간 검사하여 가이드라인 준수

요약 및 학습 포인트
LLM 서비스는 단순한 API 호출이 아니라,
비결정론적(Probabilistic)인 모델의 출력을 결정론적(Deterministic)인 시스템의 영역으로 끌어오는 과정