"너무 복잡해" 클라우드 앱 개발 문제⋯그래프QLㆍ슈퍼그래프로 해법 찾는다

우리는 클라우드 컴퓨팅의 황금시대에 살고 있다. 사용자에겐 경이롭다. 그러나 개발자에게는 총체적 난국이다.
 

전통적인 모놀리식(monolithic) 애플리케이션 아키텍처는 문제가 많은 대신 비교적 간단하다. 앱 서버와 데이터베이스를 브라우저 인터페이스에 연결하면 된다. 반면 오늘날의 애플리케이션은 이렇게 간단하지 않다. 백엔드 마이크로서비스, 퍼스트파티와 서드파티 API, 데이터베이스는 변화무쌍하고 브라우저, 셋톱 박스, 모바일 앱별로 해당 데이터를 위한 다양한 프론트엔드 랜딩존(landing zone)을 사용한다. 리액트(React)를 비롯한 여러 프론트엔드 프레임워크 덕분에 개발이 다소 쉬워졌지만, 혼란스러운 백엔드 복잡성을 프론트엔드 경험에 연결하는 일은 오히려 더 어려워졌다.

그래프QL(GraphQL)에 고마움(?)을 표시해야 하는 것도 이 때문이다. 2015년 페이스북이 공개한 그래프QL은 API를 위한 유연한 질의 언어 역할을 한다. 관계형 데이터베이스 질의에 사용하는 SQL과 달리, 그래프QL은 개발자가 다양한 데이터 소스를 질의할 수 있으며 클라이언트(프론트엔드 개발)와 서버(백엔드 개발)를 분리한다.

단, 이처럼 멋진 그래프QL도 슈퍼그래프(supergraph) 없이는 불완전하다. 아폴로 그래프QL(Apollo GraphQL) CTO 맷 드버갈리스에 따르면, 슈퍼그래프는 한 기업의 데이터, 마이크로서비스, 디지털 기능을 통합해 전체 조직의 ‘구성 계층’ 역할을 하는 네트워크다. 아폴로 그래프QL의 CEO 제오프 슈미트는 한 인터뷰에서 슈퍼그래프를 '살아 숨 쉬는 것'으로 표현하면서 “슈퍼그래프를 통해 기업은 계속 변화하는 요건에 맞게 인프라를 단계적으로 개선할 수 있다. 또한, 그린필드(greenfield, ​​완전히 새로운 설정이나 환경을 위한 시스템을 만드는 것) 같은 것이 없어 그 새로운 인프라를 구형 인프라와 연결할 수도 있다”라고 말했다.
 

슈퍼그래프와 그린필드에 대한 오해

잠시 슈미트의 말을 짚고 넘어가 보자. 당연히 스타트업이나 개인 개발자는 기성 기업과 똑같은 방식으로 기술 부채를 다룰 필요가 없으니 그린필드 개발에 집중할 수 있지 않은가? 기술 부채는 약간 감정적인 용어일 수 있지만 레드몽크(RedMonk) 애널리스트 제임스 거버너는 최근 인터뷰를 통해 이 문제에 대해 이렇게 말했다.
 

개인 개발자가 배운 기술을 바탕으로 새로운 프레임워크를 배우려는 경우든, 소기업이 확장한 특정 데이터 인프라 상에서 애널리틱스 구축 방법을 알아내려는 경우든, 직원 채용에 어려움을 겪는 대기업이 이미 보유한 기술을 활용하고자 하는 경우든… 변함없는 것은 새로운 기술(technology)이 들어오더라도 기존 인력과 기술 스택과 공존해야 한다는 사실이다.

슈미트는 이 사실을 어렵게 배웠다. 슈미트와 드버갈리스는 2010년대 초반에 엔드투엔드 자바스크립트 프레임워크를 제공할 목적으로 미티어(Meteor)를 공동 창업했다. 슈미트는 이 프레임워크를 두고 “새로운 앱 개발을 위한 마법 같은 플랫폼”이라고 표현했다. 개발자들도 수긍하는 듯했다. 깃허브에서 최고 인기 프로젝트였던 미티어JS는 전성기에 100회가 넘는 정기 모임을 열기도 했다. 문제는 미티어가 애초에 했던 가정이 잘못됐다는 점이다.

슈미트는 “미티어를 그린필드 개발용으로 설계하고 기업 내에 도입하려 했는데 막상 알고 보니 기업에는 그린필드인 것이 아무것도 없었다. 요즘 세상에는 그 어떤 앱도 개발하려면 여러 곳에서 온 데이터 소스와 다수의 다양한 서비스를 사용한다. 슈퍼그래프가 가치 있는 것도 이 때문이다. 클라우드에 있는 모든 것을 종합해 실질적인 경험을 만들어낸다”라고 말했다. 앞서 말한 것처럼, 개인 개발자든, 소규모 스타트업이든, 포천 500대 기업에 속하는 거대 기업이든, 말하자면 방화벽 외부에 있는 다양한 서비스에 의존하는 것이다. 그 모든 서비스 때문에 개발이 더 복잡해진다.

슈미트가 분석이 모두 맞는 것은 아니지만, 슈미트와 드버갈리스가 핵심적으로 간파했던 것은 의미가 있다. 즉, 미티어JS나 리액트처럼 점점 강력해지는 프론트엔드 프레임워크를 백엔드 서비스에 연결할 강력하지만 복잡하지 않은 더 좋은 방법이 기업에 필요하다는 점이다. 슈미트는 “기업이 미티어를 도입하기 얼마나 어려운지 확인한 후 미티어 2 데이터 시스템을 개발하기 시작했다. '아폴로'라고 불린 이 시스템의 바탕에는 기업을 지원하며 얻었던 모든 교훈이 깔려 있다. 즉, 복잡하고 이질적인 기업 환경에서 미티어 기술이 통하게 해야 한다는 것이다”라고 말했다. 실제로 많은 기업이 아폴로 슈퍼그래프용 질의 언어가 필요했고 그래프QL을 선택했다.
 

그래프QL 성능 개선

그렇다면 이런 변화가 개발자에 의미하는 것은 무엇일까? 개인 개발자든 대기업이든 상관없이 애플리케이션 개발 작업은 갈수록 어려워지고 있다. 확실히 마이크로서비스를 통해 복잡성이 늘어나는 방향인 것 같다. 그런데 개발자는 이 복잡성을 적극 받아들이고 있다. 이를 통해 민첩성 증대와 같이 얻을 것이 매우 많기 때문이다. 개발자들은 복잡하더라도 많은 이익이 있는 미래를 원하는 것이다.

그러나, 그 미래에 도달하기가 만만치 않다. 풍부한 잠재력이 있는 그래프QL조차 많은 개발자가 개별 서비스를 이어 붙이는 목적으로 사용했다. 아폴로가 노리는 자리는 이를테면 그래프 중의 그래프이다. 점점 세분화되는 인프라를 한데 모으기 위해 그래프를 사용하는 것도 좋지만 메타그래프(슈퍼그래프)를 더하면 개발자의 업무 방식을 극적으로 개선할 수 있다.

이에 대해 슈미트는 (슈퍼그래프를 추가하는 것이) 특정 오라클 데이터베이스나 특정 마이크로서비스에 깊고 직접적이며 취약한 연결을 생성할 필요도 없고 누군가 관리해야 할 완전히 새로운 REST 엔드포인트를 만들 필요도 없이 서로 다른 데이터 소스를 활용하는 가장 쉬운 방법이라고 설명했다.

슈퍼그래프 활용 방식은 점진적이다. 예를 들어 월마트는 점포 운영 메인프레임과 온라인 주문 처리 마이크로서비스를 통합할 필요가 있었다. 사용자는 월마트에 온라인 쇼핑용 웹사이트와 점포 내 픽업용 웹사이트가 따로 있다는 사실을 눈치채지도 못했을 수 있다. 그러나 온라인 쇼핑 때는 볼 수 있던 리뷰가 점포 내 픽업용 사이트에서는 볼 수 없다는 것을 알고 있었고, 시스템마다 호스팅 된 제품 카탈로그가 달라서 불편했다. 그렇다고 메인프레임을 운영할 형편은 안 됐던 월마트는 두 시스템을 사실상 결합하는 데, 아폴로 슈퍼그래프를 활용했다.

슈미트에 따르면 슈퍼그래프 방식은 '세상을 멈추는' 폭포식 변화를 요구하지 않는다. 기업 내 구형 시스템이 최신 시스템과 원활히 연결되도록 도울 뿐이다. 월마트의 경우 슈퍼그래프를 이용하면 프론트엔드 개발자가 제품 리뷰를 보여 주는 기능을 구현할 때 메인프레임을 포함해 어디에 있든 그 리뷰를 찾을 수 있음을 의미했다. 나중에 그 메인프레임을 마이크로서비스 기반 아키텍처로 리팩터링해도 프론트엔드에서는 아무것도 바꿀 필요가 없다.
 

클라우드 끌어안기

한 가지 흥미로운 사실은 클라우드가 반드시 상황을 개선하는 것은 아니라는 점이다. 예를 들어, AWS에서 제공하는 앱싱크(AppSync)는 앱 개발자가 다이나모DB(DynamoDB)에서 데이터를 끌어와 모바일 앱에 표시할 수 있는 훌륭한 툴이다.

그런데 가령 다이나모DB에서 끌어온 데이터를 애저(Azure) 서버리스 함수에 던져 넣은 후 메인프레임에서 데이터를 호출하고 구글 클라우드 서비스 한두 개에서 데이터에 접근하고 싶다면 어떨까? 완전히 다른 고민을 해야 하는 상황이 된다. 이때 그래프QL과 아폴로스러운 슈퍼그래프는 클라우드를 포함해 다양한 이질적인 환경을 개발자가 원하는 대로 사용할 수 있도록 지원한다. 특정 클라우드가 제공하기 어려운 중앙 라우팅 기능을 대신 수행하는 것이다.

그동안 개발자는 클라우드로 총체적 난국이 된 기업 IT를 '길들일 수 있는' 선언적 추상 계층이 필요했다. 한동안은 클라우드 업체가 그 문제를 해결할 것이라고 스스로를 속였지만, 결국은 해결하지 않았다. 오히려 기업 IT를 확대해 더 복잡하게 했다. 이제 이 선언적 추상 계층을 만드는 새로운 대안으로 슈퍼그래프가 등장했다. 실제로 지금 상황을 해결하는 데 도움이 될 것으로 기대된다.
editor@itworld.co.kr