10단계에서 LLM은 Stateless하기 때문에 매 요청마다 컨텍스트를 직접 전달해야 한다고 배웠다. 그런데 컨텍스트가 길어질수록 토큰 비용이 폭증하고, 필요한 정보만 골라서 전달해야 한다는 문제가 남아 있었다.이번 글에서는 그 해결책의 핵심인 Vector DB를 다

지금까지 Spring AI로 Gemini와 OpenAI 같은 클라우드 API를 연동해봤다.ChatClient 하나로 다양한 모델을 추상화해서 쓸 수 있다는 것도 확인했다.그런데 이런 의문이 생길 수 있다.클라우드 API를 쓰면 데이터가 외부 서버로 나가는데, 민감한 정

지난 글에서는 LLM과 대화를 설계하는 방법을 다뤘다. System / User / Assistant 세 가지 메시지 타입을 이해하고, 히스토리를 어떻게 구성해야 AI가 맥락을 잘 이해하는지 살펴봤다.그런데 히스토리를 쌓다 보면 자연스럽게 이런 의문이 생긴다.대화가 1

지난 글에서 Spring AI의 기본 구조와 ChatClient를 통해 LLM에 질문을 던지는 방법을 살펴봤다.그런데 막상 챗봇을 만들려고 하면 이런 의문이 생긴다.AI는 내가 아까 뭐라고 했는지 기억하는가?대화가 길어질수록 비용이 얼마나 늘어나는가?어떻게 해야 AI가

지금까지 IoC/DI, Bean, Spring MVC 흐름을 익히면서 Spring이 "복잡한 것을 추상화해서 개발자가 비즈니스 로직에 집중하게 해준다"는 철학을 반복해서 봐왔다. 오늘은 그 철학이 AI 영역에서 어떻게 적용되는지를 다룬다.이번 글을 읽으면서 스스로에게

지난 글에서 JPA의 기본 구조와 엔티티 매핑, 그리고 @Transactional의 존재를 처음 만났다. 그런데 코드를 짜다 보면 이런 의문이 생긴다.product.decreaseStock()만 호출했는데 왜 DB에 UPDATE가 날아가지?save()를 안 불렀는데 어

이전 글에서 Spring MVC 흐름, JPA, 영속성 컨텍스트까지 살펴봤다. 이번 글에서는 그 위에 실전 코드를 올린다. 다음 세 가지 질문을 중심으로 이야기를 풀어간다. 반복적인 Getter/Setter/생성자 코드를 어떻게 없앨 수 있을까? 잘못된 데이터가 S

들어가며 지난 글에서 Spring MVC의 흐름을 살펴봤다. HTTP 요청이 DispatcherServlet에 들어와서 Controller → Service → Repository 계층을 거쳐 응답으로 나가는 구조였다. 그런데 Repository 계층에서 실제로 D

지난 글에서 Spring Container가 Bean을 관리하고, 싱글톤으로 유지하며, 생명주기까지 책임진다는 걸 알았다. 그렇다면 자연스럽게 이런 질문이 생긴다.브라우저에서 URL을 입력하고 엔터를 누르면, Spring 내부에서 정확히 무슨 일이 벌어질까?Contro

이전 글에서 @Component를 붙이면 Spring이 그 클래스를 new해서 보관한다고 했다.그 보관된 객체를 Bean이라고 부른다고도 했다.이번 글에서는 Bean이 정확히 무엇인지, Container가 Bean을 어떻게 관리하는지,그리고 Bean이 언제 태어나고 언

Spring을 처음 접하면 @Component, @Autowired 같은 어노테이션이 낯설게 느껴진다.이 글에서는 Spring의 심장이라고 할 수 있는 두 가지 개념, IoC(제어의 역전) 와 DI(의존성 주입) 를 코드와 함께 차근차근 살펴본다.다음 코드를 보자.얼핏