호주의 개발 툴 기업 퍼포스가 인프라 자동화 소프트웨어 벤더 퍼펫(Puppet)을 인수한다. 거래 금액은 공개되지 않았다. 퍼포스는 여러 개발자 도구, 특히 데브옵스에 특화된 라인업을 보유하고 있다. 대표적인 제품으로는 헬릭스(Helix)가 있다. 퍼펫은 2005년 오레곤 주 포틀랜드에서 설립된 기업으로 초기 코드로서의 인프라스트럭처(infrastructure as code) 분야를 주도했다. 이후에는 좀더 광범위한 인프라 자동화 및 컴플라이언스 도구 분야에 진출했다.  퍼펫과 함께 코드로서의 인프라스트럭처 분야를 이끈 기업으로는 셰프, 앤서블, 솔트 등이 있다. 앤서블은 2015년 레드햇에 인수됐으며, 솔트스택은 2020년 VM웨어가 인수했다. 셰프도 2020년 프로그레스가 인수했다. 퍼펫 또한 이번에 인수됨으로써 이들 4곳의 기업 모두가 매각되게 됐다.  한편 오늘날 인기 있는 인프라 오케스트레이션 도구는 AWS나 구글, 마이크로소프트의 자체 툴인 경향을 보인다. 예외적인 존재로는 오픈소스 해시코프테라폼(Hashicorp Terraform)가 있다.    퍼펫의 이본느 와세나 CEO는 “퍼펫과 마찬가지로 퍼포스는 강력한 고객 기반을 보유하고 있다. 디지털 크리에이션과 플래닝, 개발자 생산성 도구, 자동화된 테스트와 품질을 제공하는 신뢰할 수 있는 데브옵스 분야의 리더다. 단 ‘빠진 고리’가 있다. 퍼펫의 스윗 스팟인 코드로서의 인프라다”라고 밝혔다.  이번 거래는 5월 중 마무리될 예정이다. 퍼포스는 이번 인수 이후 500명의 직원이 속한 퍼펫이 당분한 독립 비즈니스 유닛으로 동작할 것이라고 전했다. ciokr@idg.co.kr

2022.04.12

애자일(Agile) 방법론이 등장한 지 2021년을 기준으로 꼭 20년이 됐다. 일부 스타트업이 공동 장소에서 스티커와 화이트보드를 가지고 협업하던 비주류 방법론이 이제는 정교하고 확장성 있고 널리 쓰이는 애자일 소프트웨어 개발 프로세스와 툴로 발전했다.   애자일 개발은 오랜 기간 사용되고 많은 기업이 스크럼, 칸반 등의 애자일 기법을 이용해 애플리케이션을 현대화하고 고객 경험을 개선하고 디지털 트랜스포메이션을 이행하는 데는 그만한 이유가 있다. 디자인 씽킹, 제품 관리, 데브옵스와의 접점에 대한 방대한 지식이 쌓이는 것도 같은 맥락이다. 이제 사람들은 ‘애자일이 무엇인가?’라고 묻지 않는다. 오히려 자기 팀에 최고의 애자일 방법론을 적용할 방법을 활발하게 논의한다. 여기서는 다시 기본으로 돌아가 사람과 팀, 프로세스, 툴과 함께 애자일 방법론의 기초를 알아본다. 또한, 애자일이 데브옵스와 어떻게 연결되는지 살펴보고, 애자일 문화를 양성하고 고품질의 소프트웨어를 완성하는 모범 관행을 소개한다.   애자일 방법론에서의 주요 역할들 애자일 소프트웨어 개발 프로세스는 언제나 특정 제품의 사용자를 정의하고, 다뤄야 할 문제와 기회, 가치의 범위에 관한 비전을 문서화하며 시작한다. 제품 소유자(Productowner)는 이 비전을 포착하고 이를 달성하기 위해 다양한 팀과 협업하며 애자일 개발 프로세스에는 여러 역할이 관여한다. 사용자 : 애자일 프로세스는 언제나 사용자(User) 또는 고객을 염두에 두면서 시작한다. 오늘날에는 일반적으로  고객 요구 및 행동의 다른 워크플로우 역할/유형을 정형화한 사용자 페르소나(User Personas)를 정의한다. 제품 소유자 : 제품 소유자는 내부 이해관계자 등 고객의 목소리를 담당한다. 통찰, 발상, 피드백을 종합해 제품 비전을 만든다. 보통 제품 비전은 단순하고 직접적이지만, 고객 또는 사용자가 누구이고, 어떤 가치를 다루는지, 이들을 다루는 전략에 대한 전체 그림을 반영한다. 예를 들면 ...

2022.04.12

변화와 안정성은 IT팀에게 상충되는 화두다. 기존 플랫폼의 신뢰성이 중요하지만 끝없는 개선을 갈망하기도 한다. 관건은 기업들이 필요로 하는 탄탄한 가용성을 희생하지 않으면서 새로운 것을 제공하는 것이다. 그 방법을 찾아가는 과정은 불여튼튼을 외치는 안정론자와 혁신을 원하는 반항적인 몽상가들 사이의 전쟁이 될 수 있다. 좋은 IT팀에는 두 캐릭터가 모두 필요하다. IT의 중요성을 강조한 팬데믹 사태 이후 그 중요성이 그 어느 때보다 커졌다. 기업들은 신뢰할 수 있는 디지털 네트워크 없이 기능할 수 없다. 하지만 빠르게 움직이고 실험하는 능력이 없다면 선진화를 통해 급변하는 시대의 요구를 충족시킬 수 없다. 신뢰성을 확보하면서도 혁신을 조성하기 위해 IT가 애용하는 접근법을 살펴본다. 이런 트렌드 중 일부는 새로운 혁신에 의한 것이며, 순수한 경제성 측면에 의한 것들도 있다. 또 일부는 정치적 현실에 기인한 것들이다. 이 모든 것들이 IT 인프라팀들이 안정성을 희생하지 않고 추가적인 보안과 더 빠른 속도를 제공해야 한다는 압박감을 상징하고 있다.   인기 : 멀티클라우드(Multicloud) 서버실에서 클라우드로 이전할 때의 장점은 이제 널리 인정받고 있다. 다른 사람이 유지관리하고 임대하는 기기들은 간헐적인 컴퓨팅 및 워크로드에 이상적이다. 신뢰와 보안에 대한 문제는 남아 있겠지만 클라우드 벤더들은 규모의 경제를 통해 이를 신중하게 해결해가고 있다. 1개의 클라우드가 좋다면 2개나 3개는 어떨까? 여러 개의 클라우드를 지원하는 것이 더 수고스러울 수 있지만 개발자가 코드를 신중하게 작성하면 제공업체에의 종속(Lock-in)이라는 위험을 없앨 수 있다. 그리고 기업 회계사들은 여러 클라우드를 벤치마크해 각 워크로드에 가장 저렴한 제공업체를 찾을 수 있다는 점에 기뻐할 것이다. 비인기 : 동적 웹 사이트 월드 와이드 웹(World Wide Web)은 처음부터 정적 파일로 구성되어 있었다. 웹 서버는 URL을 받고 모두에게 같은 파일로 ...

2022.04.08

지난 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

많은 개발자가 자기 조직화된 애자일 팀에 소속돼 혁신적인 솔루션을 개발하는 것을 좋아한다. 이들은 스프린트 리뷰에서 문제 논의, 장애물 해결, 회고, 결과 공유의 필요성도 인지하고 있다. 하지만 개발자는 너무 많은 회의에 참석하거나 제대로 관리되지 않는 회의에 시간을 낭비하는 것을 극히 싫어한다. 쏟아지는 긴급 이메일과 즉흥적인 줌 회의, 잦은 슬랙 메시지는 생산성을 갉아먹을 수 있다. 코딩은 집중이 필요한 작업이다. 산만함은 소프트웨어 결함과 품질 문제로 이어질 수 있다.     회의 관행 및 방식 점검 애자일과 스크럼 초창기에는 화이트보드와 포스트잇을 사용해 백로그를 관리했지만 지금은 많은 팀이 지라 소프트웨어(Jira Software)와 digital.ai, 애저 데브옵스(Azure DevOps) 등 애자일 툴로 이런 아날로그 방식을 대체했다. 많은 애자일 전문가가 개방된 공간에 여러 팀이 모여서 작업하는 방식을 선호하지만 지리적으로 분산된 팀 환경에서의 애자일을 위한 지침도 많다. 어쩌면 지금이 바로 하이브리드 환경에서의 회의 방식을 점검해야 할 때일지도 모른다. 링크드인(LinkedIn) 생산성 엔지니어링 부문 부사장 사브리 토진은 “최상의 툴을 사용하는 것은 엔지니어링 및 개발자 커뮤니티에서 중요하며, 개발자의 행복과도 직결된다. 개발자는 중단 없이 작업을 완료하는 것을 선호하기 때문에 하이브리드 환경의 조직은 더욱 매끄러운 하이브리드 작업 경험을 실현하면서 인재를 유인하고 보존하는 툴에 투자해야 한다”라고 말했다. 데브그래프(DevGraph) 최고 제품 책임자인 라비 두두쿠루 역시 토진과 입장을 같이하며 개발 관리자와 제품 소유자, 스크럼 관리자가 회의 관리 방식을 조정해야 하며 시간과 의제를 관리하는 것은 더욱 중요하다고 말했다. 두두쿠루는 “모두가 사무실에서 일했던 시절에는 스탠드업 미팅으로 회의의 효율성을 달성했다. 원격 애자일 및 앱 개발 회의에도 동일한 방법을 적용해야 한다. 목적과 의제가 명확하고 모두가 무엇...

2022.03.24

소프트웨어 개발자와 설계자는 한때 로우코드 기술에 회의적이었다. 하지만 오늘날 애자일 개발 팀이 생산성을 개선하고 품질을 높이며, 배포 빈도를 높이는 것을 가능하게 하는 발전한 로우코드 플랫폼이 많다. 개발자는 로우코드 기술을 사용해 앱과 고객 환경, 포털, 검색 환경, 워크플로우 통합, 데이터 파이프라인, 데이터 스트림, 대시보드, 테스트 자동화, 머신러닝 모델을 비롯한 다양한 솔루션을 구축한다.   미국 블록체인 스타트업 플루리(Fluree)의 공동 CEO인 브라이언 플라츠는 올해 로우코드 기술에 큰 관심이 쏠리고, 지속될 이유를 설명했다. 플라츠는 “로우코드 개념은 견고하고 올해에도 로우코드 사용이 증가할 것으로 보인다. 로우코드는 IT 리소스의 부담을 덜어주고 비즈니스 부서에 고도의 맞춤형 소프트웨어를 제공하며, 궁극적으로는 지속적인 디지털 트랜스포메이션을 지원한다. 단, 로우코드는 확장 가능한 데이터 플랫폼과 엄격한 거버넌스 모델을 바탕으로 해야 한다. 그렇지 않을 경우, 맞춤형 앱의 과잉이 극심한 데이터 사일로로 이어질 수 있다”라고 설명했다. 플라츠는 로우코드 플랫폼을 선택할 때 고려해야 할 소프트웨어 아키텍처에 관해 몇 가지 우려점을 강조했다. 하지만 장점도 많다. 특히, 로우코드는 다수의 맞춤형 애플리케이션을 개발하고 지원하는 기업이 오랫동안 씨름해온 아키텍처 측면의 여러 과제를 해결해줄 수 있다. 여러 리더 및 전문가가 밝힌 IT 기업이 엔터프라이즈 아케텍처에 로우코드 솔루션을 도입해야 하는 이유는 다음과 같다.   기술 부채 방지 기술 부채 위협의 증대에 관한 연구에 따르면, 기업은 IT 예산의 40% 이상을 운영이나 새로운 기능 구축이 아닌 기술 부채를 해결하는 데 쏟아붓는 것으로 나타났다. 여기서 지목된 가장 중대한 2가지 문제는 개발 팀의 이직이 잦고 개발 언어 및 프레임워크가 너무 많다는 점이다. 로우코드 솔루션은 시각적 프로그래밍 패러다임인 경향이 있어 새로운 개발자가 지원 업무를 맡게 될 때 한결 쉽게 이...

2022.02.24

유연하면서도 생산적인 IT 조직을 구성하려면 인사이트, 인내, 창의성 등 일련의 자질을 갖춘 CIO가 필요하다. 또 기존 및 새로운 문제에 대해 새로운 접근방식을 개발할 준비가 완료된 팀이 필요하다.  CIO가 새로운 시대가 요구하는 생산성을 추구하며 IT 조직 구조를 개편하고자 할 대 참고할 만한 6가지 팁을 정리했다.    IT 운영 모델을 업데이트 우선, IT가 기업에 가치를 더해주는 방법과 영역을 결정하라고 IT 자문 및 컨설팅 기업 ITRG(Info-Tech Research Group)의 수석 CIO 활동 책임자 발렌스 하우든이 말했다.  먼저 부서가 임무를 달성하기 위해 필요한 역량과 이런 역량이 어떻게 조합되고 상호작용하는지 파악한다. 그리고 조직에 필요한 방식에 따라 운영을 조정한다. 예를 들어, 애자일 팀의 경우 전통적이거나 제품/서비스 중심적인 인력과 다른 구조를 갖는다고 하우든이 말했다. 그는 “또한 거버넌스와 새로운 구조를 일치시켜 효과성을 확보하고 성과 지표를 변경해야 한다”라고 덧붙였다. 이 모델을 구현하는 가장 좋은 방법은 기업이 무엇을 하려 하는지, 즉 기업의 가치 제안과 결과물을 파악하는 것이다. 하우든은 “그 인사이트를 활용하여 이런 목표를 달성하기 위해 IT가 어떠해야 하는지 판단한다. IT 조직의 구조조정을 위한 좋은 시발점이 될 것이다. 또한 격차 또는 새로운 IT 역량이 필요할 수 있는 기회를 찾는 데 도움이 될 것이다”라고 말했다. 하우든에 따르면 업데이트된 운영 모델을 통해 IT가 조직의 필요를 지원하기 위해 팀의 속도와 업무 방식에 맞추게 되면서 바람직한 상황이 조성될 수 있다. 그는 “조직의 목표 달성과 일치하지 않는 생산성은 가치가 제한적이다”라고 밝혔다. 매트릭스화된, 교차 기능적 접근방식을 고려 기술 연구 및 자문 기업 ISG의 파트너 올라 차우닝은 많은 IT 조직들이 이중 보고 구조를 생성하는 방식으로 생산성 개선에 매트릭스 접근방식을 취하고 있다고 전했다. 우...

2022.02.17

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

2022.02.16

애자일 매니페스토는 ‘프로세스와 툴보다 개인과 상호작용’에 더 가치를 둔다. 창안자의 핵심 원칙은 “최선의 아키텍처와 요구사항 및 설계는 자기조직화(self-organizing)가 된 팀에서 나온다”는 것이다. 필자도 이 원칙에 동의하지만, 실제 환경에서 자기조직화 팀이 어떻게 움직여야 하고, 최선의 결과를 달성하는 과정에서 의사결정 권한이 얼마나 도움이 되는지에 관해서는 실용적인 관점으로 접근해야 한다.   예를 들어 팀이 이상적인 아키텍처를 선택해 설계할 권한을 얻는다면 성과도 최적화되겠지만, 20개에 달하는 팀이 모두 각각 독립적인 아키텍처를 관리한다면 조직 관점에서는 상당한 골칫거리다.   또한, 프로세스와 툴이 더욱 개인과 원활하게 상호작용할 필요도 있다. 백로그 상태를 캡처하고 사용자 스토리를 표준으로 범주화하며 아키텍처를 문서화하면 팀 상호작용을 개선하고 회의에 소비하는 시간을 줄이는 데 도움이 된다.   애자일 자기조직화 팀에는 업무 역량 계획이 필요 애자일 업무 역량 계획은 많은 애자일 팀에서 기피하는 영역이다. 업무 역량 계획은 사람마다 생각하는 뜻이 다르므로 업무 역량 분석을 요청하거나 기술 공백 계획을 수립할 때는 맥락이 필요하다. 또한 업무 역량 계획 방법은 프로그램 관리 및 시스템 엔지니어링 분야에서 처음 개발됐는데, 이 분야는 애자일과 반대되는 영역으로 인식되는 경우도 있음을 생각해야 한다.   난점은 조달, 온보딩, 통합에 리드 시간이 필요하기 때문에 인력, 기술, 파트너십 등 애자일 팀에 필요한 요소 상당수에 사전 예측이 필요하다는 것이다. 애자일 리더는 업무 역량 계획을 생산성을 개선하고 무력감을 방지하고 데브옵스 투자에 대한 지지를 얻고 목표를 가로막는 장애물을 줄일 기회로 생각해야 한다.   그 외의 시간에는 애자일 팀은 비즈니스 관계자와 파트너가 되어 예정된 결과물에 대한 시야를 제공해야 한다. 팀의 속도와 생산성에 영향을 미칠 수 있다는 면에서 업무 역량 계획도&n...

2022.01.13

개발자들에게 선택되는 기술이 엔터프라이즈 소프트웨어 시장을 어떻게 변화시켰는지에 관한 내용을 담은 스테판 오그래디의 저서 ‘새로운 킹메이커(The New Kingmakers)’가 나온 지 9년이 됐다. 당시 개발자들은 오픈소스와 클라우드를 선택했고, 컨테이너 오케스트레이션의 주인공으로 쿠버네티스를 캐스팅했으며, 서버리스로 전환했다.   이 접근 방식들은 개발자의 삶을 더 편리하게 만들었기 때문에 인기를 얻었다. 이를테면 개발자들이 애플리케이션을 원활하게 작동시키고, 확장할 수 있도록 했다. 하지만 서비스 및 애플리케이션을 클라우드로 이전할 수 없거나 (또는) 옮기려 하지 않거나 아니면 온프레미스로 실행하는 게 좋다고 보는 기업들도 있다.  개발자들의 싸움은 계속되고 있다. 2022년에는 어떤 일이 일어날까?   #1. ‘플랫폼 엔지니어링’이 데브옵스 및 SRE을 대신할 것이다 개발자들은 애플리케이션을 빠르고 효율적으로 배포하길 원한다. 이는 데브옵스 프로세스와 배포 프로세스를 거쳐 프로덕션 환경까지의 더 많은 협업으로 이어졌다. 이후 구글의 SRE(Site Reliability Engineering) 접근 방식이 인기를 얻으면서, 인프라 관리에 소프트웨어 엔지니어링 원칙을 적용하고 이를 가용성 및 안정성을 개선하는 데 활용했다.  다음 단계는 ‘플랫폼 엔지니어링’이다. 플랫폼 엔지니어링은 티켓을 접수하거나 팀 간에 핸드오프를 수행하는 전통적인 접근 방식이 아니라, 셀프서비스 인터페이스의 형태로 팀 간에 명확한 ‘계약’을 만드는 것이다. 퍼블릭 클라우드를 사용하는 것이 플랫폼 엔지니어링 접근 방식의 예다.  내부 플랫폼 팀은 기존 솔루션과의 통합, 전체 환경의 맥락 인식, 문서화 및 교육을 통한 지원을 제공한다. 기본 플랫폼 팀은 워크플로우, 자동화, 소스 제어 및 셀프서비스를 기반으로 자체 애플리케이션 및 인프라를 만들고 실행하는 방법을 정의한다.  각 팀이 애플리케이션에 기본 기능을 제공하기 ...

2022.01.03

소규모 사용자 그룹이 새로운 기능 및 서비스를 사용할 수 있도록 하는 것은 위험을 줄이는 좋은 개발 전략이다.  클라우드와 마이크로서비스 이전 시대의 ‘개발, 테스트, 프로덕션, 재해 복구(DR)’ 배포 패러다임을 기억하는가? 당시에는 인프라를 구매하고, 구성하며, 유지관리하는 비용이 많이 들고 복잡했기 때문에 데이터센터 운영팀은 더 많은 환경과 배포 유연성을 확보하는 데 거의 동의하지 않았다.  오늘날 데브옵스 조직은 지속적 통합/지속적 제공(CI/CD)을 사용하여 딜리버리를 자동화하고, 코드형 인프라(Infrastructure as Code; IaC)를 활용해 인프라를 구성하며, 쿠버네티스를 통해 환경을 컨테이너화한다. 또 지속적인 테스트로 품질을 높이고, AI옵스(AIops)를 사용하여 모니터링 및 관찰 가능성을 중앙집중화한다. 이러한 관행 덕분에 배포 빈도를 높이는 동시에 변경으로 인한 보안, 성능, 안정성 위험을 최소화할 수 있다. 하지만 변경 사항과 액세스 권한에 따라 위험을 줄이고 릴리즈를 제어하고자 한다면 애플리케이션 또는 배포를 구성하고 관리하는 추가적인 기법이 필요하다.    릴리즈 파이프라인에는 유연한 관리 및 배포 옵션이 필요하다 배포를 제어하는 한 가지 방법은 기능 플래그를 활용하여 사용자별로 기능 액세스를 전환, A/B 테스트, 세분화하는 것이다. 데브옵스 팀은 기능 플래그를 사용하여 앱을 클라우드로 이동하거나, 단일 애플리케이션을 마이크로서비스에 리팩토링할 때 새롭게 개발한 기능을 검증할 수 있다. 기능 플래그는 앱 또는 마이크로서비스의 기능을 확인할 수 있는 사람을 통제하려는 개발팀과 제품 관리자에 유용하다. 하지만 때때로 데브옵스 또는 IT 운영팀은 배포를 관리하고 프로덕션 환경에 투입된 애플리케이션의 여러 버전을 관리할 수 있는 유연성이 필요하다. 몇 가지 예는 다음과 같다.  • 운영체제, 데이터베이스, 미들웨어 등의 중요한 시스템 구성 요소를 패치하거나 업그레이드할 때...

2021.12.30

깃랩 소프트웨어 딜리버리 플랫폼의 최신 릴리즈가 출시됐다. 회사에 따르면 ‘깃랩 14.6(GitLab 14.6)’에서는 지리적으로 분산된 애플리케이션 배포 기능이 개선됐다. 마이크로소프트의 닷넷 6(.NET6) 소프트웨어 개발 플랫폼을 대상으로 하는 취약점 스캔 기능도 추가됐다.    지난 12월 22일(현지 시각) 공개된 버전 14.6에서는 ‘깃랩 지오(GitLab Geo)’의 구성이 단순화됐다. 이를 통해 깃랩 인스턴스의 읽기 전용 미러와 쓰기 가능 미러를 모두 사용할 수 있게 됐다고 회사 측은 전했다. ‘지오’는 전 세계에 분산돼 있는 팀이 가장 가까운 지오 사이트를 자동으로 사용하여 깃 풀 명령을 가속화할 수 있도록 지원한다.  깃랩 14.6 이전 버전에서는 사용자가 모든 깃 작업에 단일 통합 URL을 사용하여 깃랩 지오를 설정할 수 있었다. 하지만 지오 복제본에는 웹 UI 및 API 액세스를 위한 자체 URL이 있어야 했다. 또 지오 복제본의 웹 UI는 읽기 전용이어서 사용자가 페이지를 보는 것을 제한하고 전체 사이트에서 변경을 수행해야 했다.  깃랩 14.6을 사용하면 지오 보조 사이트가 대부분의 읽기 요청을 가속화하는 동시에 기본 사이트로 쓰기 요청을 프록시한다. 아울러 관리자는 조직 전체의 깃랩 사용자에게 가장 가까운 지오 사이트를 자동으로 사용하는 단일 URL을 제공할 수 있다고 회사 측은 말했다. 이제 분산된 팀이 가속화된 git clone 또는 git pull 명령과 원활한 전 세계 환경의 이점을 누릴 수 있다는 설명이다.  한편 깃랩은 얼티메이트(Ultimate) 기능을 대부분 사용할 수 있는 30일 무료 평가판을 제공한다. 얼티메이트 계층은 보안, 컴플라이언스, 포트폴리오 관리 기능을 추가한다. 이 밖에 깃랩 14.6의 개선사항은 다음과 같다.  • 지난 11월 프로덕션 릴리즈로 출시된 마이크로소프트 닷넷 6(.NET 6)가 깃랩 SAST(Static Application...

2021.12.27

깃랩이 12월 21일 데브옵스 플랫폼과 데브옵스 산업 전반에 걸쳐 자사의 임원진들이 진단한 주요 전망 내용을 공개했다.  깃랩 전문가들은 2022년에는 특히 AI와 머신러닝 통합이 가속화되고, 개발 주기에서 보안을 더욱 강화하는 것은 물론, 오픈소스 및 원격근무 기회를 확장하는데 있어 데브옵스(DevOps)의 중요성이 더욱 가시화될 전망이라고 밝혔다. 깃랩 테일러 맥카슬린 모델옵스(ModelOps) 제품 수석 매니저는 “AI 및 머신러닝 채택이 증가하면서 공급망 문제와 인력 부족을 해결하는데 중요한 역할을 할 것”이라고 말했다.  회사에 따르면 인력 및 공급망 부족, 기후변화 등과 관련한 역동적인 환경에 대응하기 위해 모든 산업 분야에서 AI와 머신러닝 채택이 증가하게 될 것이다. 여전히 기존의 데브옵스 기술과 새로운 데이터 과학 플랫폼 간의 마찰이 가치실현 속도를 저하시키고, AI 및 머신러닝 기술 개발 비용을 증가시키고 있지만, 이러한 문제들이 점차 해소되고, 격차가 줄어들면서 비용과 복잡성은 감소하게 될 것이라고 업체 측은 예측했다. 조나단 헌트 보안 부문 부사장은 “기업들은 계속해서 데브옵스에 보안을 더욱 긴밀하게 통합하고, 데브섹옵스(DevSecOps) 팀을 구성하여 위험을 줄이고, 배포시간을 단축하여 경쟁 우위를 확보하고자 할 것”이라고 밝혔다.  데브섹옵스 수행 사례는 효율성과 보안 향상의 이점이 인식되면서 2022년에도 계속 증가할 것으로 예상된다. 또한 원격근무 모델 도입으로 대두되는 전반적인 위험 요소들을 효과적으로 관리하기 위해 데브섹옵스를 우선적으로 고려하는 혁신적인 방법에 집중해야 한다. 데브섹옵스는 위험 및 보안 사고를 줄이는 동시에, 더 빠르고, 안전하게 코드를 배포할 수 있는 입증된 전략이다.  조나단 헌트 보안 부문 부사장은 “2021년 가장 큰 화두였던 쿠버네티스(Kubernetes)와 제로 트러스트(Zero Trust)는 내년에 다른 양상을 보이게 될 것”이라고 전망했다.&...

2021.12.21

SLA(Service Level Agreement)는 1980년대 유선전화 통신사 사이에서 인기를 얻기 시작했다. 지난 20년 동안 미국 주요 도시의 도로 곳곳에 9x5(99.999%)를 홍보하는 광고판이 걸렸다. 그러나 지금 시점에서 SLA에 포함된 9의 수가 통신사 내에서, 그리고 외부적으로 고객에게 안정성을 전달하는 지표로서 적절할까?    SLA가 존재하는 이유가 있다. 바로 변호사이다. 누구나 서비스 계약을 맺을 때는 서비스 업체의 수행 능력이 떨어지는 경우 계약을 파기하고 나올 길이 필요하다.  계약에서 SLA와 관련해 발생하는 줄다리기는 익숙한 풍경이다. 고객의 법무팀(구매팀과 함께)은 보장되는 9의 개수를 최대화하고자 하고, 서비스 업체의 운영팀은 약속하는 9의 개수를 최대한 줄이고자 한다. 보통 고객은 SLA 미충족분에 대해 요금을 환급받거나 크레딧을 받는 정도로 협상을 한다.  서비스 업체는 고객이 서비스에 온전히 만족하지 않더라도 약속한 9의 개수를 달성하면 약정한 가격을 모두 받는다. 약간 미달하면 고객이 예를 들어 비용의 10%를 환급받고 SLA에 크게 미달할 경우에는 고객은 50%를 돌려받거나 계약을 파기하고 다른 서비스 업체를 찾아 나설 수 있다. 대체로 고객은 서비스 업체가 SLA를 충족하는 편을 선호해왔다.  이런 계약상의 SLA 의무는 서비스 업체 조직 내에서 성능, 안정성, 가동시간 및 응답성 목표로 이어진다. 또한 그 결과로 안정성에 관한 사고 프로세스가 극히 방어적으로 고착되면서, 절대적인 다운타임 방지와 무조건 최대한 빠른 사고 해결에 과도하게 초점을 두는 척도(평균 장애 간격, 평균 해결 시간)가 가장 널리 사용되는 상황에 이르렀다.  SLA로는 ‘어느 지점이 되면 고객이 실제로 만족하고, 따라서 SLA 초과 달성 노력을 멈출 수 있는가?’라는 질문에 답하지 못한다. 즉 SLA로는 사용자의 만족도를 모델링할 수 없다. 클라우드 서비스에는 안성맞춤인 지점이...

2021.09.15