온톨로지와 LLM 내부 동작 원리 Deep Dive

leave_a_comment·2026년 6월 29일

온톨로지란 무엇인가?

온톨로지는 현실 세계의 지식이나 정보를 지도처럼 그려내 AI가 사람처럼 사고할 수 있도록 돕는 구조적 기반이다. 즉 특정 분야에 존재하는 개념이나 관계를 명확하게 정의하고 구조화한 지식 모델이다.

온톨로지 구성 요소

개체

도메인 안에서 실제로 존재하고 식별할 수 있는 구체적인 대상
ex) 배달원, 특정 배달 주문

클래스

유사한 개체들을 묶는 범주로, 도메인의 기본 분류 체계를 형성
ex) DeliveryWorker(배달원), Order(주문)

속성

클래스에 속한 개체가 공통으로 가진 고유한 특징이나 상태를 설명하는 요소
ex) 배달원 - 현재 위치, 근무 가능 여부, 주문 - 배달 주소, 주문 시간

관계

두 개체가 어떻게 연결되어 있는지를 나타내는 의미적 연결
ex) 배달원은 직원이다 (is-a), 주문은 배달 주소를 가지고 있다 (have-a)

제약 조건

속성과 관계가 지켜야 하는 규칙, 도메인 일관성 유지
ex) 한 배달원은 같은 시간에 두 주문을 수행할 수 없다

온톨로지의 필요성 : 데이터가 가진 의미와 그 관계가 정리 되어 있어야 한다

팔란티어는 온톨로지가 데이터, 사건, 자원을 현실 세계의 관계로 재구성해 공통된 언어의 명확한 시스템을 제공한다고 강조했다.
온톨로지로 인해 복잡하고 비효율적인 데이터 전처리 및 정제 작업의 부담을 크게 줄일 수 있다.

개인적으로는 데이터베이스의 ERD를 설계할 때 저장하려는 데이터 간의 관계와 구조를 미리 예측해 설계해야 한다는 점에서 온톨로지와 닮았다고 느꼈다. 엔티티들을 관계로 엮어 전체 구조를 그려나가는 과정이 마인드맵과도 비슷하다고 생각했다.

서비스마다 도메인 정책과 용어 정의가 모두 다르기 때문에 기업별 온톨로지 정의는 반드시 필요하다고 생각한다.

특히 Claude Code를 사용하면서 매번 바로잡아야 했던 내용들을 온톨로지를 통해 선제적으로 명확히 잡고 갈 수 있을 것 같다.
잘못된 결과를 고치기 위한 반복 작업이 줄어드는 만큼 결과적으로 비용 효율도 높아질 수 있다고 본다.

결국 AI를 잘 활용하는 핵심은 의미와 맥락의 일관성을 확보하는 데 있고 토큰 비용 절감은 그 과정에서 자연스럽게 따라오는 부산물이라고 생각한다.

LLM이란 무엇인가?

LLM은 Large Language Model로 직역하면 거대언어모델인데 그 의미는 수많은 파라미터, 즉 모델 내부의 가중치를 학습해 언어의 규칙과 패턴을 익히는 모델이다.

'이 문맥에서 어떤 단어가 올 가능성이 높은가?'를 예측하면서 언어를 배우고, 이를 통해 문장을 생성하게 된다.

이런 예측의 기반이 되는 것은 트랜스포머라는 구조인데,

트랜스포머가 거대 언어 모델에 특히 적합한 이유는 위치 인코딩과 Self-Attention이라는 두 가지 핵심 기술 덕분이다.

위치 인코딩은 단어가 나타나는 순서 정보를 담아 단어를 순차적으로 입력하지 않아도 위치를 알 수 있게 하고,
Self-Attention은 입력된 단어들의 관계를 한꺼번에 계산하면서 실제로 중요한 부분에 더 집중하도록 가중치를 부여한다.

이 덕분에 긴 문장을 처리하거나 문장 속 멀리 떨어져 있는 단어들 사이의 관계도 훨씬 잘 파악할 수 있게 되고, 복잡한 연산을 병렬로 나눠 처리할 수 있어 GPU를 활용한 대규모 학습이 가능해진다.

LLM의 작동 방식

대부분의 LLM은 크게 두 단계의 학습 과정을 거친다.

사전학습(Pretraining) 단계에서는 방대한 양의 텍스트 데이터를 기반으로 문맥을 이해하고 언어의 패턴을 익힌다. 이 단계는 레이블이 없는 데이터를 사용하는 비지도 학습으로 이루어지기 때문에, 별도의 데이터 레이블링 없이도 대규모 학습이 가능하다. 이렇게 만들어진 범용 모델을 파운데이션 모델이라고 한다.

파인튜닝(Fine-Tuning) 단계에서는 요약, 번역, 질의응답 등 특정 태스크에 적합한 데이터셋으로 추가 학습을 진행한다. -> 특정 업무에 필요한 지식과 답변 방식을 덧붙이게 된다. (파인튜닝 외에도 프롬프트 튜닝, 어댑터 등의 맞춤화 기법이 있다.)

LLM의 한계

LLM은 한 번에 처리할 수 있는 입력의 길이가 정해져 있어서 입력이 너무 길어지면 문맥의 앞부분을 잊어버리거나 처리하지 못하는 경우가 생긴다.

할루시네이션 현상도 인간이 판별해야한다.

프롬프트를 더 잘 입력하기 위한 LLM Deep Dive

토큰과 토크나이저 — LLM이 텍스트를 "보는" 방식
트랜스포머 아키텍처 — LLM의 두뇌 구조
Pre-training에서 RLHF까지 — LLM이 똑똑해지는 과정
컨텍스트 윈도우와 어텐션 그리고 확률의 세계

이 글을 다 읽고 나면, LLM에게 프롬프트를 줄 때 "왜 이렇게 써야 하는지"가 자연스럽게 이해될 것입니다!!!

1. 토큰과 토크나이저: LLM이 텍스트를 보는 방식

LLM은 토큰 단위로 텍스트를 처리
토큰은 통계적으로 자주 함께 등장하는 문자열 조각이다.

1-1. 토크나이저의 작동 원리

토크나이저는 텍스트를 토큰으로 분할하는 알고리즘
대부분의 현대 LLM은 BPE(Byte Pair Encoding) 또는 그 변형을 사용한다.

모든 텍스트는 개별 바이트로 분해되고 가장 자주 연속으로 등장하는 짝을 찾아 하나의 토큰으로 병합한다. 이 과정을 원하는 어휘 크기에 도달할 때까지 반복한다.

대부분의 LLM은 영어 기준으로 학습이 되었기 때문에 한국어보다 영어가 더 효율적이다. 영어로 짜는 프롬프트에 익숙해져야겠다.(오늘부터 영어공부 드간다)

모든 LLM에는 처리 가능한 최대 토큰 수가 있다.
입력 토큰 + 출력 토큰 = 전체 토큰 사용량

참고) 글자 수 세기 같은 작업이 어렵다, JSON보다 CSV가 토큰 효율이 높을 수 있다.

1-2. 트랜스포머 아키텍처: LLM의 두뇌 구조

트랜스포머의 핵심 셀프 어텐션
셀프 어텐션은 각 토큰이 다른 모든 토큰과의 관련도 점수를 계산한다.
셀프 어텐션은 내부적으로 Query, Key, Value로 벡터를 산정한다.
Query (Q): "나는 어떤 정보가 필요한가?" — 현재 토큰의 질문
Key (K): "나는 어떤 정보를 가지고 있는가?" — 각 토큰의 라벨
Value (V): "내가 제공할 실제 정보" — 각 토큰의 실제 내용

1. 각 토큰이 Q, K, V를 생성
2. Q와 모든 K의 유사도를 계산 (= 어텐션 점수)
3. 어텐션 점수로 V를 가중 합산 (= 컨텍스트를 반영한 새로운 표현)

참고) 관련 정보를 가까이 배치, 마크다운, 번호 매기기 등은 모델이 정보의 관계를 파악하는 데 도움을 줍니다.

1-3. LLM의 학습 세단계

Pre-training - 언어를 배운다
Fine-tuning - 대화를 배운다
RLHF / RLAIF - 좋은 답변을 배운다

1-4. 컨텍스트 윈도우와 어텐션 그리고 확률의 세계

컨텍스트 중간에 배치된 정보는 처음이나 끝에 배치된 정보보다 누락될 가능성이 높습니다.

참고) 실전에서의 대응: [프롬프트 구성 권장 순서]

시스템 지시사항 (역할, 규칙) ← 처음: 높은 주목도
참조 데이터, 배경 정보 ← 중간: 상대적으로 낮은 주목도
핵심 질문 또는 작업 지시 ← 끝: 높은 주목도

셀프 어텐션의 계산 복잡도는 O(n²)로 긴 컨텍스트는 느리고 비싸다.

LLM의 본질을 한 마디로 요약하면 주어진 텍스트 다음에 올 토큰의 확률 분포를 예측하는 모델 이다.

입력: "오늘 날씨가 정말"

모델이 예측한 다음 토큰 확률:
  "좋다"    → 35%
  "춥다"    → 20%
  "덥다"    → 15%
  "맑다"    → 12%
  "흐리다"  → 5%
  "나쁘다"  → 3%
  ...       → (나머지 토큰들의 확률 합 = 10%)

여기서 어떤 토큰을 실제로 선택할지를 결정하는 것이 디코딩 전략(Decoding Strategy)입니다.

Temperature(온도)는 확률 분포의 "뾰족함"을 조절합니다.

Temperature = 0 (또는 매우 낮음)

같은 입력에 거의 같은 출력

적합한 용도: 사실 기반 답변, 코드 생성, 분류, 데이터 추출

Temperature = 1.0 (기본값)

원래 학습된 확률 분포를 그대로 사용

적합한 용도: 일반적인 대화

Temperature > 1.0 (높은 값)

창의적이지만 불안정: 예상치 못한 표현이 나올 수 있음

적합한 용도: 창작, 브레인스토밍, 다양한 아이디어 생성

2. 프롬프트 잘 쓰는 방법

명확한 지시

❌ 모호한 프롬프트:

"이 코드를 개선해줘"

✅ 구체적인 프롬프트:

"이 Python 코드의 성능을 개선해줘.

시간 복잡도를 O(n²)에서 O(n log n)으로 줄여줘

원래 함수의 입출력 인터페이스는 유지해줘

변경한 부분에 주석을 달아줘"

역할 부여
당신은 10년 경력의 시니어 백엔드 개발자입니다.
코드 리뷰 시 다음 관점에서 검토합니다:
- 보안 취약점
- 성능 병목
- 에러 핸들링
- 코드 가독성

예시 제공
제약 조건 명시
구분자 활용

3. 대규모 분석 작업을 위한 전략

3-1. 청킹

3-2. Map-Reduce

Map 단계

다음 고객 리뷰 500건을 분석해주세요.

각 리뷰에 대해:
1. 감성 (긍정/부정/중립)
2. 주요 불만/칭찬 카테고리
3. 긴급도 (1~5)

결과를 JSON 배열로 출력해주세요.

Reduce 단계 (Map 결과를 종합)

다음은 고객 리뷰 1만 건을 500건씩 분석한 결과 20개입니다.

이 결과들을 종합하여:
1. 전체 감성 분포
2. 상위 5개 불만 카테고리와 비율
3. 긴급 조치가 필요한 이슈
4. 개선 제안 우선순위

를 작성해주세요.

3-3. 반복 정제

--- 1차 프롬프트 ---
"이 API 문서를 읽고 모든 엔드포인트의 목록을 추출해주세요."

--- 2차 프롬프트 ---
"1차 결과를 검토해주세요. 
 원본 문서와 대조하여 누락된 엔드포인트가 있는지 확인하고,
 각 엔드포인트의 HTTP 메서드와 파라미터 정보를 보완해주세요."

--- 3차 프롬프트 ---
"최종 엔드포인트 목록을 OpenAPI 3.0 YAML 형식으로 변환해주세요.
 각 엔드포인트에 description을 추가해주세요."

3-4. 분할 정복

전체 작업: "이 프로젝트의 보안 취약점을 분석해주세요"

분할:
├── 작업 1: SQL Injection 취약점 스캔
├── 작업 2: XSS 취약점 스캔
├── 작업 3: 인증/인가 로직 검토
├── 작업 4: 의존성 패키지 취약점 확인
└── 작업 5: 환경 변수/시크릿 노출 검토

통합: 각 작업의 결과를 종합하여 우선순위별 보안 보고서 작성

3-5. 일관된 프롬프트 템플릿

ANALYSIS_TEMPLATE = """
### 역할
당신은 {domain} 전문 분석가입니다.

### 작업
아래 데이터를 분석하여 {task_description}을 수행하세요.

### 규칙
- 원본 데이터에 없는 정보를 추론하지 마세요
- 확실하지 않은 항목은 "불확실"로 표시하세요
- 결과는 아래 JSON 스키마를 정확히 따르세요

### 출력 형식
```json
{output_schema}

4. 할루시네이션 대응

4-1. 근거 기반 답변 강제

"아래 문서만을 근거로 질문에 답변해주세요.
 - 문서에 명시된 정보만 사용하세요
 - 문서에 없는 정보는 '문서에 해당 정보가 없습니다'라고 답해주세요
 - 답변할 때 근거가 되는 문서의 해당 부분을 인용해주세요

[문서]
...

[질문]
..."

4-2. 자기 검증

"답변을 작성한 후, 다음을 자체 검증해주세요:
 1. 각 사실적 주장 옆에 [확신도: 상/중/하] 표시
 2. 확신도가 '하'인 항목은 별도 목록으로 분리
 3. 원본 데이터와 대조하여 불일치 항목 표시"

4-3. Temperature 낮추기

Temperature = 0 설정

→ 가장 확률이 높은 토큰만 선택
→ 창의적이지만 부정확한 내용 생성 확률 감소
→ 사실 기반 작업에 필수

4-3. 구조화된 출력 + 필수 필드

{
  "answer": "답변 내용",
  "confidence": 0.85,
  "sources": ["문서 3.2절", "표 4"],
  "caveats": ["매출 데이터는 3분기까지만 반영"],
  "unable_to_determine": ["4분기 예측치는 문서에 없음"]
}

4-4. 최신 정보가 특정 도메인 정보는 직접 제공

[시스템]
아래 검색 결과를 참고하여 질문에 답변하세요.
검색 결과에 없는 내용은 답변하지 마세요.

[검색 결과]
1. [출처: 2024년 3분기 실적 보고서] "..."
2. [출처: 제품 매뉴얼 v3.2] "..."

[질문]
3분기 매출은 얼마인가요?

RAG (검색 증강 생성)

RAG(Retrieval-Augmented Generation)는 LLM에게 질문과 함께 관련 정보를 검색하여 제공함으로써, 더 정확하고 최신의 답변을 생성하게 하는 기법입니다.

[기존 방식]
질문 → LLM (학습된 지식만으로 답변) → 답변
        ⚠️ 학습 이후 정보 부재, 환각 위험

[RAG 방식]
질문 → 검색 엔진 (관련 문서 검색) → 질문 + 검색 결과 → LLM → 답변
        ✅ 최신 정보 활용, 근거 기반 답변

1. 임베딩과 벡터 검색

임베딩이란?
임베딩(Embedding)은 텍스트를 의미를 보존하는 고차원 벡터로 변환하는 것입니다.

"강아지"     → [0.82, -0.15, 0.43, ...]
"puppy"      → [0.80, -0.12, 0.45, ...]  ← 의미가 비슷 → 벡터가 가까움
"자동차"     → [-0.31, 0.67, -0.22, ...]  ← 의미가 다름 → 벡터가 멀음

에이전트

에이전트란?
LLM 에이전트(Agent)는 단순히 텍스트를 생성하는 것을 넘어, 목표를 이해하고, 계획을 세우고, 도구를 사용하여 작업을 수행하는 시스템입니다.

[일반 LLM 사용]
사용자: "서울 날씨 알려줘"
LLM: "제가 실시간 날씨 정보에 접근할 수 없습니다."

[에이전트]
사용자: "서울 날씨 알려줘"
에이전트 사고: "날씨 정보가 필요하다 → weather API를 호출하자"
  → weather_api("서울") 호출
  → 결과: {"temp": 15, "condition": "맑음"}
에이전트: "서울의 현재 날씨는 맑음이며, 기온은 15도입니다."

에이전트의 핵심 구성 요소

LLM (두뇌)
모든 판단과 계획의 중심입니다. 사용자의 요청을 이해하고, 어떤 도구를 어떤 순서로 사용할지 결정합니다.
도구 (Tools / Functions)
에이전트가 외부 세계와 상호작용하는 수단입니다.
메모리 / 상태
에이전트가 작업 진행 상황을 추적하는 메커니즘입니다.

Tool Use 메커니즘

Tool Use (함수 호출) 메커니즘
에이전트의 핵심 기능인 Tool Use는 다음과 같이 작동합니다.

1. 사용자가 질문/요청
    ↓
2. LLM이 사용 가능한 도구 목록에서 적절한 도구 선택
    ↓
3. LLM이 도구 호출에 필요한 파라미터를 JSON으로 생성
    ↓
4. 시스템이 실제로 도구를 실행
    ↓
5. 도구의 실행 결과를 LLM에게 전달
    ↓
6. LLM이 결과를 해석하여 답변 생성 (또는 추가 도구 호출)

주요 에이전트 패턴

패턴 1: ReAct (Reasoning + Acting)
가장 기본적이고 널리 사용되는 패턴입니다.

Thought: 사용자가 서버 에러의 원인을 파악하길 원한다.
         먼저 최근 로그를 확인해야 한다.
Action:  read_log(service="api-server", last="1h")
Observation: [TimeoutError] DB connection pool exhausted at 14:32...

Thought: DB 커넥션 풀이 소진된 것이 원인이다.
         DB의 현재 연결 수를 확인하자.
Action:  query_db("SELECT count(*) FROM pg_stat_activity")
Observation: count: 150 (max_connections: 100)

Thought: 최대 연결 수를 초과했다. 어떤 쿼리가 연결을 점유하고 있는지 확인.
Action:  query_db("SELECT query, state FROM pg_stat_activity WHERE state='active'")
Observation: 대부분 analytics_daily 배치 쿼리가 점유 중...

Thought: 원인을 파악했다. 사용자에게 보고하자.
Answer:  "서버 에러의 원인은 analytics_daily 배치 작업이 DB 연결을 
         과도하게 점유하여 커넥션 풀이 소진된 것입니다. ..."

패턴 2: Plan and Execute
복잡한 작업을 먼저 계획한 후 순차적으로 실행합니다.

[계획 단계]
목표: "프로젝트의 보안 취약점을 분석하고 보고서를 작성하라"

계획:
1. 프로젝트 구조 파악 (read_file)
2. 의존성 패키지 취약점 스캔 (run_command: npm audit)
3. 코드 내 SQL Injection 패턴 검색 (search_code)
4. 코드 내 XSS 패턴 검색 (search_code)
5. 환경 변수/시크릿 노출 검사 (search_code)
6. 결과 종합하여 보고서 작성

[실행 단계]
→ 계획의 각 단계를 순차 실행, 필요시 계획 수정

패턴 3: Multi-Agent
여러 전문 에이전트가 협력하여 작업을 수행합니다.

[오케스트레이터 에이전트]
    ├── [리서치 에이전트] - 정보 수집 전문
    ├── [코딩 에이전트] - 코드 작성 전문
    ├── [리뷰 에이전트] - 코드 검토 전문
    └── [테스트 에이전트] - 테스트 작성 및 실행 전문

에이전트의 현실적 한계

누적 오류
단계가 많아질수록 각 단계의 작은 오류가 누적됩니다.
도구 선택 실수
LLM이 잘못된 도구를 선택하거나, 올바른 도구에 잘못된 파라미터를 전달할 수 있습니다.
무한 루프
에이전트가 같은 행동을 반복하거나, 실패를 인식하지 못하고 계속 시도할 수 있습니다.
비용 폭발
복잡한 작업에서 에이전트가 수십 번의 LLM 호출을 하면 비용이 급격히 증가합니다.

안전한 에이전트 설계 원칙

1. 최소 권한 원칙: 에이전트에게 필요한 최소한의 도구만 제공
2. 인간 확인 단계: 위험한 행동(삭제, 전송 등) 전에 사용자 확인
3. 실행 제한: 최대 반복 횟수, 최대 비용, 타임아웃 설정
4. 로깅: 모든 도구 호출과 결과를 기록하여 디버깅 가능하게
5. 롤백 가능성: 에이전트의 행동을 되돌릴 수 있는 메커니즘 준비

멀티모달 LLM

멀티모달 LLM이란?
멀티모달(Multimodal) LLM은 텍스트뿐 아니라 이미지, 오디오, 비디오, 문서 등 다양한 형태의 입력을 이해하고 처리할 수 있는 모델입니다.

[텍스트 전용 LLM]
입력: 텍스트 → 출력: 텍스트

[멀티모달 LLM]
입력: 텍스트 + 이미지 + PDF + ... → 출력: 텍스트 (+ 이미지)

멀티모달 비용 고려
이미지 입력은 텍스트보다 토큰 소모가 큽니다.

일반적인 이미지 토큰 소모

저해상도 (512×512): ~85 토큰
중해상도 (1024×1024): ~170 토큰
고해상도 (2048×2048): ~680 토큰
매우 큰 이미지: 1,000+ 토큰

실전 팁

이미지 + 구체적 질문을 결합하세요. 맥락 없는 이미지만 보내면 일반적인 설명만 돌아옵니다.
비전은 "대략적 이해"에 강하고 "정밀 측정"에 약합니다. 정확한 수치가 필요하면 텍스트로 제공하세요.
PDF에서 표가 많다면 텍스트 추출 후 전달하는 것이 더 정확할 수 있습니다.
디버깅에 적극 활용하세요. 에러 화면 스크린샷은 텍스트로 옮기는 것보다 정보 손실이 적습니다.
여러 이미지를 한 번에 비교할 수 있습니다. "이 두 디자인의 차이점을 찾아줘" 같은 요청이 가능합니다.

leave_a_comment

나도 성장하고파

이전 포스트

사용자가 체감하는 웹 성능에 대하여

다음 포스트