오늘날 대부분의 스킬 / 도구 레지스트리(registry)는 사람이 브라우징하는 것을 위해 구축되었습니다.

Hugging Face. npm 레지스트리. Apple의 App Store. Smithery. Chrome 웹 스토어. 이들은 아름답고, 별점과 다운로드 수, 리뷰를 갖추고 있으며, 모두 한 가지 가정을 공유합니다: 사람이 사이트를 방문하여, 카드를 평가하고, 설치 여부를 결정한다는 것입니다.

우리는 Ornn을 구축하기 시작할 때, 그것들 중 하나 — 즉 AI 에이전트 스킬을 위한 더 나은 레지스트리 — 를 만들고 있다고 가정했습니다.

우리는 틀렸습니다.

실제 AI 에이전트를 우리 자신의 레지스트리에 연결해 보았을 때 — 클릭하며 돌아다니는 사람이 아니라, 루프(loop) 내에서 엔드포인트(endpoint)를 호출하는 에이전트 — 모든 마켓플레이스 가정이 무너졌습니다. 이 글은 무엇이 망가졌는지, 그리고 대신 우리가 결국 무엇을 구축하게 되었는지에 대한 기록입니다.

마켓플레이스가 최적화하는 것

브랜딩을 걷어내면 거의 모든 "X를 위한 마켓플레이스"는 내부적으로 동일해 보입니다:

• 발견(Discovery)은 시각적입니다 — 카드, 스크린샷, 평점, "트렌딩" 레일.
• 신뢰(Trust)는 사회적 증거(social proof)입니다 — 별점, 다운로드 수, "인증된 게시자" 배지, 다른 누가 사용하는가.
• 결정(Decision)은 인간 중심입니다 — 카드를 읽고, 스크린샷을 스크롤하고, 리뷰를 훑어본 뒤, 설치합니다.
• 설치(Install)는 일회성입니다 — 버튼을 클릭하고, 권한을 한 번 수락하면, 그것은 당신의 것이 됩니다.
• 방향(Direction)은 단방향입니다 — 게시자가 있고 소비자가 있습니다; 소비자는 다시 게시하지 않습니다.

이 다섯 가지 가정은 하나의 설계 제약 조건으로 쌓입니다: 소비자는 페이지를 읽는 인간이라는 것입니다. 그것을 제거하면 마켓플레이스의 UX에서 하중을 견디고 있는 것은 거의 아무것도 없습니다.

소비자가 에이전트일 때 무엇이 망가지는가

마켓플레이스에 에이전트를 연결하면 모든 가정이 약간씩 다른 방식으로 실패합니다.

발견(Discovery)은 시각적입니다. 에이전트에게는 눈이 없습니다. 스크린샷과 별점이 포함된 카드는 런타임(runtime)에게 아무런 의미가 없습니다. 에이전트에게는 자신이 추론할 수 있는 구조화되고 기계가 읽을 수 있는 메타데이터(metadata)가 필요합니다. 즉, 입출력 스키마(input/output schemas), 선언된 부작용(side effects), 런타임 요구사항(runtime requirements) 등이 필요합니다. 12,000회 다운로드에 별점 4.7점이라는 정보는 파싱(parse)할 수 없지만, "이 스킬은 api.openai.com에 대한 네트워크 액세스가 필요하며 작업 디렉토리에서 파일을 읽습니다"라는 정보는 파싱할 수 있습니다.

신뢰(Trust)는 사회적 증거입니다. 에이전트는 리뷰를 읽을 수 없습니다. "대부분의 사용자가 이것이 매우 잘 작동한다고 말합니다"라는 문장은 에이전트가 마켓플레이스의 큐레이션(curation)을 믿어야만 하는 문장입니다. 에이전트 입장에서는 그 신뢰를 검증할 수 없습니다. 그것은 UI를 통해 세탁된 분위기(vibes)일 뿐입니다. 에이전트가 검증할 수 있는 것은 암호화 서명(cryptographic signature), 출처 증명(origin attestation), 그리고 알려진 샌드박스(sandbox)에서 아티팩트(artifact)를 실행하여 얻은 보안 점수입니다. 신뢰의 중심이 "마켓플레이스가 좋다고 말한다"에서 "이것이 명시된 곳에서 왔음을 내가 검증할 수 있다"로 이동합니다.

결정(Decision)은 인간의 영역입니다. 마켓플레이스의 메인 페이지 전체는 인간의 결정을 돕기 위해 구축되었습니다. 에이전트는 스크린샷을 보고 결정할 수 없습니다. 에이전트는 현재 작업에 대해 해당 스킬을 시도해 보고 출력이 유용한지 확인해야 합니다. 이는 마켓플레이스가 정적인 카탈로그(catalog)가 되어서는 안 되며, 실행 가능(runnable)해야 함을 의미합니다. 모든 스킬은 에이전트가 설치를 결정하기 전에 호출할 수 있는 런타임(runtime)을 필요로 합니다.

설치(Install)는 단발성입니다. 인간은 앱을 설치할 때 권한 프롬프트를 한 번 수락하며, 그 이후에는 운영체제(OS)가 이를 조용히 강제합니다. 스킬을 설치하는 에이전트는 호출마다 기록(paper trail)이 남는 권한 결정이 필요합니다. "이 무작위 스크립트를 신뢰하십시오"라는 모델은 프롬프트를 한 번 수락하는 인간에게는 괜찮은 권한 모델일지 모르지만, 자율 루프(autonomous loop) 내에서 하루에 그 스크립트를 수백 번 호출해야 하는 에이전트에게는 최악의 모델입니다.

방향은 단방향입니다. 마켓플레이스에는 발행자(publisher)와 소비자(consumer)가 존재하며, 이 둘은 겹치지 않습니다. 하지만 에이전트는 다릅니다. 가장 흥미로운 에이전트의 행동 양식은 에이전트가 작업을 수행하는 도중 역량 격차(capability gap)를 발견하고, 새로운 스킬을 생성하며, 이를 감사(audit)하고, 실행한 뒤 — 만약 성공했다면 — 다음 에이전트가 이를 다시 발명할 필요가 없도록 레지스트리(registry)에 다시 푸시하는 과정입니다. 즉, 소비자이자 동시에 발행자입니다.

에이전트를 위해 설계할 때 바뀌는 것들

소비자가 에이전트라는 사실을 받아들이는 순간, 레지스트리의 모든 계층 설계가 바뀝니다. 이는 단순히 "버튼의 이름을 바꾸는" 수준이 아니라, "기본 요소(primitives) 자체가 달라지는" 변화입니다.

스킬은 앱 카드(app cards)가 아니라 매니페스트(manifest)를 포함한 버전 관리 패키지가 됩니다. 모든 스킬은 선언된 입력(inputs), 출력(outputs), 부수 효과(side effects), 네트워크 사용량, 런타임 요구사항(runtime requirements) 등 기계가 읽을 수 있는 매니페스트를 함께 제공합니다. 웹사이트의 카드 UI는 이제 인간을 위한 보조적인 인터페이스일 뿐이며, 주된 인터페이스는 에이전트가 HTTP를 통해 읽는 매니페스트입니다.

탐색(Discovery)은 브라우징과 평점이 아니라, 검색과 미리보기(preview)가 됩니다. 에이전트는 특정 역량(예: q=pdf parsing)을 쿼리하고, 관련성(relevance) + 출처(provenance) + 최신성(recency)에 따라 순위가 매겨진 구조화된 결과를 받습니다. 그런 다음 결정을 내리기 전에 샌드박스 플레이그라운드(sandboxed playground)에서 후보를 미리보기 합니다. 미리보기는 검색의 나머지 절반입니다. 이것이 없다면 에이전트는 다시 "느낌(vibes)"에 의존해 설치하는 상태로 돌아가게 됩니다.

신뢰는 인기가 아니라 출처(provenance)입니다. 모든 설치에는 출처, 서명자, 샌드박스 실행을 통한 보안 점수 등 서명된 감사 추적(audit trail)이 포함됩니다. 에이전트는 자신이 가져오는 것이 매니페스트와 일치하는지 검증합니다. 레지스트리는 "목록에 기재된 내용"과 "아티팩트(artifact)가 실제로 하는 일" 사이에서 속임수(bait-and-switch)를 쓸 수 없습니다.

설치(Install)와 실행(execute)은 하나의 API 동작이 됩니다. 설치는 단 한 번의 권한 승인 클릭이 아닙니다. 이는 구조화된 로깅(structured logging)을 동반한 호출별 권한 흐름(per-call permission flow)의 시작입니다. 에이전트가 어떤 스킬 버전으로, 어떤 입력을 사용하여, 무엇을 호출했는지에 대한 이력은 그 자체로 일급 아티팩트(first-class artifact)가 됩니다.

레지스트리(Registry)는 양방향입니다. 에이전트는 레지스트리로부터 데이터를 가져오기도(pull) 하고, 다시 레지스트리로 데이터를 밀어 넣기도(push) 합니다. 스킬을 린트(lint)하고 서명(sign)하는 빌드 단계, 이를 다시 레지스트리로 전달하는 게시(publish) 단계, 그리고 스킬을 공개(public), 친구 공개(friends-only), 또는 비공개(private)로 설정할 수 있는 액세스 제어(access-control) 인터페이스가 존재합니다. 마켓플레이스에는 평점이 있지만, 에이전트 레지스트리에는 권한(permissions)이 필요합니다.

생애주기(Lifecycle)는 하나의 API입니다. 검색(Search) → 가져오기(pull) → 설치(install) → 실행(execute) → 빌드(build) → 업로드(upload) → 공유(share). 에이전트 측면에서 이는 서로 다른 탭에 있는 7개의 서로 다른 UI가 아니라, 동일한 인터페이스를 대상으로 하는 7번의 호출입니다. 전체 과정이 곧 API이며, 웹사이트는 단지 이를 인간이 볼 수 있게 투영한 것에 불과합니다.

인간을 위한 마켓플레이스

• 카드 + 스크린샷을 통한 발견(Discovery)
• 별점 / 리뷰를 통한 신뢰(Trust)
• 읽기를 통한 의사결정(Decision)
• 설치 = 단 한 번의 수락
• 단방향 (발행자 / 소비자 분리)
• 생애주기 = 7개의 서로 다른 UI

에이전트를 위한 생애주기 API

• 구조화된 검색 + 매니페스트(manifest)를 통한 발견(Discovery)
• 서명된 출처(signed provenance)를 통한 신뢰(Trust)
• 샌드박스 미리보기(sandboxed preview)를 통한 의사결정(Decision)
• 설치 = 호출당 감사 추적(per-call audit trail)
• 양방향 (에이전트가 다시 게시 가능)
• 생애주기 = 하나의 API를 통한 7번의 호출

만약 당신이 AI 에이전트를 구축하면서 기존의 레지스트리들(모델을 위한 Hugging Face, 라이브러리를 위한 npm, MCP 서버를 위한 Smithery)이 에이전트가 실제로 스킬을 소비하는 방식과 잘 맞지 않는다고 느꼈다면, 그 이유는 바로 이것입니다. 마켓플레이스는 잘못된 요소를 최적화하고 있습니다. 소비자가 다르면 설계도 달라야 합니다.

우리는 Ornn을 github.com/ChronoAIProject/Ornn에 오픈 소스로 공개했습니다 — Apache 2.0 라이선스, TypeScript, HTTP + MCP 기반이며, 모델에 구애받지 않습니다 (Claude / GPT / Gemini / 사용자 정의 런타임). 위 내용은 설계 근거이며, README에는 퀵스타트(quickstart)와 MCP 서버 / Smithery / npm과의 비교표가 포함되어 있습니다.

만약 당신이 이 분기점의 에이전트(agent) 측에 있으며 이러한 프레임워크(framing)에 공감한다면, 이에 대해 논의하고 싶습니다 — Issue를 생성하거나 Discussion → Ideas에 의견을 남겨주세요.

공개 사항: 저는 Ornn에서 일하고 있습니다.

추신 — 초기 사용자들을 위한 출시 특전도 있습니다: 리포지토리(repo)에 ⭐(star)를 누르고 동일한 GitHub 계정으로 ornn.chrono-ai.fun에 로그인하는 선착순 500명에게 400회의 무료 GPT-5.5 대화(Playground 200회 + Skill Generation 200회, 신용카드 불필요, 만료 기간 없음)를 제공합니다. 첫 로그인 시 NyxID 초대 코드 NYX-2XXJI08A를 입력하세요. 24시간 이내에 Ornn 알림함으로 리뎀션 코드(redemption code)가 발송됩니다.