*잠깐, 이 글을 소개해드리는 위시켓은 2019년 시밀러웹 방문자 수 기준, 국내 1위 IT아웃소싱 플랫폼입니다.
현재 9만 이상의 개발업체, 개발 프리랜서들이 활동하고 있으며, 무료로 프로젝트 등록이 가능합니다. 프로젝트 등록 한 번으로 여러 개발업체의 견적, 포트폴리오 예상기간을 한 번에 비교해보세요🌼
Depar같은 기술들이 익숙한가?
기술의 등장과 사람짐의 속도로 인하여 어떤 기술이 투자하기 적절한지, 어떤 기술이 그저 유행일 뿐인지 알기 어려울 수 있습니다. 저는 매주 몇시간을 투자해서 널리 사용될 진짜 잠재력이 있다고 생각되는 몇몇 새로운 ‘떠오르는 기술’을 학습합니다.
올해 배울 수 있는 내용에 대한 아이디어를 몇가지 제공하기 위해 장기적으로 도움이 되고 시간 투자의 가치가 있다고 생각하는 떠오르는 기술 5가지를 선정했습니다.
간소화된 애플리케이션 개발을 위한 Dapr/오픈 애플리케이션 모델
새로운 애플리케이션을 구축할 때마다 같은 인프라 문제들을 처리하느라 지쳤나요? 저도 그렇습니다. 다행히도, Dapr과Open Application Model은 특히 인프라 의존성(dependencies)과 배포(deployment)와 관련해서 앱 개발 방식을 개선하고자 하는 ‘떠오르는 기술’입니다.
첫째, Open Application Model은 우리가 앱을 배포하는 방식을 모델링하려고 합니다. 앱 엔지니어들이 CL/CD 도구에서의 파이프라인 구축에 대해 걱정하는 것 대신 기본 구성 요소를 활용(레버리지)합니다. 이 기본 구성 요소들은 프레임워크 자체에 구축되기도 하지만 (KubeVela를 프레임워크 아래 후드에서 사용하고 있음) Terraform을 통해 추가될 수도 있습니다.
그런 모듈이 존재한다면 배포를 정의할 수 있습니다.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: first-vela-app
spec:
components:
– name: express-server
type: webservice
properties:
image: crccheck/hello-world
port: 8000
traits:
– type: ingress-1-20
properties:
domain: testsvc.example.com
http:
“/”: 8000
이 간단한 예시는 웹 서비스를 배포하지만, 로드 밸런서(load balancer)이든, 데이터 베이스이든, 클라우드 서비스이든(예를 들어 AWS S3 또는 Azure Blob) 애플리케이션에 필요한 모든 것을 여기에 추가할 수 있습니다.
둘째, Dapr은 분산된 애플리케이션 런타임입니다. 즉 Dapr은 거의 모든 앱이 요구하는 주요 사항들을 앱에게 제공하기 위해 앱과 함께 작동하는 것입니다. 예를 들어:
위의 요소들 중 하나를 연마하기 위해선 다른 서비스를 호출할 때 자동적인 재시도를 원할 가능성이 있습니다. 이는 Dapr에 의해 처리되는데, 필요한 경우 HTTP 호출을 재시도하는 사이드카를 통해 이동하기 때문입니다.
위에서 언급했듯이 요점은 Dapr이 당신의 앱 옆에 있다는 것입니다. 실제 앱은 Dapr 자체 코드를 포함하지 않아도 되며 정의된 엔드포인트를 통해 사이드카와 통신하기만 합니다.
Dapr과 Open Application Model은 모두 플랫폼의 제한을 받지 않는데, 이는 특정 실행이나 클라우드 제공자와 연결되어 있지 않음을 의미합니다.
WebAssembly
Java Applets와 Flash를 기억하시나요? WebAssembly는 사용자의 하드웨어의 모든 기능을 사용할 수 있는 웹 형식을 만들기 위한 최근의 노력입니다. Webassembly가 Java Applets 및 Flash와 비슷한 목표를 이루고자 하는데, 이 지점이 유사점들이 대부분 종결되는 지점입니다. WebAssembly는 웹 상의 주요 업체들(Mozilla, Apple, Google, Microsoft)의 지원을 받으며 World Wide Web Consortium(W3C)에 의해 개발되고 있는 ‘떠오르는 기술’입니다.
그렇다면 WebAssembly가 정확히 무엇이고, 이전 기술과의 차이점은 무엇일까요?
첫째, 코드를 다양한 언어들로 작성할 수 있고(이론적으로 이에 대한 지원이 있는 경우에), 그 뒤에 작성한 언어들을 WebAssembly로 컴파일(compile)할 수 있습니다. 지원은 아직 증가하고 있지만, 이미 WebAssembly를 C/C++, Java, Rust, C#, Swift에서 컴파일해서 몇가지를 고를 수 있습니다. 이곳에 사용 가능한 언어 목록과 지원 현황 목록이 있습니다.
둘째, 주요 브라우저들(물론 Internet Explore 제외)의 최신 버전 모두가 벌써 WebAssembly를 지원합니다. Flash를 사용하던 시대를 기억해보면, Apple은 Flash를 실제 지원하지 않았고, Safari에서 Flash에 대한 지원을 제거했을때 Flash는 효과적으로 사라졌습니다.
최종적으로 나머지 웹사이트와 앱은 JavaScript를 통해 Webassembly와 소통할 수 있습니다. 이는 Flash의 경우처럼 기술적으로 가능했지만 현실에서 실제 일어난 적은 없습니다.
본질적으로 WebAssembly는 자원 집약적인 앱들이 처음으로 브라우저에서의 기본적인 실행이 가능 해졌다는 점에서, 웹의 자연스러운 진화 버전처럼 느껴집니다. 이 기술이 절대 완벽한 것은 아니지만 특히 많은 주요 업체들이 지원하고 있다는 측면에서, 향후 몇년 간 많은 주목을 끌 것으로 기대하는 ‘떠오르는 기술’입니다.
AsyncAPI
문서화는 당신의 귀중한 배움의 시간을 투자할 만큼 특별히 흥미로운 개념은 아니라는 것을 압니다. 그러나, OpenAPI가 API 세계에 가한 영향과 현재 얼마나 폭넓게 채택되고 있는지 고려해봅시다.
AsyncAPI는 OpenAPI의 성공을 추구하고 이를 event-driven architectures에 적용합니다.
경험에 비춰 말하자면, 특정 응용 프로그램이 활용하는 이벤트 기반 메커니즘이 무엇인지를 한번에 이해하기는 매우 어려울 수 있습니다. 정기적으로 애플리케이션 작업을 하는 엔지니어들조차도 주제의 이름이나 엔드포인트와 같은 세부 사항들은 잊어버리기 십상입니다. AsyncAPI는 앱의 모든 이벤트 기반 기능을 문서화함으로써 해당 문제를 해결하고자 합니다.
OpenAPI를 사용한 적이 있는 사람이라면 위의 형식이 매우 익숙할 것입니다. 이는 AsyncAPI 기업이 OpenAPI로부터 최대한 많은 것을 활용하길 원했기에 의도적으로 설계된 것입니다. 다음은 문서화 가능한 것들의 간략한 개요입니다.
· 브로커들 – 브로커(예를 들어 Kafka)의 유형과 브로커의 엔드포인트를 문서화 가능
· 게시자와 구독자 – 브로커에 대한 발신자와 브로커의 메시지의 수신자에 대한 세부사항
· 메시지 – 필드 네임과 각각의 유형을 포함한 모든 메시지의 형식(format) 문서화 가능
· 채널 – 브로커와 관련하여 사용되고, 지원받는 모든 채널을 나열한다. 사용하는 브로커에 따라서 이름은 다양한데, 예를 들어 Kafka의 경우 주제가 채널이다.
부상하는 기술에 대해 예상할 수 있는 것처럼 AsyncAPI를 위한 도구는 OpenAPI 만큼 많지는 않지만, 성장하고 있습니다! 정말 긍정적인 신호는 대기업들이 AsyncAPI를 활용하기 시작한다는 점입니다.
가장 주목할 만한 기업들 중 하나는 Slack인데, 이 기업의 AsyncAPI 스펙을 여기에서 확인할 수 있습니다.
이 ‘떠오르는 기술’에 대해 더 알고 싶으면 이 곳에서 AsyncAPI를 확인해보세요.
Data Mesh
Data Mesh는 Zhamak Dehghani에 의해 개발되어 구체적으로 데이터 아키텍처의 문제를 처리하는 것을 목표로 삼는 아키텍처입니다. – 여기서 문제 해결 대상인 데이터 아키텍처에는 데이터 웨어하우스, 데이터 레이크를 비롯한 모든 유형이 해당됩니다.
그녀는 기업들이 교차적인(transactional) 앱들을 위한 아키텍처에는 많은 관심을 기울이면서 데이터를 다루는 일(데이터 분석, KPI 관리 등)은 등한시되고 있다고 주장합니다. 데이터는 너무 자주 데이터 분석가들에게 “울타리 너머로 던져집니다”. 그리고 이 지점에서 그들은 심지어 사용 가능하기도 전에 방대한 소스의 데이터와 힘을 겨뤄야만 합니다.
Zhamak은 이 접근 방식에는 몇가지 문제가 있다고 주장합니다.
· 중앙 집중적이고 독점적이다.
· Domain-Driven Design를 기반으로 한 도메인과 같이 풍부한 컨텍스트의 손실
· 결합된 파이프라인 아키텍처(예를 들면 ETL 작업들)
· 고도로 특화된 팀(예를 들어 데이터 팀)의 분리된 도메인 지식과 컨텍스트 부족
다행히도 이 문제에 대해 제안된 해결책이 있습니다. Data Mesh는 이를 네 가지 원칙으로 정의합니다.
The Architect Elevator
마지막으로 강조할 것은 기술 그 자체가 아니라 조직들이 앱을 설계하는 방법에 대해 생각하는 방식입니다. 제가 기억하는 바로는 설계자가 조직에서 어디에 어떻게 위치해야 하는지에 대한 논의가 있었습니다.
전체 기술 팀을 감독하는 설계자 그룹이 있어야 할까요? 혹은 아예 없어야 할까요?
Gregor Hohpe가 개발한 Architect Elevator(설계자 엘리베이터)는 설계사가 한 곳에 정적으로 자리 잡을 수 없다는 아이디어입니다. 이를테면 설계자들이 엘리베이터를 탄다면 더 효과적이라는 것입니다. 실제로 이는 설계자들이 현재와 미래 모두에 있어서 사업의 니즈를 이해하기 위해 사업 이해관계자들과 상호작용해야 함을 의미합니다. 또한 다른 면에서는 엔지니어 팀에 대한 신뢰와 지원이 필요합니다.
엘리베이터에 비유한 것은 설계자가 두 영역(사업 이해관계자, 엔지니어링 팀) 모두에서 시간을 보내야 함을 의미합니다. 저는 이 아이디어에 정말 공감하는데, 특히 불행하게도 건축가들은 엔지니어링 팀이 마주하고 있는 진짜 문제를 제대로 이해하지 못하는 경우가 흔하기 때문입니다. 어떤 경우 더 숙련돈 팀에서는 설계자들이 필요하지 않고 엔지니어들이 팀의 아키텍처를 정의하는 역할을 맡아서 스스로 관리할 수도 있습니다.
여기에서 ‘떠오르는 기술’에 더 배우거나 여기의 주제에 대한 Gregor의 책을 고를 수도 있습니다.
요약
지금까지의 내용이 제가 2022년에 배우기 위해 노력할 ‘떠오르는 기술’이며, 여러분이 무엇을 배울 수 있는지에 대해 아이디어를 조금 제공했기를 바랍니다. 여러분이 배울 다가올 ‘떠오르는 기술’이나 아이디어는 무엇인가요?
국내 1위 IT아웃소싱 플랫폼,
위시켓이 궁금하신가요?
