DevOps 텍스트 교육
DevOps 피드백을 어떻게 활성화해야 하나요?
고객의 요구와 요청이 갈수록 어려워지는 IT 환경에서 본인과 DevOps 팀은 업무 품질을 계속 개선해야 합니다. 이를 위해 가치 흐름에서 오른쪽에서 왼쪽으로 전달되는 빠르고 지속적이며 신뢰할 수 있는 피드백 루프를 만듭니다.
피드백 루프를 통해 장애물이 아직 작고 저렴하고 제거하기 쉬울 때 신속히 해결할 수 있습니다. 일하면서 조직의 학습 문화를 만드는 데도 도움이 됩니다. 문제가 발생하면 DevOps 팀은 이를 배움과 소프트웨어 제품 및 서비스의 품질 개선 기회로 받아들입니다.
DevOps 피드백 루프로 품질을 내장해야 하는 이유는 무엇인가요?
소프트웨어 엔지니어링 경험에서 이미 알 수 있듯이 복잡한 시스템에서 한 사람이 모든 것을 알 수는 없습니다. 똑같은 일을 두 번 해도 결과가 같지 않을 수 있습니다. 어떤 비즈니스도 이 정도의 불확실성을 감당하기 어려워, 체크리스트, 감사, 규정 준수, 품질 보증 전문가 및 세부적 관리를 통해 품질 보증에 의존하고 통제하는 장치를 만듭니다. 그런데도 이런 조치가 실수와 오류를 피하기에 충분하지 않을 때가 있습니다.
따라서 품질을 내장하는 조직을 만들려면 먼저 실수와 오류를 일상 업무의 일부로 받아들여야 합니다.
안전한 작업 체계를 중시하는 문화 만들기
안전한 작업 체계를 중시하는 문화를 만듭니다. DevOps 팀에서 실수를 두려워하는 사람은 없습니다. 오류가 아직 작을 때, 큰 결함이나 서비스 중단 또는 고객의 부정적 평가 같은 심각한 결과를 낳기 전에 신속히 찾아 수정한다는 점을 팀이 알기 때문입니다.
안전한 작업 체계의 문화를 만들면 본인, DevOps 팀, 그리고 IT 및 비즈니스 조직 전체가 다음과 같은 이점을 얻습니다.
- 시스템의 복잡성을 관리할 수 있어 설계와 운영의 문제를 빠르게 발견합니다.
- 문제가 작을 때 빠르게 해결합니다. 문제를 해결하는 과정에서 새로운 조직 지식과 경험이 자연스럽게 축적됩니다.
- 새 지식과 경험이 조직 전체에 퍼지고 공유됩니다.
- DevOps 조직의 리더는 안전한 작업 체계를 구축하고 지속적으로 개선하는 다른 리더를 육성합니다.
문제 발생 즉시 파악하기
조직의 피드백이 느리고 드물고 늦으면 바람직하지 않은 결과를 예방하는 데도 시간이 많이 들고 비용이 커집니다. 예전 폭포수 방식에서는 애플리케이션을 1년간 개발한 뒤 처음 고객에게 보여 주고 다시 1년간 작성했습니다. 오늘날 어떤 기업도 이런 방식으로 일할 여유는 없습니다.
목표는 빠른 피드백 루프를 만드는 것입니다. 가치 흐름에서 업무가 왼쪽에서 오른쪽으로 이동하면, 피드백이 계속 오른쪽에서 왼쪽으로 전달되어야 합니다. DevOps 조직에서 품질을 내장하는 핵심은 빠른 피드백 주기입니다. 문제를 일으키는 변경이 들어오면, 팀은 가치 흐름에서 문제가 처음 발생할 때 파악합니다. 문제를 빠르게 수정하고, 내부 및 외부 고객과 업무의 영향을 받는 가치 흐름의 모든 이해관계자의 기대에 구현 내용이 맞는지 계속 확인합니다. 빠른 피드백은 문제를 신속히 수정하는 것은 물론, 문제에서 배우고 앞으로 같은 오류를 방지하는 데 도움이 됩니다.
더 쉽고 빠르고 저렴하게 고칠 수 있을 때 오류 해결하기
문제를 빨리 찾으면 빨리 수정할 수 있습니다. 그렇지 않으면 다음과 같은 일이 생깁니다.
- 오류를 고치는 비용과 노력이 기하급수적으로 늘고, 기술 부채(임시방편 위에 임시방편을 쌓는 일)가 누적됩니다.
- 오류가 가치 흐름의 후속 작업 단계로 넘어가 다른 오류가 생길 가능성이 커집니다.
- 처음 오류가 발생한 작업 단계에서 멀리 떨어진 곳에서 오류가 되풀이되며, 이를 되돌리려면 더 많은 수정과 작업이 필요합니다.
- 오류가 처음 왜 생겼는지 기억은 흐려지고 오류를 일으킨 상황도 달라집니다. 오류가 발생한 지 몇 달 뒤에야 찾으면 진짜 근본 원인을 알기 어렵고, 그보다 나쁘게는 배울 수도 없습니다. 당장 하루를 넘기려고 임시방편을 쓰고 다음 임시방편으로 넘어갑니다. 이것이 DevOps로 피하고자 하는 바로 그 상황입니다.
DevOps 팀과 본인이 목소리를 내고 오류를 파악해 빠르게 수정할 지속적인 피드백 장치를 마련하도록 하세요. 잘못된 작업 위에 잘못된 작업을 더해서는 안 됩니다. 즉, 새 기능 개발에 악영향을 줄 오류를 고치기 전에 새 기능을 만들게 하지 마세요. 계속 품질을 개선하고 오류가 발생할 때마다 없애면 해당 시장에서 최고의 소프트웨어 제품과 서비스를 만들 수 있습니다.
품질 관리 의사결정은 실제로 일하는 곳에서 내리세요
품질 관리에 관한 결정을 실제 업무 수행 현장에서 멀어지게 하면 품질이 떨어지고 제공 리드 타임이 길어집니다. 원인과 결과 사이의 피드백이 약해지고 실수에서 배우는 능력도 줄어듭니다.
간단히 말하면 다음과 같습니다.
- 자동화할 수 있는 품질 관리 작업을 팀에 수동으로 요구하지 않습니다.
- 해당 작업에 관한 지식이 거의 없거나 전혀 없는 바쁜 사람의 승인을 요구하지 않습니다.
- 업무 특성상 곧 쓸모없어질 방대한 승인용 문서를 작성하지 않습니다.
- 많은 작업을 한꺼번에 승인권자에게 넘기지 않습니다.
DevOps 팀원 모두는 자신이 통제할 수 있는 범위에서 오류를 찾아 수정하고 공유하고 논의하며 가르쳐야 합니다. 페어 프로그래밍, 동료 검토, 자동화된 테스트, 코드 체크인 검사, 내부 점검, 잦은 시연을 통해 품질 보증을 전담 부서만이 아닌 모두의 책임으로 만드세요.
결론
본인과 DevOps 팀은 고객에게 서비스를 제공하기 위해 급여를 받는다는 것을 늘 의식합니다. 따라서 내부 및 외부 고객에게 가장 이로운 방향으로 일해야 합니다.
가치 흐름에서 바로 다음의 작업 단계는 특히 중요합니다. 그들의 입장에서 생각하며 업무를 개선하세요. 그들과 빠르고 안정적인 피드백 흐름을 구축해 가치 흐름이 빠르고 원활하며 높은 품질을 유지하도록 하면, DevOps 팀이 문제를 최대한 빨리 찾아 해결할 수 있습니다.
