“‘디지털 다위니즘’에 대처하기 위한 개발자의 여섯 계단”

디지털 다위니즘(Digital Darwinism)이라는 말이 있다. 진화하면서 환경에 적응한 생물만 살아남는다는 진화론(다위니즘)을 기업 경영에 차용한 말로, 4차 산업혁명 시대에는 일반 기업들도 디지털 기업으로 진화해야 생존할 수 있다는 의미다.

디지털 다위니즘에 대처하기 위해서는 모든 비즈니스에 반드시 기술이 필요하다. 현재 전세계 비즈니스를 이끌고 있는 글로벌 기업들은 디지털 기술을 가장 잘 활용하고 있는 회사라고 봐도 무방할 정도다. GE가 스스로 소프트웨어 기업이라고 천명하고,  스타벅스가 디지털기업이라고 이야기하는 것이 대표적인 사례다.

디지털 다위니즘을 실현하는 직군은 개발자다. 개발자의 역량이 기업의 핵심역량이 된 것이다. 디지털 다위니즘이 가속화 될 수록 개발자들은 더 많은 업무 책임을 지게 된다.  모바일이 발달하면서, 이전에는 석 달에 한 번 업그레이드 하던 애플리케이션을 이제는 모바일 전용으로 매달 내놓아야 하는 세상이다.

한국레드햇 오세영 부장은 레드햇 포럼에서 ‘디지털 다위니즘’에 대처하기 위해 필요한 개발자와 IT부서의 진화를 6단계로 설명했다.

오 부장은 “델타 항공, CNN뉴스, 코카콜라 등 수십년간 경쟁해서 살아남은 이유는 변화하는 IT 기술과 고객 트렌드를 순응하고 변화에 따른 (도태 위험을) 극복해가지고 지금 같은 회사가 된 것”이라며 “소프트웨어가 세상을 잡아 먹고 있다고 하는데, 개발하는 사람이 (여기에) 어떻게 영향을 끼칠 수 있을지를 살펴봐야 한다”고 말했다.

첫 단계는 ‘데브옵스’다. 데브옵스는 소프트웨어 개발(dev)과 운영(ops)의 합성어로 개발자와 운영자 간 소통, 협업 및 통합을 강조하는 개발 환경과 문화를 말한다. 조직이 가진 체계, 의사소통 스킬, 조직원의 일하는 방식과 프로세스가 가장 중요하다.

데브옵스를 하기 위해선 조직이 어떻게 일하고 소통하는지를 먼저 분석해야 한다. 아마존, 페이스북, 레드햇 같은 기업들이 데브옵스를 한다고 해서 무조건 벤치마킹을 한다면 그것은 잘못된 단추를 끼우는 것이라고 오 부장은 설명했다.

오 부장은 “레거시 시스템은 회사가 일하는 방식을 그대로 따다가 만들어 놓은 것이기 때문에 그걸 먼저 잘 살펴야 한다”면서 “데브옵스라고 해서 갑자기 사원이 바로 대표한테 결제를 받는 방식이 받아들여지겠는가? 그건 안되는 일”이라고 말했다.

그렇다면 데브옵스 단계에서 개발자가 할 일은 무엇일까? 각 조직에 있는 모든 이들이 모여 토의하고 각 조직에 맞는 커뮤니케이션 방법과 프로세스, 이를 도울 수 있는 도구(Tool)이 무엇이지 고민해야 한다. 흔히 말하는 ‘슈퍼개발자’는 커뮤니케이션을 잘 해야 한다는 것이 오 부장의 주장이다. 그는 “예전처럼 단순한 애플리케이션을 만들 때는 개발자가 혼자서도 일을 잘 할 수 있었다”면서 “그러나 클라우드, 머신러닝, 딥러닝처럼 복잡한 기술이 나오면서 여러 사람이 모여서 일을 하는 경우가 많아지는 만큼 커뮤니케이션 능력은 선택이 아니라 필수”라고 말했다.

두번째 단계는 ‘셀프서비스, 주문형, 유연한 인프라(slef- service, on-demanded, elastic infrastructure)’다. 흔히들 셀프서비스라고 할 때 가장 먼저 떠올리는 것이 아마존웹서비스(AWS)나 레드햇의 PaaS 클라우드다. 아이디 로그인 후 몇 번의 클릭만으로 원하는 일을 혼자 곧바로 할 수 있는 환경이 구축됐다. 과거에는 개발 그룹이 작업에 앞서 가상서버를 만들고 사내에 있는 프로세스를 그 위에 얹은 후 자원을 받고 이메일로 접속 정보를 받아야 하는 등 절차가 복잡했다. 그마저도 결제하는 이가 장기 부재일 경우엔 업무 지연이 상당했다. 그런데 지금은 요청 없이 나 혼자 어떤 일이든 가능하다. 이런 게 셀프 서비스라는 설명이다.

오 부장은 개발자들이 이런 환경 변화에 보다 적극적으로 임해야 한다고 주문한다. 조직계통이 바뀌고 의사 소통 구조가 바뀌면서 개발자의 역량이 커진 만큼, 개발자가 인프라 환경 변화에 책임을 지지 않으려고 회피하지 말아야 한다는 것이다.

셋째는 자동화(automation)다.  그 시작은 표준화다. 표준화된 것을 자동화로 바꾸기 위해 적절한 툴을 사용하는 것이 중요하다. 오 부장은 “(자동화에)가장 큰 영향을 준 것이 컨테이너 패키징 기술”이라며 “도커(Docker)라는 패키징 기술이 선보였고, 클라우드 환경과 확장성이 있는 리눅스 기반의 새로운 컨테이너 기술이 나오면서 자동화를 쉽게 만들어줬다”고 설명했다.

자동화는 특히  최근 업무 환경이 복잡하고 규모가 커지면서 더더욱 중요해진 부분이다. 기업에서 이용하는 서버가 수천, 수만 대로 많아지고 그 위치도 어떤 것은 AWS같은 클라우드에, 또다른건 데이터센터 등 복잡하다. 이런 과정에서 복잡한 것을 간소화시키고 휴먼에러를 최소화 시키기 위한 것이 자동화라는 것이다.

네번째는 CI&CD(Continuous integration and continuous deployment)다. CI는 신규 기능 개발이나 소스 커밋을 하는 사이에 자동화된 테스트가 진행되는 것을 말한다. 원하는 환경에 배포되기 전까지, CI는 하루 수백번, 수천번도 일어날 수있다. CD는 스테이징 환경 혹은 운영환경까지 소스 커밋된 결과를 배포하는 것이다. 스테이징 환경CI와 CD를 통해 개발 과정과 배포 단계 사이의 일을 테스트하고 모니터링할 수 있다.

CI와 CD를 통해가장 중요한 것은 운영단계에 나가지 말아야 할 것을 사전에 디텍팅하는 기능이다. 기능 테스트는 기본이고 성능이나 보안에서 걸리는 것이 있으면 파이프라인을 통해 그 중간에서 딱 정지가 되게 만들어야 한다. 이것이 잠재적인 해커의 위협을 미리 막는 것이 된다.

다섯번째는 어드밴스드 디플로이먼트 테크닉스(Advanced Deployment Techniques)다. 빠르면서도 안전해야 한다는 얘기다. 오 부장은 하트블리드의 예를 들었다. 2014년에 발견된 버그임에도 불구하고 아직까지 수많은 기업이 엔터프라이즈 환경에서 이에 대한 패치를 해놓지 않았다는 것이다. 이유는 간단하다. 해당 기업들이 아직 해킹 사계가 없거나, 혹은 사내 보안팀이 하트블리드를 모르기 때문이다. 소 잃고 외양간을 고치지 않기 위해서는 CI&CD 기반의 빠르고 안전한 기술 도입이 필요하다고 오 부장은 강조했다.

마지막으로 마이크로서비스다. 개발만 빨리 하는게 중요한 것이 아니라 최종적으로는 운영까지 얼마나 시간을 단축할 수 있느냐 하는 것이 중요하다. 빠른 속도를 위해서는 카나리아(canary)라는 배포 방식을 살펴볼 필요가 있다. 카나리아 배포방식은 수십년전 광부들이 탄광에서 일산화탄소 확인을 위해 카나리아라는 새를 이용한 것에서 유래됐다. 소프트웨어를 개발해서 프로덕션 단계에서 일부에 배포한 다음, 오류가 있다면 재빨리 알아내 심각한 장애를 막겠다는 콘셉트다.

오 부장은 “소프트웨어 배포에 있어 기간 단축이 그 비즈니스를 성장시킬 수 있는지에 대해서 개발자든 운영자든 최선에 대해 고민을 해야 한다”고 말했다. 소프트웨어 배포 단축에 가장 적절한 기간이라는 것은 없어졌다는 취지다.

글. 바이라인네트워크
<남혜현 기자>smilla@byline.network