2016.01.05

2016년 컨테이너 기술이 가져올 6가지 변화

Serdar Yegulalp | ARN
거의 모든 주요 IT 솔루션이 전면적인 지원을 약속하면서 컨테이너는 앞으로 수년 동안 IT를 계속 변화시켜 나갈 기술로 확고히 자리 잡았다. 2016년 한 해 동안 컨테이너와 관련 생태계가 어떻게 진화하고 IT에 어떤 영향을 미칠 것인지 6가지 주요 변화를 점쳐 본다.

더 많은 실험
이전에 컨테이너가 사용되지 않았던 분야에 컨테이너를 사용하는 것뿐만 아니라 컨테이너 기술 자체를 변형시킬 방법을 찾는 실험도 진행될 것이다.

코어OS나 랜처OS(RancherOS)와 같은 프로젝트와 다양한 클라우드 기반 컨테이너 서비스는 모두 컨테이너 자체에 대한 긍정적이고 생산적인 실험의 예다. VM웨어와 같은 업체 역시 컨테이너를 이용해 자사 제품군을 강화할 방법을 찾고 있다.

다음 단계의 실험은 컨테이너를 유니커널(Unikernel) 같은 기술과 함께 동작하는 방법을 찾는 것이 될 수도 있다. 이런 기술은 컨테이너보다 더 높은 수준의 격리와 효율성을 가져다 준다. 물론 각 애플리케이션마다 맞춤형 편집이 필요하다는 단점이 있다.

윈도우의 변화
윈도우가 컨테이너로 인해 변화하고 있다는 사실은 컨테이너 기술의 영향력을 보여줄 뿐만 아니라 마이크로소프트의 새로운 체제를 이야기한다.

이미 도커와 하이퍼-V 컨테이너를 통해 윈도우 서버에서 컨테이너 기술을 사용하는 것이 어떤 것이지 확인했다. 이 기술은 올해 하반기에 정식으로 공개될 예정이며, 나노 서버에 중점을 둔 컨테이너도 발표될 것이다. 컨테이너화를 통해 드러난 가능성, 즉 한층 더 모듈화된 윈도우 서버는 이제 막 첫걸음을 뗀 상태이지만, 마이크로소프트가 자사의 하이브리드 애저 서비스 패브릭으로 로컬과 원격 데이터센터 모두에서 컨테이너를 온전하게 활용하고자 한다는 것은 분명하다.

컨테이너 지원은 기본 중의 기본
컨테이너를 지원하지 않는 솔루션은 문제에 봉착할 것이다. 때문에 컨테이너 지원은 많은 소프트웨어 기술에서 사치품이나 선택사항이 아니라 필수 요소가 될 것이다. 하지만 단순히 컨테이너를 지원하는 것만으로는 충분하지 않다. 이미 컨테이너 관련 창의적인 작업을 구성하는 기준은 상당히 높아져 있으며, 앞으로도 계속 높아질 것이다.

컨테이너를 위한 개방형 커뮤니티의 출현
2015년의 주요 발전은 컨테이너의 개발과 사용을 촉진하기 위한 다소의 컨소시엄을 만드는 것이었다. 오픈 컨테이너 이니셔티브(Open Container Initiative)와 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 대표적인 예이다.

클러스터HQ의 공동 설립자이자 CTO인 루크 마스덴은 “마케팅 예산이 아니라 기술적인 이점에 의해 커뮤니티가 움직이면서 실제 개발자를 끌어들이는 컨테이너 프로젝트는 빠르게 변화하는 컨테이너 생태계에서 표준으로 받아들여질 것이다”라고 강조했다.

관건은 이들 커뮤니티가 단지 좋은 의도를 퍼트리는 것 이상의 일을 해낼 수 있는지 여부이다. 이들 커뮤니티는 기업 IT의 미래 주도권을 다투는 대리전의 장이 아니라 컨테이너가 실질적으로 발전해 나갈 수 있도록 기술의 성능과 다양한 가능성을 증명해야 한다.

더 다양하고 향상된 툴
컨테이너에 놀라는 단계는 이미 지나갔고, 이제 내부 관찰과 모니터링, 디버깅, 배치, 관리, 오케스트레이션을 위한 발전된 툴을 개발해야 할 시기이다.

이 작업은 더 많은 인프라가 컨테이너로 이전되고 마이크로서비스를 통해 배포되면서 훨씬 더 중요해질 것이다. 많은 툴이 서드파티 업체들에게 의해 만들어지겠지만, 그것만으로는 충분한 해법이 되지 않을 가능성이 높다. 핵심 기술로 해결해야 할 문제와 서드파티 툴이 담당해야 할 부분에 대한 논의도 필요해질 것이다.

바람직한 컨테이너에 대한 논쟁
이 논쟁은 도커가 원본 컴포넌트로 얼마나 많은 역할을 해야 하고, 서드파티는 얼마나 많은 비중을 맡아야 하는지에 대한 논쟁으로 시작됐다. 도커의 “배터리는 포함되어 있지만 선택 사항”이라는 접근 전략은 이런 논쟁에 대응하기 위해 만들어진 것이다. 즉 개방형 API를 기반으로 어떤 기본 포함 기능도 누구나 다른 기능으로 대체할 수 있다는 것이다.

하지만 컨테이너가 다양한 환경의 서비스에 적용되면서 이런 기능성 역시 문제가 될 있다. 그리고 최소한의 요구조건을 선호하는 사용자들은 컨테이너가 이런 식으로 확장되는 것을 좋아하지 않는다. 불필요한 요소가 가득 한 VM에 대한 대안으로 등장한 경량화된 기술이 컨테이너인데, 자칫 컨테이너 자체가 무질서하게 퍼져나갈 수 있기 때문이다. 관련 커뮤니티가 이런 일이 발행하지 않도록 노력해 주기를 기대해 본다.  editor@itworld.co.kr



2016.01.05

2016년 컨테이너 기술이 가져올 6가지 변화

Serdar Yegulalp | ARN
거의 모든 주요 IT 솔루션이 전면적인 지원을 약속하면서 컨테이너는 앞으로 수년 동안 IT를 계속 변화시켜 나갈 기술로 확고히 자리 잡았다. 2016년 한 해 동안 컨테이너와 관련 생태계가 어떻게 진화하고 IT에 어떤 영향을 미칠 것인지 6가지 주요 변화를 점쳐 본다.

더 많은 실험
이전에 컨테이너가 사용되지 않았던 분야에 컨테이너를 사용하는 것뿐만 아니라 컨테이너 기술 자체를 변형시킬 방법을 찾는 실험도 진행될 것이다.

코어OS나 랜처OS(RancherOS)와 같은 프로젝트와 다양한 클라우드 기반 컨테이너 서비스는 모두 컨테이너 자체에 대한 긍정적이고 생산적인 실험의 예다. VM웨어와 같은 업체 역시 컨테이너를 이용해 자사 제품군을 강화할 방법을 찾고 있다.

다음 단계의 실험은 컨테이너를 유니커널(Unikernel) 같은 기술과 함께 동작하는 방법을 찾는 것이 될 수도 있다. 이런 기술은 컨테이너보다 더 높은 수준의 격리와 효율성을 가져다 준다. 물론 각 애플리케이션마다 맞춤형 편집이 필요하다는 단점이 있다.

윈도우의 변화
윈도우가 컨테이너로 인해 변화하고 있다는 사실은 컨테이너 기술의 영향력을 보여줄 뿐만 아니라 마이크로소프트의 새로운 체제를 이야기한다.

이미 도커와 하이퍼-V 컨테이너를 통해 윈도우 서버에서 컨테이너 기술을 사용하는 것이 어떤 것이지 확인했다. 이 기술은 올해 하반기에 정식으로 공개될 예정이며, 나노 서버에 중점을 둔 컨테이너도 발표될 것이다. 컨테이너화를 통해 드러난 가능성, 즉 한층 더 모듈화된 윈도우 서버는 이제 막 첫걸음을 뗀 상태이지만, 마이크로소프트가 자사의 하이브리드 애저 서비스 패브릭으로 로컬과 원격 데이터센터 모두에서 컨테이너를 온전하게 활용하고자 한다는 것은 분명하다.

컨테이너 지원은 기본 중의 기본
컨테이너를 지원하지 않는 솔루션은 문제에 봉착할 것이다. 때문에 컨테이너 지원은 많은 소프트웨어 기술에서 사치품이나 선택사항이 아니라 필수 요소가 될 것이다. 하지만 단순히 컨테이너를 지원하는 것만으로는 충분하지 않다. 이미 컨테이너 관련 창의적인 작업을 구성하는 기준은 상당히 높아져 있으며, 앞으로도 계속 높아질 것이다.

컨테이너를 위한 개방형 커뮤니티의 출현
2015년의 주요 발전은 컨테이너의 개발과 사용을 촉진하기 위한 다소의 컨소시엄을 만드는 것이었다. 오픈 컨테이너 이니셔티브(Open Container Initiative)와 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation)이 대표적인 예이다.

클러스터HQ의 공동 설립자이자 CTO인 루크 마스덴은 “마케팅 예산이 아니라 기술적인 이점에 의해 커뮤니티가 움직이면서 실제 개발자를 끌어들이는 컨테이너 프로젝트는 빠르게 변화하는 컨테이너 생태계에서 표준으로 받아들여질 것이다”라고 강조했다.

관건은 이들 커뮤니티가 단지 좋은 의도를 퍼트리는 것 이상의 일을 해낼 수 있는지 여부이다. 이들 커뮤니티는 기업 IT의 미래 주도권을 다투는 대리전의 장이 아니라 컨테이너가 실질적으로 발전해 나갈 수 있도록 기술의 성능과 다양한 가능성을 증명해야 한다.

더 다양하고 향상된 툴
컨테이너에 놀라는 단계는 이미 지나갔고, 이제 내부 관찰과 모니터링, 디버깅, 배치, 관리, 오케스트레이션을 위한 발전된 툴을 개발해야 할 시기이다.

이 작업은 더 많은 인프라가 컨테이너로 이전되고 마이크로서비스를 통해 배포되면서 훨씬 더 중요해질 것이다. 많은 툴이 서드파티 업체들에게 의해 만들어지겠지만, 그것만으로는 충분한 해법이 되지 않을 가능성이 높다. 핵심 기술로 해결해야 할 문제와 서드파티 툴이 담당해야 할 부분에 대한 논의도 필요해질 것이다.

바람직한 컨테이너에 대한 논쟁
이 논쟁은 도커가 원본 컴포넌트로 얼마나 많은 역할을 해야 하고, 서드파티는 얼마나 많은 비중을 맡아야 하는지에 대한 논쟁으로 시작됐다. 도커의 “배터리는 포함되어 있지만 선택 사항”이라는 접근 전략은 이런 논쟁에 대응하기 위해 만들어진 것이다. 즉 개방형 API를 기반으로 어떤 기본 포함 기능도 누구나 다른 기능으로 대체할 수 있다는 것이다.

하지만 컨테이너가 다양한 환경의 서비스에 적용되면서 이런 기능성 역시 문제가 될 있다. 그리고 최소한의 요구조건을 선호하는 사용자들은 컨테이너가 이런 식으로 확장되는 것을 좋아하지 않는다. 불필요한 요소가 가득 한 VM에 대한 대안으로 등장한 경량화된 기술이 컨테이너인데, 자칫 컨테이너 자체가 무질서하게 퍼져나갈 수 있기 때문이다. 관련 커뮤니티가 이런 일이 발행하지 않도록 노력해 주기를 기대해 본다.  editor@itworld.co.kr

X