Offcanvas

������������

블로그 | 클라우드에서 데브옵스가 무너지는 이유

데브옵스는 애플리케이션 개발 생산성을 위해서는 언제는 옳은가? 그렇다고 생각한다면, 다시 생각해 보기 바란다. 툴과 인력이 없으면, 클라우드 개발은 금방 무너지고 만다. 화요일 아침, 일일 스크럼 미팅을 위해 줌 화상회의 중이다. 진척 상황에 대한 일상적인 업데이트와 장애물에 대한 이야기를 듣는데, 프로젝트마다 늘 있는 일처럼 보인다. 하지만, 퍼블릭 클라우드 개발이 관련되어 있을 때만 이런 문제가 발생한다는 사실을 알게 된다. 전통적인 개발 환경에서는 발생하지 않는 문제다.   어떤 문제가 발생하고 어떻게 처리해야 하는지 살펴보자. 그리고 클라우드와 하이브리드 개발에서만 발생하는 이유도 알아보자. 첫째는 너무나 분명한 문제인 기술 인력이다. 클라우드에서 데브옵스 방법론을 이용하려면, 툴체인을 어떻게 구축하고 활용해야 하는지 잘 알고 있는 데브옵스 엔지니어가 필요하다. 게다가 클라우드 기반 툴을 사용해 툴 체인을 구축할 줄 아는 엔지니어가 필요하다. 일부 인력은 이런 기술력을 가지고 있다. 필자는 이런 인력을 찾지 못해 데브옵스를 전통적인 플랫폼으로 되돌리는 기업을 많이 봤다. 단지 필요한 인력을 구하지 못했기 때문이다. 안타깝게도 현재로서는 그렇게 나쁜 전략은 아니다. 둘째, 클라우드가 기업의 데브옵스 툴체인에 필요한 툴을 모두 갖춘 경우는 드물다. 엄청나게 많은 데브옵스 툴이 있고, 퍼블릭 클라우스 서비스 업체나 데브옵스 클라우드 서비스를 판매하는 핵심 협력업체가 엄청나게 많은 데브옵스 툴을 제공하지만, 필요한 툴의 10~20%는 해당 클라우드 플랫폼에는 없을 것이다. 다른 서비스 업체의 플랫폼을 통합해야 하는데, 여기에는 멀티클라우드의 복잡성이 따른다. 물론, 이런 툴의 부재는 어떤 애플리케이션을 구축하느냐에 따라 다르다. 툴 부족은 옛날처럼 심각한 문제는 아니다. 데브옵스 툴 업체가 보기에도 클라우드 컴퓨팅은 분명한 대세라 신속하게 부족한 툴을 채웠기 때문이다. 하지만 선호하는 클라우드 플랫폼 상에서 이른바 “네이티브하게” 동작하는...

데브옵스 엔지니어 복잡성 툴체인 클라우드네이티브

1일 전

데브옵스는 애플리케이션 개발 생산성을 위해서는 언제는 옳은가? 그렇다고 생각한다면, 다시 생각해 보기 바란다. 툴과 인력이 없으면, 클라우드 개발은 금방 무너지고 만다. 화요일 아침, 일일 스크럼 미팅을 위해 줌 화상회의 중이다. 진척 상황에 대한 일상적인 업데이트와 장애물에 대한 이야기를 듣는데, 프로젝트마다 늘 있는 일처럼 보인다. 하지만, 퍼블릭 클라우드 개발이 관련되어 있을 때만 이런 문제가 발생한다는 사실을 알게 된다. 전통적인 개발 환경에서는 발생하지 않는 문제다.   어떤 문제가 발생하고 어떻게 처리해야 하는지 살펴보자. 그리고 클라우드와 하이브리드 개발에서만 발생하는 이유도 알아보자. 첫째는 너무나 분명한 문제인 기술 인력이다. 클라우드에서 데브옵스 방법론을 이용하려면, 툴체인을 어떻게 구축하고 활용해야 하는지 잘 알고 있는 데브옵스 엔지니어가 필요하다. 게다가 클라우드 기반 툴을 사용해 툴 체인을 구축할 줄 아는 엔지니어가 필요하다. 일부 인력은 이런 기술력을 가지고 있다. 필자는 이런 인력을 찾지 못해 데브옵스를 전통적인 플랫폼으로 되돌리는 기업을 많이 봤다. 단지 필요한 인력을 구하지 못했기 때문이다. 안타깝게도 현재로서는 그렇게 나쁜 전략은 아니다. 둘째, 클라우드가 기업의 데브옵스 툴체인에 필요한 툴을 모두 갖춘 경우는 드물다. 엄청나게 많은 데브옵스 툴이 있고, 퍼블릭 클라우스 서비스 업체나 데브옵스 클라우드 서비스를 판매하는 핵심 협력업체가 엄청나게 많은 데브옵스 툴을 제공하지만, 필요한 툴의 10~20%는 해당 클라우드 플랫폼에는 없을 것이다. 다른 서비스 업체의 플랫폼을 통합해야 하는데, 여기에는 멀티클라우드의 복잡성이 따른다. 물론, 이런 툴의 부재는 어떤 애플리케이션을 구축하느냐에 따라 다르다. 툴 부족은 옛날처럼 심각한 문제는 아니다. 데브옵스 툴 업체가 보기에도 클라우드 컴퓨팅은 분명한 대세라 신속하게 부족한 툴을 채웠기 때문이다. 하지만 선호하는 클라우드 플랫폼 상에서 이른바 “네이티브하게” 동작하는...

1일 전

데이터 거버넌스 개선·확산, 데브옵스 팀의 ‘개입’이 필요하다

CIO들은 데이터 거버넌스가 IT 팀 전원의 일이 돼야 한다는 데 모두 동의한다. 데이터의 규정 준수, 보안, 그리고 신뢰성은 비즈니스의 모든 영역에 영향을 끼치기 때문이다.    데이터 거버넌스(data governance)는 다양한 분야와 관행을 아우르는 포괄적 용어다. 우선순위는 누가 해당 활동을 주도하는지에 달린 경우가 많다. 최고데이터책임자(CDO), 프라이버시 책임자, 보안 책임자, 위험 관리 리더가 주도한다면 프라이버시, 보안, 규정에 주력하는 것이 보통이다. 데이터 과학자, 마케터, 데브옵스 리더, 비즈니스 애널리스트는 데이터 카탈로그, 데이터 통합, 데이터 품질, 데이터 계보, 고객 데이터 프로필, 그리고 마스터 데이터 관리를 포함한 대비적 데이터 거버넌스에 주력할 가능성이 더 크다. 즉, 이 모든 용어와 관행, 그리고 기술에는 해석의 여지가 다양하며 일부 기능과 목적은 서로 겹치기도 한다. 질리언트(Zilliant) CTO 겸 엔지니어링 담당 SVP 샴즈 차우타니는 목표가 여럿일 수 있기 때문에 때문에 비즈니스 이해관계자, IT, 데이터 팀 사이의 협업이 프로젝트 성공의 관건이라고 강조했다. 그는 “데이터 거버넌스는 각 부서가 알아서 해야 하는 일, 대부분 IT에서 관리하는 규정 준수 요건쯤으로 취급된다. 오늘날 디지털 시대에 데이터는 최대 자산이다. 데이터 거버넌스를 IT에서만 실행하는 고립된 업무로 취급하면 전체 조직에 해가 된다. 데이터 중심 기업이 되고자 하는 목표를 정말 현실화하고자 한다면 이해관계자 전원이 참여해 데이터 거버넌스 프로세스를 지속해서 개선해야 한다”라고 말했다. 데이터 거버넌스를 확산시키기 위해 데브옵스 리더와 팀이 알아야 할 것과 기여할 수 있는 방식에 대한 업계 전문가들의 의견을 들어본다.    데이터옵스로 일상 워크플로우에 통합  레드게이트 소프트웨어(Redgate Software)의 데브옵스 애드보케이크(DevOps Advocate) 그랜트 프리치는 이해...

데브옵스 데이터거버넌스 데브섹옵스 데이터옵스

2022.09.07

CIO들은 데이터 거버넌스가 IT 팀 전원의 일이 돼야 한다는 데 모두 동의한다. 데이터의 규정 준수, 보안, 그리고 신뢰성은 비즈니스의 모든 영역에 영향을 끼치기 때문이다.    데이터 거버넌스(data governance)는 다양한 분야와 관행을 아우르는 포괄적 용어다. 우선순위는 누가 해당 활동을 주도하는지에 달린 경우가 많다. 최고데이터책임자(CDO), 프라이버시 책임자, 보안 책임자, 위험 관리 리더가 주도한다면 프라이버시, 보안, 규정에 주력하는 것이 보통이다. 데이터 과학자, 마케터, 데브옵스 리더, 비즈니스 애널리스트는 데이터 카탈로그, 데이터 통합, 데이터 품질, 데이터 계보, 고객 데이터 프로필, 그리고 마스터 데이터 관리를 포함한 대비적 데이터 거버넌스에 주력할 가능성이 더 크다. 즉, 이 모든 용어와 관행, 그리고 기술에는 해석의 여지가 다양하며 일부 기능과 목적은 서로 겹치기도 한다. 질리언트(Zilliant) CTO 겸 엔지니어링 담당 SVP 샴즈 차우타니는 목표가 여럿일 수 있기 때문에 때문에 비즈니스 이해관계자, IT, 데이터 팀 사이의 협업이 프로젝트 성공의 관건이라고 강조했다. 그는 “데이터 거버넌스는 각 부서가 알아서 해야 하는 일, 대부분 IT에서 관리하는 규정 준수 요건쯤으로 취급된다. 오늘날 디지털 시대에 데이터는 최대 자산이다. 데이터 거버넌스를 IT에서만 실행하는 고립된 업무로 취급하면 전체 조직에 해가 된다. 데이터 중심 기업이 되고자 하는 목표를 정말 현실화하고자 한다면 이해관계자 전원이 참여해 데이터 거버넌스 프로세스를 지속해서 개선해야 한다”라고 말했다. 데이터 거버넌스를 확산시키기 위해 데브옵스 리더와 팀이 알아야 할 것과 기여할 수 있는 방식에 대한 업계 전문가들의 의견을 들어본다.    데이터옵스로 일상 워크플로우에 통합  레드게이트 소프트웨어(Redgate Software)의 데브옵스 애드보케이크(DevOps Advocate) 그랜트 프리치는 이해...

2022.09.07

칼럼 | 데브옵스 시대는 끝났다

소프트웨어 개발 작업이 점점 더 복잡해짐에 따라 개발(dev) 전문가와 운영(ops) 전문가를 다시 한번 분리해야 할 때가 다가오고 있다. 이번에는 과거의 실수를 반복하지 않고 해낼 수 있을까?   2000년대 후반 소프트웨어가 세상을 집어삼키기 시작하면서 애자일 방법론과 클라우드 컴퓨팅의 부상과 함께 데브옵스(Devops)가 등장했다. ‘개발’과 ‘운영’을 근사하게 결합한 데브옵스는 과거에는 분리돼 있던 소프트웨어 구축, 배포 담당인 두 그룹을 하나로 모으는 것이 핵심이다. 이에 따라 소프트웨어 엔지니어가 사용자 피드백에 대한 대응을 개선해 제품을 더 자주 업데이트해야 할 필요성이 부상했다. 많은 기업이 데브옵스를 통해 이전에는 불가능했던 속도로 문제를 해결해 나갔고, 일부 기업은 개발자에 운영 작업에 대한 책임까지 담당하는 방법으로 데브옵스를 활용했다. 풀 스택 개발자로 구성된 일종의 슈퍼 팀을 만들려고 했던 셈이다. 그러나 데브옵스 포 더미즈(Devops for Dummies)의 저자이자 아마존 웹 서비스의 커뮤니티 참여 책임자인 에밀리 프리먼은 트위터를 통해 “개발자는 대부분 운영 문제를 다루고 싶어 하지 않는다”라고 문제를 제기했다. 이 트윗을 본 많은 개발자가 수백 개 자기 생각을 답장으로 보냈다. 예를 들어 패스트푸드 회사 치포틀레(Chipotle)의 소프트웨어 엔지니어인 스콧 팬탈은 “맞다. 나 역시 개발자이고 운영 문제를 다루고 싶지 않다”라고 썼다. SUSE의 개발자 에반젤리스트인 앤드루 그레이시는 “개발자와 운영진은 서로 다른 역할을 맡아 긴밀하게 협력해야 한다. 팀 간의 공감이 가장 중요하다”라고 말했다. 더 많은 운영, 보안 문제를 소프트웨어 전체 수명 주기의 ‘왼쪽’으로 이동시켜 소프트웨어 개발자의 영역으로 옮기는 데브옵스 개념은 분명히 많은 장점이 있지만 위험한 병목 현상으로 이어질 가능성도 있다. 쿠버네티스(Kubernetes) 스토리지 전문업체 온닷(Ondat)의 제품 책임자인 제임스 브라운은 “개발자를 너무 많...

데브옵스 DevOps

2022.08.26

소프트웨어 개발 작업이 점점 더 복잡해짐에 따라 개발(dev) 전문가와 운영(ops) 전문가를 다시 한번 분리해야 할 때가 다가오고 있다. 이번에는 과거의 실수를 반복하지 않고 해낼 수 있을까?   2000년대 후반 소프트웨어가 세상을 집어삼키기 시작하면서 애자일 방법론과 클라우드 컴퓨팅의 부상과 함께 데브옵스(Devops)가 등장했다. ‘개발’과 ‘운영’을 근사하게 결합한 데브옵스는 과거에는 분리돼 있던 소프트웨어 구축, 배포 담당인 두 그룹을 하나로 모으는 것이 핵심이다. 이에 따라 소프트웨어 엔지니어가 사용자 피드백에 대한 대응을 개선해 제품을 더 자주 업데이트해야 할 필요성이 부상했다. 많은 기업이 데브옵스를 통해 이전에는 불가능했던 속도로 문제를 해결해 나갔고, 일부 기업은 개발자에 운영 작업에 대한 책임까지 담당하는 방법으로 데브옵스를 활용했다. 풀 스택 개발자로 구성된 일종의 슈퍼 팀을 만들려고 했던 셈이다. 그러나 데브옵스 포 더미즈(Devops for Dummies)의 저자이자 아마존 웹 서비스의 커뮤니티 참여 책임자인 에밀리 프리먼은 트위터를 통해 “개발자는 대부분 운영 문제를 다루고 싶어 하지 않는다”라고 문제를 제기했다. 이 트윗을 본 많은 개발자가 수백 개 자기 생각을 답장으로 보냈다. 예를 들어 패스트푸드 회사 치포틀레(Chipotle)의 소프트웨어 엔지니어인 스콧 팬탈은 “맞다. 나 역시 개발자이고 운영 문제를 다루고 싶지 않다”라고 썼다. SUSE의 개발자 에반젤리스트인 앤드루 그레이시는 “개발자와 운영진은 서로 다른 역할을 맡아 긴밀하게 협력해야 한다. 팀 간의 공감이 가장 중요하다”라고 말했다. 더 많은 운영, 보안 문제를 소프트웨어 전체 수명 주기의 ‘왼쪽’으로 이동시켜 소프트웨어 개발자의 영역으로 옮기는 데브옵스 개념은 분명히 많은 장점이 있지만 위험한 병목 현상으로 이어질 가능성도 있다. 쿠버네티스(Kubernetes) 스토리지 전문업체 온닷(Ondat)의 제품 책임자인 제임스 브라운은 “개발자를 너무 많...

2022.08.26

'머신러닝+자율기능'··· 데브옵스 시대 네트워킹의 조건

디지털 트랜스포메이션을 통해 기업은 경쟁 우위 확대, 새로운 수익사업 개발, 고객 경험 개선 등을 실현하고 있다. 그러나 이 모든 것을 위해 데브옵스 엔지니어는 할 일이 많다. 업무의 중요도와 요건에 따라 이를 지원하는 클라우드 서비스 업체의 리소스를 활용하고 쿠버네티스, 마이크로서비스, 기타 클라우드 네이티브 컴퓨팅 툴을 사용해 이른바 '애자일', 즉 더 빠른 속도로 애플리케이션을 구축, 테스트, 배포해야 하는 상황이다.   엔지니어와 애플리케이션 스택이 애자일을 지향하는 만큼 네트워크도 애자일에 적합해야 하는데, 바로 멀티클라우드 환경을 위한 풀스택 자율 네트워킹이다. 이를 통해 기업은 단기간에 투자 가치를 회수할 수 있고 데브옵스 엔지니어는 생산성과 사업 성장을 극대화할 수 있는 수단을 확보할 수 있다.   레거시 네트워킹 툴의 한계 애플리케이션과 서비스의 제공 속도를 높이면 비즈니스 측면에서 많은 장점이 있지만 동시에 감수해야 할 위험과 해결해야 할 과제도 함께 늘어난다. 사용자가 성능 문제를 겪고 결과적으로 생산성이 저하된다면 혁신적인 애플리케이션도 아무 소용이 없다. 따라서 보유한 애플리케이션이 안전한 경험을 제공하는지, 기업과 직원, 고객을 위험에 드러내는지, 모든 규정 준수 요건을 충족하는지 확인해야 한다. IDC에 따르면 클라우드로 이동하는 애플리케이션이 많아지면서 올해 말이면 사상 처음으로 클라우드 투자가 비 클라우드 IT 인프라 투자를 앞지를 전망이다. 또한, 프로시모(Prosimo)의 최신 ‘멀티클라우드 인프라 상태 보고서’에 따르면 기업 91%가 복수의 클라우드를 사용할 계획이며 62%는 2년 이내에 사용할 계획이다. 클라우드 사용 규모가 커질수록 복잡성도 커지기 마련이다. 기업은 이 새로운 역동적 IT 환경을 온프레미스 데이터센터, 엣지 컴퓨팅, 클라우드 인프라에 걸쳐 일관성 있게 오케스트레이션 및 관리하는 데 애를 먹고 있다. 많은 기업이 전통적인 레거시 네트워킹 툴을 사용해 연결성 요건과 씨름해 왔지만, 효...

데브옵스 네트워킹 머신러닝

2022.08.16

디지털 트랜스포메이션을 통해 기업은 경쟁 우위 확대, 새로운 수익사업 개발, 고객 경험 개선 등을 실현하고 있다. 그러나 이 모든 것을 위해 데브옵스 엔지니어는 할 일이 많다. 업무의 중요도와 요건에 따라 이를 지원하는 클라우드 서비스 업체의 리소스를 활용하고 쿠버네티스, 마이크로서비스, 기타 클라우드 네이티브 컴퓨팅 툴을 사용해 이른바 '애자일', 즉 더 빠른 속도로 애플리케이션을 구축, 테스트, 배포해야 하는 상황이다.   엔지니어와 애플리케이션 스택이 애자일을 지향하는 만큼 네트워크도 애자일에 적합해야 하는데, 바로 멀티클라우드 환경을 위한 풀스택 자율 네트워킹이다. 이를 통해 기업은 단기간에 투자 가치를 회수할 수 있고 데브옵스 엔지니어는 생산성과 사업 성장을 극대화할 수 있는 수단을 확보할 수 있다.   레거시 네트워킹 툴의 한계 애플리케이션과 서비스의 제공 속도를 높이면 비즈니스 측면에서 많은 장점이 있지만 동시에 감수해야 할 위험과 해결해야 할 과제도 함께 늘어난다. 사용자가 성능 문제를 겪고 결과적으로 생산성이 저하된다면 혁신적인 애플리케이션도 아무 소용이 없다. 따라서 보유한 애플리케이션이 안전한 경험을 제공하는지, 기업과 직원, 고객을 위험에 드러내는지, 모든 규정 준수 요건을 충족하는지 확인해야 한다. IDC에 따르면 클라우드로 이동하는 애플리케이션이 많아지면서 올해 말이면 사상 처음으로 클라우드 투자가 비 클라우드 IT 인프라 투자를 앞지를 전망이다. 또한, 프로시모(Prosimo)의 최신 ‘멀티클라우드 인프라 상태 보고서’에 따르면 기업 91%가 복수의 클라우드를 사용할 계획이며 62%는 2년 이내에 사용할 계획이다. 클라우드 사용 규모가 커질수록 복잡성도 커지기 마련이다. 기업은 이 새로운 역동적 IT 환경을 온프레미스 데이터센터, 엣지 컴퓨팅, 클라우드 인프라에 걸쳐 일관성 있게 오케스트레이션 및 관리하는 데 애를 먹고 있다. 많은 기업이 전통적인 레거시 네트워킹 툴을 사용해 연결성 요건과 씨름해 왔지만, 효...

2022.08.16

'분명히 뜬다, 몇 개월 내에'··· 넷데브옵스 안내서

네트워크를 신속하게 업데이트할 수 있는 자동화, 프로그래밍 기반의 파이프라인을 구축하면, 네트워크의 속도, 민첩성, 신뢰성 및 성능이 크게 개선된다. 이것이 바로 넷데브옵스(NetDevOps)다.   대부분 IT 책임자는 데브옵스(DevOps), 데브섹옵스(DevSecOps) 개념에 익숙할 것이다. 이제 넷데브옵스(NetDevOps)라는 모델이 등장해 특히 네트워킹 전문가 세계에 상당한 반향을 일으키고 있다. 새로 떠오르는 기술이 종종 그렇듯, 오늘날 넷데브옵스의 정의는 느슨하다. 그러나 기본적인 수준에서 이 용어는 데브옵스 원칙을 컴퓨터 네트워킹에 적용하는 것을 나타낸다. 가트너의 네트워킹 부문 리서치 부사장인 앤드류 러너는 “넷데브옵스가 현재 뜨거운 화두”라며, “그러나 여러 정의와 관점이 있는 만큼 가장 먼저 해야 할 질문은 넷데브옵스가 무엇이냐는 것”이라고 말했다. 넷데브옵스의 정의와 개념 가트너의 정의에 따르면, 넷데브옵스는 데브옵스의 지속적 통합/지속적 제공(CI/CD) 개념을 네트워킹 작업에 적용하는 것을 의미한다. 러너는 이 모델을 나타내는 다른 용어로 넷옵스(NetOps) 2.0, 코드형 네트워크(Network as Code), 깃옵스(GitOps) 네트워킹 등이 있다고 설명했다.   시장조사 업체 기가옴(GigaOm)은 “넷데브옵스의 목표는 그동안 엔지니어의 골칫거리였던 네트워크 구성 오류를 줄이고, 근본적으로 더 나은 성능과 복원력을 지닌 네트워크를 구축하는 것이다. 따라서 이 개념은 자동화된 프로그래밍 워크플로우를 기반으로 코드형 네트워크 인프라(IaC)를 추상화, 코드화 및 구현하는 모든 일련의 과정을 뜻한다”라고 설명했다. 러너는 기업이 조직이 넷데브옵스를 활용하려면 스테이징, 사전/사후 검증, 프로비저닝과 같은 네트워킹 작업 테스트가 포함된 자동화된 파이프라인을 먼저 구축해야 한다고 설명했다.  기가옴도 비슷한 파이프라인이 필요하다고 덧붙였다. 넷데브옵스 파이프라인은 다양한 개발 환경...

데브옵스 데브섹옵스 넷데브옵스 네트워크구성오류 네트워크엔지니어 네트워크프로그래밍 네트워크프로그래머

2022.07.12

네트워크를 신속하게 업데이트할 수 있는 자동화, 프로그래밍 기반의 파이프라인을 구축하면, 네트워크의 속도, 민첩성, 신뢰성 및 성능이 크게 개선된다. 이것이 바로 넷데브옵스(NetDevOps)다.   대부분 IT 책임자는 데브옵스(DevOps), 데브섹옵스(DevSecOps) 개념에 익숙할 것이다. 이제 넷데브옵스(NetDevOps)라는 모델이 등장해 특히 네트워킹 전문가 세계에 상당한 반향을 일으키고 있다. 새로 떠오르는 기술이 종종 그렇듯, 오늘날 넷데브옵스의 정의는 느슨하다. 그러나 기본적인 수준에서 이 용어는 데브옵스 원칙을 컴퓨터 네트워킹에 적용하는 것을 나타낸다. 가트너의 네트워킹 부문 리서치 부사장인 앤드류 러너는 “넷데브옵스가 현재 뜨거운 화두”라며, “그러나 여러 정의와 관점이 있는 만큼 가장 먼저 해야 할 질문은 넷데브옵스가 무엇이냐는 것”이라고 말했다. 넷데브옵스의 정의와 개념 가트너의 정의에 따르면, 넷데브옵스는 데브옵스의 지속적 통합/지속적 제공(CI/CD) 개념을 네트워킹 작업에 적용하는 것을 의미한다. 러너는 이 모델을 나타내는 다른 용어로 넷옵스(NetOps) 2.0, 코드형 네트워크(Network as Code), 깃옵스(GitOps) 네트워킹 등이 있다고 설명했다.   시장조사 업체 기가옴(GigaOm)은 “넷데브옵스의 목표는 그동안 엔지니어의 골칫거리였던 네트워크 구성 오류를 줄이고, 근본적으로 더 나은 성능과 복원력을 지닌 네트워크를 구축하는 것이다. 따라서 이 개념은 자동화된 프로그래밍 워크플로우를 기반으로 코드형 네트워크 인프라(IaC)를 추상화, 코드화 및 구현하는 모든 일련의 과정을 뜻한다”라고 설명했다. 러너는 기업이 조직이 넷데브옵스를 활용하려면 스테이징, 사전/사후 검증, 프로비저닝과 같은 네트워킹 작업 테스트가 포함된 자동화된 파이프라인을 먼저 구축해야 한다고 설명했다.  기가옴도 비슷한 파이프라인이 필요하다고 덧붙였다. 넷데브옵스 파이프라인은 다양한 개발 환경...

2022.07.12

벤츠가 쿠버네티스 클러스터 900개를 운영하는 이유

독일 자동차 회사 메르세데스 벤츠(Mercedes-Benz)의 기술팀은 지난 7년 동안 수백 개의 개별 개발팀을지원하기 위해 자체 개발한 쿠버네티스 클러스터 900개를 구축했다. 이로써 메르세데스 벤츠는 확장 가능하고 관리가 용이하다는 최신 인프라 플랫폼을 갖추게 됐다.   메르세데스 벤츠는 2014년 구글이 컨테이너 오케스트레이션 시스템인 쿠버네티스를 오픈소스화한 후 2015년부터 애플리케이션 배포 목적으로 쿠버네티스를 활용하기 시작했다. 이후 메르세데스 벤츠의 IT 전문 자회사인 메르세데스 벤츠 테크 이노베이션(Mercedes-Benz Tech Innovation)은 내부 전문 역량을 개발해 사업부와 연동되어 각자 고유한 기술 수요가 있는 수백 개의 애플리케이션팀을 지원하고 있다. 메르세데스 벤츠 테크 이노베이션 데브옵스 엔지니어 젠스 에랏은 최근 개최된 쿠버콘(KubeCon) 유럽 행사에서 “단일 공유 쿠버네티스 클러스터는 우리의 수요에 맞지 않고 우리의 요구사항에 맞는 업체 배포판도 없다는 사실을 알고 있었다. 대신 우리는 전문 기술을 갖춘 엔지니어가 있었다”라며, “동일한 데브옵스팀이 구축하고 개발한 100% 오픈소스 소프트웨어 플랫폼을 구축했고, 라이선스 문제도 기술 지원도 없었다”라고 밝혔다. 현재 메르세데스 벤츠는 네 곳의 글로벌 데이터센터에서 900개의 온프레미스 쿠버네티스를 운영 중이다. 2021년 말부터 버전 1.23을 실행 중인 오픈스택(OpenStack)을 사용한다.  이런 쿠버네티스 자산은 클라우드 서비스 업체와 비교하면 아주 큰 규모는 아니다. 하지만 클라우드 네이티브 컴퓨팅 재단(CNCF)의 2019년 조사에 따르면, 50개 이상의 클러스터를 사용하는 조직의 비율은 10%에 불과하다. 또한, 메르세데스 벤츠의 쿠버네티스 자산 규모는 쿠번콘 유럽에서 함께 기조 연설을 했고 이 기사 작성 시점 현재 210개의 클러스터를 운영 중인 CERN의 쿠버네티스 환경보다 거의 다섯 더 크다. 메르세데스 벤츠를 쿠버네티...

쿠버네티스 오케스트레이션 벤츠 클러스터 데브옵스 클러스터API

2022.06.24

독일 자동차 회사 메르세데스 벤츠(Mercedes-Benz)의 기술팀은 지난 7년 동안 수백 개의 개별 개발팀을지원하기 위해 자체 개발한 쿠버네티스 클러스터 900개를 구축했다. 이로써 메르세데스 벤츠는 확장 가능하고 관리가 용이하다는 최신 인프라 플랫폼을 갖추게 됐다.   메르세데스 벤츠는 2014년 구글이 컨테이너 오케스트레이션 시스템인 쿠버네티스를 오픈소스화한 후 2015년부터 애플리케이션 배포 목적으로 쿠버네티스를 활용하기 시작했다. 이후 메르세데스 벤츠의 IT 전문 자회사인 메르세데스 벤츠 테크 이노베이션(Mercedes-Benz Tech Innovation)은 내부 전문 역량을 개발해 사업부와 연동되어 각자 고유한 기술 수요가 있는 수백 개의 애플리케이션팀을 지원하고 있다. 메르세데스 벤츠 테크 이노베이션 데브옵스 엔지니어 젠스 에랏은 최근 개최된 쿠버콘(KubeCon) 유럽 행사에서 “단일 공유 쿠버네티스 클러스터는 우리의 수요에 맞지 않고 우리의 요구사항에 맞는 업체 배포판도 없다는 사실을 알고 있었다. 대신 우리는 전문 기술을 갖춘 엔지니어가 있었다”라며, “동일한 데브옵스팀이 구축하고 개발한 100% 오픈소스 소프트웨어 플랫폼을 구축했고, 라이선스 문제도 기술 지원도 없었다”라고 밝혔다. 현재 메르세데스 벤츠는 네 곳의 글로벌 데이터센터에서 900개의 온프레미스 쿠버네티스를 운영 중이다. 2021년 말부터 버전 1.23을 실행 중인 오픈스택(OpenStack)을 사용한다.  이런 쿠버네티스 자산은 클라우드 서비스 업체와 비교하면 아주 큰 규모는 아니다. 하지만 클라우드 네이티브 컴퓨팅 재단(CNCF)의 2019년 조사에 따르면, 50개 이상의 클러스터를 사용하는 조직의 비율은 10%에 불과하다. 또한, 메르세데스 벤츠의 쿠버네티스 자산 규모는 쿠번콘 유럽에서 함께 기조 연설을 했고 이 기사 작성 시점 현재 210개의 클러스터를 운영 중인 CERN의 쿠버네티스 환경보다 거의 다섯 더 크다. 메르세데스 벤츠를 쿠버네티...

2022.06.24

‘닮은 듯 다른’ 월가 공룡들의 데브옵스 접근법

두 금융 서비스 회사는 중앙집중식 운영 및 SRE 하에서 개발자 팀의 공유 책임 모델을 구축하는 등 데브옵스 전환에 유사한 접근 방식을 취하고 있다.  ‘뱅가드(Vanguard)’와 ‘모건 스탠리(Morgan Stanley)’는 대규모 클라우드 전환을 진행하면서 소프트웨어 개발과 운영의 균형을 신중하게 맞추고 있다. 지난 2015년 뱅가드는 자체적으로 관리하던 서버 2,000대를 대부분 AWS로 이동시키는 전환을 시작했다. 그 결과 7,000명의 개발자가 분기마다 단일 애플리케이션을 업데이트하던 것에서 개별 팀이 구축하고 실행하는 일련의 마이크로서비스로 이동했다. 이러한 팀은 이제 표준화된 CI/CD 파이프라인 그리고 코드를 적용할 수 있는 인프라를 제공하는 중앙 플랫폼 팀의 지원을 받으며, SRE는 이러한 팀 전체에 중앙집중식 및 임베디드식 감독 기능을 제공한다.    모건 스탠리는 2018년 애자일 및 클라우드 전환을 시작했으며, (이를 위해) 마이크로소프트 애저와 협력했다. 이 이니셔티브는 1만 5,000명에 달하는 해당 은행의 기술 전문가를 대상으로 최신 데브옵스 및 SRE 관행을 확립하기 위한 3개년 교육 프로젝트로 출발했다. 이는 모건 스탠리의 애플리케이션 인프라 부문 전무이사 거스 폴이 식별한 3가지 핵심 영역을 기반으로 한다. 그는 데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)에서 “3가지 핵심 영역은 소프트웨어 개발 및 제공 가속화, 변화의 예측 가능성/빈도/품질 증가, 기술 운영 혁신”이라고 말했다. 모건 스탠리의 데브옵스 및 엔터프라이즈 기술 아키텍처 책임자 트레버 브로스넌은 “현재 자사는 제품 소유자, 개발 및 운영 전문 지식을 갖춘 엔지니어로 구성된 애자일 팀을 보유하고 있으며, 이러한 팀은 온프레미스 또는 클라우드 인프라를 타깃으로 하고 있다. 개인적인 철학은 모두에게 전문 분야가 있는 것이다. 모두는 기술에 능통할 수 있다”라고 밝혔다. 뱅가드와 모건 스탠리처럼 크고 ...

데브옵스 SRE 클라우드 AWS 마이크로소프트 애저 마이크로서비스 IT 관리

2022.06.03

두 금융 서비스 회사는 중앙집중식 운영 및 SRE 하에서 개발자 팀의 공유 책임 모델을 구축하는 등 데브옵스 전환에 유사한 접근 방식을 취하고 있다.  ‘뱅가드(Vanguard)’와 ‘모건 스탠리(Morgan Stanley)’는 대규모 클라우드 전환을 진행하면서 소프트웨어 개발과 운영의 균형을 신중하게 맞추고 있다. 지난 2015년 뱅가드는 자체적으로 관리하던 서버 2,000대를 대부분 AWS로 이동시키는 전환을 시작했다. 그 결과 7,000명의 개발자가 분기마다 단일 애플리케이션을 업데이트하던 것에서 개별 팀이 구축하고 실행하는 일련의 마이크로서비스로 이동했다. 이러한 팀은 이제 표준화된 CI/CD 파이프라인 그리고 코드를 적용할 수 있는 인프라를 제공하는 중앙 플랫폼 팀의 지원을 받으며, SRE는 이러한 팀 전체에 중앙집중식 및 임베디드식 감독 기능을 제공한다.    모건 스탠리는 2018년 애자일 및 클라우드 전환을 시작했으며, (이를 위해) 마이크로소프트 애저와 협력했다. 이 이니셔티브는 1만 5,000명에 달하는 해당 은행의 기술 전문가를 대상으로 최신 데브옵스 및 SRE 관행을 확립하기 위한 3개년 교육 프로젝트로 출발했다. 이는 모건 스탠리의 애플리케이션 인프라 부문 전무이사 거스 폴이 식별한 3가지 핵심 영역을 기반으로 한다. 그는 데브옵스 엔터프라이즈 서밋(Devops Enterprise Summit)에서 “3가지 핵심 영역은 소프트웨어 개발 및 제공 가속화, 변화의 예측 가능성/빈도/품질 증가, 기술 운영 혁신”이라고 말했다. 모건 스탠리의 데브옵스 및 엔터프라이즈 기술 아키텍처 책임자 트레버 브로스넌은 “현재 자사는 제품 소유자, 개발 및 운영 전문 지식을 갖춘 엔지니어로 구성된 애자일 팀을 보유하고 있으며, 이러한 팀은 온프레미스 또는 클라우드 인프라를 타깃으로 하고 있다. 개인적인 철학은 모두에게 전문 분야가 있는 것이다. 모두는 기술에 능통할 수 있다”라고 밝혔다. 뱅가드와 모건 스탠리처럼 크고 ...

2022.06.03

기고 | 데브옵스로 ‘지속적 아키텍처’를 구현하는 3가지 방법

지속적 아키텍처(Continuous Architecture)는 시시각각 변화하는 기업 환경과 사용자 요구사항에 적응할 수 있는 유연성을 제공한다.    애플리케이션 및 시스템을 개발하기 위해 소프트웨어 아키텍처 및 시스템 계발 계획을 장황하게 세워야 했던 때가 있다. 심지어 몇몇 기업에서는 전제 조건이었다. 시스템 설계자는 상위 레벨(high level)의 요구 사항을 검토하고, 회사의 표준을 고려하면서 소프트웨어 개발 프로세스에 사용할 플랫폼, 디자인 패턴 및 구성요소의 아키텍처를 모두 아우르는 다이어그램을 구상하곤 했다.  새로운 기술이나 소프트웨어 구성요소가 필요한 경우를 대비해 좀 더 빈조한 플래닝을 채택한 기업도 있었다. 아키텍처 리뷰 보드(Architecture review board)라는 것을 만들어 의사결정을 더 투명하게 하고, 아키텍처의 리스크를 감지하고, 예산을 맞추며 지속 가능한 개발 방법에 영향을 미칠 수 있는 다른 모든 부분을 검토하고자 했다. 그러나 아키텍처 리뷰 보드의 효과성에도 의문이 제기되곤 한다. 개발 팀의 자율성을 저해하고, 개발 흐름을 방해하며 과도한 문서화를 초래할 수 있다는 지적이 있다.  다른 한편에는 애자일(Agile) 개발 방식이 있다. 이 개발 방식은 지시된 계획을 따르기 보다 변화에 빠르게 대응할 수 있도록 자율성과 권한을 추구한다. 이는 ‘애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)의 핵심 가치이기도 하다. 하지만 기술 리더에게는 재활용 가능한 플랫폼, 명확한 개발표준과 지속 가능한 운영 모델이 필요할 수 있다. 효율성, 품질 안정성을 유지하면서도 기술 부채를 줄일 수 있어야 하기 때문이다. 이러한 간극을 지속적 아키텍처(Continuous Architecture)가 메울 수 있다. 지속적 아키텍처 선언(Continuous Architecture Manifesto)은 ‘기능이 구현되기 전 아키텍처가 거의 확정...

지속적아키텍처 데브옵스 IaC

2022.06.03

지속적 아키텍처(Continuous Architecture)는 시시각각 변화하는 기업 환경과 사용자 요구사항에 적응할 수 있는 유연성을 제공한다.    애플리케이션 및 시스템을 개발하기 위해 소프트웨어 아키텍처 및 시스템 계발 계획을 장황하게 세워야 했던 때가 있다. 심지어 몇몇 기업에서는 전제 조건이었다. 시스템 설계자는 상위 레벨(high level)의 요구 사항을 검토하고, 회사의 표준을 고려하면서 소프트웨어 개발 프로세스에 사용할 플랫폼, 디자인 패턴 및 구성요소의 아키텍처를 모두 아우르는 다이어그램을 구상하곤 했다.  새로운 기술이나 소프트웨어 구성요소가 필요한 경우를 대비해 좀 더 빈조한 플래닝을 채택한 기업도 있었다. 아키텍처 리뷰 보드(Architecture review board)라는 것을 만들어 의사결정을 더 투명하게 하고, 아키텍처의 리스크를 감지하고, 예산을 맞추며 지속 가능한 개발 방법에 영향을 미칠 수 있는 다른 모든 부분을 검토하고자 했다. 그러나 아키텍처 리뷰 보드의 효과성에도 의문이 제기되곤 한다. 개발 팀의 자율성을 저해하고, 개발 흐름을 방해하며 과도한 문서화를 초래할 수 있다는 지적이 있다.  다른 한편에는 애자일(Agile) 개발 방식이 있다. 이 개발 방식은 지시된 계획을 따르기 보다 변화에 빠르게 대응할 수 있도록 자율성과 권한을 추구한다. 이는 ‘애자일 소프트웨어 개발 선언(Manifesto for Agile Software Development)의 핵심 가치이기도 하다. 하지만 기술 리더에게는 재활용 가능한 플랫폼, 명확한 개발표준과 지속 가능한 운영 모델이 필요할 수 있다. 효율성, 품질 안정성을 유지하면서도 기술 부채를 줄일 수 있어야 하기 때문이다. 이러한 간극을 지속적 아키텍처(Continuous Architecture)가 메울 수 있다. 지속적 아키텍처 선언(Continuous Architecture Manifesto)은 ‘기능이 구현되기 전 아키텍처가 거의 확정...

2022.06.03

'호환성과 일관성 모두 잡는다' 델 테크놀로지스 통합 클라우드 플랫폼의 가치 제안

“꾸준히 사업을 진행해온 기업이라면, 앱 환경이 마치 거미줄처럼 복잡할 가능성이 큽니다. 앱 환경에 사용된 코드만 해도 몇백만 줄에 이를 겁니다.”     2020 IDC 조사에 따르면 2023년까지 5억 개의 신규 앱이 클라우드 네이티브 기술로 개발될 전망이다. 또한 2020 가트너 조사에 따르면 독립 소프트웨어 벤더 중 80%가 컨테이너 기반으로 솔루션을 제공할 예정이라고 밝혔다. 그러나 많은 기업이 여전히 꼬인 앱 환경 때문에 클라우드 이전에 어려움을 겪고 있다고 델 테크놀로지스의 박성덕 상무는 한국 IDG과 주최한 클라우드 및 엣지컴퓨팅 2022에서 진단했다. 오늘날 기업의 앱 환경과 함께 델 테크놀로지스가 제안하는 현실적인 클라우드 이전 방법에 대해 살펴본다. 혼재된 앱 환경 박성덕 상무에 따르면 현대 기업의 앱 환경에는 레거시 기술과 최신 기술이 혼재할 가능성이 크다. 한편에는 상용 소프트웨어부터 닷넷 혹은 자바 프레임워크 같은 개발 도구로 개발된 레거시 앱이 존재한다. 레거시 앱 환경은 익숙하지만 유지보수가 어렵고 확장하는 데 명확한 한계가 있다.  다른 한편에는 최근 받아들이기 시작한 마이크로 서비스, 컨테이너 등과 같은 신기술을 채택한 클라우드 네이티브 앱이 있다. 클라우드 네이티브의 강점은 명확하다. 우선 개발 방식과 개발 아키텍처가 크게 개선된다. 기존의 워터폴-IT 개발 방식은 개발 기간이 길고 문제 발생 시 변경이 힘들다. 반면 클라우드 네이티브 환경에서 쓰이는 데브옵스 및 애자일 개발 방식은 피드백이 빠르고 전 개발 과정에 IT 운영팀이 참여할 수 있어 협업이 용이하다.  박성덕 상무는 “기존 개발 방식에서 채택하는 모놀리식 아키텍처도 가상화 기술로 조금 개선되기는 했다. 그러나 여전히 피드백 과정이 느리다. 클라우드 네이티브 앱 방식에서는 마이크로 아키텍처라는 작은 구성단위로 컨테이너가 묶여서 배포된다. 따라서 필요한 개별 구성 요소만 수정할 수 있어 개선 주기가 빠르다”라고 설명했다. ...

클라우드 멀티클라우드 데브옵스 클라우드네이티브 엣지컴퓨팅

2022.05.26

“꾸준히 사업을 진행해온 기업이라면, 앱 환경이 마치 거미줄처럼 복잡할 가능성이 큽니다. 앱 환경에 사용된 코드만 해도 몇백만 줄에 이를 겁니다.”     2020 IDC 조사에 따르면 2023년까지 5억 개의 신규 앱이 클라우드 네이티브 기술로 개발될 전망이다. 또한 2020 가트너 조사에 따르면 독립 소프트웨어 벤더 중 80%가 컨테이너 기반으로 솔루션을 제공할 예정이라고 밝혔다. 그러나 많은 기업이 여전히 꼬인 앱 환경 때문에 클라우드 이전에 어려움을 겪고 있다고 델 테크놀로지스의 박성덕 상무는 한국 IDG과 주최한 클라우드 및 엣지컴퓨팅 2022에서 진단했다. 오늘날 기업의 앱 환경과 함께 델 테크놀로지스가 제안하는 현실적인 클라우드 이전 방법에 대해 살펴본다. 혼재된 앱 환경 박성덕 상무에 따르면 현대 기업의 앱 환경에는 레거시 기술과 최신 기술이 혼재할 가능성이 크다. 한편에는 상용 소프트웨어부터 닷넷 혹은 자바 프레임워크 같은 개발 도구로 개발된 레거시 앱이 존재한다. 레거시 앱 환경은 익숙하지만 유지보수가 어렵고 확장하는 데 명확한 한계가 있다.  다른 한편에는 최근 받아들이기 시작한 마이크로 서비스, 컨테이너 등과 같은 신기술을 채택한 클라우드 네이티브 앱이 있다. 클라우드 네이티브의 강점은 명확하다. 우선 개발 방식과 개발 아키텍처가 크게 개선된다. 기존의 워터폴-IT 개발 방식은 개발 기간이 길고 문제 발생 시 변경이 힘들다. 반면 클라우드 네이티브 환경에서 쓰이는 데브옵스 및 애자일 개발 방식은 피드백이 빠르고 전 개발 과정에 IT 운영팀이 참여할 수 있어 협업이 용이하다.  박성덕 상무는 “기존 개발 방식에서 채택하는 모놀리식 아키텍처도 가상화 기술로 조금 개선되기는 했다. 그러나 여전히 피드백 과정이 느리다. 클라우드 네이티브 앱 방식에서는 마이크로 아키텍처라는 작은 구성단위로 컨테이너가 묶여서 배포된다. 따라서 필요한 개별 구성 요소만 수정할 수 있어 개선 주기가 빠르다”라고 설명했다. ...

2022.05.26

정의에서 사례까지··· '클라우드옵스' 안내서

클라우드 활용을 늘려감에 따라 클라우드 전략 또한 고도화하려는 기업이 늘고 있다. 성능을 최적화하고 관리 비용을 효율화하며 혁신을 도모할 수 있게 해주는 ‘클라우드옵스’에 대한 관심이 증가하는 이유다.  소프트웨어 제품의 개발에 관여한 적 있다면 ‘데브옵스’라는 말에 익숙할 것이다. 소프트웨어 개발과 IT 운영을 결합한 일련의 관행인 데브옵스는, 개발 수명 주기를 단축하고 지속 배포 및 고품질 제품을 공급하는 것을 목표로 한다. 클라우드 운영과 연관된 개념인 ‘클라우드옵스(CloudOps)’는 기업들이 애플리케이션 개발과 워크로드를 클라우드로 점점 더 이전하면서, 그리고 클라우드 비용이 한층 복잡해지면서 출현했다. 클라우드옵스가 무엇이고, 조직에게 어떤 혜택을 줄 수 있는지, 그리고 기업 내에서 클라우드옵스를 구현할 때 유념해야 할 점은 무엇인지 살펴본다. 클라우드옵스란?  클라우드옵스는 클라우드 환경에서 실행되는 IT 서비스와 워크로드의 전달, 최적화 및 성능을 관리하는 운영 관행이다. 기업이 멀티클라우드, 하이브리드 클라우드, 또는 프라이빗 클라우드 전략을 운영함에 있어 클라우드옵스는 클라우드 기반 프로세스를 위한 절차 및 모범 관행을 확립하기 위해 구현된다. 이는 데브옵스에 의한 애플리케이션의 개발 및 배포와 비슷한 성격을 가진다. 클라우드 운영을 위한 다층 프레임워크  컨설팅 기업 캡제미니 아메리카스(Capgemini Americas)의 부사장이자 클라우드 우수성 센터의 책임자인 제이슨 해치는 “기업이 자사 클라우드 생태계의 측면들을 전반적으로 관리하는 데 도움을 주는 여러 계층으로 된 프레임워크가 클라우드옵스(Holistic CloudOp)의 큰 그림이다”라고 설명했다. 프레임워크 계층 중 하나는 거버넌스 계층(governance layer)이다. 여기에는 클라우드 비용을 제어하고 예산을 관리하는, 핀옵스(FinOps)라고도 알려진 재무 업무 등의 활동을 포함한다. 해치는 “거버넌스 계층에는 무엇이 어떻게 클라우...

클라우드옵스 데브옵스 클라우드 최적화 멀티클라우드

2022.05.26

클라우드 활용을 늘려감에 따라 클라우드 전략 또한 고도화하려는 기업이 늘고 있다. 성능을 최적화하고 관리 비용을 효율화하며 혁신을 도모할 수 있게 해주는 ‘클라우드옵스’에 대한 관심이 증가하는 이유다.  소프트웨어 제품의 개발에 관여한 적 있다면 ‘데브옵스’라는 말에 익숙할 것이다. 소프트웨어 개발과 IT 운영을 결합한 일련의 관행인 데브옵스는, 개발 수명 주기를 단축하고 지속 배포 및 고품질 제품을 공급하는 것을 목표로 한다. 클라우드 운영과 연관된 개념인 ‘클라우드옵스(CloudOps)’는 기업들이 애플리케이션 개발과 워크로드를 클라우드로 점점 더 이전하면서, 그리고 클라우드 비용이 한층 복잡해지면서 출현했다. 클라우드옵스가 무엇이고, 조직에게 어떤 혜택을 줄 수 있는지, 그리고 기업 내에서 클라우드옵스를 구현할 때 유념해야 할 점은 무엇인지 살펴본다. 클라우드옵스란?  클라우드옵스는 클라우드 환경에서 실행되는 IT 서비스와 워크로드의 전달, 최적화 및 성능을 관리하는 운영 관행이다. 기업이 멀티클라우드, 하이브리드 클라우드, 또는 프라이빗 클라우드 전략을 운영함에 있어 클라우드옵스는 클라우드 기반 프로세스를 위한 절차 및 모범 관행을 확립하기 위해 구현된다. 이는 데브옵스에 의한 애플리케이션의 개발 및 배포와 비슷한 성격을 가진다. 클라우드 운영을 위한 다층 프레임워크  컨설팅 기업 캡제미니 아메리카스(Capgemini Americas)의 부사장이자 클라우드 우수성 센터의 책임자인 제이슨 해치는 “기업이 자사 클라우드 생태계의 측면들을 전반적으로 관리하는 데 도움을 주는 여러 계층으로 된 프레임워크가 클라우드옵스(Holistic CloudOp)의 큰 그림이다”라고 설명했다. 프레임워크 계층 중 하나는 거버넌스 계층(governance layer)이다. 여기에는 클라우드 비용을 제어하고 예산을 관리하는, 핀옵스(FinOps)라고도 알려진 재무 업무 등의 활동을 포함한다. 해치는 “거버넌스 계층에는 무엇이 어떻게 클라우...

2022.05.26

백엔드 개발자 경험을 위한 솔루션 열전

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

개발자경험 백엔드 오픈소스 YAML 코드형인프라. IaC 클라우드네이티브 데브옵스

2022.05.11

코드형 인프라와 데브옵스, 내부 플랫폼의 인기가 높아지면서 백엔드 개발자가 탄력적이면서 성능과 확장성이 우수한 서버 측 애플리케이션과 서비스를 구축하기에 훨씬 더 좋은 환경이 됐다. 그러나 너무 많은 부담을 짊어지고 있기도 하다. 현대 애플리케이션의 복잡함으로 인해 백엔드 개발자는 리눅스의 기본부터 스크립트 언어, 로깅, 모니터링, 클라우드 기반 네트워킹과 서비스 메시, 관찰 가능성, 쿠버네티스 클러스터, 그리고 공포의 YAML 파일에 이르기까지 갈수록 많은 툴과 기술, 기법을 마스터해야 한다.   백엔드 개발자에게는 숨을 쉴 공간, 명확히 말하자면 더 나은 개발 경험이 필요하다. 다행히 툴 제조 업체들이 앞다퉈 그런 경험을 제공하고 있다. 코드형 인프라의 장벽을 낮추는 것부터 쿠버네티스 워크플로우와 분산 앱 배포 과정을 원활하게 하고 필요에 따라 클라우드에 개발자 작업 공간을 마련하는 데 이르기까지, 새롭게 쏟아지는 여러 프로젝트는 서버 측에서 고난을 겪고 있는 개발자가 더 편하게 작업을 수행하는 데 도움이 될 것을 약속한다.   "백엔드 엔지니어도 감정이 있다" 오늘날의 클라우드 네이티브 세계에서 모든 유형의 개발자는 일반적으로 더 직관적이고 사용하기 쾌적한 툴에 자연스럽게 이끌린다. 간편함이나 사용 편의성과 거리가 먼 영역에서 일하는 경우라 해도 마찬가지다. 버셀(Vercel)이나 네트리파이(Netlify)와 같은 업체는 프론트엔드 개발자 경험에 초점을 두고 백엔드를 추상화하는 방식으로 큰 성공을 거두었지만, 많은 기업이 서버 인프라에 대한 어느 정도의 통제력을 원한다. 이런 백엔드를 담당하는 엔지니어도 더 나은 경험을 원할 수 있다. 레드몽크(RedMonk) 애널리스트 제임스 가버너는 “개발자가 이런 작업을 더 쉽게 할 수 있도록 서비스 업체가 지원에 나서는 것은 자연스러운 현상이며, 이 부분이 인프라와 소프트웨어 개발이 만나는 지점이다. 결국 헬름 차트, 연산자 또는 YAML을 수동으로 다룰 필요 없이 생산성을 높일...

2022.05.11

'CI/CD란?' 알기 쉽게 설명한 지속적 통합과 지속적 전달

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

CI/CD 지속적통합 지속적제공 데브옵스 애자일

2022.04.21

지속적 통합(Continuous integration, CI)과 지속적 제공(Continuous delivery, CD), 줄여서 CI/CD는 애플리케이션 개발팀이 더 자주, 안정적으로 코드 변경을 제공하기 위해 사용하는 문화와 운영 원칙, 일련의 작업 방식으로 구성된다.  CI/CD는 데브옵스팀을 위한 권장 사항이자 애자일 방법론의 권장 사항이기도 하다. CI/CD는 통합과 제공을 자동화함으로써 소프트웨어 개발팀이 코드 품질과 소프트웨어 보안을 보장하는 동시에 비즈니스 요구사항을 충족하는 데 집중할 수 있게 해준다.       CI/CD의 의미  지속적 통합은 개발팀이 작은 코드 변경을 수시로 구현해 버전 제어 리포지토리에 체크인하도록 유도하는 코딩 원칙이자 일련의 방식이다. 대부분의 현대 애플리케이션에서는 다양한 플랫폼과 툴을 사용해 코드를 개발해야 하므로 팀은 변경을 통합하고 검증할 일관적인 메커니즘이 필요하다. 지속적 통합은 애플리케이션을 빌드, 패키징, 테스트하기 위한 자동화된 방법을 구축한다. 일관적인 통합 프로세스를 두면 개발자는 자연스럽게 더 자주 코드 변경을 커밋하게 되고 이것이 더 나은 협업과 코드 품질로 이어진다.  지속적 제공은 지속적 통합이 끝나는 지점부터 시작되며, 프로덕션, 개발, 테스트 환경을 포함해 선택한 환경으로 애플리케이션을 제공하는 과정을 자동화한다. 지속적 제공은 이런 환경으로 코드 변경을 적용(push)하기 위한 자동화된 방법이다.    CI/CD 파이프라인 자동화  CI/CD 툴은 각 제공 단계에서 패키징해야 하는 환경별 매개변수를 저장하는 데 도움이 된다. CI/CD 자동화는 재시작해야 하는 웹 서버, 데이터베이스 및 기타 서비스를 대상으로 필요한 서비스 호출을 수행한다. 또한 배포 후 다른 절차도 실행할 수 있다.  목표는 양질의 코드와 애플리케이션을 제공하는 데 있으므로 CI/CD에는 지속적 테스트도 필요하다. 지속...

2022.04.21

벤더 기고ㅣ비즈니스를 위한 IT의 새로운 역할, 지원 부서에서 비즈니스 혁신을 위한 핵심 조직으로

비즈니스의 핵심은 고객가치의 이해에 있다. 어떤 기업이든 비즈니스에 있어서 고객이 혁신적인 아이디어를 발굴하고 제품화하여 경쟁 제품과 차별화할 수 있는 솔루션을 제공할 수 있는 전략이 필요하다. 이러한 전략은 고객이 진정으로 원하는 바를 이해하는 것에서부터 출발한다. 또한 기업이 제공하고자 하는 제품과 서비스를 고객의 니즈와 일치시킬수 있어야 한다. 이러한 과정은 결국 기업이 제공하고자 하는 제품이나 서비스의 특징 보다는 고객이 원하는 가치를 이해 하는 데에 더 많은 노력을 기울여야 함을 의미한다.  고객이 중시하는 가치와 IT 역할의 상관관계는 꽤 오랜 시간 이야기돼 왔다. 오늘날 비즈니스 가치 창출과도 직결되는 IT의 역할은 어떠해야 할까? 이 글을 통해 IT 리더십의 역할과 민첩성을 바탕으로 기업과 IT 조직의 관계를 재정의하여 이러한 가치를 극대화 할 수 있는 방법에 대해 이야기해보고자 한다.     고객 가치는 현업과 IT가 함께 생각해야 한다 대부분의 기업의 이해 관계자가 가지고 있는 가장 큰 오해 중 하나는 이미 고객을 잘 알고 있다고 생각하는 것이다. 현업 부서는 자신의 생각이 고객의 생각과 일치하고 있다는 착각을 바탕으로 현업 부서의 요구사항 또는 비즈니스의 요구사항(Business Requirement)을 다른 협업 부서에 전달하게 된다. 보통 기업내에서 IT 조직을 바라볼 때, 이런 비즈니스의 요구사항(Business Requirement)을 충족 시키기 위한 내부의 “고객-공급업체” 관계 모델, 즉 본질적으로 요구사항을 충족해주는 조직으로만 생각하는 경향이 많다. 그러나 이는 심각한 문제의 시작이 될 수 있다.  이러한 관점에서는 IT 기능을 아웃소싱하는 것이 너무나 당연해 보인다. IT는 이미 정해져 있는 비즈니스의 요구 사항에 대한 기능 구현이므로 정해진 시간과 비용으로 만들어 내야 하는 업무임은 물론, 핵심 비즈니스(core business) 활동으로도 인식되지 않기 때문에 아웃소싱이 효과적...

클라우드 AWS 혁신 IT 리더십 데브옵스

2022.04.01

비즈니스의 핵심은 고객가치의 이해에 있다. 어떤 기업이든 비즈니스에 있어서 고객이 혁신적인 아이디어를 발굴하고 제품화하여 경쟁 제품과 차별화할 수 있는 솔루션을 제공할 수 있는 전략이 필요하다. 이러한 전략은 고객이 진정으로 원하는 바를 이해하는 것에서부터 출발한다. 또한 기업이 제공하고자 하는 제품과 서비스를 고객의 니즈와 일치시킬수 있어야 한다. 이러한 과정은 결국 기업이 제공하고자 하는 제품이나 서비스의 특징 보다는 고객이 원하는 가치를 이해 하는 데에 더 많은 노력을 기울여야 함을 의미한다.  고객이 중시하는 가치와 IT 역할의 상관관계는 꽤 오랜 시간 이야기돼 왔다. 오늘날 비즈니스 가치 창출과도 직결되는 IT의 역할은 어떠해야 할까? 이 글을 통해 IT 리더십의 역할과 민첩성을 바탕으로 기업과 IT 조직의 관계를 재정의하여 이러한 가치를 극대화 할 수 있는 방법에 대해 이야기해보고자 한다.     고객 가치는 현업과 IT가 함께 생각해야 한다 대부분의 기업의 이해 관계자가 가지고 있는 가장 큰 오해 중 하나는 이미 고객을 잘 알고 있다고 생각하는 것이다. 현업 부서는 자신의 생각이 고객의 생각과 일치하고 있다는 착각을 바탕으로 현업 부서의 요구사항 또는 비즈니스의 요구사항(Business Requirement)을 다른 협업 부서에 전달하게 된다. 보통 기업내에서 IT 조직을 바라볼 때, 이런 비즈니스의 요구사항(Business Requirement)을 충족 시키기 위한 내부의 “고객-공급업체” 관계 모델, 즉 본질적으로 요구사항을 충족해주는 조직으로만 생각하는 경향이 많다. 그러나 이는 심각한 문제의 시작이 될 수 있다.  이러한 관점에서는 IT 기능을 아웃소싱하는 것이 너무나 당연해 보인다. IT는 이미 정해져 있는 비즈니스의 요구 사항에 대한 기능 구현이므로 정해진 시간과 비용으로 만들어 내야 하는 업무임은 물론, 핵심 비즈니스(core business) 활동으로도 인식되지 않기 때문에 아웃소싱이 효과적...

2022.04.01

도커 공동창업자가 만든 데브옵스 플랫폼 ‘대거’··· 공개 베타 시작

지난 2008년 컨테이너 소프트웨어 회사 ‘도커(Docker)’를 설립해 2018년 퇴사했던 공동창업자 솔로몬 하이크가 오랜 준비 기간을 걸쳐 마침내 ‘대거(Dagger)’를 공개적으로 출시했다.    도커 공동창업자 솔로몬 하이크, 전 도커 엔지니어링 부사장 샘 알바, 전 도커 수석 아키텍트 안드레아 루자디가 약 3년 전 만든 스타트업 ‘대거’는 엔지니어가 (어디서나 실행할 수 있는) 사전 정의된 구성요소 카탈로그에서 자체 CI/CD 파이프라인을 구축할 수 있게 하여 개발자가 다양한 배포 작업을 자동화할 수 있도록 지원하는 것을 목표로 한다.  공개 베타 버전 출시와 동시에 대거는 레드포인트 벤처스(Redpoint Ventures)가 주도하고 와이 콤비네이터(Y Combinator), 전 깃허브 CEO 냇 프리드먼, 전 구글 클라우드 CTO 브라이언 스티븐스, 전 레딧 CEO 엘렌 파오, 솔로닷아이오 창업자 이디트 레빈, 비트나미(Bitnami) 공동창업자 대니얼 로파즈, 프로메테우스 창시자 줄리어스 볼츠 등 업계 거물급 인사들이 참여한 2,000만 달러의 시리즈 A 라운드 투자를 유치했다.  대거는 이 투자금을 팀을 성장시키고, 오픈소스 커뮤니티 개발자의 관심을 높이는 데 활용할 계획이라고 밝혔다. 이 회사는 이전에 프리시드 및 시드펀딩을 합쳐 1,000만 달러를 모금한 바 있다.  하이크는 “거의 모든 컴퓨팅이 클라우드로 이동하면서 소프트웨어 공급망이 너무 크고 복잡해져서 심각한 병목 현상이 발생했다”라며, “이렇게 증가하는 복잡성으로 인해 다양한 전문 도구를 활용할 수 있는 데브옵스 엔지니어가 (자체) 파이프라인 연결에 시간을 낭비하고 있다. 이를 해결하는 것이 데브옵스의 성배이며, 대거가 이 문제를 해결했다고 믿는다”라고 말했다. ciokr@idg.co.kr

도커 데브옵스 대거 컨테이너 CI/CD

2022.03.31

지난 2008년 컨테이너 소프트웨어 회사 ‘도커(Docker)’를 설립해 2018년 퇴사했던 공동창업자 솔로몬 하이크가 오랜 준비 기간을 걸쳐 마침내 ‘대거(Dagger)’를 공개적으로 출시했다.    도커 공동창업자 솔로몬 하이크, 전 도커 엔지니어링 부사장 샘 알바, 전 도커 수석 아키텍트 안드레아 루자디가 약 3년 전 만든 스타트업 ‘대거’는 엔지니어가 (어디서나 실행할 수 있는) 사전 정의된 구성요소 카탈로그에서 자체 CI/CD 파이프라인을 구축할 수 있게 하여 개발자가 다양한 배포 작업을 자동화할 수 있도록 지원하는 것을 목표로 한다.  공개 베타 버전 출시와 동시에 대거는 레드포인트 벤처스(Redpoint Ventures)가 주도하고 와이 콤비네이터(Y Combinator), 전 깃허브 CEO 냇 프리드먼, 전 구글 클라우드 CTO 브라이언 스티븐스, 전 레딧 CEO 엘렌 파오, 솔로닷아이오 창업자 이디트 레빈, 비트나미(Bitnami) 공동창업자 대니얼 로파즈, 프로메테우스 창시자 줄리어스 볼츠 등 업계 거물급 인사들이 참여한 2,000만 달러의 시리즈 A 라운드 투자를 유치했다.  대거는 이 투자금을 팀을 성장시키고, 오픈소스 커뮤니티 개발자의 관심을 높이는 데 활용할 계획이라고 밝혔다. 이 회사는 이전에 프리시드 및 시드펀딩을 합쳐 1,000만 달러를 모금한 바 있다.  하이크는 “거의 모든 컴퓨팅이 클라우드로 이동하면서 소프트웨어 공급망이 너무 크고 복잡해져서 심각한 병목 현상이 발생했다”라며, “이렇게 증가하는 복잡성으로 인해 다양한 전문 도구를 활용할 수 있는 데브옵스 엔지니어가 (자체) 파이프라인 연결에 시간을 낭비하고 있다. 이를 해결하는 것이 데브옵스의 성배이며, 대거가 이 문제를 해결했다고 믿는다”라고 말했다. ciokr@idg.co.kr

2022.03.31

디지털 경험에 데브옵스 녹였다··· ‘웹옵스’ 따라잡기

많은 기업이 전자상거래에 진출하고, 고객이 원하는 것을 제공해야 하는 상황에 놓이면서 ‘온라인 경험’이 더욱더 중요해졌다. 온라인 경험은 사람들이 원하는 바에 따라 빠르게 변화해야 한다. 그렇다면 ‘웹옵스(WebOps)’는 어디에서 도움이 될 수 있을까? 팬데믹 2년, 모든 기업은 운영 방식을 바꿔야 했다. 전자상거래로의 전환 속도도 빨라졌다. 맥킨지에 따르면 유럽의 디지털 채택률은 81%에서 95%로 증가했다. 팬데믹 이전이라면 약 2~3년이 걸렸을 변화다. 이로 인해 (기업들은) 고객을 위한 디지털 경험을 구축하고 운영하는 데 초점을 맞추게 됐다. 바로 ‘웹사이트’다.   고객이 원하는 것을 제공하는 온라인 서비스와 사이트를 만드는 건 어려운 일이다. 오픈소스 콘텐츠 관리 시스템(Open-source Content Management System; CMS)은 여러 기업이 이를 달성하는 데 도움을 줬다. 하지만 이러한 사이트의 건전성을 유지해야 할 책임은 여전하다. 여기에는 기술 측면(웹사이트 플랫폼과 구성요소(플러그인 등)의 보안 관리 및 디도스(DDoS) 공격 방어 등)과 마케팅 요구사항(콘텐츠 및 새로운 서비스 업데이트 등)이 포함된다.  문제는 다음과 같다. 일반적으로 보안 업데이트는 IT가 한다고 쳐도, 사이트 갱신 또는 새로운 캠페인 등의 (웹사이트) 운영은 어떻게 관리해야 할까? 책임 소재는 어디이며, 팀 간의 협업이 제대로 이뤄지고 있는가? ‘웹옵스’의 세계 이 상황은 IT 운영 및 소프트웨어 개발 세계와 유사하다. 과거에는 개발자가 코드를 작성한 후, 새 소프트웨어를 IT 운영팀에 전달하여 생산에 투입했다. 개발자는 짧은 스프린트와 비즈니스 요구사항에 따라 새로운 기능을 제공하는 데 중점을 뒀다. IT 운영팀은 비즈니스 요구사항에 따라 서비스 가용성과 안전성을 담당했다. 두 팀 모두 저마다 목표와 지표가 달랐다. 데브옵스로 가보자. 데브옵스데이(DevOpsDays) 행사가 처음 열린 2009년 이후로, 데브옵스는 ...

웹옵스 웹 개발 소프트웨어 개발 데브옵스 전자상거래 고객 경험 직원 경험 온라인 경험 디지털 경험 팬데믹 웹사이트 마케팅 개발자 마이크로사이트 CMS

2022.03.29

많은 기업이 전자상거래에 진출하고, 고객이 원하는 것을 제공해야 하는 상황에 놓이면서 ‘온라인 경험’이 더욱더 중요해졌다. 온라인 경험은 사람들이 원하는 바에 따라 빠르게 변화해야 한다. 그렇다면 ‘웹옵스(WebOps)’는 어디에서 도움이 될 수 있을까? 팬데믹 2년, 모든 기업은 운영 방식을 바꿔야 했다. 전자상거래로의 전환 속도도 빨라졌다. 맥킨지에 따르면 유럽의 디지털 채택률은 81%에서 95%로 증가했다. 팬데믹 이전이라면 약 2~3년이 걸렸을 변화다. 이로 인해 (기업들은) 고객을 위한 디지털 경험을 구축하고 운영하는 데 초점을 맞추게 됐다. 바로 ‘웹사이트’다.   고객이 원하는 것을 제공하는 온라인 서비스와 사이트를 만드는 건 어려운 일이다. 오픈소스 콘텐츠 관리 시스템(Open-source Content Management System; CMS)은 여러 기업이 이를 달성하는 데 도움을 줬다. 하지만 이러한 사이트의 건전성을 유지해야 할 책임은 여전하다. 여기에는 기술 측면(웹사이트 플랫폼과 구성요소(플러그인 등)의 보안 관리 및 디도스(DDoS) 공격 방어 등)과 마케팅 요구사항(콘텐츠 및 새로운 서비스 업데이트 등)이 포함된다.  문제는 다음과 같다. 일반적으로 보안 업데이트는 IT가 한다고 쳐도, 사이트 갱신 또는 새로운 캠페인 등의 (웹사이트) 운영은 어떻게 관리해야 할까? 책임 소재는 어디이며, 팀 간의 협업이 제대로 이뤄지고 있는가? ‘웹옵스’의 세계 이 상황은 IT 운영 및 소프트웨어 개발 세계와 유사하다. 과거에는 개발자가 코드를 작성한 후, 새 소프트웨어를 IT 운영팀에 전달하여 생산에 투입했다. 개발자는 짧은 스프린트와 비즈니스 요구사항에 따라 새로운 기능을 제공하는 데 중점을 뒀다. IT 운영팀은 비즈니스 요구사항에 따라 서비스 가용성과 안전성을 담당했다. 두 팀 모두 저마다 목표와 지표가 달랐다. 데브옵스로 가보자. 데브옵스데이(DevOpsDays) 행사가 처음 열린 2009년 이후로, 데브옵스는 ...

2022.03.29

기고 | '대규모 마이크로서비스 구축 및 실행은...' 프라이스라인의 앱 현대화

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

마이크로서비스 데브옵스 컨테이너 쿠버네티스 12요소 모노리포 종속성 프라이스라인

2022.02.28

‘혁신가의 딜레마’라는 책에도 나오듯이, 오늘날의 성공적인 조직은 번성하기 위해 계속해서 새로운 프로세스를 도입해야 하는 과제에 직면해 있다. 소프트웨어 개발에 의존해 경쟁 우위를 유지하는 현대의 조직이 이 끊임없는 변화의 필요성에 대처하려면 개발팀의 사고방식을 바꿔야 한다. 프라이스라인(Priceline)에서 이 말은 새롭고 혁신적인 기술 도입, 그리고 서비스를 구축하고 배포하는 방법에 있어서 완전히 새로운 사고방식을 의미한다. 프라이스라인은 월별 방문자 수가 수백만 명에 달하는 세계에서 가장 인기 있는 여행 사이트 중 하나이다.   경쟁이 극히 치열한 시장에서 성공을 지속하려면 완전히 새로운 서비스 제공 전략을 지원해야 하며, 이를 위해서는 기술 리더십의 치밀한 사고와 행동이 필요하다. 프라이스라인의 유능한 기술팀은 여행 업계의 기술 발전을 선도하고자 12요소(12 Factor) 앱 개발, 모노리포(Monorepo), 트렁크 기반 개발, 종속성 관리를 채택했다. 그러나 여전히 할 일이 많이 남아 있다.  컨테이너 기반 마이크로서비스를 생각해보자. 불과 몇 년 전과 비교해도 기업의 컨테이너 및 쿠버네티스 도입은 크게 늘었다. 2020 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation) 설문에 따르면, 프로덕션에서의 컨테이너 사용은 2016년 이후 300% 증가했다. 현재 프라이스라인 전체 제품 플랫폼의 80%는 구글 클라우드에서 컨테이너와 쿠버네티스를 기반으로 실행된다.  대형 IT 업체의 상당수는 이런 애플리케이션 개발 패러다임의 변화가 주는 혜택을 활용하고 있지만(새로운 과제도 발견), 많은 기업이 이제 막 이 여정을 시작하는 단계에 있다. 하지만 지금의 경제 상황을 보면 증가하는 소프트웨어 개발 수요를 충당할 만큼의 데브옵스와 SRE 전문가를 채용할 수는 없을 것이다. CTO는 애플리케이션의 탄력성과 확장성을 높일 방법뿐만 아니라 개발자에게 수작업의 부담을 지나치게 전가하지 않으...

2022.02.28

‘마이크로 매니징은 해법 아니다’ 개발자 관리 방안 7가지

우수한 개발자들은 조직의 미세 관리(Micro management)를 못 견뎌 하는 경향을 가진다. 여기 개발자의 반발을 사지 않고도 개발팀의 성과와 비즈니스 목표를 정렬할 수 있도록 해주는 7가지 방안을 정리했다.    올해 들어 유독 자주 받은 질문이 있다. 하이브리드 근무 모델을 도입할 때 소프트웨어 개발자의 생산성, 품질, 성과를 어떻게 측정할 지와 관련된 것들이었다. 경영진이라면 해야 할 고민이기는 하다. 그러나 유능한 소프트웨어 개발자를 고용해 유지하기가 쉽지 않은 현실을 직시할 필요가 있다. 유능한 소프트웨어 개발자는 미시적 관리를 달가워하지 않을 것이며, 마이크로 매니지먼트 문화가 없는 곳으로 떠날 가능성이 크다. 개발 경험이 전무한 관리자에게 보고하도록 개발자에게 주문한다면 업무 관료주의에 대한 공포가 촉발된다. 자율성 원리를 옹호하는 소프트웨어 개발자는 전적인 자율을 원하고 경영진이 생산성, 품질, 여타 성과 고려사항을 측정하려 드는 어떤 징후에든 반발할 것이다. 소프트웨어 개발자들은 으레 마이크로 매니지먼트를 혐오한다. 또 다수의 소프트웨어 개발자가 연간 성과 리뷰를 경멸한다. 개발자 대부분은 실시간 성과 목표를 추구하고, 속도, 코드 개발 빈도, 순환 시간, 여타 핵심 성과 지표를 개선하려고 노력한다. 스크럼 팀은 스프린트가 종결될 때마다 성과를 논의하기 때문에 연간 및 분기 성과 리뷰 작업이 불필요하거나 무의미해 보이기 쉽다. 그러나 조직으로서는 가만히 맡겨둘 수 없다. 애자일 팀 및 소프트웨어 개발자가 성과, 개발, 사업 목표를 충족했거나 초과했는지를 인식할 방법이 있어야 한다는 실체적 현실 역시 존재한다. 매니저는 어떻게 하면 개발자를 괴롭히지 않으면서 자신이 필요한 것을 얻어낼 수 있을까?  아래에서는 애자일, 스크럼, 데브옵스 원리, 그리고 소프트웨어 개발 수명주기에 합치하고, 아울러 소프트웨어 개발자를 평가할 때 적용할 수 있는 7가지 권장 관행을 살펴본다. 필자가 이를 SMART 목표로...

마이크로 매니저 미세 관리 개발자 성과 개발팀 관리 애자일 데브옵스 관료주의

2022.02.16

우수한 개발자들은 조직의 미세 관리(Micro management)를 못 견뎌 하는 경향을 가진다. 여기 개발자의 반발을 사지 않고도 개발팀의 성과와 비즈니스 목표를 정렬할 수 있도록 해주는 7가지 방안을 정리했다.    올해 들어 유독 자주 받은 질문이 있다. 하이브리드 근무 모델을 도입할 때 소프트웨어 개발자의 생산성, 품질, 성과를 어떻게 측정할 지와 관련된 것들이었다. 경영진이라면 해야 할 고민이기는 하다. 그러나 유능한 소프트웨어 개발자를 고용해 유지하기가 쉽지 않은 현실을 직시할 필요가 있다. 유능한 소프트웨어 개발자는 미시적 관리를 달가워하지 않을 것이며, 마이크로 매니지먼트 문화가 없는 곳으로 떠날 가능성이 크다. 개발 경험이 전무한 관리자에게 보고하도록 개발자에게 주문한다면 업무 관료주의에 대한 공포가 촉발된다. 자율성 원리를 옹호하는 소프트웨어 개발자는 전적인 자율을 원하고 경영진이 생산성, 품질, 여타 성과 고려사항을 측정하려 드는 어떤 징후에든 반발할 것이다. 소프트웨어 개발자들은 으레 마이크로 매니지먼트를 혐오한다. 또 다수의 소프트웨어 개발자가 연간 성과 리뷰를 경멸한다. 개발자 대부분은 실시간 성과 목표를 추구하고, 속도, 코드 개발 빈도, 순환 시간, 여타 핵심 성과 지표를 개선하려고 노력한다. 스크럼 팀은 스프린트가 종결될 때마다 성과를 논의하기 때문에 연간 및 분기 성과 리뷰 작업이 불필요하거나 무의미해 보이기 쉽다. 그러나 조직으로서는 가만히 맡겨둘 수 없다. 애자일 팀 및 소프트웨어 개발자가 성과, 개발, 사업 목표를 충족했거나 초과했는지를 인식할 방법이 있어야 한다는 실체적 현실 역시 존재한다. 매니저는 어떻게 하면 개발자를 괴롭히지 않으면서 자신이 필요한 것을 얻어낼 수 있을까?  아래에서는 애자일, 스크럼, 데브옵스 원리, 그리고 소프트웨어 개발 수명주기에 합치하고, 아울러 소프트웨어 개발자를 평가할 때 적용할 수 있는 7가지 권장 관행을 살펴본다. 필자가 이를 SMART 목표로...

2022.02.16

회사명:한국IDG 제호: ITWorld 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아00743 등록일자 : 2009년 01월 19일

발행인 : 박형미 편집인 : 박재곤 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2022 International Data Group. All rights reserved.

10.4.0.13