컨텍스트 스위칭은 흐름을 끊습니다. AI 어시스턴트가 프로젝트 도중에 중단되면, 다음 세션은 아무런 정보 없이 처음부터 다시 시작해야 합니다. 저장소 구조에 대한 기억도, 어떤 포트가 활성화되어 있는지도 알지 못합니다. 어제 Monero RPC에 문제가 있었다는 사실조차 인지하지 못합니다. Daniel Ioni는 투박하지만 유용한 것을 만들었습니다. AI 시스템이 별도의 도움 없이 MyZubster Gateway 작업을 재개할 수 있도록 작성된 기술 가이드입니다. 이는 지속적인 합성 메모리(persistent synthetic memory) 역할을 합니다. 원본 소스 코드를 통째로 쏟아붓는 대신, 기계가 시스템을 운영하고, 장애를 해결하며, 파괴적인 변경을 수행하기 전에 운영자의 권한을 존중하는 방법을 가르칩니다.
MyZubster이 실제로 구축하는 것
MyZubster Gateway는 실물 자산 토큰화(real-world asset tokenization)를 중심으로 구축된 탈중앙화 마켓플레이스입니다. 쉽게 말해, 물리적 또는 전통적 자산이 정의된 메타데이터 및 소유권 규칙과 함께 온체인으로 이동할 수 있게 해주는 인프라입니다. 이 플랫폼은 대체 가능한 자산(fungible asset) 토큰화를 처리하며, 이는 자산을 분할, 거래 및 추적할 수 있고 각 단위에 표준화된 메타데이터가 첨부됨을 의미합니다.
설계의 중심에는 프라이버시가 있습니다. 거래는 Monero에서 결제됩니다. 프로그래밍 가능한 자산과 NFT는 Tari에서 실행됩니다. 전체 운영은 Tor Onion Service 뒤에 숨겨져 있어, 게이트웨이가 검열 및 지리적 차단에 저항할 수 있게 합니다. 보안 계층은 Kali Linux에서 실행되며 DeepSeek AI 보안 봇을 사용합니다. 이는 단순한 로그 로테이션보다는 자동화된 침입 탐지 또는 이상 징후 스캐닝을 시사합니다. 에스크로 및 분쟁 해결은 수동 백오피스 작업이 아닙니다. 거래 조건이 충돌을 트리거할 때 AI가 중재하는 자동화된 방식입니다.
이것은 표면적인 모습일 뿐입니다. 그 이면에는 RPC 엔드포인트, 로컬 데이터베이스, 그리고 동기화가 유지되지 않으면 마켓플레이스의 거래 정산이 중단되는 Node.js 프로세스들이 얽혀 있습니다.
기술 스택과 그 중요성
게이트웨이는 3002번 포트에서 대기합니다. 이것이 정문입니다. Monero의 wallet RPC는 localhost:18083에 위치하여, 사용자 데이터를 공개 체인 분석에 노출하지 않고 개인 지갑 작업, 잔액 조회 및 출금 이체를 처리합니다. Tari의 RPC는 localhost:12820에서 응답하며 프로그래밍 가능한 자산 계층을 관리합니다. 이 엔드포인트 중 하나라도 어긋나거나 중단되면 마켓플레이스는 즉시 멈춥니다.
MongoDB는 운영 데이터 저장소로서 백그라운드에서 작동합니다. Node.js는 게이트웨이 서비스 자체를 구동합니다. 프론트엔드 코드는 ~/myzubster-frontend라는 전용 디렉토리에 있습니다. 이는 전형적인 탈중앙화 스택입니다. 결제를 위한 블록체인 노드, 상태 관리를 위한 로컬 데이터베이스, 상호작용을 위한 얇은 웹 계층이 모두 프라이버시 도구로 감싸져 있습니다. 여기에 장식적인 요소는 없습니다. 모든 포트와 경로는 시스템을 독립적이고 방어 가능하게 유지하기 위해 선택되었습니다.
시스템 실행하기
게이트웨이를 시작하는 것은 단 하나의 systemd 명령어로 가능합니다: systemctl start myzubster-gateway. 관리되지 않은 재부팅 후 서비스가 조용히 실패하기 전까지는 이 작업이 사소하게 들릴 것입니다. 그럴 때는 journalctl -u myzubster-gateway -n 50 --no-pager를 사용하여 페이지 노이즈 없이 마지막 50줄의 로그를 가져와야 합니다. 보통 그 50줄 안에 답이 있습니다. Monero RPC가 연결을 거부했을 수도 있고, 시스템 업데이트 후 MongoDB가 다시 온라인 상태가 되지 않았을 수도 있습니다.
보안 봇은 /root/security_bot.py에 있으며 python3 /root/security_bot.py로 실행됩니다. 보안 스크립트를 root 권한으로 실행하는 것은 일반적인 서버에서는 하지 않는 일입니다. 하지만 모니터링과 자동 대응에 특화된 강화된 Kali 환경 내부에서는 운영 모델에 적합합니다. DeepSeek AI 통합은 봇이 단순히 로그를 스캔하는 것 이상을 수행함을 의미합니다. 아마도 네트워크 동작이나 트랜잭션 패턴을 평가하여 침해 흔적을 찾고 있을 것입니다.
프론트엔드 작업의 경우, 이 가이드는 추측할 필요를 완전히 없애줍니다. AI는 정확한 위치를 알고 있습니다: cd ~/myzubster-frontend. /var/www, /opt 또는 여기저기 흩어진 홈 디렉토리를 뒤질 필요가 없습니다. 가이드는 이러한 경로를 정확하게 고정함으로써 일관성을 강제하며, 이는 여러 세션이나 서로 다른 AI 인스턴스가 몇 주에 걸쳐 동일한 서버를 다룰 때 매우 중요합니다.
문제가 발생했을 때
게이트웨이가 작동을 멈추면 가장 먼저 프로세스 정찰을 수행해야 합니다. ps aux | grep node를 실행하여 Node.js 프로세스가 여전히 살아있는지 확인하십시오. 프로세스가 사라졌다면 로그를 확인하십시오. 로그에 데이터베이스 연결 오류가 표시된다면 MongoDB가 원인입니다. systemctl start mongod로 다시 시작하십시오. 많은 탈중앙화 애플리케이션이 블록체인 노드를 취약한 구성 요소로 취급하지만, 실제로는 비정상적인 종료나 정기적인 패키지 업데이트 후에 로컬 MongoDB 인스턴스가 가장 먼저 문제를 일으키는 경우가 많습니다.
Monero RPC issues follow a different pattern. If balances stop updating or payout transactions hang in a pending state, the guide instructs checking monero-wallet-rpc status. That usually means verifying the wallet RPC process is running, confirming it synced to the correct daemon, and ensuring the authentication flags match what the gateway expects. Triage here is simple: blockchain settlement layer first, database second, application third. Ignore that order and you will chase ghosts in the Node.js logs when the real failure is a dead RPC port.
How the AI Should Use This Manual
The guide imposes four behavioral rules on the AI, and they reveal an understanding of how automated assistants fail in production environments.
First, reference specific sections. If the user is troubleshooting a payment failure, the AI should name the Monero RPC or escrow subsystem explicitly so the user knows exactly which pipe is leaking. Second, provide exact commands. Do not paraphrase flags or guess paths. Third, suggest the next logical step. Project recovery is a sequence; jumping randomly between port checks and security bots wastes minutes and risks making the problem worse. Fourth, ask for user confirmation before restarting services or deleting data. Autonomy is useful until it accidentally wipes a wallet cache or brings down the gateway during active trades.
A Living Document
This guide is explicitly designed to evolve. As the MyZubster project grows, the AI updates the document. That creates a feedback loop where operational experience becomes institutional memory. In a small team, or a solo project operating across time zones and sleep cycles, this replaces the watercooler knowledge that usually lives in senior engineers' heads. The document learns from every outage.
The Real Takeaway
AI project recovery guides like this one solve a specific, painful problem. They bridge the gap between raw documentation and contextual understanding. For MyZubster, that means the marketplace can survive context loss, reboots, and team transitions. The machine does not need to relearn the stack from scratch every time a new session starts. It just needs to read the manual, follow the exact commands, and know when to stop and ask.
Source: AI Technical Guide: MyZubster Project Recovery by Daniel Ioni
Optional learning community: GyaanSetu AI on Telegram