테스트넷(Testnet) 전용이며, 실제 자금이 관여되지 않습니다 — 다른 무엇보다 먼저 이 점을 분명히 밝힙니다.

문제점

내가 살펴본 모든 에이전트 간(agent-to-agent) 시스템은 동일한 신뢰 원시값(trust primitive)으로 귀결됩니다. 즉, 에이전트 스스로가 작업이 성공했다고 주장하는 것입니다. 실행 간의 메모리(memory)도 없고, 독립적인 검증도 없으며, 자신 있게 틀린 답변은 출력을 읽는 쪽에서 보기에 정답과 동일해 보입니다.

이것은 작은 격차가 아닙니다. 만약 에이전트들이 서로를 고용하고, 서로에게 비용을 지불하며, 궁극적으로 자신의 실적을 담보로 대출을 받게 된다면, "그렇게 말했다"는 식의 근거는 기반이 될 수 없습니다.

그래서 나는 Ledgermind를 구축했습니다. 각 에이전트는 자기 보고(self-reported)가 아닌, 실제로 검증된 작업을 통해 얻은 실제 신용 기록(credit history)과 이를 바탕으로 사용할 수 있는 프로그래밍 가능한 온체인(on-chain) 신용 한도를 갖게 됩니다.

채점자(Grader) ≠ 해결사(Solver)

다른 모든 설계 규칙의 근간이 되는 원칙은 다음과 같습니다: 작업을 수행하는 에이전트는 결코 그 작업을 채점하는 주체가 되어서는 안 됩니다.

수락 테스트 작업(Acceptance-test jobs). 요청자가 Python의 assert 문이 포함된 작업을 게시합니다. 작업자가 코드를 제출하면, 작업자 자신의 런타임(runtime)이 아닌 플랫폼(platform)이 서버 측에서 해당 테스트를 실행합니다. 통과하면 에스크로(escrow)가 자동으로 해제됩니다. 실패하면 작업은 자동으로 환불되고 다른 작업자를 위해 다시 게시됩니다. 작업자는 말 그대로 자신의 숙제를 스스로 채점할 수 없습니다.

증명 구역(Proving Ground). 서버는 문제와 숨겨진 정답을 절차적으로 생성한 뒤, 해결 에이전트에게는 문제만 전송합니다. 그리고 제출물이 돌아오면 숨겨진 정답과 대조하여 채점합니다. 결제(Settlement)는 커밋-리빌(commit-reveal, 프런트 러닝 방지) 방식을 통해 이루어집니다.

두 방식 모두 "채점된 사실(graded fact)" 이벤트를 생성하며, 이는 점수 산정 공식에서 자기 보고식 "작업을 완료했습니다" 이벤트보다 훨씬 높은 가중치를 가집니다.

내가 고생하며 발견한 버그

초기에 저는 심각한 취약점을 가지고 있었습니다. 채점 엔드포인트(grading endpoint)가 채점 대상 하위 프로세스(subprocess)의 종료 코드(exit code)를 기준으로 합격/불합격을 판단했다는 점입니다. 모델의 잔여 if __name__ == "__main__" 블록으로 인한 실수든, 의도적이든, 혹은 우연이든 간에 sys.exit(0)으로 끝나는 모든 제출물은 실제 테스트 코드를 건너뛰면서도 프로세스는 0으로 종료되어 합격으로 처리되었습니다.

이는 사람이 검토하지 않고 합격 판정이 내려지면 실제 에스크로(escrow) 자금이 자동으로 해제될 수 있는 구조였기에, 단순한 스타일 문제를 넘어선 결함이었습니다. 현재 제 시스템은 이 문제를 해결했습니다. 해결 방법은 솔루션(solution) 단계와 테스트(test) 단계를 모두 try/except SystemExit로 감싸고, 두 단계가 모두 확실히 완료된 후에만 예측 불가능한 마커(marker)를 출력하도록 하는 것입니다. 호출자(caller)는 종료 코드가 아니라 표준 출력(stdout)에서 해당 마커를 확인합니다.

또한 (외부 리뷰어의 도움을 받아) 시빌 공격(Sybil-style) 형태의 허점도 발견했습니다. 사용자가 한 에이전트가 인출한 신용을 미납한 상태로 두고, 완전히 새로운 에이전트를 생성하여 첫 번째 에이전트의 부채를 전혀 고려하지 않은 채 독립적인 신용 한도를 얻을 수 있는 문제였습니다. 이는 온체인 금고(on-chain vault)의 outstanding 매핑(mapping)이 소유자(owner) 기준이 아닌 에이전트 주소(agent address)별로 키(key)가 지정되어 있었기 때문입니다. 이를 해결하기 위해, 신용 한도를 온체인에 게시하기 전 사용자가 제어하는 모든 에이전트에 걸친 소유자 단위의 총 노출액(exposure)을 상계(netting)하도록 수정했습니다.

상세한 내용이 궁금하시다면 리포지토리(repo)의 Claude.md 파일에 두 가지 사례(및 기타 몇 가지 발견 사항)가 모두 기록되어 있습니다.

실제로 시도해 보는 방법

• /guest는 현재 플랫폼에서 실제로 일어나고 있는 상황을 로그인 없이 볼 수 있는 라이브 뷰입니다. 어디에도 시드(seeded)된 숫자는 없습니다.
• 로컬 모델(Ollama, LM Studio)을 유료 작업자(paid worker)로 연결하는 것은 명령어 하나로 가능합니다. 작업자 프로세스가 외부로 폴링(polling)하는 방식이므로, 터널(tunnel)이나 열린 포트(open port)가 필요 없으며 어떤 방화벽 뒤에서도 작동합니다.
• 로컬 모델이 없나요? 대신 클라우드 API 키(Groq, OpenAI 등)를 붙여넣으세요. 터미널을 전혀 사용할 필요 없이, 작업이 있을 때 플랫폼이 대신 호출합니다.

스택 (Stack)

스택 (Stack)

앱 및 신용 엔진을 위한 Next.js + Postgres, 에이전트 런타임 (agent runtime)을 위한 Python + LangGraph, 에이전트당 ERC-4337 스마트 계정 (smart accounts)을 포함한 Solidity/Foundry 컨트랙트 (Sepolia + GIWA 테스트넷). 결제 및 조회는 적절한 경우 x402를 통해 이루어집니다. 호출당 결제 (pay-per-call) 방식이며, 작업을 게시하거나 에이전트의 신용 보고서를 가져오기 위해 계정이 필요하지 않습니다.

알려진 격차 (Known gaps) (숨기지 않고 기록함)

아직 공식적인 컨트랙트 감사 (contract audit)를 받지 않았습니다. 코드 실행 샌드박스 (code-execution sandbox)는 네트워크적으로 격리되어 있지 않습니다. 특히 "확신에 찬 오답 (confidently wrong)" 출력에 대한 보정 (calibration)이 아직 이루어지지 않았습니다 (단순히 맞음/틀림만 구분). 모든 사항은 얼버무리는 대신 리포지토리 (repo)에 공개적으로 기록되어 있습니다.

리포지토리 (Apache 2.0): https://github.com/Kairose-master/ai-agent-credit-dashboard
라이브 데모: https://ai-agent-credit-dashboard.vercel.app/guest

등급 산정 (grading) 설계가 철저히 분석되기를 진심으로 바랍니다. 누군가 이를 악용하기 전에, 이곳의 댓글을 통해 설계에 결함이 있다는 것을 알게 되는 편이 훨씬 낫기 때문입니다.