지속적인 품질 살펴보기
지속적인 품질은 DevOps 분류의 8가지 기능 중 하나입니다.
지속적인 품질이 필요한 이유 알아보기
품질 및 지속적인 품질이 중요한 이유를 보여주는 예시를 살펴보겠습니다.
일본은 자동차 회사들에 영향을 미친 엄격한 품질 보증 프로그램을 채택했습니다. 이 프로그램 덕분에, 그들은 매우 효율적이고 신뢰할 수 있는 자동차를 생산하여 경쟁사와 차별화되는 명성을 얻었습니다.
일본의 자동차 회사들은 더 높은 품질의 제품을 사용해 자신들을 차별화함으로써 연비, 안전, 제조 공정에서 혁신을 이룰 수 있었습니다. 품질 향상에 따라 고장률이 낮아져 비용도 줄었습니다. 경쟁 업체들은 뒤따라 갈 수밖에 없었습니다.
그럼, 어째서 품질이 중요할까요?
- 제품이 팔립니다.
- 비용이 절감됩니다.
- 경쟁자와 차별화됩니다.
지속적인 품질의 주요 이점은 다음과 같습니다.
- 품질에 대한 연대 책임감을 촉진하는 ‘품질 우선’ 마음가짐.
- 결함으로 인한 잦은 재작업을 하지 않아 낭비 절감.
- 품질 요건 미충족으로 인한 기술적인 문제가 점차 줄어듦.
- 고객 만족도 향상.
- 비즈니스를 방해하는 인시던트 감소.
개발 주기에서 최대한 빨리 품질에 주력한 경우 시간과 노력을 크게 아낄 수 있습니다.
코드를 더 늦게 병합할 수록, 문제를 더 늦게 발견할 수록, 해결하는 데 더 많은 비용이 듭니다. 투자 수익률을 살펴보겠습니다.
- 개발 단계에서 결함을 발견하면 5배의 비용이 듭니다.
- 통합 테스트에서 결함을 발견하면 10배의 비용이 듭니다.
- 사용자 승인 테스트에서 결함을 발견하면 15배의 비용이 듭니다.
- 제품 릴리스 후에 결함을 발견하면 30배의 비용이 듭니다.
이 이야기의 교훈은 일찍이 품질에 투자하라는 것입니다!
지속적인 품질로 품질 문화 육성하기
지속적인 품질은 품질 문화를 조성하여 팀이 다음을 수행할 수 있습니다.
- 우수한 사용자 환경 조성
- 시장의 타이밍에 맞는 기능 빌드
- 기술적인 문제가 발생하기 전에 가치를 제공하는 애플리케이션의 기능을 활성화
더 많은 버그를 찾아서 수정할 수록 품질이 향상된다는 잘못된 추정을 주의하는 것도 중요합니다.
처음부터 버그를 만들지 않았다면, 찾을 버그도 없었을 것입니다. 하지만 인간인 우리는 실수를 하고 버그를 만들 것입니다. 우리가 직접 만든 버그를 찾으면 품질이 향상된다는 사고에서 벗어나야 합니다.
스스로 물어보세요. 누가 버그를 만들고 있나요? 제품 소유자, 스토리 작가, 디자이너, 건축가, 코드 작성자, 테스터 등 그야말로 모든 사람이 버그를 만듭니다.
지속적인 품질은 품질 문화를 조성하는 일일 뿐만 아니라 마음가짐의 문제입니다. 세상에 더 큰 변화를 만들기 위해 매일 배우고 최선을 다하려는 열정이 필요합니다.
지속적인 품질 마음가짐은 다음과 같은 특징이 있습니다.
- 성장과 혁신을 장려하고, 품질 중심 행동을 활성화하고 육성하는 문화를 조성합니다.
- 품질은 내재되어 있어야 하지 나중에 개선하는 것이 아님을 기억합니다.
- 새로운 기능보다 품질을 중시합니다.
- 팀워크를 중시합니다.
- 상품에 책임을 집니다.
- 테스트에 치중하지 않습니다.
품질 보증에서 지속적인 품질로의 전환
전통적인 품질 보증에서 지속적인 품질로 전환하는 것은 중요한 패러다임 변화입니다. 다음 표가 이 둘의 차이를 보여 줍니다.
전통적인 품질 보증 | 지속적인 품질 | |
---|---|---|
이유 | 시스템 중단 | 시스템 개선 |
구성할 항목 | 기능 점검 | 시스템 해석 |
누가 | 테스터의 책임 | 팀 전원의 책임 |
When | 마지막 단계에서 테스트 | 전체 단계에서 테스트 |
Where | QA 스테이지 | 모든 범위 |
어떻게 | 문제 찾기 | 문제 방지 |
결과 | 최소 품질 | 품질 개선 |
지속적인 품질의 과제 및 위험에 대해 인지하기
지속적인 품질 | 과제 및 위험 |
---|---|
사일로 효과와 전통적인 하향식 관리 구조는 도입 속도를 저해할 수 있습니다. 이러한 문제는 조직 완성이 자리잡고 필요한 문화적 변화가 조직 전반에 걸쳐 일어나며 DevOps의 관행과 프로젝트가 성숙해져야 극복할 수 있습니다. | |
지속적인 품질을 위해서는 관련자 모두가 참여해야 하며, 그들에게 반발할 수 있는 권한을 부여해야 합니다. 뚜렷한 목표의 부재와 미지에 대한 두려움 또한 반발을 야기할 수 있습니다. 조직 전체가 지속적인 품질 마인드를 갖추기 위해서는 고위 경영진의 지원이 필수적입니다. | |
지속적인 품질을 소프트웨어 개발에 도입하려면 역할 책임에 대한 변화와 조직 문화의 변화가 필요합니다. 해당 변화에는 상당한 투자와 시간이 들기 때문에 일정에 차질이 생기고 전문 수준에 도달하기 전까지는 생산성이 저하될 것입니다. 하지만 디지털 시스템의 품질을 향상시키기도 합니다. | |
도구와 기술 덕분에 지속적인 품질이 가능하지만, 문제가 있어도 기술이 다 해결해 줄 거라고 바라서는 안됩니다. 도구는 프로세스를 자동화하고 지원하지만, 지속적인 품질을 위해서는 조직 문화가 변해야 합니다. 프로세스가 없는 경우 공급업체의 프로세스가 유용하길 바라야 합니다. | |
지속적인 품질은 새로운 협업 및 커뮤니케이션 모델을 사용하고 품질 공동 책임을 촉진함으로써 광범위한 조직 변화의 지렛대가 될 수 있습니다. 그러나 연속 통합과 테스트에만 기술적인 초점을 맞춘다면, 조직은 바라던 이점을 누릴 수 없을 것입니다. | |
측정은 필수적이지만, 단일 품질 메트릭만 지나치게 강조하면 직원들이 해당 메트릭은 개선하겠지만 기업의 다른 목표나 심지어 고객 만족도가 간과될 수 있습니다. 조직이 자신들에게 지속적인 품질이 갖는 의미를 모른다면, 이를 파악하느라 시작 단계에서 여러 번 실패할 수 있습니다. 그리고 조직이 초기에 성공을 거두지 못하면 지속적 품질이 제공할 수 있는 유익한 문화적, 협력적 변화를 추구하는 일을 단념할 수 있습니다. |