ASW Seminar · 2026.04.29

AI 프로젝트를 함께 만들기 위한 공통 언어

백엔드/풀스택 개발자와 AI 개발자가 1년 동안 같은 기준으로 소통하기 위한 세미나

오늘의 목표

• AI를 깊게 전공하는 것이 오늘의 목표는 아닙니다.
• AI 기능이 제품 안에서 어떻게 동작하고, 어떤 제약을 갖는지 이해하는 것이 목표입니다.
• 앞으로 협업할 때 모델, 학습, 추론, LLM, GPU 같은 단어를 같은 의미로 쓰기 위한 시간입니다.

오늘 다룰 네 가지

1. Model

모델은 함수다

• 모델은 입력을 받아 숫자를 계산하고, 결과를 내는 함수입니다.
• 가장 단순한 모델은 중학교 때 본 1차 함수처럼 볼 수 있습니다.
• 예: 방 개수 x = 3, 가중치 w = 1.2, 편향 b = 0.5라면 예측값은 4.1입니다.

모델은 데이터를 잘 설명하는 선을 찾는다

참고 이미지: 방의 개수 x로 집값 y를 예측하는 선형 모델

• 파란 점은 실제 데이터입니다.
• 빨간 선은 모델이 찾은 예측 함수입니다.
• 잔차는 실제값과 예측값의 차이입니다. 예: 실제 집값 5.0, 예측값 4.1이면 오차는 0.9입니다.

이미지와 오디오도 결국 숫자다

모델 안의 파라미터도 숫자다

• 모델 내부에는 수많은 파라미터가 있습니다.
• 파라미터는 모델이 학습하면서 조정하는 숫자입니다.
• 예: 기침 감지 모델이 아래처럼 계산한다고 생각할 수 있습니다.

• 여기서 0.8, 1.4, -0.3, 0.1이 파라미터입니다.
• 입력도 숫자, 파라미터도 숫자, 출력도 숫자입니다.

AI는 출력 숫자를 해석하는 과정까지 포함한다

• 모델 출력이 [0.08, 0.92]라면 “기침 아님 8%, 기침 92%”로 해석할 수 있습니다.
• 출력이 [0.71, 0.21, 0.08]이면 세 클래스 중 첫 번째 클래스가 가장 유력합니다.
• LLM도 다음 토큰 후보마다 숫자 점수를 계산합니다. 예: 점심 0.42, 회의 0.31, 산책 0.05

2. Training vs Inference

학습과 추론은 완전히 다르다

학습 데이터에는 라벨이 필요하다

학습은 오차를 줄이는 방향으로 숫자를 바꾸는 일

• 현재 모델이 clip_001을 보고 기침 확률 0.62를 냈다고 가정합니다.
• 라벨은 기침 = 1이므로 모델은 확률을 더 높이는 방향으로 파라미터를 조정합니다.
• 반대로 clip_002에서 기침 확률 0.71을 냈는데 라벨이 0이면, 그 확률을 낮추도록 조정합니다.

추론은 학습된 숫자로 새 입력을 계산하는 일

• 사용자가 새 오디오를 업로드합니다.
• 오디오가 숫자 특징으로 바뀝니다. 예: [0.79, 0.81, 0.22]
• 학습된 파라미터로 계산합니다.
• 출력 숫자를 해석합니다. 예: 기침 확률 0.91

3. LLM

LLM은 다음 토큰을 예측한다

• LLM은 문장을 한 번에 이해해서 답하는 것이 아니라, 토큰 단위로 다음 토큰을 예측합니다.
• 토큰도 내부적으로는 숫자 ID와 벡터로 바뀝니다.
• 모델은 전체 vocabulary 안의 모든 후보 토큰에 점수를 매기고, 확률이 높은 토큰을 고르거나 샘플링합니다.
• 예: Qwen3-Omni의 text config 기준 vocabulary size는 152,064입니다.

Tokenizer와 Vocabulary

• Tokenizer는 문장을 모델이 계산할 수 있는 토큰 ID로 바꿉니다.
• Vocabulary는 모델이 알고 있는 토큰 후보 목록입니다.
• 다음 토큰 예측은 결국 “vocab 안의 후보 152,064개 중 어느 토큰이 다음에 올 확률이 가장 높은가?”를 계산하는 일입니다.

예시 설정: Qwen3-Omni tokenizer_config.json

실제 tokenizer config를 보면

LLM의 답변 생성 흐름

• 이 구조 때문에 LLM은 그럴듯하지만 틀린 답을 만들 수 있습니다.
• 최신 정보나 우리 서비스 DB는 모델이 자동으로 알고 있지 않습니다.

4. GPU

왜 GPU가 필요한가?

• AI 모델은 입력 숫자와 파라미터 숫자를 엄청나게 많이 곱하고 더합니다.
• CPU는 복잡한 일을 순서대로 잘 처리하고, GPU는 단순한 계산을 많이 동시에 처리합니다.
• 학습은 같은 종류의 숫자 계산을 수없이 반복하므로 GPU가 유리합니다.

순서가 있는 계산은 동시에 하기 어렵다

• 아래 계산은 앞 결과가 나와야 다음 계산을 할 수 있습니다.
• 그래서 단계가 서로 의존적이면 병렬 처리 효과가 제한됩니다.

독립적인 계산은 동시에 하면 빠르다

• 아래 계산들은 서로 기다릴 필요가 없습니다.
• GPU는 이런 계산을 수천 개씩 동시에 처리하는 데 강합니다.

CPU와 GPU의 차이

VRAM은 숫자를 올려두는 작업대다

• GPU가 계산하려면 모델 파라미터와 입력 데이터를 VRAM에 올려야 합니다.
• 예: 70억 개 파라미터 모델을 FP16으로 올리면 가중치만 대략 14GB가 필요합니다.
• 실제로는 중간 계산값, 배치 데이터, optimizer 상태까지 필요해 더 많은 VRAM이 필요합니다.
• VRAM이 클수록 더 큰 모델, 더 긴 입력, 더 큰 batch를 다룰 수 있습니다.

Q&A

• 우리가 준비한 데이터를 GPT 같은 유명한 모델에게 학습시킬 수 있는가?
• LLM은 거대한 텍스트를 어떤 방식으로 학습하는가?
• LLM은 RAG를 어떤 메커니즘으로 활용하는가?
• AI Agent는 챗봇과 무엇이 다르고, 검색/파일 읽기는 어떻게 하는가?
• 프로젝트에 AI를 붙일 때 무엇부터 정하고, 모델은 어떻게 고르는가?

Q1. 우리 데이터로 GPT를 학습시킬 수 있나?

• 가능합니다. 다만 보통 GPT 모델 파일을 우리 컴퓨터로 가져오는 방식은 아닙니다.
• OpenAI 같은 API 제공자는 학습 데이터를 업로드하고 fine-tuning job을 생성하면, provider 인프라에서 모델을 추가 학습합니다.
• 데이터는 보통 JSONL 형태입니다. 예: 입력 “증상 요약해줘”, 정답 출력 “기침 3회, 새벽 2시 집중”
• 학습 데이터도 토큰화되어 처리되며, fine-tuning에서는 학습에 처리된 토큰 수가 비용과 기록에 반영됩니다.

참고: OpenAI Supervised Fine-tuning / Fine-tuning API docs

Q1-2. 오픈소스 모델이면 어떻게 다른가?

Q2. LLM은 거대한 텍스트를 어떻게 학습하나?

• LLM은 텍스트를 DB처럼 저장해두고 검색하는 방식으로 학습하지 않습니다.
• 문장을 토큰으로 나누고, 일부를 가린 뒤 다음 토큰을 맞히는 문제를 엄청나게 많이 풉니다.
• 예: “강아지가 밤에 ___ 했다”에서 다음 토큰 후보의 확률을 계산합니다.
• 정답이 “기침”이면 그 방향으로 수십억~수조 개 파라미터 숫자가 조금씩 조정됩니다.

Q2-2. 그러면 지식은 어디에 저장되나?

• 정확히는 문장 원문이 그대로 저장되는 것이 아니라, 학습 과정에서 파라미터 숫자에 패턴이 압축됩니다.
• 예: “Paris is the capital of France” 같은 패턴을 많이 보면 관련 토큰들이 가까운 의미 구조를 갖게 됩니다.
• 그래서 LLM은 기억을 검색하는 느낌으로 답하지만, 실제로는 파라미터 계산으로 다음 토큰을 생성합니다.
• 이 때문에 모르는 것도 그럴듯하게 만들 수 있고, 최신/사내 데이터는 별도로 넣어줘야 합니다.

Q3. RAG는 어떤 메커니즘으로 작동하나?

• RAG는 보통 LLM 혼자 알아서 DB에 접근하는 기능이 아니라, 애플리케이션이 검색 결과를 LLM에게 넣어주는 구조입니다.
• 사용자 질문을 숫자 벡터로 바꾸고, 문서 조각도 숫자 벡터로 바꿔둡니다.
• 질문 벡터와 가까운 문서 조각을 vector DB에서 찾습니다.
• 찾은 내용을 프롬프트에 붙여 LLM에게 답변을 생성하게 합니다.

Q3-2. LLM이 RAG에 접근할지 어떻게 결정하나?

• 가장 단순한 방식은 항상 검색 후 답변입니다. 질문이 오면 무조건 vector DB를 검색합니다.
• 조금 더 발전한 방식은 백엔드가 질문 유형을 보고 검색 여부를 결정합니다.
• Agent/tool calling 구조에서는 LLM이 “검색 도구를 호출해야겠다”고 판단해 백엔드 tool을 호출할 수 있습니다.
• 어떤 방식이든 핵심은 같습니다. LLM이 우리 DB를 원래 알고 있는 것이 아니라, 시스템이 검색 결과를 문맥으로 넣어주는 것입니다.

참고: OpenAI Retrieval / Vector Store docs

Q4. ChatGPT는 정말 이해하는 걸까?

• 사람처럼 경험하고 의미를 느끼는 방식의 이해는 아닙니다.
• 입력 문장을 토큰 숫자로 바꾸고, 문맥상 다음에 올 확률이 높은 토큰을 계속 고릅니다.
• 다만 학습량이 매우 크기 때문에 “질문 의도 파악, 요약, 추론, 코드 작성”처럼 이해처럼 보이는 행동이 나타납니다.
• 예: “어젯밤 강아지가 기침을 5번 했어”를 보면 반려동물, 증상, 시간, 횟수 패턴을 계산해 다음 답변을 구성합니다.

Q5. Hallucination은 왜 생기나?

• LLM의 기본 목표는 “정답 DB 검색”이 아니라 그럴듯한 다음 토큰 생성입니다.
• 질문에 필요한 근거가 없거나, 질문이 애매하거나, 학습 데이터에 오류가 섞여 있으면 틀린 문장도 자연스럽게 이어갈 수 있습니다.
• 예: 없는 논문 제목을 물어보면, 실제 논문 제목 패턴을 따라 그럴듯한 제목과 저자를 만들어낼 수 있습니다.
• 그래서 중요한 답변에는 RAG, 출처, 검증 로직, 사람 검토가 필요합니다.

Q5-2. 왜 좋은 모델은 모른다고 더 잘 말하나?

• 성능이 좋은 모델은 단순히 말만 잘하는 게 아니라, 지시문 따르기와 불확실성 표현도 더 많이 학습합니다.
• Instruction tuning, RLHF, safety tuning 과정에서 “근거가 부족하면 추측하지 말라”는 피드백을 받습니다.
• 예: “이 파일에 없는 값을 말해줘”라는 요청에 좋은 모델은 파일 근거가 없다고 답할 가능성이 높습니다.
• 그래도 완벽하지 않으므로 서비스에서는 “출처 없음”, “확신 낮음”, “검토 필요” 같은 fallback UI가 필요합니다.

Q6. Agent는 챗봇과 뭐가 다른가?

Q7. Agent가 검색하는 방식: Built-in Tool

• OpenAI Responses API처럼 provider가 제공하는 built-in tool을 켜면, 모델이 필요할 때 web_search를 호출할 수 있습니다.
• 중요한 점: 모델이 “브라우저를 직접 조작”하는 게 아니라, API 런타임이 검색 tool을 실행하고 결과를 다시 모델에게 줍니다.

curl "https://api.openai.com/v1/responses" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -d '{
    "model": "gpt-5",
    "tools": [{ "type": "web_search" }],
    "tool_choice": "auto",
    "input": "2026년 기준 반려동물 헬스케어 시장 사례를 검색해서 요약해줘"
  }'

참고: OpenAI Responses API Web Search tool

Q7-2. Agent가 파일을 읽는 방식: Custom Tool

• 파일 읽기는 보통 백엔드가 read_file(path) 같은 함수를 tool로 등록하는 방식입니다.
• 모델은 “이 tool을 이런 인자로 호출해줘”라는 구조화된 요청을 만들고, 실제 파일 접근은 우리 코드가 수행합니다.

pip install langchain langchain-openai

cat > agent_demo.py <<'PY'
from langchain.tools import tool
from langchain.agents import create_agent

@tool
def read_file(path: str) -> str:
    """Read a local text file."""
    with open(path, "r", encoding="utf-8") as f:
        return f.read()

@tool
def search_web(query: str) -> str:
    """Search the web. Replace with Tavily, SerpAPI, or provider web_search."""
    return f"검색 API 결과: {query}"

agent = create_agent(model="gpt-4o-mini", tools=[read_file, search_web])
result = agent.invoke({
    "messages": [{"role": "user", "content": "meeting-note.md 읽고 다음 액션 아이템 찾아줘"}]
})
print(result)
PY

python agent_demo.py

Q7-3. Framework로 만들면?

• OpenAI Responses API: web_search, file_search, function calling 같은 tool을 직접 연결
• LangChain / LangGraph: agent loop, tool 호출, 상태 관리, retry, tracing 구성에 유리
• LlamaIndex: 문서/RAG 중심 앱에서 index, retriever, agent 도구화에 유리
• AutoGen / CrewAI: 여러 agent 역할을 나누는 실험에 자주 사용

# Framework 선택 예시
# 문서 검색/RAG 중심: LlamaIndex
# 일반 tool-calling agent: LangChain/LangGraph
# OpenAI hosted tools: Responses API web_search, file_search
# 여러 역할 agent 실험: AutoGen, CrewAI

참고: LangChain Agents/Tools docs, LlamaIndex Agents docs

Q8. AI를 붙일 때 제일 먼저 정할 것

• 첫 번째는 모델 선택이 아닙니다. 문제, 입력, 출력, 성공 기준부터 정해야 합니다.
• 예: “반려동물 야간 녹음에서 기침 후보 구간을 찾아 수의사 리포트로 요약한다.”
• 입력: 8시간 오디오 / 출력: 이벤트 타임라인 JSON / 성공 기준: 수의사가 유용하다고 판단한 비율
• 그 다음에 rule-based, 기존 API, RAG, fine-tuning, 직접 모델 운영 중 무엇이 맞는지 고릅니다.

Q9. Hugging Face 모델을 가져다 쓴다는 것

• 모델 카드에서 task, license, 입력 형식, 필요 VRAM, 예제 코드를 확인합니다.
• 코드에서는 tokenizer와 model weights를 다운로드해 로컬/서버 GPU 메모리에 올립니다.
• “그냥 코드에 붙인다”기보다, 모델 로딩, 전처리, 추론, 후처리, 서버화 과정이 필요합니다.

pip install transformers accelerate torch

python - <<'EOF'
from transformers import AutoTokenizer, AutoModelForCausalLM

model_id = "Qwen/Qwen2.5-0.5B-Instruct"  # 예시는 작은 모델
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto",
    torch_dtype="auto"
)
EOF

Q10. 모델 선택 기준

Q10-2. ChatGPT API vs 직접 모델 운영