LLM(Large Language Model) 애플리케이션 개발은 단순히 API를 호출하여 텍스트를 받아오는 것이 전부가 아니다. 이 개념을 어떻게 바라보느냐에 따라 설계가 달라진다.

💡 LLM은 “매우 똑똑하지만, 건망증이 심하고 융통성이 없는 신입 사원”이다. 개발자는 이 신입 사원에게 최적의 ‘작업 환경’을 만들어주는 역할을 한다.

프레임워크(LangChain, LlamaIndex 등)가 바뀌어도 변하지 않는 5가지 기본 법칙을 정리한다.

1. LLM (The Engine): 뇌

“똑똑하지만 기억력이 없는 연산 장치”

핵심은 Stateless(무상태)다. 모델은 이전 대화를 기억하지 못한다. 매번 요청을 보낼 때마다 상대를 처음 보는 사람 취급한다.

  • Temperature (0.0 ~ 1.0): 창의성 조절 레버.
    • 0.0: 팩트 위주. (개발/테스트용)
    • 1.0: 아무말 대잔치 가능성 있음. (창작용)
  • Context Window: 한 번에 읽을 수 있는 글자 수 제한. 이 한계 때문에 RAG 기술이 탄생했다.

2. 프롬프트 (The Instructions): 업무 지시서

“단순 질문이 아닌, 구조화된 명령”

모델에게 역할을 부여하고 가이드를 주는 단계다. 단순히 질문만 던지는 것이 아니라, 아래와 같은 구조(Structure)를 갖춰야 한다.

Markdown

`# 프롬프트의 기본 구조

  1. System Message: “너는 20년 차 파이썬 개발자야.” (페르소나)
  2. Context: “이 코드는 데이터 분석용이야.” (배경 지식)
  3. Few-shot: “A를 넣으면 B가 나와야 해.” (예시)
  4. User Message: “이 함수를 리팩토링해줘.” (실제 요청)`

3. 임베딩 & 벡터 DB (The Knowledge): 도서관

“LLM이 모르는 지식을 찾아오는 저장소”

LLM의 두뇌에 없는 사내 데이터나 최신 뉴스를 참조하게 만드는 RAG(검색 증강 생성)의 핵심 기술이다.

  • Embedding (임베딩): 텍스트를 숫자(Vector)로 바꾸는 번역기.
    • 사과 ↔ 배 (거리가 가깝다)
    • 사과 ↔ 자동차 (거리가 멀다)
  • Vector DB: 숫자로 변환된 데이터를 저장하는 DB. 질문이 들어오면 의미적으로 가장 가까운(거리가 가까운) 문서를 찾아낸다.

4. 체인 & 메모리 (Chain & Memory): 워크플로우

“작업의 순서와 기억력의 보완”

  • Chain (순서): 여러 작업을 파이프라인처럼 묶는 것.
    • [사용자 질문] -> [번역] -> [답변 생성] -> [재번역]
  • Memory (기억): Stateless한 LLM을 위해 개발자가 대화 내역(History)을 저장했다가, 질문할 때마다 ‘참고 자료’로 동봉해서 보내주는 기술.

5. 에이전트 (Agent): 자율성

“시키는 대로 하는 게 아니라, 스스로 판단하는 주체”

Chain과 Agent의 차이는 ‘판단력’ 유무에 있다.

  • Chain: 기차가 레일 위를 달리듯, 정해진 순서(A→B→C)대로만 간다.
  • Agent: 사용자의 질문을 보고 도구(Tool)를 선택한다.
    • “오늘 날씨 어때?” → (판단) → 🌤️ 날씨 API 도구 사용
    • “123 * 456은?” → (판단) → 🧮 계산기 도구 사용

🧩 정리: 머릿속에 그려야 할 아키텍처

위 5가지 요소는 아래의 흐름으로 하나의 앱이 된다. 이 그림이 머릿속에 구조화되어야 한다.


User Input (질문)
    ⬇️
[Prompt Template] + [Memory (이전 대화)]
    ⬇️
(모르는 내용인가?) ➡️ YES: [Vector DB]에서 자료 검색 (Retrieval)
    ⬇️ NO
[LLM (Engine)] : 질문 처리 및 답변 생성
    ⬇️
Output (답변)