많은 IT 조직이 데브옵스를 도입했거나 도입 검토 중에 있습니다. RightScale의 연구에 따르면 DevOps의 원칙의 일부 측면을 채택한 기업의 비율은 2017년에 84%에 달한다고 합니다. 어쩌면 데브옵스는 너무나도 자연스러운 흐름의 하나가 될지도 모르겠습니다. 하지만 데브옵스가 어떻게 시작했는지에 대한 이야기는 잘 알려지지 않은게 현실이죠.
데브옵스는 개발자와 운영자의 소통, 협업 및 통합을 강조하는 문화, 방법론, 프로세스, 도구 모두를 의미하는데, 이렇게 정의의 폭이 넓은 것은 데브옵스의 시작이 개발팀과 운영팀 간의 충돌로 인한 문제 해결이기 때문입니다.데브옵스를 누가 어떻게 시작했는지 알게 된다면 데브옵스의 정의를 이해하는데 도움이 될 것입니다.
데브옵스 이전
1990년대는 기존의 대규모 개발에 대한 반작용으로 경량화 된 개발 방법론이 발전되었습니다. 1991년에는 빠른 애플리케이션 개발 방법인 RAD가 나왔으며 1995년에는 스크럼 개발 방법이 나왔습니다. 1996년에는 극단적인 프로그래밍 방법론을 의미하는 XP 가 발표되었습니다. 이 방법론들은 향후 애자일 선언에 많은 영향을 끼치게 됩니다.
2001년 17명의 소프트웨어 개발자들이 유타에 있는 스노우버드 리조트에 모였습니다. 이들은 경량화 된 개발 방법론에 대해서 논의했는데, 여기에서 애자일 소프트웨어 개발을 위한 선언문을 발표했습니다. 17명의 소프트웨어 개발자 중에는 Kent Beck, Ward Cunningham, Jeff Sutherland, Ken Schwaber, Jim Highsmith, Alistair Cockburn, Bob Martin 과 같은 희대의 개발자들이 포함되어 있습니다.
애자일은 소프트웨어의 운영이 아닌 개발 방법에 대한 논의였습니다. 2000년대 중반을 넘어오면서 소프트웨어는 시장이 웹 서비스로 넘어가면서 소프트웨어는 개발만큼이나 안정적인 운영이 중요해졌죠. 안정적인 운영은 개발의 속도를 늦추기 시작했고, 빠른 개발을 선호하는 문화는 안정적인 운영에 방해가 되면서 개발팀과 운영팀의 골은 점점 깊어져만 갔습니다.
데브옵스 시작
2007년 애자일 방법론을 기반으로 프로젝트를 관리하는 IT 컨설턴트 Patrick Debois는 국가에서 진행하는 데이터센터 이전 프로젝트를 지원합니다. 그의 역할은 인증 및 테스트 준비에 관련된 것이었죠. 이 역할은 애플리케이션 개발팀과 운영팀(서버, 데이터베이스, 네트워크) 모두와 협업을 해야 했습니다. 이 작업을 진행하면서 그는 개발팀과 운영팀이 결코 좁혀지지 않는 간격을 가지고 있다는 것을 알게 되었고, 이 문제를 해결할 방법을 고민하기 시작했습니다.
2008년 Andrew Schafer는 토론토에서 열리는 애자일 컨퍼런스에서 “애자일 인프라스트럭쳐”에 대해 토론하는 “Birds of a Feather” 미팅을 진행하자고 제안을 올립니다. 아무도 관심을 주지 않았던 주제였지만 Patrick Debois는 이 주제에 관심을 가질 수밖에 없었습니다. Shafer와 Debois는 토론을 통해 “애자일 시스템 관리” 개념을 발전시키고 구글에 애자일 시스템 관리 그룹을 만듭니다.
다음해 오렐리 밸로시티 컨퍼런스에서 플리커의 John Allspaw와 Paul Hammond는 데브옵스의 개념을 설명하는 최초의 시도라 할 수 있는 “10+ Deploys per Day: Dev & Ops Cooperation at Flickr” 를 발표하였습니다. Allspaw와 Hammond는 소프트웨어 배포 중에 발생하는 개발팀과 운영팀의 역할을 연기하였습니다. 서로 상대방을 손가락질하며 “내 코드가 문제가 아니라고, 너의 장비가 문제인 거야” 라며 비난하는 프레젠테이션은 많은 이들에게 공감을 얻습니다. 이 프레젠테이션을 통해 사람들은 개발팀과 운영팀이 투명하고 완벽하게 통합되어야 한다는 생각을 가지게 되었습니다.
벨기에에서 사는 Debois는 미국에서 열린 컨퍼런스에 참석하지 못했지만 비디오 스트리밍을 통해 Allspaw와 Hammond의 프레젠테이션을 보았습니다. 프레젠테이션을 통해 영감을 얻은 그는 벨기에 겐트에서 Devopsdays 컨퍼런스를 만들었습니다. 이때부터 공식적으로 “DevOps”라는 단어가 쓰이게 되었습니다.
데브옵스의 도구들
데브옵스가 확산되면서 개발팀과 운영팀이 빠르고 안정적으로 애플리케이션을 개발하고 운영할 수 있도록 도와주는 다양한 도구들이 나오기 시작합니다. 이 도구들은 프로세스를 자동화 해 줄 수 있으며 개발팀과 운영팀이 함께 사용 가능한 특징을 가지게 되었습니다.
대표적으로는 Puppet, Chef와 같은 구성 및 설정 관리 도구가 있습니다. 모니터링 분야도 데브옵스의 핵심 도구로 자리잡았는데, 이는 SaaS 형태의 모니터링 서비스들이 제공되면서 개발과 운영이 같이 사용할 수 있는 환경이 마련되었기 때문입니다.
관련 URL
https://devops.com/the-origins-of-devops-whats-in-a-name
https://conferences.oreilly.com/velocity/velocity2009/public/schedule/detail/7641
개발자와 운영자가 위치와 업무에 상관없이
볼 수 있는 멀티테넌트 기능을 가진 강력한 데브옵스 툴
와탭 무료로 시작하기
- Becky([email protected])
- Marketing TeamManager