[데이터넷] 애플리케이션을 빠르게 개발하고 시장 수요에 민첩하게 대응할 수 있는 데브옵스 방식의 개발을 위해 다양한 데브옵스 도구가 사용되면서, 기업에서는 최적의 데브옵스 도구 도입뿐만 아니라 이 도구들을 표준화하고 통합 관리하는 것에 대한 중요도가 커지고 있는 상황이다. 또 수많은 데브옵스 도구를 선택하고 연결해서 데브옵스 환경을 구현하려면 복잡성이 가중돼 개발 생산성이 저하되고 시간과 비용의 중복투자도 발생하는 것이 현실이다. 이 때문에 기업에서는 여러 종류의 도구를 사용하기 보다는 여러 기능을 포함하는 단일 플랫폼을 도입해서 사용하는 것을 선호하고 있다. <편집자>

현대화된 애플리케이션을 개발하려면 과거의 접근 방식과는 다른 프로세스가 필요하다. 소프트웨어 개발에 애자일 접근 방식을 적용하는 많은 팀들이 가장 먼저 고려하는 사항이 바로 데브옵스(DevOps)다. 실제로 ‘신속하고 지속적인 소프트웨어 제공을 통한 고객 만족’은 애자일 선언문(Agile Manifesto)의 12가지 원칙 중 첫 번째 원칙이다. 이는 지속적인 통합 및 연속 배포(CI/CD)가 데브옵스 팀에 매우 중요한 이유다.

그러나 개발 및 운영 프로세스를 변경하는 것만으로는 충분하지 않다. 소프트웨어 제공 방식을 실질적으로 최적화할 수 있도록 고안된 시스템을 적용해야 한다. 이는 데브옵스가 개발 작업을 요청하는 사업부와 최종 사용자를 지원하는 그룹에 변화를 가져온다는 의미다. 무엇보다도 최종 사용자가 비즈니스에 지속적으로 피드백을 제공하는 것이 중요하다.

현재 작업 수행 방식을 넘어서는 프로세스 변경이 필요함에 따라 수행하는 작업도 변경될 수밖에 없다. 데브옵스는 기존의 동일한 모놀리식 소프트웨어의 개발을 가속화하는 것뿐만 아니라 이러한 지속적인 개발 흐름에 더욱 적합한 새로운 종류의 소프트웨어를 개발하는 것과 관련이 있다.

이런 이유로 데브옵스 팀이 마이크로서비스 아키텍처(MSA)를 사용해 소프트웨어를 구축하고 API로 이러한 서비스를 함께 연결하는 경우가 많다. 데브옵스 팀이 각각의 기능을 더 작은 단위로 구축함으로써 서비스를 보다 신속하게 제공 가능하므로, 이러한 서비스와 API가 관리되는 방식에 중점을 두고 이 모두를 통합할 수 있는 애자일 통합과 같은 전략을 수립해야 한다.

이러한 변화는 많은 노력을 필요로 하지만 적절한 기술을 사용한다면 지금 바로 시작할 수 있다. 자동화를 활용한다면 프로세스를 가속화할 수 있으며, 최종적으로는 데브옵스 워크로드를 클라우드로 마이그레이션할 수 있다.

빠른 서비스 배포에 중점
데브옵스에서 가장 중요한 부분은 빠른 서비스 배포다. 이를 위해서 빠른 개발 및 배포 프로세스를 만드는 것도 중요하지만, 테스트 절차를 효율화하는 것이 무엇보다 중요하다. 개발 프로젝트에서 많은 경우 개발에 소요되는 시간보다는 각종 케이스를 테스트하는데 더 많은 시간이 소요되고, 이런 문제를 해결하기 위해 실제 데브옵스를 도입하는 기업에서는 테스트 자동화를 추진하고 있고 있을 정도로 필수 요소라고 할 수 있다.

기존의 전통적인 IT 개발, 운영 방식은 레거시 코드가 테스트 자동화를 적용하기에 쉽지 않은 구조와 각기 다른 개발, 운영 프로세스 방식으로 인해 비즈니스 로직 구성이 서로 상이하게 구현돼 있다. 1~2년이 아닌 5년 이상의 누적된 구조에 전혀 개선되지 않은 코드가 대부분이다.

변화하는 고객의 니즈를 반영하기 위해서는 데브옵스 개발 방식이 필요한데, 이는 초점이 벤더/개발사 중심에서 고객으로 이동한 것이라 볼 수 있다. 예전 프로젝트의 경우 ‘차세대’라는 명목으로 대규모 프로젝트가 진행되는 경우가 있었는데, 점점 규모를 쪼개는 ‘작은 변화’를 통해 위험성을 줄이는 변화가 일어나고 있다. 즉 하나의 대고객 서비스를 운영하는 것이 아니라, 개발과 운영을 나눠 자유도를 높이면서 동시에 서로에 대한 영향도를 낮춰가고 있는 것이 특징이다.

데브옵스 모델에서는 개발 팀과 운영 팀이 더 이상 사일로(silo)에 묶여 있지 않는다. 전통적인 개발 방식이 개발 프로세스 간 수동적인 이관 작업으로 연결된다면, 데브옵스는 모든 프로세스가 워크플로우를 따라 자동으로 진행된다.

데브옵스 방식을 사용해 속도가 느리고 수동으로 수행되던 프로세스를 자동화한다. 또 애플리케이션을 안정적으로 빠르게 운영하고, 개선하는데 도움이 되는 기술 스택, 파이프라인(CI/CD)과 도구(예: Eclipse, JUnit, 4force, Nexus)를 사용한다. 이러한 도구 덕분에 엔지니어는 이전 같았으면 다른 팀의 도움이 필요했을 코드 배포 또는 인프라 프로비저닝과 같이 작업을 독립적으로 수행할 수 있으며, 따라서 팀의 작업 속도가 더욱 빨라진다. 기본 방식 중 소규모 업데이트(버그 패치 등)를 자주 수행하는 것이다. 따라서 조직은 고객을 위해 더 빠르게 개선점을 적용할 수 있다.

이러한 업데이트는 기존 릴리스 방식에서 수행되는 낮은 빈도의 업데이트보다 더 빠른 개선과 진보적인 특성을 갖는다. 소규모로 자주 업데이트하면 각 배포의 위험이 줄어든다. 작은 단위의 배포는 오류의 원인이 되는 최근 배포를 확인할 수 있으므로 더 빠르게 버그를 해결할 수 있으며, 이러한 특성은 데브옵스 모델이 MSA 특성을 갖는 이유가 된다. 업데이트 소요 시간과 규모는 다르지만, 데브옵스 모델을 사용하는 조직은 기존 소프트웨어 개발 방식을 사용하는 조직보다 훨씬 더 자주 업데이트를 배포하며, 조직은 MSA를 사용해 애플리케이션의 유연성과 혁신의 속도를 높일 수 있다.

MSA는 복잡한 대규모 시스템을 간단하고 독립적인 프로젝트로 결합 또는 해제한다. 애플리케이션은 많은 개별 구성 요소(서비스)로 분할되며, 각 서비스는 단일 목적 또는 기능으로 한정되고 서비스 대상 및 전체 애플리케이션과는 별개로 운영된다.

뿐만 아니라 MSA는 애플리케이션 업데이트를 위한 조정 오버헤드를 줄이며, 각 서비스가 이를 담당하는 작고 민첩한 팀과 연결되면 조직이 좀 더 신속하게 움직일 수 있다. 하지만 마이크로서비스와 배포 빈도 증가의 조합은 배포 수를 현저히 늘려 운영 문제로 이어질 수 있다. 따라서 CI/CD와 같은 데브옵스 방식을 사용하면, 이러한 문제를 해결하고, 조직이 안전하고, 안정적인 방식으로 신속하게 업데이트를 제공할 수 있다.

비즈니스 연속성 확보 목적
한국IDC가 공개한 ‘국내 데브옵스 도입을 통한 비즈니스 성과 창출 보고서’에 따르면 펜데믹으로 인해 신속한 디지털 혁신이 기업의 중대 사안으로 대두되면서 비즈니스 민첩성이 그 어느 때보다 중요해지고 있으며, 기업 IT는 개발, 배포, 운영으로 이어지는 비즈니스 애플리케이션과 관련된 일련의 과정과 주기를 유연하게 연결해 비즈니스 서비스 출시를 신속하게 하기 위한 방안으로 애자일과 데브옵스 방법론을 채택하고 있는 것으로 나타났다.

데브옵스 구현을 지원하는 소스 관리, 저장, 통합, 배포 등 소프트웨어 툴이 계속 출시되면서 데브옵스는 전반적인 기술 및 인식 측면에서의 성숙도를 높여가고 있다. 최근에는 개발자 생산성 개선을 통한 비즈니스 민첩성 향상뿐만 아니라 비즈니스 서비스 배포 품질 관리와 이를 통한 비즈니스 혁신으로 데브옵스 도입의 목적도 변하고 있다.

한국IDC는 국내 시장의 데브옵스 도입 동인으로 ▲서비스 배포 주기 단축 ▲애플리케이션 현대화 ▲비즈니스 가치 창출 시간 단축 등 세 가지를 제시했다.

급변하는 소비자 요구사항에 대응해야 하는 B2C뿐 아니라 B2B 산업에서도 D2C(Direct to Customer) 확대와 디지털 네이티브 기업 등장으로 인한 경쟁 심화로 서비스의 빠른 배포 및 출시가 필수적인 상황이다.

이를 위해 신속한 개발 및 배포 프로세스 그리고 배포된 서비스에서 발생하는 오류의 신속한 해결이 가능해야 한다. 여기에 효과적인 방안으로 대두되는 것이 MSA로의 소프트웨어 아키텍처 변화 그리고 데브옵스 체계 구축이다.

데브옵스는 기술을 넘어서 기업 문화 및 프로세스 체계 확립이라는 관점에서 비즈니스의 민첩성과 확장성을 궁극적인 목표로 하는 클라우드 기반 MSA 효용 가치를 높이는 데 선제 요건이 되면서 그 중요성이 한층 강조되고 있는 추세다. 그러나 기존 애플리케이션의 방대한 포트폴리오, 기술적 복잡성과 함께 경영진의 지원과 다양한 부서 간 협업과 같은 문화적 요소들은 여전히 데브옵스 도입을 위해 기업이 해결해야 할 문제로 지적된다.

IDC는 향후 데브옵스 시장이 데브섹옵스(DevSecOps), 가치흐름관리(VSM) 그리고 파이프라인 자동화를 중심으로 성장해 나갈 것으로 전망했다. 애플리케이션 자산 전체에 데브옵스의 확장은 쉽지 않겠지만, 부분적으로라도 데브옵스를 도입한 기업들을 중심으로 확장에 앞서 데브옵스 파이프라인을 지속적으로 최적화하는 데 주안점을 두면서 VSM 솔루션 수요가 증가할 것으로 보인다는 설명이다.

또 클라우드 기반 동적으로 변하는 애플리케이션 수의 증가, 비즈니스 환경에 따라 계속해서 변화하는 보안 규정 등으로 인해 보안은 이제 운영 단계뿐만 아니라 개발과 운영 전 과정에 걸쳐 계속 업데이트하면서 관리해야 하는 부문으로 확장되고 있기 때문에 데브옵스 전 과정에 걸쳐 보안의 중요성이 증가하면서 CD 파이프라인에 빠르게 통합돼 데브섹옵스가 기업 데브옵스의 향후 구현 방향으로 대두될 것이라고 내다봤다.

단순 도구에서 플랫폼으로 진화
사람들이 성장 단계를 거치는 것과 마찬가지로, 시장과 산업 또한 발전 단계를 거치게 된다. 지난 수년 동안 데브옵스는 성숙한 비즈니스의 중요 성공사례로 성장해 왔다. 아울러 프로젝트 도구 통합이 증가함에 따라 기업들은 데브옵스 도구 채택 방식을 변경해야 했다. 깃랩은 그동안 데브옵스 도구 채택 방식이 4단계로 진화해 왔다고 설명한다.

• 1단계 - 사일로 데브옵스
  초기에 해당하는 이 단계는 각 부서 또는 팀이 다른 팀들과 명시적 조정 작업을 수행하지 않고 자체적으로 한정된 목표에 맞게 최적화된 도구를 빌드하거나 구매했다. 그로 인해 다른 팀의 도구에 익숙하지 않아 팀 간의 협업을 방해하는 ‘사일로 데브옵스’ 환경이 조성되었다. 이러한 혼란스러운 환경은 협업과 지식 공유를 저해하거나 완전히 중단시킨다.

• 2단계 - 파편화된 데브옵스
  기업들은 혼란을 줄이고 보다 조화로운 환경을 조성하기 위해 두 번째 단계인 파편화된 데브옵스(Fragmented DevOps)로 진화했다. 이 단계에서 기업들은 조직 전반에 걸쳐 동일한 도구 세트로 표준화했지만, 각 데브옵스 라이프사이클 단계별로 하나의 도구를 사용했다. 동일한 기능을 사용함으로써 팀 간 협업은 개선됐지만, 단계별로 도구가 연결돼 있지 않기 때문에 전체 데브옵스 라이프사이클을 따라 이동하기가 어려웠다.

• 3단계 - DIY 데브옵스
  기업들은 사일로 단계를 해결하기 위해 데브옵스 포인트 솔루션을 수동으로 통합하는 세 번째 단계인 ‘DIY 데브옵스’에 도달했다. 하지만 불행하게도 이러한 자체 제작 도구 체인은 복잡한 워크플로우를 유발해 개발 프로세스와 전체 주기 속도를 지연시켰다. 많은 기업들은 DIY 데브옵스 툴 체인을 유지관리하기 위해 상당한 노력과 비용 부담을 감당해야 했으며, 주기가 지연되고, 표적 취약성에 노출될 가능성도 높아졌다.

• 4단계 - 데브옵스 플랫폼 시대
  데브옵스의 진정한 잠재력은 네 번째 단계인 데브옵스 플랫폼 시대에 도달하면서 완전히 실현될 수 있게 되었다. 데브섹옵스 플랫폼은 하나의 사용자 인터페이스와 통합 데이터 저장소가 있는 단일 애플리케이션이다. 모든 데브옵스 라이프사이클 단계를 포함하며, 개발 및 운영, 보안 팀이 공동으로 협업하여 소프트웨어를 계획, 빌드, 보호 및 배포할 수 있도록 해준다. 그 결과, 기업들은 보다 빠르고 낮은 비용으로 소프트웨어를 제공할 수 있다.

데브섹옵스 중요성 커져
깃랩이 전 세계 5000여명의 개발자와 운영·보안 실무자, 조직 리더를 대상으로 조사한 ‘2022년 글로벌 데브섹옵스’ 조사에 따르면, 응답자의 75%가 데브옵스 플랫폼을 채택했거나 연내 채택할 계획이며, 보안을 최우선 투자 영역으로 간주해 보안 팀 절반 이상이 시프트 레프트(Shift Left) 보안으로 전환했거나 올해 안에 전환할 계획으로 나타났다. 시프트 레프트는 개발 초기부터 보안을 적용하는 방법론을 말한다.

보안은 글로벌 기업들의 데브옵스 팀 전반에 걸쳐 가장 중요한 투자 영역으로 부상하면서 클라우드 컴퓨팅을 능가했다. 그러나 시프트 레프트 보안으로 전환하려는 요구는 많지만 기업들의 접근 방식과 결과는 아직 초기 단계에 머물러 있으며, 응답자의 10%만이 보안을 위한 추가 예산을 지원받고 있다고 답했다.

또 보안 팀과 개발 팀 간의 부조화 경향은 계속되고 있는 것으로 나타났다. 조사 응답자의 절반 이상이 보안이 조직 내 개발자에 대한 성능 지표라고 답했지만, 보안 전문가의 50%는 개발자들이 보안 문제를 식별하지 못하고 있으며, 이는 취약성의 75%에 해당한다고 응답했다. 이러한 성능 지표를 현실화하기 위해서는 개발자가 보안 프로토콜을 실행해야 하며, 툴 체인과 잠재적 위험에 대한 완벽한 가시성을 제공해야 한다.

보안 협업이 이뤄지면 기업은 상당한 성과를 거둘 수 있다. 개발, 보안 및 운영 팀 모두 전반적으로 데브옵스 플랫폼의 주요 이점으로 보안 개선을 언급했다. 조사 데이터에 따르면, 많은 의사결정권자들이 데브옵스 플랫폼이나 기타 툴을 선택하는 핵심 원동력은 보안 과제인 것으로 나타났다. 한편 단일 플랫폼에 투자함으로써 실무자들은 더 적은 수의 툴로 더 많은 기능을 활용할 수 있으며, 개별 툴 대비 비용을 절감할 수 있다.

특히 이번 조사에서는 보안 및 컴플라이언스가 지속적으로 우선순위를 차지하고 있으며, 툴 체인 통합에 대한 투자와 데브옵스 채택 가속화에 따른 영향이 지속되고 있다는 사실이 드러났다.

보안 기능 통합할 도구 고려해야
데브옵스는 단순히 개발 및 운영 팀에 관한 것만이 아니다. 데브옵스 접근 방식을 최대한 활용하기 위해서는 보안이 애플리케이션의 라이프사이클에서 어떤 역할을 하는지 고려해야 한다. 다시 말해 계획 단계에서부터 핵심 보안에 대해 생각해야 한다. 이는 데브옵스 워크플로우의 속도가 저하되지 않도록 일부 보안 기능을 자동화해야 한다는 의미이기도 하다. 보안 기능을 통합할 수 있는 올바른 툴을 선택하면 데브옵스 보안 목표 달성을 지원할 수 있다.

보안 팀의 작업을 통합하기 위해서는 데브옵스의 문화적 변화를 기반으로 데브옵스 보안을 구축해야 한다. 데브옵스는 개발과 운영 간의 격차를 해소해 프로세스를 가속화하고 있지만, 비효율적인 보안 계획으로 인해 프로세스 가속화로 인한 이점을 누리지 못할 수 있다.

레드햇이 시장조사기관 IDC와 함께 조사해 발간한 데브섹옵스 연구 보고서에 의하면 데브섹옵스 작업을 클라우드로 전환할 때 가장 중요한 4가지 고려 사항으로 데이터 보안, 클라우드 보안 관리, 공급망 보안 위험, 퍼블릭 클라우드 자산 보호 등이 꼽혔다.

데브섹옵스 사례를 애플리케이션 개발 라이프 사이클에 도입해 통합하면 IT 및 보안 팀은 구성원, 프로세스, 기술 전반에서 발생하는 보안 문제를 보다 이른 시점에 해결할 수 있다. 이를 통해 보안은 개발 라이프사이클 전반에서 지속적이고 포괄적인 설계 요소로 구현 가능하다. 또 애자일 업무 방식을 통해 속도 및 효율성, 보안 및 컴플라이언스, 일관성, 반복가능성, 협업이 증진되고 인적 오류도 감소한다.

한편 소프트웨어 공급망은 최신 소프트웨어 개발에 사용되는 내부 및 외부 의존성 모두에 해당된다. 기업들은 이러한 공급망을 올바르게 보호하기 위해 사내에서 생성된 코드를 보호하는 것은 물론, 타사 구성 요소로 인해 도입될 수 있는 취약성까지 탐지할 수 있는 도구를 배치해야 한다.

하지만 변경되는 부분들이 너무 많기 때문에 조직의 소프트웨어 공급망 보호는 상당히 복잡할 수 있다. 따라서 코드가 효율적으로 안전하게 배포되도록 개발 라이프사이클 전반에 걸쳐 자동화된 견제 및 균형 시스템이 필요하다. 이같이 데브섹옵스 플랫폼을 구현하면 소유권 및 액세스에 대한 투명성을 개선하고, 핸드오프를 줄임으로써 종단 간 보안을 부분적으로 개선할 수 있다.