RecursiveCharacterTextSplitterTokenTextSplitter각 줄 끝에 /n을 읽어들임 (문장 중간이라도)원본 문서의 포맷을 완전히 캡처하지 못함 (/n/n 없음). PDF의 경우 분할이 덜 정확함.대부분의 PDF 리더는 시각적 줄바꿈을 실제

RAG가 필요한 이유Input 크기에 따라 확장 가능: 관련된 몇 개의 문단만 검색하므로, 위키/드라이브가 커지더라도 컨텍스트 윈도우 제한에 도달하지 않습니다.더 낮은 비용 및 지연 시간: 전체 문서를 매번 프롬프트에 붙여넣는 것보다 훨씬 적은 토큰을 사용합니다.더 높

LangGraph에서는 add_messages reducer를 사용해 메시지 목록을 효율적으로 관리할 수 있습니다.결과 예시:✅ 메시지 수정 가능: ID를 통해 특정 메시지를 식별하고 수정✅ 중복 방지: 동일한 ID의 메시지가 여러 번 추가되는 것을 방지✅ 메시지 삭제

LangGraph를 학습하면서 가장 중요하게 이해해야 할 개념들을 정리했습니다. 특히 Tool Binding된 LLM 노드를 추가하는 방법과 Super-Step의 개념, 그리고 이것이 메모리 관리와 어떻게 연결되는지를 중심으로 기록했습니다.LangChain은 일반 함수

비동기 프로그래밍과 AI 에이전트를 결합하여 심층 검색(Deep Research) 시스템을 구현하는 방법을 정리했습니다. 이 글에서는 OpenAI SDK의 Agent 프레임워크를 활용하여 Plan → Search → Report 3단계 파이프라인을 구성하는 실제 구현

Next.js 16의 새로운 캐싱 기능을 프로젝트에 적용하여 성능을 개선함. 기존의 fetch 기반 데이터 로딩 방식에서 서버 액션과 'use cache' 디렉티브를 활용한 최적화된 구조로 전환했음.기존에는 클라이언트에서 직접 API를 호출하는 방식을 사용했으나, 이를

AI 에이전트를 라이브러리 없이 순수하게 구현해보면서 에이전트의 핵심 작동 원리를 이해해봅시다. 이 글에서는 OpenAI의 Function Calling 기능과 반복 루프(Agent Loop)만으로 목표를 달성하기 위한 Todo 리스트를 자동으로 생성하고, 각 항목을

AI agent를 통한 개발이 활발하게 이루어지고 있고, 그에 따라 사용하는 프레임워크나 Tool 선택이 중요해졌습니다. 그 중 Next.js 가 16 버전으로 업데이트 되면서, ai와 함께 하는 풀스택 개발이 더욱 용이해 진 것 같습니다.개요 : 기존의 파일 기반 라

LLM 기반 애플리케이션이 단순한 프롬프팅을 넘어 복잡한 시스템으로 진화함에 따라, 신뢰성과 성능을 확보하기 위한 워크플로우 설계가 중요해짐. Anthropic에서 정의한 5가지 핵심 디자인 패턴을 분석하고 정리함.특징: 하나의 LLM 출력이 다음 LLM의 입력이 되는

📌 개요 Multi-Agent 시스템에서 여러 에이전트를 조율하고 실행하는 Planning Agent를 구현했음. 이번 구현에서는 두 가지 접근 방식을 비교함: PlanningAgent: 사전 정의된 순차적 워크플로우를 따르는 정적 에이전트 AutonomousPl

거대 모델을 전체 튜닝하기에는 자원 소모가 너무 큼. 이를 해결하기 위해 QLoRA(Quantized Low-Rank Adaptation)를 도입함.Freeze: 기존 모델의 가중치($W_0$)를 4비트 양자화 상태로 고정하여 메모리 점유율을 최소화함.Adapter:

SpringAI 를 활용하여 문서를 기반으로 답변하는 챗봇을 만드는 과정 정리. 🧠 RAG 구조 간단 정리 RAG는 크게 두 단계로 나뉘어져 있다. Retrieval (검색): 질문과 관련된 문서를 벡터 검색을 통해 가져옴 Generation (생성): 검색된

최근 LLM을 개발하고 활용하는 추세가 빠르게 확산되고 있다. Spring AI는 LangChain과 같이 이러한 LLM을 보다 쉽게 사용하도록 돕는 라이브러리. 이러한 흐름과 함께, Spring Boot 환경에서 Spring AI를 활용하면 LLM 기능을 간편하게 통

수정이나 삭제 등의 비즈니스 로직을 구현할 때, 엔티티의 소유자를 확인하고자 하는 로직을 작성해야할 때가 있습니다.이런 경우에 서비스 코드마다 유저가 소유자인지 확인하는 코드를 써야 합니다.아래에 보이는 코드는 짧을 지 모르지만, 서비스 코드마다 중복된 검증 로직이 들

기존 프로젝트에서 작성했던 Dockerfile을 통해 이미지를 빌드하면 속도 저하 및 많은 용량에 대한 문제가 있어, 그에 대한 해결을 공유하고자 합니다.프로젝트에 대한 구성은 아래의 글에서 확인할 수 있습니다.\[Github Actions + Docker + EC2]

현재의 개발에서는 지속적 배포(Continuous Deployment, CD)를 통해 빠르고 안정적인 서비스 제공이 필수가 되었습니다. 특히, MSA(Microservices Architecture)를 채택한 프로젝트에서는 각 서비스의 독립성과 배포 효율성을 극대화하는

내일배움캠프 스프링 심화 1기를 수료하고 그에 대한 저의 개인적인 후기를 공유하고자 합니다~!저는 컴퓨터과학과를 전공한 후, 졸업하고 1년 동안 혼자서 방향을 잡지 못하고 방황했습니다. 개발 공부를 하긴 했지만, 체계적인 학습이 부족하여 실질적인 기술을 쌓는 데 어려움

진행 중인 MSA 프로젝트에서 각 서비스 모듈에 대해 Docker를 활용한 CI/CD 파이프라인을 구축하던 중 Docker 환경 구축에 관련된 몇 가지 문제를 겪었습니다. 이를 해결하는 과정을 공유하고자 합니다.프로젝트가 멀티모듈 구조로 되어 있어서, 서비스 모듈별로

프로젝트를 진행하면서, 여러 팀원과 환경을 맞추기 위해 편리하게 docker 를 설정 후 실행하고 있었다.그런데, 어느 날 잘 실행되던 docker 가 안되는 것이다...!아래 사진은 에러 내용이다.내용을 살펴보면, docker를 2181 port 로 binding 하

프로젝트 진행 중, 컨트롤러에 대한 단위테스트를 하기 위해 Mockito 와 WebMvcTest 를 이용해 테스트를 작성하고 있었다.현재 프로젝트는 여러 멀티모듈로 이어져 있고, application 에서 다른 모듈의 component 도 scan 하고 있어서 Spri