[Cloud Computing] 다중 플랫폼 사용에 대한 고찰

정말 많은 종류의 클라우드 컴퓨팅 플랫폼이 존재한다.

---

고찰의 시작

얼마전 네이버클라우드에 재직 중인 전 회사 동료와 식사를 하게 되었고 아래와 같은 대화를 나누게 되었다.

필자: 네이버클라우드(이하 네클) 사용하다가 나중에 글로벌 시장에 진출하면 어떻게 해. 네이버클라우드 리전 별로 없잖아.

지인: AWS에 비해 없는거지 별로 없진 않아.

필자: 네클 사용하다가 리전없는 지역으로 서비스 확장하면 AWS랑 네클 연동해야하는데 연동하는 건 개발자들의 숙제아니야? CDN도 다른 서비스랑 연동해야할텐데...

지인: 그건 그렇지. 근데 AWS라고 모든 곳에 IDC가 있는 것도 아니고 그런거 해결하는게 진짜 개발자 아니야???

---

고찰 과정

하이엔드 개발자들은 어떤 생각을 하는지 궁금해하는 일반 개발자의 개인적인 의견이다.

이러한 대화를 하고 나서 생각해보니 필자는 항상 AWS만을 생각해왔다. 그 이유는 친숙하고 자료가 많으며 가장 큰 컴퓨팅 클라우드 플랫폼이기 때문이다. 또한 필자가 재직 중인 회사의 서버는 경우 총 세 개의 플랫폼으로 나뉘어 있다(AWS, NHN 등). 이러한 서버를 운영하다 보니 관리 포인트가 세 배로 늘어나고 공부할 것도 세 배로 많아져서 이미 많이 지쳐있던 상황이다보니 앞으로 새로운 서비스를 오픈한다면 "모두 AWS 종속적으로 인프라 구축을 해야겠다"라는 생각을 하고 있던 것이다.

하지만 지인의 말을 듣고 생각을 해보니 회사에서 플랫폼 사용에 대한 어떤 결정을 내릴지 모르고 또 어떠한 상황이 발생할지 모르는 상황에서 기술 검토 없이 No.1이라는 이유로 AWS에 모든 것을 의지하는 것은 맞지 않다는 생각이 들었다. 또한 플랫폼 간의 연동도 어떠한 이유가 되었든 간에 언젠가는 맞닥뜨릴 문제인데 복잡하다는 이유로 피할 수만은 없는 것이 현실이다.

"단일 플랫폼 사용"과 "다중 플랫폼 사용"의 장점과 단점은 무엇이 있는지 생각해보았다.

---

단일 플랫폼 장점:

서비스 구축 속도 향상:

단일 플랫폼에 종속적으로 개발하는 경우 플랫폼 내의 서비스들은 대부분 호환이 잘 되기 때문에 호환 걱정없이 인프라 구축을 진행할 수 있다. 예를 들어 AWS에는 CI/CD를 위한 서비스인 CodePipeline이 있다. Github와 같은 저장소에 코드가 Push되면 빌드와 배포를 담당하는 역할을 한다. 하지만 Gitlab은 공식적으로 지원하지 않는다.

만약 우리가 Gitlab이 아닌 AWS의 CodeCommit을 사용하고 있다면 CodePipeline과의 호환성은 걱정할 필요도 없을 것이다.

---

유지보수가 쉽다:

이미지와 같은 Third Party 라이브러리를 사용하여 Gitlab과 AWS의 CodePipeline을 연동했다고 가정해보자.

어느날 갑자기 CI/CD 파이프라인에 문제가 생겼다. 우리는 먼저 Gitlab에 정상적으로 Push가 되었는지 확인해야한다. 문제가 없다면 Build가 되지 않은 것인지 AWS의 CodeBuild를 확인해야하며 왜 Deploy가 되지않은지도 확인해야한다. 모든 부분에 문제가 없다면 우리가 사용하는 Third Party 라이브러리는 이슈가 없는지 확인해봐야한다. 만약 코드 저장소부터 CI/CD 파이프라인까지 전부 AWS 종속적이라면? 우리는 AWS 콘솔에서만 원인을 분석하면 된다. 문제 발생의 원인은 AWS 내부에 있다는 확신하에 디버깅을 할 수 있다.

물론 이런 CI/CD 서비스는 네이버클라우드에도 존재한다.

---

단일 플랫폼 단점:

타 플랫폼으로 이전하는 경우 많은 리소스 필요:

단일 플랫폼을 사용하며 단일 플랫폼 종속적으로 인프라를 구축하였다면 추후 플랫폼이 바뀌는 경우 상당한 리소스가 필요하다. 예를 들어 우리가 AWS의 코드 저장소인 AWS CodeCommit를 사용하고 있는 상황에서 플랫폼이 변경된다면 우리는 당장 코드를 저장하기 위한 저장소부터 바꿔야한다. 만약 우리가 AWS에 종속적이지 않은 Github와 Gitlab같은 서비스를 사용하고 있다면 코드 저장소와 인프라를 위한 플랫폼은 독립되어 있기 때문에 영향을 받지 않는다.

또 하나 예를 들어 쉽고 간편하게 Kubernetes환경을 구축하기 위해 직접 Kubernetes를 설치해서 운영한 것이 아니라 EKS를 사용하여 인프라를 구축하였다고 가정해본다. 어느 날 회사에서 네이버클라우드로 이전하게 되었으며 모든 서비스를 옮기라는 요청이 발생한다. 우리는 네이버클라우드의 Kubernetes Service를 공부해서 새로 인프라를 구축하거나 Kubernetes를 바닥부터 직접 설치해야한다.

만약 처음부터 AWS 인스턴스에 Kubernetes를 직접 설치하여 인프라를 구축하였다면 네이버클라우드로 이전하는 상황에서도 컴퓨팅 서비스에 AWS때와 동일한 방식으로 구축하여 사용하면 된다.

---

다중 플랫폼 장점:

여러 환경에 유연하게 대처 가능:

네이버클라우드 & AWS와 같이 여러 플랫폼을 같이 사용하는 경우에 하나의 플랫폼에서 지원하지 않는 기능이 있더라도 다른 플랫폼에서 찾아볼 수 있는 기회가 생긴다. 예를 들어 서버들간에 데이터를 공유하는 NAS 서버를 사용하고 싶은데 AWS에서 지원하지 않는 상황이라면 우리는 직접 NAS 서버를 구축해야한다. 하지만 네이버클라우드를 같이 사용하고 있다면 네이버클라우드의 NAS 서비스를 사용하면 된다.

우리는 다중 플랫폼을 사용하면서 더 많은 선택지를 가지게 되는 것이다.

다중 지역 지원:

단일 플랫폼만 사용한다면 해당 플랫폼이 지원하지 않는 리전이 있다면 필요한 시점에 해당 리전을 지원하는 플랫폼을 찾아서 검토해야한다. 하지만 여러 환경에서 유연하게 대처라는 장점과 동일하게 하나의 플랫폼에서 지원하지 않는 리전이 있더라도 다른 플랫폼에서 지원한다면 사용 가능하다는 장점이 존재한다. 한마디로 아래의 네이버클라우드 리전 이미지와 AWS 클라우드 리전 이미지를 겹쳐놓고 선택지를 찾을 수 있다는 의미가 된다.

네이버클라우드 리전

AWS 클라우드 리전

---

다중 플랫폼 단점:

인력 문제: 인프라 담당자를 채용할 때 플랫폼 별로 전문가를 구해야한다. 물론 돈 많은 대기업 입장에서는 큰 단점은 아닐듯하다.

호환성 문제: 기술을 검토할 때 플랫폼 간의 호환성을 고려해야한다.

유지보수가 어렵다: 플랫폼 별로 담당자가 따로 있는 것이 아니라면 한정된 담당자가 관리해야하는 관리포인트가 많아진다. 비용이 발생하는 부분도 두 배이며 문제가 발생하여 비용이 샐 수 있는 포인트도 두 배가 되기 때문이다.

---

고찰 결론

하이엔드 개발자들은 어떤 생각을 하는지 궁금해하는 일반 개발자로서 조심스럽게 결론을 내려본다.

• 단일 플랫폼 사용 & 다중 플랫폼 사용은 옳고 그름은 없고 각자의 장단점이 존재한다.
• 한정된 인력과 짧은 시간 내에 결과물을 만들어내야 한다면 단일 플랫폼에 종속적으로 개발하는 것이 훨씬 유리하다.
• 회사가 성장하면 지원하는 리전이나 특정 이유 때문에 다중 플랫폼을 사용해야하는 상황이 발생하겠지만 처음부터 모든 것을 계획하고 시작하려고 하면 시작조차 못할 수도 있다.
  이 부분은 상당히 조심스러운 부분인데 정말 잘하는 분들은 처음부터 모든 것을 예상하고 시작할 수도 있다. 어디까지나 필자는 그렇다는 것이다.

성공이 보장되어 있는 서비스를 출시한다면 얘기가 달라질 수 있지만 성공 여부가 출시 이후에 결정되는 서비스라면 처음에는 단일 플랫폼 종속적으로 빠르게 구축하는 것이 요즘 개발 트렌드에 더 적합한 방법이라고 생각된다.

---

지금까지 일반 개발자의 다중 플랫폼 사용에 대한 고찰에 대해서 얘기해보았다.