1. 구성하게 된 이유 AI Agent를 구현하면서 Tool 목록을 정리하다 보니, 먼저 Agent가 조회하고 활용할 수 있는 데이터가 준비되어 있어야 한다고 판단했다. 이를 처리하는 방법은 크게 두 가지였다. 요청 시점마다 블로그 글을 직접 탐색하는 방식 배치 작업으로 미리 데이터를 수집하고 적재해 두는 방식 이번 프로젝트는 실...

1. PostgreSQL + pgvector 환경 구성 블로그 QA AI Agent 서비스 에서는 블로그 원문, 메타데이터, 요약 정보는 RDB에 저장하고 임베딩 벡터는 Vector DB에 저장하는 구조로 구성하려고 한다. 초기 단계에서는 별도의 Vector DB를 두기보다는 PostgreSQL + pgvector 확장을 사용해서 하나의 DB에...

1. AI Agent에서 Tool이 필요한 이유 이전 글에서는 LLM을 Port / Adapter 구조로 연결했다. 현재 구조에서는 LLM문자열을 입력 받고 문자열을 생성하는 것만 가능하다. 하지만 우리가 AI Agent로 하려는 것들은 단순한 챗봇이 아닌 외부 기능을 사용할 수 있는 AI Agent이다. 예를 들어 내가 구현하려는 서비스는 ...

1. LLM 연결하기 진행하는 프로젝트에서는 AI Agent를 확장 가능한 구조로 만들고 싶었기에 Hexagonal Architecture를 기반으로 구현하려고 한다. 그런 관점에서 볼때 LLM은 외부 시스템에 해당하기 때문에 도메인 로직에서 직접 호출하지 않고 Port / Adapter 구조로 분리하여 구현되어야 한다. 이렇게 구조를 나누는...

1. 왜 직접 만들어보려고 했는가 AI Agent 란? 새로운 기술을 이해할 때, 개념을 오래 붙잡고 있기보다는 전체 구조를 빠르게 훑어보고 직접 구현하면서 익히는 방식이 더 잘 맞는 편이다. 그래서 이번에는 AI Agent라는 주제를 정하고, 단순한 개념 정리가 아니라 실제로 동작하는 Agent를 단계별로 만들어 보면서 구조를 이해...

0. 알아보게 된 이유 대부분의 자료에서 DDD를 설명할 때 함께 등장하는 구조가 있는데 Hexagonal Architecture Clean Architecture Layered Architecture 같은 아키텍처 스타일이 있다. 특히 ``Hexagonal Architecture는 DDD와 같이 설명되는 경우가 많았고, 도메인...

0. 알아보게 된 이유 Aggregate를 나누고 나면 다음으로 고민하게 되는 것은 비즈니스 로직을 어디에 둘 것인가? 이다. 현실 세계에서는 Aggregate만으로 해결되지 않는 요구사항들이 다수 존재하기 때문이다. 처음에는 모든 로직을 Entity에 넣으려고 하거나, 반대로 Service로 퉁쳐서 넣어버리는 경우가 많다. 하지만 DDD에서는...

0. 알아보게 된 이유 도메인 모델을 설계할 때 객체를 단순히 클래스 단위로 나누는 것이 아니라 의미 있는 기준으로 나누어야 한다는 것을 알 수 있다. 하지만 실제로 설계를 하다보면 객체 하나만 존재하는 경우는 거의 없고 여러 개의 객체가 서로 관계를 가지면서 하나의 기능을 구성하게 된다. 이때 객체를 각각 따로 관리하면 일관성이 깨지...

0. 알아보게 된 이유 이전 글에서 Bounded Context를 통해 도메인을 여러개의 경계로 나누는 이유에 대해 정리했다. Context를 나누었다면 이제는 Context내부에서 어떤 기준으로 모델을 설계할 것인지가 중요해진다. DDD에서는 도메인 모델을 구성할 떄 모든 객체를 동일하게 취급하지 않는다. 객체의 성격에 따라 식별자가...

0. 알아보게 된 이유 이전 글에서 DDD에서 중요한 개념 중 하나인 Ubiquitous Language에 대해 정리했다. 유비쿼터스 언어를 통해 이해관계자들이 같은 의미의 용어를 사용하도록 맞출 수 있지만, 실제로 시스템이 커질수록 하나의 언어만으로 모든 영역을 설명하는 것이 어려워진다. 업무 영역이 커지면 같은 단어라도 서로 다른 의미로 사...