블록체인과 오픈뱅킹 API를 이용한 부동산 임대차 거래 시스템

Ⅰ. 서 론

한국에서 가계자산 중 부동산이 차지하는 비율은 약 70%이며 매해 꾸준히 증가하는 추세이다[1]. 이에 따라 정부는 안전하고 합리적인 부동산 거래, 부당하지 않은 계약을 위한 주택, 상가 건물 등 다양한 유형에 따른 표준 계약서를 배포하고 등기부등본, 토지대장을 민간에서 확인할 수 있도록 공개하여 사기 피해를 줄이고자 노력하고 있다. 한국에서 기존의 임대차 계약에서는 공인 중개사를 통해 위임한 매물에 대한 특약 사항을 구체적으로 합의한 후 보증금과 계약금, 그리고 중도금을 정한다. 합의된 계약 내용은 집주인과 임차인이 각각 한 장씩 가질 수 있도록 계약서 두 장을 작성하고 이를 서명한 후 나눠 갖는다. 계약서를 작성한 이후에는 임차인이 계약을 이행하기 위해 집주인에게 약속된 보증금과 계약금을 송금을 해야 하며 이 과정은 월세와 같이 계약 종류에 따라 반복될 수 있다. 하지만 이러한 기존의 부동산 거래 시스템은 많은 사람들이 부동산 계약의 많은 종이서류와 어려운 프로세스로 인해 계약을 진행하는데 어려움을 겪고 있다.

부동산 거래를 위한 어플리케이션은 존재하고 있다. 하지만 이러한 어플리케이션은 거래자와 판매자의 중간자 역할만을 제공하며 실제로 거래를 진행하기 위해서는 대면을 통한 거래가 필요하다. 실제로 시중에 상용화 되어있는 부동산 거래 어플리케이션을 확인해 본 결과 직접적인 구매는 불가능하며 판매자에게 문자 또는 통화를 연결해 주는 기능만을 제공하고 있다. 이는 결국 사용자와 판매자의 중계자로서의 역할을 가능하지만 기존의 부동산 거래 프로세스를 따라야 한다는 문제점을 가지고 있으며, 부동산 거래에 어려움을 느끼는 사용자들에게 편리함을 줄 수 없다. 또한 계약 또한 종이 기반으로 이루어지기 때문에 종이 없는 계약을 수행할 수 없다는 문제점이 존재한다.

위의 문제점을 해결하기 위해 우리는 블록체인 기반의 부동산 거래 시스템을 제안한다. 제안하는 모델은 블록체인의 스마트 컨트랙트를 이용하여 종이 없는 계약(Paperless contract)을 실현하고 사용자의 편의성을 증진시키며 모든 거래내역 및 계약서의 무결성이 보증됨에 따라 계약의 부인방지, 허위 계약 등 다양한 거래상의 문제점을 해결할 수 있다. 또한 계약자 간에 계약서를 나눠 갖는 문서 작업 과정을 종이 없는 디지털 거래로 진행하면 문서 분실의 위험성을 없앨 수 있으며 더욱 효율적인 계약이 가능하다. 우리는 기존의 연구와는 다르게 한국의 은행권 공동 공개데이터인 오픈뱅킹 API를 사용하여 단순히 계약서만이 아닌 계약에 관련된 모든 거래내역을 블록체인에 저장하여 거래 내역 확인 및 부인방지를 통해 사기 피해를 최소화 할 것이다.

Ⅱ. 배경 지식

2.3 하이퍼레저 페브릭와 오더링 시스템

하이퍼레저 페브릭[9]은 IBM의 주도 하에 개발이 이루어지고 있는 오픈소스 기반 프라이빗 블록체인 플랫폼이다. 하이퍼레저 페브릭에서는 오더링 방식의 합의를 진행하고 있으며 이는 퍼블릭 블록체인에서 사용하는 기존의 합의 방식과 같이 확률론적 접근을 통한 합의를 진행하지 않고 결정론적 합의 모델을 갖는다. 이는 곧 트랜잭션의 정렬과 빠른 TPS를 가능하게 한다. 하이퍼레저 페브릭의 오더링 시스템이 트랜잭션을 검증하는 방식은 그림 1과 같다.

Fig. 1.

Transaction verification method of ordering system

어플리케이션이 발생시킨 트랜잭션은 오더링 시스템에 전송되며 일정 시간 혹은 일정 개수의 트랜잭션이 모이면 오더링 시스템은 모인 트랜잭션을 이용하여 블록을 생성하고 이를 endorser라고 불리는 검증자들에게 전송한다.

검증자는 전달받은 블록의 트랜잭션을 실행시키며 자신의 원장의 상태 변화값을 담아 오더링 시스템에게 되돌려 준다. 오더링 시스템은 이 데이터가 모두 같은지 확인하여 트랜잭션을 통한 상태의 변화가 결정적으로 이루어질 수 있도록 한다.

Ⅲ. 제안 모델

본 절에서는 제안하는 모델의 계층 모델과 구조 및 전체적인 동작 방식을 살펴볼 것 이다. 제안하는 모델은 스마트 컨트랙트를 통한 거래의 성사뿐만 아니라 오픈뱅킹 API를 사용하여 거래간의 비용 지불 또한 자동적으로 수행하게 한다. 이 내역들은 블록체인 네트워크에 기록되며 이를 통해 거래의 부인 방지 및 사기 피해의 최소화를 가능하게 한다.

우리 모델의 최종적인 목표는 아래와 같다.

• ∙ 종이 없는 계약 : 제안하는 모델은 기존 임대차 계약에서의 불필요한 종이 문서를 최소화 하여 거래의 복잡성을 줄이고 사용자의 편의성을 증진시키고자 한다. 따라서 전체적인 계약 흐름에 있어서 기존의 계약 방식보다 종이 문서의 이용량이 적어야 한다.
• ∙ 지불된 비용의 증거 : 제안하는 모델은 오픈뱅킹 API를 이용하여 지불을 가능하게 하며 그 증거를 블록체인에 저장하여 거래를 증명하고자 한다. 따라서 제안하는 모델은 블록체인에 올라간 지불의 증거가 믿을 수 있는 방법을 통해 업로드된 것인지 확인할 수 있어야 한다.

3.1 계층 모델

제안하는 모델의 계층구조는 그림 2와 같다. 블록체인 플랫폼은 하이퍼레저 페브릭으로 하며 합의 알고리즘은 오더링 시스템을 사용할 것이다. 거래를 위해 하이퍼레저 패브릭의 스마트 컨트랙트 기능을 이용하며 결재와 결제의 증거를 가져오기 위해 오픈뱅킹 API를 사용할 것이다. 또한 제안하는 모델을 사용하는 여러가지 어플리케이션들이 만들어 질 수 있다.

Fig. 2.

Hierarchical model of the proposed model

3.2 시스템 모델

제안하는 모델은 하이퍼레저 페브릭 기반의 블록체인 네트워크로 이루어져 있다. 이때 거래를 원하는 유저는 네트워크 가입 절차를 통해 Fabric CA에서 발급받은 개인키를 기반으로 하여 임차인 및 임대인이 될 수 있으며 자신임을 증명하게 된다.

Fig. 3.

System model

블록체인 네트워크를 이루는 피어는 국토교통부, 한국 부동산 개발 협회, 공정거래 위원회 등 신뢰 있는 기관들이 될 수 있으며, 이 기관들을 모아 거버넌스 형태로 블록체인 네트워크를 운영하도록 한다. 또한 오픈뱅킹 API는 금융거래가 진행될 때에만 사용되기 때문에 언제나 피어와 연결되어 있을 필요가 없다.

현재 오픈뱅킹 API는 REST API 방식을 취하고 있기때문에 HTTP를 사용하여 통신한다. 따라서 통신이 필요할 때 적절한 메소드를 사용하여 통신을 하도록 한다. 또한 사용자의 시스템 사용 편의성을 위해 모델은 어플리케이션을 지원해야 한다. 이는 웹 또는 모바일 어플리케이션으로 지원하며 거버넌스가 운영하는 중앙 서버를 통해 한다.

3.5 계약

본 절에서는 제안하는 모델의 계약에 대한 내용을 전반적으로 다룬다. 이때 사용하는 표기법은 표 1과 같다.

Table 1.

Notation

3.5.1 계약 생성

구매자가 매물을 구매하고자 판매자에게 거래 요청을 보내면 판매자는 C,T,pub_B,d_S를 임대차 계약을 위한 스마트 컨트랙트로 전송한다. 데이터를 받은 스마트 컨트랙트는 전송받은 데이터를 기반으로 Agreement 구조체를 생성하고 블록체인에 저장한다. 이로써 매물 등록자와 매물 구매자간의 계약이 생성된다.

Agreement 구조체는 계약에 관련된 데이터들의 집합을 의미하며 C,pub_B,d_S,d_B,tv로 이루어져 있다. d_S는 판매자가 계약서 C에 대해 구매자와의 계약을 동의했다는 것을 의미하며 d_B는 구매자가 계약서 C에 대해 판매자와의 계약을 동의했다는 것을 의미한다. 표 2에서는 아직 구매자가 계약에 동의하지 않고 입금 프로세스를 진행하지 않았으므로 d_B,tv를 null로 채워 넣는다.

Table 2.

Algorithm of create agreement

3.5.2 계약 체결

부동산 거래의 경우 현물거래가 필요하다. 따라서 기존의 블록체인 기반 부동산 거래 시스템은 블록체인에 계약서의 내용만 저장 하고 계약금 이체를 따로 진행하는 경우가 많다. 이는 곧 스마트 컨트랙트가 구매자와 판매자 사이의 현물거래가 이루어 졌음에 대한 증거는 제공하지 못한다는 것을 의미한다. 하지만 본 모델에서는 오픈뱅킹 API를 사용하여 거래금의 이체 및 확인을 자동화 시킬 것 이다.

또한, 그 증거를 블록체인에 저장하여 거래가 정상적으로 진행됐음을 증명할 것이다. 우리는 계약 생성 절에서 판매자가 판매를 위한 데이터를 스마트 컨트랙트에 전송하는 것을 확인했다. 이 스마트 컨트랙트를 통해 매물 구매자는 전송된 계약서의 내용을 확인한 뒤 거래에 동의 할 수 있다. 동의를 하게 되면 서버는 사용자를 결제 페이지로 리다이렉트 시킨다. 결제 페이지로 리다이렉트된 사용자는 오픈뱅킹의 입금 이체 프로세스에 따라 입금을 진행하고 서버는 그 응답으로 그림 4와 같은 구조를 가지는 데이터를 받는다.

Fig. 4.

Deposit transfer response data

이때 우리는 차후에 이체 결과를 조회하기 위해 위 데이터 중 bank_trand_id, bank_tran_date, tran_amt를 필요로 하며 이를 OTRD라고 정의한다.

위 결제 과정이 완료되면 OTRD와 계약 생성 과정에서 생성된 계약서의 기본키인 h(C,T), 블록체인을 통해 받은 계약서의 데이터를 해쉬화 한 h(C), 그 서명 데이터 [h(C)]_σB를 스마트 컨트랙트로 전송한다. 스마트 컨트랙트는 h(C,T)를 통해 Contract 구조체를 블록체인으로부터 불러오고 그 내부에 저장된 pub_B를 이용하여 [h(C]_σB를 검증한다. 이는 구매자가 계약서 내용에 동의하였음을 의미한다. 그런 뒤 OTRD와 C를 이용하여 계약서와 이체된 금액이 일치하는지 확인한다. 마지막으로 OTRD를 이용하여 오픈뱅킹 API를 통해 이체가 실제로 진행되었는지에 대한 검증을 진행한다. 이 프로세스는 거래 검증 절에서 자세히 설명한다.

3.5.3 결제 검증

우리는 결제가 정상적으로 진행되었는지를 확인하기 위한 프로세스를 진행하며 이 프로세스는 하이퍼레저 페브릭의 오더링 시스템을 기반으로 한다. 또한 전체적인 검증의 흐름은 그림 5와 같다.

Fig. 5.

Overall verification flow

결제 체결 절에서 우리는 OTRD를 스마트 컨트렉트로 전송하며 표 3의 알고리즘을 통해 오픈뱅킹 API와 OTRD를 이용해 이체 검증을 한다는 것을 확인하였다. 또한 우리는 2.3절에서 하이퍼레저 페브릭의 트랜잭션 검증 방식을 확인했다. 하이퍼레저 페브릭의 트랜잭션 검증 방식에 따르면 트랜잭션을 검증하는 모든 검증자 노드들의 state가 일치하지 않으면 에러를 발생시킨다. 즉 SignContract를 실행시키는 트랜잭션을 검증할 시 모든 검증자 노드에서 해당 알고리즘이 실행된다는 것을 의미하며 이는 검증자 노드의 수만큼 오픈뱅킹 API를 통해 이체 검증을 하게 되는 것을 의미한다. 이체 검증 쿼리는 각 검증자 노드로부터 따로 전송되며 그 응답 데이터도 검증자 노드들이 각자 받게 된다. 응답 데이터의 구조는 그림 6과 같다.

Table 3.

Algorithm of SignAgreement

Fig. 6.

Transfer result inquiry data

그림 6에서 볼 수 있듯이 응답 데이터는 이체 이력에 대한 데이터를 포함하고 있다. 우리는 이 데이터 중 req_list 데이터를 이체의 증거로써 남길 것 이며 이 데이터를 OCRD라고 정의한다. 오픈뱅킹 서버에 이체 요청을 전송한 뒤 실제 이체가 발생하기 까지 지연이 있을 수 있다. 또한 각 검증자 노드가 개별적인 이체 확인 요청을 전송하기 때문에 검증자 노드 중 일부는 이체 결과 조회 데이터를 받지 못할 수도 있다.

검증자 노드는 OCRD를 블록체인에 추가하여 state를 변경시키고 그 결과값을 오더링 시스템에게 다시 전송한다. 이때 위에 서술한 문제로 인하여 각 검증자에게라도 다른 데이터를 받게 된다면 결정론적이지 않게 됨을 의미하기에 해당 트랜잭션은 실패하게 된다. 이때 만일 해당 트랜잭션이 실패했다면, 오픈뱅킹 API 명세서에 따라 일정 시간이 지난 후 해당 트랜잭션을 다시 시도한다.

만일 트랜잭션이 성공한다면 계약서에 대한 구매자와 판매자의 서명과 오픈뱅킹 API로부터 전송받은 입금에 대한 증거가 블록체인 네트워크에 저장 되었으므로 결제 프로세스가 종료된다.

Ⅳ. 구현 및 실험

본 절에서는 제안하는 모델의 구현을 통한 PoC를 진행한다. 구현 환경은 표 4와 같다.

Fig. 7.

Diagram of the experimental environment

Table 4.

Experiment environment

하이퍼레저 페브릭은 1.4.6버전을 이용하였다. 블록체인 네트워크는 국토 교통부, 공정거래 위원회가 거버넌스가 된다고 가정하여 구축하였으며 이때 각각을 Org.1, Org2라고 부르도록 한다.

도커를 이용하여 네트워크를 구현하였으며 서버는 Node js를 이용하여 구현하였다. 또한, 체인코드는 go언어를 이용하여 구현하였다. 오픈뱅킹 서버는 실 서버를 사용하기에 제약이 있기 때문에 Testnet을 사용하여 실험을 진행하였다.

4.1 계약서 작성

본 구현에서 계약서는 실제 임대차 계약서를 html로 컨버팅하여 사용하였다. 필요한 부분은 판매자가 직접 채워 넣을 수 있으며 해당 내용들은 블록체인에 저장된다. 구매자가 해당 계약서를 확인하기 위해 서버에 요청하면 서버는 블록체인에서 해당 데이터를 받아와 컨버팅 된 임대차 계약서에 내용을 채워 넣고 구매자의 화면에 보여준다.

Fig. 8.

Web-converted lease agreement

4.2 입금 확인

입금 확인 프로세스는 하이퍼레저 패브릭의 오더링 방식에 의거하여 작동한다. 구현에서 네트워크는 2개의 Org.으로 이루어졌기 때문에 그림 9를 보면 2개의 Org.에 체인코드가 설치된 것을 확인할 수 있으며 검증자 노드 또한 2개로 지정하였다.

Fig. 9.

Instantiated chaincode

우리는 앞에서 오더링 시스템에 의해 검증자 노드의 수만큼 오픈뱅킹 서버에 입금 확인 요청을 진행할 것 이라고 말하였다. 이를 검증하기 위해 체인코드 소스에 로그를 남기도록 하였다.

그림 10과 그림 11을 보면 각 Org.에서 실행시킨 체인코드에 대한 로그를 보여주고 있다. 제일 처음 입금 확인 요청을 진행하기 위한 OTRD를 보여주고 그에 대한 전체 응답 데이터와 응답데이터에서 추출한 OCRD(res_list)를 확인할 수 있다. 전체 응답 데이터에서 api_tran_id 는 각 요청마다 고유하게 매겨지는 식별자이다. 이때 그림 10과 그림 11의 식별자가 다른 것으로 보아 각 검증자 노드마다 다른 요청을 수행한 것을 확인할 수 있다.

Fig. 10.

Chaincode logs of Org.1

Fig. 11.

Chaincode logs of Org2

다음은 오픈뱅킹 서버로부터 서로 다른 값(입금 실패 등)이 오는 경우를 확인해 볼 것이다. 하지만 우리는 오픈뱅킹 테스트 넷을 사용하고 있기 때문에 이를 직접적으로 확인하기에는 어려움이 있다. 따라서 이를 확인하기 위해 의도적으로 체인코드를 비결정적으로 만들어 체인코드가 제대로 수행되는지 확인해 볼 것이다.

테스트 코드는 그림 12와 같다. 렛저의 state를 변경시키는 값을 랜덤하게 주어지게 함으로써 각 검증자 노드마다 서로 다른 state를 가지도록 하였다.

Fig. 12.

Non-deterministic chaincode

그림 12의 체인코드를 실행시킨 결과는 그림 13과 같다. could not assemble transaction: ProposalResponsePayloads do not match 라는 에러 메시지와 함께 실패하는 것을 볼 수 있다. 즉 만일 입금과정에 문제가 생겨 오픈뱅킹 서버로부터 잘못된 응답이 하나라도 온다면, 비 결정적인 결과가 도출됨으로써 거래에 실패하게 된다.

Fig. 13.

Response of non-deterministic chaincode

Ⅴ. 토 론

국토교통부에서는 블록체인 기술을 사용하지 않은 인터넷 부동산 거래 서비스인 ‘부동산 거래 관리 시스템’을 제공하고 있다. 따라서 우리는 부동산 거래시스템에서 블록체인 기술 도입에 대한 타당성에 대하여 논할 필요가 있다.

기존의 부동산 거래 관리 시스템은 공인 인증 전자서명, 부인방지 기술을 통해 부동산 거래의 타당성을 제공하고 있다. 또한, 부동산 거래의 데이터를 보관하기 위해 과학기술 정보 통신부 장관으로부터 지정받은 법인 또는 국가 기관인 공인전자문서센터를 운영하여 전자문서 보관의 효율성과 안전성을 보장하고 있다. 하지만 이러한 저장소는 부동산 거래 데이터의 무결성 및 영속성을 법적 기준을 통해 이를 해결하고 있다. 따라서 사용자는 부동산 거래 데이터의 보관에 대한 기술적인 무결성 및 영속성을 지속적으로 보장받기 충분하지 않다. 하지만 우리는 부동산 거래를 위해 블록체인을 이용한 시스템을 제안하였다. 이를 통해 사용자는 부동산 거래 데이터의 무결성 및 영속성을 현실적이고 효율적으로 보장받을 수 있으며 이를 통해 거래의 신뢰성을 더욱 향상시킬 수 있다. 따라서 부동산 거래 시스템에 대한 블록체인의 적용은 타당하다고 할 수 있다.

또한, 우리는 기존 시스템과 제안한 시스템과의 비교를 통해 제안모델의 우수성을 입증할 필요가 있다. 표 5는 기존 시스템과 제안모델의 비교 결과를 보여주고 있다.

Table 5.

Comparison with existing systems

제안모델과 [11]은 블록체인 기술을 기반으로 동작하기 때문에 거래 정보에 대한 무결성과 영속성을 기술적으로 보장받을 수 있다. 하지만 국토교통부의 경우는 무결성과 영속성을 법적으로 보장하고 있기 때문에 데이터 저장소에 문제가 생길 경우 사용자는 자신의 데이터의 영속성 및 무결성을 보장받을 수 없게 된다.

[11]의 경우 부동산 거래 시 발생하는 금융 거래에 대한 방안에 대해 명확하게 제시하고 있지 않다. 국토교통부의 경우 이러한 기능을 기술적으로 제공하고 있으나 서버 클라이언트 기반의 시스템에서 동작하고 있기 때문에 금융 거래 정보에 대한 무결성과 영속성을 완벽하게 보장하고 있지 않다. 하지만 제안모델은 오픈뱅킹 API를 통한 금융 거래 프로세스를 제공하고 금융 거래 정보를 스마트 컨트랙트 에서 검증하고 블록체인에 저장한다. 따라서 국토교통부와 다르게 금융 거래 정보에 대한 기술적인 무결성과 영속성 또한 보장받을 수 있다. 따라서 제안모델은 기존 시스템보다 우수하다고 볼 수 있다.

Ⅵ. 결 론

우리는 기존 부동산 거래의 어려움과 종이문서 최소화를 위해 블록체인을 이용한 부동산 거래 시스템을 제안했다. 기존의 블록체인을 이용한 부동산 거래 시스템과는 다르게 블록체인에 이체에 대한 증거를 남으로써 실제 금전적인 거래가 이루어 졌는지에 대한 확인 또한 가능하게 했다. 이를 가능하게 하기 위해 하이퍼레저 패브릭의 오더링 시스템을 이용하였으며 실제로 이를 통한 이체 검증이 가능한지에 대한 실험을 진행하였다. 이를 통해 이 시스템을 사용하는 사용자들은 부동산 거래에 대한 편의성이 증대될 것이며 이체 거래를 블록체인에 저장하기에 거래를 더 명확하게 할 수 있을 것이라고 예상한다.

Acknowledgments

이 논문은 2018년도 정부(과학기술정보통신)의 재원으로 한국연구재단의 지원을 받아 수행된 기초연구사업임 (No.2018R1C1B6002903), 본 연구는 2019년 경기대학교 대학원 연구원장학생 장학금 지원에 의하여 수행되었음.

References

• Bank of Korea and Statistical Office of Korea, "2018 National Balance Sheet", Jul. 2019.
• Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System", http://bitcoin.org/bitcoin.pdf, , 2009.
• Jinsu Kim, jaeyoung Cho, and Namje Park, "Block Chain Based CCTV Image Forgery·Modulation Verification Mechanism", Journal of KIIT, Vol 17, No. 8, pp. 107-114, Aug. 2019. [https://doi.org/10.14801/jkiit.2019.17.8.107]
• Donghyeok Lee and Namje Park, "CCTV Video Privacy Protection Scheme Based on Edge Blockchain", Journal of KIIT, Vol. 17, No. 10, pp. 101-113, Oct. 2019. [https://doi.org/10.14801/jkiit.2019.17.10.101]
• M. Castro and B. Liskov, "Practical Byzantine Fault Tolerance", OSDI: Symposium on Operating Systems Design and Implementation, USENIX Association, Co-sponsored by IEEE TCOS and ACM SIGOPS, New Orleans, USA, pp. 173-186, Feb. 1999.
• https://github.com/ethereum/EIPs/issues/650, . [accessed: Mar. 16, 2020]
• Diego Ongaro and John Ousterhout, "In Search of an Understandable Consensus Algorithm", 2014 USENIX Annual Technical Conference, Philadelphia, PA. USA, pp. 305-319, Jun. 2014.
• Nick Szabo, "Formalizing and securing relationships on public networks", First Monday, Vol. 2, No. 9, Sep. 1997. [https://doi.org/10.5210/fm.v2i9.548]
• Elli Androulaki et al., "Hyperledger fabric: A distributed operating system for permissioned blockchains", EuroSys '18: Proceedings of the Thirteenth EuroSys Conference, Porto Portugal, Article No. 30, pp. 1-15, Apr. 2018. [https://doi.org/10.1145/3190508.3190538]
• https://www.open-platform.or.kr/apt/content/openplatform?location=openPlatform1, . [accessed: Mar. 16, 2020]
• Ioannis Karamitsos, Maria Papadaki, and Nedaa Baker Al Barghuthi, "Design of the Blockchain Smart Contract: A Use Case for Real Estate", Scientific Research An Academic Publicher, Journal of Information Security, Vol. 9, No. 3, pp. 177-190, Jul. 2018. [https://doi.org/10.4236/jis.2018.93013]
• A. Spielman, "Blockchain: Digitally Rebuilding the Real Estate Industr", Massachusetts Institute of Technology, Cambrigde, MA. 2016.