이번글은 AWSKRUG 프론트엔드 소모임에서 발표했던 클라우드 문외한에서 AWS 자격증까지,
프론트엔드의 AWS 적응기발표를 바탕으로 조금 더 많은 얘기를 공유하고자 작성합니다.
이 글은 인프라에 대해서 잘 모르지만 알아보고 싶거나 공부해보고 싶으신 엔지니어분들께 도움이 되는 글입니다.
1. Why Cloud?
저희는 왜 Cloud를 사용할까요? Cloud는 뭐고 Cloud라는것이 있기 이전에는 무엇으로 인프라환경을 구축했을까요?
Cloud
Cloud는 하늘과 같은 거의 무한한 자원을 탄력적으로 이동 및 분배할 수 있는 자원입니다.
주로 AWS, GCP, Azure, Naver와 같은 플랫폼을 통해 Cloud를 많이 활용합니다.
On Premise
반면에 사내에 직접 구축한 인프라 자원을 On Premise라고 합니다.
On Premise로 구축하면 안정된 자원이 생기므로 장점도 있지만 여러 불편한점이 생기기 마련입니다.
- 회사가 잘되면서 트래픽이 많아지는데 이를 갑자기 대응해야할때
- 특정한 날에만 트래픽이 많아지는 서비스
이런 환경에서 On Premise는 유연하지 못합니다. 이런 문제점을 좀 더 탄력적이고 유연하게 대응하기 위해서 Cloud를 활용합니다.
Devops
개발자의 경험을 증진하기위해 배포 관련 인프라, 다양한 자동화를 구축하는 직무는 Devops입니다.
Devops는 Development + Operation의 합성어로 개발 운영을 뜻하는 업무입니다.
저와같은 프론트엔드 개발자는 주로 하나의 스쿼드에 들어가 그 스쿼드에서 해결하고자 하는 목적을 만족시키기 위한 개발을 하지만, Devops는 여러 개발자들의 업무를 증진시키기 위해서 Cross Functional하게 업무를 진행합니다.
주로 Github Action, Jenkins와 같은 서비스로 서비스를 배포 진행하며 요즘은 이를 코드로 관리하는 IAS(Infra As Code)도 심심치 않게 볼 수 있습니다.
하지만 이렇게 글로만 보면 실제로 Devops에 대해 와닿지 않을 수 있어 정량적인 수치로 예시를 들어보겠습니다.
예를들어 우리 회사에 개발자가 1천명이 잇고 평균연봉이 7천만원일때 배포 시간 1분 단축시키는 업무를 하게 될 경우 배포 한번씩 할때마다 3365만원을 절약한 꼴이 됩니다.
이뿐만 아니라 개발자 생산성을 위한 다양한 업무, 실제 배포하는 환경 최적화 등 성장하는 혹은 이미 큰 개발팀에서는 정말 필요로 한 직무입니다.
클라우드를 접하며 알게 된 것
클라우드가 정말 중요하고 필요한지는 잘 알지만, 프론트엔드 취준할때만 해도 클라우드에 대해서 잘 알지 못했습니다.
주로 Netlify, Vercel과 같은 통합 플랫폼에서 자동 배포를 했었습니다.
하지만 이정도 수준으로는 회사에서 업무수준의 의사소통은 힘들었습니다. 관련하여 인프라를 접하면서 잘하게 된 제 경험들에 대해서 공유하려 합니다.
1. 원활한 소통
첫번째로는 원활한 소통입니다.
데브옵스 개발자님과 소통하면서 다음과 같은 대화를 할때 어려움을 겪었었습니다. 실제 회사에서 나눴던 대화들을 각색해봤습니다.
- 아 이건 EKS에서 띄운 파드가 문제가 있네요.
- 아 사실 그건 제가 방금 ECR에 Image 관련해서 문제가 있네요. Image를 Dokcer환경에서 다시 빌드하세요.
- Cloudfront로 헤더값에 Geo정보를 보낼게요.
이제 인프라를 공부하고 나서 EKS는 Container를 관리하는 Orchestration이라는 걸 알게 됐고 ECR은 Image를 관리하는 레지스트리, CloudFront는 CDN이라는걸 알게돼 회의에서 의사소통의 수준이 원활해졌습니다.
덕분에 회의에서도 보다 쉽게 아이디어를 낼 수 있었고 이는 곧 좋은 퀄리티의 제품까지도 이어졌습니다.
2. 넓어진 시야
두번째로는 넓어진 시야입니다.
저희 회사의 플랫폼이 존재하는데 이를 해외에 필요한 기능을 추가하고 마이그레이션 하기 위해 부분적으로 NextJS환경으로 차차 마이그레이션했습니다.
그러던 중 사내에서 특수한 상황이 있었습니다. 국내 Region에서 들어오는 요청은 이전에 개발된 플랫폼으로 라우팅하고, 해외 Region에서 들어오는 요청은 새로 만든 NextJS환경으로 라우팅 해야했습니다.
가장 간단한건 각 Region별로 URI로 분기하고 기존 회사 플랫폼 코드에 ClientSide에서 리디렉션 하는 방법이었는데 이는 유저경험 특히 해외에서는 좋지 못한 경험이라 생각했습니다.(당시 베트남 기준 한국 네트워크 환경의 1/4)
그래서 이를 해결하고자 보다 상위에서 이를 처리할 수 없을까 고민했고 아래와같은 아키텍처를 구성할 수 있게 됐습니다.
3. 비용 최적화
마지막으로 비용 최적화입니다.
AWS에는 Spot Instance라는 서비스가 존재합니다. 이를 직역하면 잉여 Instance입니다.
AWS는 전 세계 데이터센터에서 항상 가용 자원을 넉넉하게 확보해 둡니다.
하지만 사용되지 않고 유휴 상태로 남는 자원이 생깁니다.
AWS는 이 유휴 자원을 낭비하지 않고 효율적으로 사용하기 위해 Spot Instance로 제공하며 최대 90%할인된 가격으로 Instance를 제공합니다.
이를 활용하여 회사에서 비교적 안정적이지 않아도 되는 Dev환경에서 이를 구축해서 가격의 이점을 보는 환경을 구축하는 경험을 접해볼 수 있게 됐습니다.
2. 프론트엔드 배포 트렌드
프론트엔드 배포 트렌드에 대해서도 얘기해볼까 합니다.
이런 배포 트렌드가 왜 나왔는지에 대해서 보다 쉽게 이해하기 위해서 웹은 어떻게 발전했는지를 접하고 어떤 배포 방식이 존재하는지에 대해서 먼저 공유드리려 합니다.
웹 발전 흐름
오프라인에서 점유하던 많은것들이 온라인의 세계로 넘어오면서 웹은 발전했고 또 복잡해졌습니다.
초기에는 Wiki처럼 웹에서 문서를 보여주는것을 목적으로 하다가, 동적 데이터를 화면에 보여줘야 했고, 웹을 마치 하나의 모바일 어플리케이션처럼 다양한 일들을 할 수 있는 클라이언트로써 존재하며, 요즘 웹은 국내뿐만 아니라 해외에서도 잘 동작하도록 설계하는것이 흔해지고 있습니다.
이런 흐름에 맞춰 웹도 같이 발전해왔습니다.
HTML, CSS, Javascript
웹은 초기에 문서와 같았습니다. HTML(HyperText Markup Language)은 웹에서 마크업된 Text를 보여주기 위해서 존재했습니다. 그리고 DOM(Document Object Model)을 조금 조작하여 간단한 인터랙션을 할 수 있었습니다.
SSR(Server Side Rendering)
점차 웹이 발전하면서 웹은 단순하게 문서를 보여줄뿐만 아니라 실제로 변하는 데이터를 보여주고 이를 서버에서 렌더링한 HTML을 내려주는 방법을 취하게 됩니다.
현재는 하드웨어가 많이 발전해서 RAM 16GB라는것은 흔한 스펙이지만 이것이 발전하기 이전에는 하드웨어는 비싼 제품이었고 성능이 좋지 않았기 때문에 서버에서 렌더링하는것이 좋은 선택이었습니다. 그래서 성능의 문제와 변하는 데이터를 실시간으로 조회(Database)해서 렌더해주기에 유리한 SSR이 많이 사용됩니다. (JSP, PHP 등)
CSR(Client Side Rendering)
SSR은 장점이 명백했지만 클라이언트에서 화면이 바뀌거나 데이터를 저장하는 등 점차 복잡해지는 웹의 구현을 만족하기엔 쉽지 않았습니다
웹은 점차 많은것들을 할 수 있어야 했고 데이터를 웹에서 직접 조작하고 상태를 관리해서 화면을 새로 렌더링해줘야 하는 일들이 많아졌습니다.
하지만 SSR로 이 일을 처리하기엔 쉽지 않았으며, 모바일이 점차 가속화되고 배포되면서 유저의 하드웨어도 대부분 업그레이드 됐습니다.
그래서 이를 CSR로 해결하고자 합니다. 기본적인 메타데이터를 가지고 있지만 화면은 없는 빈 HTML과 클라이언트 앱에 대한 정보가 담긴 거대한 JS를 받아 클라이언트에서 렌더링하는 방법을 사용하게 됩니다.
Hybrid SSR
하지만 CSR은 많은 자원을 요구합니다. 당연하게도 Javascript의 크기가 커졌고 이는 유저에게 여전히 부담이었습니다.
그리고 사용자들의 하드웨어가 업그레이드 돼고 네트워크 환경도 개선되지만 그럼에도 불구하고 전 세계에서 균등한 성능을 보전받지 못합니다.
그리고 SEO도 CSR환경에서 많이 개선됐지만 그럼에도 불구하고 SSR만큼의 퀄리티는 제공하지 못합니다.
이를 개선하기위해서 필요한 부분만 Pre Rendering하여 초기 렌더링까지 오래걸리는 CSR의 단점을 보완하여 Chunk화돼 작은 사이즈의 자바스크립트를 Pre Rendering 된 HTML과 Hydrate하여 ClientSide에서도 잘 동적으로 작동하는 웹 어플리케이션을 구축하는 방법이 나옵니다.
Dynamic VS Static
크게 4가지의 흐름에 대해서 설명드렸는데 사실 배포관점에서 보면 Dynamic하냐 Static하냐 차이일 뿐입니다.
동적으로 데이터를 내려주거나 서버에서 렌더링한 결과물을 내려주기 위해서는 Server가 필요합니다.
또는 이미 약속된 결과물을 내려주는 정적인 자원을 내려줄때 필요한 웹서버가 필요합니다.
이에 따라 배포하는 방법이 다릅니다.
Dynamic 배포
동적으로 서버를 배포하기 위해서는 서버를 운영하기 위한 소스코드 그리고 이를 직접 띄우기 위한 환경이 필요합니다.
주로 AWS에서 EC2와 같은 인스턴스 서비스를 활용하거나 Serverless를 도입해서 운영하기도 합니다.
여기서는 Container로 서버를 배포하는 방법을 다룹니다. Container에 대한 설명은 챕터 3에서 좀 더 자세히 설명드리겠습니다.
Static 배포
정적으로 자원을 제공하기 위해서는 AWS의 S3와 이를 캐싱하는 레이어인 CloudFront(CDN)의 조합을 활용합니다.
배포 관점에서만 보면 Static하게 배포할때는 이를 저장할 버킷과 캐싱하는 레이어만 두면 이후에는 사실 운영관점에서 드는 자원은 거의 없습니다.
하지만 Dynamic하게 배포할때는 운영할때 많은것을 고민해야합니다. 서버의 인스턴스 스케일 업, 아웃의 기준은 어떻게 해야할지. 각 Container의 스케일을 아웃할때 공통적인 데이터 처리는 어떻게 해야할 지 등 많은 운영에 대한 고민이 생깁니다.
3. NextJS, Docker
앞서 설명드릴때 동적배포 시 Container로 배포하는 방법에 대해서 설명드렸습니다.
왜 Container로 배포하는것이 좋은지에 대해 앞서 알기 위해 NextJS환경에서 Container로 많이 활용하는 Docker로 설명드리려 합니다.
What is Container?
Container는 뭘까요?
Container는 애클리케이션 코드, 런타임, 그리고 이를 실행하기 위한 도구를 묶어둔 하나의 패키지입니다.
Why Container
컨테이너를 써야하는 이유에 대해서 이해하기 위해 몇가지 예시를 들어보려 합니다.
인프라를 관리할때 늘어나는 트래픽을 관리하기 위해 두가지 방법이 있습니다.
Scale Up(수직적 확장)
첫번째로는 수직적 확장입니다.
클라우드에선 빌리는 컴퓨팅 자원의 크기를 늘리는것을 뜻합니다.
수직적 확장은 가장 간단하지만 가격이 비선형적이라는 문제가 있습니다. 그리고 한 서버만 잘 관리하면 딱히 문제가 발생하지 않습니다.
Scale Out(수평적 확장)
두번째로는 수평적 확장입니다.
수평적 확장은 필요한것을 빌림에 따라 가격도 선형적이지만 이를 운영하기 위한 운영의 비용이 존재합니다. 여러 스케일을 나눈 서버들에서 어떻게 동일한 데이터를 처리할지, 캐시는 어떻게 둬야할지, 무슨기준으로 스케일을 확장해야할지 등 많은 고민이 필요합니다.
Wrap up
가격을 줄이기 위해서는 수평적 확장이 유리하지만 운영비용은 결코 공짜가 아닙니다. 그리고 이 운영비용 관점 즉 수평적 확장에서 Container는 빛을 발합니다.
Container는 배포를 위한 하나의 덩어리라고 설명드렸다 시피 여러 서버로 스케일을 확장할때 해당
그리고 엄밀히 따지면 Container가 생성되기전 Image를 만들어두고 이를 Container 환경으로 운영합니다.
이를 좀 더 이해하기 쉽게 하기위해 게임이라고 가정해볼겠습니다.
- 게임 사이트(레지스트리)에서 설치 지침(Dockerfile)으로
- 게임 다운로드 버튼을 누르면 해당 버젼에 맞게 내 컴퓨터에 게임이 다운로드(Docker Image) 받아집니다.
- 게임을 실행하는 클라가(Docker Container) 실행돼 게임을 할 수 있게 됩니다.
설치 파일은 하나만 있어도 여러번 실행해서 게임을 여러 창에서 돌릴 수 잇는 것처럼 하나의 이미지로 여러 개의 컨테이너를 동시에 띄울 수 있습니다.(수평적 확장)
Dynamic Deploy
그래서 우리는 Container를 활용합니다.
그리고 이런 여러개의 Container를 잘 관리하기 위한 플랫폼을 Orchestration이라 하며 ECS(Elastic Container Service), EKS(Elastic Kubernetis Service)와 같은 서비스를 많이 활용합니다.
하지만 주로 이 영역은 Devops가 하는 영역이니 저는 비교적 더 간단하게 운영할 수 있는 방법을 공유드리려 합니다.
ServerLess
저는 ServerLess를 ServerLease라고 부르고 싶습니다.
Less는 주로 없는 이라는 뜻으로 Server가 없이 운영가능한 환경이라고 많이 알려져있지만 저는 Lease(임대하다)라고 생각합니다.
ServerLess를 활용하면 운영할때 복잡한 과정(API Gateway, 로드밸런싱 등)을 어느정도 AWS에 위임하고 우리는 실제로 이 어플리케이션에 더 집중할 수 있도록 도와줍니다.
대표적으로 Container환경을 배포하는 환경을 임대하고 어느정도의 자동화를 지원해주는 Fargate라는 서비스가 있습니다.
4. AWS 자격증 그리고 Community Builder
이렇게 프론트엔드를 기반으로 클라우드(AWS)를 접하며 다양한것을 알게 됐습니다.
그리고 지식을 잘 알기위해서 가장 좋은 방법 중 하나인 자격증을 따리라 마음 먹었습니다.
AWS 자격증
AWS 자격증을 취득하기 위해서 우선 Cloud가 뭐고 네트워크는 어떻게 되는지 공부하고자 강의들을 들었습니다.
약 3주간 열심히 공부해서 73점으로 합격했습니다.
제가 들었던 자격증 관련 링크
AWS Community Builder
저는 BDD(Balpyo Driven Develop)을 선호하는지라 2024년에 총 4번의 대외 발표를 했습니다.
SSAPY에서 개발자가 인프라를 공부하는이유 라는 세션에 대해서 발표한적이 있고, 인프라 관련된 경험을 커뮤니티에서 자주 답변했으며 프론트엔드에도 깊은 고민과 공부를 하고 있어 이를 앞으로 보다 잘하기 위해서 2025 Community Builder를 지원했습니다.
이 글을 작성하는 2025.4.19기준으로 어제 Commnity Builder Welcome Kit도 받았습니다.
혹시나 다음 AWSKRUG Frontend 소모임에 오시면 이 모자를 보여드리겠습니다.
5. 끝으로
보다 의사소통을 잘하기 위한 관심사가 다양한 커뮤니티에서 발표 그리고 앞으로 저의 개발 부전공으로 꿈꾸게 될지는 몰랐습니다.
그리고 운좋게도 올해 2025 프론트엔드 웹, Mobile Community Builder가 됐습니다.
시작은 어설펐지만 끝은 창대하도록 노력하려 하고 AWS Re:invent에도 참여해보고 싶습니다.
뿐만 아니라 이번에 영어를 공부하기 시작했는데 세계의 다양한 개발자들과 커뮤니케이션 해보고 싶네요.(링크드인에 테슬라 개발자님이 일촌 거셨는데 알고보니 AWS Community Builder셔서 놀랐던 기억이 있네요 ㅋㅋㅋㅋ)
인프라에 대한 지식이 앞으로 더 필요로 하지 않을까 생각합니다. 다양한 에이전트들이 나오고 MCP가 나오며 프로젝트를 만들어내는건 이전보다 훨씬 적은 수고가 드는것 같습니다.
저도 이번에 claude code와 AWS Amplify를 활용해서 1시간도 안돼서 하나의 프로젝트를 만들었습니다.
코드는 어느정도 AI에 보정을 하고 인프라에 시간을 투자하면 더 좋은 시너지가 나지 않을까 생각하기 때문입니다.(물론 이마저도 미래엔 대체될수도..)
또한 올해부터 AWS Community Builder가 됐을뿐 아니라 AWSKRUG Frontend Chapter에서 오거나이저를 하게 됐습니다.
혹시나 프론트엔드 관련한 기술 공유를 하고싶으신데 발표할 자리를 찾고 계시거나, 고민하고 계시다면 편하게 댓글 혹은 제 LinkedIn으로 연락주시면 감사하겠습니다.
글이 쑥쑥 잘 읽히네요 잘 읽고 갑니다!