DevOps 텍스트 교육
품질 보장을 위해 왜 지속적 검토 프로세스를 마련하나요?
조직은 프로덕션 배포 직전의 검토, 감사, 검사, 승인에 크게 의존합니다. 이런 검사는 대개 업무에 거의 관여하지 않았거나 전혀 관여하지 않은 사람이 수행합니다. 더 나쁜 것은 검사 및 승인권자가 업무를 잘못 이해할 때도 있어, 프로덕션에 코드를 배포하려는 바로 그때 설명해야 한다는 것입니다.
외부 통제 장치의 문제
대부분의 조직에서 상호 신뢰를 만드는 것보다 통제 장치를 마련하는 편이 쉽습니다. 그래서 변경 통제 양식에 질문이 늘고, 조직 계층에 승인 단계가 추가되며, 변경을 이해하고 승인하는 데 추가 시간이 드는 일이 외부 통제 장치의 전형적 문제로 나타납니다.
지시와 통제가 지배하는 신뢰 낮은 환경에서는 인시던트가 자꾸 반복됩니다. 실제 수행한 일과 반복되는 문제를 투명하게 볼 수 없고, 번거로운 배포 횟수를 최대한 줄이려 대량으로 작업하기 때문에 악순환이 생깁니다. 제공 리드 타임이 길어지면 시장 출시 속도에서 경쟁력이 떨어집니다. 팀이 받는 피드백이 느리고 늦으며 실천할 수 없으면 실수에서 배울 수 없습니다.
유능한 DevOps 조직은 실제 업무와 관련 문제에 가장 가까운 사람이 그 일을 가장 잘 안다는 점을 이해합니다. 따라서 외부 통제와 승인을 추가해도 가치 흐름에 이점이 생기지 않습니다. 이 점은 우리 시대의 가장 큰 경영 및 리더십 과제로 이어집니다. 업무가 투명하고 진정한 존중과 상호 신뢰가 일상에 뿌리내린 문화를 만드는 일입니다.
정기 검사에 대한 의존을 줄이고 일상에서 동료 검토를 활용해야 합니다. DevOps 팀의 개발자, 운영 엔지니어, 품질 보증 및 정보 보안 전문가가 계속 협력하고 서로의 작업을 검토해 안전하게 배포하도록 하세요.
외부 통제 장치 없이 복잡한 업무 조율하기
팀 하나가 프로젝트를 맡아도 복잡하지만, 여러 팀이 같은 시스템의 서로 다른 구성 요소를 맡으면 더 복잡해질 수 있습니다. 본인과 DevOps 팀이 상황을 잘 관리하는 데 도움이 되는 조치는 다음과 같습니다.
- 관리자뿐 아니라 분야별 전문가로 구성된 변경 위원회는 변경 전에 여러 팀의 종속성을 파악하는 데 도움이 됩니다.
- SOA와 마이크로서비스 기반의 느슨한 결합 아키텍처는 종속성과 의사소통 부담을 줄입니다.
- DevOps 팀의 기술 담당자는 종속성 및 개발과 배포의 순서를 파악해야 합니다.
- 공통 채팅 플랫폼으로 계속 소통하여 변경사항을 맞추고 다른 사람이 어떻게 이해했는지 파악하고 검토합니다.
- 마이그레이션이나 인프라 변경처럼 영향과 위험이 더 큰 변경에는 테스트 환경 리허설과 장애 조치 및 전체 롤백 메커니즘 등의 기술적 대응책이 필요합니다.
고성과 DevOps 조직은 동료 검토에 더 의존하고 외부 승인에는 덜 의존합니다
Amazon, Netflix, Etsy, GitHub를 비롯한 여러 선도적 DevOps 조직은 ‘Pull Request’ 검토 및 배포 프로세스를 사용합니다. 작동 방식은 다음과 같습니다.
- 개발자는 트렁크에서 별도 개발 브랜치를 만듭니다. 브랜치는 며칠의 영업일을 넘겨 유지하지 않고, ‘login-screen-v2’처럼 알아보기 쉬운 이름을 붙입니다. 개발자는 자신의 워크스테이션에서 로컬 브랜치를 작업하고 정기적으로 버전 관리 시스템에 체크인합니다.
- 개발 브랜치를 트렁크에 병합할 준비가 되었다고 판단하면, 검토 피드백을 받기 위해 풀 리퀘스트를 엽니다.
- 다른 DevOps 팀원에게 검토 피드백과 승인을 받은 후 코드를 트렁크에 병합합니다. 그런 다음 프로덕션 시스템에 코드를 배포합니다.
데이터베이스 스키마처럼 영향이 큰 변경이나 애플리케이션의 정보 보안에 영향을 줄 수 있는 변경이라면, 데이터베이스 관리자나 정보 보안 전문가 등 조직의 다른 분야별 전문가에게 추가로 풀 리퀘스트를 보내 의견을 받을 수 있습니다.
코드 검토에도 작은 배치의 원칙을 적용해야 합니다. 그렇지 않으면 검토가 오래 걸려 엔지니어에게 큰 부담이 됩니다. 변경이 클수록 위험은 기하급수적으로 커지고 검토의 신뢰성은 떨어집니다. 너무 크고 이해하기 어려운 변경이라면 개발자에게 작고 이해할 수 있는 여러 조각으로 나누어 달라고 요청할 수 있습니다.
직급과 경험 수준에 관계없이 모든 DevOps 팀원은 자신의 변경을 다른 사람이 검토하도록 해야 합니다. 모두가 커밋 흐름을 모니터링하여 잠재적 충돌이 배포 파이프라인이나 더 나쁘게는 프로덕션 배포에서 큰 문제를 일으키기 전에 빠르게 찾아 해결해야 합니다.
페어 프로그래밍을 단독으로 사용하거나, 한 개발자가 애플리케이션을 코딩하고 다른 개발자가 자동화된 테스트를 작성하는 테스트 주도 개발(TDD)과 결합하면, 코드를 쓰는 동안 동료 검토를 할 수 있습니다. 팀 규모와 프로젝트 요구사항이 같을 때 페어 프로그래밍은 시간이 15% 더 걸리지만 코딩 오류를 85% 줄이는 것으로 측정되고 검증되었습니다. 따라서 DevOps 팀이 도입을 검토할 만한 중요한 실무 방식입니다.
이 밖에 옆자리에서 함께 보는 코드 검토, 체크인 흐름에 대한 자동 알림, 코드 검토를 돕고 품질을 높이는 도구도 도입을 고려할 수 있습니다.
결론
조직의 모든 DevOps 팀이 자체 산출물의 품질을 책임지도록 하세요. 고품질 코드를 작성하는 일만큼이나 지속적이고 수준 높은 코드 검토를 중요하게 여기는 문화를 만드세요.
