IDG 블로그 | “클라우드 네이티브가 나쁠 때도 있다”

클라우드 네이티브화되는 것은 좋다. 적어도 모두가 그렇게 이야기한다. 클라우드 네이티브화는 기존 애플리케이션을 리팩터링(부분적으로 재코딩하는 것)해 클라우드 네이티브 기능을 이용할 수 있도록 하는 것을 말한다. 클라우드 서비스 업체에 따라 다르겠지만, 네이티브 API부터 스토리지 시스템, 데이터베이스 시스템, 보안 시스템까지 많은 것을 누릴 수 있다.

클라우드 네이티브화하면 더 나은 성능, 더 낮은 애플리케이션 운영 비용, 더 쉬운 운영 등 수많은 이점을 클라우드 플랫폼이 발전하면 할수록 더욱 더 많이 누릴 수 있다.

하지만 클라우드 네이티브화의 어두운 면도 있으므로, 애플리케이션의 리팩터링에 상당한 시간을 들이기 전에 고려해 봄직하다. 고려사항은 다음과 같다.

종속성 문제. 기존 애플리케이션의 이식성 전부나 일부를 포기하지 않고 클라우드 네이티브 애플리케이션을 만들 수 없다. 애플리케이션을 AWS나 구글 클라우드 플랫폼, 마이크로소프트 애저에 맞춰 만든다면, 이들 애플리케이션의 네이티브 API에 맞춰 코딩해야 한다. 네이티브 API를 사용함으로써 해당 코드를 다른 코드로 옮기는 것도, 다시 리팩터링하지 않고는 온프레미스로 돌아가는 것도 어려울 것이다. 애플리케이션의 복잡성에 따라 다르겠지만, 상당한 시간은 물론 추가 위험도 감수해야 하는 일이 될 수 있다.

항상 누릴 수는 없는 클라우드 네이티브의 이점. 네이티브 서비스를 사용하면 어떤 방식이나 형태, 형식으로 이점을 얻을 수 있다. 하지만 언제나 그런 것은 아니다. 많은 IT 부서가 네이티브 API를 사용하지만, 운영기간 동안 이들 API 사용의 이점을 보지 못한다. 이들 API가 제공하는 이점이 무엇인지 이해하고, 일단 배치된 후에 이들 이점을 측정할 필요가 있다.

네이티브 기능의 변경. 클라우드 네이티브 API를 이용해 클라우드 서비스를 호출하도록 애플리케이션을 리팩터링하는 것은 충분히 어려운 일이다. 하지만 이들 서비스가 변한다면 더 어렵다. 비록 API 호출이 정적이라고 하더라도 이들이 액세스하는 서비스는 동적이며, 클라우드 서비스 업체는 이들을 자체적인 필요에 따라 변경할 것이다. 따라서 기업은 애플리케이션에서 어떤 것이 변경되는지 고려해 여기에 맞춰 대응해야 한다.

서비스 변경 자체는 나쁘지 않다. 하지만 이는 마음 편할 날이 없다는 뜻이 되며, 경우에 따라서는 이런 서비스 변경을 따라가기 위한 비용이 클라우드 네이티브 서비스를 사용하면서 얻는 가치를 초과할 수도 있다. 이 때 API 모니터링과 거버넌스 툴이 필요한데, 이들 툴은 API와 서비스 변경이 일어나면 이를 알려줘 제때에 대응할 수 있도록 해준다.

클라우드 네이티브 환경은 매력적이다. 그리고 대부분은 좋다. 하지만 다른 모든 기술적 선택처럼 장단점이 있기 마련이다. 애플리케이션 리팩터링에 착수하기 전에 장단점을 확실히 파악하기 바란다. editor@itworld.co.kr

David Linthicum editor@itworld.co.kr
저작권자 한국IDG & ITWorld, 무단 전재 및 재배포 금지