DevOps 원칙 및 베스트 프랙티스

효율성에 매달리는 것만으로는 생산성이 향상될지 몰라도 시간의 압박과 예상치 못한 상황으로부터 자유로워질 수는 없습니다. 팀이 성공하고 최고의 작업물을 낼 수 있도록 긍정적이며 지속 가능한 업무 문화도 조성해야 합니다. 협업하는 문화에서는 직원들이 더 자신감을 느끼고, 더 폭넓게 아이디어를 공유하고, 더 큰 연대감과 책임감을 갖게 되며 이는 곧 제품 결과물과 수익에 대한 긍정적인 영향으로 이어집니다.

협업 환경을 구축하려면 개방성, 투명성, 피드백(긍정적이거나 부정적인 피드백 모두)을 장려하면서 나쁜 아이디어는 없다는 점을 강조하세요. 팀 간에 업무와 관련하여 교류할 수 있는 시스템을 구축하고 성공에 대해 개인과 팀 모두의 공을 인정해야 합니다. 모두가 버전 관리 시스템과 같은 적절한 툴을 사용할 수 있도록 장려하는 것도 중요합니다.

DevOps에서 '원점 회귀' 원칙이란 워크플로 단계의 재구성을 의미합니다. 개발 파이프라인에서 일반적으로 이루어지는 프로세스는 DevOps 라이프사이클 베스트 프랙티스에 부합하기 위해 초기 단계로 '원점 회귀'합니다.

CI/CD는 원점 회귀가 팀의 민첩성 향상에 어떻게 도움이 되는지를 나타내는 한 가지 예입니다. CI(지속적 통합)는 작업을 중앙 저장소에 자동으로 병합하는 프로세스입니다. 빌드를 생성하고 빌드에 대해 자동화된 테스트를 실행하여 변경 사항을 검증합니다. 

CD(지속적 배포)는 CI가 끝난 시점에 빌드에서 릴리스를 배포하고 자동화된 시스템 레벨 테스트를 수행합니다. 기존 방식에서 이 프로세스는 수작업으로 이루어지며 이로 인해 파이프라인 속도가 느려집니다. CI/CD를 구현하면 일관되며 자동화된 방식으로 소프트웨어를 빌드하고, 패키징하고, 테스트할 수 있습니다.

시간을 많이 잡아먹으며 인적 오류에 취약한 수작업 프로세스를 제거하는 것이 DevOps의 핵심 원칙입니다. 자동화된 테스트 및 오류 트래킹 툴을 사용하면 팀이 버그를 트래킹하고 제거하는 번거로운 작업을 줄이면서 동시에 전반적으로 관련 프로세스를 더 효율적으로 수행할 수 있습니다. 실제로 적절한 오류 모니터링 및 보고 툴 세트를 사용하면 버그를 역이용하여 최적화된 코드, 궁극적으로는 더 나은 제품으로 인도하는 이정표로 활용할 수 있습니다.

자동화된 테스트는 DevOps의 '원점 회귀' 원칙의 또 다른 예입니다. 기존 워크플로에서는 빌드를 라이브 환경에 배포하고 수작업으로 테스트하지만, 자동화된 테스트가 통합된 워크플로에서는 코드 변경 사항이 빌드에 릴리스되기 전뿐만 아니라 프로덕션 전에 오류를 모니터링할 수 있습니다. 라이브로 전환되기 전에 오류를 식별하면 프로그래머는 실시간으로 문제를 해결하고 패치나 핫픽스같이 서비스를 중단하는 작업을 최소화할 수 있습니다.

파이프라인 성능을 정량화하고 최적화 기회를 찾으려면 몇 가지 KPI(주요 성과 지표)를 트래킹해야 합니다. 4가지 주요 DevOps KPI는 다음과 같습니다.

• 배포 빈도: 스테이징, 테스트 또는 프로덕션에 코드를 배포하는 빈도
• 변경 리드 시간: 커밋을 프로덕션에 적용하는 데 소요되는 시간
• 변경 오류율: 프로덕션 중단을 초래하는 배포의 비율
• MTTR(평균 해결 시간): 제품 또는 시스템 오류로부터 복구하는 데 소요되는 평균 시간

그 외의 KPI는 다음과 같습니다.

• 배포 시간: 스테이징, 테스트 또는 프로덕션에 코드를 배포하는 데 소요되는 시간 
• 풀 리퀘스트(Pull request) 주기 시간: 코드를 작성하고 배포하는 데 소요되는 시간
• 오류 수
• MTTD(평균 감지 시간): 오류를 발견하는 데 소요되는 평균 시간

관련성이 높고 실행 가능한 KPI에 집중하세요. 너무 많은 KPI를 트래킹하면 정보에 과부하가 발생하고 컨텍스트가 없는 데이터가 생겨 최적화가 어려워질 수 있습니다.

DevOps 원칙을 구현하는 팀은상호 보완적인 애자일 프랙티스가 제공하는 이점을 통해 효과적인 DevOps 협업에서 핵심적인 역할을 하는 애자일 가치를 함께 활용할 수 있습니다.

DevOps는 프리 프로덕션에서 릴리스에 이르는 전체 프로덕션 프로세스에 걸쳐 반복적인 개발에 중점을 두며, 이때 업데이트가 일주일에 몇 번씩 지속적으로 푸시됩니다. 애자일은 프로덕션 단계에 더욱 중점을 두며 새로운 빌드가 몇 주 또는 몇 달에 한 번씩 더 긴 주기로 릴리스되는 스프린트 모델을 따릅니다.

DevOps 방식을 실천하는 경우에도 프로젝트 관리에 대한 애자일 접근 방식의 이점을 누릴 수 있습니다. Kanban, Scrum과 같은 애자일 프랙티스는 체계적인 워크플로를 지원합니다. 또한 생산성 트래킹, 번다운 차트 계산, 백로그 구성에 주로 사용되는 툴을 사용하므로 구성원들이 프로세스와 미팅에 더 집중할 수 있습니다.

DevOps에서 피드백 루프는 하나 이상의 프로세스 또는 결과를 개선하기 위해 입력이 출력으로 이어졌다가 다시 반복되고 검토됩니다. 

피드백 루프에는 두 가지 유형이 있습니다. 피드백 강화 루프에서는 한 프로세스에 대한 긍정적인 업데이트가 다른 관련 프로세스에도 긍정적인 영향을 끼치며, 원래 업데이트의 가치가 더 높아집니다. 이를 '변화 가속화 루프'라고도 합니다. 피드백 균형 조정 루프에서는 한 프로세스에 대한 긍정적인 업데이트가 다른 프로세스에 부정적인 결과로 나타나며, 원래 업데이트의 가치에 의문을 제기합니다. 일반적으로는 피드백 강화 루프를 최대화하고 피드백 균형 조정 루프는 최소화하는 것이 좋습니다. 

피드백 루프가 단축되면 유지 관리, 모니터링, 최적화가 더욱 간편해집니다.