타임트리

PostgreSQL 컨테이너가 172.17.0.3이라는 가상 IP를 가지고 있고, 내부적으로 5432 포트에서 PostgreSQL 서비스를 제공하고 있다고 가정하자. 외부에서 이 컨테이너에 접속하려면 다음과 같은 단계를 거쳐야 한다:외부 클라이언트 → 내 PC(서버)의 IP에 접근할 수 있어야 한다.내 PC에서 받은 요청을 컨테이너의 5432 포트로 전달해줘야 한다.1번을 위해서는 공유기나 라우터에서 공인 IP의 특정 포트를 내 PC의 포트로 포트포워딩해야 한다.2번은 도커에서 -p 옵션을 통해 호스트와 컨테이너 간 포트 매핑(port binding) 을 설정함으로써 해결할 수 있다.예를 들어 아래와 같은 명령어로 컨테이너를 실행한다고 하자:docker run -p 3001:5432 postgres 이렇..

도커는 컨테이너 간/외부와의 통신을 위해 가상 네트워크를 사용한다. 가상 네트워크는 물리적인 네트워크 장비 없이, 하나의 서버 내에서 논리적으로 정의된 네트워크이며, 이 네트워크 망안에서 컨테이너들끼리 서로 통신하거나 외부의 서버와도 통신할 수 있다. 도커를 설치하면 기본적으로 가상의 브릿지 네트워크인 docker0가 자동으로 생성한다. 이 가상의 라우터/공유기 역할을 하는docker0 브릿지는 172.17.0.1의 가상 IP 주소를 할당 받는다. (보통 공유기가 192.168.0.1의 사설 IP를 할당 받듯이). 그리고 컨테이너가 실행될 때, 이 브릿지 네트워크 범위 내에서 고유한 IP 주소를 자동으로 할당한다. 예를 들어, 컨테이너 A를 실행하면, docker0의 네트워크의 주소 범위에서 A에게 IP..

FastAPI에서 알아보는 동기와 비동기 처리의 차이FastAPI를 통해 동기(Synchronous)와 비동기(Asynchronous) 처리의 차이점에 대해 알아보자. 실제 코드 예제와 함께 이 두 가지 처리 방식의 동작 원리를 자세히 살펴본다.동기와 비동기의 기본 개념동기 처리 (Synchronous)여러 개의 스레드를 사용하여 작업을 병렬(Parallelism)로 처리각 요청마다 새로운 스레드가 할당됨→ FastAPI에서는 def로 정의하면 호출 시 내부적으로 ThreadPoolExecutor를 활용해 관리되어 여러 스레드에 동시 처리 가능 (병렬성)비동기 처리 (Asynchronous)단일 스레드에서 이벤트 루프를 통해 동시성(Concurrency)을 구현I/O 작업 중에 다른 작업을 처리할 수 있..

최근 LangGraph를 활용하여 멀티 에이전트를 구축하는 사례가 증가하고 있다. 이를 어떻게 배포하는 게 좋을까 구글링을 해보면 대부분  streamlit 등을 이용한 방법이 나온다. 그런데 이를 실제 서비스로 제공하기 위해서는 백엔드와 프론트엔드가 분리된 구조에서 배포하는 방법을 이해하는 것이 중요하다. 이번 글에서는 FastAPI를 활용하여 LangGraph 애플리케이션을 서빙하고, Docker를 이용해 손쉽게 배포하는 방법을 다룬다.1. 프로젝트 구조프로젝트의 디렉토리 구조는 아래와 같다../├── Dockerfile├── graph.png├── main.py├── requirements.txt├── graph│ ├── edges.py│ ├── graph.py│ └── nodes.py└..

LangGraph 글 중 [LangGraph] 요구사항 연속적으로 수집하기 (prompt generation) 를 FastAPI로 스트리밍 방식으로 서빙해보려다 문제가 발생해서 한참 헤맸다.  위 구조에서 information_gather 노드는 Pydantic model로 정의된 tool의 4가지 변수를 모두 채울 때까지 사용자에게 재질문하고, 모든 정보를 획득했다면 도구를 호출한다. 즉, 해당 노드는 일반적인 답변(content)을 뱉을 수도 있고, tool_calls를 반환할 수도 있는 상황이다. 먼저 일반적인 답변을 뱉는 상황을 살펴보자. (gather_chain은 이전 글 참조)from langchain_core.messages import HumanMessagemessages = [HumanM..

사용자 요구 사항 기반으로 메타 프롬프트 생성하기이번에는 프롬프트를 생성하도록 돕는 챗봇을 만들어보자. 챗봇은 먼저 사용자로부터 요구사항을 수집한 뒤, 이를 바탕으로 프롬프트를 생성하고 사용자 입력에 따라 이를 수정한다. 이 과정은 두 개의 별도 State로 나뉘며, LLM이 State 전환 시점을 결정한다.핵심은 반복적으로 사용자에게 질문을 하여 사전에 정의한 요구사항을 모두 수집한다는 점! 이 개념은 사용자로부터 수집해야 하는 정보가 필요한 서비스의 경우로 확장 가능하다. 예를 들어, LLM 기반 검색 시스템을 구축할 때 필요한 요구사항 수집 등에서 유용하게 사용될 것 같다. 만약 다양한 회의록을 검색하는 챗봇을 구축한다고 가정해보자. 이때 정확한 회의록을 찾기 위해서는 회의가 진행된 연도, 부서, ..

Adaptive RAG일반적인 RAG (흔히 말하는 Naive RAG 혹은 Advanced RAG)의 경우, 개발자가 전체적인 흐름을 정의하게 된다. 그리고 해당 흐름은 고정되어 있다. 아래와 같은 그래프의 경우 일반적인 RAG의 흐름이다. 아래 흐름에서는 우선 문서를 검색해서 가져온다. 그리고 문서의 연관성을 판단한 뒤, 만약 질문과 연관있는 문서가 retrieve되지 않았다면, 쿼리를 재작성하고 새로 작성된 쿼리로 문서를 가져온다.  다시 생각해보면, 위 흐름은 고정되어 있기 때문에 질문이 들어오면 해당 질문을 토대로 무조건 문서를 가져오게 된다. 즉, 벡터스토어로부터 문서를 검색하는 선택지 이외의 web search가 필요한지 여부 혹은 바로 LLM의 답변이 필요한지 여부는 고려하지 않는다. 이럴 ..

Agentic RAG 일반적인 RAG (흔히 말하는 Naive RAG 혹은 Advanced RAG)의 경우, 개발자가 전체적인 흐름을 정의하게 된다. 그리고 해당 흐름은 고정되어 있다.  아래와 같은 그래프의 경우 에이전트를 사용하지 않은 RAG의 흐름이다. 아래 흐름에서는 우선 문서를 검색해서 가져온다. 그리고 문서의 연관성을 판단한 뒤, 만약 질문과 연관있는 문서가 retrieve되지 않았다면, 쿼리를 재작성하고 새로 작성된 쿼리로 문서를 가져온다.   다시 생각해보면, 위 흐름은 고정되어 있기 때문에 질문이 들어오면 해당 질문을 토대로 무조건 문서를 가져오게 된다. 즉, 벡터스토어로부터 문서를 검색하는 선택지 이외의 web search가 필요한지 여부 혹은 바로 LLM의 답변이 필요한지 여부는 고려..