Day 14.5. RAG 입문 — 용어와 개념 한 바퀴

지난 시간 마지막 ARIA 의 발화로 다시 돌아가 볼게요.

"음... 제 기억엔 한정된 컨텍스트만 있어서, 어제의 대화 전체를 짚어드리긴 어려워요."

이 한 줄에 LLM 운영의 두 가지 본질적 한계가 다 들어 있어요.

첫째 — 컨텍스트 윈도우 가 한정되어 있어요. 2026 년 최신 모델이 1M 토큰까지 받아준다고 해도, 매 호출마다 그만큼 토큰을 흘려보내는 건 비용·속도가 폭발해요.

둘째 — LLM 가중치 안에 외부 지식이 없어요. 모델은 학습 시점까지의 공개 데이터로 만들어진 거예요.

내가 어제 적은 일기, 우리 게임의 세계관 설정집, 캐릭터별 프로필 — 이런 자료는 모델이 본 적이 없으니 답할 수 없습니다.

바리스타와 손님 메모 — 외부 지식 주입의 비유

비유 하나 던져볼게요. 동네 단골 카페의 바리스타를 떠올려 보세요.

바리스타는 커피 만드는 법, 원두의 차이, 추출 방식 — 이런 일반 지식은 머릿속에 다 있어요. 학습된 지식이죠.

그런데 제가 가게에 들어와 "지난번에 마셨던 그 시즌 라떼 다시 한 잔 주세요" 라고 하면? 바리스타가 매일 모든 손님의 주문 이력을 머리에 담아둘 수는 없어요.

그래서 가게에 손님 메모 한 권을 둡니다. 제가 들어오면 그 페이지를 펼쳐 보고 "아, 지난주에 호두 라떼 드셨네" 를 확인한 다음 답해요.

이게 RAG 의 본질이에요.

• 바리스타의 머릿속 지식 = LLM 가중치 — 일반 지식, 추출 방식, 어휘
• 손님 메모 = 외부 지식 베이스 (KB, Knowledge Base) — 사용자별 일기, 세계관 설정집, 과거 대화
• 메모를 펼쳐 보는 동작 = Retrieval (검색)
• 펼친 페이지를 보며 답하는 동작 = Augmented Generation (증강 생성)

머릿속에만 든 지식 vs 책장 위 사전 — 두 자원을 같이 쓰는 방식이에요.

한쪽은 빠르고 풍부하지만 갱신이 어렵고, 다른 쪽은 갱신이 자유롭지만 매번 펼쳐 봐야 해요. RAG 는 그 둘을 한 흐름으로 잇는 모습입니다.

"그냥 LLM 에 KB 를 통째로 박으면 안 되나요?" — 비용·속도·갱신 3 축

자, 여기서 학생들이 자주 던지는 질문이 있어요.

세 축 비교 표 — 통째 vs RAG

세 축을 한 표로 정리해 둘게요.

왼쪽은 거대한 KB 박스가 통째로 LLM 의 입력 슬롯에 욱여넣어지는 모습(붉은 경고 아이콘), 오른쪽은 KB 박스에서 작은 청크 3 개만 화살표로 빠져나와 LLM 에 들어가는 모습(녹색 체크).

실무 사례 — RAG 가 들어간 운영 현장들

본 강의의 ai-friends 외에 2026 년 운영 현장에서 RAG 가 쓰이는 곳들을 짧게 짚어 볼게요.

• 사내 위키 챗봇 — "우리 회사 휴가 정책이 어떻게 되나요?" 에 답하는 부분. 사내 위키 (Notion · Confluence) 가 KB 가 되고, 직원의 질문이 임베딩되어 위키 청크 Top-K 가 LLM 컨텍스트로 흘러요.
• 법률 어시스턴트 — "이 계약서의 N 조 조항이 한국 상법 X 조와 어떻게 다른가?" 같은 질문. 한국 상법 전문 + 판례 데이터베이스가 KB 가 돼요.
• 고객 지원 챗봇 — "제품 반품 절차가 어떻게 되나요?" 같은 질문. FAQ + 도움말 페이지 + 과거 상담 이력이 KB.
• 개발자 도구의 AI 어시스턴트 — "이 함수의 시그니처가 우리 코드베이스 어디서 정의됐나?" 같은 질문. 코드베이스 자체가 KB 가 돼서 코드 청크 Top-K 가 흘러요.

공통점이 보이시죠? 모두 LLM 가중치 안에 없는 도메인 지식을 외부에서 끌어오는 흐름이에요. 우리 ai-friends 의 마스터 일기 · 캐릭터 세계관도 같은 흐름입니다.

KB (Knowledge Base) 란 무엇인가

용어 하나 더 익혀둘게요. RAG 가 검색해 오는 외부 저장소 를 KB (Knowledge Base, 지식 베이스) 라고 불러요.

ai-friends 의 KB 는 이런 자료들로 채워질 거예요.

• 세계관 설정집 — "이 게임의 시간 배경은 2027 년, 도시는 서울이며..."
• 캐릭터 프로필 — "ARIA 는 28 살 데이터 분석가, MBTI INTJ, 차분하고 분석적..."
• 과거 대화 요약 — "지난 주 마스터와 ARIA 가 카페에서 만난 장면에서..."
• 마스터의 일기 — "오늘 ARIA 에게 좋아한다는 말을 들었다..."

이런 자료들이 마크다운 파일 한 묶음으로 classpath:character-knowledge/ 에 들어가요. Day 15 에서 그 디렉토리가 어떻게 청크로 잘려 pgvector 에 저장되는지 손으로 돌려봅니다.

💡 튜터의 결론

RAG 는 "LLM 의 모자란 지식을 외부 사전으로 보강하는 흐름" 이에요. 비용·속도·갱신성 3 축을 한 번에 풀어서 2026 년 LLM 운영의 표준이 됐어요.

다음 Step 에서 그 사전을 어떻게 만드는지 — 임베딩으로 들어갑니다.

RAG 의 첫 번째 핵심 부품은 임베딩 (embedding) 이에요. 발음 그대로 임-베-딩. 영어로는 embedding — 무언가를 다른 공간에 끼워 넣는다는 뜻입니다.

뭘 어디에? 문장을 의미 공간 (semantic space) 에 끼워 넣어요.

첫 비유 — 지도 위 도시들

임베딩을 처음 만날 때 가장 쉬운 비유가 지도예요.

왼쪽 평면에 한국 지도를 띄우고 서울·인천·부산·제주가 점으로 표시된 모습. 옆에는 같은 평면에 "ARIA는 차분하다"·"ARIA는 침착하다"·"HARU는 활발하다" 가 점으로 표시된 모습 — 의미가 비슷한 두 문장은 가까이, 다른 문장은 멀리.

지도 위에서 두 도시의 물리적 거리가 가까우면 우리가 "가깝다" 고 부르죠. 임베딩 공간에서도 같아요. 단, 거리의 기준이 물리적 위치가 아니라 의미 입니다.

• "ARIA 는 차분하다" → 평면 위 한 점 (예: 좌표 (0.34, -0.18))
• "ARIA 는 침착한 성격이다" → 거의 같은 곳 (예: (0.33, -0.17))
• "HARU 는 활발하다" → 멀리 떨어진 지점 (예: (0.71, 0.42))

두 점 사이 거리를 계산하면 의미가 얼마나 비슷한가가 숫자로 나와요.

키워드 일치 (ARIA 가 들어가나? 차분 이 들어가나?) 가 아니라 의미의 가까움 으로 비교하는 게 임베딩의 본질이에요.

그런데 진짜 차원은 768 — 평면이 아니에요

지도 비유에선 2D 평면을 썼지만, 실제 임베딩 모델이 만드는 벡터는 768 차원 또는 1024, 1536 차원입니다.

"768 차원? 그게 뭐예요?" — 학생들이 가장 자주 멈칫하는 곳이에요.

쉽게 말하면 — 한 문장을 표현하기 위해 숫자 768 개를 쓴다는 뜻이에요.

좌표가 2 개 (x, y) 면 평면 위 한 점이고, 3 개 (x, y, z) 면 공간 한 점인 것처럼, 768 개면 768 차원 공간의 한 점이 되는 거예요.

우리가 2D 평면 이상은 머리로 그릴 수 없지만, 컴퓨터는 768 차원에서도 두 점 사이 거리를 똑같이 계산할 수 있어요.

차원이 늘어날수록 문장의 미묘한 의미 차이를 더 풍부하게 담을 수 있고요.

한 줄 코드 — 임베딩 모델이 하는 일

Day 15 의 EmbeddingService 가 하는 일이 딱 한 줄이에요. 미리 한 번 살짝 보여드릴게요.

// lectures/spring-ai/lecture-source-code/ai-friends/.../EmbeddingService.java
// (Day 15 Step 2 에서 본격적으로 다룰 부분)

private final EmbeddingModel embeddingModel;

public float[] embed(String text) {
    return embeddingModel.embed(text);
}

문장 (String text) 이 들어가면 실수 배열 (float[], 길이 768) 이 나옵니다. 그게 다예요. 문장 → 벡터 변환은 임베딩 모델의 본질을 한 줄로 압축한 모습이에요.

코사인 유사도 — 두 벡터의 가까움을 숫자로

두 벡터 사이 가까움을 어떻게 숫자로 잴까요? RAG 에서 표준으로 쓰는 방식이 코사인 유사도 (cosine similarity) 입니다.

코사인 유사도는 두 벡터가 가리키는 방향의 가까움을 -1 ~ 1 사이 값으로 돌려줘요.

• 1 에 가까울수록 → 두 벡터가 같은 방향 → 의미가 가까움
• 0 근처 → 두 벡터가 직각 → 의미가 무관함
• -1 에 가까울수록 → 두 벡터가 정반대 → 의미가 반대

실무에선 코사인 거리 (cosine distance) = 1 - 코사인 유사도 로 변환해 작을수록 가까움으로 통일해 쓰기도 해요. pgvector 도 <=> 연산자로 코사인 거리를 돌려주는 방식입니다.

임베딩 모델은 어떻게 의미가 가까운 위치를 학습하나

"문장이 의미 공간의 한 점이 된다" 는 흐름을 처음 들으면 "그 위치가 어떻게 결정되는 거예요?" 가 자연스레 떠올라요.

임베딩 모델은 보통 대조 학습 (contrastive learning) 이라는 방식으로 훈련돼요. 학습 데이터는 "의미가 가까운 문장 쌍" 과 "의미가 먼 문장 쌍" 이에요.

• 가까운 쌍: "오늘 날씨가 좋다" ↔ "오늘 하늘이 맑다"
• 먼 쌍: "오늘 날씨가 좋다" ↔ "파이썬으로 머신러닝하기"

모델은 가까운 쌍의 두 벡터가 공간에서 가까이 모이도록, 먼 쌍의 두 벡터가 멀리 떨어지도록 가중치를 학습해요.

수억 개의 쌍을 학습하면 어떤 새로운 문장을 넣어도 의미가 가까운 위치가 자연스레 만들어집니다.

세부 학습 방식은 (Sentence-BERT · SimCSE · E5 · BGE 등) 모델마다 다르지만 공간에서 의미가 가까운 위치라는 본질은 같아요.

본 강의에선 어떻게 학습됐는지보다 어떻게 사용하면 되는지에 초점을 둡니다.

semantic similarity 와 lexical similarity 의 차이

여기서 한 가지 짚어둘 게 있어요. 임베딩 기반 유사도를 semantic similarity (의미 유사도) 라고 부르는데, 이게 전통적인 lexical similarity (어휘 유사도) 와 다릅니다.

lexical 검색 (예: SQL LIKE '%차분%') 으로는 "침착하다" 를 못 잡아내요.

semantic 검색은 두 문장이 의미상 같은 영역에 있다는 걸 자동으로 알아챕니다. 그게 RAG 가 키워드 검색보다 강한 첫 번째 이유예요.

코드 한 줄 미리보기 — 의미 공간이 코드로

EmbeddingService.embed("ARIA 는 차분하다") 의 반환값이 어떻게 생겼는지 살짝 미리 보여드릴게요. Day 15 에서 직접 돌려봅니다.

[-0.0182, 0.0341, -0.0773, ..., 0.0091]   // 길이 768 의 float 배열

이 배열의 첫 3 개 숫자만 봐도 해석할 수가 없어요. 숫자 자체에 의미가 있는 게 아니라, 다른 문장의 벡터와 비교했을 때 거리가 가까운지가 중요한 거예요.

마치 지도 좌표 (37.5, 127.0) 만 봐서는 그게 서울인지 알 수 없지만, 다른 도시 좌표와 비교하면 서울이 부산보다 인천에 가깝다가 보이는 것과 같아요.

⚠️ 주의: 같은 임베딩 모델로 적재·검색

KB 청크를 적재할 때 쓴 임베딩 모델과 질문을 임베딩할 때 쓴 모델이 반드시 같아야 해요.

다른 모델 두 개의 벡터 공간은 좌표계가 달라서, 한 모델의 서울 좌표와 다른 모델의 서울 좌표가 전혀 다른 위치에 떨어져요. 코사인 거리를 비교하는 의미가 사라집니다.

💡 튜터의 결론

임베딩은 문장을 의미 공간의 한 점으로 옮기는 흐름이에요. 768 개 숫자가 한 문장을 표현하고, 두 점 사이 거리 (코사인 유사도) 가 의미의 가까움을 숫자로 돌려줘요.

다음 Step 에서 그 점들이 수만 개·수십만 개가 됐을 때 어떻게 빠르게 검색하는지 — 벡터 DB 로 갑니다.

KB 청크 하나가 벡터 한 개로 저장된다고 했어요. 그럼 청크가 자라서 100,000 개가 되면? 1,000,000 개가 되면?

매 질문마다 100만 개 벡터와 일일이 코사인 거리를 계산하면 응답이 수 초씩 늘어나요. 미연시 게임이 답답해 보이는 두 번째 신호죠.

그래서 RAG 운영에선 벡터 DB (vector database) 라는 전용 저장소를 써요.

보통 일반 RDB (PostgreSQL · MySQL) 가 행 (row) 단위 인덱스로 검색을 빠르게 하듯이, 벡터 DB 는 벡터 단위 인덱스로 검색을 빠르게 해요.

도서관에서 책 찾는 두 가지 방법

비유로 풀어볼게요. 큰 도서관에 책 100만 권이 있어요. "민음사에서 나온 김애란의 단편집" 을 찾으려면 두 가지 방법이 있어요.

왼쪽에는 사서가 첫 책장부터 마지막 책장까지 책 한 권 한 권을 들고 확인하며 지친 모습(전수조사), 오른쪽에는 사서가 분류표를 펼쳐 보고 "한국 소설 → 김애란 → 단편집" 영역으로 곧장 가는 모습(인덱스 검색).

첫 번째 — 전수조사. 첫 책장부터 마지막 책장까지 한 권씩 손에 들고 "이거 맞나?" 확인합니다.

정확하지만 시간이 너무 오래 걸려요. 100만 권이면 사서가 하루 종일 매달려도 못 끝낼 수 있어요.

두 번째 — 분류표 사용. 한국 문학 → 단편 → 김애란 → 민음사 순으로 분류 체계를 따라가요.

책 100만 권 중에서도 분류표가 잡아주는 영역만 보면 되니까 수 초 안에 끝납니다. 단, 분류가 살짝 어긋난 책 한 권은 놓칠 수도 있어요 (예: 잘못 분류된 책).

벡터 DB 도 똑같아요. 전수조사 = 정확하지만 느림. 인덱스 사용 = 빠르지만 약간 근사적. 그래서 Approximate Nearest Neighbor 라는 이름이 붙어요.

ANN — Approximate Nearest Neighbor

ANN (Approximate Nearest Neighbor, 근사 최근접 이웃) 은 정확한 1 등 대신 높은 확률로 진짜 1 등 근처의 결과를 빠르게 돌려주는 방식이에요.

예를 들어 정확한 Top-3 가 [청크A, 청크B, 청크C] 라면, ANN 은 [청크A, 청크B, 청크D] 를 돌려줄 수도 있어요. C 와 D 가 거의 같은 거리에 있는 상태에서 한 번 살짝 어긋난 거예요.

RAG 의 실무에선 이 정도 어긋남은 응답 품질에 거의 영향이 없습니다 (어차피 LLM 이 N 개 청크를 보고 답을 합치니까요).

HNSW vs IVFFlat — 두 가지 인덱스의 트레이드오프

2026 년 pgvector 의 표준 ANN 인덱스가 두 가지예요. 둘의 트레이드오프를 한 표로 정리해 둘게요.

학생 단계에선 HNSW 가 무난한 디폴트예요. 검색이 빠르고, 데이터 추가가 매끄럽거든요. 적재 비용은 학습 규모 (수백~수만 청크) 에선 체감이 거의 없어요.

HNSW 는 계층적 그래프 (위층에서 큰 점프, 아래층에서 미세 조정), IVFFlat 는 클러스터 분할 (벡터를 N 개 클러스터로 나누고 가까운 클러스터만 탐색).

운영 규모 (수백만~수천만 청크) 에 가면 두 인덱스의 트레이드오프를 다시 따져야 해요. 본 강의 범위를 넘어가니, 별도 벡터 DB 운영 과정에서 깊게 다룰 영역입니다.

HNSW 의 작동 원리 — 계층적 그래프 한 줄로

조금만 더 깊게. HNSW 의 H 가 Hierarchical (계층적) 인 이유를 한 줄로 풀어볼게요.

맨 위층은 점이 5 개, 중간층은 50 개, 맨 아래층은 모든 벡터 (예: 100,000 개) 가 점으로 표시된 모습. 검색 시 맨 위층에서 시작해 점프하며 내려와 맨 아래층에서 미세 조정하는 화살표.

HNSW 는 벡터들을 계층적 그래프로 구성해요. 위층은 점이 적고 (큰 점프 가능), 아래층은 점이 많아요 (미세 조정).

검색은 맨 위층의 한 점에서 시작 → 위층에서 점프 점프 → 가까운 곳 찾기 → 내려가서 미세 조정 → 맨 아래층의 진짜 1 등 찾기의 흐름으로 돌아갑니다.

이 방식이 대수적 복잡도를 끌어내려요. 전수조사가 100만 청크에서 100만 번 비교라면, HNSW 는 약 log(100만) = 20 번 비교 정도로 끝나요. 5만 배 빨라지는 셈.

단점은 인덱스 빌딩 비용. 100만 청크의 계층 그래프를 처음 만들 때 시간이 약간 걸려요. 한 번 만들어두면 검색은 평생 빨라요. 학습 규모에선 빌딩 비용이 거의 체감되지 않습니다.

Top-K — 가장 가까운 K 개를 꺼낸다

벡터 DB 검색의 결과는 가장 가까운 K 개의 청크예요. K 는 보통 3, 5, 10 정도. 이걸 Top-K 라고 불러요.

• K=1 — 가장 가까운 한 개만 → 정확하지만 정보가 부족할 수 있음
• K=5 — 위쪽 5 개 → 학습용 디폴트, 다양한 관점 포착
• K=20 — 위쪽 20 개 → 추가 토큰 비용 + LLM 이 노이즈에 휘둘릴 수 있음

K 의 트레이드오프는 정확도 ↔ 비용·노이즈의 균형이에요. 다음 시간 Day 15·16 에서 K 값을 바꿔가며 검색 품질이 어떻게 바뀌는지 직접 돌려보는 시간이 있어요.

코드 한 줄 미리보기 — VectorStore 의 검색 메서드

Day 15 의 VectorStore 빈이 검색을 어떻게 노출하는지 미리 한 줄.

// lectures/spring-ai/lecture-source-code/ai-friends/.../VectorStoreConfig.java
// (Day 15 Step 4 에서 다룰 부분)

@Bean
public VectorStore vectorStore(JdbcTemplate vectorStoreJdbcTemplate, EmbeddingModel embeddingModel) {
    return PgVectorStore.builder(vectorStoreJdbcTemplate, embeddingModel)
            .dimensions(768)
            .indexType(PgVectorStore.PgIndexType.HNSW)
            .distanceType(PgVectorStore.PgDistanceType.COSINE_DISTANCE)
            .initializeSchema(true)
            .build();
}

indexType(HNSW) + distanceType(COSINE_DISTANCE) — 오늘 익힌 두 개념이 빌더 한 줄에 그대로 들어 있어요. 다음 시간 그 부분에서 다시 만납니다.

💡 튜터의 결론

100만 벡터에서 Top-K 를 빠르게 찾으려면 인덱스가 필요해요. ANN (HNSW · IVFFlat) 이 정확함 대신 속도를 가져오는 방식이고, 그 약간의 근사성은 RAG 응답 품질에 영향이 거의 없어요.

학습 디폴트는 HNSW + COSINE_DISTANCE 의 조합입니다.

이제 RAG 의 풀네임을 정확히 펼쳐볼 시간이에요.

Retrieval-Augmented Generation — 검색-증강 생성.

세 글자가 각각 어떤 일을 하는지, 어디서 잘리고 어디서 이어지는지 분해해 봅시다.

R · A · G 한 글자씩

Retrieval (검색)

• 마스터의 질문을 받아, 같은 임베딩 모델 로 벡터를 만들어요.
• 벡터 DB 에서 그 벡터와 의미가 가까운 청크 Top-K 개를 꺼냅니다.
• 출력: K 개의 청크 (각각 텍스트 + metadata)

Augmented (증강)

• 꺼낸 청크를 LLM 에 넘기는 프롬프트에 추가 컨텍스트 로 끼워 넣어요.
• 보통 "다음 문서를 참고해서 답해줘: [청크1] [청크2] [청크3]" 같은 시스템 프롬프트 위치에 들어갑니다.
• 출력: 청크가 들어간 완성된 프롬프트

Generation (생성)

• LLM 이 그 프롬프트를 받아 답을 생성해요.
• 답의 근거가 청크 안에 있으니까, 모델이 모르는 부분을 지어내는 (환각, hallucination) 위험이 줄어요.
• 출력: 사용자에게 돌려줄 응답 텍스트

한 번 더 — 일상 비유로 R·A·G 풀어보기

세 글자가 약간 추상적으로 들릴 수 있어서 일상 비유 한 번 더 던져볼게요.

"어제 김애란 단편 추천해주세요" 라는 질문에 (1) 사서가 분류표로 책 3 권을 골라오고 (R), (2) 책 세 권을 책상에 펼쳐 놓고 (A), (3) "이 세 권 중에는 호두 라떼 같은 단편이 있어요" 라고 사서가 종합해서 답하는 (G) 흐름.

도서관 사서가 손님의 질문 "어제 김애란 단편 추천해주세요" 에 답하는 흐름을 떠올려 보세요.

• R (검색) — 사서가 분류표를 펼쳐 "한국 문학 → 단편 → 김애란" 영역에서 책 3 권을 골라옵니다.
• A (증강) — 책 세 권을 책상 위에 펼쳐 놓고 "이 세 권 사이에서 답해줘" 의 상태로 준비합니다.
• G (생성) — 사서가 세 권의 내용을 종합해 "호두 라떼 같은 단편이 있어요 — 비행운 추천드려요" 의 답을 만듭니다.

LLM 의 RAG 와 1:1 로 겹쳐요. 단지 책 = 청크, 분류표 = 벡터 인덱스, 사서 = ChatModel 로 매핑이 바뀌었을 뿐이에요.

한 장 플로우차트

(1) 마스터 질문 "어제 약속이 뭐였더라?" → (2) EmbeddingModel 이 질문을 768 차원 벡터로 변환 → (3) pgvector VectorStore 가 Top-K 청크 검색.

→ (4) "다음 문서를 참고해 답해줘 + 청크1 + 청크2 + 청크3" 프롬프트 빌드 → (5) ChatModel (LLM) 이 응답 생성 → (6) 마스터에게 답변 전달.

(1)(2)(3) 위에 "R" 라벨, (4) 위에 "A" 라벨, (5)(6) 위에 "G" 라벨.

이 플로우는 RAG 의 가장 기본 형태예요. 한 번의 질문 → 한 번의 검색 → 한 번의 생성. 이걸 Naive RAG 라고 불러요.

Naive RAG vs Modular RAG — 본질 차이 한 단락

2026 년 RAG 운영에선 두 가지 방식이 정착해 있어요.

Naive RAG — 위 플로우차트 한 줄. 검색 → 증강 → 생성이 직선 한 번이에요. 단순하고 빠르고 디버깅이 쉬워요. 학습 + 중소 규모 운영에 충분합니다. 본 강의 Day 15 의 첫 그림 이에요.

Modular RAG — 검색 부분을 advisor 체인으로 분해해서, 질문 재작성 → 검색 → 재랭킹 (re-ranking) → 압축 → 생성 같이 단계별로 모듈을 끼워 넣어요.

각 단계가 독립된 부품 (Spring AI 의 advisor 거울) 으로 살아 있어서 한 부품만 갈아 끼우는 유연성이 큽니다. 깊은 비교는 본 강의 Day 16 에서 본격적으로 다룹니다.

핵심 메시지 — "Naive 가 부족해서 Modular 로 가는 게 아니에요".

Naive 가 어디까지 충분한지를 먼저 익히고, 한계가 보일 때 모듈 한 개씩만 더 끼우는 흐름이 운영 친화적입니다. 처음부터 모듈을 다 끼우면 디버깅이 어려워져요.

Naive RAG 가 한계를 보이는 곳 — 4 가지 신호

Naive 가 어디까지 충분한지를 익히는 방법은 한계가 보이는 신호를 알아두는 거예요. 운영에서 Modular 의 모듈을 끼워야 할 시점이 보이는 4 가지 신호를 정리해 둘게요.

신호 1 — 질문이 짧고 모호하다

마스터의 질문이 "어제 일기" 처럼 짧은 한 단어면 임베딩이 잡아내는 의미 영역이 좁아져요. 답이 어제 일기 전체인지 어제 적은 약속 부분인지 LLM 이 헷갈리는 사고가 나요.

질문 재작성 (query rewriting) 모듈이 "어제 적은 약속과 관련된 일기 내용을 알려줘" 로 풀어 검색을 도와요.

신호 2 — Top-K 가 너무 다양한 영역에 흩어진다

검색 결과 5 개가 서로 무관한 5 가지 주제라면 LLM 이 종합하기 어려워요. 재랭킹 (re-ranking) 모듈이 질문-청크 한 쌍씩 더 정확한 점수를 매겨 진짜 가까운 N 개만 남겨요.

신호 3 — 청크가 너무 길어서 토큰이 폭발한다

청크 5 개가 합쳐 5,000 토큰이라면 LLM 컨텍스트가 차서 응답이 짧아져요. 컴프레션 (compression) 모듈이 청크의 질문과 관련된 부분만 추출해 토큰을 줄여요.

신호 4 — 답이 청크 안에 명시적으로 안 적혀 있다

마스터가 "오늘은 ARIA 가 기분이 어땠어?" 라고 물었는데 일기에 "오늘 ARIA 가 카페에서 한참 웃었다" 만 적혀 있다면? 답은 "기분이 좋았다" 인데 LLM 이 추론으로 답해야 해요.

이건 RAG 의 한계 — 복잡한 추론은 다른 패턴 (Day 14 의 Agent · Tool Calling 결합) 으로 풀어야 합니다.

네 가지 신호를 알고 있으면 언제 Naive 가 무너지는지가 보여요. 그때까지는 Naive 만으로 충분합니다.

"환각 (hallucination)" — RAG 가 줄여주는 부분

용어 하나 더 정리해 둘게요. LLM 이 자기가 모르는 영역에서도 그럴듯하게 답을 지어내는 현상을 환각 (hallucination) 이라고 불러요.

ARIA 에게 "어제 일기에 뭐라고 적었지?" 라고 물었을 때, LLM 가중치 안에 답이 없으면 두 가지 식으로 갈려요.

• 환각 — "어제 일기에 호두 라떼를 마셨다고 적으셨네요" (사실이 아니지만 그럴듯하게 지어냄)
• 솔직 — "제 기억엔 한정된 컨텍스트만 있어서, 어제 일기는 짚어드리기 어려워요" (Day 14 의 ARIA)

LLM 운영에서 환각은 가장 큰 사고 영역이에요. 사용자가 사실로 믿어버리면 신뢰가 깨지거든요. RAG 는 답의 근거가 청크 안에 있음을 강제해서 환각을 상당히 줄여줘요.

단 완전히 없애주진 않아요. 청크 안에 답이 없을 때도 LLM 이 청크 내용을 과장 해석하는 사고가 남아 있어요.

이걸 줄이는 방법이 프롬프트 엔지니어링 + 재랭킹 + citation (출처 표시) 같은 Modular RAG 의 모듈들이에요. Day 16 의 본격 다룸 영역.

Spring AI 의 advisor 가 어디 들어가는가

Day 16 에 가면 RAG 의 A 와 G 부분이 한 묶음 advisor 로 자동화돼요. 이름이 RetrievalAugmentationAdvisor 입니다 (또는 더 얇은 QuestionAnswerAdvisor).

advisor 체인의 위치를 한 줄 그림으로 정리하면 —

User Message
   ↓
[advisor 1: QuestionAnswerAdvisor or RetrievalAugmentationAdvisor]
   │  ─ (R) 질문을 임베딩 → VectorStore.similaritySearch(K)
   │  ─ (A) 청크를 시스템 프롬프트에 끼움
   ↓
[advisor 2: ChatMemory ...]
   ↓
ChatModel.call() ─ (G)
   ↓
Response

오늘은 advisor 의 모양만 잡아두세요. 코드는 Day 16 에서 직접 다룹니다.

💡 튜터의 결론

R·A·G 는 검색 → 증강 → 생성의 세 단계예요. Naive RAG (직선 한 번) 가 학습·중소 운영의 첫 그림이고, Modular RAG (단계 분해) 는 한계가 보일 때 모듈 한 개씩만 더 끼우는 흐름이에요.

Spring AI 의 RetrievalAugmentationAdvisor 가 다음 시간 그 자동화를 한 묶음으로 해줘요.

여기까지 임베딩 · 벡터 DB · R·A·G 분해를 익혔어요. 마지막 부품 하나가 남았어요. KB 가 처음 들어올 때 어떤 단위로 벡터화될지를 결정하는 부분 — 청킹 (chunking) 입니다.

왜 통째로 임베딩하면 안 되는가

비유 하나 던져볼게요. 두꺼운 책 한 권을 통째로 검색하고 싶다고 합시다.

옵션 A — 책 한 권 통째 임베딩. 책 전체를 한 벡터 (float[768]) 로 만들어요. 문제는?

• 벡터가 책 전체의 평균 의미를 담아요. "5 장 7 절의 김애란 단편 분석" 같은 특정 부분 의미는 평균에 묻혀 사라져요.
• 검색해도 "이 책 전체와 관련 있다" 만 알 수 있을 뿐, 어느 페이지가 답인지 모릅니다.
• LLM 에 청크로 넘길 때 책 전체를 넘기면 토큰 비용이 폭발해요.

옵션 B — 책을 페이지 단위로 분할 임베딩. 한 페이지씩 벡터를 만들어요. 검색하면 "5 장 7 절 페이지가 답이다" 가 바로 잡혀요. LLM 에 넘길 때도 그 한 페이지만 흘려 보내면 됩니다.

청킹은 옵션 B 의 방식이에요. KB 문서를 의미 단위 (chunk) 로 잘게 쪼개서 각각 임베딩하는 흐름.

Before / After 한 묶음

ai-friends 의 KB 예시로 풀어볼게요. ARIA 의 캐릭터 프로필 마크다운 파일이 10,000 토큰 분량이라고 합시다.

Before — 통째 임베딩

aria-profile.md (10,000 토큰)
  → 한 개의 vector (768 차원)
  → 검색 시 "이 파일 전체" 만 잡힘
  → LLM 컨텍스트에 10,000 토큰 통째로 흘려보냄 (비용 폭발)

After — 청킹 후 임베딩

aria-profile.md (10,000 토큰)
  → TokenTextSplitter (chunk=500, overlap=50)
  → 약 20 개의 chunk
  → 각 chunk → 한 개의 vector
  → 검색 시 "MBTI 가 INTJ 인 이유" 청크 한 개만 잡힘
  → LLM 컨텍스트에 500 토큰만 흘려보냄

청크 수가 늘어나지만, 검색이 의미 단위로 정확해지고 토큰 비용도 줄어요. RAG 의 본질적 가치가 여기서 살아납니다.

청크 크기와 오버랩의 트레이드오프

청크 크기 (chunk size) 와 오버랩 (overlap) — 두 파라미터를 어떻게 정할지가 RAG 검색 품질의 핵심이에요.

청크 크기 (chunk size) — 한 청크가 몇 토큰을 담을지.

오버랩 (overlap) — 청크 간 겹치는 토큰 수. 청크 경계에 걸친 문장이 두 청크 모두에 살아남게 하는 장치입니다.

chunk 500 · overlap 50 일 때, 첫 청크가 토큰 1~500 을 담고, 다음 청크가 토큰 451~950 을 담아 450~500 구간이 두 청크에 동시에 들어가는 모습.

오버랩이 없으면 문장이 청크 경계에서 잘려서 의미가 깨져요 ("ARIA 는 INTJ 라서" / "분석적이다" 가 다른 청크로 갈리면 두 청크 다 단독으로는 약함).

오버랩이 너무 크면 같은 문장이 여러 청크에 중복돼서 토큰 낭비 + 검색 결과에 같은 문장이 여러 번 등장하는 사고가 나요.

학습 디폴트는 chunk=500 · overlap=50 (10% 오버랩) 입니다. Day 15 의 TokenTextSplitter 가 그 값으로 설정돼 있어요.

손계산 — 같은 KB 를 세 가지 크기로 자르면

가상의 KB 한 묶음 (총 10,000 토큰) 을 세 가지 청크 크기로 자르면 청크 수가 어떻게 변할지 손으로 한번 계산해 봅시다.

청크 크기가 200 → 1,000 으로 5 배 커지면, 청크 수는 1/5 로 줄지만 K=5 의 총 토큰은 5 배 늘어요. 검색 정밀도와 프롬프트 토큰 비용이 정확히 반대 방향으로 움직입니다.

또 하나 — 청크가 작으면 질문 한 줄과 같은 영역의 청크가 K=5 안에 더 다양하게 잡혀요. 청크가 크면 한 의미 단위가 통째로 들어와서 LLM 의 추론이 더 풍부해질 수 있어요.

어느 쪽이 좋은지는 질문의 평균 길이와 KB 의 의미 단위 크기에 달려 있어요. 본 Day 의 생각해볼 주제 3 에서 다시 고민해 봅시다.

토큰 vs 글자 — 한국어의 미묘한 지점

용어 하나 더 정리해 둘게요. 청크 500 토큰의 토큰은 무엇일까요?

LLM 의 입력 단위가 토큰 (token) 이에요. 영어는 보통 공백 단위 + 자주 쓰이는 어미·접미사 분리로 토큰화돼요. 한국어는 좀 더 미묘해서 — 보통 서브워드 단위로 깨져요.

예:

• 안녕하세요 → 토큰 1 개 (자주 쓰이는 형태라 통째)
• 안녕하시었나요 → 토큰 3~4 개 (덜 자주 쓰여서 분할)
• RAG 임베딩 입문 → 토큰 5~7 개 (영어·한국어 혼합)

그래서 청크 500 토큰은 한국어로 대략 공백 기준 300~400 어절 정도예요. 한 문단~한 문단 반 정도 분량.

💡 튜터의 노트

한국어 RAG 운영에서 가장 신경 쓰이는 부분이 문장 경계가 청크 안에서 깨지는 사고예요. TokenTextSplitter 는 토큰 단위라 문장 경계를 보존하지 않아요.

본격 운영에선 sentence-aware splitter (마침표·물음표 단위 분할) 와의 트레이드오프를 비교하게 되는데, 그 부분은 Day 16 의 본격 다룸 영역입니다.

학습 디폴트로는 TokenTextSplitter 한 줄이면 충분해요.

청크 크기 결정 — 3 가지 가이드 라인

청크 크기를 정할 때 디폴트 500 토큰 외에 운영에서 자주 쓰는 가이드 라인 3 가지를 정리해 둘게요.

가이드 1 — KB 의 의미 단위가 평균 얼마인가

마크다운 한 문단이 의미 단위라면 한 문단의 토큰 수 (보통 200~400 토큰) 의 1.5 배쯤이 적절해요. 한 의미 단위가 한 청크 안에 통째로 들어가게 하는 방식입니다.

가이드 2 — 질문의 평균 길이는 얼마인가

질문이 짧은 (50 토큰 내외) FAQ 형이라면 청크도 짧게 (200~300 토큰) 두는 게 검색 매칭 정밀도에 좋아요.

질문과 청크의 토큰 분포가 비슷할 때 임베딩 모델의 의미 매칭이 더 정확하게 작동해요.

가이드 3 — LLM 컨텍스트 토큰 예산

Top-K=5 일 때 청크 5 개 + 시스템 프롬프트 + 질문 + 응답 여유분이 모델의 컨텍스트 윈도우를 과반 이상 차지하지 않게 두세요.

4K 모델이면 청크 5 개가 2K 를 넘지 않게 — 청크 한 개 400 토큰 미만.

세 가지를 동시에 만족시키는 값이 학습 디폴트 500 토큰이에요. 운영 환경에서는 KB 의 특성에 따라 200 ~ 1,000 사이로 갈리고요.

코드 한 줄 미리보기 — TokenTextSplitter

Day 15 의 DocumentLoaderService 안에서 청킹이 어떻게 작성되는지 미리 한 줄.

// lectures/spring-ai/lecture-source-code/ai-friends/.../DocumentLoaderService.java
// (Day 15 Step 5 에서 다룰 부분)

public static final int DEFAULT_CHUNK_TOKENS = 500;
public static final int DEFAULT_CHUNK_OVERLAP = 50;

TokenTextSplitter splitter = new TokenTextSplitter(
        DEFAULT_CHUNK_TOKENS,
        DEFAULT_CHUNK_OVERLAP,
        /* minChunkLengthToEmbed */ 5,
        /* maxNumChunks */ 10_000,
        /* keepSeparator */ true);
List<Document> chunks = splitter.apply(rawDocuments);

500 과 50 — 오늘 익힌 디폴트가 빌더 인자에 그대로 흘러갑니다. 다음 시간 그 곳에서 다시 만나요.

💡 튜터의 결론

청킹은 KB 문서를 의미 단위로 잘게 쪼개서 각각 임베딩하는 흐름이에요. 청크 크기 + 오버랩의 트레이드오프가 RAG 검색 품질의 핵심 변수입니다.

학습 디폴트는 chunk=500·overlap=50. 한국어 운영에선 sentence-aware splitter 와의 비교가 다음 단계의 고민이에요.

여기까지 5 개념을 익혔어요. 한 줄씩 다시 짚고 — 그 다음에 각 개념이 다음 시간 어느 코드로 자라는지 로드맵을 그려볼게요.

한 번 더 복습 — 5 개념이 한 흐름으로 이어지는 모습

코드로 자라는 모습을 보기 전에, 5 개념이 한 RAG 사이클에서 어떻게 이어지는지 한 번 더 짚어볼게요.

마스터가 "어제 약속이 뭐였더라?" 한 줄을 던졌을 때 ai-friends 내부에서 도는 흐름이에요.

1. 외부 지식 주입의 필요 — ARIA 가 이 질문에 답하려면 어제의 일기가 외부에 저장돼 있어야 한다.
2. 임베딩 — 마스터의 질문 "어제 약속이 뭐였더라?" 가 EmbeddingService.embed(...) 한 줄로 768 차원 벡터가 된다.
3. 벡터 DB + ANN — pgvector 안의 HNSW 인덱스가 그 벡터와 가까운 청크 Top-K=5 를 빠르게 꺼낸다.
4. R·A·G — 꺼낸 청크 5 개가 시스템 프롬프트에 끼워 들어가고 (A), ChatModel 이 그 컨텍스트 위에서 답을 생성한다 (G).
5. 청킹 — 그런데 적재 시점에 마스터의 일기가 chunk=500·overlap=50 으로 잘려 있어야 위의 흐름이 도는 거예요. 청킹은 시간상 가장 먼저 일어나는 단계.

다섯 단계가 한 사이클의 다른 시점에 동작해요. 5 (청킹) 는 적재 시점, 1 회만. 1·2·3·4 는 질문 시점, 매 호출마다.

두 흐름이 만나는 지점이 vectorStore.add(chunks) (적재) 와 vectorStore.similaritySearch(query) (검색) 두 메서드입니다.

왼쪽(적재 시점, 1회) 에 "마크다운 파일 → 청킹 → 임베딩 → pgvector 적재" 의 4 단계, 오른쪽(질문 시점, 매번) 에 "마스터 질문 → 임베딩 → pgvector 검색 → 청크 5 개 → LLM → 응답" 의 6 단계. 두 흐름이 pgvector 박스를 공유하며 가운데서 만남.

Day 15·16 로드맵 — 5 개념이 코드로 자라는 모습

왼쪽에 오늘 익힌 5 개념 박스가 세로로 정렬, 오른쪽에 Day 15·16 의 코드 부품 (EmbeddingService · VectorStoreConfig · DocumentLoaderService · CharacterKnowledgeIngestionService · RetrievalAugmentationAdvisor) 박스가 정렬, 두 묶음 사이에 화살표로 어느 개념이 어느 부품으로 자라는지 연결되는 그림.

Day 15 — RAG 의 R 부분을 손으로

Day 15 는 RAG 의 R 단계를 끝까지 손으로 돌려보는 시간이에요. KB 한 묶음을 pgvector 에 넣고, 마스터의 질문을 임베딩해서 Top-K 청크가 의미 가까운 순으로 돌아오는 모습까지.

Day 16 — A 와 G 의 자동 결합 + Modular RAG 의 첫 모듈

Day 16 은 RAG 의 A + G 단계를 advisor 가 한 묶음으로 해결하고, Modular 의 첫 모듈 (재랭킹) 을 끼워 넣어 검색 품질을 한 단계 끌어올리는 시간이에요.

코드 한 묶음 미리보기 — Day 15 가 어떻게 자랄지

세 부품이 어떻게 한 흐름으로 이어지는지 살짝 미리 보여드릴게요.

// (1) EmbeddingService — 문장을 벡터로
// lectures/spring-ai/.../rag/service/EmbeddingService.java

@Service
@RequiredArgsConstructor
public class EmbeddingService {
    private final EmbeddingModel embeddingModel;  // 인터페이스 주입

    public float[] embed(String text) {
        return embeddingModel.embed(text);
    }
}

// (2) VectorStoreConfig — pgvector + HNSW 인덱스 손등록
// lectures/spring-ai/.../rag/config/VectorStoreConfig.java

@Bean
public VectorStore vectorStore(JdbcTemplate vectorStoreJdbcTemplate, EmbeddingModel embeddingModel) {
    return PgVectorStore.builder(vectorStoreJdbcTemplate, embeddingModel)
            .dimensions(768)
            .indexType(PgVectorStore.PgIndexType.HNSW)
            .distanceType(PgVectorStore.PgDistanceType.COSINE_DISTANCE)
            .initializeSchema(true)
            .build();
}

// (3) CharacterKnowledgeIngestionService — 청크를 벡터 DB 에 적재
// lectures/spring-ai/.../rag/service/CharacterKnowledgeIngestionService.java

public int ingest() {
    List<Document> chunks = documentLoaderService.loadAndChunk();
    vectorStore.add(chunks);   // 한 줄로 N 개 청크 → 벡터화 → 적재
    return chunks.size();
}

세 부품이 오늘 익힌 5 개념 위에 한 줄 한 줄 자라는 모습이 보이시죠?

• (1) — 임베딩 개념이 EmbeddingModel 인터페이스 한 줄로
• (2) — 벡터 DB + ANN + 코사인 거리가 빌더 한 묶음으로
• (3) — 청킹 + Top-K 적재가 loadAndChunk() + add() 한 줄로

오늘 익힌 흐름 다이어그램

위쪽에 "KB 적재 (1회)" 흐름 (마크다운 파일 → 청크 분할 → 임베딩 → pgvector 적재), 아래쪽에 "질문 처리 (매 호출)" 흐름 (사용자 질문 → 임베딩 → pgvector Top-K 검색 → 청크 N 개 → LLM 컨텍스트 → 응답). 두 흐름이 pgvector 박스를 공유하며 만나는 모양.

면접 키워드 — RAG 첫 만남에서 묻는 질문들

본 강의 졸업 후 면접에서 RAG 관련 질문이 들어왔을 때 짧고 정확히 답할 수 있는 한 줄들이에요.

🎯 면접관을 홀리는 핵심 멘트

"RAG 의 본질은 비용·속도·갱신성 3 축을 한 번에 푸는 외부 지식 주입입니다. LLM 컨텍스트에 KB 를 통째로 넣으면 셋 다 깨져요.

임베딩으로 의미 공간에 매핑하고, ANN 인덱스 (HNSW) 로 Top-K 를 빠르게 꺼내, 청크 N 개만 프롬프트에 끼워 넣습니다."

🎯 면접관을 홀리는 핵심 멘트

"적재 임베딩 모델과 검색 임베딩 모델은 반드시 같아야 합니다. 다른 모델의 벡터 공간은 좌표계가 달라 코사인 거리가 의미가 없어요.

운영 중 모델을 갈아끼우려면 전체 KB 재임베딩이 동반됩니다."

🎯 면접관을 홀리는 핵심 멘트

"Naive RAG 가 어디까지 충분한지 먼저 익히고, 한계가 보일 때 Modular 의 모듈 한 개씩만 더 끼우는 흐름이 운영 친화적입니다. 처음부터 모듈을 다 끼우면 디버깅이 깊어져요."

다음 시간 Day 15 — 직접 손으로 짜는 시간

다음 시간 Day 15 부터는 오늘 익힌 5 개념 위에 코드를 한 줄씩 얹어요.

키워드 미리 잡아두면 — EmbeddingService · pgvector · PgVectorStore · TokenTextSplitter · HNSW 인덱스 다섯 가지입니다.

docker-compose 에 pgvector 컨테이너 한 줄이 추가되고, application.yml 에 임베딩 프로파일 한 묶음이 들어가요.

Ollama 로컬 (nomic-embed-text) 과 Gemini (gemini-embedding-001) 양쪽 다 돌려보고, KB 한 묶음을 적재해서 마스터의 질문에 의미 가까운 청크 Top-K 가 돌아오는 모습까지 손으로 확인합니다.

💡 튜터의 결론

오늘 5 개념을 비유로 익혔어요.

다음 시간 Day 15 의 EmbeddingService · VectorStoreConfig · DocumentLoaderService · CharacterKnowledgeIngestionService 네 부품이 오늘 빈 슬롯 위로 자연스럽게 떨어질 거예요.

코드를 보는 눈이 "이게 뭐지?" 가 아니라 "아, 이 부분이 그거구나" 로 바뀌어 있는 모습 — 그게 오늘 한 번 정리하고 간 가장 큰 가치예요.

오늘의 Step 한 줄 요약

오늘 익힌 5 개념 흐름 다이어그램

좌측의 5 개념 시퀀스: (1) "외부 지식 주입의 필요" → (2) "임베딩: 문장 → 벡터" → (3) "벡터 DB + ANN: Top-K 빠르게" → (4) "R·A·G 분해: 검색→증강→생성" → (5) "청킹: 큰 문서를 의미 단위로".

다이어그램 우측에는 다음 시간 Day 15 의 4 부품 (EmbeddingService · VectorStoreConfig · DocumentLoaderService · CharacterKnowledgeIngestionService) 이 5 개념과 화살표로 연결되어 흐르는 모습.

등장 용어 카탈로그

오늘 익힌 20 개 용어를 한눈에. 다음 시간 Day 15·16 에서 코드와 함께 다시 만나는 단어들이에요.

한국어 RAG 의 특수성 — 짧게 짚고 가요

본 강의의 KB 는 한국어 자료가 절반 이상이에요. 한국어 RAG 운영에서 특히 신경 쓰이는 부분 3 가지를 정리해 둘게요.

임베딩 모델의 한국어 지원 — 모델마다 다르다

nomic-embed-text 는 다국어를 지원하지만 영어 중심으로 학습돼서 한국어의 미묘한 어미·조사를 잘 못 잡아낼 때가 있어요.

Gemini 의 gemini-embedding-001 은 다국어 학습 비중이 높아 한국어가 잘 나오는 편.

운영에선 한국어 특화 모델 (KoSentenceBERT 등) 을 별도로 두는 경우도 있어요.

조사·어미가 키워드 매칭을 흐린다 — lexical 검색의 한국어 한계

전통 검색 (Elasticsearch · MySQL LIKE) 으로 "ARIA 의 차분함" 을 찾으면 "ARIA 는 차분하다" 를 못 잡아요. 의, 는, 를 같은 조사가 결합형이라 lexical 검색에선 정밀도가 떨어져요.

semantic 검색 (임베딩) 이 여기서 한국어 RAG 의 핵심 강점이 됩니다.

청킹 — 문장 경계가 잘리는 사고

한국어 문장은 마침표·물음표가 영어보다 적게 쓰이는 편이라 TokenTextSplitter 가 토큰 500 지점에서 문장을 어색하게 자를 수 있어요.

예: "ARIA 가 카페에서 한참 웃었다. 그래서" 까지만 한 청크에 들어가고 "기분이 좋아 보였다." 가 다음 청크로 가는 모습.

본격 운영에선 sentence-aware splitter 로 보강하는 단계예요. Day 16 의 본격 다룸 영역.

이 세 가지를 지금 다 풀려고 하지 마세요. 다음 시간 Day 15 에서 Naive RAG 만으로 충분한지를 익힌 다음에 한 단계씩 보강하는 흐름이 가장 자연스러워요.

다음 시간 Day 15 — 첫 만남

다음 시간엔 docker-compose 에 pgvector 컨테이너 한 줄을 추가하고, application.yml 에 임베딩 프로파일 두 묶음 (Ollama · Gemini) 을 넣어요.

그 위에 EmbeddingService · VectorStoreConfig · DocumentLoaderService · CharacterKnowledgeIngestionService 네 부품을 한 줄씩 직접 짭니다.

키워드 네 가지로 미리 잡아두면 — EmbeddingService · pgvector · TokenTextSplitter · HNSW 입니다.

마지막으로 한 줄 — 오늘 한 번 정리하고 간 가치는 "코드를 보는 눈이 빈 슬롯을 알고 있는 상태" 예요. 다음 시간 코드가 빈 슬롯 위로 자연스럽게 떨어지는 모습을 함께 익혀봅시다.