형식이 맞는가, 뜻이 맞는가

이 장을 다 읽으면

1. SLM을 온프레미스에 세우는 네 가지 이유를 대고, 7B 모델을 돌리려면 어떤 하드웨어가 필요한지 숫자로 말할 수 있다.
2. 딥러닝과 AI 에이전트가 왜 "대립"이 아니라 "층위"인지 설명하고, 다섯 개 항목으로 비교할 수 있다.
3. 어떤 코드를 보고 그것이 무상태(페널티 에어리어) 인지 상태 유지(넓은 필드) 인지 판별할 수 있다.
4. 임베딩이 인코딩과 무엇이 다른지 말하고, King − Man + Woman ≈ Queen 이 왜 성립하는지 설명할 수 있다.
5. 벡터 DB와 그래프 DB를 "유사도 ↔ 관계" 축으로 구분하고, GraphRAG가 왜 둘을 합치는지 안다.
6. 규칙 기반과 정책 기반을 구분하고, 한 시스템 안에서 둘을 어떤 순서로 배치해야 하는지 설계할 수 있다.
7. 구문론과 의미론이 이 장의 다른 모든 축의 부모 축임을 설명할 수 있다.
8. 어텐션의 Query·Key·Value가 각각 무엇을 묻고 무엇을 답하는지 한 문장씩으로 말할 수 있다.
9. EC2·RDS·S3를 "어디까지 내가 관리하는가"라는 하나의 축으로 세워놓고 고를 수 있다.

---

0. 이 장의 판별 축

앞에서 배운 대로, 새 용어를 만나면 비유를 찾기 전에 아래 축 중 어디에 꽂히는지부터 정하세요.

축 1이 이 장의 중심입니다. 나머지 네 축은 전부 축 1에서 파생됩니다.

• 형식만 보면 규칙이 되고, 뜻을 보려면 정책이 됩니다 (축 2).
• 형식만 남기면 상태를 안 들어도 되고, 뜻을 누적하려면 상태를 들어야 합니다 (축 3).
• 뜻을 좌표로 재면 벡터 DB, 뜻을 선으로 이으면 그래프 DB입니다 (축 4). 그리고 이 모든 것을 어디에 올려놓을 것인가가 축 5입니다.

앞 장에서 이어집니다 — 4주차 축 1이 무상태(Stateless) ↔ 상태(Stateful) 였고, 이번 장의 축 3이 바로 그것입니다. 그때는 "HTTP 통신 구간은 무상태다"라는 프로토콜 이야기였고 이번에는 내가 쓰는 코드 한 줄이 어느 쪽인가로 내려옵니다. 9주차에서 배운 온톨로지(의미의 지도) 와 스타 토폴로지(연결의 형태) 도 회수됩니다. 온톨로지는 축 1의 오른쪽(의미론)에, 토폴로지는 왼쪽(형식)에 꽂힙니다.

---

1. SLM 온프레미스 — 왜 모델을 회사 안으로 들이는가 ⭐

1.1 먼저 축부터 — LLM과 SLM은 "크기" 축이다

SLM(소형 언어 모델, Small Language Model) — [언어 모델]인데, [파라미터 수가 작아 단일 서버·단일 GPU에서 구동 가능하다]는 점에서 LLM과 구별됩니다.

주의할 것이 있습니다. SLM은 "성능이 낮은 모델"이라는 뜻이 아닙니다. 아래 세 축은 자주 같이 붙어 다니지만 각각 독립된 축입니다.

"SLM이니까 당연히 로컬"이 아니라, "SLM은 작아서 로컬에 올릴 수 있는 선택지가 생긴다"가 정확한 문장입니다.

1.2 온프레미스 — 번역어에 속지 않기

온프레미스(On-Premise) 의 premise 는 "전제"가 아니라 "건물·구내(構內)" 입니다. on-premise = 우리 건물 안에서. 클라우드가 "남의 컴퓨터"라면 온프레미스는 "우리가 산 컴퓨터"입니다.

⚠️ Base 가 "기초"가 아니라 "저장소·거점"이었던 것과 같은 종류의 번역 함정입니다. 영어 단어의 한국어 번역이 원 개념을 왜곡하는 지점을 항상 의심하세요.

1.3 도입 배경 — 네 가지 이유

SLM을 사내 인프라에 직접 구축하는 것은 보안과 효율성을 동시에 확보하기 위한 전략입니다. 이유는 네 가지입니다.

이유 1과 2가 실무에서 결정타입니다. 이유 1은 법의 문제입니다 — 개인정보나 영업비밀이 담긴 문서를 외부 API에 그대로 던지는 순간, 그것은 "편한 방법"이 아니라 "유출"입니다. 이유 2는 회계의 문제입니다 — 사용량 기반 과금은 서비스가 성공할수록 비용도 같이 커지므로, 예산을 미리 못 박아야 하는 조직에서는 그 자체가 리스크입니다.

소버린 AI (Sovereign AI) — "우리 데이터에 대한 주권을 우리가 갖는다"는 관점입니다. 개인 주소록·인사 정보·계약서처럼 밖으로 나가면 안 되는 데이터는 아예 로컬 DB에만 저장하고, 그 데이터를 다루는 모델도 로컬에 두는 것이 이 관점의 실천입니다. 이번 주 실습에서 구글 주소록을 내려받아 도커 안의 pgvector에만 넣은 것이 정확히 이 이유입니다. (12.8절)

1.4 하드웨어 요구사항 — VRAM이 한계를 정한다

로컬 모델에서 성능의 상한을 정하는 것은 CPU도 RAM도 아니고 VRAM(그래픽카드 메모리) 입니다. 모델의 가중치 전체가 VRAM에 올라가야 추론이 시작되기 때문입니다.

(추론 및 RAG 기준의 일반적인 수치입니다. 학습·파인튜닝은 이보다 훨씬 더 필요합니다.)

왜 7B에 16GB인가를 계산으로 확인해 두면 다른 모델도 추론할 수 있습니다.

파라미터 70억 개 × 2바이트(FP16) ≈ 14GB      ← 가중치만
+ KV 캐시 · 활성값 · 프레임워크 오버헤드      ← 여기서 몇 GB 더
────────────────────────────────────────
≈ 16GB                                       ← 그래서 최소 16GB

같은 계산을 13B에 적용하면 130억 × 2바이트 ≈ 26GB, 여기에 오버헤드를 더하면 32GB가 나옵니다. 숫자를 외우지 말고 계산식을 외우세요. 그러면 새 모델이 나와도 필요 사양을 스스로 뽑을 수 있습니다.

1.5 양자화 — 요구 사양을 끌어내리는 열쇠

양자화(Quantization) — [모델 압축 기법]인데, [가중치의 수치 정밀도를 낮춰 메모리 사용량을 줄인다]는 점에서 다른 경량화 기법과 구별됩니다.

위 계산식의 × 2바이트 부분을 건드리는 것입니다.

⭐ 양자화 = 정밀도를 낮춰 메모리를 줄이는 것. 품질 손실과의 거래(trade-off)입니다. 4비트/8비트 압축을 적용하면 하드웨어 요구 사양을 대폭 낮출 수 있습니다. "RTX 4090이 없으면 못 한다"가 아니라 "양자화하면 더 낮은 카드에서도 시작할 수 있다"가 정확한 결론입니다.

앞에서 배운 트레이드오프(Trade-off) 가 여기서 다시 나옵니다. 얻는 것은 메모리, 잃는 것은 정밀도입니다.

1.6 핵심 아키텍처 3요소

온프레미스 SLM 시스템은 세 덩어리로 이루어집니다. 이 셋을 따로 세워두면 어디를 손봐야 할지가 분명해집니다.

각 요소가 담당하는 실패 유형

이 3분할이 유용한 진짜 이유는, 문제가 생겼을 때 어디를 봐야 하는지가 나뉘기 때문입니다.

⭐ RAG의 존재 이유는 "똑똑하게 만들기"가 아니라 "환각 현상 방지"입니다. 모델은 "모른다"고 말하기보다 그럴듯한 문장을 만들도록 학습되어 있습니다. 그래서 근거 문서를 옆에 붙여주고 "근거에 없으면 모른다고 답하라"고 명시해야 합니다.

vLLM과 Ollama — 같은 층, 다른 목적

학습 단계에서는 Ollama로 시작하고 여러 사람이 동시에 쓰는 순간 vLLM을 검토하는 것이 자연스러운 순서입니다.

1.7 SLM의 한계 — 안 되는 것도 알아야 고를 수 있다

⭐ 실전 조합: 민감 데이터의 전처리·분류는 로컬 SLM, 최종 추론은 상용 LLM. 이번 주 실습에서 KcELECTRA-base 라는 작은 한국어 모델로 메일을 먼저 걸러낸 것이(12.13절) 이 전략의 실제 사례입니다.

---

2. 딥러닝과 AI 에이전트 — 대립이 아니라 층위

2.1 이 둘은 같은 줄에 놓고 비교할 대상이 아니다

많은 사람이 "딥러닝이 좋은가, 에이전트가 좋은가"를 묻습니다. 이 질문 자체가 축을 잘못 잡은 것입니다.

⭐ 두 개념은 대립 구조가 아니라, '기술적 엔진(기술)' 과 이를 활용하는 '자율적 주체(시스템)' 의 관계입니다.

한 줄 비유로 고정해 두세요.

딥러닝이 지능을 처리하는 '뇌'라면, 에이전트는 그 뇌를 탑재하고 도구를 사용하며 스스로 행동하는 '몸'입니다.

뇌와 몸은 경쟁하지 않습니다. 층위가 다릅니다. "CPU가 좋은가, 컴퓨터가 좋은가"라고 묻지 않는 것과 같습니다.

2.2 핵심 비교표

2.3 이 표를 축으로 다시 읽기

다섯 행이 결국 두 개의 축으로 요약됩니다.

첫 번째 축이 바로 이 장의 축 3(무상태 ↔ 상태 유지) 입니다. 같은 축이 코드 수준(3장), 시스템 수준(여기), 인프라 수준(11장)에서 반복해 나타납니다. 앞에서 배운 프랙탈 구조입니다.

2.4 에이전트 루프

   [환경 인지] ──▶ [계획] ──▶ [도구 활용] ──▶ [실행] ──▶ [결과 확인]
        ▲                                                     │
        └───────────────  경로 수정 (Self-Reflection)  ◀───────┘

딥러닝은 이 그림에서 [계획] 칸 안에 들어가는 부품입니다. 그림 전체가 에이전트입니다.

🔒 삭제·결제·배포·메일 발송처럼 되돌릴 수 없는 작업은 루프 안에서 자동 실행하지 말고 사람 확인을 거치게 하세요. 에이전트가 "알아서 다 한다"는 말은 정확하지 않습니다. 에이전트는 사람이 준 목표와 권한 안에서 순서를 따라 도구를 쓰는 방식이며, 정하는 것은 목표가 아니라 경로입니다. (흔한 오해는 부록 C를 보세요.)

---

3. 축구장 — 페널티 에어리어와 넓은 필드 ⭐

3.1 왜 이 비유가 필요한가

자바스크립트의 화살표 함수, 리액트의 함수형/클래스형 컴포넌트, 파이썬의 메서드와 클래스 — 서로 다른 언어의 서로 다른 문법이지만 하나의 질문으로 전부 갈립니다.

"이것은 상태를 안에 들고 있는가?"

축구장 하나를 머릿속에 그려놓고, 새 문법을 만날 때마다 에어리어 안인가 필드 위인가를 정하세요.

┌────────────────────────────────────────────────────────────────┐
│                                                                │
│   ┌────────────┐                                ┌────────────┐ │
│   │  페널티     │                                │  페널티     │ │
│   │  에어리어   │         넓은 필드               │  에어리어   │ │
│   │            │        (The Field)             │            │ │
│   │  무상태     │        상태 유지                │  무상태     │ │
│   │ Stateless  │        Stateful                │ Stateless  │ │
│   └────────────┘                                └────────────┘ │
│                                                                │
└────────────────────────────────────────────────────────────────┘
   좁고 명확, 외부와 격리          넓고 유기적, 흐름이 지속됨

3.2 🥅 페널티 에어리어 — 독립성과 명확성

핵심 키워드: 무상태(Stateless), 국소적 스코프(Local Scope), 예측 가능성

페널티 에어리어는 경기장 안에서 가장 규칙이 엄격하고 명확하며, 특정 순간의 판정이 외부 환경에 의해 흔들리지 않는 독립적인 공간입니다. 프로그래밍에서는 외부 상태에 의존하지 않고 주어진 역할만 정밀하게 수행하는 함수와 컴포넌트가 여기에 해당합니다.

1) 화살표 함수 (Arrow Function) — 자바스크립트

// 일반 함수 — this 가 호출 방식에 따라 바뀐다 (필드 위에서 흔들린다)
const team = {
  name: "FC Area",
  players: ["A", "B"],
  showNormal: function () {
    this.players.forEach(function (p) {
      console.log(this.name, p);   // ❌ this 가 team 이 아니다
    });
  },
  showArrow: function () {
    this.players.forEach((p) => {
      console.log(this.name, p);   // ✅ 선언된 위치의 this 를 그대로 쓴다
    });
  },
};

• 렉시컬 디스(Lexical This): 일반 함수와 달리 호출 방식에 따라 this 가 동적으로 변하지 않고 자신이 선언된 상위 스코프의 this 를 그대로 고정해 가져갑니다. 에어리어 안의 규칙이 언제나 엄격하게 유지되는 것과 같습니다.
• 간결성과 순수성: 한 줄짜리 제어나 매핑 알고리즘에 주로 쓰이며, 부작용(Side Effect)을 최소화하는 무상태 함수의 구현에 적합합니다.

⚠️ Lexical 은 "어휘의"라는 사전적 번역보다 "코드에 쓰여 있는 위치 기준" 으로 이해하세요. 실행할 때 정해지는 게 아니라 작성할 때 이미 정해져 있다는 뜻입니다.

2) 리액트 함수형 컴포넌트 & Hooks

// props 를 받아 UI 를 반환한다. 그게 전부다.
function PlayerCard({ name, number }) {
  const [open, setOpen] = useState(false);   // 국소적 상태만 제한적으로
  return (
    <div onClick={() => setOpen(!open)}>
      {number}. {name} {open && "— 상세"}
    </div>
  );
}

• 데이터 흐름: 상위로부터 받은 props 를 입력받아 그대로 UI를 반환합니다. 앞에서 배운 UI = f(state) 공식이 그대로 적용됩니다.
• 무상태 지향: 컴포넌트가 거대한 상태를 직접 소유하기보다 useState·useMemo 같은 Hooks로 국소적인 영역 안에서만 데이터 생명주기를 제한적으로 관리합니다. 그래서 테스트와 유지보수가 쉽습니다.

3) 파이썬 인스턴스 메서드

class Player:
    def __init__(self, name, number):
        self.name = name        # ← 여기는 필드 (상태)
        self.number = number

    def shirt_label(self) -> str:       # ← 여기는 에어리어 (행위)
        return f"{self.number}. {self.name}"

• 제한된 범위: 클래스 내부 또는 특정 인스턴스 스코프(self) 안에서만 유효하며, 객체의 특정 행위(Behavior)만을 정의하는 좁은 범위의 함수입니다. 상태는 self 에 있고 메서드는 그 상태를 읽어서 쓸 뿐 스스로 보관하지 않습니다.

3.3 🌿 넓은 필드 — 지속성과 공유성

핵심 키워드: 상태 유지(Stateful), 렉시컬 환경(Lexical Environment), 데이터 은닉

넓은 필드는 전후반 90분 내내 모든 선수의 움직임과 전술이 실시간으로 누적되고 흐르는 거시적인 공간입니다. 프로그래밍에서는 종료된 시점 이후에도 데이터를 메모리에 안전하게 유지하거나, 여러 요소가 공유할 수 있는 거대한 컨텍스트를 뜻합니다.

1) 클로저 (Closure)

function createScoreboard() {
  let score = 0;                    // 외부 함수의 지역 변수
  return {
    goal: () => ++score,            // 내부 함수가 score 를 계속 참조
    read: () => score,
  };
}

const board = createScoreboard();
board.goal();
board.goal();
console.log(board.read());          // 2  ← createScoreboard 는 이미 끝났는데도 살아 있다
console.log(board.score);           // undefined  ← 밖에서 직접 못 건드린다

• 렉시컬 환경의 기억: 외부 함수의 실행이 이미 종료되어 콜 스택(Call Stack)에서 제거되었음에도 불구하고, 내부 함수가 선언 당시의 상위 스코프 변수들을 계속 참조하는 구조입니다.
• 데이터 은닉(Private Variable): 전역 변수의 무분별한 오염을 막으면서도, 특정 상태를 안전하게 유지·변경할 수 있는 밀폐된 필드를 제공합니다.

앞에서 배운 것과 잇기 — 4주차에서 클로저를 "상태를 가지는 함수"로 배웠고 스택·힙·가비지 컬렉션으로 설명했습니다. 스택에서 사라졌는데도 값이 살아 있는 이유는 그 값이 힙에 있고 내부 함수가 참조를 붙들고 있어 가비지 컬렉션 대상이 되지 않기 때문입니다. 축구장 비유는 그 메커니즘을 한 장의 그림으로 기억하기 위한 손잡이이지, 메커니즘을 대체하지 않습니다.

2) 리액트 클래스형 컴포넌트 및 상태 공간 (State & Context)

• 지속적인 상태 관리: 애플리케이션이나 컴포넌트가 살아 있는 동안 유지되어야 하는 핵심 데이터(state)입니다.
• 전역 필드: 공통의 전술을 공유하듯 여러 에어리어(하위 컴포넌트)가 함께 참조·동기화해야 하는 거대한 데이터의 흐름을 통제합니다. Context 와 전역 상태 저장소가 여기에 해당합니다.

3) 파이썬 클래스 (Class)

• 상태와 행위의 캡슐화: 인스턴스가 생성된 뒤 메모리 공간에 존재하며 변수(self.attribute)들의 상태를 영속적으로 유지합니다. 필드 전체의 판을 짜고, 그 안에서 여러 메서드가 유기적으로 협력할 수 있게 하는 최상위 틀입니다.

3.4 핵심 요약 및 비교 구조도

3.5 판별 훈련 — 다음은 어느 쪽인가

3.6 어느 쪽을 기본값으로 삼을 것인가

⭐ 기본은 에어리어. 필요할 때만 필드로 나갑니다.

이유는 디버깅 비용입니다. 무상태 함수는 입력만 보면 출력을 예측할 수 있어서 틀렸을 때 그 함수 안만 보면 되지만, 상태를 든 코드는 "누가 언제 이 값을 바꿨는가"를 추적해야 하고 그 추적 범위가 곧 필드 전체입니다.

그렇다고 필드가 나쁜 것은 아닙니다. 기억해야 하는 것은 반드시 어딘가에 있어야 합니다. 좋은 설계는 필드를 없애는 것이 아니라 필드를 좁고 명확한 자리에 몰아두는 것이고, 클로저의 데이터 은닉이 정확히 그 일을 합니다.

---

4. 임베딩 — 뜻을 좌표로 바꾸기 ⭐

4.1 정의

임베딩(Embedding) — [데이터 변환 기술]인데, [의미론적 유사성을 공간적 거리로 보존한다]는 점에서 단순 인코딩과 구별됩니다.

사람이 쓰는 자연어·이미지·오디오 같은 비정형 데이터를 컴퓨터가 연산할 수 있는 고차원의 연속적인 수치 벡터(Vector) 로 바꾸는 기술입니다.

[원시 데이터: 텍스트/이미지] ──(AI 인코더 모델)──▶ [고차원 밀집 벡터 (예: 768차원)]

4.2 인코딩과 무엇이 다른가 — 여기가 핵심이다

이 둘을 구분하지 못하면 벡터 DB 전체가 이해되지 않습니다.

⭐ 핵심 메커니즘: 고차원 공간(Vector Space) 위에 의미가 유사한 엔티티들을 가깝게 배치합니다. '사과'와 '배'의 거리는 가깝고, '사과'와 '노트북'의 거리는 멀게 배치됩니다.

4.3 수학적 성질 — 벡터 연산으로 관계가 추론된다

벡터가 되면 덧셈과 뺄셈이 가능해집니다. 그리고 그 연산 결과가 의미를 갖습니다.

Vector(King) − Vector(Man) + Vector(Woman) ≈ Vector(Queen)

이 식을 말로 풀면 이렇습니다.

1. King − Man → "왕"에서 "남성"이라는 성분을 뺀다 → 남은 것은 "군주라는 지위" 라는 방향
2. + Woman → 거기에 "여성"이라는 성분을 더한다 → 결과는 여성인 군주 = Queen

즉 "성별"이라는 방향과 "지위"라는 방향이 벡터 공간 안에서 각각 독립된 축으로 자리를 잡았다는 뜻입니다. 아무도 "성별 축을 만들어라"라고 지시하지 않았는데, 대량의 문장을 학습하는 과정에서 저절로 그렇게 배치된 것입니다.

이것이 축 1이 말하는 바입니다. 인코딩은 형식(구문론) 만 다루고, 임베딩은 뜻(의미론) 을 다룹니다. 그리고 뜻을 다루기 시작하는 순간 "비슷하다"를 계산할 수 있게 됩니다.

4.4 임베딩의 시스템 내 역할

주요 역할: 시스템의 모든 비정형 데이터를 공통된 '수학적 언어'로 통일하여 후속 저장소 및 알고리즘 레이어로 전달하는 것.

텍스트든 이미지든 오디오든 임베딩을 통과하고 나면 전부 같은 형태의 숫자 배열이 됩니다. 그래서 뒤에 오는 벡터 DB는 원본이 무엇이었는지 몰라도 됩니다. 이것이 통합 번역기로서의 역할입니다.

4.5 실무에서 임베딩 품질을 정하는 세 가지

검색 품질  =  임베딩 모델  ×  청킹  ×  인덱스

청킹 실무 기준: 문단·헤딩 경계를 우선하고, 조각끼리 10~20% 겹침(overlap) 을 둡니다. 문장이 조각 경계에서 잘려 뜻이 사라지는 것을 막기 위해서입니다.

⚠️ 한국어는 임베딩 모델 선택이 특히 중요합니다. 다국어를 제대로 학습한 모델인지, 한국어 특화 모델인지 반드시 확인하세요. 이번 주 실습에서 "pgvector 저장 단계에서 쓸 임베딩 모델을 한국 현장 기준으로 추천받기"를 별도 과제로 둔 이유가 이것입니다. (12.12절)

4.6 RAG 파이프라인 — 임베딩이 놓이는 자리

[적재]  문서 → 청킹 → 임베딩 → 벡터DB 저장
[질의]  질문 → 임베딩 → 유사 청크 top-k 검색 → 프롬프트에 주입 → 생성

같은 임베딩 모델이 양쪽에 쓰여야 합니다. 문서를 A 모델로 넣고 질문을 B 모델로 변환하면, 두 벡터는 서로 다른 공간에 찍히므로 거리 계산이 무의미해집니다.

⚠️ RAG가 망가지는 지점은 대부분 "생성"이 아니라 "검색"입니다. 답이 이상하면 모델을 바꾸기 전에 검색된 청크를 눈으로 보세요. 근거가 틀렸으면 검색 문제, 근거는 맞는데 답이 틀렸으면 프롬프트·모델 문제입니다.

---

5. 벡터 DB와 그래프 DB — 유사도인가 관계인가

5.1 두 저장소는 경쟁자가 아니라 상호보완이다

임베딩된 데이터와 엔티티 간의 관계를 관리하기 위해 두 가지 상호보완적인 데이터베이스 구조를 씁니다.

                          ┌───▶ [벡터 데이터베이스] ───▶ 의미론적 유사도 기반 컨텍스트 검색
[임베딩된 수치 벡터] ─────┤
                          └───▶ [그래프 데이터베이스] ───▶ 엔티티 간 관계망 및 인과관계 추적

5.2 벡터 데이터베이스 (Vector Database)

벡터 DB — [데이터 저장소]인데, [고차원 벡터의 유사도 검색에 특화되어 있다]는 점에서 RDBMS와 구별됩니다.

• 개념: 고차원 벡터 데이터를 저장하고, 질의(Query) 벡터와 가장 유사한 데이터 포인트를 빠르게 찾아내는 데 특화된 저장소입니다.
• 핵심 기술: 정확한 전수 조사는 연산 비용이 크므로 근사 근접 이웃(ANN, Approximate Nearest Neighbor) 알고리즘을 씁니다. 적용 분야: 유사 이미지 검색, 추천 시스템, LLM 기반 검색 증강 생성(RAG) 의 컨텍스트 공급원.

ANN — "정확히"를 포기하고 "빠르게"를 얻는 거래

100만 개의 벡터가 있을 때 질문 벡터와 가장 가까운 것을 정확히 찾으려면 100만 번 거리를 계산해야 합니다(전수 검색, Brute Force). ANN은 거의 맞는 답을 훨씬 빨리 찾는 방식이며, 여기서도 트레이드오프가 나옵니다.

💡 이름이 역색인(Inverted Index)과 비슷한 것은 IVF(Inverted File) 쪽이고, 그마저도 "단어 → 문서"가 아니라 "구역 → 벡터 목록"입니다. 헷갈리면 축으로 돌아가세요. 역색인은 구문론(단어가 일치하는가), ANN은 의미론(좌표가 가까운가)입니다.

5.3 그래프 데이터베이스 (Graph Database)

그래프 DB — [데이터 저장소]인데, [관계(Relationship)를 일급 객체로 취급한다]는 점에서 RDBMS·벡터 DB와 구별됩니다.

• 개념: 데이터 자체보다 데이터 간의 관계를 일급 객체(First-class Citizen)로 다루어, 노드(Node, 엔티티) 와 엣지(Edge, 연결선) 구조로 관리합니다.
• 핵심 기술: 다대다(N:M) 관계나 계층 구조를 탐색할 때 RDBMS의 무거운 조인(Join) 연산 없이, 포인터를 따라 네트워크를 종단하는 그래프 탐색(Graph Traversal) 을 수행합니다. 적용 분야: 소셜 네트워크 분석, 금융 이상 거래 패턴 탐지(Fraud Detection), 지식 그래프(Knowledge Graph) 구축.

"일급 객체(First-class Citizen)"의 뜻 — 어떤 것이 일급이라는 말은 그 자체를 값처럼 저장하고, 전달하고, 질의할 수 있다는 뜻입니다. RDBMS에서 관계는 외래 키(FK)라는 부수적인 장치라 관계 자체에 속성을 붙이기 어렵지만, 그래프 DB에서 엣지는 이름과 속성과 방향을 가진 독립된 데이터입니다. [:WORKS_WITH {since: 2024}] 처럼 씁니다.

앞에서 배운 것과 잇기 — 9주차에서 그래프 = 노드(Vertice/Node) + 엣지(Edge/Link, 방향성 유무 존재) 라고 정의했고, 컴퓨터공학·수학(통계학)·그래프이론·네트워크이론에서 이름만 다를 뿐 개념은 동일하다는 것도 확인했습니다. 그래프 DB는 그 수학적 구조를 그대로 저장소로 만든 것입니다.

5.4 비교표 — 축 4

5.5 Vector RAG와 Graph RAG

⭐ Vector RAG는 질문을 임베딩해 Vector DB에서 유사 검색하고, Graph RAG는 Graph DB에서 관계성 데이터를 추출합니다. 둘 다 외부 시스템의 검색 결과를 프롬프트에 포함해 LLM에 쿼리하는 것이며, 그것이 RAG의 정의입니다.

여기서 놓치면 안 되는 지점은 "RAG는 저장소 종류로 정의되지 않는다" 는 것입니다. RAG의 정의는 "검색 결과를 프롬프트에 넣는다" 이고, 무엇으로 검색하는지는 그 아래 선택지입니다.

RAG (Retrieval-Augmented Generation)
├── Vector RAG   : 질문 임베딩 → 벡터 DB 유사도 검색 → 상위 k개 청크
├── Graph RAG    : 질문에서 엔티티 추출 → 그래프 DB 탐색 → 관계 경로
└── (그 외)       : 키워드 검색, SQL 조회, 웹 검색 …

GraphRAG — 융합 트렌드

💡 기술 융합 트렌드: GraphRAG — 단편적인 문장 유사도만 보는 벡터 검색의 단점을 보완하기 위해, 문서 안 엔티티의 계층과 인과관계를 그래프 DB로 구조화한 뒤 결합하는 GraphRAG 아키텍처가 결론의 정교함을 높이는 핵심 트렌드로 자리 잡고 있습니다.

왜 합쳐야 하는지를 예로 보면 분명해집니다.

GraphRAG = 의미 유사도 + 관계로 근거를 모으는 방식입니다.

5.6 온톨로지가 다시 나오는 자리

9주차에서 배운 온톨로지(Ontology) — 데이터와 지식 간의 의미와 관계를 컴퓨터가 처리할 수 있도록 정형화한 지식 지도 — 가 여기서 회수됩니다.

⭐ 에이전틱 AI 시대에 온톨로지가 중요한 이유 — 검색(RAG)을 넘어 실행으로.

RAG는 "찾아서 보여주기"까지이고, 에이전트는 "찾은 것으로 실행"까지 갑니다. 실행하려면 무엇이 무엇에 속하고, 무엇이 무엇의 앞에 오는지를 알아야 합니다. 그것이 온톨로지입니다.

온톨로지 설계 4단계

is-a 와 part-of 는 앞에서 배운 IS-A(상속)·HAS-A(연관) 의 온톨로지판 이름입니다. 같은 구조가 객체지향·DB 설계·온톨로지에서 이름만 바꿔 반복됩니다.

온톨로지 폴더는 어디에 두는가

apps/
  star_craft/                    ← 허브(Hub)
    domain/
      ontology/                  ⭐ 여기
    _docs/
      star-craft-pipeline.md
  <spoke_1>/                     ← 스포크(Spoke)
  <spoke_2>/
core/                            ← 순수 인프라 (DB 엔진, 외부 클라이언트)

• core/ 는 순수 인프라(DB 엔진·외부 클라이언트) 레이어이므로 도메인 지식이 들어가면 안 됩니다. 허브(star_craft)는 이미 전역 온톨로지 인덱스·라우팅 허브로 정의되어 있습니다.
• 스팸 분류 같은 개별 유스케이스는 스포크에 남기고, 허브의 ontology 를 참조합니다.
• ⭐ 의존성은 spoke → hub 만 허용합니다. 스포크끼리의 직접 참조와 순환 참조는 금지입니다.

9주차의 스타 토폴로지 규칙 — "스포크 간 직접 통신 불가, 반드시 허브를 거쳐 중계" — 가 폴더 구조로 내려앉은 모습입니다. 네트워크의 규칙과 코드의 규칙이 같은 모양인 것, 이것이 프랙탈입니다.

---

6. 규칙 기반과 정책 기반 — 의사결정의 두 방식 ⭐

6.1 규칙 기반 접근 방식 (Rule-based)

규칙 기반 — [의사결정 방식]인데, [인간이 If-Then을 명시적으로 지정한다]는 점에서 정책 기반과 구별됩니다.

• 정의: 명시적인 "If-Then (조건-행동)" 구조를 인간 도메인 전문가가 직접 하드코딩하여 시스템을 통제하는 방식. 장점: 결정론적 결과가 보장되므로 예측 가능성이 매우 높고, 오작동 시 원인 추적(Traceability) 이 명확합니다.
• 단점: 다뤄야 하는 변수가 많아지거나 예외 상황(Edge Case)이 생기면 규칙 수가 기하급수적으로 늘어나 관리가 불가능해집니다. 이를 규칙 폭발(Rule Explosion) 이라고 합니다.
• 적용 적합 영역: 절대 타협할 수 없는 법적 규제 검증, 안전 기준 가드레일(Guardrail), 식품위생법·HACCP 기준 검증.

# 규칙 기반의 전형 — 읽으면 바로 이해되고, 틀리면 어느 줄인지 알 수 있다
def check_layout(plan):
    if plan.aisle_width < 1.2:
        return Reject("통로 폭 최소 기준 위반")
    if plan.distance(plan.raw_zone, plan.cooked_zone) < 3.0:
        return Reject("교차오염 방지 이격거리 위반")
    return Pass()

6.2 정책 기반 접근 방식 (Policy-based)

정책 기반 — [의사결정 방식]인데, [개별 행동이 아니라 목적함수와 제약을 정의한다]는 점에서 규칙 기반과 구별됩니다.

• 정의: 개별 행동 규칙을 일일이 지정하는 대신, 시스템이 달성해야 할 상위 수준의 목적함수(Objective Function), 제약 조건, 보상 체계(Policy) 를 정의하는 방식. 장점: 예상하지 못한 동적 환경 변화나 복잡한 다차원 제어 환경에서도 시스템이 자율적으로 최적의 행동 패턴을 학습하거나 계산해 냅니다.
• 단점: 내부에 확률적 모델이나 복잡한 최적화 알고리즘(예: 강화학습의 Policy Network)이 관여하므로, "특정 순간에 왜 그 행동을 했는가"에 대한 미시적 설명 가능성이 낮습니다.
• 적용 적합 영역: 디지털 트윈 기반 공장 레이아웃 시뮬레이션, 복잡한 물류 동선 최적화, 장비 파라미터 자율 제어.

# 정책 기반의 전형 — "무엇을 잘한 것으로 볼 것인가"만 정의한다
objective = maximize(throughput) - 0.3 * penalty(travel_distance)
constraints = [aisle_width >= 1.2, distance(raw, cooked) >= 3.0]
best_plan = optimizer.search(objective, constraints)

6.3 비교표 — 축 2

6.4 통합 지능형 아키텍처 매트릭스

지금까지 나온 다섯 요소가 하나의 시스템 안에서 어떻게 조화를 이루는지 요약한 표입니다.

6.5 통합 워크플로우 — 순서가 곧 설계다 ⭐

다섯 요소를 융합해 '규제 준수형 공정 최적화 시뮬레이션 시스템' 을 만든다면 흐름은 다음과 같습니다.

[원천 정보 수집] 규정 문서, 공장 도면, 장비 사양서
       │
       ▼
[1. 임베딩 레이어] 모든 텍스트 및 사양 데이터를 고차원 벡터로 변환
       │
       ├──────────────────────────────────────────┐
       ▼                                          ▼
[2. 벡터 데이터베이스]                      [3. 그래프 데이터베이스]
- 유사한 공정 가이드라인 본문 검색          - 장비-제품-공정 간의 인과관계 추적
- 과거 유사 트러블슈팅 사례 추출            - 작업 절차의 선후 관계 네트워크 파악
       │                                          │
       └────────────────────┬─────────────────────┘
                            ▼
               [4. 정책 기반 제어 엔진]
               - 디지털 트윈 시뮬레이션 공간 안에서 최적의 장비 배치·공정 경로 자율 탐색
               - 생산성 및 효율성 극대화를 목표로 자율 최적화안 도출
                            │
                            ▼
               [5. 규칙 기반 가드레일 엔진]
               - 도출된 최적안이 식품위생법, HACCP 안전 거리, 법적 표시 기준을 위반하는지 검증
               - 위반 시 해당 안을 차단하고 재시뮬레이션 명령 (Hard Constraint)
                            │
                            ▼
                     [최종 안전 최적안 출력]

왜 정책이 먼저고 규칙이 나중인가

⭐ 순서를 뒤집으면 안 됩니다. 이것이 이 절에서 가장 중요한 한 줄입니다.

또한 책임의 위치도 달라집니다. 가드레일이 마지막에 있어야 "최종 출력물은 100% 검증을 통과했다"고 말할 수 있습니다. 중간에 있으면 그 뒤 단계에서 다시 위반이 생길 수 있습니다.

이와 같은 유기적 설계를 통해 시스템은 임베딩과 두 종류의 DB를 기반으로 풍부한 '기억과 문맥'을 갖고, 정책 기반 엔진의 유연성과 규칙 기반 엔진의 엄격함을 결합하여 안전하면서도 효율적인 '판단과 실행'을 수행합니다.

앞에서 배운 것과 잇기 — 6주차의 책임 연쇄 패턴(Chain of Responsibility) 이 이 그림의 5번 칸을 구현하는 방법입니다. 정책 하나가 늘 때마다 함수를 열어 고치는 대신 핸들러를 체인에 하나 더 붙입니다. 가드레일은 정책이 계속 늘어나는 자리이므로 체인 구조가 특히 잘 맞습니다.

---

7. 구문론과 의미론 — 이 장의 뼈대 ⭐

7.1 정의

모든 데이터와 시스템을 설계하고 해석할 때,

• 구문론(Syntax) 은 '외형적인 형식과 구조적 규칙' 을, 의미론(Semantics) 은 '본질적인 뜻과 맥락' 을 담당합니다.

7.2 한 문장으로 구별하기

구문론:  문법은 맞지만 말이 안 되는 문장을 통과시킨다.
의미론:  말이 되는지를 본다.

고전적인 예가 "Colorless green ideas sleep furiously." 입니다. 영문법상 완벽하지만(구문론 통과) 뜻이 성립하지 않습니다(의미론 실패). 개발 현장의 예로 바꾸면 이렇습니다.

⭐ 구문론 검사를 통과했다는 말은 "틀리지 않았다"가 아니라 "형식은 맞다"입니다. 이 문장 하나가 이 장 전체를 지탱합니다.

7.3 왜 이 축이 다른 모든 축의 부모인가

같은 축이 토큰 → 웹 → DB → 의사결정 네 층에서 똑같은 모양으로 반복됩니다. 그래서 한 층을 이해하면 나머지 세 층은 추론됩니다.

7.4 역사적 전환 — 사람이 규칙을 쓰던 시대에서 기계가 좌표를 재는 시대로

과거에는 컴퓨터에게 의미를 이해시키기 위해 인간이 일일이 규칙(Rule)을 지정하고, 온톨로지 지식 사전을 직접 수작업으로 구축해야 했으며, 데이터의 선후 관계를 통제하기 위해 연산 흐름을 인위적으로 제한해야 했습니다. 그러나 현재는 데이터를 토큰화하여 트랜스포머의 어텐션 메커니즘을 통해 다중적 맥락을 지닌 고차원 벡터로 정밀하게 압축하고, 이를 pgvector 에 적재하는 방식을 씁니다. 이로 인해 시스템 간 복잡한 API 매칭 규칙 없이도, 대규모 행렬의 병렬 연산과 공간 내 거리 측정을 통해 "식품위생법 개정안"과 "HACCP 의무화 규정" 사이의 긴밀한 의미적 연관성을 자율적으로 추론해내는 진정한 의미론적 제어(Semantic Control) 시스템이 완성됩니다.

⚠️ 다만 규칙이 사라진 것은 아닙니다. 6.5절에서 본 것처럼 규칙은 마지막 가드레일로 자리를 옮겼을 뿐입니다. "의미론이 구문론을 대체했다"가 아니라 "의미론이 앞으로 오고 구문론이 뒤로 갔다" 가 정확한 서술입니다.

---

8. 토큰과 어텐션 메커니즘 — 뜻은 어떻게 생겨나는가 ⭐

8.1 이 절이 놓인 자리

토큰과 어텐션은 구문론과 의미론이 교차하며 고도화되는 최전선에 있습니다. 아래 한 줄이 이 절 전체의 지도입니다.

[원시 문자열]
      │ (구문 규칙에 따른 분절)
      ▼
[토큰 : 구문론적 초기 임베딩]
      │ (어텐션 메커니즘 Q·K·V 연산)
      ▼
[문맥적 임베딩 : 의미론적 가치 획득]

8.2 구문론적 측면 — 토큰과 초기 고정 임베딩

토큰(Token) — [데이터 단위]인데, [정해진 규칙에 따라 기계적으로 쪼갠 최소 분절 단위]라는 점에서 단어·문장과 구별됩니다.

문장이나 소스코드를 공백·기호·형태소 등 정해진 규칙에 따라 기계적으로 쪼개놓은 최소 분절 단위입니다. 여기까지는 순수하게 구문론이고, 뜻은 아직 개입하지 않습니다. 초기 임베딩 공간으로 변환된 토큰은 단어 고유의 독립된 의미(사전적 의미)만 가집니다.

⭐ Mole 예시 — 이 단어는 이 단계에서 '두더지', '화학 분자(몰)', '점(피부)' 이라는 다의적 후보군을 지닌 채 형식적으로만 존재합니다. 주변 문맥 정보가 전혀 반영되지 않은 고정된 벡터 상태입니다.

"The mole dug a tunnel."          ┐
"One mole of carbon."             ├─ 세 문장 모두 mole 의 초기 벡터는 완전히 동일하다
"She has a mole on her cheek."    ┘

같은 글자면 같은 벡터. 이것이 구문론적 단계의 한계이자 정의입니다.

8.3 의미론적 측면 — 어텐션으로 문맥을 입히다

토큰들이 결합해 상위 모델(트랜스포머 아키텍처)에 입력되면, 시스템은 Query, Key, Value 라는 가중치 행렬 연산을 통해 고차원 공간에서 단어의 의미적 위치(방향성)를 자율적으로 이동시킵니다.

세 가지를 각각 한 문장의 질문/답으로 외우세요.

Query — 묻는 쪽

특정 토큰(예: 명사인 creature)이 "나를 설명해 주는 형용사가 주변에 있는가?" 라고 의미론적 질문을 던지는 주체입니다.

Key — 답하는 쪽

다른 토큰들이 그 질문에 대해 "내가 그 단서(열쇠)다" 라고 답하는 매칭 대상입니다.

쿼리와 키의 내적(Dot Product) 연산 후 소프트맥스(Softmax) 를 거쳐, 어떤 단어가 다른 단어에 얼마나 주목(Attend)해야 하는지를 나타내는 확률적 가중치 분포인 어텐션 맵(Attention Map) 을 만듭니다.

                   Q · K  (내적)           Softmax
[creature] ──질문──▶ 각 토큰과의 점수 ──▶ 합이 1인 확률 분포 ──▶ 어텐션 맵

     fluffy   0.9      ← 크게 주목
     blue     0.8      ← 크게 주목
     the      0.05
     a        0.03

💡 왜 하필 내적과 소프트맥스인가 내적(Dot Product) 은 두 벡터의 방향이 얼마나 같은가를 숫자 하나로 압축합니다. 방향이 같으면 크고, 직각이면 0, 반대면 음수입니다. "의미가 비슷하면 방향이 비슷하다"는 임베딩의 성질(4.2절) 위에서, 내적은 의미의 맞물림 정도를 재는 자연스러운 자입니다. 그런데 내적 결과는 −∞ ~ +∞ 범위의 아무 숫자라 비교가 어렵습니다. 소프트맥스(Softmax) 는 이 값들을 전부 양수로 만들고 합이 1이 되도록 정규화합니다. 그 결과 "주의력 100%를 어떻게 나눠 쓸 것인가"라는 배분 문제로 바뀝니다.

Value — 실제로 더해지는 것

문맥적 연관성이 확인되었을 때 "실제로 어떤 의미론적 변화량을 더해 줄 것인가" 를 결정하는 본질적 가치 벡터입니다. 가중치가 반영된 밸류 벡터들이 최종 변화량(ΔE)으로 합산되어 원래 토큰 임베딩에 더해집니다.

E_new(creature) = E_old(creature) + Σ ( attention_weight × V )
                                     ↑
                        '그냥 생명체' → '복슬복슬하고 파란 생명체'

⭐ 이 과정을 거쳐 토큰은 '그냥 생명체' 에서 '복슬복슬하고 파란 생명체' 라는 구체적인 문맥적 의미를 획득합니다. Mole 도 마찬가지로, 주변에 dug·tunnel 이 있으면 '두더지' 쪽으로, carbon·atoms 가 있으면 '화학의 몰' 쪽으로 벡터가 이동합니다.

왜 "교체"가 아니라 "덧셈"인가

어텐션은 원래 벡터를 버리고 새로 만드는 것이 아니라, 원래 벡터에 변화량을 더합니다. 교체하면 원래 단어가 무엇이었는지 잊을 위험이 있지만, 덧셈은 사전적 의미를 유지한 채 문맥만 얹습니다. 그래서 Mole 은 문맥을 얻은 뒤에도 여전히 "mole 이라는 단어"이고, 다만 어느 뜻인지가 정해졌을 뿐입니다.

8.4 멀티헤드 어텐션 (Multi-Head Attention)

하나의 토큰이 지닌 다각도의 의미론적 맥락을 포착하기 위해, 다수의 독립적인 쿼리·키·밸류 헤드를 병렬로 구동하여 문맥적 자율 추론을 극대화합니다. ⭐ GPT-3 기준 96개의 헤드가 병렬로 돌아갑니다. 왜 여러 개가 필요한지는 질문의 종류를 생각하면 분명합니다.

한 번의 어텐션은 한 종류의 관계만 잡습니다. 96개를 병렬로 돌리면 96가지 관계를 동시에 잡고, 그 결과를 합쳐 하나의 문맥적 임베딩으로 만듭니다.

8.5 전체 흐름 다시 보기

"The fluffy blue creature roamed the field."

1) 토큰화 (구문론)
   [The] [fluffy] [blue] [creature] [roamed] [the] [field]

2) 초기 임베딩 (구문론)
   각 토큰 → 사전적·다의적 고정 벡터

3) Q·K 내적 → 소프트맥스 → 어텐션 맵 (의미론 시작)
   creature 의 Q 가 fluffy·blue 의 K 와 크게 맞물림

4) 가중합된 V 를 ΔE 로 더함
   creature = '그냥 생명체' + '복슬복슬함' + '파랑'

5) 멀티헤드로 96가지 관계를 동시에
   → 문맥적 임베딩 완성 (의미론)

그리고 5번에서 나온 이 문맥적 임베딩이 곧 4장에서 배운 임베딩입니다. 임베딩 모델의 내부가 이렇게 생겼습니다. 4장과 8장은 같은 대상을 밖에서 본 것과 안에서 본 것입니다.

---