디지털 트랜스포메이션과 시스템 마이그레이션
기사 제목을 보자마자 촉이 왔다. '옛날 전공이네' 하는 식의 촉1)
생각보다 복잡한 클라우드 마이그레이션, 자동화 하려면?
시스템 마이그레이션이란 무엇인가?
기사가 양질2)이라는 것을 확인할 수 있는 문단이 등장했다.
우선 현재 운용중인 레거시 유닉스 시스템은 곧바로 클라우드로 이전하기 어렵다. 일단 리눅스 기반 시스템으로 마이그레이션 한 이후 다시 클라우드로 이전해야 한다. 이처럼 2단계를 거치면서 자산파악, 분석, 마이그레이션, 테스트, 인증 등을 진행해야 하기 때문에 다양한 문제가 불거진다. 현황 파악단계에서는 나타나지 않았던 연관시스템이 등장하기도 하고, 존재하는지도 몰랐던 시스템이 나타나기도 하며, 예상한 것보다 비용이 급증하기도 한다. 조직이 크고 업무와 시스템의 복잡성이 클수록 클라우드 마이그레이션 난이도는 기하급수적으로 늘어난다.
하나씩 풀어보자.
먼저, 유닉스에서 리눅스 기반으로 마이그레이션 한다. 이 말은 어떤 의미를 지닐까? 여기서 마이그레이션이란 응용 프로그램 구동을 위해 필요한 운영 체제를 바꾸는 일이다. 그런데,마이그레이션이란 표현으로 필요한 행동을 모두 담을 수 있다면, 예상과 다른 결과를 목격할 경우가 많다. 그 얘기는 차차 하기로 하고, 예전에 다운사이징이라고 불렀던 메인프레임에서 유닉스로 바꾸던 때보다 나은 모습이라 마이그레이션 이라 칭할 수 있다. 그 기저에는 유닉스와 리눅스가 공통 분모가 많아 주요 소프트웨어의 호환성을 보장해준다는 기술적 배경이 있는 것이다.
하지만, 마이그레이션이라는 행위가 단순히 기술자들이 뚝딱 해낼 수 있는 일로 생각하면 잘못된 기대를 할 가능성이 높다. 인용한 기사에서도 이러한 일이 벌어졌음을 암시하는 문장이 등장한다.
그러나 한 달이 다 지나도록 이 CIO는 제대로 된 답변을 듣지 못했다.
그렇다면 무엇을 알아야 하는가? 처음 인용한 문단에서 자산파악이라는 표현이 나온다.
자산파악은 어떻게 하는가?
기사를 읽는 분이 저기서 말하는 자산이 무엇인지 알면 좋지만, 그럴 확률은 매우 낮다. 구글에서 자산으로 검색해보라. 5천만개 문서가 나오지만, 그 중에서 기사의 자산과 뜻이 같은 내용을 찾는 일은 정말로 어려운 일이다. 기사에는 또 인벤토리란 말을 쓰고 있다. 부연 설명이 없는 이유는 업계에서 저런 표현들은 글로벌 솔루션 업체나 컨설팅 업체의 제품과 서비스를 타고 해석 없이 들어와 관행으로 쓰이고 있는 실정이기 때문이다.
해석이 없다고 표현한 것은 마땅히 개념의 주인이 되어야 할 기업이 충분히 해석하지 않고 있다는 점을 꼬집은 것이다. 제품이나 서비스 제공 업체에게 알아서 해달라고 하면 진짜로 알아서(?) 해주게 된다. ㅋㅋㅋ
아는 것이 힘이니까. 여기서 간단히 해석을 해드리겠다. ;)
Github을 아시나요?
필자가 가장 많은 Like를 받았던 popit 글이 있다. 소프트웨어를 모르는 대한민국 기업의 위기란 제목의 글이고, JetBrain 행사의 키노트 기회까지 만들었던 글이다. 이 글을 읽는 분들을 둘로 나눌 수 있다. Github을 아시는 분(써보신 분으로 대체로 개발자로 분류할 수 있다.)과 들어 봤지만 안 써봤거나 아예 모르는 분으로.
https://bit.ly/2tLIbKU
먼저, github를 모르는 분들은 아래 링크 중 하나를 골라서 보고 듣거나 읽으시길 빈다.
이제 github에 대한 최소한의 이해는 있다고 가정하고 글을 쓴다.
개발자 입장에서는 내가 만든 코드들이 github 저장소에 들어있다. 그리고, github는 코드를 단순 보관하는 것 뿐 아니라 권한 관리를 통해 보호해주는 역할도 한다. 그리고, 그러한 코드에 대해 개발자 사이에서 소통할 수도 있고, 변화 상황에 대한 이력도 남길 수 있게 해주고, 복원도 가능하게 해준다. 뿐만 아니라 더 큰 묶음으로 코드를 다룰 수 있게 해준다. 우리가 눈에 보이는 물건을 창고에서 다룰 때, 박스에 넣고 선반에 올리고 컨테이너에 넣는 일을 하는 것과 그대로 대응시켜 볼 수 있다. 그렇다. 바로 개발자가 코드를 자산으로 관리할 수 있게 해준다. 개발자에게 코드는 자산이다. 개발팀이나 개발회사에게는 말할 것도 없다. 물론, 개발자들은 자산 관리란 금융업자에게나 어울릴 말을 쓰지는 않는다. 그렇다면 기사의 자산 관리는 무엇인가?
개발을 직접하지 않을 때 자산관리는?
이렇게 이야기를 풀면 ITIL 같은 특수한 지식을 알 필요없이 인용한 기사의 자산관리에 대해 이야기 해볼 수 있다. 즉흥적인 글 치고는 잘 끌고 온 것 같다. (잠시 자뻑)
개발을 직접하지 않고 외주 업체에 맡기는 곳에서는 소스코드를 상대적으로 덜 소중하게 다룬다. 당연하다. 내가 만든 것이 아닌데, 알게 뭔가? 다른 관점으로 보면, ITO 혹은 IT 기획만 하는 기업들이 있는데, 여기서는 계약에 의존하여 블랙박스로 자산 관리를 하게 된다. 블랙박스로?
블랙박스 자산관리가 뭐냐?
즉흥적으로 만든 것이니까 설명이 필요하다. (자뻑을 저질렀더니 수세에 몰렸다. 역시 겸손이 필요해.)
내용을 모르는 상황을 우리는 블랙박스라고 말하곤 한다. 요즘은 차량에 설치된 기계를 부를 때 더 많이 쓰지만. 프로그램 작성을 남에게 의뢰해서 만든 경우라면 계약 이행의 결과로 코드를 받게 된다. 당연한 이치라고 이해하실 수 있다면 좋겠다. 유사 경험이 없는 분도 이를 이해할 수 있을까?
암튼, 마트에서 물건 사듯이 소프트웨어를 샀다면, 프로그램이 돌아가기 위해서 일단 내가 까막눈이더라도 코드가 존재한다는 사실만 아시면 된다. 이렇게 구입(외주 개발)한 프로그램은 자산이 된다. 이때는 회계 개념으로 봐야 한다. 비용이 아니라 계속 사용할 수 있는 장비와 같은 것인데 형태가 소프트웨어일 뿐이니까.
이렇게 블랙박스로 자산을 관리하면 소스코드에는 둔감해지고, 잘 돌아가는지만 다루게 된다. 그런데 소스코드에서 돌아가는 프로그램 형태로 가는 과정이 아주 단순하지가 않다. 심지어 클라우드와 모바일이니 IoT니 하는 기술 변화로 지금 이순간도 계속해서 복잡해지고 있다.
그래서, 소프트웨어 자산관리가 재무부서나 총무부서가 다루는 다른 자산처럼 관리할 수 있는 것이 아니다.
코드에서 실행 프로그램으로 가는 과정
아~ 망했다. 설명의 절벽에 도달했다. 독자가 개발자가 아니라고 가정하면, 이 부분은 어떻게 설명할 수 있을까? 아니 설명을 꼭 해야할까? 설명해서 무엇을 전달할 수 있을까 난감한 지점이다. 일단, 묻지마로 설명을 시도해보자.
소스코드와 돌아가는 코드는 무슨 차이가 있을까? 개발자들에게는 설명할 필요가 없는 일이지만, 이 글은 개발자가 아닌 분들도 읽기를 바란다.
공장에서의 제품 생산 과정에 비유해보자. 소스코드는 원재료라 말할 수 있다. 앞서 말한 github 혹은 비슷한 도구(git, svn, cvs 등등)로 부품을 1차 조립한다. 필수단계다. 그리고 나서 개발자들이 흔히 통합(integration)이라 부르는 행위를 한다. jenkins 라는 도구가 널리 쓰이는데 무료라 그렇고, 다수의 CI라고 불리는 비슷한 도구들이 있다. CI의 C는 Continuous의 약자로 통합을 지속적으로 하기 위한 자동화를 내포한 표현이다. 그렇게 한 후에 배포(deployment)라는 과정을 밟는다.
배포는 이렇게 작성한 코드가 서버나 데이터베이스와 잘 맞물려 돌아가는지 확인하는 과정이자 사용 가능한 시스템을 만드는 과정이다. 작성 주체를 기준으로 보면 배포는 개발자가 만든 것과 이미 존재하는 소프트웨어(서버, 데이터베이스, 시스템 소프트웨어 등) 혹은 데이터(데이터페이스의 레코드, 서버의 설정 등)와 미세 조정을 하는 단계라고 볼 수 있다.
너무 멀리 왔나?
일단, 여기서 독자분들의 이해를 위한 기준을 그어보자. 소프트웨어 개발 과정이 대형 공장만큼이나 복잡하다는 사실을 이해하셨는가? 전기를 많이 쓴다는 점을 제외하고는 노동집약적인 친환경(?) 공장이고, 제품이 소프트웨어 형태로 도대체 어딘지 모르는 다양한 곳에 배포되어 유통된다는 혼미한(Cloud) 세상을 만들어간다는 점을 제외하면... 소프트웨어 개발 과정은 공장에서 벌어지는 일만큼이나 체계적이고 복잡하다.
최종 결과만 갖고 우리는 무엇을 알 수 있을까?
다시 기사로 돌아오면, 기사를 이렇게 시작한다.
국내 한 금융권의 CIO(최고정보책임자)는 디지털 트랜스포메이션을 위해 자사 정보시스템을 클라우드로 옮길 계획을 세웠다.
디지털 트랜스포메이션을 위해 자사 정보시스템을 클라우드로 옮기는 시도는 많이들 쓰는 방법이지만, 나라면 다른 식으로 문제를 정의할 것이다. 무엇가 의미가 있을 것이라고 큰 작업을 시도부터 하기 전에 과정을 통해 배우는 전략을 권하고 싶다. 문제는 생각보다 간단치 않다. 마이그레이션을 시도하다 보면, 소스코드가 없는 형태로 돌아가는 시스템이 존재하기도 한다. 만든 사람이 사라졌고, 누군지도 모르는데 어떻게 분석을 할 수 있을까? 못한다.
뭐야? 협박처럼 들리잖아? 필자가 마이그레이션을 반대하려는 것은 아니다. 필요한 활동이다. 다만, 목표나 문제가 무엇이냐에 따라 전혀 다른 전략이 필요하다는 것이다. 어려운 일을 하시는 분들께 스트레스를 낮추고 할 만한 일로 만드는 아기발걸음(또, 아기발걸음이냐?)을 알려드리려는 것이다.
디지털 트랜스포메이션과 시스템 마이그레이션
필자가 다른 매체에 기고한 글이 있다. 거기서 필자는 이렇게 강조했다.
‘정보화 할 물질을 정의하는 주체가 누구인가’하는 질문이다. 디지털 트랜스포메이션은 기술과 깊은 연관성을 갖고 있지만 기업의 제품이나 서비스 혹은 기업활동에 대한 변형이 그 본질이다. 따라서 미래를 이끌어갈 기업 구성원이 정의하는 주체가 되어야 한다. 생소한 일이다 보니 전문성을 앞세워 외부 컨설턴트에 의존할 수 있지만 외부인은 전환기에 일시적인 도움을 줄 수 있을 뿐이다. 시장 변화에 따른 위협을 직감하는 경영 일선에 있는 이들이 주도해서 정보화 대상을 정의해야 한다.
시스템 마이그레이션이 다른 목적이 아니라 디지털 트랜스포메이션의 일환이라면, 반드시 마이그레이션을 클라우드 전문가에게 모두 맡기지 말고 조직 구성원이 주도하게 하라. 시스템 전문가가 아닌 사람들이 하는 대표적인 오해는 시스템을 정의할 때 사용자와 사용 기업을 시스템에 포함시키지 않는 것이다.
최초 인용한 기사 내용에서 말하는 자산 관리는 돌아가는 프로그램의 이름(대부분 익명의 외국 개발자가 만든 것)으로 붙여지는 것이 아니라 우리 회사에서 어떤 기능을 담당하고 어떤 비즈니스 효과를 갖는 것인지 드러나는 이름을 붙일 수 있어야 한다. 누가 그렇게 하냐고? 이렇게 생소하지만 해야 하는 일이 바로 디지털 트랜스포메이션이다. 예전부터 하던 방식 그대로를 클라우드 위에서 하는 일은 마이그레이션이긴 하지만 그것은 디지털 트랜스포메이션과는 전혀 무관한 활동이다.
주석
[1] TMI일 가능성이 높아서 자세히 설명하지 않습니다. 궁금한 분은 별도로 연락하세요.
[2] 기사 후반부는 서비스 소개에 그치고 있어 용두사미 느낌이 나기는 해도 요즘은 팩트 체크조차 하지 않는 기사가 많으니까.