Offcanvas

개발자 / 검색|인터넷 / 블록체인 / 클라우드

'애저 데브옵스에 웹3를 통합'··· 마이크로소프트의 블록체인 실험

2022.11.28 Simon Bisson  |  InfoWorld
‘웹3’가 소위 대세 기술이라고 하지만, 아직 지난 30년간 활용됐던 인프라 및 소프트웨어를 완전히 대체할 정도는 아니다. 그럼에도 웹3가 해결하려는 문제는 한번 살펴보면 좋다. 블록체인 기술의 방향성을 예측하는 데 도움을 받을 수 있기 때문이다.
 
ⓒ Getty Images Bank 

웹3 지지자는 웹3를 거대한 소비자 기술의 집합으로 보며, 본질적으로 웹의 트랜잭션 기반을 대체할 수 있다고 말한다. 필자가 해석한 바로는 웹3는 다소 제한적이긴 하지만 데이터 교환(Electronic Data Interchange, EDI)에 중점을 둔 엔터프라이즈 애플리케이션의 하위집합을 지원한다. 이런 기술은 블록체인 기술로 구축할 수 있는데, 신뢰할 수 있는 방식으로 약속된 당사자끼리 불변성을 가진 데이터를 교환할 수 있기 때문이다. 따라서 디지털 문서 및 계약서 형태로 쓰기 매우 유용하다. 

현재 마이크로소프트가 만드는 블록체인은 매우 흥미롭다. 이들이 만드는 기술은 신뢰할 수 없는 조직으로 이루어진 연합체가 운영하고, 작업 증명 및 지분 증명 시스템에 대한 빠르고 영향력을 적게 주는 대안을 제공한다. 동시에 최근 출시된 SQL 서버(SQL Server)는 현재 각기 다른 엔티티간 배포할 필요 없는 애플리케이션에 대한 불변 원장을 제공한다. 

해당 기술의 예로 선박 화물 관리에 사용되는 디지털 선하 증권(운송인 또는 선박소유자가 발행하는 증권)을 들 수 있다. 선하 증권 계약상에 명시된 각 당사자 제조업체, 해운 회사, 창고 관리자, 화물선 운영자, 관세사, 세관 등이 될 수 있다. 각 당사자는 문서 및 계약을 서로 주고받으면서, 직접적으로 연결된 당사자의 정보만 알 수 있는데, 모두 문서에 대한 액세스 권한이 필요하며, 다수는 복잡한 다자간 승인 프로세스의 일부로 자신의 서명을 추가해야 한다. 

이런 구조는 얼핏 보면 엔터프라이즈 블록체인으로 구축할 수 있지만, 현대 개발 환경을 한 번 더 고려해봐야 한다. 우리는 이미 데브옵스 및 CI/CD 플랫폼을 사용해 클라우드 네이티브 애플리케이션을 만들고, 그 과정에서 분산 시스템을 규모에 맞게 구축하고 있다. 그렇다면 전통적으로 쓰이던 기술을 웹3에 사용할 수 있을까?
 

블록체인의 엔터프라이즈 도구 사용하기 

마이크로소프트의 파트너 프로그램 매니저 도노반 브라운은 이러한 분산 애플리케이션 플랫폼을 어떻게 개발자가 다룰 수 있을지 검토하고 있다. 브라운은 현재 애저 사업부에서 마크 러시노비치가 이끄는 CTO 인큐베이션 팀의 일원이기도 하다. 필자는 최근 브라운과 인터뷰를 진행하며, 엔터프라이즈 도구와 블록체인이 어떻게 결합되고 있는지 확인해보았다. 

웹3 도구를 엔터프라이즈에서 사용하려면, 개발 플랫폼 및 빌드와 테스트 도구 모두를 통합해야 한다. 특히 이커머스 및 기타 주요 정보 및 가치 흐름을 처리하는 데 있어, 웹3 도구가 따로 운영되며 문제를 만들지 않도록 하는 것이 중요하다. 누군가에게 탈취당할 위험이 있는 선하 증권을 우리는 원하지 않는다. 누군가 몰래 가져가 다른 창고로 배달되거나, 심지어 다른 목적지로 유도하는 경우는 피하고 싶다. 

브라운에 따르면, 서로 다른 기능들을 제공하는 도구가 폭발적으로 많은 점이 문제가 될 수 있다. 분명한 툴체인 및 툴체인 구축에 도움이 되는 모범 사례가 없기 때문에 통합하기 어려운 환경일 수도 있다. 즉 앞으로는 깃허브 코드스페이스(GitHub Codespace)로 관리하거나 마이크로소프트의 데브 박스 가상 개발 환경에서 사용할 수 있도록 엔터프라이즈 모범 사례를 지원하는 성숙한 도구를 파악하는 작업이 필요할 것이다. 그렇지 않을 경우 팀의 새로운 개발자를 합류될 때 쉬운 경로가 없어 시작이 어렵다. 

도구 선택은 문제의 일부일 뿐이며, 가장 쉽게 극복할 수 있을 것이다. 가장 큰 문제는 개발 모범 사례를 사용하는 경우 이러한 새로운 도구를 기존 파이프라인에 포함시키기가 상당히 어렵다는 점이다. 브라운은 “더 깊이 파고들면서 이러한 도구는 파이프라인에 넣을 수 있도록 설계되지도 않았다는 점을 깨달았다”고 언급했다. 코드를 스스로 작성하고 공식적인 테스트 없이 단순히 게시하며 게시 기술에 과도하게 의존한다. 이러한 접근 방식은 자체 호스팅 실험 및 프로토타입에는 모두 적합하지만, 엔터프라이즈급 코드를 제공하는 데는 적합하지 않다. 
 

애저에서 스마트 계약용 데브옵스 파이프라인 구축하기  

어떻게 스마트 계약을 데브옵스 파이프라인으로 가져올 수 있을까? 먼저, 웹3 기술을 나머지 엔터프라이즈 애플리케이션 스택으로부터 격리된 것으로 생각하는 것을 중단할 필요가 있다. 그렇게 할 경우, 스마트 계약을 테스트 하네스(test harness)에 넣고 테스트 우선 개발 기술을 사용하는 것과 같이 통합 지점을 찾을 수 있다. 

브라운은 개발 환경(Dev), 테스팅 환경(QA), 프로덕션 아웃풋과 함께 애저 파이프라인을 사용하는 이더리움 기반 분산 애플리케이션 환경을 구축했고, 그 과정에서 애저 스태틱 웹 앱(Azure Static Web Apps)이 프론트 엔드를 호스팅했다. 개발 환경 배포는 애저 컨테이너(Azure Containers)의 개인 이더리움 인스턴스에서 실행됐다. 이러한 접근 방식의 가장 큰 문제는 스마트 계약을 다른 환경에 배포하는 것이다.  

스마트 계약은 제이슨(JSON) 파일로 컴파일될 때 자동으로 추가되는 주소를 하드코딩 하는 것으로 밝혀졌다. 이를 위해서는 각 배포에 대한 계약 전체를 재구축해야 해 각 환경에 대한 여러 개의 재구축이 필요하다. 브라운은 이를 데브옵스 원칙에서 벗어나는 패턴이라고 지적했다. 런타임에서는 환경별 특정 값을 추가하여 한 번에 컴파일해야 한다. 네트워크 주소에 대한 외부 소스를 지원하려 한다면, 애플리케이션 프론트 엔드 코드를 재작성하기 위한 작업이 어느 정도 필요했다. 이러한 접근 방식을 통해 계약 주소를 찾을 수 없을 때 서비스를 더 쉽게 사용할 수 있으며, 쿼리(query) 실행 시 애저 펑션(Azure Function)을 사용해 주소를 전달한다. 

이런 구조 속에서 브라운이 작성한 코드는 프론트엔드단에서 한 번만 빌드할 수 있게 하고, 배포 파이프라인의 각 단계에서의 사용을 지원하고 있다. 그다음 그는 표준 자바스크립트(JavaScript) 테스팅 프레임워크를 응용 프로그램과 함께 사용할 수 있었다. 깃허브 저장소에서 각 환경을 구축하고 배포하는 데 필요한 모든 단계를 단일 애저 파이프라인에 구축하여 각 단계가 검증될 때마다 환경을 삭제할 수 있다. 애저 컨테이너 앱(Azure Container Apps)과 같은 도구를 사용할 경우 빌드 아티팩트를 신속하게 배포할 수 있어 도움이 된다.  

이를 시작으로 각 환경의 추가 프레임워크와 바이셉(Bicep) 같은 코드 툴, 애저 CLI 및 파워쉘의의 시스템 관리 스크립트에 대한 지원을 추가하여 반복 가능한 환경을 구축할 수 있다. 또한 즉시 실행할 수 있는 애플리케이션과 모든 서버 및 서비스를 제공할 수 있다. 애저에서 서비스형 인프라(platform-as-a-service) 및 서비스형 플랫폼(platform-as-a-service) 도구 모두를 사용해 작업할 경우, 더 이상 사용하지 않을 환경을 제거할 수 있어 비용을 절감할 수 있고, 애플리케이션 및 애플리케이션 환경이 멱등성(idempotent) 배포가 되도록 보장할 수 있다. 코드에 대한 각 변화는 애플리케이션 전체의 재배치 및 인프라 지원이 필요한다. 
 

블록체인 기술을 위한 성숙도 모델 지향

브라운이 만드는 기술은 웹3 기술이 어떻게 현대적 애플리케이션 프레임워크의 일부로서 친숙한 엔터프라이즈 환경에 구축될 수 있는지를 보여준다. 깃허브, 애저 데브옵스, 애저 컨테이너 앱, VS 코드 등 익숙한 도구 외의 도구를 사용할 필요가 없다. 그러나 웹3 프레임워크가 환경 변수 및 동적 리소스와 함께 작동하는 방식에 변화가 필요하다. 이러한 것들은 여러 단계 파이프라인에서 작동하도록 설계되지 않았으며, 엔터프라이즈 애플리케이션에서 규모에 맞게 적절한 수준의 성숙도를 제공하려면 변경이 필요하다. 또한 개발자가 애플리케이션 및 계약이 어떻게 수행되는지 더 명확하게 볼 수 있도록 더 나은 원격 측정(telemetry)이 필요하다. 

이런 기술의 결과물은 익숙한 것과 새로운 것이 섞여 있다. 개발자가 새로운 기술을 채택하고 기존 개발 프로세스에 도입하는 것을 더욱 쉽게 해주기 때문에 좋은 결과라고 할 수 있다. 마이크로소프트의 경우, 혁신을 가속화할 수 있는 새로운 기술을 더욱 심층적으로 살펴보는 것이 중요하다. 기업은 실험에서 엔터프라이즈에 이르는 인큐베이션 경로를 제공할 수 있다. 그리고 자체적인 플랫폼 안팎에서의 수년간의 엔터프라이즈 애플리케이션 개발 경험이 이러한 경로에 정보를 제공한다. 
editor@itworld.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.