최근 데브옵스 분야에서 눈에 띄는 것은 자동화 환경들이 강화되고 있다는 점이다. 대표적인 것이 컨테이너 기술로, 한 번 만들어놓은 소프트웨어 이미지를 보존할 수 있다는 장점이 있다. 설정(Configuration)을 변화시킬 수는 있어도 제작된 이미지 자체를 변화시킬 수는 없어 안전하게 소프트웨어를 실행할 수 있다. 장애가 발생해 해당 서버에서 정상적으로 동작하지 않는다 하더라도 다른 장비에서 그대로 실행시킬 수 있어 운영자나 개발자의 걱정을 줄여준다.
소프트웨어 업데이트 배포 시에도 자동화는 적용된다. 특정 기능을 적용하기 위해 소프트웨어 업데이트를 할 때 서버의 전원을 내렸다 올리는 방법을 사용하지 않고 실시간으로 일부를 적용시킨 후 문제가 없으면 나머지들도 적용되게끔 치환하는 방식이다. 이 또한 플랫폼에서 자동으로 이뤄지고 있다.
반대의 경우도 마찬가지다. 만약 새로 적용한 기능에 문제가 발생해서 이전 버전으로 롤백을 시킬 때도 한 번에 다 바꾸는 것이 아니라 일부를 먼저 적용한 후 이상이 없다고 확인되면 나머지도 적용하는 방식으로 진행된다. 이를 활용하면 단순히 로직(Logic)을 바꾸는 것만으로도 전체적인 처리 과정도 확인 가능하다.
그러나 데브옵스 환경을 구현하기 위해 필요한 기능들이 있지만, 기업별로 개발하는 프로세스가 다르고 특정 기업만의 문화도 있을 수 있다. 그렇기에 단순히 특정 제품만 구입하면 다 되는 것이 아니라 기반 기능들을 제공해주는 제품들을 얼마나 기업에 녹여낼 수 있느냐를 고려해야 한다. 특히 표준 기술을 사용하는 제품을 선택하는 것이 추후 확장 또는 교체를 위해서도 유리하다는 것이 업계 관계자들의 전언이다.
▲ 오픈소프트랩 '루나 옵스'
데브옵스, 느리더라도 꾸준히 가야
업계에서는 국내에서 데브옵스 문화를 한 번에 받아들이기 힘들다고 평가한다. 아무리 자동화 툴이 좋다 하더라도 이들은 데브옵스를 거들어주는 도구에 불과하기 때문이다. 무엇보다 첫 도입 시 전사에 적용하기보다는 특정 대상이나 프로젝트에 시범적으로 관심이 있는 인력들을 뽑고, 그들을 기준으로 선행 사례를 만들어 볼 것을 조언한다.
물론 처음 시도하면 거의 100% 실패한다고 볼 수 있다.
대신 정해진 기간을 짧게 끊어서 점진 반복적으로 최소한의 기능을 개발해서 보여주고, 사용자 피드백을 받고, 운영하는 애자일 방법론을 학습한다는데 의의를 두면 된다. 피드백을 통해 좋았던 부분과 안 좋았던 부분들을 점검하고, 다음 프로젝트에서는 이를 개선해 적용하면서 스스로 적응력과 품질을 높여나가면 된다.
이를 통해 내부 경험이 쌓이면, 해당 경험을 쌓은 조직원들이 다음 프로젝트에 퍼져서 점진적으로 문화를 퍼트려나가는 방식이 필요하다. 그렇다고 무조건 개선에 대한 압박감을 가질 필요는 없다. 조직 구성원들이 거부감 없이 받아들이도록 하는 것이 중요하다.
