|
IT 분야에서 오랫동안 문제로 지적된 것이 사일로(Silo)다. 이는 단순히 인프라 영역에서만 발생하는 문제가 아니라 조직 내에서도 발생한다. 개발자와 운영자는 한 그룹 내에 속해 있어도 소통이 원활하지 못하는 경우가 대부분이다. 각자 자기 일에만 충실하면 된다고 생각할 뿐이며, 이로 인해 원활한 협업이 이뤄지지 못하는 경우가 많다.
김현수 한국레드햇 시니어 솔루션 아키텍트는 “개발자와 운영자의 협업이 원활히 이뤄지지 않다보니 상호 유기적으로 연계돼야 할 양쪽의 업무가 충돌하기도 한다. 가령 개발자가 금요일 오후 5시에 작업 결과물을 운영자에게 넘겨주면, 운영자 입장에서는 괴로운 생각부터 들 것이다. 퇴근을 앞둔 시간에 전달받았기 때문에 이를 테스트하고 배포까지 하려면 늦은 시간까지 업무를 해야 하기 때문”이라며 “만약 한 번에 정상적으로 기능이 동작하면 문제가 없겠지만, 에러가 발생하면 이를 해결하는데 오랜 시간이 걸리며 개발자를 원망하게 된다. 반대로 서비스가 원활히 제공되지 못하면 개발자 입장에서는 운영자가 잘 못했기에 발생했다고 생각할 수 있다. C레벨에서 협업을 강조하더라도 이 같은 문제점을 해소시켜주지 않는 이상 같은 현상이 되풀이될 수밖에 없다”고 설명했다.
데브옵스의 목적은 이처럼 개발자와 운영자의 협업 부재로 인한 비효율성을 막고 빠르게 서비스가 배포될 수 있도록 하는 것에 있다. 개발자는 운영 업무에 대해 잘 모르고, 운영자 역시 개발 업무에 대한 이해도가 부족하다 보니 툴을 활용해 서로 간의 간극을 메꿔나갈 수 있도록 하는 방안들이 등장했다.
대표적인 것이 자동화다. 그동안 개발자는 개발만 담당하며, 운영자는 테스트부터 배포까지 진행했다. 그러나 자동화를 통해 개발자들이 직접 테스트를 진행하고 배포까지 담당하며, 운영자는 테스트나 배포 과정이 잘 이뤄질 수 있도록 인프라와 플랫폼만 받쳐주면 되는 방식이다.
이에 대해 개발자가 해야 하는 일이 더 많아진다며 문제를 제기하는 경우도 있다. 물론 지금까지 운영자들이 소프트웨어를 배포하는 역할을 해왔지만, 본질적으로는 서비스가 정상적으로 동작할 수 있도록 서버, 스토리지, 네트워크 등의 인프라를 잘 관리하고 운영하는데 있다. 실제로 운영자가 테스트를 진행하는 것은 해당 서비스가 정상적으로 동작하느냐 아니냐의 여부만 확인하는 것일 뿐, 개발자의 의도대로 서비스가 동작하는지의 여부까지 확인하기에는 무리가 따른다.
IT 역량 내재화 위한 모델 부족
그동안 소프트웨어가 핵심 역량이 아니었던 기업들은 비용절감의 목적으로 IT를 아웃소싱 했었지만, 지금에 이르러 소프트웨어 역량이 중요해지면서 아웃소싱 했던 IT 역량을 다시 자체적으로 구축할(Insourcing) 필요성이 생겼다. 이를 성공적으로 해내는 것이 최근 많은 이슈가 되고 있는 디지털 전환이다.
이 같은 관점에서 보면 현재 대기업들에서 디지털 전환을 원활히 하지 못 하는 이유를 두 가지로 풀이할 수 있다. 하나는 아웃소싱을 했던 IT를 다시 인소싱해야 하는데, 이를 달성한 바람직한 모델을 찾기 힘들다는 것이며, 또 다른 하나는 기업이 IT 역량 내재화를 위한 새로운 조직을 만드는 것이 쉽지 않다는 것이다. 이는 큰 기업일수록 더 어렵게 느낀다. 해야 할 필요는 있지만 구현을 어떻게 해야 하는지 모르기 때문에 어려움을 겪는다.
정윤진 피보탈 수석은 “실제로 한 기업에서는 C레벨의 판단으로 데브옵스 팀을 만들었다. 데브옵스 A팀, 데브옵스 B팀 등으로 지정하고 업무를 맡겼지만, 해당 팀원들을 인터뷰해보면 대부분 자신들이 하는 일에 대해 ‘데브옵스가 아니다’라고 여겼다”며 “이는 팀을 구성하는 방법이나 조직에서 사용하는 프로세스 등이 기존 산업 도메인의 역량을 많이 받았기 때문이다. 제조 산업에서는 제조 산업만의 문화가 있다. 가령 특정 사업 하나를 선택해서 많은 투자를 단행하고, 그것이 성공하게끔 만드는 것 등이다. 이는 소프트웨어 문화와는 맞지 않으며, 이전까지는 지원 조직에 불과했기 때문에 핵심 사업 역량과 연계해 진행하기가 힘든 것이 대부분의 기업들에서 겪는 문제”라고 설명했다.
실제로 기업들에서도 데브옵스 이야기는 화두가 되고 있으며, 일부 기업들은 데브옵스 사업팀이 있다고 이야기하기도 한다. 그렇지만 동작하는 서비스의 다운타임은 어떤지, 해당 서비스를 위한 소프트웨어가 어떻게 만들어지는지, 원하는 속도로 서비스가 이뤄지고 있는지, 결과물을 모니터링하면서 피드백은 주기적으로 하고 있는지 등을 확인해보면 막상 해봤지만 잘 안 됐다는 식의 반응들을 내보인다는 것이 업계 관계자들의 공통된 지적이다.
데브옵스 위한 개발 문화·업무 프로세스 정립 필요
앞서 언급한 내용들을 다시 한 번 정리하면 기업들은 데브옵스를 어떻게 적용해야 하는지 잘 모르는 경우가 대부분이며, 특히 기업들이 가진 IT 관련 업무 프로세스가 핵심이 아닌 지원에 포커스 돼 있다는 이유로 인해 데브옵스를 구현하지 못하는 것으로 풀이된다.
뿐만 아니라 IT 인프라를 구매하는 비용은 전기세처럼 처리할 수 없는 프로세스이기 때문에, 디지털 전환에 필요한 클라우드를 이용하면 월비용이 얼마나 나올지 담당자들은 전혀 예상하지 못한다. 이로 인해 담당자 입장에서는 IT 인프라를 구매할 때도 저항감 때문에 어떻게 해야 할지 혼란해하는 경우도 많다.
데브옵스는 일의 ‘방법’이지만 그 실체를 정확히 모른 채 조직 이름만 바꿔 시행하려 하니 제대로 동작할 리가 없다. 여기에 인프라를 코드로 쓸 수 있다는 이야기를 예로 드는 일부 벤더들의 목소리도 한 몫을 하고 있다. 그러나 이는 데브옵스와 같은 효과를 제공하는 기술이지, 개발 문화나 업무 프로세스를 만들어주지는 못 한다는 한계를 갖고 있다.
중요한 것은 특정 조직을 지정해서 프로세스를 할당하는 것만이 아니라 개발해야 하는 서비스에 대해 서로 다른 역할을 가진 전문가들이 하나의 팀을 구성하는 것과 이를 지속적으로 유지해나가는 것이다. 같은 주제를 대할 때도 이해도가 높은 사람과 그렇지 않은 사람들이 있을 수 있지만, 함께 공부하면서 같이 일을 처리해야 한다.
피보탈은 피보탈 랩을 통해 데브옵스를 구현하려는 기업들을 위한 개발 문화와 프로세스를 전파하는 역할을 수행하고 있다. 좀처럼 모이기 힘든 개발자, 디자이너, 제품 관리자, 인프라 운영 담당자들을 한 곳에 모아서 피보탈 랩 연구원들과 함께 업무를 처리하며 협업 환경에 익숙해질 수 있도록 프로젝트를 진행한다.
이들은 매일 서로 다른 역할을 가진 사람들끼리 쌍(Pair)을 이뤄 업무를 수행하는데, 각 업무를 준비하는 환경에 대해 검색이 아니라 서로 간의 대화와 화면 공유를 통해 지식을 얻어가는 경험을 하게 된다. 이 같은 과정을 거치게 되면 특정 기능을 구현하기 위해 어떤 SQL 쿼리를 썼는지 등을 공유하면서 전체적인 업무의 프로세스를 이해할 수 있게 된다.
또한 팀원 간 쌍은 매일 변경된다. 오늘은 개발자가 디자이너와 일을 했다면, 내일은 개발자와 제품 담당자가 함께 일을 하게 된다. 이런 훈련이 됐을 경우 구성된 팀은 하나의 서비스 전체를 담당하게 되며, 서로 다른 역할을 가진 사람들도 서비스를 운영할 수 있게 된다. 이 과정에서 협업하는 훈련도 중요하지만, 실제로는 사업에 필요한 결과물을 만들어내는 과정을 학습하게 된다는 점에 의의가 있다.
빠른 시장 검증 통한 비즈니스 유연성 확보
피보탈 랩스에서 데브옵스를 적용해 소프트웨어를 만들 때는 처음부터 완성된 제품을 목표로 개발하지 않는다. 우선적으로 소프트웨어를 만드는데 필요한 프로세스나 스펙 정리, 이용층 등에 대해 먼저 정리하고, 이후 최소한의 필요 기능이 갖춰진 제품(MVP)을 먼저 만들게 된다. 이후 해당 기업 팀원들과 피보탈 랩스 연구원들이 함께 본격적인 제품 개발에 돌입한다. 이렇게 개발을 시작했을 때는 첫 배포용 소프트웨어가 8~12주 안에 나오게 된다.
이를 통해 개발한 소프트웨어는 시장 반응을 빠르게 확인할 수 있다는 장점이 존재한다. 이렇게 출시된 소프트웨어의 성과가 꼭 좋아야 할 필요는 없다. 좋으면 이를 좀 더 발전시켜 나가면 되는 것이고, 그렇지 못하면 과감히 사업을 정리하고 다른 사업을 추진하면 되기 때문이다. 이처럼 해당 소프트웨어의 개발을 지속할지 아닐지의 여부까지 빠르게 판단 가능하기 때문에 기업 비즈니스 방향에 있어 민첩성과 유연성을 제공하게 된다.
그동안 많은 기업들이 해오던 소프트웨어 개발 방식에 의하면 일반적으로 첫 배포용 제품이 나오기까지 빨라도 반년, 늦으면 1년 이상 걸리는 경우가 대부분이었다. 이는 시장에서 검증받는 속도도 느릴뿐더러, 제품이 출시될 때까지 들어가는 비용도 많이 소모될 수밖에 없다. 또한 오랫동안 추진해온 사업이기에 시장 반응이 좋지 않더라도 당분간 더 추이를 지켜보며 검증을 위한 비용을 추가적으로 지출하는 경우도 다반사다.
이 같은 과정을 거치고 나면 팀원들에게는 새로 도전해보고 싶은 아이디어와 목표가 생기게 되며, 이들이 기업으로 돌아가 내부에서 이 같은 과정을 전파하게 되면 스스로 할 수 있겠다는 구성원들의 규모가 갖춰지게 된다.
점진적인 기능 개선 도모
그동안 많은 기업들의 소프트웨어 프로젝트는 자동차를 만드는 것에 비유된다. 문제는 단계를 거치기보다 처음부터 자동차를 만들려고 한다는 점에 있다. 일단 바퀴와 차체를 만들지만, 그것만으로는 자동차가 될 수 없다. 엔진, 제동장치, 조향장치 등 자동차가 제 기능을 다 할 수 있도록 하는 다양한 기능과 부품들을 필요로 한다. 그렇기에 자동차 완제품을 만들기까지 많은 시간이 걸린다.
하지만 배포되지 않은 제품은 가치가 ‘0’에 불과하다. 그 사이 연구개발(R&D)비용이나 생산비용 등은 꾸준히 발생한다. 이에 중요한 것이 MVP를 먼저 만들어내는 것이다.
자동차를 만든다고 기획은 했더라도 처음부터 자동차를 만들기보다 이동수단에 대해 정의하고 MVP에 해당하는 간단한 킥보드를 만들기는 쉽다. 이후 시장에 내놓고 반응을 보면 이를 지속적으로 판매할지 말지를 판단할 수 있게 된다.
만약 시장에서 반응이 좋다면 사업을 지속하면서도 추가적인 기능 개선을 할 수 있다. 단순히 사람의 힘만으로 달리는 것이 아니라 배터리를 이용한 동력을 추가하고, 한층 속도가 빨라지면서 속도계와 제동장치를 달고, 한 사람뿐만이 아니라 다른 사람도 이용할 수 있도록 하기 위해 크기를 키우고 하는 과정을 거치면 어느 순간 자동차가 완성된다.
중요한 것은 첫 과정이다. 처음부터 최종 목표를 만드는 것이 아니라 최종 목표를 위해 필요한 것들을 갖춰 나간다는 개념으로 진행할 필요가 있다. 한 번의 과정이 끝나면 피드백을 취합해 반영하고, 그러면서 기능을 확대해 나간다. 해당 과정을 반복하게 되면 점점 더 짧은 기간 내 새로운 기능들이 추가될 수 있고 지속적인 배포도 가능해진다.
| |
 |
|
| ▲ 아마존은 수시로 업데이트를 진행하며 사용자 경험을 향상시키는데 주력하고 있다. 5자리 우편번호 시행 후 국내 사이트에서 반영되지 않았을 때도 아마존은 이를 재빠르게 반영했다. |
한 업계 관계자는 “지난 2015년 국내 우편번호가 6자리에서 5자리로 개편됐다. 이전부터 홍보가 진행됐었지만 여전히 사람들은 익숙한 6자리 우편번호 사용을 선호했으며, 국내 많은 인터넷 쇼핑몰들도 6자리 우편번호를 제공했다. 그러던 어느 날 아마존에서 물건을 구매할 일이 있어 주문하다가 6자리 우편번호 입력이 되지 않는 문제가 있었고, 서포트 팀에 문의했더니 국내에서 우편번호가 5자리고 바뀐 것을 반영했기에 5자리 우편번호를 입력해야 한다는 답변을 받았다. 아마존은 이미 국내에서 발생하는 사업적 요건을 알고 다운타임 없이 주소 등록 체계를 바꿨지만, 국내 유명 쇼핑몰들은 아직 반영되지 않았었다”고 말했다.
그는 이어 “물론 기존 고객들의 인식 및 호환성 문제 때문에 반영이 늦어졌을 수도 있지만, 아마존은 해외에 있으면서도 국내 소비자들을 신경 쓰고 불편함이 없다록 기능을 업데이트 한 것이다. 하루에도 몇 번씩 이러한 업데이트가 진행되는가가 궁극적으로는 굉장한 경쟁력을 갖추는 길”이라고 강조했다. |
y1333@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
