Close

DevOps를 실행하는 방법

DevOps를 구현하려는 팀을 위한 단계별 가이드

Krishna Sai의 얼굴 사진
Warren Marusiak

선임 기술 에반젤리스트


도구와 워크플로로 인해 소프트웨어 개발 수명 주기가 복잡합니까? 팀과 프로젝트가 사일로화되어 있습니까? 이러한 질문 중 하나라도 '예'라고 대답한 경우 DevOps를 고려하기에 아주 좋은 시기입니다. DevOps는 새로운 소프트웨어 개발 에코시스템을 만들어 개발 및 배포 워크플로를 단순화하고 최적화하는 데 도움이 됩니다.

하지만 DevOps를 어떻게 구현할까요? DevOps의 주요 어려움 중 하나는 팀마다 요구 사항과 목표가 다르기 때문에 표준 프로세스가 없다는 것입니다. DevOps 도구와 리소스는 너무 많아 채택을 방해하는 “분석 마비”로 이어질 수 있습니다. 팀이 DevOps를 구현하는 데 도움이 될 수 있는 단계는 다음과 같습니다.

DevOps가 필요한 이유는 무엇입니까?


이에 대한 답변을 간단히 설명하자면, DevOps는 개발자들이 가장 잘하는 일, 즉 로그 파일을 수동으로 확인하는 것과 같이 가치가 낮은 작업을 수동으로 수행하는 것보다는 뛰어난 소프트웨어를 만드는 일을 할 수 있도록 해주어 생산성을 높인다는 것입니다. DevOps 관행은 테스트 실행 및 배포, 문제에 대한 프로덕션 소프트웨어 모니터링을 비롯해 문제에 대한 복원력이 높은 배포 방법론 구축과 같은 반복적인 작업을 자동화합니다. 개발자는 구축하고 실험할 수 있는 권한이 부여되어 생산성이 향상됩니다.

DevOps는 여러 가지로 정의할 수 있습니다. 이 문서에서 DevOps는 팀이 소프트웨어의 전체 수명 주기를 소유한다는 뜻입니다. DevOps 팀은 소프트웨어를 설계, 구현, 배포, 모니터링, 업데이트하고 문제를 해결합니다. 코드 자체와 코드가 실행되는 인프라를 소유하며 최종 사용자 경험뿐만 아니라 프로덕션 문제도 책임집니다.

DevOps의 핵심은 문제를 예상하고 개발자들이 문제에 효과적으로 대응할 수 있도록 권한을 부여하는 프로세스를 구축하는 것입니다. DevOps 프로세스는 배포 후 개발자들에게 시스템 상태에 대한 즉각적인 피드백을 제공해야 합니다. 문제를 시작 단계에서 발견할수록 문제가 미치는 영향은 낮아지고 팀은 더 빠르게 다음 작업으로 넘어갈 수 있습니다. 변경 사항을 배포하고 문제에서 복구하기 쉬운 경우 개발자들은 새 아이디어를 실험하고, 구축하고, 릴리스하고, 시도해볼 수 있습니다.

DevOps는 기술이 아닙니다. 단순히 DevOps 도구를 구입하여 DevOps라고 부른다면 본말이 전도된 것이나 다름없습니다. DevOps의 핵심은 책임 공유, 투명성, 더 빠른 피드백의 문화를 구축하는 것입니다. 기술은 이것을 가능하게 만들어주는 도구일 뿐입니다.

조직 로고
관련 자료

무료로 사용해보기

트로피 아이콘
관련 자료

DevOps 모범 사례에 대해 알아보기

고지 사항


팀마다 출발점이 다르다는 점을 감안할 때, 다음 단계 중 일부는 적용되지 않을 수 있습니다. 또한 이 목록이 모든 단계를 포함하는 것은 아닙니다. 여기에 제시된 단계는 팀이 DevOps를 구현하는 데 도움을 주기 위한 출발점입니다.

이 문서에서 DevOps는 DevOps가 잘 작동하도록 하는 문화, 프로세스, 기술을 포괄하는 용어로 사용됩니다.

DevOps를 위한 8단계


DevOps 루프

1단계 - 구성 요소 선택

첫 번째 단계는 작게 시작하는 것입니다. 현재 프로덕션에 있는 구성 요소를 선택하세요. 종속성이 적고 인프라가 최소화된 단순한 코드 베이스를 갖춘 구성 요소를 고르는 것이 좋습니다. 구성 요소는 팀의 DevOps 구현에 관한 시험의 장이 되어줄 것입니다.

2단계 - 스크럼과 같은 애자일 방법론의 채택 고려

DevOps는 스크럼과 같은 애자일 작업 방법론과 함께 사용되는 경우가 많습니다. 스크럼과 같은 방법과 관련된 모든 리추얼이나 관행을 채택할 필요는 없습니다. 스크럼에서 일반적으로 채택하기 쉽고 빠르게 가치를 제공하는 세 가지 요소는 백로그, 스프린트스프린트 계획입니다.

DevOps 팀은 스크럼 백로그에서 작업을 추가하고 우선 순위를 지정한 다음 해당 작업의 일부를 특정 작업을 완료하기 위한 고정된 기간인 스프린트로 가져올 수 있습니다. 스프린트 계획은 어떤 작업이 백로그에서 다음 스프린트로 이동하는지 결정하는 과정입니다.

3단계 - GIT 기반 소스 제어 사용

버전 제어는 협업을 강화하고 릴리스 주기를 단축할 수 있는 DevOps 모범 사례입니다. Bitbucket과 같은 도구를 사용하면 개발자가 소프트웨어를 공유하고, 협업하고, 병합 및 백업할 수 있습니다.

브랜치 모델을 선택하세요. 이 문서에서는 개념의 개요를 살펴봅니다. GitHub 흐름은 이해하기 쉽고 구현하기 쉽기 때문에 Git을 처음 접하는 팀에게 좋은 출발점입니다. 트렁크 기반 개발이 선호되는 경우가 많지만, 더 많은 규율이 필요하고 Git을 처음 시도하기가 더 어렵습니다.

4단계 - 소스 제어와 작업 추적 통합

소스 제어 도구를 작업 추적 도구와 통합하세요. 특정 프로젝트와 관련된 모든 것을 한곳에서 볼 수 있으면 개발자와 경영진이 상당한 시간을 절약할 수 있습니다. Git 기반 소스 제어 리포지토리에서 업데이트한 Jira 이슈의 예시는 아래와 같습니다. Jira 이슈에는 소스 제어에서 Jira 이슈에 대해 수행한 작업을 집계하는 개발 섹션이 포함됩니다. 이 이슈에는 브랜치 1개, 커밋 6개, 풀리퀘스트 1개와 빌드 1개가 있었습니다.

소스 제어와 작업 추적을 통합하는 스크린샷

Jira 이슈의 개발 섹션을 자세히 살펴보면 추가 세부 정보를 찾을 수 있습니다. 커밋 탭에는 Jira 이슈와 관련된 모든 커밋이 나열됩니다.

소스 제어와 작업 추적을 통합하는 스크린샷

이 섹션에는 Jira 이슈와 관련된 모든 풀리퀘스트가 나열됩니다.

소스 제어와 작업 추적을 통합하는 스크린샷

이 Jira 이슈와 관련된 코드는 배포 섹션에 나열된 모든 환경에 배포됩니다. 통합은 보통 Jira 이슈 ID(이 경우에는 IM-202)를 추가하여 Jira 이슈와 관련된 작업의 메시지와 브랜치 이름을 커밋하는 방식으로 이루어집니다.

소스 제어와 작업 추적을 통합하는 스크린샷

코드 탭은 프로젝트와 관련된 모든 소스 제어 리포지토리로 연결되는 링크를 제공합니다. 이렇게 하면 개발자가 Jira 이슈에 자신을 할당할 때 작업해야 하는 코드를 찾을 수 있습니다.

소스 제어와 작업 추적을 통합하는 스크린샷

5단계 - 테스트 작성

CI/CD 파이프라인에는 다양한 환경에 배포된 코드가 제대로 작동하는지 검증하기 위한 테스트가 필요합니다. 코드에 대한 단위 테스트를 작성하는 것으로 시작하세요. 야심 찬 목표는 90%의 코드 커버리지지만, 막 시작한 경우라면 비현실적인 목표입니다. 코드 커버리지의 기준선을 낮게 설정하고 시간이 지나면서 단위 테스트 커버리지의 기준을 점차 늘리세요. 백로그에 작업 항목을 추가하여 이를 해결할 수 있습니다.

프로덕션 코드에서 발견된 버그를 수정할 때는 테스트 기반 개발을 사용하세요. 버그를 발견하면 버그가 있는 환경에서 장애를 일으키는 유닛 테스트, 통합 테스트 및/또는 시스템 테스트를 작성하세요. 그런 다음 버그를 수정하고 이제 테스트가 통과하는지 관찰하세요. 이 프로세스는 시간이 지남에 따라 코드 커버리지를 유기적으로 늘려줍니다. 테스트 환경이나 스테이징 환경에서 버그가 발견된 경우 테스트는 코드를 프로덕션으로 승격할 때 코드가 제대로 작동하고 있다는 확신을 줄 것입니다.

처음부터 시작할 때 이 단계는 노동 집약적인 작업이지만 매우 중요합니다. 테스트를 통해, 팀은 최종 사용자에게 코드 변경 사항을 공개하기 전에 코드 변경이 시스템 동작에 미치는 영향을 확인할 수 있습니다.

단위 테스트

단위 테스트는 소스 코드가 올바른지 검증해주며, CI/CD 파이프라인의 첫 번째 단계 중 하나로 실행해야 합니다. 개발자들은 녹색 경로, 문제가 있는 입력, 알려진 코너 케이스에 대한 테스트를 작성해야 합니다. 테스트를 작성할 때 개발자는 입력과 예상 출력을 모형화할 수 있습니다.

통합 테스트

통합 테스트는 두 구성 요소가 서로 올바르게 통신하는지 검증합니다. 입력과 예상 출력을 모형화하세요. 이 테스트는 어떤 환경에나 배포하기 전 CI/CD 파이프라인의 첫 번째 단계 중 하나입니다. 일반적으로 이 테스트를 제대로 실행하려면 단위 테스트보다 더 광범위한 모형화가 필요합니다.

시스템 테스트

시스템 테스트는 시스템의 엔드투엔드 성능을 검증하고 시스템이 각 환경에서 예상대로 작동하고 있다는 확신을 줍니다. 구성 요소가 받을 수 있는 입력을 모형화하고 시스템을 실행하세요. 그런 다음, 시스템이 필요한 값을 반환하고 나머지 시스템을 올바르게 업데이트하는지 확인하세요. 테스트는 각 환경에 배포한 후에 실행해야 합니다.

6단계 - 구성 요소 배포를 위한 CI/CD 프로세스 구축

CI/CD 파이프라인을 구축할 때는 여러 환경에 배포하는 것을 고려하세요. 팀이 단일 환경에만 배포하는 CI/CD 파이프라인을 구축하면 하드 코딩이 이루어집니다. 인프라와 코드를 위한 CI/CD 파이프라인을 구축하는 것이 중요합니다. 먼저 각 환경에 필요한 인프라를 배포하기 위해 CI/CD 파이프라인을 구축하는 것으로 시작하세요. 그런 다음 코드 배포를 위한 또다른 CI/CD 파이프라인을 구축하세요.

파이프라인 구조

이 파이프라인은 테스트 환경에 배포하기 전에 단위 테스트와 통합 테스트를 실행하는 것으로 시작합니다. 시스템 테스트는 환경에 배포한 후에 실행됩니다.

소스 제어와 작업 추적을 통합하는 스크린샷

위의 대략적인 템플릿은 여러 방법으로 확장할 수 있습니다. 코드 린팅, 정적 분석 및 보안 검사는 단위 테스트와 통합 테스트 전에 추가하면 좋은 단계입니다. 코드 린팅은 코딩 표준을 적용할 수 있고, 정적 분석은 안티패턴을 검사할 수 있으며, 보안 검사는 알려진 취약성이 있는지 감지할 수 있습니다.

소스 제어와 작업 추적을 통합하는 스크린샷

인프라와 코드를 배포하기 위한 CI/CD 파이프라인은 다를 수 있습니다. 인프라를 위한 CI/CD 파이프라인에는 단위 테스트나 통합 테스트가 없는 경우가 많습니다. 시스템 작동이 중단되지 않았는지 확인하기 위해 배포 후에 매번 시스템 테스트를 실행합니다.

인프라

환경 간의 인프라 차이로 인해 해당 환경에서 실행되는 소프트웨어가 올바르게 실행되기 어렵습니다. 소프트웨어가 올바르게 실행되려면 방화벽 규칙, 사용자 권한, 데이터베이스 액세스 및 기타 인프라 수준 구성 요소는 알려진 구성이어야 합니다. 수동 인프라 배포는 올바르게 반복하기 어려울 수 있습니다. 이 프로세스에는 여러 단계가 있기 때문에, 기억에 의존하여 올바른 매개 변수로 각 단계를 올바른 순서로 실행하려고 하면 오류로 이어질 수 있습니다. 이러한 문제와 다른 문제를 완화하려면 가능한 경우 항상 코드로 인프라를 정의해야 합니다.

인프라는 AWS CloudFormation, Terraform, Ansible, Puppet 또는 Chef를 비롯한 다양한 도구를 사용하여 코드로 정의할 수 있습니다.

인프라 배포를 위한 파이프라인을 여러 개 작성하세요. 코드 작성과 마찬가지로, 인프라 배포를 모듈식으로 유지하는 것이 좋습니다. 가능한 경우 필요한 인프라를 분리된 하위 집합으로 나누세요. A, B, C 및 D가 서로 종속할 수 있는 인프라 구성 요소의 추상이라고 가정해 보겠습니다. 예를 들어, A는 EC2 상자이고 B는 S3 버킷일 수 있습니다. 인프라 구성 요소 A만 구성 요소 B에 종속되는 종속성은 동일한 CI/CD 파이프라인에 함께 보관될 가능성이 높습니다. A, B 및 C가 D에 종속하지만 A, B 및 C는 독립적인 경우의 종속성은 여러 CI/CD 파이프라인으로 나누어야 합니다. 이 경우에는 4개의 독립적인 파이프라인이 있습니다. 이 인스턴스에서는 다른 3개의 구성 요소가 모두 종속하는 D에 대해 파이프라인 1개를 만들고 A, B, C에 대해 1개씩 만들어야 합니다.

코딩

CI/CD 파이프라인은 코드를 배포하기 위해 구축되었습니다. 이전 작업 덕분에 인프라가 이미 사용 가능하기 때문에, 이러한 파이프라인은 보통 간단하게 구현할 수 있습니다. 여기서 중요한 고려 사항은 테스트, 반복성, 그리고 잘못된 배포에서 복구하는 능력입니다.

반복성은 시스템을 손상시키지 않고 동일한 변경 사항을 반복적으로 배포할 수 있는 능력입니다. 배포는 재입력이 가능하고 멱등성이 있어야 합니다. 배포는 기존 상태에 수정자를 적용하는 대신 시스템 상태를 알려진 구성으로 설정해야 합니다. 첫 번째 배포 이후에 수정자가 제대로 작동하는 데 필요한 시작 상태가 변경되었으므로, 수정자 적용을 반복할 수 없습니다.

반복할 수 없는 업데이트의 간단한 예시는 구성 파일에 데이터를 추가하여 업데이트하는 것입니다. 구성 파일에 행을 추가하거나 그와 비슷한 수정 기법을 사용하지 마세요. 추가를 통해 업데이트하면 구성 파일에 수십 개의 중복 행이 생길 수 있습니다. 그 대신, 구성 파일을 소스 제어의 올바르게 작성된 파일로 대체하세요.

이 원칙은 데이터베이스 업데이트에도 적용해야 합니다. 데이터베이스 업데이트는 문제가 발생할 수 있으며 자세한 사항에 주의를 기울여야 합니다. 데이터베이스 업데이트 프로세스를 반복 가능하고 내결함성 있도록 만드는 것이 중요합니다. 복구가 가능하도록 변경 사항을 적용하기 직전에 백업을 수행하세요.

또다른 고려 사항은 잘못된 배포에서 복구하는 방법입니다. 배포가 실패하고 시스템이 알 수 없는 상태이거나 배포가 성공하면 경보가 트리거되고 문제 티켓이 들어오기 시작합니다. 이 상황을 처리하는 데는 일반적으로 두 가지 방법이 있습니다. 첫 번째 방법은 롤백입니다. 두 번째 방법은 기능 플래그를 사용하고 알려진 양호한 상태로 돌아가기 위해 필요한 플래그를 해제하는 것입니다. 기능 플래그에 관한 자세한 내용은 이 문서의 8단계를 참고하세요.

롤백은 잘못된 배포가 감지된 후 이전에 알려진 양호한 상태를 환경에 배포합니다. 롤백의 경우 처음에 계획이 이루어져 있어야 합니다. 데이터베이스를 다루기 전에 백업을 수행하세요. 이전 버전의 코드를 빨리 배포할 수 있도록 하세요. 테스트 또는 스테이징 환경에서 롤백 프로세스를 정기적으로 테스트하세요.

7단계 - 모니터링, 경보, 계측 추가

DevOps 팀은 각 환경에서 실행 중인 애플리케이션의 동작을 모니터링해야 합니다. 로그에 오류가 있습니까? API 호출 시간이 초과됩니까? 데이터베이스가 충돌합니까? 시스템의 각 구성 요소에 문제가 있는지 모니터링하세요. 모니터링에서 문제가 감지되면 누군가 문제를 해결할 수 있도록 문제 티켓을 제기하세요. 문제 해결의 일부로, 문제를 발견할 수 있는 추가 테스트를 작성하세요.

버그 수정

문제에 대한 모니터링 및 대응은 프로덕션 소프트웨어 실행의 일부입니다. DevOps 문화를 갖춘 팀은 소프트웨어 운영을 소유하고 사이트 신뢰성 엔지니어(SRE)의 행동을 차용합니다. 문제의 근본 원인 분석을 수행하고, 문제를 감지하는 테스트를 작성하고, 문제를 해결하고, 이제 테스트가 통과하는지 확인하세요. 이 프로세스는 처음에는 많은 작업이 수반되는 경우가 많지만, 기술적 부채를 줄이고 운영 애질리티가 유지되므로 장기적으로는 이익을 얻을 수 있습니다.

성능 최적화

기본적인 상태 모니터링이 마련되었다면 그 다음 단계에서는 성능 조정이 자주 이루어집니다. 각 시스템이 어떻게 실행되는지 살펴보고 느린 부분을 최적화하세요. Knuth가 언급했듯이 “조기 최적화는 만악의 근원입니다.” 시스템에 있는 모든 것의 성능을 최적화하지 말고 가장 느리고 비용이 많이 드는 부분만 최적화하세요. 모니터링을 통해 느리고 비용이 많이 드는 구성 요소를 찾아낼 수 있습니다.

8단계 - 기능 플래그를 사용하여 카나리아 테스트 구현

카나리아 테스트를 사용하려면 테스트 사용자가 포함된 허용 목록을 통해 기능 플래그에 있는 각각의 새 기능을 래핑하세요. 새 기능 코드가 환경에 배포된 후에는 허용 목록에 있는 사용자에 대해서만 실행됩니다. 새 기능을 각 환경에 먼저 적용한 후에 다음 환경으로 넘어가세요. 새 기능이 리전에 적용되는 동안에는 메트릭, 경보, 기타 계측에 주의하며 문제의 징후가 있는지 확인하세요. 특히 새로운 문제 티켓이 증가하는지 살펴보세요.

다음 환경으로 승격하기 전에 환경의 문제를 해결하세요. 프로덕션 환경에서 발견되는 문제는 테스트 환경이나 스테이징 환경의 문제와 동일하게 처리되어야 합니다. 문제의 근본 원인을 파악한 후에는 테스트를 작성하여 문제를 파악하고, 수정 사항을 구현하고, 테스트가 통과하는지 확인하고, CI/CD 파이프라인을 통해 수정 사항을 승격하세요. 문제가 감지된 환경에 변경 사항이 완전히 적용되는 동안, 새 테스트는 통과하고 문제 티켓의 개수는 감소할 것입니다.

결론...


첫 번째 구성 요소를 DevOps로 이동하는 프로젝트에 대해 회고를 진행하세요. 문제점, 까다롭거나 어려웠던 부분을 찾아내세요. 문제점을 해결하도록 계획을 보완하고 두 번째 구성 요소로 넘어가세요.

DevOps 접근 방식을 사용하여 구성 요소를 프로덕션에 적용하는 것은 처음에는 작업의 양이 꽤 많아 보일 수 있지만 나중에는 이익이 되어 돌아옵니다. 토대가 마련되면 두 번째 구성 요소를 구현하는 것이 더 쉬워질 것입니다. 도구가 준비되어 있고, 기술을 파악했으며, 팀이 DevOps 스타일로 작업하도록 교육을 받았기 때문에, 첫 번째 구성 요소의 동일한 프로세스를 사용하면서 두 번째 구성 요소에 대해서는 약간 수정하여 진행할 수 있습니다

DevOps 여정을 시작하려면 소프트웨어 개발 및 운영에 필요한 모든 것을 갖추고 있으며 요구 사항이 증가함에 따라 추가 도구를 통합할 수 있는 기능이 포함된 개방형 통합 도구 체인, Atlassian Open DevOps를 사용해 보세요.

Warren Marusiak
Warren Marusiak

Warren is a Canadian developer from Vancouver, BC with over 10 years of experience. He came to Atlassian from AWS in January of 2021.


이 문서 공유

여러분께 도움을 드릴 자료를 추천합니다.

이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

DevOps 학습 경로

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up