2020.05.29

IBM 기고 | 오픈소스 전환시 고려해야할 7가지

이상영 | CIO KR
한때 빌 게이츠로부터 “새로운 종류의 공산주의”라는 비판을 듣기도 했던 오픈소스 소프트웨어 운동이 이제는 거역할 수 없는 대세로 자리잡고 있다. 오픈소스는 클라우드라는 또다른 흐름을 만나 이를 비판했던 기업조차도 최근 적극 수용하고 투자하는 양상이다. 

이러한 움직임 속에서 IT 전문가라면 한번쯤은 오픈소스 도입과 전환 과제를 고민했을 터다. 오픈소스 도입에 대해 고려하는 기업들을 위해 도입 과정에서 공통적으로 겪는 문제와 도입에 앞서 고려해야 할 사항에 대해 그간의 경험에 기반해 정리해본다. 

최근, 한국IDG가 진행한 오픈소스 도입 현황에 대한 조사(오픈소스 기업에 안착하다, 2020.02) 결과를 보면, 국내에서는 오픈소스 기술지원에 대한 어려움과 오픈소스로의 전환을 위한 전략과 로드맵 수립을 큰 어려움으로 생각하고 있는 것으로 나타난다. 

응답군에 따라 이는 약간의 차이를 보이고 있는데, 이미 오픈소스를 도입한 응답군에서는 기술지원의 부족을, 아직 도입전인 응답군에서는 오픈소스 전환 전략 수립을 가장 어려워하는 부분으로 들고 있다. 이러한 결과는 전통적인 형태의 IT 운영 조직에서 태생과 지향점이 다른 오픈소스를 수용하는데 있어 발생하는 문제점일 것이다. 

즉, 개발자 간의 협업과 궁극적인 개방성을 지향하는 오픈소스를 서비스 운영의 안정성을 최고의 모토로 생각하는 IT 운영조직에서 수용하려 할 때 발생하는 문제이다. 근본적인 문제를 해결할 수는 없지만, 그간의 경험으로 볼 때 아래 고려사항들을 유의한다면 프로젝트 중에 발생하는 혼란을 줄이는데 도움이 될 수 있을 것이다.

첫째, 전환 계획에 앞서 현재의 IT 시스템에 대한 충분한 파악이 이뤄져야 한다. 프로젝트를 시작할 때 현재의 상태를 정확히 파악할 방법과 시간을 사전에 정의하지 않고 간과하기 쉽다. 실제로 필자는 많은 전환 프로젝트들에서 이러한 부분을 고려하지 않고 시작했다가 현상태 파악에 많은 시간이 소요되어 납기가 지연되는 어려움을 종종 겪었다. 현 시스템 아키텍처에 대해 정리된 문서가 있는지, 어플리케이션 별로 소스코드가 존재하는지 등에 대해 본격적인 시작에 앞서 미리 파악해야 한다.

둘째, 서비스와 시스템간의 종속 관계를 고려하여 우선 순위를 정하고 전환 로드맵을 작성해야 한다. 대부분의 IT 운영자들이 오픈소스 전환을 고려할 때 DB나 WAS등의 단위시스템을 1:1로 오픈소스 솔루션으로 전환하는 방법을 생각한다. 

그러나, 실제 진행할 때는 서비스와 시스템간의 종속 관계가 존재하므로 독립적인 단위시스템 단위로 전환하는 것은 쉽지 않다. 위에서 말한 것처럼, 현 시스템 아키텍처에 대해 사전에 정확한 파악이 이루어져야 하며 서로간의 종속 관계에 대한 아키텍처 다이아그램을 작성하여 우선 순위를 정해야 한다. 이를 작성하다보면, 전환의 대상이 단순한 단위시스템이 아니라 서비스 단위라는 것을 깨닫는 데에는 오랜 시간이 걸리지 않는다.

셋째, 장기적인 관점에서 전환 로드맵을 마련하여야 한다. 결국, 빅뱅 형태의 전면 차세대 재개발 형태로 프로젝트를 추진하지 않을 것이라면, 전환 리스크를 줄이기 위해서는 서비스 단위의 점진적인 전환이 고려되어야 한다. 이는 어느 한 시점에서의 전면적인 전환이 아닌, 여러 차수에 걸친 오픈소스 전환이 일어나야 함을 의미한다. 

따라서, 이러한 과정은 장기적인 시간을 요구하게 되며, 이에 맞는 로드맵 작성이 중요하게 된다. 일단, 로드맵이 완성되면 현 시스템 아키텍처 다이아그램을 사용하여 리스크를 다시 계산해보고, 반복적인 최적화 과정을 거쳐 최적의 전환 로드맵을 수립할 수 있을 것이다.


Migration Decision Tree(예시)

넷째, 전환 과정은 단순한 솔루션 전환만을 의미하지는 않는다. 서두에서 말했듯이, 오픈소스는 그 태생부터 이제까지 만나왔던 상용 솔루션들과는 다른 출발점에 서 있었다. 전환과정에서 겪는 어려움들 중 많은 부분들이 이러한 ‘다름’을 인정하지 않는 데에서 발생하는 경우가 많다. 

단적인 예로, 오픈소스 기반의 개발 툴들은 대부분 화두가 되고 있는 CI(Continuous Integration)/CD (Continuous Delivery) 사상 하에서 설계되었다. 이를 도입하기 위해서는 기존의 개발 방법론 및 전략을 수정해야할 수도 있다. 오픈소스 도입이 디지털 트랜스포메이션의 초석이 되는 기대 효과를 누리고자 한다면 여러분의 조직이나 프로세스도 어느 정도는 변화를 수용해야 할 것이다.

다섯째, 총소유비용(TCO)은 장기적인 관점에서 고려해야한다. 대부분의 IT관련자들이 오픈소스 전환을 통해 비용 절감 효과를 기대한다. 이중 가장 큰 부분이 연간 단위로 갱신되는 라이선스 비용의 절감에서 발생하게 되는데, 총소유비용 계산 시에 3년 이내의 단기간으로 계산 기간을 설정하게 되면 초기에 발생하는 마이그레이션 비용이 라이선스 절감 효과를 상쇄하는 현상이 발생할 수도 있다. 갱신 횟수를 감안하여 5년 정도의 기간을 두고 이를 산출해보는 것이 바람직할 것이다.

여섯째, 전환 기간 중 다양한 방법의 비용 절감 방안을 고려해본다. 몇 가지 예로, 커뮤니티 버전에 대한 활용과 전환 기간 중 한시적으로 오픈소스 운영에 대한 아웃소싱을 통해 인건비를 절감하는 방법을 들 수 있다. 장기적인 로드맵에 따라 전환 과제를 수행할 때 최종 전환까지의 중간 단계에서는 라이선스 비용의 절감을 위해 커뮤니티 버전을 사용할 수 있다. 

다만, 이에 대한 기술 지원이 문제가 될 수 있는데 시중에는 이를 지원하는 업체들이 존재한다. 또한, 전환과정에서 한시적으로 오픈소스 운영 인력을 아웃소싱하여 현재의 IT인력이 역량을 갖출 때까지 추가 인력의 충원 문제를 해결하는 것도 고려해볼 수 있다.

일곱째, 전문 업체를 통해 전환 프로젝트를 수행하는 경우, 건 단위가 아닌 전체 프로젝트에 대한 장기 계약을 고려해보아야 한다. 최근까지 국내에서 진행된 전환 프로젝트들은 과제별로 단기간의 프로젝트를 전문 업체와 계약하여 진행하는 경우가 많았다. 이렇게 진행할 경우, 프로젝트 이후 기술지원 문제, 프로젝트 중 사전에 인지하지 못했던 타시스템과의 종속성 발견 등으로 어려움을 겪는 경우들이 많이 발생한다. 따라서, 비용 효과를 고려하여 전환 프로젝트와 기술 지원을 묶어 장기 계약을 고려해보는 것이 바람직하다.

이제, 오픈소스 전환은 단순한 비용 절감 차원을 넘어서, 디지털 트랜스포메이션의 초석으로서 기업 IT에 필수적인 요소가 되고 있다. 모쪼록, 이 글에서 제시된 고려사항들이 오픈소스 전환 과정 및 준비 과정에서 조금이나마 도움이 되기를 바란다.

* 이상영 실장은 한국IBM 글로벌 테크놀러지 서비스에서 멀티클라우드 서비스 리더로 재직 중이다. ciokr@idg.co.kr



2020.05.29

IBM 기고 | 오픈소스 전환시 고려해야할 7가지

이상영 | CIO KR
한때 빌 게이츠로부터 “새로운 종류의 공산주의”라는 비판을 듣기도 했던 오픈소스 소프트웨어 운동이 이제는 거역할 수 없는 대세로 자리잡고 있다. 오픈소스는 클라우드라는 또다른 흐름을 만나 이를 비판했던 기업조차도 최근 적극 수용하고 투자하는 양상이다. 

이러한 움직임 속에서 IT 전문가라면 한번쯤은 오픈소스 도입과 전환 과제를 고민했을 터다. 오픈소스 도입에 대해 고려하는 기업들을 위해 도입 과정에서 공통적으로 겪는 문제와 도입에 앞서 고려해야 할 사항에 대해 그간의 경험에 기반해 정리해본다. 

최근, 한국IDG가 진행한 오픈소스 도입 현황에 대한 조사(오픈소스 기업에 안착하다, 2020.02) 결과를 보면, 국내에서는 오픈소스 기술지원에 대한 어려움과 오픈소스로의 전환을 위한 전략과 로드맵 수립을 큰 어려움으로 생각하고 있는 것으로 나타난다. 

응답군에 따라 이는 약간의 차이를 보이고 있는데, 이미 오픈소스를 도입한 응답군에서는 기술지원의 부족을, 아직 도입전인 응답군에서는 오픈소스 전환 전략 수립을 가장 어려워하는 부분으로 들고 있다. 이러한 결과는 전통적인 형태의 IT 운영 조직에서 태생과 지향점이 다른 오픈소스를 수용하는데 있어 발생하는 문제점일 것이다. 

즉, 개발자 간의 협업과 궁극적인 개방성을 지향하는 오픈소스를 서비스 운영의 안정성을 최고의 모토로 생각하는 IT 운영조직에서 수용하려 할 때 발생하는 문제이다. 근본적인 문제를 해결할 수는 없지만, 그간의 경험으로 볼 때 아래 고려사항들을 유의한다면 프로젝트 중에 발생하는 혼란을 줄이는데 도움이 될 수 있을 것이다.

첫째, 전환 계획에 앞서 현재의 IT 시스템에 대한 충분한 파악이 이뤄져야 한다. 프로젝트를 시작할 때 현재의 상태를 정확히 파악할 방법과 시간을 사전에 정의하지 않고 간과하기 쉽다. 실제로 필자는 많은 전환 프로젝트들에서 이러한 부분을 고려하지 않고 시작했다가 현상태 파악에 많은 시간이 소요되어 납기가 지연되는 어려움을 종종 겪었다. 현 시스템 아키텍처에 대해 정리된 문서가 있는지, 어플리케이션 별로 소스코드가 존재하는지 등에 대해 본격적인 시작에 앞서 미리 파악해야 한다.

둘째, 서비스와 시스템간의 종속 관계를 고려하여 우선 순위를 정하고 전환 로드맵을 작성해야 한다. 대부분의 IT 운영자들이 오픈소스 전환을 고려할 때 DB나 WAS등의 단위시스템을 1:1로 오픈소스 솔루션으로 전환하는 방법을 생각한다. 

그러나, 실제 진행할 때는 서비스와 시스템간의 종속 관계가 존재하므로 독립적인 단위시스템 단위로 전환하는 것은 쉽지 않다. 위에서 말한 것처럼, 현 시스템 아키텍처에 대해 사전에 정확한 파악이 이루어져야 하며 서로간의 종속 관계에 대한 아키텍처 다이아그램을 작성하여 우선 순위를 정해야 한다. 이를 작성하다보면, 전환의 대상이 단순한 단위시스템이 아니라 서비스 단위라는 것을 깨닫는 데에는 오랜 시간이 걸리지 않는다.

셋째, 장기적인 관점에서 전환 로드맵을 마련하여야 한다. 결국, 빅뱅 형태의 전면 차세대 재개발 형태로 프로젝트를 추진하지 않을 것이라면, 전환 리스크를 줄이기 위해서는 서비스 단위의 점진적인 전환이 고려되어야 한다. 이는 어느 한 시점에서의 전면적인 전환이 아닌, 여러 차수에 걸친 오픈소스 전환이 일어나야 함을 의미한다. 

따라서, 이러한 과정은 장기적인 시간을 요구하게 되며, 이에 맞는 로드맵 작성이 중요하게 된다. 일단, 로드맵이 완성되면 현 시스템 아키텍처 다이아그램을 사용하여 리스크를 다시 계산해보고, 반복적인 최적화 과정을 거쳐 최적의 전환 로드맵을 수립할 수 있을 것이다.


Migration Decision Tree(예시)

넷째, 전환 과정은 단순한 솔루션 전환만을 의미하지는 않는다. 서두에서 말했듯이, 오픈소스는 그 태생부터 이제까지 만나왔던 상용 솔루션들과는 다른 출발점에 서 있었다. 전환과정에서 겪는 어려움들 중 많은 부분들이 이러한 ‘다름’을 인정하지 않는 데에서 발생하는 경우가 많다. 

단적인 예로, 오픈소스 기반의 개발 툴들은 대부분 화두가 되고 있는 CI(Continuous Integration)/CD (Continuous Delivery) 사상 하에서 설계되었다. 이를 도입하기 위해서는 기존의 개발 방법론 및 전략을 수정해야할 수도 있다. 오픈소스 도입이 디지털 트랜스포메이션의 초석이 되는 기대 효과를 누리고자 한다면 여러분의 조직이나 프로세스도 어느 정도는 변화를 수용해야 할 것이다.

다섯째, 총소유비용(TCO)은 장기적인 관점에서 고려해야한다. 대부분의 IT관련자들이 오픈소스 전환을 통해 비용 절감 효과를 기대한다. 이중 가장 큰 부분이 연간 단위로 갱신되는 라이선스 비용의 절감에서 발생하게 되는데, 총소유비용 계산 시에 3년 이내의 단기간으로 계산 기간을 설정하게 되면 초기에 발생하는 마이그레이션 비용이 라이선스 절감 효과를 상쇄하는 현상이 발생할 수도 있다. 갱신 횟수를 감안하여 5년 정도의 기간을 두고 이를 산출해보는 것이 바람직할 것이다.

여섯째, 전환 기간 중 다양한 방법의 비용 절감 방안을 고려해본다. 몇 가지 예로, 커뮤니티 버전에 대한 활용과 전환 기간 중 한시적으로 오픈소스 운영에 대한 아웃소싱을 통해 인건비를 절감하는 방법을 들 수 있다. 장기적인 로드맵에 따라 전환 과제를 수행할 때 최종 전환까지의 중간 단계에서는 라이선스 비용의 절감을 위해 커뮤니티 버전을 사용할 수 있다. 

다만, 이에 대한 기술 지원이 문제가 될 수 있는데 시중에는 이를 지원하는 업체들이 존재한다. 또한, 전환과정에서 한시적으로 오픈소스 운영 인력을 아웃소싱하여 현재의 IT인력이 역량을 갖출 때까지 추가 인력의 충원 문제를 해결하는 것도 고려해볼 수 있다.

일곱째, 전문 업체를 통해 전환 프로젝트를 수행하는 경우, 건 단위가 아닌 전체 프로젝트에 대한 장기 계약을 고려해보아야 한다. 최근까지 국내에서 진행된 전환 프로젝트들은 과제별로 단기간의 프로젝트를 전문 업체와 계약하여 진행하는 경우가 많았다. 이렇게 진행할 경우, 프로젝트 이후 기술지원 문제, 프로젝트 중 사전에 인지하지 못했던 타시스템과의 종속성 발견 등으로 어려움을 겪는 경우들이 많이 발생한다. 따라서, 비용 효과를 고려하여 전환 프로젝트와 기술 지원을 묶어 장기 계약을 고려해보는 것이 바람직하다.

이제, 오픈소스 전환은 단순한 비용 절감 차원을 넘어서, 디지털 트랜스포메이션의 초석으로서 기업 IT에 필수적인 요소가 되고 있다. 모쪼록, 이 글에서 제시된 고려사항들이 오픈소스 전환 과정 및 준비 과정에서 조금이나마 도움이 되기를 바란다.

* 이상영 실장은 한국IBM 글로벌 테크놀러지 서비스에서 멀티클라우드 서비스 리더로 재직 중이다. ciokr@idg.co.kr

X