개발자 / 애플리케이션

IT 운영에 애자일 방법론을 적용하는 3단계

Isaac Sacolick | InfoWorld 2020.03.24
애자일 방식은 애플리케이션 코딩과 테스트, 출시를 위해 전력 질주하는 소프트웨어 개발팀만의 전유물이 아니다. 다양한 기업, 데이터 과학, 그리고 IT 운영팀을 포함한 기술팀에서 스크럼과 칸반(Kanban)을 비롯한 애자일 방법론을 사용하고 있다.
 
ⓒ Getty Images Bank

애자일 방법론을 IT 운영에 성공적으로 적용하는 것이 매우 어려운 것은 아니다. 그러나 운영팀마다 원칙과 우선순위, 문화가 다르므로 그 차이를 고려해야 한다. IT 운영팀은 이와 같은 차이점을 이해한 다음 전략적 우선순위를 규정해 체계적으로 이니셔티브를 실행해야 다른, 여러 분야에 걸친 애자일팀에서 더 나은 구성원이 될 수 있다. 이 과정에서 고려해야 할 3단계는 다음과 같다.
 

IT 운영의 사명과 원칙 재정의

IT 운영팀 구성원이 생각하는 자신의 주 업무는 프로덕션, 부서, 개발 네트워크, 시스템, 애플리케이션, 데이터베이스를 정상적인 상태로 유지하는 것이다. 많은 이가 정보 기술 인프라 라이브러리(ITIL) 프로세스에 따라 사고, 문제에 대처하고 변화를 관리하며 셔웰(Cherwell), 지라 서비스 데스크(Jira Service Desk), 서비스나우(ServiceNow) 같은 티켓팅 시스템을 사용해 문제를 관리한다. 직원이나 기타 최종 사용자에게 도움이 필요한 경우 또는 다른 시스템 요구사항이 발생하는 경우에도 IT 운영팀은 이러한 시스템을 사용해 요청을 접수하고 워크플로우를 지원한다.

CIO는 보통 IT 팀에 대한 의존도가 높은 전략적 로드맵을 하나 이상 두고 있다. 또한 IT 운영팀이 주도적 역할과 보조적 역할을 모두 할 수 있는 모바일과 디지털 트랜스포메이션, 클라우드, 데이터 전략도 있다. 이 중 가장 중요한 것을 꼽는다면, 클라우드 마이그레이션, 인프라 프로젝트, 엔터프라이즈 시스템 업그레이드, SaaS 툴을 위한 새로운 지원 모델, 규정 준수 감사, 새로운 협업 및 워크플로우 툴 설치, ERP 업그레이드, 사무실 이동 등이 있다.

문제는 IT 운영이 이러한 이니셔티브에 연계된 작업을 어떻게 관리하느냐다. 애자일 방법론은 많은 경우, 특히 불분명한 선행 요건, 기술적으로 알 수 없는 부분 또는 우선순위의 충돌이 있는 상황에서 매우 효과적이다. 그러나 IT 운영 분야의 많은 이들이 애자일을 개발 방법론으로 인식하고 있으므로 중요한 사명, 책임의 범위, 작업 관리 방법에 관한 얼마간의 학습과 토론이 필요하다.

특히 IT 운영 담당자 상당수는 프로젝트 관리자의 지시를 따르는 데 익숙하다. 지금까지 운영 담당자는 솔루션을 설계하고 구현하는 최선의 방법을 지정하고 작업의 순서를 정하고 기술적으로 알 수 없는 부분으로 인한 위험을 완화하는 경험을 갖지 못했다. 애자일 방법론은 이러한 하향식 프로젝트 관리의 단점을 완화한다. 애자일 방법론은 엔지니어가 애자일 역할을 맡고 세리머니에 참여하고 애자일 툴을 사용해 새로운 작업 방식을 이해할 것을 요구한다.
 

IT 운영을 위한 애자일 방법론 재정의

애자일 리더는 스크럼이나 칸반을 IT 운영팀에 무턱대고 강요할 수는 없다. 문화와 운영 모델 간의 여러 중요한 차이점을 고려해야 한다. 이때 검토해야 할 몇 가지 단계는 다음과 같다.
 
  • 애자일 역할을 재정의한다. 대부분의 IT 조직은 이니셔티브에 제품 소유자를 할당하지 않는다. 기껏해야 요구사항을 쓰는 프로젝트 스폰서와 분석가를 두는 정도다. 일반적으로 제품 소유권 책임을 가지도록 하려면 얼마간의 교육과 지도가 필요하다. 가장 필수적인 것은 이니셔티브의 고객이 누구인지 정의하고 고객의 요구사항과 가치를 바탕으로 작업의 우선순위를 정하는 것이다.
  • 스토리와 수락 기준을 작성한다. 시스템을 다루는 엔지니어는 요구사항을 사용자 스토리로 작성하고 수락 기준을 정의하는 데 익숙하지 않다. 따라서 많은 엔지니어가 전체 목표를 이해한 다음 운용 가능한 최적의 솔루션을 찾는 식으로 진행한다. 그러나 요구사항을 미리 확실히 하는 것은 그만한 이유가 있다. 고객 또는 최종 사용자 관점에서 목표에 대한 이해를 공유한 후 비기능적 요구사항에 관한 수락 기준을 지정하는 데 도움이 되기 때문이다.
  • 우선순위를 정한다. IT 운영팀은 사고 및 이행 요청에 대한 대응 시간과 애자일 이니셔티브의 목표 사이에서 타협해야 한다. 개발자는 대부분의 작업을 애자일 팀과의 약속에 맞춘다. 그러나 IT 운영팀은 애자일 백로그 작업에 착수하기 전에 운영 우선순위에 맞춰 대응해야 한다. 많은 IT 운영팀은 우선순위를 표현하는 방법, 높은 우선순위의 사고에 가로막혀 중단될 수 있는 약속이 갖는 의미, 애자일 사용자 스토리를 추정하는 방법, 그리고 팀의 수용 능력을 측정하는 방법을 파악하는 데 어려움을 겪는다.
  • 적절한 애자일 방법론을 선택한다. 방법은 여러 가지지만 각 IT 운영에서 우선순위가 높은 작업 유형에 더 잘 맞는 방법이 있다. 규모가 작은 여러 이니셔티브를 추진하는 팀은 칸반을 사용하는 편이 유리할 수 있고, 요구사항이 복잡한 장기 이니셔티브를 진행하는 팀에는 스크럼이 더 나을 수 있다. 규모가 큰 조직이라면 최소한 이 두 가지 방법론은 지원하는 것이 좋다.
  • 역할을 이해한다. IT 운영팀은 여러 애자일 이니셔티브에서 다양한 책임을 맡는다. 이들은 인프라, 클라우드 마이그레이션, 보안 이니셔티브의 운전자 역할을 하며, 동시에 애자일 팀을 관할하는 역할과 책임을 맡는 경우가 많다. 데브옵스, 자동화 또는 데이터 거버넌스 이니셔티브 같은 경우 IT 운영팀은 운전자가 아닌 애자일 팀원으로 참여한다. 따라서 두 가지 시나리오 모두 팀과 프로그램에 대한 책임을 바탕으로 엔지니어가 참여하는 방법을 정의해야 한다.
 

애자일과 운영 툴의 통합

IT 운영팀은 이미 사고 및 요청을 관리하기 위한 시스템과 시스템 모니터링을 위한 플랫폼, 그리고 팀 협업을 촉진하기 위한 부가적인 툴을 사용하고 있다. 그러나 IT 서비스 관리(ITSM) 툴은 여러 주에 걸쳐 진행되는 이니셔티브를 추적하는 데는 적합하지 않다. 간트(Gantt) 차트나 스프레드시트로 복잡한 프로젝트를 관리할 경우 오히려 프로젝트 위험이 커질 수 있다. 따라서 운영 팀이 애자일 방법론을 도입하려면 애자일 작업 방식에 맞는 적절한 툴이 필요하다. 반면 새 애자일 프로젝트 관리 툴을 추가하는 IT 운영팀은 팀 프로세스와 시스템 간의 워크플로우와 데이터 통합을 고려해야 한다.

최선은 한 엔지니어의 관점에서 영향을 파악하는 것이다. 이들은 서비스 관리에는 파우와우 모바일(PowWow Mobile), 애자일 이니셔티브에는 지라(Jira), 협업에는 슬랙(Slack), AI옵스(AIops)에는 빅판다(BigPanda)를 사용할 수 있다. 작업의 우선순위, 진행 중인 작업의 상태를 기록하는 방법, 동료와 정보를 공유하는 툴을 별도로 사용해야 한다면 이 업무만으로도 부담이 될 가능성이 크다. 또한 만일 엔지니어가 애자일 팀과 함께 작업을 수행하다가 우선순위가 높은 사고에 대응하기 위해 팀에서 빠진다면 관계자 사이에서 혼란이 일어날 수 있다.

결국 IT 운영팀은 워크플로우와 데이터가 이러한 툴 사이에서 어떻게 연결되는지 고려해 폐회로 프로세스가 없도록 해야 한다. 예를 들어 서비스 데스크에서 사고가 발생해 IT 운영 애자일 팀이 대응한 후 모니터링 툴을 통한 검증을 요구할 수 있다. 이러한 과정을 3가지 이상의 기술을 통해 추적하려면 번거롭다. 그러나 이를 통합하면 오히려 데이터 품질이 개선된다.

여기서 살펴본 것은 문제는 시작일 뿐이다. IT 운영팀은 반드시 애자일 반복을 통해 무엇이 효과적이고 무엇을 바꿔야 하며 어떻게 하면 방법론을 발전시킬 수 있을지 끊임없이 논의해야 한다. editor@itworld.co.kr
 Tags 애자일

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

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

Copyright © 2024 International Data Group. All rights reserved.