[테크월드=이혜진 기자] 데브옵스(DevOps)는 개발(Development)과 운영(Operations)의 합성어다. 쉽게 말해 시스템 개발과 운영을 병행하고 협업하는 방식을 뜻한다. 이처럼 개발과 운영의 경계가 무너지는 '데브옵스(Dev Ops)'로 기업들은 업무상 수고를 덜고 빠른 서비스를 얻을 수 있다. 다음 글을 통해 데브옵스와 데브섹옵스의 개념, 효과 등에 대해 자세히 알아보자.
데브옵스는 소프트웨어 개발 조직과 운영 조직의 상호 의존적인 대응을 목표로 한다. 이를 통해조직은 소프트웨어 제품과 서비스를 빠른 시간에 개발하고 배포할 수 있다.
데브옵스에서는 지속적인 전송(CD)과 지속적인 통합(CI)을 달성할 수 있다. 전체 프로세스 주기가 자동화되기 때문이다.
데브옵스 방식에서 기업의 테스트팀과 보안팀은 모든 프로세스에 참여한다. 동시에 린 생산 방식(Lean Process, 인력과 부품의 적시공급을 통해 재고를 줄이고 품질을 끌어올리는 도요타의 생산 시스템)에 따라 그 과정에서 가치를 주지 못하는 것은 전체 프로세스에서 제거한다.
이를 통해 기업은 타임 투 마켓(Time to market, 신제품을 출시하는 속도)을 줄여 더 높은 생산성(Productivity)과 가치(Value), 개선(Improvement)을 이끌어 낼 수 있다. 즉, 데브옵스의 가치는 타임 투 마켓을 줄여 빠르게 확장할 수 있는 가치를 제공하는데 있다. 데브옵스의 가치를 구성하는 요소는 사람(People), 기술(Technology), 프로세스(Process), 방법론(Methodology), 공통된 주인 의식(Ownership) 등이다.
데브옵스에 대해 언급할 땐 관련 기술, 패턴, 선진 사례를 빠뜨릴 수 없다. 이것들은 기업에 마이크로서비스 아키텍처(MSA, 작은 서비스를 서로 결합해 전체 응용 프로그램을 개발하는 방법)에 기반한 XaaS(인공지능, 빅데이터, 사물인터넷 등과 결합하는 서비스)와 같은 효율을 제공한다.
컨테이너(Container, 가상머신에 기업용 소프트웨어나 서비스까지 하나로 묶은 클라우드), 코드화된 인프라스트럭쳐(Infrastrcture as code), 자동화(Automation), 탄력성(Elasticity), 모니터링, 구성 관리, 자체 유지, 적응 가능한 시스템, 생태계와 같은 개념도 데브옵스를 위해 필요하다.
MSA의 개발과 배포 단계에서 쿠버네티스(Kubernetes, 컨테이너를 편성하는 기술), 앤시블(Ansible, 환경 설정 관리나 애플리케이션 구축, 클라우드 연결 등 다양한 IT 기능을 자동화 처리해주는 도구), 우분투(Ubuntu, 리눅스 운영 체제), 스웜(Swarm, 컨테이너 관리 도구), 컴포즈(Docker Compose, 다중 컨테이너 애플리케이션 개발과 시험 과정을 간소화하는 도구) 등의 활용법도 알아야 한다.
데브섹옵스(DevSecOps)는 데브옵스에 보안(Security)을 추가해 생긴 단어다. IT 개발, 배포, 운영, 관리 등 전 영역이 보안과 밀접하게 연계돼 보안을 모두의 책임으로 간주하고, 전체 개발 주기 동안 보안 기반을 구축한 것을 말한다(DevOpsSec: Creating the Agile Triangle, 가트너, 2012). 데브옵스 2.0도 같은 의미다.
그렇다고 해서 보안이 모든 것을 과도하게 주물러야 한다는 의미는 아니다. 만약 그렇다면 모든 것이 마비될 수도 있다. 데브옵스를 진행하는 주기 동안 보안이 포함되도록 설계하면 그만이다. (마이크 버셀 레드햇 수석 보안 아키텍트).
보안 전문가가 데브섹옵스에 참여하면 다양한 지식을 프로세스에 적용하도록 할 수 있다. 또 모두가 그의 전문 지식을 이용할 수 있는 방식으로 데브옵스 모델에 보안을 자동화할 수 있다.
전통적인 보안 문화에서는 전문가가 조직의 시큐어 코딩(Secure Coding, 소프트웨어를 개발하는 모든 과정에서 코딩 시 실수나 고의로 오류나 약점, 취약점이 삽입되지 않게 프로그램하고 서비스하는 것)과 같은 보안 지침을 개발 과정 초기에 공유해준다. 또 중간 과정에 거의 개입하지 않다가 마지막(통합 시험 단계)에 취약점을 분석하거나 평가한다.
이렇게 되면 빠듯한 개발 일정과 오픈 일자에 맞추기 급급해 보안에 신경 쓸 여력이 줄어든다. 실제로 오픈을 앞둔 시점에서 수많은 보안 취약점과 결함이 발견된 경우가 적지 않다. (물론 훌륭한 개발자는 결함 수가 아주 적을 때도 있다.)
이럴 때 보안 전문가는 결함이나 취약점을 완벽히 조치하려면 오픈 일자를 조정해서라도 조치해야 한다고 주장할 수 있다. 반면 개발팀은 정해진 오픈 일자를 맞추고 그 이후 결함을 조치하자고 할 수 있다. 이런 상황을 미연에 방지하려면 보안이 기업의 개발 초기부터 전 단계에 걸쳐 개입하면 되지 않을까. 완벽한 보안은 없다. 하지만 초기에 문제를 발견할수록 그것을 해결하는 시간과 노력이 줄어들 수 있다는 것에는 모두가 동의할 것이다.
데브섹옵스가 제대로 작동하기 위해서는 모든 관련자들(개발자, 운영자, 보안전문가 등)이 개방된 의사소통 채널을 공유할 필요가 있다. 프로젝트 협업 도구를 통해 관련 진행 상황을 수시로 공유하면 단계별 마찰을 빨리 줄일 수 있다.
이렇게 하면 개발자가 바라보는 보안 전문가의 역할이 통제자나 감시자가 아니라 적절한 도구, 기술, 프로세스를 제공해 개발과 운영에 신속하고 효율적인 적용을 할 수 있도록 지원해주는 조력자로 바뀔 수 있다.
다만 현실적으로 데브섹옵스를 전문으로 하는 소스 코드 분석 소프트웨어와 전문가가 아직 그렇게 많지 않다. 현재 사용중인 소프트웨어는 소나 큐브(Sonar Qube), 밸브(Valve), 볼트(Vault), 스태키파이(Stackify) 등이 있다.
정적 분석 도구인 PMD, 파인드 버그(Find Bug), 체크 스타일(Check Style), 커버리티(Coverity), 퓨리파이 플러스(Purify Plus), 포티파이(Fortify), 스패로(Sparrow), 클락 웍(Klock Work), 폴리스페이스(Poly Space), 코드 소나(Code Sonar)와 동적 분석 도구인 코어 임팩트(Core Impact), 캔버스(CANVAS), 메타 스플로잇(Meta Sploit), 앱 스캔(App Scan), 아큐네틱스(Acunetix) 등도 있으나 전체 개발 영역을 커버하지는 못하고 있다.
데브섹옵스를 성공적으로 구축하기 위해서는 다음과 같은 것이 필요하다.
첫번째는 조직 문화다. 개발 초기 단계부터 보안팀이 참여할 수 있도록 조직 문화에 대한 변화가 선행돼야 한다. 또 개발팀, 보안팀, 운영팀이 보안을 공동으로 책임지는 문화를 만드는 것이 무엇보다 중요하다.
두번째는 프로세스다. 조직의 내부 프로세스를 재배치해서 개발팀, 운영팀, 보안팀, 컴플라이언스팀에서 조직의 정책, 요구사항, 프로세스를 데브옵스 조직과 워크플로우에 통합해 개발 초기 단계에서 보안 분석과 테스트가 가능한 프로세스를 만들어야 한다.
세번째는 자동화다. 문화와 프로세스가 있다 하더라도 수동적이라면 효율성과 정확성, 빠른 속도를 충족시킬 수 없다. 그래서 보안성 시험, 보안 공유 저장소 생성, 데브옵스를 위한 보안 절차 단순화를 해야 한다. 앞서 언급한 코드로서의 보안 관리가 그 예다.
네번째는 자동화를 위한 도구가 필요하다. 데브옵스와 효과적으로 연결할 수 있는 도구를 선택해 보안 검사로 결함을 파악해야 한다. 또 동적 앱(App)의 보안 시험을 진행해야 한다. 이를 위해 데브옵스 CI와 CD 파이프라인(Pipeline)과 보안 점검 도구 간 결합이 선행돼야 한다.
마지막으로 수치에 기반한 성과 평가가 필요하다. 배포 빈도와 주기, 장애 복구 시간(MTTR, Mean time to Recover, MTTR), 비율로 표현된 결함 수의 변화 등을 통해 데브섹옵스의 효율성, 효과성을 측정해야 한다. 또 이를 통해 개선 사항을 조치해야 한다.
클라우드는 이제 거스를 수 없는 대세가 됐다. 최근 클라우드 생태계는 다양한 형태의 IT 생태계가 조합된 하이브리드 클라우드(Hybrid Cloud)와 2개 이상의 서비스형 클라우드를 연결해 사용하는 멀티 클라우드 등으로 발전하고 있다. 이에 기존 조직과 프로세스에만 머물지 말고 데브옵스와 데브섹옵스를 일찍 도입해 내부 역량을 강화하는 것이 IT 조직, 보안 조직과 구성원의 생존을 가늠할지 모른다.
그래도 삭제하시겠습니까?