Close

Atlassian이 소개하는 고속 ITSM에서 Jira Service Management와 다른 강력한 도구에 대해 자세히 알아보세요.

무료 등록

고속 ITSM에 준비되셨습니까?

팀이 변경 관리 역할 및 책임을 공유하는 방법

변경 관리 관행의 핵심 목표는 고객을 만족시키고 경쟁에서 앞서 나갈 수 있도록 업데이트를 제공할 때 인시던트를 줄이는 것입니다. 따라서 이 관행은 매우 중요합니다. 오늘날 고객들은 성능이 뛰어나고 상시 가동되는 서비스에 대한 높은 기대치를 가지고 있습니다. 점점 더 역동적인 환경에서 서비스를 신중하게 관리하고 개선 사항을 자주 제공하는 것이 중요합니다. 최신 팀은 위험을 완화하는 동시에 고객에게 최대한 간소화되고 애자일한 방식으로 가치를 제공하는 관행을 도입했습니다.

이러한 목표를 달성하기 위해 조직은 변경 관리와 관련된 다양한 역할과 책임을 지정했습니다. 대규모 엔터프라이즈에서는 다양한 직무 설명 및 팀 간에 이를 공유할 수 있습니다.

소규모 조직에서는 한 직원이 자신의 업무와 더불어 변경 관리 책임까지 맡을 수 있으며 개발자 또는 팀 리더가 변경 관리 책임을 맡을 수도 있습니다. 다른 경우에는 프로세스가 기존 팀 간에 느리게 구축되고 공유될 수 있습니다.

변경 관리 책임을 할당하는 데 적합한 하나의 모델은 없습니다. 조직은 요구 사항에 가장 적합한 설정을 마련해야 합니다. 즉, 모든 팀은 자신이 검토하는 프로젝트와 종종 거리가 먼 특정 직책을 가진 직원에게 변경 관리 책임을 위임하는 접근 방식을 다시 생각해 보는 것이 좋습니다.

기존 워크플로에 대한 관행을 자동화하고 간소화하는 새로운 기회를 받아들여 변경 관리에 관련된 직원들이 보다 전략적인 역할을 맡게 하고, 팀은 가장 중요한 우선 순위에 집중할 수 있는 시간을 확보할 수 있습니다.

일반적인 변경 관리 역할

변경 관리와 관련된 역할은 IT 조직의 규모 및 유형을 비롯한 다양한 요인에 따라 달라집니다. 가장 일반적인 직책은 다음과 같습니다.

변경 관리자/코디네이터

변경 관리자(변경 코디네이터라고도 함)는 일반적으로 IT 변경의 모든 측면을 관리하는 책임을 맡고 있습니다. 변경 요청의 우선 순위를 지정하고 그 영향을 평가하며 변경을 수락하거나 거부합니다. 또한 변경 관리 프로세스 및 변경 계획을 문서화합니다. 중요하게는 CAB 회의를 준비하고 구성하며 의장 역할을 합니다. 변경 관리자의 성공은 일반적으로 일정 및 예산 목표를 충족하는지 여부에 따라 평가됩니다.

변경 권한자/승인자

변경 권한자는 변경을 승인할지 여부를 결정하는 직원입니다. 관리자 또는 경영진과 같은 한 명의 직원인 경우가 있으며 때로는 변경 자문 위원회의 여러 직원이거나 동료 검토자가 될 수도 있습니다. ITIL 4에 따르면 “빠른 속도의 조직에서는 변경 승인을 분산시켜 동료 검토를 고성과를 예측하는 최고의 인자로 만드는 것이 일반적입니다.”

변경 관리자는 일반적으로 변경 권한자와 긴밀하게 협력하여 변경을 승인하고 조직 내에서 변경을 진행합니다. 일부 경우 특히 소규모 조직에서는 변경 관리자가 변경 권한자이며, 추가 인력이나 팀의 개입 없이 이러한 결정을 내릴 권한을 갖습니다.

비즈니스 이해 관계자

비즈니스 이해 관계자는 종종 변경 관리에 관여하며 승인 프로세스에 참여할 수 있습니다. 대부분의 엔터프라이즈에서 소프트웨어 서비스의 중요성을 감안할 때 이는 점점 더 보편화되고 있습니다.

예를 들어 변경이 재무 팀의 결제 추적 소프트웨어와 영업 팀의 CRM 간의 연결에 영향을 미치는 경우 재무 팀 및 영업 팀의 이해 관계자가 CAB 회의 및 변경에 대한 최종 결정에 관여해야 할 수 있습니다.

엔지니어/개발자

개발 팀은 일반적으로 승인을 받기 위해 변경을 제출하고 필요에 따라 사례를 문서화합니다. 직접 구축하고 직접 운영한다는 접근 방식을 취하는 회사에서는 변경이 승인되면 개발 팀이 변경 사항을 배포하고 모니터링하며 변경과 관련된 모든 인시던트 또는 문제에 응답하는 경우가 많습니다. 다른 경우에는 변경으로 인해 발생한 인시던트를 담당하는 인시던트 관리 팀이 변경 사항을 구현하는 개발자와 구분될 수 있습니다.

서비스 데스크 에이전트

서비스 데스크 에이전트는 변경으로 인해 발생할 수 있는 인시던트 및 일반적인 서비스 이슈에 대해 고유한 최전선 관점을 제시할 수 있습니다.

운영 관리자

운영 관리자는 매일 시스템을 계속 운영해야 할 책임이 있으므로 위험과 종속성을 고려합니다.

고객 관계 관리자

고객 관계 관리자는 고객의 목소리를 대변하기 위해 고객의 사고 방식, 불만 사항을 비롯해 끊임없이 변화하는 요구 사항에 대한 정보를 제공할 수 있습니다.

정보 보안 책임자 및 네트워크 엔지니어

네트워크 보안 및 클라우드 인프라 전문가는 위협과 취약성에 대한 중요한 인사이트를 제공합니다.

CAB(변경 자문 위원회)의 역할 변화

CAB란 무엇입니까?

위에서 설명한 책임을 가진 직원들을 소집하는 CAB(변경 자문 위원회)는 각 변경 요청의 위험을 평가하고 이를 승인 또는 승인하지 않는 임무를 맡은 그룹입니다. 일반적으로 CAB는 예정된 모든 변경 사항을 검토하기 위해 정기적으로 회의를 열고 필요에 따라 전문가를 초빙하여 변경에 대해 설명, 변호 또는 평가합니다. 기존 CAB는 변경의 릴리스를 제어하는 게이트키퍼(gatekeeper)라고 알려져 있습니다.

이러한 이유를 비롯해 지루한 회의, 긴 변경 요청 백로그 및 업무 자체와의 적은 연관성 때문에 CAB를 간과하는 경우가 많습니다. 다행히 많은 CAB가 보다 전략적인 자문가 역할을 맡아 애자일 소프트웨어 제공을 더 잘 지원할 수 있도록 발전하고 있습니다. CAB는 변화 추세를 모니터링하고, 이를 해결할 수 있는 관행을 권장하며, 팀이 고객에게 가치를 제공하고 위험을 줄일 수 있는 더 나은 방법을 모색하는 자문가로 거듭나고 있습니다.

CAB의 당면 문제

효과적이지 않은 회의를 둘러싼 진부한 표현도 CAB에 적용됩니다. 시간을 낭비하고, 충분히 성과를 내지 못하고, 너무 많은 직원을 무작위로 참여시키며, "이메일로 대신 진행할 수도 있는 부분"이라고 CAB를 비판하지만 이는 타당한 의견입니다. 부분적인 이유는 기존 CAB가 맡은 책임으로 인해 과중한 부담을 겪었기 때문입니다.

비행기에 비유하여 이 문제를 설명해 보겠습니다. CAB를 공항의 관제탑이라고 생각할 수 있습니다. 이 관제탑에는 한 가지 임무가 있습니다. 비행기가 착륙할 수 있는 시점이 언제인지 알리는 것입니다. 비행기가 구조적으로 안전한지 또는 조종사가 올바른 자격증을 보유하고 있는지 평가하는 임무는 없습니다. 이러한 요소는 FAA 및 다른 책임자들이 이미 확인했기 때문입니다.

한편, 너무 많은 CAB가 다양한 이해 관계자를 모으고 모든 종류의 다양한 변경에 대해 광범위하고 안전한 의사 결정을 내리는 임무를 맡고 있습니다. 게다가 피로에 지친 직원들은 주말에 휴식을 취하고 싶어 하지만 CAB 회의는 주말에 진행되는 경우가 많습니다. CAB가 성공할 수 있는 환경이 전혀 마련되지 않았습니다.

또한 CAB는 인시던트를 유발하는 변경의 위험에 주로 관심을 갖습니다. 물론 이것도 중요하지만 중요한 변경이 지연되는 위험도 고려해야 합니다. 너무 느리게 진행하면 고객에게 피해를 줄 수 있으며 경쟁이 치열한 SaaS(Software as a Service) 세계에서 조직은 침몰할 수밖에 없습니다.

CAB의 역할에 초점을 맞춰 개선할 수 있습니다. 올바른 관행만 마련되면 많은 변경을 자동화할 수 있습니다. 이러한 방식으로 CAB는 추세를 추적하고 고객에게 이익이 되는 더 빠른 변경을 가능하게 하는 방법에 대해 팀과 협력하는 중요한 자문가가 될 수 있습니다.

CAB를 전략적 자문가로 포지셔닝하는 방법

CAB를 다시 포지셔닝하는 첫 번째 단계는 과도한 변경 관리가 긍정적인 결과를 가져온다는 개념을 없애는 것입니다. 2019년 State of DevOps 보고서의 데이터에 따르면 CAB 승인이 필요한 프로세스는 소프트웨어 제공 성능에 부정적인 영향을 미쳤으며 이러한 프로세스를 따르는 응답자는 성과가 낮을 가능성이 2.6배 더 높았습니다. 또한 공식 승인 프로세스가 변경 실패율 감소와 관련이 있다는 증거도 없었습니다!

이러한 이유로 최신 팀은 CAB를 개선하기 위해 다음과 같은 조치를 취하고 있습니다.

변경 요청을 “어디에나 적합한 단 하나의” 방식으로 처리하지 않음

모든 변경 요청은 정보를 추적하고 수집할 수 있는 기회입니다. 성공률, 관련 인시던트 및 이와 관련된 요인에 대해 알아볼 수 있습니다. 시간이 지남에 따라 데이터를 적용하면 점점 더 많은 변경을 사전 승인하고 자동화할 수 있으며 가장 중요하고 위험한 변경만 대면 승인을 받아야 합니다.

변경 및 릴리스 관리를 더 긴밀하게 통합

릴리스에 대한 레거시 접근 방식은 릴리스를 번들로 묶어 한 번에 제공하는 것이었습니다. 그런 다음 CAB는 엄청난 양의 변경 패키지를 힘들게 검토하고 승인해야 합니다. 이러한 접근 방식은 주요 인시던트로 이어질 수 있으며 인시던트가 발생할 때 문제의 원인을 찾기도 더 어려워집니다. 또한 팀이 고객에게 가치를 제공할 수 있는 속도도 느려집니다. 이는 또한 변경 및 릴리스 관리자가 프로젝트 관리 작업에 할당할 수 있는 시간이 더 적다는 의미입니다.

점진적 릴리스를 사용한 테스트 및 반복

점진적 릴리스는 전체 배포 전에 안정성을 테스트하고 입증하기 위해 소규모 사용자 하위 집합에 카나리아 또는 기능 플래그를 배포합니다. 이는 잠재적 인시던트의 범위를 제한하고 모든 환경에 배포하기 전에 배포의 성공을 입증합니다.

자동화 및 도구를 사용한 변경 관리 간소화

빠른 속도의 팀은 이전 승인 모델을 다시 생각하기 시작했습니다. 주간 대면 회의에서 긴 변경 요청 백로그를 처리하는 대신 가상 공동 작업을 활용할 수 있습니다. CAB 회의 전에 검토할 수 있도록 변경 요청을 자세히 설명하는 이메일처럼 간단할 수 있습니다. 다른 경우에는 Jira 티켓 및 Confluence 페이지와 같은 기능을 통해 변경 검토자가 비동기식으로 협업하고 변경을 승인하는 데 필요한 컨텍스트를 제공할 수 있습니다. 팀은 Jira Service Management를 사용하여 이러한 방식으로 협업하고 화상 회의에 참여하거나 지정된 Slack 채널을 만들 수도 있습니다. 팀이 선호하는 소통 방식에 따라, 같은 곳에 보관되므로 모두가 같은 정보를 공유할 수 있습니다.

레거시 ITSM 도구를 사용하면 인프라, 운영 및 개발 팀이 변경 요청을 제기하기가 어렵습니다. 변경 정보를 수동으로 입력하는 부담을 줄이려면 자동화 및 최신 소프트웨어를 살펴보세요. 작업을 자동으로 추적할 수 있는데도 별도의 복잡한 시스템에서 티켓을 입력하는 일은 개발자가 가장 원하지 않는 일입니다. 팀은 Jira Service Management에서 자동화를 통해 변경 프로세스를 간소화하고 위험을 최소화하며 가동 중지 시간을 줄일 수 있습니다.

변경 관리를 실행자와 더 가깝게 만들어 조기 단계에 처리

CAB 승인을 대체하거나 줄이는 가장 일반적인 전략 중 하나는 동료 검토입니다. 동료 검토는 코드를 가장 잘 이해하는 직원에게 코드 이슈를 식별하도록 책임을 맡깁니다. ITIL 4는 “빠른 속도의 조직에서는 변경 승인을 분산시켜 동료 검토를 높은 성과를 예측하는 최고의 인자로 만드는 것이 일반적입니다”라고 설명합니다. 마찬가지로 2019년 State of DevOps 보고서는 “조직은 개발 프로세스 중에 동료 검토 기반 승인이 이뤄지도록 '조기 단계에 처리'해야 한다”고 권장했습니다.

규정을 준수하려면 이 접근 방식을 꼼꼼하게 문서화해야 합니다. Bitbucket와 같은 시스템을 도입하여 작성자와 동료 검토를 자동으로 추적하고 필요한 프로세스 없이 변경 사항이 실시간으로 푸시되지 않도록 해야 합니다.

Atlassian에서 동료 검토는 승인 프로세스의 핵심 부분입니다. IT 위험 및 컴플라이언스 전문가는 다음과 같이 설명합니다. “모든 Atlassian 코드는 Bitbucket에 저장됩니다. 개발자는 변경하고 싶을 때 자신의 노트북에서 Bitbucket으로 코드를 확인합니다. 코드를 다시 Bitbucket 리포지토리로 확인할 때 시스템은 코드를 업데이트하는 대신 동료 검토를 요구하도록 설정되어 있습니다. 검토가 완료되고 승인된 후에만 코드가 다시 리포지토리로 돌아갑니다. 코드가 승인되지 않으면 어떻게 될까요? 동료 검토자의 메모와 함께 원래 개발자에게 다시 전송됩니다. 개발자는 잘못된 부분을 수정한 후 또 다른 동료 검토를 받기 위해 제출합니다."

전문가를 소집하여 좋은 관행 지원

조직이 점점 복잡해짐에 따라 팀 간의 정보 흐름과 조정을 지원하는 것이 점점 더 중요해지고 있습니다. CAB는 개별 변경 요청을 승인하는 대신 관행을 개선하는 데 집중할 수 있습니다. 이 패러다임에서 CAB는 관행 개선에 대한 권장 사항을 제공하고, 더 나은 기능을 구현하며, 보다 향상된 성능을 발휘하는 리소스와 도구를 제공할 수 있습니다. 이것은 CAB의 범위를 확장하여 시장에 가치를 제공하는 속도가 너무 느릴 수 있는 위험을 해결합니다.

기존의 IT 조직에서도 CAB는 창의적인 솔루션을 제시하는 장소가 될 수 있습니다. 한 예로, 레거시 ITSM 도구 및 관행을 고수하며 위험을 회피하는 성향을 가진 한 대학에서는 학생들에게 앞으로 중요한 서비스를 사용할 수 없다는 사실을 알릴 방법을 찾아야 했습니다. CAB는 새로운 커뮤니케이션 전술을 브레인스토밍하는 포럼이 되었습니다. 그들은 사탕과 포스터를 배포하기로 했으며, 이 캠페인은 계획된 시스템 업그레이드에 대해 들어오는 요청을 줄이는 데 효과적이었습니다.

조직의 변경 관리 관행에 대한 책임 할당

변경 관리 관행에서 역할과 책임을 정의할 때는 모든 상황에 맞는 단 하나의 해결책은 없다는 사실부터 이해해야 합니다. 회사의 문화, 팀 구조, 사용 가능한 기술, 규제 요구 사항 등을 고려해야 합니다.

비즈니스에 필요한 역할과 책임에 대한 진정한 지지를 얻으려면 역할 및 책임 플레이를 실행하는 것이 좋습니다. 여기에는 모든 직원이 함께 모여 팀에 대한 각 팀원의 기여도를 이해하고 성공하기 위해 필요한 것이 무엇인지 모든 직원이 파악하는 과정이 포함됩니다.

변경 관리의 컨텍스트에서 역할과 책임을 개선하려면 먼저 팀을 한데 모아 아래 질문에 대해 논의하는 것이 좋습니다.

  • 다양한 프레임워크가 우리 팀에 어떤 의미가 있습니까? DevOps, CI/CD, ITIL 등
  • 프레임워크를 전체적으로 수용했습니까? 우리의 이해가 자동화와 같은 전술적인 요소에만 국한되어 있습니까?
  • 이러한 프레임워크, 특히 DevOps 및 ITIL은 변경 및 릴리스 관행에 어떤 영향을 미치며 어떻게 함께 작용하고 있습니까?
  • 현재의 변경 프로세스는 무엇입니까?
    • 누가 참여합니까?
    • 어떻게 개선할 수 있습니까?
    • 더 많은 일반 변경을 표준 또는 사전 승인으로 전환하려면 어떻게 해야 합니까?
      • 가장 일반적인 변경은 무엇입니까?
      • “표준 변경”은 어떤 변경입니까?
      • 어떤 서비스에 영향을 미칩니까?
      • 어떤 변경이 성공적이었습니까?

변경 관리는 중요한 관행이며 앞으로도 계속 필요할 것입니다. 변경 관리 관행의 상태에 관계없이 개선의 여지는 항상 있습니다. 변경을 추적하여 시작할 수도 있고, 위험 평가 및 자동화 시스템을 구현하여 시작할 수도 있습니다. Jira Service Management의 변경 관리 기능이 어떻게 IT 운영 팀에 권한을 부여하는지 알아보세요.