Close

지속적 제공 원칙

시작 가이드를 통해 지속적 제공의 기본 원칙을 알아보세요.


지속적 제공(CD)은 이전에 성공한 애자일 및 조직적 모범 사례 여러 개를 모아 놓은 것입니다. CD는 조직이 간소화 및 자동화된 소프트웨어 릴리스 프로세스를 구축하는 데 중점을 둡니다. 릴리스 프로세스의 핵심은 반복적인 피드백 루프입니다. 피드백 루프는 최종 사용자에게 최대한 빨리 소프트웨어를 제공하고 실제 경험을 통해 배우고 그 피드백을 다음 릴리스에 통합하는 것을 중심으로 진행됩니다.

지속적 통합, 지속적 제공, 지속적 배포 비교

상시 서비스를 달성하려면 운영 우수성이 핵심 역량이 되도록 팀 구조, 가치 및 도구를 정렬해야 합니다. 문서 읽기

지속적 제공의 비즈니스 가치

지속적 제공의 비즈니스 가치는 기술 애호가에게만 국한되지 않습니다. CD는 소프트웨어 개발 팀의 속도, 생산성, 지속 가능성을 개선하여 가치를 더합니다. 문서 읽기

가치 흐름 매핑

가치 흐름 매핑은 지속적 제공 파이프라인을 최적화할 수 있는 분석 기법입니다. 가치 흐름 매핑을 사용하는 방법 및 이유를 알아보세요. 문서 읽기


CD는 디자인, 제품, 마케팅 같은 비엔지니어링 팀을 포함하는 조직 전반의 포괄적인 방법론입니다. CD는 개발자가 최종 사용자 제품을 제공하는 데 집중하도록 장려하는 반면 CD가 아닌 환경은 개발자가 관심을 갖는 주요 사용자 경험이 QA 팀이 되는 “벽 너머로 넘기는” 행동을 장려할 수 있습니다. 다음 섹션에서는 CD 워크플로의 토대를 마련하는 구체적인 원칙에 대해 다룰 것입니다.

컴퓨터 코드 및 작업 항목이 지속적으로 흐르는 방법을 보여주는 다이어그램. | Atlassian CI/CD

반복 가능하고 신뢰할 수 있는 프로세스

조직 프로세스에는 자체적인 개발 수명 주기가 있습니다. 보통 수동 체크리스트나 수동으로 수행한 작업의 목록인 “플레이북”으로 시작하며 나중에 소프트웨어 도구와 스크립트로 자동화할 수 있습니다. 플레이북을 소프트웨어 스크립트로 커밋하면 반복이 가능합니다. 체크리스트를 다시 실행해야 하는 경우 팀원은 스크립트를 실행할 수 있습니다. 플레이북 스크립트가 환경 간에 일관적으로 실행될 때 안정성이 확보됩니다. 예를 들어 개발 환경이나 스테이징 환경에 코드를 배포하기 위한 플레이북은 프로덕션 환경을 최대한 비슷하게 반영해야 합니다. 환경과 실행 간의 믿을 수 있는 일관성은 모든 종류의 일관성 버그를 없앱니다.

모든 것을 자동화

자동화는 CD의 핵심 가치입니다. 수동으로 작업하는 시간은 비용이 높으며 지루한 플레이북 작업 실행 대신 창의적인 연습에 보수적으로 사용해야 합니다. 수동 프로세스는 코딩에 커밋하고 요청 시 자동으로 실행 가능하게 되기 전까지는 진정한 의미에서 반복하거나 신뢰할 수 없습니다. 자동화된 작업을 함께 구성하면 자동화 수준을 한 단계 높일 수 있습니다. 테스트, 릴리스, 구성 변경 등을 최대한 자동화하세요.

버전 제어

CD의 초석인 버전 제어는 어떤 심각한 소프트웨어 프로젝트에든 완전한 필수 사항입니다. 버전 제어를 통해 개발자 팀은 공유 코드베이스에서 효율적으로 공동 작업할 수 있습니다. Git은 가장 널리 사용되는 버전 제어 시스템이고 CD의 훌륭한 동반자입니다. 버전 제어를 통해 이전 릴리스 후보로 롤백을 허용하여 '실행 취소' 기능을 사용할 수 있습니다. 코드 외에도 구성, 스크립트, 데이터베이스, 문서를 모두 버전 제어해야 기록 전반의 편집 내용을 추적할 수 있습니다.

높은 품질의 빌드

CD에서 품질은 나중에 QA 팀에만 맡기는 것이 아닙니다. 품질은 릴리스 파이프라인의 모든 단계에 포함되어 있습니다. CD의 중앙 집중식 피드백 루프는 최종 사용자에게 제공되는 품질을 지속적으로 재검토합니다. 새 기능은 새 코드에 버그가 없고 품질 기대치를 충족하는지 확인하는 일련의 자동 테스트와 함께 제공됩니다. 새 기능 릴리스에 대한 프로젝트 계획에는 분석, 성능 모니터링, 자동화된 테스트 계측 작업에 대한 고려 사항이 포함되어야 합니다.

가장 어려운 부분부터 시작

고통스럽고 시간이 많이 걸리거나 오류가 발생하기 쉬운 작업은 시간이 지날수록 복잡해집니다. 복합적인 에너지 손실을 방지하려면 힘든 일을 최대한 빨리 해결해야 합니다. 일주일에 5번 하는 20분 걸리는 힘든 집안일을 상상해 보세요. 그 시간을 합하면 일주일에 100분, 한 달에 약 400분 정도가 됩니다. 집안일을 해결하고 힘든 시간을 완전히 없애도록 최적화할 수 있다고 상상해 보세요. 그러면 당연히 성공에 해당할 것입니다.

“가장 어려운 부분부터 시작”하는 것은 조직 프로세스의 약점을 식별할 수 있는 관행이기도 합니다. 미루거나 회피하는 작업이 있다면 개선해야 할 영역일 수 있으며 적극적으로 개선을 추구해야 합니다. 팀은 익숙해지도록 정기적으로 어려운 부분을 다루고 대화를 계획하는 데 앞장서야 합니다.

모두의 책임

최종 사용자 산출물의 품질을 최대한 높이려면 조직 전체가 집중하고 그에 따른 인센티브를 받아야 합니다. 제품 관리자는 배포와 품질 보증에 주의를 기울여 계획을 세워야 합니다. 보안 팀은 릴리스 프로세스에 적극적으로 참여해야 합니다. QA 팀원은 최종 릴리스 전에 장애를 발견하기 위해 프로덕션 환경에서와 마찬가지로 매우 엄격하게 개발 및 스테이징 환경을 테스트해야 합니다. 개발자는 프로덕션 릴리스를 적극적으로 계획해야 합니다.

팀이 협업하여 릴리스 전에 코드를 검사합니다. | Atlassian CI/CD

“완료”는 릴리스 완료를 의미

소프트웨어 회사는 최종 사용자에게 소프트웨어를 제공하기 위해 비즈니스를 하고 있습니다. 앱이 한 개발자의 컴퓨터에서만 작동하면 아무 소용이 없습니다. “저는 잘 되던데요”라는 말은 전반적인 비즈니스 목표에 대한 인식이 부족하고 최종 사용자에 대한 공감 능력이 부족하다는 것을 나타내는 흔한 위험 신호입니다. CD는 전적으로 최종 고객에게 소프트웨어를 제공하는 데 초점을 맞춥니다. 여기에 더해 '완료'란 팀원 개개인의 기여가 끝난 때가 아니라 팀의 전체 기여가 완료된 때를 의미합니다.

지속적 개선

지속적 제공 가치

이전 섹션에서 CD의 높은 수준의 부가 가치를 설명했습니다. 거시적 차원에서 CD는 실행 효율성, 팀 간의 커뮤니케이션, 제품의 시장 적합성, 애질리티, 전반적인 조직 투명성을 촉진합니다.

미시적 수준에서는 CD에 명시적 추적 메트릭을 측정하여 계측할 수 있습니다. 몇 가지 유용한 CD 메트릭은 다음과 같습니다.

  • 새 기능 디자인 단계부터 프로덕션 릴리스까지의 시간.
  • 사용자가 겪은 프로덕션 버그의 개수.
  • 새 기능에 대한 사용자의 참여 수준.
  • 새 기능 릴리스의 빈도

또한 CD는 KPI와 같은 조직 성과 메트릭을 작성하는 토대로 사용할 수 있습니다. 마지막으로 비즈니스 수익과 재무 건전성은 조직 관행의 영향을 측정하는 좋은 방법입니다.

지속적 제공으로 시작하기

CD의 이점과 철학을 이해했으므로 다음 단계는 CD를 구현하는 것입니다. 좋은 출발점은 지속적 통합입니다. 지속적 통합(CI)은 CD의 전조입니다. CI는 코드 릴리스 워크플로 자동화에 중점을 두고 있습니다. CI는 자동화된 코드 테스트 도구와 품질 보증 작업을 통해 그렇게 합니다. CI가 설치되면 그 위에 CD 프로세스를 구축하여 최종 사용자에게 코드를 배포하고 향후 릴리스를 주도할 피드백 루프를 개발할 수 있습니다.

Max Rehkopf
Max Rehkopf

스스로를 "자유분방하다"고 생각하는 저는 일상을 질서 있게 만들기 위해 애자일 관행과 린 원칙을 추구합니다. Atlassian을 위해 마련한 많은 기사, 강연 및 동영상을 통해 이러한 배운 점을 다른 분들과 공유할 때 큰 즐거움을 얻습니다 


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

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

DevOps 일러스트레이션

DevOps 커뮤니티

DevOps 일러스트레이션

블로그 읽기

맵 일러스트레이션

무료로 사용해보기

DevOps 뉴스레터 신청

Thank you for signing up