2019.05.27

칼럼 | 시스템 아키텍처의 미래

존 맥도웰 | CIO
우리가 인식하든, 인식하지 못하든 시스템 아키텍처의 진화가 이뤄지고 있다. 지난 수십 년 간 시스템 아키텍처는 건물 건축 양식과 비슷했다. 시스템이 해야 할 일을 결정하고, 필요한 주요 하부 시스템과 이들의 연결 방식을 파악하고, 계속 분해해 나가면서 상세 내용을 알게 되면 이를 이용해 개발 팀이 각 하부 시스템을 확장하고 이들을 통합해 원하는 시스템을 만들어낸다. 그러나 이러한 패턴이 최근 몇 년간 변화하고 있고 그 속도도 빨라지고 있다.
 
ⓒ Image Credit : Getty Images Bank


네트워크의 영향
1990년대 들어 네트워크 시스템이 일반화되면서 시스템 아키텍처 작업이 달라지기 시작했다. 클라이언트-서버 아키텍처가 지배적인 설계 패턴으로 등장함에 따라 네트워크 인터페이스가 포함되어야 했다. 시스템은 이제 더 이상 한 장소에 배치되어 정해진 터미널들로부터 사용하는 단일 개체가 아니었다. 

이후 시스템 아키텍처의 진화에 중대한 영향을 미친 것은 시스템 통합 니즈였다. 똑같은 데이터를 다른 여러 시스템에 입력하려면 시간이 많이 걸리고 오류가 생기기 쉽다는 것이 금방 드러나자, 데이터를 공유할 수 있도록 시스템 통합이 시도되기 시작했다. 

이는 서비스 지향 아키텍처(SOA)의 개발로 이어졌다. SOA의 기본 개념은 네트워크 상의 어떤 애플리케이션으로든 호출 가능한 서비스로 기능을 제공하자는 것이다. ‘서비스’란 원하는 기능에 대해 잘 정의된 인터페이스에 불과하다. SOA는 유동적으로 작성할 수 있는 애플리케이션의 시대를 약속했다. 새로운 업무적 필요가 생길 때마다 이를 충족하기 위해 애플리케이션의 코딩을 새로 하지 않아도 된다는 뜻이다. 

서비스의 부상
대대적인 홍보 속에 등장한 신기술들이 대개 그러하듯 SOA 역시 최초의 약속에 부응하지 못했다. 그러나 기대가 꺼진 지 10년이 지나서야 비로소 SOA 철학의 실질적인 장점이 빛을 발하고 있다. 

많은 기능들이 서비스로 이용 가능하게 되었고 이를 사용하는 기업들이 늘어났다. 일례로 페이스북, 구글 등은 모두 인증 서비스를 제공한다. 웹 사이트 운영자라면 사용자에게 사이트 전체 기능에 대한 접근을 허용하기에 앞서 인증을 해야 하는데 이 때 굳이 자체적인 인증 하부시스템을 호스팅할 필요가 없다. 서비스로 제공되는 것 중 하나를 가져다 쓰면 되기 때문이다. 마찬가지로 댓글 시스템, SNS 통합, 사용자 통계 등 많은 기능들 역시 서비스로 제공되고 있다. 클라우드 컴퓨팅 혁명의 본질은 결국 컴퓨터 하드웨어를 주문형 서비스로 변환시키는 것이다.

SOA 혁명은 비록 최초에 상상했던 형태는 아니지만 확실히 일어났다고 봐야 한다. 오늘날 기업 통합 작업은 시스템 인터페이스를 공개적으로 이용 가능하게 만드는 것에 대부분 집중되어 있다. 이를 흔히 ‘애플리케이션 프로그래밍 인터페이스(API) 우선 철학’이라고 한다.

API 우선 철학의 가장 유명한 사례는 ‘스티브 예게의 불평’이라는 글이다. 아마존의 API 우선 설계 철학을 채택하지 않은 구글을 책망하는 내용이다. 이 글의 요지는 모든 기능들을 API를 통해 네트워크 상에서 노출되어야 한다는 것이다. 그래야만 통합이 촉진될 뿐만 아니라 기업이 생산하는 (그리고 비용을 지불하는) 중복되는 기능의 양을 최소화할 수 있기 때문이다.

API가 시스템 아키텍처를 추동하는 방식
API 우선 철학이 가져온 효과는 무엇보다 개발자들이 스스로의 API를 문서화하여 알리도록 만든 것이다. 그런데 아마존의 API 우선 철학은 여러 시스템에 중복 기능을 개발하는 비용을 줄이는 것이 주요 목적이었다. 

보유 시스템을 몇 년에 한 번씩 전부 업데이트하는 기업은 거의 없기 때문에 API 우선 명령이 기업에 미치는 실질적인 효과가 나타나려면 시간이 걸릴 것이다. 그래도 시간이 지나면 그 효과는 자연적으로 느껴지게 된다. 특히 API 우선 명령이 ‘구축보다 재사용 먼저’ 명령과 결합될 때 그렇다. 말 그대로 개발자들은 새로운 기능을 구축하기에 앞서 먼저 기업에서 이미 이용 가능한 기능을 재사용해야 한다.

API를 통해 기능을 이용 가능하게 하는 시스템이 늘어나고 개발 팀은 구축 보다 먼저 재사용에 집중하게 되면, 신규 시스템 구축 작업이 기존 기능을 신규 기능으로 재작성 하는 작업으로 대체되는 시점이 오게 된다. 

매우 다양한 목적의 시스템들에 걸쳐 존재하는 중복의 양은 놀라울 정도이다. 대부분의 시스템에 필요한 것은 데이터 저장 및 검색, 사용자 인증 및 권한 부여, 텍스트 표시 및 그래픽 렌더링 기능 등이다. 

기업 내 기존 자원으로부터 재사용될 수 있는 기능은 수없이 많다. 시스템 개발 초기 시절에는 그나마 최소한으로 작동하는 시스템이라도 갖추려면 필요한 기능들을 일일이 만들어야 했다. 기본 기능의 많은 부분이 서비스로 이용 가능하게 되면서 시스템 설계 작업은 전체 시스템을 설계하던 것에서 기업 생태계 내의 주변 기능 개선 내용을 설계하는 것으로 진화하고 있다.

기능 중심 아키텍처(capability-focused architecture)를 향하여
계속해서 늘어나는 기능들을 특히 클라우드 환경에서 서비스로 이용 가능하도록 하는 기업 생태계가 대세화됐다. 클라우드 제공업체들은 앞다투어 더 많은 기능들을 제공하고 있으며, 몇 가지 서비스를 글루웨어(glueware)나 스크립트 언어로 이어 붙여 기본 시스템을 개발하는 것은 이미 가능하다. 

즉, 최소한으로 작동하는 기본 시스템이 몇 달이 아닌 몇 주 안에 만들어질 뿐만 아니라, 새로운 서비스들을 이어 붙이거나 서비스를 이용할 수 없는 경우에는 기성품 모듈을 설치하여 빠르게 개선 가능하다. 이런 환경에서는 시스템 구축 전에 몇 달에 걸쳐 세부 사항을 결정하는 설계 단계는 적합하지 않다. 시스템 아키텍처 및 설계에 대한 새로운 사고 방식이 필요하다.

이미 각종 서비스가 많은 기업에서 신규 시스템을 구축하려면 먼저 해당 시스템이 수행해야 할 기능을 명확하게 규정하고 이를 이미 서비스로 이용 가능한 기존 기능들과 비교해 봐야 한다. 그러면 원하는 시스템 중에서 기업 내에서 이미 이용 가능한 부분과 구축해야 할 부분이 드러나게 된다. 

이미 이용 가능한 기능과 필요한 기능과의 차이가 기업의 현재 기능과 원하는 기능의 간극을 나타낸다. 향후 시스템 설계자의 주요 업무는 전체 시스템을 설계하던 것에서부터 현재 기능에서 부족한 부분을 찾아내어 그 간극을 메우기 위해 최상의 수단을 설계하는 것으로 진화할 것이다.

이러한 기능 중심 아키텍처가 수월한 단계에는 아직 이르지 못했다. 전사적으로 어떤 서비스가 이용 가능한지 파악하는 능력은 심각하게 제한되어 있다. 솔직한 네트워크 관리자라면 해당 네트워크에서 이용 가능한 서비스 전체를 제대로 파악하지 못한다는 것을 인정할 것이다. 그 대신, 네트워크에 연결된 시스템, 각 시스템에 실행 중인 소프트웨어, 각 시스템에 열려 있는 포트와 프로토콜 등은 파악하고 있겠지만, 그 정보는 그러한 것들의 네트워크 수준 측면에 대해서만 알려 줄 뿐이고 사용 방식에 대해서는 어떻게 사용되고 있는지에 대해서는 아무 것도 드러내 주지 않는다. 

예컨대, 포트 8443이 열려 있고 HTTP 연결을 받아들이는 네트워크 상의 시스템은 간단한 웹 페이지들을 제공할 수도 있고 해당 인터페이스를 통해 여러 가지 REST 서비스를 제공할 수도 있다.

이와 같이 부족한 이해를 극복할 수단들이 일부 존재하지만 대부분은 수동 방식이다. 예를 들어, 기업에서 이용 가능한 서비스가 나열된 목록을 유지하려면 개발자들은 직접 배치한 서비스들을 추가하고 해당 목록을 관리해야 한다. 서비스 인터페이스를 거의 실시간으로 파악하여 목록으로 작성해 주는 자동화 수단이 더 효율적일 것이다. 단, 이는 추후에 따로 다뤄야 할 주제이다.

예외는 있다
시스템 작동 환경 때문에 전통적인 시스템 아키텍처가 살아남을 영역들이 있다. 기능 하나를 위해 기업 전체에 접근하는 것이 문제가 있는 운영 환경이라면 옛날 방식의 전면적인 시스템 설계가 필요하다. 일례로, 항공 운항 통제 시스템은 비행 안전과 관련된 기능을 지상에 호스팅 된 서비스를 호출하여 해결할 수는 없다. 이와 마찬가지로 위성 시스템 등 기타 임베디드 소프트웨어는 중요한 기능 일체를 가까운 곳에서 제공해야 한다.

기존의 시스템 아키텍처 작업 방식이 전부 사라지지는 않겠지만 시스템 아키텍처 작업 효율 개선 방법에 대한 고민은 진작 했어야 한다. 그래야만 오늘날 빠르게 진화하는 업무 환경을 보다 낫게 지원할 수 있기 때문이다.

* 존 맥도웰은 엔터프라이즈 아키텍트이자 시스템 엔지니어다. 엔터프라이즈 아키텍처, 데이터 통합, 복잡 시스템 분야의 글을 전문적으로 기고한다. ciokr@idg.co.kr
 



2019.05.27

칼럼 | 시스템 아키텍처의 미래

존 맥도웰 | CIO
우리가 인식하든, 인식하지 못하든 시스템 아키텍처의 진화가 이뤄지고 있다. 지난 수십 년 간 시스템 아키텍처는 건물 건축 양식과 비슷했다. 시스템이 해야 할 일을 결정하고, 필요한 주요 하부 시스템과 이들의 연결 방식을 파악하고, 계속 분해해 나가면서 상세 내용을 알게 되면 이를 이용해 개발 팀이 각 하부 시스템을 확장하고 이들을 통합해 원하는 시스템을 만들어낸다. 그러나 이러한 패턴이 최근 몇 년간 변화하고 있고 그 속도도 빨라지고 있다.
 
ⓒ Image Credit : Getty Images Bank


네트워크의 영향
1990년대 들어 네트워크 시스템이 일반화되면서 시스템 아키텍처 작업이 달라지기 시작했다. 클라이언트-서버 아키텍처가 지배적인 설계 패턴으로 등장함에 따라 네트워크 인터페이스가 포함되어야 했다. 시스템은 이제 더 이상 한 장소에 배치되어 정해진 터미널들로부터 사용하는 단일 개체가 아니었다. 

이후 시스템 아키텍처의 진화에 중대한 영향을 미친 것은 시스템 통합 니즈였다. 똑같은 데이터를 다른 여러 시스템에 입력하려면 시간이 많이 걸리고 오류가 생기기 쉽다는 것이 금방 드러나자, 데이터를 공유할 수 있도록 시스템 통합이 시도되기 시작했다. 

이는 서비스 지향 아키텍처(SOA)의 개발로 이어졌다. SOA의 기본 개념은 네트워크 상의 어떤 애플리케이션으로든 호출 가능한 서비스로 기능을 제공하자는 것이다. ‘서비스’란 원하는 기능에 대해 잘 정의된 인터페이스에 불과하다. SOA는 유동적으로 작성할 수 있는 애플리케이션의 시대를 약속했다. 새로운 업무적 필요가 생길 때마다 이를 충족하기 위해 애플리케이션의 코딩을 새로 하지 않아도 된다는 뜻이다. 

서비스의 부상
대대적인 홍보 속에 등장한 신기술들이 대개 그러하듯 SOA 역시 최초의 약속에 부응하지 못했다. 그러나 기대가 꺼진 지 10년이 지나서야 비로소 SOA 철학의 실질적인 장점이 빛을 발하고 있다. 

많은 기능들이 서비스로 이용 가능하게 되었고 이를 사용하는 기업들이 늘어났다. 일례로 페이스북, 구글 등은 모두 인증 서비스를 제공한다. 웹 사이트 운영자라면 사용자에게 사이트 전체 기능에 대한 접근을 허용하기에 앞서 인증을 해야 하는데 이 때 굳이 자체적인 인증 하부시스템을 호스팅할 필요가 없다. 서비스로 제공되는 것 중 하나를 가져다 쓰면 되기 때문이다. 마찬가지로 댓글 시스템, SNS 통합, 사용자 통계 등 많은 기능들 역시 서비스로 제공되고 있다. 클라우드 컴퓨팅 혁명의 본질은 결국 컴퓨터 하드웨어를 주문형 서비스로 변환시키는 것이다.

SOA 혁명은 비록 최초에 상상했던 형태는 아니지만 확실히 일어났다고 봐야 한다. 오늘날 기업 통합 작업은 시스템 인터페이스를 공개적으로 이용 가능하게 만드는 것에 대부분 집중되어 있다. 이를 흔히 ‘애플리케이션 프로그래밍 인터페이스(API) 우선 철학’이라고 한다.

API 우선 철학의 가장 유명한 사례는 ‘스티브 예게의 불평’이라는 글이다. 아마존의 API 우선 설계 철학을 채택하지 않은 구글을 책망하는 내용이다. 이 글의 요지는 모든 기능들을 API를 통해 네트워크 상에서 노출되어야 한다는 것이다. 그래야만 통합이 촉진될 뿐만 아니라 기업이 생산하는 (그리고 비용을 지불하는) 중복되는 기능의 양을 최소화할 수 있기 때문이다.

API가 시스템 아키텍처를 추동하는 방식
API 우선 철학이 가져온 효과는 무엇보다 개발자들이 스스로의 API를 문서화하여 알리도록 만든 것이다. 그런데 아마존의 API 우선 철학은 여러 시스템에 중복 기능을 개발하는 비용을 줄이는 것이 주요 목적이었다. 

보유 시스템을 몇 년에 한 번씩 전부 업데이트하는 기업은 거의 없기 때문에 API 우선 명령이 기업에 미치는 실질적인 효과가 나타나려면 시간이 걸릴 것이다. 그래도 시간이 지나면 그 효과는 자연적으로 느껴지게 된다. 특히 API 우선 명령이 ‘구축보다 재사용 먼저’ 명령과 결합될 때 그렇다. 말 그대로 개발자들은 새로운 기능을 구축하기에 앞서 먼저 기업에서 이미 이용 가능한 기능을 재사용해야 한다.

API를 통해 기능을 이용 가능하게 하는 시스템이 늘어나고 개발 팀은 구축 보다 먼저 재사용에 집중하게 되면, 신규 시스템 구축 작업이 기존 기능을 신규 기능으로 재작성 하는 작업으로 대체되는 시점이 오게 된다. 

매우 다양한 목적의 시스템들에 걸쳐 존재하는 중복의 양은 놀라울 정도이다. 대부분의 시스템에 필요한 것은 데이터 저장 및 검색, 사용자 인증 및 권한 부여, 텍스트 표시 및 그래픽 렌더링 기능 등이다. 

기업 내 기존 자원으로부터 재사용될 수 있는 기능은 수없이 많다. 시스템 개발 초기 시절에는 그나마 최소한으로 작동하는 시스템이라도 갖추려면 필요한 기능들을 일일이 만들어야 했다. 기본 기능의 많은 부분이 서비스로 이용 가능하게 되면서 시스템 설계 작업은 전체 시스템을 설계하던 것에서 기업 생태계 내의 주변 기능 개선 내용을 설계하는 것으로 진화하고 있다.

기능 중심 아키텍처(capability-focused architecture)를 향하여
계속해서 늘어나는 기능들을 특히 클라우드 환경에서 서비스로 이용 가능하도록 하는 기업 생태계가 대세화됐다. 클라우드 제공업체들은 앞다투어 더 많은 기능들을 제공하고 있으며, 몇 가지 서비스를 글루웨어(glueware)나 스크립트 언어로 이어 붙여 기본 시스템을 개발하는 것은 이미 가능하다. 

즉, 최소한으로 작동하는 기본 시스템이 몇 달이 아닌 몇 주 안에 만들어질 뿐만 아니라, 새로운 서비스들을 이어 붙이거나 서비스를 이용할 수 없는 경우에는 기성품 모듈을 설치하여 빠르게 개선 가능하다. 이런 환경에서는 시스템 구축 전에 몇 달에 걸쳐 세부 사항을 결정하는 설계 단계는 적합하지 않다. 시스템 아키텍처 및 설계에 대한 새로운 사고 방식이 필요하다.

이미 각종 서비스가 많은 기업에서 신규 시스템을 구축하려면 먼저 해당 시스템이 수행해야 할 기능을 명확하게 규정하고 이를 이미 서비스로 이용 가능한 기존 기능들과 비교해 봐야 한다. 그러면 원하는 시스템 중에서 기업 내에서 이미 이용 가능한 부분과 구축해야 할 부분이 드러나게 된다. 

이미 이용 가능한 기능과 필요한 기능과의 차이가 기업의 현재 기능과 원하는 기능의 간극을 나타낸다. 향후 시스템 설계자의 주요 업무는 전체 시스템을 설계하던 것에서부터 현재 기능에서 부족한 부분을 찾아내어 그 간극을 메우기 위해 최상의 수단을 설계하는 것으로 진화할 것이다.

이러한 기능 중심 아키텍처가 수월한 단계에는 아직 이르지 못했다. 전사적으로 어떤 서비스가 이용 가능한지 파악하는 능력은 심각하게 제한되어 있다. 솔직한 네트워크 관리자라면 해당 네트워크에서 이용 가능한 서비스 전체를 제대로 파악하지 못한다는 것을 인정할 것이다. 그 대신, 네트워크에 연결된 시스템, 각 시스템에 실행 중인 소프트웨어, 각 시스템에 열려 있는 포트와 프로토콜 등은 파악하고 있겠지만, 그 정보는 그러한 것들의 네트워크 수준 측면에 대해서만 알려 줄 뿐이고 사용 방식에 대해서는 어떻게 사용되고 있는지에 대해서는 아무 것도 드러내 주지 않는다. 

예컨대, 포트 8443이 열려 있고 HTTP 연결을 받아들이는 네트워크 상의 시스템은 간단한 웹 페이지들을 제공할 수도 있고 해당 인터페이스를 통해 여러 가지 REST 서비스를 제공할 수도 있다.

이와 같이 부족한 이해를 극복할 수단들이 일부 존재하지만 대부분은 수동 방식이다. 예를 들어, 기업에서 이용 가능한 서비스가 나열된 목록을 유지하려면 개발자들은 직접 배치한 서비스들을 추가하고 해당 목록을 관리해야 한다. 서비스 인터페이스를 거의 실시간으로 파악하여 목록으로 작성해 주는 자동화 수단이 더 효율적일 것이다. 단, 이는 추후에 따로 다뤄야 할 주제이다.

예외는 있다
시스템 작동 환경 때문에 전통적인 시스템 아키텍처가 살아남을 영역들이 있다. 기능 하나를 위해 기업 전체에 접근하는 것이 문제가 있는 운영 환경이라면 옛날 방식의 전면적인 시스템 설계가 필요하다. 일례로, 항공 운항 통제 시스템은 비행 안전과 관련된 기능을 지상에 호스팅 된 서비스를 호출하여 해결할 수는 없다. 이와 마찬가지로 위성 시스템 등 기타 임베디드 소프트웨어는 중요한 기능 일체를 가까운 곳에서 제공해야 한다.

기존의 시스템 아키텍처 작업 방식이 전부 사라지지는 않겠지만 시스템 아키텍처 작업 효율 개선 방법에 대한 고민은 진작 했어야 한다. 그래야만 오늘날 빠르게 진화하는 업무 환경을 보다 낫게 지원할 수 있기 때문이다.

* 존 맥도웰은 엔터프라이즈 아키텍트이자 시스템 엔지니어다. 엔터프라이즈 아키텍처, 데이터 통합, 복잡 시스템 분야의 글을 전문적으로 기고한다. ciokr@idg.co.kr
 

X