개발자도 잘 모른다는 ‘데브옵스’, 방법론인가 문화인가
데브옵스 등장 배경과 NHN 엔터테인먼트의 실제 사례
[보안뉴스 오다인 기자] 하나의 유령이 IT 업계를 떠돌고 있다. 데브옵스(DevOps)라는 유령이. 구 IT 업계의 모든 세력들, 즉 서버 관리자와 네트워크 관리자, 시스템 운영자와 품질 관리자, 개발자가 이 유령을 사냥하려고 하나 잡힐 듯 잡히지 않는다. 그동안 그들은 유령에 쫓길 뿐이다.
유령의 뒤를 기자가 쫓았다. 유령은 왜 지금 나타났고, 여기서 무엇을 하고 있는지 희미한 흔적을 더듬었다. 그리고 이 유령이 앞으로 무엇을 할 것인지 미약하게나마 추리해봤다. 본 기사는 누구는 봤다고 하고, 누구는 없다고 하는 데브옵스라는 유령의 뒤를 밟은 기록이다.
1장. 도대체 무엇이 ‘데브옵스’인가
최근 몇 년 사이 데브옵스만큼 수없이 회자되면서도 그 실체를 봤다는 사람이 드문 사안은 없을 것이다. 데브옵스에 대한 예찬은 쏟아지지만 정작 무엇이 데브옵스이고 어떻게 해야 한다는 것인지 명확히 정의된 바는 없다. 데브옵스는 있는 것일까, 없는 것일까.
위키백과에서는 데브옵스를 “소프트웨어 개발과 운영의 합성어로서 소프트웨어 개발자와 IT 전문가 간의 소통과 협업, 통합을 강조하는 개발 환경이나 문화”라고 정의하면서 “소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다”고 명시하고 있다.
그럼에도 불구하고 데브옵스를 둘러싸고 의견이 분분한 이유 중 하나는 이것이 방법론인지, 문화인지조차 정확히 판단할 수 없기 때문이다. 개발 환경인지, 그러한 관점을 지칭하는 것인지 경계가 흐릿하다. 개발(Dev)과 운영(Ops)을 어떻게 합한다는 것인지 감조차 잡을 수 없는 자들과, 이미 그러한 환경에서 출발한 이들이 한 데 얽혀 데브옵스라는 유령을 만들어내는 중이다.
그러나 데브옵스가 나타난 배경이 클라우드(Cloud)의 등장이라는 데는 이견이 없다. 포티넷 시큐리티 코리아(Fortinet Security Korea)의 이상훈 부장은 “지난 20~30년간 시스템 자동화를 위한 노력들이 쌓인 결과 지금처럼 보다 광범위한 자동화가 가능해졌다”며 “이런 노력들이 데브옵스라는 이름으로 불리게 된 것 같다”고 말했다.
“자동화에 대한 노력은 앞서 충분하다고 할 정도로 많았지만 예전엔 그 모두를 하나로 통합하는 게 어려웠습니다. 하지만 SDN(Software Defined Networking)과 클라우드가 등장하면서 API로 단일 인터페이스에 접근하는 네트워크 인프라 혁신이 일어났습니다. 이때부터 네트워크를 하나의 객체로 보고 개별적으로 코딩할 수 있게 됐습니다. 개발자가 코딩하는 것처럼 네트워크를 관리할 수 있게 된 것이죠.”
이 부장은 “REST API(Representational State Transfer API)가 나오면서 네트워크 장비와 보안 장비가 개발자에게 오픈되기 시작했다”고 덧붙였다. “API는 집을 짓는 시멘트라고 보시면 됩니다. 큰 골격이 서면 API로 접착시킵니다. REST API의 등장으로, 웹 개발만 할 줄 알면 API로 시스템과 장비들을 붙일 수 있게 됐습니다.”
아카마이(Akamai)의 강상진 상무 역시 “클라우드와 오픈소스 사용이 활성화 되면서 데브옵스가 더욱 부상했다”고 설명했다. “예전엔 운영 팀에서 서버와 시스템을 구입해주면 개발 팀이 이를 활용해 개발에 들어갔습니다. 기존 운영자들 입장에선 필요한 모듈을 직접 개발하는 데도 한계가 있었고요. 그런데 클라우드 환경에서 오픈소스 애플리케이션이 다양하게 제공되기 시작하면서 API만 연동하면 개발할 수 있고 모니터링 할 수 있는 시대가 왔습니다. 즉, 클라우드와 오픈소스의 등장으로 개발과 운영의 난이도가 낮아졌다고 요약할 수 있습니다. 경계가 허물어졌다고도 할 수 있겠네요.”
이와 함께 CA 테크놀로지스(CA Technologies)의 하봉문 전무는 “개발 주기가 사라지면서 나타나게 된 것”이 데브옵스라고 말했다. “예전엔 ‘올해 이런 기능을 개발하라’고 하는 개발 주기가 있었습니다. 하지만 최근엔 사용자가 엄청난 숫자로 증가하면서 빠르고 유연하게 적응해야 하는 시대로 접어들었습니다. 사업에서 살아남기 위해서는 사용자 대응 속도에 맞춰야 합니다.” 하 전무는 “(상품이나 서비스의) 실패에 대한 인내심(tolerance)이 매우 낮아진 결과”로써 데브옵스라는 방법론이 각광받게 된 것이라고 분석했다.
하 전무는 기존의 워터폴(Waterfall) 방식이 가부장제 모델이라면 최근의 데브옵스는 수평적인 모델이라고 비유했다. “가부장이라는 PM(Project Manager)이 주도하는 체제에서는 문제가 나타나기 몇 주나 몇 개월 전에 PM이 미리 그 문제를 파악해서 지시하고, 또 풀어야 한다는 단점이 있습니다. 하지만 이렇게는 매순간 변화하는 사용자 니즈에 맞출 수가 없어요. 수평적인 관계의 데브옵스 모델에서는 문제가 나올 때마다 빠르게 포착해서 바로 적용할 수 있습니다.”
데브옵스에 자동화가 함께 언급되는 이유는 사용자가 급속하게 증가할 경우 이에 상응하는 서버 관리를 수동으로 할 수 없기 때문이며, 협업 모델이라는 측면에서도 자동화가 필요하기 때문이다. 하 전무는 데브옵스를 통해 테스트 자동화나 배포 자동화가 자연스레 구축되고, 이로써 사용자 니즈에 발 빠르게 맞출 수 있다고 설명했다.
포티넷 시큐리티 코리아 이상훈 부장도 “기존에는 메인프레임(Mainframe)이나 대형 유닉스(Unix)처럼 초대형 시스템 몇 대를 통해 서비스를 제공했기 때문에 한 사람이 관리해야 할 서버의 대수가 많지 않았다”고 말했다. 이 부장에 따르면, “저가의 리눅스(Linux) x86 시스템을 여러 대 묶어서 서비스하는 기술이 개발되고, 구글 파일 시스템(Google File System)이라는 분산 시스템 개념과 마이크로서비스 아키텍처의 유행으로 인해 관리해야 할 시스템 숫자가 엄청나게 증가한 것”이 데브옵스를 도입할 수밖에 없었던 배경이 됐다. 즉, “관리 부하를 줄이기 위해 데브옵스라는 방식을 택할 수밖에 없었을 것”이라는 분석이다.
데브옵스 전문가 짐 버드(Jim Bird)는 “애자일이 총알을 채웠다면 데브옵스가 방아쇠를 당기고 있다(Agile loaded the gun. DevOps is pulling the trigger)”고 묘사한 바 있다. 개발의 마감 시한이 없는, 즉 매순간이 개발과 운영으로 수렴되는 환경이 바로 데브옵스라고 할 수 있다.
종합하자면, 데브옵스는 △클라우드 △자동화 △API 등의 세 가지 키워드로 수렴된다. 이 세 가지 키워드의 바탕에는 ‘규모’와 ‘속도’라는 거대한 시대 흐름이 자리하고 있다.
2장. 데브옵스, 어떻게 일어나고 있나
아카마이 강상진 상무는 “별도의 데브옵스 팀이 있는 곳도 있고, 기존의 시스템 운영 팀과 개발 팀이 같이 움직이는 곳도 있다”면서 “그 경계가 모호한 곳이 많다”고 말했다. “막상 현장에 나가보면 이미 데브옵스 방식으로 일하고 계신 분들이 많습니다. 스타트업처럼 규모가 작은 곳일수록 자연스레 한 사람의 엔지니어가 많은 역할을 해야 하므로 데브옵스 방식을 택하고 있는 경우가 많습니다.”
클라우드의 등장으로 데브옵스의 기본 환경이 조성됐다면 그 바탕에서 수많은 스타트업들이 개발과 운영을 혼합해 이미 일하고 있다는 것이다. 반면, 기능별로 명확하게 구분돼있는 대기업의 경우 아직까지 운영과 개발을 분리해서 운영하는 경우가 많다. 강 상무는 “데브옵스 모델로 이행하려면 예산의 문제, 보안의 문제도 무시할 수 없다”면서 “클라우드 비용과 레거시 기기 잔여에 대한 기회비용을 계산해서 손익분기점을 넘을 수 있는지에 대한 문제와 함께, 클라우드에 시스템 오픈 시 기업마다 갖고 있던 전통적인 보안 정책을 변화시켜야 하는 문제에 봉착한다”고 설명했다.
NHN 엔터테인먼트(NHN Entertainment)의 임정립 실장(IT보안실)과 강상모 실장(클라우드시스템실)은 “NHN 엔터테인먼트의 경우, ‘데브옵스(Dev→Ops)’라기보다는 ‘옵스데브(Ops→Dev)’ 형태로 진행되고 있다”고 말했다. 강 실장은 “4년 전 NHN이 네이버와 NHN 엔터테인먼트로 분할되면서부터 소수의 운영 팀 인력으로 효율적으로 일하려다 보니 자연스레 운영자가 개발자 영역으로 들어가게 됐다”고 설명했다.
강 실장은 “예전엔 운영 팀에서 외부 솔루션을 쭉 검토하고 선택한 뒤, 해당 솔루션에 대해 교육을 받고 사용하는 형태”였지만 “현재는 자동화하기 위한 도구를 직접 만든다”고 말했다. “지금은 자동화 도구들을 직접 운영 팀에서 디자인하고, 워크플로우(workflow) 연동에까지 관여하고 있습니다. 과거에 도메인 관리나 SSL 인증서 관리 같은 부분들을 부서별로 따로 관리하면서 납기 기한을 놓치는 경우가 발생했지만 이를 방지하기 위해 직접 도구를 만들고 있는 것이죠.”
NHN 엔터테인먼트에서 데브옵스 또는 옵스데브로 출시된 대표적인 사례로 ‘토스트 클라우드(TOAST Cloud)’의 일부 PaaS(Platform as a Service) 상품이 있다. 해당 상품은 NHN 엔터테인먼트 운영 팀의 필요로 개발해서 사용하다가 개발 팀에 맡겨 상품화한 사례다. 강 실장은 “운영자들이 개발하는 데 한계가 있기 때문에 어떤 도구를 개발해서 사용하다가 규모가 커지면 전문 개발 조직에 업무를 이관하는 경우가 생긴다”고 설명했다. NHN 엔터테인먼트 홍보팀의 전효주 과장은 “이렇게 개발한 서비스는 내부에서 일정기간 검증해보고 출시하기 때문에 고객 만족도도 높다”고 말했다.
NHN 엔터테인먼트의 운영 팀은 전문 개발 팀은 아니지만 기본적인 개발 능력을 바탕으로 필요한 도구들을 빠르게 만들어 바로 사용할 수 있도록 한다. 빠르게 만든 만큼 사용하다가 불편하면 버리고 다시 만드는 속도도 빠르다. “코드 전체를 뜯어 고치려면 시간이 너무 오래 걸리기 때문에 당장 쓸 수 있는 툴을 빠르게 만들어 쓰고, 또 결과물도 빨리 보도록 합니다.” 강 실장은 그래서 “불필요한 협업이 줄어들게 된다”고 말했다. 데브옵스라고 하면 협업이 마치 핵심처럼 통용되고 있으나 어떤 측면에선 반대로 협업의 필요성을 줄이기도 하는 것이다.
시간의 중요성은 이 대목에서 다시 등장한다. 데브옵스 가운데 보안을 끼워 ‘데브섹옵스(DevSecOps)’라고도 하는데, 아카마이 강상진 상무는 “개발이 모두 끝나 출시된 소프트웨어의 원시 코드 레벨까지 내려가서 보안을 다시 손보는 건 처음부터 보안을 고려하면서 소프트웨어를 설계하는 것보다 훨씬 더 어렵고 유지보수 비용도 더 많이 든다”고 말했다. 강 상무는 “이런 관점에서 보면 데브섹옵스는 유지보수 비용까지 절약해주는 모델이라고 볼 수 있다”고 덧붙였다.
익명을 요청한 한 보안 전문가는 “사실 개발자들 자체도 데브옵스에 대해 명확한 개념이나 정의를 갖고 일하지는 않는다”면서 “사람과 조직마다 데브옵스에 대한 정의가 다를뿐더러 대형 IT 기업에서 데브옵스라고 지칭하는 것이 정말 데브옵스인지에 대해서도 알 수 없다”고 지적했다. 그러면서 “보안의 경우, ‘데브’와 ‘옵스’ 사이사이에 모두 관여한다”고도 설명했다. “굳이 말하자면, ‘섹데브섹옵스섹(Sec-Dev-Sec-Ops-Sec)’이라고 할 수 있겠네요. 개인정보 수집을 어떻게 할 것이냐는 문제에서부터 분석 자동화를 어떻게 할 것이고, 품질 관리를 거쳐 보안 검수와 모니터링을 어떻게 할 것이냐는 문제까지 그 모든 과정에 보안은 개입합니다.”
그래서 데브옵스 또는 데브섹옵스가 소프트웨어 보안에 도움이 될 것이냐는 질문은 유효하지 않다. NHN 엔터테인먼트의 임정립 실장에 따르면, “프로그램의 식별 가능한 취약점은 자동화 분석으로 막을 수 있지만 개별 회사마다 갖고 있는 비즈니스 로직에서의 취약점은 자동화 분석으로 막을 수 없다.” 즉, 데브옵스로 보안이 강화된다고 말할 수 있는 부분은 프로그램 자체적으로 식별할 수 있는 취약점뿐이라는 지적이다.
아카마이 강상진 상무는 “대부분의 경우, 애플리케이션 자체 취약점은 코드로 막고, 외부로부터의 공격은 탐지 장비 및 보안 소프트웨어로 막는 것”이라고 설명했다. “데브섹옵스를 ‘코드로써의 보안(Security as Code)’이라고도 합니다. 인프라와 장비로 방어하는 건 운영자들이 해왔던 일이고, 원래부터 개발자들의 영역은 아니었습니다. 기밀정보 유출이나 해킹을 막을 수 있는 건 여전히 탐지 장비의 역할이지 개발자의 역할로 보기는 어렵습니다. 다만, 소프트웨어 자체의 보안 취약점에 대한 부분은 개발자들이 어느 정도 고려해서 개발할 수 있습니다.”
CA 테크놀로지스 하봉문 전무는 자사의 베라코드(Veracode)를 예로 들며 “코드 개발 플랫폼을 연동해 코드 단계에서부터 보안 위협을 탐지하는 수준에 이르렀다”고 말했다. 하 전무는 베라코드 같은 도구를 통해 “데브옵스에서 언급되는 엘리트주의를 타파할 수 있다”고도 덧붙였다. “이런 툴이 상용화되면 극소수의 엘리트만 발휘할 수 있었던 능력이 일반으로 퍼질 수 있습니다.”
3장. 곧 다가올 데브옵스
데브옵스로 가려면 거대한 조직 변화가 필요하다는 사람이 있는 반면, 이미 데브옵스는 만연하게 일어나고 있는 일이라고 보는 사람도 있다. 데브옵스는 부서 간 협업이 핵심이라는 입장이 있는 한편으로, 도리어 부서 간 협업의 필요성을 낮추고 자체적인 개발 역량을 키우는 흐름이라는 입장도 있다. 데브옵스라는 유령을 제각기 어떤 모습으로 보고 있든, 경계는 허물어지고 모두가 저마다의 실체를 파악하려고 노력하는 중이다.
그러나 개발과 운영이 한 데 녹아들면서 일어나는 선순환의 사례가 확산되면서 데브옵스는 거스를 수 없는 흐름으로 자리할 것으로 전망된다. 데브옵스 모델로 이행하면서 “이 서비스가 왜 필요한지, 왜 이 부분을 개선해야 하는지 빠르게 파악할 수 있고 개선할 수 있다”는 NHN 엔터테인먼트 강상모 실장의 말처럼, 데브옵스 가능 인력에 대한 수요가 점차 커지는 데서도 짐작해볼 수 있는 것처럼, 데브옵스는 잡히지 않는 유령의 모습이 아니라 살아남기 위해 받아들여야 할 변화로서 곧 모습을 드러낼 것이다.
[오다인 기자(boan2@boannews.com)]
데브옵스 등장 배경과 NHN 엔터테인먼트의 실제 사례
[보안뉴스 오다인 기자] 하나의 유령이 IT 업계를 떠돌고 있다. 데브옵스(DevOps)라는 유령이. 구 IT 업계의 모든 세력들, 즉 서버 관리자와 네트워크 관리자, 시스템 운영자와 품질 관리자, 개발자가 이 유령을 사냥하려고 하나 잡힐 듯 잡히지 않는다. 그동안 그들은 유령에 쫓길 뿐이다.
유령의 뒤를 기자가 쫓았다. 유령은 왜 지금 나타났고, 여기서 무엇을 하고 있는지 희미한 흔적을 더듬었다. 그리고 이 유령이 앞으로 무엇을 할 것인지 미약하게나마 추리해봤다. 본 기사는 누구는 봤다고 하고, 누구는 없다고 하는 데브옵스라는 유령의 뒤를 밟은 기록이다.
[이미지=iclickart]
1장. 도대체 무엇이 ‘데브옵스’인가
최근 몇 년 사이 데브옵스만큼 수없이 회자되면서도 그 실체를 봤다는 사람이 드문 사안은 없을 것이다. 데브옵스에 대한 예찬은 쏟아지지만 정작 무엇이 데브옵스이고 어떻게 해야 한다는 것인지 명확히 정의된 바는 없다. 데브옵스는 있는 것일까, 없는 것일까.
위키백과에서는 데브옵스를 “소프트웨어 개발과 운영의 합성어로서 소프트웨어 개발자와 IT 전문가 간의 소통과 협업, 통합을 강조하는 개발 환경이나 문화”라고 정의하면서 “소프트웨어 개발 조직과 운영 조직 간의 상호 의존적 대응이며 조직이 소프트웨어 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다”고 명시하고 있다.
그럼에도 불구하고 데브옵스를 둘러싸고 의견이 분분한 이유 중 하나는 이것이 방법론인지, 문화인지조차 정확히 판단할 수 없기 때문이다. 개발 환경인지, 그러한 관점을 지칭하는 것인지 경계가 흐릿하다. 개발(Dev)과 운영(Ops)을 어떻게 합한다는 것인지 감조차 잡을 수 없는 자들과, 이미 그러한 환경에서 출발한 이들이 한 데 얽혀 데브옵스라는 유령을 만들어내는 중이다.
그러나 데브옵스가 나타난 배경이 클라우드(Cloud)의 등장이라는 데는 이견이 없다. 포티넷 시큐리티 코리아(Fortinet Security Korea)의 이상훈 부장은 “지난 20~30년간 시스템 자동화를 위한 노력들이 쌓인 결과 지금처럼 보다 광범위한 자동화가 가능해졌다”며 “이런 노력들이 데브옵스라는 이름으로 불리게 된 것 같다”고 말했다.
“자동화에 대한 노력은 앞서 충분하다고 할 정도로 많았지만 예전엔 그 모두를 하나로 통합하는 게 어려웠습니다. 하지만 SDN(Software Defined Networking)과 클라우드가 등장하면서 API로 단일 인터페이스에 접근하는 네트워크 인프라 혁신이 일어났습니다. 이때부터 네트워크를 하나의 객체로 보고 개별적으로 코딩할 수 있게 됐습니다. 개발자가 코딩하는 것처럼 네트워크를 관리할 수 있게 된 것이죠.”
이 부장은 “REST API(Representational State Transfer API)가 나오면서 네트워크 장비와 보안 장비가 개발자에게 오픈되기 시작했다”고 덧붙였다. “API는 집을 짓는 시멘트라고 보시면 됩니다. 큰 골격이 서면 API로 접착시킵니다. REST API의 등장으로, 웹 개발만 할 줄 알면 API로 시스템과 장비들을 붙일 수 있게 됐습니다.”
아카마이(Akamai)의 강상진 상무 역시 “클라우드와 오픈소스 사용이 활성화 되면서 데브옵스가 더욱 부상했다”고 설명했다. “예전엔 운영 팀에서 서버와 시스템을 구입해주면 개발 팀이 이를 활용해 개발에 들어갔습니다. 기존 운영자들 입장에선 필요한 모듈을 직접 개발하는 데도 한계가 있었고요. 그런데 클라우드 환경에서 오픈소스 애플리케이션이 다양하게 제공되기 시작하면서 API만 연동하면 개발할 수 있고 모니터링 할 수 있는 시대가 왔습니다. 즉, 클라우드와 오픈소스의 등장으로 개발과 운영의 난이도가 낮아졌다고 요약할 수 있습니다. 경계가 허물어졌다고도 할 수 있겠네요.”
이와 함께 CA 테크놀로지스(CA Technologies)의 하봉문 전무는 “개발 주기가 사라지면서 나타나게 된 것”이 데브옵스라고 말했다. “예전엔 ‘올해 이런 기능을 개발하라’고 하는 개발 주기가 있었습니다. 하지만 최근엔 사용자가 엄청난 숫자로 증가하면서 빠르고 유연하게 적응해야 하는 시대로 접어들었습니다. 사업에서 살아남기 위해서는 사용자 대응 속도에 맞춰야 합니다.” 하 전무는 “(상품이나 서비스의) 실패에 대한 인내심(tolerance)이 매우 낮아진 결과”로써 데브옵스라는 방법론이 각광받게 된 것이라고 분석했다.
하 전무는 기존의 워터폴(Waterfall) 방식이 가부장제 모델이라면 최근의 데브옵스는 수평적인 모델이라고 비유했다. “가부장이라는 PM(Project Manager)이 주도하는 체제에서는 문제가 나타나기 몇 주나 몇 개월 전에 PM이 미리 그 문제를 파악해서 지시하고, 또 풀어야 한다는 단점이 있습니다. 하지만 이렇게는 매순간 변화하는 사용자 니즈에 맞출 수가 없어요. 수평적인 관계의 데브옵스 모델에서는 문제가 나올 때마다 빠르게 포착해서 바로 적용할 수 있습니다.”
데브옵스에 자동화가 함께 언급되는 이유는 사용자가 급속하게 증가할 경우 이에 상응하는 서버 관리를 수동으로 할 수 없기 때문이며, 협업 모델이라는 측면에서도 자동화가 필요하기 때문이다. 하 전무는 데브옵스를 통해 테스트 자동화나 배포 자동화가 자연스레 구축되고, 이로써 사용자 니즈에 발 빠르게 맞출 수 있다고 설명했다.
포티넷 시큐리티 코리아 이상훈 부장도 “기존에는 메인프레임(Mainframe)이나 대형 유닉스(Unix)처럼 초대형 시스템 몇 대를 통해 서비스를 제공했기 때문에 한 사람이 관리해야 할 서버의 대수가 많지 않았다”고 말했다. 이 부장에 따르면, “저가의 리눅스(Linux) x86 시스템을 여러 대 묶어서 서비스하는 기술이 개발되고, 구글 파일 시스템(Google File System)이라는 분산 시스템 개념과 마이크로서비스 아키텍처의 유행으로 인해 관리해야 할 시스템 숫자가 엄청나게 증가한 것”이 데브옵스를 도입할 수밖에 없었던 배경이 됐다. 즉, “관리 부하를 줄이기 위해 데브옵스라는 방식을 택할 수밖에 없었을 것”이라는 분석이다.
데브옵스 전문가 짐 버드(Jim Bird)는 “애자일이 총알을 채웠다면 데브옵스가 방아쇠를 당기고 있다(Agile loaded the gun. DevOps is pulling the trigger)”고 묘사한 바 있다. 개발의 마감 시한이 없는, 즉 매순간이 개발과 운영으로 수렴되는 환경이 바로 데브옵스라고 할 수 있다.
종합하자면, 데브옵스는 △클라우드 △자동화 △API 등의 세 가지 키워드로 수렴된다. 이 세 가지 키워드의 바탕에는 ‘규모’와 ‘속도’라는 거대한 시대 흐름이 자리하고 있다.
2장. 데브옵스, 어떻게 일어나고 있나
아카마이 강상진 상무는 “별도의 데브옵스 팀이 있는 곳도 있고, 기존의 시스템 운영 팀과 개발 팀이 같이 움직이는 곳도 있다”면서 “그 경계가 모호한 곳이 많다”고 말했다. “막상 현장에 나가보면 이미 데브옵스 방식으로 일하고 계신 분들이 많습니다. 스타트업처럼 규모가 작은 곳일수록 자연스레 한 사람의 엔지니어가 많은 역할을 해야 하므로 데브옵스 방식을 택하고 있는 경우가 많습니다.”
클라우드의 등장으로 데브옵스의 기본 환경이 조성됐다면 그 바탕에서 수많은 스타트업들이 개발과 운영을 혼합해 이미 일하고 있다는 것이다. 반면, 기능별로 명확하게 구분돼있는 대기업의 경우 아직까지 운영과 개발을 분리해서 운영하는 경우가 많다. 강 상무는 “데브옵스 모델로 이행하려면 예산의 문제, 보안의 문제도 무시할 수 없다”면서 “클라우드 비용과 레거시 기기 잔여에 대한 기회비용을 계산해서 손익분기점을 넘을 수 있는지에 대한 문제와 함께, 클라우드에 시스템 오픈 시 기업마다 갖고 있던 전통적인 보안 정책을 변화시켜야 하는 문제에 봉착한다”고 설명했다.
NHN 엔터테인먼트(NHN Entertainment)의 임정립 실장(IT보안실)과 강상모 실장(클라우드시스템실)은 “NHN 엔터테인먼트의 경우, ‘데브옵스(Dev→Ops)’라기보다는 ‘옵스데브(Ops→Dev)’ 형태로 진행되고 있다”고 말했다. 강 실장은 “4년 전 NHN이 네이버와 NHN 엔터테인먼트로 분할되면서부터 소수의 운영 팀 인력으로 효율적으로 일하려다 보니 자연스레 운영자가 개발자 영역으로 들어가게 됐다”고 설명했다.
강 실장은 “예전엔 운영 팀에서 외부 솔루션을 쭉 검토하고 선택한 뒤, 해당 솔루션에 대해 교육을 받고 사용하는 형태”였지만 “현재는 자동화하기 위한 도구를 직접 만든다”고 말했다. “지금은 자동화 도구들을 직접 운영 팀에서 디자인하고, 워크플로우(workflow) 연동에까지 관여하고 있습니다. 과거에 도메인 관리나 SSL 인증서 관리 같은 부분들을 부서별로 따로 관리하면서 납기 기한을 놓치는 경우가 발생했지만 이를 방지하기 위해 직접 도구를 만들고 있는 것이죠.”
NHN 엔터테인먼트에서 데브옵스 또는 옵스데브로 출시된 대표적인 사례로 ‘토스트 클라우드(TOAST Cloud)’의 일부 PaaS(Platform as a Service) 상품이 있다. 해당 상품은 NHN 엔터테인먼트 운영 팀의 필요로 개발해서 사용하다가 개발 팀에 맡겨 상품화한 사례다. 강 실장은 “운영자들이 개발하는 데 한계가 있기 때문에 어떤 도구를 개발해서 사용하다가 규모가 커지면 전문 개발 조직에 업무를 이관하는 경우가 생긴다”고 설명했다. NHN 엔터테인먼트 홍보팀의 전효주 과장은 “이렇게 개발한 서비스는 내부에서 일정기간 검증해보고 출시하기 때문에 고객 만족도도 높다”고 말했다.
NHN 엔터테인먼트의 운영 팀은 전문 개발 팀은 아니지만 기본적인 개발 능력을 바탕으로 필요한 도구들을 빠르게 만들어 바로 사용할 수 있도록 한다. 빠르게 만든 만큼 사용하다가 불편하면 버리고 다시 만드는 속도도 빠르다. “코드 전체를 뜯어 고치려면 시간이 너무 오래 걸리기 때문에 당장 쓸 수 있는 툴을 빠르게 만들어 쓰고, 또 결과물도 빨리 보도록 합니다.” 강 실장은 그래서 “불필요한 협업이 줄어들게 된다”고 말했다. 데브옵스라고 하면 협업이 마치 핵심처럼 통용되고 있으나 어떤 측면에선 반대로 협업의 필요성을 줄이기도 하는 것이다.
시간의 중요성은 이 대목에서 다시 등장한다. 데브옵스 가운데 보안을 끼워 ‘데브섹옵스(DevSecOps)’라고도 하는데, 아카마이 강상진 상무는 “개발이 모두 끝나 출시된 소프트웨어의 원시 코드 레벨까지 내려가서 보안을 다시 손보는 건 처음부터 보안을 고려하면서 소프트웨어를 설계하는 것보다 훨씬 더 어렵고 유지보수 비용도 더 많이 든다”고 말했다. 강 상무는 “이런 관점에서 보면 데브섹옵스는 유지보수 비용까지 절약해주는 모델이라고 볼 수 있다”고 덧붙였다.
익명을 요청한 한 보안 전문가는 “사실 개발자들 자체도 데브옵스에 대해 명확한 개념이나 정의를 갖고 일하지는 않는다”면서 “사람과 조직마다 데브옵스에 대한 정의가 다를뿐더러 대형 IT 기업에서 데브옵스라고 지칭하는 것이 정말 데브옵스인지에 대해서도 알 수 없다”고 지적했다. 그러면서 “보안의 경우, ‘데브’와 ‘옵스’ 사이사이에 모두 관여한다”고도 설명했다. “굳이 말하자면, ‘섹데브섹옵스섹(Sec-Dev-Sec-Ops-Sec)’이라고 할 수 있겠네요. 개인정보 수집을 어떻게 할 것이냐는 문제에서부터 분석 자동화를 어떻게 할 것이고, 품질 관리를 거쳐 보안 검수와 모니터링을 어떻게 할 것이냐는 문제까지 그 모든 과정에 보안은 개입합니다.”
그래서 데브옵스 또는 데브섹옵스가 소프트웨어 보안에 도움이 될 것이냐는 질문은 유효하지 않다. NHN 엔터테인먼트의 임정립 실장에 따르면, “프로그램의 식별 가능한 취약점은 자동화 분석으로 막을 수 있지만 개별 회사마다 갖고 있는 비즈니스 로직에서의 취약점은 자동화 분석으로 막을 수 없다.” 즉, 데브옵스로 보안이 강화된다고 말할 수 있는 부분은 프로그램 자체적으로 식별할 수 있는 취약점뿐이라는 지적이다.
아카마이 강상진 상무는 “대부분의 경우, 애플리케이션 자체 취약점은 코드로 막고, 외부로부터의 공격은 탐지 장비 및 보안 소프트웨어로 막는 것”이라고 설명했다. “데브섹옵스를 ‘코드로써의 보안(Security as Code)’이라고도 합니다. 인프라와 장비로 방어하는 건 운영자들이 해왔던 일이고, 원래부터 개발자들의 영역은 아니었습니다. 기밀정보 유출이나 해킹을 막을 수 있는 건 여전히 탐지 장비의 역할이지 개발자의 역할로 보기는 어렵습니다. 다만, 소프트웨어 자체의 보안 취약점에 대한 부분은 개발자들이 어느 정도 고려해서 개발할 수 있습니다.”
CA 테크놀로지스 하봉문 전무는 자사의 베라코드(Veracode)를 예로 들며 “코드 개발 플랫폼을 연동해 코드 단계에서부터 보안 위협을 탐지하는 수준에 이르렀다”고 말했다. 하 전무는 베라코드 같은 도구를 통해 “데브옵스에서 언급되는 엘리트주의를 타파할 수 있다”고도 덧붙였다. “이런 툴이 상용화되면 극소수의 엘리트만 발휘할 수 있었던 능력이 일반으로 퍼질 수 있습니다.”
3장. 곧 다가올 데브옵스
데브옵스로 가려면 거대한 조직 변화가 필요하다는 사람이 있는 반면, 이미 데브옵스는 만연하게 일어나고 있는 일이라고 보는 사람도 있다. 데브옵스는 부서 간 협업이 핵심이라는 입장이 있는 한편으로, 도리어 부서 간 협업의 필요성을 낮추고 자체적인 개발 역량을 키우는 흐름이라는 입장도 있다. 데브옵스라는 유령을 제각기 어떤 모습으로 보고 있든, 경계는 허물어지고 모두가 저마다의 실체를 파악하려고 노력하는 중이다.
그러나 개발과 운영이 한 데 녹아들면서 일어나는 선순환의 사례가 확산되면서 데브옵스는 거스를 수 없는 흐름으로 자리할 것으로 전망된다. 데브옵스 모델로 이행하면서 “이 서비스가 왜 필요한지, 왜 이 부분을 개선해야 하는지 빠르게 파악할 수 있고 개선할 수 있다”는 NHN 엔터테인먼트 강상모 실장의 말처럼, 데브옵스 가능 인력에 대한 수요가 점차 커지는 데서도 짐작해볼 수 있는 것처럼, 데브옵스는 잡히지 않는 유령의 모습이 아니라 살아남기 위해 받아들여야 할 변화로서 곧 모습을 드러낼 것이다.
[오다인 기자(boan2@boannews.com)]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
오다인기자 기사보기
[2024-10-31] .jpg)
