개발자

애자일 데브옵스 부서가 일선 IT 서비스 데스크를 지원하는 5가지 방법

Isaac Sacolick  | InfoWorld 2020.09.28
애자일 개발 부서는 혁신적인 기능 개발을 목표로 하고, 데브옵스 부서는 코드를 프로덕션 단계로 좀더 자주 릴리즈하려는 곳이다. 그런데 정작 책임은 애플리케이션 사건과 문제, 요청에 대응해야 하는 IT 서비스 데스크와 고객지원 부서가 지는 경우가 많다.

결함이나 성능 병목 현상 또는 보안 문제가 있는 채로 릴리즈를 너무 자주 해버리면 최종 사용자가 겪는 사고가 늘어나 서비스 부서와 지원 부서가 감당이 안되는 지경에 빠질 수 있다. 데브옵스 부서도 안정적인 변경사항을 배포할 때에도 지원 부서가 양질의 고객 서비스나 최종 사용자 지원을 제공하도록 지원할 책임을 지고 있다.
 
ⓒ Getty Images Bank

실제로는 어떤 모습일까? 전반적인 배포 성공 여부에 관한 지원 부서의 피드백이 있고 문제에 대한 파악이 되기 전까지는 프로덕션 배포를 완료 상태로 표시하지 않는 종합적인 릴리즈 관리 프로세스를 필요로 한다.

이 정도의 수준의 협업을 달성하기 위해서 애자일 부서는 데브옵스 문화에 전념하면서 다음과 같은 모범 사례를 고려해야 한다.
 

1. 고품질 릴리즈의 기대치를 규정하고 설정할 것

당연해 보이지만 실제로는 이 목표를 실천하지 못하는 개발 부서가 많다. 그 이유는 환경이 복잡하기 때문이기도 하고 기능을 지나치게 빨리 릴리즈해야 하는 업무적인 요구가 있거나 테스트에서의 간극이 있기 때문이기도 하다.

필자는 특히 문화적 간극을 발견할 때가 너무 많다. 오늘 코드를 릴리즈했는데 결함이나 최종 사용자 지원 문제 때문에 하루나 이틀 뒤에 패치해야 한다면 애초의 릴리즈를 성공이라고 볼 수 있을까? 그렇지 않을 것이다. 데브옵스 부서가 일단 릴리즈를 했다면 배포의 품질이 높아서 부서가 그 다음으로 우선적으로 해야 할 개발 작업으로 넘어갈 수 있다는 기대가 있다. 패치나 긴급 오류 수정 릴리즈, 핫픽스 또는 일정에 없던 배포를 실행해야 하는 상황이라면 애초의 릴리즈를 실패한 배포, 또는 수준 낮은 배포로 분류해야 한다.

이러한 원칙에 따라 데브옵스 부서는 애플리케이션 흐름 검토, 테스트 자동화 개선, 좀 더 강력한 테스트 데이터 집합 개발, 원점 회귀 보안 테스트 채택, 피처 플래깅에의 투자 등에 나서게 된다.
 

2. 배포 일정을 소통하고 릴리즈 노트를 공유할 것

고객지원 부서와 IT서비스 데스크 부서에 배포 일정을 물어보면, “우리 부서는 개발 계획을 가장 나중에 알게 되는 경우가 많다”는 대답이 돌아올 것이다. 고객지원과 IT 서비스 데스크 직무 종사자는 데브옵스 부서에서 릴리즈 계획 및 실행에 사용하는 지라(Jira), 마이크로소프트 부서즈, 젠킨스(Jenkins) 등 도구에 접근할 수 없는 경우가 많다. 계획된 배포, 실행된 배포에 대해 지원 부서에 통보하려고 데브옵스 부서에서 이메일 알림을 구성해 줄 때도, 이메일과 릴리즈 노트는 별로 도움이 안되는 기술 전문 용어투성이인 경우가 많다.

데브옵스 부서는 계획, 릴리즈, 배포 때문에 소통하거나 협업할 때 상대에게 구체적으로 맞춰야 한다. 서비스 데스크 부서와 고객지원 부서를 대상으로 한 소통에서는 릴리즈가 최종 사용자에게 어떻게 영향을 미치는지에 주안점을 두어야 한다.

또한, 데브옵스 부서는 변경사항이 최종 사용자에게 미칠 영향을 예상하여 지원 부서를 교육시켜야 한다. 애플리케이션의 사용자 경험이나 워크플로가 크게 달라지는 경우, 초기에 지원 부서에 변경 사항을 직접 검토하고 파악하고 경험할 기회를 준다면 지원 부서가 지원 프로세스를 업데이트할 때 도움이 된다. 
 

3. 애플리케이션 모니터링과 AI옵스에 투자할 것

2가지 경우를 상정해 보자. 한 데브옵스 부서는 멀티클라우드 환경을 모니터링하면서 서버와 저장장치, 네트워크, 컨테이너에 발생하는 문제를 파악한다. 애플리케이션 로그를 중앙집중화한 반면, 보고서나 알림은 구성하지 않았으며, 애플리케이션 모니터를 설정하지도 않았다. 사고나 문제가 최종 사용자에게 영향을 미칠 때, IT 운영부서와 현장 안정성 엔지니어(Site Reliability Engineering) 또는 데브옵스 부서에 문제를 보고하는 것은 서비스 데스크 부서와 지원 부서인 경우가 많다.

IT 운영 부서에서 구성하는 시스템과 애플리케이션 알림이 너무 많은 것도 좋은 것은 아니지만, 극단적인 상황까지는 아니다. 한 건의 사건으로 수십 건의 모니터와 알림이 촉발될 수 있다. 그러면 기본 원인을 파악하여 행동 방침을 선택하기가 어려워진다. 이 경우에는 IT 부서가 빅 판다(Pig Panda)나 무그소프트(Moogsoft) 같은 AI옵스(AIops) 솔루션을 실행하면 도움이 된다. AI옵스 솔루션은 알림을 취합한 후 머신 러닝 기술을 적용하여 모니터링 데이터의 상관관계를 파악하고, 일반적인 문제의 해결 단계를 자동화한다.

최종 사용자에게 미치는 영향을 최소화하고 애플리케이션 사건을 위해 지원 티켓을 열어야 하는 조건을 줄이는 것이 목표여야 한다.
 

4. 셀프 서비스 관리 도구와 질의 기능, 그리고 보고서를 제공할 것

또 하나의 애플리케이션 개발 원칙은 최종 사용자를 지원할 보고서나 워크플로 또는 관리 도구가 없는 기능은 릴리즈하지 않아야 한다는 것이다. 애자일 제품 소유자는 우선적으로 기능 개발을 하는 데는 빠르지만 지원 기능 투자에는 느릴 때가 있다.

서비스 데스크 또는 지원 부서가 질의 실행, 데이터 내보내기, 데이터베이스에서의 데이터 수동 변경 또는 일괄 처리 작업 실행 등을 위해 IT의 다른 영역과 티켓을 열어야 한다면 ‘만족할 만큼 훌륭하지는 않은’ 것이다. 모두 운영 부채 또는 기술 부채의 한 형태에 해당한다.

따라서 애자일 제품 소유자는 서비스 데스크와 지원 부서를 다른 이해관계자처럼 대해야 하며, 그들이 필요하는 것을 알아내고 우선시해야 한다. 어떤 도구가 필요한지, 언제 새 기능이 투자를 받는지 또는 언제 기존 기능이 향상되는지를 애자일 원칙 또는 거버넌스로 규정하는 것이 이상적이다.
 

5. 서비스 데스크 티켓을 검토하고 결함 해결을 우선적으로 할 것

IT 임원들이 개발 부서에게 데이터 위주로 하라는 요청을 할 경우, 서비스 데스크와 고객 지원 부서에게 보고되는 문제와 요청에 대한 정기적인 검토 일정을 잡는 것으로 시작하는 것이 좋다. 서비스 데스크 티켓팅 시스템에서 온 결합 또는 기능 요청이 애자일 개발 부서의 백로그로 가는 흐름을 데브옵스 부서가 자동화하는 것이 이상적이다.

애자일 개발 부서는 이 피드백을 이용해 자사 백로그에 대한 우선 순위를 정해야 한다. 피드백 활용, 특히 고객과 최종 사용자의 피드백을 활용하는 것은 스크럼 등 애자일 방법론의 핵심 신조이기도 하다.

개발 부서는 이러한 문제를 여러 관점에서 바라봐야 한다. 시스템 문제 일부는 개선을 우선시하기 쉬워서 다수의 최종 사용자에게 영향을 미치거나 여러 개의 서비스 데스크 티켓을 만들어내기가 쉽다. 마치 건초 더미 속에 숨은 바늘처럼 드물기는 해도 여전히 전략적 고객이나 중대한 비즈니스 프로세스에 영향을 미치는 시스템 문제도 있다.

이러한 문제를 모두 해결하기에는 개발 부서에 할당된 시간에 한계가 있지만, 다른 대안, 간단한 운영 도구, 더 나은 다큐멘테이션으로 서비스 데스크 직원을 지원할 수도 있을 것이다.

지원 부서와 서비스 데스크에서, 그리고 일선에서 고객과 최종 사용자와 일하는 사람들에게 공감을 해주는 것만으로 충분할 때도 있다. 따라서 새로운 기능을 추가하거나 CI/CD 파이프라인을 개선하고 새로운 기술을 활용하기에 앞서, 최종 사용자 만족도를 향상하고 서비스와 지원 부서를 지원할 수 있는 모범 사례를 먼저 고려하는 것이 좋다. editor@itworld.co.kr 

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.