Real Estate Investment MCP Server

동기

LLM은 시스템 내 환경과 어떻게 상호 작용할까요? 그렇지 않습니다. 호출 및 응답 API입니다. 에이전트에 대한 이런저런 이야기를 계속 듣지만, 환경을 관찰하거나 조작할 수 있는 도구가 없다면 에이전트는 우리가 중요하게 생각하는 의미 있는 작업을 수행하는 데 근본적으로 제약을 받는 것 같습니다.

새로운 유행어를 처음 열 번쯤 보면 최대한 무시하려고 애쓰지만, 모델 컨텍스트 프로토콜(MCP) 이 계속 등장하자 그 의미를 파악하기 시작했습니다. 도구와 리소스의 존재와 사용 방법을 알리는 일관된 형식을 제공함으로써 문제를 깔끔하게 해결했습니다. LLM을 도구나 데이터베이스에 연결하는 새로운 커넥터를 구축해야 할 때는 미리 구축된 오픈 소스 MCP 서버를 찾아 바로 사용할 수 있습니다. MCP는 업계 주요 기업 중 하나인 Anthropic 이라는 기업 스폰서가 유지 관리하고 있어 처음부터 (개밥처럼) 시험적으로 개발되었고, 오래 사용할 수 있도록 설계되었습니다.

계획

저는 실제 문제를 해결하면서 새로운 것을 스스로 배우는 것을 좋아합니다. 그렇게 하면 결과가 머릿속에 더 잘 남거든요. 검색 증강 생성(RAG) 관련 작업을 많이 해왔고, 그중 상당 부분을 오픈 소스로 공개할 준비를 하고 있습니다. MCP가 RAG 아키텍처의 차세대 진화라고 생각합니다. 가까운 미래에 RAG를 잘 활용한다면 MCP를 기반으로 하는 것이 될 거라고 생각합니다.

최근 부동산 투자에 대해 알아보고 있는데, 향후 1~2년 안에 시장 조정이 있을 것으로 예상됩니다. 무료 Zillow 데이터를 데이터베이스에 업로드한 후 MCP 서버를 실행할 예정입니다. 그런 다음 MCP 서버에 연결하여 htmx UI의 요청을 처리하는 FastAPI 서버를 실행할 것입니다. 최종 목표는 이 부동산 데이터를 탐색하고 어떤 시장에서 거래를 찾을지 결정하는 데 도움이 되는 채팅봇을 만드는 것입니다.

내가 로드할 데이터는 다음과 같습니다.

• Zillow 주택 가치 지수(ZHVI) – 65~95 백분위수 내 특정 지역 및 주택 유형의 일반적인 주택 가치를 측정한 지표입니다.
• Zillow 주택 가치 예측(ZHVF) – 현재 및 과거 시장 데이터를 기반으로 한 미래 주택 가치 추세 추정치입니다.
• Zillow 관찰 임대료 지수(ZORI) – 현재 및 비시장 임대 매물에서 관찰되는 일반적인 시장 임대료를 평활화한 측정값입니다.
• Zillow 관찰 임대료 예측(ZORF) – ZORI와 시장 지표의 추세를 기반으로 한 임대료 가격의 예상 변화입니다.

ZHVI 데이터는 제외했는데, 그 이유는 데이터가 부족하기 때문입니다. 최근에야 이를 추적하기 시작했거든요.

이건 특정 분야에만 국한된 데이터입니다. 정의를 읽지 않고 데이터에 대해 추측하는 건 바람직하지 않을 겁니다. LLM이 사소한 문제를 직관적으로 해결할 수 없기 때문에 이게 좋은 예가 될 거라고 생각합니다.

LLM에게 저렴한 주택과 임대료, 현금 흐름, 그리고 높은 미래 성장률이 균형 있게 고려된 시장을 찾는 데 도움을 요청하고 싶습니다. 이 예상 성장률을 당연하게 여기고 싶지도 않습니다. 어떤 지역에서 얼마나 자주, 그리고 어떤 지역에서 예측이 정확한지 확인하기 위해 간단한 프로그래밍을 해 보겠습니다. 다양한 쿼리를 작성하려면 상당한 프롬프트 엔지니어링이 필요할 것으로 예상합니다. 그러면 이 프롬프트들을 MCP 프롬프트로 저장하여 챗봇에 제안하고 데이터베이스에서 실행할 수 있을 것입니다.

로컬 파일에 메모리를 저장하기 때문에 SQLite를 데이터베이스로 선택했습니다. 따라서 데이터베이스를 다시 로드하거나 업/다운할 필요가 없습니다. 이식성을 위해 컨테이너에서 데이터베이스를 실행할 예정이므로, 데이터베이스 상태를 파일에 저장하면 원하는 경우 "캐시된" 데이터 로드로 처리할 수 있습니다. 이렇게 하면 로컬 볼륨에 마운트하는 경우 컨테이너를 재시작할 때마다 Zillow 데이터를 데이터베이스에 다시 로드할 필요가 없습니다.

이 데이터와 통신하려면 방금 작성한 테이블에 대해 쿼리를 실행할 수 있는 일종의 MCP 서버를 작성해야 한다는 것을 알고 있습니다. 지금까지 읽은 바에 따르면 유용한 쿼리를 MCP 프롬프트 또는 도구로 인코딩하여 MCP 클라이언트 뒤에 있는 LLM에 제시하고 싶지만 실제로 어떻게 될지 아직 잘 모르겠습니다. langchain의 이 문서 와 내가 읽은 몇 가지 다른 내용을 섞어서 빌드할 수 있는 스타터 서버로 시작하고 있습니다. 그런 다음 MCP 클라이언트의 시작 부분을 작성하기 위해 주로 Anthropic 문서를 따랐지만 많은 코드를 langgraph ReAct 에이전트로 바꿨습니다. 그런 다음 클라이언트와 서버가 서로 통신하는 방법을 확신하지 못해서 MCP에 내장된 다양한 전송 방법에 대해 설명하는 정말 훌륭한 MCP 문서를 찾았습니다. stdio를 사용하여 클라이언트와 서버 간에 진행 중인 메시지를 전달하는 기본 방법을 사용하겠습니다. 로컬 데이터베이스와 앱 백엔드를 포함하는 단일 컨테이너이므로 이는 타당해 보이지만, 프로덕션급이라면 MCP 서버가 백엔드와 분리되어 더 복잡한 HTTP 스트리밍 구성이 필요할 것으로 예상됩니다. 이 부분은 업무용으로 이와 유사한 기능을 구축해야 할 때 다시 다루겠습니다.

지금은 단일 메시지 생성을 위해 단일 스크립트를 실행하고 있습니다. 이 기능을 유용하게 사용하려면 사용자 쿼리를 받아 이러한 함수를 통해 실행하는 웹 서버를 연결해야 합니다. 웹 서버를 유용하게 만들려면 서버에 요청을 보내는 채팅 인터페이스처럼 보이는 프런트엔드가 필요합니다. 최근 이런 AI 프로젝트에 Streamlit이 큰 인기를 끌고 있으며, 이전 프로젝트 에서도 업무용 내부 도구로 사용해 봤지만, 느린 Python 코드에서 느린 React 코드를 실행하는 것은 Python에 배포해야 하는 전체 서버 코드를 필요로 하므로 가벼운 프런트엔드를 구축하는 최선의 방법이 아니라는 결론을 내렸습니다. 아무도 개념 증명(PoC)을 승인받은 후 제대로 된 프로덕션급으로 다시 작성하고 싶어 하지 않기 때문에, 종종 그런 일이 일어나지 않는 것 같습니다. 저는 Python의 중간 단계를 제거할 만큼 React를 꽤 많이 작성했지만, 정말 과하다고 느껴집니다. 풀스택으로 무언가를 만들 때마다 실제로 배우려고 했던 것보다 더 많은 프런트엔드 개발을 하게 됩니다. HTMX는 한동안 제 관심사였는데, 이번 프로젝트에서 한번 써보려고 합니다. 엄청나게 가볍고, 채팅 앱 같은 저논리 프런트엔드에 필요한 최소한의 기능만 제공합니다. 게다가 밈도 훌륭합니다 . 서버 선택에 영향을 미치는 유일한 요소는 템플릿 기반 HTML을 반환해야 한다는 점입니다. 그래서 jinja를 사용해서 웹페이지 템플릿을 만들고 HTMX 스크립트 태그와 함께 전송할 예정입니다. HTMX를 실행하는 데 필요한 건 이것뿐입니다. 정말 놀랍습니다.

에코 서버는 그다지 흥미롭지 않으니 LLM 에이전트를 추가해 보겠습니다. MCP 클라이언트를 FastAPI 서버의 라이프스팬에 추가하고 앱 상태에 바인딩하여 스레드로부터 안전하게 워커에게 전달될 수 있도록 했습니다. 클라이언트/서버가 풀링 기능을 지원하도록 설계되지는 않았지만요. 메시지를 에이전트에 전달하고 출력을 간단한 HTML 형식으로 구성한 후 UI로 다시 전달하면 됩니다.