DevOps 텍스트 교육

조직에서 DevOps를 어떻게 시작해야 하나요?

조직에서 DevOps를 어떻게 시작하느냐에 따라 도입이 얼마나 성공할지 결정됩니다. 처음이자 어쩌면 유일한 기회를 최대한 활용하세요.

대규모 일괄 전환을 피하고 작게 시작하기

이미 알고 있듯이 첫날부터 현 상태를 한꺼번에 바꾸고 조직 전체의 DevOps 전환을 선언하기는 어렵습니다. 먼저 계속해서 문제와 미달성 목표에 대처하는 팀을 찾습니다. 개선의 필요성을 분명히 알고 다른 업무 방식을 가장 잘 받아들일 팀입니다. 조직과 고객을 위해 기꺼이 일할 의지도 있어야 합니다.

빠른 초기 성과 보여 주기

DevOps 도입으로 얻은 빠른 초기 성과를 보여 주고, 회의적이거나 반대하는 사람에게 어떤 문제를 해결하고 어떤 가치를 만드는지 입증하는 것이 사명입니다. 이후 개선을 조직의 다른 분야에 차례로 적용합니다.

독일의 한 선도적인 ERP, CRM 및 SaaS 제조업체가 대체로 이렇게 DevOps를 시작했습니다. 유지보수 팀은 1년에 한 번만 제공했으며, 여러 인시던트 코드 브랜치에 릴리스되지 않은 코드가 빠르게 쌓였습니다. 코드를 병합하고 충분히 테스트된 안정적인 유지보수 릴리스를 내놓기가 매우 어려웠습니다.

먼저 유지보수 개발팀을 유지보수 제공 계획, 품질 보증 및 운영 환경 관리 팀과 합쳤습니다. 조율과 의사소통을 간소화하려고 공통 작업 및 티켓 관리 시스템도 쓰기 시작했습니다. 이후 월간 릴리스를 시작했고, 얼마 지나지 않아 2주마다 릴리스했습니다.

새 방식을 도입한 첫해에 유지보수 팀이 해결한 인시던트는 전년의 6배였습니다. 그에 못지않게 중요한 점은 다시 열린 인시던트와 관련 재작업의 비율이 39%에서 4%로 줄었다는 것입니다.

상당한 개선과 이를 입증하는 지표를 확보하자, 소규모 DevOps 도입이 조직의 큰 지지와 신뢰를 얻었습니다. 다른 제품 및 서비스 팀으로 확장할 수 있도록 경영진의 후원도 받았습니다.

적합한 그린필드 또는 브라운필드 제품과 서비스 찾기

DevOps를 처음 도입할 때는 그린필드 제품 및 서비스를 선택할지, 브라운필드 제품 및 서비스를 선택할지도 고려해야 합니다.

그린필드 제품 및 서비스는 조직에 처음 도입하는 것입니다. 특히 시작할 때는 독립적으로 일하는 새로운 별도 팀을 구성하는 편이 유리합니다. 팀원은 기존 관행을 깨고 고정관념에서 벗어날 가능성이 커지고, 조직 내 이전 책임 때문에 방해받는 일도 줄어들 수 있습니다. 새 팀에 매출 향상, 고객 참여도 개선, 제공 시간 단축처럼 구체적인 IT 및 비즈니스 성과 지표와 결과를 맡깁니다. 레거시 코드나 종속성에 의존하지 않으므로 성공적인 DevOps 추진을 시작하는 위험은 더 적습니다. 다만 그린필드 도입은 DevOps가 조직의 기존 문제를 해결할 수 있는지, 성공을 다른 분야에도 재현할 수 있는지 입증하지 못하므로 조직에 미치는 영향은 작습니다.

브라운필드 제품과 서비스로도 DevOps를 시작할 수 있습니다. 이런 제품과 서비스 상당수는 이미 프로덕션에서 작동하며 비즈니스와 고객에 기여합니다. 저희와 같은 세상에 계시다면 브라운필드 애플리케이션에는 상당한 기술 부채가 있고 믿을 만한 테스트 자동화가 많지 않을 것입니다. 따라서 도입이 더 어려울 수 있지만, 긍정적 성과를 내면 보람과 설득력이 더 크고 조직에 더 큰 영향을 줄 수 있습니다.

운영 중인 레거시 시스템이 많은 대규모 조직도 DevOps를 활용할 수 있습니다

많은 사람이 DevOps가 브라운필드 제품과 서비스에는 맞지 않는다고 생각합니다. 심지어 스타트업에만 해당한다고 생각합니다. 하지만 가장 모범적인 도입 사례 중 일부는 수많은 핵심 레거시 시스템과 수천 명의 직원을 둔 크고 성숙한 IT 조직에서 시작되었습니다. Amazon, Easy, Facebook이 그 예입니다. 앞의 SaaS 업체 사례처럼 기존 조직과 브라운필드 제품 및 서비스에서도 시작할 수 있습니다. 실제로 대다수 브라운필드 제품과 서비스에는 성과와 고객 기대 사이에 큰 격차가 있어 DevOps 전환의 혜택을 얻기에 가장 적합한 경우가 많습니다. 브라운필드 도입을 시작할 때는 먼저 기술 부채를 없애거나 줄이는 데 시간을 들이고, 기존 제품의 기능과 혜택을 검증할 자동화된 테스트를 보완하세요. 그렇지 않으면 브라운필드 제품 및 서비스에서는 짧은 주기로 안정적인 프로덕션 배포를 할 수 없습니다.

적합한 기록 시스템 또는 고객 참여 시스템 찾기

첫 DevOps 도입에서 기록 시스템과 고객 참여 시스템 중 하나를 자유롭게 선택할 수 있습니다. 기록 시스템은 조직에서 단일 진실 공급원을 관리하는 중앙 집중형 시스템입니다. 고객, 거래, 보안 및 개인정보를 포함한 데이터 관리에 중점을 둡니다. 고객 참여 시스템은 대개 분산형 애플리케이션으로, 고객과 사용자가 옴니채널 반응형 포털이나 모바일, 태블릿 및 데스크톱 애플리케이션을 통해 조직과 상호작용하도록 지원하고 장려합니다.

기록 시스템을 선택하면 DevOps 팀이 규정 준수, 보안, 개인정보 보호 등 시간과 절차가 많이 필요한 일을 얼마나 능숙하게 처리하는지 보여 줄 수 있습니다. 팀은 제품과 서비스의 개발 및 운영 수명 주기 전체에 걸쳐 테스트 자동화와 텔레메트리를 사용하여 과학적이고 구체적인 증거를 확보합니다. 대표적인 예는 여러 지역에 분산된 데이터를 온프레미스 데이터베이스에서 클라우드로 이전하면서도 단일 진실 공급원이 법률, 업계, 지역 및 국제 규칙과 규정을 계속 준수하도록 하는 마이그레이션입니다.

고객 참여 시스템을 선택하면 빠른 제공 주기로 얼마나 신속하고 안정적으로 혁신하는지 보여 줄 수 있습니다. 오늘날 상업적 성공을 가져온 눈에 띄는 혁신의 대부분이 고객 참여 시스템에서 시작되기 때문입니다. 예를 들어 전자상거래 포털의 결제 흐름을 더 직관적이고 간결하게 만들어 매출을 25% 늘릴 수 있습니다. 이를 달성하는 순간 경영진은 DevOps와 여러분을 모두 높이 평가할 것입니다.

성공적인 DevOps 전환 방법

처음에는 보수적인 팀을 설득하는 데 시간을 낭비하지 마세요. DevOps 방법론과 원칙이 필요하다고 믿는 팀 가운데 가장 혁신적이고 개방적이며 인적 네트워크가 넓고 영향력 있는 팀을 찾으세요. 한두 팀에서 작게 시작합니다. 위의 방법을 이용해 출발점으로 삼기에 가장 적합한 그린필드 또는 브라운필드 제품 및 서비스, 기록 시스템 또는 고객 참여 시스템을 고릅니다.

첫 성공 사례가 나오면 참여한 팀은 조직 전체에 DevOps를 확산하는 가장 든든한 지지자가 됩니다. 이어서 다른 그룹과도 협력해 성공 사례를 늘립니다. 성공이 쌓일수록 DevOps 도입에 대한 평판과 신뢰가 높아집니다. 측정할 수 있는 이점이 드러나면 경영진의 지원, 후원 및 관심도 커집니다.

마지막 단계에서는 영향력 있는 방해자와 강한 반대자(Curmudgeons)를 파악합니다. 그들이 쓰는 기법, 즉 위험과 두려움을 퍼뜨리는 방식으로 대응할 수도 있습니다. DevOps를 배우고 사용하기를 거부한다면 그들의 팀과 제품이 얼마나 뒤처져 보이고 조직의 가장 취약한 고리가 될지 설명합니다.

결론

조직의 IT 전환을 추진하기는 쉽지 않습니다. DevOps도 예외는 아닙니다. 하지만 작게 시작하면 위험이 크지 않습니다. 신임 리더든 숙련된 리더든 가장 중요한 책임 중 하나는 더 나은 비즈니스 성과를 위해 팀에 동기를 주고 행동하도록 이끄는 것입니다. 직업적 만족을 극대화하기 위해 신중하게 판단한 위험을 감수하는 것도 잊지 마세요.