2020.09.23

클라우드 네이티브와 데브옵스… BT가 개발 문화를 혁신한 비결

Scott Carey | InfoWorld
클라우드와 컨테이너형 워크로드로 전환하면 기존 기업이 직면했던 많은 문제를 해결할 수 있다. 그러나 클라우드 네이티브라는 거대한 흐름이 구식 기술이라는 움직일 수 없는 장애물을 처음 만나면 어떻게 될까.
 
© BT

바로 이것이 170년 역사의 영국 통신 기업 브리티시 텔레콤(BT)이 직면한 현재 상황이다. BT는 크고 다양한 개발자 집단을 활용해 안전하고 지속 가능한 방식으로 클라우드 네이티브 툴과 기술을 도입하려 노력하고 있다. 이를 통해 OTT 미디어의 확산과 5G 연결성 시대에 빠르게 변화하는 고객의 기대에 부응하고 경쟁 업체와의 격차를 더 벌린다는 구상이다.

BT의 소프트웨어 엔지니어링 탁월성 책임자인 라제시 프렘찬드란은 “우리는 과거에 잘 활용했던 구식 기술과 코드를 많이 가지고 있다. 지금은 우리 개발자에게 기존 스택에 의해 제약이 되는 바로 그것이다. 일단, 이 점을 인정하는 것이 중요하다. 이처럼 모든 기술이 새로운 환경에 적응할 수 있는 것은 아니며 모든 아키텍처와 설계에는 제약이 있기 마련이다"라고 말했다.

BT의 엔지니어링 전문가들은 컨테이너와 쿠버네티스로의 점진적인 전환과 이를 활용한 현대적인 클라우드 서비스가 개발자의 반복적인 일상 업무를 줄일 것으로 기대하고 있다.
 

모노리스(monoliths)에서 컨테이너로

BT는 느리지만 확실히 기존 워크로드를 통합하고 현대화할 방안을 모색하고 있다. 시작은 컨테이너와 쿠버네티스지만 프렘찬드란은 컨테이너를 마치 만병통치약처럼 보는 이들을 경계한다.

그는 “우리가 실제로 해야 할 일은 무엇을 컨테이너로 구현할 수 있는 알아내는 것이다. 모노리스 방식으로 개발한 구성요소를 50개 가지고 있고, 이들 모두가 하드 코딩된 의존성과 일부 구식 기술로 얽혀 있다고 하자. 이때는 다음과 같은 질문을 가장 먼저 던져야 한다. 무엇을 컨테이너로 만들 것인가? 다른 것에게 영향을 주지 않으려고 노력하는 그 유닛은 어디에 있는가? 바로 이 2가지가 대부분의 기업이 직면한 가장 큰 어려움이다”라고 말했다.

BT는 이러한 과제를 해결하기 위해 플랫폼팀을 새로 만들었다. 여기서 애플리케이션팀이 컨테이너 가능 요소를 식별하고 퍼블릭 클라우드 또는 서비스형 플랫폼(PaaS)에서 호스팅할 수 있는 최적의 환경을 전담해 찾아낸다. 이러한 작업은 BT의 모든 엔지니어가 워크로드를 현대화하려고 할 때, 즉, 워크로드를 얼마나 느슨하게 결합할지, 기존 스택에 영향을 미치지 않고 효과적으로 서비스를 격리하고 컨테이너화 할 수 있는지를 고려할 때 공통적인 고려사항이 됐다.
 

모든 길은 PaaS로 통한다

BT는 인프라 측면에서는 어느 정도 선택의 여지가 있지만, 애플리케이션에 대한 결정을 단순화해 일관성을 확보한다는 구상이다. 물론 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드 플랫폼 등 3가지 주요 서비스형 인프라(IaaS)를 모두 고려한다. 가능한 경우 플랫폼팀은 개발자에게 관리형 쿠버네티스 서비스를 사용하도록 하거나, 더 나은 방식으로 탄주 애플리케이션 서비스(Tanzu Application Service), 공급업체 VM웨어의 PaaS 및 자체 TKG(Tanzu Kubernetes Grid)를 쓰도록 한다.

프렘찬드란은 이에 대해 "개발자들에 일정한 제한을 둬야 한다. 그렇지 않으면 보통은 가능한 가장 큰 옵션을 선택한다. 이런 식으로 모든 것을 도커(Docker) 컨테이너에 담으면 더 인프라만 좋아진, 기존과 똑같은 괴물을 운영하게 된다. 이런 방식으로는 기존에 기업이 고민했던 문제를 해결하지 못한다”라고 말했다. 실제로 현업과 IT팀 간의 인프라를 둘러싼 밀고 당기기가 시작되면 온프레미스는 물론 퍼블릭 클라우드 환경에 걸쳐 일관된 관리형 쿠버네티스 레이어를 사용할 수 있는 TKG가 선호된다.

프렘찬드란은 “이를 이용하면 내일 클라우드 업체를 교체할 수도 있고, 워크로드를 온프레미스에서 클라우드로 이동시킬 수도 있다. 결과적으로 기본 IaaS에 종속되지 않는 쿠버네티스 제어 영역이 필요하다”라고 말했다.
 
© BT
 

오토 미션 대신 수동을 사용할 이유가 있을까

그렇다고 해서 BT의 일부 개발자가 여전히 쿠버네티스를 거부한다는 의미는 아니다. 프렘찬드란은 “마치 오토 자동차를 운전하는 것과 같다. 하지만 여전히 기어를 바꾸는 느낌과 클러치를 좋아하는 마니아도 있다. TKG를 이용할 수 있는 상황에서 무엇을 원하는 것인가가 아니라 구체적으로 무엇이 필요한지 물어보는 것이 더 중요하다. 쿠버네티스는 어렵다. 우리는 규모에 맞게 이를 사용하려고 하고, 개발자에게 애플리케이션 논리에 초점을 맞추고 어려운 일이 자동화되도록 해달라고 부탁한다”라고 덧붙였다.

물론 자체 관리형 쿠버네티스를 아예 고려하지 않는 것은 아니다. 단지 개발자가 그 미세한 수준의 통제를 정말로 필요로 하는 경우만으로 한정돼야 한다. 다른 모든 것들은 공급업체가 처리하도록 방치하면 안 된다는 의미다. 프렘찬드란은 “결국은 끝이 없는 힘겨루기다. 사람들이 기본적으로 쿠버네티스를 원하기 때문이다. 처음에는 개발자에게 더 규범적이어야 한다. 그러고 나서 점점 성숙할수록 독자적인 선택을 하도록 허용해야 한다"라고 말했다.
 

훈련과 개발

이러한 원칙과 프레임워크가 BT 개발자 커뮤니티 전체에 구축되면, 다음 과제는 사내 엔지니어와 외부 파트너를 위해 문서화하고 널리 알려 이를 확장하는 것이다. 일부 개발자가 쿠버네티스로 손을 담근다는 것은 새로운 전문 분야가 전사적으로 생겨나기 시작한다는 것을 의미한다. 이는 결코 나쁜 일이 아니다. 특히 소수의 존경 받는 개발자가 힘들 수도 있는 새로운 기술을 전파할 때 더 그렇다.

프렘찬드란은 “표준이 확산하는 과정을 살펴보면, 전체적인 아키텍처 표준과 정책을 살펴보는 엔터프라이즈 아키텍처가 있고, 레벨이 낮고 제품에 특화된 솔루션 설계자가 있으며, 마지막으로 우리는 뛰어난 엔지니어들을 '전문 엔지니어'라고 부르는데, 다른 개발자들의 존경을 받는 핵심 인플루언서가 있다"라고 말했다.

BT는 파트너와의 협업을 강화하기 위해 새로운 소프트웨어 엔지니어링 핸드북과 내부 위키(wiki)를 포함한 최신 문서로 새로운 방향을 제시하고 속도를 높이기 위해 이벤트와 세션을 진행했다. 이미 팬데믹 이전에 로드쇼를 시작했다. 그는 “클라우드로 나아가면서 개발자에게 스스로 학습하라고 톱다운 방식의 강요할 수는 없다. 우리가 클라우드를 중심으로 진로를 개발할 수 있는 온라인 e-러닝 플랫폼과 애자일, 데브옵스 및 관련 기술 모두를 확보해 인증 프로그램에 많은 투자를 한 이유다"라고 말했다.

최근 BT는 이렇게 만든 지식과 기술을 조직 전체로 확장하고 있다. 프렘찬드란은 “우리는 워크로드가 이동 가능한 경우 이를 다루는 요령을 터득했다. 이제는 모든 개발자가 하이브리드 클라우드 워크로드를 이해하고 다른 사람이 자신의 스택을 현대화할 수 있도록 훈련할 수 있는 기술을 갖추어야 한다”라고 말했다.
 

그다음 단계

이 모든 것이 달성되면, 프렘찬드란은 이전에 가능했던 것보다 훨씬 빠르게 필요한 서비스를 배치하는 더 행복한 개발자 커뮤니티를 관리하게 될 것이다. 그는 “데브옵스가 가능해지려면 인프라 프로비저닝 속도는 더 빨라져야 한다. 물론 속도만이 아니다. 데브옵스는 상호 연결된 문제 집합이다. 고객은 빠른 서비스를 원하므로 기업도 빠르게 내놓아야 하지만 이에 관여하는 팀은 서로 단절돼 있다. 반면 쿠버네티스와 다른 클라우드 네이티브 접근방식은 이러한 모든 팀을 단일한 방법론으로 통합할 수 있다"라고 말했다.

향후 몇 년 동안 프렘 찬드란은 더 많은 애플리케이션을 클라우드 네이티브의 마이크로 서비스 기반 아키텍처로 전환하고, ‘완전히 제로 터치 구현’을 위한 데브섹옵스(DevSecOps) 관행을 구현한다는 구상이다. 개발 그룹 전체에서 재사용 가능한 소프트웨어 구성요소의 수도 늘릴 계획이다. 예를 들어, 누군가가 비용청구 구성요소를 개발하기로 하면, 애플리케이션 내에서 고객에게 청구서를 발행해야 하는 사람이 이를 사용하는 식이다. 일단, 이상적인 세계에서는 그렇다.

프렘찬드란의 궁극적인 목표는 구식 기술이나 인프라에 얽매이지 않고 필요한 만큼 빠르게 움직일 수 있는 개발자 커뮤니티다. 그는 "애자일은 단순히 빨리 가는 것이 아니라 빨리 가는 선택을 하는 것이다. 둘은 완전히 다르다. 차가 시속 250마일을 달릴 수 있다고 해서 항상 그 속도로 간다는 뜻은 아니다. 하지만 필요하다면 그렇게 빨리 달릴 수 있는 차를 갖고 싶은 것이다”라고 말했다. editor@itworld.co.kr



2020.09.23

클라우드 네이티브와 데브옵스… BT가 개발 문화를 혁신한 비결

Scott Carey | InfoWorld
클라우드와 컨테이너형 워크로드로 전환하면 기존 기업이 직면했던 많은 문제를 해결할 수 있다. 그러나 클라우드 네이티브라는 거대한 흐름이 구식 기술이라는 움직일 수 없는 장애물을 처음 만나면 어떻게 될까.
 
© BT

바로 이것이 170년 역사의 영국 통신 기업 브리티시 텔레콤(BT)이 직면한 현재 상황이다. BT는 크고 다양한 개발자 집단을 활용해 안전하고 지속 가능한 방식으로 클라우드 네이티브 툴과 기술을 도입하려 노력하고 있다. 이를 통해 OTT 미디어의 확산과 5G 연결성 시대에 빠르게 변화하는 고객의 기대에 부응하고 경쟁 업체와의 격차를 더 벌린다는 구상이다.

BT의 소프트웨어 엔지니어링 탁월성 책임자인 라제시 프렘찬드란은 “우리는 과거에 잘 활용했던 구식 기술과 코드를 많이 가지고 있다. 지금은 우리 개발자에게 기존 스택에 의해 제약이 되는 바로 그것이다. 일단, 이 점을 인정하는 것이 중요하다. 이처럼 모든 기술이 새로운 환경에 적응할 수 있는 것은 아니며 모든 아키텍처와 설계에는 제약이 있기 마련이다"라고 말했다.

BT의 엔지니어링 전문가들은 컨테이너와 쿠버네티스로의 점진적인 전환과 이를 활용한 현대적인 클라우드 서비스가 개발자의 반복적인 일상 업무를 줄일 것으로 기대하고 있다.
 

모노리스(monoliths)에서 컨테이너로

BT는 느리지만 확실히 기존 워크로드를 통합하고 현대화할 방안을 모색하고 있다. 시작은 컨테이너와 쿠버네티스지만 프렘찬드란은 컨테이너를 마치 만병통치약처럼 보는 이들을 경계한다.

그는 “우리가 실제로 해야 할 일은 무엇을 컨테이너로 구현할 수 있는 알아내는 것이다. 모노리스 방식으로 개발한 구성요소를 50개 가지고 있고, 이들 모두가 하드 코딩된 의존성과 일부 구식 기술로 얽혀 있다고 하자. 이때는 다음과 같은 질문을 가장 먼저 던져야 한다. 무엇을 컨테이너로 만들 것인가? 다른 것에게 영향을 주지 않으려고 노력하는 그 유닛은 어디에 있는가? 바로 이 2가지가 대부분의 기업이 직면한 가장 큰 어려움이다”라고 말했다.

BT는 이러한 과제를 해결하기 위해 플랫폼팀을 새로 만들었다. 여기서 애플리케이션팀이 컨테이너 가능 요소를 식별하고 퍼블릭 클라우드 또는 서비스형 플랫폼(PaaS)에서 호스팅할 수 있는 최적의 환경을 전담해 찾아낸다. 이러한 작업은 BT의 모든 엔지니어가 워크로드를 현대화하려고 할 때, 즉, 워크로드를 얼마나 느슨하게 결합할지, 기존 스택에 영향을 미치지 않고 효과적으로 서비스를 격리하고 컨테이너화 할 수 있는지를 고려할 때 공통적인 고려사항이 됐다.
 

모든 길은 PaaS로 통한다

BT는 인프라 측면에서는 어느 정도 선택의 여지가 있지만, 애플리케이션에 대한 결정을 단순화해 일관성을 확보한다는 구상이다. 물론 아마존 웹 서비스, 마이크로소프트 애저, 구글 클라우드 플랫폼 등 3가지 주요 서비스형 인프라(IaaS)를 모두 고려한다. 가능한 경우 플랫폼팀은 개발자에게 관리형 쿠버네티스 서비스를 사용하도록 하거나, 더 나은 방식으로 탄주 애플리케이션 서비스(Tanzu Application Service), 공급업체 VM웨어의 PaaS 및 자체 TKG(Tanzu Kubernetes Grid)를 쓰도록 한다.

프렘찬드란은 이에 대해 "개발자들에 일정한 제한을 둬야 한다. 그렇지 않으면 보통은 가능한 가장 큰 옵션을 선택한다. 이런 식으로 모든 것을 도커(Docker) 컨테이너에 담으면 더 인프라만 좋아진, 기존과 똑같은 괴물을 운영하게 된다. 이런 방식으로는 기존에 기업이 고민했던 문제를 해결하지 못한다”라고 말했다. 실제로 현업과 IT팀 간의 인프라를 둘러싼 밀고 당기기가 시작되면 온프레미스는 물론 퍼블릭 클라우드 환경에 걸쳐 일관된 관리형 쿠버네티스 레이어를 사용할 수 있는 TKG가 선호된다.

프렘찬드란은 “이를 이용하면 내일 클라우드 업체를 교체할 수도 있고, 워크로드를 온프레미스에서 클라우드로 이동시킬 수도 있다. 결과적으로 기본 IaaS에 종속되지 않는 쿠버네티스 제어 영역이 필요하다”라고 말했다.
 
© BT
 

오토 미션 대신 수동을 사용할 이유가 있을까

그렇다고 해서 BT의 일부 개발자가 여전히 쿠버네티스를 거부한다는 의미는 아니다. 프렘찬드란은 “마치 오토 자동차를 운전하는 것과 같다. 하지만 여전히 기어를 바꾸는 느낌과 클러치를 좋아하는 마니아도 있다. TKG를 이용할 수 있는 상황에서 무엇을 원하는 것인가가 아니라 구체적으로 무엇이 필요한지 물어보는 것이 더 중요하다. 쿠버네티스는 어렵다. 우리는 규모에 맞게 이를 사용하려고 하고, 개발자에게 애플리케이션 논리에 초점을 맞추고 어려운 일이 자동화되도록 해달라고 부탁한다”라고 덧붙였다.

물론 자체 관리형 쿠버네티스를 아예 고려하지 않는 것은 아니다. 단지 개발자가 그 미세한 수준의 통제를 정말로 필요로 하는 경우만으로 한정돼야 한다. 다른 모든 것들은 공급업체가 처리하도록 방치하면 안 된다는 의미다. 프렘찬드란은 “결국은 끝이 없는 힘겨루기다. 사람들이 기본적으로 쿠버네티스를 원하기 때문이다. 처음에는 개발자에게 더 규범적이어야 한다. 그러고 나서 점점 성숙할수록 독자적인 선택을 하도록 허용해야 한다"라고 말했다.
 

훈련과 개발

이러한 원칙과 프레임워크가 BT 개발자 커뮤니티 전체에 구축되면, 다음 과제는 사내 엔지니어와 외부 파트너를 위해 문서화하고 널리 알려 이를 확장하는 것이다. 일부 개발자가 쿠버네티스로 손을 담근다는 것은 새로운 전문 분야가 전사적으로 생겨나기 시작한다는 것을 의미한다. 이는 결코 나쁜 일이 아니다. 특히 소수의 존경 받는 개발자가 힘들 수도 있는 새로운 기술을 전파할 때 더 그렇다.

프렘찬드란은 “표준이 확산하는 과정을 살펴보면, 전체적인 아키텍처 표준과 정책을 살펴보는 엔터프라이즈 아키텍처가 있고, 레벨이 낮고 제품에 특화된 솔루션 설계자가 있으며, 마지막으로 우리는 뛰어난 엔지니어들을 '전문 엔지니어'라고 부르는데, 다른 개발자들의 존경을 받는 핵심 인플루언서가 있다"라고 말했다.

BT는 파트너와의 협업을 강화하기 위해 새로운 소프트웨어 엔지니어링 핸드북과 내부 위키(wiki)를 포함한 최신 문서로 새로운 방향을 제시하고 속도를 높이기 위해 이벤트와 세션을 진행했다. 이미 팬데믹 이전에 로드쇼를 시작했다. 그는 “클라우드로 나아가면서 개발자에게 스스로 학습하라고 톱다운 방식의 강요할 수는 없다. 우리가 클라우드를 중심으로 진로를 개발할 수 있는 온라인 e-러닝 플랫폼과 애자일, 데브옵스 및 관련 기술 모두를 확보해 인증 프로그램에 많은 투자를 한 이유다"라고 말했다.

최근 BT는 이렇게 만든 지식과 기술을 조직 전체로 확장하고 있다. 프렘찬드란은 “우리는 워크로드가 이동 가능한 경우 이를 다루는 요령을 터득했다. 이제는 모든 개발자가 하이브리드 클라우드 워크로드를 이해하고 다른 사람이 자신의 스택을 현대화할 수 있도록 훈련할 수 있는 기술을 갖추어야 한다”라고 말했다.
 

그다음 단계

이 모든 것이 달성되면, 프렘찬드란은 이전에 가능했던 것보다 훨씬 빠르게 필요한 서비스를 배치하는 더 행복한 개발자 커뮤니티를 관리하게 될 것이다. 그는 “데브옵스가 가능해지려면 인프라 프로비저닝 속도는 더 빨라져야 한다. 물론 속도만이 아니다. 데브옵스는 상호 연결된 문제 집합이다. 고객은 빠른 서비스를 원하므로 기업도 빠르게 내놓아야 하지만 이에 관여하는 팀은 서로 단절돼 있다. 반면 쿠버네티스와 다른 클라우드 네이티브 접근방식은 이러한 모든 팀을 단일한 방법론으로 통합할 수 있다"라고 말했다.

향후 몇 년 동안 프렘 찬드란은 더 많은 애플리케이션을 클라우드 네이티브의 마이크로 서비스 기반 아키텍처로 전환하고, ‘완전히 제로 터치 구현’을 위한 데브섹옵스(DevSecOps) 관행을 구현한다는 구상이다. 개발 그룹 전체에서 재사용 가능한 소프트웨어 구성요소의 수도 늘릴 계획이다. 예를 들어, 누군가가 비용청구 구성요소를 개발하기로 하면, 애플리케이션 내에서 고객에게 청구서를 발행해야 하는 사람이 이를 사용하는 식이다. 일단, 이상적인 세계에서는 그렇다.

프렘찬드란의 궁극적인 목표는 구식 기술이나 인프라에 얽매이지 않고 필요한 만큼 빠르게 움직일 수 있는 개발자 커뮤니티다. 그는 "애자일은 단순히 빨리 가는 것이 아니라 빨리 가는 선택을 하는 것이다. 둘은 완전히 다르다. 차가 시속 250마일을 달릴 수 있다고 해서 항상 그 속도로 간다는 뜻은 아니다. 하지만 필요하다면 그렇게 빨리 달릴 수 있는 차를 갖고 싶은 것이다”라고 말했다. editor@itworld.co.kr

X