1. Devops의 개념과 등장배경

1. 개발과 운영

어플리케이션의 시작인 기획단계부터 배포까지의 과정은 다음과 같습니다.

기획, 코딩, 빌드 및 테스트는 개발팀에서 작업을 수행하고, 릴리즈 배포후 모니터링 및 피드백은 IT운영팀에서 업무를 수행했습니다.

즉, 어플리케이션개발과 서비스를 수행하는 주체가 두 팀으로 구분되어 있습니다.

이러한 역할 분담은 다양한 이유로 프로그램의 생산성을 떨어뜨리는 원인이 되었습니다.

예를 들어 배포한 코드에 문제가 있는 경우 이 문제에 대한 책임은 배포한 운영팀과 작성한 개발팀 중 누구에게 책임소재가 있는지 따지게 되면서 문제해결이 늦어 진다 거나, 문제를 해결하기 위해 운영팀에서 문제를 포착한 이 후 개발팀에게 전달될 때 까지 시간이 소요된다는 단점이 있었습니다.

이러한 문제를 해결하기 위하여 등장하게 된 개발방법론, 개발문화가 DevOps입니다.

2. DevOps

출처: https://medium.com/@distillerytech/what-is-devops-here-are-the-core-concepts-you-actually-need-to-know-a7a5b356a881

DevOps는 Development and Operations의 약자로 소프트웨어의 개발과 IT운영을 결합하여효율적으로 제품을 서비스하기 위한 프로세스나 조직문화의 변화를 통틀어 DevOps라고 부릅니다. DevOps문화가 잘 적용된 회사에서는 개발팀과 운영팀이 별도로 나뉘어져 있지 않고 하나의 개발사이클에 한 몸이 되어 협업을 이룹니다.

3. DevOps와 개발방법론

DevOps문화는 시간이 흐륵수록 바뀌는 개발방법론의 변화에 따라 자연스럽게 등장하게 되었습니다. Devops문화가 등장하기 전 2000년대에는 어떤 개발방법론이 유행하였고, 어떤식으로 변화했는지 살펴보도록 하겠습니다.

첫번째로 2000년대 이전 IT시장에서는 WaterFall이라고 불리는 방식의 개발방법론이 유행했으며 현재까지도 다양한 프로젝트에서 사용되고 있습니다.

1) WaterFall

출ㅊㅓ: https://www.instagantt.com/project-management/what-is-waterfall-project-management

WaterFall방식은 개발에 단계를 매기며 각 단계가 완료되기 전까지 다음 단계로 넘어가지 않는 선형적 개발 방법론입니다.

WaterFall방식은 각 단계를 요구사항분석 - 설계 - 개발 - 테스트 - 배포 - 유지보수로 구분하며 완료한 단계에 대해서 반드시 문서화작업을 진행합니다. 한번 다음단계로 넘어가게 되면 이전 단계로 돌아가기 힘들고 돌아가지 않으려는 특징이 있습니다. 이러한 특징으로 기능이나 요구사항 자체가 잘 표준화 되어있는 프로젝트(공기업프로젝트 등)를 진행할 때 WaterFall방식은 자주 선택되는 개발 방법론 입니다. 하지만 이러한 특징은 프로젝트 진행 중에 변경되는 변경사항에 대한 유연함이 부족하다는 단점 또한 포함합니다.

2000년대 이후에는 WaterFall방식의 단점을 보완하는 Agile방식의 개발 방법론이 대두 되기 시작했습니다.

WaterFall방식 개발 예시

어플리케이션의 규모가 방대한 경우 여러 개발자들이 몇 달에 걸쳐 개발 단계를 완료 한 후 이를 하나로 통합(Merge)하게 될텐데 이 때 코드의 통합에만 꽤 많은 시간을 할애해야 하며, 이를 마친 후 테스트 단계로 진입했을 때 프로젝트의 규모가 크기 때문에 전체를 테스트 하는 데에 만 많은 시간이 소요될 것이고 배포단계에 접어들었을 때 갑자기 발생하는 긴급한 오류건을 수정해야 하는 경우 다시 배포가 연기될 수도 있는 등 어플리케이션 배포에 긴 시간이 필요하게 되었으며, 개발자들은 배포시간이 늘어나는 요구사항의 변경에 대해서도 수용하지 않는 입장을 고수하기도 했습니다.

2) Agile

출ㅊㅓ: https://www.linkedin.com/pulse/software-development-agile-model-karthika-rajaram-y6rwc

Agile방식은 프로젝트를 WaterFall방식에 비해 높은 유연성을 가지고 있습니다.

WaterFall방식이 전체 소프트웨어 아키텍쳐를 기준으로 모든 현기능에 대한 계획을 수립하는 방면 Agile방식은 프로젝트를 스프린트(sprint)라고 불리는 여러 조각으로 나누고, 각 스프린트마다 기능을 완성하고 피드백을 받아 개선시킨 후 다음 스프린트를 진행합니다.

개발주기가 WaterFall에 비해 짧고 반복적이기 때문에 변경사항이나 개선점에 대해 훨씬 유연하게 대처가 가능합니다. 이러한 특징으로 Agile방식은 요구사항이 자주 변경되거나 요구사항이 불확실하여 자주 변경되는 현대 프로젝트들에서 자주 사용되는 대세 개발 방법론이 되었습니다.

Agile 선언문과 Agile 12원칙

2001년도에 여러명의 프로젝트 리더들이 모여 발표한 공동 선언문으로 Agile의 기치에 대해 잘 표현하고 있습니다.

<Agile 선언문>

우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를 계약 협상보다 고객과의 협력을 계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

<Agile 12 원칙>

1. 우리는 가치 있는 산출물을 일찍 그리고 지속적으로 전달해서 고객을 만족 시키는 것을 최우선으로 한다.

2. 비록 프로젝트 후반일지라도 요구사항 변경을 환영한다. 애자일 프로세스스는 변화를 고객 경쟁력 강화의 원동력이 되게 한다.

3. 가치 있는 산출물을 자주 전달한다. 두어 주에서 두어 개월의 간격으로 하되 그 기간은 짧을 수록 좋다.

4. 프로젝트에 참여하는 모든 이들은 프로젝트 기간 동안 매일 함께 일해야 한다.

5. 동기가 부여되어 있는 사람들 중심으로 프로젝트 팀을 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 일을 완수할 것이라고 굳게 믿는다.

6. 팀 내부에서 또는 팀에게 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 맞대고 이야기하는 것이다.

7. 진척도를 가장 잘 가늠할 수 있는 척도는 고객에게 가치 있는 산출물 그 자체이다.

8. 애자일 프로세스는 지속가능한 업무 속도를 장려한다. 스폰서, 실무자, 사용자는 일정한 속도를 계속 유지 할 수 있어야 한다.

9. 탁월한 기술과 뛰어난 품질에 대한 끊임없는 관심이 민첩성을 높인다.

10. 단순성이 필수적이다.

11. 최고 품질의 제품 및 서비스는 자기 조직화 팀으로부터 나온다.

12. 팀은 어떻게 하면 더 효과적으로 일할 수 있는지 정기적으로 돌아보고, 그에 따라 팀의 행동을 조율하고 조정한다.

Agile의 한계

Agile은 반복적고 소규모로 자주 코드베이스를 통합하고 배포하는데 초점을 둡니다. 이로 인해 눈에 보이는 결과물을 보여줄 수 있고, 사용자의 피드백을 받아 다음 개발과정에 적용시킬 수 있죠. 즉 애자일 방식의 핵심은 지속통합(CI) 및 지속배포(CD)입니다.

Agile이 대두될수록 CI/CD기술 또한 함께 발전하였고 이로 인해 좀 더 빠르고 효율적으로 CI/CD할 수 잇는 다양한 도구들이 개발되었습니다. 하지만 회사들은 여전히 개발팀과 운영팀이 나뉘어져 있는 상황이었으므로 개발팀이 빠르게 개발을 할수록 이를 담당해야하는 운영팀의 업무 과부화가 발생했습니다.

이러한 문제점을 해결하기 위해 Agile은 DevOps로 진화하였습니다. DevOps에서 개발의 모든 과정에 개발팀과 운영팀이 함께 긴밀히 협업하여 소프트웨어를 개발합니다.