데이터 스페이스 - 2. 데이터 스페이스 프로토콜(DSP)

이전 글에서는 데이터 스페이스가 무엇이고, 어디에서 출발해 어떻게 지금의 모습으로 성장하였는지를 폭넓게 다루었다. 오늘부터는 데이터 스페이스의 핵심 기술요소인 데이터 스페이스 프로토콜에 대해서 다루고자 한다.

 

들어가기 전에 알아두면 좋은 용어집(Terminology)을 소개하고자 한다.

참여자(Participant)	데이터 스페이스의 구성원. 데이터를 제공하거나 소비하며, 자기 대신 일할 에이전트를 등록한다.
참여자 에이전트(Participant Agent)	참여자를 대신해 실제 작업(카탈로그 공개, 전송 등)을 수행하는 기술 시스템.
커넥터(Connector)	계약 협상과 전송을 수행하고 합의를 만들어 내는 핵심 게이트웨이
카탈로그 서비스(Catalog Service)	카탈로그를 공개·제공하는 서비스.
제공자(Provider) / 소비자(Consumer)	데이터를 내놓는 쪽 / 데이터에 접근을 요청하는 쪽.
데이터셋(Dataset)	공유 대상이 되는 데이터 또는 기술 서비스.
정책(Policy)	데이터셋의 사용 조건(규칙·의무·금지)을 표현한 것.
오퍼(Offer)	카탈로그 안에서 특정 데이터셋에 결합된, 협상 전의 정책.
합의(Agreement)	협상을 거쳐 양측이 최종 합의한 협상 후의 정책, 즉 계약.
카탈로그(Catalog)	제공자가 광고하는 오퍼들의 모음.
디스트리뷰션(Distribution)	데이터셋에 접근하는 배포 형식과 그 접근점.
계약 협상(Contract Negotiation)	오퍼에서 합의에 이르는, 상태기계로 정의된 절차.
전송 프로세스(Transfer Process)	합의에 따라 데이터 접근을 조정하는, 상태기계로 정의된 절차.
메시지(Message)	참여자 사이에 오가는 정보 단위. 타입마다 구조가 JSON Schema로 정의된다.
프로파일(Profile)	외부 표준(DCAT·ODRL 등)을 데이터 스페이스에 맞게 제한·고정한 하위 집합.

데이터 스페이스 프로토콜(Dataspace Protocol, DSP)은 무엇인가?

지난 글에서 짚었듯, 데이터 스페이스는 데이터를 한곳에 모으지 않고, 각자의 원천에 둔 채로 필요할 때만 안전하게 연계/연결하여 사용하고자 하는 시스템이다. 그런데 이 발상이 실제로 작동하려면, 서로 다른 회사가 서로 다른 기술로 만든 시스템들이 기술적, 의미론적으로 같은 방식으로 대화할 수 있어야 한다.

 

예를 들어, A사의 시스템이 B사의 시스템에게 "당신은 어떤 데이터를 갖고 있나요?", "이 조건으로 쓰고 싶은데 동의하나요?", "이제 어디서 받으면 되나요?"를 물을 때, 그 질문과 답의 형식이 회사마다 다르면 사실상 기존의 데이터 레이크의 단점을 답습하는 것과 같다. 이는 지난 글에서 짚은 기관마다 다른 API·메타데이터·승인 절차 문제로, 데이터 스페이스 프로토콜(DSP)은 이 문제를 해결하기 위한 공통 프로토콜이다.

 

DSP의 계보는 IDSA(International Data Space Association)에서 출발했다. IDSA가 DSP의 초안을 만들었고, 벤더 중립적 발전을 위해서 Eclipse 재단의 Eclipse Dataspace Working Group으로 거버넌스가 이관되었으며(https://github.com/eclipse-dataspace-protocol-base/DataspaceProtocol), 2024-1, 2025-1-RC1 버전을 거쳐 2025년 7월에 DSP-2025-1이 정식적으로 Stable 버전으로 공개되었다(https://internationaldataspaces.org/offers/dataspace-protocol/). 현재 해당 명세는 ISO/IEC 20151 발간을 위한 국제 표준화 절차를 밟고 있다.

DSP는 데이터 스페이스 체계를 이루는 근간이 되는 표준으로 발전하고 있고, 최근 데이터 스페이스 생태계의 Technical Alignment가 DSP-2025-1 및 DCP를 중심으로 이루어지고 있다. IDSA Manifesto, IDSA Rulebook 2026-1, IDS-RAM 2026-1과 DSP/DCP, 그리고 이에 대한 구현체인 Eclipse EDC 및 Tractus-X가 Alignment되고 있는 중이다. 

• IDSA Rulebook은 데이터 스페이스의 규범적 중추로, 거버넌스와 참여에 관한 기능 요구사항을 정의한다. 탈중앙화, 런타임에서의 지속 가능한 신뢰 보장, 필수 및 권고 요구사항, AI Agent에 대한 데이터스페이스적 관점, 그리고 표준과의 매핑을 다룬다
• IDS-RAM은 Rulebook이 정한 개념을 실제 기술로 옮기기 위한 아키텍처 참조 모델로, DSP 및 DCP를 중심으로 두 표준을 컴포넌트, 메시지 형식, 상호작용 시퀀스, 바인딩 수준까지 핸들링하여 요구사항인 신원 관리, Observability, 데이터 탐색 및 카탈로그, 계약, 전송과정에 대해 통합한다. 
• Eclipse Dataspace Components(EDC)는 위 RAM 및 프로토콜에 대한 구현체로서, 데이터 스페이스 구현체를 만들기 위한 프레임워크(Toolbox)이다. 이는 Gaia-X Trust Framework 및 DSP를 베이스라인으로 하여 신뢰 원칙과 컴플라이언스, 그리고 프로토콜을 이어 준다. 소스코드의 구조를 가볍게 짚으면, Control Plane과 Data Plane의 분리, Connector, Identity Hub, Federated Catalog, Issuer Service, Registration Service로 요구사항을 만족하는 컴포넌트 계층을 제공하고, 여기에 DSP/DCP에 부합하는지 검증하는 TCK(Technology Compatibility Kit)을 제공한다.

이전 글에서 본 Catena-X의 참조 구현인 Tractus-X나, 이외의 대다수의 데이터 스페이스 구현체들 역시 EDC를 기반으로 구성되어 있다(이외의 경우 대부분 Fiware Trust Connector 혹은 IDSA Base/Base+/Trust Connector).

 

DSP는 데이터 스페이스에 참여하는 시스템들이 상호운용(interoperability)할 수 있도록, 그들 사이에 오가는 메시지와 절차를 규정한 통신 표준이다. 다만, DSP는 데이터 전송과정을 표준화하지는 않는다. 데이터 전송 채널을 열고 닫는 일은 전송 프로세스의 프로토콜이 조정하지만(Control Plane), 실제 데이터 전송과 그 과정의 기술적 예외 처리는 HTTP·FTP·MQTT·AMQP 같은 전송 프로토콜(Data Transfer Protocol, in Data Plane)이 담당하도록 한다.

 

DSP가 표준화하는 영역은 어떠한 데이터가 있는지(데이터 카탈로그), 어떠한 조건에서 데이터를 공유할 것인지(계약 협상), 어떻게 데이터를 전송받을지(전송 프로세스)의 세 가지다. 실제로 소비자가 카탈로그를 요청한다고 가정해보자. DSP는 이런 하나의 요청이나 응답을  다음 순서대로 처리한다.

1. 어떤 것을 주고받을 지 결정
2. 어떻게 주고받을 지 결정
3. 이 메시지가 규칙에 맞게 주고받고 있는지 검토

이를 구체적으로는 아래와 같이 이야기한다.

1. 추상 프로토콜 층 : 참여자 사이에 오가는 메시지의 종류와, 그 메시지가 만들어내는 상태 변화를 규정하는 층으로, Request Message와 이에 대한 성공 및 오류(ACK/ERROR)에 대한 응답을 정의하고,  프로세스를 한 상태에서 다음 상태로 옮기는 State Machine을 규정한다. 이 층은 카탈로그 표현에 DCAT, 정책 표현에 ODRL이라는 기존 표준 어휘를 사용한다. 
2. 바인딩 층 : 추상 프로토콜 층에서 발생한 추상 메시지를 실제 통신으로 옮기는 규칙으로, 각 메시지가 어떠한 HTTP 메서드 및 경로에 대응하는지(ex : 카탈로그 요청 - POST /catalog/request, 협상 시작 : POST /negotations/request), 결과를 어떠한 상태 코드로 알리는지(201 Created, 200 OK, 400 Bad request 등), 본문을 어떠한 미디어 타입으로 실어 보내는지(application/json, application/ld+json 등)를 정의한다. 또한 비동기로 상대가 보내오는 메시지를 받아 콜백하는 CallbackAddress, 카탈로그 결과에 대한 Pagination, 응답 압축(gzip) 등과 같은 web에서의 일반적 동작 역시 이 층에서 핸들링한다.
3. 스키마 층 : 메시지의 구조를 기계가 검증할 수 있는 구성하는 층으로, DSP의 모든 메시지는 JSON Schema로 정의되어 받은 JSON에 필수로 규정된 필드가 존재하는지를 검사함과 동시에 JSON-LD 1.1 Context(@context)를 제공하여 각 메시지가 @type에 의해 식별되어 Compaction 과정을 거치면 평범한 JSON으로도 같은 JSON Schema를 통과할 수 있도록 되어 있다. 이를 통해 JSON, JSON-LD의 상호운용성이 확보된다.

DSP-2025-1

DSP 2025-1 명세는 아래 네 가지로 구성된다. 

• 공통(common) : 용어 정의, 적용 범위, 그리고 여러 흐름을 가로지르는 공통 요구사항(버전 노출, 인증 헤더, 스키마·컨텍스트 규칙).
• 카탈로그(catalog) : 제공자가 무엇을 어떤 조건으로 내놓는지 소비자가 탐색하는 방법.
• 계약 협상(negotiation) : 사용 조건을 협상해 합의에 도달하는 절차.
• 전송(transfer) : 합의에 따라 데이터 접근을 조정하는 절차.

카탈로그·협상·전송은 각각 "프로토콜 문서"와 "HTTPS 바인딩 문서"로 나뉜다. 앞 절에서 말한 3-Layer 구조가 문서 구성에 반영된 것이다. 프로토콜 문서는 추상 프로토콜 층(메시지·상태)을, 바인딩 문서는 바인딩 층(경로·상태 코드)을 담당하며, 두 문서가 함께 가리키는 JSON Schema가 스키마 층을 맡는다. 

 

심층적으로 들어가기 전, 용어를 한 번 정리하자면 사람(조직)에 해당하는 것이 참여자이고, 그를 대신해 실제로 통신하는 프로그램이 참여자 에이전트다. 그중 협상·전송을 담당하는 핵심 에이전트가 커넥터(=데이터 서비스), 카탈로그를 내주는 에이전트가 카탈로그 서비스다. 한 참여자가 데이터를 내놓을 때는 제공자, 받을 때는 소비자 역할을 맡는다.

 

객체 쪽 관계는 다음과 같다. 하나의 데이터셋에는 사용 조건인 정책이 붙는데, 카탈로그 안에서는 그것을 오퍼라 부르고, 협상이 끝나면 합의가 된다. 데이터셋을 실제로 어떻게 받을지는 디스트리뷰션이 나타내고, 그 디스트리뷰션이 가리키는 접근점이 데이터 서비스다. 즉 "데이터셋 → (오퍼/정책 + 디스트리뷰션 → 데이터 서비스)"가 카탈로그 한 건에 담기는 구조이다.

 

모든 커넥터는 /.well-known/dspace-version으로 끝나는 버전 메타데이터 엔드포인트를 반드시 제공해야 한다. 이 엔드포인트는 버전이 붙지 않고(unversioned) 인증도 요구하지 않아야(unauthenticated) 한다. 이는 Handshaking의 출발점이기 때문이다.

 

응답은 지원하는 버전마다 버전 태그(version), 그 버전 엔드포인트로 가는 경로(path), 데이터 서비스 식별자(serviceId), 바인딩 종류(binding), 참여자 식별자 유형(identifierType), 인증 방식(auth)을 담는다. path를 루트 URL에 이어 붙이면 그 버전의 모든 엔드포인트가 매달리는 기준 경로(<base>)가 된다. 예컨대 루트가 https://provider.com이고 path가 /2025-1이면, 카탈로그 요청은 https://provider.com/2025-1/catalog/request가 된다.

{
  "@context": "https://w3id.org/dspace/2025/1/context.jsonld",
  "protocolVersions": [
    { "version": "2025-1", "path": "/2025-1", "binding": "HTTPS" }
  ]
}

(가독성을 위해 일부 필드를 생략한 대표 예시. 실제 응답은 위 스키마의 모든 필드를 포함할 수 있다.)

 

인증은 모든 HTTPS 엔드포인트에서 Authorization 헤더 사용을 권고(SHOULD)하되, 토큰의 의미(semantics)는 DSP의 표준화 대상에 포함시키지 않고 별도 표준인 DCP(Decentralized Claims Protocol)에 위임한다. 

 

DSP의 모든 프로토콜 메시지는 JSON Schema로 규범적으로(normatively) 정의된다. 즉 "올바른 메시지인가"의 최종 판정 기준을 이 JSON Schema로 검증한다. 동시에 명세는 JSON-LD 1.1 컨텍스트(https://w3id.org/dspace/2025/1/context.jsonld)를 제공해, 같은 메시지를 평범한 JSON으로 다루든 JSON-LD로 다루든 상호운용이 유지되도록 했다.

 

또한 카탈로그는 DCAT(Data Catalog Vocabulary, https://www.w3.org/TR/vocab-dcat-3/), 정책은 ODRL(Open Digital Rights Language, https://www.w3.org/TR/odrl-model/)이라는 기존 표준 어휘를 재사용하되, 원본의 표현을 그대로 쓰지 않고 프로파일로 제한한다. 구현자에게 이 대목은 핵심 결정으로 이어진다

카탈로그 프로토콜

카탈로그 프로토콜은 데이터 소비자가 무엇을 어떤 조건에 받을 수 있는지를 탐색하는 절차다. 메시지는 두 종류로, 카탈로그 전체를 요청하는 카탈로그 요청 메시지(Catalog Request Message)와, 특정 데이터셋 하나를 지목하는 데이터셋 요청 메시지(Dataset Request Message)다. HTTPS 바인딩으로 옮기면 다음과 같다.

POST /catalog/request	카탈로그 요청	200 OK + Catalog
GET /catalog/datasets/:id	단일 데이터셋 조회	200 OK + Dataset

요청은 모두 application/json 미디어 타입을 쓴다. 카탈로그 요청 본문은 아래처럼 단순하며, filter를 넣을 수 있다. 다만 구현체가 지원하지 않는 필터가 오면 400 Bad Request를 돌려줘야 한다. 소비자가 잘못된 카탈로그를 믿게 두지 않기 위함이다.

{
  "@context": "https://w3id.org/dspace/2025/1/context.jsonld",
  "@type": "CatalogRequestMessage"
}

 

 

하나의 카탈로그는 0개 이상의 데이터셋과 1개 이상의 데이터 서비스를 가져야 하고, 각 데이터셋은 반드시 하나 이상의 오퍼(hasPolicy)와 하나 이상의 디스트리뷰션을 가져야 하며, 각 디스트리뷰션은 자신을 받을 수 있는 데이터 서비스를 가리켜야 한다. 즉 카탈로그는 어떤 데이터가 있는가와 더불어 그 데이터를 어떤 정책, 어떤 엔드포인트에서, 어떤 형식으로 받을 수 있는가가 함께 들어가 있어야 한다. 

 

카탈로그에 대한 제약조건도 존재한다. 카탈로그는 연합(federated) 방식이라 별도의 복제 프로토콜을 두지 않는다. 각 소비자가 1..N개의 카탈로그 서비스에 직접 요청하고 결과를 스스로 관리하며, 필요하면 주기적으로 크롤링해 캐시한다. 여러 상위 카탈로그를 하나처럼 묶어 보여 주는 카탈로그 브로커도 허용되지만, 이때에도 상위의 접근 제어(정책)를 존중해야 한다. 둘째, 결과가 많을 때를 위한 페이지네이션은 HTTP Link 헤더(rel="next"/rel="previous")로 표현하고, 응답은 Content-Encoding: gzip으로 압축할 수 있다.

계약 협상 프로토콜

계약 협상은 제공자와 소비자가 특정 데이터셋의 사용 조건을 맞춰 가며 하나의 합의에 도달하는 과정이다. 계약 협상은 IRI로 유일하게 식별되는 하나의 프로세스이고, 양쪽 참가자가 같은 상태를 공유하는 State Machine으로 정의된다. 명세에서는 양측의 상태가 어긋나면 그 협상은 반드시 종료되어야 하고 새 협상을 다시 시작할 수 있다고 규정한다. 

 

상태는 총 7개로, 각 상태와 그 상태로 진입시키는 마지막 전이의 주체(C=소비자, P=제공자)를 함께 정리하면 다음과 같다.

REQUESTED	소비자가 오퍼를 근거로 합의를 요청	C
OFFERED	제공자가 오퍼를 제시	P
ACCEPTED	소비자가 최신 오퍼를 수락	C
AGREED	제공자가 합의를 보내 성립	P
VERIFIED	소비자가 합의를 검증	C
FINALIZED	제공자가 최종 확정 → 데이터 접근 가능	P
TERMINATED	어느 쪽이든 중단(종착)	C 또는 P

FINALIZED와 TERMINATED는 종착 상태라 다른 상태로 다시 전이될 수 없다. 협상이 정상적으로 끝나면 FINALIZED에 이르고, 이때 비로소 데이터가 소비자에게 접근 가능해진다.

 

상태를 움직이는 메시지는 누가 보내는지가 정해져 있다. 제공자 쪽 엔드포인트(소비자가 호출)를 정리하면 다음과 같다.

POST /negotiations/request	계약 요청(개시)	REQUESTED	201 Created
GET /negotiations/:providerPid	협상 상태 조회	—	200 OK
POST /negotiations/:providerPid/request	계약 요청(재오퍼)	—	200 OK
POST /negotiations/:providerPid/events	이벤트(수락 등)	ACCEPTED 등	200 OK
POST /negotiations/:providerPid/agreement/verification	합의 검증	VERIFIED	200 OK
POST /negotiations/:providerPid/termination	종료	TERMINATED	200 OK

제공자가 소비자에게 보내는 메시지(오퍼 제시, 합의 전달, 최종 확정 등)는 소비자가 처음에 알려 준 콜백 주소(callbackAddress) 아래의 경로(예: /:callback/negotiations/:consumerPid/agreement)로 전달된다. 협상을 개시하는 최초의 계약 요청은 아래와 같은 모양이다.

{
  "@context": "https://w3id.org/dspace/2025/1/context.jsonld",
  "@type": "ContractRequestMessage",
  "consumerPid": "urn:uuid:5e7a2f9c-...",
  "offer": {
    "@id": "urn:uuid:offer-1",
    "target": "urn:uuid:dataset-42"
  },
  "callbackAddress": "https://bob.com/callback"
}

 

여기서 두 개의 식별자에 주목해야 한다. 협상은 제공자 관점의 providerPid와 소비자 관점의 consumerPid 두 개로 양쪽에서 동시에 추적된다. 또 이벤트 메시지에는 비대칭 규칙이 있어서, 제공자가 eventType을 FINALIZED로 보내면 확정을, 소비자가 ACCEPTED로 보내면 수락을 뜻하며, 그 반대(소비자의 FINALIZED, 제공자의 ACCEPTED)는 오류를 의미한다.

 

바인딩은 오류 코드의 의미를 정한다. 잘못된 상태 전이는 400 Bad Request(본문에 Contract Negotiation Error), 존재하지 않는 협상은 404 Not Found, 그리고 권한이 없을 때도 404 Not Found를 반환한다. 비인가를 404로 돌려주는 것은 자원의 존재 여부 자체를 권한 없는 상대에게 노출하지 않으려는 의도이다.

전송 프로세스 프로토콜

계약이 확정되었다고 데이터가 곧장 전송되는 것은 아니다. 전송은 합의 이후에 시작되는 또 하나의 독립된 프로세스이며, 자체 State Macine을 가진다. DSP 명세는 두 가지 개념을 전제한다.

1. 제어 평면(control plane)과 데이터 평면(data plane)의 분리 : 제어 평면은 메시지를 받아 전송 프로세스의 로컬 상태를 관리하는 조정 계층이고, 데이터 평면은 실제 데이터가 와이어 프로토콜을 타고 오가는 계층이다. 
2. 전송의 유형 구분 : 제공자가 소비자 엔드포인트로 밀어 넣는 푸시(push)와 소비자가 제공자에게서 끌어오는 풀(pull), 그리고 끝이 정해진 유한(finite) 데이터와 스트림·API처럼 끝이 없는 무한(non-finite) 데이터의 구분이다.

State Machine은 아래와 같다.

REQUESTED	소비자가 합의에 근거해 데이터를 요청
STARTED	데이터가 접근 가능해졌거나 제공자가 푸시를 시작
SUSPENDED	전송이 일시 중단됨
COMPLETED	전송이 완료됨(종착)
TERMINATED	전송이 종료됨(종착)

SUSPENDED는 STARTED와 오갈 수 있는 중간 상태이고, COMPLETED와 TERMINATED가 종착 상태이다.

 

제공자 쪽 엔드포인트(소비자가 호출)는 다음과 같다.

POST /transfers/request	전송 요청(개시)	REQUESTED	201 Created
GET /transfers/:providerPid	전송 상태 조회	—	200 OK
POST /transfers/:providerPid/start	시작	STARTED	200 OK
POST /transfers/:providerPid/suspension	일시 중단	SUSPENDED	200 OK
POST /transfers/:providerPid/completion	완료	COMPLETED	200 OK
POST /transfers/:providerPid/termination	종료	TERMINATED	200 OK

마찬가지로 제공자가 소비자에게 보내는 시작·완료·중단·종료 메시지는 소비자의 콜백 주소 아래 경로(예: /:callback/transfers/:consumerPid/start)로 전달된다. 전송을 개시하는 json 메시지는 아래와 같다.

{
  "@context": "https://w3id.org/dspace/2025/1/context.jsonld",
  "@type": "TransferRequestMessage",
  "consumerPid": "urn:uuid:9b1d...",
  "agreementId": "urn:uuid:agreement-7",
  "format": "HttpData-PULL",
  "callbackAddress": "https://bob.com/callback"
}

 

이에 대한 원칙은 다음과 같다.

• 합의되지 않은 전송은 성립하지 않는다. 전송 요청의 agreementId는 반드시 실재하는 합의를 가리켜야 하며, 이 연결고리가 계약 협상과 전송을 하나의 일관된 거래로 묶는다.
• 멱등성(idempotency)을 고려해야 한다. 제공자는 consumerPid를 기준으로 전송 요청을 멱등하게 처리하여야 한다.

거래 과정 예시

지금까지의 세 흐름을 하나로 꿰어 보자. 제공자 Alice(https://alice.com)가 데이터셋을 갖고 있고, 소비자 Bob(https://bob.com)이 그것을 받으려는 가장 단순한 성공 경로다. 각 단계에서 실제로 호출되는 엔드포인트를 함께 표시했다.

1. 버전 발견. Bob의 커넥터가 GET https://alice.com/.well-known/dspace-version을 호출해, Alice가 2025-1을 HTTPS 바인딩으로 제공하며 기준 경로가 /2025-1임을 알아낸다. 이후 모든 경로는 https://alice.com/2025-1/... 으로 시작한다.
2. 카탈로그 조회. Bob이 POST /2025-1/catalog/request를 보낸다. Alice는 200 OK로 카탈로그를 돌려주고, 그 안에는 데이터셋(urn:uuid:dataset-42)과 그에 붙은 오퍼(사용 조건), 그리고 협상·전송을 시작할 데이터 서비스 엔드포인트가 들어 있다.
3. 협상 개시. Bob이 그 오퍼를 근거로 POST /2025-1/negotiations/request를 보낸다. Alice는 201 Created를 돌려주며 providerPid를 부여하고, 협상은 REQUESTED 상태가 된다.
4. 합의와 검증. Alice가 조건에 동의하면 Bob의 콜백(/callback/negotiations/:consumerPid/agreement)으로 합의를 보내 AGREED로 만든다. Bob은 POST /2025-1/negotiations/:providerPid/agreement/verification으로 합의를 검증해 VERIFIED로 넘긴다.
5. 확정. Alice가 Bob의 콜백(/callback/negotiations/:consumerPid/events)으로 eventType: FINALIZED 이벤트를 보내 협상을 FINALIZED로 확정한다. 이제 합의(agreementId)가 존재하고, 데이터는 접근 가능한 상태가 된다.
6. 전송 개시. Bob이 POST /2025-1/transfers/request에 그 agreementId와 원하는 format을 실어 보낸다. Alice는 201 Created로 응답하고 전송은 REQUESTED가 된다.
7. 시작. Alice가 Bob의 콜백(/callback/transfers/:consumerPid/start)으로 전송 시작 메시지를 보내며, 풀 전송이라면 데이터를 받을 실제 엔드포인트 주소와 접근 토큰을 dataAddress에 담는다. 상태는 STARTED.
8. 실제 데이터 접근. Bob의 데이터 평면이 그 주소에서 데이터를 끌어온다. 이 단계는 DSP가 아닌 전송 프로토콜(예: HTTP)의 영역이다.
9. 완료. 전송이 끝나면 POST /2025-1/transfers/:providerPid/completion으로 전송을 COMPLETED로 닫는다.

위 단계가 DSP가 표준화하는 거래과정이다. 여기서 DSP가 직접 다루는 것은 1~7·9의 "제어 메시지"이고, 데이터가 실제로 전달이 되는 8단계는 별도로 정의하지 않았다.

 

DSP가 정의하지 않은 부분은 다음과 같다.

• 신원과 신뢰 — 상대가 누구이고 믿을 수 있는지는 DSP가 정하지 않고 DCP(Decentralized Claims Protocol) 같은 오버레이 표준에 맡긴다. Authorization 헤더는 권고하되 토큰의 의미는 규정하지 않는다. (앞서 본 EDC의 Identity Hub와 IDS-RAM 2026-1의 "자격증명·클레임" 등이 이를 규정한다.)
• 실제 데이터 전송 — 위 시나리오 8단계에 있는 전송 채널과 와이어 프로토콜, 그 예외 처리는 DSP가 정의하지 않고, 데이터 평면(Data Plane)과 전송 프로토콜에 따른다.
• 정책의 해석 — 정책 표현에 ODRL을 쓰지만, 그 규칙을 실제로 평가·집행하는 엔진은 구현체가 책임진다.
• 서비스 발견의 세부 — 커넥터를 어떻게 찾을지는 DID 문서 등 데이터 스페이스가 직접 정할 수 있도록 한다.

---

 

이번 글에서는 DSP-2025-1에 대해서 조금 구체적으로 접근해 보았다. 다음 글에서는 Eclipse EDC의 실제 구현을 분석해보고, DSP를 실제로 구현할 때 유의해야 할 점과 교훈을 알아보도록 하겠다.