brunch

You can make anything
by writing

C.S.Lewis

by 강진우 Oct 31. 2019

온프레미스 엔지니어의 퍼블릭 클라우드 정착기

오늘은 기술적인 내용이라기보다는 이직 후 제가 경험했던 내용들에 대해 이야기해보려고 합니다. 제목 그대로 온프레미스 환경에 익숙했던 엔지니어가 퍼블릭 클라우드 환경으로 정착해 가는 과정을 통해서 그동안 느꼈던 것들 그리고 개인적인 고민들에 대해서 이야기해 보겠습니다.

이직의 이유

시간을 거슬러 올라가 먼저 이직을 하게 된 이유에 대해서 이야기해 보겠습니다. 저는 개인적으로 타 회사들의 채용 공고를 즐겨 살펴봅니다. 요즘에는 어떤 회사들이 소위 잘 나가고(?) 있는지, 그리고 어떤 직종들이 사람들의 선택을 많이 받는지 등등을 보면서 IT 업계의 트렌드를 읽어볼 수 있기 때문입니다. 처음에는 페이스북, 구글의 캐리어 페이지들을 살펴봤습니다. 그럼 이 회사들은 요즘 어떤 일들을 하기 위해 노력하고 있는지를 살펴볼 수 있었고, 시스템 엔지니어와 유사한 직종에 대한 Job Description을 통해서 실리콘 밸리에 있는 IT 회사의 시스템 엔지니어들은 어떤 업무를 하고 있는지도 살펴볼 수 있었습니다. 이런 관찰을 통해서 지금 제가 어떤 일을 해야 할지 그리고 어떻게 방향을 잡아서 나아가야 할지를 고민해 볼 수 있었고, 이런 고민을 사람들과 함께 나누며 시스템 엔지니어의 역할에 대해서 정립해 나갔습니다.

페이스북의 캐리어 페이지

하지만 언제부터인가 페이스북, 구글과 같은 회사의 채용 페이지보다 원티드와 같은 구인 서비스를 살펴보기 시작했습니다. 그리고 거기서 재미있는 현상 하나를 발견할 수 있었습니다.

바로 DevOps 엔지니어 혹은 SRE라는 Job Title이 빈번하게 등장하기 시작했다는 것이었습니다.

특히 원티드를 보면서 느낀 것은 생각보다 우리나라에 스타트업이 많다는 것과, 그런 스타트업에서 DevOps 엔지니어 혹은 SRE의 역할을 해줄 사람을 많이 찾고 있다는 것이었습니다. 해당 Job 들에 대한 Job Description을 읽어 보면 공통적으로 들어가는 한 가지 단어가 있습니다. 바로 AWS, GCP, Azure 등으로 대표되는 퍼블릭 클라우드입니다. 생각해 보면 퍼블릭 클라우드 운영 경험을 제외한 나머지 부분들은 제가 지금 하고 있는 시스템 엔지니어의 역할과 크게 다르지 않았습니다. 하지만 퍼블릭 클라우드에 대한 운영 경험이 부족한 저에게는 DevOps 엔지니어, SRE의 자리가 도전해 보기 어려운 하나의 벽처럼 느껴지기 시작했습니다.

DevOps 엔지니어 채용 공고

조금은 새롭게 퍼블릭 클라우드도 사용해보고 점점 영역이 넓어지고 있는 DevOps 엔지니어, SRE의 역할을 해보기 위해 어떻게 해야 할까 많은 고민을 하고 있던 시점에 마침 먼저 이직한 동료 개발자 분의 연락이 왔고, 고민 끝에 이직을 하기로 결심했습니다. 직접 겪어 보는 것보다 더 확실한 방법은 없었기 때문입니다.

AWS 시작하기

부푼 마음과 기대를 안고 새 회사에 첫 출근 한 뒤 AWS 콘솔을 보고 처음 느낀 건 "와.. 정말 서비스가 엄청나게 많구나"라는 것이었습니다.

AWS의 모든 서비스들

그나마 사용 경험이 있던 건 EC2 밖에 없었는데, 그동안 너무나도 많은 서비스가 출시되었습니다. 어디서부터 어떻게 시작해야 할지도 막막했던 시기에 가장 도움이 되었던 건 AWS 공식 블로그와 문서들이었습니다.

특히 https://docs.aws.amazon.com/ 는 지금도 제가 가장 많이 방문하는 사이트 중에 하나입니다. 사실 AWS의 서비스들이 어떤 역할을 하는지 전혀 모르는 경우는 많지 않습니다. EC2는 가상 머신을 사용하는 서비스 , S3는 오브젝트 저장소, RDS는 데이터 베이스 서비스 등등 대부분의 사람들이 AWS의 서비스들에 대해 개념적으로는 이해하고 있습니다. 하지만 이 서비스들이 구체적으로 어떤 기능들을 가지고 있고 어떤 역할을 할 수 있는지를 정확하게 파악해야 실제 업무에 사용할 수 있고 이를 위해서는 AWS 공식 문서 사이트가 가장 좋다고 생각 합니다. 이번에도 업무를 위해 메일 발송 시스템인 SES를 사용해야 할 기회가 생겼습니다. SES 서비스는 이메일을 수신 및 발송할 수 있는 서비스이며, 시작하기 가이드를 통하면 몇 분도 안 걸려서 실제 이메일을 보내볼 수 있습니다. 하지만 그런 정도의 경험을 가지고 업무에 사용할 수는 없습니다. 이 경우에도 AWS 공식 문서는 좋은 가이드를 제공해 주었고, SES의 동작 원리, 문제가 될 수 있는 부분 등을 알려 주었습니다.

만약 새로운 서비스가 등장해서 사용해 보려고 한다거나, 잘 모르는 서비스를 업무에 적용해 보려고 한다면 AWS 공식 문서를 시간을 내서 읽어보기를 권장합니다.

새롭게 하게 된 업무들

이번엔 조금 더 구체적으로 업무에 관한 이야기를 해보겠습니다. 환경이 변화된 만큼 기존에는 했지만 지금은 하지 않는 업무, 그리고 기존에는 하지 않았지만 지금은 하게 된 업무들이 자연스럽게 생기게 됩니다. 그중에 먼저 새롭게 하게 된 업무들에 대해 이야기해 보겠습니다.

퍼블릭 클라우드 환경에서 가장 임팩트 있게 다가왔던 부분은 IaC (Infrastructure as Code)로 표현되는 인프라의 코드화였습니다.

그리고 그 선봉장에는 테라폼이 있습니다. (https://www.terraform.io/)

테라폼 코드 예제

인프라의 구성을 코드 형태로 표현하고 이를 적용하면 인프라가 생성됩니다. 이런 형태의 업무는 온프레미스 환경에 있던 저에게는 문화 충격으로 다가올 만큼 신선했습니다. 예를 들어 개발/스테이징/베타/서비스 환경을 구축하는 작업을 해야 한다고 가정해 보겠습니다. 이 4가지 환경은 역할만 다를 뿐 사실 똑같은 구성으로 되어 있어야 CI/CD를 구현하기에도 편하고 서비스 환경에서 발생할 수 있는 다양한 이슈들을 미리 테스트해 볼 수 있습니다. 또한 이렇게 다양한 환경을 동일하게 구성할 수 있다는 것은 퍼블릭 클라우드가 가지고 있는 가장 큰 장점 중 하나일 겁니다. 온프레미스 환경에서는 비용적인 문제, 혹은 물리적인 구성의 문제 때문에 모든 환경을 똑같이 구성하기 어려웠다면, 퍼블릭 클라우드는 클릭 몇 번으로 인프라 리소스들을 생성/삭제할 수 있기 때문에 여러 환경을 똑같은 구성으로 만드는데 어려움이 없습니다. 다만, 콘솔만으로 작업하게 될 경우에는 너무 많은 수작업이 들어가게 되고 그 과정에서 사람의 실수가 발생하게 될 수 있습니다. 하지만 IaC 도구는 이러한 어려움을 해결해 주었습니다.

하나의 코드를 가지고 변수만 바꿔 주면 다수의 똑같은 형상의 인프라가 만들어지기 때문에 업무 효율성도 높아지고 퍼블릭 클라우드를 사용하는 장점도 충분히 챙길 수 있습니다.

코드 재활용을 통해 같은 인프라를 여러 환경에 배포

또한 이런 형태의 작업은 같은 업무를 하는 동료 엔지니어와의 커뮤니케이션도 훨씬 편하게 해 줍니다. 인프라에 어떤 작업을 하거나 변경이 필요할 때 그림을 그려가면서 이야기를 하거나 구두 상으로 길게 설명해야 하는 경우가 있었지만, IaC 도구를 활용하면 코드로 이야기할 수 있어서 어느 부분이 변경되었는지 찾아내기도 쉽고 실수로 인해 발생할 수 있는 장애에 대해서도 찾아내기 편합니다.

IaC를 통한 커뮤니케이션

특히 AWS에서는 security group을 수정할 때 장애가 발생하기 쉬운데 (필요한 룰을 빼거나, 불필요한 룰을 추가하거나) 이런 작업도 모두 코드화 되기 때문에 리뷰하기에 편해집니다.

다음으로 새롭게 시작하게 된 업무는 배포 시스템 구축입니다.

온프레미스 환경에서의 시스템 엔지니어로 업무 할 때는 배포 시스템을 구축하거나 관리하지 않았습니다. 회사마다 다르겠지만, 제가 있던 회사는 개발팀에서 직접 배포 시스템을 구축/운영하고 있었기 때문입니다. 배포 시스템을 엔지니어가 구축하고 관리한다는 건 다른 의미로 서비스의 품질 관리에 엔지니어가 좀 더 가깝게 다가가 있다는 것을 의미합니다. 온프레미스 환경에서는 서버 용량 부족으로 서비스에 장애가 발생했을 때 엔지니어가 할 수 있는 역할은 어느 정도의 서버가 더 필요할지 계산하고 서버를 준비하고 개발팀에 전달하는 것까지 였습니다. 즉 엔지니어가 아무리 빠르게 대응을 해도 개발팀에서 배포가 밀리게 되면 서버를 더 투입할 수 없게 되고 즉각적인 대응이 어렵게 됩니다. 이것은 사실 옳고 그름의 문제는 아니고 (개발팀이 빨리 대응해 줘야 하느냐 마느냐와 같은..) 업무의 롤이 다름으로써 발생하는 한계였습니다. 하지만 퍼블릭 클라우드 환경으로 넘어와서 배포 시스템을 구축하고 관리하게 되면 직접 배포가 가능해지고, 서버 용량 부족으로 인해 발생하는 이슈들은 서버 투입부터 배포까지 엔지니어의 의사 결정으로 빠르게 진행될 수 있기 때문에 서비스의 품질 관리를 할 수 있는 역할까지 추가가 된 것입니다. 이런 새로운 역할은 저에게는 굉장히 고무적이었는데, 그 이유는 서비스 품질을 결정할 수 있는 권한 때문이었습니다. 기존 환경보다 더 깊게 서비스에 관여하게 됨으로써 서비스에 대한 오너십도 더욱 크게 생기고 그에 따라 책임감과 책임 수준도 높아졌기 때문입니다. 또한 이렇게 엔지니어가 서비스의 품질에 더 깊게 관여하고, 배포 시스템과 관련된 업무를 지원함으로써 개발팀에서도 서비스 로직에 대한 개발 본연의 업무에 집중할 수 있고, 서비스의 품질을 관리하는 동료들이 더 늘어나게 됨에 따라 더 안정적인 서비스를 하게 되었다고 생각도 됩니다.

마지막으로 새롭게 시작하게 된 업무는 서비스 품질 관리 업무입니다.

이는 앞서 이야기했던 배포 시스템과도 결을 같이 하고 있는데, 배포 시스템 구축이 배포를 통한 서비스 품질 관리의 역할을 만들어 냈다면 퍼블릭 클라우드는 유연한 인프라 리소스의 변경을 통해 서비스 품질 관리의 역할을 만들어 냈습니다. 특히 오토스케일링을 이용한 유동적인 서버 대수 변경은 트래픽 급증에 따른 서비스 품질 저하를 막아낼 수 있는 가장 대표적인 업무 중 하나입니다. 지금 몸 담고 있는 beNX의 경우 위플리와 위버스의 트래픽이 몰릴 때는 평상시의 100배가 넘는 수준의 트래픽이 몰려오기 때문에 이를 어떻게 하면 유연하게 해결할 수 있는지를 고민하는 것 역시 중요한 고민거리 중에 하나입니다. 이 역시 퍼블릭 클라우드이기 때문에 대응이 가능하다고 생각합니다. 온프레미스라면 간헐적으로 들어오는 100배가 넘는 트래픽 때문에 상당한 수의 서버를 미리 보유하고 있어야 하고 결국 비용적인 부담이 매우 커지기 때문입니다.

순간적으로 치솟는 트래픽 그래프

온프레미스 환경에서도 엔지니어에게는 서비스 품질을 관리해야 하는 역할이 있었지만 퍼블릭 클라우드로 넘어오게 되면서 그 역할이 더 중요해지게 됩니다. 코드 버그를 제외한 대부분의 장애는 인프라를 구성하고 있는 요소들에서 발생하기 때문에 (네트워크 문제, 데이터베이스 문제, 서버 용량 부족 등등) 장애가 발생하게 되는 경우 퍼블릭 클라우드의 상태를 점검하고 대응할 수 있는 엔지니어의 역할이 더욱 중요해지는 건 당연한 것이 될 겁니다.

달라지지 않은 업무들

지금까지 퍼블릭 클라우드 환경에서 새롭게 하게 된 업무들에 대해서 이야기했는데, 이번에는 달라지지 않은 업무들에 대해서 이야기해 보겠습니다. 흔히 온프레미스 환경에서 퍼블릭 클라우드 환경으로 넘어오게 되면 환경이 달라졌다 라는 사실에 너무 빠져서 부담을 느끼게 되기 쉬운데요, 실제로 퍼블릭 클라우드라는 환경에 조금 익숙해지기 시작하면 업무가 그렇게 많이 달라지지 않는다는 것을 느끼게 됩니다.

우선 가장 중요한 업무인 인프라 설계 업무입니다.

온프레미스 환경이든 퍼블릭 클라우드 환경이든 서비스를 구성하기 위해 인프라를 설계하는 업무는 엔지니어에게 가장 중요한 업무입니다.

인프라 아키텍처링

이 업무는 오히려 온프레미스 환경에서 오랫동안 경험해 왔던 것들이 더욱 도움이 되었습니다. 온프레미스 환경은 대부분 어느 수준 이상의 트래픽이 인입되는 곳이 많기 때문에 작은 트래픽을 처리할 때와는 다른 설계가 필요합니다. 요소들을 더 잘 나누어야 하고 트래픽을 잘 견뎌낼 수 있는 설계가 필요하기 때문입니다. 전체 그림을 그리고 각 부분에 퍼블릭 클라우드의 어떤 서비스를 사용할 것인지, 예를 들어 로그 수집을 위해 ElasticStack을 구성할 때 퍼블릭 클라우드에서 제공해 주는 ElasticSearch 서비스를 사용할지, EC2 위에서 직접 ElasticSearch를 설치해서 사용할지 등등을 잘 설계하고 결정해야 합니다.

다음은 성능 최적화와 관련된 업무입니다.

온프레미스 환경에서도 퍼블릭 클라우드 환경에서도 서버가 최적의 성능을 내도록 하는 것은 매우 중요합니다. 상대적으로 저렴한 서버 비용과 유연한 대응이 가능하다고는 해도, 퍼블릭 클라우드 환경에서 제공되는 서버를 그대로 사용할 수는 없습니다. Amazon Linux 2는 안정적이고 좋은 성능을 보여주지만, 커널 파라미터들은 튜닝이 되어 있지 않기 때문에 반드시 튜닝한 후 서비스에 투입되어야 합니다. 이렇게 튜닝이 잘되면 10대로 받아낼 수 있는 트래픽을 1대로 받아낼 수도 있고, 이런 것들이 인프라 비용 절감에도 효과를 주지만 결과적으로는 개인의 기술력 향상에도 도움이 되기 때문입니다.

다음은 모니터링 관련된 업무입니다.

온프레미스 환경이건 퍼블릭 클라우드 환경이건 서비스 품질에 대한 모니터링은 반드시 해야 하는 업무입니다. 애플리케이션의 로그를 수집하고 에러 로그를 추출해서 알람을 보내고, 각 인프라 요소들에서 발생하는 이상 징후를 감지해야 하는 업무들은 환경을 따지지 않고 엔지니어가 해야 할 중요한 업무들입니다. 또한 온프레미스 환경과 마찬가지로 서버들의 CPU 사용량, Load Average, 디스크 사용량 등 각종 메트릭을 수집하고 모니터링해야 하는 업무는 그대로 이어집니다.

CloudWatch를 통한 인프라 모니터링

모니터링 데이터를 수집하기 위한 백엔드가 Cacti, Zabbix 등등에서 CloudWatch로 변경되거나 할 수는 있습니다. 물론 온프레미스 환경에서 사용하던 Cacti, Zabbix 등과 같은 전통적인 오픈소스 모니터링 툴을 사용해도 좋습니다. 이건 어디까지나 개인의 취향 문제이니까요. 다만 어떤 툴을 사용해서 모니터링을 하던지 간에, 기존에도 해왔던 모니터링 업무를 계속한다는 것이 중요합니다. 오히려 퍼블릭 클라우드 환경에서는 인프라의 변경이 모두 API 등을 이용해 소프트웨어 적으로 변경되기 때문에 모니터링 툴과 자동화 툴을 결합해서 더 견고하고 유연한 인프라를 구축할 수 있습니다.

그리고 마지막으로 자동화 시스템 구축 업무입니다.

자동화 시스템 구축과 관련된 업무는 온프레미스 환경에서도 항상 진행하던 거지만, 퍼블릭 클라우드 환경으로 넘어오면서 오히려 더 제약이 없어지고 영역이 넓어진 업무입니다. 특히 AWS의 람다를 이용한 자동화 시스템은 기존 온프레미스 환경에서 할 수 있었던 자동화의 한계를 넘어서 무한한 가능성을 보여주고 있습니다. 예를 들어 개발팀에서 새로운 개발 코드를 빌드하고 jar 파일을 만들어서 S3에 업로드하면 람다는 S3에 파일이 업데이트되었다는 이벤트를 감지해서 어떤 파일이 업데이트되었는지를 확인하고 어떤 개발 서버 배포할지 판단해서 개발 서버를 새롭게 배포합니다. 이런 형태의 자동화 파이프라인을 만들어 놓으면 개발팀에서는 개발 후 빌드만 하면 새로운 개발 소스가 개발 서버에 자동으로 배포가 됩니다. 이렇게 람다는 AWS의 각 구성요소와 연동할 수 있으며, 서버를 띄워 놓고 서버를 관리해야 할 이슈도 없애주기 때문에 관리에 대한 스트레스 없이 활용할 수 있으며 이를 통해 높은 수준의 자동화 시스템을 구축할 수 있습니다.

마치며

사실 이직을 하면서 가장 크게 고민했던 점은 과연 내가 잘할 수 있을까 였습니다. 새롭게 달라지는 환경에 잘 적응할 수 있을까.. 이직을 하는 사람들은 누구나 이런 고민을 하겠지만, 이번 이직에서는 내가 가장 잘하던, 그리고 익숙한 환경이 아닌 새로운 환경에서도 잘 해낼 수 있을까에 대한 고민을 무척 많이 했습니다.

이직 후에도 빨리 성과를 내야 할 텐데 라는 조바심이 들면서 스스로를 괴롭게 한 적도 무척 많았습니다. 그리고 이제 와서 제가 초기에 만들었던 테라폼 코드를 보면 정말 부끄러울 수준으로 엉망진창의 코드들이었습니다. 뭔가 빨리 해내고 싶다는 조바심에 엉망진창의 테라폼 코드를 만들어 가면서 일을 했습니다.

하지만 이런 과정들이 있었기에 지금은 그나마 정상적인(?) 테라폼 코드를 만들고 협업도 가능한 게 아닐까 생각이 듭니다. 그리고 이제 와서 천천히 살펴보니 환경은 달라졌지만 하고 있는 업무는 큰 틀에서는 많이 달라지지 않았다는 생각도 하게 되었습니다. 위에서 언급한 것처럼 새롭게 시작한 업무들이 있고 이제는 하지 않는 업무들도 있지만, 달라지지 않은 업무들도 있습니다. 그리고 달라지지 않은 그 업무들이 실제로는 엔지니어의 가장 중요한 업무들이라고 생각합니다.