iCloud 얘기는 물론 아니다.
AWS를 필두로 Google Cloud Azure를 보면 최근 인프라 기술은 클라우드로 정리되었다고 봐도 과언이 아니다. 실제로 사용해보면 우리가 서버 운영을 하면서 필요한 모든 것 대부분의 것들이 인스턴스 즉 서비스의 형태로 구현되어 있다는 것을 알 수 있다. AWS의 예를 들면…
리눅스 서버가 필요하면 EC2. DB는 RDS. 검색엔진은 ElasticSearch. CI는 CodeDeploy…
개인 블로그에서 게임 서버와 같은 복잡한 서비스까지 안정적으로 운영되길 원한다면 AWS에서 약간의 러닝 커브와 함께 아주 편리하게 시작하고 운영할 수 있다.
Why?
컴퓨터 산업은 자동화의 역사라고 봐도 과언이 아니다. 아니 자동화를 위해 컴퓨터는 발전했다. 테이프 레코더를 저장 매체로 쓰기 시작해서 데이터베이스에 이르기까지 기술이 발전하는 원동력은 관리부담을 줄이기 위한 것이라고 해도 과언이 아니다. 안정성, 속도, 신뢰도, 백업 등등 사람이 하는 일을 때론 개념적으로 때로는 기계적으로 줄이기 위해서 노력해왔고 사실상 개념적인 발전은 거의 이루었다고 생각한다.
무언가를 수집하다 보면 결국 부동산의 한계에 다다르게 된다. 디스켓을 CD가 대체하며, CD를 USB 메모리가 대신하며 용량을 줄여왔지만 결국은 부동산 문제를 무시할 수 없다. 결국 이제 어디 하늘에 떠다니는 구름에 저장해놓고 필요할 때만 쓰자는 식이 꽤나 안정된 것으로 보인다. 개념적으로 이보다 나은 것이 나오기는 아마 어려울 것이다.
이런 일반유저 측 트랜드와 개발 면에서도 비슷하게 일어나는데 인터넷의 발전과 함께 더 빠르게 변화하게 되었다. 불과 20여 년 전만 해도 소프트웨어라는 것은 대부분 설치하는 것을 의미했다. 하드에 설치하고 실행하는 방식으로, 이메일이든 채팅 프로그램이든 여기서 크게 벗어나지 못했다. 인터넷이 당도하고, 기술이 성숙하자 모든 것이 바뀌었다.
사람들은 설치형 프로그램에서 웹으로 이동했고, 웹은 결국 모바일로 진화했다. 사용자에게 친화적이며 개발자에게도 큰 이익을 안겨다 주었다. 설치형 프로그램의 태생적인 한계였던 불법복제 문제를 아주 효과적으로 해결하였고, 이는 다른 컨텐츠 서비스에게도 전파되고 있다.
AWS Lambda와 Serverless Architecture
최근 AWS는 Lambda 인스턴스를 Serverless Architecture로 홍보하고 있다. 1년 전과는 사뭇 다른 모습이다. 1년 전 IoT 가 화두에 오른지도 좀 되다 보니 AWS에서도 이를 준비한 제품을 발표했었는데, 사실 그게 Lambda였다. 한 하드웨어 해커톤에서 처음 접했었는데, 다소 생소했지만 아주 매력적인 제품이라고 생각했었다. 그것을 이제 갑자기 엉뚱한 컨셉으로 세일즈하고 있다.
AWS에서는 IoT를 겨냥하고 거기에서 쓸만한 제품을 만들었는데, 사람들이 Spot Instance와 같은 방식으로 사용하는 걸 보니 이거다 싶어서 피봇한 것으로 보인다. 이슈화시키는 것까지는 성공했고, 현재는 주로 이미지 리사이징과 같은 컴퓨팅 파워가 필요한 상대적으로 중요성이 떨어지는 작업에 많이 쓰이는 걸로 보인다.
기세가 많이 꺾여있지만, IoT는 장기적으로 대세가 될 것이 분명하고, 관리부담을 확실히 줄여주는 서버 없는 아키텍쳐 또한 기세가 등등하니 AWS Lambda의 미래는 밝아 보인다.
Heroku 와 MongoLab
Heroku 와 MongoLab는 대표적인 PaaS 플랫폼으로, 전자는 서버 후자는 데이터베이스를 클라우드로 서비스하고 있다. 이는 어떻게 보면 AWS의 축소형이라고 볼 수 있는데 각각 AWS에서 서버와 데이터베이스 두 가지 인스턴스만 떼어냈다고 생각해도 된다.
우리나라에서는 아직 사용하는 팀이 별로 없는 것으로 보이지만, 해외에서는 프로덕션에서도 사용되는 인기 있는 서비스다. 대표적인 장점이라면 클러스터링이나 샤딩과 같은 스케일링에서 DB 복제와 CPU 업그레이드 같은 번거로운 일들도 자동으로 해준다는 것이다. 실제로 서버를 스케일링하는 작업은 처음부터 스케일링을 고려하지 않았었다면 클라우드 환경에서도 매우 까다로운 일이다.
스케일링이 필요하단 것은 중단 없이 서비스 인프라를 확장해야 할 필요가 있다는 것인데, 로드밸런싱이나 클러스터링 같은 작업에 서버 환경 동기화나 추가적인 배포 설정 작업, 보안 등등 많은 귀찮은 일들을 매우 빠르게 실수 없이 해야 한다는 부담이 개발자에게 얹어진다. 사실 스케일 아웃 해야 하는 상황은 대체로 일시적으로 트래픽이 급증할 때가 많은데, 개발자가 아무리 빠르게 실수 없이 작업을 마무리 지을 때면 이미 상황은 종료, 트래픽은 정상으로 떨어졌을 때가 대부분이다.
게다가 사실 이런 서비스들은 대체로 비싸다. 나름대로 무료 혹은 저렴한 레벨의 서비스가 있긴 하지만, 결국 그건 개인 용도로 쓸 때만 그렇고, 서비스의 규모가 커지면 일반적으로 서버만 제공하는 AWS, Google Cloud 같은 서비스보다 비용이 크게 높아지게 된다.
게다가 결국은 쓰는 만큼 내는 Pay As You Go 라고는 해도 서버가 떠 있는 동안은 트래픽이 발생하지 않더라도 비용은 계속 발생한다. 그렇다고 서버를 죽일 수는 없는 노릇이니 아쉬운 점은 있다.
미래의 클라우드 플랫폼
Heroku와 AWS는 사실 다른 고객층을 노리고 만든 것이 분명하다. 그러나 Lambda 같은 진정한 Pay As You Go 인스턴스가 출시되면서 벽이 허물어지고 있다. 결국 사용하는 측에서는 Lambda와 Heroku를 얼마나 다르다고 인식하게 될지 잘 모르겠다. 운영 비용이 빠르게 증가하는 Heroku를 버리고, 외려 DB나 Storage 같은 것들이 잘 되어있는 AWS로 이전 Lambda 기반의 서비스로 이전하게 될 수도 있다.
그렇다면 두 플랫폼을 섞으면 어떨까? 결국 개발자가 한 서비스를 런칭할때 고민해야 하는 CDN, 캐시, 서비스 서버, 데이터베이스, 데이터 분석, 에러 알림과 같은 모든 것들을 한 번에 처리해주는 클라우드 프로바이더가 분명히 나타날 것이다. Docker의 등장으로 이러한 것들이 더 빠르게 가능해질 것으로 보이는데, Docker는 서버 스케일링이나 리소스 모니터링, 가상화를 매우 강력하고도 편리하게 할 수 있는 솔루션이기 때문이다.
DevOps가 시대의 대세로 떠오르면서 개발자들에게 Full-Stack을 요구하는 것이 아주 일반적이 되었다. DevOps는 단순히 서버와 클라이언트 개발 기술을 알고 있다는 것을 의미할 뿐만 아니라, 지속적 통합과 배포, 단위 테스트 나 서버/DB 관리 같은 운영상의 이슈도 해결할 수 있어야 한다. 그러나 뭣이 중헌디 무엇이 더 중요하냐고 말한다면 나는 역시 개발이 더 중요하다고 생각한다.
네이버나 카카오 같은 대기업에서도 이제 대부분 서버는 클라우드로 운영하고 있다. 물론 그 정도 규모가 되는 회사들은 내부 클라우드 운영팀이 있지만, 어찌 되었건 이제 물리 서버 기반의 서비스는 점차 사라지고 있다. DevOps의 잠재력은 어디서 나타날까 한다면 나는 역시 개발에 있다고 보겠다. 빠르게 기능이나 비즈니스를 여러 형태로 시도해보려면 결국 서버와 클라이언트 기술을 전부 알아야 가능한데, 운영부담이나 인프라 문제를 껴안은 상태로는 절대로 속도가 나타나지 않는다.
한 회사의 생존에는 기술보다 영업이 중요하다. 영업 측에서 바라는 것은 기능이나 서비스를 빠르게 개발하는 것. 하지만 현재의 기술이나 인프라 스택이 받쳐주지 않는다면 개발 속도는 점점 더 느려진다. 개발 프로세스는 마치 젠가와 같아서 빼는 것도 중요하지만 쌓을때도 조심해야 한다. 젠가는 언젠가는 반드시 무너지지만, 잘못 쌓으면 훨씬 더 빠르게 무너진다.
개발자의 수요는 급증하는 데 반해 공급은 그렇지 못하다. 개발 과정은 마치 예술 공동작업과 같아서, 한 명의 개발자를 확보하는 것은 한 명의 아티스트를 키우기만큼이나 어렵다. 그런데 온전히 서버 관리하는 일에만 한 명의 개발자를 할당한다? 그다지 좋은 일이 아니라고 생각한다. 잘된 클라우드 플랫폼에 올라타는 비용과 개발자 한 명의 몸값을 비교하면 후자가 훨씬 비싸다.
고민하지 않고, 필요할때 스케일링, 개발자는 개발에 집중할 수 있는 클라우드 플랫폼. 과연 이게 허황한 생각일까?
원문 : Make It Yourself
