[Rookies 개발 2기] DevOps 개념과 도구 (2)

DevOps의 기원

DevOps라는 용어는 2009년에 Patrick Debois와 Andrew Clay Shafer가 벨기에의 Agile 컨퍼런스에서 "Agile Infrastructure"라는 주제로 발표하면서 처음 소개  되었다.

 

DevOps는 개발(Development)과 운영(Operations)의 합성어로, 두 팀 간의 협업을 강화하여 소프트웨어 개발 및 배포 주기를 단축하고 품질을 향상하기 위해 사용된다.

단절된 개발과 운영간의 프로세스를 경계 없이 연결하고 자동화 방법을 통해 효율성을 극대화하는 일종의 방법론이자 문화이다.

 

과거에는 신규 서비스를 출시하기 위해 코드 개발 및 테스트에 매우 많은 시간을 투자하여 오랜 시간이 걸리고, 한 번에 오류 없이 사용자에게 안정적인 서비스를 제공하기 위해 사전 연습을 끊임없이 반복하는 느낌이라면,

현재에는 매우 빠른 속도로 서비스를 출시하고, 그에 맞춰 업데이트 주기도 매우 빈번해졌다. 먼저, 사용자에게 기본 서비스를 제공하고 빈번한 업데이트로 차례차례 서비스를 완성해 나가는 방향으로 바뀌게 되었다.

 

그렇기에 현재 대부분 기업에서는 기존의 단점을 상쇄하고 효율적으로 서비스를 운영하기 위해 DevOps를 적용한다.

 

DevOps의 핵심요소

첫번재는 문화(Culture)이다. 개발, 운영 두 팀의 경계를 허물고 협업을 하여 서비스 품질을 높이는 문화가 요구된다.

사일로란 굴뚝 모양의 곡식창고로 각각의 내용물만 저장한다. 비슷하게 팀 안에서만 소통하고 팀 내 이익만 추구하는 상황과 팀 별 데이터가 통합되지 않아서 회사 전체의 인사이트를 얻을 수 없기에 협업등을 통해 조직의 Silo(사일로) 화 되는 것을 막아야 한다.

 

두 번째는 자동화(Automation)이다. 개발자가 소스 코드를 작성하는 과정부터 사용자에게 서비스를 배포하는 과정까지의 전 과정을 모두 자동화된 프로세스로 관리하는 것을 의미하며 이는 서비스 품질 검사 및 모니터링도 포함된다.

 

세 번째는 측정(Measure)이다. 측정된 데이터는 투명해야 하며, 조직 내 누구나 접근이 가능하고 시각화를 통해 한눈에 파악할 수 있어야 한다.

 

네 번째는 공유(Share)이다. 개발 및 운영 노하우를 조직 전체에 공유를 통해 장애 예방 및 조직 전체의 기술 역량을 강화할 수 있다. 다양한 협업 도구 활용하여 중복 작업 제거 및 참여 유도를 이끌어 내야 한다.

 

DevOps의 기본 요소와 개념은 알겠다. 그렇다면 왜  필요할까?

 

DevOps의 필요성

DevOps의 주요 필요성 및 사용 이유는 아래와 같이 크게 4가지로 나뉜다.

 

1. 속도와 효율성 : DevOps는 자동화된 배포 파이프라인을 통해 소프트웨어를 빠르고 안정적으로 릴리즈

2. 품질 보증 : 지속적인 통합(CI)과 지속적인 배포(CD)를 통해 코드 변경 사항을 빠르게 테스트하고 배포함으로써 품질을 보장

3. 협업 증진 : 개발자와 운영 팀 간의 긴밀한 협업을 통해 문제를 조기에 발견하고 해결

4. 비용 절감 : 자동화를 통해 반복적인 수작업을 줄이고, 인프라 효율성을 높여 비용을 절감

 

그렇다면 이를 실현하기 위한 대표적인 예를 살펴보자.

 

버전관리(Version Controll System)

 

먼저, VSC (Version Controll System)이다. 이는 말 그대로 버전관리 시스템이며 동일한 정보에 대한 여러 버전을 관리하는 것을 말하는데 공학과 소프트웨어 개발에서 팀 단위로 개발 중인 소스 코드나, 청사진 같은 설계도 등의 디지털 문서를 관리하는 데 사용된다.

버전을 통해서 시간적으로 변경 사항과 그 변경 사항을 작성한 작업자를 추적할 수 있다.

간단한 버전 관리 방법으로는 처음 작성한 코드에 버전 번호 1을 부여한다. 변경 사항이 생기면, 버전 번호를 2로 증가시킨다. 이처럼 추후 변경 사항이 발생 시마다 버전 번호를 1씩 증가시킨다.

 

그렇다면 왜 버전관리가 필요할까?

 

다들 학창시절이나  대학생 때 이런 경험 있었을 것이다. 이렇게만 저장한다면 나중에는 뒤죽박죽 섞여 수정 전 파일을 들고 가다 낭패를 본 일 말이다.(필자는 그런 경험이 없다.)

 

이를 방지하기 위해 파일 수정사항 발생 시 파일명에 version 번호가 증가하도록 저장하고 vX.X 가 최신 버전으로 파일을 관리한다. 이는 프로젝트 진행 중 과거의 어떤 시점으로 돌아갈 수 있게 하기 위해서도 있고, 여러 사람이 프로젝트에 참여할 경우, 각자 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화하기 위하여 사용되며 소스코드의 변경사항, 누가 수정했는지, 특정 부분이 왜 그렇게 쓰여졌는지 의미등을 추적하기 위해 사용한다.

 

다음은 용어에 대해 알아보자.

 

• Baseline (베이스라인): 계속 변경된 문서 또는 소스파일의 승인된 리비전, 변경되는 문서 또는 소스파일이 시작되는 시작 지점
• Revision (리비전): 버전 관리의 특정 시점을 의미
• Branch (브랜치): 특정 시점에 Baseline 으로 부터 분기된 독립적인 작업
• Check-out (체크아웃): 특정 Local 작업본을 생성하며, 특정 리비전을 명시할 수 있음
• Commit(커밋): 작업본에 변경이 있거나 저장소 병합 시 발생하는 이력을 남기는 작업
• Conflict(충돌): 동일한 문서에 서로 다른 변경사항이 있는 경우 발생하는 사항
• Merge(병합): 특정 시점에 Baseline 으로 부터 분기된 독립적인 작업

 

형상관리(Configuration Management)

소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다.

 

버전관리는 형상관리의 한 부분으로, 형상관리의 핵심 구성 요소 중 하나이다.

 

SVN(Subversion)

SVN(Subversion)은 오픈 소스 중앙집중형 버전관리 시스템(Centralized Version Control System, CVCS)이다.

Apache Software Foundation에서 관리하고 있으며, CVS(Concurrent Versions System)의 단점을 보완하기 위해 개발되었다.

중앙 서버(Repository)에서 모든 버전을 관리하고, 클라이언트는 서버에서 파일을 받아 작업하며, 개발자들은 Checkout으로 코드를 내려받고, 수정 후 Commit을 통해 중앙 저장소에 반영한다.

 

 

Git

소스코드의 이력을 관리하는 분산 버전 관리 시스템이며 Github는 Git 저장소를 관리하는 웹 호스팅 서비스이다. 현재 MS사의 75억 달러(약 8조 원)의 거대한 가격으로 인수 합병 되었다.

Git은 중앙 서버뿐만 아니라 각 개발자의 로컬 컴퓨터에도 전체 프로젝트의 이력(history)과 파일이 저장된다.

오프라인 상태에서도 버전 관리가 가능하며, 커밋(commit)은 로컬 저장소에서 이루어지고, 필요할 때 원격 저장소에 푸시(push)한다.

 

Git과 GitHub는 밀접하게 관련이 있지만, 본질적으로 다른 개념이다. 많은 사람들이 두 개념을 혼동할 수 있기 때문에, 차이점을 명확히 이해하는 것이 중요하다. 결론은 Git은 코드 버전 관리 시스템이며, GitHub는 이를 호스팅하고 협업을 돕는 서비스다.

 

자 그렇다면 SVN 또는 Git을 통해 다른 사람들과 협업하려면 기준을 정해야 한다.

 

브랜치 전략(Branching Strategy)

브랜치 전략은 팀원들이 작업할 때 각자의 작업을 어느 브랜치에서 진행할지를 정하는 규칙이다. Git과 SVN에서 모두 중요한 부분이며, 팀의 협업 방식에 따라 적절한 브랜치 전략을 선택해야 한다.

 

Git Flow

가장 전통적으로 많이 사용되는 방식이며 아래는 흐름에 대한 설명이다.

 

`feature` 브랜치를 `develop` 브랜치에서 분기하여 기능을 개발한다. 작업이 완료되면 `feature` 브랜치를 `develop` 브랜치로 병합한다.

여러 기능 개발이 완료되면, `develop` 브랜치에서 `release` 브랜치를 분기한다. `release` 브랜치에서 배포 준비 작업(버그 수정, 테스트)을 진행한 후 `release` 브랜치를 `master`와 `develop` 브랜치에 병합한다. 그 후 `master` 브랜치에서 배포 작업이 이루어진다.

 

글자로만 보면 어지러우니 아래 사진을 보자.

 

Git Flow 사용 시 장점으로는 브랜치가 어떤 목적으로 사용되는지 명확하게 구분되어 협업이 수월하며 각 개발자는 feature 브랜치에서 독립적으로 작업할 수 있으므로 충돌을 최소화할 수 있다.

 

GitHub Flow

이는 더 간단한 전력으로 브랜치를 하나의 `master`브랜치와 `master` 에 기능을 추가하기 위한 `feature` 브랜치 두 개만으로 운영하여 훨씬 간단하지만 빠르게 수정 배포할 수 있는 전략이다.

 

 

Git Flow는 더 많은 제어와 복잡성을 가지고 있어 특정 기능이나 수정을 빠르게 배포해야 할 경우 등에서 유연성이 다소 떨어진다. 그러나 그만큼 배포 안정성과 버전 관리 및 롤백 등 체계적인 운영이 가능하다.

 

GitHub Flow 는 테스트와 검증 절차를 거치지 않고 바로 master 브랜치로 Merge 되므로 위험성을 가지고 있지만  그만큼 단순하고 빠르게 기능을 테스트하고 Agile 하게 배포할 수 있기 때문에, 주로 각 환경의 구분이 명확하지 않고 작은 규모의 프로젝트에 적합한 전략이다.  팀의 규모와 프로젝트에 맞는 전략을 선택하는 것이 중요할 것이다.