첫 수업

바이브코딩을 위한 AI 앱 지도

이 수업의 목표는 코드를 외우는 것이 아니다. AI가 무엇을 보고 답하는지, 문서를 어떻게 찾아오는지, 데이터가 어디에 저장되는지 말로 설명할 수 있게 만드는 것이다.

LLM부터 시연 임베딩 그래프 보기

사용자 브라우저 버튼을 누르고 결과를 본다

앱 웹서버 요청을 받아 일의 순서를 정한다

AI LLM API 컨텍스트를 읽고 다음 토큰을 예측한다

기억 DB 데이터를 규칙 있는 장부로 저장한다

도구 RAG · MCP · API 필요한 자료와 외부 기능을 가져온다

개념 지도

초보자가 먼저 잡아야 할 7개 단어

깊게 들어가기 전에 “이 부품은 무슨 역할인가”만 잡는다. 이후 모든 설명은 이 7개 단어 위에 올라간다.

LLM 다음 말을 잇는 엔진

앞의 텍스트를 보고 다음 토큰을 예측한다.

Token 글 조각과 비용 단위

AI가 읽고 쓰는 작은 단위다.

Embedding 의미를 좌표로 바꾸기

문장을 공간 위 위치로 바꾼다.

RAG 자료를 찾아 붙이기

관련 문서 조각을 컨텍스트에 넣는다.

MCP AI용 도구 연결 규격

파일, DB, 검색 도구를 안전하게 연결한다.

API 외부 서비스 창구

LLM, STT, 캘린더, 이메일을 호출한다.

DB 규칙 있는 장부

데이터를 테이블로 나눠 오래 저장한다.

LLM 데모

LLM은 컨텍스트 창을 읽고 다음 토큰을 고른다

LLM은 “생각하는 사람”이라기보다, 지금 창에 들어온 텍스트를 보고 다음에 올 말 조각을 계속 고르는 모델이다. 그래서 좋은 답은 좋은 컨텍스트 관리에서 시작한다.

Context window 약 18% 사용

System prompt

한국어로 쉽게 설명해. 전문 용어에는 비유를 붙여.

User prompt

RAG가 뭔지 초보자에게 설명해줘.

추가 정보

문서 청크, 검색 결과, MCP 도구 결과, 프로젝트 파일 내용.

Assistant answer

RAG는 필요한 자료를 찾아 AI 책상 위에 올려주는 방식입니다.

Next user prompt

그럼 embedding은 RAG에서 어떤 역할이야?

다음 토큰 후보

임베딩 데모

문장의 의미를 3D 공간에 놓고 거리를 비교한다

임베딩은 문장을 숫자 좌표로 바꾸는 일이다. 의미가 비슷한 문장은 가까운 곳에 놓이고, 전혀 다른 주제는 멀리 떨어진다.

RAG 데모

문서를 조각내고, 의미가 가까운 조각을 컨텍스트에 넣는다

RAG는 AI를 다시 학습시키는 일이 아니다. 필요한 문서 조각을 찾아서 답변 직전에 붙여주는 방식이다.

예시 문서회의록 업로드 기능

# 회의록 업로드 기능

## 1. 오디오 업로드
사용자는 회의 녹음 파일을 업로드한다.
앱은 파일 형식과 용량을 먼저 확인한다.
업로드가 끝나면 서버는 처리 대기열에 작업을 넣는다.

## 2. STT 변환
서버는 STT API로 음성을 텍스트로 바꾼다.
긴 회의는 10분 단위로 나눠 변환한다.
변환 결과에는 발화 시간과 화자 후보를 함께 저장한다.

## 3. 저장, 검색, 비용 기록
긴 회의록은 주제별 챕터로 나누어 저장한다.
각 챕터는 임베딩되어 검색용 DB에 들어간다.
모든 STT와 LLM 호출은 사용량 로그에 기록한다.

청킹 방식 선택

청킹 = 긴 문서를 AI가 다루기 좋은 작은 조각으로 자르는 일이다.

길이 기준은 일정한 글자 수로 자르고, 앞뒤 내용을 조금 겹쳐 맥락이 끊기지 않게 한다.

Chunk 1

사용자는 회의 녹음 파일을 업로드한다. 앱은 파일 형식과 용량을 먼저 확인한다. 업로드가 끝나면 서버는 처리 대기열에 작업을 넣는다.

Chunk 2

업로드가 끝나면 서버는 처리 대기열에 작업을 넣는다. 서버는 STT API로 음성을 텍스트로 바꾼다. 긴 회의는 10분 단위로 나눠 변환한다.

Chunk 3

긴 회의는 10분 단위로 나눠 변환한다. 변환 결과에는 발화 시간과 화자 후보를 함께 저장한다. 긴 회의록은 주제별 챕터로 나누어 저장한다.

질문“회의 음성은 어떻게 텍스트가 되나요?”

질문 임베딩

거리 비교

Top-K 선택

컨텍스트 주입

선택된 조각: Chunk 2가 질문과 가장 가깝다. 겹쳐 둔 문장 덕분에 업로드 직후 STT 흐름까지 이어서 읽을 수 있다.

API 데모

API는 다른 서비스에 일을 부탁하는 주문 창구다

앱이 모든 기능을 직접 만들 필요는 없다. 정해진 형식으로 요청을 보내고, 정해진 형식으로 결과를 받으면 된다.

내 앱 회의 파일을 텍스트로 바꿔줘

버튼을 누르면 요청 → 처리 → 응답 흐름이 표시됩니다.

DB 데모

DB 설계는 지저분한 엑셀을 장부로 정리하는 일이다

스키마 = 장부의 칸과 규칙을 정한 설계도다. 좋은 DB는 중복을 줄이고, 관계를 분명히 만든다.

wide form 엑셀한 장에 다 넣은 상태

사번	이름	이메일	법인	부서	직책	매니저	FTE 1월	FTE 2월
26001429	김민수	minsu@example.com	KR01	HR	HR Manager	이서연	1.0	0.8
26001429	김민수	minsu@example.com	KR01	People	People Lead	이서연	1.0	0.8
26001802	박지훈	jihoon@example.com	KR01	Operations	Ops Specialist	김민수	1.0	1.0

문제: 사람 정보, 자리 정보, 월별 FTE가 한 줄에 섞여 있다. 같은 사람이 반복되고, 직책명이 흔들리고, 월별 칸이 계속 늘어난다.

정리 버튼

버튼을 누르면 엑셀 한 장이 사람 장부, 자리 장부, 배정/FTE 장부로 나뉜다.

person

사람 자체의 신원 카드다. 이름과 이메일처럼 사람이 바뀌어도 계속 따라다니는 값을 둔다.

person_id	employee_id	name	work_email	legal_entity
P001	26001429	김민수	minsu@example.com	KR01
P002	26001802	박지훈	jihoon@example.com	KR01

position

자리, 즉 조직 안의 의자 장부다. 사람이 퇴사해도 자리는 남을 수 있다.

position_code	org_code	title	function	manager_position
KR01_HR_L4_001	KR01_HR_1000	HR Manager	HR	KR01_HR_L5_001
KR01_OPS_L2_014	KR01_OPS_1200	Ops Specialist	Operations	KR01_HR_L4_001

assignment_fte_period

누가 어느 자리에 언제 몇 FTE로 앉았는지 적는 연결 장부다.

person_id	position_code	period	actual_fte	source
P001	KR01_HR_L4_001	2026-01	1.0	LOCAL_HR
P001	KR01_HR_L4_001	2026-02	0.8	LOCAL_HR
P002	KR01_OPS_L2_014	2026-02	1.0	GLOBAL_HR

관계 읽는 법

P001 김민수는 KR01_HR_L4_001 자리에 앉아 있고, 2026년 2월에는 0.8 FTE로 기록된다. DB는 한 줄에 다 우겨 넣지 않고, 사람/자리/기간별 배정을 나눠서 연결한다.

실제 프로젝트

내 프로젝트를 사례로 다시 보기

앞에서 배운 LLM, 임베딩, RAG, API, DB가 실제 앱 안에서 어떻게 이어지는지 프로젝트별 상세 페이지로 본다.

뉴스 공장 NewsHub

뉴스를 수집하고, 의미가 가까운 기사끼리 묶고, LLM으로 검수한 뒤 뉴스레터와 화면으로 내보내는 파이프라인이다.

Crawling → Embedding → Clustering → Newsletter → Delivery

EmbeddingLLM 검수비용 로그

상세 사례 보기

보고서 제작 라인 Report Studio

사용자 대화, RAG 예시, 역할별 Agent, 표 생성, DOCX 렌더링이 이어지는 AI 문서 제작 시스템이다.

Chat → Prompt Builder → Agents → Normalizer → Renderer

RAG 예시Prompt 조립DOCX

상세 사례 보기

인사 데이터 검수실 HRIS

엑셀식 HR 데이터를 사람, 자리, 조직 장부로 나누고 AI가 검수 초안을 만들되 원장은 승인 후에만 바꾸는 구조다.

Upload → Validate → AI Draft → Approval → Audit

DB SchemaAI 안전장치Audit

상세 사례 보기

개인 지식창고 Second Brain

노트, 회의록, 채팅 기록, 메모리를 검색해 AI 채팅의 컨텍스트로 붙이는 개인 지식 시스템이다.

Ingest → Chunk → Retrieve → Chat → Memory

Semantic SearchSTTMemory

상세 사례 보기

상세 페이지에서 볼 것

각 페이지는 스크린샷 또는 안전한 화면 재현, 실제 프롬프트 구조, API 호출 예시, 결과값 예시, DB 장부, 컨텍스트가 쌓이는 순서를 같은 형식으로 보여준다.

뉴스 공장

NewsHub

뉴스를 모으고, 비슷한 기사끼리 묶고, LLM으로 검수한 뒤 뉴스레터와 프론트 화면으로 내보내는 파이프라인이다.

1Crawling

Naver, Google RSS, Baidu, Global RSS에서 기사를 가져온다.

2Embedding

본문을 의미 좌표로 바꿔 비슷한 기사끼리 찾을 준비를 한다.

3Clustering

HDBSCAN으로 기사 묶음을 만들고 Gemini가 주제 타당성을 검수한다.

4Newsletter

Top Story, Headlines, Insights, Glossary를 단계별로 만든다.

5Delivery

Next.js 화면, 관리자, 이메일, Telegram 운영 흐름으로 결과가 나간다.

Frontend

Next.js 14 프론트가 Vercel에 배포된다. 페이지는 처음 데이터를 서버에서 받아오고, 이후 검색/필터는 ClientContent 컴포넌트가 처리한다. ISR은 “잠깐 저장했다가 자동 갱신하는 화면 캐시”다.

Backend

FastAPI 백엔드와 cron 작업이 중심이다. `cron_helper.py`가 수집, 클러스터링, 요약, 뉴스레터 생성 같은 작업 이름을 받아 각 모듈로 보낸다.

DB Setup

PostgreSQL에 `news_articles`, `news_topics`, `email_*`, `newsletter_research_log`, `llm_usage_logs` 같은 장부가 있다. 기사 embedding은 pgvector처럼 “의미 좌표를 저장하는 칸”에 들어간다.

RAG / Semantic Search

채팅형 RAG라기보다 뉴스 기사 검색형 RAG에 가깝다. 기사와 토픽 embedding을 비교해 가까운 기사 묶음을 만들고, 최근 토픽과 중복되는지 검사한다.

APIs

Naver API, RSS, Baidu, OpenAI embedding, Gemini 검수/글쓰기, SearXNG/웹 fetch, 이메일 발송, Telegram bot이 붙는다. 유료 AI 호출은 비용 장부에 남긴다.

LLM / Prompt

Gemini 클러스터링 프롬프트는 “타깃 회사가 주인공인가, 주식/투자 잡음은 아닌가, 같은 그룹 계열사 뉴스는 아닌가”를 본다. 뉴스레터 프롬프트는 fact extraction → top story → headlines → insights → glossary 순서로 이어진다.

Context가 쌓이는 방식

기사 제목, 본문, 출처, 회사명, 기존 토픽이 기본 재료로 들어간다.
임베딩과 HDBSCAN이 먼저 후보 묶음을 줄인다. 이 단계는 LLM 비용을 줄이는 체다.
Gemini는 후보 기사 묶음과 회사별 규칙을 읽고 keep/reject/topic title을 판단한다.
뉴스레터 단계에서는 Stage 1 fact가 Stage 2/3/4의 근거가 되고, 각 cite는 원문 기사 인덱스와 연결된다.

보고서 제작 라인

Report Studio

사용자와 대화하면서 보고서 방향을 잡고, 예시/RAG/프리셋을 붙인 뒤 DOCX까지 뽑아내는 AI 문서 제작 시스템이다.

1Chat

사용자 요청과 현재 보고서 상태를 받는다.

2Prompt Builder

규칙, RAG 예시, preset, budget, runtime을 한 컨텍스트로 조립한다.

3Agents

OutlineAgent, FullDraftAgent, PatchAgent, TableAgent가 역할별로 처리한다.

4Normalizer

LLM 결과 JSON을 렌더러가 먹기 좋은 모양으로 정리한다.

5Renderer

DOCX를 만들고 미리보기 PDF/PNG를 만든다.

Frontend

Next.js 워크스페이스가 채팅, 옵션 카드, 보고서 미리보기, TablePanel, Table Library를 보여준다. 프론트는 “사용자가 보고 만지는 조종석”이다.

Backend

Python 백엔드가 chat route, prompt builder, LLM runtime, table library, render worker를 가진다. 렌더링은 LLM이 아니라 결정론 코드가 맡는다.

DB Setup

PostgreSQL dev/prod가 분리되어 있다. 세션, 보고서 JSON, RAG 예시 chunk pool, Table Library, 사용량 로그, chat LLM call 원문 로그가 DB에 남는다.

RAG

RAG는 보고서 예시를 찾아 붙이는 장치다. 후보는 `common`, preset, family/tag, slot 중 하나라도 맞아야 통과한다. 즉 예시마다 출입증을 검사한다.

APIs

LLM runtime은 사용자/서버 설정에 따라 Claude CLI/API 또는 Gemini API로 갈 수 있다. Office 미리보기는 OnlyOffice 또는 선택적 Microsoft Graph 쪽으로 분리된다.

LLM / Prompt

주요 프롬프트는 `outline_flow_v2`, `draft_flow_v2`, `patch_flow_v2`, `table_flow_draft_build`다. 역할 프롬프트와 마지막 instruction이 함께 붙어 “기획자/작가/편집자/표 담당자” 역할을 만든다.

Context 조립 순서

static invariant와 role gate가 먼저 들어간다. role gate는 “너는 지금 어떤 작업자인가”를 정하는 출입문이다.
RAG examples가 들어간다. 보고서 종류와 slot이 맞는 예시만 가져온다.
preset pack, budget YAML, preset runtime이 붙는다. budget은 분량 숫자표다.
현재 outlines 또는 current report가 붙는다. 다음 질문에서도 이 상태가 이어진다.
final instruction이 마지막에 들어가 JSON schema와 출력 규칙을 잠근다.

인사 데이터 검수실

HRIS

실제 HRIS로 넘기기 전, 사람/계약/자리/조직/FTE 데이터를 검수하고 승인 흐름을 만드는 임시 운영 도구다.

1Upload

로컬 HR 파일, worker assignment, FTE 파일을 받는다.

2Validate

법인 scope, 필수값, FK, 삭제 금지 같은 규칙을 검사한다.

3AI Draft

AI는 mapping 후보와 질문을 만들고, 원장을 직접 수정하지 않는다.

4Approve

HR_ADMIN 승인 뒤에만 기준표와 발령 요청이 반영된다.

5Analytics

정리된 schema로 조직도, FTE, 품질, 비용 관제 화면을 만든다.

Frontend

Next.js 16 앱이다. `/dashboard`, `/people`, `/organization`, `/admin/data-roundtrip`, `/schema-guidebook` 같은 화면이 있고, schema guidebook은 room/seat/person 비유로 설명한다.

Backend

Next route, server action, core service가 얇은 controller 구조로 움직인다. controller는 접수 창구, core/features는 실제 업무 담당자라고 보면 된다.

DB Setup

PostgreSQL 16과 Drizzle schema/migration을 쓴다. 핵심은 `person → employment → assignment`, `managing_org → position`, `position_reporting_line`, `assignment_fte_period`, `audit_log`다.

RAG / AI Context

전형적인 문서 RAG보다 “safe context”에 가깝다. AI에게 허용 scope, schema 설명, 업로드 파일 profile, sample rows, 검수 규칙을 넣고 structured mapping plan을 받는다.

APIs

Data Intake는 Codex CLI를 subprocess로 호출한다. AI Query, closing, standardize 계열은 Gemini flash-lite 기반으로 시작한다. 이메일 초대는 SMTP를 쓴다.

System Prompt

핵심 규칙은 “AI는 원장을 직접 고치지 않는다”다. 민감 필드, 법인 scope, 누락 질문, HRIS 업로드 draft를 구조화해서 내고, 모든 성공 호출은 `llm_usage_log`와 audit에 남긴다.

Context가 쌓이는 방식

로그인 사용자 역할과 접근 가능한 legal entity scope가 먼저 들어간다.
DB schema와 room/seat/person 규칙이 들어간다. 방은 조직, 의자는 position, 사람은 worker다.
업로드 파일 profile과 sample rows가 들어간다. AI는 이걸 보고 mapping 후보를 만든다.
결과는 바로 원장 반영이 아니라 review/apply 초안으로 저장된다.
승인, rollback, 변경 요청, audit log가 뒤에 붙어 운영 추적이 가능해진다.

개인 지식창고

Second Brain

Obsidian 노트, 회의록, 채팅 기록, 플래너, 메모리를 검색하고 AI 채팅 컨텍스트로 연결하는 개인 지식 시스템이다.

1Ingest

Obsidian vault, 회의 오디오, 채팅 기록, 플래너 데이터를 모은다.

2Chunk / Embed

노트와 회의록을 조각내고 embedding으로 검색 가능하게 만든다.

3Retrieve

검색, meeting chunks, memory, planner, finance context를 모은다.

4Chat

Claude/Codex/Gemini provider가 준비된 context로 답한다.

5Memory

중요한 대화는 working/core memory로 승격된다.

Frontend

Next.js 웹앱에 `/chat`, `/meetings`, `/search`, `/memory`, `/planning` 화면이 있다. 사용자는 지식창고를 검색하고, 회의록을 열고, 채팅에 자료를 붙인다.

Backend

FastAPI 백엔드와 별도 host-run `claude-chat` 서버가 있다. Caddy가 일반 API와 `/api/claude-chat*` 요청을 나눠 보낸다.

DB Setup

PostgreSQL init SQL에 notes/search/chat/meetings/memory/usage 장부가 있다. Neo4j는 그래프 관계를 담고, `meeting_chunks`는 회의록 검색용 조각이다.

RAG

노트 검색, chat history 검색, meeting chunk 검색, selected meetings 전체 주입이 함께 있다. RRF는 여러 검색 결과 순위를 섞는 방식이다.

APIs

OpenAI embedding, Claude/Codex/Gemini CLI, Gemini API, Deepgram/Soniox/Mistral/ElevenLabs STT, SearXNG, Google Calendar가 기능별로 붙는다. provider별 사용량 로그가 나뉜다.

Prompt / LLM

회의 분석 prompt, deep research prompt, memory promotion prompt, selected meetings system reminder, multi-agent draft 루프가 있다. prompt는 “어떤 자료를 근거로 답할지”를 묶어주는 작업지시서다.

Context가 쌓이는 방식

사용자 메시지와 provider-neutral history가 들어간다. provider-neutral history는 Claude/Codex/Gemini가 공통으로 읽을 수 있는 대화 장부다.
pre-orchestrator가 meetings, planning, finance, memory 같은 source를 읽어 관련 context를 준비한다.
선택한 meeting이 있으면 전체 transcript가 ``처럼 명시적으로 주입된다.
memory packet은 core와 working tier를 표시한다. core는 오래가는 사실, working은 현재 작업 맥락이다.
답변 뒤에는 chat history와 usage log가 DB에 남고, 필요하면 conversation memory로 승격된다.