개발된 소프트웨어가 베타 환경에서 무사히 테스트를 마쳤다 할지라도 실제 운영 환경에서는 에러가 발생할 수도 있다. 만약 이럴 경우 기존 개발 환경에서는 운영자가 책임을 져야 했다. 그러나 운영자는 개발자의 개발 과정을 모르기 때문에 에러가 발생하더라도 그 원인을 알지 못했으며, 만약 원인을 파악한다 하더라도 소프트웨어의 문제일 경우 개발자가 해당 문제를 해결해 주기 전까지는 달리 손쓸 방법이 없었다.

데브옵스를 적용하면 개발 과정에서의 노하우 등이 공유되기 때문에 이 같은 문제의 일부분은 해소가 가능하지만, 운영자가 취할 수 있는 행동에는 한계가 존재한다. 그렇기에 개발부터 배포 시까지 전 과정에서 테스트가 진행되며 완성도를 높여야 할 필요성이 있다.

하봉문 한국CA 전무는 “특정한 테스트를 필요로 할 때 전문적인 테스트 엔지니어가 필요했다. 이들은 상용 성능 체크 툴을 갖고 일정 시간 전문적으로 테스트를 한다. 그러나 테스트를 꼭 제품이 나온 이후에만 하는 것이 아니라 소프트웨어 개발 전 과정에서 이뤄져야 한다. 코드마다, 빌드마다, 코드 배포 시 등 각 단계마다 테스트를 수행할 필요가 있다”고 강조했다.

이에 실제로 각 단계별 테스트를 진행할 수 있도록 도와주는 툴들도 등장하고 있다. CA의 SaaS 기반 API 테스트 툴 ‘CA 블레이즈미터 API 테스트’는 개발자가 수많은 형태의 테스트를 자동으로 동시에 생성하고 실행하도록 지원한다. 실제로 기업에서 테스트하기 어려운 환경 등을 간단한 설정을 통해 쉽게 구축할 수 있으며, 원하는 옵션에 맞춰 테스트를 진행할 수 있다. 그렇기에 개발자의 업무 부담을 줄이면서도 비용절감 효과도 얻을 수 있다. 또한 소프트웨어의 지속 배포도 가능하게 한다.

점차 강화되는 자동화 환경

과거 인프라 체제에서는 초기에 소프트웨어를 제작하고 문제가 생기면 수정하는 방식으로 변화관리를 했다. 그런데 변화시킨 것들을 잘 기록해두고 기억하면 다행이지만 시간이 지남에 따라 이를 잊어먹거나 기록이 유실되기도 한다. 특히 소프트웨어 개발 담당자가 퇴사했을 경우 더더욱 이를 관리하는 것은 어려워진다. 다른 개발자가 보더라도 원 개발자가 어떤 의도로 어떤 코드를 활용했는지 알 수 없기에 쉽사리 손을 대지 못 한다.

이 같은 사고를 방지하고자 최근 자동화 환경들이 강화되고 있다. 대표적인 것이 컨테이너 기술로, 한 번 만들어놓은 소프트웨어 이미지를 보존할 수 있다는 장점이 있다. 설정(Configuration)을 변화시킬 수는 있어도 제작된 이미지 자체를 변화시킬 수는 없어 안전하게 소프트웨어를 실행할 수 있다. 장애가 발생해 컨테이너가 정상적으로 동작하지 않는다 하더라도 다른 장비에서 그대로 실행시킬 수 있어 운영자나 개발자의 걱정을 줄여준다.

소프트웨어 업데이트 배포 시에도 자동화는 적용된다. 특정 기능을 적용하기 위해 소프트웨어 업데이트를 할 때 서버의 전원을 내렸다 올리는 방법을 사용하지 않고 실시간으로 일부를 적용시킨 후 문제가 없으면 나머지들도 적용되게끔 치환하는 방식이다. 이 또한 플랫폼에서 자동으로 이뤄지고 있다.

반대의 경우도 마찬가지다. 만약 새로 적용한 기능에 문제가 발생해서 이전 버전으로 롤백을 시킬 때도 한 번에 다 바꾸는 것이 아니라 일부를 먼저 적용한 후 이상이 없다고 확인되면 나머지도 적용하는 방식으로 진행된다. 이를 활용하면 단순히 로직(Logic)을 바꾸는 것만으로도 전체적인 처리 과정도 확인 가능하다.

김현수 한국레드햇 시니어 아키텍트는 “데브옵스 환경을 구현하기 위해 필요한 기능들이 있지만, 기업별로 개발하는 프로세스가 다르고 특정 기업만의 문화도 있을 수 있다. 그렇기에 단순히 특정 제품만 구입하면 다 되는 것이 아니라 기반 기능들을 제공해주는 제품들을 얼마나 기업에 녹여낼 수 있느냐를 고려해야 한다. 특히 표준 기술을 사용하는 제품을 선택하는 것이 추후 확장 또는 교체를 위해서도 유리하다”고 조언했다.

보안 투자 중요성 증가

최근 보안의 중요성이 강조되고 있지만, 국내 기업들의 보안 투자는 상대적으로 미미한 수준이다. 그렇기에 정부가 규제를 강제하는 경우가 많으며, 실제로 국내에서는 공공기관 소프트웨어 개발에 시큐어코딩(Secure Coding)을 강제하기고 있기도 하다. 시큐어코딩은 소프트웨어가 복잡해짐에 따라 보안 취약점이 발생할 수 있는 부분을 보완해 개발하는 것으로, 안전하게 소프트웨어를 개발하기 위한 코딩 규칙과 소스코드 취약 목록 등이 포함돼 있다.

이처럼 안전한 소프트웨어 개발에 대한 니즈가 증가하자 데브옵스에 보안을 결합시킨 데브시크옵스(DevSecOps)가 떠오르고 있다. 이는 소프트웨어 개발 전 과정에 보안을 포함시킨 것으로, 소프트웨어 개발 프로세스에 보안 팀을 합류시켜 함께 업무를 진행하도록 한다.

시장조사기관 가트너는 보고서를 통해 “데브시크옵스의 목표는 민첩성과 협업이라는 데브옵스 특성을 해치지 않으면서 일련의 통합 보안 제어를 추가함으로써 전반적인 개발 관련 보안 수준을 개선하는 것이다. 그러나 단순히 데브옵스 사이클에 표준 보안 툴과 프로세스를 끼워 넣는 것만으로는 구현할 수 없으며 애플리케이션 개발·배포·운영 전 과정에서 보안 검사, 제어, 테스트를 투명하게 자동으로 적용해야 한다”고 기술했다.

보안이 담보되지 않은 소프트웨어는 위험한 결과를 초래할 수 있다. 이를 방지하려면 앞단에서부터 차근차근 정리하며 충분한 테스트를 거치는 과정이 최선이다. 또한 문제가 발생했을 경우 빠르게 업데이트를 가져갈 수 있어야 한다. 이런 것을 극단적으로 추구하고 있는 곳이 아마존으로, 이를 기업의 자산이자 무기로 활용하고 있다.

데브시크옵스 또한 하나의 기업 문화로 정착돼야 하지만, 툴을 활용해 좀 더 쉽고 유용하게 활용 가능하다. CA가 출시한 ‘CA 컨티뉴어스 딜리버리 디렉터 SaaS’는 파이프라인 진행 상황과 성능을 평가하는 기능으로 데브옵스 툴 체인을 통합해 개발 프로젝트의 계획·문제 해결에 대한 가시성을 제공한다. 이를 통해 데브옵스 팀은 출시 계획 및 관리에서 수작업과 부담스러운 프로세스를 없앨 수 있다. 또한 ‘CA 컨티뉴어스 딜리버리 디렉터 SaaS’는 CA 베라코드와의 통합으로 프로세스에 보안을 도입, 개발 파이프라인 전반에 걸쳐 보안 취약점 검사를 실시함으로써 애플리케이션 보안 테스트를 개발 프로세스의 핵심 요소로 구성한다. ‘CA 오토믹 애플리케이션 릴리즈 오토메이션’과 통합으로 보다 신속한 배포 기능을 확장했다.

“데브옵스는 도입 여부 따지기 힘든 ‘여정’”     ▲ 공진기 한국IBM 클라우드 테크니컬 에반젤리스트 국내에서 데브옵스가 잘 안 되는 이유는 문화적인 이유와 사업적인 이유 두 가지로 볼 수 있다. 우선 국내에서는 SI 문화가 강하다. 큰 기업들이 소프트웨어 개발을 직접하는 경우가 드물었으며, 대형 SI 업체에게 사업을 위탁한다. 여기서 대형 SI사들은 프로젝트 관리만 할 뿐 실제 개발은 협력업체에서 하는 경우도 부지기수다. 개발과 운영과 비즈니스 소유가 다 따로 있는 경우가 많기 때문에, 심리스(Seamless)하게 운영돼야 하는 데브옵스가 어렵게만 느껴질 뿐이다. 또한 기업 C레벨들이 데브옵스를 해보려 해도 개발자 부족 현상에 직면하게 된다. 미국에서도 SI가 있긴 하지만, 대부분 자체 개발을 하며 부족한 부분들에 대해 SI에 위탁한다. 그러나 국내에서는 많은 기업들이 내재된 개발 역량이 부족하기 때문에 데브옵스를 제대로 하지 못 하는 경우가 많다. 특히 데브옵스는 단순히 도입했다 아니다의 이분법으로 다가가기 힘든 여정이다. 덜 복잡하게도 확장 가능하며 조금씩 가는 것일 뿐 끝은 없다. 소프트웨어 개발 역량 내재화가 가장 중요하며, 데브옵스를 위한 문화에 익숙해지는 것이 우선이다.

군(軍) 환경에도 적용…어떤 기업도 가능해

큰 기업일수록 경직돼 있기 때문에 디지털 전환이 어렵다는 이야기들을 한다. 그러나 업계 관계자들은 그 어떤 기업도 데브옵스를 활용할 수 있다고 강조한다. 실제로 가장 폐쇄적이고 수직적인 군에서조차 데브옵스를 적용해 활용하고 있다.

미 공군은 전 세계를 전장으로 삼고 있지만, 전투기가 한 번 이륙하면 아무리 아껴서 비행한다 하더라도 비행시간이 오래 가지 못 한다는 문제를 안고 있다. 그렇기에 작전을 진행하고 유지하기 위해서는 급유기를 통해 급유를 받아야만 한다. 하지만 급유기는 한정돼 있으며 급유를 요청하는 전투기들은 많아 어떻게 효율적으로 급유기를 배치해야 할지에 대한 고민이 있었다.

이전까지는 급유기 배치를 수작업으로 계산해 진행했지만, 소프트웨어를 개발해 급유기 플랜을 효율적으로 짜는데 성공했다. 단지 버튼 한 번만 누르면 사람이 하루 종일 해야 했던 일들을 단 4초 만에 처리할 수 있게 됐으며, 새로운 임무가 주어지더라도 어떤 영향이 발생할지 확인 가능해져 비용효율성이 높아졌다. 그 결과 전투기에 투입되는 연료를 하루 100만 갤런을 절감할 수 있었다.

흥미로운 사실은 미 공군의 급유기 플랜 소프트웨어가 자체적으로 개발됐다는 점이다. 비록 소프트웨어 개발 역량이 부족했지만 데브옵스를 활용해 작은 기능부터 개발을 시작했으며, 그 결과 점차 놀라운 결과물을 개발할 수 있게 됐다는 후문이다.

기존 프로세스에 얽매이지 않는 조직 구성이 우선

비록 그 어떤 기업도 데브옵스를 활용할 수 있지만, 그렇다고 아무런 계획 없이 데브옵스를 추진해서는 좋은 결과를 얻기 어렵다. 특히 데브옵스는 그 기업의 개발 프로세스와 문화를 바꾸는 것이 궁극적인 목표이기에, 이를 실현하려면 상당 기간이 걸린다는 점도 감안할 필요가 있다.

업계 전문가들에 의하면 데브옵스 적용을 위해 우선적으로 필요한 것이 ‘기존 프로세스에서 적용되지 않는 팀’을 구축하는 것이다. 그 조직은 크지 않아도 된다. 제프 베조스 아마존 CEO는 ‘피자 2판을 먹을 수 있는 정도의 인원’이 적당하다는 견해를 밝히기도 했다. 대신 이들 팀을 지원할 높은 수준의 의사결정자가 필요하다.

두 번째로는 해야 할 일이 무엇인지 명확히 하는 것이다. 소프트웨어를 어떻게 개발하고 또 배포하고 있는지, 어떤 도구들을 사용하고 있는지 등을 먼저 살펴야 하며, 이를 토대로 무엇을 해야 할지를 확고히 해야 한다.

다음으로는 참고할만한 베스트 프랙티스(Best Practice)를 찾아보는 것이다. 비록 국내 사례가 아닐지언정 해당 기업이 속한 사업 또는 산업 분야에 있을 가능성은 충분하다. 지멘스와 같은 글로벌 성공사례에 집중해서 필요한 부분을 녹여내는 것도 좋은 방안이다.

이어 만들어야 하는 것들을 어떤 방향(milestone)으로 언제까지 배포해야 하는지를 고려해야 한다. SI 생태계 때문에 그룹사의 경우 최대 3년을 예상하는 경우가 있으며, 많은 기업들에서 특정 프로젝트에 대해 연 단위 이상 기간을 요청한다. 그러나 빠른 개발과 배포를 위해서는 그 기간을 단축시킬 필요가 있다.

끝으로 기업에서 영위하는 핵심 사업 역량과 소프트웨어의 관계에 대한 ROI를 고려할 필요가 있다. 디지털 전환 사례의 대명사격인 GE는 자사가 제조한 제트엔진이 1%의 연료를 절감할 수 있다면, 전 세계에서 날아다니는 수만 대의 비행기 비용이 얼마나 절감될 수 있는지를 생각했다. 그리고 비용절감을 위해 과연 소프트웨어가 필요한지를 고려했다. 결국은 사업성 이야기로, 사업을 소프트웨어로 할 수 있는지의 검토가 끝나면 시작하면 된다. 만약 스스로 할 수 없을 경우 적절한 파트너를 찾는 편도 도움이 된다.

비록 사업적으로 소프트웨어가 효과가 있다 하더라도 C레벨을 설득하지 못하는 경우도 발생한다. 이 때 내부적으로 팀을 구성해 실험해볼 수 있다. 조금 해보고 안 됐다고 포기할 필요는 없으며 눈으로 보여줄 수 있는 전략을 세우는 것이 중요하다.