아톨러브

세번째 코드는 MCP(Model Context Protocol) 서버와 MCP 클라이언트(LLM 에이전트)가 SSE(Server-Sent Events, HTTP 기반) 방식으로 네트워크를 통해 통신하도록 구현된 예제입니다. 이전 Stdio(표준 입출력) 방식과 달리, 서버와 클라이언트가 서로 별도의 프로세스/컴퓨터로 분리될 수 있는 웹 표준 서버 architecture 형태를 띱니다. 두 파일의 구조와 작동 원리를 핵심 위주로 명쾌하게 해설해 드리겠습니다.1. 시스템 구조 개요┌────────────────────────────────┐ HTTP GET/POST (SSE) ┌────────────────────────────────┐│ 첫 번째 파일: MCP Server ..

첫 번째 코드와 비교했을 때, 이번 코드는 질문 하나를 해결하기 위해 여러 도구를 연쇄적으로 판단하여 호출하는 에이전트 구조로 진화했습니다. 다단계 도구 호출(Multi-step Tool Calling) 및 자율적 루프(Autonomous Re-act Loop)를 구현한 대단히 완성도 높은 AI 에이전트 코드입니다. 1. 이 코드가 작동하는 전체 시나리오 (Chaining Process)사용자가 "현재 서울의 평균 기온을 계산해 줘."라는 질문을 보냈을 때 내부 동작 순서입니다. [사용자 질문] "서울의 평균 기온 계산해 줘" │ ▼ ..

OpenAI의 최신 Responses API와 Open-Meteo API를 활용해, 사용자의 질문에서 도시명을 추출하고 날씨 정보를 조회해 자연어로 변환해주는 Function Calling(도구 호출) 에이전트의 정석적인 구조입니다.전체적인 코드 흐름과 스키마 설계, 그리고 실제 동작 구조까지 핵심을 짚어 설명해 드립니다. 1. 전체 실행 흐름 (Execution Lifecycle)[사용자 질문] "서울특별시의 오늘 날씨 알려줘" │ ▼[1차 LLM 호출] client.responses.create() │ ──> LLM 판단: "직접 답할 수 없으니 get_weather 도구를 호출하자" ▼[도구 실행] get_weather(location="서울특별시") ..

결론부터 말하면:지금까지가 "ChromaDB 기반 장기기억의 기본 동작을 완성하는 과정"이었다면, 다음 단계가 이 학습 단계에서의 마지막 핵심 단계라고 보는 것이 좋습니다.다만 AI Agent의 장기기억 시스템 전체로 보면 이후에 중복 기억 방지, 기억 수정/삭제, 중요도 관리, PostgreSQL↔ChromaDB 불일치 복구 같은 고급 단계가 더 있습니다.그리고 저는 지금은 그런 고급 기능으로 바로 넘어가지 않고, 한 단계 더 정리해서 현재 시스템을 완성된 구조로 이해하는 것을 추천합니다.1. 우선 이번 테스트 결과를 해석해 봅시다이번 결과는 사실상 우리가 목표로 했던 것을 거의 모두 보여줬습니다.첫 번째 질문:"나는 앞으로 AI Agent 공부를 계속할 생각이야."에 대해서:LLM Memory Ext..

지금 구조를 보면:LLM이 Memory를 추출 → save_memory() → PostgreSQL 저장 → memory_id 확보 → save_memories()가 실제 저장 결과를 반환까지 검증됐습니다.이제 다음 단계는 자연스럽게 PostgreSQL에 저장된 새 Memory를 ChromaDB에도 넣는 것입니다. [요약]# PostgreSQL의 memories 테이블과 ChromaDB연결 단계(4.3) => agent_with_memory.py->PostgreSQL 저장 후 ChromaDB에도 저장하도록 연결 # step 1. agent_with_memory.py를 수정 # 1.1. from vector_store import add_memories 추가하기 # 1.2. run_once()의 마지막 부분..

지금 단계는 단순히 "코드가 실행되느냐"가 아니라,PostgreSQL에 저장된 Memory를 ChromaDB에도 정확히 전달할 수 있는 구조를 만드는 단계라고 이해하면 좋습니다.[요약]# PostgreSQL의 memories 테이블과 ChromaDB연결 단계(4.2) => memory.py -> save_memories()가 저장된 Memory 정보를 반환하도록 수정 # step 1. memory.py 에서 save_memories()만 수정 # step 2. 기 만들어 놓은, test_save_memories.py 실행해서 테스트1. 먼저 현재 memory.py의 전체 구조를 보겠습니다현재 구조는 크게 이렇게 되어 있습니다.memory.py│├─ 1. 환경 설정│├─ 2. OpenAI Client│├─..

현재 우리가 해결하려는 문제는 딱 하나입니다.새로운 Memory가 PostgreSQL에 저장될 때 생성된 memory_id를 받아서, 그 Memory를 ChromaDB에도 정확히 저장한다. [요약]# PostgreSQL의 memories 테이블과 ChromaDB연결 단계(4.1) => database.py -> PostgreSQL save_memory()가 생성된 memory_id를 반환하도록 수정 # step1. database.py에서 save_memory()를 찾아, 코드 교체하기(수정 코드 없음)# step2. test_save_memory.py 만들어서, 테스트오늘 진행할 범위전체 Dual Write는 다음 4단계입니다.STEP 7-1 database.py ↓ ..

현재 단계는 성공입니다. 특히 이번 결과는 단순히 "검색이 됐다"가 아니라, 지금까지 만든 장기기억 구조가 실제 Agent 안에서 연결되어 작동했다는 것이 중요합니다.그리고 질문하신 "이제 마지막 단계인가?"에 대해서는 이렇게 보는 것이 가장 정확합니다.지금까지의 진행 상황① PostgreSQL에 장기기억 저장 ↓② Memory 추출 기능 구현 ↓③ ChromaDB 구축 ↓④ PostgreSQL → ChromaDB 동기화 ↓⑤ ChromaDB semantic search 구현 ↓⑥ Agent가 ChromaDB 기억을 검색하여 답변에 활용 ← 지금 성공 ↓⑦ 새 Memory를 PostgreSQL + ChromaDB에 동시에 저장 ..

이제부터가 진짜 AI Agent의 장기기억 구조를 Agent에 연결하는 단계입니다.이번에는 서두르지 않고,① agent_with_memory.py가 현재 어떻게 되어 있는지 → ② 무엇이 문제인지 → ③ ChromaDB를 어떻게 연결하는지 → ④ 전체 코드를 수정 → ⑤ 테스트순서로 진행하겠습니다. [요약]# PostgreSQL의 memories 테이블과 ChromaDB연결 단계(3) # step1. agent_with_memory.py 전반적으로 수정(전체 파일 교체) # step2. memory.py의 build_memory_context() 코드 교체 # step3. 테스트(agent_with_memory.py 코딩) ===>python agent_with_memory.py 실행 ==..

전장의 테스트 결과는 정상입니다. 오히려 이번 결과에서 아주 중요한 것이 몇 가지 확인되었습니다.특히,PostgreSQL → Dictionary → ChromaDB → user_id 필터 → 의미 기반 검색이라는 우리가 만들고 있는 구조가 실제 데이터로 정상 동작하고 있습니다.이제 말씀하신 대로 다음 단계인 search_memory()의 ChromaDB 전환으로 넘어가겠습니다. [요약]# PostgreSQL의 memories 테이블과 ChromaDB연결 단계(2) # step1. memory.py 수정 # step1.1. from vector_store import search_similar_memories추가. # step1.2. search_memory() 코드 수정 # step1.3. def ch..