클라우드도 문제 정의를 잘해야 득이 된다

뉴스를 빠르고 유익하게 소비하기 No. 16

백신 예약시스템, 클라우드였다면… 이라는 기사를 봤습니다. 이렇게 시작합니다.

아마 대한민국 50대는 요 며칠 컴퓨터나 스마트폰 화면을 쳐다보면서 하염없이 기다려본 이들이 많을 것입니다. 누군가는 한참 기다리다가 뻗어버린 사이트로 인해 폭발하기도 했겠죠. 코로나19 백신 예방접종 사전예약 시스템 이야기입니다.

내 페친 중에서 흥분한 감정을 그대로 노출한 분들도 있어서 수긍이 가는 내용입니다. 그리고, 제가 속한 산업 경험 때문에 아는 바가 있습니다. 외주 개발에 의존하는 공공기관은 대응은 더디고, 서비스 구현 수준도 일반인이 접하는 인터넷 서비스에 비해 떨어질 수밖에 없습니다. 산업 구조가 그렇습니다. 오랫동안 고착화된 구조라서 개선이 필요합니다. (개선하지 않으면 압박이 들어오고, 이미 저 기사나 페북의 불만은 이런 압박의 실체죠.)

클라우드가 해결해주는 문제

따라서, 기사는 반만 맞다는 생각이 들었다. 클라우드의 대명사인 아마존(AWS)의 대표 서비스 중에 EC2라는 것이 있습니다. EC2 설명 페이지 내용을 봅시다.

Amazon Elastic Compute Cloud(Amazon EC2)는 Amazon Web Services(AWS) 클라우드에서 확장 가능 컴퓨팅 용량을 제공합니다.

알파벳 약자 E는 Elastic을 뜻하는데, 바로 확장 가능하다는 의미죠. 수요에 따라 서버 인스턴스를 늘린다고도 표현합니다. 그래서, 클라우드 서비스를 쓰면 문제가 없을까요? 그럴 수도 있고, 그렇지 않을 수도 있습니다.

클라우드와 무관한 문제

얼마 전 관심 있게 본 기사가 있습니다. 마이크로서비스에서 데이터를 중앙화하면 안 되는 3가지 이유라는 전문적인 개발지식을 다루는 기사였는데, 이 글에 대한 반응이 극명하게 가리는 것이 신기했습니다. 제 페친 중에 한 분은 아래와 같이 이 기사 링크를 공유했습니다.

이쪽 지식이 부족한 분들은 한국형 변태 MSA라는 말을 해석할 수 없습니다. 먼저 MSA는 마이크로 서비스 아키텍처의 약자인데, 흔히 마이크로 서비스라고 줄여서 부르기도 합니다. 프로그램을 한 덩어리로 만들지 않고, 비즈니스 유연성을 확보하기 위한 적당한 덩어리로 쪼개서 구축하는 방법입니다. 당연히 한 덩어리로 만들 때보다 프로그램 구성이 복잡해지지만 비즈니스 변화에 유연하게 하기 위해 택하는 전략입니다.

제가 전략이라는 단어를 쓴 이유는 상황에 맞춰 써야 하기 때문입니다. 그렇게 하지 않기 때문에 페친이 변태라고 쓰지 않았을까 추정합니다. 그리고, 한국형이라는 표현도 '우리나라만 그렇게 하는' 변칙을 뜻하는 말입니다.

기사에서 말한 데이터 중앙화를 유지한다면, 최악의 경우 클라우드 도입을 해도 여전히 뻗어버린 사이트로 백신 예약이 불가능한 상황이 그대로일 가능성도 있습니다.

데이터 중앙화가 악의 축이냐?

데이터 중앙화가 무조건 나쁘다는 말이 아닙니다. 오해는 마시길 바랍니다. 결국 프로그램이 백신 예약이 하나의 프로세스에 몰려 정체가 되지 않도록 짜야합니다. 그 과정에서 분산이라는 개념이 들어가는데, 분산의 구현은 물리적인 부분과 논리적인 부분으로 나뉩니다. 논리적인 부분은 프로그래머 혹은 개발자가 구획 짓는 영역을 말합니다. 흔히 설계라고 말하는 부분을 포함한 코딩 행위로 만들어지는데, 프로그램과 데이터 베이스 구성 모두를 다루죠.

이 부분의 역량 강화가 필요합니다. 인터넷 서비스 기업에서는 대체로 이런 문제를 풀고 있으리라 짐작합니다. 그런데 그렇지 못한 곳도 많습니다. 앞서 소개한 기사에 달린 댓글을 보겠습니다. 내용 전체를 동의할 수는 없습니다만 모두 일리 있는 이야기 있고, 현실을 잘 나타내고 있다는 생각이 듭니다.

조직의 사이즈란 결국 비즈니스 의사결정 단위와 관련해 있는데, 개발조직까지 고려해서 비즈니스 조직을 고려할 수 있는 곳은 인터넷 비즈니스가 아닌 기업에서는 거의 불가능하다 할 수 있습니다. 결론적으로 문제를 정확히 정의하지 않고, 솔루션만 강조하는 일은 문제를 해결하기는커녕 종종 문제를 악화시키기도 하기에 아침에 본 기사를 가지고 평소 생각들을 써봅니다.