2016.04.21

ITWorld 용어풀이 | 마이크로서비스

박상훈 기자 | ITWorld

최근 들어 '마이크로서비스(Microservice)'라는 용어가 유행입니다. 소프트웨어 개발 방법론 관련 글이나 컨테이너 관련 기술 동향 등에 빠짐없이 언급됩니다. 'micro'라는 말 때문에 뭔가 작다는 뜻인 것 같은데, 선뜻 그 의미를 짐작하기가 쉽지 않습니다. 마이크로서비스라는 용어 자체가 최근에 만들어진 것은 아닙니다. 지난 10여 년에 걸쳐 서서히 특정 아키텍처를 지칭하는 용어로 자리를 잡았습니다.

이 말을 누가 만들었는지는 정확지 않지만, 본격적으로 알려진 계기는 지난 2014년 3월 유명 개발자인 제임스 루이스와 마틴 파울러가 발표한 글입니다. 그들은 마이크로서비스 아키텍처에 대해 '단일 애플리케이션을 작은 서비스의 집합으로 개발하는 접근 방식'이라고 정의했습니다. 거대한 단일 서비스로 개발하는 기존 '모놀리식(monolithic, 단일체)' 방식과 반대되는 개념으로 마이크로서비스를 본 것이죠.

 

레고 블록처럼 서비스를 조합해 앱을 만든다. (이미지 출처 : Flickr/Paul Downey)


상반되는 개념이 있다는 것은 마이크로서비스가 기존 방식의 불편한 점을 개선하는 대안이라는 의미이기도 합니다. 예를 들어 모놀리식 방식에서는 애플리케이션을 단일 개체로 개발합니다. 이는 선형 확장 등에서 장점이 있지만 만들어진 애플리케이션을 수정할 때는 여간 번거로운 것이 아닙니다. 사소한 수정인데 전체를 다 손봐야 하는 때도 있습니다. 그만큼 기간은 늘어나고 이에 따라 비용 부담도 커집니다.

반면 마이크로서비스는 전체 애플리케이션을 작은 서비스로 나눠 개발하고 이 서비스의 조합으로 애플리케이션 구실을 합니다. 마치 레고 블록을 조립한다고 생각하면 더 쉽습니다. 컴포넌트 형태여서 필요한 부분만 수정해 다시 조합할 수 있고, 각 서비스는 서로 종속되지 않으므로 새로운 서비스를 추가하기도 편합니다. 개발, 배포, 피드백 등 전 과정에서 모놀리식 아키텍처보다 단순하고 이를 관리하는 과정도 간단합니다.

또 다른 특징은 각 서비스가 표준화된 API로 통신한다는 점입니다. 결과물만 주고받기 때문에 각 서비스를 다른 언어로 개발해도 되는 것이죠. 이를 이용하면 완전히 새로운 개발방식도 상상할 수 있습니다. 거대한 웹 애플리케이션을 전 세계 여러 업체가 참여해 각자의 언어로 서비스를 개발한 후 이를 조합해 완성하는 식이죠. 관리를 어떻게 하느냐에 따라 개발 기간을 획기적으로 단축하고 생산성도 크게 개선할 수 있습니다.

SOA의 재탕이라는 지적이 있다. (이미지 출처 : Flickr/Ernesto Andrade)


이런 방식은 특히 가상화된 인프라를 기반으로 한 클라우드 애플리케이션에서 상당한 효율성을 가져옵니다. 넷플릭스가 대표주자인데, 마이크로서비스를 이용해 웹 애플리케이션의 성능을 최적화한 것으로 널리 알려져 있습니다. 사운드클라우드는 모놀리식으로 개발을 시작했다가 뒤늦게 마이크로서비스로 이행할 만큼 이 개념에 매료됐습니다. 국내에서도 티켓몬스터 같은 업체가 마이크로서비스 개념을 자사 서비스에 활발하게 도입하고 있습니다.

물론 약점도 있습니다. 파울러는 특히 2가지를 꼽습니다. 먼저 테스트입니다. 각 서비스가 정상 작동한다고 해도 이를 모은 애플리케이션이 정상 작동하는지 확인하는 것은 다른 이야기라는 것이죠. 어떤 서비스로 트래픽이 몰릴지 예측하기 쉽지 않다는 것도 문제입니다. 특정 서비스에 병목이 걸리면 전체 애플리케이션에 문제가 발생할 수 있으므로, 이에 보완하는 리소스 풀이 필요합니다. AWS와 같은 클라우드가 현실적인 대안이겠죠.

더 근본적인 지적도 있습니다. 사실 마이크로서비스 개념은 5~6년 전 유행한 '서비스지향아키텍처(SOA)'와 비슷합니다. SOA는 일정한 기능을 담당하는 컴포넌트의 조합으로 애플리케이션을 만들고, 컴포넌트를 재사용해 생산성을 높인다는 것이었죠. 'SOA의 재탕'이라는 비아냥이 나오는 이유입니다. 특히 당시 많은 업체가 'SOA 솔루션'을 팔았는데, 성능은 기대 이하이고 오히려 개발작업이 늘어난 경우도 있어 역풍을 맞았습니다.

컨테이너 기술이 부상하면서 기대를 모으고 있다. (이미지 출처 : Flickr/Vasile Cotovanu)


마이크로서비스는 앞으로 어떻게 발전해 갈까요? 일단 주변 환경은 긍정적입니다. 컨테이너 기술이 급부상하면서 클라우드 환경에서 이를 활용할 수 있는 여건이 무르익고 있습니다. 모든 기업이 비용 절감과 빠른 시장대응을 추구하면서 개발 수명주기 전체를 더 빠르게하는 아키텍처로 마이크로서비스가 주목받고 있습니다. 기업 내 개발 문화 자체도 더 유연해지고 있어, 과거 SOA 논란이 한창이던 때와는 차이가 있는 것 같기도 합니다.

흥미로운 것은 일부 기업은 '마이크로서비스'라는 용어가 알려지기 전부터 이미 내부적으로 이런 방법론을 추구해 왔다는 것입니다. 이를 공개적으로 지향하는 기업 중에는 신생이거나 시스템을 새로 구축한 사례가 많다는 것도 눈에 띕니다. 결국, 많은 IT 용어가 그렇듯 기업의 개발 환경은 계속 진화해 왔고 이제서야 이름을 갖게 됐다는 것이죠. 앞으로 마케팅 용어나 제품보다 실제 구축사례에 주목해야 하는 이유입니다. editor@itworld.co.kr


2016.04.21

ITWorld 용어풀이 | 마이크로서비스

박상훈 기자 | ITWorld

최근 들어 '마이크로서비스(Microservice)'라는 용어가 유행입니다. 소프트웨어 개발 방법론 관련 글이나 컨테이너 관련 기술 동향 등에 빠짐없이 언급됩니다. 'micro'라는 말 때문에 뭔가 작다는 뜻인 것 같은데, 선뜻 그 의미를 짐작하기가 쉽지 않습니다. 마이크로서비스라는 용어 자체가 최근에 만들어진 것은 아닙니다. 지난 10여 년에 걸쳐 서서히 특정 아키텍처를 지칭하는 용어로 자리를 잡았습니다.

이 말을 누가 만들었는지는 정확지 않지만, 본격적으로 알려진 계기는 지난 2014년 3월 유명 개발자인 제임스 루이스와 마틴 파울러가 발표한 글입니다. 그들은 마이크로서비스 아키텍처에 대해 '단일 애플리케이션을 작은 서비스의 집합으로 개발하는 접근 방식'이라고 정의했습니다. 거대한 단일 서비스로 개발하는 기존 '모놀리식(monolithic, 단일체)' 방식과 반대되는 개념으로 마이크로서비스를 본 것이죠.

 

레고 블록처럼 서비스를 조합해 앱을 만든다. (이미지 출처 : Flickr/Paul Downey)


상반되는 개념이 있다는 것은 마이크로서비스가 기존 방식의 불편한 점을 개선하는 대안이라는 의미이기도 합니다. 예를 들어 모놀리식 방식에서는 애플리케이션을 단일 개체로 개발합니다. 이는 선형 확장 등에서 장점이 있지만 만들어진 애플리케이션을 수정할 때는 여간 번거로운 것이 아닙니다. 사소한 수정인데 전체를 다 손봐야 하는 때도 있습니다. 그만큼 기간은 늘어나고 이에 따라 비용 부담도 커집니다.

반면 마이크로서비스는 전체 애플리케이션을 작은 서비스로 나눠 개발하고 이 서비스의 조합으로 애플리케이션 구실을 합니다. 마치 레고 블록을 조립한다고 생각하면 더 쉽습니다. 컴포넌트 형태여서 필요한 부분만 수정해 다시 조합할 수 있고, 각 서비스는 서로 종속되지 않으므로 새로운 서비스를 추가하기도 편합니다. 개발, 배포, 피드백 등 전 과정에서 모놀리식 아키텍처보다 단순하고 이를 관리하는 과정도 간단합니다.

또 다른 특징은 각 서비스가 표준화된 API로 통신한다는 점입니다. 결과물만 주고받기 때문에 각 서비스를 다른 언어로 개발해도 되는 것이죠. 이를 이용하면 완전히 새로운 개발방식도 상상할 수 있습니다. 거대한 웹 애플리케이션을 전 세계 여러 업체가 참여해 각자의 언어로 서비스를 개발한 후 이를 조합해 완성하는 식이죠. 관리를 어떻게 하느냐에 따라 개발 기간을 획기적으로 단축하고 생산성도 크게 개선할 수 있습니다.

SOA의 재탕이라는 지적이 있다. (이미지 출처 : Flickr/Ernesto Andrade)


이런 방식은 특히 가상화된 인프라를 기반으로 한 클라우드 애플리케이션에서 상당한 효율성을 가져옵니다. 넷플릭스가 대표주자인데, 마이크로서비스를 이용해 웹 애플리케이션의 성능을 최적화한 것으로 널리 알려져 있습니다. 사운드클라우드는 모놀리식으로 개발을 시작했다가 뒤늦게 마이크로서비스로 이행할 만큼 이 개념에 매료됐습니다. 국내에서도 티켓몬스터 같은 업체가 마이크로서비스 개념을 자사 서비스에 활발하게 도입하고 있습니다.

물론 약점도 있습니다. 파울러는 특히 2가지를 꼽습니다. 먼저 테스트입니다. 각 서비스가 정상 작동한다고 해도 이를 모은 애플리케이션이 정상 작동하는지 확인하는 것은 다른 이야기라는 것이죠. 어떤 서비스로 트래픽이 몰릴지 예측하기 쉽지 않다는 것도 문제입니다. 특정 서비스에 병목이 걸리면 전체 애플리케이션에 문제가 발생할 수 있으므로, 이에 보완하는 리소스 풀이 필요합니다. AWS와 같은 클라우드가 현실적인 대안이겠죠.

더 근본적인 지적도 있습니다. 사실 마이크로서비스 개념은 5~6년 전 유행한 '서비스지향아키텍처(SOA)'와 비슷합니다. SOA는 일정한 기능을 담당하는 컴포넌트의 조합으로 애플리케이션을 만들고, 컴포넌트를 재사용해 생산성을 높인다는 것이었죠. 'SOA의 재탕'이라는 비아냥이 나오는 이유입니다. 특히 당시 많은 업체가 'SOA 솔루션'을 팔았는데, 성능은 기대 이하이고 오히려 개발작업이 늘어난 경우도 있어 역풍을 맞았습니다.

컨테이너 기술이 부상하면서 기대를 모으고 있다. (이미지 출처 : Flickr/Vasile Cotovanu)


마이크로서비스는 앞으로 어떻게 발전해 갈까요? 일단 주변 환경은 긍정적입니다. 컨테이너 기술이 급부상하면서 클라우드 환경에서 이를 활용할 수 있는 여건이 무르익고 있습니다. 모든 기업이 비용 절감과 빠른 시장대응을 추구하면서 개발 수명주기 전체를 더 빠르게하는 아키텍처로 마이크로서비스가 주목받고 있습니다. 기업 내 개발 문화 자체도 더 유연해지고 있어, 과거 SOA 논란이 한창이던 때와는 차이가 있는 것 같기도 합니다.

흥미로운 것은 일부 기업은 '마이크로서비스'라는 용어가 알려지기 전부터 이미 내부적으로 이런 방법론을 추구해 왔다는 것입니다. 이를 공개적으로 지향하는 기업 중에는 신생이거나 시스템을 새로 구축한 사례가 많다는 것도 눈에 띕니다. 결국, 많은 IT 용어가 그렇듯 기업의 개발 환경은 계속 진화해 왔고 이제서야 이름을 갖게 됐다는 것이죠. 앞으로 마케팅 용어나 제품보다 실제 구축사례에 주목해야 하는 이유입니다. editor@itworld.co.kr


X