10월 29일(미국 시간), 바이낸스가 대규모 해킹을 당했어요. 바이낸스가 밝힌 피해 규모는 약 63억 달러이고, 그중 약 30억 달러는 동결해서 되찾을 가능성이 있다고 해요. 초기 조사에서는 엔지니어 한 명의 노트북이 뚫린 것이 시작이었다고 해요. 아직 조사 중이라

지난 9월 말, nDapp이 Orbit이라는 보상 프로그램을 열었어요. 정해진 Neo 앱을 쓰면 쓴 만큼 GAS를 나눠주는 방식이에요. 1회차 상금은 140 GAS였고, 10월 21일에 끝났어요.앱을 쓰려면 수수료를 내야 하잖아요. 그래서 궁금해졌어요. 수수료를 내고

2026년 여름은 Neo 생태계가 꽤 바빴던 시기였어요.N3에는 하드포크가 하나 지나갔고, 다음 하드포크에는 수수료를 100배 낮추는 변경이 들어가기로 했어요. Neo X는 이더리움 최신 업그레이드를 따라잡았고, SpoonOS에는 장기 메모리 같은 기능이 새로 들어왔어

Neo 생태계에는 체인이 두 개 있습니다. C그런데 지금까지 이 시리즈에서 브리지는 한 줄씩만 나왔어요. 22편에서는 "N3 주소와 Neo X 주소는 자동으로 연결되지 않는다"는 주의사항으로, 29편에서는 "상태 증명이 가장 가치 있는 곳은 크로스체인 브리지"라는 표의

이 시리즈에서 에이전트 지갑에 가드를 여러 겹 붙였습니다. 16편에서는 MAX_REFILL_GAS 상한을, 18편에서는 일정 금액 이상이면 Slack으로 사람 승인을 받는 게이트를, 24편에서는 예산 가드를, 26편에서는 후원 자격 가드를 만들었죠.그런데 이 가드들에는

스마트 컨트랙트는 인터넷을 모릅니다. 비트코인 가격도, 오늘 날씨도, 어떤 API의 응답도 컨트랙트 안에서는 직접 가져올 수 없죠. 모든 노드가 같은 결과를 내야 하는데, 노드마다 HTTP 요청을 보내면 응답이 달라질 수 있으니까요. 그래서 외부 데이터를 체인 안으로

지난 28편에서 Neo X의 후원(sponsored) 트랜잭션이 직접 보내는 트랜잭션보다 8.42배 비싸다는 걸 확인했습니다. 아무 일도 하지 않는 호출 하나에 체인이 태운 가스는 99,358인데, 청구된 가스는 179,169였죠. 원인은 고정 오버헤드였습니다. pre

계정 추상화(ERC-4337)로 남이 가스를 대신 내주는 트랜잭션을 보내려면 보통 준비물이 많다. 스마트 계정 컨트랙트를 배포하고, 팩토리를 고르고, 카운터팩추얼 주소를 계산하고, 서명 스킴을 맞춰야 한다. 그런데 Neo X에서는 그 전부가 필요 없다. EIP-7702

25편의 마지막에 이렇게 썼어요. "다음 글에서는 이 글에서 배선만 확인한 ERC-4337 경로를 실제로 태워볼 생각이에요. (…) 자격 심사를 통과하는 UserOperation과 떨어지는 UserOperation이 각각 어떻게 실패하는지 — 에이전트가 자기 가스를 안

"neo-mcp 듀얼체인"의 끝에서 "MCP 서버 프로세스가 죽었을 때 에이전트가 어떻게 반응하는지"를 다음 글로 미뤘고, "수수료 실측과 예산 가드"의 끝에서 같은 약속을 한 번 더 했어요. 이 글에서 그 빚을 갚습니다. spoon-core의 MCP 계층과 LLM 계

"neo-mcp 듀얼체인"에서 에이전트에 51개 도구를 붙였고, "OpenViking 메모리"에서 세션을 넘어 기억하게 만들었다. 두 글이 다룬 건 전부 읽기였다 — 조회는 아무리 많이 해도 공짜다. 그런데 (22)의 도구 목록에는 transfer_assets, cla

"프로덕션 배포"에서 에이전트를 컨테이너에 넣어 24/7 돌렸고, "DBOS 듀러블 워크플로우"에서 프로세스가 죽어도 진행 상태가 이어지게 만들었고, "LLM 백엔드 이중화"에서 모델 API가 죽어도 판단이 멈추지 않게 했다. 세 글을 다 적용한 봇은 잘 죽지 않는다.

"나만의 도구 붙이기"에서 BaseTool을 상속해 Neo N3 잔액 조회 도구를 손으로 만들었다. "MCP 서버 연동"에서는 Slack·GitHub·Notion 같은 남이 만든 MCP 서버를 에이전트에 꽂았다. 이 두 글 사이에는 계속 비어 있던 칸이 하나 있었다 —

"프로덕션 배포"에서 에이전트를 Docker로 24/7 돌렸고, "DBOS 듀러블 워크플로우"에서 프로세스가 죽어도 워크플로우가 이어지게 만들었다. 그런데 여기까지 해도 죽지 않는 단일 장애점이 하나 남아 있다 — LLM 프로바이더다. OpenAI가 429를 뱉기 시작

"나만의 도구 붙이기"에서 BaseTool을 상속해 Neo N3 잔액 조회 도구를 처음부터 한 줄 한 줄 짰다. 잘 작동했지만, 도구가 열 개, 스무 개로 늘어나면 매번 이 과정을 반복하는 건 지루하다. XSpoonAi가 공개한 spoon-awesome-skill 저장

"프로덕션 배포"에서 restart: unless-stopped로 죽으면 되살아나는 봇을 만들었다. 그런데 딱 여기까지다. 프로세스가 재시작되면 runner.py는 처음부터 다시 돈다 — 만약 크래시 시점이 "리필 트랜잭션을 이미 브로드캐스트했지만 컨펌을 기다리던 도중

에이전트는 결국 LLM이 "도구"를 골라 쓰는 루프다. 기본 제공 툴킷만 쓰면 남이 정해준 능력에 갇힌다. 진짜 재미는 내 도메인에 딱 맞는 도구를 직접 짜서 에이전트 손에 쥐여줄 때 시작된다. 이 글에서는 SpoonOS의 BaseTool을 상속해 Neo N3 지갑의

"Hello, Agent"에서 python agent.py로 첫 에이전트를 띄웠다. 콘솔에 답이 찍히면 성공이었다. 그런데 진짜 봇은 내 노트북이 잠들면 같이 죽으면 안 된다. 가스비가 떨어지면 알림을 보내고, 특정 조건이면 스왑을 실행하는 봇은 항상 켜져 있어야 의미

"NEO 7가지 이유"에서 NeoFS를 두고 "IPFS는 파일이 살아있다는 보장이 약하지만, NeoFS는 노드가 GAS로 보상받으며 저장을 보증한다"고 한 줄로 언급하고 넘어갔다. 그런데 그게 실제로 어떤 경험인지, 파일 하나를 올리고 URL로 받아보는 과정은 직접 해

경쟁 현황 보기: https://arena.spoonai.io/디스코드 캠페인 채널 참여: https://discord.gg/uqmPDQsq4JSpoonOS Arena는 8개의 주요 LLM이 2026 FIFA 월드컵의 모든 경기를 분석하고, 예측하며,