2020.11.09

칼럼 | 비즈옵스(BizOps), 약인가 독인가?

정철환 | CIO KR
데브옵스(DevOps)가 IT시스템 운영 분야에서 관심의 대상이 된 때가 있었다. IT시스템 운영 부서와 소프트웨어 개발 부서간의 유기적인 연계와 통합을 통해 이상적인 시스템 운영과 개발 체계에 대한 관심 때문이다. 

데브옵스는 기본적으로 짧은 개발 사이클을 통해 비즈니스의 요구를 신속하게 대응하고 운영 부서가 유기적으로 운영을 지원하는 이상적인 통합 체계에 대한 구상이다. 하지만 필자가 2016년의 칼럼 ‘제조 기업 IT운영 담당자가 바라보는 '데브옵스'에서도 언급하였듯 대부분의 국내 기업 정보시스템 운영 조직은 이미 태생적으로 비즈니스 관련 소프트웨어 개발과 운영을 한 조직에서 수행하고 있는 상황으로 외국과는 달리 국내에서는 데브옵스가 많은 관심을 받지 않았다.

그런데 최근 필자는 국내 기업의 정보시스템 운영 분야에서는 데브옵스보다는 비즈옵스가 더 고민해 봐야 할 이슈가 아닐까 하는 생각이 들었다. 여기서 비즈옵스는 구글 검색을 하면 검색되는 그 의미는 아니라 필자가 다른 개념으로 조합한 의미다. 비즈옵스, IT시스템 운영과 비즈니스 업무 프로세스 역할이 오랜 기간 고정된 시스템 운영 아웃소싱으로 인해 시스템 운영 담당자에게 흡수 통합되어 있는 상태. 이것이 필자가 정의하는 비즈옵스다.

국내 IT 운영 아웃소싱 서비스는 1990년대부터 기업에 도입되기 시작했다. 이전까지는 회사내의 한 부서였던 전산팀이 별도의 독립 법인으로 분리되어 계약을 통해 시스템 운영을 담당하는 형태로 분화하였다. 지금은 거의 모든 대기업이 IT 운영 아웃소싱 서비스를 별도의 기업에 의뢰하고 있다. 이는 여러가지 장점이 있다. 전문인력의 시너지를 기대할 수 있고 개별적인 기업 하부 조직으로는 불가능한 수준 높은 IT 서비스 체계도 갖출 수 있다. 이를 통해 대한민국의 SI와 SM을 중심으로 한 IT 서비스 산업이 성장했다고 해도 과언이 아니다.

그런데 이런 체계와 우리나라 특유의 갑을 문화가 어우러지면서 비즈니스 협업과 IT시스템 운영 담당자 간의 고객과 담당자 관계가 형성되었다. 또한 이런 문화로 인해 IT 업계 종사자들 사이엔 소위 ‘갑’ 한번 해보는게 소원이라는 우스개소리도 생겨났다. 또 다른 관점에서 현업에 대한 시스템 운영 서비스를 제공하는데 있어 고객의 요구사항에 최대한 부응하려는 노력도 지속적으로 이루어졌다. 이런 결과로 현업에서 시스템 운영 및 개발 시 고민하고 결정하여야 하는 다양한 이슈들에 대해 시스템 운영자와 함께하거나 또는 현업이 바쁘다는 이유로 운영 담당자에게 많은 이슈를 의뢰하기 시작했다.

오늘의 기업 정보시스템은 비즈니스와 뗄레야 뗄 수 없는 관계다. 시스템에 업무 프로세스가 녹아 있고 시스템 기능과 업무는 매우 밀접한 관계다. 여기에 오랜 기간 같은 조직에 시스템 아웃소싱을 의뢰하는 경우가 대부분이어서 현업 부서의 담당자는 여러 번 바뀌었는데 시스템 운영 담당자는 그대로인 경우가 드물지 않게 되었다. 결국 현업의 비즈니스 프로세스와 기준 등에 대한 노하우가 상당부분 시스템 운영 담당자에게 녹아들어가게 된 것이다.

이렇게 되니 현업의 관점에서는 운영 담당자에게 시스템 기능 개선이 필요할 때 한마디만 해도 운영 담당자가 대부분의 내용을 이해하고 일사천리로 원하는 시스템 개발을 해 줄 수 있다. 이에 대한 긍정적인 면으로 비즈니스 요구사항에 대한 파악 및 시스템 구현의 처리 효율성이 높아진 것이다. 또한 현업 조직이 흔들리거나 담당자의 변경이 있을 때 시스템 운영 담당자가 비즈니스의 공백을 어느 정도 메꿔주는 것이 가능하다. 그렇다면 이런 비즈옵스 체계는 장점만 있을까?

우리나라의 소프트웨어 개발 문화에서 전통적으로 테스트 단계가 선진국에 비해 취약하다고 생각한다. 이론적으로 개발자와 테스터는 분리되어야 하며 명확한 테스트 계획서 등의 문서를 통해 개발자가 개발한 소프트웨어에 대해 독립된 테스터가 테스트를 하여야 하나 국내에서 대부분의 정보시스템 개발 시 개발자와 테스터가 동일하다. 가까운 일본만 봐도 전문 테스터의 역할로 한국의 IT인력이 많이 취업하였었던 것을 봐도 확실히 차이가 난다.

비즈옵스의 문제점도 위의 개발자와 테스터의 관계와 유사하다. 우선 시스템 운영자에게 과도한 의존성이 발생한다. 현업은 자신의 담당 업무에 대한 핵심 프로세스 및 의사결정기준을 시스템 운영자에 의존하게 된다. 이때 운영 담당자 또는 시스템 운영 조직의 변경이 필요한 경우 현업 업무 수행에 심각한 장애를 줄 수 있다.

하지만 더 중요한 점은 이런 의존성으로 인해 비즈니스 업무영역과 IT 운영에 대한 구분이 모호해 지면서 IT 운영 비용에 대한 체계적인 산정이 어려워진다. 다시 말해 시스템 운영 시 운영자의 역할이 어디까지인지, 개발에 얼마나 많은 공수가 들어가는지 분석이 쉽지 않게 되는 것이다. 그리고 기업이 시스템 운영 및 개발에 대한 객관적인 측정 데이터를 보유할 수 없다. 결국 운영조직의 인원수에 따른 비용 산정 방식이라는 오래되고 기본적인 방식에 의존할 수밖에 없다. 오래전인 2013년에 필자의 칼럼 ‘아웃소싱 대가 산정의 어려움’에서 언급한 내용과도 관련이 깊다.

데브옵스와 같이 비즈옵스 체계가 주는 장점도 분명하다. 하지만 이런 관계가 깊어지고 장기화되면 기업의 입장에서 객관적이고 실질적인 IT 아웃소싱 운영 비용을 산정하는 것은 점점 더 어려워질 것이다.

그렇다면 과도한 비즈옵스 체계를 지양해야 하는 것일까? 분명 효율적이고 신속한 개발과 운영 지원이라는 측면에서 비즈옵스 체계는 장점이 있다. 반면 객관적인 IT 운영비용 산정 및 거버넌스 측면에서는 문제점을 가진다. 독인가? 약인가? 의 여부는 각 기업의 상황과 시스템 운영 원칙에 따라 다를 것이다. 하지만 과도한 비즈옵스는 언젠가 기업의 고민거리로 대두될 수 있다. 선택은 여러분의 몫이다.

*정철환 팀장은 삼성SDS, 한양대학교 겸임교수를 거쳐 현재 제조업 IT기획팀장이다. 저서로는 <SI 프로젝트 전문가로 가는 길>과 <알아두면 쓸모 있는 IT 상식>이 있으며 삼성SDS 사보에 1년 동안 원고를 쓴 경력이 있다. 한국IDG가 주관하는 CIO 어워드 2012에서 올해의 CIO로 선정됐다. ciokr@idg.co.kr
 



2020.11.09

칼럼 | 비즈옵스(BizOps), 약인가 독인가?

정철환 | CIO KR
데브옵스(DevOps)가 IT시스템 운영 분야에서 관심의 대상이 된 때가 있었다. IT시스템 운영 부서와 소프트웨어 개발 부서간의 유기적인 연계와 통합을 통해 이상적인 시스템 운영과 개발 체계에 대한 관심 때문이다. 

데브옵스는 기본적으로 짧은 개발 사이클을 통해 비즈니스의 요구를 신속하게 대응하고 운영 부서가 유기적으로 운영을 지원하는 이상적인 통합 체계에 대한 구상이다. 하지만 필자가 2016년의 칼럼 ‘제조 기업 IT운영 담당자가 바라보는 '데브옵스'에서도 언급하였듯 대부분의 국내 기업 정보시스템 운영 조직은 이미 태생적으로 비즈니스 관련 소프트웨어 개발과 운영을 한 조직에서 수행하고 있는 상황으로 외국과는 달리 국내에서는 데브옵스가 많은 관심을 받지 않았다.

그런데 최근 필자는 국내 기업의 정보시스템 운영 분야에서는 데브옵스보다는 비즈옵스가 더 고민해 봐야 할 이슈가 아닐까 하는 생각이 들었다. 여기서 비즈옵스는 구글 검색을 하면 검색되는 그 의미는 아니라 필자가 다른 개념으로 조합한 의미다. 비즈옵스, IT시스템 운영과 비즈니스 업무 프로세스 역할이 오랜 기간 고정된 시스템 운영 아웃소싱으로 인해 시스템 운영 담당자에게 흡수 통합되어 있는 상태. 이것이 필자가 정의하는 비즈옵스다.

국내 IT 운영 아웃소싱 서비스는 1990년대부터 기업에 도입되기 시작했다. 이전까지는 회사내의 한 부서였던 전산팀이 별도의 독립 법인으로 분리되어 계약을 통해 시스템 운영을 담당하는 형태로 분화하였다. 지금은 거의 모든 대기업이 IT 운영 아웃소싱 서비스를 별도의 기업에 의뢰하고 있다. 이는 여러가지 장점이 있다. 전문인력의 시너지를 기대할 수 있고 개별적인 기업 하부 조직으로는 불가능한 수준 높은 IT 서비스 체계도 갖출 수 있다. 이를 통해 대한민국의 SI와 SM을 중심으로 한 IT 서비스 산업이 성장했다고 해도 과언이 아니다.

그런데 이런 체계와 우리나라 특유의 갑을 문화가 어우러지면서 비즈니스 협업과 IT시스템 운영 담당자 간의 고객과 담당자 관계가 형성되었다. 또한 이런 문화로 인해 IT 업계 종사자들 사이엔 소위 ‘갑’ 한번 해보는게 소원이라는 우스개소리도 생겨났다. 또 다른 관점에서 현업에 대한 시스템 운영 서비스를 제공하는데 있어 고객의 요구사항에 최대한 부응하려는 노력도 지속적으로 이루어졌다. 이런 결과로 현업에서 시스템 운영 및 개발 시 고민하고 결정하여야 하는 다양한 이슈들에 대해 시스템 운영자와 함께하거나 또는 현업이 바쁘다는 이유로 운영 담당자에게 많은 이슈를 의뢰하기 시작했다.

오늘의 기업 정보시스템은 비즈니스와 뗄레야 뗄 수 없는 관계다. 시스템에 업무 프로세스가 녹아 있고 시스템 기능과 업무는 매우 밀접한 관계다. 여기에 오랜 기간 같은 조직에 시스템 아웃소싱을 의뢰하는 경우가 대부분이어서 현업 부서의 담당자는 여러 번 바뀌었는데 시스템 운영 담당자는 그대로인 경우가 드물지 않게 되었다. 결국 현업의 비즈니스 프로세스와 기준 등에 대한 노하우가 상당부분 시스템 운영 담당자에게 녹아들어가게 된 것이다.

이렇게 되니 현업의 관점에서는 운영 담당자에게 시스템 기능 개선이 필요할 때 한마디만 해도 운영 담당자가 대부분의 내용을 이해하고 일사천리로 원하는 시스템 개발을 해 줄 수 있다. 이에 대한 긍정적인 면으로 비즈니스 요구사항에 대한 파악 및 시스템 구현의 처리 효율성이 높아진 것이다. 또한 현업 조직이 흔들리거나 담당자의 변경이 있을 때 시스템 운영 담당자가 비즈니스의 공백을 어느 정도 메꿔주는 것이 가능하다. 그렇다면 이런 비즈옵스 체계는 장점만 있을까?

우리나라의 소프트웨어 개발 문화에서 전통적으로 테스트 단계가 선진국에 비해 취약하다고 생각한다. 이론적으로 개발자와 테스터는 분리되어야 하며 명확한 테스트 계획서 등의 문서를 통해 개발자가 개발한 소프트웨어에 대해 독립된 테스터가 테스트를 하여야 하나 국내에서 대부분의 정보시스템 개발 시 개발자와 테스터가 동일하다. 가까운 일본만 봐도 전문 테스터의 역할로 한국의 IT인력이 많이 취업하였었던 것을 봐도 확실히 차이가 난다.

비즈옵스의 문제점도 위의 개발자와 테스터의 관계와 유사하다. 우선 시스템 운영자에게 과도한 의존성이 발생한다. 현업은 자신의 담당 업무에 대한 핵심 프로세스 및 의사결정기준을 시스템 운영자에 의존하게 된다. 이때 운영 담당자 또는 시스템 운영 조직의 변경이 필요한 경우 현업 업무 수행에 심각한 장애를 줄 수 있다.

하지만 더 중요한 점은 이런 의존성으로 인해 비즈니스 업무영역과 IT 운영에 대한 구분이 모호해 지면서 IT 운영 비용에 대한 체계적인 산정이 어려워진다. 다시 말해 시스템 운영 시 운영자의 역할이 어디까지인지, 개발에 얼마나 많은 공수가 들어가는지 분석이 쉽지 않게 되는 것이다. 그리고 기업이 시스템 운영 및 개발에 대한 객관적인 측정 데이터를 보유할 수 없다. 결국 운영조직의 인원수에 따른 비용 산정 방식이라는 오래되고 기본적인 방식에 의존할 수밖에 없다. 오래전인 2013년에 필자의 칼럼 ‘아웃소싱 대가 산정의 어려움’에서 언급한 내용과도 관련이 깊다.

데브옵스와 같이 비즈옵스 체계가 주는 장점도 분명하다. 하지만 이런 관계가 깊어지고 장기화되면 기업의 입장에서 객관적이고 실질적인 IT 아웃소싱 운영 비용을 산정하는 것은 점점 더 어려워질 것이다.

그렇다면 과도한 비즈옵스 체계를 지양해야 하는 것일까? 분명 효율적이고 신속한 개발과 운영 지원이라는 측면에서 비즈옵스 체계는 장점이 있다. 반면 객관적인 IT 운영비용 산정 및 거버넌스 측면에서는 문제점을 가진다. 독인가? 약인가? 의 여부는 각 기업의 상황과 시스템 운영 원칙에 따라 다를 것이다. 하지만 과도한 비즈옵스는 언젠가 기업의 고민거리로 대두될 수 있다. 선택은 여러분의 몫이다.

*정철환 팀장은 삼성SDS, 한양대학교 겸임교수를 거쳐 현재 제조업 IT기획팀장이다. 저서로는 <SI 프로젝트 전문가로 가는 길>과 <알아두면 쓸모 있는 IT 상식>이 있으며 삼성SDS 사보에 1년 동안 원고를 쓴 경력이 있다. 한국IDG가 주관하는 CIO 어워드 2012에서 올해의 CIO로 선정됐다. ciokr@idg.co.kr
 

X