메타데이터
- 채널: aiDotEngineer (AI Engineer)
- 발표자: Armanas Povilionis (Alithea Bio)
- 원본 URL: https://www.youtube.com/watch?v=Fu45geO3zX8
- 처리일: 2026-07-19
- 태그: #AI에이전트 #프로토콜 #검증가능성 #라이프사이언스 #에이전트경제 #MCP #Froglet
1계층: 핵심 주장 및 논거 (상세)
발표자 Armanas Povilionis는 면역항암(immuno-oncology)·면역펩티도믹스(immunopeptidomics)를 다루는 라이프사이언스 회사 Alithea Bio에서 일하며, 스스로도 에이전틱 자동화를 활용하고 고객에게도 에이전트 AI 솔루션을 제공한다. 이 실무 경험에서 발견한 "갭(gap)"이 이 발표의 출발점이다.
핵심 주장: "에이전트에게 도구를 더 많이 주는 것만으로는 충분하지 않다(adding more tools to agents will not suffice)." 특히 과학, 그중에서도 라이프사이언스는 본질적으로 협업적(inherently collaborative) 프로세스이기 때문이다. 에이전트들이 협업하려면 **검증 가능한 영수증의 체인(a verifiable chain of receipts)**이 필요하다.
여기서 "영수증(receipt)"이 의미하는 바를 발표자는 명확히 정의한다:
- 모든 단계(every step)를 증명할 수 있어야 하고
- 모든 결과가 신뢰될 수 있어야 하며(every result can be trusted)
- 대규모 반복 가능성(repeatability)과 협업(collaboration at scale)을 가능케 해야 한다
논거 — 왜 "도구 추가"만으로 부족한가: 발표자는 에이전트를 주방의 요리사(cook)에 비유한다. 더 많고 좋은 도구(더 좋은 칼, 더 많은 팬, 더 많은 오븐)를 주는 것은 "그 주방 안에서의" 효율은 높이지만(local work), 과학 연구는 "내 주방에서 혼자 요리하는 것"이 아니라 미슐랭 스타 레스토랑을 운영하는 것에 가깝다고 말한다. 미슐랭 레스토랑의 성패는 재료 공급자와 그 품질, 고품질 서비스, 그리고 같은 퀄리티의 요리를 반복적으로 일관되게 만들어낼 수 있는 능력에 달려 있다 — 이 모든 것을 한 주방 안에 다 가져다 놓을 수는 없다. 즉 진짜 도전 과제는 로컬 도구가 아니라, 전체 공급망(supply chain)을 반복 가능하고 일관되게 정렬(align)하는 것이다.
현재 상태 진단: 오늘날 에이전트는 이미 풍부한 도구를 갖고 있고 그 양과 질이 계속 증가하고 있다. 동시에 데이터와 특화된 분석 알고리즘, 컴퓨트는 서로 다른 조직에 분산되어 사일로(silo)로 갇혀 있다.
미래 비전: 에이전트 워크플로우 자동화가 성숙하면, 조직들은 에이전트에게 도구뿐 아니라 **예산(budget)**을 줄 것이다. 지금도 특정 태스크에 토큰 예산을 할당하는 원시적 형태로 이런 일을 하고 있지만, 발표자가 말하는 것은 더 넓은 개념 — 에이전트가 자신의 목표를 달성하기 위해 스스로 예산을 관리하도록 허용하는 것이다. 서비스를 발견하고, 데이터를 요청하고, 실행 조건을 협상하고, 조직 경계를 넘어 작업에 대가를 지불하는 일까지 포함한다. 이 지점에서 에이전트는 더 이상 "더 좋은 칼을 든 요리사"가 아니라 셰프(chef) — 그것도 이그제큐티브 셰프처럼 행동하기 시작한다: 공급자를 찾고, 재료를 주문하고, 주방 내 작업을 조율하고, 마지막으로 일어난 일에 대한 기록을 남긴다.
이 비전을 구현하기 위해 만든 것이 Froglet — 에이전트가 외부 데이터·서비스 제공자를 발견(discover)하고, 거래(transact)하고, 검증 가능한 영수증(verifiable receipt)을 받을 수 있게 하는 오픈소스 프로토콜이다.
2계층: 주요 개념 설명 및 사례
Froglet의 설계 철학: "교체가 아니라 통합(integrate, not replace)"
Froglet은 이미 존재하는 무빙 파츠들 "사이(in between)"에 위치하도록 설계됐다. 결제 레일(payment rails), 에이전트 하네스(agent harnesses), 실행 환경(execution environments), 심지어 전송 프로토콜(transport protocols)까지 다양한 것들과 통합된다. 네트워크의 모든 노드가 동일한 소프트웨어 스택을 쓸 것을 요구하지 않는다 — 모두가 "같은 방식으로 일하게" 강제하는 게 아니라, 단지 "같은 인터페이스를 쓰도록" 요청할 뿐이라는 게 발표자가 강조하는 "아름다움(beauty)"이다.
폐쇄형 협업 vs Froglet: 비용 구조의 대비
발표자는 오늘날의 현실을 이렇게 요약한다 — 클로즈드 소스 기반 협업은 종종 "맞춤형(bespoke) 엔터프라이즈 프로젝트"로 변질되어, 재사용 가능한 워크플로우 하나가 나오기까지 수년과 수백만 달러가 든다. 반면 Froglet의 미션은 거래 계층(transaction layer)을 훨씬 가볍게 만드는 것이다. 한 조직이 데이터·리소스·서비스를 "공유 가능(shareable)"하다고 판단하고 Froglet에 노출시키면, 에이전트는 이를 발견하고, 조건을 이해하고, 작업을 요청하고, 검증 가능한 영수증을 받을 수 있다. 이 전체 셋업에 드는 비용은 토큰 몇천 개, 시간은 몇 분이라고 발표자는 말한다.
Froglet 노드의 구조: 역할은 다르지만 구현은 하나
핵심 개념 중 하나는 Froglet 노드가 사이트마다 다르게 구현되는 게 아니라 정확히 동일한 노드가 역할(provider/requester/marketplace)만 다르게 수행한다는 점이다. 마켓플레이스조차 특정 서비스들을 제공하는 하나의 Froglet 노드일 뿐이다. Froglet이 하는 일은 네 가지로 요약된다: 찾기(find), 신뢰하기(trust), 지불하기(pay), 그리고 일이 일어났음을 증명하기(prove). 발표자는 다른 도구나 프로토콜의 기능을 대체하려는 게 아니라고 명시적으로 강조한다.
검증 가능성의 메커니즘: 서명 체인
새 노드를 생성할 때마다 신원(identity)과 아티팩트 서명(signing artifacts)을 위한 키 페어(key pair)가 생성된다. 실행 과정에서 모든 것이 이 서명으로 체인 형태로 서명되며, 이 체인은 모든 데이터 포인트가 변조(tamper)되지 않았을 때만 유효(valid)하다 — 이것이 앞서 말한 "검증 가능한 영수증"의 기술적 기반이다.
발견(Discovery)과 직접 거래
제공자(provider)는 자신이 제공하는 서비스를 동일한 프로토콜로 마켓플레이스에 게시(publish)한다. 요청자(requester)는 알려진 마켓플레이스에 사용 가능한 서비스 목록을 요청한다. 요청자가 원하는 서비스를 특정하고 나면, 그때부터 통신은 직접(direct) 이루어진다 — 제3자 개입 없이, 견적(quote)부터 거래(deal), 실행(execution), 영수증(receipt)까지 모두 한 번의 상호작용(one interaction) 안에서 일어난다.
에이전트 연동: MCP 서버/플러그인
에이전트가 관여하는 지점은 Froglet 코어 내부에 배치된 플러그인들이다. 서로 다른 실행 환경과 하네스에 통합되며, MCP 서버나 플러그인으로 작동한다. 발표자가 강조하는 원칙: 인간을 위한 주 인터페이스는 LLM이어야 한다 — 제공자든 요청자든, Froglet 사용을 LLM이 주도해야 한다는 것이다.
라이브 데모 사례 — "7 + 5" 서비스 호출
발표자는 실제로 세 가지를 시연했다:
- 원격 사용:
try.froglet.dev에 접속해 15분짜리 임시 신원(trial identity) 토큰을 생성. "숫자 두 개를 더하는" 단순 예시 서비스 제공자의 별도 토큰도 생성 — provider 토큰과 requester 토큰이 서로 다른 것을 확인. 스키마, 대상 서비스, 제공자, 입력값(7과 5)을 담은 페이로드를 원격 Froglet에 제출해 딜 ID(deal ID, 즉 거래 영수증)를 받고, for 루프로 폴링하며 클라우드 노드 부하에 따라 완료를 기다린 뒤 정답 12를 수신. - 로컬 설치: 도커(Docker) 기반으로 명령어 하나로 Froglet 에이전트를 설치. 두 개의 Froglet가 실행 중이지만 IP/포트가 아니라 노드 ID를 확인해보면 동일한 하나의 ID — 즉 하나의 Froglet 노드가 provider와 consumer 역할을 동시에 수행할 수 있음을 증명.
- Claude와의 연동: Claude에서 Froglet MCP가 활성화된 것을 확인 → 방해받지 않게 권한 설정 조정 → "Froglet MCP만 사용하고 아무것도 설치하지 말라"는 제약을 명시적으로 지시 → Claude에게 (1) provider/runtime 상태 확인 (2) 템플릿으로부터 "두 숫자 더하기" 아티팩트 게시 (3) 그 서비스를 찾아 로컬에서 호출(5+7) (4) 결과 출력까지 한 번에 순서대로 수행하도록 요청. Claude가 모든 커맨드를 실행해 정확히 요청한 대로 결과 12를 산출.
이 데모의 핵심 시사점: Froglet은 근본 프로토콜/도구의 복잡성(스키마, 결제, 실행 환경, 협상, 마켓플레이스)을 캡슐화해, LLM 컨텍스트에 그 모든 걸 쑤셔 넣지 않고도(without stuffing your LLM context) 필요한 서비스와만 상호작용하게 해준다는 것 — 발표 제목("Agents Need Receipts, Not More Tool Calls")의 실제 구현 예시다. DB에 row-by-row 접근을 제공해 결제를 받거나, 백그라운드에서 GPU를 돌리며 어떤 종류의 연산 요청이든 받는 것도 같은 패턴으로 가능하다고 언급했다.
3계층: 실행 포인트 및 시사점
- 에이전트 설계 관점에서: 단순히 도구(tool) 개수를 늘리는 방향으로 에이전트를 강화하는 접근은 "로컬 최적화"에 머문다. 여러 조직/도메인에 걸친 협업이 필요한 워크플로우(과학 연구뿐 아니라 멀티 벤더 데이터 파이프라인, B2B 자동화 등)를 설계할 때는 "누가 무엇을 증명하고, 그 증명을 누가 신뢰할 수 있는가"라는 검증 가능성(verifiability) 계층을 먼저 고민할 가치가 있다.
- MCP/에이전트 하네스 생태계와의 연결: Froglet은 기존 에이전트 하네스, MCP, 실행 환경을 대체하지 않고 그 사이에 신뢰·결제·발견 계층을 얹는 방식을 택했다. "새 프로토콜을 만들 때 기존 스택을 강제로 통일시키지 않고 인터페이스만 공유한다"는 설계 원칙은, 사내 에이전트 인프라를 설계하거나 사내 도구 표준화를 고민할 때 참고할 만한 패턴이다.
- 에이전트 경제(agent economy) 트렌드: "에이전트에게 도구뿐 아니라 예산을 준다"는 비전은 최근 업계에서 논의되는 agentic commerce/x402류 결제 프로토콜 흐름과 맥이 닿아 있다. 조직이 에이전트에게 자율적 지출 권한을 위임하는 흐름을 지켜볼 필요가 있다.
- 실무 적용 아이디어: 사내에서 여러 팀/외부 파트너와 데이터·연산 자원을 공유해야 하는 상황이라면, "폐쇄형 커스텀 통합(수년/수백만 달러)" 대신 "가벼운 거래 계층 + 검증 가능한 영수증" 패턴으로 문제를 재정의해볼 수 있다. 이는 꼭 Froglet이 아니더라도, 서명 기반 체인·표준 발견 인터페이스·직접 P2P 거래라는 세 가지 구성 요소로 일반화해 사내 아키텍처에 적용 가능하다.
- 오픈소스 프로젝트로서 확인해볼 것: froglet.dev, GitHub 저장소를 통해 실제 프로토콜 스펙, MCP 연동 방식, 로컬 설치(Docker 한 줄 명령) 방법을 직접 검증해볼 수 있다. 라이프사이언스 도메인 외에 다른 산업에도 적용 가능한 범용 프로토콜인지 스펙 레벨에서 확인할 가치가 있다.
4계층: 핵심 요약 20줄
- 발표자 Armanas Povilionis(Alithea Bio, 면역항암·면역펩티도믹스 라이프사이언스 기업)가 에이전틱 자동화 실무에서 발견한 갭을 공유하는 라이트닝 토크.
- 핵심 주장: 에이전트에게 도구를 더 주는 것만으로는 부족하다 — 과학, 특히 라이프사이언스는 본질적으로 협업적 프로세스이기 때문.
- 에이전트 협업을 위해 필요한 것은 "검증 가능한 영수증의 체인(verifiable chain of receipts)".
- 영수증은 모든 단계를 증명하고, 결과의 신뢰성을 보장하며, 대규모 반복성과 협업을 가능케 해야 한다.
- 비유: 에이전트는 주방의 요리사. 더 좋은 도구(칼·팬·오븐)는 "로컬" 효율만 높인다.
- 과학 연구는 "혼자 요리"가 아니라 "미슐랭 레스토랑 운영"에 가깝다 — 공급자 품질, 고품질 서비스, 일관된 반복 생산 능력이 핵심.
- 진짜 과제는 로컬 도구가 아니라 전체 공급망을 반복 가능하고 일관되게 정렬하는 것.
- 현재: 에이전트 도구는 풍부해지고 있지만, 데이터·분석 알고리즘·컴퓨트는 조직별로 사일로화되어 있음.
- 미래 비전: 조직이 에이전트에게 도구뿐 아니라 예산을 줘서, 서비스 발견·데이터 요청·조건 협상·조직 경계를 넘는 지불까지 스스로 관리하게 함.
- 이때 에이전트는 "더 좋은 칼을 든 요리사"에서 "이그제큐티브 셰프"로 진화 — 공급자 물색, 재료 주문, 작업 조율, 기록까지 수행.
- 이 비전을 구현하기 위해 만든 것이 Froglet: 에이전트가 외부 데이터/서비스 제공자를 발견·거래·검증 가능한 영수증 수령을 하는 오픈소스 프로토콜.
- Froglet은 기존 결제 레일, 에이전트 하네스, 실행 환경, 전송 프로토콜을 대체하지 않고 "그 사이"에서 통합(integrate)만 한다.
- 모든 노드가 같은 소프트웨어 스택을 쓸 필요 없음 — 같은 인터페이스만 공유하면 됨.
- 클로즈드 소스 커스텀 협업은 수년·수백만 달러가 드는 반면, Froglet 셋업은 토큰 몇천 개·시간 몇 분이면 충분.
- Froglet 노드는 사이트마다 다른 구현이 아니라 동일한 노드가 provider/requester/marketplace 역할만 다르게 수행.
- 새 노드 생성 시 키 페어가 생성되고, 실행 전체가 서명 체인으로 기록되어 변조 여부를 검증할 수 있음.
- 제공자가 마켓플레이스에 서비스를 게시하면 요청자가 발견 후 직접(제3자 없이) 견적-거래-실행-영수증을 한 상호작용에서 처리.
- Claude(MCP)와의 데모: "Froglet MCP만 쓰고 아무것도 설치하지 마라"는 제약 하에 상태 확인→아티팩트 게시→서비스 호출(5+7)→결과 출력을 한 번에 지시했고, 정확히 12를 반환.
- 핵심 가치: LLM 컨텍스트에 프로토콜/결제/실행 환경 복잡성을 다 쑤셔넣지 않고도 캡슐화된 서비스와 상호작용 가능 — 발표 제목의 요지("Receipts, Not More Tool Calls")를 실증.
- 마무리: Froglet은 조직 경계 밖 리소스 발견, 원격 명령 실행, 검증 가능한 영수증이라는 세 기능으로 협업적 과학과 "영구적 과학 자동화(perpetual science automation)"를 가능케 한다는 비전. froglet.dev와 GitHub에서 참여 가능.
원문 인용 (핵심 문장)
"However, from my experience, adding more tools to agents will not suffice. Because science and especially in life sciences is inherently collaborative process."
"The challenge isn't local. It's not local tools. The challenge is aligning the entire supply chain that it's repeatable and consistent."
"At that point, an agent is no longer just a cook with a better knife. It starts to act like a chef."
"It just has a services that it needs to interact. And underneath there is a receipt, there is a payment, there is a execution environment. And there is a negotiation and marketplace hidden and it's uh doesn't stuff your LLM with context."