소프트웨어 개발 방법론에 대한 생각들, 데브옵스와 마이크로서비스

직업이 되는 순간 성장동력을 상실한다, 소프트웨어 엔지니어

• 나와 같은 소프트웨어 엔지니어를 직업으로 가진 사람은 대부분 어렸을 때부터 조용한 방에서 컴퓨터로 작은 프로그램을 만드는 성취감에 이끌려 이 세계에 진입한다. 성인으로 성장하여 본격적으로 직업 프로그래머가 되면 대규모의 예산과 인력, 고성능의 컴퓨터 자원이 투입되는 대형 프로젝트를 경험하면서 혼자서 통제가 가능했던 소시적의 소프트웨어 개발과는 차원이 다르다는 것을 깨닫게 된다. 프로젝트가 요구하는 목적과 살인적인 일정에 충실하다 보면 과거에 이 세계에 진입한 동기 그 자체였던 성취감과 호기심은 온데간데 사라지며, 적지 않은 수가 회의감을 느끼고 이 세계를 완전히 떠나기도 한다. 남은 사람들은 행복을 찾아 작은 스타트업 기업을 찾거나, 생존을 위한 이상적인 협업과 방법론에 관심을 갖기 시작한다.

인간보다 월등히 빠른 컴퓨터, 그리고 찾아온 소프트웨어 위기

• 왜 이런 모순적인 일이 발생했을까? 초창기 컴퓨터는 할 수 있는 일이 한정적이었으며 사람들의 기대치도 낮았다. 비교적 간단한 프로그램을 개발하여 실행했고, 따라서 버그가 발생해도 전체 시스템에 끼치는 영향은 사소했다.
• 컴퓨터의 용량과 연산능력이 발전할수록 소프트웨어 개발의 복잡성 또한 기하급수적으로 증가하게 되면서 큰 문제가 발생하게 된다. 이러한 현상에 대한 첫 공식적인 목소리가 바로 1968년의 소프트웨어 위기 선언이다.

개발 방법론의 대두

• 이러한 문제를 해결하기 위해 다양한 소프트웨어 개발 방법론이 등장했다. 가장 먼저 주류가 된 방법론은 워터폴(Waterfall)이다. 워터폴은 완전한 설계도를 보고 차근차근 건축을 하여 집을 완성해 나가는 방식이다. 얼핏 보면 더이상 개선의 여지가 없을 정도로 완벽해보인다. 하지만…

전제부터 잘못되었던 워터폴, 그리고 애자일의 등장

• 이상적으로 완벽해보이는 워터폴의 문제는 완전하다고 여겨졌던 설계도가 시공 중에 계속 변한다는 점이었다. 완벽하게 고정된 요구사항이라는 불가능한 전제의 오류를 가지고 있었던 것이다. 그리고 2001년, 애자일(Agile)이 등장한다. 애자일은 요구사항이 빈번하게 바뀔 수 있다는 전제하에 바뀐 요구사항에 대한 빠른 수용을 목표로 하여 선풍적인 인기를 끌었다. 또한 애자일을 실현하기 위한 체계화된 수단으로서 스크럼(Scrum) 등의 방법론이 유행하게 된다.

개발과 운영을 격리하자 소프트웨어가 산으로 가다

• 애자일로 지속적으로 변경되는 요구사항을 적절하게 개발에 녹일 수 있게 되었다. 이제 우리 모두 고통에서 해방된 것일까? 애자일은 소프트웨어를 소유주에게 납품하는 것에 모든 것을 집중한다. 관리되지 않는 집이 폐가가 되는 것은 시간 문제일 뿐이다. 애자일은 소프트웨어 납품 이후의 운영 측면을 간과했고 아이디어 선점이 생존을 결정하는 현대의 IT 시장에서는 보다 적극적이고 능동적인 방법론이 요구되기 시작한다.
• 한편, 잠시 내 이야기를 하자면 경험이 부족한 PM이 초기 단계에서 나왔어야할 중요한 요구사항을 뒤늦게 추가한 후 이 것이 바로 애자일이라고 주장하며 자신의 부족한 역량과 실수를 정당화하고 일정 지연으로 인한 야근을 강요하는 모습을 수도 없이 경험하면서 나는 이제 애자일 글자만 봐도 본의 아니게 인상부터 찌푸려진다. 대한민국에서 애자일이란 용어는 무능한 비실무자들이 자신을 보호하는 마법의 단어로 남발되고 있다.

데브옵스, 현재 가장 진보된 소프트웨어 개발 문화

• 데브옵스(DevOps)는 실리콘 밸리를 중심으로 유행하여 전세계에 퍼지고 있는, 현재 IT 분야에서 가장 진보된 소프트웨어 개발 문화 또는 방법론이다.
• 데브옵스는 소프트웨어 개발과 운영을 따로 보지 않는다. 개발 조직과 운영 조직이 물리적으로 격리되지 않는 환경에서 개발, 테스트, 배포, 운영에 이르는 전체 생명주기를 서로 긴밀하게 통합하여 관리한다. 아이디어가 배포까지 이어지는 속도도 빨라진다.
• 앞서 애자일을 실현하기 위한 수단으로 스크럼이 나왔다면 데브옵스를 실현하기 위한 수단으로서 필연적으로 마이크로서비스(Microservice)가 나오게 된다.
• 마이크로서비스는 말그대로 전통적인 거대한 덩치의 애플리케이션을 잘게 쪼개는 것이다. 오래됬지만 직관적이고 효과적인 Divide and Conquer 전략과 같은 가치관을 공유한다. 쪼개서 집중하면 많은 문제가 자연스럽게 해결된다. 새로운 기술의 도입도, 고가용성과 무중단에 대한 고민도, 장애가 났을 때의 대처도 모두 비교할 수 없이 수월해진다.
• 마이크로서비스 구축에 앞서 무엇보다 선행되어야할 것은 바로 마이크로팀의 구축이다. 나는 과거 2명에 불과한 마이크로팀으로 1년이 넘는 프로젝트를 성공적으로 런칭시킨 경험이 있다. 소프트웨어 엔지니어로서 내가 애플리케이션 설계와 구축을 전담하고, 시스템 엔지니어이자 엔지니어링 매니저 역할을 담당하는 동료가 인프라와 팀 외부와의 의사소통을 전담하여 2인 구성으로 각자의 역할에 집중하여 마이크로서비스를 성공적으로 구축하였고, 해당 서비스는 현재도 국내에서 매우 유명한 이커머스 서비스의 핵심 서비스로 작동하고 있다. 전통적인 10인 이상의 거대하고 수직적인 위계질서의 팀에서는 마이크로서비스를 고려하기에 앞서 팀 리빌딩부터 해야한다는 것이 내 생각이다.
• 데브옵스 문화에서는 개발자는 건축가 보다는 정원사처럼 일하는 것이 권장된다. 마이크로서비스로 쪼개서 작아진 소프트웨어 덕분에 전체 프로세스를 관리할 수 있게 되어 끊임 없이 실수를 수정하고 새로운 기술과 아이디어를 녹일 수 있는 것이다.
• 데브옵스는 적절한 도구들을 적재적소에 활용함으로서 퍼포먼스를 극대화할 수 있다. Git, Docker, Slack, JIRA, Confluence 등의 도구가 여기에 해당한다. 이러한 도구의 발전은 규모가 작은 팀에게 있어 과거에는 불가능했던 많은 일을 가능하게 해주고 있다.

참고 글

• How are DevOps and Agile different?
• 애자일 스크럼은 생각보다 어렵다
• 잘 가요 스크럼, 반가워요 칸반
• 애자일 방법론의 어두운 비밀, IT에서는 거의 사용할 일 없다
• 왜 애자일, 특히 스크럼이 끔찍한가.
• 애자일 실패를 초래하는 7가지 실수
• 전직 CIO에게 듣는 디지털 변혁에 데브옵스가 필요한 이유
• 2018년 주류 데브옵스, 오픈소스가 주도
• 데브옵스와 마이크로서비스
• 데브 옵스로 경쟁사보다 30배 많은 코드 배포를 경험하다
• 애자일 및 DevOps: 친구인가 적인가?
• 데브옵스 잘 하려면 디테일에 집중하라
• 애자일 개발의 지휘자, 스크럼 마스터의 이해

추천 도서

• The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win